WASM-002 adversarial QA review — Pass 3 gate verification

Issue carried into Pass 3

The multi-Store MAP clause added under F-05 let an alias update from an older MAP drop another Store from current state, so the next routine run would fork it.

What the Council decided

One Store MAP file holds exactly one Store lineage (one rid_filename, one source_filename). Current state is chosen per lineage. Historical-base operations affect only their own lineage. Exact-source routing: none → new Store; one → that lineage; more than one → refuse and require an explicit MAP (§3).

What holds under attack

• The disappearance path is gone. Store B's state now lives only in Store B's own MAP history, so nothing published for Store A can remove it (§3.4–3.5). The Pass 2 scenario fails at its first step.
• The single-source predicate, the F-04 cardinality gate and the no-positional-join rule carry over unchanged (§3.3). The Join MAP boundary is clean (§3.7).
• This matches Revision BL's own schema. W002-STOR-019.6 and 019.9 already require every row to repeat one rid_filename, so the withdrawn clause was the anomaly.

What does not yet hold

• The ambiguity exit in §3.6 and historical-base materialization in §3.5 need a MAP clause in the materialization Work Order. §4.4 does not provide one. See P3-01.
• The routing word "eligible" in §3.6 must cover DEGRADED and INVALID lineages, and a lineage whose every MAP is damaged is not covered. See P3-07.

Revision BL requirements affected

W002-STOR-010.1, W002-STOR-019.1, W002-STOR-019.2, W002-STOR-019.9, W002-WKO-012.3, W002-UI-ACC-016

Integration consequence

As listed in §3.10. Also remove store_source_filename, which is still in W002-STOR-019.2 (routing), 019.6, 019.8, 019.9, 019.12, W002-MAT-ACC-002.1, W002-WKO-012.6, W002-STEPS-008 and W002-UI-ACC-017.

Residual

None of its own. Its reachability depends on P3-01.

Issue carried into Pass 3

The F-08 grammar made WORK ORDER AS mandatory and dropped trailing comments, contradicting Revision BL and F-02 without saying so.

What the Council decided

WORK ORDER AS is mandatory, appears exactly once, is non-empty, and applies to every operation. Revision BL's trailing-comment rule is retained. The superseded text is listed (§4).

What holds under attack

• Both questions now have explicit decisions with named supersessions (§4.6), which is what Pass 2 asked for.
• The comment rules match W002-STEPS-001.2 exactly: first # outside quotes, # inside quotes is content, and comment bytes are part of WKO identity (§4.3). The canonical W002-STEPS-001 example is valid again.
• A mandatory alias fits the three-column WKO MAP and removes the empty-alias special case from registry repair.

What does not yet hold

• §4.4 re-freezes the materialization structure without the optional MAP clause that Revision BL W002-WKO-012.3 provides and P2-01 depends on. The defect is in this text, but it is not the P2-02 question, so it is reported as P3-01.

Revision BL requirements affected

W002-STEPS-001, W002-STEPS-001.1, W002-STEPS-001.2, W002-STOR-018.2, W002-MAT-ACC-002.3, W002-MAT-ACC-002.4

Integration consequence

§4.8 lists the core rewrites. The optional-alias wording also survives in W002-STOR-018 ("optional immutable Work Order content"), 018.2 ("the empty string when no alias is declared"), 018.3 ("its optional Work Order alias"), W002-STEPS-001 ("the optional immutable human-facing WKO alias"), W002-UI-023 ("optional WORK ORDER AS") and the canonical INVENTORY form in W002-INV-001, which has no alias.

Residual

None of its own. Fix P3-01 in the same §4.4 text.

Issue carried into Pass 3

Pass 2 residual: registry repair could not be reached when the registry was stale. Material residuals: DEPRECATED Run eligibility, WKO validity predicate, WKO MAP row order, and the missing operation token.

What the Council decided

Bounded bootstrap: while the registry is repair-required, a saved repair-only WKO may Run by exact filename without being registered. The decision also defines the discovery rules, a structural-validity predicate, the three-column WKO MAP serialization, DEPRECATED Run by exact filename only, and the REPAIR_WORK_ORDER_REGISTRY token (§5).

What holds under attack

• The bootstrap is narrow and honest. It needs a visible, saved, immutable repair-only WKO; it runs by exact filename; no other operation gains eligibility; and Save does not pretend the registry is healthy (§5.2–5.3). The Pass 2 deadlock is broken.
• All four material residuals are answered: DEPRECATED runs by exact filename only (§5.7); structural validity is separate from runtime success (§5.5); rows sort by wko_filename (§5.6); and the token exists (§5.8). F-14's missing WKO predicate is answered by §5.5 as well.
• Discovery keeps the no-winner-by-time principle (§5.4).

What does not yet hold

• Nothing defines when the registry counts as repair-required. Revision BL's rule for choosing the current WKO MAP would make a stale MAP non-current and silently revert alias authority. See P3-03.
• §5.5 requires a WKO to parse under "exactly one defined operation grammar", but the INVENTORY, UPDATE ALIASES and CONVERT structures are still unfrozen (F-08 material). Until they are, registry repair cannot classify copied-in WKOs of those kinds.

