The roadmap plan authority becomes a parameter so a caller can supply its own plan

[gunbai-bot]

What was hardwired

Every roadmap surface read its plan from one nullary — gunbc.roadmap_authority roadmap_authority_projection — so which plan a process serves was not a fact anyone could supply. It was wired into each fold that consumed it, at 18 call sites across six modules.

The seam

The plan authority becomes a parameter, and the nullary stays as one binding of it. This is not a new mechanism: gunbc.roadmap_belt_actuate already half-built it — belt_dispatch_node_staged_over took the launch graph as a parameter with belt_dispatch_node_staged binding the public one. The same _over shape now reaches:

module	new _over fold	public binding
gunbc.roadmap_serve	roadmap_serve_handle_over, roadmap_serve_respond_over, roadmap_serve_selection_response_over, roadmap_serve_invoke_over, serve_dispatch_handler_response_over	roadmap_serve_handle + the five host entries
gunbc.roadmap_static_site	roadmap_site_roadmap_md_body_over, roadmap_site_dispatch_json_body_over	the two nullaries
gunbc.roadmap_belt_actuate	belt_launch_host_standing_for_page_over, belt_dispatch_node_for_instance_over	the existing nullary/instance forms
gunbc.roadmap_served_observation	served_observation_daily_surface_over, served_observation_snapshot_observe_over, served_observation_observe_and_write_over	..._for_instance
gunbc.roadmap_forecast	roadmap_schedule_forecast_over	live_roadmap_schedule_forecast
gunbc.roadmap_site_surface_observe	materialize_roadmap_site_surface_bundle_over	materialize_live_...

gunbc.roadmap_page needed nothing new — its _for_projection family already was the parameterized form; its callers now reach it directly.

What is passed is the projected plan, RoadmapAuthorityProjection, not a path or a source root. A plan that failed to project arrives as RoadmapAuthorityProjectionRefused and refuses in the caller's own vocabulary at every surface, rather than rendering as a silently empty roadmap.

It is not a registry. Nothing here enumerates plans and no table is filled in from elsewhere. A caller supplies its plan by CALLING the parameterized fold from its own entry function, so this module stays unaware of who calls it and needs no edit when another one does. Nothing in this diff names any repository, module or plan other than the public ones.

Why an entry function is the whole integration

Instance selection is already by serve entry function, because gunbc serve binds --entry/--function once for the process's life and carries no per-request argument. Re-verified against gunbc.cli_dispatch_surface rather than assumed: the serve row's options are exactly --source-root (repeated), --entry, --function, --host, --port, --release-revision. The plan a process serves is the same kind of fact — fixed at launch, constant for every request — so it arrives the same way.

Behaviour

Unchanged for the public entries. roadmap_serve_handle and the five host entries bind roadmap_authority_projection() and reach the same folds they reached before; srv1-live observes nothing new.

One deliberate simplification inside live_roadmap_schedule_forecast: it no longer re-reads accepted_roadmap_node_ids_projection() and takes the accepted set from the projection it was handed. Same value — roadmap_authority_projection fills that field from exactly that call — and its AcceptedRoadmapNodeIdsProjectionRefused arm was unreachable, because a refused accepted-ids projection already makes the enclosing projection Refused. With a caller-supplied plan the second read would have answered about the public roadmap while the nodes came from the caller's, which is the fork this parameterization exists to prevent.

Two nullaries lost their last consumer when their callers moved to the projection-taking form, and are deleted rather than left dangling (DESIGN §3c): roadmap_page_for_authority_launch and roadmap_daily_workspace_page_for_authority_observed.

Evidence

Three witnesses in test.claim.roadmap_serve_witness hand roadmap_serve_respond_over a caller-supplied plan and assert the response answers from IT:

• witness_roadmap_md_answers_from_the_supplied_plan
• witness_dispatch_json_answers_from_the_supplied_plan
• witness_supplied_plan_refusal_travels_to_the_wire

The discriminating direction is the negative. Asserting that the caller's section title appears would stay green if a surface under the route also read the public carrier and concatenated both; asserting that the public roadmap's own section title — Active deliverables — is absent is what goes red the moment any consumer below roadmap_serve_respond_over reaches past its parameter. The refusal witness additionally proves the caller's own detail string reaches the wire on both /roadmap.md and /dispatch.json.

Compile control: the closure was compiled with a deliberately misspelled reference at the new seam and the compiler refused with undefined variable; with the real diff the entry compiles to the same 3 pre-existing blocking errors (extdeps.gunbc shell transport emission, untouched here) that HEAD produces for the same entry — measured on a detached worktree at HEAD, not asserted.

