[P0] Remove qualification-repository tuning from production retrieval and claims

[mohanagy]

Parent: #649
Depends on: #655, #659

Outcome

Restore scientific and product independence between Madar’s production retrieval/context behavior and the repositories/tasks used to qualify it.

Remove or generalize exact status-page/OpenStatus-era paths, symbols, phrases, boosts, forced selections, demotions, and fixed claim builders from production code. Add a protected boundary preventing qualification knowledge from returning.

Confirmed evidence

The v0.32.1 audit found production behavior tied to concepts including:

• packages/api/src/router/statusPage.ts;
• trpc.statusPage.get.queryOptions;
• HTTPCheckerHandler;
• UpdateStatus();
• cloudtasks.NewClient;
• CreateTask;
• status-page projection/incident semantics;
• exact preferred/forced candidate patterns and score boosts;
• status-specific fallback demotions.

The repository name itself may not appear. The coupling is encoded through exact paths, symbols, concept arrays, ranking fragments, and fixed claim builders.

Matching strings can change selection, ranking, retained lines, or generated claims in unrelated repositories. Existing tests currently protect some special cases rather than proving general behavior.

Scope

1. Complete production audit

Search production code for direct and indirect qualification knowledge, including:

• exact repository names;
• exact paths or normalized path suffixes;
• symbol-name arrays;
• task phrases and aliases;
• hard-coded scoring boosts/demotions;
• preferred/forced files;
• status-specific expected phases;
• fixed context claims;
• benchmark-specific task classifiers;
• path/symbol fragments encoded in regexes/templates/case variants.

Classify each occurrence as:

• production ranking/candidate generation;
• production graph expansion;
• production execution-path logic;
• production claim generation;
• production implementation guidance;
• production fallback;
• legitimate generic framework behavior;
• test/fixture;
• benchmark/documentation;
• dead code.

For every production occurrence record activation condition, behavior impact, unrelated-repository risk, tests, and replacement/removal decision.

2. Remove, generalize, or quarantine

• Remove exact repository/task dependencies from general production ranking and claim generation.
• Replace behavior only when a generic typed signal is justified by non-benchmark evidence.
• Generic replacements may use typed route/controller/queue/consumer/dataflow facts, direct source evidence, evidence quality, or registered framework semantics.
• Do not replace one exact string list with a disguised synonym list.
• Preserve benchmark documentation and fixtures only in approved benchmark/test locations.
• Existing tests should be rewritten to verify generic semantics rather than exact qualification artifacts.

3. Add benchmark-independence boundary

Create a versioned forbidden-knowledge manifest covering:

• qualification repository names;
• exact paths;
• symbols;
• task phrases;
• normalized fragments;
• known aliases.

Protected scanning should cover production source and detect, where practical:

• string/template/regex literals;
• path fragments across slash/case variants;
• camel/snake/kebab normalization;
• symbol arrays;
• score/preference tables;
• manually preferred files;
• claim-builder constants.

Allow benchmark, fixture, test, and documentation locations through an explicit allowlist.

Exceptions require:

• owner;
• generic product justification;
• non-benchmark tests;
• review approval;
• expiry/revalidation date.

Failure output must identify file, line, rule, and normalized match.

4. Add independence tests

At minimum:

• unrelated repository containing similar strings must not receive fixed claims without typed evidence;
• a hidden/renamed status implementation must still work where generic facts support it;
• removing a qualification literal must not be replaced by task-text overfitting;
• hidden holdout quality must remain non-inferior;
• direct source evidence is required for high-confidence repository-specific claims.

Explicit non-goals

• No broad retrieval rewrite.
• No discretionary ranking redesign beyond removal/generalization of contaminated rules.
• No graph architecture changes.
• No new framework support.
• No vector/embedding initiative.
• No benchmark prompt changes to accommodate regressions.
• No accepting a known regression merely because special cases are undesirable; expose and track the underlying generic capability gap.

Replacement standard

A special rule may be replaced with a generic behavior only when:

1. the generic concept is defined independently of the benchmark repository;
2. at least one non-qualification fixture exercises it;
3. a holdout verifies generalization;
4. the behavior is evidence-backed and source-attributed;
5. it does not synthesize repository-specific claims from matching names alone.

Otherwise remove the rule and create a separate capability issue rather than preserving hidden overfitting.

Required tests and validation

• forbidden-manifest scanner positive/negative fixtures;
• exact known production occurrences detected before removal;
• approved test/docs allowlist;
• unrelated-string collision fixture;
• renamed/hidden implementation holdout;
• retrieval/context-pack differential review;
• no unexplained critical-fact regression;
• no production match for the forbidden manifest;
• complete protected suite and qualification gates.

Acceptance criteria

• Every identified qualification-specific production occurrence is classified and resolved.
• No exact qualification repository path, symbol, phrase, or equivalent encoded special case remains in production without an approved generic exception.
• Fixed status-specific claim builders are removed or replaced by typed evidence-backed generic behavior.
• Similar strings in an unrelated repository cannot trigger repository-specific claims.
• A hidden/renamed holdout demonstrates that generic behavior does not depend on the original literals.
• The protected independence scanner blocks reintroduction and reports actionable failures.
• Exceptions are narrow, reviewed, tested outside the qualification repository, and expiring.
• Critical-fact and unsupported-claim quality is non-inferior on the frozen independent corpus.
• No benchmark prompt/truth was changed to mask a production regression.
• All global protected gates pass.

Rollback

Any rollback reintroducing a qualification-specific production rule must also mark affected benchmark evidence invalid and block public generalization claims. Prefer disabling the generic replacement behind a documented feature flag over restoring exact repository knowledge.

Agent handoff

Begin with the full occurrence inventory and commit it to the PR description. Do not modify production behavior until each occurrence has a classification and replacement/removal plan. Report all output differences, hidden-holdout results, scanner coverage, and unresolved generic capability gaps.

[mohanagy]

Approved amendment — mechanically enforce the runtime-proof.json retrieval/grader boundary

This Wave-1 finding belongs inside #660 rather than in a duplicate standalone issue.

docs/benchmarks/suite/methodology.md currently states that runtime-proof.json is grader-only and is not passed to retrieval or the answering agent, but that separation is not mechanically enforced. Because the file contains per-repository expected symbols and paths, an accidental import/read from production retrieval, context compilation, prompt construction, or answer generation would contaminate qualification evidence.

Add the following mandatory work to #660:

Scope

• inventory every read/import/reference to docs/benchmarks/suite/runtime-proof.json and its derived values;
• define an explicit grader-only boundary and ownership contract;
• prevent production retrieval, context-pack compilation, prompt construction, MCP/CLI normal paths, and agent-answer inputs from reading or receiving grader truth;
• add a protected architecture/independence test that fails when grader-truth modules or paths become reachable from production modules;
• keep benchmark judging capable of reading the file only after the answer/context artifact is frozen;
• ensure receipts identify the rubric/truth version without embedding hidden expected paths into the Madar input arm;
• document any historical receipt invalidation caused by a proven boundary violation.

Acceptance criteria

