Red5Sorcery / Data Sculptor

WASM-002 adversarial QA review of Revision BL

Pass 1 — independent requirement review, Wednesday 23 September 2026. Findings only; no requirement text has been changed.

1. Review identity

Contract under review	`Red5Sorcery_Data_Sculptor_WASM002_Adversarial_QA_PRD_RevBL_2026-09-22.html`
SHA-256 (verified)	`828C6A81B2C0A8B97546F728628059C53CC61256FAB23B142E452A8E566E025F` — matches the supplied sidecar; 626,877 bytes
Requirements in cut	384, all SCOPE WASM-002, all UNDER REVIEW (independently recounted)
Source master	Product Backlog PRD Revision BL, SHA-256 `A5D5D8D0…6408813E6` (not supplied; not reviewed)
Non-normative input	`Data_Sculptor_WASM002_Front_End_Prototype.html`, SHA-256 `A6EC724DEDC6CCCF08F5EDC4A818EEF361A419DEBAF4A17E0D548636FE8139A6` — used only for Appendix A
Reviewer	Claude, independent adversarial QA (no implementation seen)
Record discipline	Append-only. Corrections to this pass will be filed as addenda with the original text preserved.

2. Method and conventions

The contract was read end to end, then attacked one lifecycle at a time: Suitcase gate, WKO save, Run, Stage 1, Stage 2, publication, inheritance, alias maintenance, recovery, conversion, Help/HLP, and UI. Each candidate finding was checked against the full text of all 384 retained requirements before it was kept. Where a finding depends on the absence of a rule, that absence was confirmed by full-text search of the cut.

E marks evidence: a direct reading of cited requirement text, or a search result. I marks interpretation, which is contestable. Interpretations about browser or library behavior are flagged as such and should be verified on the target platform before being relied on.

Severity uses the project scale. BLOCKING: cannot be frozen as written, because a gate cannot be passed honestly, an independent oracle cannot be derived, or a core promise can be silently broken. MATERIAL NON-BLOCKING: should be resolved before freeze, but a reasonable build could proceed with an explicit decision. CLARITY: wording, structure or navigation. Suggested directions are offered to support T's decision and are not proposed requirement text.

Out of scope for this pass: the source master, requirements outside the cut (including PB-OPS-003, 003.1 and 010 beyond their listed titles), any implementation, and final Help prose.

3. Summary

BLOCKING	11
MATERIAL NON-BLOCKING	15
CLARITY	8
Total	34

Revision BL is a strong contract at its core. The Store commit protocol, the strict UTF-8 section and the honesty boundaries hold up well under attack. The blocking findings cluster in three places.

First, lifecycle edges. What happens when things go missing, get refreshed or get edited — a damaged RID, a re-downloaded source, an aliased Work Order being revised — is either unspecified or leads to silent behavior the contract elsewhere forbids (F-02, F-03, F-04).

Second, oracles that are referenced but not present. The error contract, the string-literal rules, the CSV input grammar, Receipt serialization, source/MAP compatibility and the conversion form are cited but not in the cut. An independent QA suite cannot be derived without them (F-05 to F-10).

Third, stale in-scope text, meaning requirements left over from earlier models (F-01, F-11).

Most blocking items need a decision rather than new machinery.

4. Finding index

ID	Severity	Finding
F-01	BLOCKING	An acceptance gate requires a capability the contract forbids
F-02	BLOCKING	An aliased Work Order cannot be edited and re-saved, and the WKO alias registry has no retirement path
F-03	BLOCKING	A missing or damaged RID or COL silently forks the Store, and the RID recovery base is undefined
F-04	BLOCKING	A same-filename source refresh has no cardinality check against the inherited RID, and there is no way to start a new Store
F-05	BLOCKING	The source-to-MAP compatibility rule is referenced but never defined
F-06	BLOCKING	The CSV dialect and the rules for malformed input are not frozen
F-07	BLOCKING	The meaning of the UTF-8 first-invalid offset is undefined, and the frozen error contract it points to is not in the cut
F-08	BLOCKING	The DS-STEPS lexical rules are incomplete, and the "governed string-literal rules" they cite are not in the cut
F-09	BLOCKING	Receipt and Inventory TXT must be tested byte-for-byte, but their serialization is not specified
F-10	BLOCKING	Windows-1252 conversion has no Work Order form, output contract or class-level serialization
F-11	BLOCKING	The Store Index is an in-scope obligation with no artifact class, trigger or content contract
F-12	MATERIAL NON-BLOCKING	Selecting current state by the greatest UTC has no guard against clock movement
F-13	MATERIAL NON-BLOCKING	The single-writer assumption is not stated
F-14	MATERIAL NON-BLOCKING	Publication and validity rules for non-Store artifacts are undefined
F-15	MATERIAL NON-BLOCKING	MAP eligibility can change when unrelated files appear, and the comparison rules are undefined
F-16	MATERIAL NON-BLOCKING	The conversion suggestion conflicts with fixed diagnostic semantics, and the Windows-1252 mapping is not frozen
F-17	MATERIAL NON-BLOCKING	The Help rendering contract is missing a coverage fallback, absent-value rendering, and a consistent notion of required facts
F-18	MATERIAL NON-BLOCKING	HLP provenance merges "not applicable" with "unavailable", and absence tokens differ across artifacts
F-19	MATERIAL NON-BLOCKING	HLP disclosure edge cases: a header can be data, and aliases are not covered by the allowlist
F-20	MATERIAL NON-BLOCKING	"Bounded memory" has no stated limits, and header width and KEEP width are unlimited
F-21	MATERIAL NON-BLOCKING	Publishing from a historical MAP silently changes what is current
F-22	MATERIAL NON-BLOCKING	Expected diagnostics come from a registry the implementer delivers, which undercuts QA independence
F-23	MATERIAL NON-BLOCKING	Acceptance coverage has gaps, and test seams are missing
F-24	MATERIAL NON-BLOCKING	Session model: a new CER every session, no remembered Suitcase, no preferences, and lost drafts
F-25	MATERIAL NON-BLOCKING	The target platform and the small-screen baseline are not defined within the cut
F-26	MATERIAL NON-BLOCKING	Allowed SOURCE reference forms are undefined
F-27	CLARITY	W002-UI-006 says "editable human alias"
F-28	CLARITY	Brand-Manifest wording survives in in-scope text
F-29	CLARITY	Section headings misplace in-scope requirements and are out of order
F-30	CLARITY	Truncated text in titles, evidence and rationale
F-31	CLARITY	Numbering gaps are not explained
F-32	CLARITY	Terminology drift
F-33	CLARITY	Some registered classes have no WASM-002 producer or contract, and unknown-class reporting is unspecified
F-34	CLARITY	Smaller underspecified points

5. Findings

F-01BLOCKING

An acceptance gate requires a capability the contract forbids

Cited: W002-UI-ACC-019 W002-UI-023 W002-STOR-018 W002-STOR-015

What the contract says

E W002-UI-ACC-019 requires that editing the human-facing description of a saved Work Order changes the description view while leaving the WKO bytes, filename and UUID unchanged.
E W002-UI-023 says the browser must not expose a standalone editable Description field for a saved or draft Work Order. W002-STOR-018 says the browser must not maintain a separate mutable Description field or hidden description store.
E W002-STOR-015 lists persistent Work Order description storage among items that are no longer open.

Why it matters

I The gate describes the pre-Revision-BB mutable-description model. It cannot pass without building exactly what W002-UI-023 and W002-STOR-018 prohibit, and it cannot be failed honestly either, because the capability is forbidden.