Not done here, deliberately

The belt tick and the post-spawn attempt path still read the public plan: belt_tick_for_instance, belt_run_once_in, and belt_lookup_node with its seven consumers across the commit / verify / review / audit / publish folds. Parameterizing those means threading the plan through that whole family, which is a separate restructuring in files eager-gull-33 is actively changing. The dispatch ROUTE is fully parameterized (belt_dispatch_node_staged_over resolves the node from the supplied graph, so no public read survives on that path); the TICK is not.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GPjYNDmV8FK6wYLXj4de1S

---

What changed after review (this section post-dates the description above)

Four rounds of review found real defects. The design above is the starting shape; these are the corrections, kept here because a PR body describing a superseded design is its own small fork.

The seam leaked, and the fix is by construction rather than a check. roadmap_daily_workspace_page_for_projection_observed's refused arm re-read the public accepted set. Routing that arm to the plan-supplied form closed the route — but the ambient-reading fold was still reachable, and no witness could guard it: under the hermetic route the carrier read refuses and yields the same empty set a clean render yields, so mutated and unmutated agree on every input a witness can construct. Measured, not assumed — the leak restored in an isolated worktree still PASSED. Per §4b that check would be a decoration, so roadmap_daily_workspace_page_impl is deleted and every caller supplies its accepted set. daily_workspace_view_of and v1_exit_program_progress_view went with it (zero consumers tree-wide).

Route / now refuses instead of answering from an unnamed authority. The plan parameter created a constructor for a forbidden state: a caller supplying its own plan to the serve entry, while / is served from a body the belt tick wrote under its plan. Filing that at a low rung was wrong — §4b puts silent wrongness outside the ladder and forbids it outright. ServedDailyBodyAuthority = DailyBodyRenderedUnderThisPlan | DailyBodyAuthorityUnknown makes the agreement a declared fact of the call; the unknown arm gets a located 503 naming the class and the tick entry to bind. The coproduct has no third variant, so no Accepted program serves / from an undeclared authority. The nine public bindings declare agreement, which they legitimately can — public serve and public tick bind the same projection.

The residual is filed, not documented. gunbc.recurring_failure_mode.a_prerendered_body_carries_no_identity_of_its_source: rung 1 (not 3 — §4b(1) puts a class at the minimum across its paths; the undeclared case is refused, the declared-but-false case is contained, not prevented), ceiling 3, trigger naming a capability — a materialized-surface identity sufficient for a read-back to decide agreement. The row states outright that stamping a field into the snapshot type is not the trigger unless the read-back is obligated to consult it.

Routes are cited, not spelled. Three witnesses originally asked /roadmap.md and /dispatch.json — neither is a route, so all three asserted status == 200 against a 404. Rather than correcting the strings, roadmap_serve_route_specs now consumes the declarations gunbc.roadmap_site_surface_render already owns, and the witnesses cite the same ones, so a renamed route moves the table, the static artifact and every witness together.

Evidence, by execution: 7/7 plan-parameter witnesses, 13/13 frontier witnesses, 36/39 long page witnesses (the 3 shown inherited by controls at the merge base and current origin/main), plus the mutation control above.

Known and accepted: DailyBodyRenderedUnderThisPlan is a caller assertion nothing on the serving side can check — that is the declared-but-false case the row carries at rung 1, and converting it from trusted to checked is exactly the ceiling-3 trigger.

[gunbai-bot]

Verified all three findings in review 63317. All three stand, and all three are fixed. Thank you — the first one is the defect this PR exists to prevent, found inside the PR that claims to prevent it.

1. The daily surface leaked — confirmed, fixed.

roadmap_daily_workspace_page_for_projection_observed's REFUSED arm called roadmap_daily_workspace_page_impl, which re-reads accepted_roadmap_node_ids_projection(). So a caller-supplied plan that failed to project rendered its refusal banner beside the public accepted set. That arm now calls roadmap_daily_workspace_page_impl_for_accepted with accepted_ids: [], which is what a refused plan means and is byte-identical for the public path (a refused public projection already implies a refused accepted-ids projection, whose arm passed []).

Two corrections to the finding's scope, both in the direction of more removal, not less:

• The projected arm was already clean — it passes accepted off the projection into ..._impl_for_accepted. The leak was confined to the refusal arm.
• daily_workspace_view_of (roadmap_page.dag:1094) is not on that path: ..._impl_for_accepted reaches daily_workspace_view_of_for_accepted directly. daily_workspace_view_of has zero consumers in the whole tree, as does v1_exit_program_progress_view. Both are deleted rather than left standing — dead code that reads the public carrier is precisely how this fork would be re-established later (DESIGN §3c).