• Every current runtime-proof.json consumer is classified as grader, harness control, documentation/test, or prohibited production use.
• No production retrieval/context/prompt module can import, read, or receive runtime-proof.json expectations.
• A negative architecture test deliberately attempts the prohibited dependency and fails with an actionable message.
• Grader access occurs only after the run output is fixed and is represented separately in the receipt.
• Existing qualification-repository literals and this grader-boundary check are covered by the same protected benchmark-independence gate.
• No benchmark prompt or truth file is weakened to make the boundary pass.

This amendment is part of #660's P0 independence outcome and should be completed before evidence from the affected benchmark family is treated as untuned product evidence.

[mohanagy]

Maintainer decision — dependency amendment and qualification limits for #660

Recorded before any implementation work begins. This comment amends the
dependency line stated in the issue body (Depends on: #655, #659) and fixes the
claim boundary for the work.

1. Dependency state

Issue	State	Role for #660
#655	Completed (merged as PR #681, 9fd8e02c5605021d195f7b456d3cdee1e13a5c4e)	Provides the frozen natural qualification contract — the frozen natural repositories, independent rubrics, and stop rule that #660 regresses against without editing.
#658	Merged (PR #714, b892eafc916c8dfaddff13e585c901ebee187afe)	Provides the graph-integrity foundation — normalized candidate accounting and retained unresolved facts, i.e. the typed evidence #660's generic replacements are allowed to depend on.
#659	Closed as not planned	Its narrow publication-boundary approach failed; it was not completed and is not being represented as completed.

Amendment: #659 is no longer a prerequisite for #660. The Depends on: #655, #659 line in the issue body is superseded by Depends on: #655, #658. Both remaining dependencies are merged and are ancestors of the #660 base commit.

History is not rewritten: #659 remains closed as not planned, with its rejected approach on record.

2. Explicit scope exclusions carried by this amendment

• [P0] Remove qualification-repository tuning from production retrieval and claims #660 does not implement answerability propagation. Capping or propagating answerability from graph-integrity state is out of scope here and is not silently absorbed into this issue.
• [P0] Remove qualification-repository tuning from production retrieval and claims #660 must not reuse any code from rejected PR feat(context-pack): cap answerability from graph-integrity state (#659) #725. That PR's approach was rejected; none of its implementation is to be carried forward, adapted, or renamed into [P0] Remove qualification-repository tuning from production retrieval and claims #660.
• [P0] Add independent Tier 1 graph, retrieval, Pack, and negative-trust evaluation #661 remains the owner of the executable independent Tier 1 evaluator. [P0] Remove qualification-repository tuning from production retrieval and claims #660 does not build it, and does not claim its results.

3. Qualification limitation — what #660 may and may not claim

#660 may establish:

• removal of all identified qualification-specific production behavior;
• a protected reintroduction boundary (versioned forbidden-knowledge manifest + protected scanner);
• an enforced runtime-proof / grader separation;
• non-regression on the available frozen natural fixtures;
• unrelated-repository negative behavior (similar strings do not trigger repository-specific results);
• renamed/hidden implementation behavior working through generic typed evidence.

#660 may not claim:

• full product generalization;
• a genuinely hidden human-owned holdout;
• completion of Tier 1;
• zero false-ready outcomes;
• release readiness;
• public Native-vs-Madar superiority.

Those remain downstream work, owned primarily by #661, #662, and #663.

4. Truth-preservation constraint

Frozen qualification truth, prompts, repository pins, and expected answers must not be modified to make #660 pass. A production output difference is reported and classified; it is never resolved by editing the frozen contract.

The independence scanner delivered by #660 is a regression boundary, not proof of generalization. It detects practical encoded reintroduction (case/slash/camel/snake/kebab variants, path fragments, string templates, regex literals, preferred-symbol arrays, score/preference tables). It does not detect arbitrary semantic overfitting, and will not be described as doing so.

[mohanagy]

Stage 0 contract — #660 Remove qualification-repository tuning from production retrieval and claims

Base ref: origin/next
Base SHA: fb1cd5d2946e5dddaa98354c9c232360859bc98b
Base tree: 3c328d8f5db90ccf72df786667f2e2cda16e92c1
Branch: roadmap/660-benchmark-independence
Size class: medium (DESIGN review required)

---

1. The record and the constraints it binds

• Parent epic [Epic] Phase 0 — Stabilize trust foundations and qualification gates #649.
• Dependencies as amended in the maintainer-decision comment above: [P0] Freeze the natural qualification corpus, independent rubrics, and stop rule #655 (merged 9fd8e02c…) and [P0][Graph PR C] Account for every normalized graph candidate and retain unresolved facts #658 (merged b892eafc…). Both merge commits are verified ancestors of the base. [P0][Graph PR D] Cap answerability from graph-integrity state #659 is closed as not planned and is no longer a prerequisite.
• [P0] Remove qualification-repository tuning from production retrieval and claims #660 does not implement answerability propagation, must not reuse any code from rejected PR feat(context-pack): cap answerability from graph-integrity state (#659) #725, and does not own the Tier 1 evaluator ([P0] Add independent Tier 1 graph, retrieval, Pack, and negative-trust evaluation #661).
• Frozen qualification truth, prompts, repository pins, and expected answers are read-only for this issue.
• The independence scanner shipped here is a regression boundary, not proof of generalization. It detects practical encoded reintroduction; it does not detect arbitrary semantic overfitting, and will not be described as doing so.

2. Reproduction at the exact base

Three controls were run against fb1cd5d2 inside the issue worktree. All three demonstrate live contamination.

CONTROL A — unrelated logistics repository, no typed edge between the nodes.
Input: two nodes in services/logistics/… named .HTTPCheckerHandler() and UpdateStatus(), with snippets containing Status: "error", cloudtasks.NewClient(, .CreateTask(. No relationships supplied — there is no typed edge between them.
Base output (verbatim):

failure detection: services/logistics/handlers/scan.go .HTTPCheckerHandler() sends Status "error" to UpdateStatus
cross-runtime handoff: services/logistics/ledger/update.go UpdateStatus() enqueues the checker status update with Cloud Tasks

Two high-confidence repository-specific claims — including the words "the checker status update" — synthesised from matching names alone.

CONTROL B — unrelated marketing CMS.
Input: bannerEntries() in apps/marketing/src/content/banner.ts and bannerRouter.ts in packages/cms/src/router/banner.ts.
Base output (verbatim):

public payload divergence: when barType is not manual, an open incident event can make page.status "error" in
packages/cms/src/router/banner.ts; apps/marketing/src/content/banner.ts builds unresolved incident entries only
from page.statusReports, so an auto-created incident without a status report can yield an error indicator with
an empty incidents list

An entire status-page failure narrative asserted about a banner router.

CONTROL C — one identifier decides line retention, structure held constant.
Two files, byte-identical except for the router name:

type Feed = NonNullable<RouterOutputs["<router>"]["get"]>;
export async function buildFeed(slug: string) {
  const data = await loadFeed(slug)
  const summary = toSummary(data)
  await feedQueue.enqueueFeedUpdate({ slug, summary })
  return summary
}

Base output:

router name	retained snippet
statusPage	L1: type Feed = NonNullable<RouterOutputs["statusPage"]["get"]>; + L2 + L5
billingPage	L2 + L5 only — L1 dropped

retrieve.ts:1136-1138 bypasses the low-value-line filter only for lines matching the exact literal RouterOutputs…["statusPage"]…["get"]. Renaming the router deletes the evidence.

3. Complete affected class — the occurrence inventory

Derived by a normalized scan (slash direction, case, camel/snake/kebab, regex-escape unescaping, contiguous-token subsequence match) over all 200 production src/**/*.ts files: 37 prohibited matches, in exactly 3 production files, 0 false positives, 18 of 20 manifest rules firing. The two silent rules (apps/checker/update.go, apps/status-page/src/content/status-json.ts) are fixture-only paths retained as reintroduction guards.

Behaviour legend: CG candidate generation · RK ranking · GX graph expansion · LR line retention · FB fallback · CL claim generation · IG implementation guidance.

3.1 src/runtime/context-pack.ts — claim generation

ID	Declaration (lines)	Literal / encoded trigger	Activation condition	Behaviour	Current tests	Unrelated-repo collision risk	Decision
CP-1	buildStatusProjectionSplitClaims (426–443)	pageIndicator(page.status), page.statusReports, /e\.type\s*===\s*["']incident["']/, /barType\s*!==\s*["']manual["']/	two selected nodes whose snippets match	CL — one fixed multi-clause claim	context-pack.test.ts:353–406	Confirmed (CONTROL B)	remove
CP-2	buildPublicStatusRuntimeProvenanceClaims (445–487)	/\btrpc\s*\.\s*statusPage\s*\.\s*get\s*\.\s*queryOptions\b/, /(?:^|\/)packages\/api\/src\/router\/statusPage\.ts$/, to(Status|Summary|UnresolvedIncidents)(data, e.type==='incident', barType!=='manual'; alternate selector on overall status+status report+maintenance	two selected nodes whose snippets/paths match	CL — fixed claim naming an exact upstream path	context-pack.test.ts:408–457	Confirmed — exact-path forced claim	replace → CP-R1
CP-3	buildFailureHandoffClaims (489–516)	/HTTPCheckerHandler/ on label, /\bUpdateStatus\s*\(/, /\bStatus\s*:\s*["']error["']/, label === 'UpdateStatus()', /\bcloudtasks\.NewClient\s*\(/, /\.CreateTask\s*\(/	two selected nodes matching	CL — two fixed claims	context-pack.test.ts:459–499	Confirmed (CONTROL A)	replace → CP-R1
CP-4	buildClaims wiring (517–545)	—	always	CL ordering	above	—	update
CP-5	buildInputProvenanceClaims + ROUTER_OUTPUT_PROVENANCE_PATTERN (388–424)	RouterOutputs["<any>"]["<any>"] — router and procedure extracted from the source	any node snippet	CL	context-pack.test.ts:309–345	none — names come from the source, not a table	retain (generic) — declared tRPC framework support (src/pipeline/spi/framework-trpc.ts, SPI v1 #83)

3.2 src/runtime/retrieve.ts — line retention and ranking

ID	Declaration	Literal / encoded trigger	Activation	Behaviour and magnitude	Collision risk	Decision
RT-1	QUERY_EVIDENCE_PAGE_RESULT_PATTERN (701)	/\bpage\w*(?:indicator|status)\w*\s*\(|\bstatus\s*:\s*page\w*\s*\(/	any evidence line	LR — dedicated semantic slot (1212, 1251)	high (page-prefixed helpers are common)	remove
RT-2	QUERY_EVIDENCE_PAGE_COLLECTION_PATTERN (702)	/\breturn\s+page\.\w+/	any evidence line	LR — slot (1213, 1252)	high — collides with return page.granulePosition shapes	remove
RT-3	QUERY_EVIDENCE_INCIDENT_STATUS_PATTERN (704)	/\b\w+\.type\s*===?\s*["']incident["'][^\n]*!\w+\.to|…/	any evidence line	RK +2.4 (1094); LR fragment builder (867); slot (1214, 1253); container-declaration filter (1366)	high	remove
RT-4	QUERY_EVIDENCE_MONITOR_ROLLUP_PATTERN (705)	/\bstatus\s*=\s*monitors\.some\s*\(/	any evidence line	RK +2.0 (1097); slot (1215, 1254)	high	remove
RT-5	QUERY_EVIDENCE_INPUT_PROVENANCE_PATTERN (706)	/\bRouterOutputs\b.*\[\s*["']statusPage["']\s*\].*\[\s*["']get["']\s*\]/	any evidence line	RK +2.5 (1100); LR low-value-filter bypass (1137); slot (1216, 1255)	Confirmed (CONTROL C)	replace → RT-R1
RT-6	QUERY_EVIDENCE_PUBLIC_ROUTER_FETCH_PATTERN (707)	/\btrpc\s*\.\s*statusPage\s*\.\s*get\s*\.\s*queryOptions\b/	any evidence line	RK +4.0 — the single largest boost in the file (1103); LR fragment builder (829); slot (1209, 1248)	Confirmed	replace → RT-R2
RT-7	QUERY_EVIDENCE_DISCRIMINANT_PROPERTY_PATTERN (728)	property alternation containing incident, monitor beside generic action|event|method|mode|notification|queue|route|status|type|url	structured-call fragment scan (759)	LR	medium	remove the two domain nouns, keep the generic set
RT-8	incidentStatusOwnerFragment (847–909)	RT-3 + /^\s*const\s+status\s*=/ + .map( + return { + status,/events,	fragment construction (935)	LR — highest-priority fragment shape	high	remove (exists only to serve RT-3)
RT-9	publicRouterFetchFragment (823–845)	RT-6 + /\b(?:const|let)\s+\w+\s*=\s*await\s+\w+\.fetchQuery\s*\(/	fragment construction (936)	LR	Confirmed	generalize with RT-R2
RT-10	container-declaration filter (1363–1368)	gated on RT-3	post-selection filter	LR	high	remove
RT-11	createTask inside QUERY_EVIDENCE_HANDOFF_PATTERN (694), …DELIVERY_HANDOFF… (695), …PROVIDER_HANDOFF… (729)	createTask verb	any evidence line	RK +1.6 / +1.5; LR provider-handoff fragment	medium	remove — named in the issue's confirmed evidence; siblings enqueue|dispatch|publish|send|emit|trigger|deliver remain

3.3 src/runtime/retrieve/conceptual-fallback.ts — fallback and anchor ranking

ID	Declaration	Qualification fragments	Generic fragments kept	Behaviour	Decision
CF-1	LOW_VALUE_OWNER_PATH_PATTERN (112)	\/lib\/http\/etag\.[^/]+$, statusPage\.utils\.[^/]+$, \/content\/markdown\/	\.pb\.go$, (?:_pb|\.pb)\.ts$, \/(?:errors?|limits)\.[^/]+$	FB flow-owner admission refusal (465); RK −2.0 anchor adjustment (804); lowValueOwner signal (947)	remove the three qualification fragments
CF-2	LOW_VALUE_OWNER_LABEL_PATTERN (113)	computeETag\(\)?$, validate\w*Access\(\)?$, statusLabel, statusGlyph, generate\w*	Error\(\)?$, (?:create)?ErrorResponse, Limits?\(\)?$, (?:assert|check)?\w*Quota\(\)?$	same three sites; RK −2.0 (−0.75 when the prompt is explicitly about errors)	remove the qualification symbol names

3.4 Examined and classified NOT contamination (legitimate generic framework behaviour)

Recorded so a reviewer can check the boundary rather than take it on trust.

Construct	Why it is generic
PRESENTATION_LABEL_PATTERN ^page\s+\/ (conceptual-fallback.ts:108)	Matches Madar's own emitted label: label: \page ${info.routePath}`atsrc/pipeline/extract/frameworks/next.ts:696`. This is a declared Next.js route-label convention, not upstream repository knowledge.
RUNTIME_PATH_PATTERN, CORE_BEHAVIOR_OWNER_PATH_PATTERN, PERSISTENCE_PATH_PATTERN, PRESENTATION_PATH_PATTERN	Generic architecture directory names (api, handlers, services, db, components), independent of any repository.
promptWants* / promptExpects* predicates (retrieve.ts:2446–2504, 3072)	Generic architecture vocabulary matched against the user's own prompt; no repository literal.
Execution-phase taxonomy (controller, auth_guard, validation, service, queue, worker, persistence, …)	Generic layered-architecture concepts.
buildInputProvenanceClaims / ROUTER_OUTPUT_PROVENANCE_PATTERN (CP-5)	tRPC is a declared framework in Madar's SPI; the router and procedure names are captured from the source, not from a table. Same class as the Hono adapter: declared framework support ≠ qualification-task knowledge.
src/infrastructure/benchmark/**, src/infrastructure/compare.ts	Benchmark harness / grader, not production retrieval. Covered by the grader-boundary rule in §4 rather than by the literal rules.

4. Grader / runtime boundary — docs/benchmarks/suite/runtime-proof.json

Every read, import, and derived use at the base:

Consumer	Classification
src/infrastructure/benchmark/runtime-proof.ts — loadBenchmarkRuntimeProofProfiles, matchBenchmarkRuntimeProofProfile	grader loader (the only reader of the file)
src/infrastructure/compare.ts:5916 — loadBenchmarkRuntimeProofProfiles(input.questionsPath)	benchmark harness control
compare.ts:4350 missingRuntimeProofCitations, :5104 assessNativeAgentPromptContract, :1841–2059 merge*	grader — all consume the profile after the answer text exists
src/contracts/runtime-proof.ts, src/contracts/context-pack.ts:14 (RuntimeProofAssessment)	type-only import; carries no values
tests/unit/benchmark-suite.test.ts, compare-native-agent.test.ts, compare.test.ts, benchmark-suite-isolation-docs.test.ts, qualification-contract.test.ts	test
docs/benchmarks/suite/methodology.md, docs/qualification/*, CHANGELOG.md	documentation
production retrieval (src/runtime/retrieve*.ts, context-pack*.ts), prompt generation (buildMadarPromptPack), CLI/MCP normal paths	none — no reachability

Proof of the current boundary. buildMadarPromptPack (compare.ts:2741–2781) is the only compare export reachable from the MCP server (src/runtime/stdio/tools.ts:3). It builds its prompt from compactRetrieveResult(input.retrieval) and input.question only; it never receives a RuntimeProofProfile, and loadBenchmarkRuntimeProofProfiles is called solely from the runCompareCommand grading flow keyed on input.questionsPath.

Prohibited-reachability finding. The boundary holds structurally but is unenforced. docs/qualification/evidence-categories.md records this verbatim as an "Open enforcement gap in E3": "That isolation is asserted in prose. No test, lint rule, or CI check enforces it." Closing that gap is in scope for #660 (§11-E of the assignment).

Grader truth may be consumed only after the answer/context output is fixed. A receipt may identify the rubric/truth version; it may not place expected paths, symbols, or answers into the Madar arm.

5. Authoritative owner per behaviour

Behaviour	Single owner after the change
Repository-specific claim synthesis	buildTypedRelationshipClaims in context-pack.ts — the only claim builder allowed to assert a relationship between two nodes, and only from a registered graph edge
Router-output provenance claim	buildInputProvenanceClaims (unchanged, generic)
Query-evidence line scoring	the single queryEvidenceRange scoring block in retrieve.ts
Query-evidence fragment shapes	queryEvidenceFragments in retrieve.ts
Low-value owner suppression	LOW_VALUE_OWNER_* in conceptual-fallback.ts
Independence enforcement	src/shared/benchmark-independence.ts (new) — one scanner, one manifest

6. Exact source boundary

Production files that may change (5; ceiling without a human gate is 6):

1. src/runtime/context-pack.ts
2. src/runtime/retrieve.ts
3. src/runtime/retrieve/conceptual-fallback.ts
4. src/shared/benchmark-independence.ts (new — scanner engine)
5. src/contracts/benchmark-independence.ts (new — manifest types; folded into (4) if it stays small)

Non-production files that may change: docs/qualification/forbidden-knowledge.json (new manifest), scripts/verify-benchmark-independence.mjs (new CLI wrapper), package.json (one script entry), tests/**, docs/**, CHANGELOG.md.

Out of bounds: every other src/** path, src/infrastructure/compare.ts, the graph artifact schema, the extraction pipeline, docs/benchmarks/suite/** (frozen), docs/qualification/corpus.json|tasks.json|rubrics.json|receipt-schema.json|patches/** (frozen). A diff outside this boundary is scope expansion → HUMAN_GATE-660-SCOPE.

7. Compatibility boundary

• ContextPackClaim shape unchanged (evidence_class, text, node_labels).
• CompiledContextPack shape unchanged; claims ordering rule preserved (typed-relationship claims, then input-provenance, then per-evidence-class).
• QueryEvidenceSnippet shape unchanged.
• readQueryEvidenceSnippet / compileContextPack / retrieveContext signatures unchanged except buildClaims gaining the already-computed relationships argument — an internal function, not exported.
• The graph artifact, its schema version, and the relation-discriminator registry are untouched.
• Frozen qualification digests in docs/qualification/freeze.json must remain byte-exact; npm run qualify:validate proves it on all six lanes.

8. Determinism requirements

Risk	How it is pinned
Claim ordering	typed-relationship claims sorted by (relation, from, to) with a stable tiebreak; never by Map/Set iteration
Relationship iteration	relationships is already a deterministic array from filterRelationships; sorted explicitly before claim emission
Path separators	every path compared after replaceAll('\\','/'); the scanner normalizes slash direction in both directions
Case / locale	scanner lowercases with the invariant toLowerCase(), never toLocaleLowerCase(); no locale-sensitive localeCompare on scanner output
Line endings	scanner splits on /\r?\n/; reported line numbers are 1-based and CRLF-invariant (proved by a CRLF fixture)
File ordering	scanner walks with a sorted readdir, so the report is byte-identical across platforms
Timestamps / randomness	none introduced

9. Controls

Negative controls — must FAIL at fb1cd5d2 and PASS after. All three are reproduced above with verbatim base output.

ID	Control	Base result
N1	Unrelated logistics repo with no typed edge receives no cross-runtime handoff / failure detection claim	FAILS — both claims emitted
N2	Unrelated marketing CMS receives no public payload divergence claim	FAILS — claim emitted
N3	Router name alone does not change the retained line set (structure held constant)	FAILS — statusPage retains L1, billingPage drops it
N4	Scanner reports zero prohibited production matches	FAILS — 37 matches in 3 files
N5	A production module importing or reading runtime-proof.json fails with an exact actionable reason	FAILS — no such check exists (the recorded E3 enforcement gap)
N6	High-confidence repository-specific claims require direct or structural source evidence; matching names alone are insufficient	FAILS — N1/N2 are the counterexamples

Positive controls — must never regress.

ID	Control
P1	Scanner detects every base occurrence when run against a checked-in verbatim excerpt fixture (37 matches, 3 files, 18 rules)
P2	Scanner reports zero matches on a generic negative-control fixture that contains similar-but-unrelated names
P3	Encoded-variant fixtures are detected: back-slashes, upper/lower case, status_page, status-page, StatusPage, path fragments, string templates, regex literals, symbol arrays, score/preference tables
P4	Malformed manifest entries are rejected (missing owner/justification/expiry, value normalizing to fewer than 2 tokens, duplicate id, a rule that is a subsequence of another)
P5	A broad exception (empty/*/directory-wide value, or one missing a non-qualification test reference or expiry) is rejected
P6	Renamed/hidden implementation: a qualification-shaped execution flow whose every path and symbol is renamed still produces the correct execution claims and evidence, carried by registered graph relations (handles_route, calls, enqueues_job, …) — proving the replacement does not depend on the retired literals
P7	Existing generic pack/retrieval/fallback suites stay green: context-pack*, retrieve*, retrieve-conceptual-fallback, retrieve-cross-layer-flow (rewritten to generic semantics), mcp-response-evidence
P8	npm run qualify:validate (all six lanes), typecheck, build, release:verify, npm pack --dry-run

10. Replacement design

CP-R1 — buildTypedRelationshipClaims(nodes, relationships) replaces CP-2 and CP-3.
For each ContextPackRelationship whose relation is in a registered execution-relation set (handles_route, route_handler, controller_route, registers_route, mounts_router, submits_route, loads_route, declares_controller, registers_controller, middleware, guards, uses_guard, intercepts, calls, enqueues_job, provides) and both endpoints are selected nodes, emit one source-attributed claim naming both endpoints, their files, and the registered relation. No literal names, no repository knowledge, no synthesized semantics — the claim states only the typed fact the graph carries.

Against the five-part replacement standard:

1. Concept independent of the qualification repository — the relation vocabulary is REGISTERED_RELATIONS in src/contracts/relation-discriminator.ts, delivered by [P0][Graph PR C] Account for every normalized graph candidate and retain unresolved facts #658.
2. Existing typed source signal — graph edges admitted through the relation-discriminator registry.
3. Non-qualification fixture exercises it — the controller-service-test-flow and monorepo-package-boundary pack-quality fixtures, plus the renamed/hidden fixture P6.
4. Source-attributed — every endpoint carries its source_file and label from the graph.
5. Similar names cannot trigger it — an actual admitted edge is required; N1 supplies the matching names without the edge and must produce nothing.

RT-R1 replaces RT-5: QUERY_EVIDENCE_ROUTER_OUTPUT_PROVENANCE_PATTERN = RouterOutputs\s*\[\s*["'][^"']+["']\s*\]\s*\[\s*["'][^"']+["']\s*\] — any router and procedure. Same signal CP-5 already uses generically; keeps the low-value-filter bypass and the score contribution, now name-independent. N3 is the control.

RT-R2 replaces RT-6: QUERY_EVIDENCE_CLIENT_PROCEDURE_FETCH_PATTERN = a client fetching a typed remote procedure — \b\w+\s*\.\s*\w+\s*\.\s*\w+\s*\.\s*(?:queryOptions|mutationOptions)\b — with publicRouterFetchFragment renamed clientProcedureFetchFragment and generalized identically. The +4.0 boost is not carried over: it was tuned so one fixture line would win, it is the largest single boost in the file, and applying it to every tRPC query line on every repository is an unexplained ranking effect I cannot justify. It is reduced to the value used by the other structural signals. If that costs a critical fact on the frozen corpus, the difference is reported and classified under §13 of the assignment — it is not restored.

Removals (CP-1, RT-1, RT-2, RT-3, RT-4, RT-7 nouns, RT-8, RT-10, RT-11, CF-1, CF-2 fragments) are removals, not renames. If a removal exposes a missing generic capability, the gap is recorded in the #660 final report; no issue is created automatically and no special rule is restored to preserve an old expected output.

11. Independence manifest and scanner

Manifest — docs/qualification/forbidden-knowledge.json, versioned, one entry per rule:
{ id, kind, value, origin, rationale } where kind ∈ { path, symbol, phrase, regex_literal, string_literal, production_read }.
kind narrows where a rule may match, which is what makes a rule like return page. usable without colliding with legitimate code such as return page.granulePosition.

Normalization applied to both the rule value and each production line: \\ → /; regex shorthand classes (\b \s \w \d \S \W \D \n \t) dropped; remaining \x unescaped; camel/Pascal boundaries split; lowercased; split on non-alphanumerics. A rule matches when its token sequence appears as a contiguous subsequence of the line's token sequence. This is what gives slash-direction, case, and camel/snake/kebab invariance for free, and it is the measurement that produced the 37/3/0 figures in §3.

Coverage: all of src/**/*.ts. Allowlisted (never scanned): tests/**, docs/**, examples/**, scripts/**, .github/**, and the manifest itself.

Failure output: exact file, 1-based line, rule id, and the normalized match — the actionable form required by the issue.

Exceptions require owner, generic product justification, a named non-qualification test, review evidence, and an expires date; the scanner rejects an exception missing any of these, and rejects broad values. No exception is introduced for any current status-page/OpenStatus-specific production rule. The candidate ships with zero exceptions.

Grader-boundary rule (kind: production_read): any src/runtime/** or src/pipeline/** module that imports benchmark/runtime-proof, references runtime-proof.json, or imports infrastructure/compare for a value (not a type) fails with the exact reason and the remediation.

Wiring: the scanner runs as a vitest test (therefore on all six protected lanes, via test:run on five and test:coverage on ubuntu/22) and additionally as npm run verify:benchmark-independence for local and release use.

12. Mutation plan

Each new control must catch its mutation; a surviving mutation means the control is decorative.

#	Mutation	Control that must fail
M1	Re-add statusPage to any production regex	N4 / P1
M2	Re-add it as status_page, status-page, StatusPage, or packages\\api\\src\\router\\statusPage.ts	P3
M3	Re-add it inside a template literal or a new RegExp('…') string	P3
M4	Re-add it as an array of preferred symbols or a Record<string, number> score table	P3
M5	Restore buildFailureHandoffClaims verbatim	N1
M6	Restore buildStatusProjectionSplitClaims verbatim	N2
M7	Make buildTypedRelationshipClaims emit when the relation is absent (name match only)	N1 / N6
M8	Import loadBenchmarkRuntimeProofProfiles into src/runtime/retrieve.ts	N5
M9	Read docs/benchmarks/suite/runtime-proof.json from context-pack.ts	N5
M10	Re-narrow QUERY_EVIDENCE_ROUTER_OUTPUT_PROVENANCE_PATTERN back to a fixed router name	N3
M11	Add a manifest exception with no owner / no expiry / no non-qualification test	P4 / P5
M12	Widen the allowlist to cover src/runtime/**	P5

Fault injection is bounded to M1, M8, and M6 (one forbidden literal, one grader read, one restored claim builder), run individually and reverted. No generalized mutation program is built.

13. Performance / size gates

None required, and none claimed. No formal performance receipt, no 72-run or 480-run agent experiment, no saturated whole-suite claim. The change removes regex tests and adds a bounded relationship walk over an already-materialized array; the scanner runs only in test/CI, never at retrieval time. npm pack --dry-run and release:verify bound package size and hygiene.

14. Explicit non-goals

Broad retrieval rewrite · discretionary ranking redesign beyond removal/generalization · graph architecture or artifact-schema change · answerability propagation (#659's retired subject) · any reuse of PR #725 · new framework support · vector/embedding work · the executable independent Tier 1 evaluator (#661) · a genuinely hidden human-owned holdout · benchmark prompt, truth, pin, or rubric edits · child issues · architecture issues · release or publish activity · touching #716, #719, #721 or any unrelated retained worktree.

15. Evidence invalidation rules

Artifact	Invalidated by a change to
scanner base-occurrence report	the manifest, the scanner engine, or any file under src/**
N1–N3 collision/renaming controls	context-pack.ts, retrieve.ts, conceptual-fallback.ts, or their fixtures
N5 grader-boundary control	the scanner engine, src/runtime/**, src/pipeline/**, or src/infrastructure/compare.ts
frozen-corpus validation	docs/qualification/** or docs/benchmarks/suite/** (both frozen — any change is itself a blocker)
focused output differentials	any of the three production retrieval files

Docs-only commits do not reset candidate.productionChangingHead.

16. Rollback

git revert of the single squashed commit restores all three production files, deletes the manifest, the scanner, and the new fixtures. Blast radius: claim text and evidence-line selection for explain-class packs; no artifact, schema, or API change, so no reindex and no migration. Per the issue's rollback clause, any rollback that reintroduces a qualification-specific production rule must also mark affected benchmark evidence invalid and block public generalization claims; the documented preference is to disable the generic replacement behind a flag rather than restore exact repository knowledge.

17. Prior-art search

Searched	Found	Reused?
Remote branches matching 660	none	—
Open/closed PRs referencing 660	#626, #681, #634, #709 — all merged, none implements #660	no
PR #725 (roadmap/659-integrity-answerability-cap)	closed/rejected; narrow publication-boundary approach	no — explicitly prohibited
Existing scanners for a reusable shape	.github/scripts/verify-release-hygiene.mjs, validate-qualification-contract.mjs	shape and CLI conventions reused; no logic copied
Existing typed evidence for the generic replacement	REGISTERED_RELATIONS (src/contracts/relation-discriminator.ts, from #658); tRPC SPI (src/pipeline/spi/framework-trpc.ts); Next.js route labels (src/pipeline/extract/frameworks/next.ts:696)	yes — this is the replacement substrate
Prior contamination source	docs/benchmarks/2026-07-17-openstatus-activation/ — the run the rules were tuned against	context only; the frozen #655 corpus does not include that repository

18. What #660 will and will not claim

Establishes: removal of all identified qualification-specific production behaviour; a protected reintroduction boundary; an enforced runtime-proof/grader separation; non-regression on the available frozen natural fixtures; unrelated-repository negative behaviour; renamed/hidden implementation behaviour through generic evidence.

Does not establish: full product generalization; a genuinely hidden human-owned holdout; Tier 1 completion; zero false-ready outcomes; release readiness; public Native-vs-Madar superiority. Those remain #661, #662, #663.

[mohanagy]

DESIGN review verdict — DESIGN-HOLD-660

Reviewed head: fb1cd5d2946e5dddaa98354c9c232360859bc98b (tree 3c328d8f5db90ccf72df786667f2e2cda16e92c1), clean worktree, no production edit made.
Reviewer thread: 01a0539b-fd99-7383-898d-d381cad5dd9f (fresh DESIGN session, gpt-5.6-sol, reasoning xhigh, read-only).

DESIGN-HOLD-660 — the plan preserves qualification knowledge, replaces it with disguised tuning, cannot isolate grader truth, or requires broader architecture

Work stopped at the HOLD. No redesign, no second reviewer session, no child issue, no architecture issue. All three findings were independently re-verified against the code before this record was written; all three are real.

---

Finding 1 (Q1 completeness / Q3 truthful removal) — the inventory is incomplete

The Stage 0 inventory covered literal qualification knowledge (exact paths, symbols, encoded regex fragments) and found 37 matches in 3 files. It missed an entire class: qualification knowledge encoded as task-phrase matching on prompt obligation terms, which carries no repository literal and therefore cannot be found by the normalized literal scan.

Location	What it does
src/runtime/retrieve/conceptual-fallback.ts:1059	obligation.terms.includes('public') && obligation.terms.includes('page') gates a file-owner ranking preference
src/runtime/retrieve/conceptual-fallback.ts:1189, :1196	the same public + page term pair gates publicFileOwnerOrder and publicOwnerGrounding
src/runtime/retrieve/conceptual-fallback.ts:1230-1240	forced HTTP-boundary reservation for obligations carrying that same term pair — "A public status computation is incomplete without the HTTP boundary that fetches and serializes it"
src/runtime/retrieve/conceptual-fallback.ts:1308+	cross-runtime forced selection — keeps one lifecycle-shaped owner from a second runtime scope, tuned to the Go-checker → TS-workflow shape of the qualification run
src/runtime/retrieve.ts:5923	slice-v1 bypass gated on preserveConceptualObligationOrder, which that recovery mode sets
src/runtime/retrieve/conceptual-fallback.ts:1921	+1.5 obligation-coverage adjustment that lets obligation coverage outweigh a drop in local cluster coherence

The originating prompt was "…and affects the public status-page status…". public + page is that prompt's phrase, not a generic architecture concept. This is precisely the "task phrases and aliases" and "forced/preferred selection" contamination the issue requires to be inventoried, and the Stage 0 contract did not list it.

Finding 2 (Q4 grader isolation / Q5 scanner bounding) — the proposed production_read rule is unshippable and insufficient

The contract proposed failing any src/runtime/** or src/pipeline/** module that imports infrastructure/compare for a value. That rule fires on existing, legitimate production code:

• src/runtime/stdio/tools.ts:3 — import { buildMadarPromptPack } from '../../infrastructure/compare.js', used at :2195 (the MCP context-prompt path).
• src/infrastructure/context-prompt-command.ts:3 — the same value import, used at :98 (the normal CLI prompt path). The Stage 0 grader-boundary table missed this consumer entirely.

Because src/infrastructure/compare.ts:38 imports ./benchmark/runtime-proof.js, the grader loader is in the module graph of both normal paths. The current isolation is a property of which functions are called, not of what is reachable. A text-matching rule cannot prove transitive isolation, so §11-E ("inject a production import or read of runtime-proof.json and require failure with an exact actionable reason") is not satisfiable by the proposed design.

Finding 3 (Q6 scope) — the six-file production boundary cannot hold

Making grader isolation structurally enforceable requires extracting buildMadarPromptPack out of src/infrastructure/compare.ts into a module that does not import the runtime-proof loader, and repointing its production importers. Combined with Finding 1's additional retrieval work, the minimum production surface is:

#	File	Why
1	src/runtime/context-pack.ts	fixed claim builders
2	src/runtime/retrieve.ts	scoring, slots, fragments, slice-v1 bypass
3	src/runtime/retrieve/conceptual-fallback.ts	low-value patterns + the Finding 1 class
4	src/shared/benchmark-independence.ts (new)	scanner engine
5	src/contracts/benchmark-independence.ts (new)	manifest types
6	src/infrastructure/compare.ts	extract the prompt-pack builder
7	src/infrastructure/prompt-pack.ts (new)	grader-free prompt path
8	src/runtime/stdio/tools.ts	repoint the import
9	src/infrastructure/context-prompt-command.ts	repoint the import

Nine production files against a ceiling of six.

---

Gate

HUMAN_GATE-660-SCOPE — the six-file boundary cannot hold (assignment §9). Per §9 a split is proposed, not executed; no issue was created and no work was started.

Proposed maximum-two-PR split (both remain inside #660; neither is a new issue):

PR 1 — grader/runtime separation and the independence boundary.
Extract buildMadarPromptPack into a grader-free module; repoint src/runtime/stdio/tools.ts and src/infrastructure/context-prompt-command.ts; add the versioned forbidden-knowledge manifest and the protected scanner, including a module-graph reachability rule (not a text rule) proving no production entry point can reach benchmark/runtime-proof; controls N4, N5, P1-P5.
Production files: 5 — compare.ts, new prompt-pack.ts, stdio/tools.ts, context-prompt-command.ts, new benchmark-independence.ts.
This closes the "Open enforcement gap in E3" recorded in docs/qualification/evidence-categories.md.

PR 2 — remove and generalize the contaminated retrieval and claim rules.
The full inventory including Finding 1's task-phrase class; the buildTypedRelationshipClaims replacement; controls N1, N2, N3, N6, P6, P7.
Production files: 3 — context-pack.ts, retrieve.ts, retrieve/conceptual-fallback.ts.

State at the gate

• Base unchanged: fb1cd5d2946e5dddaa98354c9c232360859bc98b, tree 3c328d8f5db90ccf72df786667f2e2cda16e92c1.
• Worktree .claude/worktrees/issue-660 on roadmap/660-benchmark-independence: clean, zero commits, zero production edits.
• Frozen qualification truth, prompts, repository pins, expected answers: untouched.
• No PR opened. No issue created. No other issue started. [P0] Add independent Tier 1 graph, retrieval, Pack, and negative-trust evaluation #661 not started. [P0][Graph/SPI] Collision-safe semantic identity: locale must not decide which value survives #716 / [P0] Locale-dependent semantic selection and identity across persisted state #719 / [P0][Graph/SPI] Host-independent selection: order nine graph-affecting comparators by code point #721 untouched. No release activity.

[mohanagy]

Maintainer decision — #660 delivered as two bounded PRs under one issue

Recorded at HUMAN_GATE-660-SCOPE. The maintainer approved the scope split proposed in the DESIGN-HOLD record, with corrected ownership.

No new issue is created. #660 remains one GitHub issue, delivered through two sequential PRs. #660 stays open after #660-A merges.

The DESIGN-HOLD-660 verdict on thread 01a0539b-fd99-7383-898d-d381cad5dd9f stands as issued. It is not rewritten as a GO. The split follows directly from its three verified findings:

Verified finding	Consequence for the split
1. The inventory missed a task-phrase contamination class (obligation.terms.includes('public') && …('page') gating ranking at conceptual-fallback.ts:1059/1189/1196 and a forced HTTP-boundary reservation at :1230-1240, plus cross-runtime forced selection at :1308+, the slice-v1 bypass at retrieve.ts:5923, and the +1.5 obligation adjustment at :1921)	Widens the retrieval decontamination surface → #660-B
2. The proposed production_read text rule fires on existing legitimate value imports (stdio/tools.ts:3 used at :2195; context-prompt-command.ts:3 used at :98), and compare.ts:38 puts the grader loader in the transitive module graph of the MCP and CLI normal paths	Grader isolation must be structural, proved from the compiler's module graph, not text → #660-A
3. Fixing (2) requires extracting the prompt-pack builder out of compare.ts and repointing its importers; with (1) that is 9 production files against a ceiling of 6	Two bounded slices instead of one oversized PR

---

#660-A — grader/runtime structural isolation (this session)

Owns: the structural separation between normal product prompt/context construction and qualification grader truth.

Normal Madar product paths must not import, read, receive, or transitively reach grader truth — docs/benchmarks/suite/runtime-proof.json and the production module that loads or interprets it. Today's separation is a call-graph property only; #660-A replaces it with module separation, enforced by a guard built on the TypeScript compiler's actual module resolution working outward from the grader module, with an exact, justified grader/benchmark allowlist.

Production boundary: 5 files maximum — src/infrastructure/compare.ts, src/runtime/stdio/tools.ts, src/infrastructure/context-prompt-command.ts, a neutral prompt-pack owner module, and at most one further module if proven necessary for exact dependency separation.

#660-A is a dependency-boundary change, not a product-output change. Prompt-pack output parity before and after extraction is a blocking requirement; no retrieval, claim, evidence, ranking, token-budget, or answerability field may change.

#660-B — production retrieval and claim decontamination (not started)

Owns: literal qualification contamination; task-phrase-driven qualification contamination; ranking boosts and demotions; forced candidate selection; fixed claim builders; the complete forbidden-knowledge manifest and production scanner; unrelated-string and renamed-implementation behaviour.

Why the full scanner does not ship in #660-A

Known contaminated production rules still exist during #660-A. Activating the complete literal/normalized scanner now would require temporary exceptions for behaviour already known to be invalid, and a scanner shipped with exemptions for the current status-page/OpenStatus rules would be a false boundary. #660-A carries only the architecture guard needed for grader/runtime separation. The full manifest and scanner land in #660-B, after or together with the production removals.

Claim boundary, unchanged

#660-A establishes an enforced runtime-proof/grader separation. It does not establish full product generalization, a genuinely hidden human-owned holdout, Tier 1 completion, zero false-ready outcomes, release readiness, or public Native-vs-Madar superiority. Those remain #661, #662, #663.

[mohanagy]

FINAL review verdict — HOLD-PR660A (second HOLD, returning to maintainer)

FINAL thread: 01a05428-eb6d-77d0-bc82-cd0a7d906a96 (fresh session, distinct from DESIGN 01a0539b-fd99-7383-898d-d381cad5dd9f, gpt-5.6-sol, reasoning xhigh, read-only).
Candidate reviewed: 23cb43bfdcec9a960a6e468496cb424c80f05496 (tree 45062aec59182118730beb90d768cdad9be01af1).

The one permitted bounded correction is spent. Per the #660-A contract §13 a second HOLD returns immediately to the maintainer, so no further fix was attempted and no third reviewer session was opened.

---

Round 1 — HOLD, corrected

Finding. scripts/lib/grader-boundary.mjs recognised a dynamic-import specifier only when it was a StringLiteral. TypeScript parses a backtick specifier with no substitutions as a NoSubstitutionTemplateLiteral, which ts.isStringLiteral rejects. Verified directly:

import(`./x.js`)  -> FirstTemplateToken | isStringLiteral: false | isNoSubTemplate: true
import("./y.js")  -> StringLiteral      | isStringLiteral: true  | isNoSubTemplate: false

So import(`./benchmark/runtime-proof.js`) from a normal-product module was a real runtime edge the guard never saw while reporting green.

Correction. A literalSpecifier() helper now resolves every statically known form — StringLiteral, NoSubstitutionTemplateLiteral, both unwrapped through parentheses and as const — for dynamic import(), require(), and import-equals. Control G7 injects the reviewer's exact shape and was verified non-decorative: with the fix temporarily reverted it reports "injection did not create the expected edge … the control proves nothing".

Fixing only the reported shape would have left the adjacent hole open, so computed specifiers were gated too (control G8). That gating is what round 2 found wanting.

Also corrected in the same round — protected CI on 177fba26. Four of six lanes passed; the new boundary step passed on all six. Both Windows lanes failed on one test:

FAIL tests/unit/prompt-pack-parity.test.ts > produces byte-identical prompt packs …
AssertionError: expected '{\n  "normal_context_prompt": …' to be '{\r\n  "normal_context_prompt": …'

Mine, not a product defect: git rewrote the golden fixture's newlines at checkout. Fixed by pinning the fixture to text eol=lf (the convention this repo already uses for the qualification freeze and *.madar) and normalising line endings on both sides of the comparison.

Round 2 — HOLD, not corrected

Question 2 fails. scripts/lib/grader-boundary.mjs:393 keys computed-import allowances only by file path, and :397 consequently approves every computed import in the file allowlisted at docs/architecture/grader-boundary.json:62. Thus any additional computed import in src/runtime/semantic.ts can target the grader loader while the boundary check remains green.

The finding is correct, and I proved it rather than taking it on trust. A third computed import was injected into src/runtime/semantic.ts resolving to ../infrastructure/benchmark/runtime-proof.js:

GUARD ok= true  violations= 0
computed count= 3
restored exactly: True

The guard stayed green with a computed grader import present in normal product code. The worktree was restored by digest-verified byte snapshot; git status is clean.

Root cause. allowedComputed.get(entry.file) grants a whole-file exemption. src/runtime/semantic.ts is legitimately allowlisted for its two optional-dependency loads, and that allowance silently covers any future computed import in the same file. The allowance is coarser than the thing it is allowing.

Impact bound, stated honestly. No such import exists today — the file's two computed specifiers both resolve to @huggingface/transformers outside src/**, and every other guarantee in the PR holds. This is a weakness in the new guard's precision, not a live reachability path. But the guard's entire value is that it cannot be quietly widened, and a whole-file exemption is exactly the widening it was built to prevent, so it should not ship as-is.

The obvious fix is small — pin each allowance to the specifier text or the resolved target rather than the file, and add a control that a second, different computed import in an already-allowlisted file is still refused. I have deliberately not applied it: the correction budget is spent, and applying a third change without review is precisely the loop the contract exists to stop.

---

Protected CI on the candidate — 6 of 6 green

Run 33331881277 on 23cb43bf:

Lane	Result
validate (ubuntu-latest, Node 20)	pass (attempt 2)
validate (ubuntu-latest, Node 22)	pass
validate (macos-latest, Node 20)	pass
validate (macos-latest, Node 22)	pass
validate (windows-latest, Node 20)	pass
validate (windows-latest, Node 22)	pass
CodeRabbit	pass

The Verify grader/runtime structural boundary step executed on every lane. The Windows CRLF failure from the previous candidate is gone.

Attempt 1 on ubuntu Node 20 is reported, not superseded. It failed on one test, tests/unit/stdio-server.test.ts > keeps MCP control requests responsive while another process holds the refresh lease, timing out at 10009ms against a 10000ms limit — a 9-millisecond margin on a timing-sensitive concurrency test about a lease held by another process. Recorded as signature occurrence 1 (controlled_rerun_permitted) before rerunning; only that lane was rerun; no tracked file changed between attempts.

What makes the transient reading plausible, recorded as evidence rather than as a conclusion: the identical production code passed this same lane on the previous candidate 177fba26; the delta 177fba26..23cb43bf contains no src/** change whatsoever; the same test passed on the other five lanes of the same run; and the failure is a timeout, not an assertion. If this signature recurs it is a defect to investigate, not a flake.

---

State at the gate

Base SHA	fb1cd5d2946e5dddaa98354c9c232360859bc98b (unmoved)
Candidate SHA	23cb43bfdcec9a960a6e468496cb424c80f05496
Candidate tree	45062aec59182118730beb90d768cdad9be01af1
PR	#730, open against next, not merged, merge state BLOCKED (awaiting review approval)
Worktree	clean, local equals remote
Production files	4 of a permitted 5 — prompt-pack.ts (new), compare.ts, stdio/tools.ts, context-prompt-command.ts. The correction round touched zero production files.
Frozen qualification truth	unchanged — qualify:validate reports the same 21 frozen files
Correction rounds used	1 of 1
Reviewer sessions	2 (one DESIGN, one FINAL). No third opened.
Protected CI	6 of 6 green on the candidate, after one declared controlled rerun of one lane

What is proven on this candidate, and what is not

Proven. The prompt-pack builder no longer sits in the grader module: context-prompt-command.ts, stdio/tools.ts, stdio-server.ts and the new prompt-pack.ts are all off the grader graph, leaving 7 approved grader/benchmark/dispatcher ancestors. Prompt-pack output is byte-identical to a golden captured at the base commit across five shapes. Controls G0–G4 and G6–G8 pass; the direct-import, transitive-helper, re-export, template-literal, computed-specifier and direct-JSON-read attacks are all refused with the exact reason. Sequencing is verified from the syntax tree. typecheck, build, qualify:validate, release:verify, npm pack --dry-run all clean.

Not proven. That the computed-specifier allowance cannot be widened within an already-approved file — the open finding above.

Never claimed. Full product generalization, a hidden human-owned holdout, Tier 1 completion, zero false-ready outcomes, release readiness, or public Native-vs-Madar superiority. Removing qualification-repository knowledge from retrieval and claims is #660-B, not started; #660 remains open.