[lukemaj]

What: Remote delegated children stay hidden in ordinary web and mobile navigation, remain discoverable in existing search, and leave user-created forks visible.
Why: Client conversion dropped delegatedFrom, while several presentation consumers bypassed child classification or searched an already-filtered collection.
So what: This reviewed and verified component can merge into #379's integration branch; the broader outcome still needs its remaining components and one final approval PR.

Retain typed parent provenance in shared shells and apply visibility at the existing presentation owners. V2, Promachos, legacy, phone Home and mobile split-view preserve qualified identity, canonical stores, ordinary shelf/search ordering and inherited-provenance user forks. Nonempty search can find a child without its origin parent; clearing search hides it. Archived and local-subagent rows retain their exclusions. No new schema, settings, grants or authority behavior.

Refs #379 and #386. Approved user refinement, complete component handoff and metadata proof. The accepted phone search and alternate sidebar omissions are repaired. Fork metadata declares both carried upstream paths at the real upstream boundary, with one primary owner each; no glob, exemption or gate change. The map references PR #546 in this diff.

Candidate, review and proof

Target feat/379-cross-machine-parity, exact base b6d778b90409e337fcec9168c96b5c5330702055; head 57cf20e6be61f21734629bf25405afc267ed299b, tree 59ff4f0c81e7710c570aea0cd10401ce43bd315a. Cumulative 18 files, +897/-40. No package version bump under repository policy. No declared delivery-profile deltas. This internal component does not deploy or change the public website/SEO.

• Both independent complete current-source reviews pass: Sol MEDIUM, Opus 5.5 MEDIUM. Each read all 18 current files and actual consumers. Aggregate sets review/independent SUCCESS on exact head, freshly verified as created by the authenticated lukemaj account.
• Current GitHub CI passes all executed checks, including eight server shards, web tests, Build and Typecheck, Lint, Fork Stack Model, native fingerprints and Check. Explicitly skipped jobs are not claimed executed.
• Focused phone and alternate-sidebar regressions failed before repair. Functional proof reported 305 passing tests/7 files, three affected package compilers, two targeted React Compiler cases, scoped lint/format and canonical inventory. Both independent reviewers freshly ran the 305 tests and real-boundary fork check. Complete commands/results remain in their reports and component handoff.
• bash scripts/fork-check.sh --upstream upstream used true merge base d0918f1659f4c19172796c8d1910ca6e4bc18b51. No component-base substitution. Bestia's later reboot removed /tmp raw logs/manifests; those earlier results are reported historical evidence, not newly inspected reusable raw artifacts. GitHub CI and review records remain durable.
• Real primary-agent web and iOS phone acceptance: V2, Promachos and legacy default hiding preserve the ordinary task and user fork; web title search and legacy command palette find the child; native Home search/clear/re-hide and selecting the correct child pass. No provider prompt was submitted.
• Nine attached before/after and native screenshots. Uploaded with the installed gh pr comment --attach; all nine downloaded GitHub assets match the retained source SHA-256 digests. No Browser sign-in or vault credential was necessary. This corrects the earlier false access blocker.

Client proof used isolated projection-only fixture rows. It does not establish coherent backend/event history, linked-resource execution, runtime performance, tablet/Android or desktop-shell acceptance. Qualified native app compatibility was freshly checked; the only generated Mac source delta was a non-runtime declaration-file header comment. Full parent/#386 catalog, resource/third-hop/Run-group and #384/#385 work remain open. No existing user grant, live user-data operation, installed Chromeria restart, main merge or deployment.

Elon record

Requirements and who asked: User's #379 refinement requires default-hidden remote children discoverable offline; repository requires independent exact-candidate review, current CI and uploaded UI evidence.
Deleted: V2-only and split-view-only coverage, provenance-only classification, canonical-data filtering, fake lineage, new UI/schema/grants, allowlist globs/exemptions, approval transfer and the unnecessary Browser sign-in prerequisite.
Bottleneck: This component's review, CI and real client evidence are complete; remaining outcome work belongs to #379's other component owners and final cumulative proof.
Checked myself: Actual consumers and fork behavior; meaningful baseline failures and focused proof; exact current full independent reviews/creator; all current CI; real web/phone actions; installed CLI attachment help and nine uploaded binary digest matches.

Implemented by GPT-6.1 Sol / Codex / MEDIUM. Independently reviewed by GPT-6.1 Sol / Codex / MEDIUM and Claude Opus 5.5 / Claude Code / MEDIUM.

[lukemaj]

What: Parent review found that a user fork of a destination remote child would also be hidden from default navigation by546.
Why: Actual ThreadForkService spreads the source thread, retaining delegatedFrom, then sets local lineage to fork; the new predicate treats any delegatedFrom as a currently delegated child.
So what: The same546author must preserve ordinary fork visibility even when inherited remote provenance is present, add the missing regression and publish a new exact candidate. No server provenance or authority mutation is needed or granted.

Requirements and who asked: User-approved379refinement and this component's acceptance require ordinary user forks to remain visible while actual delegated children are hidden by default.
Deleted: Treating provenance presence as current relationship regardless of fork lineage, erasing server provenance to satisfy UI, expanding wire/schema/authority scope and claiming the existing no-provenance fork fixture covers this case.
Bottleneck: The shared predicate and sidebar classification must distinguish current fork lineage from inherited remote-delegation provenance.
Checked myself: Read complete54610-filediff and actual frozenbase ThreadForkService.ts84-103: targetThread spreads input.sourceProjection.thread and sets relationshipToParent='fork' without removing delegatedFrom. Current isThreadVisibleInNavigation normalquery rejects that actual shape. Existing mobile fork fixture creates a different raw shell without delegatedFrom, so286passingchecks miss this reachable case.

Reproduction path: delegate A->B, then use existing user fork on B's child; ThreadForkService preserves the remote source provenance while producing a normal fork. Shared shell conversion now correctly retains that provenance, and546classifies the user fork as hidden from normal web/desktop/mobile navigation (search can still reveal it). Required result: ordinary fork visibility remains unchanged. Preserve original delegatedFrom for existing authority/diagnostics; use the existing local fork relationship as appropriate in presentation. Keep actual delegated children, archived/local-subagent exclusions, qualified search and scope behavior intact.

Source pointers: packages/client-runtime/src/state/models.ts isThreadVisibleInNavigation; apps/web/src/components/Sidebar.logic.ts isSidebarSubagentThread; actual apps/server/src/orchestration-v2/ThreadForkService.ts84-103. Test the inherited-provenance fork shape in existing state/web/mobile proof and verify it remains visible both normally and through search, including offline parent. No server file edit or new UI concept is authorized by this finding. Parent531/539/384branches untouched.

[lukemaj]

What: PR546's fork regression is fixed and pushed at b2b7039742ff09214bca0e35f973c08256fca207.
Why: Actual user forks retain remote provenance but have current lineage fork; presentation now respects that relationship and avoids duplicate web search rows.
So what: Parent owns the current539gate/later cascade, fresh exact-candidate Sol/Opus review and real-client acceptance; worker stops clean with no topology/runtime actions.

Full superseding handoff with frozen base, final tree, commands/results/failures and unchecked surfaces: #386 (comment). Draft PR546 still targets feat/379-cross-machine-parity. Frozen component base 2b9443bae55bb712b6872c0ab75f92976fa2e870; final tree 7f36134403b35d5aff384c12f0f53b02712f4ea8.

Requirements and who asked: Parent's546finding and original ordinary-user-fork acceptance under379refinement.
Deleted: Treating inherited provenance as a current delegated relationship, erasing server provenance, no-provenance-only fork proof and duplicate fork search rows.
Bottleneck: Presentation classification at the existing shared/sidebar owners.
Checked myself: Real frozen ThreadForkService shape;3failed-before/285passed, then288passed across3focusedfiles; all3affectedcompilers exit0; scoped lint exit0 with3warnings; fmt/inventory/whitespace passed. Remote/local/GitHub heads match and workspace is clean.

No server/contracts/provenance/authority edits, independent review, borrowed approval, CI-green, merge/rebase/retarget or deployment claimed. Native386edges and other owner gaps remain. No product/dev server/browser/device/live-data/grant use.

GPT-6.1 Sol / MEDIUM / Codex.

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	5.0 KiB	—	6.8 KiB	✅
Codex	Thread snapshot wire	—	3.8 KiB	—	4.9 KiB	✅
Codex	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Codex	Live turn WebSocket decoded	—	20.9 KiB	—	29.3 KiB	✅
Codex	Live turn messages	—	2	—	8	✅
Claude	Total thread wire	—	5.0 KiB	—	6.8 KiB	✅
Claude	Thread snapshot wire	—	3.8 KiB	—	4.9 KiB	✅
Claude	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Claude	Live turn WebSocket decoded	—	21.2 KiB	—	29.3 KiB	✅
Claude	Live turn messages	—	2	—	8	✅

Baseline: unavailable · PR result: b2b7039 · Source CI: failure

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[lukemaj]