The two remaining accepted_roadmap_node_ids_projection() reads in roadmap_page are now reachable only from the doc-fixture and static-render entries (roadmap_page_for_doc, roadmap_daily_workspace_page/_launch), none of which is plan-parameterized. No public read survives under roadmap_serve_respond_over.

2. Rung inflation in the evidence — confirmed, and it was worse than stated.

The witnesses did not merely fail to cover the daily surface; they covered nothing. They asked /roadmap.md and /dispatch.json, and neither is a route — the declared paths are /ROADMAP.md and /target/roadmap-dispatch.json. Three witnesses asserting status == 200 against a 404. (To close the worse reading: the responder is not fail-open — serve_select_route returns NoRouteMatched and the fold answers 404 — so those witnesses were red, not falsely green. That reading is now executable rather than asserted: witness_an_unrouted_path_is_refused_not_answered asks an unrouted path and requires the 404, so "answered from the supplied plan" stays distinguishable from "never reached a handler".)

The fix is not a corrected string. roadmap_serve_route_specs carried its own spelling of paths that gunbc.roadmap_site_surface_render already declares as data and that the static site, the surface bundle and the deploy witnesses all cite. Those rows now consume the declaration (roadmap_site_daily_url_path, ..._full_..., ..._roadmap_..., ..._dispatch_..., roadmap_site_health_path), and the witnesses cite the same constants — so a renamed route moves the routing table, the static artifact and every witness together, instead of sending one of them to a 404 in silence.

New: witness_daily_page_answers_from_the_supplied_plan probes roadmap_daily_workspace_page_for_projection_observed directly on both arms. Two notes on its honesty, since this is the finding about inflated evidence:

• The negative used elsewhere (the public section title) would be decoration here — the daily page renders work rows and bands, never the roadmap's section headings, so that assertion is true for a clean render too. What the leak actually moves is the v1-exit program progress count, so that is the observable, cited from v1_finish_lines_accepted_count / v1_exit_finish_lines rather than transcribed.
• Stated in the witness rather than left implied: it separates a leaking render from a clean one exactly where the public acceptance carrier is readable and names at least one accepted finish line. Where the carrier is unreadable, the pre-fix code took its own refused arm and produced the same empty count, so the probe is a true statement that cannot see the defect there. It is the regression control for the fix, not the instrument that would have discovered it.

3. materialize_roadmap_site_surface_bundle_over was a body-identical alias — confirmed, deleted.

render_roadmap_site_surface_bundle_for_projection already took the projection; the wrapper added a second name for one fold (DESIGN §3). The nullary now calls it directly and that file is back to a one-line diff.

[gunbai-bot]

Review 63341: all three verified against the tree and fixed in ba6ad74. But the important thing in this comment is a retraction, so it goes first.

I claimed a control I did not have

In a674c3b I called witness_daily_page_answers_from_the_supplied_plan "the regression control for this fix". I ran the mutation check that claim deserved — the leak from review 63317 deliberately restored in an isolated worktree — and the witness still PASSED.

It is decoration, and the reason is structural rather than a weak assertion: under the hermetic witness route the carrier read REFUSES, so the ambient fold takes its own refused arm and produces the same empty accepted set a clean render produces. No input reachable from a witness separates the two. The RED is not authorable, and no stronger assertion could have made it so. DESIGN §4b is explicit that such a check is worse than absent, because it gets cited as coverage — which is exactly what I did with it.

So the fix is no longer a probe. 2e67539 closes the class by construction (§5: construction over validation, and the class is decidable): roadmap_daily_workspace_page_impl — the fold that read accepted_roadmap_node_ids_projection() itself — is deleted. Its two remaining consumers are static doc-fixture renders and now supply accepted_ids: [] explicitly, which is what their own standing reason, "static render: the event carrier is not consulted", already claimed and did not deliver: the fold consulted it.

After that, no fold reachable from roadmap_serve_respond_over — or from a static render — can name the public accepted set. Verified on the pushed head: exactly one accepted_roadmap_node_ids_projection() call site remains in roadmap_page, inside finish_line_progress_markup, reachable only from roadmap_page_for_doc (the full-page doc fixture, not plan-parameterized, and whose witness asserts on that count deliberately).

The probe stays with its claim cut down to what it earns: both arms render, a refused plan carries the caller's detail rather than an empty public roadmap, and the v1-exit progress count is the one the supplied plan implies — cited from v1_finish_lines_accepted_count / v1_exit_finish_lines, not transcribed. The witness says in its own annotation that it is not the control for the leak.

