Red5Sorcery / Data Sculptor

WASM-002 adversarial QA review — Revision BM Day 060 H-04 integration faithfulness

Independent review of the Day 060 H-04 Claude final handoff, Wednesday 7 October 2026. Findings only; no requirement text, fixture or supporting record has been changed.

Review identity

Primary target	`Red5Sorcery_Data_Sculptor_Product_Backlog_PRD_Revision_BM_Day060_H04.html`, SHA-256 `E8B41617DABC648482253111E8D3984B9151DFD56BEBA490904AE41ABAE5D79B`, 1,710,821 bytes. 803 requirements; 402 SCOPE=WASM-002.
Scoped cut	`WASM002_Integrated_Cut_Revision_BM_Day060_H04.html`, SHA-256 `AFA5CCA9977E7601EA43412E5DBE024180D6533D9C0F34DB5679D1C6652D3C5B`, 402 requirements
Handoff packet	`Red5Sorcery_Data_Sculptor_WASM002_Claude_Final_Handoff_Day060_H04.zip`. All 77 entries in `SHA256_MANIFEST.txt` and all 15 `.sha256.txt` sidecars verify; every file in the archive is listed in the manifest.
Supporting records	Pass 1 review `7BCD850A…4F58A67C`, Pass 2 review `D87E352F…EB39197`, Pass 3 review `0598550B…51FC3461`, erratum check `056499A9…B6B8F7AF`, Pass 1 log `9A73DB71…FA9255B7`, Pass 2 log `F564FFC2…E45603`, Pass 2 log + Pass 3 erratum `F5C2D819…7EE93`. Each matches the hash in my own sidecars and project copies.
Baseline used for BL→BM	The packet's full BL master (`A5D5D8D0…08813E6`, 778 requirements, 384 WASM-002). The 384-requirement projection I reviewed in Passes 1–3 (`828C6A81…E025F`) is not in the packet; its count matches.
Scope	Whether BM H-04 faithfully and completely integrates the accepted Pass 1, Pass 2, Pass 3/erratum, carried, CAT and H-01 to H-04 decisions; traceability; disposition; ID continuity; sweeps; Receipt/INV byte contracts against the golden fixtures; diagnostic grammar. Settled product choices were not reopened.

Wording boundary. Nothing here describes WASM-002 or Revision BM as approved, frozen, implemented, built, accepted or ready for implementation. A positive gate would not have frozen the PRD either; T retains acceptance authority.

1. Summary

4	BLOCKING	Four frozen Pass 1/Pass 2 decisions (F-06, F-02, F-03, F-10) have no complete normative home in BM. The BM text refers back to the reconciliation records instead of stating the rules.
8	MATERIAL NON-BLOCKING	Traceability that cannot show where decisions live; golden fixtures that encode impossible or unreachable states; undefined Receipt semantics the fixtures had to guess; H-02 diagnostic pins that conflict with Help duties; a missing P3-09 fixture; an unexercised P3-02 oracle; the normative Windows-1252 table outside the freeze set.
4	CLARITY	Stale search index (including the superseded diagnostic spelling), two leftover Pass 2 checklist edits, front-matter duplication and an incomplete omitted-ID table, and two packet gaps.

The mechanical layer is in good shape: hashes, counts, ID history, cut fidelity, Receipt grammar and the H-04 normalization all verify (section 4). The defects are in the substance. The traceability record answers "See reconciliation record and integration log" for most Pass 1 decisions, and that answer hid the four blockers. All four are integration omissions of decisions T has already made, so closing them needs no new product decision.

2. Finding index

