WASM-002 adversarial QA review — Pass 2 reconciliation audit

Original issue (Pass 1)

An aliased WKO could not be edited and re-saved, the WKO MAP had no retirement path, and a missing or copied-in WKO left the registry deadlocked or ambiguous.

What the reconciliation changed

Three-column WKO MAP (wko_status, wko_alias, wko_filename); CURRENT/DEPRECATED; Replace alias target / Cancel at save; REPAIR WORK ORDER REGISTRY removes stale rows and registers unregistered valid WKOs (§7, §8).

Why it does or does not resolve the finding

• The alias-lifecycle half is genuinely closed: edit, re-save, supersede without deletion, one CURRENT per alias, no timestamp arbitration.
• The registry repair cannot be reached when it is needed. §8.7 says a registry-changing transaction must not bypass a stale row. Saving any WKO is a registry-changing transaction (W002-STOR-018.3 publishes a successor WKO MAP). §8.8 says an unregistered WKO is not a Run target. So when a registered WKO file goes missing, the analyst cannot save a Work Order containing REPAIR WORK ORDER REGISTRY, and cannot Run one unsaved or unregistered. The only exit is a pre-existing, registered, CURRENT repair WKO. The deadlock Pass 1 described is still there, one level down.
• Run eligibility of a DEPRECATED WKO is left open (§8.3: 'governed Run eligibility follows the current registry and other separately frozen Run rules' — no such rule exists). Can last month's superseded Work Order be re-run for reproduction? Unstated.
• 'Passes the governed WKO validity checks' (§8.8) has no defined predicate. F-14 deferred class-specific validity; nothing later supplied it for WKO.
• The §8.4 'physical CSV truth' example is not in any deterministic row order (neither by filename nor alias), contradicting W002-STOR-018.2 byte-order serialization, and freezes no replacement order. Its WKO filenames (…__D4.txt) are not valid UUID identities.
• REPAIR WORK ORDER REGISTRY has no Receipt OPERATION token in F-09 (§12.7 lists MATERIALIZE, INVENTORY, UPDATE_ALIASES, REPAIR_MAP, CONVERT only).

Revision BL requirements affected

W002-STOR-018, 018.1–018.4, W002-UI-020, W002-UI-023, W002-MAT-ACC-002.3, W002-MAT-ACC-002.4

Reconciliation log sections

§7, §8

Integration consequence

Rewrite W002-STOR-018.2 (schema, ordering, one-CURRENT invariant), 018.3 (save transaction with Replace/Cancel), 018.4 (current registry selection vs F-12); add registry-repair operation, grammar, Receipt token and gates.

Residual risk

BLOCKING: the repair deadlock. MATERIAL: DEPRECATED Run eligibility, WKO validity predicate, WKO MAP row order, missing OPERATION token.

Original issue (Pass 1)

A missing RID or COL made the whole lineage ineligible, so the next MATERIALIZE silently forked a new Store; the RID recovery base was undefined.

What the reconciliation changed

Three Store statuses (VALID, DEGRADED, INVALID). Missing/invalid RID is INVALID and terminal. Missing/invalid COL is DEGRADED; only REPAIR MAP is allowed, which drops broken COL bindings into a successor MAP. RID recovery retired. Ordinary materialization must not create a replacement Store for a DEGRADED or INVALID one (§3, §4, §7).

Why it does or does not resolve the finding