Independent review, round 1: REQUEST_CHANGES

What: Web/desktop and wide-screen mobile hide remote children and find them in search as intended, but on phones (any layout narrower than 720 px) a destination child can no longer be found at all.
Why: Phone layouts never render ThreadNavigationSidebar. They search through HomeScreen, which still reads the navigation atom this PR now narrows.
So what: The author routes HomeScreen search input the same way ThreadNavigationSidebar already does, then this head gets a fresh review. No human decision is needed.

Requirements and who asked: User refinement 3796268898682 (approved #379 v5) asks for remote children hidden by default and findable offline through existing search on web/desktop and mobile touch. Parent STOP 3866271148134 named mobile touch search as the at-risk consumer.
Deleted: Nothing proposed beyond routing one existing consumer's input. No new panel, setting, schema or server change.
Bottleneck: Mobile has two existing touch search consumers. This PR covers only the split-view one.
Checked myself: Read the full diff b6d778b..a8252e1 and traced the layout to the screen to the atom (details below). Reran the focused tests: 288/288 pass.

Finding 1 (required): phone search cannot find destination children

• Location: apps/mobile/src/features/home/HomeRouteScreen.tsx:48-51 feeds HomeScreen with environmentThreadShells.navigationThreadShellsAtom. apps/mobile/src/features/home/HomeScreen.tsx:306 runs content search, and :588-594 builds buildThreadListV2Items({ threads: props.threads.filter(archivedAt === null), searchQuery }) from that input.
• Trigger: A mobile layout without split view. apps/mobile/src/lib/layout.ts:108 requires width >= 720 && height >= 600 for split view. AdaptiveWorkspaceLayout.tsx:278/728 renders ThreadNavigationSidebar only when usesSplitView is true. Every phone gets WorkspaceRootScreen.tsx:144 -> HomeRouteScreen -> HomeScreen instead.
• Actual effect: threadShell.ts:403 now drops delegatedFrom non-fork shells from navigationThreadShellsAtom, so HomeScreen never receives them. On a phone, a destination child is hidden by default (intended), and a title or content search for it returns nothing (regression). Before this PR the child was at least listed. After it, the phone thread list has no path to the child at all. The new mobile test calls buildThreadListV2Items with a pre-filtered input that mirrors ThreadNavigationSidebar. No test covers the HomeScreen input.
• Requirement: Nonempty existing search must find a remote child, including an offline one, on mobile touch input, and clearing the query must hide it again (feat(peer): complete all-tool cross-machine workflows across web desktop and mobile #386, search-ownership extension 3866271171113).
• Smallest fix in the existing model: Do in HomeRouteScreen/HomeScreen what ThreadNavigationSidebar.tsx:139-143,368-370 already does. Read threadShellsAtom only while searchQuery.trim() is nonempty (keep useAtomValueWhileVisible), and filter with isThreadVisibleInNavigation(thread, searchQuery) in place of the archived-only filter. Keep computeThreadMoveAvailability on navigation input, as the sidebar does. The parent should confirm this file set as an owned seam before the edit, per the extension's "report additional source files first" rule.

Cleared concerns

• Web duplicates: searchableThreads appends filterSidebarV2VisibleThreads(threads, scope, query).filter(isSidebarSubagentThread). The shelves come from the empty-query filter (Sidebar.tsx:635), which excludes those rows, so the appended rows are disjoint from the shelves. Inherited-provenance forks stay on the shelves and are never appended. Whitespace queries append nothing. Project scope and usePersonViewThreads filtering carry over because the appended rows derive from the same threads.
• Search order and qualification: searchSidebarThreads keeps shelf order with title matches before content matches. Content matches use environment-qualified keys, and the tests cover equal bare IDs across environments.
• Fork provenance: The only server spread site is ThreadForkService.ts:84-93, which keeps delegatedFrom and sets relationshipToParent: "fork", so the fork stays visible. Orchestrator.ts:2564 stamps delegatedFrom only with linkOrigin. Ordinary linked-origin launches carry none and stay visible.
• Stores: threadShellsAtom, threadShellAtom and threadRefsAtom stay unfiltered and keep delegatedFrom (models.ts:255).
• Mobile sidebar hooks: The conditional atom inside one useAtomValue call is hook-safe. The full-list subscription exists only while searching.
• Other navigation-atom consumers (ThreadArrangementSheet, usePullRequestStack saved fallback, web project sort Sidebar.logic.ts:1344) now treat remote children the same as local subagents in default navigation. This matches the approved boundary and is not a finding.

Proof

• Executed (this reviewer, frozen tree): npm exec --yes --package=node@24.13.1 --package=pnpm@11.10.0 -- pnpm exec vp test run packages/client-runtime/src/state/threadShell.test.ts apps/web/src/components/Sidebar.logic.test.ts apps/mobile/src/features/threads/threadListV2.test.ts gives 3 files, 288 passed.
• Reused, not rerun: the parent's compiler, lint, format and inventory logs in /tmp/chromeria-546-b6-*.
• Unverified: no real client run (web, desktop, phone or tablet), no CI, no browser or DOM run. The finding comes from a source trace, not a device observation.
• Candidate: base b6d778b90409e337fcec9168c96b5c5330702055, head a8252e1eeb4956840485d92edc9d3ebea4d39ad3, tree 918cc2bf12710978bda5bd4ddc1aa7ef08ad7961. The review tree is clean and unchanged.
• Reviewer: Claude Code, claudeAgent / claude-opus-5-5, effort medium (checked with t3_thread_configuration).

This review alone is not an aggregate status and makes no merge or readiness claim.

[lukemaj]

What: REQUEST_CHANGES on PR #546 at a8252e1eeb4956840485d92edc9d3ebea4d39ad3: existing alternate web/desktop sidebars still display destination remote children without a search query.
Why: The new rule reaches Sidebar V2 and mobile navigation, but Promachos and legacy sidebars consume canonical shells directly and bypass it.
So what: The parent should assign the finite existing-consumer correction and obtain review of the resulting candidate; this report makes no aggregate status, merge, shipment or whole-#386 completion claim.

Requirements and who asked: User3796268898682 and this review brief require default-hidden destination delegated children, offline existing-search findability, ordinary fork visibility and whole-component consumer coverage.
Deleted: Approval transfer from #539, provenance erasure, filtering canonical stores, new modes/settings/panels/grants, unrelated #386 requirements, source repair and broad checks.
Bottleneck: The presentation rule is not applied by every existing normal sidebar selected by AppSidebarLayout.
Checked myself: Persisted reviewer selection, exact Git/live PR identity, all 10 component files, shared state and actual sidebar/search/selection consumers, real fork-service spread/override, pinned atom React subscription implementation, prior complete records, manifest hashes, 288 fresh focused passes, the Sidebar React Compiler case and a fresh failing alternate-sidebar probe.

Exact candidate and independence

• Base: b6d778b90409e337fcec9168c96b5c5330702055.
• HEAD: a8252e1eeb4956840485d92edc9d3ebea4d39ad3.
• Tree: 918cc2bf12710978bda5bd4ddc1aa7ef08ad7961.
• Reviewed the whole 10-file, +316/-17 component, not only the fork correction. Live PR head/base and changed-file list match. Base-to-head divergence is 0/3.
• Exclusive detached tree: /home/luke/dev/toolboxmd/chromeria-worktrees/379-review-539-sol; clean before and after, tracked source/index/HEAD/tree unchanged. No topology operation.
• t3_thread_configuration reports instance codex, model gpt-6.1-sol, reasoningEffort=medium; Codex harness, independent of the author, no fallback or subdelegation.
• Read canonical operations, verification, code-review, full review-method/impact-analysis, applicable diagnosis/test-design/empirical guidance, repo instructions, triad/glossaries and Great Library README. Read current PR body and complete diff, original feat(peer): complete all-tool cross-machine workflows across web desktop and mobile #386 body, spec: native cross-machine control across linked environments #379 v5/Design Review/current refinement, initial STOP/search-ownership grant, both complete author handoffs and parent fork finding, plus the specified fix(peer): preserve current-main request answering policy #539 review/readiness/aggregate and test(prism): measure recovery coalescing after live observation starts #537 absorption records. These are evidence inputs, not transferred approval or authority.

Required correction

P2: Apply default hiding to the existing alternate sidebar consumers

Locations: apps/web/src/components/promachos/promachosConversations.ts:65-67, apps/web/src/components/LegacySidebar.tsx:1159-1161 and 3182-3186; reached by apps/web/src/components/AppSidebarLayout.tsx:353-358. The new rule at packages/client-runtime/src/state/models.ts:198-213 is bypassed by these consumers.

Trigger and reachable path: Delegate work to a destination project included in the configured Promachos home, then switch to Promachos mode. PromachosConversationList reads useThreadShells(), applies the existing person view, and calls promachosConversations; that function checks home, archive and local subagent lineage only. A real remote delegated child has retained delegatedFrom and no fabricated local subagent lineage, so it appears as a normal conversation with no query. Independently, enable the existing “Sidebar (legacy)” setting and expand the destination project: useProjectThreads reads the unfiltered project-shell store and filters archive only, and its rendered/jump-key path also filters archive only.

Actual effect versus requirement: The child is hidden in V2/mobile but remains in the destination's ordinary sidebar in these existing web/desktop modes. This is the same default-hiding requirement and existing-consumer coverage, not a request for unfinished parent labels, third-hop navigation or another #386 slice. Preserve canonical all-shell/project/reference stores and qualified routing; apply the presentation policy at these existing owners while preserving permitted discovery and inherited-provenance user forks. The parent may need to extend the author's finite file grant to those owners.

Independent evidence: A disposable test invoked the actual presentThreadShell and promachosConversations with an ordinary home conversation plus a destination remote child whose parent environment was absent. The new shared predicate returned false for the child, and the ordinary-conversation positive control passed, but the actual alternate-sidebar list returned both IDs. The independent requirement assertion failed: expected [ 'thread-v2', 'remote-child' ] to not include 'remote-child'. No product or mocked component markup was involved. Probe retained outside tracked source as /tmp/sol546-alternate-sidebar-probe.test.ts, log /tmp/sol546-alternate-sidebar-probe.log; temporary in-tree test removed. The legacy path is source-confirmed, not client-executed.

Cleared paths and bounded impact

• Original typed delegatedFrom is retained verbatim during shared conversion. All-shell, per-project, reference and qualified single-thread stores remain unfiltered; equal bare thread IDs across environments remain distinct.
• V2 appends only eligible hidden remote children to the existing shelf-derived search input, preserving ordinary shelf search ordering and avoiding duplicate inherited-provenance forks. Existing person/project scope, archive/local-child exclusions, content-match keys and qualified selection remain in their owners.
• Mobile's hook is called unconditionally with one of two stable atom identities. The installed @effect/atom-react implementation keys stores by registry/atom, uses useSyncExternalStore, and unsubscribes its prior store. Clearing/whitespace query selects navigation input again; the all-shell subscription is needed only during nonempty search. The pre-existing navigation subscription still serves ordering/inbox observations. No supported hook-order or persistent all-shell subscription defect found by source inspection; this is not measured device performance proof.
• Verified the mandatory fork regression against actual ThreadForkServiceV2.plan: it spreads the source and overrides lineage to fork, retaining provenance. Shared/web/mobile now preserve ordinary fork visibility and provenance, and V2 excludes that fork from the appended-child set. Backend provenance/authority remain unchanged, including lower fix(peer): preserve current-main request answering policy #539 policy consumers.
• Web/desktop search selection and both mobile Home/adaptive-layout routes retain environment plus thread identity. Existing command palettes independently retain canonical nonarchived data and qualified navigation. Settings supplies the reachable legacy-sidebar entry described above. No new wire schema, server, grant or provider behavior appears in this diff.

Proof executed, reused and unverified

All fresh runner commands used npm exec --yes --package=node@24.13.1 --package=pnpm@11.10.0 -- pnpm exec with the copied dependencies and no install.

Fresh:

1. vp test run packages/client-runtime/src/state/threadShell.test.ts apps/web/src/components/Sidebar.logic.test.ts apps/mobile/src/features/threads/threadListV2.test.ts: 288 passed, 3 files, exit 0, 3.25s.
2. vp test run apps/web/src/reactCompilerCoverage.test.ts -t 'compiles apps/web/src/components/Sidebar.tsx': 1 passed, 1093 filtered, exit 0.
3. vp test run apps/web/src/.review-546-destination.test.ts: 1 intended assertion failure, exit 1, as quoted above. Initial probe placement at repo root failed package resolution with zero tests; moving the same disposable probe under the web package resolved setup and produced the behavioral failure. Neither setup failure nor a nonexistent path search is counted as product evidence.
4. git diff --check base HEAD: pass; final status empty and identity unchanged. Live PR identity/file list rechecked; PR546 app-link confirmed, watching=false.

Reused after inspection: Parent manifest /tmp/chromeria-546-b6-proof.json hashes to 0e7177c9aa9c24c8163f0e6b1e6834907294ed99d81710bacf19455876689654; all 10 source and 8 log hashes match. Inspected the retained focused output, all three affected package compiler logs, scoped lint warnings, 10-file formatting and 52-feature inventory outputs. These are parent executions, not fresh reviewer compiler/lint runs or a complete gate. Original/fork failing-before reports retain their historical identities.

Unverified here: Current complete CI/admission, actual isolated web/desktop/mobile interactions and images, reconnect/client acceptance, native device performance, actual harness/machine/parent labels and the remaining #386 catalog/resources/third-hop/Run-group work. Those remain parent-owned; this request for changes does not depend on their incompleteness. No product/dev server, browser panel, device, provider prompt, live data/grant, installed Chromeria restart, dependency install, commit/push or merge/deploy occurred. No aggregate or review/independent status was written.

This full findings comment is the only task forge mutation. Reviewed by Codex / GPT-6.1 Sol / MEDIUM.

[lukemaj]

What: All three accepted missing-consumer findings are repaired together in draft PR546, pushed at 301b232f2a1446e1d0a69e86e097839b6bf49a8b.
Why: Phone Home searched filtered navigation input, while Promachos and legacy default lists bypassed the shared policy; earlier288passes did not cover these paths.
So what: Parent obtains BOTH fresh full Sol/Opus reviews and CI on this candidate, then owns actual client acceptance/integration. Worker stops clean; no review success or merge claim.

Current canonical386handoff: #386 (comment). Exact base b6d778b90409e337fcec9168c96b5c5330702055; final tree cbff62dc252652ae59621fdd757f438f57b97f50. Forward commit from parent-prepareda825; no topology operation. App linking and live PR head/base verified.

Requirements and who asked: User3796268898682 and parent-accepted Opus6272457840/Sol6272512045 findings with finite phone/alternate consumer ownership.
Deleted: Split-view-only phone proof, V2-only mode coverage, fake lineage/data filtering/new UX/grants, provenance-only fork hiding and prior-review approval transfer.
Bottleneck: Three bypassed existing consumer inputs/classifiers.
Checked myself: Baseline phone and alternate-list failures; final305focusedpasses in7files,3passing package compilers,2targetedReactCompilerpasses, lint exit0/13warnings,17filefmt,52featureinventory/whitespace pass. Manifest /tmp/chromeria-546-consumers-proof.json SHA256 7b38eeabfaf4db165e3d6a2648316f748e95217fc69e12f2778f96656da5d14f binds source/log hashes.

Phone tests mount the real route/screen and retain actual store/list/move logic with native UI/service boundaries mocked; tests exercise title/content/clear, qualified offline selection, visibility suspension/reveal, default update stability and navigation-only movement. Legacy render/jump lists share the tested selector; Promachos filtering and inherited-provenance forks are covered. Actual native/web/desktop interactions, screenshots, reconnect, runtime performance and real harness/machine/parent labels remain unverified. No product server/browser/device/live data/grants/subdelegation, other-workspace writes, aggregate status, merge or deployment. Native386edges and other owner gaps remain.

GPT-6.1 Sol / MEDIUM / Codex.

[lukemaj]

Independent review, round 2: APPROVE

What: At 301b232f2a1446e1d0a69e86e097839b6bf49a8b, phone Home search, Promachos and the legacy sidebar now apply the same remote-child policy as Sidebar V2 and split-view mobile, so I approve this head.
Why: Both round-1 findings (Opus phone input 6272457840, Sol alternate sidebars 6272512045) are fixed at their owning consumers. The fix uses the shared isThreadVisibleInNavigation predicate. No canonical store was narrowed and no provenance was erased.
So what: The parent still needs the second required review, current CI and real-client acceptance on this head. This comment is not an aggregate status and makes no merge or readiness claim.

Requirements and who asked: User refinement 3796268898682 (approved #379 v5) and #386 ask for remote children hidden by default in every existing ordinary sidebar, findable offline through existing search on web/desktop and mobile touch, hidden again when the query clears, with user forks visible and qualified identity kept.
Deleted: Nothing further to propose. No new panel, setting, schema, server change, inline Promachos search or store filtering is needed.
Bottleneck: None left in this component. The remaining gate is real-client acceptance, which the parent owns.
Checked myself: Read the full 17-file diff base..HEAD and the round-2 delta a8252e1..301b232. Traced every web/mobile useThreadShells/threadShellsAtom list consumer that renders a sidebar list. Reran the 7 focused files: 305/305 pass. Inspected the mocks in the phone regression and the retained red logs.

Candidate

• Base b6d778b90409e337fcec9168c96b5c5330702055, head 301b232f2a1446e1d0a69e86e097839b6bf49a8b, tree cbff62dc252652ae59621fdd757f438f57b97f50. 17 files, +894/-39. The live PR head and base match. The PR is OPEN and DRAFT.

Prior findings

1. Phone search cannot find destination children (Opus, round 1): cleared.
   • HomeRouteScreen.tsx:61-66 selects threadShellsAtom only while searchQuery.trim() is nonempty, and navigationThreadShellsAtom otherwise. Both reads keep useAtomValueWhileVisible(…, visible). Hook order is stable: one call with one of two atom identities, as in ThreadNavigationSidebar.
   • HomeScreen.tsx:593 filters list input with isThreadVisibleInNavigation(thread, props.searchQuery). Search keeps archive and local-subagent exclusion and admits delegatedFrom children only for a nonempty trimmed query. Clearing the query switches back to navigation input.
   • Move availability (:555,561) and inbox observation (:589) now use navigationThreads, so reorder and inbox behavior during search match default navigation.
   • Content-match keys and selection stay environment-qualified.
   • The regression HomeRouteScreen.search.test.tsx mounts the real HomeRouteScreen/HomeScreen with real createEnvironmentThreadShellAtoms, the shared predicate and the real buildThreadListV2Items. Only native plumbing, service boundaries and the row renderer are mocked. It is a behavior test, not static markup. It covers title search, same-bare-ID qualified content selection, clear rehiding, the visibility guard, local-child exclusion with full input, navigation-based move availability, and no rebuild on hidden-child updates in default navigation. The retained /tmp/remote-child-phone-red.log shows 2 of 3 failing before the fix.
2. Alternate web/desktop sidebars show destination children (Sol, round 1): cleared.
   • Promachos: PromachosSidebar.tsx:138-141 → promachosConversations.ts:65 now applies the shared predicate after qualified home membership. The previous archive and subagent checks are subsumed. Promachos has no inline query; discovery stays in the existing command palette, which reads canonical shells. The test covers a hidden child, a user fork that inherits provenance (visible on both home machines), and archive and local-child exclusion.
   • Legacy: legacySidebarVisibleThreads (LegacySidebar.tsx:1111) now feeds both rendered project rows (useProjectThreads, :1172) and the visible-key list used for traversal, numeric jumps and prewarming (useLegacySidebarThreads, :3193). Render and jump lists therefore cannot diverge. The test drives that real selector and real buildThreadActionItems, then confirms the hidden child is found and selected as [destination, child.id]. The retained /tmp/remote-child-alternate-red.log shows 2 failures before the fix.

Whole-component checks (unchanged from round 1, rechecked on this head)

• models.ts:198-213 keeps the typed delegatedFrom. The fork exception covers the real ThreadForkService spread, which keeps delegatedFrom and sets relationshipToParent: "fork". Canonical all-shell, project, ref and single-thread atoms stay unfiltered. Only navigationThreadShellsAtom (threadShell.ts:397-410) filters.
• Sidebar V2 appends only eligible hidden children to search, so there are no shelf duplicates and order is kept. Split-view ThreadNavigationSidebar is unchanged since round 1.

Non-blocking observations (no change requested)

• LegacySidebar.tsx:3119-3120 project activity sort still counts every non-archived shell, including remote children. Local subagents already counted there before this PR, and only project order is affected, not row visibility.
• HomeScreen.tsx:920 hasAnyThreads reads props.threads, which during phone search is the full shell list. The only visible effect would be an empty-results list instead of the empty state when the only nonarchived shells are hidden children. That is an edge case and does not affect findability.

Proof

• Executed (this reviewer, frozen tree): npm exec --yes --package=node@24.13.1 --package=pnpm@11.10.0 -- pnpm exec vp test run on the 7 files threadShell.test.ts, Sidebar.logic.test.ts, threadListV2.test.ts, HomeRouteScreen.search.test.tsx, home-route-visibility.test.tsx, LegacySidebar.test.ts and promachosConversations.test.ts: 7 files, 305 passed, exit 0. gh pr view identity check.
• Reused, not rerun: the parent's package compilers, the targeted React Compiler cases, lint, fmt, inventory and the red logs. The manifest /tmp/chromeria-546-consumers-proof.json has sha256 7b38eeabfaf4db165e3d6a2648316f748e95217fc69e12f2778f96656da5d14f. I did not rehash every bound file.
• Unverified: CI, any real web/desktop/phone/tablet client run, device subscription performance, and red-before tests rerun by me (I made no source writes to reproduce them).
• The review tree is clean and unchanged. No servers, browsers, devices or other processes were started.
• Reviewer: Claude Code, claudeAgent / claude-opus-5-5, effort medium (checked with t3_thread_configuration).

[lukemaj]

Independent review, round 2 addendum: verdict limited to 301 with the Fork Stack CI failure still open

What: My round-2 behavior APPROVE (#546 (comment)) applies only to 301b232f2a1446e1d0a69e86e097839b6bf49a8b. The Fork Stack CI failure on that head is real and still open.
Why: scripts/fork-upstream-edits.txt does not list two upstream files this PR now edits: apps/mobile/src/features/home/HomeRouteScreen.tsx and apps/web/src/components/LegacySidebar.tsx.
So what: The author adds those two lines (metadata only). The parent then requests a fresh review round on that exact new candidate. This approval does not carry over to the new head.

Requirements and who asked: The fork's carried-upstream-edit gate requires every edited upstream file to be declared with one owner in docs/fork-features.md. The parent reported the CI failure on 301.
Deleted: No re-investigation beyond the declaration owner. No behavior change requested.
Bottleneck: The allowlist declaration, not product behavior.
Checked myself: In the frozen 301 tree, I checked each of the 17 changed files that existed at base against scripts/fork-upstream-edits.txt. Only HomeRouteScreen.tsx and LegacySidebar.tsx are both missing from the list and present in an upstream ref (refs/remotes/issue411-upstream-observe/3ff5b3c82a62). promachosConversations.ts and its test are fork-only, and the docs/ files are fork docs. The peer-links entry in docs/fork-features.md already lists both missing files under upstreamFiles, so the ownership claim exists and only the allowlist line is missing.

Finding (required, metadata only)

• Location: scripts/fork-upstream-edits.txt (no entries for the two paths above).
• Trigger: Fork Stack CI on 301.
• Effect: CI is red. Runtime behavior is not affected.
• Author response (reported by the parent): The original author is adding the two paths to scripts/fork-upstream-edits.txt only, in the author workspace. I have not seen the repair, and it stays unresolved until a fresh review of the new head.

Verdict

• Behavior review of the whole 17-file component at 301: APPROVE, unchanged.
• Overall for 301: not mergeable while Fork Stack CI is red.
• No approval transfers to any later head.

Base b6d778b90409e337fcec9168c96b5c5330702055, head 301b232f2a1446e1d0a69e86e097839b6bf49a8b, tree cbff62dc252652ae59621fdd757f438f57b97f50. The review tree is clean and unchanged.

Reviewer: Claude Code, claudeAgent / claude-opus-5-5, effort medium.

[lukemaj]

What: Fork Stack CI on 301b232f2a1446e1d0a69e86e097839b6bf49a8b failed because two newly edited upstream files are missing from the carried-edit declarations.
Why: The component inventory assigns both files to peer-links, but scripts/fork-upstream-edits.txt does not yet list apps/mobile/src/features/home/HomeRouteScreen.tsx and apps/web/src/components/LegacySidebar.tsx.
So what: The original author is adding only those two exact declarations, running the real fork/upstream gate, and publishing a new candidate for both required fresh reviews and CI; this head remains held.

Requirements and who asked: The repository's existing fork-stack policy requires declared ownership for every carried upstream edit; approved #379/#386 requires these exact existing consumer repairs.
Deleted: Broad globs, gate exemptions, changes to the gate, removing the behavior fixes, and treating the direct feature inventory as the complete fork-stack gate.
Bottleneck: Two omitted declarations, with no new product decision.
Checked myself: Read the actual failed job log from run39290858595/job118190817168, failures at retained log lines244/829 and final1214; checked both source changes and existing peer-links ownership, then sent the exact metadata repair to the original Sol MEDIUM author (same task continuation ordinal5).

Retained raw log /tmp/chromeria-546-301-fork-ci.log; CI uses real upstream merge-base d0918f1659f4c19172796c8d1910ca6e4bc18b51, not the component integration base. The direct 52-feature inventory pass did not establish this separate carried-edit check. The next validation must run the actual bash scripts/fork-check.sh --upstream upstream boundary with matching upstream history, without changing the gate.

The whole-component Opus round2 behavior review cleared prior consumer findings at301. Its addendum independently confirms the declaration failure is real and required. Aggregate review/independent is FAILURE on301; no approval transfers to the next head, and both fresh whole-component Sol/Opus reviews remain required. The author exclusively owns the repair; parent has not written the branch or merged it.

Correction: the new upstream consumer owners were registered in the feature inventory but omitted from the accompanying carried-edit list. Existing fork checks already enforce this, so the fix belongs in the component declarations and actual proof, not another global rule.

[lukemaj]

What: PR546's exact carried-edit declarations are repaired at pushed 57cf20e6be61f21734629bf25405afc267ed299b, with actual correct-boundary Fork Stack admission passing locally.
Why: Direct52-feature inventory validation missed two upstream edits; both paths needed exact allowlisting and primary upstream ownership rather than only shared-file registration.
So what: Parent obtains BOTH fresh whole-component reviews and CI for this18-file candidate. Worker stops clean; no frozen301review or earlier proof is claimed as approval.

Canonical386handoff with exact errors, boundary, commands/logs and proof limits: #386 (comment). PR546 remains draft into integrationb6d778b90409e337fcec9168c96b5c5330702055. Final tree 59ff4f0c81e7710c570aea0cd10401ce43bd315a; cumulative18files,+897/-40.

Requirements and who asked: Parent's finite CI metadata repair for approved379/386consumer changes.
Deleted: Globs, broad exemptions, checker relaxation, source/test refactoring, wrongb6forkboundary and approval transfer.
Bottleneck: Two exact missing carried-edit declarations and their peer-links primary-owner field.
Checked myself: Raw CI lines244/829/1214, validator owner rule, matching local failure; actual bash scripts/fork-check.sh --upstream upstream exit0on57cfusing legitimate mergebased0918f1659f4c19172796c8d1910ca6e4bc18b51. Fresh inventory52/fmt/whitespace pass; all16unchanged prior file hashes and9proof log hashes verified.

Only scripts/fork-upstream-edits.txt and docs/fork-features.md changed from301,+5/-3. Prior305tests/3compilers/2ReactCompiler results are preserved/reused, not rerun. Metadata manifest /tmp/chromeria-546-metadata-proof.json SHA256 76c7bcbc7f7056920dbf2a632ddf39e048ff8c3a44f1f4dcfb051e028013019f. No source/tests, topology, servers/devices, live data/grants, subdelegation, review status success, CI-green, merge or deployment. Native386edges and actual client acceptance remain parent-owned and unfinished.

GPT-6.1 Sol / MEDIUM / Codex.

[lukemaj]

Independent review, round 3: APPROVE

What: I approve the whole 18-file component at 57cf20e6be61f21734629bf25405afc267ed299b. The only change since 301 is the two carried-edit declarations, and the real fork check now passes.
Why: The round-2 metadata finding is fixed with two exact allowlist lines and a single upstream owner (peer-links) for each file. No gate was weakened, and behavior and test files are byte-identical to the 301 head I approved in round 2.
So what: The parent still needs the fresh Sol review, current CI and real-client acceptance on this head. This comment is not an aggregate status and makes no merge or readiness claim.

Requirements and who asked: User refinement 3796268898682 (#379 v5) and #386 set the behavior. The fork-stack policy requires every carried upstream edit to be allowlisted with exactly one owner. The parent reported the Fork Stack failure on 301.
Deleted: Nothing further to propose. No globs, exemptions or gate changes are needed.
Bottleneck: None left in this component. Sol review, CI and real-client acceptance belong to the parent.
Checked myself: Exact identity, the 301..57cf delta, ownership uniqueness, a fresh fork-check at the true upstream boundary, 305 fresh focused tests and the reuse hashes.

Candidate

Base b6d778b90409e337fcec9168c96b5c5330702055, head 57cf20e6be61f21734629bf25405afc267ed299b, tree 59ff4f0c81e7710c570aea0cd10401ce43bd315a, 18 files, +897/-40. The live PR head and base match. The PR is OPEN and DRAFT.

Prior findings

1. Phone Home search (Opus r1 6272457840): cleared in round 2 at 301 and unchanged here. HomeRouteScreen.tsx and HomeScreen.tsx are hash-identical to 301.
2. Promachos and legacy sidebars (Sol r1 6272512045): cleared in round 2 and unchanged here (hash-identical).
3. Missing carried-edit declarations (Opus r2 addendum 6272812661): cleared.
   • scripts/fork-upstream-edits.txt adds only the literal lines apps/mobile/src/features/home/HomeRouteScreen.tsx and apps/web/src/components/LegacySidebar.tsx, under the existing Peer links section.
   • docs/fork-features.md moves those same two paths from sharedFiles to upstreamFiles in peer-links. Each path now appears exactly once in the inventory.
   • HomeScreen.tsx keeps its existing primary owner no-project-sidebar, with peer-links as a shared consumer. That is unchanged.
   • No checker or validator code changed.
4. Round-2 non-blocking observations (legacy project activity sort counts hidden children, phone hasAnyThreads during search): still apply, still no change requested.

The behavior assessment from round 2 (shared predicate, unfiltered canonical stores, inherited-provenance fork visibility, V2 non-duplicating search append, qualified identity, phone subscription and movement input) carries over because those 16 files are byte-identical. I verified this by hash, not by re-reading every line.

Proof

• Fresh (this reviewer, frozen tree):
  • bash scripts/fork-check.sh --upstream upstream: exit 0, boundary d0918f1659 (equals git merge-base HEAD upstream/main, upstream/main=e704190e8c), 196 stack commits, fork-check: OK.. Log /tmp/opus546-r3-fork-check.log.
  • vp test run on the same 7 focused files: 7 files, 305 passed.
  • node scripts/fork-features.mjs check: OK, 52 features.
  • git diff --check base HEAD: pass.
  • git diff --name-only 301b232..57cf20e: only the 2 metadata files.
• Hash-verified reuse: /tmp/chromeria-546-metadata-proof.json sha256 76c7bcbc…019f and /tmp/chromeria-546-consumers-proof.json sha256 7b38eeab…d14f match the brief. The 16 prior source hashes match the current tree. Only docs/fork-features.md differs, as intended, and both metadata file hashes match the new manifest. The parent's package compilers, React Compiler cases and lint are reused from 301 and were not rerun.
• Unverified: GitHub CI on 57cf, any real web/desktop/phone/tablet client run, device performance.
• The review tree is clean and unchanged. No servers, browsers, devices or lingering processes.
• Reviewer: Claude Code, claudeAgent / claude-opus-5-5, effort medium (checked with t3_thread_configuration).

[lukemaj]

What: APPROVE PR #546 at 57cf20e6be61f21734629bf25405afc267ed299b: this fresh independent review of the whole 18-file component found no supported actionable defect.
Why: Actual navigation/search consumers implement the required distinction between destination children and inherited-provenance user forks, and the two exact carried-edit declarations now have valid primary ownership without changing the gate.
So what: The parent owns aggregate review status, current CI, real-client evidence/acceptance and integration; this comment makes no readiness, merge or whole-#386 completion claim.

Requirements and who asked: User refinement 3796268898682, approved #379/#386 and this explicit review assignment require default-hidden destination children, offline-parent discovery through existing search, clear-to-hide behavior, preserved canonical data/provenance and qualified identity across existing clients and sidebar modes. Fork policy requires exact carried-edit declarations and one primary owner.
Deleted: Approval transfer from #539, 301 or Opus; metadata-only review; filtering canonical stores; provenance/authority erasure; new UI/settings/schema/grants; unrelated #386 expansion; source repair, broad checks and product/live-system operations.
Bottleneck: Independently verify the full current consumer behavior and true-boundary admission, then return the verdict to the parent.
Checked myself: Persisted selection, exact frozen/live identity, every cumulative diff file, actual shared/web/mobile consumers and fork producer, prior findings/responses, pinned subscription implementation, both manifests and all bound log hashes, 305 fresh focused passes, fresh true-boundary fork check, inventory ownership and final cleanliness.

Identity and independence

• Base: b6d778b90409e337fcec9168c96b5c5330702055.
• HEAD: 57cf20e6be61f21734629bf25405afc267ed299b.
• Tree: 59ff4f0c81e7710c570aea0cd10401ce43bd315a.
• All 18 files, +897/-40, reviewed from base to HEAD, with actual surrounding consumers read independently. This is a whole-component review, not a relay of the prior Opus verdict or a review limited to the latest two files.
• Exclusive workspace: /home/luke/dev/toolboxmd/chromeria-worktrees/379-review-539-grok. Detached, clean before and after, divergence from component base 0/5; HEAD/tree/source/index unchanged. Other workspaces were not touched.
• t3_thread_configuration confirms instance codex, model gpt-6.1-sol, reasoningEffort medium, through the Codex harness. No fallback or subdelegation.
• Live PR head/base match; OPEN/DRAFT. PR fix(client): hide remote children from default navigation #546 is app-linked and unwatched.

Read the full supplied historical packet, applicable operations/review/impact/verification/diagnosis guidance, project direction/glossary and Great Library README. Also read the current full PR and original #386 body, the original user refinement, STOP/search-owner extension, original/corrected handoffs and parent fork finding, plus the named lower-#539 review/readiness/aggregate and #537 absorption records. Historical verdicts remain historical.

Prior findings adjudicated on this head

1. Phone Home search, r1 6272457840: cleared. Phone layout reaches WorkspaceRootScreen -> HomeRouteScreen -> HomeScreen; split view separately renders ThreadNavigationSidebar. HomeRouteScreen.tsx:61-66 selects full shells only for nonempty trimmed search while retaining useAtomValueWhileVisible. HomeScreen.tsx:593-596 applies the shared predicate before the actual list builder. Navigation shells independently feed move availability and inbox observations. The mounted regression uses the real route, HomeScreen, registry, conversion, atoms, list builder and movement calculation; it observes title/content rows, qualified identities, clear rehiding, covered/revealed updates and no default-list rebuild for hidden-child updates. Native leaves and search/navigation service boundaries are mocked, so this is not native-stack or live search-RPC proof.

2. Promachos and legacy sidebars, r1 6272512045: cleared. The actual mode branches remain reachable in AppSidebarLayout.tsx:353-358. PromachosSidebar feeds person-view canonical shells into qualified home membership and promachosConversations.ts:65, which applies shared visibility and preserves activity ordering. Its existing command palette remains canonical discovery; no inline search exists here. LegacySidebar.tsx:1111 supplies one visibility/sort selector to both project rendering at :1172 and visible keys at :3193, which feed traversal, numeric jumps and prewarming. Existing palette actions still receive full shells and select environment plus thread. The actual selector/palette and Promachos regressions pass, including inherited-provenance forks and archive/local-child exclusions.

3. Missing declarations, r2 addendum 6272812661: cleared. The 301..57 delta is exactly docs/fork-features.md and scripts/fork-upstream-edits.txt. The allowlist adds only literal HomeRouteScreen and LegacySidebar paths. Each has exactly one upstreamFiles owner, peer-links, and neither remains a shared entry there. HomeScreen retains primary owner no-project-sidebar and shared consumer peer-links. Checker/validator source is unchanged. Fresh actual fork admission passes at the real upstream merge boundary, not the component base.

The prior nonblocking observations remain nonblocking: legacy project activity ordering can count hidden children, as it already counted local children; phone empty-state selection during search can observe full-shell presence. Neither exposes a default child row or blocks required discovery.

Whole-component behavior and coverage

• Shared models.ts retains the original typed delegatedFrom object. threadShell.ts narrows only navigation: all-shell, qualified single-thread, project and reference atoms remain canonical and unfiltered. Equal bare IDs in different environments remain distinct.
• Read the actual ThreadForkService.ts:84-103: it spreads the source, retains provenance and overrides lineage to fork. The shared predicate and web classifier recognize this reachable shape. Ordinary linked-origin work stays visible; actual remote children hide by default; archives and local subagents remain excluded even during search.
• Sidebar V2 builds ordinary shelves with empty-query policy, then appends only eligible remote child rows for nonempty search. Forks already in shelves cannot be appended again. Person/project scope, shelf ordering, title-before-content matching, qualified content keys and selection remain with their existing owners. Whitespace/clear removes the extra child input.
• Split-view mobile uses the same query-selected full/navigation atoms and shared visibility before existing environment/project/title/content filtering. Phone and split-view movement/inbox inputs remain navigation-based. The installed @effect/atom-react 4.0.5 uses registry/atom-keyed stores and useSyncExternalStore cleanup; the conditional atom argument does not change hook order. This source evidence and mounted phone tests are not measured native performance proof.
• Inspected existing web/desktop settings mode selection, palettes, jump paths and qualified route construction, plus mobile Home/adaptive-layout and iOS/Android selection owners. The diff changes no server, wire contract, provider, grant, permission or execution-authority behavior. Lower fix(peer): preserve current-main request answering policy #539 policy remains intact.
• Reviewed all changed tests and the inventory/map edits, including the new phone and legacy tests, Promachos tests, shared state tests, V2 search tests and destination-discovery map reference. No unrelated source or PR-only assets appear.

Proof

Fresh, executed here:

1. Prefix npm exec --yes --package=node@24.13.1 --package=pnpm@11.10.0 -- pnpm exec, then:
   vp test run packages/client-runtime/src/state/threadShell.test.ts apps/web/src/components/Sidebar.logic.test.ts apps/mobile/src/features/threads/threadListV2.test.ts apps/mobile/src/features/home/HomeRouteScreen.search.test.tsx apps/mobile/src/features/home/home-route-visibility.test.tsx apps/web/src/components/LegacySidebar.test.ts apps/web/src/components/promachos/promachosConversations.test.ts
   Result: 305 passed, 7 files, exit 0, 5.35s. Log /tmp/sol546-r3-focused.log.
2. bash scripts/fork-check.sh --upstream upstream: exit 0, 196 stack commits, 52 features, final fork-check: OK. Log /tmp/sol546-r3-fork-check.log. Verified upstream/main=e704190e8ce0d15f85e42bc844baad525b2110c1 and merge base d0918f1659f4c19172796c8d1910ca6e4bc18b51.
3. git diff --check base HEAD: pass. Exact changed-path/ownership checks and final empty status/unchanged identity: pass.

Hash-verified reuse, not fresh executions:

• Metadata manifest SHA256 76c7bcbc7f7056920dbf2a632ddf39e048ff8c3a44f1f4dcfb051e028013019f: matches; both metadata files and all 4 logs match.
• Consumers manifest SHA256 7b38eeabfaf4db165e3d6a2648316f748e95217fc69e12f2778f96656da5d14f: matches; all 16 unchanged prior files and all 9 logs match. Only the intentionally changed inventory file differs. Verified exact 301..57 path set.
• Inspected retained compiler output, targeted React Compiler output (2 passed, 1092 filtered), scoped lint warnings, formatting/inventory output and intended phone/alternate assertion failures. The three package compiler passes, compiler cases, lint/format and failing-before evidence belong to the author at 301 or their recorded historical candidates. I did not rerun compilers, red-before cases or any production mutation.

Unverified here: Current complete CI, actual web/desktop/native phone/tablet interactions, screenshots, reconnect, live search RPC, native subscription performance, real providers and remaining parent-label/resource/third-hop/Run-group work. These remain parent-owned and are not silently counted as component acceptance.

All reviewer-owned finite commands exited. No source/index changes, topology operations, installs, product/dev servers, browser panels/devices, live data/grants, provider prompts, commits/pushes or merge/deploy actions occurred. This findings comment is the only forge content mutation; no aggregate or commit status was written.

Reviewed independently by Codex / GPT-6.1 Sol / MEDIUM.

[lukemaj]

Independent review, round 4 (fresh whole current source): APPROVE

What: I approve the whole 18-file component at 57cf20e6be61f21734629bf25405afc267ed299b. This round re-read the full current diff of every file and the current consumer source. Nothing was carried over by hash.
Why: Every existing sidebar and search consumer on web, desktop, phone and split-view mobile applies one shared rule. Remote children are hidden by default and found by a nonempty search, user forks stay visible, and canonical stores and qualified identity are unchanged. Both new carried-edit declarations have exactly one primary owner.
So what: This closes the procedural limit on my round-3 report (6272929230). The parent still owns the aggregate status, current CI and real-client acceptance. This comment makes no merge or readiness claim.

Requirements and who asked: User refinement 3796268898682 (approved #379 v5) and #386 require remote children hidden by default, findable offline through existing search on web, desktop and mobile touch, hidden again on clear, with user forks visible and qualified identity kept. The fork-stack policy requires every carried upstream edit to be allowlisted with one owner. The parent's gate 6272953959 requires a fresh whole-source read.
Deleted: Nothing to propose. This change needs no new panel, setting, schema, server change, store filtering or gate change.
Bottleneck: None in this component. The remaining gates are owned by the parent.
Checked myself: Read the full b6d778b..57cf20e diff of all 18 files and the current consumer source listed below. Ran 305 focused tests and the true-boundary fork check fresh, and checked live PR identity.

Candidate

Base b6d778b90409e337fcec9168c96b5c5330702055, head 57cf20e6be61f21734629bf25405afc267ed299b, tree 59ff4f0c81e7710c570aea0cd10401ce43bd315a. 18 files, +897/-40. The live PR head and base match, and the PR is OPEN and DRAFT with 18 changed files.

Read this round (current source)

• Diff, all 18 files in full. Production: models.ts, threadShell.ts, Sidebar.logic.ts, Sidebar.tsx, promachosConversations.ts, LegacySidebar.tsx, HomeRouteScreen.tsx, HomeScreen.tsx, ThreadNavigationSidebar.tsx. Tests: threadShell.test.ts, Sidebar.logic.test.ts, threadListV2.test.ts, HomeRouteScreen.search.test.tsx (all 429 lines), LegacySidebar.test.ts, promachosConversations.test.ts. Metadata: fork-features.md, map.md, fork-upstream-edits.txt.
• Consumer source.
  • Mobile: HomeRouteScreen in full (atom selection, split-view branch, HomeHeader search wiring, props), home-route-visibility.ts in full, HomeScreen content search, move availability, list layout, hasAnyThreads and empty states, and ThreadNavigationSidebar thread and list inputs.
  • Shared state: the threadShell.ts all-shell and navigation atoms, and every navigationThreadShellsAtom and useNavigationThreadShells consumer.
  • Web V2: useSidebarThreads, partitionSidebarThreads, the search call site and searchSidebarThreads, and all isSidebarSubagentThread and filterSidebarV2VisibleThreads callers.
  • Alternate web sidebars: PromachosSidebar and the AppSidebarLayout mode branch. In LegacySidebar: useProjectThreads, project sort, useLegacySidebarThreads (jump keys and prewarming) and the Search trigger.
  • Command palette: its buildThreadActionItems input.
  • Server and contracts: ThreadForkService.plan, Orchestrator delegatedFrom stamping, and the OrchestrationV2ThreadShell.delegatedFrom contract.

Findings on current source

1. Shared rule (models.ts:198-213). A thread is shown when it is not archived and not a local subagent. A thread carrying delegatedFrom is shown only if it is a fork or the trimmed query is nonempty. presentThreadShell passes delegatedFrom through by reference. Only navigationThreadShellsAtom (threadShell.ts:397-410) filters. The all-shell, project, ref and single-thread atoms are unchanged. ThreadForkService.ts:84-103 spreads the source thread and sets relationshipToParent: "fork", so a real user fork keeps provenance and stays visible. Orchestrator.ts:2564 stamps delegatedFrom only together with linkOrigin, so ordinary linked work stays visible.
2. Phone Home (Opus r1 6272457840): cleared.
   • HomeRouteScreen.tsx:61-66 reads threadShellsAtom only while the trimmed query is nonempty, through useAtomValueWhileVisible. The hook takes atom in its subscribe dependencies, so a query change resubscribes, and a hidden Home keeps its held value.
   • HomeScreen.tsx:593 applies the shared rule. Move availability (:555,561) and inbox observation (:589) use navigationThreads.
   • Content matches use threadSearchMatchKey, which is environment-qualified. The mounted test confirms this with the same bare ID in two environments, and also covers clear-rehide, the hidden-route guard and no rebuild on hidden-child updates.
   • Search lives in HomeHeader, outside HomeScreen's empty state, so it stays reachable even when only hidden children exist.
3. Split-view mobile. ThreadNavigationSidebar.tsx:139-143,368-370 uses the same selection and rule. Move availability and inbox use navigation threads. There is one useAtomValue call with one of two atoms, so hook order is stable.
4. Web V2. The shelves come from the empty-query filter (Sidebar.tsx:635). searchableThreads (:582-592) appends only rows that the query admits and that isSidebarSubagentThread classifies as children. Those rows are remote children that are not forks and are not on the shelves, so nothing is duplicated. Local subagents never pass the shared rule, so the classifier admits nothing else. Whitespace appends nothing. Project scope and person view carry over because the appended rows come from the same threads. searchSidebarThreads keeps title matches before content matches.
5. Promachos and legacy (Sol r1 6272512045): cleared.
   • Promachos: PromachosSidebar.tsx:138-141 feeds person-view canonical shells to promachosConversations.ts:65, which applies the shared rule after qualified home membership. Promachos has no inline search, and the canonical command palette is unchanged.
   • Legacy: legacySidebarVisibleThreads (:1111) feeds both the rendered rows (:1172) and the keys used for jumps and prewarming (:3193), so the two cannot diverge. Legacy Search opens the command palette, whose buildThreadActionItems reads the full shells. The test runs the real selector and real palette items and selects [destination, child.id].
6. Declarations (Opus r2 addendum 6272812661): cleared. fork-upstream-edits.txt gains only the two literal paths, in the Peer links section. In fork-features.md each path appears exactly once, under peer-links upstreamFiles. HomeScreen.tsx keeps primary owner no-project-sidebar (upstreamFiles) and appears as a shared file of peer-links. No checker or validator code changed. map.md adds the DNC part with PR fix(client): hide remote children from default navigation #546 spec: native cross-machine control across linked environments #379 feat(peer): complete all-tool cross-machine workflows across web desktop and mobile #386.

Non-blocking observations (rechecked, no change requested)

• Legacy project sort (LegacySidebar.tsx:3119-3135) uses sortProjectsForSidebar over shells that are only archive-filtered, so hidden children can affect project order. Local subagents already did, and row visibility is unaffected. V2 sort (Sidebar.logic.ts:1344) uses the shared rule.
• During phone search, hasAnyThreads (HomeScreen.tsx:920) sees full shells. The only effect is a "No results" list in place of the welcome state when every shell is hidden. Findability is unaffected.
• Callers typed as Pick<…, "lineage"> (for example sortSidebarV2ProjectGroups) do not name the optional delegatedFrom in their types. At runtime they pass full shells, so behavior is correct. This is a typing nuance, not a defect.

Proof

• Fresh (this reviewer, frozen tree, copied dependencies, no install):
  • npm exec --yes --package=node@24.13.1 --package=pnpm@11.10.0 -- pnpm exec vp test run on the 7 focused files (threadShell.test.ts, Sidebar.logic.test.ts, threadListV2.test.ts, HomeRouteScreen.search.test.tsx, home-route-visibility.test.tsx, LegacySidebar.test.ts, promachosConversations.test.ts): 305 passed, exit 0. Log /tmp/opus546-r4-focused.log.
  • bash scripts/fork-check.sh --upstream upstream: exit 0, fork-features: OK (52 features), fork-check: OK., with merge base d0918f1659f4c19172796c8d1910ca6e4bc18b51. Log /tmp/opus546-r4-fork-check.log.
  • git diff --check base HEAD passes. Live gh pr view identity matches.
• Reused, not rerun: the author's 3 package compilers, 2 React Compiler cases, lint, fmt and the red-before logs. Manifest sha256 values match the brief: 76c7bcbc…019f (metadata) and 7b38eeab…d14f (consumers). This round I did not rehash the bound files individually; this round's source review did not rely on those hashes.
• Unverified: GitHub CI on 57cf, real web, desktop, phone or tablet runs, screenshots, native subscription performance, and the live search RPC.
• The review tree is clean and unchanged. No servers, browsers, devices, providers or lingering processes.
• Reviewer: Claude Code, claudeAgent / claude-opus-5-5, effort medium (checked with t3_thread_configuration).

[lukemaj]

What: Both required independent whole-component reviews approve exact head 57cf20e6be61f21734629bf25405afc267ed299b.
Why: Sol and Opus independently read the full current 18-file component and actual consumers, cleared the three prior findings, and reported no supported required code change.
So what: Code review passes on this head; current complete CI and primary-owned client evidence/acceptance remain required before the parent can merge this internal component.

Requirements and who asked: Approved #379/#386 and the recorded review policy require Sol MEDIUM plus a different-family Opus5.5 MEDIUM review on the current complete component, with original findings and responses retained.
Deleted: Earlier-head approval transfer, treating a hash-only source assessment as the required full current review, any review exemption, and merging with missing CI or client proof.
Bottleneck: Current complete CI and before/after real-client evidence; the code-review requirement is now satisfied on57cf.
Checked myself: Read both full final reports, exact current GitHub head/base/draft state, the prior finding/response trail and both reviewers' explicit current-source coverage, fresh tests, true-boundary fork checks and evidence limits.

Exact candidate: base b6d778b90409e337fcec9168c96b5c5330702055, head 57cf20e6be61f21734629bf25405afc267ed299b, tree 59ff4f0c81e7710c570aea0cd10401ce43bd315a, 18 files.

• Sol complete independent review: APPROVE; persisted Codex/GPT-6.1 Sol/MEDIUM. Read all18currentdiff files and surrounding consumers; 305 fresh focused passes, actual d0918-boundary fork check passes, manifests and source/log hashes checked, clean unchanged source and owned processes ended.
• Opus fresh full-current-source review: APPROVE; persisted Claude Code/Claude Opus5.5/MEDIUM. Read every currentdiff file and current consumer source, including full phone test; 305 fresh focused passes and actual d0918-boundary fork check passes, clean unchanged source and commands ended. This explicitly closes the source-read procedural limit of round3.

Both clear phone Home search, alternate default sidebars and exact carried-edit/primary-owner declarations. Both preserve typed delegatedFrom, actual inherited-provenance user forks, unfiltered canonical stores, qualified identity and existing search/clear/visibility behavior. Their nonblocking observations remain recorded as nonblocking, without unrelated cleanup.

Executed versus reused versus unverified remain as reported: focused tests and true-boundary fork checks were fresh; package compilers, targeted React Compiler, lint/format and earlier red evidence were reused with stated verification limits. This review status does not convert scoped checks into the full CI gate, or mocked native leaves into real client/device proof. Primary before/after visual verification uses isolated projection-only test fixtures and remains distinct from backend business acceptance. No complete parent/#386 acceptance is claimed.

This aggregate records review/independent SUCCESS only on57cf, after the findings above. PR remains DRAFT and unmerged pending all other gates. No main merge, deployment, installed Chromeria restart, live-data or existing user-grant change.

[lukemaj]

What: Exact #546 now passes real web and iOS phone navigation acceptance; both independent reviews and current CI pass.
Why: Remote delegated children belong outside default navigation but must remain searchable without their parent, while user forks remain visible.
So what: Keep this component draft until the retained before/after screenshots are attached to GitHub; the driver then integrates it into #379, not main.

Candidate: base b6d778b90409e337fcec9168c96b5c5330702055, head 57cf20e6be61f21734629bf25405afc267ed299b, tree 59ff4f0c81e7710c570aea0cd10401ce43bd315a.

Primary-agent product observations:

• Web default sidebar: at integration baseline the remote child is visible; on current head it is hidden, ordinary task and user fork remain, exact title search finds the child despite absent/offline origin parent, and clearing search hides it again.
• Web Promachos mode: chose only the disposable fixture project as home through the real UI. Its conversations retain ordinary task/user fork and omit remote/local delegated children and archived fixture.
• Web legacy sidebar: switched through Settings > General > Legacy features > Sidebar (legacy). Default project tree retains ordinary task/user fork and omits remote child. Its Search command palette finds the remote child by title. No provider run was started.
• Real native iOS phone Home: fresh task-only simulator, exact candidate Metro bundle and freshly checked compatible native client, fingerprint 689e1b8aac8c5e5e77a06e9a796f1afd022f047c. Paired only with the task-owned isolated backend using the existing mobile pairing helper and test-only grant. Default list shows ordinary task/user fork and hides delegated children. Search finds exactly the remote child; Clear text hides it again. Searching and tapping the result opens the correct 379 remote child proof thread, displaying server · bestia, with no provider prompt submitted.
• One AgentDevice fill read-back omitted a character and correctly produced No results; corrected using the tool's documented --delay-ms 80, then verified the full actual field and result. This did not change product source or weaken the oracle.

The five fixture rows were projection-only isolated data. Their original insertion did not alter either event log. This is real client visual/navigation proof, not coherent event-history, automation, linked-resource execution or parent #379 completion. No Android, tablet or desktop-shell run is claimed; shared/split-view consumers have the focused repository evidence and independent source review.

Screenshots retained: web before, current default/search, Promachos default, legacy default/search, iOS default/search/selected. Persistent local manifest 546-client-proof.json SHA256 2d97137c095f8a1a451c651a869180c6e0b584365c2db59786bb014e92f96c86 binds every retained artifact. The Browser profile was signed out of GitHub, so images have not yet been uploaded; no credential or existing grant was changed. Awaiting access for only that evidence step while other work continues.

Bestia rebooted at 20:03 Warsaw, stopping the isolated backend and losing /tmp raw logs/manifests. Screenshots, source and GitHub CI/review reports survived. The driver restored only its own isolated backend on the same ports/source; Rocky Metro survived. Earlier /tmp repository proofs are now historical reported results, not available raw evidence to relabel as inspected/current. Fresh #534 reviewers were explicitly informed and now retain new reports in persistent task state. No driver restart of installed Chromeria, deploy, main merge or live user data.

Requirements and who asked: User's #379 approval requires reviewed components and isolated browser/native acceptance; repository requires UI before/after images uploaded to GitHub.
Deleted: Reusing cached simulator connections, hash-only full review, temporary logs as durable evidence, and helper tests as live product acceptance.
Bottleneck: GitHub screenshot attachment access; the component's current reviews, CI and observed phone/web behavior pass.
Checked myself: Real UI actions and screenshots, exact local/remote candidate identities, original/full search field and selected native heading, fresh native compatibility check, live GitHub CI/review status.

[lukemaj]

What: The before/after web screenshots and real iOS phone evidence are now attached directly to this PR.
Why: Default navigation must hide delegated remote children while search can still find them and user-created forks stay visible.
So what: Screenshot access is resolved; the driver verifies current gates and integrates this exact component into #379, without merging main.

Candidate 57cf20e6be61f21734629bf25405afc267ed299b, tree 59ff4f0c81e7710c570aea0cd10401ce43bd315a, integration baseline b6d778b90409e337fcec9168c96b5c5330702055.

Images appear below in order: web baseline before, web default after, web title search after, Promachos after, legacy default after, legacy search after, iOS default, iOS title search, iOS selected child. The baseline incorrectly shows the remote child in default navigation; current default views hide it, preserve the ordinary task/user fork, and search finds it with its origin parent absent. Native selection opens the correct child heading. Full executed client proof and limits.

These are real clients against isolated projection-only fixtures, not coherent event-history or broader #379 backend acceptance. Native declarations gained only the tool-generated header comment during Metro; runtime source is unchanged. No existing user connection/grant, live user data, installed Chromeria restart, main merge or deployment.

Correction: the earlier screenshot-access blocker was wrong. The installed gh pr comment --help exposes --attach, so no Browser sign-in or vault credential was needed. Current CLI help and GitHub's first-party attachment documentation support this path; checking that actual owner should have preceded asking the user. The pending access question is superseded.

Requirements and who asked: User's #379 isolated client verification and repository's PR before/after image requirement.
Deleted: The unnecessary Browser sign-in prerequisite and reliance on remembered CLI limitations.
Bottleneck: Screenshot publication is resolved; current exact-candidate merge gates remain authoritative.
Checked myself: Actual installed gh pr comment --help, retained images/manifest, exact live head/base/draft, real web/phone observations and full review links.

Primary work: GPT-6.1 Sol / Codex / MEDIUM.

[lukemaj]

Agent work on this PR

Estimated cost at least $0.73 · 22 responses · 19 sessions · 2.6 h wall time

Model	Responses	Tokens	Estimated cost
gpt-6.1-sol (codex, medium)	19	4,548,272	$0.73
grok-4.7 (grok, medium)	3	569,146	unknown

Flags: 5 large tool outputs · 4 repeated commands · 13 repeated reads · 11 repeated skill loads · 3 unpriced responses

Details: snapshot, prices, coverage, counters

• Task toolboxmd/chromeria#546: outcome unknown (recorded acceptance only; a finished process never implies it).
• Proof: fix(client): hide remote children from default navigation #546
• Snapshot 0e0c3132deeca07722a38b7ec5cc8b02405deebd0712896df01519921e4540c9, records up to 2026-10-19 16:59 UTC.
• 19 sessions on claude, codex, grok; AgentsMD 17.4.1.
• The total includes work shared with 4 other tasks, counted whole in each, so sums across PRs overlap.
• Not counted: 1,284 responses ($45.12) in sessions shared with other PRs that worked in no single PR's checkout.
• 76 responses in these sessions worked on other PRs and are counted there.
• Totals reconcile with the measured sessions: yes. Evidence complete: yes.
• Prices: list-price estimate from T3 local rate table (path withheld) as of 2026-10-18, schedule 414551dda4c47258113dcfa46a5dfa5aa512406e3dfcadcca3381421595c5588. Unknown prices stay unknown, never zero.
  • T3 LiteLLM rate table when present; bundled schedule covers the rest.
  • Model price sources: T3 local rate table (path withheld).
  • Unpriced: unknown model (3).
• Harness-reported cost: none reported.
• Usage totals are not billing. Subscription spending is separate and is never posted as spend.
• Crashed runs are counted separately: 0.

Token counters by model (native counter semantics; never added across semantics):

• gpt-6.1-sol (codex, medium), codex counters: input includes cached, output includes reasoning: input 4,529,682; cache-read 4,484,224; cache-write 0; output 18,590; reasoning 9,128; harness total 4,548,272.
• grok-4.7 (grok, medium), grok counters: input includes cached, output includes reasoning: input 557,583; cache-read 420,352; cache-write 0; output 11,563; reasoning 9,123; harness total 569,146.

Generated tokens (reasoning and other output are disjoint; other output includes code, tool calls and replies):

Model	Reasoning	Other output	Reasoning share	Split known for
gpt-6.1-sol (codex, medium)	9,128	9,462	49.1%	19 of 19
grok-4.7 (grok, medium)	unknown	unknown	unknown	0 of 3

Usage by work phase (this task's own responses):

Phase	Model	Responses	Input	Cache read	Cache write	Output	Reasoning	Total	Priced part
unclassified	gpt-6.1-sol (codex, medium)	19	4,529,682	4,484,224	0	18,590	9,128	4,548,272	$0.725238

Recorded activity by phase (observations, not separate token bills):

Phase	Tool calls	MCP results	Reads	File changes	Failed tool results
unclassified	173	54	50	6	11

Selected rates (USD per million tokens). These rates value the report at the selected schedule date; they do not establish historical prices or subscription spending.

Model	Input tier	Input	Cache read	Cache write	Other output	Reasoning
gpt-6.1-sol	all	2	0.1	2.5	10	10
grok-4.7	all	unknown	unknown	unknown	unknown	unknown

Other output and reasoning are priced without double counting inclusive native output. Missing rates remain unknown.

_{Local measurement from native records; usage totals are not billing. Updated in place by agent-observer publish.}