BM-01	BLOCKING	F-06 CSV refusal oracle is not integrated: five of the seven condition tokens, the location rules, precedence and bare-CR/EOF rules are absent
BM-02	BLOCKING	F-02 registry-repair semantics are not integrated: REPAIR WORK ORDER REGISTRY has no stated algorithm, bootstrap or run-eligibility rule
BM-03	BLOCKING	F-03 Store-health model is only partly integrated: DEGRADED is never defined, and the DEGRADED gate and REPAIR MAP health precondition are missing
BM-04	BLOCKING	F-10 conversion gate is not integrated: nothing stops CONVERT from transcoding an already-valid UTF-8 source into mojibake
BM-05	MATERIAL	Traceability does not map most Pass 1 decisions to requirement IDs, and that gap concealed BM-01 to BM-04
BM-06	MATERIAL	Every success Receipt fixture has an impossible timeline; RUN_STARTED_UTC and RUN_FINISHED_UTC are undefined; the INV fixture depicts an unreachable Suitcase
BM-07	MATERIAL	The registry-repair success fixture omits the bootstrap repair WKO, and the REGISTERED_* counts have no defined meaning
BM-08	MATERIAL	When RID_ACTION is "established" is undefined; the fixtures switch from NOT_RUN to CREATED for a RID that was never created
BM-09	MATERIAL	H-02 pinned meanings are broad classes with fixed facts, which conflict with the P3-05, P3-07 and P2-03 Help and fact duties under closed-world Help
BM-10	MATERIAL	The P3-09 zero-byte golden Receipt is missing, and "differ in the offset value only" is false
BM-11	MATERIAL	The P3-02 CONVERT undefined-byte offset is never exercised by a fixture or an acceptance requirement
BM-12	MATERIAL	The normative Windows-1252 table is SCOPE=PRODUCT and outside the freeze set; the "exhaustive" table covers only 0x80–0x9F
BM-13	CLARITY	The data-search index is stale on 213 requirements, including six with the superseded diagnostic spelling; the zero-occurrence audit claims are case-sensitive only
BM-14	CLARITY	Two Pass 2 checklist edits were not made: CONV-004.2/.3 still use KEY=VALUE, and STOR-019.10's opening still ties eligibility to RID/COL validity
BM-15	CLARITY	Duplicated front matter with a Day 059 "in progress" banner; the omitted-ID table misses the seven IDs re-scoped in BM
BM-16	CLARITY	Packet gaps: the P2-07 erratum and its sidecar are cited but not supplied

3. Findings

BM-01BLOCKING

The F-06 CSV refusal oracle is not integrated

BM: W002-MAT-001.7W002-MAT-002.8W002-MAT-003.2W002-MAT-ACC-003W002-RCP-007W002-HELP-001.8 (DS-MAT-011) · Source: Pass 2 log §7.1–7.12 · Pass 1/2 severity: BLOCKING

Evidence

E Pass 2 log §7.2 freezes exactly seven condition tokens. In the 803-requirement master, UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD, BARE_CR_OUTSIDE_QUOTED_FIELD, EOF_INSIDE_QUOTED_FIELD, TOO_FEW_FIELDS and TOO_MANY_FIELDS occur zero times. Only BLANK_LOGICAL_RECORD and INVALID_BYTE_AFTER_CLOSING_QUOTE appear, and only in passing (P3-09 and P3-10 text).
E None of the following has BM text: the per-condition location table (§7.3), the field-ordinal rules (§7.4), the PHYSICAL_LINE and LOGICAL_RECORD definitions (§7.1), first-condition precedence (§7.7), bare CR refusing only outside quotes (§7.5), or explicit EOF-inside-quote refusal (§7.6). "precedence", "one-past-end" and "bare CR" each return zero hits.
E W002-RCP-007: the five CSV keys "carry the exact F-06 refusal condition and location oracle". W002-MAT-001.7 (P3-09): NO_HEADER_RECORD "extends the frozen structural malformed-CSV condition-token set by exactly one token". Both point to a set that BM never states.
E The integration log has no F-06 section, and the traceability row reads "See reconciliation record and integration log".

Why it matters

I CSV refusal is the most common MATERIALIZE outcome after UTF-8. An implementer working from BM cannot produce CSV_REFUSAL_CONDITION, CSV_SOURCE_BYTE_OFFSET or CSV_FIELD_ORDINAL for six of the eight conditions, and DS-MAT-011's required facts have no value set. This is exactly the Pass 2 blocking residual that F-06 closed on paper.
I W002-MAT-002.8 keeps BL's generic ragged-record and blank-record rules, but it is silent on bare CR and has no tokens or locations. The golden corpus covers only NO_HEADER_RECORD, so nothing else in the packet exposes the gap.