• The silent-fork path via ineligibility is closed for the single-Store-per-MAP reading: damage becomes an explicit status, and same-filename materialization refuses instead of forking.
• Lost COLs are now recoverable in two explicit steps (REPAIR MAP, then rematerialize from the same source under the F-04 gate). That is a clean improvement.
• REPAIR MAP has no target. §3.5 says the user names no MAP, Store alias or column, and 'Data Sculptor resolves the Store's current/latest governed MAP'. With several Stores in a Suitcase — and with F-05 allowing several Stores in one MAP — which Store is repaired? All DEGRADED Stores? Unstated.
• Repairing a Store whose every COL is broken deletes the Store. Store identity (rid_filename, store alias, source filename) exists only on COL rows (W002-STOR-019.6; F-05 §6.1). Removing all broken rows leaves no row for that lineage. The Store disappears from the MAP, and the next MATERIALIZE of the same source finds no lineage and creates a new Store — the exact silent fork F-03 was meant to close. The decision must refuse this case or keep a Store-level row.
• INVALID on 'untrustworthy current MAP' contradicts the malformed-newer-MAP fallback. W002-MAT-ACC-002 requires fallback to the greatest earlier valid MAP when a newer one is malformed; W002-STOR-019.10 says the same. F-03 §3.1 makes an untrustworthy current MAP INVALID and terminal. Which wins? Under F-05's multi-Store MAP, one corrupted file would make every Store in it terminal.
• 'Terminal' is not well defined. Status is not persisted anywhere; it is evaluated from file state. If a sync client finishes downloading the missing RID, the Store evaluates VALID again. Either 'terminal' means 'refused while the condition holds' (then say so) or status must be recorded (then say where).
• The depth of 'missing or invalid' checking is undefined. See P2-04.

Revision BL requirements affected

W002-STOR-019.2, 019.5, 019.8, 019.10, 019.11, W002-RID-001, 002, 008, 009, 010, W002-STEPS-010, W002-RID-ACC-005, W002-RCP-011, W002-MAT-ACC-002

Reconciliation log sections

§3, §4, §7

Integration consequence

Retire RID-009, RID-010, STEPS-010, RCP-011, RID-ACC-005 and the recovery clauses of RID-001/002/008, STOR-019.5/019.8/019.11, PB-STOR-013; add status, REPAIR MAP form, Receipt facts and gates.

Residual risk

BLOCKING: REPAIR MAP targeting; all-COLs-broken repair; INVALID vs fallback. MATERIAL: status persistence wording; validation depth (P2-04).

Original issue (Pass 1)

The source-to-MAP compatibility rule was cited but never defined, leaving join semantics to the implementer.

What the reconciliation changed

Single-source Store lineages; SOURCE must equal the lineage's common source_filename; no positional join; store_source_filename removed; one MAP may contain several Store lineages; Join MAP deferred (§6).

Why it does or does not resolve the finding

• The compatibility predicate itself is now exact and testable, and the no-positional-join rule is clear.
• The Store MAP schema is explicitly left unfrozen ('does not freeze the final complete Store MAP column set, column order, or serialization', §6.2, §6.5). W002-MAT-ACC-002.1 is a byte-exact gate; the integrator would be designing the schema. The §6.2 example also renames columns (col_filename, col_alias) and drops source_column_number and source_header, which W002-STOR-019.7 and RESET COL depend on.
• The multi-Store MAP clause is a new model with wide consequences. It is raised separately as P2-01.

Revision BL requirements affected

W002-STOR-019.3, 019.6, 019.9, 019.12, W002-WKO-012.3, W002-WKO-012.6, W002-WKO-ACC-008, W002-MAT-ACC-002.1

Reconciliation log sections

§6, §7

Integration consequence

Rewrite 019.6/019.9 schema and row-consistency rule; RESET STORE ALIAS restores the lineage source_filename; add compatibility and no-positional-join gates.

Residual risk

MATERIAL: freeze the column set and order (my reading: W002-STOR-019.6 minus store_source_filename, other names unchanged — the Council should confirm). BLOCKING via P2-01.

Original issue (Pass 1)

The CSV input grammar and malformed-input rules were not frozen, so refusal condition and location could not be independently derived.

What the reconciliation changed

Comma only; quote placement rules; LF/CRLF only, bare CR refuses; EOF termination; single trailing terminator; one-column ""; BOM only at offset 0 (§9).

Why it does or does not resolve the finding