Impact if frozen as written. A frozen build could never reach BUILT & ACCEPTED on this gate. An implementer who tries to satisfy it would introduce a second, mutable naming path outside the Work Order.

Question / direction for T. Retire or rewrite W002-UI-ACC-019. A natural replacement is a gate proving that there is no Description field, and that changing a WORK ORDER AS alias requires saving a new WKO. That property is already partly exercised by W002-MAT-ACC-002.4, so the rewrite may simply merge into it.

F-02BLOCKING

An aliased Work Order cannot be edited and re-saved, and the WKO alias registry has no retirement path

Cited: W002-STOR-018.2 W002-STOR-018.3 W002-STOR-018.4 W002-UI-020 W002-UI-023 W002-MAT-ACC-002.4

What the contract says

E W002-STOR-018.2 says every row in the WKO MAP is a current visible saved WKO. A non-empty alias must be unique within the current WKO MAP, and a save that would duplicate one must be refused rather than disambiguated.
E W002-UI-020 and W002-UI-023 say that editing a loaded saved WKO, including only its comments, produces a derived draft that must be saved as a new WKO. The derived draft naturally carries the original WORK ORDER AS line.
E W002-MAT-ACC-002.4 requires proof that changing only a comment requires a new WKO identity, and its fixture alias is "Prepare monthly crime data".
E No requirement in the cut removes, retires or supersedes a row in the WKO MAP. W002-STOR-018.3 validates the successor MAP against the referenced visible WKO files.

Why it matters

I The core edit loop — load, tweak, save — refuses for every aliased Work Order unless the analyst also invents a new alias. The MAT-ACC-002.4 fixture, as written, would hit that refusal.
I Because saved WKOs stay current forever, aliases accumulate permanently. A monthly Work Order would need a new alias every month.
I If an analyst deletes an old WKO file, one of two things happens. Either every later save refuses, because the successor copies a row that points at a missing file. Or, if base selection skips MAPs that are no longer valid, it falls back to an older WKO MAP and silently deregisters every WKO saved after the deleted one. The contract does not say which.
I A WKO file copied in from another Suitcase has a canonical name but no registry row. The contract does not say whether it is a valid Run target.

Impact if frozen as written. The most common authoring action fails by default. The registry can also deadlock or silently lose registrations when ordinary file housekeeping happens.

Question / direction for T. The alias needs a lifecycle decision. Should a newer WKO with the same alias supersede the older row, the way successor MAPs work for Stores? Should a derived draft's save offer that supersession explicitly in Work Order text? The contract should also say what happens when a registered WKO file disappears, and whether unregistered but well-formed WKO files may be loaded and Run.

F-03BLOCKING

A missing or damaged RID or COL silently forks the Store, and the RID recovery base is undefined

Cited: W002-STOR-019.10 W002-STOR-019.2 W002-STOR-019.3 W002-STOR-019.11 W002-RID-001 W002-RID-008 W002-RID-009 W002-STEPS-010 W002-STOR-020 W002-WKO-012.5

What the contract says

E W002-STOR-019.10: to take part in automatic or explicit inheritance, a MAP must reference a valid visible RID and valid visible COL files.
E W002-STOR-019.2: Store lineages are distinguished by the exact rid_filename. If no eligible lineage exists for the exact SOURCE, the materialization establishes a new Store with a new RID.
E Every ordinary MAP in a lineage repeats the same rid_filename (W002-STOR-019.8, W002-STOR-019.11). Every MAP after Store establishment also binds the original COLs unless they were rematerialized.
E W002-RID-009 recovers from a recovery-base MAP that is structurally valid apart from its RID binding, so by W002-STOR-019.10 it is not an eligible MAP. W002-STEPS-010 resolves that base by Store alias and operates on the current degraded Store state only.
E W002-STOR-020 leaves cross-Store Store-alias uniqueness outside the freeze. W002-WKO-012.5 lets CLEAR STORE ALIAS store an empty alias. The default Store alias is the source filename (W002-STOR-019.12).
E W002-RID-001 names the stable row reference as (Store recovery lineage, RID value), but the nine-column MAP has no field that links a post-recovery MAP to its pre-recovery predecessor.

Why it matters

I Silent fork. If the RID file goes missing — deleted, moved, or not yet downloaded by a cloud-sync client — every MAP in the lineage becomes ineligible at once. The next ordinary MATERIALIZE with the same SOURCE finds no eligible lineage and quietly creates a brand-new Store with a new RID. The same happens if any original COL file is lost. W002-RID-008 intends that damage leads to an explicit recovery decision, never a side effect of MATERIALIZE. The fork contradicts that intent without technically triggering the rule.
I Lost COLs are unrecoverable. A lost COL cannot be repaired inside the Store. Recovery requires every bound COL to be valid, and rematerialization requires an eligible base MAP, which no longer exists.
I The recovery base is undefined. Nothing says which MAP is the current degraded state. Nothing covers what happens when historical MAPs carry older Store aliases. A Store whose alias was cleared cannot be named by RECOVER RID FOR STORE, and its alias cannot be reset first, because UPDATE ALIASES also needs an eligible MAP.
I Compounding. After a silent fork, two Stores share the default alias, so recovery is ambiguous and refuses. If the old RID file later reappears — for example, the sync client finishes — two eligible lineages exist for one source, and automatic inheritance refuses from then on.

Impact if frozen as written. A routine file-system event can turn a governed Store into a different Store with no warning. That undermines the row-identity promise that WASM-002 exists to prove.

Question / direction for T. Three decisions are needed. First, should MAP eligibility separate structurally valid but degraded from invalid, so that a degraded lineage blocks new-Store creation from the same source and refuses with a Help path pointing to recovery? Second, define recovery-base selection precisely: which MAPs are candidates, how a Store alias matches, and what happens with empty or duplicate aliases. Consider allowing MAP "..." as a recovery selector. Third, decide whether recovery lineage needs a persisted link — a predecessor MAP field or an equivalent — rather than living only in the Receipts.

F-04BLOCKING

A same-filename source refresh has no cardinality check against the inherited RID, and there is no way to start a new Store

Cited: W002-STOR-019.2 W002-RID-005 W002-RID-006 W002-MAT-002.6 W002-MAT-002.7 W002-STEPS-001

What the contract says

E W002-MAT-002.6 reconciles the selected outputs to one shared N among themselves. It does not require that N to equal the inherited RID's N when the run extends an existing Store.
E W002-RID-005 states the alignment invariant, but no requirement assigns the check to a phase, a refusal diagnostic or an acceptance fixture. No acceptance gate materializes a changed-row-count source into an existing Store.
E W002-STOR-019.2 routes on the exact SOURCE filename. A full-text search of the cut finds no syntax that asks for a new Store when an eligible lineage exists.
E The canonical example in W002-STEPS-001 is a monthly Work Order ("Prepare monthly crime data") over a Statistics Canada table that is refreshed under the same filename.

Why it matters

I The expected monthly workflow is: re-download 35100178.csv under the same name and run the saved Work Order again. That automatically routes into last month's Store. If the row count changed, there is no specified point where Data Sculptor must refuse before promotion. The successor MAP could then bind COLs of length N′ to a RID of length N.
I If the row count happens to match, the rows are silently treated as aligned. The assurance boundary accepts that risk explicitly, and Help carries it (W002-HELP-011). A count mismatch, though, is something the engine can detect cheaply, so it should not rely on Help alone.
I Even when the analyst knows the file is new, the only way to get a fresh Store is to rename the source. That turns the filename into a hidden control channel, which W002-WKO-007 is meant to prevent.

