docs: two independent development lanes until Forge cutover (NO_BUMP)

[pcvantol]

Owner request

Arrange the preserved four-product roadmap into two temporary independent Codex development lanes, with persistent ARCHITECT_1 / ARCHITECT_2 sessions responding to “geef volgende prompt (1)” and “geef volgende prompt (2)”. Keep earliest safe handoff to Forge-driven Missions as the goal.

Delivery

• Add a detailed rolling-ready-frontier plan, not rigid two-item waves or a new execution DAG.
• Add a machine-readable allocation covering all 34 existing families and all 165 analytical rollup units: 82 exclusive units in lane 1, 76 in lane 2, seven shared evidence joins counted once. These counts are not effort estimates or new Missions.
• Add per-lane session routers and navigation from BOOTSTRAP and the existing overview.
• Establish empty shared coordination registers [LANE_1] Tijdelijke tweesporenplanning — architect_1 #141 and [LANE_2] Tijdelijke tweesporenplanning — architect_2 #142; existing local work must be reconciled before the first prompt. No assignment has been started or automatically adopted.

Safety and semantics

Default disjoint repository pools prevent same-repository selection races under the explicit one-architect-writer-per-lane agreement. Repository transfer requires quiescence and a two-sided matching handoff. GitHub issues are explicitly NOT atomic leases or a product scheduler; existing runtime/resource locks remain required. No duplicate prompt while prior work can mutate. Shared reset, live canary and activation resources require coordinated windows; independent fixture/source work may continue. One lane never needs to await the other's full family. Owning DAG/evidence/approval requirements remain authoritative.

The current reset-revalidation repair is carry-over, not a reason to rebuild previous release/reset/telemetry work. No new Mission-3 criterion or permission. Once a supported scope is qualified for Forge, its next prompt becomes a Mission kickoff rather than another direct implementation script. No requirement to finish all 34 families first.

Validation

Local structural validation confirms exact unique coverage of the original 165 counted IDs, 34 families, seven shared nodes, unchanged ownership/family mapping and disjoint default pools. The uploaded JSON blob 4d176a401c3e40b3ddc39603af9e6c318bb49b49 matches the validated local bytes. Original inventory remains unchanged. Full repository CI pending at creation; no installed two-session execution or runtime qualification claimed.

Documentation and coordination only. No runtime code, schema, workflow, policy, grant, credential, release, installation, CENTRAL reset, Mission or provider execution changed/started. Public content contains no private local infrastructure values. Protected delivery only.

[pcvantol]

Author-side documentary review on the exact candidate (not an independent runtime assurance receipt):

• Local validation reconstructs the original inventory and verifies all 165 counted IDs exactly once, the 34 families, unchanged owner/family mapping, and seven shared nodes. Default exclusive units are 82/76, not duration estimates.
• Exact local Git blob hashes match the uploaded JSON (4d176a4…), protocol (d9dea0e…) and both session routers (7797364…, 988229b…). Existing inventory bytes and owning dependency graphs are unchanged.
• Reviewed rolling selection, one architect writer per lane, disjoint default repository holders, two-sided quiescent transfers, no issue-as-atomic-lock claim, shared runtime/canary fences, no duplicate existing reset repair and scope-specific earliest Forge cutover.
• Comparison with the base contains only six documentation/index/navigation files, 362 additions, zero deletions. No new implementation/Mission/installation/reset/security grant.
• Exact-head Forge CI 35315690278, CodeQL 35315690319 and non-blocking TDE observe 35315690308 have all completed successfully.

The two issue registers remain unassigned until real running work is reconciled. This delivery does not prove two live Codex sessions have already used the protocol. Ready for the requested protected documentation delivery.