# Forte Hidden Content Permalinks — Step 4: Implementation Summary

## Stage 1 - Board-visibility-independent content-summary endpoint
- Changes:
  - New `GET /api/get_forte_content_summary?post_id=...` route, handled by new `handleForteContentSummary(array $query): void`.
  - New `forteContentSummary(string $postId): ?array` - resolves via the existing `fetchPost()` (the same lookup every other single-post read uses), not the board's own filtered `fetchThreads()`, so identity/bootstrap/approval-only posts resolve exactly like any other post. Returns `post_id`, `thread_id`, `is_reply`, `title` (via the existing `ThreadTitle::displayTitle()` helper), `author_label`, `created_at`, `body_preview` (full body - the dialog itself scrolls), and `reply_count` (from `threads.reply_count` for the post's root). `null`/404 for an unknown post id.
- Verification:
  - `php -l` - no syntax errors.
  - `GET ?post_id=<board-visible reply>` - 200, correct thread id, `is_reply: true`, `reply_count` matches the thread's real count.
  - `GET ?post_id=<hidden identity_bootstrap post>` (`agent-bootstrap-20260502071201-2d91e107`, excluded from the board's own listing) - 200, resolves exactly like a normal post - the entire point of this endpoint.
  - `GET ?post_id=<genuine root thread>` (`root-001`) - 200, `is_reply: false`, `thread_id` equals its own `post_id`.
  - `GET` with a nonexistent id, and with no `post_id` at all - both 404.
  - Regression: classic `/activity/`, `/forte/`, `/forte/activity/` all still 200.
- Notes:
  - Caught and fixed a wrong assumption during verification: `posts.thread_id` is self-referential for a root post (equals its own `post_id`), never `NULL` - so `thread_id !== null` is not a valid root/reply check for this table (unlike a similarly-named check on a different, write-side domain object seen elsewhere in this codebase, which does use `null` for "is a root"). `posts.parent_id` (`null` only for a root) is the correct discriminator here; caught by comparing actual query output for a known root post against a known reply before trusting the first draft.
  - `isApplicationRoute()`'s route allowlist (used only for members-only-mode gating) was not updated for this new endpoint - the same precedent as `/api/forte_commit_detail`/`/api/forte_activity_page`, neither of which are in that list either, and both already work correctly without it.

## Stage 2 - Content-summary modal on the Activity page
- Changes:
  - New `templates/partials/paned_content_summary_dialog.php`, mirroring `paned_profile_summary_dialog.php`'s structure exactly (native `<dialog>`, title bar with close button, loading/content/error states inside `.paned-standalone-body` - already scrollable via existing CSS, no new styles needed) with fields for kind (Thread/Reply), author, date, reply count, body text, and a "View full thread" link. Included from `forte_activity.php` as a sibling of `.paned-board-layout` (same placement `paned_profile_summary_dialog.php` uses in `forte_board.php`), so it survives `softNavigateToSort()`'s wholesale layout swap and only needs wiring once.
  - New `showContentSummary(postId, fullHref)` in `paned_activity_reader.js`, mirroring `showProfileSummary()` in `paned_board_reader.js` field-for-field: sets the "full link" href, opens the dialog, fetches Stage 1's endpoint, and populates the dialog (falling back to an error state on failure). A document-level click listener (bound once, matching the profile-link interception pattern including its modifier-key/middle-click bypass) intercepts `[data-forte-content-link]` clicks and opens the dialog instead of navigating - the anchor's real `href` stays set underneath for a no-JS/failed-JS fallback.
  - `paned_activity_detail_article.php`: content links now carry `data-forte-content-link data-post-id="<id>"` (`forte_link`'s `label` is already the target post id in every real content case) - excluded for `site_feature_flag`, whose link isn't a post at all.
- Verification:
  - `php -l` / `node --check` - no syntax errors.
  - Browser (Playwright): clicking a board-visible item's content link opens the dialog in place (URL unchanged), correct title/author/kind/reply-count/body populate from the live endpoint, close button closes it.
  - Browser: clicking a *hidden* `identity_bootstrap` item's content link (item 226, `view=bootstrap`) also opens the dialog correctly - this already works today, before Stage 3 even removes the classic-fallback href, because the interception only checks for `data-forte-content-link`/`data-post-id`, not the link's destination form. Its "View full thread" link still points at the classic route for now (expected - Stage 3 changes the href form, Stages 4-5 make that new form actually resolve).
  - Regression: normal row selection/keyboard nav on the Activity page unaffected; classic `/activity/` and the Forte board (`/forte/`) unaffected.
- Notes:
  - No `activityItemBoardLink()`/href changes in this stage - purely additive dialog/JS/template-attribute work, as scoped.

## Stage 3 - Every content link routes through the new preview
- Changes:
  - `activityItemBoardLink()`: dropped the `isBoardVisible` check and the classic `/posts/`/`/threads/` fallback branch entirely - any item with a resolvable thread/post id now always returns the `/forte?selected=<threadId>&created_post_id=<postId>#post-<postId>` form. `site_feature_flag`'s distinct destination is unchanged; an item missing a resolvable id still returns `['href' => '', 'label' => '']` (no link rendered at all, same as before).
- Verification:
  - `php -l` - no syntax errors.
  - Item 226 (hidden `identity_bootstrap`, `view=bootstrap`): link href is now the `/forte?selected=...` form (previously classic); clicking it opens the summary dialog correctly, and the dialog's "View full thread" link now also uses the new form (still won't resolve as a real board destination until Stages 4-5 - expected).
  - Item 1337 (`thread_label_add`, root `root-001`): link correctly resolves to the thread's root id; dialog opens with the root thread's own summary ("Hello world"), no error.
  - Regression: all 5 activity views (`all`/`content`/`identity`/`bootstrap`/`approval`) load correctly; classic `/posts/root-001`, classic `/activity/`, and RSS all still 200/unaffected (their own routes and rendering are untouched - only the Activity page's own link generation changed).
- Notes:
  - Between this stage and Stage 5, a hidden thread's "View full thread" link is a real, well-formed URL that doesn't yet land on working content - an expected, temporary gap called out in the Step 3 plan, closed by Stages 4-5.

## Stage 4 - Resolve a hidden thread on demand for the board
- Changes:
  - New `fetchThreadById(string $threadId): ?array` - the exact query `fetchThreads()` runs, minus its `isHiddenBootstrapBoardTagsJson` exclusion, for one thread by id; reuses the existing `hydrateThreadRow()` single-row hydrator so its shape matches every other thread row exactly.
  - `renderForteBoard()`: when `resolveForteBoardSelection()` can't find the requested selection in the board's own (filtered) `$threads`, it now tries `fetchThreadById()` directly; a hit sets `$selectedThreadId` and produces `$contentThreads` (`$threads` plus this one extra thread) - `$threads` itself, `$tagGroups`, and all counts stay untouched. Reply-tree building, `$allPostIds`, `$highlightedPostId`, and the viewer-like/flag lookups now iterate `$contentThreads` instead of `$threads`, so a hidden thread's replies/reactions render correctly too - `fetchAllThreadReplyPosts()` already covers every thread regardless of board-tag visibility (it only filters moderation's `is_hidden`), so no new reply-fetching was needed.
  - `forte_board.php` passes the new `$contentThreads` (not `$threads`) to `paned_board_content_pane.php` specifically - `paned_board_thread_list.php` and the folder tree/status bar keep receiving the original, unaffected `$threads`.
- Verification:
  - `php -l` - no syntax errors.
  - `GET /forte?selected=<hidden identity_bootstrap root>`: 200, its content article renders and is unhidden (selected), no matching row exists in the list, and `data-paned-board-total-count` is unchanged (530, same as a plain `/forte/` load).
  - `GET /forte?selected=<hidden thread with a real reply>&created_post_id=<that reply>`: 200, the reply tree renders inside the hidden thread's article (no PHP warnings/fatals in the response).
  - `GET /forte?selected=<nonexistent id>`: 200, falls back to the "no thread selected" placeholder exactly as before this stage (regression-safe for an unresolvable id).
  - Regression: `GET /forte?selected=<a normal, board-visible thread>` still gets both a list row and a content article, exactly as before.
  - Confirmed (expected, not yet fixed): visiting the dialog's "View full thread" link for a hidden thread in a real browser doesn't yet show it - the client-side `restoreSelectionFromUrl()` still requires a matching *visible row* before it will select anything, which this stage doesn't touch. This is precisely Stage 5's job.
- Notes:
  - `replyEnabled` (toolbar prop, `selectedThreadId !== ''`) becomes true for a hidden thread too once Stage 5 lets the client actually select it - left as-is deliberately: a reader replying to a bootstrap/hidden thread is an existing, valid capability this feature doesn't need to restrict, not a new one it's introducing.

## Stage 5 - Client-side selection for a thread with no list row
- Changes:
  - `restoreSelectionFromUrl()` in `paned_board_reader.js`: when `?selected=` matches no visible row, it now also checks for a matching content-pane article (`data-paned-board-content-post-id`) before giving up - only falling back to the "no thread selected" placeholder if neither exists. `selectThread()` itself needed no changes; its row-matching loop was already tolerant of zero matches. Row scroll-into-view is skipped when there's no row (nothing to scroll to); the reply-highlight/scroll behavior for `created_post_id` is unchanged and shared by both paths.
- Verification:
  - `node --check` - no syntax errors; unit-checked the new condition's operator precedence in isolation (no row + a selection -> falls through to the content-post check; a row present -> short-circuits to `null` immediately; no selection at all -> `null`) - matches intent in all three cases.
  - Browser (Playwright), direct URL: `/forte?selected=<hidden thread>&created_post_id=<reply>#post-<reply>` - the hidden thread's content article is visible, the placeholder is hidden, no console errors.
  - Browser, full end-to-end: Activity item (hidden `identity_bootstrap`, item 226) -> content-summary dialog -> "View full thread" -> lands on the Forte board with that exact thread now visible and selected. No console errors anywhere in the flow.
  - Regression: a normal, board-visible thread (`root-001`) still gets its list row highlighted and scrolled into view on direct selection; a nonexistent id and no-selection-at-all both still show the placeholder exactly as before; clicking an ordinary row still selects it.
- Notes:
  - This closes the gap Stage 4 explicitly left open - the feature's end-to-end flow (Activity link -> in-place preview -> full thread, for board-visible and hidden content alike) is now fully working. Stage 6 is the final regression/integration pass across the whole feature.

## Stage 6 - End-to-end regression pass
- Changes: none - verification-only stage, as scoped.
- Verification (all via a real browser, Playwright):
  - All 5 non-commit activity views (`content`/`identity`/`bootstrap`/`approval`, plus `all` covered throughout earlier stages) - one representative item per view, clicking its content link opens the dialog with correct data, and "View full thread" lands on a correctly-selected, visible thread in the board. Covered both a root-post item and a reply item (approval view item 234: a reply into thread `bootstrap-20260915111820-50f698ae`) - the reply case confirms the thread's root is selected *and* the specific reply is highlighted via `created_post_id`, not just "some content is visible."
  - Commits view (Stage 3-era work, untouched by this feature): 100 commit rows still render, clicking one still opens its on-demand manifest correctly - confirms this feature's changes to the shared activity-item article template didn't regress the separate commit-row/detail code path.
  - Forte board's own profile-summary dialog (the pattern this feature's dialog was modeled on) still opens correctly from an author link inside a selected thread - confirms the new dialog didn't interfere with the existing one (distinct `data-role`/dialog-selector attributes throughout).
  - Classic `/posts/<id>`, `/threads/<id>`, `/activity/`, and RSS (`/activity/?format=rss`) - all still 200, all untouched by this feature (only Forte's own link-generation and board-selection logic changed).
  - Zero browser console errors across every scenario above.
- Notes:
  - No issues surfaced requiring code changes - the feature works end-to-end as specified in Step 2, across board-visible and hidden content, roots and replies, with no regressions to the Commits view, the profile-summary dialog, or the classic interface.

## Post-completion fixes (after "Approved Step 4" was requested)
- **Close on backdrop click; message-box styling.** User feedback: the content-summary dialog should close when clicking outside it, and should read as a plain message box (gray header, white body, "View full thread" in a gray footer) rather than the app's own blue-titlebar window chrome.
  - `paned_content_summary_dialog.php`: dropped the shared `.paned-new-thread-dialog` class (used by the app's other dialogs, which should keep their current look); restructured into three explicit zones - `.paned-content-summary-header`, `.paned-content-summary-body`, `.paned-content-summary-footer` (the "View full thread" link moved out of the content area into this new persistent footer, so it's available even during loading).
  - `forte.css`: new dedicated rules for the three zones (gray header/footer via `--paned-chrome-dark`, white body via `--paned-content-bg`) scoped entirely to `.paned-content-summary-dialog` - the profile-summary and new-thread dialogs are untouched.
  - `paned_activity_reader.js`: added a click listener on the dialog element itself, closing it when `event.target === dialog` (the standard way to detect a native `<dialog>`'s backdrop click, since the dialog's own box is sized to its content).
- Verification:
  - Browser (Playwright): header/body/footer computed background colors match the design (gray/white/gray); clicking inside the body leaves the dialog open; clicking the backdrop closes it; the existing close button still works.
  - Regression: the board's profile-summary dialog still opens with its original blue titlebar, unaffected.

- **Follow-up correction: message-box styling replaced with a closer match to the real interface, plus a real page-load bug fix.** User clarified with a reference screenshot (a classic Windows dialog: blue titlebar, plain gray body, an inset white preview box with margin on all sides, buttons in a plain gray footer) and specific corrections: metadata should live in the header area formatted like the main interface's own post header, the titlebar should be blue (not gray, undoing the prior fix's header-recoloring), only the post's own text should be white (not the whole body area), and that white area needs visible margin around it. They also caught a real bug: an empty, uninitialized dialog was appearing on every page load.
  - **Bug fix**: `.paned-content-summary-dialog` had an unconditional `display: flex` - since author-origin CSS always wins over the browser's own UA stylesheet regardless of selector specificity, this silently overrode the browser's default `dialog:not([open]) { display: none }`, so the closed dialog rendered inline on every page load instead of staying hidden. Fixed by moving `display: flex` onto `.paned-content-summary-dialog[open]` instead, so it only applies once the dialog is actually shown.
  - **Structure**: rebuilt the dialog's body as a miniature, literal clone of the main reader's own content pane - reusing `.paned-content-pane` (white, `margin: 0.5rem`, bordered - this *is* where the "margin all around" comes from) containing an `<article class="paned-content-post">` with `.paned-content-head`/`.paned-content-subject`/`.paned-content-meta` (gray, holding the post's title and Kind/From/Date/Replies) and `.post-card .body` (the actual post text, on white) - the exact same classes and DOM shape `paned_activity_detail_article.php` uses, not a lookalike. The dialog's own titlebar reverted to the shared `.paned-dialog-titlebar` (blue, matching every other dialog in the app) with a fixed "Post Preview" label; the footer (`.paned-content-summary-footer`, plain background, top border, "View full thread") sits below, unchanged in spirit from the prior fix.
  - `paned_activity_reader.js`: `showContentSummary()` updated for the new field locations (subject/kind/author/date/replies now populate the head/meta area instead of a single hidden/shown content block); the backdrop-click-to-close listener from the prior fix needed no changes.
- Verification:
  - Browser (Playwright): confirmed `getComputedStyle(dialog).display === "none"` on a fresh page load (the bug is gone); opened the dialog and confirmed each zone's actual background color (blue titlebar, gray content-head, white `.paned-content-pane`, `margin: 0.5rem` on the pane) plus a full-page screenshot showing the result reads as a coherent message box closely matching the reference image's layout.
  - Regression: hidden-content item (226) still shows correct data and its "View full thread" link still resolves to the right board thread; an unknown post id still shows the error state gracefully; the board's own profile-summary dialog is unaffected.