Impact if frozen as written. Misaligned columns could be committed as same-Store state, or the analyst is forced into filename tricks to express intent.

Question / direction for T. Add an explicit requirement for existing-Store materialization: the accepted N must equal the inherited RID's N before any promotion, or the run refuses, with a named phase, diagnostic and acceptance fixture. Then decide how an analyst expresses "this is a new row universe" in Work Order text — a NEW STORE clause or an equivalent — instead of by renaming files.

F-05BLOCKING

The source-to-MAP compatibility rule is referenced but never defined

Cited: W002-STOR-019.3 W002-WKO-012.3 W002-WKO-ACC-008 W002-STOR-019.6

What the contract says

E W002-STOR-019.3 says the named Store MAP must be compatible with the materialization source "under the existing source/Store rules". W002-WKO-012.3 says validation must refuse an incompatible source/MAP pairing.
E W002-WKO-ACC-008 requires a refusal fixture for source/MAP incompatibility.
E The nine-column MAP carries a per-row source_filename separate from store_source_filename (W002-STOR-019.6). The schema therefore allows COLs from sources other than the one that established the Store.

Why it matters

I No requirement in the cut defines "the existing source/Store rules". The key question: may an explicit MAP bring a different source file into an existing Store? If so, that is a positional join by physical row order — the exact kind of silent alignment the product is built to avoid. If not, the separate source_filename column needs a stated purpose in WASM-002.

Impact if frozen as written. A mandatory refusal fixture cannot be written independently, and the implementer would be deciding a join-semantics question on their own.

Question / direction for T. Freeze the compatibility predicate. Is it exact equality of SOURCE with store_source_filename? Or equality plus the N check from F-04? Or something broader? And state what the per-row source_filename is for in WASM-002.

F-06BLOCKING

The CSV dialect and the rules for malformed input are not frozen

Cited: W002-MAT-002.8 W002-MAT-003.2 W002-MAT-003.3 W002-MAT-ACC-003 W002-MAT-ACC-004 W002-MAT-ACC-005 PB-OPS-001

What the contract says

E The cut specifies field-count shape (W002-MAT-002.8), the field-size limit, blank-record refusal and output quoting (W002-MAT-002.11). It does not specify the input grammar.
E A full-text search finds no statement that comma is the only delimiter, and nothing on bare CR as a record terminator.
E W002-MAT-003.2 requires the first deterministic refusal condition and its location to be invariant across windows. W002-MAT-ACC-003 and -005 require fixtures for malformed cases.

Why it matters

I Each of these needs a frozen answer before independent fixtures can be written:
(a) A quote inside an unquoted field, for example ab"c.
(b) Characters after a closing quote, for example "ab"c.
(c) A bare CR, and CR followed by something other than LF.
(d) Whether the last record may omit its terminator.
(e) Whether a trailing extra line ending at EOF is a bare blank record, and so a refusal under W002-MAT-002.8. Exported files very often end this way.
(f) One-column sources. In a one-column CSV, an unquoted empty value is exactly a blank line, so W002-MAT-002.8 makes any externally exported one-column file with an empty value refuse.
(g) Whether delimiters other than comma — the semicolon files common in some locales — are out of scope, and if so, which diagnostic tells the analyst.
I The historical toolchain crate csv is lenient on (a) and (b) by default. An implementation built on it would decide these questions silently.

Impact if frozen as written. Refusal location and condition are required to be deterministic, but the rules that determine them are not in the contract. QA cannot derive the oracle before seeing a candidate.

Question / direction for T. Freeze a short normative input grammar, either as RFC 4180 with explicit deviations or as a state table, covering (a) through (g). Say which cases refuse, and with which fact that locates them — byte offset, logical row, or physical line.

F-07BLOCKING

The meaning of the UTF-8 first-invalid offset is undefined, and the frozen error contract it points to is not in the cut

Cited: W002-ENC-004.10 W002-ENC-ACC-006 W002-ENC-ACC-007 W002-ENC-ACC-008 W002-ENC-ACC-009

What the contract says

E W002-ENC-004.10 requires the exact absolute offset "required by the frozen error contract". Searching the cut for "error contract" finds only this reference.
E W002-ENC-ACC-006 requires rejection "at known exact offsets". W002-ENC-ACC-009 requires "the governed offset" for a sequence truncated by EOF.

Why it matters

I For the bytes E2 82 41, is the reported offset the lead byte (E2) or the first offending byte (41)? For a lone continuation byte, it is obviously that byte. For a sequence truncated by EOF, is it the lead byte or the file length? For a sequence that spans a window boundary, is the offset still absolute? Presumably yes, but it should be stated.
I Rust's Utf8Error::valid_up_to reports the start of the invalid sequence. The WASM-001b fixtures may already embody a convention, but the contract does not carry it.

Impact if frozen as written. The invalid-sequence matrix cannot be authored as an independent oracle. Two correct implementations could disagree while both satisfy the text.

Question / direction for T. Import or restate the error contract. For example: the offset is the absolute byte offset of the first byte of the maximal invalid prefix, and a truncated sequence at EOF reports its lead byte. Add the reported fact names — offset, stop reason, and the offending-bytes window if any — to the diagnostic definition.

F-08BLOCKING

The DS-STEPS lexical rules are incomplete, and the "governed string-literal rules" they cite are not in the cut

Cited: W002-STOR-018 W002-STEPS-001 W002-STEPS-001.1 W002-STEPS-001.2 W002-STEPS-003 W002-WKO-012.1 W002-WKO-013 W002-WKO-ACC-006

What the contract says

E W002-STOR-018 refers to "the governed string-literal rules". Searching the cut finds no definition.
E W002-STEPS-001 freezes keyword structure and selector forms, and leaves "other complete-language lexical features" outside the freeze.
E W002-WKO-ACC-006 requires refusal of "RUN or other recognized Work Order-invocation construct". The set of recognized constructs is not listed.

Why it matters

I Unanswered questions include:
How does a string contain a double quote? A header with a " could then only be chosen by COLUMN n, and a source filename or alias could never contain one.
Are keywords case-sensitive? The prototype matches them case-insensitively.
How are leading whitespace and indentation handled?
How is COLUMN 07 or COLUMN +7 treated?
Is clause order enforced, or only canonical?
What happens with a duplicate SOURCE, KEEP or MATERIALIZE, an empty KEEP, or text after MATERIALIZE?
Does any unrecognized line refuse?
Operation mixing: may a MATERIALIZE Work Order also carry STORE AS, RID AS, CLEAR or RESET? W002-STOR-019.5's "and/or" suggests yes. W002-WKO-012.1 only restricts the alias-only form.
WKO byte form: UTF-8 is implied but not stated. Is a BOM allowed? Are CRLF line endings allowed? W002-STEPS-001.2 says comments are preserved byte-for-byte, so whatever the editor produces becomes identity-bearing.
Composition fixture: if save-time validation refuses composition syntax, a "structurally saved WKO containing RUN" can only exist as a hand-made file. That runs into the WKO validity questions in F-02 and F-14.

Impact if frozen as written. Save-time validation, run-time validation and the chaining-refusal gate all depend on rules the implementer would have to invent.

Question / direction for T. Add a compact lexical section: string-literal escaping (or an explicit statement that there is none, with the consequences); keyword case; whitespace; ordinal numerals; clause cardinality and order; the rule that unknown lines refuse; allowed operation combinations; the WKO byte encoding; and the exact set of composition tokens that trigger the deferred-composition diagnostic.

F-09BLOCKING