Revision BL requirements affected

W002-STOR-018.2, W002-STOR-018.3, W002-STOR-018.4, W002-UI-023

Integration consequence

As listed in §5.10, plus the W002-STOR-018.4 current-selection rewrite from P3-03.

Residual

MATERIAL: P3-03. The blocking residual is closed.

Issue carried into Pass 3

Pass 2 residuals: REPAIR MAP had no target, repairing a Store whose every COL was broken would erase it, and "untrustworthy MAP means INVALID" conflicted with the malformed-newer-MAP fallback.

What the Council decided

MAP structural validity is separate from Store health. Only structurally valid MAPs compete for current state, and malformed newer MAPs fall back. VALID, DEGRADED and INVALID are evaluated, not persisted. REPAIR MAP names the exact current MAP, and it refuses when the Store is not DEGRADED or when repair would leave zero COLs. Damaged lineages route to refusal, never to re-creation (§6).

What holds under attack

• The validity/health split (§6.1) removes the INVALID-versus-fallback conflict. §6.9's three cases form a usable oracle, and "don't fall back to hide present damage" is the right principle.
• REPAIR MAP now has an exact target. The target must be current and DEGRADED; historical and wrong-profile targets refuse; and Data Sculptor, not the analyst, decides which bindings are broken (§6.6–6.7).
• The all-COLs-broken case refuses without inventing an anchor row (§6.8). Status is evaluated rather than stored (§6.4). Routing treats damage as refusal, not absence (§6.10).

What does not yet hold

• An INVALID Store, or a DEGRADED Store with every COL broken, blocks its source filename indefinitely, and Help is not given the exit. See P3-05.
• "Exact original restored byte-for-byte" cannot be checked from what the MAP records. Validation depth (P2-04) now determines REPAIR MAP output. See P3-06.
• A lineage whose only MAP is damaged becomes invisible to routing and forks. See P3-07.

Revision BL requirements affected

W002-STOR-019.10, W002-STOR-019.11, W002-RID-009, W002-RID-010, W002-STEPS-010, W002-RCP-011

Integration consequence

As listed in §6.12.

Residual

MATERIAL: P3-05, P3-06, P3-07; P2-04 remains open. The blocking questions are closed.

Issue carried into Pass 3

Pass 2 residual: CSV refusal-location facts and condition tokens were undefined, and the bare-CR rule was not scoped to unquoted context.

What the Council decided

Five governed facts and seven condition tokens, each with a location rule, a field-ordinal rule, first-condition precedence and window invariance. Bare CR refuses only outside quotes. EOF inside quotes refuses explicitly. Semicolon and tab files are not refused merely for their delimiter (§7).

What holds under attack

• The location oracle is exact. Offsets are absolute and include the BOM, physical lines count LFs, logical records include the header, and field ordinals are fixed for each condition (§7.1–7.4). I worked the edge cases: blank CRLF record, short last record with no terminator, doubled quotes, a CR straight after a closing quote, and a quote after leading whitespace. Each has one answer.
• Precedence follows source-byte order, with the right tie rules (§7.7). Byte coordinates line up with F-07 (§7.10).

What does not yet hold

• The facts are frozen, but no artifact is named to record them, and the MATERIALIZE Receipt table excludes them. See P3-02.
• None of the "exactly seven" tokens covers a source with no header record. See P3-09.

Revision BL requirements affected

W002-MAT-003.2, W002-MAT-ACC-003, W002-MAT-001.7

Integration consequence

As listed in §7.12, plus the P3-09 token.

Residual

BLOCKING through P3-02. MATERIAL: P3-09.

Issue carried into Pass 3

Pass 2 residual: the six-key envelope dropped Revision BL's core Receipt facts, MATERIALIZE, INVENTORY and REPAIR_MAP had no key tables, Inventory lacked per-file fields, and three-digit indices overflowed.

What the Council decided

The Revision BL core is restored and RECEIPT_UTC is defined. There are key tables for all six operations, a three-key Inventory entry, indices with a three-digit minimum and no maximum, a concrete fallback disclosure, and mandatory byte-exact fixtures (§8).

What holds under attack

• The envelope now matches Revision BL W002-RCP-006 plus RECEIPT_UTC, which is defined exactly (§8.2). The Pass 2 conflict is gone.
• Every executable operation has a table. Inventory carries all three W002-INV-003 fields plus the generating WKO and the Suitcase declaration (§8.10). Fallback disclosure is concrete (§8.8). Golden fixtures are required for all six operations and for INV (§8.15).
• I checked the arithmetic behind the no-maximum index rule: a 16,384-column Store-establishing run creates RID + 16,384 COLs + MAP = 16,386 artifacts, as §8.4 and §8.16 state.

What does not yet hold