Direction. Integrate Pass 2 log §7.1–7.11 verbatim into a named CSV input-profile and refusal-oracle requirement (or into W002-MAT-002.8 and W002-MAT-003.x), with NO_HEADER_RECORD added as the eighth token. Extend W002-MAT-ACC-003 with the §7.11 acceptance cases. No product decision is needed.

BM-02BLOCKING

REPAIR WORK ORDER REGISTRY has no integrated algorithm, bootstrap or run-eligibility rule

BM: W002-STOR-018.3W002-STOR-018.4W002-RCP-008W002-WKO-ACC-004 · Source: Pass 2 log §5.2–5.4, §5.5 (line endings), §5.7, §5.9 · Pass 1/2 severity: BLOCKING

Evidence

E W002-STOR-018.3: "The bounded REPAIR WORK ORDER REGISTRY bootstrap defined by the accepted F-02 reconciliation remains the sole exception…". W002-STOR-018.4: "Its bounded unregistered-repair bootstrap remains governed by W002-STOR-018.3." W002-RCP-008: "…under the frozen registry-repair rules." Each points elsewhere, and the rule itself is never stated.
E Absent from BM: §5.2, a repair-only WKO may Run by exact filename while the registry is repair-required, and nothing else gains eligibility; §5.3, Save under a stale registry; §5.4, the reconciliation algorithm (drop rows whose WKO is missing; discover visible valid unregistered WKOs; CURRENT if the alias is unowned, DEPRECATED if owned; all DEPRECATED when several share an unowned alias, with no winner by time); §5.7, a DEPRECATED WKO runs by exact filename only and an unregistered WKO cannot run. Searches for "registered as DEPRECATED", "winner", "stale registry" and "by exact filename" (WKO sense) return nothing.
E §5.5's line-ending rule (LF and CRLF accepted, lone CR refused) is also absent. The F-14 WKO validity predicate in W002-STOR-018.3 omits it.
E W002-WKO-ACC-004 covers ordinary save and Replace/Cancel only. None of the §5.9 repair acceptance cases appear.

Why it matters

I One of the seven executable operations has a Receipt grammar and golden bytes but no specified behavior. Two implementers could publish different successor WKO MAPs from the same Suitcase, and both would match the PRD.
I Run eligibility of DEPRECATED and unregistered WKOs is a security-relevant boundary (which bytes may execute), and BM does not state it.

Direction. Integrate §5.2–5.4, §5.5 (line endings) and §5.7 as normative text under W002-STOR-018.x and the Run rules. Add the §5.9 acceptance set. See BM-07 for the fixture consequence.

BM-03BLOCKING

The F-03 Store-health model is only partly integrated: DEGRADED is never defined

BM: W002-STOR-019.2W002-STOR-019.10W002-RID-008W002-CAT-007W002-WKO-012.1 · Source: Pass 2 log §6.3–6.6, §6.11 · Pass 1/2 severity: BLOCKING

Evidence

E INVALID is defined (W002-RID-008: "If that bound RID is missing or invalid, the Store is INVALID"). No requirement defines VALID or DEGRADED (§6.3). DEGRADED appears 13 times, always as an already-known term.
E W002-STOR-019.2 still says "Current-MAP selection and Store-health evaluation are governed separately by the accepted Store-health rules being integrated into Revision BM." W002-CAT-007 evaluates store_health "under the canonical Store-health rules". Neither has a referent in BM.
E Absent: the §6.5 DEGRADED gate (REPAIR MAP is the only enabled Store operation; extension and alias mutation refuse; read-only Help, Inventory and status stay available); §6.6 "the target Store must currently evaluate DEGRADED"; §6.4 "status is evaluated, not persisted". "only enabled" returns zero hits. UPDATE ALIASES with a SOURCE selector has no stated health gate; W002-WKO-012.3's VALID rule covers only explicit MAP selection.
E None of the §6.11 acceptance cases appear: target required, historical target refused, WKO MAP as target refused, missing COL gives DEGRADED, missing RID gives INVALID, malformed newest Store MAP falls back.