Receipt and Inventory TXT must be tested byte-for-byte, but their serialization is not specified

Cited: W002-RCP-005 W002-RCP-006 W002-RCP-007 W002-RCP-008 W002-CONV-004.2 W002-INV-006

What the contract says

E W002-RCP-005 requires one deterministic escaping rule that is "acceptance-tested byte-for-byte", but leaves the rule to the implementation.
E W002-RCP-006 lists the core keys "at least". It does not freeze tokens for OPERATION, the explicit none token for DIAGNOSTIC_ID, or how the filenames after CREATED_ARTIFACT_COUNT are serialized — repeated keys, indexed keys, or continuation lines.
E W002-RCP-007 requires "not-run/not-available tokens" but does not name them.
E W002-CONV-004.2 writes SOURCE_ENCODING=WINDOWS-1252-COMPATIBLE with =, while W002-RCP-005 mandates KEY: VALUE. It also allows "or the exact equivalent terminology".
E W002-RCP-008 gives facts for INVENTORY, conversion and RECOVER RID but none for UPDATE ALIASES (base MAP, successor MAP).
E W002-INV-006 requires an unambiguous filename representation and ordering, but not the actual line format.

Why it matters

I A byte-for-byte test needs a spec-side oracle. With the rule left to the implementer, QA can only check self-consistency, not conformance.
I Some refusals happen before an operation is known — an unparseable WKO, for instance — and OPERATION has no defined value for that case.

Impact if frozen as written. Receipts are the Flight Recorder substrate. Leaving their grammar to the implementation weakens the "I can show somebody else" promise at its foundation.

Question / direction for T. Freeze a small TXT grammar shared by RCP and INV: the key set and order per operation, enumerated tokens (including the none, not-run, not-available and unknown-operation values), text escaping, and the list-valued form. Add the UPDATE ALIASES fact section. One golden Receipt per operation in the contract would close this.

F-10BLOCKING

Windows-1252 conversion has no Work Order form, output contract or class-level serialization

Cited: W002-CONV-001 W002-CONV-001.4 W002-CONV-004 W002-CONV-004.1 W002-CONV-ACC-001 W002-CONV-ACC-002 PB-STOR-006

What the contract says

E W002-CONV-001 makes conversion a distinct Work Order operation, and W002-CONV-ACC-001 requires it to be run. The canonical DS-STEPS forms in the cut cover MATERIALIZE, INVENTORY, UPDATE ALIASES and RECOVER RID only.
E CVT is registered (PB-STOR-006). No requirement gives its extension, its BOM policy, whether line endings are preserved, whether it goes through SCR staging, or its relationship to later Store routing.
E W002-CONV-004 asks for "canonical UTF-8 output" without defining canonical.
E W002-CONV-ACC-001 does not check the source-unchanged rule (W002-CONV-001.3) or the Receipt facts (W002-CONV-004.2 through .4).

Why it matters

I Converted output presumably becomes the SOURCE of a later Store. Its bytes — BOM, line endings — therefore feed directly into Stage 1 and Stage 2 and into the default Store alias, which will be the long CVT filename.

Impact if frozen as written. An in-scope operation with an acceptance gate cannot be implemented without inventing its syntax and output bytes.

Question / direction for T. Add the canonical conversion Work Order form, the CVT serialization (extension, BOM, byte-preserving line endings, publication path) and golden-byte fixtures. Extend W002-CONV-ACC-001 to check that the source is unchanged, that the output is certifiable, and that the Receipt facts are present. Or, if conversion is not really ready, re-scope it deliberately.

F-11BLOCKING

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

Cited: W002-STOR-010 W002-STOR-010.3 W002-STOR-010.4 W002-STOR-010.1 PB-STOR-002 W002-STOR-003.5

What the contract says

E W002-STOR-010 says the Store Index must provide a persistent HTML orientation layer, and W002-STOR-010.4 says it is static durable HTML. Both are SCOPE WASM-002.
E No registered class fits it (PB-STOR-006). W002-STOR-003.5 requires every WASM-002-generated governed artifact to use a listed class.
E W002-STOR-010.1 forbids a second separately named Store-metadata file. No requirement says when an Index is generated, or what it contains beyond orientation.

Why it matters

I This reads like a pre-Revision-AY concept that the Suitcase Directory (W002-UI-006) and the MAP snapshots have since replaced. As written, the implementer must either mint an unregistered class, breaking W002-STOR-003.5, or leave a normative requirement unmet.

Impact if frozen as written. Cheap to fix, but it cannot be frozen as it stands.

Question / direction for T. Re-scope W002-STOR-010, 010.3 and 010.4 to V1-BACKLOG, or recast them as the Suitcase Directory's orientation role. PB-STOR-002's "Store Map/Index" wording would follow.

F-12MATERIAL NON-BLOCKING

Selecting current state by the greatest UTC has no guard against clock movement

Cited: PB-STOR-013 PB-STOR-011 W002-STOR-019.2 W002-STOR-018.4

What the contract says

E Current Store MAP and current WKO MAP are both chosen by greatest canonical UTC, with ties refused.
E A search of the cut for clock or monotonic finds nothing. PB-STOR-011 forbids advancing a timestamp to escape a collision.

Why it matters

I A host clock that steps backward — an NTP correction, a Suitcase moved to a machine with a skewed clock, or a virtualized laptop — can give a successor MAP an earlier token than its base. The older snapshot then silently remains current.
I Two successive publications within the same millisecond produce a tie. That makes the product refuse its own state until an explicit MAP is used.

Impact if frozen as written. Silent staleness, or self-inflicted refusal, both of which only an expert could diagnose.

Question / direction for T. Consider a rule that a successor's transaction UTC must be strictly greater than its base's. Decide whether a violation should refuse with a Help explanation, or wait and re-read the clock. Then test it with an injected clock (see F-23).

F-13MATERIAL NON-BLOCKING

The single-writer assumption is not stated

Cited: W002-ARCH-014 W002-STOR-018.3 W002-STOR-019.5 W002-HELP-011.2

What the contract says

E W002-ARCH-014 makes analytical execution sequential within the product. A search of the cut finds no rule for two tabs, two browsers, a sync client, or the later native CLI writing to the same Suitcase.

Why it matters

I Two tabs saving from the same base WKO MAP each publish a successor, and the later one drops the other's registration — a lost update. The same race applies to Store MAP successors.
I Sync clients such as OneDrive can add conflict copies with ordinary names, and can present files as cloud placeholders that are "missing" until downloaded. That feeds directly into F-03.

Impact if frozen as written. Lost updates, and state flipping between committed and missing, with no diagnostic.

Question / direction for T. State the single-writer assumption as a contract boundary. Decide whether WASM-002 must detect a changed base at commit time — for example, by re-checking that the base is still the newest immediately before the final rename — or only explain the risk through Help.

F-14MATERIAL NON-BLOCKING

Publication and validity rules for non-Store artifacts are undefined

Cited: PB-STOR-008 PB-STOR-012 W002-STOR-018.3 W002-RCP-010 W002-MAT-002.6 W002-INV-002 W002-STOR-022 W002-HELP-009

What the contract says

E Store artifacts have a full SCR-to-final commit protocol. For WKO (W002-STOR-018.3 persists the WKO directly), RCP, INV, CER, HLP and CVT, the cut does not say whether bytes are staged as SCR or written directly under the final name.
E PB-STOR-008 requires content validation before any governed artifact is trusted. Validity criteria exist only for the two MAP profiles, RID and COL.
E SCR and RCV candidates have no filename rule — extension, whether the timestamp changes on promotion — and no content rule. "Attributable SCR/RCV evidence" (W002-MAT-002.6) has no attribution mechanism. The Receipt is not required to list retained SCR/RCV files.