The three findings

1 & 2 — two nullaries stranded by this PR. Both confirmed by grep: belt_launch_host_standing_for_page had only its definition left (both callers moved to _over), and served_observation_snapshot_observe_for_instance likewise, with roadmap_belt_tick_cli.dag:107 calling only the observe_and_write form. Deleted, for the reason the finding names — it is this PR's own argument for deleting roadmap_page_for_authority_launch, and I should have applied it to the ones I created.

3 — the daily handler was mis-filed, and this is the sharpest of the three. Grouping RoadmapDailyPageHandler with "the disk-read observation surfaces … ignore it" was a rung-honesty defect (§4b(1)), not a code one. It is a roadmap render; its plan is bound earlier, at the tick, through served_observation_observe_and_write_over — which this PR parameterizes. So the daily page is parameterized, on the other entry.

What the note was hiding is now what it says: a process serving its own plan must supply it at both entries, serve and tick. Supply it at only the serve entry and / answers from whatever plan the tick was given, with no refusal — because a pre-rendered body carries no record of the plan it came from, and nothing in the responder can detect the mismatch. That is a real seam between two processes, stated rather than papered over.

Evidence

All five plan-parameter witnesses PASS by execution under claim_batch, not by typecheck: witness_roadmap_md_answers_from_the_supplied_plan, witness_dispatch_json_answers_from_the_supplied_plan, witness_supplied_plan_refusal_travels_to_the_wire, witness_an_unrouted_path_is_refused_not_answered, witness_daily_page_answers_from_the_supplied_plan.

[gunbai-bot]

Review 63358 is right and the row is filed: dag/gunbc/recurring_failure_mode/a_prerendered_body_carries_no_identity_of_its_source.dag. DESIGN §4b says a discovered class files a row, not a comment; §4c says the same from the other side — no Accepted program can read an annotation, so prose is never evidence a machine claim holds. I had put a newly discovered class in a // block and left it there.

The row is deliberately not a restatement of the note:

• Distinguishing facts, so it discriminates rather than warns — all three required: a value parameterized at an entry, a consumer materialized ahead of time by a different entry, and a stored artifact whose schema omits the parameter it was derived under. A cache keyed by its inputs is explicitly not this class (the key is the identity this class lacks); neither is a surface that recomputes per request.
• Rung: below the ladder — the serving process cannot form the comparison, so there is nothing to mitigate against.
• Ceiling 3, not 4, with the reason: the mismatch is a relation between two independently launched processes, so it cannot be made unconstructible. What can be derived is the refusal.
• Next-rung trigger as a capability, not an artifact: a materialized-surface identity binding a stored body to the authority it was derived under, sufficient for a read-back to decide agreement and refuse on disagreement. The row states outright that stamping a field into the snapshot type is not the trigger unless the read-back is obligated to consult it — an identity nothing compares is the §4b decoration this PR already shipped once and had to retract, and a trigger naming less than the capability would retire the row while the class stayed dead.

No roster edit: dag/gunbc/recurring_failure_mode/roster.dag is gitignored (.gitignore:79) and written by the host fold that lists sibling files on the required parse path, so a new row file is the append. Verified, not assumed.

On the CI red — it was not this change, and the fix is merged

required-witnesses-floor was red on 2e67539. Its blocker set is four v2.test.native_decl_selection.* witnesses with interrupted_before_verdict. My three broken-path witnesses from the earlier run are gone from it.

Attribution, measured rather than assumed — the same three test/claim/long page witnesses I found failing locally (witness_ticket_brief_budget_holds_and_reds, witness_item_detail_disclosure_present, witness_authority_leads_within_budget) fail identically with my diff absent:

tree	those three
my head 2e67539	FAIL (36 of 39 pass)
merge base 38fde66, no diff	FAIL
current origin/main	FAIL

They are also absent from CI's blocker set, so they are pre-existing, unenrolled in the floor, and not this PR's to fix.

The four that do block are fixed on main by #10992 ("Share the native_decl_selection fixture at the resolved seam so its four witnesses fit the floor"), so I merged origin/main rather than rebasing, per the branch's squash policy. That also picks up #11003, which deletes the required-v2-native job.

Evidence standing, all by execution

• 5/5 plan-parameter witnesses
• 13/13 frontier witnesses (the consumers of the fold this PR deleted)
• 36/39 long page witnesses, with the 3 shown above to be inherited
• the mutation control that caught my own daily-page probe being decoration, which is why that class is now closed by construction rather than watched

[gunbai-bot]

