# Forte — FDP Cycle Backlog

Exhaustive, ordered list of every Feature Development Process cycle needed to close the gaps identified in `forte_roadmap.md` Section A. Each row below is one full `{feature_name}` that will get its own Step 1-4 planning docs and (where warranted) feature branch, run one at a time. Order reflects dependency and value judgment beyond item 1; only item 1 is confirmed — feel free to reshuffle the rest.

| # | Feature name | What it covers | Step 1? |
|---|---|---|---|
| 1 | `forte_identity_signing` | ✅ Done — see `forte_identity_signing_step4_implementation_summary.md`. Wire browser-key signed authorship into Forte's reply composer instead of always posting as anonymous "guest" — the flagged correctness issue. **Confirmed first; scoped to the board view only** now that the single-thread view is being deprecated (item 2) — no per-page-type split needed. | Yes — approach choices for the board view specifically (reuse `lazy_compose_signing.js` as-is vs. eager-load vs. a Forte-native indicator) |
| 2 | `forte_deprecate_single_thread_view` | ✅ Done — see `forte_deprecate_single_thread_view_step4_implementation_summary.md`. Deprecate, then remove, the single-thread Forte reader (`/threads/{id}/forte`, `forte.php`) in favor of board-view-only. Confirmed low-risk: nothing outside Forte links to this route, and the board view is already fully self-contained (no `href` back to it anywhere). Queued right after identity-signing so no later cycle builds more into a view about to be removed. | Optional — no real solution ambiguity in "delete these files/route," but worth a Step 2 to record the rationale given it reverses several previously-shipped features (`forte_step1-4`, `forte_reply`, `forte_keyboard_navigation`'s single-thread half) |
| 3 | `forte_compose_thread` | ✅ Done — see `forte_compose_thread_step4_implementation_summary.md`. Wire the permanently-disabled "New" toolbar button to actually compose a new thread, reusing `thread_compose_form.php` (a different canonical form than the one `forte_reply` already reused). Board-view-only by the time this runs. Step 1 recommended reusing the Reply panel's toolbar-panel pattern; user chose a native `<dialog>` instead (Option C). | Recommended — same "native vs. bolted-on" congruence question that came up for replies |
| 4 | `forte_reactions` | ✅ Done — see `forte_reactions_step4_implementation_summary.md`. Like/Flag buttons on posts/threads, reusing the existing `/api/apply_thread_tag` / `/api/apply_post_tag` endpoints. | Optional — straightforward reuse, low ambiguity |
| 5 | `forte_post_permalink` | ✅ Done — see `forte_post_permalink_step4_implementation_summary.md`. A shareable direct link to one specific post (classic has `/posts/{id}`; Forte has none). **Needs rework given item 2**: the original idea assumed the single-thread view's own URL scheme — this now needs to resolve to `/forte?selected=...`-style restoration instead, similar to the existing new-reply highlight mechanism. | Recommended — URL scheme and redirect-vs-direct-render are real choices |
| 6 | `forte_classic_nav_bridge` | A way to reach classic-only pages from Forte (or back). Reverses a stated non-goal (`forte_step2`: "no link from Forte back to the standard page"), so this needs a deliberate decision, not just an implementation pass. **Dependency note:** may need to land alongside or before later identity/account-management polish, since `/account/key` itself is a classic-only page. | Yes — this is a scope-reversal decision, not just a build |
| 7 | `forte_profiles` | ✅ Done — see `forte_profiles_step4_implementation_summary.md`. Profile pages, user directory, and linking author names to profiles instead of plain text. Built Forte-native (not via the nav bridge): `/forte/profiles/{slug}`, `/forte/user/{username}`, `/forte/users/`, plus a quick-glance summary dialog on author-name click. "Approve user" deliberately excluded, deferred to item 11. | Recommended — several viable approaches (full Forte-styled page vs. reusing classic's page via the nav bridge above) |
| 8 | `forte_tag_index` | A browsable, shareable tag index (`/tags/`, `/tags/{tag}`) distinct from the board's filter-only folder tree. | Optional — additive, low ambiguity |
| 9 | `forte_activity_feed` | A Forte-native view of classic's `/activity/` recent-activity feed. | Optional, but worth a quick Step 1 to scope what "activity" means in a paned layout |
| 10 | `forte_mobile_responsive` | An engineered (not pragmatic-fallback) mobile/narrow-viewport layout, including fixing the known Subject-column squeeze at 420px. | Yes — genuine breakpoint/layout strategy trade-offs |
| 11 | `forte_user_approval` | The pending-user approval workflow (`/users/pending/`, approve endpoints) — administrative/moderator-facing. | Recommended — permissions and surface-area questions |
| 12 | `forte_agent_replies` | Agent responses to comments and posts — requesting/viewing an automated agent reply on a post or thread (classic's `request-agent-reply` action). **Narrowed 2026-09-16**: originally bundled with the Codex handoff/approval workflow; split out per explicit user direction so each gets its own cycle — see item 14. | Recommended — request/visibility UX choices, but smaller than the original bundled item |

| 13 | `forte_thread_selection_url_sync` | ✅ Done — see `forte_thread_selection_url_sync_step4_implementation_summary.md` (grew beyond the original ask to also close the server-side "flash of wrong state" gap for permalinks/reply-redirects). Push `selected={threadId}` to the URL bar on every plain thread-row click/arrow-key selection, mirroring the `pushStateIfChanged(urlForState(...))` pattern tag/sort changes already use — today only tag/sort changes update the URL; selecting a thread doesn't, so a reload loses it. The "restore on load" half already exists (the board already reads `?selected=` on load for the reply-redirect landing case) — this only adds the missing "push on click" half. Related to, but independent of, `forte_post_permalink` (item 5): permalinks are explicit hrefs and work the same regardless of whether this lands. Requested directly by the user, 2026-09-15, to prepare for later — not scoped into item 5. | Optional — small, mirrors an already-proven pattern in the same file |

| 14 | `forte_codex_handoff_workflow` | The Codex handoff/approval workflow (classic's `request-codex-handoff` action and the approval steps after it) — administrative/agent-operator-facing. Split out of the original bundled item 12 (`forte_agent_codex_workflow`) per explicit user direction, 2026-09-16, so agent-replies and Codex handoff each get their own cycle. | Yes — the largest, least-defined item on this list |

**Total: 14 FDP cycles.**

## Not on this list (handled outside FDP)

Per `forte_roadmap.md` Section C, these rough edges are small enough to fix directly (as we did for the composer focus/scroll and new-reply-highlight polish) rather than running a full cycle each: the dead New/Refresh buttons (✅ New resolved by cycle #3, `forte_compose_thread`; Refresh still has no clear job), missing empty-state messaging, no error-surfacing in the composer JS, and the missing `aria-live` announcements. Flagging them here only so nothing from the roadmap silently disappears — revisit as direct fixes whenever convenient, or promote any of them to a full cycle later if they turn out bigger than expected.

## Next step

Start Step 1 for `forte_identity_signing` whenever you're ready.