Why it matters

I If a write is interrupted, it can leave a truncated file with a canonical RCP, INV or WKO name. The Flight Recorder, the WKO chooser and INVENTORY then need a rule for deciding whether it is real.
I Chromium's File System Access writable streams stage writes through a sibling .crswap file in the same directory. An interrupted write can therefore leave non-governed debris in the flat Suitcase. That is probably covered by PB-STOR-001's incidental-cache carve-out, but Help and INVENTORY should expect it. This should be verified on the target browser.

Impact if frozen as written. Evidence artifacts could be counterfeit or partial without anything detecting it, and debris could not be attributed to the run that left it.

Question / direction for T. Define a per-class publication path — direct write, or SCR then rename. Define minimal validity checks per class, including what makes a WKO loadable and Runnable. Define SCR/RCV naming and content. Require the Receipt to list any SCR/RCV evidence a run leaves behind.

F-15MATERIAL NON-BLOCKING

MAP eligibility can change when unrelated files appear, and the comparison rules are undefined

Cited: W002-STOR-020 W002-STOR-019.10 W002-STOR-019.2 PB-STOR-010 W002-STEPS-002

What the contract says

E W002-STOR-020 forbids aliases that silently shadow another visible physical filename "under the applicable filename-comparison rules". Those rules are not defined in the cut.
E W002-STOR-019.10 includes alias constraints in the eligibility test.
E W002-STOR-019.2 routes on the exact SOURCE string. PB-STOR-010 acknowledges case-insensitive file systems.

Why it matters

I Dropping a file named GEO into the Suitcase could make the current MAP, whose COL alias is GEO, ineligible. That leads to silent fallback or a fork (F-03), caused by an unrelated file.
I On NTFS, SOURCE "Crime.csv" and SOURCE "crime.csv" may open the same file, yet they route to different Store lineages.
I On macOS, a name typed in NFC and a file stored in NFD can open the same file while comparing unequal byte-for-byte. The same concern applies to HEADER matching on decoded bytes.

Impact if frozen as written. Store routing becomes a function of unrelated folder contents and of platform file-name semantics.

Question / direction for T. Define the comparison rule: exact bytes, case-folded, or normalized. Decide whether shadowing is checked only when a MAP is published, rather than every time eligibility is evaluated. Decide whether source routing must detect case or normalization aliases of the same physical file.

F-16MATERIAL NON-BLOCKING

The conversion suggestion conflicts with fixed diagnostic semantics, and the Windows-1252 mapping is not frozen

Cited: W002-HELP-001.6 W002-HELP-001.7 W002-HELP-001.8 W002-CONV-002 W002-CONV-002.1 W002-CONV-002.3 W002-CONV-002.4 W002-CONV-003.5 W002-ENC-004.10

What the contract says

E next_action is a fixed per-diagnostic value from the registry. The registry example gives DS-ENC-001 the value CONVERT_SOURCE_TO_UTF8.
E W002-CONV-003.5 says Help must not recommend conversion when the bytes are not compatible. Compatibility depends on every byte in the file.
E W002-ENC-004.10 lets certification stop at the first invalid byte. W002-CONV-002 says an assessment "may" run after failure, but not when, in which run, or with what evidence.
E W002-CONV-002.1 refers to "the frozen Windows-1252 rules", but no mapping table or normative reference is in the cut.

Why it matters

I One diagnostic ID cannot carry both "convert" and "don't convert". At least three outcomes need separate IDs: compatible, incompatible, and not assessed.
I Assessing compatibility requires another pass over the whole file inside a refused run. Its time and Receipt facts are unspecified.
I The WHATWG Encoding Standard, which encoding_rs implements, decodes Windows-1252 without errors: bytes 0x81, 0x8D, 0x8F, 0x90 and 0x9D map to the matching C1 control code points. A converter built on it would silently convert exactly the bytes that W002-CONV-002.3 and 002.4 say must refuse.
I Almost any byte stream counts as "compatible", including UTF-16 or Shift-JIS files. So a compatibility-based suggestion can recommend a conversion that produces nonsense, even though the wording avoids calling the file Windows-1252.

Impact if frozen as written. As written, Help would either break W002-CONV-003.5 or have to override the registry. The defined-byte rule could also be lost to a library default.

Question / direction for T. Split the certification-failure diagnostics by assessment outcome. Specify when the assessment runs and what the Receipt records. Freeze the mapping explicitly: the Microsoft best-fit table minus the five undefined bytes, with a pre-check that refuses them. Consider whether Help should also flag patterns such as NUL-heavy content as reasons not to suggest conversion.

F-17MATERIAL NON-BLOCKING

The Help rendering contract is missing a coverage fallback, absent-value rendering, and a consistent notion of required facts

Cited: W002-HELP-001.4 W002-HELP-001.8 W002-HELP-002.9 W002-HELP-002.10 W002-HELP-004.11 W002-UI-007

What the contract says

E Build validation fails on Help-catalog IDs that are missing from the registry, but not on registry IDs that are missing from the catalog. W002-HELP-002.9 only requires coverage for the diagnostics exercised in acceptance.
E W002-HELP-001.4 says every required fact must be present at emission. W002-HELP-004.11 speaks of a "required boundary fact" that is unavailable.
E Placeholders may reference optional facts (W002-HELP-002.10). The cut does not define how an absent optional fact renders, or how Boolean, integer, null or list values render inside prose.

Why it matters

I At runtime, a registry diagnostic with no catalog entry has no specified rendering, yet W002-UI-007 routes all user-facing guidance through Help. Absent-value rendering is exactly where the "missing must not become false" rule can quietly fail.

Impact if frozen as written. There are paths where Help cannot render truthfully, or where fallback prose gets invented in the UI.

Question / direction for T. Either require full catalog coverage of the registry at build time, or define a governed fallback rendering. Decide whether the boundary facts are optional-when-unavailable or required-and-nullable. Freeze how each value type renders, including absent values and a literal brace.

F-18MATERIAL NON-BLOCKING

HLP provenance merges "not applicable" with "unavailable", and absence tokens differ across artifacts

Cited: W002-HELP-009 W002-RCP-010 W002-HELP-004.11 W002-RCP-007

What the contract says

E W002-HELP-009 uses JSON null, displayed as NOT APPLICABLE, when no WKO or RCP relationship exists.
E W002-RCP-010 describes runs where the Receipt could not be published.
E Absence is "unavailable" in W002-HELP-004.11 and "not-run/not-available" in W002-RCP-007.

Why it matters

I A Help Report for a run whose Receipt failed to publish would say the RCP is NOT APPLICABLE. That is a false negative statement in the very artifact meant for support handoff.

Impact if frozen as written. A small misstatement, but in the evidence surface where honesty matters most.

Question / direction for T. Separate "no relationship exists" from "relationship exists but its artifact is unavailable" in both the JSON and the visible Provenance section. Consider one shared absence vocabulary across RCP, HLP and diagnostics.

F-19MATERIAL NON-BLOCKING

HLP disclosure edge cases: a header can be data, and aliases are not covered by the allowlist

Cited: W002-HELP-010 W002-HP-ACC-011

What the contract says

E The allowlist admits the "relevant source column header". It does not mention Store, RID, COL or WKO aliases in any tier.

Why it matters