Why it matters

I Whether REPAIR MAP on a VALID Store refuses or publishes a no-op successor, and whether a SOURCE-based alias update on a DEGRADED Store proceeds, cannot be decided from BM. CAT's store_health column and the CATALOG_STORES fixtures depend on the same undefined rule.
I The pieces that did land (P3-05 Help exits, P3-06 tiers, P3-07 routing, REPAIR MAP determinism) all presuppose the §6.3 definitions.

Direction. Integrate §6.1–6.6 and §6.9–6.11 into W002-STOR-019.x. Replace the "being integrated" sentence with a citation to the new requirement, and point W002-CAT-007 at it.

BM-04BLOCKING

Nothing stops CONVERT from transcoding a source that is already valid UTF-8

BM: W002-CONV-001W002-CONV-002W002-CONV-004W002-RCP-008 · Source: Pass 1 log §13.3–13.5 (F-10)

Evidence

E F-10 §13.3: "If the complete source is already valid strict UTF-8, refuse the conversion as unnecessary; do not create a CVT artifact. Only after strict UTF-8 fails, assess compatibility." BM has no equivalent. W002-CONV-002's "after strict UTF-8 FAIL" governs the read-only assessment inside a refused MATERIALIZE, not the CONVERT operation.
E The §13.5 BOM rule (no BOM on CVT output; leading EF BB BF in a failed-UTF-8 source is data, not stripped) and the §13.4 byte-preservation rule (CR, LF and CRLF unchanged; no CSV interpretation) are absent. W002-CONV-004 says only that publication "does not assert … structurally valid CSV".
E RCP-008 defines a "Validation/classification refusal before conversion begins" row, but no requirement states the classification conditions or the SOURCE_ENCODING value set beyond WINDOWS-1252-COMPATIBLE.

Why it matters

I Nearly every UTF-8 file is also "mappable" under Windows-1252 (for example é = C3 A9). An analyst who writes a CONVERT WKO for a UTF-8 export gets a strict-UTF-8, publishable CVT full of mojibake (Ã©). This is silent data corruption behind a governed success Receipt, the outcome the product exists to prevent.

Direction. Integrate F-10 §13.3–13.5 into W002-CONV-001/004, close the SOURCE_ENCODING token set, and add acceptance cases for a valid-UTF-8 refusal, a leading-EF BB BF source, and CR/CRLF preservation.

BM-05MATERIAL NON-BLOCKING

Traceability does not show where most Pass 1 decisions live, and that gap concealed BM-01 to BM-04

Packet: WASM002_Integration_Traceability_Day060_H04.html, WASM002_Carried_Item_Disposition_Day060_H04.html, Day060_Canonical_PRD_Integration_Log_through_H04.html

Evidence

E In the Pass 1 table, 28 of 34 rows say "See reconciliation record and integration log". F-06 and F-10 appear in no row that maps them to requirement IDs. F-02, F-03, F-04, F-09, F-12 and F-18 are reachable only indirectly, through later sections that each cover part of the decision (S-01, P3-05 to P3-07, S-05, H-01, P2-03, P3-04). F-06, F-10 and F-12 do not appear in the integration log at all.
E Integration log §27: "this checkpoint does not claim that every affected Revision BL requirement body has already been rewritten. The final integration sweep must fold every accepted decision…". No later section records that sweep for the Pass 1 decisions. S-01 to S-07 are targeted fixes.
E The disposition table gives P2-03, P2-04 and P2-05 the homes "Store/WKO chronology targets", "RID/Store validation targets" and "Help/HLP typed-JSON targets", not IDs. The traceability sections do give IDs for these three.
E The F-16 row is corrupted: F-22's text is merged into its target column. H-02 and H-03 have no traceability rows.
E 25 changed WASM-002 requirements are never named by ID. On inspection, all are covered by range notation (for example "W002-ENC-004.2 through .8") or by the RID-recovery retirement. I found no unexplained change, but a mechanical ID check cannot confirm that.