• Cases (a)–(g) from Pass 1 now have answers. This is a real improvement.
• Refusal location is still unfrozen. §9.3 delegates location facts to F-07. F-07 (§10) froze only the UTF-8 invalid offset. Nothing states what a malformed-CSV refusal reports: byte offset of which byte, logical record ordinal, physical line, field ordinal. W002-MAT-003.2 and W002-MAT-ACC-003 require 'first refusal location' to be window-invariant, so the oracle is still missing.
• 'A bare CR ... refuses' (§9.1) is not scoped to unquoted context. W002-MAT-ACC-004 requires CR inside quoted values to round-trip. The rule must say 'outside a quoted field'.
• EOF inside an open quoted field is not listed explicitly as a refusal condition (it is implied).
• A semicolon-delimited file does not refuse: it parses as a valid one-column CSV. That is truthful under the profile, but Pass 1 asked which diagnostic tells the analyst; the answer is none, so Help for 'HEADER not found' should mention delimiters.

Revision BL requirements affected

W002-MAT-002.8, W002-MAT-003.2, W002-MAT-003.3, W002-MAT-ACC-003, W002-MAT-ACC-004, W002-MAT-ACC-005, W002-MAT-001.6

Reconciliation log sections

§9, §10.5

Integration consequence

Add a normative CSV input-profile requirement; scope bare-CR to unquoted context; add refusal-location facts; extend MAT-ACC-003/005 fixtures.

Residual risk

BLOCKING: define the CSV refusal-location facts and condition tokens.

Original issue (Pass 1)

The UTF-8 first-invalid offset had no defined meaning, and the error contract it cited was not in the cut.

What the reconciliation changed

Zero-based absolute offset of the first byte of the invalid sequence; lead byte for sequences invalidated later or truncated at EOF; window-independent; BOM bytes counted (§10).

Why it does or does not resolve the finding

• The offset oracle is now exact. For E2 82 41, E0 80 80, ED A0 80 and truncated sequences an independent fixture author gets one answer.
• STOP_REASON is named but its token set is not enumerated. W002-ENC-004.15 and Receipts need exact values (EVID-W001B-UTF8-006 used INVALID_UTF8_SEQUENCE). One token, or a taxonomy (invalid lead, invalid continuation, truncated at EOF)?
• The fact names are uppercase (FIRST_INVALID_BYTE_OFFSET) while W002-HELP-001.4 requires lowercase snake-case fact keys; the registry example uses byte_offset. Receipt keys and diagnostic fact keys need an explicit mapping.

Revision BL requirements affected

W002-ENC-004.10, W002-ENC-004.15, W002-ENC-ACC-006, 007, 008, 009, W002-HELP-001.4

Reconciliation log sections

§10

Integration consequence

Rewrite W002-ENC-004.10; enumerate STOP_REASON tokens; map Receipt keys to diagnostic fact keys.

Residual risk

MATERIAL: STOP_REASON token set; key-casing mapping.

Original issue (Pass 1)

DS-STEPS lexical rules were incomplete and the 'governed string-literal rules' were not in the cut.

What the reconciliation changed

Doubled-quote escaping; single-line strings; ASCII case-insensitive keywords; whitespace; whole-line comments only; canonical ordinals; enforced materialization clause order and cardinality; unknown lines refuse; no operation mixing; WKO bytes; RUN as sole composition token (§11).

Why it does or does not resolve the finding

• The materialization grammar is now close to derivable by an independent parser.
• Only the materialization form has frozen structure. INVENTORY, UPDATE ALIASES (with AS/CLEAR/RESET, SOURCE-or-MAP), REPAIR MAP, REPAIR WORK ORDER REGISTRY and CONVERT (F-10 gives a form but not cardinality/order rules) have no clause order, cardinality or optional-clause rules. Is WORK ORDER AS allowed or required on INVENTORY?
• 'RUN ... when parsed as a construct' (§11.8) does not define the construct. A line whose first token is RUN? RUN followed by a string? The refusal gate needs the trigger shape.
• Token separation around SUITCASE: . (is SUITCASE:. valid? is the colon a token?) and between the words of multi-word keywords is not stated.
• Two decisions contradict Revision BL and other reconciliation decisions without disposition. Raised as P2-02.