I If the analyst's CSV has no header row, the first data record is parsed as the header. "Header" disclosure is then disclosure of source values, which is the thing the policy forbids.
I Aliases are analyst-authored text, often the most helpful explanatory label. Under the strict allowlist reading they are excluded. Under a loose reading they might leak. The policy should say which.

Impact if frozen as written. Possible data leakage through a permitted channel, and uncertainty over which labels a report may use.

Question / direction for T. Decide whether headers are disclosed as metadata with a Help caveat, or only by ordinal when the diagnostic concerns header parsing. Add aliases to an explicit tier.

F-20MATERIAL NON-BLOCKING

"Bounded memory" has no stated limits, and header width and KEEP width are unlimited

Cited: W002-ENC-001.5 W002-MAT-002.5 W002-MAT-003.1 W002-MAT-001.7 W002-MAT-002.10 W002-MAT-ACC-006

What the contract says

E "Governed WASM memory budget" appears three times with no value. W002-MAT-ACC-006 records "peak/bounded memory observations" with no threshold.
E W002-MAT-001.7 keeps the full ordered header metadata. W002-MAT-002.10 limits each field to 16 MiB but sets no limit on field count or total header size.
E There is no limit on the number of KEEP selectors, and so no limit on concurrent writers or open file handles.

Why it matters

I A runaway or binary header row with millions of fields grows memory in proportion to the input. That is the exact failure mode bounded processing is meant to rule out. A very wide KEEP list multiplies per-writer staging and browser writable handles.

Impact if frozen as written. "Bounded" cannot be accepted or rejected objectively.

Question / direction for T. Set a numeric budget, or a measurable test such as "peak must not grow when N or source size doubles". Add limits on header field count and bytes, and on KEEP width, each with a diagnostic.

F-21MATERIAL NON-BLOCKING

Publishing from a historical MAP silently changes what is current

Cited: W002-STOR-019.3 W002-WKO-ACC-008 W002-STOR-019.2

What the contract says

E W002-WKO-ACC-008 requires an alias-only successor to be published from an explicitly named older base.
E W002-STOR-019.2 then picks the newest MAP in the lineage as current.

Why it matters

I The branch successor becomes current, and any COLs or aliases added after the older base drop out of current state. This may be the intended way to roll back, but nothing says so, and Help is not required to warn about it.

Impact if frozen as written. An analyst using MAP to inspect or tweak history can silently revert the Store.

Question / direction for T. Say explicitly that branching is allowed and that the newest branch wins, and require Help and the Receipt to state which base was used and that later state was superseded. Or forbid successors from non-newest bases.

F-22MATERIAL NON-BLOCKING

Expected diagnostics come from a registry the implementer delivers, which undercuts QA independence

Cited: W002-HELP-001.8 W002-HP-ACC-013

What the contract says

E W002-HELP-001.8 says the PRD need not list the allocated diagnostics, and that "the complete registry delivered with the build is retained acceptance evidence."

Why it matters

I Many gates depend on "the canonical diagnostic" for a named condition, but the set of conditions, their required facts and their behavior (CONTINUE or REFUSE) are defined by the candidate itself. That reverses the contract-before-code principle. QA would be checking the build against a document the build supplied.

Impact if frozen as written. The oracle is weakened for every refusal gate.

Question / direction for T. Without allocating IDs, freeze a minimum condition catalog: each distinct refusal and warning condition the contract implies, with its phase, behavior and required facts. The registry must then cover it. IDs can remain implementation-allocated.

F-23MATERIAL NON-BLOCKING

Acceptance coverage has gaps, and test seams are missing

Cited: W002-WKO-012.5 W002-WKO-012.6 W002-RCP-010 PB-STOR-011 W002-STOR-007.3 PB-STOR-009 PB-STOR-010 W002-STOR-018.3 W002-HELP-002.11 W002-ENC-ACC-003

What the contract says

E No gate found for: CLEAR and RESET alias forms, including RESET refusal on an empty header and duplicate-field mutation (W002-WKO-012.5 and .6); Receipt-publication failure (W002-RCP-010); non-zero collision retries (PB-STOR-011, W002-STOR-007.3); preserving and reporting unknown classes (PB-STOR-009); case-variant governed names (PB-STOR-010); WKO save-transaction failure and rollback (W002-STOR-018.3); the embedded catalog's HTML safety and no-runtime-fetch rule (W002-HELP-002.11); and UPDATE ALIASES and INVENTORY Receipt facts.
E Several gates need fault injection — rename failure, UUID collision, source substitution (W002-ENC-ACC-003), a clock step — that an honest build cannot produce on demand.

Why it matters

I Without an explicitly allowed test seam, either these gates cannot be exercised, or the build grows undocumented hooks. Undocumented hooks are exactly the hidden alternate path the contract otherwise forbids.

Impact if frozen as written. Requirements that are frozen but untested, or test hooks that nothing governs.

Question / direction for T. Add the missing gates. Add one requirement that allows test-only injection of the clock, UUID source, file-system faults and source handles, compiled out of release builds or otherwise provably inert, and that records the retained evidence showing the hooks are absent from the release.

F-24MATERIAL NON-BLOCKING

Session model: a new CER every session, no remembered Suitcase, no preferences, and lost drafts

Cited: W002-UI-017 W002-STOR-022 PB-STOR-001

What the contract says

E W002-UI-017 requires a new certificate before the workspace unlocks. PB-STOR-001 forbids browser-private persistence of project metadata.

Why it matters

I Remembering the chosen directory handle across sessions needs IndexedDB, which is arguably forbidden. So every session means re-picking the folder and adding another CER — hundreds a year.
I Does PB-STOR-001 also forbid remembering the theme or Help voice?
I Unsaved WIP drafts cannot be autosaved anywhere, so closing the tab loses them. The contract is silent on warning the user.

Impact if frozen as written. Daily friction, and a Suitcase that fills with CER files over time.

Question / direction for T. Decide whether re-selecting a Suitcase that already holds a CER needs a fresh CER. Decide whether a directory handle and UI preferences count as project metadata. Decide whether unsaved-draft loss must be warned about.

F-25MATERIAL NON-BLOCKING

The target platform and the small-screen baseline are not defined within the cut

Cited: W002-UI-011 W002-UI-ACC-007 W002-STOR-022.1 W002-RID-004 W002-MAT-002.11

What the contract says

E Several requirements refer to a "supported host", the "canonical small-screen baseline" and "the canonical low-end Windows laptop". None of these is defined in the cut.

Why it matters

I The whole design depends on the File System Access directory picker and writable streams. Those are Chromium-only, and some operations, such as handle rename, vary by version. The browser set, minimum versions and the screen size are acceptance inputs, not presentation details.

Impact if frozen as written. Gates W002-UI-ACC-007 and W002-UI-ACC-011 cannot be run reproducibly.

Question / direction for T. Name the supported browsers and minimum versions, and the reference device and resolution, in a WASM-002 requirement. Or import the master definition into the cut.

F-26MATERIAL NON-BLOCKING

Allowed SOURCE reference forms are undefined

Cited: W002-WKO-009 W002-INV-005 PB-STOR-005

What the contract says

E File references resolve relative to the Suitcase (W002-WKO-009). User subdirectories may exist (W002-INV-005). No rule covers path separators, .., absolute paths, or pointing SOURCE at governed artifacts (a COL, a CVT) or at non-CSV files.

Why it matters

I SOURCE "sub/x.csv" and SOURCE "../x.csv" need a deterministic refusal or a defined meaning. The .. case is also a Suitcase-boundary question.
I Using a COL as a source is plausibly useful but creates Store-within-Store lineage.

Impact if frozen as written. Portability and Suitcase-boundary guarantees depend on implementation choices.

