Repository source: docs/plans/forte_fdp_cycles.md
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.