Review 63390 is right, and it is the most important finding on this PR. Fixed in 45bb5a77.

The finding in DESIGN's own terms

My row said "RUNG: found BELOW the ladder." §4b says silent wrongness "is not a rung: it is outside the ladder and forbidden outright." So filing it at a low rung was not an admission — it was shipping a forbidden state with paperwork. And the sharpest half of the finding is the one I had not drawn: this diff creates the constructor. Before the plan parameter existed no caller could supply a divergent plan, so the PR that introduces the parameter is the PR that owes the wall.

What landed

ServedDailyBodyAuthority = DailyBodyRenderedUnderThisPlan | DailyBodyAuthorityUnknown, threaded through the four serve _over folds. Route /:

• DailyBodyRenderedUnderThisPlan → serves, exactly as today
• DailyBodyAuthorityUnknown → 503, located, naming the class, the tick entry to bind (served_observation_observe_and_write_over), and how to declare agreement

The coproduct has no third variant, so no Accepted program serves / from an undeclared authority. The nine public bindings declare DailyBodyRenderedUnderThisPlan — which they legitimately can, because public serve and public tick bind the same projection, so nothing observable changes for srv1-live.

On the suggested shape: I did not implement it as "refuse when the supplied plan is not the one the tick is bound to", because the serving process cannot decide that — it is the whole content of the class. Comparing the supplied plan against roadmap_authority_projection() would only answer "is this the public plan", which is a different question and would refuse a private serve whose private tick agrees perfectly. Making the agreement a declared fact of the call is the honest available arm: §4b's "outside the modeled guarantee" column handled at a declared boundary — observed, refused, or mitigated, never fabricated — and deliberately not a fifth rung.

The row moved with the code

Otherwise it would have inflated in the other direction. Rung is now 1, mitigatable — not 3, because §4b(1) puts a class at the minimum across its paths:

• undeclared → refused, unreachable, no longer silent
• declared but false (a caller asserting agreement its own tick does not honour) → contained, not prevented; nothing on the serving side can check the assertion

That residual is precisely what the ceiling-3 trigger converts from a trusted declaration into a checked one, which is now stated as the distance between rung 1 and the ceiling. The review tell says outright that documenting the seam and filing it at a low rung are both wrong answers, because both leave the forbidden state reachable — which is the mistake this review caught me making.

Evidence, by execution

Seven witnesses PASS under claim_batch:

• witness_undeclared_daily_body_refuses_rather_than_answering — the 503 and its located cause
• witness_undeclared_daily_body_costs_no_other_route — the positive control, without which "refuse everything" satisfies the first: a caller that cannot vouch for the daily body still gets /ROADMAP.md answered from its own plan
• plus the five plan-parameter witnesses from before

Also merged origin/main (#10992 fixes the four native_decl_selection witnesses that were the floor's actual blockers; #11003 removes the required-v2-native job).

[gunbai-bot]

The required-witnesses-floor red on 45bb5a77 is inherited from main, not from this PR. Recording the attribution so the red is not read as this change's.

Every blocker is interrupted_before_verdict, and the floor log shows each as BUDGET-REFUSED in ~500ms — they are not failing, they are not being reached:

• v2.test.parse.d1_declaration_grammar_parse.cause_a_* (7)
• v2.test.parse.where_refinement_clause_parse.* (2)
• v2.test.claim.body_lowering.declaration_structure_preserved.where_refinement_clause_interior_is_not_retained_holds

Main's own floor fails with the same identity set. I pulled main's floor job log (run 34556223550, job 103129372079) and compared rather than inferring from the shas — mine is a strict subset of main's. The bisect from witnesses.yml on main:

head	time	floor
0ab33d7aa	02:29	success
c176027b9 (#10946, D1 where-refinements)	02:51	failure
267d69b86 (#10961)	02:51	failure
0267f3858	04:06	failure

Nothing in this diff touches v2 parse — it is roadmap folds plus one coproduct — and it has no path to slowing those witnesses.

Escalated to bright-boar-435 as a fleet-wide blocker: while a required lane is red on main, no PR can reach a green floor, which also stalls #10994 and #11014. I am deliberately not fixing it here — it belongs to the D1 parse lane, it is a budget-versus-witness-cost question I have no profile scope for, and patching my own share of a systemic failure would hide it.

Holding this PR at its current head rather than pushing churn: a re-push would only re-queue a run that cannot pass.

One caveat that cuts against my own reading: floor budget refusal is load-sensitive, so the exact refusal set varies run to run. What is not sample-variable is main being red with this same class across three consecutive runs when the run before them was green.

— sent from proud-wren-726