Revision BL requirements affected

W002-STEPS-001, 001.1, 001.2, 002, 003, W002-WKO-012.1, 012.2, 012.5, 012.6, W002-WKO-013, W002-WKO-ACC-006, W002-INV-001, W002-MAT-ACC-002.4

Reconciliation log sections

§11, §13.2

Integration consequence

Add a lexical-rules requirement; add a per-operation structure table for all six operations; define the RUN trigger.

Residual risk

BLOCKING via P2-02. MATERIAL: five operation grammars; RUN trigger; token separation.

Original issue (Pass 1)

Receipt and Inventory TXT must be tested byte-for-byte but their serialization was left to the implementation.

What the reconciliation changed

Physical form, KEY: VALUE, quoting, absence tokens, UNKNOWN_OPERATION, six-key common envelope, indexed lists, UPDATE_ALIASES facts, Inventory header and filename ordering (§12).

Why it does or does not resolve the finding

• The shared grammar (encoding, line form, quoting, absence tokens, indexed lists) is sound and closes most of the original finding.
• The common envelope silently drops Revision BL core facts. W002-RCP-006 requires RECEIPT_FILENAME, RUN_STARTED_UTC, RUN_FINISHED_UTC and IDENTITY_COLLISION_RETRIES; W002-STOR-007.3 requires collision retries on the Receipt. §12.5 lists six keys (adding RECEIPT_UTC) and says nothing about the other four. Retired, or moved to operation facts?
• Operation facts are frozen only for UPDATE_ALIASES and CONVERT. MATERIALIZE (the main operation, whose facts W002-RCP-007 lists without key names or order), INVENTORY and REPAIR_MAP have no key names or order. §12.10 requires golden fixtures only for operations 'whose grammar is frozen' — which excludes MATERIALIZE.
• Inventory lines carry filenames only. W002-INV-003 requires byte length and last-modified per file; W002-INV-006 requires generating WKO identity and the Suitcase declaration. §12.9 has no key for any of them.
• Three-digit indices overflow. F-20 permits KEEP of 16,384 columns, so a Store-establishing Receipt lists 16,386 created artifacts; a Suitcase can hold more than 999 files. CREATED_ARTIFACT_nnn and FILE_nnn have no defined form past 999, and the F-20 maximum-width gate cannot produce a conforming Receipt.
• REPAIR WORK ORDER REGISTRY has no OPERATION token; F-20 fallback disclosure (§23.5) has no key form.

Revision BL requirements affected

W002-RCP-005, 006, 007, 008, W002-RCP-ACC-001, 002, W002-STOR-007.3, W002-INV-003, 006, W002-CONV-004.2–004.4

Reconciliation log sections

§12, §13.9, §23.5, §38.3

Integration consequence

Rewrite RCP-005/006/007/008 and INV-006 as full key tables per operation; add golden fixtures per operation.

Residual risk

BLOCKING: envelope vs RCP-006; MATERIALIZE/INVENTORY/REPAIR_MAP key tables; Inventory per-file fields; index width.

Evidence

