Improve Context Composer resolution performance

[baron]

Summary

• remove redundant whole-root resolver and frozen-accounting passes from Context Composer loading, routing work through shared/cached resolution instead
• preserve a completed token estimate for the same selection while a refresh is pending, and publish completion only after recount scheduler state has settled
• bulk-materialize file rows, hydrate inactive tab/session selection routing, and keep exact selection/worktree identity fail-closed
• project worktree bindings once from the canonical Agent session into immutable status UI state instead of resolving them repeatedly from SwiftUI getters
• replace repeated graph path/UUID comparisons with affected-ID ranks, bounded to sparse deltas rather than sorting the whole graph
• maintain an ephemeral manifest publication inventory with exact filesystem membership/identity witnesses so repeated publications avoid unrelated payload reads without weakening external-mutation detection
• add deterministic regression coverage across token accounting, routing, bulk materialization, graph ordering, manifest authority, chat switching, and Context Composer UI readiness

Root cause and design

Opening Context Composer could independently trigger multiple expensive whole-root traversals and token-accounting passes. Samples additionally showed SwiftUI body evaluation repeatedly rebuilding persistent binding-resolution snapshots, graph sorts repeatedly traversing path bytes, and manifest publication repeatedly scanning/checksumming/decoding the whole store.

The fix establishes explicit projection and synchronization boundaries rather than adding delays or retries:

• core/session state remains authoritative; SwiftUI receives immutable projections
• completed matching token results remain usable while equivalent refresh work is pending
• known deltas are applied incrementally, with cache reuse guarded by exact authority witnesses
• external filesystem mutation and tab/session identity changes fail closed and force authoritative re-resolution

Validation

• contribution commit/push/PR-ready safety gates and outgoing-range secret scans: passed
• SwiftFormat 0.61.1 + SwiftLint strict: passed
• repository guardrails: passed
• affected integration set: passed (302 tests, 0 failures)
• CodeMapRootManifestStoreTests: passed (51 tests, 0 failures)
• WorkspaceCodemapSelectionGraphIncrementalTests: passed (13 tests, 0 failures)
• focused token, routing, bulk-materialization, chat-switch, and Context Composer regressions: passed
• make dev-swift-build PRODUCT=RepoPrompt: passed
• final make dev-build: passed; signed debug bundle at ~/Library/Application Support/RepoPrompt CE/DebugApps/RepoPrompt.app
• integrated Oracle review: no substantiated changed-line must-fix; sparse-delta scale concern was addressed before push

Live retest status

The final bundle is built but has not been visibly relaunched yet: the required immediate launch approval prompt timed out. Exact-context PID sampling and release/debug content-parity comparison remain pending that approval; the PR does not claim those as completed.

[baron]

@w-winter feel free to make direct changes or even close the PR if irrelevant (buggy or doesn't improve speed).

[morluto]

Audit disposition — evidence and current-head blocker (2026-08-14)

The design contains several careful boundaries—immutable UI projections, selection-matched token reuse, candidate-local graph ranks, and manifest membership/identity witnesses—but it changes 31 files across performance, routing, accounting, and persistence. Focused tests are not enough to establish the combined behavior.

Please resolve the exact-head failing app shard, visibly relaunch and sample the built executable in the intended Context Composer scenario, compare release/debug behavior, and provide measured before/after traversal, token-recount, UI-body, graph-sort, and manifest-publication evidence. I would not merge this large performance/persistence change while the final live and hosted evidence remains incomplete.

[morluto]

Deep-review assessment — 2026-08-14

Disposition: hold for current-head failure triage and real performance evidence. The authority-aware ideas are thoughtful: immutable UI projections, usable completed token snapshots during equivalent refresh, sparse candidate ranking, and manifest-cache reuse guarded by exact directory/file witnesses. But this is a 31-file cross-layer change, the final bundle was not visibly relaunched/PID-sampled, release-versus-debug parity remains pending, and the reviewed exact-head CI had one failing app shard.

Please identify that failure, complete the live relaunch/context sampling, and publish before/after measurements for each claimed hot path. Consider splitting manifest publication caching, graph ordering, token scheduler/UI semantics, and inactive-tab routing into independent PRs; the current evidence gap is too large for one performance branch of this breadth.