Question / direction for T. Restrict SOURCE to a bare filename in the Suitcase root, or define the permitted forms. State the policy for governed-artifact and non-CSV sources.

F-27CLARITY

W002-UI-006 says "editable human alias"

Cited: W002-UI-006 W002-UI-019 W002-UI-024

What the contract says

E W002-UI-006 lists an "editable human alias where applicable" among the directory columns. W002-UI-019 and W002-UI-024 say aliases in the directory are read-only.

Why it matters

I The gates enforce read-only behavior, so this is wording, but it invites someone to build an inline editor.

Impact if frozen as written. Wording hazard.

Question / direction for T. Change it to "read-only governed alias where applicable".

F-28CLARITY

Brand-Manifest wording survives in in-scope text

Cited: W002-UI-016 W002-INV-006 W002-STOR-022.2 W002-HELP-003.2 W002-HP-ACC-003

What the contract says

E The cut still says: "Brand ... requirements" (W002-UI-016), "branded, UTF-8 TXT" (W002-INV-006), "brandable HTML certificate" (W002-STOR-022.2), and "branded HTML Help report" (W002-HELP-003.2, W002-HP-ACC-003).

Why it matters

I Brand Manifest is deferred. "Branded" presumably means the built-in Red5Sorcery/Data Sculptor presentation, but for a TXT inventory the word has no defined meaning.

Impact if frozen as written. Invites scope creep, or a debate over what "branded" TXT means.

Question / direction for T. Replace with "uses the canonical built-in presentation" where HTML, and remove it for TXT.

F-29CLARITY

Section headings misplace in-scope requirements and are out of order

Cited: W002-WKO-007 W002-WKO-012.1 W002-CONV-ACC-001 W002-STOR-016 W002-WKO-ACC-003

What the contract says

E In-scope UPDATE ALIASES, CLEAR and RESET (W002-WKO-012.x) and the Work Order contract (W002-WKO-007 to 013) sit under the heading "Work Order Composition — Deferred Beyond WASM-002".
E Conversion and Help acceptance gates sit under "6A. Future Commercial White-Label Service".
E W002-STOR-016 to 022 (WKO identity, MAPs, CER) sit under "Suitcase Inventory Snapshot".
E The in-scope non-composition gates sit under "Composable Work Order Acceptance Gates".
E The numbering runs 2, 3, 1, 2, 3, 4, 7, 6A, 9, 9, 8, with two headings numbered 9.

Why it matters

I These are extraction artifacts, but a reader scanning headings would conclude that in-scope alias maintenance is deferred.

Impact if frozen as written. Misleading navigation in the authoritative review cut.

Question / direction for T. Regenerate headings from requirement SCOPE, or add a note in the cut that headings are inherited from the master and not authoritative.

F-30CLARITY

Truncated text in titles, evidence and rationale

Cited: W002-ENC-006 W002-STOR-001.2 W002-ENC-004.1

What the contract says

E EVID-W001B-UTF8-003 in W002-ENC-006 stops mid-sentence ("...rather than merely shrinking") and runs straight into EVID-004.
E Many requirement titles are sentence fragments that continue into the body, for example W002-STOR-001.2 and most of W002-ENC-004.x and 005.x.
E The heading "Design rationale — why Help is part of the workspace" has no content.

Why it matters

I Probably mechanical splitting during extraction. The content appears intact apart from EVID-003.

Impact if frozen as written. Readability, and one damaged evidence statement.

Question / direction for T. Repair EVID-003 and the rationale block from the master, and merge fragment titles.

F-31CLARITY

Numbering gaps are not explained

Cited: W002-RCP-005 W002-HP-ACC-008 W002-WKO-007 W002-ARCH-008

What the contract says

E The cut skips PB-STOR-003, W002-RCP-004, W002-HP-ACC-005 to 007, W002-WKO-001 to 006 and 011, W002-WKO-ACC-001 and 002, and W002-ARCH-007, 009, 010, 012 and 013.

Why it matters

I These are presumably requirements that are out of scope in the master. The cut lists external references but not omitted siblings, so a reviewer cannot confirm that nothing load-bearing — such as a Receipt requirement at RCP-004 — was dropped.

Impact if frozen as written. An audit trail gap.

Question / direction for T. Add an omitted-ID table (ID, current SCOPE, STATUS) to the cut's front matter.

F-32CLARITY

Terminology drift

Cited: PB-STOR-002 PB-STOR-006 W002-STOR-009 W002-STOR-010.1

What the contract says

E The same concept appears as "Store Map", "Store MAP", "MAP", "Store / Artifact Map" and "Store Map/Index", and the Store Index is now vestigial (F-11).

Why it matters

I The MAP class now has two profiles, so "MAP" alone is ambiguous in some places.

Impact if frozen as written. Minor, but it matters for the LLM-readability goal in W002-STOR-014.

Question / direction for T. Use "Store MAP" and "WKO MAP" consistently, and "MAP" only for the class.

F-33CLARITY

Some registered classes have no WASM-002 producer or contract, and unknown-class reporting is unspecified

Cited: PB-STOR-006 PB-STOR-009 W002-STOR-003.5

What the contract says

E DGN is registered, but no WASM-002 requirement emits or validates it.
E RCV is referenced as a retention outcome, with no creation mechanics.
E PB-STOR-009 says "report" unknown classes without saying where or when.

Why it matters

I Say whether DGN is reserved-not-emitted, like LCK.

Impact if frozen as written. Minor ambiguity.

Question / direction for T. Mark DGN as reserved-not-emitted, or define it. Define RCV together with F-14. Say whether unknown-class reporting is an INFO diagnostic, a directory annotation, or both.

F-34CLARITY

Smaller underspecified points

Cited: W002-HELP-005 W002-HELP-009 W002-INV-005 W002-STOR-014 W002-STOR-012 W002-UI-ACC-016 W002-UI-007 W002-HELP-006 W002-RID-004 W002-STOR-022.1

What the contract says

E W002-HELP-005: the "explicitly permitted run-specific fields" are not listed.
E W002-HELP-009: data_sculptor_build is "WASM-002", which cannot tell patch builds apart.
E W002-INV-005: the inventory "may" identify directories, which conflicts with deterministic serialization.
E W002-STOR-014: the public documentation has no deliverable or gate.
E W002-STOR-012: whether the UI must present the Flight Recorder is not stated.
E W002-UI-ACC-016: "current governed context" is undefined when there are several Stores or branches.
E W002-UI-007 against W002-HELP-001: are success and info messages (save succeeded, Suitcase validated) canonical INFO diagnostics?
E How many HLPs per run when a run emits several diagnostics?
E W002-HELP-006: does interpolation and rendering live in the shared Rust core or in the browser layer?
E W002-RID-004: the byte form for N=0 (BOM plus RID plus LF) is implied but not stated.
E W002-STOR-022.1: the CER filename is 73 characters (.html), and the other defined governed names are 72. The path test is valid only as long as no SCR/RCV name is longer, which is worth stating as an invariant.

Why it matters

I Each is small. Together they are the difference between a contract and a strong draft.

Impact if frozen as written. Minor.

Question / direction for T. Resolve inline during the next revision.

6. Decisions requested from T

These are the questions whose answers would unblock the most findings. Each points back to its finding.

