feat(validator,generate,run): an identifier a proposal builds on must be in the input, or the verdict falls [skip-docs]

P6 (økt 108) ended in ValidatedProposal (verdict 5fd6272e3725fe68) on two cost
codes -- M-04-01 / M-04-03 -- that appear in NO prompt of that run. Measured
here first, verbatim: validate_proposal(p, baseline=None) validates it; the same
proposal against any non-empty CostBaseline is rejected naming both codes.

So the hole was never "fabrication goes uncaught" -- _reconcile_against_baseline
exists and is right -- but that the falsifier is reached only through
`if baseline is not None`. The input always exists; the baseline does not.

New stage 0b (_ground_against_input), OUTSIDE the baseline branch, after stage 0
so an anchored run's message is byte-identical to before. ONE Rejection, the
validator's own type, naming EVERY ungrounded identifier "; "-joined in the
proposal's own order (økt 94's completeness reason).

The rule has NO pattern -- `code in grounding`, exact substring -- and that is a
measurement: over the delivered corpora (K2 1108 files / 2 005 561 chars, the
three N payloads 8 excerpts each) the identifier forms are heterogeneous, and a
pattern chosen to cover them would be a rule about shapes. Bare numerals are the
one inert class (46 394 occurrences / 2 117 distinct in K2); the rule fails OPEN
there, never closed.

Evidence is three non-model-authored sources: what run_project DELIVERED (the
rendered cut/pointer/chunks plus the base's context_files -- never files, which
would make the type: verdict layer evidence), the project's own cost lines, and
the baseline's codes when anchored. The rendered PROMPT is deliberately NOT
evidence, on two measurements: gen_context IS the debate output on the S2c path,
and from attempt 2 the prompt carries the previous Rejection.reason verbatim --
which for this stage QUOTES the identifier it just refused. Grounding in the
prompt would let the gate's own refusal disarm it on its second round.

Prose scanning was chosen against WITH THE NUMBERS: a typed gate catches 2/2
(P6) and 2/2 (S7c) -- 100% of what reached a verdict. What stays uncaught, said
plainly: an ungrounded identifier that lives only in agent/debate prose and never
becomes an affected_item code (2 of 4 P6, 2 of 4 S7c, 1 of 2 P4).

Iron Law: 9 red / 2 green before the rule existed. Ten mutations all red against
the whole suite, green control 1558 passed / 5 skipped (from 1543/5, superset,
0 removed), golden demo-transcript.stdout BYTE-UNCHANGED (shasum -a 1 of the
CONTENT = ea8c534773acdbe41ae68f2c55724d69aaf8be4f).

Three existing fixtures changed, no gate weakened -- most of all
test_pre_amendment_bundle_runs_unchanged, which sent the SAME FABRICATED code and
asserted it validated: the økt-108 hole written down as an expectation.

No paid run. Order 20260909T113641Z-38938691-from-.claude.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

tests/fixtures/p7-grounding/p4-n100-generation-prompt.txt

@@ -0,0 +1,7 @@
+Propose ONE concrete cost-saving measure for this project.
+Project: N100 - N100
+Context (prior verdicts / cited cost docs):
+A concrete cost-saving measure based on the N100 requirements is to avoid grade-separated (planskilt) crossings between pedestrian/cycle paths and roads when the road has an ÅDT of 4,000 or less. According to Krav 3.3.1—13, planskilt crossings are required only if ÅDT > 4,000, so using at-grade crossings under this threshold reduces construction costs while still complying with N100.
+
+Respond with ONLY a JSON object for a SavingsProposal with keys: project_id, measure, affected_items (list of {code, quantity, unit_cost}), claimed_saving_nok, and optional assumptions.
+Each entry in affected_items must restate a cost line as the project's price schedule already carries it: quantity and unit_cost are the unchanged baseline figures, not the reduced quantity or unit cost your measure would produce. The effect of the measure belongs in claimed_saving_nok.

tests/fixtures/p7-grounding/p6-k2-generation-prompt.txt

@@ -0,0 +1,11 @@
+Propose ONE concrete cost-saving measure for this project.
+Project: K2 - K2
+Context (prior verdicts / cited cost docs):
+A concrete cost-saving measure for K2 in the Stange skole extension project is to optimize the marking (merking) process for technical systems by reducing the extent and complexity of permanent engraved marking where possible, and instead use durable pre-printed adhesive labels or supplier-marked components. Since the general technical requirements specify extensive engraving and permanent marking for all components, including those above and below ceilings, and full coordination with documentation, this can be costly in labor and materials.
+
+By standardizing label types, using supplier pre-marked equipment, minimizing marking in hard-to-access or low-maintenance areas, and avoiding duplicated markings, the project can reduce marking time and material costs without compromising operational functionality or compliance. Close coordination early in the project between RITB, system integrators, and TE can finalize an efficient marking plan that meets requirements with lower cost.
+
+This measure addresses a specific and detailed area described in the technical requirements and has potential to save substantial costs related to labor time, materials, and rework during installation.
+
+Respond with ONLY a JSON object for a SavingsProposal with keys: project_id, measure, affected_items (list of {code, quantity, unit_cost}), claimed_saving_nok, and optional assumptions.
+Each entry in affected_items must restate a cost line as the project's price schedule already carries it: quantity and unit_cost are the unchanged baseline figures, not the reduced quantity or unit cost your measure would produce. The effect of the measure belongs in claimed_saving_nok.

tests/fixtures/p7-grounding/s7c-k2-generation-prompt.txt

@@ -0,0 +1,9 @@
+Propose ONE concrete cost-saving measure for this project.
+Project: K2 - K2
+Context (prior verdicts / cited cost docs):
+A concrete cost-saving measure for K2 is to focus on streamlining the extensive prøvedrift (trial operation) phase described in the general technical requirements. This phase involves many integrated tests, monthly coordination meetings, continuous updating of logs, and the risk of automatic extensions if systems are not fully functional. 
+
+By enhancing upfront coordination, ensuring all systems meet acceptance criteria before starting prøvedrift, and reducing repeated tests through better planning and quality control, the project can minimize costly delays and reduce resource consumption for testing and defect resolution. This approach cuts down on contractor hours and administrative overhead, resulting in tangible cost savings without compromising the project's technical quality or safety.
+
+Respond with ONLY a JSON object for a SavingsProposal with keys: project_id, measure, affected_items (list of {code, quantity, unit_cost}), claimed_saving_nok, and optional assumptions.
+Each entry in affected_items must restate a cost line as the project's price schedule already carries it: quantity and unit_cost are the unchanged baseline figures, not the reduced quantity or unit cost your measure would produce. The effect of the measure belongs in claimed_saving_nok.