• E F-05 §6.1: 'one Store MAP may describe multiple Stores'. §6.2's example shows Store B's successor MAP carrying Store A's rows 'copied forward'.
• E Revision BL still says the opposite in several places: W002-STOR-010.1 ('the single Store metadata snapshot'), W002-STOR-019.1 ('An explicitly named valid MAP binds the run to exactly the Store identified by that MAP's rid_filename'), W002-STOR-019.9 (first four fields byte-identical on every row).
• E W002-WKO-012.3: an alias-only Work Order uses SOURCE or MAP as its selector, 'not both'.
• E F-21 §24.3: a successor derived from a historical MAP becomes current if it is latest. F-03 §3.5: REPAIR MAP takes no selector. F-15 §18.3: comparison happens within 'the same applicable ... class/lineage', undefined for a shared file.

Why it matters

• I Concrete fork. Store A (crime.csv) is established in MAP1. Store B (population.csv) is added; MAP2 carries A and B. The analyst runs UPDATE ALIASES with MAP "MAP1", which F-21 permits. MAP3 is derived from MAP1 and contains only Store A. MAP3 is latest, so it is current. Store B is no longer in current state; its RID and COLs are orphaned. The next MATERIALIZE SOURCE "population.csv" finds no lineage and establishes a new Store with a new RID. No refusal, no warning: the F-03 failure mode, by a different route.
• I An alias-only Work Order selecting by MAP cannot name which lineage in a multi-Store MAP it targets, since SOURCE may not accompany MAP.
• I It is not stated whether a DEGRADED or INVALID Store A blocks publication of successors for Store B when the successor must carry A's broken rows, nor whether a malformed shared MAP makes every Store INVALID (see F-03).
• I UI-ACC-016's 'MAP associated with the current governed context' and F-34.6's operation-bound context both assume one MAP per Store.

Impact if integrated as written. Integrating F-05 as written would make one analyst action silently remove a Store from current state and let the next routine run fork it. That breaks the row-identity promise WASM-002 exists to prove.

Question / direction for T. Two coherent options. (a) One Store lineage per Store MAP file — keep F-05's single-source invariant and its compatibility predicate, drop the multi-Store clause. Current state is the latest MAP per lineage, as in Revision BL. This is the smaller change and I recommend it. (b) A Suitcase-wide Store MAP — then freeze: successors are always derived from the current Suitcase MAP with only the target lineage changed; historical selection selects a lineage state, not a whole file; status is per lineage; every selector (UPDATE ALIASES, REPAIR MAP) names a lineage; and a malformed MAP falls back rather than bricking all Stores.

Evidence

• E F-08 §11.5: the materialization form contains 'exactly one WORK ORDER AS "..." clause'.
• E Revision BL: W002-STEPS-001.1 ('at most one optional top-level clause'), W002-STOR-018.2 (wko_alias is 'the empty string when no alias is declared'), W002-MAT-ACC-002.3 (fixture must save 'one without a WORK ORDER AS clause'). F-02 §8.8 also relies on 'an unaliased valid WKO'. BL's INVENTORY and RECOVER RID forms have no alias.
• E F-08 §11.3: '#' begins a comment only as the first non-whitespace character; 'Inline comments are not part of the WASM-002 lexical contract'.
• E Revision BL: W002-STEPS-001.2 ('Whole-line comments and trailing comments are permitted'); the canonical W002-STEPS-001 example itself has a trailing comment (# reporting year) and would now refuse as unknown syntax; W002-MAT-ACC-002.4 requires trailing comments to be ignored.
• E Neither reversal appears in the §7 integration consequences or the F-08 acceptance list as a retirement of BL text.

Why it matters

• I An independent parser author cannot tell whether an unaliased materialization WKO validates, or whether the canonical example in the contract is valid.
• I If the alias is mandatory, F-02's unaliased-WKO registry rules are dead text; if optional, §11.5 is wrong.

Impact if integrated as written. Save-time validation, the canonical example and two acceptance gates disagree; a build cannot pass them all.

Question / direction for T. Decide both explicitly. If trailing comments and optional aliases are being withdrawn deliberately, list the BL text to retire (STEPS-001, 001.1, 001.2, STOR-018.2, MAT-ACC-002.3, 002.4). If not, correct §11.3 and §11.5. Then give the structure table for the other five operations (F-08 residual).

Original issue (Pass 1)

W002-UI-ACC-019 required an editable Work Order Description that three other requirements forbid.

What the reconciliation changed

Retires the mutable Description model and replaces the gate with one proving there is no Description field and that any WKO byte change produces a derived draft (§15).

Why it does or does not resolve the finding

• The contradiction is removed rather than implemented, and the replacement gate is testable from the text.
• Same-alias successors now route through the F-02 lifecycle (§15.5), so the rewrite depends on F-02 being sound. See F-02.

Revision BL requirements affected

W002-UI-ACC-019, W002-UI-023, W002-STOR-018, W002-STOR-015, W002-MAT-ACC-002.4

Reconciliation log sections

§15

Integration consequence

Replace W002-UI-ACC-019; remove 'Persistent Work Order description storage' from W002-STOR-015; consider merging with W002-MAT-ACC-002.4.

Residual risk

None beyond F-02.

Original issue (Pass 1)

A same-filename source refresh routed into last month's Store with no cardinality check, and there was no way to ask for a new Store.

What the reconciliation changed

RID header becomes N=<value>; existing-Store materialization refuses before promotion when candidate N differs; a distinct source filename is the explicit new-row-universe signal; no NEW STORE syntax (§5).

Why it does or does not resolve the finding

• The count gate is precise: phase (before any COL/MAP promotion), comparison, outcome (existing Store stays VALID) and Help all stated.
• Rejecting NEW STORE syntax in favour of a visible distinct filename is a legitimate design choice, and it is now explicit rather than a hidden trick.
• The RID byte form changes (literal RID → N=5); W002-RID-004 and W002-RID-ACC-001 golden bytes must change. §38.10 gives N=0.
• The cardinality gate trusts the RID header only if the RID is 'already valid' (§5.3). How valid is established is P2-04.

Revision BL requirements affected

W002-RID-004, W002-RID-005, W002-RID-ACC-001, W002-MAT-002.6, W002-MAT-002.7, W002-STOR-019.2

Reconciliation log sections

§5, §38.10

Integration consequence

Rewrite W002-RID-004 and RID-ACC-001; add a normative cardinality-gate requirement, diagnostic facts (expected_N, candidate_N) and refusal gate; add a distinct-filename new-Store gate.

Residual risk

Equal-N refreshes still align silently; this is the accepted assurance boundary (W002-HELP-011).

Original issue (Pass 1)

Windows-1252 conversion had no Work Order form, output contract, or CVT serialization.

What the reconciliation changed

Canonical CONVERT WINDOWS-1252 TO UTF-8 form; strict-UTF-8-first precondition; transcoding only; byte-preserved CR/LF/CRLF; no BOM added and leading EF BB BF mapped as data; SCR→CVT commit; Receipt facts; golden bytes (§13).

Why it does or does not resolve the finding

• Every Pass 1 question has an answer, and the golden fixture 63 61 66 E9 0D 0A → 63 61 66 C3 A9 0D 0A is a genuine oracle.
• Byte-preserving line endings mean a legacy file with bare-CR records converts to a CVT that F-06 will refuse at materialization. That is honest and consistent, but Help should anticipate it.
• Each conversion gets a new CVT filename, so under F-04 a monthly re-conversion always creates a new Store and never extends one. Consistent, worth stating in Help.

Revision BL requirements affected

W002-CONV-001–004.5, W002-CONV-ACC-001, 002, PB-STOR-006

Reconciliation log sections

§13

Integration consequence

Add the form, CVT serialization, precondition and Receipt facts as normative requirements; extend CONV-ACC-001; move CONV-ACC out of the '6A' heading.

Residual risk

Minor: Help for bare-CR CVTs and re-conversion routing.

Original issue (Pass 1)

The Store Index was an in-scope obligation with no class, trigger or content contract.

What the reconciliation changed

Store Index retired from WASM-002; STOR-010 narrowed to aliases; 010.3/010.4 move to DIR (WASM-003) (§14).

Why it does or does not resolve the finding

• The decision is right and cheap.
• However, §14.4, §14.7 and §14.8 describe Revision BL text that does not appear in the reviewed cut (see P2-06). The integration map for this finding must be re-derived from the actual baseline.

Revision BL requirements affected

W002-STOR-010, 010.1–010.4, PB-STOR-002, W002-STOR-012, W002-STOR-015

Reconciliation log sections

§14

Integration consequence

Retire 010.3/010.4; retitle 010; fix PB-STOR-002; re-derive 010.1 against P2-01.

Residual risk

MATERIAL via P2-06.