Work Order alias lifecycle: should a newer WKO with the same alias supersede the older row? What happens when a registered WKO file disappears? Are unregistered well-formed WKOs Runnable? (F-02)
Degraded Stores: should damage to a RID or COL block new-Store creation from the same source, and refuse with a pointer to recovery? Should recovery accept a MAP "..." selector, and should recovery lineage be persisted in the MAP? (F-03)
Monthly refresh: how does an analyst say "new row universe" in Work Order text? Should an N mismatch against the inherited RID be a named refusal? (F-04)
May an explicit MAP bring a different source into an existing Store in WASM-002? What does the per-row source_filename mean in this build? (F-05)
CSV input grammar: strict RFC 4180, or RFC 4180 with named deviations? What happens at EOF, with bare CR, and with one-column sources? Is comma the only delimiter? (F-06)
UTF-8 offset convention: lead byte, or offending byte? (F-07)
Is Windows-1252 conversion truly ready for WASM-002, or should it be re-scoped until its Work Order form and output bytes are frozen? (F-10)
Is the Store Index retired in favor of the Suitcase Directory? (F-11)
Should current-state selection require strictly increasing transaction UTC? (F-12)
Is single-writer a stated boundary, and must WASM-002 detect a changed base at commit? (F-13)
Should a minimum diagnostic condition catalog be frozen in the contract, ahead of the implementer's registry? (F-22)
Are test-only injection seams allowed, and how is their absence from release builds evidenced? (F-23)
Does re-opening an already-certified Suitcase need a new CER each session? (F-24)

7. What held up under attack

The commit-point discipline for Store state — SCR, complete-set validation, RID first, MAP rename last — is rigorous and testable. It is also stated in several places with the same meaning, which is rare.
The honesty boundaries are unusually well defined: missing never means false, the four boundary Booleans, INVENTORY's refusal to overclaim, run-local source binding explicitly not presented as cryptographic continuity, and the fixed HLP disclosure allowlist with no override controls.
The strict UTF-8 section (W002-ENC-004 and 005) is the most complete part of the contract. Apart from F-07, it could be handed to an independent fixture author today.
Keeping all analytical intent in Work Order text, with read-only aliases in the GUI, stays consistent across the UI requirements. The only exceptions are F-01 and F-27.
Separating class from serialization (PB-STOR-007) and names from proof (PB-STOR-012) gives a clean basis for resolving F-14.
I In Chromium, a File taken from a handle becomes unreadable once the underlying file changes. That gives the browser host a natural way to enforce W002-ENC-003.4 run-local continuity, which is worth confirming on the target browser.

Appendix A — Prototype divergence log (informational)

The prototype is non-binding, and the PRD wins. These are not findings against the contract. They are recorded because W002-UI-012 says a conflicting prototype must be revised, and several of them happen to illustrate open contract questions.

Source resolution	It resolves `SOURCE` through a displayed alias. The contract routes on the exact filename only.
Diagnostics	It uses `DS-PTP-*` IDs, a `HELP` severity outside the INFO/WARNING/ERROR set, phase labels with spaces, and `{diagnostic_id}` and `{phase}` placeholders, which are not declared facts.
Publication	It writes WKO, WKO MAP and HLP directly under their final names, with no SCR staging and no successor-MAP validation.
Store MAP display	It picks the newest valid MAP across all Stores, rather than per lineage, and shows nothing on a tie. It applies partial checks and requires non-empty aliases, which the contract permits to be empty after `CLEAR`.
Grammar	It matches keywords case-insensitively, accepts `COLUMN +7`, and case-folds alias uniqueness (`toLocaleLowerCase`). All three are open questions in F-08 and F-15.
Operations	It supports MATERIALIZE only. There is no RCP, INVENTORY, RECOVER RID, UPDATE ALIASES or conversion.
HLP	Its HLP has no `ds-hlp-provenance` payload and no Disclosure section.
Themes	It has no Modern Dark / Modern Light selector (W002-UI-025).
Retired panels	The Branding TOML and Data Dictionary panels remain, clearly labelled out of scope.
Consistent with the contract	The Suitcase-first CER gate, the flat directory with display-only aliases, one editor with a derived-draft transition, the read-only execution pane, and the persistent Help pane with a voice switch and report action.

Appendix B — Requirements cited in this review

135 distinct requirement IDs are cited. Every citation was mechanically checked against the 384 IDs present in the reviewed artifact.

PB-OPS-001 PB-STOR-001 PB-STOR-002 PB-STOR-005 PB-STOR-006 PB-STOR-008 PB-STOR-009 PB-STOR-010 PB-STOR-011 PB-STOR-012 PB-STOR-013 W002-ARCH-008 W002-ARCH-014 W002-CONV-001 W002-CONV-001.4 W002-CONV-002 W002-CONV-002.1 W002-CONV-002.3 W002-CONV-002.4 W002-CONV-003.5 W002-CONV-004 W002-CONV-004.1 W002-CONV-004.2 W002-CONV-ACC-001 W002-CONV-ACC-002 W002-ENC-001.5 W002-ENC-004.1 W002-ENC-004.10 W002-ENC-006 W002-ENC-ACC-003 W002-ENC-ACC-006 W002-ENC-ACC-007 W002-ENC-ACC-008 W002-ENC-ACC-009 W002-HELP-001.4 W002-HELP-001.6 W002-HELP-001.7 W002-HELP-001.8 W002-HELP-002.10 W002-HELP-002.11 W002-HELP-002.9 W002-HELP-003.2 W002-HELP-004.11 W002-HELP-005 W002-HELP-006 W002-HELP-009 W002-HELP-010 W002-HELP-011.2 W002-HP-ACC-003 W002-HP-ACC-008 W002-HP-ACC-011 W002-HP-ACC-013 W002-INV-002 W002-INV-005 W002-INV-006 W002-MAT-001.7 W002-MAT-002.10 W002-MAT-002.11 W002-MAT-002.5 W002-MAT-002.6 W002-MAT-002.7 W002-MAT-002.8 W002-MAT-003.1 W002-MAT-003.2 W002-MAT-003.3 W002-MAT-ACC-002.4 W002-MAT-ACC-003 W002-MAT-ACC-004 W002-MAT-ACC-005 W002-MAT-ACC-006 W002-RCP-005 W002-RCP-006 W002-RCP-007 W002-RCP-008 W002-RCP-010 W002-RID-001 W002-RID-004 W002-RID-005 W002-RID-006 W002-RID-008 W002-RID-009 W002-STEPS-001 W002-STEPS-001.1 W002-STEPS-001.2 W002-STEPS-002 W002-STEPS-003 W002-STEPS-010 W002-STOR-001.2 W002-STOR-003.5 W002-STOR-007.3 W002-STOR-009 W002-STOR-010 W002-STOR-010.1 W002-STOR-010.3 W002-STOR-010.4 W002-STOR-012 W002-STOR-014 W002-STOR-015 W002-STOR-016 W002-STOR-018 W002-STOR-018.2 W002-STOR-018.3 W002-STOR-018.4 W002-STOR-019.10 W002-STOR-019.11 W002-STOR-019.2 W002-STOR-019.3 W002-STOR-019.5 W002-STOR-019.6 W002-STOR-020 W002-STOR-022 W002-STOR-022.1 W002-STOR-022.2 W002-UI-006 W002-UI-007 W002-UI-011 W002-UI-016 W002-UI-017 W002-UI-019 W002-UI-020 W002-UI-023 W002-UI-024 W002-UI-ACC-007 W002-UI-ACC-016 W002-UI-ACC-019 W002-WKO-007 W002-WKO-009 W002-WKO-012.1 W002-WKO-012.3 W002-WKO-012.5 W002-WKO-012.6 W002-WKO-013 W002-WKO-ACC-003 W002-WKO-ACC-006 W002-WKO-ACC-008