Why it matters

I My handoff note named this as the main thing I would hunt for. A "see the log" row is not a home, and in four cases the log had no home to show.
I Coverage limit. I verified F-02, F-03, F-06 and F-10 against their frozen text, and confirmed presence for F-04 (S-05), F-09 (RCP/H-01), F-12 (P2-03) and F-18 (RCP-006). I did not re-verify every clause of F-01, F-05 and F-07 to F-34 against its source section. A gate cannot pass until every decision has an ID-level home.

Direction. Rebuild the Pass 1 table with requirement IDs for every finding. Add a column naming each frozen sub-clause (for example F-06 §7.3) with its BM home, so the next check is mechanical.

BM-06MATERIAL NON-BLOCKING

The golden fixtures encode impossible timelines and an unreachable Suitcase

Fixtures: all seven success/*.txt; Inventory/__DS__INV__20261007T120000000Z__…001.txt · BM: W002-RCP-006W002-RCP-ACC-001W002-STOR-018.3W002-STOR-022W002-INV-003

Evidence

E In every success Receipt, the published artifact's UTC falls outside its own [RUN_STARTED_UTC, RUN_FINISHED_UTC]. In SUCCESS__MATERIALIZE, the RID, COL and MAP are stamped 14:59:59.000, eleven seconds before the run started at 15:00:10. In the other six, the artifact is stamped after RECEIPT_UTC; for example, INVENTORY publishes its INV at 15:01:00 inside a Receipt written at 15:00:22, and CATALOG_STORES publishes its CAT at 15:06:00 inside a Receipt written at 15:01:12.
E BM never defines RUN_STARTED_UTC or RUN_FINISHED_UTC. They appear only as names in the W002-RCP-006 envelope list. P2-03 and S-04 require transaction UTCs to be truthful host observations made during publication.
E The INV fixture lists the run WKO …000000000002.txt, alpha.csv and beta.csv, but no WKO MAP and no CER. W002-STOR-018.3 publishes the WKO and its WKO MAP in one save transaction, an unregistered WKO cannot Run, and W002-STOR-022 locks analytical execution until a CER exists in the root. W002-INV-003 inventories every regular root file.

Why it matters

I A conforming implementation with a monotonic clock seam cannot reproduce these bytes. Matching them requires a seam that runs time backwards, which teaches the opposite of P2-03. A product whose creed is "I know what it actually did" should not keep, as its reference evidence, Receipts that report artifacts created after the Receipt.

Direction. Define RUN_STARTED_UTC and RUN_FINISHED_UTC, including their ordering relative to transaction UTCs and RECEIPT_UTC. Regenerate the fixture timestamps so that WKO ≤ run start ≤ transaction UTC ≤ run finish ≤ RECEIPT_UTC. Make the INV fixture list a reachable Suitcase, or state that the INV fixture is a format oracle built by a harness.

BM-07MATERIAL NON-BLOCKING

The registry-repair success fixture omits the repair WKO, and the REGISTERED_* counts are undefined

Fixture: success/SUCCESS__REPAIR_WORK_ORDER_REGISTRY.txt · BM: W002-RCP-008W002-STOR-018.3 (P3-10)

Evidence

E The base WKO MAP is stamped 14:20. The run's own WKO (…000000000025.txt, 14:50) postdates it and so cannot be registered in it. P3-10 and RCP-008 require the bootstrap repair WKO to be registered by the committed successor and to "appear in the appropriate registered list". The fixture lists only …000000000008 as CURRENT, and 0 as DEPRECATED.
E RCP-008 names REGISTERED_CURRENT_COUNT and REGISTERED_DEPRECATED_COUNT but never says whether they count rows newly registered by this repair or every CURRENT/DEPRECATED row in the successor MAP.

Direction. Define both counts, then correct the fixture once BM-02 is integrated.

BM-08MATERIAL NON-BLOCKING

When RID_ACTION becomes "established" is undefined, and the fixtures report CREATED for a RID that was never created

BM: W002-RCP-006W002-RCP-007 · Fixtures: the MATERIALIZE refusal set · Source: P3-04

Evidence

E RCP-007: "RID_ACTION is exactly CREATED or REUSED when that action has been established". For REUSED, RID_FILENAME "may be established before publication". Neither requirement says which stage establishes the action.
E New-Store fixtures with BASE_MAP_FILENAME: NONE already established show RID_ACTION: NOT_RUN through Stage 1 and Stage 2. The publication refusal shows RID_ACTION: CREATED with RID_FILENAME: NONE and CREATED_ARTIFACT_COUNT: 0.
E No fixture or text decides an existing-Store Stage-1 or Stage-2 refusal: REUSED (routing established it) or NOT_RUN (by analogy with the new-Store fixtures).

Why it matters

I This is the P3-04 question ("is RID_ACTION NONE, NOT_RUN or NOT_AVAILABLE?") moved one step along. Separately, a refusal Receipt that says a RID was CREATED when none exists reads as a false claim.

Direction. Name RID_ACTION's owning stage and its value at each refusal boundary for both new and existing Stores, and align the fixtures.

BM-09MATERIAL NON-BLOCKING

H-02 pinned meanings are broad classes that collide with other pinned Help and fact duties

BM: W002-HELP-001.8 (H-02 table) W002-HELP-005W002-STOR-019.2W002-HELP-001.6

Evidence

E DS-MAT-010's frozen meaning is "MATERIALIZE validation/routing refuses before Stage 1 begins…", with required facts [source_filename] only. Optional facts stay empty "unless another requirement explicitly adds optional facts later". That class covers the P3-05 damaged-lineage refusal and the P3-07 malformed-MAP guard.
E W002-HELP-005 (closed world): the renderer "may consume only the canonical diagnostic fields and fact keys declared by the applicable diagnostic registry entries". P3-05 and P3-07 require Help to identify the blocked lineage, its current MAP, and the malformed MAP artifacts.
E P2-03 requires the monotonic-UTC refusal diagnostic to carry observed_host_utc, predecessor_map_filename and predecessor_utc. DS-MAT-013, DS-ALS-003, DS-RPM-004 and DS-WKR-003 each pin "identity allocation/publication refuses", with only artifact_class and collision_retry_count.

Why it matters

I An implementer who uses the pinned ID cannot satisfy the Help duty. One who allocates a new ID contradicts the pinned meaning. Either way, independent acceptance (F-22) of the pinned mapping fails for one of them.

Direction. Narrow each H-02 meaning to the exact fixture condition (for example "UUID-collision exhaustion"), or declare the facts the other duties need. State that P3-05, P3-07 and P2-03 refusals use separately allocated IDs.

BM-10MATERIAL NON-BLOCKING

The P3-09 zero-byte golden Receipt is missing

BM: W002-RCP-007W002-MAT-ACC-003 · Log §12 (P3-09)

Evidence

E RCP-007: "The zero-byte and UTF-8-BOM-only golden refusal Receipts therefore differ in the offset value only: 0 versus 3." Log §12: "Added deterministic zero-byte and UTF-8-BOM-only acceptance/Receipt fixtures." The corpus contains only bom_only.csv (offset 3).
E The two would also differ in CERTIFIED_SOURCE_BYTE_COUNT (0 versus 3) and SOURCE_FILENAME, so "offset only" is wrong.

Direction. Add the zero-byte Receipt and correct the RCP-007 sentence.

BM-11MATERIAL NON-BLOCKING

The P3-02 CONVERT undefined-byte offset is never exercised

BM: W002-RCP-008W002-CONV-ACC-002 · Fixtures: REFUSED__CONVERT_*

Evidence

E All four CONVERT fixtures carry UNDEFINED_WINDOWS_1252_BYTE_OFFSET as NOT_RUN or NOT_APPLICABLE. The classification fixture shows a pre-assessment failure (SOURCE_ENCODING NOT_AVAILABLE), not an undefined-byte refusal.
E W002-CONV-ACC-002 tests undefined bytes only through the MATERIALIZE compatibility fields. No requirement says whether CONVERT detects undefined bytes in a pre-scan (classification row) or mid-stream (transcoding row).

Direction. State which stage detects the undefined byte, then add a CONVERT acceptance case and a golden Receipt carrying a real offset. This was the CONVERT half of a Pass 3 blocker.

BM-12MATERIAL NON-BLOCKING

The normative Windows-1252 table sits outside the freeze set and is not exhaustive

BM: W002-GLOSS-037W002-GLOSS-037.2W002-CONV-002.1W002-CONV-002.4 · Packet: Context-Only Dependencies

Evidence

E W002-CONV-002.4: "W002-GLOSS-037.2 is the exhaustive normative WASM-002 Windows-1252 mapping table." W002-GLOSS-037.2 is SCOPE=PRODUCT, STATUS N/A, and the packet labels it "not review targets … context only".
E GLOSS-037.2 tabulates only 0x80–0x9F. The 0x00–0x7F and 0xA0–0xFF rules are in W002-GLOSS-037, which is also PRODUCT. Its title and body still split one sentence ("…The converter must refuse" / "rather than guess…"), a fragmentation that the WASM-002-only S-06 and S-07 sweeps did not reach.

Direction. Either bring the mapping into a WASM-002-scoped requirement covering all 256 bytes, or state in CONV-002.x that GLOSS-037 and 037.2 are frozen with WASM-002. Repair the 037.2 title.

BM-13CLARITY

The search index is stale, including the superseded diagnostic spelling

Evidence

E The data-search attribute differs from the visible ID, title and body on 213 of 803 requirements (154 WASM-002), 123 of them in substance.
E Six requirements (W002-CONV-003, 003.1, HELP-001.6, 001.7, CONV-ACC-001, CONV-ACC-002) still index ds-conv-001: 8 occurrences in the master and 8 in the cut. A search for "DS-CNV-001" misses them, and a search for the superseded ID finds them.
E The H-04 and final audits ("superseded … occurrences: 0") and the sweep evidence are case-sensitive only. The 12 cut-versus-master deltas are 11 search attributes that differ only in entity encoding (') and one whitespace difference in a table; visible text is identical.

Direction. Regenerate data-search from visible text for every article and make the sweeps case-insensitive.

BM-14CLARITY

Two Pass 2 checklist edits were not made

Evidence

E The Pass 2 checklist called for "W002-CONV-004.2/.3 colon form". Both still read SOURCE_ENCODING=WINDOWS-1252-COMPATIBLE and MATERIALIZED_ENCODING=UTF-8, and 004.2 adds "or the exact equivalent terminology". W002-RCP-005: "KEY=VALUE is not valid canonical Receipt serialization."
E The Pass 3 checklist called for "W002-STOR-019.10 to structural validity only". Its opening paragraph still requires RID/COL validity for eligibility. The P3-07 paragraph makes this a deliberate inheritance-versus-routing distinction, so there is no behavioral conflict, but the paragraph reads against F-03 §6.1.

BM-15CLARITY

Front-matter duplication and an incomplete omitted-ID table

Evidence

E The master begins with three <!DOCTYPE html> lines and contains two title blocks: Day 060 in the hero, and Day 059 in #content ("…continues on Day 059"; "Full text sweep is in progress").
E The F-31 omitted-ID table "explains the deliberate numbering gaps seen in narrower WASM-002 review cuts" but lists 19 IDs. It omits the seven IDs re-scoped in BM (W002-RID-009, 010, RID-ACC-005, RCP-011, STEPS-010, STOR-010.3, 010.4), all of which now leave gaps in the 402 cut.

BM-16CLARITY

Packet gaps

Evidence

E Log §22 (P2-07): "A standalone P2-07 erratum and SHA-256 sidecar are created." Neither is in the packet or the project, and the Pass 1 log in the packet is byte-identical to the original. The disposition table cites the "Pass-1 reconciliation record" as P2-07's home.
E The disposition H-04 row cites "W002-CONV-003/.3.2", presumably W002-CONV-003.2.

4. Verified without findings

Hashes. Manifest, sidecars, the master and cut hashes in READ_ME_FIRST, and every supporting record against my own sidecars.
Counts and scope. 803 / 402 / 401. The exclusion CSV equals the non-WASM-002 set exactly. No duplicate requirement IDs. Visible ID, SCOPE, BUILD and STATUS agree with the data attributes on every article. All 402 are UNDER REVIEW with blank BUILD.
Cut fidelity. The cut equals the master's WASM-002 articles in canonical order, with identical titles and visible text. The only differences are entity encodings in the search attributes and one whitespace difference in a table.
BL→BM IDs. Recomputed independently: 25 added (all WASM-002), 0 deleted, 7 re-scoped to V1-BACKLOG/DEFERRED, and 384 + 25 − 7 = 402. The 18 non-WASM-002 text changes are covered by F-14/F-33, S-02, S-03, F-32 and the RID-recovery retirement.
Receipt and INV grammar. All 33 Receipts and the INV pass a validator built from RCP-005 to RCP-008 and INV-006: UTF-8 with no BOM, LF only, a single final LF, no trailing spaces or blank lines, exact envelope and per-operation key order, indexed keys with a minimum width of three digits, list counts that match their lines, quoting and doubled quotes, RECEIPT_UTC equal to the filename UTC, and closed RESULT and absence tokens. UNKNOWN_OPERATION has the exact envelope-then-count form. The corpus covers every refusal-boundary row in RCP-007 and RCP-008 plus the three Stage-1 compatibility variants. MATERIALIZE refusal values match the RCP-007 matrix.
H-02 and H-04. The W002-HELP-001.8 allocation table matches the fixture JSON row for row (23 IDs). RECEIPT_VERSION: 1 is frozen. DS-CNV-001 is the only spelling in visible text. All 29 diagnostic tokens fit DS-[A-Z]{3}-[0-9]{3}; the remaining matches are the element IDs ds-help-catalog and ds-hlp-provenance and the language name "DS-STEPS". The rename is recorded as pre-freeze in W002-HELP-001.1 and breaks no permanence rule.
Carried items with confirmed homes. E-01 (bare KEEP; KEEP: explicitly invalid), P3-01 (0..1 MAP after SOURCE), E-02 (historical-MAP health gate in STOR-019.3 and WKO-012.3, applied to UPDATE ALIASES), and P3-02 to P3-10 at the cited IDs (spot-checked). P2-03, P2-04, P2-06 and CAT are present.
Sweeps. Zero occurrences of store_source_filename, optional/unaliased WKO alias wording, Store Index or Map/Index, RECOVERY_ARTIFACT_FILENAME, "six executable" and "nine-column". RID recovery and RCV appear only as boundary or reserved-not-emitted wording.

5. Gate conclusion

NOT READY FOR WASM-002 PRD FREEZE — INTEGRATION DEFECTS REMAIN

Four accepted decisions (F-06, F-02, F-03, F-10) have no complete normative home, so an implementer working from BM alone would have to invent the CSV refusal oracle, the registry-repair algorithm, the meaning of DEGRADED, and the conversion precondition. The material items include fixtures that encode states a conforming build cannot reach.

Path back. Closing the four blockers requires no new product decision. Each is a transcription of already-frozen text into named requirements. I suggest this order:

Integrate F-06 §7, F-02 §5.2–5.7, F-03 §6 and F-10 §13.3–13.5.
Rebuild the Pass 1 traceability with IDs at sub-clause level (BM-05).
Decide the small undefined points: RUN_* timestamps, RID_ACTION, REGISTERED_* counts, the stage at which CONVERT detects an undefined byte, and the scope of the H-02 meanings.
Regenerate the affected fixtures.
Regenerate data-search.

A focused re-check of BM-01 to BM-12 plus a mechanical rerun should then be enough; a full Pass 2-style review should not be needed.