• The MATERIALIZE key order is frozen as exact and has no slot for the F-06 and F-07 refusal facts. See P3-02.
• Refusal serialization still turns on "the applicable absence token". RESULT is an open set, UNKNOWN_OPERATION has no form, NOT_APPLICABLE is missing from §8.3, and some key names are given only by ellipsis. See P3-04.

Revision BL requirements affected

W002-RCP-005, W002-RCP-006, W002-RCP-007, W002-RCP-008, W002-RCP-011, W002-INV-003, W002-INV-006

Integration consequence

As listed in §8.17. W002-RCP-008 also still names RECOVER RID.

Residual

BLOCKING through P3-02. MATERIAL: P3-04.

Evidence

• E P2-02 §4.4 fixes the materialization form "in enforced order": SUITCASE, WORK ORDER AS, SOURCE, KEEP, selectors, MATERIALIZE. There is no MAP clause. Under Pass 1 log §11.6, any line not valid in the selected operation grammar refuses.
• E P2-01 §3.6: when more than one lineage matches the SOURCE filename, routing refuses and "the analyst must explicitly identify the intended valid Store MAP". §3.9 has a "Compatible explicit MAP" acceptance case. §3.5 lets historical Store A state be the input to "a later governed operation".
• E Revision BL W002-WKO-012.3: "For materialization, SOURCE "..." remains mandatory and an optional MAP "..." supplies the exact historical/current Store-state base." W002-STOR-019.1 and 019.2 rely on the same clause ("The analyst must explicitly select one valid MAP").
• E P2-02 §4.6 lists the Revision BL rules it supersedes. The W002-WKO-012.3 materialization clause is not among them, and P2-01 §3.10 asks to "reconcile" W002-WKO-012.3, not retire it.
• E The omission began in Pass 1 log §11.5, which lists the same six clauses. I missed it in Pass 2. P2-01 has now made it load-bearing.

Why it matters

• I Two frozen decisions in the same record disagree. Under §4.4, a materialization Work Order containing MAP "..." refuses as unknown syntax. Under P2-01, that clause is the only way out of an ambiguous route and the only way to materialize from historical Store state.
• I Integrated as written, an analyst whose Suitcase holds two lineages for crime.csv, for example after copying files in from another Suitcase, can never materialize crime.csv again. Routing refuses, and no valid Work Order can name the MAP.
• I The §3.9 "Compatible explicit MAP" and "Different source" acceptance cases cannot be written.

Impact if integrated as written. A routine routing refusal becomes a dead end, and an independent grammar test of §4.4 fails Revision BL's own canonical selector.

Question / direction for T. Add the clause to §4.4 with a frozen position and cardinality. For example: at most one MAP "<filename>" clause, immediately after SOURCE and before KEEP, binding the run to that Store lineage under P2-01 §3.3. If explicit MAP in materialization is instead being withdrawn, retire it from W002-WKO-012.3, W002-STOR-019.1 and 019.2 and give §3.6 a different exit. I recommend the first option. It is one line.

Evidence

• E F-09 §8.7: a MATERIALIZE Receipt serializes "these operation-specific facts in exactly this order". The list has STAGE1_UTF8_OUTCOME and the Stage 2 counts, but no location or reason fact.
• E F-06 §7.1: "Every structural CSV refusal records these governed facts": REFUSAL_CONDITION, SOURCE_BYTE_OFFSET, PHYSICAL_LINE, LOGICAL_RECORD, FIELD_ORDINAL. It does not say which artifact records them.
• E Pass 1 log §10.4: FIRST_INVALID_BYTE_OFFSET and STOP_REASON must be exposed "to the governed diagnostic/Receipt/Help path".
• E DGN is reserved-not-emitted (Pass 1 F-33), and HLP is written on a Help event. Revision BL W002-RCP-007: a refusal Receipt "records only facts that actually became known before refusal".
• E F-09 §8.15 requires byte-exact golden Receipts for the refusal forms of every operation.

Why it matters

• I The two most common MATERIALIZE refusals, invalid UTF-8 and malformed CSV, are exactly where F-06 and F-07 froze location oracles. As written, those oracles have no durable serialized home: the Receipt table excludes them, and no other emitted artifact is named.
• I An implementer must either break "exactly this order" or keep the facts only in on-screen Help. Either is an invention, and the golden refusal fixtures that §8.15 demands cannot be authored until someone decides.
• I The same gap exists on a smaller scale in CONVERT. A refusal for an undefined Windows-1252 byte (Pass 1 log §19.1) records no offset in the §8.14 table.

Impact if integrated as written. F-06's blocking residual, usable location facts, is closed on paper but not in any artifact a tester can compare bytes against.

Question / direction for T. Decide where the facts live. I recommend adding them to the MATERIALIZE table: the two F-07 facts after STAGE1_ELAPSED_MS, and the five F-06 facts after STAGE2_ELAPSED_MS, each carrying NOT_APPLICABLE when that refusal did not occur. Prefixed names such as CSV_SOURCE_BYTE_OFFSET keep them unambiguous. If they are meant to live only in Help or HLP, say so and name the artifact and field names. Settle the CONVERT undefined-byte offset at the same time.