WASM-002 Development Log

=== CP019 ENGINEERING PREFLIGHT ===
Date: 2026-10-21
Git HEAD: 75620f17649a5d38d5357960bb99e9ac39ae354f
Tracked working tree: CLEAN
Baseline native tests: 94/94 PASS at CP018
Checkpoint candidate: Receipt core field-type enforcement
Scope status: PROPOSED, NOT YET FROZEN
Source files modified: NO
Git commit created: NO

=== RUST FILE HASHES ===
src\lib.rs | SHA256=69A512D5DF854EAD350C220647F9B58657F2BB7A626E87BCED342916D4761955
tests\CP016_receipt_field_serialization.rs | SHA256=BA13064905D2F8444F2E11A188FE7C4EBA30AE091947F19783E34FCE006A355C
tests\CP017_receipt_field_sequence.rs | SHA256=3EF60E8BA18CAFDB959AFBDF281A50BA23A1A615A973B17F23668792EFABD801
tests\CP018_receipt_core_envelope.rs | SHA256=FAF47D9C1CE26D0AEC3EB6A857B8FC1EE9DD79505795765C159FE1A00A3DE8D3

=== RECEIPT IMPLEMENTATION: src/lib.rs, LINES 370-560 ===
 370:     intended_final_class: &str,
 371: ) -> Option<String> {
 372:     if intended_final_class != "RCP" || !is_canonical_scr_filename_candidate(scr_filename) {
 373:         return None;
 374:     }
 375: 
 376:     let tokens = extract_artifact_filename_tokens(scr_filename)?;
 377: 
 378:     if tokens.serialization_extension != "txt" {
 379:         return None;
 380:     }
 381: 
 382:     Some(scr_filename.replacen("__DS__SCR__", "__DS__RCP__", 1))
 383: }
 384: 
 385: /// Recognizes a canonical RCP Receipt filename candidate.
 386: ///
 387: /// Lexical recognition only. This does not verify Receipt contents,
 388: /// filesystem state, staging promotion, publication, or authority.
 389: pub fn is_canonical_rcp_filename_candidate(filename: &str) -> bool {
 390:     if filename
 391:         .chars()
 392:         .any(|ch| ch.is_whitespace() || ch == '/' || ch == '\\')
 393:     {
 394:         return false;
 395:     }
 396: 
 397:     matches!(
 398:         extract_artifact_filename_tokens(filename),
 399:         Some(tokens)
 400:             if tokens.semantic_class == "RCP"
 401:                 && tokens.serialization_extension == "txt"
 402:     )
 403: }
 404: 
 405: /// Returns true when canonical SCR and RCP TXT filename candidates
 406: /// carry the same UTC and UUID identity, in that exact class order.
 407: ///
 408: /// This is lexical pairing only. It does not inspect files, validate
 409: /// Receipt contents, promote staged artifacts, publish, or grant authority.
 410: pub fn is_matching_scr_rcp_filename_candidate_pair(scr_filename: &str, rcp_filename: &str) -> bool {
 411:     if !is_canonical_scr_filename_candidate(scr_filename)
 412:         || !is_canonical_rcp_filename_candidate(rcp_filename)
 413:     {
 414:         return false;
 415:     }
 416: 
 417:     matches!(
 418:         build_final_filename_candidate_for_scr(scr_filename, "RCP"),
 419:         Some(expected) if expected == rcp_filename
 420:     )
 421: }
 422: 
 423: /// One typed canonical Receipt field value, before whole-Receipt assembly.
 424: ///
 425: /// This is an isolated formatting choice, not a claim that a field belongs to
 426: /// a frozen operation grammar or has been assigned a permitted vocabulary.
 427: #[derive(Debug, Clone, Copy, PartialEq, Eq)]
 428: pub enum ReceiptFieldValue<'a> {
 429:     MachineToken(&'a str),
 430:     NonNegativeInteger(u64),
 431:     QuotedText(&'a str),
 432: }
 433: 
 434: /// Serializes exactly one canonical Receipt `KEY: VALUE` line with one LF.
 435: ///
 436: /// Pure, deterministic formatting only: does not validate whole-Receipt
 437: /// ordering or semantics, access the filesystem, or authorize publication.
 438: /// An invalid identifier or embedded CR/LF in quoted text is refused.
 439: pub fn serialize_canonical_receipt_field_line(
 440:     key: &str,
 441:     value: ReceiptFieldValue<'_>,
 442: ) -> Option<String> {
 443:     if !is_receipt_field_identifier(key) {
 444:         return None;
 445:     }
 446: 
 447:     let encoded_value = match value {
 448:         ReceiptFieldValue::MachineToken(token) => {
 449:             if !is_receipt_field_identifier(token) {
 450:                 return None;
 451:             }
 452:             token.to_owned()
 453:         }
 454:         ReceiptFieldValue::NonNegativeInteger(value) => value.to_string(),
 455:         ReceiptFieldValue::QuotedText(text) => {
 456:             if text.contains('\r') || text.contains('\n') {
 457:                 return None;
 458:             }
 459:             format!("\"{}\"", text.replace('"', "\"\""))
 460:         }
 461:     };
 462: 
 463:     Some(format!("{key}: {encoded_value}\n"))
 464: }
 465: 
 466: /// Serializes caller-ordered canonical Receipt field lines as one in-memory string.
 467: ///
 468: /// Each line is delegated to the CP016 field serializer. If any field refuses,
 469: /// the entire sequence refuses; no partially assembled output is returned.
 470: /// This is not whole-Receipt schema validation, durable output, or publication.
 471: pub fn serialize_canonical_receipt_field_sequence(
 472:     fields: &[(&str, ReceiptFieldValue<'_>)],
 473: ) -> Option<String> {
 474:     let mut output = String::new();
 475:     for &(key, value) in fields {
 476:         output.push_str(&serialize_canonical_receipt_field_line(key, value)?);
 477:     }
 478:     Some(output)
 479: }
 480: 
 481: /// Serializes exactly the ten frozen WASM-002 Receipt core fields.
 482: ///
 483: /// Checks the mandatory key count and order before delegating formatting
 484: /// to CP017. Refuses malformed field formatting as a whole.
 485: ///
 486: /// This is a core-envelope fragment, not a complete Receipt. It does not
 487: /// validate operation-specific facts, execution truth, filename lineage,
 488: /// field-specific vocabularies, filesystem effects, or publication.
 489: pub fn serialize_canonical_receipt_core_envelope(
 490:     fields: &[(&str, ReceiptFieldValue<'_>)],
 491: ) -> Option<String> {
 492:     const CORE_KEYS: [&str; 10] = [
 493:         "RECEIPT_VERSION",
 494:         "RECEIPT_FILENAME",
 495:         "RECEIPT_UTC",
 496:         "WORK_ORDER_FILENAME",
 497:         "OPERATION",
 498:         "RUN_STARTED_UTC",
 499:         "RUN_FINISHED_UTC",
 500:         "RESULT",
 501:         "DIAGNOSTIC_ID",
 502:         "IDENTITY_COLLISION_RETRIES",
 503:     ];
 504: 
 505:     if fields.len() != CORE_KEYS.len() {
 506:         return None;
 507:     }
 508: 
 509:     for (index, &(key, _)) in fields.iter().enumerate() {
 510:         if key != CORE_KEYS[index] {
 511:             return None;
 512:         }
 513:     }
 514: 
 515:     serialize_canonical_receipt_field_sequence(fields)
 516: }
 517: 
 518: /// Lexical form shared by field keys and machine-token values in this slice.
 519: /// Starts with uppercase ASCII A-Z; remaining bytes are A-Z, 0-9, or '_'.
 520: /// This is not an operation-specific closed-vocabulary membership check.
 521: fn is_receipt_field_identifier(value: &str) -> bool {
 522:     let mut bytes = value.bytes();
 523:     matches!(bytes.next(), Some(b'A'..=b'Z'))
 524:         && bytes.all(|byte| byte.is_ascii_uppercase() || byte.is_ascii_digit() || byte == b'_')
 525: }

=== TEST FILE: tests\CP016_receipt_field_serialization.rs ===
// CP016 RED tests - Day 068 (2026-10-15)
// Proposed T-approval gate: deterministic serialization of ONE canonical Receipt field line.
// Frozen anchor: W002-RCP-005 (bounded PARTIAL portion only).
// No full Receipt schema, key ordering, operation vocabulary, filesystem I/O,
// WKO authority, staged publication, or claim that a durable Receipt exists.
// Preserve this original test file's SHA-256 after T approves the contract.

use data_sculptor_core::{ReceiptFieldValue, serialize_canonical_receipt_field_line};

#[test]
fn machine_tokens_have_exact_colon_space_and_single_lf() {
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "RESULT",
            ReceiptFieldValue::MachineToken("SUCCESS")
        ),
        Some("RESULT: SUCCESS\n".to_owned())
    );
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "ABSENCE",
            ReceiptFieldValue::MachineToken("NOT_AVAILABLE")
        ),
        Some("ABSENCE: NOT_AVAILABLE\n".to_owned())
    );
}

#[test]
fn non_negative_integers_use_ungrouped_ascii_decimal() {
    for (value, expected) in [
        (0_u64, "COUNT: 0\n"),
        (16, "COUNT: 16\n"),
        (1234567, "COUNT: 1234567\n"),
        (u64::MAX, "COUNT: 18446744073709551615\n"),
    ] {
        assert_eq!(
            serialize_canonical_receipt_field_line(
                "COUNT",
                ReceiptFieldValue::NonNegativeInteger(value)
            ),
            Some(expected.to_owned())
        );
    }
}

#[test]
fn filenames_and_utf8_free_text_are_double_quoted() {
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "WORK_ORDER_FILENAME",
            ReceiptFieldValue::QuotedText("__DS__WKO__20261015T123456789Z__550e8400-e29b-41d4-a716-446655440000.txt")
        ),
        Some("WORK_ORDER_FILENAME: \"__DS__WKO__20261015T123456789Z__550e8400-e29b-41d4-a716-446655440000.txt\"\n".to_owned())
    );
    assert_eq!(
        serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText("café 雪")),
        Some("DETAIL: \"café 雪\"\n".to_owned())
    );
}

#[test]
fn doubles_internal_quotes_without_backslash_escaping() {
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "DETAIL",
            ReceiptFieldValue::QuotedText("He said \"go\"")
        ),
        Some("DETAIL: \"He said \"\"go\"\"\"\n".to_owned())
    );
}

#[test]
fn refuses_cr_or_lf_inside_any_single_field_value() {
    for text in ["before\nafter", "before\rafter", "before\r\nafter"] {
        assert_eq!(
            serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText(text)),
            None
        );
    }
    for token in ["SUCCESS\n", "SUCCESS\r", "SUCCESS\r\n"] {
        assert_eq!(
            serialize_canonical_receipt_field_line(
                "RESULT",
                ReceiptFieldValue::MachineToken(token)
            ),
            None
        );
    }
}

#[test]
fn refuses_non_uppercase_ascii_field_keys() {
    for key in [
        "",
        "result",
        " Result",
        "RESULT ",
        "RESULT: X",
        "KEY=VALUE",
        "RÉSULT",
        "1RESULT",
        "RESULT\tOTHER",
        "RESULT\nOTHER",
    ] {
        assert_eq!(
            serialize_canonical_receipt_field_line(key, ReceiptFieldValue::MachineToken("SUCCESS")),
            None,
            "invalid key must refuse: {key:?}"
        );
    }
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "PUBLISHED_COL_001_FILENAME",
            ReceiptFieldValue::QuotedText("example.csv")
        ),
        Some("PUBLISHED_COL_001_FILENAME: \"example.csv\"\n".to_owned())
    );
}

#[test]
fn machine_token_spelling_must_be_lexically_canonical() {
    for token in [
        "",
        "success",
        "Success",
        " SUCCESS",
        "SUCCESS ",
        "NOT-AVAILABLE",
        "Café",
        "1SUCCESS",
        "SUCCESS\t",
    ] {
        assert_eq!(
            serialize_canonical_receipt_field_line(
                "RESULT",
                ReceiptFieldValue::MachineToken(token)
            ),
            None,
            "invalid token must refuse: {token:?}"
        );
    }
}

#[test]
fn text_is_preserved_without_trimming_and_document_bytes_are_deterministic() {
    let lines = [
        serialize_canonical_receipt_field_line(
            "RESULT",
            ReceiptFieldValue::MachineToken("SUCCESS"),
        )
        .unwrap(),
        serialize_canonical_receipt_field_line("COUNT", ReceiptFieldValue::NonNegativeInteger(0))
            .unwrap(),
        serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText(" a  b "))
            .unwrap(),
        serialize_canonical_receipt_field_line("EMPTY", ReceiptFieldValue::QuotedText("")).unwrap(),
    ];
    let output = lines.concat();
    assert_eq!(
        output.as_bytes(),
        b"RESULT: SUCCESS\nCOUNT: 0\nDETAIL: \" a  b \"\nEMPTY: \"\"\n"
    );
    assert!(output.ends_with('\n'));
    assert!(!output.ends_with("\n\n"));
    assert!(!output.contains("\r"));
    assert!(!output.contains("\n\n"));
    assert!(!output.as_bytes().starts_with(&[0xef, 0xbb, 0xbf]));
}

=== TEST FILE: tests\CP017_receipt_field_sequence.rs ===
// CP017 RED test contract - Day 073 (2026-10-20)
// Frozen anchor: W002-RCP-005 (bounded PARTIAL continuation of CP016).
// Assemble a caller-ordered sequence of already-typed canonical field lines.
// All-or-none in-memory formatting: one invalid field refuses the entire sequence.
// No whole-Receipt schema, key ordering, vocabulary/uniqueness policy, filesystem
// access, Work Order execution, authority, or publication is claimed.

use data_sculptor_core::{ReceiptFieldValue, serialize_canonical_receipt_field_sequence};

#[test]
fn preserves_caller_order_without_claiming_schema_order() {
    let fields = [
        ("DETAIL", ReceiptFieldValue::QuotedText(" a  b ")),
        ("RESULT", ReceiptFieldValue::MachineToken("SUCCESS")),
        ("COUNT", ReceiptFieldValue::NonNegativeInteger(3)),
    ];
    assert_eq!(
        serialize_canonical_receipt_field_sequence(&fields),
        Some("DETAIL: \" a  b \"\nRESULT: SUCCESS\nCOUNT: 3\n".to_owned()),
    );
}

#[test]
fn utf8_quotes_and_empty_quoted_text_produce_exact_bytes() {
    let fields = [
        ("DETAIL", ReceiptFieldValue::QuotedText("café 雪 — \"go\"")),
        ("EMPTY", ReceiptFieldValue::QuotedText("")),
    ];
    let output = serialize_canonical_receipt_field_sequence(&fields).unwrap();
    let expected = "DETAIL: \"café 雪 — \"\"go\"\"\"\nEMPTY: \"\"\n";
    assert_eq!(output.as_bytes(), expected.as_bytes());
    assert!(!output.starts_with('\u{feff}'));
    assert!(!output.contains('\r'));
    assert!(!output.contains("\n\n"));
}

#[test]
fn invalid_late_key_refuses_the_entire_sequence() {
    let fields = [
        ("RESULT", ReceiptFieldValue::MachineToken("SUCCESS")),
        ("bad_key", ReceiptFieldValue::NonNegativeInteger(42)),
    ];
    assert_eq!(serialize_canonical_receipt_field_sequence(&fields), None);
}

#[test]
fn invalid_late_machine_token_refuses_the_entire_sequence() {
    let fields = [
        ("COUNT", ReceiptFieldValue::NonNegativeInteger(1)),
        ("RESULT", ReceiptFieldValue::MachineToken("not_canonical")),
    ];
    assert_eq!(serialize_canonical_receipt_field_sequence(&fields), None);
}

#[test]
fn embedded_newline_in_late_text_refuses_the_entire_sequence() {
    for invalid in ["before\nafter", "before\rafter", "before\r\nafter"] {
        let fields = [
            ("RESULT", ReceiptFieldValue::MachineToken("SUCCESS")),
            ("DETAIL", ReceiptFieldValue::QuotedText(invalid)),
        ];
        assert_eq!(serialize_canonical_receipt_field_sequence(&fields), None);
    }
}

#[test]
fn repeated_invocations_are_byte_identical() {
    let fields = [
        ("RESULT", ReceiptFieldValue::MachineToken("SUCCESS")),
        ("COUNT", ReceiptFieldValue::NonNegativeInteger(u64::MAX)),
    ];
    let first = serialize_canonical_receipt_field_sequence(&fields).unwrap();
    let second = serialize_canonical_receipt_field_sequence(&fields).unwrap();
    assert_eq!(first.as_bytes(), second.as_bytes());
    assert_eq!(first, "RESULT: SUCCESS\nCOUNT: 18446744073709551615\n");
}

#[test]
fn empty_sequence_is_empty_formatting_not_a_valid_receipt_claim() {
    let fields: &[(&str, ReceiptFieldValue<'_>)] = &[];
    assert_eq!(
        serialize_canonical_receipt_field_sequence(fields),
        Some(String::new()),
    );
}

=== TEST FILE: tests\CP018_receipt_core_envelope.rs ===
// CP018 RED test contract - Day 074 (2026-10-21).
// Frozen anchors: W002-RCP-005 and W002-RCP-006.
// Approved scope: canonical ten-field core Receipt envelope.
//
// CORE-ONLY API: exactly ten fields in frozen order.
// Complete Receipts may contain operation-specific fields afterward.
//
// This checkpoint does NOT establish whole-Receipt validity,
// semantic validation, truthful timestamps, WKO authority,
// publication, or filesystem behavior.

use data_sculptor_core::{ReceiptFieldValue, serialize_canonical_receipt_core_envelope};

fn valid_core() -> [(&'static str, ReceiptFieldValue<'static>); 10] {
    [
        ("RECEIPT_VERSION", ReceiptFieldValue::NonNegativeInteger(1)),
        (
            "RECEIPT_FILENAME",
            ReceiptFieldValue::QuotedText(
                "__DS__RCP__20261021T141300000Z__123e4567-e89b-42d3-a456-426614174000.txt",
            ),
        ),
        (
            "RECEIPT_UTC",
            ReceiptFieldValue::QuotedText("20261021T141300000Z"),
        ),
        (
            "WORK_ORDER_FILENAME",
            ReceiptFieldValue::QuotedText(
                "__DS__WKO__20261021T141000000Z__550e8400-e29b-41d4-a716-446655440000.txt",
            ),
        ),
        ("OPERATION", ReceiptFieldValue::MachineToken("MATERIALIZE")),
        (
            "RUN_STARTED_UTC",
            ReceiptFieldValue::QuotedText("20261021T141100000Z"),
        ),
        (
            "RUN_FINISHED_UTC",
            ReceiptFieldValue::QuotedText("20261021T141200000Z"),
        ),
        ("RESULT", ReceiptFieldValue::MachineToken("SUCCESS")),
        ("DIAGNOSTIC_ID", ReceiptFieldValue::MachineToken("NONE")),
        (
            "IDENTITY_COLLISION_RETRIES",
            ReceiptFieldValue::NonNegativeInteger(0),
        ),
    ]
}

#[test]
fn exact_ten_core_fields_emit_exact_bytes() {
    let expected = concat!(
        "RECEIPT_VERSION: 1\n",
        "RECEIPT_FILENAME: \"__DS__RCP__20261021T141300000Z__123e4567-e89b-42d3-a456-426614174000.txt\"\n",
        "RECEIPT_UTC: \"20261021T141300000Z\"\n",
        "WORK_ORDER_FILENAME: \"__DS__WKO__20261021T141000000Z__550e8400-e29b-41d4-a716-446655440000.txt\"\n",
        "OPERATION: MATERIALIZE\n",
        "RUN_STARTED_UTC: \"20261021T141100000Z\"\n",
        "RUN_FINISHED_UTC: \"20261021T141200000Z\"\n",
        "RESULT: SUCCESS\n",
        "DIAGNOSTIC_ID: NONE\n",
        "IDENTITY_COLLISION_RETRIES: 0\n",
    );

    let actual = serialize_canonical_receipt_core_envelope(&valid_core())
        .expect("valid core fields must format");

    assert_eq!(actual.as_bytes(), expected.as_bytes());
    assert!(!actual.as_bytes().starts_with(&[0xEF, 0xBB, 0xBF]));
    assert!(!actual.contains('\r'));
    assert!(!actual.contains("\n\n"));
    assert_eq!(actual.lines().count(), 10);
    assert!(actual.ends_with('\n'));
}

#[test]
fn missing_mandatory_field_refuses() {
    for index in 0..10 {
        let mut fields = valid_core().to_vec();
        fields.remove(index);
        assert_eq!(
            serialize_canonical_receipt_core_envelope(&fields),
            None,
            "missing field at index {index}"
        );
    }
}

#[test]
fn duplicate_field_refuses() {
    let mut fields = valid_core().to_vec();
    fields.insert(7, fields[6]);
    assert_eq!(serialize_canonical_receipt_core_envelope(&fields), None);
}

#[test]
fn swapped_fields_refuse() {
    for (left, right) in [(0, 1), (4, 5), (8, 9)] {
        let mut fields = valid_core();
        fields.swap(left, right);
        assert_eq!(serialize_canonical_receipt_core_envelope(&fields), None);
    }
}

#[test]
fn unexpected_field_refuses_for_core_only_api() {
    let extra = ("EXTRA_FACT", ReceiptFieldValue::NonNegativeInteger(5));

    let mut appended = valid_core().to_vec();
    appended.push(extra);
    assert_eq!(serialize_canonical_receipt_core_envelope(&appended), None);

    let mut inserted = valid_core().to_vec();
    inserted.insert(3, extra);
    assert_eq!(serialize_canonical_receipt_core_envelope(&inserted), None);
}

#[test]
fn misspelled_or_wrong_case_key_refuses() {
    for wrong in ["RECEIPT_FILENAMEX", "Receipt_FILENAME"] {
        let mut fields = valid_core();
        fields[1].0 = wrong;
        assert_eq!(serialize_canonical_receipt_core_envelope(&fields), None);
    }
}

#[test]
fn invalid_late_value_refuses_entire_fragment() {
    let mut fields = valid_core();
    fields[7].1 = ReceiptFieldValue::MachineToken("not_canonical");

    assert_eq!(serialize_canonical_receipt_core_envelope(&fields), None);
}

#[test]
fn repeated_input_is_byte_identical() {
    let first = serialize_canonical_receipt_core_envelope(&valid_core()).unwrap();
    let second = serialize_canonical_receipt_core_envelope(&valid_core()).unwrap();

    assert_eq!(first.as_bytes(), second.as_bytes());
}

#[test]
fn empty_input_refuses() {
    let empty: &[(&str, ReceiptFieldValue<'_>)] = &[];

    assert_eq!(serialize_canonical_receipt_core_envelope(empty), None);
}

=== CP019 EVIDENCE ZIP INVENTORY ===
Date: 2026-10-21
Git HEAD: 75620f17649a5d38d5357960bb99e9ac39ae354f
Checkpoint: CP019
Original evidence sources packaged: 18
Individual evidence ZIPs: 18
Every ZIP has exactly one source file
Every archived entry SHA256 matched its original
Original source evidence retained: YES
Git commit created: NO

=== VERIFIED EVIDENCE ===
PASS | CP019_Engineering_Preflight.txt | SOURCE_SHA256=4C7A9D49D3E2310382F109FF716D463B1721CB35F0C83E457438C2581C71A5B8 | ZIP_SHA256=920D48E0F99479E4FC83A50B548919569BEAC68F64204DA88DFF316FF4534A99 | SOURCE_BYTES=20761 | ZIP_BYTES=6014
PASS | CP019_RED_Installation_Record.txt | SOURCE_SHA256=FBDF8E3421820DC11CBB8735CE9529E1C74FE34061B0903725D3071C917F92C7 | ZIP_SHA256=55EB05698609674E1DBFAB2B5AD24683080F5E9F46876FB9388DA5C18DC6B0E7 | SOURCE_BYTES=672 | ZIP_BYTES=624
PASS | CP019_RED_Run_Record.txt | SOURCE_SHA256=7D6D8F22B81F830FC0331B617552C69606FE1EA47B7D7B74F9FC1B3A6635A0EF | ZIP_SHA256=ED24114BEE1CF3A08CEBD323451DA0417105B1B3A4A1423B76AD23FAB17B643C | SOURCE_BYTES=637 | ZIP_BYTES=522
PASS | CP019_RED_StdOut.txt | SOURCE_SHA256=EE0385191D62A978177AEDBB8547112204FDB2909F6CEDB711E3CBB7054D0515 | ZIP_SHA256=DACD8649FFA84A8AE0DF2EA316047582A112F5E049A2D7468841181FF6351D02 | SOURCE_BYTES=3635 | ZIP_BYTES=960
PASS | CP019_RED_StdErr.txt | SOURCE_SHA256=07BF10B0927BCBE831145B32263E49D5B8385106A08F72A89E2ACD7C35137826 | ZIP_SHA256=E94EDAD132447940EFF9E33D8F415CA46E2F78182F4B537EB8CB7E4244C5315B | SOURCE_BYTES=359 | ZIP_BYTES=372
PASS | CP019_GREEN_Installation_Record.txt | SOURCE_SHA256=324DC51CE31BDF45E1FDFE1E3E6FD08FA0659D8DBB1D5D80FBA3F14624E16195 | ZIP_SHA256=414D139FD22295AA039B0FC2EC36750DCE2F3D7D89512A4749DE9F47D3EFA617 | SOURCE_BYTES=715 | ZIP_BYTES=606
PASS | CP019_PreGREEN_lib.rs | SOURCE_SHA256=69A512D5DF854EAD350C220647F9B58657F2BB7A626E87BCED342916D4761955 | ZIP_SHA256=3579A082BADF0300541AB13C06FB8BCAE56A1412355BC1404C0C431A71E03BB0 | SOURCE_BYTES=17265 | ZIP_BYTES=5109
PASS | CP019_GREEN_Run_Record.txt | SOURCE_SHA256=2C5380AFDF83AF3D9B77CAA7956AD094E6845D11E029A9F3E5A0F15BF262B7F0 | ZIP_SHA256=729760D390F204BA5983077F46046830883BCE119E12CB6B94ED6BA78B91D1D6 | SOURCE_BYTES=662 | ZIP_BYTES=570
PASS | CP019_GREEN_StdOut.txt | SOURCE_SHA256=565352F95008EE14032184DE7D7F599FA5DC2F87B8EBA22541A5F11D07A8DC8C | ZIP_SHA256=C9D4D01975DCE19C80403056C9DD4084393F2D114E310F24B9EA3C7232217A6F | SOURCE_BYTES=478 | ZIP_BYTES=373
PASS | CP019_GREEN_StdErr.txt | SOURCE_SHA256=5EBDE89B175BB697D1B8236A62F67D1E88FB3AABF0C19751CF8F7C9AC4EBB53D | ZIP_SHA256=B1F76836701FFF3A5C68DDF5EC98B076F178A90CC1A7D35746A807E412AFCC1A | SOURCE_BYTES=285 | ZIP_BYTES=349
PASS | CP019_Rustfmt_Check_StdOut.txt | SOURCE_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=522BC6E769DF3DD00DEE622AEFFEF5BB67167F63E9A6054DAB8E01AEC8057B01 | SOURCE_BYTES=0 | ZIP_BYTES=158
PASS | CP019_Rustfmt_Check_StdErr.txt | SOURCE_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=8CCA34CCD8749CCF882F16CAD0C0578FE89D394229FD843B56296D742B4B5DB6 | SOURCE_BYTES=0 | ZIP_BYTES=158
PASS | CP019_Regression_StdOut.txt | SOURCE_SHA256=A8A0AE611D6C9BEED52D4E66616D00D07713E926BC4293EA66154A6DB249C5D8 | ZIP_SHA256=D6EEAB32D70626DB23A7BB8A1FA23EE19D2650DDED1DD47BB90C5B67DD9FCCE7 | SOURCE_BYTES=7871 | ZIP_BYTES=1964
PASS | CP019_Regression_StdErr.txt | SOURCE_SHA256=3C3D9245BC34806B0B145AC64307213394805311D62D06ED1CA1489EE37A8BD0 | ZIP_SHA256=4605A5486DC5BEE49A286C608FD5B093407DF07031E659E54529002B9BB7E584 | SOURCE_BYTES=2454 | ZIP_BYTES=855
PASS | CP019_WASM_Build_StdOut.txt | SOURCE_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=D5F517D2777BE8AB1A66B4581AADD7F75737949A53904F2E8F2869712EFF8367 | SOURCE_BYTES=0 | ZIP_BYTES=152
PASS | CP019_WASM_Build_StdErr.txt | SOURCE_SHA256=22253096F4A2856C201EE463B0741DB221E914B13D5997B89BEAE50C785EFABE | ZIP_SHA256=3A35D919CB3C773B00EFFBC5949FCAD2D222748FAA7058217DABC4D409DACF9E | SOURCE_BYTES=159 | ZIP_BYTES=293
PASS | CP019_Verification_Run_Record.txt | SOURCE_SHA256=23FA5C6BD05491A5FC98E1536CF45482FC78C0BA1AACCF31E1886CD9366A1DAF | ZIP_SHA256=570AB2452F79FCD353678261000C9B537BEA16FFBCFF0224011793C9B10E6E55 | SOURCE_BYTES=890 | ZIP_BYTES=698
PASS | CP019_Source_Review.txt | SOURCE_SHA256=2D9329619A67522BAEB6B595509B669410D5BEAEE43F04774878A0616FDB83FB | ZIP_SHA256=AF0BD920DB90978D511466E2C9E9916C27F239153E88511782F9EAC5201326E6 | SOURCE_BYTES=1660 | ZIP_BYTES=1067

INVENTORY_RESULT=PASS

=== CP019 GREEN INSTALLATION ===
Date: 2026-10-21
Git HEAD: 75620f17649a5d38d5357960bb99e9ac39ae354f
Frozen anchors: W002-RCP-005 / W002-RCP-006
Scope: Receipt core field-type enforcement
Implementation: src/lib.rs
Pre-GREEN backup: Evidence/CP-019/CP019_PreGREEN_lib.rs
Pre-GREEN SHA256: 69A512D5DF854EAD350C220647F9B58657F2BB7A626E87BCED342916D4761955
Backup SHA256: 69A512D5DF854EAD350C220647F9B58657F2BB7A626E87BCED342916D4761955
Post-install SHA256: 035AFC8D01C93DC56145C84E089FCD223B4D1FD671C202CC689EC0D39A134FFA
CP019 RED test SHA256: 441ED1E5B1763F41FFDA4913FC586EE97B5879D182398295B1D66449DDCDA9AE
Implementation anchor matches: 1
Source installation: PASS
GREEN tests executed: NO
Git commit created: NO

=== CP019 GREEN TEST ===
Date: 2026-10-21
Git HEAD: 75620f17649a5d38d5357960bb99e9ac39ae354f
Command: cargo test --test CP019_receipt_core_field_types
Exit code: 0
Six tests passed: True
All six named tests passed: True
Source and test hashes unchanged: True
Source SHA256: 035AFC8D01C93DC56145C84E089FCD223B4D1FD671C202CC689EC0D39A134FFA
Test SHA256: 441ED1E5B1763F41FFDA4913FC586EE97B5879D182398295B1D66449DDCDA9AE
Result: GREEN PASS
StdOut: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-019\CP019_GREEN_StdOut.txt
StdErr: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-019\CP019_GREEN_StdErr.txt
Git commit created: NO

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.74s
     Running tests\CP019_receipt_core_field_types.rs (target\debug\deps\CP019_receipt_core_field_types-77a22be90979861c.exe)

running 6 tests
test correctly_typed_core_retains_exact_output_contract ... ok
test integer_core_keys_reject_quoted_text_and_machine_token ... ok
test late_type_error_refuses_the_entire_core_fragment ... ok
test machine_core_keys_reject_integer_and_quoted_text ... ok
test quoted_core_keys_reject_integer_and_machine_token ... ok
test preexisting_order_refusal_is_preserved ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

=== CP019 GIT BANKING RECORD ===
Date: 2026-10-21
Checkpoint: CP019
Human acceptance: T APPROVED
Frozen requirements: W002-RCP-005 / W002-RCP-006 (PARTIAL)
Commit message: CP019: Receipt core field-type enforcement and evidence
Commit exit code: 0
Previous HEAD: 75620f17649a5d38d5357960bb99e9ac39ae354f
New HEAD: 8f7460ced343de4b8662e45b2b0b5b7b69127021
Commit parent: 75620f17649a5d38d5357960bb99e9ac39ae354f
Expected committed files: 22
Actual committed files: 22
Remaining staged files: 0
Remaining tracked changes: 0
Native regression: 100/100 PASS
Rustfmt: PASS
WASM library build: PASS
Evidence ZIPs: 20
Independent implementation QA: NOT COMPLETED
Remote push performed: NO
Banking verification: PASS

=== COMMITTED PATHS ===
Evidence/CP-019/ZIP/CP019_Engineering_Preflight.txt.zip
Evidence/CP-019/ZIP/CP019_Evidence_ZIP_Inventory.txt.zip
Evidence/CP-019/ZIP/CP019_GREEN_Installation_Record.txt.zip
Evidence/CP-019/ZIP/CP019_GREEN_Run_Record.txt.zip
Evidence/CP-019/ZIP/CP019_GREEN_StdErr.txt.zip
Evidence/CP-019/ZIP/CP019_GREEN_StdOut.txt.zip
Evidence/CP-019/ZIP/CP019_Git_PreStaging_Review.txt.zip
Evidence/CP-019/ZIP/CP019_PreGREEN_lib.rs.zip
Evidence/CP-019/ZIP/CP019_RED_Installation_Record.txt.zip
Evidence/CP-019/ZIP/CP019_RED_Run_Record.txt.zip
Evidence/CP-019/ZIP/CP019_RED_StdErr.txt.zip
Evidence/CP-019/ZIP/CP019_RED_StdOut.txt.zip
Evidence/CP-019/ZIP/CP019_Regression_StdErr.txt.zip
Evidence/CP-019/ZIP/CP019_Regression_StdOut.txt.zip
Evidence/CP-019/ZIP/CP019_Rustfmt_Check_StdErr.txt.zip
Evidence/CP-019/ZIP/CP019_Rustfmt_Check_StdOut.txt.zip
Evidence/CP-019/ZIP/CP019_Source_Review.txt.zip
Evidence/CP-019/ZIP/CP019_Verification_Run_Record.txt.zip
Evidence/CP-019/ZIP/CP019_WASM_Build_StdErr.txt.zip
Evidence/CP-019/ZIP/CP019_WASM_Build_StdOut.txt.zip
src/lib.rs
tests/CP019_receipt_core_field_types.rs

[master 8f7460c] CP019: Receipt core field-type enforcement and evidence
 22 files changed, 124 insertions(+), 1 deletion(-)
 create mode 100644 Evidence/CP-019/ZIP/CP019_Engineering_Preflight.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_Evidence_ZIP_Inventory.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_GREEN_Installation_Record.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_GREEN_Run_Record.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_GREEN_StdErr.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_GREEN_StdOut.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_Git_PreStaging_Review.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_PreGREEN_lib.rs.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_RED_Installation_Record.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_RED_Run_Record.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_RED_StdErr.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_RED_StdOut.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_Regression_StdErr.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_Regression_StdOut.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_Rustfmt_Check_StdErr.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_Rustfmt_Check_StdOut.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_Source_Review.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_Verification_Run_Record.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_WASM_Build_StdErr.txt.zip
 create mode 100644 Evidence/CP-019/ZIP/CP019_WASM_Build_StdOut.txt.zip
 create mode 100644 tests/CP019_receipt_core_field_types.rs

=== CP019 GIT PRE-STAGING REVIEW ===
Date: 2026-10-21
Git HEAD: 75620f17649a5d38d5357960bb99e9ac39ae354f
Source SHA256: 035AFC8D01C93DC56145C84E089FCD223B4D1FD671C202CC689EC0D39A134FFA
Test SHA256: 441ED1E5B1763F41FFDA4913FC586EE97B5879D182398295B1D66449DDCDA9AE
Native regression: 100/100 PASS
Rustfmt: PASS
WASM library build: PASS
Existing evidence ZIPs verified: 19
Original evidence preserved: YES
Commit created: NO

=== INDEPENDENT ZIP VERIFICATION ===
PASS | CP019_Engineering_Preflight.txt | SOURCE_SHA256=4C7A9D49D3E2310382F109FF716D463B1721CB35F0C83E457438C2581C71A5B8 | ZIP_SHA256=920D48E0F99479E4FC83A50B548919569BEAC68F64204DA88DFF316FF4534A99
PASS | CP019_RED_Installation_Record.txt | SOURCE_SHA256=FBDF8E3421820DC11CBB8735CE9529E1C74FE34061B0903725D3071C917F92C7 | ZIP_SHA256=55EB05698609674E1DBFAB2B5AD24683080F5E9F46876FB9388DA5C18DC6B0E7
PASS | CP019_RED_Run_Record.txt | SOURCE_SHA256=7D6D8F22B81F830FC0331B617552C69606FE1EA47B7D7B74F9FC1B3A6635A0EF | ZIP_SHA256=ED24114BEE1CF3A08CEBD323451DA0417105B1B3A4A1423B76AD23FAB17B643C
PASS | CP019_RED_StdOut.txt | SOURCE_SHA256=EE0385191D62A978177AEDBB8547112204FDB2909F6CEDB711E3CBB7054D0515 | ZIP_SHA256=DACD8649FFA84A8AE0DF2EA316047582A112F5E049A2D7468841181FF6351D02
PASS | CP019_RED_StdErr.txt | SOURCE_SHA256=07BF10B0927BCBE831145B32263E49D5B8385106A08F72A89E2ACD7C35137826 | ZIP_SHA256=E94EDAD132447940EFF9E33D8F415CA46E2F78182F4B537EB8CB7E4244C5315B
PASS | CP019_GREEN_Installation_Record.txt | SOURCE_SHA256=324DC51CE31BDF45E1FDFE1E3E6FD08FA0659D8DBB1D5D80FBA3F14624E16195 | ZIP_SHA256=414D139FD22295AA039B0FC2EC36750DCE2F3D7D89512A4749DE9F47D3EFA617
PASS | CP019_PreGREEN_lib.rs | SOURCE_SHA256=69A512D5DF854EAD350C220647F9B58657F2BB7A626E87BCED342916D4761955 | ZIP_SHA256=3579A082BADF0300541AB13C06FB8BCAE56A1412355BC1404C0C431A71E03BB0
PASS | CP019_GREEN_Run_Record.txt | SOURCE_SHA256=2C5380AFDF83AF3D9B77CAA7956AD094E6845D11E029A9F3E5A0F15BF262B7F0 | ZIP_SHA256=729760D390F204BA5983077F46046830883BCE119E12CB6B94ED6BA78B91D1D6
PASS | CP019_GREEN_StdOut.txt | SOURCE_SHA256=565352F95008EE14032184DE7D7F599FA5DC2F87B8EBA22541A5F11D07A8DC8C | ZIP_SHA256=C9D4D01975DCE19C80403056C9DD4084393F2D114E310F24B9EA3C7232217A6F
PASS | CP019_GREEN_StdErr.txt | SOURCE_SHA256=5EBDE89B175BB697D1B8236A62F67D1E88FB3AABF0C19751CF8F7C9AC4EBB53D | ZIP_SHA256=B1F76836701FFF3A5C68DDF5EC98B076F178A90CC1A7D35746A807E412AFCC1A
PASS | CP019_Rustfmt_Check_StdOut.txt | SOURCE_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=522BC6E769DF3DD00DEE622AEFFEF5BB67167F63E9A6054DAB8E01AEC8057B01
PASS | CP019_Rustfmt_Check_StdErr.txt | SOURCE_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=8CCA34CCD8749CCF882F16CAD0C0578FE89D394229FD843B56296D742B4B5DB6
PASS | CP019_Regression_StdOut.txt | SOURCE_SHA256=A8A0AE611D6C9BEED52D4E66616D00D07713E926BC4293EA66154A6DB249C5D8 | ZIP_SHA256=D6EEAB32D70626DB23A7BB8A1FA23EE19D2650DDED1DD47BB90C5B67DD9FCCE7
PASS | CP019_Regression_StdErr.txt | SOURCE_SHA256=3C3D9245BC34806B0B145AC64307213394805311D62D06ED1CA1489EE37A8BD0 | ZIP_SHA256=4605A5486DC5BEE49A286C608FD5B093407DF07031E659E54529002B9BB7E584
PASS | CP019_WASM_Build_StdOut.txt | SOURCE_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=D5F517D2777BE8AB1A66B4581AADD7F75737949A53904F2E8F2869712EFF8367
PASS | CP019_WASM_Build_StdErr.txt | SOURCE_SHA256=22253096F4A2856C201EE463B0741DB221E914B13D5997B89BEAE50C785EFABE | ZIP_SHA256=3A35D919CB3C773B00EFFBC5949FCAD2D222748FAA7058217DABC4D409DACF9E
PASS | CP019_Verification_Run_Record.txt | SOURCE_SHA256=23FA5C6BD05491A5FC98E1536CF45482FC78C0BA1AACCF31E1886CD9366A1DAF | ZIP_SHA256=570AB2452F79FCD353678261000C9B537BEA16FFBCFF0224011793C9B10E6E55
PASS | CP019_Source_Review.txt | SOURCE_SHA256=2D9329619A67522BAEB6B595509B669410D5BEAEE43F04774878A0616FDB83FB | ZIP_SHA256=AF0BD920DB90978D511466E2C9E9916C27F239153E88511782F9EAC5201326E6
PASS | CP019_Evidence_ZIP_Inventory.txt | SOURCE_SHA256=CDBC6DB9160F1A5EE2781F4403682950154084A59847BB5981903E1081D4D1AE | ZIP_SHA256=9E46B8AD1D8324D5D9F513368779C0E18A211DB634321A5703BE228996BD0ABE

PRESTAGING_VERIFICATION=PASS

=== CP019 GIT STAGING REVIEW ===
Date: 2026-10-21
Git HEAD: 75620f17649a5d38d5357960bb99e9ac39ae354f
Recovery: Absolute-path correction
Original manifest sources: 18
Authorized later evidence sources: 2
Verified ZIPs: 20
Expected staged paths: 22
Actual staged paths: 22
All staged blobs match working files: YES
Staged whitespace: PASS
Unstaged tracked changes: 0
Native regression: 100/100 PASS
Rustfmt: PASS
WASM build: PASS
Human acceptance: PENDING
Git commit created: NO

=== VERIFIED ZIP EVIDENCE ===
PASS | CP019_Engineering_Preflight.txt | SOURCE_SHA256=4C7A9D49D3E2310382F109FF716D463B1721CB35F0C83E457438C2581C71A5B8 | ZIP_SHA256=920D48E0F99479E4FC83A50B548919569BEAC68F64204DA88DFF316FF4534A99
PASS | CP019_GREEN_Installation_Record.txt | SOURCE_SHA256=324DC51CE31BDF45E1FDFE1E3E6FD08FA0659D8DBB1D5D80FBA3F14624E16195 | ZIP_SHA256=414D139FD22295AA039B0FC2EC36750DCE2F3D7D89512A4749DE9F47D3EFA617
PASS | CP019_GREEN_Run_Record.txt | SOURCE_SHA256=2C5380AFDF83AF3D9B77CAA7956AD094E6845D11E029A9F3E5A0F15BF262B7F0 | ZIP_SHA256=729760D390F204BA5983077F46046830883BCE119E12CB6B94ED6BA78B91D1D6
PASS | CP019_GREEN_StdErr.txt | SOURCE_SHA256=5EBDE89B175BB697D1B8236A62F67D1E88FB3AABF0C19751CF8F7C9AC4EBB53D | ZIP_SHA256=B1F76836701FFF3A5C68DDF5EC98B076F178A90CC1A7D35746A807E412AFCC1A
PASS | CP019_GREEN_StdOut.txt | SOURCE_SHA256=565352F95008EE14032184DE7D7F599FA5DC2F87B8EBA22541A5F11D07A8DC8C | ZIP_SHA256=C9D4D01975DCE19C80403056C9DD4084393F2D114E310F24B9EA3C7232217A6F
PASS | CP019_PreGREEN_lib.rs | SOURCE_SHA256=69A512D5DF854EAD350C220647F9B58657F2BB7A626E87BCED342916D4761955 | ZIP_SHA256=3579A082BADF0300541AB13C06FB8BCAE56A1412355BC1404C0C431A71E03BB0
PASS | CP019_RED_Installation_Record.txt | SOURCE_SHA256=FBDF8E3421820DC11CBB8735CE9529E1C74FE34061B0903725D3071C917F92C7 | ZIP_SHA256=55EB05698609674E1DBFAB2B5AD24683080F5E9F46876FB9388DA5C18DC6B0E7
PASS | CP019_RED_Run_Record.txt | SOURCE_SHA256=7D6D8F22B81F830FC0331B617552C69606FE1EA47B7D7B74F9FC1B3A6635A0EF | ZIP_SHA256=ED24114BEE1CF3A08CEBD323451DA0417105B1B3A4A1423B76AD23FAB17B643C
PASS | CP019_RED_StdErr.txt | SOURCE_SHA256=07BF10B0927BCBE831145B32263E49D5B8385106A08F72A89E2ACD7C35137826 | ZIP_SHA256=E94EDAD132447940EFF9E33D8F415CA46E2F78182F4B537EB8CB7E4244C5315B
PASS | CP019_RED_StdOut.txt | SOURCE_SHA256=EE0385191D62A978177AEDBB8547112204FDB2909F6CEDB711E3CBB7054D0515 | ZIP_SHA256=DACD8649FFA84A8AE0DF2EA316047582A112F5E049A2D7468841181FF6351D02
PASS | CP019_Regression_StdErr.txt | SOURCE_SHA256=3C3D9245BC34806B0B145AC64307213394805311D62D06ED1CA1489EE37A8BD0 | ZIP_SHA256=4605A5486DC5BEE49A286C608FD5B093407DF07031E659E54529002B9BB7E584
PASS | CP019_Regression_StdOut.txt | SOURCE_SHA256=A8A0AE611D6C9BEED52D4E66616D00D07713E926BC4293EA66154A6DB249C5D8 | ZIP_SHA256=D6EEAB32D70626DB23A7BB8A1FA23EE19D2650DDED1DD47BB90C5B67DD9FCCE7
PASS | CP019_Rustfmt_Check_StdErr.txt | SOURCE_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=8CCA34CCD8749CCF882F16CAD0C0578FE89D394229FD843B56296D742B4B5DB6
PASS | CP019_Rustfmt_Check_StdOut.txt | SOURCE_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=522BC6E769DF3DD00DEE622AEFFEF5BB67167F63E9A6054DAB8E01AEC8057B01
PASS | CP019_Source_Review.txt | SOURCE_SHA256=2D9329619A67522BAEB6B595509B669410D5BEAEE43F04774878A0616FDB83FB | ZIP_SHA256=AF0BD920DB90978D511466E2C9E9916C27F239153E88511782F9EAC5201326E6
PASS | CP019_Verification_Run_Record.txt | SOURCE_SHA256=23FA5C6BD05491A5FC98E1536CF45482FC78C0BA1AACCF31E1886CD9366A1DAF | ZIP_SHA256=570AB2452F79FCD353678261000C9B537BEA16FFBCFF0224011793C9B10E6E55
PASS | CP019_WASM_Build_StdErr.txt | SOURCE_SHA256=22253096F4A2856C201EE463B0741DB221E914B13D5997B89BEAE50C785EFABE | ZIP_SHA256=3A35D919CB3C773B00EFFBC5949FCAD2D222748FAA7058217DABC4D409DACF9E
PASS | CP019_WASM_Build_StdOut.txt | SOURCE_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=D5F517D2777BE8AB1A66B4581AADD7F75737949A53904F2E8F2869712EFF8367
PASS | CP019_Evidence_ZIP_Inventory.txt | SOURCE_SHA256=CDBC6DB9160F1A5EE2781F4403682950154084A59847BB5981903E1081D4D1AE | ZIP_SHA256=9E46B8AD1D8324D5D9F513368779C0E18A211DB634321A5703BE228996BD0ABE
PASS | CP019_Git_PreStaging_Review.txt | SOURCE_SHA256=2A4AAB1ED207FFE9E1F7904918E29A2190D044EBC40A1C5F5552A87364F6EF76 | ZIP_SHA256=D9407CE0DD7899EFDCAEE21401DAF7F358121E27E581A29007F2745C689AC137

=== STAGED PATHS ===
Evidence/CP-019/ZIP/CP019_Engineering_Preflight.txt.zip
Evidence/CP-019/ZIP/CP019_Evidence_ZIP_Inventory.txt.zip
Evidence/CP-019/ZIP/CP019_GREEN_Installation_Record.txt.zip
Evidence/CP-019/ZIP/CP019_GREEN_Run_Record.txt.zip
Evidence/CP-019/ZIP/CP019_GREEN_StdErr.txt.zip
Evidence/CP-019/ZIP/CP019_GREEN_StdOut.txt.zip
Evidence/CP-019/ZIP/CP019_Git_PreStaging_Review.txt.zip
Evidence/CP-019/ZIP/CP019_PreGREEN_lib.rs.zip
Evidence/CP-019/ZIP/CP019_RED_Installation_Record.txt.zip
Evidence/CP-019/ZIP/CP019_RED_Run_Record.txt.zip
Evidence/CP-019/ZIP/CP019_RED_StdErr.txt.zip
Evidence/CP-019/ZIP/CP019_RED_StdOut.txt.zip
Evidence/CP-019/ZIP/CP019_Regression_StdErr.txt.zip
Evidence/CP-019/ZIP/CP019_Regression_StdOut.txt.zip
Evidence/CP-019/ZIP/CP019_Rustfmt_Check_StdErr.txt.zip
Evidence/CP-019/ZIP/CP019_Rustfmt_Check_StdOut.txt.zip
Evidence/CP-019/ZIP/CP019_Source_Review.txt.zip
Evidence/CP-019/ZIP/CP019_Verification_Run_Record.txt.zip
Evidence/CP-019/ZIP/CP019_WASM_Build_StdErr.txt.zip
Evidence/CP-019/ZIP/CP019_WASM_Build_StdOut.txt.zip
src/lib.rs
tests/CP019_receipt_core_field_types.rs

STAGING_VERIFICATION=PASS

=== CP019 DIRECT GIT OBJECT VOLUME AUDIT ===
Date: 2026-10-21
Commit: 8f7460ced343de4b8662e45b2b0b5b7b69127021
Parent: 75620f17649a5d38d5357960bb99e9ac39ae354f
Committed paths: 22
Evidence ZIPs: 20
Evidence bytes: 25226
Source bytes: 17633
Tests bytes: 3873
GROSS COMMITTED BYTES: 46732
NET REPOSITORY GROWTH BYTES: 29467
Gross KiB: 45.637
Net KiB: 28.776
File ledger SHA256: B9FEA18F9E35A10047E37E0478B048A663AF0D8D737AC947E357F5C8ADB83A02
Method: git diff-tree, rev-parse, cat-file -s
Git commit created: NO
Remote push performed: NO
AUDIT RESULT: PASS

"Path","Status","Category","GitBlob","GrossBytes","PreviousBytes","NetBytes"
"Evidence/CP-019/ZIP/CP019_Engineering_Preflight.txt.zip","A","Evidence","29443f1f649d419c5c5922e7167fc4fcc4da35f2","6014","0","6014"
"Evidence/CP-019/ZIP/CP019_Evidence_ZIP_Inventory.txt.zip","A","Evidence","fc8edb39c68d134e61acda832eeef7937793f641","2187","0","2187"
"Evidence/CP-019/ZIP/CP019_GREEN_Installation_Record.txt.zip","A","Evidence","0ae22205723259d1c89eec57da07a04240053731","606","0","606"
"Evidence/CP-019/ZIP/CP019_GREEN_Run_Record.txt.zip","A","Evidence","7f1682781758e599bdd9ba2efe44b17b0a3d9ae2","570","0","570"
"Evidence/CP-019/ZIP/CP019_GREEN_StdErr.txt.zip","A","Evidence","42da25316764491788e05e0d369aa5ab6fa16cc4","349","0","349"
"Evidence/CP-019/ZIP/CP019_GREEN_StdOut.txt.zip","A","Evidence","1b3d655ffd0d3941909409067d64a964e530caa1","373","0","373"
"Evidence/CP-019/ZIP/CP019_Git_PreStaging_Review.txt.zip","A","Evidence","350ef5fc411fe1e02820aebe3f7fdf221e23a324","2195","0","2195"
"Evidence/CP-019/ZIP/CP019_PreGREEN_lib.rs.zip","A","Evidence","43c3831756fa7a19e0fc55581c11e88bc8ec8120","5109","0","5109"
"Evidence/CP-019/ZIP/CP019_RED_Installation_Record.txt.zip","A","Evidence","315a1c369ee44dbdbdf2ff33721b4a4c0645638f","624","0","624"
"Evidence/CP-019/ZIP/CP019_RED_Run_Record.txt.zip","A","Evidence","384edd12db6a7a9b42bebda51b3c006749fa5d13","522","0","522"
"Evidence/CP-019/ZIP/CP019_RED_StdErr.txt.zip","A","Evidence","3e68791f0cc8f964ef6299a85c43ac8bf2a34d5d","372","0","372"
"Evidence/CP-019/ZIP/CP019_RED_StdOut.txt.zip","A","Evidence","993d85192d8eb18e78f79a82f68dceddf842ef73","960","0","960"
"Evidence/CP-019/ZIP/CP019_Regression_StdErr.txt.zip","A","Evidence","4ce306a52a7bf4945ca90a126025a1ef4731ff16","855","0","855"
"Evidence/CP-019/ZIP/CP019_Regression_StdOut.txt.zip","A","Evidence","71d571e78b40b9e08c20e110cce85942fd8cd14c","1964","0","1964"
"Evidence/CP-019/ZIP/CP019_Rustfmt_Check_StdErr.txt.zip","A","Evidence","c84eefddafafccdfd85938fce296ff53c6c8a829","158","0","158"
"Evidence/CP-019/ZIP/CP019_Rustfmt_Check_StdOut.txt.zip","A","Evidence","09762f3e8db11d81cc2ec8c6783e8d5b51ea2d38","158","0","158"
"Evidence/CP-019/ZIP/CP019_Source_Review.txt.zip","A","Evidence","2625d03f68f5ed0a86c4d309b9e4d018ef152bb1","1067","0","1067"
"Evidence/CP-019/ZIP/CP019_Verification_Run_Record.txt.zip","A","Evidence","92e5d32988edcfe8037b8406a4e283369b36a395","698","0","698"
"Evidence/CP-019/ZIP/CP019_WASM_Build_StdErr.txt.zip","A","Evidence","339ec0d20ee6216d6125f1c12af944ada28c37c6","293","0","293"
"Evidence/CP-019/ZIP/CP019_WASM_Build_StdOut.txt.zip","A","Evidence","b5852caa9026f313d0dd27e4305aa94f0d650ec4","152","0","152"
"src/lib.rs","M","Source","1ea0543c1b61bf823f658b57c9894f1c50aa6c86","17633","17265","368"
"tests/CP019_receipt_core_field_types.rs","A","Tests","8b04b966fc5c9e5287314d9d65b97751d3ec3142","3873","0","3873"

=== CP019 RED INSTALLATION ===
Date: 2026-10-21
Git HEAD: 75620f17649a5d38d5357960bb99e9ac39ae354f
Frozen anchors: W002-RCP-005 / W002-RCP-006
Scope: ten-field Receipt core value-category enforcement
RED test file: tests/CP019_receipt_core_field_types.rs
RED test count: 6
RED test SHA256: 441ED1E5B1763F41FFDA4913FC586EE97B5879D182398295B1D66449DDCDA9AE
Source SHA256: 69A512D5DF854EAD350C220647F9B58657F2BB7A626E87BCED342916D4761955
Prior CP018 test SHA256: FAF47D9C1CE26D0AEC3EB6A857B8FC1EE9DD79505795765C159FE1A00A3DE8D3
Test file UTF-8 without BOM and LF: YES
Implementation source modified: NO
RED tests executed: NO
Git commit created: NO
Installation result: PASS

=== CP019 RED TEST ===
Date: 2026-10-21
Git HEAD: 75620f17649a5d38d5357960bb99e9ac39ae354f
Command: cargo test --test CP019_receipt_core_field_types
Exit code: 101
Expected failing tests: 4
Expected passing tests: 2
Four expected failures identified: True
Two expected passes identified: True
Test summary correct: True
Source and test hashes unchanged: True
Result: EXPECTED RED PASS
StdOut: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-019\CP019_RED_StdOut.txt
StdErr: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-019\CP019_RED_StdErr.txt
Implementation modified: NO
Git commit created: NO

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.71s
     Running tests\CP019_receipt_core_field_types.rs (target\debug\deps\CP019_receipt_core_field_types-77a22be90979861c.exe)
error: test failed, to rerun pass `--test CP019_receipt_core_field_types`

running 6 tests
test correctly_typed_core_retains_exact_output_contract ... ok
test integer_core_keys_reject_quoted_text_and_machine_token ... FAILED
test machine_core_keys_reject_integer_and_quoted_text ... FAILED
test late_type_error_refuses_the_entire_core_fragment ... FAILED
test preexisting_order_refusal_is_preserved ... ok
test quoted_core_keys_reject_integer_and_machine_token ... FAILED

failures:

---- integer_core_keys_reject_quoted_text_and_machine_token stdout ----

thread 'integer_core_keys_reject_quoted_text_and_machine_token' (5036) panicked at tests\CP019_receipt_core_field_types.rs:51:5:
assertion `left == right` failed: incorrect type must refuse for RECEIPT_VERSION
  left: Some("RECEIPT_VERSION: \"7\"\nRECEIPT_FILENAME: \"__DS__RCP__20261021T141300000Z__123e4567-e89b-42d3-a456-426614174000.txt\"\nRECEIPT_UTC: \"20261021T141300000Z\"\nWORK_ORDER_FILENAME: \"__DS__WKO__20261021T141000000Z__550e8400-e29b-41d4-a716-446655440000.txt\"\nOPERATION: MATERIALIZE\nRUN_STARTED_UTC: \"20261021T141100000Z\"\nRUN_FINISHED_UTC: \"20261021T141200000Z\"\nRESULT: SUCCESS\nDIAGNOSTIC_ID: NONE\nIDENTITY_COLLISION_RETRIES: 0\n")
 right: None

---- machine_core_keys_reject_integer_and_quoted_text stdout ----

thread 'machine_core_keys_reject_integer_and_quoted_text' (4180) panicked at tests\CP019_receipt_core_field_types.rs:51:5:
assertion `left == right` failed: incorrect type must refuse for OPERATION
  left: Some("RECEIPT_VERSION: 1\nRECEIPT_FILENAME: \"__DS__RCP__20261021T141300000Z__123e4567-e89b-42d3-a456-426614174000.txt\"\nRECEIPT_UTC: \"20261021T141300000Z\"\nWORK_ORDER_FILENAME: \"__DS__WKO__20261021T141000000Z__550e8400-e29b-41d4-a716-446655440000.txt\"\nOPERATION: 7\nRUN_STARTED_UTC: \"20261021T141100000Z\"\nRUN_FINISHED_UTC: \"20261021T141200000Z\"\nRESULT: SUCCESS\nDIAGNOSTIC_ID: NONE\nIDENTITY_COLLISION_RETRIES: 0\n")
 right: None

---- late_type_error_refuses_the_entire_core_fragment stdout ----

thread 'late_type_error_refuses_the_entire_core_fragment' (11980) panicked at tests\CP019_receipt_core_field_types.rs:88:5:
assertion `left == right` failed
  left: Some("RECEIPT_VERSION: 1\nRECEIPT_FILENAME: \"__DS__RCP__20261021T141300000Z__123e4567-e89b-42d3-a456-426614174000.txt\"\nRECEIPT_UTC: \"20261021T141300000Z\"\nWORK_ORDER_FILENAME: \"__DS__WKO__20261021T141000000Z__550e8400-e29b-41d4-a716-446655440000.txt\"\nOPERATION: MATERIALIZE\nRUN_STARTED_UTC: \"20261021T141100000Z\"\nRUN_FINISHED_UTC: \"20261021T141200000Z\"\nRESULT: SUCCESS\nDIAGNOSTIC_ID: NONE\nIDENTITY_COLLISION_RETRIES: \"0\"\n")
 right: None
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- quoted_core_keys_reject_integer_and_machine_token stdout ----

thread 'quoted_core_keys_reject_integer_and_machine_token' (8576) panicked at tests\CP019_receipt_core_field_types.rs:51:5:
assertion `left == right` failed: incorrect type must refuse for RECEIPT_FILENAME
  left: Some("RECEIPT_VERSION: 1\nRECEIPT_FILENAME: 7\nRECEIPT_UTC: \"20261021T141300000Z\"\nWORK_ORDER_FILENAME: \"__DS__WKO__20261021T141000000Z__550e8400-e29b-41d4-a716-446655440000.txt\"\nOPERATION: MATERIALIZE\nRUN_STARTED_UTC: \"20261021T141100000Z\"\nRUN_FINISHED_UTC: \"20261021T141200000Z\"\nRESULT: SUCCESS\nDIAGNOSTIC_ID: NONE\nIDENTITY_COLLISION_RETRIES: 0\n")
 right: None


failures:
    integer_core_keys_reject_quoted_text_and_machine_token
    late_type_error_refuses_the_entire_core_fragment
    machine_core_keys_reject_integer_and_quoted_text
    quoted_core_keys_reject_integer_and_machine_token

test result: FAILED. 2 passed; 4 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 2.37s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)
     Running tests\CP008_source_eligibility.rs (target\debug\deps\CP008_source_eligibility-194c314726b26929.exe)
     Running tests\CP009_exact_root_snapshot.rs (target\debug\deps\CP009_exact_root_snapshot-b26a1b02e36e8f07.exe)
     Running tests\CP010_cvt_filename_candidate.rs (target\debug\deps\CP010_cvt_filename_candidate-ce216c0140f6b173.exe)
     Running tests\CP011_cvt_scr_candidate_identity.rs (target\debug\deps\CP011_cvt_scr_candidate_identity-8bc68fabbbb42eb4.exe)
     Running tests\CP012_scr_filename_candidate.rs (target\debug\deps\CP012_scr_filename_candidate-7c39746d8bb6fac7.exe)
     Running tests\CP013_scr_rcp_candidate_identity.rs (target\debug\deps\CP013_scr_rcp_candidate_identity-4f7c7bea8654150d.exe)
     Running tests\CP014_rcp_filename_candidate_identity.rs (target\debug\deps\CP014_rcp_filename_candidate_identity-249a1cd498442ced.exe)
     Running tests\CP015_scr_rcp_filename_pair_identity.rs (target\debug\deps\CP015_scr_rcp_filename_pair_identity-526d10560ef9b891.exe)
     Running tests\CP016_receipt_field_serialization.rs (target\debug\deps\CP016_receipt_field_serialization-8c3a6628143f8cc6.exe)
     Running tests\CP017_receipt_field_sequence.rs (target\debug\deps\CP017_receipt_field_sequence-c803df96b76f21ee.exe)
     Running tests\CP018_receipt_core_envelope.rs (target\debug\deps\CP018_receipt_core_envelope-b0aa754d7846f001.exe)
     Running tests\CP019_receipt_core_field_types.rs (target\debug\deps\CP019_receipt_core_field_types-77a22be90979861c.exe)
     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)
     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)
     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)
     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)
     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)
     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 5 tests
test accepts_analyst_csv_final_extension_in_ascii_case_variants ... ok
test makes_no_case_or_unicode_normalization_claim ... ok
test refuses_paths_traversal_and_external_references ... ok
test refuses_reserved_namespace_even_if_name_looks_like_csv ... ok
test rejects_non_csv_or_nonfinal_csv_extensions ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 8 tests
test candidate_preflight_runs_before_root_matching ... ok
test full_filename_match_is_exact_and_case_sensitive ... ok
test finds_one_exact_reported_regular_file ... ok
test duplicate_exact_entries_refuse_instead_of_picking_first ... ok
test never_trims_to_find_a_different_physical_name ... ok
test reported_non_regular_entries_do_not_pass ... ok
test result_is_order_independent_and_empty_snapshot_is_not_found ... ok
test unicode_scalar_sequence_is_not_normalized ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test accepts_exact_canonical_cvt_csv_candidate ... ok
test refuses_paths_and_noncanonical_references ... ok
test refuses_wrong_classes_and_extensions ... ok
test refuses_malformed_canonical_identity ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test derives_exact_corresponding_scr_identity ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_whitespace_and_noncanonical_names ... ok
test refuses_wrong_extension_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test accepts_canonical_scr_csv_candidate ... ok
test accepts_canonical_scr_txt_candidate ... ok
test refuses_noncanonical_namespace_class_and_extension ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_and_whitespace ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test derives_rcp_candidate_only_with_explicit_class ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_invalid_identity_paths_and_whitespace ... ok
test refuses_non_scr_and_noncanonical_source_classes ... ok
test refuses_unsupported_or_incorrectly_cased_final_classes ... ok
test refuses_wrong_or_ambiguous_serialization_extensions ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test accepts_canonical_rcp_txt_identity ... ok
test recognizes_existing_scr_to_rcp_derivation ... ok
test refuses_noncanonical_serialization ... ok
test refuses_invalid_timestamp_uuid_and_envelope ... ok
test refuses_paths_and_whitespace ... ok
test refuses_wrong_semantic_class_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test accepts_matching_canonical_scr_and_rcp_txt_names ... ok
test refuses_mismatched_utc_timestamp_even_when_both_names_are_canonical ... ok
test refuses_paths_and_whitespace_on_either_side ... ok
test refuses_mismatched_uuid_even_when_both_names_are_canonical ... ok
test refuses_wrong_class_or_reversed_pair_order ... ok
test refuses_wrong_extensions_and_noncanonical_envelopes ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 8 tests
test doubles_internal_quotes_without_backslash_escaping ... ok
test filenames_and_utf8_free_text_are_double_quoted ... ok
test machine_tokens_have_exact_colon_space_and_single_lf ... ok
test machine_token_spelling_must_be_lexically_canonical ... ok
test non_negative_integers_use_ungrouped_ascii_decimal ... ok
test refuses_cr_or_lf_inside_any_single_field_value ... ok
test refuses_non_uppercase_ascii_field_keys ... ok
test text_is_preserved_without_trimming_and_document_bytes_are_deterministic ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 7 tests
test embedded_newline_in_late_text_refuses_the_entire_sequence ... ok
test empty_sequence_is_empty_formatting_not_a_valid_receipt_claim ... ok
test invalid_late_machine_token_refuses_the_entire_sequence ... ok
test invalid_late_key_refuses_the_entire_sequence ... ok
test preserves_caller_order_without_claiming_schema_order ... ok
test repeated_invocations_are_byte_identical ... ok
test utf8_quotes_and_empty_quoted_text_produce_exact_bytes ... ok

test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 9 tests
test duplicate_field_refuses ... ok
test exact_ten_core_fields_emit_exact_bytes ... ok
test empty_input_refuses ... ok
test invalid_late_value_refuses_entire_fragment ... ok
test missing_mandatory_field_refuses ... ok
test misspelled_or_wrong_case_key_refuses ... ok
test swapped_fields_refuse ... ok
test repeated_input_is_byte_identical ... ok
test unexpected_field_refuses_for_core_only_api ... ok

test result: ok. 9 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test correctly_typed_core_retains_exact_output_contract ... ok
test integer_core_keys_reject_quoted_text_and_machine_token ... ok
test machine_core_keys_reject_integer_and_quoted_text ... ok
test late_type_error_refuses_the_entire_core_fragment ... ok
test preexisting_order_refusal_is_preserved ... ok
test quoted_core_keys_reject_integer_and_machine_token ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok
test distinguishes_registered_emittable_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test preserves_extension_without_case_or_unicode_normalization ... ok
test constructs_exact_canonical_filename_candidates ... ok
test refuses_noncanonical_class_without_repair ... ok
test refuses_invalid_timestamp_uuid_and_empty_extension ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test recognizes_governed_namespace_and_class ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_invalid_class_boundaries ... ok
test reserved_prefix_is_independent_of_registered_class ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test extension_does_not_determine_semantic_class ... ok
test extracts_semantic_class_and_serialization_separately ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok
test preserves_literal_tokens_without_claiming_authority ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok
test rejects_nonexistent_gregorian_dates ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

=== CP019 FINAL SOURCE REVIEW ===
Date: 2026-10-21
Git HEAD: 75620f17649a5d38d5357960bb99e9ac39ae354f
Checkpoint: CP019
Frozen anchors: W002-RCP-005 / W002-RCP-006
Scope: Ten Receipt core field value categories
Previous source SHA256: 69A512D5DF854EAD350C220647F9B58657F2BB7A626E87BCED342916D4761955
Current source SHA256: 035AFC8D01C93DC56145C84E089FCD223B4D1FD671C202CC689EC0D39A134FFA
CP019 test SHA256: 441ED1E5B1763F41FFDA4913FC586EE97B5879D182398295B1D66449DDCDA9AE
Tracked modifications: src/lib.rs ONLY
Staged files: 0
Source whitespace: PASS
Native regression: 100 / 100 PASS
Test suites: 19
Rustfmt: PASS
WASM library build: PASS
Full Receipt semantics: NOT CLAIMED
Browser runtime: NOT TESTED
Independent implementation QA: NOT COMPLETED
Git commit created: NO

=== EXACT SOURCE DIFF ===
diff --git a/src/lib.rs b/src/lib.rs
index b6aaa20..1ea0543 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -506,10 +506,21 @@ pub fn serialize_canonical_receipt_core_envelope(
         return None;
     }
 
-    for (index, &(key, _)) in fields.iter().enumerate() {
+    for (index, &(key, value)) in fields.iter().enumerate() {
         if key != CORE_KEYS[index] {
             return None;
         }
+
+        let correct_type = match (index, value) {
+            (0 | 9, ReceiptFieldValue::NonNegativeInteger(_)) => true,
+            (1 | 2 | 3 | 5 | 6, ReceiptFieldValue::QuotedText(_)) => true,
+            (4 | 7 | 8, ReceiptFieldValue::MachineToken(_)) => true,
+            _ => false,
+        };
+
+        if !correct_type {
+            return None;
+        }
     }
 
     serialize_canonical_receipt_field_sequence(fields)

SOURCE_REVIEW=PASS

=== CP019 VERIFICATION ===
Date: 2026-10-21
Git HEAD: 75620f17649a5d38d5357960bb99e9ac39ae354f
Frozen anchors: W002-RCP-005 / W002-RCP-006
RED gate: EXPECTED RED PASS (previously verified)
GREEN gate: 6/6 PASS (previously verified)

=== RUSTFMT ===
Command: cargo fmt --all -- --check
Exit code: 0

=== NATIVE REGRESSION ===
Command: cargo test --all-targets
Exit code: 0
Passed: 100
Failed: 0
Suite summaries: 19

=== WASM ===
Command: cargo build --target wasm32-unknown-unknown --lib
Exit code: 0

=== INTEGRITY ===
Source SHA256: 035AFC8D01C93DC56145C84E089FCD223B4D1FD671C202CC689EC0D39A134FFA
Test SHA256: 441ED1E5B1763F41FFDA4913FC586EE97B5879D182398295B1D66449DDCDA9AE
Source unchanged: True
Test unchanged: True
Git HEAD unchanged: True
Git staging empty: True
Git commit created: NO
Browser runtime tested: NO
Independent implementation QA completed: NO

VERIFICATION_RESULT=PASS

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.37s

requirement_id,title,family,major_family,scope,source_prd_status,source_build_flag,requirement_text,implementation_state,local_verification,independent_qa,requirement_acceptance,linked_checkpoints,checkpoint_disposition,git_commits,test_evidence,implementation_notes,last_evidence_day,source_revision
PB-STOR-001,Suitcase is the complete Data Sculptor-controlled persistence surface,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Every persistent project or analytical artifact intentionally created by Data Sculptor must be written into the visible, user-controlled Suitcase. Data Sculptor must not intentionally persist user data, analytical state, scratch state, logs, recovery state, or project metadata in hidden AppData-style locations or browser-private persistence such as OPFS. Incidental browser/OS runtime caches outside Data Sculptor control are explicitly outside this contract. F-24 browser-session persistence boundary: WASM-002 must not use IndexedDB, localStorage , OPFS, another browser-private database, or an equivalent hidden Data Sculptor-controlled persistence surface to remember a Suitcase directory handle, unsaved WIP text, project truth, analytical state, or live UI preferences between application instances. A later build may deliberately define a user-visible preferences or continuity mechanism, but WASM-002 does not create one implicitly. Volatile in-memory runtime state within the current application instance is permitted.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-002,No Data Sculptor-created subfolders,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor does not create scratch/cache subfolders inside the Suitcase. Logical organization is expressed by the flat filename grammar, open metadata, Store MAP, and human-facing aliases.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-004,__DS__ is the reserved Data Sculptor governed namespace,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Every artifact that Data Sculptor creates or intentionally interprets as one of its governed artifacts must use the exact visible prefix __DS__ . The prefix identifies participation in the Data Sculptor namespace; it does not imply that the artifact is temporary, scratch-only, or automatically generated.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-001,BANKED; separate requirement acceptance not claimed,03201870b8ec68730a0c027c572db03ccd5eeaa8,Evidence/CP-001/CP001_GREEN2_Test_Output.txt; Evidence/CP-001/CP001_WASM_Build_Output.txt,"CP001: bounded lexical artifact-class recognition via reserved_artifact_class(). Five native tests passed and Rust wasm32-target library built. No content/provenance/authority validation, persistence, or complete governed artifact contract implemented.",Day063,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-005,External inputs retain their identity; Data Sculptor derivatives enter the namespace,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"An analyst or external source file must not be renamed into __DS__ merely because Data Sculptor reads, fingerprints, certifies, or references it. If Data Sculptor creates a new governed derivative—such as an explicit converted source—the new artifact enters the __DS__ namespace under its semantic class. F-26 SOURCE boundary: a Suitcase-root file whose exact filename begins with the reserved prefix __DS__ is not treated as an analyst-owned source merely because it has a CSV-like extension or CSV-like bytes. It participates in the reserved Data Sculptor namespace and must satisfy the applicable governed-artifact contract before any governed role is granted.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-002,"T-ACCEPTED, BANKED; requirement remains partial",206dcd8b76af29edcb658a0c5a2dc40d87089fe3,Evidence/CP-002/CP002_Post_Format_Test_Output.txt; Evidence/CP-002/CP002_Post_Format_WASM_Build_Output.txt; Evidence/CP-002/CP002_Hash_Inventory_Verification.txt,CP002: exact __DS__ lexical prefix recognition via has_reserved_namespace_prefix(). Six native tests and wasm32-target compilation passed. The SOURCE boundary and governed CVT validation/emission rules in this requirement are NOT implemented.,Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-006,The governed semantic artifact-class registry is explicit and stable,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The token immediately following __DS__ must be an exact three-uppercase-letter semantic artifact class. The governed class tokens currently reserved by this PRD are: Class Meaning WKO Work Order RCP Receipt DGN Diagnostic Event — reserved; not emitted by WASM-002 HLP Help Report CER Certification Evidence CVT Converted Source RID Row Identity COL Materialized Column MAP Governed MAP artifact class — Store MAP and WKO MAP profiles CAT Store Catalog — collection-level orientation index across MAP-governed Stores INV Suitcase Inventory Snapshot SCR Scratch / Structural Support RCV Recovery Artifact — reserved; not emitted by WASM-002 BRD Brand Manifest — reserved; not emitted by WASM-002 LCK Suitcase Lock — reserved for the explicit later-V1 FINGERPRINT workflow; not emitted or maintained by ordinary WASM-002 WASM-002 emission boundary. DGN , RCV , BRD , and LCK are registered/reserved classes but are not emitted by WASM-002. Registration alone does not create a producer, serialization contract, validity contract, lifecycle, or acceptance surface. A later build that activates one of these classes must define those contracts explicitly before the class becomes emitted product behavior. The class states semantic role rather than serialization format. WIP is not an artifact class; it is the editable non-executable Work Order lifecycle state. The Flight Recorder defined by W002-STOR-012 is a derived chronological view of governed RCP artifacts and is not an additional semantic artifact class. Existing class tokens must not be silently reassigned to different meanings. A new class requires an explicit PRD revision.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-001; CP-003,CP-001 banked; CP-003 T-accepted and banked; requirement remains partial,03201870b8ec68730a0c027c572db03ccd5eeaa8; 2d06f6259de93f5beaa8eb15f8f22f171127a10e,Evidence/CP-001/CP001_GREEN2_Test_Output.txt; Evidence/CP-001/CP001_WASM_Build_Output.txt; Evidence/CP-003/CP003_Post_Format_Test_Output.txt,"CP001: bounded lexical artifact-class recognition via reserved_artifact_class(). Five native tests passed and Rust wasm32-target library built. No content/provenance/authority validation, persistence, or complete governed artifact contract implemented. CP003 adds locally verified lexical distinction between the 11 emittable-class tokens and four registered-but-not-emitted tokens; full governance/producer behavior not implemented.",Day063,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-007,Serialization is orthogonal to artifact class,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Filename extensions such as .toml , .html , .csv , .bin , and .txt describe physical serialization only and must not be used as semantic artifact classes. A governed HLP serialized as .html remains an HLP, and a governed WKO serialized as .txt remains a WKO. Any future BRD serialization must obey the same class-versus-format separation, but its format is not frozen by WASM-002.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-006,"T-ACCEPTED, BANKED; full class-specific serialization and authority contracts remain open",aff54d08dcbacaa0c54d8869749344a504c5ad61,Evidence/CP-006/CP006_RED_Test_Output.txt; Evidence/CP-006/CP006_Post_Format_Test_Output.txt; Evidence/CP-006/CP006_WASM_Build_Output.txt; Evidence/CP-006/CP006_Hash_Inventory_Verification.txt; Evidence/CP-006/CP006_Precommit_Git_Review.txt,"CP006: public ArtifactFilenameTokens and extract_artifact_filename_tokens() reuse the CP004/CP005 immutable filename validator and extract semantic_class and serialization_extension as separate borrowed lexical fields. Four new tests, total 19/19 native tests post-format; wasm32-target compilation exit 0; 20-file pre-verification SHA-256 inventory independently matched. Literal unknown class and extension values preserved without registration or approval. No class-specific extension allowlist, format contract, file contents, provenance, governed publication, trust, or authority implemented. T accepted CP006 and banked commit aff54d08dcbacaa0c54d8869749344a504c5ad61; independent Claude implementation QA remains pending. This is requirement PARTIAL, not fully closed.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-008,Namespace and class do not confer authority by themselves,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Renaming an arbitrary file to resemble a __DS__ artifact must not make it authoritative. Before treating a governed artifact as valid, Data Sculptor must validate the applicable filename grammar plus the content, provenance, fingerprint, lineage, or other evidence required by that artifact's contract. F-14/F-33 publication distinction: SCR-to-final promotion under W002-STOR-023 proves only that the artifact satisfied its class-specific publication predicate. It does not manufacture broader authority. In particular, WKO alias authority still comes from the committed WKO MAP, Store authority comes from the committed Store MAP, and CAT is orientation only. Retained SCR failure evidence remains non-authoritative, and the reserved RCV class is not emitted by WASM-002. F-26 SOURCE authority: a governed CVT is eligible as a WASM-002 SOURCE only when its exact canonical CVT identity and the publication predicate governed by W002-CONV-004 and W002-STOR-023 are satisfied. Filename resemblance, a .csv extension, or copied bytes alone do not confer CVT source authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,Cross-cutting constraint recognized in CP001/CP002 scope: filenames/classes alone convey no artifact authority. This requirement is NOT claimed implemented or touched.,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-009,Unknown and known-but-not-emitted Data Sculptor classes are preserved and reported,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"If WASM-002 encounters a syntactically valid __DS__ artifact whose three-letter semantic class is not allocated in the current registry, or whose class is a registered-but-not-emitted WASM-002 class ( DGN , RCV , BRD , or LCK ), Data Sculptor must preserve the physical file unchanged. It must not trust, execute, mutate, delete, rename, or reinterpret that file as a known emitted artifact merely because the filename has governed form. Unknown class does not mean invalid data; it means this build has no authority to interpret that class. A known-but-not-emitted class is likewise not an instruction to activate a dormant producer or lifecycle. Whenever a WASM-002 operation performs the governed Suitcase scan/enumeration relevant to such a file, the condition must be surfaced through a canonical INFO diagnostic rather than being silently ignored. INVENTORY must include the physical file under its existing metadata-only contract; if an existing classification field is rendered, an unknown class is identified as unknown/unrecognized and a known-but-not-emitted class is identified as reserved/not emitted without guessing additional semantics. F-33 adds no new Inventory schema field and does not pull the governed DIR feature into WASM-002.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-003,"T-ACCEPTED, BANKED; full preservation/INFO requirement not closed",2d06f6259de93f5beaa8eb15f8f22f171127a10e,Evidence/CP-003/CP003_Post_Format_Test_Output.txt; Evidence/CP-003/CP003_WASM_Build_Output.txt; Evidence/CP-003/CP003_Hash_Inventory_Verification.txt,"CP003: token-only Rust classify_artifact_class_token() returns registered/emittable, registered/not-emitted, unallocated, malformed-reserved, or outside-reserved disposition. Three new tests (27 cases) plus six prior regression tests passed, wasm32 compilation exit 0, 15-file historic SHA-256 inventory verified. No Suitcase scan, filesystem preservation, canonical INFO diagnostic, INVENTORY integration, full filename validity, or artifact authority implemented. RegisteredEmittable describes a class category; it does not authorize emission. Independent Claude QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-010,Namespace and class casing are canonical and exact,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor-generated names must use exact uppercase __DS__ and exact uppercase three-letter class tokens. Data Sculptor must not silently normalize variant namespace/class spellings into canonical governed artifacts. This rule applies even on case-insensitive filesystems. F-15 governed comparison rule: unless a requirement explicitly defines a different domain-specific comparison, WASM-002 semantic equality and textual reference resolution compare decoded strings by exact Unicode scalar-value sequence. Data Sculptor performs no case folding, locale folding, Unicode normalization, trimming, or host-filesystem equivalence before the comparison. Thus differently cased strings and canonically equivalent-but-differently-encoded Unicode strings remain distinct governed values. If a host filesystem cannot safely publish two physical names that the governed semantics distinguish, publication must refuse rather than merge or reinterpret the governed identities.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-007; CP-009; CP-010,"T-ACCEPTED, BANKED; exact lexical construction verified; full normative requirement remains partial; CP009 T-ACCEPTED, BANKED — pure exact-name root snapshot matching only; full requirement remains partial; CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open",3c512df519f3a2431b363e4c57dc234c02378124; dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8; b7c515faa9bd000369d7656e09437310261290ae,Evidence/CP-007/CP007_RED_Test_Output.txt; Evidence/CP-007/CP007_GREEN_Test_Output.txt; Evidence/CP-007/CP007_Post_Format_Test_Output.txt; Evidence/CP-007/CP007_WASM_Build_Output.txt; Evidence/CP-007/CP007_Hash_Inventory_Verification.txt; Evidence/CP-007/CP007_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Baseline_Test_Output.txt; Evidence/CP-009/CP009_RED_Test_Output.txt; Evidence/CP-009/CP009_GREEN_Test_Output.txt; Evidence/CP-009/CP009_Full_Regression_Test_Output.txt; Evidence/CP-009/CP009_Rustfmt_Check_Output.txt; Evidence/CP-009/CP009_Git_Whitespace_Check.txt; Evidence/CP-009/CP009_Post_Format_Test_Output.txt; Evidence/CP-009/CP009_WASM_Build_Output.txt; Evidence/CP-009/CP009_Hash_Inventory.txt; Evidence/CP-009/CP009_Hash_Inventory_Verification.txt; Evidence/CP-009/CP009_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Final_Staging_Review.txt; CP009_Git_Banking_Output.txt (separately archived post-commit evidence); Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived),"CP007: public build_immutable_artifact_filename_candidate() assembles exact class, UTC timestamp, UUID v4 and serialization extension tokens into an ordinary canonical immutable filename candidate; it delegates validation to the existing CP004/CP005 envelope validator and refuses malformed casing/identities rather than case-folding, trimming or normalizing input. Four new integration tests, total 23/23 native tests after Rustfmt; wasm32-target compilation exit 0; 21-entry SHA-256+byte inventory independently verified. Lexically valid unknown class tokens and unapproved extension tokens may be preserved as candidates; this grants no registration, serialization contract, authority, filesystem publication or content/provenance validation. The F-15 exact Unicode scalar-value semantic equality and host-filesystem collision/refusal requirements are NOT implemented. T approved and banked commit 3c512df519f3a2431b363e4c57dc234c02378124 (14 files), clean master; independent Claude adversarial implementation QA pending. Requirement remains PARTIAL, not fully closed. CP009 Day066: match_analyst_csv_root_snapshot(&str, &[RootSnapshotEntry]) -> RootSnapshotMatch applies CP008 analyst CSV candidate preflight, then exact Rust string equality (case, Unicode scalar sequence and whitespace preserved), reports no match, reported nonregular entry, ambiguous duplicate exact entries, or single caller-reported regular file. Entry origin and kind are caller assertions, not independently verified. Eight new tests; post-format full native regression 36/36; wasm32-unknown-unknown library compilation exit 0; SHA-256 inventory verified 22/22; staged whitespace exit 0; T approved and git banked 15 files, clean working tree. This is NOT actual root scanning, filesystem entry proof, browser permission, CSV/UTF-8 certification, governed CVT SOURCE eligibility or end-to-end requirement acceptance; independent Claude QA pending. CP010 Day066 also tests canonical uppercase __DS__/CVT tokens and exact lowercase .csv conversion-output extension, refusing variant prefix/class/extension spellings; existing canonical validator is reused without repair or normalization. Only lexical form is locally verified: no actual filesystem identity enforcement or publication collision handling. T accepted CP010; git b7c515faa9bd000369d7656e09437310261290ae; independent QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-011,Generated identity collisions regenerate the UUID and never overwrite,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor must never overwrite, rename, truncate, or mutate an existing artifact merely because a newly generated governed filename collides with it. For an ordinary immutable artifact using the governed UTC+UUID identity grammar, Data Sculptor must keep the originally established canonical UTC millisecond creation timestamp, generate a new canonical lowercase hyphenated UUID v4, reconstruct the candidate filename, and try creation again. Collision retry must not advance or falsify the artifact creation timestamp merely to obtain a different sort position. This retry may repeat until an unused valid identity is obtained. If UUID generation fails, the host cannot safely test/create the target, or another filesystem error prevents safe allocation, creation must refuse through the canonical diagnostic path rather than risk overwrite. Collision retry changes only the not-yet-created artifact's UUID. UUID is never used as a chronology field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-012,Names route; governed contents and provenance prove,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The filename must help humans and Data Sculptor identify the artifact's intended semantic role and route it to the correct validator. The artifact's governed content, lineage, receipt, fingerprint, provenance, and other required evidence establish what is actually true.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-013,Ordinary immutable governed artifacts use class → UTC millisecond → UUID v4 identity order,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The exact default filename grammar for an ordinary immutable Data Sculptor-governed artifact is: __DS__CCC__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.<extension> CCC is the governed semantic artifact class. YYYYMMDDTHHMMSSmmmZ is the artifact's governed UTC creation/publication timestamp at millisecond precision: four-digit year, two-digit month/day/hour/minute/second, exactly three millisecond digits, and literal T / Z . <uuid-v4> is a canonical lowercase hyphenated UUID v4. The extension is governed by the artifact's serialization contract. The token order is normative: namespace, semantic class, UTC timestamp, UUID, extension. UTC precedes UUID for every ordinary immutable class. Canonical UTC tokens with different values sort chronologically within the same class. UUID provides uniqueness and physical identity only; it must not be interpreted as a chronology tie-breaker when two artifacts share the same timestamp. When one governed all-or-refuse Store-state publication transaction creates multiple new analytical state artifacts, Data Sculptor establishes one canonical UTC millisecond publication-transaction timestamp before final identity allocation and uses that same UTC token for every newly published RID , COL , and MAP artifact created by that transaction. Each artifact receives its own UUID. Thus a first Store materialization gives the new RID, every newly materialized COL, and the successor MAP one shared transaction UTC; a later materialization gives only its newly created COL artifacts and successor MAP the new transaction UTC while the inherited RID and inherited COL artifacts retain their earlier identities. The shared transaction UTC is not the Work Order's authoring timestamp and does not require the Receipt filename UTC to match. RCP remains governed by W002-RCP-002 and carries its own receipt creation/publication timestamp. A shared transaction UTC expresses common publication membership, but MAP binding—not timestamp equality—remains authoritative for Store membership/current state. Source identity, source filename, run identity, parent identity, lineage, hashes, aliases, supersession, column identity, and other relationships must not be appended as ordinary identity tokens merely to make the filename descriptive; those facts belong in governed metadata and provenance. P2-03 successor-state UTC rule: when an operation will publish a successor Store MAP or successor WKO MAP, the transaction UTC remains a truthful observation of host UTC and must be strictly greater than the applicable chronology predecessor MAP UTC. Data Sculptor must not synthesize, increment, round forward, or otherwise fabricate a later UTC merely to satisfy chronology. UUID remains identity only and is never a chronology tie-breaker. The first MAP in a genuinely new Store lineage, and the first WKO MAP when no structurally valid WKO MAP exists, has no chronology predecessor and therefore uses the observed host UTC normally.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Immutable filename envelope, UTC and UUID syntax only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. Full requirement also governs true UTC millisecond identity, creation chronology, publication timestamp sharing, UUID identity semantics, and successor MAP chronology; none are implemented in CP004. Independent QA pending. CP005: CP005 now validates the timestamp token as a real Gregorian calendar date and ordinary UTC clock time (four-digit years 0001–9999, leap years, month lengths, 00–23 hours, 00–59 minutes/seconds, millisecond precision preserved lexically). Actual UTC issuance/publication, timestamp allocation, chronological truth, common transaction timestamp and identity authority are not implemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-014,Store-state publication transactions share UTC but never UUID identity,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Within one all-or-refuse Store-state publication transaction, every newly created RID , COL , and MAP final identity must carry the exact same canonical UTC millisecond transaction token and a distinct canonical UUID v4. UUID collision retry under PB-STOR-011 changes only the affected not-yet-created artifact UUID; it must not advance or alter the shared transaction UTC. Artifacts merely inherited or referenced by the transaction are not renamed, retimestamped, or assigned replacement UUIDs. A valid MAP may therefore bind artifacts created under several earlier transaction timestamps. Timestamp equality is evidence that artifacts were newly published by the same transaction; timestamp inequality is not evidence that artifacts belong to different Stores. P2-03 publication guard: for a successor Store-state transaction, the shared transaction UTC is established from truthful observed host UTC and is checked against the Store lineage's chronology predecessor before any newly created RID/COL/MAP artifact is promoted into its final governed class. If the observed transaction UTC is less than or equal to the chronology predecessor UTC, the publication refuses; the prior current MAP remains authoritative and no successor Store state commits.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-OPS-001,Permanent row identity after materialization,PB-OPS,PB-OPS,WASM-002,UNDER REVIEW,—,"Each logical Store has exactly one visible, deterministic RID artifact representing 1..N in governed logical CSV-record order. The header is excluded. Physical line count is not row identity: embedded newlines inside quoted fields remain inside one logical record. The RID is created when the first successful materialization establishes the Store and remains stable for the life of that Store. Every same-Store materialized or later aligned result column must contain exactly N data records in the same RID order. Multiple Stores may coexist in one Suitcase, and their RID values are unrelated; the meaningful row identity is therefore the pair (Store, RID) .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-OPS-002,Materialized columns preserve facts and alignment,PB-OPS,PB-OPS,WASM-002,UNDER REVIEW,—,Materialized columns preserve governed values in permanent row alignment. Materialization stores facts for reuse; it does not decide which rows are analytically interesting.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001,Flat Project Suitcase,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,The durable WASM-002 project model must not require semantic per-store subfolders. A logical store is represented by governed relationships among artifacts and metadata inside a flat project folder.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.1,The flat model must remain usable through ordinary filesystem tools.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.2,Native and browser hosts must use the same logical storage semantics even when their filesystem APIs differ.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.3,Folder placement must not be treated as the authoritative meaning of an artifact.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-002,Reserved Core namespace and sorting,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Every Data Sculptor Core-managed artifact must use the reserved __DS__ prefix. The prefix is deliberately visually distinctive and mechanically simple so Core artifacts cluster together under ordinary filename sorting in a mixed flat folder.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003,Three-character base-26 artifact class,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The class token must be exactly three uppercase ASCII letters A through Z, giving the fixed physical range AAA through ZZZ, and must immediately follow the reserved namespace within the frozen filename grammar.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.1,The three-character alphabetic class rule supersedes every earlier numeric class example.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.2,"Class ordering is positional base-26 using the alphabet A through Z: AAA, AAB, AAC, ... AAZ, ABA, ... ZZZ.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Ordinary lexical filename sorting therefore preserves the governed class order.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.3,"The namespace contains 26 cubed, or 17,576, possible class values while preserving one fixed-width token.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.4,Unallocated class tokens remain unassigned until explicitly allocated,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"WASM-002 does not reserve semantic meaning by numeric interval, lexical neighborhood, or implied class range. Any syntactically possible three-letter token that is not listed in the governed registry is unassigned for this build. A future artifact class may be allocated only by explicit PRD revision. Existing class meanings must never be shifted, renumbered, or reassigned merely to make room for later families.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.5,The WASM-002 artifact-class table is frozen by the governed registry,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The exact WASM-002 artifact-class table is the registry in PB-STOR-006. It is no longer a separate open storage freeze item. No additional reserved class ranges are defined by WASM-002. DGN , RCV , BRD , and LCK remain registered/reserved but are not emitted by WASM-002. Their presence in the registry does not create a WASM-002 producer, serialization contract, validity contract, lifecycle, or acceptance surface. Independent adversarial review must verify that every WASM-002-generated governed artifact uses a listed class that this build actually emits, that WIP remains a lifecycle state rather than a class, and that unknown/unallocated classes plus known-but-not-emitted classes are preserved and reported under PB-STOR-009 rather than silently interpreted or activated.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-004,Canonical Core filename envelope,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The default Core physical naming model for immutable governed artifacts is __DS__<CLASS>__<UTC>__<UUID>.<ext> . CLASS, UTC, and UUID are governed identity tokens. Human semantic labels are excluded from the physical identity envelope. A separately frozen artifact contract may define a well-known current-state singleton filename when that artifact must be updated in place and discovered by a stable name.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Default immutable filename-envelope structure only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. Singleton exception support, class-specific contracts and authority remain unimplemented. Syntactic success does not imply an authorized artifact. Independent QA pending. CP005: CP005 adds Gregorian calendar/UTC-clock validity to the already recognized immutable Core physical name. Singleton filenames, artifact-type extension rules and authorization remain unimplemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005,Canonical filename shape and fixed token lengths,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Every governed Core artifact type must have a canonical filename shape and total filename length so that a parser, browser host, native host, QA tool, or LLM can recognize malformed physical identity without interpreting variable human language. Under the Revision AH default immutable grammar, the canonical UTC token YYYYMMDDTHHMMSSmmmZ is exactly 19 ASCII characters and the canonical lowercase hyphenated UUID v4 token is exactly 36 ASCII characters. Class precedes UTC and UTC precedes UUID.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Fixed core lexical UTC (19 ASCII) and UUID v4 (36 ASCII) structure only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. No calendar validation, class/extension contract mapping, class-specific total length table, or filename publication gate is claimed. Independent QA pending. CP005: CP005 strengthens the fixed 19-ASCII-character UTC token with Gregorian calendar and UTC-clock range checks. Class-specific total filename lengths, extension mapping, and publication gates remain unimplemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.1,"If an artifact class has exactly one governed representation, all filenames in that class have one frozen total length.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.2,"If a future class permits more than one representation, each class/representation pair must still have a frozen total length.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.3,"Friendly store names, column names, aliases, and operation descriptions must never stretch or shorten a Core physical filename.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-006,Physical identity versus integrity,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,UUID identifies the governed artifact instance. SHA-256 records or verifies the exact bytes. The system must not overload one field to serve both identity and integrity.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007,Collision handling,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Physical filename collisions are expected to be rare but must be handled explicitly. Data Sculptor must never silently overwrite an existing governed artifact because a generated physical name already exists.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.1,"Before durable creation, the host must check whether the target physical name already exists.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.2,"On a UUID collision, the existing artifact is preserved and a fresh UUID is generated under the same relevant UTC/class context unless a later frozen rule requires a different deterministic response.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.3,Collision handling must be visible in the run Receipt/evidence when it occurs,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If governed identity allocation encounters one or more filename collisions before successfully allocating a non-colliding UUID identity, the canonical run Receipt must record that a collision retry occurred and the number of retries when the run reaches receipt publication. If identity allocation ultimately refuses, the refusal Receipt and diagnostic evidence must preserve the collision-failure fact without overwriting or mutating any pre-existing artifact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-008,Analyst-owned files remain analyst-owned,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Source files and analyst documents may retain their original filenames. Data Sculptor must not rename every input merely to fit the governed __DS__ namespace. For an ordinary WASM-002 analytical run, continuity between certification and materialization is established by the run-local source-binding contract, not by pretending a mutable source filename is permanent byte identity. Durable cross-run exact-byte verification requires separately governed integrity evidence such as the later V1 FINGERPRINT operation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-009,Store MAP as machine truth,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The Store MAP must provide the machine-readable relationship between governed physical artifacts and their logical meaning, including the fields required by the frozen schema for store identity, column identity, source reference/binding, run/materialization identity, row counts, status, lineage, supersession, and related provenance. Cryptographic hashes are recorded when a requirement or explicit operation actually produces them; the Store MAP contract must not imply that every source or artifact is automatically hashed during ordinary WASM-002 execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010,Aliases provide human orientation without a separate Store Index,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, human-facing orientation is provided by aliases exposed from governed Store MAP state and related governed artifacts. Aliases may help analysts navigate by meaning while preserving exact physical identities. WASM-002 does not publish or maintain a separate Store Index artifact. Richer directory/index presentation is carried by the governed DIR surface in WASM-003.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010.1,WASM-002 Store MAP profile is the unified Store metadata snapshot,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, the Store MAP profile of the governed MAP artifact class is the Store metadata snapshot. It records the Store's human-facing alias, Store-establishing source filename, exact RID artifact binding, RID alias, and the complete current materialized-column mappings and aliases governed by W002-STOR-019 through W002-STOR-019.12. WASM-002 must not create a second hidden or separately named Store-metadata file merely to bind the Store to its RID or aliases. The visible immutable __DS__MAP__...csv artifact is the authoritative governed Store MAP for this build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010.2,"Changing a friendly alias must not change physical identity, hashes, lineage, or historical provenance.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-011,"Store, row-universe, and future Boolean-selection-column rule",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Same-row derived columns and later aligned Boolean selection/filter columns remain within the same logical Store when row identity, row order, and cardinality are preserved. A future filter that evaluates every existing RID and writes one aligned two-valued Boolean result per RID does not by itself create a new row universe or a new logical Store. The canonical future selection tokens are 0 for FALSE and 1 for TRUE under PB-OPS-003 and PB-OPS-003.1. A new row universe is created only when a later governed operation actually changes which rows exist or their order—for example by building/exporting only selected rows, deduplicating rows, or otherwise materializing a different row set. Such an operation creates a new logical Store identity under the frozen row-identity contract. Filtering remains deferred from executable WASM-002 scope; this requirement freezes only the Store/RID compatibility rule that later filtering will rely upon.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-012,Current orientation and history are different truths,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Current Store orientation is represented by the applicable immutable MAP snapshot, while execution history is preserved by immutable RCP Receipts. For WASM-002, the Flight Recorder is the logical chronological view of published canonical RCP artifacts from actual Run invocations of saved immutable WKO Work Orders. It is not separately persisted and has no separate artifact class. Successful and refused runs contribute when Receipt publication succeeds; Receipt-publication failure is governed by W002-RCP-010 and must not be silently reconstructed as original evidence. Any Flight Recorder presentation is derived and regenerable from the authoritative Receipts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-013,Open representations,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Durable project artifacts should use documented open formats such as CSV, HTML, TXT, TOML, or other explicitly governed representations so that the Suitcase remains inspectable and portable outside Data Sculptor.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-014,LLM-readable storage grammar is a documentation principle,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The storage grammar, class table, Store MAP schema, current-state selection rule, and alias semantics must be documented clearly enough that an LLM collaborator can distinguish physical identity, logical meaning, integrity evidence, current state, and history without guessing. This is a documentation/readability principle for the Product Backlog PRD and related public product documentation. It does not create a new governed Suitcase artifact, require a new public-documentation file or publication operation, or add a separate WASM-002 acceptance deliverable beyond keeping the governing contract explicit and internally consistent.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-015,WASM-002 storage freeze status,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The current WASM-002 storage design preserves the resolved semantic artifact-class registry, canonical UTC millisecond rendering, class → UTC → UUID token order, UUID rendering/version, default immutable identity grammar, collision retry behavior, immutable one-Store-per-MAP versioning, Store-aware automatic MAP inheritance, complete-snapshot semantics, the exact eight-column Store MAP schema, deterministic Store/RID/COL alias defaults, rematerialization alias continuity, deterministic Store-MAP CSV serialization, Store-MAP eligibility/publication validation, materialization-coupled AS alias semantics, standalone alias maintenance using UPDATE ALIASES , explicit alias clearing with CLEAR ... ALIAS , deterministic default restoration with RESET ... ALIAS , exact historical Store-MAP selection using MAP ""<exact Store MAP filename>"" , canonical one-column COL serialization, the all-or-refuse materialization publication boundary, SCR -to-final-class host rename promotion, complete-set validation before promotion, new-Store RID-first promotion, inherited-RID reuse for existing-Store work, deterministic COL promotion, successor-MAP construction/validation as SCR , successor-MAP rename last as the Store-state commit point, rollback/recovery treatment for uncommitted promoted artifacts, the canonical RID CSV contract, the seven-operation Work Order execution surface, the canonical automatic TXT Receipt contract including exact WKO lineage, the Receipt-backed Flight Recorder, the governed HTML Suitcase Validation Certificate, the Work Order alias/comment contract plus WKO-MAP alias-registry profile, and the LCK reservation for explicit later-V1 FINGERPRINT evidence without automatic hashing in ordinary WASM-002. RID reconstruction/replacement is deliberately not part of the WASM-002 executable surface; RECOVER RID requirements are deferred to V1-BACKLOG. The Help-report provenance boundary is resolved: WASM-002 records governed HLP identity and lineage but does not automatically SHA-256 HLP bytes or create/refresh LCK evidence; exact-byte HLP integrity remains the later explicit FINGERPRINT/LCK workflow. Future branded Receipt rendering/Brand-Manifest integration remains outside the WASM-002 TXT-only Receipt contract. P2-04 closure: WASM-002 Store governance now has a complete two-tier artifact-validation model. Tier 1 supplies bounded Store-health checks for non-content-consuming paths; Tier 2 supplies full streaming RID/COL validation for content-consuming paths, candidate commit, and REPAIR MAP . The eight-column Store MAP remains unchanged and ordinary Store health makes no cryptographic claim of historical-byte identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-001,Every actual Run invocation of a saved WKO automatically produces one Receipt attempt,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"When the analyst invokes Run on a saved immutable WKO, Data Sculptor must automatically create one governed run-receipt attempt for that invocation. The Work Order must not require a RECEIPT , SAVE RECEIPT , or equivalent clause. An editable unsaved WIP is non-executable under the Work Order lifecycle contract and therefore cannot produce an execution Receipt. A saved WKO that is invoked and then refuses during validation or execution still has an execution outcome and must receive a refusal Receipt when receipt publication succeeds.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-002,The canonical WASM-002 Receipt is a governed TXT artifact with its own creation timestamp,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,The physical Receipt filename is: __DS__RCP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt The UTC token belongs to the Receipt artifact itself and represents the Receipt's governed creation/publication time under the canonical artifact-identity rules. It must not be copied from the authorizing WKO's filename merely to make the two filenames share a timestamp. The file is written visibly in the flat Suitcase under the governed RCP artifact class. Data Sculptor chooses the governed filename; the analyst does not supply it.,PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-014; CP-015,"CP014 T-ACCEPTED, GIT BANKED — canonical RCP TXT filename lexical recognizer only; own creation-time allocation, file emission, complete Receipt contract and publication unimplemented; CP015 T-ACCEPTED, GIT BANKED — pure lexical canonical SCR-to-RCP TXT filename-candidate pair matching only; no actual file/Receipt validation, promotion, publication or authority",f5038a183f1d3dc31b0065571bf8ac8814b5d8a9; be997dc0dbd65fc370814c4a5f2d0f1254870572,Evidence/CP-014/ZIP/CP014_RED_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_WASM_Build_Record.txt.zip; CP014_Git_Banking_Record.txt (external closeout); Evidence/CP-015/ZIP/CP015_RED_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_GREEN_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_PostAmend_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_Full_Regression_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_WASM_Build_Output.txt.zip; Evidence/CP-015/ZIP/CP015_Final_Archive_Manifest.txt.zip; CP015_PostCommit_Verification.txt (external closeout),"CP014 Day067: T-accepted, Git-banked lexical RCP .txt filename recognizer only. Pure is_canonical_rcp_filename_candidate(&str)->bool uses shared canonical envelope, rejects wrong class/extension/casing, malformed UTC/UUID, paths and whitespace. Six target GREEN passes; 64/64 native regression; Rustfmt and wasm32 library build PASS; 32 original-TXT-per-ZIP objects validated and committed unchanged. Commit f5038a183f1d3dc31b0065571bf8ac8814b5d8a9. No new Receipt timestamp generation, Receipt byte serialization, creation/promotion/publication or authority; independent implementation QA and browser runtime pending. CP015 Day067: T-approved pure is_matching_scr_rcp_filename_candidate_pair(&str,&str)->bool checks canonical SCR/RCP lowercase .txt candidates and exact timestamp/UUID pairing, reusing existing lexical recognizers and candidate derivation; rejects wrong classes/order, mismatched timestamps/UUID, paths, whitespace and noncanonical envelopes. Expected RED E0432 exit 101; six targeted GREEN PASS; T-approved formatting-only source+test amendment and recheck; full native regression 70/70 PASS, Rustfmt PASS, Rust 1.97.1 wasm32-unknown-unknown --lib compile PASS. Original TXT archived as 16 verified single-entry ZIPs; 18/18 committed Git blob identities checked; working tree clean. Banked at be997dc0dbd65fc370814c4a5f2d0f1254870572. No actual SCR/RCP file reads, Receipt content validation, timestamp generation, authority, promotion or publication; browser execution and independent implementation QA pending.",Day067,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-003,WASM-002 Receipts are TXT-only and independent of presentation state,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"For WASM-002, the canonical run Receipt is always plain TXT. Browser theme, built-in HTML presentation, Help voice, or other presentation state must not change whether the run Receipt is emitted as TXT or alter its governed facts. WASM-002 must not emit an HTML Receipt as an alternative to the canonical TXT Receipt. Configurable Brand Manifest behavior is deferred to a future build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-005,Canonical Receipt TXT serialization is deterministic,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The WASM-002 Receipt is UTF-8 without BOM and uses LF ( 0x0A ) line endings. Every Receipt ends with exactly one final LF. No serialized line carries trailing spaces, and no blank physical lines are emitted unless a later operation-specific grammar explicitly freezes them. It is a deterministic line-oriented KEY: VALUE document with a frozen core-key order followed by operation-specific fact sections in deterministic order. KEY is an uppercase ASCII field name. The separator is exactly one ASCII colon followed by exactly one ASCII space. KEY=VALUE is not valid canonical Receipt serialization. Fixed machine tokens and non-negative decimal integers are serialized unquoted. Human-authored text, filenames, aliases, headers, and other free text are serialized as double-quoted UTF-8 strings. Inside a quoted value, a literal double quote is represented by doubling it as """" . CR and LF are not permitted inside a single serialized value; each fact remains exactly one physical line. Enumerated values use the exact uppercase tokens frozen by the applicable requirement. Non-negative integers use ungrouped ASCII base-10 digits. This shared text rule is normative for all Receipt free-text values and is acceptance-tested byte-for-byte.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-016; CP-017; CP-018; CP-019,"CP016 T-accepted, Git-banked: pure field-line formatting; CP017 T-accepted, Git-banked: caller-ordered field sequence; CP018 T-accepted, Git-banked: exactly ten ordered mandatory core keys in a core-only in-memory fragment. Whole Receipt, runtime lineage truth, field-specific vocabularies, operation-specific sections, durable creation and publication NOT implemented. CP019 T-accepted, Git-banked: Receipt ten-core-field value category enforcement; rejects wrong integer/quoted/machine variant; no whole-document validation or truthful runtime semantics.",fde0f0a8b96c92f6cfb80b517396ff5512cccd13; 339cf12e747738d89442ce401feeea1afcd19dc6; 75620f17649a5d38d5357960bb99e9ac39ae354f; 8f7460ced343de4b8662e45b2b0b5b7b69127021,Evidence/CP-016/ZIP/CP016_RED_StdErr.txt.zip; Evidence/CP-016/ZIP/CP016_GREEN_Verification_StdOut.txt.zip; Evidence/CP-016/ZIP/CP016_PostFormat_Run_Record.txt.zip; Evidence/CP-016/ZIP/CP016_PostAmendment_Regression_StdOut.txt.zip; Evidence/CP-016/ZIP/CP016_WASM_Build_Run_Record.txt.zip; Evidence/CP-016/ZIP/CP016_PreFormat_Frozen_Test.rs.zip; Evidence/CP-016/ZIP/CP016_Final_Custody_Addendum_Record.txt.zip; CP016_Git_Postcommit_Integrity_Record.txt (external closeout); Evidence/CP-018/ZIP/CP018_PostFormat_Verification_Record.txt.zip; Evidence/CP-018/ZIP/CP018_PostFormat_Regression_StdOut.txt.zip; Evidence/CP-018/ZIP/CP018_WASM_Build_Run_Record.txt.zip; Evidence/CP-018/ZIP/CP018_Custody_Seal_Record.txt.zip; CP018_Git_Banking_Record.txt (external after-commit record); Evidence/CP-019/ZIP/CP019_RED_StdOut.txt.zip; Evidence/CP-019/ZIP/CP019_GREEN_StdOut.txt.zip; Evidence/CP-019/ZIP/CP019_Regression_StdOut.txt.zip; Evidence/CP-019/ZIP/CP019_Verification_Run_Record.txt.zip; Evidence/CP-019/ZIP/CP019_Source_Review.txt.zip; Evidence/CP-019/ZIP/CP019_Git_PreStaging_Review.txt.zip; CP019_Git_Banking_Record.txt (external postcommit); CP019_Git_Volume_Audit.txt (external postcommit),"CP016 Day068: T-approved and Git banked pure serialize_canonical_receipt_field_line(key, ReceiptFieldValue) and typed MachineToken, NonNegativeInteger(u64), QuotedText values. Exactly one KEY: VALUE\n line; uppercase ASCII lexical keys and machine tokens; ungrouped decimal u64; doubled interior quote; quoted UTF-8; CR/LF rejected within values. Eight frozen tests passed, 78/78 complete native regression, rustfmt check exit 0 after separately authorized formatting-only frozen-test amendment, wasm32-unknown-unknown --lib build exit 0. 36 individually verified evidence ZIPs Git banked; 31 original TXT evidence retained untracked. No whole-Receipt assembly, full document BOM/end-of-document acceptance, operation-specific core-key ordering, semantic token vocabulary, filesystem I/O, run invocation, authority, or publication. Independent adversarial implementation QA remains NOT_REVIEWED; no complete requirement acceptance. CP017 Day073: seven additional sequence tests, 85/85 full native regression, rustfmt correction preserved, wasm32 library build PASS, commit 339cf12e747738d89442ce401feeea1afcd19dc6. CP018 Day074: enforces the ordered ten-key common core through serialize_canonical_receipt_core_envelope by delegating to CP017; rejects missing, duplicate, reordered, mistyped key names and invalid lexical value, but does not validate field-specific semantics or full receipt. Intentional RED exit 101; nine GREEN tests; formatting-only correction recorded; 94/94 native regression, rustfmt PASS, WASM --lib build PASS; 30 individually checked evidence ZIPs, 32 committed paths, clean index/working tracked files; T-approved; commit 75620f17649a5d38d5357960bb99e9ac39ae354f. No independent implementation QA or browser execution. CP019 Day074: user human-accepted pure Receipt core-field category gate after test-first RED (4 expected failures / 2 existing passes); GREEN 6/6; full native 100/100 PASS across 19 suites; Rustfmt PASS; wasm32 library compile PASS. Exactly 20 independently checked evidence ZIPs plus Rust source and new test Git-banked, commit 8f7460ced343de4b8662e45b2b0b5b7b69127021. Two staging script errors (post-inventory allowlist and .NET relative path resolution) were surfaced and repaired before staging, no Rust source/test change. Does not validate RECEIPT_VERSION==1, RESULT vocabulary, UTC values, WKO lineage, diagnostics, whole Receipt, durable writing or publication; Claude independent QA and browser runtime NOT performed.",Day074,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-006,Every Receipt records the fixed core execution facts and exact WKO lineage,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"Every canonical WASM-002 Receipt begins with the following common envelope keys in exactly this order: RECEIPT_VERSION RECEIPT_FILENAME RECEIPT_UTC WORK_ORDER_FILENAME OPERATION RUN_STARTED_UTC RUN_FINISHED_UTC RESULT DIAGNOSTIC_ID IDENTITY_COLLISION_RETRIES Day 060 H-02 version freeze: RECEIPT_VERSION is the unquoted integer 1 for the WASM-002 Receipt contract. RECEIPT_FILENAME is the exact physical governed RCP filename. RECEIPT_UTC is exactly the canonical UTC timestamp embedded in that filename and is distinct from the run start/finish timestamps. WORK_ORDER_FILENAME is the exact physical immutable WKO identity invoked and is the authoritative WKO→RCP lineage link. Day 060 H-09 / BM-06 truthful run-timestamp semantics RUN_STARTED_UTC and RUN_FINISHED_UTC are governed truthful host-UTC observations at millisecond precision. They are not decorative labels and are not synthesized from artifact filenames. RUN_STARTED_UTC is observed only after the exact saved WKO has been resolved and found eligible to Run, and immediately before operation-specific validation/execution begins. It therefore brackets operation validation, analytical work, publication attempts, refusal processing, and any governed rollback/cleanup performed by that Run. RUN_FINISHED_UTC is observed only after the operation has reached its final SUCCESS or REFUSED analytical outcome and all non-Receipt governed effects are settled: successful artifacts are committed, refusal state is established, and required rollback/cleanup or retained non-authoritative evidence classification is complete. Receipt publication begins only after this observation. For one Run, the truthful temporal invariant is: WKO_UTC ≤ RUN_STARTED_UTC ≤ each successfully published run-artifact UTC ≤ RUN_FINISHED_UTC ≤ RECEIPT_UTC where WKO_UTC is the governed UTC token embedded in the exact WORK_ORDER_FILENAME , and “run-artifact UTC” means the governed UTC embedded in each non-Receipt artifact successfully published by that Run, including a shared materialization transaction UTC where applicable. An operation that publishes no non-Receipt artifact simply has no middle artifact-UTC comparison. Equality is permitted because the canonical timestamp precision is milliseconds. Data Sculptor must not fabricate, increment, decrement, or reorder UTC values merely to make this invariant appear true. Receipt fixtures and retained acceptance evidence must use physically possible timelines under this rule. The existing rule that WKO and Receipt filename timestamps are not required to match remains unchanged: they are distinct events, but a WKO invoked by a Run must already exist as a governed artifact before that Run begins. RESULT is a closed WASM-002 vocabulary containing exactly SUCCESS and REFUSED . No other RESULT token is valid. DIAGNOSTIC_ID: NONE is used for an ordinary successful run; a refused run carries the exact governed diagnostic identity. The shared governed absence-state vocabulary is closed to these four tokens, with these exact meanings: NONE — the fact is applicable and definitively has no value in this event; NOT_RUN — the owning stage or operation was not executed; NOT_AVAILABLE — the fact is applicable or potentially applicable, but its value could not be obtained; NOT_APPLICABLE — the fact does not apply to this event, diagnostic, operation, or artifact. These states are semantically distinct and must not be substituted for one another. A count that was actually established as zero is serialized as the integer 0 , never as an absence token. The refusal-serialization matrix for every present operation-specific key is deterministic: State of the key's owning fact/stage at refusal Required serialization The fact was authoritatively established before refusal Serialize the exact governed value. The owning stage was never entered NOT_RUN . The owning stage ran and definitively produced no value/artifact for this event NONE . The fact applies but could not be obtained NOT_AVAILABLE . The fact does not apply to this event NOT_APPLICABLE . An applicable count was authoritatively established as zero 0 . A publication identity whose publication stage was never entered NOT_RUN , except where an earlier frozen operation-specific rule explicitly fixes another token. A publication identity whose publication stage was entered but no artifact of that identity successfully published NONE . A publication identity that successfully published The exact physical governed filename. For this contract, a fact is established only when its owning validation/stage has deterministically fixed the value and later execution cannot revise that fact. Candidate allocation, partial bytes, or an uncommitted publication does not establish a published-artifact identity. If parsing/validation refuses before one of the seven governed WASM-002 operations can be identified, the Receipt uses OPERATION: UNKNOWN_OPERATION , RESULT: REFUSED , and the applicable DIAGNOSTIC_ID . After the common envelope there is no operation-specific section; the Receipt proceeds directly to CREATED_ARTIFACT_COUNT: 0 . UNKNOWN_OPERATION is not an executable operation. After all operation-specific facts and indexed lists, every Receipt ends with: CREATED_ARTIFACT_COUNT: <N>
CREATED_ARTIFACT_001: ""...""
...
CREATED_ARTIFACT_N: ""..."" The created-artifact list contains only exact physical governed filenames successfully published by the run, excluding the Receipt itself. For this accounting, an artifact is successfully published only if it remains a committed governed artifact when the Run finishes; an artifact promoted and then rolled back, or left only as non-authoritative failure residue under All-or-Refuse, is excluded from CREATED_ARTIFACT_COUNT and its indexed list. Indexed suffixes are one-based decimal with a minimum width of three digits and no maximum width: 001 through 999 are zero-padded and 1000 onward uses the ordinary full ungrouped decimal form. When a count is zero, no indexed lines for that list appear. IDENTITY_COLLISION_RETRIES is always present and is 0 when no governed filename-allocation retry occurred. Receipt/WKO filename timestamps are not required to match. One immutable WKO may be run multiple times, each producing a distinct Receipt that points back to the same exact WORK_ORDER_FILENAME . F-08 DS-STEPS / Receipt token separation. Human-authored Work Orders use the readable terminal clauses below; the Receipt serializes the corresponding machine token in OPERATION . The two columns are not interchangeable spellings: DS-STEPS terminal clause Receipt OPERATION MATERIALIZE MATERIALIZE INVENTORY INVENTORY UPDATE ALIASES UPDATE_ALIASES REPAIR MAP REPAIR_MAP REPAIR WORK ORDER REGISTRY REPAIR_WORK_ORDER_REGISTRY CONVERT WINDOWS-1252 TO UTF-8 CONVERT_WINDOWS_1252_TO_UTF_8 CATALOG STORES CATALOG_STORES For example, REPAIR_MAP is not valid DS-STEPS syntax and REPAIR MAP is not the serialized Receipt token. UNKNOWN_OPERATION remains a refusal-only Receipt value when validation cannot identify one of these seven operations; it is not an executable operation.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-018; CP-019,"CP018 T-accepted and Git-banked: exact mandatory ten-core-key count and order in an in-memory formatting fragment only; no verified WKO lineage semantics or real execution facts. CP019 T-accepted, Git-banked: Receipt ten-core-field value category enforcement; rejects wrong integer/quoted/machine variant; no whole-document validation or truthful runtime semantics.",75620f17649a5d38d5357960bb99e9ac39ae354f; 8f7460ced343de4b8662e45b2b0b5b7b69127021,Evidence/CP-018/ZIP/CP018_RED_StdErr.txt.zip; Evidence/CP-018/ZIP/CP018_GREEN_StdOut.txt.zip; Evidence/CP-018/ZIP/CP018_PostFormat_Regression_StdOut.txt.zip; Evidence/CP-018/ZIP/CP018_WASM_Build_Run_Record.txt.zip; Evidence/CP-018/ZIP/CP018_Custody_Seal_Record.txt.zip; CP018_Git_Banking_Record.txt (external after-commit record); Evidence/CP-019/ZIP/CP019_RED_StdOut.txt.zip; Evidence/CP-019/ZIP/CP019_GREEN_StdOut.txt.zip; Evidence/CP-019/ZIP/CP019_Regression_StdOut.txt.zip; Evidence/CP-019/ZIP/CP019_Verification_Run_Record.txt.zip; Evidence/CP-019/ZIP/CP019_Source_Review.txt.zip; Evidence/CP-019/ZIP/CP019_Git_PreStaging_Review.txt.zip; CP019_Git_Banking_Record.txt (external postcommit); CP019_Git_Volume_Audit.txt (external postcommit),"CP018 Day074: T-approved and locally Git-banked pure serialize_canonical_receipt_core_envelope enforces exactly the ten frozen header keys in order, calls existing CP017/CP016 serializer, refuses invalid count/order/value; nine targeted tests and 94/94 full native test regression pass, Rustfmt and WASM library compile pass. Does NOT prove correct data lineage, actual timestamps or vocabularies, operation-specific facts, durable writing or publication; independent Claude review and browser runtime not performed. CP019 Day074: user human-accepted pure Receipt core-field category gate after test-first RED (4 expected failures / 2 existing passes); GREEN 6/6; full native 100/100 PASS across 19 suites; Rustfmt PASS; wasm32 library compile PASS. Exactly 20 independently checked evidence ZIPs plus Rust source and new test Git-banked, commit 8f7460ced343de4b8662e45b2b0b5b7b69127021. Two staging script errors (post-inventory allowlist and .NET relative path resolution) were surfaced and repaired before staging, no Rust source/test change. Does not validate RECEIPT_VERSION==1, RESULT vocabulary, UTC values, WKO lineage, diagnostics, whole Receipt, durable writing or publication; Claude independent QA and browser runtime NOT performed.",Day074,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-007,"Materialization Receipts record Store, RID, Stage 1, Stage 2, and output facts",W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"For a WASM-002 MATERIALIZE run, after the common envelope the Receipt serializes these operation-specific keys in exactly this order: SOURCE_FILENAME BASE_MAP_FILENAME RID_FILENAME RID_ACTION STAGE1_UTF8_OUTCOME CERTIFIED_SOURCE_BYTE_COUNT STAGE1_ELAPSED_MS UTF8_FIRST_INVALID_BYTE_OFFSET UTF8_STOP_REASON WINDOWS_1252_COMPATIBILITY_OUTCOME WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET STAGE2_LOGICAL_ROW_COUNT STAGE2_ELAPSED_MS CSV_REFUSAL_CONDITION CSV_SOURCE_BYTE_OFFSET CSV_PHYSICAL_LINE CSV_LOGICAL_RECORD CSV_FIELD_ORDINAL REQUESTED_COLUMN_COUNT RESOLVED_COLUMN_COUNT PUBLISHED_COL_COUNT zero or more indexed published-COL filename lines whose exact key form is PUBLISHED_COL_<INDEX>_FILENAME (for example PUBLISHED_COL_001_FILENAME , PUBLISHED_COL_002_FILENAME ) SUCCESSOR_MAP_FILENAME OPERATIONAL_NAME_FALLBACK_COUNT zero or more indexed fallback triplets: OPERATIONAL_NAME_FALLBACK_001_COLUMN_ORDINAL , OPERATIONAL_NAME_FALLBACK_001_ASSIGNED_NAME , OPERATIONAL_NAME_FALLBACK_001_REASON , continuing under the common indexed-key rule. BASE_MAP_FILENAME: NONE denotes a newly established Store with no predecessor Store MAP. Day 060 H-11 / BM-08 RID_ACTION ownership and establishment RID_ACTION is a governed execution fact describing what this Run actually established for the Store RID path. It is never an intention, plan, or prediction. RID_ACTION: REUSED is established when routing has selected an existing Store, the exact inherited RID filename is known, and that inherited RID has passed the validation required to proceed. Because the RID already exists, this fact may be established before Stage 1 or Stage 2 completes. RID_ACTION: CREATED is established only when a new-Store RID candidate has successfully completed governed promotion into its final RID identity. Merely planning, allocating, writing, closing, validating, or naming an SCR candidate does not establish CREATED . Until either of those facts is established, the common refusal matrix governs RID_ACTION . For a new-Store path that refuses before successful RID promotion, RID_ACTION is NOT_RUN . If an existing-Store route is identified but the required inherited RID fact cannot be validly established, RID_ACTION is NOT_AVAILABLE . RID_FILENAME is a separate fact: for REUSED , it is the exact already-published inherited RID filename as soon as reuse is established; for CREATED , it is the exact governed final RID filename only after successful RID promotion; before new-RID promotion succeeds, no candidate/SCR filename may be serialized as though it were a published RID. With RID_ACTION: CREATED , RID_FILENAME records the RID identity successfully promoted during the Run even if that RID is later rolled back under All-or-Refuse; rollback does not erase the already-established RID_ACTION / RID_FILENAME execution facts. The refusal-boundary matrix is therefore: Materialization state RID_ACTION RID_FILENAME Validation/routing refuses before a Store/RID path is established NOT_RUN NOT_RUN or NOT_AVAILABLE only when an applicable routing fact could not be obtained under the common matrix New Store; Stage 1 refusal NOT_RUN NOT_RUN New Store; Stage 2 refusal NOT_RUN NOT_RUN New Store; post-Stage-2 gate refusal before RID promotion NOT_RUN NOT_RUN New Store; RID candidate/promotion has not successfully completed NOT_RUN NOT_RUN New Store; RID promotion succeeds CREATED exact published RID filename Existing Store; exact inherited RID selected and validated REUSED exact inherited RID filename Existing Store; later Stage 1, Stage 2, gate, or publication refusal after reuse was established REUSED exact inherited RID filename Existing lineage identified but required inherited RID cannot be validly established NOT_AVAILABLE NOT_AVAILABLE A refusal Receipt that says RID_ACTION: CREATED while RID_FILENAME is NONE or NOT_RUN and no RID was successfully promoted is invalid evidence. STAGE1_UTF8_OUTCOME has exactly two completed Stage-1 values: PASS and FAIL . If Stage 1 never ran, the value is NOT_RUN . If Stage 1 began but a separate failure prevented a governed PASS/FAIL determination, the value is NOT_AVAILABLE . NOT_APPLICABLE is not valid for this key. UTF8_FIRST_INVALID_BYTE_OFFSET and UTF8_STOP_REASON are refusal-only Stage-1 evidence. On STAGE1_UTF8_OUTCOME: FAIL , the offset is mandatory and is the exact zero-based absolute physical source-byte offset of the first byte of the invalid sequence, and the stop reason is mandatory and exactly INVALID_UTF8_SEQUENCE . Neither field may be NOT_AVAILABLE when the Stage-1 outcome is FAIL . On PASS , both fields are NOT_APPLICABLE . If Stage 1 never ran, both are NOT_RUN . If Stage 1 began but no UTF-8 PASS/FAIL conclusion was established because of a separate failure, both refusal-only fields are NOT_APPLICABLE . WINDOWS_1252_COMPATIBILITY_OUTCOME and WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET are the governed F-16 follow-on facts. They are evaluated only after STAGE1_UTF8_OUTCOME: FAIL . When the complete second pass reaches EOF with every byte mappable, the outcome is COMPATIBLE and the offset is NOT_APPLICABLE . When the pass encounters one of the undefined bytes frozen in W002-CONV-002.4, the outcome is INCOMPATIBLE and the offset is the exact zero-based absolute physical source-byte offset of the first such byte. If the pass begins but an independent failure prevents a conclusion, both fields are NOT_AVAILABLE . If Stage 1 did not conclude FAIL , the compatibility pass does not run and both fields are NOT_RUN . The five exact CSV refusal keys CSV_REFUSAL_CONDITION , CSV_SOURCE_BYTE_OFFSET , CSV_PHYSICAL_LINE , CSV_LOGICAL_RECORD , and CSV_FIELD_ORDINAL carry the exact structural CSV refusal condition and location oracle frozen in W002-MAT-002.8. If Stage 2 never ran, all five are NOT_RUN ; if Stage 2 completed without an applicable CSV refusal, all five are NOT_APPLICABLE ; on a CSV refusal, each established location fact is serialized and any applicable fact that could not be obtained is NOT_AVAILABLE . The MATERIALIZE refusal-stage matrix is: Refusal boundary Validation/routing and request facts Stage 1 facts Stage 2 facts Publication facts Validation, before Stage 1 Serialize each fact already established; an applicable fact that validation could not obtain is NOT_AVAILABLE . REQUESTED_COLUMN_COUNT is the actual count when the KEEP list parsed completely; otherwise NOT_AVAILABLE . RESOLVED_COLUMN_COUNT and fallback records are NOT_RUN until name/ordinal resolution has run. NOT_RUN for all Stage 1-owned facts. NOT_RUN for all Stage 2-owned facts. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Stage 1 refusal Established validation/routing facts are exact values. Serialize the exact Stage 1 outcome/timing and established refusal evidence; incomplete applicable facts are NOT_AVAILABLE . The Windows-1252 compatibility fields then serialize the exact complete assessment result under the rule above; if an independent assessment failure prevents a conclusion, they are NOT_AVAILABLE . NOT_RUN for all Stage 2-owned facts. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Stage 2 refusal Established validation/routing facts are exact values. Completed Stage 1 facts are exact values; UTF-8 refusal fields are NOT_APPLICABLE when no UTF-8 refusal occurred. Because Stage 1 passed, both Windows-1252 compatibility fields are NOT_RUN . STAGE2_ELAPSED_MS is the actual elapsed time when obtained; STAGE2_LOGICAL_ROW_COUNT is NOT_AVAILABLE unless the complete accepted logical row count was established; CSV refusal facts follow the rule above. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Post-Stage-2 gate refusal before publication All facts established through the gate are serialized exactly; non-applicable UTF-8/CSV refusal fields are NOT_APPLICABLE . Both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Publication refusal before the successor-MAP publication stage is entered All facts established before refusal are serialized exactly. This row includes a new-Store RID/COL identity-allocation or promotion refusal that occurs before the successor-MAP publication stage is entered. Completed Stage 1 and Stage 2 facts remain exact; non-applicable UTF-8/CSV refusal fields use their governed absence tokens, and both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. Under All-or-Refuse publication, PUBLISHED_COL_COUNT: 0 and no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN because the successor-MAP publication stage was never entered. A candidate filename is never serialized as a published identity. Publication refusal after the successor-MAP publication stage is entered All facts established before refusal are serialized exactly. Any RID fact already established before this later refusal remains governed by the RID_ACTION/RID_FILENAME matrix above. Completed Stage 1 and Stage 2 facts remain exact; non-applicable UTF-8/CSV refusal fields use their governed absence tokens, and both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. Under All-or-Refuse publication, PUBLISHED_COL_COUNT: 0 and no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NONE because the successor-MAP publication stage was entered but no successor MAP successfully published. A candidate filename is never serialized as a published identity. Success All applicable facts are exact values; refusal-only UTF-8/CSV fields are NOT_APPLICABLE . Both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. PUBLISHED_COL_COUNT is the actual count; indexed keys are exactly PUBLISHED_COL_001_FILENAME onward in resolved KEEP order; SUCCESSOR_MAP_FILENAME is the exact published successor MAP filename. Day 060 H-24 / BM-08 publication-boundary split: these two MATERIALIZE publication-refusal rows apply the common W002-RCP-006 ownership rule to the successor-MAP publication stage. NOT_RUN means that stage was never entered; NONE means it was entered but no successor MAP successfully published. The early boundary is exercised by the RID identity-allocation exhaustion fixture; the later boundary has its own byte-exact golden fixture. OPERATIONAL_NAME_FALLBACK_COUNT is NOT_RUN until operational-name resolution has run; afterward it is the established non-negative count, including literal 0 . Fallback records are ordered by ascending physical source-column ordinal. the exact fallback key OPERATIONAL_NAME_FALLBACK_<INDEX>_REASON is exactly SOURCE_HEADER_EXCEEDS_1024_SCALARS . For successful Store-establishing materialization, the common created-artifact list is ordered RID first, newly published COLs in resolved KEEP order, then successor MAP. For successful existing-Store materialization, the inherited RID is not newly created; the list contains newly published COLs in resolved KEEP order followed by the successor MAP. P3-09 Receipt oracle: when Stage 2 refuses because the certified source contains no logical CSV record, the five CSV refusal fields must serialize exactly as CSV_REFUSAL_CONDITION: NO_HEADER_RECORD , CSV_SOURCE_BYTE_OFFSET: <exact source byte length> , CSV_PHYSICAL_LINE: 1 , CSV_LOGICAL_RECORD: 1 , and CSV_FIELD_ORDINAL: 1 . Day 060 H-13 / BM-10 clarification: within those five governed CSV refusal fields, the zero-byte and UTF-8-BOM-only cases differ only in CSV_SOURCE_BYTE_OFFSET : 0 versus 3 . Their complete Receipt bytes also differ wherever the underlying source identity, certified source byte count, Work Order identity, run/Receipt timestamps, Receipt filename/UUID, or other fixture-specific governed facts differ. The complete Receipts must never be described as differing only by one field. F-20 operational-name Receipt oracle: OPERATIONAL_NAME_FALLBACK_COUNT counts selected/materialized columns whose exact source header exceeded 1,024 Unicode scalar values. Each corresponding ..._ASSIGNED_NAME stores the final deterministic operational/default-alias name after any permitted fallback collision disambiguation; ..._REASON remains exactly SOURCE_HEADER_EXCEEDS_1024_SCALARS . The Receipt does not copy the oversized exact source header merely to explain the fallback. The common indexed-key rule from W002-RCP-006 applies without a maximum width. A full-width KEEP is therefore representable through PUBLISHED_COL_16384_FILENAME (and corresponding fallback indexes when applicable); the three-digit examples are a minimum-width convention, not a 999-item ceiling.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-008,Other WASM-002 operations add deterministic operation-specific Receipt facts,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The same common envelope, closed RESULT/absence vocabulary, refusal matrix, created-artifact tail, and indexed-key rule apply to the other executable WASM-002 operations. Their operation-specific key tables are closed as follows. INVENTORY INVENTORY_FILENAME INVENTORY_ENTRY_COUNT Refusal boundary INVENTORY_ENTRY_COUNT INVENTORY_FILENAME Validation before inventory scan NOT_RUN NOT_RUN Inventory scan/measurement refusal Exact count if the complete count was established; otherwise NOT_AVAILABLE NOT_RUN Publication refusal after the snapshot facts were established Exact established count, including 0 NONE Success Exact established count Exact physical published INV filename UPDATE_ALIASES BASE_MAP_FILENAME SUCCESSOR_MAP_FILENAME Refusal boundary BASE_MAP_FILENAME SUCCESSOR_MAP_FILENAME Validation/routing before an exact base MAP is established NOT_AVAILABLE NOT_RUN Validation/gate refusal after the exact base MAP is established Exact base MAP filename NOT_RUN Publication refusal Exact base MAP filename NONE Success Exact base MAP filename Exact published successor MAP filename REPAIR_MAP TARGET_MAP_FILENAME RID_FILENAME BROKEN_COL_COUNT zero or more indexed broken-COL filename lines using exact key form BROKEN_COL_<INDEX>_FILENAME (for example BROKEN_COL_001_FILENAME , BROKEN_COL_002_FILENAME ) RETAINED_COL_COUNT SUCCESSOR_MAP_FILENAME Broken COL filenames are ordered by ascending exact UTF-8 filename bytes. RETAINED_COL_COUNT is the actual count once repair analysis completes, including literal 0 . Refusal boundary Target/RID facts Broken/retained facts SUCCESSOR_MAP_FILENAME Validation before an exact target MAP/RID is established Established facts are exact; otherwise NOT_AVAILABLE NOT_RUN NOT_RUN Repair-analysis refusal before a repair result is established Exact established values Exact values if established; otherwise the applicable unavailable/not-run token from the common matrix NOT_RUN All-COLs-broken refusal frozen under F-03/F-09 Exact values Exact broken count/list; RETAINED_COL_COUNT: 0 NONE — this earlier frozen named refusal remains an explicit operation-specific exception. Publication refusal Exact values Exact repair-analysis values NONE Success Exact values Exact repair-analysis values Exact published successor MAP filename REPAIR_WORK_ORDER_REGISTRY BASE_WKO_MAP_FILENAME REMOVED_STALE_ROW_COUNT zero or more indexed stale-WKO filename lines using exact key form REMOVED_STALE_WKO_<INDEX>_FILENAME (for example REMOVED_STALE_WKO_001_FILENAME , REMOVED_STALE_WKO_002_FILENAME ) REGISTERED_CURRENT_COUNT zero or more indexed current-WKO filename lines using exact key form REGISTERED_CURRENT_WKO_<INDEX>_FILENAME (for example REGISTERED_CURRENT_WKO_001_FILENAME , REGISTERED_CURRENT_WKO_002_FILENAME ) REGISTERED_DEPRECATED_COUNT zero or more indexed deprecated-WKO filename lines using exact key form REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME (for example REGISTERED_DEPRECATED_WKO_001_FILENAME , REGISTERED_DEPRECATED_WKO_002_FILENAME ) SUCCESSOR_WKO_MAP_FILENAME Each filename list is independently sorted by ascending exact UTF-8 filename bytes. If the bootstrap repair WKO is newly discovered and registered, it appears in the appropriate registered list under W002-STOR-018.3 and W002-STOR-018.4. Day 060 H-10 / BM-07 count semantics: REGISTERED_CURRENT_COUNT and REGISTERED_DEPRECATED_COUNT count only previously unregistered structurally valid WKOs that this repair Run newly adds to the successor WKO MAP with the stated status. They do not count surviving pre-existing rows already present in the base registry. The indexed filename lines list exactly the corresponding newly registered WKOs and no others. If the bootstrap repair WKO is one of those newly registered WKOs, it must appear in exactly one registered list. A successful repair Receipt that omits a newly registered bootstrap repair WKO is invalid evidence. Refusal boundary Base registry Repair-plan counts/lists SUCCESSOR_WKO_MAP_FILENAME Validation before the current structurally valid WKO MAP is established NOT_AVAILABLE NOT_RUN NOT_RUN Repair-analysis/gate refusal Exact base WKO MAP filename Exact values if the repair plan was established; otherwise the common matrix governs each present field NOT_RUN Publication refusal Exact base WKO MAP filename Exact established repair-plan values NONE Success Exact base WKO MAP filename Exact established repair-plan values Exact published successor WKO MAP filename CONVERT_WINDOWS_1252_TO_UTF_8 SOURCE_FILENAME SOURCE_ENCODING UNDEFINED_WINDOWS_1252_BYTE_OFFSET MATERIALIZED_ENCODING TRANSCODING SOURCE_CHANGED OUTPUT_FILENAME UNDEFINED_WINDOWS_1252_BYTE_OFFSET is the zero-based absolute physical source-byte offset of the first byte undefined by the frozen Windows-1252 mapping when that refusal occurs. If the compatibility stage never ran it is NOT_RUN ; if the stage ran and no undefined-byte refusal occurred it is NOT_APPLICABLE ; if the fact applies but could not be obtained it is NOT_AVAILABLE . Day 060 H-14 / BM-11 undefined-Windows-1252-byte refusal oracle For CONVERT WINDOWS-1252 TO UTF-8 , an undefined Windows-1252 byte is detected during the complete pre-transcoding compatibility assessment . Transcoding has not begun when this refusal is established. When the complete compatibility assessment encounters the first undefined byte, the Receipt must serialize these exact operation facts: SOURCE_ENCODING: WINDOWS-1252-INCOMPATIBLE
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: <exact zero-based absolute physical source-byte offset>
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE WINDOWS-1252-INCOMPATIBLE is the exact SOURCE_ENCODING token for this governed CONVERT refusal. OUTPUT_FILENAME: NONE means the operation definitively established that no CVT was published for the event. No CVT candidate may be reported as output. The compatibility scan reports the first undefined byte only. Later undefined bytes do not replace that offset. Permitted changes in scan buffer/window size or boundary placement must not change the reported absolute offset. Day 060 H-25 / BM-04 already-valid-UTF-8 refusal oracle. If the complete bound source passes strict UTF-8 validation, CONVERT refuses as unnecessary before Windows-1252 compatibility assessment or transcoding. The Receipt must serialize these exact operation facts: SOURCE_ENCODING: UTF-8
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: NOT_RUN
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE UTF-8 is the exact SOURCE_ENCODING token for this governed refusal. OUTPUT_FILENAME: NONE means the classification gate definitively established that this event publishes no CVT. The Windows-1252 compatibility stage is not entered. Refusal boundary Source/classification facts Conversion facts OUTPUT_FILENAME Validation/classification refusal before conversion begins Serialize each fact already established; an applicable fact that could not be obtained is NOT_AVAILABLE . The undefined-byte offset follows the rule above. MATERIALIZED_ENCODING and TRANSCODING are NOT_RUN when conversion did not run. SOURCE_CHANGED is the exact governed value once established. NONE only for either of the two definitively classified no-CVT cases: (1) the complete source is already valid strict UTF-8 and conversion is unnecessary; or (2) the complete Windows-1252 compatibility assessment finds an undefined byte. For other validation/classification refusals before conversion begins, OUTPUT_FILENAME: NOT_RUN unless another normative rule explicitly assigns a different closed token. Conversion/refusal after bounded transcoding begins but before publication Exact established source/classification facts Serialize exact established conversion facts; applicable incomplete facts use NOT_AVAILABLE . NOT_RUN Publication refusal Exact established facts Exact established conversion facts NONE Success SOURCE_ENCODING: WINDOWS-1252-COMPATIBLE ; undefined-byte offset NOT_APPLICABLE MATERIALIZED_ENCODING: UTF-8 ; TRANSCODING: BOUNDED_STREAMING ; SOURCE_CHANGED: NO Exact published CVT filename CATALOG_STORES CATALOG_ENTRY_COUNT CATALOG_FILENAME Refusal boundary CATALOG_ENTRY_COUNT CATALOG_FILENAME Validation/discovery refusal before the complete authoritative catalog row set is established NOT_AVAILABLE NOT_RUN Publication refusal after the complete catalog row set is established Exact established count, including 0 NONE Success Exact established count Exact physical published CAT filename On success, CATALOG_ENTRY_COUNT equals the number of data rows in the published CAT. CAT itself is the only new non-Receipt governed artifact produced by the operation. RECOVER RID / RECOVER_RID is not a valid executable WASM-002 operation in Revision BM.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-009,"Receipt truth is execution evidence, not presentation authority",W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The Receipt records what Data Sculptor actually attempted, observed, refused, and successfully published. It must not reinterpret the analyst's WKO, replace the Store MAP, or become a second analytical command surface. The WKO remains the durable authorization record; Store MAP/RID/COL artifacts remain the governed analytical state; diagnostic events remain the refusal/help truth; the Receipt cross-references those facts as the durable run ledger. The body of published canonical RCP artifacts is the authoritative evidence substrate for the Flight Recorder logical view defined in W002-STOR-012.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-010,Receipt-publication failure is itself a governed evidence failure,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"Data Sculptor must never claim that a durable Receipt exists until the RCP file has been successfully written and closed in the Suitcase. If host or filesystem failure prevents Receipt publication, the browser must surface a canonical diagnostic through the Help Engine stating that receipt evidence could not be persisted. A receipt-publication failure does not retroactively falsify analytical artifacts that were already successfully committed under their own publication contracts, but the user-facing run summary must clearly distinguish analytical outcome from receipt-persistence failure. Data Sculptor must not invent, backdate, or silently reconstruct a Receipt and present it as the original run artifact. F-14 publication path, reconciled by F-33: the RCP itself is first written as the corresponding SCR candidate under W002-STOR-023.1, closed, reopened and validated against the exact Receipt serialization/key contract before the class-token rename to RCP . If final RCP promotion fails, the candidate remains non-authoritative SCR evidence. Help may identify the exact retained SCR filename when that fact was established, but it must still state that the canonical Receipt was not persisted. WASM-002 does not emit an RCV artifact for this failure.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-001,Successful materialization Receipt and WKO-lineage acceptance,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,"A Store-establishing materialization fixture must run one saved WKO, publish exactly one canonical TXT RCP, and prove that the Receipt identifies the exact WKO through WORK_ORDER_FILENAME , source, RID_ACTION: CREATED , new RID, Stage 1 result/bytes/time, Stage 2 row count/time, all requested COL artifacts in resolved KEEP order, successor Store MAP, published-artifact count, timestamps, and RESULT: SUCCESS . The RCP filename UTC must represent the Receipt artifact's own creation/publication event and must not be required to equal the WKO filename UTC. The same immutable WKO must then be executable again in an appropriate fixture, producing a second distinct RCP with its own Receipt/run timestamps while both Receipts contain the same exact WORK_ORDER_FILENAME . A later same-Store materialization fixture must additionally prove RID_ACTION: REUSED and the original RID filename. The Store-establishing fixture must also prove that the newly created RID, every newly created COL, and the successor MAP carry one identical publication-transaction UTC token while each has a distinct UUID; the RCP filename UTC remains its own Receipt publication timestamp and is not required to equal that analytical transaction UTC. A later same-Store materialization must prove that newly created COLs and its successor MAP share the later transaction UTC while the inherited RID retains its original timestamp/UUID. F-07 Stage-1 success fixture: a successful materialization Receipt must serialize STAGE1_UTF8_OUTCOME: PASS , with UTF8_FIRST_INVALID_BYTE_OFFSET: NOT_APPLICABLE and UTF8_STOP_REASON: NOT_APPLICABLE . Separate refusal fixtures under W002-RCP-ACC-002 must prove FAIL plus the mandatory exact offset and INVALID_UTF8_SEQUENCE . F-20 maximum-width Receipt acceptance: a successful full-width materialization fixture must prove that published-COL indexed keys continue through PUBLISHED_COL_16384_FILENAME using the minimum-three-digit/no-maximum suffix rule. Oversized-header fixtures must prove the exact fallback count, source ordinal, assigned operational name, and SOURCE_HEADER_EXCEEDS_1024_SCALARS reason without embedding the oversized source-header text in the Receipt merely as fallback evidence. F-23 additional successful-Receipt coverage: acceptance must include a successful INVENTORY run whose RCP carries the exact governed INVENTORY operation-specific facts and a successful UPDATE_ALIASES run whose RCP carries the exact BASE_MAP_FILENAME and SUCCESSOR_MAP_FILENAME while reporting only actually published artifacts in the common created-artifact tail. F-23 UUID-collision seam: using a controlled UUID sequence, acceptance must force one or more governed filename collisions before successful allocation. Every pre-existing colliding artifact must remain byte-for-byte unchanged; allocation must retain the originally established governed UTC context while changing only the not-yet-created UUID as permitted; and the published Receipt must report the exact retry count in IDENTITY_COLLISION_RETRIES . Day 060 H-09 success-timeline acceptance Every retained successful Receipt fixture must satisfy the W002-RCP-006 temporal invariant using its actual embedded UTC tokens. Acceptance must mechanically prove: the invoked WKO UTC is less than or equal to RUN_STARTED_UTC ; every non-Receipt governed artifact successfully published by that Run has a governed artifact/transaction UTC between RUN_STARTED_UTC and RUN_FINISHED_UTC , inclusive; RUN_FINISHED_UTC is less than or equal to the Receipt filename/ RECEIPT_UTC ; and no fixture relies on an artifact timestamp that occurs after the Receipt that claims it, or before the Run that created it. A controlled-clock acceptance seam may be used to make equality and strict-order cases deterministic, but the fixture generator must not alter timestamps after the fact merely to satisfy the checker. Day 060 H-11 successful RID_ACTION acceptance A successful new-Store materialization Receipt may report RID_ACTION: CREATED only because the RID was actually promoted into its final governed RID identity during that Run. A successful existing-Store materialization Receipt reports RID_ACTION: REUSED and the exact inherited RID filename; no new RID candidate is created for that Run.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-002,Refusal Receipt acceptance,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,"A saved WKO that is actually Run and deterministically refuses must still produce one canonical TXT Receipt when Receipt publication itself remains available. The emitted bytes must conform to the closed RESULT vocabulary, the four governed absence tokens, the exact operation-specific key spelling/order, and the refusal matrix in W002-RCP-006 through W002-RCP-008. Acceptance must include byte-exact golden Receipt fixtures for every distinct refusal-boundary row required to exercise the serialization matrix for each of the seven executable WASM-002 operations: MATERIALIZE , INVENTORY , UPDATE_ALIASES , REPAIR_MAP , REPAIR_WORK_ORDER_REGISTRY , CONVERT_WINDOWS_1252_TO_UTF_8 , and CATALOG_STORES . Multiple Diagnostic IDs that map to the same refusal boundary and the same serialization row do not require duplicate byte fixtures merely because the Diagnostic ID differs. Acceptance must additionally include one byte-exact UNKNOWN_OPERATION refusal fixture proving the common envelope, OPERATION: UNKNOWN_OPERATION , RESULT: REFUSED , the exact diagnostic ID, absence of any operation-specific section, and immediate CREATED_ARTIFACT_COUNT: 0 . Fixtures must prove that NONE , NOT_RUN , NOT_AVAILABLE , and NOT_APPLICABLE retain distinct meanings; an established zero count is serialized as 0 ; no candidate filename is reported as a published identity; and every indexed key uses its complete frozen name and the minimum-three-digit/no-maximum suffix rule. An unsaved WIP must be proven unable to Run and therefore must not create an execution Receipt. F-16 materialization-refusal fixtures: byte-exact MATERIALIZE refusal Receipts must exercise the new compatibility pair in all four applicable states: NOT_RUN when Stage 1 did not fail; COMPATIBLE plus NOT_APPLICABLE offset; INCOMPATIBLE plus the exact first undefined-byte offset; and NOT_AVAILABLE / NOT_AVAILABLE when an independent compatibility-read failure prevents a conclusion. F-23 Receipt-publication failure fixture, reconciled by F-33: a controlled filesystem-fault seam must make canonical RCP publication fail after the underlying analytical/refusal outcome has been established. Acceptance must prove the W002-RCP-010 boundary exactly: no final RCP is fabricated or claimed, any retained candidate evidence follows the governed SCR retention/non-authority rules in W002-STOR-023.1, no RCV artifact is emitted, the user-facing diagnostic distinguishes analytical outcome from Receipt-persistence failure, and already committed analytical artifacts are not retroactively falsified solely because RCP persistence failed. F-23 ultimate identity-allocation failure fixture: with Receipt publication itself still available, a controlled identity-allocation seam must force a governed operation artifact to exhaust/fail safe allocation. The operation must refuse without overwriting or mutating any colliding pre-existing artifact, and the refusal Receipt/diagnostic evidence must preserve the established collision/allocation-failure facts under PB-STOR-011 and W002-STOR-007.3. Day 060 H-02 fixture binding: the retained golden corpus must use RECEIPT_VERSION: 1 and the fixture-pinned diagnostic allocations in W002-HELP-001.8. The corpus must contain one success Receipt for each of the seven executable operations, one refusal Receipt for every distinct refusal-boundary row in W002-RCP-007/W002-RCP-008, the three additional Stage-1 compatibility variants needed to cover COMPATIBLE , INCOMPATIBLE , and NOT_AVAILABLE after UTF-8 failure, and one UNKNOWN_OPERATION Receipt. Publication-refusal fixtures may use the operation-specific H-02 publication diagnostic and a non-zero IDENTITY_COLLISION_RETRIES value to satisfy the ultimate identity-allocation-failure acceptance boundary without inventing a second diagnostic solely for the same serialization row. Day 060 H-09 refusal-timeline acceptance Every retained refusal Receipt fixture must also satisfy the W002-RCP-006 temporal invariant. For a refusal with no successfully published non-Receipt artifact, acceptance proves WKO_UTC ≤ RUN_STARTED_UTC ≤ RUN_FINISHED_UTC ≤ RECEIPT_UTC . If a refusal legitimately leaves one or more successfully committed non-Receipt artifacts from an already-completed stage, each such artifact UTC must fall between Run start and Run finish and must be listed truthfully under the governing created-artifact rules. Day 060 H-11 / BM-08 RID_ACTION refusal acceptance Byte-exact MATERIALIZE refusal acceptance must distinguish new-Store and existing-Store RID paths: new-Store validation, Stage 1, Stage 2, and post-Stage-2 gate refusals before successful RID promotion serialize RID_ACTION: NOT_RUN and do not serialize a candidate as a published RID; a controlled new-Store refusal after RID promotion has successfully completed may serialize RID_ACTION: CREATED together with the exact published RID filename, but only if that RID was actually promoted and the remaining refusal/rollback evidence is truthful under the publication rules; an existing-Store refusal after the inherited RID has been selected and validated serializes RID_ACTION: REUSED and the exact inherited RID filename even when Stage 1, Stage 2, a later gate, or publication subsequently refuses; an existing lineage whose required inherited RID cannot be validly established serializes RID_ACTION: NOT_AVAILABLE and RID_FILENAME: NOT_AVAILABLE rather than claiming reuse. Acceptance must specifically reject the historical H-02 fixture pattern that reported RID_ACTION: CREATED while no RID existed and CREATED_ARTIFACT_COUNT: 0 . Day 060 H-12 H-02 publication-diagnostic scope The H-02 operation-specific publication diagnostics whose required facts are artifact_class and collision_retry_count are acceptance pins for governed filename identity-allocation collision exhaustion. They are not catch-all Diagnostic IDs for unrelated publication failures such as chronology guards, write/close/rename failures, or malformed predecessor state. Those distinct conditions use their own registry allocations; DS-UTC-001 is independently frozen for the strict monotonic-UTC guard. Day 060 H-13 / BM-10 zero-byte and BOM-only NO_HEADER_RECORD Receipt fixtures The retained golden corpus must contain two distinct byte-exact MATERIALIZE refusal Receipts for the P3-09 no-header boundary: Zero-byte source: the bound source has exact certified byte count 0 ; Stage 1 passes; Stage 2 refuses with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD ; CSV_SOURCE_BYTE_OFFSET: 0 ; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; and CSV_FIELD_ORDINAL: 1 . UTF-8-BOM-only source: the bound source consists exactly of bytes EF BB BF and has exact certified byte count 3 ; Stage 1 passes; Stage 2 refuses with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD ; CSV_SOURCE_BYTE_OFFSET: 3 ; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; and CSV_FIELD_ORDINAL: 1 . These two Receipt fixtures must carry their own truthful source filenames, Work Order identities, run timestamps, Receipt identities, and other governed facts. Only the five-field CSV refusal tuple has the narrower relationship stated in W002-RCP-007; the complete Receipt files are not otherwise required to be byte-identical. Day 060 H-14 / BM-11 CONVERT undefined-byte Receipt binding The coordinated golden Receipt corpus must include the byte-exact CONVERT_WINDOWS_1252_TO_UTF_8 refusal fixture from W002-CONV-ACC-002 using source bytes 41 81 42 . Its Receipt must carry UNDEFINED_WINDOWS_1252_BYTE_OFFSET: 1 and the exact pre-transcoding refusal values frozen in W002-RCP-008.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-003,Receipt TXT is invariant to presentation state in WASM-002,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,The same governed run must be exercised under materially different permitted browser presentation states. In each case the run Receipt must remain an RCP TXT artifact governed by the same receipt serialization and facts. Presentation must not convert it to HTML or alter execution truth in WASM-002. This acceptance gate does not require a configurable Brand Manifest; that capability is deferred.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-001,A Suitcase may contain multiple Stores and each current Store state binds exactly one RID,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The Suitcase is a workspace and may contain zero, one, or multiple logical Stores. Every committed Store state binds exactly one governed current RID artifact. RID values are unique only within their Store row universe; they are not Suitcase-global identifiers. Ordinary same-row-universe work reuses that RID unchanged. In WASM-002, a missing, unreadable, or invalid current RID makes the Store INVALID ; no executable WASM-002 operation regenerates or substitutes that RID. Read-only Help/evidence may explain analyst-owned restoration or lineage-retirement choices, but Data Sculptor does not publish a replacement RID. The stable logical row reference in WASM-002 is conceptually (Store lineage, RID value) ; the current physical RID identity is the exact rid_filename bound by the authoritative MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-002,The Store RID is generated automatically once and reused unchanged in WASM-002,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"When the first successful materialization establishes a new Store, Data Sculptor must automatically generate that Store's initial RID artifact as part of the same Stage 2 operation and the same all-or-refuse publication boundary. The analyst does not separately request ordinary RID generation. Before the RID SCR candidate is created, Data Sculptor establishes the materialization publication-transaction UTC under PB-STOR-013/PB-STOR-014 and allocates a RID-specific UUID. The canonical RID byte stream is then written as the visible governed SCR candidate whose filename already carries that exact UTC, UUID, and .csv extension intended for the final RID identity. Requested materialized columns likewise begin as governed SCR candidates whose distinct COL-specific UUIDs are allocated before those candidates are opened under the same transaction UTC. The new RID candidate and all requested COL candidates must reach EOF, reconcile to the same accepted Store row count N, and pass their required final validation before any candidate is promoted. After complete-set validation, Data Sculptor promotes the RID candidate first by host rename that changes only the three-letter semantic class token from SCR to RID . The candidate bytes, UTC token, UUID, and .csv extension must remain unchanged across that promotion. Requested COL candidates are promoted only after RID promotion succeeds. If later promotion or successor-MAP publication prevents transaction commit, the newly promoted RID is not committed Store state merely because an RID-looking file exists; it must be rolled back where safely possible or retained as attributable recovery evidence under the materialization failure contract. A first Store-establishing materialization commits exactly one RID regardless of how many requested COLs are materialized. Later ordinary materializations and other same-row-universe WASM-002 operations must reuse that RID unchanged. They must not create a new RID candidate, regenerate, replace, renumber, or silently supersede the inherited RID. RID reconstruction/replacement is not an executable WASM-002 operation. Any future governed RID-recovery design remains deferred and must be reintroduced by an explicit later PRD freeze.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-003,RID physical identity uses the governed RID filename grammar,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The physical RID filename must be: __DS__RID__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv The filename contains governed physical identity only. A Store name or friendly analyst alias must not be inserted into, substituted for, or used to rename this immutable physical RID filename.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-004,RID is a canonical one-column CSV containing the exact sequence 1 through N,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The RID artifact must serialize as a canonical one-column UTF-8 CSV with: exactly one UTF-8 BOM at byte zero; a structural first logical record exactly N=<value> , where <value> is the canonical unsigned base-10 representation of the Store's total logical data-row count N ; uppercase N , exactly one equals sign, no spaces, no sign, no leading zeroes except the single digit 0 , and no separators or locale formatting; LF ( 0x0A ) record terminators on every supported host; exactly N data records after the header, containing the consecutive unquoted decimal integers 1 through N in order; no zero RID data value, negatives, signs, thousands separators, decimal points, exponent notation, or leading zeroes; and a final LF after the last record. For N=0 , the canonical bytes are the UTF-8 BOM followed by N=0 and LF, with no data records. The N=<value> record is structural metadata and does not consume a Store row. The governed RID artifact class/filename and Store MAP binding identify the artifact as a RID; the literal header RID is not used by the frozen WASM-002 serialization.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-005,RID cardinality and order define same-Store column alignment,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"If a Store RID contains N data records, every governed column claimed to be aligned to that Store must contain exactly N data records in the same RID order. Data Sculptor must not describe a shorter, longer, reordered, duplicated, or row-shifted column as aligned to that Store. This invariant applies to materialized source columns in WASM-002 and is the stable contract that later calculated, Boolean-selection, verification, or left-join enrichment columns may rely upon.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-006,A different row universe requires a different Store and a new RID,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,An operation that changes which rows exist or changes their governed order does not mutate the existing Store RID. It establishes a different row universe and therefore requires a new logical Store identity and a new RID artifact beginning again at 1 for that new Store. Filtering that is represented only as a same-length aligned Boolean/selection column does not itself change the row universe; building a new reduced/reordered row set later would.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-007,The Store MAP gives RID a friendly alias without changing RID identity,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The physical RID artifact remains identified by its immutable governed filename and semantic RID class. Every valid Store MAP records that exact rid_filename and one current human-facing rid_alias . Changing the RID alias must not rename, rewrite, regenerate, or alter the meaning of the RID artifact. The same Store MAP also records the Store alias and materialized-column aliases, so the analyst-facing names and the physical Store spine remain explicitly connected in one visible governed artifact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-008,Ordinary RID generation is implicit Store infrastructure; RID reconstruction is deferred,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"WASM-002 materialization Work Orders specify the analyst's requested source columns and aliases. They must not require or expose a separate instruction such as RID , ROW INDEX , GENERATE RID , or an equivalent switch to create the Store row spine. Initial RID generation for a new Store is mandatory engine behavior implied by successful MATERIALIZE . WASM-002 must not provide an option to disable it. When ordinary materialization extends an existing Store, the engine must recognize and reuse that Store's existing RID. If that bound RID is missing or invalid, the Store is INVALID and ordinary Store operations refuse. WASM-002 exposes no RECOVER RID executable syntax. A future explicit recovery design may be considered in V1-BACKLOG, but it is not part of this build contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-001,Canonical RID byte serialization acceptance,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"An acceptance fixture with N=5 must prove exact governed bytes equivalent to a UTF-8 BOM followed by: N=5
1
2
3
4
5 Every record uses LF termination and the file ends with a final LF. A separate N=0 fixture must prove exact bytes equivalent to UTF-8 BOM + N=0 and no data records. The N=5 fixture repeated under different permitted source-window boundaries must produce byte-identical RID content apart from the governed physical filename allocated to the artifact. Full RID validation must also prove that the declared N , the number of following data records, and the exact sequence 1..N agree.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-002,Multiple Stores in one Suitcase retain independent RID spines,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,An acceptance fixture must establish at least two Stores with different row counts in the same Suitcase and prove that each Store publishes and retains exactly one distinct governed RID artifact. RID values may overlap numerically across Stores without collision because the Store identity disambiguates them.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-003,Later same-Store materialization reuses rather than regenerates RID,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"An acceptance fixture must establish a Store with an initial materialization, record the physical RID identity and exact RID bytes, then perform a later permitted materialization that adds at least one aligned COL without changing the row universe. The later run must reference and reuse the original RID artifact; no replacement RID may be published and the original RID bytes must remain unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-004,Implicit RID generation acceptance for single- and multi-column first materialization,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"Acceptance must execute two Store-establishing Work Orders that contain no RID or row-index syntax: one requesting exactly one source column and one requesting multiple source columns. Each successfully committed run must publish exactly one governed RID artifact regardless of the number of requested COL artifacts. The fixture must prove that RID creation occurs during the same Stage 2 source-record traversal that establishes the Store row count rather than by requiring a second source pass solely to construct RID. The RID row count must reconcile exactly with every requested COL row count and the final accepted Store N. Before RID candidate creation, acceptance must prove that the publication-transaction UTC and RID-specific UUID are already established, and that the governed SCR filename carries exactly the UTC, UUID, and .csv extension intended for the final RID identity. Before complete-set validation, the RID bytes must exist only as that governed SCR candidate. Acceptance must prove that the RID candidate is promoted by host rename only after the complete RID/COL candidate set validates, that the physical-name change is exactly the class token SCR to RID , that candidate bytes/UTC/UUID/extension are unchanged across promotion, that RID promotion precedes COL promotion, and that the resulting RID is not considered committed Store membership until the successor MAP is successfully promoted and binds that exact RID filename.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-001,INVENTORY is an explicit standalone WASM-002 Work Order operation,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 form is: SUITCASE: .
WORK ORDER AS ""Inventory this Suitcase""
INVENTORY INVENTORY reads the authorized Suitcase directory metadata and creates one governed Suitcase Inventory Snapshot. It is read-only with respect to pre-existing Suitcase files. In WASM-002, an INVENTORY Work Order must not also request materialization, conversion, fingerprinting, another analytical operation, or another Work Order invocation. F-08 structure freeze: after the common SUITCASE: . / WORK ORDER AS ""..."" preamble, INVENTORY is the sole semantic operation clause and is terminal. No SOURCE , MAP , KEEP , alias mutation, conversion, repair, catalog, or composition clause is valid in the same WKO.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-002,Suitcase Inventory uses the governed INV artifact class and canonical filename grammar,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"A successful inventory produces exactly one visible flat TXT artifact whose physical filename is: __DS__INV__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt The UTC and UUID tokens follow the existing governed artifact-identity rules. Data Sculptor must not create an inventory subfolder, hidden cache copy, or alternate private persistence. F-14 publication: the INV body is produced first under the matching W002-STOR-023.1 SCR identity with the same UTC, UUID and .txt extension intended for the final INV. Publication to INV occurs only after the complete scan and deterministic INV serialization validate successfully.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-003,"The lightweight inventory records filename, exact byte length, and last-modified metadata",W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"For every regular file present in the authorized flat Suitcase root at snapshot time, the inventory must record: the exact visible filename; the exact byte length reported by the host file object; and the host/browser-reported last-modified value rendered in the canonical UTC millisecond form when available. WASM-002 must not claim access to a true file-creation timestamp. It must not infer, fabricate, or substitute a creation time from the last-modified value. If usable last-modified metadata is unavailable, the inventory must represent that fact explicitly rather than invent a timestamp. P3-10 last-modified availability test: host/browser last-modified metadata is usable only when the host supplies a finite, non-negative whole-number millisecond value that can be represented in the canonical UTC millisecond timestamp form. If that test fails, the inventory must serialize the governed unavailable value rather than infer, round, substitute, or fabricate a timestamp.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-004,INVENTORY does not read file contents or compute content hashes,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The lightweight inventory must be produced from directory enumeration and file metadata only. Data Sculptor must not open and stream the contents of each listed file merely to create the inventory, and it must not compute SHA-256 or another content fingerprint as an implicit side effect. Its cost should therefore scale primarily with the number of directory entries and metadata calls, not with the aggregate byte size of the files. A 7 GB CSV and a 7 KB CSV each contribute one metadata entry rather than requiring their contents to be read.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-005,Inventory scope is the authorized flat Suitcase root,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"WASM-002 inventories regular files and immediate child directory entries in the directory denoted by SUITCASE: . . Data Sculptor must not recursively inspect, enumerate, size, hash, or otherwise inventory the contents of a child directory in this build. Each immediate child directory is recorded as a directory entry by its exact visible name only. Its nested contents and aggregate size are outside the WASM-002 Inventory contract. This rule preserves the flat-Suitcase storage model while making the presence of user-created directories explicit rather than silently omitting them. F-26 SOURCE distinction: inclusion in an Inventory is evidence that an entry was physically visible to the Inventory operation; it does not make that entry eligible for a Work Order SOURCE . SOURCE eligibility is the narrower contract in W002-WKO-009.1.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-006,Inventory serialization is deterministic UTF-8 TXT,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The INV artifact is a deterministic human-readable TXT document encoded as UTF-8 without BOM, using LF ( 0x0A ) line endings, the same KEY: VALUE line grammar, and the same quoted-text escaping rule frozen by W002-RCP-005. Every INV ends with exactly one final LF, contains no trailing spaces, and contains no blank physical lines. The exact V1 Inventory serialization order is: INVENTORY_VERSION INVENTORY_UTC WORK_ORDER_FILENAME SUITCASE ENTRY_COUNT for each regular-file entry in deterministic ascending exact-filename UTF-8 byte order, one contiguous indexed triplet: FILE_<INDEX> , FILE_<INDEX>_BYTE_LENGTH , FILE_<INDEX>_LAST_MODIFIED_UTC DIRECTORY_COUNT exactly DIRECTORY_COUNT directory-name records using contiguous indexed keys DIRECTORY_<INDEX> , ordered by ascending exact-directory-name UTF-8 bytes. INVENTORY_VERSION is the unquoted integer 1 for this contract. WORK_ORDER_FILENAME , SUITCASE , each FILE_<INDEX> filename, and each DIRECTORY_<INDEX> name use the common double-quoted UTF-8 text serialization. FILE_<INDEX>_BYTE_LENGTH is the exact non-negative ungrouped ASCII base-10 byte length. FILE_<INDEX>_LAST_MODIFIED_UTC is either the exact canonical UTC millisecond token governed by W002-INV-003 or the unquoted governed absence token NOT_AVAILABLE . Indexed suffixes are one-based decimal with a minimum width of three digits and no maximum width: 001 through 999 are zero-padded and 1000 onward uses the full ungrouped decimal form. When ENTRY_COUNT or DIRECTORY_COUNT is zero, no indexed lines for that list appear. ENTRY_COUNT remains the regular-file count. Directory records contain the exact immediate child directory name only and do not imply recursive inspection or a computed directory size. Filename and directory-name representations remain unambiguous even when a name contains whitespace, quotes, or delimiter-like characters because the common quote-doubling rule applies. P3-10 inventory timestamp binding: INVENTORY_UTC must equal the exact canonical UTC token embedded in the final governed __DS__INV__<UTC>__<uuid-v4>.txt filename, just as RECEIPT_UTC is bound to the governed Receipt filename UTC. The INV body and filename therefore cannot claim different capture times.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-007,The current inventory describes the pre-publication Suitcase state and excludes itself,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,Data Sculptor must enumerate and fix the inventory snapshot before publishing the new INV artifact. The INV artifact being created is therefore not one of its own listed entries. Any older INV artifact that already existed at snapshot time is an ordinary Suitcase file and is included like any other file. This pre-publication rule prevents recursive self-reference while preserving an accurate snapshot of the state that existed immediately before the new inventory evidence was added.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-008,"Help describes INVENTORY as a quick continuity aid, not byte-level proof",W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"Help must explain that an INV snapshot is useful for ordinary closeout and later orientation: it can reveal additions, removals, renames, size changes, or last-modified changes when snapshots or current metadata are compared. For an unexpected cross-session source problem, Help may direct the analyst to the relevant source entry in an earlier INV and ask whether its filename, exact byte length, or last-modified metadata differs. Help must also state that unchanged filename/size/last-modified metadata does not prove that file contents or row order are identical. When stronger assurance is warranted because files may change unexpectedly, Help may recommend the explicit later/deeper content-fingerprinting workflow; INVENTORY itself must never imply forensic or cryptographic assurance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-001,Large-file inventory acceptance proves metadata-only behavior,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"An acceptance fixture must place at least one multi-gigabyte file plus several small files in the authorized Suitcase, execute INVENTORY , and prove that the resulting INV records the correct filename, exact byte length, and last-modified metadata without reading the multi-gigabyte file contents. Evidence must demonstrate that inventory runtime and memory do not scale with the aggregate bytes of the listed files in the way a fingerprinting pass would. P3-10 metadata determinism: acceptance must include at least one file with usable host last-modified metadata and one test double/fixture in which the last-modified value fails the governed availability test. The first must serialize the exact canonical UTC millisecond value; the second must serialize exactly NOT_AVAILABLE . The accepted INV must also prove that INVENTORY_UTC exactly matches the UTC token in its final INV filename. Day 060 H-01 byte oracle: acceptance must include at least one byte-exact INV golden fixture using the complete W002-INV-006 key order, indexed suffix rule, quoted-text escaping rule, UTF-8/no-BOM physical form, LF-only line endings, and exactly one final LF. It must include at least two file records so deterministic filename ordering is observable, including one NOT_AVAILABLE last-modified value, and at least one directory record. Day 060 H-09 reachable-Suitcase INV golden fixture The byte-exact INV golden fixture used for WASM-002 review must depict a Suitcase state that could actually execute INVENTORY under the current contract rather than an isolated impossible file list. At minimum, immediately before the Inventory Run begins, the fixture Suitcase contains: one valid current Suitcase Validation Certificate ( CER ) authorizing the root; one structurally valid current WKO registry MAP; the exact saved immutable INVENTORY WKO referenced by WORK_ORDER_FILENAME , registered as runnable by that current WKO MAP; and the ordinary analyst files used to demonstrate inventory metadata, including the controlled last-modified-available and NOT_AVAILABLE cases. The INV snapshot is taken before publication of the new INV artifact and before its Receipt publication. Therefore the INV being created and the Receipt for that Run do not appear as pre-existing entries in their own inventory snapshot. For the retained minimal review fixture, the regular-file ENTRY_COUNT and indexed records must include the CER, current WKO MAP, exact INVENTORY WKO, and the two ordinary sample files, for a total of five regular-file rows, serialized in ascending exact-filename UTF-8 byte order. A later implementation fixture may use different exact governed filenames/UUIDs while preserving the same reachable-state requirement and deterministic ordering.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-002,Inventory snapshot membership and self-exclusion acceptance,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"An acceptance fixture must include ordinary analyst files, existing governed __DS__ artifacts, and at least one older INV artifact. The new inventory must include every qualifying pre-existing root file in deterministic order, include the older INV, and exclude only the newly generated INV because it did not exist in the fixed pre-publication snapshot. Adding an unrelated PDF or ZIP before a later inventory must appear as an added inventory entry and must not be treated as an analytical error.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-003,Inventory does not overclaim unchanged contents,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"Acceptance documentation and Help fixtures must demonstrate the limitation of metadata-only continuity. A case in which a file's bytes are changed while the observed filename, byte length, and last-modified metadata are preserved or restored must not be described as detectable by INVENTORY alone. The product must direct the analyst toward stronger explicit fingerprint evidence when byte-level assurance is required.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-016,Work Order filenames use the governed immutable identity grammar,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When Data Sculptor saves a new Work Order as a WKO, it shall assign the physical TXT filename. The analyst chooses the validated Suitcase but is not asked to choose or edit the WKO filename. The exact WKO filename shape is __DS__WKO__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt , using UTC at millisecond precision with exactly three millisecond digits and a canonical lowercase hyphenated UUID v4. UTC precedes UUID. If the generated name collides with an existing artifact, PB-STOR-011 governs UUID regeneration and safe retry. The saved WKO thereafter retains that physical identity and remains immutable under W002-STOR-017.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-017,Saved Work Orders are immutable artifacts,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"After a Work Order TXT artifact is saved, Data Sculptor shall not edit, overwrite, or rename that saved Work Order in place. Changing analytical instructions requires saving a new Work Order artifact with a new governed physical identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018,Work Order alias is immutable WKO content and governed MAP metadata,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A human-facing Work Order name is required immutable Work Order content for every executable/saved WASM-002 WKO, not separately editable browser metadata. The canonical declaration is WORK ORDER AS ""<alias>"" under W002-STEPS-001.1. The quoted alias must be non-empty UTF-8 text and may contain spaces and ordinary phrase punctuation subject to the governed string-literal rules. After the WKO TXT artifact is saved, Data Sculptor shall not edit the alias in place. Changing the alias, analytical instructions, or comments means creating and saving a new immutable WKO with a new governed physical identity. The physical WKO filename/UUID remains execution identity; the alias is human-facing metadata for display and governed name resolution. The browser must not maintain a separate mutable Description field or hidden description store. The alias declared by the WKO is also represented in the current governed WKO MAP under W002-STOR-018.1 through W002-STOR-018.4.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.1,The existing MAP class includes a distinct WKO alias-registry profile,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Revision BB does not add a new semantic artifact class. The existing MAP class has two explicitly distinguished governed profiles: Store MAP — the existing exact eight-column Store/RID/COL snapshot governed by W002-STOR-019 through W002-STOR-019.12; WKO MAP — a complete immutable snapshot that maps saved Work Order aliases and lifecycle status to exact immutable WKO filenames. Profile classification is determined by the exact CSV header before profile-specific validation. A valid WKO MAP must never be treated as an eligible Store MAP, and a Store MAP must never be treated as a WKO alias registry. Both remain visible flat-Suitcase MAP artifacts under the canonical immutable filename grammar.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.2,WKO MAP schema and serialization are exact and deterministic,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical WKO MAP is UTF-8 CSV without BOM, using LF record termination, with exactly this three-field header: wko_status,wko_alias,wko_filename Each row identifies one immutable governed WKO represented in that registry snapshot. wko_status is exactly CURRENT or DEPRECATED . wko_alias is the exact mandatory non-empty alias declared by that WKO's WORK ORDER AS clause. wko_filename is the exact governed physical WKO filename. Rows are written deterministically by ascending exact UTF-8 byte order of wko_filename . Duplicate wko_filename rows are invalid. Standard governed CSV quoting applies. For any exact wko_alias value, at most one row may have wko_status=CURRENT ; zero or more older rows for that same alias may have wko_status=DEPRECATED . Alias resolution uses the CURRENT row only. A WKO represented by a DEPRECATED row remains immutable historical evidence and is not renamed, rewritten, or deleted merely because its alias target was superseded. A WKO MAP containing more than one CURRENT row for the same exact alias is structurally invalid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.3,Saving a WKO and publishing its WKO MAP binding is one governed save transaction,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Saving a new immutable WKO begins from the current structurally valid WKO MAP in the Suitcase, or an empty WKO registry if no structurally valid WKO MAP exists. Data Sculptor validates the draft, including its mandatory non-empty WORK ORDER AS alias and comment syntax, and checks the governed alias/lifecycle constraints before commit. F-02 alias-lifecycle decision: if no CURRENT row in the predecessor WKO MAP uses the new WKO's exact alias, the successor registry adds the new WKO as CURRENT . If exactly one CURRENT row already owns that exact alias, Data Sculptor must present exactly two analyst choices before registry commit: Replace alias target or Cancel . Replace alias target constructs the successor WKO MAP by changing the former owner's row to DEPRECATED and adding the newly saved WKO as the sole CURRENT row for that alias; any older DEPRECATED rows remain unchanged. Cancel leaves the predecessor WKO MAP authoritative and does not commit the pending WKO/WKO-MAP pair as a registry update. Data Sculptor must not silently replace the alias target, auto-suffix the alias, or choose between competing owners. A predecessor WKO MAP with more than one CURRENT row for the same alias is structurally invalid under W002-STOR-018.2 and cannot be used as save authority. The former CURRENT WKO and every prior WKO MAP remain byte-for-byte immutable after replacement. Supersession changes only the lifecycle metadata represented in the newly published successor WKO MAP; it does not edit, rename, delete, or rewrite the historical WKO artifact. F-14 WKO publication predicate: the new immutable Work Order is first written under the W002-STOR-023.1 SCR identity using the UTC, UUID and .txt extension intended for its final WKO identity. The complete candidate is closed, reopened and validated as a saved WKO: required common preamble, exactly one non-whitespace WORK ORDER AS alias, governed lexical/comment rules, and complete parse under exactly one current WASM-002 executable operation grammar. Only then may the candidate be renamed from SCR to WKO . Save-time current-registry, alias-lifecycle and lifecycle gates remain transaction preconditions. A valid promoted WKO is not yet alias-registry authority; the successor WKO MAP promotion remains the save-transaction commit point. The WKO is persisted as a new immutable governed WKO artifact and the complete successor WKO MAP is constructed under SCR , closed, reopened, and validated for WKO MAP structural validity : exact profile/schema, exact governed serialization, filename/profile rules, lifecycle-row constraints, and internal row constraints. Whether every referenced physical WKO file is presently visible is a separate registry-health/publication check and is not part of WKO MAP structural validity. For an ordinary successful save transaction, every WKO referenced by the successor registry must be present at publication. The successor WKO MAP is promoted to MAP last; that successful MAP promotion is the alias-registry commit point for the save transaction. The WKO and successor WKO MAP created by one successful save transaction use one shared canonical transaction UTC while retaining distinct UUIDs. If successor WKO-MAP structural validation, referenced-file publication checking, or publication itself fails, the save must not be represented as a successfully committed alias-registry update. Data Sculptor must roll back the new WKO out of committed WKO state where safely possible or retain visible non-authoritative SCR failure evidence and report the failure through Help. F-02 repair-only bootstrap and stale-registry Save boundary When the current WKO registry is repair-required under W002-STOR-018.4, Data Sculptor may save one ordinary visible immutable WKO whose sole semantic operation is exactly REPAIR WORK ORDER REGISTRY . That saved repair-only WKO may Run by its exact physical WKO filename even though it is not yet represented in the current WKO MAP. The WKO must be structurally valid under the predicate below, must contain exactly one mandatory non-empty WORK ORDER AS , and must contain exactly the governed registry-repair operation and no second operation. The exception does not grant alias-based Run authority. The repair WKO is invoked only by exact physical WKO filename. No other visible but unregistered WKO gains Run eligibility from this exception. The exception ends once registry repair successfully publishes the successor WKO MAP. This is the sole WASM-002 bypass of ordinary current-registry membership for Run eligibility. Because the registry is already stale, Save of the repair-only WKO does not claim that the WKO has been registered, does not commit an ordinary successor WKO MAP, and does not represent the stale registry as healthy. The new immutable WKO remains visibly unregistered until the repair operation successfully publishes the successor WKO MAP containing its row. Save does not silently perform registry repair. F-02 governed WKO structural-validity predicate A visible WKO is structurally valid for registry purposes only when all of the following hold: it is a regular root-level Suitcase file; its physical filename conforms exactly to the governed WKO filename grammar; its bytes are valid UTF-8; LF and CRLF physical line endings are accepted; a lone CR line ending refuses; its content parses completely under exactly one defined WASM-002 executable Work Order grammar; it contains exactly one mandatory non-empty WORK ORDER AS clause; its required common and operation-specific structural clauses are present in their governed order/cardinality; and unknown syntax or prohibited operation mixing causes invalidity/refusal. Structural validity is not runtime success. A structurally valid WKO remains a valid governed artifact even when a runtime precondition is currently false, such as a referenced source file being absent. Runtime preconditions are checked at Run. P3-10 repair-bootstrap timing: during REPAIR WORK ORDER REGISTRY , the saved repair-only WKO participates in the bounded discovery performed by that repair run. It is not first “discovered after success.” Its governed registration becomes durable only when the complete successor WKO MAP containing that WKO row is successfully committed. Discovery during the run and registration in the committed successor registry are distinct events. P2-03 WKO-registry chronology guard: before a save or registry-repair transaction publishes a successor WKO MAP, Data Sculptor establishes the truthful observed transaction UTC and compares it with the chronology predecessor defined by W002-STOR-018.4. The observed UTC must be strictly greater. Equal or earlier UTC refuses before the new WKO/WKO-MAP pair is committed; Data Sculptor must not fabricate a later timestamp, silently wait/retry, skip the predecessor, or select an older registry merely to make publication succeed. F-13 single-writer pre-commit guard: immediately before the successor WKO MAP promotion that would commit the alias-registry update, Data Sculptor re-resolves the current WKO-registry authority and compares the relevant governing state with the state from which this transaction was derived. If another writing context or external filesystem action has changed that relevant authority, the transaction refuses publication. It must not overwrite the newer registry, silently rebase the pending save, or choose an older registry to make the commit succeed. The existing rollback / attributable SCR recovery-evidence rules apply to any WKO or candidate bytes already produced. If the save later refuses and an SCR candidate or other attributable staged evidence cannot be safely removed/restored, W002-STOR-023.1 governs retained SCR evidence and its non-authority boundary; WASM-002 does not emit RCV. An unregistered final WKO left by a failure is a valid immutable WKO artifact but does not become current registry authority merely by existing; the WKO MAP remains authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.4,Current WKO MAP selection is based on structural validity; missing referenced WKOs make the registry repair-required,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"WKO MAP structural validity is distinct from registry health. A WKO MAP is structurally valid when the MAP artifact itself satisfies the governed WKO MAP profile/schema, serialization, filename/profile rules, lifecycle-row constraints, and internal row constraints. The present existence of every physical WKO file named by its rows is not part of WKO MAP structural validity. Only structurally valid WKO MAP artifacts participate in current-registry selection. Among structurally valid WKO MAPs, the one with the greatest canonical UTC millisecond timestamp is the current WKO MAP snapshot and therefore the current governed Work Order alias registry. If two or more structurally valid WKO MAPs share that greatest timestamp, current-registry selection must refuse rather than break the tie by UUID, discovery order, filesystem modified time, or directory order. Registry-snapshot authority is distinct from alias-target status inside that snapshot. After the current WKO MAP snapshot is selected, an alias resolves only to its exact row whose wko_status is CURRENT . Rows marked DEPRECATED remain visible historical registry evidence but are not alias-resolution targets. The registry must never use the greatest WKO filename UTC, filesystem modified time, or discovery order to choose between rows for an alias. More than one CURRENT row for the same exact alias makes that WKO MAP structurally invalid under W002-STOR-018.2. If a newer WKO MAP artifact is structurally malformed, it never becomes current. Data Sculptor uses the greatest earlier structurally valid WKO MAP, if one exists, and reports the malformed newer artifact through Help/evidence surfaces. A malformed newer WKO MAP does not itself make the selected earlier registry repair-required. The current WKO registry is repair-required exactly when the current structurally valid WKO MAP contains one or more rows whose referenced physical WKO files are missing from the Suitcase. Such a MAP remains current ; Data Sculptor must not silently fall back to an older WKO MAP merely because a referenced WKO is missing. This preserves the latest registry authority while making the damage explicit and reachable through the governed REPAIR WORK ORDER REGISTRY path. F-02 deterministic registry reconciliation REPAIR WORK ORDER REGISTRY reconciles the current WKO MAP against visible WKO artifacts in the Suitcase and constructs one complete successor WKO MAP deterministically: Remove every row from the successor whose referenced physical WKO file is missing. A missing WKO is never reconstructed, inferred, copied from history, or replaced automatically by a deprecated WKO. Discover visible structurally valid WKOs that are absent from the current WKO MAP. If no surviving CURRENT row owns a discovered WKO's exact alias, register that discovered WKO as CURRENT . If a surviving CURRENT row already owns that exact alias, register the discovered WKO as DEPRECATED ; existing current authority is not silently displaced. If two or more previously unregistered structurally valid WKOs share the same alias and no surviving CURRENT owner exists, register all of those discovered WKOs as DEPRECATED . Data Sculptor must not choose a winner by UTC, filename, UUID, directory order, discovery order, or filesystem modified time. The repair WKO itself participates in the same discovery and registration process during the repair run. Its registration becomes durable only when the complete successor WKO MAP is committed. Predecessor WKO MAPs and surviving WKO files remain immutable historical evidence. Successor rows remain serialized in ascending exact UTF-8 byte order of wko_filename under W002-STOR-018.2. Day 060 H-10 / BM-07 registry-repair change-set counts The registry-repair operation distinguishes the successor registry state from the change set produced by this repair Run . The Receipt's REGISTERED_CURRENT_* and REGISTERED_DEPRECATED_* fields describe only the latter. REGISTERED_CURRENT_COUNT is the exact number of previously unregistered structurally valid WKO files newly added by this repair Run with wko_status=CURRENT . REGISTERED_CURRENT_WKO_<INDEX>_FILENAME lists exactly those newly registered CURRENT WKOs, ordered by ascending exact UTF-8 filename bytes. REGISTERED_DEPRECATED_COUNT is the exact number of previously unregistered structurally valid WKO files newly added by this repair Run with wko_status=DEPRECATED . REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME lists exactly those newly registered DEPRECATED WKOs, ordered by ascending exact UTF-8 filename bytes. Surviving rows that were already present in the base WKO MAP are not counted in either REGISTERED_* total, even though they appear in the successor WKO MAP. Rows removed because their referenced WKO is missing are represented only by REMOVED_STALE_ROW_COUNT and the corresponding stale-WKO filename list; they are not also reflected in either registered count. The bootstrap repair WKO participates exactly like any other newly discovered structurally valid unregistered WKO. If the repair commits it, that exact WKO must appear in one and only one of the two registered filename lists according to the ordinary alias-ownership rules. These counts therefore answer “what did this repair register?” rather than “how many CURRENT/DEPRECATED rows exist in the resulting registry?”. F-02 Run eligibility and alias authority Run by human-facing alias resolves only to the sole CURRENT WKO for that alias. A registered CURRENT WKO may Run by exact physical WKO filename, subject to ordinary runtime preconditions. A registered DEPRECATED WKO may also Run by exact physical WKO filename, subject to ordinary runtime preconditions, to support deliberate historical reproduction. An unregistered WKO may not Run merely because its file is visible, except for the single bounded repair-only bootstrap in W002-STOR-018.3. The browser may use the current structurally valid WKO MAP to show human-facing Work Order aliases together with read-only CURRENT / DEPRECATED lifecycle state while keeping exact physical WKO filenames visible/inspectable. Future Work Order composition may use the same registry to resolve a non-empty alias to exactly one immutable WKO artifact through its sole CURRENT row. This requirement does not pull deferred Work Order invocation/orchestration grammar into WASM-002; it establishes the governed alias-registry selection, lifecycle, and repair boundary that later composition can depend on. F-08 REPAIR WORK ORDER REGISTRY Work Order structure: SUITCASE: .
WORK ORDER AS ""Repair Work Order Registry""
REPAIR WORK ORDER REGISTRY After the common preamble, REPAIR WORK ORDER REGISTRY is the sole semantic operation clause and is terminal. It takes no analyst-supplied SOURCE , Store MAP , alias-mutation list, column selector, conversion source, or catalog clause. Its bounded unregistered-repair bootstrap remains governed by W002-STOR-018.3. The DS-STEPS phrase is distinct from the Receipt operation token REPAIR_WORK_ORDER_REGISTRY . P2-03 chronology predecessor: for any WKO-registry successor publication, the chronology predecessor is the unique current structurally valid WKO MAP immediately before that publication transaction. It is the MAP selected by the current-registry rule above, not an older registry used for inspection and not a filesystem-modified-time surrogate. If no structurally valid WKO MAP exists and the operation is legitimately establishing the first governed registry state, there is no predecessor UTC. Future-dated current WKO MAP: a structurally valid current WKO MAP whose governed UTC is later than truthful observed host UTC remains the current registry; the timestamp conflict does not by itself make the MAP malformed or repair-required. Successor WKO-MAP publication is blocked until the monotonic UTC precondition can be satisfied. Help must identify the exact blocking WKO MAP and explain the analyst-owned exits: correct an incorrect host clock; wait/rerun after truthful time advances beyond the predecessor; or, when the analyst deliberately determines that the active future-dated WKO MAP should no longer govern the Suitcase, move that exact MAP out of the active Suitcase root and reopen/rescan. That filesystem action is not a Data Sculptor repair operation. It may expose an older structurally valid WKO MAP as current, and restoring the moved future-dated MAP to the active Suitcase may make it current again under the ordinary greatest-UTC rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019,Store state is preserved as visible immutable MAP history,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each valid WASM-002 MAP is one complete immutable Store snapshot in the same flat Suitcase. Store state is not stored in hidden browser persistence and is not represented by a mutable well-known singleton. Each successful Store-establishing materialization or later governed Store-metadata/materialized-column update publishes a new immutable MAP under the canonical __DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv identity grammar. Earlier MAP artifacts remain visible history and are not overwritten or deleted merely because a newer Store state is created. Day 057 CAT reconciliation: the one-Store-per-MAP invariant is unchanged. A collection of independently MAP-governed Stores may additionally be summarized by a governed CAT Store Catalog for collection-level discovery and orientation. CAT does not govern Store semantics, lineage, health, repair, inheritance, or current-MAP selection. MAP remains authoritative for each Store.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.1,A Work Order may explicitly select at most one Store MAP,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each governed Work Order may explicitly identify at most one valid immutable Store MAP as its Store/inheritance base. If more than one MAP is explicitly specified, Data Sculptor must refuse before Store resolution, alias resolution, materialization, or mutation. An explicitly named valid MAP binds the run to exactly the Store identified by that MAP's rid_filename and overrides automatic Store-MAP discovery even when newer MAPs for that Store or other Stores exist.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.2,"Without an explicit MAP, materialization performs Store-aware MAP inheritance",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If a materializing Work Order does not explicitly identify a MAP, Data Sculptor must compare the exact Work Order SOURCE filename with the one common exact source_filename carried by every row of each routable Store lineage's structurally valid Store MAP. That common source_filename is the Store lineage's source identity for WASM-002 routing. The redundant ninth Store-source field from the superseded profile is not part of the canonical Store MAP. P3-07 routing term: for automatic source routing, a routable Store lineage is a Store lineage for which at least one structurally valid Store MAP exists, regardless of whether the lineage currently evaluates VALID , DEGRADED , or INVALID . Routing discovery must use this term rather than the ambiguous word eligible . Store health is evaluated only after the lineage has been discovered. If no routable Store lineage exists for the exact source filename, Data Sculptor may establish a new Store with a new RID and first Store MAP only if the active Suitcase contains no structurally malformed Store-MAP-class artifact . If exactly one routable Store lineage exists, Data Sculptor routes to that lineage. If its current state permits materialization, the current governed Store MAP is the inheritance base; if its current state is DEGRADED or INVALID , ordinary materialization refuses under the damaged-lineage rules below. If more than one distinct routable Store lineage exists for the same exact source filename, automatic inheritance must refuse rather than guess which Store the analyst intended. The analyst must explicitly select one permitted MAP. All-Store-MAPs-damaged guard: if exact- SOURCE routing finds no routable Store lineage but one or more structurally malformed Store-MAP-class artifacts are present in the active Suitcase, ordinary materialization must refuse before creating a new Store or RID. Data Sculptor must not infer that the absence of a structurally valid Store MAP proves that no prior Store lineage existed. Help must identify the malformed Store MAP artifact or artifacts that caused this guard. A damaged MAP therefore cannot silently turn Store damage into permission to create a replacement lineage. Store lineages are distinguished by their governed lineage identity. Current-MAP selection and Store-health evaluation are separate governed questions under this requirement and W002-STOR-019.10. If two or more structurally valid current MAP candidates for the one routed Store share the greatest canonical UTC millisecond timestamp, automatic inheritance must refuse rather than infer chronology from UUID, directory order, filesystem modified time, or discovery order. F-03 canonical evaluated Store-health states Store health is evaluated from the current structurally valid Store MAP and the presently visible governed artifacts it references, using the applicable validation tier in W002-STOR-019.10. WASM-002 has exactly three evaluated Store-health states: VALID — the current Store MAP is structurally valid; the referenced RID is valid; and every mapped non-RID COL is valid. DEGRADED — the current Store MAP is structurally valid; the referenced RID is valid; and one or more mapped non-RID COL artifacts are missing or invalid. INVALID — the current Store MAP is structurally valid, but its referenced RID is missing or invalid. There is no fourth ABANDONED Store-health status in WASM-002. F-03 status is evaluated, not persisted VALID , DEGRADED , and INVALID are evaluated states. WASM-002 does not write or maintain a mutable persisted Store-status flag. While a Store evaluates INVALID , Data Sculptor exposes no governed Store-recovery operation for that Store and never regenerates, substitutes, or infers a replacement RID. If the exact governed RID physical identity becomes visible again through analyst-owned external restoration and passes the validation tier required by the next operation, the Store is re-evaluated from the visible governed artifacts and may become VALID or DEGRADED . That is re-evaluation, not RID recovery by Data Sculptor. F-03 strict DEGRADED operation gate When a Store evaluates DEGRADED , REPAIR MAP is the only enabled Store mutation operation for that lineage . ordinary materialization into that Store refuses; extension with new columns refuses; alias mutation refuses; transformations and other Store mutations refuse; read-only Help, Inventory, status/orientation surfaces, CAT orientation, and evidence inspection remain available subject to their own contracts. F-03 no damaged-lineage fork If exact SOURCE routing identifies a lineage whose current Store evaluates DEGRADED , ordinary materialization refuses and directs the analyst to the governed REPAIR MAP path. If the routed Store evaluates INVALID , ordinary materialization refuses and WASM-002 provides no RID-recovery path. Neither condition permits Data Sculptor to treat the source as unseen or establish a replacement Store with a new RID for that routed lineage. Damaged-lineage routing: exact SOURCE routing must not treat a known damaged lineage as unseen merely because its current Store state cannot accept ordinary materialization. If routing identifies a DEGRADED or INVALID lineage, ordinary materialization refuses rather than silently creating a replacement Store for that same routed lineage. Help duty for an all-COLs-broken DEGRADED lineage: when the current structurally valid Store MAP references a valid RID but every mapped non-RID COL is missing or invalid, REPAIR MAP cannot publish a zero-COL successor and must refuse. Help must identify the exact blocked Store lineage and current MAP, then explain these analyst-owned exits: (1) externally restore at least one governed COL artifact under its original physical filename; Data Sculptor then applies the governed validation tier required by the next operation before the artifact can re-enter use, so Store health can be re-evaluated and REPAIR MAP may become available; (2) rename the analyst-owned source and materialize the renamed source to deliberately begin a new Store lineage with a new RID, without repairing, replacing, or erasing the damaged lineage; or (3) retire the damaged lineage from active Suitcase routing by moving all Store MAP artifacts belonging to that lineage out of the Suitcase root. Help must warn that moving only the latest MAP is insufficient because an older structurally valid MAP could otherwise become current. Help duty for an INVALID lineage: when the current structurally valid Store MAP references a missing or invalid RID, Help must identify the exact blocked Store lineage and current MAP, state that WASM-002 does not silently regenerate or substitute a RID as part of ordinary materialization, and explain these analyst-owned exits: (1) externally restore a governed RID artifact under its original physical filename; Data Sculptor then applies the governed validation tier required by the next operation before the artifact can re-enter use, so Store health can be re-evaluated; (2) rename the analyst-owned source and materialize the renamed source to deliberately begin a new Store lineage with a new RID while leaving the damaged lineage untouched; or (3) retire the damaged lineage from active Suitcase routing by moving all Store MAP artifacts belonging to that lineage out of the Suitcase root, again warning that moving only the latest MAP is insufficient. Renaming the source and retiring a lineage are distinct analyst choices. Renaming preserves the damaged lineage in the Suitcase and creates a separate lineage under a different source identity. Moving all lineage MAPs out removes that lineage from active routing while preserving the moved artifacts wherever the analyst chooses to keep them. These are analyst filesystem actions, not new Data Sculptor recovery operations. Assurance boundary: exact source-filename matching in this rule is a Store-routing/orientation mechanism, not proof that an analyst-owned source has identical bytes or row order across separate sessions. Ordinary WASM-002 materialization must not silently represent that filename equality as cryptographic continuity. P3-08 CVT source-identity boundary: a governed CVT is a new immutable source artifact whose Store-routing source identity is its exact physical CVT filename. Two different CVT filenames are different source identities even when both conversions began from analyst-owned files having the same original filename. WASM-002 does not carry the analyst-owned pre-conversion filename forward as hidden Store-lineage identity and does not infer continuity between separate CVT artifacts. First materialization of a CVT therefore establishes or routes only by that exact CVT filename under the normal rules above. P2-03 current Store-MAP chronology: within one routable Store lineage, the current structurally valid Store MAP is the unique structurally valid MAP carrying the greatest canonical UTC millisecond timestamp. If two or more structurally valid MAPs share that greatest timestamp, current authority is ambiguous and selection refuses rather than using UUID or discovery order. This current MAP is also the lineage's chronology predecessor for any new successor publication, even when the operation explicitly derives its requested new state from an older historical MAP. F-15 exact-source comparison and routing domain: the Work Order SOURCE value and each Store MAP's common source_filename are compared by exact Unicode scalar-value sequence under PB-STOR-010, with no case folding or Unicode normalization. Automatic routing compares only routable Store lineages whose structurally valid Store MAPs participate in that exact-source routing decision. Unrelated Suitcase files, non-Store artifact classes, filesystem enumeration order, and arrival order are outside the routing comparison domain and cannot create or remove a source match.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.3,"Any valid historical Store MAP may be selected explicitly with MAP ""<filename>""",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A governed Store-aware Work Order may explicitly identify any one structurally valid immutable Store MAP present in the Suitcase, including an older snapshot when newer MAPs for that Store also exist. The canonical clause is: MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv"" The quoted value must be the exact physical filename of one valid Store MAP. A WKO MAP profile, missing file, malformed MAP, or other MAP profile is invalid for this clause. Data Sculptor uses exactly the named Store MAP rather than silently substituting a later one. For materialization, SOURCE ""..."" remains required to identify the source file being read; the optional MAP ""..."" clause occurs immediately after SOURCE and before KEEP , overrides automatic Store-MAP inheritance, and supplies the exact Store-state base. The Work Order's exact SOURCE filename must match the selected lineage's governed source identity under the frozen source/Store compatibility rules or validation refuses. For an alias-only UPDATE ALIASES Work Order, MAP ""..."" may itself be the Store-state selector and no source-data read is required. Historical-MAP health gate. Explicit selection of a current or historical Store MAP never bypasses current Store-lineage health. The selected lineage must currently evaluate VALID , and every RID/COL binding referenced by the named MAP must currently be present and valid. If either condition fails, Data Sculptor refuses the operation. An older MAP cannot be used to hide present lineage damage. The same rule applies when UPDATE ALIASES uses a historical Store MAP as its base. Once selected, the exact MAP identity, Store RID binding, Store alias, RID alias, and materialized-column mapping state remain fixed for the governed run. The MAP filename is execution input, not a friendly alias. P2-03 base-versus-predecessor distinction: an explicitly selected historical MAP is the operation's base MAP —the Store snapshot from which requested new state is derived. It does not become the chronology predecessor merely because it was selected. If the operation publishes a new Store MAP, the chronology predecessor remains the Store lineage's current structurally valid MAP immediately before publication. The new transaction UTC must be strictly greater than that current MAP UTC. This preserves one chronological MAP history rather than creating a branch from the historical base. F-21 current-state consequence: merely selecting or validating a historical Store MAP does not change Store authority. If the governed run refuses or otherwise publishes no successor Store MAP, the lineage's pre-run current MAP remains current. If the run successfully publishes a successor derived from a historical base, that new MAP enters the same single chronological history and ordinary greatest-governed-UTC current-state selection applies. Because successor publication already requires a truthful transaction UTC strictly greater than the pre-publication chronology predecessor, the successfully published successor becomes current. The explicitly selected historical base and the formerly current MAP both remain immutable historical evidence. This behavior is deliberate state derivation, not a branch, rollback-in-place, overwrite, or mutation of prior MAPs. The operation base records which Store snapshot supplied the requested starting state ; chronology records when the new governed state was published . Those are distinct facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.4,"Store MAPs are complete snapshots, not delta logs",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each valid Store MAP represents one complete usable Store metadata and materialized-column mapping state for that version. It must not require replaying a chain of earlier MAP files merely to reconstruct the Store's current RID binding, aliases, or materialized-column mappings. A newer MAP created from an inherited older MAP contains the complete resulting Store snapshot after applying the governed Work Order's successful changes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.5,Materialization or governed Store metadata mutation emits one successor MAP,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When a governed Work Order materializes one or more columns or requests governed Store/RID/COL alias changes, Data Sculptor begins from the applicable governed Store-state base. Ordinary materialization uses the explicitly selected MAP or Store-aware automatic inheritance under W002-STOR-019.2. A new Store begins from newly established Store/RID metadata plus an empty materialized-column mapping set before requested materialization is applied. All successful updates in that Work Order are applied to one in-memory complete Store snapshot. The complete deterministic successor-MAP bytes must first be written under a governed SCR candidate identity, closed successfully, reopened, and fully validated while still an SCR candidate. Only a complete validated candidate may be promoted by host rename into one new immutable MAP artifact. The inherited MAP remains unchanged. The successful SCR -to- MAP rename is the Store-state commit point. A failed run must not create a valid successor MAP; a malformed, incomplete, or unpromoted MAP candidate remains visible non-authoritative SCR evidence rather than Store state. RID reconstruction/replacement is not a WASM-002 Store-mutation path. P2-03 successor publication precondition: before any final RID/COL/MAP promotion for a successor Store-state transaction, Data Sculptor identifies the lineage's chronology predecessor and establishes one truthful observed host transaction UTC. For an existing lineage, that UTC must be strictly greater than the current structurally valid Store MAP UTC, regardless of whether the Work Order's base MAP is current or historical. Equal or earlier observed UTC refuses publication; no artificial +1 ms , sleep-and-retry loop, UUID tie-break, older-predecessor fallback, or branch chronology is permitted. The chronology predecessor remains current and unchanged. Future-dated current Store MAP: a structurally valid current MAP with a governed UTC later than truthful observed host UTC is a clock-order conflict, not by itself Store corruption. It remains current and successor publication is blocked. Help must identify the exact blocking MAP and explain the analyst-owned exits: correct an incorrect host clock; wait/rerun after truthful time advances beyond the predecessor; or deliberately move that exact future-dated current Store MAP out of the active Suitcase root and reopen/rescan. Moving it is an analyst filesystem action, not a governed Data Sculptor mutation. An older structurally valid MAP may then become current; returning the future-dated MAP may restore its authority under the ordinary greatest-UTC rule. F-13 single-writer pre-commit guard: immediately before the final successor Store-MAP promotion, Data Sculptor re-resolves the relevant current Store authority and exact-source routing state on which the transaction depended. For an existing lineage, the current chronology predecessor must still be the authority against which the transaction was prepared; for a new-Store transaction, no newly established routable lineage may have appeared that changes the routing decision. If relevant governed state changed while the transaction was in flight, publication refuses. Data Sculptor must not overwrite the newer authority, silently rebase onto it, create a competing branch, or report success. Any RID/COL/candidate artifacts already produced are handled by the existing rollback / attributable recovery-evidence rules and do not become committed Store membership without the final valid MAP binding. F-21 historical-base publication rule: when the applicable Store-state base is a valid historical MAP rather than the pre-run current MAP, the complete successor snapshot is still derived from that explicitly selected base plus the current Work Order's requested changes. Publication does not silently merge later state from the formerly current MAP back into the successor. Therefore mappings or aliases introduced only after the selected historical base may be absent from the new successor when the requested operation does not recreate them. That is the deliberate consequence of using the historical base, not data loss caused by an implicit merge. The pre-run current MAP remains the chronology predecessor solely for monotonic publication ordering and stale-authority protection. Successful publication leaves both the historical base and the formerly current MAP byte-for-byte unchanged, publishes one new immutable successor MAP in the same lineage, and makes that successor current under the ordinary chronology rule. No branch identifier, hidden branch state, overwrite, in-place rollback, or automatic rebase is created.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.6,Store MAP CSV schema is exactly eight columns,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 Store MAP is a CSV whose header row is exactly: store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename Each data row describes one current logical materialized-column mapping: store_alias — current human-facing Store name; rid_filename — exact immutable governed RID artifact filename that physically anchors this Store lineage; rid_alias — current human-facing RID name; source_filename — exact visible source filename common to every row in this one-Store MAP and therefore the Store source identity; source_column_number — 1-based source-column ordinal; source_header — exact decoded CSV header value after governed parsing; alias — current human-facing COL name; and column_filename — exact physical governed COL artifact filename represented by the row. Every row in one valid Store MAP must carry the same exact rid_filename and the same exact source_filename . A MAP that mixes RID lineages or source filenames is invalid. The logical source-column key for COL alias continuity remains the exact triple (source_filename, source_column_number, source_header) . The Store is physically identified by the repeated exact rid_filename , not by mutable aliases. F-05/P2-01 reconciliation: the superseded redundant Store-source column is removed. One Store MAP represents exactly one Store lineage and exactly one source identity, so the common source_filename supplies the required source identity without a second Store-source field. P3-06 identity-evidence boundary: this eight-column MAP profile intentionally records governed physical filenames and mapping metadata, not per-artifact byte lengths, row counts, digests, or historical-content fingerprints. A MAP therefore cannot prove that a same-named RID or COL restored later is byte-for-byte identical to the earlier artifact. WASM-002 must not make that claim unless separate authoritative fingerprint evidence exists outside this MAP profile. P2-04 schema consequence: no byte-length, RID- N , digest, or per-artifact fingerprint columns are added to the eight-column Store MAP to close restoration validation. The MAP remains compact relationship/state metadata. Stronger byte-identity assurance remains the responsibility of explicit fingerprint evidence outside ordinary WASM-002 Store governance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.7,Source headers become default COL aliases on first materialization,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When a logical source column is materialized and its exact logical key does not already exist in the inherited Store MAP, its default COL alias is its operational column name . For an exact decoded source_header of at most 1,024 Unicode scalar values, the operational name is that exact header text. For an exact decoded source_header longer than 1,024 scalar values, the operational name begins as Column <LETTERS> from the column's 1-based physical source ordinal (for example Column A , Column Z , Column AA , through Column XFD ). The exact source_header remains unchanged in the Store MAP and physical COL header; the operational name exists only to provide a bounded human-facing/default-alias value. HEADER selection continues to match the exact decoded source header under W002-STEPS-002. If an oversized-header base fallback Column <LETTERS> would collide in the complete successor alias namespace, Data Sculptor deterministically tries Column <LETTERS> [<ordinal>] ; if that also collides, it appends -2 , -3 , and so on until the first available exact value is found. This is the only automatic alias-suffix rule in WASM-002. A short exact source-header default that is empty or collides still refuses unless the Work Order supplies an explicit valid alias; Data Sculptor must not suffix or rewrite it. If the same Work Order supplies an explicit alias for a newly materialized column, the explicit governed alias overrides the operational default and must pass the ordinary exact uniqueness/shadowing rules without automatic suffix repair. For a previously materialized COL, RESET COL ""<reference>"" ALIAS restores this same deterministic operational default from the exact recorded source_header and physical source ordinal. An oversized recorded header therefore restores its deterministic fallback/disambiguated operational name rather than inserting the potentially very long exact header into the alias field. A short empty/colliding source-header default still refuses rather than inventing a substitute.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.8,"Ordinary rematerialization preserves Store metadata, inherited RID, and inherited COL alias",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If a newly materialized column's exact logical key already exists in the inherited Store MAP, Data Sculptor must preserve that row's current COL alias unless the Work Order explicitly changes it. The successor MAP replaces only that logical row's column_filename with the newly created physical COL artifact filename. Ordinary rematerialization must preserve the inherited Store's exact common source_filename and rid_filename . It must not silently create a different Store, replace the Store RID, revert a user-facing Store/RID alias, or revert a COL alias to its source header. Every row in the successor MAP continues to carry that same common Store source_filename . WASM-002 has no executable operation that replaces rid_filename while preserving the same Store lineage. A different RID filename therefore cannot be introduced as ordinary successor-state continuity in this build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.9,Store MAP serialization is deterministic UTF-8 CSV,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Store MAP CSV files are encoded as UTF-8 without BOM and use LF ( 0x0A ) record termination. The exact eight-field header in W002-STOR-019.6 is written once as the first row. Fields use standard CSV quoting semantics: a field containing comma, double quote, CR, or LF is enclosed in double quotes, and embedded double quotes are doubled. No locale-dependent formatting is permitted. Every data row in one MAP must contain byte-for-byte identical values for store_alias , rid_filename , rid_alias , and source_filename . Mapping rows are written deterministically by ascending numeric source_column_number , then ascending UTF-8 byte order of source_header . Because one valid Store MAP has exactly one common source_filename , that field is not needed as a leading row-sort discriminator. Two rows with the same logical source-column key (source_filename, source_column_number, source_header) are invalid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.10,Only a complete validated Store MAP is eligible for inheritance,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A canonical MAP filename alone does not make a file a structurally valid Store MAP. For Store-MAP structural validity , the MAP artifact itself must be readable as complete UTF-8, have the exact eight-column schema, parse deterministically, satisfy Store-level consistency, lineage, deterministic row-order, mapping-key, and alias constraints, and carry structurally valid governed RID/COL filename bindings. The present health of the referenced RID/COL artifacts is a separate question and does not determine whether the MAP itself is structurally valid. A Store MAP remains part of governed Store history when its own bytes, schema, lineage facts, and deterministic structural rules are valid even if a referenced RID or COL later becomes missing or invalid. Referenced-artifact damage therefore does not make the current structurally valid Store MAP disappear and does not by itself cause fallback to an older MAP. F-03 current Store MAP selection Current-state selection is performed independently within one exact Store lineage. Only structurally valid Store MAP artifacts participate. Among those MAPs, the ordinary frozen chronology rule selects the unique structurally valid MAP with the greatest canonical UTC millisecond timestamp. A structurally malformed newer MAP is never current. If a newer canonical MAP artifact is structurally malformed, Data Sculptor uses the greatest earlier structurally valid Store MAP in that same lineage, if one exists, and reports the malformed newer artifact through governed Help/evidence surfaces. This fallback applies to structural MAP invalidity only. It does not apply merely because a structurally valid current MAP references a damaged RID or COL. If two or more structurally valid MAPs share the greatest canonical UTC millisecond timestamp, current authority is ambiguous and selection refuses rather than breaking the tie by UUID, discovery order, directory order, or filesystem modified time. P3-07 routing distinction: Store-MAP inheritance eligibility is stricter than lineage discovery. A Store lineage participates in exact- SOURCE routing when at least one Store MAP in that lineage is structurally valid, even if the current Store later evaluates DEGRADED or INVALID . Referenced RID/COL health is evaluated after routing and may cause refusal; it must not make an already discoverable lineage disappear. For successor publication, after the required RID/COL physical promotions have succeeded, Data Sculptor uses the already-established publication-transaction UTC and allocates a MAP-specific UUID before opening the complete deterministic MAP CSV under its governed SCR candidate identity. The SCR filename therefore already carries the exact UTC, UUID, and .csv extension intended for the final MAP identity. The candidate is closed successfully, reopened, and validated for bytes, schema, Store-level consistency, aliases, RID binding, COL bindings, deterministic row order, and all other MAP eligibility rules while it remains SCR . Only after that validation succeeds may Data Sculptor promote the candidate by host rename that changes only the three-letter semantic class token from SCR to MAP . The candidate bytes, UTC, UUID, and extension must remain unchanged across promotion. The successful rename is the publication/commit point. If validation or rename fails, no successor MAP becomes eligible/current; the candidate remains or is retained as visible non-authoritative SCR evidence. Store-aware automatic selection therefore continues to use the greatest earlier valid MAP in the same Store lineage, if one exists, while Help reports the failed candidate/publication rather than silently treating it as current state. P3-06 governed artifact-validation tiers. Store-health status and full content validity are distinct assurances. The following two tiers are normative for WASM-002: Tier 1 — Store-health structural validation. Used for routine Store status, source routing, historical-MAP health gates, inheritance decisions that do not consume analytical artifact contents, and alias-only maintenance. The selected Store MAP itself is fully parsed and structurally validated because it is the compact authority for the snapshot. A referenced RID passes Tier 1 only when the exact MAP-bound governed RID filename is present and readable, the bytes begin with exactly one UTF-8 BOM, the first logical record is a canonical N=<value> header, the final byte is LF, and the physical byte length equals the deterministic length implied by the canonical RID representation for that declared N . Tier 1 does not rescan every RID data record merely to perform routine status or alias work. A referenced COL passes Tier 1 only when the exact MAP-bound governed COL filename is present and readable, begins with exactly one UTF-8 BOM, exposes the canonical one-column CSV header whose decoded value exactly equals the MAP row's recorded source_header , and ends with LF. Tier 1 does not stream every COL value merely to establish routine Store health. Tier 2 — full artifact validation. Used whenever an operation actually consumes RID/COL contents, for complete validation of newly created candidates before commit, and by REPAIR MAP after the repair operation has been validly entered. A RID passes Tier 2 only when a full stream proves the canonical N=<value> header, exactly N data records, and exact ordered values 1..N . A COL passes Tier 2 only when a full stream proves canonical one-column CSV encoding/serialization, the exact expected header, and exactly N logical data records aligned to the Store RID. VALID , DEGRADED , and INVALID are Store-health states evaluated from the governed current snapshot using the required validation tier; they are not claims of cryptographic historical identity. When REPAIR MAP is validly invoked, it must perform Tier 2 validation of the RID and every mapped COL that would survive into the successor. The deterministic repair result removes exactly the mapped COL bindings that fail that Tier 2 check, subject to the separately frozen refusal when no mapped COL would remain. Two implementations presented with the same bytes must therefore identify the same repair set. External restoration boundary: a file placed back under an original governed RID/COL physical filename may re-enter use only when it passes the validation tier required by the operation. Filename equality plus governed validation is sufficient for operation eligibility under this WASM-002 boundary; it is not proof that the restored bytes are the historical original bytes. Stronger historical-byte identity requires separate authoritative fingerprint evidence. P3-10 terminology boundary: Store-state repair is REPAIR MAP . Work Order alias-registry repair is REPAIR WORK ORDER REGISTRY . These are distinct governed operations and the integrated specification must not describe a Store REPAIR MAP Work Order as a “registry-repair Work Order.” This corrects wording only; it does not change either operation's frozen semantics. F-08 / F-03 REPAIR MAP Work Order structure and target precondition: SUITCASE: .
WORK ORDER AS ""Repair Crime Store""
MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""
REPAIR MAP Exactly one MAP ""<filename>"" clause is mandatory. It names the exact physical filename of one structurally valid Store MAP. At Run time, that named MAP must be the current structurally valid Store MAP for exactly one lineage and the target Store must currently evaluate DEGRADED . A historical Store MAP, WKO MAP, missing MAP, malformed MAP, ambiguous equal-latest current state, MAP from an unsupported profile, or target Store that does not evaluate DEGRADED refuses. No SOURCE , Store/RID/COL alias selector or mutation, KEEP , materialization, conversion, Inventory, registry repair, cataloging, or composition clause is supplied in the same WKO. The analyst selects the Store by exact current Store MAP identity; Data Sculptor determines which mapped non-RID COL bindings are broken. The terminal DS-STEPS clause is REPAIR MAP ; the Receipt operation token is separately REPAIR_MAP . P2-03 monotonic eligibility boundary: structural validity/eligibility and chronology are separate. A structurally valid future-dated Store MAP remains a structurally valid MAP and participates in current-state selection. It is not demoted merely because the host clock is presently earlier. The monotonic guard applies when publishing a successor: truthful observed transaction UTC must be strictly greater than the chronology predecessor UTC before any successor state may commit. P2-04 closure — validation depth is now complete. The Tier-1/Tier-2 rules in this requirement are the complete WASM-002 oracle for deciding whether a MAP-bound RID/COL is sufficiently valid for the operation being attempted. Tier 1 is intentionally bounded and is used only by operations that do not consume RID/COL analytical contents. Tier 2 is a full streaming validation and is mandatory before an operation relies on RID/COL contents, for newly created candidates before commit, and for REPAIR MAP . REPAIR MAP determinism. Once a valid REPAIR MAP operation is entered, Data Sculptor performs Tier 2 on the Store RID and on every mapped COL. The repair successor removes exactly those mapped COL bindings whose physical COL artifacts fail Tier 2, preserves exactly those that pass Tier 2, and still refuses if zero mapped COL bindings would remain. No shallower Tier-1 result may decide the repair set. F-03 repair semantics: after target validation, Data Sculptor confirms the named MAP is current for exactly one Store lineage, confirms the referenced RID is valid, identifies every mapped non-RID COL that is missing or invalid under the required repair validation tier, preserves every valid COL binding unchanged, removes exactly the broken COL bindings from the successor candidate, preserves the exact Store lineage RID identity and remaining Store/RID metadata, validates the complete successor MAP candidate, and publishes the successor only if every repair gate succeeds. REPAIR MAP does not reread or regenerate the source CSV, rematerialize a lost COL, regenerate the RID, or edit the predecessor MAP in place. F-03 all-COLs-broken refusal: if removing the broken bindings would leave zero COL mapping rows, REPAIR MAP refuses. No zero-COL Store MAP is introduced, no special anchor row is invented, no successor MAP is published, and the Store remains DEGRADED . The existing current structurally valid MAP and RID continue to anchor the visible lineage. Identity boundary. Passing Tier 1 or Tier 2 proves only that the currently visible file under the exact governed filename satisfies the applicable WASM-002 validation contract. It does not prove that those bytes are historically identical to bytes previously present under that filename. Cryptographic historical-byte identity belongs to separately governed fingerprint evidence rather than ordinary Store health. F-15 reference-bounded eligibility: Store-MAP structural validity and inheritance eligibility are determined from the MAP artifact itself plus the governed artifacts and values that the MAP explicitly binds or that its profile explicitly requires for the validation tier being applied. Unrelated Suitcase files, unrelated Store lineages, WKOs, Receipts, Inventories, CAT/HLP/CER artifacts, analyst-owned files, directory enumeration order, and unrelated-file count cannot by their mere presence or later appearance make an already-published Store MAP eligible or ineligible. Alias-shadowing validation is a successor-publication check under W002-STOR-020; it is not a continuing ambient scan that retroactively invalidates historical MAPs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.11,The MAP-bound RID filename is the stable physical Store identity anchor in WASM-002,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, Data Sculptor does not allocate a second permanent Store UUID in addition to governed RID/MAP evidence. The exact governed rid_filename created when the Store is established is the stable physical anchor used to distinguish that Store's MAP lineage from other Stores in the same Suitcase, and every ordinary successor MAP repeats it exactly. Within any one MAP, every row must repeat the same exact current rid_filename ; disagreement is invalid. Across WASM-002 successor MAPs, a different RID filename denotes a different Store row universe and must not be silently treated as same-Store continuation. A later PRD revision may define an explicit governed recovery transition if Red5Sorcery chooses to support replacement of a damaged RID while preserving logical continuity. No such transition is executable in WASM-002.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.12,First Store MAP has deterministic Store and RID aliases,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When the first successful materialization establishes a Store, its first Store MAP must initialize store_alias to the exact common source_filename and rid_alias to the literal RID . Those are the deterministic Store and RID default aliases. A later alias-only Work Order may replace them with STORE AS ""<alias>"" and RID AS ""<alias>"" , clear them with CLEAR STORE ALIAS / CLEAR RID ALIAS , or restore these defaults with RESET STORE ALIAS / RESET RID ALIAS under W002-WKO-012.1 through W002-WKO-012.6. None of those operations changes the common source_filename , rid_filename , RID bytes, COL bytes, or prior MAP history.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-001,CAT is the governed collection-level Store Catalog artifact,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"WASM-002 shall define CAT as a governed Data Sculptor artifact class for cataloging a collection of CSV Stores inside one active Suitcase. CAT exists to let an analyst orient across many independently governed Stores without opening every MAP individually. The scaling invariant is: MAP governs locally; CAT orients globally. CAT is an index over governed Store state, not a replacement for MAP and not a second Store authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-002,CAT may reference many Stores while every MAP still governs exactly one Store,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"A CAT may contain entries for many Store lineages in the active Suitcase. Every MAP referenced by CAT still governs exactly one Store lineage under the frozen one-Store-per-MAP rule. CAT must not combine multiple Stores into one MAP, synthesize a shared Store state, or centralize Store semantics that remain governed independently by each Store's MAP lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-003,CAT has one governed CSV representation and immutable snapshot identity,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The WASM-002 Store Catalog has one durable representation: UTF-8 CSV. WASM-002 shall not emit separate HTML and CSV companion CAT artifacts for one catalog snapshot. Each successful catalog publication creates one immutable governed artifact named exactly __DS__CAT__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv . A later catalog run publishes a new CAT snapshot; earlier CAT artifacts remain visible history and are not overwritten or deleted merely because a newer snapshot exists. For orientation, the directory may identify the newest structurally valid CAT snapshot by the canonical UTC token. If two or more structurally valid CAT artifacts share the greatest canonical UTC timestamp, the UI must not invent chronology from UUID, discovery order, or filesystem modified time; it must surface the ambiguity and may present the tied CAT artifacts together until a later governed catalog run publishes an unambiguous newer snapshot. F-14 publication: CAT is first written as __DS__SCR__<UTC>__<UUID>.csv using the UTC/UUID intended for the final CAT. The complete candidate must close, reopen, and validate the exact five-column schema, deterministic row ordering, row count and CSV serialization before the class token may be renamed to CAT . A failed candidate remains SCR/non-authoritative and must not be selected as a catalog snapshot.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-004,CAT CSV schema and row order are exact and deterministic,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The canonical CAT header row is exactly: store_alias,source_filename,rid_filename,map_filename,store_health Each data row describes one routable Store lineage using values derived from the authoritative current structurally valid Store MAP selected under the existing Store rules: store_alias — current human-facing Store identity; source_filename — the one common exact source filename carried by that Store MAP and used for Store routing; rid_filename — exact immutable governed RID filename that physically identifies the Store lineage; map_filename — exact current structurally valid Store MAP used to derive the row; and store_health — the Store health evaluated during this CATALOG STORES run, exactly one of VALID , DEGRADED , or INVALID . store_health is snapshot orientation metadata, not MAP health and not an independent health authority. If the Suitcase later changes, an older CAT row continues to report the health value observed when that CAT was created. CAT rows are sorted by ascending exact UTF-8 bytes of map_filename . The header is not part of that ordering.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-005,CAT is reconstructible and never becomes Store authority,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"CAT shall be reconstructible from authoritative Store MAP artifacts and the governed Store-health evaluation applied when CATALOG STORES runs. CAT must never be consulted to decide Store routing, inheritance, Store health, repair eligibility, current MAP selection, RID/COL validity, or whether a new Store may be established. If a CAT row conflicts with authoritative MAP/Store state, current governed state wins and the CAT is stale/inconsistent. A stale CAT remains an inspectable historical governed artifact but must not be treated as current Store truth. CAT is not automatically updated by materialization, repair, alias change, or any other Store-changing operation. The analyst creates a fresh catalog explicitly by running a new CATALOG STORES Work Order; success publishes a new immutable CAT snapshot and leaves earlier CAT snapshots visible history.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-006,CATALOG STORES is the standalone governed Work Order operation,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 Work Order form is: SUITCASE: .
WORK ORDER AS ""Catalog Stores""
CATALOG STORES CATALOG STORES is one standalone top-level operation. It is initiated only by an explicit analyst Work Order. No materialization, repair, alias update, conversion, or other governed operation automatically creates, rewrites, or refreshes CAT. The operation scans authoritative governed Store MAP state, evaluates each cataloged Store's current health, and publishes one CAT snapshot plus the normal canonical Receipt. It does not mutate any Store or MAP. It must not also request materialization, conversion, alias mutation, repair, Inventory, Work Order composition, or another consequential operation in the same WKO. The canonical Receipt operation token is CATALOG_STORES .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-007,CATALOG STORES derives one row per routable Store lineage from authoritative MAP state,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The catalog scan shall identify every routable Store lineage using the same structurally-valid-MAP routing definition already frozen for WASM-002. For each routable lineage, Data Sculptor evaluates current Store health exactly under W002-STOR-019.2, using the current structurally valid Store MAP selected under W002-STOR-019.10 and the applicable validation tier, and records exactly one of VALID , DEGRADED , or INVALID . Catalog presence is orientation, not permission to perform another operation. Exactly one CAT row is emitted for each routable Store lineage, derived from that lineage's authoritative current structurally valid Store MAP and the Store-health result observed during this catalog run. If the complete authoritative collection state cannot be determined unambiguously, the operation must refuse rather than publish a knowingly incomplete or guessed CAT. CATALOG STORES is read-only with respect to all pre-existing Store, RID, COL, MAP, source, WKO, and other Suitcase artifacts. It does not repair or mutate them.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-008,CAT publication is all-or-refuse and historical CAT snapshots remain visible,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"After the complete deterministic CAT row set is established, publication follows the governed all-or-refuse artifact path: write the candidate under governed scratch, close and reopen it, validate its exact filename, UTF-8/LF CSV structure, exact header, deterministic row count/order, and row references, then promote the final CAT artifact. The CAT is not successfully published until final promotion succeeds. A publication refusal leaves prior CAT snapshots and all Store/MAP state unchanged. The Receipt records whether the catalog entry count was established and whether a final CAT filename was published.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-001,CAT and MAP discovery reuse the existing Suitcase Directory,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,WASM-002 shall reuse the existing Data Sculptor Suitcase Directory for CAT and MAP discovery and inspection. A separate CAT/MAP browser panel shall not be added.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-002,CAT and MAP artifacts are first-ranked in the existing directory,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The newest unambiguous structurally valid CAT snapshot, or any tied newest CAT candidates when chronology is ambiguous, and all Store MAP artifacts shall be surfaced prominently at the top of the existing Suitcase Directory ahead of ordinary Suitcase files. The presentation may be pinned, grouped, or otherwise first-ranked, provided the priority is obvious and deterministic.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-003,CAT and MAP contents are immediately viewable from the existing HTML UI,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,The analyst shall be able to select a visible CAT or MAP entry and inspect its contents through the existing read-only HTML UI without first locating or opening the artifact through the operating-system file browser.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-004,CAT/MAP prominence preserves ordinary read-only Suitcase filtering,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The Suitcase Directory may continue to provide read-only filtered views of other Suitcase files. CAT/MAP prominence must not remove, replace, or weaken the existing ability to inspect the rest of the flat Suitcase.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-005,Directory browsing and inspection do not require a Work Order,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"Browsing, sorting, UI filtering, selecting, opening, and viewing Suitcase files are read-only inspection actions and shall not require a Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-006,Read-only directory filtering is not governed SEARCH,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"Read-only UI filtering is not the same operation as governed SEARCH . Governed SEARCH, ZIP creation, metadata changes, repairs, CAT regeneration, and every other consequential state change remain subject to the applicable Work Order and Receipt discipline.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-007,"The directory cannot mutate CAT, MAP, Store, or Suitcase state",W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The Suitcase Directory shall not edit, rename, delete, repair, replace, regenerate, or otherwise mutate CAT, MAP, Store, or Suitcase state through direct GUI manipulation. Consequential changes occur only through explicit governed operations or analyst-owned filesystem actions already permitted by the canonical contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-008,The CAT/MAP directory view must remain practical at large collection scale,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The CAT/MAP presentation shall make collections containing dozens or hundreds of Stores practical to inspect. An analyst must be able to understand what Stores exist, which current MAP describes each Store, and which source file each Store governs without manually opening every MAP artifact through the operating-system file browser.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-ACC-001,CAT acceptance proves collection-scale orientation without centralizing Store authority,W002-CAT-ACC,W002-CAT,WASM-002,UNDER REVIEW,—,"Acceptance must include a MusicBrainz-scale fixture containing 177 routable CSV Store lineages, each with its own authoritative current Store MAP. One explicit analyst-run CATALOG STORES Work Order must publish exactly one CAT snapshot containing exactly 177 data rows under the frozen five-column schema store_alias,source_filename,rid_filename,map_filename,store_health and deterministic MAP-filename ordering. The fixture must include Stores that evaluate VALID , DEGRADED , and INVALID while retaining structurally valid current MAPs, and the CAT must record the exact health observed for each Store when the catalog run occurs. The CAT must not expose a separate MAP-health field. The existing Suitcase Directory must surface CAT and MAP artifacts ahead of ordinary files; the analyst must be able to open CAT, inspect the collection, select and view MAP artifacts, sort/filter the directory, and inspect other Suitcase files without a Work Order. No direct GUI mutation path may be exposed. Acceptance must alter authoritative MAP/Store state after the first CAT publication and prove that the earlier CAT is neither rewritten nor automatically refreshed. It remains visible and becomes stale/inconsistent where appropriate. Only a later explicit CATALOG STORES Work Order may reconstruct the collection and publish a new immutable CAT snapshot. The linked WASM-003 DIR behavior remains outside the WASM-002 implementation scope: later DIR requirements auto-populate human-readable CAT/MAP descriptions, but those descriptions never become authority over CAT, MAP, or Store semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-020,"Store, RID, and COL aliases remain human-facing metadata separate from physical identity",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Aliases are governed human-facing metadata. Creating, changing, clearing, or replacing an alias must not rename or rewrite the underlying artifact. Within one Store MAP, every non-empty COL alias and the non-empty rid_alias must be unambiguous within the row-addressable artifact alias namespace under the exact Unicode scalar-value comparison rule in PB-STOR-010. F-15 publication-time shadowing boundary: alias uniqueness and physical-name shadowing are validated when a candidate successor Store MAP is being published, against the comparison domain applicable to that one Store snapshot and the then-visible governed physical targets it makes row-addressable. If an alias would exactly collide with another addressable alias or physical filename in that publication domain, publication refuses. After a Store MAP has been validly published, the later appearance, disappearance, rename, or copying-in of an unrelated Suitcase file does not retroactively make that immutable MAP structurally invalid or ineligible. A later textual reference can still become ambiguous at resolution time under W002-STOR-021; that ambiguity causes the later operation to refuse rather than changing the historical MAP's validity. The store_alias names the Store as a whole and is separate from the field/COL alias namespace. Alias mutation occurs through a governed Work Order, not through an editable GUI field. Exact cross-Store Store-alias uniqueness and future selection-by-Store-alias syntax remain outside this freeze.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-021,Work Order resolution binds one exact Store MAP and physical targets,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A saved Work Order may refer to governed materialized columns by exact physical filename or by a unique COL alias from one selected Store MAP. The canonical explicit Store-MAP selector is MAP ""<exact Store MAP filename>"" under W002-STOR-019.3 and W002-WKO-012.3. If that clause is present and valid, exactly that Store snapshot is used. Otherwise Data Sculptor applies the Store-aware source-qualified selection rule in W002-STOR-019.2. All textual physical-filename and COL-alias comparisons in this resolution step use exact Unicode scalar-value sequence equality under PB-STOR-010: no case folding, Unicode normalization, trimming, locale equivalence, or filesystem enumeration heuristic is permitted. Resolution is bounded to the selected Store snapshot and the physical targets/aliases that are addressable through that snapshot. If the supplied text has no exact target, resolution refuses. If it has more than one exact possible target in that domain—for example because a currently visible physical filename and a current alias are both exact matches—resolution also refuses. Data Sculptor must not choose filename over alias, alias over filename, first-found entry, directory order, modified time, UUID, or any other tie-break heuristic. Before execution, Data Sculptor must record the exact physical Store MAP identity when one is used, bind the run to its exact rid_filename , and resolve aliases deterministically to physical COL artifacts. The selected Store MAP must remain fixed for the run even if a newer MAP is created during that same run. This protects Store/selection continuity but does not by itself claim that bytes stored under an analyst-owned source filename are cryptographically identical across different runs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022,Each successful Suitcase validation publishes one retained governed CER HTML certificate,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A selected directory becomes a validated Suitcase only when Data Sculptor successfully creates, completely writes, and closes one governed CER HTML Suitcase Validation Certificate in that directory. The certificate itself is the validation artifact and remains visible in the flat Suitcase as durable evidence. No validation-only delete or rename is required. Failure to create, completely write, or close the certificate means the directory has not passed Suitcase validation and analytical execution remains locked. F-14 CER exception: the CER is deliberately not staged as SCR . Suitcase validation is specifically the direct create/write/close test of the final canonical CER identity in the selected directory. Inserting an SCR-to-CER rename would test a different publication path and is therefore forbidden for this validation step. A successful CER does not pre-certify later SCR-to-final renames for other artifact classes. F-24 CER lifecycle: every successful explicit Suitcase selection and validation publishes exactly one fresh immutable CER with a new governed UTC+UUID identity. Data Sculptor must not satisfy a new validation event by reusing an earlier CER. Every prior valid CER remains a standalone historical artifact under its original governed filename and exact bytes. WASM-002 performs no automatic CER deletion, replacement, compaction, or CER-history ZIP packaging. Historical CERs are not housekeeping candidates merely because a newer CER exists. Any later archival or packaging capability must be separately governed and explicitly invoked; it is not part of the WASM-002 validation lifecycle.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.1,Suitcase Validation Certificate physical identity and longest-name path gate,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The exact certificate filename is __DS__CER__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html , using the canonical UTC millisecond token and canonical lowercase hyphenated UUID v4. Data Sculptor chooses the filename; the analyst does not supply or edit it. The CER create/write/close test begins only after the browser host has satisfied the required user-selected writable-directory capability in W002-PLAT-001. A browser that cannot expose that capability produces a host-capability refusal before folder validation; that condition is not evidence that any particular directory is unwritable or filename-incompatible. WASM-002 path/filename acceptance must derive the maximum filename length from every governed final-artifact filename form and every governed SCR staging form that this build can actually emit. Under the current contract, the maximum is 73 ASCII bytes/characters : the governed .html CER/HLP final forms and an SCR candidate reserved for a .html final artifact have that length. The canonical CER filename therefore exercises the current maximum emitted filename length during the create/write/close validation test. On a supported host, successful create/write/close of this canonical governed HTML filename is the WASM-002 folder filename/path compatibility test for the current emitted-name maximum. Data Sculptor does not maintain a product-level table of operating-system numeric path maxima and must not truncate, abbreviate, hash-shorten, or otherwise mutate a governed filename to fit a host path limitation. If the certificate cannot be created under its canonical name after a directory has actually been selected through the supported-host contract, the selected directory does not pass validation. If a future PRD revision introduces an emitted final or staging filename longer than the current CER/HLP/SCR-HTML maximum, acceptance must detect that change and explicitly exercise the new maximum before the build may rely on this path-compatibility claim.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.2,Suitcase Validation Certificate semantic content,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The HTML certificate uses the canonical built-in Data Sculptor presentation and must visibly contain, at minimum: SUITCASE VALIDATION CERTIFICATE RESULT: PASS SUITCASE: . UTC: <canonical certificate UTC> UUID: <certificate UUID> ARTIFACT: <full governed certificate filename> TEST: CREATE_WRITE_CLOSE It must state that Data Sculptor successfully created, completely wrote, and closed this governed HTML certificate in the selected Suitcase. It must state that this establishes that the selected directory was writable by Data Sculptor at the recorded UTC and accepted the governed artifact filename used for the certificate. It must also state that the certificate does not certify available disk capacity, guarantee success of future analytical operations, or certify later SCR -to-final-class publication/rename operations. The semantic record uses SUITCASE: . and must not persist an absolute machine-specific path merely to prove validation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.3,Suitcase Validation Certificate uses the canonical built-in presentation in WASM-002,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The certificate is a human-facing HTML CER artifact and uses the canonical built-in Red5Sorcery/Data Sculptor presentation in WASM-002. Presentation must never change RESULT , SUITCASE , UTC, UUID, artifact identity, TEST , validation meaning, or limitation facts. Configurable Brand Manifest application to CER artifacts is deferred to V1-BACKLOG / a future build and is not required for WASM-002 Suitcase validation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-023,Non-Store governed artifacts use class-specific all-or-refuse publication profiles,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Except for the deliberate CER Suitcase-validation path below, WASM-002 does not place a newly generated durable artifact into its final semantic class merely because candidate bytes exist. The complete candidate is first written under the governed SCR identity defined by W002-STOR-023.1, closed, reopened, and validated against the target class contract. Only a candidate that passes its class-specific publication predicate may be renamed into the intended final class. A final-class filename therefore records successful class publication, not broader authority where a separate MAP/registry relationship governs authority. F-33 reserved-class boundary: DGN , RCV , BRD , and LCK are registered but not emitted by WASM-002, so they do not appear as publication profiles in this table and have no WASM-002 producer here. Final class Final serialization / identity Publication predicate Authority boundary WKO __DS__WKO__<UTC>__<UUID>.txt The complete candidate obeys the saved-Work-Order lifecycle and parses completely under exactly one WASM-002 executable operation grammar with the required SUITCASE: . , exactly one non-whitespace WORK ORDER AS alias, and the governed lexical/comment rules. Applicable save-time alias/registry gates must also pass before the save transaction may commit. Promotion proves a valid immutable WKO artifact. Alias-registry authority is not committed until the complete successor WKO MAP is successfully published under W002-STOR-018.3. RCP __DS__RCP__<UTC>__<UUID>.txt The complete candidate validates against W002-RCP-005 through W002-RCP-008: exact deterministic TXT serialization, common envelope, applicable operation-specific key table, governed absence semantics, and created-artifact tail. Publication creates durable run evidence only. It does not retroactively create or change analytical state. HLP __DS__HLP__<UTC>__<UUID>.html The complete self-contained HTML satisfies the HLP disclosure, presentation, provenance, embedded-JSON, lineage and semantic-parity rules in W002-HELP-009 and related Help requirements. Publication creates durable Help/support evidence. It does not override the underlying diagnostic event or analytical state. CVT __DS__CVT__<UTC>__<UUID>.csv The bounded Windows-1252 conversion completes, the original analyst-owned source remains unchanged, the converted bytes pass the governed strict UTF-8 requirement, and the candidate closes/reopens successfully. Structural CSV interpretation remains a later certification/materialization concern. The published exact CVT filename is a new immutable governed source identity for later routing under W002-CONV-004. INV __DS__INV__<UTC>__<UUID>.txt The complete inventory scan has established the governed entry set and the candidate validates the deterministic INV serialization, count, metadata availability and ordering rules. Publication creates an immutable inventory snapshot; it is evidence/orientation, not Store authority. CAT __DS__CAT__<UTC>__<UUID>.csv The authoritative MAP discovery/evaluation pass has completed and the candidate validates the exact five-column CAT schema, row count, row ordering and deterministic CSV rules. Publication creates an immutable collection-level orientation snapshot. MAP remains authoritative for each Store. CER __DS__CER__<UTC>__<UUID>.html Deliberate exception: Suitcase validation directly creates, completely writes and successfully closes the final CER identity under W002-STOR-022 through W002-STOR-022.3. No SCR staging/rename is inserted into this test. The CER proves that canonical governed create/write/close succeeded in the selected directory at that recorded moment. It does not pre-certify later SCR-to-final publication. RID, COL, Store MAP and WKO MAP publication retain their specialized transaction/commit rules elsewhere in this PRD. W002-STOR-023 does not replace those state-publication contracts; W002-STOR-023.1 supplies the shared SCR candidate identity and retained-failure-evidence boundary they may reference.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-023.1,SCR candidates preserve intended final identity; retained failure evidence remains non-authoritative,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical candidate filename for a staged governed artifact is: __DS__SCR__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.<final-extension> The SCR candidate uses the exact UTC token, UUID and extension reserved for its intended final artifact. Successful publication changes only the three-letter semantic class token from SCR to the intended final class. For example, an RCP candidate __DS__SCR__20261006T190000000Z__<uuid>.txt may become __DS__RCP__20261006T190000000Z__<uuid>.txt only after the complete candidate has been closed, reopened and validated against the RCP publication predicate. The rename must not alter candidate bytes, UTC, UUID or extension. An SCR filename never by itself confers final-class validity, Store membership, registry authority, execution authority, or durable final-class evidence status. A retained SCR whose bytes happen to satisfy a target validator after an interrupted or refused transaction must not be auto-promoted, silently adopted, or treated as if the missing publication step occurred. F-33 retained-failure-evidence boundary: when a handled failure leaves one or more SCR candidates or other staged bytes that cannot be safely removed or restored, they must remain visible only as non-authoritative SCR evidence. WASM-002 does not publish an RCV recovery manifest. Retention must not complete or simulate the failed publication step, and the governed diagnostic/Help path must report the failure using only facts actually established. A retained or orphaned SCR remains non-authoritative even if its bytes later validate. Data Sculptor must not infer an intended final class solely from extension or byte content, must not rename or promote the SCR merely because it survives a later scan, and must not create a replacement RCV sidecar to manufacture attribution that the failed transaction did not durably preserve.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-011; CP-012; CP-013; CP-014; CP-015,"CP011 T-ACCEPTED, GIT BANKED — exact CVT-to-SCR candidate identity derivation only; full SCR lifecycle and publication contract remains open; CP012 T-ACCEPTED, GIT BANKED — canonical SCR staging filename recognition only; generic publication, recovery and authority remain unimplemented; CP013 T-ACCEPTED, GIT BANKED — explicit SCR-to-RCP final filename candidate derivation only; no complete SCR lifecycle, RCP validator, filesystem promotion, publication or authority; CP014 T-ACCEPTED, GIT BANKED — related RCP final-candidate lexical recognition only, no SCR creation or publication; CP015 T-ACCEPTED, GIT BANKED — pure lexical canonical SCR-to-RCP TXT filename-candidate pair matching only; no actual file/Receipt validation, promotion, publication or authority",e84ae5baeee05f9d5d30284c65b86eebba3c0f6a; efca04392940e398020a5c06b9ee50296c8a1fdd; 005a38ef5e876847c4c08901c18da9c18565fd6b; f5038a183f1d3dc31b0065571bf8ac8814b5d8a9; be997dc0dbd65fc370814c4a5f2d0f1254870572,"Evidence/CP-011/CP011_Scope_Lock.txt; Evidence/CP-011/CP011_RED_Test_Output.txt; Evidence/CP-011/CP011_GREEN_Test_Output.txt; Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt; Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt; Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt; Evidence/CP-011/CP011_Hash_Inventory_Verification.txt; Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt; Evidence/CP-011/CP011_Closing_Git_Review.txt; CP011_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-012/CP012_Scope_Lock.txt; Evidence/CP-012/CP012_RED_Test_Output.txt; Evidence/CP-012/CP012_GREEN_Test_Output.txt (initial 5/6, retained); Evidence/CP-012/CP012_GREEN_Failure_Triage.txt; Evidence/CP-012/CP012_GREEN_Correction_Review.txt; Evidence/CP-012/CP012_GREEN2_Test_Output.txt; Evidence/CP-012/CP012_Full_Regression_Test_Output.txt; Evidence/CP-012/CP012_WASM_Build_Output.txt; Evidence/CP-012/CP012_Final_Rustfmt_Check.txt; Evidence/CP-012/CP012_Hash_Inventory_Verification.txt; Evidence/CP-012/CP012_Supplementary_Hash_Verification.txt; Evidence/CP-012/CP012_Post_Staging_Hash_Verification.txt; Evidence/CP-012/CP012_Closing_Git_Review.txt; CP012_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-013/CP013_Approved_Scope_Lock.txt; Evidence/CP-013/CP013_RED_Test_Output.txt; Evidence/CP-013/CP013_GREEN_Test_Output.txt; Evidence/CP-013/CP013_Full_Regression_Test_Output.txt; Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt; Evidence/CP-013/CP013_WASM_Build_Verification.txt; Evidence/CP-013/CP013_Hash_Inventory_Verification.txt; Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt; Evidence/CP-013/CP013_Closing_Hash_Verification.txt; Evidence/CP-013/CP013_Final_Staging_Verification.txt; Evidence/CP-013/CP013_Closing_Git_Review.txt; CP013_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip; CP014_Git_Banking_Record.txt (external closeout); Evidence/CP-015/ZIP/CP015_RED_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_GREEN_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_PostAmend_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_Full_Regression_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_WASM_Build_Output.txt.zip; Evidence/CP-015/ZIP/CP015_Final_Archive_Manifest.txt.zip; CP015_PostCommit_Verification.txt (external closeout)","CP011 Day066: public pure helper build_scr_candidate_filename_for_cvt(&str)->Option<String> accepts an exact canonical governed CVT .csv filename (via CP010 recognizer) and derives the paired SCR filename by substituting only class token CVT -> SCR, preserving exact UTC, UUIDv4 and lowercase .csv bytes; rejects wrong classes, paths, whitespace, malformed clock/date/UUID, extension and class case. Six targeted tests; RED expected E0432 exit 101; GREEN 6/6; post-format native regression 46/46; rustfmt recheck PASS; Rust 1.97.1 wasm32-unknown-unknown --lib build PASS; original 28/28 and combined 36/36 SHA-256 records verified. Two local scoped .gitattributes whitespace exceptions preserve Rustfmt/Git diagnostic TXT bytes; final Git staged check PASS. T-approved and Git banked e84ae5baeee05f9d5d30284c65b86eebba3c0f6a, 27 committed files, working tree clean. Lexical candidate-name pairing ONLY; no SCR creation, bytes, converter, transaction, close/reopen, validation/publication, retained SCR adoption, SOURCE authority or browser execution. Independent Claude implementation QA pending. CP012 Day066: pure public bool recognizer is_canonical_scr_filename_candidate(&str) validates exact uppercase SCR staging class via shared canonical immutable filename-token parser, with local rejection of whitespace and both path separators; accepts canonical .csv and .txt SCR candidates without assuming extension or bytes confer intended final class, validity, publication or authority. RED expected missing import E0432 exit 101. Initial GREEN 5/6 exposed trailing whitespace acceptance through generic extension grammar, retained verbatim; controlled CP012-local correction yielded 6/6 PASS. Full native regression 52/52 PASS, Rustfmt 12 Rust files checked/0 modified, canonical Rust 1.97.1 wasm32-unknown-unknown --lib build PASS (not browser execution). Primary independent SHA256/size inventory 29/29 PASS; supplementary original 4/4 PASS; post-staging 6-record amendment independently verified following narrowly scoped trailing-space and blank-at-EOF git attributes for preserved diagnostic evidence; final staged Git whitespace exit 0. T approved and banked Git commit efca04392940e398020a5c06b9ee50296c8a1fdd (28 committed files; master clean). Previous generic canonical parser unchanged. W002-STOR-023.1 remains PARTIAL, no filesystem creation, close/reopen, class publication, retained/orphan SCR adoption or recovery, SOURCE authority, or independent Claude implementation QA claimed. CP013 Day066: pure public function build_final_filename_candidate_for_scr(&str, &str)->Option<String> accepts only a canonical SCR staging filename with exact lowercase .txt serialization and explicit intended_final_class == ""RCP""; derives RCP final filename candidate by substituting the SCR semantic-class token only, preserving original UTC token, UUID and extension. Rejects all other class intentions, malformed or non-SCR staging names, paths/whitespace, wrong extension or case. Six intentional RED tests (unresolved E0432 before implementation), six GREEN targeted passes; full native 58/58 PASS; Rust 1.97.1 rustfmt check PASS and wasm32-unknown-unknown --lib build PASS (not browser runtime). Primary 21/21, supplementary 27/27 before attribute revisions; post-normalization 32/32 and closing 37/37 SHA-256 identity/byte-preservation checks; 42/42 commit blobs verified, Git whitespace check exit 0 after directory-scoped CRLF-aware whitespace attributes and raw-byte preservation; staging failures and adjustments retained byte-for-byte. T accepted and Git banked 005a38ef5e876847c4c08901c18da9c18565fd6b (efca04392940e398020a5c06b9ee50296c8a1fdd parent), 42 files, clean tree and index. This covers only lexical candidate-name derivation under already-PARTIAL W002-STOR-023.1; W002-STOR-023 remains NOT_STARTED; no SCR creation, RCP contract validation, promotion, publication, retained/orphan handling, authority or recovery. No independent adversarial QA or accepted end-to-end requirements; Day066 OPEN. CP014 Day067: T-accepted, Git-banked lexical RCP .txt filename recognizer only. Pure is_canonical_rcp_filename_candidate(&str)->bool uses shared canonical envelope, rejects wrong class/extension/casing, malformed UTC/UUID, paths and whitespace. Six target GREEN passes; 64/64 native regression; Rustfmt and wasm32 library build PASS; 32 original-TXT-per-ZIP objects validated and committed unchanged. Commit f5038a183f1d3dc31b0065571bf8ac8814b5d8a9. No new Receipt timestamp generation, Receipt byte serialization, creation/promotion/publication or authority; independent implementation QA and browser runtime pending. CP015 Day067: T-approved pure is_matching_scr_rcp_filename_candidate_pair(&str,&str)->bool checks canonical SCR/RCP lowercase .txt candidates and exact timestamp/UUID pairing, reusing existing lexical recognizers and candidate derivation; rejects wrong classes/order, mismatched timestamps/UUID, paths, whitespace and noncanonical envelopes. Expected RED E0432 exit 101; six targeted GREEN PASS; T-approved formatting-only source+test amendment and recheck; full native regression 70/70 PASS, Rustfmt PASS, Rust 1.97.1 wasm32-unknown-unknown --lib compile PASS. Original TXT archived as 16 verified single-entry ZIPs; 18/18 committed Git blob identities checked; working tree clean. Banked at be997dc0dbd65fc370814c4a5f2d0f1254870572. No actual SCR/RCP file reads, Receipt content validation, timestamp generation, authority, promotion or publication; browser execution and independent implementation QA pending.",Day067,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001,Strict whole-file UTF-8 certification,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Before WASM-002 performs analytical CSV materialization, it must certify the complete selected source as valid UTF-8 using bounded processing.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.1,"Certification must examine the entire source, not merely a prefix, sample, BOM, or first analytical window.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.2,"UTF-8 validity must be determined across chunk boundaries, including incomplete multi-byte sequences that span adjacent input windows.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.3,"A UTF-8 BOM, when present, is parsing metadata and must not be treated as proof that the remainder of the source is valid UTF-8.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.4,Certification must preserve exact source-byte accounting.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.5,Certification must operate within the governed WASM memory budget.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Stage 1 UTF-8 certification must remain bounded independently of source byte length and must not buffer the complete source, CSV header, or CSV row set in memory. CSV column-count and operational-name rules belong to Stage 2 and must not be used to justify unbounded Stage-1 state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.6,Certification must produce deterministic PASS or FAIL for the same source bytes under the same frozen rules.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002,UTF-8 certification is a hard analytical gate,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,The WASM-002 analytical/materialization path must proceed only after successful UTF-8 certification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.1,"If UTF-8 certification fails, the current analytical Work Order must stop.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.2,The analytical engine must not silently switch to another decoder.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.3,The analytical engine must not continue materialization under an inferred or guessed source encoding.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.4,No Windows-1252 transcoding may occur as an implicit sub-step of the failed analytical Work Order.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003,Certification and materialization share one run-local selected source,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"For a governed WASM-002 analytical run, the browser host must resolve the Work Order source reference once and retain the same selected source instance across Stage 1 UTF-8 certification and Stage 2 materialization. The purpose of this binding is to prevent Stage 2 from accidentally consuming a different source than the one Stage 1 certified. It is a run-local continuity guarantee, not a claim of durable cryptographic identity across separate runs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.1,Stage 2 must not re-resolve or substitute the source,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"After Stage 1 begins, Stage 2 must not reacquire the analytical source by re-reading an alias mapping, re-resolving a filename/path, opening a newly selected browser file, or otherwise substituting another source instance. Stage 2 consumes the source instance already bound to the governed run.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.2,"Filename, alias, path, or byte length alone is not durable byte identity",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Filename equality, alias equality, path equality, timestamps, or exact byte length may be useful provenance facts but must not be presented as cryptographic proof that source bytes are identical across separate runs. WASM-002 makes no such automatic cross-run exact-byte claim.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.3,Ordinary WASM-002 source binding does not require automatic SHA-256,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,UTF-8 certification and ordinary column materialization must not automatically compute SHA-256 merely to establish WASM-002 source binding. The source-binding requirement is satisfied by preserving the same run-local selected source instance across the two stages. This rule does not prohibit SHA-256 where another explicit WASM-002 requirement governs integrity for a specific generated artifact. It applies to automatic hashing of ordinary analytical source data.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.4,Loss of run-local source continuity causes refusal,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"If the browser host cannot preserve the selected source instance from certification into materialization, or the source becomes unavailable before Stage 2 can consume it, the analytical run must refuse before materialization rather than silently reselect, substitute, or infer another source.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004,ASCII-first inline UTF-8 certification algorithm,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"WASM-002 must use an ASCII-first, strict inline UTF-8 certification algorithm or an equivalent implementation that preserves the same single-forward-scan semantics, bounded state, deterministic validity result, exact error location, and performance intent established by WASM-001b.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.1,The certifier must process the source in bounded windows and must not allocate memory proportional to source-file size.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.2,"The 4 MiB window used in WASM-001b is a proven reference point, not a frozen WASM-002 production constant.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Window size may be changed only if semantics and byte-identical certification outcomes remain invariant.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.3,"At the beginning of each window, any incomplete UTF-8 sequence carried from the preceding window must be resolved before the remaining bytes are treated as independent input.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.4,"When there is no pending cross-window sequence, consecutive bytes below 0x80 must be recognized as ASCII and certified directly because ASCII is a complete subset of UTF-8.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.5,An all-ASCII window with no pending cross-window sequence must be certifiable without submitting the same bytes to a second general UTF-8 decoder pass.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.6,"When a byte at or above 0x80 is encountered, the certifier must validate the UTF-8 sequence inline, then resume the ASCII-fast scan after the valid sequence.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.7,"The implementation must not require collecting all non-ASCII bytes, all non-ASCII runs, or all non-ASCII offsets for later validation.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.8,The implementation must not require a separate general-purpose string-decoder call for each non-ASCII sequence.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,An equivalent low-overhead strict validator is acceptable if it preserves the same governed result and bounded-state behavior.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.9,Cross-window state must be bounded to the information required for at most one incomplete UTF-8 sequence.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"No more than three source bytes may need to remain pending between windows, or an equivalent smaller state representation may be used.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.10,"On the first invalid UTF-8 sequence, certification must stop and report the exact absolute source-byte offset required by the frozen error contract.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"On the first invalid UTF-8 sequence, certification must stop and return FAIL . The governed UTF-8 refusal evidence is: FIRST_INVALID_BYTE_OFFSET — the zero-based absolute byte offset of the first byte of the invalid sequence , counted from the first physical source byte, including a permitted leading UTF-8 BOM when present; and STOP_REASON — exactly INVALID_UTF8_SEQUENCE . For an EOF-truncated multibyte sequence, FIRST_INVALID_BYTE_OFFSET is the absolute offset of that incomplete sequence's lead byte, not the EOF position. The certifier need not read the remainder of an already-invalid source. Input-window boundaries must not change the outcome, stop reason, or first-invalid offset. F-16 follow-on boundary: stopping strict UTF-8 certification at the first invalid sequence does not make the remainder of the source irrelevant to conversion advice. When the governing operation is MATERIALIZE and Stage 1 reaches FAIL , the analytical run remains refused; Data Sculptor then starts the separate read-only compatibility assessment in W002-CONV-002 from physical byte offset 0 of the same bound source instance. That second pass may read to EOF solely to determine converter compatibility. Stage 2 must not start.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.11,"At EOF, certification may return PASS only if every source byte has been consumed under the strict UTF-8 rules and no incomplete sequence remains pending.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"At EOF, certification may return PASS only if every physical source byte has been consumed under the strict UTF-8 rules and no incomplete sequence remains pending. The completed Stage-1 outcome vocabulary is exactly PASS and FAIL . PASS means strict whole-source UTF-8 certification completed successfully. FAIL means an invalid UTF-8 sequence was deterministically established under W002-ENC-004.10. The common Receipt absence tokens remain separate from those completed outcomes: NOT_RUN when Stage 1 never begins, and NOT_AVAILABLE when Stage 1 begins but a separate failure prevents a governed PASS/FAIL conclusion. NOT_APPLICABLE is not a completed value for STAGE1_UTF8_OUTCOME .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.12,"A UTF-8 BOM at absolute source offset zero may be recognized as BOM metadata after its bytes are validated, but the remaining source must still undergo complete certification.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.13,"The certifier must not perform CSV delimiter, quote, header, row, or analytical interpretation.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Certification answers only whether the complete source byte stream is valid UTF-8 under the frozen rules.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.14,Certification results must be independent of window boundaries.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Splitting the same valid or invalid source at different bounded window sizes must not change PASS/FAIL or the first invalid absolute byte offset.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.15,"The certifier must expose enough measured counters for acceptance evidence to reconcile source bytes read, windows/pushes processed, non-ASCII sequences encountered when counted, final pending state, and stop reason without requiring those counters to alter certification semantics.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005,Strict UTF-8 byte-sequence rules,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"The inline validator must implement strict modern UTF-8 validity, excluding overlong forms, UTF-16 surrogate code points, values above U+10FFFF, invalid lead bytes, invalid continuation bytes, and truncated sequences. F-07 stop-reason vocabulary: all strict UTF-8 invalidity classes governed by this requirement—lone continuation bytes, malformed continuation sequences, overlong forms, surrogate encodings, values above U+10FFFF, invalid lead bytes, and EOF-truncated sequences—serialize the single machine reason token INVALID_UTF8_SEQUENCE . The specific fixture category is acceptance evidence; the canonical stop reason intentionally does not duplicate validator-library-specific subcodes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.1,Single-byte ASCII is 0x00 through 0x7F.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.2,Two-byte sequences must begin with 0xC2 through 0xDF and be followed by exactly one continuation byte 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.3,"Three-byte sequences beginning with 0xE0 must use a second byte 0xA0 through 0xBF and a third byte 0x80 through 0xBF, preventing overlong encodings.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.4,Three-byte sequences beginning with 0xE1 through 0xEC or 0xEE through 0xEF must use two continuation bytes 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.5,"Three-byte sequences beginning with 0xED must use a second byte 0x80 through 0x9F and a third byte 0x80 through 0xBF, excluding UTF-16 surrogate halves.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.6,"Four-byte sequences beginning with 0xF0 must use a second byte 0x90 through 0xBF followed by two continuation bytes 0x80 through 0xBF, preventing overlong encodings.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.7,Four-byte sequences beginning with 0xF1 through 0xF3 must use three continuation bytes 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.8,"Four-byte sequences beginning with 0xF4 must use a second byte 0x80 through 0x8F followed by two continuation bytes 0x80 through 0xBF, preventing code points above U+10FFFF.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.9,Bytes 0x80 through 0xBF are invalid when encountered as lead bytes.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.10,Bytes 0xC0 and 0xC1 are invalid lead bytes because they can only introduce overlong encodings.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.11,Bytes 0xF5 through 0xFF are invalid UTF-8 lead bytes.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"ASCII-first inline UTF-8 certification algorithm READ NEXT BOUNDED WINDOW Reference evidence used 4 MiB windows RESOLVE PENDING CROSS-WINDOW STATE At most one incomplete UTF-8 sequence ASCII FAST SCAN Advance cheaply while every byte < 0x80 ASCII RUN Already valid UTF-8 RESUME SCAN Same window BYTE >= 0x80 Validate sequence inline STRICT UTF-8 Lead + continuation range rules VALID END OF WINDOW? Persist only bounded carry state MORE SOURCE? Yes: read next window; No: finish EOF + NO PENDING STATE UTF-8 PASS INVALID OR TRUNCATED UTF-8 FAIL No full-file allocation. No collection of all non-ASCII bytes. No per-sequence general string decode required. Figure 2. The WASM-001b-derived fast path certifies ASCII directly, validates only non-ASCII sequences inline, and carries only bounded state across windows.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-006,Measured evidence inherited from WASM-001b,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"The following measurements are non-normative evidence explaining why WASM-002 begins with the ASCII-first inline algorithm. They are not WASM-002 acceptance results and must not be represented as such. EVID-W001B-UTF8-001 On the 7,250,808,204-byte Statistics Canada source, the Day 039 distribution experiment observed 659,103 non-ASCII bytes, approximately 0.009090063% of the file, across 329,551 non-ASCII runs/sequences; the maximum observed non-ASCII run was three bytes. EVID-W001B-UTF8-002 The Day 039 non-ASCII-only experiment submitted only 659,103 bytes to strict UTF-8 validation and completed in 12.664716 seconds at 545.998 MiB/s; it proved the source valid but still incurred 329,551 strict validation calls. EVID-W001B-UTF8-003 A 1 GiB A/B test showed that reducing validated bytes alone was not enough: the selective per-run strategy submitted 115,839 bytes in 57,919 strict calls but took 503.7536 ms, while the baseline submitted 113,246,208 bytes in 27 strict calls and took 411.3590 ms. UNRESOLVED SOURCE DAMAGE: preserved authoritative text continues “This supported removing per-run general-validator call overhead rather than merely shrinking” but the remainder has not been recovered. No missing words are inferred or supplied. EVID-W001B-UTF8-004 The final native inline scan certified all 7,250,808,204 bytes in 10.377870 seconds at 666.313 MiB/s, observed 329,551 non-ASCII sequences and 659,103 non-ASCII bytes, and made zero std::str::from_utf8 calls. EVID-W001B-UTF8-005 The same inline design was exercised in Microsoft Edge/WASM with 4 MiB transfers: the valid 7,250,808,204-byte source completed with 1,729 pushes, UTF8_VALID=true, and EOF_ALL_BYTES_VALID. That experimental run took 30.5858 seconds including file I/O, JS-to-WASM copy, and WASM validation. EVID-W001B-UTF8-006 A full-size deliberately invalid Edge/WASM fixture stopped early after 2,936,012,800 bytes and 700 pushes with UTF8_VALID=false and STOP_REASON=INVALID_UTF8_SEQUENCE rather than reading to EOF. EVID-W001B-UTF8-007 WASM-001b also retained malformed UTF-8 fixtures for stray legacy bytes, truncated sequences, lone continuation bytes, overlong encodings, UTF-16 surrogate halves, and 0xFE/0xFF invalid bytes. WASM-002 should reuse or regenerate equivalent acceptance fixtures with known invalid offsets.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001,Stage 2 consumes the source instance certified by Stage 1,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The structural CSV parser and materializer operate under the explicit invariant that the same run-local selected source instance has already passed governed whole-file UTF-8 certification. Stage 2 must not independently re-resolve the analytical source. Stage 1 establishes encoding validity. Stage 2 establishes CSV structure, row identity, selected values, and governed outputs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.1,Stage 2 must not independently re-decide the source encoding.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.2,Stage 2 must not contain an automatic Windows-1252 fallback.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.3,Stage 2 may perform only those byte/character checks required for correct CSV structural parsing and frozen analytical semantics.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.4,"Any implementation shortcut that would weaken the certified-source invariant must be treated as a PRD change, not an optimization.",W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.5,Stage 2 restarts at byte offset zero of the same certified source instance,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"After Stage 1 returns PASS, Stage 2 must begin its structural pass from absolute source byte offset zero using the same run-local selected source instance. Rewinding/re-reading the existing source handle is permitted; performing a new filename, alias, path, picker, or directory resolution is not. If the host cannot re-read that same selected source instance for Stage 2, the Work Order must refuse under the run-local source-continuity contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.6,Stage 2 consumes an offset-zero UTF-8 BOM as metadata before header parsing,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"If the certified source begins with the UTF-8 BOM bytes EF BB BF , Stage 2 must consume those three bytes before parsing the first CSV header field. They must not become part of the first source header or selected value. The BOM is recognized only at absolute source offset zero. The fact that Stage 1 already saw the BOM does not permit Stage 2 to skip or reinterpret arbitrary later bytes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.7,Stage 2 parses the header once and then continues directly into the data-record scan,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Within the Stage 2 forward source scan, Data Sculptor must parse the complete first logical CSV record as the source header, construct ordered header metadata including exact decoded header text and 1-based source ordinal, resolve and validate all Work Order selectors/aliases, and then continue from the first data record without restarting the source. Header resolution therefore does not add a third whole-file pass. A header-only valid CSV yields a zero-row materialization; a source with no valid header record refuses. P3-09 no-header-record refusal: after Stage 1 has certified the source, if Stage 2 reaches end-of-source without establishing any logical CSV record from which a header could be parsed, materialization must refuse with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD . This is the eighth governed Stage-2 structural CSV refusal token in the canonical oracle defined by W002-MAT-002.8. Its governed location facts are: CSV_SOURCE_BYTE_OFFSET = exact source byte length; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; CSV_FIELD_ORDINAL: 1 . Therefore a zero-byte source reports offset 0 , and a source containing only the UTF-8 BOM bytes EF BB BF reports offset 3 . A first logical record that exists but is blank remains governed by the already-frozen BLANK_LOGICAL_RECORD condition and must not be reclassified as NO_HEADER_RECORD . F-20 source-width boundary: the established header record may contain at most 16,384 physical source columns. Exactly 16,384 is valid; a header record containing 16,385 or more fields must refuse deterministically during header resolution before the first data record is consumed. The bound applies to the complete physical source width, not merely the requested KEEP set. Header processing must remain bounded. Exact decoded source-header text is authoritative source evidence and must be preserved for every selected/materialized column, but the implementation is not required to retain the complete decoded text of every unselected header after selector resolution when bounded metadata is sufficient.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.8,Stage 2 relies on Stage 1 UTF-8 validity rather than revalidating the file,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 must not run a second whole-file UTF-8 certification algorithm over the source. It may inspect bytes and decoded field content only as required for CSV structure, header/selector semantics, governed field-size limits, output serialization, and diagnostics. Any implementation that reintroduces redundant whole-source UTF-8 validation into Stage 2 is a measurable architectural regression unless separately justified and accepted.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002,One-pass multi-column materialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"A valid Work Order may request multiple source columns for materialization during the same bounded structural pass. For WASM-002 DS-STEPS, the requested set is expressed by one KEEP block containing one or more HEADER and/or COLUMN selectors under W002-STEPS-001 through W002-STEPS-004. F-20 KEEP-width boundary: one governed KEEP block may resolve from 1 through 16,384 distinct source columns, subject to the source itself containing no more than 16,384 columns. An empty KEEP or a request that cannot resolve within that bound refuses before data-row materialization.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.1,Requested columns must be resolved and validated before data-row materialization begins,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Every HEADER and COLUMN selector in the governed KEEP block must resolve to exactly one source column before any data-row materialization begins. Missing headers, ambiguous duplicate-header matches, invalid/out-of-range ordinals, duplicate resolved selections, invalid aliases, and successor-MAP alias collisions must refuse before the structural data-row pass. The resolved selection cardinality must be an integer from 1 through 16,384 . Resolution/validation must finish before the first data record is consumed, including operational-name/default-alias derivation and any deterministic oversized-header fallback required by W002-STOR-019.7.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.2,All selected columns are emitted from one forward data-record scan,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"After header/selector resolution, Stage 2 must traverse the source data records once regardless of whether the Work Order selects one column or many. The engine must not perform one complete source rescan per requested column. During that scan, every source field is interpreted structurally, but only the fields required by the resolved selection set are materialized into governed COL outputs. F-20 one-pass boundary: “one forward data-record scan” means one traversal of the source data records for the MATERIALIZE operation. WASM-002 must not reread source data records in batches merely because the selected-column set is wide. An implementation may perform additional bounded passes over Data-Sculptor-owned SCR , spool, or staging structures after the source scan when needed to finalize many outputs within resource limits; such passes must not reread the source data records or change governed output semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.3,One 1-based logical row ordinal aligns every selected output,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The header is not a data row. The first accepted logical data record is row identity 1, the next is 2, and so on through N. The row counter advances exactly once per accepted logical CSV data record, not per physical line. Every selected COL produced by the run must contain exactly one logical data record for each accepted source data row and therefore exactly N data records in the same governed order. A multiline quoted field remains part of one logical record and must not advance row identity merely because it contains physical newline bytes. When the run establishes a new Store, this 1..N sequence is published as that Store's one governed RID artifact. When the run extends an existing Store without changing its row universe, the existing RID is reused and must not be regenerated or renumbered.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.4,Selected-column writer order follows resolved KEEP order,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Before the data-record scan begins, the validated selection set is placed in the same order in which its selectors appear in the governed KEEP block. That resolved order governs writer creation, per-row selected-field dispatch, progress/receipt presentation, deterministic backpressure-drain priority, and candidate COL identity allocation. The Store MAP's own CSV mapping-row ordering remains governed separately by W002-STOR-019.9 and must not be confused with Work Order selection order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.5,Multiple active COL outputs use bounded staging and explicit backpressure,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Each active materialized-column writer, or an equivalent shared multiplexed output structure, must have bounded staging capacity. The aggregate kernel-owned staging state for all active writers must remain inside the governed WASM memory budget and must not grow with source row count or total output size. If a required output writer cannot accept additional canonical bytes without exceeding its governed staging capacity, source consumption must pause while pending output is drained/written. When more than one writer requires service, drain priority follows resolved KEEP order. After sufficient space is available, parsing resumes from the same structural state. The exact tuned staging-buffer size is an implementation/benchmark constant rather than an analytical semantic constant; changing it must not change output bytes, row identity, selection results, or diagnostics for the same governed input. F-20 writer-resource bound: KEEP width and simultaneously active writable resources are distinct. The accepted build must declare a finite implementation bound on simultaneously active writable-output resources and retain acceptance evidence of both that configured bound and the observed peak. The engine may satisfy a wide selection by bounded shared/multiplexed staging or a Data-Sculptor-owned spool followed by bounded finalization passes, but it must not require one simultaneously open writer per selected column. Changing the writer-resource bound must not change final bytes, row order, selection identity, aliases, Receipts, or diagnostics for the same governed input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.6,Partial output sets are never published as a successful materialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"All requested materialized-column outputs begin as visible governed SCR candidates, not COL artifacts. On first materialization of a new Store, the automatically generated RID likewise begins as a governed SCR candidate. Before any new RID/COL SCR candidate is opened, Data Sculptor establishes one publication-transaction UTC under PB-STOR-013/PB-STOR-014 and allocates a distinct artifact-specific UUID for each new candidate. Each candidate filename therefore already carries the exact UTC, UUID, and final extension intended for that RID or COL identity. A materialization transaction may begin promotion only when every required RID/COL candidate reaches EOF successfully, all selected outputs reconcile to the same accepted data-row count N, and all required candidate finalization/validation succeeds. F-04 existing-Store cardinality gate: when materialization targets an existing VALID Store, after Stage 2 establishes the complete candidate logical data-row count N and before any requested COL candidate is promoted, Data Sculptor must read the expected N from the already-valid inherited RID header and compare the two values. If candidate N equals RID-header N , the cardinality gate passes and ordinary publication may continue. If candidate N differs, the Run must refuse before any SCR -to- COL promotion and before successor-MAP publication. The inherited RID, current MAP, and existing COL artifacts remain unchanged, and the existing Store remains VALID. Equal N proves cardinality compatibility only; it does not prove source-byte continuity, row-semantic identity, or permission for a different SOURCE to enter the lineage. Exact SOURCE/Store compatibility rules are prior gates. For a new Store, Data Sculptor promotes the validated RID candidate first by host rename that changes only the class token from SCR to RID ; the candidate bytes, shared transaction UTC, RID-specific UUID, and extension remain unchanged. That successful SCR-to-RID promotion is the event that establishes RID_ACTION: CREATED and the published RID_FILENAME fact for the Run. Before that promotion succeeds, the Run has not created a governed RID even if a candidate identity has been allocated. For an existing Store, the inherited RID is reused unchanged and no RID candidate/promotion occurs. Once routing has selected and validated that exact inherited RID, that event establishes RID_ACTION: REUSED and the exact inherited RID_FILENAME ; later refusal does not erase the already-established reuse fact. After the required RID state is established, Data Sculptor promotes each requested COL candidate in deterministic resolved KEEP order by changing only the class token from SCR to COL ; each candidate's bytes, shared transaction UTC, COL-specific UUID, and extension remain unchanged. If RID or COL promotion fails, Data Sculptor must refuse the run and roll any newly promoted RID/COL names back out of their final namespaces where safely possible. Candidate or rollback bytes that cannot be safely restored or removed must be retained visibly as non-authoritative SCR failure evidence. The existence of an unreferenced RID- or COL-looking file after interruption does not by itself make that artifact committed Store state. After all required RID/COL promotions succeed, Data Sculptor allocates a MAP-specific UUID before opening the complete successor-MAP SCR candidate. That candidate uses the same publication-transaction UTC, the allocated MAP UUID, and the final .csv extension, and is constructed using the exact final RID/COL filenames. It is closed successfully, reopened, and validated completely while it remains SCR . Only then may the MAP candidate be promoted by changing only the class token from SCR to MAP ; its bytes, UTC, UUID, and extension remain unchanged. The successful SCR -to- MAP rename is the materialization commit point. Until that commit point, the prior valid MAP remains authoritative for an existing Store; for a new Store, no committed Store state exists yet. If MAP validation or MAP rename fails, Data Sculptor must refuse and roll the newly promoted RID/COL set back out of the final namespaces where safely possible; otherwise affected bytes remain attributable recovery evidence and are not committed Store membership. Governed Store membership/current state is established by a valid MAP binding, not by a final-class filename or timestamp equality alone. Revision BB preserves the Revision AY staging/promotion mechanics and Revision AZ shared transaction-UTC rule for newly published RID/COL/MAP artifacts. Selected-folder support for the canonical governed filename/path form is established by the Suitcase Validation Certificate under W002-STOR-022 through W002-STOR-022.3 rather than by a frozen numeric host path-length table. Operation-specific host rename or publication failure remains a governed refusal under this requirement and is not pre-certified by Suitcase validation. F-14 shared candidate grammar, reconciled by F-33: every RID/COL/MAP SCR candidate in this transaction follows W002-STOR-023.1: its SCR name already carries the UTC, UUID and extension intended for the final RID/COL/MAP identity, and successful promotion changes only the class token. Any retained SCR candidates after a handled publication/rollback failure remain visible non-authoritative failure evidence under W002-STOR-023.1 and are reported through the governed diagnostic/Help path; WASM-002 does not emit an RCV manifest. An orphaned SCR remains non-authoritative even if its bytes later validate.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.7,Successful materialization publishes one complete Store MAP,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"A successful governed materialization that creates one or more COL artifacts must also publish exactly one new complete immutable Store MAP under W002-STOR-019 through W002-STOR-019.12. For a new Store, that MAP binds the automatically generated and promoted RID to the Store metadata and all newly materialized COL mappings. For an existing Store, it preserves the inherited RID binding and complete prior Store state while applying the successful materialization updates. All required RID/COL SCR candidates must complete and validate before promotion begins. On a new Store, RID promotion occurs first; on an existing Store, the inherited RID is reused unchanged. All requested COL promotions must then succeed before successor-MAP candidate construction begins. The complete successor MAP is written as SCR , closed, reopened, and fully validated before entering the MAP namespace. Its final host rename from SCR to the governed MAP filename occurs last and is the materialization commit point. The materialization run is not reported as successfully committed until that MAP rename succeeds. If MAP candidate validation or MAP rename fails after RID/COL promotion, the run must refuse and the newly promoted artifacts must be rolled back out of their final namespaces where safely possible. Any failure residue that cannot safely be removed or restored is governed by W002-STOR-023.1 and remains non-authoritative retained failure evidence; its survival must not be used to infer or manufacture attribution or to simulate the failed publication step. The prior valid MAP remains authoritative for an existing Store; no committed Store is established for a first materialization without a valid successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.8,Stage 2 enforces deterministic source-record shape,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The parsed header establishes the expected source field count. Every nonblank logical data record must contain exactly that many fields after CSV parsing. A nonblank ragged record with fewer or more fields must refuse rather than pad, truncate, or shift later values. An explicit empty field is valid data and preserves its ordinal. A bare blank logical data record occurring outside a quoted field must refuse and must not be silently skipped or converted into one empty field. A physical blank line inside a valid quoted multiline field is field content, not a blank record. F-06 canonical malformed-CSV refusal facts Every structural CSV refusal records these governed facts: REFUSAL_CONDITION
SOURCE_BYTE_OFFSET
PHYSICAL_LINE
LOGICAL_RECORD
FIELD_ORDINAL SOURCE_BYTE_OFFSET is the zero-based absolute byte offset from the first physical byte of the source file. A leading UTF-8 BOM, when present, occupies offsets 0–2 and therefore counts in subsequent absolute byte locations. PHYSICAL_LINE is one-based and equals one plus the number of LF bytes strictly before the governed refusal location. LF bytes inside quoted multiline fields still increment physical-line count. LOGICAL_RECORD is one-based CSV logical-record ordinal and includes the header as logical record 1. The first data record is therefore logical record 2. FIELD_ORDINAL is the one-based field position within that logical record. These facts describe the same first structural refusal regardless of permitted streaming-window size or boundary placement. Canonical structural refusal tokens The seven frozen F-06 malformed-CSV tokens are: UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD
INVALID_BYTE_AFTER_CLOSING_QUOTE
BARE_CR_OUTSIDE_QUOTED_FIELD
EOF_INSIDE_QUOTED_FIELD
BLANK_LOGICAL_RECORD
TOO_FEW_FIELDS
TOO_MANY_FIELDS P3-09 adds NO_HEADER_RECORD as the eighth governed Stage-2 structural CSV refusal token. Parser-library names, host exceptions, crate-specific error enums, or localized descriptions must not replace these governed tokens. Governed refusal location by condition Condition Governed refusal location UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD Offset of the offending "" byte. INVALID_BYTE_AFTER_CLOSING_QUOTE Offset of the first prohibited byte after the closing quote. BARE_CR_OUTSIDE_QUOTED_FIELD Offset of the CR byte itself. EOF_INSIDE_QUOTED_FIELD One-past-end offset, equal to the physical source byte length. BLANK_LOGICAL_RECORD First byte of the record terminator that proves the blank record: LF for LF termination; CR for CRLF termination. TOO_FEW_FIELDS First byte of the record terminator that closes the short record; at EOF, one-past-end offset equal to source byte length. TOO_MANY_FIELDS The comma delimiter that begins the first field beyond the expected header width. NO_HEADER_RECORD One-past-end offset equal to the exact physical source byte length, with physical line 1, logical record 1, and field ordinal 1, as frozen by W002-MAT-001.7. Field ordinal rules For TOO_FEW_FIELDS , FIELD_ORDINAL is the first missing field ordinal: expected-width position immediately after the last field actually present. For TOO_MANY_FIELDS , FIELD_ORDINAL is the first extra field ordinal: header-width + 1. For quote/CR/EOF structural conditions, FIELD_ORDINAL is the current field ordinal in which the malformed condition is established. For BLANK_LOGICAL_RECORD , FIELD_ORDINAL is 1. For NO_HEADER_RECORD , FIELD_ORDINAL is 1. Bare CR scope A bare CR outside a quoted field is malformed CSV and refuses with BARE_CR_OUTSIDE_QUOTED_FIELD . CR inside a valid quoted field is ordinary field content. LF inside a valid quoted field is ordinary field content. CRLF inside a valid quoted field is ordinary field content. Outside quoted fields, CRLF is one accepted logical-record terminator and LF is one accepted logical-record terminator. Outside quoted fields, a CR not immediately followed by LF is malformed. EOF while quoted If EOF is reached while the parser remains inside an open quoted field, the source refuses with EOF_INSIDE_QUOTED_FIELD . Data Sculptor must not synthesize a closing quote, truncate the field, reinterpret prior bytes as unquoted content, or otherwise repair the source. First-condition precedence Stage 2 evaluates structural CSV input in absolute source-byte order and reports the earliest refusal condition that becomes deterministically established. CSV grammar errors take precedence over later row-shape errors. BLANK_LOGICAL_RECORD takes precedence over TOO_FEW_FIELDS for a physically blank logical record. BARE_CR_OUTSIDE_QUOTED_FIELD takes precedence over INVALID_BYTE_AFTER_CLOSING_QUOTE when the post-quote offending byte is a CR that is not followed by LF. At EOF while still inside a quoted field, EOF_INSIDE_QUOTED_FIELD takes precedence over field-count evaluation. No implementation may choose a different error merely because of parser buffering, window boundaries, library behavior, or host platform. Delimiter boundary Comma remains the only WASM-002 field delimiter. Automatic delimiter detection is outside the WASM-002 CSV contract. A file whose rows contain semicolons, tabs, or other non-comma separators may still be valid under the comma-only grammar as a one-column CSV. Data Sculptor must not invent a malformed-CSV refusal merely because another application would treat those bytes as delimiters. When a requested HEADER cannot be resolved, Help may explain that WASM-002 uses comma as the CSV delimiter and that semicolon/tab exports may therefore be interpreted as one field per row. Interaction with UTF-8 diagnostics This structural CSV refusal oracle applies only after the source has passed the applicable encoding-certification boundary. Invalid UTF-8 remains governed by the separately frozen UTF-8 diagnostic contract. Its zero-based absolute source-byte orientation is intentionally aligned with SOURCE_BYTE_OFFSET so WASM-002 does not have competing byte-coordinate systems.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.9,Unselected field contents are not retained,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 must parse every field sufficiently to preserve CSV structure, field count, row boundaries, and governed safety checks, but it must not retain complete contents for unselected fields after those bytes are no longer structurally needed. The engine must not materialize a complete source row, complete table, or complete unselected column in memory merely to emit selected columns. Selected-field content may use bounded accumulation required by the frozen field-size/output rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.10,Individual decoded CSV fields are limited to 16 MiB,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"WASM-002 carries forward the established Data Sculptor field-buffer safety boundary: an individual CSV field may contain at most 16 MiB (16,777,216 bytes) of decoded UTF-8 field content. This is an engineering safety limit, not a semantic statement about CSV or an Excel cell limit. The limit must be enforced incrementally for header and data fields. The parser must not first accumulate an arbitrarily large field and then check it. If a field would exceed the limit, the run must refuse without truncating, repairing, discarding the remainder, or finalizing the candidate materialization. For an unselected field, Data Sculptor may count decoded field bytes without retaining the field value; the safety limit still applies so malformed unterminated fields cannot turn the structural scan into unbounded growth. F-20 operational column-name boundary: after an exact source header field is decoded, Data Sculptor measures its length in Unicode scalar values, not UTF-8 bytes or grapheme clusters. If the exact decoded source header contains at most 1,024 Unicode scalar values, its operational column name is that exact header text. If it contains more than 1,024 scalar values, the operational column name begins from the deterministic physical-ordinal fallback Column <LETTERS> , where the letters are the Excel-style 1-based source ordinal ( A through XFD for the WASM-002 width bound). This operational name is a bounded human-facing/default-alias construct; it does not replace or truncate the authoritative exact source header.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.11,Materialized COL artifacts use canonical one-column UTF-8 CSV serialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Each finalized materialized COL artifact is a one-column CSV. It begins with exactly one UTF-8 BOM ( EF BB BF ) and uses LF ( 0x0A ) as the record terminator on every supported host. The first logical record contains the exact decoded source header text for that physical source column; an alias assigned with AS lives in the governed MAP and does not rewrite the physical COL header. A deliberately empty source header is serialized as one explicit empty header field rather than as absence of a header record. Header and data fields use deterministic minimal CSV quoting: quote when the field contains comma, double quote, CR, or LF; double embedded double quotes; otherwise write the field without quotes. Embedded CR/LF that belong to a quoted field remain field content. For a one-column data record whose decoded value is the empty string, serialize the value explicitly as """" so the row cannot be confused with a bare blank logical record. For fixed source bytes and fixed governed semantics, changing input/output window boundaries must not change the finalized COL bytes. F-20 source-fidelity rule: the physical COL header record always serializes the exact decoded source header, even when that header exceeds the 1,024 -scalar operational-name boundary and the Store MAP/default alias therefore uses an operational fallback. The fallback name must never be substituted into the COL header record or into the MAP source_header field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003,Stage 2 processes the source through bounded reusable windows,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,Structural materialization must process the certified source through bounded reusable input windows compatible with browser/WASM memory constraints. Source size and row count must not require proportional WASM memory growth.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.1,"The 4 MiB WASM-001b window is a proven reference point, not a frozen production constant",W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The 4 MiB source window used successfully during the WASM-001b browser experiments is an evidence-backed starting/reference size. WASM-002 may tune the production input-window size using benchmark evidence, provided the governed memory budget and all window-invariance requirements remain satisfied.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.2,Changing source-window size or boundary placement must not change results,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"For the same certified source and Work Order, permitted changes in bounded Stage 2 input-window size or boundary placement must not change CSV interpretation, resolved headers/ordinals, accepted row count, row identity, aliases, canonical COL bytes, successor MAP contents apart from newly allocated physical identities/timestamps, or the first deterministic refusal condition. P3-09 window invariance: for a Stage-1-certified source containing no logical CSV record, every permitted Stage 2 window size and boundary placement must produce the same NO_HEADER_RECORD refusal and the same governed location tuple: source-byte offset equal to the exact source byte length, physical line 1, logical record 1, field ordinal 1. F-06 full refusal-oracle window invariance: for the same certified source bytes, changing any permitted Stage 2 input-window size or boundary placement must not change whether the source is accepted or refused; the first REFUSAL_CONDITION ; SOURCE_BYTE_OFFSET ; PHYSICAL_LINE ; LOGICAL_RECORD ; or FIELD_ORDINAL . This applies to every structural CSV refusal governed by W002-MAT-002.8.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.3,CSV structure must survive arbitrary input-window boundaries,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Input-window boundaries may occur between ordinary field bytes, delimiter bytes, quote/escaped-quote pairs, CR/LF record-ending bytes, inside quoted multiline fields, and inside already-certified multi-byte UTF-8 sequences. The Stage 2 parser must preserve equivalent structural meaning across those boundaries.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.4,Cross-window parser state is small and explicit,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 may carry only the bounded state needed to continue the current logical CSV parse, including the current logical row ordinal, current field ordinal, quoted/unquoted state, escaped-quote/quote-transition state as required by the parser, pending CR/LF state, decoded-field byte count, resolved selected-field dispatch metadata, and bounded selected-field/output staging. The parser must not retain previous complete rows or source windows merely because a CSV record crosses a window boundary.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.5,Input-window and output-drain sizes are independent implementation controls,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The source read window, WASM transfer window where applicable, selected-field accumulator bound, and output-drain window are separate controls. One must not be silently treated as the maximum for another merely because an earlier prototype used the same numeric value. Any tuning must preserve the Stage 2 memory, backpressure, byte, and window-invariance contracts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.6,Stage 2 uses direct structural parsing rather than a required structural sidecar,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The WASM-002 baseline performs its Stage 2 work directly from the certified source stream. It must not require a precomputed comma/quote/newline position map, binary structural index, hidden cache, or OPFS sidecar before materialization can proceed. The previously discussed structural-sidecar comparison remains a separate future experiment and must not be introduced into WASM-002 as an unmeasured dependency.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.7,The Stage 2 algorithm is browser-first shared Rust core behavior,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The structural parser, row-count semantics, selector dispatch, canonical field serialization, and bounded output-state machine defined by Stage 2 belong in the shared Rust semantic core proven through the browser/WASM path first. A later native CLI host must call the same governed core rather than reimplementing competing materialization semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001,Conversion is a separate governed operation,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Windows-1252-to-UTF-8 conversion is a distinct governed Work Order operation, separate from UTF-8 certification and separate from analytical materialization. The analyst must explicitly authorize it. The canonical WASM-002 form is: SUITCASE: .
WORK ORDER AS ""Convert legacy source to UTF-8""
SOURCE ""legacy_source.csv""
CONVERT WINDOWS-1252 TO UTF-8 CONVERT WINDOWS-1252 TO UTF-8 is the terminal operation clause. Exactly one SOURCE is permitted. The same WKO must not contain KEEP , MATERIALIZE , Store/RID/COL alias mutation, MAP , Inventory, repair, cataloging, Work Order composition, or another operation terminal clause. F-10 conversion entry precondition Before CONVERT WINDOWS-1252 TO UTF-8 may begin character transcoding, Data Sculptor must validate the complete bound source as strict UTF-8 under the same deterministic whole-source certification rules used elsewhere in WASM-002. If the complete source is already valid strict UTF-8, the conversion refuses as unnecessary and publishes no CVT . Only after complete strict UTF-8 validation reaches governed FAIL may Data Sculptor assess the same complete bound source against the frozen Windows-1252 compatibility mapping. Only a source that fails strict UTF-8 and passes the complete Windows-1252 compatibility assessment may proceed to conversion. A failed analytical Work Order, UTF-8 certification, or materialization never silently invokes this operation. The analyst must explicitly authorize the separate conversion WKO.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.1,A failed analytical Work Order must not automatically invoke conversion.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.2,The user must explicitly choose or submit the separate conversion task.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.3,The original source file must remain unchanged.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.4,Successful conversion must create a new UTF-8 artifact with its own governed identity and receipt/evidence.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002,Windows-1252 compatibility assessment,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"After strict whole-source UTF-8 certification returns FAIL , the current analytical operation remains refused and Stage 2 must not start. As refusal handling, Data Sculptor performs one separate read-only Windows-1252 compatibility assessment from physical byte offset 0 of the same run-local bound source instance. The compatibility assessment scans the complete source sequentially under W002-CONV-002.1 through W002-CONV-002.5. It does not transcode, publish a CVT, modify the analyst-owned source, resume materialization, or claim that Windows-1252 is the historical encoding. Its sole governed result is whether the entire byte stream is mappable by the frozen WASM-002 Windows-1252 converter. If strict UTF-8 certification returned PASS , or did not reach a governed FAIL conclusion, this compatibility assessment is not run. F-10 conversion classification gate The conversion operation itself repeats/executes the complete classification gate on its bound source before transcoding: validate the complete source as strict UTF-8; if strict UTF-8 passes, refuse conversion as unnecessary; only after strict UTF-8 fails, scan the complete source against the frozen Windows-1252 mapping; if any source byte is undefined or unsupported by that mapping, refuse rather than guess; and begin transcoding only when strict UTF-8 has failed and the complete Windows-1252 compatibility assessment has succeeded. An undefined/unsupported Windows-1252 byte is therefore a pre-transcoding compatibility-assessment refusal . No CVT candidate may be represented as successfully converted from a source whose compatibility scan found an undefined byte. The compatibility assessment must not substitute U+FFFD , reinterpret an undefined Windows-1252 byte as ISO-8859-1, or use permissive host/library decoder behavior to make an incompatible source convertible.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.1,Compatibility means that the supported deterministic converter can map the observed source bytes under the frozen Windows-1252 rules.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Compatibility means that every physical source byte can be mapped deterministically by the complete normative WASM-002 Windows-1252 mapping in W002-CONV-002.4 . Successful EOF produces the governed outcome COMPATIBLE . No statistical detector, locale rule, browser guess, replacement character, ISO-8859-1 substitution, best-effort decoder, or PRODUCT-scoped glossary text participates as normative authority in this determination.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.2,Compatibility must not be described as proof that Windows-1252 was historically or authoritatively the file's original encoding.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"COMPATIBLE means only that the complete byte stream is convertible under Data Sculptor's frozen Windows-1252 mapping. It must not be described as proof that Windows-1252 was historically, authoritatively, or intentionally the source file's original encoding.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.3,Bytes undefined by the frozen Windows-1252 mapping must cause the compatibility assessment or conversion task to refuse rather than guess.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"If the compatibility pass encounters a byte that W002-CONV-002.4 defines as undefined, the assessment stops at the first such byte and returns INCOMPATIBLE . Data Sculptor must not substitute a replacement character, reinterpret the byte under another code page, or continue as though conversion were safe. A later explicit conversion Work Order must apply the same complete WASM-002 mapping and the same refusal rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.4,Complete normative WASM-002 Windows-1252 byte mapping,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"This requirement is the complete normative Windows-1252 mapping authority for WASM-002 . It covers all 256 possible byte values. No PRODUCT-scoped glossary entry or host/library decoder is required to interpret compatibility or conversion. 0x00–0x7F Every byte 0x00 through 0x7F maps one-to-one to Unicode U+0000 through U+007F . 0x80–0x9F Byte Windows-1252 mapping Unicode 0x80 EURO SIGN U+20AC 0x81 UNDEFINED — 0x82 SINGLE LOW-9 QUOTATION MARK U+201A 0x83 LATIN SMALL LETTER F WITH HOOK U+0192 0x84 DOUBLE LOW-9 QUOTATION MARK U+201E 0x85 HORIZONTAL ELLIPSIS U+2026 0x86 DAGGER U+2020 0x87 DOUBLE DAGGER U+2021 0x88 MODIFIER LETTER CIRCUMFLEX ACCENT U+02C6 0x89 PER MILLE SIGN U+2030 0x8A LATIN CAPITAL LETTER S WITH CARON U+0160 0x8B SINGLE LEFT-POINTING ANGLE QUOTATION MARK U+2039 0x8C LATIN CAPITAL LIGATURE OE U+0152 0x8D UNDEFINED — 0x8E LATIN CAPITAL LETTER Z WITH CARON U+017D 0x8F UNDEFINED — 0x90 UNDEFINED — 0x91 LEFT SINGLE QUOTATION MARK U+2018 0x92 RIGHT SINGLE QUOTATION MARK U+2019 0x93 LEFT DOUBLE QUOTATION MARK U+201C 0x94 RIGHT DOUBLE QUOTATION MARK U+201D 0x95 BULLET U+2022 0x96 EN DASH U+2013 0x97 EM DASH U+2014 0x98 SMALL TILDE U+02DC 0x99 TRADE MARK SIGN U+2122 0x9A LATIN SMALL LETTER S WITH CARON U+0161 0x9B SINGLE RIGHT-POINTING ANGLE QUOTATION MARK U+203A 0x9C LATIN SMALL LIGATURE OE U+0153 0x9D UNDEFINED — 0x9E LATIN SMALL LETTER Z WITH CARON U+017E 0x9F LATIN CAPITAL LETTER Y WITH DIAERESIS U+0178 0xA0–0xFF Every byte 0xA0 through 0xFF maps one-to-one to Unicode U+00A0 through U+00FF . Undefined-byte rule The only undefined byte values in this frozen WASM-002 mapping are exactly 0x81 , 0x8D , 0x8F , 0x90 , and 0x9D . Encountering any one of them makes the complete compatibility assessment INCOMPATIBLE at the first such byte and causes an explicitly run conversion Work Order to refuse before transcoding rather than guess. These three ranges plus the 32-position table above exhaust the byte domain 0x00–0xFF . No unlisted byte value exists.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.5,The compatibility check must itself be bounded and deterministic.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"The compatibility check is one bounded-memory deterministic sequential pass from physical source byte offset 0 to EOF unless the first undefined Windows-1252 byte is encountered earlier. Buffer/window size must not change the compatibility outcome or the first undefined-byte offset. On INCOMPATIBLE , WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET is the zero-based absolute physical source-byte offset of the first undefined byte. On COMPATIBLE , that offset is NOT_APPLICABLE . If the assessment begins but an independent read/host failure prevents a governed compatibility conclusion, the outcome is NOT_AVAILABLE and the first-undefined-byte offset is NOT_AVAILABLE . The assessment itself publishes no converted output.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003,Help suggestion after failed UTF-8 certification,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Help may suggest the separate CONVERT WINDOWS-1252 TO UTF-8 Work Order only when the governed engine emits DS-CNV-001 after a complete compatibility assessment returned COMPATIBLE . The suggestion is therefore derived from a governed diagnostic fact, not from the UTF-8 failure itself. If the assessment returns INCOMPATIBLE , is NOT_AVAILABLE , or did not run, DS-CNV-001 is not emitted and Help must not invent the conversion recommendation. P3-08 Help disclosure: when conversion succeeds, Help must state that the published CVT is a new governed source artifact with its own source identity and that converting a refreshed legacy source later will publish another distinct CVT rather than refresh an earlier CVT-backed Store lineage. When a CVT is selected for first materialization, Help must disclose the same consequence before or with the normal materialization guidance: the Store lineage is anchored to the exact CVT filename, not to the analyst-owned pre-conversion filename. Help must not imply hidden lineage continuity across separate CVT artifacts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.1,The suggestion must state that the current analytical task has stopped.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must state that the current analytical task has already stopped/refused because strict UTF-8 certification failed. DS-CNV-001 is informational and must not be rendered as though materialization can continue from the failed run.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.2,The suggestion must state that the original source has not been changed.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must state that the compatibility assessment was read-only and that Data Sculptor did not change the analyst-owned source. Any later successful conversion publishes a separate governed CVT artifact rather than editing the original source in place.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.3,"The suggestion must describe the source as compatible with the supported Windows-1252 converter, not definitively identified as Windows-1252.",W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must describe the complete source as compatible with Data Sculptor's supported Windows-1252 converter . It must not say that the source was definitively identified as Windows-1252 or imply provenance that the compatibility pass cannot prove.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.4,The suggestion must make clear that conversion is a separate user-authorized task.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"The suggestion must make clear that conversion is a separate user-authorized Work Order. next_action: RUN_WINDOWS_1252_CONVERSION means that the separate operation is a governed safe option; it is not permission for Data Sculptor to silently transcode, modify the source, or reinterpret the refused analytical Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.5,"If the bytes are not compatible with the supported converter, Help must not recommend Windows-1252 conversion as though it were safe.",W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"If the compatibility outcome is INCOMPATIBLE , NOT_AVAILABLE , or NOT_RUN , Help must not recommend Windows-1252 conversion as though it were safe. In particular, the mere presence of DS-ENC-001 never authorizes that recommendation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004,Canonical conversion output,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"A successful Windows-1252 conversion task must produce canonical UTF-8 output suitable for later submission to the normal UTF-8 certification and materialization path. P3-08 lineage consequence: the successful conversion output is a new immutable governed CVT artifact with its own exact physical filename. That CVT filename is the source identity used by later Store routing. A later conversion, including one made from a refreshed analyst-owned legacy source with the same original filename, publishes a different CVT and therefore does not refresh, replace, or continue an earlier CVT-backed Store lineage merely by name association. On first materialization, each distinct CVT begins a new Store lineage unless that exact CVT filename already routes to an existing lineage under the normal Store rules. F-14 CVT identity and publication: the final converted-source filename is exactly __DS__CVT__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv . Conversion writes first to the corresponding W002-STOR-023.1 SCR identity with the same UTC, UUID and .csv extension. Only after bounded conversion completes, the candidate closes/reopens successfully, and the converted bytes satisfy the governed strict UTF-8 requirement may the class token be renamed to CVT . CSV structural interpretation remains governed by the later normal certification/materialization path; CVT publication does not assert that the converted source is structurally valid CSV. F-10 conversion semantics — encoding conversion only The conversion operation performs deterministic character transcoding only. It does not parse, repair, normalize, or reinterpret CSV structure. Commas remain commas. Double quotes remain double quotes. Ordinary ASCII bytes retain the same byte value. LF remains LF. CR remains CR. CRLF remains CRLF. Embedded CR/LF bytes are preserved in place; the converter does not decide whether they are record terminators or field content. Canonical UTF-8 output therefore means deterministic UTF-8 encoding of the accepted source characters, not normalization of line endings, quoting, delimiters, records, headers, or fields. F-10 BOM rule The published CVT is UTF-8 without a BOM ; Data Sculptor does not prepend EF BB BF . If the source failed strict UTF-8 classification, a leading source byte sequence EF BB BF is not blindly stripped as though it were a UTF-8 BOM. Under the Windows-1252 conversion path those source bytes are source data and are mapped according to the frozen Windows-1252 mapping. BOM interpretation remains subordinate to encoding classification rather than acting as a blind prefix-removal rule.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-010; CP-011,"CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open; CP011 T-ACCEPTED, GIT BANKED — CVT-to-SCR lexical staging-name pairing only; complete conversion requirement remains open",b7c515faa9bd000369d7656e09437310261290ae; e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,"Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived); Evidence/CP-011/CP011_Scope_Lock.txt; Evidence/CP-011/CP011_RED_Test_Output.txt; Evidence/CP-011/CP011_GREEN_Test_Output.txt; Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt; Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt; Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt; Evidence/CP-011/CP011_Hash_Inventory_Verification.txt; Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt; Evidence/CP-011/CP011_Closing_Git_Review.txt; CP011_Git_Banking_Output.txt (post-commit, separately preserved)","CP010 Day066 first-touches ONLY the F-14 canonical final CVT output filename grammar subconstraint: is_governed_cvt_source_filename_candidate(&str)->bool recognizes exact canonical __DS__CVT__<UTC>__<UUIDv4>.csv lexical form by reusing existing envelope validation. Four targeted tests + 40/40 full native regression PASS; wasm32-target build PASS; T accepted and banked b7c515faa9bd000369d7656e09437310261290ae. No encoding conversion, SCR creation, close/reopen, UTF-8 validation, CVT publication, immutable physical output, source authority, or CSV structural checks; entire W002-CONV-004 remains PARTIAL, independently unreviewed. CP011 Day066: public pure helper build_scr_candidate_filename_for_cvt(&str)->Option<String> accepts an exact canonical governed CVT .csv filename (via CP010 recognizer) and derives the paired SCR filename by substituting only class token CVT -> SCR, preserving exact UTC, UUIDv4 and lowercase .csv bytes; rejects wrong classes, paths, whitespace, malformed clock/date/UUID, extension and class case. Six targeted tests; RED expected E0432 exit 101; GREEN 6/6; post-format native regression 46/46; rustfmt recheck PASS; Rust 1.97.1 wasm32-unknown-unknown --lib build PASS; original 28/28 and combined 36/36 SHA-256 records verified. Two local scoped .gitattributes whitespace exceptions preserve Rustfmt/Git diagnostic TXT bytes; final Git staged check PASS. T-approved and Git banked e84ae5baeee05f9d5d30284c65b86eebba3c0f6a, 27 committed files, working tree clean. Lexical candidate-name pairing ONLY; no SCR creation, bytes, converter, transaction, close/reopen, validation/publication, retained SCR adoption, SOURCE authority or browser execution. Independent Claude implementation QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.1,The converted artifact must itself be certifiable as UTF-8.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.2,The conversion Receipt identifies the governed source encoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for a successful governed Windows-1252-compatible conversion must identify exactly SOURCE_ENCODING: WINDOWS-1252-COMPATIBLE . That operation-specific fact is carried within the canonical TXT Receipt governed by W002-RCP-001 through W002-RCP-010. Only that exact serialized spelling is permitted for this key/value pair.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.3,The conversion Receipt identifies the materialized UTF-8 encoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for a successful governed conversion must identify exactly MATERIALIZED_ENCODING: UTF-8 . This uses the canonical KEY: VALUE serialization frozen by W002-RCP-005. MATERIALIZED_ENCODING=UTF-8 is not valid canonical Receipt serialization.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.4,The conversion Receipt identifies bounded streaming transcoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for successful conversion must identify that transcoding was performed under the governed bounded/streaming conversion contract.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.5,No analytical column materialization occurs as part of this conversion operation.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001,Canonical diagnostic truth,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every governed user-visible failure or warning produced by WASM-002 must originate as a canonical diagnostic event. A diagnostic event must have a stable identity and structured facts independent of its final wording. Governed success/status events that participate in the Help/status/evidence system—such as a successfully saved Work Order or a successfully validated Suitcase—are canonical INFO diagnostic events and obey the same identity/fact/behavior contract. Ordinary static labels, headings, decorative copy, and presentation-only status text are not automatically diagnostics merely because they are visible in the UI.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.1,Canonical diagnostic IDs use the frozen DS-<DOMAIN>-<NNN> grammar,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry one stable identifier using the exact form DS-<DOMAIN>-<NNN> . DOMAIN is exactly three uppercase ASCII letters A through Z. NNN is exactly three decimal digits, zero-padded, in the range 001 through 999 . Examples include DS-ENC-001 , DS-WKO-001 , DS-STO-001 , DS-MAT-001 , and DS-HLP-001 . A diagnostic ID is permanent after allocation and must never be reused for a different diagnostic meaning. Severity, host, build/release, source filename, path, UUID, byte offset, row/column number, count, timestamp, occurrence ID, and other run-specific facts must not be encoded into the diagnostic ID; those values belong in structured diagnostic fields. The identifier is the canonical lookup key used by the Help message catalog. Day 060 H-04 pre-freeze identifier normalization: the Windows-1252 compatibility suggestion diagnostic is DS-CNV-001 . It follows the same exact three-letter DOMAIN grammar as every other diagnostic ID. No four-letter DOMAIN exception exists in the current WASM-002 contract. Any pre-H-04 draft spelling of this diagnostic is superseded and is not valid build-registry input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.2,Diagnostic severity uses one exact token set,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry exactly one severity token: INFO , WARNING , or ERROR . Severity classifies the condition for human and machine interpretation. It does not itself determine whether execution continues or refuses; that authority is carried separately by the canonical behavior field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.3,Diagnostic phase uses a stable uppercase token,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must identify the governed operation or phase using an uppercase ASCII snake-case token matching [A-Z][A-Z0-9]*(?:_[A-Z0-9]+)* . Examples include WORK_ORDER_VALIDATION , SOURCE_CERTIFICATION , MATERIALIZATION , STORE_PUBLICATION , and HELP_REPORT . These examples do not constitute a closed global phase list; the fixed phase for each allocated diagnostic is declared by that diagnostic's registry entry.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.4,Structured diagnostic facts are declared per diagnostic,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The canonical event carries diagnostic-specific evidence in a structured facts object. Fact keys use lowercase ASCII snake case matching [a-z][a-z0-9]*(?:_[a-z0-9]+)* . Each diagnostic registry entry declares disjoint required_facts and optional_facts sets. Every required fact must be present when that diagnostic is emitted. An optional fact key may be omitted when that fact is not emitted for the event, but omission itself has no governed absence-state meaning : it must not be interpreted as NONE , NOT_RUN , NOT_AVAILABLE , NOT_APPLICABLE , false , zero, or an empty string. An emitted fact key that is not declared for that diagnostic is invalid. For structured JSON diagnostic facts, an established ordinary value retains its native JSON type. When a present diagnostic fact must express one of the shared governed absence states, its value is the exact JSON string ""NONE"" , ""NOT_RUN"" , ""NOT_AVAILABLE"" , or ""NOT_APPLICABLE"" , with the meaning frozen by F-18. JSON null is not a generic encoding for diagnostic-fact absence; it is permitted only where a specific JSON schema explicitly declares a nullable field and defines what that null means, as W002-HELP-009 does for HLP lineage. A required diagnostic fact may not be silently omitted, defaulted, converted to null , guessed, or replaced by a Help-layer value. If Data Sculptor attempts to establish a registered diagnostic but cannot produce one or more facts declared required for that diagnostic, the intended diagnostic is not emitted . Instead the engine emits DS-HLP-001 under W002-HELP-001.8. The replacement event records the intended diagnostic ID and the complete sorted set of missing required fact names. No partially populated copy of the intended diagnostic may be presented beside it. This fail-closed substitution is a diagnostic-contract integrity rule, not a presentation fallback. It preserves the F-17 boundary that diagnostics own facts and Help renders only complete governed diagnostic truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.5,Execution behavior is explicitly CONTINUE or REFUSE,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry exactly one execution-behavior token: CONTINUE or REFUSE . This field is the governed continue/refuse decision for the event. Help wording, severity, UI color, or presentation must not independently weaken, strengthen, or reinterpret it.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.6,Safe next action uses a stable token rather than Help prose,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry a next_action token using uppercase ASCII snake case matching [A-Z][A-Z0-9]*(?:_[A-Z0-9]+)* . NONE is the canonical value when no safe governed next action applies. The token expresses stable machine-readable intent; Casual, Office Speak, and Technical wording for that action belongs to the Help layer. Run-specific values such as timestamps, paths, UUIDs, byte offsets, filenames, counts, or occurrence IDs remain structured facts and do not change the diagnostic identity or fixed next-action meaning. Damaged-Store guidance is part of the safe-next-action contract. When ordinary materialization refuses because exact source routing identifies an INVALID Store lineage, or a DEGRADED lineage whose every mapped COL is broken and therefore cannot be reduced to a non-empty successor by REPAIR MAP , the selected Help voice must preserve the same frozen choices and consequences rather than inventing a recovery operation. The explanation must identify the blocked lineage/current MAP and distinguish: external restoration under the original governed physical filename followed by the required governed validation tier; source rename to deliberately begin a separate new Store lineage; and analyst retirement of the damaged lineage by moving all of that lineage's Store MAPs out of the active Suitcase root. For retirement, Help must warn that moving only the latest MAP can expose an older structurally valid MAP as current. Help must not claim that matching the original filename proves historical byte identity, and must not describe any of these analyst filesystem actions as Data Sculptor-authored repair, deletion, RID regeneration, or silent lineage replacement. P3-07 malformed-MAP routing guard: when ordinary materialization refuses because no routable Store lineage can be established while one or more structurally malformed Store-MAP-class artifacts are present in the active Suitcase, Help must identify the malformed MAP artifact or artifacts and state that new-Store/RID creation was blocked to prevent a silent lineage fork. Help must not describe the missing structurally valid MAP as proof that the prior Store never existed, and must not invent a Data Sculptor repair or replacement operation for this condition. P3-10 delimiter-hint clarification: when Stage 2 refuses with INVALID_BYTE_AFTER_CLOSING_QUOTE and the offending byte is semicolon ( 0x3B ) or horizontal TAB ( 0x09 ), Help may include the governed delimiter-mismatch hint even though the refusal occurred before header-delimiter resolution. The hint is explanatory only: it must not change the canonical refusal condition, location facts, behavior, or safe-action boundary. F-16 conversion-suggestion boundary: strict UTF-8 refusal diagnostic DS-ENC-001 has fixed next_action: NONE . UTF-8 failure alone does not establish that any converter is safe. Only the separate compatibility diagnostic DS-CNV-001 , emitted after the complete governed Windows-1252 compatibility assessment returns COMPATIBLE , may carry next_action: RUN_WINDOWS_1252_CONVERSION . That token identifies a safe separately authorized option; it never resumes or rewrites the refused analytical Work Order. Day 060 H-12 damaged-lineage diagnostic binding ordinary MATERIALIZE refusal for a routed INVALID Store uses DS-MAT-014 and its declared facts; ordinary MATERIALIZE refusal for a DEGRADED Store whose every mapped COL is broken uses DS-MAT-015 and its declared facts; the no-routable-lineage / malformed-Store-MAP guard uses DS-MAT-016 and its declared facts. These specialized allocations are what permit closed-world Help to identify the blocked lineage/current MAP or malformed MAP artifacts without adding unrelated facts to the ordinary DS-MAT-010 validation diagnostic. Day 060 H-26 / BM-09 ordinary DEGRADED routing binding. When ordinary MATERIALIZE exact-source routing identifies a DEGRADED Store whose RID is valid and at least one mapped non-RID COL remains valid, the refusal uses DS-MAT-017 . Its fixed next_action is RUN_REPAIR_MAP because REPAIR MAP is the safe governed Store mutation for this repairable DEGRADED state. Help must use the diagnostic's declared current_map_filename as the exact MAP identity the analyst must name in the separate governed REPAIR MAP Work Order. The token does not run repair automatically and does not mutate the refused MATERIALIZE Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.7,"The governed engine emits the diagnostic semantic core, not voice-authored prose",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The shared Rust/WASM diagnostic path must provide the canonical semantic core required by Help: diagnostic_id , severity , phase , behavior , facts , and next_action . The fixed values and permitted fact-key sets for an allocated diagnostic are governed by diagnostics.json . Casual, Office Speak, and Technical prose belongs to the Help rendering layer rather than being duplicated as authored message sets inside the governed engine. Host/build/occurrence metadata may be carried by surrounding governed execution evidence, but it must not redefine the diagnostic semantic core. F-16 closed-world Help rule: Help may recommend the WASM-002 Windows-1252 conversion Work Order only when the governed engine emitted DS-CNV-001 . Help must not infer compatibility from DS-ENC-001 , byte appearance, file extension, locale, browser behavior, heuristic encoding detection, or prose outside the diagnostic facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.8,diagnostics.json is the canonical WASM-002 diagnostic registry build resource,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The human-inspectable development/build source for the WASM-002 diagnostic registry is exactly diagnostics.json , encoded as UTF-8 without BOM. It is Data Sculptor product/build content, not a Suitcase artifact; it must not use the __DS__ namespace, consume an artifact-class token, or be copied into an analyst's Suitcase merely because Data Sculptor runs. The top-level JSON object has exactly two fields: registry_version and diagnostics . registry_version is the string ""1"" . diagnostics is an array written in ascending UTF-8 byte order of diagnostic_id . Each diagnostic entry has exactly seven fields: diagnostic_id , severity , phase , behavior , next_action , required_facts , and optional_facts . Diagnostic IDs must be unique and satisfy W002-HELP-001.1. Severity, phase, behavior, and next-action values must satisfy W002-HELP-001.2 through W002-HELP-001.6. required_facts and optional_facts are arrays of canonical fact-key strings sorted in ascending UTF-8 byte order; keys must be unique within each array and the two arrays must be disjoint. {
  ""registry_version"": ""1"",
  ""diagnostics"": [
    {
      ""diagnostic_id"": ""DS-CNV-001"",
      ""severity"": ""INFO"",
      ""phase"": ""SOURCE_CERTIFICATION"",
      ""behavior"": ""CONTINUE"",
      ""next_action"": ""RUN_WINDOWS_1252_CONVERSION"",
      ""required_facts"": [""source_filename"", ""windows_1252_compatibility_outcome""],
      ""optional_facts"": []
    },
    {
      ""diagnostic_id"": ""DS-ENC-001"",
      ""severity"": ""ERROR"",
      ""phase"": ""SOURCE_CERTIFICATION"",
      ""behavior"": ""REFUSE"",
      ""next_action"": ""NONE"",
      ""required_facts"": [""first_invalid_byte_offset"", ""source_filename"", ""stop_reason""],
      ""optional_facts"": [""analytical_outputs_published"", ""materialization_started"", ""source_modified_by_data_sculptor"", ""store_state_committed""]
    },
    {
      ""diagnostic_id"": ""DS-HLP-001"",
      ""severity"": ""ERROR"",
      ""phase"": ""DIAGNOSTIC_ASSEMBLY"",
      ""behavior"": ""REFUSE"",
      ""next_action"": ""NONE"",
      ""required_facts"": [""intended_diagnostic_id"", ""missing_required_facts""],
      ""optional_facts"": []
    }
  ]
} The PRD does not need to enumerate every allocated WASM-002 diagnostic row. The complete registry delivered with the build is retained acceptance evidence. A diagnostic ID becomes permanent once allocated and must not later be reused for a different meaning. Build validation must fail on malformed JSON; extra/missing entry fields; duplicate or noncanonical diagnostic IDs; invalid fixed tokens; unsorted, duplicate, overlapping, or invalid fact-key declarations; engine diagnostic definitions whose fixed semantics disagree with the registry; engine diagnostic definitions absent from the registry; Help-catalog IDs absent from the registry; or Help placeholders that name facts not declared as required or optional by the matching diagnostic. F-07 DS-ENC-001 fact mapping: the canonical lower-case diagnostic facts for strict UTF-8 refusal are first_invalid_byte_offset , source_filename , and stop_reason . For this diagnostic, stop_reason is exactly INVALID_UTF8_SEQUENCE . The generic fact name byte_offset is retired for this UTF-8 refusal diagnostic. P2-03 clock-order diagnostic facts: whichever stable WASM-002 Diagnostic ID is allocated to refusal because a successor Store MAP or WKO MAP cannot satisfy the strict monotonic UTC publication guard must declare these exact lower-case required facts in its diagnostic-registry entry: map_profile , observed_host_utc , predecessor_map_filename , and predecessor_utc . map_profile has exactly two permitted values: STORE for a Store-MAP chronology guard and WKO for a Work-Order-registry-MAP chronology guard. These facts identify both the governed MAP profile, the blocking predecessor artifact, and the truthful clock observation that caused refusal. F-16 DS-CNV-001 allocation: DS-CNV-001 is emitted only when the complete read-only compatibility assessment under W002-CONV-002 through W002-CONV-002.5 reaches EOF with outcome COMPATIBLE . Its required fact windows_1252_compatibility_outcome is therefore exactly the JSON string ""COMPATIBLE"" . behavior: CONTINUE means this informational diagnostic introduces no additional refusal; it does not reverse the already-established DS-ENC-001 refusal or resume Stage 2. F-17 DS-HLP-001 allocation: DS-HLP-001 is the canonical fail-safe event when the engine cannot satisfy the complete required-fact contract of an intended registered diagnostic. intended_diagnostic_id is the exact canonical ID that was being assembled. missing_required_facts is a JSON array of every missing required fact-key string, sorted in ascending UTF-8 byte order with no duplicates. The intended diagnostic is suppressed rather than emitted incompletely. DS-HLP-001 always refuses and has next_action: NONE . F-22 QA-independence boundary: diagnostics.json is authoritative for the fixed semantic contract of an allocated Diagnostic ID — its ID, severity, phase, behavior, next action, and permitted required/optional fact keys — but the implementation-delivered registry is not, by itself, an independent oracle proving that every arbitrary runtime condition was mapped to the correct Diagnostic ID. WASM-002 does not require a second QA-owned registry duplicating every implementation allocation. Where this PRD independently freezes a condition-to-diagnostic mapping or exact required facts — including the named DS-ENC-001 , DS-CNV-001 , and DS-HLP-001 contracts and other explicitly pinned diagnostic facts — that PRD text remains normative and acceptance must test the mapping independently of the implementation registry. For allocations not independently pinned by the PRD, WASM-002 accepts the validated build registry as the build allocation while retaining all registry-shape, permanence, semantic-agreement, fact-discipline, and Help cross-validation gates. This is an explicit accepted QA-scope risk, not a claim of independent condition-to-ID verification. Day 060 H-02 fixture-pinned diagnostic allocations The following allocations are normative for the byte-exact Receipt acceptance corpus. They are genuine product diagnostics, not QA-only placeholder IDs. Every row has severity: ERROR , behavior: REFUSE , next_action: NONE , the phase shown below, the listed required facts, and an empty optional_facts array unless another requirement explicitly adds optional facts later. The existing DS-ENC-001 remains the Stage-1 invalid UTF-8 diagnostic and is reused by the H-02 Stage-1 compatibility-state fixtures. Diagnostic ID Severity Phase Behavior Next action Frozen meaning Required facts DS-WKO-001 ERROR WORK_ORDER_VALIDATION REFUSE NONE Work Order validation refuses before one of the seven governed operations can be identified. work_order_filename DS-MAT-010 ERROR MATERIALIZATION_VALIDATION REFUSE NONE Ordinary MATERIALIZE validation/routing refuses before Stage 1 begins after the source reference is established, excluding the specialized damaged-lineage and malformed-MAP routing conditions allocated by Day 060 H-12. source_filename DS-MAT-011 ERROR CSV_DECODING REFUSE NONE MATERIALIZE Stage 2 refuses on a governed structural CSV condition. source_filename csv_refusal_condition csv_source_byte_offset csv_physical_line csv_logical_record csv_field_ordinal DS-MAT-012 ERROR MATERIALIZATION_GATE REFUSE NONE MATERIALIZE post-Stage-2 gate refuses because existing-Store source cardinality does not match the inherited RID cardinality. source_filename base_map_filename rid_filename source_row_count rid_row_count DS-MAT-013 ERROR STORE_PUBLICATION REFUSE NONE MATERIALIZE governed Store-artifact filename identity allocation refuses after collision-retry exhaustion before any new Store artifact becomes authoritative. artifact_class collision_retry_count DS-INV-001 ERROR INVENTORY_VALIDATION REFUSE NONE INVENTORY validation refuses before the inventory scan begins. work_order_filename DS-INV-002 ERROR INVENTORY_SCAN REFUSE NONE INVENTORY scan/measurement refuses for an identified immediate Suitcase entry before a complete snapshot is established. entry_name DS-INV-003 ERROR INVENTORY_PUBLICATION REFUSE NONE INVENTORY governed INV filename identity allocation refuses after collision-retry exhaustion after the snapshot facts are established. artifact_class collision_retry_count DS-ALS-001 ERROR ALIAS_VALIDATION REFUSE NONE UPDATE ALIASES validation/routing refuses before an exact base Store MAP is established. work_order_filename DS-ALS-002 ERROR ALIAS_GATE REFUSE NONE UPDATE ALIASES refuses after the exact base Store MAP is established but before successor publication. base_map_filename DS-ALS-003 ERROR STORE_PUBLICATION REFUSE NONE UPDATE ALIASES successor-MAP filename identity allocation refuses after collision-retry exhaustion. artifact_class collision_retry_count DS-RPM-001 ERROR REPAIR_MAP_VALIDATION REFUSE NONE REPAIR MAP validation refuses before an exact target MAP/RID pair is established. work_order_filename DS-RPM-002 ERROR REPAIR_MAP_ANALYSIS REFUSE NONE REPAIR MAP analysis refuses before a complete repair result is established. target_map_filename DS-RPM-003 ERROR REPAIR_MAP_ANALYSIS REFUSE NONE REPAIR MAP deterministically refuses because every mapped COL is broken and retained COL count is zero. target_map_filename broken_col_count DS-RPM-004 ERROR STORE_PUBLICATION REFUSE NONE REPAIR MAP successor-MAP filename identity allocation refuses after collision-retry exhaustion after repair analysis is established. artifact_class collision_retry_count DS-WKR-001 ERROR WORK_ORDER_REGISTRY_VALIDATION REFUSE NONE REPAIR WORK ORDER REGISTRY validation refuses before the current structurally valid WKO MAP is established. work_order_filename DS-WKR-002 ERROR WORK_ORDER_REGISTRY_REPAIR REFUSE NONE REPAIR WORK ORDER REGISTRY repair-plan/gate processing refuses after the base WKO MAP is established. base_wko_map_filename DS-WKR-003 ERROR WORK_ORDER_REGISTRY_PUBLICATION REFUSE NONE REPAIR WORK ORDER REGISTRY successor-WKO-MAP filename identity allocation refuses after collision-retry exhaustion. artifact_class collision_retry_count DS-CVT-001 ERROR CONVERSION_VALIDATION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 validation/classification refuses before bounded transcoding begins. source_filename DS-CVT-002 ERROR CONVERSION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 refuses after bounded transcoding begins but before publication. source_filename DS-CVT-003 ERROR CONVERSION_PUBLICATION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 CVT filename identity allocation refuses after collision-retry exhaustion after conversion facts are established. artifact_class collision_retry_count DS-CAT-001 ERROR CATALOG_DISCOVERY REFUSE NONE CATALOG STORES validation/discovery refuses before the complete authoritative catalog row set is established. work_order_filename DS-CAT-002 ERROR CATALOG_PUBLICATION REFUSE NONE CATALOG STORES CAT filename identity allocation refuses after collision-retry exhaustion after the complete row set is established. artifact_class collision_retry_count Day 060 H-04 normalization: all allocated Diagnostic IDs in the current WASM-002 contract, including DS-CNV-001 , use exactly three ASCII uppercase letters in DOMAIN . No exception exists. Day 060 H-12 / BM-09 specialized diagnostic allocations The H-02 fixture diagnostics above are intentionally narrow. In particular, publication diagnostics whose required facts are only artifact_class and collision_retry_count mean identity-allocation collision exhaustion , not every possible publication failure. Other publication failures receive distinct registry allocations unless another requirement independently pins their Diagnostic ID. The following additional pre-freeze allocations are normative because existing Help duties require fact contracts that the broad H-02 fixture IDs cannot truthfully carry. Every row has severity: ERROR , behavior: REFUSE , and next_action: NONE except DS-MAT-017 , whose next_action is RUN_REPAIR_MAP . optional_facts is empty unless another requirement explicitly extends it. Diagnostic ID Severity Phase Behavior Next action Frozen meaning Required facts DS-MAT-014 ERROR MATERIALIZATION_ROUTING REFUSE NONE MATERIALIZE is blocked because exact source routing identifies a current INVALID Store lineage whose governed RID is missing or invalid. source_filename current_map_filename rid_filename store_health DS-MAT-015 ERROR MATERIALIZATION_ROUTING REFUSE NONE MATERIALIZE is blocked because exact source routing identifies a DEGRADED Store whose every mapped non-RID COL is missing or invalid, so REPAIR MAP cannot publish a non-empty successor. source_filename current_map_filename rid_filename store_health mapped_col_count broken_col_count DS-MAT-016 ERROR MATERIALIZATION_ROUTING REFUSE NONE New-Store creation is blocked because no routable Store lineage can be established while one or more structurally malformed Store-MAP-class artifacts are visible in the active Suitcase. source_filename malformed_map_filenames DS-MAT-017 ERROR MATERIALIZATION_ROUTING REFUSE RUN_REPAIR_MAP MATERIALIZE is blocked because exact source routing identifies a current DEGRADED Store whose governed RID is valid and whose mapped non-RID COL set contains at least one broken COL and at least one surviving valid COL, so a separate governed REPAIR MAP operation is available. source_filename current_map_filename rid_filename store_health broken_col_count DS-UTC-001 ERROR PUBLICATION_CHRONOLOGY REFUSE NONE A successor Store MAP or WKO MAP publication is blocked because truthful observed host UTC is not strictly greater than the canonical chronology predecessor UTC. map_profile observed_host_utc predecessor_map_filename predecessor_utc Day 060 H-26 / BM-09 allocation: DS-MAT-017 is the ordinary repairable-DEGRADED routing refusal. store_health is exactly DEGRADED ; broken_col_count is the exact number of mapped non-RID COL bindings that fail the applicable Store-health validation at this routing gate and is at least 1 . The condition excludes the all-COLs-broken case allocated to DS-MAT-015 . current_map_filename is the exact current structurally valid Store MAP that a separate REPAIR MAP Work Order must name. RUN_REPAIR_MAP is a safe next-action token only; it never causes automatic repair. Closed-world Help consequence: Help may render the richer damaged-lineage, malformed-MAP, and monotonic-UTC explanations only from the applicable specialized diagnostic event above. It must not borrow undeclared facts from DS-MAT-010 or from a collision-exhaustion publication diagnostic merely because those facts are available elsewhere at runtime. Cross-operation UTC rule: DS-UTC-001 has one stable semantic condition across Store-MAP and WKO-MAP successor publication. The required map_profile fact tells closed-world Help which governed MAP profile encountered the chronology guard: STORE means Store MAP and WKO means Work Order registry MAP. Help must select profile-appropriate explanation and analyst exits only from that declared fact and the other registered event facts; it must not infer the profile from filename shape, surrounding host state, or an undeclared operation field. The shared Diagnostic ID therefore does not need profile-specific clones.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002,Three-voice parity,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help Engine must support the three established Data Sculptor help voices. All three renderings must preserve the same diagnostic truth. Voice selection may change wording, sentence structure, degree of technical detail, and explanatory style. F-24 session default and persistence: Technical is the canonical Help voice at the start of every new browser application instance. The analyst may select Casual or Office Speak during that instance, but WASM-002 retains the selected voice only in volatile runtime state and does not persist the preference in browser-private storage. A new application instance therefore returns to Technical. This default does not alter the F-17 rule that a missing diagnostic-specific catalog entry visibly falls back to Generic Technical Help.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.1,Voice selection must not change diagnostic identity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.2,Voice selection must not change severity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.3,Voice selection must not change counts or evidence.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.4,Voice selection must not change whether execution continues or refuses.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.5,Voice selection must not change safe/unsafe action boundaries.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.6,Voice selection must not change provenance.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.7,Voice selection must not change the meaning of the recommended next step.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Tests must assert parity on the canonical event and structured facts, not brittle equality of prose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.8,One validated Help message catalog is the source of truth for all three voices,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help layer resolves a canonical diagnostic ID through one validated catalog that associates an authored ID with Casual, Office Speak, and Technical templates. The human-maintained development source is exactly help_messages.json , encoded as UTF-8 without BOM. help_messages.json is a Data Sculptor product/build resource, not a Suitcase artifact. It must not use the __DS__ governed artifact namespace, consume a semantic artifact-class token, or be copied into an analyst's Suitcase merely because Data Sculptor runs. Run-specific structured facts remain authoritative in the canonical diagnostic event and are supplied separately to the selected template. The three authored voices must not be maintained as unrelated message stores. F-17 coverage fallback: absence of an authored catalog entry for an otherwise complete registered diagnostic is permitted at run time and does not make the diagnostic incomplete. Data Sculptor must instead render the deterministic Generic Technical Help view defined by W002-HELP-002.9. The fallback consumes only the canonical event semantic core and its emitted governed facts; it is not a second message catalog and does not manufacture replacement diagnostic facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.9,WASM-002 may use mechanically generated placeholder voice text to prove Help wiring,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance does not require the complete production Help corpus. Authored catalog entries may use unmistakable placeholder strings, and placeholder entries may be generated mechanically from the validated diagnostics.json registry; no production prose authorship is required. Deterministic Generic Technical Help fallback. When a complete registered canonical diagnostic has no matching entry in help_messages.json , all selected Help voices fall back visibly to one Generic Technical rendering. The rendering must show, in this exact conceptual order, the diagnostic ID, severity, phase, behavior, next-action token, and then every emitted governed fact ordered by ascending UTF-8 byte order of fact key. It must state that no diagnostic-specific authored explanation is available. It must not infer cause beyond the diagnostic, invent remediation, default missing facts, inspect undeclared external state, or substitute prose for governed fact values. The Generic Technical fallback preserves the original diagnostic unchanged. Catalog incompleteness is therefore distinct from diagnostic incompleteness: a valid event can always be rendered generically, while inability to satisfy the event's own required_facts contract suppresses that intended event and produces DS-HLP-001 under W002-HELP-001.4 and W002-HELP-001.8. Acceptance must prove correct diagnostic-ID lookup, selected-voice resolution, structured-fact interpolation where a template exists, voice switching, deterministic Generic Technical fallback for a deliberately absent catalog entry, and semantic parity across authored voices. Final authored Help wording, examples, editorial polishing, and production-corpus quality remain deferred to a later Help-content milestone.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.10,help_messages.json has one deterministic WASM-002 source schema,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The top-level JSON object has exactly two fields: catalog_version and messages . catalog_version is the string ""1"" . messages is an array written in ascending UTF-8 byte order of diagnostic_id . Each message entry has exactly four fields: diagnostic_id , casual , office_speak , and technical . diagnostic_id must satisfy the canonical DS-<DOMAIN>-<NNN> grammar and must be unique in the catalog. Each voice field is a JSON string. A voice string may contain zero or more structured-fact placeholders using the exact form {fact_name} . Each catalog diagnostic_id must exist in the validated diagnostics.json registry, and each referenced placeholder must be declared in that diagnostic's required_facts or optional_facts . Duplicate IDs, missing voice fields, null voice values, malformed JSON, noncanonical or unregistered diagnostic IDs, or undeclared fact placeholders make catalog validation fail. The catalog is intentionally allowed to be non-exhaustive. A registered diagnostic with no message entry is rendered through the deterministic Generic Technical fallback in W002-HELP-002.9. Therefore a missing catalog entry for a registered diagnostic is not a build-validation failure and must not cause the engine to synthesize an authored entry or suppress the diagnostic. WASM-002 therefore does not require one global exhaustive fact-name table in the PRD. Fact-key authority is per diagnostic: the validated registry declares which fact names are legal for each stable diagnostic meaning. {
  ""catalog_version"": ""1"",
  ""messages"": [
    {
      ""diagnostic_id"": ""DS-ENC-001"",
      ""casual"": ""[CASUAL PLACEHOLDER] {source_filename}"",
      ""office_speak"": ""[OFFICE PLACEHOLDER] {source_filename}"",
      ""technical"": ""[TECHNICAL PLACEHOLDER] {source_filename} {first_invalid_byte_offset} {stop_reason}""
    }
  ]
} Later Help-content revisions may extend or version this schema only through an explicit PRD revision. F-07 placeholder mapping: Help for the strict UTF-8 refusal may render {first_invalid_byte_offset} and {stop_reason} because those exact fact names are declared by the canonical DS-ENC-001 diagnostic registry entry. The older generic {byte_offset} placeholder is not valid for DS-ENC-001. P2-03 Help rendering duty: Help for the monotonic-UTC refusal must identify the exact blocking predecessor MAP and show both predecessor UTC and truthful observed host UTC. It must distinguish an incorrect host clock from a genuinely future-dated governed MAP and may explain the approved analyst-owned choices: correct the clock, wait/rerun after truthful time advances, or deliberately move the exact future-dated current MAP out of the active Suitcase root with the warning that an older snapshot/registry may become current and that restoring the moved MAP may restore its authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.11,The validated Help catalog is embedded into the released HTML build and supplied to the shared core,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Before a WASM-002 browser build is accepted, the build must parse and validate help_messages.json , then serialize the validated catalog directly into the Data Sculptor HTML itself as one non-executable application/json payload with the exact element ID ds-help-catalog . The embedded JSON must be HTML-safe so catalog text cannot terminate the containing script element; at minimum, literal less-than characters in JSON string content must be escaped during embedding. At runtime, the browser host obtains this embedded payload and supplies the validated catalog to the shared Rust/WASM Help core. Browser JavaScript must not implement a competing template-selection, fact-interpolation, fallback, escaping, or HLP-semantic engine. The browser host must not fetch a Help catalog from the network, the filesystem, the Suitcase, or an adjacent deployment file. Missing or malformed embedded catalog JSON, or a build whose embedded catalog does not correspond to the validated build input, is a build-validation failure. The released HTML therefore remains one offline portable front door for the browser Help catalog. A later native host may supply the same governed catalog semantics to the same shared core from its own build-bundled resource; host packaging may differ, but Help semantics must not fork.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003,Message and report outputs,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The Help Engine must support both live and durable help surfaces.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003.1,The Help Engine must support a concise human-facing message suitable for the live browser surface.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The concise message is rendered in the dedicated browser Help / Diagnostic Surface when that surface is present; it is not required to be a modal or transient notification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003.2,"The Help Engine must support a durable HTML Help report using the canonical built-in Data Sculptor presentation suitable for saving with the Work Order, receipt, and output artifacts.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"A concise Help message for an individual diagnostic and any durable Help Report that includes that diagnostic must resolve from the same canonical diagnostic event. A durable Help Report request may cover one active governed diagnostic, including a non-run diagnostic, or one governed run containing one or more canonical diagnostic events. Exactly one HLP is published for each explicit Help Report request.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004,HTML Help report content,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,A saved Help report must be able to include the following elements when relevant.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.1,Product and brand identity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.2,Plain-language summary.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.3,Stable diagnostic ID.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.4,What Data Sculptor observed.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.5,Evidence and structured facts.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.6,What the user can safely do next.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.7,Source/Work-Order context is governed by the HLP disclosure allowlist.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The report may include only source and Work Order context permitted by W002-HELP-010. Durable HLP disclosure is intentionally stricter than transient local Help because the HLP is a portable support-handoff artifact. A relevant governed alias or source header may enter the HLP only under the necessity and disclosure rules in W002-HELP-010. Source-header text is eligible only when Data Sculptor has structurally established an actual CSV header record under the governed parser. Record position alone does not make text a header. When no valid header record has been established, including the headerless-source refusal case, the HLP must use structural evidence such as the 1-based column ordinal, diagnostic condition/location, or an applicable operational fallback name and must not substitute field data from the first data row. Absolute local paths, entire Work Orders, Work Order comments, source rows/values, unrelated headers/aliases/columns, and unrelated Suitcase contents are not automatically eligible merely because they are available to the running application.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.8,Report-generation metadata preserves HLP identity and lineage.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The report must carry its own governed HLP filename and generation UTC together with the diagnostic identity and applicable originating execution lineage. The exact HLP provenance contract is governed by W002-HELP-009.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.9,Selected Help voice and its human-facing explanation.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.10,A clearly labelled structured-facts block derived from the canonical diagnostic event.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.11,Four canonical Boolean facts describe the WASM-002 execution boundary.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When the governed diagnostic context can determine the execution boundary, the canonical fact names are exactly: source_modified_by_data_sculptor materialization_started analytical_outputs_published store_state_committed When one of these facts has an established Boolean value, the JSON/structured value is the native Boolean true or false , never the strings ""TRUE"" or ""FALSE"" . source_modified_by_data_sculptor states only whether Data Sculptor modified the analyst-owned source in place; it must not imply knowledge that no external process or analyst changed the source between sessions. materialization_started records whether the governed analytical materialization phase began. analytical_outputs_published records whether governed analytical outputs were successfully published for user use; transient SCR candidates or abandoned/uncommitted debris do not make this fact true. store_state_committed records whether the successor Store MAP commit point was crossed. If a present boundary fact must express governed absence rather than an established Boolean, its JSON/structured value is the exact applicable shared absence-state string ""NONE"" , ""NOT_RUN"" , ""NOT_AVAILABLE"" , or ""NOT_APPLICABLE"" . JSON null is not a valid encoding for these four boundary facts because it would discard the reason for absence. A boundary fact that is optional for a particular diagnostic may instead be omitted under W002-HELP-001.4; that omission carries no absence-state meaning. A missing, omitted, unavailable, or not-run fact must never be interpreted as false . If one of these facts is declared required for an intended diagnostic and the required value cannot be produced, it must not be silently defaulted; the intended diagnostic is suppressed and the fail-safe DS-HLP-001 contract in W002-HELP-001.4/W002-HELP-001.8 applies.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.12,Governed Work Order lineage sufficient to establish user intent.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,Included lineage must obey the disclosure boundary defined for Help reports and must not automatically expand into source-data disclosure.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-005,Deterministic rendering uses a closed governed input set,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Given the same canonical diagnostic event or ordered set of events, selected voice, PRETTY rules, validated Help catalog, and built-in presentation version, Help rendering must be deterministic except for explicitly permitted event/report-specific fields. The Help renderer may consume only the canonical diagnostic fields and fact keys declared by the applicable diagnostic registry entries plus fields explicitly defined by the applicable HLP provenance schema. It must not inspect or interpolate an open-ended host-state bag, undeclared browser state, unrelated Suitcase contents, or another value merely because it is available at runtime. A future configurable Brand Manifest may add another governed presentation input, but it is not part of the WASM-002 rendering contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-006,Host parity uses one shared Help semantic core,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help Engine must be designed for use by the browser host and the later native CLI host without changing diagnostic semantics. The shared Rust core owns diagnostic-to-template selection, governed fact interpolation, deterministic fallback behavior, governed escaping, and durable HLP semantic serialization. The WASM-002 browser host supplies the validated catalog embedded under W002-HELP-002.11. A later native host may supply the same governed catalog semantics from a build-bundled native resource. Host-specific presentation and packaging may differ, but they must not create a second Help semantic engine or change canonical diagnostic identity, facts, behavior, next action, voice semantics, disclosure policy, or HLP meaning.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-007,"Help surfaces are projections, not diagnostic authority",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The live Help / Diagnostic Surface and the saved HTML Help Report must render from the canonical diagnostic event. Neither surface may independently create, reinterpret, weaken, suppress, or override governed diagnostic truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008,HTML Help Report is a governed support-handoff artifact,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The user must be able to generate a styled, self-contained HTML Help Report from a governed diagnostic event for retention, IT/support handoff, or communication to another analyst. The report must support two audiences in one document: a human-readable explanation using the selected Help voice and a clearly inspectable structured-facts section that preserves the technical evidence required to understand the event.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008.1,"The report preserves the canonical execution-boundary facts, including relevant negative facts.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When relevant to the diagnostic, the report must render the governed values of source_modified_by_data_sculptor , materialization_started , analytical_outputs_published , and store_state_committed . These values originate from governed execution state rather than reassuring prose invented by the renderer. A missing/unavailable fact is not rendered as false .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008.2,The report preserves only the Work Order lineage needed to explain the diagnostic.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The report must identify the originating WKO physical filename when one applies and may include only the minimum executable Work Order clause or clauses needed to establish the governed operation, user intent, and trigger for the diagnostic. It must not automatically embed the entire Work Order or Work Order comments. All such context remains subject to the fixed disclosure boundary in W002-HELP-010.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-009,"WASM-002 establishes HLP identity, lineage, multiplicity, and one canonical embedded provenance payload.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"A durable generated Help Report is an immutable governed HLP artifact whose physical filename is: __DS__HLP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html The UTC token is the HLP's own governed generation/publication time. The report is the final self-contained HTML artifact using the canonical built-in Red5Sorcery/Data Sculptor presentation; no unstyled intermediate is the canonical HLP. Report-request multiplicity: one explicit Help Report request publishes exactly one HLP. The request may be bound to one active governed diagnostic, including a diagnostic that is not associated with a Run, or to one governed Run containing one or more canonical diagnostic events. A Run-level report includes the governed diagnostic events selected by that request in deterministic event order. HLP generation is never an automatic one-artifact-per-diagnostic side effect. Every HLP must expose a visible deterministic Provenance section and exactly one embedded non-executable application/json payload whose element ID is exactly ds-hlp-provenance . F-34 supersedes the earlier draft schema version ""1"" . For schema version ""2"" , the JSON top-level object contains exactly these ten fields: {
  ""schema_version"": ""2"",
  ""hlp_filename"": ""__DS__HLP__20260922T191500123Z__<uuid-v4>.html"",
  ""hlp_generation_utc"": ""20260922T191500123Z"",
  ""diagnostic_ids"": [""DS-ENC-001"", ""DS-MAT-004""],
  ""originating_wko_filename"": ""__DS__WKO__...txt"",
  ""originating_rcp_filename"": null,
  ""selected_help_voice"": ""technical"",
  ""presentation_id"": ""red5sorcery-data-sculptor"",
  ""presentation_version"": ""1"",
  ""data_sculptor_build"": ""<exact-build-id>""
} hlp_generation_utc must use the canonical fixed-width millisecond UTC form YYYYMMDDTHHMMSSmmmZ . diagnostic_ids is a non-empty JSON array containing one canonical diagnostic ID for each diagnostic event included in the report, in the same deterministic event order used by the report. Repeated IDs are permitted when distinct included events legitimately share one diagnostic type. selected_help_voice is exactly one of casual , office_speak , or technical , matching the Help catalog keys. For WASM-002 the built-in presentation identity is exactly red5sorcery-data-sculptor and its presentation version is exactly ""1"" . data_sculptor_build must contain the exact running build identifier used for the tested/released build; the literal scope label WASM-002 alone is not sufficient unless it is also the exact build identifier. originating_wko_filename and originating_rcp_filename are schema-declared nullable lineage fields . When the relationship exists and the exact physical filename is known, the value is that filename as a JSON string. When the relationship itself does not apply to this Help event/report request, the machine-readable value is JSON null . That null has one schema-defined meaning: the nullable relationship has no value, equivalent to Rust Option<T>::None and to the governed semantic state NOT_APPLICABLE . The visible Provenance section renders it as NOT APPLICABLE . If the lineage relationship does apply but the exact filename cannot be obtained, JSON null must not be used; the field value is the exact string ""NOT_AVAILABLE"" and the visible Provenance section renders NOT AVAILABLE . Empty strings, invented lineage, N/A , UNKNOWN , or another substitute are forbidden. For these two lineage fields, null and ""NOT_AVAILABLE"" are deliberately non-interchangeable. A non-run HLP may therefore legitimately carry JSON null for both lineage fields when neither relationship applies. This nullable-field rule is a schema-specific serialization choice, not a fifth absence state and not a generic JSON encoding rule. Other diagnostic JSON facts follow W002-HELP-001.4 and W002-HELP-004.11. The visible and machine-readable HLP provenance must express the same governed semantics even where their physical representations differ; a semantic mismatch is an HLP-generation failure and must not be silently tolerated. The embedded JSON must be HTML-safe so provenance text cannot terminate the containing script element; at minimum literal less-than characters in JSON string content must be escaped during embedding. The provenance payload remains subject to W002-HELP-010 and must not introduce source rows, source values, absolute local paths, arbitrary Work Order content, or other context excluded by the fixed HLP disclosure policy. WASM-002 does not automatically compute or embed a SHA-256 of the HLP, and saving an HLP must not create, refresh, or verify an LCK . The final HLP bytes remain eligible for exact-byte integrity evidence under the later explicit FINGERPRINT/LCK workflow. Configurable Brand Manifest provenance remains deferred to V1-BACKLOG / a future build. F-14 HLP publication: the complete self-contained report is first written as the corresponding SCR candidate under W002-STOR-023.1. It must close, reopen, and validate the required visible Provenance section, exact schema-version-2 embedded JSON shape, HTML-safe serialization, self-contained presentation and visible/machine semantic parity before the class token may be renamed from SCR to HLP . A partial or semantically mismatched candidate never becomes a canonical HLP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-010,Help Report disclosure uses one fixed WASM-002 allowlist.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Generating a Help Report must not silently become a data-export path. WASM-002 therefore uses one deterministic allowlist rather than collecting broad context and attempting to redact it afterward. There are no disclosure checkboxes, permissive export modes, or per-report overrides in WASM-002. Always eligible when present and applicable: diagnostic ID; severity/classification; governed operation/phase; continue/refuse decision; safe next action; selected Help voice; HLP identity and generation UTC; relevant governed artifact filenames; and the four canonical boundary facts from W002-HELP-004.11. Eligible only when necessary to explain the diagnostic: the exact source filename but not an absolute OS path; a relevant source column header only when Data Sculptor has structurally established an actual CSV header record; the relevant 1-based column number; a relevant governed Store/RID/COL alias only when that alias itself is necessary to explain the diagnostic, such as an alias collision, ambiguity, or governed alias mutation; byte offset, row/count, or byte-length evidence; Store/RID/COL/MAP/WKO physical filenames; and only the minimum executable Work Order clause or clauses needed to establish intent and the diagnostic trigger. If that minimum Work Order excerpt necessarily contains a governed alias, that alias is disclosed and counts as alias text included. Headerless boundary: record position alone never establishes a source header. If the governed parser has not established a valid header record, including a headerless-source refusal, HLP generation must not treat any field from the first data row or any later data record as header text. Structural evidence such as 1-based column ordinal, governed diagnostic/location facts, or an applicable operational fallback name must be used instead. Never included automatically: source rows; source field values or arbitrary data samples; field data mislabeled as header text; absolute local paths; unrelated source headers, aliases, or column names; the complete Work Order; Work Order comments; unrelated Suitcase contents; browser/environment internals not governed as diagnostic evidence; or raw ungoverned stack traces. Every generated HLP must contain a visible Disclosure section stating, at minimum: Source rows included: NO ; Source values included: NO ; Source header text included: YES or NO ; Governed alias text included: YES or NO ; Absolute local paths included: NO ; Work Order comments included: NO ; and Work Order excerpt: RELEVANT EXECUTABLE CLAUSES ONLY . The two YES/NO declarations must truthfully reflect the actual HLP bytes. A genuine established source header does not count as a source field value; this distinction applies only after the governed parser has established the header record. The renderer must not weaken any declaration when the underlying policy has not changed. This durable-HLP allowlist does not prohibit transient local Help from showing a relevant governed alias or a genuinely established source header when useful to explain the same canonical diagnostic event. Local presentation does not enlarge what the portable HLP may disclose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011,Help owns the cross-session source-continuity edge-case explanation,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When an unexpected analytical result, row-alignment concern, or support question raises the possibility that an analyst-owned source changed between sessions, Data Sculptor-controlled guidance must flow through the Help Engine. Help must not imply that the engine monitored or cryptographically protected the source when it did not. The explanation must distinguish ordinary analyst-controlled workflow from stronger optional evidence. It may ask whether the analyst edited, replaced, sorted, re-exported, synchronized, copied over, or otherwise changed the source after the Store was established.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011.1,Help presents continuity evidence in explicit assurance levels,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"For a suspected cross-session source change, Help must distinguish at least these evidence levels: No continuity evidence: state that cross-session byte continuity cannot be independently verified from filename/Store metadata alone. INVENTORY available: use filename, exact byte length, and last-modified metadata as lightweight clues; changed metadata may indicate that the source changed, while unchanged metadata must not be presented as proof of unchanged bytes. Explicit fingerprint evidence available: exact-byte SHA-256 evidence may establish whether the compared file bytes match or differ under the later governed FINGERPRINT workflow. Help must not collapse these levels into one generic statement of certainty.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011.2,WASM-002 does not impose automatic cross-session hashing or Suitcase surveillance,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Ordinary WASM-002 materialization and Store inheritance must not automatically SHA-256 the source, recursively fingerprint the Suitcase, or maintain hidden whole-Suitcase surveillance merely to guard against the possibility that an analyst-owned file changed between sessions. This is an intentional product boundary for the lone-office-analyst model. The product assumes the analyst normally controls the Suitcase, provides lightweight explicit INVENTORY evidence in WASM-002, preserves a later explicit FINGERPRINT path for stronger assurance, and relies on Help to explain unusual cross-session continuity questions proportionately. WASM-002 must not create, refresh, or silently verify an LCK Suitcase Lock as a side effect of Work Order save, materialization, Store inheritance, INVENTORY, alias maintenance, or ordinary project use. LCK publication belongs to the explicit later-V1 FINGERPRINT workflow. F-13 single-writer Help boundary: Help must distinguish cross-session continuity from concurrent writing. WASM-002 does not claim that two Data Sculptor tabs/windows can safely write the same Suitcase at once. User guidance must say to use one writing Data Sculptor context per Suitcase; read-only viewing is not itself a governed write. When a pre-commit guard detects that relevant governed state changed underneath an operation, Help must identify the changed authority where available and direct the analyst to refresh or reopen current state and rerun deliberately. It must not imply that Data Sculptor acquired a cross-tab lock, merged the competing work, or automatically rebased the refused transaction.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-001,Separation of truth and presentation,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,The PRETTY Engine must not decide analytical truth or reinterpret diagnostic meaning. It receives governed content and renders it into human-facing artifacts. WASM-002 conceptual boundary: ENGINE TRUTH -> HELP / REPORT CONTENT -> PRETTY ENGINE -> BUILT-IN DATA SCULPTOR PRESENTATION -> ARTIFACT. A future build may replace the built-in presentation source with a governed Brand Manifest without changing the analytical or diagnostic truth supplied to PRETTY.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-002,Shared renderer path,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"The PRETTY Engine must provide a common rendering path for Data Sculptor artifacts that require governed human presentation, including at minimum the WASM-002 Help HTML report. WASM-002 uses the canonical built-in Red5Sorcery/Data Sculptor presentation. The architecture must permit the same path to accept a configurable Brand Manifest in a future build without changing analytical semantics. The architecture must also permit later reuse for branded Receipt HTML, verification reports, tables, Quick Viz, and other PRETTY outputs. WASM-002 canonical run Receipts themselves remain TXT-only under W002-RCP-003.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003,Self-contained HTML,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"Durable HTML artifacts produced by PRETTY must be self-contained for ordinary viewing after generation. Self-containment requires semantic and functional portability, not pixel-identical rendering across operating systems or browsers; ordinary system-font substitution and browser rendering differences are acceptable when meaning, evidence, hierarchy, and accessibility remain intact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.1,A saved artifact must not require a network connection.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.2,A saved artifact must not require an external stylesheet.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.3,A saved artifact must not require a remote font.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.4,A saved artifact must not require a separately located logo file.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.5,A saved artifact must not require external presentation resources.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"Required CSS, SVG, and other built-in presentation assets needed for ordinary viewing must be embedded or otherwise resolved into the generated artifact at creation time. Future configurable Brand Manifest inputs, when implemented, must preserve this self-contained output rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-004,Accessibility and inspectability,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"PRETTY HTML must remain ordinary inspectable HTML. Presentation must not obscure the text, evidence, diagnostic code, provenance, or next-step guidance. The rendered artifact must remain usable without JavaScript when JavaScript is not required for its content.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-QA-001,Governed test-only seams and acceptance coverage,W002-QA,W002-QA,WASM-002,UNDER REVIEW,—,"Every material frozen WASM-002 behavior must have retained acceptance evidence sufficient to exercise the governed success, refusal, mutation, publication, or recovery boundary that makes the behavior meaningful. Related cases may share one fixture when the shared fixture proves each required condition explicitly; acceptance coverage must not rely on a behavior being difficult to reproduce under an uncontrolled host environment. Permitted deterministic test-only seams. WASM-002 acceptance may use controlled clock values; controlled UUID sequences and collision outcomes; controlled filesystem create/write/close/rename/promotion failures; and controlled run-local source-handle reread/substitution conditions. A seam supplies only the external condition required to reach the governed behavior. It must not bypass validation, alter the normative semantic result, change governed serialization, relax publication rules, rewrite diagnostic truth, or create a second analytical execution model. Release boundary. Test-only controls must not be invocable through the ordinary Data Sculptor UI, DS-STEPS, saved Work Orders, URL/query parameters, Suitcase configuration, or another analyst-facing product path. Compile-time exclusion, test-build configuration, or an isolated acceptance harness are permitted implementation techniques. Retained acceptance evidence must identify any seam used and must separately demonstrate that the accepted release surface cannot invoke that seam as a user feature. Named storage acceptance gaps. Acceptance must include a case-variant governed namespace/class fixture proving that Data Sculptor does not silently normalize the variant spelling into canonical governed identity; an unknown syntactically valid governed-class fixture proving that the file remains byte-for-byte unchanged while a canonical INFO diagnostic and INVENTORY surface the unknown/unrecognized class; and at least one known-but-not-emitted-class fixture drawn from DGN , RCV , BRD , or LCK proving the same preserve-and-report behavior without activating a producer, lifecycle, or interpretation path. Carried feature gates remain feature-owned. Mechanisms whose normative lifecycle is integrated in another package — including the F-02 Work Order-registry/alias-replacement behavior, the F-04 existing-Store cardinality refusal, and the F-24 CER-history decision — cannot be considered accepted without their corresponding feature acceptance gates. This requirement does not invent those feature semantics. If a proposed mechanism is removed from WASM-002 rather than integrated, no acceptance gate for that removed mechanism is required.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-001,UTF-8 certification pass,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,A valid multi-gigabyte UTF-8 fixture must complete whole-source certification with exact byte accounting under bounded memory.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-002,UTF-8 certification fail,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"A fixture containing an invalid UTF-8 sequence, including a sequence that crosses an input-window boundary, must deterministically produce STAGE1_UTF8_OUTCOME: FAIL , UTF8_STOP_REASON: INVALID_UTF8_SEQUENCE , and the exact governed zero-based UTF8_FIRST_INVALID_BYTE_OFFSET . Stage 2 must not begin and no analytical materialization output may be published. The same bytes tested under different permitted Stage-1 input-window sizes and boundary placements must yield the same outcome, stop-reason token, and first-invalid offset.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-003,Run-local source substitution refusal,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"An acceptance fixture must attempt to present Stage 2 with a different source instance/reference than the one retained from Stage 1. The run must refuse before materialization rather than accept the substitute merely because filename, alias, path, or byte length appears compatible. F-23 governed seam: this fixture must use the test-only source-handle substitution/reread seam permitted by W002-QA-001 so the different Stage-2 instance is injected without changing the analyst-visible SOURCE syntax or adding a product-level source-selection path. Release-surface evidence must demonstrate that an analyst cannot invoke this substitution seam through the normal UI, Work Order, URL/query, or Suitcase configuration.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-004,ASCII-only fast path,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,An all-ASCII fixture must certify successfully without invoking non-ASCII sequence validation and must produce exact byte accounting.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-005,Valid non-ASCII sequence matrix,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"Acceptance must cover valid two-byte, three-byte, and four-byte UTF-8 sequences, including sequences placed at window boundaries and split at every legal boundary position.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-006,Strict invalid-sequence matrix,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"Acceptance must reject at known exact offsets: lone continuation bytes, malformed continuation sequences, truncated sequences, overlong encodings, UTF-16 surrogate encodings, invalid lead bytes 0xC0 / 0xC1 , values introduced by 0xF5 - 0xFF , and code points above U+10FFFF. Every invalid fixture must serialize the same canonical UTF-8 stop reason INVALID_UTF8_SEQUENCE while preserving its fixture-specific exact first-invalid byte offset. For an EOF-truncated multibyte sequence, the expected offset is the lead byte of the incomplete sequence. Acceptance must include at least one malformed sequence crossing a Stage-1 input-window boundary and prove window invariance. Separate valid fixtures covering ASCII-only, valid multibyte UTF-8, and permitted leading-BOM forms must complete with STAGE1_UTF8_OUTCOME: PASS ; their UTF-8 refusal-only Receipt fields are NOT_APPLICABLE .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-007,Late invalidity,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,A source that is ASCII/valid UTF-8 until near EOF and becomes invalid late in the file must fail at the first invalid absolute offset; bounded-prefix success must not be treated as whole-file certification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-008,Window-size invariance,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,The same fixture matrix must return the same PASS/FAIL and first invalid absolute offset across at least two materially different bounded window sizes.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-009,EOF pending-state refusal,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,EOF with an incomplete UTF-8 sequence must fail deterministically and report the governed offset; no replacement character may be inserted.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-010,BOM behavior,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"A UTF-8 BOM at offset zero must be accepted as metadata while the remainder of the source is still fully certified; a BOM must not mask later invalid UTF-8. F-07 BOM coordinate fixture: when a permitted three-byte UTF-8 BOM precedes a later malformed UTF-8 sequence, the expected first-invalid offset counts the BOM's physical bytes. The BOM is excluded from analytical CSV content but included in the absolute physical source-byte coordinate system.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-001,Multi-column one-pass Stage 2 materialization,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Using a valid UTF-8 source and a Work Order requesting at least four source columns through a mixture of HEADER and COLUMN selectors, acceptance must prove that Stage 1 completes first, Stage 2 restarts at byte zero of the same run-local source instance, parses the header once, resolves all selectors before the first data row, and reads the source data records only once while producing all requested columns. Evidence must reconcile total source bytes read by Stage 2, logical data-row count N, per- COL data-record count N, selector-to-source ordinal/header resolution, resolved KEEP order, and the resulting successor MAP. A one-column rerun of the same source/column must produce the same canonical physical column bytes as that column produced inside the multi-column run, apart from governed artifact identity. F-20 width/one-pass acceptance: acceptance must include a maximum-width fixture whose valid source has exactly 16,384 columns and whose KEEP resolves all 16,384 distinct columns. Instrumentation must prove one source data-record traversal regardless of the implementation's bounded post-scan spool/finalization strategy. A companion 16,385 -column source must refuse during header resolution before the first data record is consumed.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002,"Automatic Store MAP creation, inheritance, and rematerialization continuity",W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must materialize four previously unseen source columns in one Store-establishing Work Order and prove that one successor Store MAP is created with four mapping rows. Every row must repeat identical Store-level fields, bind the newly created RID filename, default store_alias to the exact Store-establishing source filename, default rid_alias to RID , and default each COL alias to its exact source header. A later Work Order using the same exact SOURCE without explicitly naming a MAP must route under W002-STOR-019.2 . If exactly one routable Store lineage exists for that exact source filename and its current Store state permits materialization, the Work Order must inherit that lineage’s current structurally valid Store MAP, preserve the Store/RID metadata and four prior mappings, add a fifth default COL alias, and publish one new complete Store MAP. A later rematerialization of one earlier logical column must preserve its inherited COL alias while updating its column_filename . An explicit older MAP selection must instead use that historical Store state. Equal-latest-timestamp ambiguity within one routed lineage, malformed-newer-MAP fallback within the same Store lineage, no-routable-Store-lineage creation, and multiple-routable-Store-lineages-for-the-same-source refusal must also be exercised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.1,Exact eight-column Store MAP serialization acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must validate the exact Store MAP header store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename , UTF-8 without BOM, LF line endings, deterministic mapping-row order, standard governed CSV quoting, and byte-for-byte repetition of store_alias , rid_filename , rid_alias , and the common source_filename on every mapping row. The fixture must prove that a MAP with inconsistent repeated Store-level metadata, more than one rid_filename , more than one source_filename , a missing or invalid RID filename, a duplicate logical source-column key, or a non-eight-column schema is ineligible for inheritance. Source compatibility fixtures must prove that an explicit MAP may proceed only when the Work Order SOURCE exactly equals that MAP's common source_filename . A different source must refuse before materialization even when its row count equals the Store's RID cardinality; matching row count never creates a positional-join escape. P3-06 validation-tier fixtures: acceptance must distinguish Store-health Tier 1 from full Tier 2 validation. A same-named externally restored RID/COL may be treated as eligible only after it passes the tier required by the operation, and no fixture may label such an artifact “the exact original” solely from its physical filename. Tier-1 fixtures must prove the exact bounded checks in W002-STOR-019.10 without an end-to-end scan of every artifact value. Tier-2 fixtures must prove full RID sequence/cardinality validation and full COL canonical-form/header/cardinality validation. REPAIR MAP fixtures must demonstrate that the same input bytes yield one deterministic set of removed COL bindings under Tier 2. P2-04 closure fixtures: acceptance must include (1) a RID that satisfies Tier 1 but fails Tier 2 because the body does not contain the exact declared 1..N sequence; (2) a COL that satisfies Tier 1 but fails Tier 2 because its complete CSV body or logical-record count is invalid; (3) an externally supplied same-named RID/COL that passes the required governed tier without any assertion that it is the historical original bytes; and (4) a REPAIR MAP case with a mixture of Tier-2-valid and Tier-2-invalid COLs proving that the successor removes exactly the failing bindings. Repeating the same fixture bytes must yield the same repair set and successor mapping.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.2,Multiple Stores in one Suitcase remain distinct through RID-anchored MAP lineages,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must establish at least two Stores from different source files in the same Suitcase. Their Store MAP lineages must contain different immutable rid_filename values, and automatic routing for each source must choose only that source's routable Store lineage. The fixture must prove that a lineage remains routable when at least one Store MAP is structurally valid even if subsequent Store-health evaluation is DEGRADED or INVALID ; health may refuse the operation, but it must not make the lineage disappear from routing. Changing a human-facing store_alias or rid_alias in a later governed MAP must not change the Store's rid_filename , RID bytes, or lineage identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.3,WKO MAP profile and alias-registry publication acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must save at least three immutable WKO artifacts, each containing exactly one non-empty WORK ORDER AS clause: one with a multi-word alias, one whose alias is deliberately replaced under the frozen WKO lifecycle, and one with punctuation permitted by the governed string rules. The committed WKO MAP must satisfy the frozen current-registry schema and lifecycle rules, use UTF-8 without BOM and LF endings, preserve exact physical WKO references, and prove deterministic governed serialization. The fixture must prove that a WKO MAP cannot be treated as a Store MAP; duplicate physical WKO rows are invalid; conflicting current authority for the same non-empty alias is refused before commit; and equal-latest-timestamp ambiguity refuses current-registry selection. A saved/executable WKO without WORK ORDER AS is invalid in Revision BM and must refuse before execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.4,WORK ORDER AS and # comment lexical acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must prove that WORK ORDER AS ""Prepare monthly crime data"" is parsed as the immutable WKO alias, that whole-line and trailing # comments are ignored semantically, and that # inside double-quoted strings remains ordinary string content. The fixture must also prove that saved WKO bytes preserve comments exactly, that changing only a comment or Work Order alias requires a new WKO physical identity, and that no standalone browser Description value is required to reopen or display the governed alias. P3-10 alias fixture: acceptance must prove that WORK ORDER AS ""   "" refuses as a whitespace-only alias, while an otherwise valid alias containing leading or trailing whitespace is not silently trimmed or normalized and is preserved exactly in saved WKO bytes and the governed alias registry.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-003,Stage 2 structural window-invariance matrix,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Acceptance fixtures must force input boundaries at structurally difficult positions including before/after delimiters, before/after opening and closing quotes, between doubled quote bytes, between CR and LF, inside quoted multiline field content, at empty fields, and inside already-certified multi-byte UTF-8 sequences. Across permitted window sizes and boundary placements, the logical row count, selected values, canonical COL bytes, first refusal location/condition, and resolved mapping semantics must remain invariant. P3-09 fixtures: acceptance must include both byte forms identified by the Pass 3 finding: (1) an exactly zero-byte source and (2) a source containing only the three UTF-8 BOM bytes EF BB BF . Both must pass the applicable Stage 1 UTF-8 gate and then refuse in Stage 2 with NO_HEADER_RECORD . The exact expected location tuples are respectively (offset 0, physical line 1, logical record 1, field ordinal 1) and (offset 3, physical line 1, logical record 1, field ordinal 1) . The fixtures must also distinguish this case from an existing-but-blank first logical record, which remains BLANK_LOGICAL_RECORD . P3-10 delimiter-help fixture: acceptance must include a quoted semicolon-delimited form such as ""a"";""b"" and an equivalent TAB-delimited quoted form that reach INVALID_BYTE_AFTER_CLOSING_QUOTE . The canonical refusal condition and location facts must remain unchanged, while the Help rendering is permitted to surface the delimiter-mismatch hint for offending byte 0x3B or 0x09 . F-06 structural-refusal acceptance matrix An unexpected quote in an unquoted field must report the quote byte and UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD . A prohibited byte after a closing quote must report that byte and INVALID_BYTE_AFTER_CLOSING_QUOTE . A bare CR outside quoted content must report the CR byte and BARE_CR_OUTSIDE_QUOTED_FIELD . CR, LF, and CRLF inside valid quoted values must remain field content and must not trigger the bare-CR rule. EOF in an open quoted field must report the one-past-end source offset and EOF_INSIDE_QUOTED_FIELD . A blank logical record must report BLANK_LOGICAL_RECORD , not TOO_FEW_FIELDS . A short record must report the terminator/EOF location and the first missing field ordinal. A wide record must report the comma delimiter opening the first extra field and that extra field ordinal. All five refusal facts must remain identical across permitted source-window sizes and boundary placements. Fixtures must force boundaries around commas, opening and closing quotes, doubled-quote pairs, CR/LF pairs, quoted multiline content, empty fields, and already-certified multibyte UTF-8 sequences. A semicolon-separated file must not refuse solely because it uses semicolons; Help may explain comma-only interpretation when header selection fails. Day 060 H-13 Receipt-corpus binding for P3-09 The two analytical P3-09 source fixtures above must each have a corresponding byte-exact refusal Receipt under W002-RCP-ACC-002. The zero-byte and BOM-only cases therefore prove both the parser/refusal oracle and the Receipt serialization oracle independently.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-004,Canonical one-column COL serialization acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Golden-byte fixtures must cover ordinary ASCII, non-ASCII UTF-8, commas, embedded double quotes, CR, LF, CRLF inside quoted values, explicit empty data values, empty source headers, and header-only zero-row input. Acceptance must prove one UTF-8 BOM at file start, LF record termination independent of host platform, deterministic minimal quoting, doubled embedded quotes, """" for an empty one-column data value, no accidental inclusion of the source BOM in the first header, and byte-identical round-trip semantics through the Data Sculptor CSV reader. F-20 oversized-header serialization acceptance: fixtures at exactly 1,024 and 1,025 Unicode scalar values must prove that the physical COL header remains byte-faithful to the exact decoded source header while only the operational/default-alias name changes at the boundary. Scalar-count fixtures must include combining characters so acceptance cannot accidentally measure UTF-8 bytes or grapheme clusters instead.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-005,"Field-limit, ragged-record, blank-record, and failure-publication acceptance",W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Acceptance must include decoded field sizes exactly 16 MiB and 16 MiB + 1 byte, malformed runaway quoted-field cases, nonblank records with too few and too many fields, a bare blank logical data record, explicit empty fields, and a physical blank line inside a valid quoted multiline field. The first invalid case must refuse without truncation or silent repair. Publication evidence must additionally exercise both a new-Store multi-column materialization and a later existing-Store materialization. For the new Store, the shared publication-transaction UTC must be established before any new RID/COL SCR candidate is opened, and each candidate-specific UUID must be allocated before its candidate is created. RID and COL outputs must remain governed SCR until the complete candidate set validates; the RID must then promote first, requested COLs must promote in deterministic KEEP order, the successor MAP UUID must be allocated before its MAP SCR candidate is opened, that MAP candidate must be written/closed/reopened/validated while still SCR , and its final SCR -to- MAP rename must occur last. For every successfully promoted RID, COL, and MAP artifact, acceptance must prove that the candidate and final identity have the exact same UTC, UUID, extension, and bytes and differ in the governed filename only by the three-letter semantic class token. For the existing Store, the inherited RID must remain byte-for-byte and filename-identical with no new RID candidate. F-04 existing-Store cardinality acceptance: acceptance must include two otherwise valid existing-Store materializations using the same exact governed SOURCE identity. In the equal-cardinality fixture, Stage 2 candidate N must equal the inherited RID-header N and publication may proceed under the ordinary rules. In the mismatch fixture, candidate N must differ from RID-header N ; the Run must refuse before any candidate COL is promoted into the final COL namespace and before any successor MAP is published. The inherited RID, current MAP, existing COL artifacts, and Store health must remain unchanged, with the existing Store remaining VALID. The equal-cardinality case must not be represented as proof of source-byte or row-semantic identity. Forced failure cases must cover: failure before any promotion; RID-promotion failure; failure during COL promotion after RID and at least one COL have promoted; MAP-candidate write/close/reopen/validation failure; MAP final-rename failure; and interruption after physical RID/COL promotion but before MAP commit. Each case must prove rollback where safely possible or visible non-authoritative SCR failure evidence otherwise, must prove that unreferenced final-class-looking RID/COL files are not treated as committed Store membership, and must prove that the prior valid MAP remains authoritative for an existing Store or that no committed Store exists for an uncommitted first materialization. F-20 bounded-width/name acceptance: acceptance must cover exactly 16,384 versus 16,385 source columns; KEEP widths of 1 and 16,384 ; operational-name derivation at 1,024 versus 1,025 Unicode scalar values; physical ordinals producing Column A , Column Z , Column AA , and Column XFD ; and deterministic oversized-header fallback collisions proving [ordinal] then -2 progression. A separate short-header alias collision must prove refusal rather than automatic suffixing.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-006,Large-source browser materialization evidence,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance must include a browser run against the established Statistics Canada scale source or an equivalently retained scale fixture, recording source bytes, Stage 1 time, Stage 2 time, total time, selected-column count, logical row count, bytes written per COL , peak/bounded memory observations, output fingerprints, and browser/platform details. The retained Day 039 evidence established that Microsoft Edge could stream the 7,250,808,204-byte source through a small Rust/WASM materializer and materialize 29,014,718 VALUE data rows in practical time. Revision AM treats that result as engineering evidence and a comparison baseline, not as proof that WASM-002 is already implemented or as a frozen wall-time threshold. F-20 writer-resource evidence: retained acceptance evidence must identify the build's configured maximum simultaneously active writable-output resources and the observed peak for the run. Evidence must show that wide KEEP cardinality does not imply one simultaneously open writer per selected column and that any bounded spool/finalization strategy preserves the same governed output bytes and semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-ACC-001,Separate Windows-1252 conversion,W002-CONV-ACC,W002-CONV,WASM-002,UNDER REVIEW,—,"A non-UTF-8 fixture compatible with the supported Windows-1252 converter must cause the analytical task to stop, permit a Help suggestion, and succeed only when the separate conversion Work Order is explicitly run. P3-08 acceptance: the fixture set must convert an analyst-owned legacy source successfully, materialize the resulting CVT, then perform a second successful conversion from a refreshed legacy source using the same analyst-owned filename. The second conversion must publish a different CVT physical filename. First materialization of that second CVT must establish a distinct Store/RID lineage rather than inherit from the first CVT-backed Store. Acceptance must also prove that Help discloses this consequence at conversion success and again when the CVT is first materialized, and that no hidden original-source identity is used to join the two CVTs into one lineage. F-16 acceptance: the compatible non-UTF-8 fixture must prove that strict UTF-8 certification first emits DS-ENC-001 with next_action: NONE ; Stage 2 does not start; Data Sculptor restarts at byte 0 of the same bound source instance and scans the complete source under the frozen mapping; the Receipt records WINDOWS_1252_COMPATIBILITY_OUTCOME: COMPATIBLE and WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET: NOT_APPLICABLE ; and only then is DS-CNV-001 emitted with severity: INFO , behavior: CONTINUE , and next_action: RUN_WINDOWS_1252_CONVERSION . The refused MATERIALIZE run must remain refused. A separate valid-UTF-8 fixture must prove that both Windows-1252 compatibility Receipt fields are NOT_RUN and DS-CNV-001 is not emitted. F-10 conversion-gate and byte-output acceptance A source already valid as complete strict UTF-8 must refuse CONVERT WINDOWS-1252 TO UTF-8 as unnecessary and create no CVT . A source that fails strict UTF-8 but passes the complete Windows-1252 compatibility assessment may convert only when the separate conversion WKO is explicitly run. The analyst-owned source bytes must remain unchanged. The published CVT must pass complete strict UTF-8 certification. Source CR, LF, and CRLF bytes must be preserved in place rather than normalized. The conversion must remain bounded/streaming. The published CVT must not begin with a UTF-8 BOM introduced by Data Sculptor. The successful Receipt must contain the frozen conversion operation token and required conversion facts. Frozen minimal byte oracle: Windows-1252 source bytes:
63 61 66 E9 0D 0A

UTF-8 CVT bytes:
63 61 66 C3 A9 0D 0A This is café followed by CRLF. The expected CVT begins with byte 63 ; no EF BB BF prefix is present. Day 060 H-25 / BM-04 acceptance: the already-valid-UTF-8 CONVERT fixture must use a complete source whose byte stream is valid strict UTF-8 and must produce a byte-exact refused Receipt containing: SOURCE_ENCODING: UTF-8
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: NOT_RUN
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE The same fixture must prove that no Windows-1252 compatibility assessment runs, no transcoding begins, the analyst-owned source bytes remain unchanged, and no CVT file is created.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-ACC-002,Undefined Windows-1252 byte refusal,W002-CONV-ACC,W002-CONV,WASM-002,UNDER REVIEW,—,"A fixture containing a byte undefined by the frozen Windows-1252 mapping must not be silently converted. F-16 acceptance: use fixtures placing each of 0x81 , 0x8D , 0x8F , 0x90 , and 0x9D at controlled physical offsets, including across compatibility-buffer boundaries. The complete oracle must prove WINDOWS_1252_COMPATIBILITY_OUTCOME: INCOMPATIBLE , the exact first undefined-byte offset, no DS-CNV-001 emission, no conversion recommendation, and window-size invariance. A separate injected read-failure fixture after the compatibility pass begins must prove NOT_AVAILABLE for both compatibility Receipt fields and no conversion recommendation. F-10 conversion-operation undefined-byte acceptance The separate CONVERT WINDOWS-1252 TO UTF-8 operation must itself refuse before transcoding when its complete compatibility assessment encounters any byte undefined by the frozen Windows-1252 mapping. Such a refusal publishes no CVT . Acceptance must cover each frozen undefined byte value at a controlled absolute source offset and prove that no replacement-character, ISO-8859-1, or permissive-decoder fallback produces output. Day 060 H-14 / BM-11 byte-exact undefined-byte CONVERT fixture The golden CONVERT refusal fixture uses this exact analyst-owned source byte sequence: 41 81 42 The strict UTF-8 gate must fail, and the subsequent complete Windows-1252 compatibility assessment must encounter 0x81 as the first undefined byte at exact zero-based absolute physical source-byte offset 1 . The operation must refuse before transcoding begins. The byte-exact Receipt for this fixture must include: SOURCE_ENCODING: WINDOWS-1252-INCOMPATIBLE
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: 1
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE
RESULT: REFUSED The analyst-owned source bytes must remain exactly 41 81 42 ; no CVT is published; no replacement character is introduced; and no ISO-8859-1 or permissive-decoder fallback is permitted. A second acceptance form must place at least two undefined Windows-1252 bytes in one source and prove that the reported offset is always the first undefined byte. Buffer/window-boundary variants must preserve the same absolute offset.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-001,Canonical diagnostic event,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,At least one real governed WASM-002 failure path must emit a complete canonical diagnostic event with stable code and structured facts. A separate test-only fault-injection fixture must remove or withhold one required fact while the engine attempts to assemble a registered diagnostic. Acceptance must prove that the malformed intended diagnostic is not emitted and that exactly one canonical DS-HLP-001 replacement event is emitted with the exact intended diagnostic ID and the complete ascending-UTF-8 list of missing required fact keys.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-002,Three-voice rendering parity,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"A complete event with an authored catalog entry must be renderable in all three established Help voices. Automated checks must demonstrate invariant diagnostic truth across the three outputs. A separate complete registered diagnostic fixture must deliberately have no help_messages.json entry. Casual, Office Speak, and Technical selections must all resolve to the same deterministic Generic Technical Help fallback, preserving the original diagnostic semantic core and rendering emitted facts in ascending UTF-8 fact-key order without invented cause or remediation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-003,Saved HTML Help report using the canonical built-in Data Sculptor presentation,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,At least one complete HTML Help report using the canonical built-in Data Sculptor presentation must be generated and saved locally from that real event.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-004,Offline durability,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,The saved HTML report must remain readable with its canonical built-in Red5Sorcery/Data Sculptor presentation when opened without network access and without access to Data Sculptor or any external presentation resource.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-008,Support-handoff report acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"From a real governed refusal, Data Sculptor must generate one styled HTML Help Report that opens in an ordinary browser without Data Sculptor or network access and contains both a selected-voice explanation and the canonical structured facts needed by a technical reviewer.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-009,Canonical boundary-fact acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"An early-refusal fixture that stops before analytical materialization must demonstrate the exact four Boolean fact names from W002-HELP-004.11 and, when those are the true governed facts, values equivalent to: source_modified_by_data_sculptor = false
materialization_started = false
analytical_outputs_published = false
store_state_committed = false Acceptance must also exercise at least one boundary-fact case in which an established Boolean value is unavailable or otherwise carries an applicable governed absence state. The emitted value must use the exact shared JSON string token required by W002-HELP-004.11 (for example ""NOT_AVAILABLE"" ) and must not be coerced to false or JSON null . Where a boundary fact is optional and its key is omitted, acceptance must prove that omission is not interpreted as false or as any governed absence token. The same fixture family must prove that temporary SCR candidates or abandoned/uncommitted debris do not make analytical_outputs_published true.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-010,"HLP provenance, multiplicity, and no-automatic-hash acceptance",W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"Acceptance evidence must generate a final HLP using the built-in Red5Sorcery/Data Sculptor presentation and verify its governed __DS__HLP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html identity, its visible Provenance section, and exactly one embedded application/json payload with element ID ds-hlp-provenance . The embedded payload must contain exactly the schema-version-2 fields governed by W002-HELP-009 and must verify the same HLP filename/generation UTC, non-empty ordered diagnostic_ids array, WKO/RCP lineage semantics, selected Help voice, built-in presentation identifier red5sorcery-data-sculptor , built-in presentation version ""1"" , and the exact running Data Sculptor build identifier. Acceptance must cover: (1) an explicit request for a single diagnostic; (2) one governed Run with multiple included diagnostic events, proving exactly one HLP for the request and event-order parity with diagnostic_ids ; and (3) a non-run diagnostic such as Suitcase-validation or WKO-save refusal, proving that non-applicable WKO/RCP lineage is represented by JSON null and visible NOT APPLICABLE rather than invented Run lineage. Acceptance must also cover all three lineage representations permitted by W002-HELP-009: an exact physical filename when the relationship exists and is known; JSON null when the relationship does not apply; and the exact JSON string ""NOT_AVAILABLE"" when the relationship applies but its exact filename cannot be obtained. The fixture must prove that null and ""NOT_AVAILABLE"" are not interchangeable. Acceptance must prove that the visible Provenance section and machine-readable payload agree semantically; missing, duplicate, malformed, mismatched, non-HTML-safe, disclosure-violating, empty diagnostic_ids , or scope-label-only build provenance must not be accepted. The same acceptance must prove that ordinary HLP generation does not compute or embed an HLP SHA-256 and does not create, refresh, or verify an LCK . Exact-byte HLP integrity remains outside WASM-002 in the later explicit FINGERPRINT/LCK workflow.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-011,Fixed support-handoff disclosure acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"Acceptance must prove the fixed support-handoff disclosure boundary with both permitted-context and adversarial headerless fixtures. A permitted-context fixture must generate an HLP whose diagnostic requires a source filename, one genuinely established relevant source header and/or 1-based column number, bounded execution evidence, and a small executable Work Order excerpt. A governed alias may appear only when the alias itself is necessary to explain the diagnostic, such as an alias collision, ambiguity, or mutation; an unrelated alias must remain excluded. The report must include only the necessary permitted facts while excluding source rows/values, absolute local paths, unrelated headers/aliases/columns, the complete Work Order, Work Order comments, unrelated Suitcase contents, and raw ungoverned stack traces. A separate headerless-source fixture must place unmistakable sentinel text in the first data row and prove that none of that text appears in the HLP as a header or other disclosed source value. That HLP must show Source header text included: NO and Source values included: NO while still presenting sufficient structural evidence to explain the diagnostic. A genuine-header fixture must prove that a necessary established header may appear with Source header text included: YES . Alias fixtures must similarly prove truthful Governed alias text included: YES only when necessary and NO otherwise. Every fixture must verify the remaining frozen Disclosure declarations from W002-HELP-010. WASM-002 must expose no control that changes this fixed disclosure policy.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-012,Cross-session source-continuity Help acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"An acceptance fixture must present Help with a suspected cross-session source-change scenario and verify that the explanation asks whether the source may have been edited/replaced/sorted/re-exported/synchronized, distinguishes no evidence from INVENTORY metadata evidence and stronger explicit fingerprint evidence, and never claims that unchanged filename or unchanged INVENTORY metadata proves byte identity. A no-evidence fixture must state that continuity cannot be independently verified. An INVENTORY fixture with changed source byte length or last-modified metadata must describe the difference as evidence that the source may have changed, not as a cryptographic conclusion. The fixture must also confirm that ordinary WASM-002 materialization did not automatically hash the source as part of this edge-case protection.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-013,Diagnostic-registry and Help cross-validation acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance must retain the validated diagnostics.json used by the accepted build and verify its exact version-1 schema, canonical sort order, unique permanent IDs, fixed-token grammars, and disjoint required/optional fact declarations. At least one real governed diagnostic fixture must prove that the emitted semantic core matches the matching registry entry and that all required facts are present while no undeclared fact key is emitted. Negative build-validation fixtures must prove deterministic failure for malformed/duplicate registry entries, an engine diagnostic definition absent from the registry, fixed semantic disagreement, an undeclared emitted fact, a Help-catalog diagnostic ID absent from the registry, and a Help placeholder not declared for its matching diagnostic. F-17 runtime completeness fixtures: missing required facts are no longer treated as a malformed event that may leak to Help. Fault injection must prove deterministic substitution with DS-HLP-001 , including exact intended_diagnostic_id and sorted missing_required_facts , with no partially populated intended diagnostic emitted. Separately, a valid registered diagnostic omitted from help_messages.json must remain a valid build/runtime condition and must exercise the Generic Technical fallback rather than build failure or diagnostic suppression. F-22 QA-independence acceptance boundary: acceptance must prove the registry/engine/Help wiring and generic invariants without circularly presenting the implementation-delivered registry as an independent oracle for its own condition-to-Diagnostic-ID allocations. Representative governed fixtures must trace condition → emitted Diagnostic ID → matching registry semantic core → required/optional fact discipline → Help lookup/rendering. Every condition-to-ID or required-fact mapping explicitly frozen elsewhere in this PRD remains independently testable and must match that PRD contract. For allocations not independently pinned by this PRD, WASM-002 does not require a duplicate QA-owned registry that restates every condition-to-ID choice. Passing this acceptance gate therefore demonstrates registry integrity, engine↔registry semantic agreement, fact completeness/legality, Help-catalog wiring, F-17 fail-safe behavior, and representative end-to-end diagnostic routing; it must not be reported as exhaustive independent proof that every possible runtime condition was assigned the semantically correct Diagnostic ID. That residual independence limitation is an accepted WASM-002 risk. F-23 embedded Help-catalog release fixture: acceptance must build the released HTML from a validated help_messages.json , verify exactly one non-executable application/json payload with element ID ds-help-catalog , and include adversarial catalog text containing literal < / script-like delimiter content to prove HTML-safe embedding. Runtime instrumentation must prove that Help lookup reads only the embedded payload and performs no network, filesystem, Suitcase, or adjacent-file fetch for the Help catalog. A missing, malformed, mismatched, or unsafe embedded catalog must fail build acceptance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-007,Work Order syntax is the analytical contract,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"If a value, reference, option, or instruction changes what Data Sculptor analytically does, that intent must be represented in governed Work Order text or in a separately governed artifact explicitly referenced by that Work Order. Browser permission, directory selection, UI focus, a highlighted file, an alias display, or another GUI gesture must not silently become analytical intent. For WASM-002, every executable saved WKO begins with the common preamble: SUITCASE: .
WORK ORDER AS ""<non-whitespace alias>"" Ignoring blank lines and governed comments, the WKO must then parse completely under exactly one of these seven executable operation grammars: Operation Governed DS-STEPS structure after the common preamble MATERIALIZE SOURCE ""..."" ; optional MAP ""..."" ; KEEP ; one or more selectors; terminal MATERIALIZE . INVENTORY terminal INVENTORY only. UPDATE ALIASES exactly one Store-state selector: SOURCE ""..."" or MAP ""..."" ; one or more governed alias mutations; terminal UPDATE ALIASES . REPAIR MAP exactly one MAP ""<exact current Store MAP filename>"" ; terminal REPAIR MAP . REPAIR WORK ORDER REGISTRY terminal REPAIR WORK ORDER REGISTRY only. CONVERT WINDOWS-1252 TO UTF-8 exactly one SOURCE ""..."" ; terminal CONVERT WINDOWS-1252 TO UTF-8 . CATALOG STORES terminal CATALOG STORES only. Each operation-specific numbered requirement remains authoritative for its detailed selectors, preconditions, mutations, publication semantics, and acceptance behavior. This requirement freezes the cross-operation boundary: unknown semantic lines refuse; clauses from another operation grammar refuse unless the selected operation explicitly defines them; there is no best-effort interpretation and no silent cross-operation mixing. Lexical token separation. DS-STEPS keywords are matched ASCII case-insensitively; canonical examples render them uppercase. Wherever two adjacent lexical tokens would otherwise run together, they must be separated by one or more ASCII SPACE ( 0x20 ) or horizontal TAB ( 0x09 ) characters. Leading SPACE/TAB indentation is semantically neutral. Thus REPAIR MAP , SOURCE ""crime.csv"" , and COLUMN 7 are valid tokenizations, while REPAIRMAP , SOURCE""crime.csv"" , and UPDATE_ALIASES are not alternate DS-STEPS spellings. Quoted-string contents are never case-folded or whitespace-normalized merely because keywords are case-insensitive. The browser may authorize resources, edit text, validate, save, invoke Run, display evidence, and provide Help. Authorization to access a resource is not authorization to use that resource analytically.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-008,Every executable Work Order explicitly declares its Suitcase,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"For WASM-002, every executable saved Work Order must contain the exact portable declaration SUITCASE: . . The dot means the filesystem directory that physically contains the saved WKO artifact being executed. A Work Order lacking this declaration must not be treated as an executable WASM-002 Work Order. The declaration is analytical/execution syntax, not a substitute for browser filesystem permission. The host must still possess valid access to the directory before execution can proceed. Help obligation: Data Sculptor Help must explain SUITCASE: . in plain language: the saved Work Order uses the folder that contains that WKO as its Suitcase; the dot means “this folder”; ordinary Work Order file references are therefore portable and Suitcase-relative; and browser/host permission to the folder is granted separately. Help must not teach an absolute machine path as the normal replacement for . .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-009,Ordinary Work Order file references are Suitcase-relative,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Unless another numbered requirement explicitly governs a different reference mechanism, file references in an executable WASM-002 Work Order resolve relative to the declared Suitcase. A portable Work Order must not depend on an absolute machine-specific path to identify ordinary Suitcase files. Resolution must be deterministic in browser and later native hosts. Moving an intact Suitcase to another permitted filesystem location must not change the logical meaning of the Work Order solely because the parent machine path changed.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-009.1,WASM-002 SOURCE eligibility is exact and root-bounded,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"A WASM-002 SOURCE clause names exactly one physical regular file in the Suitcase root by exact filename only. It must not name an absolute path, drive or UNC path, subdirectory, path containing / or \ , traversal such as .. , URL/URI, or another external reference. Resolution uses the exact Unicode-scalar filename identity and reference-bounded rules frozen by F-15; no case-folding, normalization, trimming, or filesystem-equivalence search is permitted. The only eligible WASM-002 SOURCE kinds are: Analyst-owned CSV: a regular Suitcase-root file whose exact filename does not begin with the reserved exact prefix __DS__ and whose final extension is .csv under ASCII case-insensitive extension recognition. Thus .csv , .CSV , and mixed-case equivalents are candidate CSV extensions. This case-insensitivity applies only to extension recognition; the complete filename reference remains exact. If the physical file is crime.CSV , a differently cased full filename does not become an alternate reference to it. Governed converted source: a successfully published CVT whose exact canonical identity and class-specific publication/validity predicate satisfy W002-CONV-004, W002-STOR-023, and PB-STOR-008. A filename that merely resembles a CVT is not sufficient. No other governed semantic class is eligible as SOURCE in WASM-002, even when its physical serialization is CSV. In particular, COL , RID , MAP , CAT , INV , RCP , HLP , CER , SCR , RCV , and WKO artifacts cannot be reintroduced as SOURCE merely because their bytes or extension appear compatible. A recognized .csv extension establishes only candidate SOURCE form. It does not certify encoding or CSV structure; the normal strict UTF-8 and structural certification contracts still govern after source resolution. Conversely, CSV-like bytes stored under a non-CSV analyst-owned extension are not an eligible WASM-002 SOURCE.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-008; CP-009; CP-010,"T-ACCEPTED, BANKED; analyst-owned CSV filename candidate preflight only; full SOURCE eligibility remains partial; CP009 T-ACCEPTED, BANKED — pure exact-name root snapshot matching only; full requirement remains partial; CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open",346733a962192320e0d56271add15a47b6037b6b; dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8; b7c515faa9bd000369d7656e09437310261290ae,Evidence/CP-008/CP008_RED_Test_Output.txt; Evidence/CP-008/CP008_GREEN_Test_Output.txt; Evidence/CP-008/CP008_Full_Regression_Test_Output.txt; Evidence/CP-008/CP008_Post_Format_Test_Output.txt; Evidence/CP-008/CP008_Rustfmt_Check_Output.txt; Evidence/CP-008/CP008_WASM_Build_Output.txt; Evidence/CP-008/CP008_Hash_Inventory_Verification.txt; Evidence/CP-008/CP008_Precommit_Git_Review.txt; Evidence/CP-008/CP008_Final_Source_Review.txt; Evidence/CP-008/CP008_Whitespace_Exception_Review.txt; CP008_Git_Banking_Output.txt (separate post-commit evidence; archived outside repository); Evidence/CP-009/CP009_Baseline_Test_Output.txt; Evidence/CP-009/CP009_RED_Test_Output.txt; Evidence/CP-009/CP009_GREEN_Test_Output.txt; Evidence/CP-009/CP009_Full_Regression_Test_Output.txt; Evidence/CP-009/CP009_Rustfmt_Check_Output.txt; Evidence/CP-009/CP009_Git_Whitespace_Check.txt; Evidence/CP-009/CP009_Post_Format_Test_Output.txt; Evidence/CP-009/CP009_WASM_Build_Output.txt; Evidence/CP-009/CP009_Hash_Inventory.txt; Evidence/CP-009/CP009_Hash_Inventory_Verification.txt; Evidence/CP-009/CP009_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Final_Staging_Review.txt; CP009_Git_Banking_Output.txt (separately archived post-commit evidence); Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived),"CP008 Day066: public is_analyst_owned_csv_source_candidate(&str) -> bool recognizes the final .csv extension ASCII case-insensitively for exact Suitcase-root analyst-owned candidate names. It refuses empty stems, __DS__-reserved names, slash/backslash paths, colon-bearing references, and traversal-like double-dot forms; preserves full spelling, case and Unicode normalization distinctions. Five new tests and 23 prior tests passed, 28/28 after Rustfmt. WASM32-target library compilation passed; no standalone browser execution proven. 20/20 SHA-256 file inventory matched; staged Rust source/test whitespace check 0. Full staged whitespace check 2 due solely to two preserved archival trailing-space lines in the CP008 precommit TXT, documented with supplemental diagnostic. Human T approved; Git commit banked with 18 files and clean working tree. This is ONLY lexical analyst-owned CSV candidate form, NOT regular-file proof, exact physical filename resolution, governed CVT publication, CSV UTF-8 certification, full SOURCE eligibility, or requirement acceptance. Independent Claude implementation QA pending. CP009 Day066: match_analyst_csv_root_snapshot(&str, &[RootSnapshotEntry]) -> RootSnapshotMatch applies CP008 analyst CSV candidate preflight, then exact Rust string equality (case, Unicode scalar sequence and whitespace preserved), reports no match, reported nonregular entry, ambiguous duplicate exact entries, or single caller-reported regular file. Entry origin and kind are caller assertions, not independently verified. Eight new tests; post-format full native regression 36/36; wasm32-unknown-unknown library compilation exit 0; SHA-256 inventory verified 22/22; staged whitespace exit 0; T approved and git banked 15 files, clean working tree. This is NOT actual root scanning, filesystem entry proof, browser permission, CSV/UTF-8 certification, governed CVT SOURCE eligibility or end-to-end requirement acceptance; independent Claude QA pending. CP010 Day066 adds is_governed_cvt_source_filename_candidate(&str)->bool, requiring existing canonical immutable envelope validator, exact CVT class, and exact lowercase .csv serialization token. Four bounded tests pass and native full regression 40/40; wasm32-target library build PASS with Rust 1.97.1; format check PASS; primary 29/29 and supplementary 8/8 SHA-256 verification PASS; staged whitespace PASS with documented exact-file archival exceptions; T approval; git b7c515faa9bd000369d7656e09437310261290ae committed 28 files and clean working tree. No physical file checks, conversion execution, close/reopen, publication predicate, UTF-8/CSV certification, executable SOURCE authority or browser runtime proven. Independent Claude QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-010,WIP and WKO are distinct Work Order lifecycle states,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"WIP is the editable, non-executable Work Order state. WKO is the saved, validated, immutable Work Order artifact that may become a Run target. Validation establishes that a Work Order is structurally eligible to run; it does not guarantee that runtime conditions will succeed. Loading a WKO for inspection does not make it mutable. If its instruction text is changed, the editor must treat the edited text as a new WIP derived from the original WKO. The original WKO bytes and physical identity remain unchanged, and the derived WIP cannot Run until saved as a new WKO. F-08 Run distinction: the browser Run action invokes one selected saved immutable WKO that is eligible under the governed WKO-registry rules. No ordinary WASM-002 WKO contains a textual RUN line merely to execute itself. The DS-STEPS token RUN is reserved for future saved-Work-Order composition under W002-WKO-011 and is not repurposed as the browser execution trigger.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-013,WASM-002 executes one saved Work Order without Work Order chaining,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"For WASM-002, one saved immutable WKO is one top-level executable request. It must not invoke, include, chain, or execute another WKO. The governed RUN composition operation and equivalent nested-orchestration constructs are not executable in WASM-002. If a saved WKO contains composition syntax, validation must refuse before analytical execution begins. The canonical diagnostic and Help path must explain that Work Order composition is deferred rather than treating the syntax as arbitrary text, silently ignoring it, or partially executing surrounding instructions. This scope cut does not prohibit one Work Order from selecting and materializing multiple columns in the single Stage 2 operation defined by WASM-002.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012,Materialization COL alias assignment uses AS; standalone alias maintenance uses UPDATE ALIASES,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within the WASM-002 DS-STEPS materialization form, an analyst assigns or changes the alias of a selected materialized COL with the optional same-line clause AS ""alias"" under W002-STEPS-005. This syntax is part of the governed Work Order and is not a GUI gesture. A single KEEP block may therefore assign aliases to multiple selected columns in one governed materialization. Automatic source-header COL aliases and inherited rematerialization aliases are resolved first; explicit AS clauses then determine requested successor COL aliases before complete Store-MAP validation and publication. Revision BD freezes alias-only creation/replacement with UPDATE ALIASES and explicit historical Store-MAP selection with MAP ""<exact Store MAP filename>"" . Revision BE completes the bounded alias lifecycle with explicit CLEAR ... ALIAS and RESET ... ALIAS forms under W002-WKO-012.5 through W002-WKO-012.6. Empty-string AS """" is not the clearing syntax.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.1,Canonical standalone alias-maintenance Work Order uses UPDATE ALIASES,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"The canonical alias-only Store metadata forms are: SUITCASE: .
WORK ORDER AS ""Rename crime store""
SOURCE ""35100178.csv""
STORE AS ""Crime Statistics""
UPDATE ALIASES or, when the analyst intentionally selects one exact Store snapshot: SUITCASE: .
WORK ORDER AS ""Rename crime store""
MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""
STORE AS ""Crime Statistics""
UPDATE ALIASES UPDATE ALIASES is the explicit terminal commitment clause for an alias-only Work Order. The WKO must identify exactly one Store-state base using either SOURCE ""..."" for ordinary Store-aware current-state selection or MAP ""..."" for exact Store-MAP selection, never both. At least one supported alias mutation clause must occur after the Store-state selector and before UPDATE ALIASES . An alias-only Work Order must not contain KEEP , MATERIALIZE , INVENTORY , conversion, Store repair, Work Order registry repair, cataloging, deferred Work Order composition, or another operation's terminal clause. Alias maintenance changes governed human-facing metadata only.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.2,"STORE AS, RID AS, and COL ... AS are the canonical alias-replacement clauses",W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical mutation clauses are: STORE AS ""Crime Statistics""
RID AS ""Row Number""
COL ""Crime Rate"" AS ""Police-Reported Crime Rate"" STORE AS ""..."" replaces the selected Store snapshot's store_alias . RID AS ""..."" replaces its rid_alias . COL ""<reference>"" AS ""..."" replaces the alias of exactly one existing mapped COL. The COL reference resolves under W002-STOR-021: it may be the exact physical column_filename or one unique current COL alias from the selected Store MAP. Missing, ambiguous, non-COL, or conflicting resolution must refuse rather than guess. One Work Order may update the Store alias, RID alias, and multiple distinct COL aliases together, provided the complete successor state satisfies all existing alias uniqueness/shadowing rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.3,"MAP ""<filename>"" is the exact historical Store-MAP selector",W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"The canonical explicit Store-MAP selection clause is: MAP ""__DS__MAP__20260920T184512347Z__<uuid-v4>.csv"" The value is always the exact physical filename of one structurally valid immutable Store MAP. It is not a Store alias, WKO alias, timestamp shorthand, UUID-only selector, or latest expression. For MATERIALIZE, if present, the clause occurs immediately after SOURCE and before KEEP . It overrides automatic Store-MAP inheritance and binds the run to exactly the named Store snapshot. For alias-only maintenance, the Work Order uses either SOURCE ""..."" or MAP ""..."" as its Store-state selector, not both. For materialization, SOURCE ""..."" remains mandatory and an optional MAP ""..."" supplies the exact historical/current Store-state base. Validation must refuse an incompatible source/MAP pairing or a MAP that is not a valid Store-MAP profile. Health rule: explicit historical selection does not override the current Store-lineage health gate. The selected lineage must currently be VALID and every RID/COL binding referenced by the named MAP must currently be present and valid. Otherwise the operation refuses. This applies equally to MATERIALIZE and UPDATE ALIASES. F-05/P2-01 source-compatibility predicate: for materialization, an explicitly named MAP is compatible only when the mandatory Work Order SOURCE exactly equals the one common source_filename carried by that Store MAP. If the exact filenames differ, validation refuses before the F-04 existing-Store cardinality gate in W002-MAT-002.6. Equal row count never authorizes a different source to enter the selected Store lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.4,Alias-only execution publishes one complete successor Store MAP and no rewritten data artifacts,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"A successful UPDATE ALIASES operation begins from the selected complete Store MAP, applies only the requested alias replacements in memory, validates the complete resulting Store state, writes the successor MAP under governed SCR , closes and reopens it, validates it fully, and promotes it to a new immutable MAP last. That successful promotion is the alias-update commit point. The operation must preserve the selected Store's physical RID and COL filenames and bytes, source-column keys, row order, cardinality, and lineage except for the human-facing alias fields explicitly changed by the Work Order. It must not reread source data rows merely to change aliases, must not create RID/COL artifacts, and must not rewrite or delete the inherited MAP. The prior MAP remains visible historical state. If validation or MAP publication fails, no successor alias state becomes current. The failure is reported through the governed diagnostic/Help path and any incomplete candidate remains subject to the retained- SCR failure-evidence rules in W002-STOR-023.1; WASM-002 does not emit RCV. Revision BM E-02 integration: when the alias-only operation uses an explicitly named historical Store MAP, publication is permitted only if the Store lineage currently evaluates VALID and every RID/COL binding referenced by that named MAP is currently present and valid. An older MAP cannot be used to bypass current damage. P3-06 validation depth: because UPDATE ALIASES does not consume RID/COL analytical contents, its Store-health and binding checks use Tier 1 under W002-STOR-019.10. The operation must not scan every RID/COL record merely to change aliases. This does not weaken later operations that actually consume those artifacts; they must perform the applicable Tier 2 validation before relying on the contents.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-007,Standalone Store/RID/COL alias maintenance acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance must establish a Store with one RID and at least three materialized COLs, then execute an alias-only Work Order that changes the Store alias, RID alias, and at least two COL aliases in one UPDATE ALIASES operation. One COL must be targeted by its unique current alias and another by its exact physical COL filename. The fixture must prove that exactly one complete successor Store MAP becomes current; prior MAP, RID, and COL artifacts remain byte-for-byte unchanged; no source-data row read is required; no new RID/COL artifact is published; and the successor MAP contains exactly the requested aliases while preserving all physical bindings and logical source-column keys. Missing/ambiguous COL references and successor alias collisions must refuse without publishing a successor MAP. F-23 CLEAR/RESET alias fixtures: acceptance must separately exercise CLEAR STORE ALIAS , CLEAR RID ALIAS , CLEAR COL ""<reference>"" ALIAS , RESET STORE ALIAS , RESET RID ALIAS , and RESET COL ""<reference>"" ALIAS . Each CLEAR fixture must prove that the successor MAP stores the governed empty alias without renaming or rewriting the referenced artifact. Each RESET fixture must prove restoration of the exact deterministic default governed by W002-WKO-012.6 and W002-STOR-019.7, including the oversized-header operational fallback where applicable. The fixtures must prove that CLEAR and RESET require no source-data row read, publish exactly one complete successor Store MAP on success, leave the predecessor MAP/RID/COL bytes unchanged, and deterministically refuse duplicate mutation of the same alias field or a reset/default value that fails the complete successor alias validity/uniqueness/shadowing rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-008,Explicit historical Store-MAP selection acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance must create at least two valid Store MAP snapshots for one Store, then prove that a Work Order containing MAP ""<older exact Store MAP filename>"" binds to that exact older snapshot even though a newer valid MAP exists. An alias-only fixture must publish its successor from the explicitly named older base rather than from the newer automatic current state. A materialization fixture must retain mandatory SOURCE ""..."" while using the explicit MAP as its Store-state base. The tests must also prove refusal for a missing MAP, malformed MAP, WKO-MAP profile supplied as Store MAP, and source/MAP incompatibility. No implementation may substitute the newest MAP after an explicit MAP clause has validated. F-21 chronology acceptance: the fixture must use at least three successive valid MAP snapshots for one Store so that an explicitly selected older base and a distinct pre-run current MAP both exist. Merely selecting/validating the older MAP must leave current authority unchanged. A successful governed operation from that older base must then publish exactly one new successor whose requested state is derived from the named older base, whose publication UTC is later than the pre-run current chronology predecessor, and which becomes current under ordinary greatest-UTC selection. The selected historical MAP and the formerly current MAP must remain byte-for-byte unchanged. Acceptance must prove that later mappings/aliases present only in the formerly current MAP are not silently merged into the historical-base successor unless the Work Order explicitly recreates them. Receipt evidence must identify the exact operation base and exact published successor through the already-frozen operation-specific Receipt fields. No additional warning/permission gate or informational diagnostic is required merely because the analyst explicitly chose a historical base.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.5,CLEAR ... ALIAS deliberately removes a human-facing alias,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical clearing forms are: CLEAR STORE ALIAS
CLEAR RID ALIAS
CLEAR COL ""<reference>"" ALIAS CLEAR deliberately stores the empty string in the corresponding alias field of the successor Store MAP. It does not restore a default alias. An empty-string replacement such as STORE AS """" , RID AS """" , or COL ""..."" AS """" is not the canonical clearing form and must be rejected by the bounded WASM-002 grammar. For CLEAR COL , <reference> resolves against the selected pre-mutation Store MAP by exact physical column_filename or one unique current COL alias under W002-STOR-021. All COL references in one UPDATE ALIASES Work Order are resolved before any mutation is applied so clause order cannot change target identity. Missing, ambiguous, duplicate-target, or non-COL references must refuse. Clearing an alias never renames, rewrites, or deletes the underlying RID/COL artifact and never changes physical identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.6,RESET ... ALIAS restores the deterministic default alias,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical reset forms are: RESET STORE ALIAS
RESET RID ALIAS
RESET COL ""<reference>"" ALIAS RESET STORE ALIAS restores the Store MAP's common exact source_filename . RESET RID ALIAS restores the literal RID . RESET COL ""<reference>"" ALIAS restores that mapped COL's deterministic operational default defined by W002-STOR-019.7 from its exact recorded source_header and physical source ordinal: the exact header when it contains at most 1,024 Unicode scalar values, or the deterministic Column <LETTERS> fallback/disambiguation rule when the recorded header exceeds that boundary. RESET never substitutes the potentially oversized exact header into the alias field merely because that header remains authoritative source evidence. RESET is therefore distinct from CLEAR . The restored value must pass the same governed alias validity, uniqueness, and shadowing rules as any explicit alias. If the deterministic default is empty or conflicts in the complete successor Store MAP, RESET must refuse except for the narrow oversized-header fallback/disambiguation rule already frozen in W002-STOR-019.7; Data Sculptor must not otherwise invent a suffix, alternate spelling, or substitute. AS , CLEAR , and RESET mutations may coexist in one Work Order when they target distinct alias fields; duplicate mutation of the same alias field in one Work Order must refuse. A successful operation publishes exactly one complete successor Store MAP under the existing UPDATE ALIASES commit contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001,Canonical WASM-002 DS-STEPS materialization form,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 materialization Work Order form is: # Optional human comment
SUITCASE: .
WORK ORDER AS ""Prepare monthly crime data""
SOURCE ""crime.csv""
[MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""]

KEEP
  HEADER ""REF_DATE"" AS ""Year""      # reporting year
  HEADER ""GEO""
  COLUMN 7 AS ""Crime Rate""

MATERIALIZE SUITCASE: . is governed by W002-WKO-008. WORK ORDER AS ""..."" is mandatory for an executable/saved WASM-002 Work Order and declares the immutable human-facing WKO alias governed by W002-STEPS-001.1. SOURCE ""..."" names the exact Suitcase-root source file. MAP ""..."" is optional with cardinality 0..1. If present, it occurs immediately after SOURCE and before KEEP , names one exact physical governed Store MAP filename, and binds the run to that exact current or historical Store lineage subject to W002-STOR-019.3 and W002-WKO-012.3. If absent, the Store-aware exact-source routing rules apply. KEEP is the bare governed keyword and introduces one or more column selectors. KEEP: is not valid WASM-002 syntax. Each selector is either HEADER ""..."" or COLUMN n and may optionally end with AS ""..."" . MATERIALIZE is the explicit terminal commitment verb. Duplicate structural clauses refuse. An empty KEEP refuses. After MATERIALIZE , only blank lines or comments may follow; a trailing comment on the physical MATERIALIZE line is permitted because comments are removed from the semantic token stream. # comments are governed by W002-STEPS-001.2. No RID/row-index clause appears in the Work Order. If this materialization establishes a new Store, the engine automatically generates exactly one RID artifact under W002-RID-002 and W002-RID-008. If it extends an existing Store, the existing RID is reused subject to the Store health/cardinality rules. This requirement freezes the bounded keyword structure and selector forms shown above for BM integration. Other complete-language lexical features remain outside this bounded syntax freeze unless separately specified. F-08 common-grammar boundary: MATERIALIZE is one of the seven executable WASM-002 operation grammars governed by W002-WKO-007. Its optional MAP clause remains in the frozen position immediately after SOURCE and before KEEP . The terminal MATERIALIZE clause is DS-STEPS syntax; the browser's Run action is not written into the Work Order. F-20 bounded KEEP: the canonical KEEP block contains at least one and at most 16,384 selectors, and after resolution those selectors must identify at least one and at most 16,384 distinct source columns. This is the complete WASM-002 selection-width bound.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001.1,WORK ORDER AS declares the immutable human-facing Work Order alias,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"An executable or saved WASM-002 Work Order must contain exactly one top-level clause: WORK ORDER AS ""<alias>"" In canonical forms it appears after SUITCASE: . and before the operation-specific source/selector clauses. The decoded alias must be non-empty. The quoted alias may contain spaces and ordinary UTF-8 phrase text subject to the governed string-literal rules. The alias affects display and governed alias resolution only; it does not replace the WKO filename/UUID as physical execution identity. The alias is stored in the immutable WKO bytes and is published into the current WKO MAP when the WKO save transaction commits. Changing the alias therefore requires saving a new WKO under the frozen WKO lifecycle. No valid executable/saved WKO in WASM-002 is unaliased. P3-10 alias-content rule: “non-empty” means that, after decoding the quoted string literal, the alias must contain at least one non-whitespace character. An alias consisting only of whitespace refuses Work Order validation. Data Sculptor must not trim, collapse, normalize, or otherwise rewrite leading or trailing whitespace in an otherwise valid alias; the decoded alias text remains authoritative and is preserved exactly in the immutable WKO and governed WKO MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001.2,# introduces a DS-STEPS line comment outside double-quoted strings,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"Outside a double-quoted string, the first # on a line begins a comment that continues through the line's LF terminator. Whole-line comments and trailing comments are permitted. Comment text has no execution semantics and is ignored by the DS-STEPS parser after lexical recognition. A # inside a double-quoted string is ordinary string content and does not begin a comment; for example WORK ORDER AS ""Analysis #3"" and HEADER ""CATEGORY #"" preserve the hash character. WASM-002 defines no block-comment syntax. Comments are preserved byte-for-byte in the saved immutable WKO TXT. Editing, adding, or removing a comment changes the WKO bytes and therefore requires saving a new WKO artifact even though analytical semantics may remain unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-002,HEADER selects by exact decoded source-header value,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"HEADER ""name"" resolves against the exact decoded header values established for the certified source. Header equality is exact Unicode scalar-value sequence equality under PB-STOR-010: Data Sculptor performs no case folding, locale folding, Unicode normalization, trimming, or filesystem-style comparison. A selector that matches no source header must refuse. If the same exact decoded header sequence occurs in more than one source column, the header selector is ambiguous and must refuse rather than choose by position, discovery order, normalization, case-insensitive similarity, or another heuristic. An analyst can disambiguate duplicate exact header text with the 1-based COLUMN n selector. F-20 selector identity: HEADER always matches the authoritative exact decoded source header. It never matches an operational fallback name such as Column AA , a generated collision-disambiguation suffix, a COL alias, or a truncated form of the source header.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-003,COLUMN selects by 1-based source ordinal,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"COLUMN n identifies the source column by 1-based ordinal position. COLUMN 1 is the first source column. Zero, negative values, non-integers, and ordinals greater than the source width must refuse. Ordinal selection does not suppress source metadata: Data Sculptor must still resolve and record the selected column's actual decoded source header in the successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-004,HEADER and COLUMN selectors may be mixed but may not select one source column twice,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"One KEEP block may contain any supported mixture of HEADER and COLUMN selectors. Selector order expresses the analyst's requested selection order for the governed operation. After resolution, two or more selectors that identify the same physical source column constitute a duplicate selection and must refuse before materialization. Data Sculptor must not materialize the same source column twice merely because it was named once by header and once by ordinal.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-005,AS assigns the resulting materialized-column alias,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The optional clause AS ""alias"" belongs to the immediately preceding HEADER or COLUMN selector and expresses an intentional human-facing alias assignment in the governed Work Order. For a logical source column not present in the inherited MAP, omission of AS uses the exact source header as the default alias. For a logical source column already present in the inherited MAP, omission of AS preserves the inherited alias. An explicit AS overrides either default for the successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-006,The complete successor MAP must contain unique aliases,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"After inheritance, selector resolution, default-alias application, rematerialization continuity, and all explicit AS clauses are applied, every alias in the complete successor MAP must identify exactly one logical materialized column. If two different logical columns would have the same alias, including a collision with an inherited mapping, validation must refuse unless the Work Order has explicitly resolved the conflict through supported governed syntax. Data Sculptor must not invent suffixes such as Year_2 , use last-write-wins behavior, or silently shadow an existing alias. F-20 narrow generated-name exception: the prohibition on invented suffixes applies to ordinary source-header defaults and analyst-authored aliases. The only automatic suffixing permitted in WASM-002 is deterministic disambiguation of an oversized-header operational fallback under W002-STOR-019.7. That mechanism is not an alias-repair heuristic and must not be applied to an explicit AS value or to a short exact source-header default.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-007,MATERIALIZE commits the resolved KEEP set to the governed structural pass,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"MATERIALIZE is the explicit commitment verb for this WASM-002 DS-STEPS form. The KEEP selectors express which source columns belong in the operation; they do not themselves authorize data-row materialization. Before the bounded structural pass begins, the source, all selectors, actual source ordinals/headers, requested aliases, inherited alias state, and resulting alias uniqueness must be resolved and validated. Successful multi-column execution then follows the one-pass materialization contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-008,The Store MAP records resolved truth rather than selector spelling,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The successor Store MAP must record the fully resolved materialization result using the frozen eight-column schema store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename , regardless of whether the analyst selected a column with HEADER or COLUMN . For example, COLUMN 7 AS ""Crime Rate"" records the Store alias, RID filename/alias, common source filename, source ordinal 7 , the actual decoded header found at column 7, alias Crime Rate , and the newly generated physical COL filename. DS-STEPS expresses intent; the Store MAP persists the resolved durable mapping truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-009,DS-STEPS materialization syntax acceptance,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"Acceptance must cover: one column selected by exact header; one column selected by 1-based ordinal; mixed header/ordinal selectors in one KEEP block; multiple columns materialized in one governed structural pass; AS alias assignment; default header aliasing; inherited-alias preservation on rematerialization; explicit alias replacement on rematerialization; duplicate-header ambiguity refusal; invalid ordinal refusal; duplicate resolved-column refusal; and duplicate successor-alias refusal. Acceptance must also prove that the generated successor MAP records the same resolved source filename, source ordinal, actual source header, resulting alias, and physical COL identity whether a column was selected by header or by ordinal. For a new Store, both the single-column and multi-column materialization fixtures must contain no RID/row-index instruction yet must automatically publish exactly one RID artifact. For a later permitted same-Store materialization, the fixture must likewise contain no RID instruction and must reuse the original RID without publishing another. Damaged-lineage Help acceptance: fixtures must prove that exact source routing to an INVALID Store, and to a DEGRADED Store whose every mapped COL is broken, refuses ordinary materialization without silently treating the source as unseen. The canonical diagnostic/Help evidence must identify the blocked lineage/current MAP and preserve the frozen analyst-owned exits: external restoration under the original governed physical filename followed by governed validation; source rename to begin a distinct new Store lineage; or moving all lineage MAPs out of the active Suitcase to retire that lineage from routing. The all-COLs-broken fixture must warn that moving only the latest MAP is insufficient. No fixture may imply a new Data Sculptor recovery command, automatic RID regeneration, silent replacement of the damaged lineage, or historical byte identity based only on a restored filename. P3-06 validation-tier acceptance: acceptance must prove that a routine routing/status or alias-only path can use Tier 1 without an end-to-end scan of every RID/COL value, while an operation that consumes artifact contents performs Tier 2 before relying on them. Fixtures must include: a RID that passes Tier 1 but fails Tier 2 because its declared N /sequence is internally wrong beyond the Tier-1 boundary; a COL that passes Tier 1 but fails Tier 2 because its data-record count or CSV body is invalid beyond the Tier-1 boundary; and a REPAIR MAP fixture proving that the Tier-2 failure set determines exactly which COL bindings are removed. P3-07 routing acceptance: fixtures must prove that routing discovers a lineage from a structurally valid Store MAP regardless of whether later Store-health evaluation is VALID , DEGRADED , or INVALID . A separate fixture must present no routable lineage together with at least one structurally malformed Store-MAP-class artifact in the active Suitcase and prove that ordinary materialization refuses before publishing a new RID or first Store MAP, while Help identifies the malformed MAP artifact or artifacts. No fixture may treat an all-MAPs-damaged condition as permission for a silent replacement lineage. F-08 cross-operation grammar acceptance: fixtures must prove the common preamble, ASCII-case-insensitive keywords, exact quoted-value preservation, required SPACE/TAB token separation, unknown-line refusal, one-operation-per-WKO refusal, and separation between DS-STEPS terminal phrases and Receipt OPERATION tokens. At least one fixture for each of the seven executable operations must prove that its canonical structure validates while an otherwise similar WKO containing another operation's terminal clause refuses. Separate fixtures must prove that browser Run does not require a textual RUN clause and that parsed RUN composition syntax refuses as deferred before analytical execution. P2-04 restoration-language acceptance: Help, diagnostics, UI text, and acceptance evidence may say that a file restored under the exact governed physical filename passed the required validation tier and may therefore re-enter use. They must not state or imply that filename equality alone proves restoration of the historical original bytes. If stronger historical-byte identity is desired, Help may point to the separately governed explicit fingerprint/LCK direction rather than silently hashing ordinary Store artifacts. F-20 selector/name/width acceptance: fixtures must additionally prove that HEADER resolves only against exact decoded source-header text and never against an operational fallback/default alias; a KEEP selecting all 16,384 columns is valid; a source wider than 16,384 refuses before data-row materialization; and RESET of an oversized-header COL restores the deterministic operational fallback rather than the exact oversized header as alias text. F-03 Store-health and REPAIR MAP acceptance set Target required: REPAIR MAP without exactly one current Store MAP target refuses. Historical target: a structurally valid but non-current historical Store MAP refuses for repair. Wrong profile: a WKO MAP supplied as the repair target refuses. DEGRADED repair: one or more broken COL bindings are removed while every valid binding and the exact RID identity are preserved. All COLs broken: repair refuses, publishes no successor MAP, and the Store remains DEGRADED . Malformed newest MAP: current-state resolution falls back to the greatest earlier structurally valid MAP in the same lineage and reports the malformed artifact. Missing COL in current valid MAP: no fallback occurs; the current MAP remains current and the Store evaluates DEGRADED . Missing RID in current valid MAP: no fallback occurs; the current MAP remains current and the Store evaluates INVALID . Original RID externally restored: the Store is re-evaluated after governed validation without Data Sculptor creating or inferring a replacement RID. No silent fork: neither DEGRADED nor INVALID permits ordinary materialization to create a replacement Store for the same routed lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-003,Suitcase-relative Work Order portability acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must execute a saved WKO containing SUITCASE: . and ordinary Suitcase-relative file references, then move the intact fixture Suitcase to a different permitted parent path and execute the same saved WKO again. Resolution must identify the same logical Suitcase files without editing the WKO to insert the new absolute machine path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-004,WIP/WKO lifecycle acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance evidence must show that an editable WIP cannot Run; saving a valid WIP produces a distinct immutable WKO Run target; loading that WKO and changing instruction text creates a new non-runnable WIP; and the original WKO bytes, filename, identity, and provenance remain unchanged. F-02 alias-registry lifecycle acceptance: a first save for an unused alias must publish a successor WKO MAP containing exactly one CURRENT row for that alias. Saving a second valid WKO with the same exact alias must surface exactly Replace alias target and Cancel . The Cancel fixture must leave the predecessor WKO MAP authoritative and must not commit the pending WKO/WKO-MAP pair as a registry update. The Replace fixture must publish a successor WKO MAP in which the former owner is DEPRECATED , the new WKO is the sole CURRENT row for that alias, and any earlier deprecated history remains preserved. The former WKO bytes and filename and every predecessor WKO MAP must remain unchanged. Alias resolution against the successor registry must resolve to the new CURRENT row and never to a DEPRECATED row. A malformed fixture containing more than one CURRENT row for one exact alias must fail structural validation rather than choose by filename UTC, modified time, discovery order, or row order. P2-03 WKO-registry clock acceptance: using a deterministic injected clock seam, acceptance must prove that a successor WKO MAP publishes only when the observed transaction UTC is strictly greater than the current structurally valid WKO MAP UTC; equal-millisecond and backward/future-dated-predecessor cases refuse without committing the new WKO/registry state. The diagnostic must expose predecessor_map_filename , predecessor_utc , and observed_host_utc . A separate fixture must deliberately move the future-dated current WKO MAP out of the active Suitcase, rescan, and prove deterministic reselection of the remaining current structurally valid WKO MAP without Data Sculptor silently moving or deleting anything itself. Day 060 H-12: every equal/backward/future-predecessor chronology refusal in this acceptance set must emit DS-UTC-001 with exact map_profile: WKO , observed_host_utc , predecessor_map_filename , and predecessor_utc facts. F-23 save-transaction filesystem-fault fixture, reconciled by F-33: using a controlled create/write/close/rename/promotion failure at a deterministic point after a valid WIP has entered the governed save path, acceptance must prove that a failed WKO/WKO-MAP save is never represented as a committed alias-registry update. The pre-run current WKO MAP must remain authoritative; no malformed or unpromoted candidate may become current; and any rollback or retained SCR evidence must follow W002-STOR-018.3 and the shared non-Store publication/retained-evidence contract. No RCV artifact is emitted. F-02 registry-repair acceptance set Deadlock escape: with a repair-required current WKO MAP, a newly saved structurally valid repair-only WKO can Run by exact filename and successfully publish a repaired successor registry. No broad bypass: a newly saved unregistered WKO for any other operation remains ineligible to Run. Missing reference: repair removes a stale registry row but does not recreate the missing WKO, substitute a historical WKO, or promote an older WKO automatically. Discovered alias, no owner: one discovered valid WKO with an otherwise unowned alias becomes CURRENT . Discovered alias collision: a discovered WKO whose alias is already owned by a surviving CURRENT row becomes DEPRECATED . Several discovered WKOs, no owner: all become DEPRECATED ; no winner is inferred by UTC, filename, UUID, directory order, discovery order, or modified time. Mandatory alias: an unaliased WKO cannot be structurally valid. Line endings: otherwise-identical structurally valid WKO fixtures with LF and CRLF line endings are accepted; the lone-CR form refuses. Deterministic successor: repaired successor rows serialize in ascending UTF-8 byte order of exact wko_filename . Historical Run: a registered DEPRECATED WKO can Run by exact physical filename but not by alias. Receipt identity: a successful or refused registry-repair Receipt uses REPAIR_WORK_ORDER_REGISTRY as the operation token. Day 060 H-10 / BM-07 registry-repair Receipt-count acceptance Acceptance must include a successful repair-required-registry fixture in which the exact repair-only bootstrap WKO is initially visible and unregistered, runs by the bounded exact-filename bootstrap, and is then registered by the repair result. The committed successor WKO MAP must contain the repair WKO row. The successful Receipt must list that exact repair WKO under either REGISTERED_CURRENT_WKO_<INDEX>_FILENAME or REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME , according to the ordinary alias-ownership rule. The corresponding REGISTERED_*_COUNT must equal the number of newly registered rows in that status class, including the repair WKO when applicable. Pre-existing surviving CURRENT / DEPRECATED rows in the base registry must not inflate either registered count. A fixture containing both pre-existing surviving rows and newly registered rows must prove that the Receipt reports the repair change set while the successor MAP reports the complete resulting registry state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-005,"Store MAP inheritance, historical override, and immutable snapshot acceptance",W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must execute a saved Store-establishing Work Order containing multiple COL alias assignments when no routable Store lineage exists and no structurally malformed Store-MAP-class artifact is present , and prove that exactly one new immutable complete Store MAP is created while the GUI supplies no alias-edit gesture and target artifacts remain unchanged. A later Work Order with the same exact source and no explicit MAP must route to that Store's lineage and inherit its unique newest permitted MAP automatically. Another Work Order must explicitly select an older valid MAP even though newer MAPs for that Store exist and prove that Store/RID binding, alias resolution, and inheritance use exactly the named historical MAP instead. A fixture specifying more than one MAP must refuse. A fixture with two otherwise permitted current MAP candidates for the selected Store sharing the greatest UTC millisecond timestamp must refuse automatic inheritance rather than use UUID as chronology. A separate fixture must remove or corrupt every Store MAP in a prior lineage so that no structurally valid Store MAP remains while at least one malformed Store-MAP-class artifact remains visible in the active Suitcase. Re-running ordinary materialization must refuse before creating a new RID or first Store MAP, and Help must identify the malformed MAP artifact or artifacts. P2-03 Store chronology acceptance: injected-clock fixtures must prove later observed UTC success, equal-millisecond refusal, backward-UTC refusal, and a genuinely future-dated current Store MAP that remains current while blocking successor publication. Every refusal must leave the chronology predecessor unchanged and publish no successor Store MAP. A historical-base fixture must derive requested state from an older eligible MAP while proving that the strict-greater-than comparison uses the actual current Store MAP as chronology predecessor, not the historical base. A deliberate analyst-removal fixture must move the future-dated current MAP out of the active Suitcase and prove deterministic reselection of the remaining structurally valid history; restoring that MAP must make ordinary greatest-UTC authority rules applicable again. Day 060 H-12: every equal/backward/future-predecessor Store-MAP chronology refusal in this acceptance set must emit DS-UTC-001 with exact map_profile: STORE , observed_host_utc , predecessor_map_filename , and predecessor_utc facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-006,Work Order chaining refusal acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must submit a structurally saved WKO containing a RUN or other recognized Work Order-invocation construct and prove that WASM-002 refuses it during validation before Stage 1, Stage 2, conversion, inventory, or other governed execution begins. The diagnostic/Help output must identify composition as deferred functionality. A separate multi-column MATERIALIZE fixture must still succeed, proving that multiple selected columns inside one Work Order are not misclassified as Work Order chaining.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-001,One explicit Work Order command surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser front end shall use the Work Order editor as the single human command-entry surface for governed execution. It shall not expose a second interactive command prompt or point-and-click analytical path that can become an independent source of analytical intent. The editable draft may be syntax-highlighted, validated, and saved, but it is not itself executable authority. The browser Run action operates only on one loaded/selected saved immutable WKO that is eligible under the governed Work Order registry rules. Run is a browser action, not a line that ordinary WASM-002 Work Orders must contain. If a WKO contains the reserved DS-STEPS RUN composition token, WASM-002 refuses before executing any child or top-level analytical operation because saved-Work-Order chaining is deferred. The token remains reserved so later ordered composition can be added without repurposing existing syntax. F-24 fresh-application state: each new Data Sculptor browser application instance begins without a selected Suitcase and without a restored unsaved Work Order draft. Initial page load and full reload therefore return the command surface to the pre-Suitcase gate. A previously selected folder, loaded WKO, or dirty WIP must not be silently reconstructed from browser-private persistence.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-002,Front end presents and authorizes; shared Rust core decides,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser front end may authorize files, edit and validate Work Orders, invoke the shared engine, display governed state, render diagnostics, and present generated artifacts. It must not independently decide analytical truth, silently reinterpret a Work Order, or implement a competing semantic path. Where front-end presentation and shared-core semantics disagree, the shared governed semantics and frozen requirements are authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-003,Visible Suitcase and governed run context,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser surface shall make the currently validated Suitcase visible and shall expose the visible files in that folder. Source and requested-column context become governed execution state only when a saved Work Order resolves them; the UI must not imply that directory presence alone means a source has been selected, scanned, certified, or materialized.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-004,Certification gate is visible and blocking,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The front end shall visibly represent strict whole-file UTF-8 certification as a required stage before analytical materialization. A certification refusal must stop the current analytical Work Order, prevent later materialization stages from being presented as successful, and provide the canonical diagnostic / Help path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-005,One-pass multi-column materialization is represented truthfully,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"When a valid Work Order requests multiple source columns, the front end shall represent them as one governed multi-column materialization request through one bounded structural CSV pass, not as unrelated per-column scans when the frozen engine contract performs one pass. Requested columns must be validated before data-row materialization begins, consistent with the materialization requirements.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-006,Visible Suitcase Directory is the artifact orientation surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"After Suitcase validation, the browser shall present a human-readable directory view of the visible files in the selected Suitcase, including physical filename, read-only governed alias where applicable, file type, and size. Governed artifacts created by a run shall appear in that same visible inventory after refresh or update. The directory is an orientation and metadata surface over the real flat Suitcase. It is not a hidden browser cache, a second persistence system, or an analytical command surface. CAT integration: this existing directory remains the sole WASM-002 artifact-orientation surface. CAT and MAP artifacts are first-ranked under W002-CAT-UI-001 through W002-CAT-UI-008; no second catalog browser is introduced.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-007,All user-facing Help flows through the Help Engine,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"All Data Sculptor-controlled user-facing Help messages, warnings, refusals, explanations, validation guidance, safe-next-action messages, and governed success/status messages that participate in the Help/status/evidence system shall be produced through the Help Engine from governed facts or canonical diagnostic events. Individual UI controls must not maintain an independent competing stock of semantic Help text. Governed success/status events in this system use canonical INFO diagnostics. Ordinary static labels, headings, decorative copy, and presentation-only UI text are not diagnostics and need not be routed through the diagnostic registry merely because they are visible. Help voice may change wording and depth but must not change diagnostic identity, evidence, severity, refusal/continue behavior, provenance, or safe next action. Durable Help Reports derive from the same governed truth. F-17 fallback behavior: when a complete registered diagnostic lacks an authored help_messages.json entry, the UI must show the deterministic Generic Technical Help rendering from W002-HELP-002.9 for Casual, Office Speak, and Technical selections rather than a blank state, guessed prose, or UI-local explanation. When diagnostic assembly itself fails its required-fact contract, the UI presents DS-HLP-001 ; it must not display the incomplete intended diagnostic as if valid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-008,Legacy encoding conversion remains a separate operation,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"If UTF-8 certification fails and the bytes are eligible for the separately governed Windows-1252 compatibility/conversion path, the front end may explain or help draft that separate conversion Work Order. It must not silently reinterpret the failed analytical Work Order as Windows-1252 and continue materialization. P3-08 front-end disclosure: after a successful conversion, the visible result/Help path must identify the exact published CVT filename and explain that it is a new source identity for later Store routing. When that CVT is subsequently chosen for first materialization, the front end must not present the action as a refresh of an earlier conversion-derived Store merely because the analyst-owned input filename is the same; it must preserve the governed Help disclosure that each distinct CVT is a distinct source artifact and lineage input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-009,Front-end branding is presentation-only,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser front end shall use the canonical built-in Red5Sorcery/Data Sculptor branding and approved presentation tokens without changing analytical or diagnostic meaning. The current Red5Sorcery identity treatment, including the red “5”, remains the active WASM-002 design direction. Configurable Brand Manifest loading, validation, selection, and substitution are deferred to V1-BACKLOG / a future build whose number is not yet assigned.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-010,WASM-002 front end must not preview deferred analytical features as available controls,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 front end shall stop at the capabilities allocated to the WASM-002 build slice. It shall not present filtering, grouping, sorting, Quick Viz, PRETTY Tables, DS-VERIFY, or later filter-driven build/export workflows as executable WASM-002 controls unless their individual requirement SCOPE is deliberately changed and frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PLAT-001,WASM-002/V1 browser and modest-hardware acceptance baseline,W002-PLAT,W002-PLAT,WASM-002,UNDER REVIEW,—,"The canonical modest-hardware acceptance machine for the WASM-002 browser release and the browser path carried into V1 is the project's 11-inch Windows 11 laptop with an Intel N100 processor, 16 GB RAM, and a 1920×1200 native display. Each acceptance record must capture the exact tested Windows build, browser version, Windows display scaling, browser zoom, and materially relevant machine configuration. Those observed version and presentation settings are acceptance evidence; they do not become timeless minimum-version requirements unless separately frozen. V1 browser support is scoped to certified desktop Chromium hosts that expose the user-selected writable-directory and file-publication capabilities required by the visible Suitcase contract. Microsoft Edge is the primary certified browser. Google Chrome is the secondary certified browser. Another Chromium-derived browser may work, but Data Sculptor must not claim it as a certified V1 browser until that browser has passed the applicable acceptance suite. Firefox and Safari are not supported V1 browser hosts under this contract and their lack of the required filesystem capability must not block V1 release. Supported-host acceptance must exercise the real browser filesystem path: explicit user-selected Suitcase access, CER validation, governed Work Order save/Run behavior, and governed artifact publication. Data Sculptor must not substitute OPFS, IndexedDB, download-only publication, a browser extension, or another hidden/different persistence model merely to make an unsupported browser appear supported. Required filesystem capability is feature-detected before folder validation begins. If the host cannot expose the governed writable-directory contract, Data Sculptor must treat that state as a host-capability refusal , keep governed save/Run/analytical controls locked, and route the explanation through the canonical diagnostic/Help path. It must not claim that a particular user folder failed validation when no folder could actually be tested.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-011,"Keyboard-operable, small-screen browser shell",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The required WASM-002 front-end interactions shall remain operable from a keyboard and usable on the canonical modest-hardware/small-screen baseline defined by W002-PLAT-001. At the display scaling and browser zoom recorded for acceptance, every required control and governed surface needed to complete the supported workflow must remain reachable without changing those settings merely to reveal an otherwise inaccessible control. Responsive reflow and ordinary scrolling are permitted; this requirement does not demand that every panel be visible simultaneously. Visible labels must carry meaning without relying on color alone. Exact shortcut assignments are presentation details unless separately frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-012,"Reference prototype is evidence, not a shadow specification",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Day 043 HTML prototype embedded below is retained as concrete design evidence for the WASM-002 browser workbench. Its layout, simulated analytical execution, illustrative Work Order grammar, current aliases, demo shortcuts, artifact examples, and other unfrozen literals do not become normative merely because they appear in the prototype. If the embedded prototype conflicts with a numbered requirement, the numbered requirement governs and the prototype must be revised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-013,Dedicated persistent Help / Diagnostic Surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The primary WASM-002 workspace must reserve a dedicated Help / Diagnostic Surface with stable layout presence. When a governed diagnostic is active, the analyst must be able to view its explanation without losing sight of the Work Order and the execution/source context required to understand it. The persistent surface is a viewport into canonical diagnostic truth; it is not a second state authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-014,Governed analytical refusals are not modal- or toast-only interactions,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,An application-controlled modal dialog must not be the primary presentation of a governed analytical refusal when it would obscure the Work Order or execution context. A transient toast or timed notification must not be the sole carrier of governed diagnostic truth. Browser- or operating-system-controlled permission/security dialogs are outside this requirement because Data Sculptor does not control their presentation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-015,Idle Help state remains semantically quiet,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"When no canonical diagnostic is active, the Help / Diagnostic Surface should communicate only restrained readiness/idle state rather than becoming a general dashboard for unrelated metrics, checkpoints, or project status. Exact wording such as “No active diagnostic. Ready.” is presentation detail unless separately frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-016,Help surface exposes a direct saved-report action,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"From an active governed diagnostic, including a non-run diagnostic, or from one governed Run whose diagnostic history is available to the Help surface, the browser Help / Diagnostic Surface must provide an explicit action to generate the durable HTML Help Report. Each explicit report request publishes exactly one HLP under W002-HELP-003.2 and W002-HELP-009. The generated report must become a visible Suitcase artifact governed by the Help, PRETTY, persistence, and provenance requirements and must use the canonical built-in Data Sculptor presentation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-017,Writable Suitcase validation is the first interaction gate,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Before Data Sculptor enables Work Order saving, governed Run, or analytical processing, the analyst must choose one Suitcase folder and Data Sculptor must validate that folder by successfully creating, completely writing, and closing one governed HTML Suitcase Validation Certificate under W002-STOR-022 through W002-STOR-022.3. Permission state or directory enumeration alone is not sufficient to pass the gate. The successful certificate remains visibly in the Suitcase as durable evidence. Validation does not require deleting or renaming the certificate. Until the certificate write/close succeeds, the analytical workspace remains locked except for Help and Suitcase selection. Browser- or operating-system-controlled refusal of protected directories is outside Data Sculptor presentation control and must be explained through the Help Engine when the host can observe the refusal. F-24 opening/selection lifecycle: merely loading Data Sculptor does not create a CER. A CER is published only after an explicit Suitcase selection successfully passes the governed validation gate. Reselecting and successfully validating the same physical Suitcase is a new certification event and publishes one new CER; all earlier CERs remain untouched. Data Sculptor does not remember the directory handle between application instances, so a new load/reload requires explicit Suitcase selection again before the workspace can unlock.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-018,Suitcase Directory enumerates visible files before analytical work,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Immediately after Suitcase validation, Data Sculptor shall enumerate the visible files available through the authorized directory handle and show them in the Suitcase Directory. No source, header, column, certification, or materialization state shall be inferred merely from the existence of those files.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-019,Directory inventory and displayed aliases must not become point-and-click analytical intent,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Suitcase Directory may expose file inventory and read-only human-facing metadata such as aliases, but it shall not provide alias-edit controls, “Use as source,” column-pick, materialize, filter, or equivalent governed-action controls. Source files, requested columns, alias mutations, and analytical operations are stated in saved Work Orders and resolved by the governed engine.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-020,Saved Work Orders are the only Run targets,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Work Order editor may create a new draft or load a saved Work Order TXT artifact from the validated Suitcase. A loaded saved Work Order is an immutable Run target and may be inspected or run directly. If the analyst changes its instruction text, the editor must transition to a new draft derived from that saved Work Order; the draft is not runnable until it is saved as a new immutable Work Order with a new governed physical identity. The original saved Work Order remains unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-021,User chooses the Suitcase; Data Sculptor chooses generated filenames,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"For Work Orders, materialized columns, Help Reports, receipts, maps, and other Data Sculptor-generated artifacts, the analyst chooses or has already chosen the validated Suitcase folder. The browser shall not require the analyst to supply an output filename for those governed artifacts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-022,"Execution Output is read-only observation, never command input",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser shall provide a read-only Execution Output surface that reports which saved Work Order was run, how its source and governed aliases resolved, which execution stages occurred, what was refused, and which governed artifacts were created or assigned. For WASM-002 it does not display a nested Work Order invocation chain because Work Order composition is deferred. The surface shall not accept commands, analytical text, or cursor-driven execution input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-023,The browser has no separate Work Order Description field,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser must not expose a standalone editable Description field for a saved or draft Work Order. Human-facing Work Order naming is authored in DS-STEPS with the required WORK ORDER AS ""..."" clause inside the Work Order itself. The Saved Work Order chooser and Suitcase Directory may display governed WKO alias/lifecycle information from the current structurally valid WKO MAP . Where lifecycle information is shown, CURRENT and DEPRECATED are read-only governed registry state, and the exact physical WKO filename must remain available/visible so human meaning, lifecycle authority, and physical identity remain distinct. Alias resolution uses the sole CURRENT row for the exact alias; a DEPRECATED row is historical evidence rather than the alias target. If that current registry references a missing physical WKO, the MAP remains current and the registry is repair-required; the browser must not silently display an older WKO MAP as though it had become current merely because of the missing reference. A structurally malformed newer WKO MAP never becomes current and is reported through Help/evidence surfaces. Editing a loaded saved WKO—including changing its alias or comments—creates a derived draft that must be saved as a new immutable WKO before it can Run. If that save would supersede the existing CURRENT target for the same alias, the save flow follows the exact Replace alias target / Cancel decision in W002-STOR-018.3; the UI must not provide a separate direct registry-edit gesture.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-024,Suitcase Directory aliases are read-only views of governed MAP profiles,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Alias displays in the Suitcase Directory are observation-only. Store, RID, and materialized-COL aliases are read from eligible Store MAP state. Saved Work Order alias and lifecycle state are read from the current structurally valid WKO MAP. The browser may aggregate those governed sources into one human-facing directory view while keeping exact physical filenames available for inspection. For WKO rows, CURRENT / DEPRECATED is read-only governed lifecycle metadata. A CURRENT row identifies the registry target for that exact alias; a DEPRECATED row remains historical registry evidence and must not be presented as the current alias target. The GUI must not expose an input, inline editor, context action, or other non-Work-Order path that directly mutates governed aliases or WKO lifecycle status. Store/RID/COL alias mutation remains Work-Order-governed. WKO aliases are authored inside immutable WKO text with WORK ORDER AS and enter or change WKO alias-registry authority only through a successful governed save transaction under W002-STOR-018.3.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-025,The browser has exactly two governed built-in presentation themes,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser presentation contract exposes exactly two governed theme choices: Modern Dark and Modern Light . Custom presentation is deferred to V1-BACKLOG / a future build not yet numbered. A Terminal theme is not part of the WASM-002/V1 browser contract and must not be exposed as a governed theme choice. Theme selection is presentation-only. It must not change Work Order semantics, source resolution, diagnostic identity or facts, continue/refuse decisions, analytical values, Receipt truth, or other governed execution meaning. The selected browser theme does not control durable HLP or CER presentation in WASM-002. Those governed HTML artifacts use the canonical built-in Red5Sorcery/Data Sculptor presentation regardless of whether the live browser is using Modern Dark or Modern Light. F-24 session default and persistence: Modern Dark is the canonical theme at the start of every new browser application instance. The analyst may switch to Modern Light during that instance, but WASM-002 retains the choice only in volatile runtime state and does not persist it in browser-private storage. A new application instance therefore returns to Modern Dark.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-026,Flight Recorder is a read-only derived Receipt-history surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser may present a Flight Recorder surface that is derived exclusively from governed RCP Receipt artifacts currently visible in the authorized Suitcase. The surface is read-only and regenerable. It must not create or maintain a second execution-history database, mutable log, hidden cache, browser-private history, or alternate chronology authority. The Flight Recorder may sort, filter, group, or summarize Receipt-derived facts for human orientation, but those presentation operations must not alter Receipt bytes, invent missing events, or become authoritative over the underlying immutable Receipts. Where no canonical Receipt exists because Receipt publication failed, the surface must not reconstruct a substitute original Receipt from UI state, console text, or memory.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-001,Single-command-surface and saved-run-target acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The acceptance check must show one Work Order editor that can hold either a new draft or a loaded saved Work Order and no second independent prompt, command-entry cursor, point-and-click source selector, or point-and-click column selector. A governed browser Run must read exactly one loaded/selected saved immutable WKO artifact that is eligible under the current registry rules. An unsaved WIP must not Run. Editing the instruction text of a loaded saved WKO must transition the editor to a new draft state that cannot Run until saved as a new immutable WKO. A fixture containing the exact reserved semantic token RUN as a Work Order composition construct must refuse before any governed operation executes and must reach the deferred-composition Help path. A near-synonym such as CALL , EXEC , or INCLUDE must not be silently accepted as composition syntax.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-002,Certification-refusal gating acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a source fixture that fails strict UTF-8 certification, the browser must show certification failure, leave later analytical stages unaccepted, produce no materialized analytical outputs, preserve the source unchanged, and expose the canonical Help path. The retained event/Receipt evidence must agree on STAGE1_UTF8_OUTCOME: FAIL , exact UTF8_FIRST_INVALID_BYTE_OFFSET , and UTF8_STOP_REASON: INVALID_UTF8_SEQUENCE . The canonical diagnostic event must expose the same meaning through lower-case facts first_invalid_byte_offset , source_filename , and stop_reason .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-003,Multi-column path acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a valid UTF-8 source and a Work Order requesting at least two source columns, the browser must show successful certification followed by one governed structural materialization pass and then expose the resulting visible Suitcase artifacts required by the build contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-004,Diagnostic/Help parity acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"For at least one real WASM-002 refusal path, the live message, each supported Help voice, and the durable HTML Help report must resolve from the same canonical diagnostic event and preserve the governed facts, severity, provenance, refusal behavior, and safe next action.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-005,Visible-persistence and Suitcase-directory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"A completed governed browser run must be auditable from the visible Suitcase artifacts required by the build contract, and newly created governed artifacts must become visible through the Suitcase Directory. Acceptance evidence must show that Data Sculptor did not intentionally persist project or analytical state in browser-private storage as a substitute for those artifacts. F-24 session/CER lifecycle acceptance: acceptance must begin from a clean application instance and prove all of the following in one controlled sequence: no Suitcase is selected or silently recovered; Work Order saving and governed Run remain gated; the live browser defaults to Modern Dark and Technical Help; explicitly selecting and successfully validating a writable Suitcase publishes exactly one fresh CER and unlocks the workspace; after switching to Modern Light and a non-Technical Help voice and creating a dirty unsaved WIP, an ordinary reload/navigation path triggers the browser-supported unsaved-change warning where the host permits it; after proceeding with reload, the Suitcase handle, non-default theme, non-default Help voice, and dirty WIP are not restored from Data Sculptor-controlled browser-private persistence; reselecting and successfully validating the same Suitcase publishes a second distinct CER while the first CER remains present under its original governed filename and exact bytes; and no automatic CER-history ZIP, compaction, replacement, or deletion occurs. The acceptance record must inspect the relevant Data Sculptor-controlled browser persistence surfaces and show that no persisted project/session record was used to restore the Suitcase handle, WIP, theme, or Help voice. WASM-002 does not claim dirty-draft warning or recovery after browser crash, forced process termination, operating-system failure, or power loss.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-006,Scope-surface acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The frozen WASM-002 browser build must not expose executable controls for requirements whose current SCOPE remains V1-BACKLOG, POST-V1, OUT-WASM-002, or otherwise outside the frozen WASM-002 build slice.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-007,"Small-screen, keyboard, and certified-browser acceptance",W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"On the canonical Intel N100 / 16 GB Windows 11 laptop and its 1920×1200 display, acceptance must record the Windows build, display scaling, browser zoom, and exact browser version. In the primary certified Microsoft Edge host, the required browser controls, Work Order editor, governed-stage status, artifact/result surface, and diagnostic/Help surface must remain reachable and usable without requiring an IDE or developer tools, and the required interaction path must be completable by keyboard. Ordinary scrolling and responsive reflow are allowed; changing scaling or zoom merely to expose an otherwise unreachable required control is not. The same canonical machine must also exercise the supported-host Suitcase → CER → Work Order save/Run → governed publication path in the secondary certified Google Chrome host. Chrome must satisfy the same governed filesystem and semantic contract; browser-specific presentation differences do not permit different analytical meaning or a different persistence model.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-008,Persistent diagnostic co-presence acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,Triggering a real governed refusal must leave the Work Order and relevant execution/source context available while the diagnostic is visible in the dedicated Help surface. The refusal must not depend on an application-controlled modal dialog or transient toast as its sole presentation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-009,Idle-state discipline acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"With no active diagnostic, the dedicated Help surface must remain present but semantically quiet and must not aggregate unrelated project/dashboard state as a substitute for its diagnostic purpose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-010,Saved-report action acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"From a displayed real diagnostic event, including a governed non-run diagnostic, the user must be able to invoke the Help-report action and obtain the corresponding durable HTML Help Report as one visible governed artifact without manually copying diagnostic text or reconstructing the event. A governed Run fixture containing multiple diagnostic events must also permit one explicit Run-level Help Report request and must produce exactly one HLP for that request. The HLP must identify the included diagnostics in deterministic event order and must not create one HLP automatically for each diagnostic.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-011,Suitcase-first gate and supported-host capability acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"With no Suitcase validated, Work Order saving, governed Run, and analytical processing controls must be unavailable. Acceptance first proves supported-host capability under W002-PLAT-001. Microsoft Edge and Google Chrome acceptance must each expose the required user-selected writable-directory path; Data Sculptor must not satisfy this gate through OPFS, IndexedDB, download-only output, a browser extension, or another substitute persistence model. Acceptance must enumerate every governed final-artifact filename form and SCR staging form that WASM-002 can emit, derive the longest canonical filename length, and verify that the current contract yields 73 ASCII bytes/characters . The canonical __DS__CER__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html form is one of the forms at that maximum and is used for the actual create/write/close folder-validation test. After the analyst selects a writable test folder on a supported host, Data Sculptor must create one retained governed certificate whose filename matches that canonical CER form, completely write and close it, and expose it in the visible Suitcase Directory. The certificate must contain the semantic fields and limitation statements required by W002-STOR-022.2. Only after that certificate operation succeeds may the workspace unlock. A failure to create, completely write, or close the certificate after actual folder selection must leave the workspace locked and surface the canonical diagnostic/Help path. Separately, a deterministic missing-capability acceptance fixture must prove that a host lacking the required writable-directory contract refuses before folder validation, leaves the workspace locked, and does not mislabel an untested folder as unwritable. Acceptance must not depend on a hard-coded operating-system path-length number, deletion of the certificate, or a validation-only rename. If the emitted-name inventory changes so that another form exceeds the CER maximum, this acceptance gate must fail until the new maximum is explicitly exercised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-012,Directory-is-inventory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"After Suitcase validation, the visible directory must list a mixed fixture set including at least one CSV and one non-CSV file with their physical names, types, and sizes. The directory must expose no “Use as source,” column-pick, or materialize action that bypasses the Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-013,Generated Work Order identity and immutability acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,Saving a valid draft must create a new TXT artifact whose physical name matches the frozen Work Order filename contract and must not open a filename-entry Save As path. Editing the draft and saving again must create a different Work Order identity; the first saved TXT bytes and filename must remain unchanged.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-014,Work-Order-only source and column selection acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a Suitcase containing multiple candidate files and a CSV with multiple headers, the analyst must be able to request the source and materialized column solely through a saved Work Order. Acceptance must show that the browser performs no separate point-and-click source or column selection. F-26 SOURCE eligibility fixtures: the acceptance set must prove all of the following under W002-WKO-009.1: analyst-owned root files ending .csv , .CSV , and a mixed-case equivalent are recognized as CSV candidates; the complete physical filename reference remains exact and case-sensitive under F-15; an analyst-created __DS__notes.csv is refused as an analyst-owned SOURCE; a valid published CVT is accepted; a canonical-looking or renamed file that does not satisfy the governed CVT validity/publication contract is refused; governed non-CVT classes including COL are refused as SOURCE; a non-CSV analyst-owned extension is refused even if its bytes are CSV-like; and path, traversal, subdirectory, URL/URI, and external-file references are refused.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-015,Read-only Execution Output acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The execution surface must display the selected saved Work Order, source resolution, relevant stage/refusal facts, and resulting artifact identity while accepting no command input. Keyboard focus in the execution surface must not create a second execution path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-016,Store-MAP snapshot persistence and read-only directory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Creating or changing governed alias/Store metadata through a saved Work Order must create one new immutable complete Store MAP in the same flat Suitcase while preserving earlier MAPs and leaving target artifact bytes and physical filenames unchanged. After a governed run that creates a new Store MAP, refreshing/reopening the Suitcase may display Store, RID, and COL aliases from the exact Store lineage and Store MAP resolved for that specific governed operation. The directory must not infer a global “current Store,” guess from unrelated newest MAP timestamps, or independently choose or mutate Store/MAP authority for execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-017,"Store-aware MAP selection, historical override, and anti-rebinding acceptance",W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"A saved materializing Work Order that does not explicitly name a MAP must use exact SOURCE matching against the one common source_filename carried by each routable Store lineage's Store MAP. A routable Store lineage is one with at least one structurally valid Store MAP, regardless of later Store-health state. A fixture with exactly one routable Store lineage must route to that lineage and, when its health permits materialization, inherit the Store's unique newest permitted MAP and record both the MAP identity and bound rid_filename in execution evidence. A fixture with no routable Store lineage and no structurally malformed Store-MAP-class artifact present may establish a new Store. A fixture with more than one routable Store lineage for the same source must refuse automatic selection. An explicit-MAP fixture must prove that SOURCE must exactly equal the selected MAP's common source_filename . A different source must refuse before materialization even when source/RID row counts happen to match. A separate all-MAPs-damaged fixture must leave one or more structurally malformed Store-MAP-class artifacts visible while no routable lineage can be established. The UI/run path must refuse before new-Store/RID creation and expose Help that identifies the malformed MAP artifact or artifacts; it must not present the condition as an unseen source. Another fixture must prove that explicitly naming an older valid MAP overrides the newer default for that same Store. More than one explicitly named MAP must refuse. An equal-greatest-timestamp ambiguity within the selected Store lineage must refuse automatic selection. Once an inherited Store MAP has been selected for a run, creation of a newer MAP during execution must not silently rebind that in-progress run. P2-03 authority/clock acceptance: the UI/evidence path must distinguish the selected operation base MAP from the chronology predecessor used for successor UTC validation. When a future-dated current MAP blocks publication, the UI must not label that MAP corrupt merely because of its timestamp, must identify it as the blocking current authority, and must route to Help describing the clock correction/wait/deliberate-removal choices without performing any automatic fallback or filesystem move.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-018,Help-Engine-only messaging acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"For representative Suitcase validation, Work Order validation, source-resolution, and analytical refusal cases, user-facing guidance must be traceable to the Help Engine/canonical diagnostic path. Acceptance must show no competing ad hoc semantic refusal text generated independently by individual analytical controls.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-019,No standalone Work Order Description acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Acceptance must prove the architecture that WASM-002 permits: the browser exposes no standalone editable Work Order Description field; no separate mutable or hidden Work Order-description store exists; editing any governed WKO byte transitions a loaded saved WKO into a derived draft; the predecessor WKO TXT bytes, physical filename, and UUID remain unchanged; and the derived draft cannot Run until saved as a new WKO identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-020,Theme semantic-invariance acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The same saved Work Order and governed diagnostic fixture must be exercised under Modern Dark and Modern Light. Acceptance evidence must show identical Work Order resolution, diagnostic ID and structured facts, continue/refuse decision, and analytical result/provenance across both themes, with only governed live-browser presentation differences. The browser must expose no Custom or Terminal governed theme choice in WASM-002. Acceptance must also verify that switching between Modern Dark and Modern Light does not change the canonical built-in presentation of a generated HLP or CER.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-021,Flight Recorder read-only derivation acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Acceptance must populate the Suitcase with governed RCP artifacts for at least one successful Run and one refused Run whose Receipt publication succeeded, then reconstruct the Flight Recorder surface solely from those Receipts. The rendered history must preserve each Receipt's governed execution outcome and lineage while allowing only read-only presentation operations. A separate fixture must represent a Run for which Receipt publication failed under W002-RCP-010 and prove that the Flight Recorder does not invent, backfill, or reconstruct a canonical Receipt from transient execution state. User interaction with the Flight Recorder must not modify, delete, rename, rewrite, supersede, or create RCP artifacts and must not create hidden persistent history state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-001,Certification interprets nothing analytically,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The certification stage establishes source-encoding validity and evidence; it does not perform analytical materialization.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-002,Materialization assumes nothing about encoding,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,Materialization proceeds only under the governed UTF-8-certified-source invariant and does not guess or silently change source encoding.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-003,Conversion is a separate transformation,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"Windows-1252-to-UTF-8 conversion is an explicit user-authorized operation producing a new artifact, not a hidden fallback.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-004,The fast path preserves strictness,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"ASCII-first acceleration is an optimization of strict UTF-8 certification, not a relaxation of validity rules. Every non-ASCII sequence remains subject to strict validation and EOF remains authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-005,Help is first-class,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The shared engine emits governed diagnostic truth; the Help Engine owns governed explanation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-006,PRETTY is first-class,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The PRETTY Engine owns deterministic human-facing rendering.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-008,One shared semantic core,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The WASM-first implementation must remain suitable for later use by a standalone native CLI host without creating a permanent second semantic engine.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-011,Open source and commercial service are separate layers,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The open-source analytical product and Red5Sorcery's optional paid automation must remain architecturally distinguishable. A paid service may save work; it must not become a hidden prerequisite for executing or understanding the delivered analytical software.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-014,WASM-002 and V1 analytical execution are sequential,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"WASM-002 must execute governed analytical operations sequentially and predictably. The product must not expose worker-count, thread-count, task-parallelism, or similar tuning controls, and it must not silently introduce a parallel analytical execution mode whose ordering or resource use changes the governed semantics. Sequential execution does not require inefficient repeated scans. One bounded structural source pass may process multiple requested columns together, and implementation may use ordinary low-level/runtime mechanisms that do not create user-visible analytical concurrency or change deterministic operation order. Any future analytical parallelism requires a separate measured experiment and explicit PRD decision.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-014.1,WASM-002 has a single-writer Suitcase contract,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"WASM-002 assumes one user, one active Suitcase, and one Data Sculptor writing execution context at a time . Multiple read-only views may observe the same Suitcase, but concurrent governed writers—including a second browser tab or window attempting governed writes against the same Suitcase—are outside the supported WASM-002 contract. WASM-002 does not implement cross-tab locks, filesystem leases, lockfiles, hidden coordination state, or multi-writer merge/rebase semantics. This is an explicit product boundary, not an implicit guarantee that concurrent writers are safe. Before a governed transaction reaches its authoritative commit point, Data Sculptor must re-resolve and revalidate the governing state on which the transaction depends. If relevant governed state has changed since the transaction established its basis, publication must refuse rather than overwrite the newer authority, silently rebase itself, synthesize another chronology, or report success. Candidates already created remain subject to the existing rollback and attributable SCR recovery-evidence rules. Help must explain the boundary in ordinary terms: do not run two writing Data Sculptor contexts against the same Suitcase at the same time. If a pre-commit guard detects changed authority, the safe next action is to refresh or reopen the current governed state and rerun deliberately. Acceptance evidence must inject a relevant Store-MAP and WKO-MAP authority change after transaction preparation but before commit and prove that the newer authority remains authoritative and the stale transaction refuses.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)

=== CP018 DIRECT GIT OBJECT VOLUME AUDIT ===
Date: 2026-10-21
Commit: 75620f17649a5d38d5357960bb99e9ac39ae354f
Parent: 339cf12e747738d89442ce401feeea1afcd19dc6
Committed paths: 32
Evidence ZIPs: 30
Evidence bytes: 25906
Source bytes: 17265
Tests bytes: 4970
GROSS COMMITTED BYTES: 48141
NET REPOSITORY GROWTH BYTES: 31996
Gross KiB: 47.013
Net KiB: 31.246
File ledger SHA256: 0305D7F6038493955968817D0F8726B2BF1A2F0C9364BCA8E74D6E63F3CEF0B0
Method: git diff-tree, rev-parse, cat-file -s
Git files modified: NO
Git commit created: NO
AUDIT RESULT: PASS

"Path","Status","Category","GitBlob","GrossBytes","PreviousBytes","NetBytes"
"Evidence/CP-018/ZIP/CP018_Custody_Seal_Record.txt.zip","A","Evidence","213d0d139c4eedebb917dc7cadefe8834f910e67","610","0","610"
"Evidence/CP-018/ZIP/CP018_Evidence_ZIP_Inventory.txt.zip","A","Evidence","eaa19f5be44ff705cd95e875267b3305e700b45d","2689","0","2689"
"Evidence/CP-018/ZIP/CP018_Formatting_Correction_Record.txt.zip","A","Evidence","4ad9c5481bf4cbf2788dc34f53624cac3227c189","539","0","539"
"Evidence/CP-018/ZIP/CP018_Formatting_Correction_StdErr.txt.zip","A","Evidence","9f79019c719f3af3a84e24796bf78e497253fe9e","174","0","174"
"Evidence/CP-018/ZIP/CP018_Formatting_Correction_StdOut.txt.zip","A","Evidence","b8e6ae3be860cb0a64be4869938b65c3670a3892","174","0","174"
"Evidence/CP-018/ZIP/CP018_GREEN_Installation_Record.txt.zip","A","Evidence","9bed6e8c1b7c33afb99f04e06e5591f16d99723a","565","0","565"
"Evidence/CP-018/ZIP/CP018_GREEN_Run_Record.txt.zip","A","Evidence","b94b46ba6d8971431ce10f443a70b2fe5c3e09d0","536","0","536"
"Evidence/CP-018/ZIP/CP018_GREEN_StdErr.txt.zip","A","Evidence","4dd8642ddeb8ba91059e32ec8d7bd5ceca84c7b2","347","0","347"
"Evidence/CP-018/ZIP/CP018_GREEN_StdOut.txt.zip","A","Evidence","03bb16a3b3c2f8323e3560a46ac4ddc47aeafa4a","387","0","387"
"Evidence/CP-018/ZIP/CP018_Git_PreStaging_Review.txt.zip","A","Evidence","dc763ee7981ad60b41ce82eb2ec4a2eb40bf9adc","3028","0","3028"
"Evidence/CP-018/ZIP/CP018_PostFormat_Check_StdErr.txt.zip","A","Evidence","63220ca15bb3fbd09f3cdc1d606220fbe6aa0c39","164","0","164"
"Evidence/CP-018/ZIP/CP018_PostFormat_Check_StdOut.txt.zip","A","Evidence","5e21da0223e5482f283d5bce95a4d828ebd69bc4","164","0","164"
"Evidence/CP-018/ZIP/CP018_PostFormat_Regression_StdErr.txt.zip","A","Evidence","cc0fb9402b0fa7f9def7fa2a9157f11211f4b7e6","851","0","851"
"Evidence/CP-018/ZIP/CP018_PostFormat_Regression_StdOut.txt.zip","A","Evidence","560562f209e108ec7abe8fcdd773c7aaaf590589","1883","0","1883"
"Evidence/CP-018/ZIP/CP018_PostFormat_Verification_Record.txt.zip","A","Evidence","5877b657824509f2ce520c697764bc008ed6304c","526","0","526"
"Evidence/CP-018/ZIP/CP018_PreFormat_Test_Original.rs.zip","A","Evidence","ba1e54dfea313fd06601283276f50f4f5efe1fe3","1658","0","1658"
"Evidence/CP-018/ZIP/CP018_PreGREEN_lib.rs.zip","A","Evidence","f6de95516d606e936ebf2f481c274e915ac28746","4746","0","4746"
"Evidence/CP-018/ZIP/CP018_RED_Installation_Record.txt.zip","A","Evidence","3dacfa5b3453367fdb61758020f9aec793a1e8ad","421","0","421"
"Evidence/CP-018/ZIP/CP018_RED_Run_Record.txt.zip","A","Evidence","eb5e52e0ecfeb2b74639886bebecf060675303cf","489","0","489"
"Evidence/CP-018/ZIP/CP018_RED_StdErr.txt.zip","A","Evidence","8df8bf092699e57d6dc205778ff4b3ee7ba97154","501","0","501"
"Evidence/CP-018/ZIP/CP018_RED_StdOut.txt.zip","A","Evidence","a3081afc3c18cace5f13e4efc2514fd2848052dd","138","0","138"
"Evidence/CP-018/ZIP/CP018_Regression_Run_Record.txt.zip","A","Evidence","f220a479a1eca5b723eaa8bc986794cfd558138d","503","0","503"
"Evidence/CP-018/ZIP/CP018_Regression_StdErr.txt.zip","A","Evidence","824de2eda373793326fe82ea8a443beeebe64d2e","830","0","830"
"Evidence/CP-018/ZIP/CP018_Regression_StdOut.txt.zip","A","Evidence","82365c6a175193719140f409dec1915720ace41f","1881","0","1881"
"Evidence/CP-018/ZIP/CP018_Rustfmt_Run_Record.txt.zip","A","Evidence","12a5331d6cd2fdb0d76d20c67c62ff7a70a0363d","428","0","428"
"Evidence/CP-018/ZIP/CP018_Rustfmt_StdErr.txt.zip","A","Evidence","d67d517a30affa2a52d9ad3c7ab3634b38440ec8","146","0","146"
"Evidence/CP-018/ZIP/CP018_Rustfmt_StdOut.txt.zip","A","Evidence","25b807aeeb66a34d25377188df95d3b0ea84011f","461","0","461"
"Evidence/CP-018/ZIP/CP018_WASM_Build_Run_Record.txt.zip","A","Evidence","78947f4765727ae9c947eedb805d368bde6ed99c","622","0","622"
"Evidence/CP-018/ZIP/CP018_WASM_Build_StdErr.txt.zip","A","Evidence","7eccfb28719af961461f55870915d39aa4677325","293","0","293"
"Evidence/CP-018/ZIP/CP018_WASM_Build_StdOut.txt.zip","A","Evidence","0bef6896a81f6b1784173510eaeb61a828c81d10","152","0","152"
"src/lib.rs","M","Source","b6aaa205315108a6c13c57d6664ac0d43e7087e7","17265","16145","1120"
"tests/CP018_receipt_core_envelope.rs","A","Tests","a267a5bd6916476326d847f34ac253ce40ccdade","4970","0","4970"

requirement_id,title,family,major_family,scope,source_prd_status,source_build_flag,requirement_text,implementation_state,local_verification,independent_qa,requirement_acceptance,linked_checkpoints,checkpoint_disposition,git_commits,test_evidence,implementation_notes,last_evidence_day,source_revision
PB-STOR-001,Suitcase is the complete Data Sculptor-controlled persistence surface,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Every persistent project or analytical artifact intentionally created by Data Sculptor must be written into the visible, user-controlled Suitcase. Data Sculptor must not intentionally persist user data, analytical state, scratch state, logs, recovery state, or project metadata in hidden AppData-style locations or browser-private persistence such as OPFS. Incidental browser/OS runtime caches outside Data Sculptor control are explicitly outside this contract. F-24 browser-session persistence boundary: WASM-002 must not use IndexedDB, localStorage , OPFS, another browser-private database, or an equivalent hidden Data Sculptor-controlled persistence surface to remember a Suitcase directory handle, unsaved WIP text, project truth, analytical state, or live UI preferences between application instances. A later build may deliberately define a user-visible preferences or continuity mechanism, but WASM-002 does not create one implicitly. Volatile in-memory runtime state within the current application instance is permitted.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-002,No Data Sculptor-created subfolders,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor does not create scratch/cache subfolders inside the Suitcase. Logical organization is expressed by the flat filename grammar, open metadata, Store MAP, and human-facing aliases.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-004,__DS__ is the reserved Data Sculptor governed namespace,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Every artifact that Data Sculptor creates or intentionally interprets as one of its governed artifacts must use the exact visible prefix __DS__ . The prefix identifies participation in the Data Sculptor namespace; it does not imply that the artifact is temporary, scratch-only, or automatically generated.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-001,BANKED; separate requirement acceptance not claimed,03201870b8ec68730a0c027c572db03ccd5eeaa8,Evidence/CP-001/CP001_GREEN2_Test_Output.txt; Evidence/CP-001/CP001_WASM_Build_Output.txt,"CP001: bounded lexical artifact-class recognition via reserved_artifact_class(). Five native tests passed and Rust wasm32-target library built. No content/provenance/authority validation, persistence, or complete governed artifact contract implemented.",Day063,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-005,External inputs retain their identity; Data Sculptor derivatives enter the namespace,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"An analyst or external source file must not be renamed into __DS__ merely because Data Sculptor reads, fingerprints, certifies, or references it. If Data Sculptor creates a new governed derivative—such as an explicit converted source—the new artifact enters the __DS__ namespace under its semantic class. F-26 SOURCE boundary: a Suitcase-root file whose exact filename begins with the reserved prefix __DS__ is not treated as an analyst-owned source merely because it has a CSV-like extension or CSV-like bytes. It participates in the reserved Data Sculptor namespace and must satisfy the applicable governed-artifact contract before any governed role is granted.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-002,"T-ACCEPTED, BANKED; requirement remains partial",206dcd8b76af29edcb658a0c5a2dc40d87089fe3,Evidence/CP-002/CP002_Post_Format_Test_Output.txt; Evidence/CP-002/CP002_Post_Format_WASM_Build_Output.txt; Evidence/CP-002/CP002_Hash_Inventory_Verification.txt,CP002: exact __DS__ lexical prefix recognition via has_reserved_namespace_prefix(). Six native tests and wasm32-target compilation passed. The SOURCE boundary and governed CVT validation/emission rules in this requirement are NOT implemented.,Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-006,The governed semantic artifact-class registry is explicit and stable,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The token immediately following __DS__ must be an exact three-uppercase-letter semantic artifact class. The governed class tokens currently reserved by this PRD are: Class Meaning WKO Work Order RCP Receipt DGN Diagnostic Event — reserved; not emitted by WASM-002 HLP Help Report CER Certification Evidence CVT Converted Source RID Row Identity COL Materialized Column MAP Governed MAP artifact class — Store MAP and WKO MAP profiles CAT Store Catalog — collection-level orientation index across MAP-governed Stores INV Suitcase Inventory Snapshot SCR Scratch / Structural Support RCV Recovery Artifact — reserved; not emitted by WASM-002 BRD Brand Manifest — reserved; not emitted by WASM-002 LCK Suitcase Lock — reserved for the explicit later-V1 FINGERPRINT workflow; not emitted or maintained by ordinary WASM-002 WASM-002 emission boundary. DGN , RCV , BRD , and LCK are registered/reserved classes but are not emitted by WASM-002. Registration alone does not create a producer, serialization contract, validity contract, lifecycle, or acceptance surface. A later build that activates one of these classes must define those contracts explicitly before the class becomes emitted product behavior. The class states semantic role rather than serialization format. WIP is not an artifact class; it is the editable non-executable Work Order lifecycle state. The Flight Recorder defined by W002-STOR-012 is a derived chronological view of governed RCP artifacts and is not an additional semantic artifact class. Existing class tokens must not be silently reassigned to different meanings. A new class requires an explicit PRD revision.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-001; CP-003,CP-001 banked; CP-003 T-accepted and banked; requirement remains partial,03201870b8ec68730a0c027c572db03ccd5eeaa8; 2d06f6259de93f5beaa8eb15f8f22f171127a10e,Evidence/CP-001/CP001_GREEN2_Test_Output.txt; Evidence/CP-001/CP001_WASM_Build_Output.txt; Evidence/CP-003/CP003_Post_Format_Test_Output.txt,"CP001: bounded lexical artifact-class recognition via reserved_artifact_class(). Five native tests passed and Rust wasm32-target library built. No content/provenance/authority validation, persistence, or complete governed artifact contract implemented. CP003 adds locally verified lexical distinction between the 11 emittable-class tokens and four registered-but-not-emitted tokens; full governance/producer behavior not implemented.",Day063,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-007,Serialization is orthogonal to artifact class,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Filename extensions such as .toml , .html , .csv , .bin , and .txt describe physical serialization only and must not be used as semantic artifact classes. A governed HLP serialized as .html remains an HLP, and a governed WKO serialized as .txt remains a WKO. Any future BRD serialization must obey the same class-versus-format separation, but its format is not frozen by WASM-002.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-006,"T-ACCEPTED, BANKED; full class-specific serialization and authority contracts remain open",aff54d08dcbacaa0c54d8869749344a504c5ad61,Evidence/CP-006/CP006_RED_Test_Output.txt; Evidence/CP-006/CP006_Post_Format_Test_Output.txt; Evidence/CP-006/CP006_WASM_Build_Output.txt; Evidence/CP-006/CP006_Hash_Inventory_Verification.txt; Evidence/CP-006/CP006_Precommit_Git_Review.txt,"CP006: public ArtifactFilenameTokens and extract_artifact_filename_tokens() reuse the CP004/CP005 immutable filename validator and extract semantic_class and serialization_extension as separate borrowed lexical fields. Four new tests, total 19/19 native tests post-format; wasm32-target compilation exit 0; 20-file pre-verification SHA-256 inventory independently matched. Literal unknown class and extension values preserved without registration or approval. No class-specific extension allowlist, format contract, file contents, provenance, governed publication, trust, or authority implemented. T accepted CP006 and banked commit aff54d08dcbacaa0c54d8869749344a504c5ad61; independent Claude implementation QA remains pending. This is requirement PARTIAL, not fully closed.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-008,Namespace and class do not confer authority by themselves,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Renaming an arbitrary file to resemble a __DS__ artifact must not make it authoritative. Before treating a governed artifact as valid, Data Sculptor must validate the applicable filename grammar plus the content, provenance, fingerprint, lineage, or other evidence required by that artifact's contract. F-14/F-33 publication distinction: SCR-to-final promotion under W002-STOR-023 proves only that the artifact satisfied its class-specific publication predicate. It does not manufacture broader authority. In particular, WKO alias authority still comes from the committed WKO MAP, Store authority comes from the committed Store MAP, and CAT is orientation only. Retained SCR failure evidence remains non-authoritative, and the reserved RCV class is not emitted by WASM-002. F-26 SOURCE authority: a governed CVT is eligible as a WASM-002 SOURCE only when its exact canonical CVT identity and the publication predicate governed by W002-CONV-004 and W002-STOR-023 are satisfied. Filename resemblance, a .csv extension, or copied bytes alone do not confer CVT source authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,Cross-cutting constraint recognized in CP001/CP002 scope: filenames/classes alone convey no artifact authority. This requirement is NOT claimed implemented or touched.,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-009,Unknown and known-but-not-emitted Data Sculptor classes are preserved and reported,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"If WASM-002 encounters a syntactically valid __DS__ artifact whose three-letter semantic class is not allocated in the current registry, or whose class is a registered-but-not-emitted WASM-002 class ( DGN , RCV , BRD , or LCK ), Data Sculptor must preserve the physical file unchanged. It must not trust, execute, mutate, delete, rename, or reinterpret that file as a known emitted artifact merely because the filename has governed form. Unknown class does not mean invalid data; it means this build has no authority to interpret that class. A known-but-not-emitted class is likewise not an instruction to activate a dormant producer or lifecycle. Whenever a WASM-002 operation performs the governed Suitcase scan/enumeration relevant to such a file, the condition must be surfaced through a canonical INFO diagnostic rather than being silently ignored. INVENTORY must include the physical file under its existing metadata-only contract; if an existing classification field is rendered, an unknown class is identified as unknown/unrecognized and a known-but-not-emitted class is identified as reserved/not emitted without guessing additional semantics. F-33 adds no new Inventory schema field and does not pull the governed DIR feature into WASM-002.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-003,"T-ACCEPTED, BANKED; full preservation/INFO requirement not closed",2d06f6259de93f5beaa8eb15f8f22f171127a10e,Evidence/CP-003/CP003_Post_Format_Test_Output.txt; Evidence/CP-003/CP003_WASM_Build_Output.txt; Evidence/CP-003/CP003_Hash_Inventory_Verification.txt,"CP003: token-only Rust classify_artifact_class_token() returns registered/emittable, registered/not-emitted, unallocated, malformed-reserved, or outside-reserved disposition. Three new tests (27 cases) plus six prior regression tests passed, wasm32 compilation exit 0, 15-file historic SHA-256 inventory verified. No Suitcase scan, filesystem preservation, canonical INFO diagnostic, INVENTORY integration, full filename validity, or artifact authority implemented. RegisteredEmittable describes a class category; it does not authorize emission. Independent Claude QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-010,Namespace and class casing are canonical and exact,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor-generated names must use exact uppercase __DS__ and exact uppercase three-letter class tokens. Data Sculptor must not silently normalize variant namespace/class spellings into canonical governed artifacts. This rule applies even on case-insensitive filesystems. F-15 governed comparison rule: unless a requirement explicitly defines a different domain-specific comparison, WASM-002 semantic equality and textual reference resolution compare decoded strings by exact Unicode scalar-value sequence. Data Sculptor performs no case folding, locale folding, Unicode normalization, trimming, or host-filesystem equivalence before the comparison. Thus differently cased strings and canonically equivalent-but-differently-encoded Unicode strings remain distinct governed values. If a host filesystem cannot safely publish two physical names that the governed semantics distinguish, publication must refuse rather than merge or reinterpret the governed identities.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-007; CP-009; CP-010,"T-ACCEPTED, BANKED; exact lexical construction verified; full normative requirement remains partial; CP009 T-ACCEPTED, BANKED — pure exact-name root snapshot matching only; full requirement remains partial; CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open",3c512df519f3a2431b363e4c57dc234c02378124; dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8; b7c515faa9bd000369d7656e09437310261290ae,Evidence/CP-007/CP007_RED_Test_Output.txt; Evidence/CP-007/CP007_GREEN_Test_Output.txt; Evidence/CP-007/CP007_Post_Format_Test_Output.txt; Evidence/CP-007/CP007_WASM_Build_Output.txt; Evidence/CP-007/CP007_Hash_Inventory_Verification.txt; Evidence/CP-007/CP007_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Baseline_Test_Output.txt; Evidence/CP-009/CP009_RED_Test_Output.txt; Evidence/CP-009/CP009_GREEN_Test_Output.txt; Evidence/CP-009/CP009_Full_Regression_Test_Output.txt; Evidence/CP-009/CP009_Rustfmt_Check_Output.txt; Evidence/CP-009/CP009_Git_Whitespace_Check.txt; Evidence/CP-009/CP009_Post_Format_Test_Output.txt; Evidence/CP-009/CP009_WASM_Build_Output.txt; Evidence/CP-009/CP009_Hash_Inventory.txt; Evidence/CP-009/CP009_Hash_Inventory_Verification.txt; Evidence/CP-009/CP009_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Final_Staging_Review.txt; CP009_Git_Banking_Output.txt (separately archived post-commit evidence); Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived),"CP007: public build_immutable_artifact_filename_candidate() assembles exact class, UTC timestamp, UUID v4 and serialization extension tokens into an ordinary canonical immutable filename candidate; it delegates validation to the existing CP004/CP005 envelope validator and refuses malformed casing/identities rather than case-folding, trimming or normalizing input. Four new integration tests, total 23/23 native tests after Rustfmt; wasm32-target compilation exit 0; 21-entry SHA-256+byte inventory independently verified. Lexically valid unknown class tokens and unapproved extension tokens may be preserved as candidates; this grants no registration, serialization contract, authority, filesystem publication or content/provenance validation. The F-15 exact Unicode scalar-value semantic equality and host-filesystem collision/refusal requirements are NOT implemented. T approved and banked commit 3c512df519f3a2431b363e4c57dc234c02378124 (14 files), clean master; independent Claude adversarial implementation QA pending. Requirement remains PARTIAL, not fully closed. CP009 Day066: match_analyst_csv_root_snapshot(&str, &[RootSnapshotEntry]) -> RootSnapshotMatch applies CP008 analyst CSV candidate preflight, then exact Rust string equality (case, Unicode scalar sequence and whitespace preserved), reports no match, reported nonregular entry, ambiguous duplicate exact entries, or single caller-reported regular file. Entry origin and kind are caller assertions, not independently verified. Eight new tests; post-format full native regression 36/36; wasm32-unknown-unknown library compilation exit 0; SHA-256 inventory verified 22/22; staged whitespace exit 0; T approved and git banked 15 files, clean working tree. This is NOT actual root scanning, filesystem entry proof, browser permission, CSV/UTF-8 certification, governed CVT SOURCE eligibility or end-to-end requirement acceptance; independent Claude QA pending. CP010 Day066 also tests canonical uppercase __DS__/CVT tokens and exact lowercase .csv conversion-output extension, refusing variant prefix/class/extension spellings; existing canonical validator is reused without repair or normalization. Only lexical form is locally verified: no actual filesystem identity enforcement or publication collision handling. T accepted CP010; git b7c515faa9bd000369d7656e09437310261290ae; independent QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-011,Generated identity collisions regenerate the UUID and never overwrite,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor must never overwrite, rename, truncate, or mutate an existing artifact merely because a newly generated governed filename collides with it. For an ordinary immutable artifact using the governed UTC+UUID identity grammar, Data Sculptor must keep the originally established canonical UTC millisecond creation timestamp, generate a new canonical lowercase hyphenated UUID v4, reconstruct the candidate filename, and try creation again. Collision retry must not advance or falsify the artifact creation timestamp merely to obtain a different sort position. This retry may repeat until an unused valid identity is obtained. If UUID generation fails, the host cannot safely test/create the target, or another filesystem error prevents safe allocation, creation must refuse through the canonical diagnostic path rather than risk overwrite. Collision retry changes only the not-yet-created artifact's UUID. UUID is never used as a chronology field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-012,Names route; governed contents and provenance prove,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The filename must help humans and Data Sculptor identify the artifact's intended semantic role and route it to the correct validator. The artifact's governed content, lineage, receipt, fingerprint, provenance, and other required evidence establish what is actually true.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-013,Ordinary immutable governed artifacts use class → UTC millisecond → UUID v4 identity order,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The exact default filename grammar for an ordinary immutable Data Sculptor-governed artifact is: __DS__CCC__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.<extension> CCC is the governed semantic artifact class. YYYYMMDDTHHMMSSmmmZ is the artifact's governed UTC creation/publication timestamp at millisecond precision: four-digit year, two-digit month/day/hour/minute/second, exactly three millisecond digits, and literal T / Z . <uuid-v4> is a canonical lowercase hyphenated UUID v4. The extension is governed by the artifact's serialization contract. The token order is normative: namespace, semantic class, UTC timestamp, UUID, extension. UTC precedes UUID for every ordinary immutable class. Canonical UTC tokens with different values sort chronologically within the same class. UUID provides uniqueness and physical identity only; it must not be interpreted as a chronology tie-breaker when two artifacts share the same timestamp. When one governed all-or-refuse Store-state publication transaction creates multiple new analytical state artifacts, Data Sculptor establishes one canonical UTC millisecond publication-transaction timestamp before final identity allocation and uses that same UTC token for every newly published RID , COL , and MAP artifact created by that transaction. Each artifact receives its own UUID. Thus a first Store materialization gives the new RID, every newly materialized COL, and the successor MAP one shared transaction UTC; a later materialization gives only its newly created COL artifacts and successor MAP the new transaction UTC while the inherited RID and inherited COL artifacts retain their earlier identities. The shared transaction UTC is not the Work Order's authoring timestamp and does not require the Receipt filename UTC to match. RCP remains governed by W002-RCP-002 and carries its own receipt creation/publication timestamp. A shared transaction UTC expresses common publication membership, but MAP binding—not timestamp equality—remains authoritative for Store membership/current state. Source identity, source filename, run identity, parent identity, lineage, hashes, aliases, supersession, column identity, and other relationships must not be appended as ordinary identity tokens merely to make the filename descriptive; those facts belong in governed metadata and provenance. P2-03 successor-state UTC rule: when an operation will publish a successor Store MAP or successor WKO MAP, the transaction UTC remains a truthful observation of host UTC and must be strictly greater than the applicable chronology predecessor MAP UTC. Data Sculptor must not synthesize, increment, round forward, or otherwise fabricate a later UTC merely to satisfy chronology. UUID remains identity only and is never a chronology tie-breaker. The first MAP in a genuinely new Store lineage, and the first WKO MAP when no structurally valid WKO MAP exists, has no chronology predecessor and therefore uses the observed host UTC normally.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Immutable filename envelope, UTC and UUID syntax only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. Full requirement also governs true UTC millisecond identity, creation chronology, publication timestamp sharing, UUID identity semantics, and successor MAP chronology; none are implemented in CP004. Independent QA pending. CP005: CP005 now validates the timestamp token as a real Gregorian calendar date and ordinary UTC clock time (four-digit years 0001–9999, leap years, month lengths, 00–23 hours, 00–59 minutes/seconds, millisecond precision preserved lexically). Actual UTC issuance/publication, timestamp allocation, chronological truth, common transaction timestamp and identity authority are not implemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-014,Store-state publication transactions share UTC but never UUID identity,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Within one all-or-refuse Store-state publication transaction, every newly created RID , COL , and MAP final identity must carry the exact same canonical UTC millisecond transaction token and a distinct canonical UUID v4. UUID collision retry under PB-STOR-011 changes only the affected not-yet-created artifact UUID; it must not advance or alter the shared transaction UTC. Artifacts merely inherited or referenced by the transaction are not renamed, retimestamped, or assigned replacement UUIDs. A valid MAP may therefore bind artifacts created under several earlier transaction timestamps. Timestamp equality is evidence that artifacts were newly published by the same transaction; timestamp inequality is not evidence that artifacts belong to different Stores. P2-03 publication guard: for a successor Store-state transaction, the shared transaction UTC is established from truthful observed host UTC and is checked against the Store lineage's chronology predecessor before any newly created RID/COL/MAP artifact is promoted into its final governed class. If the observed transaction UTC is less than or equal to the chronology predecessor UTC, the publication refuses; the prior current MAP remains authoritative and no successor Store state commits.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-OPS-001,Permanent row identity after materialization,PB-OPS,PB-OPS,WASM-002,UNDER REVIEW,—,"Each logical Store has exactly one visible, deterministic RID artifact representing 1..N in governed logical CSV-record order. The header is excluded. Physical line count is not row identity: embedded newlines inside quoted fields remain inside one logical record. The RID is created when the first successful materialization establishes the Store and remains stable for the life of that Store. Every same-Store materialized or later aligned result column must contain exactly N data records in the same RID order. Multiple Stores may coexist in one Suitcase, and their RID values are unrelated; the meaningful row identity is therefore the pair (Store, RID) .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-OPS-002,Materialized columns preserve facts and alignment,PB-OPS,PB-OPS,WASM-002,UNDER REVIEW,—,Materialized columns preserve governed values in permanent row alignment. Materialization stores facts for reuse; it does not decide which rows are analytically interesting.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001,Flat Project Suitcase,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,The durable WASM-002 project model must not require semantic per-store subfolders. A logical store is represented by governed relationships among artifacts and metadata inside a flat project folder.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.1,The flat model must remain usable through ordinary filesystem tools.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.2,Native and browser hosts must use the same logical storage semantics even when their filesystem APIs differ.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.3,Folder placement must not be treated as the authoritative meaning of an artifact.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-002,Reserved Core namespace and sorting,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Every Data Sculptor Core-managed artifact must use the reserved __DS__ prefix. The prefix is deliberately visually distinctive and mechanically simple so Core artifacts cluster together under ordinary filename sorting in a mixed flat folder.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003,Three-character base-26 artifact class,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The class token must be exactly three uppercase ASCII letters A through Z, giving the fixed physical range AAA through ZZZ, and must immediately follow the reserved namespace within the frozen filename grammar.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.1,The three-character alphabetic class rule supersedes every earlier numeric class example.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.2,"Class ordering is positional base-26 using the alphabet A through Z: AAA, AAB, AAC, ... AAZ, ABA, ... ZZZ.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Ordinary lexical filename sorting therefore preserves the governed class order.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.3,"The namespace contains 26 cubed, or 17,576, possible class values while preserving one fixed-width token.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.4,Unallocated class tokens remain unassigned until explicitly allocated,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"WASM-002 does not reserve semantic meaning by numeric interval, lexical neighborhood, or implied class range. Any syntactically possible three-letter token that is not listed in the governed registry is unassigned for this build. A future artifact class may be allocated only by explicit PRD revision. Existing class meanings must never be shifted, renumbered, or reassigned merely to make room for later families.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.5,The WASM-002 artifact-class table is frozen by the governed registry,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The exact WASM-002 artifact-class table is the registry in PB-STOR-006. It is no longer a separate open storage freeze item. No additional reserved class ranges are defined by WASM-002. DGN , RCV , BRD , and LCK remain registered/reserved but are not emitted by WASM-002. Their presence in the registry does not create a WASM-002 producer, serialization contract, validity contract, lifecycle, or acceptance surface. Independent adversarial review must verify that every WASM-002-generated governed artifact uses a listed class that this build actually emits, that WIP remains a lifecycle state rather than a class, and that unknown/unallocated classes plus known-but-not-emitted classes are preserved and reported under PB-STOR-009 rather than silently interpreted or activated.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-004,Canonical Core filename envelope,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The default Core physical naming model for immutable governed artifacts is __DS__<CLASS>__<UTC>__<UUID>.<ext> . CLASS, UTC, and UUID are governed identity tokens. Human semantic labels are excluded from the physical identity envelope. A separately frozen artifact contract may define a well-known current-state singleton filename when that artifact must be updated in place and discovered by a stable name.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Default immutable filename-envelope structure only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. Singleton exception support, class-specific contracts and authority remain unimplemented. Syntactic success does not imply an authorized artifact. Independent QA pending. CP005: CP005 adds Gregorian calendar/UTC-clock validity to the already recognized immutable Core physical name. Singleton filenames, artifact-type extension rules and authorization remain unimplemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005,Canonical filename shape and fixed token lengths,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Every governed Core artifact type must have a canonical filename shape and total filename length so that a parser, browser host, native host, QA tool, or LLM can recognize malformed physical identity without interpreting variable human language. Under the Revision AH default immutable grammar, the canonical UTC token YYYYMMDDTHHMMSSmmmZ is exactly 19 ASCII characters and the canonical lowercase hyphenated UUID v4 token is exactly 36 ASCII characters. Class precedes UTC and UTC precedes UUID.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Fixed core lexical UTC (19 ASCII) and UUID v4 (36 ASCII) structure only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. No calendar validation, class/extension contract mapping, class-specific total length table, or filename publication gate is claimed. Independent QA pending. CP005: CP005 strengthens the fixed 19-ASCII-character UTC token with Gregorian calendar and UTC-clock range checks. Class-specific total filename lengths, extension mapping, and publication gates remain unimplemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.1,"If an artifact class has exactly one governed representation, all filenames in that class have one frozen total length.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.2,"If a future class permits more than one representation, each class/representation pair must still have a frozen total length.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.3,"Friendly store names, column names, aliases, and operation descriptions must never stretch or shorten a Core physical filename.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-006,Physical identity versus integrity,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,UUID identifies the governed artifact instance. SHA-256 records or verifies the exact bytes. The system must not overload one field to serve both identity and integrity.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007,Collision handling,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Physical filename collisions are expected to be rare but must be handled explicitly. Data Sculptor must never silently overwrite an existing governed artifact because a generated physical name already exists.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.1,"Before durable creation, the host must check whether the target physical name already exists.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.2,"On a UUID collision, the existing artifact is preserved and a fresh UUID is generated under the same relevant UTC/class context unless a later frozen rule requires a different deterministic response.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.3,Collision handling must be visible in the run Receipt/evidence when it occurs,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If governed identity allocation encounters one or more filename collisions before successfully allocating a non-colliding UUID identity, the canonical run Receipt must record that a collision retry occurred and the number of retries when the run reaches receipt publication. If identity allocation ultimately refuses, the refusal Receipt and diagnostic evidence must preserve the collision-failure fact without overwriting or mutating any pre-existing artifact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-008,Analyst-owned files remain analyst-owned,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Source files and analyst documents may retain their original filenames. Data Sculptor must not rename every input merely to fit the governed __DS__ namespace. For an ordinary WASM-002 analytical run, continuity between certification and materialization is established by the run-local source-binding contract, not by pretending a mutable source filename is permanent byte identity. Durable cross-run exact-byte verification requires separately governed integrity evidence such as the later V1 FINGERPRINT operation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-009,Store MAP as machine truth,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The Store MAP must provide the machine-readable relationship between governed physical artifacts and their logical meaning, including the fields required by the frozen schema for store identity, column identity, source reference/binding, run/materialization identity, row counts, status, lineage, supersession, and related provenance. Cryptographic hashes are recorded when a requirement or explicit operation actually produces them; the Store MAP contract must not imply that every source or artifact is automatically hashed during ordinary WASM-002 execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010,Aliases provide human orientation without a separate Store Index,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, human-facing orientation is provided by aliases exposed from governed Store MAP state and related governed artifacts. Aliases may help analysts navigate by meaning while preserving exact physical identities. WASM-002 does not publish or maintain a separate Store Index artifact. Richer directory/index presentation is carried by the governed DIR surface in WASM-003.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010.1,WASM-002 Store MAP profile is the unified Store metadata snapshot,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, the Store MAP profile of the governed MAP artifact class is the Store metadata snapshot. It records the Store's human-facing alias, Store-establishing source filename, exact RID artifact binding, RID alias, and the complete current materialized-column mappings and aliases governed by W002-STOR-019 through W002-STOR-019.12. WASM-002 must not create a second hidden or separately named Store-metadata file merely to bind the Store to its RID or aliases. The visible immutable __DS__MAP__...csv artifact is the authoritative governed Store MAP for this build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010.2,"Changing a friendly alias must not change physical identity, hashes, lineage, or historical provenance.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-011,"Store, row-universe, and future Boolean-selection-column rule",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Same-row derived columns and later aligned Boolean selection/filter columns remain within the same logical Store when row identity, row order, and cardinality are preserved. A future filter that evaluates every existing RID and writes one aligned two-valued Boolean result per RID does not by itself create a new row universe or a new logical Store. The canonical future selection tokens are 0 for FALSE and 1 for TRUE under PB-OPS-003 and PB-OPS-003.1. A new row universe is created only when a later governed operation actually changes which rows exist or their order—for example by building/exporting only selected rows, deduplicating rows, or otherwise materializing a different row set. Such an operation creates a new logical Store identity under the frozen row-identity contract. Filtering remains deferred from executable WASM-002 scope; this requirement freezes only the Store/RID compatibility rule that later filtering will rely upon.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-012,Current orientation and history are different truths,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Current Store orientation is represented by the applicable immutable MAP snapshot, while execution history is preserved by immutable RCP Receipts. For WASM-002, the Flight Recorder is the logical chronological view of published canonical RCP artifacts from actual Run invocations of saved immutable WKO Work Orders. It is not separately persisted and has no separate artifact class. Successful and refused runs contribute when Receipt publication succeeds; Receipt-publication failure is governed by W002-RCP-010 and must not be silently reconstructed as original evidence. Any Flight Recorder presentation is derived and regenerable from the authoritative Receipts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-013,Open representations,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Durable project artifacts should use documented open formats such as CSV, HTML, TXT, TOML, or other explicitly governed representations so that the Suitcase remains inspectable and portable outside Data Sculptor.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-014,LLM-readable storage grammar is a documentation principle,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The storage grammar, class table, Store MAP schema, current-state selection rule, and alias semantics must be documented clearly enough that an LLM collaborator can distinguish physical identity, logical meaning, integrity evidence, current state, and history without guessing. This is a documentation/readability principle for the Product Backlog PRD and related public product documentation. It does not create a new governed Suitcase artifact, require a new public-documentation file or publication operation, or add a separate WASM-002 acceptance deliverable beyond keeping the governing contract explicit and internally consistent.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-015,WASM-002 storage freeze status,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The current WASM-002 storage design preserves the resolved semantic artifact-class registry, canonical UTC millisecond rendering, class → UTC → UUID token order, UUID rendering/version, default immutable identity grammar, collision retry behavior, immutable one-Store-per-MAP versioning, Store-aware automatic MAP inheritance, complete-snapshot semantics, the exact eight-column Store MAP schema, deterministic Store/RID/COL alias defaults, rematerialization alias continuity, deterministic Store-MAP CSV serialization, Store-MAP eligibility/publication validation, materialization-coupled AS alias semantics, standalone alias maintenance using UPDATE ALIASES , explicit alias clearing with CLEAR ... ALIAS , deterministic default restoration with RESET ... ALIAS , exact historical Store-MAP selection using MAP ""<exact Store MAP filename>"" , canonical one-column COL serialization, the all-or-refuse materialization publication boundary, SCR -to-final-class host rename promotion, complete-set validation before promotion, new-Store RID-first promotion, inherited-RID reuse for existing-Store work, deterministic COL promotion, successor-MAP construction/validation as SCR , successor-MAP rename last as the Store-state commit point, rollback/recovery treatment for uncommitted promoted artifacts, the canonical RID CSV contract, the seven-operation Work Order execution surface, the canonical automatic TXT Receipt contract including exact WKO lineage, the Receipt-backed Flight Recorder, the governed HTML Suitcase Validation Certificate, the Work Order alias/comment contract plus WKO-MAP alias-registry profile, and the LCK reservation for explicit later-V1 FINGERPRINT evidence without automatic hashing in ordinary WASM-002. RID reconstruction/replacement is deliberately not part of the WASM-002 executable surface; RECOVER RID requirements are deferred to V1-BACKLOG. The Help-report provenance boundary is resolved: WASM-002 records governed HLP identity and lineage but does not automatically SHA-256 HLP bytes or create/refresh LCK evidence; exact-byte HLP integrity remains the later explicit FINGERPRINT/LCK workflow. Future branded Receipt rendering/Brand-Manifest integration remains outside the WASM-002 TXT-only Receipt contract. P2-04 closure: WASM-002 Store governance now has a complete two-tier artifact-validation model. Tier 1 supplies bounded Store-health checks for non-content-consuming paths; Tier 2 supplies full streaming RID/COL validation for content-consuming paths, candidate commit, and REPAIR MAP . The eight-column Store MAP remains unchanged and ordinary Store health makes no cryptographic claim of historical-byte identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-001,Every actual Run invocation of a saved WKO automatically produces one Receipt attempt,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"When the analyst invokes Run on a saved immutable WKO, Data Sculptor must automatically create one governed run-receipt attempt for that invocation. The Work Order must not require a RECEIPT , SAVE RECEIPT , or equivalent clause. An editable unsaved WIP is non-executable under the Work Order lifecycle contract and therefore cannot produce an execution Receipt. A saved WKO that is invoked and then refuses during validation or execution still has an execution outcome and must receive a refusal Receipt when receipt publication succeeds.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-002,The canonical WASM-002 Receipt is a governed TXT artifact with its own creation timestamp,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,The physical Receipt filename is: __DS__RCP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt The UTC token belongs to the Receipt artifact itself and represents the Receipt's governed creation/publication time under the canonical artifact-identity rules. It must not be copied from the authorizing WKO's filename merely to make the two filenames share a timestamp. The file is written visibly in the flat Suitcase under the governed RCP artifact class. Data Sculptor chooses the governed filename; the analyst does not supply it.,PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-014; CP-015,"CP014 T-ACCEPTED, GIT BANKED — canonical RCP TXT filename lexical recognizer only; own creation-time allocation, file emission, complete Receipt contract and publication unimplemented; CP015 T-ACCEPTED, GIT BANKED — pure lexical canonical SCR-to-RCP TXT filename-candidate pair matching only; no actual file/Receipt validation, promotion, publication or authority",f5038a183f1d3dc31b0065571bf8ac8814b5d8a9; be997dc0dbd65fc370814c4a5f2d0f1254870572,Evidence/CP-014/ZIP/CP014_RED_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_WASM_Build_Record.txt.zip; CP014_Git_Banking_Record.txt (external closeout); Evidence/CP-015/ZIP/CP015_RED_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_GREEN_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_PostAmend_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_Full_Regression_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_WASM_Build_Output.txt.zip; Evidence/CP-015/ZIP/CP015_Final_Archive_Manifest.txt.zip; CP015_PostCommit_Verification.txt (external closeout),"CP014 Day067: T-accepted, Git-banked lexical RCP .txt filename recognizer only. Pure is_canonical_rcp_filename_candidate(&str)->bool uses shared canonical envelope, rejects wrong class/extension/casing, malformed UTC/UUID, paths and whitespace. Six target GREEN passes; 64/64 native regression; Rustfmt and wasm32 library build PASS; 32 original-TXT-per-ZIP objects validated and committed unchanged. Commit f5038a183f1d3dc31b0065571bf8ac8814b5d8a9. No new Receipt timestamp generation, Receipt byte serialization, creation/promotion/publication or authority; independent implementation QA and browser runtime pending. CP015 Day067: T-approved pure is_matching_scr_rcp_filename_candidate_pair(&str,&str)->bool checks canonical SCR/RCP lowercase .txt candidates and exact timestamp/UUID pairing, reusing existing lexical recognizers and candidate derivation; rejects wrong classes/order, mismatched timestamps/UUID, paths, whitespace and noncanonical envelopes. Expected RED E0432 exit 101; six targeted GREEN PASS; T-approved formatting-only source+test amendment and recheck; full native regression 70/70 PASS, Rustfmt PASS, Rust 1.97.1 wasm32-unknown-unknown --lib compile PASS. Original TXT archived as 16 verified single-entry ZIPs; 18/18 committed Git blob identities checked; working tree clean. Banked at be997dc0dbd65fc370814c4a5f2d0f1254870572. No actual SCR/RCP file reads, Receipt content validation, timestamp generation, authority, promotion or publication; browser execution and independent implementation QA pending.",Day067,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-003,WASM-002 Receipts are TXT-only and independent of presentation state,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"For WASM-002, the canonical run Receipt is always plain TXT. Browser theme, built-in HTML presentation, Help voice, or other presentation state must not change whether the run Receipt is emitted as TXT or alter its governed facts. WASM-002 must not emit an HTML Receipt as an alternative to the canonical TXT Receipt. Configurable Brand Manifest behavior is deferred to a future build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-005,Canonical Receipt TXT serialization is deterministic,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The WASM-002 Receipt is UTF-8 without BOM and uses LF ( 0x0A ) line endings. Every Receipt ends with exactly one final LF. No serialized line carries trailing spaces, and no blank physical lines are emitted unless a later operation-specific grammar explicitly freezes them. It is a deterministic line-oriented KEY: VALUE document with a frozen core-key order followed by operation-specific fact sections in deterministic order. KEY is an uppercase ASCII field name. The separator is exactly one ASCII colon followed by exactly one ASCII space. KEY=VALUE is not valid canonical Receipt serialization. Fixed machine tokens and non-negative decimal integers are serialized unquoted. Human-authored text, filenames, aliases, headers, and other free text are serialized as double-quoted UTF-8 strings. Inside a quoted value, a literal double quote is represented by doubling it as """" . CR and LF are not permitted inside a single serialized value; each fact remains exactly one physical line. Enumerated values use the exact uppercase tokens frozen by the applicable requirement. Non-negative integers use ungrouped ASCII base-10 digits. This shared text rule is normative for all Receipt free-text values and is acceptance-tested byte-for-byte.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-016; CP-017; CP-018,"CP016 T-accepted, Git-banked: pure field-line formatting; CP017 T-accepted, Git-banked: caller-ordered field sequence; CP018 T-accepted, Git-banked: exactly ten ordered mandatory core keys in a core-only in-memory fragment. Whole Receipt, runtime lineage truth, field-specific vocabularies, operation-specific sections, durable creation and publication NOT implemented.",fde0f0a8b96c92f6cfb80b517396ff5512cccd13; 339cf12e747738d89442ce401feeea1afcd19dc6; 75620f17649a5d38d5357960bb99e9ac39ae354f,Evidence/CP-016/ZIP/CP016_RED_StdErr.txt.zip; Evidence/CP-016/ZIP/CP016_GREEN_Verification_StdOut.txt.zip; Evidence/CP-016/ZIP/CP016_PostFormat_Run_Record.txt.zip; Evidence/CP-016/ZIP/CP016_PostAmendment_Regression_StdOut.txt.zip; Evidence/CP-016/ZIP/CP016_WASM_Build_Run_Record.txt.zip; Evidence/CP-016/ZIP/CP016_PreFormat_Frozen_Test.rs.zip; Evidence/CP-016/ZIP/CP016_Final_Custody_Addendum_Record.txt.zip; CP016_Git_Postcommit_Integrity_Record.txt (external closeout); Evidence/CP-018/ZIP/CP018_PostFormat_Verification_Record.txt.zip; Evidence/CP-018/ZIP/CP018_PostFormat_Regression_StdOut.txt.zip; Evidence/CP-018/ZIP/CP018_WASM_Build_Run_Record.txt.zip; Evidence/CP-018/ZIP/CP018_Custody_Seal_Record.txt.zip; CP018_Git_Banking_Record.txt (external after-commit record),"CP016 Day068: T-approved and Git banked pure serialize_canonical_receipt_field_line(key, ReceiptFieldValue) and typed MachineToken, NonNegativeInteger(u64), QuotedText values. Exactly one KEY: VALUE\n line; uppercase ASCII lexical keys and machine tokens; ungrouped decimal u64; doubled interior quote; quoted UTF-8; CR/LF rejected within values. Eight frozen tests passed, 78/78 complete native regression, rustfmt check exit 0 after separately authorized formatting-only frozen-test amendment, wasm32-unknown-unknown --lib build exit 0. 36 individually verified evidence ZIPs Git banked; 31 original TXT evidence retained untracked. No whole-Receipt assembly, full document BOM/end-of-document acceptance, operation-specific core-key ordering, semantic token vocabulary, filesystem I/O, run invocation, authority, or publication. Independent adversarial implementation QA remains NOT_REVIEWED; no complete requirement acceptance. CP017 Day073: seven additional sequence tests, 85/85 full native regression, rustfmt correction preserved, wasm32 library build PASS, commit 339cf12e747738d89442ce401feeea1afcd19dc6. CP018 Day074: enforces the ordered ten-key common core through serialize_canonical_receipt_core_envelope by delegating to CP017; rejects missing, duplicate, reordered, mistyped key names and invalid lexical value, but does not validate field-specific semantics or full receipt. Intentional RED exit 101; nine GREEN tests; formatting-only correction recorded; 94/94 native regression, rustfmt PASS, WASM --lib build PASS; 30 individually checked evidence ZIPs, 32 committed paths, clean index/working tracked files; T-approved; commit 75620f17649a5d38d5357960bb99e9ac39ae354f. No independent implementation QA or browser execution.",Day074,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-006,Every Receipt records the fixed core execution facts and exact WKO lineage,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"Every canonical WASM-002 Receipt begins with the following common envelope keys in exactly this order: RECEIPT_VERSION RECEIPT_FILENAME RECEIPT_UTC WORK_ORDER_FILENAME OPERATION RUN_STARTED_UTC RUN_FINISHED_UTC RESULT DIAGNOSTIC_ID IDENTITY_COLLISION_RETRIES Day 060 H-02 version freeze: RECEIPT_VERSION is the unquoted integer 1 for the WASM-002 Receipt contract. RECEIPT_FILENAME is the exact physical governed RCP filename. RECEIPT_UTC is exactly the canonical UTC timestamp embedded in that filename and is distinct from the run start/finish timestamps. WORK_ORDER_FILENAME is the exact physical immutable WKO identity invoked and is the authoritative WKO→RCP lineage link. Day 060 H-09 / BM-06 truthful run-timestamp semantics RUN_STARTED_UTC and RUN_FINISHED_UTC are governed truthful host-UTC observations at millisecond precision. They are not decorative labels and are not synthesized from artifact filenames. RUN_STARTED_UTC is observed only after the exact saved WKO has been resolved and found eligible to Run, and immediately before operation-specific validation/execution begins. It therefore brackets operation validation, analytical work, publication attempts, refusal processing, and any governed rollback/cleanup performed by that Run. RUN_FINISHED_UTC is observed only after the operation has reached its final SUCCESS or REFUSED analytical outcome and all non-Receipt governed effects are settled: successful artifacts are committed, refusal state is established, and required rollback/cleanup or retained non-authoritative evidence classification is complete. Receipt publication begins only after this observation. For one Run, the truthful temporal invariant is: WKO_UTC ≤ RUN_STARTED_UTC ≤ each successfully published run-artifact UTC ≤ RUN_FINISHED_UTC ≤ RECEIPT_UTC where WKO_UTC is the governed UTC token embedded in the exact WORK_ORDER_FILENAME , and “run-artifact UTC” means the governed UTC embedded in each non-Receipt artifact successfully published by that Run, including a shared materialization transaction UTC where applicable. An operation that publishes no non-Receipt artifact simply has no middle artifact-UTC comparison. Equality is permitted because the canonical timestamp precision is milliseconds. Data Sculptor must not fabricate, increment, decrement, or reorder UTC values merely to make this invariant appear true. Receipt fixtures and retained acceptance evidence must use physically possible timelines under this rule. The existing rule that WKO and Receipt filename timestamps are not required to match remains unchanged: they are distinct events, but a WKO invoked by a Run must already exist as a governed artifact before that Run begins. RESULT is a closed WASM-002 vocabulary containing exactly SUCCESS and REFUSED . No other RESULT token is valid. DIAGNOSTIC_ID: NONE is used for an ordinary successful run; a refused run carries the exact governed diagnostic identity. The shared governed absence-state vocabulary is closed to these four tokens, with these exact meanings: NONE — the fact is applicable and definitively has no value in this event; NOT_RUN — the owning stage or operation was not executed; NOT_AVAILABLE — the fact is applicable or potentially applicable, but its value could not be obtained; NOT_APPLICABLE — the fact does not apply to this event, diagnostic, operation, or artifact. These states are semantically distinct and must not be substituted for one another. A count that was actually established as zero is serialized as the integer 0 , never as an absence token. The refusal-serialization matrix for every present operation-specific key is deterministic: State of the key's owning fact/stage at refusal Required serialization The fact was authoritatively established before refusal Serialize the exact governed value. The owning stage was never entered NOT_RUN . The owning stage ran and definitively produced no value/artifact for this event NONE . The fact applies but could not be obtained NOT_AVAILABLE . The fact does not apply to this event NOT_APPLICABLE . An applicable count was authoritatively established as zero 0 . A publication identity whose publication stage was never entered NOT_RUN , except where an earlier frozen operation-specific rule explicitly fixes another token. A publication identity whose publication stage was entered but no artifact of that identity successfully published NONE . A publication identity that successfully published The exact physical governed filename. For this contract, a fact is established only when its owning validation/stage has deterministically fixed the value and later execution cannot revise that fact. Candidate allocation, partial bytes, or an uncommitted publication does not establish a published-artifact identity. If parsing/validation refuses before one of the seven governed WASM-002 operations can be identified, the Receipt uses OPERATION: UNKNOWN_OPERATION , RESULT: REFUSED , and the applicable DIAGNOSTIC_ID . After the common envelope there is no operation-specific section; the Receipt proceeds directly to CREATED_ARTIFACT_COUNT: 0 . UNKNOWN_OPERATION is not an executable operation. After all operation-specific facts and indexed lists, every Receipt ends with: CREATED_ARTIFACT_COUNT: <N>
CREATED_ARTIFACT_001: ""...""
...
CREATED_ARTIFACT_N: ""..."" The created-artifact list contains only exact physical governed filenames successfully published by the run, excluding the Receipt itself. For this accounting, an artifact is successfully published only if it remains a committed governed artifact when the Run finishes; an artifact promoted and then rolled back, or left only as non-authoritative failure residue under All-or-Refuse, is excluded from CREATED_ARTIFACT_COUNT and its indexed list. Indexed suffixes are one-based decimal with a minimum width of three digits and no maximum width: 001 through 999 are zero-padded and 1000 onward uses the ordinary full ungrouped decimal form. When a count is zero, no indexed lines for that list appear. IDENTITY_COLLISION_RETRIES is always present and is 0 when no governed filename-allocation retry occurred. Receipt/WKO filename timestamps are not required to match. One immutable WKO may be run multiple times, each producing a distinct Receipt that points back to the same exact WORK_ORDER_FILENAME . F-08 DS-STEPS / Receipt token separation. Human-authored Work Orders use the readable terminal clauses below; the Receipt serializes the corresponding machine token in OPERATION . The two columns are not interchangeable spellings: DS-STEPS terminal clause Receipt OPERATION MATERIALIZE MATERIALIZE INVENTORY INVENTORY UPDATE ALIASES UPDATE_ALIASES REPAIR MAP REPAIR_MAP REPAIR WORK ORDER REGISTRY REPAIR_WORK_ORDER_REGISTRY CONVERT WINDOWS-1252 TO UTF-8 CONVERT_WINDOWS_1252_TO_UTF_8 CATALOG STORES CATALOG_STORES For example, REPAIR_MAP is not valid DS-STEPS syntax and REPAIR MAP is not the serialized Receipt token. UNKNOWN_OPERATION remains a refusal-only Receipt value when validation cannot identify one of these seven operations; it is not an executable operation.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-018,CP018 T-accepted and Git-banked: exact mandatory ten-core-key count and order in an in-memory formatting fragment only; no verified WKO lineage semantics or real execution facts.,75620f17649a5d38d5357960bb99e9ac39ae354f,Evidence/CP-018/ZIP/CP018_RED_StdErr.txt.zip; Evidence/CP-018/ZIP/CP018_GREEN_StdOut.txt.zip; Evidence/CP-018/ZIP/CP018_PostFormat_Regression_StdOut.txt.zip; Evidence/CP-018/ZIP/CP018_WASM_Build_Run_Record.txt.zip; Evidence/CP-018/ZIP/CP018_Custody_Seal_Record.txt.zip; CP018_Git_Banking_Record.txt (external after-commit record),"CP018 Day074: T-approved and locally Git-banked pure serialize_canonical_receipt_core_envelope enforces exactly the ten frozen header keys in order, calls existing CP017/CP016 serializer, refuses invalid count/order/value; nine targeted tests and 94/94 full native test regression pass, Rustfmt and WASM library compile pass. Does NOT prove correct data lineage, actual timestamps or vocabularies, operation-specific facts, durable writing or publication; independent Claude review and browser runtime not performed.",Day074,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-007,"Materialization Receipts record Store, RID, Stage 1, Stage 2, and output facts",W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"For a WASM-002 MATERIALIZE run, after the common envelope the Receipt serializes these operation-specific keys in exactly this order: SOURCE_FILENAME BASE_MAP_FILENAME RID_FILENAME RID_ACTION STAGE1_UTF8_OUTCOME CERTIFIED_SOURCE_BYTE_COUNT STAGE1_ELAPSED_MS UTF8_FIRST_INVALID_BYTE_OFFSET UTF8_STOP_REASON WINDOWS_1252_COMPATIBILITY_OUTCOME WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET STAGE2_LOGICAL_ROW_COUNT STAGE2_ELAPSED_MS CSV_REFUSAL_CONDITION CSV_SOURCE_BYTE_OFFSET CSV_PHYSICAL_LINE CSV_LOGICAL_RECORD CSV_FIELD_ORDINAL REQUESTED_COLUMN_COUNT RESOLVED_COLUMN_COUNT PUBLISHED_COL_COUNT zero or more indexed published-COL filename lines whose exact key form is PUBLISHED_COL_<INDEX>_FILENAME (for example PUBLISHED_COL_001_FILENAME , PUBLISHED_COL_002_FILENAME ) SUCCESSOR_MAP_FILENAME OPERATIONAL_NAME_FALLBACK_COUNT zero or more indexed fallback triplets: OPERATIONAL_NAME_FALLBACK_001_COLUMN_ORDINAL , OPERATIONAL_NAME_FALLBACK_001_ASSIGNED_NAME , OPERATIONAL_NAME_FALLBACK_001_REASON , continuing under the common indexed-key rule. BASE_MAP_FILENAME: NONE denotes a newly established Store with no predecessor Store MAP. Day 060 H-11 / BM-08 RID_ACTION ownership and establishment RID_ACTION is a governed execution fact describing what this Run actually established for the Store RID path. It is never an intention, plan, or prediction. RID_ACTION: REUSED is established when routing has selected an existing Store, the exact inherited RID filename is known, and that inherited RID has passed the validation required to proceed. Because the RID already exists, this fact may be established before Stage 1 or Stage 2 completes. RID_ACTION: CREATED is established only when a new-Store RID candidate has successfully completed governed promotion into its final RID identity. Merely planning, allocating, writing, closing, validating, or naming an SCR candidate does not establish CREATED . Until either of those facts is established, the common refusal matrix governs RID_ACTION . For a new-Store path that refuses before successful RID promotion, RID_ACTION is NOT_RUN . If an existing-Store route is identified but the required inherited RID fact cannot be validly established, RID_ACTION is NOT_AVAILABLE . RID_FILENAME is a separate fact: for REUSED , it is the exact already-published inherited RID filename as soon as reuse is established; for CREATED , it is the exact governed final RID filename only after successful RID promotion; before new-RID promotion succeeds, no candidate/SCR filename may be serialized as though it were a published RID. With RID_ACTION: CREATED , RID_FILENAME records the RID identity successfully promoted during the Run even if that RID is later rolled back under All-or-Refuse; rollback does not erase the already-established RID_ACTION / RID_FILENAME execution facts. The refusal-boundary matrix is therefore: Materialization state RID_ACTION RID_FILENAME Validation/routing refuses before a Store/RID path is established NOT_RUN NOT_RUN or NOT_AVAILABLE only when an applicable routing fact could not be obtained under the common matrix New Store; Stage 1 refusal NOT_RUN NOT_RUN New Store; Stage 2 refusal NOT_RUN NOT_RUN New Store; post-Stage-2 gate refusal before RID promotion NOT_RUN NOT_RUN New Store; RID candidate/promotion has not successfully completed NOT_RUN NOT_RUN New Store; RID promotion succeeds CREATED exact published RID filename Existing Store; exact inherited RID selected and validated REUSED exact inherited RID filename Existing Store; later Stage 1, Stage 2, gate, or publication refusal after reuse was established REUSED exact inherited RID filename Existing lineage identified but required inherited RID cannot be validly established NOT_AVAILABLE NOT_AVAILABLE A refusal Receipt that says RID_ACTION: CREATED while RID_FILENAME is NONE or NOT_RUN and no RID was successfully promoted is invalid evidence. STAGE1_UTF8_OUTCOME has exactly two completed Stage-1 values: PASS and FAIL . If Stage 1 never ran, the value is NOT_RUN . If Stage 1 began but a separate failure prevented a governed PASS/FAIL determination, the value is NOT_AVAILABLE . NOT_APPLICABLE is not valid for this key. UTF8_FIRST_INVALID_BYTE_OFFSET and UTF8_STOP_REASON are refusal-only Stage-1 evidence. On STAGE1_UTF8_OUTCOME: FAIL , the offset is mandatory and is the exact zero-based absolute physical source-byte offset of the first byte of the invalid sequence, and the stop reason is mandatory and exactly INVALID_UTF8_SEQUENCE . Neither field may be NOT_AVAILABLE when the Stage-1 outcome is FAIL . On PASS , both fields are NOT_APPLICABLE . If Stage 1 never ran, both are NOT_RUN . If Stage 1 began but no UTF-8 PASS/FAIL conclusion was established because of a separate failure, both refusal-only fields are NOT_APPLICABLE . WINDOWS_1252_COMPATIBILITY_OUTCOME and WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET are the governed F-16 follow-on facts. They are evaluated only after STAGE1_UTF8_OUTCOME: FAIL . When the complete second pass reaches EOF with every byte mappable, the outcome is COMPATIBLE and the offset is NOT_APPLICABLE . When the pass encounters one of the undefined bytes frozen in W002-CONV-002.4, the outcome is INCOMPATIBLE and the offset is the exact zero-based absolute physical source-byte offset of the first such byte. If the pass begins but an independent failure prevents a conclusion, both fields are NOT_AVAILABLE . If Stage 1 did not conclude FAIL , the compatibility pass does not run and both fields are NOT_RUN . The five exact CSV refusal keys CSV_REFUSAL_CONDITION , CSV_SOURCE_BYTE_OFFSET , CSV_PHYSICAL_LINE , CSV_LOGICAL_RECORD , and CSV_FIELD_ORDINAL carry the exact structural CSV refusal condition and location oracle frozen in W002-MAT-002.8. If Stage 2 never ran, all five are NOT_RUN ; if Stage 2 completed without an applicable CSV refusal, all five are NOT_APPLICABLE ; on a CSV refusal, each established location fact is serialized and any applicable fact that could not be obtained is NOT_AVAILABLE . The MATERIALIZE refusal-stage matrix is: Refusal boundary Validation/routing and request facts Stage 1 facts Stage 2 facts Publication facts Validation, before Stage 1 Serialize each fact already established; an applicable fact that validation could not obtain is NOT_AVAILABLE . REQUESTED_COLUMN_COUNT is the actual count when the KEEP list parsed completely; otherwise NOT_AVAILABLE . RESOLVED_COLUMN_COUNT and fallback records are NOT_RUN until name/ordinal resolution has run. NOT_RUN for all Stage 1-owned facts. NOT_RUN for all Stage 2-owned facts. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Stage 1 refusal Established validation/routing facts are exact values. Serialize the exact Stage 1 outcome/timing and established refusal evidence; incomplete applicable facts are NOT_AVAILABLE . The Windows-1252 compatibility fields then serialize the exact complete assessment result under the rule above; if an independent assessment failure prevents a conclusion, they are NOT_AVAILABLE . NOT_RUN for all Stage 2-owned facts. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Stage 2 refusal Established validation/routing facts are exact values. Completed Stage 1 facts are exact values; UTF-8 refusal fields are NOT_APPLICABLE when no UTF-8 refusal occurred. Because Stage 1 passed, both Windows-1252 compatibility fields are NOT_RUN . STAGE2_ELAPSED_MS is the actual elapsed time when obtained; STAGE2_LOGICAL_ROW_COUNT is NOT_AVAILABLE unless the complete accepted logical row count was established; CSV refusal facts follow the rule above. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Post-Stage-2 gate refusal before publication All facts established through the gate are serialized exactly; non-applicable UTF-8/CSV refusal fields are NOT_APPLICABLE . Both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Publication refusal before the successor-MAP publication stage is entered All facts established before refusal are serialized exactly. This row includes a new-Store RID/COL identity-allocation or promotion refusal that occurs before the successor-MAP publication stage is entered. Completed Stage 1 and Stage 2 facts remain exact; non-applicable UTF-8/CSV refusal fields use their governed absence tokens, and both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. Under All-or-Refuse publication, PUBLISHED_COL_COUNT: 0 and no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN because the successor-MAP publication stage was never entered. A candidate filename is never serialized as a published identity. Publication refusal after the successor-MAP publication stage is entered All facts established before refusal are serialized exactly. Any RID fact already established before this later refusal remains governed by the RID_ACTION/RID_FILENAME matrix above. Completed Stage 1 and Stage 2 facts remain exact; non-applicable UTF-8/CSV refusal fields use their governed absence tokens, and both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. Under All-or-Refuse publication, PUBLISHED_COL_COUNT: 0 and no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NONE because the successor-MAP publication stage was entered but no successor MAP successfully published. A candidate filename is never serialized as a published identity. Success All applicable facts are exact values; refusal-only UTF-8/CSV fields are NOT_APPLICABLE . Both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. PUBLISHED_COL_COUNT is the actual count; indexed keys are exactly PUBLISHED_COL_001_FILENAME onward in resolved KEEP order; SUCCESSOR_MAP_FILENAME is the exact published successor MAP filename. Day 060 H-24 / BM-08 publication-boundary split: these two MATERIALIZE publication-refusal rows apply the common W002-RCP-006 ownership rule to the successor-MAP publication stage. NOT_RUN means that stage was never entered; NONE means it was entered but no successor MAP successfully published. The early boundary is exercised by the RID identity-allocation exhaustion fixture; the later boundary has its own byte-exact golden fixture. OPERATIONAL_NAME_FALLBACK_COUNT is NOT_RUN until operational-name resolution has run; afterward it is the established non-negative count, including literal 0 . Fallback records are ordered by ascending physical source-column ordinal. the exact fallback key OPERATIONAL_NAME_FALLBACK_<INDEX>_REASON is exactly SOURCE_HEADER_EXCEEDS_1024_SCALARS . For successful Store-establishing materialization, the common created-artifact list is ordered RID first, newly published COLs in resolved KEEP order, then successor MAP. For successful existing-Store materialization, the inherited RID is not newly created; the list contains newly published COLs in resolved KEEP order followed by the successor MAP. P3-09 Receipt oracle: when Stage 2 refuses because the certified source contains no logical CSV record, the five CSV refusal fields must serialize exactly as CSV_REFUSAL_CONDITION: NO_HEADER_RECORD , CSV_SOURCE_BYTE_OFFSET: <exact source byte length> , CSV_PHYSICAL_LINE: 1 , CSV_LOGICAL_RECORD: 1 , and CSV_FIELD_ORDINAL: 1 . Day 060 H-13 / BM-10 clarification: within those five governed CSV refusal fields, the zero-byte and UTF-8-BOM-only cases differ only in CSV_SOURCE_BYTE_OFFSET : 0 versus 3 . Their complete Receipt bytes also differ wherever the underlying source identity, certified source byte count, Work Order identity, run/Receipt timestamps, Receipt filename/UUID, or other fixture-specific governed facts differ. The complete Receipts must never be described as differing only by one field. F-20 operational-name Receipt oracle: OPERATIONAL_NAME_FALLBACK_COUNT counts selected/materialized columns whose exact source header exceeded 1,024 Unicode scalar values. Each corresponding ..._ASSIGNED_NAME stores the final deterministic operational/default-alias name after any permitted fallback collision disambiguation; ..._REASON remains exactly SOURCE_HEADER_EXCEEDS_1024_SCALARS . The Receipt does not copy the oversized exact source header merely to explain the fallback. The common indexed-key rule from W002-RCP-006 applies without a maximum width. A full-width KEEP is therefore representable through PUBLISHED_COL_16384_FILENAME (and corresponding fallback indexes when applicable); the three-digit examples are a minimum-width convention, not a 999-item ceiling.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-008,Other WASM-002 operations add deterministic operation-specific Receipt facts,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The same common envelope, closed RESULT/absence vocabulary, refusal matrix, created-artifact tail, and indexed-key rule apply to the other executable WASM-002 operations. Their operation-specific key tables are closed as follows. INVENTORY INVENTORY_FILENAME INVENTORY_ENTRY_COUNT Refusal boundary INVENTORY_ENTRY_COUNT INVENTORY_FILENAME Validation before inventory scan NOT_RUN NOT_RUN Inventory scan/measurement refusal Exact count if the complete count was established; otherwise NOT_AVAILABLE NOT_RUN Publication refusal after the snapshot facts were established Exact established count, including 0 NONE Success Exact established count Exact physical published INV filename UPDATE_ALIASES BASE_MAP_FILENAME SUCCESSOR_MAP_FILENAME Refusal boundary BASE_MAP_FILENAME SUCCESSOR_MAP_FILENAME Validation/routing before an exact base MAP is established NOT_AVAILABLE NOT_RUN Validation/gate refusal after the exact base MAP is established Exact base MAP filename NOT_RUN Publication refusal Exact base MAP filename NONE Success Exact base MAP filename Exact published successor MAP filename REPAIR_MAP TARGET_MAP_FILENAME RID_FILENAME BROKEN_COL_COUNT zero or more indexed broken-COL filename lines using exact key form BROKEN_COL_<INDEX>_FILENAME (for example BROKEN_COL_001_FILENAME , BROKEN_COL_002_FILENAME ) RETAINED_COL_COUNT SUCCESSOR_MAP_FILENAME Broken COL filenames are ordered by ascending exact UTF-8 filename bytes. RETAINED_COL_COUNT is the actual count once repair analysis completes, including literal 0 . Refusal boundary Target/RID facts Broken/retained facts SUCCESSOR_MAP_FILENAME Validation before an exact target MAP/RID is established Established facts are exact; otherwise NOT_AVAILABLE NOT_RUN NOT_RUN Repair-analysis refusal before a repair result is established Exact established values Exact values if established; otherwise the applicable unavailable/not-run token from the common matrix NOT_RUN All-COLs-broken refusal frozen under F-03/F-09 Exact values Exact broken count/list; RETAINED_COL_COUNT: 0 NONE — this earlier frozen named refusal remains an explicit operation-specific exception. Publication refusal Exact values Exact repair-analysis values NONE Success Exact values Exact repair-analysis values Exact published successor MAP filename REPAIR_WORK_ORDER_REGISTRY BASE_WKO_MAP_FILENAME REMOVED_STALE_ROW_COUNT zero or more indexed stale-WKO filename lines using exact key form REMOVED_STALE_WKO_<INDEX>_FILENAME (for example REMOVED_STALE_WKO_001_FILENAME , REMOVED_STALE_WKO_002_FILENAME ) REGISTERED_CURRENT_COUNT zero or more indexed current-WKO filename lines using exact key form REGISTERED_CURRENT_WKO_<INDEX>_FILENAME (for example REGISTERED_CURRENT_WKO_001_FILENAME , REGISTERED_CURRENT_WKO_002_FILENAME ) REGISTERED_DEPRECATED_COUNT zero or more indexed deprecated-WKO filename lines using exact key form REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME (for example REGISTERED_DEPRECATED_WKO_001_FILENAME , REGISTERED_DEPRECATED_WKO_002_FILENAME ) SUCCESSOR_WKO_MAP_FILENAME Each filename list is independently sorted by ascending exact UTF-8 filename bytes. If the bootstrap repair WKO is newly discovered and registered, it appears in the appropriate registered list under W002-STOR-018.3 and W002-STOR-018.4. Day 060 H-10 / BM-07 count semantics: REGISTERED_CURRENT_COUNT and REGISTERED_DEPRECATED_COUNT count only previously unregistered structurally valid WKOs that this repair Run newly adds to the successor WKO MAP with the stated status. They do not count surviving pre-existing rows already present in the base registry. The indexed filename lines list exactly the corresponding newly registered WKOs and no others. If the bootstrap repair WKO is one of those newly registered WKOs, it must appear in exactly one registered list. A successful repair Receipt that omits a newly registered bootstrap repair WKO is invalid evidence. Refusal boundary Base registry Repair-plan counts/lists SUCCESSOR_WKO_MAP_FILENAME Validation before the current structurally valid WKO MAP is established NOT_AVAILABLE NOT_RUN NOT_RUN Repair-analysis/gate refusal Exact base WKO MAP filename Exact values if the repair plan was established; otherwise the common matrix governs each present field NOT_RUN Publication refusal Exact base WKO MAP filename Exact established repair-plan values NONE Success Exact base WKO MAP filename Exact established repair-plan values Exact published successor WKO MAP filename CONVERT_WINDOWS_1252_TO_UTF_8 SOURCE_FILENAME SOURCE_ENCODING UNDEFINED_WINDOWS_1252_BYTE_OFFSET MATERIALIZED_ENCODING TRANSCODING SOURCE_CHANGED OUTPUT_FILENAME UNDEFINED_WINDOWS_1252_BYTE_OFFSET is the zero-based absolute physical source-byte offset of the first byte undefined by the frozen Windows-1252 mapping when that refusal occurs. If the compatibility stage never ran it is NOT_RUN ; if the stage ran and no undefined-byte refusal occurred it is NOT_APPLICABLE ; if the fact applies but could not be obtained it is NOT_AVAILABLE . Day 060 H-14 / BM-11 undefined-Windows-1252-byte refusal oracle For CONVERT WINDOWS-1252 TO UTF-8 , an undefined Windows-1252 byte is detected during the complete pre-transcoding compatibility assessment . Transcoding has not begun when this refusal is established. When the complete compatibility assessment encounters the first undefined byte, the Receipt must serialize these exact operation facts: SOURCE_ENCODING: WINDOWS-1252-INCOMPATIBLE
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: <exact zero-based absolute physical source-byte offset>
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE WINDOWS-1252-INCOMPATIBLE is the exact SOURCE_ENCODING token for this governed CONVERT refusal. OUTPUT_FILENAME: NONE means the operation definitively established that no CVT was published for the event. No CVT candidate may be reported as output. The compatibility scan reports the first undefined byte only. Later undefined bytes do not replace that offset. Permitted changes in scan buffer/window size or boundary placement must not change the reported absolute offset. Day 060 H-25 / BM-04 already-valid-UTF-8 refusal oracle. If the complete bound source passes strict UTF-8 validation, CONVERT refuses as unnecessary before Windows-1252 compatibility assessment or transcoding. The Receipt must serialize these exact operation facts: SOURCE_ENCODING: UTF-8
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: NOT_RUN
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE UTF-8 is the exact SOURCE_ENCODING token for this governed refusal. OUTPUT_FILENAME: NONE means the classification gate definitively established that this event publishes no CVT. The Windows-1252 compatibility stage is not entered. Refusal boundary Source/classification facts Conversion facts OUTPUT_FILENAME Validation/classification refusal before conversion begins Serialize each fact already established; an applicable fact that could not be obtained is NOT_AVAILABLE . The undefined-byte offset follows the rule above. MATERIALIZED_ENCODING and TRANSCODING are NOT_RUN when conversion did not run. SOURCE_CHANGED is the exact governed value once established. NONE only for either of the two definitively classified no-CVT cases: (1) the complete source is already valid strict UTF-8 and conversion is unnecessary; or (2) the complete Windows-1252 compatibility assessment finds an undefined byte. For other validation/classification refusals before conversion begins, OUTPUT_FILENAME: NOT_RUN unless another normative rule explicitly assigns a different closed token. Conversion/refusal after bounded transcoding begins but before publication Exact established source/classification facts Serialize exact established conversion facts; applicable incomplete facts use NOT_AVAILABLE . NOT_RUN Publication refusal Exact established facts Exact established conversion facts NONE Success SOURCE_ENCODING: WINDOWS-1252-COMPATIBLE ; undefined-byte offset NOT_APPLICABLE MATERIALIZED_ENCODING: UTF-8 ; TRANSCODING: BOUNDED_STREAMING ; SOURCE_CHANGED: NO Exact published CVT filename CATALOG_STORES CATALOG_ENTRY_COUNT CATALOG_FILENAME Refusal boundary CATALOG_ENTRY_COUNT CATALOG_FILENAME Validation/discovery refusal before the complete authoritative catalog row set is established NOT_AVAILABLE NOT_RUN Publication refusal after the complete catalog row set is established Exact established count, including 0 NONE Success Exact established count Exact physical published CAT filename On success, CATALOG_ENTRY_COUNT equals the number of data rows in the published CAT. CAT itself is the only new non-Receipt governed artifact produced by the operation. RECOVER RID / RECOVER_RID is not a valid executable WASM-002 operation in Revision BM.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-009,"Receipt truth is execution evidence, not presentation authority",W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The Receipt records what Data Sculptor actually attempted, observed, refused, and successfully published. It must not reinterpret the analyst's WKO, replace the Store MAP, or become a second analytical command surface. The WKO remains the durable authorization record; Store MAP/RID/COL artifacts remain the governed analytical state; diagnostic events remain the refusal/help truth; the Receipt cross-references those facts as the durable run ledger. The body of published canonical RCP artifacts is the authoritative evidence substrate for the Flight Recorder logical view defined in W002-STOR-012.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-010,Receipt-publication failure is itself a governed evidence failure,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"Data Sculptor must never claim that a durable Receipt exists until the RCP file has been successfully written and closed in the Suitcase. If host or filesystem failure prevents Receipt publication, the browser must surface a canonical diagnostic through the Help Engine stating that receipt evidence could not be persisted. A receipt-publication failure does not retroactively falsify analytical artifacts that were already successfully committed under their own publication contracts, but the user-facing run summary must clearly distinguish analytical outcome from receipt-persistence failure. Data Sculptor must not invent, backdate, or silently reconstruct a Receipt and present it as the original run artifact. F-14 publication path, reconciled by F-33: the RCP itself is first written as the corresponding SCR candidate under W002-STOR-023.1, closed, reopened and validated against the exact Receipt serialization/key contract before the class-token rename to RCP . If final RCP promotion fails, the candidate remains non-authoritative SCR evidence. Help may identify the exact retained SCR filename when that fact was established, but it must still state that the canonical Receipt was not persisted. WASM-002 does not emit an RCV artifact for this failure.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-001,Successful materialization Receipt and WKO-lineage acceptance,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,"A Store-establishing materialization fixture must run one saved WKO, publish exactly one canonical TXT RCP, and prove that the Receipt identifies the exact WKO through WORK_ORDER_FILENAME , source, RID_ACTION: CREATED , new RID, Stage 1 result/bytes/time, Stage 2 row count/time, all requested COL artifacts in resolved KEEP order, successor Store MAP, published-artifact count, timestamps, and RESULT: SUCCESS . The RCP filename UTC must represent the Receipt artifact's own creation/publication event and must not be required to equal the WKO filename UTC. The same immutable WKO must then be executable again in an appropriate fixture, producing a second distinct RCP with its own Receipt/run timestamps while both Receipts contain the same exact WORK_ORDER_FILENAME . A later same-Store materialization fixture must additionally prove RID_ACTION: REUSED and the original RID filename. The Store-establishing fixture must also prove that the newly created RID, every newly created COL, and the successor MAP carry one identical publication-transaction UTC token while each has a distinct UUID; the RCP filename UTC remains its own Receipt publication timestamp and is not required to equal that analytical transaction UTC. A later same-Store materialization must prove that newly created COLs and its successor MAP share the later transaction UTC while the inherited RID retains its original timestamp/UUID. F-07 Stage-1 success fixture: a successful materialization Receipt must serialize STAGE1_UTF8_OUTCOME: PASS , with UTF8_FIRST_INVALID_BYTE_OFFSET: NOT_APPLICABLE and UTF8_STOP_REASON: NOT_APPLICABLE . Separate refusal fixtures under W002-RCP-ACC-002 must prove FAIL plus the mandatory exact offset and INVALID_UTF8_SEQUENCE . F-20 maximum-width Receipt acceptance: a successful full-width materialization fixture must prove that published-COL indexed keys continue through PUBLISHED_COL_16384_FILENAME using the minimum-three-digit/no-maximum suffix rule. Oversized-header fixtures must prove the exact fallback count, source ordinal, assigned operational name, and SOURCE_HEADER_EXCEEDS_1024_SCALARS reason without embedding the oversized source-header text in the Receipt merely as fallback evidence. F-23 additional successful-Receipt coverage: acceptance must include a successful INVENTORY run whose RCP carries the exact governed INVENTORY operation-specific facts and a successful UPDATE_ALIASES run whose RCP carries the exact BASE_MAP_FILENAME and SUCCESSOR_MAP_FILENAME while reporting only actually published artifacts in the common created-artifact tail. F-23 UUID-collision seam: using a controlled UUID sequence, acceptance must force one or more governed filename collisions before successful allocation. Every pre-existing colliding artifact must remain byte-for-byte unchanged; allocation must retain the originally established governed UTC context while changing only the not-yet-created UUID as permitted; and the published Receipt must report the exact retry count in IDENTITY_COLLISION_RETRIES . Day 060 H-09 success-timeline acceptance Every retained successful Receipt fixture must satisfy the W002-RCP-006 temporal invariant using its actual embedded UTC tokens. Acceptance must mechanically prove: the invoked WKO UTC is less than or equal to RUN_STARTED_UTC ; every non-Receipt governed artifact successfully published by that Run has a governed artifact/transaction UTC between RUN_STARTED_UTC and RUN_FINISHED_UTC , inclusive; RUN_FINISHED_UTC is less than or equal to the Receipt filename/ RECEIPT_UTC ; and no fixture relies on an artifact timestamp that occurs after the Receipt that claims it, or before the Run that created it. A controlled-clock acceptance seam may be used to make equality and strict-order cases deterministic, but the fixture generator must not alter timestamps after the fact merely to satisfy the checker. Day 060 H-11 successful RID_ACTION acceptance A successful new-Store materialization Receipt may report RID_ACTION: CREATED only because the RID was actually promoted into its final governed RID identity during that Run. A successful existing-Store materialization Receipt reports RID_ACTION: REUSED and the exact inherited RID filename; no new RID candidate is created for that Run.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-002,Refusal Receipt acceptance,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,"A saved WKO that is actually Run and deterministically refuses must still produce one canonical TXT Receipt when Receipt publication itself remains available. The emitted bytes must conform to the closed RESULT vocabulary, the four governed absence tokens, the exact operation-specific key spelling/order, and the refusal matrix in W002-RCP-006 through W002-RCP-008. Acceptance must include byte-exact golden Receipt fixtures for every distinct refusal-boundary row required to exercise the serialization matrix for each of the seven executable WASM-002 operations: MATERIALIZE , INVENTORY , UPDATE_ALIASES , REPAIR_MAP , REPAIR_WORK_ORDER_REGISTRY , CONVERT_WINDOWS_1252_TO_UTF_8 , and CATALOG_STORES . Multiple Diagnostic IDs that map to the same refusal boundary and the same serialization row do not require duplicate byte fixtures merely because the Diagnostic ID differs. Acceptance must additionally include one byte-exact UNKNOWN_OPERATION refusal fixture proving the common envelope, OPERATION: UNKNOWN_OPERATION , RESULT: REFUSED , the exact diagnostic ID, absence of any operation-specific section, and immediate CREATED_ARTIFACT_COUNT: 0 . Fixtures must prove that NONE , NOT_RUN , NOT_AVAILABLE , and NOT_APPLICABLE retain distinct meanings; an established zero count is serialized as 0 ; no candidate filename is reported as a published identity; and every indexed key uses its complete frozen name and the minimum-three-digit/no-maximum suffix rule. An unsaved WIP must be proven unable to Run and therefore must not create an execution Receipt. F-16 materialization-refusal fixtures: byte-exact MATERIALIZE refusal Receipts must exercise the new compatibility pair in all four applicable states: NOT_RUN when Stage 1 did not fail; COMPATIBLE plus NOT_APPLICABLE offset; INCOMPATIBLE plus the exact first undefined-byte offset; and NOT_AVAILABLE / NOT_AVAILABLE when an independent compatibility-read failure prevents a conclusion. F-23 Receipt-publication failure fixture, reconciled by F-33: a controlled filesystem-fault seam must make canonical RCP publication fail after the underlying analytical/refusal outcome has been established. Acceptance must prove the W002-RCP-010 boundary exactly: no final RCP is fabricated or claimed, any retained candidate evidence follows the governed SCR retention/non-authority rules in W002-STOR-023.1, no RCV artifact is emitted, the user-facing diagnostic distinguishes analytical outcome from Receipt-persistence failure, and already committed analytical artifacts are not retroactively falsified solely because RCP persistence failed. F-23 ultimate identity-allocation failure fixture: with Receipt publication itself still available, a controlled identity-allocation seam must force a governed operation artifact to exhaust/fail safe allocation. The operation must refuse without overwriting or mutating any colliding pre-existing artifact, and the refusal Receipt/diagnostic evidence must preserve the established collision/allocation-failure facts under PB-STOR-011 and W002-STOR-007.3. Day 060 H-02 fixture binding: the retained golden corpus must use RECEIPT_VERSION: 1 and the fixture-pinned diagnostic allocations in W002-HELP-001.8. The corpus must contain one success Receipt for each of the seven executable operations, one refusal Receipt for every distinct refusal-boundary row in W002-RCP-007/W002-RCP-008, the three additional Stage-1 compatibility variants needed to cover COMPATIBLE , INCOMPATIBLE , and NOT_AVAILABLE after UTF-8 failure, and one UNKNOWN_OPERATION Receipt. Publication-refusal fixtures may use the operation-specific H-02 publication diagnostic and a non-zero IDENTITY_COLLISION_RETRIES value to satisfy the ultimate identity-allocation-failure acceptance boundary without inventing a second diagnostic solely for the same serialization row. Day 060 H-09 refusal-timeline acceptance Every retained refusal Receipt fixture must also satisfy the W002-RCP-006 temporal invariant. For a refusal with no successfully published non-Receipt artifact, acceptance proves WKO_UTC ≤ RUN_STARTED_UTC ≤ RUN_FINISHED_UTC ≤ RECEIPT_UTC . If a refusal legitimately leaves one or more successfully committed non-Receipt artifacts from an already-completed stage, each such artifact UTC must fall between Run start and Run finish and must be listed truthfully under the governing created-artifact rules. Day 060 H-11 / BM-08 RID_ACTION refusal acceptance Byte-exact MATERIALIZE refusal acceptance must distinguish new-Store and existing-Store RID paths: new-Store validation, Stage 1, Stage 2, and post-Stage-2 gate refusals before successful RID promotion serialize RID_ACTION: NOT_RUN and do not serialize a candidate as a published RID; a controlled new-Store refusal after RID promotion has successfully completed may serialize RID_ACTION: CREATED together with the exact published RID filename, but only if that RID was actually promoted and the remaining refusal/rollback evidence is truthful under the publication rules; an existing-Store refusal after the inherited RID has been selected and validated serializes RID_ACTION: REUSED and the exact inherited RID filename even when Stage 1, Stage 2, a later gate, or publication subsequently refuses; an existing lineage whose required inherited RID cannot be validly established serializes RID_ACTION: NOT_AVAILABLE and RID_FILENAME: NOT_AVAILABLE rather than claiming reuse. Acceptance must specifically reject the historical H-02 fixture pattern that reported RID_ACTION: CREATED while no RID existed and CREATED_ARTIFACT_COUNT: 0 . Day 060 H-12 H-02 publication-diagnostic scope The H-02 operation-specific publication diagnostics whose required facts are artifact_class and collision_retry_count are acceptance pins for governed filename identity-allocation collision exhaustion. They are not catch-all Diagnostic IDs for unrelated publication failures such as chronology guards, write/close/rename failures, or malformed predecessor state. Those distinct conditions use their own registry allocations; DS-UTC-001 is independently frozen for the strict monotonic-UTC guard. Day 060 H-13 / BM-10 zero-byte and BOM-only NO_HEADER_RECORD Receipt fixtures The retained golden corpus must contain two distinct byte-exact MATERIALIZE refusal Receipts for the P3-09 no-header boundary: Zero-byte source: the bound source has exact certified byte count 0 ; Stage 1 passes; Stage 2 refuses with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD ; CSV_SOURCE_BYTE_OFFSET: 0 ; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; and CSV_FIELD_ORDINAL: 1 . UTF-8-BOM-only source: the bound source consists exactly of bytes EF BB BF and has exact certified byte count 3 ; Stage 1 passes; Stage 2 refuses with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD ; CSV_SOURCE_BYTE_OFFSET: 3 ; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; and CSV_FIELD_ORDINAL: 1 . These two Receipt fixtures must carry their own truthful source filenames, Work Order identities, run timestamps, Receipt identities, and other governed facts. Only the five-field CSV refusal tuple has the narrower relationship stated in W002-RCP-007; the complete Receipt files are not otherwise required to be byte-identical. Day 060 H-14 / BM-11 CONVERT undefined-byte Receipt binding The coordinated golden Receipt corpus must include the byte-exact CONVERT_WINDOWS_1252_TO_UTF_8 refusal fixture from W002-CONV-ACC-002 using source bytes 41 81 42 . Its Receipt must carry UNDEFINED_WINDOWS_1252_BYTE_OFFSET: 1 and the exact pre-transcoding refusal values frozen in W002-RCP-008.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-003,Receipt TXT is invariant to presentation state in WASM-002,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,The same governed run must be exercised under materially different permitted browser presentation states. In each case the run Receipt must remain an RCP TXT artifact governed by the same receipt serialization and facts. Presentation must not convert it to HTML or alter execution truth in WASM-002. This acceptance gate does not require a configurable Brand Manifest; that capability is deferred.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-001,A Suitcase may contain multiple Stores and each current Store state binds exactly one RID,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The Suitcase is a workspace and may contain zero, one, or multiple logical Stores. Every committed Store state binds exactly one governed current RID artifact. RID values are unique only within their Store row universe; they are not Suitcase-global identifiers. Ordinary same-row-universe work reuses that RID unchanged. In WASM-002, a missing, unreadable, or invalid current RID makes the Store INVALID ; no executable WASM-002 operation regenerates or substitutes that RID. Read-only Help/evidence may explain analyst-owned restoration or lineage-retirement choices, but Data Sculptor does not publish a replacement RID. The stable logical row reference in WASM-002 is conceptually (Store lineage, RID value) ; the current physical RID identity is the exact rid_filename bound by the authoritative MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-002,The Store RID is generated automatically once and reused unchanged in WASM-002,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"When the first successful materialization establishes a new Store, Data Sculptor must automatically generate that Store's initial RID artifact as part of the same Stage 2 operation and the same all-or-refuse publication boundary. The analyst does not separately request ordinary RID generation. Before the RID SCR candidate is created, Data Sculptor establishes the materialization publication-transaction UTC under PB-STOR-013/PB-STOR-014 and allocates a RID-specific UUID. The canonical RID byte stream is then written as the visible governed SCR candidate whose filename already carries that exact UTC, UUID, and .csv extension intended for the final RID identity. Requested materialized columns likewise begin as governed SCR candidates whose distinct COL-specific UUIDs are allocated before those candidates are opened under the same transaction UTC. The new RID candidate and all requested COL candidates must reach EOF, reconcile to the same accepted Store row count N, and pass their required final validation before any candidate is promoted. After complete-set validation, Data Sculptor promotes the RID candidate first by host rename that changes only the three-letter semantic class token from SCR to RID . The candidate bytes, UTC token, UUID, and .csv extension must remain unchanged across that promotion. Requested COL candidates are promoted only after RID promotion succeeds. If later promotion or successor-MAP publication prevents transaction commit, the newly promoted RID is not committed Store state merely because an RID-looking file exists; it must be rolled back where safely possible or retained as attributable recovery evidence under the materialization failure contract. A first Store-establishing materialization commits exactly one RID regardless of how many requested COLs are materialized. Later ordinary materializations and other same-row-universe WASM-002 operations must reuse that RID unchanged. They must not create a new RID candidate, regenerate, replace, renumber, or silently supersede the inherited RID. RID reconstruction/replacement is not an executable WASM-002 operation. Any future governed RID-recovery design remains deferred and must be reintroduced by an explicit later PRD freeze.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-003,RID physical identity uses the governed RID filename grammar,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The physical RID filename must be: __DS__RID__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv The filename contains governed physical identity only. A Store name or friendly analyst alias must not be inserted into, substituted for, or used to rename this immutable physical RID filename.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-004,RID is a canonical one-column CSV containing the exact sequence 1 through N,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The RID artifact must serialize as a canonical one-column UTF-8 CSV with: exactly one UTF-8 BOM at byte zero; a structural first logical record exactly N=<value> , where <value> is the canonical unsigned base-10 representation of the Store's total logical data-row count N ; uppercase N , exactly one equals sign, no spaces, no sign, no leading zeroes except the single digit 0 , and no separators or locale formatting; LF ( 0x0A ) record terminators on every supported host; exactly N data records after the header, containing the consecutive unquoted decimal integers 1 through N in order; no zero RID data value, negatives, signs, thousands separators, decimal points, exponent notation, or leading zeroes; and a final LF after the last record. For N=0 , the canonical bytes are the UTF-8 BOM followed by N=0 and LF, with no data records. The N=<value> record is structural metadata and does not consume a Store row. The governed RID artifact class/filename and Store MAP binding identify the artifact as a RID; the literal header RID is not used by the frozen WASM-002 serialization.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-005,RID cardinality and order define same-Store column alignment,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"If a Store RID contains N data records, every governed column claimed to be aligned to that Store must contain exactly N data records in the same RID order. Data Sculptor must not describe a shorter, longer, reordered, duplicated, or row-shifted column as aligned to that Store. This invariant applies to materialized source columns in WASM-002 and is the stable contract that later calculated, Boolean-selection, verification, or left-join enrichment columns may rely upon.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-006,A different row universe requires a different Store and a new RID,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,An operation that changes which rows exist or changes their governed order does not mutate the existing Store RID. It establishes a different row universe and therefore requires a new logical Store identity and a new RID artifact beginning again at 1 for that new Store. Filtering that is represented only as a same-length aligned Boolean/selection column does not itself change the row universe; building a new reduced/reordered row set later would.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-007,The Store MAP gives RID a friendly alias without changing RID identity,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The physical RID artifact remains identified by its immutable governed filename and semantic RID class. Every valid Store MAP records that exact rid_filename and one current human-facing rid_alias . Changing the RID alias must not rename, rewrite, regenerate, or alter the meaning of the RID artifact. The same Store MAP also records the Store alias and materialized-column aliases, so the analyst-facing names and the physical Store spine remain explicitly connected in one visible governed artifact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-008,Ordinary RID generation is implicit Store infrastructure; RID reconstruction is deferred,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"WASM-002 materialization Work Orders specify the analyst's requested source columns and aliases. They must not require or expose a separate instruction such as RID , ROW INDEX , GENERATE RID , or an equivalent switch to create the Store row spine. Initial RID generation for a new Store is mandatory engine behavior implied by successful MATERIALIZE . WASM-002 must not provide an option to disable it. When ordinary materialization extends an existing Store, the engine must recognize and reuse that Store's existing RID. If that bound RID is missing or invalid, the Store is INVALID and ordinary Store operations refuse. WASM-002 exposes no RECOVER RID executable syntax. A future explicit recovery design may be considered in V1-BACKLOG, but it is not part of this build contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-001,Canonical RID byte serialization acceptance,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"An acceptance fixture with N=5 must prove exact governed bytes equivalent to a UTF-8 BOM followed by: N=5
1
2
3
4
5 Every record uses LF termination and the file ends with a final LF. A separate N=0 fixture must prove exact bytes equivalent to UTF-8 BOM + N=0 and no data records. The N=5 fixture repeated under different permitted source-window boundaries must produce byte-identical RID content apart from the governed physical filename allocated to the artifact. Full RID validation must also prove that the declared N , the number of following data records, and the exact sequence 1..N agree.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-002,Multiple Stores in one Suitcase retain independent RID spines,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,An acceptance fixture must establish at least two Stores with different row counts in the same Suitcase and prove that each Store publishes and retains exactly one distinct governed RID artifact. RID values may overlap numerically across Stores without collision because the Store identity disambiguates them.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-003,Later same-Store materialization reuses rather than regenerates RID,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"An acceptance fixture must establish a Store with an initial materialization, record the physical RID identity and exact RID bytes, then perform a later permitted materialization that adds at least one aligned COL without changing the row universe. The later run must reference and reuse the original RID artifact; no replacement RID may be published and the original RID bytes must remain unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-004,Implicit RID generation acceptance for single- and multi-column first materialization,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"Acceptance must execute two Store-establishing Work Orders that contain no RID or row-index syntax: one requesting exactly one source column and one requesting multiple source columns. Each successfully committed run must publish exactly one governed RID artifact regardless of the number of requested COL artifacts. The fixture must prove that RID creation occurs during the same Stage 2 source-record traversal that establishes the Store row count rather than by requiring a second source pass solely to construct RID. The RID row count must reconcile exactly with every requested COL row count and the final accepted Store N. Before RID candidate creation, acceptance must prove that the publication-transaction UTC and RID-specific UUID are already established, and that the governed SCR filename carries exactly the UTC, UUID, and .csv extension intended for the final RID identity. Before complete-set validation, the RID bytes must exist only as that governed SCR candidate. Acceptance must prove that the RID candidate is promoted by host rename only after the complete RID/COL candidate set validates, that the physical-name change is exactly the class token SCR to RID , that candidate bytes/UTC/UUID/extension are unchanged across promotion, that RID promotion precedes COL promotion, and that the resulting RID is not considered committed Store membership until the successor MAP is successfully promoted and binds that exact RID filename.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-001,INVENTORY is an explicit standalone WASM-002 Work Order operation,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 form is: SUITCASE: .
WORK ORDER AS ""Inventory this Suitcase""
INVENTORY INVENTORY reads the authorized Suitcase directory metadata and creates one governed Suitcase Inventory Snapshot. It is read-only with respect to pre-existing Suitcase files. In WASM-002, an INVENTORY Work Order must not also request materialization, conversion, fingerprinting, another analytical operation, or another Work Order invocation. F-08 structure freeze: after the common SUITCASE: . / WORK ORDER AS ""..."" preamble, INVENTORY is the sole semantic operation clause and is terminal. No SOURCE , MAP , KEEP , alias mutation, conversion, repair, catalog, or composition clause is valid in the same WKO.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-002,Suitcase Inventory uses the governed INV artifact class and canonical filename grammar,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"A successful inventory produces exactly one visible flat TXT artifact whose physical filename is: __DS__INV__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt The UTC and UUID tokens follow the existing governed artifact-identity rules. Data Sculptor must not create an inventory subfolder, hidden cache copy, or alternate private persistence. F-14 publication: the INV body is produced first under the matching W002-STOR-023.1 SCR identity with the same UTC, UUID and .txt extension intended for the final INV. Publication to INV occurs only after the complete scan and deterministic INV serialization validate successfully.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-003,"The lightweight inventory records filename, exact byte length, and last-modified metadata",W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"For every regular file present in the authorized flat Suitcase root at snapshot time, the inventory must record: the exact visible filename; the exact byte length reported by the host file object; and the host/browser-reported last-modified value rendered in the canonical UTC millisecond form when available. WASM-002 must not claim access to a true file-creation timestamp. It must not infer, fabricate, or substitute a creation time from the last-modified value. If usable last-modified metadata is unavailable, the inventory must represent that fact explicitly rather than invent a timestamp. P3-10 last-modified availability test: host/browser last-modified metadata is usable only when the host supplies a finite, non-negative whole-number millisecond value that can be represented in the canonical UTC millisecond timestamp form. If that test fails, the inventory must serialize the governed unavailable value rather than infer, round, substitute, or fabricate a timestamp.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-004,INVENTORY does not read file contents or compute content hashes,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The lightweight inventory must be produced from directory enumeration and file metadata only. Data Sculptor must not open and stream the contents of each listed file merely to create the inventory, and it must not compute SHA-256 or another content fingerprint as an implicit side effect. Its cost should therefore scale primarily with the number of directory entries and metadata calls, not with the aggregate byte size of the files. A 7 GB CSV and a 7 KB CSV each contribute one metadata entry rather than requiring their contents to be read.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-005,Inventory scope is the authorized flat Suitcase root,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"WASM-002 inventories regular files and immediate child directory entries in the directory denoted by SUITCASE: . . Data Sculptor must not recursively inspect, enumerate, size, hash, or otherwise inventory the contents of a child directory in this build. Each immediate child directory is recorded as a directory entry by its exact visible name only. Its nested contents and aggregate size are outside the WASM-002 Inventory contract. This rule preserves the flat-Suitcase storage model while making the presence of user-created directories explicit rather than silently omitting them. F-26 SOURCE distinction: inclusion in an Inventory is evidence that an entry was physically visible to the Inventory operation; it does not make that entry eligible for a Work Order SOURCE . SOURCE eligibility is the narrower contract in W002-WKO-009.1.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-006,Inventory serialization is deterministic UTF-8 TXT,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The INV artifact is a deterministic human-readable TXT document encoded as UTF-8 without BOM, using LF ( 0x0A ) line endings, the same KEY: VALUE line grammar, and the same quoted-text escaping rule frozen by W002-RCP-005. Every INV ends with exactly one final LF, contains no trailing spaces, and contains no blank physical lines. The exact V1 Inventory serialization order is: INVENTORY_VERSION INVENTORY_UTC WORK_ORDER_FILENAME SUITCASE ENTRY_COUNT for each regular-file entry in deterministic ascending exact-filename UTF-8 byte order, one contiguous indexed triplet: FILE_<INDEX> , FILE_<INDEX>_BYTE_LENGTH , FILE_<INDEX>_LAST_MODIFIED_UTC DIRECTORY_COUNT exactly DIRECTORY_COUNT directory-name records using contiguous indexed keys DIRECTORY_<INDEX> , ordered by ascending exact-directory-name UTF-8 bytes. INVENTORY_VERSION is the unquoted integer 1 for this contract. WORK_ORDER_FILENAME , SUITCASE , each FILE_<INDEX> filename, and each DIRECTORY_<INDEX> name use the common double-quoted UTF-8 text serialization. FILE_<INDEX>_BYTE_LENGTH is the exact non-negative ungrouped ASCII base-10 byte length. FILE_<INDEX>_LAST_MODIFIED_UTC is either the exact canonical UTC millisecond token governed by W002-INV-003 or the unquoted governed absence token NOT_AVAILABLE . Indexed suffixes are one-based decimal with a minimum width of three digits and no maximum width: 001 through 999 are zero-padded and 1000 onward uses the full ungrouped decimal form. When ENTRY_COUNT or DIRECTORY_COUNT is zero, no indexed lines for that list appear. ENTRY_COUNT remains the regular-file count. Directory records contain the exact immediate child directory name only and do not imply recursive inspection or a computed directory size. Filename and directory-name representations remain unambiguous even when a name contains whitespace, quotes, or delimiter-like characters because the common quote-doubling rule applies. P3-10 inventory timestamp binding: INVENTORY_UTC must equal the exact canonical UTC token embedded in the final governed __DS__INV__<UTC>__<uuid-v4>.txt filename, just as RECEIPT_UTC is bound to the governed Receipt filename UTC. The INV body and filename therefore cannot claim different capture times.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-007,The current inventory describes the pre-publication Suitcase state and excludes itself,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,Data Sculptor must enumerate and fix the inventory snapshot before publishing the new INV artifact. The INV artifact being created is therefore not one of its own listed entries. Any older INV artifact that already existed at snapshot time is an ordinary Suitcase file and is included like any other file. This pre-publication rule prevents recursive self-reference while preserving an accurate snapshot of the state that existed immediately before the new inventory evidence was added.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-008,"Help describes INVENTORY as a quick continuity aid, not byte-level proof",W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"Help must explain that an INV snapshot is useful for ordinary closeout and later orientation: it can reveal additions, removals, renames, size changes, or last-modified changes when snapshots or current metadata are compared. For an unexpected cross-session source problem, Help may direct the analyst to the relevant source entry in an earlier INV and ask whether its filename, exact byte length, or last-modified metadata differs. Help must also state that unchanged filename/size/last-modified metadata does not prove that file contents or row order are identical. When stronger assurance is warranted because files may change unexpectedly, Help may recommend the explicit later/deeper content-fingerprinting workflow; INVENTORY itself must never imply forensic or cryptographic assurance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-001,Large-file inventory acceptance proves metadata-only behavior,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"An acceptance fixture must place at least one multi-gigabyte file plus several small files in the authorized Suitcase, execute INVENTORY , and prove that the resulting INV records the correct filename, exact byte length, and last-modified metadata without reading the multi-gigabyte file contents. Evidence must demonstrate that inventory runtime and memory do not scale with the aggregate bytes of the listed files in the way a fingerprinting pass would. P3-10 metadata determinism: acceptance must include at least one file with usable host last-modified metadata and one test double/fixture in which the last-modified value fails the governed availability test. The first must serialize the exact canonical UTC millisecond value; the second must serialize exactly NOT_AVAILABLE . The accepted INV must also prove that INVENTORY_UTC exactly matches the UTC token in its final INV filename. Day 060 H-01 byte oracle: acceptance must include at least one byte-exact INV golden fixture using the complete W002-INV-006 key order, indexed suffix rule, quoted-text escaping rule, UTF-8/no-BOM physical form, LF-only line endings, and exactly one final LF. It must include at least two file records so deterministic filename ordering is observable, including one NOT_AVAILABLE last-modified value, and at least one directory record. Day 060 H-09 reachable-Suitcase INV golden fixture The byte-exact INV golden fixture used for WASM-002 review must depict a Suitcase state that could actually execute INVENTORY under the current contract rather than an isolated impossible file list. At minimum, immediately before the Inventory Run begins, the fixture Suitcase contains: one valid current Suitcase Validation Certificate ( CER ) authorizing the root; one structurally valid current WKO registry MAP; the exact saved immutable INVENTORY WKO referenced by WORK_ORDER_FILENAME , registered as runnable by that current WKO MAP; and the ordinary analyst files used to demonstrate inventory metadata, including the controlled last-modified-available and NOT_AVAILABLE cases. The INV snapshot is taken before publication of the new INV artifact and before its Receipt publication. Therefore the INV being created and the Receipt for that Run do not appear as pre-existing entries in their own inventory snapshot. For the retained minimal review fixture, the regular-file ENTRY_COUNT and indexed records must include the CER, current WKO MAP, exact INVENTORY WKO, and the two ordinary sample files, for a total of five regular-file rows, serialized in ascending exact-filename UTF-8 byte order. A later implementation fixture may use different exact governed filenames/UUIDs while preserving the same reachable-state requirement and deterministic ordering.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-002,Inventory snapshot membership and self-exclusion acceptance,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"An acceptance fixture must include ordinary analyst files, existing governed __DS__ artifacts, and at least one older INV artifact. The new inventory must include every qualifying pre-existing root file in deterministic order, include the older INV, and exclude only the newly generated INV because it did not exist in the fixed pre-publication snapshot. Adding an unrelated PDF or ZIP before a later inventory must appear as an added inventory entry and must not be treated as an analytical error.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-003,Inventory does not overclaim unchanged contents,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"Acceptance documentation and Help fixtures must demonstrate the limitation of metadata-only continuity. A case in which a file's bytes are changed while the observed filename, byte length, and last-modified metadata are preserved or restored must not be described as detectable by INVENTORY alone. The product must direct the analyst toward stronger explicit fingerprint evidence when byte-level assurance is required.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-016,Work Order filenames use the governed immutable identity grammar,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When Data Sculptor saves a new Work Order as a WKO, it shall assign the physical TXT filename. The analyst chooses the validated Suitcase but is not asked to choose or edit the WKO filename. The exact WKO filename shape is __DS__WKO__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt , using UTC at millisecond precision with exactly three millisecond digits and a canonical lowercase hyphenated UUID v4. UTC precedes UUID. If the generated name collides with an existing artifact, PB-STOR-011 governs UUID regeneration and safe retry. The saved WKO thereafter retains that physical identity and remains immutable under W002-STOR-017.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-017,Saved Work Orders are immutable artifacts,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"After a Work Order TXT artifact is saved, Data Sculptor shall not edit, overwrite, or rename that saved Work Order in place. Changing analytical instructions requires saving a new Work Order artifact with a new governed physical identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018,Work Order alias is immutable WKO content and governed MAP metadata,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A human-facing Work Order name is required immutable Work Order content for every executable/saved WASM-002 WKO, not separately editable browser metadata. The canonical declaration is WORK ORDER AS ""<alias>"" under W002-STEPS-001.1. The quoted alias must be non-empty UTF-8 text and may contain spaces and ordinary phrase punctuation subject to the governed string-literal rules. After the WKO TXT artifact is saved, Data Sculptor shall not edit the alias in place. Changing the alias, analytical instructions, or comments means creating and saving a new immutable WKO with a new governed physical identity. The physical WKO filename/UUID remains execution identity; the alias is human-facing metadata for display and governed name resolution. The browser must not maintain a separate mutable Description field or hidden description store. The alias declared by the WKO is also represented in the current governed WKO MAP under W002-STOR-018.1 through W002-STOR-018.4.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.1,The existing MAP class includes a distinct WKO alias-registry profile,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Revision BB does not add a new semantic artifact class. The existing MAP class has two explicitly distinguished governed profiles: Store MAP — the existing exact eight-column Store/RID/COL snapshot governed by W002-STOR-019 through W002-STOR-019.12; WKO MAP — a complete immutable snapshot that maps saved Work Order aliases and lifecycle status to exact immutable WKO filenames. Profile classification is determined by the exact CSV header before profile-specific validation. A valid WKO MAP must never be treated as an eligible Store MAP, and a Store MAP must never be treated as a WKO alias registry. Both remain visible flat-Suitcase MAP artifacts under the canonical immutable filename grammar.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.2,WKO MAP schema and serialization are exact and deterministic,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical WKO MAP is UTF-8 CSV without BOM, using LF record termination, with exactly this three-field header: wko_status,wko_alias,wko_filename Each row identifies one immutable governed WKO represented in that registry snapshot. wko_status is exactly CURRENT or DEPRECATED . wko_alias is the exact mandatory non-empty alias declared by that WKO's WORK ORDER AS clause. wko_filename is the exact governed physical WKO filename. Rows are written deterministically by ascending exact UTF-8 byte order of wko_filename . Duplicate wko_filename rows are invalid. Standard governed CSV quoting applies. For any exact wko_alias value, at most one row may have wko_status=CURRENT ; zero or more older rows for that same alias may have wko_status=DEPRECATED . Alias resolution uses the CURRENT row only. A WKO represented by a DEPRECATED row remains immutable historical evidence and is not renamed, rewritten, or deleted merely because its alias target was superseded. A WKO MAP containing more than one CURRENT row for the same exact alias is structurally invalid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.3,Saving a WKO and publishing its WKO MAP binding is one governed save transaction,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Saving a new immutable WKO begins from the current structurally valid WKO MAP in the Suitcase, or an empty WKO registry if no structurally valid WKO MAP exists. Data Sculptor validates the draft, including its mandatory non-empty WORK ORDER AS alias and comment syntax, and checks the governed alias/lifecycle constraints before commit. F-02 alias-lifecycle decision: if no CURRENT row in the predecessor WKO MAP uses the new WKO's exact alias, the successor registry adds the new WKO as CURRENT . If exactly one CURRENT row already owns that exact alias, Data Sculptor must present exactly two analyst choices before registry commit: Replace alias target or Cancel . Replace alias target constructs the successor WKO MAP by changing the former owner's row to DEPRECATED and adding the newly saved WKO as the sole CURRENT row for that alias; any older DEPRECATED rows remain unchanged. Cancel leaves the predecessor WKO MAP authoritative and does not commit the pending WKO/WKO-MAP pair as a registry update. Data Sculptor must not silently replace the alias target, auto-suffix the alias, or choose between competing owners. A predecessor WKO MAP with more than one CURRENT row for the same alias is structurally invalid under W002-STOR-018.2 and cannot be used as save authority. The former CURRENT WKO and every prior WKO MAP remain byte-for-byte immutable after replacement. Supersession changes only the lifecycle metadata represented in the newly published successor WKO MAP; it does not edit, rename, delete, or rewrite the historical WKO artifact. F-14 WKO publication predicate: the new immutable Work Order is first written under the W002-STOR-023.1 SCR identity using the UTC, UUID and .txt extension intended for its final WKO identity. The complete candidate is closed, reopened and validated as a saved WKO: required common preamble, exactly one non-whitespace WORK ORDER AS alias, governed lexical/comment rules, and complete parse under exactly one current WASM-002 executable operation grammar. Only then may the candidate be renamed from SCR to WKO . Save-time current-registry, alias-lifecycle and lifecycle gates remain transaction preconditions. A valid promoted WKO is not yet alias-registry authority; the successor WKO MAP promotion remains the save-transaction commit point. The WKO is persisted as a new immutable governed WKO artifact and the complete successor WKO MAP is constructed under SCR , closed, reopened, and validated for WKO MAP structural validity : exact profile/schema, exact governed serialization, filename/profile rules, lifecycle-row constraints, and internal row constraints. Whether every referenced physical WKO file is presently visible is a separate registry-health/publication check and is not part of WKO MAP structural validity. For an ordinary successful save transaction, every WKO referenced by the successor registry must be present at publication. The successor WKO MAP is promoted to MAP last; that successful MAP promotion is the alias-registry commit point for the save transaction. The WKO and successor WKO MAP created by one successful save transaction use one shared canonical transaction UTC while retaining distinct UUIDs. If successor WKO-MAP structural validation, referenced-file publication checking, or publication itself fails, the save must not be represented as a successfully committed alias-registry update. Data Sculptor must roll back the new WKO out of committed WKO state where safely possible or retain visible non-authoritative SCR failure evidence and report the failure through Help. F-02 repair-only bootstrap and stale-registry Save boundary When the current WKO registry is repair-required under W002-STOR-018.4, Data Sculptor may save one ordinary visible immutable WKO whose sole semantic operation is exactly REPAIR WORK ORDER REGISTRY . That saved repair-only WKO may Run by its exact physical WKO filename even though it is not yet represented in the current WKO MAP. The WKO must be structurally valid under the predicate below, must contain exactly one mandatory non-empty WORK ORDER AS , and must contain exactly the governed registry-repair operation and no second operation. The exception does not grant alias-based Run authority. The repair WKO is invoked only by exact physical WKO filename. No other visible but unregistered WKO gains Run eligibility from this exception. The exception ends once registry repair successfully publishes the successor WKO MAP. This is the sole WASM-002 bypass of ordinary current-registry membership for Run eligibility. Because the registry is already stale, Save of the repair-only WKO does not claim that the WKO has been registered, does not commit an ordinary successor WKO MAP, and does not represent the stale registry as healthy. The new immutable WKO remains visibly unregistered until the repair operation successfully publishes the successor WKO MAP containing its row. Save does not silently perform registry repair. F-02 governed WKO structural-validity predicate A visible WKO is structurally valid for registry purposes only when all of the following hold: it is a regular root-level Suitcase file; its physical filename conforms exactly to the governed WKO filename grammar; its bytes are valid UTF-8; LF and CRLF physical line endings are accepted; a lone CR line ending refuses; its content parses completely under exactly one defined WASM-002 executable Work Order grammar; it contains exactly one mandatory non-empty WORK ORDER AS clause; its required common and operation-specific structural clauses are present in their governed order/cardinality; and unknown syntax or prohibited operation mixing causes invalidity/refusal. Structural validity is not runtime success. A structurally valid WKO remains a valid governed artifact even when a runtime precondition is currently false, such as a referenced source file being absent. Runtime preconditions are checked at Run. P3-10 repair-bootstrap timing: during REPAIR WORK ORDER REGISTRY , the saved repair-only WKO participates in the bounded discovery performed by that repair run. It is not first “discovered after success.” Its governed registration becomes durable only when the complete successor WKO MAP containing that WKO row is successfully committed. Discovery during the run and registration in the committed successor registry are distinct events. P2-03 WKO-registry chronology guard: before a save or registry-repair transaction publishes a successor WKO MAP, Data Sculptor establishes the truthful observed transaction UTC and compares it with the chronology predecessor defined by W002-STOR-018.4. The observed UTC must be strictly greater. Equal or earlier UTC refuses before the new WKO/WKO-MAP pair is committed; Data Sculptor must not fabricate a later timestamp, silently wait/retry, skip the predecessor, or select an older registry merely to make publication succeed. F-13 single-writer pre-commit guard: immediately before the successor WKO MAP promotion that would commit the alias-registry update, Data Sculptor re-resolves the current WKO-registry authority and compares the relevant governing state with the state from which this transaction was derived. If another writing context or external filesystem action has changed that relevant authority, the transaction refuses publication. It must not overwrite the newer registry, silently rebase the pending save, or choose an older registry to make the commit succeed. The existing rollback / attributable SCR recovery-evidence rules apply to any WKO or candidate bytes already produced. If the save later refuses and an SCR candidate or other attributable staged evidence cannot be safely removed/restored, W002-STOR-023.1 governs retained SCR evidence and its non-authority boundary; WASM-002 does not emit RCV. An unregistered final WKO left by a failure is a valid immutable WKO artifact but does not become current registry authority merely by existing; the WKO MAP remains authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.4,Current WKO MAP selection is based on structural validity; missing referenced WKOs make the registry repair-required,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"WKO MAP structural validity is distinct from registry health. A WKO MAP is structurally valid when the MAP artifact itself satisfies the governed WKO MAP profile/schema, serialization, filename/profile rules, lifecycle-row constraints, and internal row constraints. The present existence of every physical WKO file named by its rows is not part of WKO MAP structural validity. Only structurally valid WKO MAP artifacts participate in current-registry selection. Among structurally valid WKO MAPs, the one with the greatest canonical UTC millisecond timestamp is the current WKO MAP snapshot and therefore the current governed Work Order alias registry. If two or more structurally valid WKO MAPs share that greatest timestamp, current-registry selection must refuse rather than break the tie by UUID, discovery order, filesystem modified time, or directory order. Registry-snapshot authority is distinct from alias-target status inside that snapshot. After the current WKO MAP snapshot is selected, an alias resolves only to its exact row whose wko_status is CURRENT . Rows marked DEPRECATED remain visible historical registry evidence but are not alias-resolution targets. The registry must never use the greatest WKO filename UTC, filesystem modified time, or discovery order to choose between rows for an alias. More than one CURRENT row for the same exact alias makes that WKO MAP structurally invalid under W002-STOR-018.2. If a newer WKO MAP artifact is structurally malformed, it never becomes current. Data Sculptor uses the greatest earlier structurally valid WKO MAP, if one exists, and reports the malformed newer artifact through Help/evidence surfaces. A malformed newer WKO MAP does not itself make the selected earlier registry repair-required. The current WKO registry is repair-required exactly when the current structurally valid WKO MAP contains one or more rows whose referenced physical WKO files are missing from the Suitcase. Such a MAP remains current ; Data Sculptor must not silently fall back to an older WKO MAP merely because a referenced WKO is missing. This preserves the latest registry authority while making the damage explicit and reachable through the governed REPAIR WORK ORDER REGISTRY path. F-02 deterministic registry reconciliation REPAIR WORK ORDER REGISTRY reconciles the current WKO MAP against visible WKO artifacts in the Suitcase and constructs one complete successor WKO MAP deterministically: Remove every row from the successor whose referenced physical WKO file is missing. A missing WKO is never reconstructed, inferred, copied from history, or replaced automatically by a deprecated WKO. Discover visible structurally valid WKOs that are absent from the current WKO MAP. If no surviving CURRENT row owns a discovered WKO's exact alias, register that discovered WKO as CURRENT . If a surviving CURRENT row already owns that exact alias, register the discovered WKO as DEPRECATED ; existing current authority is not silently displaced. If two or more previously unregistered structurally valid WKOs share the same alias and no surviving CURRENT owner exists, register all of those discovered WKOs as DEPRECATED . Data Sculptor must not choose a winner by UTC, filename, UUID, directory order, discovery order, or filesystem modified time. The repair WKO itself participates in the same discovery and registration process during the repair run. Its registration becomes durable only when the complete successor WKO MAP is committed. Predecessor WKO MAPs and surviving WKO files remain immutable historical evidence. Successor rows remain serialized in ascending exact UTF-8 byte order of wko_filename under W002-STOR-018.2. Day 060 H-10 / BM-07 registry-repair change-set counts The registry-repair operation distinguishes the successor registry state from the change set produced by this repair Run . The Receipt's REGISTERED_CURRENT_* and REGISTERED_DEPRECATED_* fields describe only the latter. REGISTERED_CURRENT_COUNT is the exact number of previously unregistered structurally valid WKO files newly added by this repair Run with wko_status=CURRENT . REGISTERED_CURRENT_WKO_<INDEX>_FILENAME lists exactly those newly registered CURRENT WKOs, ordered by ascending exact UTF-8 filename bytes. REGISTERED_DEPRECATED_COUNT is the exact number of previously unregistered structurally valid WKO files newly added by this repair Run with wko_status=DEPRECATED . REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME lists exactly those newly registered DEPRECATED WKOs, ordered by ascending exact UTF-8 filename bytes. Surviving rows that were already present in the base WKO MAP are not counted in either REGISTERED_* total, even though they appear in the successor WKO MAP. Rows removed because their referenced WKO is missing are represented only by REMOVED_STALE_ROW_COUNT and the corresponding stale-WKO filename list; they are not also reflected in either registered count. The bootstrap repair WKO participates exactly like any other newly discovered structurally valid unregistered WKO. If the repair commits it, that exact WKO must appear in one and only one of the two registered filename lists according to the ordinary alias-ownership rules. These counts therefore answer “what did this repair register?” rather than “how many CURRENT/DEPRECATED rows exist in the resulting registry?”. F-02 Run eligibility and alias authority Run by human-facing alias resolves only to the sole CURRENT WKO for that alias. A registered CURRENT WKO may Run by exact physical WKO filename, subject to ordinary runtime preconditions. A registered DEPRECATED WKO may also Run by exact physical WKO filename, subject to ordinary runtime preconditions, to support deliberate historical reproduction. An unregistered WKO may not Run merely because its file is visible, except for the single bounded repair-only bootstrap in W002-STOR-018.3. The browser may use the current structurally valid WKO MAP to show human-facing Work Order aliases together with read-only CURRENT / DEPRECATED lifecycle state while keeping exact physical WKO filenames visible/inspectable. Future Work Order composition may use the same registry to resolve a non-empty alias to exactly one immutable WKO artifact through its sole CURRENT row. This requirement does not pull deferred Work Order invocation/orchestration grammar into WASM-002; it establishes the governed alias-registry selection, lifecycle, and repair boundary that later composition can depend on. F-08 REPAIR WORK ORDER REGISTRY Work Order structure: SUITCASE: .
WORK ORDER AS ""Repair Work Order Registry""
REPAIR WORK ORDER REGISTRY After the common preamble, REPAIR WORK ORDER REGISTRY is the sole semantic operation clause and is terminal. It takes no analyst-supplied SOURCE , Store MAP , alias-mutation list, column selector, conversion source, or catalog clause. Its bounded unregistered-repair bootstrap remains governed by W002-STOR-018.3. The DS-STEPS phrase is distinct from the Receipt operation token REPAIR_WORK_ORDER_REGISTRY . P2-03 chronology predecessor: for any WKO-registry successor publication, the chronology predecessor is the unique current structurally valid WKO MAP immediately before that publication transaction. It is the MAP selected by the current-registry rule above, not an older registry used for inspection and not a filesystem-modified-time surrogate. If no structurally valid WKO MAP exists and the operation is legitimately establishing the first governed registry state, there is no predecessor UTC. Future-dated current WKO MAP: a structurally valid current WKO MAP whose governed UTC is later than truthful observed host UTC remains the current registry; the timestamp conflict does not by itself make the MAP malformed or repair-required. Successor WKO-MAP publication is blocked until the monotonic UTC precondition can be satisfied. Help must identify the exact blocking WKO MAP and explain the analyst-owned exits: correct an incorrect host clock; wait/rerun after truthful time advances beyond the predecessor; or, when the analyst deliberately determines that the active future-dated WKO MAP should no longer govern the Suitcase, move that exact MAP out of the active Suitcase root and reopen/rescan. That filesystem action is not a Data Sculptor repair operation. It may expose an older structurally valid WKO MAP as current, and restoring the moved future-dated MAP to the active Suitcase may make it current again under the ordinary greatest-UTC rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019,Store state is preserved as visible immutable MAP history,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each valid WASM-002 MAP is one complete immutable Store snapshot in the same flat Suitcase. Store state is not stored in hidden browser persistence and is not represented by a mutable well-known singleton. Each successful Store-establishing materialization or later governed Store-metadata/materialized-column update publishes a new immutable MAP under the canonical __DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv identity grammar. Earlier MAP artifacts remain visible history and are not overwritten or deleted merely because a newer Store state is created. Day 057 CAT reconciliation: the one-Store-per-MAP invariant is unchanged. A collection of independently MAP-governed Stores may additionally be summarized by a governed CAT Store Catalog for collection-level discovery and orientation. CAT does not govern Store semantics, lineage, health, repair, inheritance, or current-MAP selection. MAP remains authoritative for each Store.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.1,A Work Order may explicitly select at most one Store MAP,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each governed Work Order may explicitly identify at most one valid immutable Store MAP as its Store/inheritance base. If more than one MAP is explicitly specified, Data Sculptor must refuse before Store resolution, alias resolution, materialization, or mutation. An explicitly named valid MAP binds the run to exactly the Store identified by that MAP's rid_filename and overrides automatic Store-MAP discovery even when newer MAPs for that Store or other Stores exist.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.2,"Without an explicit MAP, materialization performs Store-aware MAP inheritance",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If a materializing Work Order does not explicitly identify a MAP, Data Sculptor must compare the exact Work Order SOURCE filename with the one common exact source_filename carried by every row of each routable Store lineage's structurally valid Store MAP. That common source_filename is the Store lineage's source identity for WASM-002 routing. The redundant ninth Store-source field from the superseded profile is not part of the canonical Store MAP. P3-07 routing term: for automatic source routing, a routable Store lineage is a Store lineage for which at least one structurally valid Store MAP exists, regardless of whether the lineage currently evaluates VALID , DEGRADED , or INVALID . Routing discovery must use this term rather than the ambiguous word eligible . Store health is evaluated only after the lineage has been discovered. If no routable Store lineage exists for the exact source filename, Data Sculptor may establish a new Store with a new RID and first Store MAP only if the active Suitcase contains no structurally malformed Store-MAP-class artifact . If exactly one routable Store lineage exists, Data Sculptor routes to that lineage. If its current state permits materialization, the current governed Store MAP is the inheritance base; if its current state is DEGRADED or INVALID , ordinary materialization refuses under the damaged-lineage rules below. If more than one distinct routable Store lineage exists for the same exact source filename, automatic inheritance must refuse rather than guess which Store the analyst intended. The analyst must explicitly select one permitted MAP. All-Store-MAPs-damaged guard: if exact- SOURCE routing finds no routable Store lineage but one or more structurally malformed Store-MAP-class artifacts are present in the active Suitcase, ordinary materialization must refuse before creating a new Store or RID. Data Sculptor must not infer that the absence of a structurally valid Store MAP proves that no prior Store lineage existed. Help must identify the malformed Store MAP artifact or artifacts that caused this guard. A damaged MAP therefore cannot silently turn Store damage into permission to create a replacement lineage. Store lineages are distinguished by their governed lineage identity. Current-MAP selection and Store-health evaluation are separate governed questions under this requirement and W002-STOR-019.10. If two or more structurally valid current MAP candidates for the one routed Store share the greatest canonical UTC millisecond timestamp, automatic inheritance must refuse rather than infer chronology from UUID, directory order, filesystem modified time, or discovery order. F-03 canonical evaluated Store-health states Store health is evaluated from the current structurally valid Store MAP and the presently visible governed artifacts it references, using the applicable validation tier in W002-STOR-019.10. WASM-002 has exactly three evaluated Store-health states: VALID — the current Store MAP is structurally valid; the referenced RID is valid; and every mapped non-RID COL is valid. DEGRADED — the current Store MAP is structurally valid; the referenced RID is valid; and one or more mapped non-RID COL artifacts are missing or invalid. INVALID — the current Store MAP is structurally valid, but its referenced RID is missing or invalid. There is no fourth ABANDONED Store-health status in WASM-002. F-03 status is evaluated, not persisted VALID , DEGRADED , and INVALID are evaluated states. WASM-002 does not write or maintain a mutable persisted Store-status flag. While a Store evaluates INVALID , Data Sculptor exposes no governed Store-recovery operation for that Store and never regenerates, substitutes, or infers a replacement RID. If the exact governed RID physical identity becomes visible again through analyst-owned external restoration and passes the validation tier required by the next operation, the Store is re-evaluated from the visible governed artifacts and may become VALID or DEGRADED . That is re-evaluation, not RID recovery by Data Sculptor. F-03 strict DEGRADED operation gate When a Store evaluates DEGRADED , REPAIR MAP is the only enabled Store mutation operation for that lineage . ordinary materialization into that Store refuses; extension with new columns refuses; alias mutation refuses; transformations and other Store mutations refuse; read-only Help, Inventory, status/orientation surfaces, CAT orientation, and evidence inspection remain available subject to their own contracts. F-03 no damaged-lineage fork If exact SOURCE routing identifies a lineage whose current Store evaluates DEGRADED , ordinary materialization refuses and directs the analyst to the governed REPAIR MAP path. If the routed Store evaluates INVALID , ordinary materialization refuses and WASM-002 provides no RID-recovery path. Neither condition permits Data Sculptor to treat the source as unseen or establish a replacement Store with a new RID for that routed lineage. Damaged-lineage routing: exact SOURCE routing must not treat a known damaged lineage as unseen merely because its current Store state cannot accept ordinary materialization. If routing identifies a DEGRADED or INVALID lineage, ordinary materialization refuses rather than silently creating a replacement Store for that same routed lineage. Help duty for an all-COLs-broken DEGRADED lineage: when the current structurally valid Store MAP references a valid RID but every mapped non-RID COL is missing or invalid, REPAIR MAP cannot publish a zero-COL successor and must refuse. Help must identify the exact blocked Store lineage and current MAP, then explain these analyst-owned exits: (1) externally restore at least one governed COL artifact under its original physical filename; Data Sculptor then applies the governed validation tier required by the next operation before the artifact can re-enter use, so Store health can be re-evaluated and REPAIR MAP may become available; (2) rename the analyst-owned source and materialize the renamed source to deliberately begin a new Store lineage with a new RID, without repairing, replacing, or erasing the damaged lineage; or (3) retire the damaged lineage from active Suitcase routing by moving all Store MAP artifacts belonging to that lineage out of the Suitcase root. Help must warn that moving only the latest MAP is insufficient because an older structurally valid MAP could otherwise become current. Help duty for an INVALID lineage: when the current structurally valid Store MAP references a missing or invalid RID, Help must identify the exact blocked Store lineage and current MAP, state that WASM-002 does not silently regenerate or substitute a RID as part of ordinary materialization, and explain these analyst-owned exits: (1) externally restore a governed RID artifact under its original physical filename; Data Sculptor then applies the governed validation tier required by the next operation before the artifact can re-enter use, so Store health can be re-evaluated; (2) rename the analyst-owned source and materialize the renamed source to deliberately begin a new Store lineage with a new RID while leaving the damaged lineage untouched; or (3) retire the damaged lineage from active Suitcase routing by moving all Store MAP artifacts belonging to that lineage out of the Suitcase root, again warning that moving only the latest MAP is insufficient. Renaming the source and retiring a lineage are distinct analyst choices. Renaming preserves the damaged lineage in the Suitcase and creates a separate lineage under a different source identity. Moving all lineage MAPs out removes that lineage from active routing while preserving the moved artifacts wherever the analyst chooses to keep them. These are analyst filesystem actions, not new Data Sculptor recovery operations. Assurance boundary: exact source-filename matching in this rule is a Store-routing/orientation mechanism, not proof that an analyst-owned source has identical bytes or row order across separate sessions. Ordinary WASM-002 materialization must not silently represent that filename equality as cryptographic continuity. P3-08 CVT source-identity boundary: a governed CVT is a new immutable source artifact whose Store-routing source identity is its exact physical CVT filename. Two different CVT filenames are different source identities even when both conversions began from analyst-owned files having the same original filename. WASM-002 does not carry the analyst-owned pre-conversion filename forward as hidden Store-lineage identity and does not infer continuity between separate CVT artifacts. First materialization of a CVT therefore establishes or routes only by that exact CVT filename under the normal rules above. P2-03 current Store-MAP chronology: within one routable Store lineage, the current structurally valid Store MAP is the unique structurally valid MAP carrying the greatest canonical UTC millisecond timestamp. If two or more structurally valid MAPs share that greatest timestamp, current authority is ambiguous and selection refuses rather than using UUID or discovery order. This current MAP is also the lineage's chronology predecessor for any new successor publication, even when the operation explicitly derives its requested new state from an older historical MAP. F-15 exact-source comparison and routing domain: the Work Order SOURCE value and each Store MAP's common source_filename are compared by exact Unicode scalar-value sequence under PB-STOR-010, with no case folding or Unicode normalization. Automatic routing compares only routable Store lineages whose structurally valid Store MAPs participate in that exact-source routing decision. Unrelated Suitcase files, non-Store artifact classes, filesystem enumeration order, and arrival order are outside the routing comparison domain and cannot create or remove a source match.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.3,"Any valid historical Store MAP may be selected explicitly with MAP ""<filename>""",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A governed Store-aware Work Order may explicitly identify any one structurally valid immutable Store MAP present in the Suitcase, including an older snapshot when newer MAPs for that Store also exist. The canonical clause is: MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv"" The quoted value must be the exact physical filename of one valid Store MAP. A WKO MAP profile, missing file, malformed MAP, or other MAP profile is invalid for this clause. Data Sculptor uses exactly the named Store MAP rather than silently substituting a later one. For materialization, SOURCE ""..."" remains required to identify the source file being read; the optional MAP ""..."" clause occurs immediately after SOURCE and before KEEP , overrides automatic Store-MAP inheritance, and supplies the exact Store-state base. The Work Order's exact SOURCE filename must match the selected lineage's governed source identity under the frozen source/Store compatibility rules or validation refuses. For an alias-only UPDATE ALIASES Work Order, MAP ""..."" may itself be the Store-state selector and no source-data read is required. Historical-MAP health gate. Explicit selection of a current or historical Store MAP never bypasses current Store-lineage health. The selected lineage must currently evaluate VALID , and every RID/COL binding referenced by the named MAP must currently be present and valid. If either condition fails, Data Sculptor refuses the operation. An older MAP cannot be used to hide present lineage damage. The same rule applies when UPDATE ALIASES uses a historical Store MAP as its base. Once selected, the exact MAP identity, Store RID binding, Store alias, RID alias, and materialized-column mapping state remain fixed for the governed run. The MAP filename is execution input, not a friendly alias. P2-03 base-versus-predecessor distinction: an explicitly selected historical MAP is the operation's base MAP —the Store snapshot from which requested new state is derived. It does not become the chronology predecessor merely because it was selected. If the operation publishes a new Store MAP, the chronology predecessor remains the Store lineage's current structurally valid MAP immediately before publication. The new transaction UTC must be strictly greater than that current MAP UTC. This preserves one chronological MAP history rather than creating a branch from the historical base. F-21 current-state consequence: merely selecting or validating a historical Store MAP does not change Store authority. If the governed run refuses or otherwise publishes no successor Store MAP, the lineage's pre-run current MAP remains current. If the run successfully publishes a successor derived from a historical base, that new MAP enters the same single chronological history and ordinary greatest-governed-UTC current-state selection applies. Because successor publication already requires a truthful transaction UTC strictly greater than the pre-publication chronology predecessor, the successfully published successor becomes current. The explicitly selected historical base and the formerly current MAP both remain immutable historical evidence. This behavior is deliberate state derivation, not a branch, rollback-in-place, overwrite, or mutation of prior MAPs. The operation base records which Store snapshot supplied the requested starting state ; chronology records when the new governed state was published . Those are distinct facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.4,"Store MAPs are complete snapshots, not delta logs",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each valid Store MAP represents one complete usable Store metadata and materialized-column mapping state for that version. It must not require replaying a chain of earlier MAP files merely to reconstruct the Store's current RID binding, aliases, or materialized-column mappings. A newer MAP created from an inherited older MAP contains the complete resulting Store snapshot after applying the governed Work Order's successful changes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.5,Materialization or governed Store metadata mutation emits one successor MAP,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When a governed Work Order materializes one or more columns or requests governed Store/RID/COL alias changes, Data Sculptor begins from the applicable governed Store-state base. Ordinary materialization uses the explicitly selected MAP or Store-aware automatic inheritance under W002-STOR-019.2. A new Store begins from newly established Store/RID metadata plus an empty materialized-column mapping set before requested materialization is applied. All successful updates in that Work Order are applied to one in-memory complete Store snapshot. The complete deterministic successor-MAP bytes must first be written under a governed SCR candidate identity, closed successfully, reopened, and fully validated while still an SCR candidate. Only a complete validated candidate may be promoted by host rename into one new immutable MAP artifact. The inherited MAP remains unchanged. The successful SCR -to- MAP rename is the Store-state commit point. A failed run must not create a valid successor MAP; a malformed, incomplete, or unpromoted MAP candidate remains visible non-authoritative SCR evidence rather than Store state. RID reconstruction/replacement is not a WASM-002 Store-mutation path. P2-03 successor publication precondition: before any final RID/COL/MAP promotion for a successor Store-state transaction, Data Sculptor identifies the lineage's chronology predecessor and establishes one truthful observed host transaction UTC. For an existing lineage, that UTC must be strictly greater than the current structurally valid Store MAP UTC, regardless of whether the Work Order's base MAP is current or historical. Equal or earlier observed UTC refuses publication; no artificial +1 ms , sleep-and-retry loop, UUID tie-break, older-predecessor fallback, or branch chronology is permitted. The chronology predecessor remains current and unchanged. Future-dated current Store MAP: a structurally valid current MAP with a governed UTC later than truthful observed host UTC is a clock-order conflict, not by itself Store corruption. It remains current and successor publication is blocked. Help must identify the exact blocking MAP and explain the analyst-owned exits: correct an incorrect host clock; wait/rerun after truthful time advances beyond the predecessor; or deliberately move that exact future-dated current Store MAP out of the active Suitcase root and reopen/rescan. Moving it is an analyst filesystem action, not a governed Data Sculptor mutation. An older structurally valid MAP may then become current; returning the future-dated MAP may restore its authority under the ordinary greatest-UTC rule. F-13 single-writer pre-commit guard: immediately before the final successor Store-MAP promotion, Data Sculptor re-resolves the relevant current Store authority and exact-source routing state on which the transaction depended. For an existing lineage, the current chronology predecessor must still be the authority against which the transaction was prepared; for a new-Store transaction, no newly established routable lineage may have appeared that changes the routing decision. If relevant governed state changed while the transaction was in flight, publication refuses. Data Sculptor must not overwrite the newer authority, silently rebase onto it, create a competing branch, or report success. Any RID/COL/candidate artifacts already produced are handled by the existing rollback / attributable recovery-evidence rules and do not become committed Store membership without the final valid MAP binding. F-21 historical-base publication rule: when the applicable Store-state base is a valid historical MAP rather than the pre-run current MAP, the complete successor snapshot is still derived from that explicitly selected base plus the current Work Order's requested changes. Publication does not silently merge later state from the formerly current MAP back into the successor. Therefore mappings or aliases introduced only after the selected historical base may be absent from the new successor when the requested operation does not recreate them. That is the deliberate consequence of using the historical base, not data loss caused by an implicit merge. The pre-run current MAP remains the chronology predecessor solely for monotonic publication ordering and stale-authority protection. Successful publication leaves both the historical base and the formerly current MAP byte-for-byte unchanged, publishes one new immutable successor MAP in the same lineage, and makes that successor current under the ordinary chronology rule. No branch identifier, hidden branch state, overwrite, in-place rollback, or automatic rebase is created.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.6,Store MAP CSV schema is exactly eight columns,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 Store MAP is a CSV whose header row is exactly: store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename Each data row describes one current logical materialized-column mapping: store_alias — current human-facing Store name; rid_filename — exact immutable governed RID artifact filename that physically anchors this Store lineage; rid_alias — current human-facing RID name; source_filename — exact visible source filename common to every row in this one-Store MAP and therefore the Store source identity; source_column_number — 1-based source-column ordinal; source_header — exact decoded CSV header value after governed parsing; alias — current human-facing COL name; and column_filename — exact physical governed COL artifact filename represented by the row. Every row in one valid Store MAP must carry the same exact rid_filename and the same exact source_filename . A MAP that mixes RID lineages or source filenames is invalid. The logical source-column key for COL alias continuity remains the exact triple (source_filename, source_column_number, source_header) . The Store is physically identified by the repeated exact rid_filename , not by mutable aliases. F-05/P2-01 reconciliation: the superseded redundant Store-source column is removed. One Store MAP represents exactly one Store lineage and exactly one source identity, so the common source_filename supplies the required source identity without a second Store-source field. P3-06 identity-evidence boundary: this eight-column MAP profile intentionally records governed physical filenames and mapping metadata, not per-artifact byte lengths, row counts, digests, or historical-content fingerprints. A MAP therefore cannot prove that a same-named RID or COL restored later is byte-for-byte identical to the earlier artifact. WASM-002 must not make that claim unless separate authoritative fingerprint evidence exists outside this MAP profile. P2-04 schema consequence: no byte-length, RID- N , digest, or per-artifact fingerprint columns are added to the eight-column Store MAP to close restoration validation. The MAP remains compact relationship/state metadata. Stronger byte-identity assurance remains the responsibility of explicit fingerprint evidence outside ordinary WASM-002 Store governance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.7,Source headers become default COL aliases on first materialization,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When a logical source column is materialized and its exact logical key does not already exist in the inherited Store MAP, its default COL alias is its operational column name . For an exact decoded source_header of at most 1,024 Unicode scalar values, the operational name is that exact header text. For an exact decoded source_header longer than 1,024 scalar values, the operational name begins as Column <LETTERS> from the column's 1-based physical source ordinal (for example Column A , Column Z , Column AA , through Column XFD ). The exact source_header remains unchanged in the Store MAP and physical COL header; the operational name exists only to provide a bounded human-facing/default-alias value. HEADER selection continues to match the exact decoded source header under W002-STEPS-002. If an oversized-header base fallback Column <LETTERS> would collide in the complete successor alias namespace, Data Sculptor deterministically tries Column <LETTERS> [<ordinal>] ; if that also collides, it appends -2 , -3 , and so on until the first available exact value is found. This is the only automatic alias-suffix rule in WASM-002. A short exact source-header default that is empty or collides still refuses unless the Work Order supplies an explicit valid alias; Data Sculptor must not suffix or rewrite it. If the same Work Order supplies an explicit alias for a newly materialized column, the explicit governed alias overrides the operational default and must pass the ordinary exact uniqueness/shadowing rules without automatic suffix repair. For a previously materialized COL, RESET COL ""<reference>"" ALIAS restores this same deterministic operational default from the exact recorded source_header and physical source ordinal. An oversized recorded header therefore restores its deterministic fallback/disambiguated operational name rather than inserting the potentially very long exact header into the alias field. A short empty/colliding source-header default still refuses rather than inventing a substitute.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.8,"Ordinary rematerialization preserves Store metadata, inherited RID, and inherited COL alias",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If a newly materialized column's exact logical key already exists in the inherited Store MAP, Data Sculptor must preserve that row's current COL alias unless the Work Order explicitly changes it. The successor MAP replaces only that logical row's column_filename with the newly created physical COL artifact filename. Ordinary rematerialization must preserve the inherited Store's exact common source_filename and rid_filename . It must not silently create a different Store, replace the Store RID, revert a user-facing Store/RID alias, or revert a COL alias to its source header. Every row in the successor MAP continues to carry that same common Store source_filename . WASM-002 has no executable operation that replaces rid_filename while preserving the same Store lineage. A different RID filename therefore cannot be introduced as ordinary successor-state continuity in this build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.9,Store MAP serialization is deterministic UTF-8 CSV,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Store MAP CSV files are encoded as UTF-8 without BOM and use LF ( 0x0A ) record termination. The exact eight-field header in W002-STOR-019.6 is written once as the first row. Fields use standard CSV quoting semantics: a field containing comma, double quote, CR, or LF is enclosed in double quotes, and embedded double quotes are doubled. No locale-dependent formatting is permitted. Every data row in one MAP must contain byte-for-byte identical values for store_alias , rid_filename , rid_alias , and source_filename . Mapping rows are written deterministically by ascending numeric source_column_number , then ascending UTF-8 byte order of source_header . Because one valid Store MAP has exactly one common source_filename , that field is not needed as a leading row-sort discriminator. Two rows with the same logical source-column key (source_filename, source_column_number, source_header) are invalid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.10,Only a complete validated Store MAP is eligible for inheritance,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A canonical MAP filename alone does not make a file a structurally valid Store MAP. For Store-MAP structural validity , the MAP artifact itself must be readable as complete UTF-8, have the exact eight-column schema, parse deterministically, satisfy Store-level consistency, lineage, deterministic row-order, mapping-key, and alias constraints, and carry structurally valid governed RID/COL filename bindings. The present health of the referenced RID/COL artifacts is a separate question and does not determine whether the MAP itself is structurally valid. A Store MAP remains part of governed Store history when its own bytes, schema, lineage facts, and deterministic structural rules are valid even if a referenced RID or COL later becomes missing or invalid. Referenced-artifact damage therefore does not make the current structurally valid Store MAP disappear and does not by itself cause fallback to an older MAP. F-03 current Store MAP selection Current-state selection is performed independently within one exact Store lineage. Only structurally valid Store MAP artifacts participate. Among those MAPs, the ordinary frozen chronology rule selects the unique structurally valid MAP with the greatest canonical UTC millisecond timestamp. A structurally malformed newer MAP is never current. If a newer canonical MAP artifact is structurally malformed, Data Sculptor uses the greatest earlier structurally valid Store MAP in that same lineage, if one exists, and reports the malformed newer artifact through governed Help/evidence surfaces. This fallback applies to structural MAP invalidity only. It does not apply merely because a structurally valid current MAP references a damaged RID or COL. If two or more structurally valid MAPs share the greatest canonical UTC millisecond timestamp, current authority is ambiguous and selection refuses rather than breaking the tie by UUID, discovery order, directory order, or filesystem modified time. P3-07 routing distinction: Store-MAP inheritance eligibility is stricter than lineage discovery. A Store lineage participates in exact- SOURCE routing when at least one Store MAP in that lineage is structurally valid, even if the current Store later evaluates DEGRADED or INVALID . Referenced RID/COL health is evaluated after routing and may cause refusal; it must not make an already discoverable lineage disappear. For successor publication, after the required RID/COL physical promotions have succeeded, Data Sculptor uses the already-established publication-transaction UTC and allocates a MAP-specific UUID before opening the complete deterministic MAP CSV under its governed SCR candidate identity. The SCR filename therefore already carries the exact UTC, UUID, and .csv extension intended for the final MAP identity. The candidate is closed successfully, reopened, and validated for bytes, schema, Store-level consistency, aliases, RID binding, COL bindings, deterministic row order, and all other MAP eligibility rules while it remains SCR . Only after that validation succeeds may Data Sculptor promote the candidate by host rename that changes only the three-letter semantic class token from SCR to MAP . The candidate bytes, UTC, UUID, and extension must remain unchanged across promotion. The successful rename is the publication/commit point. If validation or rename fails, no successor MAP becomes eligible/current; the candidate remains or is retained as visible non-authoritative SCR evidence. Store-aware automatic selection therefore continues to use the greatest earlier valid MAP in the same Store lineage, if one exists, while Help reports the failed candidate/publication rather than silently treating it as current state. P3-06 governed artifact-validation tiers. Store-health status and full content validity are distinct assurances. The following two tiers are normative for WASM-002: Tier 1 — Store-health structural validation. Used for routine Store status, source routing, historical-MAP health gates, inheritance decisions that do not consume analytical artifact contents, and alias-only maintenance. The selected Store MAP itself is fully parsed and structurally validated because it is the compact authority for the snapshot. A referenced RID passes Tier 1 only when the exact MAP-bound governed RID filename is present and readable, the bytes begin with exactly one UTF-8 BOM, the first logical record is a canonical N=<value> header, the final byte is LF, and the physical byte length equals the deterministic length implied by the canonical RID representation for that declared N . Tier 1 does not rescan every RID data record merely to perform routine status or alias work. A referenced COL passes Tier 1 only when the exact MAP-bound governed COL filename is present and readable, begins with exactly one UTF-8 BOM, exposes the canonical one-column CSV header whose decoded value exactly equals the MAP row's recorded source_header , and ends with LF. Tier 1 does not stream every COL value merely to establish routine Store health. Tier 2 — full artifact validation. Used whenever an operation actually consumes RID/COL contents, for complete validation of newly created candidates before commit, and by REPAIR MAP after the repair operation has been validly entered. A RID passes Tier 2 only when a full stream proves the canonical N=<value> header, exactly N data records, and exact ordered values 1..N . A COL passes Tier 2 only when a full stream proves canonical one-column CSV encoding/serialization, the exact expected header, and exactly N logical data records aligned to the Store RID. VALID , DEGRADED , and INVALID are Store-health states evaluated from the governed current snapshot using the required validation tier; they are not claims of cryptographic historical identity. When REPAIR MAP is validly invoked, it must perform Tier 2 validation of the RID and every mapped COL that would survive into the successor. The deterministic repair result removes exactly the mapped COL bindings that fail that Tier 2 check, subject to the separately frozen refusal when no mapped COL would remain. Two implementations presented with the same bytes must therefore identify the same repair set. External restoration boundary: a file placed back under an original governed RID/COL physical filename may re-enter use only when it passes the validation tier required by the operation. Filename equality plus governed validation is sufficient for operation eligibility under this WASM-002 boundary; it is not proof that the restored bytes are the historical original bytes. Stronger historical-byte identity requires separate authoritative fingerprint evidence. P3-10 terminology boundary: Store-state repair is REPAIR MAP . Work Order alias-registry repair is REPAIR WORK ORDER REGISTRY . These are distinct governed operations and the integrated specification must not describe a Store REPAIR MAP Work Order as a “registry-repair Work Order.” This corrects wording only; it does not change either operation's frozen semantics. F-08 / F-03 REPAIR MAP Work Order structure and target precondition: SUITCASE: .
WORK ORDER AS ""Repair Crime Store""
MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""
REPAIR MAP Exactly one MAP ""<filename>"" clause is mandatory. It names the exact physical filename of one structurally valid Store MAP. At Run time, that named MAP must be the current structurally valid Store MAP for exactly one lineage and the target Store must currently evaluate DEGRADED . A historical Store MAP, WKO MAP, missing MAP, malformed MAP, ambiguous equal-latest current state, MAP from an unsupported profile, or target Store that does not evaluate DEGRADED refuses. No SOURCE , Store/RID/COL alias selector or mutation, KEEP , materialization, conversion, Inventory, registry repair, cataloging, or composition clause is supplied in the same WKO. The analyst selects the Store by exact current Store MAP identity; Data Sculptor determines which mapped non-RID COL bindings are broken. The terminal DS-STEPS clause is REPAIR MAP ; the Receipt operation token is separately REPAIR_MAP . P2-03 monotonic eligibility boundary: structural validity/eligibility and chronology are separate. A structurally valid future-dated Store MAP remains a structurally valid MAP and participates in current-state selection. It is not demoted merely because the host clock is presently earlier. The monotonic guard applies when publishing a successor: truthful observed transaction UTC must be strictly greater than the chronology predecessor UTC before any successor state may commit. P2-04 closure — validation depth is now complete. The Tier-1/Tier-2 rules in this requirement are the complete WASM-002 oracle for deciding whether a MAP-bound RID/COL is sufficiently valid for the operation being attempted. Tier 1 is intentionally bounded and is used only by operations that do not consume RID/COL analytical contents. Tier 2 is a full streaming validation and is mandatory before an operation relies on RID/COL contents, for newly created candidates before commit, and for REPAIR MAP . REPAIR MAP determinism. Once a valid REPAIR MAP operation is entered, Data Sculptor performs Tier 2 on the Store RID and on every mapped COL. The repair successor removes exactly those mapped COL bindings whose physical COL artifacts fail Tier 2, preserves exactly those that pass Tier 2, and still refuses if zero mapped COL bindings would remain. No shallower Tier-1 result may decide the repair set. F-03 repair semantics: after target validation, Data Sculptor confirms the named MAP is current for exactly one Store lineage, confirms the referenced RID is valid, identifies every mapped non-RID COL that is missing or invalid under the required repair validation tier, preserves every valid COL binding unchanged, removes exactly the broken COL bindings from the successor candidate, preserves the exact Store lineage RID identity and remaining Store/RID metadata, validates the complete successor MAP candidate, and publishes the successor only if every repair gate succeeds. REPAIR MAP does not reread or regenerate the source CSV, rematerialize a lost COL, regenerate the RID, or edit the predecessor MAP in place. F-03 all-COLs-broken refusal: if removing the broken bindings would leave zero COL mapping rows, REPAIR MAP refuses. No zero-COL Store MAP is introduced, no special anchor row is invented, no successor MAP is published, and the Store remains DEGRADED . The existing current structurally valid MAP and RID continue to anchor the visible lineage. Identity boundary. Passing Tier 1 or Tier 2 proves only that the currently visible file under the exact governed filename satisfies the applicable WASM-002 validation contract. It does not prove that those bytes are historically identical to bytes previously present under that filename. Cryptographic historical-byte identity belongs to separately governed fingerprint evidence rather than ordinary Store health. F-15 reference-bounded eligibility: Store-MAP structural validity and inheritance eligibility are determined from the MAP artifact itself plus the governed artifacts and values that the MAP explicitly binds or that its profile explicitly requires for the validation tier being applied. Unrelated Suitcase files, unrelated Store lineages, WKOs, Receipts, Inventories, CAT/HLP/CER artifacts, analyst-owned files, directory enumeration order, and unrelated-file count cannot by their mere presence or later appearance make an already-published Store MAP eligible or ineligible. Alias-shadowing validation is a successor-publication check under W002-STOR-020; it is not a continuing ambient scan that retroactively invalidates historical MAPs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.11,The MAP-bound RID filename is the stable physical Store identity anchor in WASM-002,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, Data Sculptor does not allocate a second permanent Store UUID in addition to governed RID/MAP evidence. The exact governed rid_filename created when the Store is established is the stable physical anchor used to distinguish that Store's MAP lineage from other Stores in the same Suitcase, and every ordinary successor MAP repeats it exactly. Within any one MAP, every row must repeat the same exact current rid_filename ; disagreement is invalid. Across WASM-002 successor MAPs, a different RID filename denotes a different Store row universe and must not be silently treated as same-Store continuation. A later PRD revision may define an explicit governed recovery transition if Red5Sorcery chooses to support replacement of a damaged RID while preserving logical continuity. No such transition is executable in WASM-002.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.12,First Store MAP has deterministic Store and RID aliases,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When the first successful materialization establishes a Store, its first Store MAP must initialize store_alias to the exact common source_filename and rid_alias to the literal RID . Those are the deterministic Store and RID default aliases. A later alias-only Work Order may replace them with STORE AS ""<alias>"" and RID AS ""<alias>"" , clear them with CLEAR STORE ALIAS / CLEAR RID ALIAS , or restore these defaults with RESET STORE ALIAS / RESET RID ALIAS under W002-WKO-012.1 through W002-WKO-012.6. None of those operations changes the common source_filename , rid_filename , RID bytes, COL bytes, or prior MAP history.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-001,CAT is the governed collection-level Store Catalog artifact,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"WASM-002 shall define CAT as a governed Data Sculptor artifact class for cataloging a collection of CSV Stores inside one active Suitcase. CAT exists to let an analyst orient across many independently governed Stores without opening every MAP individually. The scaling invariant is: MAP governs locally; CAT orients globally. CAT is an index over governed Store state, not a replacement for MAP and not a second Store authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-002,CAT may reference many Stores while every MAP still governs exactly one Store,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"A CAT may contain entries for many Store lineages in the active Suitcase. Every MAP referenced by CAT still governs exactly one Store lineage under the frozen one-Store-per-MAP rule. CAT must not combine multiple Stores into one MAP, synthesize a shared Store state, or centralize Store semantics that remain governed independently by each Store's MAP lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-003,CAT has one governed CSV representation and immutable snapshot identity,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The WASM-002 Store Catalog has one durable representation: UTF-8 CSV. WASM-002 shall not emit separate HTML and CSV companion CAT artifacts for one catalog snapshot. Each successful catalog publication creates one immutable governed artifact named exactly __DS__CAT__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv . A later catalog run publishes a new CAT snapshot; earlier CAT artifacts remain visible history and are not overwritten or deleted merely because a newer snapshot exists. For orientation, the directory may identify the newest structurally valid CAT snapshot by the canonical UTC token. If two or more structurally valid CAT artifacts share the greatest canonical UTC timestamp, the UI must not invent chronology from UUID, discovery order, or filesystem modified time; it must surface the ambiguity and may present the tied CAT artifacts together until a later governed catalog run publishes an unambiguous newer snapshot. F-14 publication: CAT is first written as __DS__SCR__<UTC>__<UUID>.csv using the UTC/UUID intended for the final CAT. The complete candidate must close, reopen, and validate the exact five-column schema, deterministic row ordering, row count and CSV serialization before the class token may be renamed to CAT . A failed candidate remains SCR/non-authoritative and must not be selected as a catalog snapshot.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-004,CAT CSV schema and row order are exact and deterministic,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The canonical CAT header row is exactly: store_alias,source_filename,rid_filename,map_filename,store_health Each data row describes one routable Store lineage using values derived from the authoritative current structurally valid Store MAP selected under the existing Store rules: store_alias — current human-facing Store identity; source_filename — the one common exact source filename carried by that Store MAP and used for Store routing; rid_filename — exact immutable governed RID filename that physically identifies the Store lineage; map_filename — exact current structurally valid Store MAP used to derive the row; and store_health — the Store health evaluated during this CATALOG STORES run, exactly one of VALID , DEGRADED , or INVALID . store_health is snapshot orientation metadata, not MAP health and not an independent health authority. If the Suitcase later changes, an older CAT row continues to report the health value observed when that CAT was created. CAT rows are sorted by ascending exact UTF-8 bytes of map_filename . The header is not part of that ordering.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-005,CAT is reconstructible and never becomes Store authority,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"CAT shall be reconstructible from authoritative Store MAP artifacts and the governed Store-health evaluation applied when CATALOG STORES runs. CAT must never be consulted to decide Store routing, inheritance, Store health, repair eligibility, current MAP selection, RID/COL validity, or whether a new Store may be established. If a CAT row conflicts with authoritative MAP/Store state, current governed state wins and the CAT is stale/inconsistent. A stale CAT remains an inspectable historical governed artifact but must not be treated as current Store truth. CAT is not automatically updated by materialization, repair, alias change, or any other Store-changing operation. The analyst creates a fresh catalog explicitly by running a new CATALOG STORES Work Order; success publishes a new immutable CAT snapshot and leaves earlier CAT snapshots visible history.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-006,CATALOG STORES is the standalone governed Work Order operation,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 Work Order form is: SUITCASE: .
WORK ORDER AS ""Catalog Stores""
CATALOG STORES CATALOG STORES is one standalone top-level operation. It is initiated only by an explicit analyst Work Order. No materialization, repair, alias update, conversion, or other governed operation automatically creates, rewrites, or refreshes CAT. The operation scans authoritative governed Store MAP state, evaluates each cataloged Store's current health, and publishes one CAT snapshot plus the normal canonical Receipt. It does not mutate any Store or MAP. It must not also request materialization, conversion, alias mutation, repair, Inventory, Work Order composition, or another consequential operation in the same WKO. The canonical Receipt operation token is CATALOG_STORES .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-007,CATALOG STORES derives one row per routable Store lineage from authoritative MAP state,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The catalog scan shall identify every routable Store lineage using the same structurally-valid-MAP routing definition already frozen for WASM-002. For each routable lineage, Data Sculptor evaluates current Store health exactly under W002-STOR-019.2, using the current structurally valid Store MAP selected under W002-STOR-019.10 and the applicable validation tier, and records exactly one of VALID , DEGRADED , or INVALID . Catalog presence is orientation, not permission to perform another operation. Exactly one CAT row is emitted for each routable Store lineage, derived from that lineage's authoritative current structurally valid Store MAP and the Store-health result observed during this catalog run. If the complete authoritative collection state cannot be determined unambiguously, the operation must refuse rather than publish a knowingly incomplete or guessed CAT. CATALOG STORES is read-only with respect to all pre-existing Store, RID, COL, MAP, source, WKO, and other Suitcase artifacts. It does not repair or mutate them.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-008,CAT publication is all-or-refuse and historical CAT snapshots remain visible,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"After the complete deterministic CAT row set is established, publication follows the governed all-or-refuse artifact path: write the candidate under governed scratch, close and reopen it, validate its exact filename, UTF-8/LF CSV structure, exact header, deterministic row count/order, and row references, then promote the final CAT artifact. The CAT is not successfully published until final promotion succeeds. A publication refusal leaves prior CAT snapshots and all Store/MAP state unchanged. The Receipt records whether the catalog entry count was established and whether a final CAT filename was published.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-001,CAT and MAP discovery reuse the existing Suitcase Directory,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,WASM-002 shall reuse the existing Data Sculptor Suitcase Directory for CAT and MAP discovery and inspection. A separate CAT/MAP browser panel shall not be added.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-002,CAT and MAP artifacts are first-ranked in the existing directory,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The newest unambiguous structurally valid CAT snapshot, or any tied newest CAT candidates when chronology is ambiguous, and all Store MAP artifacts shall be surfaced prominently at the top of the existing Suitcase Directory ahead of ordinary Suitcase files. The presentation may be pinned, grouped, or otherwise first-ranked, provided the priority is obvious and deterministic.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-003,CAT and MAP contents are immediately viewable from the existing HTML UI,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,The analyst shall be able to select a visible CAT or MAP entry and inspect its contents through the existing read-only HTML UI without first locating or opening the artifact through the operating-system file browser.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-004,CAT/MAP prominence preserves ordinary read-only Suitcase filtering,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The Suitcase Directory may continue to provide read-only filtered views of other Suitcase files. CAT/MAP prominence must not remove, replace, or weaken the existing ability to inspect the rest of the flat Suitcase.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-005,Directory browsing and inspection do not require a Work Order,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"Browsing, sorting, UI filtering, selecting, opening, and viewing Suitcase files are read-only inspection actions and shall not require a Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-006,Read-only directory filtering is not governed SEARCH,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"Read-only UI filtering is not the same operation as governed SEARCH . Governed SEARCH, ZIP creation, metadata changes, repairs, CAT regeneration, and every other consequential state change remain subject to the applicable Work Order and Receipt discipline.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-007,"The directory cannot mutate CAT, MAP, Store, or Suitcase state",W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The Suitcase Directory shall not edit, rename, delete, repair, replace, regenerate, or otherwise mutate CAT, MAP, Store, or Suitcase state through direct GUI manipulation. Consequential changes occur only through explicit governed operations or analyst-owned filesystem actions already permitted by the canonical contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-008,The CAT/MAP directory view must remain practical at large collection scale,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The CAT/MAP presentation shall make collections containing dozens or hundreds of Stores practical to inspect. An analyst must be able to understand what Stores exist, which current MAP describes each Store, and which source file each Store governs without manually opening every MAP artifact through the operating-system file browser.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-ACC-001,CAT acceptance proves collection-scale orientation without centralizing Store authority,W002-CAT-ACC,W002-CAT,WASM-002,UNDER REVIEW,—,"Acceptance must include a MusicBrainz-scale fixture containing 177 routable CSV Store lineages, each with its own authoritative current Store MAP. One explicit analyst-run CATALOG STORES Work Order must publish exactly one CAT snapshot containing exactly 177 data rows under the frozen five-column schema store_alias,source_filename,rid_filename,map_filename,store_health and deterministic MAP-filename ordering. The fixture must include Stores that evaluate VALID , DEGRADED , and INVALID while retaining structurally valid current MAPs, and the CAT must record the exact health observed for each Store when the catalog run occurs. The CAT must not expose a separate MAP-health field. The existing Suitcase Directory must surface CAT and MAP artifacts ahead of ordinary files; the analyst must be able to open CAT, inspect the collection, select and view MAP artifacts, sort/filter the directory, and inspect other Suitcase files without a Work Order. No direct GUI mutation path may be exposed. Acceptance must alter authoritative MAP/Store state after the first CAT publication and prove that the earlier CAT is neither rewritten nor automatically refreshed. It remains visible and becomes stale/inconsistent where appropriate. Only a later explicit CATALOG STORES Work Order may reconstruct the collection and publish a new immutable CAT snapshot. The linked WASM-003 DIR behavior remains outside the WASM-002 implementation scope: later DIR requirements auto-populate human-readable CAT/MAP descriptions, but those descriptions never become authority over CAT, MAP, or Store semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-020,"Store, RID, and COL aliases remain human-facing metadata separate from physical identity",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Aliases are governed human-facing metadata. Creating, changing, clearing, or replacing an alias must not rename or rewrite the underlying artifact. Within one Store MAP, every non-empty COL alias and the non-empty rid_alias must be unambiguous within the row-addressable artifact alias namespace under the exact Unicode scalar-value comparison rule in PB-STOR-010. F-15 publication-time shadowing boundary: alias uniqueness and physical-name shadowing are validated when a candidate successor Store MAP is being published, against the comparison domain applicable to that one Store snapshot and the then-visible governed physical targets it makes row-addressable. If an alias would exactly collide with another addressable alias or physical filename in that publication domain, publication refuses. After a Store MAP has been validly published, the later appearance, disappearance, rename, or copying-in of an unrelated Suitcase file does not retroactively make that immutable MAP structurally invalid or ineligible. A later textual reference can still become ambiguous at resolution time under W002-STOR-021; that ambiguity causes the later operation to refuse rather than changing the historical MAP's validity. The store_alias names the Store as a whole and is separate from the field/COL alias namespace. Alias mutation occurs through a governed Work Order, not through an editable GUI field. Exact cross-Store Store-alias uniqueness and future selection-by-Store-alias syntax remain outside this freeze.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-021,Work Order resolution binds one exact Store MAP and physical targets,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A saved Work Order may refer to governed materialized columns by exact physical filename or by a unique COL alias from one selected Store MAP. The canonical explicit Store-MAP selector is MAP ""<exact Store MAP filename>"" under W002-STOR-019.3 and W002-WKO-012.3. If that clause is present and valid, exactly that Store snapshot is used. Otherwise Data Sculptor applies the Store-aware source-qualified selection rule in W002-STOR-019.2. All textual physical-filename and COL-alias comparisons in this resolution step use exact Unicode scalar-value sequence equality under PB-STOR-010: no case folding, Unicode normalization, trimming, locale equivalence, or filesystem enumeration heuristic is permitted. Resolution is bounded to the selected Store snapshot and the physical targets/aliases that are addressable through that snapshot. If the supplied text has no exact target, resolution refuses. If it has more than one exact possible target in that domain—for example because a currently visible physical filename and a current alias are both exact matches—resolution also refuses. Data Sculptor must not choose filename over alias, alias over filename, first-found entry, directory order, modified time, UUID, or any other tie-break heuristic. Before execution, Data Sculptor must record the exact physical Store MAP identity when one is used, bind the run to its exact rid_filename , and resolve aliases deterministically to physical COL artifacts. The selected Store MAP must remain fixed for the run even if a newer MAP is created during that same run. This protects Store/selection continuity but does not by itself claim that bytes stored under an analyst-owned source filename are cryptographically identical across different runs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022,Each successful Suitcase validation publishes one retained governed CER HTML certificate,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A selected directory becomes a validated Suitcase only when Data Sculptor successfully creates, completely writes, and closes one governed CER HTML Suitcase Validation Certificate in that directory. The certificate itself is the validation artifact and remains visible in the flat Suitcase as durable evidence. No validation-only delete or rename is required. Failure to create, completely write, or close the certificate means the directory has not passed Suitcase validation and analytical execution remains locked. F-14 CER exception: the CER is deliberately not staged as SCR . Suitcase validation is specifically the direct create/write/close test of the final canonical CER identity in the selected directory. Inserting an SCR-to-CER rename would test a different publication path and is therefore forbidden for this validation step. A successful CER does not pre-certify later SCR-to-final renames for other artifact classes. F-24 CER lifecycle: every successful explicit Suitcase selection and validation publishes exactly one fresh immutable CER with a new governed UTC+UUID identity. Data Sculptor must not satisfy a new validation event by reusing an earlier CER. Every prior valid CER remains a standalone historical artifact under its original governed filename and exact bytes. WASM-002 performs no automatic CER deletion, replacement, compaction, or CER-history ZIP packaging. Historical CERs are not housekeeping candidates merely because a newer CER exists. Any later archival or packaging capability must be separately governed and explicitly invoked; it is not part of the WASM-002 validation lifecycle.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.1,Suitcase Validation Certificate physical identity and longest-name path gate,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The exact certificate filename is __DS__CER__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html , using the canonical UTC millisecond token and canonical lowercase hyphenated UUID v4. Data Sculptor chooses the filename; the analyst does not supply or edit it. The CER create/write/close test begins only after the browser host has satisfied the required user-selected writable-directory capability in W002-PLAT-001. A browser that cannot expose that capability produces a host-capability refusal before folder validation; that condition is not evidence that any particular directory is unwritable or filename-incompatible. WASM-002 path/filename acceptance must derive the maximum filename length from every governed final-artifact filename form and every governed SCR staging form that this build can actually emit. Under the current contract, the maximum is 73 ASCII bytes/characters : the governed .html CER/HLP final forms and an SCR candidate reserved for a .html final artifact have that length. The canonical CER filename therefore exercises the current maximum emitted filename length during the create/write/close validation test. On a supported host, successful create/write/close of this canonical governed HTML filename is the WASM-002 folder filename/path compatibility test for the current emitted-name maximum. Data Sculptor does not maintain a product-level table of operating-system numeric path maxima and must not truncate, abbreviate, hash-shorten, or otherwise mutate a governed filename to fit a host path limitation. If the certificate cannot be created under its canonical name after a directory has actually been selected through the supported-host contract, the selected directory does not pass validation. If a future PRD revision introduces an emitted final or staging filename longer than the current CER/HLP/SCR-HTML maximum, acceptance must detect that change and explicitly exercise the new maximum before the build may rely on this path-compatibility claim.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.2,Suitcase Validation Certificate semantic content,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The HTML certificate uses the canonical built-in Data Sculptor presentation and must visibly contain, at minimum: SUITCASE VALIDATION CERTIFICATE RESULT: PASS SUITCASE: . UTC: <canonical certificate UTC> UUID: <certificate UUID> ARTIFACT: <full governed certificate filename> TEST: CREATE_WRITE_CLOSE It must state that Data Sculptor successfully created, completely wrote, and closed this governed HTML certificate in the selected Suitcase. It must state that this establishes that the selected directory was writable by Data Sculptor at the recorded UTC and accepted the governed artifact filename used for the certificate. It must also state that the certificate does not certify available disk capacity, guarantee success of future analytical operations, or certify later SCR -to-final-class publication/rename operations. The semantic record uses SUITCASE: . and must not persist an absolute machine-specific path merely to prove validation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.3,Suitcase Validation Certificate uses the canonical built-in presentation in WASM-002,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The certificate is a human-facing HTML CER artifact and uses the canonical built-in Red5Sorcery/Data Sculptor presentation in WASM-002. Presentation must never change RESULT , SUITCASE , UTC, UUID, artifact identity, TEST , validation meaning, or limitation facts. Configurable Brand Manifest application to CER artifacts is deferred to V1-BACKLOG / a future build and is not required for WASM-002 Suitcase validation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-023,Non-Store governed artifacts use class-specific all-or-refuse publication profiles,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Except for the deliberate CER Suitcase-validation path below, WASM-002 does not place a newly generated durable artifact into its final semantic class merely because candidate bytes exist. The complete candidate is first written under the governed SCR identity defined by W002-STOR-023.1, closed, reopened, and validated against the target class contract. Only a candidate that passes its class-specific publication predicate may be renamed into the intended final class. A final-class filename therefore records successful class publication, not broader authority where a separate MAP/registry relationship governs authority. F-33 reserved-class boundary: DGN , RCV , BRD , and LCK are registered but not emitted by WASM-002, so they do not appear as publication profiles in this table and have no WASM-002 producer here. Final class Final serialization / identity Publication predicate Authority boundary WKO __DS__WKO__<UTC>__<UUID>.txt The complete candidate obeys the saved-Work-Order lifecycle and parses completely under exactly one WASM-002 executable operation grammar with the required SUITCASE: . , exactly one non-whitespace WORK ORDER AS alias, and the governed lexical/comment rules. Applicable save-time alias/registry gates must also pass before the save transaction may commit. Promotion proves a valid immutable WKO artifact. Alias-registry authority is not committed until the complete successor WKO MAP is successfully published under W002-STOR-018.3. RCP __DS__RCP__<UTC>__<UUID>.txt The complete candidate validates against W002-RCP-005 through W002-RCP-008: exact deterministic TXT serialization, common envelope, applicable operation-specific key table, governed absence semantics, and created-artifact tail. Publication creates durable run evidence only. It does not retroactively create or change analytical state. HLP __DS__HLP__<UTC>__<UUID>.html The complete self-contained HTML satisfies the HLP disclosure, presentation, provenance, embedded-JSON, lineage and semantic-parity rules in W002-HELP-009 and related Help requirements. Publication creates durable Help/support evidence. It does not override the underlying diagnostic event or analytical state. CVT __DS__CVT__<UTC>__<UUID>.csv The bounded Windows-1252 conversion completes, the original analyst-owned source remains unchanged, the converted bytes pass the governed strict UTF-8 requirement, and the candidate closes/reopens successfully. Structural CSV interpretation remains a later certification/materialization concern. The published exact CVT filename is a new immutable governed source identity for later routing under W002-CONV-004. INV __DS__INV__<UTC>__<UUID>.txt The complete inventory scan has established the governed entry set and the candidate validates the deterministic INV serialization, count, metadata availability and ordering rules. Publication creates an immutable inventory snapshot; it is evidence/orientation, not Store authority. CAT __DS__CAT__<UTC>__<UUID>.csv The authoritative MAP discovery/evaluation pass has completed and the candidate validates the exact five-column CAT schema, row count, row ordering and deterministic CSV rules. Publication creates an immutable collection-level orientation snapshot. MAP remains authoritative for each Store. CER __DS__CER__<UTC>__<UUID>.html Deliberate exception: Suitcase validation directly creates, completely writes and successfully closes the final CER identity under W002-STOR-022 through W002-STOR-022.3. No SCR staging/rename is inserted into this test. The CER proves that canonical governed create/write/close succeeded in the selected directory at that recorded moment. It does not pre-certify later SCR-to-final publication. RID, COL, Store MAP and WKO MAP publication retain their specialized transaction/commit rules elsewhere in this PRD. W002-STOR-023 does not replace those state-publication contracts; W002-STOR-023.1 supplies the shared SCR candidate identity and retained-failure-evidence boundary they may reference.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-023.1,SCR candidates preserve intended final identity; retained failure evidence remains non-authoritative,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical candidate filename for a staged governed artifact is: __DS__SCR__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.<final-extension> The SCR candidate uses the exact UTC token, UUID and extension reserved for its intended final artifact. Successful publication changes only the three-letter semantic class token from SCR to the intended final class. For example, an RCP candidate __DS__SCR__20261006T190000000Z__<uuid>.txt may become __DS__RCP__20261006T190000000Z__<uuid>.txt only after the complete candidate has been closed, reopened and validated against the RCP publication predicate. The rename must not alter candidate bytes, UTC, UUID or extension. An SCR filename never by itself confers final-class validity, Store membership, registry authority, execution authority, or durable final-class evidence status. A retained SCR whose bytes happen to satisfy a target validator after an interrupted or refused transaction must not be auto-promoted, silently adopted, or treated as if the missing publication step occurred. F-33 retained-failure-evidence boundary: when a handled failure leaves one or more SCR candidates or other staged bytes that cannot be safely removed or restored, they must remain visible only as non-authoritative SCR evidence. WASM-002 does not publish an RCV recovery manifest. Retention must not complete or simulate the failed publication step, and the governed diagnostic/Help path must report the failure using only facts actually established. A retained or orphaned SCR remains non-authoritative even if its bytes later validate. Data Sculptor must not infer an intended final class solely from extension or byte content, must not rename or promote the SCR merely because it survives a later scan, and must not create a replacement RCV sidecar to manufacture attribution that the failed transaction did not durably preserve.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-011; CP-012; CP-013; CP-014; CP-015,"CP011 T-ACCEPTED, GIT BANKED — exact CVT-to-SCR candidate identity derivation only; full SCR lifecycle and publication contract remains open; CP012 T-ACCEPTED, GIT BANKED — canonical SCR staging filename recognition only; generic publication, recovery and authority remain unimplemented; CP013 T-ACCEPTED, GIT BANKED — explicit SCR-to-RCP final filename candidate derivation only; no complete SCR lifecycle, RCP validator, filesystem promotion, publication or authority; CP014 T-ACCEPTED, GIT BANKED — related RCP final-candidate lexical recognition only, no SCR creation or publication; CP015 T-ACCEPTED, GIT BANKED — pure lexical canonical SCR-to-RCP TXT filename-candidate pair matching only; no actual file/Receipt validation, promotion, publication or authority",e84ae5baeee05f9d5d30284c65b86eebba3c0f6a; efca04392940e398020a5c06b9ee50296c8a1fdd; 005a38ef5e876847c4c08901c18da9c18565fd6b; f5038a183f1d3dc31b0065571bf8ac8814b5d8a9; be997dc0dbd65fc370814c4a5f2d0f1254870572,"Evidence/CP-011/CP011_Scope_Lock.txt; Evidence/CP-011/CP011_RED_Test_Output.txt; Evidence/CP-011/CP011_GREEN_Test_Output.txt; Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt; Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt; Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt; Evidence/CP-011/CP011_Hash_Inventory_Verification.txt; Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt; Evidence/CP-011/CP011_Closing_Git_Review.txt; CP011_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-012/CP012_Scope_Lock.txt; Evidence/CP-012/CP012_RED_Test_Output.txt; Evidence/CP-012/CP012_GREEN_Test_Output.txt (initial 5/6, retained); Evidence/CP-012/CP012_GREEN_Failure_Triage.txt; Evidence/CP-012/CP012_GREEN_Correction_Review.txt; Evidence/CP-012/CP012_GREEN2_Test_Output.txt; Evidence/CP-012/CP012_Full_Regression_Test_Output.txt; Evidence/CP-012/CP012_WASM_Build_Output.txt; Evidence/CP-012/CP012_Final_Rustfmt_Check.txt; Evidence/CP-012/CP012_Hash_Inventory_Verification.txt; Evidence/CP-012/CP012_Supplementary_Hash_Verification.txt; Evidence/CP-012/CP012_Post_Staging_Hash_Verification.txt; Evidence/CP-012/CP012_Closing_Git_Review.txt; CP012_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-013/CP013_Approved_Scope_Lock.txt; Evidence/CP-013/CP013_RED_Test_Output.txt; Evidence/CP-013/CP013_GREEN_Test_Output.txt; Evidence/CP-013/CP013_Full_Regression_Test_Output.txt; Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt; Evidence/CP-013/CP013_WASM_Build_Verification.txt; Evidence/CP-013/CP013_Hash_Inventory_Verification.txt; Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt; Evidence/CP-013/CP013_Closing_Hash_Verification.txt; Evidence/CP-013/CP013_Final_Staging_Verification.txt; Evidence/CP-013/CP013_Closing_Git_Review.txt; CP013_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip; CP014_Git_Banking_Record.txt (external closeout); Evidence/CP-015/ZIP/CP015_RED_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_GREEN_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_PostAmend_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_Full_Regression_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_WASM_Build_Output.txt.zip; Evidence/CP-015/ZIP/CP015_Final_Archive_Manifest.txt.zip; CP015_PostCommit_Verification.txt (external closeout)","CP011 Day066: public pure helper build_scr_candidate_filename_for_cvt(&str)->Option<String> accepts an exact canonical governed CVT .csv filename (via CP010 recognizer) and derives the paired SCR filename by substituting only class token CVT -> SCR, preserving exact UTC, UUIDv4 and lowercase .csv bytes; rejects wrong classes, paths, whitespace, malformed clock/date/UUID, extension and class case. Six targeted tests; RED expected E0432 exit 101; GREEN 6/6; post-format native regression 46/46; rustfmt recheck PASS; Rust 1.97.1 wasm32-unknown-unknown --lib build PASS; original 28/28 and combined 36/36 SHA-256 records verified. Two local scoped .gitattributes whitespace exceptions preserve Rustfmt/Git diagnostic TXT bytes; final Git staged check PASS. T-approved and Git banked e84ae5baeee05f9d5d30284c65b86eebba3c0f6a, 27 committed files, working tree clean. Lexical candidate-name pairing ONLY; no SCR creation, bytes, converter, transaction, close/reopen, validation/publication, retained SCR adoption, SOURCE authority or browser execution. Independent Claude implementation QA pending. CP012 Day066: pure public bool recognizer is_canonical_scr_filename_candidate(&str) validates exact uppercase SCR staging class via shared canonical immutable filename-token parser, with local rejection of whitespace and both path separators; accepts canonical .csv and .txt SCR candidates without assuming extension or bytes confer intended final class, validity, publication or authority. RED expected missing import E0432 exit 101. Initial GREEN 5/6 exposed trailing whitespace acceptance through generic extension grammar, retained verbatim; controlled CP012-local correction yielded 6/6 PASS. Full native regression 52/52 PASS, Rustfmt 12 Rust files checked/0 modified, canonical Rust 1.97.1 wasm32-unknown-unknown --lib build PASS (not browser execution). Primary independent SHA256/size inventory 29/29 PASS; supplementary original 4/4 PASS; post-staging 6-record amendment independently verified following narrowly scoped trailing-space and blank-at-EOF git attributes for preserved diagnostic evidence; final staged Git whitespace exit 0. T approved and banked Git commit efca04392940e398020a5c06b9ee50296c8a1fdd (28 committed files; master clean). Previous generic canonical parser unchanged. W002-STOR-023.1 remains PARTIAL, no filesystem creation, close/reopen, class publication, retained/orphan SCR adoption or recovery, SOURCE authority, or independent Claude implementation QA claimed. CP013 Day066: pure public function build_final_filename_candidate_for_scr(&str, &str)->Option<String> accepts only a canonical SCR staging filename with exact lowercase .txt serialization and explicit intended_final_class == ""RCP""; derives RCP final filename candidate by substituting the SCR semantic-class token only, preserving original UTC token, UUID and extension. Rejects all other class intentions, malformed or non-SCR staging names, paths/whitespace, wrong extension or case. Six intentional RED tests (unresolved E0432 before implementation), six GREEN targeted passes; full native 58/58 PASS; Rust 1.97.1 rustfmt check PASS and wasm32-unknown-unknown --lib build PASS (not browser runtime). Primary 21/21, supplementary 27/27 before attribute revisions; post-normalization 32/32 and closing 37/37 SHA-256 identity/byte-preservation checks; 42/42 commit blobs verified, Git whitespace check exit 0 after directory-scoped CRLF-aware whitespace attributes and raw-byte preservation; staging failures and adjustments retained byte-for-byte. T accepted and Git banked 005a38ef5e876847c4c08901c18da9c18565fd6b (efca04392940e398020a5c06b9ee50296c8a1fdd parent), 42 files, clean tree and index. This covers only lexical candidate-name derivation under already-PARTIAL W002-STOR-023.1; W002-STOR-023 remains NOT_STARTED; no SCR creation, RCP contract validation, promotion, publication, retained/orphan handling, authority or recovery. No independent adversarial QA or accepted end-to-end requirements; Day066 OPEN. CP014 Day067: T-accepted, Git-banked lexical RCP .txt filename recognizer only. Pure is_canonical_rcp_filename_candidate(&str)->bool uses shared canonical envelope, rejects wrong class/extension/casing, malformed UTC/UUID, paths and whitespace. Six target GREEN passes; 64/64 native regression; Rustfmt and wasm32 library build PASS; 32 original-TXT-per-ZIP objects validated and committed unchanged. Commit f5038a183f1d3dc31b0065571bf8ac8814b5d8a9. No new Receipt timestamp generation, Receipt byte serialization, creation/promotion/publication or authority; independent implementation QA and browser runtime pending. CP015 Day067: T-approved pure is_matching_scr_rcp_filename_candidate_pair(&str,&str)->bool checks canonical SCR/RCP lowercase .txt candidates and exact timestamp/UUID pairing, reusing existing lexical recognizers and candidate derivation; rejects wrong classes/order, mismatched timestamps/UUID, paths, whitespace and noncanonical envelopes. Expected RED E0432 exit 101; six targeted GREEN PASS; T-approved formatting-only source+test amendment and recheck; full native regression 70/70 PASS, Rustfmt PASS, Rust 1.97.1 wasm32-unknown-unknown --lib compile PASS. Original TXT archived as 16 verified single-entry ZIPs; 18/18 committed Git blob identities checked; working tree clean. Banked at be997dc0dbd65fc370814c4a5f2d0f1254870572. No actual SCR/RCP file reads, Receipt content validation, timestamp generation, authority, promotion or publication; browser execution and independent implementation QA pending.",Day067,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001,Strict whole-file UTF-8 certification,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Before WASM-002 performs analytical CSV materialization, it must certify the complete selected source as valid UTF-8 using bounded processing.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.1,"Certification must examine the entire source, not merely a prefix, sample, BOM, or first analytical window.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.2,"UTF-8 validity must be determined across chunk boundaries, including incomplete multi-byte sequences that span adjacent input windows.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.3,"A UTF-8 BOM, when present, is parsing metadata and must not be treated as proof that the remainder of the source is valid UTF-8.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.4,Certification must preserve exact source-byte accounting.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.5,Certification must operate within the governed WASM memory budget.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Stage 1 UTF-8 certification must remain bounded independently of source byte length and must not buffer the complete source, CSV header, or CSV row set in memory. CSV column-count and operational-name rules belong to Stage 2 and must not be used to justify unbounded Stage-1 state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.6,Certification must produce deterministic PASS or FAIL for the same source bytes under the same frozen rules.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002,UTF-8 certification is a hard analytical gate,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,The WASM-002 analytical/materialization path must proceed only after successful UTF-8 certification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.1,"If UTF-8 certification fails, the current analytical Work Order must stop.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.2,The analytical engine must not silently switch to another decoder.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.3,The analytical engine must not continue materialization under an inferred or guessed source encoding.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.4,No Windows-1252 transcoding may occur as an implicit sub-step of the failed analytical Work Order.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003,Certification and materialization share one run-local selected source,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"For a governed WASM-002 analytical run, the browser host must resolve the Work Order source reference once and retain the same selected source instance across Stage 1 UTF-8 certification and Stage 2 materialization. The purpose of this binding is to prevent Stage 2 from accidentally consuming a different source than the one Stage 1 certified. It is a run-local continuity guarantee, not a claim of durable cryptographic identity across separate runs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.1,Stage 2 must not re-resolve or substitute the source,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"After Stage 1 begins, Stage 2 must not reacquire the analytical source by re-reading an alias mapping, re-resolving a filename/path, opening a newly selected browser file, or otherwise substituting another source instance. Stage 2 consumes the source instance already bound to the governed run.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.2,"Filename, alias, path, or byte length alone is not durable byte identity",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Filename equality, alias equality, path equality, timestamps, or exact byte length may be useful provenance facts but must not be presented as cryptographic proof that source bytes are identical across separate runs. WASM-002 makes no such automatic cross-run exact-byte claim.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.3,Ordinary WASM-002 source binding does not require automatic SHA-256,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,UTF-8 certification and ordinary column materialization must not automatically compute SHA-256 merely to establish WASM-002 source binding. The source-binding requirement is satisfied by preserving the same run-local selected source instance across the two stages. This rule does not prohibit SHA-256 where another explicit WASM-002 requirement governs integrity for a specific generated artifact. It applies to automatic hashing of ordinary analytical source data.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.4,Loss of run-local source continuity causes refusal,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"If the browser host cannot preserve the selected source instance from certification into materialization, or the source becomes unavailable before Stage 2 can consume it, the analytical run must refuse before materialization rather than silently reselect, substitute, or infer another source.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004,ASCII-first inline UTF-8 certification algorithm,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"WASM-002 must use an ASCII-first, strict inline UTF-8 certification algorithm or an equivalent implementation that preserves the same single-forward-scan semantics, bounded state, deterministic validity result, exact error location, and performance intent established by WASM-001b.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.1,The certifier must process the source in bounded windows and must not allocate memory proportional to source-file size.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.2,"The 4 MiB window used in WASM-001b is a proven reference point, not a frozen WASM-002 production constant.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Window size may be changed only if semantics and byte-identical certification outcomes remain invariant.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.3,"At the beginning of each window, any incomplete UTF-8 sequence carried from the preceding window must be resolved before the remaining bytes are treated as independent input.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.4,"When there is no pending cross-window sequence, consecutive bytes below 0x80 must be recognized as ASCII and certified directly because ASCII is a complete subset of UTF-8.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.5,An all-ASCII window with no pending cross-window sequence must be certifiable without submitting the same bytes to a second general UTF-8 decoder pass.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.6,"When a byte at or above 0x80 is encountered, the certifier must validate the UTF-8 sequence inline, then resume the ASCII-fast scan after the valid sequence.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.7,"The implementation must not require collecting all non-ASCII bytes, all non-ASCII runs, or all non-ASCII offsets for later validation.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.8,The implementation must not require a separate general-purpose string-decoder call for each non-ASCII sequence.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,An equivalent low-overhead strict validator is acceptable if it preserves the same governed result and bounded-state behavior.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.9,Cross-window state must be bounded to the information required for at most one incomplete UTF-8 sequence.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"No more than three source bytes may need to remain pending between windows, or an equivalent smaller state representation may be used.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.10,"On the first invalid UTF-8 sequence, certification must stop and report the exact absolute source-byte offset required by the frozen error contract.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"On the first invalid UTF-8 sequence, certification must stop and return FAIL . The governed UTF-8 refusal evidence is: FIRST_INVALID_BYTE_OFFSET — the zero-based absolute byte offset of the first byte of the invalid sequence , counted from the first physical source byte, including a permitted leading UTF-8 BOM when present; and STOP_REASON — exactly INVALID_UTF8_SEQUENCE . For an EOF-truncated multibyte sequence, FIRST_INVALID_BYTE_OFFSET is the absolute offset of that incomplete sequence's lead byte, not the EOF position. The certifier need not read the remainder of an already-invalid source. Input-window boundaries must not change the outcome, stop reason, or first-invalid offset. F-16 follow-on boundary: stopping strict UTF-8 certification at the first invalid sequence does not make the remainder of the source irrelevant to conversion advice. When the governing operation is MATERIALIZE and Stage 1 reaches FAIL , the analytical run remains refused; Data Sculptor then starts the separate read-only compatibility assessment in W002-CONV-002 from physical byte offset 0 of the same bound source instance. That second pass may read to EOF solely to determine converter compatibility. Stage 2 must not start.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.11,"At EOF, certification may return PASS only if every source byte has been consumed under the strict UTF-8 rules and no incomplete sequence remains pending.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"At EOF, certification may return PASS only if every physical source byte has been consumed under the strict UTF-8 rules and no incomplete sequence remains pending. The completed Stage-1 outcome vocabulary is exactly PASS and FAIL . PASS means strict whole-source UTF-8 certification completed successfully. FAIL means an invalid UTF-8 sequence was deterministically established under W002-ENC-004.10. The common Receipt absence tokens remain separate from those completed outcomes: NOT_RUN when Stage 1 never begins, and NOT_AVAILABLE when Stage 1 begins but a separate failure prevents a governed PASS/FAIL conclusion. NOT_APPLICABLE is not a completed value for STAGE1_UTF8_OUTCOME .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.12,"A UTF-8 BOM at absolute source offset zero may be recognized as BOM metadata after its bytes are validated, but the remaining source must still undergo complete certification.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.13,"The certifier must not perform CSV delimiter, quote, header, row, or analytical interpretation.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Certification answers only whether the complete source byte stream is valid UTF-8 under the frozen rules.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.14,Certification results must be independent of window boundaries.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Splitting the same valid or invalid source at different bounded window sizes must not change PASS/FAIL or the first invalid absolute byte offset.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.15,"The certifier must expose enough measured counters for acceptance evidence to reconcile source bytes read, windows/pushes processed, non-ASCII sequences encountered when counted, final pending state, and stop reason without requiring those counters to alter certification semantics.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005,Strict UTF-8 byte-sequence rules,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"The inline validator must implement strict modern UTF-8 validity, excluding overlong forms, UTF-16 surrogate code points, values above U+10FFFF, invalid lead bytes, invalid continuation bytes, and truncated sequences. F-07 stop-reason vocabulary: all strict UTF-8 invalidity classes governed by this requirement—lone continuation bytes, malformed continuation sequences, overlong forms, surrogate encodings, values above U+10FFFF, invalid lead bytes, and EOF-truncated sequences—serialize the single machine reason token INVALID_UTF8_SEQUENCE . The specific fixture category is acceptance evidence; the canonical stop reason intentionally does not duplicate validator-library-specific subcodes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.1,Single-byte ASCII is 0x00 through 0x7F.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.2,Two-byte sequences must begin with 0xC2 through 0xDF and be followed by exactly one continuation byte 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.3,"Three-byte sequences beginning with 0xE0 must use a second byte 0xA0 through 0xBF and a third byte 0x80 through 0xBF, preventing overlong encodings.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.4,Three-byte sequences beginning with 0xE1 through 0xEC or 0xEE through 0xEF must use two continuation bytes 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.5,"Three-byte sequences beginning with 0xED must use a second byte 0x80 through 0x9F and a third byte 0x80 through 0xBF, excluding UTF-16 surrogate halves.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.6,"Four-byte sequences beginning with 0xF0 must use a second byte 0x90 through 0xBF followed by two continuation bytes 0x80 through 0xBF, preventing overlong encodings.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.7,Four-byte sequences beginning with 0xF1 through 0xF3 must use three continuation bytes 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.8,"Four-byte sequences beginning with 0xF4 must use a second byte 0x80 through 0x8F followed by two continuation bytes 0x80 through 0xBF, preventing code points above U+10FFFF.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.9,Bytes 0x80 through 0xBF are invalid when encountered as lead bytes.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.10,Bytes 0xC0 and 0xC1 are invalid lead bytes because they can only introduce overlong encodings.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.11,Bytes 0xF5 through 0xFF are invalid UTF-8 lead bytes.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"ASCII-first inline UTF-8 certification algorithm READ NEXT BOUNDED WINDOW Reference evidence used 4 MiB windows RESOLVE PENDING CROSS-WINDOW STATE At most one incomplete UTF-8 sequence ASCII FAST SCAN Advance cheaply while every byte < 0x80 ASCII RUN Already valid UTF-8 RESUME SCAN Same window BYTE >= 0x80 Validate sequence inline STRICT UTF-8 Lead + continuation range rules VALID END OF WINDOW? Persist only bounded carry state MORE SOURCE? Yes: read next window; No: finish EOF + NO PENDING STATE UTF-8 PASS INVALID OR TRUNCATED UTF-8 FAIL No full-file allocation. No collection of all non-ASCII bytes. No per-sequence general string decode required. Figure 2. The WASM-001b-derived fast path certifies ASCII directly, validates only non-ASCII sequences inline, and carries only bounded state across windows.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-006,Measured evidence inherited from WASM-001b,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"The following measurements are non-normative evidence explaining why WASM-002 begins with the ASCII-first inline algorithm. They are not WASM-002 acceptance results and must not be represented as such. EVID-W001B-UTF8-001 On the 7,250,808,204-byte Statistics Canada source, the Day 039 distribution experiment observed 659,103 non-ASCII bytes, approximately 0.009090063% of the file, across 329,551 non-ASCII runs/sequences; the maximum observed non-ASCII run was three bytes. EVID-W001B-UTF8-002 The Day 039 non-ASCII-only experiment submitted only 659,103 bytes to strict UTF-8 validation and completed in 12.664716 seconds at 545.998 MiB/s; it proved the source valid but still incurred 329,551 strict validation calls. EVID-W001B-UTF8-003 A 1 GiB A/B test showed that reducing validated bytes alone was not enough: the selective per-run strategy submitted 115,839 bytes in 57,919 strict calls but took 503.7536 ms, while the baseline submitted 113,246,208 bytes in 27 strict calls and took 411.3590 ms. UNRESOLVED SOURCE DAMAGE: preserved authoritative text continues “This supported removing per-run general-validator call overhead rather than merely shrinking” but the remainder has not been recovered. No missing words are inferred or supplied. EVID-W001B-UTF8-004 The final native inline scan certified all 7,250,808,204 bytes in 10.377870 seconds at 666.313 MiB/s, observed 329,551 non-ASCII sequences and 659,103 non-ASCII bytes, and made zero std::str::from_utf8 calls. EVID-W001B-UTF8-005 The same inline design was exercised in Microsoft Edge/WASM with 4 MiB transfers: the valid 7,250,808,204-byte source completed with 1,729 pushes, UTF8_VALID=true, and EOF_ALL_BYTES_VALID. That experimental run took 30.5858 seconds including file I/O, JS-to-WASM copy, and WASM validation. EVID-W001B-UTF8-006 A full-size deliberately invalid Edge/WASM fixture stopped early after 2,936,012,800 bytes and 700 pushes with UTF8_VALID=false and STOP_REASON=INVALID_UTF8_SEQUENCE rather than reading to EOF. EVID-W001B-UTF8-007 WASM-001b also retained malformed UTF-8 fixtures for stray legacy bytes, truncated sequences, lone continuation bytes, overlong encodings, UTF-16 surrogate halves, and 0xFE/0xFF invalid bytes. WASM-002 should reuse or regenerate equivalent acceptance fixtures with known invalid offsets.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001,Stage 2 consumes the source instance certified by Stage 1,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The structural CSV parser and materializer operate under the explicit invariant that the same run-local selected source instance has already passed governed whole-file UTF-8 certification. Stage 2 must not independently re-resolve the analytical source. Stage 1 establishes encoding validity. Stage 2 establishes CSV structure, row identity, selected values, and governed outputs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.1,Stage 2 must not independently re-decide the source encoding.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.2,Stage 2 must not contain an automatic Windows-1252 fallback.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.3,Stage 2 may perform only those byte/character checks required for correct CSV structural parsing and frozen analytical semantics.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.4,"Any implementation shortcut that would weaken the certified-source invariant must be treated as a PRD change, not an optimization.",W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.5,Stage 2 restarts at byte offset zero of the same certified source instance,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"After Stage 1 returns PASS, Stage 2 must begin its structural pass from absolute source byte offset zero using the same run-local selected source instance. Rewinding/re-reading the existing source handle is permitted; performing a new filename, alias, path, picker, or directory resolution is not. If the host cannot re-read that same selected source instance for Stage 2, the Work Order must refuse under the run-local source-continuity contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.6,Stage 2 consumes an offset-zero UTF-8 BOM as metadata before header parsing,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"If the certified source begins with the UTF-8 BOM bytes EF BB BF , Stage 2 must consume those three bytes before parsing the first CSV header field. They must not become part of the first source header or selected value. The BOM is recognized only at absolute source offset zero. The fact that Stage 1 already saw the BOM does not permit Stage 2 to skip or reinterpret arbitrary later bytes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.7,Stage 2 parses the header once and then continues directly into the data-record scan,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Within the Stage 2 forward source scan, Data Sculptor must parse the complete first logical CSV record as the source header, construct ordered header metadata including exact decoded header text and 1-based source ordinal, resolve and validate all Work Order selectors/aliases, and then continue from the first data record without restarting the source. Header resolution therefore does not add a third whole-file pass. A header-only valid CSV yields a zero-row materialization; a source with no valid header record refuses. P3-09 no-header-record refusal: after Stage 1 has certified the source, if Stage 2 reaches end-of-source without establishing any logical CSV record from which a header could be parsed, materialization must refuse with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD . This is the eighth governed Stage-2 structural CSV refusal token in the canonical oracle defined by W002-MAT-002.8. Its governed location facts are: CSV_SOURCE_BYTE_OFFSET = exact source byte length; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; CSV_FIELD_ORDINAL: 1 . Therefore a zero-byte source reports offset 0 , and a source containing only the UTF-8 BOM bytes EF BB BF reports offset 3 . A first logical record that exists but is blank remains governed by the already-frozen BLANK_LOGICAL_RECORD condition and must not be reclassified as NO_HEADER_RECORD . F-20 source-width boundary: the established header record may contain at most 16,384 physical source columns. Exactly 16,384 is valid; a header record containing 16,385 or more fields must refuse deterministically during header resolution before the first data record is consumed. The bound applies to the complete physical source width, not merely the requested KEEP set. Header processing must remain bounded. Exact decoded source-header text is authoritative source evidence and must be preserved for every selected/materialized column, but the implementation is not required to retain the complete decoded text of every unselected header after selector resolution when bounded metadata is sufficient.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.8,Stage 2 relies on Stage 1 UTF-8 validity rather than revalidating the file,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 must not run a second whole-file UTF-8 certification algorithm over the source. It may inspect bytes and decoded field content only as required for CSV structure, header/selector semantics, governed field-size limits, output serialization, and diagnostics. Any implementation that reintroduces redundant whole-source UTF-8 validation into Stage 2 is a measurable architectural regression unless separately justified and accepted.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002,One-pass multi-column materialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"A valid Work Order may request multiple source columns for materialization during the same bounded structural pass. For WASM-002 DS-STEPS, the requested set is expressed by one KEEP block containing one or more HEADER and/or COLUMN selectors under W002-STEPS-001 through W002-STEPS-004. F-20 KEEP-width boundary: one governed KEEP block may resolve from 1 through 16,384 distinct source columns, subject to the source itself containing no more than 16,384 columns. An empty KEEP or a request that cannot resolve within that bound refuses before data-row materialization.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.1,Requested columns must be resolved and validated before data-row materialization begins,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Every HEADER and COLUMN selector in the governed KEEP block must resolve to exactly one source column before any data-row materialization begins. Missing headers, ambiguous duplicate-header matches, invalid/out-of-range ordinals, duplicate resolved selections, invalid aliases, and successor-MAP alias collisions must refuse before the structural data-row pass. The resolved selection cardinality must be an integer from 1 through 16,384 . Resolution/validation must finish before the first data record is consumed, including operational-name/default-alias derivation and any deterministic oversized-header fallback required by W002-STOR-019.7.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.2,All selected columns are emitted from one forward data-record scan,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"After header/selector resolution, Stage 2 must traverse the source data records once regardless of whether the Work Order selects one column or many. The engine must not perform one complete source rescan per requested column. During that scan, every source field is interpreted structurally, but only the fields required by the resolved selection set are materialized into governed COL outputs. F-20 one-pass boundary: “one forward data-record scan” means one traversal of the source data records for the MATERIALIZE operation. WASM-002 must not reread source data records in batches merely because the selected-column set is wide. An implementation may perform additional bounded passes over Data-Sculptor-owned SCR , spool, or staging structures after the source scan when needed to finalize many outputs within resource limits; such passes must not reread the source data records or change governed output semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.3,One 1-based logical row ordinal aligns every selected output,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The header is not a data row. The first accepted logical data record is row identity 1, the next is 2, and so on through N. The row counter advances exactly once per accepted logical CSV data record, not per physical line. Every selected COL produced by the run must contain exactly one logical data record for each accepted source data row and therefore exactly N data records in the same governed order. A multiline quoted field remains part of one logical record and must not advance row identity merely because it contains physical newline bytes. When the run establishes a new Store, this 1..N sequence is published as that Store's one governed RID artifact. When the run extends an existing Store without changing its row universe, the existing RID is reused and must not be regenerated or renumbered.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.4,Selected-column writer order follows resolved KEEP order,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Before the data-record scan begins, the validated selection set is placed in the same order in which its selectors appear in the governed KEEP block. That resolved order governs writer creation, per-row selected-field dispatch, progress/receipt presentation, deterministic backpressure-drain priority, and candidate COL identity allocation. The Store MAP's own CSV mapping-row ordering remains governed separately by W002-STOR-019.9 and must not be confused with Work Order selection order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.5,Multiple active COL outputs use bounded staging and explicit backpressure,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Each active materialized-column writer, or an equivalent shared multiplexed output structure, must have bounded staging capacity. The aggregate kernel-owned staging state for all active writers must remain inside the governed WASM memory budget and must not grow with source row count or total output size. If a required output writer cannot accept additional canonical bytes without exceeding its governed staging capacity, source consumption must pause while pending output is drained/written. When more than one writer requires service, drain priority follows resolved KEEP order. After sufficient space is available, parsing resumes from the same structural state. The exact tuned staging-buffer size is an implementation/benchmark constant rather than an analytical semantic constant; changing it must not change output bytes, row identity, selection results, or diagnostics for the same governed input. F-20 writer-resource bound: KEEP width and simultaneously active writable resources are distinct. The accepted build must declare a finite implementation bound on simultaneously active writable-output resources and retain acceptance evidence of both that configured bound and the observed peak. The engine may satisfy a wide selection by bounded shared/multiplexed staging or a Data-Sculptor-owned spool followed by bounded finalization passes, but it must not require one simultaneously open writer per selected column. Changing the writer-resource bound must not change final bytes, row order, selection identity, aliases, Receipts, or diagnostics for the same governed input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.6,Partial output sets are never published as a successful materialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"All requested materialized-column outputs begin as visible governed SCR candidates, not COL artifacts. On first materialization of a new Store, the automatically generated RID likewise begins as a governed SCR candidate. Before any new RID/COL SCR candidate is opened, Data Sculptor establishes one publication-transaction UTC under PB-STOR-013/PB-STOR-014 and allocates a distinct artifact-specific UUID for each new candidate. Each candidate filename therefore already carries the exact UTC, UUID, and final extension intended for that RID or COL identity. A materialization transaction may begin promotion only when every required RID/COL candidate reaches EOF successfully, all selected outputs reconcile to the same accepted data-row count N, and all required candidate finalization/validation succeeds. F-04 existing-Store cardinality gate: when materialization targets an existing VALID Store, after Stage 2 establishes the complete candidate logical data-row count N and before any requested COL candidate is promoted, Data Sculptor must read the expected N from the already-valid inherited RID header and compare the two values. If candidate N equals RID-header N , the cardinality gate passes and ordinary publication may continue. If candidate N differs, the Run must refuse before any SCR -to- COL promotion and before successor-MAP publication. The inherited RID, current MAP, and existing COL artifacts remain unchanged, and the existing Store remains VALID. Equal N proves cardinality compatibility only; it does not prove source-byte continuity, row-semantic identity, or permission for a different SOURCE to enter the lineage. Exact SOURCE/Store compatibility rules are prior gates. For a new Store, Data Sculptor promotes the validated RID candidate first by host rename that changes only the class token from SCR to RID ; the candidate bytes, shared transaction UTC, RID-specific UUID, and extension remain unchanged. That successful SCR-to-RID promotion is the event that establishes RID_ACTION: CREATED and the published RID_FILENAME fact for the Run. Before that promotion succeeds, the Run has not created a governed RID even if a candidate identity has been allocated. For an existing Store, the inherited RID is reused unchanged and no RID candidate/promotion occurs. Once routing has selected and validated that exact inherited RID, that event establishes RID_ACTION: REUSED and the exact inherited RID_FILENAME ; later refusal does not erase the already-established reuse fact. After the required RID state is established, Data Sculptor promotes each requested COL candidate in deterministic resolved KEEP order by changing only the class token from SCR to COL ; each candidate's bytes, shared transaction UTC, COL-specific UUID, and extension remain unchanged. If RID or COL promotion fails, Data Sculptor must refuse the run and roll any newly promoted RID/COL names back out of their final namespaces where safely possible. Candidate or rollback bytes that cannot be safely restored or removed must be retained visibly as non-authoritative SCR failure evidence. The existence of an unreferenced RID- or COL-looking file after interruption does not by itself make that artifact committed Store state. After all required RID/COL promotions succeed, Data Sculptor allocates a MAP-specific UUID before opening the complete successor-MAP SCR candidate. That candidate uses the same publication-transaction UTC, the allocated MAP UUID, and the final .csv extension, and is constructed using the exact final RID/COL filenames. It is closed successfully, reopened, and validated completely while it remains SCR . Only then may the MAP candidate be promoted by changing only the class token from SCR to MAP ; its bytes, UTC, UUID, and extension remain unchanged. The successful SCR -to- MAP rename is the materialization commit point. Until that commit point, the prior valid MAP remains authoritative for an existing Store; for a new Store, no committed Store state exists yet. If MAP validation or MAP rename fails, Data Sculptor must refuse and roll the newly promoted RID/COL set back out of the final namespaces where safely possible; otherwise affected bytes remain attributable recovery evidence and are not committed Store membership. Governed Store membership/current state is established by a valid MAP binding, not by a final-class filename or timestamp equality alone. Revision BB preserves the Revision AY staging/promotion mechanics and Revision AZ shared transaction-UTC rule for newly published RID/COL/MAP artifacts. Selected-folder support for the canonical governed filename/path form is established by the Suitcase Validation Certificate under W002-STOR-022 through W002-STOR-022.3 rather than by a frozen numeric host path-length table. Operation-specific host rename or publication failure remains a governed refusal under this requirement and is not pre-certified by Suitcase validation. F-14 shared candidate grammar, reconciled by F-33: every RID/COL/MAP SCR candidate in this transaction follows W002-STOR-023.1: its SCR name already carries the UTC, UUID and extension intended for the final RID/COL/MAP identity, and successful promotion changes only the class token. Any retained SCR candidates after a handled publication/rollback failure remain visible non-authoritative failure evidence under W002-STOR-023.1 and are reported through the governed diagnostic/Help path; WASM-002 does not emit an RCV manifest. An orphaned SCR remains non-authoritative even if its bytes later validate.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.7,Successful materialization publishes one complete Store MAP,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"A successful governed materialization that creates one or more COL artifacts must also publish exactly one new complete immutable Store MAP under W002-STOR-019 through W002-STOR-019.12. For a new Store, that MAP binds the automatically generated and promoted RID to the Store metadata and all newly materialized COL mappings. For an existing Store, it preserves the inherited RID binding and complete prior Store state while applying the successful materialization updates. All required RID/COL SCR candidates must complete and validate before promotion begins. On a new Store, RID promotion occurs first; on an existing Store, the inherited RID is reused unchanged. All requested COL promotions must then succeed before successor-MAP candidate construction begins. The complete successor MAP is written as SCR , closed, reopened, and fully validated before entering the MAP namespace. Its final host rename from SCR to the governed MAP filename occurs last and is the materialization commit point. The materialization run is not reported as successfully committed until that MAP rename succeeds. If MAP candidate validation or MAP rename fails after RID/COL promotion, the run must refuse and the newly promoted artifacts must be rolled back out of their final namespaces where safely possible. Any failure residue that cannot safely be removed or restored is governed by W002-STOR-023.1 and remains non-authoritative retained failure evidence; its survival must not be used to infer or manufacture attribution or to simulate the failed publication step. The prior valid MAP remains authoritative for an existing Store; no committed Store is established for a first materialization without a valid successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.8,Stage 2 enforces deterministic source-record shape,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The parsed header establishes the expected source field count. Every nonblank logical data record must contain exactly that many fields after CSV parsing. A nonblank ragged record with fewer or more fields must refuse rather than pad, truncate, or shift later values. An explicit empty field is valid data and preserves its ordinal. A bare blank logical data record occurring outside a quoted field must refuse and must not be silently skipped or converted into one empty field. A physical blank line inside a valid quoted multiline field is field content, not a blank record. F-06 canonical malformed-CSV refusal facts Every structural CSV refusal records these governed facts: REFUSAL_CONDITION
SOURCE_BYTE_OFFSET
PHYSICAL_LINE
LOGICAL_RECORD
FIELD_ORDINAL SOURCE_BYTE_OFFSET is the zero-based absolute byte offset from the first physical byte of the source file. A leading UTF-8 BOM, when present, occupies offsets 0–2 and therefore counts in subsequent absolute byte locations. PHYSICAL_LINE is one-based and equals one plus the number of LF bytes strictly before the governed refusal location. LF bytes inside quoted multiline fields still increment physical-line count. LOGICAL_RECORD is one-based CSV logical-record ordinal and includes the header as logical record 1. The first data record is therefore logical record 2. FIELD_ORDINAL is the one-based field position within that logical record. These facts describe the same first structural refusal regardless of permitted streaming-window size or boundary placement. Canonical structural refusal tokens The seven frozen F-06 malformed-CSV tokens are: UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD
INVALID_BYTE_AFTER_CLOSING_QUOTE
BARE_CR_OUTSIDE_QUOTED_FIELD
EOF_INSIDE_QUOTED_FIELD
BLANK_LOGICAL_RECORD
TOO_FEW_FIELDS
TOO_MANY_FIELDS P3-09 adds NO_HEADER_RECORD as the eighth governed Stage-2 structural CSV refusal token. Parser-library names, host exceptions, crate-specific error enums, or localized descriptions must not replace these governed tokens. Governed refusal location by condition Condition Governed refusal location UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD Offset of the offending "" byte. INVALID_BYTE_AFTER_CLOSING_QUOTE Offset of the first prohibited byte after the closing quote. BARE_CR_OUTSIDE_QUOTED_FIELD Offset of the CR byte itself. EOF_INSIDE_QUOTED_FIELD One-past-end offset, equal to the physical source byte length. BLANK_LOGICAL_RECORD First byte of the record terminator that proves the blank record: LF for LF termination; CR for CRLF termination. TOO_FEW_FIELDS First byte of the record terminator that closes the short record; at EOF, one-past-end offset equal to source byte length. TOO_MANY_FIELDS The comma delimiter that begins the first field beyond the expected header width. NO_HEADER_RECORD One-past-end offset equal to the exact physical source byte length, with physical line 1, logical record 1, and field ordinal 1, as frozen by W002-MAT-001.7. Field ordinal rules For TOO_FEW_FIELDS , FIELD_ORDINAL is the first missing field ordinal: expected-width position immediately after the last field actually present. For TOO_MANY_FIELDS , FIELD_ORDINAL is the first extra field ordinal: header-width + 1. For quote/CR/EOF structural conditions, FIELD_ORDINAL is the current field ordinal in which the malformed condition is established. For BLANK_LOGICAL_RECORD , FIELD_ORDINAL is 1. For NO_HEADER_RECORD , FIELD_ORDINAL is 1. Bare CR scope A bare CR outside a quoted field is malformed CSV and refuses with BARE_CR_OUTSIDE_QUOTED_FIELD . CR inside a valid quoted field is ordinary field content. LF inside a valid quoted field is ordinary field content. CRLF inside a valid quoted field is ordinary field content. Outside quoted fields, CRLF is one accepted logical-record terminator and LF is one accepted logical-record terminator. Outside quoted fields, a CR not immediately followed by LF is malformed. EOF while quoted If EOF is reached while the parser remains inside an open quoted field, the source refuses with EOF_INSIDE_QUOTED_FIELD . Data Sculptor must not synthesize a closing quote, truncate the field, reinterpret prior bytes as unquoted content, or otherwise repair the source. First-condition precedence Stage 2 evaluates structural CSV input in absolute source-byte order and reports the earliest refusal condition that becomes deterministically established. CSV grammar errors take precedence over later row-shape errors. BLANK_LOGICAL_RECORD takes precedence over TOO_FEW_FIELDS for a physically blank logical record. BARE_CR_OUTSIDE_QUOTED_FIELD takes precedence over INVALID_BYTE_AFTER_CLOSING_QUOTE when the post-quote offending byte is a CR that is not followed by LF. At EOF while still inside a quoted field, EOF_INSIDE_QUOTED_FIELD takes precedence over field-count evaluation. No implementation may choose a different error merely because of parser buffering, window boundaries, library behavior, or host platform. Delimiter boundary Comma remains the only WASM-002 field delimiter. Automatic delimiter detection is outside the WASM-002 CSV contract. A file whose rows contain semicolons, tabs, or other non-comma separators may still be valid under the comma-only grammar as a one-column CSV. Data Sculptor must not invent a malformed-CSV refusal merely because another application would treat those bytes as delimiters. When a requested HEADER cannot be resolved, Help may explain that WASM-002 uses comma as the CSV delimiter and that semicolon/tab exports may therefore be interpreted as one field per row. Interaction with UTF-8 diagnostics This structural CSV refusal oracle applies only after the source has passed the applicable encoding-certification boundary. Invalid UTF-8 remains governed by the separately frozen UTF-8 diagnostic contract. Its zero-based absolute source-byte orientation is intentionally aligned with SOURCE_BYTE_OFFSET so WASM-002 does not have competing byte-coordinate systems.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.9,Unselected field contents are not retained,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 must parse every field sufficiently to preserve CSV structure, field count, row boundaries, and governed safety checks, but it must not retain complete contents for unselected fields after those bytes are no longer structurally needed. The engine must not materialize a complete source row, complete table, or complete unselected column in memory merely to emit selected columns. Selected-field content may use bounded accumulation required by the frozen field-size/output rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.10,Individual decoded CSV fields are limited to 16 MiB,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"WASM-002 carries forward the established Data Sculptor field-buffer safety boundary: an individual CSV field may contain at most 16 MiB (16,777,216 bytes) of decoded UTF-8 field content. This is an engineering safety limit, not a semantic statement about CSV or an Excel cell limit. The limit must be enforced incrementally for header and data fields. The parser must not first accumulate an arbitrarily large field and then check it. If a field would exceed the limit, the run must refuse without truncating, repairing, discarding the remainder, or finalizing the candidate materialization. For an unselected field, Data Sculptor may count decoded field bytes without retaining the field value; the safety limit still applies so malformed unterminated fields cannot turn the structural scan into unbounded growth. F-20 operational column-name boundary: after an exact source header field is decoded, Data Sculptor measures its length in Unicode scalar values, not UTF-8 bytes or grapheme clusters. If the exact decoded source header contains at most 1,024 Unicode scalar values, its operational column name is that exact header text. If it contains more than 1,024 scalar values, the operational column name begins from the deterministic physical-ordinal fallback Column <LETTERS> , where the letters are the Excel-style 1-based source ordinal ( A through XFD for the WASM-002 width bound). This operational name is a bounded human-facing/default-alias construct; it does not replace or truncate the authoritative exact source header.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.11,Materialized COL artifacts use canonical one-column UTF-8 CSV serialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Each finalized materialized COL artifact is a one-column CSV. It begins with exactly one UTF-8 BOM ( EF BB BF ) and uses LF ( 0x0A ) as the record terminator on every supported host. The first logical record contains the exact decoded source header text for that physical source column; an alias assigned with AS lives in the governed MAP and does not rewrite the physical COL header. A deliberately empty source header is serialized as one explicit empty header field rather than as absence of a header record. Header and data fields use deterministic minimal CSV quoting: quote when the field contains comma, double quote, CR, or LF; double embedded double quotes; otherwise write the field without quotes. Embedded CR/LF that belong to a quoted field remain field content. For a one-column data record whose decoded value is the empty string, serialize the value explicitly as """" so the row cannot be confused with a bare blank logical record. For fixed source bytes and fixed governed semantics, changing input/output window boundaries must not change the finalized COL bytes. F-20 source-fidelity rule: the physical COL header record always serializes the exact decoded source header, even when that header exceeds the 1,024 -scalar operational-name boundary and the Store MAP/default alias therefore uses an operational fallback. The fallback name must never be substituted into the COL header record or into the MAP source_header field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003,Stage 2 processes the source through bounded reusable windows,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,Structural materialization must process the certified source through bounded reusable input windows compatible with browser/WASM memory constraints. Source size and row count must not require proportional WASM memory growth.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.1,"The 4 MiB WASM-001b window is a proven reference point, not a frozen production constant",W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The 4 MiB source window used successfully during the WASM-001b browser experiments is an evidence-backed starting/reference size. WASM-002 may tune the production input-window size using benchmark evidence, provided the governed memory budget and all window-invariance requirements remain satisfied.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.2,Changing source-window size or boundary placement must not change results,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"For the same certified source and Work Order, permitted changes in bounded Stage 2 input-window size or boundary placement must not change CSV interpretation, resolved headers/ordinals, accepted row count, row identity, aliases, canonical COL bytes, successor MAP contents apart from newly allocated physical identities/timestamps, or the first deterministic refusal condition. P3-09 window invariance: for a Stage-1-certified source containing no logical CSV record, every permitted Stage 2 window size and boundary placement must produce the same NO_HEADER_RECORD refusal and the same governed location tuple: source-byte offset equal to the exact source byte length, physical line 1, logical record 1, field ordinal 1. F-06 full refusal-oracle window invariance: for the same certified source bytes, changing any permitted Stage 2 input-window size or boundary placement must not change whether the source is accepted or refused; the first REFUSAL_CONDITION ; SOURCE_BYTE_OFFSET ; PHYSICAL_LINE ; LOGICAL_RECORD ; or FIELD_ORDINAL . This applies to every structural CSV refusal governed by W002-MAT-002.8.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.3,CSV structure must survive arbitrary input-window boundaries,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Input-window boundaries may occur between ordinary field bytes, delimiter bytes, quote/escaped-quote pairs, CR/LF record-ending bytes, inside quoted multiline fields, and inside already-certified multi-byte UTF-8 sequences. The Stage 2 parser must preserve equivalent structural meaning across those boundaries.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.4,Cross-window parser state is small and explicit,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 may carry only the bounded state needed to continue the current logical CSV parse, including the current logical row ordinal, current field ordinal, quoted/unquoted state, escaped-quote/quote-transition state as required by the parser, pending CR/LF state, decoded-field byte count, resolved selected-field dispatch metadata, and bounded selected-field/output staging. The parser must not retain previous complete rows or source windows merely because a CSV record crosses a window boundary.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.5,Input-window and output-drain sizes are independent implementation controls,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The source read window, WASM transfer window where applicable, selected-field accumulator bound, and output-drain window are separate controls. One must not be silently treated as the maximum for another merely because an earlier prototype used the same numeric value. Any tuning must preserve the Stage 2 memory, backpressure, byte, and window-invariance contracts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.6,Stage 2 uses direct structural parsing rather than a required structural sidecar,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The WASM-002 baseline performs its Stage 2 work directly from the certified source stream. It must not require a precomputed comma/quote/newline position map, binary structural index, hidden cache, or OPFS sidecar before materialization can proceed. The previously discussed structural-sidecar comparison remains a separate future experiment and must not be introduced into WASM-002 as an unmeasured dependency.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.7,The Stage 2 algorithm is browser-first shared Rust core behavior,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The structural parser, row-count semantics, selector dispatch, canonical field serialization, and bounded output-state machine defined by Stage 2 belong in the shared Rust semantic core proven through the browser/WASM path first. A later native CLI host must call the same governed core rather than reimplementing competing materialization semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001,Conversion is a separate governed operation,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Windows-1252-to-UTF-8 conversion is a distinct governed Work Order operation, separate from UTF-8 certification and separate from analytical materialization. The analyst must explicitly authorize it. The canonical WASM-002 form is: SUITCASE: .
WORK ORDER AS ""Convert legacy source to UTF-8""
SOURCE ""legacy_source.csv""
CONVERT WINDOWS-1252 TO UTF-8 CONVERT WINDOWS-1252 TO UTF-8 is the terminal operation clause. Exactly one SOURCE is permitted. The same WKO must not contain KEEP , MATERIALIZE , Store/RID/COL alias mutation, MAP , Inventory, repair, cataloging, Work Order composition, or another operation terminal clause. F-10 conversion entry precondition Before CONVERT WINDOWS-1252 TO UTF-8 may begin character transcoding, Data Sculptor must validate the complete bound source as strict UTF-8 under the same deterministic whole-source certification rules used elsewhere in WASM-002. If the complete source is already valid strict UTF-8, the conversion refuses as unnecessary and publishes no CVT . Only after complete strict UTF-8 validation reaches governed FAIL may Data Sculptor assess the same complete bound source against the frozen Windows-1252 compatibility mapping. Only a source that fails strict UTF-8 and passes the complete Windows-1252 compatibility assessment may proceed to conversion. A failed analytical Work Order, UTF-8 certification, or materialization never silently invokes this operation. The analyst must explicitly authorize the separate conversion WKO.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.1,A failed analytical Work Order must not automatically invoke conversion.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.2,The user must explicitly choose or submit the separate conversion task.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.3,The original source file must remain unchanged.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.4,Successful conversion must create a new UTF-8 artifact with its own governed identity and receipt/evidence.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002,Windows-1252 compatibility assessment,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"After strict whole-source UTF-8 certification returns FAIL , the current analytical operation remains refused and Stage 2 must not start. As refusal handling, Data Sculptor performs one separate read-only Windows-1252 compatibility assessment from physical byte offset 0 of the same run-local bound source instance. The compatibility assessment scans the complete source sequentially under W002-CONV-002.1 through W002-CONV-002.5. It does not transcode, publish a CVT, modify the analyst-owned source, resume materialization, or claim that Windows-1252 is the historical encoding. Its sole governed result is whether the entire byte stream is mappable by the frozen WASM-002 Windows-1252 converter. If strict UTF-8 certification returned PASS , or did not reach a governed FAIL conclusion, this compatibility assessment is not run. F-10 conversion classification gate The conversion operation itself repeats/executes the complete classification gate on its bound source before transcoding: validate the complete source as strict UTF-8; if strict UTF-8 passes, refuse conversion as unnecessary; only after strict UTF-8 fails, scan the complete source against the frozen Windows-1252 mapping; if any source byte is undefined or unsupported by that mapping, refuse rather than guess; and begin transcoding only when strict UTF-8 has failed and the complete Windows-1252 compatibility assessment has succeeded. An undefined/unsupported Windows-1252 byte is therefore a pre-transcoding compatibility-assessment refusal . No CVT candidate may be represented as successfully converted from a source whose compatibility scan found an undefined byte. The compatibility assessment must not substitute U+FFFD , reinterpret an undefined Windows-1252 byte as ISO-8859-1, or use permissive host/library decoder behavior to make an incompatible source convertible.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.1,Compatibility means that the supported deterministic converter can map the observed source bytes under the frozen Windows-1252 rules.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Compatibility means that every physical source byte can be mapped deterministically by the complete normative WASM-002 Windows-1252 mapping in W002-CONV-002.4 . Successful EOF produces the governed outcome COMPATIBLE . No statistical detector, locale rule, browser guess, replacement character, ISO-8859-1 substitution, best-effort decoder, or PRODUCT-scoped glossary text participates as normative authority in this determination.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.2,Compatibility must not be described as proof that Windows-1252 was historically or authoritatively the file's original encoding.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"COMPATIBLE means only that the complete byte stream is convertible under Data Sculptor's frozen Windows-1252 mapping. It must not be described as proof that Windows-1252 was historically, authoritatively, or intentionally the source file's original encoding.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.3,Bytes undefined by the frozen Windows-1252 mapping must cause the compatibility assessment or conversion task to refuse rather than guess.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"If the compatibility pass encounters a byte that W002-CONV-002.4 defines as undefined, the assessment stops at the first such byte and returns INCOMPATIBLE . Data Sculptor must not substitute a replacement character, reinterpret the byte under another code page, or continue as though conversion were safe. A later explicit conversion Work Order must apply the same complete WASM-002 mapping and the same refusal rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.4,Complete normative WASM-002 Windows-1252 byte mapping,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"This requirement is the complete normative Windows-1252 mapping authority for WASM-002 . It covers all 256 possible byte values. No PRODUCT-scoped glossary entry or host/library decoder is required to interpret compatibility or conversion. 0x00–0x7F Every byte 0x00 through 0x7F maps one-to-one to Unicode U+0000 through U+007F . 0x80–0x9F Byte Windows-1252 mapping Unicode 0x80 EURO SIGN U+20AC 0x81 UNDEFINED — 0x82 SINGLE LOW-9 QUOTATION MARK U+201A 0x83 LATIN SMALL LETTER F WITH HOOK U+0192 0x84 DOUBLE LOW-9 QUOTATION MARK U+201E 0x85 HORIZONTAL ELLIPSIS U+2026 0x86 DAGGER U+2020 0x87 DOUBLE DAGGER U+2021 0x88 MODIFIER LETTER CIRCUMFLEX ACCENT U+02C6 0x89 PER MILLE SIGN U+2030 0x8A LATIN CAPITAL LETTER S WITH CARON U+0160 0x8B SINGLE LEFT-POINTING ANGLE QUOTATION MARK U+2039 0x8C LATIN CAPITAL LIGATURE OE U+0152 0x8D UNDEFINED — 0x8E LATIN CAPITAL LETTER Z WITH CARON U+017D 0x8F UNDEFINED — 0x90 UNDEFINED — 0x91 LEFT SINGLE QUOTATION MARK U+2018 0x92 RIGHT SINGLE QUOTATION MARK U+2019 0x93 LEFT DOUBLE QUOTATION MARK U+201C 0x94 RIGHT DOUBLE QUOTATION MARK U+201D 0x95 BULLET U+2022 0x96 EN DASH U+2013 0x97 EM DASH U+2014 0x98 SMALL TILDE U+02DC 0x99 TRADE MARK SIGN U+2122 0x9A LATIN SMALL LETTER S WITH CARON U+0161 0x9B SINGLE RIGHT-POINTING ANGLE QUOTATION MARK U+203A 0x9C LATIN SMALL LIGATURE OE U+0153 0x9D UNDEFINED — 0x9E LATIN SMALL LETTER Z WITH CARON U+017E 0x9F LATIN CAPITAL LETTER Y WITH DIAERESIS U+0178 0xA0–0xFF Every byte 0xA0 through 0xFF maps one-to-one to Unicode U+00A0 through U+00FF . Undefined-byte rule The only undefined byte values in this frozen WASM-002 mapping are exactly 0x81 , 0x8D , 0x8F , 0x90 , and 0x9D . Encountering any one of them makes the complete compatibility assessment INCOMPATIBLE at the first such byte and causes an explicitly run conversion Work Order to refuse before transcoding rather than guess. These three ranges plus the 32-position table above exhaust the byte domain 0x00–0xFF . No unlisted byte value exists.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.5,The compatibility check must itself be bounded and deterministic.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"The compatibility check is one bounded-memory deterministic sequential pass from physical source byte offset 0 to EOF unless the first undefined Windows-1252 byte is encountered earlier. Buffer/window size must not change the compatibility outcome or the first undefined-byte offset. On INCOMPATIBLE , WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET is the zero-based absolute physical source-byte offset of the first undefined byte. On COMPATIBLE , that offset is NOT_APPLICABLE . If the assessment begins but an independent read/host failure prevents a governed compatibility conclusion, the outcome is NOT_AVAILABLE and the first-undefined-byte offset is NOT_AVAILABLE . The assessment itself publishes no converted output.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003,Help suggestion after failed UTF-8 certification,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Help may suggest the separate CONVERT WINDOWS-1252 TO UTF-8 Work Order only when the governed engine emits DS-CNV-001 after a complete compatibility assessment returned COMPATIBLE . The suggestion is therefore derived from a governed diagnostic fact, not from the UTF-8 failure itself. If the assessment returns INCOMPATIBLE , is NOT_AVAILABLE , or did not run, DS-CNV-001 is not emitted and Help must not invent the conversion recommendation. P3-08 Help disclosure: when conversion succeeds, Help must state that the published CVT is a new governed source artifact with its own source identity and that converting a refreshed legacy source later will publish another distinct CVT rather than refresh an earlier CVT-backed Store lineage. When a CVT is selected for first materialization, Help must disclose the same consequence before or with the normal materialization guidance: the Store lineage is anchored to the exact CVT filename, not to the analyst-owned pre-conversion filename. Help must not imply hidden lineage continuity across separate CVT artifacts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.1,The suggestion must state that the current analytical task has stopped.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must state that the current analytical task has already stopped/refused because strict UTF-8 certification failed. DS-CNV-001 is informational and must not be rendered as though materialization can continue from the failed run.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.2,The suggestion must state that the original source has not been changed.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must state that the compatibility assessment was read-only and that Data Sculptor did not change the analyst-owned source. Any later successful conversion publishes a separate governed CVT artifact rather than editing the original source in place.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.3,"The suggestion must describe the source as compatible with the supported Windows-1252 converter, not definitively identified as Windows-1252.",W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must describe the complete source as compatible with Data Sculptor's supported Windows-1252 converter . It must not say that the source was definitively identified as Windows-1252 or imply provenance that the compatibility pass cannot prove.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.4,The suggestion must make clear that conversion is a separate user-authorized task.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"The suggestion must make clear that conversion is a separate user-authorized Work Order. next_action: RUN_WINDOWS_1252_CONVERSION means that the separate operation is a governed safe option; it is not permission for Data Sculptor to silently transcode, modify the source, or reinterpret the refused analytical Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.5,"If the bytes are not compatible with the supported converter, Help must not recommend Windows-1252 conversion as though it were safe.",W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"If the compatibility outcome is INCOMPATIBLE , NOT_AVAILABLE , or NOT_RUN , Help must not recommend Windows-1252 conversion as though it were safe. In particular, the mere presence of DS-ENC-001 never authorizes that recommendation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004,Canonical conversion output,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"A successful Windows-1252 conversion task must produce canonical UTF-8 output suitable for later submission to the normal UTF-8 certification and materialization path. P3-08 lineage consequence: the successful conversion output is a new immutable governed CVT artifact with its own exact physical filename. That CVT filename is the source identity used by later Store routing. A later conversion, including one made from a refreshed analyst-owned legacy source with the same original filename, publishes a different CVT and therefore does not refresh, replace, or continue an earlier CVT-backed Store lineage merely by name association. On first materialization, each distinct CVT begins a new Store lineage unless that exact CVT filename already routes to an existing lineage under the normal Store rules. F-14 CVT identity and publication: the final converted-source filename is exactly __DS__CVT__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv . Conversion writes first to the corresponding W002-STOR-023.1 SCR identity with the same UTC, UUID and .csv extension. Only after bounded conversion completes, the candidate closes/reopens successfully, and the converted bytes satisfy the governed strict UTF-8 requirement may the class token be renamed to CVT . CSV structural interpretation remains governed by the later normal certification/materialization path; CVT publication does not assert that the converted source is structurally valid CSV. F-10 conversion semantics — encoding conversion only The conversion operation performs deterministic character transcoding only. It does not parse, repair, normalize, or reinterpret CSV structure. Commas remain commas. Double quotes remain double quotes. Ordinary ASCII bytes retain the same byte value. LF remains LF. CR remains CR. CRLF remains CRLF. Embedded CR/LF bytes are preserved in place; the converter does not decide whether they are record terminators or field content. Canonical UTF-8 output therefore means deterministic UTF-8 encoding of the accepted source characters, not normalization of line endings, quoting, delimiters, records, headers, or fields. F-10 BOM rule The published CVT is UTF-8 without a BOM ; Data Sculptor does not prepend EF BB BF . If the source failed strict UTF-8 classification, a leading source byte sequence EF BB BF is not blindly stripped as though it were a UTF-8 BOM. Under the Windows-1252 conversion path those source bytes are source data and are mapped according to the frozen Windows-1252 mapping. BOM interpretation remains subordinate to encoding classification rather than acting as a blind prefix-removal rule.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-010; CP-011,"CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open; CP011 T-ACCEPTED, GIT BANKED — CVT-to-SCR lexical staging-name pairing only; complete conversion requirement remains open",b7c515faa9bd000369d7656e09437310261290ae; e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,"Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived); Evidence/CP-011/CP011_Scope_Lock.txt; Evidence/CP-011/CP011_RED_Test_Output.txt; Evidence/CP-011/CP011_GREEN_Test_Output.txt; Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt; Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt; Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt; Evidence/CP-011/CP011_Hash_Inventory_Verification.txt; Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt; Evidence/CP-011/CP011_Closing_Git_Review.txt; CP011_Git_Banking_Output.txt (post-commit, separately preserved)","CP010 Day066 first-touches ONLY the F-14 canonical final CVT output filename grammar subconstraint: is_governed_cvt_source_filename_candidate(&str)->bool recognizes exact canonical __DS__CVT__<UTC>__<UUIDv4>.csv lexical form by reusing existing envelope validation. Four targeted tests + 40/40 full native regression PASS; wasm32-target build PASS; T accepted and banked b7c515faa9bd000369d7656e09437310261290ae. No encoding conversion, SCR creation, close/reopen, UTF-8 validation, CVT publication, immutable physical output, source authority, or CSV structural checks; entire W002-CONV-004 remains PARTIAL, independently unreviewed. CP011 Day066: public pure helper build_scr_candidate_filename_for_cvt(&str)->Option<String> accepts an exact canonical governed CVT .csv filename (via CP010 recognizer) and derives the paired SCR filename by substituting only class token CVT -> SCR, preserving exact UTC, UUIDv4 and lowercase .csv bytes; rejects wrong classes, paths, whitespace, malformed clock/date/UUID, extension and class case. Six targeted tests; RED expected E0432 exit 101; GREEN 6/6; post-format native regression 46/46; rustfmt recheck PASS; Rust 1.97.1 wasm32-unknown-unknown --lib build PASS; original 28/28 and combined 36/36 SHA-256 records verified. Two local scoped .gitattributes whitespace exceptions preserve Rustfmt/Git diagnostic TXT bytes; final Git staged check PASS. T-approved and Git banked e84ae5baeee05f9d5d30284c65b86eebba3c0f6a, 27 committed files, working tree clean. Lexical candidate-name pairing ONLY; no SCR creation, bytes, converter, transaction, close/reopen, validation/publication, retained SCR adoption, SOURCE authority or browser execution. Independent Claude implementation QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.1,The converted artifact must itself be certifiable as UTF-8.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.2,The conversion Receipt identifies the governed source encoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for a successful governed Windows-1252-compatible conversion must identify exactly SOURCE_ENCODING: WINDOWS-1252-COMPATIBLE . That operation-specific fact is carried within the canonical TXT Receipt governed by W002-RCP-001 through W002-RCP-010. Only that exact serialized spelling is permitted for this key/value pair.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.3,The conversion Receipt identifies the materialized UTF-8 encoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for a successful governed conversion must identify exactly MATERIALIZED_ENCODING: UTF-8 . This uses the canonical KEY: VALUE serialization frozen by W002-RCP-005. MATERIALIZED_ENCODING=UTF-8 is not valid canonical Receipt serialization.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.4,The conversion Receipt identifies bounded streaming transcoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for successful conversion must identify that transcoding was performed under the governed bounded/streaming conversion contract.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.5,No analytical column materialization occurs as part of this conversion operation.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001,Canonical diagnostic truth,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every governed user-visible failure or warning produced by WASM-002 must originate as a canonical diagnostic event. A diagnostic event must have a stable identity and structured facts independent of its final wording. Governed success/status events that participate in the Help/status/evidence system—such as a successfully saved Work Order or a successfully validated Suitcase—are canonical INFO diagnostic events and obey the same identity/fact/behavior contract. Ordinary static labels, headings, decorative copy, and presentation-only status text are not automatically diagnostics merely because they are visible in the UI.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.1,Canonical diagnostic IDs use the frozen DS-<DOMAIN>-<NNN> grammar,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry one stable identifier using the exact form DS-<DOMAIN>-<NNN> . DOMAIN is exactly three uppercase ASCII letters A through Z. NNN is exactly three decimal digits, zero-padded, in the range 001 through 999 . Examples include DS-ENC-001 , DS-WKO-001 , DS-STO-001 , DS-MAT-001 , and DS-HLP-001 . A diagnostic ID is permanent after allocation and must never be reused for a different diagnostic meaning. Severity, host, build/release, source filename, path, UUID, byte offset, row/column number, count, timestamp, occurrence ID, and other run-specific facts must not be encoded into the diagnostic ID; those values belong in structured diagnostic fields. The identifier is the canonical lookup key used by the Help message catalog. Day 060 H-04 pre-freeze identifier normalization: the Windows-1252 compatibility suggestion diagnostic is DS-CNV-001 . It follows the same exact three-letter DOMAIN grammar as every other diagnostic ID. No four-letter DOMAIN exception exists in the current WASM-002 contract. Any pre-H-04 draft spelling of this diagnostic is superseded and is not valid build-registry input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.2,Diagnostic severity uses one exact token set,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry exactly one severity token: INFO , WARNING , or ERROR . Severity classifies the condition for human and machine interpretation. It does not itself determine whether execution continues or refuses; that authority is carried separately by the canonical behavior field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.3,Diagnostic phase uses a stable uppercase token,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must identify the governed operation or phase using an uppercase ASCII snake-case token matching [A-Z][A-Z0-9]*(?:_[A-Z0-9]+)* . Examples include WORK_ORDER_VALIDATION , SOURCE_CERTIFICATION , MATERIALIZATION , STORE_PUBLICATION , and HELP_REPORT . These examples do not constitute a closed global phase list; the fixed phase for each allocated diagnostic is declared by that diagnostic's registry entry.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.4,Structured diagnostic facts are declared per diagnostic,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The canonical event carries diagnostic-specific evidence in a structured facts object. Fact keys use lowercase ASCII snake case matching [a-z][a-z0-9]*(?:_[a-z0-9]+)* . Each diagnostic registry entry declares disjoint required_facts and optional_facts sets. Every required fact must be present when that diagnostic is emitted. An optional fact key may be omitted when that fact is not emitted for the event, but omission itself has no governed absence-state meaning : it must not be interpreted as NONE , NOT_RUN , NOT_AVAILABLE , NOT_APPLICABLE , false , zero, or an empty string. An emitted fact key that is not declared for that diagnostic is invalid. For structured JSON diagnostic facts, an established ordinary value retains its native JSON type. When a present diagnostic fact must express one of the shared governed absence states, its value is the exact JSON string ""NONE"" , ""NOT_RUN"" , ""NOT_AVAILABLE"" , or ""NOT_APPLICABLE"" , with the meaning frozen by F-18. JSON null is not a generic encoding for diagnostic-fact absence; it is permitted only where a specific JSON schema explicitly declares a nullable field and defines what that null means, as W002-HELP-009 does for HLP lineage. A required diagnostic fact may not be silently omitted, defaulted, converted to null , guessed, or replaced by a Help-layer value. If Data Sculptor attempts to establish a registered diagnostic but cannot produce one or more facts declared required for that diagnostic, the intended diagnostic is not emitted . Instead the engine emits DS-HLP-001 under W002-HELP-001.8. The replacement event records the intended diagnostic ID and the complete sorted set of missing required fact names. No partially populated copy of the intended diagnostic may be presented beside it. This fail-closed substitution is a diagnostic-contract integrity rule, not a presentation fallback. It preserves the F-17 boundary that diagnostics own facts and Help renders only complete governed diagnostic truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.5,Execution behavior is explicitly CONTINUE or REFUSE,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry exactly one execution-behavior token: CONTINUE or REFUSE . This field is the governed continue/refuse decision for the event. Help wording, severity, UI color, or presentation must not independently weaken, strengthen, or reinterpret it.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.6,Safe next action uses a stable token rather than Help prose,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry a next_action token using uppercase ASCII snake case matching [A-Z][A-Z0-9]*(?:_[A-Z0-9]+)* . NONE is the canonical value when no safe governed next action applies. The token expresses stable machine-readable intent; Casual, Office Speak, and Technical wording for that action belongs to the Help layer. Run-specific values such as timestamps, paths, UUIDs, byte offsets, filenames, counts, or occurrence IDs remain structured facts and do not change the diagnostic identity or fixed next-action meaning. Damaged-Store guidance is part of the safe-next-action contract. When ordinary materialization refuses because exact source routing identifies an INVALID Store lineage, or a DEGRADED lineage whose every mapped COL is broken and therefore cannot be reduced to a non-empty successor by REPAIR MAP , the selected Help voice must preserve the same frozen choices and consequences rather than inventing a recovery operation. The explanation must identify the blocked lineage/current MAP and distinguish: external restoration under the original governed physical filename followed by the required governed validation tier; source rename to deliberately begin a separate new Store lineage; and analyst retirement of the damaged lineage by moving all of that lineage's Store MAPs out of the active Suitcase root. For retirement, Help must warn that moving only the latest MAP can expose an older structurally valid MAP as current. Help must not claim that matching the original filename proves historical byte identity, and must not describe any of these analyst filesystem actions as Data Sculptor-authored repair, deletion, RID regeneration, or silent lineage replacement. P3-07 malformed-MAP routing guard: when ordinary materialization refuses because no routable Store lineage can be established while one or more structurally malformed Store-MAP-class artifacts are present in the active Suitcase, Help must identify the malformed MAP artifact or artifacts and state that new-Store/RID creation was blocked to prevent a silent lineage fork. Help must not describe the missing structurally valid MAP as proof that the prior Store never existed, and must not invent a Data Sculptor repair or replacement operation for this condition. P3-10 delimiter-hint clarification: when Stage 2 refuses with INVALID_BYTE_AFTER_CLOSING_QUOTE and the offending byte is semicolon ( 0x3B ) or horizontal TAB ( 0x09 ), Help may include the governed delimiter-mismatch hint even though the refusal occurred before header-delimiter resolution. The hint is explanatory only: it must not change the canonical refusal condition, location facts, behavior, or safe-action boundary. F-16 conversion-suggestion boundary: strict UTF-8 refusal diagnostic DS-ENC-001 has fixed next_action: NONE . UTF-8 failure alone does not establish that any converter is safe. Only the separate compatibility diagnostic DS-CNV-001 , emitted after the complete governed Windows-1252 compatibility assessment returns COMPATIBLE , may carry next_action: RUN_WINDOWS_1252_CONVERSION . That token identifies a safe separately authorized option; it never resumes or rewrites the refused analytical Work Order. Day 060 H-12 damaged-lineage diagnostic binding ordinary MATERIALIZE refusal for a routed INVALID Store uses DS-MAT-014 and its declared facts; ordinary MATERIALIZE refusal for a DEGRADED Store whose every mapped COL is broken uses DS-MAT-015 and its declared facts; the no-routable-lineage / malformed-Store-MAP guard uses DS-MAT-016 and its declared facts. These specialized allocations are what permit closed-world Help to identify the blocked lineage/current MAP or malformed MAP artifacts without adding unrelated facts to the ordinary DS-MAT-010 validation diagnostic. Day 060 H-26 / BM-09 ordinary DEGRADED routing binding. When ordinary MATERIALIZE exact-source routing identifies a DEGRADED Store whose RID is valid and at least one mapped non-RID COL remains valid, the refusal uses DS-MAT-017 . Its fixed next_action is RUN_REPAIR_MAP because REPAIR MAP is the safe governed Store mutation for this repairable DEGRADED state. Help must use the diagnostic's declared current_map_filename as the exact MAP identity the analyst must name in the separate governed REPAIR MAP Work Order. The token does not run repair automatically and does not mutate the refused MATERIALIZE Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.7,"The governed engine emits the diagnostic semantic core, not voice-authored prose",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The shared Rust/WASM diagnostic path must provide the canonical semantic core required by Help: diagnostic_id , severity , phase , behavior , facts , and next_action . The fixed values and permitted fact-key sets for an allocated diagnostic are governed by diagnostics.json . Casual, Office Speak, and Technical prose belongs to the Help rendering layer rather than being duplicated as authored message sets inside the governed engine. Host/build/occurrence metadata may be carried by surrounding governed execution evidence, but it must not redefine the diagnostic semantic core. F-16 closed-world Help rule: Help may recommend the WASM-002 Windows-1252 conversion Work Order only when the governed engine emitted DS-CNV-001 . Help must not infer compatibility from DS-ENC-001 , byte appearance, file extension, locale, browser behavior, heuristic encoding detection, or prose outside the diagnostic facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.8,diagnostics.json is the canonical WASM-002 diagnostic registry build resource,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The human-inspectable development/build source for the WASM-002 diagnostic registry is exactly diagnostics.json , encoded as UTF-8 without BOM. It is Data Sculptor product/build content, not a Suitcase artifact; it must not use the __DS__ namespace, consume an artifact-class token, or be copied into an analyst's Suitcase merely because Data Sculptor runs. The top-level JSON object has exactly two fields: registry_version and diagnostics . registry_version is the string ""1"" . diagnostics is an array written in ascending UTF-8 byte order of diagnostic_id . Each diagnostic entry has exactly seven fields: diagnostic_id , severity , phase , behavior , next_action , required_facts , and optional_facts . Diagnostic IDs must be unique and satisfy W002-HELP-001.1. Severity, phase, behavior, and next-action values must satisfy W002-HELP-001.2 through W002-HELP-001.6. required_facts and optional_facts are arrays of canonical fact-key strings sorted in ascending UTF-8 byte order; keys must be unique within each array and the two arrays must be disjoint. {
  ""registry_version"": ""1"",
  ""diagnostics"": [
    {
      ""diagnostic_id"": ""DS-CNV-001"",
      ""severity"": ""INFO"",
      ""phase"": ""SOURCE_CERTIFICATION"",
      ""behavior"": ""CONTINUE"",
      ""next_action"": ""RUN_WINDOWS_1252_CONVERSION"",
      ""required_facts"": [""source_filename"", ""windows_1252_compatibility_outcome""],
      ""optional_facts"": []
    },
    {
      ""diagnostic_id"": ""DS-ENC-001"",
      ""severity"": ""ERROR"",
      ""phase"": ""SOURCE_CERTIFICATION"",
      ""behavior"": ""REFUSE"",
      ""next_action"": ""NONE"",
      ""required_facts"": [""first_invalid_byte_offset"", ""source_filename"", ""stop_reason""],
      ""optional_facts"": [""analytical_outputs_published"", ""materialization_started"", ""source_modified_by_data_sculptor"", ""store_state_committed""]
    },
    {
      ""diagnostic_id"": ""DS-HLP-001"",
      ""severity"": ""ERROR"",
      ""phase"": ""DIAGNOSTIC_ASSEMBLY"",
      ""behavior"": ""REFUSE"",
      ""next_action"": ""NONE"",
      ""required_facts"": [""intended_diagnostic_id"", ""missing_required_facts""],
      ""optional_facts"": []
    }
  ]
} The PRD does not need to enumerate every allocated WASM-002 diagnostic row. The complete registry delivered with the build is retained acceptance evidence. A diagnostic ID becomes permanent once allocated and must not later be reused for a different meaning. Build validation must fail on malformed JSON; extra/missing entry fields; duplicate or noncanonical diagnostic IDs; invalid fixed tokens; unsorted, duplicate, overlapping, or invalid fact-key declarations; engine diagnostic definitions whose fixed semantics disagree with the registry; engine diagnostic definitions absent from the registry; Help-catalog IDs absent from the registry; or Help placeholders that name facts not declared as required or optional by the matching diagnostic. F-07 DS-ENC-001 fact mapping: the canonical lower-case diagnostic facts for strict UTF-8 refusal are first_invalid_byte_offset , source_filename , and stop_reason . For this diagnostic, stop_reason is exactly INVALID_UTF8_SEQUENCE . The generic fact name byte_offset is retired for this UTF-8 refusal diagnostic. P2-03 clock-order diagnostic facts: whichever stable WASM-002 Diagnostic ID is allocated to refusal because a successor Store MAP or WKO MAP cannot satisfy the strict monotonic UTC publication guard must declare these exact lower-case required facts in its diagnostic-registry entry: map_profile , observed_host_utc , predecessor_map_filename , and predecessor_utc . map_profile has exactly two permitted values: STORE for a Store-MAP chronology guard and WKO for a Work-Order-registry-MAP chronology guard. These facts identify both the governed MAP profile, the blocking predecessor artifact, and the truthful clock observation that caused refusal. F-16 DS-CNV-001 allocation: DS-CNV-001 is emitted only when the complete read-only compatibility assessment under W002-CONV-002 through W002-CONV-002.5 reaches EOF with outcome COMPATIBLE . Its required fact windows_1252_compatibility_outcome is therefore exactly the JSON string ""COMPATIBLE"" . behavior: CONTINUE means this informational diagnostic introduces no additional refusal; it does not reverse the already-established DS-ENC-001 refusal or resume Stage 2. F-17 DS-HLP-001 allocation: DS-HLP-001 is the canonical fail-safe event when the engine cannot satisfy the complete required-fact contract of an intended registered diagnostic. intended_diagnostic_id is the exact canonical ID that was being assembled. missing_required_facts is a JSON array of every missing required fact-key string, sorted in ascending UTF-8 byte order with no duplicates. The intended diagnostic is suppressed rather than emitted incompletely. DS-HLP-001 always refuses and has next_action: NONE . F-22 QA-independence boundary: diagnostics.json is authoritative for the fixed semantic contract of an allocated Diagnostic ID — its ID, severity, phase, behavior, next action, and permitted required/optional fact keys — but the implementation-delivered registry is not, by itself, an independent oracle proving that every arbitrary runtime condition was mapped to the correct Diagnostic ID. WASM-002 does not require a second QA-owned registry duplicating every implementation allocation. Where this PRD independently freezes a condition-to-diagnostic mapping or exact required facts — including the named DS-ENC-001 , DS-CNV-001 , and DS-HLP-001 contracts and other explicitly pinned diagnostic facts — that PRD text remains normative and acceptance must test the mapping independently of the implementation registry. For allocations not independently pinned by the PRD, WASM-002 accepts the validated build registry as the build allocation while retaining all registry-shape, permanence, semantic-agreement, fact-discipline, and Help cross-validation gates. This is an explicit accepted QA-scope risk, not a claim of independent condition-to-ID verification. Day 060 H-02 fixture-pinned diagnostic allocations The following allocations are normative for the byte-exact Receipt acceptance corpus. They are genuine product diagnostics, not QA-only placeholder IDs. Every row has severity: ERROR , behavior: REFUSE , next_action: NONE , the phase shown below, the listed required facts, and an empty optional_facts array unless another requirement explicitly adds optional facts later. The existing DS-ENC-001 remains the Stage-1 invalid UTF-8 diagnostic and is reused by the H-02 Stage-1 compatibility-state fixtures. Diagnostic ID Severity Phase Behavior Next action Frozen meaning Required facts DS-WKO-001 ERROR WORK_ORDER_VALIDATION REFUSE NONE Work Order validation refuses before one of the seven governed operations can be identified. work_order_filename DS-MAT-010 ERROR MATERIALIZATION_VALIDATION REFUSE NONE Ordinary MATERIALIZE validation/routing refuses before Stage 1 begins after the source reference is established, excluding the specialized damaged-lineage and malformed-MAP routing conditions allocated by Day 060 H-12. source_filename DS-MAT-011 ERROR CSV_DECODING REFUSE NONE MATERIALIZE Stage 2 refuses on a governed structural CSV condition. source_filename csv_refusal_condition csv_source_byte_offset csv_physical_line csv_logical_record csv_field_ordinal DS-MAT-012 ERROR MATERIALIZATION_GATE REFUSE NONE MATERIALIZE post-Stage-2 gate refuses because existing-Store source cardinality does not match the inherited RID cardinality. source_filename base_map_filename rid_filename source_row_count rid_row_count DS-MAT-013 ERROR STORE_PUBLICATION REFUSE NONE MATERIALIZE governed Store-artifact filename identity allocation refuses after collision-retry exhaustion before any new Store artifact becomes authoritative. artifact_class collision_retry_count DS-INV-001 ERROR INVENTORY_VALIDATION REFUSE NONE INVENTORY validation refuses before the inventory scan begins. work_order_filename DS-INV-002 ERROR INVENTORY_SCAN REFUSE NONE INVENTORY scan/measurement refuses for an identified immediate Suitcase entry before a complete snapshot is established. entry_name DS-INV-003 ERROR INVENTORY_PUBLICATION REFUSE NONE INVENTORY governed INV filename identity allocation refuses after collision-retry exhaustion after the snapshot facts are established. artifact_class collision_retry_count DS-ALS-001 ERROR ALIAS_VALIDATION REFUSE NONE UPDATE ALIASES validation/routing refuses before an exact base Store MAP is established. work_order_filename DS-ALS-002 ERROR ALIAS_GATE REFUSE NONE UPDATE ALIASES refuses after the exact base Store MAP is established but before successor publication. base_map_filename DS-ALS-003 ERROR STORE_PUBLICATION REFUSE NONE UPDATE ALIASES successor-MAP filename identity allocation refuses after collision-retry exhaustion. artifact_class collision_retry_count DS-RPM-001 ERROR REPAIR_MAP_VALIDATION REFUSE NONE REPAIR MAP validation refuses before an exact target MAP/RID pair is established. work_order_filename DS-RPM-002 ERROR REPAIR_MAP_ANALYSIS REFUSE NONE REPAIR MAP analysis refuses before a complete repair result is established. target_map_filename DS-RPM-003 ERROR REPAIR_MAP_ANALYSIS REFUSE NONE REPAIR MAP deterministically refuses because every mapped COL is broken and retained COL count is zero. target_map_filename broken_col_count DS-RPM-004 ERROR STORE_PUBLICATION REFUSE NONE REPAIR MAP successor-MAP filename identity allocation refuses after collision-retry exhaustion after repair analysis is established. artifact_class collision_retry_count DS-WKR-001 ERROR WORK_ORDER_REGISTRY_VALIDATION REFUSE NONE REPAIR WORK ORDER REGISTRY validation refuses before the current structurally valid WKO MAP is established. work_order_filename DS-WKR-002 ERROR WORK_ORDER_REGISTRY_REPAIR REFUSE NONE REPAIR WORK ORDER REGISTRY repair-plan/gate processing refuses after the base WKO MAP is established. base_wko_map_filename DS-WKR-003 ERROR WORK_ORDER_REGISTRY_PUBLICATION REFUSE NONE REPAIR WORK ORDER REGISTRY successor-WKO-MAP filename identity allocation refuses after collision-retry exhaustion. artifact_class collision_retry_count DS-CVT-001 ERROR CONVERSION_VALIDATION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 validation/classification refuses before bounded transcoding begins. source_filename DS-CVT-002 ERROR CONVERSION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 refuses after bounded transcoding begins but before publication. source_filename DS-CVT-003 ERROR CONVERSION_PUBLICATION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 CVT filename identity allocation refuses after collision-retry exhaustion after conversion facts are established. artifact_class collision_retry_count DS-CAT-001 ERROR CATALOG_DISCOVERY REFUSE NONE CATALOG STORES validation/discovery refuses before the complete authoritative catalog row set is established. work_order_filename DS-CAT-002 ERROR CATALOG_PUBLICATION REFUSE NONE CATALOG STORES CAT filename identity allocation refuses after collision-retry exhaustion after the complete row set is established. artifact_class collision_retry_count Day 060 H-04 normalization: all allocated Diagnostic IDs in the current WASM-002 contract, including DS-CNV-001 , use exactly three ASCII uppercase letters in DOMAIN . No exception exists. Day 060 H-12 / BM-09 specialized diagnostic allocations The H-02 fixture diagnostics above are intentionally narrow. In particular, publication diagnostics whose required facts are only artifact_class and collision_retry_count mean identity-allocation collision exhaustion , not every possible publication failure. Other publication failures receive distinct registry allocations unless another requirement independently pins their Diagnostic ID. The following additional pre-freeze allocations are normative because existing Help duties require fact contracts that the broad H-02 fixture IDs cannot truthfully carry. Every row has severity: ERROR , behavior: REFUSE , and next_action: NONE except DS-MAT-017 , whose next_action is RUN_REPAIR_MAP . optional_facts is empty unless another requirement explicitly extends it. Diagnostic ID Severity Phase Behavior Next action Frozen meaning Required facts DS-MAT-014 ERROR MATERIALIZATION_ROUTING REFUSE NONE MATERIALIZE is blocked because exact source routing identifies a current INVALID Store lineage whose governed RID is missing or invalid. source_filename current_map_filename rid_filename store_health DS-MAT-015 ERROR MATERIALIZATION_ROUTING REFUSE NONE MATERIALIZE is blocked because exact source routing identifies a DEGRADED Store whose every mapped non-RID COL is missing or invalid, so REPAIR MAP cannot publish a non-empty successor. source_filename current_map_filename rid_filename store_health mapped_col_count broken_col_count DS-MAT-016 ERROR MATERIALIZATION_ROUTING REFUSE NONE New-Store creation is blocked because no routable Store lineage can be established while one or more structurally malformed Store-MAP-class artifacts are visible in the active Suitcase. source_filename malformed_map_filenames DS-MAT-017 ERROR MATERIALIZATION_ROUTING REFUSE RUN_REPAIR_MAP MATERIALIZE is blocked because exact source routing identifies a current DEGRADED Store whose governed RID is valid and whose mapped non-RID COL set contains at least one broken COL and at least one surviving valid COL, so a separate governed REPAIR MAP operation is available. source_filename current_map_filename rid_filename store_health broken_col_count DS-UTC-001 ERROR PUBLICATION_CHRONOLOGY REFUSE NONE A successor Store MAP or WKO MAP publication is blocked because truthful observed host UTC is not strictly greater than the canonical chronology predecessor UTC. map_profile observed_host_utc predecessor_map_filename predecessor_utc Day 060 H-26 / BM-09 allocation: DS-MAT-017 is the ordinary repairable-DEGRADED routing refusal. store_health is exactly DEGRADED ; broken_col_count is the exact number of mapped non-RID COL bindings that fail the applicable Store-health validation at this routing gate and is at least 1 . The condition excludes the all-COLs-broken case allocated to DS-MAT-015 . current_map_filename is the exact current structurally valid Store MAP that a separate REPAIR MAP Work Order must name. RUN_REPAIR_MAP is a safe next-action token only; it never causes automatic repair. Closed-world Help consequence: Help may render the richer damaged-lineage, malformed-MAP, and monotonic-UTC explanations only from the applicable specialized diagnostic event above. It must not borrow undeclared facts from DS-MAT-010 or from a collision-exhaustion publication diagnostic merely because those facts are available elsewhere at runtime. Cross-operation UTC rule: DS-UTC-001 has one stable semantic condition across Store-MAP and WKO-MAP successor publication. The required map_profile fact tells closed-world Help which governed MAP profile encountered the chronology guard: STORE means Store MAP and WKO means Work Order registry MAP. Help must select profile-appropriate explanation and analyst exits only from that declared fact and the other registered event facts; it must not infer the profile from filename shape, surrounding host state, or an undeclared operation field. The shared Diagnostic ID therefore does not need profile-specific clones.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002,Three-voice parity,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help Engine must support the three established Data Sculptor help voices. All three renderings must preserve the same diagnostic truth. Voice selection may change wording, sentence structure, degree of technical detail, and explanatory style. F-24 session default and persistence: Technical is the canonical Help voice at the start of every new browser application instance. The analyst may select Casual or Office Speak during that instance, but WASM-002 retains the selected voice only in volatile runtime state and does not persist the preference in browser-private storage. A new application instance therefore returns to Technical. This default does not alter the F-17 rule that a missing diagnostic-specific catalog entry visibly falls back to Generic Technical Help.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.1,Voice selection must not change diagnostic identity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.2,Voice selection must not change severity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.3,Voice selection must not change counts or evidence.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.4,Voice selection must not change whether execution continues or refuses.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.5,Voice selection must not change safe/unsafe action boundaries.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.6,Voice selection must not change provenance.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.7,Voice selection must not change the meaning of the recommended next step.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Tests must assert parity on the canonical event and structured facts, not brittle equality of prose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.8,One validated Help message catalog is the source of truth for all three voices,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help layer resolves a canonical diagnostic ID through one validated catalog that associates an authored ID with Casual, Office Speak, and Technical templates. The human-maintained development source is exactly help_messages.json , encoded as UTF-8 without BOM. help_messages.json is a Data Sculptor product/build resource, not a Suitcase artifact. It must not use the __DS__ governed artifact namespace, consume a semantic artifact-class token, or be copied into an analyst's Suitcase merely because Data Sculptor runs. Run-specific structured facts remain authoritative in the canonical diagnostic event and are supplied separately to the selected template. The three authored voices must not be maintained as unrelated message stores. F-17 coverage fallback: absence of an authored catalog entry for an otherwise complete registered diagnostic is permitted at run time and does not make the diagnostic incomplete. Data Sculptor must instead render the deterministic Generic Technical Help view defined by W002-HELP-002.9. The fallback consumes only the canonical event semantic core and its emitted governed facts; it is not a second message catalog and does not manufacture replacement diagnostic facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.9,WASM-002 may use mechanically generated placeholder voice text to prove Help wiring,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance does not require the complete production Help corpus. Authored catalog entries may use unmistakable placeholder strings, and placeholder entries may be generated mechanically from the validated diagnostics.json registry; no production prose authorship is required. Deterministic Generic Technical Help fallback. When a complete registered canonical diagnostic has no matching entry in help_messages.json , all selected Help voices fall back visibly to one Generic Technical rendering. The rendering must show, in this exact conceptual order, the diagnostic ID, severity, phase, behavior, next-action token, and then every emitted governed fact ordered by ascending UTF-8 byte order of fact key. It must state that no diagnostic-specific authored explanation is available. It must not infer cause beyond the diagnostic, invent remediation, default missing facts, inspect undeclared external state, or substitute prose for governed fact values. The Generic Technical fallback preserves the original diagnostic unchanged. Catalog incompleteness is therefore distinct from diagnostic incompleteness: a valid event can always be rendered generically, while inability to satisfy the event's own required_facts contract suppresses that intended event and produces DS-HLP-001 under W002-HELP-001.4 and W002-HELP-001.8. Acceptance must prove correct diagnostic-ID lookup, selected-voice resolution, structured-fact interpolation where a template exists, voice switching, deterministic Generic Technical fallback for a deliberately absent catalog entry, and semantic parity across authored voices. Final authored Help wording, examples, editorial polishing, and production-corpus quality remain deferred to a later Help-content milestone.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.10,help_messages.json has one deterministic WASM-002 source schema,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The top-level JSON object has exactly two fields: catalog_version and messages . catalog_version is the string ""1"" . messages is an array written in ascending UTF-8 byte order of diagnostic_id . Each message entry has exactly four fields: diagnostic_id , casual , office_speak , and technical . diagnostic_id must satisfy the canonical DS-<DOMAIN>-<NNN> grammar and must be unique in the catalog. Each voice field is a JSON string. A voice string may contain zero or more structured-fact placeholders using the exact form {fact_name} . Each catalog diagnostic_id must exist in the validated diagnostics.json registry, and each referenced placeholder must be declared in that diagnostic's required_facts or optional_facts . Duplicate IDs, missing voice fields, null voice values, malformed JSON, noncanonical or unregistered diagnostic IDs, or undeclared fact placeholders make catalog validation fail. The catalog is intentionally allowed to be non-exhaustive. A registered diagnostic with no message entry is rendered through the deterministic Generic Technical fallback in W002-HELP-002.9. Therefore a missing catalog entry for a registered diagnostic is not a build-validation failure and must not cause the engine to synthesize an authored entry or suppress the diagnostic. WASM-002 therefore does not require one global exhaustive fact-name table in the PRD. Fact-key authority is per diagnostic: the validated registry declares which fact names are legal for each stable diagnostic meaning. {
  ""catalog_version"": ""1"",
  ""messages"": [
    {
      ""diagnostic_id"": ""DS-ENC-001"",
      ""casual"": ""[CASUAL PLACEHOLDER] {source_filename}"",
      ""office_speak"": ""[OFFICE PLACEHOLDER] {source_filename}"",
      ""technical"": ""[TECHNICAL PLACEHOLDER] {source_filename} {first_invalid_byte_offset} {stop_reason}""
    }
  ]
} Later Help-content revisions may extend or version this schema only through an explicit PRD revision. F-07 placeholder mapping: Help for the strict UTF-8 refusal may render {first_invalid_byte_offset} and {stop_reason} because those exact fact names are declared by the canonical DS-ENC-001 diagnostic registry entry. The older generic {byte_offset} placeholder is not valid for DS-ENC-001. P2-03 Help rendering duty: Help for the monotonic-UTC refusal must identify the exact blocking predecessor MAP and show both predecessor UTC and truthful observed host UTC. It must distinguish an incorrect host clock from a genuinely future-dated governed MAP and may explain the approved analyst-owned choices: correct the clock, wait/rerun after truthful time advances, or deliberately move the exact future-dated current MAP out of the active Suitcase root with the warning that an older snapshot/registry may become current and that restoring the moved MAP may restore its authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.11,The validated Help catalog is embedded into the released HTML build and supplied to the shared core,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Before a WASM-002 browser build is accepted, the build must parse and validate help_messages.json , then serialize the validated catalog directly into the Data Sculptor HTML itself as one non-executable application/json payload with the exact element ID ds-help-catalog . The embedded JSON must be HTML-safe so catalog text cannot terminate the containing script element; at minimum, literal less-than characters in JSON string content must be escaped during embedding. At runtime, the browser host obtains this embedded payload and supplies the validated catalog to the shared Rust/WASM Help core. Browser JavaScript must not implement a competing template-selection, fact-interpolation, fallback, escaping, or HLP-semantic engine. The browser host must not fetch a Help catalog from the network, the filesystem, the Suitcase, or an adjacent deployment file. Missing or malformed embedded catalog JSON, or a build whose embedded catalog does not correspond to the validated build input, is a build-validation failure. The released HTML therefore remains one offline portable front door for the browser Help catalog. A later native host may supply the same governed catalog semantics to the same shared core from its own build-bundled resource; host packaging may differ, but Help semantics must not fork.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003,Message and report outputs,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The Help Engine must support both live and durable help surfaces.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003.1,The Help Engine must support a concise human-facing message suitable for the live browser surface.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The concise message is rendered in the dedicated browser Help / Diagnostic Surface when that surface is present; it is not required to be a modal or transient notification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003.2,"The Help Engine must support a durable HTML Help report using the canonical built-in Data Sculptor presentation suitable for saving with the Work Order, receipt, and output artifacts.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"A concise Help message for an individual diagnostic and any durable Help Report that includes that diagnostic must resolve from the same canonical diagnostic event. A durable Help Report request may cover one active governed diagnostic, including a non-run diagnostic, or one governed run containing one or more canonical diagnostic events. Exactly one HLP is published for each explicit Help Report request.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004,HTML Help report content,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,A saved Help report must be able to include the following elements when relevant.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.1,Product and brand identity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.2,Plain-language summary.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.3,Stable diagnostic ID.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.4,What Data Sculptor observed.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.5,Evidence and structured facts.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.6,What the user can safely do next.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.7,Source/Work-Order context is governed by the HLP disclosure allowlist.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The report may include only source and Work Order context permitted by W002-HELP-010. Durable HLP disclosure is intentionally stricter than transient local Help because the HLP is a portable support-handoff artifact. A relevant governed alias or source header may enter the HLP only under the necessity and disclosure rules in W002-HELP-010. Source-header text is eligible only when Data Sculptor has structurally established an actual CSV header record under the governed parser. Record position alone does not make text a header. When no valid header record has been established, including the headerless-source refusal case, the HLP must use structural evidence such as the 1-based column ordinal, diagnostic condition/location, or an applicable operational fallback name and must not substitute field data from the first data row. Absolute local paths, entire Work Orders, Work Order comments, source rows/values, unrelated headers/aliases/columns, and unrelated Suitcase contents are not automatically eligible merely because they are available to the running application.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.8,Report-generation metadata preserves HLP identity and lineage.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The report must carry its own governed HLP filename and generation UTC together with the diagnostic identity and applicable originating execution lineage. The exact HLP provenance contract is governed by W002-HELP-009.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.9,Selected Help voice and its human-facing explanation.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.10,A clearly labelled structured-facts block derived from the canonical diagnostic event.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.11,Four canonical Boolean facts describe the WASM-002 execution boundary.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When the governed diagnostic context can determine the execution boundary, the canonical fact names are exactly: source_modified_by_data_sculptor materialization_started analytical_outputs_published store_state_committed When one of these facts has an established Boolean value, the JSON/structured value is the native Boolean true or false , never the strings ""TRUE"" or ""FALSE"" . source_modified_by_data_sculptor states only whether Data Sculptor modified the analyst-owned source in place; it must not imply knowledge that no external process or analyst changed the source between sessions. materialization_started records whether the governed analytical materialization phase began. analytical_outputs_published records whether governed analytical outputs were successfully published for user use; transient SCR candidates or abandoned/uncommitted debris do not make this fact true. store_state_committed records whether the successor Store MAP commit point was crossed. If a present boundary fact must express governed absence rather than an established Boolean, its JSON/structured value is the exact applicable shared absence-state string ""NONE"" , ""NOT_RUN"" , ""NOT_AVAILABLE"" , or ""NOT_APPLICABLE"" . JSON null is not a valid encoding for these four boundary facts because it would discard the reason for absence. A boundary fact that is optional for a particular diagnostic may instead be omitted under W002-HELP-001.4; that omission carries no absence-state meaning. A missing, omitted, unavailable, or not-run fact must never be interpreted as false . If one of these facts is declared required for an intended diagnostic and the required value cannot be produced, it must not be silently defaulted; the intended diagnostic is suppressed and the fail-safe DS-HLP-001 contract in W002-HELP-001.4/W002-HELP-001.8 applies.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.12,Governed Work Order lineage sufficient to establish user intent.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,Included lineage must obey the disclosure boundary defined for Help reports and must not automatically expand into source-data disclosure.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-005,Deterministic rendering uses a closed governed input set,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Given the same canonical diagnostic event or ordered set of events, selected voice, PRETTY rules, validated Help catalog, and built-in presentation version, Help rendering must be deterministic except for explicitly permitted event/report-specific fields. The Help renderer may consume only the canonical diagnostic fields and fact keys declared by the applicable diagnostic registry entries plus fields explicitly defined by the applicable HLP provenance schema. It must not inspect or interpolate an open-ended host-state bag, undeclared browser state, unrelated Suitcase contents, or another value merely because it is available at runtime. A future configurable Brand Manifest may add another governed presentation input, but it is not part of the WASM-002 rendering contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-006,Host parity uses one shared Help semantic core,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help Engine must be designed for use by the browser host and the later native CLI host without changing diagnostic semantics. The shared Rust core owns diagnostic-to-template selection, governed fact interpolation, deterministic fallback behavior, governed escaping, and durable HLP semantic serialization. The WASM-002 browser host supplies the validated catalog embedded under W002-HELP-002.11. A later native host may supply the same governed catalog semantics from a build-bundled native resource. Host-specific presentation and packaging may differ, but they must not create a second Help semantic engine or change canonical diagnostic identity, facts, behavior, next action, voice semantics, disclosure policy, or HLP meaning.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-007,"Help surfaces are projections, not diagnostic authority",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The live Help / Diagnostic Surface and the saved HTML Help Report must render from the canonical diagnostic event. Neither surface may independently create, reinterpret, weaken, suppress, or override governed diagnostic truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008,HTML Help Report is a governed support-handoff artifact,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The user must be able to generate a styled, self-contained HTML Help Report from a governed diagnostic event for retention, IT/support handoff, or communication to another analyst. The report must support two audiences in one document: a human-readable explanation using the selected Help voice and a clearly inspectable structured-facts section that preserves the technical evidence required to understand the event.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008.1,"The report preserves the canonical execution-boundary facts, including relevant negative facts.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When relevant to the diagnostic, the report must render the governed values of source_modified_by_data_sculptor , materialization_started , analytical_outputs_published , and store_state_committed . These values originate from governed execution state rather than reassuring prose invented by the renderer. A missing/unavailable fact is not rendered as false .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008.2,The report preserves only the Work Order lineage needed to explain the diagnostic.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The report must identify the originating WKO physical filename when one applies and may include only the minimum executable Work Order clause or clauses needed to establish the governed operation, user intent, and trigger for the diagnostic. It must not automatically embed the entire Work Order or Work Order comments. All such context remains subject to the fixed disclosure boundary in W002-HELP-010.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-009,"WASM-002 establishes HLP identity, lineage, multiplicity, and one canonical embedded provenance payload.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"A durable generated Help Report is an immutable governed HLP artifact whose physical filename is: __DS__HLP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html The UTC token is the HLP's own governed generation/publication time. The report is the final self-contained HTML artifact using the canonical built-in Red5Sorcery/Data Sculptor presentation; no unstyled intermediate is the canonical HLP. Report-request multiplicity: one explicit Help Report request publishes exactly one HLP. The request may be bound to one active governed diagnostic, including a diagnostic that is not associated with a Run, or to one governed Run containing one or more canonical diagnostic events. A Run-level report includes the governed diagnostic events selected by that request in deterministic event order. HLP generation is never an automatic one-artifact-per-diagnostic side effect. Every HLP must expose a visible deterministic Provenance section and exactly one embedded non-executable application/json payload whose element ID is exactly ds-hlp-provenance . F-34 supersedes the earlier draft schema version ""1"" . For schema version ""2"" , the JSON top-level object contains exactly these ten fields: {
  ""schema_version"": ""2"",
  ""hlp_filename"": ""__DS__HLP__20260922T191500123Z__<uuid-v4>.html"",
  ""hlp_generation_utc"": ""20260922T191500123Z"",
  ""diagnostic_ids"": [""DS-ENC-001"", ""DS-MAT-004""],
  ""originating_wko_filename"": ""__DS__WKO__...txt"",
  ""originating_rcp_filename"": null,
  ""selected_help_voice"": ""technical"",
  ""presentation_id"": ""red5sorcery-data-sculptor"",
  ""presentation_version"": ""1"",
  ""data_sculptor_build"": ""<exact-build-id>""
} hlp_generation_utc must use the canonical fixed-width millisecond UTC form YYYYMMDDTHHMMSSmmmZ . diagnostic_ids is a non-empty JSON array containing one canonical diagnostic ID for each diagnostic event included in the report, in the same deterministic event order used by the report. Repeated IDs are permitted when distinct included events legitimately share one diagnostic type. selected_help_voice is exactly one of casual , office_speak , or technical , matching the Help catalog keys. For WASM-002 the built-in presentation identity is exactly red5sorcery-data-sculptor and its presentation version is exactly ""1"" . data_sculptor_build must contain the exact running build identifier used for the tested/released build; the literal scope label WASM-002 alone is not sufficient unless it is also the exact build identifier. originating_wko_filename and originating_rcp_filename are schema-declared nullable lineage fields . When the relationship exists and the exact physical filename is known, the value is that filename as a JSON string. When the relationship itself does not apply to this Help event/report request, the machine-readable value is JSON null . That null has one schema-defined meaning: the nullable relationship has no value, equivalent to Rust Option<T>::None and to the governed semantic state NOT_APPLICABLE . The visible Provenance section renders it as NOT APPLICABLE . If the lineage relationship does apply but the exact filename cannot be obtained, JSON null must not be used; the field value is the exact string ""NOT_AVAILABLE"" and the visible Provenance section renders NOT AVAILABLE . Empty strings, invented lineage, N/A , UNKNOWN , or another substitute are forbidden. For these two lineage fields, null and ""NOT_AVAILABLE"" are deliberately non-interchangeable. A non-run HLP may therefore legitimately carry JSON null for both lineage fields when neither relationship applies. This nullable-field rule is a schema-specific serialization choice, not a fifth absence state and not a generic JSON encoding rule. Other diagnostic JSON facts follow W002-HELP-001.4 and W002-HELP-004.11. The visible and machine-readable HLP provenance must express the same governed semantics even where their physical representations differ; a semantic mismatch is an HLP-generation failure and must not be silently tolerated. The embedded JSON must be HTML-safe so provenance text cannot terminate the containing script element; at minimum literal less-than characters in JSON string content must be escaped during embedding. The provenance payload remains subject to W002-HELP-010 and must not introduce source rows, source values, absolute local paths, arbitrary Work Order content, or other context excluded by the fixed HLP disclosure policy. WASM-002 does not automatically compute or embed a SHA-256 of the HLP, and saving an HLP must not create, refresh, or verify an LCK . The final HLP bytes remain eligible for exact-byte integrity evidence under the later explicit FINGERPRINT/LCK workflow. Configurable Brand Manifest provenance remains deferred to V1-BACKLOG / a future build. F-14 HLP publication: the complete self-contained report is first written as the corresponding SCR candidate under W002-STOR-023.1. It must close, reopen, and validate the required visible Provenance section, exact schema-version-2 embedded JSON shape, HTML-safe serialization, self-contained presentation and visible/machine semantic parity before the class token may be renamed from SCR to HLP . A partial or semantically mismatched candidate never becomes a canonical HLP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-010,Help Report disclosure uses one fixed WASM-002 allowlist.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Generating a Help Report must not silently become a data-export path. WASM-002 therefore uses one deterministic allowlist rather than collecting broad context and attempting to redact it afterward. There are no disclosure checkboxes, permissive export modes, or per-report overrides in WASM-002. Always eligible when present and applicable: diagnostic ID; severity/classification; governed operation/phase; continue/refuse decision; safe next action; selected Help voice; HLP identity and generation UTC; relevant governed artifact filenames; and the four canonical boundary facts from W002-HELP-004.11. Eligible only when necessary to explain the diagnostic: the exact source filename but not an absolute OS path; a relevant source column header only when Data Sculptor has structurally established an actual CSV header record; the relevant 1-based column number; a relevant governed Store/RID/COL alias only when that alias itself is necessary to explain the diagnostic, such as an alias collision, ambiguity, or governed alias mutation; byte offset, row/count, or byte-length evidence; Store/RID/COL/MAP/WKO physical filenames; and only the minimum executable Work Order clause or clauses needed to establish intent and the diagnostic trigger. If that minimum Work Order excerpt necessarily contains a governed alias, that alias is disclosed and counts as alias text included. Headerless boundary: record position alone never establishes a source header. If the governed parser has not established a valid header record, including a headerless-source refusal, HLP generation must not treat any field from the first data row or any later data record as header text. Structural evidence such as 1-based column ordinal, governed diagnostic/location facts, or an applicable operational fallback name must be used instead. Never included automatically: source rows; source field values or arbitrary data samples; field data mislabeled as header text; absolute local paths; unrelated source headers, aliases, or column names; the complete Work Order; Work Order comments; unrelated Suitcase contents; browser/environment internals not governed as diagnostic evidence; or raw ungoverned stack traces. Every generated HLP must contain a visible Disclosure section stating, at minimum: Source rows included: NO ; Source values included: NO ; Source header text included: YES or NO ; Governed alias text included: YES or NO ; Absolute local paths included: NO ; Work Order comments included: NO ; and Work Order excerpt: RELEVANT EXECUTABLE CLAUSES ONLY . The two YES/NO declarations must truthfully reflect the actual HLP bytes. A genuine established source header does not count as a source field value; this distinction applies only after the governed parser has established the header record. The renderer must not weaken any declaration when the underlying policy has not changed. This durable-HLP allowlist does not prohibit transient local Help from showing a relevant governed alias or a genuinely established source header when useful to explain the same canonical diagnostic event. Local presentation does not enlarge what the portable HLP may disclose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011,Help owns the cross-session source-continuity edge-case explanation,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When an unexpected analytical result, row-alignment concern, or support question raises the possibility that an analyst-owned source changed between sessions, Data Sculptor-controlled guidance must flow through the Help Engine. Help must not imply that the engine monitored or cryptographically protected the source when it did not. The explanation must distinguish ordinary analyst-controlled workflow from stronger optional evidence. It may ask whether the analyst edited, replaced, sorted, re-exported, synchronized, copied over, or otherwise changed the source after the Store was established.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011.1,Help presents continuity evidence in explicit assurance levels,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"For a suspected cross-session source change, Help must distinguish at least these evidence levels: No continuity evidence: state that cross-session byte continuity cannot be independently verified from filename/Store metadata alone. INVENTORY available: use filename, exact byte length, and last-modified metadata as lightweight clues; changed metadata may indicate that the source changed, while unchanged metadata must not be presented as proof of unchanged bytes. Explicit fingerprint evidence available: exact-byte SHA-256 evidence may establish whether the compared file bytes match or differ under the later governed FINGERPRINT workflow. Help must not collapse these levels into one generic statement of certainty.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011.2,WASM-002 does not impose automatic cross-session hashing or Suitcase surveillance,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Ordinary WASM-002 materialization and Store inheritance must not automatically SHA-256 the source, recursively fingerprint the Suitcase, or maintain hidden whole-Suitcase surveillance merely to guard against the possibility that an analyst-owned file changed between sessions. This is an intentional product boundary for the lone-office-analyst model. The product assumes the analyst normally controls the Suitcase, provides lightweight explicit INVENTORY evidence in WASM-002, preserves a later explicit FINGERPRINT path for stronger assurance, and relies on Help to explain unusual cross-session continuity questions proportionately. WASM-002 must not create, refresh, or silently verify an LCK Suitcase Lock as a side effect of Work Order save, materialization, Store inheritance, INVENTORY, alias maintenance, or ordinary project use. LCK publication belongs to the explicit later-V1 FINGERPRINT workflow. F-13 single-writer Help boundary: Help must distinguish cross-session continuity from concurrent writing. WASM-002 does not claim that two Data Sculptor tabs/windows can safely write the same Suitcase at once. User guidance must say to use one writing Data Sculptor context per Suitcase; read-only viewing is not itself a governed write. When a pre-commit guard detects that relevant governed state changed underneath an operation, Help must identify the changed authority where available and direct the analyst to refresh or reopen current state and rerun deliberately. It must not imply that Data Sculptor acquired a cross-tab lock, merged the competing work, or automatically rebased the refused transaction.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-001,Separation of truth and presentation,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,The PRETTY Engine must not decide analytical truth or reinterpret diagnostic meaning. It receives governed content and renders it into human-facing artifacts. WASM-002 conceptual boundary: ENGINE TRUTH -> HELP / REPORT CONTENT -> PRETTY ENGINE -> BUILT-IN DATA SCULPTOR PRESENTATION -> ARTIFACT. A future build may replace the built-in presentation source with a governed Brand Manifest without changing the analytical or diagnostic truth supplied to PRETTY.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-002,Shared renderer path,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"The PRETTY Engine must provide a common rendering path for Data Sculptor artifacts that require governed human presentation, including at minimum the WASM-002 Help HTML report. WASM-002 uses the canonical built-in Red5Sorcery/Data Sculptor presentation. The architecture must permit the same path to accept a configurable Brand Manifest in a future build without changing analytical semantics. The architecture must also permit later reuse for branded Receipt HTML, verification reports, tables, Quick Viz, and other PRETTY outputs. WASM-002 canonical run Receipts themselves remain TXT-only under W002-RCP-003.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003,Self-contained HTML,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"Durable HTML artifacts produced by PRETTY must be self-contained for ordinary viewing after generation. Self-containment requires semantic and functional portability, not pixel-identical rendering across operating systems or browsers; ordinary system-font substitution and browser rendering differences are acceptable when meaning, evidence, hierarchy, and accessibility remain intact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.1,A saved artifact must not require a network connection.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.2,A saved artifact must not require an external stylesheet.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.3,A saved artifact must not require a remote font.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.4,A saved artifact must not require a separately located logo file.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.5,A saved artifact must not require external presentation resources.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"Required CSS, SVG, and other built-in presentation assets needed for ordinary viewing must be embedded or otherwise resolved into the generated artifact at creation time. Future configurable Brand Manifest inputs, when implemented, must preserve this self-contained output rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-004,Accessibility and inspectability,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"PRETTY HTML must remain ordinary inspectable HTML. Presentation must not obscure the text, evidence, diagnostic code, provenance, or next-step guidance. The rendered artifact must remain usable without JavaScript when JavaScript is not required for its content.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-QA-001,Governed test-only seams and acceptance coverage,W002-QA,W002-QA,WASM-002,UNDER REVIEW,—,"Every material frozen WASM-002 behavior must have retained acceptance evidence sufficient to exercise the governed success, refusal, mutation, publication, or recovery boundary that makes the behavior meaningful. Related cases may share one fixture when the shared fixture proves each required condition explicitly; acceptance coverage must not rely on a behavior being difficult to reproduce under an uncontrolled host environment. Permitted deterministic test-only seams. WASM-002 acceptance may use controlled clock values; controlled UUID sequences and collision outcomes; controlled filesystem create/write/close/rename/promotion failures; and controlled run-local source-handle reread/substitution conditions. A seam supplies only the external condition required to reach the governed behavior. It must not bypass validation, alter the normative semantic result, change governed serialization, relax publication rules, rewrite diagnostic truth, or create a second analytical execution model. Release boundary. Test-only controls must not be invocable through the ordinary Data Sculptor UI, DS-STEPS, saved Work Orders, URL/query parameters, Suitcase configuration, or another analyst-facing product path. Compile-time exclusion, test-build configuration, or an isolated acceptance harness are permitted implementation techniques. Retained acceptance evidence must identify any seam used and must separately demonstrate that the accepted release surface cannot invoke that seam as a user feature. Named storage acceptance gaps. Acceptance must include a case-variant governed namespace/class fixture proving that Data Sculptor does not silently normalize the variant spelling into canonical governed identity; an unknown syntactically valid governed-class fixture proving that the file remains byte-for-byte unchanged while a canonical INFO diagnostic and INVENTORY surface the unknown/unrecognized class; and at least one known-but-not-emitted-class fixture drawn from DGN , RCV , BRD , or LCK proving the same preserve-and-report behavior without activating a producer, lifecycle, or interpretation path. Carried feature gates remain feature-owned. Mechanisms whose normative lifecycle is integrated in another package — including the F-02 Work Order-registry/alias-replacement behavior, the F-04 existing-Store cardinality refusal, and the F-24 CER-history decision — cannot be considered accepted without their corresponding feature acceptance gates. This requirement does not invent those feature semantics. If a proposed mechanism is removed from WASM-002 rather than integrated, no acceptance gate for that removed mechanism is required.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-001,UTF-8 certification pass,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,A valid multi-gigabyte UTF-8 fixture must complete whole-source certification with exact byte accounting under bounded memory.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-002,UTF-8 certification fail,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"A fixture containing an invalid UTF-8 sequence, including a sequence that crosses an input-window boundary, must deterministically produce STAGE1_UTF8_OUTCOME: FAIL , UTF8_STOP_REASON: INVALID_UTF8_SEQUENCE , and the exact governed zero-based UTF8_FIRST_INVALID_BYTE_OFFSET . Stage 2 must not begin and no analytical materialization output may be published. The same bytes tested under different permitted Stage-1 input-window sizes and boundary placements must yield the same outcome, stop-reason token, and first-invalid offset.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-003,Run-local source substitution refusal,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"An acceptance fixture must attempt to present Stage 2 with a different source instance/reference than the one retained from Stage 1. The run must refuse before materialization rather than accept the substitute merely because filename, alias, path, or byte length appears compatible. F-23 governed seam: this fixture must use the test-only source-handle substitution/reread seam permitted by W002-QA-001 so the different Stage-2 instance is injected without changing the analyst-visible SOURCE syntax or adding a product-level source-selection path. Release-surface evidence must demonstrate that an analyst cannot invoke this substitution seam through the normal UI, Work Order, URL/query, or Suitcase configuration.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-004,ASCII-only fast path,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,An all-ASCII fixture must certify successfully without invoking non-ASCII sequence validation and must produce exact byte accounting.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-005,Valid non-ASCII sequence matrix,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"Acceptance must cover valid two-byte, three-byte, and four-byte UTF-8 sequences, including sequences placed at window boundaries and split at every legal boundary position.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-006,Strict invalid-sequence matrix,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"Acceptance must reject at known exact offsets: lone continuation bytes, malformed continuation sequences, truncated sequences, overlong encodings, UTF-16 surrogate encodings, invalid lead bytes 0xC0 / 0xC1 , values introduced by 0xF5 - 0xFF , and code points above U+10FFFF. Every invalid fixture must serialize the same canonical UTF-8 stop reason INVALID_UTF8_SEQUENCE while preserving its fixture-specific exact first-invalid byte offset. For an EOF-truncated multibyte sequence, the expected offset is the lead byte of the incomplete sequence. Acceptance must include at least one malformed sequence crossing a Stage-1 input-window boundary and prove window invariance. Separate valid fixtures covering ASCII-only, valid multibyte UTF-8, and permitted leading-BOM forms must complete with STAGE1_UTF8_OUTCOME: PASS ; their UTF-8 refusal-only Receipt fields are NOT_APPLICABLE .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-007,Late invalidity,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,A source that is ASCII/valid UTF-8 until near EOF and becomes invalid late in the file must fail at the first invalid absolute offset; bounded-prefix success must not be treated as whole-file certification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-008,Window-size invariance,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,The same fixture matrix must return the same PASS/FAIL and first invalid absolute offset across at least two materially different bounded window sizes.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-009,EOF pending-state refusal,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,EOF with an incomplete UTF-8 sequence must fail deterministically and report the governed offset; no replacement character may be inserted.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-010,BOM behavior,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"A UTF-8 BOM at offset zero must be accepted as metadata while the remainder of the source is still fully certified; a BOM must not mask later invalid UTF-8. F-07 BOM coordinate fixture: when a permitted three-byte UTF-8 BOM precedes a later malformed UTF-8 sequence, the expected first-invalid offset counts the BOM's physical bytes. The BOM is excluded from analytical CSV content but included in the absolute physical source-byte coordinate system.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-001,Multi-column one-pass Stage 2 materialization,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Using a valid UTF-8 source and a Work Order requesting at least four source columns through a mixture of HEADER and COLUMN selectors, acceptance must prove that Stage 1 completes first, Stage 2 restarts at byte zero of the same run-local source instance, parses the header once, resolves all selectors before the first data row, and reads the source data records only once while producing all requested columns. Evidence must reconcile total source bytes read by Stage 2, logical data-row count N, per- COL data-record count N, selector-to-source ordinal/header resolution, resolved KEEP order, and the resulting successor MAP. A one-column rerun of the same source/column must produce the same canonical physical column bytes as that column produced inside the multi-column run, apart from governed artifact identity. F-20 width/one-pass acceptance: acceptance must include a maximum-width fixture whose valid source has exactly 16,384 columns and whose KEEP resolves all 16,384 distinct columns. Instrumentation must prove one source data-record traversal regardless of the implementation's bounded post-scan spool/finalization strategy. A companion 16,385 -column source must refuse during header resolution before the first data record is consumed.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002,"Automatic Store MAP creation, inheritance, and rematerialization continuity",W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must materialize four previously unseen source columns in one Store-establishing Work Order and prove that one successor Store MAP is created with four mapping rows. Every row must repeat identical Store-level fields, bind the newly created RID filename, default store_alias to the exact Store-establishing source filename, default rid_alias to RID , and default each COL alias to its exact source header. A later Work Order using the same exact SOURCE without explicitly naming a MAP must route under W002-STOR-019.2 . If exactly one routable Store lineage exists for that exact source filename and its current Store state permits materialization, the Work Order must inherit that lineage’s current structurally valid Store MAP, preserve the Store/RID metadata and four prior mappings, add a fifth default COL alias, and publish one new complete Store MAP. A later rematerialization of one earlier logical column must preserve its inherited COL alias while updating its column_filename . An explicit older MAP selection must instead use that historical Store state. Equal-latest-timestamp ambiguity within one routed lineage, malformed-newer-MAP fallback within the same Store lineage, no-routable-Store-lineage creation, and multiple-routable-Store-lineages-for-the-same-source refusal must also be exercised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.1,Exact eight-column Store MAP serialization acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must validate the exact Store MAP header store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename , UTF-8 without BOM, LF line endings, deterministic mapping-row order, standard governed CSV quoting, and byte-for-byte repetition of store_alias , rid_filename , rid_alias , and the common source_filename on every mapping row. The fixture must prove that a MAP with inconsistent repeated Store-level metadata, more than one rid_filename , more than one source_filename , a missing or invalid RID filename, a duplicate logical source-column key, or a non-eight-column schema is ineligible for inheritance. Source compatibility fixtures must prove that an explicit MAP may proceed only when the Work Order SOURCE exactly equals that MAP's common source_filename . A different source must refuse before materialization even when its row count equals the Store's RID cardinality; matching row count never creates a positional-join escape. P3-06 validation-tier fixtures: acceptance must distinguish Store-health Tier 1 from full Tier 2 validation. A same-named externally restored RID/COL may be treated as eligible only after it passes the tier required by the operation, and no fixture may label such an artifact “the exact original” solely from its physical filename. Tier-1 fixtures must prove the exact bounded checks in W002-STOR-019.10 without an end-to-end scan of every artifact value. Tier-2 fixtures must prove full RID sequence/cardinality validation and full COL canonical-form/header/cardinality validation. REPAIR MAP fixtures must demonstrate that the same input bytes yield one deterministic set of removed COL bindings under Tier 2. P2-04 closure fixtures: acceptance must include (1) a RID that satisfies Tier 1 but fails Tier 2 because the body does not contain the exact declared 1..N sequence; (2) a COL that satisfies Tier 1 but fails Tier 2 because its complete CSV body or logical-record count is invalid; (3) an externally supplied same-named RID/COL that passes the required governed tier without any assertion that it is the historical original bytes; and (4) a REPAIR MAP case with a mixture of Tier-2-valid and Tier-2-invalid COLs proving that the successor removes exactly the failing bindings. Repeating the same fixture bytes must yield the same repair set and successor mapping.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.2,Multiple Stores in one Suitcase remain distinct through RID-anchored MAP lineages,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must establish at least two Stores from different source files in the same Suitcase. Their Store MAP lineages must contain different immutable rid_filename values, and automatic routing for each source must choose only that source's routable Store lineage. The fixture must prove that a lineage remains routable when at least one Store MAP is structurally valid even if subsequent Store-health evaluation is DEGRADED or INVALID ; health may refuse the operation, but it must not make the lineage disappear from routing. Changing a human-facing store_alias or rid_alias in a later governed MAP must not change the Store's rid_filename , RID bytes, or lineage identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.3,WKO MAP profile and alias-registry publication acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must save at least three immutable WKO artifacts, each containing exactly one non-empty WORK ORDER AS clause: one with a multi-word alias, one whose alias is deliberately replaced under the frozen WKO lifecycle, and one with punctuation permitted by the governed string rules. The committed WKO MAP must satisfy the frozen current-registry schema and lifecycle rules, use UTF-8 without BOM and LF endings, preserve exact physical WKO references, and prove deterministic governed serialization. The fixture must prove that a WKO MAP cannot be treated as a Store MAP; duplicate physical WKO rows are invalid; conflicting current authority for the same non-empty alias is refused before commit; and equal-latest-timestamp ambiguity refuses current-registry selection. A saved/executable WKO without WORK ORDER AS is invalid in Revision BM and must refuse before execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.4,WORK ORDER AS and # comment lexical acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must prove that WORK ORDER AS ""Prepare monthly crime data"" is parsed as the immutable WKO alias, that whole-line and trailing # comments are ignored semantically, and that # inside double-quoted strings remains ordinary string content. The fixture must also prove that saved WKO bytes preserve comments exactly, that changing only a comment or Work Order alias requires a new WKO physical identity, and that no standalone browser Description value is required to reopen or display the governed alias. P3-10 alias fixture: acceptance must prove that WORK ORDER AS ""   "" refuses as a whitespace-only alias, while an otherwise valid alias containing leading or trailing whitespace is not silently trimmed or normalized and is preserved exactly in saved WKO bytes and the governed alias registry.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-003,Stage 2 structural window-invariance matrix,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Acceptance fixtures must force input boundaries at structurally difficult positions including before/after delimiters, before/after opening and closing quotes, between doubled quote bytes, between CR and LF, inside quoted multiline field content, at empty fields, and inside already-certified multi-byte UTF-8 sequences. Across permitted window sizes and boundary placements, the logical row count, selected values, canonical COL bytes, first refusal location/condition, and resolved mapping semantics must remain invariant. P3-09 fixtures: acceptance must include both byte forms identified by the Pass 3 finding: (1) an exactly zero-byte source and (2) a source containing only the three UTF-8 BOM bytes EF BB BF . Both must pass the applicable Stage 1 UTF-8 gate and then refuse in Stage 2 with NO_HEADER_RECORD . The exact expected location tuples are respectively (offset 0, physical line 1, logical record 1, field ordinal 1) and (offset 3, physical line 1, logical record 1, field ordinal 1) . The fixtures must also distinguish this case from an existing-but-blank first logical record, which remains BLANK_LOGICAL_RECORD . P3-10 delimiter-help fixture: acceptance must include a quoted semicolon-delimited form such as ""a"";""b"" and an equivalent TAB-delimited quoted form that reach INVALID_BYTE_AFTER_CLOSING_QUOTE . The canonical refusal condition and location facts must remain unchanged, while the Help rendering is permitted to surface the delimiter-mismatch hint for offending byte 0x3B or 0x09 . F-06 structural-refusal acceptance matrix An unexpected quote in an unquoted field must report the quote byte and UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD . A prohibited byte after a closing quote must report that byte and INVALID_BYTE_AFTER_CLOSING_QUOTE . A bare CR outside quoted content must report the CR byte and BARE_CR_OUTSIDE_QUOTED_FIELD . CR, LF, and CRLF inside valid quoted values must remain field content and must not trigger the bare-CR rule. EOF in an open quoted field must report the one-past-end source offset and EOF_INSIDE_QUOTED_FIELD . A blank logical record must report BLANK_LOGICAL_RECORD , not TOO_FEW_FIELDS . A short record must report the terminator/EOF location and the first missing field ordinal. A wide record must report the comma delimiter opening the first extra field and that extra field ordinal. All five refusal facts must remain identical across permitted source-window sizes and boundary placements. Fixtures must force boundaries around commas, opening and closing quotes, doubled-quote pairs, CR/LF pairs, quoted multiline content, empty fields, and already-certified multibyte UTF-8 sequences. A semicolon-separated file must not refuse solely because it uses semicolons; Help may explain comma-only interpretation when header selection fails. Day 060 H-13 Receipt-corpus binding for P3-09 The two analytical P3-09 source fixtures above must each have a corresponding byte-exact refusal Receipt under W002-RCP-ACC-002. The zero-byte and BOM-only cases therefore prove both the parser/refusal oracle and the Receipt serialization oracle independently.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-004,Canonical one-column COL serialization acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Golden-byte fixtures must cover ordinary ASCII, non-ASCII UTF-8, commas, embedded double quotes, CR, LF, CRLF inside quoted values, explicit empty data values, empty source headers, and header-only zero-row input. Acceptance must prove one UTF-8 BOM at file start, LF record termination independent of host platform, deterministic minimal quoting, doubled embedded quotes, """" for an empty one-column data value, no accidental inclusion of the source BOM in the first header, and byte-identical round-trip semantics through the Data Sculptor CSV reader. F-20 oversized-header serialization acceptance: fixtures at exactly 1,024 and 1,025 Unicode scalar values must prove that the physical COL header remains byte-faithful to the exact decoded source header while only the operational/default-alias name changes at the boundary. Scalar-count fixtures must include combining characters so acceptance cannot accidentally measure UTF-8 bytes or grapheme clusters instead.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-005,"Field-limit, ragged-record, blank-record, and failure-publication acceptance",W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Acceptance must include decoded field sizes exactly 16 MiB and 16 MiB + 1 byte, malformed runaway quoted-field cases, nonblank records with too few and too many fields, a bare blank logical data record, explicit empty fields, and a physical blank line inside a valid quoted multiline field. The first invalid case must refuse without truncation or silent repair. Publication evidence must additionally exercise both a new-Store multi-column materialization and a later existing-Store materialization. For the new Store, the shared publication-transaction UTC must be established before any new RID/COL SCR candidate is opened, and each candidate-specific UUID must be allocated before its candidate is created. RID and COL outputs must remain governed SCR until the complete candidate set validates; the RID must then promote first, requested COLs must promote in deterministic KEEP order, the successor MAP UUID must be allocated before its MAP SCR candidate is opened, that MAP candidate must be written/closed/reopened/validated while still SCR , and its final SCR -to- MAP rename must occur last. For every successfully promoted RID, COL, and MAP artifact, acceptance must prove that the candidate and final identity have the exact same UTC, UUID, extension, and bytes and differ in the governed filename only by the three-letter semantic class token. For the existing Store, the inherited RID must remain byte-for-byte and filename-identical with no new RID candidate. F-04 existing-Store cardinality acceptance: acceptance must include two otherwise valid existing-Store materializations using the same exact governed SOURCE identity. In the equal-cardinality fixture, Stage 2 candidate N must equal the inherited RID-header N and publication may proceed under the ordinary rules. In the mismatch fixture, candidate N must differ from RID-header N ; the Run must refuse before any candidate COL is promoted into the final COL namespace and before any successor MAP is published. The inherited RID, current MAP, existing COL artifacts, and Store health must remain unchanged, with the existing Store remaining VALID. The equal-cardinality case must not be represented as proof of source-byte or row-semantic identity. Forced failure cases must cover: failure before any promotion; RID-promotion failure; failure during COL promotion after RID and at least one COL have promoted; MAP-candidate write/close/reopen/validation failure; MAP final-rename failure; and interruption after physical RID/COL promotion but before MAP commit. Each case must prove rollback where safely possible or visible non-authoritative SCR failure evidence otherwise, must prove that unreferenced final-class-looking RID/COL files are not treated as committed Store membership, and must prove that the prior valid MAP remains authoritative for an existing Store or that no committed Store exists for an uncommitted first materialization. F-20 bounded-width/name acceptance: acceptance must cover exactly 16,384 versus 16,385 source columns; KEEP widths of 1 and 16,384 ; operational-name derivation at 1,024 versus 1,025 Unicode scalar values; physical ordinals producing Column A , Column Z , Column AA , and Column XFD ; and deterministic oversized-header fallback collisions proving [ordinal] then -2 progression. A separate short-header alias collision must prove refusal rather than automatic suffixing.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-006,Large-source browser materialization evidence,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance must include a browser run against the established Statistics Canada scale source or an equivalently retained scale fixture, recording source bytes, Stage 1 time, Stage 2 time, total time, selected-column count, logical row count, bytes written per COL , peak/bounded memory observations, output fingerprints, and browser/platform details. The retained Day 039 evidence established that Microsoft Edge could stream the 7,250,808,204-byte source through a small Rust/WASM materializer and materialize 29,014,718 VALUE data rows in practical time. Revision AM treats that result as engineering evidence and a comparison baseline, not as proof that WASM-002 is already implemented or as a frozen wall-time threshold. F-20 writer-resource evidence: retained acceptance evidence must identify the build's configured maximum simultaneously active writable-output resources and the observed peak for the run. Evidence must show that wide KEEP cardinality does not imply one simultaneously open writer per selected column and that any bounded spool/finalization strategy preserves the same governed output bytes and semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-ACC-001,Separate Windows-1252 conversion,W002-CONV-ACC,W002-CONV,WASM-002,UNDER REVIEW,—,"A non-UTF-8 fixture compatible with the supported Windows-1252 converter must cause the analytical task to stop, permit a Help suggestion, and succeed only when the separate conversion Work Order is explicitly run. P3-08 acceptance: the fixture set must convert an analyst-owned legacy source successfully, materialize the resulting CVT, then perform a second successful conversion from a refreshed legacy source using the same analyst-owned filename. The second conversion must publish a different CVT physical filename. First materialization of that second CVT must establish a distinct Store/RID lineage rather than inherit from the first CVT-backed Store. Acceptance must also prove that Help discloses this consequence at conversion success and again when the CVT is first materialized, and that no hidden original-source identity is used to join the two CVTs into one lineage. F-16 acceptance: the compatible non-UTF-8 fixture must prove that strict UTF-8 certification first emits DS-ENC-001 with next_action: NONE ; Stage 2 does not start; Data Sculptor restarts at byte 0 of the same bound source instance and scans the complete source under the frozen mapping; the Receipt records WINDOWS_1252_COMPATIBILITY_OUTCOME: COMPATIBLE and WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET: NOT_APPLICABLE ; and only then is DS-CNV-001 emitted with severity: INFO , behavior: CONTINUE , and next_action: RUN_WINDOWS_1252_CONVERSION . The refused MATERIALIZE run must remain refused. A separate valid-UTF-8 fixture must prove that both Windows-1252 compatibility Receipt fields are NOT_RUN and DS-CNV-001 is not emitted. F-10 conversion-gate and byte-output acceptance A source already valid as complete strict UTF-8 must refuse CONVERT WINDOWS-1252 TO UTF-8 as unnecessary and create no CVT . A source that fails strict UTF-8 but passes the complete Windows-1252 compatibility assessment may convert only when the separate conversion WKO is explicitly run. The analyst-owned source bytes must remain unchanged. The published CVT must pass complete strict UTF-8 certification. Source CR, LF, and CRLF bytes must be preserved in place rather than normalized. The conversion must remain bounded/streaming. The published CVT must not begin with a UTF-8 BOM introduced by Data Sculptor. The successful Receipt must contain the frozen conversion operation token and required conversion facts. Frozen minimal byte oracle: Windows-1252 source bytes:
63 61 66 E9 0D 0A

UTF-8 CVT bytes:
63 61 66 C3 A9 0D 0A This is café followed by CRLF. The expected CVT begins with byte 63 ; no EF BB BF prefix is present. Day 060 H-25 / BM-04 acceptance: the already-valid-UTF-8 CONVERT fixture must use a complete source whose byte stream is valid strict UTF-8 and must produce a byte-exact refused Receipt containing: SOURCE_ENCODING: UTF-8
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: NOT_RUN
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE The same fixture must prove that no Windows-1252 compatibility assessment runs, no transcoding begins, the analyst-owned source bytes remain unchanged, and no CVT file is created.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-ACC-002,Undefined Windows-1252 byte refusal,W002-CONV-ACC,W002-CONV,WASM-002,UNDER REVIEW,—,"A fixture containing a byte undefined by the frozen Windows-1252 mapping must not be silently converted. F-16 acceptance: use fixtures placing each of 0x81 , 0x8D , 0x8F , 0x90 , and 0x9D at controlled physical offsets, including across compatibility-buffer boundaries. The complete oracle must prove WINDOWS_1252_COMPATIBILITY_OUTCOME: INCOMPATIBLE , the exact first undefined-byte offset, no DS-CNV-001 emission, no conversion recommendation, and window-size invariance. A separate injected read-failure fixture after the compatibility pass begins must prove NOT_AVAILABLE for both compatibility Receipt fields and no conversion recommendation. F-10 conversion-operation undefined-byte acceptance The separate CONVERT WINDOWS-1252 TO UTF-8 operation must itself refuse before transcoding when its complete compatibility assessment encounters any byte undefined by the frozen Windows-1252 mapping. Such a refusal publishes no CVT . Acceptance must cover each frozen undefined byte value at a controlled absolute source offset and prove that no replacement-character, ISO-8859-1, or permissive-decoder fallback produces output. Day 060 H-14 / BM-11 byte-exact undefined-byte CONVERT fixture The golden CONVERT refusal fixture uses this exact analyst-owned source byte sequence: 41 81 42 The strict UTF-8 gate must fail, and the subsequent complete Windows-1252 compatibility assessment must encounter 0x81 as the first undefined byte at exact zero-based absolute physical source-byte offset 1 . The operation must refuse before transcoding begins. The byte-exact Receipt for this fixture must include: SOURCE_ENCODING: WINDOWS-1252-INCOMPATIBLE
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: 1
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE
RESULT: REFUSED The analyst-owned source bytes must remain exactly 41 81 42 ; no CVT is published; no replacement character is introduced; and no ISO-8859-1 or permissive-decoder fallback is permitted. A second acceptance form must place at least two undefined Windows-1252 bytes in one source and prove that the reported offset is always the first undefined byte. Buffer/window-boundary variants must preserve the same absolute offset.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-001,Canonical diagnostic event,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,At least one real governed WASM-002 failure path must emit a complete canonical diagnostic event with stable code and structured facts. A separate test-only fault-injection fixture must remove or withhold one required fact while the engine attempts to assemble a registered diagnostic. Acceptance must prove that the malformed intended diagnostic is not emitted and that exactly one canonical DS-HLP-001 replacement event is emitted with the exact intended diagnostic ID and the complete ascending-UTF-8 list of missing required fact keys.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-002,Three-voice rendering parity,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"A complete event with an authored catalog entry must be renderable in all three established Help voices. Automated checks must demonstrate invariant diagnostic truth across the three outputs. A separate complete registered diagnostic fixture must deliberately have no help_messages.json entry. Casual, Office Speak, and Technical selections must all resolve to the same deterministic Generic Technical Help fallback, preserving the original diagnostic semantic core and rendering emitted facts in ascending UTF-8 fact-key order without invented cause or remediation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-003,Saved HTML Help report using the canonical built-in Data Sculptor presentation,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,At least one complete HTML Help report using the canonical built-in Data Sculptor presentation must be generated and saved locally from that real event.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-004,Offline durability,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,The saved HTML report must remain readable with its canonical built-in Red5Sorcery/Data Sculptor presentation when opened without network access and without access to Data Sculptor or any external presentation resource.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-008,Support-handoff report acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"From a real governed refusal, Data Sculptor must generate one styled HTML Help Report that opens in an ordinary browser without Data Sculptor or network access and contains both a selected-voice explanation and the canonical structured facts needed by a technical reviewer.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-009,Canonical boundary-fact acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"An early-refusal fixture that stops before analytical materialization must demonstrate the exact four Boolean fact names from W002-HELP-004.11 and, when those are the true governed facts, values equivalent to: source_modified_by_data_sculptor = false
materialization_started = false
analytical_outputs_published = false
store_state_committed = false Acceptance must also exercise at least one boundary-fact case in which an established Boolean value is unavailable or otherwise carries an applicable governed absence state. The emitted value must use the exact shared JSON string token required by W002-HELP-004.11 (for example ""NOT_AVAILABLE"" ) and must not be coerced to false or JSON null . Where a boundary fact is optional and its key is omitted, acceptance must prove that omission is not interpreted as false or as any governed absence token. The same fixture family must prove that temporary SCR candidates or abandoned/uncommitted debris do not make analytical_outputs_published true.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-010,"HLP provenance, multiplicity, and no-automatic-hash acceptance",W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"Acceptance evidence must generate a final HLP using the built-in Red5Sorcery/Data Sculptor presentation and verify its governed __DS__HLP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html identity, its visible Provenance section, and exactly one embedded application/json payload with element ID ds-hlp-provenance . The embedded payload must contain exactly the schema-version-2 fields governed by W002-HELP-009 and must verify the same HLP filename/generation UTC, non-empty ordered diagnostic_ids array, WKO/RCP lineage semantics, selected Help voice, built-in presentation identifier red5sorcery-data-sculptor , built-in presentation version ""1"" , and the exact running Data Sculptor build identifier. Acceptance must cover: (1) an explicit request for a single diagnostic; (2) one governed Run with multiple included diagnostic events, proving exactly one HLP for the request and event-order parity with diagnostic_ids ; and (3) a non-run diagnostic such as Suitcase-validation or WKO-save refusal, proving that non-applicable WKO/RCP lineage is represented by JSON null and visible NOT APPLICABLE rather than invented Run lineage. Acceptance must also cover all three lineage representations permitted by W002-HELP-009: an exact physical filename when the relationship exists and is known; JSON null when the relationship does not apply; and the exact JSON string ""NOT_AVAILABLE"" when the relationship applies but its exact filename cannot be obtained. The fixture must prove that null and ""NOT_AVAILABLE"" are not interchangeable. Acceptance must prove that the visible Provenance section and machine-readable payload agree semantically; missing, duplicate, malformed, mismatched, non-HTML-safe, disclosure-violating, empty diagnostic_ids , or scope-label-only build provenance must not be accepted. The same acceptance must prove that ordinary HLP generation does not compute or embed an HLP SHA-256 and does not create, refresh, or verify an LCK . Exact-byte HLP integrity remains outside WASM-002 in the later explicit FINGERPRINT/LCK workflow.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-011,Fixed support-handoff disclosure acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"Acceptance must prove the fixed support-handoff disclosure boundary with both permitted-context and adversarial headerless fixtures. A permitted-context fixture must generate an HLP whose diagnostic requires a source filename, one genuinely established relevant source header and/or 1-based column number, bounded execution evidence, and a small executable Work Order excerpt. A governed alias may appear only when the alias itself is necessary to explain the diagnostic, such as an alias collision, ambiguity, or mutation; an unrelated alias must remain excluded. The report must include only the necessary permitted facts while excluding source rows/values, absolute local paths, unrelated headers/aliases/columns, the complete Work Order, Work Order comments, unrelated Suitcase contents, and raw ungoverned stack traces. A separate headerless-source fixture must place unmistakable sentinel text in the first data row and prove that none of that text appears in the HLP as a header or other disclosed source value. That HLP must show Source header text included: NO and Source values included: NO while still presenting sufficient structural evidence to explain the diagnostic. A genuine-header fixture must prove that a necessary established header may appear with Source header text included: YES . Alias fixtures must similarly prove truthful Governed alias text included: YES only when necessary and NO otherwise. Every fixture must verify the remaining frozen Disclosure declarations from W002-HELP-010. WASM-002 must expose no control that changes this fixed disclosure policy.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-012,Cross-session source-continuity Help acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"An acceptance fixture must present Help with a suspected cross-session source-change scenario and verify that the explanation asks whether the source may have been edited/replaced/sorted/re-exported/synchronized, distinguishes no evidence from INVENTORY metadata evidence and stronger explicit fingerprint evidence, and never claims that unchanged filename or unchanged INVENTORY metadata proves byte identity. A no-evidence fixture must state that continuity cannot be independently verified. An INVENTORY fixture with changed source byte length or last-modified metadata must describe the difference as evidence that the source may have changed, not as a cryptographic conclusion. The fixture must also confirm that ordinary WASM-002 materialization did not automatically hash the source as part of this edge-case protection.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-013,Diagnostic-registry and Help cross-validation acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance must retain the validated diagnostics.json used by the accepted build and verify its exact version-1 schema, canonical sort order, unique permanent IDs, fixed-token grammars, and disjoint required/optional fact declarations. At least one real governed diagnostic fixture must prove that the emitted semantic core matches the matching registry entry and that all required facts are present while no undeclared fact key is emitted. Negative build-validation fixtures must prove deterministic failure for malformed/duplicate registry entries, an engine diagnostic definition absent from the registry, fixed semantic disagreement, an undeclared emitted fact, a Help-catalog diagnostic ID absent from the registry, and a Help placeholder not declared for its matching diagnostic. F-17 runtime completeness fixtures: missing required facts are no longer treated as a malformed event that may leak to Help. Fault injection must prove deterministic substitution with DS-HLP-001 , including exact intended_diagnostic_id and sorted missing_required_facts , with no partially populated intended diagnostic emitted. Separately, a valid registered diagnostic omitted from help_messages.json must remain a valid build/runtime condition and must exercise the Generic Technical fallback rather than build failure or diagnostic suppression. F-22 QA-independence acceptance boundary: acceptance must prove the registry/engine/Help wiring and generic invariants without circularly presenting the implementation-delivered registry as an independent oracle for its own condition-to-Diagnostic-ID allocations. Representative governed fixtures must trace condition → emitted Diagnostic ID → matching registry semantic core → required/optional fact discipline → Help lookup/rendering. Every condition-to-ID or required-fact mapping explicitly frozen elsewhere in this PRD remains independently testable and must match that PRD contract. For allocations not independently pinned by this PRD, WASM-002 does not require a duplicate QA-owned registry that restates every condition-to-ID choice. Passing this acceptance gate therefore demonstrates registry integrity, engine↔registry semantic agreement, fact completeness/legality, Help-catalog wiring, F-17 fail-safe behavior, and representative end-to-end diagnostic routing; it must not be reported as exhaustive independent proof that every possible runtime condition was assigned the semantically correct Diagnostic ID. That residual independence limitation is an accepted WASM-002 risk. F-23 embedded Help-catalog release fixture: acceptance must build the released HTML from a validated help_messages.json , verify exactly one non-executable application/json payload with element ID ds-help-catalog , and include adversarial catalog text containing literal < / script-like delimiter content to prove HTML-safe embedding. Runtime instrumentation must prove that Help lookup reads only the embedded payload and performs no network, filesystem, Suitcase, or adjacent-file fetch for the Help catalog. A missing, malformed, mismatched, or unsafe embedded catalog must fail build acceptance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-007,Work Order syntax is the analytical contract,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"If a value, reference, option, or instruction changes what Data Sculptor analytically does, that intent must be represented in governed Work Order text or in a separately governed artifact explicitly referenced by that Work Order. Browser permission, directory selection, UI focus, a highlighted file, an alias display, or another GUI gesture must not silently become analytical intent. For WASM-002, every executable saved WKO begins with the common preamble: SUITCASE: .
WORK ORDER AS ""<non-whitespace alias>"" Ignoring blank lines and governed comments, the WKO must then parse completely under exactly one of these seven executable operation grammars: Operation Governed DS-STEPS structure after the common preamble MATERIALIZE SOURCE ""..."" ; optional MAP ""..."" ; KEEP ; one or more selectors; terminal MATERIALIZE . INVENTORY terminal INVENTORY only. UPDATE ALIASES exactly one Store-state selector: SOURCE ""..."" or MAP ""..."" ; one or more governed alias mutations; terminal UPDATE ALIASES . REPAIR MAP exactly one MAP ""<exact current Store MAP filename>"" ; terminal REPAIR MAP . REPAIR WORK ORDER REGISTRY terminal REPAIR WORK ORDER REGISTRY only. CONVERT WINDOWS-1252 TO UTF-8 exactly one SOURCE ""..."" ; terminal CONVERT WINDOWS-1252 TO UTF-8 . CATALOG STORES terminal CATALOG STORES only. Each operation-specific numbered requirement remains authoritative for its detailed selectors, preconditions, mutations, publication semantics, and acceptance behavior. This requirement freezes the cross-operation boundary: unknown semantic lines refuse; clauses from another operation grammar refuse unless the selected operation explicitly defines them; there is no best-effort interpretation and no silent cross-operation mixing. Lexical token separation. DS-STEPS keywords are matched ASCII case-insensitively; canonical examples render them uppercase. Wherever two adjacent lexical tokens would otherwise run together, they must be separated by one or more ASCII SPACE ( 0x20 ) or horizontal TAB ( 0x09 ) characters. Leading SPACE/TAB indentation is semantically neutral. Thus REPAIR MAP , SOURCE ""crime.csv"" , and COLUMN 7 are valid tokenizations, while REPAIRMAP , SOURCE""crime.csv"" , and UPDATE_ALIASES are not alternate DS-STEPS spellings. Quoted-string contents are never case-folded or whitespace-normalized merely because keywords are case-insensitive. The browser may authorize resources, edit text, validate, save, invoke Run, display evidence, and provide Help. Authorization to access a resource is not authorization to use that resource analytically.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-008,Every executable Work Order explicitly declares its Suitcase,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"For WASM-002, every executable saved Work Order must contain the exact portable declaration SUITCASE: . . The dot means the filesystem directory that physically contains the saved WKO artifact being executed. A Work Order lacking this declaration must not be treated as an executable WASM-002 Work Order. The declaration is analytical/execution syntax, not a substitute for browser filesystem permission. The host must still possess valid access to the directory before execution can proceed. Help obligation: Data Sculptor Help must explain SUITCASE: . in plain language: the saved Work Order uses the folder that contains that WKO as its Suitcase; the dot means “this folder”; ordinary Work Order file references are therefore portable and Suitcase-relative; and browser/host permission to the folder is granted separately. Help must not teach an absolute machine path as the normal replacement for . .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-009,Ordinary Work Order file references are Suitcase-relative,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Unless another numbered requirement explicitly governs a different reference mechanism, file references in an executable WASM-002 Work Order resolve relative to the declared Suitcase. A portable Work Order must not depend on an absolute machine-specific path to identify ordinary Suitcase files. Resolution must be deterministic in browser and later native hosts. Moving an intact Suitcase to another permitted filesystem location must not change the logical meaning of the Work Order solely because the parent machine path changed.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-009.1,WASM-002 SOURCE eligibility is exact and root-bounded,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"A WASM-002 SOURCE clause names exactly one physical regular file in the Suitcase root by exact filename only. It must not name an absolute path, drive or UNC path, subdirectory, path containing / or \ , traversal such as .. , URL/URI, or another external reference. Resolution uses the exact Unicode-scalar filename identity and reference-bounded rules frozen by F-15; no case-folding, normalization, trimming, or filesystem-equivalence search is permitted. The only eligible WASM-002 SOURCE kinds are: Analyst-owned CSV: a regular Suitcase-root file whose exact filename does not begin with the reserved exact prefix __DS__ and whose final extension is .csv under ASCII case-insensitive extension recognition. Thus .csv , .CSV , and mixed-case equivalents are candidate CSV extensions. This case-insensitivity applies only to extension recognition; the complete filename reference remains exact. If the physical file is crime.CSV , a differently cased full filename does not become an alternate reference to it. Governed converted source: a successfully published CVT whose exact canonical identity and class-specific publication/validity predicate satisfy W002-CONV-004, W002-STOR-023, and PB-STOR-008. A filename that merely resembles a CVT is not sufficient. No other governed semantic class is eligible as SOURCE in WASM-002, even when its physical serialization is CSV. In particular, COL , RID , MAP , CAT , INV , RCP , HLP , CER , SCR , RCV , and WKO artifacts cannot be reintroduced as SOURCE merely because their bytes or extension appear compatible. A recognized .csv extension establishes only candidate SOURCE form. It does not certify encoding or CSV structure; the normal strict UTF-8 and structural certification contracts still govern after source resolution. Conversely, CSV-like bytes stored under a non-CSV analyst-owned extension are not an eligible WASM-002 SOURCE.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-008; CP-009; CP-010,"T-ACCEPTED, BANKED; analyst-owned CSV filename candidate preflight only; full SOURCE eligibility remains partial; CP009 T-ACCEPTED, BANKED — pure exact-name root snapshot matching only; full requirement remains partial; CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open",346733a962192320e0d56271add15a47b6037b6b; dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8; b7c515faa9bd000369d7656e09437310261290ae,Evidence/CP-008/CP008_RED_Test_Output.txt; Evidence/CP-008/CP008_GREEN_Test_Output.txt; Evidence/CP-008/CP008_Full_Regression_Test_Output.txt; Evidence/CP-008/CP008_Post_Format_Test_Output.txt; Evidence/CP-008/CP008_Rustfmt_Check_Output.txt; Evidence/CP-008/CP008_WASM_Build_Output.txt; Evidence/CP-008/CP008_Hash_Inventory_Verification.txt; Evidence/CP-008/CP008_Precommit_Git_Review.txt; Evidence/CP-008/CP008_Final_Source_Review.txt; Evidence/CP-008/CP008_Whitespace_Exception_Review.txt; CP008_Git_Banking_Output.txt (separate post-commit evidence; archived outside repository); Evidence/CP-009/CP009_Baseline_Test_Output.txt; Evidence/CP-009/CP009_RED_Test_Output.txt; Evidence/CP-009/CP009_GREEN_Test_Output.txt; Evidence/CP-009/CP009_Full_Regression_Test_Output.txt; Evidence/CP-009/CP009_Rustfmt_Check_Output.txt; Evidence/CP-009/CP009_Git_Whitespace_Check.txt; Evidence/CP-009/CP009_Post_Format_Test_Output.txt; Evidence/CP-009/CP009_WASM_Build_Output.txt; Evidence/CP-009/CP009_Hash_Inventory.txt; Evidence/CP-009/CP009_Hash_Inventory_Verification.txt; Evidence/CP-009/CP009_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Final_Staging_Review.txt; CP009_Git_Banking_Output.txt (separately archived post-commit evidence); Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived),"CP008 Day066: public is_analyst_owned_csv_source_candidate(&str) -> bool recognizes the final .csv extension ASCII case-insensitively for exact Suitcase-root analyst-owned candidate names. It refuses empty stems, __DS__-reserved names, slash/backslash paths, colon-bearing references, and traversal-like double-dot forms; preserves full spelling, case and Unicode normalization distinctions. Five new tests and 23 prior tests passed, 28/28 after Rustfmt. WASM32-target library compilation passed; no standalone browser execution proven. 20/20 SHA-256 file inventory matched; staged Rust source/test whitespace check 0. Full staged whitespace check 2 due solely to two preserved archival trailing-space lines in the CP008 precommit TXT, documented with supplemental diagnostic. Human T approved; Git commit banked with 18 files and clean working tree. This is ONLY lexical analyst-owned CSV candidate form, NOT regular-file proof, exact physical filename resolution, governed CVT publication, CSV UTF-8 certification, full SOURCE eligibility, or requirement acceptance. Independent Claude implementation QA pending. CP009 Day066: match_analyst_csv_root_snapshot(&str, &[RootSnapshotEntry]) -> RootSnapshotMatch applies CP008 analyst CSV candidate preflight, then exact Rust string equality (case, Unicode scalar sequence and whitespace preserved), reports no match, reported nonregular entry, ambiguous duplicate exact entries, or single caller-reported regular file. Entry origin and kind are caller assertions, not independently verified. Eight new tests; post-format full native regression 36/36; wasm32-unknown-unknown library compilation exit 0; SHA-256 inventory verified 22/22; staged whitespace exit 0; T approved and git banked 15 files, clean working tree. This is NOT actual root scanning, filesystem entry proof, browser permission, CSV/UTF-8 certification, governed CVT SOURCE eligibility or end-to-end requirement acceptance; independent Claude QA pending. CP010 Day066 adds is_governed_cvt_source_filename_candidate(&str)->bool, requiring existing canonical immutable envelope validator, exact CVT class, and exact lowercase .csv serialization token. Four bounded tests pass and native full regression 40/40; wasm32-target library build PASS with Rust 1.97.1; format check PASS; primary 29/29 and supplementary 8/8 SHA-256 verification PASS; staged whitespace PASS with documented exact-file archival exceptions; T approval; git b7c515faa9bd000369d7656e09437310261290ae committed 28 files and clean working tree. No physical file checks, conversion execution, close/reopen, publication predicate, UTF-8/CSV certification, executable SOURCE authority or browser runtime proven. Independent Claude QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-010,WIP and WKO are distinct Work Order lifecycle states,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"WIP is the editable, non-executable Work Order state. WKO is the saved, validated, immutable Work Order artifact that may become a Run target. Validation establishes that a Work Order is structurally eligible to run; it does not guarantee that runtime conditions will succeed. Loading a WKO for inspection does not make it mutable. If its instruction text is changed, the editor must treat the edited text as a new WIP derived from the original WKO. The original WKO bytes and physical identity remain unchanged, and the derived WIP cannot Run until saved as a new WKO. F-08 Run distinction: the browser Run action invokes one selected saved immutable WKO that is eligible under the governed WKO-registry rules. No ordinary WASM-002 WKO contains a textual RUN line merely to execute itself. The DS-STEPS token RUN is reserved for future saved-Work-Order composition under W002-WKO-011 and is not repurposed as the browser execution trigger.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-013,WASM-002 executes one saved Work Order without Work Order chaining,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"For WASM-002, one saved immutable WKO is one top-level executable request. It must not invoke, include, chain, or execute another WKO. The governed RUN composition operation and equivalent nested-orchestration constructs are not executable in WASM-002. If a saved WKO contains composition syntax, validation must refuse before analytical execution begins. The canonical diagnostic and Help path must explain that Work Order composition is deferred rather than treating the syntax as arbitrary text, silently ignoring it, or partially executing surrounding instructions. This scope cut does not prohibit one Work Order from selecting and materializing multiple columns in the single Stage 2 operation defined by WASM-002.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012,Materialization COL alias assignment uses AS; standalone alias maintenance uses UPDATE ALIASES,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within the WASM-002 DS-STEPS materialization form, an analyst assigns or changes the alias of a selected materialized COL with the optional same-line clause AS ""alias"" under W002-STEPS-005. This syntax is part of the governed Work Order and is not a GUI gesture. A single KEEP block may therefore assign aliases to multiple selected columns in one governed materialization. Automatic source-header COL aliases and inherited rematerialization aliases are resolved first; explicit AS clauses then determine requested successor COL aliases before complete Store-MAP validation and publication. Revision BD freezes alias-only creation/replacement with UPDATE ALIASES and explicit historical Store-MAP selection with MAP ""<exact Store MAP filename>"" . Revision BE completes the bounded alias lifecycle with explicit CLEAR ... ALIAS and RESET ... ALIAS forms under W002-WKO-012.5 through W002-WKO-012.6. Empty-string AS """" is not the clearing syntax.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.1,Canonical standalone alias-maintenance Work Order uses UPDATE ALIASES,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"The canonical alias-only Store metadata forms are: SUITCASE: .
WORK ORDER AS ""Rename crime store""
SOURCE ""35100178.csv""
STORE AS ""Crime Statistics""
UPDATE ALIASES or, when the analyst intentionally selects one exact Store snapshot: SUITCASE: .
WORK ORDER AS ""Rename crime store""
MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""
STORE AS ""Crime Statistics""
UPDATE ALIASES UPDATE ALIASES is the explicit terminal commitment clause for an alias-only Work Order. The WKO must identify exactly one Store-state base using either SOURCE ""..."" for ordinary Store-aware current-state selection or MAP ""..."" for exact Store-MAP selection, never both. At least one supported alias mutation clause must occur after the Store-state selector and before UPDATE ALIASES . An alias-only Work Order must not contain KEEP , MATERIALIZE , INVENTORY , conversion, Store repair, Work Order registry repair, cataloging, deferred Work Order composition, or another operation's terminal clause. Alias maintenance changes governed human-facing metadata only.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.2,"STORE AS, RID AS, and COL ... AS are the canonical alias-replacement clauses",W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical mutation clauses are: STORE AS ""Crime Statistics""
RID AS ""Row Number""
COL ""Crime Rate"" AS ""Police-Reported Crime Rate"" STORE AS ""..."" replaces the selected Store snapshot's store_alias . RID AS ""..."" replaces its rid_alias . COL ""<reference>"" AS ""..."" replaces the alias of exactly one existing mapped COL. The COL reference resolves under W002-STOR-021: it may be the exact physical column_filename or one unique current COL alias from the selected Store MAP. Missing, ambiguous, non-COL, or conflicting resolution must refuse rather than guess. One Work Order may update the Store alias, RID alias, and multiple distinct COL aliases together, provided the complete successor state satisfies all existing alias uniqueness/shadowing rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.3,"MAP ""<filename>"" is the exact historical Store-MAP selector",W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"The canonical explicit Store-MAP selection clause is: MAP ""__DS__MAP__20260920T184512347Z__<uuid-v4>.csv"" The value is always the exact physical filename of one structurally valid immutable Store MAP. It is not a Store alias, WKO alias, timestamp shorthand, UUID-only selector, or latest expression. For MATERIALIZE, if present, the clause occurs immediately after SOURCE and before KEEP . It overrides automatic Store-MAP inheritance and binds the run to exactly the named Store snapshot. For alias-only maintenance, the Work Order uses either SOURCE ""..."" or MAP ""..."" as its Store-state selector, not both. For materialization, SOURCE ""..."" remains mandatory and an optional MAP ""..."" supplies the exact historical/current Store-state base. Validation must refuse an incompatible source/MAP pairing or a MAP that is not a valid Store-MAP profile. Health rule: explicit historical selection does not override the current Store-lineage health gate. The selected lineage must currently be VALID and every RID/COL binding referenced by the named MAP must currently be present and valid. Otherwise the operation refuses. This applies equally to MATERIALIZE and UPDATE ALIASES. F-05/P2-01 source-compatibility predicate: for materialization, an explicitly named MAP is compatible only when the mandatory Work Order SOURCE exactly equals the one common source_filename carried by that Store MAP. If the exact filenames differ, validation refuses before the F-04 existing-Store cardinality gate in W002-MAT-002.6. Equal row count never authorizes a different source to enter the selected Store lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.4,Alias-only execution publishes one complete successor Store MAP and no rewritten data artifacts,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"A successful UPDATE ALIASES operation begins from the selected complete Store MAP, applies only the requested alias replacements in memory, validates the complete resulting Store state, writes the successor MAP under governed SCR , closes and reopens it, validates it fully, and promotes it to a new immutable MAP last. That successful promotion is the alias-update commit point. The operation must preserve the selected Store's physical RID and COL filenames and bytes, source-column keys, row order, cardinality, and lineage except for the human-facing alias fields explicitly changed by the Work Order. It must not reread source data rows merely to change aliases, must not create RID/COL artifacts, and must not rewrite or delete the inherited MAP. The prior MAP remains visible historical state. If validation or MAP publication fails, no successor alias state becomes current. The failure is reported through the governed diagnostic/Help path and any incomplete candidate remains subject to the retained- SCR failure-evidence rules in W002-STOR-023.1; WASM-002 does not emit RCV. Revision BM E-02 integration: when the alias-only operation uses an explicitly named historical Store MAP, publication is permitted only if the Store lineage currently evaluates VALID and every RID/COL binding referenced by that named MAP is currently present and valid. An older MAP cannot be used to bypass current damage. P3-06 validation depth: because UPDATE ALIASES does not consume RID/COL analytical contents, its Store-health and binding checks use Tier 1 under W002-STOR-019.10. The operation must not scan every RID/COL record merely to change aliases. This does not weaken later operations that actually consume those artifacts; they must perform the applicable Tier 2 validation before relying on the contents.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-007,Standalone Store/RID/COL alias maintenance acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance must establish a Store with one RID and at least three materialized COLs, then execute an alias-only Work Order that changes the Store alias, RID alias, and at least two COL aliases in one UPDATE ALIASES operation. One COL must be targeted by its unique current alias and another by its exact physical COL filename. The fixture must prove that exactly one complete successor Store MAP becomes current; prior MAP, RID, and COL artifacts remain byte-for-byte unchanged; no source-data row read is required; no new RID/COL artifact is published; and the successor MAP contains exactly the requested aliases while preserving all physical bindings and logical source-column keys. Missing/ambiguous COL references and successor alias collisions must refuse without publishing a successor MAP. F-23 CLEAR/RESET alias fixtures: acceptance must separately exercise CLEAR STORE ALIAS , CLEAR RID ALIAS , CLEAR COL ""<reference>"" ALIAS , RESET STORE ALIAS , RESET RID ALIAS , and RESET COL ""<reference>"" ALIAS . Each CLEAR fixture must prove that the successor MAP stores the governed empty alias without renaming or rewriting the referenced artifact. Each RESET fixture must prove restoration of the exact deterministic default governed by W002-WKO-012.6 and W002-STOR-019.7, including the oversized-header operational fallback where applicable. The fixtures must prove that CLEAR and RESET require no source-data row read, publish exactly one complete successor Store MAP on success, leave the predecessor MAP/RID/COL bytes unchanged, and deterministically refuse duplicate mutation of the same alias field or a reset/default value that fails the complete successor alias validity/uniqueness/shadowing rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-008,Explicit historical Store-MAP selection acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance must create at least two valid Store MAP snapshots for one Store, then prove that a Work Order containing MAP ""<older exact Store MAP filename>"" binds to that exact older snapshot even though a newer valid MAP exists. An alias-only fixture must publish its successor from the explicitly named older base rather than from the newer automatic current state. A materialization fixture must retain mandatory SOURCE ""..."" while using the explicit MAP as its Store-state base. The tests must also prove refusal for a missing MAP, malformed MAP, WKO-MAP profile supplied as Store MAP, and source/MAP incompatibility. No implementation may substitute the newest MAP after an explicit MAP clause has validated. F-21 chronology acceptance: the fixture must use at least three successive valid MAP snapshots for one Store so that an explicitly selected older base and a distinct pre-run current MAP both exist. Merely selecting/validating the older MAP must leave current authority unchanged. A successful governed operation from that older base must then publish exactly one new successor whose requested state is derived from the named older base, whose publication UTC is later than the pre-run current chronology predecessor, and which becomes current under ordinary greatest-UTC selection. The selected historical MAP and the formerly current MAP must remain byte-for-byte unchanged. Acceptance must prove that later mappings/aliases present only in the formerly current MAP are not silently merged into the historical-base successor unless the Work Order explicitly recreates them. Receipt evidence must identify the exact operation base and exact published successor through the already-frozen operation-specific Receipt fields. No additional warning/permission gate or informational diagnostic is required merely because the analyst explicitly chose a historical base.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.5,CLEAR ... ALIAS deliberately removes a human-facing alias,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical clearing forms are: CLEAR STORE ALIAS
CLEAR RID ALIAS
CLEAR COL ""<reference>"" ALIAS CLEAR deliberately stores the empty string in the corresponding alias field of the successor Store MAP. It does not restore a default alias. An empty-string replacement such as STORE AS """" , RID AS """" , or COL ""..."" AS """" is not the canonical clearing form and must be rejected by the bounded WASM-002 grammar. For CLEAR COL , <reference> resolves against the selected pre-mutation Store MAP by exact physical column_filename or one unique current COL alias under W002-STOR-021. All COL references in one UPDATE ALIASES Work Order are resolved before any mutation is applied so clause order cannot change target identity. Missing, ambiguous, duplicate-target, or non-COL references must refuse. Clearing an alias never renames, rewrites, or deletes the underlying RID/COL artifact and never changes physical identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.6,RESET ... ALIAS restores the deterministic default alias,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical reset forms are: RESET STORE ALIAS
RESET RID ALIAS
RESET COL ""<reference>"" ALIAS RESET STORE ALIAS restores the Store MAP's common exact source_filename . RESET RID ALIAS restores the literal RID . RESET COL ""<reference>"" ALIAS restores that mapped COL's deterministic operational default defined by W002-STOR-019.7 from its exact recorded source_header and physical source ordinal: the exact header when it contains at most 1,024 Unicode scalar values, or the deterministic Column <LETTERS> fallback/disambiguation rule when the recorded header exceeds that boundary. RESET never substitutes the potentially oversized exact header into the alias field merely because that header remains authoritative source evidence. RESET is therefore distinct from CLEAR . The restored value must pass the same governed alias validity, uniqueness, and shadowing rules as any explicit alias. If the deterministic default is empty or conflicts in the complete successor Store MAP, RESET must refuse except for the narrow oversized-header fallback/disambiguation rule already frozen in W002-STOR-019.7; Data Sculptor must not otherwise invent a suffix, alternate spelling, or substitute. AS , CLEAR , and RESET mutations may coexist in one Work Order when they target distinct alias fields; duplicate mutation of the same alias field in one Work Order must refuse. A successful operation publishes exactly one complete successor Store MAP under the existing UPDATE ALIASES commit contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001,Canonical WASM-002 DS-STEPS materialization form,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 materialization Work Order form is: # Optional human comment
SUITCASE: .
WORK ORDER AS ""Prepare monthly crime data""
SOURCE ""crime.csv""
[MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""]

KEEP
  HEADER ""REF_DATE"" AS ""Year""      # reporting year
  HEADER ""GEO""
  COLUMN 7 AS ""Crime Rate""

MATERIALIZE SUITCASE: . is governed by W002-WKO-008. WORK ORDER AS ""..."" is mandatory for an executable/saved WASM-002 Work Order and declares the immutable human-facing WKO alias governed by W002-STEPS-001.1. SOURCE ""..."" names the exact Suitcase-root source file. MAP ""..."" is optional with cardinality 0..1. If present, it occurs immediately after SOURCE and before KEEP , names one exact physical governed Store MAP filename, and binds the run to that exact current or historical Store lineage subject to W002-STOR-019.3 and W002-WKO-012.3. If absent, the Store-aware exact-source routing rules apply. KEEP is the bare governed keyword and introduces one or more column selectors. KEEP: is not valid WASM-002 syntax. Each selector is either HEADER ""..."" or COLUMN n and may optionally end with AS ""..."" . MATERIALIZE is the explicit terminal commitment verb. Duplicate structural clauses refuse. An empty KEEP refuses. After MATERIALIZE , only blank lines or comments may follow; a trailing comment on the physical MATERIALIZE line is permitted because comments are removed from the semantic token stream. # comments are governed by W002-STEPS-001.2. No RID/row-index clause appears in the Work Order. If this materialization establishes a new Store, the engine automatically generates exactly one RID artifact under W002-RID-002 and W002-RID-008. If it extends an existing Store, the existing RID is reused subject to the Store health/cardinality rules. This requirement freezes the bounded keyword structure and selector forms shown above for BM integration. Other complete-language lexical features remain outside this bounded syntax freeze unless separately specified. F-08 common-grammar boundary: MATERIALIZE is one of the seven executable WASM-002 operation grammars governed by W002-WKO-007. Its optional MAP clause remains in the frozen position immediately after SOURCE and before KEEP . The terminal MATERIALIZE clause is DS-STEPS syntax; the browser's Run action is not written into the Work Order. F-20 bounded KEEP: the canonical KEEP block contains at least one and at most 16,384 selectors, and after resolution those selectors must identify at least one and at most 16,384 distinct source columns. This is the complete WASM-002 selection-width bound.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001.1,WORK ORDER AS declares the immutable human-facing Work Order alias,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"An executable or saved WASM-002 Work Order must contain exactly one top-level clause: WORK ORDER AS ""<alias>"" In canonical forms it appears after SUITCASE: . and before the operation-specific source/selector clauses. The decoded alias must be non-empty. The quoted alias may contain spaces and ordinary UTF-8 phrase text subject to the governed string-literal rules. The alias affects display and governed alias resolution only; it does not replace the WKO filename/UUID as physical execution identity. The alias is stored in the immutable WKO bytes and is published into the current WKO MAP when the WKO save transaction commits. Changing the alias therefore requires saving a new WKO under the frozen WKO lifecycle. No valid executable/saved WKO in WASM-002 is unaliased. P3-10 alias-content rule: “non-empty” means that, after decoding the quoted string literal, the alias must contain at least one non-whitespace character. An alias consisting only of whitespace refuses Work Order validation. Data Sculptor must not trim, collapse, normalize, or otherwise rewrite leading or trailing whitespace in an otherwise valid alias; the decoded alias text remains authoritative and is preserved exactly in the immutable WKO and governed WKO MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001.2,# introduces a DS-STEPS line comment outside double-quoted strings,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"Outside a double-quoted string, the first # on a line begins a comment that continues through the line's LF terminator. Whole-line comments and trailing comments are permitted. Comment text has no execution semantics and is ignored by the DS-STEPS parser after lexical recognition. A # inside a double-quoted string is ordinary string content and does not begin a comment; for example WORK ORDER AS ""Analysis #3"" and HEADER ""CATEGORY #"" preserve the hash character. WASM-002 defines no block-comment syntax. Comments are preserved byte-for-byte in the saved immutable WKO TXT. Editing, adding, or removing a comment changes the WKO bytes and therefore requires saving a new WKO artifact even though analytical semantics may remain unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-002,HEADER selects by exact decoded source-header value,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"HEADER ""name"" resolves against the exact decoded header values established for the certified source. Header equality is exact Unicode scalar-value sequence equality under PB-STOR-010: Data Sculptor performs no case folding, locale folding, Unicode normalization, trimming, or filesystem-style comparison. A selector that matches no source header must refuse. If the same exact decoded header sequence occurs in more than one source column, the header selector is ambiguous and must refuse rather than choose by position, discovery order, normalization, case-insensitive similarity, or another heuristic. An analyst can disambiguate duplicate exact header text with the 1-based COLUMN n selector. F-20 selector identity: HEADER always matches the authoritative exact decoded source header. It never matches an operational fallback name such as Column AA , a generated collision-disambiguation suffix, a COL alias, or a truncated form of the source header.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-003,COLUMN selects by 1-based source ordinal,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"COLUMN n identifies the source column by 1-based ordinal position. COLUMN 1 is the first source column. Zero, negative values, non-integers, and ordinals greater than the source width must refuse. Ordinal selection does not suppress source metadata: Data Sculptor must still resolve and record the selected column's actual decoded source header in the successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-004,HEADER and COLUMN selectors may be mixed but may not select one source column twice,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"One KEEP block may contain any supported mixture of HEADER and COLUMN selectors. Selector order expresses the analyst's requested selection order for the governed operation. After resolution, two or more selectors that identify the same physical source column constitute a duplicate selection and must refuse before materialization. Data Sculptor must not materialize the same source column twice merely because it was named once by header and once by ordinal.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-005,AS assigns the resulting materialized-column alias,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The optional clause AS ""alias"" belongs to the immediately preceding HEADER or COLUMN selector and expresses an intentional human-facing alias assignment in the governed Work Order. For a logical source column not present in the inherited MAP, omission of AS uses the exact source header as the default alias. For a logical source column already present in the inherited MAP, omission of AS preserves the inherited alias. An explicit AS overrides either default for the successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-006,The complete successor MAP must contain unique aliases,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"After inheritance, selector resolution, default-alias application, rematerialization continuity, and all explicit AS clauses are applied, every alias in the complete successor MAP must identify exactly one logical materialized column. If two different logical columns would have the same alias, including a collision with an inherited mapping, validation must refuse unless the Work Order has explicitly resolved the conflict through supported governed syntax. Data Sculptor must not invent suffixes such as Year_2 , use last-write-wins behavior, or silently shadow an existing alias. F-20 narrow generated-name exception: the prohibition on invented suffixes applies to ordinary source-header defaults and analyst-authored aliases. The only automatic suffixing permitted in WASM-002 is deterministic disambiguation of an oversized-header operational fallback under W002-STOR-019.7. That mechanism is not an alias-repair heuristic and must not be applied to an explicit AS value or to a short exact source-header default.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-007,MATERIALIZE commits the resolved KEEP set to the governed structural pass,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"MATERIALIZE is the explicit commitment verb for this WASM-002 DS-STEPS form. The KEEP selectors express which source columns belong in the operation; they do not themselves authorize data-row materialization. Before the bounded structural pass begins, the source, all selectors, actual source ordinals/headers, requested aliases, inherited alias state, and resulting alias uniqueness must be resolved and validated. Successful multi-column execution then follows the one-pass materialization contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-008,The Store MAP records resolved truth rather than selector spelling,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The successor Store MAP must record the fully resolved materialization result using the frozen eight-column schema store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename , regardless of whether the analyst selected a column with HEADER or COLUMN . For example, COLUMN 7 AS ""Crime Rate"" records the Store alias, RID filename/alias, common source filename, source ordinal 7 , the actual decoded header found at column 7, alias Crime Rate , and the newly generated physical COL filename. DS-STEPS expresses intent; the Store MAP persists the resolved durable mapping truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-009,DS-STEPS materialization syntax acceptance,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"Acceptance must cover: one column selected by exact header; one column selected by 1-based ordinal; mixed header/ordinal selectors in one KEEP block; multiple columns materialized in one governed structural pass; AS alias assignment; default header aliasing; inherited-alias preservation on rematerialization; explicit alias replacement on rematerialization; duplicate-header ambiguity refusal; invalid ordinal refusal; duplicate resolved-column refusal; and duplicate successor-alias refusal. Acceptance must also prove that the generated successor MAP records the same resolved source filename, source ordinal, actual source header, resulting alias, and physical COL identity whether a column was selected by header or by ordinal. For a new Store, both the single-column and multi-column materialization fixtures must contain no RID/row-index instruction yet must automatically publish exactly one RID artifact. For a later permitted same-Store materialization, the fixture must likewise contain no RID instruction and must reuse the original RID without publishing another. Damaged-lineage Help acceptance: fixtures must prove that exact source routing to an INVALID Store, and to a DEGRADED Store whose every mapped COL is broken, refuses ordinary materialization without silently treating the source as unseen. The canonical diagnostic/Help evidence must identify the blocked lineage/current MAP and preserve the frozen analyst-owned exits: external restoration under the original governed physical filename followed by governed validation; source rename to begin a distinct new Store lineage; or moving all lineage MAPs out of the active Suitcase to retire that lineage from routing. The all-COLs-broken fixture must warn that moving only the latest MAP is insufficient. No fixture may imply a new Data Sculptor recovery command, automatic RID regeneration, silent replacement of the damaged lineage, or historical byte identity based only on a restored filename. P3-06 validation-tier acceptance: acceptance must prove that a routine routing/status or alias-only path can use Tier 1 without an end-to-end scan of every RID/COL value, while an operation that consumes artifact contents performs Tier 2 before relying on them. Fixtures must include: a RID that passes Tier 1 but fails Tier 2 because its declared N /sequence is internally wrong beyond the Tier-1 boundary; a COL that passes Tier 1 but fails Tier 2 because its data-record count or CSV body is invalid beyond the Tier-1 boundary; and a REPAIR MAP fixture proving that the Tier-2 failure set determines exactly which COL bindings are removed. P3-07 routing acceptance: fixtures must prove that routing discovers a lineage from a structurally valid Store MAP regardless of whether later Store-health evaluation is VALID , DEGRADED , or INVALID . A separate fixture must present no routable lineage together with at least one structurally malformed Store-MAP-class artifact in the active Suitcase and prove that ordinary materialization refuses before publishing a new RID or first Store MAP, while Help identifies the malformed MAP artifact or artifacts. No fixture may treat an all-MAPs-damaged condition as permission for a silent replacement lineage. F-08 cross-operation grammar acceptance: fixtures must prove the common preamble, ASCII-case-insensitive keywords, exact quoted-value preservation, required SPACE/TAB token separation, unknown-line refusal, one-operation-per-WKO refusal, and separation between DS-STEPS terminal phrases and Receipt OPERATION tokens. At least one fixture for each of the seven executable operations must prove that its canonical structure validates while an otherwise similar WKO containing another operation's terminal clause refuses. Separate fixtures must prove that browser Run does not require a textual RUN clause and that parsed RUN composition syntax refuses as deferred before analytical execution. P2-04 restoration-language acceptance: Help, diagnostics, UI text, and acceptance evidence may say that a file restored under the exact governed physical filename passed the required validation tier and may therefore re-enter use. They must not state or imply that filename equality alone proves restoration of the historical original bytes. If stronger historical-byte identity is desired, Help may point to the separately governed explicit fingerprint/LCK direction rather than silently hashing ordinary Store artifacts. F-20 selector/name/width acceptance: fixtures must additionally prove that HEADER resolves only against exact decoded source-header text and never against an operational fallback/default alias; a KEEP selecting all 16,384 columns is valid; a source wider than 16,384 refuses before data-row materialization; and RESET of an oversized-header COL restores the deterministic operational fallback rather than the exact oversized header as alias text. F-03 Store-health and REPAIR MAP acceptance set Target required: REPAIR MAP without exactly one current Store MAP target refuses. Historical target: a structurally valid but non-current historical Store MAP refuses for repair. Wrong profile: a WKO MAP supplied as the repair target refuses. DEGRADED repair: one or more broken COL bindings are removed while every valid binding and the exact RID identity are preserved. All COLs broken: repair refuses, publishes no successor MAP, and the Store remains DEGRADED . Malformed newest MAP: current-state resolution falls back to the greatest earlier structurally valid MAP in the same lineage and reports the malformed artifact. Missing COL in current valid MAP: no fallback occurs; the current MAP remains current and the Store evaluates DEGRADED . Missing RID in current valid MAP: no fallback occurs; the current MAP remains current and the Store evaluates INVALID . Original RID externally restored: the Store is re-evaluated after governed validation without Data Sculptor creating or inferring a replacement RID. No silent fork: neither DEGRADED nor INVALID permits ordinary materialization to create a replacement Store for the same routed lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-003,Suitcase-relative Work Order portability acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must execute a saved WKO containing SUITCASE: . and ordinary Suitcase-relative file references, then move the intact fixture Suitcase to a different permitted parent path and execute the same saved WKO again. Resolution must identify the same logical Suitcase files without editing the WKO to insert the new absolute machine path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-004,WIP/WKO lifecycle acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance evidence must show that an editable WIP cannot Run; saving a valid WIP produces a distinct immutable WKO Run target; loading that WKO and changing instruction text creates a new non-runnable WIP; and the original WKO bytes, filename, identity, and provenance remain unchanged. F-02 alias-registry lifecycle acceptance: a first save for an unused alias must publish a successor WKO MAP containing exactly one CURRENT row for that alias. Saving a second valid WKO with the same exact alias must surface exactly Replace alias target and Cancel . The Cancel fixture must leave the predecessor WKO MAP authoritative and must not commit the pending WKO/WKO-MAP pair as a registry update. The Replace fixture must publish a successor WKO MAP in which the former owner is DEPRECATED , the new WKO is the sole CURRENT row for that alias, and any earlier deprecated history remains preserved. The former WKO bytes and filename and every predecessor WKO MAP must remain unchanged. Alias resolution against the successor registry must resolve to the new CURRENT row and never to a DEPRECATED row. A malformed fixture containing more than one CURRENT row for one exact alias must fail structural validation rather than choose by filename UTC, modified time, discovery order, or row order. P2-03 WKO-registry clock acceptance: using a deterministic injected clock seam, acceptance must prove that a successor WKO MAP publishes only when the observed transaction UTC is strictly greater than the current structurally valid WKO MAP UTC; equal-millisecond and backward/future-dated-predecessor cases refuse without committing the new WKO/registry state. The diagnostic must expose predecessor_map_filename , predecessor_utc , and observed_host_utc . A separate fixture must deliberately move the future-dated current WKO MAP out of the active Suitcase, rescan, and prove deterministic reselection of the remaining current structurally valid WKO MAP without Data Sculptor silently moving or deleting anything itself. Day 060 H-12: every equal/backward/future-predecessor chronology refusal in this acceptance set must emit DS-UTC-001 with exact map_profile: WKO , observed_host_utc , predecessor_map_filename , and predecessor_utc facts. F-23 save-transaction filesystem-fault fixture, reconciled by F-33: using a controlled create/write/close/rename/promotion failure at a deterministic point after a valid WIP has entered the governed save path, acceptance must prove that a failed WKO/WKO-MAP save is never represented as a committed alias-registry update. The pre-run current WKO MAP must remain authoritative; no malformed or unpromoted candidate may become current; and any rollback or retained SCR evidence must follow W002-STOR-018.3 and the shared non-Store publication/retained-evidence contract. No RCV artifact is emitted. F-02 registry-repair acceptance set Deadlock escape: with a repair-required current WKO MAP, a newly saved structurally valid repair-only WKO can Run by exact filename and successfully publish a repaired successor registry. No broad bypass: a newly saved unregistered WKO for any other operation remains ineligible to Run. Missing reference: repair removes a stale registry row but does not recreate the missing WKO, substitute a historical WKO, or promote an older WKO automatically. Discovered alias, no owner: one discovered valid WKO with an otherwise unowned alias becomes CURRENT . Discovered alias collision: a discovered WKO whose alias is already owned by a surviving CURRENT row becomes DEPRECATED . Several discovered WKOs, no owner: all become DEPRECATED ; no winner is inferred by UTC, filename, UUID, directory order, discovery order, or modified time. Mandatory alias: an unaliased WKO cannot be structurally valid. Line endings: otherwise-identical structurally valid WKO fixtures with LF and CRLF line endings are accepted; the lone-CR form refuses. Deterministic successor: repaired successor rows serialize in ascending UTF-8 byte order of exact wko_filename . Historical Run: a registered DEPRECATED WKO can Run by exact physical filename but not by alias. Receipt identity: a successful or refused registry-repair Receipt uses REPAIR_WORK_ORDER_REGISTRY as the operation token. Day 060 H-10 / BM-07 registry-repair Receipt-count acceptance Acceptance must include a successful repair-required-registry fixture in which the exact repair-only bootstrap WKO is initially visible and unregistered, runs by the bounded exact-filename bootstrap, and is then registered by the repair result. The committed successor WKO MAP must contain the repair WKO row. The successful Receipt must list that exact repair WKO under either REGISTERED_CURRENT_WKO_<INDEX>_FILENAME or REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME , according to the ordinary alias-ownership rule. The corresponding REGISTERED_*_COUNT must equal the number of newly registered rows in that status class, including the repair WKO when applicable. Pre-existing surviving CURRENT / DEPRECATED rows in the base registry must not inflate either registered count. A fixture containing both pre-existing surviving rows and newly registered rows must prove that the Receipt reports the repair change set while the successor MAP reports the complete resulting registry state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-005,"Store MAP inheritance, historical override, and immutable snapshot acceptance",W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must execute a saved Store-establishing Work Order containing multiple COL alias assignments when no routable Store lineage exists and no structurally malformed Store-MAP-class artifact is present , and prove that exactly one new immutable complete Store MAP is created while the GUI supplies no alias-edit gesture and target artifacts remain unchanged. A later Work Order with the same exact source and no explicit MAP must route to that Store's lineage and inherit its unique newest permitted MAP automatically. Another Work Order must explicitly select an older valid MAP even though newer MAPs for that Store exist and prove that Store/RID binding, alias resolution, and inheritance use exactly the named historical MAP instead. A fixture specifying more than one MAP must refuse. A fixture with two otherwise permitted current MAP candidates for the selected Store sharing the greatest UTC millisecond timestamp must refuse automatic inheritance rather than use UUID as chronology. A separate fixture must remove or corrupt every Store MAP in a prior lineage so that no structurally valid Store MAP remains while at least one malformed Store-MAP-class artifact remains visible in the active Suitcase. Re-running ordinary materialization must refuse before creating a new RID or first Store MAP, and Help must identify the malformed MAP artifact or artifacts. P2-03 Store chronology acceptance: injected-clock fixtures must prove later observed UTC success, equal-millisecond refusal, backward-UTC refusal, and a genuinely future-dated current Store MAP that remains current while blocking successor publication. Every refusal must leave the chronology predecessor unchanged and publish no successor Store MAP. A historical-base fixture must derive requested state from an older eligible MAP while proving that the strict-greater-than comparison uses the actual current Store MAP as chronology predecessor, not the historical base. A deliberate analyst-removal fixture must move the future-dated current MAP out of the active Suitcase and prove deterministic reselection of the remaining structurally valid history; restoring that MAP must make ordinary greatest-UTC authority rules applicable again. Day 060 H-12: every equal/backward/future-predecessor Store-MAP chronology refusal in this acceptance set must emit DS-UTC-001 with exact map_profile: STORE , observed_host_utc , predecessor_map_filename , and predecessor_utc facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-006,Work Order chaining refusal acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must submit a structurally saved WKO containing a RUN or other recognized Work Order-invocation construct and prove that WASM-002 refuses it during validation before Stage 1, Stage 2, conversion, inventory, or other governed execution begins. The diagnostic/Help output must identify composition as deferred functionality. A separate multi-column MATERIALIZE fixture must still succeed, proving that multiple selected columns inside one Work Order are not misclassified as Work Order chaining.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-001,One explicit Work Order command surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser front end shall use the Work Order editor as the single human command-entry surface for governed execution. It shall not expose a second interactive command prompt or point-and-click analytical path that can become an independent source of analytical intent. The editable draft may be syntax-highlighted, validated, and saved, but it is not itself executable authority. The browser Run action operates only on one loaded/selected saved immutable WKO that is eligible under the governed Work Order registry rules. Run is a browser action, not a line that ordinary WASM-002 Work Orders must contain. If a WKO contains the reserved DS-STEPS RUN composition token, WASM-002 refuses before executing any child or top-level analytical operation because saved-Work-Order chaining is deferred. The token remains reserved so later ordered composition can be added without repurposing existing syntax. F-24 fresh-application state: each new Data Sculptor browser application instance begins without a selected Suitcase and without a restored unsaved Work Order draft. Initial page load and full reload therefore return the command surface to the pre-Suitcase gate. A previously selected folder, loaded WKO, or dirty WIP must not be silently reconstructed from browser-private persistence.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-002,Front end presents and authorizes; shared Rust core decides,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser front end may authorize files, edit and validate Work Orders, invoke the shared engine, display governed state, render diagnostics, and present generated artifacts. It must not independently decide analytical truth, silently reinterpret a Work Order, or implement a competing semantic path. Where front-end presentation and shared-core semantics disagree, the shared governed semantics and frozen requirements are authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-003,Visible Suitcase and governed run context,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser surface shall make the currently validated Suitcase visible and shall expose the visible files in that folder. Source and requested-column context become governed execution state only when a saved Work Order resolves them; the UI must not imply that directory presence alone means a source has been selected, scanned, certified, or materialized.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-004,Certification gate is visible and blocking,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The front end shall visibly represent strict whole-file UTF-8 certification as a required stage before analytical materialization. A certification refusal must stop the current analytical Work Order, prevent later materialization stages from being presented as successful, and provide the canonical diagnostic / Help path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-005,One-pass multi-column materialization is represented truthfully,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"When a valid Work Order requests multiple source columns, the front end shall represent them as one governed multi-column materialization request through one bounded structural CSV pass, not as unrelated per-column scans when the frozen engine contract performs one pass. Requested columns must be validated before data-row materialization begins, consistent with the materialization requirements.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-006,Visible Suitcase Directory is the artifact orientation surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"After Suitcase validation, the browser shall present a human-readable directory view of the visible files in the selected Suitcase, including physical filename, read-only governed alias where applicable, file type, and size. Governed artifacts created by a run shall appear in that same visible inventory after refresh or update. The directory is an orientation and metadata surface over the real flat Suitcase. It is not a hidden browser cache, a second persistence system, or an analytical command surface. CAT integration: this existing directory remains the sole WASM-002 artifact-orientation surface. CAT and MAP artifacts are first-ranked under W002-CAT-UI-001 through W002-CAT-UI-008; no second catalog browser is introduced.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-007,All user-facing Help flows through the Help Engine,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"All Data Sculptor-controlled user-facing Help messages, warnings, refusals, explanations, validation guidance, safe-next-action messages, and governed success/status messages that participate in the Help/status/evidence system shall be produced through the Help Engine from governed facts or canonical diagnostic events. Individual UI controls must not maintain an independent competing stock of semantic Help text. Governed success/status events in this system use canonical INFO diagnostics. Ordinary static labels, headings, decorative copy, and presentation-only UI text are not diagnostics and need not be routed through the diagnostic registry merely because they are visible. Help voice may change wording and depth but must not change diagnostic identity, evidence, severity, refusal/continue behavior, provenance, or safe next action. Durable Help Reports derive from the same governed truth. F-17 fallback behavior: when a complete registered diagnostic lacks an authored help_messages.json entry, the UI must show the deterministic Generic Technical Help rendering from W002-HELP-002.9 for Casual, Office Speak, and Technical selections rather than a blank state, guessed prose, or UI-local explanation. When diagnostic assembly itself fails its required-fact contract, the UI presents DS-HLP-001 ; it must not display the incomplete intended diagnostic as if valid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-008,Legacy encoding conversion remains a separate operation,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"If UTF-8 certification fails and the bytes are eligible for the separately governed Windows-1252 compatibility/conversion path, the front end may explain or help draft that separate conversion Work Order. It must not silently reinterpret the failed analytical Work Order as Windows-1252 and continue materialization. P3-08 front-end disclosure: after a successful conversion, the visible result/Help path must identify the exact published CVT filename and explain that it is a new source identity for later Store routing. When that CVT is subsequently chosen for first materialization, the front end must not present the action as a refresh of an earlier conversion-derived Store merely because the analyst-owned input filename is the same; it must preserve the governed Help disclosure that each distinct CVT is a distinct source artifact and lineage input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-009,Front-end branding is presentation-only,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser front end shall use the canonical built-in Red5Sorcery/Data Sculptor branding and approved presentation tokens without changing analytical or diagnostic meaning. The current Red5Sorcery identity treatment, including the red “5”, remains the active WASM-002 design direction. Configurable Brand Manifest loading, validation, selection, and substitution are deferred to V1-BACKLOG / a future build whose number is not yet assigned.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-010,WASM-002 front end must not preview deferred analytical features as available controls,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 front end shall stop at the capabilities allocated to the WASM-002 build slice. It shall not present filtering, grouping, sorting, Quick Viz, PRETTY Tables, DS-VERIFY, or later filter-driven build/export workflows as executable WASM-002 controls unless their individual requirement SCOPE is deliberately changed and frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PLAT-001,WASM-002/V1 browser and modest-hardware acceptance baseline,W002-PLAT,W002-PLAT,WASM-002,UNDER REVIEW,—,"The canonical modest-hardware acceptance machine for the WASM-002 browser release and the browser path carried into V1 is the project's 11-inch Windows 11 laptop with an Intel N100 processor, 16 GB RAM, and a 1920×1200 native display. Each acceptance record must capture the exact tested Windows build, browser version, Windows display scaling, browser zoom, and materially relevant machine configuration. Those observed version and presentation settings are acceptance evidence; they do not become timeless minimum-version requirements unless separately frozen. V1 browser support is scoped to certified desktop Chromium hosts that expose the user-selected writable-directory and file-publication capabilities required by the visible Suitcase contract. Microsoft Edge is the primary certified browser. Google Chrome is the secondary certified browser. Another Chromium-derived browser may work, but Data Sculptor must not claim it as a certified V1 browser until that browser has passed the applicable acceptance suite. Firefox and Safari are not supported V1 browser hosts under this contract and their lack of the required filesystem capability must not block V1 release. Supported-host acceptance must exercise the real browser filesystem path: explicit user-selected Suitcase access, CER validation, governed Work Order save/Run behavior, and governed artifact publication. Data Sculptor must not substitute OPFS, IndexedDB, download-only publication, a browser extension, or another hidden/different persistence model merely to make an unsupported browser appear supported. Required filesystem capability is feature-detected before folder validation begins. If the host cannot expose the governed writable-directory contract, Data Sculptor must treat that state as a host-capability refusal , keep governed save/Run/analytical controls locked, and route the explanation through the canonical diagnostic/Help path. It must not claim that a particular user folder failed validation when no folder could actually be tested.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-011,"Keyboard-operable, small-screen browser shell",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The required WASM-002 front-end interactions shall remain operable from a keyboard and usable on the canonical modest-hardware/small-screen baseline defined by W002-PLAT-001. At the display scaling and browser zoom recorded for acceptance, every required control and governed surface needed to complete the supported workflow must remain reachable without changing those settings merely to reveal an otherwise inaccessible control. Responsive reflow and ordinary scrolling are permitted; this requirement does not demand that every panel be visible simultaneously. Visible labels must carry meaning without relying on color alone. Exact shortcut assignments are presentation details unless separately frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-012,"Reference prototype is evidence, not a shadow specification",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Day 043 HTML prototype embedded below is retained as concrete design evidence for the WASM-002 browser workbench. Its layout, simulated analytical execution, illustrative Work Order grammar, current aliases, demo shortcuts, artifact examples, and other unfrozen literals do not become normative merely because they appear in the prototype. If the embedded prototype conflicts with a numbered requirement, the numbered requirement governs and the prototype must be revised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-013,Dedicated persistent Help / Diagnostic Surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The primary WASM-002 workspace must reserve a dedicated Help / Diagnostic Surface with stable layout presence. When a governed diagnostic is active, the analyst must be able to view its explanation without losing sight of the Work Order and the execution/source context required to understand it. The persistent surface is a viewport into canonical diagnostic truth; it is not a second state authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-014,Governed analytical refusals are not modal- or toast-only interactions,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,An application-controlled modal dialog must not be the primary presentation of a governed analytical refusal when it would obscure the Work Order or execution context. A transient toast or timed notification must not be the sole carrier of governed diagnostic truth. Browser- or operating-system-controlled permission/security dialogs are outside this requirement because Data Sculptor does not control their presentation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-015,Idle Help state remains semantically quiet,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"When no canonical diagnostic is active, the Help / Diagnostic Surface should communicate only restrained readiness/idle state rather than becoming a general dashboard for unrelated metrics, checkpoints, or project status. Exact wording such as “No active diagnostic. Ready.” is presentation detail unless separately frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-016,Help surface exposes a direct saved-report action,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"From an active governed diagnostic, including a non-run diagnostic, or from one governed Run whose diagnostic history is available to the Help surface, the browser Help / Diagnostic Surface must provide an explicit action to generate the durable HTML Help Report. Each explicit report request publishes exactly one HLP under W002-HELP-003.2 and W002-HELP-009. The generated report must become a visible Suitcase artifact governed by the Help, PRETTY, persistence, and provenance requirements and must use the canonical built-in Data Sculptor presentation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-017,Writable Suitcase validation is the first interaction gate,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Before Data Sculptor enables Work Order saving, governed Run, or analytical processing, the analyst must choose one Suitcase folder and Data Sculptor must validate that folder by successfully creating, completely writing, and closing one governed HTML Suitcase Validation Certificate under W002-STOR-022 through W002-STOR-022.3. Permission state or directory enumeration alone is not sufficient to pass the gate. The successful certificate remains visibly in the Suitcase as durable evidence. Validation does not require deleting or renaming the certificate. Until the certificate write/close succeeds, the analytical workspace remains locked except for Help and Suitcase selection. Browser- or operating-system-controlled refusal of protected directories is outside Data Sculptor presentation control and must be explained through the Help Engine when the host can observe the refusal. F-24 opening/selection lifecycle: merely loading Data Sculptor does not create a CER. A CER is published only after an explicit Suitcase selection successfully passes the governed validation gate. Reselecting and successfully validating the same physical Suitcase is a new certification event and publishes one new CER; all earlier CERs remain untouched. Data Sculptor does not remember the directory handle between application instances, so a new load/reload requires explicit Suitcase selection again before the workspace can unlock.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-018,Suitcase Directory enumerates visible files before analytical work,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Immediately after Suitcase validation, Data Sculptor shall enumerate the visible files available through the authorized directory handle and show them in the Suitcase Directory. No source, header, column, certification, or materialization state shall be inferred merely from the existence of those files.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-019,Directory inventory and displayed aliases must not become point-and-click analytical intent,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Suitcase Directory may expose file inventory and read-only human-facing metadata such as aliases, but it shall not provide alias-edit controls, “Use as source,” column-pick, materialize, filter, or equivalent governed-action controls. Source files, requested columns, alias mutations, and analytical operations are stated in saved Work Orders and resolved by the governed engine.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-020,Saved Work Orders are the only Run targets,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Work Order editor may create a new draft or load a saved Work Order TXT artifact from the validated Suitcase. A loaded saved Work Order is an immutable Run target and may be inspected or run directly. If the analyst changes its instruction text, the editor must transition to a new draft derived from that saved Work Order; the draft is not runnable until it is saved as a new immutable Work Order with a new governed physical identity. The original saved Work Order remains unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-021,User chooses the Suitcase; Data Sculptor chooses generated filenames,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"For Work Orders, materialized columns, Help Reports, receipts, maps, and other Data Sculptor-generated artifacts, the analyst chooses or has already chosen the validated Suitcase folder. The browser shall not require the analyst to supply an output filename for those governed artifacts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-022,"Execution Output is read-only observation, never command input",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser shall provide a read-only Execution Output surface that reports which saved Work Order was run, how its source and governed aliases resolved, which execution stages occurred, what was refused, and which governed artifacts were created or assigned. For WASM-002 it does not display a nested Work Order invocation chain because Work Order composition is deferred. The surface shall not accept commands, analytical text, or cursor-driven execution input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-023,The browser has no separate Work Order Description field,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser must not expose a standalone editable Description field for a saved or draft Work Order. Human-facing Work Order naming is authored in DS-STEPS with the required WORK ORDER AS ""..."" clause inside the Work Order itself. The Saved Work Order chooser and Suitcase Directory may display governed WKO alias/lifecycle information from the current structurally valid WKO MAP . Where lifecycle information is shown, CURRENT and DEPRECATED are read-only governed registry state, and the exact physical WKO filename must remain available/visible so human meaning, lifecycle authority, and physical identity remain distinct. Alias resolution uses the sole CURRENT row for the exact alias; a DEPRECATED row is historical evidence rather than the alias target. If that current registry references a missing physical WKO, the MAP remains current and the registry is repair-required; the browser must not silently display an older WKO MAP as though it had become current merely because of the missing reference. A structurally malformed newer WKO MAP never becomes current and is reported through Help/evidence surfaces. Editing a loaded saved WKO—including changing its alias or comments—creates a derived draft that must be saved as a new immutable WKO before it can Run. If that save would supersede the existing CURRENT target for the same alias, the save flow follows the exact Replace alias target / Cancel decision in W002-STOR-018.3; the UI must not provide a separate direct registry-edit gesture.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-024,Suitcase Directory aliases are read-only views of governed MAP profiles,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Alias displays in the Suitcase Directory are observation-only. Store, RID, and materialized-COL aliases are read from eligible Store MAP state. Saved Work Order alias and lifecycle state are read from the current structurally valid WKO MAP. The browser may aggregate those governed sources into one human-facing directory view while keeping exact physical filenames available for inspection. For WKO rows, CURRENT / DEPRECATED is read-only governed lifecycle metadata. A CURRENT row identifies the registry target for that exact alias; a DEPRECATED row remains historical registry evidence and must not be presented as the current alias target. The GUI must not expose an input, inline editor, context action, or other non-Work-Order path that directly mutates governed aliases or WKO lifecycle status. Store/RID/COL alias mutation remains Work-Order-governed. WKO aliases are authored inside immutable WKO text with WORK ORDER AS and enter or change WKO alias-registry authority only through a successful governed save transaction under W002-STOR-018.3.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-025,The browser has exactly two governed built-in presentation themes,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser presentation contract exposes exactly two governed theme choices: Modern Dark and Modern Light . Custom presentation is deferred to V1-BACKLOG / a future build not yet numbered. A Terminal theme is not part of the WASM-002/V1 browser contract and must not be exposed as a governed theme choice. Theme selection is presentation-only. It must not change Work Order semantics, source resolution, diagnostic identity or facts, continue/refuse decisions, analytical values, Receipt truth, or other governed execution meaning. The selected browser theme does not control durable HLP or CER presentation in WASM-002. Those governed HTML artifacts use the canonical built-in Red5Sorcery/Data Sculptor presentation regardless of whether the live browser is using Modern Dark or Modern Light. F-24 session default and persistence: Modern Dark is the canonical theme at the start of every new browser application instance. The analyst may switch to Modern Light during that instance, but WASM-002 retains the choice only in volatile runtime state and does not persist it in browser-private storage. A new application instance therefore returns to Modern Dark.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-026,Flight Recorder is a read-only derived Receipt-history surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser may present a Flight Recorder surface that is derived exclusively from governed RCP Receipt artifacts currently visible in the authorized Suitcase. The surface is read-only and regenerable. It must not create or maintain a second execution-history database, mutable log, hidden cache, browser-private history, or alternate chronology authority. The Flight Recorder may sort, filter, group, or summarize Receipt-derived facts for human orientation, but those presentation operations must not alter Receipt bytes, invent missing events, or become authoritative over the underlying immutable Receipts. Where no canonical Receipt exists because Receipt publication failed, the surface must not reconstruct a substitute original Receipt from UI state, console text, or memory.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-001,Single-command-surface and saved-run-target acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The acceptance check must show one Work Order editor that can hold either a new draft or a loaded saved Work Order and no second independent prompt, command-entry cursor, point-and-click source selector, or point-and-click column selector. A governed browser Run must read exactly one loaded/selected saved immutable WKO artifact that is eligible under the current registry rules. An unsaved WIP must not Run. Editing the instruction text of a loaded saved WKO must transition the editor to a new draft state that cannot Run until saved as a new immutable WKO. A fixture containing the exact reserved semantic token RUN as a Work Order composition construct must refuse before any governed operation executes and must reach the deferred-composition Help path. A near-synonym such as CALL , EXEC , or INCLUDE must not be silently accepted as composition syntax.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-002,Certification-refusal gating acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a source fixture that fails strict UTF-8 certification, the browser must show certification failure, leave later analytical stages unaccepted, produce no materialized analytical outputs, preserve the source unchanged, and expose the canonical Help path. The retained event/Receipt evidence must agree on STAGE1_UTF8_OUTCOME: FAIL , exact UTF8_FIRST_INVALID_BYTE_OFFSET , and UTF8_STOP_REASON: INVALID_UTF8_SEQUENCE . The canonical diagnostic event must expose the same meaning through lower-case facts first_invalid_byte_offset , source_filename , and stop_reason .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-003,Multi-column path acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a valid UTF-8 source and a Work Order requesting at least two source columns, the browser must show successful certification followed by one governed structural materialization pass and then expose the resulting visible Suitcase artifacts required by the build contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-004,Diagnostic/Help parity acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"For at least one real WASM-002 refusal path, the live message, each supported Help voice, and the durable HTML Help report must resolve from the same canonical diagnostic event and preserve the governed facts, severity, provenance, refusal behavior, and safe next action.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-005,Visible-persistence and Suitcase-directory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"A completed governed browser run must be auditable from the visible Suitcase artifacts required by the build contract, and newly created governed artifacts must become visible through the Suitcase Directory. Acceptance evidence must show that Data Sculptor did not intentionally persist project or analytical state in browser-private storage as a substitute for those artifacts. F-24 session/CER lifecycle acceptance: acceptance must begin from a clean application instance and prove all of the following in one controlled sequence: no Suitcase is selected or silently recovered; Work Order saving and governed Run remain gated; the live browser defaults to Modern Dark and Technical Help; explicitly selecting and successfully validating a writable Suitcase publishes exactly one fresh CER and unlocks the workspace; after switching to Modern Light and a non-Technical Help voice and creating a dirty unsaved WIP, an ordinary reload/navigation path triggers the browser-supported unsaved-change warning where the host permits it; after proceeding with reload, the Suitcase handle, non-default theme, non-default Help voice, and dirty WIP are not restored from Data Sculptor-controlled browser-private persistence; reselecting and successfully validating the same Suitcase publishes a second distinct CER while the first CER remains present under its original governed filename and exact bytes; and no automatic CER-history ZIP, compaction, replacement, or deletion occurs. The acceptance record must inspect the relevant Data Sculptor-controlled browser persistence surfaces and show that no persisted project/session record was used to restore the Suitcase handle, WIP, theme, or Help voice. WASM-002 does not claim dirty-draft warning or recovery after browser crash, forced process termination, operating-system failure, or power loss.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-006,Scope-surface acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The frozen WASM-002 browser build must not expose executable controls for requirements whose current SCOPE remains V1-BACKLOG, POST-V1, OUT-WASM-002, or otherwise outside the frozen WASM-002 build slice.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-007,"Small-screen, keyboard, and certified-browser acceptance",W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"On the canonical Intel N100 / 16 GB Windows 11 laptop and its 1920×1200 display, acceptance must record the Windows build, display scaling, browser zoom, and exact browser version. In the primary certified Microsoft Edge host, the required browser controls, Work Order editor, governed-stage status, artifact/result surface, and diagnostic/Help surface must remain reachable and usable without requiring an IDE or developer tools, and the required interaction path must be completable by keyboard. Ordinary scrolling and responsive reflow are allowed; changing scaling or zoom merely to expose an otherwise unreachable required control is not. The same canonical machine must also exercise the supported-host Suitcase → CER → Work Order save/Run → governed publication path in the secondary certified Google Chrome host. Chrome must satisfy the same governed filesystem and semantic contract; browser-specific presentation differences do not permit different analytical meaning or a different persistence model.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-008,Persistent diagnostic co-presence acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,Triggering a real governed refusal must leave the Work Order and relevant execution/source context available while the diagnostic is visible in the dedicated Help surface. The refusal must not depend on an application-controlled modal dialog or transient toast as its sole presentation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-009,Idle-state discipline acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"With no active diagnostic, the dedicated Help surface must remain present but semantically quiet and must not aggregate unrelated project/dashboard state as a substitute for its diagnostic purpose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-010,Saved-report action acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"From a displayed real diagnostic event, including a governed non-run diagnostic, the user must be able to invoke the Help-report action and obtain the corresponding durable HTML Help Report as one visible governed artifact without manually copying diagnostic text or reconstructing the event. A governed Run fixture containing multiple diagnostic events must also permit one explicit Run-level Help Report request and must produce exactly one HLP for that request. The HLP must identify the included diagnostics in deterministic event order and must not create one HLP automatically for each diagnostic.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-011,Suitcase-first gate and supported-host capability acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"With no Suitcase validated, Work Order saving, governed Run, and analytical processing controls must be unavailable. Acceptance first proves supported-host capability under W002-PLAT-001. Microsoft Edge and Google Chrome acceptance must each expose the required user-selected writable-directory path; Data Sculptor must not satisfy this gate through OPFS, IndexedDB, download-only output, a browser extension, or another substitute persistence model. Acceptance must enumerate every governed final-artifact filename form and SCR staging form that WASM-002 can emit, derive the longest canonical filename length, and verify that the current contract yields 73 ASCII bytes/characters . The canonical __DS__CER__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html form is one of the forms at that maximum and is used for the actual create/write/close folder-validation test. After the analyst selects a writable test folder on a supported host, Data Sculptor must create one retained governed certificate whose filename matches that canonical CER form, completely write and close it, and expose it in the visible Suitcase Directory. The certificate must contain the semantic fields and limitation statements required by W002-STOR-022.2. Only after that certificate operation succeeds may the workspace unlock. A failure to create, completely write, or close the certificate after actual folder selection must leave the workspace locked and surface the canonical diagnostic/Help path. Separately, a deterministic missing-capability acceptance fixture must prove that a host lacking the required writable-directory contract refuses before folder validation, leaves the workspace locked, and does not mislabel an untested folder as unwritable. Acceptance must not depend on a hard-coded operating-system path-length number, deletion of the certificate, or a validation-only rename. If the emitted-name inventory changes so that another form exceeds the CER maximum, this acceptance gate must fail until the new maximum is explicitly exercised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-012,Directory-is-inventory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"After Suitcase validation, the visible directory must list a mixed fixture set including at least one CSV and one non-CSV file with their physical names, types, and sizes. The directory must expose no “Use as source,” column-pick, or materialize action that bypasses the Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-013,Generated Work Order identity and immutability acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,Saving a valid draft must create a new TXT artifact whose physical name matches the frozen Work Order filename contract and must not open a filename-entry Save As path. Editing the draft and saving again must create a different Work Order identity; the first saved TXT bytes and filename must remain unchanged.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-014,Work-Order-only source and column selection acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a Suitcase containing multiple candidate files and a CSV with multiple headers, the analyst must be able to request the source and materialized column solely through a saved Work Order. Acceptance must show that the browser performs no separate point-and-click source or column selection. F-26 SOURCE eligibility fixtures: the acceptance set must prove all of the following under W002-WKO-009.1: analyst-owned root files ending .csv , .CSV , and a mixed-case equivalent are recognized as CSV candidates; the complete physical filename reference remains exact and case-sensitive under F-15; an analyst-created __DS__notes.csv is refused as an analyst-owned SOURCE; a valid published CVT is accepted; a canonical-looking or renamed file that does not satisfy the governed CVT validity/publication contract is refused; governed non-CVT classes including COL are refused as SOURCE; a non-CSV analyst-owned extension is refused even if its bytes are CSV-like; and path, traversal, subdirectory, URL/URI, and external-file references are refused.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-015,Read-only Execution Output acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The execution surface must display the selected saved Work Order, source resolution, relevant stage/refusal facts, and resulting artifact identity while accepting no command input. Keyboard focus in the execution surface must not create a second execution path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-016,Store-MAP snapshot persistence and read-only directory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Creating or changing governed alias/Store metadata through a saved Work Order must create one new immutable complete Store MAP in the same flat Suitcase while preserving earlier MAPs and leaving target artifact bytes and physical filenames unchanged. After a governed run that creates a new Store MAP, refreshing/reopening the Suitcase may display Store, RID, and COL aliases from the exact Store lineage and Store MAP resolved for that specific governed operation. The directory must not infer a global “current Store,” guess from unrelated newest MAP timestamps, or independently choose or mutate Store/MAP authority for execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-017,"Store-aware MAP selection, historical override, and anti-rebinding acceptance",W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"A saved materializing Work Order that does not explicitly name a MAP must use exact SOURCE matching against the one common source_filename carried by each routable Store lineage's Store MAP. A routable Store lineage is one with at least one structurally valid Store MAP, regardless of later Store-health state. A fixture with exactly one routable Store lineage must route to that lineage and, when its health permits materialization, inherit the Store's unique newest permitted MAP and record both the MAP identity and bound rid_filename in execution evidence. A fixture with no routable Store lineage and no structurally malformed Store-MAP-class artifact present may establish a new Store. A fixture with more than one routable Store lineage for the same source must refuse automatic selection. An explicit-MAP fixture must prove that SOURCE must exactly equal the selected MAP's common source_filename . A different source must refuse before materialization even when source/RID row counts happen to match. A separate all-MAPs-damaged fixture must leave one or more structurally malformed Store-MAP-class artifacts visible while no routable lineage can be established. The UI/run path must refuse before new-Store/RID creation and expose Help that identifies the malformed MAP artifact or artifacts; it must not present the condition as an unseen source. Another fixture must prove that explicitly naming an older valid MAP overrides the newer default for that same Store. More than one explicitly named MAP must refuse. An equal-greatest-timestamp ambiguity within the selected Store lineage must refuse automatic selection. Once an inherited Store MAP has been selected for a run, creation of a newer MAP during execution must not silently rebind that in-progress run. P2-03 authority/clock acceptance: the UI/evidence path must distinguish the selected operation base MAP from the chronology predecessor used for successor UTC validation. When a future-dated current MAP blocks publication, the UI must not label that MAP corrupt merely because of its timestamp, must identify it as the blocking current authority, and must route to Help describing the clock correction/wait/deliberate-removal choices without performing any automatic fallback or filesystem move.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-018,Help-Engine-only messaging acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"For representative Suitcase validation, Work Order validation, source-resolution, and analytical refusal cases, user-facing guidance must be traceable to the Help Engine/canonical diagnostic path. Acceptance must show no competing ad hoc semantic refusal text generated independently by individual analytical controls.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-019,No standalone Work Order Description acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Acceptance must prove the architecture that WASM-002 permits: the browser exposes no standalone editable Work Order Description field; no separate mutable or hidden Work Order-description store exists; editing any governed WKO byte transitions a loaded saved WKO into a derived draft; the predecessor WKO TXT bytes, physical filename, and UUID remain unchanged; and the derived draft cannot Run until saved as a new WKO identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-020,Theme semantic-invariance acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The same saved Work Order and governed diagnostic fixture must be exercised under Modern Dark and Modern Light. Acceptance evidence must show identical Work Order resolution, diagnostic ID and structured facts, continue/refuse decision, and analytical result/provenance across both themes, with only governed live-browser presentation differences. The browser must expose no Custom or Terminal governed theme choice in WASM-002. Acceptance must also verify that switching between Modern Dark and Modern Light does not change the canonical built-in presentation of a generated HLP or CER.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-021,Flight Recorder read-only derivation acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Acceptance must populate the Suitcase with governed RCP artifacts for at least one successful Run and one refused Run whose Receipt publication succeeded, then reconstruct the Flight Recorder surface solely from those Receipts. The rendered history must preserve each Receipt's governed execution outcome and lineage while allowing only read-only presentation operations. A separate fixture must represent a Run for which Receipt publication failed under W002-RCP-010 and prove that the Flight Recorder does not invent, backfill, or reconstruct a canonical Receipt from transient execution state. User interaction with the Flight Recorder must not modify, delete, rename, rewrite, supersede, or create RCP artifacts and must not create hidden persistent history state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-001,Certification interprets nothing analytically,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The certification stage establishes source-encoding validity and evidence; it does not perform analytical materialization.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-002,Materialization assumes nothing about encoding,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,Materialization proceeds only under the governed UTF-8-certified-source invariant and does not guess or silently change source encoding.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-003,Conversion is a separate transformation,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"Windows-1252-to-UTF-8 conversion is an explicit user-authorized operation producing a new artifact, not a hidden fallback.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-004,The fast path preserves strictness,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"ASCII-first acceleration is an optimization of strict UTF-8 certification, not a relaxation of validity rules. Every non-ASCII sequence remains subject to strict validation and EOF remains authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-005,Help is first-class,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The shared engine emits governed diagnostic truth; the Help Engine owns governed explanation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-006,PRETTY is first-class,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The PRETTY Engine owns deterministic human-facing rendering.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-008,One shared semantic core,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The WASM-first implementation must remain suitable for later use by a standalone native CLI host without creating a permanent second semantic engine.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-011,Open source and commercial service are separate layers,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The open-source analytical product and Red5Sorcery's optional paid automation must remain architecturally distinguishable. A paid service may save work; it must not become a hidden prerequisite for executing or understanding the delivered analytical software.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-014,WASM-002 and V1 analytical execution are sequential,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"WASM-002 must execute governed analytical operations sequentially and predictably. The product must not expose worker-count, thread-count, task-parallelism, or similar tuning controls, and it must not silently introduce a parallel analytical execution mode whose ordering or resource use changes the governed semantics. Sequential execution does not require inefficient repeated scans. One bounded structural source pass may process multiple requested columns together, and implementation may use ordinary low-level/runtime mechanisms that do not create user-visible analytical concurrency or change deterministic operation order. Any future analytical parallelism requires a separate measured experiment and explicit PRD decision.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-014.1,WASM-002 has a single-writer Suitcase contract,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"WASM-002 assumes one user, one active Suitcase, and one Data Sculptor writing execution context at a time . Multiple read-only views may observe the same Suitcase, but concurrent governed writers—including a second browser tab or window attempting governed writes against the same Suitcase—are outside the supported WASM-002 contract. WASM-002 does not implement cross-tab locks, filesystem leases, lockfiles, hidden coordination state, or multi-writer merge/rebase semantics. This is an explicit product boundary, not an implicit guarantee that concurrent writers are safe. Before a governed transaction reaches its authoritative commit point, Data Sculptor must re-resolve and revalidate the governing state on which the transaction depends. If relevant governed state has changed since the transaction established its basis, publication must refuse rather than overwrite the newer authority, silently rebase itself, synthesize another chronology, or report success. Candidates already created remain subject to the existing rollback and attributable SCR recovery-evidence rules. Help must explain the boundary in ordinary terms: do not run two writing Data Sculptor contexts against the same Suitcase at the same time. If a pre-commit guard detects changed authority, the safe next action is to refresh or reopen the current governed state and rerun deliberately. Acceptance evidence must inject a relevant Store-MAP and WKO-MAP authority change after transaction preparation but before commit and prove that the newer authority remains authoritative and the stale transaction refuses.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)

=== CP018 EVIDENCE CUSTODY SEAL ===
Date: 2026-10-21
Git HEAD: 339cf12e747738d89442ce401feeea1afcd19dc6
Original evidence archives reconciled: 27
Original/ZIP inventory hash reconciliation: PASS
Inventory TXT SHA256: 65C9AE89E95DDC31E73457E63C9F7AEA3DC8F3413EC2171E2507CA2BF636F154
Inventory ZIP SHA256: C0D1E349B67A9AE7B264D70C5A6F1568D50CAB9EAD11ADAB9F7680CD83AA5E01
Inventory ZIP entry integrity: PASS
Rust source SHA256: 69A512D5DF854EAD350C220647F9B58657F2BB7A626E87BCED342916D4761955
CP018 test SHA256: FAF47D9C1CE26D0AEC3EB6A857B8FC1EE9DD79505795765C159FE1A00A3DE8D3
Original evidence retained: YES
Seal record is outside the original 27-file inventory by design.
Git commit created: NO

=== CP018 EVIDENCE ZIP INVENTORY ===
Date: 2026-10-21
Git HEAD: 339cf12e747738d89442ce401feeea1afcd19dc6
Original files: 27
Method: one original file per ZIP
Integrity: source SHA256 equals extracted-entry SHA256

=== VERIFIED ARCHIVES ===
PASS | CP018_Formatting_Correction_Record.txt | SOURCE_SHA256=D29A6429F780E81EA5ECA5A7EE0EE53F0FCD15F9E759699D85DDA4152082F52B | ZIP_SHA256=2ED7608ECCA2B13C533FB993C63F0623F7AC4D2D37407C82C2A38E10561437C9
PASS | CP018_Formatting_Correction_StdErr.txt | SOURCE_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=35744AB6A830E76B54E2C0FA100B88B7D4EA91AFBC0DF1965163EA385D8007CA
PASS | CP018_Formatting_Correction_StdOut.txt | SOURCE_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=54612D9F8684EC25E155096247F569892EB9C714F68810D10421F51EE6886EF3
PASS | CP018_GREEN_Installation_Record.txt | SOURCE_SHA256=35386F7E78A7EF97B1B7FC86E7276EA41C0B1C52EECEB232E96F487F12EE3E7C | ZIP_SHA256=AEB1F489C5E271379394B3E07DA6B9C27B30991CEEA551C5EF7F26D42172FB59
PASS | CP018_GREEN_Run_Record.txt | SOURCE_SHA256=99ECB22B72695E0938609CE0CD56F7602403ABAA2D1F83768C5F93EA1044C4D7 | ZIP_SHA256=3DB9ED1A3B58E069EC05504A33DFB92DDDAFC63072F7EC74CDE7C2FBFC05290C
PASS | CP018_GREEN_StdErr.txt | SOURCE_SHA256=88B56B95934B583C21923A93A84CA70388945546973B5DBA63DF6EFA614D4E22 | ZIP_SHA256=FC38CF74640F5FE4F556A6C2E0095BF0EDC6CEDE6E3D32E0E888EB047AC63F05
PASS | CP018_GREEN_StdOut.txt | SOURCE_SHA256=9855307D3955AE649DFF581BE39F6209FBCEBECA10FACC4F8A52A00A2C565457 | ZIP_SHA256=7E4A12EA1423A66F16012BB86874BD889925C4958A8450DD94CF3163CE271A5B
PASS | CP018_PostFormat_Check_StdErr.txt | SOURCE_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=F23438F03B2219FDC97F81460DBC8F6A3B471B90F22F1A56E56D0CA21CFD7AD3
PASS | CP018_PostFormat_Check_StdOut.txt | SOURCE_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=0BE0A2ED8F73C44CEC19761CF6A22972773A844AB2CDE241F2AD336BBAADAA6B
PASS | CP018_PostFormat_Regression_StdErr.txt | SOURCE_SHA256=8C1D138F444104B0063756983262B0B6B804991C2CDB37B62F12F8D3C82BD1AF | ZIP_SHA256=A853386F8BAC7982E903C977FE22DE7FE402B0A511974837EE98B296F13C3393
PASS | CP018_PostFormat_Regression_StdOut.txt | SOURCE_SHA256=028EEC503DB1F201B629677BEEE45708E70FD4BC74DF7D675EA2BBAD3BF50188 | ZIP_SHA256=EE7A635D063DD9AC5933CB02012A0BBBE8388DEEA8D2A065104E6C3526B99810
PASS | CP018_PostFormat_Verification_Record.txt | SOURCE_SHA256=186FD2CD2DB21534A3AE42DB20CA852E3BAA1E76D49D286BEA1820C4AA88542F | ZIP_SHA256=C0218E8C93A89EFBEF825E2547F3370A43F4AF2EDDBAD20587BE49574B01DD5D
PASS | CP018_PreFormat_Test_Original.rs | SOURCE_SHA256=AFD7B86FF49F55DD71B265CE8B9000A87228EB01BED701029BD5E508306F150C | ZIP_SHA256=2287D9288B4C4F2030D0A5F43F266D9313ECB5DCCE4148EB0AB2B30B30551F62
PASS | CP018_PreGREEN_lib.rs | SOURCE_SHA256=903378F90A61E141EE008D60758F0241CAD67A5737DE301F4A1D1FBB61F9F3AE | ZIP_SHA256=EC7E2654B2145438B90008EA21BA812BD6D9D907931FDD4BA55B00DBC01F84C2
PASS | CP018_RED_Installation_Record.txt | SOURCE_SHA256=8C16146C5AF345D9141511BD48B16D2169DFDE7E837357F9D235239D8F8633AB | ZIP_SHA256=37B486DD214FC94B6F9AE737C46137C88FCA1711FCA2FE6385CCB33DFC501712
PASS | CP018_RED_Run_Record.txt | SOURCE_SHA256=6E474C32912FBC83B6C2BF5C47A24CF99B75294AE9593CF0569F28D4D6B9964A | ZIP_SHA256=6C2A7DF5736CB58BC227C4C044FA06516DA9374D19BD5A9DBF9783EA3AF04D9B
PASS | CP018_RED_StdErr.txt | SOURCE_SHA256=44653198AF2CA0F9D4A1E8086B775092254ED58641654D471E7F224F2947403F | ZIP_SHA256=90DBF2E55E2D72AE6277DBCFA48E98C4D77C092CA7816C92B1B7268CDA74F44C
PASS | CP018_RED_StdOut.txt | SOURCE_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=1C51034B5A3881B75D10CCC1077DA5EF33D2BC681F6DAEBEAA54CD3E00FBB537
PASS | CP018_Regression_Run_Record.txt | SOURCE_SHA256=E7A1BC6396CC42F14B4EE99C7CFB230EAE9047BE86E9916C3C917AA13C0E5A1F | ZIP_SHA256=D6B6B8A62F77E12C54A5CFB59B92F54A1513717361F96116F6A0F979F7390009
PASS | CP018_Regression_StdErr.txt | SOURCE_SHA256=5FF07A678D4E612AB7607CF21CE6ABB129DA3EF71F6D43B8FC50203450A79B77 | ZIP_SHA256=3632507EA863750150BC23E93D00F64F268FC99F2B01055EDF77364DE6833820
PASS | CP018_Regression_StdOut.txt | SOURCE_SHA256=759BE2EF098D362D594B867559CD0430C9F9CD88C9D46E34508B15F553CD30A5 | ZIP_SHA256=2550DA301842DF9BD7A64C7C7CC492E5B44433E878E2444D0BD7A36CCEEF8366
PASS | CP018_Rustfmt_Run_Record.txt | SOURCE_SHA256=6479875E789A165503D9878CD270AD4429382536FCAB3BD6A6A9239671F2E0A7 | ZIP_SHA256=7045DAEDB0E0412F9C1EC73893A7250C56C6D16D2B613A87BE32F9AF7A8AD77B
PASS | CP018_Rustfmt_StdErr.txt | SOURCE_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=320B19D8AE3CFA984F313571659C114DC42D9E9CD77A82BB9A5C61E0C6DA78DF
PASS | CP018_Rustfmt_StdOut.txt | SOURCE_SHA256=0AC9F3DF0920EBEF1CD2A03E8742E8D3AC7F8ABE20A14175C7093EBB033EA0CF | ZIP_SHA256=0BDC852F78855CABE022973BF2408B1D436A6E3F458295450236D845A4AD770B
PASS | CP018_WASM_Build_Run_Record.txt | SOURCE_SHA256=5D739FB615B388FEF157509D5272B3C8C25B01E14F24D7AA234E08B4705B15F3 | ZIP_SHA256=53AA24BCC1DE0BD7DCDD22C89E5A74ACD2FD1C6D2C753C48C43B73D2AEF03B82
PASS | CP018_WASM_Build_StdErr.txt | SOURCE_SHA256=E86726CE73796A73AB619E36201CD6AD458198C8B82C587EAA74687054E8B66E | ZIP_SHA256=F6FD853C479BFFEA81E1459F4CC48EFB3ED79CD23E178387D28E2EF439870ECD
PASS | CP018_WASM_Build_StdOut.txt | SOURCE_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=BE545D150BE29053A2BCC5C9F63234F4D7F26E6C4B50353CB65B14DF4B9AF656

Verified ZIPs: 27
Overall result: PASS
Original files deleted: NO
Git commit created: NO
Inventory generated after packaging; not included in this ZIP set.

=== CP018 FORMATTING CORRECTION ===
Date: 2026-10-21
Command: cargo fmt --all
Exit code: 0
Original test SHA256: AFD7B86FF49F55DD71B265CE8B9000A87228EB01BED701029BD5E508306F150C
Preserved backup SHA256: AFD7B86FF49F55DD71B265CE8B9000A87228EB01BED701029BD5E508306F150C
Formatted test SHA256: FAF47D9C1CE26D0AEC3EB6A857B8FC1EE9DD79505795765C159FE1A00A3DE8D3
Source SHA256 before: 69A512D5DF854EAD350C220647F9B58657F2BB7A626E87BCED342916D4761955
Source SHA256 after: 69A512D5DF854EAD350C220647F9B58657F2BB7A626E87BCED342916D4761955
Implementation source unchanged: True
Result: FORMATTING CORRECTION PASS
Git commit created: NO

=== CP018 GREEN INSTALLATION ===
Date: 2026-10-21
Git HEAD: 339cf12e747738d89442ce401feeea1afcd19dc6
Frozen requirements: W002-RCP-005, W002-RCP-006
Source: src/lib.rs
Backup: Evidence/CP-018/CP018_PreGREEN_lib.rs
Pre-GREEN SHA256: 903378F90A61E141EE008D60758F0241CAD67A5737DE301F4A1D1FBB61F9F3AE
Post-install SHA256: 69A512D5DF854EAD350C220647F9B58657F2BB7A626E87BCED342916D4761955
CP018 RED test SHA256: AFD7B86FF49F55DD71B265CE8B9000A87228EB01BED701029BD5E508306F150C
Source installation: PASS
GREEN test executed: NO
Git commit created: NO

=== CP018 GREEN TEST ===
Date: 2026-10-21
Git HEAD: 339cf12e747738d89442ce401feeea1afcd19dc6
Source SHA256: 69A512D5DF854EAD350C220647F9B58657F2BB7A626E87BCED342916D4761955
Test SHA256: AFD7B86FF49F55DD71B265CE8B9000A87228EB01BED701029BD5E508306F150C
Command: cargo test --test CP018_receipt_core_envelope
Exit code: 0
Nine tests passed: True
Result: GREEN PASS
StdOut: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-018\CP018_GREEN_StdOut.txt
StdErr: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-018\CP018_GREEN_StdErr.txt
Git commit created: NO

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 2.48s
     Running tests\CP018_receipt_core_envelope.rs (target\debug\deps\CP018_receipt_core_envelope-b0aa754d7846f001.exe)

running 9 tests
test duplicate_field_refuses ... ok
test empty_input_refuses ... ok
test exact_ten_core_fields_emit_exact_bytes ... ok
test invalid_late_value_refuses_entire_fragment ... ok
test missing_mandatory_field_refuses ... ok
test misspelled_or_wrong_case_key_refuses ... ok
test repeated_input_is_byte_identical ... ok
test swapped_fields_refuse ... ok
test unexpected_field_refuses_for_core_only_api ... ok

test result: ok. 9 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

=== CP018 GIT BANKING ===
Date: 2026-10-21
Human acceptance: T APPROVED
Checkpoint: CP018
Requirements: W002-RCP-005 / W002-RCP-006 (PARTIAL)
Commit message: CP018: canonical Receipt core-envelope ordering and evidence
Commit exit code: 0
Previous HEAD: 339cf12e747738d89442ce401feeea1afcd19dc6
New HEAD: 75620f17649a5d38d5357960bb99e9ac39ae354f
Commit parent: 339cf12e747738d89442ce401feeea1afcd19dc6
Expected committed files: 32
Actual committed files: 32
Remaining staged files: 0
Remaining tracked changes: 0
Native regression: 94/94 PASS
Rustfmt: PASS
WASM library build: PASS
Evidence ZIPs: 30
Banking verification: PASS
Remote push performed: NO

[master 75620f1] CP018: canonical Receipt core-envelope ordering and evidence
 32 files changed, 186 insertions(+)
 create mode 100644 Evidence/CP-018/ZIP/CP018_Custody_Seal_Record.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_Evidence_ZIP_Inventory.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_Formatting_Correction_Record.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_Formatting_Correction_StdErr.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_Formatting_Correction_StdOut.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_GREEN_Installation_Record.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_GREEN_Run_Record.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_GREEN_StdErr.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_GREEN_StdOut.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_Git_PreStaging_Review.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_PostFormat_Check_StdErr.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_PostFormat_Check_StdOut.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_PostFormat_Regression_StdErr.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_PostFormat_Regression_StdOut.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_PostFormat_Verification_Record.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_PreFormat_Test_Original.rs.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_PreGREEN_lib.rs.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_RED_Installation_Record.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_RED_Run_Record.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_RED_StdErr.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_RED_StdOut.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_Regression_Run_Record.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_Regression_StdErr.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_Regression_StdOut.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_Rustfmt_Run_Record.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_Rustfmt_StdErr.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_Rustfmt_StdOut.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_WASM_Build_Run_Record.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_WASM_Build_StdErr.txt.zip
 create mode 100644 Evidence/CP-018/ZIP/CP018_WASM_Build_StdOut.txt.zip
 create mode 100644 tests/CP018_receipt_core_envelope.rs

=== CP018 GIT PRE-STAGING REVIEW ===
Date: 2026-10-21
Git HEAD: 339cf12e747738d89442ce401feeea1afcd19dc6
Tracked modifications: 1
Tracked modified file: src/lib.rs
New test: tests/CP018_receipt_core_envelope.rs
Already staged files: 0
Git whitespace check: PASS
Evidence ZIPs verified: 29
Source SHA256: 69A512D5DF854EAD350C220647F9B58657F2BB7A626E87BCED342916D4761955
Test SHA256: FAF47D9C1CE26D0AEC3EB6A857B8FC1EE9DD79505795765C159FE1A00A3DE8D3

=== SOURCE DIFF ===
diff --git a/src/lib.rs b/src/lib.rs
index 2d27aef..b6aaa20 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -478,6 +478,43 @@ pub fn serialize_canonical_receipt_field_sequence(
     Some(output)
 }
 
+/// Serializes exactly the ten frozen WASM-002 Receipt core fields.
+///
+/// Checks the mandatory key count and order before delegating formatting
+/// to CP017. Refuses malformed field formatting as a whole.
+///
+/// This is a core-envelope fragment, not a complete Receipt. It does not
+/// validate operation-specific facts, execution truth, filename lineage,
+/// field-specific vocabularies, filesystem effects, or publication.
+pub fn serialize_canonical_receipt_core_envelope(
+    fields: &[(&str, ReceiptFieldValue<'_>)],
+) -> Option<String> {
+    const CORE_KEYS: [&str; 10] = [
+        "RECEIPT_VERSION",
+        "RECEIPT_FILENAME",
+        "RECEIPT_UTC",
+        "WORK_ORDER_FILENAME",
+        "OPERATION",
+        "RUN_STARTED_UTC",
+        "RUN_FINISHED_UTC",
+        "RESULT",
+        "DIAGNOSTIC_ID",
+        "IDENTITY_COLLISION_RETRIES",
+    ];
+
+    if fields.len() != CORE_KEYS.len() {
+        return None;
+    }
+
+    for (index, &(key, _)) in fields.iter().enumerate() {
+        if key != CORE_KEYS[index] {
+            return None;
+        }
+    }
+
+    serialize_canonical_receipt_field_sequence(fields)
+}
+
 /// Lexical form shared by field keys and machine-token values in this slice.
 /// Starts with uppercase ASCII A-Z; remaining bytes are A-Z, 0-9, or '_'.
 /// This is not an operation-specific closed-vocabulary membership check.

=== EVIDENCE ARCHIVES ===
PASS | CP018_Custody_Seal_Record.txt.zip | SHA256=4DA3B192CF1BAA124D7453F64F4B1365A84367B281005E3DDF4668FD1900D69E
PASS | CP018_Evidence_ZIP_Inventory.txt.zip | SHA256=C0D1E349B67A9AE7B264D70C5A6F1568D50CAB9EAD11ADAB9F7680CD83AA5E01
PASS | CP018_Formatting_Correction_Record.txt.zip | SHA256=2ED7608ECCA2B13C533FB993C63F0623F7AC4D2D37407C82C2A38E10561437C9
PASS | CP018_Formatting_Correction_StdErr.txt.zip | SHA256=35744AB6A830E76B54E2C0FA100B88B7D4EA91AFBC0DF1965163EA385D8007CA
PASS | CP018_Formatting_Correction_StdOut.txt.zip | SHA256=54612D9F8684EC25E155096247F569892EB9C714F68810D10421F51EE6886EF3
PASS | CP018_GREEN_Installation_Record.txt.zip | SHA256=AEB1F489C5E271379394B3E07DA6B9C27B30991CEEA551C5EF7F26D42172FB59
PASS | CP018_GREEN_Run_Record.txt.zip | SHA256=3DB9ED1A3B58E069EC05504A33DFB92DDDAFC63072F7EC74CDE7C2FBFC05290C
PASS | CP018_GREEN_StdErr.txt.zip | SHA256=FC38CF74640F5FE4F556A6C2E0095BF0EDC6CEDE6E3D32E0E888EB047AC63F05
PASS | CP018_GREEN_StdOut.txt.zip | SHA256=7E4A12EA1423A66F16012BB86874BD889925C4958A8450DD94CF3163CE271A5B
PASS | CP018_PostFormat_Check_StdErr.txt.zip | SHA256=F23438F03B2219FDC97F81460DBC8F6A3B471B90F22F1A56E56D0CA21CFD7AD3
PASS | CP018_PostFormat_Check_StdOut.txt.zip | SHA256=0BE0A2ED8F73C44CEC19761CF6A22972773A844AB2CDE241F2AD336BBAADAA6B
PASS | CP018_PostFormat_Regression_StdErr.txt.zip | SHA256=A853386F8BAC7982E903C977FE22DE7FE402B0A511974837EE98B296F13C3393
PASS | CP018_PostFormat_Regression_StdOut.txt.zip | SHA256=EE7A635D063DD9AC5933CB02012A0BBBE8388DEEA8D2A065104E6C3526B99810
PASS | CP018_PostFormat_Verification_Record.txt.zip | SHA256=C0218E8C93A89EFBEF825E2547F3370A43F4AF2EDDBAD20587BE49574B01DD5D
PASS | CP018_PreFormat_Test_Original.rs.zip | SHA256=2287D9288B4C4F2030D0A5F43F266D9313ECB5DCCE4148EB0AB2B30B30551F62
PASS | CP018_PreGREEN_lib.rs.zip | SHA256=EC7E2654B2145438B90008EA21BA812BD6D9D907931FDD4BA55B00DBC01F84C2
PASS | CP018_RED_Installation_Record.txt.zip | SHA256=37B486DD214FC94B6F9AE737C46137C88FCA1711FCA2FE6385CCB33DFC501712
PASS | CP018_RED_Run_Record.txt.zip | SHA256=6C2A7DF5736CB58BC227C4C044FA06516DA9374D19BD5A9DBF9783EA3AF04D9B
PASS | CP018_RED_StdErr.txt.zip | SHA256=90DBF2E55E2D72AE6277DBCFA48E98C4D77C092CA7816C92B1B7268CDA74F44C
PASS | CP018_RED_StdOut.txt.zip | SHA256=1C51034B5A3881B75D10CCC1077DA5EF33D2BC681F6DAEBEAA54CD3E00FBB537
PASS | CP018_Regression_Run_Record.txt.zip | SHA256=D6B6B8A62F77E12C54A5CFB59B92F54A1513717361F96116F6A0F979F7390009
PASS | CP018_Regression_StdErr.txt.zip | SHA256=3632507EA863750150BC23E93D00F64F268FC99F2B01055EDF77364DE6833820
PASS | CP018_Regression_StdOut.txt.zip | SHA256=2550DA301842DF9BD7A64C7C7CC492E5B44433E878E2444D0BD7A36CCEEF8366
PASS | CP018_Rustfmt_Run_Record.txt.zip | SHA256=7045DAEDB0E0412F9C1EC73893A7250C56C6D16D2B613A87BE32F9AF7A8AD77B
PASS | CP018_Rustfmt_StdErr.txt.zip | SHA256=320B19D8AE3CFA984F313571659C114DC42D9E9CD77A82BB9A5C61E0C6DA78DF
PASS | CP018_Rustfmt_StdOut.txt.zip | SHA256=0BDC852F78855CABE022973BF2408B1D436A6E3F458295450236D845A4AD770B
PASS | CP018_WASM_Build_Run_Record.txt.zip | SHA256=53AA24BCC1DE0BD7DCDD22C89E5A74ACD2FD1C6D2C753C48C43B73D2AEF03B82
PASS | CP018_WASM_Build_StdErr.txt.zip | SHA256=F6FD853C479BFFEA81E1459F4CC48EFB3ED79CD23E178387D28E2EF439870ECD
PASS | CP018_WASM_Build_StdOut.txt.zip | SHA256=BE545D150BE29053A2BCC5C9F63234F4D7F26E6C4B50353CB65B14DF4B9AF656

=== GIT STATUS ===
 M src/lib.rs
?? Evidence/CP-018/ZIP/CP018_Custody_Seal_Record.txt.zip
?? Evidence/CP-018/ZIP/CP018_Evidence_ZIP_Inventory.txt.zip
?? Evidence/CP-018/ZIP/CP018_Formatting_Correction_Record.txt.zip
?? Evidence/CP-018/ZIP/CP018_Formatting_Correction_StdErr.txt.zip
?? Evidence/CP-018/ZIP/CP018_Formatting_Correction_StdOut.txt.zip
?? Evidence/CP-018/ZIP/CP018_GREEN_Installation_Record.txt.zip
?? Evidence/CP-018/ZIP/CP018_GREEN_Run_Record.txt.zip
?? Evidence/CP-018/ZIP/CP018_GREEN_StdErr.txt.zip
?? Evidence/CP-018/ZIP/CP018_GREEN_StdOut.txt.zip
?? Evidence/CP-018/ZIP/CP018_PostFormat_Check_StdErr.txt.zip
?? Evidence/CP-018/ZIP/CP018_PostFormat_Check_StdOut.txt.zip
?? Evidence/CP-018/ZIP/CP018_PostFormat_Regression_StdErr.txt.zip
?? Evidence/CP-018/ZIP/CP018_PostFormat_Regression_StdOut.txt.zip
?? Evidence/CP-018/ZIP/CP018_PostFormat_Verification_Record.txt.zip
?? Evidence/CP-018/ZIP/CP018_PreFormat_Test_Original.rs.zip
?? Evidence/CP-018/ZIP/CP018_PreGREEN_lib.rs.zip
?? Evidence/CP-018/ZIP/CP018_RED_Installation_Record.txt.zip
?? Evidence/CP-018/ZIP/CP018_RED_Run_Record.txt.zip
?? Evidence/CP-018/ZIP/CP018_RED_StdErr.txt.zip
?? Evidence/CP-018/ZIP/CP018_RED_StdOut.txt.zip
?? Evidence/CP-018/ZIP/CP018_Regression_Run_Record.txt.zip
?? Evidence/CP-018/ZIP/CP018_Regression_StdErr.txt.zip
?? Evidence/CP-018/ZIP/CP018_Regression_StdOut.txt.zip
?? Evidence/CP-018/ZIP/CP018_Rustfmt_Run_Record.txt.zip
?? Evidence/CP-018/ZIP/CP018_Rustfmt_StdErr.txt.zip
?? Evidence/CP-018/ZIP/CP018_Rustfmt_StdOut.txt.zip
?? Evidence/CP-018/ZIP/CP018_WASM_Build_Run_Record.txt.zip
?? Evidence/CP-018/ZIP/CP018_WASM_Build_StdErr.txt.zip
?? Evidence/CP-018/ZIP/CP018_WASM_Build_StdOut.txt.zip
?? tests/CP018_receipt_core_envelope.rs

Review result: PASS
Git staging performed: NO
Git commit created: NO

=== CP018 GIT STAGING REVIEW ===
Date: 2026-10-21
Git HEAD: 339cf12e747738d89442ce401feeea1afcd19dc6
Rust source SHA256: 69A512D5DF854EAD350C220647F9B58657F2BB7A626E87BCED342916D4761955
Rust test SHA256: FAF47D9C1CE26D0AEC3EB6A857B8FC1EE9DD79505795765C159FE1A00A3DE8D3
Pre-staging review SHA256: EEBB85220C233AC498CDEB0BD7A130B417F16BAC107EA61F4A7940A270641A16
Pre-staging review ZIP: VERIFIED
Expected staged files: 32
Actual staged files: 32
Evidence ZIP blobs verified: 30
Staged whitespace: PASS
Git commit created: NO

=== STAGED FILES ===
Evidence/CP-018/ZIP/CP018_Custody_Seal_Record.txt.zip
Evidence/CP-018/ZIP/CP018_Evidence_ZIP_Inventory.txt.zip
Evidence/CP-018/ZIP/CP018_Formatting_Correction_Record.txt.zip
Evidence/CP-018/ZIP/CP018_Formatting_Correction_StdErr.txt.zip
Evidence/CP-018/ZIP/CP018_Formatting_Correction_StdOut.txt.zip
Evidence/CP-018/ZIP/CP018_GREEN_Installation_Record.txt.zip
Evidence/CP-018/ZIP/CP018_GREEN_Run_Record.txt.zip
Evidence/CP-018/ZIP/CP018_GREEN_StdErr.txt.zip
Evidence/CP-018/ZIP/CP018_GREEN_StdOut.txt.zip
Evidence/CP-018/ZIP/CP018_Git_PreStaging_Review.txt.zip
Evidence/CP-018/ZIP/CP018_PostFormat_Check_StdErr.txt.zip
Evidence/CP-018/ZIP/CP018_PostFormat_Check_StdOut.txt.zip
Evidence/CP-018/ZIP/CP018_PostFormat_Regression_StdErr.txt.zip
Evidence/CP-018/ZIP/CP018_PostFormat_Regression_StdOut.txt.zip
Evidence/CP-018/ZIP/CP018_PostFormat_Verification_Record.txt.zip
Evidence/CP-018/ZIP/CP018_PreFormat_Test_Original.rs.zip
Evidence/CP-018/ZIP/CP018_PreGREEN_lib.rs.zip
Evidence/CP-018/ZIP/CP018_RED_Installation_Record.txt.zip
Evidence/CP-018/ZIP/CP018_RED_Run_Record.txt.zip
Evidence/CP-018/ZIP/CP018_RED_StdErr.txt.zip
Evidence/CP-018/ZIP/CP018_RED_StdOut.txt.zip
Evidence/CP-018/ZIP/CP018_Regression_Run_Record.txt.zip
Evidence/CP-018/ZIP/CP018_Regression_StdErr.txt.zip
Evidence/CP-018/ZIP/CP018_Regression_StdOut.txt.zip
Evidence/CP-018/ZIP/CP018_Rustfmt_Run_Record.txt.zip
Evidence/CP-018/ZIP/CP018_Rustfmt_StdErr.txt.zip
Evidence/CP-018/ZIP/CP018_Rustfmt_StdOut.txt.zip
Evidence/CP-018/ZIP/CP018_WASM_Build_Run_Record.txt.zip
Evidence/CP-018/ZIP/CP018_WASM_Build_StdErr.txt.zip
Evidence/CP-018/ZIP/CP018_WASM_Build_StdOut.txt.zip
src/lib.rs
tests/CP018_receipt_core_envelope.rs

=== ZIP GIT BLOB VERIFICATION ===
PASS | Evidence/CP-018/ZIP/CP018_Custody_Seal_Record.txt.zip | GIT_BLOB=213d0d139c4eedebb917dc7cadefe8834f910e67
PASS | Evidence/CP-018/ZIP/CP018_Evidence_ZIP_Inventory.txt.zip | GIT_BLOB=eaa19f5be44ff705cd95e875267b3305e700b45d
PASS | Evidence/CP-018/ZIP/CP018_Formatting_Correction_Record.txt.zip | GIT_BLOB=4ad9c5481bf4cbf2788dc34f53624cac3227c189
PASS | Evidence/CP-018/ZIP/CP018_Formatting_Correction_StdErr.txt.zip | GIT_BLOB=9f79019c719f3af3a84e24796bf78e497253fe9e
PASS | Evidence/CP-018/ZIP/CP018_Formatting_Correction_StdOut.txt.zip | GIT_BLOB=b8e6ae3be860cb0a64be4869938b65c3670a3892
PASS | Evidence/CP-018/ZIP/CP018_Git_PreStaging_Review.txt.zip | GIT_BLOB=dc763ee7981ad60b41ce82eb2ec4a2eb40bf9adc
PASS | Evidence/CP-018/ZIP/CP018_GREEN_Installation_Record.txt.zip | GIT_BLOB=9bed6e8c1b7c33afb99f04e06e5591f16d99723a
PASS | Evidence/CP-018/ZIP/CP018_GREEN_Run_Record.txt.zip | GIT_BLOB=b94b46ba6d8971431ce10f443a70b2fe5c3e09d0
PASS | Evidence/CP-018/ZIP/CP018_GREEN_StdErr.txt.zip | GIT_BLOB=4dd8642ddeb8ba91059e32ec8d7bd5ceca84c7b2
PASS | Evidence/CP-018/ZIP/CP018_GREEN_StdOut.txt.zip | GIT_BLOB=03bb16a3b3c2f8323e3560a46ac4ddc47aeafa4a
PASS | Evidence/CP-018/ZIP/CP018_PostFormat_Check_StdErr.txt.zip | GIT_BLOB=63220ca15bb3fbd09f3cdc1d606220fbe6aa0c39
PASS | Evidence/CP-018/ZIP/CP018_PostFormat_Check_StdOut.txt.zip | GIT_BLOB=5e21da0223e5482f283d5bce95a4d828ebd69bc4
PASS | Evidence/CP-018/ZIP/CP018_PostFormat_Regression_StdErr.txt.zip | GIT_BLOB=cc0fb9402b0fa7f9def7fa2a9157f11211f4b7e6
PASS | Evidence/CP-018/ZIP/CP018_PostFormat_Regression_StdOut.txt.zip | GIT_BLOB=560562f209e108ec7abe8fcdd773c7aaaf590589
PASS | Evidence/CP-018/ZIP/CP018_PostFormat_Verification_Record.txt.zip | GIT_BLOB=5877b657824509f2ce520c697764bc008ed6304c
PASS | Evidence/CP-018/ZIP/CP018_PreFormat_Test_Original.rs.zip | GIT_BLOB=ba1e54dfea313fd06601283276f50f4f5efe1fe3
PASS | Evidence/CP-018/ZIP/CP018_PreGREEN_lib.rs.zip | GIT_BLOB=f6de95516d606e936ebf2f481c274e915ac28746
PASS | Evidence/CP-018/ZIP/CP018_RED_Installation_Record.txt.zip | GIT_BLOB=3dacfa5b3453367fdb61758020f9aec793a1e8ad
PASS | Evidence/CP-018/ZIP/CP018_RED_Run_Record.txt.zip | GIT_BLOB=eb5e52e0ecfeb2b74639886bebecf060675303cf
PASS | Evidence/CP-018/ZIP/CP018_RED_StdErr.txt.zip | GIT_BLOB=8df8bf092699e57d6dc205778ff4b3ee7ba97154
PASS | Evidence/CP-018/ZIP/CP018_RED_StdOut.txt.zip | GIT_BLOB=a3081afc3c18cace5f13e4efc2514fd2848052dd
PASS | Evidence/CP-018/ZIP/CP018_Regression_Run_Record.txt.zip | GIT_BLOB=f220a479a1eca5b723eaa8bc986794cfd558138d
PASS | Evidence/CP-018/ZIP/CP018_Regression_StdErr.txt.zip | GIT_BLOB=824de2eda373793326fe82ea8a443beeebe64d2e
PASS | Evidence/CP-018/ZIP/CP018_Regression_StdOut.txt.zip | GIT_BLOB=82365c6a175193719140f409dec1915720ace41f
PASS | Evidence/CP-018/ZIP/CP018_Rustfmt_Run_Record.txt.zip | GIT_BLOB=12a5331d6cd2fdb0d76d20c67c62ff7a70a0363d
PASS | Evidence/CP-018/ZIP/CP018_Rustfmt_StdErr.txt.zip | GIT_BLOB=d67d517a30affa2a52d9ad3c7ab3634b38440ec8
PASS | Evidence/CP-018/ZIP/CP018_Rustfmt_StdOut.txt.zip | GIT_BLOB=25b807aeeb66a34d25377188df95d3b0ea84011f
PASS | Evidence/CP-018/ZIP/CP018_WASM_Build_Run_Record.txt.zip | GIT_BLOB=78947f4765727ae9c947eedb805d368bde6ed99c
PASS | Evidence/CP-018/ZIP/CP018_WASM_Build_StdErr.txt.zip | GIT_BLOB=7eccfb28719af961461f55870915d39aa4677325
PASS | Evidence/CP-018/ZIP/CP018_WASM_Build_StdOut.txt.zip | GIT_BLOB=0bef6896a81f6b1784173510eaeb61a828c81d10

=== STAGED SUMMARY ===
 .../CP-018/ZIP/CP018_Custody_Seal_Record.txt.zip   | Bin 0 -> 610 bytes
 .../ZIP/CP018_Evidence_ZIP_Inventory.txt.zip       | Bin 0 -> 2689 bytes
 .../ZIP/CP018_Formatting_Correction_Record.txt.zip | Bin 0 -> 539 bytes
 .../ZIP/CP018_Formatting_Correction_StdErr.txt.zip | Bin 0 -> 174 bytes
 .../ZIP/CP018_Formatting_Correction_StdOut.txt.zip | Bin 0 -> 174 bytes
 .../ZIP/CP018_GREEN_Installation_Record.txt.zip    | Bin 0 -> 565 bytes
 Evidence/CP-018/ZIP/CP018_GREEN_Run_Record.txt.zip | Bin 0 -> 536 bytes
 Evidence/CP-018/ZIP/CP018_GREEN_StdErr.txt.zip     | Bin 0 -> 347 bytes
 Evidence/CP-018/ZIP/CP018_GREEN_StdOut.txt.zip     | Bin 0 -> 387 bytes
 .../CP-018/ZIP/CP018_Git_PreStaging_Review.txt.zip | Bin 0 -> 3028 bytes
 .../ZIP/CP018_PostFormat_Check_StdErr.txt.zip      | Bin 0 -> 164 bytes
 .../ZIP/CP018_PostFormat_Check_StdOut.txt.zip      | Bin 0 -> 164 bytes
 .../ZIP/CP018_PostFormat_Regression_StdErr.txt.zip | Bin 0 -> 851 bytes
 .../ZIP/CP018_PostFormat_Regression_StdOut.txt.zip | Bin 0 -> 1883 bytes
 .../CP018_PostFormat_Verification_Record.txt.zip   | Bin 0 -> 526 bytes
 .../ZIP/CP018_PreFormat_Test_Original.rs.zip       | Bin 0 -> 1658 bytes
 Evidence/CP-018/ZIP/CP018_PreGREEN_lib.rs.zip      | Bin 0 -> 4746 bytes
 .../ZIP/CP018_RED_Installation_Record.txt.zip      | Bin 0 -> 421 bytes
 Evidence/CP-018/ZIP/CP018_RED_Run_Record.txt.zip   | Bin 0 -> 489 bytes
 Evidence/CP-018/ZIP/CP018_RED_StdErr.txt.zip       | Bin 0 -> 501 bytes
 Evidence/CP-018/ZIP/CP018_RED_StdOut.txt.zip       | Bin 0 -> 138 bytes
 .../CP-018/ZIP/CP018_Regression_Run_Record.txt.zip | Bin 0 -> 503 bytes
 .../CP-018/ZIP/CP018_Regression_StdErr.txt.zip     | Bin 0 -> 830 bytes
 .../CP-018/ZIP/CP018_Regression_StdOut.txt.zip     | Bin 0 -> 1881 bytes
 .../CP-018/ZIP/CP018_Rustfmt_Run_Record.txt.zip    | Bin 0 -> 428 bytes
 Evidence/CP-018/ZIP/CP018_Rustfmt_StdErr.txt.zip   | Bin 0 -> 146 bytes
 Evidence/CP-018/ZIP/CP018_Rustfmt_StdOut.txt.zip   | Bin 0 -> 461 bytes
 .../CP-018/ZIP/CP018_WASM_Build_Run_Record.txt.zip | Bin 0 -> 622 bytes
 .../CP-018/ZIP/CP018_WASM_Build_StdErr.txt.zip     | Bin 0 -> 293 bytes
 .../CP-018/ZIP/CP018_WASM_Build_StdOut.txt.zip     | Bin 0 -> 152 bytes
 src/lib.rs                                         |  37 +++++
 tests/CP018_receipt_core_envelope.rs               | 149 +++++++++++++++++++++
 32 files changed, 186 insertions(+)

STAGING_VERIFICATION=PASS
GIT_COMMIT_CREATED=NO

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.44s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)
     Running tests\CP008_source_eligibility.rs (target\debug\deps\CP008_source_eligibility-194c314726b26929.exe)
     Running tests\CP009_exact_root_snapshot.rs (target\debug\deps\CP009_exact_root_snapshot-b26a1b02e36e8f07.exe)
     Running tests\CP010_cvt_filename_candidate.rs (target\debug\deps\CP010_cvt_filename_candidate-ce216c0140f6b173.exe)
     Running tests\CP011_cvt_scr_candidate_identity.rs (target\debug\deps\CP011_cvt_scr_candidate_identity-8bc68fabbbb42eb4.exe)
     Running tests\CP012_scr_filename_candidate.rs (target\debug\deps\CP012_scr_filename_candidate-7c39746d8bb6fac7.exe)
     Running tests\CP013_scr_rcp_candidate_identity.rs (target\debug\deps\CP013_scr_rcp_candidate_identity-4f7c7bea8654150d.exe)
     Running tests\CP014_rcp_filename_candidate_identity.rs (target\debug\deps\CP014_rcp_filename_candidate_identity-249a1cd498442ced.exe)
     Running tests\CP015_scr_rcp_filename_pair_identity.rs (target\debug\deps\CP015_scr_rcp_filename_pair_identity-526d10560ef9b891.exe)
     Running tests\CP016_receipt_field_serialization.rs (target\debug\deps\CP016_receipt_field_serialization-8c3a6628143f8cc6.exe)
     Running tests\CP017_receipt_field_sequence.rs (target\debug\deps\CP017_receipt_field_sequence-c803df96b76f21ee.exe)
     Running tests\CP018_receipt_core_envelope.rs (target\debug\deps\CP018_receipt_core_envelope-b0aa754d7846f001.exe)
     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)
     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)
     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)
     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)
     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)
     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 5 tests
test accepts_analyst_csv_final_extension_in_ascii_case_variants ... ok
test makes_no_case_or_unicode_normalization_claim ... ok
test refuses_paths_traversal_and_external_references ... ok
test refuses_reserved_namespace_even_if_name_looks_like_csv ... ok
test rejects_non_csv_or_nonfinal_csv_extensions ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 8 tests
test candidate_preflight_runs_before_root_matching ... ok
test duplicate_exact_entries_refuse_instead_of_picking_first ... ok
test full_filename_match_is_exact_and_case_sensitive ... ok
test finds_one_exact_reported_regular_file ... ok
test never_trims_to_find_a_different_physical_name ... ok
test reported_non_regular_entries_do_not_pass ... ok
test result_is_order_independent_and_empty_snapshot_is_not_found ... ok
test unicode_scalar_sequence_is_not_normalized ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test accepts_exact_canonical_cvt_csv_candidate ... ok
test refuses_paths_and_noncanonical_references ... ok
test refuses_malformed_canonical_identity ... ok
test refuses_wrong_classes_and_extensions ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test derives_exact_corresponding_scr_identity ... ok
test refuses_invalid_utc_and_uuid ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_whitespace_and_noncanonical_names ... ok
test refuses_wrong_extension_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test accepts_canonical_scr_csv_candidate ... ok
test refuses_noncanonical_namespace_class_and_extension ... ok
test refuses_invalid_utc_and_uuid ... ok
test accepts_canonical_scr_txt_candidate ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_and_whitespace ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test derives_rcp_candidate_only_with_explicit_class ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_invalid_identity_paths_and_whitespace ... ok
test refuses_non_scr_and_noncanonical_source_classes ... ok
test refuses_unsupported_or_incorrectly_cased_final_classes ... ok
test refuses_wrong_or_ambiguous_serialization_extensions ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test accepts_canonical_rcp_txt_identity ... ok
test recognizes_existing_scr_to_rcp_derivation ... ok
test refuses_invalid_timestamp_uuid_and_envelope ... ok
test refuses_noncanonical_serialization ... ok
test refuses_paths_and_whitespace ... ok
test refuses_wrong_semantic_class_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test accepts_matching_canonical_scr_and_rcp_txt_names ... ok
test refuses_mismatched_utc_timestamp_even_when_both_names_are_canonical ... ok
test refuses_mismatched_uuid_even_when_both_names_are_canonical ... ok
test refuses_paths_and_whitespace_on_either_side ... ok
test refuses_wrong_class_or_reversed_pair_order ... ok
test refuses_wrong_extensions_and_noncanonical_envelopes ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 8 tests
test doubles_internal_quotes_without_backslash_escaping ... ok
test filenames_and_utf8_free_text_are_double_quoted ... ok
test machine_tokens_have_exact_colon_space_and_single_lf ... ok
test machine_token_spelling_must_be_lexically_canonical ... ok
test non_negative_integers_use_ungrouped_ascii_decimal ... ok
test refuses_cr_or_lf_inside_any_single_field_value ... ok
test refuses_non_uppercase_ascii_field_keys ... ok
test text_is_preserved_without_trimming_and_document_bytes_are_deterministic ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 7 tests
test embedded_newline_in_late_text_refuses_the_entire_sequence ... ok
test empty_sequence_is_empty_formatting_not_a_valid_receipt_claim ... ok
test invalid_late_machine_token_refuses_the_entire_sequence ... ok
test invalid_late_key_refuses_the_entire_sequence ... ok
test preserves_caller_order_without_claiming_schema_order ... ok
test repeated_invocations_are_byte_identical ... ok
test utf8_quotes_and_empty_quoted_text_produce_exact_bytes ... ok

test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 9 tests
test duplicate_field_refuses ... ok
test empty_input_refuses ... ok
test invalid_late_value_refuses_entire_fragment ... ok
test exact_ten_core_fields_emit_exact_bytes ... ok
test missing_mandatory_field_refuses ... ok
test misspelled_or_wrong_case_key_refuses ... ok
test repeated_input_is_byte_identical ... ok
test swapped_fields_refuse ... ok
test unexpected_field_refuses_for_core_only_api ... ok

test result: ok. 9 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_registered_emittable_classes ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test constructs_exact_canonical_filename_candidates ... ok
test preserves_extension_without_case_or_unicode_normalization ... ok
test refuses_noncanonical_class_without_repair ... ok
test refuses_invalid_timestamp_uuid_and_empty_extension ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test recognizes_governed_namespace_and_class ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_invalid_class_boundaries ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test extension_does_not_determine_semantic_class ... ok
test preserves_literal_tokens_without_claiming_authority ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok
test extracts_semantic_class_and_serialization_separately ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok
test rejects_nonexistent_gregorian_dates ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

=== CP018 POST-FORMAT VERIFICATION ===
Date: 2026-10-21
Git HEAD: 339cf12e747738d89442ce401feeea1afcd19dc6
Rustfmt check exit code: 0
Full regression exit code: 0
Test suites: 18
Passing tests: 94
Expected passing tests: 94
Source and test hashes unchanged: True
Result: PASS
Rustfmt StdOut: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-018\CP018_PostFormat_Check_StdOut.txt
Rustfmt StdErr: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-018\CP018_PostFormat_Check_StdErr.txt
Regression StdOut: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-018\CP018_PostFormat_Regression_StdOut.txt
Regression StdErr: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-018\CP018_PostFormat_Regression_StdErr.txt
Git commit created: NO

=== CP018 RED TEST INSTALLATION ===
Date: 2026-10-21
Git HEAD: 339cf12e747738d89442ce401feeea1afcd19dc6
Test: tests/CP018_receipt_core_envelope.rs
Size: 5038 bytes
SHA256: AFD7B86FF49F55DD71B265CE8B9000A87228EB01BED701029BD5E508306F150C
Installation: PASS
Implementation modified by this command: NO
RED executed: NO

=== CP018 RED TEST ===
Date: 2026-10-21
Git HEAD: 339cf12e747738d89442ce401feeea1afcd19dc6
Test SHA256: AFD7B86FF49F55DD71B265CE8B9000A87228EB01BED701029BD5E508306F150C
Command: cargo test --test CP018_receipt_core_envelope
Exit code: 101
Result: EXPECTED RED COMPILATION FAILURE
StdOut: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-018\CP018_RED_StdOut.txt
StdErr: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-018\CP018_RED_StdErr.txt
Implementation modified: NO

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
error[E0432]: unresolved import `data_sculptor_core::serialize_canonical_receipt_core_envelope`
  --> tests\CP018_receipt_core_envelope.rs:12:45
   |
12 | use data_sculptor_core::{ReceiptFieldValue, serialize_canonical_receipt_core_envelope};
   |                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `serialize_canonical_receipt_core_envelope` in the root
   |
help: a similar name exists in the module
   |
12 - use data_sculptor_core::{ReceiptFieldValue, serialize_canonical_receipt_core_envelope};
12 + use data_sculptor_core::{ReceiptFieldValue, serialize_canonical_receipt_field_line};
   |

For more information about this error, try `rustc --explain E0432`.
error: could not compile `data_sculptor_core` (test "CP018_receipt_core_envelope") due to 1 previous error

=== CP018 FULL NATIVE REGRESSION ===
Date: 2026-10-21
Git HEAD: 339cf12e747738d89442ce401feeea1afcd19dc6
Command: cargo test --all-targets
Exit code: 0
Test suites reported: 18
Total passing tests: 94
Expected baseline: 85 prior + 9 CP018 = 94
Source and test hashes unchanged: True
Result: PASS
StdOut: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-018\CP018_Regression_StdOut.txt
StdErr: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-018\CP018_Regression_StdErr.txt
Git commit created: NO

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 3.36s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)
     Running tests\CP008_source_eligibility.rs (target\debug\deps\CP008_source_eligibility-194c314726b26929.exe)
     Running tests\CP009_exact_root_snapshot.rs (target\debug\deps\CP009_exact_root_snapshot-b26a1b02e36e8f07.exe)
     Running tests\CP010_cvt_filename_candidate.rs (target\debug\deps\CP010_cvt_filename_candidate-ce216c0140f6b173.exe)
     Running tests\CP011_cvt_scr_candidate_identity.rs (target\debug\deps\CP011_cvt_scr_candidate_identity-8bc68fabbbb42eb4.exe)
     Running tests\CP012_scr_filename_candidate.rs (target\debug\deps\CP012_scr_filename_candidate-7c39746d8bb6fac7.exe)
     Running tests\CP013_scr_rcp_candidate_identity.rs (target\debug\deps\CP013_scr_rcp_candidate_identity-4f7c7bea8654150d.exe)
     Running tests\CP014_rcp_filename_candidate_identity.rs (target\debug\deps\CP014_rcp_filename_candidate_identity-249a1cd498442ced.exe)
     Running tests\CP015_scr_rcp_filename_pair_identity.rs (target\debug\deps\CP015_scr_rcp_filename_pair_identity-526d10560ef9b891.exe)
     Running tests\CP016_receipt_field_serialization.rs (target\debug\deps\CP016_receipt_field_serialization-8c3a6628143f8cc6.exe)
     Running tests\CP017_receipt_field_sequence.rs (target\debug\deps\CP017_receipt_field_sequence-c803df96b76f21ee.exe)
     Running tests\CP018_receipt_core_envelope.rs (target\debug\deps\CP018_receipt_core_envelope-b0aa754d7846f001.exe)
     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)
     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)
     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)
     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)
     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)
     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 5 tests
test makes_no_case_or_unicode_normalization_claim ... ok
test accepts_analyst_csv_final_extension_in_ascii_case_variants ... ok
test refuses_paths_traversal_and_external_references ... ok
test refuses_reserved_namespace_even_if_name_looks_like_csv ... ok
test rejects_non_csv_or_nonfinal_csv_extensions ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 8 tests
test finds_one_exact_reported_regular_file ... ok
test candidate_preflight_runs_before_root_matching ... ok
test duplicate_exact_entries_refuse_instead_of_picking_first ... ok
test full_filename_match_is_exact_and_case_sensitive ... ok
test never_trims_to_find_a_different_physical_name ... ok
test reported_non_regular_entries_do_not_pass ... ok
test result_is_order_independent_and_empty_snapshot_is_not_found ... ok
test unicode_scalar_sequence_is_not_normalized ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test accepts_exact_canonical_cvt_csv_candidate ... ok
test refuses_wrong_classes_and_extensions ... ok
test refuses_malformed_canonical_identity ... ok
test refuses_paths_and_noncanonical_references ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test derives_exact_corresponding_scr_identity ... ok
test refuses_other_semantic_classes ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_paths_whitespace_and_noncanonical_names ... ok
test refuses_wrong_extension_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test accepts_canonical_scr_csv_candidate ... ok
test accepts_canonical_scr_txt_candidate ... ok
test refuses_noncanonical_namespace_class_and_extension ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_and_whitespace ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test derives_rcp_candidate_only_with_explicit_class ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_non_scr_and_noncanonical_source_classes ... ok
test refuses_invalid_identity_paths_and_whitespace ... ok
test refuses_unsupported_or_incorrectly_cased_final_classes ... ok
test refuses_wrong_or_ambiguous_serialization_extensions ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test accepts_canonical_rcp_txt_identity ... ok
test recognizes_existing_scr_to_rcp_derivation ... ok
test refuses_invalid_timestamp_uuid_and_envelope ... ok
test refuses_noncanonical_serialization ... ok
test refuses_paths_and_whitespace ... ok
test refuses_wrong_semantic_class_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test accepts_matching_canonical_scr_and_rcp_txt_names ... ok
test refuses_mismatched_utc_timestamp_even_when_both_names_are_canonical ... ok
test refuses_paths_and_whitespace_on_either_side ... ok
test refuses_mismatched_uuid_even_when_both_names_are_canonical ... ok
test refuses_wrong_extensions_and_noncanonical_envelopes ... ok
test refuses_wrong_class_or_reversed_pair_order ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 8 tests
test filenames_and_utf8_free_text_are_double_quoted ... ok
test doubles_internal_quotes_without_backslash_escaping ... ok
test machine_tokens_have_exact_colon_space_and_single_lf ... ok
test machine_token_spelling_must_be_lexically_canonical ... ok
test non_negative_integers_use_ungrouped_ascii_decimal ... ok
test refuses_cr_or_lf_inside_any_single_field_value ... ok
test refuses_non_uppercase_ascii_field_keys ... ok
test text_is_preserved_without_trimming_and_document_bytes_are_deterministic ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 7 tests
test embedded_newline_in_late_text_refuses_the_entire_sequence ... ok
test empty_sequence_is_empty_formatting_not_a_valid_receipt_claim ... ok
test invalid_late_key_refuses_the_entire_sequence ... ok
test invalid_late_machine_token_refuses_the_entire_sequence ... ok
test preserves_caller_order_without_claiming_schema_order ... ok
test repeated_invocations_are_byte_identical ... ok
test utf8_quotes_and_empty_quoted_text_produce_exact_bytes ... ok

test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 9 tests
test duplicate_field_refuses ... ok
test empty_input_refuses ... ok
test invalid_late_value_refuses_entire_fragment ... ok
test exact_ten_core_fields_emit_exact_bytes ... ok
test missing_mandatory_field_refuses ... ok
test misspelled_or_wrong_case_key_refuses ... ok
test repeated_input_is_byte_identical ... ok
test swapped_fields_refuse ... ok
test unexpected_field_refuses_for_core_only_api ... ok

test result: ok. 9 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_registered_emittable_classes ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test preserves_extension_without_case_or_unicode_normalization ... ok
test constructs_exact_canonical_filename_candidates ... ok
test refuses_invalid_timestamp_uuid_and_empty_extension ... ok
test refuses_noncanonical_class_without_repair ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test rejects_noncanonical_uuid_and_missing_extension ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok
test accepts_canonical_immutable_filename_envelopes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test recognizes_governed_namespace_and_class ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_invalid_class_boundaries ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test extension_does_not_determine_semantic_class ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok
test extracts_semantic_class_and_serialization_separately ... ok
test preserves_literal_tokens_without_claiming_authority ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_nonexistent_gregorian_dates ... ok
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

=== CP018 RUSTFMT CHECK ===
Date: 2026-10-21
Git HEAD: 339cf12e747738d89442ce401feeea1afcd19dc6
Command: cargo fmt --all -- --check
Exit code: 1
Hashes unchanged: True
Result: INVESTIGATION REQUIRED
StdOut: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-018\CP018_Rustfmt_StdOut.txt
StdErr: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-018\CP018_Rustfmt_StdErr.txt

Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP018_receipt_core_envelope.rs:99:
     for (left, right) in [(0, 1), (4, 5), (8, 9)] {
         let mut fields = valid_core();
         fields.swap(left, right);
-        assert_eq!(
-            serialize_canonical_receipt_core_envelope(&fields),
-            None
-        );
+        assert_eq!(serialize_canonical_receipt_core_envelope(&fields), None);
     }
 }
 
Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP018_receipt_core_envelope.rs:124:
     for wrong in ["RECEIPT_FILENAMEX", "Receipt_FILENAME"] {
         let mut fields = valid_core();
         fields[1].0 = wrong;
-        assert_eq!(
-            serialize_canonical_receipt_core_envelope(&fields),
-            None
-        );
+        assert_eq!(serialize_canonical_receipt_core_envelope(&fields), None);
     }
 }
 

RED5SORCERY DATA SCULPTOR | DAY 074 | CP018 SCOPE INVESTIGATION
Date: 2026-10-21
Status: PROPOSED — NOT YET APPROVED FOR RED TEST INSTALLATION OR IMPLEMENTATION
Baseline: CP017 at Git HEAD 339cf12e747738d89442ce401feeea1afcd19dc6
Source: Day 073 Development Log embedded H-31 402-row frozen-requirement ledger; CP016/CP017 source diffs and tests preserved in the Development Log and Git staging evidence.

PURPOSE
Provide a pure in-memory formatter for the EXACT ordered 10-key Receipt core field sequence, using CP017's existing caller-order field-sequence serializer. W002-RCP-005 and W002-RCP-006 remain PARTIAL after this work.

FROZEN KEY ORDER — W002-RCP-006
01 RECEIPT_VERSION
02 RECEIPT_FILENAME
03 RECEIPT_UTC
04 WORK_ORDER_FILENAME
05 OPERATION
06 RUN_STARTED_UTC
07 RUN_FINISHED_UTC
08 RESULT
09 DIAGNOSTIC_ID
10 IDENTITY_COLLISION_RETRIES

PROPOSED BEHAVIOR
- Accept exactly ten (key, typed field value) entries in the prescribed order.
- Refuse an omission, duplicate, extra, typo, or out-of-order key; no silent sorting, insertion, or correction.
- Delegate per-field lexical validation and KEY: VALUE formatting to CP016/CP017.
- On any refusal return None, not partial output.
- Valid inputs produce deterministic UTF-8 with LF lines and no BOM.
- The returned fragment contains only the ten core lines. It is NOT a whole Receipt and MUST NOT be published as one.

RED TEST CONTRACT (PROPOSED)
1. Ten exact keys in order produce exact expected bytes.
2. Missing any field refuses.
3. Duplicate field refuses.
4. Swapped fields refuse.
5. Unexpected eleventh field refuses.
6. Typo/wrong-case key refuses.
7. Late invalid typed value refuses entire fragment.
8. Repeated invocation yields byte-identical output.

EXCLUSIONS
No value-specific semantics (including RECEIPT_VERSION=1, RESULT vocabulary, diagnostic correlation, datetime validation/timeline invariants, WKO/RCP filename identity); no operation-specific sections or CREATED_ARTIFACT tail; no filesystem access, execution, publication, browser acceptance, or independent adversarial QA.

ENGINEERING GATES
T approval of this proposed scope -> install RED test -> capture RED evidence -> implement minimum GREEN change -> focused and full regression -> rustfmt check -> WASM library build -> SHA-256 evidence inventories -> ZIP original TXT evidence -> Git staging inspection -> T explicit acceptance -> Git banking.
Do not treat the approved investigation as approval to modify product code or to accept CP018.

=== CP018 WASM LIBRARY BUILD ===
Date: 2026-10-21
Git HEAD: 339cf12e747738d89442ce401feeea1afcd19dc6
Rust version: rustc 1.97.1 (8bab26f4f 2026-07-14)
Command: cargo build --target wasm32-unknown-unknown --lib
Exit code: 0
Source SHA256: 69A512D5DF854EAD350C220647F9B58657F2BB7A626E87BCED342916D4761955
Test SHA256: FAF47D9C1CE26D0AEC3EB6A857B8FC1EE9DD79505795765C159FE1A00A3DE8D3
Source and test hashes unchanged: True
Result: PASS
StdOut: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-018\CP018_WASM_Build_StdOut.txt
StdErr: C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-018\CP018_WASM_Build_StdErr.txt
Browser runtime verified: NO
Git commit created: NO

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.53s

ProjectDay,CommitSHA,ChangeStatus,Path,Category,OldBlobSHA,NewBlobSHA,OldBlobBytes,NewBlobBytes,GrossBytes,NetBytes,SHA256,MeasurementBasis
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_Content_Manifest.zip,Evidence,,96dccafb9901e645c11645b826692a3470c85ce8,0,2520,2520,2520,A13ADC852231998A8DD5C62D01B4A8AE559FA33474B2E4A6C29232ADE8EC4073,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_Evidence_Preflight_Corrected_Record.zip,Evidence,,de72d4ebfa5cc559c3eb33a0c7924dfa0420bd02,0,2241,2241,2241,103A91FFA87B7C9F05DCAC8CD39CD5BC122714F809B5DC14A96E9AE57DEB96CE,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_Evidence_Preflight_Record.zip,Evidence,,4c3dd6e36f7cf2051653605cafbd565d176c4c56,0,285,285,285,C0F03B9F5488805E43A6DD04F0CA3E9013E45EC901DEF68E898669F129EEBB1D,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_Full_Regression_Run_Record.zip,Evidence,,f5663afb99e3a31357ca4b73b719b9be4724bf07,0,1436,1436,1436,7BE9A924853651CC9110C806C6A39C608EA2B7C2CD09143037D8FE58125955D6,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_Full_Regression_StdErr.zip,Evidence,,0d3ff4abf532ff6e343f8505193ae8c59045e986,0,827,827,827,4B220AC4B0B9186478084042AD1546ADD61B25FF285ACB518E6D90128D636CFD,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_Full_Regression_StdOut.zip,Evidence,,0e017a9e9dd5e3599f12a7d534b051428aeb5c66,0,1784,1784,1784,4904A2DB33F1A2DD09CD9E6194B62153D56728757B36E584DFFFB2B0E9816294,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_GREEN_Run_Record.zip,Evidence,,0ad51ba1c38bb3b735937b848a6e8e03c9cb9b7c,0,846,846,846,8E90849A6E979A214D67499748BBB55335D5F2484823969B0D15246B5A0D91E3,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_GREEN_StdErr.zip,Evidence,,32568b3b35e544a40c200520c24d04c50c60e540,0,349,349,349,490E6EB9D9E2D1B7C0E9A54C0077571D1A5496332C26E92AF1457854C39F31AB,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_GREEN_StdOut.zip,Evidence,,5a0268f57c5cebd4265408be215a0b5d1a77dd79,0,411,411,411,22677475956810E9D299E88BA8A3EF37B8ABA2EF2B8F1AB26B99591AFC08C144,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_PostFormat_GREEN_Run_Record.zip,Evidence,,ee647b6bc8d65ade515b62b383d3691f38c26967,0,985,985,985,9C244F3490F2ED6BE48BB54FBBE21A75AB17DEF97B141CCAF1500E5FE68A955C,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_PostFormat_GREEN_StdErr.zip,Evidence,,564a9ea66c07f942a87687e68bdcbcf93457439e,0,370,370,370,0F5924DBBA0E37C262E203919D21E086D1A841511B3723AA9C20E02953F78EA0,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_PostFormat_GREEN_StdOut.zip,Evidence,,d3fb07a8dc10abaed97d0b0d6084b109e386fe65,0,433,433,433,147D165CAF2A53DDDB788A90F48011C7F8CED484D790730CC7BF8427B2BF5EB1,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_RED_Run_Record.zip,Evidence,,8beb6dec9445d272596733db11378596578346da,0,746,746,746,C5ABAA7814101EC1A9EE3629611588A37AB88BDE30A43B24415D12D730891D7C,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_RED_StdErr.zip,Evidence,,e786ab6934995bef2cea292442519f5593170709,0,488,488,488,68700D7A857FA4B3A939D4771748614EF7775E6F6CB5009246AD528688D5689A,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_RED_StdOut.zip,Evidence,,0ae5c14226274d2668f21bcc4b08528d21f176ba,0,138,138,138,F369741A389DFACC9161D897F9FD79A051AEC611897068F3959ED158BBCD06B5,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_Rustfmt_Check_Run_Record.zip,Evidence,,b94c44f0f318ebe357baccdbf770789372ac6c87,0,814,814,814,9F968E8CA709FE5A49FFAF86DA1A63B644142055B8A3439BA0C8A39B2BA99268,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_Rustfmt_Check_StdErr.zip,Evidence,,4bfd97cd7b775e5069e69f2f217ac0c9331bb85f,0,158,158,158,E2D793490C0C03C664F96200908C44BD70AC74F31DD48F4442F4910DF987944F,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_Rustfmt_Check_StdOut.zip,Evidence,,ccf37712978eb2c4b8e44f66f27b57783c2c74d9,0,483,483,483,4EC5BC21EC56C45CA6BD15D01C384F09F59C2618B8841307D8973E330EE88C55,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_Rustfmt_Correction_Record.zip,Evidence,,683b69f45d995688552d92caec230aff4ae4b026,0,410,410,410,0B0E8A2148461B6C6701511A11F921AF29547C63C339147499848015464A19E3,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_Rustfmt_Correction_StdErr.zip,Evidence,,9e0cc39feb599ddcfd7a94257d2b62e75a9669d0,0,168,168,168,C1DA937CA56B1EE441507AEF6ECF7EF6A4C60AA131B927CB11A428CA23ED780B,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_Rustfmt_Correction_StdOut.zip,Evidence,,6c8850a03e2d7ea803d3fa92781315c196469340,0,168,168,168,0CC20205C377594C63A3845E91164E3ECE2AC85CDD8438FDB138B3EDC2C47FBA,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_Rustfmt_Recheck_StdErr.zip,Evidence,,9a1f8eb70856631e9c2ac4498d7372ce5f6d7841,0,162,162,162,01247A1F53EADFCF98CDC0FC99BB07BF4D8EFD2815E92CDAB6D324BB0909929B,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_Rustfmt_Recheck_StdOut.zip,Evidence,,16947582a0b13ae33fbb1b75c3c0e3b6d8319d8a,0,162,162,162,B0667724A1DB90A6F58A53F5D88BE110CD787C5B1A64EE22B6B9F7D60C6A3F25,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_WASM_Build_Run_Record.zip,Evidence,,8b2ef2dbcaffb737902f29d39cba302cad3ebeb5,0,630,630,630,F4DDBD51D8CE430EA1B9D342DBE63FF14BA191F6ECE6710A5D04AD8E97AC0097,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_WASM_Build_StdErr.zip,Evidence,,932e8122c8fb64f419ed82a424b594d8d1efaa7e,0,292,292,292,2C310DEF2C179848BF6B0863F8AD23EAE4B74C72CA1278A1CA5B759DD0A27BE2,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,Evidence/CP-017/CP017_WASM_Build_StdOut.zip,Evidence,,e9687fb8e56bd26235322418586b02a27bbbb1a0,0,152,152,152,1D4C1A04772D47FA681410051F484C75F9314CB06BE778F7DDD6E56B656B57B6,ZIP custody SHA256 and staged Git blob identity
073,339cf12e747738d89442ce401feeea1afcd19dc6,M,src/lib.rs,Source,39d0a674dcf55ac2244fbe2333ab0b0cd15d54c9,2d27aefb95c329649d3362e1ec6398d460919bde,15525,16145,16145,620,903378F90A61E141EE008D60758F0241CAD67A5737DE301F4A1D1FBB61F9F3AE,Full source bytes; Git blob hash matches staged diff
073,339cf12e747738d89442ce401feeea1afcd19dc6,A,tests/CP017_receipt_field_sequence.rs,Tests,,dd40fb7708c3db0052140bfbf5cdd2ec21103de1,0,3274,3274,3274,3EF60E8BA18CAFDB959AFBDF281A50BA23A1A615A973B17F23668792EFABD801,Formatted test bytes; Git blob hash matches staged diff

��=== DAY 073 PREFLIGHT ===

=== GIT HEAD ===

fde0f0a8b96c92f6cfb80b517396ff5512cccd13

=== GIT STATUS ===

## master

?? Evidence/CP-016/CP016_Formatting_Amendment_Installation_Record.txt

?? Evidence/CP-016/CP016_Formatting_Candidate_Record.txt

?? Evidence/CP-016/CP016_Formatting_Candidate_StdErr.txt

?? Evidence/CP-016/CP016_Formatting_Candidate_StdOut.txt

?? Evidence/CP-016/CP016_GREEN_Installation_Record.txt

?? Evidence/CP-016/CP016_GREEN_Reconciliation_Record.txt

?? Evidence/CP-016/CP016_GREEN_Refusal_Diagnostic.txt

?? Evidence/CP-016/CP016_GREEN_StdErr.txt

?? Evidence/CP-016/CP016_GREEN_StdOut.txt

?? Evidence/CP-016/CP016_GREEN_Verification_Run_Record.txt

?? Evidence/CP-016/CP016_GREEN_Verification_StdErr.txt

?? Evidence/CP-016/CP016_GREEN_Verification_StdOut.txt

?? Evidence/CP-016/CP016_PostAmendment_Regression_Run_Record.txt

?? Evidence/CP-016/CP016_PostAmendment_Regression_StdErr.txt

?? Evidence/CP-016/CP016_PostAmendment_Regression_StdOut.txt

?? Evidence/CP-016/CP016_PostFormat_Run_Record.txt

?? Evidence/CP-016/CP016_PostFormat_StdErr.txt

?? Evidence/CP-016/CP016_PostFormat_StdOut.txt

?? Evidence/CP-016/CP016_PreCustody_Inventory.txt

?? Evidence/CP-016/CP016_RED_Run_Record.txt

?? Evidence/CP-016/CP016_RED_StdErr.txt

?? Evidence/CP-016/CP016_RED_StdOut.txt

?? Evidence/CP-016/CP016_Regression_Run_Record.txt

?? Evidence/CP-016/CP016_Regression_StdErr.txt

?? Evidence/CP-016/CP016_Regression_StdOut.txt

?? Evidence/CP-016/CP016_Rustfmt_Run_Record.txt

?? Evidence/CP-016/CP016_Rustfmt_StdErr.txt

?? Evidence/CP-016/CP016_Rustfmt_StdOut.txt

?? Evidence/CP-016/CP016_WASM_Build_Run_Record.txt

?? Evidence/CP-016/CP016_WASM_Build_StdErr.txt

?? Evidence/CP-016/CP016_WASM_Build_StdOut.txt

=== RUST VERSION ===

rustc 1.97.1 (8bab26f4f 2026-07-14)

=== CARGO VERSION ===

cargo 1.97.1 (c980f4866 2026-06-30)

=== ACTIVE TOOLCHAIN ===

1.97.1-x86_64-pc-windows-msvc (overridden by 'C:\Users\Admin\Downloads\DataSculptor-WASM002\rust-toolchain.toml')

��=== DAY 073 CP017 SCOPE INSPECTION ===

=== LAST COMMIT ===

fde0f0a8b96c92f6cfb80b517396ff5512cccd13

CP016: canonical Receipt field-line serialization and evidence

=== TRACKED SOURCE AND TEST FILES ===

src/lib.rs

tests/CP008_source_eligibility.rs

tests/CP009_exact_root_snapshot.rs

tests/CP010_cvt_filename_candidate.rs

tests/CP011_cvt_scr_candidate_identity.rs

tests/CP012_scr_filename_candidate.rs

tests/CP013_scr_rcp_candidate_identity.rs

tests/CP014_rcp_filename_candidate_identity.rs

tests/CP015_scr_rcp_filename_pair_identity.rs

tests/CP016_receipt_field_serialization.rs

tests/artifact_class_disposition.rs

tests/artifact_filename_construction.rs

tests/artifact_filename_envelope.rs

tests/artifact_namespace.rs

tests/artifact_serialization_separation.rs

tests/artifact_utc_timestamp.rs

=== RECEIPT AND SERIALIZATION REFERENCES ===

src/lib.rs:385:/// Recognizes a canonical RCP Receipt filename candidate.

src/lib.rs:387:/// Lexical recognition only. This does not verify Receipt contents,

src/lib.rs:409:/// Receipt contents, promote staged artifacts, publish, or grant authority.

src/lib.rs:423:/// One typed canonical Receipt field value, before whole-Receipt assembly.

src/lib.rs:428:pub enum ReceiptFieldValue<'a> {

src/lib.rs:434:/// Serializes exactly one canonical Receipt `KEY: VALUE` line with one LF.

src/lib.rs:436:/// Pure, deterministic formatting only: does not validate whole-Receipt

src/lib.rs:439:pub fn serialize_canonical_receipt_field_line(

src/lib.rs:441:    value: ReceiptFieldValue<'_>,

src/lib.rs:443:    if !is_receipt_field_identifier(key) {

src/lib.rs:448:        ReceiptFieldValue::MachineToken(token) => {

src/lib.rs:449:            if !is_receipt_field_identifier(token) {

src/lib.rs:454:        ReceiptFieldValue::NonNegativeInteger(value) => value.to_string(),

src/lib.rs:455:        ReceiptFieldValue::QuotedText(text) => {

src/lib.rs:469:fn is_receipt_field_identifier(value: &str) -> bool {

tests/CP015_scr_rcp_filename_pair_identity.rs:4:// No file reads/writes, Receipt-content validation, promotion, or authority.

tests/CP016_receipt_field_serialization.rs:2:// Proposed T-approval gate: deterministic serialization of ONE canonical Receipt field line.

tests/CP016_receipt_field_serialization.rs:4:// No full Receipt schema, key ordering, operation vocabulary, filesystem I/O,

tests/CP016_receipt_field_serialization.rs:5:// WKO authority, staged publication, or claim that a durable Receipt exists.

tests/CP016_receipt_field_serialization.rs:8:use data_sculptor_core::{ReceiptFieldValue, serialize_canonical_receipt_field_line};

tests/CP016_receipt_field_serialization.rs:13:        serialize_canonical_receipt_field_line(

tests/CP016_receipt_field_serialization.rs:15:            ReceiptFieldValue::MachineToken("SUCCESS")

tests/CP016_receipt_field_serialization.rs:20:        serialize_canonical_receipt_field_line(

tests/CP016_receipt_field_serialization.rs:22:            ReceiptFieldValue::MachineToken("NOT_AVAILABLE")

tests/CP016_receipt_field_serialization.rs:37:            serialize_canonical_receipt_field_line(

tests/CP016_receipt_field_serialization.rs:39:                ReceiptFieldValue::NonNegativeInteger(value)

tests/CP016_receipt_field_serialization.rs:49:        serialize_canonical_receipt_field_line(

tests/CP016_receipt_field_serialization.rs:51:            ReceiptFieldValue::QuotedText("__DS__WKO__20261015T123456789Z__550e8400-e29b-41d4-a716-446655440000.txt")

tests/CP016_receipt_field_serialization.rs:56:        serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText("caf%# ���")),

tests/CP016_receipt_field_serialization.rs:64:        serialize_canonical_receipt_field_line(

tests/CP016_receipt_field_serialization.rs:66:            ReceiptFieldValue::QuotedText("He said \"go\"")

tests/CP016_receipt_field_serialization.rs:76:            serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText(text)),

tests/CP016_receipt_field_serialization.rs:82:            serialize_canonical_receipt_field_line(

tests/CP016_receipt_field_serialization.rs:84:                ReceiptFieldValue::MachineToken(token)

tests/CP016_receipt_field_serialization.rs:106:            serialize_canonical_receipt_field_line(key, ReceiptFieldValue::MachineToken("SUCCESS")),

tests/CP016_receipt_field_serialization.rs:112:        serialize_canonical_receipt_field_line(

tests/CP016_receipt_field_serialization.rs:114:            ReceiptFieldValue::QuotedText("example.csv")

tests/CP016_receipt_field_serialization.rs:134:            serialize_canonical_receipt_field_line(

tests/CP016_receipt_field_serialization.rs:136:                ReceiptFieldValue::MachineToken(token)

tests/CP016_receipt_field_serialization.rs:147:        serialize_canonical_receipt_field_line(

tests/CP016_receipt_field_serialization.rs:149:            ReceiptFieldValue::MachineToken("SUCCESS"),

tests/CP016_receipt_field_serialization.rs:152:        serialize_canonical_receipt_field_line("COUNT", ReceiptFieldValue::NonNegativeInteger(0))

tests/CP016_receipt_field_serialization.rs:154:        serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText(" a  b "))

tests/CP016_receipt_field_serialization.rs:156:        serialize_canonical_receipt_field_line("EMPTY", ReceiptFieldValue::QuotedText("")).unwrap(),

=== COMMITTED CP016 EVIDENCE COUNT ===

36

=== UNTRACKED CP016 TXT COUNT ===

31

=== TRACKED FILE DIFF SUMMARY ===

��=== DAY 073 CP017 CORRECTED EVIDENCE PREFLIGHT ===

RECOVERY=Original report attempted to hash itself while open.

ORIGINAL_FAILED_RECORD=PRESERVED

=== TXT INVENTORY ===

TXT_COUNT=24

FILE=CP017_Evidence_Preflight_Record.txt | BYTES=188 | SHA256=4D36B07E9D9651142E6BFDD21398CA9D9691A357C164D7C5A53EEAF4ACBB8F00

FILE=CP017_Full_Regression_Run_Record.txt | BYTES=8508 | SHA256=4ACB62E7F1E0BEB38DF413AC7A38B87CC1FE38C35F597F5B7A6DC23E10072CFB

FILE=CP017_Full_Regression_StdErr.txt | BYTES=2242 | SHA256=1E338F8DC167D9695157C9637052C4E270EB303804714A507D50EA8E8A52F2DF

FILE=CP017_Full_Regression_StdOut.txt | BYTES=6992 | SHA256=9B2DA9F06ECF6007869B16FD89A22D59DEF25312CD5CD570E480666A4636B90E

FILE=CP017_GREEN_Run_Record.txt | BYTES=2042 | SHA256=CD0BAE12628FBD4FCE536191360EADDFA6EC698974BCFCB4D6640FF042DD67C3

FILE=CP017_GREEN_StdErr.txt | BYTES=281 | SHA256=28A4924A4BB410AA7C40CE2A0FAB8E9E009DA93AFD2189D4B488F49617FCE689

FILE=CP017_GREEN_StdOut.txt | BYTES=563 | SHA256=AED3071E322AA08697174CA8C8207875004E45293054ECA2202864F4DACE3BCD

FILE=CP017_PostFormat_GREEN_Run_Record.txt | BYTES=2242 | SHA256=0003649B678978569B4A4A2C26E77C4D78D65D004C0CBBB3F40CA022E0211898

FILE=CP017_PostFormat_GREEN_StdErr.txt | BYTES=281 | SHA256=76639D06E75B335DFB1F05EB19C5B655979B7C9A352755A0AA51302EA3EB4624

FILE=CP017_PostFormat_GREEN_StdOut.txt | BYTES=563 | SHA256=DBF25142FEE668E0CD285F26674B254CCA72AD85DE701D6FEBC856EE7A4A0285

FILE=CP017_RED_Run_Record.txt | BYTES=1942 | SHA256=4DBC984C57A68935F58330C05621AA75BB0C194037BB77694DAEB79FB3B1A0DB

FILE=CP017_RED_StdErr.txt | BYTES=806 | SHA256=B85072C4BCEB879B5886A781F8ADA3D7C28019F9AC116BDEA479B982748285C7

FILE=CP017_RED_StdOut.txt | BYTES=0 | SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855

FILE=CP017_Rustfmt_Check_Run_Record.txt | BYTES=1660 | SHA256=D5624C130F053962D764A5F7754F73A1265019DD2C0AC548E9CEB6FF8E9B0334

FILE=CP017_Rustfmt_Check_StdErr.txt | BYTES=0 | SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855

FILE=CP017_Rustfmt_Check_StdOut.txt | BYTES=554 | SHA256=794EF6E9F70AFB3E77BA83736CD20F86015502C6079F0533CF8F80F4696EA86F

FILE=CP017_Rustfmt_Correction_Record.txt | BYTES=510 | SHA256=359E31671309C59EB32E872181B3527DF6F59585DDB25573D2FA7A5F9D28F12F

FILE=CP017_Rustfmt_Correction_StdErr.txt | BYTES=0 | SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855

FILE=CP017_Rustfmt_Correction_StdOut.txt | BYTES=0 | SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855

FILE=CP017_Rustfmt_Recheck_StdErr.txt | BYTES=0 | SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855

FILE=CP017_Rustfmt_Recheck_StdOut.txt | BYTES=0 | SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855

FILE=CP017_WASM_Build_Run_Record.txt | BYTES=954 | SHA256=9C017895C670DDB5927B45A62FD3F93735A4E2FEE030E6D1B708911C589091E2

FILE=CP017_WASM_Build_StdErr.txt | BYTES=159 | SHA256=7B76A67C9343F408F3AB0EC3CEE356A38406DDB556413372BB9DE9AB99A791A1

FILE=CP017_WASM_Build_StdOut.txt | BYTES=0 | SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855

=== OTHER CP017 FILES ===

FILE=CP017_PreGREEN_lib.rs | BYTES=15525

FILE=CP017_PreRustfmt_Test_Original.rs | BYTES=3281

=== TRACKED SOURCE DIFF ===

 src/lib.rs | 15 +++++++++++++++

 1 file changed, 15 insertions(+)

=== GIT STATUS ===

 M src/lib.rs

?? Evidence/CP-016/CP016_Formatting_Amendment_Installation_Record.txt

?? Evidence/CP-016/CP016_Formatting_Candidate_Record.txt

?? Evidence/CP-016/CP016_Formatting_Candidate_StdErr.txt

?? Evidence/CP-016/CP016_Formatting_Candidate_StdOut.txt

?? Evidence/CP-016/CP016_GREEN_Installation_Record.txt

?? Evidence/CP-016/CP016_GREEN_Reconciliation_Record.txt

?? Evidence/CP-016/CP016_GREEN_Refusal_Diagnostic.txt

?? Evidence/CP-016/CP016_GREEN_StdErr.txt

?? Evidence/CP-016/CP016_GREEN_StdOut.txt

?? Evidence/CP-016/CP016_GREEN_Verification_Run_Record.txt

?? Evidence/CP-016/CP016_GREEN_Verification_StdErr.txt

?? Evidence/CP-016/CP016_GREEN_Verification_StdOut.txt

?? Evidence/CP-016/CP016_PostAmendment_Regression_Run_Record.txt

?? Evidence/CP-016/CP016_PostAmendment_Regression_StdErr.txt

?? Evidence/CP-016/CP016_PostAmendment_Regression_StdOut.txt

?? Evidence/CP-016/CP016_PostFormat_Run_Record.txt

?? Evidence/CP-016/CP016_PostFormat_StdErr.txt

?? Evidence/CP-016/CP016_PostFormat_StdOut.txt

?? Evidence/CP-016/CP016_PreCustody_Inventory.txt

?? Evidence/CP-016/CP016_RED_Run_Record.txt

?? Evidence/CP-016/CP016_RED_StdErr.txt

?? Evidence/CP-016/CP016_RED_StdOut.txt

?? Evidence/CP-016/CP016_Regression_Run_Record.txt

?? Evidence/CP-016/CP016_Regression_StdErr.txt

?? Evidence/CP-016/CP016_Regression_StdOut.txt

?? Evidence/CP-016/CP016_Rustfmt_Run_Record.txt

?? Evidence/CP-016/CP016_Rustfmt_StdErr.txt

?? Evidence/CP-016/CP016_Rustfmt_StdOut.txt

?? Evidence/CP-016/CP016_WASM_Build_Run_Record.txt

?? Evidence/CP-016/CP016_WASM_Build_StdErr.txt

?? Evidence/CP-016/CP016_WASM_Build_StdOut.txt

?? Evidence/CP-017/

?? tests/CP017_receipt_field_sequence.rs

=== STAGED FILES ===

=== WORKTREE WHITESPACE CHECK ===

GIT_DIFF_CHECK_EXIT_CODE=0

��=== DAY 073 CP017 EVIDENCE PREFLIGHT ===

=== ORIGINAL TXT FILE INVENTORY ===

TXT_COUNT=24

��=== DAY 073 CP017 RED TEST ===

TEST_SHA256=9AA7D93804733392EFD81C627684FDCD538A0CDA0A5A18D9A819791DB616EFC1

RED_EXIT_CODE=101

=== RED STDERR ===

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)

error[E0432]: unresolved import `data_sculptor_core::serialize_canonical_receipt_field_sequence`

 --> tests\CP017_receipt_field_sequence.rs:9:24

  |

9 |     ReceiptFieldValue, serialize_canonical_receipt_field_sequence,

  |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `serialize_canonical_receipt_field_sequence` in the root

  |

help: a similar name exists in the module

  |

9 -     ReceiptFieldValue, serialize_canonical_receipt_field_sequence,

9 +     ReceiptFieldValue, serialize_canonical_receipt_field_line,

  |



For more information about this error, try `rustc --explain E0432`.

error: could not compile `data_sculptor_core` (test "CP017_receipt_field_sequence") due to 1 previous error

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
error[E0432]: unresolved import `data_sculptor_core::serialize_canonical_receipt_field_sequence`
 --> tests\CP017_receipt_field_sequence.rs:9:24
  |
9 |     ReceiptFieldValue, serialize_canonical_receipt_field_sequence,
  |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `serialize_canonical_receipt_field_sequence` in the root
  |
help: a similar name exists in the module
  |
9 -     ReceiptFieldValue, serialize_canonical_receipt_field_sequence,
9 +     ReceiptFieldValue, serialize_canonical_receipt_field_line,
  |

For more information about this error, try `rustc --explain E0432`.
error: could not compile `data_sculptor_core` (test "CP017_receipt_field_sequence") due to 1 previous error

��=== DAY 073 CP017 GREEN TEST ===

SOURCE_HASH=VERIFIED

BACKUP_HASH=VERIFIED

TEST_HASH=VERIFIED

GREEN_EXIT_CODE=0

=== GREEN STDOUT ===



running 7 tests

test embedded_newline_in_late_text_refuses_the_entire_sequence ... ok

test empty_sequence_is_empty_formatting_not_a_valid_receipt_claim ... ok

test invalid_late_key_refuses_the_entire_sequence ... ok

test invalid_late_machine_token_refuses_the_entire_sequence ... ok

test preserves_caller_order_without_claiming_schema_order ... ok

test utf8_quotes_and_empty_quoted_text_produce_exact_bytes ... ok

test repeated_invocations_are_byte_identical ... ok



test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s



=== GREEN STDERR ===

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)

    Finished `test` profile [unoptimized + debuginfo] target(s) in 2.43s

     Running tests\CP017_receipt_field_sequence.rs (target\debug\deps\CP017_receipt_field_sequence-c803df96b76f21ee.exe)

running 7 tests
test embedded_newline_in_late_text_refuses_the_entire_sequence ... ok
test empty_sequence_is_empty_formatting_not_a_valid_receipt_claim ... ok
test invalid_late_key_refuses_the_entire_sequence ... ok
test invalid_late_machine_token_refuses_the_entire_sequence ... ok
test preserves_caller_order_without_claiming_schema_order ... ok
test utf8_quotes_and_empty_quoted_text_produce_exact_bytes ... ok
test repeated_invocations_are_byte_identical ... ok

test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 2.43s
     Running tests\CP017_receipt_field_sequence.rs (target\debug\deps\CP017_receipt_field_sequence-c803df96b76f21ee.exe)

��=== DAY 073 CP017 RUSTFMT CHECK ===

SOURCE_SHA256=903378F90A61E141EE008D60758F0241CAD67A5737DE301F4A1D1FBB61F9F3AE

TEST_SHA256=9AA7D93804733392EFD81C627684FDCD538A0CDA0A5A18D9A819791DB616EFC1

RUSTFMT_EXIT_CODE=1

=== RUSTFMT STDOUT ===

Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP017_receipt_field_sequence.rs:5:

 // No whole-Receipt schema, key ordering, vocabulary/uniqueness policy, filesystem

 // access, Work Order execution, authority, or publication is claimed.

 

␛[31m-use data_sculptor_core::{

␛[0m␛[31m-    ReceiptFieldValue, serialize_canonical_receipt_field_sequence,

␛[0m␛[31m-};

␛[0m␛[32m+use data_sculptor_core::{ReceiptFieldValue, serialize_canonical_receipt_field_sequence};

␛[0m 

 #[test]

 fn preserves_caller_order_without_claiming_schema_order() {

=== RUSTFMT STDERR ===

Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP017_receipt_field_sequence.rs:5:
 // No whole-Receipt schema, key ordering, vocabulary/uniqueness policy, filesystem
 // access, Work Order execution, authority, or publication is claimed.
 
␛[31m-use data_sculptor_core::{
␛[0m␛[31m-    ReceiptFieldValue, serialize_canonical_receipt_field_sequence,
␛[0m␛[31m-};
␛[0m␛[32m+use data_sculptor_core::{ReceiptFieldValue, serialize_canonical_receipt_field_sequence};
␛[0m 
 #[test]
 fn preserves_caller_order_without_claiming_schema_order() {

��=== CP017 RUSTFMT CORRECTION ===

ORIGINAL_TEST_SHA256=9AA7D93804733392EFD81C627684FDCD538A0CDA0A5A18D9A819791DB616EFC1

CORRECTION_EXIT_CODE=0

FORMATTED_TEST_SHA256=3EF60E8BA18CAFDB959AFBDF281A50BA23A1A615A973B17F23668792EFABD801

RECHECK_EXIT_CODE=0

��=== DAY 073 CP017 POST-FORMAT GREEN ===

SOURCE_SHA256=903378F90A61E141EE008D60758F0241CAD67A5737DE301F4A1D1FBB61F9F3AE

TEST_SHA256=3EF60E8BA18CAFDB959AFBDF281A50BA23A1A615A973B17F23668792EFABD801

POSTFORMAT_GREEN_EXIT_CODE=0

=== STDOUT ===



running 7 tests

test empty_sequence_is_empty_formatting_not_a_valid_receipt_claim ... ok

test embedded_newline_in_late_text_refuses_the_entire_sequence ... ok

test invalid_late_key_refuses_the_entire_sequence ... ok

test invalid_late_machine_token_refuses_the_entire_sequence ... ok

test preserves_caller_order_without_claiming_schema_order ... ok

test repeated_invocations_are_byte_identical ... ok

test utf8_quotes_and_empty_quoted_text_produce_exact_bytes ... ok



test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s



=== STDERR ===

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)

    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.40s

     Running tests\CP017_receipt_field_sequence.rs (target\debug\deps\CP017_receipt_field_sequence-c803df96b76f21ee.exe)

running 7 tests
test empty_sequence_is_empty_formatting_not_a_valid_receipt_claim ... ok
test embedded_newline_in_late_text_refuses_the_entire_sequence ... ok
test invalid_late_key_refuses_the_entire_sequence ... ok
test invalid_late_machine_token_refuses_the_entire_sequence ... ok
test preserves_caller_order_without_claiming_schema_order ... ok
test repeated_invocations_are_byte_identical ... ok
test utf8_quotes_and_empty_quoted_text_produce_exact_bytes ... ok

test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.40s
     Running tests\CP017_receipt_field_sequence.rs (target\debug\deps\CP017_receipt_field_sequence-c803df96b76f21ee.exe)

��=== DAY 073 CP017 FULL NATIVE REGRESSION ===

SOURCE_SHA256=903378F90A61E141EE008D60758F0241CAD67A5737DE301F4A1D1FBB61F9F3AE

TEST_SHA256=3EF60E8BA18CAFDB959AFBDF281A50BA23A1A615A973B17F23668792EFABD801

REGRESSION_EXIT_CODE=0

=== TEST RESULT SUMMARIES ===



test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

=== STDERR ===

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)

    Finished `test` profile [unoptimized + debuginfo] target(s) in 3.02s

     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)

     Running tests\CP008_source_eligibility.rs (target\debug\deps\CP008_source_eligibility-194c314726b26929.exe)

     Running tests\CP009_exact_root_snapshot.rs (target\debug\deps\CP009_exact_root_snapshot-b26a1b02e36e8f07.exe)

     Running tests\CP010_cvt_filename_candidate.rs (target\debug\deps\CP010_cvt_filename_candidate-ce216c0140f6b173.exe)

     Running tests\CP011_cvt_scr_candidate_identity.rs (target\debug\deps\CP011_cvt_scr_candidate_identity-8bc68fabbbb42eb4.exe)

     Running tests\CP012_scr_filename_candidate.rs (target\debug\deps\CP012_scr_filename_candidate-7c39746d8bb6fac7.exe)

     Running tests\CP013_scr_rcp_candidate_identity.rs (target\debug\deps\CP013_scr_rcp_candidate_identity-4f7c7bea8654150d.exe)

     Running tests\CP014_rcp_filename_candidate_identity.rs (target\debug\deps\CP014_rcp_filename_candidate_identity-249a1cd498442ced.exe)

     Running tests\CP015_scr_rcp_filename_pair_identity.rs (target\debug\deps\CP015_scr_rcp_filename_pair_identity-526d10560ef9b891.exe)

     Running tests\CP016_receipt_field_serialization.rs (target\debug\deps\CP016_receipt_field_serialization-8c3a6628143f8cc6.exe)

     Running tests\CP017_receipt_field_sequence.rs (target\debug\deps\CP017_receipt_field_sequence-c803df96b76f21ee.exe)

     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)

     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)

     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)

     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)

     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)

     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

   Doc-tests data_sculptor_core

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 5 tests
test accepts_analyst_csv_final_extension_in_ascii_case_variants ... ok
test makes_no_case_or_unicode_normalization_claim ... ok
test refuses_paths_traversal_and_external_references ... ok
test refuses_reserved_namespace_even_if_name_looks_like_csv ... ok
test rejects_non_csv_or_nonfinal_csv_extensions ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 8 tests
test candidate_preflight_runs_before_root_matching ... ok
test duplicate_exact_entries_refuse_instead_of_picking_first ... ok
test full_filename_match_is_exact_and_case_sensitive ... ok
test finds_one_exact_reported_regular_file ... ok
test never_trims_to_find_a_different_physical_name ... ok
test reported_non_regular_entries_do_not_pass ... ok
test result_is_order_independent_and_empty_snapshot_is_not_found ... ok
test unicode_scalar_sequence_is_not_normalized ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test refuses_malformed_canonical_identity ... ok
test accepts_exact_canonical_cvt_csv_candidate ... ok
test refuses_paths_and_noncanonical_references ... ok
test refuses_wrong_classes_and_extensions ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test derives_exact_corresponding_scr_identity ... ok
test refuses_invalid_utc_and_uuid ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_other_semantic_classes ... ok
test refuses_wrong_extension_and_case ... ok
test refuses_paths_whitespace_and_noncanonical_names ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test accepts_canonical_scr_csv_candidate ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_noncanonical_namespace_class_and_extension ... ok
test accepts_canonical_scr_txt_candidate ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_and_whitespace ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test derives_rcp_candidate_only_with_explicit_class ... ok
test refuses_non_scr_and_noncanonical_source_classes ... ok
test refuses_invalid_identity_paths_and_whitespace ... ok
test refuses_unsupported_or_incorrectly_cased_final_classes ... ok
test refuses_wrong_or_ambiguous_serialization_extensions ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test accepts_canonical_rcp_txt_identity ... ok
test refuses_noncanonical_serialization ... ok
test recognizes_existing_scr_to_rcp_derivation ... ok
test refuses_invalid_timestamp_uuid_and_envelope ... ok
test refuses_paths_and_whitespace ... ok
test refuses_wrong_semantic_class_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test accepts_matching_canonical_scr_and_rcp_txt_names ... ok
test refuses_mismatched_utc_timestamp_even_when_both_names_are_canonical ... ok
test refuses_paths_and_whitespace_on_either_side ... ok
test refuses_mismatched_uuid_even_when_both_names_are_canonical ... ok
test refuses_wrong_class_or_reversed_pair_order ... ok
test refuses_wrong_extensions_and_noncanonical_envelopes ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 8 tests
test filenames_and_utf8_free_text_are_double_quoted ... ok
test doubles_internal_quotes_without_backslash_escaping ... ok
test machine_token_spelling_must_be_lexically_canonical ... ok
test machine_tokens_have_exact_colon_space_and_single_lf ... ok
test non_negative_integers_use_ungrouped_ascii_decimal ... ok
test refuses_cr_or_lf_inside_any_single_field_value ... ok
test refuses_non_uppercase_ascii_field_keys ... ok
test text_is_preserved_without_trimming_and_document_bytes_are_deterministic ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 7 tests
test embedded_newline_in_late_text_refuses_the_entire_sequence ... ok
test empty_sequence_is_empty_formatting_not_a_valid_receipt_claim ... ok
test invalid_late_machine_token_refuses_the_entire_sequence ... ok
test invalid_late_key_refuses_the_entire_sequence ... ok
test repeated_invocations_are_byte_identical ... ok
test preserves_caller_order_without_claiming_schema_order ... ok
test utf8_quotes_and_empty_quoted_text_produce_exact_bytes ... ok

test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok
test distinguishes_registered_emittable_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test constructs_exact_canonical_filename_candidates ... ok
test preserves_extension_without_case_or_unicode_normalization ... ok
test refuses_invalid_timestamp_uuid_and_empty_extension ... ok
test refuses_noncanonical_class_without_repair ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test recognizes_governed_namespace_and_class ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_invalid_class_boundaries ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test extension_does_not_determine_semantic_class ... ok
test extracts_semantic_class_and_serialization_separately ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok
test preserves_literal_tokens_without_claiming_authority ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok
test rejects_nonexistent_gregorian_dates ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 3.02s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)
     Running tests\CP008_source_eligibility.rs (target\debug\deps\CP008_source_eligibility-194c314726b26929.exe)
     Running tests\CP009_exact_root_snapshot.rs (target\debug\deps\CP009_exact_root_snapshot-b26a1b02e36e8f07.exe)
     Running tests\CP010_cvt_filename_candidate.rs (target\debug\deps\CP010_cvt_filename_candidate-ce216c0140f6b173.exe)
     Running tests\CP011_cvt_scr_candidate_identity.rs (target\debug\deps\CP011_cvt_scr_candidate_identity-8bc68fabbbb42eb4.exe)
     Running tests\CP012_scr_filename_candidate.rs (target\debug\deps\CP012_scr_filename_candidate-7c39746d8bb6fac7.exe)
     Running tests\CP013_scr_rcp_candidate_identity.rs (target\debug\deps\CP013_scr_rcp_candidate_identity-4f7c7bea8654150d.exe)
     Running tests\CP014_rcp_filename_candidate_identity.rs (target\debug\deps\CP014_rcp_filename_candidate_identity-249a1cd498442ced.exe)
     Running tests\CP015_scr_rcp_filename_pair_identity.rs (target\debug\deps\CP015_scr_rcp_filename_pair_identity-526d10560ef9b891.exe)
     Running tests\CP016_receipt_field_serialization.rs (target\debug\deps\CP016_receipt_field_serialization-8c3a6628143f8cc6.exe)
     Running tests\CP017_receipt_field_sequence.rs (target\debug\deps\CP017_receipt_field_sequence-c803df96b76f21ee.exe)
     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)
     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)
     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)
     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)
     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)
     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)
   Doc-tests data_sculptor_core

��=== DAY 073 CP017 WASM LIBRARY BUILD ===

SOURCE_SHA256=903378F90A61E141EE008D60758F0241CAD67A5737DE301F4A1D1FBB61F9F3AE

TEST_SHA256=3EF60E8BA18CAFDB959AFBDF281A50BA23A1A615A973B17F23668792EFABD801

TARGET=wasm32-unknown-unknown

TOOLCHAIN=1.97.1

WASM_BUILD_EXIT_CODE=0

=== WASM STDOUT ===

=== WASM STDERR ===

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)

    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.28s

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.28s

=== DAY 073 CP017 FROZEN EVIDENCE INVENTORY ===
BASELINE_HEAD=fde0f0a8b96c92f6cfb80b517396ff5512cccd13
ORIGINAL_TXT_COUNT=25
STATUS=CONTENT_FROZEN_PENDING_ZIP_VERIFICATION
TXT_SHA256=BFC4AD9C215625B745E62AD0662A9367BDDA71D1F03F92F5A0A84C3BD5C63D83 | TXT_BYTES=10316 | BASENAME=CP017_Evidence_Preflight_Corrected_Record.txt
TXT_SHA256=4D36B07E9D9651142E6BFDD21398CA9D9691A357C164D7C5A53EEAF4ACBB8F00 | TXT_BYTES=188 | BASENAME=CP017_Evidence_Preflight_Record.txt
TXT_SHA256=4ACB62E7F1E0BEB38DF413AC7A38B87CC1FE38C35F597F5B7A6DC23E10072CFB | TXT_BYTES=8508 | BASENAME=CP017_Full_Regression_Run_Record.txt
TXT_SHA256=1E338F8DC167D9695157C9637052C4E270EB303804714A507D50EA8E8A52F2DF | TXT_BYTES=2242 | BASENAME=CP017_Full_Regression_StdErr.txt
TXT_SHA256=9B2DA9F06ECF6007869B16FD89A22D59DEF25312CD5CD570E480666A4636B90E | TXT_BYTES=6992 | BASENAME=CP017_Full_Regression_StdOut.txt
TXT_SHA256=CD0BAE12628FBD4FCE536191360EADDFA6EC698974BCFCB4D6640FF042DD67C3 | TXT_BYTES=2042 | BASENAME=CP017_GREEN_Run_Record.txt
TXT_SHA256=28A4924A4BB410AA7C40CE2A0FAB8E9E009DA93AFD2189D4B488F49617FCE689 | TXT_BYTES=281 | BASENAME=CP017_GREEN_StdErr.txt
TXT_SHA256=AED3071E322AA08697174CA8C8207875004E45293054ECA2202864F4DACE3BCD | TXT_BYTES=563 | BASENAME=CP017_GREEN_StdOut.txt
TXT_SHA256=0003649B678978569B4A4A2C26E77C4D78D65D004C0CBBB3F40CA022E0211898 | TXT_BYTES=2242 | BASENAME=CP017_PostFormat_GREEN_Run_Record.txt
TXT_SHA256=76639D06E75B335DFB1F05EB19C5B655979B7C9A352755A0AA51302EA3EB4624 | TXT_BYTES=281 | BASENAME=CP017_PostFormat_GREEN_StdErr.txt
TXT_SHA256=DBF25142FEE668E0CD285F26674B254CCA72AD85DE701D6FEBC856EE7A4A0285 | TXT_BYTES=563 | BASENAME=CP017_PostFormat_GREEN_StdOut.txt
TXT_SHA256=4DBC984C57A68935F58330C05621AA75BB0C194037BB77694DAEB79FB3B1A0DB | TXT_BYTES=1942 | BASENAME=CP017_RED_Run_Record.txt
TXT_SHA256=B85072C4BCEB879B5886A781F8ADA3D7C28019F9AC116BDEA479B982748285C7 | TXT_BYTES=806 | BASENAME=CP017_RED_StdErr.txt
TXT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | TXT_BYTES=0 | BASENAME=CP017_RED_StdOut.txt
TXT_SHA256=D5624C130F053962D764A5F7754F73A1265019DD2C0AC548E9CEB6FF8E9B0334 | TXT_BYTES=1660 | BASENAME=CP017_Rustfmt_Check_Run_Record.txt
TXT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | TXT_BYTES=0 | BASENAME=CP017_Rustfmt_Check_StdErr.txt
TXT_SHA256=794EF6E9F70AFB3E77BA83736CD20F86015502C6079F0533CF8F80F4696EA86F | TXT_BYTES=554 | BASENAME=CP017_Rustfmt_Check_StdOut.txt
TXT_SHA256=359E31671309C59EB32E872181B3527DF6F59585DDB25573D2FA7A5F9D28F12F | TXT_BYTES=510 | BASENAME=CP017_Rustfmt_Correction_Record.txt
TXT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | TXT_BYTES=0 | BASENAME=CP017_Rustfmt_Correction_StdErr.txt
TXT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | TXT_BYTES=0 | BASENAME=CP017_Rustfmt_Correction_StdOut.txt
TXT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | TXT_BYTES=0 | BASENAME=CP017_Rustfmt_Recheck_StdErr.txt
TXT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | TXT_BYTES=0 | BASENAME=CP017_Rustfmt_Recheck_StdOut.txt
TXT_SHA256=9C017895C670DDB5927B45A62FD3F93735A4E2FEE030E6D1B708911C589091E2 | TXT_BYTES=954 | BASENAME=CP017_WASM_Build_Run_Record.txt
TXT_SHA256=7B76A67C9343F408F3AB0EC3CEE356A38406DDB556413372BB9DE9AB99A791A1 | TXT_BYTES=159 | BASENAME=CP017_WASM_Build_StdErr.txt
TXT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | TXT_BYTES=0 | BASENAME=CP017_WASM_Build_StdOut.txt
=== SOURCE BACKUP SNAPSHOTS ===
BACKUP_SHA256=1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911 | BYTES=15525 | BASENAME=CP017_PreGREEN_lib.rs
BACKUP_SHA256=9AA7D93804733392EFD81C627684FDCD538A0CDA0A5A18D9A819791DB616EFC1 | BYTES=3281 | BASENAME=CP017_PreRustfmt_Test_Original.rs

=== DAY 073 CP017 ZIP PACKAGING VERIFICATION ===
BASELINE_HEAD=fde0f0a8b96c92f6cfb80b517396ff5512cccd13
ORIGINAL_TXT_COUNT=25
TXT_SHA256=BFC4AD9C215625B745E62AD0662A9367BDDA71D1F03F92F5A0A84C3BD5C63D83 | ZIP_SHA256=103A91FFA87B7C9F05DCAC8CD39CD5BC122714F809B5DC14A96E9AE57DEB96CE | TXT_BYTES=10316 | ZIP_BYTES=2241 | BASENAME=CP017_Evidence_Preflight_Corrected_Record.txt
TXT_SHA256=4D36B07E9D9651142E6BFDD21398CA9D9691A357C164D7C5A53EEAF4ACBB8F00 | ZIP_SHA256=C0F03B9F5488805E43A6DD04F0CA3E9013E45EC901DEF68E898669F129EEBB1D | TXT_BYTES=188 | ZIP_BYTES=285 | BASENAME=CP017_Evidence_Preflight_Record.txt
TXT_SHA256=4ACB62E7F1E0BEB38DF413AC7A38B87CC1FE38C35F597F5B7A6DC23E10072CFB | ZIP_SHA256=7BE9A924853651CC9110C806C6A39C608EA2B7C2CD09143037D8FE58125955D6 | TXT_BYTES=8508 | ZIP_BYTES=1436 | BASENAME=CP017_Full_Regression_Run_Record.txt
TXT_SHA256=1E338F8DC167D9695157C9637052C4E270EB303804714A507D50EA8E8A52F2DF | ZIP_SHA256=4B220AC4B0B9186478084042AD1546ADD61B25FF285ACB518E6D90128D636CFD | TXT_BYTES=2242 | ZIP_BYTES=827 | BASENAME=CP017_Full_Regression_StdErr.txt
TXT_SHA256=9B2DA9F06ECF6007869B16FD89A22D59DEF25312CD5CD570E480666A4636B90E | ZIP_SHA256=4904A2DB33F1A2DD09CD9E6194B62153D56728757B36E584DFFFB2B0E9816294 | TXT_BYTES=6992 | ZIP_BYTES=1784 | BASENAME=CP017_Full_Regression_StdOut.txt
TXT_SHA256=CD0BAE12628FBD4FCE536191360EADDFA6EC698974BCFCB4D6640FF042DD67C3 | ZIP_SHA256=8E90849A6E979A214D67499748BBB55335D5F2484823969B0D15246B5A0D91E3 | TXT_BYTES=2042 | ZIP_BYTES=846 | BASENAME=CP017_GREEN_Run_Record.txt
TXT_SHA256=28A4924A4BB410AA7C40CE2A0FAB8E9E009DA93AFD2189D4B488F49617FCE689 | ZIP_SHA256=490E6EB9D9E2D1B7C0E9A54C0077571D1A5496332C26E92AF1457854C39F31AB | TXT_BYTES=281 | ZIP_BYTES=349 | BASENAME=CP017_GREEN_StdErr.txt
TXT_SHA256=AED3071E322AA08697174CA8C8207875004E45293054ECA2202864F4DACE3BCD | ZIP_SHA256=22677475956810E9D299E88BA8A3EF37B8ABA2EF2B8F1AB26B99591AFC08C144 | TXT_BYTES=563 | ZIP_BYTES=411 | BASENAME=CP017_GREEN_StdOut.txt
TXT_SHA256=0003649B678978569B4A4A2C26E77C4D78D65D004C0CBBB3F40CA022E0211898 | ZIP_SHA256=9C244F3490F2ED6BE48BB54FBBE21A75AB17DEF97B141CCAF1500E5FE68A955C | TXT_BYTES=2242 | ZIP_BYTES=985 | BASENAME=CP017_PostFormat_GREEN_Run_Record.txt
TXT_SHA256=76639D06E75B335DFB1F05EB19C5B655979B7C9A352755A0AA51302EA3EB4624 | ZIP_SHA256=0F5924DBBA0E37C262E203919D21E086D1A841511B3723AA9C20E02953F78EA0 | TXT_BYTES=281 | ZIP_BYTES=370 | BASENAME=CP017_PostFormat_GREEN_StdErr.txt
TXT_SHA256=DBF25142FEE668E0CD285F26674B254CCA72AD85DE701D6FEBC856EE7A4A0285 | ZIP_SHA256=147D165CAF2A53DDDB788A90F48011C7F8CED484D790730CC7BF8427B2BF5EB1 | TXT_BYTES=563 | ZIP_BYTES=433 | BASENAME=CP017_PostFormat_GREEN_StdOut.txt
TXT_SHA256=4DBC984C57A68935F58330C05621AA75BB0C194037BB77694DAEB79FB3B1A0DB | ZIP_SHA256=C5ABAA7814101EC1A9EE3629611588A37AB88BDE30A43B24415D12D730891D7C | TXT_BYTES=1942 | ZIP_BYTES=746 | BASENAME=CP017_RED_Run_Record.txt
TXT_SHA256=B85072C4BCEB879B5886A781F8ADA3D7C28019F9AC116BDEA479B982748285C7 | ZIP_SHA256=68700D7A857FA4B3A939D4771748614EF7775E6F6CB5009246AD528688D5689A | TXT_BYTES=806 | ZIP_BYTES=488 | BASENAME=CP017_RED_StdErr.txt
TXT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=F369741A389DFACC9161D897F9FD79A051AEC611897068F3959ED158BBCD06B5 | TXT_BYTES=0 | ZIP_BYTES=138 | BASENAME=CP017_RED_StdOut.txt
TXT_SHA256=D5624C130F053962D764A5F7754F73A1265019DD2C0AC548E9CEB6FF8E9B0334 | ZIP_SHA256=9F968E8CA709FE5A49FFAF86DA1A63B644142055B8A3439BA0C8A39B2BA99268 | TXT_BYTES=1660 | ZIP_BYTES=814 | BASENAME=CP017_Rustfmt_Check_Run_Record.txt
TXT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=E2D793490C0C03C664F96200908C44BD70AC74F31DD48F4442F4910DF987944F | TXT_BYTES=0 | ZIP_BYTES=158 | BASENAME=CP017_Rustfmt_Check_StdErr.txt
TXT_SHA256=794EF6E9F70AFB3E77BA83736CD20F86015502C6079F0533CF8F80F4696EA86F | ZIP_SHA256=4EC5BC21EC56C45CA6BD15D01C384F09F59C2618B8841307D8973E330EE88C55 | TXT_BYTES=554 | ZIP_BYTES=483 | BASENAME=CP017_Rustfmt_Check_StdOut.txt
TXT_SHA256=359E31671309C59EB32E872181B3527DF6F59585DDB25573D2FA7A5F9D28F12F | ZIP_SHA256=0B0E8A2148461B6C6701511A11F921AF29547C63C339147499848015464A19E3 | TXT_BYTES=510 | ZIP_BYTES=410 | BASENAME=CP017_Rustfmt_Correction_Record.txt
TXT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=C1DA937CA56B1EE441507AEF6ECF7EF6A4C60AA131B927CB11A428CA23ED780B | TXT_BYTES=0 | ZIP_BYTES=168 | BASENAME=CP017_Rustfmt_Correction_StdErr.txt
TXT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=0CC20205C377594C63A3845E91164E3ECE2AC85CDD8438FDB138B3EDC2C47FBA | TXT_BYTES=0 | ZIP_BYTES=168 | BASENAME=CP017_Rustfmt_Correction_StdOut.txt
TXT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=01247A1F53EADFCF98CDC0FC99BB07BF4D8EFD2815E92CDAB6D324BB0909929B | TXT_BYTES=0 | ZIP_BYTES=162 | BASENAME=CP017_Rustfmt_Recheck_StdErr.txt
TXT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=B0667724A1DB90A6F58A53F5D88BE110CD787C5B1A64EE22B6B9F7D60C6A3F25 | TXT_BYTES=0 | ZIP_BYTES=162 | BASENAME=CP017_Rustfmt_Recheck_StdOut.txt
TXT_SHA256=9C017895C670DDB5927B45A62FD3F93735A4E2FEE030E6D1B708911C589091E2 | ZIP_SHA256=F4DDBD51D8CE430EA1B9D342DBE63FF14BA191F6ECE6710A5D04AD8E97AC0097 | TXT_BYTES=954 | ZIP_BYTES=630 | BASENAME=CP017_WASM_Build_Run_Record.txt
TXT_SHA256=7B76A67C9343F408F3AB0EC3CEE356A38406DDB556413372BB9DE9AB99A791A1 | ZIP_SHA256=2C310DEF2C179848BF6B0863F8AD23EAE4B74C72CA1278A1CA5B759DD0A27BE2 | TXT_BYTES=159 | ZIP_BYTES=292 | BASENAME=CP017_WASM_Build_StdErr.txt
TXT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | ZIP_SHA256=1D4C1A04772D47FA681410051F484C75F9314CB06BE778F7DDD6E56B656B57B6 | TXT_BYTES=0 | ZIP_BYTES=152 | BASENAME=CP017_WASM_Build_StdOut.txt
VERIFIED_ZIP_COUNT=25
RESTORED_CONTENT_SHA256=PASS
STATUS=PASS_PENDING_MANIFEST_SEAL

=== DAY 073 CP017 MANIFEST SEAL ===
BASELINE_HEAD=fde0f0a8b96c92f6cfb80b517396ff5512cccd13
ORIGINAL_EVIDENCE_ZIPS=25
CONTENT_MANIFEST_ZIPS=1
TOTAL_VERIFIED_ZIPS=26
PACKAGING_REPORT_SHA256=4A3F836D7C8776C2E47F255EA49F360DB841398174AFBDE2C023171F5FEAD3B3
MANIFEST_TXT_SHA256=4A3F836D7C8776C2E47F255EA49F360DB841398174AFBDE2C023171F5FEAD3B3
MANIFEST_ZIP_SHA256=A13ADC852231998A8DD5C62D01B4A8AE559FA33474B2E4A6C29232ADE8EC4073
MANIFEST_ZIP_BYTES=2520
RESTORED_MANIFEST_SHA256=PASS
SEAL_STATUS=PASS

��=== DAY 073 CP017 GIT STAGING REVIEW ===

BASELINE_HEAD=fde0f0a8b96c92f6cfb80b517396ff5512cccd13

EXPECTED_STAGED_FILES=28

=== STAGED FILES ===

Evidence/CP-017/CP017_Content_Manifest.zip

Evidence/CP-017/CP017_Evidence_Preflight_Corrected_Record.zip

Evidence/CP-017/CP017_Evidence_Preflight_Record.zip

Evidence/CP-017/CP017_Full_Regression_Run_Record.zip

Evidence/CP-017/CP017_Full_Regression_StdErr.zip

Evidence/CP-017/CP017_Full_Regression_StdOut.zip

Evidence/CP-017/CP017_GREEN_Run_Record.zip

Evidence/CP-017/CP017_GREEN_StdErr.zip

Evidence/CP-017/CP017_GREEN_StdOut.zip

Evidence/CP-017/CP017_PostFormat_GREEN_Run_Record.zip

Evidence/CP-017/CP017_PostFormat_GREEN_StdErr.zip

Evidence/CP-017/CP017_PostFormat_GREEN_StdOut.zip

Evidence/CP-017/CP017_RED_Run_Record.zip

Evidence/CP-017/CP017_RED_StdErr.zip

Evidence/CP-017/CP017_RED_StdOut.zip

Evidence/CP-017/CP017_Rustfmt_Check_Run_Record.zip

Evidence/CP-017/CP017_Rustfmt_Check_StdErr.zip

Evidence/CP-017/CP017_Rustfmt_Check_StdOut.zip

Evidence/CP-017/CP017_Rustfmt_Correction_Record.zip

Evidence/CP-017/CP017_Rustfmt_Correction_StdErr.zip

Evidence/CP-017/CP017_Rustfmt_Correction_StdOut.zip

Evidence/CP-017/CP017_Rustfmt_Recheck_StdErr.zip

Evidence/CP-017/CP017_Rustfmt_Recheck_StdOut.zip

Evidence/CP-017/CP017_WASM_Build_Run_Record.zip

Evidence/CP-017/CP017_WASM_Build_StdErr.zip

Evidence/CP-017/CP017_WASM_Build_StdOut.zip

src/lib.rs

tests/CP017_receipt_field_sequence.rs

=== STAGED WHITESPACE CHECK ===

STAGED_WHITESPACE_EXIT_CODE=0

=== ZIP GIT OBJECT IDENTITY ===

ZIP_BLOB_MATCH=PASS | CP017_Content_Manifest.zip | 96dccafb9901e645c11645b826692a3470c85ce8

ZIP_BLOB_MATCH=PASS | CP017_Evidence_Preflight_Corrected_Record.zip | de72d4ebfa5cc559c3eb33a0c7924dfa0420bd02

ZIP_BLOB_MATCH=PASS | CP017_Evidence_Preflight_Record.zip | 4c3dd6e36f7cf2051653605cafbd565d176c4c56

ZIP_BLOB_MATCH=PASS | CP017_Full_Regression_Run_Record.zip | f5663afb99e3a31357ca4b73b719b9be4724bf07

ZIP_BLOB_MATCH=PASS | CP017_Full_Regression_StdErr.zip | 0d3ff4abf532ff6e343f8505193ae8c59045e986

ZIP_BLOB_MATCH=PASS | CP017_Full_Regression_StdOut.zip | 0e017a9e9dd5e3599f12a7d534b051428aeb5c66

ZIP_BLOB_MATCH=PASS | CP017_GREEN_Run_Record.zip | 0ad51ba1c38bb3b735937b848a6e8e03c9cb9b7c

ZIP_BLOB_MATCH=PASS | CP017_GREEN_StdErr.zip | 32568b3b35e544a40c200520c24d04c50c60e540

ZIP_BLOB_MATCH=PASS | CP017_GREEN_StdOut.zip | 5a0268f57c5cebd4265408be215a0b5d1a77dd79

ZIP_BLOB_MATCH=PASS | CP017_PostFormat_GREEN_Run_Record.zip | ee647b6bc8d65ade515b62b383d3691f38c26967

ZIP_BLOB_MATCH=PASS | CP017_PostFormat_GREEN_StdErr.zip | 564a9ea66c07f942a87687e68bdcbcf93457439e

ZIP_BLOB_MATCH=PASS | CP017_PostFormat_GREEN_StdOut.zip | d3fb07a8dc10abaed97d0b0d6084b109e386fe65

ZIP_BLOB_MATCH=PASS | CP017_RED_Run_Record.zip | 8beb6dec9445d272596733db11378596578346da

ZIP_BLOB_MATCH=PASS | CP017_RED_StdErr.zip | e786ab6934995bef2cea292442519f5593170709

ZIP_BLOB_MATCH=PASS | CP017_RED_StdOut.zip | 0ae5c14226274d2668f21bcc4b08528d21f176ba

ZIP_BLOB_MATCH=PASS | CP017_Rustfmt_Check_Run_Record.zip | b94c44f0f318ebe357baccdbf770789372ac6c87

ZIP_BLOB_MATCH=PASS | CP017_Rustfmt_Check_StdErr.zip | 4bfd97cd7b775e5069e69f2f217ac0c9331bb85f

ZIP_BLOB_MATCH=PASS | CP017_Rustfmt_Check_StdOut.zip | ccf37712978eb2c4b8e44f66f27b57783c2c74d9

ZIP_BLOB_MATCH=PASS | CP017_Rustfmt_Correction_Record.zip | 683b69f45d995688552d92caec230aff4ae4b026

ZIP_BLOB_MATCH=PASS | CP017_Rustfmt_Correction_StdErr.zip | 9e0cc39feb599ddcfd7a94257d2b62e75a9669d0

ZIP_BLOB_MATCH=PASS | CP017_Rustfmt_Correction_StdOut.zip | 6c8850a03e2d7ea803d3fa92781315c196469340

ZIP_BLOB_MATCH=PASS | CP017_Rustfmt_Recheck_StdErr.zip | 9a1f8eb70856631e9c2ac4498d7372ce5f6d7841

ZIP_BLOB_MATCH=PASS | CP017_Rustfmt_Recheck_StdOut.zip | 16947582a0b13ae33fbb1b75c3c0e3b6d8319d8a

ZIP_BLOB_MATCH=PASS | CP017_WASM_Build_Run_Record.zip | 8b2ef2dbcaffb737902f29d39cba302cad3ebeb5

ZIP_BLOB_MATCH=PASS | CP017_WASM_Build_StdErr.zip | 932e8122c8fb64f419ed82a424b594d8d1efaa7e

ZIP_BLOB_MATCH=PASS | CP017_WASM_Build_StdOut.zip | e9687fb8e56bd26235322418586b02a27bbbb1a0

=== SOURCE DIFF ===

diff --git a/src/lib.rs b/src/lib.rs

index 39d0a67..2d27aef 100644

--- a/src/lib.rs

+++ b/src/lib.rs

@@ -463,6 +463,21 @@ pub fn serialize_canonical_receipt_field_line(

     Some(format!("{key}: {encoded_value}\n"))

 }

 

+/// Serializes caller-ordered canonical Receipt field lines as one in-memory string.

+///

+/// Each line is delegated to the CP016 field serializer. If any field refuses,

+/// the entire sequence refuses; no partially assembled output is returned.

+/// This is not whole-Receipt schema validation, durable output, or publication.

+pub fn serialize_canonical_receipt_field_sequence(

+    fields: &[(&str, ReceiptFieldValue<'_>)],

+) -> Option<String> {

+    let mut output = String::new();

+    for &(key, value) in fields {

+        output.push_str(&serialize_canonical_receipt_field_line(key, value)?);

+    }

+    Some(output)

+}

+

 /// Lexical form shared by field keys and machine-token values in this slice.

 /// Starts with uppercase ASCII A-Z; remaining bytes are A-Z, 0-9, or '_'.

 /// This is not an operation-specific closed-vocabulary membership check.

diff --git a/tests/CP017_receipt_field_sequence.rs b/tests/CP017_receipt_field_sequence.rs

new file mode 100644

index 0000000..dd40fb7

--- /dev/null

+++ b/tests/CP017_receipt_field_sequence.rs

@@ -0,0 +1,85 @@

+// CP017 RED test contract - Day 073 (2026-10-20)

+// Frozen anchor: W002-RCP-005 (bounded PARTIAL continuation of CP016).

+// Assemble a caller-ordered sequence of already-typed canonical field lines.

+// All-or-none in-memory formatting: one invalid field refuses the entire sequence.

+// No whole-Receipt schema, key ordering, vocabulary/uniqueness policy, filesystem

+// access, Work Order execution, authority, or publication is claimed.

+

+use data_sculptor_core::{ReceiptFieldValue, serialize_canonical_receipt_field_sequence};

+

+#[test]

+fn preserves_caller_order_without_claiming_schema_order() {

+    let fields = [

+        ("DETAIL", ReceiptFieldValue::QuotedText(" a  b ")),

+        ("RESULT", ReceiptFieldValue::MachineToken("SUCCESS")),

+        ("COUNT", ReceiptFieldValue::NonNegativeInteger(3)),

+    ];

+    assert_eq!(

+        serialize_canonical_receipt_field_sequence(&fields),

+        Some("DETAIL: \" a  b \"\nRESULT: SUCCESS\nCOUNT: 3\n".to_owned()),

+    );

+}

+

+#[test]

+fn utf8_quotes_and_empty_quoted_text_produce_exact_bytes() {

+    let fields = [

+        ("DETAIL", ReceiptFieldValue::QuotedText("caf%# ��� ��� \"go\"")),

+        ("EMPTY", ReceiptFieldValue::QuotedText("")),

+    ];

+    let output = serialize_canonical_receipt_field_sequence(&fields).unwrap();

+    let expected = "DETAIL: \"caf%# ��� ��� \"\"go\"\"\"\nEMPTY: \"\"\n";

+    assert_eq!(output.as_bytes(), expected.as_bytes());

+    assert!(!output.starts_with('\u{feff}'));

+    assert!(!output.contains('\r'));

+    assert!(!output.contains("\n\n"));

+}

+

+#[test]

+fn invalid_late_key_refuses_the_entire_sequence() {

+    let fields = [

+        ("RESULT", ReceiptFieldValue::MachineToken("SUCCESS")),

+        ("bad_key", ReceiptFieldValue::NonNegativeInteger(42)),

+    ];

+    assert_eq!(serialize_canonical_receipt_field_sequence(&fields), None);

+}

+

+#[test]

+fn invalid_late_machine_token_refuses_the_entire_sequence() {

+    let fields = [

+        ("COUNT", ReceiptFieldValue::NonNegativeInteger(1)),

+        ("RESULT", ReceiptFieldValue::MachineToken("not_canonical")),

+    ];

+    assert_eq!(serialize_canonical_receipt_field_sequence(&fields), None);

+}

+

+#[test]

+fn embedded_newline_in_late_text_refuses_the_entire_sequence() {

+    for invalid in ["before\nafter", "before\rafter", "before\r\nafter"] {

+        let fields = [

+            ("RESULT", ReceiptFieldValue::MachineToken("SUCCESS")),

+            ("DETAIL", ReceiptFieldValue::QuotedText(invalid)),

+        ];

+        assert_eq!(serialize_canonical_receipt_field_sequence(&fields), None);

+    }

+}

+

+#[test]

+fn repeated_invocations_are_byte_identical() {

+    let fields = [

+        ("RESULT", ReceiptFieldValue::MachineToken("SUCCESS")),

+        ("COUNT", ReceiptFieldValue::NonNegativeInteger(u64::MAX)),

+    ];

+    let first = serialize_canonical_receipt_field_sequence(&fields).unwrap();

+    let second = serialize_canonical_receipt_field_sequence(&fields).unwrap();

+    assert_eq!(first.as_bytes(), second.as_bytes());

+    assert_eq!(first, "RESULT: SUCCESS\nCOUNT: 18446744073709551615\n");

+}

+

+#[test]

+fn empty_sequence_is_empty_formatting_not_a_valid_receipt_claim() {

+    let fields: &[(&str, ReceiptFieldValue<'_>)] = &[];

+    assert_eq!(

+        serialize_canonical_receipt_field_sequence(fields),

+        Some(String::new()),

+    );

+}

=== STAGED SUMMARY ===

 Evidence/CP-017/CP017_Content_Manifest.zip         | Bin 0 -> 2520 bytes

 .../CP017_Evidence_Preflight_Corrected_Record.zip  | Bin 0 -> 2241 bytes

 .../CP-017/CP017_Evidence_Preflight_Record.zip     | Bin 0 -> 285 bytes

 .../CP-017/CP017_Full_Regression_Run_Record.zip    | Bin 0 -> 1436 bytes

 Evidence/CP-017/CP017_Full_Regression_StdErr.zip   | Bin 0 -> 827 bytes

 Evidence/CP-017/CP017_Full_Regression_StdOut.zip   | Bin 0 -> 1784 bytes

 Evidence/CP-017/CP017_GREEN_Run_Record.zip         | Bin 0 -> 846 bytes

 Evidence/CP-017/CP017_GREEN_StdErr.zip             | Bin 0 -> 349 bytes

 Evidence/CP-017/CP017_GREEN_StdOut.zip             | Bin 0 -> 411 bytes

 .../CP-017/CP017_PostFormat_GREEN_Run_Record.zip   | Bin 0 -> 985 bytes

 Evidence/CP-017/CP017_PostFormat_GREEN_StdErr.zip  | Bin 0 -> 370 bytes

 Evidence/CP-017/CP017_PostFormat_GREEN_StdOut.zip  | Bin 0 -> 433 bytes

 Evidence/CP-017/CP017_RED_Run_Record.zip           | Bin 0 -> 746 bytes

 Evidence/CP-017/CP017_RED_StdErr.zip               | Bin 0 -> 488 bytes

 Evidence/CP-017/CP017_RED_StdOut.zip               | Bin 0 -> 138 bytes

 Evidence/CP-017/CP017_Rustfmt_Check_Run_Record.zip | Bin 0 -> 814 bytes

 Evidence/CP-017/CP017_Rustfmt_Check_StdErr.zip     | Bin 0 -> 158 bytes

 Evidence/CP-017/CP017_Rustfmt_Check_StdOut.zip     | Bin 0 -> 483 bytes

 .../CP-017/CP017_Rustfmt_Correction_Record.zip     | Bin 0 -> 410 bytes

 .../CP-017/CP017_Rustfmt_Correction_StdErr.zip     | Bin 0 -> 168 bytes

 .../CP-017/CP017_Rustfmt_Correction_StdOut.zip     | Bin 0 -> 168 bytes

 Evidence/CP-017/CP017_Rustfmt_Recheck_StdErr.zip   | Bin 0 -> 162 bytes

 Evidence/CP-017/CP017_Rustfmt_Recheck_StdOut.zip   | Bin 0 -> 162 bytes

 Evidence/CP-017/CP017_WASM_Build_Run_Record.zip    | Bin 0 -> 630 bytes

 Evidence/CP-017/CP017_WASM_Build_StdErr.zip        | Bin 0 -> 292 bytes

 Evidence/CP-017/CP017_WASM_Build_StdOut.zip        | Bin 0 -> 152 bytes

 src/lib.rs                                         |  15 ++++

 tests/CP017_receipt_field_sequence.rs              |  85 +++++++++++++++++++++

 28 files changed, 100 insertions(+)

=== FINAL STATUS ===

A  Evidence/CP-017/CP017_Content_Manifest.zip

A  Evidence/CP-017/CP017_Evidence_Preflight_Corrected_Record.zip

A  Evidence/CP-017/CP017_Evidence_Preflight_Record.zip

A  Evidence/CP-017/CP017_Full_Regression_Run_Record.zip

A  Evidence/CP-017/CP017_Full_Regression_StdErr.zip

A  Evidence/CP-017/CP017_Full_Regression_StdOut.zip

A  Evidence/CP-017/CP017_GREEN_Run_Record.zip

A  Evidence/CP-017/CP017_GREEN_StdErr.zip

A  Evidence/CP-017/CP017_GREEN_StdOut.zip

A  Evidence/CP-017/CP017_PostFormat_GREEN_Run_Record.zip

A  Evidence/CP-017/CP017_PostFormat_GREEN_StdErr.zip

A  Evidence/CP-017/CP017_PostFormat_GREEN_StdOut.zip

A  Evidence/CP-017/CP017_RED_Run_Record.zip

A  Evidence/CP-017/CP017_RED_StdErr.zip

A  Evidence/CP-017/CP017_RED_StdOut.zip

A  Evidence/CP-017/CP017_Rustfmt_Check_Run_Record.zip

A  Evidence/CP-017/CP017_Rustfmt_Check_StdErr.zip

A  Evidence/CP-017/CP017_Rustfmt_Check_StdOut.zip

A  Evidence/CP-017/CP017_Rustfmt_Correction_Record.zip

A  Evidence/CP-017/CP017_Rustfmt_Correction_StdErr.zip

A  Evidence/CP-017/CP017_Rustfmt_Correction_StdOut.zip

A  Evidence/CP-017/CP017_Rustfmt_Recheck_StdErr.zip

A  Evidence/CP-017/CP017_Rustfmt_Recheck_StdOut.zip

A  Evidence/CP-017/CP017_WASM_Build_Run_Record.zip

A  Evidence/CP-017/CP017_WASM_Build_StdErr.zip

A  Evidence/CP-017/CP017_WASM_Build_StdOut.zip

M  src/lib.rs

A  tests/CP017_receipt_field_sequence.rs

?? Evidence/CP-016/CP016_Formatting_Amendment_Installation_Record.txt

?? Evidence/CP-016/CP016_Formatting_Candidate_Record.txt

?? Evidence/CP-016/CP016_Formatting_Candidate_StdErr.txt

?? Evidence/CP-016/CP016_Formatting_Candidate_StdOut.txt

?? Evidence/CP-016/CP016_GREEN_Installation_Record.txt

?? Evidence/CP-016/CP016_GREEN_Reconciliation_Record.txt

?? Evidence/CP-016/CP016_GREEN_Refusal_Diagnostic.txt

?? Evidence/CP-016/CP016_GREEN_StdErr.txt

?? Evidence/CP-016/CP016_GREEN_StdOut.txt

?? Evidence/CP-016/CP016_GREEN_Verification_Run_Record.txt

?? Evidence/CP-016/CP016_GREEN_Verification_StdErr.txt

?? Evidence/CP-016/CP016_GREEN_Verification_StdOut.txt

?? Evidence/CP-016/CP016_PostAmendment_Regression_Run_Record.txt

?? Evidence/CP-016/CP016_PostAmendment_Regression_StdErr.txt

?? Evidence/CP-016/CP016_PostAmendment_Regression_StdOut.txt

?? Evidence/CP-016/CP016_PostFormat_Run_Record.txt

?? Evidence/CP-016/CP016_PostFormat_StdErr.txt

?? Evidence/CP-016/CP016_PostFormat_StdOut.txt

?? Evidence/CP-016/CP016_PreCustody_Inventory.txt

?? Evidence/CP-016/CP016_RED_Run_Record.txt

?? Evidence/CP-016/CP016_RED_StdErr.txt

?? Evidence/CP-016/CP016_RED_StdOut.txt

?? Evidence/CP-016/CP016_Regression_Run_Record.txt

?? Evidence/CP-016/CP016_Regression_StdErr.txt

?? Evidence/CP-016/CP016_Regression_StdOut.txt

?? Evidence/CP-016/CP016_Rustfmt_Run_Record.txt

?? Evidence/CP-016/CP016_Rustfmt_StdErr.txt

?? Evidence/CP-016/CP016_Rustfmt_StdOut.txt

?? Evidence/CP-016/CP016_WASM_Build_Run_Record.txt

?? Evidence/CP-016/CP016_WASM_Build_StdErr.txt

?? Evidence/CP-016/CP016_WASM_Build_StdOut.txt

?? Evidence/CP-017/CP017_Content_Manifest.txt

?? Evidence/CP-017/CP017_Evidence_Preflight_Corrected_Record.txt

?? Evidence/CP-017/CP017_Evidence_Preflight_Record.txt

?? Evidence/CP-017/CP017_Full_Regression_Run_Record.txt

?? Evidence/CP-017/CP017_Full_Regression_StdErr.txt

?? Evidence/CP-017/CP017_Full_Regression_StdOut.txt

?? Evidence/CP-017/CP017_GREEN_Run_Record.txt

?? Evidence/CP-017/CP017_GREEN_StdErr.txt

?? Evidence/CP-017/CP017_GREEN_StdOut.txt

?? Evidence/CP-017/CP017_PostFormat_GREEN_Run_Record.txt

?? Evidence/CP-017/CP017_PostFormat_GREEN_StdErr.txt

?? Evidence/CP-017/CP017_PostFormat_GREEN_StdOut.txt

?? Evidence/CP-017/CP017_PreGREEN_lib.rs

?? Evidence/CP-017/CP017_PreRustfmt_Test_Original.rs

?? Evidence/CP-017/CP017_RED_Run_Record.txt

?? Evidence/CP-017/CP017_RED_StdErr.txt

?? Evidence/CP-017/CP017_RED_StdOut.txt

?? Evidence/CP-017/CP017_Rustfmt_Check_Run_Record.txt

?? Evidence/CP-017/CP017_Rustfmt_Check_StdErr.txt

?? Evidence/CP-017/CP017_Rustfmt_Check_StdOut.txt

?? Evidence/CP-017/CP017_Rustfmt_Correction_Record.txt

?? Evidence/CP-017/CP017_Rustfmt_Correction_StdErr.txt

?? Evidence/CP-017/CP017_Rustfmt_Correction_StdOut.txt

?? Evidence/CP-017/CP017_Rustfmt_Recheck_StdErr.txt

?? Evidence/CP-017/CP017_Rustfmt_Recheck_StdOut.txt

?? Evidence/CP-017/CP017_WASM_Build_Run_Record.txt

?? Evidence/CP-017/CP017_WASM_Build_StdErr.txt

?? Evidence/CP-017/CP017_WASM_Build_StdOut.txt

STAGING_VERIFICATION=PASS

GIT_COMMIT_CREATED=NO

��=== DAY 073 CP017 GIT BANKING ===

HUMAN_ACCEPTANCE=T APPROVED CP017

PARENT_HEAD=fde0f0a8b96c92f6cfb80b517396ff5512cccd13

ACCEPTED_STAGED_FILES=28

PRECOMMIT_VERIFICATION=PASS

COMMIT_EXIT_CODE=0

=== GIT COMMIT STDOUT ===

[master 339cf12] CP017: canonical Receipt field-sequence serialization and evidence

 28 files changed, 100 insertions(+)

 create mode 100644 Evidence/CP-017/CP017_Content_Manifest.zip

 create mode 100644 Evidence/CP-017/CP017_Evidence_Preflight_Corrected_Record.zip

 create mode 100644 Evidence/CP-017/CP017_Evidence_Preflight_Record.zip

 create mode 100644 Evidence/CP-017/CP017_Full_Regression_Run_Record.zip

 create mode 100644 Evidence/CP-017/CP017_Full_Regression_StdErr.zip

 create mode 100644 Evidence/CP-017/CP017_Full_Regression_StdOut.zip

 create mode 100644 Evidence/CP-017/CP017_GREEN_Run_Record.zip

 create mode 100644 Evidence/CP-017/CP017_GREEN_StdErr.zip

 create mode 100644 Evidence/CP-017/CP017_GREEN_StdOut.zip

 create mode 100644 Evidence/CP-017/CP017_PostFormat_GREEN_Run_Record.zip

 create mode 100644 Evidence/CP-017/CP017_PostFormat_GREEN_StdErr.zip

 create mode 100644 Evidence/CP-017/CP017_PostFormat_GREEN_StdOut.zip

 create mode 100644 Evidence/CP-017/CP017_RED_Run_Record.zip

 create mode 100644 Evidence/CP-017/CP017_RED_StdErr.zip

 create mode 100644 Evidence/CP-017/CP017_RED_StdOut.zip

 create mode 100644 Evidence/CP-017/CP017_Rustfmt_Check_Run_Record.zip

 create mode 100644 Evidence/CP-017/CP017_Rustfmt_Check_StdErr.zip

 create mode 100644 Evidence/CP-017/CP017_Rustfmt_Check_StdOut.zip

 create mode 100644 Evidence/CP-017/CP017_Rustfmt_Correction_Record.zip

 create mode 100644 Evidence/CP-017/CP017_Rustfmt_Correction_StdErr.zip

 create mode 100644 Evidence/CP-017/CP017_Rustfmt_Correction_StdOut.zip

 create mode 100644 Evidence/CP-017/CP017_Rustfmt_Recheck_StdErr.zip

 create mode 100644 Evidence/CP-017/CP017_Rustfmt_Recheck_StdOut.zip

 create mode 100644 Evidence/CP-017/CP017_WASM_Build_Run_Record.zip

 create mode 100644 Evidence/CP-017/CP017_WASM_Build_StdErr.zip

 create mode 100644 Evidence/CP-017/CP017_WASM_Build_StdOut.zip

 create mode 100644 tests/CP017_receipt_field_sequence.rs

=== GIT COMMIT STDERR ===

NEW_HEAD=339cf12e747738d89442ce401feeea1afcd19dc6

VERIFIED_PARENT=fde0f0a8b96c92f6cfb80b517396ff5512cccd13

COMMITTED_PATHS=28

COMMITTED_BLOB_IDENTITIES=28/28 PASS

TRACKED_TREE_AND_INDEX=CLEAN

UNTRACKED_RAW_EVIDENCE=PRESERVED

GIT_BANKING_VERIFICATION=PASS

[master 339cf12] CP017: canonical Receipt field-sequence serialization and evidence
 28 files changed, 100 insertions(+)
 create mode 100644 Evidence/CP-017/CP017_Content_Manifest.zip
 create mode 100644 Evidence/CP-017/CP017_Evidence_Preflight_Corrected_Record.zip
 create mode 100644 Evidence/CP-017/CP017_Evidence_Preflight_Record.zip
 create mode 100644 Evidence/CP-017/CP017_Full_Regression_Run_Record.zip
 create mode 100644 Evidence/CP-017/CP017_Full_Regression_StdErr.zip
 create mode 100644 Evidence/CP-017/CP017_Full_Regression_StdOut.zip
 create mode 100644 Evidence/CP-017/CP017_GREEN_Run_Record.zip
 create mode 100644 Evidence/CP-017/CP017_GREEN_StdErr.zip
 create mode 100644 Evidence/CP-017/CP017_GREEN_StdOut.zip
 create mode 100644 Evidence/CP-017/CP017_PostFormat_GREEN_Run_Record.zip
 create mode 100644 Evidence/CP-017/CP017_PostFormat_GREEN_StdErr.zip
 create mode 100644 Evidence/CP-017/CP017_PostFormat_GREEN_StdOut.zip
 create mode 100644 Evidence/CP-017/CP017_RED_Run_Record.zip
 create mode 100644 Evidence/CP-017/CP017_RED_StdErr.zip
 create mode 100644 Evidence/CP-017/CP017_RED_StdOut.zip
 create mode 100644 Evidence/CP-017/CP017_Rustfmt_Check_Run_Record.zip
 create mode 100644 Evidence/CP-017/CP017_Rustfmt_Check_StdErr.zip
 create mode 100644 Evidence/CP-017/CP017_Rustfmt_Check_StdOut.zip
 create mode 100644 Evidence/CP-017/CP017_Rustfmt_Correction_Record.zip
 create mode 100644 Evidence/CP-017/CP017_Rustfmt_Correction_StdErr.zip
 create mode 100644 Evidence/CP-017/CP017_Rustfmt_Correction_StdOut.zip
 create mode 100644 Evidence/CP-017/CP017_Rustfmt_Recheck_StdErr.zip
 create mode 100644 Evidence/CP-017/CP017_Rustfmt_Recheck_StdOut.zip
 create mode 100644 Evidence/CP-017/CP017_WASM_Build_Run_Record.zip
 create mode 100644 Evidence/CP-017/CP017_WASM_Build_StdErr.zip
 create mode 100644 Evidence/CP-017/CP017_WASM_Build_StdOut.zip
 create mode 100644 tests/CP017_receipt_field_sequence.rs

DAY 073 / CP017 / GREEN SOURCE EDIT VERIFICATION
RESULT=PASS_STATIC_EDIT
SOURCE_UPLOADED=lib(2).rs
SOURCE_BYTES=15525
SOURCE_SHA256=1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911
OUTPUT=lib.rs
OUTPUT_BYTES=16145
OUTPUT_SHA256=903378F90A61E141EE008D60758F0241CAD67A5737DE301F4A1D1FBB61F9F3AE
INSERTION=before receipt identifier lexical-form comment
INSERTION_OCCURRENCES=1
INSERTION_BYTES=620
ORIGINAL_REMAINDER_BYTE_IDENTICAL=YES
RED_TEST_SHA256=9AA7D93804733392EFD81C627684FDCD538A0CDA0A5A18D9A819791DB616EFC1
CP016_FUNCTION_UNMODIFIED=YES
BOM=ABSENT
LINE_ENDINGS=LF
GREEN_TEST_STATUS=NOT_EXECUTED_ON_USER_REPOSITORY
NOTE=Copy replacement only after comparing project src/lib.rs SHA-256 to SOURCE_SHA256.

CP008 GIT BANKING - DAY 066
Previous HEAD: 3c512df519f3a2431b363e4c57dc234c02378124
Staged files: 18
Source/test whitespace: PASS
Archival whitespace exceptions: documented separately
Human approval: GRANTED

GIT COMMIT OUTPUT:
[master 346733a] WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates
 18 files changed, 645 insertions(+), 2 deletions(-)
 create mode 100644 Evidence/CP-008/CP008_Final_Source_Review.txt
 create mode 100644 Evidence/CP-008/CP008_Final_Staging_Review.txt
 create mode 100644 Evidence/CP-008/CP008_Full_Regression_Test_Output.txt
 create mode 100644 Evidence/CP-008/CP008_GREEN_Test_Output.txt
 create mode 100644 Evidence/CP-008/CP008_Git_Whitespace_Check.txt
 create mode 100644 Evidence/CP-008/CP008_Hash_Inventory.txt
 create mode 100644 Evidence/CP-008/CP008_Hash_Inventory_Verification.txt
 create mode 100644 Evidence/CP-008/CP008_Post_Format_Test_Output.txt
 create mode 100644 Evidence/CP-008/CP008_Precommit_Git_Review.txt
 create mode 100644 Evidence/CP-008/CP008_RED_Test_Output.txt
 create mode 100644 Evidence/CP-008/CP008_Rustfmt_Check_Output.txt
 create mode 100644 Evidence/CP-008/CP008_Rustfmt_Output.txt
 create mode 100644 Evidence/CP-008/CP008_Staged_Whitespace_Diagnostic.txt
 create mode 100644 Evidence/CP-008/CP008_WASM_Build_Output.txt
 create mode 100644 Evidence/CP-008/CP008_Whitespace_Exception_Review.txt
 create mode 100644 Evidence/Day066_Preflight_Native_Test_Output.txt
 create mode 100644 tests/CP008_source_eligibility.rs
Git commit exit code: 0
New HEAD: 346733a962192320e0d56271add15a47b6037b6b
Remaining working-tree entries: 0

CP009 GIT BANKING - DAY 066
Previous HEAD: 346733a962192320e0d56271add15a47b6037b6b
Approved staged files: 15
Source/test hashes: VERIFIED
Staged whitespace: PASS
Human approval: GRANTED

GIT COMMIT OUTPUT:
[master dc6ee5d] WASM-002 CP-009: match exact CSV SOURCE names in root snapshots
 15 files changed, 648 insertions(+)
 create mode 100644 Evidence/CP-009/CP009_Baseline_Test_Output.txt
 create mode 100644 Evidence/CP-009/CP009_Final_Staging_Review.txt
 create mode 100644 Evidence/CP-009/CP009_Full_Regression_Test_Output.txt
 create mode 100644 Evidence/CP-009/CP009_GREEN_Test_Output.txt
 create mode 100644 Evidence/CP-009/CP009_Git_Whitespace_Check.txt
 create mode 100644 Evidence/CP-009/CP009_Hash_Inventory.txt
 create mode 100644 Evidence/CP-009/CP009_Hash_Inventory_Verification.txt
 create mode 100644 Evidence/CP-009/CP009_Post_Format_Test_Output.txt
 create mode 100644 Evidence/CP-009/CP009_Precommit_Git_Review.txt
 create mode 100644 Evidence/CP-009/CP009_RED_Test_Output.txt
 create mode 100644 Evidence/CP-009/CP009_Rustfmt_Check_Output.txt
 create mode 100644 Evidence/CP-009/CP009_Rustfmt_Output.txt
 create mode 100644 Evidence/CP-009/CP009_WASM_Build_Output.txt
 create mode 100644 tests/CP009_exact_root_snapshot.rs
Git commit exit code: 0
New HEAD: dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8
Parent HEAD: 346733a962192320e0d56271add15a47b6037b6b
Committed files: 15
Remaining working-tree entries: 0

CP010 GIT BANKING - DAY 066
Previous HEAD: dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8
Human acceptance: GRANTED
Approved staged files: 28
Source/test SHA-256: VERIFIED
Staged whitespace: PASS
Native regression: 40/40 PASS
WASM build: PASS
Commit message: WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates
Day 066 status: OPEN

=== GIT COMMIT OUTPUT ===
[master b7c515f] WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates
 28 files changed, 1483 insertions(+)
 create mode 100644 Evidence/CP-010/.gitattributes
 create mode 100644 Evidence/CP-010/CP010_Closing_Git_Review.txt
 create mode 100644 Evidence/CP-010/CP010_Final_Staging_Review.txt
 create mode 100644 Evidence/CP-010/CP010_Full_Regression_Test_Output.txt
 create mode 100644 Evidence/CP-010/CP010_GREEN_Implementation_Review.txt
 create mode 100644 Evidence/CP-010/CP010_GREEN_Test_Output.txt
 create mode 100644 Evidence/CP-010/CP010_Hash_Inventory.txt
 create mode 100644 Evidence/CP-010/CP010_Hash_Inventory_Corrected.txt
 create mode 100644 Evidence/CP-010/CP010_Hash_Inventory_Verification.txt
 create mode 100644 Evidence/CP-010/CP010_Post_Format_Check_Output.txt
 create mode 100644 Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt
 create mode 100644 Evidence/CP-010/CP010_Precommit_Git_Review.txt
 create mode 100644 Evidence/CP-010/CP010_RED_Test_Output.txt
 create mode 100644 Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt
 create mode 100644 Evidence/CP-010/CP010_Rust_Toolchain_Verification.txt
 create mode 100644 Evidence/CP-010/CP010_Rustfmt_Application_Output.txt
 create mode 100644 Evidence/CP-010/CP010_Rustfmt_Check_Output.txt
 create mode 100644 Evidence/CP-010/CP010_Scope_Lock.txt
 create mode 100644 Evidence/CP-010/CP010_Staged_Whitespace_Diagnostic.txt
 create mode 100644 Evidence/CP-010/CP010_Starting_State.txt
 create mode 100644 Evidence/CP-010/CP010_Supplementary_Hash_Inventory.txt
 create mode 100644 Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt
 create mode 100644 Evidence/CP-010/CP010_Test_PreFormat_Snapshot.txt
 create mode 100644 Evidence/CP-010/CP010_WASM_Build_Output.txt
 create mode 100644 Evidence/CP-010/CP010_Whitespace_Exception_Review.txt
 create mode 100644 Evidence/CP-010/CP010_Whitespace_Followup_Verification.txt
 create mode 100644 tests/CP010_cvt_filename_candidate.rs
GIT_COMMIT_EXIT_CODE=0
NEW_HEAD=b7c515faa9bd000369d7656e09437310261290ae
PARENT_HEAD=dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8
COMMITTED_FILES=28
WORKING_TREE_CLEAN=True
DAY_066_STATUS=OPEN
CP010_STATUS=BANKED

[master e84ae5b] CP011: canonical CVT-to-SCR candidate identity
 27 files changed, 1208 insertions(+)
 create mode 100644 Evidence/CP-011/.gitattributes
 create mode 100644 Evidence/CP-011/CP011_Closing_Git_Review.txt
 create mode 100644 Evidence/CP-011/CP011_Final_Staging_Review.txt
 create mode 100644 Evidence/CP-011/CP011_Full_Regression_Test_Output.txt
 create mode 100644 Evidence/CP-011/CP011_GREEN_Source_Change.txt
 create mode 100644 Evidence/CP-011/CP011_GREEN_Test_Output.txt
 create mode 100644 Evidence/CP-011/CP011_Hash_Inventory.txt
 create mode 100644 Evidence/CP-011/CP011_Hash_Inventory_Verification.txt
 create mode 100644 Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt
 create mode 100644 Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt
 create mode 100644 Evidence/CP-011/CP011_Precommit_Git_Review.txt
 create mode 100644 Evidence/CP-011/CP011_Preformat_Test_Snapshot.txt
 create mode 100644 Evidence/CP-011/CP011_RED_Test_Output.txt
 create mode 100644 Evidence/CP-011/CP011_Rustfmt_Apply_Output.txt
 create mode 100644 Evidence/CP-011/CP011_Rustfmt_Check_Output.txt
 create mode 100644 Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt
 create mode 100644 Evidence/CP-011/CP011_Scope_Lock.txt
 create mode 100644 Evidence/CP-011/CP011_Staged_Whitespace_Diagnostic.txt
 create mode 100644 Evidence/CP-011/CP011_Staging_Recovery_Review.txt
 create mode 100644 Evidence/CP-011/CP011_Starting_State.txt
 create mode 100644 Evidence/CP-011/CP011_Supplementary_Hash_Inventory.txt
 create mode 100644 Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt
 create mode 100644 Evidence/CP-011/CP011_Supplementary_Staging_Review.txt
 create mode 100644 Evidence/CP-011/CP011_WASM_Build_Output.txt
 create mode 100644 Evidence/CP-011/CP011_Whitespace_Exception_Review.txt
 create mode 100644 tests/CP011_cvt_scr_candidate_identity.rs

=== CP011 GIT BANKING VERIFICATION ===
CHECKPOINT=CP011
DAY=066
HUMAN_ACCEPTANCE=APPROVED
GIT_BRANCH=master
HEAD_BEFORE=b7c515faa9bd000369d7656e09437310261290ae
HEAD_AFTER=e84ae5baeee05f9d5d30284c65b86eebba3c0f6a
PARENT_CORRECT=True
COMMIT_SUBJECT=CP011: canonical CVT-to-SCR candidate identity
COMMIT_SUBJECT_CORRECT=True
COMMIT_EXIT_CODE=0
COMMITTED_FILES=27
COMMIT_PAYLOAD_CORRECT=True
WORKING_TREE_CLEAN=True
BANKING_PASS=True
NATIVE_TESTS=46_PASS_0_FAIL
CANONICAL_WASM_BUILD=PASS
RUSTFMT=PASS
SHA256_VERIFICATION=36_PASS_0_ISSUES
DAY_066_STATUS=OPEN

=== COMMITTED FILES ===
Evidence/CP-011/.gitattributes
Evidence/CP-011/CP011_Closing_Git_Review.txt
Evidence/CP-011/CP011_Final_Staging_Review.txt
Evidence/CP-011/CP011_Full_Regression_Test_Output.txt
Evidence/CP-011/CP011_GREEN_Source_Change.txt
Evidence/CP-011/CP011_GREEN_Test_Output.txt
Evidence/CP-011/CP011_Hash_Inventory.txt
Evidence/CP-011/CP011_Hash_Inventory_Verification.txt
Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt
Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt
Evidence/CP-011/CP011_Precommit_Git_Review.txt
Evidence/CP-011/CP011_Preformat_Test_Snapshot.txt
Evidence/CP-011/CP011_RED_Test_Output.txt
Evidence/CP-011/CP011_Rustfmt_Apply_Output.txt
Evidence/CP-011/CP011_Rustfmt_Check_Output.txt
Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt
Evidence/CP-011/CP011_Scope_Lock.txt
Evidence/CP-011/CP011_Staged_Whitespace_Diagnostic.txt
Evidence/CP-011/CP011_Staging_Recovery_Review.txt
Evidence/CP-011/CP011_Starting_State.txt
Evidence/CP-011/CP011_Supplementary_Hash_Inventory.txt
Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt
Evidence/CP-011/CP011_Supplementary_Staging_Review.txt
Evidence/CP-011/CP011_WASM_Build_Output.txt
Evidence/CP-011/CP011_Whitespace_Exception_Review.txt
src/lib.rs
tests/CP011_cvt_scr_candidate_identity.rs

[master efca043] CP012: canonical SCR filename candidate recognition
 28 files changed, 1370 insertions(+)
 create mode 100644 Evidence/CP-012/.gitattributes
 create mode 100644 Evidence/CP-012/CP012_Closing_Git_Review.txt
 create mode 100644 Evidence/CP-012/CP012_EOF_Whitespace_Amendment.txt
 create mode 100644 Evidence/CP-012/CP012_Final_Rustfmt_Check.txt
 create mode 100644 Evidence/CP-012/CP012_Final_Staging_Review.txt
 create mode 100644 Evidence/CP-012/CP012_Full_Regression_Test_Output.txt
 create mode 100644 Evidence/CP-012/CP012_GREEN2_Test_Output.txt
 create mode 100644 Evidence/CP-012/CP012_GREEN_Correction_Review.txt
 create mode 100644 Evidence/CP-012/CP012_GREEN_Failure_Triage.txt
 create mode 100644 Evidence/CP-012/CP012_GREEN_Rustfmt_Precheck.txt
 create mode 100644 Evidence/CP-012/CP012_GREEN_Source_Change.txt
 create mode 100644 Evidence/CP-012/CP012_GREEN_Test_Output.txt
 create mode 100644 Evidence/CP-012/CP012_Hash_Inventory.txt
 create mode 100644 Evidence/CP-012/CP012_Hash_Inventory_Verification.txt
 create mode 100644 Evidence/CP-012/CP012_Post_Staging_Hash_Amendment.txt
 create mode 100644 Evidence/CP-012/CP012_Post_Staging_Hash_Verification.txt
 create mode 100644 Evidence/CP-012/CP012_Precommit_Git_Review.txt
 create mode 100644 Evidence/CP-012/CP012_RED_Test_Output.txt
 create mode 100644 Evidence/CP-012/CP012_Scope_Lock.txt
 create mode 100644 Evidence/CP-012/CP012_Staged_Whitespace_Review.txt
 create mode 100644 Evidence/CP-012/CP012_Starting_State.txt
 create mode 100644 Evidence/CP-012/CP012_Supplementary_Hash_Inventory.txt
 create mode 100644 Evidence/CP-012/CP012_Supplementary_Hash_Verification.txt
 create mode 100644 Evidence/CP-012/CP012_Test_Authoring_Format_Output.txt
 create mode 100644 Evidence/CP-012/CP012_WASM_Build_Output.txt
 create mode 100644 Evidence/CP-012/CP012_Whitespace_Exceptions_Review.txt
 create mode 100644 tests/CP012_scr_filename_candidate.rs

=== CP012 GIT BANKING VERIFICATION ===
PREVIOUS_HEAD=e84ae5baeee05f9d5d30284c65b86eebba3c0f6a
NEW_HEAD=efca04392940e398020a5c06b9ee50296c8a1fdd
COMMIT_PARENT=e84ae5baeee05f9d5d30284c65b86eebba3c0f6a
COMMIT_SUBJECT=CP012: canonical SCR filename candidate recognition
BRANCH=master
COMMIT_EXIT_CODE=0
COMMITTED_FILES=28
COMMITTED_MEMBERSHIP_PASS=True
COMMIT_IDENTITY_PASS=True
COMMITTED_WHITESPACE_EXIT_CODE=0
COMMITTED_WHITESPACE_PASS=True
CRITICAL_HASHES_STABLE=True
WORKING_TREE_CLEAN=True
GIT_BANKING_PASS=True
CP012_HUMAN_ACCEPTANCE=APPROVED
W002-STOR-023.1=PARTIALLY_IMPLEMENTED
NATIVE_REGRESSION=52_PASS_0_FAIL
CANONICAL_WASM_BUILD=PASS
FINAL_RUSTFMT=PASS
DAY_066_STATUS=OPEN
END_OF_BANKING_VERIFICATION

WASM-002 CP013 GIT BANKING RECEIPT
Timestamp: 2026-10-13 22:01:42 -03:00
Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Requested message: CP013: explicit SCR-to-RCP filename candidate derivation
HUMAN_ACCEPTANCE=APPROVED_BY_T
PRECOMMIT_STAGED_FILES=42
PRECOMMIT_BLOBS_VERIFIED=42
PRECOMMIT_WHITESPACE=PASS
DAY_066=OPEN

=== GIT COMMIT OUTPUT ===
[master 005a38e] CP013: explicit SCR-to-RCP filename candidate derivation
 42 files changed, 5859 insertions(+)
 create mode 100644 Evidence/CP-013/.gitattributes
 create mode 100644 Evidence/CP-013/CP013_Approved_Scope_Lock.txt
 create mode 100644 Evidence/CP-013/CP013_Closing_Git_Review.txt
 create mode 100644 Evidence/CP-013/CP013_Closing_Hash_Amendment.txt
 create mode 100644 Evidence/CP-013/CP013_Closing_Hash_Verification.txt
 create mode 100644 Evidence/CP-013/CP013_Final_Evidence_Staging_Review.txt
 create mode 100644 Evidence/CP-013/CP013_Final_Staging_Verification.txt
 create mode 100644 Evidence/CP-013/CP013_Full_Regression_Test_Output.txt
 create mode 100644 Evidence/CP-013/CP013_Full_Regression_Verification.txt
 create mode 100644 Evidence/CP-013/CP013_GREEN_Implementation_Report.txt
 create mode 100644 Evidence/CP-013/CP013_GREEN_Test_Output.txt
 create mode 100644 Evidence/CP-013/CP013_GREEN_Test_Verification.txt
 create mode 100644 Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt
 create mode 100644 Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt
 create mode 100644 Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt
 create mode 100644 Evidence/CP-013/CP013_Hash_Inventory.txt
 create mode 100644 Evidence/CP-013/CP013_Hash_Inventory_Verification.txt
 create mode 100644 Evidence/CP-013/CP013_Opening_Git_Preflight.txt
 create mode 100644 Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt
 create mode 100644 Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt
 create mode 100644 Evidence/CP-013/CP013_Precedent_Test_Inspection.txt
 create mode 100644 Evidence/CP-013/CP013_Precommit_Git_Review.txt
 create mode 100644 Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt
 create mode 100644 Evidence/CP-013/CP013_RED_Test_Output.txt
 create mode 100644 Evidence/CP-013/CP013_RED_Test_Verification.txt
 create mode 100644 Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt
 create mode 100644 Evidence/CP-013/CP013_Rustfmt_Check_Output.txt
 create mode 100644 Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt
 create mode 100644 Evidence/CP-013/CP013_Source_Inspection.txt
 create mode 100644 Evidence/CP-013/CP013_Staged_Whitespace_Recovery_Output.txt
 create mode 100644 Evidence/CP-013/CP013_Staged_Whitespace_Recovery_Report.txt
 create mode 100644 Evidence/CP-013/CP013_Staging_Action_Report.txt
 create mode 100644 Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt
 create mode 100644 Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt
 create mode 100644 Evidence/CP-013/CP013_Test_Authoring_Report.txt
 create mode 100644 Evidence/CP-013/CP013_Test_Formatting_Report.txt
 create mode 100644 Evidence/CP-013/CP013_Test_Rustfmt_Output.txt
 create mode 100644 Evidence/CP-013/CP013_WASM_Build_Output.txt
 create mode 100644 Evidence/CP-013/CP013_WASM_Build_Verification.txt
 create mode 100644 Evidence/CP-013/CP013_Whitespace_Exception_Review.txt
 create mode 100644 tests/CP013_scr_rcp_candidate_identity.rs

=== POST-COMMIT VERIFICATION ===
COMMIT_EXIT=0
NEW_HEAD=005a38ef5e876847c4c08901c18da9c18565fd6b
PARENT_HEAD=efca04392940e398020a5c06b9ee50296c8a1fdd
COMMIT_SUBJECT=CP013: explicit SCR-to-RCP filename candidate derivation
COMMITTED_FILES=42
COMMITTED_BLOBS_VERIFIED=42
WORKING_TREE_CLEAN=True
GIT_INDEX_CLEAN=True
DAY_066=OPEN

RESULT: PASS - CP013 BANKED

WASM-002 CP004 SHA-256 INVENTORY
Git baseline: 2d06f6259de93f5beaa8eb15f8f22f171127a10e
Scope: Canonical immutable filename envelope
Inventory entries: 19
Inventory excludes itself and later verification reports.
All sizes are exact file bytes.

PATH | BYTES | SHA256
.gitattributes | 109 | 978CF143947177C92114C50A5C68F24B6E9818597AA64788406884E116EC5A0B
.gitignore | 8 | 44C92E3A70AD3307B7056871C2BDB096D8BFA9373F5BF06A79BB6324A20FF2FB
Cargo.lock | 162 | BDB2BCD1BA65C0FFDABC7960B279978411113895E0CDAD12F4E2604E916BD9D8
Cargo.toml | 89 | 6FAD50B667CBD473B2E6A8E7FE4E33BD788B4CF617505B9A08B88E9B684EFF25
Evidence/CP-004/CP004_Format_Output.txt | 368 | 60F6CD06DE2F6D2A36B723A0EC535743FC67B187222C7A0FB22348CD0E680B6A
Evidence/CP-004/CP004_GREEN_Source_Change.txt | 1989 | AD437F1E0AF2BD340819B114D5213117208207DD5B1E28F4F707697445210840
Evidence/CP-004/CP004_GREEN_Test_Output.txt | 1963 | B18E53FE6A2D04BF044000DB749E5F3188F9D588823A270AFD872F19373861BC
Evidence/CP-004/CP004_Post_Format_Diff_Review.txt | 4696 | DC3520A66DBBA8924F9F377205F2F05E4472D58F9D39B41A33A5110FC85F1D27
Evidence/CP-004/CP004_Post_Format_Test_Output.txt | 1969 | B813894113FD78968A31592D726F275E30BE9D672E3104FAEE23068A544AC902
Evidence/CP-004/CP004_RED_Test_Change.txt | 2266 | 7928D795FF3E2A163E5256243C8237FAF856DA857ADE0DFCFCA3999FD07153DC
Evidence/CP-004/CP004_RED_Test_Correction.txt | 402 | 8B38C32A6773B2F5654D267292BBD4C3465CCC425B81834241C489891F3CB0EF
Evidence/CP-004/CP004_RED_Test_Output.txt | 634 | FD4593DA5C2CBDB8C3ADA0EAFC9BBCE55A7299297D86839EA792BEE4E1AACEB4
Evidence/CP-004/CP004_Starting_State.txt | 379 | 7C05B1EC015C49D6984BAE036B39A477376088F4C50935C4F69B8065483E7B17
Evidence/CP-004/CP004_WASM_Build_Output.txt | 362 | E6CE813085AEFED0E3D1403F53F84E4E8CCDF3F86920476A4C4A6E3FD099FF12
rust-toolchain.toml | 92 | D02F2301203B36F8C98CF05DD8716E38064154631D7CC0D6D1A0313CC4098AF0
src/lib.rs | 4071 | EDCBDE36A28EE162A6216C22DA21200A97A3B4F7548C9C48EC028A0810C54E3D
tests/artifact_class_disposition.rs | 1834 | B5956A618DA5F70495EF6E3CED1E6DC5B1A4A0EA283B2AE2D2FB97F3803002C9
tests/artifact_filename_envelope.rs | 1901 | D407CA8874064A304EB381ED719B693EC6851088ECB20E654D099A96DCB3020A
tests/artifact_namespace.rs | 2656 | C908B49BB1B4C475A04901C3A70FCF45585079616DE869082D6EC0B357FD1249

CP004 INDEPENDENT SHA-256 VERIFICATION
Git HEAD: 2d06f6259de93f5beaa8eb15f8f22f171127a10e
Inventory SHA256: A6C80D9AD23DF03D65605DA135D8C062412FE3DCF0392C8A537561E904382CC1
Expected entries: 19

RESULTS
PASS | .gitattributes | 109 | 978CF143947177C92114C50A5C68F24B6E9818597AA64788406884E116EC5A0B
PASS | .gitignore | 8 | 44C92E3A70AD3307B7056871C2BDB096D8BFA9373F5BF06A79BB6324A20FF2FB
PASS | Cargo.lock | 162 | BDB2BCD1BA65C0FFDABC7960B279978411113895E0CDAD12F4E2604E916BD9D8
PASS | Cargo.toml | 89 | 6FAD50B667CBD473B2E6A8E7FE4E33BD788B4CF617505B9A08B88E9B684EFF25
PASS | Evidence/CP-004/CP004_Format_Output.txt | 368 | 60F6CD06DE2F6D2A36B723A0EC535743FC67B187222C7A0FB22348CD0E680B6A
PASS | Evidence/CP-004/CP004_GREEN_Source_Change.txt | 1989 | AD437F1E0AF2BD340819B114D5213117208207DD5B1E28F4F707697445210840
PASS | Evidence/CP-004/CP004_GREEN_Test_Output.txt | 1963 | B18E53FE6A2D04BF044000DB749E5F3188F9D588823A270AFD872F19373861BC
PASS | Evidence/CP-004/CP004_Post_Format_Diff_Review.txt | 4696 | DC3520A66DBBA8924F9F377205F2F05E4472D58F9D39B41A33A5110FC85F1D27
PASS | Evidence/CP-004/CP004_Post_Format_Test_Output.txt | 1969 | B813894113FD78968A31592D726F275E30BE9D672E3104FAEE23068A544AC902
PASS | Evidence/CP-004/CP004_RED_Test_Change.txt | 2266 | 7928D795FF3E2A163E5256243C8237FAF856DA857ADE0DFCFCA3999FD07153DC
PASS | Evidence/CP-004/CP004_RED_Test_Correction.txt | 402 | 8B38C32A6773B2F5654D267292BBD4C3465CCC425B81834241C489891F3CB0EF
PASS | Evidence/CP-004/CP004_RED_Test_Output.txt | 634 | FD4593DA5C2CBDB8C3ADA0EAFC9BBCE55A7299297D86839EA792BEE4E1AACEB4
PASS | Evidence/CP-004/CP004_Starting_State.txt | 379 | 7C05B1EC015C49D6984BAE036B39A477376088F4C50935C4F69B8065483E7B17
PASS | Evidence/CP-004/CP004_WASM_Build_Output.txt | 362 | E6CE813085AEFED0E3D1403F53F84E4E8CCDF3F86920476A4C4A6E3FD099FF12
PASS | rust-toolchain.toml | 92 | D02F2301203B36F8C98CF05DD8716E38064154631D7CC0D6D1A0313CC4098AF0
PASS | src/lib.rs | 4071 | EDCBDE36A28EE162A6216C22DA21200A97A3B4F7548C9C48EC028A0810C54E3D
PASS | tests/artifact_class_disposition.rs | 1834 | B5956A618DA5F70495EF6E3CED1E6DC5B1A4A0EA283B2AE2D2FB97F3803002C9
PASS | tests/artifact_filename_envelope.rs | 1901 | D407CA8874064A304EB381ED719B693EC6851088ECB20E654D099A96DCB3020A
PASS | tests/artifact_namespace.rs | 2656 | C908B49BB1B4C475A04901C3A70FCF45585079616DE869082D6EC0B357FD1249

Files verified: 19 / 19
Issues: 0
RESULT: PASS

CP004 PRECOMMIT GIT REVIEW
Git HEAD: 2d06f6259de93f5beaa8eb15f8f22f171127a10e
Staged files: 0
CP004 evidence files before review: 12
Source SHA256: EDCBDE36A28EE162A6216C22DA21200A97A3B4F7548C9C48EC028A0810C54E3D
Test SHA256: D407CA8874064A304EB381ED719B693EC6851088ECB20E654D099A96DCB3020A
Git whitespace exit code: 0

=== PENDING CHANGES ===
 M src/lib.rs
?? Evidence/CP-004/CP004_Format_Output.txt
?? Evidence/CP-004/CP004_GREEN_Source_Change.txt
?? Evidence/CP-004/CP004_GREEN_Test_Output.txt
?? Evidence/CP-004/CP004_Hash_Inventory.txt
?? Evidence/CP-004/CP004_Hash_Inventory_Verification.txt
?? Evidence/CP-004/CP004_Post_Format_Diff_Review.txt
?? Evidence/CP-004/CP004_Post_Format_Test_Output.txt
?? Evidence/CP-004/CP004_RED_Test_Change.txt
?? Evidence/CP-004/CP004_RED_Test_Correction.txt
?? Evidence/CP-004/CP004_RED_Test_Output.txt
?? Evidence/CP-004/CP004_Starting_State.txt
?? Evidence/CP-004/CP004_WASM_Build_Output.txt
?? tests/artifact_filename_envelope.rs

=== SOURCE DIFF ===
diff --git a/src/lib.rs b/src/lib.rs
index 1c892af..d1ea916 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -73,3 +73,64 @@ pub fn classify_artifact_class_token(filename: &str) -> ArtifactClassDisposition
         _ => ArtifactClassDisposition::Unallocated(class),
     }
 }
+
+/// Checks the lexical envelope of an ordinary immutable artifact filename.
+///
+/// This does not validate the UTC calendar date, artifact-specific extension,
+/// registered class, governed contents, provenance, or authority.
+pub fn is_canonical_immutable_artifact_filename(filename: &str) -> bool {
+    let Some(rest) = filename.strip_prefix("__DS__") else {
+        return false;
+    };
+
+    let Some((class, rest)) = rest.split_once("__") else {
+        return false;
+    };
+
+    if class.len() != 3 || !class.bytes().all(|byte| byte.is_ascii_uppercase()) {
+        return false;
+    }
+
+    let Some((utc, rest)) = rest.split_once("__") else {
+        return false;
+    };
+
+    let timestamp = utc.as_bytes();
+
+    if timestamp.len() != 19
+        || timestamp[8] != b'T'
+        || timestamp[18] != b'Z'
+        || !timestamp
+            .iter()
+            .enumerate()
+            .all(|(i, byte)| matches!(i, 8 | 18) || byte.is_ascii_digit())
+    {
+        return false;
+    }
+
+    let Some((uuid, extension)) = rest.split_once('.') else {
+        return false;
+    };
+
+    if extension.is_empty() {
+        return false;
+    }
+
+    let bytes = uuid.as_bytes();
+
+    if bytes.len() != 36 {
+        return false;
+    }
+
+    for (i, byte) in bytes.iter().enumerate() {
+        if matches!(i, 8 | 13 | 18 | 23) {
+            if *byte != b'-' {
+                return false;
+            }
+        } else if !byte.is_ascii_hexdigit() || byte.is_ascii_uppercase() {
+            return false;
+        }
+    }
+
+    bytes[14] == b'4' && matches!(bytes[19], b'8' | b'9' | b'a' | b'b')
+}

RESULT: REVIEW READY

WASM-002 CP005 SHA-256 INVENTORY
Git baseline: 12c02a0f2ff51fae72599adc09332f50fed62ce8
Scope: Gregorian UTC timestamp validation
Inventory entries: 19
Inventory excludes itself and later verification reports.
All sizes are exact file bytes.

PATH | BYTES | SHA256
.gitattributes | 109 | 978CF143947177C92114C50A5C68F24B6E9818597AA64788406884E116EC5A0B
.gitignore | 8 | 44C92E3A70AD3307B7056871C2BDB096D8BFA9373F5BF06A79BB6324A20FF2FB
Cargo.lock | 162 | BDB2BCD1BA65C0FFDABC7960B279978411113895E0CDAD12F4E2604E916BD9D8
Cargo.toml | 89 | 6FAD50B667CBD473B2E6A8E7FE4E33BD788B4CF617505B9A08B88E9B684EFF25
Evidence/CP-005/CP005_Format_Output.txt | 374 | A84075ECEA7D301EB0DDCE0A032D23679E3C7C83800C0E72E248649AF33B3EAB
Evidence/CP-005/CP005_GREEN_Source_Change.txt | 2203 | 2E6320A9C7DF6AD7BEFAACF1EA6954DC0C217D6B612C20213E346775CF3BB8A6
Evidence/CP-005/CP005_GREEN_Test_Output.txt | 2365 | 407DB6F584154C9935FCA75DFA882C7325950FB6D562CBC79642DB4B9715EB36
Evidence/CP-005/CP005_Post_Format_Diff_Review.txt | 2416 | 61C005FC2AB63C6360FC2E4A942A44434C4CE3EA517502750AB4292DCAD019AA
Evidence/CP-005/CP005_Post_Format_Test_Output.txt | 2396 | 7C1178BAF84C463DCB9C3F1F94AF2CAAD45DFD3ED19FB88A35E44E683A670B2B
Evidence/CP-005/CP005_RED_Test_Change.txt | 2450 | B56EB1D1C68FE337716306E4ED75007BD3511BCE7C2DF0A4E0C5CB9EE673B9FD
Evidence/CP-005/CP005_RED_Test_Output.txt | 3095 | C6D0AD1AF53C7EA2CA63634A38A82648A737777F610F5FC3D2D2BC3A067ABB2F
Evidence/CP-005/CP005_Starting_State.txt | 386 | A1CD2BE362838BA4C516A9724952F97184C93F0BDCAD45F68009B60DDA870B64
Evidence/CP-005/CP005_WASM_Build_Output.txt | 400 | 5715F5CE45F41DABF8C8CDBFAC219397226F9965627BFC7102B664F75597BF58
rust-toolchain.toml | 92 | D02F2301203B36F8C98CF05DD8716E38064154631D7CC0D6D1A0313CC4098AF0
src/lib.rs | 5176 | B23A7EBD9CB00EE9FFDAD0B757BC107C28DEE82B0984575249FC77E412B38974
tests/artifact_class_disposition.rs | 1834 | B5956A618DA5F70495EF6E3CED1E6DC5B1A4A0EA283B2AE2D2FB97F3803002C9
tests/artifact_filename_envelope.rs | 1901 | D407CA8874064A304EB381ED719B693EC6851088ECB20E654D099A96DCB3020A
tests/artifact_namespace.rs | 2656 | C908B49BB1B4C475A04901C3A70FCF45585079616DE869082D6EC0B357FD1249
tests/artifact_utc_timestamp.rs | 2019 | C79937779E1022AA638F750D1F78DA1D6A6CE4A54DF52458BA83E18173EB9D20

CP005 INDEPENDENT SHA-256 VERIFICATION
Git HEAD: 12c02a0f2ff51fae72599adc09332f50fed62ce8
Inventory SHA256: 207213DCCB35A28E6DA0B091CC06CCCF9DD517796048D175869A31F3D56805D7
Expected entries: 19

RESULTS
PASS | .gitattributes | 109 | 978CF143947177C92114C50A5C68F24B6E9818597AA64788406884E116EC5A0B
PASS | .gitignore | 8 | 44C92E3A70AD3307B7056871C2BDB096D8BFA9373F5BF06A79BB6324A20FF2FB
PASS | Cargo.lock | 162 | BDB2BCD1BA65C0FFDABC7960B279978411113895E0CDAD12F4E2604E916BD9D8
PASS | Cargo.toml | 89 | 6FAD50B667CBD473B2E6A8E7FE4E33BD788B4CF617505B9A08B88E9B684EFF25
PASS | Evidence/CP-005/CP005_Format_Output.txt | 374 | A84075ECEA7D301EB0DDCE0A032D23679E3C7C83800C0E72E248649AF33B3EAB
PASS | Evidence/CP-005/CP005_GREEN_Source_Change.txt | 2203 | 2E6320A9C7DF6AD7BEFAACF1EA6954DC0C217D6B612C20213E346775CF3BB8A6
PASS | Evidence/CP-005/CP005_GREEN_Test_Output.txt | 2365 | 407DB6F584154C9935FCA75DFA882C7325950FB6D562CBC79642DB4B9715EB36
PASS | Evidence/CP-005/CP005_Post_Format_Diff_Review.txt | 2416 | 61C005FC2AB63C6360FC2E4A942A44434C4CE3EA517502750AB4292DCAD019AA
PASS | Evidence/CP-005/CP005_Post_Format_Test_Output.txt | 2396 | 7C1178BAF84C463DCB9C3F1F94AF2CAAD45DFD3ED19FB88A35E44E683A670B2B
PASS | Evidence/CP-005/CP005_RED_Test_Change.txt | 2450 | B56EB1D1C68FE337716306E4ED75007BD3511BCE7C2DF0A4E0C5CB9EE673B9FD
PASS | Evidence/CP-005/CP005_RED_Test_Output.txt | 3095 | C6D0AD1AF53C7EA2CA63634A38A82648A737777F610F5FC3D2D2BC3A067ABB2F
PASS | Evidence/CP-005/CP005_Starting_State.txt | 386 | A1CD2BE362838BA4C516A9724952F97184C93F0BDCAD45F68009B60DDA870B64
PASS | Evidence/CP-005/CP005_WASM_Build_Output.txt | 400 | 5715F5CE45F41DABF8C8CDBFAC219397226F9965627BFC7102B664F75597BF58
PASS | rust-toolchain.toml | 92 | D02F2301203B36F8C98CF05DD8716E38064154631D7CC0D6D1A0313CC4098AF0
PASS | src/lib.rs | 5176 | B23A7EBD9CB00EE9FFDAD0B757BC107C28DEE82B0984575249FC77E412B38974
PASS | tests/artifact_class_disposition.rs | 1834 | B5956A618DA5F70495EF6E3CED1E6DC5B1A4A0EA283B2AE2D2FB97F3803002C9
PASS | tests/artifact_filename_envelope.rs | 1901 | D407CA8874064A304EB381ED719B693EC6851088ECB20E654D099A96DCB3020A
PASS | tests/artifact_namespace.rs | 2656 | C908B49BB1B4C475A04901C3A70FCF45585079616DE869082D6EC0B357FD1249
PASS | tests/artifact_utc_timestamp.rs | 2019 | C79937779E1022AA638F750D1F78DA1D6A6CE4A54DF52458BA83E18173EB9D20

Files verified: 19 / 19
Issues: 0
RESULT: PASS

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.94s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)

running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_registered_emittable_classes ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)

running 3 tests
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)

running 6 tests
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_invalid_class_boundaries ... ok
test recognizes_governed_namespace_and_class ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

running 3 tests
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_nonexistent_gregorian_dates ... ok
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

CP005 Post-format Cargo exit code: 0
Total passing tests: 15
Production source SHA256: B23A7EBD9CB00EE9FFDAD0B757BC107C28DEE82B0984575249FC77E412B38974
Test source SHA256: C79937779E1022AA638F750D1F78DA1D6A6CE4A54DF52458BA83E18173EB9D20

CP005 PRECOMMIT GIT REVIEW
Git HEAD: 12c02a0f2ff51fae72599adc09332f50fed62ce8
Staged files: 0
CP005 evidence files before review: 11
Source SHA256: B23A7EBD9CB00EE9FFDAD0B757BC107C28DEE82B0984575249FC77E412B38974
Test SHA256: C79937779E1022AA638F750D1F78DA1D6A6CE4A54DF52458BA83E18173EB9D20
Inventory SHA256: 207213DCCB35A28E6DA0B091CC06CCCF9DD517796048D175869A31F3D56805D7
Verified inventory entries: 19 / 19
Git whitespace exit code: 0
Leap-second handling: PROVISIONAL; independent QA pending

=== PENDING CHANGES ===
 M src/lib.rs
?? Evidence/CP-005/CP005_Format_Output.txt
?? Evidence/CP-005/CP005_GREEN_Source_Change.txt
?? Evidence/CP-005/CP005_GREEN_Test_Output.txt
?? Evidence/CP-005/CP005_Hash_Inventory.txt
?? Evidence/CP-005/CP005_Hash_Inventory_Verification.txt
?? Evidence/CP-005/CP005_Post_Format_Diff_Review.txt
?? Evidence/CP-005/CP005_Post_Format_Test_Output.txt
?? Evidence/CP-005/CP005_RED_Test_Change.txt
?? Evidence/CP-005/CP005_RED_Test_Output.txt
?? Evidence/CP-005/CP005_Starting_State.txt
?? Evidence/CP-005/CP005_WASM_Build_Output.txt
?? tests/artifact_utc_timestamp.rs

=== SOURCE DIFF ===
diff --git a/src/lib.rs b/src/lib.rs
index d1ea916..57e06e4 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -108,6 +108,10 @@ pub fn is_canonical_immutable_artifact_filename(filename: &str) -> bool {
         return false;
     }
 
+    if !utc_calendar_fields_valid(timestamp) {
+        return false;
+    }
+
     let Some((uuid, extension)) = rest.split_once('.') else {
         return false;
     };
@@ -134,3 +138,37 @@ pub fn is_canonical_immutable_artifact_filename(filename: &str) -> bool {
 
     bytes[14] == b'4' && matches!(bytes[19], b'8' | b'9' | b'a' | b'b')
 }
+
+/// Validates Gregorian calendar and ordinary UTC clock fields.
+/// Called only after the 19-byte ASCII timestamp grammar has passed.
+/// Leap-second values (seconds = 60) are provisionally rejected.
+fn utc_calendar_fields_valid(timestamp: &[u8]) -> bool {
+    if timestamp.len() != 19 {
+        return false;
+    }
+
+    let digit = |index: usize| u32::from(timestamp[index] - b'0');
+    let two = |index: usize| digit(index) * 10 + digit(index + 1);
+
+    let year = digit(0) * 1000 + digit(1) * 100 + digit(2) * 10 + digit(3);
+    let month = two(4);
+    let day = two(6);
+    let hour = two(9);
+    let minute = two(11);
+    let second = two(13);
+
+    if year == 0 || !(1..=12).contains(&month) || hour > 23 || minute > 59 || second > 59 {
+        return false;
+    }
+
+    let leap_year = year % 4 == 0 && (year % 100 != 0 || year % 400 == 0);
+
+    let days_in_month = match month {
+        4 | 6 | 9 | 11 => 30,
+        2 if leap_year => 29,
+        2 => 28,
+        _ => 31,
+    };
+
+    (1..=days_in_month).contains(&day)
+}

RESULT: REVIEW READY

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.68s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)

running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_registered_emittable_classes ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)

running 3 tests
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)

running 6 tests
test recognizes_governed_namespace_and_class ... ok
test rejects_invalid_class_boundaries ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

running 3 tests
test rejects_nonexistent_gregorian_dates ... FAILED
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... FAILED
test accepts_valid_gregorian_dates_and_time_boundaries ... ok

failures:

---- rejects_nonexistent_gregorian_dates stdout ----

thread 'rejects_nonexistent_gregorian_dates' (1928) panicked at tests\artifact_utc_timestamp.rs:50:9:
Invalid date accepted: 00000101T000000000Z
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- rejects_invalid_clock_values_and_unapproved_leap_seconds stdout ----

thread 'rejects_invalid_clock_values_and_unapproved_leap_seconds' (10756) panicked at tests\artifact_utc_timestamp.rs:70:9:
Invalid clock/token accepted: 20261012T240000000Z


failures:
    rejects_invalid_clock_values_and_unapproved_leap_seconds
    rejects_nonexistent_gregorian_dates

test result: FAILED. 1 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

error: test failed, to rerun pass `--test artifact_utc_timestamp`
CP005 RED Cargo exit code: 101
Production source SHA256: EDCBDE36A28EE162A6216C22DA21200A97A3B4F7548C9C48EC028A0810C54E3D
Test source SHA256: C79937779E1022AA638F750D1F78DA1D6A6CE4A54DF52458BA83E18173EB9D20

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.38s
CP005 WASM build exit code: 0
Target: wasm32-unknown-unknown
Production source SHA256: B23A7EBD9CB00EE9FFDAD0B757BC107C28DEE82B0984575249FC77E412B38974
Test source SHA256: C79937779E1022AA638F750D1F78DA1D6A6CE4A54DF52458BA83E18173EB9D20

WASM-002 CP006 SHA-256 INVENTORY
Git baseline: cedd5d54506b8f3f879b96c5e64fefc9365b6eb0
Target requirement: PB-STOR-007
Scope: Semantic artifact class and serialization separation
Inventory entries: 20
Inventory excludes itself and later verification reports.
All sizes are exact file bytes.

PATH | BYTES | SHA256
.gitattributes | 109 | 978CF143947177C92114C50A5C68F24B6E9818597AA64788406884E116EC5A0B
.gitignore | 8 | 44C92E3A70AD3307B7056871C2BDB096D8BFA9373F5BF06A79BB6324A20FF2FB
Cargo.lock | 162 | BDB2BCD1BA65C0FFDABC7960B279978411113895E0CDAD12F4E2604E916BD9D8
Cargo.toml | 89 | 6FAD50B667CBD473B2E6A8E7FE4E33BD788B4CF617505B9A08B88E9B684EFF25
Evidence/CP-006/CP006_Format_Output.txt | 374 | 30E5CE37AB0B207A86153590B3E15DCA0FACD8680BE0C415DB97B2C9CD636122
Evidence/CP-006/CP006_GREEN_Source_Change.txt | 1841 | 2897FB2F15BD95FEBDAEE908772E0D9CCD4126E9C89A67D7A58AD59A8A791F66
Evidence/CP-006/CP006_GREEN_Test_Output.txt | 2880 | 7767D514CCA6CA2DBB1AF2C4EE2603D133C872C8769FDBC42D7996997182F2B2
Evidence/CP-006/CP006_Post_Format_Diff_Review.txt | 2022 | 41BF82EA933E2ED464E52801B5C31FD20EA4727BBF2811B62F910B8BE77FAD0F
Evidence/CP-006/CP006_Post_Format_Test_Output.txt | 2886 | 31C224F5099CFF452225CC99DB3680FE1A5464D0E8771684FAA5BFBAFF7D38A6
Evidence/CP-006/CP006_RED_Test_Change.txt | 3518 | E0EE9A49BDE2692C010F752A834A726E86F0782218B4C5FB156B731FB1FA8C12
Evidence/CP-006/CP006_RED_Test_Output.txt | 795 | 22EA0A6DA2CEC01CC7BE6BC5BC7A7FC2695F0E245520B10EA497056202D27943
Evidence/CP-006/CP006_Starting_State.txt | 870 | 13363EFF77C4AFF3559B1BE6B697C25B8F3856A22E7C63B6D942EF0A3844932A
Evidence/CP-006/CP006_WASM_Build_Output.txt | 400 | 5E7CCA2B0D3EB09F3E5888FAB99E5AA19AB8101FBE7839C5E4475D5D2EB0FFDD
rust-toolchain.toml | 92 | D02F2301203B36F8C98CF05DD8716E38064154631D7CC0D6D1A0313CC4098AF0
src/lib.rs | 6143 | B65E26AF5E2AB8E959936103DC6AD3E8D11BEB67E79722491546F00F5426A1C0
tests/artifact_class_disposition.rs | 1834 | B5956A618DA5F70495EF6E3CED1E6DC5B1A4A0EA283B2AE2D2FB97F3803002C9
tests/artifact_filename_envelope.rs | 1901 | D407CA8874064A304EB381ED719B693EC6851088ECB20E654D099A96DCB3020A
tests/artifact_namespace.rs | 2656 | C908B49BB1B4C475A04901C3A70FCF45585079616DE869082D6EC0B357FD1249
tests/artifact_serialization_separation.rs | 3003 | 3AC71FCD46A91BA471A53CA4A5DE945D91CC99E2E8E9FCAE3CB447FA75BD93D1
tests/artifact_utc_timestamp.rs | 2019 | C79937779E1022AA638F750D1F78DA1D6A6CE4A54DF52458BA83E18173EB9D20

CP006 INDEPENDENT SHA-256 VERIFICATION
Git HEAD: cedd5d54506b8f3f879b96c5e64fefc9365b6eb0
Inventory SHA256: E783D19F3199AECD20F93141FECAE51F2D10B60A9E5AFCC5EA9D8B9FD0AD6D91
Target requirement: PB-STOR-007
Expected entries: 20

RESULTS
PASS | .gitattributes | 109 | 978CF143947177C92114C50A5C68F24B6E9818597AA64788406884E116EC5A0B
PASS | .gitignore | 8 | 44C92E3A70AD3307B7056871C2BDB096D8BFA9373F5BF06A79BB6324A20FF2FB
PASS | Cargo.lock | 162 | BDB2BCD1BA65C0FFDABC7960B279978411113895E0CDAD12F4E2604E916BD9D8
PASS | Cargo.toml | 89 | 6FAD50B667CBD473B2E6A8E7FE4E33BD788B4CF617505B9A08B88E9B684EFF25
PASS | Evidence/CP-006/CP006_Format_Output.txt | 374 | 30E5CE37AB0B207A86153590B3E15DCA0FACD8680BE0C415DB97B2C9CD636122
PASS | Evidence/CP-006/CP006_GREEN_Source_Change.txt | 1841 | 2897FB2F15BD95FEBDAEE908772E0D9CCD4126E9C89A67D7A58AD59A8A791F66
PASS | Evidence/CP-006/CP006_GREEN_Test_Output.txt | 2880 | 7767D514CCA6CA2DBB1AF2C4EE2603D133C872C8769FDBC42D7996997182F2B2
PASS | Evidence/CP-006/CP006_Post_Format_Diff_Review.txt | 2022 | 41BF82EA933E2ED464E52801B5C31FD20EA4727BBF2811B62F910B8BE77FAD0F
PASS | Evidence/CP-006/CP006_Post_Format_Test_Output.txt | 2886 | 31C224F5099CFF452225CC99DB3680FE1A5464D0E8771684FAA5BFBAFF7D38A6
PASS | Evidence/CP-006/CP006_RED_Test_Change.txt | 3518 | E0EE9A49BDE2692C010F752A834A726E86F0782218B4C5FB156B731FB1FA8C12
PASS | Evidence/CP-006/CP006_RED_Test_Output.txt | 795 | 22EA0A6DA2CEC01CC7BE6BC5BC7A7FC2695F0E245520B10EA497056202D27943
PASS | Evidence/CP-006/CP006_Starting_State.txt | 870 | 13363EFF77C4AFF3559B1BE6B697C25B8F3856A22E7C63B6D942EF0A3844932A
PASS | Evidence/CP-006/CP006_WASM_Build_Output.txt | 400 | 5E7CCA2B0D3EB09F3E5888FAB99E5AA19AB8101FBE7839C5E4475D5D2EB0FFDD
PASS | rust-toolchain.toml | 92 | D02F2301203B36F8C98CF05DD8716E38064154631D7CC0D6D1A0313CC4098AF0
PASS | src/lib.rs | 6143 | B65E26AF5E2AB8E959936103DC6AD3E8D11BEB67E79722491546F00F5426A1C0
PASS | tests/artifact_class_disposition.rs | 1834 | B5956A618DA5F70495EF6E3CED1E6DC5B1A4A0EA283B2AE2D2FB97F3803002C9
PASS | tests/artifact_filename_envelope.rs | 1901 | D407CA8874064A304EB381ED719B693EC6851088ECB20E654D099A96DCB3020A
PASS | tests/artifact_namespace.rs | 2656 | C908B49BB1B4C475A04901C3A70FCF45585079616DE869082D6EC0B357FD1249
PASS | tests/artifact_serialization_separation.rs | 3003 | 3AC71FCD46A91BA471A53CA4A5DE945D91CC99E2E8E9FCAE3CB447FA75BD93D1
PASS | tests/artifact_utc_timestamp.rs | 2019 | C79937779E1022AA638F750D1F78DA1D6A6CE4A54DF52458BA83E18173EB9D20

Files verified: 20 / 20
Issues: 0
RESULT: PASS

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 1.19s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)

running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok
test distinguishes_registered_emittable_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)

running 3 tests
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)

running 6 tests
test recognizes_governed_namespace_and_class ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_invalid_class_boundaries ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)

running 4 tests
test extension_does_not_determine_semantic_class ... ok
test extracts_semantic_class_and_serialization_separately ... ok
test preserves_literal_tokens_without_claiming_authority ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

running 3 tests
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok
test rejects_nonexistent_gregorian_dates ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

CP006 Post-format Cargo exit code: 0
Total passing tests: 19
Production source SHA256: B65E26AF5E2AB8E959936103DC6AD3E8D11BEB67E79722491546F00F5426A1C0
Test source SHA256: 3AC71FCD46A91BA471A53CA4A5DE945D91CC99E2E8E9FCAE3CB447FA75BD93D1

CP006 PRECOMMIT GIT REVIEW
Git HEAD: cedd5d54506b8f3f879b96c5e64fefc9365b6eb0
Target requirement: PB-STOR-007
Staged files: 0
CP006 evidence files before review: 11
Source SHA256: B65E26AF5E2AB8E959936103DC6AD3E8D11BEB67E79722491546F00F5426A1C0
Test SHA256: 3AC71FCD46A91BA471A53CA4A5DE945D91CC99E2E8E9FCAE3CB447FA75BD93D1
Inventory SHA256: E783D19F3199AECD20F93141FECAE51F2D10B60A9E5AFCC5EA9D8B9FD0AD6D91
Verified inventory entries: 20 / 20
Rustfmt check exit code: 0
Git whitespace exit code: 0
Scope: Semantic class / serialization token separation
Artifact authority: NOT GRANTED

=== PENDING CHANGES ===
 M src/lib.rs
?? Evidence/CP-006/CP006_Format_Output.txt
?? Evidence/CP-006/CP006_GREEN_Source_Change.txt
?? Evidence/CP-006/CP006_GREEN_Test_Output.txt
?? Evidence/CP-006/CP006_Hash_Inventory.txt
?? Evidence/CP-006/CP006_Hash_Inventory_Verification.txt
?? Evidence/CP-006/CP006_Post_Format_Diff_Review.txt
?? Evidence/CP-006/CP006_Post_Format_Test_Output.txt
?? Evidence/CP-006/CP006_RED_Test_Change.txt
?? Evidence/CP-006/CP006_RED_Test_Output.txt
?? Evidence/CP-006/CP006_Starting_State.txt
?? Evidence/CP-006/CP006_WASM_Build_Output.txt
?? tests/artifact_serialization_separation.rs

=== SOURCE DIFF ===
diff --git a/src/lib.rs b/src/lib.rs
index 57e06e4..5510381 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -172,3 +172,30 @@ fn utc_calendar_fields_valid(timestamp: &[u8]) -> bool {
 
     (1..=days_in_month).contains(&day)
 }
+
+/// Lexical class and serialization tokens from a canonical artifact filename.
+///
+/// Extraction does not register a class, approve a serialization format,
+/// validate artifact contents, or establish governed authority.
+#[derive(Debug, Clone, Copy, PartialEq, Eq)]
+pub struct ArtifactFilenameTokens<'a> {
+    pub semantic_class: &'a str,
+    pub serialization_extension: &'a str,
+}
+
+/// Extracts independent class and serialization tokens after envelope validation.
+pub fn extract_artifact_filename_tokens(filename: &str) -> Option<ArtifactFilenameTokens<'_>> {
+    if !is_canonical_immutable_artifact_filename(filename) {
+        return None;
+    }
+
+    let rest = filename.strip_prefix("__DS__")?;
+    let (semantic_class, rest) = rest.split_once("__")?;
+    let (_, rest) = rest.split_once("__")?;
+    let (_, serialization_extension) = rest.split_once('.')?;
+
+    Some(ArtifactFilenameTokens {
+        semantic_class,
+        serialization_extension,
+    })
+}

RESULT: REVIEW READY

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
error[E0432]: unresolved import `data_sculptor_core::extract_artifact_filename_tokens`
 --> tests\artifact_serialization_separation.rs:1:5
  |
1 | use data_sculptor_core::extract_artifact_filename_tokens;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `extract_artifact_filename_tokens` in the root

For more information about this error, try `rustc --explain E0432`.
error: could not compile `data_sculptor_core` (test "artifact_serialization_separation") due to 1 previous error
CP006 RED Cargo exit code: 101
Production source SHA256: B23A7EBD9CB00EE9FFDAD0B757BC107C28DEE82B0984575249FC77E412B38974
Test source SHA256: 3AC71FCD46A91BA471A53CA4A5DE945D91CC99E2E8E9FCAE3CB447FA75BD93D1

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.36s
CP006 WASM build exit code: 0
Target: wasm32-unknown-unknown
Production source SHA256: B65E26AF5E2AB8E959936103DC6AD3E8D11BEB67E79722491546F00F5426A1C0
Test source SHA256: 3AC71FCD46A91BA471A53CA4A5DE945D91CC99E2E8E9FCAE3CB447FA75BD93D1

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 1.79s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)

running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok
test distinguishes_registered_emittable_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)

running 4 tests
test refuses_invalid_timestamp_uuid_and_empty_extension ... ok
test preserves_extension_without_case_or_unicode_normalization ... ok
test refuses_noncanonical_class_without_repair ... ok
test constructs_exact_canonical_filename_candidates ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)

running 3 tests
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)

running 6 tests
test recognizes_governed_namespace_and_class ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_invalid_class_boundaries ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)

running 4 tests
test extension_does_not_determine_semantic_class ... ok
test extracts_semantic_class_and_serialization_separately ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok
test preserves_literal_tokens_without_claiming_authority ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

running 3 tests
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_nonexistent_gregorian_dates ... ok
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

CP007 GREEN Cargo exit code: 0
Total passing tests: 23
Production source SHA256: 7520BCF2E246D3488C8F1187F95C9B5A30586C6E7E0D65A1D841A5F8239018D0
Test source SHA256: DCF94D1E8EBFC224B260A8466FF212D7E8BEE2E47DAE81F1371E8571EF034783

WASM-002 CP007 SHA-256 INVENTORY
Git HEAD: aff54d08dcbacaa0c54d8869749344a504c5ad61
Target requirement: PB-STOR-010
Native post-format tests: 23
WASM build exit code: 0
Expected entries: 21
Format: PATH | BYTES | SHA256

ENTRIES
.gitattributes | 109 | 978CF143947177C92114C50A5C68F24B6E9818597AA64788406884E116EC5A0B
.gitignore | 8 | 44C92E3A70AD3307B7056871C2BDB096D8BFA9373F5BF06A79BB6324A20FF2FB
Cargo.lock | 162 | BDB2BCD1BA65C0FFDABC7960B279978411113895E0CDAD12F4E2604E916BD9D8
Cargo.toml | 89 | 6FAD50B667CBD473B2E6A8E7FE4E33BD788B4CF617505B9A08B88E9B684EFF25
rust-toolchain.toml | 92 | D02F2301203B36F8C98CF05DD8716E38064154631D7CC0D6D1A0313CC4098AF0
src/lib.rs | 6829 | 6F4D9914DAAD44084B8E5F4E548139E5A8E46CCE7DD055586AE34C619328E812
tests/artifact_class_disposition.rs | 1834 | B5956A618DA5F70495EF6E3CED1E6DC5B1A4A0EA283B2AE2D2FB97F3803002C9
tests/artifact_filename_construction.rs | 2872 | EBBBE7DA74CA32959C0F851494FD0D6F72688D93708F91E37AE5082BA47B18E9
tests/artifact_filename_envelope.rs | 1901 | D407CA8874064A304EB381ED719B693EC6851088ECB20E654D099A96DCB3020A
tests/artifact_namespace.rs | 2656 | C908B49BB1B4C475A04901C3A70FCF45585079616DE869082D6EC0B357FD1249
tests/artifact_serialization_separation.rs | 3003 | 3AC71FCD46A91BA471A53CA4A5DE945D91CC99E2E8E9FCAE3CB447FA75BD93D1
tests/artifact_utc_timestamp.rs | 2019 | C79937779E1022AA638F750D1F78DA1D6A6CE4A54DF52458BA83E18173EB9D20
Evidence/CP-007/CP007_Starting_State.txt | 1169 | 3D767A70AC72D06717FB95C8487BD8BDF71D7EFB7C7F6FAD0CFEF310BC5C6F70
Evidence/CP-007/CP007_RED_Test_Change.txt | 3586 | 46996AE34BC885B75F7DEEF156467D0C5775DC890675C0C79313C094552BE4D0
Evidence/CP-007/CP007_RED_Test_Output.txt | 793 | E2B202895A0356D76883F69CAD89747822BA62403D7F145B5C31D4933092485D
Evidence/CP-007/CP007_GREEN_Source_Change.txt | 1575 | 43BF205FACAE0E345F0914A0E9D19438C7124C56F6132CFB6558AFECC0F4C511
Evidence/CP-007/CP007_GREEN_Test_Output.txt | 3364 | 55DF006D757F7710AF8B7F4D61F50AF4A0989E797F0494C31FDDFFAAE939CFD0
Evidence/CP-007/CP007_Format_Output.txt | 374 | 5601F96365B88EA79481D723C1225C7A3BAD1E9BA3A220E35E34396D0B0B353D
Evidence/CP-007/CP007_Post_Format_Diff_Review.txt | 1924 | 6E9FFA3503FA205F87892CFD3661217DD28232418532DBA27C3A91A417931A9F
Evidence/CP-007/CP007_Post_Format_Test_Output.txt | 3410 | D0E7573CEC3BE27761633F292D5CF4A88FA50AC1FACD8E8D26720153DE2C6AAD
Evidence/CP-007/CP007_WASM_Build_Output.txt | 400 | 387F3E8166ADA7BB42FA9EC5E72D4E85F2A868E8235EFDF603E4DB2825186A77

CP007 INDEPENDENT SHA-256 VERIFICATION
Git HEAD: aff54d08dcbacaa0c54d8869749344a504c5ad61
Inventory SHA256: 5BA36A94D5A3516792BBC81056F2488938D546F473A68E80BB3DD185445D76D2
Target requirement: PB-STOR-010
Expected entries: 21

RESULTS
PASS | .gitattributes | 109 | 978CF143947177C92114C50A5C68F24B6E9818597AA64788406884E116EC5A0B
PASS | .gitignore | 8 | 44C92E3A70AD3307B7056871C2BDB096D8BFA9373F5BF06A79BB6324A20FF2FB
PASS | Cargo.lock | 162 | BDB2BCD1BA65C0FFDABC7960B279978411113895E0CDAD12F4E2604E916BD9D8
PASS | Cargo.toml | 89 | 6FAD50B667CBD473B2E6A8E7FE4E33BD788B4CF617505B9A08B88E9B684EFF25
PASS | rust-toolchain.toml | 92 | D02F2301203B36F8C98CF05DD8716E38064154631D7CC0D6D1A0313CC4098AF0
PASS | src/lib.rs | 6829 | 6F4D9914DAAD44084B8E5F4E548139E5A8E46CCE7DD055586AE34C619328E812
PASS | tests/artifact_class_disposition.rs | 1834 | B5956A618DA5F70495EF6E3CED1E6DC5B1A4A0EA283B2AE2D2FB97F3803002C9
PASS | tests/artifact_filename_construction.rs | 2872 | EBBBE7DA74CA32959C0F851494FD0D6F72688D93708F91E37AE5082BA47B18E9
PASS | tests/artifact_filename_envelope.rs | 1901 | D407CA8874064A304EB381ED719B693EC6851088ECB20E654D099A96DCB3020A
PASS | tests/artifact_namespace.rs | 2656 | C908B49BB1B4C475A04901C3A70FCF45585079616DE869082D6EC0B357FD1249
PASS | tests/artifact_serialization_separation.rs | 3003 | 3AC71FCD46A91BA471A53CA4A5DE945D91CC99E2E8E9FCAE3CB447FA75BD93D1
PASS | tests/artifact_utc_timestamp.rs | 2019 | C79937779E1022AA638F750D1F78DA1D6A6CE4A54DF52458BA83E18173EB9D20
PASS | Evidence/CP-007/CP007_Starting_State.txt | 1169 | 3D767A70AC72D06717FB95C8487BD8BDF71D7EFB7C7F6FAD0CFEF310BC5C6F70
PASS | Evidence/CP-007/CP007_RED_Test_Change.txt | 3586 | 46996AE34BC885B75F7DEEF156467D0C5775DC890675C0C79313C094552BE4D0
PASS | Evidence/CP-007/CP007_RED_Test_Output.txt | 793 | E2B202895A0356D76883F69CAD89747822BA62403D7F145B5C31D4933092485D
PASS | Evidence/CP-007/CP007_GREEN_Source_Change.txt | 1575 | 43BF205FACAE0E345F0914A0E9D19438C7124C56F6132CFB6558AFECC0F4C511
PASS | Evidence/CP-007/CP007_GREEN_Test_Output.txt | 3364 | 55DF006D757F7710AF8B7F4D61F50AF4A0989E797F0494C31FDDFFAAE939CFD0
PASS | Evidence/CP-007/CP007_Format_Output.txt | 374 | 5601F96365B88EA79481D723C1225C7A3BAD1E9BA3A220E35E34396D0B0B353D
PASS | Evidence/CP-007/CP007_Post_Format_Diff_Review.txt | 1924 | 6E9FFA3503FA205F87892CFD3661217DD28232418532DBA27C3A91A417931A9F
PASS | Evidence/CP-007/CP007_Post_Format_Test_Output.txt | 3410 | D0E7573CEC3BE27761633F292D5CF4A88FA50AC1FACD8E8D26720153DE2C6AAD
PASS | Evidence/CP-007/CP007_WASM_Build_Output.txt | 400 | 387F3E8166ADA7BB42FA9EC5E72D4E85F2A868E8235EFDF603E4DB2825186A77

Files verified: 21 / 21
Issues: 0
RESULT: PASS

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 1.29s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)

running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_registered_emittable_classes ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)

running 4 tests
test refuses_invalid_timestamp_uuid_and_empty_extension ... ok
test preserves_extension_without_case_or_unicode_normalization ... ok
test refuses_noncanonical_class_without_repair ... ok
test constructs_exact_canonical_filename_candidates ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)

running 3 tests
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)

running 6 tests
test recognizes_governed_namespace_and_class ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_invalid_class_boundaries ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test reserved_prefix_is_independent_of_registered_class ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)

running 4 tests
test extension_does_not_determine_semantic_class ... ok
test extracts_semantic_class_and_serialization_separately ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok
test preserves_literal_tokens_without_claiming_authority ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

running 3 tests
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok
test rejects_nonexistent_gregorian_dates ... ok
test accepts_valid_gregorian_dates_and_time_boundaries ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

CP007 Post-format Cargo exit code: 0
Test suites: 7
Total passing tests: 23
CP007 passing tests: 4
Production source SHA256: 6F4D9914DAAD44084B8E5F4E548139E5A8E46CCE7DD055586AE34C619328E812
Test source SHA256: EBBBE7DA74CA32959C0F851494FD0D6F72688D93708F91E37AE5082BA47B18E9

CP007 PRECOMMIT GIT REVIEW
Git HEAD: aff54d08dcbacaa0c54d8869749344a504c5ad61
Target requirement: PB-STOR-010
Source SHA256: 6F4D9914DAAD44084B8E5F4E548139E5A8E46CCE7DD055586AE34C619328E812
Test SHA256: EBBBE7DA74CA32959C0F851494FD0D6F72688D93708F91E37AE5082BA47B18E9
Inventory SHA256: 5BA36A94D5A3516792BBC81056F2488938D546F473A68E80BB3DD185445D76D2
Verification SHA256: A504583F0C369CB525378B8AB688E060EEF3864C019DFC68B71BE7043447603C
Verified inventory entries: 21 / 21
Post-format native tests: 23 / 23 PASS
WASM compilation: PASS
Rustfmt check exit code: 0
Git whitespace check exit code: 0
Removed source lines: 0
Previously staged files: 0
Pending CP007 paths: 13
Scope: Exact canonical filename candidate construction
No filesystem writes, silent normalization, or artifact authority

=== PENDING CHANGES ===
 M src/lib.rs
?? Evidence/CP-007/CP007_Format_Output.txt
?? Evidence/CP-007/CP007_GREEN_Source_Change.txt
?? Evidence/CP-007/CP007_GREEN_Test_Output.txt
?? Evidence/CP-007/CP007_Hash_Inventory.txt
?? Evidence/CP-007/CP007_Hash_Inventory_Verification.txt
?? Evidence/CP-007/CP007_Post_Format_Diff_Review.txt
?? Evidence/CP-007/CP007_Post_Format_Test_Output.txt
?? Evidence/CP-007/CP007_RED_Test_Change.txt
?? Evidence/CP-007/CP007_RED_Test_Output.txt
?? Evidence/CP-007/CP007_Starting_State.txt
?? Evidence/CP-007/CP007_WASM_Build_Output.txt
?? tests/artifact_filename_construction.rs

=== SOURCE DIFF ===
diff --git a/src/lib.rs b/src/lib.rs
index 5510381..72e48f3 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -199,3 +199,23 @@ pub fn extract_artifact_filename_tokens(filename: &str) -> Option<ArtifactFilena
         serialization_extension,
     })
 }
+
+/// Constructs a canonical immutable filename candidate from exact input tokens.
+///
+/// This function performs no case folding, trimming, Unicode normalization,
+/// UUID allocation, filesystem operation, or artifact publication.
+/// A successful candidate does not establish governed artifact authority.
+pub fn build_immutable_artifact_filename_candidate(
+    semantic_class: &str,
+    utc: &str,
+    uuid: &str,
+    serialization_extension: &str,
+) -> Option<String> {
+    let filename = format!("__DS__{semantic_class}__{utc}__{uuid}.{serialization_extension}");
+
+    if is_canonical_immutable_artifact_filename(&filename) {
+        Some(filename)
+    } else {
+        None
+    }
+}

RESULT: REVIEW READY

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
error[E0432]: unresolved import `data_sculptor_core::build_immutable_artifact_filename_candidate`
 --> tests\artifact_filename_construction.rs:2:5
  |
2 |     build_immutable_artifact_filename_candidate,
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `build_immutable_artifact_filename_candidate` in the root

For more information about this error, try `rustc --explain E0432`.
error: could not compile `data_sculptor_core` (test "artifact_filename_construction") due to 1 previous error
CP007 RED Cargo exit code: 101
Production source SHA256: B65E26AF5E2AB8E959936103DC6AD3E8D11BEB67E79722491546F00F5426A1C0
Test source SHA256: DCF94D1E8EBFC224B260A8466FF212D7E8BEE2E47DAE81F1371E8571EF034783

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.60s
CP007 WASM build exit code: 0
Target: wasm32-unknown-unknown
Production source SHA256: 6F4D9914DAAD44084B8E5F4E548139E5A8E46CCE7DD055586AE34C619328E812
Test source SHA256: EBBBE7DA74CA32959C0F851494FD0D6F72688D93708F91E37AE5082BA47B18E9

CP008 FINAL SOURCE REVIEW - DAY 066
Git HEAD: 3c512df519f3a2431b363e4c57dc234c02378124
Staged files: 17
Command: git diff --cached --check -- src/lib.rs tests/CP008_source_eligibility.rs
Rust source/test whitespace exit code: 0

CP008 GREEN - Day 066
Git HEAD: 3c512df519f3a2431b363e4c57dc234c02378124
Command: cargo test --locked --test CP008_source_eligibility
   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 1.99s
     Running tests\CP008_source_eligibility.rs (target\debug\deps\CP008_source_eligibility-194c314726b26929.exe)

running 5 tests
test accepts_analyst_csv_final_extension_in_ascii_case_variants ... ok
test makes_no_case_or_unicode_normalization_claim ... ok
test refuses_paths_traversal_and_external_references ... ok
test refuses_reserved_namespace_even_if_name_looks_like_csv ... ok
test rejects_non_csv_or_nonfinal_csv_extensions ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Cargo exit code: 0

CP008 SHA-256 Inventory - Day 066
Git HEAD: 3c512df519f3a2431b363e4c57dc234c02378124
Records: 20
Recorded UTC: 2026-10-13T18:19:04Z
Path	SizeBytes	SHA256
Cargo.toml	89	6FAD50B667CBD473B2E6A8E7FE4E33BD788B4CF617505B9A08B88E9B684EFF25
Cargo.lock	162	BDB2BCD1BA65C0FFDABC7960B279978411113895E0CDAD12F4E2604E916BD9D8
rust-toolchain.toml	92	D02F2301203B36F8C98CF05DD8716E38064154631D7CC0D6D1A0313CC4098AF0
.gitattributes	109	978CF143947177C92114C50A5C68F24B6E9818597AA64788406884E116EC5A0B
src\lib.rs	7783	5D0BA1723F2BBF0E9A4B2EB629183EEF9FEE809946080AA72BA63B523D69EAC2
tests\CP008_source_eligibility.rs	2189	298768A861A9BB1A1AF9822C8F5883B9C8E87981BAA13BCD88F6A83DFBB628B7
tests\artifact_class_disposition.rs	1834	B5956A618DA5F70495EF6E3CED1E6DC5B1A4A0EA283B2AE2D2FB97F3803002C9
tests\artifact_filename_construction.rs	2872	EBBBE7DA74CA32959C0F851494FD0D6F72688D93708F91E37AE5082BA47B18E9
tests\artifact_filename_envelope.rs	1901	D407CA8874064A304EB381ED719B693EC6851088ECB20E654D099A96DCB3020A
tests\artifact_namespace.rs	2656	C908B49BB1B4C475A04901C3A70FCF45585079616DE869082D6EC0B357FD1249
tests\artifact_serialization_separation.rs	3003	3AC71FCD46A91BA471A53CA4A5DE945D91CC99E2E8E9FCAE3CB447FA75BD93D1
tests\artifact_utc_timestamp.rs	2019	C79937779E1022AA638F750D1F78DA1D6A6CE4A54DF52458BA83E18173EB9D20
Evidence\CP-008\CP008_RED_Test_Output.txt	742	6E6C48DA9CF91E11F209780E484008FDB2A57F95FF9C244A4E5685FC38642F33
Evidence\CP-008\CP008_GREEN_Test_Output.txt	851	50B4A79709EB833DB770CEB79285F5A910131F938F8A0F5703B35040C89C7398
Evidence\CP-008\CP008_Full_Regression_Test_Output.txt	3950	FCD89D04AA60A808AD94314A713DC233C855A9AE48323A63D8F8337008AA75E8
Evidence\CP-008\CP008_Rustfmt_Output.txt	24	20B54110CB25FC25E72BC1F412D30443C0636B9D8769880A7D625ADA26A801B9
Evidence\CP-008\CP008_Rustfmt_Check_Output.txt	28	237E14061B55413CB450524444BF6800A6645E843A9AE7345A9AF6F5D60E8F73
Evidence\CP-008\CP008_Git_Whitespace_Check.txt	35	1E4A1D7B3562C3BED85700144C961DAA5DC7929855FFA104C34BB95C7BA737F7
Evidence\CP-008\CP008_Post_Format_Test_Output.txt	3830	81DF01E4171FA2480B89393A7D264B0C1572FF510DEA0A4F3804957BF6FB6312
Evidence\CP-008\CP008_WASM_Build_Output.txt	326	154F5CF140A544A2AD15D8ADBFF0382B5A4183E12B66472AB028EF09B28B4F2E

CP008 Independent SHA-256 Verification
Git HEAD: 3c512df519f3a2431b363e4c57dc234c02378124
Inventory SHA-256: 79FC5E414857405DE31C3A9E09FBF165F8691199D8AC54F6AFB40C7B68A3338E
Records: 20
Matched: 20
Issues: 0
RESULT: PASS

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.34s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP008_source_eligibility.rs (target\debug\deps\CP008_source_eligibility-194c314726b26929.exe)

running 5 tests
test accepts_analyst_csv_final_extension_in_ascii_case_variants ... ok
test makes_no_case_or_unicode_normalization_claim ... ok
test refuses_paths_traversal_and_external_references ... ok
test refuses_reserved_namespace_even_if_name_looks_like_csv ... ok
test rejects_non_csv_or_nonfinal_csv_extensions ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)

running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_registered_emittable_classes ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)

running 4 tests
test constructs_exact_canonical_filename_candidates ... ok
test preserves_extension_without_case_or_unicode_normalization ... ok
test refuses_invalid_timestamp_uuid_and_empty_extension ... ok
test refuses_noncanonical_class_without_repair ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)

running 3 tests
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)

running 6 tests
test recognizes_governed_namespace_and_class ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test rejects_invalid_class_boundaries ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)

running 4 tests
test extension_does_not_determine_semantic_class ... ok
test extracts_semantic_class_and_serialization_separately ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok
test preserves_literal_tokens_without_claiming_authority ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

running 3 tests
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_nonexistent_gregorian_dates ... ok
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests data_sculptor_core

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Cargo exit code: 0

CP008 PRECOMMIT GIT REVIEW - DAY 066
Git HEAD: 3c512df519f3a2431b363e4c57dc234c02378124
Staged files: 12

COMMAND: git diff --cached --name-status
A	Evidence/CP-008/CP008_Full_Regression_Test_Output.txt
A	Evidence/CP-008/CP008_GREEN_Test_Output.txt
A	Evidence/CP-008/CP008_Git_Whitespace_Check.txt
A	Evidence/CP-008/CP008_Hash_Inventory.txt
A	Evidence/CP-008/CP008_Hash_Inventory_Verification.txt
A	Evidence/CP-008/CP008_Post_Format_Test_Output.txt
A	Evidence/CP-008/CP008_RED_Test_Output.txt
A	Evidence/CP-008/CP008_Rustfmt_Check_Output.txt
A	Evidence/CP-008/CP008_Rustfmt_Output.txt
A	Evidence/CP-008/CP008_WASM_Build_Output.txt
M	src/lib.rs
A	tests/CP008_source_eligibility.rs
Exit code: 0

COMMAND: git diff --cached --check
Exit code: 0

COMMAND: git diff --cached --stat
 .../CP-008/CP008_Full_Regression_Test_Output.txt   | 88 ++++++++++++++++++++++
 Evidence/CP-008/CP008_GREEN_Test_Output.txt        | 17 +++++
 Evidence/CP-008/CP008_Git_Whitespace_Check.txt     |  1 +
 Evidence/CP-008/CP008_Hash_Inventory.txt           | 25 ++++++
 .../CP-008/CP008_Hash_Inventory_Verification.txt   |  7 ++
 Evidence/CP-008/CP008_Post_Format_Test_Output.txt  | 85 +++++++++++++++++++++
 Evidence/CP-008/CP008_RED_Test_Output.txt          | 13 ++++
 Evidence/CP-008/CP008_Rustfmt_Check_Output.txt     |  1 +
 Evidence/CP-008/CP008_Rustfmt_Output.txt           |  1 +
 Evidence/CP-008/CP008_WASM_Build_Output.txt        |  6 ++
 src/lib.rs                                         | 30 +++++++-
 tests/CP008_source_eligibility.rs                  | 72 ++++++++++++++++++
 12 files changed, 344 insertions(+), 2 deletions(-)
Exit code: 0

COMMAND: git diff --cached -- src/lib.rs tests/CP008_source_eligibility.rs
diff --git a/src/lib.rs b/src/lib.rs
index 72e48f3..65e21fd 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -5,6 +5,31 @@ pub fn has_reserved_namespace_prefix(filename: &str) -> bool {
     filename.starts_with("__DS__")
 }
 
+/// Screens an exact filename for analyst-owned CSV SOURCE candidate form.
+///
+/// The full filename is not folded, trimmed, or Unicode-normalized. ASCII
+/// case-insensitivity applies only to the final ".csv" extension.
+/// A true result does NOT prove that a Suitcase-root regular file exists,
+/// that an exact physical filename matched, or that encoding/CSV is valid.
+/// Governed CVT sources require separate publication/validity checks.
+pub fn is_analyst_owned_csv_source_candidate(filename: &str) -> bool {
+    if filename.is_empty()
+        || has_reserved_namespace_prefix(filename)
+        || filename.contains('/')
+        || filename.contains('\\')
+        || filename.contains(':')
+        || filename.contains("..")
+    {
+        return false;
+    }
+
+    let Some((stem, extension)) = filename.rsplit_once('.') else {
+        return false;
+    };
+
+    !stem.is_empty() && extension.eq_ignore_ascii_case("csv")
+}
+
 /// Recognizes a governed Data Sculptor artifact class from a filename.
 ///
 /// Lexical recognition only: this does not validate file contents,
@@ -76,8 +101,9 @@ pub fn classify_artifact_class_token(filename: &str) -> ArtifactClassDisposition
 
 /// Checks the lexical envelope of an ordinary immutable artifact filename.
 ///
-/// This does not validate the UTC calendar date, artifact-specific extension,
-/// registered class, governed contents, provenance, or authority.
+/// This validates ordinary Gregorian UTC calendar/clock fields, but not
+/// artifact-specific extension, registered class, governed contents,
+/// provenance, or authority.
 pub fn is_canonical_immutable_artifact_filename(filename: &str) -> bool {
     let Some(rest) = filename.strip_prefix("__DS__") else {
         return false;
diff --git a/tests/CP008_source_eligibility.rs b/tests/CP008_source_eligibility.rs
new file mode 100644
index 0000000..9278693
--- /dev/null
+++ b/tests/CP008_source_eligibility.rs
@@ -0,0 +1,72 @@
+// CP008 RED tests -- Day 066
+// Frozen requirement: W002-WKO-009.1; related: PB-STOR-005, PB-STOR-008,
+// PB-STOR-010, W002-UI-ACC-014.
+// Scope: analyst-owned CSV filename *candidate* only. No filesystem access,
+// regular-file proof, exact physical lookup, CVT publication proof, or CSV parsing.
+
+use data_sculptor_core::is_analyst_owned_csv_source_candidate;
+
+#[test]
+fn accepts_analyst_csv_final_extension_in_ascii_case_variants() {
+    for name in [
+        "crime.csv",
+        "crime.CSV",
+        "crime.CsV",
+        "crime.cSv",
+        "study.v2.csv",
+    ] {
+        assert!(is_analyst_owned_csv_source_candidate(name), "{name:?}");
+    }
+}
+
+#[test]
+fn rejects_non_csv_or_nonfinal_csv_extensions() {
+    for name in [
+        "crime",
+        "crime.txt",
+        "crime.csv.bak",
+        "crime.csv.gz",
+        "crime.csv ",
+    ] {
+        assert!(!is_analyst_owned_csv_source_candidate(name), "{name:?}");
+    }
+}
+
+#[test]
+fn refuses_reserved_namespace_even_if_name_looks_like_csv() {
+    for name in [
+        "__DS__notes.csv",
+        "__DS__COL__20261012T213045123Z__b6f032e5-527e-4cdf-9951-2f1bb72ffaca.csv",
+        "__DS__CVT__20261012T213045123Z__b6f032e5-527e-4cdf-9951-2f1bb72ffaca.csv",
+    ] {
+        assert!(!is_analyst_owned_csv_source_candidate(name), "{name:?}");
+    }
+}
+
+#[test]
+fn refuses_paths_traversal_and_external_references() {
+    for name in [
+        "../crime.csv",
+        r"..\crime.csv",
+        "folder/crime.csv",
+        r"folder\crime.csv",
+        "/crime.csv",
+        r"C:\data\crime.csv",
+        r"\\server\share\crime.csv",
+        "https://example.test/crime.csv",
+        "file:///tmp/crime.csv",
+        "file:crime.csv",
+        "crime:stream.csv",
+    ] {
+        assert!(!is_analyst_owned_csv_source_candidate(name), "{name:?}");
+    }
+}
+
+#[test]
+fn makes_no_case_or_unicode_normalization_claim() {
+    // Both are candidate forms; this helper does NOT resolve either filename.
+    // Exact on-disk reference comparison and regular-file status are later gates.
+    for name in ["Crime.CSV", "crime.CSV", "cafe\u{301}.csv", "caf\u{e9}.csv"] {
+        assert!(is_analyst_owned_csv_source_candidate(name), "{name:?}");
+    }
+}
Exit code: 0

COMMAND: git status --short --branch
## master
A  Evidence/CP-008/CP008_Full_Regression_Test_Output.txt
A  Evidence/CP-008/CP008_GREEN_Test_Output.txt
A  Evidence/CP-008/CP008_Git_Whitespace_Check.txt
A  Evidence/CP-008/CP008_Hash_Inventory.txt
A  Evidence/CP-008/CP008_Hash_Inventory_Verification.txt
A  Evidence/CP-008/CP008_Post_Format_Test_Output.txt
A  Evidence/CP-008/CP008_RED_Test_Output.txt
A  Evidence/CP-008/CP008_Rustfmt_Check_Output.txt
A  Evidence/CP-008/CP008_Rustfmt_Output.txt
A  Evidence/CP-008/CP008_WASM_Build_Output.txt
M  src/lib.rs
A  tests/CP008_source_eligibility.rs
?? Evidence/CP-008/CP008_Precommit_Git_Review.txt
?? Evidence/Day066_Preflight_Native_Test_Output.txt
Exit code: 0

CP008 RED - Day 066
Git HEAD: 3c512df519f3a2431b363e4c57dc234c02378124
Command: cargo test --locked --test CP008_source_eligibility
   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
error[E0432]: unresolved import `data_sculptor_core::is_analyst_owned_csv_source_candidate`
 --> tests\CP008_source_eligibility.rs:7:5
  |
7 | use data_sculptor_core::is_analyst_owned_csv_source_candidate;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `is_analyst_owned_csv_source_candidate` in the root

For more information about this error, try `rustc --explain E0432`.
error: could not compile `data_sculptor_core` (test "CP008_source_eligibility") due to 1 previous error
Cargo exit code: 101

CP008 WASM Build - Day 066
Git HEAD: 3c512df519f3a2431b363e4c57dc234c02378124
Command: cargo build --locked --lib --target wasm32-unknown-unknown
   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.21s
Cargo exit code: 0

CP008 WHITESPACE EXCEPTION REVIEW - DAY 066
Full staged whitespace exit: 2
Rust source and tests exit: 0
Known archival warnings only: True
Original evidence preserved unchanged.
RESULT: PASS WITH DOCUMENTED ARCHIVAL EXCEPTION

Full staged diagnostic:
Evidence/CP-008/CP008_Precommit_Git_Review.txt:47: trailing whitespace.
+ 
Evidence/CP-008/CP008_Precommit_Git_Review.txt:77: trailing whitespace.
+ 

Rust source/test diagnostic:

CP009 FINAL STAGING REVIEW - DAY 066
Git HEAD: 346733a962192320e0d56271add15a47b6037b6b
Human acceptance: PENDING
Staged files before final report: 14
Staged paths:
Evidence/CP-009/CP009_Baseline_Test_Output.txt
Evidence/CP-009/CP009_Full_Regression_Test_Output.txt
Evidence/CP-009/CP009_GREEN_Test_Output.txt
Evidence/CP-009/CP009_Git_Whitespace_Check.txt
Evidence/CP-009/CP009_Hash_Inventory.txt
Evidence/CP-009/CP009_Hash_Inventory_Verification.txt
Evidence/CP-009/CP009_Post_Format_Test_Output.txt
Evidence/CP-009/CP009_Precommit_Git_Review.txt
Evidence/CP-009/CP009_RED_Test_Output.txt
Evidence/CP-009/CP009_Rustfmt_Check_Output.txt
Evidence/CP-009/CP009_Rustfmt_Output.txt
Evidence/CP-009/CP009_WASM_Build_Output.txt
src/lib.rs
tests/CP009_exact_root_snapshot.rs
Final staged count: 15
Final whitespace exit code: 0

CP009 GREEN - Day 066
Git HEAD: 346733a962192320e0d56271add15a47b6037b6b
Command: cargo test --locked --test CP009_exact_root_snapshot
   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 1.18s
     Running tests\CP009_exact_root_snapshot.rs (target\debug\deps\CP009_exact_root_snapshot-b26a1b02e36e8f07.exe)

running 8 tests
test candidate_preflight_runs_before_root_matching ... ok
test duplicate_exact_entries_refuse_instead_of_picking_first ... ok
test finds_one_exact_reported_regular_file ... ok
test full_filename_match_is_exact_and_case_sensitive ... ok
test never_trims_to_find_a_different_physical_name ... ok
test reported_non_regular_entries_do_not_pass ... ok
test result_is_order_independent_and_empty_snapshot_is_not_found ... ok
test unicode_scalar_sequence_is_not_normalized ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Cargo exit code: 0

CP009 SHA-256 INVENTORY - DAY 066
Git HEAD: 346733a962192320e0d56271add15a47b6037b6b
Records: 22
Recorded UTC: 2026-10-13T18:57:19Z
Path	SizeBytes	SHA256
Cargo.toml	89	6FAD50B667CBD473B2E6A8E7FE4E33BD788B4CF617505B9A08B88E9B684EFF25
Cargo.lock	162	BDB2BCD1BA65C0FFDABC7960B279978411113895E0CDAD12F4E2604E916BD9D8
rust-toolchain.toml	92	D02F2301203B36F8C98CF05DD8716E38064154631D7CC0D6D1A0313CC4098AF0
.gitattributes	109	978CF143947177C92114C50A5C68F24B6E9818597AA64788406884E116EC5A0B
src\lib.rs	10093	F9CB47F97B7A29D10E8B5CF86164260223A92454C643E0AA74BA13B12FA8B096
tests\CP008_source_eligibility.rs	2189	298768A861A9BB1A1AF9822C8F5883B9C8E87981BAA13BCD88F6A83DFBB628B7
tests\CP009_exact_root_snapshot.rs	4389	1FB3D0CB0C1098F204A8BFC039A73ABD594C0AAD2D6E2D00DF68AA10471A4057
tests\artifact_class_disposition.rs	1834	B5956A618DA5F70495EF6E3CED1E6DC5B1A4A0EA283B2AE2D2FB97F3803002C9
tests\artifact_filename_construction.rs	2872	EBBBE7DA74CA32959C0F851494FD0D6F72688D93708F91E37AE5082BA47B18E9
tests\artifact_filename_envelope.rs	1901	D407CA8874064A304EB381ED719B693EC6851088ECB20E654D099A96DCB3020A
tests\artifact_namespace.rs	2656	C908B49BB1B4C475A04901C3A70FCF45585079616DE869082D6EC0B357FD1249
tests\artifact_serialization_separation.rs	3003	3AC71FCD46A91BA471A53CA4A5DE945D91CC99E2E8E9FCAE3CB447FA75BD93D1
tests\artifact_utc_timestamp.rs	2019	C79937779E1022AA638F750D1F78DA1D6A6CE4A54DF52458BA83E18173EB9D20
Evidence\CP-009\CP009_Baseline_Test_Output.txt	3820	9A2565D0DBB3EAF86D535F8FB1CC59D6259433994F3AC682E47A3568FF54ACBA
Evidence\CP-009\CP009_RED_Test_Output.txt	1094	16AF7F7D7FA68C4C6EB0DBB080E7F0AA3DD052DCD493B444AEE78C931EE6E49A
Evidence\CP-009\CP009_GREEN_Test_Output.txt	1017	9B747B3AA3BADF0B22E24DFC8D0A49B80B26345D5A2940D6B525ECA91E88F492
Evidence\CP-009\CP009_Full_Regression_Test_Output.txt	4653	484B7C29888277244BA4505958976D20869531D07F129F551DE1EA15819B3A6F
Evidence\CP-009\CP009_Rustfmt_Output.txt	22	82DE1C5C5AB0B5AAF4DEB809819EDD78DCF050C8BB6785FC099A26FAB1BC7070
Evidence\CP-009\CP009_Rustfmt_Check_Output.txt	28	237E14061B55413CB450524444BF6800A6645E843A9AE7345A9AF6F5D60E8F73
Evidence\CP-009\CP009_Git_Whitespace_Check.txt	29	CC865565B54FA8101F27DCB91C40692DADA3F50F52C6B11A5CED0C71EBCA859C
Evidence\CP-009\CP009_Post_Format_Test_Output.txt	4660	E00462266C32F5B7CB0360D397A212B6F7D68899052F1C3372C6AD0E4E1B1A68
Evidence\CP-009\CP009_WASM_Build_Output.txt	328	4485CBC9F1E288870DFD78318B9B0A9E8716788CBC4366EF2F0D7B6B92E903A6

CP009 INDEPENDENT SHA-256 VERIFICATION - DAY 066
Git HEAD: 346733a962192320e0d56271add15a47b6037b6b
Inventory SHA-256: E0905659695747F7F91C33D7BE6C18E8802D80C8C482961165FCA4F7E39B9E1B
Records: 22
Matched: 22
Issues: 0
RESULT: PASS

CP009 POST-FORMAT NATIVE REGRESSION - DAY 066
Git HEAD: 346733a962192320e0d56271add15a47b6037b6b
Command: cargo test --locked
   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.39s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP008_source_eligibility.rs (target\debug\deps\CP008_source_eligibility-194c314726b26929.exe)

running 5 tests
test accepts_analyst_csv_final_extension_in_ascii_case_variants ... ok
test makes_no_case_or_unicode_normalization_claim ... ok
test refuses_paths_traversal_and_external_references ... ok
test refuses_reserved_namespace_even_if_name_looks_like_csv ... ok
test rejects_non_csv_or_nonfinal_csv_extensions ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP009_exact_root_snapshot.rs (target\debug\deps\CP009_exact_root_snapshot-b26a1b02e36e8f07.exe)

running 8 tests
test candidate_preflight_runs_before_root_matching ... ok
test duplicate_exact_entries_refuse_instead_of_picking_first ... ok
test finds_one_exact_reported_regular_file ... ok
test full_filename_match_is_exact_and_case_sensitive ... ok
test never_trims_to_find_a_different_physical_name ... ok
test reported_non_regular_entries_do_not_pass ... ok
test unicode_scalar_sequence_is_not_normalized ... ok
test result_is_order_independent_and_empty_snapshot_is_not_found ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)

running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_registered_emittable_classes ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)

running 4 tests
test constructs_exact_canonical_filename_candidates ... ok
test preserves_extension_without_case_or_unicode_normalization ... ok
test refuses_invalid_timestamp_uuid_and_empty_extension ... ok
test refuses_noncanonical_class_without_repair ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)

running 3 tests
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)

running 6 tests
test recognizes_governed_namespace_and_class ... ok
test rejects_invalid_class_boundaries ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)

running 4 tests
test extension_does_not_determine_semantic_class ... ok
test extracts_semantic_class_and_serialization_separately ... ok
test preserves_literal_tokens_without_claiming_authority ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

running 3 tests
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_nonexistent_gregorian_dates ... ok
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests data_sculptor_core

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Cargo exit code: 0

CP009 RED - Day 066
Git HEAD: 346733a962192320e0d56271add15a47b6037b6b
   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
error[E0432]: unresolved imports `data_sculptor_core::match_analyst_csv_root_snapshot`, `data_sculptor_core::RootSnapshotEntry`, `data_sculptor_core::RootSnapshotEntryKind`, `data_sculptor_core::RootSnapshotMatch`
  --> tests\CP009_exact_root_snapshot.rs:9:5
   |
 9 |     match_analyst_csv_root_snapshot, RootSnapshotEntry, RootSnapshotEntryKind,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^ no `RootSnapshotEntryKind` in the root
   |     |                                |
   |     |                                no `RootSnapshotEntry` in the root
   |     no `match_analyst_csv_root_snapshot` in the root
10 |     RootSnapshotMatch,
   |     ^^^^^^^^^^^^^^^^^ no `RootSnapshotMatch` in the root

For more information about this error, try `rustc --explain E0432`.
error: could not compile `data_sculptor_core` (test "CP009_exact_root_snapshot") due to 1 previous error
Cargo exit code: 101

CP009 WASM BUILD - DAY 066
Git HEAD: 346733a962192320e0d56271add15a47b6037b6b
Command: cargo build --locked --lib --target wasm32-unknown-unknown
   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.46s
Cargo exit code: 0

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.97s
     Running tests\CP010_cvt_filename_candidate.rs (target\debug\deps\CP010_cvt_filename_candidate-ce216c0140f6b173.exe)

running 4 tests
test accepts_exact_canonical_cvt_csv_candidate ... ok
test refuses_malformed_canonical_identity ... ok
test refuses_wrong_classes_and_extensions ... ok
test refuses_paths_and_noncanonical_references ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

CARGO_EXIT_CODE=0
EXPECTED_FOUR_TESTS_PASS=True

CP010 INDEPENDENT SHA-256 VERIFICATION - DAY 066
Git HEAD: dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8
INVENTORY_SHA256=E720BBEC3D8701C5CE79C1CC7BCD548A80339B295849C95ACDB885F2066E46F3
INVENTORY_RECORDS=29
VERIFIED_RECORDS=29
ISSUES=0
RESULT=PASS
=== VERIFIED FILES ===
PASS	.gitattributes	109	978CF143947177C92114C50A5C68F24B6E9818597AA64788406884E116EC5A0B
PASS	Cargo.lock	162	BDB2BCD1BA65C0FFDABC7960B279978411113895E0CDAD12F4E2604E916BD9D8
PASS	Cargo.toml	89	6FAD50B667CBD473B2E6A8E7FE4E33BD788B4CF617505B9A08B88E9B684EFF25
PASS	Evidence\CP-010\CP010_Full_Regression_Test_Output.txt	5035	4C2BB86F2CF5E094E5175E854AA5806FEDE52ADE0AA5C5DA01ABB0B33F9F43D8
PASS	Evidence\CP-010\CP010_GREEN_Implementation_Review.txt	1098	EFC1F3ACF401686FEBD6A4255B6E01F75533890F9385A34FED2CC06935F8D7D5
PASS	Evidence\CP-010\CP010_GREEN_Test_Output.txt	650	FF9CBAAC145C25AC965C7F1EE195A240DB1073BBC330CA0EF504E85EBA3CCA24
PASS	Evidence\CP-010\CP010_Hash_Inventory.txt	3299	E88CC4E4A68F0CBC636F378C14A2A8CA660C6EBA6B091899D3A41A48341FC887
PASS	Evidence\CP-010\CP010_Post_Format_Check_Output.txt	176	C93F5B1882AF4558B5BA958C92B3E6D3C9BCDB0CE69D36AB03655BAEC55B459B
PASS	Evidence\CP-010\CP010_Post_Format_Regression_Test_Output.txt	5058	C0F139521C96C1140807C130B828BD98F1AAAB10D44F2C92CC98FA6FD81275DD
PASS	Evidence\CP-010\CP010_RED_Test_Output.txt	1942	23305D1555ED55B4170CCE4E42FBAA896B91C3262EB6609AD38BC2802A95E0D7
PASS	Evidence\CP-010\CP010_RED_Test_Output_CMD_Corrected.txt	665	2C5A0BB6C9572DD68FF406496FFE573A29AA7F1ACB974AA106F9AEBF1B4E2846
PASS	Evidence\CP-010\CP010_Rust_Toolchain_Verification.txt	258	FD3FB1ACA08D9B8E88E8CE7F9EE67254B86DC83A5FC33FC501069CAA09EE86D4
PASS	Evidence\CP-010\CP010_Rustfmt_Application_Output.txt	366	D5B069EAB5FF80EC456916D4A858510EACD8485D8E698442896A7D3381197140
PASS	Evidence\CP-010\CP010_Rustfmt_Check_Output.txt	680	6FA7F0809C994308A6EAF0A9173D2B1FBE0C4497BE085742D9A95A41A9544E34
PASS	Evidence\CP-010\CP010_Scope_Lock.txt	752	3F437224A1E4426B0BF8C47E3790E99AC82C3A1C6FA3BB6B875692DFC7A78A33
PASS	Evidence\CP-010\CP010_Starting_State.txt	17369	6BBA8F9C452EE46BD8A058736E4A461B01DC6D433378B8274E2C58992955A921
PASS	Evidence\CP-010\CP010_Test_PreFormat_Snapshot.txt	2175	C066AD3AAA20D8C355C24D4F749239A0649DAD4396953402A03E7B788EDE994D
PASS	Evidence\CP-010\CP010_WASM_Build_Output.txt	232	76C9E71484A1BCF555225EB16F13838FF2840FB408F4400A59993050400D0894
PASS	rust-toolchain.toml	92	D02F2301203B36F8C98CF05DD8716E38064154631D7CC0D6D1A0313CC4098AF0
PASS	src\lib.rs	10589	C6C8DFF08B0A6DD76FEF141441A36D46BAC5CC4244A3D89D5A145E10AD9A20EA
PASS	tests\artifact_class_disposition.rs	1834	B5956A618DA5F70495EF6E3CED1E6DC5B1A4A0EA283B2AE2D2FB97F3803002C9
PASS	tests\artifact_filename_construction.rs	2872	EBBBE7DA74CA32959C0F851494FD0D6F72688D93708F91E37AE5082BA47B18E9
PASS	tests\artifact_filename_envelope.rs	1901	D407CA8874064A304EB381ED719B693EC6851088ECB20E654D099A96DCB3020A
PASS	tests\artifact_namespace.rs	2656	C908B49BB1B4C475A04901C3A70FCF45585079616DE869082D6EC0B357FD1249
PASS	tests\artifact_serialization_separation.rs	3003	3AC71FCD46A91BA471A53CA4A5DE945D91CC99E2E8E9FCAE3CB447FA75BD93D1
PASS	tests\artifact_utc_timestamp.rs	2019	C79937779E1022AA638F750D1F78DA1D6A6CE4A54DF52458BA83E18173EB9D20
PASS	tests\CP008_source_eligibility.rs	2189	298768A861A9BB1A1AF9822C8F5883B9C8E87981BAA13BCD88F6A83DFBB628B7
PASS	tests\CP009_exact_root_snapshot.rs	4389	1FB3D0CB0C1098F204A8BFC039A73ABD594C0AAD2D6E2D00DF68AA10471A4057
PASS	tests\CP010_cvt_filename_candidate.rs	2172	A666B9BF200376CCCD330602CEF1121817E0D1343F72492D513DE9715E4C9C3F
=== ISSUES ===

RUSTFMT_EXIT_CODE=0
LIB_SHA256=C6C8DFF08B0A6DD76FEF141441A36D46BAC5CC4244A3D89D5A145E10AD9A20EA
TEST_SHA256=A666B9BF200376CCCD330602CEF1121817E0D1343F72492D513DE9715E4C9C3F

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.38s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP008_source_eligibility.rs (target\debug\deps\CP008_source_eligibility-194c314726b26929.exe)

running 5 tests
test makes_no_case_or_unicode_normalization_claim ... ok
test accepts_analyst_csv_final_extension_in_ascii_case_variants ... ok
test refuses_paths_traversal_and_external_references ... ok
test refuses_reserved_namespace_even_if_name_looks_like_csv ... ok
test rejects_non_csv_or_nonfinal_csv_extensions ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP009_exact_root_snapshot.rs (target\debug\deps\CP009_exact_root_snapshot-b26a1b02e36e8f07.exe)

running 8 tests
test candidate_preflight_runs_before_root_matching ... ok
test duplicate_exact_entries_refuse_instead_of_picking_first ... ok
test finds_one_exact_reported_regular_file ... ok
test full_filename_match_is_exact_and_case_sensitive ... ok
test never_trims_to_find_a_different_physical_name ... ok
test reported_non_regular_entries_do_not_pass ... ok
test result_is_order_independent_and_empty_snapshot_is_not_found ... ok
test unicode_scalar_sequence_is_not_normalized ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP010_cvt_filename_candidate.rs (target\debug\deps\CP010_cvt_filename_candidate-ce216c0140f6b173.exe)

running 4 tests
test refuses_malformed_canonical_identity ... ok
test refuses_wrong_classes_and_extensions ... ok
test accepts_exact_canonical_cvt_csv_candidate ... ok
test refuses_paths_and_noncanonical_references ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)

running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_registered_emittable_classes ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)

running 4 tests
test constructs_exact_canonical_filename_candidates ... ok
test preserves_extension_without_case_or_unicode_normalization ... ok
test refuses_noncanonical_class_without_repair ... ok
test refuses_invalid_timestamp_uuid_and_empty_extension ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)

running 3 tests
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)

running 6 tests
test recognizes_governed_namespace_and_class ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_invalid_class_boundaries ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)

running 4 tests
test extension_does_not_determine_semantic_class ... ok
test preserves_literal_tokens_without_claiming_authority ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok
test extracts_semantic_class_and_serialization_separately ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

running 3 tests
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_nonexistent_gregorian_dates ... ok
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests data_sculptor_core

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

CARGO_EXIT_CODE=0
TOTAL_TESTS_PASSED=40
TOTAL_TESTS_FAILED=0
CP010_PRESENT=True
RUST_TOOLCHAIN=1.97.1

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
error[E0432]: unresolved import `data_sculptor_core::is_governed_cvt_source_filename_candidate`
 --> tests\CP010_cvt_filename_candidate.rs:8:5
  |
8 | use data_sculptor_core::is_governed_cvt_source_filename_candidate;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `is_governed_cvt_source_filename_candidate` in the root

For more information about this error, try `rustc --explain E0432`.
error: could not compile `data_sculptor_core` (test "CP010_cvt_filename_candidate") due to 1 previous error
CARGO_EXIT_CODE=101
EXPECTED_UNRESOLVED_IMPORT=True

Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP010_cvt_filename_candidate.rs:7:
 
 use data_sculptor_core::is_governed_cvt_source_filename_candidate;
 
-const VALID: &str =
-    "__DS__CVT__20261012T213045123Z__b6f032e5-527e-4cdf-9951-2f1bb72ffaca.csv";
+const VALID: &str = "__DS__CVT__20261012T213045123Z__b6f032e5-527e-4cdf-9951-2f1bb72ffaca.csv";
 
 #[test]
 fn accepts_exact_canonical_cvt_csv_candidate() {
Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP010_cvt_filename_candidate.rs:54:
         assert!(!is_governed_cvt_source_filename_candidate(name), "{name:?}");
     }
 }
+
RUSTFMT_EXIT_CODE=1

Evidence/CP-010/CP010_Rustfmt_Check_Output.txt:2: trailing whitespace.
+ 
Evidence/CP-010/CP010_Rustfmt_Check_Output.txt:4: trailing whitespace.
+ 
Evidence/CP-010/CP010_Rustfmt_Check_Output.txt:8: trailing whitespace.
+ 
Evidence/CP-010/CP010_Starting_State.txt:567: new blank line at EOF.
GIT_WHITESPACE_EXIT_CODE=2
STAGED_FILES=21
REMEDIATION=NOT YET PERFORMED

CP010 SUPPLEMENTARY SHA-256 VERIFICATION - DAY 066
GIT_HEAD=dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8
INVENTORY_SHA256=8C4018368D5588080D5668657FE1EE8F2C1ABFA8FDE96C49B9CB2CA262DA22F1
VERIFIED_RECORDS=8
ISSUES=0
RESULT=PASS
=== VERIFIED FILES ===
PASS	Evidence\CP-010\.gitattributes	03A3098E416C16E4763584EE84E2E9C7335D68A0E3DA8C4716C762B96FF78771
PASS	Evidence\CP-010\CP010_Hash_Inventory_Corrected.txt	E720BBEC3D8701C5CE79C1CC7BCD548A80339B295849C95ACDB885F2066E46F3
PASS	Evidence\CP-010\CP010_Hash_Inventory_Verification.txt	31B16867751E000687AE428DEF0742532664C094B58D049996595A6F9C4EDBBA
PASS	Evidence\CP-010\CP010_Precommit_Git_Review.txt	D0DBE0EFFB8A1E5E2556C39EC06760A0E306A08911DAA85A87F160A859266C5D
PASS	Evidence\CP-010\CP010_Final_Staging_Review.txt	55D599D347C47DBFA1E6D9ACEA3B589C07B29F9004015F7903662A88E8011218
PASS	Evidence\CP-010\CP010_Staged_Whitespace_Diagnostic.txt	7FC258D4B0ACE3CBEF65ADA72248BFA3A0C58F8ECA17FC2DCA228496023EFD47
PASS	Evidence\CP-010\CP010_Whitespace_Exception_Review.txt	CF8F85B5B77CB61DAC97818B1C74886E90E037A46969EDD0C584A9D9F3EF24EE
PASS	Evidence\CP-010\CP010_Whitespace_Followup_Verification.txt	74BB6C31EC68C421096F417FDD83A28D47A303DA25BD15585E767E6A69AC3674
=== ISSUES ===

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.35s
CARGO_EXIT_CODE=0
RUST_TOOLCHAIN=1.97.1
TARGET=wasm32-unknown-unknown

CP010 WHITESPACE FOLLOW-UP VERIFICATION - DAY 066
GIT_HEAD=dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8
PREVIOUS_WHITESPACE_EXIT_CODE=2
REMEDIATION=THIRD_FILE_SPECIFIC_EXCEPTION
DIAGNOSTIC_SHA256=7FC258D4B0ACE3CBEF65ADA72248BFA3A0C58F8ECA17FC2DCA228496023EFD47
DIAGNOSTIC_ATTRIBUTE=Evidence/CP-010/CP010_Staged_Whitespace_Diagnostic.txt: whitespace: -blank-at-eol
HISTORICAL_EVIDENCE_UNCHANGED=True
RUST_SOURCE_AND_TESTS_UNCHANGED=True
GIT_WHITESPACE_EXIT_CODE=0
HUMAN_ACCEPTANCE=PENDING
GIT_COMMIT=NOT_PERFORMED

# CP011 historical raw Rustfmt diagnostic exception only.
# Preserve original evidence bytes and SHA-256 integrity.
CP011_Rustfmt_Check_Output.txt whitespace=-blank-at-eol
CP011_Staged_Whitespace_Diagnostic.txt whitespace=-blank-at-eol

CP011 CLOSING GIT REVIEW - DAY 066
GIT_HEAD=b7c515faa9bd000369d7656e09437310261290ae
BRANCH=master
STAGED_BEFORE_CLOSING=26
EXPECTED_STAGED_BEFORE_CLOSING=26
RUST_INDEX_BLOBS_MATCH=True
GIT_DIFF_CACHED_CHECK_EXIT=0
SOURCE_SHA256=8D856818070BE87AF353D92876A84FBF43EE42E2A3D08524734F0DB7D5240A19
TEST_SHA256=83534850CC916B8CA98173D65BB683EE06E792BFDDC35E335CACD5F935F0E82E
ORIGINAL_AND_SUPPLEMENTARY_HASH_VERIFICATION=36_PASS_0_ISSUES
POST_FORMAT_NATIVE_REGRESSION=46_PASS_0_FAIL
CANONICAL_WASM_BUILD=PASS
RUSTFMT_RECHECK=PASS
CLOSING_REVIEW_RECORD=CREATED_FOR_STAGING
GIT_COMMIT=NOT_PERFORMED
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

=== STAGED FILES BEFORE CLOSING REVIEW ===
Evidence/CP-011/.gitattributes
Evidence/CP-011/CP011_Final_Staging_Review.txt
Evidence/CP-011/CP011_Full_Regression_Test_Output.txt
Evidence/CP-011/CP011_GREEN_Source_Change.txt
Evidence/CP-011/CP011_GREEN_Test_Output.txt
Evidence/CP-011/CP011_Hash_Inventory.txt
Evidence/CP-011/CP011_Hash_Inventory_Verification.txt
Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt
Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt
Evidence/CP-011/CP011_Precommit_Git_Review.txt
Evidence/CP-011/CP011_Preformat_Test_Snapshot.txt
Evidence/CP-011/CP011_RED_Test_Output.txt
Evidence/CP-011/CP011_Rustfmt_Apply_Output.txt
Evidence/CP-011/CP011_Rustfmt_Check_Output.txt
Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt
Evidence/CP-011/CP011_Scope_Lock.txt
Evidence/CP-011/CP011_Staged_Whitespace_Diagnostic.txt
Evidence/CP-011/CP011_Staging_Recovery_Review.txt
Evidence/CP-011/CP011_Starting_State.txt
Evidence/CP-011/CP011_Supplementary_Hash_Inventory.txt
Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt
Evidence/CP-011/CP011_Supplementary_Staging_Review.txt
Evidence/CP-011/CP011_WASM_Build_Output.txt
Evidence/CP-011/CP011_Whitespace_Exception_Review.txt
src/lib.rs
tests/CP011_cvt_scr_candidate_identity.rs

=== STAGED RUST DIFF ===
diff --git a/src/lib.rs b/src/lib.rs
index 715a1c1..e08d25b 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -329,3 +329,15 @@ pub fn is_governed_cvt_source_filename_candidate(filename: &str) -> bool {
                 && tokens.serialization_extension == "csv"
     )
 }
+
+/// Derives the SCR staging filename candidate corresponding to a canonical CVT.
+///
+/// Lexical construction only. This grants no filesystem, conversion,
+/// publication, or SOURCE authority.
+pub fn build_scr_candidate_filename_for_cvt(filename: &str) -> Option<String> {
+    if !is_governed_cvt_source_filename_candidate(filename) {
+        return None;
+    }
+
+    Some(filename.replacen("__DS__CVT__", "__DS__SCR__", 1))
+}
diff --git a/tests/CP011_cvt_scr_candidate_identity.rs b/tests/CP011_cvt_scr_candidate_identity.rs
new file mode 100644
index 0000000..bd21f27
--- /dev/null
+++ b/tests/CP011_cvt_scr_candidate_identity.rs
@@ -0,0 +1,74 @@
+// CP011 RED tests - Day 066
+// W002-CONV-004 and W002-STOR-023.1 (partial).
+// Pure lexical CVT-to-SCR candidate identity only.
+// No conversion, publication, filesystem authority, or recovery.
+
+use data_sculptor_core::build_scr_candidate_filename_for_cvt;
+
+const CVT: &str = "__DS__CVT__20261013T173300000Z__123e4567-e89b-42d3-a456-426614174000.csv";
+const SCR: &str = "__DS__SCR__20261013T173300000Z__123e4567-e89b-42d3-a456-426614174000.csv";
+
+#[test]
+fn derives_exact_corresponding_scr_identity() {
+    assert_eq!(
+        build_scr_candidate_filename_for_cvt(CVT),
+        Some(SCR.to_string())
+    );
+}
+
+#[test]
+fn preserves_distinct_timestamp_and_uuid_tokens() {
+    let final_name = "__DS__CVT__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.csv";
+    let staged_name = "__DS__SCR__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.csv";
+
+    assert_eq!(
+        build_scr_candidate_filename_for_cvt(final_name),
+        Some(staged_name.to_string())
+    );
+    assert_ne!(staged_name, SCR);
+}
+
+#[test]
+fn refuses_other_semantic_classes() {
+    for class in ["SCR", "RCP", "CAT", "MAP", "COL"] {
+        let filename = CVT.replacen("__DS__CVT__", &format!("__DS__{class}__"), 1);
+        assert_eq!(build_scr_candidate_filename_for_cvt(&filename), None);
+    }
+}
+
+#[test]
+fn refuses_wrong_extension_and_case() {
+    for filename in [
+        CVT.replace(".csv", ".CSV"),
+        CVT.replace(".csv", ".txt"),
+        CVT.replacen("__DS__CVT__", "__DS__cvt__", 1),
+        CVT.replacen("__DS__CVT__", "__DS__Cvt__", 1),
+    ] {
+        assert_eq!(build_scr_candidate_filename_for_cvt(&filename), None);
+    }
+}
+
+#[test]
+fn refuses_invalid_utc_and_uuid() {
+    for filename in [
+        CVT.replace("20261013", "20260230"),
+        CVT.replace("T173300000Z", "T253300000Z"),
+        CVT.replace("-42d3-", "-52d3-"),
+        CVT.replace("-a456-", "-7456-"),
+    ] {
+        assert_eq!(build_scr_candidate_filename_for_cvt(&filename), None);
+    }
+}
+
+#[test]
+fn refuses_paths_whitespace_and_noncanonical_names() {
+    for filename in [
+        format!("folder/{CVT}"),
+        format!("folder\\{CVT}"),
+        format!(" {CVT}"),
+        format!("{CVT} "),
+        CVT.replace("__DS__CVT__", "__DS__CVT_"),
+    ] {
+        assert_eq!(build_scr_candidate_filename_for_cvt(&filename), None);
+    }
+}

=== FINAL CP011 GIT VERIFICATION ===
FINAL_STAGED_FILES=27
EXPECTED_FINAL_STAGED_FILES=27
FINAL_WHITESPACE_EXIT_CODE=0
UNSTAGED_TRACKED_FILES=0
UNTRACKED_FILES=0
CLOSING_GIT_REVIEW_PASS=True
GIT_COMMIT=NOT_PERFORMED
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 1.18s
     Running tests\CP011_cvt_scr_candidate_identity.rs (target\debug\deps\CP011_cvt_scr_candidate_identity-8bc68fabbbb42eb4.exe)

running 6 tests
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_invalid_utc_and_uuid ... ok
test derives_exact_corresponding_scr_identity ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_whitespace_and_noncanonical_names ... ok
test refuses_wrong_extension_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


=== CP011 GREEN VERIFICATION ===
CARGO_EXIT_CODE=0
SIX_TESTS_PASSED=True
GIT_HEAD=b7c515faa9bd000369d7656e09437310261290ae
SOURCE_SHA256=8D856818070BE87AF353D92876A84FBF43EE42E2A3D08524734F0DB7D5240A19
TEST_SHA256=9ACEFDD5E135C415BE9E803AAD78EB6A18C00377DFB74D0DB8022B1E3289877F
RED_EVIDENCE=PRESERVED
FULL_REGRESSION=NOT_YET_RUN
WASM_BUILD=NOT_YET_RUN
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

CP011 INDEPENDENT SHA-256 VERIFICATION - DAY 066
GIT_HEAD=b7c515faa9bd000369d7656e09437310261290ae
INVENTORY_SHA256=EEAEBAB9E3AA43BA8A5D38EB1ED7B5C77A65DB64D63940C55A846426B170D564
INVENTORY_RECORDS=28
ACTUAL_SCOPED_FILES=28
FILES_VERIFIED=28
ISSUES=0
ALL_HASHES_AND_SIZES_MATCH=True
INDEPENDENT_VERIFICATION_PASS=True
GIT_REVIEW=PENDING
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

=== VERIFICATION ISSUES ===
NONE

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.70s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP008_source_eligibility.rs (target\debug\deps\CP008_source_eligibility-194c314726b26929.exe)

running 5 tests
test accepts_analyst_csv_final_extension_in_ascii_case_variants ... ok
test refuses_reserved_namespace_even_if_name_looks_like_csv ... ok
test refuses_paths_traversal_and_external_references ... ok
test makes_no_case_or_unicode_normalization_claim ... ok
test rejects_non_csv_or_nonfinal_csv_extensions ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP009_exact_root_snapshot.rs (target\debug\deps\CP009_exact_root_snapshot-b26a1b02e36e8f07.exe)

running 8 tests
test duplicate_exact_entries_refuse_instead_of_picking_first ... ok
test candidate_preflight_runs_before_root_matching ... ok
test finds_one_exact_reported_regular_file ... ok
test full_filename_match_is_exact_and_case_sensitive ... ok
test never_trims_to_find_a_different_physical_name ... ok
test reported_non_regular_entries_do_not_pass ... ok
test result_is_order_independent_and_empty_snapshot_is_not_found ... ok
test unicode_scalar_sequence_is_not_normalized ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP010_cvt_filename_candidate.rs (target\debug\deps\CP010_cvt_filename_candidate-ce216c0140f6b173.exe)

running 4 tests
test accepts_exact_canonical_cvt_csv_candidate ... ok
test refuses_malformed_canonical_identity ... ok
test refuses_paths_and_noncanonical_references ... ok
test refuses_wrong_classes_and_extensions ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP011_cvt_scr_candidate_identity.rs (target\debug\deps\CP011_cvt_scr_candidate_identity-8bc68fabbbb42eb4.exe)

running 6 tests
test derives_exact_corresponding_scr_identity ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_whitespace_and_noncanonical_names ... ok
test refuses_wrong_extension_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)

running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok
test distinguishes_registered_emittable_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)

running 4 tests
test constructs_exact_canonical_filename_candidates ... ok
test preserves_extension_without_case_or_unicode_normalization ... ok
test refuses_noncanonical_class_without_repair ... ok
test refuses_invalid_timestamp_uuid_and_empty_extension ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)

running 3 tests
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)

running 6 tests
test recognizes_governed_namespace_and_class ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_invalid_class_boundaries ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)

running 4 tests
test extension_does_not_determine_semantic_class ... ok
test preserves_literal_tokens_without_claiming_authority ... ok
test extracts_semantic_class_and_serialization_separately ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

running 3 tests
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_nonexistent_gregorian_dates ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests data_sculptor_core

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


=== CP011 POST-FORMAT REGRESSION VERIFICATION ===
CARGO_EXIT_CODE=0
TEST_RESULT_GROUPS=12
TOTAL_TESTS_PASSED=46
TOTAL_TESTS_FAILED=0
CP011_SIX_TESTS_PASS=True
POST_FORMAT_REGRESSION_PASS=True
SOURCE_AND_TEST_HASHES_UNCHANGED=True
SOURCE_SHA256=8D856818070BE87AF353D92876A84FBF43EE42E2A3D08524734F0DB7D5240A19
TEST_SHA256=83534850CC916B8CA98173D65BB683EE06E792BFDDC35E335CACD5F935F0E82E
GIT_HEAD=b7c515faa9bd000369d7656e09437310261290ae
RUSTFMT_RECHECK=PASS
ORIGINAL_REGRESSION_EVIDENCE=PRESERVED
POST_FORMAT_WASM_BUILD=PENDING
FINAL_SHA256_VERIFICATION=PENDING
GIT_REVIEW=PENDING
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.01s

=== CP011 CANONICAL POST-FORMAT WASM BUILD ===
CARGO_EXIT_CODE=0
RUST_TOOLCHAIN=1.97.1
TARGET=wasm32-unknown-unknown
BUILD_MODE=LIB_ONLY
POST_FORMAT_WASM_BUILD_PASS=True
SOURCE_AND_TEST_HASHES_UNCHANGED=True
SOURCE_SHA256=8D856818070BE87AF353D92876A84FBF43EE42E2A3D08524734F0DB7D5240A19
TEST_SHA256=83534850CC916B8CA98173D65BB683EE06E792BFDDC35E335CACD5F935F0E82E
GIT_HEAD=b7c515faa9bd000369d7656e09437310261290ae
POST_FORMAT_NATIVE_REGRESSION=46_PASS_0_FAIL
RUSTFMT_RECHECK=PASS
ORIGINAL_WASM_EVIDENCE=PRESERVED
FINAL_SHA256_VERIFICATION=PENDING
GIT_REVIEW=PENDING
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
error[E0432]: unresolved import `data_sculptor_core::build_scr_candidate_filename_for_cvt`
 --> tests\CP011_cvt_scr_candidate_identity.rs:6:5
  |
6 | use data_sculptor_core::build_scr_candidate_filename_for_cvt;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `build_scr_candidate_filename_for_cvt` in the root

For more information about this error, try `rustc --explain E0432`.
error: could not compile `data_sculptor_core` (test "CP011_cvt_scr_candidate_identity") due to 1 previous error

=== CP011 RED VERIFICATION ===
CARGO_EXIT_CODE=101
EXPECTED_MISSING_FUNCTION_RED=True
GIT_HEAD=b7c515faa9bd000369d7656e09437310261290ae
SOURCE_SHA256=C6C8DFF08B0A6DD76FEF141441A36D46BAC5CC4244A3D89D5A145E10AD9A20EA
TEST_SHA256=9ACEFDD5E135C415BE9E803AAD78EB6A18C00377DFB74D0DB8022B1E3289877F
PRODUCTION_SOURCE_MODIFIED=NO
DAY_066_STATUS=OPEN

=== CP011 CONTROLLED RUSTFMT APPLICATION ===
RUSTFMT_EXIT_CODE=0
GIT_HEAD=b7c515faa9bd000369d7656e09437310261290ae
SOURCE_SHA256_BEFORE=8D856818070BE87AF353D92876A84FBF43EE42E2A3D08524734F0DB7D5240A19
SOURCE_SHA256_AFTER=8D856818070BE87AF353D92876A84FBF43EE42E2A3D08524734F0DB7D5240A19
TEST_SHA256_BEFORE=9ACEFDD5E135C415BE9E803AAD78EB6A18C00377DFB74D0DB8022B1E3289877F
TEST_SHA256_AFTER=83534850CC916B8CA98173D65BB683EE06E792BFDDC35E335CACD5F935F0E82E
PREFORMAT_SNAPSHOT_SHA256=9ACEFDD5E135C415BE9E803AAD78EB6A18C00377DFB74D0DB8022B1E3289877F
RUST_FILES_CHANGED=1
ONLY_EXPECTED_TEST_CHANGED=True
ORIGINAL_FORMAT_DIAGNOSTIC=PRESERVED
RUSTFMT_RECHECK=PENDING
POST_FORMAT_REGRESSION=PENDING
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN
=== CHANGED RUST FILES ===
C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP011_cvt_scr_candidate_identity.rs

Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP011_cvt_scr_candidate_identity.rs:5:
 
 use data_sculptor_core::build_scr_candidate_filename_for_cvt;
 
-const CVT: &str =
-    "__DS__CVT__20261013T173300000Z__123e4567-e89b-42d3-a456-426614174000.csv";
-const SCR: &str =
-    "__DS__SCR__20261013T173300000Z__123e4567-e89b-42d3-a456-426614174000.csv";
+const CVT: &str = "__DS__CVT__20261013T173300000Z__123e4567-e89b-42d3-a456-426614174000.csv";
+const SCR: &str = "__DS__SCR__20261013T173300000Z__123e4567-e89b-42d3-a456-426614174000.csv";
 
 #[test]
 fn derives_exact_corresponding_scr_identity() {
Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP011_cvt_scr_candidate_identity.rs:20:
 
 #[test]
 fn preserves_distinct_timestamp_and_uuid_tokens() {
-    let final_name =
-        "__DS__CVT__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.csv";
-    let staged_name =
-        "__DS__SCR__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.csv";
+    let final_name = "__DS__CVT__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.csv";
+    let staged_name = "__DS__SCR__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.csv";
 
     assert_eq!(
         build_scr_candidate_filename_for_cvt(final_name),
Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP011_cvt_scr_candidate_identity.rs:76:
         assert_eq!(build_scr_candidate_filename_for_cvt(&filename), None);
     }
 }
+

=== CP011 RUSTFMT CHECK VERIFICATION ===
CARGO_EXIT_CODE=1
RUSTFMT_CHECK_PASS=False
SOURCE_AND_TEST_HASHES_UNCHANGED=True
SOURCE_SHA256=8D856818070BE87AF353D92876A84FBF43EE42E2A3D08524734F0DB7D5240A19
TEST_SHA256=9ACEFDD5E135C415BE9E803AAD78EB6A18C00377DFB74D0DB8022B1E3289877F
GIT_HEAD=b7c515faa9bd000369d7656e09437310261290ae
FULL_NATIVE_REGRESSION=46_PASS_0_FAIL
WASM_BUILD=PASS
FINAL_SHA256_VERIFICATION=PENDING
GIT_REVIEW=PENDING
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

=== CP011 RUSTFMT RECHECK VERIFICATION ===
RUSTFMT_EXIT_CODE=0
RUSTFMT_RECHECK_PASS=True
SOURCE_AND_TEST_HASHES_UNCHANGED=True
SOURCE_SHA256=8D856818070BE87AF353D92876A84FBF43EE42E2A3D08524734F0DB7D5240A19
TEST_SHA256=83534850CC916B8CA98173D65BB683EE06E792BFDDC35E335CACD5F935F0E82E
GIT_HEAD=b7c515faa9bd000369d7656e09437310261290ae
ORIGINAL_FORMAT_FAILURE=PRESERVED
CONTROLLED_FORMAT_APPLICATION=PRESERVED
POST_FORMAT_REGRESSION=PENDING
POST_FORMAT_WASM_BUILD=PENDING
FINAL_SHA256_VERIFICATION=PENDING
GIT_REVIEW=PENDING
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

CP011 SCOPE LOCK - DAY 066
Baseline HEAD: b7c515faa9bd000369d7656e09437310261290ae
Production source SHA256: C6C8DFF08B0A6DD76FEF141441A36D46BAC5CC4244A3D89D5A145E10AD9A20EA
Test file SHA256: 9ACEFDD5E135C415BE9E803AAD78EB6A18C00377DFB74D0DB8022B1E3289877F

FROZEN REQUIREMENTS
W002-CONV-004
W002-STOR-023.1

SCOPED INCREMENT
Pure lexical derivation of the SCR candidate filename
corresponding to one canonical governed CVT CSV filename.

EXPECTED PUBLIC FUNCTION
build_scr_candidate_filename_for_cvt(&str) -> Option<String>

INVARIANTS
Only the semantic class token changes: CVT to SCR.
UTC, UUID and lowercase .csv remain byte-identical.
Invalid or non-CVT input returns None.
No trimming, case folding or normalization.

OUT OF SCOPE
Conversion; byte writes; file close/reopen;
publication; physical verification; UTF-8 checking;
CSV certification; SOURCE authority; recovery;
retained-SCR adoption or automatic promotion.

ACCEPTANCE LIMIT
Lexical candidate derivation only.
No complete requirement acceptance.

RED STATUS
Six tests authored.
RED execution NOT YET PERFORMED.
Production source remains unchanged.
Day 066 remains OPEN.

Evidence/CP-011/CP011_Rustfmt_Check_Output.txt:2: trailing whitespace.
+ 
Evidence/CP-011/CP011_Rustfmt_Check_Output.txt:4: trailing whitespace.
+ 
Evidence/CP-011/CP011_Rustfmt_Check_Output.txt:11: trailing whitespace.
+ 
Evidence/CP-011/CP011_Rustfmt_Check_Output.txt:15: trailing whitespace.
+ 
Evidence/CP-011/CP011_Rustfmt_Check_Output.txt:24: trailing whitespace.
+ 

=== CP011 STAGED WHITESPACE DIAGNOSTIC ===
GIT_HEAD=b7c515faa9bd000369d7656e09437310261290ae
GIT_DIFF_CACHED_CHECK_EXIT=2
STAGED_FILES=18
EXPECTED_STAGED_PAYLOAD_FILES=18
UNSTAGED_TRACKED_FILES=0
SOURCE_SHA256=8D856818070BE87AF353D92876A84FBF43EE42E2A3D08524734F0DB7D5240A19
TEST_SHA256=83534850CC916B8CA98173D65BB683EE06E792BFDDC35E335CACD5F935F0E82E
GIT_COMMIT=NOT_PERFORMED
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

=== STAGED FILES ===
Evidence/CP-011/CP011_Full_Regression_Test_Output.txt
Evidence/CP-011/CP011_GREEN_Source_Change.txt
Evidence/CP-011/CP011_GREEN_Test_Output.txt
Evidence/CP-011/CP011_Hash_Inventory.txt
Evidence/CP-011/CP011_Hash_Inventory_Verification.txt
Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt
Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt
Evidence/CP-011/CP011_Precommit_Git_Review.txt
Evidence/CP-011/CP011_Preformat_Test_Snapshot.txt
Evidence/CP-011/CP011_RED_Test_Output.txt
Evidence/CP-011/CP011_Rustfmt_Apply_Output.txt
Evidence/CP-011/CP011_Rustfmt_Check_Output.txt
Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt
Evidence/CP-011/CP011_Scope_Lock.txt
Evidence/CP-011/CP011_Starting_State.txt
Evidence/CP-011/CP011_WASM_Build_Output.txt
src/lib.rs
tests/CP011_cvt_scr_candidate_identity.rs

=== UNSTAGED TRACKED FILES ===

=== UNTRACKED FILES ===
Evidence/CP-011/CP011_Staged_Whitespace_Diagnostic.txt

CP011 SUPPLEMENTARY SHA-256 VERIFICATION - DAY 066
GIT_HEAD=b7c515faa9bd000369d7656e09437310261290ae
ORIGINAL_INVENTORY_SHA256=EEAEBAB9E3AA43BA8A5D38EB1ED7B5C77A65DB64D63940C55A846426B170D564
SUPPLEMENTARY_INVENTORY_SHA256=269B3623255267434A22E3F5B632D82CD861069328AA1B2E65627CAF9FACDCC8
ORIGINAL_RECORDS=28
SUPPLEMENTARY_RECORDS=8
TOTAL_FILES_VERIFIED=36
EVIDENCE_FILES_BEFORE_VERIFICATION=22
DIRECTORY_COVERAGE_MATCH=True
STAGED_FILES=23
GIT_STATE_CORRECT=True
ISSUES=0
SUPPLEMENTARY_VERIFICATION_PASS=True
GIT_COMMIT=NOT_PERFORMED
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

=== VERIFICATION ISSUES ===
NONE

# CP012: preserve historical diagnostic evidence byte-for-byte.
# Scoped whitespace exceptions for preserved CP012 diagnostics.
CP012_GREEN_Correction_Review.txt whitespace=-blank-at-eol
CP012_GREEN_Failure_Triage.txt whitespace=-blank-at-eol
CP012_GREEN_Source_Change.txt whitespace=-blank-at-eol
CP012_Starting_State.txt whitespace=-blank-at-eol,-blank-at-eof
CP012_Whitespace_Exceptions_Review.txt whitespace=-blank-at-eof

CP012 CLOSING GIT REVIEW - DAY 066
GIT_HEAD=e84ae5baeee05f9d5d30284c65b86eebba3c0f6a
BRANCH=master
FINAL_STAGING_REVIEW_SHA256=47EF4445BD162F5DAEBCC6692C5CB4674D2955FAF93AAD508BA42EB9A71F2597
STAGED_FILES=27
STAGED_MEMBERSHIP_PASS=True
GIT_STAGED_WHITESPACE_EXIT_CODE=0
GIT_STAGED_WHITESPACE_PASS=True
UNSTAGED_TRACKED_FILES=0
UNTRACKED_FILES_BEFORE_CLOSING_REPORT=0
WORKTREE_REMAINDER_PASS=True
CRITICAL_HASHES_STABLE=True
CLOSING_GIT_REVIEW_PASS=True
SOURCE_SHA256=E28C62D1413D782EC715FB6DC56CA421B8B3793F557442B25D20D34243342153
TEST_SHA256=261708C9F535A50D1B01F5F0B6260057E3E422CD59B8A8BDA6E454BA22289DCA
AMENDED_ATTRIBUTES_SHA256=267E4038886945C8F63940D9BE62911E8B3CED1BC3EE2851BCF1D4D57B906DC1
NATIVE_REGRESSION=52_PASS_0_FAIL
CANONICAL_WASM_BUILD=PASS
FINAL_RUSTFMT=PASS
ORIGINAL_AND_AMENDED_HASH_EVIDENCE=PRESERVED
W002-STOR-023.1=PARTIALLY_IMPLEMENTED
CLOSING_REPORT=NOT_YET_STAGED
GIT_COMMIT=NOT_PERFORMED
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

=== STAGED FILES ===
A	Evidence/CP-012/.gitattributes
A	Evidence/CP-012/CP012_EOF_Whitespace_Amendment.txt
A	Evidence/CP-012/CP012_Final_Rustfmt_Check.txt
A	Evidence/CP-012/CP012_Final_Staging_Review.txt
A	Evidence/CP-012/CP012_Full_Regression_Test_Output.txt
A	Evidence/CP-012/CP012_GREEN2_Test_Output.txt
A	Evidence/CP-012/CP012_GREEN_Correction_Review.txt
A	Evidence/CP-012/CP012_GREEN_Failure_Triage.txt
A	Evidence/CP-012/CP012_GREEN_Rustfmt_Precheck.txt
A	Evidence/CP-012/CP012_GREEN_Source_Change.txt
A	Evidence/CP-012/CP012_GREEN_Test_Output.txt
A	Evidence/CP-012/CP012_Hash_Inventory.txt
A	Evidence/CP-012/CP012_Hash_Inventory_Verification.txt
A	Evidence/CP-012/CP012_Post_Staging_Hash_Amendment.txt
A	Evidence/CP-012/CP012_Post_Staging_Hash_Verification.txt
A	Evidence/CP-012/CP012_Precommit_Git_Review.txt
A	Evidence/CP-012/CP012_RED_Test_Output.txt
A	Evidence/CP-012/CP012_Scope_Lock.txt
A	Evidence/CP-012/CP012_Staged_Whitespace_Review.txt
A	Evidence/CP-012/CP012_Starting_State.txt
A	Evidence/CP-012/CP012_Supplementary_Hash_Inventory.txt
A	Evidence/CP-012/CP012_Supplementary_Hash_Verification.txt
A	Evidence/CP-012/CP012_Test_Authoring_Format_Output.txt
A	Evidence/CP-012/CP012_WASM_Build_Output.txt
A	Evidence/CP-012/CP012_Whitespace_Exceptions_Review.txt
M	src/lib.rs
A	tests/CP012_scr_filename_candidate.rs

=== STAGED WHITESPACE DIAGNOSTICS ===
NONE
END_OF_CLOSING_REVIEW

=== CP012 FINAL RUSTFMT VERIFICATION ===
GIT_HEAD=e84ae5baeee05f9d5d30284c65b86eebba3c0f6a
RUST_TOOLCHAIN=1.97.1
RUSTFMT_EXIT_CODE=0
RUSTFMT_CHECK_PASS=True
RUST_FILES_CHECKED=12
RUST_FILES_CHANGED=0
SOURCE_AND_TEST_FILES_UNCHANGED=True
HISTORICAL_FAILURE_PRESERVED=True
SOURCE_SHA256=E28C62D1413D782EC715FB6DC56CA421B8B3793F557442B25D20D34243342153
TEST_SHA256=261708C9F535A50D1B01F5F0B6260057E3E422CD59B8A8BDA6E454BA22289DCA
FAILED_GREEN_EVIDENCE_SHA256=4405B66F628F2B3CC08C439B743C516C66DBA0AF5B2F96B405909AF45F2C77C9
FINAL_FORMAT_VERIFICATION_PASS=True
NATIVE_REGRESSION=52_PASS_0_FAIL
CANONICAL_WASM_BUILD=PASS
SHA256_INVENTORY=PENDING
GIT_REVIEW=PENDING
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 1.42s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP008_source_eligibility.rs (target\debug\deps\CP008_source_eligibility-194c314726b26929.exe)

running 5 tests
test accepts_analyst_csv_final_extension_in_ascii_case_variants ... ok
test refuses_reserved_namespace_even_if_name_looks_like_csv ... ok
test refuses_paths_traversal_and_external_references ... ok
test makes_no_case_or_unicode_normalization_claim ... ok
test rejects_non_csv_or_nonfinal_csv_extensions ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP009_exact_root_snapshot.rs (target\debug\deps\CP009_exact_root_snapshot-b26a1b02e36e8f07.exe)

running 8 tests
test candidate_preflight_runs_before_root_matching ... ok
test finds_one_exact_reported_regular_file ... ok
test full_filename_match_is_exact_and_case_sensitive ... ok
test duplicate_exact_entries_refuse_instead_of_picking_first ... ok
test never_trims_to_find_a_different_physical_name ... ok
test reported_non_regular_entries_do_not_pass ... ok
test result_is_order_independent_and_empty_snapshot_is_not_found ... ok
test unicode_scalar_sequence_is_not_normalized ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP010_cvt_filename_candidate.rs (target\debug\deps\CP010_cvt_filename_candidate-ce216c0140f6b173.exe)

running 4 tests
test accepts_exact_canonical_cvt_csv_candidate ... ok
test refuses_malformed_canonical_identity ... ok
test refuses_wrong_classes_and_extensions ... ok
test refuses_paths_and_noncanonical_references ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP011_cvt_scr_candidate_identity.rs (target\debug\deps\CP011_cvt_scr_candidate_identity-8bc68fabbbb42eb4.exe)

running 6 tests
test derives_exact_corresponding_scr_identity ... ok
test refuses_invalid_utc_and_uuid ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_whitespace_and_noncanonical_names ... ok
test refuses_wrong_extension_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP012_scr_filename_candidate.rs (target\debug\deps\CP012_scr_filename_candidate-7c39746d8bb6fac7.exe)

running 6 tests
test accepts_canonical_scr_csv_candidate ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_noncanonical_namespace_class_and_extension ... ok
test accepts_canonical_scr_txt_candidate ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_and_whitespace ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)

running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok
test distinguishes_registered_emittable_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)

running 4 tests
test constructs_exact_canonical_filename_candidates ... ok
test refuses_invalid_timestamp_uuid_and_empty_extension ... ok
test refuses_noncanonical_class_without_repair ... ok
test preserves_extension_without_case_or_unicode_normalization ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)

running 3 tests
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)

running 6 tests
test recognizes_governed_namespace_and_class ... ok
test rejects_invalid_class_boundaries ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)

running 4 tests
test extension_does_not_determine_semantic_class ... ok
test preserves_literal_tokens_without_claiming_authority ... ok
test extracts_semantic_class_and_serialization_separately ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

running 3 tests
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_nonexistent_gregorian_dates ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests data_sculptor_core

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


=== CP012 FULL NATIVE REGRESSION VERIFICATION ===
GIT_HEAD=e84ae5baeee05f9d5d30284c65b86eebba3c0f6a
CARGO_EXIT_CODE=0
TEST_RESULT_GROUPS=13
TOTAL_TESTS_PASSED=52
TOTAL_TESTS_FAILED=0
CP012_SIX_TESTS_PASS=True
FULL_REGRESSION_PASS=True
SOURCE_AND_TEST_HASHES_STABLE=True
HISTORICAL_FAILURE_PRESERVED=True
SOURCE_SHA256=E28C62D1413D782EC715FB6DC56CA421B8B3793F557442B25D20D34243342153
TEST_SHA256=261708C9F535A50D1B01F5F0B6260057E3E422CD59B8A8BDA6E454BA22289DCA
FAILED_GREEN_EVIDENCE_SHA256=4405B66F628F2B3CC08C439B743C516C66DBA0AF5B2F96B405909AF45F2C77C9
EARLY_RUSTFMT=PASS
WASM_BUILD=PENDING
FINAL_FORMAT_CHECK=PENDING
SHA256_VERIFICATION=PENDING
GIT_REVIEW=PENDING
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 1.04s
     Running tests\CP012_scr_filename_candidate.rs (target\debug\deps\CP012_scr_filename_candidate-7c39746d8bb6fac7.exe)

running 6 tests
test accepts_canonical_scr_csv_candidate ... ok
test accepts_canonical_scr_txt_candidate ... ok
test refuses_noncanonical_namespace_class_and_extension ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_and_whitespace ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


=== CP012 GREEN2 VERIFICATION ===
GIT_HEAD=e84ae5baeee05f9d5d30284c65b86eebba3c0f6a
CARGO_EXIT_CODE=0
SIX_TESTS_PASSED=True
GREEN2_PASS=True
SOURCE_AND_TEST_HASHES_STABLE=True
SOURCE_SHA256=E28C62D1413D782EC715FB6DC56CA421B8B3793F557442B25D20D34243342153
TEST_SHA256=261708C9F535A50D1B01F5F0B6260057E3E422CD59B8A8BDA6E454BA22289DCA
FAILED_GREEN_EVIDENCE_SHA256=4405B66F628F2B3CC08C439B743C516C66DBA0AF5B2F96B405909AF45F2C77C9
HISTORICAL_FAILURE_PRESERVED=True
EARLY_RUSTFMT=PASS
SHARED_FILENAME_PARSER=UNCHANGED
FULL_REGRESSION=PENDING
WASM_BUILD=PENDING
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

=== CP012 GREEN CORRECTION REVIEW ===
GIT_HEAD=e84ae5baeee05f9d5d30284c65b86eebba3c0f6a
SOURCE_SHA256_BEFORE=06D257B045BA7179493793B17C461DFCC451D580DCD2F6E19364D6283660CC7B
SOURCE_SHA256_AFTER=E28C62D1413D782EC715FB6DC56CA421B8B3793F557442B25D20D34243342153
TEST_SHA256=261708C9F535A50D1B01F5F0B6260057E3E422CD59B8A8BDA6E454BA22289DCA
RUSTFMT_EXIT_CODE=0
GIT_DIFF_CHECK_EXIT=0
SOURCE_AND_TEST_HASHES_STABLE=True
CORRECTION_REVIEW_PASS=True
CORRECTION=REJECT_WHITESPACE_AND_PATH_SEPARATORS
SHARED_FILENAME_PARSER=UNCHANGED
TEST_SOURCE=UNCHANGED
FAILED_GREEN_EVIDENCE=PRESERVED
GREEN_RERUN=PENDING
FULL_REGRESSION=PENDING
WASM_BUILD=PENDING
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

=== SOURCE DIFF ===
diff --git a/src/lib.rs b/src/lib.rs
index e08d25b..b59ee46 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -341,3 +341,21 @@ pub fn build_scr_candidate_filename_for_cvt(filename: &str) -> Option<String> {
 
     Some(filename.replacen("__DS__CVT__", "__DS__SCR__", 1))
 }
+
+/// Recognizes a canonical SCR staging filename candidate.
+///
+/// Lexical recognition only. This does not verify file existence,
+/// contents, intended final class, publication, or authority.
+pub fn is_canonical_scr_filename_candidate(filename: &str) -> bool {
+    if filename
+        .chars()
+        .any(|ch| ch.is_whitespace() || ch == '/' || ch == '\\')
+    {
+        return false;
+    }
+
+    matches!(
+        extract_artifact_filename_tokens(filename),
+        Some(tokens) if tokens.semantic_class == "SCR"
+    )
+}

=== WHITESPACE DIAGNOSTIC ===
NONE

CP012 GREEN FAILURE TRIAGE - DAY 066
GIT_HEAD=e84ae5baeee05f9d5d30284c65b86eebba3c0f6a
SOURCE_SHA256=06D257B045BA7179493793B17C461DFCC451D580DCD2F6E19364D6283660CC7B
TEST_SHA256=261708C9F535A50D1B01F5F0B6260057E3E422CD59B8A8BDA6E454BA22289DCA
CARGO_EXIT_CODE=101
TESTS_PASSED=5
TESTS_FAILED=1
FAILING_TEST=refuses_paths_and_whitespace
EXACT_FAILING_INPUT=NOT_YET_IDENTIFIED
FAILURE_EVIDENCE=PRESERVED
PRODUCTION_SOURCE=UNCHANGED_DURING_TRIAGE
TEST_SOURCE=UNCHANGED_DURING_TRIAGE
CORRECTIVE_ACTION=NOT_YET_AUTHORIZED
DAY_066_STATUS=OPEN

=== RELEVANT SOURCE AND TEST INSPECTION ===
=== SOURCE FUNCTION: is_canonical_immutable_artifact_filename ===
 168:         }
 169:         _ => ArtifactClassDisposition::Unallocated(class),
 170:     }
 171: }
 172: 
 173: /// Checks the lexical envelope of an ordinary immutable artifact filename.
 174: ///
 175: /// This validates ordinary Gregorian UTC calendar/clock fields, but not
 176: /// artifact-specific extension, registered class, governed contents,
 177: /// provenance, or authority.
 178: pub fn is_canonical_immutable_artifact_filename(filename: &str) -> bool {
 179:     let Some(rest) = filename.strip_prefix("__DS__") else {
 180:         return false;
 181:     };
 182: 
 183:     let Some((class, rest)) = rest.split_once("__") else {
 184:         return false;
 185:     };
 186: 
 187:     if class.len() != 3 || !class.bytes().all(|byte| byte.is_ascii_uppercase()) {
 188:         return false;
 189:     }
 190: 
 191:     let Some((utc, rest)) = rest.split_once("__") else {
 192:         return false;
 193:     };
 194: 
 195:     let timestamp = utc.as_bytes();
 196: 
 197:     if timestamp.len() != 19
 198:         || timestamp[8] != b'T'
 199:         || timestamp[18] != b'Z'
 200:         || !timestamp
 201:             .iter()
 202:             .enumerate()
 203:             .all(|(i, byte)| matches!(i, 8 | 18) || byte.is_ascii_digit())
 204:     {
 205:         return false;
 206:     }
 207: 
 208:     if !utc_calendar_fields_valid(timestamp) {
 209:         return false;
 210:     }
 211: 
 212:     let Some((uuid, extension)) = rest.split_once('.') else {
 213:         return false;
 214:     };
 215: 
 216:     if extension.is_empty() {
 217:         return false;
 218:     }
 219: 
 220:     let bytes = uuid.as_bytes();
 221: 
 222:     if bytes.len() != 36 {
 223:         return false;
 224:     }
 225: 
 226:     for (i, byte) in bytes.iter().enumerate() {
 227:         if matches!(i, 8 | 13 | 18 | 23) {
 228:             if *byte != b'-' {
 229:                 return false;
 230:             }
 231:         } else if !byte.is_ascii_hexdigit() || byte.is_ascii_uppercase() {
 232:             return false;
 233:         }
 234:     }
 235: 
 236:     bytes[14] == b'4' && matches!(bytes[19], b'8' | b'9' | b'a' | b'b')
 237: }
 238: 
 239: /// Validates Gregorian calendar and ordinary UTC clock fields.
 240: /// Called only after the 19-byte ASCII timestamp grammar has passed.
 241: /// Leap-second values (seconds = 60) are provisionally rejected.
 242: fn utc_calendar_fields_valid(timestamp: &[u8]) -> bool {
 243:     if timestamp.len() != 19 {

=== SOURCE FUNCTION: extract_artifact_filename_tokens ===
 274: ///
 275: /// Extraction does not register a class, approve a serialization format,
 276: /// validate artifact contents, or establish governed authority.
 277: #[derive(Debug, Clone, Copy, PartialEq, Eq)]
 278: pub struct ArtifactFilenameTokens<'a> {
 279:     pub semantic_class: &'a str,
 280:     pub serialization_extension: &'a str,
 281: }
 282: 
 283: /// Extracts independent class and serialization tokens after envelope validation.
 284: pub fn extract_artifact_filename_tokens(filename: &str) -> Option<ArtifactFilenameTokens<'_>> {
 285:     if !is_canonical_immutable_artifact_filename(filename) {
 286:         return None;
 287:     }
 288: 
 289:     let rest = filename.strip_prefix("__DS__")?;
 290:     let (semantic_class, rest) = rest.split_once("__")?;
 291:     let (_, rest) = rest.split_once("__")?;
 292:     let (_, serialization_extension) = rest.split_once('.')?;
 293: 
 294:     Some(ArtifactFilenameTokens {
 295:         semantic_class,
 296:         serialization_extension,
 297:     })
 298: }
 299: 
 300: /// Constructs a canonical immutable filename candidate from exact input tokens.
 301: ///
 302: /// This function performs no case folding, trimming, Unicode normalization,
 303: /// UUID allocation, filesystem operation, or artifact publication.
 304: /// A successful candidate does not establish governed artifact authority.
 305: pub fn build_immutable_artifact_filename_candidate(
 306:     semantic_class: &str,
 307:     utc: &str,
 308:     uuid: &str,
 309:     serialization_extension: &str,
 310: ) -> Option<String> {
 311:     let filename = format!("__DS__{semantic_class}__{utc}__{uuid}.{serialization_extension}");
 312: 
 313:     if is_canonical_immutable_artifact_filename(&filename) {
 314:         Some(filename)
 315:     } else {
 316:         None
 317:     }
 318: }
 319: 
 320: /// Recognizes a canonical governed CVT CSV SOURCE filename candidate.
 321: ///
 322: /// Lexical recognition only. This does not verify physical existence,
 323: /// publication, provenance, encoding, CSV validity, or SOURCE authority.
 324: pub fn is_governed_cvt_source_filename_candidate(filename: &str) -> bool {
 325:     matches!(
 326:         extract_artifact_filename_tokens(filename),
 327:         Some(tokens)
 328:             if tokens.semantic_class == "CVT"
 329:                 && tokens.serialization_extension == "csv"
 330:     )
 331: }
 332: 
 333: /// Derives the SCR staging filename candidate corresponding to a canonical CVT.
 334: ///
 335: /// Lexical construction only. This grants no filesystem, conversion,
 336: /// publication, or SOURCE authority.
 337: pub fn build_scr_candidate_filename_for_cvt(filename: &str) -> Option<String> {
 338:     if !is_governed_cvt_source_filename_candidate(filename) {
 339:         return None;
 340:     }
 341: 
 342:     Some(filename.replacen("__DS__CVT__", "__DS__SCR__", 1))
 343: }
 344: 
 345: /// Recognizes a canonical SCR staging filename candidate.
 346: ///
 347: /// Lexical recognition only. This does not verify file existence,
 348: /// contents, intended final class, publication, or authority.
 349: pub fn is_canonical_scr_filename_candidate(filename: &str) -> bool {

=== SOURCE FUNCTION: is_canonical_scr_filename_candidate ===
 339:         return None;
 340:     }
 341: 
 342:     Some(filename.replacen("__DS__CVT__", "__DS__SCR__", 1))
 343: }
 344: 
 345: /// Recognizes a canonical SCR staging filename candidate.
 346: ///
 347: /// Lexical recognition only. This does not verify file existence,
 348: /// contents, intended final class, publication, or authority.
 349: pub fn is_canonical_scr_filename_candidate(filename: &str) -> bool {
 350:     matches!(
 351:         extract_artifact_filename_tokens(filename),
 352:         Some(tokens) if tokens.semantic_class == "SCR"
 353:     )
 354: }

=== CP012 TEST SOURCE ===
   1: // CP012 RED tests - Day 066
   2: // W002-STOR-023.1 (partial).
   3: // Generic canonical SCR candidate recognition only.
   4: // No filesystem, publication, promotion, or authority.
   5: 
   6: use data_sculptor_core::is_canonical_scr_filename_candidate;
   7: 
   8: const SCR_CSV: &str = "__DS__SCR__20261013T173300000Z__123e4567-e89b-42d3-a456-426614174000.csv";
   9: const SCR_TXT: &str = "__DS__SCR__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.txt";
  10: 
  11: #[test]
  12: fn accepts_canonical_scr_csv_candidate() {
  13:     assert!(is_canonical_scr_filename_candidate(SCR_CSV));
  14: }
  15: 
  16: #[test]
  17: fn accepts_canonical_scr_txt_candidate() {
  18:     assert!(is_canonical_scr_filename_candidate(SCR_TXT));
  19: }
  20: 
  21: #[test]
  22: fn refuses_other_semantic_classes() {
  23:     for class in ["CVT", "RCP", "COL", "MAP", "CAT"] {
  24:         let filename = SCR_CSV.replacen("__DS__SCR__", &format!("__DS__{class}__"), 1);
  25:         assert!(!is_canonical_scr_filename_candidate(&filename));
  26:     }
  27: }
  28: 
  29: #[test]
  30: fn refuses_invalid_utc_and_uuid() {
  31:     for filename in [
  32:         SCR_CSV.replace("20261013", "20260230"),
  33:         SCR_CSV.replace("T173300000Z", "T253300000Z"),
  34:         SCR_CSV.replace("-42d3-", "-52d3-"),
  35:         SCR_CSV.replace("-a456-", "-7456-"),
  36:     ] {
  37:         assert!(!is_canonical_scr_filename_candidate(&filename));
  38:     }
  39: }
  40: 
  41: #[test]
  42: fn refuses_paths_and_whitespace() {
  43:     for filename in [
  44:         format!("folder/{SCR_CSV}"),
  45:         format!("folder\\{SCR_CSV}"),
  46:         format!("./{SCR_CSV}"),
  47:         format!(" {SCR_CSV}"),
  48:         format!("{SCR_CSV} "),
  49:     ] {
  50:         assert!(!is_canonical_scr_filename_candidate(&filename));
  51:     }
  52: }
  53: 
  54: #[test]
  55: fn refuses_noncanonical_namespace_class_and_extension() {
  56:     for filename in [
  57:         SCR_CSV.replacen("__DS__SCR__", "__DS__scr__", 1),
  58:         SCR_CSV.replacen("__DS__SCR__", "__DS__SCR_", 1),
  59:         SCR_CSV.replace(".csv", ""),
  60:         SCR_CSV.replace(".csv", "."),
  61:         "__DS__SCR__".to_string(),
  62:     ] {
  63:         assert!(!is_canonical_scr_filename_candidate(&filename));
  64:     }
  65: }

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 1.03s
     Running tests\CP012_scr_filename_candidate.rs (target\debug\deps\CP012_scr_filename_candidate-7c39746d8bb6fac7.exe)

running 6 tests
test accepts_canonical_scr_txt_candidate ... ok
test accepts_canonical_scr_csv_candidate ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_noncanonical_namespace_class_and_extension ... ok
test refuses_other_semantic_classes ... ok

thread 'refuses_paths_and_whitespace' (10112) panicked at tests\CP012_scr_filename_candidate.rs:50:9:
assertion failed: !is_canonical_scr_filename_candidate(&filename)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
test refuses_paths_and_whitespace ... FAILED

failures:

failures:
    refuses_paths_and_whitespace

test result: FAILED. 5 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

error: test failed, to rerun pass `--test CP012_scr_filename_candidate`

=== CP012 GREEN VERIFICATION ===
CARGO_EXIT_CODE=101
SIX_TESTS_PASSED=False
SOURCE_AND_TEST_HASHES_STABLE=True
SOURCE_SHA256=06D257B045BA7179493793B17C461DFCC451D580DCD2F6E19364D6283660CC7B
TEST_SHA256=261708C9F535A50D1B01F5F0B6260057E3E422CD59B8A8BDA6E454BA22289DCA
RUSTFMT_PRECHECK_OUTPUT_BYTES=0
RUSTFMT_PRECHECK_OUTPUT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
RUSTFMT_PRECHECK_EXIT_CODE=0
RED_EVIDENCE=PRESERVED
FULL_REGRESSION=PENDING
WASM_BUILD=PENDING
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

CP012 INDEPENDENT SHA-256 VERIFICATION - DAY 066
GIT_HEAD=e84ae5baeee05f9d5d30284c65b86eebba3c0f6a
INVENTORY_SHA256=1EBA801751DA08605DEA1B57B9EE96D4BD39AED7DBCD385A4078D849BB284EAB
INVENTORY_ROWS=29
FILES_VERIFIED=29
RUST_SOURCE_AND_TEST_FILES=12
CONFIG_FILES=4
CP012_ORIGINAL_EVIDENCE_FILES=13
SIZE_AND_SHA256_VERIFICATION_PASS=True
INVENTORY_MEMBERSHIP_PASS=True
CRITICAL_HASHES_PASS=True
WHITESPACE_RISK_COUNT=4
WHITESPACE_RISK_SET_MATCHES_INVENTORY=True
INDEPENDENT_VERIFICATION_PASS=True
MISMATCH_COUNT=0
HISTORICAL_FILES_MODIFIED=NONE
GIT_STAGING=NOT_PERFORMED
GIT_COMMIT=NOT_PERFORMED
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

=== WHITESPACE RISK DETAILS ===
RISK_PATH=Evidence/CP-012/CP012_GREEN_Correction_Review.txt
RISK_LINE_COUNT=1
FIRST_RISK_LINES=27
GIT_ATTRIBUTE=Evidence/CP-012/CP012_GREEN_Correction_Review.txt: whitespace: unspecified

RISK_PATH=Evidence/CP-012/CP012_GREEN_Failure_Triage.txt
RISK_LINE_COUNT=33
FIRST_RISK_LINES=22,32,36,40,44,46,57,61,65,69,71,75,85,88,104
GIT_ATTRIBUTE=Evidence/CP-012/CP012_GREEN_Failure_Triage.txt: whitespace: unspecified

RISK_PATH=Evidence/CP-012/CP012_GREEN_Source_Change.txt
RISK_LINE_COUNT=1
FIRST_RISK_LINES=22
GIT_ATTRIBUTE=Evidence/CP-012/CP012_GREEN_Source_Change.txt: whitespace: unspecified

RISK_PATH=Evidence/CP-012/CP012_Starting_State.txt
RISK_LINE_COUNT=9
FIRST_RISK_LINES=21,27,32,38,51,58,72,81,93
GIT_ATTRIBUTE=Evidence/CP-012/CP012_Starting_State.txt: whitespace: unspecified

=== INVENTORY MISMATCHES ===
NONE

CP012 APPEND-ONLY POST-STAGING HASH AMENDMENT - DAY 066
GIT_HEAD=e84ae5baeee05f9d5d30284c65b86eebba3c0f6a
BRANCH=master
RECORDED_UTC=2026-10-13T23:08:08Z
ORIGINAL_INVENTORY_ROWS=29
ORIGINAL_ROWS_REVERIFIED=29
SUPPLEMENTARY_INVENTORY_ROWS=4
UNCHANGED_SUPPLEMENTARY_ROWS_REVERIFIED=3
REVISED_FILE=Evidence/CP-012/.gitattributes
PREVIOUS_ATTRIBUTES_SHA256=B07B6100FA350354628493F6B7CC78988319E832B665B4C0C28A1707D4EF9294
CURRENT_ATTRIBUTES_SHA256=267E4038886945C8F63940D9BE62911E8B3CED1BC3EE2851BCF1D4D57B906DC1
REASON=SCOPED_EOF_WHITESPACE_AMENDMENT
PRIOR_INVENTORIES=PRESERVED_UNMODIFIED
UNIQUE_FILE_PATHS_BEFORE_THIS_REPORT=38
AMENDMENT_RECORDS=6
STAGED_FILES=22
STAGED_WHITESPACE=PASS
HISTORICAL_FILES=UNCHANGED_EXCEPT_DOCUMENTED_ATTRIBUTES_REVISION
GIT_COMMIT=NOT_PERFORMED
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN
Path	SizeBytes	SHA256
Evidence/CP-012/.gitattributes	433	267E4038886945C8F63940D9BE62911E8B3CED1BC3EE2851BCF1D4D57B906DC1
Evidence/CP-012/CP012_EOF_Whitespace_Amendment.txt	1814	5F2514CC5DF7AEFADC1245BE9967FD059C12C14B481A575A160BA19C1E5178D5
Evidence/CP-012/CP012_Precommit_Git_Review.txt	3168	6A598B069755A0AB82DF268D235B8A22ACC6A7139AEBACC47C12DDB11A25950F
Evidence/CP-012/CP012_Staged_Whitespace_Review.txt	2034	19E977002E0AD9218C5F63AA5A857EFB800B434D8F73D07D46775F169CAA3D58
Evidence/CP-012/CP012_Supplementary_Hash_Inventory.txt	1066	AE78236DC452BFB045DA0DB978121001B309AB6F97CA56171E7B28459C14FF08
Evidence/CP-012/CP012_Supplementary_Hash_Verification.txt	801	473DC72D8B8D3D62823863B0D02950C47060AC01F1AF7D0F256DD7FDCA731A70
END_OF_AMENDMENT

CP012 INDEPENDENT POST-STAGING HASH VERIFICATION - DAY 066
GIT_HEAD=e84ae5baeee05f9d5d30284c65b86eebba3c0f6a
AMENDMENT_SHA256=2DF96E0AF25000D5E28055A92F5E1035A244DC50D3D340FFBF69212D1238992B
ORIGINAL_FILES_REVERIFIED=29
UNCHANGED_SUPPLEMENTARY_FILES_REVERIFIED=3
AMENDMENT_RECORDS_VERIFIED=6
AMENDMENT_MEMBERSHIP_PASS=True
AMENDED_ATTRIBUTES_SHA256=267E4038886945C8F63940D9BE62911E8B3CED1BC3EE2851BCF1D4D57B906DC1
SUPERSEDED_ATTRIBUTE_RECORD=DOCUMENTED
CRITICAL_SOURCE_AND_TEST_HASHES=PASS
STAGED_FILES=22
GIT_STAGED_WHITESPACE_EXIT_CODE=0
GIT_STAGED_WHITESPACE=PASS
UNTRACKED_EVIDENCE_BEFORE_REPORT=3
POST_STAGING_HASH_VERIFICATION_PASS=True
HISTORICAL_INVENTORIES=UNCHANGED
GIT_COMMIT=NOT_PERFORMED
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN
END_OF_VERIFICATION

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
error[E0432]: unresolved import `data_sculptor_core::is_canonical_scr_filename_candidate`
 --> tests\CP012_scr_filename_candidate.rs:6:5
  |
6 | use data_sculptor_core::is_canonical_scr_filename_candidate;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `is_canonical_scr_filename_candidate` in the root

For more information about this error, try `rustc --explain E0432`.
error: could not compile `data_sculptor_core` (test "CP012_scr_filename_candidate") due to 1 previous error

=== CP012 RED VERIFICATION ===
CARGO_EXIT_CODE=101
EXPECTED_MISSING_FUNCTION_RED=True
SOURCE_AND_TEST_HASHES_UNCHANGED=True
GIT_HEAD=e84ae5baeee05f9d5d30284c65b86eebba3c0f6a
SOURCE_SHA256=8D856818070BE87AF353D92876A84FBF43EE42E2A3D08524734F0DB7D5240A19
TEST_SHA256=261708C9F535A50D1B01F5F0B6260057E3E422CD59B8A8BDA6E454BA22289DCA
TEST_AUTHORING_FORMAT=PASS
PRODUCTION_IMPLEMENTATION=NOT_STARTED
GREEN_EXECUTION=PENDING
FULL_REGRESSION=PENDING
WASM_BUILD=PENDING
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

CP012 INDEPENDENT SUPPLEMENTARY HASH VERIFICATION - DAY 066
GIT_HEAD=e84ae5baeee05f9d5d30284c65b86eebba3c0f6a
ORIGINAL_INVENTORY_SHA256=1EBA801751DA08605DEA1B57B9EE96D4BD39AED7DBCD385A4078D849BB284EAB
SUPPLEMENTARY_INVENTORY_SHA256=AE78236DC452BFB045DA0DB978121001B309AB6F97CA56171E7B28459C14FF08
ORIGINAL_RECORDS_VERIFIED=29
SUPPLEMENTARY_RECORDS_VERIFIED=4
TOTAL_FILES_VERIFIED=33
SHA256_AND_FILE_SIZES=PASS
INVENTORY_MEMBERSHIP=PASS
EVIDENCE_DIRECTORY_FILES=18
EVIDENCE_DIRECTORY_MEMBERSHIP=PASS
FOUR_SCOPED_GIT_ATTRIBUTES=PASS
UNRELATED_GIT_ATTRIBUTES=UNCHANGED
CRITICAL_SOURCE_AND_TEST_HASHES_PASS=True
INDEPENDENT_SUPPLEMENTARY_VERIFICATION_PASS=True
ORIGINAL_EVIDENCE=UNCHANGED
GIT_STAGING=NOT_PERFORMED
GIT_COMMIT=NOT_PERFORMED
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.48s

=== CP012 CANONICAL WASM BUILD VERIFICATION ===
GIT_HEAD=e84ae5baeee05f9d5d30284c65b86eebba3c0f6a
CARGO_EXIT_CODE=0
RUST_TOOLCHAIN=1.97.1
TARGET=wasm32-unknown-unknown
BUILD_MODE=LIB_ONLY
WASM_BUILD_PASS=True
SOURCE_AND_TEST_HASHES_STABLE=True
HISTORICAL_FAILURE_PRESERVED=True
SOURCE_SHA256=E28C62D1413D782EC715FB6DC56CA421B8B3793F557442B25D20D34243342153
TEST_SHA256=261708C9F535A50D1B01F5F0B6260057E3E422CD59B8A8BDA6E454BA22289DCA
FAILED_GREEN_EVIDENCE_SHA256=4405B66F628F2B3CC08C439B743C516C66DBA0AF5B2F96B405909AF45F2C77C9
CP012_WASM_VERIFICATION_PASS=True
NATIVE_REGRESSION=52_PASS_0_FAIL
RUSTFMT_PRECHECK=PASS
FINAL_FORMAT_CHECK=PENDING
SHA256_VERIFICATION=PENDING
GIT_REVIEW=PENDING
HUMAN_ACCEPTANCE=PENDING
DAY_066_STATUS=OPEN

# CP013 CRLF-aware whitespace checks
CP013_*.txt whitespace=cr-at-eol
.gitattributes whitespace=cr-at-eol
# CP013 raw evidence whitespace exceptions
# Preserve original diagnostic evidence bytes.
CP013_Source_Inspection.txt whitespace=-blank-at-eol
CP013_Precedent_Test_Inspection.txt whitespace=-blank-at-eol
CP013_GREEN_Test_Output.txt whitespace=-blank-at-eof
CP013_Full_Regression_Test_Output.txt whitespace=-blank-at-eof
# Preserve CP013 evidence bytes against inherited text normalization.
CP013_*.txt -text
.gitattributes -text

RED5SORCERY DATA SCULPTOR
WASM-002 CP013 APPROVED SCOPE LOCK
DAY 066 - OPEN

Recorded UTC: 2026-10-13T23:53:22Z
Parent Git HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Approval authority: T
Approval: EXPLICIT - RECORDED IN CHAT
Scope status: LOCKED

TITLE
Explicit SCR-to-RCP Final Filename Candidate Derivation

FROZEN REQUIREMENT ANCHORS
W002-STOR-023.1 - PARTIAL
W002-STOR-023 - NOT_STARTED

PUBLIC RUST FUNCTION
build_final_filename_candidate_for_scr
Inputs: scr_filename, intended_final_class
Return: Option<String>

ACCEPTED BEHAVIOR
1. Require a canonical SCR staging filename candidate.
2. Require explicit intended_final_class exactly RCP.
3. Require the SCR serialization extension exactly txt.
4. Construct the corresponding RCP filename candidate.
5. Preserve UTC timestamp and UUID unchanged.
6. Preserve the lowercase txt serialization extension.
7. Change only the semantic class token SCR to RCP.
8. Return None for malformed or unsupported inputs.
9. Reuse existing canonical filename validation.

MANDATORY REFUSALS
Non-SCR input.
Unsupported or incorrectly cased final class.
Extensions other than exact lowercase txt.
Invalid UTC timestamp or UUID.
Whitespace, path separators, or noncanonical identity.

OUT OF SCOPE
No filesystem reads or writes.
No staging or final artifact creation.
No rename, promotion, or publication.
No Receipt validation or provenance verification.
No conversion, recovery, or orphan adoption.
No inference of intended class from extension.
No authority or requirement completion claim.

PLDD EXECUTION
Author approximately six focused RED tests.
Format tests before RED.
Record exact test-file SHA256 before RED.
Require expected missing-symbol RED failure.
Implement minimal GREEN.
Run targeted and full native regression.
Verify Rustfmt and canonical WASM build.
Preserve TXT evidence and SHA256 inventories.
Complete Git reviews before human acceptance.
Do not bank without explicit T approval.

ACCEPTANCE BOUNDARY
CP013 may establish lexical candidate derivation only.
Frozen parent requirements remain incomplete.
Independent adversarial QA is not claimed.
DAY 066 REMAINS OPEN.

RESULT: APPROVED SCOPE RECORDED

WASM-002 CP013 CLOSING HASH VERIFICATION
Timestamp: 2026-10-13 21:48:36 -03:00
Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
CLOSING_AMENDMENT_SHA256=B9B082CCB3727F0D4E205D0A6F4627C7C46407ADB813A6AE299F63DEE38C59FA
EXPECTED_EFFECTIVE_FILES=37
VERIFIED_EFFECTIVE_FILES=37
GIT_BYTE_PRESERVED_FILES=37
STAGED_BLOBS_VERIFIED=34
STAGED_SET_MATCH=True
UNTRACKED_SET_MATCH=True
EVIDENCE_SET_MATCH=True
STAGED_WHITESPACE_EXIT=0
FAILURE_COUNT=0
NO_GIT_STAGING_OR_COMMIT_PERFORMED=True
DAY_066=OPEN

=== FILE VERIFICATION ===
FILE=Evidence/CP-013/.gitattributes
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Approved_Scope_Lock.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Full_Regression_Test_Output.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Full_Regression_Verification.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_GREEN_Implementation_Report.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_GREEN_Test_Output.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_GREEN_Test_Verification.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Hash_Inventory.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Hash_Inventory_Verification.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Opening_Git_Preflight.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Precedent_Test_Inspection.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Precommit_Git_Review.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_RED_Test_Output.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_RED_Test_Verification.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Rustfmt_Check_Output.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Source_Inspection.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Staged_Whitespace_Recovery_Output.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Staged_Whitespace_Recovery_Report.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Staging_Action_Report.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Test_Authoring_Report.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Test_Formatting_Report.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Test_Rustfmt_Output.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_WASM_Build_Output.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_WASM_Build_Verification.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=Evidence/CP-013/CP013_Whitespace_Exception_Review.txt
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=src/lib.rs
HASH_MATCH=True
BYTE_PRESERVED=True

FILE=tests/CP013_scr_rcp_candidate_identity.rs
HASH_MATCH=True
BYTE_PRESERVED=True

=== FAILURES ===
(none)

RESULT: PASS - CLOSING HASH VERIFICATION

WASM-002 CP013 FINAL STAGING VERIFICATION
Timestamp: 2026-10-13 21:55:39 -03:00
Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Final HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
PREVIOUSLY_STAGED=40
NEWLY_STAGED=1
EXPECTED_STAGED_FILES=41
ACTUAL_STAGED_FILES=41
STAGED_SET_MATCH=True
STAGED_BLOBS_VERIFIED=41
BLOB_FAILURE_COUNT=0
STAGED_WHITESPACE_EXIT=0
UNTRACKED_BEFORE_REPORT=0
UNSTAGED_TRACKED_AFTER=0
NATIVE_REGRESSION=58_PASS_0_FAIL
CANONICAL_WASM_BUILD=PASS
CLOSING_REVIEW_SHA256=5988ADE01F6F646AF7BB7844E7B1E2BF841C78EC7BFF6E6A34B540E0CF5926C9
FINAL_VERIFICATION_REPORT_NOT_YET_STAGED=True
GIT_COMMIT_PERFORMED=False
HUMAN_ACCEPTANCE_PENDING=True
DAY_066=OPEN

=== STAGED BLOB VERIFICATION ===
PASS	src/lib.rs	b2df81ba4946220e85543b44bd8ab33e3a341f9e
PASS	tests/CP013_scr_rcp_candidate_identity.rs	f512948ac406169c9c2e454a3814103b75bf3e24
PASS	Evidence/CP-013/.gitattributes	8d3a12dc9988365eb06c13d3d8204414afdc97a6
PASS	Evidence/CP-013/CP013_Approved_Scope_Lock.txt	b8bc3bd6c76f89dd2b9666de8be27e63fbba3a43
PASS	Evidence/CP-013/CP013_Closing_Git_Review.txt	f40b328d99141f6957177c7beea915af8c05b927
PASS	Evidence/CP-013/CP013_Closing_Hash_Amendment.txt	a05a3768adb7c7067ea90aecff54e67ad46d15ea
PASS	Evidence/CP-013/CP013_Closing_Hash_Verification.txt	82c57faa151d5c12bf3759ea8a5e76f778f654e4
PASS	Evidence/CP-013/CP013_Final_Evidence_Staging_Review.txt	7cd60f441ebe866fdf03f9395ed098f9397eebdf
PASS	Evidence/CP-013/CP013_Full_Regression_Test_Output.txt	f5a449cf20643c9ab32ffa70fd42ba598bc35a8a
PASS	Evidence/CP-013/CP013_Full_Regression_Verification.txt	4632d651638cd57e9da841bfef854dcebc645683
PASS	Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt	01395098a88f9feced444983f3e9f81e30f76095
PASS	Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt	203d5c62dff3e9d7e244eca005a29101615ea8c4
PASS	Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt	92ae84193d99d78c9c379ca86052b48333f879f7
PASS	Evidence/CP-013/CP013_GREEN_Implementation_Report.txt	4d79c7eb970b267a9328638008a9c2df3cbddb6d
PASS	Evidence/CP-013/CP013_GREEN_Test_Output.txt	c319ce343f8a09041ecfaa85c5fa7d190dc6aa57
PASS	Evidence/CP-013/CP013_GREEN_Test_Verification.txt	32e085d02532cfa358e7d6940bcc0d12ea25354f
PASS	Evidence/CP-013/CP013_Hash_Inventory.txt	a1f5df08f90d5d4ea5be238d52251dd855ae9b0b
PASS	Evidence/CP-013/CP013_Hash_Inventory_Verification.txt	4eb11024534c02c46bbd0b8331bfd81ee6d98017
PASS	Evidence/CP-013/CP013_Opening_Git_Preflight.txt	51aeaf3e50206991f3ccf49053968ed7e1338c1a
PASS	Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt	490fa0c07fbfb2122232c9946bb1152b5a3f0a8d
PASS	Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt	8720da037e07fb1288c7ff119415e846f8483782
PASS	Evidence/CP-013/CP013_Precedent_Test_Inspection.txt	154133126e4498a2f50515dd638cd32e9af73b27
PASS	Evidence/CP-013/CP013_Precommit_Git_Review.txt	5bf9c20483d8228e10a7605d1f48f10c5b61e799
PASS	Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt	99c0646006eb5158d61fc0a48d94bb0fc13bc25d
PASS	Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt	5ddc7d90b0f61505b9cab336fb1629ccb0f50a80
PASS	Evidence/CP-013/CP013_RED_Test_Output.txt	0651f6c49f27cbc79a39cbb3bb283e2e4c1b38d0
PASS	Evidence/CP-013/CP013_RED_Test_Verification.txt	7bf907adb2824596adb7586b973aefebc0b31c85
PASS	Evidence/CP-013/CP013_Rustfmt_Check_Output.txt	e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
PASS	Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt	fb6e89b73db5e992391a73321d8562ae21a8e176
PASS	Evidence/CP-013/CP013_Source_Inspection.txt	65dcb70d89d638f34ab76e0a30aec04a3b65d528
PASS	Evidence/CP-013/CP013_Staged_Whitespace_Recovery_Output.txt	e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
PASS	Evidence/CP-013/CP013_Staged_Whitespace_Recovery_Report.txt	c4e1c38ec42377e5c1a252465718b29fce30dbcd
PASS	Evidence/CP-013/CP013_Staging_Action_Report.txt	ddc2cc3f566ed4ed3e0d927c5cfe51c2cf0fcd79
PASS	Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt	124fc8d216d41773fe373fa46226568a2aa8066a
PASS	Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt	a11d3b59a1cdf118be9dc3b88662b6baa5f45eb3
PASS	Evidence/CP-013/CP013_Test_Authoring_Report.txt	9b5ba5b6f8ff81ee40a0cc13d7b064139398f5d7
PASS	Evidence/CP-013/CP013_Test_Formatting_Report.txt	18037ce47355fb21b656d3d14735a957c3b8123e
PASS	Evidence/CP-013/CP013_Test_Rustfmt_Output.txt	e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
PASS	Evidence/CP-013/CP013_WASM_Build_Output.txt	6f56aedba8899dc42cefc4d1e6f741cc09871c48
PASS	Evidence/CP-013/CP013_WASM_Build_Verification.txt	87586e87ae33a0dabc8ed078ab939af9b1b8daf1
PASS	Evidence/CP-013/CP013_Whitespace_Exception_Review.txt	718b425f6e80e1a1ea313e7e85ad32663f9acb37

=== WHITESPACE DIAGNOSTICS ===
(none)

=== FAILURES ===
(none)

=== ACCEPTANCE BOUNDARY ===
Lexical SCR-to-RCP candidate derivation only.
No filesystem publication or promotion.
Frozen parent requirements remain incomplete.
No independent adversarial QA claimed.
No Git banking without explicit T approval.

RESULT: PASS - FINAL STAGING VERIFICATION

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 1.95s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP008_source_eligibility.rs (target\debug\deps\CP008_source_eligibility-194c314726b26929.exe)

running 5 tests
test accepts_analyst_csv_final_extension_in_ascii_case_variants ... ok
test refuses_paths_traversal_and_external_references ... ok
test makes_no_case_or_unicode_normalization_claim ... ok
test refuses_reserved_namespace_even_if_name_looks_like_csv ... ok
test rejects_non_csv_or_nonfinal_csv_extensions ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP009_exact_root_snapshot.rs (target\debug\deps\CP009_exact_root_snapshot-b26a1b02e36e8f07.exe)

running 8 tests
test candidate_preflight_runs_before_root_matching ... ok
test duplicate_exact_entries_refuse_instead_of_picking_first ... ok
test full_filename_match_is_exact_and_case_sensitive ... ok
test finds_one_exact_reported_regular_file ... ok
test never_trims_to_find_a_different_physical_name ... ok
test reported_non_regular_entries_do_not_pass ... ok
test unicode_scalar_sequence_is_not_normalized ... ok
test result_is_order_independent_and_empty_snapshot_is_not_found ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP010_cvt_filename_candidate.rs (target\debug\deps\CP010_cvt_filename_candidate-ce216c0140f6b173.exe)

running 4 tests
test accepts_exact_canonical_cvt_csv_candidate ... ok
test refuses_paths_and_noncanonical_references ... ok
test refuses_wrong_classes_and_extensions ... ok
test refuses_malformed_canonical_identity ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP011_cvt_scr_candidate_identity.rs (target\debug\deps\CP011_cvt_scr_candidate_identity-8bc68fabbbb42eb4.exe)

running 6 tests
test derives_exact_corresponding_scr_identity ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_other_semantic_classes ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_paths_whitespace_and_noncanonical_names ... ok
test refuses_wrong_extension_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP012_scr_filename_candidate.rs (target\debug\deps\CP012_scr_filename_candidate-7c39746d8bb6fac7.exe)

running 6 tests
test accepts_canonical_scr_csv_candidate ... ok
test accepts_canonical_scr_txt_candidate ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_noncanonical_namespace_class_and_extension ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_and_whitespace ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP013_scr_rcp_candidate_identity.rs (target\debug\deps\CP013_scr_rcp_candidate_identity-4f7c7bea8654150d.exe)

running 6 tests
test derives_rcp_candidate_only_with_explicit_class ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_non_scr_and_noncanonical_source_classes ... ok
test refuses_invalid_identity_paths_and_whitespace ... ok
test refuses_unsupported_or_incorrectly_cased_final_classes ... ok
test refuses_wrong_or_ambiguous_serialization_extensions ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)

running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_registered_emittable_classes ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)

running 4 tests
test constructs_exact_canonical_filename_candidates ... ok
test preserves_extension_without_case_or_unicode_normalization ... ok
test refuses_noncanonical_class_without_repair ... ok
test refuses_invalid_timestamp_uuid_and_empty_extension ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)

running 3 tests
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)

running 6 tests
test recognizes_governed_namespace_and_class ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_invalid_class_boundaries ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)

running 4 tests
test extracts_semantic_class_and_serialization_separately ... ok
test extension_does_not_determine_semantic_class ... ok
test preserves_literal_tokens_without_claiming_authority ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

running 3 tests
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok
test rejects_nonexistent_gregorian_dates ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests data_sculptor_core

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 1.13s
     Running tests\CP013_scr_rcp_candidate_identity.rs (target\debug\deps\CP013_scr_rcp_candidate_identity-4f7c7bea8654150d.exe)

running 6 tests
test derives_rcp_candidate_only_with_explicit_class ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_non_scr_and_noncanonical_source_classes ... ok
test refuses_invalid_identity_paths_and_whitespace ... ok
test refuses_unsupported_or_incorrectly_cased_final_classes ... ok
test refuses_wrong_or_ambiguous_serialization_extensions ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

WASM-002 CP013 GIT BYTE PRESERVATION PREFLIGHT
Timestamp: 2026-10-13 21:23:45 -03:00
Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
FILES_CHECKED=29
RAW_BYTES_PRESERVED=8
GIT_TRANSFORMED_FILES=21
GIT_STAGING_PERFORMED=False
SOURCE_MODIFIED=False
HISTORICAL_EVIDENCE_MODIFIED=False
DAY_066=OPEN

=== FILE HASH COMPARISONS ===
FILE=src/lib.rs
RAW_BLOB=b2df81ba4946220e85543b44bd8ab33e3a341f9e
GIT_CLEAN_BLOB=b2df81ba4946220e85543b44bd8ab33e3a341f9e
BYTES_PRESERVED_IF_STAGED=True

FILE=tests/CP013_scr_rcp_candidate_identity.rs
RAW_BLOB=f512948ac406169c9c2e454a3814103b75bf3e24
GIT_CLEAN_BLOB=f512948ac406169c9c2e454a3814103b75bf3e24
BYTES_PRESERVED_IF_STAGED=True

FILE=Evidence/CP-013/.gitattributes
RAW_BLOB=e72aeef0d117129ce236f749a977c88c5d476fe5
GIT_CLEAN_BLOB=76c35bd65a4609cb3ee9c3480318aff04a1bc604
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_Approved_Scope_Lock.txt
RAW_BLOB=b8bc3bd6c76f89dd2b9666de8be27e63fbba3a43
GIT_CLEAN_BLOB=5d1e825a3b85ae4a8a64628ec127bd585e960e61
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_Full_Regression_Test_Output.txt
RAW_BLOB=f5a449cf20643c9ab32ffa70fd42ba598bc35a8a
GIT_CLEAN_BLOB=f5a449cf20643c9ab32ffa70fd42ba598bc35a8a
BYTES_PRESERVED_IF_STAGED=True

FILE=Evidence/CP-013/CP013_Full_Regression_Verification.txt
RAW_BLOB=4632d651638cd57e9da841bfef854dcebc645683
GIT_CLEAN_BLOB=0cfc0733f304393ccbe9abf0e4cae9a3bb1c33cb
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_GREEN_Implementation_Report.txt
RAW_BLOB=4d79c7eb970b267a9328638008a9c2df3cbddb6d
GIT_CLEAN_BLOB=9710f35e747d15fc9ba2cce020d458c8b3d910f8
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_GREEN_Test_Output.txt
RAW_BLOB=c319ce343f8a09041ecfaa85c5fa7d190dc6aa57
GIT_CLEAN_BLOB=c319ce343f8a09041ecfaa85c5fa7d190dc6aa57
BYTES_PRESERVED_IF_STAGED=True

FILE=Evidence/CP-013/CP013_GREEN_Test_Verification.txt
RAW_BLOB=32e085d02532cfa358e7d6940bcc0d12ea25354f
GIT_CLEAN_BLOB=4db942b6bb16de2a785727420a29f8982c60a5ea
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_Hash_Inventory.txt
RAW_BLOB=a1f5df08f90d5d4ea5be238d52251dd855ae9b0b
GIT_CLEAN_BLOB=cfe0f66fbc25345f460b3113ddeebc70aed27405
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_Hash_Inventory_Verification.txt
RAW_BLOB=4eb11024534c02c46bbd0b8331bfd81ee6d98017
GIT_CLEAN_BLOB=498d6870e7f75c178d209ebf9735c82bdbbcb60f
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_Opening_Git_Preflight.txt
RAW_BLOB=51aeaf3e50206991f3ccf49053968ed7e1338c1a
GIT_CLEAN_BLOB=558f3b477b2920cc526e4159fda2b6bcbbcfcb65
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_Precedent_Test_Inspection.txt
RAW_BLOB=154133126e4498a2f50515dd638cd32e9af73b27
GIT_CLEAN_BLOB=9ac760fa1a501705efb858b8f8d82d1a6e2b771a
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_Precommit_Git_Review.txt
RAW_BLOB=5bf9c20483d8228e10a7605d1f48f10c5b61e799
GIT_CLEAN_BLOB=f758a02712e7fdf87c53b250170fda6f1efac87e
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt
RAW_BLOB=99c0646006eb5158d61fc0a48d94bb0fc13bc25d
GIT_CLEAN_BLOB=04acb7ef8108cfbb98a346e852cd5af82782509a
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt
RAW_BLOB=5ddc7d90b0f61505b9cab336fb1629ccb0f50a80
GIT_CLEAN_BLOB=a7d1aa0cf30615dec242805b90f2043c43c4a12c
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_RED_Test_Output.txt
RAW_BLOB=0651f6c49f27cbc79a39cbb3bb283e2e4c1b38d0
GIT_CLEAN_BLOB=0651f6c49f27cbc79a39cbb3bb283e2e4c1b38d0
BYTES_PRESERVED_IF_STAGED=True

FILE=Evidence/CP-013/CP013_RED_Test_Verification.txt
RAW_BLOB=7bf907adb2824596adb7586b973aefebc0b31c85
GIT_CLEAN_BLOB=d4c2cd3cf2c773ebce3a8e35150822bcdfd825b3
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_Rustfmt_Check_Output.txt
RAW_BLOB=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
GIT_CLEAN_BLOB=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
BYTES_PRESERVED_IF_STAGED=True

FILE=Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt
RAW_BLOB=fb6e89b73db5e992391a73321d8562ae21a8e176
GIT_CLEAN_BLOB=6ff17699077f8e8c79bf1c0f1c48202e47c12580
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_Source_Inspection.txt
RAW_BLOB=65dcb70d89d638f34ab76e0a30aec04a3b65d528
GIT_CLEAN_BLOB=073a1a73b510f017c141bb74387b1740dd637efc
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt
RAW_BLOB=124fc8d216d41773fe373fa46226568a2aa8066a
GIT_CLEAN_BLOB=84f6563602a8297f1fd0ca44962063940a486d50
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt
RAW_BLOB=a11d3b59a1cdf118be9dc3b88662b6baa5f45eb3
GIT_CLEAN_BLOB=cfc7c6008b5d748498bba33f810ca411345bed49
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_Test_Authoring_Report.txt
RAW_BLOB=9b5ba5b6f8ff81ee40a0cc13d7b064139398f5d7
GIT_CLEAN_BLOB=902882b8f9cee4fcf88b69e0c2cfd50684391680
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_Test_Formatting_Report.txt
RAW_BLOB=18037ce47355fb21b656d3d14735a957c3b8123e
GIT_CLEAN_BLOB=f975e240ff9d4901417c5afa904d0d2e03504939
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_Test_Rustfmt_Output.txt
RAW_BLOB=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
GIT_CLEAN_BLOB=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
BYTES_PRESERVED_IF_STAGED=True

FILE=Evidence/CP-013/CP013_WASM_Build_Output.txt
RAW_BLOB=6f56aedba8899dc42cefc4d1e6f741cc09871c48
GIT_CLEAN_BLOB=6f56aedba8899dc42cefc4d1e6f741cc09871c48
BYTES_PRESERVED_IF_STAGED=True

FILE=Evidence/CP-013/CP013_WASM_Build_Verification.txt
RAW_BLOB=87586e87ae33a0dabc8ed078ab939af9b1b8daf1
GIT_CLEAN_BLOB=7753c919782568faab8035399118a09d3851a3e3
BYTES_PRESERVED_IF_STAGED=False

FILE=Evidence/CP-013/CP013_Whitespace_Exception_Review.txt
RAW_BLOB=718b425f6e80e1a1ea313e7e85ad32663f9acb37
GIT_CLEAN_BLOB=5695a284bf3cd183e4d8022227bfe6e1e29ebced
BYTES_PRESERVED_IF_STAGED=False

=== POSSIBLE GIT TRANSFORMATIONS ===
Evidence/CP-013/.gitattributes
Evidence/CP-013/CP013_Approved_Scope_Lock.txt
Evidence/CP-013/CP013_Full_Regression_Verification.txt
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt
Evidence/CP-013/CP013_GREEN_Test_Verification.txt
Evidence/CP-013/CP013_Hash_Inventory.txt
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt
Evidence/CP-013/CP013_Opening_Git_Preflight.txt
Evidence/CP-013/CP013_Precedent_Test_Inspection.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt
Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt
Evidence/CP-013/CP013_RED_Test_Verification.txt
Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt
Evidence/CP-013/CP013_Source_Inspection.txt
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt
Evidence/CP-013/CP013_Test_Authoring_Report.txt
Evidence/CP-013/CP013_Test_Formatting_Report.txt
Evidence/CP-013/CP013_WASM_Build_Verification.txt
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt

RESULT: REVIEW REQUIRED - GIT TRANSFORMATIONS

WASM-002 CP013 SHA256 INVENTORY VERIFICATION
Timestamp: 2026-10-13 21:11:23 -03:00
Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
INVENTORY_SHA256=3D88250E36BADBED442FFBDD819A013F0CD903465ED7D4956D06282E9E99D73D
EXPECTED_RECORDS=21
VERIFIED_RECORDS=21
EVIDENCE_RECORDS=19
EVIDENCE_SET_MATCH=True
FAILURE_COUNT=0
HASH_ALGORITHM=SHA256
SOURCE_MODIFIED_BY_VERIFICATION=False
DAY_066=OPEN

=== INDIVIDUAL FILE VERIFICATION ===
PASS	Evidence/CP-013/CP013_Approved_Scope_Lock.txt	2236
PASS	Evidence/CP-013/CP013_Full_Regression_Test_Output.txt	6617
PASS	Evidence/CP-013/CP013_Full_Regression_Verification.txt	674
PASS	Evidence/CP-013/CP013_GREEN_Implementation_Report.txt	752
PASS	Evidence/CP-013/CP013_GREEN_Test_Output.txt	767
PASS	Evidence/CP-013/CP013_GREEN_Test_Verification.txt	692
PASS	Evidence/CP-013/CP013_Opening_Git_Preflight.txt	340
PASS	Evidence/CP-013/CP013_Precedent_Test_Inspection.txt	8512
PASS	Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt	568
PASS	Evidence/CP-013/CP013_RED_Test_Output.txt	607
PASS	Evidence/CP-013/CP013_RED_Test_Verification.txt	551
PASS	Evidence/CP-013/CP013_Rustfmt_Check_Output.txt	0
PASS	Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt	526
PASS	Evidence/CP-013/CP013_Source_Inspection.txt	15768
PASS	Evidence/CP-013/CP013_Test_Authoring_Report.txt	446
PASS	Evidence/CP-013/CP013_Test_Formatting_Report.txt	524
PASS	Evidence/CP-013/CP013_Test_Rustfmt_Output.txt	0
PASS	Evidence/CP-013/CP013_WASM_Build_Output.txt	159
PASS	Evidence/CP-013/CP013_WASM_Build_Verification.txt	713
PASS	src/lib.rs	12312
PASS	tests/CP013_scr_rcp_candidate_identity.rs	2727

=== FAILURES ===
(none)

RESULT: PASS - ALL 21 HASHES VERIFIED

WASM-002 CP013 POST-NORMALIZATION HASH VERIFICATION
Timestamp: 2026-10-13 21:35:58 -03:00
Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
EXPECTED_EFFECTIVE_FILES=32
VERIFIED_EFFECTIVE_FILES=32
GIT_BYTE_PRESERVED_FILES=32
EVIDENCE_SET_MATCH=True
UNTRACKED_SET_MATCH=True
FAILURE_COUNT=0
HISTORICAL_INVENTORIES_REWRITTEN=False
GIT_STAGING_PERFORMED=False
DAY_066=OPEN

=== INDIVIDUAL VERIFICATION ===
FILE=Evidence/CP-013/.gitattributes
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Approved_Scope_Lock.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Full_Regression_Test_Output.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Full_Regression_Verification.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_GREEN_Implementation_Report.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_GREEN_Test_Output.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_GREEN_Test_Verification.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Hash_Inventory.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Hash_Inventory_Verification.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Opening_Git_Preflight.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Precedent_Test_Inspection.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Precommit_Git_Review.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_RED_Test_Output.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_RED_Test_Verification.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Rustfmt_Check_Output.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Source_Inspection.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Test_Authoring_Report.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Test_Formatting_Report.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Test_Rustfmt_Output.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_WASM_Build_Output.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_WASM_Build_Verification.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=Evidence/CP-013/CP013_Whitespace_Exception_Review.txt
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=src/lib.rs
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

FILE=tests/CP013_scr_rcp_candidate_identity.rs
HASH_MATCH=True
GIT_BYTES_PRESERVED=True

=== FAILURES ===
(none)
RESULT: PASS - 32 EFFECTIVE FILES VERIFIED

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
error[E0432]: unresolved import `data_sculptor_core::build_final_filename_candidate_for_scr`
 --> tests\CP013_scr_rcp_candidate_identity.rs:6:5
  |
6 | use data_sculptor_core::build_final_filename_candidate_for_scr;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `build_final_filename_candidate_for_scr` in the root

For more information about this error, try `rustc --explain E0432`.
error: could not compile `data_sculptor_core` (test "CP013_scr_rcp_candidate_identity") due to 1 previous error

WASM-002 CP013 RUSTFMT CHECK VERIFICATION
Timestamp: 2026-10-13 21:04:24 -03:00
Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Command: cargo +1.97.1 fmt --all -- --check
FORMAT_EXIT=0
SOURCE_SHA256=99741F26933AA8EEDBF1E75031F5012CA01918D06E1A3D013CA1703A49842649
SOURCE_UNCHANGED=True
FROZEN_TEST_UNCHANGED=True
TRACKED_CHANGE_SET_VALID=True
RUSTFMT_LOG_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
READ_ONLY_CHECK=True
FULL_REGRESSION_EXECUTED=False
DAY_066=OPEN
RESULT: PASS

WASM-002 CP013 CONTROLLED GIT STAGING
Timestamp: 2026-10-13 21:38:26 -03:00
Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
EXPECTED_STAGED_FILES=34
ACTUAL_STAGED_FILES=34
STAGED_SET_MATCH=True
STAGED_BLOBS_VERIFIED=34
BLOB_FAILURES=0
STAGED_WHITESPACE_EXIT=2
GIT_COMMIT_PERFORMED=False
STAGING_REPORT_NOT_YET_STAGED=True
DAY_066=OPEN

=== STAGED BLOB VERIFICATION ===
PASS	src/lib.rs	b2df81ba4946220e85543b44bd8ab33e3a341f9e
PASS	tests/CP013_scr_rcp_candidate_identity.rs	f512948ac406169c9c2e454a3814103b75bf3e24
PASS	Evidence/CP-013/.gitattributes	360724538f7d577ea34b299a87aa55eb0ad400e7
PASS	Evidence/CP-013/CP013_Approved_Scope_Lock.txt	b8bc3bd6c76f89dd2b9666de8be27e63fbba3a43
PASS	Evidence/CP-013/CP013_Full_Regression_Test_Output.txt	f5a449cf20643c9ab32ffa70fd42ba598bc35a8a
PASS	Evidence/CP-013/CP013_Full_Regression_Verification.txt	4632d651638cd57e9da841bfef854dcebc645683
PASS	Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt	01395098a88f9feced444983f3e9f81e30f76095
PASS	Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt	203d5c62dff3e9d7e244eca005a29101615ea8c4
PASS	Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt	92ae84193d99d78c9c379ca86052b48333f879f7
PASS	Evidence/CP-013/CP013_GREEN_Implementation_Report.txt	4d79c7eb970b267a9328638008a9c2df3cbddb6d
PASS	Evidence/CP-013/CP013_GREEN_Test_Output.txt	c319ce343f8a09041ecfaa85c5fa7d190dc6aa57
PASS	Evidence/CP-013/CP013_GREEN_Test_Verification.txt	32e085d02532cfa358e7d6940bcc0d12ea25354f
PASS	Evidence/CP-013/CP013_Hash_Inventory.txt	a1f5df08f90d5d4ea5be238d52251dd855ae9b0b
PASS	Evidence/CP-013/CP013_Hash_Inventory_Verification.txt	4eb11024534c02c46bbd0b8331bfd81ee6d98017
PASS	Evidence/CP-013/CP013_Opening_Git_Preflight.txt	51aeaf3e50206991f3ccf49053968ed7e1338c1a
PASS	Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt	490fa0c07fbfb2122232c9946bb1152b5a3f0a8d
PASS	Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt	8720da037e07fb1288c7ff119415e846f8483782
PASS	Evidence/CP-013/CP013_Precedent_Test_Inspection.txt	154133126e4498a2f50515dd638cd32e9af73b27
PASS	Evidence/CP-013/CP013_Precommit_Git_Review.txt	5bf9c20483d8228e10a7605d1f48f10c5b61e799
PASS	Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt	99c0646006eb5158d61fc0a48d94bb0fc13bc25d
PASS	Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt	5ddc7d90b0f61505b9cab336fb1629ccb0f50a80
PASS	Evidence/CP-013/CP013_RED_Test_Output.txt	0651f6c49f27cbc79a39cbb3bb283e2e4c1b38d0
PASS	Evidence/CP-013/CP013_RED_Test_Verification.txt	7bf907adb2824596adb7586b973aefebc0b31c85
PASS	Evidence/CP-013/CP013_Rustfmt_Check_Output.txt	e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
PASS	Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt	fb6e89b73db5e992391a73321d8562ae21a8e176
PASS	Evidence/CP-013/CP013_Source_Inspection.txt	65dcb70d89d638f34ab76e0a30aec04a3b65d528
PASS	Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt	124fc8d216d41773fe373fa46226568a2aa8066a
PASS	Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt	a11d3b59a1cdf118be9dc3b88662b6baa5f45eb3
PASS	Evidence/CP-013/CP013_Test_Authoring_Report.txt	9b5ba5b6f8ff81ee40a0cc13d7b064139398f5d7
PASS	Evidence/CP-013/CP013_Test_Formatting_Report.txt	18037ce47355fb21b656d3d14735a957c3b8123e
PASS	Evidence/CP-013/CP013_Test_Rustfmt_Output.txt	e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
PASS	Evidence/CP-013/CP013_WASM_Build_Output.txt	6f56aedba8899dc42cefc4d1e6f741cc09871c48
PASS	Evidence/CP-013/CP013_WASM_Build_Verification.txt	87586e87ae33a0dabc8ed078ab939af9b1b8daf1
PASS	Evidence/CP-013/CP013_Whitespace_Exception_Review.txt	718b425f6e80e1a1ea313e7e85ad32663f9acb37

=== WHITESPACE DIAGNOSTICS ===
Evidence/CP-013/.gitattributes:1: trailing whitespace.
+# CP013 raw evidence whitespace exceptions
Evidence/CP-013/.gitattributes:2: trailing whitespace.
+# Preserve original diagnostic evidence bytes.
Evidence/CP-013/.gitattributes:3: trailing whitespace.
+CP013_Source_Inspection.txt whitespace=-blank-at-eol
Evidence/CP-013/.gitattributes:4: trailing whitespace.
+CP013_Precedent_Test_Inspection.txt whitespace=-blank-at-eol
Evidence/CP-013/.gitattributes:5: trailing whitespace.
+CP013_GREEN_Test_Output.txt whitespace=-blank-at-eof
Evidence/CP-013/.gitattributes:6: trailing whitespace.
+CP013_Full_Regression_Test_Output.txt whitespace=-blank-at-eof
Evidence/CP-013/.gitattributes:7: trailing whitespace.
+# Preserve CP013 evidence bytes against inherited text normalization.
Evidence/CP-013/.gitattributes:8: trailing whitespace.
+CP013_*.txt -text
Evidence/CP-013/.gitattributes:9: trailing whitespace.
+.gitattributes -text
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:1: trailing whitespace.
+RED5SORCERY DATA SCULPTOR
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:2: trailing whitespace.
+WASM-002 CP013 APPROVED SCOPE LOCK
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:3: trailing whitespace.
+DAY 066 - OPEN
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:4: trailing whitespace.
+
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:5: trailing whitespace.
+Recorded UTC: 2026-10-13T23:53:22Z
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:6: trailing whitespace.
+Parent Git HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:7: trailing whitespace.
+Approval authority: T
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:8: trailing whitespace.
+Approval: EXPLICIT - RECORDED IN CHAT
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:9: trailing whitespace.
+Scope status: LOCKED
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:10: trailing whitespace.
+
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:11: trailing whitespace.
+TITLE
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:12: trailing whitespace.
+Explicit SCR-to-RCP Final Filename Candidate Derivation
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:13: trailing whitespace.
+
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:14: trailing whitespace.
+FROZEN REQUIREMENT ANCHORS
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:15: trailing whitespace.
+W002-STOR-023.1 - PARTIAL
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:16: trailing whitespace.
+W002-STOR-023 - NOT_STARTED
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:17: trailing whitespace.
+
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:18: trailing whitespace.
+PUBLIC RUST FUNCTION
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:19: trailing whitespace.
+build_final_filename_candidate_for_scr
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:20: trailing whitespace.
+Inputs: scr_filename, intended_final_class
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:21: trailing whitespace.
+Return: Option<String>
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:22: trailing whitespace.
+
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:23: trailing whitespace.
+ACCEPTED BEHAVIOR
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:24: trailing whitespace.
+1. Require a canonical SCR staging filename candidate.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:25: trailing whitespace.
+2. Require explicit intended_final_class exactly RCP.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:26: trailing whitespace.
+3. Require the SCR serialization extension exactly txt.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:27: trailing whitespace.
+4. Construct the corresponding RCP filename candidate.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:28: trailing whitespace.
+5. Preserve UTC timestamp and UUID unchanged.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:29: trailing whitespace.
+6. Preserve the lowercase txt serialization extension.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:30: trailing whitespace.
+7. Change only the semantic class token SCR to RCP.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:31: trailing whitespace.
+8. Return None for malformed or unsupported inputs.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:32: trailing whitespace.
+9. Reuse existing canonical filename validation.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:33: trailing whitespace.
+
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:34: trailing whitespace.
+MANDATORY REFUSALS
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:35: trailing whitespace.
+Non-SCR input.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:36: trailing whitespace.
+Unsupported or incorrectly cased final class.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:37: trailing whitespace.
+Extensions other than exact lowercase txt.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:38: trailing whitespace.
+Invalid UTC timestamp or UUID.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:39: trailing whitespace.
+Whitespace, path separators, or noncanonical identity.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:40: trailing whitespace.
+
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:41: trailing whitespace.
+OUT OF SCOPE
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:42: trailing whitespace.
+No filesystem reads or writes.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:43: trailing whitespace.
+No staging or final artifact creation.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:44: trailing whitespace.
+No rename, promotion, or publication.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:45: trailing whitespace.
+No Receipt validation or provenance verification.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:46: trailing whitespace.
+No conversion, recovery, or orphan adoption.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:47: trailing whitespace.
+No inference of intended class from extension.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:48: trailing whitespace.
+No authority or requirement completion claim.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:49: trailing whitespace.
+
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:50: trailing whitespace.
+PLDD EXECUTION
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:51: trailing whitespace.
+Author approximately six focused RED tests.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:52: trailing whitespace.
+Format tests before RED.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:53: trailing whitespace.
+Record exact test-file SHA256 before RED.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:54: trailing whitespace.
+Require expected missing-symbol RED failure.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:55: trailing whitespace.
+Implement minimal GREEN.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:56: trailing whitespace.
+Run targeted and full native regression.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:57: trailing whitespace.
+Verify Rustfmt and canonical WASM build.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:58: trailing whitespace.
+Preserve TXT evidence and SHA256 inventories.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:59: trailing whitespace.
+Complete Git reviews before human acceptance.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:60: trailing whitespace.
+Do not bank without explicit T approval.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:61: trailing whitespace.
+
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:62: trailing whitespace.
+ACCEPTANCE BOUNDARY
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:63: trailing whitespace.
+CP013 may establish lexical candidate derivation only.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:64: trailing whitespace.
+Frozen parent requirements remain incomplete.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:65: trailing whitespace.
+Independent adversarial QA is not claimed.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:66: trailing whitespace.
+DAY 066 REMAINS OPEN.
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:67: trailing whitespace.
+
Evidence/CP-013/CP013_Approved_Scope_Lock.txt:68: trailing whitespace.
+RESULT: APPROVED SCOPE RECORDED
Evidence/CP-013/CP013_Full_Regression_Verification.txt:1: trailing whitespace.
+WASM-002 CP013 FULL NATIVE REGRESSION
Evidence/CP-013/CP013_Full_Regression_Verification.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 21:06:10 -03:00
Evidence/CP-013/CP013_Full_Regression_Verification.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Full_Regression_Verification.txt:4: trailing whitespace.
+Command: cargo +1.97.1 test
Evidence/CP-013/CP013_Full_Regression_Verification.txt:5: trailing whitespace.
+CARGO_EXIT=0
Evidence/CP-013/CP013_Full_Regression_Verification.txt:6: trailing whitespace.
+TEST_SUITES_REPORTED=14
Evidence/CP-013/CP013_Full_Regression_Verification.txt:7: trailing whitespace.
+EXPECTED_PASSED=58
Evidence/CP-013/CP013_Full_Regression_Verification.txt:8: trailing whitespace.
+ACTUAL_PASSED=58
Evidence/CP-013/CP013_Full_Regression_Verification.txt:9: trailing whitespace.
+ACTUAL_FAILED=0
Evidence/CP-013/CP013_Full_Regression_Verification.txt:10: trailing whitespace.
+SOURCE_UNCHANGED=True
Evidence/CP-013/CP013_Full_Regression_Verification.txt:11: trailing whitespace.
+FROZEN_TEST_UNCHANGED=True
Evidence/CP-013/CP013_Full_Regression_Verification.txt:12: trailing whitespace.
+TRACKED_CHANGE_SET_VALID=True
Evidence/CP-013/CP013_Full_Regression_Verification.txt:13: trailing whitespace.
+SOURCE_SHA256=99741F26933AA8EEDBF1E75031F5012CA01918D06E1A3D013CA1703A49842649
Evidence/CP-013/CP013_Full_Regression_Verification.txt:14: trailing whitespace.
+TEST_SHA256=758FE6ECED824B1D05277C414D1BD223F062B3A1AA15AA1D1E3D90BD069452D3
Evidence/CP-013/CP013_Full_Regression_Verification.txt:15: trailing whitespace.
+REGRESSION_LOG_SHA256=CDF724B92EBC09B1D49E53A76249B3A909B2E2DD3F5014DDE5710FCBADBC0BD7
Evidence/CP-013/CP013_Full_Regression_Verification.txt:16: trailing whitespace.
+CANONICAL_WASM_BUILD_EXECUTED=False
Evidence/CP-013/CP013_Full_Regression_Verification.txt:17: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_Full_Regression_Verification.txt:18: trailing whitespace.
+RESULT: PASS - FULL NATIVE REGRESSION
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt:1: trailing whitespace.
+WASM-002 CP013 GREEN IMPLEMENTATION REPORT
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 21:00:51 -03:00
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt:4: trailing whitespace.
+Scope: APPROVED AND LOCKED
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt:5: trailing whitespace.
+Function: build_final_filename_candidate_for_scr
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt:6: trailing whitespace.
+SOURCE_SHA256_BEFORE=E28C62D1413D782EC715FB6DC56CA421B8B3793F557442B25D20D34243342153
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt:7: trailing whitespace.
+SOURCE_SHA256_AFTER=99741F26933AA8EEDBF1E75031F5012CA01918D06E1A3D013CA1703A49842649
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt:8: trailing whitespace.
+SOURCE_BLOB_BEFORE=b59ee4678de5c956107766f75e867dd1c1f4a352
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt:9: trailing whitespace.
+SOURCE_BLOB_AFTER=b2df81ba4946220e85543b44bd8ab33e3a341f9e
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt:10: trailing whitespace.
+FROZEN_TEST_SHA256=758FE6ECED824B1D05277C414D1BD223F062B3A1AA15AA1D1E3D90BD069452D3
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt:11: trailing whitespace.
+FROZEN_TEST_UNCHANGED=True
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt:12: trailing whitespace.
+TRACKED_CHANGE_SET=src/lib.rs
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt:13: trailing whitespace.
+GREEN_TESTS_EXECUTED=False
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt:14: trailing whitespace.
+FILESYSTEM_PUBLICATION_IMPLEMENTED=False
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt:15: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_GREEN_Implementation_Report.txt:16: trailing whitespace.
+RESULT: PASS
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:1: trailing whitespace.
+WASM-002 CP013 GREEN TEST VERIFICATION
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 21:02:36 -03:00
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:4: trailing whitespace.
+Command: cargo +1.97.1 test --test CP013_scr_rcp_candidate_identity
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:5: trailing whitespace.
+CARGO_EXIT=0
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:6: trailing whitespace.
+SIX_TESTS_STARTED=True
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:7: trailing whitespace.
+SIX_TESTS_PASSED=True
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:8: trailing whitespace.
+SOURCE_UNCHANGED=True
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:9: trailing whitespace.
+FROZEN_TEST_UNCHANGED=True
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:10: trailing whitespace.
+TRACKED_CHANGE_SET_VALID=True
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:11: trailing whitespace.
+SOURCE_SHA256=99741F26933AA8EEDBF1E75031F5012CA01918D06E1A3D013CA1703A49842649
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:12: trailing whitespace.
+TEST_SHA256=758FE6ECED824B1D05277C414D1BD223F062B3A1AA15AA1D1E3D90BD069452D3
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:13: trailing whitespace.
+GREEN_LOG_SHA256=09DEE35F2106EEE09F0E9DA838616569E221FF649B6FDE9CA286332104E75C1E
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:14: trailing whitespace.
+FULL_REGRESSION_EXECUTED=False
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:15: trailing whitespace.
+WASM_BUILD_EXECUTED=False
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:16: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_GREEN_Test_Verification.txt:17: trailing whitespace.
+RESULT: PASS - SIX GREEN TESTS
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:1: trailing whitespace.
+WASM-002 CP013 GIT BYTE PRESERVATION CORRECTION
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 21:28:32 -03:00
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:4: trailing whitespace.
+ATTRIBUTES_SHA256_BEFORE=24524EBCCCC01067F9E4D1DA67DCB855CC670458309DBFBF5AF84F1D22AC7B2A
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:5: trailing whitespace.
+ATTRIBUTES_SHA256_AFTER=1EBEA3A50E9A71FB77D43421B1F5FAC20265DF011C67B5B52491B2ADE83112FB
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:6: trailing whitespace.
+CORRECTION_SCOPE=Evidence/CP-013
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:7: trailing whitespace.
+CORRECTION_RULES=2
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:8: trailing whitespace.
+FILES_CHECKED=31
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:9: trailing whitespace.
+BYTES_PRESERVED=31
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:10: trailing whitespace.
+GIT_TRANSFORMED_FILES=0
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:11: trailing whitespace.
+UNEXPECTED_FILE_CHANGES=0
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:12: trailing whitespace.
+ATTRIBUTE_FAILURES=0
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:13: trailing whitespace.
+HISTORICAL_INVENTORIES_REWRITTEN=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:14: trailing whitespace.
+GIT_STAGING_PERFORMED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:15: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:16: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:17: trailing whitespace.
+=== ATTRIBUTE CHECKS ===
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:18: trailing whitespace.
+Evidence/CP-013/.gitattributes: text: unset
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:19: trailing whitespace.
+Evidence/CP-013/CP013_Source_Inspection.txt: text: unset
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:20: trailing whitespace.
+Evidence/CP-013/CP013_Precedent_Test_Inspection.txt: text: unset
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:21: trailing whitespace.
+Evidence/CP-013/CP013_GREEN_Test_Output.txt: text: unset
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:22: trailing whitespace.
+Evidence/CP-013/CP013_Full_Regression_Test_Output.txt: text: unset
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:23: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:24: trailing whitespace.
+=== BYTE COMPARISONS ===
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:25: trailing whitespace.
+FILE=src/lib.rs
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:26: trailing whitespace.
+RAW=b2df81ba4946220e85543b44bd8ab33e3a341f9e
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:27: trailing whitespace.
+GIT_CLEAN=b2df81ba4946220e85543b44bd8ab33e3a341f9e
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:28: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:29: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:30: trailing whitespace.
+FILE=tests/CP013_scr_rcp_candidate_identity.rs
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:31: trailing whitespace.
+RAW=f512948ac406169c9c2e454a3814103b75bf3e24
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:32: trailing whitespace.
+GIT_CLEAN=f512948ac406169c9c2e454a3814103b75bf3e24
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:33: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:34: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:35: trailing whitespace.
+FILE=Evidence/CP-013/.gitattributes
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:36: trailing whitespace.
+RAW=360724538f7d577ea34b299a87aa55eb0ad400e7
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:37: trailing whitespace.
+GIT_CLEAN=360724538f7d577ea34b299a87aa55eb0ad400e7
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:38: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:39: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:40: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Approved_Scope_Lock.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:41: trailing whitespace.
+RAW=b8bc3bd6c76f89dd2b9666de8be27e63fbba3a43
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:42: trailing whitespace.
+GIT_CLEAN=b8bc3bd6c76f89dd2b9666de8be27e63fbba3a43
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:43: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:44: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:45: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Full_Regression_Test_Output.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:46: trailing whitespace.
+RAW=f5a449cf20643c9ab32ffa70fd42ba598bc35a8a
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:47: trailing whitespace.
+GIT_CLEAN=f5a449cf20643c9ab32ffa70fd42ba598bc35a8a
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:48: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:49: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:50: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Full_Regression_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:51: trailing whitespace.
+RAW=4632d651638cd57e9da841bfef854dcebc645683
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:52: trailing whitespace.
+GIT_CLEAN=4632d651638cd57e9da841bfef854dcebc645683
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:53: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:54: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:55: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:56: trailing whitespace.
+RAW=203d5c62dff3e9d7e244eca005a29101615ea8c4
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:57: trailing whitespace.
+GIT_CLEAN=203d5c62dff3e9d7e244eca005a29101615ea8c4
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:58: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:59: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:60: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:61: trailing whitespace.
+RAW=92ae84193d99d78c9c379ca86052b48333f879f7
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:62: trailing whitespace.
+GIT_CLEAN=92ae84193d99d78c9c379ca86052b48333f879f7
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:63: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:64: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:65: trailing whitespace.
+FILE=Evidence/CP-013/CP013_GREEN_Implementation_Report.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:66: trailing whitespace.
+RAW=4d79c7eb970b267a9328638008a9c2df3cbddb6d
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:67: trailing whitespace.
+GIT_CLEAN=4d79c7eb970b267a9328638008a9c2df3cbddb6d
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:68: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:69: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:70: trailing whitespace.
+FILE=Evidence/CP-013/CP013_GREEN_Test_Output.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:71: trailing whitespace.
+RAW=c319ce343f8a09041ecfaa85c5fa7d190dc6aa57
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:72: trailing whitespace.
+GIT_CLEAN=c319ce343f8a09041ecfaa85c5fa7d190dc6aa57
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:73: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:74: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:75: trailing whitespace.
+FILE=Evidence/CP-013/CP013_GREEN_Test_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:76: trailing whitespace.
+RAW=32e085d02532cfa358e7d6940bcc0d12ea25354f
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:77: trailing whitespace.
+GIT_CLEAN=32e085d02532cfa358e7d6940bcc0d12ea25354f
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:78: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:79: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:80: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Hash_Inventory.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:81: trailing whitespace.
+RAW=a1f5df08f90d5d4ea5be238d52251dd855ae9b0b
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:82: trailing whitespace.
+GIT_CLEAN=a1f5df08f90d5d4ea5be238d52251dd855ae9b0b
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:83: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:84: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:85: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Hash_Inventory_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:86: trailing whitespace.
+RAW=4eb11024534c02c46bbd0b8331bfd81ee6d98017
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:87: trailing whitespace.
+GIT_CLEAN=4eb11024534c02c46bbd0b8331bfd81ee6d98017
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:88: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:89: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:90: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Opening_Git_Preflight.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:91: trailing whitespace.
+RAW=51aeaf3e50206991f3ccf49053968ed7e1338c1a
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:92: trailing whitespace.
+GIT_CLEAN=51aeaf3e50206991f3ccf49053968ed7e1338c1a
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:93: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:94: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:95: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Precedent_Test_Inspection.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:96: trailing whitespace.
+RAW=154133126e4498a2f50515dd638cd32e9af73b27
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:97: trailing whitespace.
+GIT_CLEAN=154133126e4498a2f50515dd638cd32e9af73b27
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:98: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:99: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:100: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Precommit_Git_Review.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:101: trailing whitespace.
+RAW=5bf9c20483d8228e10a7605d1f48f10c5b61e799
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:102: trailing whitespace.
+GIT_CLEAN=5bf9c20483d8228e10a7605d1f48f10c5b61e799
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:103: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:104: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:105: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:106: trailing whitespace.
+RAW=99c0646006eb5158d61fc0a48d94bb0fc13bc25d
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:107: trailing whitespace.
+GIT_CLEAN=99c0646006eb5158d61fc0a48d94bb0fc13bc25d
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:108: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:109: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:110: trailing whitespace.
+FILE=Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:111: trailing whitespace.
+RAW=5ddc7d90b0f61505b9cab336fb1629ccb0f50a80
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:112: trailing whitespace.
+GIT_CLEAN=5ddc7d90b0f61505b9cab336fb1629ccb0f50a80
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:113: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:114: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:115: trailing whitespace.
+FILE=Evidence/CP-013/CP013_RED_Test_Output.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:116: trailing whitespace.
+RAW=0651f6c49f27cbc79a39cbb3bb283e2e4c1b38d0
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:117: trailing whitespace.
+GIT_CLEAN=0651f6c49f27cbc79a39cbb3bb283e2e4c1b38d0
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:118: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:119: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:120: trailing whitespace.
+FILE=Evidence/CP-013/CP013_RED_Test_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:121: trailing whitespace.
+RAW=7bf907adb2824596adb7586b973aefebc0b31c85
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:122: trailing whitespace.
+GIT_CLEAN=7bf907adb2824596adb7586b973aefebc0b31c85
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:123: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:124: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:125: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Rustfmt_Check_Output.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:126: trailing whitespace.
+RAW=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:127: trailing whitespace.
+GIT_CLEAN=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:128: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:129: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:130: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:131: trailing whitespace.
+RAW=fb6e89b73db5e992391a73321d8562ae21a8e176
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:132: trailing whitespace.
+GIT_CLEAN=fb6e89b73db5e992391a73321d8562ae21a8e176
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:133: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:134: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:135: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Source_Inspection.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:136: trailing whitespace.
+RAW=65dcb70d89d638f34ab76e0a30aec04a3b65d528
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:137: trailing whitespace.
+GIT_CLEAN=65dcb70d89d638f34ab76e0a30aec04a3b65d528
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:138: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:139: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:140: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:141: trailing whitespace.
+RAW=124fc8d216d41773fe373fa46226568a2aa8066a
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:142: trailing whitespace.
+GIT_CLEAN=124fc8d216d41773fe373fa46226568a2aa8066a
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:143: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:144: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:145: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:146: trailing whitespace.
+RAW=a11d3b59a1cdf118be9dc3b88662b6baa5f45eb3
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:147: trailing whitespace.
+GIT_CLEAN=a11d3b59a1cdf118be9dc3b88662b6baa5f45eb3
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:148: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:149: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:150: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Test_Authoring_Report.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:151: trailing whitespace.
+RAW=9b5ba5b6f8ff81ee40a0cc13d7b064139398f5d7
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:152: trailing whitespace.
+GIT_CLEAN=9b5ba5b6f8ff81ee40a0cc13d7b064139398f5d7
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:153: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:154: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:155: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Test_Formatting_Report.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:156: trailing whitespace.
+RAW=18037ce47355fb21b656d3d14735a957c3b8123e
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:157: trailing whitespace.
+GIT_CLEAN=18037ce47355fb21b656d3d14735a957c3b8123e
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:158: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:159: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:160: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Test_Rustfmt_Output.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:161: trailing whitespace.
+RAW=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:162: trailing whitespace.
+GIT_CLEAN=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:163: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:164: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:165: trailing whitespace.
+FILE=Evidence/CP-013/CP013_WASM_Build_Output.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:166: trailing whitespace.
+RAW=6f56aedba8899dc42cefc4d1e6f741cc09871c48
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:167: trailing whitespace.
+GIT_CLEAN=6f56aedba8899dc42cefc4d1e6f741cc09871c48
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:168: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:169: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:170: trailing whitespace.
+FILE=Evidence/CP-013/CP013_WASM_Build_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:171: trailing whitespace.
+RAW=87586e87ae33a0dabc8ed078ab939af9b1b8daf1
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:172: trailing whitespace.
+GIT_CLEAN=87586e87ae33a0dabc8ed078ab939af9b1b8daf1
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:173: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:174: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:175: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Whitespace_Exception_Review.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:176: trailing whitespace.
+RAW=718b425f6e80e1a1ea313e7e85ad32663f9acb37
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:177: trailing whitespace.
+GIT_CLEAN=718b425f6e80e1a1ea313e7e85ad32663f9acb37
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:178: trailing whitespace.
+BYTES_PRESERVED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:179: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:180: trailing whitespace.
+=== TRANSFORMED FILES ===
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:181: trailing whitespace.
+(none)
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:182: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:183: trailing whitespace.
+=== UNEXPECTED CHANGES ===
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:184: trailing whitespace.
+(none)
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:185: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt:186: trailing whitespace.
+RESULT: PASS - BYTE PRESERVATION RESTORED
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:1: trailing whitespace.
+WASM-002 CP013 GIT BYTE PRESERVATION PREFLIGHT
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 21:23:45 -03:00
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:4: trailing whitespace.
+FILES_CHECKED=29
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:5: trailing whitespace.
+RAW_BYTES_PRESERVED=8
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:6: trailing whitespace.
+GIT_TRANSFORMED_FILES=21
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:7: trailing whitespace.
+GIT_STAGING_PERFORMED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:8: trailing whitespace.
+SOURCE_MODIFIED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:9: trailing whitespace.
+HISTORICAL_EVIDENCE_MODIFIED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:10: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:11: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:12: trailing whitespace.
+=== FILE HASH COMPARISONS ===
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:13: trailing whitespace.
+FILE=src/lib.rs
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:14: trailing whitespace.
+RAW_BLOB=b2df81ba4946220e85543b44bd8ab33e3a341f9e
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:15: trailing whitespace.
+GIT_CLEAN_BLOB=b2df81ba4946220e85543b44bd8ab33e3a341f9e
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:16: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:17: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:18: trailing whitespace.
+FILE=tests/CP013_scr_rcp_candidate_identity.rs
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:19: trailing whitespace.
+RAW_BLOB=f512948ac406169c9c2e454a3814103b75bf3e24
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:20: trailing whitespace.
+GIT_CLEAN_BLOB=f512948ac406169c9c2e454a3814103b75bf3e24
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:21: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:22: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:23: trailing whitespace.
+FILE=Evidence/CP-013/.gitattributes
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:24: trailing whitespace.
+RAW_BLOB=e72aeef0d117129ce236f749a977c88c5d476fe5
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:25: trailing whitespace.
+GIT_CLEAN_BLOB=76c35bd65a4609cb3ee9c3480318aff04a1bc604
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:26: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:27: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:28: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Approved_Scope_Lock.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:29: trailing whitespace.
+RAW_BLOB=b8bc3bd6c76f89dd2b9666de8be27e63fbba3a43
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:30: trailing whitespace.
+GIT_CLEAN_BLOB=5d1e825a3b85ae4a8a64628ec127bd585e960e61
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:31: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:32: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:33: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Full_Regression_Test_Output.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:34: trailing whitespace.
+RAW_BLOB=f5a449cf20643c9ab32ffa70fd42ba598bc35a8a
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:35: trailing whitespace.
+GIT_CLEAN_BLOB=f5a449cf20643c9ab32ffa70fd42ba598bc35a8a
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:36: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:37: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:38: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Full_Regression_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:39: trailing whitespace.
+RAW_BLOB=4632d651638cd57e9da841bfef854dcebc645683
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:40: trailing whitespace.
+GIT_CLEAN_BLOB=0cfc0733f304393ccbe9abf0e4cae9a3bb1c33cb
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:41: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:42: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:43: trailing whitespace.
+FILE=Evidence/CP-013/CP013_GREEN_Implementation_Report.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:44: trailing whitespace.
+RAW_BLOB=4d79c7eb970b267a9328638008a9c2df3cbddb6d
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:45: trailing whitespace.
+GIT_CLEAN_BLOB=9710f35e747d15fc9ba2cce020d458c8b3d910f8
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:46: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:47: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:48: trailing whitespace.
+FILE=Evidence/CP-013/CP013_GREEN_Test_Output.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:49: trailing whitespace.
+RAW_BLOB=c319ce343f8a09041ecfaa85c5fa7d190dc6aa57
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:50: trailing whitespace.
+GIT_CLEAN_BLOB=c319ce343f8a09041ecfaa85c5fa7d190dc6aa57
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:51: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:52: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:53: trailing whitespace.
+FILE=Evidence/CP-013/CP013_GREEN_Test_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:54: trailing whitespace.
+RAW_BLOB=32e085d02532cfa358e7d6940bcc0d12ea25354f
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:55: trailing whitespace.
+GIT_CLEAN_BLOB=4db942b6bb16de2a785727420a29f8982c60a5ea
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:56: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:57: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:58: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Hash_Inventory.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:59: trailing whitespace.
+RAW_BLOB=a1f5df08f90d5d4ea5be238d52251dd855ae9b0b
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:60: trailing whitespace.
+GIT_CLEAN_BLOB=cfe0f66fbc25345f460b3113ddeebc70aed27405
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:61: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:62: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:63: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Hash_Inventory_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:64: trailing whitespace.
+RAW_BLOB=4eb11024534c02c46bbd0b8331bfd81ee6d98017
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:65: trailing whitespace.
+GIT_CLEAN_BLOB=498d6870e7f75c178d209ebf9735c82bdbbcb60f
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:66: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:67: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:68: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Opening_Git_Preflight.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:69: trailing whitespace.
+RAW_BLOB=51aeaf3e50206991f3ccf49053968ed7e1338c1a
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:70: trailing whitespace.
+GIT_CLEAN_BLOB=558f3b477b2920cc526e4159fda2b6bcbbcfcb65
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:71: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:72: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:73: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Precedent_Test_Inspection.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:74: trailing whitespace.
+RAW_BLOB=154133126e4498a2f50515dd638cd32e9af73b27
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:75: trailing whitespace.
+GIT_CLEAN_BLOB=9ac760fa1a501705efb858b8f8d82d1a6e2b771a
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:76: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:77: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:78: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Precommit_Git_Review.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:79: trailing whitespace.
+RAW_BLOB=5bf9c20483d8228e10a7605d1f48f10c5b61e799
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:80: trailing whitespace.
+GIT_CLEAN_BLOB=f758a02712e7fdf87c53b250170fda6f1efac87e
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:81: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:82: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:83: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:84: trailing whitespace.
+RAW_BLOB=99c0646006eb5158d61fc0a48d94bb0fc13bc25d
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:85: trailing whitespace.
+GIT_CLEAN_BLOB=04acb7ef8108cfbb98a346e852cd5af82782509a
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:86: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:87: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:88: trailing whitespace.
+FILE=Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:89: trailing whitespace.
+RAW_BLOB=5ddc7d90b0f61505b9cab336fb1629ccb0f50a80
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:90: trailing whitespace.
+GIT_CLEAN_BLOB=a7d1aa0cf30615dec242805b90f2043c43c4a12c
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:91: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:92: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:93: trailing whitespace.
+FILE=Evidence/CP-013/CP013_RED_Test_Output.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:94: trailing whitespace.
+RAW_BLOB=0651f6c49f27cbc79a39cbb3bb283e2e4c1b38d0
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:95: trailing whitespace.
+GIT_CLEAN_BLOB=0651f6c49f27cbc79a39cbb3bb283e2e4c1b38d0
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:96: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:97: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:98: trailing whitespace.
+FILE=Evidence/CP-013/CP013_RED_Test_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:99: trailing whitespace.
+RAW_BLOB=7bf907adb2824596adb7586b973aefebc0b31c85
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:100: trailing whitespace.
+GIT_CLEAN_BLOB=d4c2cd3cf2c773ebce3a8e35150822bcdfd825b3
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:101: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:102: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:103: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Rustfmt_Check_Output.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:104: trailing whitespace.
+RAW_BLOB=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:105: trailing whitespace.
+GIT_CLEAN_BLOB=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:106: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:107: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:108: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:109: trailing whitespace.
+RAW_BLOB=fb6e89b73db5e992391a73321d8562ae21a8e176
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:110: trailing whitespace.
+GIT_CLEAN_BLOB=6ff17699077f8e8c79bf1c0f1c48202e47c12580
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:111: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:112: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:113: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Source_Inspection.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:114: trailing whitespace.
+RAW_BLOB=65dcb70d89d638f34ab76e0a30aec04a3b65d528
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:115: trailing whitespace.
+GIT_CLEAN_BLOB=073a1a73b510f017c141bb74387b1740dd637efc
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:116: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:117: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:118: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:119: trailing whitespace.
+RAW_BLOB=124fc8d216d41773fe373fa46226568a2aa8066a
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:120: trailing whitespace.
+GIT_CLEAN_BLOB=84f6563602a8297f1fd0ca44962063940a486d50
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:121: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:122: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:123: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:124: trailing whitespace.
+RAW_BLOB=a11d3b59a1cdf118be9dc3b88662b6baa5f45eb3
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:125: trailing whitespace.
+GIT_CLEAN_BLOB=cfc7c6008b5d748498bba33f810ca411345bed49
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:126: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:127: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:128: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Test_Authoring_Report.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:129: trailing whitespace.
+RAW_BLOB=9b5ba5b6f8ff81ee40a0cc13d7b064139398f5d7
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:130: trailing whitespace.
+GIT_CLEAN_BLOB=902882b8f9cee4fcf88b69e0c2cfd50684391680
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:131: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:132: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:133: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Test_Formatting_Report.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:134: trailing whitespace.
+RAW_BLOB=18037ce47355fb21b656d3d14735a957c3b8123e
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:135: trailing whitespace.
+GIT_CLEAN_BLOB=f975e240ff9d4901417c5afa904d0d2e03504939
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:136: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:137: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:138: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Test_Rustfmt_Output.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:139: trailing whitespace.
+RAW_BLOB=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:140: trailing whitespace.
+GIT_CLEAN_BLOB=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:141: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:142: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:143: trailing whitespace.
+FILE=Evidence/CP-013/CP013_WASM_Build_Output.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:144: trailing whitespace.
+RAW_BLOB=6f56aedba8899dc42cefc4d1e6f741cc09871c48
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:145: trailing whitespace.
+GIT_CLEAN_BLOB=6f56aedba8899dc42cefc4d1e6f741cc09871c48
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:146: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=True
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:147: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:148: trailing whitespace.
+FILE=Evidence/CP-013/CP013_WASM_Build_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:149: trailing whitespace.
+RAW_BLOB=87586e87ae33a0dabc8ed078ab939af9b1b8daf1
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:150: trailing whitespace.
+GIT_CLEAN_BLOB=7753c919782568faab8035399118a09d3851a3e3
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:151: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:152: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:153: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Whitespace_Exception_Review.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:154: trailing whitespace.
+RAW_BLOB=718b425f6e80e1a1ea313e7e85ad32663f9acb37
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:155: trailing whitespace.
+GIT_CLEAN_BLOB=5695a284bf3cd183e4d8022227bfe6e1e29ebced
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:156: trailing whitespace.
+BYTES_PRESERVED_IF_STAGED=False
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:157: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:158: trailing whitespace.
+=== POSSIBLE GIT TRANSFORMATIONS ===
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:159: trailing whitespace.
+Evidence/CP-013/.gitattributes
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:160: trailing whitespace.
+Evidence/CP-013/CP013_Approved_Scope_Lock.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:161: trailing whitespace.
+Evidence/CP-013/CP013_Full_Regression_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:162: trailing whitespace.
+Evidence/CP-013/CP013_GREEN_Implementation_Report.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:163: trailing whitespace.
+Evidence/CP-013/CP013_GREEN_Test_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:164: trailing whitespace.
+Evidence/CP-013/CP013_Hash_Inventory.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:165: trailing whitespace.
+Evidence/CP-013/CP013_Hash_Inventory_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:166: trailing whitespace.
+Evidence/CP-013/CP013_Opening_Git_Preflight.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:167: trailing whitespace.
+Evidence/CP-013/CP013_Precedent_Test_Inspection.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:168: trailing whitespace.
+Evidence/CP-013/CP013_Precommit_Git_Review.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:169: trailing whitespace.
+Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:170: trailing whitespace.
+Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:171: trailing whitespace.
+Evidence/CP-013/CP013_RED_Test_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:172: trailing whitespace.
+Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:173: trailing whitespace.
+Evidence/CP-013/CP013_Source_Inspection.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:174: trailing whitespace.
+Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:175: trailing whitespace.
+Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:176: trailing whitespace.
+Evidence/CP-013/CP013_Test_Authoring_Report.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:177: trailing whitespace.
+Evidence/CP-013/CP013_Test_Formatting_Report.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:178: trailing whitespace.
+Evidence/CP-013/CP013_WASM_Build_Verification.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:179: trailing whitespace.
+Evidence/CP-013/CP013_Whitespace_Exception_Review.txt
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:180: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt:181: trailing whitespace.
+RESULT: REVIEW REQUIRED - GIT TRANSFORMATIONS
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:1: trailing whitespace.
+WASM-002 CP013 GIT NORMALIZATION DIAGNOSTIC
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 21:25:55 -03:00
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:4: trailing whitespace.
+FILES_CHECKED=29
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:5: trailing whitespace.
+DEFAULT_PRESERVED=8
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:6: trailing whitespace.
+DEFAULT_TRANSFORMED=21
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:7: trailing whitespace.
+AUTOCRLF_FALSE_PRESERVED=8
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:8: trailing whitespace.
+AUTOCRLF_FALSE_TRANSFORMED=21
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:9: trailing whitespace.
+CONFIGURATION_CHANGED=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:10: trailing whitespace.
+GIT_STAGING_PERFORMED=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:11: trailing whitespace.
+SOURCE_MODIFIED=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:12: trailing whitespace.
+HISTORICAL_EVIDENCE_MODIFIED=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:13: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:14: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:15: trailing whitespace.
+=== CURRENT GIT CONFIGURATION ===
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:16: trailing whitespace.
+core.autocrlf=file:C:/Program Files/Git/etc/gitconfig	true
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:17: trailing whitespace.
+core.eol=(unset)
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:18: trailing whitespace.
+core.safecrlf=(unset)
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:19: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:20: trailing whitespace.
+=== REPRESENTATIVE ATTRIBUTES AND LINE ENDINGS ===
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:21: trailing whitespace.
+FILE=Evidence/CP-013/.gitattributes
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:22: trailing whitespace.
+Evidence/CP-013/.gitattributes: text: auto
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:23: trailing whitespace.
+Evidence/CP-013/.gitattributes: eol: unspecified
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:24: trailing whitespace.
+Evidence/CP-013/.gitattributes: filter: unspecified
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:25: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:26: trailing whitespace.
+CRLF_PAIRS=6
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:27: trailing whitespace.
+LONE_LF=0
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:28: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:29: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Approved_Scope_Lock.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:30: trailing whitespace.
+Evidence/CP-013/CP013_Approved_Scope_Lock.txt: text: auto
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:31: trailing whitespace.
+Evidence/CP-013/CP013_Approved_Scope_Lock.txt: eol: unspecified
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:32: trailing whitespace.
+Evidence/CP-013/CP013_Approved_Scope_Lock.txt: filter: unspecified
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:33: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:34: trailing whitespace.
+CRLF_PAIRS=68
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:35: trailing whitespace.
+LONE_LF=0
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:36: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:37: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Source_Inspection.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:38: trailing whitespace.
+Evidence/CP-013/CP013_Source_Inspection.txt: text: auto
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:39: trailing whitespace.
+Evidence/CP-013/CP013_Source_Inspection.txt: eol: unspecified
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:40: trailing whitespace.
+Evidence/CP-013/CP013_Source_Inspection.txt: filter: unspecified
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:41: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:42: trailing whitespace.
+CRLF_PAIRS=416
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:43: trailing whitespace.
+LONE_LF=0
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:44: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:45: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Full_Regression_Test_Output.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:46: trailing whitespace.
+Evidence/CP-013/CP013_Full_Regression_Test_Output.txt: text: auto
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:47: trailing whitespace.
+Evidence/CP-013/CP013_Full_Regression_Test_Output.txt: eol: unspecified
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:48: trailing whitespace.
+Evidence/CP-013/CP013_Full_Regression_Test_Output.txt: filter: unspecified
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:49: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:50: trailing whitespace.
+CRLF_PAIRS=0
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:51: trailing whitespace.
+LONE_LF=144
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:52: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:53: trailing whitespace.
+=== ALL FILE COMPARISONS ===
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:54: trailing whitespace.
+FILE=src/lib.rs
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:55: trailing whitespace.
+RAW=b2df81ba4946220e85543b44bd8ab33e3a341f9e
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:56: trailing whitespace.
+DEFAULT=b2df81ba4946220e85543b44bd8ab33e3a341f9e
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:57: trailing whitespace.
+AUTOCRLF_FALSE=b2df81ba4946220e85543b44bd8ab33e3a341f9e
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:58: trailing whitespace.
+DEFAULT_PRESERVES=True
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:59: trailing whitespace.
+OVERRIDE_PRESERVES=True
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:60: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:61: trailing whitespace.
+FILE=tests/CP013_scr_rcp_candidate_identity.rs
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:62: trailing whitespace.
+RAW=f512948ac406169c9c2e454a3814103b75bf3e24
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:63: trailing whitespace.
+DEFAULT=f512948ac406169c9c2e454a3814103b75bf3e24
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:64: trailing whitespace.
+AUTOCRLF_FALSE=f512948ac406169c9c2e454a3814103b75bf3e24
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:65: trailing whitespace.
+DEFAULT_PRESERVES=True
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:66: trailing whitespace.
+OVERRIDE_PRESERVES=True
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:67: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:68: trailing whitespace.
+FILE=Evidence/CP-013/.gitattributes
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:69: trailing whitespace.
+RAW=e72aeef0d117129ce236f749a977c88c5d476fe5
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:70: trailing whitespace.
+DEFAULT=76c35bd65a4609cb3ee9c3480318aff04a1bc604
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:71: trailing whitespace.
+AUTOCRLF_FALSE=76c35bd65a4609cb3ee9c3480318aff04a1bc604
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:72: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:73: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:74: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:75: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Approved_Scope_Lock.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:76: trailing whitespace.
+RAW=b8bc3bd6c76f89dd2b9666de8be27e63fbba3a43
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:77: trailing whitespace.
+DEFAULT=5d1e825a3b85ae4a8a64628ec127bd585e960e61
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:78: trailing whitespace.
+AUTOCRLF_FALSE=5d1e825a3b85ae4a8a64628ec127bd585e960e61
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:79: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:80: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:81: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:82: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Full_Regression_Test_Output.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:83: trailing whitespace.
+RAW=f5a449cf20643c9ab32ffa70fd42ba598bc35a8a
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:84: trailing whitespace.
+DEFAULT=f5a449cf20643c9ab32ffa70fd42ba598bc35a8a
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:85: trailing whitespace.
+AUTOCRLF_FALSE=f5a449cf20643c9ab32ffa70fd42ba598bc35a8a
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:86: trailing whitespace.
+DEFAULT_PRESERVES=True
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:87: trailing whitespace.
+OVERRIDE_PRESERVES=True
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:88: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:89: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Full_Regression_Verification.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:90: trailing whitespace.
+RAW=4632d651638cd57e9da841bfef854dcebc645683
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:91: trailing whitespace.
+DEFAULT=0cfc0733f304393ccbe9abf0e4cae9a3bb1c33cb
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:92: trailing whitespace.
+AUTOCRLF_FALSE=0cfc0733f304393ccbe9abf0e4cae9a3bb1c33cb
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:93: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:94: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:95: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:96: trailing whitespace.
+FILE=Evidence/CP-013/CP013_GREEN_Implementation_Report.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:97: trailing whitespace.
+RAW=4d79c7eb970b267a9328638008a9c2df3cbddb6d
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:98: trailing whitespace.
+DEFAULT=9710f35e747d15fc9ba2cce020d458c8b3d910f8
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:99: trailing whitespace.
+AUTOCRLF_FALSE=9710f35e747d15fc9ba2cce020d458c8b3d910f8
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:100: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:101: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:102: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:103: trailing whitespace.
+FILE=Evidence/CP-013/CP013_GREEN_Test_Output.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:104: trailing whitespace.
+RAW=c319ce343f8a09041ecfaa85c5fa7d190dc6aa57
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:105: trailing whitespace.
+DEFAULT=c319ce343f8a09041ecfaa85c5fa7d190dc6aa57
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:106: trailing whitespace.
+AUTOCRLF_FALSE=c319ce343f8a09041ecfaa85c5fa7d190dc6aa57
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:107: trailing whitespace.
+DEFAULT_PRESERVES=True
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:108: trailing whitespace.
+OVERRIDE_PRESERVES=True
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:109: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:110: trailing whitespace.
+FILE=Evidence/CP-013/CP013_GREEN_Test_Verification.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:111: trailing whitespace.
+RAW=32e085d02532cfa358e7d6940bcc0d12ea25354f
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:112: trailing whitespace.
+DEFAULT=4db942b6bb16de2a785727420a29f8982c60a5ea
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:113: trailing whitespace.
+AUTOCRLF_FALSE=4db942b6bb16de2a785727420a29f8982c60a5ea
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:114: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:115: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:116: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:117: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Hash_Inventory.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:118: trailing whitespace.
+RAW=a1f5df08f90d5d4ea5be238d52251dd855ae9b0b
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:119: trailing whitespace.
+DEFAULT=cfe0f66fbc25345f460b3113ddeebc70aed27405
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:120: trailing whitespace.
+AUTOCRLF_FALSE=cfe0f66fbc25345f460b3113ddeebc70aed27405
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:121: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:122: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:123: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:124: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Hash_Inventory_Verification.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:125: trailing whitespace.
+RAW=4eb11024534c02c46bbd0b8331bfd81ee6d98017
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:126: trailing whitespace.
+DEFAULT=498d6870e7f75c178d209ebf9735c82bdbbcb60f
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:127: trailing whitespace.
+AUTOCRLF_FALSE=498d6870e7f75c178d209ebf9735c82bdbbcb60f
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:128: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:129: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:130: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:131: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Opening_Git_Preflight.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:132: trailing whitespace.
+RAW=51aeaf3e50206991f3ccf49053968ed7e1338c1a
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:133: trailing whitespace.
+DEFAULT=558f3b477b2920cc526e4159fda2b6bcbbcfcb65
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:134: trailing whitespace.
+AUTOCRLF_FALSE=558f3b477b2920cc526e4159fda2b6bcbbcfcb65
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:135: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:136: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:137: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:138: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Precedent_Test_Inspection.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:139: trailing whitespace.
+RAW=154133126e4498a2f50515dd638cd32e9af73b27
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:140: trailing whitespace.
+DEFAULT=9ac760fa1a501705efb858b8f8d82d1a6e2b771a
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:141: trailing whitespace.
+AUTOCRLF_FALSE=9ac760fa1a501705efb858b8f8d82d1a6e2b771a
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:142: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:143: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:144: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:145: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Precommit_Git_Review.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:146: trailing whitespace.
+RAW=5bf9c20483d8228e10a7605d1f48f10c5b61e799
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:147: trailing whitespace.
+DEFAULT=f758a02712e7fdf87c53b250170fda6f1efac87e
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:148: trailing whitespace.
+AUTOCRLF_FALSE=f758a02712e7fdf87c53b250170fda6f1efac87e
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:149: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:150: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:151: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:152: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:153: trailing whitespace.
+RAW=99c0646006eb5158d61fc0a48d94bb0fc13bc25d
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:154: trailing whitespace.
+DEFAULT=04acb7ef8108cfbb98a346e852cd5af82782509a
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:155: trailing whitespace.
+AUTOCRLF_FALSE=04acb7ef8108cfbb98a346e852cd5af82782509a
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:156: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:157: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:158: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:159: trailing whitespace.
+FILE=Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:160: trailing whitespace.
+RAW=5ddc7d90b0f61505b9cab336fb1629ccb0f50a80
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:161: trailing whitespace.
+DEFAULT=a7d1aa0cf30615dec242805b90f2043c43c4a12c
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:162: trailing whitespace.
+AUTOCRLF_FALSE=a7d1aa0cf30615dec242805b90f2043c43c4a12c
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:163: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:164: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:165: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:166: trailing whitespace.
+FILE=Evidence/CP-013/CP013_RED_Test_Output.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:167: trailing whitespace.
+RAW=0651f6c49f27cbc79a39cbb3bb283e2e4c1b38d0
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:168: trailing whitespace.
+DEFAULT=0651f6c49f27cbc79a39cbb3bb283e2e4c1b38d0
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:169: trailing whitespace.
+AUTOCRLF_FALSE=0651f6c49f27cbc79a39cbb3bb283e2e4c1b38d0
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:170: trailing whitespace.
+DEFAULT_PRESERVES=True
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:171: trailing whitespace.
+OVERRIDE_PRESERVES=True
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:172: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:173: trailing whitespace.
+FILE=Evidence/CP-013/CP013_RED_Test_Verification.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:174: trailing whitespace.
+RAW=7bf907adb2824596adb7586b973aefebc0b31c85
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:175: trailing whitespace.
+DEFAULT=d4c2cd3cf2c773ebce3a8e35150822bcdfd825b3
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:176: trailing whitespace.
+AUTOCRLF_FALSE=d4c2cd3cf2c773ebce3a8e35150822bcdfd825b3
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:177: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:178: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:179: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:180: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Rustfmt_Check_Output.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:181: trailing whitespace.
+RAW=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:182: trailing whitespace.
+DEFAULT=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:183: trailing whitespace.
+AUTOCRLF_FALSE=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:184: trailing whitespace.
+DEFAULT_PRESERVES=True
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:185: trailing whitespace.
+OVERRIDE_PRESERVES=True
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:186: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:187: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:188: trailing whitespace.
+RAW=fb6e89b73db5e992391a73321d8562ae21a8e176
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:189: trailing whitespace.
+DEFAULT=6ff17699077f8e8c79bf1c0f1c48202e47c12580
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:190: trailing whitespace.
+AUTOCRLF_FALSE=6ff17699077f8e8c79bf1c0f1c48202e47c12580
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:191: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:192: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:193: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:194: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Source_Inspection.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:195: trailing whitespace.
+RAW=65dcb70d89d638f34ab76e0a30aec04a3b65d528
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:196: trailing whitespace.
+DEFAULT=073a1a73b510f017c141bb74387b1740dd637efc
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:197: trailing whitespace.
+AUTOCRLF_FALSE=073a1a73b510f017c141bb74387b1740dd637efc
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:198: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:199: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:200: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:201: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:202: trailing whitespace.
+RAW=124fc8d216d41773fe373fa46226568a2aa8066a
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:203: trailing whitespace.
+DEFAULT=84f6563602a8297f1fd0ca44962063940a486d50
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:204: trailing whitespace.
+AUTOCRLF_FALSE=84f6563602a8297f1fd0ca44962063940a486d50
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:205: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:206: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:207: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:208: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:209: trailing whitespace.
+RAW=a11d3b59a1cdf118be9dc3b88662b6baa5f45eb3
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:210: trailing whitespace.
+DEFAULT=cfc7c6008b5d748498bba33f810ca411345bed49
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:211: trailing whitespace.
+AUTOCRLF_FALSE=cfc7c6008b5d748498bba33f810ca411345bed49
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:212: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:213: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:214: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:215: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Test_Authoring_Report.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:216: trailing whitespace.
+RAW=9b5ba5b6f8ff81ee40a0cc13d7b064139398f5d7
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:217: trailing whitespace.
+DEFAULT=902882b8f9cee4fcf88b69e0c2cfd50684391680
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:218: trailing whitespace.
+AUTOCRLF_FALSE=902882b8f9cee4fcf88b69e0c2cfd50684391680
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:219: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:220: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:221: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:222: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Test_Formatting_Report.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:223: trailing whitespace.
+RAW=18037ce47355fb21b656d3d14735a957c3b8123e
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:224: trailing whitespace.
+DEFAULT=f975e240ff9d4901417c5afa904d0d2e03504939
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:225: trailing whitespace.
+AUTOCRLF_FALSE=f975e240ff9d4901417c5afa904d0d2e03504939
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:226: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:227: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:228: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:229: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Test_Rustfmt_Output.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:230: trailing whitespace.
+RAW=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:231: trailing whitespace.
+DEFAULT=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:232: trailing whitespace.
+AUTOCRLF_FALSE=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:233: trailing whitespace.
+DEFAULT_PRESERVES=True
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:234: trailing whitespace.
+OVERRIDE_PRESERVES=True
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:235: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:236: trailing whitespace.
+FILE=Evidence/CP-013/CP013_WASM_Build_Output.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:237: trailing whitespace.
+RAW=6f56aedba8899dc42cefc4d1e6f741cc09871c48
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:238: trailing whitespace.
+DEFAULT=6f56aedba8899dc42cefc4d1e6f741cc09871c48
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:239: trailing whitespace.
+AUTOCRLF_FALSE=6f56aedba8899dc42cefc4d1e6f741cc09871c48
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:240: trailing whitespace.
+DEFAULT_PRESERVES=True
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:241: trailing whitespace.
+OVERRIDE_PRESERVES=True
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:242: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:243: trailing whitespace.
+FILE=Evidence/CP-013/CP013_WASM_Build_Verification.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:244: trailing whitespace.
+RAW=87586e87ae33a0dabc8ed078ab939af9b1b8daf1
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:245: trailing whitespace.
+DEFAULT=7753c919782568faab8035399118a09d3851a3e3
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:246: trailing whitespace.
+AUTOCRLF_FALSE=7753c919782568faab8035399118a09d3851a3e3
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:247: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:248: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:249: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:250: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Whitespace_Exception_Review.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:251: trailing whitespace.
+RAW=718b425f6e80e1a1ea313e7e85ad32663f9acb37
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:252: trailing whitespace.
+DEFAULT=5695a284bf3cd183e4d8022227bfe6e1e29ebced
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:253: trailing whitespace.
+AUTOCRLF_FALSE=5695a284bf3cd183e4d8022227bfe6e1e29ebced
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:254: trailing whitespace.
+DEFAULT_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:255: trailing whitespace.
+OVERRIDE_PRESERVES=False
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:256: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:257: trailing whitespace.
+=== REMAINING TRANSFORMATIONS WITH OVERRIDE ===
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:258: trailing whitespace.
+Evidence/CP-013/.gitattributes
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:259: trailing whitespace.
+Evidence/CP-013/CP013_Approved_Scope_Lock.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:260: trailing whitespace.
+Evidence/CP-013/CP013_Full_Regression_Verification.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:261: trailing whitespace.
+Evidence/CP-013/CP013_GREEN_Implementation_Report.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:262: trailing whitespace.
+Evidence/CP-013/CP013_GREEN_Test_Verification.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:263: trailing whitespace.
+Evidence/CP-013/CP013_Hash_Inventory.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:264: trailing whitespace.
+Evidence/CP-013/CP013_Hash_Inventory_Verification.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:265: trailing whitespace.
+Evidence/CP-013/CP013_Opening_Git_Preflight.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:266: trailing whitespace.
+Evidence/CP-013/CP013_Precedent_Test_Inspection.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:267: trailing whitespace.
+Evidence/CP-013/CP013_Precommit_Git_Review.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:268: trailing whitespace.
+Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:269: trailing whitespace.
+Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:270: trailing whitespace.
+Evidence/CP-013/CP013_RED_Test_Verification.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:271: trailing whitespace.
+Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:272: trailing whitespace.
+Evidence/CP-013/CP013_Source_Inspection.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:273: trailing whitespace.
+Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:274: trailing whitespace.
+Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:275: trailing whitespace.
+Evidence/CP-013/CP013_Test_Authoring_Report.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:276: trailing whitespace.
+Evidence/CP-013/CP013_Test_Formatting_Report.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:277: trailing whitespace.
+Evidence/CP-013/CP013_WASM_Build_Verification.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:278: trailing whitespace.
+Evidence/CP-013/CP013_Whitespace_Exception_Review.txt
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:279: trailing whitespace.
+
Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt:280: trailing whitespace.
+RESULT: DIAGNOSTIC COMPLETED - NO STAGING
Evidence/CP-013/CP013_Hash_Inventory.txt:1: trailing whitespace.
+WASM-002 CP013 SHA256 EVIDENCE INVENTORY
Evidence/CP-013/CP013_Hash_Inventory.txt:2: trailing whitespace.
+Created UTC: 2026-10-14T00:09:27Z
Evidence/CP-013/CP013_Hash_Inventory.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Hash_Inventory.txt:4: trailing whitespace.
+Scope: APPROVED AND LOCKED
Evidence/CP-013/CP013_Hash_Inventory.txt:5: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_Hash_Inventory.txt:6: trailing whitespace.
+ENTRY_COUNT=21
Evidence/CP-013/CP013_Hash_Inventory.txt:7: trailing whitespace.
+HASH_ALGORITHM=SHA256
Evidence/CP-013/CP013_Hash_Inventory.txt:8: trailing whitespace.
+PATH_BASE=REPOSITORY_ROOT
Evidence/CP-013/CP013_Hash_Inventory.txt:9: trailing whitespace.
+INVENTORY_SELF_INCLUDED=False
Evidence/CP-013/CP013_Hash_Inventory.txt:10: trailing whitespace.
+
Evidence/CP-013/CP013_Hash_Inventory.txt:11: trailing whitespace.
+SHA256	BYTES	RELATIVE_PATH
Evidence/CP-013/CP013_Hash_Inventory.txt:12: trailing whitespace.
+0D53E3CB1707C3D560FC54F5819777C0165B600756ECEE23EEE85A55EEFC842D	2236	Evidence/CP-013/CP013_Approved_Scope_Lock.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:13: trailing whitespace.
+CDF724B92EBC09B1D49E53A76249B3A909B2E2DD3F5014DDE5710FCBADBC0BD7	6617	Evidence/CP-013/CP013_Full_Regression_Test_Output.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:14: trailing whitespace.
+69677A9F4B337FA97EBCA45DA3CCF521BFCF6F6D47B457674D9021A1A72063C8	674	Evidence/CP-013/CP013_Full_Regression_Verification.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:15: trailing whitespace.
+3F7D5E689A3D4C388FC8550A50D212EDAD02D8E9CF38FDB8751D66CD7797A77F	752	Evidence/CP-013/CP013_GREEN_Implementation_Report.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:16: trailing whitespace.
+09DEE35F2106EEE09F0E9DA838616569E221FF649B6FDE9CA286332104E75C1E	767	Evidence/CP-013/CP013_GREEN_Test_Output.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:17: trailing whitespace.
+6D2A3D18675FBF2BAB92A1D7CE28C3022BEB06739DC224C6829CE76ECFD4A239	692	Evidence/CP-013/CP013_GREEN_Test_Verification.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:18: trailing whitespace.
+FAE4C245BEB38BCF8BF6E0865E8BE68933A3F65202049043E192A22F855A5B93	340	Evidence/CP-013/CP013_Opening_Git_Preflight.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:19: trailing whitespace.
+6CE547C1011A0269E4A46BAF500B481C7D0F5D23E3F5DB7E1DC19167CD10007E	8512	Evidence/CP-013/CP013_Precedent_Test_Inspection.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:20: trailing whitespace.
+268BB398D3107CDE27811C69846933DBDD13A1C147B88F141993A9C06ADFD855	568	Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:21: trailing whitespace.
+BF2BA7CE6093966F7CD1F064B048340A584C97C89226516C619467B019D32D26	607	Evidence/CP-013/CP013_RED_Test_Output.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:22: trailing whitespace.
+6BB29DF940EE4BC47E0CE1284826F775E39E894E9E7D750C7B9E331318A77989	551	Evidence/CP-013/CP013_RED_Test_Verification.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:23: trailing whitespace.
+E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855	0	Evidence/CP-013/CP013_Rustfmt_Check_Output.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:24: trailing whitespace.
+203785BA39E9A17086C6707135AE5F9CBF7790E21C8FA9374F7E272EE30E43B3	526	Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:25: trailing whitespace.
+B3F8BA7253344430E36E48B82AF5B60E2DAF4FC0F5C298A9926E428792A5873D	15768	Evidence/CP-013/CP013_Source_Inspection.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:26: trailing whitespace.
+0CBEBAA36A051FD051A867DEDF0C85A2F49C8DF38867A86A816F37858BFC85E9	446	Evidence/CP-013/CP013_Test_Authoring_Report.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:27: trailing whitespace.
+70AE62C845CE0472A923AD9EC4D95CD4F9CCB1691C86D9EA298F8E78C347791E	524	Evidence/CP-013/CP013_Test_Formatting_Report.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:28: trailing whitespace.
+E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855	0	Evidence/CP-013/CP013_Test_Rustfmt_Output.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:29: trailing whitespace.
+22253096F4A2856C201EE463B0741DB221E914B13D5997B89BEAE50C785EFABE	159	Evidence/CP-013/CP013_WASM_Build_Output.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:30: trailing whitespace.
+964E184B11CF2EBCC22E752DB28C7B0BD074DC797A2AEED1BA6753E6A6042BEC	713	Evidence/CP-013/CP013_WASM_Build_Verification.txt
Evidence/CP-013/CP013_Hash_Inventory.txt:31: trailing whitespace.
+99741F26933AA8EEDBF1E75031F5012CA01918D06E1A3D013CA1703A49842649	12312	src/lib.rs
Evidence/CP-013/CP013_Hash_Inventory.txt:32: trailing whitespace.
+758FE6ECED824B1D05277C414D1BD223F062B3A1AA15AA1D1E3D90BD069452D3	2727	tests/CP013_scr_rcp_candidate_identity.rs
Evidence/CP-013/CP013_Hash_Inventory.txt:33: trailing whitespace.
+
Evidence/CP-013/CP013_Hash_Inventory.txt:34: trailing whitespace.
+RESULT: INVENTORY CREATED
Evidence/CP-013/CP013_Hash_Inventory.txt:35: trailing whitespace.
+VERIFICATION_PENDING=True
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:1: trailing whitespace.
+WASM-002 CP013 SHA256 INVENTORY VERIFICATION
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 21:11:23 -03:00
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:4: trailing whitespace.
+INVENTORY_SHA256=3D88250E36BADBED442FFBDD819A013F0CD903465ED7D4956D06282E9E99D73D
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:5: trailing whitespace.
+EXPECTED_RECORDS=21
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:6: trailing whitespace.
+VERIFIED_RECORDS=21
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:7: trailing whitespace.
+EVIDENCE_RECORDS=19
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:8: trailing whitespace.
+EVIDENCE_SET_MATCH=True
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:9: trailing whitespace.
+FAILURE_COUNT=0
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:10: trailing whitespace.
+HASH_ALGORITHM=SHA256
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:11: trailing whitespace.
+SOURCE_MODIFIED_BY_VERIFICATION=False
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:12: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:13: trailing whitespace.
+
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:14: trailing whitespace.
+=== INDIVIDUAL FILE VERIFICATION ===
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:15: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Approved_Scope_Lock.txt	2236
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:16: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Full_Regression_Test_Output.txt	6617
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:17: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Full_Regression_Verification.txt	674
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:18: trailing whitespace.
+PASS	Evidence/CP-013/CP013_GREEN_Implementation_Report.txt	752
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:19: trailing whitespace.
+PASS	Evidence/CP-013/CP013_GREEN_Test_Output.txt	767
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:20: trailing whitespace.
+PASS	Evidence/CP-013/CP013_GREEN_Test_Verification.txt	692
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:21: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Opening_Git_Preflight.txt	340
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:22: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Precedent_Test_Inspection.txt	8512
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:23: trailing whitespace.
+PASS	Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt	568
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:24: trailing whitespace.
+PASS	Evidence/CP-013/CP013_RED_Test_Output.txt	607
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:25: trailing whitespace.
+PASS	Evidence/CP-013/CP013_RED_Test_Verification.txt	551
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:26: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Rustfmt_Check_Output.txt	0
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:27: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt	526
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:28: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Source_Inspection.txt	15768
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:29: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Test_Authoring_Report.txt	446
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:30: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Test_Formatting_Report.txt	524
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:31: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Test_Rustfmt_Output.txt	0
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:32: trailing whitespace.
+PASS	Evidence/CP-013/CP013_WASM_Build_Output.txt	159
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:33: trailing whitespace.
+PASS	Evidence/CP-013/CP013_WASM_Build_Verification.txt	713
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:34: trailing whitespace.
+PASS	src/lib.rs	12312
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:35: trailing whitespace.
+PASS	tests/CP013_scr_rcp_candidate_identity.rs	2727
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:36: trailing whitespace.
+
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:37: trailing whitespace.
+=== FAILURES ===
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:38: trailing whitespace.
+(none)
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:39: trailing whitespace.
+
Evidence/CP-013/CP013_Hash_Inventory_Verification.txt:40: trailing whitespace.
+RESULT: PASS - ALL 21 HASHES VERIFIED
Evidence/CP-013/CP013_Opening_Git_Preflight.txt:1: trailing whitespace.
+WASM-002 CP013 OPENING GIT PREFLIGHT
Evidence/CP-013/CP013_Opening_Git_Preflight.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 20:36:00 -03:00
Evidence/CP-013/CP013_Opening_Git_Preflight.txt:3: trailing whitespace.
+Repository: C:/Users/Admin/Downloads/DataSculptor-WASM002
Evidence/CP-013/CP013_Opening_Git_Preflight.txt:4: trailing whitespace.
+Expected HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Opening_Git_Preflight.txt:5: trailing whitespace.
+Actual HEAD:   efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Opening_Git_Preflight.txt:6: trailing whitespace.
+HEAD MATCH: True
Evidence/CP-013/CP013_Opening_Git_Preflight.txt:7: trailing whitespace.
+WORKING TREE CLEAN: True
Evidence/CP-013/CP013_Opening_Git_Preflight.txt:8: trailing whitespace.
+Git porcelain status:
Evidence/CP-013/CP013_Opening_Git_Preflight.txt:9: trailing whitespace.
+(empty)
Evidence/CP-013/CP013_Opening_Git_Preflight.txt:10: trailing whitespace.
+RESULT: PASS
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:1: trailing whitespace.
+WASM-002 CP013 POST-NORMALIZATION HASH AMENDMENT
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:2: trailing whitespace.
+Created UTC: 2026-10-14T00:31:05Z
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:4: trailing whitespace.
+PRIOR_INVENTORY_RECORDS=27
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:5: trailing whitespace.
+PRIOR_UNCHANGED_VERIFIED=26
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:6: trailing whitespace.
+PRIOR_ATTRIBUTE_ENTRY_SUPERSEDED=1
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:7: trailing whitespace.
+NEW_EVIDENCE_FILES=5
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:8: trailing whitespace.
+AMENDMENT_RECORDS=6
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:9: trailing whitespace.
+EFFECTIVE_FILES_COVERED=32
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:10: trailing whitespace.
+ATTRIBUTES_OLD_SHA256=24524EBCCCC01067F9E4D1DA67DCB855CC670458309DBFBF5AF84F1D22AC7B2A
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:11: trailing whitespace.
+ATTRIBUTES_NEW_SHA256=1EBEA3A50E9A71FB77D43421B1F5FAC20265DF011C67B5B52491B2ADE83112FB
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:12: trailing whitespace.
+HASH_ALGORITHM=SHA256
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:13: trailing whitespace.
+PATH_BASE=REPOSITORY_ROOT
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:14: trailing whitespace.
+AMENDMENT_SELF_INCLUDED=False
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:15: trailing whitespace.
+HISTORICAL_INVENTORIES_REWRITTEN=False
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:16: trailing whitespace.
+GIT_STAGING_PERFORMED=False
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:17: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:18: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:19: trailing whitespace.
+SHA256	BYTES	RELATIVE_PATH
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:20: trailing whitespace.
+1EBEA3A50E9A71FB77D43421B1F5FAC20265DF011C67B5B52491B2ADE83112FB	438	Evidence/CP-013/.gitattributes
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:21: trailing whitespace.
+FEBD319CEBF27601CF490FE6D3D2EEFB9E28B9FB3D06A3EC5A41F4C9E65EDCED	6495	Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:22: trailing whitespace.
+BB6137D73E50A97B35CA74CEE6041712B7103C3FCFC10C5E5F3706299BAECBA6	7179	Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:23: trailing whitespace.
+108165B25B6372C80F75B5023284675B7A3E2832FD47E8824A6706AC225AE38E	10336	Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:24: trailing whitespace.
+AD2B2AD6D313CAAD88A5715E9A9EFB3D2E96EA13A6BB69BC40BE0BE745B145F2	1115	Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:25: trailing whitespace.
+E1305F78E5B0F7EB06BD3315E89EB2797B4EA026634644DFC6BDE97A9E9892E4	2239	Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:26: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:27: trailing whitespace.
+RESULT: AMENDMENT CREATED
Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt:28: trailing whitespace.
+VERIFICATION_PENDING=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:1: trailing whitespace.
+WASM-002 CP013 POST-NORMALIZATION HASH VERIFICATION
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 21:35:58 -03:00
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:4: trailing whitespace.
+EXPECTED_EFFECTIVE_FILES=32
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:5: trailing whitespace.
+VERIFIED_EFFECTIVE_FILES=32
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:6: trailing whitespace.
+GIT_BYTE_PRESERVED_FILES=32
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:7: trailing whitespace.
+EVIDENCE_SET_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:8: trailing whitespace.
+UNTRACKED_SET_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:9: trailing whitespace.
+FAILURE_COUNT=0
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:10: trailing whitespace.
+HISTORICAL_INVENTORIES_REWRITTEN=False
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:11: trailing whitespace.
+GIT_STAGING_PERFORMED=False
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:12: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:13: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:14: trailing whitespace.
+=== INDIVIDUAL VERIFICATION ===
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:15: trailing whitespace.
+FILE=Evidence/CP-013/.gitattributes
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:16: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:17: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:18: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:19: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Approved_Scope_Lock.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:20: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:21: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:22: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:23: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Full_Regression_Test_Output.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:24: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:25: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:26: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:27: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Full_Regression_Verification.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:28: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:29: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:30: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:31: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:32: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:33: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:34: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:35: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:36: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:37: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:38: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:39: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:40: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:41: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:42: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:43: trailing whitespace.
+FILE=Evidence/CP-013/CP013_GREEN_Implementation_Report.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:44: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:45: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:46: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:47: trailing whitespace.
+FILE=Evidence/CP-013/CP013_GREEN_Test_Output.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:48: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:49: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:50: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:51: trailing whitespace.
+FILE=Evidence/CP-013/CP013_GREEN_Test_Verification.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:52: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:53: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:54: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:55: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Hash_Inventory.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:56: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:57: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:58: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:59: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Hash_Inventory_Verification.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:60: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:61: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:62: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:63: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Opening_Git_Preflight.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:64: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:65: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:66: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:67: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Precedent_Test_Inspection.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:68: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:69: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:70: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:71: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Precommit_Git_Review.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:72: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:73: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:74: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:75: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:76: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:77: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:78: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:79: trailing whitespace.
+FILE=Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:80: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:81: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:82: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:83: trailing whitespace.
+FILE=Evidence/CP-013/CP013_RED_Test_Output.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:84: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:85: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:86: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:87: trailing whitespace.
+FILE=Evidence/CP-013/CP013_RED_Test_Verification.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:88: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:89: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:90: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:91: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Rustfmt_Check_Output.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:92: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:93: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:94: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:95: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:96: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:97: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:98: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:99: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Source_Inspection.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:100: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:101: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:102: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:103: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:104: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:105: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:106: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:107: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:108: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:109: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:110: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:111: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Test_Authoring_Report.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:112: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:113: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:114: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:115: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Test_Formatting_Report.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:116: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:117: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:118: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:119: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Test_Rustfmt_Output.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:120: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:121: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:122: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:123: trailing whitespace.
+FILE=Evidence/CP-013/CP013_WASM_Build_Output.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:124: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:125: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:126: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:127: trailing whitespace.
+FILE=Evidence/CP-013/CP013_WASM_Build_Verification.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:128: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:129: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:130: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:131: trailing whitespace.
+FILE=Evidence/CP-013/CP013_Whitespace_Exception_Review.txt
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:132: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:133: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:134: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:135: trailing whitespace.
+FILE=src/lib.rs
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:136: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:137: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:138: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:139: trailing whitespace.
+FILE=tests/CP013_scr_rcp_candidate_identity.rs
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:140: trailing whitespace.
+HASH_MATCH=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:141: trailing whitespace.
+GIT_BYTES_PRESERVED=True
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:142: trailing whitespace.
+
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:143: trailing whitespace.
+=== FAILURES ===
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:144: trailing whitespace.
+(none)
Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt:145: trailing whitespace.
+RESULT: PASS - 32 EFFECTIVE FILES VERIFIED
Evidence/CP-013/CP013_Precommit_Git_Review.txt:1: trailing whitespace.
+WASM-002 CP013 PRECOMMIT GIT REVIEW
Evidence/CP-013/CP013_Precommit_Git_Review.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 21:12:55 -03:00
Evidence/CP-013/CP013_Precommit_Git_Review.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Precommit_Git_Review.txt:4: trailing whitespace.
+STAGING_EMPTY=True
Evidence/CP-013/CP013_Precommit_Git_Review.txt:5: trailing whitespace.
+TRACKED_CHANGE_SET_VALID=True
Evidence/CP-013/CP013_Precommit_Git_Review.txt:6: trailing whitespace.
+UNTRACKED_PATHS_VALID=True
Evidence/CP-013/CP013_Precommit_Git_Review.txt:7: trailing whitespace.
+UNTRACKED_FILE_COUNT=22
Evidence/CP-013/CP013_Precommit_Git_Review.txt:8: trailing whitespace.
+UNEXPECTED_UNTRACKED_COUNT=0
Evidence/CP-013/CP013_Precommit_Git_Review.txt:9: trailing whitespace.
+SOURCE_WHITESPACE_CHECK_EXIT=0
Evidence/CP-013/CP013_Precommit_Git_Review.txt:10: trailing whitespace.
+SOURCE_WHITESPACE_CHECK_PASS=True
Evidence/CP-013/CP013_Precommit_Git_Review.txt:11: trailing whitespace.
+SOURCE_AND_TEST_HASHES_MATCH=True
Evidence/CP-013/CP013_Precommit_Git_Review.txt:12: trailing whitespace.
+INVENTORY_HASH_MATCH=True
Evidence/CP-013/CP013_Precommit_Git_Review.txt:13: trailing whitespace.
+NO_STAGING_OR_COMMIT_PERFORMED=True
Evidence/CP-013/CP013_Precommit_Git_Review.txt:14: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_Precommit_Git_Review.txt:15: trailing whitespace.
+
Evidence/CP-013/CP013_Precommit_Git_Review.txt:16: trailing whitespace.
+=== GIT STATUS ===
Evidence/CP-013/CP013_Precommit_Git_Review.txt:17: trailing whitespace.
+ M src/lib.rs
Evidence/CP-013/CP013_Precommit_Git_Review.txt:18: trailing whitespace.
+?? Evidence/CP-013/CP013_Approved_Scope_Lock.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:19: trailing whitespace.
+?? Evidence/CP-013/CP013_Full_Regression_Test_Output.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:20: trailing whitespace.
+?? Evidence/CP-013/CP013_Full_Regression_Verification.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:21: trailing whitespace.
+?? Evidence/CP-013/CP013_GREEN_Implementation_Report.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:22: trailing whitespace.
+?? Evidence/CP-013/CP013_GREEN_Test_Output.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:23: trailing whitespace.
+?? Evidence/CP-013/CP013_GREEN_Test_Verification.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:24: trailing whitespace.
+?? Evidence/CP-013/CP013_Hash_Inventory.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:25: trailing whitespace.
+?? Evidence/CP-013/CP013_Hash_Inventory_Verification.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:26: trailing whitespace.
+?? Evidence/CP-013/CP013_Opening_Git_Preflight.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:27: trailing whitespace.
+?? Evidence/CP-013/CP013_Precedent_Test_Inspection.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:28: trailing whitespace.
+?? Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:29: trailing whitespace.
+?? Evidence/CP-013/CP013_RED_Test_Output.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:30: trailing whitespace.
+?? Evidence/CP-013/CP013_RED_Test_Verification.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:31: trailing whitespace.
+?? Evidence/CP-013/CP013_Rustfmt_Check_Output.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:32: trailing whitespace.
+?? Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:33: trailing whitespace.
+?? Evidence/CP-013/CP013_Source_Inspection.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:34: trailing whitespace.
+?? Evidence/CP-013/CP013_Test_Authoring_Report.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:35: trailing whitespace.
+?? Evidence/CP-013/CP013_Test_Formatting_Report.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:36: trailing whitespace.
+?? Evidence/CP-013/CP013_Test_Rustfmt_Output.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:37: trailing whitespace.
+?? Evidence/CP-013/CP013_WASM_Build_Output.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:38: trailing whitespace.
+?? Evidence/CP-013/CP013_WASM_Build_Verification.txt
Evidence/CP-013/CP013_Precommit_Git_Review.txt:39: trailing whitespace.
+?? tests/CP013_scr_rcp_candidate_identity.rs
Evidence/CP-013/CP013_Precommit_Git_Review.txt:40: trailing whitespace.
+
Evidence/CP-013/CP013_Precommit_Git_Review.txt:41: trailing whitespace.
+=== TRACKED CHANGES ===
Evidence/CP-013/CP013_Precommit_Git_Review.txt:42: trailing whitespace.
+src/lib.rs
Evidence/CP-013/CP013_Precommit_Git_Review.txt:43: trailing whitespace.
+
Evidence/CP-013/CP013_Precommit_Git_Review.txt:44: trailing whitespace.
+=== UNEXPECTED UNTRACKED FILES ===
Evidence/CP-013/CP013_Precommit_Git_Review.txt:45: trailing whitespace.
+(none)
Evidence/CP-013/CP013_Precommit_Git_Review.txt:46: trailing whitespace.
+
Evidence/CP-013/CP013_Precommit_Git_Review.txt:47: trailing whitespace.
+=== SOURCE WHITESPACE DIAGNOSTICS ===
Evidence/CP-013/CP013_Precommit_Git_Review.txt:48: trailing whitespace.
+(none)
Evidence/CP-013/CP013_Precommit_Git_Review.txt:49: trailing whitespace.
+
Evidence/CP-013/CP013_Precommit_Git_Review.txt:50: trailing whitespace.
+=== COMPLETE SOURCE DIFF ===
Evidence/CP-013/CP013_Precommit_Git_Review.txt:51: trailing whitespace.
+diff --git a/src/lib.rs b/src/lib.rs
Evidence/CP-013/CP013_Precommit_Git_Review.txt:52: trailing whitespace.
+index b59ee46..b2df81b 100644
Evidence/CP-013/CP013_Precommit_Git_Review.txt:53: trailing whitespace.
+--- a/src/lib.rs
Evidence/CP-013/CP013_Precommit_Git_Review.txt:54: trailing whitespace.
++++ b/src/lib.rs
Evidence/CP-013/CP013_Precommit_Git_Review.txt:55: trailing whitespace.
+@@ -359,3 +359,25 @@ pub fn is_canonical_scr_filename_candidate(filename: &str) -> bool {
Evidence/CP-013/CP013_Precommit_Git_Review.txt:56: trailing whitespace.
+         Some(tokens) if tokens.semantic_class == "SCR"
Evidence/CP-013/CP013_Precommit_Git_Review.txt:57: trailing whitespace.
+     )
Evidence/CP-013/CP013_Precommit_Git_Review.txt:58: trailing whitespace.
+ }
Evidence/CP-013/CP013_Precommit_Git_Review.txt:59: trailing whitespace.
++
Evidence/CP-013/CP013_Precommit_Git_Review.txt:60: trailing whitespace.
++/// Derives a canonical RCP final filename candidate from an SCR staging name.
Evidence/CP-013/CP013_Precommit_Git_Review.txt:61: trailing whitespace.
++///
Evidence/CP-013/CP013_Precommit_Git_Review.txt:62: trailing whitespace.
++/// The intended final class must be supplied explicitly. This function only
Evidence/CP-013/CP013_Precommit_Git_Review.txt:63: trailing whitespace.
++/// constructs a lexical candidate; it does not validate contents, perform
Evidence/CP-013/CP013_Precommit_Git_Review.txt:64: trailing whitespace.
++/// filesystem operations, promote staged files, publish, or grant authority.
Evidence/CP-013/CP013_Precommit_Git_Review.txt:65: trailing whitespace.
++pub fn build_final_filename_candidate_for_scr(
Evidence/CP-013/CP013_Precommit_Git_Review.txt:66: trailing whitespace.
++    scr_filename: &str,
Evidence/CP-013/CP013_Precommit_Git_Review.txt:67: trailing whitespace.
++    intended_final_class: &str,
Evidence/CP-013/CP013_Precommit_Git_Review.txt:68: trailing whitespace.
++) -> Option<String> {
Evidence/CP-013/CP013_Precommit_Git_Review.txt:69: trailing whitespace.
++    if intended_final_class != "RCP" || !is_canonical_scr_filename_candidate(scr_filename) {
Evidence/CP-013/CP013_Precommit_Git_Review.txt:70: trailing whitespace.
++        return None;
Evidence/CP-013/CP013_Precommit_Git_Review.txt:71: trailing whitespace.
++    }
Evidence/CP-013/CP013_Precommit_Git_Review.txt:72: trailing whitespace.
++
Evidence/CP-013/CP013_Precommit_Git_Review.txt:73: trailing whitespace.
++    let tokens = extract_artifact_filename_tokens(scr_filename)?;
Evidence/CP-013/CP013_Precommit_Git_Review.txt:74: trailing whitespace.
++
Evidence/CP-013/CP013_Precommit_Git_Review.txt:75: trailing whitespace.
++    if tokens.serialization_extension != "txt" {
Evidence/CP-013/CP013_Precommit_Git_Review.txt:76: trailing whitespace.
++        return None;
Evidence/CP-013/CP013_Precommit_Git_Review.txt:77: trailing whitespace.
++    }
Evidence/CP-013/CP013_Precommit_Git_Review.txt:78: trailing whitespace.
++
Evidence/CP-013/CP013_Precommit_Git_Review.txt:79: trailing whitespace.
++    Some(scr_filename.replacen("__DS__SCR__", "__DS__RCP__", 1))
Evidence/CP-013/CP013_Precommit_Git_Review.txt:80: trailing whitespace.
++}
Evidence/CP-013/CP013_Precommit_Git_Review.txt:81: trailing whitespace.
+
Evidence/CP-013/CP013_Precommit_Git_Review.txt:82: trailing whitespace.
+RESULT: PASS - PRECOMMIT REVIEW
Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt:1: trailing whitespace.
+WASM-002 CP013 RED TEST HASH LOCK
Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 20:57:44 -03:00
Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt:4: trailing whitespace.
+Scope: APPROVED AND LOCKED
Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt:5: trailing whitespace.
+Test: tests/CP013_scr_rcp_candidate_identity.rs
Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt:6: trailing whitespace.
+FROZEN_TEST_SHA256=758FE6ECED824B1D05277C414D1BD223F062B3A1AA15AA1D1E3D90BD069452D3
Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt:7: trailing whitespace.
+TEST_COUNT=6
Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt:8: trailing whitespace.
+COMMITTED_SOURCE_BLOB=b59ee4678de5c956107766f75e867dd1c1f4a352
Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt:9: trailing whitespace.
+WORKING_SOURCE_BLOB=b59ee4678de5c956107766f75e867dd1c1f4a352
Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt:10: trailing whitespace.
+SOURCE_UNCHANGED=True
Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt:11: trailing whitespace.
+PREVIOUSLY_TRACKED_FILES_UNCHANGED=True
Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt:12: trailing whitespace.
+RED_EXECUTED=False
Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt:13: trailing whitespace.
+GREEN_IMPLEMENTED=False
Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt:14: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt:15: trailing whitespace.
+RESULT: PASS
Evidence/CP-013/CP013_RED_Test_Verification.txt:1: trailing whitespace.
+WASM-002 CP013 RED TEST VERIFICATION
Evidence/CP-013/CP013_RED_Test_Verification.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 20:59:07 -03:00
Evidence/CP-013/CP013_RED_Test_Verification.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_RED_Test_Verification.txt:4: trailing whitespace.
+Command: cargo +1.97.1 test --test CP013_scr_rcp_candidate_identity
Evidence/CP-013/CP013_RED_Test_Verification.txt:5: trailing whitespace.
+CARGO_EXIT=101
Evidence/CP-013/CP013_RED_Test_Verification.txt:6: trailing whitespace.
+EXPECTED_E0432_FOUND=True
Evidence/CP-013/CP013_RED_Test_Verification.txt:7: trailing whitespace.
+UNRESOLVED_IMPORT_FOUND=True
Evidence/CP-013/CP013_RED_Test_Verification.txt:8: trailing whitespace.
+MISSING_SYMBOL_FOUND=True
Evidence/CP-013/CP013_RED_Test_Verification.txt:9: trailing whitespace.
+ONLY_EXPECTED_ERROR_CODE=True
Evidence/CP-013/CP013_RED_Test_Verification.txt:10: trailing whitespace.
+ERROR_CODES=E0432
Evidence/CP-013/CP013_RED_Test_Verification.txt:11: trailing whitespace.
+SOURCE_UNCHANGED=True
Evidence/CP-013/CP013_RED_Test_Verification.txt:12: trailing whitespace.
+FROZEN_TEST_UNCHANGED=True
Evidence/CP-013/CP013_RED_Test_Verification.txt:13: trailing whitespace.
+RED_LOG_SHA256=BF2BA7CE6093966F7CD1F064B048340A584C97C89226516C619467B019D32D26
Evidence/CP-013/CP013_RED_Test_Verification.txt:14: trailing whitespace.
+GREEN_IMPLEMENTED=False
Evidence/CP-013/CP013_RED_Test_Verification.txt:15: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_RED_Test_Verification.txt:16: trailing whitespace.
+RESULT: PASS - EXPECTED RED
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:1: trailing whitespace.
+WASM-002 CP013 RAW EVIDENCE WHITESPACE PREFLIGHT
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 21:14:57 -03:00
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:4: trailing whitespace.
+FILES_SCANNED=22
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:5: trailing whitespace.
+FILES_FLAGGED=4
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:6: trailing whitespace.
+TOTAL_TRAILING_WHITESPACE_LINES=75
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:7: trailing whitespace.
+TOTAL_BLANK_LINES_AT_EOF=2
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:8: trailing whitespace.
+ORIGINAL_EVIDENCE_MODIFIED=False
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:9: trailing whitespace.
+GIT_STAGING_PERFORMED=False
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:10: trailing whitespace.
+STAGED_WHITESPACE_VERIFIED=False
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:11: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:12: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:13: trailing whitespace.
+=== FLAGGED FILES ===
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:14: trailing whitespace.
+CP013_Full_Regression_Test_Output.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:15: trailing whitespace.
+CP013_GREEN_Test_Output.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:16: trailing whitespace.
+CP013_Precedent_Test_Inspection.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:17: trailing whitespace.
+CP013_Source_Inspection.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:18: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:19: trailing whitespace.
+=== PER-FILE DETAILS ===
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:20: trailing whitespace.
+FILE=CP013_Approved_Scope_Lock.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:21: trailing whitespace.
+BYTES=2236
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:22: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:23: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:24: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:25: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_Approved_Scope_Lock.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:26: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:27: trailing whitespace.
+FILE=CP013_Full_Regression_Test_Output.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:28: trailing whitespace.
+BYTES=6617
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:29: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:30: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:31: trailing whitespace.
+BLANK_LINES_AT_EOF=1
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:32: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_Full_Regression_Test_Output.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:33: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:34: trailing whitespace.
+FILE=CP013_Full_Regression_Verification.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:35: trailing whitespace.
+BYTES=674
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:36: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:37: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:38: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:39: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_Full_Regression_Verification.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:40: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:41: trailing whitespace.
+FILE=CP013_GREEN_Implementation_Report.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:42: trailing whitespace.
+BYTES=752
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:43: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:44: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:45: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:46: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_GREEN_Implementation_Report.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:47: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:48: trailing whitespace.
+FILE=CP013_GREEN_Test_Output.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:49: trailing whitespace.
+BYTES=767
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:50: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:51: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:52: trailing whitespace.
+BLANK_LINES_AT_EOF=1
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:53: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_GREEN_Test_Output.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:54: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:55: trailing whitespace.
+FILE=CP013_GREEN_Test_Verification.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:56: trailing whitespace.
+BYTES=692
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:57: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:58: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:59: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:60: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_GREEN_Test_Verification.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:61: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:62: trailing whitespace.
+FILE=CP013_Hash_Inventory.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:63: trailing whitespace.
+BYTES=2803
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:64: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:65: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:66: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:67: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_Hash_Inventory.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:68: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:69: trailing whitespace.
+FILE=CP013_Hash_Inventory_Verification.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:70: trailing whitespace.
+BYTES=1699
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:71: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:72: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:73: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:74: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_Hash_Inventory_Verification.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:75: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:76: trailing whitespace.
+FILE=CP013_Opening_Git_Preflight.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:77: trailing whitespace.
+BYTES=340
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:78: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:79: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:80: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:81: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_Opening_Git_Preflight.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:82: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:83: trailing whitespace.
+FILE=CP013_Precedent_Test_Inspection.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:84: trailing whitespace.
+BYTES=8512
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:85: trailing whitespace.
+TRAILING_WHITESPACE_LINES=23
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:86: trailing whitespace.
+TRAILING_LINE_NUMBERS=17,19,21,26,39,52,75,77,80,88,93,100,108,120,132,154,156,159,164,169,177,189,202
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:87: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:88: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_Precedent_Test_Inspection.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:89: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:90: trailing whitespace.
+FILE=CP013_Precommit_Git_Review.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:91: trailing whitespace.
+BYTES=2907
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:92: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:93: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:94: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:95: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_Precommit_Git_Review.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:96: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:97: trailing whitespace.
+FILE=CP013_RED_Test_Hash_Lock.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:98: trailing whitespace.
+BYTES=568
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:99: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:100: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:101: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:102: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:103: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:104: trailing whitespace.
+FILE=CP013_RED_Test_Output.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:105: trailing whitespace.
+BYTES=607
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:106: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:107: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:108: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:109: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_RED_Test_Output.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:110: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:111: trailing whitespace.
+FILE=CP013_RED_Test_Verification.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:112: trailing whitespace.
+BYTES=551
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:113: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:114: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:115: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:116: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_RED_Test_Verification.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:117: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:118: trailing whitespace.
+FILE=CP013_Rustfmt_Check_Output.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:119: trailing whitespace.
+BYTES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:120: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:121: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:122: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:123: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_Rustfmt_Check_Output.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:124: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:125: trailing whitespace.
+FILE=CP013_Rustfmt_Check_Verification.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:126: trailing whitespace.
+BYTES=526
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:127: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:128: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:129: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:130: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:131: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:132: trailing whitespace.
+FILE=CP013_Source_Inspection.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:133: trailing whitespace.
+BYTES=15768
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:134: trailing whitespace.
+TRAILING_WHITESPACE_LINES=52
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:135: trailing whitespace.
+TRAILING_LINE_NUMBERS=59,77,81,84,95,104,118,132,134,139,143,146,155,163,167,187,198,204,206,210,215,224,234,238,242,246,248,259,263,267,271,273,277,287,290,298,301,308,312,314,321,324,334,340,345,351,364,371,384,393,396,408
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:136: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:137: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_Source_Inspection.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:138: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:139: trailing whitespace.
+FILE=CP013_Test_Authoring_Report.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:140: trailing whitespace.
+BYTES=446
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:141: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:142: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:143: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:144: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_Test_Authoring_Report.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:145: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:146: trailing whitespace.
+FILE=CP013_Test_Formatting_Report.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:147: trailing whitespace.
+BYTES=524
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:148: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:149: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:150: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:151: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_Test_Formatting_Report.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:152: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:153: trailing whitespace.
+FILE=CP013_Test_Rustfmt_Output.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:154: trailing whitespace.
+BYTES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:155: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:156: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:157: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:158: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_Test_Rustfmt_Output.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:159: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:160: trailing whitespace.
+FILE=CP013_WASM_Build_Output.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:161: trailing whitespace.
+BYTES=159
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:162: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:163: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:164: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:165: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_WASM_Build_Output.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:166: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:167: trailing whitespace.
+FILE=CP013_WASM_Build_Verification.txt
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:168: trailing whitespace.
+BYTES=713
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:169: trailing whitespace.
+TRAILING_WHITESPACE_LINES=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:170: trailing whitespace.
+TRAILING_LINE_NUMBERS=
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:171: trailing whitespace.
+BLANK_LINES_AT_EOF=0
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:172: trailing whitespace.
+GIT_ATTRIBUTE=Evidence/CP-013/CP013_WASM_Build_Verification.txt: whitespace: unspecified
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:173: trailing whitespace.
+
Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt:174: trailing whitespace.
+RESULT: PASS - PREFLIGHT COMPLETED
Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt:1: trailing whitespace.
+WASM-002 CP013 RUSTFMT CHECK VERIFICATION
Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 21:04:24 -03:00
Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt:4: trailing whitespace.
+Command: cargo +1.97.1 fmt --all -- --check
Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt:5: trailing whitespace.
+FORMAT_EXIT=0
Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt:6: trailing whitespace.
+SOURCE_SHA256=99741F26933AA8EEDBF1E75031F5012CA01918D06E1A3D013CA1703A49842649
Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt:7: trailing whitespace.
+SOURCE_UNCHANGED=True
Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt:8: trailing whitespace.
+FROZEN_TEST_UNCHANGED=True
Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt:9: trailing whitespace.
+TRACKED_CHANGE_SET_VALID=True
Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt:10: trailing whitespace.
+RUSTFMT_LOG_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt:11: trailing whitespace.
+READ_ONLY_CHECK=True
Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt:12: trailing whitespace.
+FULL_REGRESSION_EXECUTED=False
Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt:13: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt:14: trailing whitespace.
+RESULT: PASS
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:1: trailing whitespace.
+WASM-002 CP013 SUPPLEMENTARY SHA256 INVENTORY
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:2: trailing whitespace.
+Created UTC: 2026-10-14T00:18:18Z
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:4: trailing whitespace.
+ORIGINAL_INVENTORY_RECORDS=21
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:5: trailing whitespace.
+SUPPLEMENTARY_RECORDS=6
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:6: trailing whitespace.
+CUMULATIVE_COVERED_FILES=27
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:7: trailing whitespace.
+HASH_ALGORITHM=SHA256
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:8: trailing whitespace.
+PATH_BASE=REPOSITORY_ROOT
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:9: trailing whitespace.
+INVENTORY_SELF_INCLUDED=False
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:10: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:11: trailing whitespace.
+
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:12: trailing whitespace.
+SHA256	BYTES	RELATIVE_PATH
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:13: trailing whitespace.
+24524EBCCCC01067F9E4D1DA67DCB855CC670458309DBFBF5AF84F1D22AC7B2A	326	Evidence/CP-013/.gitattributes
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:14: trailing whitespace.
+3D88250E36BADBED442FFBDD819A013F0CD903465ED7D4956D06282E9E99D73D	2803	Evidence/CP-013/CP013_Hash_Inventory.txt
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:15: trailing whitespace.
+D4A06F2A2A6A8A04963255AB574F6B60F0727DE5627FE17793F849B9CDC2DEA0	1699	Evidence/CP-013/CP013_Hash_Inventory_Verification.txt
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:16: trailing whitespace.
+78D198D5E9600F8C77ABC60AF394B8283CE8A2058BC8C7BA0C282BC3608FC877	2907	Evidence/CP-013/CP013_Precommit_Git_Review.txt
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:17: trailing whitespace.
+D2026A2EFD9802364D5F32B6FA540A9BA9C98ACB74163E4C8E23006603043048	5583	Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:18: trailing whitespace.
+BD66B9B01572C86F77094354775239B1154865142F4696C89BF2D2B960C7BDC0	1284	Evidence/CP-013/CP013_Whitespace_Exception_Review.txt
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:19: trailing whitespace.
+
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:20: trailing whitespace.
+RESULT: INVENTORY CREATED
Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt:21: trailing whitespace.
+VERIFICATION_PENDING=True
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:1: trailing whitespace.
+WASM-002 CP013 SUPPLEMENTARY HASH VERIFICATION
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 21:21:01 -03:00
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:4: trailing whitespace.
+ORIGINAL_INVENTORY_SHA256=3D88250E36BADBED442FFBDD819A013F0CD903465ED7D4956D06282E9E99D73D
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:5: trailing whitespace.
+SUPPLEMENTARY_INVENTORY_SHA256=AD2B2AD6D313CAAD88A5715E9A9EFB3D2E96EA13A6BB69BC40BE0BE745B145F2
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:6: trailing whitespace.
+ORIGINAL_RECORDS=21
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:7: trailing whitespace.
+SUPPLEMENTARY_RECORDS=6
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:8: trailing whitespace.
+EXPECTED_RECORDS=27
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:9: trailing whitespace.
+VERIFIED_RECORDS=27
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:10: trailing whitespace.
+EVIDENCE_FOLDER_FILES=26
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:11: trailing whitespace.
+EVIDENCE_SET_MATCH=True
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:12: trailing whitespace.
+UNTRACKED_SET_MATCH=True
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:13: trailing whitespace.
+FAILURE_COUNT=0
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:14: trailing whitespace.
+GIT_STAGING_PERFORMED=False
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:15: trailing whitespace.
+HISTORICAL_EVIDENCE_MODIFIED=False
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:16: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:17: trailing whitespace.
+
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:18: trailing whitespace.
+=== INDIVIDUAL FILE VERIFICATION ===
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:19: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Approved_Scope_Lock.txt	2236
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:20: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Full_Regression_Test_Output.txt	6617
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:21: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Full_Regression_Verification.txt	674
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:22: trailing whitespace.
+PASS	Evidence/CP-013/CP013_GREEN_Implementation_Report.txt	752
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:23: trailing whitespace.
+PASS	Evidence/CP-013/CP013_GREEN_Test_Output.txt	767
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:24: trailing whitespace.
+PASS	Evidence/CP-013/CP013_GREEN_Test_Verification.txt	692
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:25: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Opening_Git_Preflight.txt	340
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:26: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Precedent_Test_Inspection.txt	8512
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:27: trailing whitespace.
+PASS	Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt	568
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:28: trailing whitespace.
+PASS	Evidence/CP-013/CP013_RED_Test_Output.txt	607
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:29: trailing whitespace.
+PASS	Evidence/CP-013/CP013_RED_Test_Verification.txt	551
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:30: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Rustfmt_Check_Output.txt	0
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:31: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt	526
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:32: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Source_Inspection.txt	15768
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:33: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Test_Authoring_Report.txt	446
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:34: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Test_Formatting_Report.txt	524
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:35: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Test_Rustfmt_Output.txt	0
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:36: trailing whitespace.
+PASS	Evidence/CP-013/CP013_WASM_Build_Output.txt	159
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:37: trailing whitespace.
+PASS	Evidence/CP-013/CP013_WASM_Build_Verification.txt	713
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:38: trailing whitespace.
+PASS	src/lib.rs	12312
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:39: trailing whitespace.
+PASS	tests/CP013_scr_rcp_candidate_identity.rs	2727
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:40: trailing whitespace.
+PASS	Evidence/CP-013/.gitattributes	326
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:41: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Hash_Inventory.txt	2803
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:42: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Hash_Inventory_Verification.txt	1699
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:43: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Precommit_Git_Review.txt	2907
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:44: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt	5583
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:45: trailing whitespace.
+PASS	Evidence/CP-013/CP013_Whitespace_Exception_Review.txt	1284
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:46: trailing whitespace.
+
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:47: trailing whitespace.
+=== FAILURES ===
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:48: trailing whitespace.
+(none)
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:49: trailing whitespace.
+
Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt:50: trailing whitespace.
+RESULT: PASS - ALL 27 HASHES VERIFIED
Evidence/CP-013/CP013_Test_Authoring_Report.txt:1: trailing whitespace.
+WASM-002 CP013 RED TEST AUTHORING
Evidence/CP-013/CP013_Test_Authoring_Report.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 20:55:02 -03:00
Evidence/CP-013/CP013_Test_Authoring_Report.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Test_Authoring_Report.txt:4: trailing whitespace.
+Scope lock: CONFIRMED
Evidence/CP-013/CP013_Test_Authoring_Report.txt:5: trailing whitespace.
+Tests authored: 6
Evidence/CP-013/CP013_Test_Authoring_Report.txt:6: trailing whitespace.
+Tests executed: NO
Evidence/CP-013/CP013_Test_Authoring_Report.txt:7: trailing whitespace.
+Rustfmt executed: NO
Evidence/CP-013/CP013_Test_Authoring_Report.txt:8: trailing whitespace.
+src/lib.rs modified: NO
Evidence/CP-013/CP013_Test_Authoring_Report.txt:9: trailing whitespace.
+Scope: SCR-to-RCP filename candidate only
Evidence/CP-013/CP013_Test_Authoring_Report.txt:10: trailing whitespace.
+Test path: tests/CP013_scr_rcp_candidate_identity.rs
Evidence/CP-013/CP013_Test_Authoring_Report.txt:11: trailing whitespace.
+Test SHA256 before formatting: AF35CB6D72DF5AEAB9FCCB5C5C3A3982BE8834164D960EE5D1616122A8E0F3EB
Evidence/CP-013/CP013_Test_Authoring_Report.txt:12: trailing whitespace.
+RESULT: PASS
Evidence/CP-013/CP013_Test_Formatting_Report.txt:1: trailing whitespace.
+WASM-002 CP013 TEST FORMATTING
Evidence/CP-013/CP013_Test_Formatting_Report.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 20:56:30 -03:00
Evidence/CP-013/CP013_Test_Formatting_Report.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Test_Formatting_Report.txt:4: trailing whitespace.
+Command: cargo +1.97.1 fmt --all
Evidence/CP-013/CP013_Test_Formatting_Report.txt:5: trailing whitespace.
+FORMAT_EXIT=0
Evidence/CP-013/CP013_Test_Formatting_Report.txt:6: trailing whitespace.
+TEST_SHA256_BEFORE=AF35CB6D72DF5AEAB9FCCB5C5C3A3982BE8834164D960EE5D1616122A8E0F3EB
Evidence/CP-013/CP013_Test_Formatting_Report.txt:7: trailing whitespace.
+TEST_SHA256_AFTER=758FE6ECED824B1D05277C414D1BD223F062B3A1AA15AA1D1E3D90BD069452D3
Evidence/CP-013/CP013_Test_Formatting_Report.txt:8: trailing whitespace.
+RUSTFMT_LOG_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
Evidence/CP-013/CP013_Test_Formatting_Report.txt:9: trailing whitespace.
+TRACKED_FILES_UNCHANGED=True
Evidence/CP-013/CP013_Test_Formatting_Report.txt:10: trailing whitespace.
+TESTS_EXECUTED=NO
Evidence/CP-013/CP013_Test_Formatting_Report.txt:11: trailing whitespace.
+SOURCE_IMPLEMENTATION_ADDED=NO
Evidence/CP-013/CP013_Test_Formatting_Report.txt:12: trailing whitespace.
+RESULT: PASS
Evidence/CP-013/CP013_WASM_Build_Verification.txt:1: trailing whitespace.
+WASM-002 CP013 CANONICAL WASM BUILD VERIFICATION
Evidence/CP-013/CP013_WASM_Build_Verification.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 21:07:33 -03:00
Evidence/CP-013/CP013_WASM_Build_Verification.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_WASM_Build_Verification.txt:4: trailing whitespace.
+Command: cargo +1.97.1 build --lib --target wasm32-unknown-unknown
Evidence/CP-013/CP013_WASM_Build_Verification.txt:5: trailing whitespace.
+BUILD_EXIT=0
Evidence/CP-013/CP013_WASM_Build_Verification.txt:6: trailing whitespace.
+RUST_TOOLCHAIN=1.97.1
Evidence/CP-013/CP013_WASM_Build_Verification.txt:7: trailing whitespace.
+TARGET=wasm32-unknown-unknown
Evidence/CP-013/CP013_WASM_Build_Verification.txt:8: trailing whitespace.
+SOURCE_UNCHANGED=True
Evidence/CP-013/CP013_WASM_Build_Verification.txt:9: trailing whitespace.
+FROZEN_TEST_UNCHANGED=True
Evidence/CP-013/CP013_WASM_Build_Verification.txt:10: trailing whitespace.
+TRACKED_CHANGE_SET_VALID=True
Evidence/CP-013/CP013_WASM_Build_Verification.txt:11: trailing whitespace.
+SOURCE_SHA256=99741F26933AA8EEDBF1E75031F5012CA01918D06E1A3D013CA1703A49842649
Evidence/CP-013/CP013_WASM_Build_Verification.txt:12: trailing whitespace.
+TEST_SHA256=758FE6ECED824B1D05277C414D1BD223F062B3A1AA15AA1D1E3D90BD069452D3
Evidence/CP-013/CP013_WASM_Build_Verification.txt:13: trailing whitespace.
+WASM_LOG_SHA256=22253096F4A2856C201EE463B0741DB221E914B13D5997B89BEAE50C785EFABE
Evidence/CP-013/CP013_WASM_Build_Verification.txt:14: trailing whitespace.
+BROWSER_RUNTIME_TESTED=False
Evidence/CP-013/CP013_WASM_Build_Verification.txt:15: trailing whitespace.
+INDEPENDENT_QA_CLAIMED=False
Evidence/CP-013/CP013_WASM_Build_Verification.txt:16: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_WASM_Build_Verification.txt:17: trailing whitespace.
+RESULT: PASS - CANONICAL WASM BUILD
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:1: trailing whitespace.
+WASM-002 CP013 WHITESPACE EXCEPTION REVIEW
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:2: trailing whitespace.
+Timestamp: 2026-10-13 21:16:47 -03:00
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:3: trailing whitespace.
+Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:4: trailing whitespace.
+EXCEPTION_SCOPE=Evidence/CP-013
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:5: trailing whitespace.
+EXCEPTION_FILES=4
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:6: trailing whitespace.
+ATTRIBUTES_SHA256=24524EBCCCC01067F9E4D1DA67DCB855CC670458309DBFBF5AF84F1D22AC7B2A
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:7: trailing whitespace.
+FAILURE_COUNT=0
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:8: trailing whitespace.
+ORIGINAL_EVIDENCE_PRESERVED=True
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:9: trailing whitespace.
+GIT_STAGING_PERFORMED=False
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:10: trailing whitespace.
+STAGED_WHITESPACE_CHECK_PENDING=True
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:11: trailing whitespace.
+DAY_066=OPEN
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:12: trailing whitespace.
+
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:13: trailing whitespace.
+=== FILE-SPECIFIC VERIFICATION ===
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:14: trailing whitespace.
+FILE=CP013_Source_Inspection.txt
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:15: trailing whitespace.
+ATTRIBUTE=Evidence/CP-013/CP013_Source_Inspection.txt: whitespace: -blank-at-eol
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:16: trailing whitespace.
+SHA256=B3F8BA7253344430E36E48B82AF5B60E2DAF4FC0F5C298A9926E428792A5873D
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:17: trailing whitespace.
+
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:18: trailing whitespace.
+FILE=CP013_Precedent_Test_Inspection.txt
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:19: trailing whitespace.
+ATTRIBUTE=Evidence/CP-013/CP013_Precedent_Test_Inspection.txt: whitespace: -blank-at-eol
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:20: trailing whitespace.
+SHA256=6CE547C1011A0269E4A46BAF500B481C7D0F5D23E3F5DB7E1DC19167CD10007E
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:21: trailing whitespace.
+
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:22: trailing whitespace.
+FILE=CP013_GREEN_Test_Output.txt
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:23: trailing whitespace.
+ATTRIBUTE=Evidence/CP-013/CP013_GREEN_Test_Output.txt: whitespace: -blank-at-eof
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:24: trailing whitespace.
+SHA256=09DEE35F2106EEE09F0E9DA838616569E221FF649B6FDE9CA286332104E75C1E
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:25: trailing whitespace.
+
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:26: trailing whitespace.
+FILE=CP013_Full_Regression_Test_Output.txt
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:27: trailing whitespace.
+ATTRIBUTE=Evidence/CP-013/CP013_Full_Regression_Test_Output.txt: whitespace: -blank-at-eof
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:28: trailing whitespace.
+SHA256=CDF724B92EBC09B1D49E53A76249B3A909B2E2DD3F5014DDE5710FCBADBC0BD7
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:29: trailing whitespace.
+
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:30: trailing whitespace.
+=== FAILURES ===
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:31: trailing whitespace.
+(none)
Evidence/CP-013/CP013_Whitespace_Exception_Review.txt:32: trailing whitespace.
+RESULT: PASS

=== BLOB FAILURES ===
(none)

RESULT: FAIL - INVESTIGATE

WASM-002 CP013 CANONICAL WASM BUILD VERIFICATION
Timestamp: 2026-10-13 21:07:33 -03:00
Parent HEAD: efca04392940e398020a5c06b9ee50296c8a1fdd
Command: cargo +1.97.1 build --lib --target wasm32-unknown-unknown
BUILD_EXIT=0
RUST_TOOLCHAIN=1.97.1
TARGET=wasm32-unknown-unknown
SOURCE_UNCHANGED=True
FROZEN_TEST_UNCHANGED=True
TRACKED_CHANGE_SET_VALID=True
SOURCE_SHA256=99741F26933AA8EEDBF1E75031F5012CA01918D06E1A3D013CA1703A49842649
TEST_SHA256=758FE6ECED824B1D05277C414D1BD223F062B3A1AA15AA1D1E3D90BD069452D3
WASM_LOG_SHA256=22253096F4A2856C201EE463B0741DB221E914B13D5997B89BEAE50C785EFABE
BROWSER_RUNTIME_TESTED=False
INDEPENDENT_QA_CLAIMED=False
DAY_066=OPEN
RESULT: PASS - CANONICAL WASM BUILD

project_day,date,day_kind,cumulative_touched,cumulative_checkpoints,cumulative_requirement_accepted,evidence
63,2026-10-10,BUILD,2,0,0,Day063 log and CP001 evidence; initial ledger scope
64,2026-10-11,BUILD,2,0,0,Day064 Workbench BUILD prototype entry; no new IDs credited
65,2026-10-12,BUILD,9,7,0,Day065 CP007 frozen-scope ledger and banked checkpoint evidence
66,2026-10-13,BUILD,12,13,0,"Day066 CP008: git 346733a962192320e0d56271add15a47b6037b6b; 28 native tests; wasm32 build; 20/20 SHA-256; human accepted; requirement partial; CP009: git dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8; 36 native tests; wasm32 build; 22/22 SHA-256; human accepted; existing requirements deepened, no new IDs; CP010: git b7c515faa9bd000369d7656e09437310261290ae; 40/40 native tests; Rust 1.97.1 wasm32 build; primary 29/29 and supplementary 8/8 SHA-256; staged whitespace PASS with 3 limited evidence-only attribute exceptions; T-approved; first lexical touch W002-CONV-004 only; no SOURCE authority; CP011: git e84ae5baeee05f9d5d30284c65b86eebba3c0f6a; 6 RED/GREEN tests, 46/46 native tests; Rust 1.97.1 canonical wasm32 --lib PASS; Rustfmt PASS after correction; 36/36 recorded SHA-256/size checks; two scoped TXT whitespace exceptions; 27 files committed; T accepted; first-touch W002-STOR-023.1 and deepen W002-CONV-004 only; no SCR publication or SOURCE authority; CP012: git efca04392940e398020a5c06b9ee50296c8a1fdd; six new targeted tests, initial GREEN 5/6 failure with trailing-whitespace validation gap preserved, CP012-local correction, corrected GREEN 6/6 and full native 52/52; Rust 1.97.1 wasm32 --lib PASS; final rustfmt PASS; 29/29 initial + 4/4 supplementary SHA256/size inputs verified with an independently verified six-record post-staging hash amendment for scoped Git attributes; 28 committed files; T-approved; deepens existing PARTIAL W002-STOR-023.1 only, +0 first-touched IDs; Day066 OPEN; CP013: git 005a38ef5e876847c4c08901c18da9c18565fd6b (parent efca04392940e398020a5c06b9ee50296c8a1fdd); explicit SCR-to-RCP final filename candidate only; six RED/GREEN target tests; native 58/58 PASS; Rust 1.97.1 rustfmt and canonical wasm32 --lib build PASS; primary 21/21, supplementary 27/27 historical, post-normalization 32/32, closing 37/37, final commit 42/42 blob identity; Git CRLF whitespace and byte-preservation remediation tracked, full staged whitespace PASS; T-approved, 42 files banked, clean tree; deepens existing PARTIAL W002-STOR-023.1, W002-STOR-023 NOT_STARTED, +0 newly touched IDs; Day066 OPEN"

requirement_id,title,family,major_family,scope,source_prd_status,source_build_flag,requirement_text,implementation_state,local_verification,independent_qa,requirement_acceptance,linked_checkpoints,checkpoint_disposition,git_commits,test_evidence,implementation_notes,last_evidence_day,source_revision
PB-STOR-001,Suitcase is the complete Data Sculptor-controlled persistence surface,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Every persistent project or analytical artifact intentionally created by Data Sculptor must be written into the visible, user-controlled Suitcase. Data Sculptor must not intentionally persist user data, analytical state, scratch state, logs, recovery state, or project metadata in hidden AppData-style locations or browser-private persistence such as OPFS. Incidental browser/OS runtime caches outside Data Sculptor control are explicitly outside this contract. F-24 browser-session persistence boundary: WASM-002 must not use IndexedDB, localStorage , OPFS, another browser-private database, or an equivalent hidden Data Sculptor-controlled persistence surface to remember a Suitcase directory handle, unsaved WIP text, project truth, analytical state, or live UI preferences between application instances. A later build may deliberately define a user-visible preferences or continuity mechanism, but WASM-002 does not create one implicitly. Volatile in-memory runtime state within the current application instance is permitted.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-002,No Data Sculptor-created subfolders,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor does not create scratch/cache subfolders inside the Suitcase. Logical organization is expressed by the flat filename grammar, open metadata, Store MAP, and human-facing aliases.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-004,__DS__ is the reserved Data Sculptor governed namespace,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Every artifact that Data Sculptor creates or intentionally interprets as one of its governed artifacts must use the exact visible prefix __DS__ . The prefix identifies participation in the Data Sculptor namespace; it does not imply that the artifact is temporary, scratch-only, or automatically generated.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-001,BANKED; separate requirement acceptance not claimed,03201870b8ec68730a0c027c572db03ccd5eeaa8,Evidence/CP-001/CP001_GREEN2_Test_Output.txt; Evidence/CP-001/CP001_WASM_Build_Output.txt,"CP001: bounded lexical artifact-class recognition via reserved_artifact_class(). Five native tests passed and Rust wasm32-target library built. No content/provenance/authority validation, persistence, or complete governed artifact contract implemented.",Day063,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-005,External inputs retain their identity; Data Sculptor derivatives enter the namespace,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"An analyst or external source file must not be renamed into __DS__ merely because Data Sculptor reads, fingerprints, certifies, or references it. If Data Sculptor creates a new governed derivative—such as an explicit converted source—the new artifact enters the __DS__ namespace under its semantic class. F-26 SOURCE boundary: a Suitcase-root file whose exact filename begins with the reserved prefix __DS__ is not treated as an analyst-owned source merely because it has a CSV-like extension or CSV-like bytes. It participates in the reserved Data Sculptor namespace and must satisfy the applicable governed-artifact contract before any governed role is granted.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-002,"T-ACCEPTED, BANKED; requirement remains partial",206dcd8b76af29edcb658a0c5a2dc40d87089fe3,Evidence/CP-002/CP002_Post_Format_Test_Output.txt; Evidence/CP-002/CP002_Post_Format_WASM_Build_Output.txt; Evidence/CP-002/CP002_Hash_Inventory_Verification.txt,CP002: exact __DS__ lexical prefix recognition via has_reserved_namespace_prefix(). Six native tests and wasm32-target compilation passed. The SOURCE boundary and governed CVT validation/emission rules in this requirement are NOT implemented.,Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-006,The governed semantic artifact-class registry is explicit and stable,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The token immediately following __DS__ must be an exact three-uppercase-letter semantic artifact class. The governed class tokens currently reserved by this PRD are: Class Meaning WKO Work Order RCP Receipt DGN Diagnostic Event — reserved; not emitted by WASM-002 HLP Help Report CER Certification Evidence CVT Converted Source RID Row Identity COL Materialized Column MAP Governed MAP artifact class — Store MAP and WKO MAP profiles CAT Store Catalog — collection-level orientation index across MAP-governed Stores INV Suitcase Inventory Snapshot SCR Scratch / Structural Support RCV Recovery Artifact — reserved; not emitted by WASM-002 BRD Brand Manifest — reserved; not emitted by WASM-002 LCK Suitcase Lock — reserved for the explicit later-V1 FINGERPRINT workflow; not emitted or maintained by ordinary WASM-002 WASM-002 emission boundary. DGN , RCV , BRD , and LCK are registered/reserved classes but are not emitted by WASM-002. Registration alone does not create a producer, serialization contract, validity contract, lifecycle, or acceptance surface. A later build that activates one of these classes must define those contracts explicitly before the class becomes emitted product behavior. The class states semantic role rather than serialization format. WIP is not an artifact class; it is the editable non-executable Work Order lifecycle state. The Flight Recorder defined by W002-STOR-012 is a derived chronological view of governed RCP artifacts and is not an additional semantic artifact class. Existing class tokens must not be silently reassigned to different meanings. A new class requires an explicit PRD revision.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-001; CP-003,CP-001 banked; CP-003 T-accepted and banked; requirement remains partial,03201870b8ec68730a0c027c572db03ccd5eeaa8; 2d06f6259de93f5beaa8eb15f8f22f171127a10e,Evidence/CP-001/CP001_GREEN2_Test_Output.txt; Evidence/CP-001/CP001_WASM_Build_Output.txt; Evidence/CP-003/CP003_Post_Format_Test_Output.txt,"CP001: bounded lexical artifact-class recognition via reserved_artifact_class(). Five native tests passed and Rust wasm32-target library built. No content/provenance/authority validation, persistence, or complete governed artifact contract implemented. CP003 adds locally verified lexical distinction between the 11 emittable-class tokens and four registered-but-not-emitted tokens; full governance/producer behavior not implemented.",Day063,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-007,Serialization is orthogonal to artifact class,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Filename extensions such as .toml , .html , .csv , .bin , and .txt describe physical serialization only and must not be used as semantic artifact classes. A governed HLP serialized as .html remains an HLP, and a governed WKO serialized as .txt remains a WKO. Any future BRD serialization must obey the same class-versus-format separation, but its format is not frozen by WASM-002.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-006,"T-ACCEPTED, BANKED; full class-specific serialization and authority contracts remain open",aff54d08dcbacaa0c54d8869749344a504c5ad61,Evidence/CP-006/CP006_RED_Test_Output.txt; Evidence/CP-006/CP006_Post_Format_Test_Output.txt; Evidence/CP-006/CP006_WASM_Build_Output.txt; Evidence/CP-006/CP006_Hash_Inventory_Verification.txt; Evidence/CP-006/CP006_Precommit_Git_Review.txt,"CP006: public ArtifactFilenameTokens and extract_artifact_filename_tokens() reuse the CP004/CP005 immutable filename validator and extract semantic_class and serialization_extension as separate borrowed lexical fields. Four new tests, total 19/19 native tests post-format; wasm32-target compilation exit 0; 20-file pre-verification SHA-256 inventory independently matched. Literal unknown class and extension values preserved without registration or approval. No class-specific extension allowlist, format contract, file contents, provenance, governed publication, trust, or authority implemented. T accepted CP006 and banked commit aff54d08dcbacaa0c54d8869749344a504c5ad61; independent Claude implementation QA remains pending. This is requirement PARTIAL, not fully closed.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-008,Namespace and class do not confer authority by themselves,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Renaming an arbitrary file to resemble a __DS__ artifact must not make it authoritative. Before treating a governed artifact as valid, Data Sculptor must validate the applicable filename grammar plus the content, provenance, fingerprint, lineage, or other evidence required by that artifact's contract. F-14/F-33 publication distinction: SCR-to-final promotion under W002-STOR-023 proves only that the artifact satisfied its class-specific publication predicate. It does not manufacture broader authority. In particular, WKO alias authority still comes from the committed WKO MAP, Store authority comes from the committed Store MAP, and CAT is orientation only. Retained SCR failure evidence remains non-authoritative, and the reserved RCV class is not emitted by WASM-002. F-26 SOURCE authority: a governed CVT is eligible as a WASM-002 SOURCE only when its exact canonical CVT identity and the publication predicate governed by W002-CONV-004 and W002-STOR-023 are satisfied. Filename resemblance, a .csv extension, or copied bytes alone do not confer CVT source authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,Cross-cutting constraint recognized in CP001/CP002 scope: filenames/classes alone convey no artifact authority. This requirement is NOT claimed implemented or touched.,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-009,Unknown and known-but-not-emitted Data Sculptor classes are preserved and reported,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"If WASM-002 encounters a syntactically valid __DS__ artifact whose three-letter semantic class is not allocated in the current registry, or whose class is a registered-but-not-emitted WASM-002 class ( DGN , RCV , BRD , or LCK ), Data Sculptor must preserve the physical file unchanged. It must not trust, execute, mutate, delete, rename, or reinterpret that file as a known emitted artifact merely because the filename has governed form. Unknown class does not mean invalid data; it means this build has no authority to interpret that class. A known-but-not-emitted class is likewise not an instruction to activate a dormant producer or lifecycle. Whenever a WASM-002 operation performs the governed Suitcase scan/enumeration relevant to such a file, the condition must be surfaced through a canonical INFO diagnostic rather than being silently ignored. INVENTORY must include the physical file under its existing metadata-only contract; if an existing classification field is rendered, an unknown class is identified as unknown/unrecognized and a known-but-not-emitted class is identified as reserved/not emitted without guessing additional semantics. F-33 adds no new Inventory schema field and does not pull the governed DIR feature into WASM-002.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-003,"T-ACCEPTED, BANKED; full preservation/INFO requirement not closed",2d06f6259de93f5beaa8eb15f8f22f171127a10e,Evidence/CP-003/CP003_Post_Format_Test_Output.txt; Evidence/CP-003/CP003_WASM_Build_Output.txt; Evidence/CP-003/CP003_Hash_Inventory_Verification.txt,"CP003: token-only Rust classify_artifact_class_token() returns registered/emittable, registered/not-emitted, unallocated, malformed-reserved, or outside-reserved disposition. Three new tests (27 cases) plus six prior regression tests passed, wasm32 compilation exit 0, 15-file historic SHA-256 inventory verified. No Suitcase scan, filesystem preservation, canonical INFO diagnostic, INVENTORY integration, full filename validity, or artifact authority implemented. RegisteredEmittable describes a class category; it does not authorize emission. Independent Claude QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-010,Namespace and class casing are canonical and exact,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor-generated names must use exact uppercase __DS__ and exact uppercase three-letter class tokens. Data Sculptor must not silently normalize variant namespace/class spellings into canonical governed artifacts. This rule applies even on case-insensitive filesystems. F-15 governed comparison rule: unless a requirement explicitly defines a different domain-specific comparison, WASM-002 semantic equality and textual reference resolution compare decoded strings by exact Unicode scalar-value sequence. Data Sculptor performs no case folding, locale folding, Unicode normalization, trimming, or host-filesystem equivalence before the comparison. Thus differently cased strings and canonically equivalent-but-differently-encoded Unicode strings remain distinct governed values. If a host filesystem cannot safely publish two physical names that the governed semantics distinguish, publication must refuse rather than merge or reinterpret the governed identities.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-007; CP-009; CP-010,"T-ACCEPTED, BANKED; exact lexical construction verified; full normative requirement remains partial; CP009 T-ACCEPTED, BANKED — pure exact-name root snapshot matching only; full requirement remains partial; CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open",3c512df519f3a2431b363e4c57dc234c02378124; dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8; b7c515faa9bd000369d7656e09437310261290ae,Evidence/CP-007/CP007_RED_Test_Output.txt; Evidence/CP-007/CP007_GREEN_Test_Output.txt; Evidence/CP-007/CP007_Post_Format_Test_Output.txt; Evidence/CP-007/CP007_WASM_Build_Output.txt; Evidence/CP-007/CP007_Hash_Inventory_Verification.txt; Evidence/CP-007/CP007_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Baseline_Test_Output.txt; Evidence/CP-009/CP009_RED_Test_Output.txt; Evidence/CP-009/CP009_GREEN_Test_Output.txt; Evidence/CP-009/CP009_Full_Regression_Test_Output.txt; Evidence/CP-009/CP009_Rustfmt_Check_Output.txt; Evidence/CP-009/CP009_Git_Whitespace_Check.txt; Evidence/CP-009/CP009_Post_Format_Test_Output.txt; Evidence/CP-009/CP009_WASM_Build_Output.txt; Evidence/CP-009/CP009_Hash_Inventory.txt; Evidence/CP-009/CP009_Hash_Inventory_Verification.txt; Evidence/CP-009/CP009_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Final_Staging_Review.txt; CP009_Git_Banking_Output.txt (separately archived post-commit evidence); Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived),"CP007: public build_immutable_artifact_filename_candidate() assembles exact class, UTC timestamp, UUID v4 and serialization extension tokens into an ordinary canonical immutable filename candidate; it delegates validation to the existing CP004/CP005 envelope validator and refuses malformed casing/identities rather than case-folding, trimming or normalizing input. Four new integration tests, total 23/23 native tests after Rustfmt; wasm32-target compilation exit 0; 21-entry SHA-256+byte inventory independently verified. Lexically valid unknown class tokens and unapproved extension tokens may be preserved as candidates; this grants no registration, serialization contract, authority, filesystem publication or content/provenance validation. The F-15 exact Unicode scalar-value semantic equality and host-filesystem collision/refusal requirements are NOT implemented. T approved and banked commit 3c512df519f3a2431b363e4c57dc234c02378124 (14 files), clean master; independent Claude adversarial implementation QA pending. Requirement remains PARTIAL, not fully closed. CP009 Day066: match_analyst_csv_root_snapshot(&str, &[RootSnapshotEntry]) -> RootSnapshotMatch applies CP008 analyst CSV candidate preflight, then exact Rust string equality (case, Unicode scalar sequence and whitespace preserved), reports no match, reported nonregular entry, ambiguous duplicate exact entries, or single caller-reported regular file. Entry origin and kind are caller assertions, not independently verified. Eight new tests; post-format full native regression 36/36; wasm32-unknown-unknown library compilation exit 0; SHA-256 inventory verified 22/22; staged whitespace exit 0; T approved and git banked 15 files, clean working tree. This is NOT actual root scanning, filesystem entry proof, browser permission, CSV/UTF-8 certification, governed CVT SOURCE eligibility or end-to-end requirement acceptance; independent Claude QA pending. CP010 Day066 also tests canonical uppercase __DS__/CVT tokens and exact lowercase .csv conversion-output extension, refusing variant prefix/class/extension spellings; existing canonical validator is reused without repair or normalization. Only lexical form is locally verified: no actual filesystem identity enforcement or publication collision handling. T accepted CP010; git b7c515faa9bd000369d7656e09437310261290ae; independent QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-011,Generated identity collisions regenerate the UUID and never overwrite,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor must never overwrite, rename, truncate, or mutate an existing artifact merely because a newly generated governed filename collides with it. For an ordinary immutable artifact using the governed UTC+UUID identity grammar, Data Sculptor must keep the originally established canonical UTC millisecond creation timestamp, generate a new canonical lowercase hyphenated UUID v4, reconstruct the candidate filename, and try creation again. Collision retry must not advance or falsify the artifact creation timestamp merely to obtain a different sort position. This retry may repeat until an unused valid identity is obtained. If UUID generation fails, the host cannot safely test/create the target, or another filesystem error prevents safe allocation, creation must refuse through the canonical diagnostic path rather than risk overwrite. Collision retry changes only the not-yet-created artifact's UUID. UUID is never used as a chronology field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-012,Names route; governed contents and provenance prove,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The filename must help humans and Data Sculptor identify the artifact's intended semantic role and route it to the correct validator. The artifact's governed content, lineage, receipt, fingerprint, provenance, and other required evidence establish what is actually true.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-013,Ordinary immutable governed artifacts use class → UTC millisecond → UUID v4 identity order,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The exact default filename grammar for an ordinary immutable Data Sculptor-governed artifact is: __DS__CCC__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.<extension> CCC is the governed semantic artifact class. YYYYMMDDTHHMMSSmmmZ is the artifact's governed UTC creation/publication timestamp at millisecond precision: four-digit year, two-digit month/day/hour/minute/second, exactly three millisecond digits, and literal T / Z . <uuid-v4> is a canonical lowercase hyphenated UUID v4. The extension is governed by the artifact's serialization contract. The token order is normative: namespace, semantic class, UTC timestamp, UUID, extension. UTC precedes UUID for every ordinary immutable class. Canonical UTC tokens with different values sort chronologically within the same class. UUID provides uniqueness and physical identity only; it must not be interpreted as a chronology tie-breaker when two artifacts share the same timestamp. When one governed all-or-refuse Store-state publication transaction creates multiple new analytical state artifacts, Data Sculptor establishes one canonical UTC millisecond publication-transaction timestamp before final identity allocation and uses that same UTC token for every newly published RID , COL , and MAP artifact created by that transaction. Each artifact receives its own UUID. Thus a first Store materialization gives the new RID, every newly materialized COL, and the successor MAP one shared transaction UTC; a later materialization gives only its newly created COL artifacts and successor MAP the new transaction UTC while the inherited RID and inherited COL artifacts retain their earlier identities. The shared transaction UTC is not the Work Order's authoring timestamp and does not require the Receipt filename UTC to match. RCP remains governed by W002-RCP-002 and carries its own receipt creation/publication timestamp. A shared transaction UTC expresses common publication membership, but MAP binding—not timestamp equality—remains authoritative for Store membership/current state. Source identity, source filename, run identity, parent identity, lineage, hashes, aliases, supersession, column identity, and other relationships must not be appended as ordinary identity tokens merely to make the filename descriptive; those facts belong in governed metadata and provenance. P2-03 successor-state UTC rule: when an operation will publish a successor Store MAP or successor WKO MAP, the transaction UTC remains a truthful observation of host UTC and must be strictly greater than the applicable chronology predecessor MAP UTC. Data Sculptor must not synthesize, increment, round forward, or otherwise fabricate a later UTC merely to satisfy chronology. UUID remains identity only and is never a chronology tie-breaker. The first MAP in a genuinely new Store lineage, and the first WKO MAP when no structurally valid WKO MAP exists, has no chronology predecessor and therefore uses the observed host UTC normally.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Immutable filename envelope, UTC and UUID syntax only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. Full requirement also governs true UTC millisecond identity, creation chronology, publication timestamp sharing, UUID identity semantics, and successor MAP chronology; none are implemented in CP004. Independent QA pending. CP005: CP005 now validates the timestamp token as a real Gregorian calendar date and ordinary UTC clock time (four-digit years 0001–9999, leap years, month lengths, 00–23 hours, 00–59 minutes/seconds, millisecond precision preserved lexically). Actual UTC issuance/publication, timestamp allocation, chronological truth, common transaction timestamp and identity authority are not implemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-014,Store-state publication transactions share UTC but never UUID identity,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Within one all-or-refuse Store-state publication transaction, every newly created RID , COL , and MAP final identity must carry the exact same canonical UTC millisecond transaction token and a distinct canonical UUID v4. UUID collision retry under PB-STOR-011 changes only the affected not-yet-created artifact UUID; it must not advance or alter the shared transaction UTC. Artifacts merely inherited or referenced by the transaction are not renamed, retimestamped, or assigned replacement UUIDs. A valid MAP may therefore bind artifacts created under several earlier transaction timestamps. Timestamp equality is evidence that artifacts were newly published by the same transaction; timestamp inequality is not evidence that artifacts belong to different Stores. P2-03 publication guard: for a successor Store-state transaction, the shared transaction UTC is established from truthful observed host UTC and is checked against the Store lineage's chronology predecessor before any newly created RID/COL/MAP artifact is promoted into its final governed class. If the observed transaction UTC is less than or equal to the chronology predecessor UTC, the publication refuses; the prior current MAP remains authoritative and no successor Store state commits.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-OPS-001,Permanent row identity after materialization,PB-OPS,PB-OPS,WASM-002,UNDER REVIEW,—,"Each logical Store has exactly one visible, deterministic RID artifact representing 1..N in governed logical CSV-record order. The header is excluded. Physical line count is not row identity: embedded newlines inside quoted fields remain inside one logical record. The RID is created when the first successful materialization establishes the Store and remains stable for the life of that Store. Every same-Store materialized or later aligned result column must contain exactly N data records in the same RID order. Multiple Stores may coexist in one Suitcase, and their RID values are unrelated; the meaningful row identity is therefore the pair (Store, RID) .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-OPS-002,Materialized columns preserve facts and alignment,PB-OPS,PB-OPS,WASM-002,UNDER REVIEW,—,Materialized columns preserve governed values in permanent row alignment. Materialization stores facts for reuse; it does not decide which rows are analytically interesting.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001,Flat Project Suitcase,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,The durable WASM-002 project model must not require semantic per-store subfolders. A logical store is represented by governed relationships among artifacts and metadata inside a flat project folder.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.1,The flat model must remain usable through ordinary filesystem tools.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.2,Native and browser hosts must use the same logical storage semantics even when their filesystem APIs differ.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.3,Folder placement must not be treated as the authoritative meaning of an artifact.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-002,Reserved Core namespace and sorting,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Every Data Sculptor Core-managed artifact must use the reserved __DS__ prefix. The prefix is deliberately visually distinctive and mechanically simple so Core artifacts cluster together under ordinary filename sorting in a mixed flat folder.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003,Three-character base-26 artifact class,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The class token must be exactly three uppercase ASCII letters A through Z, giving the fixed physical range AAA through ZZZ, and must immediately follow the reserved namespace within the frozen filename grammar.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.1,The three-character alphabetic class rule supersedes every earlier numeric class example.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.2,"Class ordering is positional base-26 using the alphabet A through Z: AAA, AAB, AAC, ... AAZ, ABA, ... ZZZ.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Ordinary lexical filename sorting therefore preserves the governed class order.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.3,"The namespace contains 26 cubed, or 17,576, possible class values while preserving one fixed-width token.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.4,Unallocated class tokens remain unassigned until explicitly allocated,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"WASM-002 does not reserve semantic meaning by numeric interval, lexical neighborhood, or implied class range. Any syntactically possible three-letter token that is not listed in the governed registry is unassigned for this build. A future artifact class may be allocated only by explicit PRD revision. Existing class meanings must never be shifted, renumbered, or reassigned merely to make room for later families.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.5,The WASM-002 artifact-class table is frozen by the governed registry,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The exact WASM-002 artifact-class table is the registry in PB-STOR-006. It is no longer a separate open storage freeze item. No additional reserved class ranges are defined by WASM-002. DGN , RCV , BRD , and LCK remain registered/reserved but are not emitted by WASM-002. Their presence in the registry does not create a WASM-002 producer, serialization contract, validity contract, lifecycle, or acceptance surface. Independent adversarial review must verify that every WASM-002-generated governed artifact uses a listed class that this build actually emits, that WIP remains a lifecycle state rather than a class, and that unknown/unallocated classes plus known-but-not-emitted classes are preserved and reported under PB-STOR-009 rather than silently interpreted or activated.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-004,Canonical Core filename envelope,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The default Core physical naming model for immutable governed artifacts is __DS__<CLASS>__<UTC>__<UUID>.<ext> . CLASS, UTC, and UUID are governed identity tokens. Human semantic labels are excluded from the physical identity envelope. A separately frozen artifact contract may define a well-known current-state singleton filename when that artifact must be updated in place and discovered by a stable name.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Default immutable filename-envelope structure only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. Singleton exception support, class-specific contracts and authority remain unimplemented. Syntactic success does not imply an authorized artifact. Independent QA pending. CP005: CP005 adds Gregorian calendar/UTC-clock validity to the already recognized immutable Core physical name. Singleton filenames, artifact-type extension rules and authorization remain unimplemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005,Canonical filename shape and fixed token lengths,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Every governed Core artifact type must have a canonical filename shape and total filename length so that a parser, browser host, native host, QA tool, or LLM can recognize malformed physical identity without interpreting variable human language. Under the Revision AH default immutable grammar, the canonical UTC token YYYYMMDDTHHMMSSmmmZ is exactly 19 ASCII characters and the canonical lowercase hyphenated UUID v4 token is exactly 36 ASCII characters. Class precedes UTC and UTC precedes UUID.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Fixed core lexical UTC (19 ASCII) and UUID v4 (36 ASCII) structure only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. No calendar validation, class/extension contract mapping, class-specific total length table, or filename publication gate is claimed. Independent QA pending. CP005: CP005 strengthens the fixed 19-ASCII-character UTC token with Gregorian calendar and UTC-clock range checks. Class-specific total filename lengths, extension mapping, and publication gates remain unimplemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.1,"If an artifact class has exactly one governed representation, all filenames in that class have one frozen total length.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.2,"If a future class permits more than one representation, each class/representation pair must still have a frozen total length.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.3,"Friendly store names, column names, aliases, and operation descriptions must never stretch or shorten a Core physical filename.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-006,Physical identity versus integrity,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,UUID identifies the governed artifact instance. SHA-256 records or verifies the exact bytes. The system must not overload one field to serve both identity and integrity.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007,Collision handling,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Physical filename collisions are expected to be rare but must be handled explicitly. Data Sculptor must never silently overwrite an existing governed artifact because a generated physical name already exists.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.1,"Before durable creation, the host must check whether the target physical name already exists.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.2,"On a UUID collision, the existing artifact is preserved and a fresh UUID is generated under the same relevant UTC/class context unless a later frozen rule requires a different deterministic response.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.3,Collision handling must be visible in the run Receipt/evidence when it occurs,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If governed identity allocation encounters one or more filename collisions before successfully allocating a non-colliding UUID identity, the canonical run Receipt must record that a collision retry occurred and the number of retries when the run reaches receipt publication. If identity allocation ultimately refuses, the refusal Receipt and diagnostic evidence must preserve the collision-failure fact without overwriting or mutating any pre-existing artifact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-008,Analyst-owned files remain analyst-owned,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Source files and analyst documents may retain their original filenames. Data Sculptor must not rename every input merely to fit the governed __DS__ namespace. For an ordinary WASM-002 analytical run, continuity between certification and materialization is established by the run-local source-binding contract, not by pretending a mutable source filename is permanent byte identity. Durable cross-run exact-byte verification requires separately governed integrity evidence such as the later V1 FINGERPRINT operation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-009,Store MAP as machine truth,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The Store MAP must provide the machine-readable relationship between governed physical artifacts and their logical meaning, including the fields required by the frozen schema for store identity, column identity, source reference/binding, run/materialization identity, row counts, status, lineage, supersession, and related provenance. Cryptographic hashes are recorded when a requirement or explicit operation actually produces them; the Store MAP contract must not imply that every source or artifact is automatically hashed during ordinary WASM-002 execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010,Aliases provide human orientation without a separate Store Index,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, human-facing orientation is provided by aliases exposed from governed Store MAP state and related governed artifacts. Aliases may help analysts navigate by meaning while preserving exact physical identities. WASM-002 does not publish or maintain a separate Store Index artifact. Richer directory/index presentation is carried by the governed DIR surface in WASM-003.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010.1,WASM-002 Store MAP profile is the unified Store metadata snapshot,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, the Store MAP profile of the governed MAP artifact class is the Store metadata snapshot. It records the Store's human-facing alias, Store-establishing source filename, exact RID artifact binding, RID alias, and the complete current materialized-column mappings and aliases governed by W002-STOR-019 through W002-STOR-019.12. WASM-002 must not create a second hidden or separately named Store-metadata file merely to bind the Store to its RID or aliases. The visible immutable __DS__MAP__...csv artifact is the authoritative governed Store MAP for this build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010.2,"Changing a friendly alias must not change physical identity, hashes, lineage, or historical provenance.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-011,"Store, row-universe, and future Boolean-selection-column rule",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Same-row derived columns and later aligned Boolean selection/filter columns remain within the same logical Store when row identity, row order, and cardinality are preserved. A future filter that evaluates every existing RID and writes one aligned two-valued Boolean result per RID does not by itself create a new row universe or a new logical Store. The canonical future selection tokens are 0 for FALSE and 1 for TRUE under PB-OPS-003 and PB-OPS-003.1. A new row universe is created only when a later governed operation actually changes which rows exist or their order—for example by building/exporting only selected rows, deduplicating rows, or otherwise materializing a different row set. Such an operation creates a new logical Store identity under the frozen row-identity contract. Filtering remains deferred from executable WASM-002 scope; this requirement freezes only the Store/RID compatibility rule that later filtering will rely upon.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-012,Current orientation and history are different truths,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Current Store orientation is represented by the applicable immutable MAP snapshot, while execution history is preserved by immutable RCP Receipts. For WASM-002, the Flight Recorder is the logical chronological view of published canonical RCP artifacts from actual Run invocations of saved immutable WKO Work Orders. It is not separately persisted and has no separate artifact class. Successful and refused runs contribute when Receipt publication succeeds; Receipt-publication failure is governed by W002-RCP-010 and must not be silently reconstructed as original evidence. Any Flight Recorder presentation is derived and regenerable from the authoritative Receipts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-013,Open representations,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Durable project artifacts should use documented open formats such as CSV, HTML, TXT, TOML, or other explicitly governed representations so that the Suitcase remains inspectable and portable outside Data Sculptor.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-014,LLM-readable storage grammar is a documentation principle,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The storage grammar, class table, Store MAP schema, current-state selection rule, and alias semantics must be documented clearly enough that an LLM collaborator can distinguish physical identity, logical meaning, integrity evidence, current state, and history without guessing. This is a documentation/readability principle for the Product Backlog PRD and related public product documentation. It does not create a new governed Suitcase artifact, require a new public-documentation file or publication operation, or add a separate WASM-002 acceptance deliverable beyond keeping the governing contract explicit and internally consistent.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-015,WASM-002 storage freeze status,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The current WASM-002 storage design preserves the resolved semantic artifact-class registry, canonical UTC millisecond rendering, class → UTC → UUID token order, UUID rendering/version, default immutable identity grammar, collision retry behavior, immutable one-Store-per-MAP versioning, Store-aware automatic MAP inheritance, complete-snapshot semantics, the exact eight-column Store MAP schema, deterministic Store/RID/COL alias defaults, rematerialization alias continuity, deterministic Store-MAP CSV serialization, Store-MAP eligibility/publication validation, materialization-coupled AS alias semantics, standalone alias maintenance using UPDATE ALIASES , explicit alias clearing with CLEAR ... ALIAS , deterministic default restoration with RESET ... ALIAS , exact historical Store-MAP selection using MAP ""<exact Store MAP filename>"" , canonical one-column COL serialization, the all-or-refuse materialization publication boundary, SCR -to-final-class host rename promotion, complete-set validation before promotion, new-Store RID-first promotion, inherited-RID reuse for existing-Store work, deterministic COL promotion, successor-MAP construction/validation as SCR , successor-MAP rename last as the Store-state commit point, rollback/recovery treatment for uncommitted promoted artifacts, the canonical RID CSV contract, the seven-operation Work Order execution surface, the canonical automatic TXT Receipt contract including exact WKO lineage, the Receipt-backed Flight Recorder, the governed HTML Suitcase Validation Certificate, the Work Order alias/comment contract plus WKO-MAP alias-registry profile, and the LCK reservation for explicit later-V1 FINGERPRINT evidence without automatic hashing in ordinary WASM-002. RID reconstruction/replacement is deliberately not part of the WASM-002 executable surface; RECOVER RID requirements are deferred to V1-BACKLOG. The Help-report provenance boundary is resolved: WASM-002 records governed HLP identity and lineage but does not automatically SHA-256 HLP bytes or create/refresh LCK evidence; exact-byte HLP integrity remains the later explicit FINGERPRINT/LCK workflow. Future branded Receipt rendering/Brand-Manifest integration remains outside the WASM-002 TXT-only Receipt contract. P2-04 closure: WASM-002 Store governance now has a complete two-tier artifact-validation model. Tier 1 supplies bounded Store-health checks for non-content-consuming paths; Tier 2 supplies full streaming RID/COL validation for content-consuming paths, candidate commit, and REPAIR MAP . The eight-column Store MAP remains unchanged and ordinary Store health makes no cryptographic claim of historical-byte identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-001,Every actual Run invocation of a saved WKO automatically produces one Receipt attempt,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"When the analyst invokes Run on a saved immutable WKO, Data Sculptor must automatically create one governed run-receipt attempt for that invocation. The Work Order must not require a RECEIPT , SAVE RECEIPT , or equivalent clause. An editable unsaved WIP is non-executable under the Work Order lifecycle contract and therefore cannot produce an execution Receipt. A saved WKO that is invoked and then refuses during validation or execution still has an execution outcome and must receive a refusal Receipt when receipt publication succeeds.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-002,The canonical WASM-002 Receipt is a governed TXT artifact with its own creation timestamp,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,The physical Receipt filename is: __DS__RCP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt The UTC token belongs to the Receipt artifact itself and represents the Receipt's governed creation/publication time under the canonical artifact-identity rules. It must not be copied from the authorizing WKO's filename merely to make the two filenames share a timestamp. The file is written visibly in the flat Suitcase under the governed RCP artifact class. Data Sculptor chooses the governed filename; the analyst does not supply it.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-003,WASM-002 Receipts are TXT-only and independent of presentation state,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"For WASM-002, the canonical run Receipt is always plain TXT. Browser theme, built-in HTML presentation, Help voice, or other presentation state must not change whether the run Receipt is emitted as TXT or alter its governed facts. WASM-002 must not emit an HTML Receipt as an alternative to the canonical TXT Receipt. Configurable Brand Manifest behavior is deferred to a future build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-005,Canonical Receipt TXT serialization is deterministic,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The WASM-002 Receipt is UTF-8 without BOM and uses LF ( 0x0A ) line endings. Every Receipt ends with exactly one final LF. No serialized line carries trailing spaces, and no blank physical lines are emitted unless a later operation-specific grammar explicitly freezes them. It is a deterministic line-oriented KEY: VALUE document with a frozen core-key order followed by operation-specific fact sections in deterministic order. KEY is an uppercase ASCII field name. The separator is exactly one ASCII colon followed by exactly one ASCII space. KEY=VALUE is not valid canonical Receipt serialization. Fixed machine tokens and non-negative decimal integers are serialized unquoted. Human-authored text, filenames, aliases, headers, and other free text are serialized as double-quoted UTF-8 strings. Inside a quoted value, a literal double quote is represented by doubling it as """" . CR and LF are not permitted inside a single serialized value; each fact remains exactly one physical line. Enumerated values use the exact uppercase tokens frozen by the applicable requirement. Non-negative integers use ungrouped ASCII base-10 digits. This shared text rule is normative for all Receipt free-text values and is acceptance-tested byte-for-byte.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-006,Every Receipt records the fixed core execution facts and exact WKO lineage,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"Every canonical WASM-002 Receipt begins with the following common envelope keys in exactly this order: RECEIPT_VERSION RECEIPT_FILENAME RECEIPT_UTC WORK_ORDER_FILENAME OPERATION RUN_STARTED_UTC RUN_FINISHED_UTC RESULT DIAGNOSTIC_ID IDENTITY_COLLISION_RETRIES Day 060 H-02 version freeze: RECEIPT_VERSION is the unquoted integer 1 for the WASM-002 Receipt contract. RECEIPT_FILENAME is the exact physical governed RCP filename. RECEIPT_UTC is exactly the canonical UTC timestamp embedded in that filename and is distinct from the run start/finish timestamps. WORK_ORDER_FILENAME is the exact physical immutable WKO identity invoked and is the authoritative WKO→RCP lineage link. Day 060 H-09 / BM-06 truthful run-timestamp semantics RUN_STARTED_UTC and RUN_FINISHED_UTC are governed truthful host-UTC observations at millisecond precision. They are not decorative labels and are not synthesized from artifact filenames. RUN_STARTED_UTC is observed only after the exact saved WKO has been resolved and found eligible to Run, and immediately before operation-specific validation/execution begins. It therefore brackets operation validation, analytical work, publication attempts, refusal processing, and any governed rollback/cleanup performed by that Run. RUN_FINISHED_UTC is observed only after the operation has reached its final SUCCESS or REFUSED analytical outcome and all non-Receipt governed effects are settled: successful artifacts are committed, refusal state is established, and required rollback/cleanup or retained non-authoritative evidence classification is complete. Receipt publication begins only after this observation. For one Run, the truthful temporal invariant is: WKO_UTC ≤ RUN_STARTED_UTC ≤ each successfully published run-artifact UTC ≤ RUN_FINISHED_UTC ≤ RECEIPT_UTC where WKO_UTC is the governed UTC token embedded in the exact WORK_ORDER_FILENAME , and “run-artifact UTC” means the governed UTC embedded in each non-Receipt artifact successfully published by that Run, including a shared materialization transaction UTC where applicable. An operation that publishes no non-Receipt artifact simply has no middle artifact-UTC comparison. Equality is permitted because the canonical timestamp precision is milliseconds. Data Sculptor must not fabricate, increment, decrement, or reorder UTC values merely to make this invariant appear true. Receipt fixtures and retained acceptance evidence must use physically possible timelines under this rule. The existing rule that WKO and Receipt filename timestamps are not required to match remains unchanged: they are distinct events, but a WKO invoked by a Run must already exist as a governed artifact before that Run begins. RESULT is a closed WASM-002 vocabulary containing exactly SUCCESS and REFUSED . No other RESULT token is valid. DIAGNOSTIC_ID: NONE is used for an ordinary successful run; a refused run carries the exact governed diagnostic identity. The shared governed absence-state vocabulary is closed to these four tokens, with these exact meanings: NONE — the fact is applicable and definitively has no value in this event; NOT_RUN — the owning stage or operation was not executed; NOT_AVAILABLE — the fact is applicable or potentially applicable, but its value could not be obtained; NOT_APPLICABLE — the fact does not apply to this event, diagnostic, operation, or artifact. These states are semantically distinct and must not be substituted for one another. A count that was actually established as zero is serialized as the integer 0 , never as an absence token. The refusal-serialization matrix for every present operation-specific key is deterministic: State of the key's owning fact/stage at refusal Required serialization The fact was authoritatively established before refusal Serialize the exact governed value. The owning stage was never entered NOT_RUN . The owning stage ran and definitively produced no value/artifact for this event NONE . The fact applies but could not be obtained NOT_AVAILABLE . The fact does not apply to this event NOT_APPLICABLE . An applicable count was authoritatively established as zero 0 . A publication identity whose publication stage was never entered NOT_RUN , except where an earlier frozen operation-specific rule explicitly fixes another token. A publication identity whose publication stage was entered but no artifact of that identity successfully published NONE . A publication identity that successfully published The exact physical governed filename. For this contract, a fact is established only when its owning validation/stage has deterministically fixed the value and later execution cannot revise that fact. Candidate allocation, partial bytes, or an uncommitted publication does not establish a published-artifact identity. If parsing/validation refuses before one of the seven governed WASM-002 operations can be identified, the Receipt uses OPERATION: UNKNOWN_OPERATION , RESULT: REFUSED , and the applicable DIAGNOSTIC_ID . After the common envelope there is no operation-specific section; the Receipt proceeds directly to CREATED_ARTIFACT_COUNT: 0 . UNKNOWN_OPERATION is not an executable operation. After all operation-specific facts and indexed lists, every Receipt ends with: CREATED_ARTIFACT_COUNT: <N>
CREATED_ARTIFACT_001: ""...""
...
CREATED_ARTIFACT_N: ""..."" The created-artifact list contains only exact physical governed filenames successfully published by the run, excluding the Receipt itself. For this accounting, an artifact is successfully published only if it remains a committed governed artifact when the Run finishes; an artifact promoted and then rolled back, or left only as non-authoritative failure residue under All-or-Refuse, is excluded from CREATED_ARTIFACT_COUNT and its indexed list. Indexed suffixes are one-based decimal with a minimum width of three digits and no maximum width: 001 through 999 are zero-padded and 1000 onward uses the ordinary full ungrouped decimal form. When a count is zero, no indexed lines for that list appear. IDENTITY_COLLISION_RETRIES is always present and is 0 when no governed filename-allocation retry occurred. Receipt/WKO filename timestamps are not required to match. One immutable WKO may be run multiple times, each producing a distinct Receipt that points back to the same exact WORK_ORDER_FILENAME . F-08 DS-STEPS / Receipt token separation. Human-authored Work Orders use the readable terminal clauses below; the Receipt serializes the corresponding machine token in OPERATION . The two columns are not interchangeable spellings: DS-STEPS terminal clause Receipt OPERATION MATERIALIZE MATERIALIZE INVENTORY INVENTORY UPDATE ALIASES UPDATE_ALIASES REPAIR MAP REPAIR_MAP REPAIR WORK ORDER REGISTRY REPAIR_WORK_ORDER_REGISTRY CONVERT WINDOWS-1252 TO UTF-8 CONVERT_WINDOWS_1252_TO_UTF_8 CATALOG STORES CATALOG_STORES For example, REPAIR_MAP is not valid DS-STEPS syntax and REPAIR MAP is not the serialized Receipt token. UNKNOWN_OPERATION remains a refusal-only Receipt value when validation cannot identify one of these seven operations; it is not an executable operation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-007,"Materialization Receipts record Store, RID, Stage 1, Stage 2, and output facts",W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"For a WASM-002 MATERIALIZE run, after the common envelope the Receipt serializes these operation-specific keys in exactly this order: SOURCE_FILENAME BASE_MAP_FILENAME RID_FILENAME RID_ACTION STAGE1_UTF8_OUTCOME CERTIFIED_SOURCE_BYTE_COUNT STAGE1_ELAPSED_MS UTF8_FIRST_INVALID_BYTE_OFFSET UTF8_STOP_REASON WINDOWS_1252_COMPATIBILITY_OUTCOME WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET STAGE2_LOGICAL_ROW_COUNT STAGE2_ELAPSED_MS CSV_REFUSAL_CONDITION CSV_SOURCE_BYTE_OFFSET CSV_PHYSICAL_LINE CSV_LOGICAL_RECORD CSV_FIELD_ORDINAL REQUESTED_COLUMN_COUNT RESOLVED_COLUMN_COUNT PUBLISHED_COL_COUNT zero or more indexed published-COL filename lines whose exact key form is PUBLISHED_COL_<INDEX>_FILENAME (for example PUBLISHED_COL_001_FILENAME , PUBLISHED_COL_002_FILENAME ) SUCCESSOR_MAP_FILENAME OPERATIONAL_NAME_FALLBACK_COUNT zero or more indexed fallback triplets: OPERATIONAL_NAME_FALLBACK_001_COLUMN_ORDINAL , OPERATIONAL_NAME_FALLBACK_001_ASSIGNED_NAME , OPERATIONAL_NAME_FALLBACK_001_REASON , continuing under the common indexed-key rule. BASE_MAP_FILENAME: NONE denotes a newly established Store with no predecessor Store MAP. Day 060 H-11 / BM-08 RID_ACTION ownership and establishment RID_ACTION is a governed execution fact describing what this Run actually established for the Store RID path. It is never an intention, plan, or prediction. RID_ACTION: REUSED is established when routing has selected an existing Store, the exact inherited RID filename is known, and that inherited RID has passed the validation required to proceed. Because the RID already exists, this fact may be established before Stage 1 or Stage 2 completes. RID_ACTION: CREATED is established only when a new-Store RID candidate has successfully completed governed promotion into its final RID identity. Merely planning, allocating, writing, closing, validating, or naming an SCR candidate does not establish CREATED . Until either of those facts is established, the common refusal matrix governs RID_ACTION . For a new-Store path that refuses before successful RID promotion, RID_ACTION is NOT_RUN . If an existing-Store route is identified but the required inherited RID fact cannot be validly established, RID_ACTION is NOT_AVAILABLE . RID_FILENAME is a separate fact: for REUSED , it is the exact already-published inherited RID filename as soon as reuse is established; for CREATED , it is the exact governed final RID filename only after successful RID promotion; before new-RID promotion succeeds, no candidate/SCR filename may be serialized as though it were a published RID. With RID_ACTION: CREATED , RID_FILENAME records the RID identity successfully promoted during the Run even if that RID is later rolled back under All-or-Refuse; rollback does not erase the already-established RID_ACTION / RID_FILENAME execution facts. The refusal-boundary matrix is therefore: Materialization state RID_ACTION RID_FILENAME Validation/routing refuses before a Store/RID path is established NOT_RUN NOT_RUN or NOT_AVAILABLE only when an applicable routing fact could not be obtained under the common matrix New Store; Stage 1 refusal NOT_RUN NOT_RUN New Store; Stage 2 refusal NOT_RUN NOT_RUN New Store; post-Stage-2 gate refusal before RID promotion NOT_RUN NOT_RUN New Store; RID candidate/promotion has not successfully completed NOT_RUN NOT_RUN New Store; RID promotion succeeds CREATED exact published RID filename Existing Store; exact inherited RID selected and validated REUSED exact inherited RID filename Existing Store; later Stage 1, Stage 2, gate, or publication refusal after reuse was established REUSED exact inherited RID filename Existing lineage identified but required inherited RID cannot be validly established NOT_AVAILABLE NOT_AVAILABLE A refusal Receipt that says RID_ACTION: CREATED while RID_FILENAME is NONE or NOT_RUN and no RID was successfully promoted is invalid evidence. STAGE1_UTF8_OUTCOME has exactly two completed Stage-1 values: PASS and FAIL . If Stage 1 never ran, the value is NOT_RUN . If Stage 1 began but a separate failure prevented a governed PASS/FAIL determination, the value is NOT_AVAILABLE . NOT_APPLICABLE is not valid for this key. UTF8_FIRST_INVALID_BYTE_OFFSET and UTF8_STOP_REASON are refusal-only Stage-1 evidence. On STAGE1_UTF8_OUTCOME: FAIL , the offset is mandatory and is the exact zero-based absolute physical source-byte offset of the first byte of the invalid sequence, and the stop reason is mandatory and exactly INVALID_UTF8_SEQUENCE . Neither field may be NOT_AVAILABLE when the Stage-1 outcome is FAIL . On PASS , both fields are NOT_APPLICABLE . If Stage 1 never ran, both are NOT_RUN . If Stage 1 began but no UTF-8 PASS/FAIL conclusion was established because of a separate failure, both refusal-only fields are NOT_APPLICABLE . WINDOWS_1252_COMPATIBILITY_OUTCOME and WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET are the governed F-16 follow-on facts. They are evaluated only after STAGE1_UTF8_OUTCOME: FAIL . When the complete second pass reaches EOF with every byte mappable, the outcome is COMPATIBLE and the offset is NOT_APPLICABLE . When the pass encounters one of the undefined bytes frozen in W002-CONV-002.4, the outcome is INCOMPATIBLE and the offset is the exact zero-based absolute physical source-byte offset of the first such byte. If the pass begins but an independent failure prevents a conclusion, both fields are NOT_AVAILABLE . If Stage 1 did not conclude FAIL , the compatibility pass does not run and both fields are NOT_RUN . The five exact CSV refusal keys CSV_REFUSAL_CONDITION , CSV_SOURCE_BYTE_OFFSET , CSV_PHYSICAL_LINE , CSV_LOGICAL_RECORD , and CSV_FIELD_ORDINAL carry the exact structural CSV refusal condition and location oracle frozen in W002-MAT-002.8. If Stage 2 never ran, all five are NOT_RUN ; if Stage 2 completed without an applicable CSV refusal, all five are NOT_APPLICABLE ; on a CSV refusal, each established location fact is serialized and any applicable fact that could not be obtained is NOT_AVAILABLE . The MATERIALIZE refusal-stage matrix is: Refusal boundary Validation/routing and request facts Stage 1 facts Stage 2 facts Publication facts Validation, before Stage 1 Serialize each fact already established; an applicable fact that validation could not obtain is NOT_AVAILABLE . REQUESTED_COLUMN_COUNT is the actual count when the KEEP list parsed completely; otherwise NOT_AVAILABLE . RESOLVED_COLUMN_COUNT and fallback records are NOT_RUN until name/ordinal resolution has run. NOT_RUN for all Stage 1-owned facts. NOT_RUN for all Stage 2-owned facts. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Stage 1 refusal Established validation/routing facts are exact values. Serialize the exact Stage 1 outcome/timing and established refusal evidence; incomplete applicable facts are NOT_AVAILABLE . The Windows-1252 compatibility fields then serialize the exact complete assessment result under the rule above; if an independent assessment failure prevents a conclusion, they are NOT_AVAILABLE . NOT_RUN for all Stage 2-owned facts. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Stage 2 refusal Established validation/routing facts are exact values. Completed Stage 1 facts are exact values; UTF-8 refusal fields are NOT_APPLICABLE when no UTF-8 refusal occurred. Because Stage 1 passed, both Windows-1252 compatibility fields are NOT_RUN . STAGE2_ELAPSED_MS is the actual elapsed time when obtained; STAGE2_LOGICAL_ROW_COUNT is NOT_AVAILABLE unless the complete accepted logical row count was established; CSV refusal facts follow the rule above. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Post-Stage-2 gate refusal before publication All facts established through the gate are serialized exactly; non-applicable UTF-8/CSV refusal fields are NOT_APPLICABLE . Both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Publication refusal before the successor-MAP publication stage is entered All facts established before refusal are serialized exactly. This row includes a new-Store RID/COL identity-allocation or promotion refusal that occurs before the successor-MAP publication stage is entered. Completed Stage 1 and Stage 2 facts remain exact; non-applicable UTF-8/CSV refusal fields use their governed absence tokens, and both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. Under All-or-Refuse publication, PUBLISHED_COL_COUNT: 0 and no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN because the successor-MAP publication stage was never entered. A candidate filename is never serialized as a published identity. Publication refusal after the successor-MAP publication stage is entered All facts established before refusal are serialized exactly. Any RID fact already established before this later refusal remains governed by the RID_ACTION/RID_FILENAME matrix above. Completed Stage 1 and Stage 2 facts remain exact; non-applicable UTF-8/CSV refusal fields use their governed absence tokens, and both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. Under All-or-Refuse publication, PUBLISHED_COL_COUNT: 0 and no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NONE because the successor-MAP publication stage was entered but no successor MAP successfully published. A candidate filename is never serialized as a published identity. Success All applicable facts are exact values; refusal-only UTF-8/CSV fields are NOT_APPLICABLE . Both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. PUBLISHED_COL_COUNT is the actual count; indexed keys are exactly PUBLISHED_COL_001_FILENAME onward in resolved KEEP order; SUCCESSOR_MAP_FILENAME is the exact published successor MAP filename. Day 060 H-24 / BM-08 publication-boundary split: these two MATERIALIZE publication-refusal rows apply the common W002-RCP-006 ownership rule to the successor-MAP publication stage. NOT_RUN means that stage was never entered; NONE means it was entered but no successor MAP successfully published. The early boundary is exercised by the RID identity-allocation exhaustion fixture; the later boundary has its own byte-exact golden fixture. OPERATIONAL_NAME_FALLBACK_COUNT is NOT_RUN until operational-name resolution has run; afterward it is the established non-negative count, including literal 0 . Fallback records are ordered by ascending physical source-column ordinal. the exact fallback key OPERATIONAL_NAME_FALLBACK_<INDEX>_REASON is exactly SOURCE_HEADER_EXCEEDS_1024_SCALARS . For successful Store-establishing materialization, the common created-artifact list is ordered RID first, newly published COLs in resolved KEEP order, then successor MAP. For successful existing-Store materialization, the inherited RID is not newly created; the list contains newly published COLs in resolved KEEP order followed by the successor MAP. P3-09 Receipt oracle: when Stage 2 refuses because the certified source contains no logical CSV record, the five CSV refusal fields must serialize exactly as CSV_REFUSAL_CONDITION: NO_HEADER_RECORD , CSV_SOURCE_BYTE_OFFSET: <exact source byte length> , CSV_PHYSICAL_LINE: 1 , CSV_LOGICAL_RECORD: 1 , and CSV_FIELD_ORDINAL: 1 . Day 060 H-13 / BM-10 clarification: within those five governed CSV refusal fields, the zero-byte and UTF-8-BOM-only cases differ only in CSV_SOURCE_BYTE_OFFSET : 0 versus 3 . Their complete Receipt bytes also differ wherever the underlying source identity, certified source byte count, Work Order identity, run/Receipt timestamps, Receipt filename/UUID, or other fixture-specific governed facts differ. The complete Receipts must never be described as differing only by one field. F-20 operational-name Receipt oracle: OPERATIONAL_NAME_FALLBACK_COUNT counts selected/materialized columns whose exact source header exceeded 1,024 Unicode scalar values. Each corresponding ..._ASSIGNED_NAME stores the final deterministic operational/default-alias name after any permitted fallback collision disambiguation; ..._REASON remains exactly SOURCE_HEADER_EXCEEDS_1024_SCALARS . The Receipt does not copy the oversized exact source header merely to explain the fallback. The common indexed-key rule from W002-RCP-006 applies without a maximum width. A full-width KEEP is therefore representable through PUBLISHED_COL_16384_FILENAME (and corresponding fallback indexes when applicable); the three-digit examples are a minimum-width convention, not a 999-item ceiling.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-008,Other WASM-002 operations add deterministic operation-specific Receipt facts,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The same common envelope, closed RESULT/absence vocabulary, refusal matrix, created-artifact tail, and indexed-key rule apply to the other executable WASM-002 operations. Their operation-specific key tables are closed as follows. INVENTORY INVENTORY_FILENAME INVENTORY_ENTRY_COUNT Refusal boundary INVENTORY_ENTRY_COUNT INVENTORY_FILENAME Validation before inventory scan NOT_RUN NOT_RUN Inventory scan/measurement refusal Exact count if the complete count was established; otherwise NOT_AVAILABLE NOT_RUN Publication refusal after the snapshot facts were established Exact established count, including 0 NONE Success Exact established count Exact physical published INV filename UPDATE_ALIASES BASE_MAP_FILENAME SUCCESSOR_MAP_FILENAME Refusal boundary BASE_MAP_FILENAME SUCCESSOR_MAP_FILENAME Validation/routing before an exact base MAP is established NOT_AVAILABLE NOT_RUN Validation/gate refusal after the exact base MAP is established Exact base MAP filename NOT_RUN Publication refusal Exact base MAP filename NONE Success Exact base MAP filename Exact published successor MAP filename REPAIR_MAP TARGET_MAP_FILENAME RID_FILENAME BROKEN_COL_COUNT zero or more indexed broken-COL filename lines using exact key form BROKEN_COL_<INDEX>_FILENAME (for example BROKEN_COL_001_FILENAME , BROKEN_COL_002_FILENAME ) RETAINED_COL_COUNT SUCCESSOR_MAP_FILENAME Broken COL filenames are ordered by ascending exact UTF-8 filename bytes. RETAINED_COL_COUNT is the actual count once repair analysis completes, including literal 0 . Refusal boundary Target/RID facts Broken/retained facts SUCCESSOR_MAP_FILENAME Validation before an exact target MAP/RID is established Established facts are exact; otherwise NOT_AVAILABLE NOT_RUN NOT_RUN Repair-analysis refusal before a repair result is established Exact established values Exact values if established; otherwise the applicable unavailable/not-run token from the common matrix NOT_RUN All-COLs-broken refusal frozen under F-03/F-09 Exact values Exact broken count/list; RETAINED_COL_COUNT: 0 NONE — this earlier frozen named refusal remains an explicit operation-specific exception. Publication refusal Exact values Exact repair-analysis values NONE Success Exact values Exact repair-analysis values Exact published successor MAP filename REPAIR_WORK_ORDER_REGISTRY BASE_WKO_MAP_FILENAME REMOVED_STALE_ROW_COUNT zero or more indexed stale-WKO filename lines using exact key form REMOVED_STALE_WKO_<INDEX>_FILENAME (for example REMOVED_STALE_WKO_001_FILENAME , REMOVED_STALE_WKO_002_FILENAME ) REGISTERED_CURRENT_COUNT zero or more indexed current-WKO filename lines using exact key form REGISTERED_CURRENT_WKO_<INDEX>_FILENAME (for example REGISTERED_CURRENT_WKO_001_FILENAME , REGISTERED_CURRENT_WKO_002_FILENAME ) REGISTERED_DEPRECATED_COUNT zero or more indexed deprecated-WKO filename lines using exact key form REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME (for example REGISTERED_DEPRECATED_WKO_001_FILENAME , REGISTERED_DEPRECATED_WKO_002_FILENAME ) SUCCESSOR_WKO_MAP_FILENAME Each filename list is independently sorted by ascending exact UTF-8 filename bytes. If the bootstrap repair WKO is newly discovered and registered, it appears in the appropriate registered list under W002-STOR-018.3 and W002-STOR-018.4. Day 060 H-10 / BM-07 count semantics: REGISTERED_CURRENT_COUNT and REGISTERED_DEPRECATED_COUNT count only previously unregistered structurally valid WKOs that this repair Run newly adds to the successor WKO MAP with the stated status. They do not count surviving pre-existing rows already present in the base registry. The indexed filename lines list exactly the corresponding newly registered WKOs and no others. If the bootstrap repair WKO is one of those newly registered WKOs, it must appear in exactly one registered list. A successful repair Receipt that omits a newly registered bootstrap repair WKO is invalid evidence. Refusal boundary Base registry Repair-plan counts/lists SUCCESSOR_WKO_MAP_FILENAME Validation before the current structurally valid WKO MAP is established NOT_AVAILABLE NOT_RUN NOT_RUN Repair-analysis/gate refusal Exact base WKO MAP filename Exact values if the repair plan was established; otherwise the common matrix governs each present field NOT_RUN Publication refusal Exact base WKO MAP filename Exact established repair-plan values NONE Success Exact base WKO MAP filename Exact established repair-plan values Exact published successor WKO MAP filename CONVERT_WINDOWS_1252_TO_UTF_8 SOURCE_FILENAME SOURCE_ENCODING UNDEFINED_WINDOWS_1252_BYTE_OFFSET MATERIALIZED_ENCODING TRANSCODING SOURCE_CHANGED OUTPUT_FILENAME UNDEFINED_WINDOWS_1252_BYTE_OFFSET is the zero-based absolute physical source-byte offset of the first byte undefined by the frozen Windows-1252 mapping when that refusal occurs. If the compatibility stage never ran it is NOT_RUN ; if the stage ran and no undefined-byte refusal occurred it is NOT_APPLICABLE ; if the fact applies but could not be obtained it is NOT_AVAILABLE . Day 060 H-14 / BM-11 undefined-Windows-1252-byte refusal oracle For CONVERT WINDOWS-1252 TO UTF-8 , an undefined Windows-1252 byte is detected during the complete pre-transcoding compatibility assessment . Transcoding has not begun when this refusal is established. When the complete compatibility assessment encounters the first undefined byte, the Receipt must serialize these exact operation facts: SOURCE_ENCODING: WINDOWS-1252-INCOMPATIBLE
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: <exact zero-based absolute physical source-byte offset>
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE WINDOWS-1252-INCOMPATIBLE is the exact SOURCE_ENCODING token for this governed CONVERT refusal. OUTPUT_FILENAME: NONE means the operation definitively established that no CVT was published for the event. No CVT candidate may be reported as output. The compatibility scan reports the first undefined byte only. Later undefined bytes do not replace that offset. Permitted changes in scan buffer/window size or boundary placement must not change the reported absolute offset. Day 060 H-25 / BM-04 already-valid-UTF-8 refusal oracle. If the complete bound source passes strict UTF-8 validation, CONVERT refuses as unnecessary before Windows-1252 compatibility assessment or transcoding. The Receipt must serialize these exact operation facts: SOURCE_ENCODING: UTF-8
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: NOT_RUN
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE UTF-8 is the exact SOURCE_ENCODING token for this governed refusal. OUTPUT_FILENAME: NONE means the classification gate definitively established that this event publishes no CVT. The Windows-1252 compatibility stage is not entered. Refusal boundary Source/classification facts Conversion facts OUTPUT_FILENAME Validation/classification refusal before conversion begins Serialize each fact already established; an applicable fact that could not be obtained is NOT_AVAILABLE . The undefined-byte offset follows the rule above. MATERIALIZED_ENCODING and TRANSCODING are NOT_RUN when conversion did not run. SOURCE_CHANGED is the exact governed value once established. NONE only for either of the two definitively classified no-CVT cases: (1) the complete source is already valid strict UTF-8 and conversion is unnecessary; or (2) the complete Windows-1252 compatibility assessment finds an undefined byte. For other validation/classification refusals before conversion begins, OUTPUT_FILENAME: NOT_RUN unless another normative rule explicitly assigns a different closed token. Conversion/refusal after bounded transcoding begins but before publication Exact established source/classification facts Serialize exact established conversion facts; applicable incomplete facts use NOT_AVAILABLE . NOT_RUN Publication refusal Exact established facts Exact established conversion facts NONE Success SOURCE_ENCODING: WINDOWS-1252-COMPATIBLE ; undefined-byte offset NOT_APPLICABLE MATERIALIZED_ENCODING: UTF-8 ; TRANSCODING: BOUNDED_STREAMING ; SOURCE_CHANGED: NO Exact published CVT filename CATALOG_STORES CATALOG_ENTRY_COUNT CATALOG_FILENAME Refusal boundary CATALOG_ENTRY_COUNT CATALOG_FILENAME Validation/discovery refusal before the complete authoritative catalog row set is established NOT_AVAILABLE NOT_RUN Publication refusal after the complete catalog row set is established Exact established count, including 0 NONE Success Exact established count Exact physical published CAT filename On success, CATALOG_ENTRY_COUNT equals the number of data rows in the published CAT. CAT itself is the only new non-Receipt governed artifact produced by the operation. RECOVER RID / RECOVER_RID is not a valid executable WASM-002 operation in Revision BM.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-009,"Receipt truth is execution evidence, not presentation authority",W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The Receipt records what Data Sculptor actually attempted, observed, refused, and successfully published. It must not reinterpret the analyst's WKO, replace the Store MAP, or become a second analytical command surface. The WKO remains the durable authorization record; Store MAP/RID/COL artifacts remain the governed analytical state; diagnostic events remain the refusal/help truth; the Receipt cross-references those facts as the durable run ledger. The body of published canonical RCP artifacts is the authoritative evidence substrate for the Flight Recorder logical view defined in W002-STOR-012.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-010,Receipt-publication failure is itself a governed evidence failure,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"Data Sculptor must never claim that a durable Receipt exists until the RCP file has been successfully written and closed in the Suitcase. If host or filesystem failure prevents Receipt publication, the browser must surface a canonical diagnostic through the Help Engine stating that receipt evidence could not be persisted. A receipt-publication failure does not retroactively falsify analytical artifacts that were already successfully committed under their own publication contracts, but the user-facing run summary must clearly distinguish analytical outcome from receipt-persistence failure. Data Sculptor must not invent, backdate, or silently reconstruct a Receipt and present it as the original run artifact. F-14 publication path, reconciled by F-33: the RCP itself is first written as the corresponding SCR candidate under W002-STOR-023.1, closed, reopened and validated against the exact Receipt serialization/key contract before the class-token rename to RCP . If final RCP promotion fails, the candidate remains non-authoritative SCR evidence. Help may identify the exact retained SCR filename when that fact was established, but it must still state that the canonical Receipt was not persisted. WASM-002 does not emit an RCV artifact for this failure.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-001,Successful materialization Receipt and WKO-lineage acceptance,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,"A Store-establishing materialization fixture must run one saved WKO, publish exactly one canonical TXT RCP, and prove that the Receipt identifies the exact WKO through WORK_ORDER_FILENAME , source, RID_ACTION: CREATED , new RID, Stage 1 result/bytes/time, Stage 2 row count/time, all requested COL artifacts in resolved KEEP order, successor Store MAP, published-artifact count, timestamps, and RESULT: SUCCESS . The RCP filename UTC must represent the Receipt artifact's own creation/publication event and must not be required to equal the WKO filename UTC. The same immutable WKO must then be executable again in an appropriate fixture, producing a second distinct RCP with its own Receipt/run timestamps while both Receipts contain the same exact WORK_ORDER_FILENAME . A later same-Store materialization fixture must additionally prove RID_ACTION: REUSED and the original RID filename. The Store-establishing fixture must also prove that the newly created RID, every newly created COL, and the successor MAP carry one identical publication-transaction UTC token while each has a distinct UUID; the RCP filename UTC remains its own Receipt publication timestamp and is not required to equal that analytical transaction UTC. A later same-Store materialization must prove that newly created COLs and its successor MAP share the later transaction UTC while the inherited RID retains its original timestamp/UUID. F-07 Stage-1 success fixture: a successful materialization Receipt must serialize STAGE1_UTF8_OUTCOME: PASS , with UTF8_FIRST_INVALID_BYTE_OFFSET: NOT_APPLICABLE and UTF8_STOP_REASON: NOT_APPLICABLE . Separate refusal fixtures under W002-RCP-ACC-002 must prove FAIL plus the mandatory exact offset and INVALID_UTF8_SEQUENCE . F-20 maximum-width Receipt acceptance: a successful full-width materialization fixture must prove that published-COL indexed keys continue through PUBLISHED_COL_16384_FILENAME using the minimum-three-digit/no-maximum suffix rule. Oversized-header fixtures must prove the exact fallback count, source ordinal, assigned operational name, and SOURCE_HEADER_EXCEEDS_1024_SCALARS reason without embedding the oversized source-header text in the Receipt merely as fallback evidence. F-23 additional successful-Receipt coverage: acceptance must include a successful INVENTORY run whose RCP carries the exact governed INVENTORY operation-specific facts and a successful UPDATE_ALIASES run whose RCP carries the exact BASE_MAP_FILENAME and SUCCESSOR_MAP_FILENAME while reporting only actually published artifacts in the common created-artifact tail. F-23 UUID-collision seam: using a controlled UUID sequence, acceptance must force one or more governed filename collisions before successful allocation. Every pre-existing colliding artifact must remain byte-for-byte unchanged; allocation must retain the originally established governed UTC context while changing only the not-yet-created UUID as permitted; and the published Receipt must report the exact retry count in IDENTITY_COLLISION_RETRIES . Day 060 H-09 success-timeline acceptance Every retained successful Receipt fixture must satisfy the W002-RCP-006 temporal invariant using its actual embedded UTC tokens. Acceptance must mechanically prove: the invoked WKO UTC is less than or equal to RUN_STARTED_UTC ; every non-Receipt governed artifact successfully published by that Run has a governed artifact/transaction UTC between RUN_STARTED_UTC and RUN_FINISHED_UTC , inclusive; RUN_FINISHED_UTC is less than or equal to the Receipt filename/ RECEIPT_UTC ; and no fixture relies on an artifact timestamp that occurs after the Receipt that claims it, or before the Run that created it. A controlled-clock acceptance seam may be used to make equality and strict-order cases deterministic, but the fixture generator must not alter timestamps after the fact merely to satisfy the checker. Day 060 H-11 successful RID_ACTION acceptance A successful new-Store materialization Receipt may report RID_ACTION: CREATED only because the RID was actually promoted into its final governed RID identity during that Run. A successful existing-Store materialization Receipt reports RID_ACTION: REUSED and the exact inherited RID filename; no new RID candidate is created for that Run.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-002,Refusal Receipt acceptance,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,"A saved WKO that is actually Run and deterministically refuses must still produce one canonical TXT Receipt when Receipt publication itself remains available. The emitted bytes must conform to the closed RESULT vocabulary, the four governed absence tokens, the exact operation-specific key spelling/order, and the refusal matrix in W002-RCP-006 through W002-RCP-008. Acceptance must include byte-exact golden Receipt fixtures for every distinct refusal-boundary row required to exercise the serialization matrix for each of the seven executable WASM-002 operations: MATERIALIZE , INVENTORY , UPDATE_ALIASES , REPAIR_MAP , REPAIR_WORK_ORDER_REGISTRY , CONVERT_WINDOWS_1252_TO_UTF_8 , and CATALOG_STORES . Multiple Diagnostic IDs that map to the same refusal boundary and the same serialization row do not require duplicate byte fixtures merely because the Diagnostic ID differs. Acceptance must additionally include one byte-exact UNKNOWN_OPERATION refusal fixture proving the common envelope, OPERATION: UNKNOWN_OPERATION , RESULT: REFUSED , the exact diagnostic ID, absence of any operation-specific section, and immediate CREATED_ARTIFACT_COUNT: 0 . Fixtures must prove that NONE , NOT_RUN , NOT_AVAILABLE , and NOT_APPLICABLE retain distinct meanings; an established zero count is serialized as 0 ; no candidate filename is reported as a published identity; and every indexed key uses its complete frozen name and the minimum-three-digit/no-maximum suffix rule. An unsaved WIP must be proven unable to Run and therefore must not create an execution Receipt. F-16 materialization-refusal fixtures: byte-exact MATERIALIZE refusal Receipts must exercise the new compatibility pair in all four applicable states: NOT_RUN when Stage 1 did not fail; COMPATIBLE plus NOT_APPLICABLE offset; INCOMPATIBLE plus the exact first undefined-byte offset; and NOT_AVAILABLE / NOT_AVAILABLE when an independent compatibility-read failure prevents a conclusion. F-23 Receipt-publication failure fixture, reconciled by F-33: a controlled filesystem-fault seam must make canonical RCP publication fail after the underlying analytical/refusal outcome has been established. Acceptance must prove the W002-RCP-010 boundary exactly: no final RCP is fabricated or claimed, any retained candidate evidence follows the governed SCR retention/non-authority rules in W002-STOR-023.1, no RCV artifact is emitted, the user-facing diagnostic distinguishes analytical outcome from Receipt-persistence failure, and already committed analytical artifacts are not retroactively falsified solely because RCP persistence failed. F-23 ultimate identity-allocation failure fixture: with Receipt publication itself still available, a controlled identity-allocation seam must force a governed operation artifact to exhaust/fail safe allocation. The operation must refuse without overwriting or mutating any colliding pre-existing artifact, and the refusal Receipt/diagnostic evidence must preserve the established collision/allocation-failure facts under PB-STOR-011 and W002-STOR-007.3. Day 060 H-02 fixture binding: the retained golden corpus must use RECEIPT_VERSION: 1 and the fixture-pinned diagnostic allocations in W002-HELP-001.8. The corpus must contain one success Receipt for each of the seven executable operations, one refusal Receipt for every distinct refusal-boundary row in W002-RCP-007/W002-RCP-008, the three additional Stage-1 compatibility variants needed to cover COMPATIBLE , INCOMPATIBLE , and NOT_AVAILABLE after UTF-8 failure, and one UNKNOWN_OPERATION Receipt. Publication-refusal fixtures may use the operation-specific H-02 publication diagnostic and a non-zero IDENTITY_COLLISION_RETRIES value to satisfy the ultimate identity-allocation-failure acceptance boundary without inventing a second diagnostic solely for the same serialization row. Day 060 H-09 refusal-timeline acceptance Every retained refusal Receipt fixture must also satisfy the W002-RCP-006 temporal invariant. For a refusal with no successfully published non-Receipt artifact, acceptance proves WKO_UTC ≤ RUN_STARTED_UTC ≤ RUN_FINISHED_UTC ≤ RECEIPT_UTC . If a refusal legitimately leaves one or more successfully committed non-Receipt artifacts from an already-completed stage, each such artifact UTC must fall between Run start and Run finish and must be listed truthfully under the governing created-artifact rules. Day 060 H-11 / BM-08 RID_ACTION refusal acceptance Byte-exact MATERIALIZE refusal acceptance must distinguish new-Store and existing-Store RID paths: new-Store validation, Stage 1, Stage 2, and post-Stage-2 gate refusals before successful RID promotion serialize RID_ACTION: NOT_RUN and do not serialize a candidate as a published RID; a controlled new-Store refusal after RID promotion has successfully completed may serialize RID_ACTION: CREATED together with the exact published RID filename, but only if that RID was actually promoted and the remaining refusal/rollback evidence is truthful under the publication rules; an existing-Store refusal after the inherited RID has been selected and validated serializes RID_ACTION: REUSED and the exact inherited RID filename even when Stage 1, Stage 2, a later gate, or publication subsequently refuses; an existing lineage whose required inherited RID cannot be validly established serializes RID_ACTION: NOT_AVAILABLE and RID_FILENAME: NOT_AVAILABLE rather than claiming reuse. Acceptance must specifically reject the historical H-02 fixture pattern that reported RID_ACTION: CREATED while no RID existed and CREATED_ARTIFACT_COUNT: 0 . Day 060 H-12 H-02 publication-diagnostic scope The H-02 operation-specific publication diagnostics whose required facts are artifact_class and collision_retry_count are acceptance pins for governed filename identity-allocation collision exhaustion. They are not catch-all Diagnostic IDs for unrelated publication failures such as chronology guards, write/close/rename failures, or malformed predecessor state. Those distinct conditions use their own registry allocations; DS-UTC-001 is independently frozen for the strict monotonic-UTC guard. Day 060 H-13 / BM-10 zero-byte and BOM-only NO_HEADER_RECORD Receipt fixtures The retained golden corpus must contain two distinct byte-exact MATERIALIZE refusal Receipts for the P3-09 no-header boundary: Zero-byte source: the bound source has exact certified byte count 0 ; Stage 1 passes; Stage 2 refuses with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD ; CSV_SOURCE_BYTE_OFFSET: 0 ; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; and CSV_FIELD_ORDINAL: 1 . UTF-8-BOM-only source: the bound source consists exactly of bytes EF BB BF and has exact certified byte count 3 ; Stage 1 passes; Stage 2 refuses with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD ; CSV_SOURCE_BYTE_OFFSET: 3 ; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; and CSV_FIELD_ORDINAL: 1 . These two Receipt fixtures must carry their own truthful source filenames, Work Order identities, run timestamps, Receipt identities, and other governed facts. Only the five-field CSV refusal tuple has the narrower relationship stated in W002-RCP-007; the complete Receipt files are not otherwise required to be byte-identical. Day 060 H-14 / BM-11 CONVERT undefined-byte Receipt binding The coordinated golden Receipt corpus must include the byte-exact CONVERT_WINDOWS_1252_TO_UTF_8 refusal fixture from W002-CONV-ACC-002 using source bytes 41 81 42 . Its Receipt must carry UNDEFINED_WINDOWS_1252_BYTE_OFFSET: 1 and the exact pre-transcoding refusal values frozen in W002-RCP-008.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-003,Receipt TXT is invariant to presentation state in WASM-002,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,The same governed run must be exercised under materially different permitted browser presentation states. In each case the run Receipt must remain an RCP TXT artifact governed by the same receipt serialization and facts. Presentation must not convert it to HTML or alter execution truth in WASM-002. This acceptance gate does not require a configurable Brand Manifest; that capability is deferred.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-001,A Suitcase may contain multiple Stores and each current Store state binds exactly one RID,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The Suitcase is a workspace and may contain zero, one, or multiple logical Stores. Every committed Store state binds exactly one governed current RID artifact. RID values are unique only within their Store row universe; they are not Suitcase-global identifiers. Ordinary same-row-universe work reuses that RID unchanged. In WASM-002, a missing, unreadable, or invalid current RID makes the Store INVALID ; no executable WASM-002 operation regenerates or substitutes that RID. Read-only Help/evidence may explain analyst-owned restoration or lineage-retirement choices, but Data Sculptor does not publish a replacement RID. The stable logical row reference in WASM-002 is conceptually (Store lineage, RID value) ; the current physical RID identity is the exact rid_filename bound by the authoritative MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-002,The Store RID is generated automatically once and reused unchanged in WASM-002,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"When the first successful materialization establishes a new Store, Data Sculptor must automatically generate that Store's initial RID artifact as part of the same Stage 2 operation and the same all-or-refuse publication boundary. The analyst does not separately request ordinary RID generation. Before the RID SCR candidate is created, Data Sculptor establishes the materialization publication-transaction UTC under PB-STOR-013/PB-STOR-014 and allocates a RID-specific UUID. The canonical RID byte stream is then written as the visible governed SCR candidate whose filename already carries that exact UTC, UUID, and .csv extension intended for the final RID identity. Requested materialized columns likewise begin as governed SCR candidates whose distinct COL-specific UUIDs are allocated before those candidates are opened under the same transaction UTC. The new RID candidate and all requested COL candidates must reach EOF, reconcile to the same accepted Store row count N, and pass their required final validation before any candidate is promoted. After complete-set validation, Data Sculptor promotes the RID candidate first by host rename that changes only the three-letter semantic class token from SCR to RID . The candidate bytes, UTC token, UUID, and .csv extension must remain unchanged across that promotion. Requested COL candidates are promoted only after RID promotion succeeds. If later promotion or successor-MAP publication prevents transaction commit, the newly promoted RID is not committed Store state merely because an RID-looking file exists; it must be rolled back where safely possible or retained as attributable recovery evidence under the materialization failure contract. A first Store-establishing materialization commits exactly one RID regardless of how many requested COLs are materialized. Later ordinary materializations and other same-row-universe WASM-002 operations must reuse that RID unchanged. They must not create a new RID candidate, regenerate, replace, renumber, or silently supersede the inherited RID. RID reconstruction/replacement is not an executable WASM-002 operation. Any future governed RID-recovery design remains deferred and must be reintroduced by an explicit later PRD freeze.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-003,RID physical identity uses the governed RID filename grammar,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The physical RID filename must be: __DS__RID__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv The filename contains governed physical identity only. A Store name or friendly analyst alias must not be inserted into, substituted for, or used to rename this immutable physical RID filename.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-004,RID is a canonical one-column CSV containing the exact sequence 1 through N,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The RID artifact must serialize as a canonical one-column UTF-8 CSV with: exactly one UTF-8 BOM at byte zero; a structural first logical record exactly N=<value> , where <value> is the canonical unsigned base-10 representation of the Store's total logical data-row count N ; uppercase N , exactly one equals sign, no spaces, no sign, no leading zeroes except the single digit 0 , and no separators or locale formatting; LF ( 0x0A ) record terminators on every supported host; exactly N data records after the header, containing the consecutive unquoted decimal integers 1 through N in order; no zero RID data value, negatives, signs, thousands separators, decimal points, exponent notation, or leading zeroes; and a final LF after the last record. For N=0 , the canonical bytes are the UTF-8 BOM followed by N=0 and LF, with no data records. The N=<value> record is structural metadata and does not consume a Store row. The governed RID artifact class/filename and Store MAP binding identify the artifact as a RID; the literal header RID is not used by the frozen WASM-002 serialization.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-005,RID cardinality and order define same-Store column alignment,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"If a Store RID contains N data records, every governed column claimed to be aligned to that Store must contain exactly N data records in the same RID order. Data Sculptor must not describe a shorter, longer, reordered, duplicated, or row-shifted column as aligned to that Store. This invariant applies to materialized source columns in WASM-002 and is the stable contract that later calculated, Boolean-selection, verification, or left-join enrichment columns may rely upon.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-006,A different row universe requires a different Store and a new RID,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,An operation that changes which rows exist or changes their governed order does not mutate the existing Store RID. It establishes a different row universe and therefore requires a new logical Store identity and a new RID artifact beginning again at 1 for that new Store. Filtering that is represented only as a same-length aligned Boolean/selection column does not itself change the row universe; building a new reduced/reordered row set later would.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-007,The Store MAP gives RID a friendly alias without changing RID identity,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The physical RID artifact remains identified by its immutable governed filename and semantic RID class. Every valid Store MAP records that exact rid_filename and one current human-facing rid_alias . Changing the RID alias must not rename, rewrite, regenerate, or alter the meaning of the RID artifact. The same Store MAP also records the Store alias and materialized-column aliases, so the analyst-facing names and the physical Store spine remain explicitly connected in one visible governed artifact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-008,Ordinary RID generation is implicit Store infrastructure; RID reconstruction is deferred,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"WASM-002 materialization Work Orders specify the analyst's requested source columns and aliases. They must not require or expose a separate instruction such as RID , ROW INDEX , GENERATE RID , or an equivalent switch to create the Store row spine. Initial RID generation for a new Store is mandatory engine behavior implied by successful MATERIALIZE . WASM-002 must not provide an option to disable it. When ordinary materialization extends an existing Store, the engine must recognize and reuse that Store's existing RID. If that bound RID is missing or invalid, the Store is INVALID and ordinary Store operations refuse. WASM-002 exposes no RECOVER RID executable syntax. A future explicit recovery design may be considered in V1-BACKLOG, but it is not part of this build contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-001,Canonical RID byte serialization acceptance,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"An acceptance fixture with N=5 must prove exact governed bytes equivalent to a UTF-8 BOM followed by: N=5
1
2
3
4
5 Every record uses LF termination and the file ends with a final LF. A separate N=0 fixture must prove exact bytes equivalent to UTF-8 BOM + N=0 and no data records. The N=5 fixture repeated under different permitted source-window boundaries must produce byte-identical RID content apart from the governed physical filename allocated to the artifact. Full RID validation must also prove that the declared N , the number of following data records, and the exact sequence 1..N agree.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-002,Multiple Stores in one Suitcase retain independent RID spines,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,An acceptance fixture must establish at least two Stores with different row counts in the same Suitcase and prove that each Store publishes and retains exactly one distinct governed RID artifact. RID values may overlap numerically across Stores without collision because the Store identity disambiguates them.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-003,Later same-Store materialization reuses rather than regenerates RID,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"An acceptance fixture must establish a Store with an initial materialization, record the physical RID identity and exact RID bytes, then perform a later permitted materialization that adds at least one aligned COL without changing the row universe. The later run must reference and reuse the original RID artifact; no replacement RID may be published and the original RID bytes must remain unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-004,Implicit RID generation acceptance for single- and multi-column first materialization,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"Acceptance must execute two Store-establishing Work Orders that contain no RID or row-index syntax: one requesting exactly one source column and one requesting multiple source columns. Each successfully committed run must publish exactly one governed RID artifact regardless of the number of requested COL artifacts. The fixture must prove that RID creation occurs during the same Stage 2 source-record traversal that establishes the Store row count rather than by requiring a second source pass solely to construct RID. The RID row count must reconcile exactly with every requested COL row count and the final accepted Store N. Before RID candidate creation, acceptance must prove that the publication-transaction UTC and RID-specific UUID are already established, and that the governed SCR filename carries exactly the UTC, UUID, and .csv extension intended for the final RID identity. Before complete-set validation, the RID bytes must exist only as that governed SCR candidate. Acceptance must prove that the RID candidate is promoted by host rename only after the complete RID/COL candidate set validates, that the physical-name change is exactly the class token SCR to RID , that candidate bytes/UTC/UUID/extension are unchanged across promotion, that RID promotion precedes COL promotion, and that the resulting RID is not considered committed Store membership until the successor MAP is successfully promoted and binds that exact RID filename.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-001,INVENTORY is an explicit standalone WASM-002 Work Order operation,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 form is: SUITCASE: .
WORK ORDER AS ""Inventory this Suitcase""
INVENTORY INVENTORY reads the authorized Suitcase directory metadata and creates one governed Suitcase Inventory Snapshot. It is read-only with respect to pre-existing Suitcase files. In WASM-002, an INVENTORY Work Order must not also request materialization, conversion, fingerprinting, another analytical operation, or another Work Order invocation. F-08 structure freeze: after the common SUITCASE: . / WORK ORDER AS ""..."" preamble, INVENTORY is the sole semantic operation clause and is terminal. No SOURCE , MAP , KEEP , alias mutation, conversion, repair, catalog, or composition clause is valid in the same WKO.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-002,Suitcase Inventory uses the governed INV artifact class and canonical filename grammar,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"A successful inventory produces exactly one visible flat TXT artifact whose physical filename is: __DS__INV__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt The UTC and UUID tokens follow the existing governed artifact-identity rules. Data Sculptor must not create an inventory subfolder, hidden cache copy, or alternate private persistence. F-14 publication: the INV body is produced first under the matching W002-STOR-023.1 SCR identity with the same UTC, UUID and .txt extension intended for the final INV. Publication to INV occurs only after the complete scan and deterministic INV serialization validate successfully.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-003,"The lightweight inventory records filename, exact byte length, and last-modified metadata",W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"For every regular file present in the authorized flat Suitcase root at snapshot time, the inventory must record: the exact visible filename; the exact byte length reported by the host file object; and the host/browser-reported last-modified value rendered in the canonical UTC millisecond form when available. WASM-002 must not claim access to a true file-creation timestamp. It must not infer, fabricate, or substitute a creation time from the last-modified value. If usable last-modified metadata is unavailable, the inventory must represent that fact explicitly rather than invent a timestamp. P3-10 last-modified availability test: host/browser last-modified metadata is usable only when the host supplies a finite, non-negative whole-number millisecond value that can be represented in the canonical UTC millisecond timestamp form. If that test fails, the inventory must serialize the governed unavailable value rather than infer, round, substitute, or fabricate a timestamp.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-004,INVENTORY does not read file contents or compute content hashes,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The lightweight inventory must be produced from directory enumeration and file metadata only. Data Sculptor must not open and stream the contents of each listed file merely to create the inventory, and it must not compute SHA-256 or another content fingerprint as an implicit side effect. Its cost should therefore scale primarily with the number of directory entries and metadata calls, not with the aggregate byte size of the files. A 7 GB CSV and a 7 KB CSV each contribute one metadata entry rather than requiring their contents to be read.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-005,Inventory scope is the authorized flat Suitcase root,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"WASM-002 inventories regular files and immediate child directory entries in the directory denoted by SUITCASE: . . Data Sculptor must not recursively inspect, enumerate, size, hash, or otherwise inventory the contents of a child directory in this build. Each immediate child directory is recorded as a directory entry by its exact visible name only. Its nested contents and aggregate size are outside the WASM-002 Inventory contract. This rule preserves the flat-Suitcase storage model while making the presence of user-created directories explicit rather than silently omitting them. F-26 SOURCE distinction: inclusion in an Inventory is evidence that an entry was physically visible to the Inventory operation; it does not make that entry eligible for a Work Order SOURCE . SOURCE eligibility is the narrower contract in W002-WKO-009.1.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-006,Inventory serialization is deterministic UTF-8 TXT,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The INV artifact is a deterministic human-readable TXT document encoded as UTF-8 without BOM, using LF ( 0x0A ) line endings, the same KEY: VALUE line grammar, and the same quoted-text escaping rule frozen by W002-RCP-005. Every INV ends with exactly one final LF, contains no trailing spaces, and contains no blank physical lines. The exact V1 Inventory serialization order is: INVENTORY_VERSION INVENTORY_UTC WORK_ORDER_FILENAME SUITCASE ENTRY_COUNT for each regular-file entry in deterministic ascending exact-filename UTF-8 byte order, one contiguous indexed triplet: FILE_<INDEX> , FILE_<INDEX>_BYTE_LENGTH , FILE_<INDEX>_LAST_MODIFIED_UTC DIRECTORY_COUNT exactly DIRECTORY_COUNT directory-name records using contiguous indexed keys DIRECTORY_<INDEX> , ordered by ascending exact-directory-name UTF-8 bytes. INVENTORY_VERSION is the unquoted integer 1 for this contract. WORK_ORDER_FILENAME , SUITCASE , each FILE_<INDEX> filename, and each DIRECTORY_<INDEX> name use the common double-quoted UTF-8 text serialization. FILE_<INDEX>_BYTE_LENGTH is the exact non-negative ungrouped ASCII base-10 byte length. FILE_<INDEX>_LAST_MODIFIED_UTC is either the exact canonical UTC millisecond token governed by W002-INV-003 or the unquoted governed absence token NOT_AVAILABLE . Indexed suffixes are one-based decimal with a minimum width of three digits and no maximum width: 001 through 999 are zero-padded and 1000 onward uses the full ungrouped decimal form. When ENTRY_COUNT or DIRECTORY_COUNT is zero, no indexed lines for that list appear. ENTRY_COUNT remains the regular-file count. Directory records contain the exact immediate child directory name only and do not imply recursive inspection or a computed directory size. Filename and directory-name representations remain unambiguous even when a name contains whitespace, quotes, or delimiter-like characters because the common quote-doubling rule applies. P3-10 inventory timestamp binding: INVENTORY_UTC must equal the exact canonical UTC token embedded in the final governed __DS__INV__<UTC>__<uuid-v4>.txt filename, just as RECEIPT_UTC is bound to the governed Receipt filename UTC. The INV body and filename therefore cannot claim different capture times.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-007,The current inventory describes the pre-publication Suitcase state and excludes itself,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,Data Sculptor must enumerate and fix the inventory snapshot before publishing the new INV artifact. The INV artifact being created is therefore not one of its own listed entries. Any older INV artifact that already existed at snapshot time is an ordinary Suitcase file and is included like any other file. This pre-publication rule prevents recursive self-reference while preserving an accurate snapshot of the state that existed immediately before the new inventory evidence was added.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-008,"Help describes INVENTORY as a quick continuity aid, not byte-level proof",W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"Help must explain that an INV snapshot is useful for ordinary closeout and later orientation: it can reveal additions, removals, renames, size changes, or last-modified changes when snapshots or current metadata are compared. For an unexpected cross-session source problem, Help may direct the analyst to the relevant source entry in an earlier INV and ask whether its filename, exact byte length, or last-modified metadata differs. Help must also state that unchanged filename/size/last-modified metadata does not prove that file contents or row order are identical. When stronger assurance is warranted because files may change unexpectedly, Help may recommend the explicit later/deeper content-fingerprinting workflow; INVENTORY itself must never imply forensic or cryptographic assurance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-001,Large-file inventory acceptance proves metadata-only behavior,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"An acceptance fixture must place at least one multi-gigabyte file plus several small files in the authorized Suitcase, execute INVENTORY , and prove that the resulting INV records the correct filename, exact byte length, and last-modified metadata without reading the multi-gigabyte file contents. Evidence must demonstrate that inventory runtime and memory do not scale with the aggregate bytes of the listed files in the way a fingerprinting pass would. P3-10 metadata determinism: acceptance must include at least one file with usable host last-modified metadata and one test double/fixture in which the last-modified value fails the governed availability test. The first must serialize the exact canonical UTC millisecond value; the second must serialize exactly NOT_AVAILABLE . The accepted INV must also prove that INVENTORY_UTC exactly matches the UTC token in its final INV filename. Day 060 H-01 byte oracle: acceptance must include at least one byte-exact INV golden fixture using the complete W002-INV-006 key order, indexed suffix rule, quoted-text escaping rule, UTF-8/no-BOM physical form, LF-only line endings, and exactly one final LF. It must include at least two file records so deterministic filename ordering is observable, including one NOT_AVAILABLE last-modified value, and at least one directory record. Day 060 H-09 reachable-Suitcase INV golden fixture The byte-exact INV golden fixture used for WASM-002 review must depict a Suitcase state that could actually execute INVENTORY under the current contract rather than an isolated impossible file list. At minimum, immediately before the Inventory Run begins, the fixture Suitcase contains: one valid current Suitcase Validation Certificate ( CER ) authorizing the root; one structurally valid current WKO registry MAP; the exact saved immutable INVENTORY WKO referenced by WORK_ORDER_FILENAME , registered as runnable by that current WKO MAP; and the ordinary analyst files used to demonstrate inventory metadata, including the controlled last-modified-available and NOT_AVAILABLE cases. The INV snapshot is taken before publication of the new INV artifact and before its Receipt publication. Therefore the INV being created and the Receipt for that Run do not appear as pre-existing entries in their own inventory snapshot. For the retained minimal review fixture, the regular-file ENTRY_COUNT and indexed records must include the CER, current WKO MAP, exact INVENTORY WKO, and the two ordinary sample files, for a total of five regular-file rows, serialized in ascending exact-filename UTF-8 byte order. A later implementation fixture may use different exact governed filenames/UUIDs while preserving the same reachable-state requirement and deterministic ordering.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-002,Inventory snapshot membership and self-exclusion acceptance,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"An acceptance fixture must include ordinary analyst files, existing governed __DS__ artifacts, and at least one older INV artifact. The new inventory must include every qualifying pre-existing root file in deterministic order, include the older INV, and exclude only the newly generated INV because it did not exist in the fixed pre-publication snapshot. Adding an unrelated PDF or ZIP before a later inventory must appear as an added inventory entry and must not be treated as an analytical error.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-003,Inventory does not overclaim unchanged contents,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"Acceptance documentation and Help fixtures must demonstrate the limitation of metadata-only continuity. A case in which a file's bytes are changed while the observed filename, byte length, and last-modified metadata are preserved or restored must not be described as detectable by INVENTORY alone. The product must direct the analyst toward stronger explicit fingerprint evidence when byte-level assurance is required.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-016,Work Order filenames use the governed immutable identity grammar,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When Data Sculptor saves a new Work Order as a WKO, it shall assign the physical TXT filename. The analyst chooses the validated Suitcase but is not asked to choose or edit the WKO filename. The exact WKO filename shape is __DS__WKO__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt , using UTC at millisecond precision with exactly three millisecond digits and a canonical lowercase hyphenated UUID v4. UTC precedes UUID. If the generated name collides with an existing artifact, PB-STOR-011 governs UUID regeneration and safe retry. The saved WKO thereafter retains that physical identity and remains immutable under W002-STOR-017.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-017,Saved Work Orders are immutable artifacts,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"After a Work Order TXT artifact is saved, Data Sculptor shall not edit, overwrite, or rename that saved Work Order in place. Changing analytical instructions requires saving a new Work Order artifact with a new governed physical identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018,Work Order alias is immutable WKO content and governed MAP metadata,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A human-facing Work Order name is required immutable Work Order content for every executable/saved WASM-002 WKO, not separately editable browser metadata. The canonical declaration is WORK ORDER AS ""<alias>"" under W002-STEPS-001.1. The quoted alias must be non-empty UTF-8 text and may contain spaces and ordinary phrase punctuation subject to the governed string-literal rules. After the WKO TXT artifact is saved, Data Sculptor shall not edit the alias in place. Changing the alias, analytical instructions, or comments means creating and saving a new immutable WKO with a new governed physical identity. The physical WKO filename/UUID remains execution identity; the alias is human-facing metadata for display and governed name resolution. The browser must not maintain a separate mutable Description field or hidden description store. The alias declared by the WKO is also represented in the current governed WKO MAP under W002-STOR-018.1 through W002-STOR-018.4.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.1,The existing MAP class includes a distinct WKO alias-registry profile,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Revision BB does not add a new semantic artifact class. The existing MAP class has two explicitly distinguished governed profiles: Store MAP — the existing exact eight-column Store/RID/COL snapshot governed by W002-STOR-019 through W002-STOR-019.12; WKO MAP — a complete immutable snapshot that maps saved Work Order aliases and lifecycle status to exact immutable WKO filenames. Profile classification is determined by the exact CSV header before profile-specific validation. A valid WKO MAP must never be treated as an eligible Store MAP, and a Store MAP must never be treated as a WKO alias registry. Both remain visible flat-Suitcase MAP artifacts under the canonical immutable filename grammar.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.2,WKO MAP schema and serialization are exact and deterministic,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical WKO MAP is UTF-8 CSV without BOM, using LF record termination, with exactly this three-field header: wko_status,wko_alias,wko_filename Each row identifies one immutable governed WKO represented in that registry snapshot. wko_status is exactly CURRENT or DEPRECATED . wko_alias is the exact mandatory non-empty alias declared by that WKO's WORK ORDER AS clause. wko_filename is the exact governed physical WKO filename. Rows are written deterministically by ascending exact UTF-8 byte order of wko_filename . Duplicate wko_filename rows are invalid. Standard governed CSV quoting applies. For any exact wko_alias value, at most one row may have wko_status=CURRENT ; zero or more older rows for that same alias may have wko_status=DEPRECATED . Alias resolution uses the CURRENT row only. A WKO represented by a DEPRECATED row remains immutable historical evidence and is not renamed, rewritten, or deleted merely because its alias target was superseded. A WKO MAP containing more than one CURRENT row for the same exact alias is structurally invalid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.3,Saving a WKO and publishing its WKO MAP binding is one governed save transaction,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Saving a new immutable WKO begins from the current structurally valid WKO MAP in the Suitcase, or an empty WKO registry if no structurally valid WKO MAP exists. Data Sculptor validates the draft, including its mandatory non-empty WORK ORDER AS alias and comment syntax, and checks the governed alias/lifecycle constraints before commit. F-02 alias-lifecycle decision: if no CURRENT row in the predecessor WKO MAP uses the new WKO's exact alias, the successor registry adds the new WKO as CURRENT . If exactly one CURRENT row already owns that exact alias, Data Sculptor must present exactly two analyst choices before registry commit: Replace alias target or Cancel . Replace alias target constructs the successor WKO MAP by changing the former owner's row to DEPRECATED and adding the newly saved WKO as the sole CURRENT row for that alias; any older DEPRECATED rows remain unchanged. Cancel leaves the predecessor WKO MAP authoritative and does not commit the pending WKO/WKO-MAP pair as a registry update. Data Sculptor must not silently replace the alias target, auto-suffix the alias, or choose between competing owners. A predecessor WKO MAP with more than one CURRENT row for the same alias is structurally invalid under W002-STOR-018.2 and cannot be used as save authority. The former CURRENT WKO and every prior WKO MAP remain byte-for-byte immutable after replacement. Supersession changes only the lifecycle metadata represented in the newly published successor WKO MAP; it does not edit, rename, delete, or rewrite the historical WKO artifact. F-14 WKO publication predicate: the new immutable Work Order is first written under the W002-STOR-023.1 SCR identity using the UTC, UUID and .txt extension intended for its final WKO identity. The complete candidate is closed, reopened and validated as a saved WKO: required common preamble, exactly one non-whitespace WORK ORDER AS alias, governed lexical/comment rules, and complete parse under exactly one current WASM-002 executable operation grammar. Only then may the candidate be renamed from SCR to WKO . Save-time current-registry, alias-lifecycle and lifecycle gates remain transaction preconditions. A valid promoted WKO is not yet alias-registry authority; the successor WKO MAP promotion remains the save-transaction commit point. The WKO is persisted as a new immutable governed WKO artifact and the complete successor WKO MAP is constructed under SCR , closed, reopened, and validated for WKO MAP structural validity : exact profile/schema, exact governed serialization, filename/profile rules, lifecycle-row constraints, and internal row constraints. Whether every referenced physical WKO file is presently visible is a separate registry-health/publication check and is not part of WKO MAP structural validity. For an ordinary successful save transaction, every WKO referenced by the successor registry must be present at publication. The successor WKO MAP is promoted to MAP last; that successful MAP promotion is the alias-registry commit point for the save transaction. The WKO and successor WKO MAP created by one successful save transaction use one shared canonical transaction UTC while retaining distinct UUIDs. If successor WKO-MAP structural validation, referenced-file publication checking, or publication itself fails, the save must not be represented as a successfully committed alias-registry update. Data Sculptor must roll back the new WKO out of committed WKO state where safely possible or retain visible non-authoritative SCR failure evidence and report the failure through Help. F-02 repair-only bootstrap and stale-registry Save boundary When the current WKO registry is repair-required under W002-STOR-018.4, Data Sculptor may save one ordinary visible immutable WKO whose sole semantic operation is exactly REPAIR WORK ORDER REGISTRY . That saved repair-only WKO may Run by its exact physical WKO filename even though it is not yet represented in the current WKO MAP. The WKO must be structurally valid under the predicate below, must contain exactly one mandatory non-empty WORK ORDER AS , and must contain exactly the governed registry-repair operation and no second operation. The exception does not grant alias-based Run authority. The repair WKO is invoked only by exact physical WKO filename. No other visible but unregistered WKO gains Run eligibility from this exception. The exception ends once registry repair successfully publishes the successor WKO MAP. This is the sole WASM-002 bypass of ordinary current-registry membership for Run eligibility. Because the registry is already stale, Save of the repair-only WKO does not claim that the WKO has been registered, does not commit an ordinary successor WKO MAP, and does not represent the stale registry as healthy. The new immutable WKO remains visibly unregistered until the repair operation successfully publishes the successor WKO MAP containing its row. Save does not silently perform registry repair. F-02 governed WKO structural-validity predicate A visible WKO is structurally valid for registry purposes only when all of the following hold: it is a regular root-level Suitcase file; its physical filename conforms exactly to the governed WKO filename grammar; its bytes are valid UTF-8; LF and CRLF physical line endings are accepted; a lone CR line ending refuses; its content parses completely under exactly one defined WASM-002 executable Work Order grammar; it contains exactly one mandatory non-empty WORK ORDER AS clause; its required common and operation-specific structural clauses are present in their governed order/cardinality; and unknown syntax or prohibited operation mixing causes invalidity/refusal. Structural validity is not runtime success. A structurally valid WKO remains a valid governed artifact even when a runtime precondition is currently false, such as a referenced source file being absent. Runtime preconditions are checked at Run. P3-10 repair-bootstrap timing: during REPAIR WORK ORDER REGISTRY , the saved repair-only WKO participates in the bounded discovery performed by that repair run. It is not first “discovered after success.” Its governed registration becomes durable only when the complete successor WKO MAP containing that WKO row is successfully committed. Discovery during the run and registration in the committed successor registry are distinct events. P2-03 WKO-registry chronology guard: before a save or registry-repair transaction publishes a successor WKO MAP, Data Sculptor establishes the truthful observed transaction UTC and compares it with the chronology predecessor defined by W002-STOR-018.4. The observed UTC must be strictly greater. Equal or earlier UTC refuses before the new WKO/WKO-MAP pair is committed; Data Sculptor must not fabricate a later timestamp, silently wait/retry, skip the predecessor, or select an older registry merely to make publication succeed. F-13 single-writer pre-commit guard: immediately before the successor WKO MAP promotion that would commit the alias-registry update, Data Sculptor re-resolves the current WKO-registry authority and compares the relevant governing state with the state from which this transaction was derived. If another writing context or external filesystem action has changed that relevant authority, the transaction refuses publication. It must not overwrite the newer registry, silently rebase the pending save, or choose an older registry to make the commit succeed. The existing rollback / attributable SCR recovery-evidence rules apply to any WKO or candidate bytes already produced. If the save later refuses and an SCR candidate or other attributable staged evidence cannot be safely removed/restored, W002-STOR-023.1 governs retained SCR evidence and its non-authority boundary; WASM-002 does not emit RCV. An unregistered final WKO left by a failure is a valid immutable WKO artifact but does not become current registry authority merely by existing; the WKO MAP remains authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.4,Current WKO MAP selection is based on structural validity; missing referenced WKOs make the registry repair-required,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"WKO MAP structural validity is distinct from registry health. A WKO MAP is structurally valid when the MAP artifact itself satisfies the governed WKO MAP profile/schema, serialization, filename/profile rules, lifecycle-row constraints, and internal row constraints. The present existence of every physical WKO file named by its rows is not part of WKO MAP structural validity. Only structurally valid WKO MAP artifacts participate in current-registry selection. Among structurally valid WKO MAPs, the one with the greatest canonical UTC millisecond timestamp is the current WKO MAP snapshot and therefore the current governed Work Order alias registry. If two or more structurally valid WKO MAPs share that greatest timestamp, current-registry selection must refuse rather than break the tie by UUID, discovery order, filesystem modified time, or directory order. Registry-snapshot authority is distinct from alias-target status inside that snapshot. After the current WKO MAP snapshot is selected, an alias resolves only to its exact row whose wko_status is CURRENT . Rows marked DEPRECATED remain visible historical registry evidence but are not alias-resolution targets. The registry must never use the greatest WKO filename UTC, filesystem modified time, or discovery order to choose between rows for an alias. More than one CURRENT row for the same exact alias makes that WKO MAP structurally invalid under W002-STOR-018.2. If a newer WKO MAP artifact is structurally malformed, it never becomes current. Data Sculptor uses the greatest earlier structurally valid WKO MAP, if one exists, and reports the malformed newer artifact through Help/evidence surfaces. A malformed newer WKO MAP does not itself make the selected earlier registry repair-required. The current WKO registry is repair-required exactly when the current structurally valid WKO MAP contains one or more rows whose referenced physical WKO files are missing from the Suitcase. Such a MAP remains current ; Data Sculptor must not silently fall back to an older WKO MAP merely because a referenced WKO is missing. This preserves the latest registry authority while making the damage explicit and reachable through the governed REPAIR WORK ORDER REGISTRY path. F-02 deterministic registry reconciliation REPAIR WORK ORDER REGISTRY reconciles the current WKO MAP against visible WKO artifacts in the Suitcase and constructs one complete successor WKO MAP deterministically: Remove every row from the successor whose referenced physical WKO file is missing. A missing WKO is never reconstructed, inferred, copied from history, or replaced automatically by a deprecated WKO. Discover visible structurally valid WKOs that are absent from the current WKO MAP. If no surviving CURRENT row owns a discovered WKO's exact alias, register that discovered WKO as CURRENT . If a surviving CURRENT row already owns that exact alias, register the discovered WKO as DEPRECATED ; existing current authority is not silently displaced. If two or more previously unregistered structurally valid WKOs share the same alias and no surviving CURRENT owner exists, register all of those discovered WKOs as DEPRECATED . Data Sculptor must not choose a winner by UTC, filename, UUID, directory order, discovery order, or filesystem modified time. The repair WKO itself participates in the same discovery and registration process during the repair run. Its registration becomes durable only when the complete successor WKO MAP is committed. Predecessor WKO MAPs and surviving WKO files remain immutable historical evidence. Successor rows remain serialized in ascending exact UTF-8 byte order of wko_filename under W002-STOR-018.2. Day 060 H-10 / BM-07 registry-repair change-set counts The registry-repair operation distinguishes the successor registry state from the change set produced by this repair Run . The Receipt's REGISTERED_CURRENT_* and REGISTERED_DEPRECATED_* fields describe only the latter. REGISTERED_CURRENT_COUNT is the exact number of previously unregistered structurally valid WKO files newly added by this repair Run with wko_status=CURRENT . REGISTERED_CURRENT_WKO_<INDEX>_FILENAME lists exactly those newly registered CURRENT WKOs, ordered by ascending exact UTF-8 filename bytes. REGISTERED_DEPRECATED_COUNT is the exact number of previously unregistered structurally valid WKO files newly added by this repair Run with wko_status=DEPRECATED . REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME lists exactly those newly registered DEPRECATED WKOs, ordered by ascending exact UTF-8 filename bytes. Surviving rows that were already present in the base WKO MAP are not counted in either REGISTERED_* total, even though they appear in the successor WKO MAP. Rows removed because their referenced WKO is missing are represented only by REMOVED_STALE_ROW_COUNT and the corresponding stale-WKO filename list; they are not also reflected in either registered count. The bootstrap repair WKO participates exactly like any other newly discovered structurally valid unregistered WKO. If the repair commits it, that exact WKO must appear in one and only one of the two registered filename lists according to the ordinary alias-ownership rules. These counts therefore answer “what did this repair register?” rather than “how many CURRENT/DEPRECATED rows exist in the resulting registry?”. F-02 Run eligibility and alias authority Run by human-facing alias resolves only to the sole CURRENT WKO for that alias. A registered CURRENT WKO may Run by exact physical WKO filename, subject to ordinary runtime preconditions. A registered DEPRECATED WKO may also Run by exact physical WKO filename, subject to ordinary runtime preconditions, to support deliberate historical reproduction. An unregistered WKO may not Run merely because its file is visible, except for the single bounded repair-only bootstrap in W002-STOR-018.3. The browser may use the current structurally valid WKO MAP to show human-facing Work Order aliases together with read-only CURRENT / DEPRECATED lifecycle state while keeping exact physical WKO filenames visible/inspectable. Future Work Order composition may use the same registry to resolve a non-empty alias to exactly one immutable WKO artifact through its sole CURRENT row. This requirement does not pull deferred Work Order invocation/orchestration grammar into WASM-002; it establishes the governed alias-registry selection, lifecycle, and repair boundary that later composition can depend on. F-08 REPAIR WORK ORDER REGISTRY Work Order structure: SUITCASE: .
WORK ORDER AS ""Repair Work Order Registry""
REPAIR WORK ORDER REGISTRY After the common preamble, REPAIR WORK ORDER REGISTRY is the sole semantic operation clause and is terminal. It takes no analyst-supplied SOURCE , Store MAP , alias-mutation list, column selector, conversion source, or catalog clause. Its bounded unregistered-repair bootstrap remains governed by W002-STOR-018.3. The DS-STEPS phrase is distinct from the Receipt operation token REPAIR_WORK_ORDER_REGISTRY . P2-03 chronology predecessor: for any WKO-registry successor publication, the chronology predecessor is the unique current structurally valid WKO MAP immediately before that publication transaction. It is the MAP selected by the current-registry rule above, not an older registry used for inspection and not a filesystem-modified-time surrogate. If no structurally valid WKO MAP exists and the operation is legitimately establishing the first governed registry state, there is no predecessor UTC. Future-dated current WKO MAP: a structurally valid current WKO MAP whose governed UTC is later than truthful observed host UTC remains the current registry; the timestamp conflict does not by itself make the MAP malformed or repair-required. Successor WKO-MAP publication is blocked until the monotonic UTC precondition can be satisfied. Help must identify the exact blocking WKO MAP and explain the analyst-owned exits: correct an incorrect host clock; wait/rerun after truthful time advances beyond the predecessor; or, when the analyst deliberately determines that the active future-dated WKO MAP should no longer govern the Suitcase, move that exact MAP out of the active Suitcase root and reopen/rescan. That filesystem action is not a Data Sculptor repair operation. It may expose an older structurally valid WKO MAP as current, and restoring the moved future-dated MAP to the active Suitcase may make it current again under the ordinary greatest-UTC rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019,Store state is preserved as visible immutable MAP history,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each valid WASM-002 MAP is one complete immutable Store snapshot in the same flat Suitcase. Store state is not stored in hidden browser persistence and is not represented by a mutable well-known singleton. Each successful Store-establishing materialization or later governed Store-metadata/materialized-column update publishes a new immutable MAP under the canonical __DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv identity grammar. Earlier MAP artifacts remain visible history and are not overwritten or deleted merely because a newer Store state is created. Day 057 CAT reconciliation: the one-Store-per-MAP invariant is unchanged. A collection of independently MAP-governed Stores may additionally be summarized by a governed CAT Store Catalog for collection-level discovery and orientation. CAT does not govern Store semantics, lineage, health, repair, inheritance, or current-MAP selection. MAP remains authoritative for each Store.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.1,A Work Order may explicitly select at most one Store MAP,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each governed Work Order may explicitly identify at most one valid immutable Store MAP as its Store/inheritance base. If more than one MAP is explicitly specified, Data Sculptor must refuse before Store resolution, alias resolution, materialization, or mutation. An explicitly named valid MAP binds the run to exactly the Store identified by that MAP's rid_filename and overrides automatic Store-MAP discovery even when newer MAPs for that Store or other Stores exist.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.2,"Without an explicit MAP, materialization performs Store-aware MAP inheritance",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If a materializing Work Order does not explicitly identify a MAP, Data Sculptor must compare the exact Work Order SOURCE filename with the one common exact source_filename carried by every row of each routable Store lineage's structurally valid Store MAP. That common source_filename is the Store lineage's source identity for WASM-002 routing. The redundant ninth Store-source field from the superseded profile is not part of the canonical Store MAP. P3-07 routing term: for automatic source routing, a routable Store lineage is a Store lineage for which at least one structurally valid Store MAP exists, regardless of whether the lineage currently evaluates VALID , DEGRADED , or INVALID . Routing discovery must use this term rather than the ambiguous word eligible . Store health is evaluated only after the lineage has been discovered. If no routable Store lineage exists for the exact source filename, Data Sculptor may establish a new Store with a new RID and first Store MAP only if the active Suitcase contains no structurally malformed Store-MAP-class artifact . If exactly one routable Store lineage exists, Data Sculptor routes to that lineage. If its current state permits materialization, the current governed Store MAP is the inheritance base; if its current state is DEGRADED or INVALID , ordinary materialization refuses under the damaged-lineage rules below. If more than one distinct routable Store lineage exists for the same exact source filename, automatic inheritance must refuse rather than guess which Store the analyst intended. The analyst must explicitly select one permitted MAP. All-Store-MAPs-damaged guard: if exact- SOURCE routing finds no routable Store lineage but one or more structurally malformed Store-MAP-class artifacts are present in the active Suitcase, ordinary materialization must refuse before creating a new Store or RID. Data Sculptor must not infer that the absence of a structurally valid Store MAP proves that no prior Store lineage existed. Help must identify the malformed Store MAP artifact or artifacts that caused this guard. A damaged MAP therefore cannot silently turn Store damage into permission to create a replacement lineage. Store lineages are distinguished by their governed lineage identity. Current-MAP selection and Store-health evaluation are separate governed questions under this requirement and W002-STOR-019.10. If two or more structurally valid current MAP candidates for the one routed Store share the greatest canonical UTC millisecond timestamp, automatic inheritance must refuse rather than infer chronology from UUID, directory order, filesystem modified time, or discovery order. F-03 canonical evaluated Store-health states Store health is evaluated from the current structurally valid Store MAP and the presently visible governed artifacts it references, using the applicable validation tier in W002-STOR-019.10. WASM-002 has exactly three evaluated Store-health states: VALID — the current Store MAP is structurally valid; the referenced RID is valid; and every mapped non-RID COL is valid. DEGRADED — the current Store MAP is structurally valid; the referenced RID is valid; and one or more mapped non-RID COL artifacts are missing or invalid. INVALID — the current Store MAP is structurally valid, but its referenced RID is missing or invalid. There is no fourth ABANDONED Store-health status in WASM-002. F-03 status is evaluated, not persisted VALID , DEGRADED , and INVALID are evaluated states. WASM-002 does not write or maintain a mutable persisted Store-status flag. While a Store evaluates INVALID , Data Sculptor exposes no governed Store-recovery operation for that Store and never regenerates, substitutes, or infers a replacement RID. If the exact governed RID physical identity becomes visible again through analyst-owned external restoration and passes the validation tier required by the next operation, the Store is re-evaluated from the visible governed artifacts and may become VALID or DEGRADED . That is re-evaluation, not RID recovery by Data Sculptor. F-03 strict DEGRADED operation gate When a Store evaluates DEGRADED , REPAIR MAP is the only enabled Store mutation operation for that lineage . ordinary materialization into that Store refuses; extension with new columns refuses; alias mutation refuses; transformations and other Store mutations refuse; read-only Help, Inventory, status/orientation surfaces, CAT orientation, and evidence inspection remain available subject to their own contracts. F-03 no damaged-lineage fork If exact SOURCE routing identifies a lineage whose current Store evaluates DEGRADED , ordinary materialization refuses and directs the analyst to the governed REPAIR MAP path. If the routed Store evaluates INVALID , ordinary materialization refuses and WASM-002 provides no RID-recovery path. Neither condition permits Data Sculptor to treat the source as unseen or establish a replacement Store with a new RID for that routed lineage. Damaged-lineage routing: exact SOURCE routing must not treat a known damaged lineage as unseen merely because its current Store state cannot accept ordinary materialization. If routing identifies a DEGRADED or INVALID lineage, ordinary materialization refuses rather than silently creating a replacement Store for that same routed lineage. Help duty for an all-COLs-broken DEGRADED lineage: when the current structurally valid Store MAP references a valid RID but every mapped non-RID COL is missing or invalid, REPAIR MAP cannot publish a zero-COL successor and must refuse. Help must identify the exact blocked Store lineage and current MAP, then explain these analyst-owned exits: (1) externally restore at least one governed COL artifact under its original physical filename; Data Sculptor then applies the governed validation tier required by the next operation before the artifact can re-enter use, so Store health can be re-evaluated and REPAIR MAP may become available; (2) rename the analyst-owned source and materialize the renamed source to deliberately begin a new Store lineage with a new RID, without repairing, replacing, or erasing the damaged lineage; or (3) retire the damaged lineage from active Suitcase routing by moving all Store MAP artifacts belonging to that lineage out of the Suitcase root. Help must warn that moving only the latest MAP is insufficient because an older structurally valid MAP could otherwise become current. Help duty for an INVALID lineage: when the current structurally valid Store MAP references a missing or invalid RID, Help must identify the exact blocked Store lineage and current MAP, state that WASM-002 does not silently regenerate or substitute a RID as part of ordinary materialization, and explain these analyst-owned exits: (1) externally restore a governed RID artifact under its original physical filename; Data Sculptor then applies the governed validation tier required by the next operation before the artifact can re-enter use, so Store health can be re-evaluated; (2) rename the analyst-owned source and materialize the renamed source to deliberately begin a new Store lineage with a new RID while leaving the damaged lineage untouched; or (3) retire the damaged lineage from active Suitcase routing by moving all Store MAP artifacts belonging to that lineage out of the Suitcase root, again warning that moving only the latest MAP is insufficient. Renaming the source and retiring a lineage are distinct analyst choices. Renaming preserves the damaged lineage in the Suitcase and creates a separate lineage under a different source identity. Moving all lineage MAPs out removes that lineage from active routing while preserving the moved artifacts wherever the analyst chooses to keep them. These are analyst filesystem actions, not new Data Sculptor recovery operations. Assurance boundary: exact source-filename matching in this rule is a Store-routing/orientation mechanism, not proof that an analyst-owned source has identical bytes or row order across separate sessions. Ordinary WASM-002 materialization must not silently represent that filename equality as cryptographic continuity. P3-08 CVT source-identity boundary: a governed CVT is a new immutable source artifact whose Store-routing source identity is its exact physical CVT filename. Two different CVT filenames are different source identities even when both conversions began from analyst-owned files having the same original filename. WASM-002 does not carry the analyst-owned pre-conversion filename forward as hidden Store-lineage identity and does not infer continuity between separate CVT artifacts. First materialization of a CVT therefore establishes or routes only by that exact CVT filename under the normal rules above. P2-03 current Store-MAP chronology: within one routable Store lineage, the current structurally valid Store MAP is the unique structurally valid MAP carrying the greatest canonical UTC millisecond timestamp. If two or more structurally valid MAPs share that greatest timestamp, current authority is ambiguous and selection refuses rather than using UUID or discovery order. This current MAP is also the lineage's chronology predecessor for any new successor publication, even when the operation explicitly derives its requested new state from an older historical MAP. F-15 exact-source comparison and routing domain: the Work Order SOURCE value and each Store MAP's common source_filename are compared by exact Unicode scalar-value sequence under PB-STOR-010, with no case folding or Unicode normalization. Automatic routing compares only routable Store lineages whose structurally valid Store MAPs participate in that exact-source routing decision. Unrelated Suitcase files, non-Store artifact classes, filesystem enumeration order, and arrival order are outside the routing comparison domain and cannot create or remove a source match.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.3,"Any valid historical Store MAP may be selected explicitly with MAP ""<filename>""",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A governed Store-aware Work Order may explicitly identify any one structurally valid immutable Store MAP present in the Suitcase, including an older snapshot when newer MAPs for that Store also exist. The canonical clause is: MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv"" The quoted value must be the exact physical filename of one valid Store MAP. A WKO MAP profile, missing file, malformed MAP, or other MAP profile is invalid for this clause. Data Sculptor uses exactly the named Store MAP rather than silently substituting a later one. For materialization, SOURCE ""..."" remains required to identify the source file being read; the optional MAP ""..."" clause occurs immediately after SOURCE and before KEEP , overrides automatic Store-MAP inheritance, and supplies the exact Store-state base. The Work Order's exact SOURCE filename must match the selected lineage's governed source identity under the frozen source/Store compatibility rules or validation refuses. For an alias-only UPDATE ALIASES Work Order, MAP ""..."" may itself be the Store-state selector and no source-data read is required. Historical-MAP health gate. Explicit selection of a current or historical Store MAP never bypasses current Store-lineage health. The selected lineage must currently evaluate VALID , and every RID/COL binding referenced by the named MAP must currently be present and valid. If either condition fails, Data Sculptor refuses the operation. An older MAP cannot be used to hide present lineage damage. The same rule applies when UPDATE ALIASES uses a historical Store MAP as its base. Once selected, the exact MAP identity, Store RID binding, Store alias, RID alias, and materialized-column mapping state remain fixed for the governed run. The MAP filename is execution input, not a friendly alias. P2-03 base-versus-predecessor distinction: an explicitly selected historical MAP is the operation's base MAP —the Store snapshot from which requested new state is derived. It does not become the chronology predecessor merely because it was selected. If the operation publishes a new Store MAP, the chronology predecessor remains the Store lineage's current structurally valid MAP immediately before publication. The new transaction UTC must be strictly greater than that current MAP UTC. This preserves one chronological MAP history rather than creating a branch from the historical base. F-21 current-state consequence: merely selecting or validating a historical Store MAP does not change Store authority. If the governed run refuses or otherwise publishes no successor Store MAP, the lineage's pre-run current MAP remains current. If the run successfully publishes a successor derived from a historical base, that new MAP enters the same single chronological history and ordinary greatest-governed-UTC current-state selection applies. Because successor publication already requires a truthful transaction UTC strictly greater than the pre-publication chronology predecessor, the successfully published successor becomes current. The explicitly selected historical base and the formerly current MAP both remain immutable historical evidence. This behavior is deliberate state derivation, not a branch, rollback-in-place, overwrite, or mutation of prior MAPs. The operation base records which Store snapshot supplied the requested starting state ; chronology records when the new governed state was published . Those are distinct facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.4,"Store MAPs are complete snapshots, not delta logs",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each valid Store MAP represents one complete usable Store metadata and materialized-column mapping state for that version. It must not require replaying a chain of earlier MAP files merely to reconstruct the Store's current RID binding, aliases, or materialized-column mappings. A newer MAP created from an inherited older MAP contains the complete resulting Store snapshot after applying the governed Work Order's successful changes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.5,Materialization or governed Store metadata mutation emits one successor MAP,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When a governed Work Order materializes one or more columns or requests governed Store/RID/COL alias changes, Data Sculptor begins from the applicable governed Store-state base. Ordinary materialization uses the explicitly selected MAP or Store-aware automatic inheritance under W002-STOR-019.2. A new Store begins from newly established Store/RID metadata plus an empty materialized-column mapping set before requested materialization is applied. All successful updates in that Work Order are applied to one in-memory complete Store snapshot. The complete deterministic successor-MAP bytes must first be written under a governed SCR candidate identity, closed successfully, reopened, and fully validated while still an SCR candidate. Only a complete validated candidate may be promoted by host rename into one new immutable MAP artifact. The inherited MAP remains unchanged. The successful SCR -to- MAP rename is the Store-state commit point. A failed run must not create a valid successor MAP; a malformed, incomplete, or unpromoted MAP candidate remains visible non-authoritative SCR evidence rather than Store state. RID reconstruction/replacement is not a WASM-002 Store-mutation path. P2-03 successor publication precondition: before any final RID/COL/MAP promotion for a successor Store-state transaction, Data Sculptor identifies the lineage's chronology predecessor and establishes one truthful observed host transaction UTC. For an existing lineage, that UTC must be strictly greater than the current structurally valid Store MAP UTC, regardless of whether the Work Order's base MAP is current or historical. Equal or earlier observed UTC refuses publication; no artificial +1 ms , sleep-and-retry loop, UUID tie-break, older-predecessor fallback, or branch chronology is permitted. The chronology predecessor remains current and unchanged. Future-dated current Store MAP: a structurally valid current MAP with a governed UTC later than truthful observed host UTC is a clock-order conflict, not by itself Store corruption. It remains current and successor publication is blocked. Help must identify the exact blocking MAP and explain the analyst-owned exits: correct an incorrect host clock; wait/rerun after truthful time advances beyond the predecessor; or deliberately move that exact future-dated current Store MAP out of the active Suitcase root and reopen/rescan. Moving it is an analyst filesystem action, not a governed Data Sculptor mutation. An older structurally valid MAP may then become current; returning the future-dated MAP may restore its authority under the ordinary greatest-UTC rule. F-13 single-writer pre-commit guard: immediately before the final successor Store-MAP promotion, Data Sculptor re-resolves the relevant current Store authority and exact-source routing state on which the transaction depended. For an existing lineage, the current chronology predecessor must still be the authority against which the transaction was prepared; for a new-Store transaction, no newly established routable lineage may have appeared that changes the routing decision. If relevant governed state changed while the transaction was in flight, publication refuses. Data Sculptor must not overwrite the newer authority, silently rebase onto it, create a competing branch, or report success. Any RID/COL/candidate artifacts already produced are handled by the existing rollback / attributable recovery-evidence rules and do not become committed Store membership without the final valid MAP binding. F-21 historical-base publication rule: when the applicable Store-state base is a valid historical MAP rather than the pre-run current MAP, the complete successor snapshot is still derived from that explicitly selected base plus the current Work Order's requested changes. Publication does not silently merge later state from the formerly current MAP back into the successor. Therefore mappings or aliases introduced only after the selected historical base may be absent from the new successor when the requested operation does not recreate them. That is the deliberate consequence of using the historical base, not data loss caused by an implicit merge. The pre-run current MAP remains the chronology predecessor solely for monotonic publication ordering and stale-authority protection. Successful publication leaves both the historical base and the formerly current MAP byte-for-byte unchanged, publishes one new immutable successor MAP in the same lineage, and makes that successor current under the ordinary chronology rule. No branch identifier, hidden branch state, overwrite, in-place rollback, or automatic rebase is created.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.6,Store MAP CSV schema is exactly eight columns,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 Store MAP is a CSV whose header row is exactly: store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename Each data row describes one current logical materialized-column mapping: store_alias — current human-facing Store name; rid_filename — exact immutable governed RID artifact filename that physically anchors this Store lineage; rid_alias — current human-facing RID name; source_filename — exact visible source filename common to every row in this one-Store MAP and therefore the Store source identity; source_column_number — 1-based source-column ordinal; source_header — exact decoded CSV header value after governed parsing; alias — current human-facing COL name; and column_filename — exact physical governed COL artifact filename represented by the row. Every row in one valid Store MAP must carry the same exact rid_filename and the same exact source_filename . A MAP that mixes RID lineages or source filenames is invalid. The logical source-column key for COL alias continuity remains the exact triple (source_filename, source_column_number, source_header) . The Store is physically identified by the repeated exact rid_filename , not by mutable aliases. F-05/P2-01 reconciliation: the superseded redundant Store-source column is removed. One Store MAP represents exactly one Store lineage and exactly one source identity, so the common source_filename supplies the required source identity without a second Store-source field. P3-06 identity-evidence boundary: this eight-column MAP profile intentionally records governed physical filenames and mapping metadata, not per-artifact byte lengths, row counts, digests, or historical-content fingerprints. A MAP therefore cannot prove that a same-named RID or COL restored later is byte-for-byte identical to the earlier artifact. WASM-002 must not make that claim unless separate authoritative fingerprint evidence exists outside this MAP profile. P2-04 schema consequence: no byte-length, RID- N , digest, or per-artifact fingerprint columns are added to the eight-column Store MAP to close restoration validation. The MAP remains compact relationship/state metadata. Stronger byte-identity assurance remains the responsibility of explicit fingerprint evidence outside ordinary WASM-002 Store governance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.7,Source headers become default COL aliases on first materialization,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When a logical source column is materialized and its exact logical key does not already exist in the inherited Store MAP, its default COL alias is its operational column name . For an exact decoded source_header of at most 1,024 Unicode scalar values, the operational name is that exact header text. For an exact decoded source_header longer than 1,024 scalar values, the operational name begins as Column <LETTERS> from the column's 1-based physical source ordinal (for example Column A , Column Z , Column AA , through Column XFD ). The exact source_header remains unchanged in the Store MAP and physical COL header; the operational name exists only to provide a bounded human-facing/default-alias value. HEADER selection continues to match the exact decoded source header under W002-STEPS-002. If an oversized-header base fallback Column <LETTERS> would collide in the complete successor alias namespace, Data Sculptor deterministically tries Column <LETTERS> [<ordinal>] ; if that also collides, it appends -2 , -3 , and so on until the first available exact value is found. This is the only automatic alias-suffix rule in WASM-002. A short exact source-header default that is empty or collides still refuses unless the Work Order supplies an explicit valid alias; Data Sculptor must not suffix or rewrite it. If the same Work Order supplies an explicit alias for a newly materialized column, the explicit governed alias overrides the operational default and must pass the ordinary exact uniqueness/shadowing rules without automatic suffix repair. For a previously materialized COL, RESET COL ""<reference>"" ALIAS restores this same deterministic operational default from the exact recorded source_header and physical source ordinal. An oversized recorded header therefore restores its deterministic fallback/disambiguated operational name rather than inserting the potentially very long exact header into the alias field. A short empty/colliding source-header default still refuses rather than inventing a substitute.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.8,"Ordinary rematerialization preserves Store metadata, inherited RID, and inherited COL alias",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If a newly materialized column's exact logical key already exists in the inherited Store MAP, Data Sculptor must preserve that row's current COL alias unless the Work Order explicitly changes it. The successor MAP replaces only that logical row's column_filename with the newly created physical COL artifact filename. Ordinary rematerialization must preserve the inherited Store's exact common source_filename and rid_filename . It must not silently create a different Store, replace the Store RID, revert a user-facing Store/RID alias, or revert a COL alias to its source header. Every row in the successor MAP continues to carry that same common Store source_filename . WASM-002 has no executable operation that replaces rid_filename while preserving the same Store lineage. A different RID filename therefore cannot be introduced as ordinary successor-state continuity in this build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.9,Store MAP serialization is deterministic UTF-8 CSV,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Store MAP CSV files are encoded as UTF-8 without BOM and use LF ( 0x0A ) record termination. The exact eight-field header in W002-STOR-019.6 is written once as the first row. Fields use standard CSV quoting semantics: a field containing comma, double quote, CR, or LF is enclosed in double quotes, and embedded double quotes are doubled. No locale-dependent formatting is permitted. Every data row in one MAP must contain byte-for-byte identical values for store_alias , rid_filename , rid_alias , and source_filename . Mapping rows are written deterministically by ascending numeric source_column_number , then ascending UTF-8 byte order of source_header . Because one valid Store MAP has exactly one common source_filename , that field is not needed as a leading row-sort discriminator. Two rows with the same logical source-column key (source_filename, source_column_number, source_header) are invalid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.10,Only a complete validated Store MAP is eligible for inheritance,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A canonical MAP filename alone does not make a file a structurally valid Store MAP. For Store-MAP structural validity , the MAP artifact itself must be readable as complete UTF-8, have the exact eight-column schema, parse deterministically, satisfy Store-level consistency, lineage, deterministic row-order, mapping-key, and alias constraints, and carry structurally valid governed RID/COL filename bindings. The present health of the referenced RID/COL artifacts is a separate question and does not determine whether the MAP itself is structurally valid. A Store MAP remains part of governed Store history when its own bytes, schema, lineage facts, and deterministic structural rules are valid even if a referenced RID or COL later becomes missing or invalid. Referenced-artifact damage therefore does not make the current structurally valid Store MAP disappear and does not by itself cause fallback to an older MAP. F-03 current Store MAP selection Current-state selection is performed independently within one exact Store lineage. Only structurally valid Store MAP artifacts participate. Among those MAPs, the ordinary frozen chronology rule selects the unique structurally valid MAP with the greatest canonical UTC millisecond timestamp. A structurally malformed newer MAP is never current. If a newer canonical MAP artifact is structurally malformed, Data Sculptor uses the greatest earlier structurally valid Store MAP in that same lineage, if one exists, and reports the malformed newer artifact through governed Help/evidence surfaces. This fallback applies to structural MAP invalidity only. It does not apply merely because a structurally valid current MAP references a damaged RID or COL. If two or more structurally valid MAPs share the greatest canonical UTC millisecond timestamp, current authority is ambiguous and selection refuses rather than breaking the tie by UUID, discovery order, directory order, or filesystem modified time. P3-07 routing distinction: Store-MAP inheritance eligibility is stricter than lineage discovery. A Store lineage participates in exact- SOURCE routing when at least one Store MAP in that lineage is structurally valid, even if the current Store later evaluates DEGRADED or INVALID . Referenced RID/COL health is evaluated after routing and may cause refusal; it must not make an already discoverable lineage disappear. For successor publication, after the required RID/COL physical promotions have succeeded, Data Sculptor uses the already-established publication-transaction UTC and allocates a MAP-specific UUID before opening the complete deterministic MAP CSV under its governed SCR candidate identity. The SCR filename therefore already carries the exact UTC, UUID, and .csv extension intended for the final MAP identity. The candidate is closed successfully, reopened, and validated for bytes, schema, Store-level consistency, aliases, RID binding, COL bindings, deterministic row order, and all other MAP eligibility rules while it remains SCR . Only after that validation succeeds may Data Sculptor promote the candidate by host rename that changes only the three-letter semantic class token from SCR to MAP . The candidate bytes, UTC, UUID, and extension must remain unchanged across promotion. The successful rename is the publication/commit point. If validation or rename fails, no successor MAP becomes eligible/current; the candidate remains or is retained as visible non-authoritative SCR evidence. Store-aware automatic selection therefore continues to use the greatest earlier valid MAP in the same Store lineage, if one exists, while Help reports the failed candidate/publication rather than silently treating it as current state. P3-06 governed artifact-validation tiers. Store-health status and full content validity are distinct assurances. The following two tiers are normative for WASM-002: Tier 1 — Store-health structural validation. Used for routine Store status, source routing, historical-MAP health gates, inheritance decisions that do not consume analytical artifact contents, and alias-only maintenance. The selected Store MAP itself is fully parsed and structurally validated because it is the compact authority for the snapshot. A referenced RID passes Tier 1 only when the exact MAP-bound governed RID filename is present and readable, the bytes begin with exactly one UTF-8 BOM, the first logical record is a canonical N=<value> header, the final byte is LF, and the physical byte length equals the deterministic length implied by the canonical RID representation for that declared N . Tier 1 does not rescan every RID data record merely to perform routine status or alias work. A referenced COL passes Tier 1 only when the exact MAP-bound governed COL filename is present and readable, begins with exactly one UTF-8 BOM, exposes the canonical one-column CSV header whose decoded value exactly equals the MAP row's recorded source_header , and ends with LF. Tier 1 does not stream every COL value merely to establish routine Store health. Tier 2 — full artifact validation. Used whenever an operation actually consumes RID/COL contents, for complete validation of newly created candidates before commit, and by REPAIR MAP after the repair operation has been validly entered. A RID passes Tier 2 only when a full stream proves the canonical N=<value> header, exactly N data records, and exact ordered values 1..N . A COL passes Tier 2 only when a full stream proves canonical one-column CSV encoding/serialization, the exact expected header, and exactly N logical data records aligned to the Store RID. VALID , DEGRADED , and INVALID are Store-health states evaluated from the governed current snapshot using the required validation tier; they are not claims of cryptographic historical identity. When REPAIR MAP is validly invoked, it must perform Tier 2 validation of the RID and every mapped COL that would survive into the successor. The deterministic repair result removes exactly the mapped COL bindings that fail that Tier 2 check, subject to the separately frozen refusal when no mapped COL would remain. Two implementations presented with the same bytes must therefore identify the same repair set. External restoration boundary: a file placed back under an original governed RID/COL physical filename may re-enter use only when it passes the validation tier required by the operation. Filename equality plus governed validation is sufficient for operation eligibility under this WASM-002 boundary; it is not proof that the restored bytes are the historical original bytes. Stronger historical-byte identity requires separate authoritative fingerprint evidence. P3-10 terminology boundary: Store-state repair is REPAIR MAP . Work Order alias-registry repair is REPAIR WORK ORDER REGISTRY . These are distinct governed operations and the integrated specification must not describe a Store REPAIR MAP Work Order as a “registry-repair Work Order.” This corrects wording only; it does not change either operation's frozen semantics. F-08 / F-03 REPAIR MAP Work Order structure and target precondition: SUITCASE: .
WORK ORDER AS ""Repair Crime Store""
MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""
REPAIR MAP Exactly one MAP ""<filename>"" clause is mandatory. It names the exact physical filename of one structurally valid Store MAP. At Run time, that named MAP must be the current structurally valid Store MAP for exactly one lineage and the target Store must currently evaluate DEGRADED . A historical Store MAP, WKO MAP, missing MAP, malformed MAP, ambiguous equal-latest current state, MAP from an unsupported profile, or target Store that does not evaluate DEGRADED refuses. No SOURCE , Store/RID/COL alias selector or mutation, KEEP , materialization, conversion, Inventory, registry repair, cataloging, or composition clause is supplied in the same WKO. The analyst selects the Store by exact current Store MAP identity; Data Sculptor determines which mapped non-RID COL bindings are broken. The terminal DS-STEPS clause is REPAIR MAP ; the Receipt operation token is separately REPAIR_MAP . P2-03 monotonic eligibility boundary: structural validity/eligibility and chronology are separate. A structurally valid future-dated Store MAP remains a structurally valid MAP and participates in current-state selection. It is not demoted merely because the host clock is presently earlier. The monotonic guard applies when publishing a successor: truthful observed transaction UTC must be strictly greater than the chronology predecessor UTC before any successor state may commit. P2-04 closure — validation depth is now complete. The Tier-1/Tier-2 rules in this requirement are the complete WASM-002 oracle for deciding whether a MAP-bound RID/COL is sufficiently valid for the operation being attempted. Tier 1 is intentionally bounded and is used only by operations that do not consume RID/COL analytical contents. Tier 2 is a full streaming validation and is mandatory before an operation relies on RID/COL contents, for newly created candidates before commit, and for REPAIR MAP . REPAIR MAP determinism. Once a valid REPAIR MAP operation is entered, Data Sculptor performs Tier 2 on the Store RID and on every mapped COL. The repair successor removes exactly those mapped COL bindings whose physical COL artifacts fail Tier 2, preserves exactly those that pass Tier 2, and still refuses if zero mapped COL bindings would remain. No shallower Tier-1 result may decide the repair set. F-03 repair semantics: after target validation, Data Sculptor confirms the named MAP is current for exactly one Store lineage, confirms the referenced RID is valid, identifies every mapped non-RID COL that is missing or invalid under the required repair validation tier, preserves every valid COL binding unchanged, removes exactly the broken COL bindings from the successor candidate, preserves the exact Store lineage RID identity and remaining Store/RID metadata, validates the complete successor MAP candidate, and publishes the successor only if every repair gate succeeds. REPAIR MAP does not reread or regenerate the source CSV, rematerialize a lost COL, regenerate the RID, or edit the predecessor MAP in place. F-03 all-COLs-broken refusal: if removing the broken bindings would leave zero COL mapping rows, REPAIR MAP refuses. No zero-COL Store MAP is introduced, no special anchor row is invented, no successor MAP is published, and the Store remains DEGRADED . The existing current structurally valid MAP and RID continue to anchor the visible lineage. Identity boundary. Passing Tier 1 or Tier 2 proves only that the currently visible file under the exact governed filename satisfies the applicable WASM-002 validation contract. It does not prove that those bytes are historically identical to bytes previously present under that filename. Cryptographic historical-byte identity belongs to separately governed fingerprint evidence rather than ordinary Store health. F-15 reference-bounded eligibility: Store-MAP structural validity and inheritance eligibility are determined from the MAP artifact itself plus the governed artifacts and values that the MAP explicitly binds or that its profile explicitly requires for the validation tier being applied. Unrelated Suitcase files, unrelated Store lineages, WKOs, Receipts, Inventories, CAT/HLP/CER artifacts, analyst-owned files, directory enumeration order, and unrelated-file count cannot by their mere presence or later appearance make an already-published Store MAP eligible or ineligible. Alias-shadowing validation is a successor-publication check under W002-STOR-020; it is not a continuing ambient scan that retroactively invalidates historical MAPs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.11,The MAP-bound RID filename is the stable physical Store identity anchor in WASM-002,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, Data Sculptor does not allocate a second permanent Store UUID in addition to governed RID/MAP evidence. The exact governed rid_filename created when the Store is established is the stable physical anchor used to distinguish that Store's MAP lineage from other Stores in the same Suitcase, and every ordinary successor MAP repeats it exactly. Within any one MAP, every row must repeat the same exact current rid_filename ; disagreement is invalid. Across WASM-002 successor MAPs, a different RID filename denotes a different Store row universe and must not be silently treated as same-Store continuation. A later PRD revision may define an explicit governed recovery transition if Red5Sorcery chooses to support replacement of a damaged RID while preserving logical continuity. No such transition is executable in WASM-002.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.12,First Store MAP has deterministic Store and RID aliases,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When the first successful materialization establishes a Store, its first Store MAP must initialize store_alias to the exact common source_filename and rid_alias to the literal RID . Those are the deterministic Store and RID default aliases. A later alias-only Work Order may replace them with STORE AS ""<alias>"" and RID AS ""<alias>"" , clear them with CLEAR STORE ALIAS / CLEAR RID ALIAS , or restore these defaults with RESET STORE ALIAS / RESET RID ALIAS under W002-WKO-012.1 through W002-WKO-012.6. None of those operations changes the common source_filename , rid_filename , RID bytes, COL bytes, or prior MAP history.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-001,CAT is the governed collection-level Store Catalog artifact,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"WASM-002 shall define CAT as a governed Data Sculptor artifact class for cataloging a collection of CSV Stores inside one active Suitcase. CAT exists to let an analyst orient across many independently governed Stores without opening every MAP individually. The scaling invariant is: MAP governs locally; CAT orients globally. CAT is an index over governed Store state, not a replacement for MAP and not a second Store authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-002,CAT may reference many Stores while every MAP still governs exactly one Store,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"A CAT may contain entries for many Store lineages in the active Suitcase. Every MAP referenced by CAT still governs exactly one Store lineage under the frozen one-Store-per-MAP rule. CAT must not combine multiple Stores into one MAP, synthesize a shared Store state, or centralize Store semantics that remain governed independently by each Store's MAP lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-003,CAT has one governed CSV representation and immutable snapshot identity,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The WASM-002 Store Catalog has one durable representation: UTF-8 CSV. WASM-002 shall not emit separate HTML and CSV companion CAT artifacts for one catalog snapshot. Each successful catalog publication creates one immutable governed artifact named exactly __DS__CAT__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv . A later catalog run publishes a new CAT snapshot; earlier CAT artifacts remain visible history and are not overwritten or deleted merely because a newer snapshot exists. For orientation, the directory may identify the newest structurally valid CAT snapshot by the canonical UTC token. If two or more structurally valid CAT artifacts share the greatest canonical UTC timestamp, the UI must not invent chronology from UUID, discovery order, or filesystem modified time; it must surface the ambiguity and may present the tied CAT artifacts together until a later governed catalog run publishes an unambiguous newer snapshot. F-14 publication: CAT is first written as __DS__SCR__<UTC>__<UUID>.csv using the UTC/UUID intended for the final CAT. The complete candidate must close, reopen, and validate the exact five-column schema, deterministic row ordering, row count and CSV serialization before the class token may be renamed to CAT . A failed candidate remains SCR/non-authoritative and must not be selected as a catalog snapshot.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-004,CAT CSV schema and row order are exact and deterministic,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The canonical CAT header row is exactly: store_alias,source_filename,rid_filename,map_filename,store_health Each data row describes one routable Store lineage using values derived from the authoritative current structurally valid Store MAP selected under the existing Store rules: store_alias — current human-facing Store identity; source_filename — the one common exact source filename carried by that Store MAP and used for Store routing; rid_filename — exact immutable governed RID filename that physically identifies the Store lineage; map_filename — exact current structurally valid Store MAP used to derive the row; and store_health — the Store health evaluated during this CATALOG STORES run, exactly one of VALID , DEGRADED , or INVALID . store_health is snapshot orientation metadata, not MAP health and not an independent health authority. If the Suitcase later changes, an older CAT row continues to report the health value observed when that CAT was created. CAT rows are sorted by ascending exact UTF-8 bytes of map_filename . The header is not part of that ordering.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-005,CAT is reconstructible and never becomes Store authority,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"CAT shall be reconstructible from authoritative Store MAP artifacts and the governed Store-health evaluation applied when CATALOG STORES runs. CAT must never be consulted to decide Store routing, inheritance, Store health, repair eligibility, current MAP selection, RID/COL validity, or whether a new Store may be established. If a CAT row conflicts with authoritative MAP/Store state, current governed state wins and the CAT is stale/inconsistent. A stale CAT remains an inspectable historical governed artifact but must not be treated as current Store truth. CAT is not automatically updated by materialization, repair, alias change, or any other Store-changing operation. The analyst creates a fresh catalog explicitly by running a new CATALOG STORES Work Order; success publishes a new immutable CAT snapshot and leaves earlier CAT snapshots visible history.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-006,CATALOG STORES is the standalone governed Work Order operation,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 Work Order form is: SUITCASE: .
WORK ORDER AS ""Catalog Stores""
CATALOG STORES CATALOG STORES is one standalone top-level operation. It is initiated only by an explicit analyst Work Order. No materialization, repair, alias update, conversion, or other governed operation automatically creates, rewrites, or refreshes CAT. The operation scans authoritative governed Store MAP state, evaluates each cataloged Store's current health, and publishes one CAT snapshot plus the normal canonical Receipt. It does not mutate any Store or MAP. It must not also request materialization, conversion, alias mutation, repair, Inventory, Work Order composition, or another consequential operation in the same WKO. The canonical Receipt operation token is CATALOG_STORES .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-007,CATALOG STORES derives one row per routable Store lineage from authoritative MAP state,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The catalog scan shall identify every routable Store lineage using the same structurally-valid-MAP routing definition already frozen for WASM-002. For each routable lineage, Data Sculptor evaluates current Store health exactly under W002-STOR-019.2, using the current structurally valid Store MAP selected under W002-STOR-019.10 and the applicable validation tier, and records exactly one of VALID , DEGRADED , or INVALID . Catalog presence is orientation, not permission to perform another operation. Exactly one CAT row is emitted for each routable Store lineage, derived from that lineage's authoritative current structurally valid Store MAP and the Store-health result observed during this catalog run. If the complete authoritative collection state cannot be determined unambiguously, the operation must refuse rather than publish a knowingly incomplete or guessed CAT. CATALOG STORES is read-only with respect to all pre-existing Store, RID, COL, MAP, source, WKO, and other Suitcase artifacts. It does not repair or mutate them.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-008,CAT publication is all-or-refuse and historical CAT snapshots remain visible,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"After the complete deterministic CAT row set is established, publication follows the governed all-or-refuse artifact path: write the candidate under governed scratch, close and reopen it, validate its exact filename, UTF-8/LF CSV structure, exact header, deterministic row count/order, and row references, then promote the final CAT artifact. The CAT is not successfully published until final promotion succeeds. A publication refusal leaves prior CAT snapshots and all Store/MAP state unchanged. The Receipt records whether the catalog entry count was established and whether a final CAT filename was published.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-001,CAT and MAP discovery reuse the existing Suitcase Directory,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,WASM-002 shall reuse the existing Data Sculptor Suitcase Directory for CAT and MAP discovery and inspection. A separate CAT/MAP browser panel shall not be added.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-002,CAT and MAP artifacts are first-ranked in the existing directory,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The newest unambiguous structurally valid CAT snapshot, or any tied newest CAT candidates when chronology is ambiguous, and all Store MAP artifacts shall be surfaced prominently at the top of the existing Suitcase Directory ahead of ordinary Suitcase files. The presentation may be pinned, grouped, or otherwise first-ranked, provided the priority is obvious and deterministic.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-003,CAT and MAP contents are immediately viewable from the existing HTML UI,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,The analyst shall be able to select a visible CAT or MAP entry and inspect its contents through the existing read-only HTML UI without first locating or opening the artifact through the operating-system file browser.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-004,CAT/MAP prominence preserves ordinary read-only Suitcase filtering,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The Suitcase Directory may continue to provide read-only filtered views of other Suitcase files. CAT/MAP prominence must not remove, replace, or weaken the existing ability to inspect the rest of the flat Suitcase.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-005,Directory browsing and inspection do not require a Work Order,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"Browsing, sorting, UI filtering, selecting, opening, and viewing Suitcase files are read-only inspection actions and shall not require a Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-006,Read-only directory filtering is not governed SEARCH,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"Read-only UI filtering is not the same operation as governed SEARCH . Governed SEARCH, ZIP creation, metadata changes, repairs, CAT regeneration, and every other consequential state change remain subject to the applicable Work Order and Receipt discipline.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-007,"The directory cannot mutate CAT, MAP, Store, or Suitcase state",W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The Suitcase Directory shall not edit, rename, delete, repair, replace, regenerate, or otherwise mutate CAT, MAP, Store, or Suitcase state through direct GUI manipulation. Consequential changes occur only through explicit governed operations or analyst-owned filesystem actions already permitted by the canonical contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-008,The CAT/MAP directory view must remain practical at large collection scale,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The CAT/MAP presentation shall make collections containing dozens or hundreds of Stores practical to inspect. An analyst must be able to understand what Stores exist, which current MAP describes each Store, and which source file each Store governs without manually opening every MAP artifact through the operating-system file browser.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-ACC-001,CAT acceptance proves collection-scale orientation without centralizing Store authority,W002-CAT-ACC,W002-CAT,WASM-002,UNDER REVIEW,—,"Acceptance must include a MusicBrainz-scale fixture containing 177 routable CSV Store lineages, each with its own authoritative current Store MAP. One explicit analyst-run CATALOG STORES Work Order must publish exactly one CAT snapshot containing exactly 177 data rows under the frozen five-column schema store_alias,source_filename,rid_filename,map_filename,store_health and deterministic MAP-filename ordering. The fixture must include Stores that evaluate VALID , DEGRADED , and INVALID while retaining structurally valid current MAPs, and the CAT must record the exact health observed for each Store when the catalog run occurs. The CAT must not expose a separate MAP-health field. The existing Suitcase Directory must surface CAT and MAP artifacts ahead of ordinary files; the analyst must be able to open CAT, inspect the collection, select and view MAP artifacts, sort/filter the directory, and inspect other Suitcase files without a Work Order. No direct GUI mutation path may be exposed. Acceptance must alter authoritative MAP/Store state after the first CAT publication and prove that the earlier CAT is neither rewritten nor automatically refreshed. It remains visible and becomes stale/inconsistent where appropriate. Only a later explicit CATALOG STORES Work Order may reconstruct the collection and publish a new immutable CAT snapshot. The linked WASM-003 DIR behavior remains outside the WASM-002 implementation scope: later DIR requirements auto-populate human-readable CAT/MAP descriptions, but those descriptions never become authority over CAT, MAP, or Store semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-020,"Store, RID, and COL aliases remain human-facing metadata separate from physical identity",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Aliases are governed human-facing metadata. Creating, changing, clearing, or replacing an alias must not rename or rewrite the underlying artifact. Within one Store MAP, every non-empty COL alias and the non-empty rid_alias must be unambiguous within the row-addressable artifact alias namespace under the exact Unicode scalar-value comparison rule in PB-STOR-010. F-15 publication-time shadowing boundary: alias uniqueness and physical-name shadowing are validated when a candidate successor Store MAP is being published, against the comparison domain applicable to that one Store snapshot and the then-visible governed physical targets it makes row-addressable. If an alias would exactly collide with another addressable alias or physical filename in that publication domain, publication refuses. After a Store MAP has been validly published, the later appearance, disappearance, rename, or copying-in of an unrelated Suitcase file does not retroactively make that immutable MAP structurally invalid or ineligible. A later textual reference can still become ambiguous at resolution time under W002-STOR-021; that ambiguity causes the later operation to refuse rather than changing the historical MAP's validity. The store_alias names the Store as a whole and is separate from the field/COL alias namespace. Alias mutation occurs through a governed Work Order, not through an editable GUI field. Exact cross-Store Store-alias uniqueness and future selection-by-Store-alias syntax remain outside this freeze.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-021,Work Order resolution binds one exact Store MAP and physical targets,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A saved Work Order may refer to governed materialized columns by exact physical filename or by a unique COL alias from one selected Store MAP. The canonical explicit Store-MAP selector is MAP ""<exact Store MAP filename>"" under W002-STOR-019.3 and W002-WKO-012.3. If that clause is present and valid, exactly that Store snapshot is used. Otherwise Data Sculptor applies the Store-aware source-qualified selection rule in W002-STOR-019.2. All textual physical-filename and COL-alias comparisons in this resolution step use exact Unicode scalar-value sequence equality under PB-STOR-010: no case folding, Unicode normalization, trimming, locale equivalence, or filesystem enumeration heuristic is permitted. Resolution is bounded to the selected Store snapshot and the physical targets/aliases that are addressable through that snapshot. If the supplied text has no exact target, resolution refuses. If it has more than one exact possible target in that domain—for example because a currently visible physical filename and a current alias are both exact matches—resolution also refuses. Data Sculptor must not choose filename over alias, alias over filename, first-found entry, directory order, modified time, UUID, or any other tie-break heuristic. Before execution, Data Sculptor must record the exact physical Store MAP identity when one is used, bind the run to its exact rid_filename , and resolve aliases deterministically to physical COL artifacts. The selected Store MAP must remain fixed for the run even if a newer MAP is created during that same run. This protects Store/selection continuity but does not by itself claim that bytes stored under an analyst-owned source filename are cryptographically identical across different runs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022,Each successful Suitcase validation publishes one retained governed CER HTML certificate,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A selected directory becomes a validated Suitcase only when Data Sculptor successfully creates, completely writes, and closes one governed CER HTML Suitcase Validation Certificate in that directory. The certificate itself is the validation artifact and remains visible in the flat Suitcase as durable evidence. No validation-only delete or rename is required. Failure to create, completely write, or close the certificate means the directory has not passed Suitcase validation and analytical execution remains locked. F-14 CER exception: the CER is deliberately not staged as SCR . Suitcase validation is specifically the direct create/write/close test of the final canonical CER identity in the selected directory. Inserting an SCR-to-CER rename would test a different publication path and is therefore forbidden for this validation step. A successful CER does not pre-certify later SCR-to-final renames for other artifact classes. F-24 CER lifecycle: every successful explicit Suitcase selection and validation publishes exactly one fresh immutable CER with a new governed UTC+UUID identity. Data Sculptor must not satisfy a new validation event by reusing an earlier CER. Every prior valid CER remains a standalone historical artifact under its original governed filename and exact bytes. WASM-002 performs no automatic CER deletion, replacement, compaction, or CER-history ZIP packaging. Historical CERs are not housekeeping candidates merely because a newer CER exists. Any later archival or packaging capability must be separately governed and explicitly invoked; it is not part of the WASM-002 validation lifecycle.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.1,Suitcase Validation Certificate physical identity and longest-name path gate,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The exact certificate filename is __DS__CER__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html , using the canonical UTC millisecond token and canonical lowercase hyphenated UUID v4. Data Sculptor chooses the filename; the analyst does not supply or edit it. The CER create/write/close test begins only after the browser host has satisfied the required user-selected writable-directory capability in W002-PLAT-001. A browser that cannot expose that capability produces a host-capability refusal before folder validation; that condition is not evidence that any particular directory is unwritable or filename-incompatible. WASM-002 path/filename acceptance must derive the maximum filename length from every governed final-artifact filename form and every governed SCR staging form that this build can actually emit. Under the current contract, the maximum is 73 ASCII bytes/characters : the governed .html CER/HLP final forms and an SCR candidate reserved for a .html final artifact have that length. The canonical CER filename therefore exercises the current maximum emitted filename length during the create/write/close validation test. On a supported host, successful create/write/close of this canonical governed HTML filename is the WASM-002 folder filename/path compatibility test for the current emitted-name maximum. Data Sculptor does not maintain a product-level table of operating-system numeric path maxima and must not truncate, abbreviate, hash-shorten, or otherwise mutate a governed filename to fit a host path limitation. If the certificate cannot be created under its canonical name after a directory has actually been selected through the supported-host contract, the selected directory does not pass validation. If a future PRD revision introduces an emitted final or staging filename longer than the current CER/HLP/SCR-HTML maximum, acceptance must detect that change and explicitly exercise the new maximum before the build may rely on this path-compatibility claim.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.2,Suitcase Validation Certificate semantic content,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The HTML certificate uses the canonical built-in Data Sculptor presentation and must visibly contain, at minimum: SUITCASE VALIDATION CERTIFICATE RESULT: PASS SUITCASE: . UTC: <canonical certificate UTC> UUID: <certificate UUID> ARTIFACT: <full governed certificate filename> TEST: CREATE_WRITE_CLOSE It must state that Data Sculptor successfully created, completely wrote, and closed this governed HTML certificate in the selected Suitcase. It must state that this establishes that the selected directory was writable by Data Sculptor at the recorded UTC and accepted the governed artifact filename used for the certificate. It must also state that the certificate does not certify available disk capacity, guarantee success of future analytical operations, or certify later SCR -to-final-class publication/rename operations. The semantic record uses SUITCASE: . and must not persist an absolute machine-specific path merely to prove validation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.3,Suitcase Validation Certificate uses the canonical built-in presentation in WASM-002,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The certificate is a human-facing HTML CER artifact and uses the canonical built-in Red5Sorcery/Data Sculptor presentation in WASM-002. Presentation must never change RESULT , SUITCASE , UTC, UUID, artifact identity, TEST , validation meaning, or limitation facts. Configurable Brand Manifest application to CER artifacts is deferred to V1-BACKLOG / a future build and is not required for WASM-002 Suitcase validation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-023,Non-Store governed artifacts use class-specific all-or-refuse publication profiles,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Except for the deliberate CER Suitcase-validation path below, WASM-002 does not place a newly generated durable artifact into its final semantic class merely because candidate bytes exist. The complete candidate is first written under the governed SCR identity defined by W002-STOR-023.1, closed, reopened, and validated against the target class contract. Only a candidate that passes its class-specific publication predicate may be renamed into the intended final class. A final-class filename therefore records successful class publication, not broader authority where a separate MAP/registry relationship governs authority. F-33 reserved-class boundary: DGN , RCV , BRD , and LCK are registered but not emitted by WASM-002, so they do not appear as publication profiles in this table and have no WASM-002 producer here. Final class Final serialization / identity Publication predicate Authority boundary WKO __DS__WKO__<UTC>__<UUID>.txt The complete candidate obeys the saved-Work-Order lifecycle and parses completely under exactly one WASM-002 executable operation grammar with the required SUITCASE: . , exactly one non-whitespace WORK ORDER AS alias, and the governed lexical/comment rules. Applicable save-time alias/registry gates must also pass before the save transaction may commit. Promotion proves a valid immutable WKO artifact. Alias-registry authority is not committed until the complete successor WKO MAP is successfully published under W002-STOR-018.3. RCP __DS__RCP__<UTC>__<UUID>.txt The complete candidate validates against W002-RCP-005 through W002-RCP-008: exact deterministic TXT serialization, common envelope, applicable operation-specific key table, governed absence semantics, and created-artifact tail. Publication creates durable run evidence only. It does not retroactively create or change analytical state. HLP __DS__HLP__<UTC>__<UUID>.html The complete self-contained HTML satisfies the HLP disclosure, presentation, provenance, embedded-JSON, lineage and semantic-parity rules in W002-HELP-009 and related Help requirements. Publication creates durable Help/support evidence. It does not override the underlying diagnostic event or analytical state. CVT __DS__CVT__<UTC>__<UUID>.csv The bounded Windows-1252 conversion completes, the original analyst-owned source remains unchanged, the converted bytes pass the governed strict UTF-8 requirement, and the candidate closes/reopens successfully. Structural CSV interpretation remains a later certification/materialization concern. The published exact CVT filename is a new immutable governed source identity for later routing under W002-CONV-004. INV __DS__INV__<UTC>__<UUID>.txt The complete inventory scan has established the governed entry set and the candidate validates the deterministic INV serialization, count, metadata availability and ordering rules. Publication creates an immutable inventory snapshot; it is evidence/orientation, not Store authority. CAT __DS__CAT__<UTC>__<UUID>.csv The authoritative MAP discovery/evaluation pass has completed and the candidate validates the exact five-column CAT schema, row count, row ordering and deterministic CSV rules. Publication creates an immutable collection-level orientation snapshot. MAP remains authoritative for each Store. CER __DS__CER__<UTC>__<UUID>.html Deliberate exception: Suitcase validation directly creates, completely writes and successfully closes the final CER identity under W002-STOR-022 through W002-STOR-022.3. No SCR staging/rename is inserted into this test. The CER proves that canonical governed create/write/close succeeded in the selected directory at that recorded moment. It does not pre-certify later SCR-to-final publication. RID, COL, Store MAP and WKO MAP publication retain their specialized transaction/commit rules elsewhere in this PRD. W002-STOR-023 does not replace those state-publication contracts; W002-STOR-023.1 supplies the shared SCR candidate identity and retained-failure-evidence boundary they may reference.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-023.1,SCR candidates preserve intended final identity; retained failure evidence remains non-authoritative,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical candidate filename for a staged governed artifact is: __DS__SCR__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.<final-extension> The SCR candidate uses the exact UTC token, UUID and extension reserved for its intended final artifact. Successful publication changes only the three-letter semantic class token from SCR to the intended final class. For example, an RCP candidate __DS__SCR__20261006T190000000Z__<uuid>.txt may become __DS__RCP__20261006T190000000Z__<uuid>.txt only after the complete candidate has been closed, reopened and validated against the RCP publication predicate. The rename must not alter candidate bytes, UTC, UUID or extension. An SCR filename never by itself confers final-class validity, Store membership, registry authority, execution authority, or durable final-class evidence status. A retained SCR whose bytes happen to satisfy a target validator after an interrupted or refused transaction must not be auto-promoted, silently adopted, or treated as if the missing publication step occurred. F-33 retained-failure-evidence boundary: when a handled failure leaves one or more SCR candidates or other staged bytes that cannot be safely removed or restored, they must remain visible only as non-authoritative SCR evidence. WASM-002 does not publish an RCV recovery manifest. Retention must not complete or simulate the failed publication step, and the governed diagnostic/Help path must report the failure using only facts actually established. A retained or orphaned SCR remains non-authoritative even if its bytes later validate. Data Sculptor must not infer an intended final class solely from extension or byte content, must not rename or promote the SCR merely because it survives a later scan, and must not create a replacement RCV sidecar to manufacture attribution that the failed transaction did not durably preserve.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-011; CP-012; CP-013,"CP011 T-ACCEPTED, GIT BANKED — exact CVT-to-SCR candidate identity derivation only; full SCR lifecycle and publication contract remains open; CP012 T-ACCEPTED, GIT BANKED — canonical SCR staging filename recognition only; generic publication, recovery and authority remain unimplemented; CP013 T-ACCEPTED, GIT BANKED — explicit SCR-to-RCP final filename candidate derivation only; no complete SCR lifecycle, RCP validator, filesystem promotion, publication or authority",e84ae5baeee05f9d5d30284c65b86eebba3c0f6a; efca04392940e398020a5c06b9ee50296c8a1fdd; 005a38ef5e876847c4c08901c18da9c18565fd6b,"Evidence/CP-011/CP011_Scope_Lock.txt; Evidence/CP-011/CP011_RED_Test_Output.txt; Evidence/CP-011/CP011_GREEN_Test_Output.txt; Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt; Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt; Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt; Evidence/CP-011/CP011_Hash_Inventory_Verification.txt; Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt; Evidence/CP-011/CP011_Closing_Git_Review.txt; CP011_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-012/CP012_Scope_Lock.txt; Evidence/CP-012/CP012_RED_Test_Output.txt; Evidence/CP-012/CP012_GREEN_Test_Output.txt (initial 5/6, retained); Evidence/CP-012/CP012_GREEN_Failure_Triage.txt; Evidence/CP-012/CP012_GREEN_Correction_Review.txt; Evidence/CP-012/CP012_GREEN2_Test_Output.txt; Evidence/CP-012/CP012_Full_Regression_Test_Output.txt; Evidence/CP-012/CP012_WASM_Build_Output.txt; Evidence/CP-012/CP012_Final_Rustfmt_Check.txt; Evidence/CP-012/CP012_Hash_Inventory_Verification.txt; Evidence/CP-012/CP012_Supplementary_Hash_Verification.txt; Evidence/CP-012/CP012_Post_Staging_Hash_Verification.txt; Evidence/CP-012/CP012_Closing_Git_Review.txt; CP012_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-013/CP013_Approved_Scope_Lock.txt; Evidence/CP-013/CP013_RED_Test_Output.txt; Evidence/CP-013/CP013_GREEN_Test_Output.txt; Evidence/CP-013/CP013_Full_Regression_Test_Output.txt; Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt; Evidence/CP-013/CP013_WASM_Build_Verification.txt; Evidence/CP-013/CP013_Hash_Inventory_Verification.txt; Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt; Evidence/CP-013/CP013_Closing_Hash_Verification.txt; Evidence/CP-013/CP013_Final_Staging_Verification.txt; Evidence/CP-013/CP013_Closing_Git_Review.txt; CP013_Git_Banking_Output.txt (post-commit, separately preserved)","CP011 Day066: public pure helper build_scr_candidate_filename_for_cvt(&str)->Option<String> accepts an exact canonical governed CVT .csv filename (via CP010 recognizer) and derives the paired SCR filename by substituting only class token CVT -> SCR, preserving exact UTC, UUIDv4 and lowercase .csv bytes; rejects wrong classes, paths, whitespace, malformed clock/date/UUID, extension and class case. Six targeted tests; RED expected E0432 exit 101; GREEN 6/6; post-format native regression 46/46; rustfmt recheck PASS; Rust 1.97.1 wasm32-unknown-unknown --lib build PASS; original 28/28 and combined 36/36 SHA-256 records verified. Two local scoped .gitattributes whitespace exceptions preserve Rustfmt/Git diagnostic TXT bytes; final Git staged check PASS. T-approved and Git banked e84ae5baeee05f9d5d30284c65b86eebba3c0f6a, 27 committed files, working tree clean. Lexical candidate-name pairing ONLY; no SCR creation, bytes, converter, transaction, close/reopen, validation/publication, retained SCR adoption, SOURCE authority or browser execution. Independent Claude implementation QA pending. CP012 Day066: pure public bool recognizer is_canonical_scr_filename_candidate(&str) validates exact uppercase SCR staging class via shared canonical immutable filename-token parser, with local rejection of whitespace and both path separators; accepts canonical .csv and .txt SCR candidates without assuming extension or bytes confer intended final class, validity, publication or authority. RED expected missing import E0432 exit 101. Initial GREEN 5/6 exposed trailing whitespace acceptance through generic extension grammar, retained verbatim; controlled CP012-local correction yielded 6/6 PASS. Full native regression 52/52 PASS, Rustfmt 12 Rust files checked/0 modified, canonical Rust 1.97.1 wasm32-unknown-unknown --lib build PASS (not browser execution). Primary independent SHA256/size inventory 29/29 PASS; supplementary original 4/4 PASS; post-staging 6-record amendment independently verified following narrowly scoped trailing-space and blank-at-EOF git attributes for preserved diagnostic evidence; final staged Git whitespace exit 0. T approved and banked Git commit efca04392940e398020a5c06b9ee50296c8a1fdd (28 committed files; master clean). Previous generic canonical parser unchanged. W002-STOR-023.1 remains PARTIAL, no filesystem creation, close/reopen, class publication, retained/orphan SCR adoption or recovery, SOURCE authority, or independent Claude implementation QA claimed. CP013 Day066: pure public function build_final_filename_candidate_for_scr(&str, &str)->Option<String> accepts only a canonical SCR staging filename with exact lowercase .txt serialization and explicit intended_final_class == ""RCP""; derives RCP final filename candidate by substituting the SCR semantic-class token only, preserving original UTC token, UUID and extension. Rejects all other class intentions, malformed or non-SCR staging names, paths/whitespace, wrong extension or case. Six intentional RED tests (unresolved E0432 before implementation), six GREEN targeted passes; full native 58/58 PASS; Rust 1.97.1 rustfmt check PASS and wasm32-unknown-unknown --lib build PASS (not browser runtime). Primary 21/21, supplementary 27/27 before attribute revisions; post-normalization 32/32 and closing 37/37 SHA-256 identity/byte-preservation checks; 42/42 commit blobs verified, Git whitespace check exit 0 after directory-scoped CRLF-aware whitespace attributes and raw-byte preservation; staging failures and adjustments retained byte-for-byte. T accepted and Git banked 005a38ef5e876847c4c08901c18da9c18565fd6b (efca04392940e398020a5c06b9ee50296c8a1fdd parent), 42 files, clean tree and index. This covers only lexical candidate-name derivation under already-PARTIAL W002-STOR-023.1; W002-STOR-023 remains NOT_STARTED; no SCR creation, RCP contract validation, promotion, publication, retained/orphan handling, authority or recovery. No independent adversarial QA or accepted end-to-end requirements; Day066 OPEN.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001,Strict whole-file UTF-8 certification,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Before WASM-002 performs analytical CSV materialization, it must certify the complete selected source as valid UTF-8 using bounded processing.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.1,"Certification must examine the entire source, not merely a prefix, sample, BOM, or first analytical window.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.2,"UTF-8 validity must be determined across chunk boundaries, including incomplete multi-byte sequences that span adjacent input windows.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.3,"A UTF-8 BOM, when present, is parsing metadata and must not be treated as proof that the remainder of the source is valid UTF-8.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.4,Certification must preserve exact source-byte accounting.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.5,Certification must operate within the governed WASM memory budget.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Stage 1 UTF-8 certification must remain bounded independently of source byte length and must not buffer the complete source, CSV header, or CSV row set in memory. CSV column-count and operational-name rules belong to Stage 2 and must not be used to justify unbounded Stage-1 state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.6,Certification must produce deterministic PASS or FAIL for the same source bytes under the same frozen rules.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002,UTF-8 certification is a hard analytical gate,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,The WASM-002 analytical/materialization path must proceed only after successful UTF-8 certification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.1,"If UTF-8 certification fails, the current analytical Work Order must stop.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.2,The analytical engine must not silently switch to another decoder.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.3,The analytical engine must not continue materialization under an inferred or guessed source encoding.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.4,No Windows-1252 transcoding may occur as an implicit sub-step of the failed analytical Work Order.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003,Certification and materialization share one run-local selected source,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"For a governed WASM-002 analytical run, the browser host must resolve the Work Order source reference once and retain the same selected source instance across Stage 1 UTF-8 certification and Stage 2 materialization. The purpose of this binding is to prevent Stage 2 from accidentally consuming a different source than the one Stage 1 certified. It is a run-local continuity guarantee, not a claim of durable cryptographic identity across separate runs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.1,Stage 2 must not re-resolve or substitute the source,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"After Stage 1 begins, Stage 2 must not reacquire the analytical source by re-reading an alias mapping, re-resolving a filename/path, opening a newly selected browser file, or otherwise substituting another source instance. Stage 2 consumes the source instance already bound to the governed run.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.2,"Filename, alias, path, or byte length alone is not durable byte identity",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Filename equality, alias equality, path equality, timestamps, or exact byte length may be useful provenance facts but must not be presented as cryptographic proof that source bytes are identical across separate runs. WASM-002 makes no such automatic cross-run exact-byte claim.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.3,Ordinary WASM-002 source binding does not require automatic SHA-256,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,UTF-8 certification and ordinary column materialization must not automatically compute SHA-256 merely to establish WASM-002 source binding. The source-binding requirement is satisfied by preserving the same run-local selected source instance across the two stages. This rule does not prohibit SHA-256 where another explicit WASM-002 requirement governs integrity for a specific generated artifact. It applies to automatic hashing of ordinary analytical source data.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.4,Loss of run-local source continuity causes refusal,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"If the browser host cannot preserve the selected source instance from certification into materialization, or the source becomes unavailable before Stage 2 can consume it, the analytical run must refuse before materialization rather than silently reselect, substitute, or infer another source.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004,ASCII-first inline UTF-8 certification algorithm,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"WASM-002 must use an ASCII-first, strict inline UTF-8 certification algorithm or an equivalent implementation that preserves the same single-forward-scan semantics, bounded state, deterministic validity result, exact error location, and performance intent established by WASM-001b.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.1,The certifier must process the source in bounded windows and must not allocate memory proportional to source-file size.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.2,"The 4 MiB window used in WASM-001b is a proven reference point, not a frozen WASM-002 production constant.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Window size may be changed only if semantics and byte-identical certification outcomes remain invariant.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.3,"At the beginning of each window, any incomplete UTF-8 sequence carried from the preceding window must be resolved before the remaining bytes are treated as independent input.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.4,"When there is no pending cross-window sequence, consecutive bytes below 0x80 must be recognized as ASCII and certified directly because ASCII is a complete subset of UTF-8.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.5,An all-ASCII window with no pending cross-window sequence must be certifiable without submitting the same bytes to a second general UTF-8 decoder pass.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.6,"When a byte at or above 0x80 is encountered, the certifier must validate the UTF-8 sequence inline, then resume the ASCII-fast scan after the valid sequence.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.7,"The implementation must not require collecting all non-ASCII bytes, all non-ASCII runs, or all non-ASCII offsets for later validation.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.8,The implementation must not require a separate general-purpose string-decoder call for each non-ASCII sequence.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,An equivalent low-overhead strict validator is acceptable if it preserves the same governed result and bounded-state behavior.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.9,Cross-window state must be bounded to the information required for at most one incomplete UTF-8 sequence.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"No more than three source bytes may need to remain pending between windows, or an equivalent smaller state representation may be used.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.10,"On the first invalid UTF-8 sequence, certification must stop and report the exact absolute source-byte offset required by the frozen error contract.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"On the first invalid UTF-8 sequence, certification must stop and return FAIL . The governed UTF-8 refusal evidence is: FIRST_INVALID_BYTE_OFFSET — the zero-based absolute byte offset of the first byte of the invalid sequence , counted from the first physical source byte, including a permitted leading UTF-8 BOM when present; and STOP_REASON — exactly INVALID_UTF8_SEQUENCE . For an EOF-truncated multibyte sequence, FIRST_INVALID_BYTE_OFFSET is the absolute offset of that incomplete sequence's lead byte, not the EOF position. The certifier need not read the remainder of an already-invalid source. Input-window boundaries must not change the outcome, stop reason, or first-invalid offset. F-16 follow-on boundary: stopping strict UTF-8 certification at the first invalid sequence does not make the remainder of the source irrelevant to conversion advice. When the governing operation is MATERIALIZE and Stage 1 reaches FAIL , the analytical run remains refused; Data Sculptor then starts the separate read-only compatibility assessment in W002-CONV-002 from physical byte offset 0 of the same bound source instance. That second pass may read to EOF solely to determine converter compatibility. Stage 2 must not start.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.11,"At EOF, certification may return PASS only if every source byte has been consumed under the strict UTF-8 rules and no incomplete sequence remains pending.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"At EOF, certification may return PASS only if every physical source byte has been consumed under the strict UTF-8 rules and no incomplete sequence remains pending. The completed Stage-1 outcome vocabulary is exactly PASS and FAIL . PASS means strict whole-source UTF-8 certification completed successfully. FAIL means an invalid UTF-8 sequence was deterministically established under W002-ENC-004.10. The common Receipt absence tokens remain separate from those completed outcomes: NOT_RUN when Stage 1 never begins, and NOT_AVAILABLE when Stage 1 begins but a separate failure prevents a governed PASS/FAIL conclusion. NOT_APPLICABLE is not a completed value for STAGE1_UTF8_OUTCOME .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.12,"A UTF-8 BOM at absolute source offset zero may be recognized as BOM metadata after its bytes are validated, but the remaining source must still undergo complete certification.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.13,"The certifier must not perform CSV delimiter, quote, header, row, or analytical interpretation.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Certification answers only whether the complete source byte stream is valid UTF-8 under the frozen rules.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.14,Certification results must be independent of window boundaries.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Splitting the same valid or invalid source at different bounded window sizes must not change PASS/FAIL or the first invalid absolute byte offset.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.15,"The certifier must expose enough measured counters for acceptance evidence to reconcile source bytes read, windows/pushes processed, non-ASCII sequences encountered when counted, final pending state, and stop reason without requiring those counters to alter certification semantics.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005,Strict UTF-8 byte-sequence rules,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"The inline validator must implement strict modern UTF-8 validity, excluding overlong forms, UTF-16 surrogate code points, values above U+10FFFF, invalid lead bytes, invalid continuation bytes, and truncated sequences. F-07 stop-reason vocabulary: all strict UTF-8 invalidity classes governed by this requirement—lone continuation bytes, malformed continuation sequences, overlong forms, surrogate encodings, values above U+10FFFF, invalid lead bytes, and EOF-truncated sequences—serialize the single machine reason token INVALID_UTF8_SEQUENCE . The specific fixture category is acceptance evidence; the canonical stop reason intentionally does not duplicate validator-library-specific subcodes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.1,Single-byte ASCII is 0x00 through 0x7F.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.2,Two-byte sequences must begin with 0xC2 through 0xDF and be followed by exactly one continuation byte 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.3,"Three-byte sequences beginning with 0xE0 must use a second byte 0xA0 through 0xBF and a third byte 0x80 through 0xBF, preventing overlong encodings.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.4,Three-byte sequences beginning with 0xE1 through 0xEC or 0xEE through 0xEF must use two continuation bytes 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.5,"Three-byte sequences beginning with 0xED must use a second byte 0x80 through 0x9F and a third byte 0x80 through 0xBF, excluding UTF-16 surrogate halves.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.6,"Four-byte sequences beginning with 0xF0 must use a second byte 0x90 through 0xBF followed by two continuation bytes 0x80 through 0xBF, preventing overlong encodings.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.7,Four-byte sequences beginning with 0xF1 through 0xF3 must use three continuation bytes 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.8,"Four-byte sequences beginning with 0xF4 must use a second byte 0x80 through 0x8F followed by two continuation bytes 0x80 through 0xBF, preventing code points above U+10FFFF.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.9,Bytes 0x80 through 0xBF are invalid when encountered as lead bytes.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.10,Bytes 0xC0 and 0xC1 are invalid lead bytes because they can only introduce overlong encodings.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.11,Bytes 0xF5 through 0xFF are invalid UTF-8 lead bytes.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"ASCII-first inline UTF-8 certification algorithm READ NEXT BOUNDED WINDOW Reference evidence used 4 MiB windows RESOLVE PENDING CROSS-WINDOW STATE At most one incomplete UTF-8 sequence ASCII FAST SCAN Advance cheaply while every byte < 0x80 ASCII RUN Already valid UTF-8 RESUME SCAN Same window BYTE >= 0x80 Validate sequence inline STRICT UTF-8 Lead + continuation range rules VALID END OF WINDOW? Persist only bounded carry state MORE SOURCE? Yes: read next window; No: finish EOF + NO PENDING STATE UTF-8 PASS INVALID OR TRUNCATED UTF-8 FAIL No full-file allocation. No collection of all non-ASCII bytes. No per-sequence general string decode required. Figure 2. The WASM-001b-derived fast path certifies ASCII directly, validates only non-ASCII sequences inline, and carries only bounded state across windows.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-006,Measured evidence inherited from WASM-001b,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"The following measurements are non-normative evidence explaining why WASM-002 begins with the ASCII-first inline algorithm. They are not WASM-002 acceptance results and must not be represented as such. EVID-W001B-UTF8-001 On the 7,250,808,204-byte Statistics Canada source, the Day 039 distribution experiment observed 659,103 non-ASCII bytes, approximately 0.009090063% of the file, across 329,551 non-ASCII runs/sequences; the maximum observed non-ASCII run was three bytes. EVID-W001B-UTF8-002 The Day 039 non-ASCII-only experiment submitted only 659,103 bytes to strict UTF-8 validation and completed in 12.664716 seconds at 545.998 MiB/s; it proved the source valid but still incurred 329,551 strict validation calls. EVID-W001B-UTF8-003 A 1 GiB A/B test showed that reducing validated bytes alone was not enough: the selective per-run strategy submitted 115,839 bytes in 57,919 strict calls but took 503.7536 ms, while the baseline submitted 113,246,208 bytes in 27 strict calls and took 411.3590 ms. UNRESOLVED SOURCE DAMAGE: preserved authoritative text continues “This supported removing per-run general-validator call overhead rather than merely shrinking” but the remainder has not been recovered. No missing words are inferred or supplied. EVID-W001B-UTF8-004 The final native inline scan certified all 7,250,808,204 bytes in 10.377870 seconds at 666.313 MiB/s, observed 329,551 non-ASCII sequences and 659,103 non-ASCII bytes, and made zero std::str::from_utf8 calls. EVID-W001B-UTF8-005 The same inline design was exercised in Microsoft Edge/WASM with 4 MiB transfers: the valid 7,250,808,204-byte source completed with 1,729 pushes, UTF8_VALID=true, and EOF_ALL_BYTES_VALID. That experimental run took 30.5858 seconds including file I/O, JS-to-WASM copy, and WASM validation. EVID-W001B-UTF8-006 A full-size deliberately invalid Edge/WASM fixture stopped early after 2,936,012,800 bytes and 700 pushes with UTF8_VALID=false and STOP_REASON=INVALID_UTF8_SEQUENCE rather than reading to EOF. EVID-W001B-UTF8-007 WASM-001b also retained malformed UTF-8 fixtures for stray legacy bytes, truncated sequences, lone continuation bytes, overlong encodings, UTF-16 surrogate halves, and 0xFE/0xFF invalid bytes. WASM-002 should reuse or regenerate equivalent acceptance fixtures with known invalid offsets.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001,Stage 2 consumes the source instance certified by Stage 1,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The structural CSV parser and materializer operate under the explicit invariant that the same run-local selected source instance has already passed governed whole-file UTF-8 certification. Stage 2 must not independently re-resolve the analytical source. Stage 1 establishes encoding validity. Stage 2 establishes CSV structure, row identity, selected values, and governed outputs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.1,Stage 2 must not independently re-decide the source encoding.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.2,Stage 2 must not contain an automatic Windows-1252 fallback.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.3,Stage 2 may perform only those byte/character checks required for correct CSV structural parsing and frozen analytical semantics.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.4,"Any implementation shortcut that would weaken the certified-source invariant must be treated as a PRD change, not an optimization.",W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.5,Stage 2 restarts at byte offset zero of the same certified source instance,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"After Stage 1 returns PASS, Stage 2 must begin its structural pass from absolute source byte offset zero using the same run-local selected source instance. Rewinding/re-reading the existing source handle is permitted; performing a new filename, alias, path, picker, or directory resolution is not. If the host cannot re-read that same selected source instance for Stage 2, the Work Order must refuse under the run-local source-continuity contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.6,Stage 2 consumes an offset-zero UTF-8 BOM as metadata before header parsing,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"If the certified source begins with the UTF-8 BOM bytes EF BB BF , Stage 2 must consume those three bytes before parsing the first CSV header field. They must not become part of the first source header or selected value. The BOM is recognized only at absolute source offset zero. The fact that Stage 1 already saw the BOM does not permit Stage 2 to skip or reinterpret arbitrary later bytes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.7,Stage 2 parses the header once and then continues directly into the data-record scan,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Within the Stage 2 forward source scan, Data Sculptor must parse the complete first logical CSV record as the source header, construct ordered header metadata including exact decoded header text and 1-based source ordinal, resolve and validate all Work Order selectors/aliases, and then continue from the first data record without restarting the source. Header resolution therefore does not add a third whole-file pass. A header-only valid CSV yields a zero-row materialization; a source with no valid header record refuses. P3-09 no-header-record refusal: after Stage 1 has certified the source, if Stage 2 reaches end-of-source without establishing any logical CSV record from which a header could be parsed, materialization must refuse with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD . This is the eighth governed Stage-2 structural CSV refusal token in the canonical oracle defined by W002-MAT-002.8. Its governed location facts are: CSV_SOURCE_BYTE_OFFSET = exact source byte length; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; CSV_FIELD_ORDINAL: 1 . Therefore a zero-byte source reports offset 0 , and a source containing only the UTF-8 BOM bytes EF BB BF reports offset 3 . A first logical record that exists but is blank remains governed by the already-frozen BLANK_LOGICAL_RECORD condition and must not be reclassified as NO_HEADER_RECORD . F-20 source-width boundary: the established header record may contain at most 16,384 physical source columns. Exactly 16,384 is valid; a header record containing 16,385 or more fields must refuse deterministically during header resolution before the first data record is consumed. The bound applies to the complete physical source width, not merely the requested KEEP set. Header processing must remain bounded. Exact decoded source-header text is authoritative source evidence and must be preserved for every selected/materialized column, but the implementation is not required to retain the complete decoded text of every unselected header after selector resolution when bounded metadata is sufficient.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.8,Stage 2 relies on Stage 1 UTF-8 validity rather than revalidating the file,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 must not run a second whole-file UTF-8 certification algorithm over the source. It may inspect bytes and decoded field content only as required for CSV structure, header/selector semantics, governed field-size limits, output serialization, and diagnostics. Any implementation that reintroduces redundant whole-source UTF-8 validation into Stage 2 is a measurable architectural regression unless separately justified and accepted.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002,One-pass multi-column materialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"A valid Work Order may request multiple source columns for materialization during the same bounded structural pass. For WASM-002 DS-STEPS, the requested set is expressed by one KEEP block containing one or more HEADER and/or COLUMN selectors under W002-STEPS-001 through W002-STEPS-004. F-20 KEEP-width boundary: one governed KEEP block may resolve from 1 through 16,384 distinct source columns, subject to the source itself containing no more than 16,384 columns. An empty KEEP or a request that cannot resolve within that bound refuses before data-row materialization.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.1,Requested columns must be resolved and validated before data-row materialization begins,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Every HEADER and COLUMN selector in the governed KEEP block must resolve to exactly one source column before any data-row materialization begins. Missing headers, ambiguous duplicate-header matches, invalid/out-of-range ordinals, duplicate resolved selections, invalid aliases, and successor-MAP alias collisions must refuse before the structural data-row pass. The resolved selection cardinality must be an integer from 1 through 16,384 . Resolution/validation must finish before the first data record is consumed, including operational-name/default-alias derivation and any deterministic oversized-header fallback required by W002-STOR-019.7.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.2,All selected columns are emitted from one forward data-record scan,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"After header/selector resolution, Stage 2 must traverse the source data records once regardless of whether the Work Order selects one column or many. The engine must not perform one complete source rescan per requested column. During that scan, every source field is interpreted structurally, but only the fields required by the resolved selection set are materialized into governed COL outputs. F-20 one-pass boundary: “one forward data-record scan” means one traversal of the source data records for the MATERIALIZE operation. WASM-002 must not reread source data records in batches merely because the selected-column set is wide. An implementation may perform additional bounded passes over Data-Sculptor-owned SCR , spool, or staging structures after the source scan when needed to finalize many outputs within resource limits; such passes must not reread the source data records or change governed output semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.3,One 1-based logical row ordinal aligns every selected output,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The header is not a data row. The first accepted logical data record is row identity 1, the next is 2, and so on through N. The row counter advances exactly once per accepted logical CSV data record, not per physical line. Every selected COL produced by the run must contain exactly one logical data record for each accepted source data row and therefore exactly N data records in the same governed order. A multiline quoted field remains part of one logical record and must not advance row identity merely because it contains physical newline bytes. When the run establishes a new Store, this 1..N sequence is published as that Store's one governed RID artifact. When the run extends an existing Store without changing its row universe, the existing RID is reused and must not be regenerated or renumbered.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.4,Selected-column writer order follows resolved KEEP order,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Before the data-record scan begins, the validated selection set is placed in the same order in which its selectors appear in the governed KEEP block. That resolved order governs writer creation, per-row selected-field dispatch, progress/receipt presentation, deterministic backpressure-drain priority, and candidate COL identity allocation. The Store MAP's own CSV mapping-row ordering remains governed separately by W002-STOR-019.9 and must not be confused with Work Order selection order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.5,Multiple active COL outputs use bounded staging and explicit backpressure,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Each active materialized-column writer, or an equivalent shared multiplexed output structure, must have bounded staging capacity. The aggregate kernel-owned staging state for all active writers must remain inside the governed WASM memory budget and must not grow with source row count or total output size. If a required output writer cannot accept additional canonical bytes without exceeding its governed staging capacity, source consumption must pause while pending output is drained/written. When more than one writer requires service, drain priority follows resolved KEEP order. After sufficient space is available, parsing resumes from the same structural state. The exact tuned staging-buffer size is an implementation/benchmark constant rather than an analytical semantic constant; changing it must not change output bytes, row identity, selection results, or diagnostics for the same governed input. F-20 writer-resource bound: KEEP width and simultaneously active writable resources are distinct. The accepted build must declare a finite implementation bound on simultaneously active writable-output resources and retain acceptance evidence of both that configured bound and the observed peak. The engine may satisfy a wide selection by bounded shared/multiplexed staging or a Data-Sculptor-owned spool followed by bounded finalization passes, but it must not require one simultaneously open writer per selected column. Changing the writer-resource bound must not change final bytes, row order, selection identity, aliases, Receipts, or diagnostics for the same governed input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.6,Partial output sets are never published as a successful materialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"All requested materialized-column outputs begin as visible governed SCR candidates, not COL artifacts. On first materialization of a new Store, the automatically generated RID likewise begins as a governed SCR candidate. Before any new RID/COL SCR candidate is opened, Data Sculptor establishes one publication-transaction UTC under PB-STOR-013/PB-STOR-014 and allocates a distinct artifact-specific UUID for each new candidate. Each candidate filename therefore already carries the exact UTC, UUID, and final extension intended for that RID or COL identity. A materialization transaction may begin promotion only when every required RID/COL candidate reaches EOF successfully, all selected outputs reconcile to the same accepted data-row count N, and all required candidate finalization/validation succeeds. F-04 existing-Store cardinality gate: when materialization targets an existing VALID Store, after Stage 2 establishes the complete candidate logical data-row count N and before any requested COL candidate is promoted, Data Sculptor must read the expected N from the already-valid inherited RID header and compare the two values. If candidate N equals RID-header N , the cardinality gate passes and ordinary publication may continue. If candidate N differs, the Run must refuse before any SCR -to- COL promotion and before successor-MAP publication. The inherited RID, current MAP, and existing COL artifacts remain unchanged, and the existing Store remains VALID. Equal N proves cardinality compatibility only; it does not prove source-byte continuity, row-semantic identity, or permission for a different SOURCE to enter the lineage. Exact SOURCE/Store compatibility rules are prior gates. For a new Store, Data Sculptor promotes the validated RID candidate first by host rename that changes only the class token from SCR to RID ; the candidate bytes, shared transaction UTC, RID-specific UUID, and extension remain unchanged. That successful SCR-to-RID promotion is the event that establishes RID_ACTION: CREATED and the published RID_FILENAME fact for the Run. Before that promotion succeeds, the Run has not created a governed RID even if a candidate identity has been allocated. For an existing Store, the inherited RID is reused unchanged and no RID candidate/promotion occurs. Once routing has selected and validated that exact inherited RID, that event establishes RID_ACTION: REUSED and the exact inherited RID_FILENAME ; later refusal does not erase the already-established reuse fact. After the required RID state is established, Data Sculptor promotes each requested COL candidate in deterministic resolved KEEP order by changing only the class token from SCR to COL ; each candidate's bytes, shared transaction UTC, COL-specific UUID, and extension remain unchanged. If RID or COL promotion fails, Data Sculptor must refuse the run and roll any newly promoted RID/COL names back out of their final namespaces where safely possible. Candidate or rollback bytes that cannot be safely restored or removed must be retained visibly as non-authoritative SCR failure evidence. The existence of an unreferenced RID- or COL-looking file after interruption does not by itself make that artifact committed Store state. After all required RID/COL promotions succeed, Data Sculptor allocates a MAP-specific UUID before opening the complete successor-MAP SCR candidate. That candidate uses the same publication-transaction UTC, the allocated MAP UUID, and the final .csv extension, and is constructed using the exact final RID/COL filenames. It is closed successfully, reopened, and validated completely while it remains SCR . Only then may the MAP candidate be promoted by changing only the class token from SCR to MAP ; its bytes, UTC, UUID, and extension remain unchanged. The successful SCR -to- MAP rename is the materialization commit point. Until that commit point, the prior valid MAP remains authoritative for an existing Store; for a new Store, no committed Store state exists yet. If MAP validation or MAP rename fails, Data Sculptor must refuse and roll the newly promoted RID/COL set back out of the final namespaces where safely possible; otherwise affected bytes remain attributable recovery evidence and are not committed Store membership. Governed Store membership/current state is established by a valid MAP binding, not by a final-class filename or timestamp equality alone. Revision BB preserves the Revision AY staging/promotion mechanics and Revision AZ shared transaction-UTC rule for newly published RID/COL/MAP artifacts. Selected-folder support for the canonical governed filename/path form is established by the Suitcase Validation Certificate under W002-STOR-022 through W002-STOR-022.3 rather than by a frozen numeric host path-length table. Operation-specific host rename or publication failure remains a governed refusal under this requirement and is not pre-certified by Suitcase validation. F-14 shared candidate grammar, reconciled by F-33: every RID/COL/MAP SCR candidate in this transaction follows W002-STOR-023.1: its SCR name already carries the UTC, UUID and extension intended for the final RID/COL/MAP identity, and successful promotion changes only the class token. Any retained SCR candidates after a handled publication/rollback failure remain visible non-authoritative failure evidence under W002-STOR-023.1 and are reported through the governed diagnostic/Help path; WASM-002 does not emit an RCV manifest. An orphaned SCR remains non-authoritative even if its bytes later validate.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.7,Successful materialization publishes one complete Store MAP,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"A successful governed materialization that creates one or more COL artifacts must also publish exactly one new complete immutable Store MAP under W002-STOR-019 through W002-STOR-019.12. For a new Store, that MAP binds the automatically generated and promoted RID to the Store metadata and all newly materialized COL mappings. For an existing Store, it preserves the inherited RID binding and complete prior Store state while applying the successful materialization updates. All required RID/COL SCR candidates must complete and validate before promotion begins. On a new Store, RID promotion occurs first; on an existing Store, the inherited RID is reused unchanged. All requested COL promotions must then succeed before successor-MAP candidate construction begins. The complete successor MAP is written as SCR , closed, reopened, and fully validated before entering the MAP namespace. Its final host rename from SCR to the governed MAP filename occurs last and is the materialization commit point. The materialization run is not reported as successfully committed until that MAP rename succeeds. If MAP candidate validation or MAP rename fails after RID/COL promotion, the run must refuse and the newly promoted artifacts must be rolled back out of their final namespaces where safely possible. Any failure residue that cannot safely be removed or restored is governed by W002-STOR-023.1 and remains non-authoritative retained failure evidence; its survival must not be used to infer or manufacture attribution or to simulate the failed publication step. The prior valid MAP remains authoritative for an existing Store; no committed Store is established for a first materialization without a valid successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.8,Stage 2 enforces deterministic source-record shape,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The parsed header establishes the expected source field count. Every nonblank logical data record must contain exactly that many fields after CSV parsing. A nonblank ragged record with fewer or more fields must refuse rather than pad, truncate, or shift later values. An explicit empty field is valid data and preserves its ordinal. A bare blank logical data record occurring outside a quoted field must refuse and must not be silently skipped or converted into one empty field. A physical blank line inside a valid quoted multiline field is field content, not a blank record. F-06 canonical malformed-CSV refusal facts Every structural CSV refusal records these governed facts: REFUSAL_CONDITION
SOURCE_BYTE_OFFSET
PHYSICAL_LINE
LOGICAL_RECORD
FIELD_ORDINAL SOURCE_BYTE_OFFSET is the zero-based absolute byte offset from the first physical byte of the source file. A leading UTF-8 BOM, when present, occupies offsets 0–2 and therefore counts in subsequent absolute byte locations. PHYSICAL_LINE is one-based and equals one plus the number of LF bytes strictly before the governed refusal location. LF bytes inside quoted multiline fields still increment physical-line count. LOGICAL_RECORD is one-based CSV logical-record ordinal and includes the header as logical record 1. The first data record is therefore logical record 2. FIELD_ORDINAL is the one-based field position within that logical record. These facts describe the same first structural refusal regardless of permitted streaming-window size or boundary placement. Canonical structural refusal tokens The seven frozen F-06 malformed-CSV tokens are: UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD
INVALID_BYTE_AFTER_CLOSING_QUOTE
BARE_CR_OUTSIDE_QUOTED_FIELD
EOF_INSIDE_QUOTED_FIELD
BLANK_LOGICAL_RECORD
TOO_FEW_FIELDS
TOO_MANY_FIELDS P3-09 adds NO_HEADER_RECORD as the eighth governed Stage-2 structural CSV refusal token. Parser-library names, host exceptions, crate-specific error enums, or localized descriptions must not replace these governed tokens. Governed refusal location by condition Condition Governed refusal location UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD Offset of the offending "" byte. INVALID_BYTE_AFTER_CLOSING_QUOTE Offset of the first prohibited byte after the closing quote. BARE_CR_OUTSIDE_QUOTED_FIELD Offset of the CR byte itself. EOF_INSIDE_QUOTED_FIELD One-past-end offset, equal to the physical source byte length. BLANK_LOGICAL_RECORD First byte of the record terminator that proves the blank record: LF for LF termination; CR for CRLF termination. TOO_FEW_FIELDS First byte of the record terminator that closes the short record; at EOF, one-past-end offset equal to source byte length. TOO_MANY_FIELDS The comma delimiter that begins the first field beyond the expected header width. NO_HEADER_RECORD One-past-end offset equal to the exact physical source byte length, with physical line 1, logical record 1, and field ordinal 1, as frozen by W002-MAT-001.7. Field ordinal rules For TOO_FEW_FIELDS , FIELD_ORDINAL is the first missing field ordinal: expected-width position immediately after the last field actually present. For TOO_MANY_FIELDS , FIELD_ORDINAL is the first extra field ordinal: header-width + 1. For quote/CR/EOF structural conditions, FIELD_ORDINAL is the current field ordinal in which the malformed condition is established. For BLANK_LOGICAL_RECORD , FIELD_ORDINAL is 1. For NO_HEADER_RECORD , FIELD_ORDINAL is 1. Bare CR scope A bare CR outside a quoted field is malformed CSV and refuses with BARE_CR_OUTSIDE_QUOTED_FIELD . CR inside a valid quoted field is ordinary field content. LF inside a valid quoted field is ordinary field content. CRLF inside a valid quoted field is ordinary field content. Outside quoted fields, CRLF is one accepted logical-record terminator and LF is one accepted logical-record terminator. Outside quoted fields, a CR not immediately followed by LF is malformed. EOF while quoted If EOF is reached while the parser remains inside an open quoted field, the source refuses with EOF_INSIDE_QUOTED_FIELD . Data Sculptor must not synthesize a closing quote, truncate the field, reinterpret prior bytes as unquoted content, or otherwise repair the source. First-condition precedence Stage 2 evaluates structural CSV input in absolute source-byte order and reports the earliest refusal condition that becomes deterministically established. CSV grammar errors take precedence over later row-shape errors. BLANK_LOGICAL_RECORD takes precedence over TOO_FEW_FIELDS for a physically blank logical record. BARE_CR_OUTSIDE_QUOTED_FIELD takes precedence over INVALID_BYTE_AFTER_CLOSING_QUOTE when the post-quote offending byte is a CR that is not followed by LF. At EOF while still inside a quoted field, EOF_INSIDE_QUOTED_FIELD takes precedence over field-count evaluation. No implementation may choose a different error merely because of parser buffering, window boundaries, library behavior, or host platform. Delimiter boundary Comma remains the only WASM-002 field delimiter. Automatic delimiter detection is outside the WASM-002 CSV contract. A file whose rows contain semicolons, tabs, or other non-comma separators may still be valid under the comma-only grammar as a one-column CSV. Data Sculptor must not invent a malformed-CSV refusal merely because another application would treat those bytes as delimiters. When a requested HEADER cannot be resolved, Help may explain that WASM-002 uses comma as the CSV delimiter and that semicolon/tab exports may therefore be interpreted as one field per row. Interaction with UTF-8 diagnostics This structural CSV refusal oracle applies only after the source has passed the applicable encoding-certification boundary. Invalid UTF-8 remains governed by the separately frozen UTF-8 diagnostic contract. Its zero-based absolute source-byte orientation is intentionally aligned with SOURCE_BYTE_OFFSET so WASM-002 does not have competing byte-coordinate systems.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.9,Unselected field contents are not retained,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 must parse every field sufficiently to preserve CSV structure, field count, row boundaries, and governed safety checks, but it must not retain complete contents for unselected fields after those bytes are no longer structurally needed. The engine must not materialize a complete source row, complete table, or complete unselected column in memory merely to emit selected columns. Selected-field content may use bounded accumulation required by the frozen field-size/output rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.10,Individual decoded CSV fields are limited to 16 MiB,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"WASM-002 carries forward the established Data Sculptor field-buffer safety boundary: an individual CSV field may contain at most 16 MiB (16,777,216 bytes) of decoded UTF-8 field content. This is an engineering safety limit, not a semantic statement about CSV or an Excel cell limit. The limit must be enforced incrementally for header and data fields. The parser must not first accumulate an arbitrarily large field and then check it. If a field would exceed the limit, the run must refuse without truncating, repairing, discarding the remainder, or finalizing the candidate materialization. For an unselected field, Data Sculptor may count decoded field bytes without retaining the field value; the safety limit still applies so malformed unterminated fields cannot turn the structural scan into unbounded growth. F-20 operational column-name boundary: after an exact source header field is decoded, Data Sculptor measures its length in Unicode scalar values, not UTF-8 bytes or grapheme clusters. If the exact decoded source header contains at most 1,024 Unicode scalar values, its operational column name is that exact header text. If it contains more than 1,024 scalar values, the operational column name begins from the deterministic physical-ordinal fallback Column <LETTERS> , where the letters are the Excel-style 1-based source ordinal ( A through XFD for the WASM-002 width bound). This operational name is a bounded human-facing/default-alias construct; it does not replace or truncate the authoritative exact source header.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.11,Materialized COL artifacts use canonical one-column UTF-8 CSV serialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Each finalized materialized COL artifact is a one-column CSV. It begins with exactly one UTF-8 BOM ( EF BB BF ) and uses LF ( 0x0A ) as the record terminator on every supported host. The first logical record contains the exact decoded source header text for that physical source column; an alias assigned with AS lives in the governed MAP and does not rewrite the physical COL header. A deliberately empty source header is serialized as one explicit empty header field rather than as absence of a header record. Header and data fields use deterministic minimal CSV quoting: quote when the field contains comma, double quote, CR, or LF; double embedded double quotes; otherwise write the field without quotes. Embedded CR/LF that belong to a quoted field remain field content. For a one-column data record whose decoded value is the empty string, serialize the value explicitly as """" so the row cannot be confused with a bare blank logical record. For fixed source bytes and fixed governed semantics, changing input/output window boundaries must not change the finalized COL bytes. F-20 source-fidelity rule: the physical COL header record always serializes the exact decoded source header, even when that header exceeds the 1,024 -scalar operational-name boundary and the Store MAP/default alias therefore uses an operational fallback. The fallback name must never be substituted into the COL header record or into the MAP source_header field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003,Stage 2 processes the source through bounded reusable windows,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,Structural materialization must process the certified source through bounded reusable input windows compatible with browser/WASM memory constraints. Source size and row count must not require proportional WASM memory growth.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.1,"The 4 MiB WASM-001b window is a proven reference point, not a frozen production constant",W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The 4 MiB source window used successfully during the WASM-001b browser experiments is an evidence-backed starting/reference size. WASM-002 may tune the production input-window size using benchmark evidence, provided the governed memory budget and all window-invariance requirements remain satisfied.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.2,Changing source-window size or boundary placement must not change results,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"For the same certified source and Work Order, permitted changes in bounded Stage 2 input-window size or boundary placement must not change CSV interpretation, resolved headers/ordinals, accepted row count, row identity, aliases, canonical COL bytes, successor MAP contents apart from newly allocated physical identities/timestamps, or the first deterministic refusal condition. P3-09 window invariance: for a Stage-1-certified source containing no logical CSV record, every permitted Stage 2 window size and boundary placement must produce the same NO_HEADER_RECORD refusal and the same governed location tuple: source-byte offset equal to the exact source byte length, physical line 1, logical record 1, field ordinal 1. F-06 full refusal-oracle window invariance: for the same certified source bytes, changing any permitted Stage 2 input-window size or boundary placement must not change whether the source is accepted or refused; the first REFUSAL_CONDITION ; SOURCE_BYTE_OFFSET ; PHYSICAL_LINE ; LOGICAL_RECORD ; or FIELD_ORDINAL . This applies to every structural CSV refusal governed by W002-MAT-002.8.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.3,CSV structure must survive arbitrary input-window boundaries,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Input-window boundaries may occur between ordinary field bytes, delimiter bytes, quote/escaped-quote pairs, CR/LF record-ending bytes, inside quoted multiline fields, and inside already-certified multi-byte UTF-8 sequences. The Stage 2 parser must preserve equivalent structural meaning across those boundaries.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.4,Cross-window parser state is small and explicit,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 may carry only the bounded state needed to continue the current logical CSV parse, including the current logical row ordinal, current field ordinal, quoted/unquoted state, escaped-quote/quote-transition state as required by the parser, pending CR/LF state, decoded-field byte count, resolved selected-field dispatch metadata, and bounded selected-field/output staging. The parser must not retain previous complete rows or source windows merely because a CSV record crosses a window boundary.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.5,Input-window and output-drain sizes are independent implementation controls,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The source read window, WASM transfer window where applicable, selected-field accumulator bound, and output-drain window are separate controls. One must not be silently treated as the maximum for another merely because an earlier prototype used the same numeric value. Any tuning must preserve the Stage 2 memory, backpressure, byte, and window-invariance contracts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.6,Stage 2 uses direct structural parsing rather than a required structural sidecar,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The WASM-002 baseline performs its Stage 2 work directly from the certified source stream. It must not require a precomputed comma/quote/newline position map, binary structural index, hidden cache, or OPFS sidecar before materialization can proceed. The previously discussed structural-sidecar comparison remains a separate future experiment and must not be introduced into WASM-002 as an unmeasured dependency.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.7,The Stage 2 algorithm is browser-first shared Rust core behavior,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The structural parser, row-count semantics, selector dispatch, canonical field serialization, and bounded output-state machine defined by Stage 2 belong in the shared Rust semantic core proven through the browser/WASM path first. A later native CLI host must call the same governed core rather than reimplementing competing materialization semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001,Conversion is a separate governed operation,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Windows-1252-to-UTF-8 conversion is a distinct governed Work Order operation, separate from UTF-8 certification and separate from analytical materialization. The analyst must explicitly authorize it. The canonical WASM-002 form is: SUITCASE: .
WORK ORDER AS ""Convert legacy source to UTF-8""
SOURCE ""legacy_source.csv""
CONVERT WINDOWS-1252 TO UTF-8 CONVERT WINDOWS-1252 TO UTF-8 is the terminal operation clause. Exactly one SOURCE is permitted. The same WKO must not contain KEEP , MATERIALIZE , Store/RID/COL alias mutation, MAP , Inventory, repair, cataloging, Work Order composition, or another operation terminal clause. F-10 conversion entry precondition Before CONVERT WINDOWS-1252 TO UTF-8 may begin character transcoding, Data Sculptor must validate the complete bound source as strict UTF-8 under the same deterministic whole-source certification rules used elsewhere in WASM-002. If the complete source is already valid strict UTF-8, the conversion refuses as unnecessary and publishes no CVT . Only after complete strict UTF-8 validation reaches governed FAIL may Data Sculptor assess the same complete bound source against the frozen Windows-1252 compatibility mapping. Only a source that fails strict UTF-8 and passes the complete Windows-1252 compatibility assessment may proceed to conversion. A failed analytical Work Order, UTF-8 certification, or materialization never silently invokes this operation. The analyst must explicitly authorize the separate conversion WKO.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.1,A failed analytical Work Order must not automatically invoke conversion.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.2,The user must explicitly choose or submit the separate conversion task.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.3,The original source file must remain unchanged.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.4,Successful conversion must create a new UTF-8 artifact with its own governed identity and receipt/evidence.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002,Windows-1252 compatibility assessment,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"After strict whole-source UTF-8 certification returns FAIL , the current analytical operation remains refused and Stage 2 must not start. As refusal handling, Data Sculptor performs one separate read-only Windows-1252 compatibility assessment from physical byte offset 0 of the same run-local bound source instance. The compatibility assessment scans the complete source sequentially under W002-CONV-002.1 through W002-CONV-002.5. It does not transcode, publish a CVT, modify the analyst-owned source, resume materialization, or claim that Windows-1252 is the historical encoding. Its sole governed result is whether the entire byte stream is mappable by the frozen WASM-002 Windows-1252 converter. If strict UTF-8 certification returned PASS , or did not reach a governed FAIL conclusion, this compatibility assessment is not run. F-10 conversion classification gate The conversion operation itself repeats/executes the complete classification gate on its bound source before transcoding: validate the complete source as strict UTF-8; if strict UTF-8 passes, refuse conversion as unnecessary; only after strict UTF-8 fails, scan the complete source against the frozen Windows-1252 mapping; if any source byte is undefined or unsupported by that mapping, refuse rather than guess; and begin transcoding only when strict UTF-8 has failed and the complete Windows-1252 compatibility assessment has succeeded. An undefined/unsupported Windows-1252 byte is therefore a pre-transcoding compatibility-assessment refusal . No CVT candidate may be represented as successfully converted from a source whose compatibility scan found an undefined byte. The compatibility assessment must not substitute U+FFFD , reinterpret an undefined Windows-1252 byte as ISO-8859-1, or use permissive host/library decoder behavior to make an incompatible source convertible.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.1,Compatibility means that the supported deterministic converter can map the observed source bytes under the frozen Windows-1252 rules.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Compatibility means that every physical source byte can be mapped deterministically by the complete normative WASM-002 Windows-1252 mapping in W002-CONV-002.4 . Successful EOF produces the governed outcome COMPATIBLE . No statistical detector, locale rule, browser guess, replacement character, ISO-8859-1 substitution, best-effort decoder, or PRODUCT-scoped glossary text participates as normative authority in this determination.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.2,Compatibility must not be described as proof that Windows-1252 was historically or authoritatively the file's original encoding.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"COMPATIBLE means only that the complete byte stream is convertible under Data Sculptor's frozen Windows-1252 mapping. It must not be described as proof that Windows-1252 was historically, authoritatively, or intentionally the source file's original encoding.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.3,Bytes undefined by the frozen Windows-1252 mapping must cause the compatibility assessment or conversion task to refuse rather than guess.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"If the compatibility pass encounters a byte that W002-CONV-002.4 defines as undefined, the assessment stops at the first such byte and returns INCOMPATIBLE . Data Sculptor must not substitute a replacement character, reinterpret the byte under another code page, or continue as though conversion were safe. A later explicit conversion Work Order must apply the same complete WASM-002 mapping and the same refusal rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.4,Complete normative WASM-002 Windows-1252 byte mapping,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"This requirement is the complete normative Windows-1252 mapping authority for WASM-002 . It covers all 256 possible byte values. No PRODUCT-scoped glossary entry or host/library decoder is required to interpret compatibility or conversion. 0x00–0x7F Every byte 0x00 through 0x7F maps one-to-one to Unicode U+0000 through U+007F . 0x80–0x9F Byte Windows-1252 mapping Unicode 0x80 EURO SIGN U+20AC 0x81 UNDEFINED — 0x82 SINGLE LOW-9 QUOTATION MARK U+201A 0x83 LATIN SMALL LETTER F WITH HOOK U+0192 0x84 DOUBLE LOW-9 QUOTATION MARK U+201E 0x85 HORIZONTAL ELLIPSIS U+2026 0x86 DAGGER U+2020 0x87 DOUBLE DAGGER U+2021 0x88 MODIFIER LETTER CIRCUMFLEX ACCENT U+02C6 0x89 PER MILLE SIGN U+2030 0x8A LATIN CAPITAL LETTER S WITH CARON U+0160 0x8B SINGLE LEFT-POINTING ANGLE QUOTATION MARK U+2039 0x8C LATIN CAPITAL LIGATURE OE U+0152 0x8D UNDEFINED — 0x8E LATIN CAPITAL LETTER Z WITH CARON U+017D 0x8F UNDEFINED — 0x90 UNDEFINED — 0x91 LEFT SINGLE QUOTATION MARK U+2018 0x92 RIGHT SINGLE QUOTATION MARK U+2019 0x93 LEFT DOUBLE QUOTATION MARK U+201C 0x94 RIGHT DOUBLE QUOTATION MARK U+201D 0x95 BULLET U+2022 0x96 EN DASH U+2013 0x97 EM DASH U+2014 0x98 SMALL TILDE U+02DC 0x99 TRADE MARK SIGN U+2122 0x9A LATIN SMALL LETTER S WITH CARON U+0161 0x9B SINGLE RIGHT-POINTING ANGLE QUOTATION MARK U+203A 0x9C LATIN SMALL LIGATURE OE U+0153 0x9D UNDEFINED — 0x9E LATIN SMALL LETTER Z WITH CARON U+017E 0x9F LATIN CAPITAL LETTER Y WITH DIAERESIS U+0178 0xA0–0xFF Every byte 0xA0 through 0xFF maps one-to-one to Unicode U+00A0 through U+00FF . Undefined-byte rule The only undefined byte values in this frozen WASM-002 mapping are exactly 0x81 , 0x8D , 0x8F , 0x90 , and 0x9D . Encountering any one of them makes the complete compatibility assessment INCOMPATIBLE at the first such byte and causes an explicitly run conversion Work Order to refuse before transcoding rather than guess. These three ranges plus the 32-position table above exhaust the byte domain 0x00–0xFF . No unlisted byte value exists.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.5,The compatibility check must itself be bounded and deterministic.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"The compatibility check is one bounded-memory deterministic sequential pass from physical source byte offset 0 to EOF unless the first undefined Windows-1252 byte is encountered earlier. Buffer/window size must not change the compatibility outcome or the first undefined-byte offset. On INCOMPATIBLE , WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET is the zero-based absolute physical source-byte offset of the first undefined byte. On COMPATIBLE , that offset is NOT_APPLICABLE . If the assessment begins but an independent read/host failure prevents a governed compatibility conclusion, the outcome is NOT_AVAILABLE and the first-undefined-byte offset is NOT_AVAILABLE . The assessment itself publishes no converted output.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003,Help suggestion after failed UTF-8 certification,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Help may suggest the separate CONVERT WINDOWS-1252 TO UTF-8 Work Order only when the governed engine emits DS-CNV-001 after a complete compatibility assessment returned COMPATIBLE . The suggestion is therefore derived from a governed diagnostic fact, not from the UTF-8 failure itself. If the assessment returns INCOMPATIBLE , is NOT_AVAILABLE , or did not run, DS-CNV-001 is not emitted and Help must not invent the conversion recommendation. P3-08 Help disclosure: when conversion succeeds, Help must state that the published CVT is a new governed source artifact with its own source identity and that converting a refreshed legacy source later will publish another distinct CVT rather than refresh an earlier CVT-backed Store lineage. When a CVT is selected for first materialization, Help must disclose the same consequence before or with the normal materialization guidance: the Store lineage is anchored to the exact CVT filename, not to the analyst-owned pre-conversion filename. Help must not imply hidden lineage continuity across separate CVT artifacts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.1,The suggestion must state that the current analytical task has stopped.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must state that the current analytical task has already stopped/refused because strict UTF-8 certification failed. DS-CNV-001 is informational and must not be rendered as though materialization can continue from the failed run.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.2,The suggestion must state that the original source has not been changed.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must state that the compatibility assessment was read-only and that Data Sculptor did not change the analyst-owned source. Any later successful conversion publishes a separate governed CVT artifact rather than editing the original source in place.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.3,"The suggestion must describe the source as compatible with the supported Windows-1252 converter, not definitively identified as Windows-1252.",W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must describe the complete source as compatible with Data Sculptor's supported Windows-1252 converter . It must not say that the source was definitively identified as Windows-1252 or imply provenance that the compatibility pass cannot prove.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.4,The suggestion must make clear that conversion is a separate user-authorized task.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"The suggestion must make clear that conversion is a separate user-authorized Work Order. next_action: RUN_WINDOWS_1252_CONVERSION means that the separate operation is a governed safe option; it is not permission for Data Sculptor to silently transcode, modify the source, or reinterpret the refused analytical Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.5,"If the bytes are not compatible with the supported converter, Help must not recommend Windows-1252 conversion as though it were safe.",W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"If the compatibility outcome is INCOMPATIBLE , NOT_AVAILABLE , or NOT_RUN , Help must not recommend Windows-1252 conversion as though it were safe. In particular, the mere presence of DS-ENC-001 never authorizes that recommendation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004,Canonical conversion output,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"A successful Windows-1252 conversion task must produce canonical UTF-8 output suitable for later submission to the normal UTF-8 certification and materialization path. P3-08 lineage consequence: the successful conversion output is a new immutable governed CVT artifact with its own exact physical filename. That CVT filename is the source identity used by later Store routing. A later conversion, including one made from a refreshed analyst-owned legacy source with the same original filename, publishes a different CVT and therefore does not refresh, replace, or continue an earlier CVT-backed Store lineage merely by name association. On first materialization, each distinct CVT begins a new Store lineage unless that exact CVT filename already routes to an existing lineage under the normal Store rules. F-14 CVT identity and publication: the final converted-source filename is exactly __DS__CVT__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv . Conversion writes first to the corresponding W002-STOR-023.1 SCR identity with the same UTC, UUID and .csv extension. Only after bounded conversion completes, the candidate closes/reopens successfully, and the converted bytes satisfy the governed strict UTF-8 requirement may the class token be renamed to CVT . CSV structural interpretation remains governed by the later normal certification/materialization path; CVT publication does not assert that the converted source is structurally valid CSV. F-10 conversion semantics — encoding conversion only The conversion operation performs deterministic character transcoding only. It does not parse, repair, normalize, or reinterpret CSV structure. Commas remain commas. Double quotes remain double quotes. Ordinary ASCII bytes retain the same byte value. LF remains LF. CR remains CR. CRLF remains CRLF. Embedded CR/LF bytes are preserved in place; the converter does not decide whether they are record terminators or field content. Canonical UTF-8 output therefore means deterministic UTF-8 encoding of the accepted source characters, not normalization of line endings, quoting, delimiters, records, headers, or fields. F-10 BOM rule The published CVT is UTF-8 without a BOM ; Data Sculptor does not prepend EF BB BF . If the source failed strict UTF-8 classification, a leading source byte sequence EF BB BF is not blindly stripped as though it were a UTF-8 BOM. Under the Windows-1252 conversion path those source bytes are source data and are mapped according to the frozen Windows-1252 mapping. BOM interpretation remains subordinate to encoding classification rather than acting as a blind prefix-removal rule.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-010; CP-011,"CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open; CP011 T-ACCEPTED, GIT BANKED — CVT-to-SCR lexical staging-name pairing only; complete conversion requirement remains open",b7c515faa9bd000369d7656e09437310261290ae; e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,"Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived); Evidence/CP-011/CP011_Scope_Lock.txt; Evidence/CP-011/CP011_RED_Test_Output.txt; Evidence/CP-011/CP011_GREEN_Test_Output.txt; Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt; Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt; Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt; Evidence/CP-011/CP011_Hash_Inventory_Verification.txt; Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt; Evidence/CP-011/CP011_Closing_Git_Review.txt; CP011_Git_Banking_Output.txt (post-commit, separately preserved)","CP010 Day066 first-touches ONLY the F-14 canonical final CVT output filename grammar subconstraint: is_governed_cvt_source_filename_candidate(&str)->bool recognizes exact canonical __DS__CVT__<UTC>__<UUIDv4>.csv lexical form by reusing existing envelope validation. Four targeted tests + 40/40 full native regression PASS; wasm32-target build PASS; T accepted and banked b7c515faa9bd000369d7656e09437310261290ae. No encoding conversion, SCR creation, close/reopen, UTF-8 validation, CVT publication, immutable physical output, source authority, or CSV structural checks; entire W002-CONV-004 remains PARTIAL, independently unreviewed. CP011 Day066: public pure helper build_scr_candidate_filename_for_cvt(&str)->Option<String> accepts an exact canonical governed CVT .csv filename (via CP010 recognizer) and derives the paired SCR filename by substituting only class token CVT -> SCR, preserving exact UTC, UUIDv4 and lowercase .csv bytes; rejects wrong classes, paths, whitespace, malformed clock/date/UUID, extension and class case. Six targeted tests; RED expected E0432 exit 101; GREEN 6/6; post-format native regression 46/46; rustfmt recheck PASS; Rust 1.97.1 wasm32-unknown-unknown --lib build PASS; original 28/28 and combined 36/36 SHA-256 records verified. Two local scoped .gitattributes whitespace exceptions preserve Rustfmt/Git diagnostic TXT bytes; final Git staged check PASS. T-approved and Git banked e84ae5baeee05f9d5d30284c65b86eebba3c0f6a, 27 committed files, working tree clean. Lexical candidate-name pairing ONLY; no SCR creation, bytes, converter, transaction, close/reopen, validation/publication, retained SCR adoption, SOURCE authority or browser execution. Independent Claude implementation QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.1,The converted artifact must itself be certifiable as UTF-8.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.2,The conversion Receipt identifies the governed source encoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for a successful governed Windows-1252-compatible conversion must identify exactly SOURCE_ENCODING: WINDOWS-1252-COMPATIBLE . That operation-specific fact is carried within the canonical TXT Receipt governed by W002-RCP-001 through W002-RCP-010. Only that exact serialized spelling is permitted for this key/value pair.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.3,The conversion Receipt identifies the materialized UTF-8 encoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for a successful governed conversion must identify exactly MATERIALIZED_ENCODING: UTF-8 . This uses the canonical KEY: VALUE serialization frozen by W002-RCP-005. MATERIALIZED_ENCODING=UTF-8 is not valid canonical Receipt serialization.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.4,The conversion Receipt identifies bounded streaming transcoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for successful conversion must identify that transcoding was performed under the governed bounded/streaming conversion contract.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.5,No analytical column materialization occurs as part of this conversion operation.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001,Canonical diagnostic truth,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every governed user-visible failure or warning produced by WASM-002 must originate as a canonical diagnostic event. A diagnostic event must have a stable identity and structured facts independent of its final wording. Governed success/status events that participate in the Help/status/evidence system—such as a successfully saved Work Order or a successfully validated Suitcase—are canonical INFO diagnostic events and obey the same identity/fact/behavior contract. Ordinary static labels, headings, decorative copy, and presentation-only status text are not automatically diagnostics merely because they are visible in the UI.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.1,Canonical diagnostic IDs use the frozen DS-<DOMAIN>-<NNN> grammar,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry one stable identifier using the exact form DS-<DOMAIN>-<NNN> . DOMAIN is exactly three uppercase ASCII letters A through Z. NNN is exactly three decimal digits, zero-padded, in the range 001 through 999 . Examples include DS-ENC-001 , DS-WKO-001 , DS-STO-001 , DS-MAT-001 , and DS-HLP-001 . A diagnostic ID is permanent after allocation and must never be reused for a different diagnostic meaning. Severity, host, build/release, source filename, path, UUID, byte offset, row/column number, count, timestamp, occurrence ID, and other run-specific facts must not be encoded into the diagnostic ID; those values belong in structured diagnostic fields. The identifier is the canonical lookup key used by the Help message catalog. Day 060 H-04 pre-freeze identifier normalization: the Windows-1252 compatibility suggestion diagnostic is DS-CNV-001 . It follows the same exact three-letter DOMAIN grammar as every other diagnostic ID. No four-letter DOMAIN exception exists in the current WASM-002 contract. Any pre-H-04 draft spelling of this diagnostic is superseded and is not valid build-registry input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.2,Diagnostic severity uses one exact token set,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry exactly one severity token: INFO , WARNING , or ERROR . Severity classifies the condition for human and machine interpretation. It does not itself determine whether execution continues or refuses; that authority is carried separately by the canonical behavior field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.3,Diagnostic phase uses a stable uppercase token,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must identify the governed operation or phase using an uppercase ASCII snake-case token matching [A-Z][A-Z0-9]*(?:_[A-Z0-9]+)* . Examples include WORK_ORDER_VALIDATION , SOURCE_CERTIFICATION , MATERIALIZATION , STORE_PUBLICATION , and HELP_REPORT . These examples do not constitute a closed global phase list; the fixed phase for each allocated diagnostic is declared by that diagnostic's registry entry.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.4,Structured diagnostic facts are declared per diagnostic,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The canonical event carries diagnostic-specific evidence in a structured facts object. Fact keys use lowercase ASCII snake case matching [a-z][a-z0-9]*(?:_[a-z0-9]+)* . Each diagnostic registry entry declares disjoint required_facts and optional_facts sets. Every required fact must be present when that diagnostic is emitted. An optional fact key may be omitted when that fact is not emitted for the event, but omission itself has no governed absence-state meaning : it must not be interpreted as NONE , NOT_RUN , NOT_AVAILABLE , NOT_APPLICABLE , false , zero, or an empty string. An emitted fact key that is not declared for that diagnostic is invalid. For structured JSON diagnostic facts, an established ordinary value retains its native JSON type. When a present diagnostic fact must express one of the shared governed absence states, its value is the exact JSON string ""NONE"" , ""NOT_RUN"" , ""NOT_AVAILABLE"" , or ""NOT_APPLICABLE"" , with the meaning frozen by F-18. JSON null is not a generic encoding for diagnostic-fact absence; it is permitted only where a specific JSON schema explicitly declares a nullable field and defines what that null means, as W002-HELP-009 does for HLP lineage. A required diagnostic fact may not be silently omitted, defaulted, converted to null , guessed, or replaced by a Help-layer value. If Data Sculptor attempts to establish a registered diagnostic but cannot produce one or more facts declared required for that diagnostic, the intended diagnostic is not emitted . Instead the engine emits DS-HLP-001 under W002-HELP-001.8. The replacement event records the intended diagnostic ID and the complete sorted set of missing required fact names. No partially populated copy of the intended diagnostic may be presented beside it. This fail-closed substitution is a diagnostic-contract integrity rule, not a presentation fallback. It preserves the F-17 boundary that diagnostics own facts and Help renders only complete governed diagnostic truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.5,Execution behavior is explicitly CONTINUE or REFUSE,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry exactly one execution-behavior token: CONTINUE or REFUSE . This field is the governed continue/refuse decision for the event. Help wording, severity, UI color, or presentation must not independently weaken, strengthen, or reinterpret it.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.6,Safe next action uses a stable token rather than Help prose,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry a next_action token using uppercase ASCII snake case matching [A-Z][A-Z0-9]*(?:_[A-Z0-9]+)* . NONE is the canonical value when no safe governed next action applies. The token expresses stable machine-readable intent; Casual, Office Speak, and Technical wording for that action belongs to the Help layer. Run-specific values such as timestamps, paths, UUIDs, byte offsets, filenames, counts, or occurrence IDs remain structured facts and do not change the diagnostic identity or fixed next-action meaning. Damaged-Store guidance is part of the safe-next-action contract. When ordinary materialization refuses because exact source routing identifies an INVALID Store lineage, or a DEGRADED lineage whose every mapped COL is broken and therefore cannot be reduced to a non-empty successor by REPAIR MAP , the selected Help voice must preserve the same frozen choices and consequences rather than inventing a recovery operation. The explanation must identify the blocked lineage/current MAP and distinguish: external restoration under the original governed physical filename followed by the required governed validation tier; source rename to deliberately begin a separate new Store lineage; and analyst retirement of the damaged lineage by moving all of that lineage's Store MAPs out of the active Suitcase root. For retirement, Help must warn that moving only the latest MAP can expose an older structurally valid MAP as current. Help must not claim that matching the original filename proves historical byte identity, and must not describe any of these analyst filesystem actions as Data Sculptor-authored repair, deletion, RID regeneration, or silent lineage replacement. P3-07 malformed-MAP routing guard: when ordinary materialization refuses because no routable Store lineage can be established while one or more structurally malformed Store-MAP-class artifacts are present in the active Suitcase, Help must identify the malformed MAP artifact or artifacts and state that new-Store/RID creation was blocked to prevent a silent lineage fork. Help must not describe the missing structurally valid MAP as proof that the prior Store never existed, and must not invent a Data Sculptor repair or replacement operation for this condition. P3-10 delimiter-hint clarification: when Stage 2 refuses with INVALID_BYTE_AFTER_CLOSING_QUOTE and the offending byte is semicolon ( 0x3B ) or horizontal TAB ( 0x09 ), Help may include the governed delimiter-mismatch hint even though the refusal occurred before header-delimiter resolution. The hint is explanatory only: it must not change the canonical refusal condition, location facts, behavior, or safe-action boundary. F-16 conversion-suggestion boundary: strict UTF-8 refusal diagnostic DS-ENC-001 has fixed next_action: NONE . UTF-8 failure alone does not establish that any converter is safe. Only the separate compatibility diagnostic DS-CNV-001 , emitted after the complete governed Windows-1252 compatibility assessment returns COMPATIBLE , may carry next_action: RUN_WINDOWS_1252_CONVERSION . That token identifies a safe separately authorized option; it never resumes or rewrites the refused analytical Work Order. Day 060 H-12 damaged-lineage diagnostic binding ordinary MATERIALIZE refusal for a routed INVALID Store uses DS-MAT-014 and its declared facts; ordinary MATERIALIZE refusal for a DEGRADED Store whose every mapped COL is broken uses DS-MAT-015 and its declared facts; the no-routable-lineage / malformed-Store-MAP guard uses DS-MAT-016 and its declared facts. These specialized allocations are what permit closed-world Help to identify the blocked lineage/current MAP or malformed MAP artifacts without adding unrelated facts to the ordinary DS-MAT-010 validation diagnostic. Day 060 H-26 / BM-09 ordinary DEGRADED routing binding. When ordinary MATERIALIZE exact-source routing identifies a DEGRADED Store whose RID is valid and at least one mapped non-RID COL remains valid, the refusal uses DS-MAT-017 . Its fixed next_action is RUN_REPAIR_MAP because REPAIR MAP is the safe governed Store mutation for this repairable DEGRADED state. Help must use the diagnostic's declared current_map_filename as the exact MAP identity the analyst must name in the separate governed REPAIR MAP Work Order. The token does not run repair automatically and does not mutate the refused MATERIALIZE Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.7,"The governed engine emits the diagnostic semantic core, not voice-authored prose",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The shared Rust/WASM diagnostic path must provide the canonical semantic core required by Help: diagnostic_id , severity , phase , behavior , facts , and next_action . The fixed values and permitted fact-key sets for an allocated diagnostic are governed by diagnostics.json . Casual, Office Speak, and Technical prose belongs to the Help rendering layer rather than being duplicated as authored message sets inside the governed engine. Host/build/occurrence metadata may be carried by surrounding governed execution evidence, but it must not redefine the diagnostic semantic core. F-16 closed-world Help rule: Help may recommend the WASM-002 Windows-1252 conversion Work Order only when the governed engine emitted DS-CNV-001 . Help must not infer compatibility from DS-ENC-001 , byte appearance, file extension, locale, browser behavior, heuristic encoding detection, or prose outside the diagnostic facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.8,diagnostics.json is the canonical WASM-002 diagnostic registry build resource,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The human-inspectable development/build source for the WASM-002 diagnostic registry is exactly diagnostics.json , encoded as UTF-8 without BOM. It is Data Sculptor product/build content, not a Suitcase artifact; it must not use the __DS__ namespace, consume an artifact-class token, or be copied into an analyst's Suitcase merely because Data Sculptor runs. The top-level JSON object has exactly two fields: registry_version and diagnostics . registry_version is the string ""1"" . diagnostics is an array written in ascending UTF-8 byte order of diagnostic_id . Each diagnostic entry has exactly seven fields: diagnostic_id , severity , phase , behavior , next_action , required_facts , and optional_facts . Diagnostic IDs must be unique and satisfy W002-HELP-001.1. Severity, phase, behavior, and next-action values must satisfy W002-HELP-001.2 through W002-HELP-001.6. required_facts and optional_facts are arrays of canonical fact-key strings sorted in ascending UTF-8 byte order; keys must be unique within each array and the two arrays must be disjoint. {
  ""registry_version"": ""1"",
  ""diagnostics"": [
    {
      ""diagnostic_id"": ""DS-CNV-001"",
      ""severity"": ""INFO"",
      ""phase"": ""SOURCE_CERTIFICATION"",
      ""behavior"": ""CONTINUE"",
      ""next_action"": ""RUN_WINDOWS_1252_CONVERSION"",
      ""required_facts"": [""source_filename"", ""windows_1252_compatibility_outcome""],
      ""optional_facts"": []
    },
    {
      ""diagnostic_id"": ""DS-ENC-001"",
      ""severity"": ""ERROR"",
      ""phase"": ""SOURCE_CERTIFICATION"",
      ""behavior"": ""REFUSE"",
      ""next_action"": ""NONE"",
      ""required_facts"": [""first_invalid_byte_offset"", ""source_filename"", ""stop_reason""],
      ""optional_facts"": [""analytical_outputs_published"", ""materialization_started"", ""source_modified_by_data_sculptor"", ""store_state_committed""]
    },
    {
      ""diagnostic_id"": ""DS-HLP-001"",
      ""severity"": ""ERROR"",
      ""phase"": ""DIAGNOSTIC_ASSEMBLY"",
      ""behavior"": ""REFUSE"",
      ""next_action"": ""NONE"",
      ""required_facts"": [""intended_diagnostic_id"", ""missing_required_facts""],
      ""optional_facts"": []
    }
  ]
} The PRD does not need to enumerate every allocated WASM-002 diagnostic row. The complete registry delivered with the build is retained acceptance evidence. A diagnostic ID becomes permanent once allocated and must not later be reused for a different meaning. Build validation must fail on malformed JSON; extra/missing entry fields; duplicate or noncanonical diagnostic IDs; invalid fixed tokens; unsorted, duplicate, overlapping, or invalid fact-key declarations; engine diagnostic definitions whose fixed semantics disagree with the registry; engine diagnostic definitions absent from the registry; Help-catalog IDs absent from the registry; or Help placeholders that name facts not declared as required or optional by the matching diagnostic. F-07 DS-ENC-001 fact mapping: the canonical lower-case diagnostic facts for strict UTF-8 refusal are first_invalid_byte_offset , source_filename , and stop_reason . For this diagnostic, stop_reason is exactly INVALID_UTF8_SEQUENCE . The generic fact name byte_offset is retired for this UTF-8 refusal diagnostic. P2-03 clock-order diagnostic facts: whichever stable WASM-002 Diagnostic ID is allocated to refusal because a successor Store MAP or WKO MAP cannot satisfy the strict monotonic UTC publication guard must declare these exact lower-case required facts in its diagnostic-registry entry: map_profile , observed_host_utc , predecessor_map_filename , and predecessor_utc . map_profile has exactly two permitted values: STORE for a Store-MAP chronology guard and WKO for a Work-Order-registry-MAP chronology guard. These facts identify both the governed MAP profile, the blocking predecessor artifact, and the truthful clock observation that caused refusal. F-16 DS-CNV-001 allocation: DS-CNV-001 is emitted only when the complete read-only compatibility assessment under W002-CONV-002 through W002-CONV-002.5 reaches EOF with outcome COMPATIBLE . Its required fact windows_1252_compatibility_outcome is therefore exactly the JSON string ""COMPATIBLE"" . behavior: CONTINUE means this informational diagnostic introduces no additional refusal; it does not reverse the already-established DS-ENC-001 refusal or resume Stage 2. F-17 DS-HLP-001 allocation: DS-HLP-001 is the canonical fail-safe event when the engine cannot satisfy the complete required-fact contract of an intended registered diagnostic. intended_diagnostic_id is the exact canonical ID that was being assembled. missing_required_facts is a JSON array of every missing required fact-key string, sorted in ascending UTF-8 byte order with no duplicates. The intended diagnostic is suppressed rather than emitted incompletely. DS-HLP-001 always refuses and has next_action: NONE . F-22 QA-independence boundary: diagnostics.json is authoritative for the fixed semantic contract of an allocated Diagnostic ID — its ID, severity, phase, behavior, next action, and permitted required/optional fact keys — but the implementation-delivered registry is not, by itself, an independent oracle proving that every arbitrary runtime condition was mapped to the correct Diagnostic ID. WASM-002 does not require a second QA-owned registry duplicating every implementation allocation. Where this PRD independently freezes a condition-to-diagnostic mapping or exact required facts — including the named DS-ENC-001 , DS-CNV-001 , and DS-HLP-001 contracts and other explicitly pinned diagnostic facts — that PRD text remains normative and acceptance must test the mapping independently of the implementation registry. For allocations not independently pinned by the PRD, WASM-002 accepts the validated build registry as the build allocation while retaining all registry-shape, permanence, semantic-agreement, fact-discipline, and Help cross-validation gates. This is an explicit accepted QA-scope risk, not a claim of independent condition-to-ID verification. Day 060 H-02 fixture-pinned diagnostic allocations The following allocations are normative for the byte-exact Receipt acceptance corpus. They are genuine product diagnostics, not QA-only placeholder IDs. Every row has severity: ERROR , behavior: REFUSE , next_action: NONE , the phase shown below, the listed required facts, and an empty optional_facts array unless another requirement explicitly adds optional facts later. The existing DS-ENC-001 remains the Stage-1 invalid UTF-8 diagnostic and is reused by the H-02 Stage-1 compatibility-state fixtures. Diagnostic ID Severity Phase Behavior Next action Frozen meaning Required facts DS-WKO-001 ERROR WORK_ORDER_VALIDATION REFUSE NONE Work Order validation refuses before one of the seven governed operations can be identified. work_order_filename DS-MAT-010 ERROR MATERIALIZATION_VALIDATION REFUSE NONE Ordinary MATERIALIZE validation/routing refuses before Stage 1 begins after the source reference is established, excluding the specialized damaged-lineage and malformed-MAP routing conditions allocated by Day 060 H-12. source_filename DS-MAT-011 ERROR CSV_DECODING REFUSE NONE MATERIALIZE Stage 2 refuses on a governed structural CSV condition. source_filename csv_refusal_condition csv_source_byte_offset csv_physical_line csv_logical_record csv_field_ordinal DS-MAT-012 ERROR MATERIALIZATION_GATE REFUSE NONE MATERIALIZE post-Stage-2 gate refuses because existing-Store source cardinality does not match the inherited RID cardinality. source_filename base_map_filename rid_filename source_row_count rid_row_count DS-MAT-013 ERROR STORE_PUBLICATION REFUSE NONE MATERIALIZE governed Store-artifact filename identity allocation refuses after collision-retry exhaustion before any new Store artifact becomes authoritative. artifact_class collision_retry_count DS-INV-001 ERROR INVENTORY_VALIDATION REFUSE NONE INVENTORY validation refuses before the inventory scan begins. work_order_filename DS-INV-002 ERROR INVENTORY_SCAN REFUSE NONE INVENTORY scan/measurement refuses for an identified immediate Suitcase entry before a complete snapshot is established. entry_name DS-INV-003 ERROR INVENTORY_PUBLICATION REFUSE NONE INVENTORY governed INV filename identity allocation refuses after collision-retry exhaustion after the snapshot facts are established. artifact_class collision_retry_count DS-ALS-001 ERROR ALIAS_VALIDATION REFUSE NONE UPDATE ALIASES validation/routing refuses before an exact base Store MAP is established. work_order_filename DS-ALS-002 ERROR ALIAS_GATE REFUSE NONE UPDATE ALIASES refuses after the exact base Store MAP is established but before successor publication. base_map_filename DS-ALS-003 ERROR STORE_PUBLICATION REFUSE NONE UPDATE ALIASES successor-MAP filename identity allocation refuses after collision-retry exhaustion. artifact_class collision_retry_count DS-RPM-001 ERROR REPAIR_MAP_VALIDATION REFUSE NONE REPAIR MAP validation refuses before an exact target MAP/RID pair is established. work_order_filename DS-RPM-002 ERROR REPAIR_MAP_ANALYSIS REFUSE NONE REPAIR MAP analysis refuses before a complete repair result is established. target_map_filename DS-RPM-003 ERROR REPAIR_MAP_ANALYSIS REFUSE NONE REPAIR MAP deterministically refuses because every mapped COL is broken and retained COL count is zero. target_map_filename broken_col_count DS-RPM-004 ERROR STORE_PUBLICATION REFUSE NONE REPAIR MAP successor-MAP filename identity allocation refuses after collision-retry exhaustion after repair analysis is established. artifact_class collision_retry_count DS-WKR-001 ERROR WORK_ORDER_REGISTRY_VALIDATION REFUSE NONE REPAIR WORK ORDER REGISTRY validation refuses before the current structurally valid WKO MAP is established. work_order_filename DS-WKR-002 ERROR WORK_ORDER_REGISTRY_REPAIR REFUSE NONE REPAIR WORK ORDER REGISTRY repair-plan/gate processing refuses after the base WKO MAP is established. base_wko_map_filename DS-WKR-003 ERROR WORK_ORDER_REGISTRY_PUBLICATION REFUSE NONE REPAIR WORK ORDER REGISTRY successor-WKO-MAP filename identity allocation refuses after collision-retry exhaustion. artifact_class collision_retry_count DS-CVT-001 ERROR CONVERSION_VALIDATION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 validation/classification refuses before bounded transcoding begins. source_filename DS-CVT-002 ERROR CONVERSION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 refuses after bounded transcoding begins but before publication. source_filename DS-CVT-003 ERROR CONVERSION_PUBLICATION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 CVT filename identity allocation refuses after collision-retry exhaustion after conversion facts are established. artifact_class collision_retry_count DS-CAT-001 ERROR CATALOG_DISCOVERY REFUSE NONE CATALOG STORES validation/discovery refuses before the complete authoritative catalog row set is established. work_order_filename DS-CAT-002 ERROR CATALOG_PUBLICATION REFUSE NONE CATALOG STORES CAT filename identity allocation refuses after collision-retry exhaustion after the complete row set is established. artifact_class collision_retry_count Day 060 H-04 normalization: all allocated Diagnostic IDs in the current WASM-002 contract, including DS-CNV-001 , use exactly three ASCII uppercase letters in DOMAIN . No exception exists. Day 060 H-12 / BM-09 specialized diagnostic allocations The H-02 fixture diagnostics above are intentionally narrow. In particular, publication diagnostics whose required facts are only artifact_class and collision_retry_count mean identity-allocation collision exhaustion , not every possible publication failure. Other publication failures receive distinct registry allocations unless another requirement independently pins their Diagnostic ID. The following additional pre-freeze allocations are normative because existing Help duties require fact contracts that the broad H-02 fixture IDs cannot truthfully carry. Every row has severity: ERROR , behavior: REFUSE , and next_action: NONE except DS-MAT-017 , whose next_action is RUN_REPAIR_MAP . optional_facts is empty unless another requirement explicitly extends it. Diagnostic ID Severity Phase Behavior Next action Frozen meaning Required facts DS-MAT-014 ERROR MATERIALIZATION_ROUTING REFUSE NONE MATERIALIZE is blocked because exact source routing identifies a current INVALID Store lineage whose governed RID is missing or invalid. source_filename current_map_filename rid_filename store_health DS-MAT-015 ERROR MATERIALIZATION_ROUTING REFUSE NONE MATERIALIZE is blocked because exact source routing identifies a DEGRADED Store whose every mapped non-RID COL is missing or invalid, so REPAIR MAP cannot publish a non-empty successor. source_filename current_map_filename rid_filename store_health mapped_col_count broken_col_count DS-MAT-016 ERROR MATERIALIZATION_ROUTING REFUSE NONE New-Store creation is blocked because no routable Store lineage can be established while one or more structurally malformed Store-MAP-class artifacts are visible in the active Suitcase. source_filename malformed_map_filenames DS-MAT-017 ERROR MATERIALIZATION_ROUTING REFUSE RUN_REPAIR_MAP MATERIALIZE is blocked because exact source routing identifies a current DEGRADED Store whose governed RID is valid and whose mapped non-RID COL set contains at least one broken COL and at least one surviving valid COL, so a separate governed REPAIR MAP operation is available. source_filename current_map_filename rid_filename store_health broken_col_count DS-UTC-001 ERROR PUBLICATION_CHRONOLOGY REFUSE NONE A successor Store MAP or WKO MAP publication is blocked because truthful observed host UTC is not strictly greater than the canonical chronology predecessor UTC. map_profile observed_host_utc predecessor_map_filename predecessor_utc Day 060 H-26 / BM-09 allocation: DS-MAT-017 is the ordinary repairable-DEGRADED routing refusal. store_health is exactly DEGRADED ; broken_col_count is the exact number of mapped non-RID COL bindings that fail the applicable Store-health validation at this routing gate and is at least 1 . The condition excludes the all-COLs-broken case allocated to DS-MAT-015 . current_map_filename is the exact current structurally valid Store MAP that a separate REPAIR MAP Work Order must name. RUN_REPAIR_MAP is a safe next-action token only; it never causes automatic repair. Closed-world Help consequence: Help may render the richer damaged-lineage, malformed-MAP, and monotonic-UTC explanations only from the applicable specialized diagnostic event above. It must not borrow undeclared facts from DS-MAT-010 or from a collision-exhaustion publication diagnostic merely because those facts are available elsewhere at runtime. Cross-operation UTC rule: DS-UTC-001 has one stable semantic condition across Store-MAP and WKO-MAP successor publication. The required map_profile fact tells closed-world Help which governed MAP profile encountered the chronology guard: STORE means Store MAP and WKO means Work Order registry MAP. Help must select profile-appropriate explanation and analyst exits only from that declared fact and the other registered event facts; it must not infer the profile from filename shape, surrounding host state, or an undeclared operation field. The shared Diagnostic ID therefore does not need profile-specific clones.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002,Three-voice parity,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help Engine must support the three established Data Sculptor help voices. All three renderings must preserve the same diagnostic truth. Voice selection may change wording, sentence structure, degree of technical detail, and explanatory style. F-24 session default and persistence: Technical is the canonical Help voice at the start of every new browser application instance. The analyst may select Casual or Office Speak during that instance, but WASM-002 retains the selected voice only in volatile runtime state and does not persist the preference in browser-private storage. A new application instance therefore returns to Technical. This default does not alter the F-17 rule that a missing diagnostic-specific catalog entry visibly falls back to Generic Technical Help.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.1,Voice selection must not change diagnostic identity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.2,Voice selection must not change severity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.3,Voice selection must not change counts or evidence.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.4,Voice selection must not change whether execution continues or refuses.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.5,Voice selection must not change safe/unsafe action boundaries.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.6,Voice selection must not change provenance.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.7,Voice selection must not change the meaning of the recommended next step.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Tests must assert parity on the canonical event and structured facts, not brittle equality of prose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.8,One validated Help message catalog is the source of truth for all three voices,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help layer resolves a canonical diagnostic ID through one validated catalog that associates an authored ID with Casual, Office Speak, and Technical templates. The human-maintained development source is exactly help_messages.json , encoded as UTF-8 without BOM. help_messages.json is a Data Sculptor product/build resource, not a Suitcase artifact. It must not use the __DS__ governed artifact namespace, consume a semantic artifact-class token, or be copied into an analyst's Suitcase merely because Data Sculptor runs. Run-specific structured facts remain authoritative in the canonical diagnostic event and are supplied separately to the selected template. The three authored voices must not be maintained as unrelated message stores. F-17 coverage fallback: absence of an authored catalog entry for an otherwise complete registered diagnostic is permitted at run time and does not make the diagnostic incomplete. Data Sculptor must instead render the deterministic Generic Technical Help view defined by W002-HELP-002.9. The fallback consumes only the canonical event semantic core and its emitted governed facts; it is not a second message catalog and does not manufacture replacement diagnostic facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.9,WASM-002 may use mechanically generated placeholder voice text to prove Help wiring,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance does not require the complete production Help corpus. Authored catalog entries may use unmistakable placeholder strings, and placeholder entries may be generated mechanically from the validated diagnostics.json registry; no production prose authorship is required. Deterministic Generic Technical Help fallback. When a complete registered canonical diagnostic has no matching entry in help_messages.json , all selected Help voices fall back visibly to one Generic Technical rendering. The rendering must show, in this exact conceptual order, the diagnostic ID, severity, phase, behavior, next-action token, and then every emitted governed fact ordered by ascending UTF-8 byte order of fact key. It must state that no diagnostic-specific authored explanation is available. It must not infer cause beyond the diagnostic, invent remediation, default missing facts, inspect undeclared external state, or substitute prose for governed fact values. The Generic Technical fallback preserves the original diagnostic unchanged. Catalog incompleteness is therefore distinct from diagnostic incompleteness: a valid event can always be rendered generically, while inability to satisfy the event's own required_facts contract suppresses that intended event and produces DS-HLP-001 under W002-HELP-001.4 and W002-HELP-001.8. Acceptance must prove correct diagnostic-ID lookup, selected-voice resolution, structured-fact interpolation where a template exists, voice switching, deterministic Generic Technical fallback for a deliberately absent catalog entry, and semantic parity across authored voices. Final authored Help wording, examples, editorial polishing, and production-corpus quality remain deferred to a later Help-content milestone.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.10,help_messages.json has one deterministic WASM-002 source schema,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The top-level JSON object has exactly two fields: catalog_version and messages . catalog_version is the string ""1"" . messages is an array written in ascending UTF-8 byte order of diagnostic_id . Each message entry has exactly four fields: diagnostic_id , casual , office_speak , and technical . diagnostic_id must satisfy the canonical DS-<DOMAIN>-<NNN> grammar and must be unique in the catalog. Each voice field is a JSON string. A voice string may contain zero or more structured-fact placeholders using the exact form {fact_name} . Each catalog diagnostic_id must exist in the validated diagnostics.json registry, and each referenced placeholder must be declared in that diagnostic's required_facts or optional_facts . Duplicate IDs, missing voice fields, null voice values, malformed JSON, noncanonical or unregistered diagnostic IDs, or undeclared fact placeholders make catalog validation fail. The catalog is intentionally allowed to be non-exhaustive. A registered diagnostic with no message entry is rendered through the deterministic Generic Technical fallback in W002-HELP-002.9. Therefore a missing catalog entry for a registered diagnostic is not a build-validation failure and must not cause the engine to synthesize an authored entry or suppress the diagnostic. WASM-002 therefore does not require one global exhaustive fact-name table in the PRD. Fact-key authority is per diagnostic: the validated registry declares which fact names are legal for each stable diagnostic meaning. {
  ""catalog_version"": ""1"",
  ""messages"": [
    {
      ""diagnostic_id"": ""DS-ENC-001"",
      ""casual"": ""[CASUAL PLACEHOLDER] {source_filename}"",
      ""office_speak"": ""[OFFICE PLACEHOLDER] {source_filename}"",
      ""technical"": ""[TECHNICAL PLACEHOLDER] {source_filename} {first_invalid_byte_offset} {stop_reason}""
    }
  ]
} Later Help-content revisions may extend or version this schema only through an explicit PRD revision. F-07 placeholder mapping: Help for the strict UTF-8 refusal may render {first_invalid_byte_offset} and {stop_reason} because those exact fact names are declared by the canonical DS-ENC-001 diagnostic registry entry. The older generic {byte_offset} placeholder is not valid for DS-ENC-001. P2-03 Help rendering duty: Help for the monotonic-UTC refusal must identify the exact blocking predecessor MAP and show both predecessor UTC and truthful observed host UTC. It must distinguish an incorrect host clock from a genuinely future-dated governed MAP and may explain the approved analyst-owned choices: correct the clock, wait/rerun after truthful time advances, or deliberately move the exact future-dated current MAP out of the active Suitcase root with the warning that an older snapshot/registry may become current and that restoring the moved MAP may restore its authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.11,The validated Help catalog is embedded into the released HTML build and supplied to the shared core,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Before a WASM-002 browser build is accepted, the build must parse and validate help_messages.json , then serialize the validated catalog directly into the Data Sculptor HTML itself as one non-executable application/json payload with the exact element ID ds-help-catalog . The embedded JSON must be HTML-safe so catalog text cannot terminate the containing script element; at minimum, literal less-than characters in JSON string content must be escaped during embedding. At runtime, the browser host obtains this embedded payload and supplies the validated catalog to the shared Rust/WASM Help core. Browser JavaScript must not implement a competing template-selection, fact-interpolation, fallback, escaping, or HLP-semantic engine. The browser host must not fetch a Help catalog from the network, the filesystem, the Suitcase, or an adjacent deployment file. Missing or malformed embedded catalog JSON, or a build whose embedded catalog does not correspond to the validated build input, is a build-validation failure. The released HTML therefore remains one offline portable front door for the browser Help catalog. A later native host may supply the same governed catalog semantics to the same shared core from its own build-bundled resource; host packaging may differ, but Help semantics must not fork.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003,Message and report outputs,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The Help Engine must support both live and durable help surfaces.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003.1,The Help Engine must support a concise human-facing message suitable for the live browser surface.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The concise message is rendered in the dedicated browser Help / Diagnostic Surface when that surface is present; it is not required to be a modal or transient notification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003.2,"The Help Engine must support a durable HTML Help report using the canonical built-in Data Sculptor presentation suitable for saving with the Work Order, receipt, and output artifacts.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"A concise Help message for an individual diagnostic and any durable Help Report that includes that diagnostic must resolve from the same canonical diagnostic event. A durable Help Report request may cover one active governed diagnostic, including a non-run diagnostic, or one governed run containing one or more canonical diagnostic events. Exactly one HLP is published for each explicit Help Report request.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004,HTML Help report content,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,A saved Help report must be able to include the following elements when relevant.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.1,Product and brand identity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.2,Plain-language summary.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.3,Stable diagnostic ID.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.4,What Data Sculptor observed.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.5,Evidence and structured facts.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.6,What the user can safely do next.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.7,Source/Work-Order context is governed by the HLP disclosure allowlist.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The report may include only source and Work Order context permitted by W002-HELP-010. Durable HLP disclosure is intentionally stricter than transient local Help because the HLP is a portable support-handoff artifact. A relevant governed alias or source header may enter the HLP only under the necessity and disclosure rules in W002-HELP-010. Source-header text is eligible only when Data Sculptor has structurally established an actual CSV header record under the governed parser. Record position alone does not make text a header. When no valid header record has been established, including the headerless-source refusal case, the HLP must use structural evidence such as the 1-based column ordinal, diagnostic condition/location, or an applicable operational fallback name and must not substitute field data from the first data row. Absolute local paths, entire Work Orders, Work Order comments, source rows/values, unrelated headers/aliases/columns, and unrelated Suitcase contents are not automatically eligible merely because they are available to the running application.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.8,Report-generation metadata preserves HLP identity and lineage.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The report must carry its own governed HLP filename and generation UTC together with the diagnostic identity and applicable originating execution lineage. The exact HLP provenance contract is governed by W002-HELP-009.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.9,Selected Help voice and its human-facing explanation.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.10,A clearly labelled structured-facts block derived from the canonical diagnostic event.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.11,Four canonical Boolean facts describe the WASM-002 execution boundary.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When the governed diagnostic context can determine the execution boundary, the canonical fact names are exactly: source_modified_by_data_sculptor materialization_started analytical_outputs_published store_state_committed When one of these facts has an established Boolean value, the JSON/structured value is the native Boolean true or false , never the strings ""TRUE"" or ""FALSE"" . source_modified_by_data_sculptor states only whether Data Sculptor modified the analyst-owned source in place; it must not imply knowledge that no external process or analyst changed the source between sessions. materialization_started records whether the governed analytical materialization phase began. analytical_outputs_published records whether governed analytical outputs were successfully published for user use; transient SCR candidates or abandoned/uncommitted debris do not make this fact true. store_state_committed records whether the successor Store MAP commit point was crossed. If a present boundary fact must express governed absence rather than an established Boolean, its JSON/structured value is the exact applicable shared absence-state string ""NONE"" , ""NOT_RUN"" , ""NOT_AVAILABLE"" , or ""NOT_APPLICABLE"" . JSON null is not a valid encoding for these four boundary facts because it would discard the reason for absence. A boundary fact that is optional for a particular diagnostic may instead be omitted under W002-HELP-001.4; that omission carries no absence-state meaning. A missing, omitted, unavailable, or not-run fact must never be interpreted as false . If one of these facts is declared required for an intended diagnostic and the required value cannot be produced, it must not be silently defaulted; the intended diagnostic is suppressed and the fail-safe DS-HLP-001 contract in W002-HELP-001.4/W002-HELP-001.8 applies.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.12,Governed Work Order lineage sufficient to establish user intent.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,Included lineage must obey the disclosure boundary defined for Help reports and must not automatically expand into source-data disclosure.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-005,Deterministic rendering uses a closed governed input set,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Given the same canonical diagnostic event or ordered set of events, selected voice, PRETTY rules, validated Help catalog, and built-in presentation version, Help rendering must be deterministic except for explicitly permitted event/report-specific fields. The Help renderer may consume only the canonical diagnostic fields and fact keys declared by the applicable diagnostic registry entries plus fields explicitly defined by the applicable HLP provenance schema. It must not inspect or interpolate an open-ended host-state bag, undeclared browser state, unrelated Suitcase contents, or another value merely because it is available at runtime. A future configurable Brand Manifest may add another governed presentation input, but it is not part of the WASM-002 rendering contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-006,Host parity uses one shared Help semantic core,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help Engine must be designed for use by the browser host and the later native CLI host without changing diagnostic semantics. The shared Rust core owns diagnostic-to-template selection, governed fact interpolation, deterministic fallback behavior, governed escaping, and durable HLP semantic serialization. The WASM-002 browser host supplies the validated catalog embedded under W002-HELP-002.11. A later native host may supply the same governed catalog semantics from a build-bundled native resource. Host-specific presentation and packaging may differ, but they must not create a second Help semantic engine or change canonical diagnostic identity, facts, behavior, next action, voice semantics, disclosure policy, or HLP meaning.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-007,"Help surfaces are projections, not diagnostic authority",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The live Help / Diagnostic Surface and the saved HTML Help Report must render from the canonical diagnostic event. Neither surface may independently create, reinterpret, weaken, suppress, or override governed diagnostic truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008,HTML Help Report is a governed support-handoff artifact,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The user must be able to generate a styled, self-contained HTML Help Report from a governed diagnostic event for retention, IT/support handoff, or communication to another analyst. The report must support two audiences in one document: a human-readable explanation using the selected Help voice and a clearly inspectable structured-facts section that preserves the technical evidence required to understand the event.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008.1,"The report preserves the canonical execution-boundary facts, including relevant negative facts.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When relevant to the diagnostic, the report must render the governed values of source_modified_by_data_sculptor , materialization_started , analytical_outputs_published , and store_state_committed . These values originate from governed execution state rather than reassuring prose invented by the renderer. A missing/unavailable fact is not rendered as false .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008.2,The report preserves only the Work Order lineage needed to explain the diagnostic.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The report must identify the originating WKO physical filename when one applies and may include only the minimum executable Work Order clause or clauses needed to establish the governed operation, user intent, and trigger for the diagnostic. It must not automatically embed the entire Work Order or Work Order comments. All such context remains subject to the fixed disclosure boundary in W002-HELP-010.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-009,"WASM-002 establishes HLP identity, lineage, multiplicity, and one canonical embedded provenance payload.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"A durable generated Help Report is an immutable governed HLP artifact whose physical filename is: __DS__HLP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html The UTC token is the HLP's own governed generation/publication time. The report is the final self-contained HTML artifact using the canonical built-in Red5Sorcery/Data Sculptor presentation; no unstyled intermediate is the canonical HLP. Report-request multiplicity: one explicit Help Report request publishes exactly one HLP. The request may be bound to one active governed diagnostic, including a diagnostic that is not associated with a Run, or to one governed Run containing one or more canonical diagnostic events. A Run-level report includes the governed diagnostic events selected by that request in deterministic event order. HLP generation is never an automatic one-artifact-per-diagnostic side effect. Every HLP must expose a visible deterministic Provenance section and exactly one embedded non-executable application/json payload whose element ID is exactly ds-hlp-provenance . F-34 supersedes the earlier draft schema version ""1"" . For schema version ""2"" , the JSON top-level object contains exactly these ten fields: {
  ""schema_version"": ""2"",
  ""hlp_filename"": ""__DS__HLP__20260922T191500123Z__<uuid-v4>.html"",
  ""hlp_generation_utc"": ""20260922T191500123Z"",
  ""diagnostic_ids"": [""DS-ENC-001"", ""DS-MAT-004""],
  ""originating_wko_filename"": ""__DS__WKO__...txt"",
  ""originating_rcp_filename"": null,
  ""selected_help_voice"": ""technical"",
  ""presentation_id"": ""red5sorcery-data-sculptor"",
  ""presentation_version"": ""1"",
  ""data_sculptor_build"": ""<exact-build-id>""
} hlp_generation_utc must use the canonical fixed-width millisecond UTC form YYYYMMDDTHHMMSSmmmZ . diagnostic_ids is a non-empty JSON array containing one canonical diagnostic ID for each diagnostic event included in the report, in the same deterministic event order used by the report. Repeated IDs are permitted when distinct included events legitimately share one diagnostic type. selected_help_voice is exactly one of casual , office_speak , or technical , matching the Help catalog keys. For WASM-002 the built-in presentation identity is exactly red5sorcery-data-sculptor and its presentation version is exactly ""1"" . data_sculptor_build must contain the exact running build identifier used for the tested/released build; the literal scope label WASM-002 alone is not sufficient unless it is also the exact build identifier. originating_wko_filename and originating_rcp_filename are schema-declared nullable lineage fields . When the relationship exists and the exact physical filename is known, the value is that filename as a JSON string. When the relationship itself does not apply to this Help event/report request, the machine-readable value is JSON null . That null has one schema-defined meaning: the nullable relationship has no value, equivalent to Rust Option<T>::None and to the governed semantic state NOT_APPLICABLE . The visible Provenance section renders it as NOT APPLICABLE . If the lineage relationship does apply but the exact filename cannot be obtained, JSON null must not be used; the field value is the exact string ""NOT_AVAILABLE"" and the visible Provenance section renders NOT AVAILABLE . Empty strings, invented lineage, N/A , UNKNOWN , or another substitute are forbidden. For these two lineage fields, null and ""NOT_AVAILABLE"" are deliberately non-interchangeable. A non-run HLP may therefore legitimately carry JSON null for both lineage fields when neither relationship applies. This nullable-field rule is a schema-specific serialization choice, not a fifth absence state and not a generic JSON encoding rule. Other diagnostic JSON facts follow W002-HELP-001.4 and W002-HELP-004.11. The visible and machine-readable HLP provenance must express the same governed semantics even where their physical representations differ; a semantic mismatch is an HLP-generation failure and must not be silently tolerated. The embedded JSON must be HTML-safe so provenance text cannot terminate the containing script element; at minimum literal less-than characters in JSON string content must be escaped during embedding. The provenance payload remains subject to W002-HELP-010 and must not introduce source rows, source values, absolute local paths, arbitrary Work Order content, or other context excluded by the fixed HLP disclosure policy. WASM-002 does not automatically compute or embed a SHA-256 of the HLP, and saving an HLP must not create, refresh, or verify an LCK . The final HLP bytes remain eligible for exact-byte integrity evidence under the later explicit FINGERPRINT/LCK workflow. Configurable Brand Manifest provenance remains deferred to V1-BACKLOG / a future build. F-14 HLP publication: the complete self-contained report is first written as the corresponding SCR candidate under W002-STOR-023.1. It must close, reopen, and validate the required visible Provenance section, exact schema-version-2 embedded JSON shape, HTML-safe serialization, self-contained presentation and visible/machine semantic parity before the class token may be renamed from SCR to HLP . A partial or semantically mismatched candidate never becomes a canonical HLP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-010,Help Report disclosure uses one fixed WASM-002 allowlist.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Generating a Help Report must not silently become a data-export path. WASM-002 therefore uses one deterministic allowlist rather than collecting broad context and attempting to redact it afterward. There are no disclosure checkboxes, permissive export modes, or per-report overrides in WASM-002. Always eligible when present and applicable: diagnostic ID; severity/classification; governed operation/phase; continue/refuse decision; safe next action; selected Help voice; HLP identity and generation UTC; relevant governed artifact filenames; and the four canonical boundary facts from W002-HELP-004.11. Eligible only when necessary to explain the diagnostic: the exact source filename but not an absolute OS path; a relevant source column header only when Data Sculptor has structurally established an actual CSV header record; the relevant 1-based column number; a relevant governed Store/RID/COL alias only when that alias itself is necessary to explain the diagnostic, such as an alias collision, ambiguity, or governed alias mutation; byte offset, row/count, or byte-length evidence; Store/RID/COL/MAP/WKO physical filenames; and only the minimum executable Work Order clause or clauses needed to establish intent and the diagnostic trigger. If that minimum Work Order excerpt necessarily contains a governed alias, that alias is disclosed and counts as alias text included. Headerless boundary: record position alone never establishes a source header. If the governed parser has not established a valid header record, including a headerless-source refusal, HLP generation must not treat any field from the first data row or any later data record as header text. Structural evidence such as 1-based column ordinal, governed diagnostic/location facts, or an applicable operational fallback name must be used instead. Never included automatically: source rows; source field values or arbitrary data samples; field data mislabeled as header text; absolute local paths; unrelated source headers, aliases, or column names; the complete Work Order; Work Order comments; unrelated Suitcase contents; browser/environment internals not governed as diagnostic evidence; or raw ungoverned stack traces. Every generated HLP must contain a visible Disclosure section stating, at minimum: Source rows included: NO ; Source values included: NO ; Source header text included: YES or NO ; Governed alias text included: YES or NO ; Absolute local paths included: NO ; Work Order comments included: NO ; and Work Order excerpt: RELEVANT EXECUTABLE CLAUSES ONLY . The two YES/NO declarations must truthfully reflect the actual HLP bytes. A genuine established source header does not count as a source field value; this distinction applies only after the governed parser has established the header record. The renderer must not weaken any declaration when the underlying policy has not changed. This durable-HLP allowlist does not prohibit transient local Help from showing a relevant governed alias or a genuinely established source header when useful to explain the same canonical diagnostic event. Local presentation does not enlarge what the portable HLP may disclose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011,Help owns the cross-session source-continuity edge-case explanation,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When an unexpected analytical result, row-alignment concern, or support question raises the possibility that an analyst-owned source changed between sessions, Data Sculptor-controlled guidance must flow through the Help Engine. Help must not imply that the engine monitored or cryptographically protected the source when it did not. The explanation must distinguish ordinary analyst-controlled workflow from stronger optional evidence. It may ask whether the analyst edited, replaced, sorted, re-exported, synchronized, copied over, or otherwise changed the source after the Store was established.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011.1,Help presents continuity evidence in explicit assurance levels,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"For a suspected cross-session source change, Help must distinguish at least these evidence levels: No continuity evidence: state that cross-session byte continuity cannot be independently verified from filename/Store metadata alone. INVENTORY available: use filename, exact byte length, and last-modified metadata as lightweight clues; changed metadata may indicate that the source changed, while unchanged metadata must not be presented as proof of unchanged bytes. Explicit fingerprint evidence available: exact-byte SHA-256 evidence may establish whether the compared file bytes match or differ under the later governed FINGERPRINT workflow. Help must not collapse these levels into one generic statement of certainty.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011.2,WASM-002 does not impose automatic cross-session hashing or Suitcase surveillance,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Ordinary WASM-002 materialization and Store inheritance must not automatically SHA-256 the source, recursively fingerprint the Suitcase, or maintain hidden whole-Suitcase surveillance merely to guard against the possibility that an analyst-owned file changed between sessions. This is an intentional product boundary for the lone-office-analyst model. The product assumes the analyst normally controls the Suitcase, provides lightweight explicit INVENTORY evidence in WASM-002, preserves a later explicit FINGERPRINT path for stronger assurance, and relies on Help to explain unusual cross-session continuity questions proportionately. WASM-002 must not create, refresh, or silently verify an LCK Suitcase Lock as a side effect of Work Order save, materialization, Store inheritance, INVENTORY, alias maintenance, or ordinary project use. LCK publication belongs to the explicit later-V1 FINGERPRINT workflow. F-13 single-writer Help boundary: Help must distinguish cross-session continuity from concurrent writing. WASM-002 does not claim that two Data Sculptor tabs/windows can safely write the same Suitcase at once. User guidance must say to use one writing Data Sculptor context per Suitcase; read-only viewing is not itself a governed write. When a pre-commit guard detects that relevant governed state changed underneath an operation, Help must identify the changed authority where available and direct the analyst to refresh or reopen current state and rerun deliberately. It must not imply that Data Sculptor acquired a cross-tab lock, merged the competing work, or automatically rebased the refused transaction.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-001,Separation of truth and presentation,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,The PRETTY Engine must not decide analytical truth or reinterpret diagnostic meaning. It receives governed content and renders it into human-facing artifacts. WASM-002 conceptual boundary: ENGINE TRUTH -> HELP / REPORT CONTENT -> PRETTY ENGINE -> BUILT-IN DATA SCULPTOR PRESENTATION -> ARTIFACT. A future build may replace the built-in presentation source with a governed Brand Manifest without changing the analytical or diagnostic truth supplied to PRETTY.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-002,Shared renderer path,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"The PRETTY Engine must provide a common rendering path for Data Sculptor artifacts that require governed human presentation, including at minimum the WASM-002 Help HTML report. WASM-002 uses the canonical built-in Red5Sorcery/Data Sculptor presentation. The architecture must permit the same path to accept a configurable Brand Manifest in a future build without changing analytical semantics. The architecture must also permit later reuse for branded Receipt HTML, verification reports, tables, Quick Viz, and other PRETTY outputs. WASM-002 canonical run Receipts themselves remain TXT-only under W002-RCP-003.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003,Self-contained HTML,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"Durable HTML artifacts produced by PRETTY must be self-contained for ordinary viewing after generation. Self-containment requires semantic and functional portability, not pixel-identical rendering across operating systems or browsers; ordinary system-font substitution and browser rendering differences are acceptable when meaning, evidence, hierarchy, and accessibility remain intact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.1,A saved artifact must not require a network connection.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.2,A saved artifact must not require an external stylesheet.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.3,A saved artifact must not require a remote font.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.4,A saved artifact must not require a separately located logo file.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.5,A saved artifact must not require external presentation resources.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"Required CSS, SVG, and other built-in presentation assets needed for ordinary viewing must be embedded or otherwise resolved into the generated artifact at creation time. Future configurable Brand Manifest inputs, when implemented, must preserve this self-contained output rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-004,Accessibility and inspectability,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"PRETTY HTML must remain ordinary inspectable HTML. Presentation must not obscure the text, evidence, diagnostic code, provenance, or next-step guidance. The rendered artifact must remain usable without JavaScript when JavaScript is not required for its content.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-QA-001,Governed test-only seams and acceptance coverage,W002-QA,W002-QA,WASM-002,UNDER REVIEW,—,"Every material frozen WASM-002 behavior must have retained acceptance evidence sufficient to exercise the governed success, refusal, mutation, publication, or recovery boundary that makes the behavior meaningful. Related cases may share one fixture when the shared fixture proves each required condition explicitly; acceptance coverage must not rely on a behavior being difficult to reproduce under an uncontrolled host environment. Permitted deterministic test-only seams. WASM-002 acceptance may use controlled clock values; controlled UUID sequences and collision outcomes; controlled filesystem create/write/close/rename/promotion failures; and controlled run-local source-handle reread/substitution conditions. A seam supplies only the external condition required to reach the governed behavior. It must not bypass validation, alter the normative semantic result, change governed serialization, relax publication rules, rewrite diagnostic truth, or create a second analytical execution model. Release boundary. Test-only controls must not be invocable through the ordinary Data Sculptor UI, DS-STEPS, saved Work Orders, URL/query parameters, Suitcase configuration, or another analyst-facing product path. Compile-time exclusion, test-build configuration, or an isolated acceptance harness are permitted implementation techniques. Retained acceptance evidence must identify any seam used and must separately demonstrate that the accepted release surface cannot invoke that seam as a user feature. Named storage acceptance gaps. Acceptance must include a case-variant governed namespace/class fixture proving that Data Sculptor does not silently normalize the variant spelling into canonical governed identity; an unknown syntactically valid governed-class fixture proving that the file remains byte-for-byte unchanged while a canonical INFO diagnostic and INVENTORY surface the unknown/unrecognized class; and at least one known-but-not-emitted-class fixture drawn from DGN , RCV , BRD , or LCK proving the same preserve-and-report behavior without activating a producer, lifecycle, or interpretation path. Carried feature gates remain feature-owned. Mechanisms whose normative lifecycle is integrated in another package — including the F-02 Work Order-registry/alias-replacement behavior, the F-04 existing-Store cardinality refusal, and the F-24 CER-history decision — cannot be considered accepted without their corresponding feature acceptance gates. This requirement does not invent those feature semantics. If a proposed mechanism is removed from WASM-002 rather than integrated, no acceptance gate for that removed mechanism is required.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-001,UTF-8 certification pass,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,A valid multi-gigabyte UTF-8 fixture must complete whole-source certification with exact byte accounting under bounded memory.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-002,UTF-8 certification fail,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"A fixture containing an invalid UTF-8 sequence, including a sequence that crosses an input-window boundary, must deterministically produce STAGE1_UTF8_OUTCOME: FAIL , UTF8_STOP_REASON: INVALID_UTF8_SEQUENCE , and the exact governed zero-based UTF8_FIRST_INVALID_BYTE_OFFSET . Stage 2 must not begin and no analytical materialization output may be published. The same bytes tested under different permitted Stage-1 input-window sizes and boundary placements must yield the same outcome, stop-reason token, and first-invalid offset.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-003,Run-local source substitution refusal,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"An acceptance fixture must attempt to present Stage 2 with a different source instance/reference than the one retained from Stage 1. The run must refuse before materialization rather than accept the substitute merely because filename, alias, path, or byte length appears compatible. F-23 governed seam: this fixture must use the test-only source-handle substitution/reread seam permitted by W002-QA-001 so the different Stage-2 instance is injected without changing the analyst-visible SOURCE syntax or adding a product-level source-selection path. Release-surface evidence must demonstrate that an analyst cannot invoke this substitution seam through the normal UI, Work Order, URL/query, or Suitcase configuration.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-004,ASCII-only fast path,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,An all-ASCII fixture must certify successfully without invoking non-ASCII sequence validation and must produce exact byte accounting.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-005,Valid non-ASCII sequence matrix,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"Acceptance must cover valid two-byte, three-byte, and four-byte UTF-8 sequences, including sequences placed at window boundaries and split at every legal boundary position.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-006,Strict invalid-sequence matrix,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"Acceptance must reject at known exact offsets: lone continuation bytes, malformed continuation sequences, truncated sequences, overlong encodings, UTF-16 surrogate encodings, invalid lead bytes 0xC0 / 0xC1 , values introduced by 0xF5 - 0xFF , and code points above U+10FFFF. Every invalid fixture must serialize the same canonical UTF-8 stop reason INVALID_UTF8_SEQUENCE while preserving its fixture-specific exact first-invalid byte offset. For an EOF-truncated multibyte sequence, the expected offset is the lead byte of the incomplete sequence. Acceptance must include at least one malformed sequence crossing a Stage-1 input-window boundary and prove window invariance. Separate valid fixtures covering ASCII-only, valid multibyte UTF-8, and permitted leading-BOM forms must complete with STAGE1_UTF8_OUTCOME: PASS ; their UTF-8 refusal-only Receipt fields are NOT_APPLICABLE .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-007,Late invalidity,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,A source that is ASCII/valid UTF-8 until near EOF and becomes invalid late in the file must fail at the first invalid absolute offset; bounded-prefix success must not be treated as whole-file certification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-008,Window-size invariance,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,The same fixture matrix must return the same PASS/FAIL and first invalid absolute offset across at least two materially different bounded window sizes.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-009,EOF pending-state refusal,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,EOF with an incomplete UTF-8 sequence must fail deterministically and report the governed offset; no replacement character may be inserted.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-010,BOM behavior,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"A UTF-8 BOM at offset zero must be accepted as metadata while the remainder of the source is still fully certified; a BOM must not mask later invalid UTF-8. F-07 BOM coordinate fixture: when a permitted three-byte UTF-8 BOM precedes a later malformed UTF-8 sequence, the expected first-invalid offset counts the BOM's physical bytes. The BOM is excluded from analytical CSV content but included in the absolute physical source-byte coordinate system.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-001,Multi-column one-pass Stage 2 materialization,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Using a valid UTF-8 source and a Work Order requesting at least four source columns through a mixture of HEADER and COLUMN selectors, acceptance must prove that Stage 1 completes first, Stage 2 restarts at byte zero of the same run-local source instance, parses the header once, resolves all selectors before the first data row, and reads the source data records only once while producing all requested columns. Evidence must reconcile total source bytes read by Stage 2, logical data-row count N, per- COL data-record count N, selector-to-source ordinal/header resolution, resolved KEEP order, and the resulting successor MAP. A one-column rerun of the same source/column must produce the same canonical physical column bytes as that column produced inside the multi-column run, apart from governed artifact identity. F-20 width/one-pass acceptance: acceptance must include a maximum-width fixture whose valid source has exactly 16,384 columns and whose KEEP resolves all 16,384 distinct columns. Instrumentation must prove one source data-record traversal regardless of the implementation's bounded post-scan spool/finalization strategy. A companion 16,385 -column source must refuse during header resolution before the first data record is consumed.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002,"Automatic Store MAP creation, inheritance, and rematerialization continuity",W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must materialize four previously unseen source columns in one Store-establishing Work Order and prove that one successor Store MAP is created with four mapping rows. Every row must repeat identical Store-level fields, bind the newly created RID filename, default store_alias to the exact Store-establishing source filename, default rid_alias to RID , and default each COL alias to its exact source header. A later Work Order using the same exact SOURCE without explicitly naming a MAP must route under W002-STOR-019.2 . If exactly one routable Store lineage exists for that exact source filename and its current Store state permits materialization, the Work Order must inherit that lineage’s current structurally valid Store MAP, preserve the Store/RID metadata and four prior mappings, add a fifth default COL alias, and publish one new complete Store MAP. A later rematerialization of one earlier logical column must preserve its inherited COL alias while updating its column_filename . An explicit older MAP selection must instead use that historical Store state. Equal-latest-timestamp ambiguity within one routed lineage, malformed-newer-MAP fallback within the same Store lineage, no-routable-Store-lineage creation, and multiple-routable-Store-lineages-for-the-same-source refusal must also be exercised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.1,Exact eight-column Store MAP serialization acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must validate the exact Store MAP header store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename , UTF-8 without BOM, LF line endings, deterministic mapping-row order, standard governed CSV quoting, and byte-for-byte repetition of store_alias , rid_filename , rid_alias , and the common source_filename on every mapping row. The fixture must prove that a MAP with inconsistent repeated Store-level metadata, more than one rid_filename , more than one source_filename , a missing or invalid RID filename, a duplicate logical source-column key, or a non-eight-column schema is ineligible for inheritance. Source compatibility fixtures must prove that an explicit MAP may proceed only when the Work Order SOURCE exactly equals that MAP's common source_filename . A different source must refuse before materialization even when its row count equals the Store's RID cardinality; matching row count never creates a positional-join escape. P3-06 validation-tier fixtures: acceptance must distinguish Store-health Tier 1 from full Tier 2 validation. A same-named externally restored RID/COL may be treated as eligible only after it passes the tier required by the operation, and no fixture may label such an artifact “the exact original” solely from its physical filename. Tier-1 fixtures must prove the exact bounded checks in W002-STOR-019.10 without an end-to-end scan of every artifact value. Tier-2 fixtures must prove full RID sequence/cardinality validation and full COL canonical-form/header/cardinality validation. REPAIR MAP fixtures must demonstrate that the same input bytes yield one deterministic set of removed COL bindings under Tier 2. P2-04 closure fixtures: acceptance must include (1) a RID that satisfies Tier 1 but fails Tier 2 because the body does not contain the exact declared 1..N sequence; (2) a COL that satisfies Tier 1 but fails Tier 2 because its complete CSV body or logical-record count is invalid; (3) an externally supplied same-named RID/COL that passes the required governed tier without any assertion that it is the historical original bytes; and (4) a REPAIR MAP case with a mixture of Tier-2-valid and Tier-2-invalid COLs proving that the successor removes exactly the failing bindings. Repeating the same fixture bytes must yield the same repair set and successor mapping.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.2,Multiple Stores in one Suitcase remain distinct through RID-anchored MAP lineages,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must establish at least two Stores from different source files in the same Suitcase. Their Store MAP lineages must contain different immutable rid_filename values, and automatic routing for each source must choose only that source's routable Store lineage. The fixture must prove that a lineage remains routable when at least one Store MAP is structurally valid even if subsequent Store-health evaluation is DEGRADED or INVALID ; health may refuse the operation, but it must not make the lineage disappear from routing. Changing a human-facing store_alias or rid_alias in a later governed MAP must not change the Store's rid_filename , RID bytes, or lineage identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.3,WKO MAP profile and alias-registry publication acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must save at least three immutable WKO artifacts, each containing exactly one non-empty WORK ORDER AS clause: one with a multi-word alias, one whose alias is deliberately replaced under the frozen WKO lifecycle, and one with punctuation permitted by the governed string rules. The committed WKO MAP must satisfy the frozen current-registry schema and lifecycle rules, use UTF-8 without BOM and LF endings, preserve exact physical WKO references, and prove deterministic governed serialization. The fixture must prove that a WKO MAP cannot be treated as a Store MAP; duplicate physical WKO rows are invalid; conflicting current authority for the same non-empty alias is refused before commit; and equal-latest-timestamp ambiguity refuses current-registry selection. A saved/executable WKO without WORK ORDER AS is invalid in Revision BM and must refuse before execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.4,WORK ORDER AS and # comment lexical acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must prove that WORK ORDER AS ""Prepare monthly crime data"" is parsed as the immutable WKO alias, that whole-line and trailing # comments are ignored semantically, and that # inside double-quoted strings remains ordinary string content. The fixture must also prove that saved WKO bytes preserve comments exactly, that changing only a comment or Work Order alias requires a new WKO physical identity, and that no standalone browser Description value is required to reopen or display the governed alias. P3-10 alias fixture: acceptance must prove that WORK ORDER AS ""   "" refuses as a whitespace-only alias, while an otherwise valid alias containing leading or trailing whitespace is not silently trimmed or normalized and is preserved exactly in saved WKO bytes and the governed alias registry.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-003,Stage 2 structural window-invariance matrix,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Acceptance fixtures must force input boundaries at structurally difficult positions including before/after delimiters, before/after opening and closing quotes, between doubled quote bytes, between CR and LF, inside quoted multiline field content, at empty fields, and inside already-certified multi-byte UTF-8 sequences. Across permitted window sizes and boundary placements, the logical row count, selected values, canonical COL bytes, first refusal location/condition, and resolved mapping semantics must remain invariant. P3-09 fixtures: acceptance must include both byte forms identified by the Pass 3 finding: (1) an exactly zero-byte source and (2) a source containing only the three UTF-8 BOM bytes EF BB BF . Both must pass the applicable Stage 1 UTF-8 gate and then refuse in Stage 2 with NO_HEADER_RECORD . The exact expected location tuples are respectively (offset 0, physical line 1, logical record 1, field ordinal 1) and (offset 3, physical line 1, logical record 1, field ordinal 1) . The fixtures must also distinguish this case from an existing-but-blank first logical record, which remains BLANK_LOGICAL_RECORD . P3-10 delimiter-help fixture: acceptance must include a quoted semicolon-delimited form such as ""a"";""b"" and an equivalent TAB-delimited quoted form that reach INVALID_BYTE_AFTER_CLOSING_QUOTE . The canonical refusal condition and location facts must remain unchanged, while the Help rendering is permitted to surface the delimiter-mismatch hint for offending byte 0x3B or 0x09 . F-06 structural-refusal acceptance matrix An unexpected quote in an unquoted field must report the quote byte and UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD . A prohibited byte after a closing quote must report that byte and INVALID_BYTE_AFTER_CLOSING_QUOTE . A bare CR outside quoted content must report the CR byte and BARE_CR_OUTSIDE_QUOTED_FIELD . CR, LF, and CRLF inside valid quoted values must remain field content and must not trigger the bare-CR rule. EOF in an open quoted field must report the one-past-end source offset and EOF_INSIDE_QUOTED_FIELD . A blank logical record must report BLANK_LOGICAL_RECORD , not TOO_FEW_FIELDS . A short record must report the terminator/EOF location and the first missing field ordinal. A wide record must report the comma delimiter opening the first extra field and that extra field ordinal. All five refusal facts must remain identical across permitted source-window sizes and boundary placements. Fixtures must force boundaries around commas, opening and closing quotes, doubled-quote pairs, CR/LF pairs, quoted multiline content, empty fields, and already-certified multibyte UTF-8 sequences. A semicolon-separated file must not refuse solely because it uses semicolons; Help may explain comma-only interpretation when header selection fails. Day 060 H-13 Receipt-corpus binding for P3-09 The two analytical P3-09 source fixtures above must each have a corresponding byte-exact refusal Receipt under W002-RCP-ACC-002. The zero-byte and BOM-only cases therefore prove both the parser/refusal oracle and the Receipt serialization oracle independently.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-004,Canonical one-column COL serialization acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Golden-byte fixtures must cover ordinary ASCII, non-ASCII UTF-8, commas, embedded double quotes, CR, LF, CRLF inside quoted values, explicit empty data values, empty source headers, and header-only zero-row input. Acceptance must prove one UTF-8 BOM at file start, LF record termination independent of host platform, deterministic minimal quoting, doubled embedded quotes, """" for an empty one-column data value, no accidental inclusion of the source BOM in the first header, and byte-identical round-trip semantics through the Data Sculptor CSV reader. F-20 oversized-header serialization acceptance: fixtures at exactly 1,024 and 1,025 Unicode scalar values must prove that the physical COL header remains byte-faithful to the exact decoded source header while only the operational/default-alias name changes at the boundary. Scalar-count fixtures must include combining characters so acceptance cannot accidentally measure UTF-8 bytes or grapheme clusters instead.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-005,"Field-limit, ragged-record, blank-record, and failure-publication acceptance",W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Acceptance must include decoded field sizes exactly 16 MiB and 16 MiB + 1 byte, malformed runaway quoted-field cases, nonblank records with too few and too many fields, a bare blank logical data record, explicit empty fields, and a physical blank line inside a valid quoted multiline field. The first invalid case must refuse without truncation or silent repair. Publication evidence must additionally exercise both a new-Store multi-column materialization and a later existing-Store materialization. For the new Store, the shared publication-transaction UTC must be established before any new RID/COL SCR candidate is opened, and each candidate-specific UUID must be allocated before its candidate is created. RID and COL outputs must remain governed SCR until the complete candidate set validates; the RID must then promote first, requested COLs must promote in deterministic KEEP order, the successor MAP UUID must be allocated before its MAP SCR candidate is opened, that MAP candidate must be written/closed/reopened/validated while still SCR , and its final SCR -to- MAP rename must occur last. For every successfully promoted RID, COL, and MAP artifact, acceptance must prove that the candidate and final identity have the exact same UTC, UUID, extension, and bytes and differ in the governed filename only by the three-letter semantic class token. For the existing Store, the inherited RID must remain byte-for-byte and filename-identical with no new RID candidate. F-04 existing-Store cardinality acceptance: acceptance must include two otherwise valid existing-Store materializations using the same exact governed SOURCE identity. In the equal-cardinality fixture, Stage 2 candidate N must equal the inherited RID-header N and publication may proceed under the ordinary rules. In the mismatch fixture, candidate N must differ from RID-header N ; the Run must refuse before any candidate COL is promoted into the final COL namespace and before any successor MAP is published. The inherited RID, current MAP, existing COL artifacts, and Store health must remain unchanged, with the existing Store remaining VALID. The equal-cardinality case must not be represented as proof of source-byte or row-semantic identity. Forced failure cases must cover: failure before any promotion; RID-promotion failure; failure during COL promotion after RID and at least one COL have promoted; MAP-candidate write/close/reopen/validation failure; MAP final-rename failure; and interruption after physical RID/COL promotion but before MAP commit. Each case must prove rollback where safely possible or visible non-authoritative SCR failure evidence otherwise, must prove that unreferenced final-class-looking RID/COL files are not treated as committed Store membership, and must prove that the prior valid MAP remains authoritative for an existing Store or that no committed Store exists for an uncommitted first materialization. F-20 bounded-width/name acceptance: acceptance must cover exactly 16,384 versus 16,385 source columns; KEEP widths of 1 and 16,384 ; operational-name derivation at 1,024 versus 1,025 Unicode scalar values; physical ordinals producing Column A , Column Z , Column AA , and Column XFD ; and deterministic oversized-header fallback collisions proving [ordinal] then -2 progression. A separate short-header alias collision must prove refusal rather than automatic suffixing.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-006,Large-source browser materialization evidence,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance must include a browser run against the established Statistics Canada scale source or an equivalently retained scale fixture, recording source bytes, Stage 1 time, Stage 2 time, total time, selected-column count, logical row count, bytes written per COL , peak/bounded memory observations, output fingerprints, and browser/platform details. The retained Day 039 evidence established that Microsoft Edge could stream the 7,250,808,204-byte source through a small Rust/WASM materializer and materialize 29,014,718 VALUE data rows in practical time. Revision AM treats that result as engineering evidence and a comparison baseline, not as proof that WASM-002 is already implemented or as a frozen wall-time threshold. F-20 writer-resource evidence: retained acceptance evidence must identify the build's configured maximum simultaneously active writable-output resources and the observed peak for the run. Evidence must show that wide KEEP cardinality does not imply one simultaneously open writer per selected column and that any bounded spool/finalization strategy preserves the same governed output bytes and semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-ACC-001,Separate Windows-1252 conversion,W002-CONV-ACC,W002-CONV,WASM-002,UNDER REVIEW,—,"A non-UTF-8 fixture compatible with the supported Windows-1252 converter must cause the analytical task to stop, permit a Help suggestion, and succeed only when the separate conversion Work Order is explicitly run. P3-08 acceptance: the fixture set must convert an analyst-owned legacy source successfully, materialize the resulting CVT, then perform a second successful conversion from a refreshed legacy source using the same analyst-owned filename. The second conversion must publish a different CVT physical filename. First materialization of that second CVT must establish a distinct Store/RID lineage rather than inherit from the first CVT-backed Store. Acceptance must also prove that Help discloses this consequence at conversion success and again when the CVT is first materialized, and that no hidden original-source identity is used to join the two CVTs into one lineage. F-16 acceptance: the compatible non-UTF-8 fixture must prove that strict UTF-8 certification first emits DS-ENC-001 with next_action: NONE ; Stage 2 does not start; Data Sculptor restarts at byte 0 of the same bound source instance and scans the complete source under the frozen mapping; the Receipt records WINDOWS_1252_COMPATIBILITY_OUTCOME: COMPATIBLE and WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET: NOT_APPLICABLE ; and only then is DS-CNV-001 emitted with severity: INFO , behavior: CONTINUE , and next_action: RUN_WINDOWS_1252_CONVERSION . The refused MATERIALIZE run must remain refused. A separate valid-UTF-8 fixture must prove that both Windows-1252 compatibility Receipt fields are NOT_RUN and DS-CNV-001 is not emitted. F-10 conversion-gate and byte-output acceptance A source already valid as complete strict UTF-8 must refuse CONVERT WINDOWS-1252 TO UTF-8 as unnecessary and create no CVT . A source that fails strict UTF-8 but passes the complete Windows-1252 compatibility assessment may convert only when the separate conversion WKO is explicitly run. The analyst-owned source bytes must remain unchanged. The published CVT must pass complete strict UTF-8 certification. Source CR, LF, and CRLF bytes must be preserved in place rather than normalized. The conversion must remain bounded/streaming. The published CVT must not begin with a UTF-8 BOM introduced by Data Sculptor. The successful Receipt must contain the frozen conversion operation token and required conversion facts. Frozen minimal byte oracle: Windows-1252 source bytes:
63 61 66 E9 0D 0A

UTF-8 CVT bytes:
63 61 66 C3 A9 0D 0A This is café followed by CRLF. The expected CVT begins with byte 63 ; no EF BB BF prefix is present. Day 060 H-25 / BM-04 acceptance: the already-valid-UTF-8 CONVERT fixture must use a complete source whose byte stream is valid strict UTF-8 and must produce a byte-exact refused Receipt containing: SOURCE_ENCODING: UTF-8
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: NOT_RUN
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE The same fixture must prove that no Windows-1252 compatibility assessment runs, no transcoding begins, the analyst-owned source bytes remain unchanged, and no CVT file is created.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-ACC-002,Undefined Windows-1252 byte refusal,W002-CONV-ACC,W002-CONV,WASM-002,UNDER REVIEW,—,"A fixture containing a byte undefined by the frozen Windows-1252 mapping must not be silently converted. F-16 acceptance: use fixtures placing each of 0x81 , 0x8D , 0x8F , 0x90 , and 0x9D at controlled physical offsets, including across compatibility-buffer boundaries. The complete oracle must prove WINDOWS_1252_COMPATIBILITY_OUTCOME: INCOMPATIBLE , the exact first undefined-byte offset, no DS-CNV-001 emission, no conversion recommendation, and window-size invariance. A separate injected read-failure fixture after the compatibility pass begins must prove NOT_AVAILABLE for both compatibility Receipt fields and no conversion recommendation. F-10 conversion-operation undefined-byte acceptance The separate CONVERT WINDOWS-1252 TO UTF-8 operation must itself refuse before transcoding when its complete compatibility assessment encounters any byte undefined by the frozen Windows-1252 mapping. Such a refusal publishes no CVT . Acceptance must cover each frozen undefined byte value at a controlled absolute source offset and prove that no replacement-character, ISO-8859-1, or permissive-decoder fallback produces output. Day 060 H-14 / BM-11 byte-exact undefined-byte CONVERT fixture The golden CONVERT refusal fixture uses this exact analyst-owned source byte sequence: 41 81 42 The strict UTF-8 gate must fail, and the subsequent complete Windows-1252 compatibility assessment must encounter 0x81 as the first undefined byte at exact zero-based absolute physical source-byte offset 1 . The operation must refuse before transcoding begins. The byte-exact Receipt for this fixture must include: SOURCE_ENCODING: WINDOWS-1252-INCOMPATIBLE
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: 1
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE
RESULT: REFUSED The analyst-owned source bytes must remain exactly 41 81 42 ; no CVT is published; no replacement character is introduced; and no ISO-8859-1 or permissive-decoder fallback is permitted. A second acceptance form must place at least two undefined Windows-1252 bytes in one source and prove that the reported offset is always the first undefined byte. Buffer/window-boundary variants must preserve the same absolute offset.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-001,Canonical diagnostic event,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,At least one real governed WASM-002 failure path must emit a complete canonical diagnostic event with stable code and structured facts. A separate test-only fault-injection fixture must remove or withhold one required fact while the engine attempts to assemble a registered diagnostic. Acceptance must prove that the malformed intended diagnostic is not emitted and that exactly one canonical DS-HLP-001 replacement event is emitted with the exact intended diagnostic ID and the complete ascending-UTF-8 list of missing required fact keys.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-002,Three-voice rendering parity,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"A complete event with an authored catalog entry must be renderable in all three established Help voices. Automated checks must demonstrate invariant diagnostic truth across the three outputs. A separate complete registered diagnostic fixture must deliberately have no help_messages.json entry. Casual, Office Speak, and Technical selections must all resolve to the same deterministic Generic Technical Help fallback, preserving the original diagnostic semantic core and rendering emitted facts in ascending UTF-8 fact-key order without invented cause or remediation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-003,Saved HTML Help report using the canonical built-in Data Sculptor presentation,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,At least one complete HTML Help report using the canonical built-in Data Sculptor presentation must be generated and saved locally from that real event.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-004,Offline durability,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,The saved HTML report must remain readable with its canonical built-in Red5Sorcery/Data Sculptor presentation when opened without network access and without access to Data Sculptor or any external presentation resource.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-008,Support-handoff report acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"From a real governed refusal, Data Sculptor must generate one styled HTML Help Report that opens in an ordinary browser without Data Sculptor or network access and contains both a selected-voice explanation and the canonical structured facts needed by a technical reviewer.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-009,Canonical boundary-fact acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"An early-refusal fixture that stops before analytical materialization must demonstrate the exact four Boolean fact names from W002-HELP-004.11 and, when those are the true governed facts, values equivalent to: source_modified_by_data_sculptor = false
materialization_started = false
analytical_outputs_published = false
store_state_committed = false Acceptance must also exercise at least one boundary-fact case in which an established Boolean value is unavailable or otherwise carries an applicable governed absence state. The emitted value must use the exact shared JSON string token required by W002-HELP-004.11 (for example ""NOT_AVAILABLE"" ) and must not be coerced to false or JSON null . Where a boundary fact is optional and its key is omitted, acceptance must prove that omission is not interpreted as false or as any governed absence token. The same fixture family must prove that temporary SCR candidates or abandoned/uncommitted debris do not make analytical_outputs_published true.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-010,"HLP provenance, multiplicity, and no-automatic-hash acceptance",W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"Acceptance evidence must generate a final HLP using the built-in Red5Sorcery/Data Sculptor presentation and verify its governed __DS__HLP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html identity, its visible Provenance section, and exactly one embedded application/json payload with element ID ds-hlp-provenance . The embedded payload must contain exactly the schema-version-2 fields governed by W002-HELP-009 and must verify the same HLP filename/generation UTC, non-empty ordered diagnostic_ids array, WKO/RCP lineage semantics, selected Help voice, built-in presentation identifier red5sorcery-data-sculptor , built-in presentation version ""1"" , and the exact running Data Sculptor build identifier. Acceptance must cover: (1) an explicit request for a single diagnostic; (2) one governed Run with multiple included diagnostic events, proving exactly one HLP for the request and event-order parity with diagnostic_ids ; and (3) a non-run diagnostic such as Suitcase-validation or WKO-save refusal, proving that non-applicable WKO/RCP lineage is represented by JSON null and visible NOT APPLICABLE rather than invented Run lineage. Acceptance must also cover all three lineage representations permitted by W002-HELP-009: an exact physical filename when the relationship exists and is known; JSON null when the relationship does not apply; and the exact JSON string ""NOT_AVAILABLE"" when the relationship applies but its exact filename cannot be obtained. The fixture must prove that null and ""NOT_AVAILABLE"" are not interchangeable. Acceptance must prove that the visible Provenance section and machine-readable payload agree semantically; missing, duplicate, malformed, mismatched, non-HTML-safe, disclosure-violating, empty diagnostic_ids , or scope-label-only build provenance must not be accepted. The same acceptance must prove that ordinary HLP generation does not compute or embed an HLP SHA-256 and does not create, refresh, or verify an LCK . Exact-byte HLP integrity remains outside WASM-002 in the later explicit FINGERPRINT/LCK workflow.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-011,Fixed support-handoff disclosure acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"Acceptance must prove the fixed support-handoff disclosure boundary with both permitted-context and adversarial headerless fixtures. A permitted-context fixture must generate an HLP whose diagnostic requires a source filename, one genuinely established relevant source header and/or 1-based column number, bounded execution evidence, and a small executable Work Order excerpt. A governed alias may appear only when the alias itself is necessary to explain the diagnostic, such as an alias collision, ambiguity, or mutation; an unrelated alias must remain excluded. The report must include only the necessary permitted facts while excluding source rows/values, absolute local paths, unrelated headers/aliases/columns, the complete Work Order, Work Order comments, unrelated Suitcase contents, and raw ungoverned stack traces. A separate headerless-source fixture must place unmistakable sentinel text in the first data row and prove that none of that text appears in the HLP as a header or other disclosed source value. That HLP must show Source header text included: NO and Source values included: NO while still presenting sufficient structural evidence to explain the diagnostic. A genuine-header fixture must prove that a necessary established header may appear with Source header text included: YES . Alias fixtures must similarly prove truthful Governed alias text included: YES only when necessary and NO otherwise. Every fixture must verify the remaining frozen Disclosure declarations from W002-HELP-010. WASM-002 must expose no control that changes this fixed disclosure policy.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-012,Cross-session source-continuity Help acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"An acceptance fixture must present Help with a suspected cross-session source-change scenario and verify that the explanation asks whether the source may have been edited/replaced/sorted/re-exported/synchronized, distinguishes no evidence from INVENTORY metadata evidence and stronger explicit fingerprint evidence, and never claims that unchanged filename or unchanged INVENTORY metadata proves byte identity. A no-evidence fixture must state that continuity cannot be independently verified. An INVENTORY fixture with changed source byte length or last-modified metadata must describe the difference as evidence that the source may have changed, not as a cryptographic conclusion. The fixture must also confirm that ordinary WASM-002 materialization did not automatically hash the source as part of this edge-case protection.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-013,Diagnostic-registry and Help cross-validation acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance must retain the validated diagnostics.json used by the accepted build and verify its exact version-1 schema, canonical sort order, unique permanent IDs, fixed-token grammars, and disjoint required/optional fact declarations. At least one real governed diagnostic fixture must prove that the emitted semantic core matches the matching registry entry and that all required facts are present while no undeclared fact key is emitted. Negative build-validation fixtures must prove deterministic failure for malformed/duplicate registry entries, an engine diagnostic definition absent from the registry, fixed semantic disagreement, an undeclared emitted fact, a Help-catalog diagnostic ID absent from the registry, and a Help placeholder not declared for its matching diagnostic. F-17 runtime completeness fixtures: missing required facts are no longer treated as a malformed event that may leak to Help. Fault injection must prove deterministic substitution with DS-HLP-001 , including exact intended_diagnostic_id and sorted missing_required_facts , with no partially populated intended diagnostic emitted. Separately, a valid registered diagnostic omitted from help_messages.json must remain a valid build/runtime condition and must exercise the Generic Technical fallback rather than build failure or diagnostic suppression. F-22 QA-independence acceptance boundary: acceptance must prove the registry/engine/Help wiring and generic invariants without circularly presenting the implementation-delivered registry as an independent oracle for its own condition-to-Diagnostic-ID allocations. Representative governed fixtures must trace condition → emitted Diagnostic ID → matching registry semantic core → required/optional fact discipline → Help lookup/rendering. Every condition-to-ID or required-fact mapping explicitly frozen elsewhere in this PRD remains independently testable and must match that PRD contract. For allocations not independently pinned by this PRD, WASM-002 does not require a duplicate QA-owned registry that restates every condition-to-ID choice. Passing this acceptance gate therefore demonstrates registry integrity, engine↔registry semantic agreement, fact completeness/legality, Help-catalog wiring, F-17 fail-safe behavior, and representative end-to-end diagnostic routing; it must not be reported as exhaustive independent proof that every possible runtime condition was assigned the semantically correct Diagnostic ID. That residual independence limitation is an accepted WASM-002 risk. F-23 embedded Help-catalog release fixture: acceptance must build the released HTML from a validated help_messages.json , verify exactly one non-executable application/json payload with element ID ds-help-catalog , and include adversarial catalog text containing literal < / script-like delimiter content to prove HTML-safe embedding. Runtime instrumentation must prove that Help lookup reads only the embedded payload and performs no network, filesystem, Suitcase, or adjacent-file fetch for the Help catalog. A missing, malformed, mismatched, or unsafe embedded catalog must fail build acceptance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-007,Work Order syntax is the analytical contract,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"If a value, reference, option, or instruction changes what Data Sculptor analytically does, that intent must be represented in governed Work Order text or in a separately governed artifact explicitly referenced by that Work Order. Browser permission, directory selection, UI focus, a highlighted file, an alias display, or another GUI gesture must not silently become analytical intent. For WASM-002, every executable saved WKO begins with the common preamble: SUITCASE: .
WORK ORDER AS ""<non-whitespace alias>"" Ignoring blank lines and governed comments, the WKO must then parse completely under exactly one of these seven executable operation grammars: Operation Governed DS-STEPS structure after the common preamble MATERIALIZE SOURCE ""..."" ; optional MAP ""..."" ; KEEP ; one or more selectors; terminal MATERIALIZE . INVENTORY terminal INVENTORY only. UPDATE ALIASES exactly one Store-state selector: SOURCE ""..."" or MAP ""..."" ; one or more governed alias mutations; terminal UPDATE ALIASES . REPAIR MAP exactly one MAP ""<exact current Store MAP filename>"" ; terminal REPAIR MAP . REPAIR WORK ORDER REGISTRY terminal REPAIR WORK ORDER REGISTRY only. CONVERT WINDOWS-1252 TO UTF-8 exactly one SOURCE ""..."" ; terminal CONVERT WINDOWS-1252 TO UTF-8 . CATALOG STORES terminal CATALOG STORES only. Each operation-specific numbered requirement remains authoritative for its detailed selectors, preconditions, mutations, publication semantics, and acceptance behavior. This requirement freezes the cross-operation boundary: unknown semantic lines refuse; clauses from another operation grammar refuse unless the selected operation explicitly defines them; there is no best-effort interpretation and no silent cross-operation mixing. Lexical token separation. DS-STEPS keywords are matched ASCII case-insensitively; canonical examples render them uppercase. Wherever two adjacent lexical tokens would otherwise run together, they must be separated by one or more ASCII SPACE ( 0x20 ) or horizontal TAB ( 0x09 ) characters. Leading SPACE/TAB indentation is semantically neutral. Thus REPAIR MAP , SOURCE ""crime.csv"" , and COLUMN 7 are valid tokenizations, while REPAIRMAP , SOURCE""crime.csv"" , and UPDATE_ALIASES are not alternate DS-STEPS spellings. Quoted-string contents are never case-folded or whitespace-normalized merely because keywords are case-insensitive. The browser may authorize resources, edit text, validate, save, invoke Run, display evidence, and provide Help. Authorization to access a resource is not authorization to use that resource analytically.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-008,Every executable Work Order explicitly declares its Suitcase,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"For WASM-002, every executable saved Work Order must contain the exact portable declaration SUITCASE: . . The dot means the filesystem directory that physically contains the saved WKO artifact being executed. A Work Order lacking this declaration must not be treated as an executable WASM-002 Work Order. The declaration is analytical/execution syntax, not a substitute for browser filesystem permission. The host must still possess valid access to the directory before execution can proceed. Help obligation: Data Sculptor Help must explain SUITCASE: . in plain language: the saved Work Order uses the folder that contains that WKO as its Suitcase; the dot means “this folder”; ordinary Work Order file references are therefore portable and Suitcase-relative; and browser/host permission to the folder is granted separately. Help must not teach an absolute machine path as the normal replacement for . .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-009,Ordinary Work Order file references are Suitcase-relative,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Unless another numbered requirement explicitly governs a different reference mechanism, file references in an executable WASM-002 Work Order resolve relative to the declared Suitcase. A portable Work Order must not depend on an absolute machine-specific path to identify ordinary Suitcase files. Resolution must be deterministic in browser and later native hosts. Moving an intact Suitcase to another permitted filesystem location must not change the logical meaning of the Work Order solely because the parent machine path changed.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-009.1,WASM-002 SOURCE eligibility is exact and root-bounded,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"A WASM-002 SOURCE clause names exactly one physical regular file in the Suitcase root by exact filename only. It must not name an absolute path, drive or UNC path, subdirectory, path containing / or \ , traversal such as .. , URL/URI, or another external reference. Resolution uses the exact Unicode-scalar filename identity and reference-bounded rules frozen by F-15; no case-folding, normalization, trimming, or filesystem-equivalence search is permitted. The only eligible WASM-002 SOURCE kinds are: Analyst-owned CSV: a regular Suitcase-root file whose exact filename does not begin with the reserved exact prefix __DS__ and whose final extension is .csv under ASCII case-insensitive extension recognition. Thus .csv , .CSV , and mixed-case equivalents are candidate CSV extensions. This case-insensitivity applies only to extension recognition; the complete filename reference remains exact. If the physical file is crime.CSV , a differently cased full filename does not become an alternate reference to it. Governed converted source: a successfully published CVT whose exact canonical identity and class-specific publication/validity predicate satisfy W002-CONV-004, W002-STOR-023, and PB-STOR-008. A filename that merely resembles a CVT is not sufficient. No other governed semantic class is eligible as SOURCE in WASM-002, even when its physical serialization is CSV. In particular, COL , RID , MAP , CAT , INV , RCP , HLP , CER , SCR , RCV , and WKO artifacts cannot be reintroduced as SOURCE merely because their bytes or extension appear compatible. A recognized .csv extension establishes only candidate SOURCE form. It does not certify encoding or CSV structure; the normal strict UTF-8 and structural certification contracts still govern after source resolution. Conversely, CSV-like bytes stored under a non-CSV analyst-owned extension are not an eligible WASM-002 SOURCE.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-008; CP-009; CP-010,"T-ACCEPTED, BANKED; analyst-owned CSV filename candidate preflight only; full SOURCE eligibility remains partial; CP009 T-ACCEPTED, BANKED — pure exact-name root snapshot matching only; full requirement remains partial; CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open",346733a962192320e0d56271add15a47b6037b6b; dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8; b7c515faa9bd000369d7656e09437310261290ae,Evidence/CP-008/CP008_RED_Test_Output.txt; Evidence/CP-008/CP008_GREEN_Test_Output.txt; Evidence/CP-008/CP008_Full_Regression_Test_Output.txt; Evidence/CP-008/CP008_Post_Format_Test_Output.txt; Evidence/CP-008/CP008_Rustfmt_Check_Output.txt; Evidence/CP-008/CP008_WASM_Build_Output.txt; Evidence/CP-008/CP008_Hash_Inventory_Verification.txt; Evidence/CP-008/CP008_Precommit_Git_Review.txt; Evidence/CP-008/CP008_Final_Source_Review.txt; Evidence/CP-008/CP008_Whitespace_Exception_Review.txt; CP008_Git_Banking_Output.txt (separate post-commit evidence; archived outside repository); Evidence/CP-009/CP009_Baseline_Test_Output.txt; Evidence/CP-009/CP009_RED_Test_Output.txt; Evidence/CP-009/CP009_GREEN_Test_Output.txt; Evidence/CP-009/CP009_Full_Regression_Test_Output.txt; Evidence/CP-009/CP009_Rustfmt_Check_Output.txt; Evidence/CP-009/CP009_Git_Whitespace_Check.txt; Evidence/CP-009/CP009_Post_Format_Test_Output.txt; Evidence/CP-009/CP009_WASM_Build_Output.txt; Evidence/CP-009/CP009_Hash_Inventory.txt; Evidence/CP-009/CP009_Hash_Inventory_Verification.txt; Evidence/CP-009/CP009_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Final_Staging_Review.txt; CP009_Git_Banking_Output.txt (separately archived post-commit evidence); Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived),"CP008 Day066: public is_analyst_owned_csv_source_candidate(&str) -> bool recognizes the final .csv extension ASCII case-insensitively for exact Suitcase-root analyst-owned candidate names. It refuses empty stems, __DS__-reserved names, slash/backslash paths, colon-bearing references, and traversal-like double-dot forms; preserves full spelling, case and Unicode normalization distinctions. Five new tests and 23 prior tests passed, 28/28 after Rustfmt. WASM32-target library compilation passed; no standalone browser execution proven. 20/20 SHA-256 file inventory matched; staged Rust source/test whitespace check 0. Full staged whitespace check 2 due solely to two preserved archival trailing-space lines in the CP008 precommit TXT, documented with supplemental diagnostic. Human T approved; Git commit banked with 18 files and clean working tree. This is ONLY lexical analyst-owned CSV candidate form, NOT regular-file proof, exact physical filename resolution, governed CVT publication, CSV UTF-8 certification, full SOURCE eligibility, or requirement acceptance. Independent Claude implementation QA pending. CP009 Day066: match_analyst_csv_root_snapshot(&str, &[RootSnapshotEntry]) -> RootSnapshotMatch applies CP008 analyst CSV candidate preflight, then exact Rust string equality (case, Unicode scalar sequence and whitespace preserved), reports no match, reported nonregular entry, ambiguous duplicate exact entries, or single caller-reported regular file. Entry origin and kind are caller assertions, not independently verified. Eight new tests; post-format full native regression 36/36; wasm32-unknown-unknown library compilation exit 0; SHA-256 inventory verified 22/22; staged whitespace exit 0; T approved and git banked 15 files, clean working tree. This is NOT actual root scanning, filesystem entry proof, browser permission, CSV/UTF-8 certification, governed CVT SOURCE eligibility or end-to-end requirement acceptance; independent Claude QA pending. CP010 Day066 adds is_governed_cvt_source_filename_candidate(&str)->bool, requiring existing canonical immutable envelope validator, exact CVT class, and exact lowercase .csv serialization token. Four bounded tests pass and native full regression 40/40; wasm32-target library build PASS with Rust 1.97.1; format check PASS; primary 29/29 and supplementary 8/8 SHA-256 verification PASS; staged whitespace PASS with documented exact-file archival exceptions; T approval; git b7c515faa9bd000369d7656e09437310261290ae committed 28 files and clean working tree. No physical file checks, conversion execution, close/reopen, publication predicate, UTF-8/CSV certification, executable SOURCE authority or browser runtime proven. Independent Claude QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-010,WIP and WKO are distinct Work Order lifecycle states,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"WIP is the editable, non-executable Work Order state. WKO is the saved, validated, immutable Work Order artifact that may become a Run target. Validation establishes that a Work Order is structurally eligible to run; it does not guarantee that runtime conditions will succeed. Loading a WKO for inspection does not make it mutable. If its instruction text is changed, the editor must treat the edited text as a new WIP derived from the original WKO. The original WKO bytes and physical identity remain unchanged, and the derived WIP cannot Run until saved as a new WKO. F-08 Run distinction: the browser Run action invokes one selected saved immutable WKO that is eligible under the governed WKO-registry rules. No ordinary WASM-002 WKO contains a textual RUN line merely to execute itself. The DS-STEPS token RUN is reserved for future saved-Work-Order composition under W002-WKO-011 and is not repurposed as the browser execution trigger.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-013,WASM-002 executes one saved Work Order without Work Order chaining,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"For WASM-002, one saved immutable WKO is one top-level executable request. It must not invoke, include, chain, or execute another WKO. The governed RUN composition operation and equivalent nested-orchestration constructs are not executable in WASM-002. If a saved WKO contains composition syntax, validation must refuse before analytical execution begins. The canonical diagnostic and Help path must explain that Work Order composition is deferred rather than treating the syntax as arbitrary text, silently ignoring it, or partially executing surrounding instructions. This scope cut does not prohibit one Work Order from selecting and materializing multiple columns in the single Stage 2 operation defined by WASM-002.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012,Materialization COL alias assignment uses AS; standalone alias maintenance uses UPDATE ALIASES,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within the WASM-002 DS-STEPS materialization form, an analyst assigns or changes the alias of a selected materialized COL with the optional same-line clause AS ""alias"" under W002-STEPS-005. This syntax is part of the governed Work Order and is not a GUI gesture. A single KEEP block may therefore assign aliases to multiple selected columns in one governed materialization. Automatic source-header COL aliases and inherited rematerialization aliases are resolved first; explicit AS clauses then determine requested successor COL aliases before complete Store-MAP validation and publication. Revision BD freezes alias-only creation/replacement with UPDATE ALIASES and explicit historical Store-MAP selection with MAP ""<exact Store MAP filename>"" . Revision BE completes the bounded alias lifecycle with explicit CLEAR ... ALIAS and RESET ... ALIAS forms under W002-WKO-012.5 through W002-WKO-012.6. Empty-string AS """" is not the clearing syntax.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.1,Canonical standalone alias-maintenance Work Order uses UPDATE ALIASES,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"The canonical alias-only Store metadata forms are: SUITCASE: .
WORK ORDER AS ""Rename crime store""
SOURCE ""35100178.csv""
STORE AS ""Crime Statistics""
UPDATE ALIASES or, when the analyst intentionally selects one exact Store snapshot: SUITCASE: .
WORK ORDER AS ""Rename crime store""
MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""
STORE AS ""Crime Statistics""
UPDATE ALIASES UPDATE ALIASES is the explicit terminal commitment clause for an alias-only Work Order. The WKO must identify exactly one Store-state base using either SOURCE ""..."" for ordinary Store-aware current-state selection or MAP ""..."" for exact Store-MAP selection, never both. At least one supported alias mutation clause must occur after the Store-state selector and before UPDATE ALIASES . An alias-only Work Order must not contain KEEP , MATERIALIZE , INVENTORY , conversion, Store repair, Work Order registry repair, cataloging, deferred Work Order composition, or another operation's terminal clause. Alias maintenance changes governed human-facing metadata only.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.2,"STORE AS, RID AS, and COL ... AS are the canonical alias-replacement clauses",W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical mutation clauses are: STORE AS ""Crime Statistics""
RID AS ""Row Number""
COL ""Crime Rate"" AS ""Police-Reported Crime Rate"" STORE AS ""..."" replaces the selected Store snapshot's store_alias . RID AS ""..."" replaces its rid_alias . COL ""<reference>"" AS ""..."" replaces the alias of exactly one existing mapped COL. The COL reference resolves under W002-STOR-021: it may be the exact physical column_filename or one unique current COL alias from the selected Store MAP. Missing, ambiguous, non-COL, or conflicting resolution must refuse rather than guess. One Work Order may update the Store alias, RID alias, and multiple distinct COL aliases together, provided the complete successor state satisfies all existing alias uniqueness/shadowing rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.3,"MAP ""<filename>"" is the exact historical Store-MAP selector",W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"The canonical explicit Store-MAP selection clause is: MAP ""__DS__MAP__20260920T184512347Z__<uuid-v4>.csv"" The value is always the exact physical filename of one structurally valid immutable Store MAP. It is not a Store alias, WKO alias, timestamp shorthand, UUID-only selector, or latest expression. For MATERIALIZE, if present, the clause occurs immediately after SOURCE and before KEEP . It overrides automatic Store-MAP inheritance and binds the run to exactly the named Store snapshot. For alias-only maintenance, the Work Order uses either SOURCE ""..."" or MAP ""..."" as its Store-state selector, not both. For materialization, SOURCE ""..."" remains mandatory and an optional MAP ""..."" supplies the exact historical/current Store-state base. Validation must refuse an incompatible source/MAP pairing or a MAP that is not a valid Store-MAP profile. Health rule: explicit historical selection does not override the current Store-lineage health gate. The selected lineage must currently be VALID and every RID/COL binding referenced by the named MAP must currently be present and valid. Otherwise the operation refuses. This applies equally to MATERIALIZE and UPDATE ALIASES. F-05/P2-01 source-compatibility predicate: for materialization, an explicitly named MAP is compatible only when the mandatory Work Order SOURCE exactly equals the one common source_filename carried by that Store MAP. If the exact filenames differ, validation refuses before the F-04 existing-Store cardinality gate in W002-MAT-002.6. Equal row count never authorizes a different source to enter the selected Store lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.4,Alias-only execution publishes one complete successor Store MAP and no rewritten data artifacts,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"A successful UPDATE ALIASES operation begins from the selected complete Store MAP, applies only the requested alias replacements in memory, validates the complete resulting Store state, writes the successor MAP under governed SCR , closes and reopens it, validates it fully, and promotes it to a new immutable MAP last. That successful promotion is the alias-update commit point. The operation must preserve the selected Store's physical RID and COL filenames and bytes, source-column keys, row order, cardinality, and lineage except for the human-facing alias fields explicitly changed by the Work Order. It must not reread source data rows merely to change aliases, must not create RID/COL artifacts, and must not rewrite or delete the inherited MAP. The prior MAP remains visible historical state. If validation or MAP publication fails, no successor alias state becomes current. The failure is reported through the governed diagnostic/Help path and any incomplete candidate remains subject to the retained- SCR failure-evidence rules in W002-STOR-023.1; WASM-002 does not emit RCV. Revision BM E-02 integration: when the alias-only operation uses an explicitly named historical Store MAP, publication is permitted only if the Store lineage currently evaluates VALID and every RID/COL binding referenced by that named MAP is currently present and valid. An older MAP cannot be used to bypass current damage. P3-06 validation depth: because UPDATE ALIASES does not consume RID/COL analytical contents, its Store-health and binding checks use Tier 1 under W002-STOR-019.10. The operation must not scan every RID/COL record merely to change aliases. This does not weaken later operations that actually consume those artifacts; they must perform the applicable Tier 2 validation before relying on the contents.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-007,Standalone Store/RID/COL alias maintenance acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance must establish a Store with one RID and at least three materialized COLs, then execute an alias-only Work Order that changes the Store alias, RID alias, and at least two COL aliases in one UPDATE ALIASES operation. One COL must be targeted by its unique current alias and another by its exact physical COL filename. The fixture must prove that exactly one complete successor Store MAP becomes current; prior MAP, RID, and COL artifacts remain byte-for-byte unchanged; no source-data row read is required; no new RID/COL artifact is published; and the successor MAP contains exactly the requested aliases while preserving all physical bindings and logical source-column keys. Missing/ambiguous COL references and successor alias collisions must refuse without publishing a successor MAP. F-23 CLEAR/RESET alias fixtures: acceptance must separately exercise CLEAR STORE ALIAS , CLEAR RID ALIAS , CLEAR COL ""<reference>"" ALIAS , RESET STORE ALIAS , RESET RID ALIAS , and RESET COL ""<reference>"" ALIAS . Each CLEAR fixture must prove that the successor MAP stores the governed empty alias without renaming or rewriting the referenced artifact. Each RESET fixture must prove restoration of the exact deterministic default governed by W002-WKO-012.6 and W002-STOR-019.7, including the oversized-header operational fallback where applicable. The fixtures must prove that CLEAR and RESET require no source-data row read, publish exactly one complete successor Store MAP on success, leave the predecessor MAP/RID/COL bytes unchanged, and deterministically refuse duplicate mutation of the same alias field or a reset/default value that fails the complete successor alias validity/uniqueness/shadowing rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-008,Explicit historical Store-MAP selection acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance must create at least two valid Store MAP snapshots for one Store, then prove that a Work Order containing MAP ""<older exact Store MAP filename>"" binds to that exact older snapshot even though a newer valid MAP exists. An alias-only fixture must publish its successor from the explicitly named older base rather than from the newer automatic current state. A materialization fixture must retain mandatory SOURCE ""..."" while using the explicit MAP as its Store-state base. The tests must also prove refusal for a missing MAP, malformed MAP, WKO-MAP profile supplied as Store MAP, and source/MAP incompatibility. No implementation may substitute the newest MAP after an explicit MAP clause has validated. F-21 chronology acceptance: the fixture must use at least three successive valid MAP snapshots for one Store so that an explicitly selected older base and a distinct pre-run current MAP both exist. Merely selecting/validating the older MAP must leave current authority unchanged. A successful governed operation from that older base must then publish exactly one new successor whose requested state is derived from the named older base, whose publication UTC is later than the pre-run current chronology predecessor, and which becomes current under ordinary greatest-UTC selection. The selected historical MAP and the formerly current MAP must remain byte-for-byte unchanged. Acceptance must prove that later mappings/aliases present only in the formerly current MAP are not silently merged into the historical-base successor unless the Work Order explicitly recreates them. Receipt evidence must identify the exact operation base and exact published successor through the already-frozen operation-specific Receipt fields. No additional warning/permission gate or informational diagnostic is required merely because the analyst explicitly chose a historical base.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.5,CLEAR ... ALIAS deliberately removes a human-facing alias,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical clearing forms are: CLEAR STORE ALIAS
CLEAR RID ALIAS
CLEAR COL ""<reference>"" ALIAS CLEAR deliberately stores the empty string in the corresponding alias field of the successor Store MAP. It does not restore a default alias. An empty-string replacement such as STORE AS """" , RID AS """" , or COL ""..."" AS """" is not the canonical clearing form and must be rejected by the bounded WASM-002 grammar. For CLEAR COL , <reference> resolves against the selected pre-mutation Store MAP by exact physical column_filename or one unique current COL alias under W002-STOR-021. All COL references in one UPDATE ALIASES Work Order are resolved before any mutation is applied so clause order cannot change target identity. Missing, ambiguous, duplicate-target, or non-COL references must refuse. Clearing an alias never renames, rewrites, or deletes the underlying RID/COL artifact and never changes physical identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.6,RESET ... ALIAS restores the deterministic default alias,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical reset forms are: RESET STORE ALIAS
RESET RID ALIAS
RESET COL ""<reference>"" ALIAS RESET STORE ALIAS restores the Store MAP's common exact source_filename . RESET RID ALIAS restores the literal RID . RESET COL ""<reference>"" ALIAS restores that mapped COL's deterministic operational default defined by W002-STOR-019.7 from its exact recorded source_header and physical source ordinal: the exact header when it contains at most 1,024 Unicode scalar values, or the deterministic Column <LETTERS> fallback/disambiguation rule when the recorded header exceeds that boundary. RESET never substitutes the potentially oversized exact header into the alias field merely because that header remains authoritative source evidence. RESET is therefore distinct from CLEAR . The restored value must pass the same governed alias validity, uniqueness, and shadowing rules as any explicit alias. If the deterministic default is empty or conflicts in the complete successor Store MAP, RESET must refuse except for the narrow oversized-header fallback/disambiguation rule already frozen in W002-STOR-019.7; Data Sculptor must not otherwise invent a suffix, alternate spelling, or substitute. AS , CLEAR , and RESET mutations may coexist in one Work Order when they target distinct alias fields; duplicate mutation of the same alias field in one Work Order must refuse. A successful operation publishes exactly one complete successor Store MAP under the existing UPDATE ALIASES commit contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001,Canonical WASM-002 DS-STEPS materialization form,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 materialization Work Order form is: # Optional human comment
SUITCASE: .
WORK ORDER AS ""Prepare monthly crime data""
SOURCE ""crime.csv""
[MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""]

KEEP
  HEADER ""REF_DATE"" AS ""Year""      # reporting year
  HEADER ""GEO""
  COLUMN 7 AS ""Crime Rate""

MATERIALIZE SUITCASE: . is governed by W002-WKO-008. WORK ORDER AS ""..."" is mandatory for an executable/saved WASM-002 Work Order and declares the immutable human-facing WKO alias governed by W002-STEPS-001.1. SOURCE ""..."" names the exact Suitcase-root source file. MAP ""..."" is optional with cardinality 0..1. If present, it occurs immediately after SOURCE and before KEEP , names one exact physical governed Store MAP filename, and binds the run to that exact current or historical Store lineage subject to W002-STOR-019.3 and W002-WKO-012.3. If absent, the Store-aware exact-source routing rules apply. KEEP is the bare governed keyword and introduces one or more column selectors. KEEP: is not valid WASM-002 syntax. Each selector is either HEADER ""..."" or COLUMN n and may optionally end with AS ""..."" . MATERIALIZE is the explicit terminal commitment verb. Duplicate structural clauses refuse. An empty KEEP refuses. After MATERIALIZE , only blank lines or comments may follow; a trailing comment on the physical MATERIALIZE line is permitted because comments are removed from the semantic token stream. # comments are governed by W002-STEPS-001.2. No RID/row-index clause appears in the Work Order. If this materialization establishes a new Store, the engine automatically generates exactly one RID artifact under W002-RID-002 and W002-RID-008. If it extends an existing Store, the existing RID is reused subject to the Store health/cardinality rules. This requirement freezes the bounded keyword structure and selector forms shown above for BM integration. Other complete-language lexical features remain outside this bounded syntax freeze unless separately specified. F-08 common-grammar boundary: MATERIALIZE is one of the seven executable WASM-002 operation grammars governed by W002-WKO-007. Its optional MAP clause remains in the frozen position immediately after SOURCE and before KEEP . The terminal MATERIALIZE clause is DS-STEPS syntax; the browser's Run action is not written into the Work Order. F-20 bounded KEEP: the canonical KEEP block contains at least one and at most 16,384 selectors, and after resolution those selectors must identify at least one and at most 16,384 distinct source columns. This is the complete WASM-002 selection-width bound.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001.1,WORK ORDER AS declares the immutable human-facing Work Order alias,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"An executable or saved WASM-002 Work Order must contain exactly one top-level clause: WORK ORDER AS ""<alias>"" In canonical forms it appears after SUITCASE: . and before the operation-specific source/selector clauses. The decoded alias must be non-empty. The quoted alias may contain spaces and ordinary UTF-8 phrase text subject to the governed string-literal rules. The alias affects display and governed alias resolution only; it does not replace the WKO filename/UUID as physical execution identity. The alias is stored in the immutable WKO bytes and is published into the current WKO MAP when the WKO save transaction commits. Changing the alias therefore requires saving a new WKO under the frozen WKO lifecycle. No valid executable/saved WKO in WASM-002 is unaliased. P3-10 alias-content rule: “non-empty” means that, after decoding the quoted string literal, the alias must contain at least one non-whitespace character. An alias consisting only of whitespace refuses Work Order validation. Data Sculptor must not trim, collapse, normalize, or otherwise rewrite leading or trailing whitespace in an otherwise valid alias; the decoded alias text remains authoritative and is preserved exactly in the immutable WKO and governed WKO MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001.2,# introduces a DS-STEPS line comment outside double-quoted strings,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"Outside a double-quoted string, the first # on a line begins a comment that continues through the line's LF terminator. Whole-line comments and trailing comments are permitted. Comment text has no execution semantics and is ignored by the DS-STEPS parser after lexical recognition. A # inside a double-quoted string is ordinary string content and does not begin a comment; for example WORK ORDER AS ""Analysis #3"" and HEADER ""CATEGORY #"" preserve the hash character. WASM-002 defines no block-comment syntax. Comments are preserved byte-for-byte in the saved immutable WKO TXT. Editing, adding, or removing a comment changes the WKO bytes and therefore requires saving a new WKO artifact even though analytical semantics may remain unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-002,HEADER selects by exact decoded source-header value,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"HEADER ""name"" resolves against the exact decoded header values established for the certified source. Header equality is exact Unicode scalar-value sequence equality under PB-STOR-010: Data Sculptor performs no case folding, locale folding, Unicode normalization, trimming, or filesystem-style comparison. A selector that matches no source header must refuse. If the same exact decoded header sequence occurs in more than one source column, the header selector is ambiguous and must refuse rather than choose by position, discovery order, normalization, case-insensitive similarity, or another heuristic. An analyst can disambiguate duplicate exact header text with the 1-based COLUMN n selector. F-20 selector identity: HEADER always matches the authoritative exact decoded source header. It never matches an operational fallback name such as Column AA , a generated collision-disambiguation suffix, a COL alias, or a truncated form of the source header.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-003,COLUMN selects by 1-based source ordinal,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"COLUMN n identifies the source column by 1-based ordinal position. COLUMN 1 is the first source column. Zero, negative values, non-integers, and ordinals greater than the source width must refuse. Ordinal selection does not suppress source metadata: Data Sculptor must still resolve and record the selected column's actual decoded source header in the successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-004,HEADER and COLUMN selectors may be mixed but may not select one source column twice,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"One KEEP block may contain any supported mixture of HEADER and COLUMN selectors. Selector order expresses the analyst's requested selection order for the governed operation. After resolution, two or more selectors that identify the same physical source column constitute a duplicate selection and must refuse before materialization. Data Sculptor must not materialize the same source column twice merely because it was named once by header and once by ordinal.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-005,AS assigns the resulting materialized-column alias,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The optional clause AS ""alias"" belongs to the immediately preceding HEADER or COLUMN selector and expresses an intentional human-facing alias assignment in the governed Work Order. For a logical source column not present in the inherited MAP, omission of AS uses the exact source header as the default alias. For a logical source column already present in the inherited MAP, omission of AS preserves the inherited alias. An explicit AS overrides either default for the successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-006,The complete successor MAP must contain unique aliases,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"After inheritance, selector resolution, default-alias application, rematerialization continuity, and all explicit AS clauses are applied, every alias in the complete successor MAP must identify exactly one logical materialized column. If two different logical columns would have the same alias, including a collision with an inherited mapping, validation must refuse unless the Work Order has explicitly resolved the conflict through supported governed syntax. Data Sculptor must not invent suffixes such as Year_2 , use last-write-wins behavior, or silently shadow an existing alias. F-20 narrow generated-name exception: the prohibition on invented suffixes applies to ordinary source-header defaults and analyst-authored aliases. The only automatic suffixing permitted in WASM-002 is deterministic disambiguation of an oversized-header operational fallback under W002-STOR-019.7. That mechanism is not an alias-repair heuristic and must not be applied to an explicit AS value or to a short exact source-header default.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-007,MATERIALIZE commits the resolved KEEP set to the governed structural pass,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"MATERIALIZE is the explicit commitment verb for this WASM-002 DS-STEPS form. The KEEP selectors express which source columns belong in the operation; they do not themselves authorize data-row materialization. Before the bounded structural pass begins, the source, all selectors, actual source ordinals/headers, requested aliases, inherited alias state, and resulting alias uniqueness must be resolved and validated. Successful multi-column execution then follows the one-pass materialization contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-008,The Store MAP records resolved truth rather than selector spelling,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The successor Store MAP must record the fully resolved materialization result using the frozen eight-column schema store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename , regardless of whether the analyst selected a column with HEADER or COLUMN . For example, COLUMN 7 AS ""Crime Rate"" records the Store alias, RID filename/alias, common source filename, source ordinal 7 , the actual decoded header found at column 7, alias Crime Rate , and the newly generated physical COL filename. DS-STEPS expresses intent; the Store MAP persists the resolved durable mapping truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-009,DS-STEPS materialization syntax acceptance,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"Acceptance must cover: one column selected by exact header; one column selected by 1-based ordinal; mixed header/ordinal selectors in one KEEP block; multiple columns materialized in one governed structural pass; AS alias assignment; default header aliasing; inherited-alias preservation on rematerialization; explicit alias replacement on rematerialization; duplicate-header ambiguity refusal; invalid ordinal refusal; duplicate resolved-column refusal; and duplicate successor-alias refusal. Acceptance must also prove that the generated successor MAP records the same resolved source filename, source ordinal, actual source header, resulting alias, and physical COL identity whether a column was selected by header or by ordinal. For a new Store, both the single-column and multi-column materialization fixtures must contain no RID/row-index instruction yet must automatically publish exactly one RID artifact. For a later permitted same-Store materialization, the fixture must likewise contain no RID instruction and must reuse the original RID without publishing another. Damaged-lineage Help acceptance: fixtures must prove that exact source routing to an INVALID Store, and to a DEGRADED Store whose every mapped COL is broken, refuses ordinary materialization without silently treating the source as unseen. The canonical diagnostic/Help evidence must identify the blocked lineage/current MAP and preserve the frozen analyst-owned exits: external restoration under the original governed physical filename followed by governed validation; source rename to begin a distinct new Store lineage; or moving all lineage MAPs out of the active Suitcase to retire that lineage from routing. The all-COLs-broken fixture must warn that moving only the latest MAP is insufficient. No fixture may imply a new Data Sculptor recovery command, automatic RID regeneration, silent replacement of the damaged lineage, or historical byte identity based only on a restored filename. P3-06 validation-tier acceptance: acceptance must prove that a routine routing/status or alias-only path can use Tier 1 without an end-to-end scan of every RID/COL value, while an operation that consumes artifact contents performs Tier 2 before relying on them. Fixtures must include: a RID that passes Tier 1 but fails Tier 2 because its declared N /sequence is internally wrong beyond the Tier-1 boundary; a COL that passes Tier 1 but fails Tier 2 because its data-record count or CSV body is invalid beyond the Tier-1 boundary; and a REPAIR MAP fixture proving that the Tier-2 failure set determines exactly which COL bindings are removed. P3-07 routing acceptance: fixtures must prove that routing discovers a lineage from a structurally valid Store MAP regardless of whether later Store-health evaluation is VALID , DEGRADED , or INVALID . A separate fixture must present no routable lineage together with at least one structurally malformed Store-MAP-class artifact in the active Suitcase and prove that ordinary materialization refuses before publishing a new RID or first Store MAP, while Help identifies the malformed MAP artifact or artifacts. No fixture may treat an all-MAPs-damaged condition as permission for a silent replacement lineage. F-08 cross-operation grammar acceptance: fixtures must prove the common preamble, ASCII-case-insensitive keywords, exact quoted-value preservation, required SPACE/TAB token separation, unknown-line refusal, one-operation-per-WKO refusal, and separation between DS-STEPS terminal phrases and Receipt OPERATION tokens. At least one fixture for each of the seven executable operations must prove that its canonical structure validates while an otherwise similar WKO containing another operation's terminal clause refuses. Separate fixtures must prove that browser Run does not require a textual RUN clause and that parsed RUN composition syntax refuses as deferred before analytical execution. P2-04 restoration-language acceptance: Help, diagnostics, UI text, and acceptance evidence may say that a file restored under the exact governed physical filename passed the required validation tier and may therefore re-enter use. They must not state or imply that filename equality alone proves restoration of the historical original bytes. If stronger historical-byte identity is desired, Help may point to the separately governed explicit fingerprint/LCK direction rather than silently hashing ordinary Store artifacts. F-20 selector/name/width acceptance: fixtures must additionally prove that HEADER resolves only against exact decoded source-header text and never against an operational fallback/default alias; a KEEP selecting all 16,384 columns is valid; a source wider than 16,384 refuses before data-row materialization; and RESET of an oversized-header COL restores the deterministic operational fallback rather than the exact oversized header as alias text. F-03 Store-health and REPAIR MAP acceptance set Target required: REPAIR MAP without exactly one current Store MAP target refuses. Historical target: a structurally valid but non-current historical Store MAP refuses for repair. Wrong profile: a WKO MAP supplied as the repair target refuses. DEGRADED repair: one or more broken COL bindings are removed while every valid binding and the exact RID identity are preserved. All COLs broken: repair refuses, publishes no successor MAP, and the Store remains DEGRADED . Malformed newest MAP: current-state resolution falls back to the greatest earlier structurally valid MAP in the same lineage and reports the malformed artifact. Missing COL in current valid MAP: no fallback occurs; the current MAP remains current and the Store evaluates DEGRADED . Missing RID in current valid MAP: no fallback occurs; the current MAP remains current and the Store evaluates INVALID . Original RID externally restored: the Store is re-evaluated after governed validation without Data Sculptor creating or inferring a replacement RID. No silent fork: neither DEGRADED nor INVALID permits ordinary materialization to create a replacement Store for the same routed lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-003,Suitcase-relative Work Order portability acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must execute a saved WKO containing SUITCASE: . and ordinary Suitcase-relative file references, then move the intact fixture Suitcase to a different permitted parent path and execute the same saved WKO again. Resolution must identify the same logical Suitcase files without editing the WKO to insert the new absolute machine path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-004,WIP/WKO lifecycle acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance evidence must show that an editable WIP cannot Run; saving a valid WIP produces a distinct immutable WKO Run target; loading that WKO and changing instruction text creates a new non-runnable WIP; and the original WKO bytes, filename, identity, and provenance remain unchanged. F-02 alias-registry lifecycle acceptance: a first save for an unused alias must publish a successor WKO MAP containing exactly one CURRENT row for that alias. Saving a second valid WKO with the same exact alias must surface exactly Replace alias target and Cancel . The Cancel fixture must leave the predecessor WKO MAP authoritative and must not commit the pending WKO/WKO-MAP pair as a registry update. The Replace fixture must publish a successor WKO MAP in which the former owner is DEPRECATED , the new WKO is the sole CURRENT row for that alias, and any earlier deprecated history remains preserved. The former WKO bytes and filename and every predecessor WKO MAP must remain unchanged. Alias resolution against the successor registry must resolve to the new CURRENT row and never to a DEPRECATED row. A malformed fixture containing more than one CURRENT row for one exact alias must fail structural validation rather than choose by filename UTC, modified time, discovery order, or row order. P2-03 WKO-registry clock acceptance: using a deterministic injected clock seam, acceptance must prove that a successor WKO MAP publishes only when the observed transaction UTC is strictly greater than the current structurally valid WKO MAP UTC; equal-millisecond and backward/future-dated-predecessor cases refuse without committing the new WKO/registry state. The diagnostic must expose predecessor_map_filename , predecessor_utc , and observed_host_utc . A separate fixture must deliberately move the future-dated current WKO MAP out of the active Suitcase, rescan, and prove deterministic reselection of the remaining current structurally valid WKO MAP without Data Sculptor silently moving or deleting anything itself. Day 060 H-12: every equal/backward/future-predecessor chronology refusal in this acceptance set must emit DS-UTC-001 with exact map_profile: WKO , observed_host_utc , predecessor_map_filename , and predecessor_utc facts. F-23 save-transaction filesystem-fault fixture, reconciled by F-33: using a controlled create/write/close/rename/promotion failure at a deterministic point after a valid WIP has entered the governed save path, acceptance must prove that a failed WKO/WKO-MAP save is never represented as a committed alias-registry update. The pre-run current WKO MAP must remain authoritative; no malformed or unpromoted candidate may become current; and any rollback or retained SCR evidence must follow W002-STOR-018.3 and the shared non-Store publication/retained-evidence contract. No RCV artifact is emitted. F-02 registry-repair acceptance set Deadlock escape: with a repair-required current WKO MAP, a newly saved structurally valid repair-only WKO can Run by exact filename and successfully publish a repaired successor registry. No broad bypass: a newly saved unregistered WKO for any other operation remains ineligible to Run. Missing reference: repair removes a stale registry row but does not recreate the missing WKO, substitute a historical WKO, or promote an older WKO automatically. Discovered alias, no owner: one discovered valid WKO with an otherwise unowned alias becomes CURRENT . Discovered alias collision: a discovered WKO whose alias is already owned by a surviving CURRENT row becomes DEPRECATED . Several discovered WKOs, no owner: all become DEPRECATED ; no winner is inferred by UTC, filename, UUID, directory order, discovery order, or modified time. Mandatory alias: an unaliased WKO cannot be structurally valid. Line endings: otherwise-identical structurally valid WKO fixtures with LF and CRLF line endings are accepted; the lone-CR form refuses. Deterministic successor: repaired successor rows serialize in ascending UTF-8 byte order of exact wko_filename . Historical Run: a registered DEPRECATED WKO can Run by exact physical filename but not by alias. Receipt identity: a successful or refused registry-repair Receipt uses REPAIR_WORK_ORDER_REGISTRY as the operation token. Day 060 H-10 / BM-07 registry-repair Receipt-count acceptance Acceptance must include a successful repair-required-registry fixture in which the exact repair-only bootstrap WKO is initially visible and unregistered, runs by the bounded exact-filename bootstrap, and is then registered by the repair result. The committed successor WKO MAP must contain the repair WKO row. The successful Receipt must list that exact repair WKO under either REGISTERED_CURRENT_WKO_<INDEX>_FILENAME or REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME , according to the ordinary alias-ownership rule. The corresponding REGISTERED_*_COUNT must equal the number of newly registered rows in that status class, including the repair WKO when applicable. Pre-existing surviving CURRENT / DEPRECATED rows in the base registry must not inflate either registered count. A fixture containing both pre-existing surviving rows and newly registered rows must prove that the Receipt reports the repair change set while the successor MAP reports the complete resulting registry state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-005,"Store MAP inheritance, historical override, and immutable snapshot acceptance",W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must execute a saved Store-establishing Work Order containing multiple COL alias assignments when no routable Store lineage exists and no structurally malformed Store-MAP-class artifact is present , and prove that exactly one new immutable complete Store MAP is created while the GUI supplies no alias-edit gesture and target artifacts remain unchanged. A later Work Order with the same exact source and no explicit MAP must route to that Store's lineage and inherit its unique newest permitted MAP automatically. Another Work Order must explicitly select an older valid MAP even though newer MAPs for that Store exist and prove that Store/RID binding, alias resolution, and inheritance use exactly the named historical MAP instead. A fixture specifying more than one MAP must refuse. A fixture with two otherwise permitted current MAP candidates for the selected Store sharing the greatest UTC millisecond timestamp must refuse automatic inheritance rather than use UUID as chronology. A separate fixture must remove or corrupt every Store MAP in a prior lineage so that no structurally valid Store MAP remains while at least one malformed Store-MAP-class artifact remains visible in the active Suitcase. Re-running ordinary materialization must refuse before creating a new RID or first Store MAP, and Help must identify the malformed MAP artifact or artifacts. P2-03 Store chronology acceptance: injected-clock fixtures must prove later observed UTC success, equal-millisecond refusal, backward-UTC refusal, and a genuinely future-dated current Store MAP that remains current while blocking successor publication. Every refusal must leave the chronology predecessor unchanged and publish no successor Store MAP. A historical-base fixture must derive requested state from an older eligible MAP while proving that the strict-greater-than comparison uses the actual current Store MAP as chronology predecessor, not the historical base. A deliberate analyst-removal fixture must move the future-dated current MAP out of the active Suitcase and prove deterministic reselection of the remaining structurally valid history; restoring that MAP must make ordinary greatest-UTC authority rules applicable again. Day 060 H-12: every equal/backward/future-predecessor Store-MAP chronology refusal in this acceptance set must emit DS-UTC-001 with exact map_profile: STORE , observed_host_utc , predecessor_map_filename , and predecessor_utc facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-006,Work Order chaining refusal acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must submit a structurally saved WKO containing a RUN or other recognized Work Order-invocation construct and prove that WASM-002 refuses it during validation before Stage 1, Stage 2, conversion, inventory, or other governed execution begins. The diagnostic/Help output must identify composition as deferred functionality. A separate multi-column MATERIALIZE fixture must still succeed, proving that multiple selected columns inside one Work Order are not misclassified as Work Order chaining.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-001,One explicit Work Order command surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser front end shall use the Work Order editor as the single human command-entry surface for governed execution. It shall not expose a second interactive command prompt or point-and-click analytical path that can become an independent source of analytical intent. The editable draft may be syntax-highlighted, validated, and saved, but it is not itself executable authority. The browser Run action operates only on one loaded/selected saved immutable WKO that is eligible under the governed Work Order registry rules. Run is a browser action, not a line that ordinary WASM-002 Work Orders must contain. If a WKO contains the reserved DS-STEPS RUN composition token, WASM-002 refuses before executing any child or top-level analytical operation because saved-Work-Order chaining is deferred. The token remains reserved so later ordered composition can be added without repurposing existing syntax. F-24 fresh-application state: each new Data Sculptor browser application instance begins without a selected Suitcase and without a restored unsaved Work Order draft. Initial page load and full reload therefore return the command surface to the pre-Suitcase gate. A previously selected folder, loaded WKO, or dirty WIP must not be silently reconstructed from browser-private persistence.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-002,Front end presents and authorizes; shared Rust core decides,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser front end may authorize files, edit and validate Work Orders, invoke the shared engine, display governed state, render diagnostics, and present generated artifacts. It must not independently decide analytical truth, silently reinterpret a Work Order, or implement a competing semantic path. Where front-end presentation and shared-core semantics disagree, the shared governed semantics and frozen requirements are authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-003,Visible Suitcase and governed run context,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser surface shall make the currently validated Suitcase visible and shall expose the visible files in that folder. Source and requested-column context become governed execution state only when a saved Work Order resolves them; the UI must not imply that directory presence alone means a source has been selected, scanned, certified, or materialized.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-004,Certification gate is visible and blocking,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The front end shall visibly represent strict whole-file UTF-8 certification as a required stage before analytical materialization. A certification refusal must stop the current analytical Work Order, prevent later materialization stages from being presented as successful, and provide the canonical diagnostic / Help path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-005,One-pass multi-column materialization is represented truthfully,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"When a valid Work Order requests multiple source columns, the front end shall represent them as one governed multi-column materialization request through one bounded structural CSV pass, not as unrelated per-column scans when the frozen engine contract performs one pass. Requested columns must be validated before data-row materialization begins, consistent with the materialization requirements.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-006,Visible Suitcase Directory is the artifact orientation surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"After Suitcase validation, the browser shall present a human-readable directory view of the visible files in the selected Suitcase, including physical filename, read-only governed alias where applicable, file type, and size. Governed artifacts created by a run shall appear in that same visible inventory after refresh or update. The directory is an orientation and metadata surface over the real flat Suitcase. It is not a hidden browser cache, a second persistence system, or an analytical command surface. CAT integration: this existing directory remains the sole WASM-002 artifact-orientation surface. CAT and MAP artifacts are first-ranked under W002-CAT-UI-001 through W002-CAT-UI-008; no second catalog browser is introduced.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-007,All user-facing Help flows through the Help Engine,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"All Data Sculptor-controlled user-facing Help messages, warnings, refusals, explanations, validation guidance, safe-next-action messages, and governed success/status messages that participate in the Help/status/evidence system shall be produced through the Help Engine from governed facts or canonical diagnostic events. Individual UI controls must not maintain an independent competing stock of semantic Help text. Governed success/status events in this system use canonical INFO diagnostics. Ordinary static labels, headings, decorative copy, and presentation-only UI text are not diagnostics and need not be routed through the diagnostic registry merely because they are visible. Help voice may change wording and depth but must not change diagnostic identity, evidence, severity, refusal/continue behavior, provenance, or safe next action. Durable Help Reports derive from the same governed truth. F-17 fallback behavior: when a complete registered diagnostic lacks an authored help_messages.json entry, the UI must show the deterministic Generic Technical Help rendering from W002-HELP-002.9 for Casual, Office Speak, and Technical selections rather than a blank state, guessed prose, or UI-local explanation. When diagnostic assembly itself fails its required-fact contract, the UI presents DS-HLP-001 ; it must not display the incomplete intended diagnostic as if valid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-008,Legacy encoding conversion remains a separate operation,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"If UTF-8 certification fails and the bytes are eligible for the separately governed Windows-1252 compatibility/conversion path, the front end may explain or help draft that separate conversion Work Order. It must not silently reinterpret the failed analytical Work Order as Windows-1252 and continue materialization. P3-08 front-end disclosure: after a successful conversion, the visible result/Help path must identify the exact published CVT filename and explain that it is a new source identity for later Store routing. When that CVT is subsequently chosen for first materialization, the front end must not present the action as a refresh of an earlier conversion-derived Store merely because the analyst-owned input filename is the same; it must preserve the governed Help disclosure that each distinct CVT is a distinct source artifact and lineage input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-009,Front-end branding is presentation-only,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser front end shall use the canonical built-in Red5Sorcery/Data Sculptor branding and approved presentation tokens without changing analytical or diagnostic meaning. The current Red5Sorcery identity treatment, including the red “5”, remains the active WASM-002 design direction. Configurable Brand Manifest loading, validation, selection, and substitution are deferred to V1-BACKLOG / a future build whose number is not yet assigned.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-010,WASM-002 front end must not preview deferred analytical features as available controls,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 front end shall stop at the capabilities allocated to the WASM-002 build slice. It shall not present filtering, grouping, sorting, Quick Viz, PRETTY Tables, DS-VERIFY, or later filter-driven build/export workflows as executable WASM-002 controls unless their individual requirement SCOPE is deliberately changed and frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PLAT-001,WASM-002/V1 browser and modest-hardware acceptance baseline,W002-PLAT,W002-PLAT,WASM-002,UNDER REVIEW,—,"The canonical modest-hardware acceptance machine for the WASM-002 browser release and the browser path carried into V1 is the project's 11-inch Windows 11 laptop with an Intel N100 processor, 16 GB RAM, and a 1920×1200 native display. Each acceptance record must capture the exact tested Windows build, browser version, Windows display scaling, browser zoom, and materially relevant machine configuration. Those observed version and presentation settings are acceptance evidence; they do not become timeless minimum-version requirements unless separately frozen. V1 browser support is scoped to certified desktop Chromium hosts that expose the user-selected writable-directory and file-publication capabilities required by the visible Suitcase contract. Microsoft Edge is the primary certified browser. Google Chrome is the secondary certified browser. Another Chromium-derived browser may work, but Data Sculptor must not claim it as a certified V1 browser until that browser has passed the applicable acceptance suite. Firefox and Safari are not supported V1 browser hosts under this contract and their lack of the required filesystem capability must not block V1 release. Supported-host acceptance must exercise the real browser filesystem path: explicit user-selected Suitcase access, CER validation, governed Work Order save/Run behavior, and governed artifact publication. Data Sculptor must not substitute OPFS, IndexedDB, download-only publication, a browser extension, or another hidden/different persistence model merely to make an unsupported browser appear supported. Required filesystem capability is feature-detected before folder validation begins. If the host cannot expose the governed writable-directory contract, Data Sculptor must treat that state as a host-capability refusal , keep governed save/Run/analytical controls locked, and route the explanation through the canonical diagnostic/Help path. It must not claim that a particular user folder failed validation when no folder could actually be tested.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-011,"Keyboard-operable, small-screen browser shell",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The required WASM-002 front-end interactions shall remain operable from a keyboard and usable on the canonical modest-hardware/small-screen baseline defined by W002-PLAT-001. At the display scaling and browser zoom recorded for acceptance, every required control and governed surface needed to complete the supported workflow must remain reachable without changing those settings merely to reveal an otherwise inaccessible control. Responsive reflow and ordinary scrolling are permitted; this requirement does not demand that every panel be visible simultaneously. Visible labels must carry meaning without relying on color alone. Exact shortcut assignments are presentation details unless separately frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-012,"Reference prototype is evidence, not a shadow specification",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Day 043 HTML prototype embedded below is retained as concrete design evidence for the WASM-002 browser workbench. Its layout, simulated analytical execution, illustrative Work Order grammar, current aliases, demo shortcuts, artifact examples, and other unfrozen literals do not become normative merely because they appear in the prototype. If the embedded prototype conflicts with a numbered requirement, the numbered requirement governs and the prototype must be revised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-013,Dedicated persistent Help / Diagnostic Surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The primary WASM-002 workspace must reserve a dedicated Help / Diagnostic Surface with stable layout presence. When a governed diagnostic is active, the analyst must be able to view its explanation without losing sight of the Work Order and the execution/source context required to understand it. The persistent surface is a viewport into canonical diagnostic truth; it is not a second state authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-014,Governed analytical refusals are not modal- or toast-only interactions,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,An application-controlled modal dialog must not be the primary presentation of a governed analytical refusal when it would obscure the Work Order or execution context. A transient toast or timed notification must not be the sole carrier of governed diagnostic truth. Browser- or operating-system-controlled permission/security dialogs are outside this requirement because Data Sculptor does not control their presentation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-015,Idle Help state remains semantically quiet,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"When no canonical diagnostic is active, the Help / Diagnostic Surface should communicate only restrained readiness/idle state rather than becoming a general dashboard for unrelated metrics, checkpoints, or project status. Exact wording such as “No active diagnostic. Ready.” is presentation detail unless separately frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-016,Help surface exposes a direct saved-report action,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"From an active governed diagnostic, including a non-run diagnostic, or from one governed Run whose diagnostic history is available to the Help surface, the browser Help / Diagnostic Surface must provide an explicit action to generate the durable HTML Help Report. Each explicit report request publishes exactly one HLP under W002-HELP-003.2 and W002-HELP-009. The generated report must become a visible Suitcase artifact governed by the Help, PRETTY, persistence, and provenance requirements and must use the canonical built-in Data Sculptor presentation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-017,Writable Suitcase validation is the first interaction gate,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Before Data Sculptor enables Work Order saving, governed Run, or analytical processing, the analyst must choose one Suitcase folder and Data Sculptor must validate that folder by successfully creating, completely writing, and closing one governed HTML Suitcase Validation Certificate under W002-STOR-022 through W002-STOR-022.3. Permission state or directory enumeration alone is not sufficient to pass the gate. The successful certificate remains visibly in the Suitcase as durable evidence. Validation does not require deleting or renaming the certificate. Until the certificate write/close succeeds, the analytical workspace remains locked except for Help and Suitcase selection. Browser- or operating-system-controlled refusal of protected directories is outside Data Sculptor presentation control and must be explained through the Help Engine when the host can observe the refusal. F-24 opening/selection lifecycle: merely loading Data Sculptor does not create a CER. A CER is published only after an explicit Suitcase selection successfully passes the governed validation gate. Reselecting and successfully validating the same physical Suitcase is a new certification event and publishes one new CER; all earlier CERs remain untouched. Data Sculptor does not remember the directory handle between application instances, so a new load/reload requires explicit Suitcase selection again before the workspace can unlock.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-018,Suitcase Directory enumerates visible files before analytical work,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Immediately after Suitcase validation, Data Sculptor shall enumerate the visible files available through the authorized directory handle and show them in the Suitcase Directory. No source, header, column, certification, or materialization state shall be inferred merely from the existence of those files.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-019,Directory inventory and displayed aliases must not become point-and-click analytical intent,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Suitcase Directory may expose file inventory and read-only human-facing metadata such as aliases, but it shall not provide alias-edit controls, “Use as source,” column-pick, materialize, filter, or equivalent governed-action controls. Source files, requested columns, alias mutations, and analytical operations are stated in saved Work Orders and resolved by the governed engine.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-020,Saved Work Orders are the only Run targets,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Work Order editor may create a new draft or load a saved Work Order TXT artifact from the validated Suitcase. A loaded saved Work Order is an immutable Run target and may be inspected or run directly. If the analyst changes its instruction text, the editor must transition to a new draft derived from that saved Work Order; the draft is not runnable until it is saved as a new immutable Work Order with a new governed physical identity. The original saved Work Order remains unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-021,User chooses the Suitcase; Data Sculptor chooses generated filenames,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"For Work Orders, materialized columns, Help Reports, receipts, maps, and other Data Sculptor-generated artifacts, the analyst chooses or has already chosen the validated Suitcase folder. The browser shall not require the analyst to supply an output filename for those governed artifacts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-022,"Execution Output is read-only observation, never command input",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser shall provide a read-only Execution Output surface that reports which saved Work Order was run, how its source and governed aliases resolved, which execution stages occurred, what was refused, and which governed artifacts were created or assigned. For WASM-002 it does not display a nested Work Order invocation chain because Work Order composition is deferred. The surface shall not accept commands, analytical text, or cursor-driven execution input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-023,The browser has no separate Work Order Description field,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser must not expose a standalone editable Description field for a saved or draft Work Order. Human-facing Work Order naming is authored in DS-STEPS with the required WORK ORDER AS ""..."" clause inside the Work Order itself. The Saved Work Order chooser and Suitcase Directory may display governed WKO alias/lifecycle information from the current structurally valid WKO MAP . Where lifecycle information is shown, CURRENT and DEPRECATED are read-only governed registry state, and the exact physical WKO filename must remain available/visible so human meaning, lifecycle authority, and physical identity remain distinct. Alias resolution uses the sole CURRENT row for the exact alias; a DEPRECATED row is historical evidence rather than the alias target. If that current registry references a missing physical WKO, the MAP remains current and the registry is repair-required; the browser must not silently display an older WKO MAP as though it had become current merely because of the missing reference. A structurally malformed newer WKO MAP never becomes current and is reported through Help/evidence surfaces. Editing a loaded saved WKO—including changing its alias or comments—creates a derived draft that must be saved as a new immutable WKO before it can Run. If that save would supersede the existing CURRENT target for the same alias, the save flow follows the exact Replace alias target / Cancel decision in W002-STOR-018.3; the UI must not provide a separate direct registry-edit gesture.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-024,Suitcase Directory aliases are read-only views of governed MAP profiles,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Alias displays in the Suitcase Directory are observation-only. Store, RID, and materialized-COL aliases are read from eligible Store MAP state. Saved Work Order alias and lifecycle state are read from the current structurally valid WKO MAP. The browser may aggregate those governed sources into one human-facing directory view while keeping exact physical filenames available for inspection. For WKO rows, CURRENT / DEPRECATED is read-only governed lifecycle metadata. A CURRENT row identifies the registry target for that exact alias; a DEPRECATED row remains historical registry evidence and must not be presented as the current alias target. The GUI must not expose an input, inline editor, context action, or other non-Work-Order path that directly mutates governed aliases or WKO lifecycle status. Store/RID/COL alias mutation remains Work-Order-governed. WKO aliases are authored inside immutable WKO text with WORK ORDER AS and enter or change WKO alias-registry authority only through a successful governed save transaction under W002-STOR-018.3.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-025,The browser has exactly two governed built-in presentation themes,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser presentation contract exposes exactly two governed theme choices: Modern Dark and Modern Light . Custom presentation is deferred to V1-BACKLOG / a future build not yet numbered. A Terminal theme is not part of the WASM-002/V1 browser contract and must not be exposed as a governed theme choice. Theme selection is presentation-only. It must not change Work Order semantics, source resolution, diagnostic identity or facts, continue/refuse decisions, analytical values, Receipt truth, or other governed execution meaning. The selected browser theme does not control durable HLP or CER presentation in WASM-002. Those governed HTML artifacts use the canonical built-in Red5Sorcery/Data Sculptor presentation regardless of whether the live browser is using Modern Dark or Modern Light. F-24 session default and persistence: Modern Dark is the canonical theme at the start of every new browser application instance. The analyst may switch to Modern Light during that instance, but WASM-002 retains the choice only in volatile runtime state and does not persist it in browser-private storage. A new application instance therefore returns to Modern Dark.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-026,Flight Recorder is a read-only derived Receipt-history surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser may present a Flight Recorder surface that is derived exclusively from governed RCP Receipt artifacts currently visible in the authorized Suitcase. The surface is read-only and regenerable. It must not create or maintain a second execution-history database, mutable log, hidden cache, browser-private history, or alternate chronology authority. The Flight Recorder may sort, filter, group, or summarize Receipt-derived facts for human orientation, but those presentation operations must not alter Receipt bytes, invent missing events, or become authoritative over the underlying immutable Receipts. Where no canonical Receipt exists because Receipt publication failed, the surface must not reconstruct a substitute original Receipt from UI state, console text, or memory.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-001,Single-command-surface and saved-run-target acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The acceptance check must show one Work Order editor that can hold either a new draft or a loaded saved Work Order and no second independent prompt, command-entry cursor, point-and-click source selector, or point-and-click column selector. A governed browser Run must read exactly one loaded/selected saved immutable WKO artifact that is eligible under the current registry rules. An unsaved WIP must not Run. Editing the instruction text of a loaded saved WKO must transition the editor to a new draft state that cannot Run until saved as a new immutable WKO. A fixture containing the exact reserved semantic token RUN as a Work Order composition construct must refuse before any governed operation executes and must reach the deferred-composition Help path. A near-synonym such as CALL , EXEC , or INCLUDE must not be silently accepted as composition syntax.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-002,Certification-refusal gating acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a source fixture that fails strict UTF-8 certification, the browser must show certification failure, leave later analytical stages unaccepted, produce no materialized analytical outputs, preserve the source unchanged, and expose the canonical Help path. The retained event/Receipt evidence must agree on STAGE1_UTF8_OUTCOME: FAIL , exact UTF8_FIRST_INVALID_BYTE_OFFSET , and UTF8_STOP_REASON: INVALID_UTF8_SEQUENCE . The canonical diagnostic event must expose the same meaning through lower-case facts first_invalid_byte_offset , source_filename , and stop_reason .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-003,Multi-column path acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a valid UTF-8 source and a Work Order requesting at least two source columns, the browser must show successful certification followed by one governed structural materialization pass and then expose the resulting visible Suitcase artifacts required by the build contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-004,Diagnostic/Help parity acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"For at least one real WASM-002 refusal path, the live message, each supported Help voice, and the durable HTML Help report must resolve from the same canonical diagnostic event and preserve the governed facts, severity, provenance, refusal behavior, and safe next action.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-005,Visible-persistence and Suitcase-directory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"A completed governed browser run must be auditable from the visible Suitcase artifacts required by the build contract, and newly created governed artifacts must become visible through the Suitcase Directory. Acceptance evidence must show that Data Sculptor did not intentionally persist project or analytical state in browser-private storage as a substitute for those artifacts. F-24 session/CER lifecycle acceptance: acceptance must begin from a clean application instance and prove all of the following in one controlled sequence: no Suitcase is selected or silently recovered; Work Order saving and governed Run remain gated; the live browser defaults to Modern Dark and Technical Help; explicitly selecting and successfully validating a writable Suitcase publishes exactly one fresh CER and unlocks the workspace; after switching to Modern Light and a non-Technical Help voice and creating a dirty unsaved WIP, an ordinary reload/navigation path triggers the browser-supported unsaved-change warning where the host permits it; after proceeding with reload, the Suitcase handle, non-default theme, non-default Help voice, and dirty WIP are not restored from Data Sculptor-controlled browser-private persistence; reselecting and successfully validating the same Suitcase publishes a second distinct CER while the first CER remains present under its original governed filename and exact bytes; and no automatic CER-history ZIP, compaction, replacement, or deletion occurs. The acceptance record must inspect the relevant Data Sculptor-controlled browser persistence surfaces and show that no persisted project/session record was used to restore the Suitcase handle, WIP, theme, or Help voice. WASM-002 does not claim dirty-draft warning or recovery after browser crash, forced process termination, operating-system failure, or power loss.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-006,Scope-surface acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The frozen WASM-002 browser build must not expose executable controls for requirements whose current SCOPE remains V1-BACKLOG, POST-V1, OUT-WASM-002, or otherwise outside the frozen WASM-002 build slice.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-007,"Small-screen, keyboard, and certified-browser acceptance",W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"On the canonical Intel N100 / 16 GB Windows 11 laptop and its 1920×1200 display, acceptance must record the Windows build, display scaling, browser zoom, and exact browser version. In the primary certified Microsoft Edge host, the required browser controls, Work Order editor, governed-stage status, artifact/result surface, and diagnostic/Help surface must remain reachable and usable without requiring an IDE or developer tools, and the required interaction path must be completable by keyboard. Ordinary scrolling and responsive reflow are allowed; changing scaling or zoom merely to expose an otherwise unreachable required control is not. The same canonical machine must also exercise the supported-host Suitcase → CER → Work Order save/Run → governed publication path in the secondary certified Google Chrome host. Chrome must satisfy the same governed filesystem and semantic contract; browser-specific presentation differences do not permit different analytical meaning or a different persistence model.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-008,Persistent diagnostic co-presence acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,Triggering a real governed refusal must leave the Work Order and relevant execution/source context available while the diagnostic is visible in the dedicated Help surface. The refusal must not depend on an application-controlled modal dialog or transient toast as its sole presentation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-009,Idle-state discipline acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"With no active diagnostic, the dedicated Help surface must remain present but semantically quiet and must not aggregate unrelated project/dashboard state as a substitute for its diagnostic purpose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-010,Saved-report action acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"From a displayed real diagnostic event, including a governed non-run diagnostic, the user must be able to invoke the Help-report action and obtain the corresponding durable HTML Help Report as one visible governed artifact without manually copying diagnostic text or reconstructing the event. A governed Run fixture containing multiple diagnostic events must also permit one explicit Run-level Help Report request and must produce exactly one HLP for that request. The HLP must identify the included diagnostics in deterministic event order and must not create one HLP automatically for each diagnostic.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-011,Suitcase-first gate and supported-host capability acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"With no Suitcase validated, Work Order saving, governed Run, and analytical processing controls must be unavailable. Acceptance first proves supported-host capability under W002-PLAT-001. Microsoft Edge and Google Chrome acceptance must each expose the required user-selected writable-directory path; Data Sculptor must not satisfy this gate through OPFS, IndexedDB, download-only output, a browser extension, or another substitute persistence model. Acceptance must enumerate every governed final-artifact filename form and SCR staging form that WASM-002 can emit, derive the longest canonical filename length, and verify that the current contract yields 73 ASCII bytes/characters . The canonical __DS__CER__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html form is one of the forms at that maximum and is used for the actual create/write/close folder-validation test. After the analyst selects a writable test folder on a supported host, Data Sculptor must create one retained governed certificate whose filename matches that canonical CER form, completely write and close it, and expose it in the visible Suitcase Directory. The certificate must contain the semantic fields and limitation statements required by W002-STOR-022.2. Only after that certificate operation succeeds may the workspace unlock. A failure to create, completely write, or close the certificate after actual folder selection must leave the workspace locked and surface the canonical diagnostic/Help path. Separately, a deterministic missing-capability acceptance fixture must prove that a host lacking the required writable-directory contract refuses before folder validation, leaves the workspace locked, and does not mislabel an untested folder as unwritable. Acceptance must not depend on a hard-coded operating-system path-length number, deletion of the certificate, or a validation-only rename. If the emitted-name inventory changes so that another form exceeds the CER maximum, this acceptance gate must fail until the new maximum is explicitly exercised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-012,Directory-is-inventory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"After Suitcase validation, the visible directory must list a mixed fixture set including at least one CSV and one non-CSV file with their physical names, types, and sizes. The directory must expose no “Use as source,” column-pick, or materialize action that bypasses the Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-013,Generated Work Order identity and immutability acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,Saving a valid draft must create a new TXT artifact whose physical name matches the frozen Work Order filename contract and must not open a filename-entry Save As path. Editing the draft and saving again must create a different Work Order identity; the first saved TXT bytes and filename must remain unchanged.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-014,Work-Order-only source and column selection acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a Suitcase containing multiple candidate files and a CSV with multiple headers, the analyst must be able to request the source and materialized column solely through a saved Work Order. Acceptance must show that the browser performs no separate point-and-click source or column selection. F-26 SOURCE eligibility fixtures: the acceptance set must prove all of the following under W002-WKO-009.1: analyst-owned root files ending .csv , .CSV , and a mixed-case equivalent are recognized as CSV candidates; the complete physical filename reference remains exact and case-sensitive under F-15; an analyst-created __DS__notes.csv is refused as an analyst-owned SOURCE; a valid published CVT is accepted; a canonical-looking or renamed file that does not satisfy the governed CVT validity/publication contract is refused; governed non-CVT classes including COL are refused as SOURCE; a non-CSV analyst-owned extension is refused even if its bytes are CSV-like; and path, traversal, subdirectory, URL/URI, and external-file references are refused.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-015,Read-only Execution Output acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The execution surface must display the selected saved Work Order, source resolution, relevant stage/refusal facts, and resulting artifact identity while accepting no command input. Keyboard focus in the execution surface must not create a second execution path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-016,Store-MAP snapshot persistence and read-only directory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Creating or changing governed alias/Store metadata through a saved Work Order must create one new immutable complete Store MAP in the same flat Suitcase while preserving earlier MAPs and leaving target artifact bytes and physical filenames unchanged. After a governed run that creates a new Store MAP, refreshing/reopening the Suitcase may display Store, RID, and COL aliases from the exact Store lineage and Store MAP resolved for that specific governed operation. The directory must not infer a global “current Store,” guess from unrelated newest MAP timestamps, or independently choose or mutate Store/MAP authority for execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-017,"Store-aware MAP selection, historical override, and anti-rebinding acceptance",W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"A saved materializing Work Order that does not explicitly name a MAP must use exact SOURCE matching against the one common source_filename carried by each routable Store lineage's Store MAP. A routable Store lineage is one with at least one structurally valid Store MAP, regardless of later Store-health state. A fixture with exactly one routable Store lineage must route to that lineage and, when its health permits materialization, inherit the Store's unique newest permitted MAP and record both the MAP identity and bound rid_filename in execution evidence. A fixture with no routable Store lineage and no structurally malformed Store-MAP-class artifact present may establish a new Store. A fixture with more than one routable Store lineage for the same source must refuse automatic selection. An explicit-MAP fixture must prove that SOURCE must exactly equal the selected MAP's common source_filename . A different source must refuse before materialization even when source/RID row counts happen to match. A separate all-MAPs-damaged fixture must leave one or more structurally malformed Store-MAP-class artifacts visible while no routable lineage can be established. The UI/run path must refuse before new-Store/RID creation and expose Help that identifies the malformed MAP artifact or artifacts; it must not present the condition as an unseen source. Another fixture must prove that explicitly naming an older valid MAP overrides the newer default for that same Store. More than one explicitly named MAP must refuse. An equal-greatest-timestamp ambiguity within the selected Store lineage must refuse automatic selection. Once an inherited Store MAP has been selected for a run, creation of a newer MAP during execution must not silently rebind that in-progress run. P2-03 authority/clock acceptance: the UI/evidence path must distinguish the selected operation base MAP from the chronology predecessor used for successor UTC validation. When a future-dated current MAP blocks publication, the UI must not label that MAP corrupt merely because of its timestamp, must identify it as the blocking current authority, and must route to Help describing the clock correction/wait/deliberate-removal choices without performing any automatic fallback or filesystem move.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-018,Help-Engine-only messaging acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"For representative Suitcase validation, Work Order validation, source-resolution, and analytical refusal cases, user-facing guidance must be traceable to the Help Engine/canonical diagnostic path. Acceptance must show no competing ad hoc semantic refusal text generated independently by individual analytical controls.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-019,No standalone Work Order Description acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Acceptance must prove the architecture that WASM-002 permits: the browser exposes no standalone editable Work Order Description field; no separate mutable or hidden Work Order-description store exists; editing any governed WKO byte transitions a loaded saved WKO into a derived draft; the predecessor WKO TXT bytes, physical filename, and UUID remain unchanged; and the derived draft cannot Run until saved as a new WKO identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-020,Theme semantic-invariance acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The same saved Work Order and governed diagnostic fixture must be exercised under Modern Dark and Modern Light. Acceptance evidence must show identical Work Order resolution, diagnostic ID and structured facts, continue/refuse decision, and analytical result/provenance across both themes, with only governed live-browser presentation differences. The browser must expose no Custom or Terminal governed theme choice in WASM-002. Acceptance must also verify that switching between Modern Dark and Modern Light does not change the canonical built-in presentation of a generated HLP or CER.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-021,Flight Recorder read-only derivation acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Acceptance must populate the Suitcase with governed RCP artifacts for at least one successful Run and one refused Run whose Receipt publication succeeded, then reconstruct the Flight Recorder surface solely from those Receipts. The rendered history must preserve each Receipt's governed execution outcome and lineage while allowing only read-only presentation operations. A separate fixture must represent a Run for which Receipt publication failed under W002-RCP-010 and prove that the Flight Recorder does not invent, backfill, or reconstruct a canonical Receipt from transient execution state. User interaction with the Flight Recorder must not modify, delete, rename, rewrite, supersede, or create RCP artifacts and must not create hidden persistent history state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-001,Certification interprets nothing analytically,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The certification stage establishes source-encoding validity and evidence; it does not perform analytical materialization.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-002,Materialization assumes nothing about encoding,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,Materialization proceeds only under the governed UTF-8-certified-source invariant and does not guess or silently change source encoding.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-003,Conversion is a separate transformation,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"Windows-1252-to-UTF-8 conversion is an explicit user-authorized operation producing a new artifact, not a hidden fallback.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-004,The fast path preserves strictness,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"ASCII-first acceleration is an optimization of strict UTF-8 certification, not a relaxation of validity rules. Every non-ASCII sequence remains subject to strict validation and EOF remains authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-005,Help is first-class,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The shared engine emits governed diagnostic truth; the Help Engine owns governed explanation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-006,PRETTY is first-class,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The PRETTY Engine owns deterministic human-facing rendering.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-008,One shared semantic core,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The WASM-first implementation must remain suitable for later use by a standalone native CLI host without creating a permanent second semantic engine.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-011,Open source and commercial service are separate layers,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The open-source analytical product and Red5Sorcery's optional paid automation must remain architecturally distinguishable. A paid service may save work; it must not become a hidden prerequisite for executing or understanding the delivered analytical software.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-014,WASM-002 and V1 analytical execution are sequential,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"WASM-002 must execute governed analytical operations sequentially and predictably. The product must not expose worker-count, thread-count, task-parallelism, or similar tuning controls, and it must not silently introduce a parallel analytical execution mode whose ordering or resource use changes the governed semantics. Sequential execution does not require inefficient repeated scans. One bounded structural source pass may process multiple requested columns together, and implementation may use ordinary low-level/runtime mechanisms that do not create user-visible analytical concurrency or change deterministic operation order. Any future analytical parallelism requires a separate measured experiment and explicit PRD decision.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-014.1,WASM-002 has a single-writer Suitcase contract,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"WASM-002 assumes one user, one active Suitcase, and one Data Sculptor writing execution context at a time . Multiple read-only views may observe the same Suitcase, but concurrent governed writers—including a second browser tab or window attempting governed writes against the same Suitcase—are outside the supported WASM-002 contract. WASM-002 does not implement cross-tab locks, filesystem leases, lockfiles, hidden coordination state, or multi-writer merge/rebase semantics. This is an explicit product boundary, not an implicit guarantee that concurrent writers are safe. Before a governed transaction reaches its authoritative commit point, Data Sculptor must re-resolve and revalidate the governing state on which the transaction depends. If relevant governed state has changed since the transaction established its basis, publication must refuse rather than overwrite the newer authority, silently rebase itself, synthesize another chronology, or report success. Candidates already created remain subject to the existing rollback and attributable SCR recovery-evidence rules. Help must explain the boundary in ordinary terms: do not run two writing Data Sculptor contexts against the same Suitcase at the same time. If a pre-commit guard detects changed authority, the safe next action is to refresh or reopen the current governed state and rerun deliberately. Acceptance evidence must inject a relevant Store-MAP and WKO-MAP authority change after transaction preparation but before commit and prove that the newer authority remains authoritative and the stale transaction refuses.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)

Algorithm : SHA256
Hash      : 66F57F7D9EA7A98CEEBB95A28ACAC017D3CF35599A28FC8FC70DC028F016D114
Path      : C:\Users\Admin\Downloads\DataSculptor-WASM002\Evidence\CP-001\CP001_Hash_Inventory.txt

DATA SCULPTOR WASM-002 CP002 HASH INVENTORY
Git HEAD: 03201870b8ec68730a0c027c572db03ccd5eeaa8
File count: 21

PATH | BYTES | SHA256
Cargo.toml | 89 | 6FAD50B667CBD473B2E6A8E7FE4E33BD788B4CF617505B9A08B88E9B684EFF25
Cargo.lock | 162 | BDB2BCD1BA65C0FFDABC7960B279978411113895E0CDAD12F4E2604E916BD9D8
rust-toolchain.toml | 92 | D02F2301203B36F8C98CF05DD8716E38064154631D7CC0D6D1A0313CC4098AF0
src\lib.rs | 1183 | 678ECEFE992D13080656FD2E1BE9F41ADF1FFC19E677B4D301D20A5D0C018D40
tests\artifact_namespace.rs | 2656 | C908B49BB1B4C475A04901C3A70FCF45585079616DE869082D6EC0B357FD1249
Evidence\CP-002\CP002_Baseline_Cargo_Test_Output.txt | 2228 | 1450087E16ADDBFA60EEF983A8E6341C3577809419CA60EFC6DD77976D20FD37
Evidence\CP-002\CP002_Day065_Repository_Inventory.txt | 3152 | A121070DFFCB5552E8D89452113F70CB1C7273AC1A8419F09F071B65C641C477
Evidence\CP-002\CP002_Day065_Source_And_Tests_Baseline.txt | 6050 | 233BA51535008D7CFBEBF3A37CD07B53E70CD5F98558626FF04F31F954C0C790
Evidence\CP-002\CP002_Day065_Starting_State.txt | 1560 | 214D77AC8737AD0984514E05FD16F923AFBF9DDBB3F2A8787CA6B2BBC7AFAC54
Evidence\CP-002\CP002_Evidence_Organization.txt | 391 | 2FC5F9B3A269FB83315DBD37081A74A46F46B9F136B58FB087196C834088B6BB
Evidence\CP-002\CP002_Format_Output.txt | 215 | 95655268A5AC3ED47690459B4940F951E3A9135A8A9F01939F8AA03578DCC11F
Evidence\CP-002\CP002_Format_Retry_Output.txt | 27 | A4ECCDEDFA9150EAEAAF83E6112528F14FDCB8A9F2776F47AC3842A62314ACB4
Evidence\CP-002\CP002_GREEN_Source_Change.txt | 528 | 6F76C3B5A9973F8EBE340C1464B3B885405F9A4B8B030E03CBAC22B1435BE313
Evidence\CP-002\CP002_GREEN_Test_Output.txt | 937 | 7C3EBD67C48B18ACFFFE1A35409864511149B9C1F3301738E8AEC732D4454F90
Evidence\CP-002\CP002_Post_Format_Diff_Review.txt | 6760 | E6C3440373F09E9F17B8F3EB4DED05075F9E8BF27867B40378AA15D027C2CEFF
Evidence\CP-002\CP002_Post_Format_Test_Output.txt | 937 | 0F97BAD6F8AC59CD2DC1F84E0560741CED3FC652962B3504D6DB107F9E46F7D6
Evidence\CP-002\CP002_Post_Format_WASM_Build_Output.txt | 103 | 5F7855D3463D821761CB7AB9BCADAFB8158C38AE6D2BF792B2BF95D79073978A
Evidence\CP-002\CP002_RED_Test_Change.txt | 2010 | 5C0888C3BCC2205856F745A6C9FBB3B19BACDA404AE0B12539614E67B7EDB3AE
Evidence\CP-002\CP002_RED_Test_Output.txt | 626 | 60B6686B1005C10DC6BB908E221137FB4A7454DFEF784862ED019721CA55F0A5
Evidence\CP-002\CP002_Rustfmt_Install_Output.txt | 71 | 5D550C604B5D8F48768C33D8AE5E4F39DCDCE245B317488BD13A65A01D3CA517
Evidence\CP-002\CP002_WASM_Build_Output.txt | 190 | 0CBC42B4349E7F99F8D779ABE67D0C9C136AFAC29EC8460B1430BAA01BB3670F

CP002 INDEPENDENT SHA256 VERIFICATION
PASS | Cargo.toml
PASS | Cargo.lock
PASS | rust-toolchain.toml
PASS | src\lib.rs
PASS | tests\artifact_namespace.rs
PASS | Evidence\CP-002\CP002_Baseline_Cargo_Test_Output.txt
PASS | Evidence\CP-002\CP002_Day065_Repository_Inventory.txt
PASS | Evidence\CP-002\CP002_Day065_Source_And_Tests_Baseline.txt
PASS | Evidence\CP-002\CP002_Day065_Starting_State.txt
PASS | Evidence\CP-002\CP002_Evidence_Organization.txt
PASS | Evidence\CP-002\CP002_Format_Output.txt
PASS | Evidence\CP-002\CP002_Format_Retry_Output.txt
PASS | Evidence\CP-002\CP002_GREEN_Source_Change.txt
PASS | Evidence\CP-002\CP002_GREEN_Test_Output.txt
PASS | Evidence\CP-002\CP002_Post_Format_Diff_Review.txt
PASS | Evidence\CP-002\CP002_Post_Format_Test_Output.txt
PASS | Evidence\CP-002\CP002_Post_Format_WASM_Build_Output.txt
PASS | Evidence\CP-002\CP002_RED_Test_Change.txt
PASS | Evidence\CP-002\CP002_RED_Test_Output.txt
PASS | Evidence\CP-002\CP002_Rustfmt_Install_Output.txt
PASS | Evidence\CP-002\CP002_WASM_Build_Output.txt

Verified files: 21 / 21
Inventory SHA256: 1BA180B4F0A2416177CEAAA2BB73CAE2C8E93E1AFD14710D9D8A50B30E98AEE8
Issues: 0

CP002 HASH VERIFICATION COMPLETION
Original verification report preserved unchanged.
Verified files: 21 / 21
Issues: 0
Console exception: orphaned PowerShell else statement.
No hash or file-size mismatches reported.
RESULT: PASS

CP003 INDEPENDENT SHA256 VERIFICATION
PASS | Cargo.toml
PASS | Cargo.lock
PASS | rust-toolchain.toml
PASS | src\lib.rs
PASS | tests\artifact_namespace.rs
PASS | tests\artifact_class_disposition.rs
PASS | Evidence\CP-003\CP003_Format_Output.txt
PASS | Evidence\CP-003\CP003_GREEN_Source_Change.txt
PASS | Evidence\CP-003\CP003_GREEN_Test_Output.txt
PASS | Evidence\CP-003\CP003_Post_Format_Diff_Review.txt
PASS | Evidence\CP-003\CP003_Post_Format_Test_Output.txt
PASS | Evidence\CP-003\CP003_RED_Test_Change.txt
PASS | Evidence\CP-003\CP003_RED_Test_Output.txt
PASS | Evidence\CP-003\CP003_Starting_State.txt
PASS | Evidence\CP-003\CP003_WASM_Build_Output.txt

Verified files: 15 / 15
Issues: 0
Inventory SHA256: 760A13CB2118DEF15E323B8579A4AEBE1C8E16E651B428997989757C380F7338
RESULT: PASS

WASM-002 GIT COMMITTED-VOLUME INVENTORY
Created: 2026-10-13 22:56:05 -03:00
Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Period start: 2026-10-09T00:00:00-03:00
History: first-parent commits on current branch
COMMITS=15
CHANGED_FILE_RECORDS=267
GROSS_COMMITTED_BYTES=773769
GROSS_COMMITTED_KIB=755.634
NET_GROWTH_BYTES=693714
NET_GROWTH_KIB=677.455
EVIDENCE_GROSS_BYTES=640770
EVIDENCE_GROSS_KIB=625.752
PROJECT_DAY_ASSIGNMENT=PENDING

DEFINITION: Gross = complete new blob size for added or
content-modified files; unchanged blobs count as zero.
DEFINITION: Net = new file size minus prior file size.
DEFINITION: Sizes are uncompressed bytes, not Git pack size.
DEFINITION: A rename with unchanged content adds zero gross.

=== COMMITS ===
2026-10-10T14:49:59-03:00 | 6b373ff782b97b751d63d44449320f72d05ba339 | 0.547 KiB | WASM-002: establish verified Rust 1.97.1 baseline
2026-10-10T14:53:13-03:00 | 01580a1873cc51a675a2c2b560d2500cf5cf909f | 0.105 KiB | WASM-002: establish cross-platform line-ending policy
2026-10-10T15:27:19-03:00 | 03201870b8ec68730a0c027c572db03ccd5eeaa8 | 18.682 KiB | WASM-002 CP-001: locally verified namespace recognizer candidate
2026-10-12T18:55:44-03:00 | 206dcd8b76af29edcb658a0c5a2dc40d87089fe3 | 36.931 KiB | WASM-002 CP-002: reserve Data Sculptor filename namespace
2026-10-12T19:56:23-03:00 | 2d06f6259de93f5beaa8eb15f8f22f171127a10e | 19.337 KiB | WASM-002 CP-003: classify governed artifact tokens
2026-10-12T20:22:47-03:00 | 12c02a0f2ff51fae72599adc09332f50fed62ce8 | 27.657 KiB | WASM-002 CP-004: validate immutable filename envelope
2026-10-12T20:53:56-03:00 | cedd5d54506b8f3f879b96c5e64fefc9365b6eb0 | 29.752 KiB | WASM-002 CP-005: validate Gregorian UTC timestamps
2026-10-12T21:20:03-03:00 | aff54d08dcbacaa0c54d8869749344a504c5ad61 | 31.181 KiB | WASM-002 CP-006: separate artifact class and serialization
2026-10-12T21:52:18-03:00 | 3c512df519f3a2431b363e4c57dc234c02378124 | 32.778 KiB | WASM-002 CP-007: construct canonical filenames without normalization
2026-10-13T15:35:46-03:00 | 346733a962192320e0d56271add15a47b6037b6b | 33.108 KiB | WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates
2026-10-13T16:05:03-03:00 | dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8 | 34.449 KiB | WASM-002 CP-009: match exact CSV SOURCE names in root snapshots
2026-10-13T17:20:42-03:00 | b7c515faa9bd000369d7656e09437310261290ae | 73.828 KiB | WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates
2026-10-13T18:41:56-03:00 | e84ae5baeee05f9d5d30284c65b86eebba3c0f6a | 57.753 KiB | CP011: canonical CVT-to-SCR candidate identity
2026-10-13T20:18:43-03:00 | efca04392940e398020a5c06b9ee50296c8a1fdd | 64.554 KiB | CP012: canonical SCR filename candidate recognition
2026-10-13T22:01:42-03:00 | 005a38ef5e876847c4c08901c18da9c18565fd6b | 294.972 KiB | CP013: explicit SCR-to-RCP filename candidate derivation

FILES_CSV_SHA256=C82884BFAF38906976048FF8264B1367199BF9CE0A1CB02E510F1FEDA067094F
COMMITS_CSV_SHA256=68CE57F9BD062C05238B034EE3313C31A2B486794430F9B7BA4F3FB30A9BA5BD
GIT_CHANGES_PERFORMED=False
DAY_066=OPEN
RESULT: PASS - READ-ONLY VOLUME INVENTORY

"CommitSHA","ParentSHA","CommitTime","Subject","ChangedFiles","GrossBytes","GrossKiB","NetBytes","EvidenceBytes","SourceBytes","TestBytes","OtherBytes"
"6b373ff782b97b751d63d44449320f72d05ba339","","2026-10-10T14:49:59-03:00","WASM-002: establish verified Rust 1.97.1 baseline","5","560","0.547","560","0","210","0","350"
"01580a1873cc51a675a2c2b560d2500cf5cf909f","6b373ff782b97b751d63d44449320f72d05ba339","2026-10-10T14:53:13-03:00","WASM-002: establish cross-platform line-ending policy","1","108","0.105","108","0","0","0","108"
"03201870b8ec68730a0c027c572db03ccd5eeaa8","01580a1873cc51a675a2c2b560d2500cf5cf909f","2026-10-10T15:27:19-03:00","WASM-002 CP-001: locally verified namespace recognizer candidate","10","19130","18.682","18920","6070","937","2006","10117"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","03201870b8ec68730a0c027c572db03ccd5eeaa8","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","22","37817","36.931","34874","33986","1175","2656","0"
"2d06f6259de93f5beaa8eb15f8f22f171127a10e","206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T19:56:23-03:00","WASM-002 CP-003: classify governed artifact tokens","14","19801","19.337","18626","15481","2486","1834","0"
"12c02a0f2ff51fae72599adc09332f50fed62ce8","2d06f6259de93f5beaa8eb15f8f22f171127a10e","2026-10-12T20:22:47-03:00","WASM-002 CP-004: validate immutable filename envelope","15","28321","27.657","25835","22349","4071","1901","0"
"cedd5d54506b8f3f879b96c5e64fefc9365b6eb0","12c02a0f2ff51fae72599adc09332f50fed62ce8","2026-10-12T20:53:56-03:00","WASM-002 CP-005: validate Gregorian UTC timestamps","14","30466","29.752","26395","23272","5176","2018","0"
"aff54d08dcbacaa0c54d8869749344a504c5ad61","cedd5d54506b8f3f879b96c5e64fefc9365b6eb0","2026-10-12T21:20:03-03:00","WASM-002 CP-006: separate artifact class and serialization","14","31929","31.181","26753","22784","6143","3002","0"
"3c512df519f3a2431b363e4c57dc234c02378124","aff54d08dcbacaa0c54d8869749344a504c5ad61","2026-10-12T21:52:18-03:00","WASM-002 CP-007: construct canonical filenames without normalization","14","33565","32.778","27422","23864","6829","2872","0"
"346733a962192320e0d56271add15a47b6037b6b","3c512df519f3a2431b363e4c57dc234c02378124","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","18","33903","33.108","27074","23931","7783","2189","0"
"dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","346733a962192320e0d56271add15a47b6037b6b","2026-10-13T16:05:03-03:00","WASM-002 CP-009: match exact CSV SOURCE names in root snapshots","15","35276","34.449","27493","20794","10093","4389","0"
"b7c515faa9bd000369d7656e09437310261290ae","dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","28","75600","73.828","65507","62839","10589","2172","0"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","27","59139","57.753","48550","45802","11016","2321","0"
"efca04392940e398020a5c06b9ee50296c8a1fdd","e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","28","66103","64.554","55087","52586","11541","1976","0"
"005a38ef5e876847c4c08901c18da9c18565fd6b","efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","42","302051","294.972","290510","287012","12312","2727","0"

"CommitSHA","CommitTime","Subject","Status","Category","OldPath","Path","BeforeBytes","AfterBytes","GrossBytes","NetBytes"
"6b373ff782b97b751d63d44449320f72d05ba339","2026-10-10T14:49:59-03:00","WASM-002: establish verified Rust 1.97.1 baseline","A","Other",".gitignore",".gitignore","0","8","8","8"
"6b373ff782b97b751d63d44449320f72d05ba339","2026-10-10T14:49:59-03:00","WASM-002: establish verified Rust 1.97.1 baseline","A","Other","Cargo.lock","Cargo.lock","0","162","162","162"
"6b373ff782b97b751d63d44449320f72d05ba339","2026-10-10T14:49:59-03:00","WASM-002: establish verified Rust 1.97.1 baseline","A","Other","Cargo.toml","Cargo.toml","0","89","89","89"
"6b373ff782b97b751d63d44449320f72d05ba339","2026-10-10T14:49:59-03:00","WASM-002: establish verified Rust 1.97.1 baseline","A","Other","rust-toolchain.toml","rust-toolchain.toml","0","91","91","91"
"6b373ff782b97b751d63d44449320f72d05ba339","2026-10-10T14:49:59-03:00","WASM-002: establish verified Rust 1.97.1 baseline","A","Source","src/lib.rs","src/lib.rs","0","210","210","210"
"01580a1873cc51a675a2c2b560d2500cf5cf909f","2026-10-10T14:53:13-03:00","WASM-002: establish cross-platform line-ending policy","A","Other",".gitattributes",".gitattributes","0","108","108","108"
"03201870b8ec68730a0c027c572db03ccd5eeaa8","2026-10-10T15:27:19-03:00","WASM-002 CP-001: locally verified namespace recognizer candidate","A","Other","DataSculptor_WASM002_Development_Log.html","DataSculptor_WASM002_Development_Log.html","0","10117","10117","10117"
"03201870b8ec68730a0c027c572db03ccd5eeaa8","2026-10-10T15:27:19-03:00","WASM-002 CP-001: locally verified namespace recognizer candidate","A","Evidence","Evidence/CP-001/CP001_GREEN2_Test_Output.txt","Evidence/CP-001/CP001_GREEN2_Test_Output.txt","0","1188","1188","1188"
"03201870b8ec68730a0c027c572db03ccd5eeaa8","2026-10-10T15:27:19-03:00","WASM-002 CP-001: locally verified namespace recognizer candidate","A","Evidence","Evidence/CP-001/CP001_GREEN_Test_Output.txt","Evidence/CP-001/CP001_GREEN_Test_Output.txt","0","965","965","965"
"03201870b8ec68730a0c027c572db03ccd5eeaa8","2026-10-10T15:27:19-03:00","WASM-002 CP-001: locally verified namespace recognizer candidate","A","Evidence","Evidence/CP-001/CP001_Hash_Inventory.txt","Evidence/CP-001/CP001_Hash_Inventory.txt","0","984","984","984"
"03201870b8ec68730a0c027c572db03ccd5eeaa8","2026-10-10T15:27:19-03:00","WASM-002 CP-001: locally verified namespace recognizer candidate","A","Evidence","Evidence/CP-001/CP001_Hash_Inventory_Verification.txt","Evidence/CP-001/CP001_Hash_Inventory_Verification.txt","0","422","422","422"
"03201870b8ec68730a0c027c572db03ccd5eeaa8","2026-10-10T15:27:19-03:00","WASM-002 CP-001: locally verified namespace recognizer candidate","A","Evidence","Evidence/CP-001/CP001_RED2_Test_Output.txt","Evidence/CP-001/CP001_RED2_Test_Output.txt","0","1530","1530","1530"
"03201870b8ec68730a0c027c572db03ccd5eeaa8","2026-10-10T15:27:19-03:00","WASM-002 CP-001: locally verified namespace recognizer candidate","A","Evidence","Evidence/CP-001/CP001_RED_Test_Output.txt","Evidence/CP-001/CP001_RED_Test_Output.txt","0","592","592","592"
"03201870b8ec68730a0c027c572db03ccd5eeaa8","2026-10-10T15:27:19-03:00","WASM-002 CP-001: locally verified namespace recognizer candidate","A","Evidence","Evidence/CP-001/CP001_WASM_Build_Output.txt","Evidence/CP-001/CP001_WASM_Build_Output.txt","0","389","389","389"
"03201870b8ec68730a0c027c572db03ccd5eeaa8","2026-10-10T15:27:19-03:00","WASM-002 CP-001: locally verified namespace recognizer candidate","M","Source","src/lib.rs","src/lib.rs","210","937","937","727"
"03201870b8ec68730a0c027c572db03ccd5eeaa8","2026-10-10T15:27:19-03:00","WASM-002 CP-001: locally verified namespace recognizer candidate","A","Tests","tests/artifact_namespace.rs","tests/artifact_namespace.rs","0","2006","2006","2006"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_Baseline_Cargo_Test_Output.txt","Evidence/CP-002/CP002_Baseline_Cargo_Test_Output.txt","0","2228","2228","2228"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_Day065_Repository_Inventory.txt","Evidence/CP-002/CP002_Day065_Repository_Inventory.txt","0","3152","3152","3152"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_Day065_Source_And_Tests_Baseline.txt","Evidence/CP-002/CP002_Day065_Source_And_Tests_Baseline.txt","0","6050","6050","6050"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_Day065_Starting_State.txt","Evidence/CP-002/CP002_Day065_Starting_State.txt","0","1560","1560","1560"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_Evidence_Organization.txt","Evidence/CP-002/CP002_Evidence_Organization.txt","0","387","387","387"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_Format_Output.txt","Evidence/CP-002/CP002_Format_Output.txt","0","214","214","214"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_Format_Retry_Output.txt","Evidence/CP-002/CP002_Format_Retry_Output.txt","0","26","26","26"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_GREEN_Source_Change.txt","Evidence/CP-002/CP002_GREEN_Source_Change.txt","0","513","513","513"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_GREEN_Test_Output.txt","Evidence/CP-002/CP002_GREEN_Test_Output.txt","0","936","936","936"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_Hash_Inventory.txt","Evidence/CP-002/CP002_Hash_Inventory.txt","0","2522","2522","2522"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_Hash_Inventory_Verification.txt","Evidence/CP-002/CP002_Hash_Inventory_Verification.txt","0","1158","1158","1158"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_Post_Format_Diff_Review.txt","Evidence/CP-002/CP002_Post_Format_Diff_Review.txt","0","6760","6760","6760"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_Post_Format_Test_Output.txt","Evidence/CP-002/CP002_Post_Format_Test_Output.txt","0","936","936","936"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_Post_Format_WASM_Build_Output.txt","Evidence/CP-002/CP002_Post_Format_WASM_Build_Output.txt","0","102","102","102"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_Precommit_Git_Review.txt","Evidence/CP-002/CP002_Precommit_Git_Review.txt","0","4315","4315","4315"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_RED_Test_Change.txt","Evidence/CP-002/CP002_RED_Test_Change.txt","0","2010","2010","2010"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_RED_Test_Output.txt","Evidence/CP-002/CP002_RED_Test_Output.txt","0","626","626","626"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_Rustfmt_Install_Output.txt","Evidence/CP-002/CP002_Rustfmt_Install_Output.txt","0","70","70","70"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_Verification_Completion.txt","Evidence/CP-002/CP002_Verification_Completion.txt","0","232","232","232"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","A","Evidence","Evidence/CP-002/CP002_WASM_Build_Output.txt","Evidence/CP-002/CP002_WASM_Build_Output.txt","0","189","189","189"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","M","Source","src/lib.rs","src/lib.rs","937","1175","1175","238"
"206dcd8b76af29edcb658a0c5a2dc40d87089fe3","2026-10-12T18:55:44-03:00","WASM-002 CP-002: reserve Data Sculptor filename namespace","M","Tests","tests/artifact_namespace.rs","tests/artifact_namespace.rs","2006","2656","2656","650"
"2d06f6259de93f5beaa8eb15f8f22f171127a10e","2026-10-12T19:56:23-03:00","WASM-002 CP-003: classify governed artifact tokens","A","Evidence","Evidence/CP-003/CP003_Format_Output.txt","Evidence/CP-003/CP003_Format_Output.txt","0","26","26","26"
"2d06f6259de93f5beaa8eb15f8f22f171127a10e","2026-10-12T19:56:23-03:00","WASM-002 CP-003: classify governed artifact tokens","A","Evidence","Evidence/CP-003/CP003_GREEN_Source_Change.txt","Evidence/CP-003/CP003_GREEN_Source_Change.txt","0","1626","1626","1626"
"2d06f6259de93f5beaa8eb15f8f22f171127a10e","2026-10-12T19:56:23-03:00","WASM-002 CP-003: classify governed artifact tokens","A","Evidence","Evidence/CP-003/CP003_GREEN_Test_Output.txt","Evidence/CP-003/CP003_GREEN_Test_Output.txt","0","1368","1368","1368"
"2d06f6259de93f5beaa8eb15f8f22f171127a10e","2026-10-12T19:56:23-03:00","WASM-002 CP-003: classify governed artifact tokens","A","Evidence","Evidence/CP-003/CP003_Hash_Inventory.txt","Evidence/CP-003/CP003_Hash_Inventory.txt","0","1749","1749","1749"
"2d06f6259de93f5beaa8eb15f8f22f171127a10e","2026-10-12T19:56:23-03:00","WASM-002 CP-003: classify governed artifact tokens","A","Evidence","Evidence/CP-003/CP003_Hash_Inventory_Verification.txt","Evidence/CP-003/CP003_Hash_Inventory_Verification.txt","0","790","790","790"
"2d06f6259de93f5beaa8eb15f8f22f171127a10e","2026-10-12T19:56:23-03:00","WASM-002 CP-003: classify governed artifact tokens","A","Evidence","Evidence/CP-003/CP003_Post_Format_Diff_Review.txt","Evidence/CP-003/CP003_Post_Format_Diff_Review.txt","0","4144","4144","4144"
"2d06f6259de93f5beaa8eb15f8f22f171127a10e","2026-10-12T19:56:23-03:00","WASM-002 CP-003: classify governed artifact tokens","A","Evidence","Evidence/CP-003/CP003_Post_Format_Test_Output.txt","Evidence/CP-003/CP003_Post_Format_Test_Output.txt","0","1362","1362","1362"
"2d06f6259de93f5beaa8eb15f8f22f171127a10e","2026-10-12T19:56:23-03:00","WASM-002 CP-003: classify governed artifact tokens","A","Evidence","Evidence/CP-003/CP003_Precommit_Git_Review.txt","Evidence/CP-003/CP003_Precommit_Git_Review.txt","0","1272","1272","1272"
"2d06f6259de93f5beaa8eb15f8f22f171127a10e","2026-10-12T19:56:23-03:00","WASM-002 CP-003: classify governed artifact tokens","A","Evidence","Evidence/CP-003/CP003_RED_Test_Change.txt","Evidence/CP-003/CP003_RED_Test_Change.txt","0","2044","2044","2044"
"2d06f6259de93f5beaa8eb15f8f22f171127a10e","2026-10-12T19:56:23-03:00","WASM-002 CP-003: classify governed artifact tokens","A","Evidence","Evidence/CP-003/CP003_RED_Test_Output.txt","Evidence/CP-003/CP003_RED_Test_Output.txt","0","710","710","710"
"2d06f6259de93f5beaa8eb15f8f22f171127a10e","2026-10-12T19:56:23-03:00","WASM-002 CP-003: classify governed artifact tokens","A","Evidence","Evidence/CP-003/CP003_Starting_State.txt","Evidence/CP-003/CP003_Starting_State.txt","0","201","201","201"
"2d06f6259de93f5beaa8eb15f8f22f171127a10e","2026-10-12T19:56:23-03:00","WASM-002 CP-003: classify governed artifact tokens","A","Evidence","Evidence/CP-003/CP003_WASM_Build_Output.txt","Evidence/CP-003/CP003_WASM_Build_Output.txt","0","189","189","189"
"2d06f6259de93f5beaa8eb15f8f22f171127a10e","2026-10-12T19:56:23-03:00","WASM-002 CP-003: classify governed artifact tokens","M","Source","src/lib.rs","src/lib.rs","1175","2486","2486","1311"
"2d06f6259de93f5beaa8eb15f8f22f171127a10e","2026-10-12T19:56:23-03:00","WASM-002 CP-003: classify governed artifact tokens","A","Tests","tests/artifact_class_disposition.rs","tests/artifact_class_disposition.rs","0","1834","1834","1834"
"12c02a0f2ff51fae72599adc09332f50fed62ce8","2026-10-12T20:22:47-03:00","WASM-002 CP-004: validate immutable filename envelope","A","Evidence","Evidence/CP-004/CP004_Format_Output.txt","Evidence/CP-004/CP004_Format_Output.txt","0","363","363","363"
"12c02a0f2ff51fae72599adc09332f50fed62ce8","2026-10-12T20:22:47-03:00","WASM-002 CP-004: validate immutable filename envelope","A","Evidence","Evidence/CP-004/CP004_GREEN_Source_Change.txt","Evidence/CP-004/CP004_GREEN_Source_Change.txt","0","1920","1920","1920"
"12c02a0f2ff51fae72599adc09332f50fed62ce8","2026-10-12T20:22:47-03:00","WASM-002 CP-004: validate immutable filename envelope","A","Evidence","Evidence/CP-004/CP004_GREEN_Test_Output.txt","Evidence/CP-004/CP004_GREEN_Test_Output.txt","0","1960","1960","1960"
"12c02a0f2ff51fae72599adc09332f50fed62ce8","2026-10-12T20:22:47-03:00","WASM-002 CP-004: validate immutable filename envelope","A","Evidence","Evidence/CP-004/CP004_Hash_Inventory.txt","Evidence/CP-004/CP004_Hash_Inventory.txt","0","2284","2284","2284"
"12c02a0f2ff51fae72599adc09332f50fed62ce8","2026-10-12T20:22:47-03:00","WASM-002 CP-004: validate immutable filename envelope","A","Evidence","Evidence/CP-004/CP004_Hash_Inventory_Verification.txt","Evidence/CP-004/CP004_Hash_Inventory_Verification.txt","0","2400","2400","2400"
"12c02a0f2ff51fae72599adc09332f50fed62ce8","2026-10-12T20:22:47-03:00","WASM-002 CP-004: validate immutable filename envelope","A","Evidence","Evidence/CP-004/CP004_Post_Format_Diff_Review.txt","Evidence/CP-004/CP004_Post_Format_Diff_Review.txt","0","4559","4559","4559"
"12c02a0f2ff51fae72599adc09332f50fed62ce8","2026-10-12T20:22:47-03:00","WASM-002 CP-004: validate immutable filename envelope","A","Evidence","Evidence/CP-004/CP004_Post_Format_Test_Output.txt","Evidence/CP-004/CP004_Post_Format_Test_Output.txt","0","1966","1966","1966"
"12c02a0f2ff51fae72599adc09332f50fed62ce8","2026-10-12T20:22:47-03:00","WASM-002 CP-004: validate immutable filename envelope","A","Evidence","Evidence/CP-004/CP004_Precommit_Git_Review.txt","Evidence/CP-004/CP004_Precommit_Git_Review.txt","0","2933","2933","2933"
"12c02a0f2ff51fae72599adc09332f50fed62ce8","2026-10-12T20:22:47-03:00","WASM-002 CP-004: validate immutable filename envelope","A","Evidence","Evidence/CP-004/CP004_RED_Test_Change.txt","Evidence/CP-004/CP004_RED_Test_Change.txt","0","2206","2206","2206"
"12c02a0f2ff51fae72599adc09332f50fed62ce8","2026-10-12T20:22:47-03:00","WASM-002 CP-004: validate immutable filename envelope","A","Evidence","Evidence/CP-004/CP004_RED_Test_Correction.txt","Evidence/CP-004/CP004_RED_Test_Correction.txt","0","394","394","394"
"12c02a0f2ff51fae72599adc09332f50fed62ce8","2026-10-12T20:22:47-03:00","WASM-002 CP-004: validate immutable filename envelope","A","Evidence","Evidence/CP-004/CP004_RED_Test_Output.txt","Evidence/CP-004/CP004_RED_Test_Output.txt","0","633","633","633"
"12c02a0f2ff51fae72599adc09332f50fed62ce8","2026-10-12T20:22:47-03:00","WASM-002 CP-004: validate immutable filename envelope","A","Evidence","Evidence/CP-004/CP004_Starting_State.txt","Evidence/CP-004/CP004_Starting_State.txt","0","372","372","372"
"12c02a0f2ff51fae72599adc09332f50fed62ce8","2026-10-12T20:22:47-03:00","WASM-002 CP-004: validate immutable filename envelope","A","Evidence","Evidence/CP-004/CP004_WASM_Build_Output.txt","Evidence/CP-004/CP004_WASM_Build_Output.txt","0","359","359","359"
"12c02a0f2ff51fae72599adc09332f50fed62ce8","2026-10-12T20:22:47-03:00","WASM-002 CP-004: validate immutable filename envelope","M","Source","src/lib.rs","src/lib.rs","2486","4071","4071","1585"
"12c02a0f2ff51fae72599adc09332f50fed62ce8","2026-10-12T20:22:47-03:00","WASM-002 CP-004: validate immutable filename envelope","A","Tests","tests/artifact_filename_envelope.rs","tests/artifact_filename_envelope.rs","0","1901","1901","1901"
"cedd5d54506b8f3f879b96c5e64fefc9365b6eb0","2026-10-12T20:53:56-03:00","WASM-002 CP-005: validate Gregorian UTC timestamps","A","Evidence","Evidence/CP-005/CP005_Format_Output.txt","Evidence/CP-005/CP005_Format_Output.txt","0","369","369","369"
"cedd5d54506b8f3f879b96c5e64fefc9365b6eb0","2026-10-12T20:53:56-03:00","WASM-002 CP-005: validate Gregorian UTC timestamps","A","Evidence","Evidence/CP-005/CP005_GREEN_Source_Change.txt","Evidence/CP-005/CP005_GREEN_Source_Change.txt","0","2136","2136","2136"
"cedd5d54506b8f3f879b96c5e64fefc9365b6eb0","2026-10-12T20:53:56-03:00","WASM-002 CP-005: validate Gregorian UTC timestamps","A","Evidence","Evidence/CP-005/CP005_GREEN_Test_Output.txt","Evidence/CP-005/CP005_GREEN_Test_Output.txt","0","2362","2362","2362"
"cedd5d54506b8f3f879b96c5e64fefc9365b6eb0","2026-10-12T20:53:56-03:00","WASM-002 CP-005: validate Gregorian UTC timestamps","A","Evidence","Evidence/CP-005/CP005_Hash_Inventory.txt","Evidence/CP-005/CP005_Hash_Inventory.txt","0","2269","2269","2269"
"cedd5d54506b8f3f879b96c5e64fefc9365b6eb0","2026-10-12T20:53:56-03:00","WASM-002 CP-005: validate Gregorian UTC timestamps","A","Evidence","Evidence/CP-005/CP005_Hash_Inventory_Verification.txt","Evidence/CP-005/CP005_Hash_Inventory_Verification.txt","0","2388","2388","2388"
"cedd5d54506b8f3f879b96c5e64fefc9365b6eb0","2026-10-12T20:53:56-03:00","WASM-002 CP-005: validate Gregorian UTC timestamps","A","Evidence","Evidence/CP-005/CP005_Post_Format_Diff_Review.txt","Evidence/CP-005/CP005_Post_Format_Diff_Review.txt","0","2342","2342","2342"
"cedd5d54506b8f3f879b96c5e64fefc9365b6eb0","2026-10-12T20:53:56-03:00","WASM-002 CP-005: validate Gregorian UTC timestamps","A","Evidence","Evidence/CP-005/CP005_Post_Format_Test_Output.txt","Evidence/CP-005/CP005_Post_Format_Test_Output.txt","0","2392","2392","2392"
"cedd5d54506b8f3f879b96c5e64fefc9365b6eb0","2026-10-12T20:53:56-03:00","WASM-002 CP-005: validate Gregorian UTC timestamps","A","Evidence","Evidence/CP-005/CP005_Precommit_Git_Review.txt","Evidence/CP-005/CP005_Precommit_Git_Review.txt","0","2778","2778","2778"
"cedd5d54506b8f3f879b96c5e64fefc9365b6eb0","2026-10-12T20:53:56-03:00","WASM-002 CP-005: validate Gregorian UTC timestamps","A","Evidence","Evidence/CP-005/CP005_RED_Test_Change.txt","Evidence/CP-005/CP005_RED_Test_Change.txt","0","2369","2369","2369"
"cedd5d54506b8f3f879b96c5e64fefc9365b6eb0","2026-10-12T20:53:56-03:00","WASM-002 CP-005: validate Gregorian UTC timestamps","A","Evidence","Evidence/CP-005/CP005_RED_Test_Output.txt","Evidence/CP-005/CP005_RED_Test_Output.txt","0","3092","3092","3092"
"cedd5d54506b8f3f879b96c5e64fefc9365b6eb0","2026-10-12T20:53:56-03:00","WASM-002 CP-005: validate Gregorian UTC timestamps","A","Evidence","Evidence/CP-005/CP005_Starting_State.txt","Evidence/CP-005/CP005_Starting_State.txt","0","379","379","379"
"cedd5d54506b8f3f879b96c5e64fefc9365b6eb0","2026-10-12T20:53:56-03:00","WASM-002 CP-005: validate Gregorian UTC timestamps","A","Evidence","Evidence/CP-005/CP005_WASM_Build_Output.txt","Evidence/CP-005/CP005_WASM_Build_Output.txt","0","396","396","396"
"cedd5d54506b8f3f879b96c5e64fefc9365b6eb0","2026-10-12T20:53:56-03:00","WASM-002 CP-005: validate Gregorian UTC timestamps","M","Source","src/lib.rs","src/lib.rs","4071","5176","5176","1105"
"cedd5d54506b8f3f879b96c5e64fefc9365b6eb0","2026-10-12T20:53:56-03:00","WASM-002 CP-005: validate Gregorian UTC timestamps","A","Tests","tests/artifact_utc_timestamp.rs","tests/artifact_utc_timestamp.rs","0","2018","2018","2018"
"aff54d08dcbacaa0c54d8869749344a504c5ad61","2026-10-12T21:20:03-03:00","WASM-002 CP-006: separate artifact class and serialization","A","Evidence","Evidence/CP-006/CP006_Format_Output.txt","Evidence/CP-006/CP006_Format_Output.txt","0","369","369","369"
"aff54d08dcbacaa0c54d8869749344a504c5ad61","2026-10-12T21:20:03-03:00","WASM-002 CP-006: separate artifact class and serialization","A","Evidence","Evidence/CP-006/CP006_GREEN_Source_Change.txt","Evidence/CP-006/CP006_GREEN_Source_Change.txt","0","1792","1792","1792"
"aff54d08dcbacaa0c54d8869749344a504c5ad61","2026-10-12T21:20:03-03:00","WASM-002 CP-006: separate artifact class and serialization","A","Evidence","Evidence/CP-006/CP006_GREEN_Test_Output.txt","Evidence/CP-006/CP006_GREEN_Test_Output.txt","0","2876","2876","2876"
"aff54d08dcbacaa0c54d8869749344a504c5ad61","2026-10-12T21:20:03-03:00","WASM-002 CP-006: separate artifact class and serialization","A","Evidence","Evidence/CP-006/CP006_Hash_Inventory.txt","Evidence/CP-006/CP006_Hash_Inventory.txt","0","2435","2435","2435"
"aff54d08dcbacaa0c54d8869749344a504c5ad61","2026-10-12T21:20:03-03:00","WASM-002 CP-006: separate artifact class and serialization","A","Evidence","Evidence/CP-006/CP006_Hash_Inventory_Verification.txt","Evidence/CP-006/CP006_Hash_Inventory_Verification.txt","0","2543","2543","2543"
"aff54d08dcbacaa0c54d8869749344a504c5ad61","2026-10-12T21:20:03-03:00","WASM-002 CP-006: separate artifact class and serialization","A","Evidence","Evidence/CP-006/CP006_Post_Format_Diff_Review.txt","Evidence/CP-006/CP006_Post_Format_Diff_Review.txt","0","1965","1965","1965"
"aff54d08dcbacaa0c54d8869749344a504c5ad61","2026-10-12T21:20:03-03:00","WASM-002 CP-006: separate artifact class and serialization","A","Evidence","Evidence/CP-006/CP006_Post_Format_Test_Output.txt","Evidence/CP-006/CP006_Post_Format_Test_Output.txt","0","2882","2882","2882"
"aff54d08dcbacaa0c54d8869749344a504c5ad61","2026-10-12T21:20:03-03:00","WASM-002 CP-006: separate artifact class and serialization","A","Evidence","Evidence/CP-006/CP006_Precommit_Git_Review.txt","Evidence/CP-006/CP006_Precommit_Git_Review.txt","0","2457","2457","2457"
"aff54d08dcbacaa0c54d8869749344a504c5ad61","2026-10-12T21:20:03-03:00","WASM-002 CP-006: separate artifact class and serialization","A","Evidence","Evidence/CP-006/CP006_RED_Test_Change.txt","Evidence/CP-006/CP006_RED_Test_Change.txt","0","3423","3423","3423"
"aff54d08dcbacaa0c54d8869749344a504c5ad61","2026-10-12T21:20:03-03:00","WASM-002 CP-006: separate artifact class and serialization","A","Evidence","Evidence/CP-006/CP006_RED_Test_Output.txt","Evidence/CP-006/CP006_RED_Test_Output.txt","0","792","792","792"
"aff54d08dcbacaa0c54d8869749344a504c5ad61","2026-10-12T21:20:03-03:00","WASM-002 CP-006: separate artifact class and serialization","A","Evidence","Evidence/CP-006/CP006_Starting_State.txt","Evidence/CP-006/CP006_Starting_State.txt","0","854","854","854"
"aff54d08dcbacaa0c54d8869749344a504c5ad61","2026-10-12T21:20:03-03:00","WASM-002 CP-006: separate artifact class and serialization","A","Evidence","Evidence/CP-006/CP006_WASM_Build_Output.txt","Evidence/CP-006/CP006_WASM_Build_Output.txt","0","396","396","396"
"aff54d08dcbacaa0c54d8869749344a504c5ad61","2026-10-12T21:20:03-03:00","WASM-002 CP-006: separate artifact class and serialization","M","Source","src/lib.rs","src/lib.rs","5176","6143","6143","967"
"aff54d08dcbacaa0c54d8869749344a504c5ad61","2026-10-12T21:20:03-03:00","WASM-002 CP-006: separate artifact class and serialization","A","Tests","tests/artifact_serialization_separation.rs","tests/artifact_serialization_separation.rs","0","3002","3002","3002"
"3c512df519f3a2431b363e4c57dc234c02378124","2026-10-12T21:52:18-03:00","WASM-002 CP-007: construct canonical filenames without normalization","A","Evidence","Evidence/CP-007/CP007_Format_Output.txt","Evidence/CP-007/CP007_Format_Output.txt","0","369","369","369"
"3c512df519f3a2431b363e4c57dc234c02378124","2026-10-12T21:52:18-03:00","WASM-002 CP-007: construct canonical filenames without normalization","A","Evidence","Evidence/CP-007/CP007_GREEN_Source_Change.txt","Evidence/CP-007/CP007_GREEN_Source_Change.txt","0","1535","1535","1535"
"3c512df519f3a2431b363e4c57dc234c02378124","2026-10-12T21:52:18-03:00","WASM-002 CP-007: construct canonical filenames without normalization","A","Evidence","Evidence/CP-007/CP007_GREEN_Test_Output.txt","Evidence/CP-007/CP007_GREEN_Test_Output.txt","0","3360","3360","3360"
"3c512df519f3a2431b363e4c57dc234c02378124","2026-10-12T21:52:18-03:00","WASM-002 CP-007: construct canonical filenames without normalization","A","Evidence","Evidence/CP-007/CP007_Hash_Inventory.txt","Evidence/CP-007/CP007_Hash_Inventory.txt","0","2464","2464","2464"
"3c512df519f3a2431b363e4c57dc234c02378124","2026-10-12T21:52:18-03:00","WASM-002 CP-007: construct canonical filenames without normalization","A","Evidence","Evidence/CP-007/CP007_Hash_Inventory_Verification.txt","Evidence/CP-007/CP007_Hash_Inventory_Verification.txt","0","2665","2665","2665"
"3c512df519f3a2431b363e4c57dc234c02378124","2026-10-12T21:52:18-03:00","WASM-002 CP-007: construct canonical filenames without normalization","A","Evidence","Evidence/CP-007/CP007_Post_Format_Diff_Review.txt","Evidence/CP-007/CP007_Post_Format_Diff_Review.txt","0","1870","1870","1870"
"3c512df519f3a2431b363e4c57dc234c02378124","2026-10-12T21:52:18-03:00","WASM-002 CP-007: construct canonical filenames without normalization","A","Evidence","Evidence/CP-007/CP007_Post_Format_Test_Output.txt","Evidence/CP-007/CP007_Post_Format_Test_Output.txt","0","3404","3404","3404"
"3c512df519f3a2431b363e4c57dc234c02378124","2026-10-12T21:52:18-03:00","WASM-002 CP-007: construct canonical filenames without normalization","A","Evidence","Evidence/CP-007/CP007_Precommit_Git_Review.txt","Evidence/CP-007/CP007_Precommit_Git_Review.txt","0","2398","2398","2398"
"3c512df519f3a2431b363e4c57dc234c02378124","2026-10-12T21:52:18-03:00","WASM-002 CP-007: construct canonical filenames without normalization","A","Evidence","Evidence/CP-007/CP007_RED_Test_Change.txt","Evidence/CP-007/CP007_RED_Test_Change.txt","0","3465","3465","3465"
"3c512df519f3a2431b363e4c57dc234c02378124","2026-10-12T21:52:18-03:00","WASM-002 CP-007: construct canonical filenames without normalization","A","Evidence","Evidence/CP-007/CP007_RED_Test_Output.txt","Evidence/CP-007/CP007_RED_Test_Output.txt","0","790","790","790"
"3c512df519f3a2431b363e4c57dc234c02378124","2026-10-12T21:52:18-03:00","WASM-002 CP-007: construct canonical filenames without normalization","A","Evidence","Evidence/CP-007/CP007_Starting_State.txt","Evidence/CP-007/CP007_Starting_State.txt","0","1148","1148","1148"
"3c512df519f3a2431b363e4c57dc234c02378124","2026-10-12T21:52:18-03:00","WASM-002 CP-007: construct canonical filenames without normalization","A","Evidence","Evidence/CP-007/CP007_WASM_Build_Output.txt","Evidence/CP-007/CP007_WASM_Build_Output.txt","0","396","396","396"
"3c512df519f3a2431b363e4c57dc234c02378124","2026-10-12T21:52:18-03:00","WASM-002 CP-007: construct canonical filenames without normalization","M","Source","src/lib.rs","src/lib.rs","6143","6829","6829","686"
"3c512df519f3a2431b363e4c57dc234c02378124","2026-10-12T21:52:18-03:00","WASM-002 CP-007: construct canonical filenames without normalization","A","Tests","tests/artifact_filename_construction.rs","tests/artifact_filename_construction.rs","0","2872","2872","2872"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Evidence","Evidence/CP-008/CP008_Final_Source_Review.txt","Evidence/CP-008/CP008_Final_Source_Review.txt","0","228","228","228"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Evidence","Evidence/CP-008/CP008_Final_Staging_Review.txt","Evidence/CP-008/CP008_Final_Staging_Review.txt","0","784","784","784"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Evidence","Evidence/CP-008/CP008_Full_Regression_Test_Output.txt","Evidence/CP-008/CP008_Full_Regression_Test_Output.txt","0","3948","3948","3948"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Evidence","Evidence/CP-008/CP008_GREEN_Test_Output.txt","Evidence/CP-008/CP008_GREEN_Test_Output.txt","0","849","849","849"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Evidence","Evidence/CP-008/CP008_Git_Whitespace_Check.txt","Evidence/CP-008/CP008_Git_Whitespace_Check.txt","0","34","34","34"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Evidence","Evidence/CP-008/CP008_Hash_Inventory.txt","Evidence/CP-008/CP008_Hash_Inventory.txt","0","2228","2228","2228"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Evidence","Evidence/CP-008/CP008_Hash_Inventory_Verification.txt","Evidence/CP-008/CP008_Hash_Inventory_Verification.txt","0","224","224","224"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Evidence","Evidence/CP-008/CP008_Post_Format_Test_Output.txt","Evidence/CP-008/CP008_Post_Format_Test_Output.txt","0","3829","3829","3829"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Evidence","Evidence/CP-008/CP008_Precommit_Git_Review.txt","Evidence/CP-008/CP008_Precommit_Git_Review.txt","0","6874","6874","6874"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Evidence","Evidence/CP-008/CP008_RED_Test_Output.txt","Evidence/CP-008/CP008_RED_Test_Output.txt","0","740","740","740"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Evidence","Evidence/CP-008/CP008_Rustfmt_Check_Output.txt","Evidence/CP-008/CP008_Rustfmt_Check_Output.txt","0","27","27","27"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Evidence","Evidence/CP-008/CP008_Rustfmt_Output.txt","Evidence/CP-008/CP008_Rustfmt_Output.txt","0","23","23","23"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Evidence","Evidence/CP-008/CP008_Staged_Whitespace_Diagnostic.txt","Evidence/CP-008/CP008_Staged_Whitespace_Diagnostic.txt","0","178","178","178"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Evidence","Evidence/CP-008/CP008_WASM_Build_Output.txt","Evidence/CP-008/CP008_WASM_Build_Output.txt","0","324","324","324"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Evidence","Evidence/CP-008/CP008_Whitespace_Exception_Review.txt","Evidence/CP-008/CP008_Whitespace_Exception_Review.txt","0","435","435","435"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Evidence","Evidence/Day066_Preflight_Native_Test_Output.txt","Evidence/Day066_Preflight_Native_Test_Output.txt","0","3206","3206","3206"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","M","Source","src/lib.rs","src/lib.rs","6829","7783","7783","954"
"346733a962192320e0d56271add15a47b6037b6b","2026-10-13T15:35:46-03:00","WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates","A","Tests","tests/CP008_source_eligibility.rs","tests/CP008_source_eligibility.rs","0","2189","2189","2189"
"dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","2026-10-13T16:05:03-03:00","WASM-002 CP-009: match exact CSV SOURCE names in root snapshots","A","Evidence","Evidence/CP-009/CP009_Baseline_Test_Output.txt","Evidence/CP-009/CP009_Baseline_Test_Output.txt","0","3818","3818","3818"
"dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","2026-10-13T16:05:03-03:00","WASM-002 CP-009: match exact CSV SOURCE names in root snapshots","A","Evidence","Evidence/CP-009/CP009_Final_Staging_Review.txt","Evidence/CP-009/CP009_Final_Staging_Review.txt","0","825","825","825"
"dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","2026-10-13T16:05:03-03:00","WASM-002 CP-009: match exact CSV SOURCE names in root snapshots","A","Evidence","Evidence/CP-009/CP009_Full_Regression_Test_Output.txt","Evidence/CP-009/CP009_Full_Regression_Test_Output.txt","0","4649","4649","4649"
"dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","2026-10-13T16:05:03-03:00","WASM-002 CP-009: match exact CSV SOURCE names in root snapshots","A","Evidence","Evidence/CP-009/CP009_GREEN_Test_Output.txt","Evidence/CP-009/CP009_GREEN_Test_Output.txt","0","1015","1015","1015"
"dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","2026-10-13T16:05:03-03:00","WASM-002 CP-009: match exact CSV SOURCE names in root snapshots","A","Evidence","Evidence/CP-009/CP009_Git_Whitespace_Check.txt","Evidence/CP-009/CP009_Git_Whitespace_Check.txt","0","28","28","28"
"dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","2026-10-13T16:05:03-03:00","WASM-002 CP-009: match exact CSV SOURCE names in root snapshots","A","Evidence","Evidence/CP-009/CP009_Hash_Inventory.txt","Evidence/CP-009/CP009_Hash_Inventory.txt","0","2453","2453","2453"
"dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","2026-10-13T16:05:03-03:00","WASM-002 CP-009: match exact CSV SOURCE names in root snapshots","A","Evidence","Evidence/CP-009/CP009_Hash_Inventory_Verification.txt","Evidence/CP-009/CP009_Hash_Inventory_Verification.txt","0","234","234","234"
"dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","2026-10-13T16:05:03-03:00","WASM-002 CP-009: match exact CSV SOURCE names in root snapshots","A","Evidence","Evidence/CP-009/CP009_Post_Format_Test_Output.txt","Evidence/CP-009/CP009_Post_Format_Test_Output.txt","0","4656","4656","4656"
"dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","2026-10-13T16:05:03-03:00","WASM-002 CP-009: match exact CSV SOURCE names in root snapshots","A","Evidence","Evidence/CP-009/CP009_Precommit_Git_Review.txt","Evidence/CP-009/CP009_Precommit_Git_Review.txt","0","1652","1652","1652"
"dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","2026-10-13T16:05:03-03:00","WASM-002 CP-009: match exact CSV SOURCE names in root snapshots","A","Evidence","Evidence/CP-009/CP009_RED_Test_Output.txt","Evidence/CP-009/CP009_RED_Test_Output.txt","0","1092","1092","1092"
"dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","2026-10-13T16:05:03-03:00","WASM-002 CP-009: match exact CSV SOURCE names in root snapshots","A","Evidence","Evidence/CP-009/CP009_Rustfmt_Check_Output.txt","Evidence/CP-009/CP009_Rustfmt_Check_Output.txt","0","27","27","27"
"dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","2026-10-13T16:05:03-03:00","WASM-002 CP-009: match exact CSV SOURCE names in root snapshots","A","Evidence","Evidence/CP-009/CP009_Rustfmt_Output.txt","Evidence/CP-009/CP009_Rustfmt_Output.txt","0","21","21","21"
"dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","2026-10-13T16:05:03-03:00","WASM-002 CP-009: match exact CSV SOURCE names in root snapshots","A","Evidence","Evidence/CP-009/CP009_WASM_Build_Output.txt","Evidence/CP-009/CP009_WASM_Build_Output.txt","0","324","324","324"
"dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","2026-10-13T16:05:03-03:00","WASM-002 CP-009: match exact CSV SOURCE names in root snapshots","M","Source","src/lib.rs","src/lib.rs","7783","10093","10093","2310"
"dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8","2026-10-13T16:05:03-03:00","WASM-002 CP-009: match exact CSV SOURCE names in root snapshots","A","Tests","tests/CP009_exact_root_snapshot.rs","tests/CP009_exact_root_snapshot.rs","0","4389","4389","4389"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/.gitattributes","Evidence/CP-010/.gitattributes","0","272","272","272"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Closing_Git_Review.txt","Evidence/CP-010/CP010_Closing_Git_Review.txt","0","3487","3487","3487"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Final_Staging_Review.txt","Evidence/CP-010/CP010_Final_Staging_Review.txt","0","5675","5675","5675"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Full_Regression_Test_Output.txt","Evidence/CP-010/CP010_Full_Regression_Test_Output.txt","0","5031","5031","5031"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_GREEN_Implementation_Review.txt","Evidence/CP-010/CP010_GREEN_Implementation_Review.txt","0","1069","1069","1069"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_GREEN_Test_Output.txt","Evidence/CP-010/CP010_GREEN_Test_Output.txt","0","648","648","648"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Hash_Inventory.txt","Evidence/CP-010/CP010_Hash_Inventory.txt","0","3265","3265","3265"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Hash_Inventory_Corrected.txt","Evidence/CP-010/CP010_Hash_Inventory_Corrected.txt","0","3306","3306","3306"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Hash_Inventory_Verification.txt","Evidence/CP-010/CP010_Hash_Inventory_Verification.txt","0","3567","3567","3567"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Post_Format_Check_Output.txt","Evidence/CP-010/CP010_Post_Format_Check_Output.txt","0","173","173","173"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt","Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt","0","5053","5053","5053"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Precommit_Git_Review.txt","Evidence/CP-010/CP010_Precommit_Git_Review.txt","0","2854","2854","2854"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_RED_Test_Output.txt","Evidence/CP-010/CP010_RED_Test_Output.txt","0","1942","1942","1942"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt","Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt","0","663","663","663"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Rust_Toolchain_Verification.txt","Evidence/CP-010/CP010_Rust_Toolchain_Verification.txt","0","257","257","257"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Rustfmt_Application_Output.txt","Evidence/CP-010/CP010_Rustfmt_Application_Output.txt","0","360","360","360"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Rustfmt_Check_Output.txt","Evidence/CP-010/CP010_Rustfmt_Check_Output.txt","0","679","679","679"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Scope_Lock.txt","Evidence/CP-010/CP010_Scope_Lock.txt","0","752","752","752"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Staged_Whitespace_Diagnostic.txt","Evidence/CP-010/CP010_Staged_Whitespace_Diagnostic.txt","0","368","368","368"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Starting_State.txt","Evidence/CP-010/CP010_Starting_State.txt","0","17346","17346","17346"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Supplementary_Hash_Inventory.txt","Evidence/CP-010/CP010_Supplementary_Hash_Inventory.txt","0","1138","1138","1138"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt","Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt","0","1219","1219","1219"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Test_PreFormat_Snapshot.txt","Evidence/CP-010/CP010_Test_PreFormat_Snapshot.txt","0","2175","2175","2175"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_WASM_Build_Output.txt","Evidence/CP-010/CP010_WASM_Build_Output.txt","0","229","229","229"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Whitespace_Exception_Review.txt","Evidence/CP-010/CP010_Whitespace_Exception_Review.txt","0","802","802","802"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Evidence","Evidence/CP-010/CP010_Whitespace_Followup_Verification.txt","Evidence/CP-010/CP010_Whitespace_Followup_Verification.txt","0","509","509","509"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","M","Source","src/lib.rs","src/lib.rs","10093","10589","10589","496"
"b7c515faa9bd000369d7656e09437310261290ae","2026-10-13T17:20:42-03:00","WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates","A","Tests","tests/CP010_cvt_filename_candidate.rs","tests/CP010_cvt_filename_candidate.rs","0","2172","2172","2172"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/.gitattributes","Evidence/CP-011/.gitattributes","0","236","236","236"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Closing_Git_Review.txt","Evidence/CP-011/CP011_Closing_Git_Review.txt","0","5510","5510","5510"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Final_Staging_Review.txt","Evidence/CP-011/CP011_Final_Staging_Review.txt","0","1852","1852","1852"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Full_Regression_Test_Output.txt","Evidence/CP-011/CP011_Full_Regression_Test_Output.txt","0","6032","6032","6032"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_GREEN_Source_Change.txt","Evidence/CP-011/CP011_GREEN_Source_Change.txt","0","1247","1247","1247"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_GREEN_Test_Output.txt","Evidence/CP-011/CP011_GREEN_Test_Output.txt","0","1100","1100","1100"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Hash_Inventory.txt","Evidence/CP-011/CP011_Hash_Inventory.txt","0","3339","3339","3339"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Hash_Inventory_Verification.txt","Evidence/CP-011/CP011_Hash_Inventory_Verification.txt","0","417","417","417"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt","Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt","0","6118","6118","6118"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt","Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt","0","684","684","684"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Precommit_Git_Review.txt","Evidence/CP-011/CP011_Precommit_Git_Review.txt","0","2982","2982","2982"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Preformat_Test_Snapshot.txt","Evidence/CP-011/CP011_Preformat_Test_Snapshot.txt","0","2344","2344","2344"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_RED_Test_Output.txt","Evidence/CP-011/CP011_RED_Test_Output.txt","0","942","942","942"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Rustfmt_Apply_Output.txt","Evidence/CP-011/CP011_Rustfmt_Apply_Output.txt","0","853","853","853"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Rustfmt_Check_Output.txt","Evidence/CP-011/CP011_Rustfmt_Check_Output.txt","0","2068","2068","2068"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt","Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt","0","571","571","571"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Scope_Lock.txt","Evidence/CP-011/CP011_Scope_Lock.txt","0","1138","1138","1138"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Staged_Whitespace_Diagnostic.txt","Evidence/CP-011/CP011_Staged_Whitespace_Diagnostic.txt","0","1751","1751","1751"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Staging_Recovery_Review.txt","Evidence/CP-011/CP011_Staging_Recovery_Review.txt","0","894","894","894"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Starting_State.txt","Evidence/CP-011/CP011_Starting_State.txt","0","404","404","404"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Supplementary_Hash_Inventory.txt","Evidence/CP-011/CP011_Supplementary_Hash_Inventory.txt","0","1370","1370","1370"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt","Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt","0","613","613","613"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Supplementary_Staging_Review.txt","Evidence/CP-011/CP011_Supplementary_Staging_Review.txt","0","1995","1995","1995"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_WASM_Build_Output.txt","Evidence/CP-011/CP011_WASM_Build_Output.txt","0","688","688","688"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Evidence","Evidence/CP-011/CP011_Whitespace_Exception_Review.txt","Evidence/CP-011/CP011_Whitespace_Exception_Review.txt","0","654","654","654"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","M","Source","src/lib.rs","src/lib.rs","10589","11016","11016","427"
"e84ae5baeee05f9d5d30284c65b86eebba3c0f6a","2026-10-13T18:41:56-03:00","CP011: canonical CVT-to-SCR candidate identity","A","Tests","tests/CP011_cvt_scr_candidate_identity.rs","tests/CP011_cvt_scr_candidate_identity.rs","0","2321","2321","2321"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/.gitattributes","Evidence/CP-012/.gitattributes","0","426","426","426"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_Closing_Git_Review.txt","Evidence/CP-012/CP012_Closing_Git_Review.txt","0","2353","2353","2353"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_EOF_Whitespace_Amendment.txt","Evidence/CP-012/CP012_EOF_Whitespace_Amendment.txt","0","1772","1772","1772"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_Final_Rustfmt_Check.txt","Evidence/CP-012/CP012_Final_Rustfmt_Check.txt","0","706","706","706"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_Final_Staging_Review.txt","Evidence/CP-012/CP012_Final_Staging_Review.txt","0","2228","2228","2228"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_Full_Regression_Test_Output.txt","Evidence/CP-012/CP012_Full_Regression_Test_Output.txt","0","6722","6722","6722"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_GREEN2_Test_Output.txt","Evidence/CP-012/CP012_GREEN2_Test_Output.txt","0","1279","1279","1279"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_GREEN_Correction_Review.txt","Evidence/CP-012/CP012_GREEN_Correction_Review.txt","0","1558","1558","1558"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_GREEN_Failure_Triage.txt","Evidence/CP-012/CP012_GREEN_Failure_Triage.txt","0","9465","9465","9465"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_GREEN_Rustfmt_Precheck.txt","Evidence/CP-012/CP012_GREEN_Rustfmt_Precheck.txt","0","0","0","0"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_GREEN_Source_Change.txt","Evidence/CP-012/CP012_GREEN_Source_Change.txt","0","1320","1320","1320"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_GREEN_Test_Output.txt","Evidence/CP-012/CP012_GREEN_Test_Output.txt","0","1596","1596","1596"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_Hash_Inventory.txt","Evidence/CP-012/CP012_Hash_Inventory.txt","0","3730","3730","3730"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_Hash_Inventory_Verification.txt","Evidence/CP-012/CP012_Hash_Inventory_Verification.txt","0","1492","1492","1492"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_Post_Staging_Hash_Amendment.txt","Evidence/CP-012/CP012_Post_Staging_Hash_Amendment.txt","0","1571","1571","1571"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_Post_Staging_Hash_Verification.txt","Evidence/CP-012/CP012_Post_Staging_Hash_Verification.txt","0","766","766","766"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_Precommit_Git_Review.txt","Evidence/CP-012/CP012_Precommit_Git_Review.txt","0","3086","3086","3086"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_RED_Test_Output.txt","Evidence/CP-012/CP012_RED_Test_Output.txt","0","1095","1095","1095"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_Scope_Lock.txt","Evidence/CP-012/CP012_Scope_Lock.txt","0","1317","1317","1317"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_Staged_Whitespace_Review.txt","Evidence/CP-012/CP012_Staged_Whitespace_Review.txt","0","1984","1984","1984"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_Starting_State.txt","Evidence/CP-012/CP012_Starting_State.txt","0","3699","3699","3699"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_Supplementary_Hash_Inventory.txt","Evidence/CP-012/CP012_Supplementary_Hash_Inventory.txt","0","1046","1046","1046"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_Supplementary_Hash_Verification.txt","Evidence/CP-012/CP012_Supplementary_Hash_Verification.txt","0","781","781","781"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_Test_Authoring_Format_Output.txt","Evidence/CP-012/CP012_Test_Authoring_Format_Output.txt","0","242","242","242"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_WASM_Build_Output.txt","Evidence/CP-012/CP012_WASM_Build_Output.txt","0","896","896","896"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Evidence","Evidence/CP-012/CP012_Whitespace_Exceptions_Review.txt","Evidence/CP-012/CP012_Whitespace_Exceptions_Review.txt","0","1456","1456","1456"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","M","Source","src/lib.rs","src/lib.rs","11016","11541","11541","525"
"efca04392940e398020a5c06b9ee50296c8a1fdd","2026-10-13T20:18:43-03:00","CP012: canonical SCR filename candidate recognition","A","Tests","tests/CP012_scr_filename_candidate.rs","tests/CP012_scr_filename_candidate.rs","0","1976","1976","1976"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/.gitattributes","Evidence/CP-013/.gitattributes","0","547","547","547"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Approved_Scope_Lock.txt","Evidence/CP-013/CP013_Approved_Scope_Lock.txt","0","2236","2236","2236"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Closing_Git_Review.txt","Evidence/CP-013/CP013_Closing_Git_Review.txt","0","3386","3386","3386"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Closing_Hash_Amendment.txt","Evidence/CP-013/CP013_Closing_Hash_Amendment.txt","0","1496","1496","1496"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Closing_Hash_Verification.txt","Evidence/CP-013/CP013_Closing_Hash_Verification.txt","0","4148","4148","4148"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Final_Evidence_Staging_Review.txt","Evidence/CP-013/CP013_Final_Evidence_Staging_Review.txt","0","2986","2986","2986"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Final_Staging_Verification.txt","Evidence/CP-013/CP013_Final_Staging_Verification.txt","0","5064","5064","5064"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Full_Regression_Test_Output.txt","Evidence/CP-013/CP013_Full_Regression_Test_Output.txt","0","6617","6617","6617"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Full_Regression_Verification.txt","Evidence/CP-013/CP013_Full_Regression_Verification.txt","0","674","674","674"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_GREEN_Implementation_Report.txt","Evidence/CP-013/CP013_GREEN_Implementation_Report.txt","0","752","752","752"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_GREEN_Test_Output.txt","Evidence/CP-013/CP013_GREEN_Test_Output.txt","0","767","767","767"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_GREEN_Test_Verification.txt","Evidence/CP-013/CP013_GREEN_Test_Verification.txt","0","692","692","692"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt","Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt","0","6495","6495","6495"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt","Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt","0","7179","7179","7179"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt","Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt","0","10336","10336","10336"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Hash_Inventory.txt","Evidence/CP-013/CP013_Hash_Inventory.txt","0","2803","2803","2803"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Hash_Inventory_Verification.txt","Evidence/CP-013/CP013_Hash_Inventory_Verification.txt","0","1699","1699","1699"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Opening_Git_Preflight.txt","Evidence/CP-013/CP013_Opening_Git_Preflight.txt","0","340","340","340"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt","Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt","0","1472","1472","1472"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt","Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt","0","3666","3666","3666"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Precedent_Test_Inspection.txt","Evidence/CP-013/CP013_Precedent_Test_Inspection.txt","0","8512","8512","8512"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Precommit_Git_Review.txt","Evidence/CP-013/CP013_Precommit_Git_Review.txt","0","2907","2907","2907"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt","Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt","0","568","568","568"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_RED_Test_Output.txt","Evidence/CP-013/CP013_RED_Test_Output.txt","0","607","607","607"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_RED_Test_Verification.txt","Evidence/CP-013/CP013_RED_Test_Verification.txt","0","551","551","551"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt","Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt","0","5583","5583","5583"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Rustfmt_Check_Output.txt","Evidence/CP-013/CP013_Rustfmt_Check_Output.txt","0","0","0","0"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt","Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt","0","526","526","526"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Source_Inspection.txt","Evidence/CP-013/CP013_Source_Inspection.txt","0","15768","15768","15768"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Staged_Whitespace_Recovery_Output.txt","Evidence/CP-013/CP013_Staged_Whitespace_Recovery_Output.txt","0","0","0","0"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Staged_Whitespace_Recovery_Report.txt","Evidence/CP-013/CP013_Staged_Whitespace_Recovery_Report.txt","0","856","856","856"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Staging_Action_Report.txt","Evidence/CP-013/CP013_Staging_Action_Report.txt","0","181299","181299","181299"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt","Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt","0","1115","1115","1115"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt","Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt","0","2239","2239","2239"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Test_Authoring_Report.txt","Evidence/CP-013/CP013_Test_Authoring_Report.txt","0","446","446","446"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Test_Formatting_Report.txt","Evidence/CP-013/CP013_Test_Formatting_Report.txt","0","524","524","524"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Test_Rustfmt_Output.txt","Evidence/CP-013/CP013_Test_Rustfmt_Output.txt","0","0","0","0"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_WASM_Build_Output.txt","Evidence/CP-013/CP013_WASM_Build_Output.txt","0","159","159","159"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_WASM_Build_Verification.txt","Evidence/CP-013/CP013_WASM_Build_Verification.txt","0","713","713","713"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Evidence","Evidence/CP-013/CP013_Whitespace_Exception_Review.txt","Evidence/CP-013/CP013_Whitespace_Exception_Review.txt","0","1284","1284","1284"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","M","Source","src/lib.rs","src/lib.rs","11541","12312","12312","771"
"005a38ef5e876847c4c08901c18da9c18565fd6b","2026-10-13T22:01:42-03:00","CP013: explicit SCR-to-RCP filename candidate derivation","A","Tests","tests/CP013_scr_rcp_candidate_identity.rs","tests/CP013_scr_rcp_candidate_identity.rs","0","2727","2727","2727"

ProjectDay,Date,DayKind,GitCommits,GitCheckpointCommits,LedgerCreditedCheckpoints,NewRequirementIDsTouched,GrossBytes,GrossKiB,EvidenceBytes,EvidenceKiB,SourceBytes,TestsBytes,OtherBytes,NetBytes,NetKiB,EvidencePercent
063,2026-10-10,BUILD,3,1,0,2,19798,19.334,6070,5.928,1147,2006,10575,19588,19.129,30.66
064,2026-10-11,BUILD,0,0,0,0,0,0.000,0,0.000,0,0,0,0,0.000,0.00
065,2026-10-12,BUILD,6,6,7,7,181899,177.636,141736,138.414,25880,14283,0,159905,156.157,77.92
066,2026-10-13,BUILD,6,6,6,3,572072,558.664,492964,481.410,63334,15774,0,514221,502.169,86.17

WASM-002 / DAY066 / COMMITTED VOLUME VS DEVELOPMENT VELOCITY
Read-only Git data analysis and reconciliation; no local Git commands executed by this report.
Source Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Timestamp window: 2026-10-09T00:00:00-03:00 through 2026-10-13T22:01:42-03:00
Inventory: WASM002_Git_Volume_Inventory.txt
Commits: WASM002_Git_Volume_Commits.csv
Files: WASM002_Git_Volume_Files.csv
Velocity snapshot: WASM002_Development_Velocity_History_Day066_CP013.csv
COMMIT_COUNT=15
CHANGED_FILE_RECORDS=267
GROSS_BYTES=773769
GROSS_KIB=755.634
NET_BYTES=693714
NET_KIB=677.455
EVIDENCE_BYTES=640770
EVIDENCE_KIB=625.752
SOURCE_BYTES=90361
TEST_BYTES=32063
OTHER_BYTES=10575
EVIDENCE_PERCENT=82.81
CP013_GROSS_BYTES=302051
CP013_EVIDENCE_BYTES=287012
FROZEN_REQUIREMENTS_TOUCHED=12_OF_402
BANKED_CHECKPOINTS=13
BUILD_DAYS=4
VELOCITY_CHECKPOINTS_PER_BUILD_DAY=3.25
FULLY_ACCEPTED_REQUIREMENTS=0

DAY RECONCILIATION:
Committed volume and Git checkpoint commit count use Git commit local date;
historical ledger velocity uses the credited checkpoint in its dated BUILD-day snapshots.
CP001 Git commit 2026-10-10 (Day063); ledger cumulative checkpoint count first reflects CP001 on Day065.
Do not equate zero Git volume with zero development work (Day064 Workbench prototype).
This is a historical baseline, not a measure of engineering hours, functionality, quality, or release readiness.

PER-DAY DATA:
DAY_063 Date=2026-10-10 | GitCommits=3 | GitCheckpointCommits=1 | LedgerCreditedCheckpoints=0 | GrossBytes=19798 | EvidenceBytes=6070 | SourceBytes=1147 | TestsBytes=2006 | OtherBytes=10575 | NetBytes=19588
DAY_064 Date=2026-10-11 | GitCommits=0 | GitCheckpointCommits=0 | LedgerCreditedCheckpoints=0 | GrossBytes=0 | EvidenceBytes=0 | SourceBytes=0 | TestsBytes=0 | OtherBytes=0 | NetBytes=0
DAY_065 Date=2026-10-12 | GitCommits=6 | GitCheckpointCommits=6 | LedgerCreditedCheckpoints=7 | GrossBytes=181899 | EvidenceBytes=141736 | SourceBytes=25880 | TestsBytes=14283 | OtherBytes=0 | NetBytes=159905
DAY_066 Date=2026-10-13 | GitCommits=6 | GitCheckpointCommits=6 | LedgerCreditedCheckpoints=6 | GrossBytes=572072 | EvidenceBytes=492964 | SourceBytes=63334 | TestsBytes=15774 | OtherBytes=0 | NetBytes=514221

SHA256_INPUT_COMMITS=68CE57F9BD062C05238B034EE3313C31A2B486794430F9B7BA4F3FB30A9BA5BD
SHA256_INPUT_FILES=C82884BFAF38906976048FF8264B1367199BF9CE0A1CB02E510F1FEDA067094F
SHA256_INPUT_INVENTORY=95DD9D51B4256052087A1B0FAA04FCCAFB120520E6FF501A4899A7357870EC8B
SHA256_DERIVED_DAILY=7733A47D924AA3A1571EC909ABA5DFB970683A1942818CFA3499D5EBE7C05BA7
VALIDATION=PASS: 15 commits and 267 file records; per-commit category/size reconciliation; daily sums match inventory; preserved checkpoint history.
GIT_CHANGES_PERFORMED=False
DAY_066=OPEN
RESULT: PASS - COMMITTED VOLUME RECONCILIATION

CP014 EVIDENCE INTEGRITY PREFLIGHT
Day: 067
Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Source SHA256: B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236
Test SHA256: 27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
WASM log SHA256: E0553F624C36C32260BF6850045362AB18920896E111C2E94ABAA6D022BD583A
Pre-existing evidence TXT files: 17
Original evidence modified: NO
Git staging performed: NO

--- ORIGINAL EVIDENCE INVENTORY ---

File: CP014_Full_Regression_Record.txt
Bytes: 611
SHA256: 051556BE29E0C06BA560C37BBE8F3BE478D82DE40FF830897657B976F31E0626
UTF8 BOM: False
LF endings: 0
CRLF endings: 15
Other CR bytes: 0
Lines with trailing SP/TAB: 0

File: CP014_Full_Regression_Test_Output.txt
Bytes: 7164
SHA256: 9669D0A3040CCCC2B6F7768FC4E84BC1D71FD69D20CD261B20CABBB0938A83DF
UTF8 BOM: False
LF endings: 156
CRLF endings: 0
Other CR bytes: 0
Lines with trailing SP/TAB: 0

File: CP014_GREEN_Run_Record.txt
Bytes: 588
SHA256: C28E4993E66A1E790B24E78E59953711A7EDFB34D5F9D2812C294C427591533E
UTF8 BOM: False
LF endings: 0
CRLF endings: 12
Other CR bytes: 0
Lines with trailing SP/TAB: 0

File: CP014_GREEN_Test_Output.txt
Bytes: 707
SHA256: 6C79FD4AA16190F4F9851334435FB601014D61D3A59B40F3A3E18151FAA550B8
UTF8 BOM: False
LF endings: 14
CRLF endings: 0
Other CR bytes: 0
Lines with trailing SP/TAB: 0

File: CP014_Implementation_Record.txt
Bytes: 529
SHA256: 1B23A6A15EE66CA820BC15C2D935099DE510CB30BEBD32E2B8422C5C5773B184
UTF8 BOM: False
LF endings: 0
CRLF endings: 13
Other CR bytes: 0
Lines with trailing SP/TAB: 0

File: CP014_Implementation_Surface.txt
Bytes: 10143
SHA256: 5573FDE0F50394BFE63ADECA872B6C84CCAAE5643F54426A29E816DD15F5264F
UTF8 BOM: True
LF endings: 0
CRLF endings: 262
Other CR bytes: 0
Lines with trailing SP/TAB: 39

File: CP014_RED_Run_Record.txt
Bytes: 398
SHA256: 816E574D51AD7B9CA99E96A637993D78F3E63175694A3DD03492AE9CDD80B111
UTF8 BOM: False
LF endings: 0
CRLF endings: 8
Other CR bytes: 0
Lines with trailing SP/TAB: 0

File: CP014_RED_Test_Output.txt
Bytes: 870
SHA256: 8E3F94F9567BDA62E90DE377FD76346CC98514AC106EE941152D84FAA7227AF0
UTF8 BOM: False
LF endings: 15
CRLF endings: 0
Other CR bytes: 0
Lines with trailing SP/TAB: 0

File: CP014_Rustfmt_Check_Output.txt
Bytes: 0
SHA256: E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
UTF8 BOM: False
LF endings: 0
CRLF endings: 0
Other CR bytes: 0
Lines with trailing SP/TAB: 0

File: CP014_Rustfmt_Check_Record.txt
Bytes: 530
SHA256: A3A58BCD382E8DAEC99008BC70299403DA9A884AD45B0A26557EAA334203FBEB
UTF8 BOM: False
LF endings: 0
CRLF endings: 11
Other CR bytes: 0
Lines with trailing SP/TAB: 0

File: CP014_Rustfmt_Output.txt
Bytes: 0
SHA256: E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
UTF8 BOM: False
LF endings: 0
CRLF endings: 0
Other CR bytes: 0
Lines with trailing SP/TAB: 0

File: CP014_Scope_Inspection.txt
Bytes: 4967
SHA256: 8760615464B2477CD85CCE2A74302BDB6421CEBA0726920BD6C9FDCC915D3C02
UTF8 BOM: True
LF endings: 5
CRLF endings: 118
Other CR bytes: 0
Lines with trailing SP/TAB: 0

File: CP014_Scope_Lock.txt
Bytes: 826
SHA256: FD47D4837EE8152D95DCD5C3EFA3746D5404D0B40576CEDFE50597CF887ABB9D
UTF8 BOM: False
LF endings: 33
CRLF endings: 0
Other CR bytes: 0
Lines with trailing SP/TAB: 0

File: CP014_Source_Diff.txt
Bytes: 894
SHA256: 74FD689FA0528F12A4BCA6BFD66CB226EBE77E85170D0E0CD775ED81F10B5E61
UTF8 BOM: True
LF endings: 0
CRLF endings: 28
Other CR bytes: 0
Lines with trailing SP/TAB: 1

File: CP014_Test_Format_Record.txt
Bytes: 392
SHA256: 350F43CAA2E14C4F51E700288D5EF7FFECC09D14480E8D0A102BCF14D59DCD58
UTF8 BOM: False
LF endings: 0
CRLF endings: 8
Other CR bytes: 0
Lines with trailing SP/TAB: 0

File: CP014_WASM_Build_Output.txt
Bytes: 159
SHA256: E0553F624C36C32260BF6850045362AB18920896E111C2E94ABAA6D022BD583A
UTF8 BOM: False
LF endings: 2
CRLF endings: 0
Other CR bytes: 0
Lines with trailing SP/TAB: 0

File: CP014_WASM_Build_Record.txt
Bytes: 562
SHA256: 8CCD83F6E36C54CECF3DFA34A17A1EDD1E82BBB7BFAA03078F13D4AC807DCD4C
UTF8 BOM: False
LF endings: 0
CRLF endings: 12
Other CR bytes: 0
Lines with trailing SP/TAB: 0

--- GIT WORKING TREE STATUS ---
Exit code: 0
 M src/lib.rs
?? Evidence/CP-014/CP014_Full_Regression_Record.txt
?? Evidence/CP-014/CP014_Full_Regression_Test_Output.txt
?? Evidence/CP-014/CP014_GREEN_Run_Record.txt
?? Evidence/CP-014/CP014_GREEN_Test_Output.txt
?? Evidence/CP-014/CP014_Implementation_Record.txt
?? Evidence/CP-014/CP014_Implementation_Surface.txt
?? Evidence/CP-014/CP014_RED_Run_Record.txt
?? Evidence/CP-014/CP014_RED_Test_Output.txt
?? Evidence/CP-014/CP014_Rustfmt_Check_Output.txt
?? Evidence/CP-014/CP014_Rustfmt_Check_Record.txt
?? Evidence/CP-014/CP014_Rustfmt_Output.txt
?? Evidence/CP-014/CP014_Scope_Inspection.txt
?? Evidence/CP-014/CP014_Scope_Lock.txt
?? Evidence/CP-014/CP014_Source_Diff.txt
?? Evidence/CP-014/CP014_Test_Format_Record.txt
?? Evidence/CP-014/CP014_WASM_Build_Output.txt
?? Evidence/CP-014/CP014_WASM_Build_Record.txt
?? tests/CP014_rcp_filename_candidate_identity.rs

--- UNSTAGED TRACKED DIFF WHITESPACE CHECK ---
Exit code: 0

--- EVIDENCE GIT ATTRIBUTES ---
Exit code: 0
Evidence/CP-014/CP014_Full_Regression_Record.txt: text: auto
Evidence/CP-014/CP014_Full_Regression_Test_Output.txt: text: auto
Evidence/CP-014/CP014_GREEN_Run_Record.txt: text: auto
Evidence/CP-014/CP014_GREEN_Test_Output.txt: text: auto
Evidence/CP-014/CP014_Implementation_Record.txt: text: auto
Evidence/CP-014/CP014_Implementation_Surface.txt: text: auto
Evidence/CP-014/CP014_RED_Run_Record.txt: text: auto
Evidence/CP-014/CP014_RED_Test_Output.txt: text: auto
Evidence/CP-014/CP014_Rustfmt_Check_Output.txt: text: auto
Evidence/CP-014/CP014_Rustfmt_Check_Record.txt: text: auto
Evidence/CP-014/CP014_Rustfmt_Output.txt: text: auto
Evidence/CP-014/CP014_Scope_Inspection.txt: text: auto
Evidence/CP-014/CP014_Scope_Lock.txt: text: auto
Evidence/CP-014/CP014_Source_Diff.txt: text: auto
Evidence/CP-014/CP014_Test_Format_Record.txt: text: auto
Evidence/CP-014/CP014_WASM_Build_Output.txt: text: auto
Evidence/CP-014/CP014_WASM_Build_Record.txt: text: auto

--- GATE SUMMARY ---
Git status exit: 0
Tracked diff whitespace exit: 0
Git attributes exit: 0
Evidence whitespace findings require classification.
Untracked files require staged review later.
NO automatic normalization or repair authorized.

CP014 FINAL PRE-ACCEPTANCE REVIEW
Day: 067
Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Branch: master
Total staged paths: 34
Staged evidence ZIPs: 32
Staged Rust files: 2
Rust diff exit: 0
Staged stat exit: 0
Whitespace check exit: 0
Source SHA256: B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236
Test SHA256: 27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
Pre-acceptance review PASS: True
Git commit executed: NO
Git banking authorized: NO

diff --git a/src/lib.rs b/src/lib.rs
index b2df81b..56916f9 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -381,3 +381,23 @@ pub fn build_final_filename_candidate_for_scr(
 
     Some(scr_filename.replacen("__DS__SCR__", "__DS__RCP__", 1))
 }
+
+/// Recognizes a canonical RCP Receipt filename candidate.
+///
+/// Lexical recognition only. This does not verify Receipt contents,
+/// filesystem state, staging promotion, publication, or authority.
+pub fn is_canonical_rcp_filename_candidate(filename: &str) -> bool {
+    if filename
+        .chars()
+        .any(|ch| ch.is_whitespace() || ch == '/' || ch == '\\')
+    {
+        return false;
+    }
+
+    matches!(
+        extract_artifact_filename_tokens(filename),
+        Some(tokens)
+            if tokens.semantic_class == "RCP"
+                && tokens.serialization_extension == "txt"
+    )
+}
diff --git a/tests/CP014_rcp_filename_candidate_identity.rs b/tests/CP014_rcp_filename_candidate_identity.rs
new file mode 100644
index 0000000..f5d6552
--- /dev/null
+++ b/tests/CP014_rcp_filename_candidate_identity.rs
@@ -0,0 +1,86 @@
+// CP014 RED tests - Day 067
+// Frozen anchors: W002-RCP-002, W002-STOR-023, W002-STOR-023.1.
+// Lexical RCP filename recognition only.
+// No content validation, filesystem activity, promotion, or authority.
+
+use data_sculptor_core::{
+    build_final_filename_candidate_for_scr, is_canonical_rcp_filename_candidate,
+};
+
+const RCP: &str = "__DS__RCP__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.txt";
+
+const SCR: &str = "__DS__SCR__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.txt";
+
+#[test]
+fn accepts_canonical_rcp_txt_identity() {
+    assert!(is_canonical_rcp_filename_candidate(RCP));
+
+    assert!(is_canonical_rcp_filename_candidate(
+        "__DS__RCP__20261013T173300000Z__123e4567-e89b-42d3-a456-426614174000.txt"
+    ));
+}
+
+#[test]
+fn recognizes_existing_scr_to_rcp_derivation() {
+    let candidate = build_final_filename_candidate_for_scr(SCR, "RCP")
+        .expect("CP013 should derive an RCP candidate");
+
+    assert_eq!(candidate, RCP);
+    assert!(is_canonical_rcp_filename_candidate(&candidate));
+    assert!(!is_canonical_rcp_filename_candidate(SCR));
+}
+
+#[test]
+fn refuses_wrong_semantic_class_and_case() {
+    for filename in [
+        RCP.replace("__DS__RCP__", "__DS__SCR__"),
+        RCP.replace("__DS__RCP__", "__DS__CVT__"),
+        RCP.replace("__DS__RCP__", "__DS__rcp__"),
+        RCP.replace("__DS__RCP__", "__DS__Rcp__"),
+        RCP.replace("__DS__RCP__", "__DS__RCV__"),
+    ] {
+        assert!(!is_canonical_rcp_filename_candidate(&filename));
+    }
+}
+
+#[test]
+fn refuses_noncanonical_serialization() {
+    for filename in [
+        RCP.replace(".txt", ".csv"),
+        RCP.replace(".txt", ".TXT"),
+        RCP.replace(".txt", ".html"),
+        RCP.replace(".txt", ".txt.gz"),
+        RCP.replace(".txt", "."),
+        RCP.replace(".txt", ""),
+    ] {
+        assert!(!is_canonical_rcp_filename_candidate(&filename));
+    }
+}
+
+#[test]
+fn refuses_invalid_timestamp_uuid_and_envelope() {
+    for filename in [
+        RCP.replace("20261014", "20260230"),
+        RCP.replace("T011203456Z", "T251203456Z"),
+        RCP.replace("-41d4-", "-51d4-"),
+        RCP.replace("-a716-", "-1716-"),
+        RCP.replacen("__DS__", "__ds__", 1),
+        "ordinary.txt".to_string(),
+    ] {
+        assert!(!is_canonical_rcp_filename_candidate(&filename));
+    }
+}
+
+#[test]
+fn refuses_paths_and_whitespace() {
+    for filename in [
+        format!("folder/{RCP}"),
+        format!("folder\\{RCP}"),
+        format!(" {RCP}"),
+        format!("{RCP} "),
+        format!("{RCP}\n"),
+        format!("{RCP}\t"),
+    ] {
+        assert!(!is_canonical_rcp_filename_candidate(&filename));
+    }
+}

 .../CP-014/ZIP/CP014_Evidence_Preflight.txt.zip    | Bin 0 -> 1980 bytes
 .../ZIP/CP014_Full_Regression_Record.txt.zip       | Bin 0 -> 587 bytes
 .../ZIP/CP014_Full_Regression_Test_Output.txt.zip  | Bin 0 -> 1913 bytes
 Evidence/CP-014/ZIP/CP014_GREEN_Run_Record.txt.zip | Bin 0 -> 575 bytes
 .../CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip     | Bin 0 -> 547 bytes
 .../CP014_Git_Attributes_Amendment_Record.txt.zip  | Bin 0 -> 593 bytes
 .../ZIP/CP014_Git_Attributes_Diff_Recovery.txt.zip | Bin 0 -> 386 bytes
 .../CP014_Git_Attributes_Recovery_Record.txt.zip   | Bin 0 -> 654 bytes
 .../ZIP/CP014_Git_Text_Policy_Inspection.txt.zip   | Bin 0 -> 614 bytes
 Evidence/CP-014/ZIP/CP014_Hash_Inventory.txt.zip   | Bin 0 -> 1611 bytes
 .../ZIP/CP014_Hash_Inventory_Verification.txt.zip  | Bin 0 -> 458 bytes
 .../CP-014/ZIP/CP014_Implementation_Record.txt.zip | Bin 0 -> 545 bytes
 .../ZIP/CP014_Implementation_Surface.txt.zip       | Bin 0 -> 3401 bytes
 Evidence/CP-014/ZIP/CP014_RED_Run_Record.txt.zip   | Bin 0 -> 453 bytes
 Evidence/CP-014/ZIP/CP014_RED_Test_Output.txt.zip  | Bin 0 -> 500 bytes
 .../CP-014/ZIP/CP014_Rustfmt_Check_Output.txt.zip  | Bin 0 -> 158 bytes
 .../CP-014/ZIP/CP014_Rustfmt_Check_Record.txt.zip  | Bin 0 -> 545 bytes
 Evidence/CP-014/ZIP/CP014_Rustfmt_Output.txt.zip   | Bin 0 -> 146 bytes
 Evidence/CP-014/ZIP/CP014_Scope_Inspection.txt.zip | Bin 0 -> 1588 bytes
 Evidence/CP-014/ZIP/CP014_Scope_Lock.txt.zip       | Bin 0 -> 705 bytes
 Evidence/CP-014/ZIP/CP014_Source_Diff.txt.zip      | Bin 0 -> 630 bytes
 Evidence/CP-014/ZIP/CP014_Staged_Path_List.txt.zip | Bin 0 -> 453 bytes
 .../ZIP/CP014_Staged_Whitespace_Check.txt.zip      | Bin 0 -> 12668 bytes
 .../ZIP/CP014_Staging_Command_Output.txt.zip       | Bin 0 -> 257 bytes
 Evidence/CP-014/ZIP/CP014_Staging_Record.txt.zip   | Bin 0 -> 528 bytes
 .../CP-014/ZIP/CP014_Test_Format_Record.txt.zip    | Bin 0 -> 456 bytes
 .../CP-014/ZIP/CP014_WASM_Build_Output.txt.zip     | Bin 0 -> 293 bytes
 .../CP-014/ZIP/CP014_WASM_Build_Record.txt.zip     | Bin 0 -> 551 bytes
 .../ZIP/CP014_ZIP_Batch_Verification.txt.zip       | Bin 0 -> 3494 bytes
 .../ZIP/CP014_ZIP_Pilot_Git_Add_Output.txt.zip     | Bin 0 -> 166 bytes
 .../CP-014/ZIP/CP014_ZIP_Pilot_Git_Record.txt.zip  | Bin 0 -> 571 bytes
 .../ZIP/CP014_ZIP_Pilot_Verification.txt.zip       | Bin 0 -> 573 bytes
 src/lib.rs                                         |  20 +++++
 tests/CP014_rcp_filename_candidate_identity.rs     |  86 +++++++++++++++++++++
 34 files changed, 106 insertions(+)

CP014 FULL NATIVE REGRESSION RECORD
Day: 067
Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Command: cargo +1.97.1 test
Exit code: 0
Test suites reported: 15
Passing tests counted: 64
Expected passing tests: 64
Expected count met: True
Source SHA256: B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236
Test SHA256: 27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
Raw Cargo log SHA256: 9669D0A3040CCCC2B6F7768FC4E84BC1D71FD69D20CD261B20CABBB0938A83DF
Raw output: CP014_Full_Regression_Test_Output.txt
Canonical WASM build executed: NO
Git banking authorized: NO

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 2.59s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP008_source_eligibility.rs (target\debug\deps\CP008_source_eligibility-194c314726b26929.exe)

running 5 tests
test accepts_analyst_csv_final_extension_in_ascii_case_variants ... ok
test makes_no_case_or_unicode_normalization_claim ... ok
test refuses_paths_traversal_and_external_references ... ok
test refuses_reserved_namespace_even_if_name_looks_like_csv ... ok
test rejects_non_csv_or_nonfinal_csv_extensions ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP009_exact_root_snapshot.rs (target\debug\deps\CP009_exact_root_snapshot-b26a1b02e36e8f07.exe)

running 8 tests
test candidate_preflight_runs_before_root_matching ... ok
test full_filename_match_is_exact_and_case_sensitive ... ok
test duplicate_exact_entries_refuse_instead_of_picking_first ... ok
test finds_one_exact_reported_regular_file ... ok
test never_trims_to_find_a_different_physical_name ... ok
test reported_non_regular_entries_do_not_pass ... ok
test result_is_order_independent_and_empty_snapshot_is_not_found ... ok
test unicode_scalar_sequence_is_not_normalized ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP010_cvt_filename_candidate.rs (target\debug\deps\CP010_cvt_filename_candidate-ce216c0140f6b173.exe)

running 4 tests
test accepts_exact_canonical_cvt_csv_candidate ... ok
test refuses_malformed_canonical_identity ... ok
test refuses_paths_and_noncanonical_references ... ok
test refuses_wrong_classes_and_extensions ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP011_cvt_scr_candidate_identity.rs (target\debug\deps\CP011_cvt_scr_candidate_identity-8bc68fabbbb42eb4.exe)

running 6 tests
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test derives_exact_corresponding_scr_identity ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_whitespace_and_noncanonical_names ... ok
test refuses_wrong_extension_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP012_scr_filename_candidate.rs (target\debug\deps\CP012_scr_filename_candidate-7c39746d8bb6fac7.exe)

running 6 tests
test accepts_canonical_scr_txt_candidate ... ok
test refuses_invalid_utc_and_uuid ... ok
test accepts_canonical_scr_csv_candidate ... ok
test refuses_noncanonical_namespace_class_and_extension ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_and_whitespace ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP013_scr_rcp_candidate_identity.rs (target\debug\deps\CP013_scr_rcp_candidate_identity-4f7c7bea8654150d.exe)

running 6 tests
test derives_rcp_candidate_only_with_explicit_class ... ok
test refuses_invalid_identity_paths_and_whitespace ... ok
test refuses_non_scr_and_noncanonical_source_classes ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_unsupported_or_incorrectly_cased_final_classes ... ok
test refuses_wrong_or_ambiguous_serialization_extensions ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP014_rcp_filename_candidate_identity.rs (target\debug\deps\CP014_rcp_filename_candidate_identity-249a1cd498442ced.exe)

running 6 tests
test accepts_canonical_rcp_txt_identity ... ok
test refuses_invalid_timestamp_uuid_and_envelope ... ok
test recognizes_existing_scr_to_rcp_derivation ... ok
test refuses_noncanonical_serialization ... ok
test refuses_paths_and_whitespace ... ok
test refuses_wrong_semantic_class_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)

running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_registered_emittable_classes ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)

running 4 tests
test constructs_exact_canonical_filename_candidates ... ok
test preserves_extension_without_case_or_unicode_normalization ... ok
test refuses_noncanonical_class_without_repair ... ok
test refuses_invalid_timestamp_uuid_and_empty_extension ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)

running 3 tests
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)

running 6 tests
test recognizes_governed_namespace_and_class ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_invalid_class_boundaries ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)

running 4 tests
test extension_does_not_determine_semantic_class ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok
test extracts_semantic_class_and_serialization_separately ... ok
test preserves_literal_tokens_without_claiming_authority ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

running 3 tests
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_nonexistent_gregorian_dates ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests data_sculptor_core

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

CP014 GIT ATTRIBUTES AMENDMENT
Day: 067
Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Rule: Evidence/CP-014/*.txt -text
Purpose: Preserve original CP014 TXT evidence bytes.
Attributes SHA256 before: 978CF143947177C92114C50A5C68F24B6E9818597AA64788406884E116EC5A0B
Attributes SHA256 after: 3C48424F40BE15C07FE03C7AB0731DBF13CDE0FF2729275FD7D4E6B9B825604B
Existing TXT files checked: 19
Original TXT bytes unchanged: True
All original TXT paths protected: True
Git check-attr exit: 0
Git diff exit: -1
Diff evidence: CP014_Git_Attributes_Diff.txt
Git staging performed: NO
Git banking authorized: NO

warning: in the working copy of '.gitattributes', LF will be replaced by CRLF the next time Git touches it
diff --git a/.gitattributes b/.gitattributes
index b38a50c..e934e4b 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -4,3 +4,4 @@
 Cargo.lock text eol=lf
 *.sh text eol=lf
 *.ps1 text eol=crlf
+Evidence/CP-014/*.txt -text

CP014 GIT ATTRIBUTES RECOVERY RECORD
Day: 067
Purpose: Recover diff capture after PowerShell NativeCommandError.
Original failed amendment record preserved: YES
Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Attributes SHA256: 3C48424F40BE15C07FE03C7AB0731DBF13CDE0FF2729275FD7D4E6B9B825604B
Recovery command: git --no-pager diff -- .gitattributes
Git exit code: 0
LF/CRLF warning captured: True
Expected preservation rule found: True
Only expected diff addition: True
Raw recovery output SHA256: FC54CF9CF95253519DFF561FC1DEF8D457BB815343FD4C75D81ABE9895DA366E
Raw output: CP014_Git_Attributes_Diff_Recovery.txt
Original evidence modified: NO
Git staging performed: NO
Git banking authorized: NO

[master f5038a1] CP014: recognize canonical RCP filename candidates
 34 files changed, 106 insertions(+)
 create mode 100644 Evidence/CP-014/ZIP/CP014_Evidence_Preflight.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Full_Regression_Record.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_GREEN_Run_Record.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Git_Attributes_Amendment_Record.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Git_Attributes_Diff_Recovery.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Git_Attributes_Recovery_Record.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Git_Text_Policy_Inspection.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Hash_Inventory.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Hash_Inventory_Verification.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Implementation_Record.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Implementation_Surface.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_RED_Run_Record.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_RED_Test_Output.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Rustfmt_Check_Output.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Rustfmt_Check_Record.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Rustfmt_Output.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Scope_Inspection.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Scope_Lock.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Source_Diff.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Staged_Path_List.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Staged_Whitespace_Check.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Staging_Command_Output.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Staging_Record.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_Test_Format_Record.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_WASM_Build_Output.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_WASM_Build_Record.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_ZIP_Batch_Verification.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Git_Add_Output.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Git_Record.txt.zip
 create mode 100644 Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Verification.txt.zip
 create mode 100644 tests/CP014_rcp_filename_candidate_identity.rs

CP014 GIT BANKING RECORD
Day: 067
Human CP014 acceptance: GRANTED
Git banking authorization: GRANTED
Branch: master
Previous HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Committed HEAD: f5038a183f1d3dc31b0065571bf8ac8814b5d8a9
Commit parent: 005a38ef5e876847c4c08901c18da9c18565fd6b
Commit exit: 0
Expected committed paths: 34
Actual committed paths: 34
Missing paths: 0
Unexpected paths: 0
ZIP fingerprints checked: 32/32
Committed object identities verified: 34/34
Index clean exit: 0
Git status exit: 0
Banking verification PASS: True
Day 067: OPEN
Original TXT evidence preserved locally.
External closeout evidence preserved outside repository.

CP014 GIT TEXT POLICY INSPECTION
Day 067 - READ ONLY

--- EXISTING .gitattributes ---
* text=auto
*.rs text eol=lf
*.toml text eol=lf
Cargo.lock text eol=lf
*.sh text eol=lf
*.ps1 text eol=crlf

--- EFFECTIVE FILE ATTRIBUTES ---
Evidence/CP-014/CP014_Implementation_Surface.txt: text: auto
Evidence/CP-014/CP014_Source_Diff.txt: text: auto
Evidence/CP-014/CP014_RED_Test_Output.txt: text: auto
Evidence/CP-014/CP014_GREEN_Run_Record.txt: text: auto
Exit code: 0

--- GIT CONFIGURATION ---
core.autocrlf : file:C:/Program Files/Git/etc/gitconfig	true
Exit code: 0
core.safecrlf : (unset)
core.whitespace : (unset)

--- CURRENT GIT STATUS ---
## master
 M src/lib.rs
?? Evidence/CP-014/
?? tests/CP014_rcp_filename_candidate_identity.rs
Exit code: 0

No staging or normalization performed.

CP014 TARGETED GREEN EXECUTION RECORD
Day: 067
Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Command: cargo +1.97.1 test --test CP014_rcp_filename_candidate_identity -- --nocapture
Exit code: 0
Six passed, zero failed: True
Source SHA256: B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236
Test SHA256: 27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
Raw Cargo log SHA256: 6C79FD4AA16190F4F9851334435FB601014D61D3A59B40F3A3E18151FAA550B8
Raw Cargo output: CP014_GREEN_Test_Output.txt
Full regression executed: NO
Git banking authorized: NO

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 2.04s
     Running tests\CP014_rcp_filename_candidate_identity.rs (target\debug\deps\CP014_rcp_filename_candidate_identity-249a1cd498442ced.exe)

running 6 tests
test accepts_canonical_rcp_txt_identity ... ok
test recognizes_existing_scr_to_rcp_derivation ... ok
test refuses_invalid_timestamp_uuid_and_envelope ... ok
test refuses_noncanonical_serialization ... ok
test refuses_paths_and_whitespace ... ok
test refuses_wrong_semantic_class_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

# CP014 PRE-STAGING SHA256 INVENTORY
# Day 067
# Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
# Entries: 25
# Original evidence preserved without modification
# Format: SHA256<TAB>REPOSITORY_RELATIVE_PATH
3C48424F40BE15C07FE03C7AB0731DBF13CDE0FF2729275FD7D4E6B9B825604B	.gitattributes
B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236	src/lib.rs
27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4	tests/CP014_rcp_filename_candidate_identity.rs
62748820D199957C385FF28BDA6B6EDF4B82E80ED90C05E9A1F57CC9BE4ABC5A	Evidence/CP-014/CP014_Evidence_Preflight.txt
051556BE29E0C06BA560C37BBE8F3BE478D82DE40FF830897657B976F31E0626	Evidence/CP-014/CP014_Full_Regression_Record.txt
9669D0A3040CCCC2B6F7768FC4E84BC1D71FD69D20CD261B20CABBB0938A83DF	Evidence/CP-014/CP014_Full_Regression_Test_Output.txt
7C9D6A199D4F5F912B10E63FC94F72254D3EECEF7787E4D49155B8FBE677F3D5	Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt
FC54CF9CF95253519DFF561FC1DEF8D457BB815343FD4C75D81ABE9895DA366E	Evidence/CP-014/CP014_Git_Attributes_Diff_Recovery.txt
212CA232CE05AEDE0FBD932AADF48000E6A3C8A0F56EFEF0A2C6EC891B597238	Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt
3E30775424DEC65711D193156EE720DCEE4B1CB20ED096AEE9C67DF7042B09FE	Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt
C28E4993E66A1E790B24E78E59953711A7EDFB34D5F9D2812C294C427591533E	Evidence/CP-014/CP014_GREEN_Run_Record.txt
6C79FD4AA16190F4F9851334435FB601014D61D3A59B40F3A3E18151FAA550B8	Evidence/CP-014/CP014_GREEN_Test_Output.txt
1B23A6A15EE66CA820BC15C2D935099DE510CB30BEBD32E2B8422C5C5773B184	Evidence/CP-014/CP014_Implementation_Record.txt
5573FDE0F50394BFE63ADECA872B6C84CCAAE5643F54426A29E816DD15F5264F	Evidence/CP-014/CP014_Implementation_Surface.txt
816E574D51AD7B9CA99E96A637993D78F3E63175694A3DD03492AE9CDD80B111	Evidence/CP-014/CP014_RED_Run_Record.txt
8E3F94F9567BDA62E90DE377FD76346CC98514AC106EE941152D84FAA7227AF0	Evidence/CP-014/CP014_RED_Test_Output.txt
E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855	Evidence/CP-014/CP014_Rustfmt_Check_Output.txt
A3A58BCD382E8DAEC99008BC70299403DA9A884AD45B0A26557EAA334203FBEB	Evidence/CP-014/CP014_Rustfmt_Check_Record.txt
E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855	Evidence/CP-014/CP014_Rustfmt_Output.txt
8760615464B2477CD85CCE2A74302BDB6421CEBA0726920BD6C9FDCC915D3C02	Evidence/CP-014/CP014_Scope_Inspection.txt
FD47D4837EE8152D95DCD5C3EFA3746D5404D0B40576CEDFE50597CF887ABB9D	Evidence/CP-014/CP014_Scope_Lock.txt
74FD689FA0528F12A4BCA6BFD66CB226EBE77E85170D0E0CD775ED81F10B5E61	Evidence/CP-014/CP014_Source_Diff.txt
350F43CAA2E14C4F51E700288D5EF7FFECC09D14480E8D0A102BCF14D59DCD58	Evidence/CP-014/CP014_Test_Format_Record.txt
E0553F624C36C32260BF6850045362AB18920896E111C2E94ABAA6D022BD583A	Evidence/CP-014/CP014_WASM_Build_Output.txt
8CCD83F6E36C54CECF3DFA34A17A1EDD1E82BBB7BFAA03078F13D4AC807DCD4C	Evidence/CP-014/CP014_WASM_Build_Record.txt

CP014 SHA256 INVENTORY VERIFICATION
Day: 067
Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Inventory: CP014_Hash_Inventory.txt
Inventory SHA256: 6ED47A9151696174BF9E8193B8B5399E662270ED10436FED29C1F1D732389472
Files inventoried: 25
Files verified: 25
Mismatches: 0
All hashes verified: True
Inventory and verification excluded from snapshot.
Git staging performed: NO
Git banking authorized: NO

CP014 MINIMAL GREEN IMPLEMENTATION RECORD
Day: 067
Baseline Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Branch: master
Source: src/lib.rs
Before SHA256: 99741F26933AA8EEDBF1E75031F5012CA01918D06E1A3D013CA1703A49842649
After SHA256: B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236
Test SHA256: 27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
Bytes appended: 603
Git diff exit code: 0
Diff evidence: CP014_Source_Diff.txt
Targeted GREEN executed: NO
Git banking authorized: NO

=== CP014 IMPLEMENTATION SURFACE ===
READ-ONLY SOURCE INSPECTION
  90:         }
  91: 
  92:         matched_kind = Some(entry.kind);
  93:     }
  94: 
  95:     match matched_kind {
  96:         None => RootSnapshotMatch::NotFound,
  97:         Some(RootSnapshotEntryKind::RegularFile) => RootSnapshotMatch::SingleReportedRegularFile,
  98:         Some(RootSnapshotEntryKind::Directory | RootSnapshotEntryKind::Other) => {
  99:             RootSnapshotMatch::NonRegularEntry
 100:         }
 101:     }
 102: }
 103: 
 104: /// Recognizes a governed Data Sculptor artifact class from a filename.
 105: ///
 106: /// Lexical recognition only: this does not validate file contents,
 107: /// artifact authority, publication eligibility, or filesystem state.
 108: pub fn reserved_artifact_class(filename: &str) -> Option<&'static str> {
 109:     let rest = filename.strip_prefix("__DS__")?;
 110:     let (class, suffix) = rest.split_once("__")?;
 111: 
 112:     if suffix.is_empty() {
 113:         return None;
 114:     }
 115: 
 116:     match class {
 117:         "WKO" => Some("WKO"),
 118:         "MAP" => Some("MAP"),
 119:         "CAT" => Some("CAT"),
 120:         "DGN" => Some("DGN"),
 121:         "RCV" => Some("RCV"),
 122:         "BRD" => Some("BRD"),
 123:         "LCK" => Some("LCK"),
 124:         "RCP" => Some("RCP"),
 125:         "HLP" => Some("HLP"),
 126:         "CER" => Some("CER"),
 127:         "CVT" => Some("CVT"),
 128:         "RID" => Some("RID"),
 129:         "COL" => Some("COL"),
 130:         "INV" => Some("INV"),
 131:         "SCR" => Some("SCR"),
 132:         _ => None,
 133:     }
 134: }
 135: 
 136: /// Lexical classification only; does not establish artifact validity,
 137: /// emission permission, filesystem state, or governed authority.
 138: #[derive(Debug, PartialEq, Eq)]
 139: pub enum ArtifactClassDisposition<'a> {
 140:     RegisteredEmittable(&'a str),
 141:     RegisteredNotEmitted(&'a str),
 142:     Unallocated(&'a str),
 143:     MalformedReserved,
 144:     OutsideReservedNamespace,
 145: }
 146: 
 147: /// Classifies a governed class token, not a complete artifact filename.
 148: pub fn classify_artifact_class_token(filename: &str) -> ArtifactClassDisposition<'_> {
 149:     if !has_reserved_namespace_prefix(filename) {
 150:         return ArtifactClassDisposition::OutsideReservedNamespace;
 151:     }
 152: 
 153:     let rest = &filename["__DS__".len()..];
 154: 
 155:     let Some((class, suffix)) = rest.split_once("__") else {
 156:         return ArtifactClassDisposition::MalformedReserved;
 157:     };
 158: 
 159:     if class.len() != 3 || !class.bytes().all(|byte| byte.is_ascii_uppercase()) || suffix.is_empty()
 160:     {
 161:         return ArtifactClassDisposition::MalformedReserved;
 162:     }
 163: 
 164:     match class {
 165:         "DGN" | "RCV" | "BRD" | "LCK" => ArtifactClassDisposition::RegisteredNotEmitted(class),
 166:         _ if reserved_artifact_class(filename).is_some() => {
 167:             ArtifactClassDisposition::RegisteredEmittable(class)
 168:         }
 169:         _ => ArtifactClassDisposition::Unallocated(class),
 170:     }
 171: }
 172: 
 173: /// Checks the lexical envelope of an ordinary immutable artifact filename.
 174: ///
 175: /// This validates ordinary Gregorian UTC calendar/clock fields, but not
 176: /// artifact-specific extension, registered class, governed contents,
 177: /// provenance, or authority.
 178: pub fn is_canonical_immutable_artifact_filename(filename: &str) -> bool {
 179:     let Some(rest) = filename.strip_prefix("__DS__") else {
 180:         return false;
 181:     };
 182: 
 183:     let Some((class, rest)) = rest.split_once("__") else {
 184:         return false;
 185:     };
 186: 
 187:     if class.len() != 3 || !class.bytes().all(|byte| byte.is_ascii_uppercase()) {
 188:         return false;
 189:     }
 190: 
 191:     let Some((utc, rest)) = rest.split_once("__") else {
 192:         return false;
 193:     };
 194: 
 195:     let timestamp = utc.as_bytes();
 196: 
 197:     if timestamp.len() != 19
 198:         || timestamp[8] != b'T'
 199:         || timestamp[18] != b'Z'
 200:         || !timestamp
 201:             .iter()
 202:             .enumerate()
 203:             .all(|(i, byte)| matches!(i, 8 | 18) || byte.is_ascii_digit())
 204:     {
 205:         return false;
 206:     }
 207: 
 208:     if !utc_calendar_fields_valid(timestamp) {
 209:         return false;
 210:     }
 211: 
 212:     let Some((uuid, extension)) = rest.split_once('.') else {
 213:         return false;
 214:     };
 215: 
 250:     let year = digit(0) * 1000 + digit(1) * 100 + digit(2) * 10 + digit(3);
 251:     let month = two(4);
 252:     let day = two(6);
 253:     let hour = two(9);
 254:     let minute = two(11);
 255:     let second = two(13);
 256: 
 257:     if year == 0 || !(1..=12).contains(&month) || hour > 23 || minute > 59 || second > 59 {
 258:         return false;
 259:     }
 260: 
 261:     let leap_year = year % 4 == 0 && (year % 100 != 0 || year % 400 == 0);
 262: 
 263:     let days_in_month = match month {
 264:         4 | 6 | 9 | 11 => 30,
 265:         2 if leap_year => 29,
 266:         2 => 28,
 267:         _ => 31,
 268:     };
 269: 
 270:     (1..=days_in_month).contains(&day)
 271: }
 272: 
 273: /// Lexical class and serialization tokens from a canonical artifact filename.
 274: ///
 275: /// Extraction does not register a class, approve a serialization format,
 276: /// validate artifact contents, or establish governed authority.
 277: #[derive(Debug, Clone, Copy, PartialEq, Eq)]
 278: pub struct ArtifactFilenameTokens<'a> {
 279:     pub semantic_class: &'a str,
 280:     pub serialization_extension: &'a str,
 281: }
 282: 
 283: /// Extracts independent class and serialization tokens after envelope validation.
 284: pub fn extract_artifact_filename_tokens(filename: &str) -> Option<ArtifactFilenameTokens<'_>> {
 285:     if !is_canonical_immutable_artifact_filename(filename) {
 286:         return None;
 287:     }
 288: 
 289:     let rest = filename.strip_prefix("__DS__")?;
 290:     let (semantic_class, rest) = rest.split_once("__")?;
 291:     let (_, rest) = rest.split_once("__")?;
 292:     let (_, serialization_extension) = rest.split_once('.')?;
 293: 
 294:     Some(ArtifactFilenameTokens {
 295:         semantic_class,
 296:         serialization_extension,
 297:     })
 298: }
 299: 
 300: /// Constructs a canonical immutable filename candidate from exact input tokens.
 301: ///
 302: /// This function performs no case folding, trimming, Unicode normalization,
 303: /// UUID allocation, filesystem operation, or artifact publication.
 304: /// A successful candidate does not establish governed artifact authority.
 305: pub fn build_immutable_artifact_filename_candidate(
 306:     semantic_class: &str,
 307:     utc: &str,
 308:     uuid: &str,
 309:     serialization_extension: &str,
 310: ) -> Option<String> {
 311:     let filename = format!("__DS__{semantic_class}__{utc}__{uuid}.{serialization_extension}");
 312: 
 313:     if is_canonical_immutable_artifact_filename(&filename) {
 314:         Some(filename)
 315:     } else {
 316:         None
 317:     }
 318: }
 319: 
 320: /// Recognizes a canonical governed CVT CSV SOURCE filename candidate.
 321: ///
 322: /// Lexical recognition only. This does not verify physical existence,
 323: /// publication, provenance, encoding, CSV validity, or SOURCE authority.
 324: pub fn is_governed_cvt_source_filename_candidate(filename: &str) -> bool {
 325:     matches!(
 326:         extract_artifact_filename_tokens(filename),
 327:         Some(tokens)
 328:             if tokens.semantic_class == "CVT"
 329:                 && tokens.serialization_extension == "csv"
 330:     )
 331: }
 332: 
 333: /// Derives the SCR staging filename candidate corresponding to a canonical CVT.
 334: ///
 335: /// Lexical construction only. This grants no filesystem, conversion,
 336: /// publication, or SOURCE authority.
 337: pub fn build_scr_candidate_filename_for_cvt(filename: &str) -> Option<String> {
 338:     if !is_governed_cvt_source_filename_candidate(filename) {
 339:         return None;
 340:     }
 341: 
 342:     Some(filename.replacen("__DS__CVT__", "__DS__SCR__", 1))
 343: }
 344: 
 345: /// Recognizes a canonical SCR staging filename candidate.
 346: ///
 347: /// Lexical recognition only. This does not verify file existence,
 348: /// contents, intended final class, publication, or authority.
 349: pub fn is_canonical_scr_filename_candidate(filename: &str) -> bool {
 350:     if filename
 351:         .chars()
 352:         .any(|ch| ch.is_whitespace() || ch == '/' || ch == '\\')
 353:     {
 354:         return false;
 355:     }
 356: 
 357:     matches!(
 358:         extract_artifact_filename_tokens(filename),
 359:         Some(tokens) if tokens.semantic_class == "SCR"
 360:     )
 361: }
 362: 
 363: /// Derives a canonical RCP final filename candidate from an SCR staging name.
 364: ///
 365: /// The intended final class must be supplied explicitly. This function only
 366: /// constructs a lexical candidate; it does not validate contents, perform
 367: /// filesystem operations, promote staged files, publish, or grant authority.
 368: pub fn build_final_filename_candidate_for_scr(
 369:     scr_filename: &str,
 370:     intended_final_class: &str,
 371: ) -> Option<String> {
 372:     if intended_final_class != "RCP" || !is_canonical_scr_filename_candidate(scr_filename) {
 373:         return None;
 374:     }
 375: 
 376:     let tokens = extract_artifact_filename_tokens(scr_filename)?;
 377: 
 378:     if tokens.serialization_extension != "txt" {
 379:         return None;
 380:     }
 381: 
 382:     Some(scr_filename.replacen("__DS__SCR__", "__DS__RCP__", 1))
 383: }

CP014 LOCAL EVIDENCE CUSTODY GATE
Day: 067
Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Original TXT files: 32
ZIP archives: 32
Original TXT files locally excluded: 32
Untracked CP014 files not excluded: 0
Local exclude backup SHA256: FDB7DC7BE17051C3C5067CDF2B8FDF2CA3A8DAF2B5E91F34C6CE1FF3A94C5F6A
Current local exclude SHA256: E044F9021C67AD13651DF3C8E8146E96C6A4D4D664B4B76A27D3FE3D05027B57
Git attributes worktree diff exit: 0
Git attributes index diff exit: 0
Rust staged objects byte-identical: 2/2
Staged whitespace check exit: 0
Git status exit: 0
Staging unchanged: True
Custody gate PASS: True
Git commit executed: NO
Git banking authorized: NO

--- RUST STAGED OBJECTS ---
56916f9a9d682e9ec6b0d95c60dc27013dd30b78 | src/lib.rs
f5d6552ebdb25a15a689f345b248613084963bbb | tests/CP014_rcp_filename_candidate_identity.rs

A  Evidence/CP-014/ZIP/CP014_Evidence_Preflight.txt.zip
A  Evidence/CP-014/ZIP/CP014_Full_Regression_Record.txt.zip
A  Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip
A  Evidence/CP-014/ZIP/CP014_GREEN_Run_Record.txt.zip
A  Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip
A  Evidence/CP-014/ZIP/CP014_Git_Attributes_Amendment_Record.txt.zip
A  Evidence/CP-014/ZIP/CP014_Git_Attributes_Diff_Recovery.txt.zip
A  Evidence/CP-014/ZIP/CP014_Git_Attributes_Recovery_Record.txt.zip
A  Evidence/CP-014/ZIP/CP014_Git_Text_Policy_Inspection.txt.zip
A  Evidence/CP-014/ZIP/CP014_Hash_Inventory.txt.zip
A  Evidence/CP-014/ZIP/CP014_Hash_Inventory_Verification.txt.zip
A  Evidence/CP-014/ZIP/CP014_Implementation_Record.txt.zip
A  Evidence/CP-014/ZIP/CP014_Implementation_Surface.txt.zip
A  Evidence/CP-014/ZIP/CP014_RED_Run_Record.txt.zip
A  Evidence/CP-014/ZIP/CP014_RED_Test_Output.txt.zip
A  Evidence/CP-014/ZIP/CP014_Rustfmt_Check_Output.txt.zip
A  Evidence/CP-014/ZIP/CP014_Rustfmt_Check_Record.txt.zip
A  Evidence/CP-014/ZIP/CP014_Rustfmt_Output.txt.zip
A  Evidence/CP-014/ZIP/CP014_Scope_Inspection.txt.zip
A  Evidence/CP-014/ZIP/CP014_Scope_Lock.txt.zip
A  Evidence/CP-014/ZIP/CP014_Source_Diff.txt.zip
A  Evidence/CP-014/ZIP/CP014_Staged_Path_List.txt.zip
A  Evidence/CP-014/ZIP/CP014_Staged_Whitespace_Check.txt.zip
A  Evidence/CP-014/ZIP/CP014_Staging_Command_Output.txt.zip
A  Evidence/CP-014/ZIP/CP014_Staging_Record.txt.zip
A  Evidence/CP-014/ZIP/CP014_Test_Format_Record.txt.zip
A  Evidence/CP-014/ZIP/CP014_WASM_Build_Output.txt.zip
A  Evidence/CP-014/ZIP/CP014_WASM_Build_Record.txt.zip
A  Evidence/CP-014/ZIP/CP014_ZIP_Batch_Verification.txt.zip
A  Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Git_Add_Output.txt.zip
A  Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Git_Record.txt.zip
A  Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Verification.txt.zip
M  src/lib.rs
A  tests/CP014_rcp_filename_candidate_identity.rs

CP014 RED EXECUTION RECORD
Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Command: cargo +1.97.1 test --test CP014_rcp_filename_candidate_identity -- --nocapture
Exit code: 101
Expected unresolved-symbol diagnostic: True
Formatted test SHA256: 27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
Original Cargo output: CP014_RED_Test_Output.txt
Product source modified: NO

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
error[E0432]: unresolved import `data_sculptor_core::is_canonical_rcp_filename_candidate`
 --> tests\CP014_rcp_filename_candidate_identity.rs:7:45
  |
7 |     build_final_filename_candidate_for_scr, is_canonical_rcp_filename_candidate,
  |                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `is_canonical_rcp_filename_candidate` in the root
  |
help: a similar name exists in the module
  |
7 -     build_final_filename_candidate_for_scr, is_canonical_rcp_filename_candidate,
7 +     build_final_filename_candidate_for_scr, is_canonical_scr_filename_candidate,
  |

For more information about this error, try `rustc --explain E0432`.
error: could not compile `data_sculptor_core` (test "CP014_rcp_filename_candidate_identity") due to 1 previous error

CP014 RUSTFMT CHECK RECORD
Day: 067
Command: rustfmt +1.97.1 --check --edition 2021 src\lib.rs tests\CP014_rcp_filename_candidate_identity.rs
Exit code: 0
Source unchanged: True
Source SHA256: B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236
Test SHA256: 27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
Raw output SHA256: E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
Raw output: CP014_Rustfmt_Check_Output.txt
Full regression executed: NO
Git banking authorized: NO

=== CP014 READ-ONLY SCOPE INSPECTION ===

--- Git HEAD ---
005a38ef5e876847c4c08901c18da9c18565fd6b
Git exit code: 0

--- Branch ---
master
Git exit code: 0

--- Previous checkpoint test ---
// CP013 RED tests - Day 066
// Frozen anchors: W002-STOR-023.1 and W002-STOR-023.
// Explicit SCR-to-RCP lexical candidate derivation only.
// No promotion, filesystem activity, publication, or authority.

use data_sculptor_core::build_final_filename_candidate_for_scr;

const SCR: &str = "__DS__SCR__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.txt";
const RCP: &str = "__DS__RCP__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.txt";

#[test]
fn derives_rcp_candidate_only_with_explicit_class() {
    assert_eq!(
        build_final_filename_candidate_for_scr(SCR, "RCP"),
        Some(RCP.to_string())
    );
}

#[test]
fn preserves_distinct_timestamp_and_uuid_tokens() {
    let scr = "__DS__SCR__20261013T173300000Z__123e4567-e89b-42d3-a456-426614174000.txt";
    let rcp = "__DS__RCP__20261013T173300000Z__123e4567-e89b-42d3-a456-426614174000.txt";

    assert_eq!(
        build_final_filename_candidate_for_scr(scr, "RCP"),
        Some(rcp.to_string())
    );
    assert_ne!(rcp, RCP);
}

#[test]
fn refuses_non_scr_and_noncanonical_source_classes() {
    for filename in [
        SCR.replacen("__DS__SCR__", "__DS__CVT__", 1),
        SCR.replacen("__DS__SCR__", "__DS__RCP__", 1),
        SCR.replacen("__DS__SCR__", "__DS__scr__", 1),
        "ordinary.txt".to_string(),
    ] {
        assert_eq!(
            build_final_filename_candidate_for_scr(&filename, "RCP"),
            None
        );
    }
}

#[test]
fn refuses_unsupported_or_incorrectly_cased_final_classes() {
    for class in ["", "rcp", "Rcp", "CVT", "CAT", "SCR", "MAP", "RCP ", " RCP"] {
        assert_eq!(
            build_final_filename_candidate_for_scr(SCR, class),
            None,
            "{class:?}"
        );
    }
}

#[test]
fn refuses_wrong_or_ambiguous_serialization_extensions() {
    for filename in [
        SCR.replace(".txt", ".csv"),
        SCR.replace(".txt", ".TXT"),
        SCR.replace(".txt", ".tXt"),
        SCR.replace(".txt", ".txt.gz"),
        SCR.replace(".txt", "."),
        SCR.replace(".txt", ""),
    ] {
        assert_eq!(
            build_final_filename_candidate_for_scr(&filename, "RCP"),
            None
        );
    }
}

#[test]
fn refuses_invalid_identity_paths_and_whitespace() {
    for filename in [
        SCR.replace("20261014", "20260230"),
        SCR.replace("T011203456Z", "T251203456Z"),
        SCR.replace("-41d4-", "-51d4-"),
        SCR.replace("-a716-", "-1716-"),
        format!("folder/{SCR}"),
        format!("folder\\{SCR}"),
        format!(" {SCR}"),
        format!("{SCR} "),
        format!("{SCR}\n"),
    ] {
        assert_eq!(
            build_final_filename_candidate_for_scr(&filename, "RCP"),
            None
        );
    }
}

--- Rust source file inventory ---
C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs

--- SCR / RCP source references ---
C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:8: /// Screens an exact filename for analyst-owned CSV SOURCE candidate form.
C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:124: "RCP" => Some("RCP"),
C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:131: "SCR" => Some("SCR"),
C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:333: /// Derives the SCR staging filename candidate corresponding to a canonical CVT.
C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:337: pub fn build_scr_candidate_filename_for_cvt(filename: &str) -> Option<String> {
C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:342: Some(filename.replacen("__DS__CVT__", "__DS__SCR__", 1))
C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:345: /// Recognizes a canonical SCR staging filename candidate.
C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:349: pub fn is_canonical_scr_filename_candidate(filename: &str) -> bool {
C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:359: Some(tokens) if tokens.semantic_class == "SCR"
C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:363: /// Derives a canonical RCP final filename candidate from an SCR staging name.
C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:368: pub fn build_final_filename_candidate_for_scr(
C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:369: scr_filename: &str,
C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:372: if intended_final_class != "RCP" || !is_canonical_scr_filename_candidate(scr_filename) {
C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:376: let tokens = extract_artifact_filename_tokens(scr_filename)?;
C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:382: Some(scr_filename.replacen("__DS__SCR__", "__DS__RCP__", 1))

CP014 SCOPE LOCK - DAY 067
State: TEST AUTHORED / RED NOT YET RUN
Baseline Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Branch: master

FROZEN CONTRACT
Revision BM H-31
W002-RCP-002
W002-STOR-023
W002-STOR-023.1

IMPLEMENTATION TARGET
is_canonical_rcp_filename_candidate(filename: &str) -> bool

BOUNDARY
Exact lexical RCP .txt identity only.
No artifact-content validation.
No filesystem interaction.
No SCR promotion.
No publication or authority.
No frozen requirement changes.

TEST SOURCE
tests/CP014_rcp_filename_candidate_identity.rs

INITIAL TEST SHA256
B5F51F876EBD13E734D99087E4F46D6E580EC653DA4FF9243BFEA880C58F75E5

NEXT GATES
Format newly authored test.
Record final formatted test hash.
Capture expected RED missing-symbol failure.
Make minimal approved implementation.
Preserve all evidence and exit codes.

diff --git a/src/lib.rs b/src/lib.rs
index b2df81b..56916f9 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -381,3 +381,23 @@ pub fn build_final_filename_candidate_for_scr(
 
     Some(scr_filename.replacen("__DS__SCR__", "__DS__RCP__", 1))
 }
+
+/// Recognizes a canonical RCP Receipt filename candidate.
+///
+/// Lexical recognition only. This does not verify Receipt contents,
+/// filesystem state, staging promotion, publication, or authority.
+pub fn is_canonical_rcp_filename_candidate(filename: &str) -> bool {
+    if filename
+        .chars()
+        .any(|ch| ch.is_whitespace() || ch == '/' || ch == '\\')
+    {
+        return false;
+    }
+
+    matches!(
+        extract_artifact_filename_tokens(filename),
+        Some(tokens)
+            if tokens.semantic_class == "RCP"
+                && tokens.serialization_extension == "txt"
+    )
+}

.gitattributes
Evidence/CP-014/CP014_Evidence_Preflight.txt
Evidence/CP-014/CP014_Full_Regression_Record.txt
Evidence/CP-014/CP014_Full_Regression_Test_Output.txt
Evidence/CP-014/CP014_GREEN_Run_Record.txt
Evidence/CP-014/CP014_GREEN_Test_Output.txt
Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt
Evidence/CP-014/CP014_Git_Attributes_Diff_Recovery.txt
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt
Evidence/CP-014/CP014_Hash_Inventory.txt
Evidence/CP-014/CP014_Hash_Inventory_Verification.txt
Evidence/CP-014/CP014_Implementation_Record.txt
Evidence/CP-014/CP014_Implementation_Surface.txt
Evidence/CP-014/CP014_RED_Run_Record.txt
Evidence/CP-014/CP014_RED_Test_Output.txt
Evidence/CP-014/CP014_Rustfmt_Check_Output.txt
Evidence/CP-014/CP014_Rustfmt_Check_Record.txt
Evidence/CP-014/CP014_Rustfmt_Output.txt
Evidence/CP-014/CP014_Scope_Inspection.txt
Evidence/CP-014/CP014_Scope_Lock.txt
Evidence/CP-014/CP014_Source_Diff.txt
Evidence/CP-014/CP014_Test_Format_Record.txt
Evidence/CP-014/CP014_WASM_Build_Output.txt
Evidence/CP-014/CP014_WASM_Build_Record.txt
src/lib.rs
tests/CP014_rcp_filename_candidate_identity.rs

Evidence/CP-014/CP014_Evidence_Preflight.txt:1: trailing whitespace.
+CP014 EVIDENCE INTEGRITY PREFLIGHT
Evidence/CP-014/CP014_Evidence_Preflight.txt:2: trailing whitespace.
+Day: 067
Evidence/CP-014/CP014_Evidence_Preflight.txt:3: trailing whitespace.
+Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Evidence/CP-014/CP014_Evidence_Preflight.txt:4: trailing whitespace.
+Source SHA256: B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236
Evidence/CP-014/CP014_Evidence_Preflight.txt:5: trailing whitespace.
+Test SHA256: 27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
Evidence/CP-014/CP014_Evidence_Preflight.txt:6: trailing whitespace.
+WASM log SHA256: E0553F624C36C32260BF6850045362AB18920896E111C2E94ABAA6D022BD583A
Evidence/CP-014/CP014_Evidence_Preflight.txt:7: trailing whitespace.
+Pre-existing evidence TXT files: 17
Evidence/CP-014/CP014_Evidence_Preflight.txt:8: trailing whitespace.
+Original evidence modified: NO
Evidence/CP-014/CP014_Evidence_Preflight.txt:9: trailing whitespace.
+Git staging performed: NO
Evidence/CP-014/CP014_Evidence_Preflight.txt:10: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:11: trailing whitespace.
+--- ORIGINAL EVIDENCE INVENTORY ---
Evidence/CP-014/CP014_Evidence_Preflight.txt:12: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:13: trailing whitespace.
+File: CP014_Full_Regression_Record.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:14: trailing whitespace.
+Bytes: 611
Evidence/CP-014/CP014_Evidence_Preflight.txt:15: trailing whitespace.
+SHA256: 051556BE29E0C06BA560C37BBE8F3BE478D82DE40FF830897657B976F31E0626
Evidence/CP-014/CP014_Evidence_Preflight.txt:16: trailing whitespace.
+UTF8 BOM: False
Evidence/CP-014/CP014_Evidence_Preflight.txt:17: trailing whitespace.
+LF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:18: trailing whitespace.
+CRLF endings: 15
Evidence/CP-014/CP014_Evidence_Preflight.txt:19: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:20: trailing whitespace.
+Lines with trailing SP/TAB: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:21: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:22: trailing whitespace.
+File: CP014_Full_Regression_Test_Output.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:23: trailing whitespace.
+Bytes: 7164
Evidence/CP-014/CP014_Evidence_Preflight.txt:24: trailing whitespace.
+SHA256: 9669D0A3040CCCC2B6F7768FC4E84BC1D71FD69D20CD261B20CABBB0938A83DF
Evidence/CP-014/CP014_Evidence_Preflight.txt:25: trailing whitespace.
+UTF8 BOM: False
Evidence/CP-014/CP014_Evidence_Preflight.txt:26: trailing whitespace.
+LF endings: 156
Evidence/CP-014/CP014_Evidence_Preflight.txt:27: trailing whitespace.
+CRLF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:28: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:29: trailing whitespace.
+Lines with trailing SP/TAB: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:30: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:31: trailing whitespace.
+File: CP014_GREEN_Run_Record.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:32: trailing whitespace.
+Bytes: 588
Evidence/CP-014/CP014_Evidence_Preflight.txt:33: trailing whitespace.
+SHA256: C28E4993E66A1E790B24E78E59953711A7EDFB34D5F9D2812C294C427591533E
Evidence/CP-014/CP014_Evidence_Preflight.txt:34: trailing whitespace.
+UTF8 BOM: False
Evidence/CP-014/CP014_Evidence_Preflight.txt:35: trailing whitespace.
+LF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:36: trailing whitespace.
+CRLF endings: 12
Evidence/CP-014/CP014_Evidence_Preflight.txt:37: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:38: trailing whitespace.
+Lines with trailing SP/TAB: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:39: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:40: trailing whitespace.
+File: CP014_GREEN_Test_Output.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:41: trailing whitespace.
+Bytes: 707
Evidence/CP-014/CP014_Evidence_Preflight.txt:42: trailing whitespace.
+SHA256: 6C79FD4AA16190F4F9851334435FB601014D61D3A59B40F3A3E18151FAA550B8
Evidence/CP-014/CP014_Evidence_Preflight.txt:43: trailing whitespace.
+UTF8 BOM: False
Evidence/CP-014/CP014_Evidence_Preflight.txt:44: trailing whitespace.
+LF endings: 14
Evidence/CP-014/CP014_Evidence_Preflight.txt:45: trailing whitespace.
+CRLF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:46: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:47: trailing whitespace.
+Lines with trailing SP/TAB: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:48: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:49: trailing whitespace.
+File: CP014_Implementation_Record.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:50: trailing whitespace.
+Bytes: 529
Evidence/CP-014/CP014_Evidence_Preflight.txt:51: trailing whitespace.
+SHA256: 1B23A6A15EE66CA820BC15C2D935099DE510CB30BEBD32E2B8422C5C5773B184
Evidence/CP-014/CP014_Evidence_Preflight.txt:52: trailing whitespace.
+UTF8 BOM: False
Evidence/CP-014/CP014_Evidence_Preflight.txt:53: trailing whitespace.
+LF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:54: trailing whitespace.
+CRLF endings: 13
Evidence/CP-014/CP014_Evidence_Preflight.txt:55: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:56: trailing whitespace.
+Lines with trailing SP/TAB: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:57: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:58: trailing whitespace.
+File: CP014_Implementation_Surface.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:59: trailing whitespace.
+Bytes: 10143
Evidence/CP-014/CP014_Evidence_Preflight.txt:60: trailing whitespace.
+SHA256: 5573FDE0F50394BFE63ADECA872B6C84CCAAE5643F54426A29E816DD15F5264F
Evidence/CP-014/CP014_Evidence_Preflight.txt:61: trailing whitespace.
+UTF8 BOM: True
Evidence/CP-014/CP014_Evidence_Preflight.txt:62: trailing whitespace.
+LF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:63: trailing whitespace.
+CRLF endings: 262
Evidence/CP-014/CP014_Evidence_Preflight.txt:64: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:65: trailing whitespace.
+Lines with trailing SP/TAB: 39
Evidence/CP-014/CP014_Evidence_Preflight.txt:66: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:67: trailing whitespace.
+File: CP014_RED_Run_Record.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:68: trailing whitespace.
+Bytes: 398
Evidence/CP-014/CP014_Evidence_Preflight.txt:69: trailing whitespace.
+SHA256: 816E574D51AD7B9CA99E96A637993D78F3E63175694A3DD03492AE9CDD80B111
Evidence/CP-014/CP014_Evidence_Preflight.txt:70: trailing whitespace.
+UTF8 BOM: False
Evidence/CP-014/CP014_Evidence_Preflight.txt:71: trailing whitespace.
+LF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:72: trailing whitespace.
+CRLF endings: 8
Evidence/CP-014/CP014_Evidence_Preflight.txt:73: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:74: trailing whitespace.
+Lines with trailing SP/TAB: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:75: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:76: trailing whitespace.
+File: CP014_RED_Test_Output.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:77: trailing whitespace.
+Bytes: 870
Evidence/CP-014/CP014_Evidence_Preflight.txt:78: trailing whitespace.
+SHA256: 8E3F94F9567BDA62E90DE377FD76346CC98514AC106EE941152D84FAA7227AF0
Evidence/CP-014/CP014_Evidence_Preflight.txt:79: trailing whitespace.
+UTF8 BOM: False
Evidence/CP-014/CP014_Evidence_Preflight.txt:80: trailing whitespace.
+LF endings: 15
Evidence/CP-014/CP014_Evidence_Preflight.txt:81: trailing whitespace.
+CRLF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:82: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:83: trailing whitespace.
+Lines with trailing SP/TAB: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:84: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:85: trailing whitespace.
+File: CP014_Rustfmt_Check_Output.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:86: trailing whitespace.
+Bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:87: trailing whitespace.
+SHA256: E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
Evidence/CP-014/CP014_Evidence_Preflight.txt:88: trailing whitespace.
+UTF8 BOM: False
Evidence/CP-014/CP014_Evidence_Preflight.txt:89: trailing whitespace.
+LF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:90: trailing whitespace.
+CRLF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:91: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:92: trailing whitespace.
+Lines with trailing SP/TAB: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:93: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:94: trailing whitespace.
+File: CP014_Rustfmt_Check_Record.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:95: trailing whitespace.
+Bytes: 530
Evidence/CP-014/CP014_Evidence_Preflight.txt:96: trailing whitespace.
+SHA256: A3A58BCD382E8DAEC99008BC70299403DA9A884AD45B0A26557EAA334203FBEB
Evidence/CP-014/CP014_Evidence_Preflight.txt:97: trailing whitespace.
+UTF8 BOM: False
Evidence/CP-014/CP014_Evidence_Preflight.txt:98: trailing whitespace.
+LF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:99: trailing whitespace.
+CRLF endings: 11
Evidence/CP-014/CP014_Evidence_Preflight.txt:100: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:101: trailing whitespace.
+Lines with trailing SP/TAB: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:102: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:103: trailing whitespace.
+File: CP014_Rustfmt_Output.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:104: trailing whitespace.
+Bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:105: trailing whitespace.
+SHA256: E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
Evidence/CP-014/CP014_Evidence_Preflight.txt:106: trailing whitespace.
+UTF8 BOM: False
Evidence/CP-014/CP014_Evidence_Preflight.txt:107: trailing whitespace.
+LF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:108: trailing whitespace.
+CRLF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:109: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:110: trailing whitespace.
+Lines with trailing SP/TAB: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:111: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:112: trailing whitespace.
+File: CP014_Scope_Inspection.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:113: trailing whitespace.
+Bytes: 4967
Evidence/CP-014/CP014_Evidence_Preflight.txt:114: trailing whitespace.
+SHA256: 8760615464B2477CD85CCE2A74302BDB6421CEBA0726920BD6C9FDCC915D3C02
Evidence/CP-014/CP014_Evidence_Preflight.txt:115: trailing whitespace.
+UTF8 BOM: True
Evidence/CP-014/CP014_Evidence_Preflight.txt:116: trailing whitespace.
+LF endings: 5
Evidence/CP-014/CP014_Evidence_Preflight.txt:117: trailing whitespace.
+CRLF endings: 118
Evidence/CP-014/CP014_Evidence_Preflight.txt:118: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:119: trailing whitespace.
+Lines with trailing SP/TAB: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:120: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:121: trailing whitespace.
+File: CP014_Scope_Lock.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:122: trailing whitespace.
+Bytes: 826
Evidence/CP-014/CP014_Evidence_Preflight.txt:123: trailing whitespace.
+SHA256: FD47D4837EE8152D95DCD5C3EFA3746D5404D0B40576CEDFE50597CF887ABB9D
Evidence/CP-014/CP014_Evidence_Preflight.txt:124: trailing whitespace.
+UTF8 BOM: False
Evidence/CP-014/CP014_Evidence_Preflight.txt:125: trailing whitespace.
+LF endings: 33
Evidence/CP-014/CP014_Evidence_Preflight.txt:126: trailing whitespace.
+CRLF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:127: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:128: trailing whitespace.
+Lines with trailing SP/TAB: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:129: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:130: trailing whitespace.
+File: CP014_Source_Diff.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:131: trailing whitespace.
+Bytes: 894
Evidence/CP-014/CP014_Evidence_Preflight.txt:132: trailing whitespace.
+SHA256: 74FD689FA0528F12A4BCA6BFD66CB226EBE77E85170D0E0CD775ED81F10B5E61
Evidence/CP-014/CP014_Evidence_Preflight.txt:133: trailing whitespace.
+UTF8 BOM: True
Evidence/CP-014/CP014_Evidence_Preflight.txt:134: trailing whitespace.
+LF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:135: trailing whitespace.
+CRLF endings: 28
Evidence/CP-014/CP014_Evidence_Preflight.txt:136: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:137: trailing whitespace.
+Lines with trailing SP/TAB: 1
Evidence/CP-014/CP014_Evidence_Preflight.txt:138: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:139: trailing whitespace.
+File: CP014_Test_Format_Record.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:140: trailing whitespace.
+Bytes: 392
Evidence/CP-014/CP014_Evidence_Preflight.txt:141: trailing whitespace.
+SHA256: 350F43CAA2E14C4F51E700288D5EF7FFECC09D14480E8D0A102BCF14D59DCD58
Evidence/CP-014/CP014_Evidence_Preflight.txt:142: trailing whitespace.
+UTF8 BOM: False
Evidence/CP-014/CP014_Evidence_Preflight.txt:143: trailing whitespace.
+LF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:144: trailing whitespace.
+CRLF endings: 8
Evidence/CP-014/CP014_Evidence_Preflight.txt:145: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:146: trailing whitespace.
+Lines with trailing SP/TAB: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:147: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:148: trailing whitespace.
+File: CP014_WASM_Build_Output.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:149: trailing whitespace.
+Bytes: 159
Evidence/CP-014/CP014_Evidence_Preflight.txt:150: trailing whitespace.
+SHA256: E0553F624C36C32260BF6850045362AB18920896E111C2E94ABAA6D022BD583A
Evidence/CP-014/CP014_Evidence_Preflight.txt:151: trailing whitespace.
+UTF8 BOM: False
Evidence/CP-014/CP014_Evidence_Preflight.txt:152: trailing whitespace.
+LF endings: 2
Evidence/CP-014/CP014_Evidence_Preflight.txt:153: trailing whitespace.
+CRLF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:154: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:155: trailing whitespace.
+Lines with trailing SP/TAB: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:156: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:157: trailing whitespace.
+File: CP014_WASM_Build_Record.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:158: trailing whitespace.
+Bytes: 562
Evidence/CP-014/CP014_Evidence_Preflight.txt:159: trailing whitespace.
+SHA256: 8CCD83F6E36C54CECF3DFA34A17A1EDD1E82BBB7BFAA03078F13D4AC807DCD4C
Evidence/CP-014/CP014_Evidence_Preflight.txt:160: trailing whitespace.
+UTF8 BOM: False
Evidence/CP-014/CP014_Evidence_Preflight.txt:161: trailing whitespace.
+LF endings: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:162: trailing whitespace.
+CRLF endings: 12
Evidence/CP-014/CP014_Evidence_Preflight.txt:163: trailing whitespace.
+Other CR bytes: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:164: trailing whitespace.
+Lines with trailing SP/TAB: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:165: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:166: trailing whitespace.
+--- GIT WORKING TREE STATUS ---
Evidence/CP-014/CP014_Evidence_Preflight.txt:167: trailing whitespace.
+Exit code: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:168: trailing whitespace.
+ M src/lib.rs
Evidence/CP-014/CP014_Evidence_Preflight.txt:169: trailing whitespace.
+?? Evidence/CP-014/CP014_Full_Regression_Record.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:170: trailing whitespace.
+?? Evidence/CP-014/CP014_Full_Regression_Test_Output.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:171: trailing whitespace.
+?? Evidence/CP-014/CP014_GREEN_Run_Record.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:172: trailing whitespace.
+?? Evidence/CP-014/CP014_GREEN_Test_Output.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:173: trailing whitespace.
+?? Evidence/CP-014/CP014_Implementation_Record.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:174: trailing whitespace.
+?? Evidence/CP-014/CP014_Implementation_Surface.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:175: trailing whitespace.
+?? Evidence/CP-014/CP014_RED_Run_Record.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:176: trailing whitespace.
+?? Evidence/CP-014/CP014_RED_Test_Output.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:177: trailing whitespace.
+?? Evidence/CP-014/CP014_Rustfmt_Check_Output.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:178: trailing whitespace.
+?? Evidence/CP-014/CP014_Rustfmt_Check_Record.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:179: trailing whitespace.
+?? Evidence/CP-014/CP014_Rustfmt_Output.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:180: trailing whitespace.
+?? Evidence/CP-014/CP014_Scope_Inspection.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:181: trailing whitespace.
+?? Evidence/CP-014/CP014_Scope_Lock.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:182: trailing whitespace.
+?? Evidence/CP-014/CP014_Source_Diff.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:183: trailing whitespace.
+?? Evidence/CP-014/CP014_Test_Format_Record.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:184: trailing whitespace.
+?? Evidence/CP-014/CP014_WASM_Build_Output.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:185: trailing whitespace.
+?? Evidence/CP-014/CP014_WASM_Build_Record.txt
Evidence/CP-014/CP014_Evidence_Preflight.txt:186: trailing whitespace.
+?? tests/CP014_rcp_filename_candidate_identity.rs
Evidence/CP-014/CP014_Evidence_Preflight.txt:187: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:188: trailing whitespace.
+--- UNSTAGED TRACKED DIFF WHITESPACE CHECK ---
Evidence/CP-014/CP014_Evidence_Preflight.txt:189: trailing whitespace.
+Exit code: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:190: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:191: trailing whitespace.
+--- EVIDENCE GIT ATTRIBUTES ---
Evidence/CP-014/CP014_Evidence_Preflight.txt:192: trailing whitespace.
+Exit code: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:193: trailing whitespace.
+Evidence/CP-014/CP014_Full_Regression_Record.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:194: trailing whitespace.
+Evidence/CP-014/CP014_Full_Regression_Test_Output.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:195: trailing whitespace.
+Evidence/CP-014/CP014_GREEN_Run_Record.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:196: trailing whitespace.
+Evidence/CP-014/CP014_GREEN_Test_Output.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:197: trailing whitespace.
+Evidence/CP-014/CP014_Implementation_Record.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:198: trailing whitespace.
+Evidence/CP-014/CP014_Implementation_Surface.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:199: trailing whitespace.
+Evidence/CP-014/CP014_RED_Run_Record.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:200: trailing whitespace.
+Evidence/CP-014/CP014_RED_Test_Output.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:201: trailing whitespace.
+Evidence/CP-014/CP014_Rustfmt_Check_Output.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:202: trailing whitespace.
+Evidence/CP-014/CP014_Rustfmt_Check_Record.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:203: trailing whitespace.
+Evidence/CP-014/CP014_Rustfmt_Output.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:204: trailing whitespace.
+Evidence/CP-014/CP014_Scope_Inspection.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:205: trailing whitespace.
+Evidence/CP-014/CP014_Scope_Lock.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:206: trailing whitespace.
+Evidence/CP-014/CP014_Source_Diff.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:207: trailing whitespace.
+Evidence/CP-014/CP014_Test_Format_Record.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:208: trailing whitespace.
+Evidence/CP-014/CP014_WASM_Build_Output.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:209: trailing whitespace.
+Evidence/CP-014/CP014_WASM_Build_Record.txt: text: auto
Evidence/CP-014/CP014_Evidence_Preflight.txt:210: trailing whitespace.
+
Evidence/CP-014/CP014_Evidence_Preflight.txt:211: trailing whitespace.
+--- GATE SUMMARY ---
Evidence/CP-014/CP014_Evidence_Preflight.txt:212: trailing whitespace.
+Git status exit: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:213: trailing whitespace.
+Tracked diff whitespace exit: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:214: trailing whitespace.
+Git attributes exit: 0
Evidence/CP-014/CP014_Evidence_Preflight.txt:215: trailing whitespace.
+Evidence whitespace findings require classification.
Evidence/CP-014/CP014_Evidence_Preflight.txt:216: trailing whitespace.
+Untracked files require staged review later.
Evidence/CP-014/CP014_Evidence_Preflight.txt:217: trailing whitespace.
+NO automatic normalization or repair authorized.
Evidence/CP-014/CP014_Full_Regression_Record.txt:1: trailing whitespace.
+CP014 FULL NATIVE REGRESSION RECORD
Evidence/CP-014/CP014_Full_Regression_Record.txt:2: trailing whitespace.
+Day: 067
Evidence/CP-014/CP014_Full_Regression_Record.txt:3: trailing whitespace.
+Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Evidence/CP-014/CP014_Full_Regression_Record.txt:4: trailing whitespace.
+Command: cargo +1.97.1 test
Evidence/CP-014/CP014_Full_Regression_Record.txt:5: trailing whitespace.
+Exit code: 0
Evidence/CP-014/CP014_Full_Regression_Record.txt:6: trailing whitespace.
+Test suites reported: 15
Evidence/CP-014/CP014_Full_Regression_Record.txt:7: trailing whitespace.
+Passing tests counted: 64
Evidence/CP-014/CP014_Full_Regression_Record.txt:8: trailing whitespace.
+Expected passing tests: 64
Evidence/CP-014/CP014_Full_Regression_Record.txt:9: trailing whitespace.
+Expected count met: True
Evidence/CP-014/CP014_Full_Regression_Record.txt:10: trailing whitespace.
+Source SHA256: B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236
Evidence/CP-014/CP014_Full_Regression_Record.txt:11: trailing whitespace.
+Test SHA256: 27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
Evidence/CP-014/CP014_Full_Regression_Record.txt:12: trailing whitespace.
+Raw Cargo log SHA256: 9669D0A3040CCCC2B6F7768FC4E84BC1D71FD69D20CD261B20CABBB0938A83DF
Evidence/CP-014/CP014_Full_Regression_Record.txt:13: trailing whitespace.
+Raw output: CP014_Full_Regression_Test_Output.txt
Evidence/CP-014/CP014_Full_Regression_Record.txt:14: trailing whitespace.
+Canonical WASM build executed: NO
Evidence/CP-014/CP014_Full_Regression_Record.txt:15: trailing whitespace.
+Git banking authorized: NO
Evidence/CP-014/CP014_Full_Regression_Test_Output.txt:156: new blank line at EOF.
Evidence/CP-014/CP014_GREEN_Run_Record.txt:1: trailing whitespace.
+CP014 TARGETED GREEN EXECUTION RECORD
Evidence/CP-014/CP014_GREEN_Run_Record.txt:2: trailing whitespace.
+Day: 067
Evidence/CP-014/CP014_GREEN_Run_Record.txt:3: trailing whitespace.
+Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Evidence/CP-014/CP014_GREEN_Run_Record.txt:4: trailing whitespace.
+Command: cargo +1.97.1 test --test CP014_rcp_filename_candidate_identity -- --nocapture
Evidence/CP-014/CP014_GREEN_Run_Record.txt:5: trailing whitespace.
+Exit code: 0
Evidence/CP-014/CP014_GREEN_Run_Record.txt:6: trailing whitespace.
+Six passed, zero failed: True
Evidence/CP-014/CP014_GREEN_Run_Record.txt:7: trailing whitespace.
+Source SHA256: B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236
Evidence/CP-014/CP014_GREEN_Run_Record.txt:8: trailing whitespace.
+Test SHA256: 27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
Evidence/CP-014/CP014_GREEN_Run_Record.txt:9: trailing whitespace.
+Raw Cargo log SHA256: 6C79FD4AA16190F4F9851334435FB601014D61D3A59B40F3A3E18151FAA550B8
Evidence/CP-014/CP014_GREEN_Run_Record.txt:10: trailing whitespace.
+Raw Cargo output: CP014_GREEN_Test_Output.txt
Evidence/CP-014/CP014_GREEN_Run_Record.txt:11: trailing whitespace.
+Full regression executed: NO
Evidence/CP-014/CP014_GREEN_Run_Record.txt:12: trailing whitespace.
+Git banking authorized: NO
Evidence/CP-014/CP014_GREEN_Test_Output.txt:14: new blank line at EOF.
Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt:1: trailing whitespace.
+CP014 GIT ATTRIBUTES AMENDMENT
Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt:2: trailing whitespace.
+Day: 067
Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt:3: trailing whitespace.
+Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt:4: trailing whitespace.
+Rule: Evidence/CP-014/*.txt -text
Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt:5: trailing whitespace.
+Purpose: Preserve original CP014 TXT evidence bytes.
Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt:6: trailing whitespace.
+Attributes SHA256 before: 978CF143947177C92114C50A5C68F24B6E9818597AA64788406884E116EC5A0B
Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt:7: trailing whitespace.
+Attributes SHA256 after: 3C48424F40BE15C07FE03C7AB0731DBF13CDE0FF2729275FD7D4E6B9B825604B
Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt:8: trailing whitespace.
+Existing TXT files checked: 19
Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt:9: trailing whitespace.
+Original TXT bytes unchanged: True
Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt:10: trailing whitespace.
+All original TXT paths protected: True
Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt:11: trailing whitespace.
+Git check-attr exit: 0
Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt:12: trailing whitespace.
+Git diff exit: -1
Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt:13: trailing whitespace.
+Diff evidence: CP014_Git_Attributes_Diff.txt
Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt:14: trailing whitespace.
+Git staging performed: NO
Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt:15: trailing whitespace.
+Git banking authorized: NO
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt:1: trailing whitespace.
+CP014 GIT ATTRIBUTES RECOVERY RECORD
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt:2: trailing whitespace.
+Day: 067
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt:3: trailing whitespace.
+Purpose: Recover diff capture after PowerShell NativeCommandError.
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt:4: trailing whitespace.
+Original failed amendment record preserved: YES
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt:5: trailing whitespace.
+Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt:6: trailing whitespace.
+Attributes SHA256: 3C48424F40BE15C07FE03C7AB0731DBF13CDE0FF2729275FD7D4E6B9B825604B
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt:7: trailing whitespace.
+Recovery command: git --no-pager diff -- .gitattributes
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt:8: trailing whitespace.
+Git exit code: 0
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt:9: trailing whitespace.
+LF/CRLF warning captured: True
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt:10: trailing whitespace.
+Expected preservation rule found: True
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt:11: trailing whitespace.
+Only expected diff addition: True
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt:12: trailing whitespace.
+Raw recovery output SHA256: FC54CF9CF95253519DFF561FC1DEF8D457BB815343FD4C75D81ABE9895DA366E
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt:13: trailing whitespace.
+Raw output: CP014_Git_Attributes_Diff_Recovery.txt
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt:14: trailing whitespace.
+Original evidence modified: NO
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt:15: trailing whitespace.
+Git staging performed: NO
Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt:16: trailing whitespace.
+Git banking authorized: NO
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:1: trailing whitespace.
+CP014 GIT TEXT POLICY INSPECTION
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:2: trailing whitespace.
+Day 067 - READ ONLY
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:3: trailing whitespace.
+
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:4: trailing whitespace.
+--- EXISTING .gitattributes ---
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:5: trailing whitespace.
+* text=auto
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:6: trailing whitespace.
+*.rs text eol=lf
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:7: trailing whitespace.
+*.toml text eol=lf
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:8: trailing whitespace.
+Cargo.lock text eol=lf
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:9: trailing whitespace.
+*.sh text eol=lf
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:10: trailing whitespace.
+*.ps1 text eol=crlf
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:11: trailing whitespace.
+
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:12: trailing whitespace.
+--- EFFECTIVE FILE ATTRIBUTES ---
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:13: trailing whitespace.
+Evidence/CP-014/CP014_Implementation_Surface.txt: text: auto
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:14: trailing whitespace.
+Evidence/CP-014/CP014_Source_Diff.txt: text: auto
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:15: trailing whitespace.
+Evidence/CP-014/CP014_RED_Test_Output.txt: text: auto
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:16: trailing whitespace.
+Evidence/CP-014/CP014_GREEN_Run_Record.txt: text: auto
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:17: trailing whitespace.
+Exit code: 0
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:18: trailing whitespace.
+
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:19: trailing whitespace.
+--- GIT CONFIGURATION ---
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:20: trailing whitespace.
+core.autocrlf : file:C:/Program Files/Git/etc/gitconfig	true
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:21: trailing whitespace.
+Exit code: 0
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:22: trailing whitespace.
+core.safecrlf : (unset)
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:23: trailing whitespace.
+core.whitespace : (unset)
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:24: trailing whitespace.
+
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:25: trailing whitespace.
+--- CURRENT GIT STATUS ---
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:26: trailing whitespace.
+## master
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:27: trailing whitespace.
+ M src/lib.rs
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:28: trailing whitespace.
+?? Evidence/CP-014/
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:29: trailing whitespace.
+?? tests/CP014_rcp_filename_candidate_identity.rs
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:30: trailing whitespace.
+Exit code: 0
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:31: trailing whitespace.
+
Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt:32: trailing whitespace.
+No staging or normalization performed.
Evidence/CP-014/CP014_Hash_Inventory.txt:1: trailing whitespace.
+# CP014 PRE-STAGING SHA256 INVENTORY
Evidence/CP-014/CP014_Hash_Inventory.txt:2: trailing whitespace.
+# Day 067
Evidence/CP-014/CP014_Hash_Inventory.txt:3: trailing whitespace.
+# Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Evidence/CP-014/CP014_Hash_Inventory.txt:4: trailing whitespace.
+# Entries: 25
Evidence/CP-014/CP014_Hash_Inventory.txt:5: trailing whitespace.
+# Original evidence preserved without modification
Evidence/CP-014/CP014_Hash_Inventory.txt:6: trailing whitespace.
+# Format: SHA256<TAB>REPOSITORY_RELATIVE_PATH
Evidence/CP-014/CP014_Hash_Inventory.txt:7: trailing whitespace.
+3C48424F40BE15C07FE03C7AB0731DBF13CDE0FF2729275FD7D4E6B9B825604B	.gitattributes
Evidence/CP-014/CP014_Hash_Inventory.txt:8: trailing whitespace.
+B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236	src/lib.rs
Evidence/CP-014/CP014_Hash_Inventory.txt:9: trailing whitespace.
+27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4	tests/CP014_rcp_filename_candidate_identity.rs
Evidence/CP-014/CP014_Hash_Inventory.txt:10: trailing whitespace.
+62748820D199957C385FF28BDA6B6EDF4B82E80ED90C05E9A1F57CC9BE4ABC5A	Evidence/CP-014/CP014_Evidence_Preflight.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:11: trailing whitespace.
+051556BE29E0C06BA560C37BBE8F3BE478D82DE40FF830897657B976F31E0626	Evidence/CP-014/CP014_Full_Regression_Record.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:12: trailing whitespace.
+9669D0A3040CCCC2B6F7768FC4E84BC1D71FD69D20CD261B20CABBB0938A83DF	Evidence/CP-014/CP014_Full_Regression_Test_Output.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:13: trailing whitespace.
+7C9D6A199D4F5F912B10E63FC94F72254D3EECEF7787E4D49155B8FBE677F3D5	Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:14: trailing whitespace.
+FC54CF9CF95253519DFF561FC1DEF8D457BB815343FD4C75D81ABE9895DA366E	Evidence/CP-014/CP014_Git_Attributes_Diff_Recovery.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:15: trailing whitespace.
+212CA232CE05AEDE0FBD932AADF48000E6A3C8A0F56EFEF0A2C6EC891B597238	Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:16: trailing whitespace.
+3E30775424DEC65711D193156EE720DCEE4B1CB20ED096AEE9C67DF7042B09FE	Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:17: trailing whitespace.
+C28E4993E66A1E790B24E78E59953711A7EDFB34D5F9D2812C294C427591533E	Evidence/CP-014/CP014_GREEN_Run_Record.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:18: trailing whitespace.
+6C79FD4AA16190F4F9851334435FB601014D61D3A59B40F3A3E18151FAA550B8	Evidence/CP-014/CP014_GREEN_Test_Output.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:19: trailing whitespace.
+1B23A6A15EE66CA820BC15C2D935099DE510CB30BEBD32E2B8422C5C5773B184	Evidence/CP-014/CP014_Implementation_Record.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:20: trailing whitespace.
+5573FDE0F50394BFE63ADECA872B6C84CCAAE5643F54426A29E816DD15F5264F	Evidence/CP-014/CP014_Implementation_Surface.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:21: trailing whitespace.
+816E574D51AD7B9CA99E96A637993D78F3E63175694A3DD03492AE9CDD80B111	Evidence/CP-014/CP014_RED_Run_Record.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:22: trailing whitespace.
+8E3F94F9567BDA62E90DE377FD76346CC98514AC106EE941152D84FAA7227AF0	Evidence/CP-014/CP014_RED_Test_Output.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:23: trailing whitespace.
+E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855	Evidence/CP-014/CP014_Rustfmt_Check_Output.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:24: trailing whitespace.
+A3A58BCD382E8DAEC99008BC70299403DA9A884AD45B0A26557EAA334203FBEB	Evidence/CP-014/CP014_Rustfmt_Check_Record.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:25: trailing whitespace.
+E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855	Evidence/CP-014/CP014_Rustfmt_Output.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:26: trailing whitespace.
+8760615464B2477CD85CCE2A74302BDB6421CEBA0726920BD6C9FDCC915D3C02	Evidence/CP-014/CP014_Scope_Inspection.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:27: trailing whitespace.
+FD47D4837EE8152D95DCD5C3EFA3746D5404D0B40576CEDFE50597CF887ABB9D	Evidence/CP-014/CP014_Scope_Lock.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:28: trailing whitespace.
+74FD689FA0528F12A4BCA6BFD66CB226EBE77E85170D0E0CD775ED81F10B5E61	Evidence/CP-014/CP014_Source_Diff.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:29: trailing whitespace.
+350F43CAA2E14C4F51E700288D5EF7FFECC09D14480E8D0A102BCF14D59DCD58	Evidence/CP-014/CP014_Test_Format_Record.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:30: trailing whitespace.
+E0553F624C36C32260BF6850045362AB18920896E111C2E94ABAA6D022BD583A	Evidence/CP-014/CP014_WASM_Build_Output.txt
Evidence/CP-014/CP014_Hash_Inventory.txt:31: trailing whitespace.
+8CCD83F6E36C54CECF3DFA34A17A1EDD1E82BBB7BFAA03078F13D4AC807DCD4C	Evidence/CP-014/CP014_WASM_Build_Record.txt
Evidence/CP-014/CP014_Hash_Inventory_Verification.txt:1: trailing whitespace.
+CP014 SHA256 INVENTORY VERIFICATION
Evidence/CP-014/CP014_Hash_Inventory_Verification.txt:2: trailing whitespace.
+Day: 067
Evidence/CP-014/CP014_Hash_Inventory_Verification.txt:3: trailing whitespace.
+Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Evidence/CP-014/CP014_Hash_Inventory_Verification.txt:4: trailing whitespace.
+Inventory: CP014_Hash_Inventory.txt
Evidence/CP-014/CP014_Hash_Inventory_Verification.txt:5: trailing whitespace.
+Inventory SHA256: 6ED47A9151696174BF9E8193B8B5399E662270ED10436FED29C1F1D732389472
Evidence/CP-014/CP014_Hash_Inventory_Verification.txt:6: trailing whitespace.
+Files inventoried: 25
Evidence/CP-014/CP014_Hash_Inventory_Verification.txt:7: trailing whitespace.
+Files verified: 25
Evidence/CP-014/CP014_Hash_Inventory_Verification.txt:8: trailing whitespace.
+Mismatches: 0
Evidence/CP-014/CP014_Hash_Inventory_Verification.txt:9: trailing whitespace.
+All hashes verified: True
Evidence/CP-014/CP014_Hash_Inventory_Verification.txt:10: trailing whitespace.
+Inventory and verification excluded from snapshot.
Evidence/CP-014/CP014_Hash_Inventory_Verification.txt:11: trailing whitespace.
+Git staging performed: NO
Evidence/CP-014/CP014_Hash_Inventory_Verification.txt:12: trailing whitespace.
+Git banking authorized: NO
Evidence/CP-014/CP014_Implementation_Record.txt:1: trailing whitespace.
+CP014 MINIMAL GREEN IMPLEMENTATION RECORD
Evidence/CP-014/CP014_Implementation_Record.txt:2: trailing whitespace.
+Day: 067
Evidence/CP-014/CP014_Implementation_Record.txt:3: trailing whitespace.
+Baseline Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Evidence/CP-014/CP014_Implementation_Record.txt:4: trailing whitespace.
+Branch: master
Evidence/CP-014/CP014_Implementation_Record.txt:5: trailing whitespace.
+Source: src/lib.rs
Evidence/CP-014/CP014_Implementation_Record.txt:6: trailing whitespace.
+Before SHA256: 99741F26933AA8EEDBF1E75031F5012CA01918D06E1A3D013CA1703A49842649
Evidence/CP-014/CP014_Implementation_Record.txt:7: trailing whitespace.
+After SHA256: B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236
Evidence/CP-014/CP014_Implementation_Record.txt:8: trailing whitespace.
+Test SHA256: 27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
Evidence/CP-014/CP014_Implementation_Record.txt:9: trailing whitespace.
+Bytes appended: 603
Evidence/CP-014/CP014_Implementation_Record.txt:10: trailing whitespace.
+Git diff exit code: 0
Evidence/CP-014/CP014_Implementation_Record.txt:11: trailing whitespace.
+Diff evidence: CP014_Source_Diff.txt
Evidence/CP-014/CP014_Implementation_Record.txt:12: trailing whitespace.
+Targeted GREEN executed: NO
Evidence/CP-014/CP014_Implementation_Record.txt:13: trailing whitespace.
+Git banking authorized: NO
Evidence/CP-014/CP014_Implementation_Surface.txt:1: trailing whitespace.
+=== CP014 IMPLEMENTATION SURFACE ===
Evidence/CP-014/CP014_Implementation_Surface.txt:2: trailing whitespace.
+READ-ONLY SOURCE INSPECTION
Evidence/CP-014/CP014_Implementation_Surface.txt:3: trailing whitespace.
+  90:         }
Evidence/CP-014/CP014_Implementation_Surface.txt:4: trailing whitespace.
+  91: 
Evidence/CP-014/CP014_Implementation_Surface.txt:5: trailing whitespace.
+  92:         matched_kind = Some(entry.kind);
Evidence/CP-014/CP014_Implementation_Surface.txt:6: trailing whitespace.
+  93:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:7: trailing whitespace.
+  94: 
Evidence/CP-014/CP014_Implementation_Surface.txt:8: trailing whitespace.
+  95:     match matched_kind {
Evidence/CP-014/CP014_Implementation_Surface.txt:9: trailing whitespace.
+  96:         None => RootSnapshotMatch::NotFound,
Evidence/CP-014/CP014_Implementation_Surface.txt:10: trailing whitespace.
+  97:         Some(RootSnapshotEntryKind::RegularFile) => RootSnapshotMatch::SingleReportedRegularFile,
Evidence/CP-014/CP014_Implementation_Surface.txt:11: trailing whitespace.
+  98:         Some(RootSnapshotEntryKind::Directory | RootSnapshotEntryKind::Other) => {
Evidence/CP-014/CP014_Implementation_Surface.txt:12: trailing whitespace.
+  99:             RootSnapshotMatch::NonRegularEntry
Evidence/CP-014/CP014_Implementation_Surface.txt:13: trailing whitespace.
+ 100:         }
Evidence/CP-014/CP014_Implementation_Surface.txt:14: trailing whitespace.
+ 101:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:15: trailing whitespace.
+ 102: }
Evidence/CP-014/CP014_Implementation_Surface.txt:16: trailing whitespace.
+ 103: 
Evidence/CP-014/CP014_Implementation_Surface.txt:17: trailing whitespace.
+ 104: /// Recognizes a governed Data Sculptor artifact class from a filename.
Evidence/CP-014/CP014_Implementation_Surface.txt:18: trailing whitespace.
+ 105: ///
Evidence/CP-014/CP014_Implementation_Surface.txt:19: trailing whitespace.
+ 106: /// Lexical recognition only: this does not validate file contents,
Evidence/CP-014/CP014_Implementation_Surface.txt:20: trailing whitespace.
+ 107: /// artifact authority, publication eligibility, or filesystem state.
Evidence/CP-014/CP014_Implementation_Surface.txt:21: trailing whitespace.
+ 108: pub fn reserved_artifact_class(filename: &str) -> Option<&'static str> {
Evidence/CP-014/CP014_Implementation_Surface.txt:22: trailing whitespace.
+ 109:     let rest = filename.strip_prefix("__DS__")?;
Evidence/CP-014/CP014_Implementation_Surface.txt:23: trailing whitespace.
+ 110:     let (class, suffix) = rest.split_once("__")?;
Evidence/CP-014/CP014_Implementation_Surface.txt:24: trailing whitespace.
+ 111: 
Evidence/CP-014/CP014_Implementation_Surface.txt:25: trailing whitespace.
+ 112:     if suffix.is_empty() {
Evidence/CP-014/CP014_Implementation_Surface.txt:26: trailing whitespace.
+ 113:         return None;
Evidence/CP-014/CP014_Implementation_Surface.txt:27: trailing whitespace.
+ 114:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:28: trailing whitespace.
+ 115: 
Evidence/CP-014/CP014_Implementation_Surface.txt:29: trailing whitespace.
+ 116:     match class {
Evidence/CP-014/CP014_Implementation_Surface.txt:30: trailing whitespace.
+ 117:         "WKO" => Some("WKO"),
Evidence/CP-014/CP014_Implementation_Surface.txt:31: trailing whitespace.
+ 118:         "MAP" => Some("MAP"),
Evidence/CP-014/CP014_Implementation_Surface.txt:32: trailing whitespace.
+ 119:         "CAT" => Some("CAT"),
Evidence/CP-014/CP014_Implementation_Surface.txt:33: trailing whitespace.
+ 120:         "DGN" => Some("DGN"),
Evidence/CP-014/CP014_Implementation_Surface.txt:34: trailing whitespace.
+ 121:         "RCV" => Some("RCV"),
Evidence/CP-014/CP014_Implementation_Surface.txt:35: trailing whitespace.
+ 122:         "BRD" => Some("BRD"),
Evidence/CP-014/CP014_Implementation_Surface.txt:36: trailing whitespace.
+ 123:         "LCK" => Some("LCK"),
Evidence/CP-014/CP014_Implementation_Surface.txt:37: trailing whitespace.
+ 124:         "RCP" => Some("RCP"),
Evidence/CP-014/CP014_Implementation_Surface.txt:38: trailing whitespace.
+ 125:         "HLP" => Some("HLP"),
Evidence/CP-014/CP014_Implementation_Surface.txt:39: trailing whitespace.
+ 126:         "CER" => Some("CER"),
Evidence/CP-014/CP014_Implementation_Surface.txt:40: trailing whitespace.
+ 127:         "CVT" => Some("CVT"),
Evidence/CP-014/CP014_Implementation_Surface.txt:41: trailing whitespace.
+ 128:         "RID" => Some("RID"),
Evidence/CP-014/CP014_Implementation_Surface.txt:42: trailing whitespace.
+ 129:         "COL" => Some("COL"),
Evidence/CP-014/CP014_Implementation_Surface.txt:43: trailing whitespace.
+ 130:         "INV" => Some("INV"),
Evidence/CP-014/CP014_Implementation_Surface.txt:44: trailing whitespace.
+ 131:         "SCR" => Some("SCR"),
Evidence/CP-014/CP014_Implementation_Surface.txt:45: trailing whitespace.
+ 132:         _ => None,
Evidence/CP-014/CP014_Implementation_Surface.txt:46: trailing whitespace.
+ 133:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:47: trailing whitespace.
+ 134: }
Evidence/CP-014/CP014_Implementation_Surface.txt:48: trailing whitespace.
+ 135: 
Evidence/CP-014/CP014_Implementation_Surface.txt:49: trailing whitespace.
+ 136: /// Lexical classification only; does not establish artifact validity,
Evidence/CP-014/CP014_Implementation_Surface.txt:50: trailing whitespace.
+ 137: /// emission permission, filesystem state, or governed authority.
Evidence/CP-014/CP014_Implementation_Surface.txt:51: trailing whitespace.
+ 138: #[derive(Debug, PartialEq, Eq)]
Evidence/CP-014/CP014_Implementation_Surface.txt:52: trailing whitespace.
+ 139: pub enum ArtifactClassDisposition<'a> {
Evidence/CP-014/CP014_Implementation_Surface.txt:53: trailing whitespace.
+ 140:     RegisteredEmittable(&'a str),
Evidence/CP-014/CP014_Implementation_Surface.txt:54: trailing whitespace.
+ 141:     RegisteredNotEmitted(&'a str),
Evidence/CP-014/CP014_Implementation_Surface.txt:55: trailing whitespace.
+ 142:     Unallocated(&'a str),
Evidence/CP-014/CP014_Implementation_Surface.txt:56: trailing whitespace.
+ 143:     MalformedReserved,
Evidence/CP-014/CP014_Implementation_Surface.txt:57: trailing whitespace.
+ 144:     OutsideReservedNamespace,
Evidence/CP-014/CP014_Implementation_Surface.txt:58: trailing whitespace.
+ 145: }
Evidence/CP-014/CP014_Implementation_Surface.txt:59: trailing whitespace.
+ 146: 
Evidence/CP-014/CP014_Implementation_Surface.txt:60: trailing whitespace.
+ 147: /// Classifies a governed class token, not a complete artifact filename.
Evidence/CP-014/CP014_Implementation_Surface.txt:61: trailing whitespace.
+ 148: pub fn classify_artifact_class_token(filename: &str) -> ArtifactClassDisposition<'_> {
Evidence/CP-014/CP014_Implementation_Surface.txt:62: trailing whitespace.
+ 149:     if !has_reserved_namespace_prefix(filename) {
Evidence/CP-014/CP014_Implementation_Surface.txt:63: trailing whitespace.
+ 150:         return ArtifactClassDisposition::OutsideReservedNamespace;
Evidence/CP-014/CP014_Implementation_Surface.txt:64: trailing whitespace.
+ 151:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:65: trailing whitespace.
+ 152: 
Evidence/CP-014/CP014_Implementation_Surface.txt:66: trailing whitespace.
+ 153:     let rest = &filename["__DS__".len()..];
Evidence/CP-014/CP014_Implementation_Surface.txt:67: trailing whitespace.
+ 154: 
Evidence/CP-014/CP014_Implementation_Surface.txt:68: trailing whitespace.
+ 155:     let Some((class, suffix)) = rest.split_once("__") else {
Evidence/CP-014/CP014_Implementation_Surface.txt:69: trailing whitespace.
+ 156:         return ArtifactClassDisposition::MalformedReserved;
Evidence/CP-014/CP014_Implementation_Surface.txt:70: trailing whitespace.
+ 157:     };
Evidence/CP-014/CP014_Implementation_Surface.txt:71: trailing whitespace.
+ 158: 
Evidence/CP-014/CP014_Implementation_Surface.txt:72: trailing whitespace.
+ 159:     if class.len() != 3 || !class.bytes().all(|byte| byte.is_ascii_uppercase()) || suffix.is_empty()
Evidence/CP-014/CP014_Implementation_Surface.txt:73: trailing whitespace.
+ 160:     {
Evidence/CP-014/CP014_Implementation_Surface.txt:74: trailing whitespace.
+ 161:         return ArtifactClassDisposition::MalformedReserved;
Evidence/CP-014/CP014_Implementation_Surface.txt:75: trailing whitespace.
+ 162:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:76: trailing whitespace.
+ 163: 
Evidence/CP-014/CP014_Implementation_Surface.txt:77: trailing whitespace.
+ 164:     match class {
Evidence/CP-014/CP014_Implementation_Surface.txt:78: trailing whitespace.
+ 165:         "DGN" | "RCV" | "BRD" | "LCK" => ArtifactClassDisposition::RegisteredNotEmitted(class),
Evidence/CP-014/CP014_Implementation_Surface.txt:79: trailing whitespace.
+ 166:         _ if reserved_artifact_class(filename).is_some() => {
Evidence/CP-014/CP014_Implementation_Surface.txt:80: trailing whitespace.
+ 167:             ArtifactClassDisposition::RegisteredEmittable(class)
Evidence/CP-014/CP014_Implementation_Surface.txt:81: trailing whitespace.
+ 168:         }
Evidence/CP-014/CP014_Implementation_Surface.txt:82: trailing whitespace.
+ 169:         _ => ArtifactClassDisposition::Unallocated(class),
Evidence/CP-014/CP014_Implementation_Surface.txt:83: trailing whitespace.
+ 170:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:84: trailing whitespace.
+ 171: }
Evidence/CP-014/CP014_Implementation_Surface.txt:85: trailing whitespace.
+ 172: 
Evidence/CP-014/CP014_Implementation_Surface.txt:86: trailing whitespace.
+ 173: /// Checks the lexical envelope of an ordinary immutable artifact filename.
Evidence/CP-014/CP014_Implementation_Surface.txt:87: trailing whitespace.
+ 174: ///
Evidence/CP-014/CP014_Implementation_Surface.txt:88: trailing whitespace.
+ 175: /// This validates ordinary Gregorian UTC calendar/clock fields, but not
Evidence/CP-014/CP014_Implementation_Surface.txt:89: trailing whitespace.
+ 176: /// artifact-specific extension, registered class, governed contents,
Evidence/CP-014/CP014_Implementation_Surface.txt:90: trailing whitespace.
+ 177: /// provenance, or authority.
Evidence/CP-014/CP014_Implementation_Surface.txt:91: trailing whitespace.
+ 178: pub fn is_canonical_immutable_artifact_filename(filename: &str) -> bool {
Evidence/CP-014/CP014_Implementation_Surface.txt:92: trailing whitespace.
+ 179:     let Some(rest) = filename.strip_prefix("__DS__") else {
Evidence/CP-014/CP014_Implementation_Surface.txt:93: trailing whitespace.
+ 180:         return false;
Evidence/CP-014/CP014_Implementation_Surface.txt:94: trailing whitespace.
+ 181:     };
Evidence/CP-014/CP014_Implementation_Surface.txt:95: trailing whitespace.
+ 182: 
Evidence/CP-014/CP014_Implementation_Surface.txt:96: trailing whitespace.
+ 183:     let Some((class, rest)) = rest.split_once("__") else {
Evidence/CP-014/CP014_Implementation_Surface.txt:97: trailing whitespace.
+ 184:         return false;
Evidence/CP-014/CP014_Implementation_Surface.txt:98: trailing whitespace.
+ 185:     };
Evidence/CP-014/CP014_Implementation_Surface.txt:99: trailing whitespace.
+ 186: 
Evidence/CP-014/CP014_Implementation_Surface.txt:100: trailing whitespace.
+ 187:     if class.len() != 3 || !class.bytes().all(|byte| byte.is_ascii_uppercase()) {
Evidence/CP-014/CP014_Implementation_Surface.txt:101: trailing whitespace.
+ 188:         return false;
Evidence/CP-014/CP014_Implementation_Surface.txt:102: trailing whitespace.
+ 189:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:103: trailing whitespace.
+ 190: 
Evidence/CP-014/CP014_Implementation_Surface.txt:104: trailing whitespace.
+ 191:     let Some((utc, rest)) = rest.split_once("__") else {
Evidence/CP-014/CP014_Implementation_Surface.txt:105: trailing whitespace.
+ 192:         return false;
Evidence/CP-014/CP014_Implementation_Surface.txt:106: trailing whitespace.
+ 193:     };
Evidence/CP-014/CP014_Implementation_Surface.txt:107: trailing whitespace.
+ 194: 
Evidence/CP-014/CP014_Implementation_Surface.txt:108: trailing whitespace.
+ 195:     let timestamp = utc.as_bytes();
Evidence/CP-014/CP014_Implementation_Surface.txt:109: trailing whitespace.
+ 196: 
Evidence/CP-014/CP014_Implementation_Surface.txt:110: trailing whitespace.
+ 197:     if timestamp.len() != 19
Evidence/CP-014/CP014_Implementation_Surface.txt:111: trailing whitespace.
+ 198:         || timestamp[8] != b'T'
Evidence/CP-014/CP014_Implementation_Surface.txt:112: trailing whitespace.
+ 199:         || timestamp[18] != b'Z'
Evidence/CP-014/CP014_Implementation_Surface.txt:113: trailing whitespace.
+ 200:         || !timestamp
Evidence/CP-014/CP014_Implementation_Surface.txt:114: trailing whitespace.
+ 201:             .iter()
Evidence/CP-014/CP014_Implementation_Surface.txt:115: trailing whitespace.
+ 202:             .enumerate()
Evidence/CP-014/CP014_Implementation_Surface.txt:116: trailing whitespace.
+ 203:             .all(|(i, byte)| matches!(i, 8 | 18) || byte.is_ascii_digit())
Evidence/CP-014/CP014_Implementation_Surface.txt:117: trailing whitespace.
+ 204:     {
Evidence/CP-014/CP014_Implementation_Surface.txt:118: trailing whitespace.
+ 205:         return false;
Evidence/CP-014/CP014_Implementation_Surface.txt:119: trailing whitespace.
+ 206:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:120: trailing whitespace.
+ 207: 
Evidence/CP-014/CP014_Implementation_Surface.txt:121: trailing whitespace.
+ 208:     if !utc_calendar_fields_valid(timestamp) {
Evidence/CP-014/CP014_Implementation_Surface.txt:122: trailing whitespace.
+ 209:         return false;
Evidence/CP-014/CP014_Implementation_Surface.txt:123: trailing whitespace.
+ 210:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:124: trailing whitespace.
+ 211: 
Evidence/CP-014/CP014_Implementation_Surface.txt:125: trailing whitespace.
+ 212:     let Some((uuid, extension)) = rest.split_once('.') else {
Evidence/CP-014/CP014_Implementation_Surface.txt:126: trailing whitespace.
+ 213:         return false;
Evidence/CP-014/CP014_Implementation_Surface.txt:127: trailing whitespace.
+ 214:     };
Evidence/CP-014/CP014_Implementation_Surface.txt:128: trailing whitespace.
+ 215: 
Evidence/CP-014/CP014_Implementation_Surface.txt:129: trailing whitespace.
+ 250:     let year = digit(0) * 1000 + digit(1) * 100 + digit(2) * 10 + digit(3);
Evidence/CP-014/CP014_Implementation_Surface.txt:130: trailing whitespace.
+ 251:     let month = two(4);
Evidence/CP-014/CP014_Implementation_Surface.txt:131: trailing whitespace.
+ 252:     let day = two(6);
Evidence/CP-014/CP014_Implementation_Surface.txt:132: trailing whitespace.
+ 253:     let hour = two(9);
Evidence/CP-014/CP014_Implementation_Surface.txt:133: trailing whitespace.
+ 254:     let minute = two(11);
Evidence/CP-014/CP014_Implementation_Surface.txt:134: trailing whitespace.
+ 255:     let second = two(13);
Evidence/CP-014/CP014_Implementation_Surface.txt:135: trailing whitespace.
+ 256: 
Evidence/CP-014/CP014_Implementation_Surface.txt:136: trailing whitespace.
+ 257:     if year == 0 || !(1..=12).contains(&month) || hour > 23 || minute > 59 || second > 59 {
Evidence/CP-014/CP014_Implementation_Surface.txt:137: trailing whitespace.
+ 258:         return false;
Evidence/CP-014/CP014_Implementation_Surface.txt:138: trailing whitespace.
+ 259:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:139: trailing whitespace.
+ 260: 
Evidence/CP-014/CP014_Implementation_Surface.txt:140: trailing whitespace.
+ 261:     let leap_year = year % 4 == 0 && (year % 100 != 0 || year % 400 == 0);
Evidence/CP-014/CP014_Implementation_Surface.txt:141: trailing whitespace.
+ 262: 
Evidence/CP-014/CP014_Implementation_Surface.txt:142: trailing whitespace.
+ 263:     let days_in_month = match month {
Evidence/CP-014/CP014_Implementation_Surface.txt:143: trailing whitespace.
+ 264:         4 | 6 | 9 | 11 => 30,
Evidence/CP-014/CP014_Implementation_Surface.txt:144: trailing whitespace.
+ 265:         2 if leap_year => 29,
Evidence/CP-014/CP014_Implementation_Surface.txt:145: trailing whitespace.
+ 266:         2 => 28,
Evidence/CP-014/CP014_Implementation_Surface.txt:146: trailing whitespace.
+ 267:         _ => 31,
Evidence/CP-014/CP014_Implementation_Surface.txt:147: trailing whitespace.
+ 268:     };
Evidence/CP-014/CP014_Implementation_Surface.txt:148: trailing whitespace.
+ 269: 
Evidence/CP-014/CP014_Implementation_Surface.txt:149: trailing whitespace.
+ 270:     (1..=days_in_month).contains(&day)
Evidence/CP-014/CP014_Implementation_Surface.txt:150: trailing whitespace.
+ 271: }
Evidence/CP-014/CP014_Implementation_Surface.txt:151: trailing whitespace.
+ 272: 
Evidence/CP-014/CP014_Implementation_Surface.txt:152: trailing whitespace.
+ 273: /// Lexical class and serialization tokens from a canonical artifact filename.
Evidence/CP-014/CP014_Implementation_Surface.txt:153: trailing whitespace.
+ 274: ///
Evidence/CP-014/CP014_Implementation_Surface.txt:154: trailing whitespace.
+ 275: /// Extraction does not register a class, approve a serialization format,
Evidence/CP-014/CP014_Implementation_Surface.txt:155: trailing whitespace.
+ 276: /// validate artifact contents, or establish governed authority.
Evidence/CP-014/CP014_Implementation_Surface.txt:156: trailing whitespace.
+ 277: #[derive(Debug, Clone, Copy, PartialEq, Eq)]
Evidence/CP-014/CP014_Implementation_Surface.txt:157: trailing whitespace.
+ 278: pub struct ArtifactFilenameTokens<'a> {
Evidence/CP-014/CP014_Implementation_Surface.txt:158: trailing whitespace.
+ 279:     pub semantic_class: &'a str,
Evidence/CP-014/CP014_Implementation_Surface.txt:159: trailing whitespace.
+ 280:     pub serialization_extension: &'a str,
Evidence/CP-014/CP014_Implementation_Surface.txt:160: trailing whitespace.
+ 281: }
Evidence/CP-014/CP014_Implementation_Surface.txt:161: trailing whitespace.
+ 282: 
Evidence/CP-014/CP014_Implementation_Surface.txt:162: trailing whitespace.
+ 283: /// Extracts independent class and serialization tokens after envelope validation.
Evidence/CP-014/CP014_Implementation_Surface.txt:163: trailing whitespace.
+ 284: pub fn extract_artifact_filename_tokens(filename: &str) -> Option<ArtifactFilenameTokens<'_>> {
Evidence/CP-014/CP014_Implementation_Surface.txt:164: trailing whitespace.
+ 285:     if !is_canonical_immutable_artifact_filename(filename) {
Evidence/CP-014/CP014_Implementation_Surface.txt:165: trailing whitespace.
+ 286:         return None;
Evidence/CP-014/CP014_Implementation_Surface.txt:166: trailing whitespace.
+ 287:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:167: trailing whitespace.
+ 288: 
Evidence/CP-014/CP014_Implementation_Surface.txt:168: trailing whitespace.
+ 289:     let rest = filename.strip_prefix("__DS__")?;
Evidence/CP-014/CP014_Implementation_Surface.txt:169: trailing whitespace.
+ 290:     let (semantic_class, rest) = rest.split_once("__")?;
Evidence/CP-014/CP014_Implementation_Surface.txt:170: trailing whitespace.
+ 291:     let (_, rest) = rest.split_once("__")?;
Evidence/CP-014/CP014_Implementation_Surface.txt:171: trailing whitespace.
+ 292:     let (_, serialization_extension) = rest.split_once('.')?;
Evidence/CP-014/CP014_Implementation_Surface.txt:172: trailing whitespace.
+ 293: 
Evidence/CP-014/CP014_Implementation_Surface.txt:173: trailing whitespace.
+ 294:     Some(ArtifactFilenameTokens {
Evidence/CP-014/CP014_Implementation_Surface.txt:174: trailing whitespace.
+ 295:         semantic_class,
Evidence/CP-014/CP014_Implementation_Surface.txt:175: trailing whitespace.
+ 296:         serialization_extension,
Evidence/CP-014/CP014_Implementation_Surface.txt:176: trailing whitespace.
+ 297:     })
Evidence/CP-014/CP014_Implementation_Surface.txt:177: trailing whitespace.
+ 298: }
Evidence/CP-014/CP014_Implementation_Surface.txt:178: trailing whitespace.
+ 299: 
Evidence/CP-014/CP014_Implementation_Surface.txt:179: trailing whitespace.
+ 300: /// Constructs a canonical immutable filename candidate from exact input tokens.
Evidence/CP-014/CP014_Implementation_Surface.txt:180: trailing whitespace.
+ 301: ///
Evidence/CP-014/CP014_Implementation_Surface.txt:181: trailing whitespace.
+ 302: /// This function performs no case folding, trimming, Unicode normalization,
Evidence/CP-014/CP014_Implementation_Surface.txt:182: trailing whitespace.
+ 303: /// UUID allocation, filesystem operation, or artifact publication.
Evidence/CP-014/CP014_Implementation_Surface.txt:183: trailing whitespace.
+ 304: /// A successful candidate does not establish governed artifact authority.
Evidence/CP-014/CP014_Implementation_Surface.txt:184: trailing whitespace.
+ 305: pub fn build_immutable_artifact_filename_candidate(
Evidence/CP-014/CP014_Implementation_Surface.txt:185: trailing whitespace.
+ 306:     semantic_class: &str,
Evidence/CP-014/CP014_Implementation_Surface.txt:186: trailing whitespace.
+ 307:     utc: &str,
Evidence/CP-014/CP014_Implementation_Surface.txt:187: trailing whitespace.
+ 308:     uuid: &str,
Evidence/CP-014/CP014_Implementation_Surface.txt:188: trailing whitespace.
+ 309:     serialization_extension: &str,
Evidence/CP-014/CP014_Implementation_Surface.txt:189: trailing whitespace.
+ 310: ) -> Option<String> {
Evidence/CP-014/CP014_Implementation_Surface.txt:190: trailing whitespace.
+ 311:     let filename = format!("__DS__{semantic_class}__{utc}__{uuid}.{serialization_extension}");
Evidence/CP-014/CP014_Implementation_Surface.txt:191: trailing whitespace.
+ 312: 
Evidence/CP-014/CP014_Implementation_Surface.txt:192: trailing whitespace.
+ 313:     if is_canonical_immutable_artifact_filename(&filename) {
Evidence/CP-014/CP014_Implementation_Surface.txt:193: trailing whitespace.
+ 314:         Some(filename)
Evidence/CP-014/CP014_Implementation_Surface.txt:194: trailing whitespace.
+ 315:     } else {
Evidence/CP-014/CP014_Implementation_Surface.txt:195: trailing whitespace.
+ 316:         None
Evidence/CP-014/CP014_Implementation_Surface.txt:196: trailing whitespace.
+ 317:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:197: trailing whitespace.
+ 318: }
Evidence/CP-014/CP014_Implementation_Surface.txt:198: trailing whitespace.
+ 319: 
Evidence/CP-014/CP014_Implementation_Surface.txt:199: trailing whitespace.
+ 320: /// Recognizes a canonical governed CVT CSV SOURCE filename candidate.
Evidence/CP-014/CP014_Implementation_Surface.txt:200: trailing whitespace.
+ 321: ///
Evidence/CP-014/CP014_Implementation_Surface.txt:201: trailing whitespace.
+ 322: /// Lexical recognition only. This does not verify physical existence,
Evidence/CP-014/CP014_Implementation_Surface.txt:202: trailing whitespace.
+ 323: /// publication, provenance, encoding, CSV validity, or SOURCE authority.
Evidence/CP-014/CP014_Implementation_Surface.txt:203: trailing whitespace.
+ 324: pub fn is_governed_cvt_source_filename_candidate(filename: &str) -> bool {
Evidence/CP-014/CP014_Implementation_Surface.txt:204: trailing whitespace.
+ 325:     matches!(
Evidence/CP-014/CP014_Implementation_Surface.txt:205: trailing whitespace.
+ 326:         extract_artifact_filename_tokens(filename),
Evidence/CP-014/CP014_Implementation_Surface.txt:206: trailing whitespace.
+ 327:         Some(tokens)
Evidence/CP-014/CP014_Implementation_Surface.txt:207: trailing whitespace.
+ 328:             if tokens.semantic_class == "CVT"
Evidence/CP-014/CP014_Implementation_Surface.txt:208: trailing whitespace.
+ 329:                 && tokens.serialization_extension == "csv"
Evidence/CP-014/CP014_Implementation_Surface.txt:209: trailing whitespace.
+ 330:     )
Evidence/CP-014/CP014_Implementation_Surface.txt:210: trailing whitespace.
+ 331: }
Evidence/CP-014/CP014_Implementation_Surface.txt:211: trailing whitespace.
+ 332: 
Evidence/CP-014/CP014_Implementation_Surface.txt:212: trailing whitespace.
+ 333: /// Derives the SCR staging filename candidate corresponding to a canonical CVT.
Evidence/CP-014/CP014_Implementation_Surface.txt:213: trailing whitespace.
+ 334: ///
Evidence/CP-014/CP014_Implementation_Surface.txt:214: trailing whitespace.
+ 335: /// Lexical construction only. This grants no filesystem, conversion,
Evidence/CP-014/CP014_Implementation_Surface.txt:215: trailing whitespace.
+ 336: /// publication, or SOURCE authority.
Evidence/CP-014/CP014_Implementation_Surface.txt:216: trailing whitespace.
+ 337: pub fn build_scr_candidate_filename_for_cvt(filename: &str) -> Option<String> {
Evidence/CP-014/CP014_Implementation_Surface.txt:217: trailing whitespace.
+ 338:     if !is_governed_cvt_source_filename_candidate(filename) {
Evidence/CP-014/CP014_Implementation_Surface.txt:218: trailing whitespace.
+ 339:         return None;
Evidence/CP-014/CP014_Implementation_Surface.txt:219: trailing whitespace.
+ 340:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:220: trailing whitespace.
+ 341: 
Evidence/CP-014/CP014_Implementation_Surface.txt:221: trailing whitespace.
+ 342:     Some(filename.replacen("__DS__CVT__", "__DS__SCR__", 1))
Evidence/CP-014/CP014_Implementation_Surface.txt:222: trailing whitespace.
+ 343: }
Evidence/CP-014/CP014_Implementation_Surface.txt:223: trailing whitespace.
+ 344: 
Evidence/CP-014/CP014_Implementation_Surface.txt:224: trailing whitespace.
+ 345: /// Recognizes a canonical SCR staging filename candidate.
Evidence/CP-014/CP014_Implementation_Surface.txt:225: trailing whitespace.
+ 346: ///
Evidence/CP-014/CP014_Implementation_Surface.txt:226: trailing whitespace.
+ 347: /// Lexical recognition only. This does not verify file existence,
Evidence/CP-014/CP014_Implementation_Surface.txt:227: trailing whitespace.
+ 348: /// contents, intended final class, publication, or authority.
Evidence/CP-014/CP014_Implementation_Surface.txt:228: trailing whitespace.
+ 349: pub fn is_canonical_scr_filename_candidate(filename: &str) -> bool {
Evidence/CP-014/CP014_Implementation_Surface.txt:229: trailing whitespace.
+ 350:     if filename
Evidence/CP-014/CP014_Implementation_Surface.txt:230: trailing whitespace.
+ 351:         .chars()
Evidence/CP-014/CP014_Implementation_Surface.txt:231: trailing whitespace.
+ 352:         .any(|ch| ch.is_whitespace() || ch == '/' || ch == '\\')
Evidence/CP-014/CP014_Implementation_Surface.txt:232: trailing whitespace.
+ 353:     {
Evidence/CP-014/CP014_Implementation_Surface.txt:233: trailing whitespace.
+ 354:         return false;
Evidence/CP-014/CP014_Implementation_Surface.txt:234: trailing whitespace.
+ 355:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:235: trailing whitespace.
+ 356: 
Evidence/CP-014/CP014_Implementation_Surface.txt:236: trailing whitespace.
+ 357:     matches!(
Evidence/CP-014/CP014_Implementation_Surface.txt:237: trailing whitespace.
+ 358:         extract_artifact_filename_tokens(filename),
Evidence/CP-014/CP014_Implementation_Surface.txt:238: trailing whitespace.
+ 359:         Some(tokens) if tokens.semantic_class == "SCR"
Evidence/CP-014/CP014_Implementation_Surface.txt:239: trailing whitespace.
+ 360:     )
Evidence/CP-014/CP014_Implementation_Surface.txt:240: trailing whitespace.
+ 361: }
Evidence/CP-014/CP014_Implementation_Surface.txt:241: trailing whitespace.
+ 362: 
Evidence/CP-014/CP014_Implementation_Surface.txt:242: trailing whitespace.
+ 363: /// Derives a canonical RCP final filename candidate from an SCR staging name.
Evidence/CP-014/CP014_Implementation_Surface.txt:243: trailing whitespace.
+ 364: ///
Evidence/CP-014/CP014_Implementation_Surface.txt:244: trailing whitespace.
+ 365: /// The intended final class must be supplied explicitly. This function only
Evidence/CP-014/CP014_Implementation_Surface.txt:245: trailing whitespace.
+ 366: /// constructs a lexical candidate; it does not validate contents, perform
Evidence/CP-014/CP014_Implementation_Surface.txt:246: trailing whitespace.
+ 367: /// filesystem operations, promote staged files, publish, or grant authority.
Evidence/CP-014/CP014_Implementation_Surface.txt:247: trailing whitespace.
+ 368: pub fn build_final_filename_candidate_for_scr(
Evidence/CP-014/CP014_Implementation_Surface.txt:248: trailing whitespace.
+ 369:     scr_filename: &str,
Evidence/CP-014/CP014_Implementation_Surface.txt:249: trailing whitespace.
+ 370:     intended_final_class: &str,
Evidence/CP-014/CP014_Implementation_Surface.txt:250: trailing whitespace.
+ 371: ) -> Option<String> {
Evidence/CP-014/CP014_Implementation_Surface.txt:251: trailing whitespace.
+ 372:     if intended_final_class != "RCP" || !is_canonical_scr_filename_candidate(scr_filename) {
Evidence/CP-014/CP014_Implementation_Surface.txt:252: trailing whitespace.
+ 373:         return None;
Evidence/CP-014/CP014_Implementation_Surface.txt:253: trailing whitespace.
+ 374:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:254: trailing whitespace.
+ 375: 
Evidence/CP-014/CP014_Implementation_Surface.txt:255: trailing whitespace.
+ 376:     let tokens = extract_artifact_filename_tokens(scr_filename)?;
Evidence/CP-014/CP014_Implementation_Surface.txt:256: trailing whitespace.
+ 377: 
Evidence/CP-014/CP014_Implementation_Surface.txt:257: trailing whitespace.
+ 378:     if tokens.serialization_extension != "txt" {
Evidence/CP-014/CP014_Implementation_Surface.txt:258: trailing whitespace.
+ 379:         return None;
Evidence/CP-014/CP014_Implementation_Surface.txt:259: trailing whitespace.
+ 380:     }
Evidence/CP-014/CP014_Implementation_Surface.txt:260: trailing whitespace.
+ 381: 
Evidence/CP-014/CP014_Implementation_Surface.txt:261: trailing whitespace.
+ 382:     Some(scr_filename.replacen("__DS__SCR__", "__DS__RCP__", 1))
Evidence/CP-014/CP014_Implementation_Surface.txt:262: trailing whitespace.
+ 383: }
Evidence/CP-014/CP014_RED_Run_Record.txt:1: trailing whitespace.
+CP014 RED EXECUTION RECORD
Evidence/CP-014/CP014_RED_Run_Record.txt:2: trailing whitespace.
+Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Evidence/CP-014/CP014_RED_Run_Record.txt:3: trailing whitespace.
+Command: cargo +1.97.1 test --test CP014_rcp_filename_candidate_identity -- --nocapture
Evidence/CP-014/CP014_RED_Run_Record.txt:4: trailing whitespace.
+Exit code: 101
Evidence/CP-014/CP014_RED_Run_Record.txt:5: trailing whitespace.
+Expected unresolved-symbol diagnostic: True
Evidence/CP-014/CP014_RED_Run_Record.txt:6: trailing whitespace.
+Formatted test SHA256: 27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
Evidence/CP-014/CP014_RED_Run_Record.txt:7: trailing whitespace.
+Original Cargo output: CP014_RED_Test_Output.txt
Evidence/CP-014/CP014_RED_Run_Record.txt:8: trailing whitespace.
+Product source modified: NO
Evidence/CP-014/CP014_Rustfmt_Check_Record.txt:1: trailing whitespace.
+CP014 RUSTFMT CHECK RECORD
Evidence/CP-014/CP014_Rustfmt_Check_Record.txt:2: trailing whitespace.
+Day: 067
Evidence/CP-014/CP014_Rustfmt_Check_Record.txt:3: trailing whitespace.
+Command: rustfmt +1.97.1 --check --edition 2021 src\lib.rs tests\CP014_rcp_filename_candidate_identity.rs
Evidence/CP-014/CP014_Rustfmt_Check_Record.txt:4: trailing whitespace.
+Exit code: 0
Evidence/CP-014/CP014_Rustfmt_Check_Record.txt:5: trailing whitespace.
+Source unchanged: True
Evidence/CP-014/CP014_Rustfmt_Check_Record.txt:6: trailing whitespace.
+Source SHA256: B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236
Evidence/CP-014/CP014_Rustfmt_Check_Record.txt:7: trailing whitespace.
+Test SHA256: 27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
Evidence/CP-014/CP014_Rustfmt_Check_Record.txt:8: trailing whitespace.
+Raw output SHA256: E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
Evidence/CP-014/CP014_Rustfmt_Check_Record.txt:9: trailing whitespace.
+Raw output: CP014_Rustfmt_Check_Output.txt
Evidence/CP-014/CP014_Rustfmt_Check_Record.txt:10: trailing whitespace.
+Full regression executed: NO
Evidence/CP-014/CP014_Rustfmt_Check_Record.txt:11: trailing whitespace.
+Git banking authorized: NO
Evidence/CP-014/CP014_Scope_Inspection.txt:1: trailing whitespace.
+=== CP014 READ-ONLY SCOPE INSPECTION ===
Evidence/CP-014/CP014_Scope_Inspection.txt:3: trailing whitespace.
+--- Git HEAD ---
Evidence/CP-014/CP014_Scope_Inspection.txt:4: trailing whitespace.
+005a38ef5e876847c4c08901c18da9c18565fd6b
Evidence/CP-014/CP014_Scope_Inspection.txt:5: trailing whitespace.
+Git exit code: 0
Evidence/CP-014/CP014_Scope_Inspection.txt:7: trailing whitespace.
+--- Branch ---
Evidence/CP-014/CP014_Scope_Inspection.txt:8: trailing whitespace.
+master
Evidence/CP-014/CP014_Scope_Inspection.txt:9: trailing whitespace.
+Git exit code: 0
Evidence/CP-014/CP014_Scope_Inspection.txt:11: trailing whitespace.
+--- Previous checkpoint test ---
Evidence/CP-014/CP014_Scope_Inspection.txt:12: trailing whitespace.
+// CP013 RED tests - Day 066
Evidence/CP-014/CP014_Scope_Inspection.txt:13: trailing whitespace.
+// Frozen anchors: W002-STOR-023.1 and W002-STOR-023.
Evidence/CP-014/CP014_Scope_Inspection.txt:14: trailing whitespace.
+// Explicit SCR-to-RCP lexical candidate derivation only.
Evidence/CP-014/CP014_Scope_Inspection.txt:15: trailing whitespace.
+// No promotion, filesystem activity, publication, or authority.
Evidence/CP-014/CP014_Scope_Inspection.txt:16: trailing whitespace.
+
Evidence/CP-014/CP014_Scope_Inspection.txt:17: trailing whitespace.
+use data_sculptor_core::build_final_filename_candidate_for_scr;
Evidence/CP-014/CP014_Scope_Inspection.txt:18: trailing whitespace.
+
Evidence/CP-014/CP014_Scope_Inspection.txt:19: trailing whitespace.
+const SCR: &str = "__DS__SCR__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.txt";
Evidence/CP-014/CP014_Scope_Inspection.txt:20: trailing whitespace.
+const RCP: &str = "__DS__RCP__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.txt";
Evidence/CP-014/CP014_Scope_Inspection.txt:21: trailing whitespace.
+
Evidence/CP-014/CP014_Scope_Inspection.txt:22: trailing whitespace.
+#[test]
Evidence/CP-014/CP014_Scope_Inspection.txt:23: trailing whitespace.
+fn derives_rcp_candidate_only_with_explicit_class() {
Evidence/CP-014/CP014_Scope_Inspection.txt:24: trailing whitespace.
+    assert_eq!(
Evidence/CP-014/CP014_Scope_Inspection.txt:25: trailing whitespace.
+        build_final_filename_candidate_for_scr(SCR, "RCP"),
Evidence/CP-014/CP014_Scope_Inspection.txt:26: trailing whitespace.
+        Some(RCP.to_string())
Evidence/CP-014/CP014_Scope_Inspection.txt:27: trailing whitespace.
+    );
Evidence/CP-014/CP014_Scope_Inspection.txt:28: trailing whitespace.
+}
Evidence/CP-014/CP014_Scope_Inspection.txt:29: trailing whitespace.
+
Evidence/CP-014/CP014_Scope_Inspection.txt:30: trailing whitespace.
+#[test]
Evidence/CP-014/CP014_Scope_Inspection.txt:31: trailing whitespace.
+fn preserves_distinct_timestamp_and_uuid_tokens() {
Evidence/CP-014/CP014_Scope_Inspection.txt:32: trailing whitespace.
+    let scr = "__DS__SCR__20261013T173300000Z__123e4567-e89b-42d3-a456-426614174000.txt";
Evidence/CP-014/CP014_Scope_Inspection.txt:33: trailing whitespace.
+    let rcp = "__DS__RCP__20261013T173300000Z__123e4567-e89b-42d3-a456-426614174000.txt";
Evidence/CP-014/CP014_Scope_Inspection.txt:34: trailing whitespace.
+
Evidence/CP-014/CP014_Scope_Inspection.txt:35: trailing whitespace.
+    assert_eq!(
Evidence/CP-014/CP014_Scope_Inspection.txt:36: trailing whitespace.
+        build_final_filename_candidate_for_scr(scr, "RCP"),
Evidence/CP-014/CP014_Scope_Inspection.txt:37: trailing whitespace.
+        Some(rcp.to_string())
Evidence/CP-014/CP014_Scope_Inspection.txt:38: trailing whitespace.
+    );
Evidence/CP-014/CP014_Scope_Inspection.txt:39: trailing whitespace.
+    assert_ne!(rcp, RCP);
Evidence/CP-014/CP014_Scope_Inspection.txt:40: trailing whitespace.
+}
Evidence/CP-014/CP014_Scope_Inspection.txt:41: trailing whitespace.
+
Evidence/CP-014/CP014_Scope_Inspection.txt:42: trailing whitespace.
+#[test]
Evidence/CP-014/CP014_Scope_Inspection.txt:43: trailing whitespace.
+fn refuses_non_scr_and_noncanonical_source_classes() {
Evidence/CP-014/CP014_Scope_Inspection.txt:44: trailing whitespace.
+    for filename in [
Evidence/CP-014/CP014_Scope_Inspection.txt:45: trailing whitespace.
+        SCR.replacen("__DS__SCR__", "__DS__CVT__", 1),
Evidence/CP-014/CP014_Scope_Inspection.txt:46: trailing whitespace.
+        SCR.replacen("__DS__SCR__", "__DS__RCP__", 1),
Evidence/CP-014/CP014_Scope_Inspection.txt:47: trailing whitespace.
+        SCR.replacen("__DS__SCR__", "__DS__scr__", 1),
Evidence/CP-014/CP014_Scope_Inspection.txt:48: trailing whitespace.
+        "ordinary.txt".to_string(),
Evidence/CP-014/CP014_Scope_Inspection.txt:49: trailing whitespace.
+    ] {
Evidence/CP-014/CP014_Scope_Inspection.txt:50: trailing whitespace.
+        assert_eq!(
Evidence/CP-014/CP014_Scope_Inspection.txt:51: trailing whitespace.
+            build_final_filename_candidate_for_scr(&filename, "RCP"),
Evidence/CP-014/CP014_Scope_Inspection.txt:52: trailing whitespace.
+            None
Evidence/CP-014/CP014_Scope_Inspection.txt:53: trailing whitespace.
+        );
Evidence/CP-014/CP014_Scope_Inspection.txt:54: trailing whitespace.
+    }
Evidence/CP-014/CP014_Scope_Inspection.txt:55: trailing whitespace.
+}
Evidence/CP-014/CP014_Scope_Inspection.txt:56: trailing whitespace.
+
Evidence/CP-014/CP014_Scope_Inspection.txt:57: trailing whitespace.
+#[test]
Evidence/CP-014/CP014_Scope_Inspection.txt:58: trailing whitespace.
+fn refuses_unsupported_or_incorrectly_cased_final_classes() {
Evidence/CP-014/CP014_Scope_Inspection.txt:59: trailing whitespace.
+    for class in ["", "rcp", "Rcp", "CVT", "CAT", "SCR", "MAP", "RCP ", " RCP"] {
Evidence/CP-014/CP014_Scope_Inspection.txt:60: trailing whitespace.
+        assert_eq!(
Evidence/CP-014/CP014_Scope_Inspection.txt:61: trailing whitespace.
+            build_final_filename_candidate_for_scr(SCR, class),
Evidence/CP-014/CP014_Scope_Inspection.txt:62: trailing whitespace.
+            None,
Evidence/CP-014/CP014_Scope_Inspection.txt:63: trailing whitespace.
+            "{class:?}"
Evidence/CP-014/CP014_Scope_Inspection.txt:64: trailing whitespace.
+        );
Evidence/CP-014/CP014_Scope_Inspection.txt:65: trailing whitespace.
+    }
Evidence/CP-014/CP014_Scope_Inspection.txt:66: trailing whitespace.
+}
Evidence/CP-014/CP014_Scope_Inspection.txt:67: trailing whitespace.
+
Evidence/CP-014/CP014_Scope_Inspection.txt:68: trailing whitespace.
+#[test]
Evidence/CP-014/CP014_Scope_Inspection.txt:69: trailing whitespace.
+fn refuses_wrong_or_ambiguous_serialization_extensions() {
Evidence/CP-014/CP014_Scope_Inspection.txt:70: trailing whitespace.
+    for filename in [
Evidence/CP-014/CP014_Scope_Inspection.txt:71: trailing whitespace.
+        SCR.replace(".txt", ".csv"),
Evidence/CP-014/CP014_Scope_Inspection.txt:72: trailing whitespace.
+        SCR.replace(".txt", ".TXT"),
Evidence/CP-014/CP014_Scope_Inspection.txt:73: trailing whitespace.
+        SCR.replace(".txt", ".tXt"),
Evidence/CP-014/CP014_Scope_Inspection.txt:74: trailing whitespace.
+        SCR.replace(".txt", ".txt.gz"),
Evidence/CP-014/CP014_Scope_Inspection.txt:75: trailing whitespace.
+        SCR.replace(".txt", "."),
Evidence/CP-014/CP014_Scope_Inspection.txt:76: trailing whitespace.
+        SCR.replace(".txt", ""),
Evidence/CP-014/CP014_Scope_Inspection.txt:77: trailing whitespace.
+    ] {
Evidence/CP-014/CP014_Scope_Inspection.txt:78: trailing whitespace.
+        assert_eq!(
Evidence/CP-014/CP014_Scope_Inspection.txt:79: trailing whitespace.
+            build_final_filename_candidate_for_scr(&filename, "RCP"),
Evidence/CP-014/CP014_Scope_Inspection.txt:80: trailing whitespace.
+            None
Evidence/CP-014/CP014_Scope_Inspection.txt:81: trailing whitespace.
+        );
Evidence/CP-014/CP014_Scope_Inspection.txt:82: trailing whitespace.
+    }
Evidence/CP-014/CP014_Scope_Inspection.txt:83: trailing whitespace.
+}
Evidence/CP-014/CP014_Scope_Inspection.txt:84: trailing whitespace.
+
Evidence/CP-014/CP014_Scope_Inspection.txt:85: trailing whitespace.
+#[test]
Evidence/CP-014/CP014_Scope_Inspection.txt:86: trailing whitespace.
+fn refuses_invalid_identity_paths_and_whitespace() {
Evidence/CP-014/CP014_Scope_Inspection.txt:87: trailing whitespace.
+    for filename in [
Evidence/CP-014/CP014_Scope_Inspection.txt:88: trailing whitespace.
+        SCR.replace("20261014", "20260230"),
Evidence/CP-014/CP014_Scope_Inspection.txt:89: trailing whitespace.
+        SCR.replace("T011203456Z", "T251203456Z"),
Evidence/CP-014/CP014_Scope_Inspection.txt:90: trailing whitespace.
+        SCR.replace("-41d4-", "-51d4-"),
Evidence/CP-014/CP014_Scope_Inspection.txt:91: trailing whitespace.
+        SCR.replace("-a716-", "-1716-"),
Evidence/CP-014/CP014_Scope_Inspection.txt:92: trailing whitespace.
+        format!("folder/{SCR}"),
Evidence/CP-014/CP014_Scope_Inspection.txt:93: trailing whitespace.
+        format!("folder\\{SCR}"),
Evidence/CP-014/CP014_Scope_Inspection.txt:94: trailing whitespace.
+        format!(" {SCR}"),
Evidence/CP-014/CP014_Scope_Inspection.txt:95: trailing whitespace.
+        format!("{SCR} "),
Evidence/CP-014/CP014_Scope_Inspection.txt:96: trailing whitespace.
+        format!("{SCR}\n"),
Evidence/CP-014/CP014_Scope_Inspection.txt:97: trailing whitespace.
+    ] {
Evidence/CP-014/CP014_Scope_Inspection.txt:98: trailing whitespace.
+        assert_eq!(
Evidence/CP-014/CP014_Scope_Inspection.txt:99: trailing whitespace.
+            build_final_filename_candidate_for_scr(&filename, "RCP"),
Evidence/CP-014/CP014_Scope_Inspection.txt:100: trailing whitespace.
+            None
Evidence/CP-014/CP014_Scope_Inspection.txt:101: trailing whitespace.
+        );
Evidence/CP-014/CP014_Scope_Inspection.txt:102: trailing whitespace.
+    }
Evidence/CP-014/CP014_Scope_Inspection.txt:103: trailing whitespace.
+}
Evidence/CP-014/CP014_Scope_Inspection.txt:105: trailing whitespace.
+--- Rust source file inventory ---
Evidence/CP-014/CP014_Scope_Inspection.txt:106: trailing whitespace.
+C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs
Evidence/CP-014/CP014_Scope_Inspection.txt:108: trailing whitespace.
+--- SCR / RCP source references ---
Evidence/CP-014/CP014_Scope_Inspection.txt:109: trailing whitespace.
+C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:8: /// Screens an exact filename for analyst-owned CSV SOURCE candidate form.
Evidence/CP-014/CP014_Scope_Inspection.txt:110: trailing whitespace.
+C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:124: "RCP" => Some("RCP"),
Evidence/CP-014/CP014_Scope_Inspection.txt:111: trailing whitespace.
+C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:131: "SCR" => Some("SCR"),
Evidence/CP-014/CP014_Scope_Inspection.txt:112: trailing whitespace.
+C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:333: /// Derives the SCR staging filename candidate corresponding to a canonical CVT.
Evidence/CP-014/CP014_Scope_Inspection.txt:113: trailing whitespace.
+C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:337: pub fn build_scr_candidate_filename_for_cvt(filename: &str) -> Option<String> {
Evidence/CP-014/CP014_Scope_Inspection.txt:114: trailing whitespace.
+C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:342: Some(filename.replacen("__DS__CVT__", "__DS__SCR__", 1))
Evidence/CP-014/CP014_Scope_Inspection.txt:115: trailing whitespace.
+C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:345: /// Recognizes a canonical SCR staging filename candidate.
Evidence/CP-014/CP014_Scope_Inspection.txt:116: trailing whitespace.
+C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:349: pub fn is_canonical_scr_filename_candidate(filename: &str) -> bool {
Evidence/CP-014/CP014_Scope_Inspection.txt:117: trailing whitespace.
+C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:359: Some(tokens) if tokens.semantic_class == "SCR"
Evidence/CP-014/CP014_Scope_Inspection.txt:118: trailing whitespace.
+C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:363: /// Derives a canonical RCP final filename candidate from an SCR staging name.
Evidence/CP-014/CP014_Scope_Inspection.txt:119: trailing whitespace.
+C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:368: pub fn build_final_filename_candidate_for_scr(
Evidence/CP-014/CP014_Scope_Inspection.txt:120: trailing whitespace.
+C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:369: scr_filename: &str,
Evidence/CP-014/CP014_Scope_Inspection.txt:121: trailing whitespace.
+C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:372: if intended_final_class != "RCP" || !is_canonical_scr_filename_candidate(scr_filename) {
Evidence/CP-014/CP014_Scope_Inspection.txt:122: trailing whitespace.
+C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:376: let tokens = extract_artifact_filename_tokens(scr_filename)?;
Evidence/CP-014/CP014_Scope_Inspection.txt:123: trailing whitespace.
+C:\Users\Admin\downloads\DataSculptor-WASM002\src\lib.rs:382: Some(scr_filename.replacen("__DS__SCR__", "__DS__RCP__", 1))
Evidence/CP-014/CP014_Source_Diff.txt:1: trailing whitespace.
+diff --git a/src/lib.rs b/src/lib.rs
Evidence/CP-014/CP014_Source_Diff.txt:2: trailing whitespace.
+index b2df81b..56916f9 100644
Evidence/CP-014/CP014_Source_Diff.txt:3: trailing whitespace.
+--- a/src/lib.rs
Evidence/CP-014/CP014_Source_Diff.txt:4: trailing whitespace.
++++ b/src/lib.rs
Evidence/CP-014/CP014_Source_Diff.txt:5: trailing whitespace.
+@@ -381,3 +381,23 @@ pub fn build_final_filename_candidate_for_scr(
Evidence/CP-014/CP014_Source_Diff.txt:6: trailing whitespace.
+ 
Evidence/CP-014/CP014_Source_Diff.txt:7: trailing whitespace.
+     Some(scr_filename.replacen("__DS__SCR__", "__DS__RCP__", 1))
Evidence/CP-014/CP014_Source_Diff.txt:8: trailing whitespace.
+ }
Evidence/CP-014/CP014_Source_Diff.txt:9: trailing whitespace.
++
Evidence/CP-014/CP014_Source_Diff.txt:10: trailing whitespace.
++/// Recognizes a canonical RCP Receipt filename candidate.
Evidence/CP-014/CP014_Source_Diff.txt:11: trailing whitespace.
++///
Evidence/CP-014/CP014_Source_Diff.txt:12: trailing whitespace.
++/// Lexical recognition only. This does not verify Receipt contents,
Evidence/CP-014/CP014_Source_Diff.txt:13: trailing whitespace.
++/// filesystem state, staging promotion, publication, or authority.
Evidence/CP-014/CP014_Source_Diff.txt:14: trailing whitespace.
++pub fn is_canonical_rcp_filename_candidate(filename: &str) -> bool {
Evidence/CP-014/CP014_Source_Diff.txt:15: trailing whitespace.
++    if filename
Evidence/CP-014/CP014_Source_Diff.txt:16: trailing whitespace.
++        .chars()
Evidence/CP-014/CP014_Source_Diff.txt:17: trailing whitespace.
++        .any(|ch| ch.is_whitespace() || ch == '/' || ch == '\\')
Evidence/CP-014/CP014_Source_Diff.txt:18: trailing whitespace.
++    {
Evidence/CP-014/CP014_Source_Diff.txt:19: trailing whitespace.
++        return false;
Evidence/CP-014/CP014_Source_Diff.txt:20: trailing whitespace.
++    }
Evidence/CP-014/CP014_Source_Diff.txt:21: trailing whitespace.
++
Evidence/CP-014/CP014_Source_Diff.txt:22: trailing whitespace.
++    matches!(
Evidence/CP-014/CP014_Source_Diff.txt:23: trailing whitespace.
++        extract_artifact_filename_tokens(filename),
Evidence/CP-014/CP014_Source_Diff.txt:24: trailing whitespace.
++        Some(tokens)
Evidence/CP-014/CP014_Source_Diff.txt:25: trailing whitespace.
++            if tokens.semantic_class == "RCP"
Evidence/CP-014/CP014_Source_Diff.txt:26: trailing whitespace.
++                && tokens.serialization_extension == "txt"
Evidence/CP-014/CP014_Source_Diff.txt:27: trailing whitespace.
++    )
Evidence/CP-014/CP014_Source_Diff.txt:28: trailing whitespace.
++}
Evidence/CP-014/CP014_Test_Format_Record.txt:1: trailing whitespace.
+CP014 TEST FORMATTING RECORD
Evidence/CP-014/CP014_Test_Format_Record.txt:2: trailing whitespace.
+Command: rustfmt +1.97.1 --edition 2021 tests\CP014_rcp_filename_candidate_identity.rs
Evidence/CP-014/CP014_Test_Format_Record.txt:3: trailing whitespace.
+Exit code: 0
Evidence/CP-014/CP014_Test_Format_Record.txt:4: trailing whitespace.
+SHA256 before: B5F51F876EBD13E734D99087E4F46D6E580EC653DA4FF9243BFEA880C58F75E5
Evidence/CP-014/CP014_Test_Format_Record.txt:5: trailing whitespace.
+SHA256 after:  27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
Evidence/CP-014/CP014_Test_Format_Record.txt:6: trailing whitespace.
+Changed by formatting: True
Evidence/CP-014/CP014_Test_Format_Record.txt:7: trailing whitespace.
+Raw command output: CP014_Rustfmt_Output.txt
Evidence/CP-014/CP014_Test_Format_Record.txt:8: trailing whitespace.
+RED test executed: NO
Evidence/CP-014/CP014_WASM_Build_Record.txt:1: trailing whitespace.
+CP014 CANONICAL WASM BUILD RECORD
Evidence/CP-014/CP014_WASM_Build_Record.txt:2: trailing whitespace.
+Day: 067
Evidence/CP-014/CP014_WASM_Build_Record.txt:3: trailing whitespace.
+Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Evidence/CP-014/CP014_WASM_Build_Record.txt:4: trailing whitespace.
+Command: cargo +1.97.1 build --target wasm32-unknown-unknown --lib
Evidence/CP-014/CP014_WASM_Build_Record.txt:5: trailing whitespace.
+Exit code: 0
Evidence/CP-014/CP014_WASM_Build_Record.txt:6: trailing whitespace.
+Source and test unchanged: True
Evidence/CP-014/CP014_WASM_Build_Record.txt:7: trailing whitespace.
+Source SHA256: B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236
Evidence/CP-014/CP014_WASM_Build_Record.txt:8: trailing whitespace.
+Test SHA256: 27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
Evidence/CP-014/CP014_WASM_Build_Record.txt:9: trailing whitespace.
+Raw build output SHA256: E0553F624C36C32260BF6850045362AB18920896E111C2E94ABAA6D022BD583A
Evidence/CP-014/CP014_WASM_Build_Record.txt:10: trailing whitespace.
+Raw output: CP014_WASM_Build_Output.txt
Evidence/CP-014/CP014_WASM_Build_Record.txt:11: trailing whitespace.
+Browser execution tested: NO
Evidence/CP-014/CP014_WASM_Build_Record.txt:12: trailing whitespace.
+Git banking authorized: NO

warning: in the working copy of '.gitattributes', LF will be replaced by CRLF the next time Git touches it

CP014 CONTROLLED STAGING RECORD
Day: 067
Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Branch: master
Inventory SHA256: 6ED47A9151696174BF9E8193B8B5399E662270ED10436FED29C1F1D732389472
Expected staged paths: 27
Actual staged paths: 27
Git add exit: 0
Staged path-list exit: 0
Exact staged path set: True
Missing intended paths: 0
Unexpected staged paths: 0
Git staged whitespace exit: 2
Git add log: CP014_Staging_Command_Output.txt
Staged paths: CP014_Staged_Path_List.txt
Whitespace log: CP014_Staged_Whitespace_Check.txt
Original evidence rewritten: NO
Git commit executed: NO
Git banking authorized: NO

CP014 TEST FORMATTING RECORD
Command: rustfmt +1.97.1 --edition 2021 tests\CP014_rcp_filename_candidate_identity.rs
Exit code: 0
SHA256 before: B5F51F876EBD13E734D99087E4F46D6E580EC653DA4FF9243BFEA880C58F75E5
SHA256 after:  27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
Changed by formatting: True
Raw command output: CP014_Rustfmt_Output.txt
RED test executed: NO

rm 'Evidence/CP-014/CP014_Evidence_Preflight.txt'
rm 'Evidence/CP-014/CP014_Full_Regression_Record.txt'
rm 'Evidence/CP-014/CP014_Full_Regression_Test_Output.txt'
rm 'Evidence/CP-014/CP014_GREEN_Run_Record.txt'
rm 'Evidence/CP-014/CP014_GREEN_Test_Output.txt'
rm 'Evidence/CP-014/CP014_Git_Attributes_Amendment_Record.txt'
rm 'Evidence/CP-014/CP014_Git_Attributes_Diff_Recovery.txt'
rm 'Evidence/CP-014/CP014_Git_Attributes_Recovery_Record.txt'
rm 'Evidence/CP-014/CP014_Git_Text_Policy_Inspection.txt'
rm 'Evidence/CP-014/CP014_Hash_Inventory.txt'
rm 'Evidence/CP-014/CP014_Hash_Inventory_Verification.txt'
rm 'Evidence/CP-014/CP014_Implementation_Record.txt'
rm 'Evidence/CP-014/CP014_Implementation_Surface.txt'
rm 'Evidence/CP-014/CP014_RED_Run_Record.txt'
rm 'Evidence/CP-014/CP014_RED_Test_Output.txt'
rm 'Evidence/CP-014/CP014_Rustfmt_Check_Output.txt'
rm 'Evidence/CP-014/CP014_Rustfmt_Check_Record.txt'
rm 'Evidence/CP-014/CP014_Rustfmt_Output.txt'
rm 'Evidence/CP-014/CP014_Scope_Inspection.txt'
rm 'Evidence/CP-014/CP014_Scope_Lock.txt'
rm 'Evidence/CP-014/CP014_Source_Diff.txt'
rm 'Evidence/CP-014/CP014_Test_Format_Record.txt'
rm 'Evidence/CP-014/CP014_WASM_Build_Output.txt'
rm 'Evidence/CP-014/CP014_WASM_Build_Record.txt'

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.35s

CP014 CANONICAL WASM BUILD RECORD
Day: 067
Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Command: cargo +1.97.1 build --target wasm32-unknown-unknown --lib
Exit code: 0
Source and test unchanged: True
Source SHA256: B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236
Test SHA256: 27916505EA60D32B325305BED31AEFE60FEBB666AA54399228796DF3EEC659C4
Raw build output SHA256: E0553F624C36C32260BF6850045362AB18920896E111C2E94ABAA6D022BD583A
Raw output: CP014_WASM_Build_Output.txt
Browser execution tested: NO
Git banking authorized: NO

CP014 ZIP BATCH VERIFICATION
Day: 067
Status: EXPERIMENTAL - NO COMMIT
Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
TXT files in batch: 31
Each ZIP contains exactly one original TXT.
Original TXT files remain unchanged.

FORMAT: TXT_SHA256 | ZIP_SHA256 | TXT_BYTES | ZIP_BYTES | FILENAME

62748820D199957C385FF28BDA6B6EDF4B82E80ED90C05E9A1F57CC9BE4ABC5A | CFE971BACDE2594A73A9B6895943DE43BAE8E91553ABEF2626064D8F1F07FDCF | 6551 | 1980 | CP014_Evidence_Preflight.txt
051556BE29E0C06BA560C37BBE8F3BE478D82DE40FF830897657B976F31E0626 | E72E36E8D717EC7C5534FD214D38942C072B0F0F89783D4E98206B7315C93F3B | 611 | 587 | CP014_Full_Regression_Record.txt
9669D0A3040CCCC2B6F7768FC4E84BC1D71FD69D20CD261B20CABBB0938A83DF | E0F88B01B37177C793882AC50A47EE1A6845C18060790E557ECB8D4F17DE0624 | 7164 | 1913 | CP014_Full_Regression_Test_Output.txt
7C9D6A199D4F5F912B10E63FC94F72254D3EECEF7787E4D49155B8FBE677F3D5 | 0E31EBD60FFC2E12091B0A8194A845B8937A9189DD2602F2CE4C2292C392A605 | 618 | 593 | CP014_Git_Attributes_Amendment_Record.txt
FC54CF9CF95253519DFF561FC1DEF8D457BB815343FD4C75D81ABE9895DA366E | 4DB9A9553BECA7074320ED20D70D4E315754C88896DDE6E6D2FBD8A6AFC09C75 | 332 | 386 | CP014_Git_Attributes_Diff_Recovery.txt
212CA232CE05AEDE0FBD932AADF48000E6A3C8A0F56EFEF0A2C6EC891B597238 | C423ED3873954BCC0097FB89C4285B60B71CE7EAEFD05F9AC7D55BC503BC6930 | 717 | 654 | CP014_Git_Attributes_Recovery_Record.txt
3E30775424DEC65711D193156EE720DCEE4B1CB20ED096AEE9C67DF7042B09FE | E1FA6CF00727C22F7C85171D11629F40B1F822D073FA233FAA0AB32C970996B5 | 820 | 614 | CP014_Git_Text_Policy_Inspection.txt
C28E4993E66A1E790B24E78E59953711A7EDFB34D5F9D2812C294C427591533E | 31F81DE51284F1A74FB489F1F2E2C5AB6D37353845B55479BFE7BC1F98209874 | 588 | 575 | CP014_GREEN_Run_Record.txt
6C79FD4AA16190F4F9851334435FB601014D61D3A59B40F3A3E18151FAA550B8 | E9EBA6A5C0C0F60382322823EE4D80B817BCB120D21FE3B636AFEF7B9DB786E4 | 707 | 547 | CP014_GREEN_Test_Output.txt
6ED47A9151696174BF9E8193B8B5399E662270ED10436FED29C1F1D732389472 | 116259B839F680807BAA79D9554C092C131D0B281094829CAB0A41AD5FC321C1 | 2964 | 1611 | CP014_Hash_Inventory.txt
30BE1A8EA1C3ACAAD813A16BCEBF3AFFBAA2F1CF91898F1E393AB57DFA8F6786 | 8057184681537EC245177EC3656494492BDC09DA4986ACCF68E1223C4E2AB63B | 412 | 458 | CP014_Hash_Inventory_Verification.txt
1B23A6A15EE66CA820BC15C2D935099DE510CB30BEBD32E2B8422C5C5773B184 | 820294732AF244056689F4FE3CFF00620DF21F26AB3596080DCA8BD297BEB966 | 529 | 545 | CP014_Implementation_Record.txt
5573FDE0F50394BFE63ADECA872B6C84CCAAE5643F54426A29E816DD15F5264F | 01BA1A45CDBB7CF9CB4FDE7BF5F00EAA05B576C156473675465367925BF85569 | 10143 | 3401 | CP014_Implementation_Surface.txt
816E574D51AD7B9CA99E96A637993D78F3E63175694A3DD03492AE9CDD80B111 | EAA885650769D239B03CA7790DFC3AE4E5A87B04B61F36F51ABE345A7699BDCB | 398 | 453 | CP014_RED_Run_Record.txt
8E3F94F9567BDA62E90DE377FD76346CC98514AC106EE941152D84FAA7227AF0 | 63F025185C072728FED9A61C36C687A159296CD3DBAA2A3D88DF2B678349B478 | 870 | 500 | CP014_RED_Test_Output.txt
E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | 304DC900B588130472D51D41942DE5C95A9DD2FEACC763E298BB2D107402335C | 0 | 158 | CP014_Rustfmt_Check_Output.txt
A3A58BCD382E8DAEC99008BC70299403DA9A884AD45B0A26557EAA334203FBEB | 52377DE30D0AA57C6193B3A09168973A526AD16861B1793224D6F55F854D116B | 530 | 545 | CP014_Rustfmt_Check_Record.txt
E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | C6AF8815A7A05CDCBEE2839B7FBD7F0D2DBB46F50D31CE562AD26B0C4A7D227B | 0 | 146 | CP014_Rustfmt_Output.txt
8760615464B2477CD85CCE2A74302BDB6421CEBA0726920BD6C9FDCC915D3C02 | F10EC6951484ECFD2B6AE70F1AC17DD31633CDAFB50F29D4669A0965833255D6 | 4967 | 1588 | CP014_Scope_Inspection.txt
FD47D4837EE8152D95DCD5C3EFA3746D5404D0B40576CEDFE50597CF887ABB9D | FCD18D95396DB6274705FEA2C96538B8BC4D6936FC3FAFD68EB0BB339DC58322 | 826 | 705 | CP014_Scope_Lock.txt
74FD689FA0528F12A4BCA6BFD66CB226EBE77E85170D0E0CD775ED81F10B5E61 | 0361ED758A156638B929B8B9E90A6BD40CCBAC9FD6AF25DC60124F6B2BB904FD | 894 | 630 | CP014_Source_Diff.txt
025C97F1A29FEFBFAA519A361E1E63FC8A4F3A2D6FEC51559D735D55930BFF85 | D9EC08185A46CFEBDC0EAE37B9A35BCB81AF57D9832DFAF0E0797C58ABD3A648 | 1192 | 453 | CP014_Staged_Path_List.txt
15ABFA12A42641C220ACDC1FF123FA348E1F04AF8C227B040662F71EE346A8C8 | C86B4A5FFCD85D77064E9A5EED677E2EA0207AAF0BAFABD50B15E948C68F4E94 | 90813 | 12668 | CP014_Staged_Whitespace_Check.txt
27C51123B0695A2886E7887D49F40EC1E9681190C0F62AE5E15C1E08B2C4ED22 | 763D43C12F9CF0C70826EB33818B73B0D8D29C2275E6FD7BADC6EF7A95DDC85C | 107 | 257 | CP014_Staging_Command_Output.txt
7834041BE84CFA25BFC2F63FFF167424A8A4B67E9C4E2CD521ED35C858034BE7 | 62B06FF2EEC06ED6A22A73E4EF0A100073931292B6C1F928BA9EBA2FDB1C1F30 | 631 | 528 | CP014_Staging_Record.txt
350F43CAA2E14C4F51E700288D5EF7FFECC09D14480E8D0A102BCF14D59DCD58 | 204837CB0113BDD84CDCA7324EDC24B0B989A99CAFD235785DEAB80F7751A53C | 392 | 456 | CP014_Test_Format_Record.txt
E0553F624C36C32260BF6850045362AB18920896E111C2E94ABAA6D022BD583A | 67CF354FD542C86A09FCFA1783825883A5985D69C60D30F8D82B4F33E88C869F | 159 | 293 | CP014_WASM_Build_Output.txt
8CCD83F6E36C54CECF3DFA34A17A1EDD1E82BBB7BFAA03078F13D4AC807DCD4C | 2FB1F229BE87CF974E3B0158A25BDF00192BD96AC0826480858EE3D8B1AEC32B | 562 | 551 | CP014_WASM_Build_Record.txt
E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | 8F9950850F5A435897C9247ECBE5D5B6491FC254D27BD79BDE1309E4809E6420 | 0 | 166 | CP014_ZIP_Pilot_Git_Add_Output.txt
DD571E4256B774BA3A86D8CE51DAE9AD5966552D5102FF109F4E5EFABF3710D6 | 823D0BC183FF9C15254986B47AE6F07BF2D5B087BF3A680CC8A493BE3C7B26A5 | 686 | 571 | CP014_ZIP_Pilot_Git_Record.txt
33FCCF77CA87F7CB9F8F213EA9C7A92B24A057FFDC6277AE20F368D4CA5A6136 | 1BBC26B8C3A3F521CEAAC29B85F68C5BA491AFBF1370EBA34239107E85AF5B00 | 733 | 573 | CP014_ZIP_Pilot_Verification.txt

ZIP archives verified: 31
Pilot ZIP reused unchanged: True
Staged Git paths unchanged: True
Batch verification PASS: True
Batch record itself excluded from snapshot.
Git staging replacement performed: NO
Git commit executed: NO
Git banking authorized: NO

CP014 ZIP EVIDENCE INDEX REPLACEMENT
Day: 067
Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Plaintext paths removed from Git index: 24
Index removal exit: 0
Original plaintext files still on disk: True
ZIP archives staged: 32
Temporary attributes policy backed up: YES
Attributes restored to HEAD in index: True
Attributes restore exit: 0
Final staged whitespace exit: 0
Expected staged paths: 34
Actual staged paths: 34
Missing paths: 0
Unexpected paths: 0
Source/test fingerprints unchanged: True
Replacement PASS: True
Git commit executed: NO
Git banking authorized: NO
Original TXT files may now appear untracked.
No Git ignore policy has been added.

CP014 ZIP PILOT - GIT OBJECT VERIFICATION
Day: 067
Pilot ZIP: Evidence/CP-014/ZIP/CP014_Implementation_Surface.txt.zip
ZIP SHA256: 01BA1A45CDBB7CF9CB4FDE7BF5F00EAA05B576C156473675465367925BF85569
Git add exit: 0
Raw-byte Git hash exit: 0
Staged Git object lookup exit: 0
Raw-byte Git object ID: bdb223bb982bced6919253bf8512856922a0a5cb
Staged Git object ID: bdb223bb982bced6919253bf8512856922a0a5cb
Raw and staged objects identical: True
Original 27 staged paths preserved: True
Staged paths now: 28
Pilot Git verification PASS: True
Original TXT rewritten: NO
Original TXT staging retained for later replacement: YES
Git commit executed: NO
Git banking authorized: NO

CP014 ZIP EVIDENCE PILOT
Day: 067
Status: EXPERIMENTAL - NOT YET APPROVED

Original: CP014_Implementation_Surface.txt
Original bytes: 10143
Original SHA256: 5573FDE0F50394BFE63ADECA872B6C84CCAAE5643F54426A29E816DD15F5264F
Original unchanged after ZIP: True

ZIP: ZIP/CP014_Implementation_Surface.txt.zip
ZIP bytes: 3401
ZIP SHA256: 01BA1A45CDBB7CF9CB4FDE7BF5F00EAA05B576C156473675465367925BF85569
Entries inside ZIP: 1

Extracted SHA256: 5573FDE0F50394BFE63ADECA872B6C84CCAAE5643F54426A29E816DD15F5264F
Extracted bytes: 10143
Exact original recovered: True

Existing Git staged path list unchanged: True
Git ZIP blob verification: PENDING
Original TXT committed: NO
Git commit executed: NO
Overall pilot: True

Evidence/CP-014/ZIP/CP014_Evidence_Preflight.txt.zip
Evidence/CP-014/ZIP/CP014_Full_Regression_Record.txt.zip
Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip
Evidence/CP-014/ZIP/CP014_GREEN_Run_Record.txt.zip
Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip
Evidence/CP-014/ZIP/CP014_Git_Attributes_Amendment_Record.txt.zip
Evidence/CP-014/ZIP/CP014_Git_Attributes_Diff_Recovery.txt.zip
Evidence/CP-014/ZIP/CP014_Git_Attributes_Recovery_Record.txt.zip
Evidence/CP-014/ZIP/CP014_Git_Text_Policy_Inspection.txt.zip
Evidence/CP-014/ZIP/CP014_Hash_Inventory.txt.zip
Evidence/CP-014/ZIP/CP014_Hash_Inventory_Verification.txt.zip
Evidence/CP-014/ZIP/CP014_Implementation_Record.txt.zip
Evidence/CP-014/ZIP/CP014_Implementation_Surface.txt.zip
Evidence/CP-014/ZIP/CP014_RED_Run_Record.txt.zip
Evidence/CP-014/ZIP/CP014_RED_Test_Output.txt.zip
Evidence/CP-014/ZIP/CP014_Rustfmt_Check_Output.txt.zip
Evidence/CP-014/ZIP/CP014_Rustfmt_Check_Record.txt.zip
Evidence/CP-014/ZIP/CP014_Rustfmt_Output.txt.zip
Evidence/CP-014/ZIP/CP014_Scope_Inspection.txt.zip
Evidence/CP-014/ZIP/CP014_Scope_Lock.txt.zip
Evidence/CP-014/ZIP/CP014_Source_Diff.txt.zip
Evidence/CP-014/ZIP/CP014_Staged_Path_List.txt.zip
Evidence/CP-014/ZIP/CP014_Staged_Whitespace_Check.txt.zip
Evidence/CP-014/ZIP/CP014_Staging_Command_Output.txt.zip
Evidence/CP-014/ZIP/CP014_Staging_Record.txt.zip
Evidence/CP-014/ZIP/CP014_Test_Format_Record.txt.zip
Evidence/CP-014/ZIP/CP014_WASM_Build_Output.txt.zip
Evidence/CP-014/ZIP/CP014_WASM_Build_Record.txt.zip
Evidence/CP-014/ZIP/CP014_ZIP_Batch_Verification.txt.zip
Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Git_Add_Output.txt.zip
Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Git_Record.txt.zip
Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Verification.txt.zip
src/lib.rs
tests/CP014_rcp_filename_candidate_identity.rs

CP014 ZIP EVIDENCE SEAL VERIFICATION
Day: 067
Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Original batch record SHA256: 461F4554A86FEDC03949E5375BFC15B6513ED058128C906A97621F3085B6D8B8
Recovered TXT SHA256: 461F4554A86FEDC03949E5375BFC15B6513ED058128C906A97621F3085B6D8B8
Original TXT unchanged: True
Sealing ZIP SHA256: FFB0BF3AD0009EC2CE337BE90E99F1F5DC4231439EC954A1EF7DC1C004299105
Total ZIP archives: 32
Git staging unchanged: True
Evidence ZIP set sealed: True
Git replacement staging performed: NO
Git commit executed: NO
Git banking authorized: NO
Closeout record stored outside repository.

CP014 SEALED ZIP GIT STAGING VERIFICATION
Day: 067
Git HEAD: 005a38ef5e876847c4c08901c18da9c18565fd6b
Batch record SHA256: 461F4554A86FEDC03949E5375BFC15B6513ED058128C906A97621F3085B6D8B8
Seal record SHA256: 66357141AB4F51C4A808E37A49393151555E606A9688641107AEF3AB25FCC111
ZIPs in sealed evidence set: 32
ZIPs matching recorded SHA256: 32
ZIPs matching Git staged raw-byte object: 32
Git add exit: 0
Expected staged paths: 59
Actual staged paths: 59
Missing paths: 0
Unexpected paths: 0
Verification PASS: True
Original TXT files modified: NO
Previously staged plaintext removed: NO
Git commit executed: NO
Git banking authorized: NO

--- VERIFIED STAGED ZIP OBJECTS ---
a310e356f3be36dce8c40c42c7cd454925a80e5b | Evidence/CP-014/ZIP/CP014_Evidence_Preflight.txt.zip
2e9c2a52ab6d684f18c151f9cae19a5fd1855ca8 | Evidence/CP-014/ZIP/CP014_Full_Regression_Record.txt.zip
79cbf74526bfc0c6f811ee113af1d9cb054ca34c | Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip
dc870a4724ae08ecc22f9584e30b49ecf1ce2816 | Evidence/CP-014/ZIP/CP014_Git_Attributes_Amendment_Record.txt.zip
4e0d267710c12f956196a3d5ed6ada1f75586d18 | Evidence/CP-014/ZIP/CP014_Git_Attributes_Diff_Recovery.txt.zip
0581808d3a5a3204c75ea7224235c3a807ddc6a3 | Evidence/CP-014/ZIP/CP014_Git_Attributes_Recovery_Record.txt.zip
2ac1c6b3c9b3b1d1061c8b45b34fd36b07a45b12 | Evidence/CP-014/ZIP/CP014_Git_Text_Policy_Inspection.txt.zip
0460ce3e6ea383792cbd534bb4dfba231583de18 | Evidence/CP-014/ZIP/CP014_GREEN_Run_Record.txt.zip
b60a91accecc7c7e67aa6d7e9a7839ce2a24697d | Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip
39ce42f7bae0412cef05f420357d5e9409497e70 | Evidence/CP-014/ZIP/CP014_Hash_Inventory.txt.zip
5ceac0a014bcffb233e8271906b92f8bdd90daa5 | Evidence/CP-014/ZIP/CP014_Hash_Inventory_Verification.txt.zip
93dcc2358240ff84cde0eac6cc027de7d621b9bc | Evidence/CP-014/ZIP/CP014_Implementation_Record.txt.zip
bdb223bb982bced6919253bf8512856922a0a5cb | Evidence/CP-014/ZIP/CP014_Implementation_Surface.txt.zip
0bac9153ce90edf974b29a73cb8d5af8c59dda42 | Evidence/CP-014/ZIP/CP014_RED_Run_Record.txt.zip
a9f8c41c934fd173b7a020e3eca8da03e1f3e0e6 | Evidence/CP-014/ZIP/CP014_RED_Test_Output.txt.zip
c56f93c64b6bf4cde623544d582528129da17ae6 | Evidence/CP-014/ZIP/CP014_Rustfmt_Check_Output.txt.zip
3ae5253de673d3e3ed5f2b4190a4067f26491464 | Evidence/CP-014/ZIP/CP014_Rustfmt_Check_Record.txt.zip
eefd51e878c1c832f35e50866a663ada3d66e3b2 | Evidence/CP-014/ZIP/CP014_Rustfmt_Output.txt.zip
bf2e644644f6f45d4490218ea5224c7559217725 | Evidence/CP-014/ZIP/CP014_Scope_Inspection.txt.zip
83a1ecb59915044f7457ae8c1f013cf359a895f3 | Evidence/CP-014/ZIP/CP014_Scope_Lock.txt.zip
ef563010c132ff6ce42a8b69f7542c20e32ecfc2 | Evidence/CP-014/ZIP/CP014_Source_Diff.txt.zip
e67046776ce5a241cde2c188193db92252004427 | Evidence/CP-014/ZIP/CP014_Staged_Path_List.txt.zip
a46161c2583031567708955cf6d1d32628257f6c | Evidence/CP-014/ZIP/CP014_Staged_Whitespace_Check.txt.zip
c9b25e67a759a531b3fe2154d0cf9db5fc0cfafd | Evidence/CP-014/ZIP/CP014_Staging_Command_Output.txt.zip
7a5a9ad31f814516de9851e914103650c3cd19c2 | Evidence/CP-014/ZIP/CP014_Staging_Record.txt.zip
02b6b7ee3676384521be0488ee977e2d7eb3013c | Evidence/CP-014/ZIP/CP014_Test_Format_Record.txt.zip
8fa0f362ec151fc8cad538c795465bf310c0afb2 | Evidence/CP-014/ZIP/CP014_WASM_Build_Output.txt.zip
c3ecc912c39c4e90207a8aabf457d02b5d8b56a2 | Evidence/CP-014/ZIP/CP014_WASM_Build_Record.txt.zip
a0db08db8962dea3cf64b74e381d914ce090caf7 | Evidence/CP-014/ZIP/CP014_ZIP_Batch_Verification.txt.zip
fe3bd771fe521d852ac1d894bc6d2eb88ab31926 | Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Git_Add_Output.txt.zip
0a185b4321360f495ca2611bb70618dbd8a305a3 | Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Git_Record.txt.zip
7937e1f6b1ab4a6db98eca06882e5b98e7cdc288 | Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Verification.txt.zip

requirement_id,title,family,major_family,scope,source_prd_status,source_build_flag,requirement_text,implementation_state,local_verification,independent_qa,requirement_acceptance,linked_checkpoints,checkpoint_disposition,git_commits,test_evidence,implementation_notes,last_evidence_day,source_revision
PB-STOR-001,Suitcase is the complete Data Sculptor-controlled persistence surface,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Every persistent project or analytical artifact intentionally created by Data Sculptor must be written into the visible, user-controlled Suitcase. Data Sculptor must not intentionally persist user data, analytical state, scratch state, logs, recovery state, or project metadata in hidden AppData-style locations or browser-private persistence such as OPFS. Incidental browser/OS runtime caches outside Data Sculptor control are explicitly outside this contract. F-24 browser-session persistence boundary: WASM-002 must not use IndexedDB, localStorage , OPFS, another browser-private database, or an equivalent hidden Data Sculptor-controlled persistence surface to remember a Suitcase directory handle, unsaved WIP text, project truth, analytical state, or live UI preferences between application instances. A later build may deliberately define a user-visible preferences or continuity mechanism, but WASM-002 does not create one implicitly. Volatile in-memory runtime state within the current application instance is permitted.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-002,No Data Sculptor-created subfolders,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor does not create scratch/cache subfolders inside the Suitcase. Logical organization is expressed by the flat filename grammar, open metadata, Store MAP, and human-facing aliases.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-004,__DS__ is the reserved Data Sculptor governed namespace,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Every artifact that Data Sculptor creates or intentionally interprets as one of its governed artifacts must use the exact visible prefix __DS__ . The prefix identifies participation in the Data Sculptor namespace; it does not imply that the artifact is temporary, scratch-only, or automatically generated.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-001,BANKED; separate requirement acceptance not claimed,03201870b8ec68730a0c027c572db03ccd5eeaa8,Evidence/CP-001/CP001_GREEN2_Test_Output.txt; Evidence/CP-001/CP001_WASM_Build_Output.txt,"CP001: bounded lexical artifact-class recognition via reserved_artifact_class(). Five native tests passed and Rust wasm32-target library built. No content/provenance/authority validation, persistence, or complete governed artifact contract implemented.",Day063,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-005,External inputs retain their identity; Data Sculptor derivatives enter the namespace,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"An analyst or external source file must not be renamed into __DS__ merely because Data Sculptor reads, fingerprints, certifies, or references it. If Data Sculptor creates a new governed derivative—such as an explicit converted source—the new artifact enters the __DS__ namespace under its semantic class. F-26 SOURCE boundary: a Suitcase-root file whose exact filename begins with the reserved prefix __DS__ is not treated as an analyst-owned source merely because it has a CSV-like extension or CSV-like bytes. It participates in the reserved Data Sculptor namespace and must satisfy the applicable governed-artifact contract before any governed role is granted.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-002,"T-ACCEPTED, BANKED; requirement remains partial",206dcd8b76af29edcb658a0c5a2dc40d87089fe3,Evidence/CP-002/CP002_Post_Format_Test_Output.txt; Evidence/CP-002/CP002_Post_Format_WASM_Build_Output.txt; Evidence/CP-002/CP002_Hash_Inventory_Verification.txt,CP002: exact __DS__ lexical prefix recognition via has_reserved_namespace_prefix(). Six native tests and wasm32-target compilation passed. The SOURCE boundary and governed CVT validation/emission rules in this requirement are NOT implemented.,Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-006,The governed semantic artifact-class registry is explicit and stable,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The token immediately following __DS__ must be an exact three-uppercase-letter semantic artifact class. The governed class tokens currently reserved by this PRD are: Class Meaning WKO Work Order RCP Receipt DGN Diagnostic Event — reserved; not emitted by WASM-002 HLP Help Report CER Certification Evidence CVT Converted Source RID Row Identity COL Materialized Column MAP Governed MAP artifact class — Store MAP and WKO MAP profiles CAT Store Catalog — collection-level orientation index across MAP-governed Stores INV Suitcase Inventory Snapshot SCR Scratch / Structural Support RCV Recovery Artifact — reserved; not emitted by WASM-002 BRD Brand Manifest — reserved; not emitted by WASM-002 LCK Suitcase Lock — reserved for the explicit later-V1 FINGERPRINT workflow; not emitted or maintained by ordinary WASM-002 WASM-002 emission boundary. DGN , RCV , BRD , and LCK are registered/reserved classes but are not emitted by WASM-002. Registration alone does not create a producer, serialization contract, validity contract, lifecycle, or acceptance surface. A later build that activates one of these classes must define those contracts explicitly before the class becomes emitted product behavior. The class states semantic role rather than serialization format. WIP is not an artifact class; it is the editable non-executable Work Order lifecycle state. The Flight Recorder defined by W002-STOR-012 is a derived chronological view of governed RCP artifacts and is not an additional semantic artifact class. Existing class tokens must not be silently reassigned to different meanings. A new class requires an explicit PRD revision.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-001; CP-003,CP-001 banked; CP-003 T-accepted and banked; requirement remains partial,03201870b8ec68730a0c027c572db03ccd5eeaa8; 2d06f6259de93f5beaa8eb15f8f22f171127a10e,Evidence/CP-001/CP001_GREEN2_Test_Output.txt; Evidence/CP-001/CP001_WASM_Build_Output.txt; Evidence/CP-003/CP003_Post_Format_Test_Output.txt,"CP001: bounded lexical artifact-class recognition via reserved_artifact_class(). Five native tests passed and Rust wasm32-target library built. No content/provenance/authority validation, persistence, or complete governed artifact contract implemented. CP003 adds locally verified lexical distinction between the 11 emittable-class tokens and four registered-but-not-emitted tokens; full governance/producer behavior not implemented.",Day063,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-007,Serialization is orthogonal to artifact class,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Filename extensions such as .toml , .html , .csv , .bin , and .txt describe physical serialization only and must not be used as semantic artifact classes. A governed HLP serialized as .html remains an HLP, and a governed WKO serialized as .txt remains a WKO. Any future BRD serialization must obey the same class-versus-format separation, but its format is not frozen by WASM-002.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-006,"T-ACCEPTED, BANKED; full class-specific serialization and authority contracts remain open",aff54d08dcbacaa0c54d8869749344a504c5ad61,Evidence/CP-006/CP006_RED_Test_Output.txt; Evidence/CP-006/CP006_Post_Format_Test_Output.txt; Evidence/CP-006/CP006_WASM_Build_Output.txt; Evidence/CP-006/CP006_Hash_Inventory_Verification.txt; Evidence/CP-006/CP006_Precommit_Git_Review.txt,"CP006: public ArtifactFilenameTokens and extract_artifact_filename_tokens() reuse the CP004/CP005 immutable filename validator and extract semantic_class and serialization_extension as separate borrowed lexical fields. Four new tests, total 19/19 native tests post-format; wasm32-target compilation exit 0; 20-file pre-verification SHA-256 inventory independently matched. Literal unknown class and extension values preserved without registration or approval. No class-specific extension allowlist, format contract, file contents, provenance, governed publication, trust, or authority implemented. T accepted CP006 and banked commit aff54d08dcbacaa0c54d8869749344a504c5ad61; independent Claude implementation QA remains pending. This is requirement PARTIAL, not fully closed.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-008,Namespace and class do not confer authority by themselves,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Renaming an arbitrary file to resemble a __DS__ artifact must not make it authoritative. Before treating a governed artifact as valid, Data Sculptor must validate the applicable filename grammar plus the content, provenance, fingerprint, lineage, or other evidence required by that artifact's contract. F-14/F-33 publication distinction: SCR-to-final promotion under W002-STOR-023 proves only that the artifact satisfied its class-specific publication predicate. It does not manufacture broader authority. In particular, WKO alias authority still comes from the committed WKO MAP, Store authority comes from the committed Store MAP, and CAT is orientation only. Retained SCR failure evidence remains non-authoritative, and the reserved RCV class is not emitted by WASM-002. F-26 SOURCE authority: a governed CVT is eligible as a WASM-002 SOURCE only when its exact canonical CVT identity and the publication predicate governed by W002-CONV-004 and W002-STOR-023 are satisfied. Filename resemblance, a .csv extension, or copied bytes alone do not confer CVT source authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,Cross-cutting constraint recognized in CP001/CP002 scope: filenames/classes alone convey no artifact authority. This requirement is NOT claimed implemented or touched.,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-009,Unknown and known-but-not-emitted Data Sculptor classes are preserved and reported,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"If WASM-002 encounters a syntactically valid __DS__ artifact whose three-letter semantic class is not allocated in the current registry, or whose class is a registered-but-not-emitted WASM-002 class ( DGN , RCV , BRD , or LCK ), Data Sculptor must preserve the physical file unchanged. It must not trust, execute, mutate, delete, rename, or reinterpret that file as a known emitted artifact merely because the filename has governed form. Unknown class does not mean invalid data; it means this build has no authority to interpret that class. A known-but-not-emitted class is likewise not an instruction to activate a dormant producer or lifecycle. Whenever a WASM-002 operation performs the governed Suitcase scan/enumeration relevant to such a file, the condition must be surfaced through a canonical INFO diagnostic rather than being silently ignored. INVENTORY must include the physical file under its existing metadata-only contract; if an existing classification field is rendered, an unknown class is identified as unknown/unrecognized and a known-but-not-emitted class is identified as reserved/not emitted without guessing additional semantics. F-33 adds no new Inventory schema field and does not pull the governed DIR feature into WASM-002.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-003,"T-ACCEPTED, BANKED; full preservation/INFO requirement not closed",2d06f6259de93f5beaa8eb15f8f22f171127a10e,Evidence/CP-003/CP003_Post_Format_Test_Output.txt; Evidence/CP-003/CP003_WASM_Build_Output.txt; Evidence/CP-003/CP003_Hash_Inventory_Verification.txt,"CP003: token-only Rust classify_artifact_class_token() returns registered/emittable, registered/not-emitted, unallocated, malformed-reserved, or outside-reserved disposition. Three new tests (27 cases) plus six prior regression tests passed, wasm32 compilation exit 0, 15-file historic SHA-256 inventory verified. No Suitcase scan, filesystem preservation, canonical INFO diagnostic, INVENTORY integration, full filename validity, or artifact authority implemented. RegisteredEmittable describes a class category; it does not authorize emission. Independent Claude QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-010,Namespace and class casing are canonical and exact,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor-generated names must use exact uppercase __DS__ and exact uppercase three-letter class tokens. Data Sculptor must not silently normalize variant namespace/class spellings into canonical governed artifacts. This rule applies even on case-insensitive filesystems. F-15 governed comparison rule: unless a requirement explicitly defines a different domain-specific comparison, WASM-002 semantic equality and textual reference resolution compare decoded strings by exact Unicode scalar-value sequence. Data Sculptor performs no case folding, locale folding, Unicode normalization, trimming, or host-filesystem equivalence before the comparison. Thus differently cased strings and canonically equivalent-but-differently-encoded Unicode strings remain distinct governed values. If a host filesystem cannot safely publish two physical names that the governed semantics distinguish, publication must refuse rather than merge or reinterpret the governed identities.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-007; CP-009; CP-010,"T-ACCEPTED, BANKED; exact lexical construction verified; full normative requirement remains partial; CP009 T-ACCEPTED, BANKED — pure exact-name root snapshot matching only; full requirement remains partial; CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open",3c512df519f3a2431b363e4c57dc234c02378124; dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8; b7c515faa9bd000369d7656e09437310261290ae,Evidence/CP-007/CP007_RED_Test_Output.txt; Evidence/CP-007/CP007_GREEN_Test_Output.txt; Evidence/CP-007/CP007_Post_Format_Test_Output.txt; Evidence/CP-007/CP007_WASM_Build_Output.txt; Evidence/CP-007/CP007_Hash_Inventory_Verification.txt; Evidence/CP-007/CP007_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Baseline_Test_Output.txt; Evidence/CP-009/CP009_RED_Test_Output.txt; Evidence/CP-009/CP009_GREEN_Test_Output.txt; Evidence/CP-009/CP009_Full_Regression_Test_Output.txt; Evidence/CP-009/CP009_Rustfmt_Check_Output.txt; Evidence/CP-009/CP009_Git_Whitespace_Check.txt; Evidence/CP-009/CP009_Post_Format_Test_Output.txt; Evidence/CP-009/CP009_WASM_Build_Output.txt; Evidence/CP-009/CP009_Hash_Inventory.txt; Evidence/CP-009/CP009_Hash_Inventory_Verification.txt; Evidence/CP-009/CP009_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Final_Staging_Review.txt; CP009_Git_Banking_Output.txt (separately archived post-commit evidence); Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived),"CP007: public build_immutable_artifact_filename_candidate() assembles exact class, UTC timestamp, UUID v4 and serialization extension tokens into an ordinary canonical immutable filename candidate; it delegates validation to the existing CP004/CP005 envelope validator and refuses malformed casing/identities rather than case-folding, trimming or normalizing input. Four new integration tests, total 23/23 native tests after Rustfmt; wasm32-target compilation exit 0; 21-entry SHA-256+byte inventory independently verified. Lexically valid unknown class tokens and unapproved extension tokens may be preserved as candidates; this grants no registration, serialization contract, authority, filesystem publication or content/provenance validation. The F-15 exact Unicode scalar-value semantic equality and host-filesystem collision/refusal requirements are NOT implemented. T approved and banked commit 3c512df519f3a2431b363e4c57dc234c02378124 (14 files), clean master; independent Claude adversarial implementation QA pending. Requirement remains PARTIAL, not fully closed. CP009 Day066: match_analyst_csv_root_snapshot(&str, &[RootSnapshotEntry]) -> RootSnapshotMatch applies CP008 analyst CSV candidate preflight, then exact Rust string equality (case, Unicode scalar sequence and whitespace preserved), reports no match, reported nonregular entry, ambiguous duplicate exact entries, or single caller-reported regular file. Entry origin and kind are caller assertions, not independently verified. Eight new tests; post-format full native regression 36/36; wasm32-unknown-unknown library compilation exit 0; SHA-256 inventory verified 22/22; staged whitespace exit 0; T approved and git banked 15 files, clean working tree. This is NOT actual root scanning, filesystem entry proof, browser permission, CSV/UTF-8 certification, governed CVT SOURCE eligibility or end-to-end requirement acceptance; independent Claude QA pending. CP010 Day066 also tests canonical uppercase __DS__/CVT tokens and exact lowercase .csv conversion-output extension, refusing variant prefix/class/extension spellings; existing canonical validator is reused without repair or normalization. Only lexical form is locally verified: no actual filesystem identity enforcement or publication collision handling. T accepted CP010; git b7c515faa9bd000369d7656e09437310261290ae; independent QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-011,Generated identity collisions regenerate the UUID and never overwrite,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor must never overwrite, rename, truncate, or mutate an existing artifact merely because a newly generated governed filename collides with it. For an ordinary immutable artifact using the governed UTC+UUID identity grammar, Data Sculptor must keep the originally established canonical UTC millisecond creation timestamp, generate a new canonical lowercase hyphenated UUID v4, reconstruct the candidate filename, and try creation again. Collision retry must not advance or falsify the artifact creation timestamp merely to obtain a different sort position. This retry may repeat until an unused valid identity is obtained. If UUID generation fails, the host cannot safely test/create the target, or another filesystem error prevents safe allocation, creation must refuse through the canonical diagnostic path rather than risk overwrite. Collision retry changes only the not-yet-created artifact's UUID. UUID is never used as a chronology field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-012,Names route; governed contents and provenance prove,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The filename must help humans and Data Sculptor identify the artifact's intended semantic role and route it to the correct validator. The artifact's governed content, lineage, receipt, fingerprint, provenance, and other required evidence establish what is actually true.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-013,Ordinary immutable governed artifacts use class → UTC millisecond → UUID v4 identity order,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The exact default filename grammar for an ordinary immutable Data Sculptor-governed artifact is: __DS__CCC__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.<extension> CCC is the governed semantic artifact class. YYYYMMDDTHHMMSSmmmZ is the artifact's governed UTC creation/publication timestamp at millisecond precision: four-digit year, two-digit month/day/hour/minute/second, exactly three millisecond digits, and literal T / Z . <uuid-v4> is a canonical lowercase hyphenated UUID v4. The extension is governed by the artifact's serialization contract. The token order is normative: namespace, semantic class, UTC timestamp, UUID, extension. UTC precedes UUID for every ordinary immutable class. Canonical UTC tokens with different values sort chronologically within the same class. UUID provides uniqueness and physical identity only; it must not be interpreted as a chronology tie-breaker when two artifacts share the same timestamp. When one governed all-or-refuse Store-state publication transaction creates multiple new analytical state artifacts, Data Sculptor establishes one canonical UTC millisecond publication-transaction timestamp before final identity allocation and uses that same UTC token for every newly published RID , COL , and MAP artifact created by that transaction. Each artifact receives its own UUID. Thus a first Store materialization gives the new RID, every newly materialized COL, and the successor MAP one shared transaction UTC; a later materialization gives only its newly created COL artifacts and successor MAP the new transaction UTC while the inherited RID and inherited COL artifacts retain their earlier identities. The shared transaction UTC is not the Work Order's authoring timestamp and does not require the Receipt filename UTC to match. RCP remains governed by W002-RCP-002 and carries its own receipt creation/publication timestamp. A shared transaction UTC expresses common publication membership, but MAP binding—not timestamp equality—remains authoritative for Store membership/current state. Source identity, source filename, run identity, parent identity, lineage, hashes, aliases, supersession, column identity, and other relationships must not be appended as ordinary identity tokens merely to make the filename descriptive; those facts belong in governed metadata and provenance. P2-03 successor-state UTC rule: when an operation will publish a successor Store MAP or successor WKO MAP, the transaction UTC remains a truthful observation of host UTC and must be strictly greater than the applicable chronology predecessor MAP UTC. Data Sculptor must not synthesize, increment, round forward, or otherwise fabricate a later UTC merely to satisfy chronology. UUID remains identity only and is never a chronology tie-breaker. The first MAP in a genuinely new Store lineage, and the first WKO MAP when no structurally valid WKO MAP exists, has no chronology predecessor and therefore uses the observed host UTC normally.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Immutable filename envelope, UTC and UUID syntax only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. Full requirement also governs true UTC millisecond identity, creation chronology, publication timestamp sharing, UUID identity semantics, and successor MAP chronology; none are implemented in CP004. Independent QA pending. CP005: CP005 now validates the timestamp token as a real Gregorian calendar date and ordinary UTC clock time (four-digit years 0001–9999, leap years, month lengths, 00–23 hours, 00–59 minutes/seconds, millisecond precision preserved lexically). Actual UTC issuance/publication, timestamp allocation, chronological truth, common transaction timestamp and identity authority are not implemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-014,Store-state publication transactions share UTC but never UUID identity,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Within one all-or-refuse Store-state publication transaction, every newly created RID , COL , and MAP final identity must carry the exact same canonical UTC millisecond transaction token and a distinct canonical UUID v4. UUID collision retry under PB-STOR-011 changes only the affected not-yet-created artifact UUID; it must not advance or alter the shared transaction UTC. Artifacts merely inherited or referenced by the transaction are not renamed, retimestamped, or assigned replacement UUIDs. A valid MAP may therefore bind artifacts created under several earlier transaction timestamps. Timestamp equality is evidence that artifacts were newly published by the same transaction; timestamp inequality is not evidence that artifacts belong to different Stores. P2-03 publication guard: for a successor Store-state transaction, the shared transaction UTC is established from truthful observed host UTC and is checked against the Store lineage's chronology predecessor before any newly created RID/COL/MAP artifact is promoted into its final governed class. If the observed transaction UTC is less than or equal to the chronology predecessor UTC, the publication refuses; the prior current MAP remains authoritative and no successor Store state commits.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-OPS-001,Permanent row identity after materialization,PB-OPS,PB-OPS,WASM-002,UNDER REVIEW,—,"Each logical Store has exactly one visible, deterministic RID artifact representing 1..N in governed logical CSV-record order. The header is excluded. Physical line count is not row identity: embedded newlines inside quoted fields remain inside one logical record. The RID is created when the first successful materialization establishes the Store and remains stable for the life of that Store. Every same-Store materialized or later aligned result column must contain exactly N data records in the same RID order. Multiple Stores may coexist in one Suitcase, and their RID values are unrelated; the meaningful row identity is therefore the pair (Store, RID) .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-OPS-002,Materialized columns preserve facts and alignment,PB-OPS,PB-OPS,WASM-002,UNDER REVIEW,—,Materialized columns preserve governed values in permanent row alignment. Materialization stores facts for reuse; it does not decide which rows are analytically interesting.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001,Flat Project Suitcase,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,The durable WASM-002 project model must not require semantic per-store subfolders. A logical store is represented by governed relationships among artifacts and metadata inside a flat project folder.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.1,The flat model must remain usable through ordinary filesystem tools.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.2,Native and browser hosts must use the same logical storage semantics even when their filesystem APIs differ.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.3,Folder placement must not be treated as the authoritative meaning of an artifact.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-002,Reserved Core namespace and sorting,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Every Data Sculptor Core-managed artifact must use the reserved __DS__ prefix. The prefix is deliberately visually distinctive and mechanically simple so Core artifacts cluster together under ordinary filename sorting in a mixed flat folder.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003,Three-character base-26 artifact class,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The class token must be exactly three uppercase ASCII letters A through Z, giving the fixed physical range AAA through ZZZ, and must immediately follow the reserved namespace within the frozen filename grammar.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.1,The three-character alphabetic class rule supersedes every earlier numeric class example.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.2,"Class ordering is positional base-26 using the alphabet A through Z: AAA, AAB, AAC, ... AAZ, ABA, ... ZZZ.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Ordinary lexical filename sorting therefore preserves the governed class order.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.3,"The namespace contains 26 cubed, or 17,576, possible class values while preserving one fixed-width token.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.4,Unallocated class tokens remain unassigned until explicitly allocated,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"WASM-002 does not reserve semantic meaning by numeric interval, lexical neighborhood, or implied class range. Any syntactically possible three-letter token that is not listed in the governed registry is unassigned for this build. A future artifact class may be allocated only by explicit PRD revision. Existing class meanings must never be shifted, renumbered, or reassigned merely to make room for later families.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.5,The WASM-002 artifact-class table is frozen by the governed registry,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The exact WASM-002 artifact-class table is the registry in PB-STOR-006. It is no longer a separate open storage freeze item. No additional reserved class ranges are defined by WASM-002. DGN , RCV , BRD , and LCK remain registered/reserved but are not emitted by WASM-002. Their presence in the registry does not create a WASM-002 producer, serialization contract, validity contract, lifecycle, or acceptance surface. Independent adversarial review must verify that every WASM-002-generated governed artifact uses a listed class that this build actually emits, that WIP remains a lifecycle state rather than a class, and that unknown/unallocated classes plus known-but-not-emitted classes are preserved and reported under PB-STOR-009 rather than silently interpreted or activated.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-004,Canonical Core filename envelope,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The default Core physical naming model for immutable governed artifacts is __DS__<CLASS>__<UTC>__<UUID>.<ext> . CLASS, UTC, and UUID are governed identity tokens. Human semantic labels are excluded from the physical identity envelope. A separately frozen artifact contract may define a well-known current-state singleton filename when that artifact must be updated in place and discovered by a stable name.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Default immutable filename-envelope structure only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. Singleton exception support, class-specific contracts and authority remain unimplemented. Syntactic success does not imply an authorized artifact. Independent QA pending. CP005: CP005 adds Gregorian calendar/UTC-clock validity to the already recognized immutable Core physical name. Singleton filenames, artifact-type extension rules and authorization remain unimplemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005,Canonical filename shape and fixed token lengths,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Every governed Core artifact type must have a canonical filename shape and total filename length so that a parser, browser host, native host, QA tool, or LLM can recognize malformed physical identity without interpreting variable human language. Under the Revision AH default immutable grammar, the canonical UTC token YYYYMMDDTHHMMSSmmmZ is exactly 19 ASCII characters and the canonical lowercase hyphenated UUID v4 token is exactly 36 ASCII characters. Class precedes UTC and UTC precedes UUID.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Fixed core lexical UTC (19 ASCII) and UUID v4 (36 ASCII) structure only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. No calendar validation, class/extension contract mapping, class-specific total length table, or filename publication gate is claimed. Independent QA pending. CP005: CP005 strengthens the fixed 19-ASCII-character UTC token with Gregorian calendar and UTC-clock range checks. Class-specific total filename lengths, extension mapping, and publication gates remain unimplemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.1,"If an artifact class has exactly one governed representation, all filenames in that class have one frozen total length.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.2,"If a future class permits more than one representation, each class/representation pair must still have a frozen total length.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.3,"Friendly store names, column names, aliases, and operation descriptions must never stretch or shorten a Core physical filename.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-006,Physical identity versus integrity,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,UUID identifies the governed artifact instance. SHA-256 records or verifies the exact bytes. The system must not overload one field to serve both identity and integrity.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007,Collision handling,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Physical filename collisions are expected to be rare but must be handled explicitly. Data Sculptor must never silently overwrite an existing governed artifact because a generated physical name already exists.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.1,"Before durable creation, the host must check whether the target physical name already exists.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.2,"On a UUID collision, the existing artifact is preserved and a fresh UUID is generated under the same relevant UTC/class context unless a later frozen rule requires a different deterministic response.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.3,Collision handling must be visible in the run Receipt/evidence when it occurs,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If governed identity allocation encounters one or more filename collisions before successfully allocating a non-colliding UUID identity, the canonical run Receipt must record that a collision retry occurred and the number of retries when the run reaches receipt publication. If identity allocation ultimately refuses, the refusal Receipt and diagnostic evidence must preserve the collision-failure fact without overwriting or mutating any pre-existing artifact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-008,Analyst-owned files remain analyst-owned,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Source files and analyst documents may retain their original filenames. Data Sculptor must not rename every input merely to fit the governed __DS__ namespace. For an ordinary WASM-002 analytical run, continuity between certification and materialization is established by the run-local source-binding contract, not by pretending a mutable source filename is permanent byte identity. Durable cross-run exact-byte verification requires separately governed integrity evidence such as the later V1 FINGERPRINT operation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-009,Store MAP as machine truth,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The Store MAP must provide the machine-readable relationship between governed physical artifacts and their logical meaning, including the fields required by the frozen schema for store identity, column identity, source reference/binding, run/materialization identity, row counts, status, lineage, supersession, and related provenance. Cryptographic hashes are recorded when a requirement or explicit operation actually produces them; the Store MAP contract must not imply that every source or artifact is automatically hashed during ordinary WASM-002 execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010,Aliases provide human orientation without a separate Store Index,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, human-facing orientation is provided by aliases exposed from governed Store MAP state and related governed artifacts. Aliases may help analysts navigate by meaning while preserving exact physical identities. WASM-002 does not publish or maintain a separate Store Index artifact. Richer directory/index presentation is carried by the governed DIR surface in WASM-003.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010.1,WASM-002 Store MAP profile is the unified Store metadata snapshot,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, the Store MAP profile of the governed MAP artifact class is the Store metadata snapshot. It records the Store's human-facing alias, Store-establishing source filename, exact RID artifact binding, RID alias, and the complete current materialized-column mappings and aliases governed by W002-STOR-019 through W002-STOR-019.12. WASM-002 must not create a second hidden or separately named Store-metadata file merely to bind the Store to its RID or aliases. The visible immutable __DS__MAP__...csv artifact is the authoritative governed Store MAP for this build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010.2,"Changing a friendly alias must not change physical identity, hashes, lineage, or historical provenance.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-011,"Store, row-universe, and future Boolean-selection-column rule",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Same-row derived columns and later aligned Boolean selection/filter columns remain within the same logical Store when row identity, row order, and cardinality are preserved. A future filter that evaluates every existing RID and writes one aligned two-valued Boolean result per RID does not by itself create a new row universe or a new logical Store. The canonical future selection tokens are 0 for FALSE and 1 for TRUE under PB-OPS-003 and PB-OPS-003.1. A new row universe is created only when a later governed operation actually changes which rows exist or their order—for example by building/exporting only selected rows, deduplicating rows, or otherwise materializing a different row set. Such an operation creates a new logical Store identity under the frozen row-identity contract. Filtering remains deferred from executable WASM-002 scope; this requirement freezes only the Store/RID compatibility rule that later filtering will rely upon.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-012,Current orientation and history are different truths,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Current Store orientation is represented by the applicable immutable MAP snapshot, while execution history is preserved by immutable RCP Receipts. For WASM-002, the Flight Recorder is the logical chronological view of published canonical RCP artifacts from actual Run invocations of saved immutable WKO Work Orders. It is not separately persisted and has no separate artifact class. Successful and refused runs contribute when Receipt publication succeeds; Receipt-publication failure is governed by W002-RCP-010 and must not be silently reconstructed as original evidence. Any Flight Recorder presentation is derived and regenerable from the authoritative Receipts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-013,Open representations,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Durable project artifacts should use documented open formats such as CSV, HTML, TXT, TOML, or other explicitly governed representations so that the Suitcase remains inspectable and portable outside Data Sculptor.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-014,LLM-readable storage grammar is a documentation principle,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The storage grammar, class table, Store MAP schema, current-state selection rule, and alias semantics must be documented clearly enough that an LLM collaborator can distinguish physical identity, logical meaning, integrity evidence, current state, and history without guessing. This is a documentation/readability principle for the Product Backlog PRD and related public product documentation. It does not create a new governed Suitcase artifact, require a new public-documentation file or publication operation, or add a separate WASM-002 acceptance deliverable beyond keeping the governing contract explicit and internally consistent.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-015,WASM-002 storage freeze status,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The current WASM-002 storage design preserves the resolved semantic artifact-class registry, canonical UTC millisecond rendering, class → UTC → UUID token order, UUID rendering/version, default immutable identity grammar, collision retry behavior, immutable one-Store-per-MAP versioning, Store-aware automatic MAP inheritance, complete-snapshot semantics, the exact eight-column Store MAP schema, deterministic Store/RID/COL alias defaults, rematerialization alias continuity, deterministic Store-MAP CSV serialization, Store-MAP eligibility/publication validation, materialization-coupled AS alias semantics, standalone alias maintenance using UPDATE ALIASES , explicit alias clearing with CLEAR ... ALIAS , deterministic default restoration with RESET ... ALIAS , exact historical Store-MAP selection using MAP ""<exact Store MAP filename>"" , canonical one-column COL serialization, the all-or-refuse materialization publication boundary, SCR -to-final-class host rename promotion, complete-set validation before promotion, new-Store RID-first promotion, inherited-RID reuse for existing-Store work, deterministic COL promotion, successor-MAP construction/validation as SCR , successor-MAP rename last as the Store-state commit point, rollback/recovery treatment for uncommitted promoted artifacts, the canonical RID CSV contract, the seven-operation Work Order execution surface, the canonical automatic TXT Receipt contract including exact WKO lineage, the Receipt-backed Flight Recorder, the governed HTML Suitcase Validation Certificate, the Work Order alias/comment contract plus WKO-MAP alias-registry profile, and the LCK reservation for explicit later-V1 FINGERPRINT evidence without automatic hashing in ordinary WASM-002. RID reconstruction/replacement is deliberately not part of the WASM-002 executable surface; RECOVER RID requirements are deferred to V1-BACKLOG. The Help-report provenance boundary is resolved: WASM-002 records governed HLP identity and lineage but does not automatically SHA-256 HLP bytes or create/refresh LCK evidence; exact-byte HLP integrity remains the later explicit FINGERPRINT/LCK workflow. Future branded Receipt rendering/Brand-Manifest integration remains outside the WASM-002 TXT-only Receipt contract. P2-04 closure: WASM-002 Store governance now has a complete two-tier artifact-validation model. Tier 1 supplies bounded Store-health checks for non-content-consuming paths; Tier 2 supplies full streaming RID/COL validation for content-consuming paths, candidate commit, and REPAIR MAP . The eight-column Store MAP remains unchanged and ordinary Store health makes no cryptographic claim of historical-byte identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-001,Every actual Run invocation of a saved WKO automatically produces one Receipt attempt,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"When the analyst invokes Run on a saved immutable WKO, Data Sculptor must automatically create one governed run-receipt attempt for that invocation. The Work Order must not require a RECEIPT , SAVE RECEIPT , or equivalent clause. An editable unsaved WIP is non-executable under the Work Order lifecycle contract and therefore cannot produce an execution Receipt. A saved WKO that is invoked and then refuses during validation or execution still has an execution outcome and must receive a refusal Receipt when receipt publication succeeds.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-002,The canonical WASM-002 Receipt is a governed TXT artifact with its own creation timestamp,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,The physical Receipt filename is: __DS__RCP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt The UTC token belongs to the Receipt artifact itself and represents the Receipt's governed creation/publication time under the canonical artifact-identity rules. It must not be copied from the authorizing WKO's filename merely to make the two filenames share a timestamp. The file is written visibly in the flat Suitcase under the governed RCP artifact class. Data Sculptor chooses the governed filename; the analyst does not supply it.,PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-014,"CP014 T-ACCEPTED, GIT BANKED — canonical RCP TXT filename lexical recognizer only; own creation-time allocation, file emission, complete Receipt contract and publication unimplemented",f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,Evidence/CP-014/ZIP/CP014_RED_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_WASM_Build_Record.txt.zip; CP014_Git_Banking_Record.txt (external closeout),"CP014 Day067: T-accepted, Git-banked lexical RCP .txt filename recognizer only. Pure is_canonical_rcp_filename_candidate(&str)->bool uses shared canonical envelope, rejects wrong class/extension/casing, malformed UTC/UUID, paths and whitespace. Six target GREEN passes; 64/64 native regression; Rustfmt and wasm32 library build PASS; 32 original-TXT-per-ZIP objects validated and committed unchanged. Commit f5038a183f1d3dc31b0065571bf8ac8814b5d8a9. No new Receipt timestamp generation, Receipt byte serialization, creation/promotion/publication or authority; independent implementation QA and browser runtime pending.",Day067,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-003,WASM-002 Receipts are TXT-only and independent of presentation state,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"For WASM-002, the canonical run Receipt is always plain TXT. Browser theme, built-in HTML presentation, Help voice, or other presentation state must not change whether the run Receipt is emitted as TXT or alter its governed facts. WASM-002 must not emit an HTML Receipt as an alternative to the canonical TXT Receipt. Configurable Brand Manifest behavior is deferred to a future build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-005,Canonical Receipt TXT serialization is deterministic,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The WASM-002 Receipt is UTF-8 without BOM and uses LF ( 0x0A ) line endings. Every Receipt ends with exactly one final LF. No serialized line carries trailing spaces, and no blank physical lines are emitted unless a later operation-specific grammar explicitly freezes them. It is a deterministic line-oriented KEY: VALUE document with a frozen core-key order followed by operation-specific fact sections in deterministic order. KEY is an uppercase ASCII field name. The separator is exactly one ASCII colon followed by exactly one ASCII space. KEY=VALUE is not valid canonical Receipt serialization. Fixed machine tokens and non-negative decimal integers are serialized unquoted. Human-authored text, filenames, aliases, headers, and other free text are serialized as double-quoted UTF-8 strings. Inside a quoted value, a literal double quote is represented by doubling it as """" . CR and LF are not permitted inside a single serialized value; each fact remains exactly one physical line. Enumerated values use the exact uppercase tokens frozen by the applicable requirement. Non-negative integers use ungrouped ASCII base-10 digits. This shared text rule is normative for all Receipt free-text values and is acceptance-tested byte-for-byte.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-006,Every Receipt records the fixed core execution facts and exact WKO lineage,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"Every canonical WASM-002 Receipt begins with the following common envelope keys in exactly this order: RECEIPT_VERSION RECEIPT_FILENAME RECEIPT_UTC WORK_ORDER_FILENAME OPERATION RUN_STARTED_UTC RUN_FINISHED_UTC RESULT DIAGNOSTIC_ID IDENTITY_COLLISION_RETRIES Day 060 H-02 version freeze: RECEIPT_VERSION is the unquoted integer 1 for the WASM-002 Receipt contract. RECEIPT_FILENAME is the exact physical governed RCP filename. RECEIPT_UTC is exactly the canonical UTC timestamp embedded in that filename and is distinct from the run start/finish timestamps. WORK_ORDER_FILENAME is the exact physical immutable WKO identity invoked and is the authoritative WKO→RCP lineage link. Day 060 H-09 / BM-06 truthful run-timestamp semantics RUN_STARTED_UTC and RUN_FINISHED_UTC are governed truthful host-UTC observations at millisecond precision. They are not decorative labels and are not synthesized from artifact filenames. RUN_STARTED_UTC is observed only after the exact saved WKO has been resolved and found eligible to Run, and immediately before operation-specific validation/execution begins. It therefore brackets operation validation, analytical work, publication attempts, refusal processing, and any governed rollback/cleanup performed by that Run. RUN_FINISHED_UTC is observed only after the operation has reached its final SUCCESS or REFUSED analytical outcome and all non-Receipt governed effects are settled: successful artifacts are committed, refusal state is established, and required rollback/cleanup or retained non-authoritative evidence classification is complete. Receipt publication begins only after this observation. For one Run, the truthful temporal invariant is: WKO_UTC ≤ RUN_STARTED_UTC ≤ each successfully published run-artifact UTC ≤ RUN_FINISHED_UTC ≤ RECEIPT_UTC where WKO_UTC is the governed UTC token embedded in the exact WORK_ORDER_FILENAME , and “run-artifact UTC” means the governed UTC embedded in each non-Receipt artifact successfully published by that Run, including a shared materialization transaction UTC where applicable. An operation that publishes no non-Receipt artifact simply has no middle artifact-UTC comparison. Equality is permitted because the canonical timestamp precision is milliseconds. Data Sculptor must not fabricate, increment, decrement, or reorder UTC values merely to make this invariant appear true. Receipt fixtures and retained acceptance evidence must use physically possible timelines under this rule. The existing rule that WKO and Receipt filename timestamps are not required to match remains unchanged: they are distinct events, but a WKO invoked by a Run must already exist as a governed artifact before that Run begins. RESULT is a closed WASM-002 vocabulary containing exactly SUCCESS and REFUSED . No other RESULT token is valid. DIAGNOSTIC_ID: NONE is used for an ordinary successful run; a refused run carries the exact governed diagnostic identity. The shared governed absence-state vocabulary is closed to these four tokens, with these exact meanings: NONE — the fact is applicable and definitively has no value in this event; NOT_RUN — the owning stage or operation was not executed; NOT_AVAILABLE — the fact is applicable or potentially applicable, but its value could not be obtained; NOT_APPLICABLE — the fact does not apply to this event, diagnostic, operation, or artifact. These states are semantically distinct and must not be substituted for one another. A count that was actually established as zero is serialized as the integer 0 , never as an absence token. The refusal-serialization matrix for every present operation-specific key is deterministic: State of the key's owning fact/stage at refusal Required serialization The fact was authoritatively established before refusal Serialize the exact governed value. The owning stage was never entered NOT_RUN . The owning stage ran and definitively produced no value/artifact for this event NONE . The fact applies but could not be obtained NOT_AVAILABLE . The fact does not apply to this event NOT_APPLICABLE . An applicable count was authoritatively established as zero 0 . A publication identity whose publication stage was never entered NOT_RUN , except where an earlier frozen operation-specific rule explicitly fixes another token. A publication identity whose publication stage was entered but no artifact of that identity successfully published NONE . A publication identity that successfully published The exact physical governed filename. For this contract, a fact is established only when its owning validation/stage has deterministically fixed the value and later execution cannot revise that fact. Candidate allocation, partial bytes, or an uncommitted publication does not establish a published-artifact identity. If parsing/validation refuses before one of the seven governed WASM-002 operations can be identified, the Receipt uses OPERATION: UNKNOWN_OPERATION , RESULT: REFUSED , and the applicable DIAGNOSTIC_ID . After the common envelope there is no operation-specific section; the Receipt proceeds directly to CREATED_ARTIFACT_COUNT: 0 . UNKNOWN_OPERATION is not an executable operation. After all operation-specific facts and indexed lists, every Receipt ends with: CREATED_ARTIFACT_COUNT: <N>
CREATED_ARTIFACT_001: ""...""
...
CREATED_ARTIFACT_N: ""..."" The created-artifact list contains only exact physical governed filenames successfully published by the run, excluding the Receipt itself. For this accounting, an artifact is successfully published only if it remains a committed governed artifact when the Run finishes; an artifact promoted and then rolled back, or left only as non-authoritative failure residue under All-or-Refuse, is excluded from CREATED_ARTIFACT_COUNT and its indexed list. Indexed suffixes are one-based decimal with a minimum width of three digits and no maximum width: 001 through 999 are zero-padded and 1000 onward uses the ordinary full ungrouped decimal form. When a count is zero, no indexed lines for that list appear. IDENTITY_COLLISION_RETRIES is always present and is 0 when no governed filename-allocation retry occurred. Receipt/WKO filename timestamps are not required to match. One immutable WKO may be run multiple times, each producing a distinct Receipt that points back to the same exact WORK_ORDER_FILENAME . F-08 DS-STEPS / Receipt token separation. Human-authored Work Orders use the readable terminal clauses below; the Receipt serializes the corresponding machine token in OPERATION . The two columns are not interchangeable spellings: DS-STEPS terminal clause Receipt OPERATION MATERIALIZE MATERIALIZE INVENTORY INVENTORY UPDATE ALIASES UPDATE_ALIASES REPAIR MAP REPAIR_MAP REPAIR WORK ORDER REGISTRY REPAIR_WORK_ORDER_REGISTRY CONVERT WINDOWS-1252 TO UTF-8 CONVERT_WINDOWS_1252_TO_UTF_8 CATALOG STORES CATALOG_STORES For example, REPAIR_MAP is not valid DS-STEPS syntax and REPAIR MAP is not the serialized Receipt token. UNKNOWN_OPERATION remains a refusal-only Receipt value when validation cannot identify one of these seven operations; it is not an executable operation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-007,"Materialization Receipts record Store, RID, Stage 1, Stage 2, and output facts",W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"For a WASM-002 MATERIALIZE run, after the common envelope the Receipt serializes these operation-specific keys in exactly this order: SOURCE_FILENAME BASE_MAP_FILENAME RID_FILENAME RID_ACTION STAGE1_UTF8_OUTCOME CERTIFIED_SOURCE_BYTE_COUNT STAGE1_ELAPSED_MS UTF8_FIRST_INVALID_BYTE_OFFSET UTF8_STOP_REASON WINDOWS_1252_COMPATIBILITY_OUTCOME WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET STAGE2_LOGICAL_ROW_COUNT STAGE2_ELAPSED_MS CSV_REFUSAL_CONDITION CSV_SOURCE_BYTE_OFFSET CSV_PHYSICAL_LINE CSV_LOGICAL_RECORD CSV_FIELD_ORDINAL REQUESTED_COLUMN_COUNT RESOLVED_COLUMN_COUNT PUBLISHED_COL_COUNT zero or more indexed published-COL filename lines whose exact key form is PUBLISHED_COL_<INDEX>_FILENAME (for example PUBLISHED_COL_001_FILENAME , PUBLISHED_COL_002_FILENAME ) SUCCESSOR_MAP_FILENAME OPERATIONAL_NAME_FALLBACK_COUNT zero or more indexed fallback triplets: OPERATIONAL_NAME_FALLBACK_001_COLUMN_ORDINAL , OPERATIONAL_NAME_FALLBACK_001_ASSIGNED_NAME , OPERATIONAL_NAME_FALLBACK_001_REASON , continuing under the common indexed-key rule. BASE_MAP_FILENAME: NONE denotes a newly established Store with no predecessor Store MAP. Day 060 H-11 / BM-08 RID_ACTION ownership and establishment RID_ACTION is a governed execution fact describing what this Run actually established for the Store RID path. It is never an intention, plan, or prediction. RID_ACTION: REUSED is established when routing has selected an existing Store, the exact inherited RID filename is known, and that inherited RID has passed the validation required to proceed. Because the RID already exists, this fact may be established before Stage 1 or Stage 2 completes. RID_ACTION: CREATED is established only when a new-Store RID candidate has successfully completed governed promotion into its final RID identity. Merely planning, allocating, writing, closing, validating, or naming an SCR candidate does not establish CREATED . Until either of those facts is established, the common refusal matrix governs RID_ACTION . For a new-Store path that refuses before successful RID promotion, RID_ACTION is NOT_RUN . If an existing-Store route is identified but the required inherited RID fact cannot be validly established, RID_ACTION is NOT_AVAILABLE . RID_FILENAME is a separate fact: for REUSED , it is the exact already-published inherited RID filename as soon as reuse is established; for CREATED , it is the exact governed final RID filename only after successful RID promotion; before new-RID promotion succeeds, no candidate/SCR filename may be serialized as though it were a published RID. With RID_ACTION: CREATED , RID_FILENAME records the RID identity successfully promoted during the Run even if that RID is later rolled back under All-or-Refuse; rollback does not erase the already-established RID_ACTION / RID_FILENAME execution facts. The refusal-boundary matrix is therefore: Materialization state RID_ACTION RID_FILENAME Validation/routing refuses before a Store/RID path is established NOT_RUN NOT_RUN or NOT_AVAILABLE only when an applicable routing fact could not be obtained under the common matrix New Store; Stage 1 refusal NOT_RUN NOT_RUN New Store; Stage 2 refusal NOT_RUN NOT_RUN New Store; post-Stage-2 gate refusal before RID promotion NOT_RUN NOT_RUN New Store; RID candidate/promotion has not successfully completed NOT_RUN NOT_RUN New Store; RID promotion succeeds CREATED exact published RID filename Existing Store; exact inherited RID selected and validated REUSED exact inherited RID filename Existing Store; later Stage 1, Stage 2, gate, or publication refusal after reuse was established REUSED exact inherited RID filename Existing lineage identified but required inherited RID cannot be validly established NOT_AVAILABLE NOT_AVAILABLE A refusal Receipt that says RID_ACTION: CREATED while RID_FILENAME is NONE or NOT_RUN and no RID was successfully promoted is invalid evidence. STAGE1_UTF8_OUTCOME has exactly two completed Stage-1 values: PASS and FAIL . If Stage 1 never ran, the value is NOT_RUN . If Stage 1 began but a separate failure prevented a governed PASS/FAIL determination, the value is NOT_AVAILABLE . NOT_APPLICABLE is not valid for this key. UTF8_FIRST_INVALID_BYTE_OFFSET and UTF8_STOP_REASON are refusal-only Stage-1 evidence. On STAGE1_UTF8_OUTCOME: FAIL , the offset is mandatory and is the exact zero-based absolute physical source-byte offset of the first byte of the invalid sequence, and the stop reason is mandatory and exactly INVALID_UTF8_SEQUENCE . Neither field may be NOT_AVAILABLE when the Stage-1 outcome is FAIL . On PASS , both fields are NOT_APPLICABLE . If Stage 1 never ran, both are NOT_RUN . If Stage 1 began but no UTF-8 PASS/FAIL conclusion was established because of a separate failure, both refusal-only fields are NOT_APPLICABLE . WINDOWS_1252_COMPATIBILITY_OUTCOME and WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET are the governed F-16 follow-on facts. They are evaluated only after STAGE1_UTF8_OUTCOME: FAIL . When the complete second pass reaches EOF with every byte mappable, the outcome is COMPATIBLE and the offset is NOT_APPLICABLE . When the pass encounters one of the undefined bytes frozen in W002-CONV-002.4, the outcome is INCOMPATIBLE and the offset is the exact zero-based absolute physical source-byte offset of the first such byte. If the pass begins but an independent failure prevents a conclusion, both fields are NOT_AVAILABLE . If Stage 1 did not conclude FAIL , the compatibility pass does not run and both fields are NOT_RUN . The five exact CSV refusal keys CSV_REFUSAL_CONDITION , CSV_SOURCE_BYTE_OFFSET , CSV_PHYSICAL_LINE , CSV_LOGICAL_RECORD , and CSV_FIELD_ORDINAL carry the exact structural CSV refusal condition and location oracle frozen in W002-MAT-002.8. If Stage 2 never ran, all five are NOT_RUN ; if Stage 2 completed without an applicable CSV refusal, all five are NOT_APPLICABLE ; on a CSV refusal, each established location fact is serialized and any applicable fact that could not be obtained is NOT_AVAILABLE . The MATERIALIZE refusal-stage matrix is: Refusal boundary Validation/routing and request facts Stage 1 facts Stage 2 facts Publication facts Validation, before Stage 1 Serialize each fact already established; an applicable fact that validation could not obtain is NOT_AVAILABLE . REQUESTED_COLUMN_COUNT is the actual count when the KEEP list parsed completely; otherwise NOT_AVAILABLE . RESOLVED_COLUMN_COUNT and fallback records are NOT_RUN until name/ordinal resolution has run. NOT_RUN for all Stage 1-owned facts. NOT_RUN for all Stage 2-owned facts. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Stage 1 refusal Established validation/routing facts are exact values. Serialize the exact Stage 1 outcome/timing and established refusal evidence; incomplete applicable facts are NOT_AVAILABLE . The Windows-1252 compatibility fields then serialize the exact complete assessment result under the rule above; if an independent assessment failure prevents a conclusion, they are NOT_AVAILABLE . NOT_RUN for all Stage 2-owned facts. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Stage 2 refusal Established validation/routing facts are exact values. Completed Stage 1 facts are exact values; UTF-8 refusal fields are NOT_APPLICABLE when no UTF-8 refusal occurred. Because Stage 1 passed, both Windows-1252 compatibility fields are NOT_RUN . STAGE2_ELAPSED_MS is the actual elapsed time when obtained; STAGE2_LOGICAL_ROW_COUNT is NOT_AVAILABLE unless the complete accepted logical row count was established; CSV refusal facts follow the rule above. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Post-Stage-2 gate refusal before publication All facts established through the gate are serialized exactly; non-applicable UTF-8/CSV refusal fields are NOT_APPLICABLE . Both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Publication refusal before the successor-MAP publication stage is entered All facts established before refusal are serialized exactly. This row includes a new-Store RID/COL identity-allocation or promotion refusal that occurs before the successor-MAP publication stage is entered. Completed Stage 1 and Stage 2 facts remain exact; non-applicable UTF-8/CSV refusal fields use their governed absence tokens, and both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. Under All-or-Refuse publication, PUBLISHED_COL_COUNT: 0 and no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN because the successor-MAP publication stage was never entered. A candidate filename is never serialized as a published identity. Publication refusal after the successor-MAP publication stage is entered All facts established before refusal are serialized exactly. Any RID fact already established before this later refusal remains governed by the RID_ACTION/RID_FILENAME matrix above. Completed Stage 1 and Stage 2 facts remain exact; non-applicable UTF-8/CSV refusal fields use their governed absence tokens, and both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. Under All-or-Refuse publication, PUBLISHED_COL_COUNT: 0 and no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NONE because the successor-MAP publication stage was entered but no successor MAP successfully published. A candidate filename is never serialized as a published identity. Success All applicable facts are exact values; refusal-only UTF-8/CSV fields are NOT_APPLICABLE . Both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. PUBLISHED_COL_COUNT is the actual count; indexed keys are exactly PUBLISHED_COL_001_FILENAME onward in resolved KEEP order; SUCCESSOR_MAP_FILENAME is the exact published successor MAP filename. Day 060 H-24 / BM-08 publication-boundary split: these two MATERIALIZE publication-refusal rows apply the common W002-RCP-006 ownership rule to the successor-MAP publication stage. NOT_RUN means that stage was never entered; NONE means it was entered but no successor MAP successfully published. The early boundary is exercised by the RID identity-allocation exhaustion fixture; the later boundary has its own byte-exact golden fixture. OPERATIONAL_NAME_FALLBACK_COUNT is NOT_RUN until operational-name resolution has run; afterward it is the established non-negative count, including literal 0 . Fallback records are ordered by ascending physical source-column ordinal. the exact fallback key OPERATIONAL_NAME_FALLBACK_<INDEX>_REASON is exactly SOURCE_HEADER_EXCEEDS_1024_SCALARS . For successful Store-establishing materialization, the common created-artifact list is ordered RID first, newly published COLs in resolved KEEP order, then successor MAP. For successful existing-Store materialization, the inherited RID is not newly created; the list contains newly published COLs in resolved KEEP order followed by the successor MAP. P3-09 Receipt oracle: when Stage 2 refuses because the certified source contains no logical CSV record, the five CSV refusal fields must serialize exactly as CSV_REFUSAL_CONDITION: NO_HEADER_RECORD , CSV_SOURCE_BYTE_OFFSET: <exact source byte length> , CSV_PHYSICAL_LINE: 1 , CSV_LOGICAL_RECORD: 1 , and CSV_FIELD_ORDINAL: 1 . Day 060 H-13 / BM-10 clarification: within those five governed CSV refusal fields, the zero-byte and UTF-8-BOM-only cases differ only in CSV_SOURCE_BYTE_OFFSET : 0 versus 3 . Their complete Receipt bytes also differ wherever the underlying source identity, certified source byte count, Work Order identity, run/Receipt timestamps, Receipt filename/UUID, or other fixture-specific governed facts differ. The complete Receipts must never be described as differing only by one field. F-20 operational-name Receipt oracle: OPERATIONAL_NAME_FALLBACK_COUNT counts selected/materialized columns whose exact source header exceeded 1,024 Unicode scalar values. Each corresponding ..._ASSIGNED_NAME stores the final deterministic operational/default-alias name after any permitted fallback collision disambiguation; ..._REASON remains exactly SOURCE_HEADER_EXCEEDS_1024_SCALARS . The Receipt does not copy the oversized exact source header merely to explain the fallback. The common indexed-key rule from W002-RCP-006 applies without a maximum width. A full-width KEEP is therefore representable through PUBLISHED_COL_16384_FILENAME (and corresponding fallback indexes when applicable); the three-digit examples are a minimum-width convention, not a 999-item ceiling.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-008,Other WASM-002 operations add deterministic operation-specific Receipt facts,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The same common envelope, closed RESULT/absence vocabulary, refusal matrix, created-artifact tail, and indexed-key rule apply to the other executable WASM-002 operations. Their operation-specific key tables are closed as follows. INVENTORY INVENTORY_FILENAME INVENTORY_ENTRY_COUNT Refusal boundary INVENTORY_ENTRY_COUNT INVENTORY_FILENAME Validation before inventory scan NOT_RUN NOT_RUN Inventory scan/measurement refusal Exact count if the complete count was established; otherwise NOT_AVAILABLE NOT_RUN Publication refusal after the snapshot facts were established Exact established count, including 0 NONE Success Exact established count Exact physical published INV filename UPDATE_ALIASES BASE_MAP_FILENAME SUCCESSOR_MAP_FILENAME Refusal boundary BASE_MAP_FILENAME SUCCESSOR_MAP_FILENAME Validation/routing before an exact base MAP is established NOT_AVAILABLE NOT_RUN Validation/gate refusal after the exact base MAP is established Exact base MAP filename NOT_RUN Publication refusal Exact base MAP filename NONE Success Exact base MAP filename Exact published successor MAP filename REPAIR_MAP TARGET_MAP_FILENAME RID_FILENAME BROKEN_COL_COUNT zero or more indexed broken-COL filename lines using exact key form BROKEN_COL_<INDEX>_FILENAME (for example BROKEN_COL_001_FILENAME , BROKEN_COL_002_FILENAME ) RETAINED_COL_COUNT SUCCESSOR_MAP_FILENAME Broken COL filenames are ordered by ascending exact UTF-8 filename bytes. RETAINED_COL_COUNT is the actual count once repair analysis completes, including literal 0 . Refusal boundary Target/RID facts Broken/retained facts SUCCESSOR_MAP_FILENAME Validation before an exact target MAP/RID is established Established facts are exact; otherwise NOT_AVAILABLE NOT_RUN NOT_RUN Repair-analysis refusal before a repair result is established Exact established values Exact values if established; otherwise the applicable unavailable/not-run token from the common matrix NOT_RUN All-COLs-broken refusal frozen under F-03/F-09 Exact values Exact broken count/list; RETAINED_COL_COUNT: 0 NONE — this earlier frozen named refusal remains an explicit operation-specific exception. Publication refusal Exact values Exact repair-analysis values NONE Success Exact values Exact repair-analysis values Exact published successor MAP filename REPAIR_WORK_ORDER_REGISTRY BASE_WKO_MAP_FILENAME REMOVED_STALE_ROW_COUNT zero or more indexed stale-WKO filename lines using exact key form REMOVED_STALE_WKO_<INDEX>_FILENAME (for example REMOVED_STALE_WKO_001_FILENAME , REMOVED_STALE_WKO_002_FILENAME ) REGISTERED_CURRENT_COUNT zero or more indexed current-WKO filename lines using exact key form REGISTERED_CURRENT_WKO_<INDEX>_FILENAME (for example REGISTERED_CURRENT_WKO_001_FILENAME , REGISTERED_CURRENT_WKO_002_FILENAME ) REGISTERED_DEPRECATED_COUNT zero or more indexed deprecated-WKO filename lines using exact key form REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME (for example REGISTERED_DEPRECATED_WKO_001_FILENAME , REGISTERED_DEPRECATED_WKO_002_FILENAME ) SUCCESSOR_WKO_MAP_FILENAME Each filename list is independently sorted by ascending exact UTF-8 filename bytes. If the bootstrap repair WKO is newly discovered and registered, it appears in the appropriate registered list under W002-STOR-018.3 and W002-STOR-018.4. Day 060 H-10 / BM-07 count semantics: REGISTERED_CURRENT_COUNT and REGISTERED_DEPRECATED_COUNT count only previously unregistered structurally valid WKOs that this repair Run newly adds to the successor WKO MAP with the stated status. They do not count surviving pre-existing rows already present in the base registry. The indexed filename lines list exactly the corresponding newly registered WKOs and no others. If the bootstrap repair WKO is one of those newly registered WKOs, it must appear in exactly one registered list. A successful repair Receipt that omits a newly registered bootstrap repair WKO is invalid evidence. Refusal boundary Base registry Repair-plan counts/lists SUCCESSOR_WKO_MAP_FILENAME Validation before the current structurally valid WKO MAP is established NOT_AVAILABLE NOT_RUN NOT_RUN Repair-analysis/gate refusal Exact base WKO MAP filename Exact values if the repair plan was established; otherwise the common matrix governs each present field NOT_RUN Publication refusal Exact base WKO MAP filename Exact established repair-plan values NONE Success Exact base WKO MAP filename Exact established repair-plan values Exact published successor WKO MAP filename CONVERT_WINDOWS_1252_TO_UTF_8 SOURCE_FILENAME SOURCE_ENCODING UNDEFINED_WINDOWS_1252_BYTE_OFFSET MATERIALIZED_ENCODING TRANSCODING SOURCE_CHANGED OUTPUT_FILENAME UNDEFINED_WINDOWS_1252_BYTE_OFFSET is the zero-based absolute physical source-byte offset of the first byte undefined by the frozen Windows-1252 mapping when that refusal occurs. If the compatibility stage never ran it is NOT_RUN ; if the stage ran and no undefined-byte refusal occurred it is NOT_APPLICABLE ; if the fact applies but could not be obtained it is NOT_AVAILABLE . Day 060 H-14 / BM-11 undefined-Windows-1252-byte refusal oracle For CONVERT WINDOWS-1252 TO UTF-8 , an undefined Windows-1252 byte is detected during the complete pre-transcoding compatibility assessment . Transcoding has not begun when this refusal is established. When the complete compatibility assessment encounters the first undefined byte, the Receipt must serialize these exact operation facts: SOURCE_ENCODING: WINDOWS-1252-INCOMPATIBLE
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: <exact zero-based absolute physical source-byte offset>
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE WINDOWS-1252-INCOMPATIBLE is the exact SOURCE_ENCODING token for this governed CONVERT refusal. OUTPUT_FILENAME: NONE means the operation definitively established that no CVT was published for the event. No CVT candidate may be reported as output. The compatibility scan reports the first undefined byte only. Later undefined bytes do not replace that offset. Permitted changes in scan buffer/window size or boundary placement must not change the reported absolute offset. Day 060 H-25 / BM-04 already-valid-UTF-8 refusal oracle. If the complete bound source passes strict UTF-8 validation, CONVERT refuses as unnecessary before Windows-1252 compatibility assessment or transcoding. The Receipt must serialize these exact operation facts: SOURCE_ENCODING: UTF-8
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: NOT_RUN
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE UTF-8 is the exact SOURCE_ENCODING token for this governed refusal. OUTPUT_FILENAME: NONE means the classification gate definitively established that this event publishes no CVT. The Windows-1252 compatibility stage is not entered. Refusal boundary Source/classification facts Conversion facts OUTPUT_FILENAME Validation/classification refusal before conversion begins Serialize each fact already established; an applicable fact that could not be obtained is NOT_AVAILABLE . The undefined-byte offset follows the rule above. MATERIALIZED_ENCODING and TRANSCODING are NOT_RUN when conversion did not run. SOURCE_CHANGED is the exact governed value once established. NONE only for either of the two definitively classified no-CVT cases: (1) the complete source is already valid strict UTF-8 and conversion is unnecessary; or (2) the complete Windows-1252 compatibility assessment finds an undefined byte. For other validation/classification refusals before conversion begins, OUTPUT_FILENAME: NOT_RUN unless another normative rule explicitly assigns a different closed token. Conversion/refusal after bounded transcoding begins but before publication Exact established source/classification facts Serialize exact established conversion facts; applicable incomplete facts use NOT_AVAILABLE . NOT_RUN Publication refusal Exact established facts Exact established conversion facts NONE Success SOURCE_ENCODING: WINDOWS-1252-COMPATIBLE ; undefined-byte offset NOT_APPLICABLE MATERIALIZED_ENCODING: UTF-8 ; TRANSCODING: BOUNDED_STREAMING ; SOURCE_CHANGED: NO Exact published CVT filename CATALOG_STORES CATALOG_ENTRY_COUNT CATALOG_FILENAME Refusal boundary CATALOG_ENTRY_COUNT CATALOG_FILENAME Validation/discovery refusal before the complete authoritative catalog row set is established NOT_AVAILABLE NOT_RUN Publication refusal after the complete catalog row set is established Exact established count, including 0 NONE Success Exact established count Exact physical published CAT filename On success, CATALOG_ENTRY_COUNT equals the number of data rows in the published CAT. CAT itself is the only new non-Receipt governed artifact produced by the operation. RECOVER RID / RECOVER_RID is not a valid executable WASM-002 operation in Revision BM.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-009,"Receipt truth is execution evidence, not presentation authority",W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The Receipt records what Data Sculptor actually attempted, observed, refused, and successfully published. It must not reinterpret the analyst's WKO, replace the Store MAP, or become a second analytical command surface. The WKO remains the durable authorization record; Store MAP/RID/COL artifacts remain the governed analytical state; diagnostic events remain the refusal/help truth; the Receipt cross-references those facts as the durable run ledger. The body of published canonical RCP artifacts is the authoritative evidence substrate for the Flight Recorder logical view defined in W002-STOR-012.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-010,Receipt-publication failure is itself a governed evidence failure,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"Data Sculptor must never claim that a durable Receipt exists until the RCP file has been successfully written and closed in the Suitcase. If host or filesystem failure prevents Receipt publication, the browser must surface a canonical diagnostic through the Help Engine stating that receipt evidence could not be persisted. A receipt-publication failure does not retroactively falsify analytical artifacts that were already successfully committed under their own publication contracts, but the user-facing run summary must clearly distinguish analytical outcome from receipt-persistence failure. Data Sculptor must not invent, backdate, or silently reconstruct a Receipt and present it as the original run artifact. F-14 publication path, reconciled by F-33: the RCP itself is first written as the corresponding SCR candidate under W002-STOR-023.1, closed, reopened and validated against the exact Receipt serialization/key contract before the class-token rename to RCP . If final RCP promotion fails, the candidate remains non-authoritative SCR evidence. Help may identify the exact retained SCR filename when that fact was established, but it must still state that the canonical Receipt was not persisted. WASM-002 does not emit an RCV artifact for this failure.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-001,Successful materialization Receipt and WKO-lineage acceptance,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,"A Store-establishing materialization fixture must run one saved WKO, publish exactly one canonical TXT RCP, and prove that the Receipt identifies the exact WKO through WORK_ORDER_FILENAME , source, RID_ACTION: CREATED , new RID, Stage 1 result/bytes/time, Stage 2 row count/time, all requested COL artifacts in resolved KEEP order, successor Store MAP, published-artifact count, timestamps, and RESULT: SUCCESS . The RCP filename UTC must represent the Receipt artifact's own creation/publication event and must not be required to equal the WKO filename UTC. The same immutable WKO must then be executable again in an appropriate fixture, producing a second distinct RCP with its own Receipt/run timestamps while both Receipts contain the same exact WORK_ORDER_FILENAME . A later same-Store materialization fixture must additionally prove RID_ACTION: REUSED and the original RID filename. The Store-establishing fixture must also prove that the newly created RID, every newly created COL, and the successor MAP carry one identical publication-transaction UTC token while each has a distinct UUID; the RCP filename UTC remains its own Receipt publication timestamp and is not required to equal that analytical transaction UTC. A later same-Store materialization must prove that newly created COLs and its successor MAP share the later transaction UTC while the inherited RID retains its original timestamp/UUID. F-07 Stage-1 success fixture: a successful materialization Receipt must serialize STAGE1_UTF8_OUTCOME: PASS , with UTF8_FIRST_INVALID_BYTE_OFFSET: NOT_APPLICABLE and UTF8_STOP_REASON: NOT_APPLICABLE . Separate refusal fixtures under W002-RCP-ACC-002 must prove FAIL plus the mandatory exact offset and INVALID_UTF8_SEQUENCE . F-20 maximum-width Receipt acceptance: a successful full-width materialization fixture must prove that published-COL indexed keys continue through PUBLISHED_COL_16384_FILENAME using the minimum-three-digit/no-maximum suffix rule. Oversized-header fixtures must prove the exact fallback count, source ordinal, assigned operational name, and SOURCE_HEADER_EXCEEDS_1024_SCALARS reason without embedding the oversized source-header text in the Receipt merely as fallback evidence. F-23 additional successful-Receipt coverage: acceptance must include a successful INVENTORY run whose RCP carries the exact governed INVENTORY operation-specific facts and a successful UPDATE_ALIASES run whose RCP carries the exact BASE_MAP_FILENAME and SUCCESSOR_MAP_FILENAME while reporting only actually published artifacts in the common created-artifact tail. F-23 UUID-collision seam: using a controlled UUID sequence, acceptance must force one or more governed filename collisions before successful allocation. Every pre-existing colliding artifact must remain byte-for-byte unchanged; allocation must retain the originally established governed UTC context while changing only the not-yet-created UUID as permitted; and the published Receipt must report the exact retry count in IDENTITY_COLLISION_RETRIES . Day 060 H-09 success-timeline acceptance Every retained successful Receipt fixture must satisfy the W002-RCP-006 temporal invariant using its actual embedded UTC tokens. Acceptance must mechanically prove: the invoked WKO UTC is less than or equal to RUN_STARTED_UTC ; every non-Receipt governed artifact successfully published by that Run has a governed artifact/transaction UTC between RUN_STARTED_UTC and RUN_FINISHED_UTC , inclusive; RUN_FINISHED_UTC is less than or equal to the Receipt filename/ RECEIPT_UTC ; and no fixture relies on an artifact timestamp that occurs after the Receipt that claims it, or before the Run that created it. A controlled-clock acceptance seam may be used to make equality and strict-order cases deterministic, but the fixture generator must not alter timestamps after the fact merely to satisfy the checker. Day 060 H-11 successful RID_ACTION acceptance A successful new-Store materialization Receipt may report RID_ACTION: CREATED only because the RID was actually promoted into its final governed RID identity during that Run. A successful existing-Store materialization Receipt reports RID_ACTION: REUSED and the exact inherited RID filename; no new RID candidate is created for that Run.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-002,Refusal Receipt acceptance,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,"A saved WKO that is actually Run and deterministically refuses must still produce one canonical TXT Receipt when Receipt publication itself remains available. The emitted bytes must conform to the closed RESULT vocabulary, the four governed absence tokens, the exact operation-specific key spelling/order, and the refusal matrix in W002-RCP-006 through W002-RCP-008. Acceptance must include byte-exact golden Receipt fixtures for every distinct refusal-boundary row required to exercise the serialization matrix for each of the seven executable WASM-002 operations: MATERIALIZE , INVENTORY , UPDATE_ALIASES , REPAIR_MAP , REPAIR_WORK_ORDER_REGISTRY , CONVERT_WINDOWS_1252_TO_UTF_8 , and CATALOG_STORES . Multiple Diagnostic IDs that map to the same refusal boundary and the same serialization row do not require duplicate byte fixtures merely because the Diagnostic ID differs. Acceptance must additionally include one byte-exact UNKNOWN_OPERATION refusal fixture proving the common envelope, OPERATION: UNKNOWN_OPERATION , RESULT: REFUSED , the exact diagnostic ID, absence of any operation-specific section, and immediate CREATED_ARTIFACT_COUNT: 0 . Fixtures must prove that NONE , NOT_RUN , NOT_AVAILABLE , and NOT_APPLICABLE retain distinct meanings; an established zero count is serialized as 0 ; no candidate filename is reported as a published identity; and every indexed key uses its complete frozen name and the minimum-three-digit/no-maximum suffix rule. An unsaved WIP must be proven unable to Run and therefore must not create an execution Receipt. F-16 materialization-refusal fixtures: byte-exact MATERIALIZE refusal Receipts must exercise the new compatibility pair in all four applicable states: NOT_RUN when Stage 1 did not fail; COMPATIBLE plus NOT_APPLICABLE offset; INCOMPATIBLE plus the exact first undefined-byte offset; and NOT_AVAILABLE / NOT_AVAILABLE when an independent compatibility-read failure prevents a conclusion. F-23 Receipt-publication failure fixture, reconciled by F-33: a controlled filesystem-fault seam must make canonical RCP publication fail after the underlying analytical/refusal outcome has been established. Acceptance must prove the W002-RCP-010 boundary exactly: no final RCP is fabricated or claimed, any retained candidate evidence follows the governed SCR retention/non-authority rules in W002-STOR-023.1, no RCV artifact is emitted, the user-facing diagnostic distinguishes analytical outcome from Receipt-persistence failure, and already committed analytical artifacts are not retroactively falsified solely because RCP persistence failed. F-23 ultimate identity-allocation failure fixture: with Receipt publication itself still available, a controlled identity-allocation seam must force a governed operation artifact to exhaust/fail safe allocation. The operation must refuse without overwriting or mutating any colliding pre-existing artifact, and the refusal Receipt/diagnostic evidence must preserve the established collision/allocation-failure facts under PB-STOR-011 and W002-STOR-007.3. Day 060 H-02 fixture binding: the retained golden corpus must use RECEIPT_VERSION: 1 and the fixture-pinned diagnostic allocations in W002-HELP-001.8. The corpus must contain one success Receipt for each of the seven executable operations, one refusal Receipt for every distinct refusal-boundary row in W002-RCP-007/W002-RCP-008, the three additional Stage-1 compatibility variants needed to cover COMPATIBLE , INCOMPATIBLE , and NOT_AVAILABLE after UTF-8 failure, and one UNKNOWN_OPERATION Receipt. Publication-refusal fixtures may use the operation-specific H-02 publication diagnostic and a non-zero IDENTITY_COLLISION_RETRIES value to satisfy the ultimate identity-allocation-failure acceptance boundary without inventing a second diagnostic solely for the same serialization row. Day 060 H-09 refusal-timeline acceptance Every retained refusal Receipt fixture must also satisfy the W002-RCP-006 temporal invariant. For a refusal with no successfully published non-Receipt artifact, acceptance proves WKO_UTC ≤ RUN_STARTED_UTC ≤ RUN_FINISHED_UTC ≤ RECEIPT_UTC . If a refusal legitimately leaves one or more successfully committed non-Receipt artifacts from an already-completed stage, each such artifact UTC must fall between Run start and Run finish and must be listed truthfully under the governing created-artifact rules. Day 060 H-11 / BM-08 RID_ACTION refusal acceptance Byte-exact MATERIALIZE refusal acceptance must distinguish new-Store and existing-Store RID paths: new-Store validation, Stage 1, Stage 2, and post-Stage-2 gate refusals before successful RID promotion serialize RID_ACTION: NOT_RUN and do not serialize a candidate as a published RID; a controlled new-Store refusal after RID promotion has successfully completed may serialize RID_ACTION: CREATED together with the exact published RID filename, but only if that RID was actually promoted and the remaining refusal/rollback evidence is truthful under the publication rules; an existing-Store refusal after the inherited RID has been selected and validated serializes RID_ACTION: REUSED and the exact inherited RID filename even when Stage 1, Stage 2, a later gate, or publication subsequently refuses; an existing lineage whose required inherited RID cannot be validly established serializes RID_ACTION: NOT_AVAILABLE and RID_FILENAME: NOT_AVAILABLE rather than claiming reuse. Acceptance must specifically reject the historical H-02 fixture pattern that reported RID_ACTION: CREATED while no RID existed and CREATED_ARTIFACT_COUNT: 0 . Day 060 H-12 H-02 publication-diagnostic scope The H-02 operation-specific publication diagnostics whose required facts are artifact_class and collision_retry_count are acceptance pins for governed filename identity-allocation collision exhaustion. They are not catch-all Diagnostic IDs for unrelated publication failures such as chronology guards, write/close/rename failures, or malformed predecessor state. Those distinct conditions use their own registry allocations; DS-UTC-001 is independently frozen for the strict monotonic-UTC guard. Day 060 H-13 / BM-10 zero-byte and BOM-only NO_HEADER_RECORD Receipt fixtures The retained golden corpus must contain two distinct byte-exact MATERIALIZE refusal Receipts for the P3-09 no-header boundary: Zero-byte source: the bound source has exact certified byte count 0 ; Stage 1 passes; Stage 2 refuses with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD ; CSV_SOURCE_BYTE_OFFSET: 0 ; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; and CSV_FIELD_ORDINAL: 1 . UTF-8-BOM-only source: the bound source consists exactly of bytes EF BB BF and has exact certified byte count 3 ; Stage 1 passes; Stage 2 refuses with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD ; CSV_SOURCE_BYTE_OFFSET: 3 ; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; and CSV_FIELD_ORDINAL: 1 . These two Receipt fixtures must carry their own truthful source filenames, Work Order identities, run timestamps, Receipt identities, and other governed facts. Only the five-field CSV refusal tuple has the narrower relationship stated in W002-RCP-007; the complete Receipt files are not otherwise required to be byte-identical. Day 060 H-14 / BM-11 CONVERT undefined-byte Receipt binding The coordinated golden Receipt corpus must include the byte-exact CONVERT_WINDOWS_1252_TO_UTF_8 refusal fixture from W002-CONV-ACC-002 using source bytes 41 81 42 . Its Receipt must carry UNDEFINED_WINDOWS_1252_BYTE_OFFSET: 1 and the exact pre-transcoding refusal values frozen in W002-RCP-008.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-003,Receipt TXT is invariant to presentation state in WASM-002,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,The same governed run must be exercised under materially different permitted browser presentation states. In each case the run Receipt must remain an RCP TXT artifact governed by the same receipt serialization and facts. Presentation must not convert it to HTML or alter execution truth in WASM-002. This acceptance gate does not require a configurable Brand Manifest; that capability is deferred.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-001,A Suitcase may contain multiple Stores and each current Store state binds exactly one RID,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The Suitcase is a workspace and may contain zero, one, or multiple logical Stores. Every committed Store state binds exactly one governed current RID artifact. RID values are unique only within their Store row universe; they are not Suitcase-global identifiers. Ordinary same-row-universe work reuses that RID unchanged. In WASM-002, a missing, unreadable, or invalid current RID makes the Store INVALID ; no executable WASM-002 operation regenerates or substitutes that RID. Read-only Help/evidence may explain analyst-owned restoration or lineage-retirement choices, but Data Sculptor does not publish a replacement RID. The stable logical row reference in WASM-002 is conceptually (Store lineage, RID value) ; the current physical RID identity is the exact rid_filename bound by the authoritative MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-002,The Store RID is generated automatically once and reused unchanged in WASM-002,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"When the first successful materialization establishes a new Store, Data Sculptor must automatically generate that Store's initial RID artifact as part of the same Stage 2 operation and the same all-or-refuse publication boundary. The analyst does not separately request ordinary RID generation. Before the RID SCR candidate is created, Data Sculptor establishes the materialization publication-transaction UTC under PB-STOR-013/PB-STOR-014 and allocates a RID-specific UUID. The canonical RID byte stream is then written as the visible governed SCR candidate whose filename already carries that exact UTC, UUID, and .csv extension intended for the final RID identity. Requested materialized columns likewise begin as governed SCR candidates whose distinct COL-specific UUIDs are allocated before those candidates are opened under the same transaction UTC. The new RID candidate and all requested COL candidates must reach EOF, reconcile to the same accepted Store row count N, and pass their required final validation before any candidate is promoted. After complete-set validation, Data Sculptor promotes the RID candidate first by host rename that changes only the three-letter semantic class token from SCR to RID . The candidate bytes, UTC token, UUID, and .csv extension must remain unchanged across that promotion. Requested COL candidates are promoted only after RID promotion succeeds. If later promotion or successor-MAP publication prevents transaction commit, the newly promoted RID is not committed Store state merely because an RID-looking file exists; it must be rolled back where safely possible or retained as attributable recovery evidence under the materialization failure contract. A first Store-establishing materialization commits exactly one RID regardless of how many requested COLs are materialized. Later ordinary materializations and other same-row-universe WASM-002 operations must reuse that RID unchanged. They must not create a new RID candidate, regenerate, replace, renumber, or silently supersede the inherited RID. RID reconstruction/replacement is not an executable WASM-002 operation. Any future governed RID-recovery design remains deferred and must be reintroduced by an explicit later PRD freeze.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-003,RID physical identity uses the governed RID filename grammar,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The physical RID filename must be: __DS__RID__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv The filename contains governed physical identity only. A Store name or friendly analyst alias must not be inserted into, substituted for, or used to rename this immutable physical RID filename.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-004,RID is a canonical one-column CSV containing the exact sequence 1 through N,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The RID artifact must serialize as a canonical one-column UTF-8 CSV with: exactly one UTF-8 BOM at byte zero; a structural first logical record exactly N=<value> , where <value> is the canonical unsigned base-10 representation of the Store's total logical data-row count N ; uppercase N , exactly one equals sign, no spaces, no sign, no leading zeroes except the single digit 0 , and no separators or locale formatting; LF ( 0x0A ) record terminators on every supported host; exactly N data records after the header, containing the consecutive unquoted decimal integers 1 through N in order; no zero RID data value, negatives, signs, thousands separators, decimal points, exponent notation, or leading zeroes; and a final LF after the last record. For N=0 , the canonical bytes are the UTF-8 BOM followed by N=0 and LF, with no data records. The N=<value> record is structural metadata and does not consume a Store row. The governed RID artifact class/filename and Store MAP binding identify the artifact as a RID; the literal header RID is not used by the frozen WASM-002 serialization.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-005,RID cardinality and order define same-Store column alignment,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"If a Store RID contains N data records, every governed column claimed to be aligned to that Store must contain exactly N data records in the same RID order. Data Sculptor must not describe a shorter, longer, reordered, duplicated, or row-shifted column as aligned to that Store. This invariant applies to materialized source columns in WASM-002 and is the stable contract that later calculated, Boolean-selection, verification, or left-join enrichment columns may rely upon.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-006,A different row universe requires a different Store and a new RID,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,An operation that changes which rows exist or changes their governed order does not mutate the existing Store RID. It establishes a different row universe and therefore requires a new logical Store identity and a new RID artifact beginning again at 1 for that new Store. Filtering that is represented only as a same-length aligned Boolean/selection column does not itself change the row universe; building a new reduced/reordered row set later would.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-007,The Store MAP gives RID a friendly alias without changing RID identity,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The physical RID artifact remains identified by its immutable governed filename and semantic RID class. Every valid Store MAP records that exact rid_filename and one current human-facing rid_alias . Changing the RID alias must not rename, rewrite, regenerate, or alter the meaning of the RID artifact. The same Store MAP also records the Store alias and materialized-column aliases, so the analyst-facing names and the physical Store spine remain explicitly connected in one visible governed artifact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-008,Ordinary RID generation is implicit Store infrastructure; RID reconstruction is deferred,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"WASM-002 materialization Work Orders specify the analyst's requested source columns and aliases. They must not require or expose a separate instruction such as RID , ROW INDEX , GENERATE RID , or an equivalent switch to create the Store row spine. Initial RID generation for a new Store is mandatory engine behavior implied by successful MATERIALIZE . WASM-002 must not provide an option to disable it. When ordinary materialization extends an existing Store, the engine must recognize and reuse that Store's existing RID. If that bound RID is missing or invalid, the Store is INVALID and ordinary Store operations refuse. WASM-002 exposes no RECOVER RID executable syntax. A future explicit recovery design may be considered in V1-BACKLOG, but it is not part of this build contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-001,Canonical RID byte serialization acceptance,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"An acceptance fixture with N=5 must prove exact governed bytes equivalent to a UTF-8 BOM followed by: N=5
1
2
3
4
5 Every record uses LF termination and the file ends with a final LF. A separate N=0 fixture must prove exact bytes equivalent to UTF-8 BOM + N=0 and no data records. The N=5 fixture repeated under different permitted source-window boundaries must produce byte-identical RID content apart from the governed physical filename allocated to the artifact. Full RID validation must also prove that the declared N , the number of following data records, and the exact sequence 1..N agree.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-002,Multiple Stores in one Suitcase retain independent RID spines,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,An acceptance fixture must establish at least two Stores with different row counts in the same Suitcase and prove that each Store publishes and retains exactly one distinct governed RID artifact. RID values may overlap numerically across Stores without collision because the Store identity disambiguates them.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-003,Later same-Store materialization reuses rather than regenerates RID,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"An acceptance fixture must establish a Store with an initial materialization, record the physical RID identity and exact RID bytes, then perform a later permitted materialization that adds at least one aligned COL without changing the row universe. The later run must reference and reuse the original RID artifact; no replacement RID may be published and the original RID bytes must remain unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-004,Implicit RID generation acceptance for single- and multi-column first materialization,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"Acceptance must execute two Store-establishing Work Orders that contain no RID or row-index syntax: one requesting exactly one source column and one requesting multiple source columns. Each successfully committed run must publish exactly one governed RID artifact regardless of the number of requested COL artifacts. The fixture must prove that RID creation occurs during the same Stage 2 source-record traversal that establishes the Store row count rather than by requiring a second source pass solely to construct RID. The RID row count must reconcile exactly with every requested COL row count and the final accepted Store N. Before RID candidate creation, acceptance must prove that the publication-transaction UTC and RID-specific UUID are already established, and that the governed SCR filename carries exactly the UTC, UUID, and .csv extension intended for the final RID identity. Before complete-set validation, the RID bytes must exist only as that governed SCR candidate. Acceptance must prove that the RID candidate is promoted by host rename only after the complete RID/COL candidate set validates, that the physical-name change is exactly the class token SCR to RID , that candidate bytes/UTC/UUID/extension are unchanged across promotion, that RID promotion precedes COL promotion, and that the resulting RID is not considered committed Store membership until the successor MAP is successfully promoted and binds that exact RID filename.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-001,INVENTORY is an explicit standalone WASM-002 Work Order operation,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 form is: SUITCASE: .
WORK ORDER AS ""Inventory this Suitcase""
INVENTORY INVENTORY reads the authorized Suitcase directory metadata and creates one governed Suitcase Inventory Snapshot. It is read-only with respect to pre-existing Suitcase files. In WASM-002, an INVENTORY Work Order must not also request materialization, conversion, fingerprinting, another analytical operation, or another Work Order invocation. F-08 structure freeze: after the common SUITCASE: . / WORK ORDER AS ""..."" preamble, INVENTORY is the sole semantic operation clause and is terminal. No SOURCE , MAP , KEEP , alias mutation, conversion, repair, catalog, or composition clause is valid in the same WKO.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-002,Suitcase Inventory uses the governed INV artifact class and canonical filename grammar,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"A successful inventory produces exactly one visible flat TXT artifact whose physical filename is: __DS__INV__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt The UTC and UUID tokens follow the existing governed artifact-identity rules. Data Sculptor must not create an inventory subfolder, hidden cache copy, or alternate private persistence. F-14 publication: the INV body is produced first under the matching W002-STOR-023.1 SCR identity with the same UTC, UUID and .txt extension intended for the final INV. Publication to INV occurs only after the complete scan and deterministic INV serialization validate successfully.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-003,"The lightweight inventory records filename, exact byte length, and last-modified metadata",W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"For every regular file present in the authorized flat Suitcase root at snapshot time, the inventory must record: the exact visible filename; the exact byte length reported by the host file object; and the host/browser-reported last-modified value rendered in the canonical UTC millisecond form when available. WASM-002 must not claim access to a true file-creation timestamp. It must not infer, fabricate, or substitute a creation time from the last-modified value. If usable last-modified metadata is unavailable, the inventory must represent that fact explicitly rather than invent a timestamp. P3-10 last-modified availability test: host/browser last-modified metadata is usable only when the host supplies a finite, non-negative whole-number millisecond value that can be represented in the canonical UTC millisecond timestamp form. If that test fails, the inventory must serialize the governed unavailable value rather than infer, round, substitute, or fabricate a timestamp.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-004,INVENTORY does not read file contents or compute content hashes,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The lightweight inventory must be produced from directory enumeration and file metadata only. Data Sculptor must not open and stream the contents of each listed file merely to create the inventory, and it must not compute SHA-256 or another content fingerprint as an implicit side effect. Its cost should therefore scale primarily with the number of directory entries and metadata calls, not with the aggregate byte size of the files. A 7 GB CSV and a 7 KB CSV each contribute one metadata entry rather than requiring their contents to be read.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-005,Inventory scope is the authorized flat Suitcase root,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"WASM-002 inventories regular files and immediate child directory entries in the directory denoted by SUITCASE: . . Data Sculptor must not recursively inspect, enumerate, size, hash, or otherwise inventory the contents of a child directory in this build. Each immediate child directory is recorded as a directory entry by its exact visible name only. Its nested contents and aggregate size are outside the WASM-002 Inventory contract. This rule preserves the flat-Suitcase storage model while making the presence of user-created directories explicit rather than silently omitting them. F-26 SOURCE distinction: inclusion in an Inventory is evidence that an entry was physically visible to the Inventory operation; it does not make that entry eligible for a Work Order SOURCE . SOURCE eligibility is the narrower contract in W002-WKO-009.1.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-006,Inventory serialization is deterministic UTF-8 TXT,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The INV artifact is a deterministic human-readable TXT document encoded as UTF-8 without BOM, using LF ( 0x0A ) line endings, the same KEY: VALUE line grammar, and the same quoted-text escaping rule frozen by W002-RCP-005. Every INV ends with exactly one final LF, contains no trailing spaces, and contains no blank physical lines. The exact V1 Inventory serialization order is: INVENTORY_VERSION INVENTORY_UTC WORK_ORDER_FILENAME SUITCASE ENTRY_COUNT for each regular-file entry in deterministic ascending exact-filename UTF-8 byte order, one contiguous indexed triplet: FILE_<INDEX> , FILE_<INDEX>_BYTE_LENGTH , FILE_<INDEX>_LAST_MODIFIED_UTC DIRECTORY_COUNT exactly DIRECTORY_COUNT directory-name records using contiguous indexed keys DIRECTORY_<INDEX> , ordered by ascending exact-directory-name UTF-8 bytes. INVENTORY_VERSION is the unquoted integer 1 for this contract. WORK_ORDER_FILENAME , SUITCASE , each FILE_<INDEX> filename, and each DIRECTORY_<INDEX> name use the common double-quoted UTF-8 text serialization. FILE_<INDEX>_BYTE_LENGTH is the exact non-negative ungrouped ASCII base-10 byte length. FILE_<INDEX>_LAST_MODIFIED_UTC is either the exact canonical UTC millisecond token governed by W002-INV-003 or the unquoted governed absence token NOT_AVAILABLE . Indexed suffixes are one-based decimal with a minimum width of three digits and no maximum width: 001 through 999 are zero-padded and 1000 onward uses the full ungrouped decimal form. When ENTRY_COUNT or DIRECTORY_COUNT is zero, no indexed lines for that list appear. ENTRY_COUNT remains the regular-file count. Directory records contain the exact immediate child directory name only and do not imply recursive inspection or a computed directory size. Filename and directory-name representations remain unambiguous even when a name contains whitespace, quotes, or delimiter-like characters because the common quote-doubling rule applies. P3-10 inventory timestamp binding: INVENTORY_UTC must equal the exact canonical UTC token embedded in the final governed __DS__INV__<UTC>__<uuid-v4>.txt filename, just as RECEIPT_UTC is bound to the governed Receipt filename UTC. The INV body and filename therefore cannot claim different capture times.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-007,The current inventory describes the pre-publication Suitcase state and excludes itself,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,Data Sculptor must enumerate and fix the inventory snapshot before publishing the new INV artifact. The INV artifact being created is therefore not one of its own listed entries. Any older INV artifact that already existed at snapshot time is an ordinary Suitcase file and is included like any other file. This pre-publication rule prevents recursive self-reference while preserving an accurate snapshot of the state that existed immediately before the new inventory evidence was added.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-008,"Help describes INVENTORY as a quick continuity aid, not byte-level proof",W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"Help must explain that an INV snapshot is useful for ordinary closeout and later orientation: it can reveal additions, removals, renames, size changes, or last-modified changes when snapshots or current metadata are compared. For an unexpected cross-session source problem, Help may direct the analyst to the relevant source entry in an earlier INV and ask whether its filename, exact byte length, or last-modified metadata differs. Help must also state that unchanged filename/size/last-modified metadata does not prove that file contents or row order are identical. When stronger assurance is warranted because files may change unexpectedly, Help may recommend the explicit later/deeper content-fingerprinting workflow; INVENTORY itself must never imply forensic or cryptographic assurance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-001,Large-file inventory acceptance proves metadata-only behavior,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"An acceptance fixture must place at least one multi-gigabyte file plus several small files in the authorized Suitcase, execute INVENTORY , and prove that the resulting INV records the correct filename, exact byte length, and last-modified metadata without reading the multi-gigabyte file contents. Evidence must demonstrate that inventory runtime and memory do not scale with the aggregate bytes of the listed files in the way a fingerprinting pass would. P3-10 metadata determinism: acceptance must include at least one file with usable host last-modified metadata and one test double/fixture in which the last-modified value fails the governed availability test. The first must serialize the exact canonical UTC millisecond value; the second must serialize exactly NOT_AVAILABLE . The accepted INV must also prove that INVENTORY_UTC exactly matches the UTC token in its final INV filename. Day 060 H-01 byte oracle: acceptance must include at least one byte-exact INV golden fixture using the complete W002-INV-006 key order, indexed suffix rule, quoted-text escaping rule, UTF-8/no-BOM physical form, LF-only line endings, and exactly one final LF. It must include at least two file records so deterministic filename ordering is observable, including one NOT_AVAILABLE last-modified value, and at least one directory record. Day 060 H-09 reachable-Suitcase INV golden fixture The byte-exact INV golden fixture used for WASM-002 review must depict a Suitcase state that could actually execute INVENTORY under the current contract rather than an isolated impossible file list. At minimum, immediately before the Inventory Run begins, the fixture Suitcase contains: one valid current Suitcase Validation Certificate ( CER ) authorizing the root; one structurally valid current WKO registry MAP; the exact saved immutable INVENTORY WKO referenced by WORK_ORDER_FILENAME , registered as runnable by that current WKO MAP; and the ordinary analyst files used to demonstrate inventory metadata, including the controlled last-modified-available and NOT_AVAILABLE cases. The INV snapshot is taken before publication of the new INV artifact and before its Receipt publication. Therefore the INV being created and the Receipt for that Run do not appear as pre-existing entries in their own inventory snapshot. For the retained minimal review fixture, the regular-file ENTRY_COUNT and indexed records must include the CER, current WKO MAP, exact INVENTORY WKO, and the two ordinary sample files, for a total of five regular-file rows, serialized in ascending exact-filename UTF-8 byte order. A later implementation fixture may use different exact governed filenames/UUIDs while preserving the same reachable-state requirement and deterministic ordering.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-002,Inventory snapshot membership and self-exclusion acceptance,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"An acceptance fixture must include ordinary analyst files, existing governed __DS__ artifacts, and at least one older INV artifact. The new inventory must include every qualifying pre-existing root file in deterministic order, include the older INV, and exclude only the newly generated INV because it did not exist in the fixed pre-publication snapshot. Adding an unrelated PDF or ZIP before a later inventory must appear as an added inventory entry and must not be treated as an analytical error.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-003,Inventory does not overclaim unchanged contents,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"Acceptance documentation and Help fixtures must demonstrate the limitation of metadata-only continuity. A case in which a file's bytes are changed while the observed filename, byte length, and last-modified metadata are preserved or restored must not be described as detectable by INVENTORY alone. The product must direct the analyst toward stronger explicit fingerprint evidence when byte-level assurance is required.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-016,Work Order filenames use the governed immutable identity grammar,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When Data Sculptor saves a new Work Order as a WKO, it shall assign the physical TXT filename. The analyst chooses the validated Suitcase but is not asked to choose or edit the WKO filename. The exact WKO filename shape is __DS__WKO__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt , using UTC at millisecond precision with exactly three millisecond digits and a canonical lowercase hyphenated UUID v4. UTC precedes UUID. If the generated name collides with an existing artifact, PB-STOR-011 governs UUID regeneration and safe retry. The saved WKO thereafter retains that physical identity and remains immutable under W002-STOR-017.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-017,Saved Work Orders are immutable artifacts,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"After a Work Order TXT artifact is saved, Data Sculptor shall not edit, overwrite, or rename that saved Work Order in place. Changing analytical instructions requires saving a new Work Order artifact with a new governed physical identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018,Work Order alias is immutable WKO content and governed MAP metadata,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A human-facing Work Order name is required immutable Work Order content for every executable/saved WASM-002 WKO, not separately editable browser metadata. The canonical declaration is WORK ORDER AS ""<alias>"" under W002-STEPS-001.1. The quoted alias must be non-empty UTF-8 text and may contain spaces and ordinary phrase punctuation subject to the governed string-literal rules. After the WKO TXT artifact is saved, Data Sculptor shall not edit the alias in place. Changing the alias, analytical instructions, or comments means creating and saving a new immutable WKO with a new governed physical identity. The physical WKO filename/UUID remains execution identity; the alias is human-facing metadata for display and governed name resolution. The browser must not maintain a separate mutable Description field or hidden description store. The alias declared by the WKO is also represented in the current governed WKO MAP under W002-STOR-018.1 through W002-STOR-018.4.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.1,The existing MAP class includes a distinct WKO alias-registry profile,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Revision BB does not add a new semantic artifact class. The existing MAP class has two explicitly distinguished governed profiles: Store MAP — the existing exact eight-column Store/RID/COL snapshot governed by W002-STOR-019 through W002-STOR-019.12; WKO MAP — a complete immutable snapshot that maps saved Work Order aliases and lifecycle status to exact immutable WKO filenames. Profile classification is determined by the exact CSV header before profile-specific validation. A valid WKO MAP must never be treated as an eligible Store MAP, and a Store MAP must never be treated as a WKO alias registry. Both remain visible flat-Suitcase MAP artifacts under the canonical immutable filename grammar.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.2,WKO MAP schema and serialization are exact and deterministic,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical WKO MAP is UTF-8 CSV without BOM, using LF record termination, with exactly this three-field header: wko_status,wko_alias,wko_filename Each row identifies one immutable governed WKO represented in that registry snapshot. wko_status is exactly CURRENT or DEPRECATED . wko_alias is the exact mandatory non-empty alias declared by that WKO's WORK ORDER AS clause. wko_filename is the exact governed physical WKO filename. Rows are written deterministically by ascending exact UTF-8 byte order of wko_filename . Duplicate wko_filename rows are invalid. Standard governed CSV quoting applies. For any exact wko_alias value, at most one row may have wko_status=CURRENT ; zero or more older rows for that same alias may have wko_status=DEPRECATED . Alias resolution uses the CURRENT row only. A WKO represented by a DEPRECATED row remains immutable historical evidence and is not renamed, rewritten, or deleted merely because its alias target was superseded. A WKO MAP containing more than one CURRENT row for the same exact alias is structurally invalid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.3,Saving a WKO and publishing its WKO MAP binding is one governed save transaction,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Saving a new immutable WKO begins from the current structurally valid WKO MAP in the Suitcase, or an empty WKO registry if no structurally valid WKO MAP exists. Data Sculptor validates the draft, including its mandatory non-empty WORK ORDER AS alias and comment syntax, and checks the governed alias/lifecycle constraints before commit. F-02 alias-lifecycle decision: if no CURRENT row in the predecessor WKO MAP uses the new WKO's exact alias, the successor registry adds the new WKO as CURRENT . If exactly one CURRENT row already owns that exact alias, Data Sculptor must present exactly two analyst choices before registry commit: Replace alias target or Cancel . Replace alias target constructs the successor WKO MAP by changing the former owner's row to DEPRECATED and adding the newly saved WKO as the sole CURRENT row for that alias; any older DEPRECATED rows remain unchanged. Cancel leaves the predecessor WKO MAP authoritative and does not commit the pending WKO/WKO-MAP pair as a registry update. Data Sculptor must not silently replace the alias target, auto-suffix the alias, or choose between competing owners. A predecessor WKO MAP with more than one CURRENT row for the same alias is structurally invalid under W002-STOR-018.2 and cannot be used as save authority. The former CURRENT WKO and every prior WKO MAP remain byte-for-byte immutable after replacement. Supersession changes only the lifecycle metadata represented in the newly published successor WKO MAP; it does not edit, rename, delete, or rewrite the historical WKO artifact. F-14 WKO publication predicate: the new immutable Work Order is first written under the W002-STOR-023.1 SCR identity using the UTC, UUID and .txt extension intended for its final WKO identity. The complete candidate is closed, reopened and validated as a saved WKO: required common preamble, exactly one non-whitespace WORK ORDER AS alias, governed lexical/comment rules, and complete parse under exactly one current WASM-002 executable operation grammar. Only then may the candidate be renamed from SCR to WKO . Save-time current-registry, alias-lifecycle and lifecycle gates remain transaction preconditions. A valid promoted WKO is not yet alias-registry authority; the successor WKO MAP promotion remains the save-transaction commit point. The WKO is persisted as a new immutable governed WKO artifact and the complete successor WKO MAP is constructed under SCR , closed, reopened, and validated for WKO MAP structural validity : exact profile/schema, exact governed serialization, filename/profile rules, lifecycle-row constraints, and internal row constraints. Whether every referenced physical WKO file is presently visible is a separate registry-health/publication check and is not part of WKO MAP structural validity. For an ordinary successful save transaction, every WKO referenced by the successor registry must be present at publication. The successor WKO MAP is promoted to MAP last; that successful MAP promotion is the alias-registry commit point for the save transaction. The WKO and successor WKO MAP created by one successful save transaction use one shared canonical transaction UTC while retaining distinct UUIDs. If successor WKO-MAP structural validation, referenced-file publication checking, or publication itself fails, the save must not be represented as a successfully committed alias-registry update. Data Sculptor must roll back the new WKO out of committed WKO state where safely possible or retain visible non-authoritative SCR failure evidence and report the failure through Help. F-02 repair-only bootstrap and stale-registry Save boundary When the current WKO registry is repair-required under W002-STOR-018.4, Data Sculptor may save one ordinary visible immutable WKO whose sole semantic operation is exactly REPAIR WORK ORDER REGISTRY . That saved repair-only WKO may Run by its exact physical WKO filename even though it is not yet represented in the current WKO MAP. The WKO must be structurally valid under the predicate below, must contain exactly one mandatory non-empty WORK ORDER AS , and must contain exactly the governed registry-repair operation and no second operation. The exception does not grant alias-based Run authority. The repair WKO is invoked only by exact physical WKO filename. No other visible but unregistered WKO gains Run eligibility from this exception. The exception ends once registry repair successfully publishes the successor WKO MAP. This is the sole WASM-002 bypass of ordinary current-registry membership for Run eligibility. Because the registry is already stale, Save of the repair-only WKO does not claim that the WKO has been registered, does not commit an ordinary successor WKO MAP, and does not represent the stale registry as healthy. The new immutable WKO remains visibly unregistered until the repair operation successfully publishes the successor WKO MAP containing its row. Save does not silently perform registry repair. F-02 governed WKO structural-validity predicate A visible WKO is structurally valid for registry purposes only when all of the following hold: it is a regular root-level Suitcase file; its physical filename conforms exactly to the governed WKO filename grammar; its bytes are valid UTF-8; LF and CRLF physical line endings are accepted; a lone CR line ending refuses; its content parses completely under exactly one defined WASM-002 executable Work Order grammar; it contains exactly one mandatory non-empty WORK ORDER AS clause; its required common and operation-specific structural clauses are present in their governed order/cardinality; and unknown syntax or prohibited operation mixing causes invalidity/refusal. Structural validity is not runtime success. A structurally valid WKO remains a valid governed artifact even when a runtime precondition is currently false, such as a referenced source file being absent. Runtime preconditions are checked at Run. P3-10 repair-bootstrap timing: during REPAIR WORK ORDER REGISTRY , the saved repair-only WKO participates in the bounded discovery performed by that repair run. It is not first “discovered after success.” Its governed registration becomes durable only when the complete successor WKO MAP containing that WKO row is successfully committed. Discovery during the run and registration in the committed successor registry are distinct events. P2-03 WKO-registry chronology guard: before a save or registry-repair transaction publishes a successor WKO MAP, Data Sculptor establishes the truthful observed transaction UTC and compares it with the chronology predecessor defined by W002-STOR-018.4. The observed UTC must be strictly greater. Equal or earlier UTC refuses before the new WKO/WKO-MAP pair is committed; Data Sculptor must not fabricate a later timestamp, silently wait/retry, skip the predecessor, or select an older registry merely to make publication succeed. F-13 single-writer pre-commit guard: immediately before the successor WKO MAP promotion that would commit the alias-registry update, Data Sculptor re-resolves the current WKO-registry authority and compares the relevant governing state with the state from which this transaction was derived. If another writing context or external filesystem action has changed that relevant authority, the transaction refuses publication. It must not overwrite the newer registry, silently rebase the pending save, or choose an older registry to make the commit succeed. The existing rollback / attributable SCR recovery-evidence rules apply to any WKO or candidate bytes already produced. If the save later refuses and an SCR candidate or other attributable staged evidence cannot be safely removed/restored, W002-STOR-023.1 governs retained SCR evidence and its non-authority boundary; WASM-002 does not emit RCV. An unregistered final WKO left by a failure is a valid immutable WKO artifact but does not become current registry authority merely by existing; the WKO MAP remains authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.4,Current WKO MAP selection is based on structural validity; missing referenced WKOs make the registry repair-required,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"WKO MAP structural validity is distinct from registry health. A WKO MAP is structurally valid when the MAP artifact itself satisfies the governed WKO MAP profile/schema, serialization, filename/profile rules, lifecycle-row constraints, and internal row constraints. The present existence of every physical WKO file named by its rows is not part of WKO MAP structural validity. Only structurally valid WKO MAP artifacts participate in current-registry selection. Among structurally valid WKO MAPs, the one with the greatest canonical UTC millisecond timestamp is the current WKO MAP snapshot and therefore the current governed Work Order alias registry. If two or more structurally valid WKO MAPs share that greatest timestamp, current-registry selection must refuse rather than break the tie by UUID, discovery order, filesystem modified time, or directory order. Registry-snapshot authority is distinct from alias-target status inside that snapshot. After the current WKO MAP snapshot is selected, an alias resolves only to its exact row whose wko_status is CURRENT . Rows marked DEPRECATED remain visible historical registry evidence but are not alias-resolution targets. The registry must never use the greatest WKO filename UTC, filesystem modified time, or discovery order to choose between rows for an alias. More than one CURRENT row for the same exact alias makes that WKO MAP structurally invalid under W002-STOR-018.2. If a newer WKO MAP artifact is structurally malformed, it never becomes current. Data Sculptor uses the greatest earlier structurally valid WKO MAP, if one exists, and reports the malformed newer artifact through Help/evidence surfaces. A malformed newer WKO MAP does not itself make the selected earlier registry repair-required. The current WKO registry is repair-required exactly when the current structurally valid WKO MAP contains one or more rows whose referenced physical WKO files are missing from the Suitcase. Such a MAP remains current ; Data Sculptor must not silently fall back to an older WKO MAP merely because a referenced WKO is missing. This preserves the latest registry authority while making the damage explicit and reachable through the governed REPAIR WORK ORDER REGISTRY path. F-02 deterministic registry reconciliation REPAIR WORK ORDER REGISTRY reconciles the current WKO MAP against visible WKO artifacts in the Suitcase and constructs one complete successor WKO MAP deterministically: Remove every row from the successor whose referenced physical WKO file is missing. A missing WKO is never reconstructed, inferred, copied from history, or replaced automatically by a deprecated WKO. Discover visible structurally valid WKOs that are absent from the current WKO MAP. If no surviving CURRENT row owns a discovered WKO's exact alias, register that discovered WKO as CURRENT . If a surviving CURRENT row already owns that exact alias, register the discovered WKO as DEPRECATED ; existing current authority is not silently displaced. If two or more previously unregistered structurally valid WKOs share the same alias and no surviving CURRENT owner exists, register all of those discovered WKOs as DEPRECATED . Data Sculptor must not choose a winner by UTC, filename, UUID, directory order, discovery order, or filesystem modified time. The repair WKO itself participates in the same discovery and registration process during the repair run. Its registration becomes durable only when the complete successor WKO MAP is committed. Predecessor WKO MAPs and surviving WKO files remain immutable historical evidence. Successor rows remain serialized in ascending exact UTF-8 byte order of wko_filename under W002-STOR-018.2. Day 060 H-10 / BM-07 registry-repair change-set counts The registry-repair operation distinguishes the successor registry state from the change set produced by this repair Run . The Receipt's REGISTERED_CURRENT_* and REGISTERED_DEPRECATED_* fields describe only the latter. REGISTERED_CURRENT_COUNT is the exact number of previously unregistered structurally valid WKO files newly added by this repair Run with wko_status=CURRENT . REGISTERED_CURRENT_WKO_<INDEX>_FILENAME lists exactly those newly registered CURRENT WKOs, ordered by ascending exact UTF-8 filename bytes. REGISTERED_DEPRECATED_COUNT is the exact number of previously unregistered structurally valid WKO files newly added by this repair Run with wko_status=DEPRECATED . REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME lists exactly those newly registered DEPRECATED WKOs, ordered by ascending exact UTF-8 filename bytes. Surviving rows that were already present in the base WKO MAP are not counted in either REGISTERED_* total, even though they appear in the successor WKO MAP. Rows removed because their referenced WKO is missing are represented only by REMOVED_STALE_ROW_COUNT and the corresponding stale-WKO filename list; they are not also reflected in either registered count. The bootstrap repair WKO participates exactly like any other newly discovered structurally valid unregistered WKO. If the repair commits it, that exact WKO must appear in one and only one of the two registered filename lists according to the ordinary alias-ownership rules. These counts therefore answer “what did this repair register?” rather than “how many CURRENT/DEPRECATED rows exist in the resulting registry?”. F-02 Run eligibility and alias authority Run by human-facing alias resolves only to the sole CURRENT WKO for that alias. A registered CURRENT WKO may Run by exact physical WKO filename, subject to ordinary runtime preconditions. A registered DEPRECATED WKO may also Run by exact physical WKO filename, subject to ordinary runtime preconditions, to support deliberate historical reproduction. An unregistered WKO may not Run merely because its file is visible, except for the single bounded repair-only bootstrap in W002-STOR-018.3. The browser may use the current structurally valid WKO MAP to show human-facing Work Order aliases together with read-only CURRENT / DEPRECATED lifecycle state while keeping exact physical WKO filenames visible/inspectable. Future Work Order composition may use the same registry to resolve a non-empty alias to exactly one immutable WKO artifact through its sole CURRENT row. This requirement does not pull deferred Work Order invocation/orchestration grammar into WASM-002; it establishes the governed alias-registry selection, lifecycle, and repair boundary that later composition can depend on. F-08 REPAIR WORK ORDER REGISTRY Work Order structure: SUITCASE: .
WORK ORDER AS ""Repair Work Order Registry""
REPAIR WORK ORDER REGISTRY After the common preamble, REPAIR WORK ORDER REGISTRY is the sole semantic operation clause and is terminal. It takes no analyst-supplied SOURCE , Store MAP , alias-mutation list, column selector, conversion source, or catalog clause. Its bounded unregistered-repair bootstrap remains governed by W002-STOR-018.3. The DS-STEPS phrase is distinct from the Receipt operation token REPAIR_WORK_ORDER_REGISTRY . P2-03 chronology predecessor: for any WKO-registry successor publication, the chronology predecessor is the unique current structurally valid WKO MAP immediately before that publication transaction. It is the MAP selected by the current-registry rule above, not an older registry used for inspection and not a filesystem-modified-time surrogate. If no structurally valid WKO MAP exists and the operation is legitimately establishing the first governed registry state, there is no predecessor UTC. Future-dated current WKO MAP: a structurally valid current WKO MAP whose governed UTC is later than truthful observed host UTC remains the current registry; the timestamp conflict does not by itself make the MAP malformed or repair-required. Successor WKO-MAP publication is blocked until the monotonic UTC precondition can be satisfied. Help must identify the exact blocking WKO MAP and explain the analyst-owned exits: correct an incorrect host clock; wait/rerun after truthful time advances beyond the predecessor; or, when the analyst deliberately determines that the active future-dated WKO MAP should no longer govern the Suitcase, move that exact MAP out of the active Suitcase root and reopen/rescan. That filesystem action is not a Data Sculptor repair operation. It may expose an older structurally valid WKO MAP as current, and restoring the moved future-dated MAP to the active Suitcase may make it current again under the ordinary greatest-UTC rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019,Store state is preserved as visible immutable MAP history,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each valid WASM-002 MAP is one complete immutable Store snapshot in the same flat Suitcase. Store state is not stored in hidden browser persistence and is not represented by a mutable well-known singleton. Each successful Store-establishing materialization or later governed Store-metadata/materialized-column update publishes a new immutable MAP under the canonical __DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv identity grammar. Earlier MAP artifacts remain visible history and are not overwritten or deleted merely because a newer Store state is created. Day 057 CAT reconciliation: the one-Store-per-MAP invariant is unchanged. A collection of independently MAP-governed Stores may additionally be summarized by a governed CAT Store Catalog for collection-level discovery and orientation. CAT does not govern Store semantics, lineage, health, repair, inheritance, or current-MAP selection. MAP remains authoritative for each Store.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.1,A Work Order may explicitly select at most one Store MAP,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each governed Work Order may explicitly identify at most one valid immutable Store MAP as its Store/inheritance base. If more than one MAP is explicitly specified, Data Sculptor must refuse before Store resolution, alias resolution, materialization, or mutation. An explicitly named valid MAP binds the run to exactly the Store identified by that MAP's rid_filename and overrides automatic Store-MAP discovery even when newer MAPs for that Store or other Stores exist.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.2,"Without an explicit MAP, materialization performs Store-aware MAP inheritance",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If a materializing Work Order does not explicitly identify a MAP, Data Sculptor must compare the exact Work Order SOURCE filename with the one common exact source_filename carried by every row of each routable Store lineage's structurally valid Store MAP. That common source_filename is the Store lineage's source identity for WASM-002 routing. The redundant ninth Store-source field from the superseded profile is not part of the canonical Store MAP. P3-07 routing term: for automatic source routing, a routable Store lineage is a Store lineage for which at least one structurally valid Store MAP exists, regardless of whether the lineage currently evaluates VALID , DEGRADED , or INVALID . Routing discovery must use this term rather than the ambiguous word eligible . Store health is evaluated only after the lineage has been discovered. If no routable Store lineage exists for the exact source filename, Data Sculptor may establish a new Store with a new RID and first Store MAP only if the active Suitcase contains no structurally malformed Store-MAP-class artifact . If exactly one routable Store lineage exists, Data Sculptor routes to that lineage. If its current state permits materialization, the current governed Store MAP is the inheritance base; if its current state is DEGRADED or INVALID , ordinary materialization refuses under the damaged-lineage rules below. If more than one distinct routable Store lineage exists for the same exact source filename, automatic inheritance must refuse rather than guess which Store the analyst intended. The analyst must explicitly select one permitted MAP. All-Store-MAPs-damaged guard: if exact- SOURCE routing finds no routable Store lineage but one or more structurally malformed Store-MAP-class artifacts are present in the active Suitcase, ordinary materialization must refuse before creating a new Store or RID. Data Sculptor must not infer that the absence of a structurally valid Store MAP proves that no prior Store lineage existed. Help must identify the malformed Store MAP artifact or artifacts that caused this guard. A damaged MAP therefore cannot silently turn Store damage into permission to create a replacement lineage. Store lineages are distinguished by their governed lineage identity. Current-MAP selection and Store-health evaluation are separate governed questions under this requirement and W002-STOR-019.10. If two or more structurally valid current MAP candidates for the one routed Store share the greatest canonical UTC millisecond timestamp, automatic inheritance must refuse rather than infer chronology from UUID, directory order, filesystem modified time, or discovery order. F-03 canonical evaluated Store-health states Store health is evaluated from the current structurally valid Store MAP and the presently visible governed artifacts it references, using the applicable validation tier in W002-STOR-019.10. WASM-002 has exactly three evaluated Store-health states: VALID — the current Store MAP is structurally valid; the referenced RID is valid; and every mapped non-RID COL is valid. DEGRADED — the current Store MAP is structurally valid; the referenced RID is valid; and one or more mapped non-RID COL artifacts are missing or invalid. INVALID — the current Store MAP is structurally valid, but its referenced RID is missing or invalid. There is no fourth ABANDONED Store-health status in WASM-002. F-03 status is evaluated, not persisted VALID , DEGRADED , and INVALID are evaluated states. WASM-002 does not write or maintain a mutable persisted Store-status flag. While a Store evaluates INVALID , Data Sculptor exposes no governed Store-recovery operation for that Store and never regenerates, substitutes, or infers a replacement RID. If the exact governed RID physical identity becomes visible again through analyst-owned external restoration and passes the validation tier required by the next operation, the Store is re-evaluated from the visible governed artifacts and may become VALID or DEGRADED . That is re-evaluation, not RID recovery by Data Sculptor. F-03 strict DEGRADED operation gate When a Store evaluates DEGRADED , REPAIR MAP is the only enabled Store mutation operation for that lineage . ordinary materialization into that Store refuses; extension with new columns refuses; alias mutation refuses; transformations and other Store mutations refuse; read-only Help, Inventory, status/orientation surfaces, CAT orientation, and evidence inspection remain available subject to their own contracts. F-03 no damaged-lineage fork If exact SOURCE routing identifies a lineage whose current Store evaluates DEGRADED , ordinary materialization refuses and directs the analyst to the governed REPAIR MAP path. If the routed Store evaluates INVALID , ordinary materialization refuses and WASM-002 provides no RID-recovery path. Neither condition permits Data Sculptor to treat the source as unseen or establish a replacement Store with a new RID for that routed lineage. Damaged-lineage routing: exact SOURCE routing must not treat a known damaged lineage as unseen merely because its current Store state cannot accept ordinary materialization. If routing identifies a DEGRADED or INVALID lineage, ordinary materialization refuses rather than silently creating a replacement Store for that same routed lineage. Help duty for an all-COLs-broken DEGRADED lineage: when the current structurally valid Store MAP references a valid RID but every mapped non-RID COL is missing or invalid, REPAIR MAP cannot publish a zero-COL successor and must refuse. Help must identify the exact blocked Store lineage and current MAP, then explain these analyst-owned exits: (1) externally restore at least one governed COL artifact under its original physical filename; Data Sculptor then applies the governed validation tier required by the next operation before the artifact can re-enter use, so Store health can be re-evaluated and REPAIR MAP may become available; (2) rename the analyst-owned source and materialize the renamed source to deliberately begin a new Store lineage with a new RID, without repairing, replacing, or erasing the damaged lineage; or (3) retire the damaged lineage from active Suitcase routing by moving all Store MAP artifacts belonging to that lineage out of the Suitcase root. Help must warn that moving only the latest MAP is insufficient because an older structurally valid MAP could otherwise become current. Help duty for an INVALID lineage: when the current structurally valid Store MAP references a missing or invalid RID, Help must identify the exact blocked Store lineage and current MAP, state that WASM-002 does not silently regenerate or substitute a RID as part of ordinary materialization, and explain these analyst-owned exits: (1) externally restore a governed RID artifact under its original physical filename; Data Sculptor then applies the governed validation tier required by the next operation before the artifact can re-enter use, so Store health can be re-evaluated; (2) rename the analyst-owned source and materialize the renamed source to deliberately begin a new Store lineage with a new RID while leaving the damaged lineage untouched; or (3) retire the damaged lineage from active Suitcase routing by moving all Store MAP artifacts belonging to that lineage out of the Suitcase root, again warning that moving only the latest MAP is insufficient. Renaming the source and retiring a lineage are distinct analyst choices. Renaming preserves the damaged lineage in the Suitcase and creates a separate lineage under a different source identity. Moving all lineage MAPs out removes that lineage from active routing while preserving the moved artifacts wherever the analyst chooses to keep them. These are analyst filesystem actions, not new Data Sculptor recovery operations. Assurance boundary: exact source-filename matching in this rule is a Store-routing/orientation mechanism, not proof that an analyst-owned source has identical bytes or row order across separate sessions. Ordinary WASM-002 materialization must not silently represent that filename equality as cryptographic continuity. P3-08 CVT source-identity boundary: a governed CVT is a new immutable source artifact whose Store-routing source identity is its exact physical CVT filename. Two different CVT filenames are different source identities even when both conversions began from analyst-owned files having the same original filename. WASM-002 does not carry the analyst-owned pre-conversion filename forward as hidden Store-lineage identity and does not infer continuity between separate CVT artifacts. First materialization of a CVT therefore establishes or routes only by that exact CVT filename under the normal rules above. P2-03 current Store-MAP chronology: within one routable Store lineage, the current structurally valid Store MAP is the unique structurally valid MAP carrying the greatest canonical UTC millisecond timestamp. If two or more structurally valid MAPs share that greatest timestamp, current authority is ambiguous and selection refuses rather than using UUID or discovery order. This current MAP is also the lineage's chronology predecessor for any new successor publication, even when the operation explicitly derives its requested new state from an older historical MAP. F-15 exact-source comparison and routing domain: the Work Order SOURCE value and each Store MAP's common source_filename are compared by exact Unicode scalar-value sequence under PB-STOR-010, with no case folding or Unicode normalization. Automatic routing compares only routable Store lineages whose structurally valid Store MAPs participate in that exact-source routing decision. Unrelated Suitcase files, non-Store artifact classes, filesystem enumeration order, and arrival order are outside the routing comparison domain and cannot create or remove a source match.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.3,"Any valid historical Store MAP may be selected explicitly with MAP ""<filename>""",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A governed Store-aware Work Order may explicitly identify any one structurally valid immutable Store MAP present in the Suitcase, including an older snapshot when newer MAPs for that Store also exist. The canonical clause is: MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv"" The quoted value must be the exact physical filename of one valid Store MAP. A WKO MAP profile, missing file, malformed MAP, or other MAP profile is invalid for this clause. Data Sculptor uses exactly the named Store MAP rather than silently substituting a later one. For materialization, SOURCE ""..."" remains required to identify the source file being read; the optional MAP ""..."" clause occurs immediately after SOURCE and before KEEP , overrides automatic Store-MAP inheritance, and supplies the exact Store-state base. The Work Order's exact SOURCE filename must match the selected lineage's governed source identity under the frozen source/Store compatibility rules or validation refuses. For an alias-only UPDATE ALIASES Work Order, MAP ""..."" may itself be the Store-state selector and no source-data read is required. Historical-MAP health gate. Explicit selection of a current or historical Store MAP never bypasses current Store-lineage health. The selected lineage must currently evaluate VALID , and every RID/COL binding referenced by the named MAP must currently be present and valid. If either condition fails, Data Sculptor refuses the operation. An older MAP cannot be used to hide present lineage damage. The same rule applies when UPDATE ALIASES uses a historical Store MAP as its base. Once selected, the exact MAP identity, Store RID binding, Store alias, RID alias, and materialized-column mapping state remain fixed for the governed run. The MAP filename is execution input, not a friendly alias. P2-03 base-versus-predecessor distinction: an explicitly selected historical MAP is the operation's base MAP —the Store snapshot from which requested new state is derived. It does not become the chronology predecessor merely because it was selected. If the operation publishes a new Store MAP, the chronology predecessor remains the Store lineage's current structurally valid MAP immediately before publication. The new transaction UTC must be strictly greater than that current MAP UTC. This preserves one chronological MAP history rather than creating a branch from the historical base. F-21 current-state consequence: merely selecting or validating a historical Store MAP does not change Store authority. If the governed run refuses or otherwise publishes no successor Store MAP, the lineage's pre-run current MAP remains current. If the run successfully publishes a successor derived from a historical base, that new MAP enters the same single chronological history and ordinary greatest-governed-UTC current-state selection applies. Because successor publication already requires a truthful transaction UTC strictly greater than the pre-publication chronology predecessor, the successfully published successor becomes current. The explicitly selected historical base and the formerly current MAP both remain immutable historical evidence. This behavior is deliberate state derivation, not a branch, rollback-in-place, overwrite, or mutation of prior MAPs. The operation base records which Store snapshot supplied the requested starting state ; chronology records when the new governed state was published . Those are distinct facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.4,"Store MAPs are complete snapshots, not delta logs",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each valid Store MAP represents one complete usable Store metadata and materialized-column mapping state for that version. It must not require replaying a chain of earlier MAP files merely to reconstruct the Store's current RID binding, aliases, or materialized-column mappings. A newer MAP created from an inherited older MAP contains the complete resulting Store snapshot after applying the governed Work Order's successful changes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.5,Materialization or governed Store metadata mutation emits one successor MAP,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When a governed Work Order materializes one or more columns or requests governed Store/RID/COL alias changes, Data Sculptor begins from the applicable governed Store-state base. Ordinary materialization uses the explicitly selected MAP or Store-aware automatic inheritance under W002-STOR-019.2. A new Store begins from newly established Store/RID metadata plus an empty materialized-column mapping set before requested materialization is applied. All successful updates in that Work Order are applied to one in-memory complete Store snapshot. The complete deterministic successor-MAP bytes must first be written under a governed SCR candidate identity, closed successfully, reopened, and fully validated while still an SCR candidate. Only a complete validated candidate may be promoted by host rename into one new immutable MAP artifact. The inherited MAP remains unchanged. The successful SCR -to- MAP rename is the Store-state commit point. A failed run must not create a valid successor MAP; a malformed, incomplete, or unpromoted MAP candidate remains visible non-authoritative SCR evidence rather than Store state. RID reconstruction/replacement is not a WASM-002 Store-mutation path. P2-03 successor publication precondition: before any final RID/COL/MAP promotion for a successor Store-state transaction, Data Sculptor identifies the lineage's chronology predecessor and establishes one truthful observed host transaction UTC. For an existing lineage, that UTC must be strictly greater than the current structurally valid Store MAP UTC, regardless of whether the Work Order's base MAP is current or historical. Equal or earlier observed UTC refuses publication; no artificial +1 ms , sleep-and-retry loop, UUID tie-break, older-predecessor fallback, or branch chronology is permitted. The chronology predecessor remains current and unchanged. Future-dated current Store MAP: a structurally valid current MAP with a governed UTC later than truthful observed host UTC is a clock-order conflict, not by itself Store corruption. It remains current and successor publication is blocked. Help must identify the exact blocking MAP and explain the analyst-owned exits: correct an incorrect host clock; wait/rerun after truthful time advances beyond the predecessor; or deliberately move that exact future-dated current Store MAP out of the active Suitcase root and reopen/rescan. Moving it is an analyst filesystem action, not a governed Data Sculptor mutation. An older structurally valid MAP may then become current; returning the future-dated MAP may restore its authority under the ordinary greatest-UTC rule. F-13 single-writer pre-commit guard: immediately before the final successor Store-MAP promotion, Data Sculptor re-resolves the relevant current Store authority and exact-source routing state on which the transaction depended. For an existing lineage, the current chronology predecessor must still be the authority against which the transaction was prepared; for a new-Store transaction, no newly established routable lineage may have appeared that changes the routing decision. If relevant governed state changed while the transaction was in flight, publication refuses. Data Sculptor must not overwrite the newer authority, silently rebase onto it, create a competing branch, or report success. Any RID/COL/candidate artifacts already produced are handled by the existing rollback / attributable recovery-evidence rules and do not become committed Store membership without the final valid MAP binding. F-21 historical-base publication rule: when the applicable Store-state base is a valid historical MAP rather than the pre-run current MAP, the complete successor snapshot is still derived from that explicitly selected base plus the current Work Order's requested changes. Publication does not silently merge later state from the formerly current MAP back into the successor. Therefore mappings or aliases introduced only after the selected historical base may be absent from the new successor when the requested operation does not recreate them. That is the deliberate consequence of using the historical base, not data loss caused by an implicit merge. The pre-run current MAP remains the chronology predecessor solely for monotonic publication ordering and stale-authority protection. Successful publication leaves both the historical base and the formerly current MAP byte-for-byte unchanged, publishes one new immutable successor MAP in the same lineage, and makes that successor current under the ordinary chronology rule. No branch identifier, hidden branch state, overwrite, in-place rollback, or automatic rebase is created.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.6,Store MAP CSV schema is exactly eight columns,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 Store MAP is a CSV whose header row is exactly: store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename Each data row describes one current logical materialized-column mapping: store_alias — current human-facing Store name; rid_filename — exact immutable governed RID artifact filename that physically anchors this Store lineage; rid_alias — current human-facing RID name; source_filename — exact visible source filename common to every row in this one-Store MAP and therefore the Store source identity; source_column_number — 1-based source-column ordinal; source_header — exact decoded CSV header value after governed parsing; alias — current human-facing COL name; and column_filename — exact physical governed COL artifact filename represented by the row. Every row in one valid Store MAP must carry the same exact rid_filename and the same exact source_filename . A MAP that mixes RID lineages or source filenames is invalid. The logical source-column key for COL alias continuity remains the exact triple (source_filename, source_column_number, source_header) . The Store is physically identified by the repeated exact rid_filename , not by mutable aliases. F-05/P2-01 reconciliation: the superseded redundant Store-source column is removed. One Store MAP represents exactly one Store lineage and exactly one source identity, so the common source_filename supplies the required source identity without a second Store-source field. P3-06 identity-evidence boundary: this eight-column MAP profile intentionally records governed physical filenames and mapping metadata, not per-artifact byte lengths, row counts, digests, or historical-content fingerprints. A MAP therefore cannot prove that a same-named RID or COL restored later is byte-for-byte identical to the earlier artifact. WASM-002 must not make that claim unless separate authoritative fingerprint evidence exists outside this MAP profile. P2-04 schema consequence: no byte-length, RID- N , digest, or per-artifact fingerprint columns are added to the eight-column Store MAP to close restoration validation. The MAP remains compact relationship/state metadata. Stronger byte-identity assurance remains the responsibility of explicit fingerprint evidence outside ordinary WASM-002 Store governance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.7,Source headers become default COL aliases on first materialization,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When a logical source column is materialized and its exact logical key does not already exist in the inherited Store MAP, its default COL alias is its operational column name . For an exact decoded source_header of at most 1,024 Unicode scalar values, the operational name is that exact header text. For an exact decoded source_header longer than 1,024 scalar values, the operational name begins as Column <LETTERS> from the column's 1-based physical source ordinal (for example Column A , Column Z , Column AA , through Column XFD ). The exact source_header remains unchanged in the Store MAP and physical COL header; the operational name exists only to provide a bounded human-facing/default-alias value. HEADER selection continues to match the exact decoded source header under W002-STEPS-002. If an oversized-header base fallback Column <LETTERS> would collide in the complete successor alias namespace, Data Sculptor deterministically tries Column <LETTERS> [<ordinal>] ; if that also collides, it appends -2 , -3 , and so on until the first available exact value is found. This is the only automatic alias-suffix rule in WASM-002. A short exact source-header default that is empty or collides still refuses unless the Work Order supplies an explicit valid alias; Data Sculptor must not suffix or rewrite it. If the same Work Order supplies an explicit alias for a newly materialized column, the explicit governed alias overrides the operational default and must pass the ordinary exact uniqueness/shadowing rules without automatic suffix repair. For a previously materialized COL, RESET COL ""<reference>"" ALIAS restores this same deterministic operational default from the exact recorded source_header and physical source ordinal. An oversized recorded header therefore restores its deterministic fallback/disambiguated operational name rather than inserting the potentially very long exact header into the alias field. A short empty/colliding source-header default still refuses rather than inventing a substitute.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.8,"Ordinary rematerialization preserves Store metadata, inherited RID, and inherited COL alias",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If a newly materialized column's exact logical key already exists in the inherited Store MAP, Data Sculptor must preserve that row's current COL alias unless the Work Order explicitly changes it. The successor MAP replaces only that logical row's column_filename with the newly created physical COL artifact filename. Ordinary rematerialization must preserve the inherited Store's exact common source_filename and rid_filename . It must not silently create a different Store, replace the Store RID, revert a user-facing Store/RID alias, or revert a COL alias to its source header. Every row in the successor MAP continues to carry that same common Store source_filename . WASM-002 has no executable operation that replaces rid_filename while preserving the same Store lineage. A different RID filename therefore cannot be introduced as ordinary successor-state continuity in this build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.9,Store MAP serialization is deterministic UTF-8 CSV,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Store MAP CSV files are encoded as UTF-8 without BOM and use LF ( 0x0A ) record termination. The exact eight-field header in W002-STOR-019.6 is written once as the first row. Fields use standard CSV quoting semantics: a field containing comma, double quote, CR, or LF is enclosed in double quotes, and embedded double quotes are doubled. No locale-dependent formatting is permitted. Every data row in one MAP must contain byte-for-byte identical values for store_alias , rid_filename , rid_alias , and source_filename . Mapping rows are written deterministically by ascending numeric source_column_number , then ascending UTF-8 byte order of source_header . Because one valid Store MAP has exactly one common source_filename , that field is not needed as a leading row-sort discriminator. Two rows with the same logical source-column key (source_filename, source_column_number, source_header) are invalid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.10,Only a complete validated Store MAP is eligible for inheritance,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A canonical MAP filename alone does not make a file a structurally valid Store MAP. For Store-MAP structural validity , the MAP artifact itself must be readable as complete UTF-8, have the exact eight-column schema, parse deterministically, satisfy Store-level consistency, lineage, deterministic row-order, mapping-key, and alias constraints, and carry structurally valid governed RID/COL filename bindings. The present health of the referenced RID/COL artifacts is a separate question and does not determine whether the MAP itself is structurally valid. A Store MAP remains part of governed Store history when its own bytes, schema, lineage facts, and deterministic structural rules are valid even if a referenced RID or COL later becomes missing or invalid. Referenced-artifact damage therefore does not make the current structurally valid Store MAP disappear and does not by itself cause fallback to an older MAP. F-03 current Store MAP selection Current-state selection is performed independently within one exact Store lineage. Only structurally valid Store MAP artifacts participate. Among those MAPs, the ordinary frozen chronology rule selects the unique structurally valid MAP with the greatest canonical UTC millisecond timestamp. A structurally malformed newer MAP is never current. If a newer canonical MAP artifact is structurally malformed, Data Sculptor uses the greatest earlier structurally valid Store MAP in that same lineage, if one exists, and reports the malformed newer artifact through governed Help/evidence surfaces. This fallback applies to structural MAP invalidity only. It does not apply merely because a structurally valid current MAP references a damaged RID or COL. If two or more structurally valid MAPs share the greatest canonical UTC millisecond timestamp, current authority is ambiguous and selection refuses rather than breaking the tie by UUID, discovery order, directory order, or filesystem modified time. P3-07 routing distinction: Store-MAP inheritance eligibility is stricter than lineage discovery. A Store lineage participates in exact- SOURCE routing when at least one Store MAP in that lineage is structurally valid, even if the current Store later evaluates DEGRADED or INVALID . Referenced RID/COL health is evaluated after routing and may cause refusal; it must not make an already discoverable lineage disappear. For successor publication, after the required RID/COL physical promotions have succeeded, Data Sculptor uses the already-established publication-transaction UTC and allocates a MAP-specific UUID before opening the complete deterministic MAP CSV under its governed SCR candidate identity. The SCR filename therefore already carries the exact UTC, UUID, and .csv extension intended for the final MAP identity. The candidate is closed successfully, reopened, and validated for bytes, schema, Store-level consistency, aliases, RID binding, COL bindings, deterministic row order, and all other MAP eligibility rules while it remains SCR . Only after that validation succeeds may Data Sculptor promote the candidate by host rename that changes only the three-letter semantic class token from SCR to MAP . The candidate bytes, UTC, UUID, and extension must remain unchanged across promotion. The successful rename is the publication/commit point. If validation or rename fails, no successor MAP becomes eligible/current; the candidate remains or is retained as visible non-authoritative SCR evidence. Store-aware automatic selection therefore continues to use the greatest earlier valid MAP in the same Store lineage, if one exists, while Help reports the failed candidate/publication rather than silently treating it as current state. P3-06 governed artifact-validation tiers. Store-health status and full content validity are distinct assurances. The following two tiers are normative for WASM-002: Tier 1 — Store-health structural validation. Used for routine Store status, source routing, historical-MAP health gates, inheritance decisions that do not consume analytical artifact contents, and alias-only maintenance. The selected Store MAP itself is fully parsed and structurally validated because it is the compact authority for the snapshot. A referenced RID passes Tier 1 only when the exact MAP-bound governed RID filename is present and readable, the bytes begin with exactly one UTF-8 BOM, the first logical record is a canonical N=<value> header, the final byte is LF, and the physical byte length equals the deterministic length implied by the canonical RID representation for that declared N . Tier 1 does not rescan every RID data record merely to perform routine status or alias work. A referenced COL passes Tier 1 only when the exact MAP-bound governed COL filename is present and readable, begins with exactly one UTF-8 BOM, exposes the canonical one-column CSV header whose decoded value exactly equals the MAP row's recorded source_header , and ends with LF. Tier 1 does not stream every COL value merely to establish routine Store health. Tier 2 — full artifact validation. Used whenever an operation actually consumes RID/COL contents, for complete validation of newly created candidates before commit, and by REPAIR MAP after the repair operation has been validly entered. A RID passes Tier 2 only when a full stream proves the canonical N=<value> header, exactly N data records, and exact ordered values 1..N . A COL passes Tier 2 only when a full stream proves canonical one-column CSV encoding/serialization, the exact expected header, and exactly N logical data records aligned to the Store RID. VALID , DEGRADED , and INVALID are Store-health states evaluated from the governed current snapshot using the required validation tier; they are not claims of cryptographic historical identity. When REPAIR MAP is validly invoked, it must perform Tier 2 validation of the RID and every mapped COL that would survive into the successor. The deterministic repair result removes exactly the mapped COL bindings that fail that Tier 2 check, subject to the separately frozen refusal when no mapped COL would remain. Two implementations presented with the same bytes must therefore identify the same repair set. External restoration boundary: a file placed back under an original governed RID/COL physical filename may re-enter use only when it passes the validation tier required by the operation. Filename equality plus governed validation is sufficient for operation eligibility under this WASM-002 boundary; it is not proof that the restored bytes are the historical original bytes. Stronger historical-byte identity requires separate authoritative fingerprint evidence. P3-10 terminology boundary: Store-state repair is REPAIR MAP . Work Order alias-registry repair is REPAIR WORK ORDER REGISTRY . These are distinct governed operations and the integrated specification must not describe a Store REPAIR MAP Work Order as a “registry-repair Work Order.” This corrects wording only; it does not change either operation's frozen semantics. F-08 / F-03 REPAIR MAP Work Order structure and target precondition: SUITCASE: .
WORK ORDER AS ""Repair Crime Store""
MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""
REPAIR MAP Exactly one MAP ""<filename>"" clause is mandatory. It names the exact physical filename of one structurally valid Store MAP. At Run time, that named MAP must be the current structurally valid Store MAP for exactly one lineage and the target Store must currently evaluate DEGRADED . A historical Store MAP, WKO MAP, missing MAP, malformed MAP, ambiguous equal-latest current state, MAP from an unsupported profile, or target Store that does not evaluate DEGRADED refuses. No SOURCE , Store/RID/COL alias selector or mutation, KEEP , materialization, conversion, Inventory, registry repair, cataloging, or composition clause is supplied in the same WKO. The analyst selects the Store by exact current Store MAP identity; Data Sculptor determines which mapped non-RID COL bindings are broken. The terminal DS-STEPS clause is REPAIR MAP ; the Receipt operation token is separately REPAIR_MAP . P2-03 monotonic eligibility boundary: structural validity/eligibility and chronology are separate. A structurally valid future-dated Store MAP remains a structurally valid MAP and participates in current-state selection. It is not demoted merely because the host clock is presently earlier. The monotonic guard applies when publishing a successor: truthful observed transaction UTC must be strictly greater than the chronology predecessor UTC before any successor state may commit. P2-04 closure — validation depth is now complete. The Tier-1/Tier-2 rules in this requirement are the complete WASM-002 oracle for deciding whether a MAP-bound RID/COL is sufficiently valid for the operation being attempted. Tier 1 is intentionally bounded and is used only by operations that do not consume RID/COL analytical contents. Tier 2 is a full streaming validation and is mandatory before an operation relies on RID/COL contents, for newly created candidates before commit, and for REPAIR MAP . REPAIR MAP determinism. Once a valid REPAIR MAP operation is entered, Data Sculptor performs Tier 2 on the Store RID and on every mapped COL. The repair successor removes exactly those mapped COL bindings whose physical COL artifacts fail Tier 2, preserves exactly those that pass Tier 2, and still refuses if zero mapped COL bindings would remain. No shallower Tier-1 result may decide the repair set. F-03 repair semantics: after target validation, Data Sculptor confirms the named MAP is current for exactly one Store lineage, confirms the referenced RID is valid, identifies every mapped non-RID COL that is missing or invalid under the required repair validation tier, preserves every valid COL binding unchanged, removes exactly the broken COL bindings from the successor candidate, preserves the exact Store lineage RID identity and remaining Store/RID metadata, validates the complete successor MAP candidate, and publishes the successor only if every repair gate succeeds. REPAIR MAP does not reread or regenerate the source CSV, rematerialize a lost COL, regenerate the RID, or edit the predecessor MAP in place. F-03 all-COLs-broken refusal: if removing the broken bindings would leave zero COL mapping rows, REPAIR MAP refuses. No zero-COL Store MAP is introduced, no special anchor row is invented, no successor MAP is published, and the Store remains DEGRADED . The existing current structurally valid MAP and RID continue to anchor the visible lineage. Identity boundary. Passing Tier 1 or Tier 2 proves only that the currently visible file under the exact governed filename satisfies the applicable WASM-002 validation contract. It does not prove that those bytes are historically identical to bytes previously present under that filename. Cryptographic historical-byte identity belongs to separately governed fingerprint evidence rather than ordinary Store health. F-15 reference-bounded eligibility: Store-MAP structural validity and inheritance eligibility are determined from the MAP artifact itself plus the governed artifacts and values that the MAP explicitly binds or that its profile explicitly requires for the validation tier being applied. Unrelated Suitcase files, unrelated Store lineages, WKOs, Receipts, Inventories, CAT/HLP/CER artifacts, analyst-owned files, directory enumeration order, and unrelated-file count cannot by their mere presence or later appearance make an already-published Store MAP eligible or ineligible. Alias-shadowing validation is a successor-publication check under W002-STOR-020; it is not a continuing ambient scan that retroactively invalidates historical MAPs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.11,The MAP-bound RID filename is the stable physical Store identity anchor in WASM-002,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, Data Sculptor does not allocate a second permanent Store UUID in addition to governed RID/MAP evidence. The exact governed rid_filename created when the Store is established is the stable physical anchor used to distinguish that Store's MAP lineage from other Stores in the same Suitcase, and every ordinary successor MAP repeats it exactly. Within any one MAP, every row must repeat the same exact current rid_filename ; disagreement is invalid. Across WASM-002 successor MAPs, a different RID filename denotes a different Store row universe and must not be silently treated as same-Store continuation. A later PRD revision may define an explicit governed recovery transition if Red5Sorcery chooses to support replacement of a damaged RID while preserving logical continuity. No such transition is executable in WASM-002.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.12,First Store MAP has deterministic Store and RID aliases,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When the first successful materialization establishes a Store, its first Store MAP must initialize store_alias to the exact common source_filename and rid_alias to the literal RID . Those are the deterministic Store and RID default aliases. A later alias-only Work Order may replace them with STORE AS ""<alias>"" and RID AS ""<alias>"" , clear them with CLEAR STORE ALIAS / CLEAR RID ALIAS , or restore these defaults with RESET STORE ALIAS / RESET RID ALIAS under W002-WKO-012.1 through W002-WKO-012.6. None of those operations changes the common source_filename , rid_filename , RID bytes, COL bytes, or prior MAP history.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-001,CAT is the governed collection-level Store Catalog artifact,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"WASM-002 shall define CAT as a governed Data Sculptor artifact class for cataloging a collection of CSV Stores inside one active Suitcase. CAT exists to let an analyst orient across many independently governed Stores without opening every MAP individually. The scaling invariant is: MAP governs locally; CAT orients globally. CAT is an index over governed Store state, not a replacement for MAP and not a second Store authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-002,CAT may reference many Stores while every MAP still governs exactly one Store,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"A CAT may contain entries for many Store lineages in the active Suitcase. Every MAP referenced by CAT still governs exactly one Store lineage under the frozen one-Store-per-MAP rule. CAT must not combine multiple Stores into one MAP, synthesize a shared Store state, or centralize Store semantics that remain governed independently by each Store's MAP lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-003,CAT has one governed CSV representation and immutable snapshot identity,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The WASM-002 Store Catalog has one durable representation: UTF-8 CSV. WASM-002 shall not emit separate HTML and CSV companion CAT artifacts for one catalog snapshot. Each successful catalog publication creates one immutable governed artifact named exactly __DS__CAT__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv . A later catalog run publishes a new CAT snapshot; earlier CAT artifacts remain visible history and are not overwritten or deleted merely because a newer snapshot exists. For orientation, the directory may identify the newest structurally valid CAT snapshot by the canonical UTC token. If two or more structurally valid CAT artifacts share the greatest canonical UTC timestamp, the UI must not invent chronology from UUID, discovery order, or filesystem modified time; it must surface the ambiguity and may present the tied CAT artifacts together until a later governed catalog run publishes an unambiguous newer snapshot. F-14 publication: CAT is first written as __DS__SCR__<UTC>__<UUID>.csv using the UTC/UUID intended for the final CAT. The complete candidate must close, reopen, and validate the exact five-column schema, deterministic row ordering, row count and CSV serialization before the class token may be renamed to CAT . A failed candidate remains SCR/non-authoritative and must not be selected as a catalog snapshot.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-004,CAT CSV schema and row order are exact and deterministic,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The canonical CAT header row is exactly: store_alias,source_filename,rid_filename,map_filename,store_health Each data row describes one routable Store lineage using values derived from the authoritative current structurally valid Store MAP selected under the existing Store rules: store_alias — current human-facing Store identity; source_filename — the one common exact source filename carried by that Store MAP and used for Store routing; rid_filename — exact immutable governed RID filename that physically identifies the Store lineage; map_filename — exact current structurally valid Store MAP used to derive the row; and store_health — the Store health evaluated during this CATALOG STORES run, exactly one of VALID , DEGRADED , or INVALID . store_health is snapshot orientation metadata, not MAP health and not an independent health authority. If the Suitcase later changes, an older CAT row continues to report the health value observed when that CAT was created. CAT rows are sorted by ascending exact UTF-8 bytes of map_filename . The header is not part of that ordering.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-005,CAT is reconstructible and never becomes Store authority,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"CAT shall be reconstructible from authoritative Store MAP artifacts and the governed Store-health evaluation applied when CATALOG STORES runs. CAT must never be consulted to decide Store routing, inheritance, Store health, repair eligibility, current MAP selection, RID/COL validity, or whether a new Store may be established. If a CAT row conflicts with authoritative MAP/Store state, current governed state wins and the CAT is stale/inconsistent. A stale CAT remains an inspectable historical governed artifact but must not be treated as current Store truth. CAT is not automatically updated by materialization, repair, alias change, or any other Store-changing operation. The analyst creates a fresh catalog explicitly by running a new CATALOG STORES Work Order; success publishes a new immutable CAT snapshot and leaves earlier CAT snapshots visible history.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-006,CATALOG STORES is the standalone governed Work Order operation,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 Work Order form is: SUITCASE: .
WORK ORDER AS ""Catalog Stores""
CATALOG STORES CATALOG STORES is one standalone top-level operation. It is initiated only by an explicit analyst Work Order. No materialization, repair, alias update, conversion, or other governed operation automatically creates, rewrites, or refreshes CAT. The operation scans authoritative governed Store MAP state, evaluates each cataloged Store's current health, and publishes one CAT snapshot plus the normal canonical Receipt. It does not mutate any Store or MAP. It must not also request materialization, conversion, alias mutation, repair, Inventory, Work Order composition, or another consequential operation in the same WKO. The canonical Receipt operation token is CATALOG_STORES .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-007,CATALOG STORES derives one row per routable Store lineage from authoritative MAP state,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The catalog scan shall identify every routable Store lineage using the same structurally-valid-MAP routing definition already frozen for WASM-002. For each routable lineage, Data Sculptor evaluates current Store health exactly under W002-STOR-019.2, using the current structurally valid Store MAP selected under W002-STOR-019.10 and the applicable validation tier, and records exactly one of VALID , DEGRADED , or INVALID . Catalog presence is orientation, not permission to perform another operation. Exactly one CAT row is emitted for each routable Store lineage, derived from that lineage's authoritative current structurally valid Store MAP and the Store-health result observed during this catalog run. If the complete authoritative collection state cannot be determined unambiguously, the operation must refuse rather than publish a knowingly incomplete or guessed CAT. CATALOG STORES is read-only with respect to all pre-existing Store, RID, COL, MAP, source, WKO, and other Suitcase artifacts. It does not repair or mutate them.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-008,CAT publication is all-or-refuse and historical CAT snapshots remain visible,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"After the complete deterministic CAT row set is established, publication follows the governed all-or-refuse artifact path: write the candidate under governed scratch, close and reopen it, validate its exact filename, UTF-8/LF CSV structure, exact header, deterministic row count/order, and row references, then promote the final CAT artifact. The CAT is not successfully published until final promotion succeeds. A publication refusal leaves prior CAT snapshots and all Store/MAP state unchanged. The Receipt records whether the catalog entry count was established and whether a final CAT filename was published.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-001,CAT and MAP discovery reuse the existing Suitcase Directory,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,WASM-002 shall reuse the existing Data Sculptor Suitcase Directory for CAT and MAP discovery and inspection. A separate CAT/MAP browser panel shall not be added.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-002,CAT and MAP artifacts are first-ranked in the existing directory,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The newest unambiguous structurally valid CAT snapshot, or any tied newest CAT candidates when chronology is ambiguous, and all Store MAP artifacts shall be surfaced prominently at the top of the existing Suitcase Directory ahead of ordinary Suitcase files. The presentation may be pinned, grouped, or otherwise first-ranked, provided the priority is obvious and deterministic.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-003,CAT and MAP contents are immediately viewable from the existing HTML UI,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,The analyst shall be able to select a visible CAT or MAP entry and inspect its contents through the existing read-only HTML UI without first locating or opening the artifact through the operating-system file browser.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-004,CAT/MAP prominence preserves ordinary read-only Suitcase filtering,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The Suitcase Directory may continue to provide read-only filtered views of other Suitcase files. CAT/MAP prominence must not remove, replace, or weaken the existing ability to inspect the rest of the flat Suitcase.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-005,Directory browsing and inspection do not require a Work Order,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"Browsing, sorting, UI filtering, selecting, opening, and viewing Suitcase files are read-only inspection actions and shall not require a Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-006,Read-only directory filtering is not governed SEARCH,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"Read-only UI filtering is not the same operation as governed SEARCH . Governed SEARCH, ZIP creation, metadata changes, repairs, CAT regeneration, and every other consequential state change remain subject to the applicable Work Order and Receipt discipline.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-007,"The directory cannot mutate CAT, MAP, Store, or Suitcase state",W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The Suitcase Directory shall not edit, rename, delete, repair, replace, regenerate, or otherwise mutate CAT, MAP, Store, or Suitcase state through direct GUI manipulation. Consequential changes occur only through explicit governed operations or analyst-owned filesystem actions already permitted by the canonical contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-008,The CAT/MAP directory view must remain practical at large collection scale,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The CAT/MAP presentation shall make collections containing dozens or hundreds of Stores practical to inspect. An analyst must be able to understand what Stores exist, which current MAP describes each Store, and which source file each Store governs without manually opening every MAP artifact through the operating-system file browser.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-ACC-001,CAT acceptance proves collection-scale orientation without centralizing Store authority,W002-CAT-ACC,W002-CAT,WASM-002,UNDER REVIEW,—,"Acceptance must include a MusicBrainz-scale fixture containing 177 routable CSV Store lineages, each with its own authoritative current Store MAP. One explicit analyst-run CATALOG STORES Work Order must publish exactly one CAT snapshot containing exactly 177 data rows under the frozen five-column schema store_alias,source_filename,rid_filename,map_filename,store_health and deterministic MAP-filename ordering. The fixture must include Stores that evaluate VALID , DEGRADED , and INVALID while retaining structurally valid current MAPs, and the CAT must record the exact health observed for each Store when the catalog run occurs. The CAT must not expose a separate MAP-health field. The existing Suitcase Directory must surface CAT and MAP artifacts ahead of ordinary files; the analyst must be able to open CAT, inspect the collection, select and view MAP artifacts, sort/filter the directory, and inspect other Suitcase files without a Work Order. No direct GUI mutation path may be exposed. Acceptance must alter authoritative MAP/Store state after the first CAT publication and prove that the earlier CAT is neither rewritten nor automatically refreshed. It remains visible and becomes stale/inconsistent where appropriate. Only a later explicit CATALOG STORES Work Order may reconstruct the collection and publish a new immutable CAT snapshot. The linked WASM-003 DIR behavior remains outside the WASM-002 implementation scope: later DIR requirements auto-populate human-readable CAT/MAP descriptions, but those descriptions never become authority over CAT, MAP, or Store semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-020,"Store, RID, and COL aliases remain human-facing metadata separate from physical identity",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Aliases are governed human-facing metadata. Creating, changing, clearing, or replacing an alias must not rename or rewrite the underlying artifact. Within one Store MAP, every non-empty COL alias and the non-empty rid_alias must be unambiguous within the row-addressable artifact alias namespace under the exact Unicode scalar-value comparison rule in PB-STOR-010. F-15 publication-time shadowing boundary: alias uniqueness and physical-name shadowing are validated when a candidate successor Store MAP is being published, against the comparison domain applicable to that one Store snapshot and the then-visible governed physical targets it makes row-addressable. If an alias would exactly collide with another addressable alias or physical filename in that publication domain, publication refuses. After a Store MAP has been validly published, the later appearance, disappearance, rename, or copying-in of an unrelated Suitcase file does not retroactively make that immutable MAP structurally invalid or ineligible. A later textual reference can still become ambiguous at resolution time under W002-STOR-021; that ambiguity causes the later operation to refuse rather than changing the historical MAP's validity. The store_alias names the Store as a whole and is separate from the field/COL alias namespace. Alias mutation occurs through a governed Work Order, not through an editable GUI field. Exact cross-Store Store-alias uniqueness and future selection-by-Store-alias syntax remain outside this freeze.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-021,Work Order resolution binds one exact Store MAP and physical targets,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A saved Work Order may refer to governed materialized columns by exact physical filename or by a unique COL alias from one selected Store MAP. The canonical explicit Store-MAP selector is MAP ""<exact Store MAP filename>"" under W002-STOR-019.3 and W002-WKO-012.3. If that clause is present and valid, exactly that Store snapshot is used. Otherwise Data Sculptor applies the Store-aware source-qualified selection rule in W002-STOR-019.2. All textual physical-filename and COL-alias comparisons in this resolution step use exact Unicode scalar-value sequence equality under PB-STOR-010: no case folding, Unicode normalization, trimming, locale equivalence, or filesystem enumeration heuristic is permitted. Resolution is bounded to the selected Store snapshot and the physical targets/aliases that are addressable through that snapshot. If the supplied text has no exact target, resolution refuses. If it has more than one exact possible target in that domain—for example because a currently visible physical filename and a current alias are both exact matches—resolution also refuses. Data Sculptor must not choose filename over alias, alias over filename, first-found entry, directory order, modified time, UUID, or any other tie-break heuristic. Before execution, Data Sculptor must record the exact physical Store MAP identity when one is used, bind the run to its exact rid_filename , and resolve aliases deterministically to physical COL artifacts. The selected Store MAP must remain fixed for the run even if a newer MAP is created during that same run. This protects Store/selection continuity but does not by itself claim that bytes stored under an analyst-owned source filename are cryptographically identical across different runs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022,Each successful Suitcase validation publishes one retained governed CER HTML certificate,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A selected directory becomes a validated Suitcase only when Data Sculptor successfully creates, completely writes, and closes one governed CER HTML Suitcase Validation Certificate in that directory. The certificate itself is the validation artifact and remains visible in the flat Suitcase as durable evidence. No validation-only delete or rename is required. Failure to create, completely write, or close the certificate means the directory has not passed Suitcase validation and analytical execution remains locked. F-14 CER exception: the CER is deliberately not staged as SCR . Suitcase validation is specifically the direct create/write/close test of the final canonical CER identity in the selected directory. Inserting an SCR-to-CER rename would test a different publication path and is therefore forbidden for this validation step. A successful CER does not pre-certify later SCR-to-final renames for other artifact classes. F-24 CER lifecycle: every successful explicit Suitcase selection and validation publishes exactly one fresh immutable CER with a new governed UTC+UUID identity. Data Sculptor must not satisfy a new validation event by reusing an earlier CER. Every prior valid CER remains a standalone historical artifact under its original governed filename and exact bytes. WASM-002 performs no automatic CER deletion, replacement, compaction, or CER-history ZIP packaging. Historical CERs are not housekeeping candidates merely because a newer CER exists. Any later archival or packaging capability must be separately governed and explicitly invoked; it is not part of the WASM-002 validation lifecycle.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.1,Suitcase Validation Certificate physical identity and longest-name path gate,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The exact certificate filename is __DS__CER__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html , using the canonical UTC millisecond token and canonical lowercase hyphenated UUID v4. Data Sculptor chooses the filename; the analyst does not supply or edit it. The CER create/write/close test begins only after the browser host has satisfied the required user-selected writable-directory capability in W002-PLAT-001. A browser that cannot expose that capability produces a host-capability refusal before folder validation; that condition is not evidence that any particular directory is unwritable or filename-incompatible. WASM-002 path/filename acceptance must derive the maximum filename length from every governed final-artifact filename form and every governed SCR staging form that this build can actually emit. Under the current contract, the maximum is 73 ASCII bytes/characters : the governed .html CER/HLP final forms and an SCR candidate reserved for a .html final artifact have that length. The canonical CER filename therefore exercises the current maximum emitted filename length during the create/write/close validation test. On a supported host, successful create/write/close of this canonical governed HTML filename is the WASM-002 folder filename/path compatibility test for the current emitted-name maximum. Data Sculptor does not maintain a product-level table of operating-system numeric path maxima and must not truncate, abbreviate, hash-shorten, or otherwise mutate a governed filename to fit a host path limitation. If the certificate cannot be created under its canonical name after a directory has actually been selected through the supported-host contract, the selected directory does not pass validation. If a future PRD revision introduces an emitted final or staging filename longer than the current CER/HLP/SCR-HTML maximum, acceptance must detect that change and explicitly exercise the new maximum before the build may rely on this path-compatibility claim.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.2,Suitcase Validation Certificate semantic content,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The HTML certificate uses the canonical built-in Data Sculptor presentation and must visibly contain, at minimum: SUITCASE VALIDATION CERTIFICATE RESULT: PASS SUITCASE: . UTC: <canonical certificate UTC> UUID: <certificate UUID> ARTIFACT: <full governed certificate filename> TEST: CREATE_WRITE_CLOSE It must state that Data Sculptor successfully created, completely wrote, and closed this governed HTML certificate in the selected Suitcase. It must state that this establishes that the selected directory was writable by Data Sculptor at the recorded UTC and accepted the governed artifact filename used for the certificate. It must also state that the certificate does not certify available disk capacity, guarantee success of future analytical operations, or certify later SCR -to-final-class publication/rename operations. The semantic record uses SUITCASE: . and must not persist an absolute machine-specific path merely to prove validation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.3,Suitcase Validation Certificate uses the canonical built-in presentation in WASM-002,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The certificate is a human-facing HTML CER artifact and uses the canonical built-in Red5Sorcery/Data Sculptor presentation in WASM-002. Presentation must never change RESULT , SUITCASE , UTC, UUID, artifact identity, TEST , validation meaning, or limitation facts. Configurable Brand Manifest application to CER artifacts is deferred to V1-BACKLOG / a future build and is not required for WASM-002 Suitcase validation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-023,Non-Store governed artifacts use class-specific all-or-refuse publication profiles,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Except for the deliberate CER Suitcase-validation path below, WASM-002 does not place a newly generated durable artifact into its final semantic class merely because candidate bytes exist. The complete candidate is first written under the governed SCR identity defined by W002-STOR-023.1, closed, reopened, and validated against the target class contract. Only a candidate that passes its class-specific publication predicate may be renamed into the intended final class. A final-class filename therefore records successful class publication, not broader authority where a separate MAP/registry relationship governs authority. F-33 reserved-class boundary: DGN , RCV , BRD , and LCK are registered but not emitted by WASM-002, so they do not appear as publication profiles in this table and have no WASM-002 producer here. Final class Final serialization / identity Publication predicate Authority boundary WKO __DS__WKO__<UTC>__<UUID>.txt The complete candidate obeys the saved-Work-Order lifecycle and parses completely under exactly one WASM-002 executable operation grammar with the required SUITCASE: . , exactly one non-whitespace WORK ORDER AS alias, and the governed lexical/comment rules. Applicable save-time alias/registry gates must also pass before the save transaction may commit. Promotion proves a valid immutable WKO artifact. Alias-registry authority is not committed until the complete successor WKO MAP is successfully published under W002-STOR-018.3. RCP __DS__RCP__<UTC>__<UUID>.txt The complete candidate validates against W002-RCP-005 through W002-RCP-008: exact deterministic TXT serialization, common envelope, applicable operation-specific key table, governed absence semantics, and created-artifact tail. Publication creates durable run evidence only. It does not retroactively create or change analytical state. HLP __DS__HLP__<UTC>__<UUID>.html The complete self-contained HTML satisfies the HLP disclosure, presentation, provenance, embedded-JSON, lineage and semantic-parity rules in W002-HELP-009 and related Help requirements. Publication creates durable Help/support evidence. It does not override the underlying diagnostic event or analytical state. CVT __DS__CVT__<UTC>__<UUID>.csv The bounded Windows-1252 conversion completes, the original analyst-owned source remains unchanged, the converted bytes pass the governed strict UTF-8 requirement, and the candidate closes/reopens successfully. Structural CSV interpretation remains a later certification/materialization concern. The published exact CVT filename is a new immutable governed source identity for later routing under W002-CONV-004. INV __DS__INV__<UTC>__<UUID>.txt The complete inventory scan has established the governed entry set and the candidate validates the deterministic INV serialization, count, metadata availability and ordering rules. Publication creates an immutable inventory snapshot; it is evidence/orientation, not Store authority. CAT __DS__CAT__<UTC>__<UUID>.csv The authoritative MAP discovery/evaluation pass has completed and the candidate validates the exact five-column CAT schema, row count, row ordering and deterministic CSV rules. Publication creates an immutable collection-level orientation snapshot. MAP remains authoritative for each Store. CER __DS__CER__<UTC>__<UUID>.html Deliberate exception: Suitcase validation directly creates, completely writes and successfully closes the final CER identity under W002-STOR-022 through W002-STOR-022.3. No SCR staging/rename is inserted into this test. The CER proves that canonical governed create/write/close succeeded in the selected directory at that recorded moment. It does not pre-certify later SCR-to-final publication. RID, COL, Store MAP and WKO MAP publication retain their specialized transaction/commit rules elsewhere in this PRD. W002-STOR-023 does not replace those state-publication contracts; W002-STOR-023.1 supplies the shared SCR candidate identity and retained-failure-evidence boundary they may reference.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-023.1,SCR candidates preserve intended final identity; retained failure evidence remains non-authoritative,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical candidate filename for a staged governed artifact is: __DS__SCR__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.<final-extension> The SCR candidate uses the exact UTC token, UUID and extension reserved for its intended final artifact. Successful publication changes only the three-letter semantic class token from SCR to the intended final class. For example, an RCP candidate __DS__SCR__20261006T190000000Z__<uuid>.txt may become __DS__RCP__20261006T190000000Z__<uuid>.txt only after the complete candidate has been closed, reopened and validated against the RCP publication predicate. The rename must not alter candidate bytes, UTC, UUID or extension. An SCR filename never by itself confers final-class validity, Store membership, registry authority, execution authority, or durable final-class evidence status. A retained SCR whose bytes happen to satisfy a target validator after an interrupted or refused transaction must not be auto-promoted, silently adopted, or treated as if the missing publication step occurred. F-33 retained-failure-evidence boundary: when a handled failure leaves one or more SCR candidates or other staged bytes that cannot be safely removed or restored, they must remain visible only as non-authoritative SCR evidence. WASM-002 does not publish an RCV recovery manifest. Retention must not complete or simulate the failed publication step, and the governed diagnostic/Help path must report the failure using only facts actually established. A retained or orphaned SCR remains non-authoritative even if its bytes later validate. Data Sculptor must not infer an intended final class solely from extension or byte content, must not rename or promote the SCR merely because it survives a later scan, and must not create a replacement RCV sidecar to manufacture attribution that the failed transaction did not durably preserve.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-011; CP-012; CP-013; CP-014,"CP011 T-ACCEPTED, GIT BANKED — exact CVT-to-SCR candidate identity derivation only; full SCR lifecycle and publication contract remains open; CP012 T-ACCEPTED, GIT BANKED — canonical SCR staging filename recognition only; generic publication, recovery and authority remain unimplemented; CP013 T-ACCEPTED, GIT BANKED — explicit SCR-to-RCP final filename candidate derivation only; no complete SCR lifecycle, RCP validator, filesystem promotion, publication or authority; CP014 T-ACCEPTED, GIT BANKED — related RCP final-candidate lexical recognition only, no SCR creation or publication",e84ae5baeee05f9d5d30284c65b86eebba3c0f6a; efca04392940e398020a5c06b9ee50296c8a1fdd; 005a38ef5e876847c4c08901c18da9c18565fd6b; f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,"Evidence/CP-011/CP011_Scope_Lock.txt; Evidence/CP-011/CP011_RED_Test_Output.txt; Evidence/CP-011/CP011_GREEN_Test_Output.txt; Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt; Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt; Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt; Evidence/CP-011/CP011_Hash_Inventory_Verification.txt; Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt; Evidence/CP-011/CP011_Closing_Git_Review.txt; CP011_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-012/CP012_Scope_Lock.txt; Evidence/CP-012/CP012_RED_Test_Output.txt; Evidence/CP-012/CP012_GREEN_Test_Output.txt (initial 5/6, retained); Evidence/CP-012/CP012_GREEN_Failure_Triage.txt; Evidence/CP-012/CP012_GREEN_Correction_Review.txt; Evidence/CP-012/CP012_GREEN2_Test_Output.txt; Evidence/CP-012/CP012_Full_Regression_Test_Output.txt; Evidence/CP-012/CP012_WASM_Build_Output.txt; Evidence/CP-012/CP012_Final_Rustfmt_Check.txt; Evidence/CP-012/CP012_Hash_Inventory_Verification.txt; Evidence/CP-012/CP012_Supplementary_Hash_Verification.txt; Evidence/CP-012/CP012_Post_Staging_Hash_Verification.txt; Evidence/CP-012/CP012_Closing_Git_Review.txt; CP012_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-013/CP013_Approved_Scope_Lock.txt; Evidence/CP-013/CP013_RED_Test_Output.txt; Evidence/CP-013/CP013_GREEN_Test_Output.txt; Evidence/CP-013/CP013_Full_Regression_Test_Output.txt; Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt; Evidence/CP-013/CP013_WASM_Build_Verification.txt; Evidence/CP-013/CP013_Hash_Inventory_Verification.txt; Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt; Evidence/CP-013/CP013_Closing_Hash_Verification.txt; Evidence/CP-013/CP013_Final_Staging_Verification.txt; Evidence/CP-013/CP013_Closing_Git_Review.txt; CP013_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip; CP014_Git_Banking_Record.txt (external closeout)","CP011 Day066: public pure helper build_scr_candidate_filename_for_cvt(&str)->Option<String> accepts an exact canonical governed CVT .csv filename (via CP010 recognizer) and derives the paired SCR filename by substituting only class token CVT -> SCR, preserving exact UTC, UUIDv4 and lowercase .csv bytes; rejects wrong classes, paths, whitespace, malformed clock/date/UUID, extension and class case. Six targeted tests; RED expected E0432 exit 101; GREEN 6/6; post-format native regression 46/46; rustfmt recheck PASS; Rust 1.97.1 wasm32-unknown-unknown --lib build PASS; original 28/28 and combined 36/36 SHA-256 records verified. Two local scoped .gitattributes whitespace exceptions preserve Rustfmt/Git diagnostic TXT bytes; final Git staged check PASS. T-approved and Git banked e84ae5baeee05f9d5d30284c65b86eebba3c0f6a, 27 committed files, working tree clean. Lexical candidate-name pairing ONLY; no SCR creation, bytes, converter, transaction, close/reopen, validation/publication, retained SCR adoption, SOURCE authority or browser execution. Independent Claude implementation QA pending. CP012 Day066: pure public bool recognizer is_canonical_scr_filename_candidate(&str) validates exact uppercase SCR staging class via shared canonical immutable filename-token parser, with local rejection of whitespace and both path separators; accepts canonical .csv and .txt SCR candidates without assuming extension or bytes confer intended final class, validity, publication or authority. RED expected missing import E0432 exit 101. Initial GREEN 5/6 exposed trailing whitespace acceptance through generic extension grammar, retained verbatim; controlled CP012-local correction yielded 6/6 PASS. Full native regression 52/52 PASS, Rustfmt 12 Rust files checked/0 modified, canonical Rust 1.97.1 wasm32-unknown-unknown --lib build PASS (not browser execution). Primary independent SHA256/size inventory 29/29 PASS; supplementary original 4/4 PASS; post-staging 6-record amendment independently verified following narrowly scoped trailing-space and blank-at-EOF git attributes for preserved diagnostic evidence; final staged Git whitespace exit 0. T approved and banked Git commit efca04392940e398020a5c06b9ee50296c8a1fdd (28 committed files; master clean). Previous generic canonical parser unchanged. W002-STOR-023.1 remains PARTIAL, no filesystem creation, close/reopen, class publication, retained/orphan SCR adoption or recovery, SOURCE authority, or independent Claude implementation QA claimed. CP013 Day066: pure public function build_final_filename_candidate_for_scr(&str, &str)->Option<String> accepts only a canonical SCR staging filename with exact lowercase .txt serialization and explicit intended_final_class == ""RCP""; derives RCP final filename candidate by substituting the SCR semantic-class token only, preserving original UTC token, UUID and extension. Rejects all other class intentions, malformed or non-SCR staging names, paths/whitespace, wrong extension or case. Six intentional RED tests (unresolved E0432 before implementation), six GREEN targeted passes; full native 58/58 PASS; Rust 1.97.1 rustfmt check PASS and wasm32-unknown-unknown --lib build PASS (not browser runtime). Primary 21/21, supplementary 27/27 before attribute revisions; post-normalization 32/32 and closing 37/37 SHA-256 identity/byte-preservation checks; 42/42 commit blobs verified, Git whitespace check exit 0 after directory-scoped CRLF-aware whitespace attributes and raw-byte preservation; staging failures and adjustments retained byte-for-byte. T accepted and Git banked 005a38ef5e876847c4c08901c18da9c18565fd6b (efca04392940e398020a5c06b9ee50296c8a1fdd parent), 42 files, clean tree and index. This covers only lexical candidate-name derivation under already-PARTIAL W002-STOR-023.1; W002-STOR-023 remains NOT_STARTED; no SCR creation, RCP contract validation, promotion, publication, retained/orphan handling, authority or recovery. No independent adversarial QA or accepted end-to-end requirements; Day066 OPEN. CP014 Day067: T-accepted, Git-banked lexical RCP .txt filename recognizer only. Pure is_canonical_rcp_filename_candidate(&str)->bool uses shared canonical envelope, rejects wrong class/extension/casing, malformed UTC/UUID, paths and whitespace. Six target GREEN passes; 64/64 native regression; Rustfmt and wasm32 library build PASS; 32 original-TXT-per-ZIP objects validated and committed unchanged. Commit f5038a183f1d3dc31b0065571bf8ac8814b5d8a9. No new Receipt timestamp generation, Receipt byte serialization, creation/promotion/publication or authority; independent implementation QA and browser runtime pending.",Day067,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001,Strict whole-file UTF-8 certification,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Before WASM-002 performs analytical CSV materialization, it must certify the complete selected source as valid UTF-8 using bounded processing.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.1,"Certification must examine the entire source, not merely a prefix, sample, BOM, or first analytical window.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.2,"UTF-8 validity must be determined across chunk boundaries, including incomplete multi-byte sequences that span adjacent input windows.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.3,"A UTF-8 BOM, when present, is parsing metadata and must not be treated as proof that the remainder of the source is valid UTF-8.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.4,Certification must preserve exact source-byte accounting.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.5,Certification must operate within the governed WASM memory budget.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Stage 1 UTF-8 certification must remain bounded independently of source byte length and must not buffer the complete source, CSV header, or CSV row set in memory. CSV column-count and operational-name rules belong to Stage 2 and must not be used to justify unbounded Stage-1 state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.6,Certification must produce deterministic PASS or FAIL for the same source bytes under the same frozen rules.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002,UTF-8 certification is a hard analytical gate,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,The WASM-002 analytical/materialization path must proceed only after successful UTF-8 certification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.1,"If UTF-8 certification fails, the current analytical Work Order must stop.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.2,The analytical engine must not silently switch to another decoder.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.3,The analytical engine must not continue materialization under an inferred or guessed source encoding.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.4,No Windows-1252 transcoding may occur as an implicit sub-step of the failed analytical Work Order.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003,Certification and materialization share one run-local selected source,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"For a governed WASM-002 analytical run, the browser host must resolve the Work Order source reference once and retain the same selected source instance across Stage 1 UTF-8 certification and Stage 2 materialization. The purpose of this binding is to prevent Stage 2 from accidentally consuming a different source than the one Stage 1 certified. It is a run-local continuity guarantee, not a claim of durable cryptographic identity across separate runs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.1,Stage 2 must not re-resolve or substitute the source,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"After Stage 1 begins, Stage 2 must not reacquire the analytical source by re-reading an alias mapping, re-resolving a filename/path, opening a newly selected browser file, or otherwise substituting another source instance. Stage 2 consumes the source instance already bound to the governed run.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.2,"Filename, alias, path, or byte length alone is not durable byte identity",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Filename equality, alias equality, path equality, timestamps, or exact byte length may be useful provenance facts but must not be presented as cryptographic proof that source bytes are identical across separate runs. WASM-002 makes no such automatic cross-run exact-byte claim.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.3,Ordinary WASM-002 source binding does not require automatic SHA-256,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,UTF-8 certification and ordinary column materialization must not automatically compute SHA-256 merely to establish WASM-002 source binding. The source-binding requirement is satisfied by preserving the same run-local selected source instance across the two stages. This rule does not prohibit SHA-256 where another explicit WASM-002 requirement governs integrity for a specific generated artifact. It applies to automatic hashing of ordinary analytical source data.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.4,Loss of run-local source continuity causes refusal,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"If the browser host cannot preserve the selected source instance from certification into materialization, or the source becomes unavailable before Stage 2 can consume it, the analytical run must refuse before materialization rather than silently reselect, substitute, or infer another source.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004,ASCII-first inline UTF-8 certification algorithm,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"WASM-002 must use an ASCII-first, strict inline UTF-8 certification algorithm or an equivalent implementation that preserves the same single-forward-scan semantics, bounded state, deterministic validity result, exact error location, and performance intent established by WASM-001b.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.1,The certifier must process the source in bounded windows and must not allocate memory proportional to source-file size.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.2,"The 4 MiB window used in WASM-001b is a proven reference point, not a frozen WASM-002 production constant.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Window size may be changed only if semantics and byte-identical certification outcomes remain invariant.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.3,"At the beginning of each window, any incomplete UTF-8 sequence carried from the preceding window must be resolved before the remaining bytes are treated as independent input.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.4,"When there is no pending cross-window sequence, consecutive bytes below 0x80 must be recognized as ASCII and certified directly because ASCII is a complete subset of UTF-8.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.5,An all-ASCII window with no pending cross-window sequence must be certifiable without submitting the same bytes to a second general UTF-8 decoder pass.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.6,"When a byte at or above 0x80 is encountered, the certifier must validate the UTF-8 sequence inline, then resume the ASCII-fast scan after the valid sequence.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.7,"The implementation must not require collecting all non-ASCII bytes, all non-ASCII runs, or all non-ASCII offsets for later validation.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.8,The implementation must not require a separate general-purpose string-decoder call for each non-ASCII sequence.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,An equivalent low-overhead strict validator is acceptable if it preserves the same governed result and bounded-state behavior.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.9,Cross-window state must be bounded to the information required for at most one incomplete UTF-8 sequence.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"No more than three source bytes may need to remain pending between windows, or an equivalent smaller state representation may be used.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.10,"On the first invalid UTF-8 sequence, certification must stop and report the exact absolute source-byte offset required by the frozen error contract.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"On the first invalid UTF-8 sequence, certification must stop and return FAIL . The governed UTF-8 refusal evidence is: FIRST_INVALID_BYTE_OFFSET — the zero-based absolute byte offset of the first byte of the invalid sequence , counted from the first physical source byte, including a permitted leading UTF-8 BOM when present; and STOP_REASON — exactly INVALID_UTF8_SEQUENCE . For an EOF-truncated multibyte sequence, FIRST_INVALID_BYTE_OFFSET is the absolute offset of that incomplete sequence's lead byte, not the EOF position. The certifier need not read the remainder of an already-invalid source. Input-window boundaries must not change the outcome, stop reason, or first-invalid offset. F-16 follow-on boundary: stopping strict UTF-8 certification at the first invalid sequence does not make the remainder of the source irrelevant to conversion advice. When the governing operation is MATERIALIZE and Stage 1 reaches FAIL , the analytical run remains refused; Data Sculptor then starts the separate read-only compatibility assessment in W002-CONV-002 from physical byte offset 0 of the same bound source instance. That second pass may read to EOF solely to determine converter compatibility. Stage 2 must not start.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.11,"At EOF, certification may return PASS only if every source byte has been consumed under the strict UTF-8 rules and no incomplete sequence remains pending.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"At EOF, certification may return PASS only if every physical source byte has been consumed under the strict UTF-8 rules and no incomplete sequence remains pending. The completed Stage-1 outcome vocabulary is exactly PASS and FAIL . PASS means strict whole-source UTF-8 certification completed successfully. FAIL means an invalid UTF-8 sequence was deterministically established under W002-ENC-004.10. The common Receipt absence tokens remain separate from those completed outcomes: NOT_RUN when Stage 1 never begins, and NOT_AVAILABLE when Stage 1 begins but a separate failure prevents a governed PASS/FAIL conclusion. NOT_APPLICABLE is not a completed value for STAGE1_UTF8_OUTCOME .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.12,"A UTF-8 BOM at absolute source offset zero may be recognized as BOM metadata after its bytes are validated, but the remaining source must still undergo complete certification.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.13,"The certifier must not perform CSV delimiter, quote, header, row, or analytical interpretation.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Certification answers only whether the complete source byte stream is valid UTF-8 under the frozen rules.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.14,Certification results must be independent of window boundaries.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Splitting the same valid or invalid source at different bounded window sizes must not change PASS/FAIL or the first invalid absolute byte offset.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.15,"The certifier must expose enough measured counters for acceptance evidence to reconcile source bytes read, windows/pushes processed, non-ASCII sequences encountered when counted, final pending state, and stop reason without requiring those counters to alter certification semantics.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005,Strict UTF-8 byte-sequence rules,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"The inline validator must implement strict modern UTF-8 validity, excluding overlong forms, UTF-16 surrogate code points, values above U+10FFFF, invalid lead bytes, invalid continuation bytes, and truncated sequences. F-07 stop-reason vocabulary: all strict UTF-8 invalidity classes governed by this requirement—lone continuation bytes, malformed continuation sequences, overlong forms, surrogate encodings, values above U+10FFFF, invalid lead bytes, and EOF-truncated sequences—serialize the single machine reason token INVALID_UTF8_SEQUENCE . The specific fixture category is acceptance evidence; the canonical stop reason intentionally does not duplicate validator-library-specific subcodes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.1,Single-byte ASCII is 0x00 through 0x7F.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.2,Two-byte sequences must begin with 0xC2 through 0xDF and be followed by exactly one continuation byte 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.3,"Three-byte sequences beginning with 0xE0 must use a second byte 0xA0 through 0xBF and a third byte 0x80 through 0xBF, preventing overlong encodings.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.4,Three-byte sequences beginning with 0xE1 through 0xEC or 0xEE through 0xEF must use two continuation bytes 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.5,"Three-byte sequences beginning with 0xED must use a second byte 0x80 through 0x9F and a third byte 0x80 through 0xBF, excluding UTF-16 surrogate halves.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.6,"Four-byte sequences beginning with 0xF0 must use a second byte 0x90 through 0xBF followed by two continuation bytes 0x80 through 0xBF, preventing overlong encodings.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.7,Four-byte sequences beginning with 0xF1 through 0xF3 must use three continuation bytes 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.8,"Four-byte sequences beginning with 0xF4 must use a second byte 0x80 through 0x8F followed by two continuation bytes 0x80 through 0xBF, preventing code points above U+10FFFF.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.9,Bytes 0x80 through 0xBF are invalid when encountered as lead bytes.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.10,Bytes 0xC0 and 0xC1 are invalid lead bytes because they can only introduce overlong encodings.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.11,Bytes 0xF5 through 0xFF are invalid UTF-8 lead bytes.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"ASCII-first inline UTF-8 certification algorithm READ NEXT BOUNDED WINDOW Reference evidence used 4 MiB windows RESOLVE PENDING CROSS-WINDOW STATE At most one incomplete UTF-8 sequence ASCII FAST SCAN Advance cheaply while every byte < 0x80 ASCII RUN Already valid UTF-8 RESUME SCAN Same window BYTE >= 0x80 Validate sequence inline STRICT UTF-8 Lead + continuation range rules VALID END OF WINDOW? Persist only bounded carry state MORE SOURCE? Yes: read next window; No: finish EOF + NO PENDING STATE UTF-8 PASS INVALID OR TRUNCATED UTF-8 FAIL No full-file allocation. No collection of all non-ASCII bytes. No per-sequence general string decode required. Figure 2. The WASM-001b-derived fast path certifies ASCII directly, validates only non-ASCII sequences inline, and carries only bounded state across windows.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-006,Measured evidence inherited from WASM-001b,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"The following measurements are non-normative evidence explaining why WASM-002 begins with the ASCII-first inline algorithm. They are not WASM-002 acceptance results and must not be represented as such. EVID-W001B-UTF8-001 On the 7,250,808,204-byte Statistics Canada source, the Day 039 distribution experiment observed 659,103 non-ASCII bytes, approximately 0.009090063% of the file, across 329,551 non-ASCII runs/sequences; the maximum observed non-ASCII run was three bytes. EVID-W001B-UTF8-002 The Day 039 non-ASCII-only experiment submitted only 659,103 bytes to strict UTF-8 validation and completed in 12.664716 seconds at 545.998 MiB/s; it proved the source valid but still incurred 329,551 strict validation calls. EVID-W001B-UTF8-003 A 1 GiB A/B test showed that reducing validated bytes alone was not enough: the selective per-run strategy submitted 115,839 bytes in 57,919 strict calls but took 503.7536 ms, while the baseline submitted 113,246,208 bytes in 27 strict calls and took 411.3590 ms. UNRESOLVED SOURCE DAMAGE: preserved authoritative text continues “This supported removing per-run general-validator call overhead rather than merely shrinking” but the remainder has not been recovered. No missing words are inferred or supplied. EVID-W001B-UTF8-004 The final native inline scan certified all 7,250,808,204 bytes in 10.377870 seconds at 666.313 MiB/s, observed 329,551 non-ASCII sequences and 659,103 non-ASCII bytes, and made zero std::str::from_utf8 calls. EVID-W001B-UTF8-005 The same inline design was exercised in Microsoft Edge/WASM with 4 MiB transfers: the valid 7,250,808,204-byte source completed with 1,729 pushes, UTF8_VALID=true, and EOF_ALL_BYTES_VALID. That experimental run took 30.5858 seconds including file I/O, JS-to-WASM copy, and WASM validation. EVID-W001B-UTF8-006 A full-size deliberately invalid Edge/WASM fixture stopped early after 2,936,012,800 bytes and 700 pushes with UTF8_VALID=false and STOP_REASON=INVALID_UTF8_SEQUENCE rather than reading to EOF. EVID-W001B-UTF8-007 WASM-001b also retained malformed UTF-8 fixtures for stray legacy bytes, truncated sequences, lone continuation bytes, overlong encodings, UTF-16 surrogate halves, and 0xFE/0xFF invalid bytes. WASM-002 should reuse or regenerate equivalent acceptance fixtures with known invalid offsets.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001,Stage 2 consumes the source instance certified by Stage 1,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The structural CSV parser and materializer operate under the explicit invariant that the same run-local selected source instance has already passed governed whole-file UTF-8 certification. Stage 2 must not independently re-resolve the analytical source. Stage 1 establishes encoding validity. Stage 2 establishes CSV structure, row identity, selected values, and governed outputs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.1,Stage 2 must not independently re-decide the source encoding.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.2,Stage 2 must not contain an automatic Windows-1252 fallback.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.3,Stage 2 may perform only those byte/character checks required for correct CSV structural parsing and frozen analytical semantics.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.4,"Any implementation shortcut that would weaken the certified-source invariant must be treated as a PRD change, not an optimization.",W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.5,Stage 2 restarts at byte offset zero of the same certified source instance,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"After Stage 1 returns PASS, Stage 2 must begin its structural pass from absolute source byte offset zero using the same run-local selected source instance. Rewinding/re-reading the existing source handle is permitted; performing a new filename, alias, path, picker, or directory resolution is not. If the host cannot re-read that same selected source instance for Stage 2, the Work Order must refuse under the run-local source-continuity contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.6,Stage 2 consumes an offset-zero UTF-8 BOM as metadata before header parsing,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"If the certified source begins with the UTF-8 BOM bytes EF BB BF , Stage 2 must consume those three bytes before parsing the first CSV header field. They must not become part of the first source header or selected value. The BOM is recognized only at absolute source offset zero. The fact that Stage 1 already saw the BOM does not permit Stage 2 to skip or reinterpret arbitrary later bytes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.7,Stage 2 parses the header once and then continues directly into the data-record scan,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Within the Stage 2 forward source scan, Data Sculptor must parse the complete first logical CSV record as the source header, construct ordered header metadata including exact decoded header text and 1-based source ordinal, resolve and validate all Work Order selectors/aliases, and then continue from the first data record without restarting the source. Header resolution therefore does not add a third whole-file pass. A header-only valid CSV yields a zero-row materialization; a source with no valid header record refuses. P3-09 no-header-record refusal: after Stage 1 has certified the source, if Stage 2 reaches end-of-source without establishing any logical CSV record from which a header could be parsed, materialization must refuse with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD . This is the eighth governed Stage-2 structural CSV refusal token in the canonical oracle defined by W002-MAT-002.8. Its governed location facts are: CSV_SOURCE_BYTE_OFFSET = exact source byte length; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; CSV_FIELD_ORDINAL: 1 . Therefore a zero-byte source reports offset 0 , and a source containing only the UTF-8 BOM bytes EF BB BF reports offset 3 . A first logical record that exists but is blank remains governed by the already-frozen BLANK_LOGICAL_RECORD condition and must not be reclassified as NO_HEADER_RECORD . F-20 source-width boundary: the established header record may contain at most 16,384 physical source columns. Exactly 16,384 is valid; a header record containing 16,385 or more fields must refuse deterministically during header resolution before the first data record is consumed. The bound applies to the complete physical source width, not merely the requested KEEP set. Header processing must remain bounded. Exact decoded source-header text is authoritative source evidence and must be preserved for every selected/materialized column, but the implementation is not required to retain the complete decoded text of every unselected header after selector resolution when bounded metadata is sufficient.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.8,Stage 2 relies on Stage 1 UTF-8 validity rather than revalidating the file,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 must not run a second whole-file UTF-8 certification algorithm over the source. It may inspect bytes and decoded field content only as required for CSV structure, header/selector semantics, governed field-size limits, output serialization, and diagnostics. Any implementation that reintroduces redundant whole-source UTF-8 validation into Stage 2 is a measurable architectural regression unless separately justified and accepted.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002,One-pass multi-column materialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"A valid Work Order may request multiple source columns for materialization during the same bounded structural pass. For WASM-002 DS-STEPS, the requested set is expressed by one KEEP block containing one or more HEADER and/or COLUMN selectors under W002-STEPS-001 through W002-STEPS-004. F-20 KEEP-width boundary: one governed KEEP block may resolve from 1 through 16,384 distinct source columns, subject to the source itself containing no more than 16,384 columns. An empty KEEP or a request that cannot resolve within that bound refuses before data-row materialization.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.1,Requested columns must be resolved and validated before data-row materialization begins,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Every HEADER and COLUMN selector in the governed KEEP block must resolve to exactly one source column before any data-row materialization begins. Missing headers, ambiguous duplicate-header matches, invalid/out-of-range ordinals, duplicate resolved selections, invalid aliases, and successor-MAP alias collisions must refuse before the structural data-row pass. The resolved selection cardinality must be an integer from 1 through 16,384 . Resolution/validation must finish before the first data record is consumed, including operational-name/default-alias derivation and any deterministic oversized-header fallback required by W002-STOR-019.7.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.2,All selected columns are emitted from one forward data-record scan,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"After header/selector resolution, Stage 2 must traverse the source data records once regardless of whether the Work Order selects one column or many. The engine must not perform one complete source rescan per requested column. During that scan, every source field is interpreted structurally, but only the fields required by the resolved selection set are materialized into governed COL outputs. F-20 one-pass boundary: “one forward data-record scan” means one traversal of the source data records for the MATERIALIZE operation. WASM-002 must not reread source data records in batches merely because the selected-column set is wide. An implementation may perform additional bounded passes over Data-Sculptor-owned SCR , spool, or staging structures after the source scan when needed to finalize many outputs within resource limits; such passes must not reread the source data records or change governed output semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.3,One 1-based logical row ordinal aligns every selected output,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The header is not a data row. The first accepted logical data record is row identity 1, the next is 2, and so on through N. The row counter advances exactly once per accepted logical CSV data record, not per physical line. Every selected COL produced by the run must contain exactly one logical data record for each accepted source data row and therefore exactly N data records in the same governed order. A multiline quoted field remains part of one logical record and must not advance row identity merely because it contains physical newline bytes. When the run establishes a new Store, this 1..N sequence is published as that Store's one governed RID artifact. When the run extends an existing Store without changing its row universe, the existing RID is reused and must not be regenerated or renumbered.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.4,Selected-column writer order follows resolved KEEP order,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Before the data-record scan begins, the validated selection set is placed in the same order in which its selectors appear in the governed KEEP block. That resolved order governs writer creation, per-row selected-field dispatch, progress/receipt presentation, deterministic backpressure-drain priority, and candidate COL identity allocation. The Store MAP's own CSV mapping-row ordering remains governed separately by W002-STOR-019.9 and must not be confused with Work Order selection order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.5,Multiple active COL outputs use bounded staging and explicit backpressure,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Each active materialized-column writer, or an equivalent shared multiplexed output structure, must have bounded staging capacity. The aggregate kernel-owned staging state for all active writers must remain inside the governed WASM memory budget and must not grow with source row count or total output size. If a required output writer cannot accept additional canonical bytes without exceeding its governed staging capacity, source consumption must pause while pending output is drained/written. When more than one writer requires service, drain priority follows resolved KEEP order. After sufficient space is available, parsing resumes from the same structural state. The exact tuned staging-buffer size is an implementation/benchmark constant rather than an analytical semantic constant; changing it must not change output bytes, row identity, selection results, or diagnostics for the same governed input. F-20 writer-resource bound: KEEP width and simultaneously active writable resources are distinct. The accepted build must declare a finite implementation bound on simultaneously active writable-output resources and retain acceptance evidence of both that configured bound and the observed peak. The engine may satisfy a wide selection by bounded shared/multiplexed staging or a Data-Sculptor-owned spool followed by bounded finalization passes, but it must not require one simultaneously open writer per selected column. Changing the writer-resource bound must not change final bytes, row order, selection identity, aliases, Receipts, or diagnostics for the same governed input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.6,Partial output sets are never published as a successful materialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"All requested materialized-column outputs begin as visible governed SCR candidates, not COL artifacts. On first materialization of a new Store, the automatically generated RID likewise begins as a governed SCR candidate. Before any new RID/COL SCR candidate is opened, Data Sculptor establishes one publication-transaction UTC under PB-STOR-013/PB-STOR-014 and allocates a distinct artifact-specific UUID for each new candidate. Each candidate filename therefore already carries the exact UTC, UUID, and final extension intended for that RID or COL identity. A materialization transaction may begin promotion only when every required RID/COL candidate reaches EOF successfully, all selected outputs reconcile to the same accepted data-row count N, and all required candidate finalization/validation succeeds. F-04 existing-Store cardinality gate: when materialization targets an existing VALID Store, after Stage 2 establishes the complete candidate logical data-row count N and before any requested COL candidate is promoted, Data Sculptor must read the expected N from the already-valid inherited RID header and compare the two values. If candidate N equals RID-header N , the cardinality gate passes and ordinary publication may continue. If candidate N differs, the Run must refuse before any SCR -to- COL promotion and before successor-MAP publication. The inherited RID, current MAP, and existing COL artifacts remain unchanged, and the existing Store remains VALID. Equal N proves cardinality compatibility only; it does not prove source-byte continuity, row-semantic identity, or permission for a different SOURCE to enter the lineage. Exact SOURCE/Store compatibility rules are prior gates. For a new Store, Data Sculptor promotes the validated RID candidate first by host rename that changes only the class token from SCR to RID ; the candidate bytes, shared transaction UTC, RID-specific UUID, and extension remain unchanged. That successful SCR-to-RID promotion is the event that establishes RID_ACTION: CREATED and the published RID_FILENAME fact for the Run. Before that promotion succeeds, the Run has not created a governed RID even if a candidate identity has been allocated. For an existing Store, the inherited RID is reused unchanged and no RID candidate/promotion occurs. Once routing has selected and validated that exact inherited RID, that event establishes RID_ACTION: REUSED and the exact inherited RID_FILENAME ; later refusal does not erase the already-established reuse fact. After the required RID state is established, Data Sculptor promotes each requested COL candidate in deterministic resolved KEEP order by changing only the class token from SCR to COL ; each candidate's bytes, shared transaction UTC, COL-specific UUID, and extension remain unchanged. If RID or COL promotion fails, Data Sculptor must refuse the run and roll any newly promoted RID/COL names back out of their final namespaces where safely possible. Candidate or rollback bytes that cannot be safely restored or removed must be retained visibly as non-authoritative SCR failure evidence. The existence of an unreferenced RID- or COL-looking file after interruption does not by itself make that artifact committed Store state. After all required RID/COL promotions succeed, Data Sculptor allocates a MAP-specific UUID before opening the complete successor-MAP SCR candidate. That candidate uses the same publication-transaction UTC, the allocated MAP UUID, and the final .csv extension, and is constructed using the exact final RID/COL filenames. It is closed successfully, reopened, and validated completely while it remains SCR . Only then may the MAP candidate be promoted by changing only the class token from SCR to MAP ; its bytes, UTC, UUID, and extension remain unchanged. The successful SCR -to- MAP rename is the materialization commit point. Until that commit point, the prior valid MAP remains authoritative for an existing Store; for a new Store, no committed Store state exists yet. If MAP validation or MAP rename fails, Data Sculptor must refuse and roll the newly promoted RID/COL set back out of the final namespaces where safely possible; otherwise affected bytes remain attributable recovery evidence and are not committed Store membership. Governed Store membership/current state is established by a valid MAP binding, not by a final-class filename or timestamp equality alone. Revision BB preserves the Revision AY staging/promotion mechanics and Revision AZ shared transaction-UTC rule for newly published RID/COL/MAP artifacts. Selected-folder support for the canonical governed filename/path form is established by the Suitcase Validation Certificate under W002-STOR-022 through W002-STOR-022.3 rather than by a frozen numeric host path-length table. Operation-specific host rename or publication failure remains a governed refusal under this requirement and is not pre-certified by Suitcase validation. F-14 shared candidate grammar, reconciled by F-33: every RID/COL/MAP SCR candidate in this transaction follows W002-STOR-023.1: its SCR name already carries the UTC, UUID and extension intended for the final RID/COL/MAP identity, and successful promotion changes only the class token. Any retained SCR candidates after a handled publication/rollback failure remain visible non-authoritative failure evidence under W002-STOR-023.1 and are reported through the governed diagnostic/Help path; WASM-002 does not emit an RCV manifest. An orphaned SCR remains non-authoritative even if its bytes later validate.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.7,Successful materialization publishes one complete Store MAP,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"A successful governed materialization that creates one or more COL artifacts must also publish exactly one new complete immutable Store MAP under W002-STOR-019 through W002-STOR-019.12. For a new Store, that MAP binds the automatically generated and promoted RID to the Store metadata and all newly materialized COL mappings. For an existing Store, it preserves the inherited RID binding and complete prior Store state while applying the successful materialization updates. All required RID/COL SCR candidates must complete and validate before promotion begins. On a new Store, RID promotion occurs first; on an existing Store, the inherited RID is reused unchanged. All requested COL promotions must then succeed before successor-MAP candidate construction begins. The complete successor MAP is written as SCR , closed, reopened, and fully validated before entering the MAP namespace. Its final host rename from SCR to the governed MAP filename occurs last and is the materialization commit point. The materialization run is not reported as successfully committed until that MAP rename succeeds. If MAP candidate validation or MAP rename fails after RID/COL promotion, the run must refuse and the newly promoted artifacts must be rolled back out of their final namespaces where safely possible. Any failure residue that cannot safely be removed or restored is governed by W002-STOR-023.1 and remains non-authoritative retained failure evidence; its survival must not be used to infer or manufacture attribution or to simulate the failed publication step. The prior valid MAP remains authoritative for an existing Store; no committed Store is established for a first materialization without a valid successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.8,Stage 2 enforces deterministic source-record shape,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The parsed header establishes the expected source field count. Every nonblank logical data record must contain exactly that many fields after CSV parsing. A nonblank ragged record with fewer or more fields must refuse rather than pad, truncate, or shift later values. An explicit empty field is valid data and preserves its ordinal. A bare blank logical data record occurring outside a quoted field must refuse and must not be silently skipped or converted into one empty field. A physical blank line inside a valid quoted multiline field is field content, not a blank record. F-06 canonical malformed-CSV refusal facts Every structural CSV refusal records these governed facts: REFUSAL_CONDITION
SOURCE_BYTE_OFFSET
PHYSICAL_LINE
LOGICAL_RECORD
FIELD_ORDINAL SOURCE_BYTE_OFFSET is the zero-based absolute byte offset from the first physical byte of the source file. A leading UTF-8 BOM, when present, occupies offsets 0–2 and therefore counts in subsequent absolute byte locations. PHYSICAL_LINE is one-based and equals one plus the number of LF bytes strictly before the governed refusal location. LF bytes inside quoted multiline fields still increment physical-line count. LOGICAL_RECORD is one-based CSV logical-record ordinal and includes the header as logical record 1. The first data record is therefore logical record 2. FIELD_ORDINAL is the one-based field position within that logical record. These facts describe the same first structural refusal regardless of permitted streaming-window size or boundary placement. Canonical structural refusal tokens The seven frozen F-06 malformed-CSV tokens are: UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD
INVALID_BYTE_AFTER_CLOSING_QUOTE
BARE_CR_OUTSIDE_QUOTED_FIELD
EOF_INSIDE_QUOTED_FIELD
BLANK_LOGICAL_RECORD
TOO_FEW_FIELDS
TOO_MANY_FIELDS P3-09 adds NO_HEADER_RECORD as the eighth governed Stage-2 structural CSV refusal token. Parser-library names, host exceptions, crate-specific error enums, or localized descriptions must not replace these governed tokens. Governed refusal location by condition Condition Governed refusal location UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD Offset of the offending "" byte. INVALID_BYTE_AFTER_CLOSING_QUOTE Offset of the first prohibited byte after the closing quote. BARE_CR_OUTSIDE_QUOTED_FIELD Offset of the CR byte itself. EOF_INSIDE_QUOTED_FIELD One-past-end offset, equal to the physical source byte length. BLANK_LOGICAL_RECORD First byte of the record terminator that proves the blank record: LF for LF termination; CR for CRLF termination. TOO_FEW_FIELDS First byte of the record terminator that closes the short record; at EOF, one-past-end offset equal to source byte length. TOO_MANY_FIELDS The comma delimiter that begins the first field beyond the expected header width. NO_HEADER_RECORD One-past-end offset equal to the exact physical source byte length, with physical line 1, logical record 1, and field ordinal 1, as frozen by W002-MAT-001.7. Field ordinal rules For TOO_FEW_FIELDS , FIELD_ORDINAL is the first missing field ordinal: expected-width position immediately after the last field actually present. For TOO_MANY_FIELDS , FIELD_ORDINAL is the first extra field ordinal: header-width + 1. For quote/CR/EOF structural conditions, FIELD_ORDINAL is the current field ordinal in which the malformed condition is established. For BLANK_LOGICAL_RECORD , FIELD_ORDINAL is 1. For NO_HEADER_RECORD , FIELD_ORDINAL is 1. Bare CR scope A bare CR outside a quoted field is malformed CSV and refuses with BARE_CR_OUTSIDE_QUOTED_FIELD . CR inside a valid quoted field is ordinary field content. LF inside a valid quoted field is ordinary field content. CRLF inside a valid quoted field is ordinary field content. Outside quoted fields, CRLF is one accepted logical-record terminator and LF is one accepted logical-record terminator. Outside quoted fields, a CR not immediately followed by LF is malformed. EOF while quoted If EOF is reached while the parser remains inside an open quoted field, the source refuses with EOF_INSIDE_QUOTED_FIELD . Data Sculptor must not synthesize a closing quote, truncate the field, reinterpret prior bytes as unquoted content, or otherwise repair the source. First-condition precedence Stage 2 evaluates structural CSV input in absolute source-byte order and reports the earliest refusal condition that becomes deterministically established. CSV grammar errors take precedence over later row-shape errors. BLANK_LOGICAL_RECORD takes precedence over TOO_FEW_FIELDS for a physically blank logical record. BARE_CR_OUTSIDE_QUOTED_FIELD takes precedence over INVALID_BYTE_AFTER_CLOSING_QUOTE when the post-quote offending byte is a CR that is not followed by LF. At EOF while still inside a quoted field, EOF_INSIDE_QUOTED_FIELD takes precedence over field-count evaluation. No implementation may choose a different error merely because of parser buffering, window boundaries, library behavior, or host platform. Delimiter boundary Comma remains the only WASM-002 field delimiter. Automatic delimiter detection is outside the WASM-002 CSV contract. A file whose rows contain semicolons, tabs, or other non-comma separators may still be valid under the comma-only grammar as a one-column CSV. Data Sculptor must not invent a malformed-CSV refusal merely because another application would treat those bytes as delimiters. When a requested HEADER cannot be resolved, Help may explain that WASM-002 uses comma as the CSV delimiter and that semicolon/tab exports may therefore be interpreted as one field per row. Interaction with UTF-8 diagnostics This structural CSV refusal oracle applies only after the source has passed the applicable encoding-certification boundary. Invalid UTF-8 remains governed by the separately frozen UTF-8 diagnostic contract. Its zero-based absolute source-byte orientation is intentionally aligned with SOURCE_BYTE_OFFSET so WASM-002 does not have competing byte-coordinate systems.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.9,Unselected field contents are not retained,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 must parse every field sufficiently to preserve CSV structure, field count, row boundaries, and governed safety checks, but it must not retain complete contents for unselected fields after those bytes are no longer structurally needed. The engine must not materialize a complete source row, complete table, or complete unselected column in memory merely to emit selected columns. Selected-field content may use bounded accumulation required by the frozen field-size/output rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.10,Individual decoded CSV fields are limited to 16 MiB,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"WASM-002 carries forward the established Data Sculptor field-buffer safety boundary: an individual CSV field may contain at most 16 MiB (16,777,216 bytes) of decoded UTF-8 field content. This is an engineering safety limit, not a semantic statement about CSV or an Excel cell limit. The limit must be enforced incrementally for header and data fields. The parser must not first accumulate an arbitrarily large field and then check it. If a field would exceed the limit, the run must refuse without truncating, repairing, discarding the remainder, or finalizing the candidate materialization. For an unselected field, Data Sculptor may count decoded field bytes without retaining the field value; the safety limit still applies so malformed unterminated fields cannot turn the structural scan into unbounded growth. F-20 operational column-name boundary: after an exact source header field is decoded, Data Sculptor measures its length in Unicode scalar values, not UTF-8 bytes or grapheme clusters. If the exact decoded source header contains at most 1,024 Unicode scalar values, its operational column name is that exact header text. If it contains more than 1,024 scalar values, the operational column name begins from the deterministic physical-ordinal fallback Column <LETTERS> , where the letters are the Excel-style 1-based source ordinal ( A through XFD for the WASM-002 width bound). This operational name is a bounded human-facing/default-alias construct; it does not replace or truncate the authoritative exact source header.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.11,Materialized COL artifacts use canonical one-column UTF-8 CSV serialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Each finalized materialized COL artifact is a one-column CSV. It begins with exactly one UTF-8 BOM ( EF BB BF ) and uses LF ( 0x0A ) as the record terminator on every supported host. The first logical record contains the exact decoded source header text for that physical source column; an alias assigned with AS lives in the governed MAP and does not rewrite the physical COL header. A deliberately empty source header is serialized as one explicit empty header field rather than as absence of a header record. Header and data fields use deterministic minimal CSV quoting: quote when the field contains comma, double quote, CR, or LF; double embedded double quotes; otherwise write the field without quotes. Embedded CR/LF that belong to a quoted field remain field content. For a one-column data record whose decoded value is the empty string, serialize the value explicitly as """" so the row cannot be confused with a bare blank logical record. For fixed source bytes and fixed governed semantics, changing input/output window boundaries must not change the finalized COL bytes. F-20 source-fidelity rule: the physical COL header record always serializes the exact decoded source header, even when that header exceeds the 1,024 -scalar operational-name boundary and the Store MAP/default alias therefore uses an operational fallback. The fallback name must never be substituted into the COL header record or into the MAP source_header field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003,Stage 2 processes the source through bounded reusable windows,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,Structural materialization must process the certified source through bounded reusable input windows compatible with browser/WASM memory constraints. Source size and row count must not require proportional WASM memory growth.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.1,"The 4 MiB WASM-001b window is a proven reference point, not a frozen production constant",W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The 4 MiB source window used successfully during the WASM-001b browser experiments is an evidence-backed starting/reference size. WASM-002 may tune the production input-window size using benchmark evidence, provided the governed memory budget and all window-invariance requirements remain satisfied.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.2,Changing source-window size or boundary placement must not change results,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"For the same certified source and Work Order, permitted changes in bounded Stage 2 input-window size or boundary placement must not change CSV interpretation, resolved headers/ordinals, accepted row count, row identity, aliases, canonical COL bytes, successor MAP contents apart from newly allocated physical identities/timestamps, or the first deterministic refusal condition. P3-09 window invariance: for a Stage-1-certified source containing no logical CSV record, every permitted Stage 2 window size and boundary placement must produce the same NO_HEADER_RECORD refusal and the same governed location tuple: source-byte offset equal to the exact source byte length, physical line 1, logical record 1, field ordinal 1. F-06 full refusal-oracle window invariance: for the same certified source bytes, changing any permitted Stage 2 input-window size or boundary placement must not change whether the source is accepted or refused; the first REFUSAL_CONDITION ; SOURCE_BYTE_OFFSET ; PHYSICAL_LINE ; LOGICAL_RECORD ; or FIELD_ORDINAL . This applies to every structural CSV refusal governed by W002-MAT-002.8.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.3,CSV structure must survive arbitrary input-window boundaries,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Input-window boundaries may occur between ordinary field bytes, delimiter bytes, quote/escaped-quote pairs, CR/LF record-ending bytes, inside quoted multiline fields, and inside already-certified multi-byte UTF-8 sequences. The Stage 2 parser must preserve equivalent structural meaning across those boundaries.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.4,Cross-window parser state is small and explicit,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 may carry only the bounded state needed to continue the current logical CSV parse, including the current logical row ordinal, current field ordinal, quoted/unquoted state, escaped-quote/quote-transition state as required by the parser, pending CR/LF state, decoded-field byte count, resolved selected-field dispatch metadata, and bounded selected-field/output staging. The parser must not retain previous complete rows or source windows merely because a CSV record crosses a window boundary.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.5,Input-window and output-drain sizes are independent implementation controls,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The source read window, WASM transfer window where applicable, selected-field accumulator bound, and output-drain window are separate controls. One must not be silently treated as the maximum for another merely because an earlier prototype used the same numeric value. Any tuning must preserve the Stage 2 memory, backpressure, byte, and window-invariance contracts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.6,Stage 2 uses direct structural parsing rather than a required structural sidecar,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The WASM-002 baseline performs its Stage 2 work directly from the certified source stream. It must not require a precomputed comma/quote/newline position map, binary structural index, hidden cache, or OPFS sidecar before materialization can proceed. The previously discussed structural-sidecar comparison remains a separate future experiment and must not be introduced into WASM-002 as an unmeasured dependency.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.7,The Stage 2 algorithm is browser-first shared Rust core behavior,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The structural parser, row-count semantics, selector dispatch, canonical field serialization, and bounded output-state machine defined by Stage 2 belong in the shared Rust semantic core proven through the browser/WASM path first. A later native CLI host must call the same governed core rather than reimplementing competing materialization semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001,Conversion is a separate governed operation,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Windows-1252-to-UTF-8 conversion is a distinct governed Work Order operation, separate from UTF-8 certification and separate from analytical materialization. The analyst must explicitly authorize it. The canonical WASM-002 form is: SUITCASE: .
WORK ORDER AS ""Convert legacy source to UTF-8""
SOURCE ""legacy_source.csv""
CONVERT WINDOWS-1252 TO UTF-8 CONVERT WINDOWS-1252 TO UTF-8 is the terminal operation clause. Exactly one SOURCE is permitted. The same WKO must not contain KEEP , MATERIALIZE , Store/RID/COL alias mutation, MAP , Inventory, repair, cataloging, Work Order composition, or another operation terminal clause. F-10 conversion entry precondition Before CONVERT WINDOWS-1252 TO UTF-8 may begin character transcoding, Data Sculptor must validate the complete bound source as strict UTF-8 under the same deterministic whole-source certification rules used elsewhere in WASM-002. If the complete source is already valid strict UTF-8, the conversion refuses as unnecessary and publishes no CVT . Only after complete strict UTF-8 validation reaches governed FAIL may Data Sculptor assess the same complete bound source against the frozen Windows-1252 compatibility mapping. Only a source that fails strict UTF-8 and passes the complete Windows-1252 compatibility assessment may proceed to conversion. A failed analytical Work Order, UTF-8 certification, or materialization never silently invokes this operation. The analyst must explicitly authorize the separate conversion WKO.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.1,A failed analytical Work Order must not automatically invoke conversion.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.2,The user must explicitly choose or submit the separate conversion task.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.3,The original source file must remain unchanged.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.4,Successful conversion must create a new UTF-8 artifact with its own governed identity and receipt/evidence.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002,Windows-1252 compatibility assessment,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"After strict whole-source UTF-8 certification returns FAIL , the current analytical operation remains refused and Stage 2 must not start. As refusal handling, Data Sculptor performs one separate read-only Windows-1252 compatibility assessment from physical byte offset 0 of the same run-local bound source instance. The compatibility assessment scans the complete source sequentially under W002-CONV-002.1 through W002-CONV-002.5. It does not transcode, publish a CVT, modify the analyst-owned source, resume materialization, or claim that Windows-1252 is the historical encoding. Its sole governed result is whether the entire byte stream is mappable by the frozen WASM-002 Windows-1252 converter. If strict UTF-8 certification returned PASS , or did not reach a governed FAIL conclusion, this compatibility assessment is not run. F-10 conversion classification gate The conversion operation itself repeats/executes the complete classification gate on its bound source before transcoding: validate the complete source as strict UTF-8; if strict UTF-8 passes, refuse conversion as unnecessary; only after strict UTF-8 fails, scan the complete source against the frozen Windows-1252 mapping; if any source byte is undefined or unsupported by that mapping, refuse rather than guess; and begin transcoding only when strict UTF-8 has failed and the complete Windows-1252 compatibility assessment has succeeded. An undefined/unsupported Windows-1252 byte is therefore a pre-transcoding compatibility-assessment refusal . No CVT candidate may be represented as successfully converted from a source whose compatibility scan found an undefined byte. The compatibility assessment must not substitute U+FFFD , reinterpret an undefined Windows-1252 byte as ISO-8859-1, or use permissive host/library decoder behavior to make an incompatible source convertible.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.1,Compatibility means that the supported deterministic converter can map the observed source bytes under the frozen Windows-1252 rules.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Compatibility means that every physical source byte can be mapped deterministically by the complete normative WASM-002 Windows-1252 mapping in W002-CONV-002.4 . Successful EOF produces the governed outcome COMPATIBLE . No statistical detector, locale rule, browser guess, replacement character, ISO-8859-1 substitution, best-effort decoder, or PRODUCT-scoped glossary text participates as normative authority in this determination.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.2,Compatibility must not be described as proof that Windows-1252 was historically or authoritatively the file's original encoding.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"COMPATIBLE means only that the complete byte stream is convertible under Data Sculptor's frozen Windows-1252 mapping. It must not be described as proof that Windows-1252 was historically, authoritatively, or intentionally the source file's original encoding.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.3,Bytes undefined by the frozen Windows-1252 mapping must cause the compatibility assessment or conversion task to refuse rather than guess.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"If the compatibility pass encounters a byte that W002-CONV-002.4 defines as undefined, the assessment stops at the first such byte and returns INCOMPATIBLE . Data Sculptor must not substitute a replacement character, reinterpret the byte under another code page, or continue as though conversion were safe. A later explicit conversion Work Order must apply the same complete WASM-002 mapping and the same refusal rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.4,Complete normative WASM-002 Windows-1252 byte mapping,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"This requirement is the complete normative Windows-1252 mapping authority for WASM-002 . It covers all 256 possible byte values. No PRODUCT-scoped glossary entry or host/library decoder is required to interpret compatibility or conversion. 0x00–0x7F Every byte 0x00 through 0x7F maps one-to-one to Unicode U+0000 through U+007F . 0x80–0x9F Byte Windows-1252 mapping Unicode 0x80 EURO SIGN U+20AC 0x81 UNDEFINED — 0x82 SINGLE LOW-9 QUOTATION MARK U+201A 0x83 LATIN SMALL LETTER F WITH HOOK U+0192 0x84 DOUBLE LOW-9 QUOTATION MARK U+201E 0x85 HORIZONTAL ELLIPSIS U+2026 0x86 DAGGER U+2020 0x87 DOUBLE DAGGER U+2021 0x88 MODIFIER LETTER CIRCUMFLEX ACCENT U+02C6 0x89 PER MILLE SIGN U+2030 0x8A LATIN CAPITAL LETTER S WITH CARON U+0160 0x8B SINGLE LEFT-POINTING ANGLE QUOTATION MARK U+2039 0x8C LATIN CAPITAL LIGATURE OE U+0152 0x8D UNDEFINED — 0x8E LATIN CAPITAL LETTER Z WITH CARON U+017D 0x8F UNDEFINED — 0x90 UNDEFINED — 0x91 LEFT SINGLE QUOTATION MARK U+2018 0x92 RIGHT SINGLE QUOTATION MARK U+2019 0x93 LEFT DOUBLE QUOTATION MARK U+201C 0x94 RIGHT DOUBLE QUOTATION MARK U+201D 0x95 BULLET U+2022 0x96 EN DASH U+2013 0x97 EM DASH U+2014 0x98 SMALL TILDE U+02DC 0x99 TRADE MARK SIGN U+2122 0x9A LATIN SMALL LETTER S WITH CARON U+0161 0x9B SINGLE RIGHT-POINTING ANGLE QUOTATION MARK U+203A 0x9C LATIN SMALL LIGATURE OE U+0153 0x9D UNDEFINED — 0x9E LATIN SMALL LETTER Z WITH CARON U+017E 0x9F LATIN CAPITAL LETTER Y WITH DIAERESIS U+0178 0xA0–0xFF Every byte 0xA0 through 0xFF maps one-to-one to Unicode U+00A0 through U+00FF . Undefined-byte rule The only undefined byte values in this frozen WASM-002 mapping are exactly 0x81 , 0x8D , 0x8F , 0x90 , and 0x9D . Encountering any one of them makes the complete compatibility assessment INCOMPATIBLE at the first such byte and causes an explicitly run conversion Work Order to refuse before transcoding rather than guess. These three ranges plus the 32-position table above exhaust the byte domain 0x00–0xFF . No unlisted byte value exists.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.5,The compatibility check must itself be bounded and deterministic.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"The compatibility check is one bounded-memory deterministic sequential pass from physical source byte offset 0 to EOF unless the first undefined Windows-1252 byte is encountered earlier. Buffer/window size must not change the compatibility outcome or the first undefined-byte offset. On INCOMPATIBLE , WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET is the zero-based absolute physical source-byte offset of the first undefined byte. On COMPATIBLE , that offset is NOT_APPLICABLE . If the assessment begins but an independent read/host failure prevents a governed compatibility conclusion, the outcome is NOT_AVAILABLE and the first-undefined-byte offset is NOT_AVAILABLE . The assessment itself publishes no converted output.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003,Help suggestion after failed UTF-8 certification,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Help may suggest the separate CONVERT WINDOWS-1252 TO UTF-8 Work Order only when the governed engine emits DS-CNV-001 after a complete compatibility assessment returned COMPATIBLE . The suggestion is therefore derived from a governed diagnostic fact, not from the UTF-8 failure itself. If the assessment returns INCOMPATIBLE , is NOT_AVAILABLE , or did not run, DS-CNV-001 is not emitted and Help must not invent the conversion recommendation. P3-08 Help disclosure: when conversion succeeds, Help must state that the published CVT is a new governed source artifact with its own source identity and that converting a refreshed legacy source later will publish another distinct CVT rather than refresh an earlier CVT-backed Store lineage. When a CVT is selected for first materialization, Help must disclose the same consequence before or with the normal materialization guidance: the Store lineage is anchored to the exact CVT filename, not to the analyst-owned pre-conversion filename. Help must not imply hidden lineage continuity across separate CVT artifacts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.1,The suggestion must state that the current analytical task has stopped.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must state that the current analytical task has already stopped/refused because strict UTF-8 certification failed. DS-CNV-001 is informational and must not be rendered as though materialization can continue from the failed run.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.2,The suggestion must state that the original source has not been changed.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must state that the compatibility assessment was read-only and that Data Sculptor did not change the analyst-owned source. Any later successful conversion publishes a separate governed CVT artifact rather than editing the original source in place.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.3,"The suggestion must describe the source as compatible with the supported Windows-1252 converter, not definitively identified as Windows-1252.",W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must describe the complete source as compatible with Data Sculptor's supported Windows-1252 converter . It must not say that the source was definitively identified as Windows-1252 or imply provenance that the compatibility pass cannot prove.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.4,The suggestion must make clear that conversion is a separate user-authorized task.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"The suggestion must make clear that conversion is a separate user-authorized Work Order. next_action: RUN_WINDOWS_1252_CONVERSION means that the separate operation is a governed safe option; it is not permission for Data Sculptor to silently transcode, modify the source, or reinterpret the refused analytical Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.5,"If the bytes are not compatible with the supported converter, Help must not recommend Windows-1252 conversion as though it were safe.",W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"If the compatibility outcome is INCOMPATIBLE , NOT_AVAILABLE , or NOT_RUN , Help must not recommend Windows-1252 conversion as though it were safe. In particular, the mere presence of DS-ENC-001 never authorizes that recommendation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004,Canonical conversion output,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"A successful Windows-1252 conversion task must produce canonical UTF-8 output suitable for later submission to the normal UTF-8 certification and materialization path. P3-08 lineage consequence: the successful conversion output is a new immutable governed CVT artifact with its own exact physical filename. That CVT filename is the source identity used by later Store routing. A later conversion, including one made from a refreshed analyst-owned legacy source with the same original filename, publishes a different CVT and therefore does not refresh, replace, or continue an earlier CVT-backed Store lineage merely by name association. On first materialization, each distinct CVT begins a new Store lineage unless that exact CVT filename already routes to an existing lineage under the normal Store rules. F-14 CVT identity and publication: the final converted-source filename is exactly __DS__CVT__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv . Conversion writes first to the corresponding W002-STOR-023.1 SCR identity with the same UTC, UUID and .csv extension. Only after bounded conversion completes, the candidate closes/reopens successfully, and the converted bytes satisfy the governed strict UTF-8 requirement may the class token be renamed to CVT . CSV structural interpretation remains governed by the later normal certification/materialization path; CVT publication does not assert that the converted source is structurally valid CSV. F-10 conversion semantics — encoding conversion only The conversion operation performs deterministic character transcoding only. It does not parse, repair, normalize, or reinterpret CSV structure. Commas remain commas. Double quotes remain double quotes. Ordinary ASCII bytes retain the same byte value. LF remains LF. CR remains CR. CRLF remains CRLF. Embedded CR/LF bytes are preserved in place; the converter does not decide whether they are record terminators or field content. Canonical UTF-8 output therefore means deterministic UTF-8 encoding of the accepted source characters, not normalization of line endings, quoting, delimiters, records, headers, or fields. F-10 BOM rule The published CVT is UTF-8 without a BOM ; Data Sculptor does not prepend EF BB BF . If the source failed strict UTF-8 classification, a leading source byte sequence EF BB BF is not blindly stripped as though it were a UTF-8 BOM. Under the Windows-1252 conversion path those source bytes are source data and are mapped according to the frozen Windows-1252 mapping. BOM interpretation remains subordinate to encoding classification rather than acting as a blind prefix-removal rule.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-010; CP-011,"CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open; CP011 T-ACCEPTED, GIT BANKED — CVT-to-SCR lexical staging-name pairing only; complete conversion requirement remains open",b7c515faa9bd000369d7656e09437310261290ae; e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,"Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived); Evidence/CP-011/CP011_Scope_Lock.txt; Evidence/CP-011/CP011_RED_Test_Output.txt; Evidence/CP-011/CP011_GREEN_Test_Output.txt; Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt; Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt; Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt; Evidence/CP-011/CP011_Hash_Inventory_Verification.txt; Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt; Evidence/CP-011/CP011_Closing_Git_Review.txt; CP011_Git_Banking_Output.txt (post-commit, separately preserved)","CP010 Day066 first-touches ONLY the F-14 canonical final CVT output filename grammar subconstraint: is_governed_cvt_source_filename_candidate(&str)->bool recognizes exact canonical __DS__CVT__<UTC>__<UUIDv4>.csv lexical form by reusing existing envelope validation. Four targeted tests + 40/40 full native regression PASS; wasm32-target build PASS; T accepted and banked b7c515faa9bd000369d7656e09437310261290ae. No encoding conversion, SCR creation, close/reopen, UTF-8 validation, CVT publication, immutable physical output, source authority, or CSV structural checks; entire W002-CONV-004 remains PARTIAL, independently unreviewed. CP011 Day066: public pure helper build_scr_candidate_filename_for_cvt(&str)->Option<String> accepts an exact canonical governed CVT .csv filename (via CP010 recognizer) and derives the paired SCR filename by substituting only class token CVT -> SCR, preserving exact UTC, UUIDv4 and lowercase .csv bytes; rejects wrong classes, paths, whitespace, malformed clock/date/UUID, extension and class case. Six targeted tests; RED expected E0432 exit 101; GREEN 6/6; post-format native regression 46/46; rustfmt recheck PASS; Rust 1.97.1 wasm32-unknown-unknown --lib build PASS; original 28/28 and combined 36/36 SHA-256 records verified. Two local scoped .gitattributes whitespace exceptions preserve Rustfmt/Git diagnostic TXT bytes; final Git staged check PASS. T-approved and Git banked e84ae5baeee05f9d5d30284c65b86eebba3c0f6a, 27 committed files, working tree clean. Lexical candidate-name pairing ONLY; no SCR creation, bytes, converter, transaction, close/reopen, validation/publication, retained SCR adoption, SOURCE authority or browser execution. Independent Claude implementation QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.1,The converted artifact must itself be certifiable as UTF-8.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.2,The conversion Receipt identifies the governed source encoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for a successful governed Windows-1252-compatible conversion must identify exactly SOURCE_ENCODING: WINDOWS-1252-COMPATIBLE . That operation-specific fact is carried within the canonical TXT Receipt governed by W002-RCP-001 through W002-RCP-010. Only that exact serialized spelling is permitted for this key/value pair.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.3,The conversion Receipt identifies the materialized UTF-8 encoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for a successful governed conversion must identify exactly MATERIALIZED_ENCODING: UTF-8 . This uses the canonical KEY: VALUE serialization frozen by W002-RCP-005. MATERIALIZED_ENCODING=UTF-8 is not valid canonical Receipt serialization.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.4,The conversion Receipt identifies bounded streaming transcoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for successful conversion must identify that transcoding was performed under the governed bounded/streaming conversion contract.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.5,No analytical column materialization occurs as part of this conversion operation.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001,Canonical diagnostic truth,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every governed user-visible failure or warning produced by WASM-002 must originate as a canonical diagnostic event. A diagnostic event must have a stable identity and structured facts independent of its final wording. Governed success/status events that participate in the Help/status/evidence system—such as a successfully saved Work Order or a successfully validated Suitcase—are canonical INFO diagnostic events and obey the same identity/fact/behavior contract. Ordinary static labels, headings, decorative copy, and presentation-only status text are not automatically diagnostics merely because they are visible in the UI.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.1,Canonical diagnostic IDs use the frozen DS-<DOMAIN>-<NNN> grammar,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry one stable identifier using the exact form DS-<DOMAIN>-<NNN> . DOMAIN is exactly three uppercase ASCII letters A through Z. NNN is exactly three decimal digits, zero-padded, in the range 001 through 999 . Examples include DS-ENC-001 , DS-WKO-001 , DS-STO-001 , DS-MAT-001 , and DS-HLP-001 . A diagnostic ID is permanent after allocation and must never be reused for a different diagnostic meaning. Severity, host, build/release, source filename, path, UUID, byte offset, row/column number, count, timestamp, occurrence ID, and other run-specific facts must not be encoded into the diagnostic ID; those values belong in structured diagnostic fields. The identifier is the canonical lookup key used by the Help message catalog. Day 060 H-04 pre-freeze identifier normalization: the Windows-1252 compatibility suggestion diagnostic is DS-CNV-001 . It follows the same exact three-letter DOMAIN grammar as every other diagnostic ID. No four-letter DOMAIN exception exists in the current WASM-002 contract. Any pre-H-04 draft spelling of this diagnostic is superseded and is not valid build-registry input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.2,Diagnostic severity uses one exact token set,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry exactly one severity token: INFO , WARNING , or ERROR . Severity classifies the condition for human and machine interpretation. It does not itself determine whether execution continues or refuses; that authority is carried separately by the canonical behavior field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.3,Diagnostic phase uses a stable uppercase token,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must identify the governed operation or phase using an uppercase ASCII snake-case token matching [A-Z][A-Z0-9]*(?:_[A-Z0-9]+)* . Examples include WORK_ORDER_VALIDATION , SOURCE_CERTIFICATION , MATERIALIZATION , STORE_PUBLICATION , and HELP_REPORT . These examples do not constitute a closed global phase list; the fixed phase for each allocated diagnostic is declared by that diagnostic's registry entry.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.4,Structured diagnostic facts are declared per diagnostic,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The canonical event carries diagnostic-specific evidence in a structured facts object. Fact keys use lowercase ASCII snake case matching [a-z][a-z0-9]*(?:_[a-z0-9]+)* . Each diagnostic registry entry declares disjoint required_facts and optional_facts sets. Every required fact must be present when that diagnostic is emitted. An optional fact key may be omitted when that fact is not emitted for the event, but omission itself has no governed absence-state meaning : it must not be interpreted as NONE , NOT_RUN , NOT_AVAILABLE , NOT_APPLICABLE , false , zero, or an empty string. An emitted fact key that is not declared for that diagnostic is invalid. For structured JSON diagnostic facts, an established ordinary value retains its native JSON type. When a present diagnostic fact must express one of the shared governed absence states, its value is the exact JSON string ""NONE"" , ""NOT_RUN"" , ""NOT_AVAILABLE"" , or ""NOT_APPLICABLE"" , with the meaning frozen by F-18. JSON null is not a generic encoding for diagnostic-fact absence; it is permitted only where a specific JSON schema explicitly declares a nullable field and defines what that null means, as W002-HELP-009 does for HLP lineage. A required diagnostic fact may not be silently omitted, defaulted, converted to null , guessed, or replaced by a Help-layer value. If Data Sculptor attempts to establish a registered diagnostic but cannot produce one or more facts declared required for that diagnostic, the intended diagnostic is not emitted . Instead the engine emits DS-HLP-001 under W002-HELP-001.8. The replacement event records the intended diagnostic ID and the complete sorted set of missing required fact names. No partially populated copy of the intended diagnostic may be presented beside it. This fail-closed substitution is a diagnostic-contract integrity rule, not a presentation fallback. It preserves the F-17 boundary that diagnostics own facts and Help renders only complete governed diagnostic truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.5,Execution behavior is explicitly CONTINUE or REFUSE,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry exactly one execution-behavior token: CONTINUE or REFUSE . This field is the governed continue/refuse decision for the event. Help wording, severity, UI color, or presentation must not independently weaken, strengthen, or reinterpret it.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.6,Safe next action uses a stable token rather than Help prose,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry a next_action token using uppercase ASCII snake case matching [A-Z][A-Z0-9]*(?:_[A-Z0-9]+)* . NONE is the canonical value when no safe governed next action applies. The token expresses stable machine-readable intent; Casual, Office Speak, and Technical wording for that action belongs to the Help layer. Run-specific values such as timestamps, paths, UUIDs, byte offsets, filenames, counts, or occurrence IDs remain structured facts and do not change the diagnostic identity or fixed next-action meaning. Damaged-Store guidance is part of the safe-next-action contract. When ordinary materialization refuses because exact source routing identifies an INVALID Store lineage, or a DEGRADED lineage whose every mapped COL is broken and therefore cannot be reduced to a non-empty successor by REPAIR MAP , the selected Help voice must preserve the same frozen choices and consequences rather than inventing a recovery operation. The explanation must identify the blocked lineage/current MAP and distinguish: external restoration under the original governed physical filename followed by the required governed validation tier; source rename to deliberately begin a separate new Store lineage; and analyst retirement of the damaged lineage by moving all of that lineage's Store MAPs out of the active Suitcase root. For retirement, Help must warn that moving only the latest MAP can expose an older structurally valid MAP as current. Help must not claim that matching the original filename proves historical byte identity, and must not describe any of these analyst filesystem actions as Data Sculptor-authored repair, deletion, RID regeneration, or silent lineage replacement. P3-07 malformed-MAP routing guard: when ordinary materialization refuses because no routable Store lineage can be established while one or more structurally malformed Store-MAP-class artifacts are present in the active Suitcase, Help must identify the malformed MAP artifact or artifacts and state that new-Store/RID creation was blocked to prevent a silent lineage fork. Help must not describe the missing structurally valid MAP as proof that the prior Store never existed, and must not invent a Data Sculptor repair or replacement operation for this condition. P3-10 delimiter-hint clarification: when Stage 2 refuses with INVALID_BYTE_AFTER_CLOSING_QUOTE and the offending byte is semicolon ( 0x3B ) or horizontal TAB ( 0x09 ), Help may include the governed delimiter-mismatch hint even though the refusal occurred before header-delimiter resolution. The hint is explanatory only: it must not change the canonical refusal condition, location facts, behavior, or safe-action boundary. F-16 conversion-suggestion boundary: strict UTF-8 refusal diagnostic DS-ENC-001 has fixed next_action: NONE . UTF-8 failure alone does not establish that any converter is safe. Only the separate compatibility diagnostic DS-CNV-001 , emitted after the complete governed Windows-1252 compatibility assessment returns COMPATIBLE , may carry next_action: RUN_WINDOWS_1252_CONVERSION . That token identifies a safe separately authorized option; it never resumes or rewrites the refused analytical Work Order. Day 060 H-12 damaged-lineage diagnostic binding ordinary MATERIALIZE refusal for a routed INVALID Store uses DS-MAT-014 and its declared facts; ordinary MATERIALIZE refusal for a DEGRADED Store whose every mapped COL is broken uses DS-MAT-015 and its declared facts; the no-routable-lineage / malformed-Store-MAP guard uses DS-MAT-016 and its declared facts. These specialized allocations are what permit closed-world Help to identify the blocked lineage/current MAP or malformed MAP artifacts without adding unrelated facts to the ordinary DS-MAT-010 validation diagnostic. Day 060 H-26 / BM-09 ordinary DEGRADED routing binding. When ordinary MATERIALIZE exact-source routing identifies a DEGRADED Store whose RID is valid and at least one mapped non-RID COL remains valid, the refusal uses DS-MAT-017 . Its fixed next_action is RUN_REPAIR_MAP because REPAIR MAP is the safe governed Store mutation for this repairable DEGRADED state. Help must use the diagnostic's declared current_map_filename as the exact MAP identity the analyst must name in the separate governed REPAIR MAP Work Order. The token does not run repair automatically and does not mutate the refused MATERIALIZE Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.7,"The governed engine emits the diagnostic semantic core, not voice-authored prose",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The shared Rust/WASM diagnostic path must provide the canonical semantic core required by Help: diagnostic_id , severity , phase , behavior , facts , and next_action . The fixed values and permitted fact-key sets for an allocated diagnostic are governed by diagnostics.json . Casual, Office Speak, and Technical prose belongs to the Help rendering layer rather than being duplicated as authored message sets inside the governed engine. Host/build/occurrence metadata may be carried by surrounding governed execution evidence, but it must not redefine the diagnostic semantic core. F-16 closed-world Help rule: Help may recommend the WASM-002 Windows-1252 conversion Work Order only when the governed engine emitted DS-CNV-001 . Help must not infer compatibility from DS-ENC-001 , byte appearance, file extension, locale, browser behavior, heuristic encoding detection, or prose outside the diagnostic facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.8,diagnostics.json is the canonical WASM-002 diagnostic registry build resource,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The human-inspectable development/build source for the WASM-002 diagnostic registry is exactly diagnostics.json , encoded as UTF-8 without BOM. It is Data Sculptor product/build content, not a Suitcase artifact; it must not use the __DS__ namespace, consume an artifact-class token, or be copied into an analyst's Suitcase merely because Data Sculptor runs. The top-level JSON object has exactly two fields: registry_version and diagnostics . registry_version is the string ""1"" . diagnostics is an array written in ascending UTF-8 byte order of diagnostic_id . Each diagnostic entry has exactly seven fields: diagnostic_id , severity , phase , behavior , next_action , required_facts , and optional_facts . Diagnostic IDs must be unique and satisfy W002-HELP-001.1. Severity, phase, behavior, and next-action values must satisfy W002-HELP-001.2 through W002-HELP-001.6. required_facts and optional_facts are arrays of canonical fact-key strings sorted in ascending UTF-8 byte order; keys must be unique within each array and the two arrays must be disjoint. {
  ""registry_version"": ""1"",
  ""diagnostics"": [
    {
      ""diagnostic_id"": ""DS-CNV-001"",
      ""severity"": ""INFO"",
      ""phase"": ""SOURCE_CERTIFICATION"",
      ""behavior"": ""CONTINUE"",
      ""next_action"": ""RUN_WINDOWS_1252_CONVERSION"",
      ""required_facts"": [""source_filename"", ""windows_1252_compatibility_outcome""],
      ""optional_facts"": []
    },
    {
      ""diagnostic_id"": ""DS-ENC-001"",
      ""severity"": ""ERROR"",
      ""phase"": ""SOURCE_CERTIFICATION"",
      ""behavior"": ""REFUSE"",
      ""next_action"": ""NONE"",
      ""required_facts"": [""first_invalid_byte_offset"", ""source_filename"", ""stop_reason""],
      ""optional_facts"": [""analytical_outputs_published"", ""materialization_started"", ""source_modified_by_data_sculptor"", ""store_state_committed""]
    },
    {
      ""diagnostic_id"": ""DS-HLP-001"",
      ""severity"": ""ERROR"",
      ""phase"": ""DIAGNOSTIC_ASSEMBLY"",
      ""behavior"": ""REFUSE"",
      ""next_action"": ""NONE"",
      ""required_facts"": [""intended_diagnostic_id"", ""missing_required_facts""],
      ""optional_facts"": []
    }
  ]
} The PRD does not need to enumerate every allocated WASM-002 diagnostic row. The complete registry delivered with the build is retained acceptance evidence. A diagnostic ID becomes permanent once allocated and must not later be reused for a different meaning. Build validation must fail on malformed JSON; extra/missing entry fields; duplicate or noncanonical diagnostic IDs; invalid fixed tokens; unsorted, duplicate, overlapping, or invalid fact-key declarations; engine diagnostic definitions whose fixed semantics disagree with the registry; engine diagnostic definitions absent from the registry; Help-catalog IDs absent from the registry; or Help placeholders that name facts not declared as required or optional by the matching diagnostic. F-07 DS-ENC-001 fact mapping: the canonical lower-case diagnostic facts for strict UTF-8 refusal are first_invalid_byte_offset , source_filename , and stop_reason . For this diagnostic, stop_reason is exactly INVALID_UTF8_SEQUENCE . The generic fact name byte_offset is retired for this UTF-8 refusal diagnostic. P2-03 clock-order diagnostic facts: whichever stable WASM-002 Diagnostic ID is allocated to refusal because a successor Store MAP or WKO MAP cannot satisfy the strict monotonic UTC publication guard must declare these exact lower-case required facts in its diagnostic-registry entry: map_profile , observed_host_utc , predecessor_map_filename , and predecessor_utc . map_profile has exactly two permitted values: STORE for a Store-MAP chronology guard and WKO for a Work-Order-registry-MAP chronology guard. These facts identify both the governed MAP profile, the blocking predecessor artifact, and the truthful clock observation that caused refusal. F-16 DS-CNV-001 allocation: DS-CNV-001 is emitted only when the complete read-only compatibility assessment under W002-CONV-002 through W002-CONV-002.5 reaches EOF with outcome COMPATIBLE . Its required fact windows_1252_compatibility_outcome is therefore exactly the JSON string ""COMPATIBLE"" . behavior: CONTINUE means this informational diagnostic introduces no additional refusal; it does not reverse the already-established DS-ENC-001 refusal or resume Stage 2. F-17 DS-HLP-001 allocation: DS-HLP-001 is the canonical fail-safe event when the engine cannot satisfy the complete required-fact contract of an intended registered diagnostic. intended_diagnostic_id is the exact canonical ID that was being assembled. missing_required_facts is a JSON array of every missing required fact-key string, sorted in ascending UTF-8 byte order with no duplicates. The intended diagnostic is suppressed rather than emitted incompletely. DS-HLP-001 always refuses and has next_action: NONE . F-22 QA-independence boundary: diagnostics.json is authoritative for the fixed semantic contract of an allocated Diagnostic ID — its ID, severity, phase, behavior, next action, and permitted required/optional fact keys — but the implementation-delivered registry is not, by itself, an independent oracle proving that every arbitrary runtime condition was mapped to the correct Diagnostic ID. WASM-002 does not require a second QA-owned registry duplicating every implementation allocation. Where this PRD independently freezes a condition-to-diagnostic mapping or exact required facts — including the named DS-ENC-001 , DS-CNV-001 , and DS-HLP-001 contracts and other explicitly pinned diagnostic facts — that PRD text remains normative and acceptance must test the mapping independently of the implementation registry. For allocations not independently pinned by the PRD, WASM-002 accepts the validated build registry as the build allocation while retaining all registry-shape, permanence, semantic-agreement, fact-discipline, and Help cross-validation gates. This is an explicit accepted QA-scope risk, not a claim of independent condition-to-ID verification. Day 060 H-02 fixture-pinned diagnostic allocations The following allocations are normative for the byte-exact Receipt acceptance corpus. They are genuine product diagnostics, not QA-only placeholder IDs. Every row has severity: ERROR , behavior: REFUSE , next_action: NONE , the phase shown below, the listed required facts, and an empty optional_facts array unless another requirement explicitly adds optional facts later. The existing DS-ENC-001 remains the Stage-1 invalid UTF-8 diagnostic and is reused by the H-02 Stage-1 compatibility-state fixtures. Diagnostic ID Severity Phase Behavior Next action Frozen meaning Required facts DS-WKO-001 ERROR WORK_ORDER_VALIDATION REFUSE NONE Work Order validation refuses before one of the seven governed operations can be identified. work_order_filename DS-MAT-010 ERROR MATERIALIZATION_VALIDATION REFUSE NONE Ordinary MATERIALIZE validation/routing refuses before Stage 1 begins after the source reference is established, excluding the specialized damaged-lineage and malformed-MAP routing conditions allocated by Day 060 H-12. source_filename DS-MAT-011 ERROR CSV_DECODING REFUSE NONE MATERIALIZE Stage 2 refuses on a governed structural CSV condition. source_filename csv_refusal_condition csv_source_byte_offset csv_physical_line csv_logical_record csv_field_ordinal DS-MAT-012 ERROR MATERIALIZATION_GATE REFUSE NONE MATERIALIZE post-Stage-2 gate refuses because existing-Store source cardinality does not match the inherited RID cardinality. source_filename base_map_filename rid_filename source_row_count rid_row_count DS-MAT-013 ERROR STORE_PUBLICATION REFUSE NONE MATERIALIZE governed Store-artifact filename identity allocation refuses after collision-retry exhaustion before any new Store artifact becomes authoritative. artifact_class collision_retry_count DS-INV-001 ERROR INVENTORY_VALIDATION REFUSE NONE INVENTORY validation refuses before the inventory scan begins. work_order_filename DS-INV-002 ERROR INVENTORY_SCAN REFUSE NONE INVENTORY scan/measurement refuses for an identified immediate Suitcase entry before a complete snapshot is established. entry_name DS-INV-003 ERROR INVENTORY_PUBLICATION REFUSE NONE INVENTORY governed INV filename identity allocation refuses after collision-retry exhaustion after the snapshot facts are established. artifact_class collision_retry_count DS-ALS-001 ERROR ALIAS_VALIDATION REFUSE NONE UPDATE ALIASES validation/routing refuses before an exact base Store MAP is established. work_order_filename DS-ALS-002 ERROR ALIAS_GATE REFUSE NONE UPDATE ALIASES refuses after the exact base Store MAP is established but before successor publication. base_map_filename DS-ALS-003 ERROR STORE_PUBLICATION REFUSE NONE UPDATE ALIASES successor-MAP filename identity allocation refuses after collision-retry exhaustion. artifact_class collision_retry_count DS-RPM-001 ERROR REPAIR_MAP_VALIDATION REFUSE NONE REPAIR MAP validation refuses before an exact target MAP/RID pair is established. work_order_filename DS-RPM-002 ERROR REPAIR_MAP_ANALYSIS REFUSE NONE REPAIR MAP analysis refuses before a complete repair result is established. target_map_filename DS-RPM-003 ERROR REPAIR_MAP_ANALYSIS REFUSE NONE REPAIR MAP deterministically refuses because every mapped COL is broken and retained COL count is zero. target_map_filename broken_col_count DS-RPM-004 ERROR STORE_PUBLICATION REFUSE NONE REPAIR MAP successor-MAP filename identity allocation refuses after collision-retry exhaustion after repair analysis is established. artifact_class collision_retry_count DS-WKR-001 ERROR WORK_ORDER_REGISTRY_VALIDATION REFUSE NONE REPAIR WORK ORDER REGISTRY validation refuses before the current structurally valid WKO MAP is established. work_order_filename DS-WKR-002 ERROR WORK_ORDER_REGISTRY_REPAIR REFUSE NONE REPAIR WORK ORDER REGISTRY repair-plan/gate processing refuses after the base WKO MAP is established. base_wko_map_filename DS-WKR-003 ERROR WORK_ORDER_REGISTRY_PUBLICATION REFUSE NONE REPAIR WORK ORDER REGISTRY successor-WKO-MAP filename identity allocation refuses after collision-retry exhaustion. artifact_class collision_retry_count DS-CVT-001 ERROR CONVERSION_VALIDATION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 validation/classification refuses before bounded transcoding begins. source_filename DS-CVT-002 ERROR CONVERSION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 refuses after bounded transcoding begins but before publication. source_filename DS-CVT-003 ERROR CONVERSION_PUBLICATION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 CVT filename identity allocation refuses after collision-retry exhaustion after conversion facts are established. artifact_class collision_retry_count DS-CAT-001 ERROR CATALOG_DISCOVERY REFUSE NONE CATALOG STORES validation/discovery refuses before the complete authoritative catalog row set is established. work_order_filename DS-CAT-002 ERROR CATALOG_PUBLICATION REFUSE NONE CATALOG STORES CAT filename identity allocation refuses after collision-retry exhaustion after the complete row set is established. artifact_class collision_retry_count Day 060 H-04 normalization: all allocated Diagnostic IDs in the current WASM-002 contract, including DS-CNV-001 , use exactly three ASCII uppercase letters in DOMAIN . No exception exists. Day 060 H-12 / BM-09 specialized diagnostic allocations The H-02 fixture diagnostics above are intentionally narrow. In particular, publication diagnostics whose required facts are only artifact_class and collision_retry_count mean identity-allocation collision exhaustion , not every possible publication failure. Other publication failures receive distinct registry allocations unless another requirement independently pins their Diagnostic ID. The following additional pre-freeze allocations are normative because existing Help duties require fact contracts that the broad H-02 fixture IDs cannot truthfully carry. Every row has severity: ERROR , behavior: REFUSE , and next_action: NONE except DS-MAT-017 , whose next_action is RUN_REPAIR_MAP . optional_facts is empty unless another requirement explicitly extends it. Diagnostic ID Severity Phase Behavior Next action Frozen meaning Required facts DS-MAT-014 ERROR MATERIALIZATION_ROUTING REFUSE NONE MATERIALIZE is blocked because exact source routing identifies a current INVALID Store lineage whose governed RID is missing or invalid. source_filename current_map_filename rid_filename store_health DS-MAT-015 ERROR MATERIALIZATION_ROUTING REFUSE NONE MATERIALIZE is blocked because exact source routing identifies a DEGRADED Store whose every mapped non-RID COL is missing or invalid, so REPAIR MAP cannot publish a non-empty successor. source_filename current_map_filename rid_filename store_health mapped_col_count broken_col_count DS-MAT-016 ERROR MATERIALIZATION_ROUTING REFUSE NONE New-Store creation is blocked because no routable Store lineage can be established while one or more structurally malformed Store-MAP-class artifacts are visible in the active Suitcase. source_filename malformed_map_filenames DS-MAT-017 ERROR MATERIALIZATION_ROUTING REFUSE RUN_REPAIR_MAP MATERIALIZE is blocked because exact source routing identifies a current DEGRADED Store whose governed RID is valid and whose mapped non-RID COL set contains at least one broken COL and at least one surviving valid COL, so a separate governed REPAIR MAP operation is available. source_filename current_map_filename rid_filename store_health broken_col_count DS-UTC-001 ERROR PUBLICATION_CHRONOLOGY REFUSE NONE A successor Store MAP or WKO MAP publication is blocked because truthful observed host UTC is not strictly greater than the canonical chronology predecessor UTC. map_profile observed_host_utc predecessor_map_filename predecessor_utc Day 060 H-26 / BM-09 allocation: DS-MAT-017 is the ordinary repairable-DEGRADED routing refusal. store_health is exactly DEGRADED ; broken_col_count is the exact number of mapped non-RID COL bindings that fail the applicable Store-health validation at this routing gate and is at least 1 . The condition excludes the all-COLs-broken case allocated to DS-MAT-015 . current_map_filename is the exact current structurally valid Store MAP that a separate REPAIR MAP Work Order must name. RUN_REPAIR_MAP is a safe next-action token only; it never causes automatic repair. Closed-world Help consequence: Help may render the richer damaged-lineage, malformed-MAP, and monotonic-UTC explanations only from the applicable specialized diagnostic event above. It must not borrow undeclared facts from DS-MAT-010 or from a collision-exhaustion publication diagnostic merely because those facts are available elsewhere at runtime. Cross-operation UTC rule: DS-UTC-001 has one stable semantic condition across Store-MAP and WKO-MAP successor publication. The required map_profile fact tells closed-world Help which governed MAP profile encountered the chronology guard: STORE means Store MAP and WKO means Work Order registry MAP. Help must select profile-appropriate explanation and analyst exits only from that declared fact and the other registered event facts; it must not infer the profile from filename shape, surrounding host state, or an undeclared operation field. The shared Diagnostic ID therefore does not need profile-specific clones.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002,Three-voice parity,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help Engine must support the three established Data Sculptor help voices. All three renderings must preserve the same diagnostic truth. Voice selection may change wording, sentence structure, degree of technical detail, and explanatory style. F-24 session default and persistence: Technical is the canonical Help voice at the start of every new browser application instance. The analyst may select Casual or Office Speak during that instance, but WASM-002 retains the selected voice only in volatile runtime state and does not persist the preference in browser-private storage. A new application instance therefore returns to Technical. This default does not alter the F-17 rule that a missing diagnostic-specific catalog entry visibly falls back to Generic Technical Help.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.1,Voice selection must not change diagnostic identity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.2,Voice selection must not change severity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.3,Voice selection must not change counts or evidence.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.4,Voice selection must not change whether execution continues or refuses.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.5,Voice selection must not change safe/unsafe action boundaries.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.6,Voice selection must not change provenance.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.7,Voice selection must not change the meaning of the recommended next step.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Tests must assert parity on the canonical event and structured facts, not brittle equality of prose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.8,One validated Help message catalog is the source of truth for all three voices,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help layer resolves a canonical diagnostic ID through one validated catalog that associates an authored ID with Casual, Office Speak, and Technical templates. The human-maintained development source is exactly help_messages.json , encoded as UTF-8 without BOM. help_messages.json is a Data Sculptor product/build resource, not a Suitcase artifact. It must not use the __DS__ governed artifact namespace, consume a semantic artifact-class token, or be copied into an analyst's Suitcase merely because Data Sculptor runs. Run-specific structured facts remain authoritative in the canonical diagnostic event and are supplied separately to the selected template. The three authored voices must not be maintained as unrelated message stores. F-17 coverage fallback: absence of an authored catalog entry for an otherwise complete registered diagnostic is permitted at run time and does not make the diagnostic incomplete. Data Sculptor must instead render the deterministic Generic Technical Help view defined by W002-HELP-002.9. The fallback consumes only the canonical event semantic core and its emitted governed facts; it is not a second message catalog and does not manufacture replacement diagnostic facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.9,WASM-002 may use mechanically generated placeholder voice text to prove Help wiring,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance does not require the complete production Help corpus. Authored catalog entries may use unmistakable placeholder strings, and placeholder entries may be generated mechanically from the validated diagnostics.json registry; no production prose authorship is required. Deterministic Generic Technical Help fallback. When a complete registered canonical diagnostic has no matching entry in help_messages.json , all selected Help voices fall back visibly to one Generic Technical rendering. The rendering must show, in this exact conceptual order, the diagnostic ID, severity, phase, behavior, next-action token, and then every emitted governed fact ordered by ascending UTF-8 byte order of fact key. It must state that no diagnostic-specific authored explanation is available. It must not infer cause beyond the diagnostic, invent remediation, default missing facts, inspect undeclared external state, or substitute prose for governed fact values. The Generic Technical fallback preserves the original diagnostic unchanged. Catalog incompleteness is therefore distinct from diagnostic incompleteness: a valid event can always be rendered generically, while inability to satisfy the event's own required_facts contract suppresses that intended event and produces DS-HLP-001 under W002-HELP-001.4 and W002-HELP-001.8. Acceptance must prove correct diagnostic-ID lookup, selected-voice resolution, structured-fact interpolation where a template exists, voice switching, deterministic Generic Technical fallback for a deliberately absent catalog entry, and semantic parity across authored voices. Final authored Help wording, examples, editorial polishing, and production-corpus quality remain deferred to a later Help-content milestone.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.10,help_messages.json has one deterministic WASM-002 source schema,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The top-level JSON object has exactly two fields: catalog_version and messages . catalog_version is the string ""1"" . messages is an array written in ascending UTF-8 byte order of diagnostic_id . Each message entry has exactly four fields: diagnostic_id , casual , office_speak , and technical . diagnostic_id must satisfy the canonical DS-<DOMAIN>-<NNN> grammar and must be unique in the catalog. Each voice field is a JSON string. A voice string may contain zero or more structured-fact placeholders using the exact form {fact_name} . Each catalog diagnostic_id must exist in the validated diagnostics.json registry, and each referenced placeholder must be declared in that diagnostic's required_facts or optional_facts . Duplicate IDs, missing voice fields, null voice values, malformed JSON, noncanonical or unregistered diagnostic IDs, or undeclared fact placeholders make catalog validation fail. The catalog is intentionally allowed to be non-exhaustive. A registered diagnostic with no message entry is rendered through the deterministic Generic Technical fallback in W002-HELP-002.9. Therefore a missing catalog entry for a registered diagnostic is not a build-validation failure and must not cause the engine to synthesize an authored entry or suppress the diagnostic. WASM-002 therefore does not require one global exhaustive fact-name table in the PRD. Fact-key authority is per diagnostic: the validated registry declares which fact names are legal for each stable diagnostic meaning. {
  ""catalog_version"": ""1"",
  ""messages"": [
    {
      ""diagnostic_id"": ""DS-ENC-001"",
      ""casual"": ""[CASUAL PLACEHOLDER] {source_filename}"",
      ""office_speak"": ""[OFFICE PLACEHOLDER] {source_filename}"",
      ""technical"": ""[TECHNICAL PLACEHOLDER] {source_filename} {first_invalid_byte_offset} {stop_reason}""
    }
  ]
} Later Help-content revisions may extend or version this schema only through an explicit PRD revision. F-07 placeholder mapping: Help for the strict UTF-8 refusal may render {first_invalid_byte_offset} and {stop_reason} because those exact fact names are declared by the canonical DS-ENC-001 diagnostic registry entry. The older generic {byte_offset} placeholder is not valid for DS-ENC-001. P2-03 Help rendering duty: Help for the monotonic-UTC refusal must identify the exact blocking predecessor MAP and show both predecessor UTC and truthful observed host UTC. It must distinguish an incorrect host clock from a genuinely future-dated governed MAP and may explain the approved analyst-owned choices: correct the clock, wait/rerun after truthful time advances, or deliberately move the exact future-dated current MAP out of the active Suitcase root with the warning that an older snapshot/registry may become current and that restoring the moved MAP may restore its authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.11,The validated Help catalog is embedded into the released HTML build and supplied to the shared core,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Before a WASM-002 browser build is accepted, the build must parse and validate help_messages.json , then serialize the validated catalog directly into the Data Sculptor HTML itself as one non-executable application/json payload with the exact element ID ds-help-catalog . The embedded JSON must be HTML-safe so catalog text cannot terminate the containing script element; at minimum, literal less-than characters in JSON string content must be escaped during embedding. At runtime, the browser host obtains this embedded payload and supplies the validated catalog to the shared Rust/WASM Help core. Browser JavaScript must not implement a competing template-selection, fact-interpolation, fallback, escaping, or HLP-semantic engine. The browser host must not fetch a Help catalog from the network, the filesystem, the Suitcase, or an adjacent deployment file. Missing or malformed embedded catalog JSON, or a build whose embedded catalog does not correspond to the validated build input, is a build-validation failure. The released HTML therefore remains one offline portable front door for the browser Help catalog. A later native host may supply the same governed catalog semantics to the same shared core from its own build-bundled resource; host packaging may differ, but Help semantics must not fork.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003,Message and report outputs,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The Help Engine must support both live and durable help surfaces.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003.1,The Help Engine must support a concise human-facing message suitable for the live browser surface.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The concise message is rendered in the dedicated browser Help / Diagnostic Surface when that surface is present; it is not required to be a modal or transient notification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003.2,"The Help Engine must support a durable HTML Help report using the canonical built-in Data Sculptor presentation suitable for saving with the Work Order, receipt, and output artifacts.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"A concise Help message for an individual diagnostic and any durable Help Report that includes that diagnostic must resolve from the same canonical diagnostic event. A durable Help Report request may cover one active governed diagnostic, including a non-run diagnostic, or one governed run containing one or more canonical diagnostic events. Exactly one HLP is published for each explicit Help Report request.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004,HTML Help report content,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,A saved Help report must be able to include the following elements when relevant.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.1,Product and brand identity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.2,Plain-language summary.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.3,Stable diagnostic ID.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.4,What Data Sculptor observed.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.5,Evidence and structured facts.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.6,What the user can safely do next.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.7,Source/Work-Order context is governed by the HLP disclosure allowlist.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The report may include only source and Work Order context permitted by W002-HELP-010. Durable HLP disclosure is intentionally stricter than transient local Help because the HLP is a portable support-handoff artifact. A relevant governed alias or source header may enter the HLP only under the necessity and disclosure rules in W002-HELP-010. Source-header text is eligible only when Data Sculptor has structurally established an actual CSV header record under the governed parser. Record position alone does not make text a header. When no valid header record has been established, including the headerless-source refusal case, the HLP must use structural evidence such as the 1-based column ordinal, diagnostic condition/location, or an applicable operational fallback name and must not substitute field data from the first data row. Absolute local paths, entire Work Orders, Work Order comments, source rows/values, unrelated headers/aliases/columns, and unrelated Suitcase contents are not automatically eligible merely because they are available to the running application.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.8,Report-generation metadata preserves HLP identity and lineage.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The report must carry its own governed HLP filename and generation UTC together with the diagnostic identity and applicable originating execution lineage. The exact HLP provenance contract is governed by W002-HELP-009.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.9,Selected Help voice and its human-facing explanation.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.10,A clearly labelled structured-facts block derived from the canonical diagnostic event.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.11,Four canonical Boolean facts describe the WASM-002 execution boundary.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When the governed diagnostic context can determine the execution boundary, the canonical fact names are exactly: source_modified_by_data_sculptor materialization_started analytical_outputs_published store_state_committed When one of these facts has an established Boolean value, the JSON/structured value is the native Boolean true or false , never the strings ""TRUE"" or ""FALSE"" . source_modified_by_data_sculptor states only whether Data Sculptor modified the analyst-owned source in place; it must not imply knowledge that no external process or analyst changed the source between sessions. materialization_started records whether the governed analytical materialization phase began. analytical_outputs_published records whether governed analytical outputs were successfully published for user use; transient SCR candidates or abandoned/uncommitted debris do not make this fact true. store_state_committed records whether the successor Store MAP commit point was crossed. If a present boundary fact must express governed absence rather than an established Boolean, its JSON/structured value is the exact applicable shared absence-state string ""NONE"" , ""NOT_RUN"" , ""NOT_AVAILABLE"" , or ""NOT_APPLICABLE"" . JSON null is not a valid encoding for these four boundary facts because it would discard the reason for absence. A boundary fact that is optional for a particular diagnostic may instead be omitted under W002-HELP-001.4; that omission carries no absence-state meaning. A missing, omitted, unavailable, or not-run fact must never be interpreted as false . If one of these facts is declared required for an intended diagnostic and the required value cannot be produced, it must not be silently defaulted; the intended diagnostic is suppressed and the fail-safe DS-HLP-001 contract in W002-HELP-001.4/W002-HELP-001.8 applies.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.12,Governed Work Order lineage sufficient to establish user intent.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,Included lineage must obey the disclosure boundary defined for Help reports and must not automatically expand into source-data disclosure.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-005,Deterministic rendering uses a closed governed input set,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Given the same canonical diagnostic event or ordered set of events, selected voice, PRETTY rules, validated Help catalog, and built-in presentation version, Help rendering must be deterministic except for explicitly permitted event/report-specific fields. The Help renderer may consume only the canonical diagnostic fields and fact keys declared by the applicable diagnostic registry entries plus fields explicitly defined by the applicable HLP provenance schema. It must not inspect or interpolate an open-ended host-state bag, undeclared browser state, unrelated Suitcase contents, or another value merely because it is available at runtime. A future configurable Brand Manifest may add another governed presentation input, but it is not part of the WASM-002 rendering contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-006,Host parity uses one shared Help semantic core,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help Engine must be designed for use by the browser host and the later native CLI host without changing diagnostic semantics. The shared Rust core owns diagnostic-to-template selection, governed fact interpolation, deterministic fallback behavior, governed escaping, and durable HLP semantic serialization. The WASM-002 browser host supplies the validated catalog embedded under W002-HELP-002.11. A later native host may supply the same governed catalog semantics from a build-bundled native resource. Host-specific presentation and packaging may differ, but they must not create a second Help semantic engine or change canonical diagnostic identity, facts, behavior, next action, voice semantics, disclosure policy, or HLP meaning.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-007,"Help surfaces are projections, not diagnostic authority",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The live Help / Diagnostic Surface and the saved HTML Help Report must render from the canonical diagnostic event. Neither surface may independently create, reinterpret, weaken, suppress, or override governed diagnostic truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008,HTML Help Report is a governed support-handoff artifact,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The user must be able to generate a styled, self-contained HTML Help Report from a governed diagnostic event for retention, IT/support handoff, or communication to another analyst. The report must support two audiences in one document: a human-readable explanation using the selected Help voice and a clearly inspectable structured-facts section that preserves the technical evidence required to understand the event.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008.1,"The report preserves the canonical execution-boundary facts, including relevant negative facts.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When relevant to the diagnostic, the report must render the governed values of source_modified_by_data_sculptor , materialization_started , analytical_outputs_published , and store_state_committed . These values originate from governed execution state rather than reassuring prose invented by the renderer. A missing/unavailable fact is not rendered as false .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008.2,The report preserves only the Work Order lineage needed to explain the diagnostic.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The report must identify the originating WKO physical filename when one applies and may include only the minimum executable Work Order clause or clauses needed to establish the governed operation, user intent, and trigger for the diagnostic. It must not automatically embed the entire Work Order or Work Order comments. All such context remains subject to the fixed disclosure boundary in W002-HELP-010.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-009,"WASM-002 establishes HLP identity, lineage, multiplicity, and one canonical embedded provenance payload.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"A durable generated Help Report is an immutable governed HLP artifact whose physical filename is: __DS__HLP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html The UTC token is the HLP's own governed generation/publication time. The report is the final self-contained HTML artifact using the canonical built-in Red5Sorcery/Data Sculptor presentation; no unstyled intermediate is the canonical HLP. Report-request multiplicity: one explicit Help Report request publishes exactly one HLP. The request may be bound to one active governed diagnostic, including a diagnostic that is not associated with a Run, or to one governed Run containing one or more canonical diagnostic events. A Run-level report includes the governed diagnostic events selected by that request in deterministic event order. HLP generation is never an automatic one-artifact-per-diagnostic side effect. Every HLP must expose a visible deterministic Provenance section and exactly one embedded non-executable application/json payload whose element ID is exactly ds-hlp-provenance . F-34 supersedes the earlier draft schema version ""1"" . For schema version ""2"" , the JSON top-level object contains exactly these ten fields: {
  ""schema_version"": ""2"",
  ""hlp_filename"": ""__DS__HLP__20260922T191500123Z__<uuid-v4>.html"",
  ""hlp_generation_utc"": ""20260922T191500123Z"",
  ""diagnostic_ids"": [""DS-ENC-001"", ""DS-MAT-004""],
  ""originating_wko_filename"": ""__DS__WKO__...txt"",
  ""originating_rcp_filename"": null,
  ""selected_help_voice"": ""technical"",
  ""presentation_id"": ""red5sorcery-data-sculptor"",
  ""presentation_version"": ""1"",
  ""data_sculptor_build"": ""<exact-build-id>""
} hlp_generation_utc must use the canonical fixed-width millisecond UTC form YYYYMMDDTHHMMSSmmmZ . diagnostic_ids is a non-empty JSON array containing one canonical diagnostic ID for each diagnostic event included in the report, in the same deterministic event order used by the report. Repeated IDs are permitted when distinct included events legitimately share one diagnostic type. selected_help_voice is exactly one of casual , office_speak , or technical , matching the Help catalog keys. For WASM-002 the built-in presentation identity is exactly red5sorcery-data-sculptor and its presentation version is exactly ""1"" . data_sculptor_build must contain the exact running build identifier used for the tested/released build; the literal scope label WASM-002 alone is not sufficient unless it is also the exact build identifier. originating_wko_filename and originating_rcp_filename are schema-declared nullable lineage fields . When the relationship exists and the exact physical filename is known, the value is that filename as a JSON string. When the relationship itself does not apply to this Help event/report request, the machine-readable value is JSON null . That null has one schema-defined meaning: the nullable relationship has no value, equivalent to Rust Option<T>::None and to the governed semantic state NOT_APPLICABLE . The visible Provenance section renders it as NOT APPLICABLE . If the lineage relationship does apply but the exact filename cannot be obtained, JSON null must not be used; the field value is the exact string ""NOT_AVAILABLE"" and the visible Provenance section renders NOT AVAILABLE . Empty strings, invented lineage, N/A , UNKNOWN , or another substitute are forbidden. For these two lineage fields, null and ""NOT_AVAILABLE"" are deliberately non-interchangeable. A non-run HLP may therefore legitimately carry JSON null for both lineage fields when neither relationship applies. This nullable-field rule is a schema-specific serialization choice, not a fifth absence state and not a generic JSON encoding rule. Other diagnostic JSON facts follow W002-HELP-001.4 and W002-HELP-004.11. The visible and machine-readable HLP provenance must express the same governed semantics even where their physical representations differ; a semantic mismatch is an HLP-generation failure and must not be silently tolerated. The embedded JSON must be HTML-safe so provenance text cannot terminate the containing script element; at minimum literal less-than characters in JSON string content must be escaped during embedding. The provenance payload remains subject to W002-HELP-010 and must not introduce source rows, source values, absolute local paths, arbitrary Work Order content, or other context excluded by the fixed HLP disclosure policy. WASM-002 does not automatically compute or embed a SHA-256 of the HLP, and saving an HLP must not create, refresh, or verify an LCK . The final HLP bytes remain eligible for exact-byte integrity evidence under the later explicit FINGERPRINT/LCK workflow. Configurable Brand Manifest provenance remains deferred to V1-BACKLOG / a future build. F-14 HLP publication: the complete self-contained report is first written as the corresponding SCR candidate under W002-STOR-023.1. It must close, reopen, and validate the required visible Provenance section, exact schema-version-2 embedded JSON shape, HTML-safe serialization, self-contained presentation and visible/machine semantic parity before the class token may be renamed from SCR to HLP . A partial or semantically mismatched candidate never becomes a canonical HLP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-010,Help Report disclosure uses one fixed WASM-002 allowlist.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Generating a Help Report must not silently become a data-export path. WASM-002 therefore uses one deterministic allowlist rather than collecting broad context and attempting to redact it afterward. There are no disclosure checkboxes, permissive export modes, or per-report overrides in WASM-002. Always eligible when present and applicable: diagnostic ID; severity/classification; governed operation/phase; continue/refuse decision; safe next action; selected Help voice; HLP identity and generation UTC; relevant governed artifact filenames; and the four canonical boundary facts from W002-HELP-004.11. Eligible only when necessary to explain the diagnostic: the exact source filename but not an absolute OS path; a relevant source column header only when Data Sculptor has structurally established an actual CSV header record; the relevant 1-based column number; a relevant governed Store/RID/COL alias only when that alias itself is necessary to explain the diagnostic, such as an alias collision, ambiguity, or governed alias mutation; byte offset, row/count, or byte-length evidence; Store/RID/COL/MAP/WKO physical filenames; and only the minimum executable Work Order clause or clauses needed to establish intent and the diagnostic trigger. If that minimum Work Order excerpt necessarily contains a governed alias, that alias is disclosed and counts as alias text included. Headerless boundary: record position alone never establishes a source header. If the governed parser has not established a valid header record, including a headerless-source refusal, HLP generation must not treat any field from the first data row or any later data record as header text. Structural evidence such as 1-based column ordinal, governed diagnostic/location facts, or an applicable operational fallback name must be used instead. Never included automatically: source rows; source field values or arbitrary data samples; field data mislabeled as header text; absolute local paths; unrelated source headers, aliases, or column names; the complete Work Order; Work Order comments; unrelated Suitcase contents; browser/environment internals not governed as diagnostic evidence; or raw ungoverned stack traces. Every generated HLP must contain a visible Disclosure section stating, at minimum: Source rows included: NO ; Source values included: NO ; Source header text included: YES or NO ; Governed alias text included: YES or NO ; Absolute local paths included: NO ; Work Order comments included: NO ; and Work Order excerpt: RELEVANT EXECUTABLE CLAUSES ONLY . The two YES/NO declarations must truthfully reflect the actual HLP bytes. A genuine established source header does not count as a source field value; this distinction applies only after the governed parser has established the header record. The renderer must not weaken any declaration when the underlying policy has not changed. This durable-HLP allowlist does not prohibit transient local Help from showing a relevant governed alias or a genuinely established source header when useful to explain the same canonical diagnostic event. Local presentation does not enlarge what the portable HLP may disclose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011,Help owns the cross-session source-continuity edge-case explanation,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When an unexpected analytical result, row-alignment concern, or support question raises the possibility that an analyst-owned source changed between sessions, Data Sculptor-controlled guidance must flow through the Help Engine. Help must not imply that the engine monitored or cryptographically protected the source when it did not. The explanation must distinguish ordinary analyst-controlled workflow from stronger optional evidence. It may ask whether the analyst edited, replaced, sorted, re-exported, synchronized, copied over, or otherwise changed the source after the Store was established.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011.1,Help presents continuity evidence in explicit assurance levels,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"For a suspected cross-session source change, Help must distinguish at least these evidence levels: No continuity evidence: state that cross-session byte continuity cannot be independently verified from filename/Store metadata alone. INVENTORY available: use filename, exact byte length, and last-modified metadata as lightweight clues; changed metadata may indicate that the source changed, while unchanged metadata must not be presented as proof of unchanged bytes. Explicit fingerprint evidence available: exact-byte SHA-256 evidence may establish whether the compared file bytes match or differ under the later governed FINGERPRINT workflow. Help must not collapse these levels into one generic statement of certainty.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011.2,WASM-002 does not impose automatic cross-session hashing or Suitcase surveillance,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Ordinary WASM-002 materialization and Store inheritance must not automatically SHA-256 the source, recursively fingerprint the Suitcase, or maintain hidden whole-Suitcase surveillance merely to guard against the possibility that an analyst-owned file changed between sessions. This is an intentional product boundary for the lone-office-analyst model. The product assumes the analyst normally controls the Suitcase, provides lightweight explicit INVENTORY evidence in WASM-002, preserves a later explicit FINGERPRINT path for stronger assurance, and relies on Help to explain unusual cross-session continuity questions proportionately. WASM-002 must not create, refresh, or silently verify an LCK Suitcase Lock as a side effect of Work Order save, materialization, Store inheritance, INVENTORY, alias maintenance, or ordinary project use. LCK publication belongs to the explicit later-V1 FINGERPRINT workflow. F-13 single-writer Help boundary: Help must distinguish cross-session continuity from concurrent writing. WASM-002 does not claim that two Data Sculptor tabs/windows can safely write the same Suitcase at once. User guidance must say to use one writing Data Sculptor context per Suitcase; read-only viewing is not itself a governed write. When a pre-commit guard detects that relevant governed state changed underneath an operation, Help must identify the changed authority where available and direct the analyst to refresh or reopen current state and rerun deliberately. It must not imply that Data Sculptor acquired a cross-tab lock, merged the competing work, or automatically rebased the refused transaction.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-001,Separation of truth and presentation,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,The PRETTY Engine must not decide analytical truth or reinterpret diagnostic meaning. It receives governed content and renders it into human-facing artifacts. WASM-002 conceptual boundary: ENGINE TRUTH -> HELP / REPORT CONTENT -> PRETTY ENGINE -> BUILT-IN DATA SCULPTOR PRESENTATION -> ARTIFACT. A future build may replace the built-in presentation source with a governed Brand Manifest without changing the analytical or diagnostic truth supplied to PRETTY.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-002,Shared renderer path,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"The PRETTY Engine must provide a common rendering path for Data Sculptor artifacts that require governed human presentation, including at minimum the WASM-002 Help HTML report. WASM-002 uses the canonical built-in Red5Sorcery/Data Sculptor presentation. The architecture must permit the same path to accept a configurable Brand Manifest in a future build without changing analytical semantics. The architecture must also permit later reuse for branded Receipt HTML, verification reports, tables, Quick Viz, and other PRETTY outputs. WASM-002 canonical run Receipts themselves remain TXT-only under W002-RCP-003.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003,Self-contained HTML,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"Durable HTML artifacts produced by PRETTY must be self-contained for ordinary viewing after generation. Self-containment requires semantic and functional portability, not pixel-identical rendering across operating systems or browsers; ordinary system-font substitution and browser rendering differences are acceptable when meaning, evidence, hierarchy, and accessibility remain intact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.1,A saved artifact must not require a network connection.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.2,A saved artifact must not require an external stylesheet.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.3,A saved artifact must not require a remote font.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.4,A saved artifact must not require a separately located logo file.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.5,A saved artifact must not require external presentation resources.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"Required CSS, SVG, and other built-in presentation assets needed for ordinary viewing must be embedded or otherwise resolved into the generated artifact at creation time. Future configurable Brand Manifest inputs, when implemented, must preserve this self-contained output rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-004,Accessibility and inspectability,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"PRETTY HTML must remain ordinary inspectable HTML. Presentation must not obscure the text, evidence, diagnostic code, provenance, or next-step guidance. The rendered artifact must remain usable without JavaScript when JavaScript is not required for its content.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-QA-001,Governed test-only seams and acceptance coverage,W002-QA,W002-QA,WASM-002,UNDER REVIEW,—,"Every material frozen WASM-002 behavior must have retained acceptance evidence sufficient to exercise the governed success, refusal, mutation, publication, or recovery boundary that makes the behavior meaningful. Related cases may share one fixture when the shared fixture proves each required condition explicitly; acceptance coverage must not rely on a behavior being difficult to reproduce under an uncontrolled host environment. Permitted deterministic test-only seams. WASM-002 acceptance may use controlled clock values; controlled UUID sequences and collision outcomes; controlled filesystem create/write/close/rename/promotion failures; and controlled run-local source-handle reread/substitution conditions. A seam supplies only the external condition required to reach the governed behavior. It must not bypass validation, alter the normative semantic result, change governed serialization, relax publication rules, rewrite diagnostic truth, or create a second analytical execution model. Release boundary. Test-only controls must not be invocable through the ordinary Data Sculptor UI, DS-STEPS, saved Work Orders, URL/query parameters, Suitcase configuration, or another analyst-facing product path. Compile-time exclusion, test-build configuration, or an isolated acceptance harness are permitted implementation techniques. Retained acceptance evidence must identify any seam used and must separately demonstrate that the accepted release surface cannot invoke that seam as a user feature. Named storage acceptance gaps. Acceptance must include a case-variant governed namespace/class fixture proving that Data Sculptor does not silently normalize the variant spelling into canonical governed identity; an unknown syntactically valid governed-class fixture proving that the file remains byte-for-byte unchanged while a canonical INFO diagnostic and INVENTORY surface the unknown/unrecognized class; and at least one known-but-not-emitted-class fixture drawn from DGN , RCV , BRD , or LCK proving the same preserve-and-report behavior without activating a producer, lifecycle, or interpretation path. Carried feature gates remain feature-owned. Mechanisms whose normative lifecycle is integrated in another package — including the F-02 Work Order-registry/alias-replacement behavior, the F-04 existing-Store cardinality refusal, and the F-24 CER-history decision — cannot be considered accepted without their corresponding feature acceptance gates. This requirement does not invent those feature semantics. If a proposed mechanism is removed from WASM-002 rather than integrated, no acceptance gate for that removed mechanism is required.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-001,UTF-8 certification pass,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,A valid multi-gigabyte UTF-8 fixture must complete whole-source certification with exact byte accounting under bounded memory.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-002,UTF-8 certification fail,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"A fixture containing an invalid UTF-8 sequence, including a sequence that crosses an input-window boundary, must deterministically produce STAGE1_UTF8_OUTCOME: FAIL , UTF8_STOP_REASON: INVALID_UTF8_SEQUENCE , and the exact governed zero-based UTF8_FIRST_INVALID_BYTE_OFFSET . Stage 2 must not begin and no analytical materialization output may be published. The same bytes tested under different permitted Stage-1 input-window sizes and boundary placements must yield the same outcome, stop-reason token, and first-invalid offset.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-003,Run-local source substitution refusal,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"An acceptance fixture must attempt to present Stage 2 with a different source instance/reference than the one retained from Stage 1. The run must refuse before materialization rather than accept the substitute merely because filename, alias, path, or byte length appears compatible. F-23 governed seam: this fixture must use the test-only source-handle substitution/reread seam permitted by W002-QA-001 so the different Stage-2 instance is injected without changing the analyst-visible SOURCE syntax or adding a product-level source-selection path. Release-surface evidence must demonstrate that an analyst cannot invoke this substitution seam through the normal UI, Work Order, URL/query, or Suitcase configuration.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-004,ASCII-only fast path,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,An all-ASCII fixture must certify successfully without invoking non-ASCII sequence validation and must produce exact byte accounting.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-005,Valid non-ASCII sequence matrix,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"Acceptance must cover valid two-byte, three-byte, and four-byte UTF-8 sequences, including sequences placed at window boundaries and split at every legal boundary position.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-006,Strict invalid-sequence matrix,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"Acceptance must reject at known exact offsets: lone continuation bytes, malformed continuation sequences, truncated sequences, overlong encodings, UTF-16 surrogate encodings, invalid lead bytes 0xC0 / 0xC1 , values introduced by 0xF5 - 0xFF , and code points above U+10FFFF. Every invalid fixture must serialize the same canonical UTF-8 stop reason INVALID_UTF8_SEQUENCE while preserving its fixture-specific exact first-invalid byte offset. For an EOF-truncated multibyte sequence, the expected offset is the lead byte of the incomplete sequence. Acceptance must include at least one malformed sequence crossing a Stage-1 input-window boundary and prove window invariance. Separate valid fixtures covering ASCII-only, valid multibyte UTF-8, and permitted leading-BOM forms must complete with STAGE1_UTF8_OUTCOME: PASS ; their UTF-8 refusal-only Receipt fields are NOT_APPLICABLE .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-007,Late invalidity,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,A source that is ASCII/valid UTF-8 until near EOF and becomes invalid late in the file must fail at the first invalid absolute offset; bounded-prefix success must not be treated as whole-file certification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-008,Window-size invariance,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,The same fixture matrix must return the same PASS/FAIL and first invalid absolute offset across at least two materially different bounded window sizes.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-009,EOF pending-state refusal,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,EOF with an incomplete UTF-8 sequence must fail deterministically and report the governed offset; no replacement character may be inserted.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-010,BOM behavior,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"A UTF-8 BOM at offset zero must be accepted as metadata while the remainder of the source is still fully certified; a BOM must not mask later invalid UTF-8. F-07 BOM coordinate fixture: when a permitted three-byte UTF-8 BOM precedes a later malformed UTF-8 sequence, the expected first-invalid offset counts the BOM's physical bytes. The BOM is excluded from analytical CSV content but included in the absolute physical source-byte coordinate system.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-001,Multi-column one-pass Stage 2 materialization,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Using a valid UTF-8 source and a Work Order requesting at least four source columns through a mixture of HEADER and COLUMN selectors, acceptance must prove that Stage 1 completes first, Stage 2 restarts at byte zero of the same run-local source instance, parses the header once, resolves all selectors before the first data row, and reads the source data records only once while producing all requested columns. Evidence must reconcile total source bytes read by Stage 2, logical data-row count N, per- COL data-record count N, selector-to-source ordinal/header resolution, resolved KEEP order, and the resulting successor MAP. A one-column rerun of the same source/column must produce the same canonical physical column bytes as that column produced inside the multi-column run, apart from governed artifact identity. F-20 width/one-pass acceptance: acceptance must include a maximum-width fixture whose valid source has exactly 16,384 columns and whose KEEP resolves all 16,384 distinct columns. Instrumentation must prove one source data-record traversal regardless of the implementation's bounded post-scan spool/finalization strategy. A companion 16,385 -column source must refuse during header resolution before the first data record is consumed.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002,"Automatic Store MAP creation, inheritance, and rematerialization continuity",W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must materialize four previously unseen source columns in one Store-establishing Work Order and prove that one successor Store MAP is created with four mapping rows. Every row must repeat identical Store-level fields, bind the newly created RID filename, default store_alias to the exact Store-establishing source filename, default rid_alias to RID , and default each COL alias to its exact source header. A later Work Order using the same exact SOURCE without explicitly naming a MAP must route under W002-STOR-019.2 . If exactly one routable Store lineage exists for that exact source filename and its current Store state permits materialization, the Work Order must inherit that lineage’s current structurally valid Store MAP, preserve the Store/RID metadata and four prior mappings, add a fifth default COL alias, and publish one new complete Store MAP. A later rematerialization of one earlier logical column must preserve its inherited COL alias while updating its column_filename . An explicit older MAP selection must instead use that historical Store state. Equal-latest-timestamp ambiguity within one routed lineage, malformed-newer-MAP fallback within the same Store lineage, no-routable-Store-lineage creation, and multiple-routable-Store-lineages-for-the-same-source refusal must also be exercised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.1,Exact eight-column Store MAP serialization acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must validate the exact Store MAP header store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename , UTF-8 without BOM, LF line endings, deterministic mapping-row order, standard governed CSV quoting, and byte-for-byte repetition of store_alias , rid_filename , rid_alias , and the common source_filename on every mapping row. The fixture must prove that a MAP with inconsistent repeated Store-level metadata, more than one rid_filename , more than one source_filename , a missing or invalid RID filename, a duplicate logical source-column key, or a non-eight-column schema is ineligible for inheritance. Source compatibility fixtures must prove that an explicit MAP may proceed only when the Work Order SOURCE exactly equals that MAP's common source_filename . A different source must refuse before materialization even when its row count equals the Store's RID cardinality; matching row count never creates a positional-join escape. P3-06 validation-tier fixtures: acceptance must distinguish Store-health Tier 1 from full Tier 2 validation. A same-named externally restored RID/COL may be treated as eligible only after it passes the tier required by the operation, and no fixture may label such an artifact “the exact original” solely from its physical filename. Tier-1 fixtures must prove the exact bounded checks in W002-STOR-019.10 without an end-to-end scan of every artifact value. Tier-2 fixtures must prove full RID sequence/cardinality validation and full COL canonical-form/header/cardinality validation. REPAIR MAP fixtures must demonstrate that the same input bytes yield one deterministic set of removed COL bindings under Tier 2. P2-04 closure fixtures: acceptance must include (1) a RID that satisfies Tier 1 but fails Tier 2 because the body does not contain the exact declared 1..N sequence; (2) a COL that satisfies Tier 1 but fails Tier 2 because its complete CSV body or logical-record count is invalid; (3) an externally supplied same-named RID/COL that passes the required governed tier without any assertion that it is the historical original bytes; and (4) a REPAIR MAP case with a mixture of Tier-2-valid and Tier-2-invalid COLs proving that the successor removes exactly the failing bindings. Repeating the same fixture bytes must yield the same repair set and successor mapping.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.2,Multiple Stores in one Suitcase remain distinct through RID-anchored MAP lineages,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must establish at least two Stores from different source files in the same Suitcase. Their Store MAP lineages must contain different immutable rid_filename values, and automatic routing for each source must choose only that source's routable Store lineage. The fixture must prove that a lineage remains routable when at least one Store MAP is structurally valid even if subsequent Store-health evaluation is DEGRADED or INVALID ; health may refuse the operation, but it must not make the lineage disappear from routing. Changing a human-facing store_alias or rid_alias in a later governed MAP must not change the Store's rid_filename , RID bytes, or lineage identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.3,WKO MAP profile and alias-registry publication acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must save at least three immutable WKO artifacts, each containing exactly one non-empty WORK ORDER AS clause: one with a multi-word alias, one whose alias is deliberately replaced under the frozen WKO lifecycle, and one with punctuation permitted by the governed string rules. The committed WKO MAP must satisfy the frozen current-registry schema and lifecycle rules, use UTF-8 without BOM and LF endings, preserve exact physical WKO references, and prove deterministic governed serialization. The fixture must prove that a WKO MAP cannot be treated as a Store MAP; duplicate physical WKO rows are invalid; conflicting current authority for the same non-empty alias is refused before commit; and equal-latest-timestamp ambiguity refuses current-registry selection. A saved/executable WKO without WORK ORDER AS is invalid in Revision BM and must refuse before execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.4,WORK ORDER AS and # comment lexical acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must prove that WORK ORDER AS ""Prepare monthly crime data"" is parsed as the immutable WKO alias, that whole-line and trailing # comments are ignored semantically, and that # inside double-quoted strings remains ordinary string content. The fixture must also prove that saved WKO bytes preserve comments exactly, that changing only a comment or Work Order alias requires a new WKO physical identity, and that no standalone browser Description value is required to reopen or display the governed alias. P3-10 alias fixture: acceptance must prove that WORK ORDER AS ""   "" refuses as a whitespace-only alias, while an otherwise valid alias containing leading or trailing whitespace is not silently trimmed or normalized and is preserved exactly in saved WKO bytes and the governed alias registry.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-003,Stage 2 structural window-invariance matrix,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Acceptance fixtures must force input boundaries at structurally difficult positions including before/after delimiters, before/after opening and closing quotes, between doubled quote bytes, between CR and LF, inside quoted multiline field content, at empty fields, and inside already-certified multi-byte UTF-8 sequences. Across permitted window sizes and boundary placements, the logical row count, selected values, canonical COL bytes, first refusal location/condition, and resolved mapping semantics must remain invariant. P3-09 fixtures: acceptance must include both byte forms identified by the Pass 3 finding: (1) an exactly zero-byte source and (2) a source containing only the three UTF-8 BOM bytes EF BB BF . Both must pass the applicable Stage 1 UTF-8 gate and then refuse in Stage 2 with NO_HEADER_RECORD . The exact expected location tuples are respectively (offset 0, physical line 1, logical record 1, field ordinal 1) and (offset 3, physical line 1, logical record 1, field ordinal 1) . The fixtures must also distinguish this case from an existing-but-blank first logical record, which remains BLANK_LOGICAL_RECORD . P3-10 delimiter-help fixture: acceptance must include a quoted semicolon-delimited form such as ""a"";""b"" and an equivalent TAB-delimited quoted form that reach INVALID_BYTE_AFTER_CLOSING_QUOTE . The canonical refusal condition and location facts must remain unchanged, while the Help rendering is permitted to surface the delimiter-mismatch hint for offending byte 0x3B or 0x09 . F-06 structural-refusal acceptance matrix An unexpected quote in an unquoted field must report the quote byte and UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD . A prohibited byte after a closing quote must report that byte and INVALID_BYTE_AFTER_CLOSING_QUOTE . A bare CR outside quoted content must report the CR byte and BARE_CR_OUTSIDE_QUOTED_FIELD . CR, LF, and CRLF inside valid quoted values must remain field content and must not trigger the bare-CR rule. EOF in an open quoted field must report the one-past-end source offset and EOF_INSIDE_QUOTED_FIELD . A blank logical record must report BLANK_LOGICAL_RECORD , not TOO_FEW_FIELDS . A short record must report the terminator/EOF location and the first missing field ordinal. A wide record must report the comma delimiter opening the first extra field and that extra field ordinal. All five refusal facts must remain identical across permitted source-window sizes and boundary placements. Fixtures must force boundaries around commas, opening and closing quotes, doubled-quote pairs, CR/LF pairs, quoted multiline content, empty fields, and already-certified multibyte UTF-8 sequences. A semicolon-separated file must not refuse solely because it uses semicolons; Help may explain comma-only interpretation when header selection fails. Day 060 H-13 Receipt-corpus binding for P3-09 The two analytical P3-09 source fixtures above must each have a corresponding byte-exact refusal Receipt under W002-RCP-ACC-002. The zero-byte and BOM-only cases therefore prove both the parser/refusal oracle and the Receipt serialization oracle independently.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-004,Canonical one-column COL serialization acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Golden-byte fixtures must cover ordinary ASCII, non-ASCII UTF-8, commas, embedded double quotes, CR, LF, CRLF inside quoted values, explicit empty data values, empty source headers, and header-only zero-row input. Acceptance must prove one UTF-8 BOM at file start, LF record termination independent of host platform, deterministic minimal quoting, doubled embedded quotes, """" for an empty one-column data value, no accidental inclusion of the source BOM in the first header, and byte-identical round-trip semantics through the Data Sculptor CSV reader. F-20 oversized-header serialization acceptance: fixtures at exactly 1,024 and 1,025 Unicode scalar values must prove that the physical COL header remains byte-faithful to the exact decoded source header while only the operational/default-alias name changes at the boundary. Scalar-count fixtures must include combining characters so acceptance cannot accidentally measure UTF-8 bytes or grapheme clusters instead.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-005,"Field-limit, ragged-record, blank-record, and failure-publication acceptance",W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Acceptance must include decoded field sizes exactly 16 MiB and 16 MiB + 1 byte, malformed runaway quoted-field cases, nonblank records with too few and too many fields, a bare blank logical data record, explicit empty fields, and a physical blank line inside a valid quoted multiline field. The first invalid case must refuse without truncation or silent repair. Publication evidence must additionally exercise both a new-Store multi-column materialization and a later existing-Store materialization. For the new Store, the shared publication-transaction UTC must be established before any new RID/COL SCR candidate is opened, and each candidate-specific UUID must be allocated before its candidate is created. RID and COL outputs must remain governed SCR until the complete candidate set validates; the RID must then promote first, requested COLs must promote in deterministic KEEP order, the successor MAP UUID must be allocated before its MAP SCR candidate is opened, that MAP candidate must be written/closed/reopened/validated while still SCR , and its final SCR -to- MAP rename must occur last. For every successfully promoted RID, COL, and MAP artifact, acceptance must prove that the candidate and final identity have the exact same UTC, UUID, extension, and bytes and differ in the governed filename only by the three-letter semantic class token. For the existing Store, the inherited RID must remain byte-for-byte and filename-identical with no new RID candidate. F-04 existing-Store cardinality acceptance: acceptance must include two otherwise valid existing-Store materializations using the same exact governed SOURCE identity. In the equal-cardinality fixture, Stage 2 candidate N must equal the inherited RID-header N and publication may proceed under the ordinary rules. In the mismatch fixture, candidate N must differ from RID-header N ; the Run must refuse before any candidate COL is promoted into the final COL namespace and before any successor MAP is published. The inherited RID, current MAP, existing COL artifacts, and Store health must remain unchanged, with the existing Store remaining VALID. The equal-cardinality case must not be represented as proof of source-byte or row-semantic identity. Forced failure cases must cover: failure before any promotion; RID-promotion failure; failure during COL promotion after RID and at least one COL have promoted; MAP-candidate write/close/reopen/validation failure; MAP final-rename failure; and interruption after physical RID/COL promotion but before MAP commit. Each case must prove rollback where safely possible or visible non-authoritative SCR failure evidence otherwise, must prove that unreferenced final-class-looking RID/COL files are not treated as committed Store membership, and must prove that the prior valid MAP remains authoritative for an existing Store or that no committed Store exists for an uncommitted first materialization. F-20 bounded-width/name acceptance: acceptance must cover exactly 16,384 versus 16,385 source columns; KEEP widths of 1 and 16,384 ; operational-name derivation at 1,024 versus 1,025 Unicode scalar values; physical ordinals producing Column A , Column Z , Column AA , and Column XFD ; and deterministic oversized-header fallback collisions proving [ordinal] then -2 progression. A separate short-header alias collision must prove refusal rather than automatic suffixing.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-006,Large-source browser materialization evidence,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance must include a browser run against the established Statistics Canada scale source or an equivalently retained scale fixture, recording source bytes, Stage 1 time, Stage 2 time, total time, selected-column count, logical row count, bytes written per COL , peak/bounded memory observations, output fingerprints, and browser/platform details. The retained Day 039 evidence established that Microsoft Edge could stream the 7,250,808,204-byte source through a small Rust/WASM materializer and materialize 29,014,718 VALUE data rows in practical time. Revision AM treats that result as engineering evidence and a comparison baseline, not as proof that WASM-002 is already implemented or as a frozen wall-time threshold. F-20 writer-resource evidence: retained acceptance evidence must identify the build's configured maximum simultaneously active writable-output resources and the observed peak for the run. Evidence must show that wide KEEP cardinality does not imply one simultaneously open writer per selected column and that any bounded spool/finalization strategy preserves the same governed output bytes and semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-ACC-001,Separate Windows-1252 conversion,W002-CONV-ACC,W002-CONV,WASM-002,UNDER REVIEW,—,"A non-UTF-8 fixture compatible with the supported Windows-1252 converter must cause the analytical task to stop, permit a Help suggestion, and succeed only when the separate conversion Work Order is explicitly run. P3-08 acceptance: the fixture set must convert an analyst-owned legacy source successfully, materialize the resulting CVT, then perform a second successful conversion from a refreshed legacy source using the same analyst-owned filename. The second conversion must publish a different CVT physical filename. First materialization of that second CVT must establish a distinct Store/RID lineage rather than inherit from the first CVT-backed Store. Acceptance must also prove that Help discloses this consequence at conversion success and again when the CVT is first materialized, and that no hidden original-source identity is used to join the two CVTs into one lineage. F-16 acceptance: the compatible non-UTF-8 fixture must prove that strict UTF-8 certification first emits DS-ENC-001 with next_action: NONE ; Stage 2 does not start; Data Sculptor restarts at byte 0 of the same bound source instance and scans the complete source under the frozen mapping; the Receipt records WINDOWS_1252_COMPATIBILITY_OUTCOME: COMPATIBLE and WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET: NOT_APPLICABLE ; and only then is DS-CNV-001 emitted with severity: INFO , behavior: CONTINUE , and next_action: RUN_WINDOWS_1252_CONVERSION . The refused MATERIALIZE run must remain refused. A separate valid-UTF-8 fixture must prove that both Windows-1252 compatibility Receipt fields are NOT_RUN and DS-CNV-001 is not emitted. F-10 conversion-gate and byte-output acceptance A source already valid as complete strict UTF-8 must refuse CONVERT WINDOWS-1252 TO UTF-8 as unnecessary and create no CVT . A source that fails strict UTF-8 but passes the complete Windows-1252 compatibility assessment may convert only when the separate conversion WKO is explicitly run. The analyst-owned source bytes must remain unchanged. The published CVT must pass complete strict UTF-8 certification. Source CR, LF, and CRLF bytes must be preserved in place rather than normalized. The conversion must remain bounded/streaming. The published CVT must not begin with a UTF-8 BOM introduced by Data Sculptor. The successful Receipt must contain the frozen conversion operation token and required conversion facts. Frozen minimal byte oracle: Windows-1252 source bytes:
63 61 66 E9 0D 0A

UTF-8 CVT bytes:
63 61 66 C3 A9 0D 0A This is café followed by CRLF. The expected CVT begins with byte 63 ; no EF BB BF prefix is present. Day 060 H-25 / BM-04 acceptance: the already-valid-UTF-8 CONVERT fixture must use a complete source whose byte stream is valid strict UTF-8 and must produce a byte-exact refused Receipt containing: SOURCE_ENCODING: UTF-8
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: NOT_RUN
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE The same fixture must prove that no Windows-1252 compatibility assessment runs, no transcoding begins, the analyst-owned source bytes remain unchanged, and no CVT file is created.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-ACC-002,Undefined Windows-1252 byte refusal,W002-CONV-ACC,W002-CONV,WASM-002,UNDER REVIEW,—,"A fixture containing a byte undefined by the frozen Windows-1252 mapping must not be silently converted. F-16 acceptance: use fixtures placing each of 0x81 , 0x8D , 0x8F , 0x90 , and 0x9D at controlled physical offsets, including across compatibility-buffer boundaries. The complete oracle must prove WINDOWS_1252_COMPATIBILITY_OUTCOME: INCOMPATIBLE , the exact first undefined-byte offset, no DS-CNV-001 emission, no conversion recommendation, and window-size invariance. A separate injected read-failure fixture after the compatibility pass begins must prove NOT_AVAILABLE for both compatibility Receipt fields and no conversion recommendation. F-10 conversion-operation undefined-byte acceptance The separate CONVERT WINDOWS-1252 TO UTF-8 operation must itself refuse before transcoding when its complete compatibility assessment encounters any byte undefined by the frozen Windows-1252 mapping. Such a refusal publishes no CVT . Acceptance must cover each frozen undefined byte value at a controlled absolute source offset and prove that no replacement-character, ISO-8859-1, or permissive-decoder fallback produces output. Day 060 H-14 / BM-11 byte-exact undefined-byte CONVERT fixture The golden CONVERT refusal fixture uses this exact analyst-owned source byte sequence: 41 81 42 The strict UTF-8 gate must fail, and the subsequent complete Windows-1252 compatibility assessment must encounter 0x81 as the first undefined byte at exact zero-based absolute physical source-byte offset 1 . The operation must refuse before transcoding begins. The byte-exact Receipt for this fixture must include: SOURCE_ENCODING: WINDOWS-1252-INCOMPATIBLE
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: 1
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE
RESULT: REFUSED The analyst-owned source bytes must remain exactly 41 81 42 ; no CVT is published; no replacement character is introduced; and no ISO-8859-1 or permissive-decoder fallback is permitted. A second acceptance form must place at least two undefined Windows-1252 bytes in one source and prove that the reported offset is always the first undefined byte. Buffer/window-boundary variants must preserve the same absolute offset.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-001,Canonical diagnostic event,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,At least one real governed WASM-002 failure path must emit a complete canonical diagnostic event with stable code and structured facts. A separate test-only fault-injection fixture must remove or withhold one required fact while the engine attempts to assemble a registered diagnostic. Acceptance must prove that the malformed intended diagnostic is not emitted and that exactly one canonical DS-HLP-001 replacement event is emitted with the exact intended diagnostic ID and the complete ascending-UTF-8 list of missing required fact keys.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-002,Three-voice rendering parity,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"A complete event with an authored catalog entry must be renderable in all three established Help voices. Automated checks must demonstrate invariant diagnostic truth across the three outputs. A separate complete registered diagnostic fixture must deliberately have no help_messages.json entry. Casual, Office Speak, and Technical selections must all resolve to the same deterministic Generic Technical Help fallback, preserving the original diagnostic semantic core and rendering emitted facts in ascending UTF-8 fact-key order without invented cause or remediation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-003,Saved HTML Help report using the canonical built-in Data Sculptor presentation,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,At least one complete HTML Help report using the canonical built-in Data Sculptor presentation must be generated and saved locally from that real event.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-004,Offline durability,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,The saved HTML report must remain readable with its canonical built-in Red5Sorcery/Data Sculptor presentation when opened without network access and without access to Data Sculptor or any external presentation resource.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-008,Support-handoff report acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"From a real governed refusal, Data Sculptor must generate one styled HTML Help Report that opens in an ordinary browser without Data Sculptor or network access and contains both a selected-voice explanation and the canonical structured facts needed by a technical reviewer.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-009,Canonical boundary-fact acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"An early-refusal fixture that stops before analytical materialization must demonstrate the exact four Boolean fact names from W002-HELP-004.11 and, when those are the true governed facts, values equivalent to: source_modified_by_data_sculptor = false
materialization_started = false
analytical_outputs_published = false
store_state_committed = false Acceptance must also exercise at least one boundary-fact case in which an established Boolean value is unavailable or otherwise carries an applicable governed absence state. The emitted value must use the exact shared JSON string token required by W002-HELP-004.11 (for example ""NOT_AVAILABLE"" ) and must not be coerced to false or JSON null . Where a boundary fact is optional and its key is omitted, acceptance must prove that omission is not interpreted as false or as any governed absence token. The same fixture family must prove that temporary SCR candidates or abandoned/uncommitted debris do not make analytical_outputs_published true.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-010,"HLP provenance, multiplicity, and no-automatic-hash acceptance",W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"Acceptance evidence must generate a final HLP using the built-in Red5Sorcery/Data Sculptor presentation and verify its governed __DS__HLP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html identity, its visible Provenance section, and exactly one embedded application/json payload with element ID ds-hlp-provenance . The embedded payload must contain exactly the schema-version-2 fields governed by W002-HELP-009 and must verify the same HLP filename/generation UTC, non-empty ordered diagnostic_ids array, WKO/RCP lineage semantics, selected Help voice, built-in presentation identifier red5sorcery-data-sculptor , built-in presentation version ""1"" , and the exact running Data Sculptor build identifier. Acceptance must cover: (1) an explicit request for a single diagnostic; (2) one governed Run with multiple included diagnostic events, proving exactly one HLP for the request and event-order parity with diagnostic_ids ; and (3) a non-run diagnostic such as Suitcase-validation or WKO-save refusal, proving that non-applicable WKO/RCP lineage is represented by JSON null and visible NOT APPLICABLE rather than invented Run lineage. Acceptance must also cover all three lineage representations permitted by W002-HELP-009: an exact physical filename when the relationship exists and is known; JSON null when the relationship does not apply; and the exact JSON string ""NOT_AVAILABLE"" when the relationship applies but its exact filename cannot be obtained. The fixture must prove that null and ""NOT_AVAILABLE"" are not interchangeable. Acceptance must prove that the visible Provenance section and machine-readable payload agree semantically; missing, duplicate, malformed, mismatched, non-HTML-safe, disclosure-violating, empty diagnostic_ids , or scope-label-only build provenance must not be accepted. The same acceptance must prove that ordinary HLP generation does not compute or embed an HLP SHA-256 and does not create, refresh, or verify an LCK . Exact-byte HLP integrity remains outside WASM-002 in the later explicit FINGERPRINT/LCK workflow.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-011,Fixed support-handoff disclosure acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"Acceptance must prove the fixed support-handoff disclosure boundary with both permitted-context and adversarial headerless fixtures. A permitted-context fixture must generate an HLP whose diagnostic requires a source filename, one genuinely established relevant source header and/or 1-based column number, bounded execution evidence, and a small executable Work Order excerpt. A governed alias may appear only when the alias itself is necessary to explain the diagnostic, such as an alias collision, ambiguity, or mutation; an unrelated alias must remain excluded. The report must include only the necessary permitted facts while excluding source rows/values, absolute local paths, unrelated headers/aliases/columns, the complete Work Order, Work Order comments, unrelated Suitcase contents, and raw ungoverned stack traces. A separate headerless-source fixture must place unmistakable sentinel text in the first data row and prove that none of that text appears in the HLP as a header or other disclosed source value. That HLP must show Source header text included: NO and Source values included: NO while still presenting sufficient structural evidence to explain the diagnostic. A genuine-header fixture must prove that a necessary established header may appear with Source header text included: YES . Alias fixtures must similarly prove truthful Governed alias text included: YES only when necessary and NO otherwise. Every fixture must verify the remaining frozen Disclosure declarations from W002-HELP-010. WASM-002 must expose no control that changes this fixed disclosure policy.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-012,Cross-session source-continuity Help acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"An acceptance fixture must present Help with a suspected cross-session source-change scenario and verify that the explanation asks whether the source may have been edited/replaced/sorted/re-exported/synchronized, distinguishes no evidence from INVENTORY metadata evidence and stronger explicit fingerprint evidence, and never claims that unchanged filename or unchanged INVENTORY metadata proves byte identity. A no-evidence fixture must state that continuity cannot be independently verified. An INVENTORY fixture with changed source byte length or last-modified metadata must describe the difference as evidence that the source may have changed, not as a cryptographic conclusion. The fixture must also confirm that ordinary WASM-002 materialization did not automatically hash the source as part of this edge-case protection.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-013,Diagnostic-registry and Help cross-validation acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance must retain the validated diagnostics.json used by the accepted build and verify its exact version-1 schema, canonical sort order, unique permanent IDs, fixed-token grammars, and disjoint required/optional fact declarations. At least one real governed diagnostic fixture must prove that the emitted semantic core matches the matching registry entry and that all required facts are present while no undeclared fact key is emitted. Negative build-validation fixtures must prove deterministic failure for malformed/duplicate registry entries, an engine diagnostic definition absent from the registry, fixed semantic disagreement, an undeclared emitted fact, a Help-catalog diagnostic ID absent from the registry, and a Help placeholder not declared for its matching diagnostic. F-17 runtime completeness fixtures: missing required facts are no longer treated as a malformed event that may leak to Help. Fault injection must prove deterministic substitution with DS-HLP-001 , including exact intended_diagnostic_id and sorted missing_required_facts , with no partially populated intended diagnostic emitted. Separately, a valid registered diagnostic omitted from help_messages.json must remain a valid build/runtime condition and must exercise the Generic Technical fallback rather than build failure or diagnostic suppression. F-22 QA-independence acceptance boundary: acceptance must prove the registry/engine/Help wiring and generic invariants without circularly presenting the implementation-delivered registry as an independent oracle for its own condition-to-Diagnostic-ID allocations. Representative governed fixtures must trace condition → emitted Diagnostic ID → matching registry semantic core → required/optional fact discipline → Help lookup/rendering. Every condition-to-ID or required-fact mapping explicitly frozen elsewhere in this PRD remains independently testable and must match that PRD contract. For allocations not independently pinned by this PRD, WASM-002 does not require a duplicate QA-owned registry that restates every condition-to-ID choice. Passing this acceptance gate therefore demonstrates registry integrity, engine↔registry semantic agreement, fact completeness/legality, Help-catalog wiring, F-17 fail-safe behavior, and representative end-to-end diagnostic routing; it must not be reported as exhaustive independent proof that every possible runtime condition was assigned the semantically correct Diagnostic ID. That residual independence limitation is an accepted WASM-002 risk. F-23 embedded Help-catalog release fixture: acceptance must build the released HTML from a validated help_messages.json , verify exactly one non-executable application/json payload with element ID ds-help-catalog , and include adversarial catalog text containing literal < / script-like delimiter content to prove HTML-safe embedding. Runtime instrumentation must prove that Help lookup reads only the embedded payload and performs no network, filesystem, Suitcase, or adjacent-file fetch for the Help catalog. A missing, malformed, mismatched, or unsafe embedded catalog must fail build acceptance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-007,Work Order syntax is the analytical contract,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"If a value, reference, option, or instruction changes what Data Sculptor analytically does, that intent must be represented in governed Work Order text or in a separately governed artifact explicitly referenced by that Work Order. Browser permission, directory selection, UI focus, a highlighted file, an alias display, or another GUI gesture must not silently become analytical intent. For WASM-002, every executable saved WKO begins with the common preamble: SUITCASE: .
WORK ORDER AS ""<non-whitespace alias>"" Ignoring blank lines and governed comments, the WKO must then parse completely under exactly one of these seven executable operation grammars: Operation Governed DS-STEPS structure after the common preamble MATERIALIZE SOURCE ""..."" ; optional MAP ""..."" ; KEEP ; one or more selectors; terminal MATERIALIZE . INVENTORY terminal INVENTORY only. UPDATE ALIASES exactly one Store-state selector: SOURCE ""..."" or MAP ""..."" ; one or more governed alias mutations; terminal UPDATE ALIASES . REPAIR MAP exactly one MAP ""<exact current Store MAP filename>"" ; terminal REPAIR MAP . REPAIR WORK ORDER REGISTRY terminal REPAIR WORK ORDER REGISTRY only. CONVERT WINDOWS-1252 TO UTF-8 exactly one SOURCE ""..."" ; terminal CONVERT WINDOWS-1252 TO UTF-8 . CATALOG STORES terminal CATALOG STORES only. Each operation-specific numbered requirement remains authoritative for its detailed selectors, preconditions, mutations, publication semantics, and acceptance behavior. This requirement freezes the cross-operation boundary: unknown semantic lines refuse; clauses from another operation grammar refuse unless the selected operation explicitly defines them; there is no best-effort interpretation and no silent cross-operation mixing. Lexical token separation. DS-STEPS keywords are matched ASCII case-insensitively; canonical examples render them uppercase. Wherever two adjacent lexical tokens would otherwise run together, they must be separated by one or more ASCII SPACE ( 0x20 ) or horizontal TAB ( 0x09 ) characters. Leading SPACE/TAB indentation is semantically neutral. Thus REPAIR MAP , SOURCE ""crime.csv"" , and COLUMN 7 are valid tokenizations, while REPAIRMAP , SOURCE""crime.csv"" , and UPDATE_ALIASES are not alternate DS-STEPS spellings. Quoted-string contents are never case-folded or whitespace-normalized merely because keywords are case-insensitive. The browser may authorize resources, edit text, validate, save, invoke Run, display evidence, and provide Help. Authorization to access a resource is not authorization to use that resource analytically.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-008,Every executable Work Order explicitly declares its Suitcase,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"For WASM-002, every executable saved Work Order must contain the exact portable declaration SUITCASE: . . The dot means the filesystem directory that physically contains the saved WKO artifact being executed. A Work Order lacking this declaration must not be treated as an executable WASM-002 Work Order. The declaration is analytical/execution syntax, not a substitute for browser filesystem permission. The host must still possess valid access to the directory before execution can proceed. Help obligation: Data Sculptor Help must explain SUITCASE: . in plain language: the saved Work Order uses the folder that contains that WKO as its Suitcase; the dot means “this folder”; ordinary Work Order file references are therefore portable and Suitcase-relative; and browser/host permission to the folder is granted separately. Help must not teach an absolute machine path as the normal replacement for . .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-009,Ordinary Work Order file references are Suitcase-relative,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Unless another numbered requirement explicitly governs a different reference mechanism, file references in an executable WASM-002 Work Order resolve relative to the declared Suitcase. A portable Work Order must not depend on an absolute machine-specific path to identify ordinary Suitcase files. Resolution must be deterministic in browser and later native hosts. Moving an intact Suitcase to another permitted filesystem location must not change the logical meaning of the Work Order solely because the parent machine path changed.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-009.1,WASM-002 SOURCE eligibility is exact and root-bounded,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"A WASM-002 SOURCE clause names exactly one physical regular file in the Suitcase root by exact filename only. It must not name an absolute path, drive or UNC path, subdirectory, path containing / or \ , traversal such as .. , URL/URI, or another external reference. Resolution uses the exact Unicode-scalar filename identity and reference-bounded rules frozen by F-15; no case-folding, normalization, trimming, or filesystem-equivalence search is permitted. The only eligible WASM-002 SOURCE kinds are: Analyst-owned CSV: a regular Suitcase-root file whose exact filename does not begin with the reserved exact prefix __DS__ and whose final extension is .csv under ASCII case-insensitive extension recognition. Thus .csv , .CSV , and mixed-case equivalents are candidate CSV extensions. This case-insensitivity applies only to extension recognition; the complete filename reference remains exact. If the physical file is crime.CSV , a differently cased full filename does not become an alternate reference to it. Governed converted source: a successfully published CVT whose exact canonical identity and class-specific publication/validity predicate satisfy W002-CONV-004, W002-STOR-023, and PB-STOR-008. A filename that merely resembles a CVT is not sufficient. No other governed semantic class is eligible as SOURCE in WASM-002, even when its physical serialization is CSV. In particular, COL , RID , MAP , CAT , INV , RCP , HLP , CER , SCR , RCV , and WKO artifacts cannot be reintroduced as SOURCE merely because their bytes or extension appear compatible. A recognized .csv extension establishes only candidate SOURCE form. It does not certify encoding or CSV structure; the normal strict UTF-8 and structural certification contracts still govern after source resolution. Conversely, CSV-like bytes stored under a non-CSV analyst-owned extension are not an eligible WASM-002 SOURCE.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-008; CP-009; CP-010,"T-ACCEPTED, BANKED; analyst-owned CSV filename candidate preflight only; full SOURCE eligibility remains partial; CP009 T-ACCEPTED, BANKED — pure exact-name root snapshot matching only; full requirement remains partial; CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open",346733a962192320e0d56271add15a47b6037b6b; dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8; b7c515faa9bd000369d7656e09437310261290ae,Evidence/CP-008/CP008_RED_Test_Output.txt; Evidence/CP-008/CP008_GREEN_Test_Output.txt; Evidence/CP-008/CP008_Full_Regression_Test_Output.txt; Evidence/CP-008/CP008_Post_Format_Test_Output.txt; Evidence/CP-008/CP008_Rustfmt_Check_Output.txt; Evidence/CP-008/CP008_WASM_Build_Output.txt; Evidence/CP-008/CP008_Hash_Inventory_Verification.txt; Evidence/CP-008/CP008_Precommit_Git_Review.txt; Evidence/CP-008/CP008_Final_Source_Review.txt; Evidence/CP-008/CP008_Whitespace_Exception_Review.txt; CP008_Git_Banking_Output.txt (separate post-commit evidence; archived outside repository); Evidence/CP-009/CP009_Baseline_Test_Output.txt; Evidence/CP-009/CP009_RED_Test_Output.txt; Evidence/CP-009/CP009_GREEN_Test_Output.txt; Evidence/CP-009/CP009_Full_Regression_Test_Output.txt; Evidence/CP-009/CP009_Rustfmt_Check_Output.txt; Evidence/CP-009/CP009_Git_Whitespace_Check.txt; Evidence/CP-009/CP009_Post_Format_Test_Output.txt; Evidence/CP-009/CP009_WASM_Build_Output.txt; Evidence/CP-009/CP009_Hash_Inventory.txt; Evidence/CP-009/CP009_Hash_Inventory_Verification.txt; Evidence/CP-009/CP009_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Final_Staging_Review.txt; CP009_Git_Banking_Output.txt (separately archived post-commit evidence); Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived),"CP008 Day066: public is_analyst_owned_csv_source_candidate(&str) -> bool recognizes the final .csv extension ASCII case-insensitively for exact Suitcase-root analyst-owned candidate names. It refuses empty stems, __DS__-reserved names, slash/backslash paths, colon-bearing references, and traversal-like double-dot forms; preserves full spelling, case and Unicode normalization distinctions. Five new tests and 23 prior tests passed, 28/28 after Rustfmt. WASM32-target library compilation passed; no standalone browser execution proven. 20/20 SHA-256 file inventory matched; staged Rust source/test whitespace check 0. Full staged whitespace check 2 due solely to two preserved archival trailing-space lines in the CP008 precommit TXT, documented with supplemental diagnostic. Human T approved; Git commit banked with 18 files and clean working tree. This is ONLY lexical analyst-owned CSV candidate form, NOT regular-file proof, exact physical filename resolution, governed CVT publication, CSV UTF-8 certification, full SOURCE eligibility, or requirement acceptance. Independent Claude implementation QA pending. CP009 Day066: match_analyst_csv_root_snapshot(&str, &[RootSnapshotEntry]) -> RootSnapshotMatch applies CP008 analyst CSV candidate preflight, then exact Rust string equality (case, Unicode scalar sequence and whitespace preserved), reports no match, reported nonregular entry, ambiguous duplicate exact entries, or single caller-reported regular file. Entry origin and kind are caller assertions, not independently verified. Eight new tests; post-format full native regression 36/36; wasm32-unknown-unknown library compilation exit 0; SHA-256 inventory verified 22/22; staged whitespace exit 0; T approved and git banked 15 files, clean working tree. This is NOT actual root scanning, filesystem entry proof, browser permission, CSV/UTF-8 certification, governed CVT SOURCE eligibility or end-to-end requirement acceptance; independent Claude QA pending. CP010 Day066 adds is_governed_cvt_source_filename_candidate(&str)->bool, requiring existing canonical immutable envelope validator, exact CVT class, and exact lowercase .csv serialization token. Four bounded tests pass and native full regression 40/40; wasm32-target library build PASS with Rust 1.97.1; format check PASS; primary 29/29 and supplementary 8/8 SHA-256 verification PASS; staged whitespace PASS with documented exact-file archival exceptions; T approval; git b7c515faa9bd000369d7656e09437310261290ae committed 28 files and clean working tree. No physical file checks, conversion execution, close/reopen, publication predicate, UTF-8/CSV certification, executable SOURCE authority or browser runtime proven. Independent Claude QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-010,WIP and WKO are distinct Work Order lifecycle states,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"WIP is the editable, non-executable Work Order state. WKO is the saved, validated, immutable Work Order artifact that may become a Run target. Validation establishes that a Work Order is structurally eligible to run; it does not guarantee that runtime conditions will succeed. Loading a WKO for inspection does not make it mutable. If its instruction text is changed, the editor must treat the edited text as a new WIP derived from the original WKO. The original WKO bytes and physical identity remain unchanged, and the derived WIP cannot Run until saved as a new WKO. F-08 Run distinction: the browser Run action invokes one selected saved immutable WKO that is eligible under the governed WKO-registry rules. No ordinary WASM-002 WKO contains a textual RUN line merely to execute itself. The DS-STEPS token RUN is reserved for future saved-Work-Order composition under W002-WKO-011 and is not repurposed as the browser execution trigger.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-013,WASM-002 executes one saved Work Order without Work Order chaining,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"For WASM-002, one saved immutable WKO is one top-level executable request. It must not invoke, include, chain, or execute another WKO. The governed RUN composition operation and equivalent nested-orchestration constructs are not executable in WASM-002. If a saved WKO contains composition syntax, validation must refuse before analytical execution begins. The canonical diagnostic and Help path must explain that Work Order composition is deferred rather than treating the syntax as arbitrary text, silently ignoring it, or partially executing surrounding instructions. This scope cut does not prohibit one Work Order from selecting and materializing multiple columns in the single Stage 2 operation defined by WASM-002.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012,Materialization COL alias assignment uses AS; standalone alias maintenance uses UPDATE ALIASES,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within the WASM-002 DS-STEPS materialization form, an analyst assigns or changes the alias of a selected materialized COL with the optional same-line clause AS ""alias"" under W002-STEPS-005. This syntax is part of the governed Work Order and is not a GUI gesture. A single KEEP block may therefore assign aliases to multiple selected columns in one governed materialization. Automatic source-header COL aliases and inherited rematerialization aliases are resolved first; explicit AS clauses then determine requested successor COL aliases before complete Store-MAP validation and publication. Revision BD freezes alias-only creation/replacement with UPDATE ALIASES and explicit historical Store-MAP selection with MAP ""<exact Store MAP filename>"" . Revision BE completes the bounded alias lifecycle with explicit CLEAR ... ALIAS and RESET ... ALIAS forms under W002-WKO-012.5 through W002-WKO-012.6. Empty-string AS """" is not the clearing syntax.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.1,Canonical standalone alias-maintenance Work Order uses UPDATE ALIASES,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"The canonical alias-only Store metadata forms are: SUITCASE: .
WORK ORDER AS ""Rename crime store""
SOURCE ""35100178.csv""
STORE AS ""Crime Statistics""
UPDATE ALIASES or, when the analyst intentionally selects one exact Store snapshot: SUITCASE: .
WORK ORDER AS ""Rename crime store""
MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""
STORE AS ""Crime Statistics""
UPDATE ALIASES UPDATE ALIASES is the explicit terminal commitment clause for an alias-only Work Order. The WKO must identify exactly one Store-state base using either SOURCE ""..."" for ordinary Store-aware current-state selection or MAP ""..."" for exact Store-MAP selection, never both. At least one supported alias mutation clause must occur after the Store-state selector and before UPDATE ALIASES . An alias-only Work Order must not contain KEEP , MATERIALIZE , INVENTORY , conversion, Store repair, Work Order registry repair, cataloging, deferred Work Order composition, or another operation's terminal clause. Alias maintenance changes governed human-facing metadata only.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.2,"STORE AS, RID AS, and COL ... AS are the canonical alias-replacement clauses",W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical mutation clauses are: STORE AS ""Crime Statistics""
RID AS ""Row Number""
COL ""Crime Rate"" AS ""Police-Reported Crime Rate"" STORE AS ""..."" replaces the selected Store snapshot's store_alias . RID AS ""..."" replaces its rid_alias . COL ""<reference>"" AS ""..."" replaces the alias of exactly one existing mapped COL. The COL reference resolves under W002-STOR-021: it may be the exact physical column_filename or one unique current COL alias from the selected Store MAP. Missing, ambiguous, non-COL, or conflicting resolution must refuse rather than guess. One Work Order may update the Store alias, RID alias, and multiple distinct COL aliases together, provided the complete successor state satisfies all existing alias uniqueness/shadowing rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.3,"MAP ""<filename>"" is the exact historical Store-MAP selector",W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"The canonical explicit Store-MAP selection clause is: MAP ""__DS__MAP__20260920T184512347Z__<uuid-v4>.csv"" The value is always the exact physical filename of one structurally valid immutable Store MAP. It is not a Store alias, WKO alias, timestamp shorthand, UUID-only selector, or latest expression. For MATERIALIZE, if present, the clause occurs immediately after SOURCE and before KEEP . It overrides automatic Store-MAP inheritance and binds the run to exactly the named Store snapshot. For alias-only maintenance, the Work Order uses either SOURCE ""..."" or MAP ""..."" as its Store-state selector, not both. For materialization, SOURCE ""..."" remains mandatory and an optional MAP ""..."" supplies the exact historical/current Store-state base. Validation must refuse an incompatible source/MAP pairing or a MAP that is not a valid Store-MAP profile. Health rule: explicit historical selection does not override the current Store-lineage health gate. The selected lineage must currently be VALID and every RID/COL binding referenced by the named MAP must currently be present and valid. Otherwise the operation refuses. This applies equally to MATERIALIZE and UPDATE ALIASES. F-05/P2-01 source-compatibility predicate: for materialization, an explicitly named MAP is compatible only when the mandatory Work Order SOURCE exactly equals the one common source_filename carried by that Store MAP. If the exact filenames differ, validation refuses before the F-04 existing-Store cardinality gate in W002-MAT-002.6. Equal row count never authorizes a different source to enter the selected Store lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.4,Alias-only execution publishes one complete successor Store MAP and no rewritten data artifacts,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"A successful UPDATE ALIASES operation begins from the selected complete Store MAP, applies only the requested alias replacements in memory, validates the complete resulting Store state, writes the successor MAP under governed SCR , closes and reopens it, validates it fully, and promotes it to a new immutable MAP last. That successful promotion is the alias-update commit point. The operation must preserve the selected Store's physical RID and COL filenames and bytes, source-column keys, row order, cardinality, and lineage except for the human-facing alias fields explicitly changed by the Work Order. It must not reread source data rows merely to change aliases, must not create RID/COL artifacts, and must not rewrite or delete the inherited MAP. The prior MAP remains visible historical state. If validation or MAP publication fails, no successor alias state becomes current. The failure is reported through the governed diagnostic/Help path and any incomplete candidate remains subject to the retained- SCR failure-evidence rules in W002-STOR-023.1; WASM-002 does not emit RCV. Revision BM E-02 integration: when the alias-only operation uses an explicitly named historical Store MAP, publication is permitted only if the Store lineage currently evaluates VALID and every RID/COL binding referenced by that named MAP is currently present and valid. An older MAP cannot be used to bypass current damage. P3-06 validation depth: because UPDATE ALIASES does not consume RID/COL analytical contents, its Store-health and binding checks use Tier 1 under W002-STOR-019.10. The operation must not scan every RID/COL record merely to change aliases. This does not weaken later operations that actually consume those artifacts; they must perform the applicable Tier 2 validation before relying on the contents.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-007,Standalone Store/RID/COL alias maintenance acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance must establish a Store with one RID and at least three materialized COLs, then execute an alias-only Work Order that changes the Store alias, RID alias, and at least two COL aliases in one UPDATE ALIASES operation. One COL must be targeted by its unique current alias and another by its exact physical COL filename. The fixture must prove that exactly one complete successor Store MAP becomes current; prior MAP, RID, and COL artifacts remain byte-for-byte unchanged; no source-data row read is required; no new RID/COL artifact is published; and the successor MAP contains exactly the requested aliases while preserving all physical bindings and logical source-column keys. Missing/ambiguous COL references and successor alias collisions must refuse without publishing a successor MAP. F-23 CLEAR/RESET alias fixtures: acceptance must separately exercise CLEAR STORE ALIAS , CLEAR RID ALIAS , CLEAR COL ""<reference>"" ALIAS , RESET STORE ALIAS , RESET RID ALIAS , and RESET COL ""<reference>"" ALIAS . Each CLEAR fixture must prove that the successor MAP stores the governed empty alias without renaming or rewriting the referenced artifact. Each RESET fixture must prove restoration of the exact deterministic default governed by W002-WKO-012.6 and W002-STOR-019.7, including the oversized-header operational fallback where applicable. The fixtures must prove that CLEAR and RESET require no source-data row read, publish exactly one complete successor Store MAP on success, leave the predecessor MAP/RID/COL bytes unchanged, and deterministically refuse duplicate mutation of the same alias field or a reset/default value that fails the complete successor alias validity/uniqueness/shadowing rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-008,Explicit historical Store-MAP selection acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance must create at least two valid Store MAP snapshots for one Store, then prove that a Work Order containing MAP ""<older exact Store MAP filename>"" binds to that exact older snapshot even though a newer valid MAP exists. An alias-only fixture must publish its successor from the explicitly named older base rather than from the newer automatic current state. A materialization fixture must retain mandatory SOURCE ""..."" while using the explicit MAP as its Store-state base. The tests must also prove refusal for a missing MAP, malformed MAP, WKO-MAP profile supplied as Store MAP, and source/MAP incompatibility. No implementation may substitute the newest MAP after an explicit MAP clause has validated. F-21 chronology acceptance: the fixture must use at least three successive valid MAP snapshots for one Store so that an explicitly selected older base and a distinct pre-run current MAP both exist. Merely selecting/validating the older MAP must leave current authority unchanged. A successful governed operation from that older base must then publish exactly one new successor whose requested state is derived from the named older base, whose publication UTC is later than the pre-run current chronology predecessor, and which becomes current under ordinary greatest-UTC selection. The selected historical MAP and the formerly current MAP must remain byte-for-byte unchanged. Acceptance must prove that later mappings/aliases present only in the formerly current MAP are not silently merged into the historical-base successor unless the Work Order explicitly recreates them. Receipt evidence must identify the exact operation base and exact published successor through the already-frozen operation-specific Receipt fields. No additional warning/permission gate or informational diagnostic is required merely because the analyst explicitly chose a historical base.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.5,CLEAR ... ALIAS deliberately removes a human-facing alias,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical clearing forms are: CLEAR STORE ALIAS
CLEAR RID ALIAS
CLEAR COL ""<reference>"" ALIAS CLEAR deliberately stores the empty string in the corresponding alias field of the successor Store MAP. It does not restore a default alias. An empty-string replacement such as STORE AS """" , RID AS """" , or COL ""..."" AS """" is not the canonical clearing form and must be rejected by the bounded WASM-002 grammar. For CLEAR COL , <reference> resolves against the selected pre-mutation Store MAP by exact physical column_filename or one unique current COL alias under W002-STOR-021. All COL references in one UPDATE ALIASES Work Order are resolved before any mutation is applied so clause order cannot change target identity. Missing, ambiguous, duplicate-target, or non-COL references must refuse. Clearing an alias never renames, rewrites, or deletes the underlying RID/COL artifact and never changes physical identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.6,RESET ... ALIAS restores the deterministic default alias,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical reset forms are: RESET STORE ALIAS
RESET RID ALIAS
RESET COL ""<reference>"" ALIAS RESET STORE ALIAS restores the Store MAP's common exact source_filename . RESET RID ALIAS restores the literal RID . RESET COL ""<reference>"" ALIAS restores that mapped COL's deterministic operational default defined by W002-STOR-019.7 from its exact recorded source_header and physical source ordinal: the exact header when it contains at most 1,024 Unicode scalar values, or the deterministic Column <LETTERS> fallback/disambiguation rule when the recorded header exceeds that boundary. RESET never substitutes the potentially oversized exact header into the alias field merely because that header remains authoritative source evidence. RESET is therefore distinct from CLEAR . The restored value must pass the same governed alias validity, uniqueness, and shadowing rules as any explicit alias. If the deterministic default is empty or conflicts in the complete successor Store MAP, RESET must refuse except for the narrow oversized-header fallback/disambiguation rule already frozen in W002-STOR-019.7; Data Sculptor must not otherwise invent a suffix, alternate spelling, or substitute. AS , CLEAR , and RESET mutations may coexist in one Work Order when they target distinct alias fields; duplicate mutation of the same alias field in one Work Order must refuse. A successful operation publishes exactly one complete successor Store MAP under the existing UPDATE ALIASES commit contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001,Canonical WASM-002 DS-STEPS materialization form,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 materialization Work Order form is: # Optional human comment
SUITCASE: .
WORK ORDER AS ""Prepare monthly crime data""
SOURCE ""crime.csv""
[MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""]

KEEP
  HEADER ""REF_DATE"" AS ""Year""      # reporting year
  HEADER ""GEO""
  COLUMN 7 AS ""Crime Rate""

MATERIALIZE SUITCASE: . is governed by W002-WKO-008. WORK ORDER AS ""..."" is mandatory for an executable/saved WASM-002 Work Order and declares the immutable human-facing WKO alias governed by W002-STEPS-001.1. SOURCE ""..."" names the exact Suitcase-root source file. MAP ""..."" is optional with cardinality 0..1. If present, it occurs immediately after SOURCE and before KEEP , names one exact physical governed Store MAP filename, and binds the run to that exact current or historical Store lineage subject to W002-STOR-019.3 and W002-WKO-012.3. If absent, the Store-aware exact-source routing rules apply. KEEP is the bare governed keyword and introduces one or more column selectors. KEEP: is not valid WASM-002 syntax. Each selector is either HEADER ""..."" or COLUMN n and may optionally end with AS ""..."" . MATERIALIZE is the explicit terminal commitment verb. Duplicate structural clauses refuse. An empty KEEP refuses. After MATERIALIZE , only blank lines or comments may follow; a trailing comment on the physical MATERIALIZE line is permitted because comments are removed from the semantic token stream. # comments are governed by W002-STEPS-001.2. No RID/row-index clause appears in the Work Order. If this materialization establishes a new Store, the engine automatically generates exactly one RID artifact under W002-RID-002 and W002-RID-008. If it extends an existing Store, the existing RID is reused subject to the Store health/cardinality rules. This requirement freezes the bounded keyword structure and selector forms shown above for BM integration. Other complete-language lexical features remain outside this bounded syntax freeze unless separately specified. F-08 common-grammar boundary: MATERIALIZE is one of the seven executable WASM-002 operation grammars governed by W002-WKO-007. Its optional MAP clause remains in the frozen position immediately after SOURCE and before KEEP . The terminal MATERIALIZE clause is DS-STEPS syntax; the browser's Run action is not written into the Work Order. F-20 bounded KEEP: the canonical KEEP block contains at least one and at most 16,384 selectors, and after resolution those selectors must identify at least one and at most 16,384 distinct source columns. This is the complete WASM-002 selection-width bound.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001.1,WORK ORDER AS declares the immutable human-facing Work Order alias,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"An executable or saved WASM-002 Work Order must contain exactly one top-level clause: WORK ORDER AS ""<alias>"" In canonical forms it appears after SUITCASE: . and before the operation-specific source/selector clauses. The decoded alias must be non-empty. The quoted alias may contain spaces and ordinary UTF-8 phrase text subject to the governed string-literal rules. The alias affects display and governed alias resolution only; it does not replace the WKO filename/UUID as physical execution identity. The alias is stored in the immutable WKO bytes and is published into the current WKO MAP when the WKO save transaction commits. Changing the alias therefore requires saving a new WKO under the frozen WKO lifecycle. No valid executable/saved WKO in WASM-002 is unaliased. P3-10 alias-content rule: “non-empty” means that, after decoding the quoted string literal, the alias must contain at least one non-whitespace character. An alias consisting only of whitespace refuses Work Order validation. Data Sculptor must not trim, collapse, normalize, or otherwise rewrite leading or trailing whitespace in an otherwise valid alias; the decoded alias text remains authoritative and is preserved exactly in the immutable WKO and governed WKO MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001.2,# introduces a DS-STEPS line comment outside double-quoted strings,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"Outside a double-quoted string, the first # on a line begins a comment that continues through the line's LF terminator. Whole-line comments and trailing comments are permitted. Comment text has no execution semantics and is ignored by the DS-STEPS parser after lexical recognition. A # inside a double-quoted string is ordinary string content and does not begin a comment; for example WORK ORDER AS ""Analysis #3"" and HEADER ""CATEGORY #"" preserve the hash character. WASM-002 defines no block-comment syntax. Comments are preserved byte-for-byte in the saved immutable WKO TXT. Editing, adding, or removing a comment changes the WKO bytes and therefore requires saving a new WKO artifact even though analytical semantics may remain unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-002,HEADER selects by exact decoded source-header value,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"HEADER ""name"" resolves against the exact decoded header values established for the certified source. Header equality is exact Unicode scalar-value sequence equality under PB-STOR-010: Data Sculptor performs no case folding, locale folding, Unicode normalization, trimming, or filesystem-style comparison. A selector that matches no source header must refuse. If the same exact decoded header sequence occurs in more than one source column, the header selector is ambiguous and must refuse rather than choose by position, discovery order, normalization, case-insensitive similarity, or another heuristic. An analyst can disambiguate duplicate exact header text with the 1-based COLUMN n selector. F-20 selector identity: HEADER always matches the authoritative exact decoded source header. It never matches an operational fallback name such as Column AA , a generated collision-disambiguation suffix, a COL alias, or a truncated form of the source header.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-003,COLUMN selects by 1-based source ordinal,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"COLUMN n identifies the source column by 1-based ordinal position. COLUMN 1 is the first source column. Zero, negative values, non-integers, and ordinals greater than the source width must refuse. Ordinal selection does not suppress source metadata: Data Sculptor must still resolve and record the selected column's actual decoded source header in the successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-004,HEADER and COLUMN selectors may be mixed but may not select one source column twice,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"One KEEP block may contain any supported mixture of HEADER and COLUMN selectors. Selector order expresses the analyst's requested selection order for the governed operation. After resolution, two or more selectors that identify the same physical source column constitute a duplicate selection and must refuse before materialization. Data Sculptor must not materialize the same source column twice merely because it was named once by header and once by ordinal.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-005,AS assigns the resulting materialized-column alias,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The optional clause AS ""alias"" belongs to the immediately preceding HEADER or COLUMN selector and expresses an intentional human-facing alias assignment in the governed Work Order. For a logical source column not present in the inherited MAP, omission of AS uses the exact source header as the default alias. For a logical source column already present in the inherited MAP, omission of AS preserves the inherited alias. An explicit AS overrides either default for the successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-006,The complete successor MAP must contain unique aliases,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"After inheritance, selector resolution, default-alias application, rematerialization continuity, and all explicit AS clauses are applied, every alias in the complete successor MAP must identify exactly one logical materialized column. If two different logical columns would have the same alias, including a collision with an inherited mapping, validation must refuse unless the Work Order has explicitly resolved the conflict through supported governed syntax. Data Sculptor must not invent suffixes such as Year_2 , use last-write-wins behavior, or silently shadow an existing alias. F-20 narrow generated-name exception: the prohibition on invented suffixes applies to ordinary source-header defaults and analyst-authored aliases. The only automatic suffixing permitted in WASM-002 is deterministic disambiguation of an oversized-header operational fallback under W002-STOR-019.7. That mechanism is not an alias-repair heuristic and must not be applied to an explicit AS value or to a short exact source-header default.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-007,MATERIALIZE commits the resolved KEEP set to the governed structural pass,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"MATERIALIZE is the explicit commitment verb for this WASM-002 DS-STEPS form. The KEEP selectors express which source columns belong in the operation; they do not themselves authorize data-row materialization. Before the bounded structural pass begins, the source, all selectors, actual source ordinals/headers, requested aliases, inherited alias state, and resulting alias uniqueness must be resolved and validated. Successful multi-column execution then follows the one-pass materialization contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-008,The Store MAP records resolved truth rather than selector spelling,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The successor Store MAP must record the fully resolved materialization result using the frozen eight-column schema store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename , regardless of whether the analyst selected a column with HEADER or COLUMN . For example, COLUMN 7 AS ""Crime Rate"" records the Store alias, RID filename/alias, common source filename, source ordinal 7 , the actual decoded header found at column 7, alias Crime Rate , and the newly generated physical COL filename. DS-STEPS expresses intent; the Store MAP persists the resolved durable mapping truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-009,DS-STEPS materialization syntax acceptance,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"Acceptance must cover: one column selected by exact header; one column selected by 1-based ordinal; mixed header/ordinal selectors in one KEEP block; multiple columns materialized in one governed structural pass; AS alias assignment; default header aliasing; inherited-alias preservation on rematerialization; explicit alias replacement on rematerialization; duplicate-header ambiguity refusal; invalid ordinal refusal; duplicate resolved-column refusal; and duplicate successor-alias refusal. Acceptance must also prove that the generated successor MAP records the same resolved source filename, source ordinal, actual source header, resulting alias, and physical COL identity whether a column was selected by header or by ordinal. For a new Store, both the single-column and multi-column materialization fixtures must contain no RID/row-index instruction yet must automatically publish exactly one RID artifact. For a later permitted same-Store materialization, the fixture must likewise contain no RID instruction and must reuse the original RID without publishing another. Damaged-lineage Help acceptance: fixtures must prove that exact source routing to an INVALID Store, and to a DEGRADED Store whose every mapped COL is broken, refuses ordinary materialization without silently treating the source as unseen. The canonical diagnostic/Help evidence must identify the blocked lineage/current MAP and preserve the frozen analyst-owned exits: external restoration under the original governed physical filename followed by governed validation; source rename to begin a distinct new Store lineage; or moving all lineage MAPs out of the active Suitcase to retire that lineage from routing. The all-COLs-broken fixture must warn that moving only the latest MAP is insufficient. No fixture may imply a new Data Sculptor recovery command, automatic RID regeneration, silent replacement of the damaged lineage, or historical byte identity based only on a restored filename. P3-06 validation-tier acceptance: acceptance must prove that a routine routing/status or alias-only path can use Tier 1 without an end-to-end scan of every RID/COL value, while an operation that consumes artifact contents performs Tier 2 before relying on them. Fixtures must include: a RID that passes Tier 1 but fails Tier 2 because its declared N /sequence is internally wrong beyond the Tier-1 boundary; a COL that passes Tier 1 but fails Tier 2 because its data-record count or CSV body is invalid beyond the Tier-1 boundary; and a REPAIR MAP fixture proving that the Tier-2 failure set determines exactly which COL bindings are removed. P3-07 routing acceptance: fixtures must prove that routing discovers a lineage from a structurally valid Store MAP regardless of whether later Store-health evaluation is VALID , DEGRADED , or INVALID . A separate fixture must present no routable lineage together with at least one structurally malformed Store-MAP-class artifact in the active Suitcase and prove that ordinary materialization refuses before publishing a new RID or first Store MAP, while Help identifies the malformed MAP artifact or artifacts. No fixture may treat an all-MAPs-damaged condition as permission for a silent replacement lineage. F-08 cross-operation grammar acceptance: fixtures must prove the common preamble, ASCII-case-insensitive keywords, exact quoted-value preservation, required SPACE/TAB token separation, unknown-line refusal, one-operation-per-WKO refusal, and separation between DS-STEPS terminal phrases and Receipt OPERATION tokens. At least one fixture for each of the seven executable operations must prove that its canonical structure validates while an otherwise similar WKO containing another operation's terminal clause refuses. Separate fixtures must prove that browser Run does not require a textual RUN clause and that parsed RUN composition syntax refuses as deferred before analytical execution. P2-04 restoration-language acceptance: Help, diagnostics, UI text, and acceptance evidence may say that a file restored under the exact governed physical filename passed the required validation tier and may therefore re-enter use. They must not state or imply that filename equality alone proves restoration of the historical original bytes. If stronger historical-byte identity is desired, Help may point to the separately governed explicit fingerprint/LCK direction rather than silently hashing ordinary Store artifacts. F-20 selector/name/width acceptance: fixtures must additionally prove that HEADER resolves only against exact decoded source-header text and never against an operational fallback/default alias; a KEEP selecting all 16,384 columns is valid; a source wider than 16,384 refuses before data-row materialization; and RESET of an oversized-header COL restores the deterministic operational fallback rather than the exact oversized header as alias text. F-03 Store-health and REPAIR MAP acceptance set Target required: REPAIR MAP without exactly one current Store MAP target refuses. Historical target: a structurally valid but non-current historical Store MAP refuses for repair. Wrong profile: a WKO MAP supplied as the repair target refuses. DEGRADED repair: one or more broken COL bindings are removed while every valid binding and the exact RID identity are preserved. All COLs broken: repair refuses, publishes no successor MAP, and the Store remains DEGRADED . Malformed newest MAP: current-state resolution falls back to the greatest earlier structurally valid MAP in the same lineage and reports the malformed artifact. Missing COL in current valid MAP: no fallback occurs; the current MAP remains current and the Store evaluates DEGRADED . Missing RID in current valid MAP: no fallback occurs; the current MAP remains current and the Store evaluates INVALID . Original RID externally restored: the Store is re-evaluated after governed validation without Data Sculptor creating or inferring a replacement RID. No silent fork: neither DEGRADED nor INVALID permits ordinary materialization to create a replacement Store for the same routed lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-003,Suitcase-relative Work Order portability acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must execute a saved WKO containing SUITCASE: . and ordinary Suitcase-relative file references, then move the intact fixture Suitcase to a different permitted parent path and execute the same saved WKO again. Resolution must identify the same logical Suitcase files without editing the WKO to insert the new absolute machine path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-004,WIP/WKO lifecycle acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance evidence must show that an editable WIP cannot Run; saving a valid WIP produces a distinct immutable WKO Run target; loading that WKO and changing instruction text creates a new non-runnable WIP; and the original WKO bytes, filename, identity, and provenance remain unchanged. F-02 alias-registry lifecycle acceptance: a first save for an unused alias must publish a successor WKO MAP containing exactly one CURRENT row for that alias. Saving a second valid WKO with the same exact alias must surface exactly Replace alias target and Cancel . The Cancel fixture must leave the predecessor WKO MAP authoritative and must not commit the pending WKO/WKO-MAP pair as a registry update. The Replace fixture must publish a successor WKO MAP in which the former owner is DEPRECATED , the new WKO is the sole CURRENT row for that alias, and any earlier deprecated history remains preserved. The former WKO bytes and filename and every predecessor WKO MAP must remain unchanged. Alias resolution against the successor registry must resolve to the new CURRENT row and never to a DEPRECATED row. A malformed fixture containing more than one CURRENT row for one exact alias must fail structural validation rather than choose by filename UTC, modified time, discovery order, or row order. P2-03 WKO-registry clock acceptance: using a deterministic injected clock seam, acceptance must prove that a successor WKO MAP publishes only when the observed transaction UTC is strictly greater than the current structurally valid WKO MAP UTC; equal-millisecond and backward/future-dated-predecessor cases refuse without committing the new WKO/registry state. The diagnostic must expose predecessor_map_filename , predecessor_utc , and observed_host_utc . A separate fixture must deliberately move the future-dated current WKO MAP out of the active Suitcase, rescan, and prove deterministic reselection of the remaining current structurally valid WKO MAP without Data Sculptor silently moving or deleting anything itself. Day 060 H-12: every equal/backward/future-predecessor chronology refusal in this acceptance set must emit DS-UTC-001 with exact map_profile: WKO , observed_host_utc , predecessor_map_filename , and predecessor_utc facts. F-23 save-transaction filesystem-fault fixture, reconciled by F-33: using a controlled create/write/close/rename/promotion failure at a deterministic point after a valid WIP has entered the governed save path, acceptance must prove that a failed WKO/WKO-MAP save is never represented as a committed alias-registry update. The pre-run current WKO MAP must remain authoritative; no malformed or unpromoted candidate may become current; and any rollback or retained SCR evidence must follow W002-STOR-018.3 and the shared non-Store publication/retained-evidence contract. No RCV artifact is emitted. F-02 registry-repair acceptance set Deadlock escape: with a repair-required current WKO MAP, a newly saved structurally valid repair-only WKO can Run by exact filename and successfully publish a repaired successor registry. No broad bypass: a newly saved unregistered WKO for any other operation remains ineligible to Run. Missing reference: repair removes a stale registry row but does not recreate the missing WKO, substitute a historical WKO, or promote an older WKO automatically. Discovered alias, no owner: one discovered valid WKO with an otherwise unowned alias becomes CURRENT . Discovered alias collision: a discovered WKO whose alias is already owned by a surviving CURRENT row becomes DEPRECATED . Several discovered WKOs, no owner: all become DEPRECATED ; no winner is inferred by UTC, filename, UUID, directory order, discovery order, or modified time. Mandatory alias: an unaliased WKO cannot be structurally valid. Line endings: otherwise-identical structurally valid WKO fixtures with LF and CRLF line endings are accepted; the lone-CR form refuses. Deterministic successor: repaired successor rows serialize in ascending UTF-8 byte order of exact wko_filename . Historical Run: a registered DEPRECATED WKO can Run by exact physical filename but not by alias. Receipt identity: a successful or refused registry-repair Receipt uses REPAIR_WORK_ORDER_REGISTRY as the operation token. Day 060 H-10 / BM-07 registry-repair Receipt-count acceptance Acceptance must include a successful repair-required-registry fixture in which the exact repair-only bootstrap WKO is initially visible and unregistered, runs by the bounded exact-filename bootstrap, and is then registered by the repair result. The committed successor WKO MAP must contain the repair WKO row. The successful Receipt must list that exact repair WKO under either REGISTERED_CURRENT_WKO_<INDEX>_FILENAME or REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME , according to the ordinary alias-ownership rule. The corresponding REGISTERED_*_COUNT must equal the number of newly registered rows in that status class, including the repair WKO when applicable. Pre-existing surviving CURRENT / DEPRECATED rows in the base registry must not inflate either registered count. A fixture containing both pre-existing surviving rows and newly registered rows must prove that the Receipt reports the repair change set while the successor MAP reports the complete resulting registry state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-005,"Store MAP inheritance, historical override, and immutable snapshot acceptance",W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must execute a saved Store-establishing Work Order containing multiple COL alias assignments when no routable Store lineage exists and no structurally malformed Store-MAP-class artifact is present , and prove that exactly one new immutable complete Store MAP is created while the GUI supplies no alias-edit gesture and target artifacts remain unchanged. A later Work Order with the same exact source and no explicit MAP must route to that Store's lineage and inherit its unique newest permitted MAP automatically. Another Work Order must explicitly select an older valid MAP even though newer MAPs for that Store exist and prove that Store/RID binding, alias resolution, and inheritance use exactly the named historical MAP instead. A fixture specifying more than one MAP must refuse. A fixture with two otherwise permitted current MAP candidates for the selected Store sharing the greatest UTC millisecond timestamp must refuse automatic inheritance rather than use UUID as chronology. A separate fixture must remove or corrupt every Store MAP in a prior lineage so that no structurally valid Store MAP remains while at least one malformed Store-MAP-class artifact remains visible in the active Suitcase. Re-running ordinary materialization must refuse before creating a new RID or first Store MAP, and Help must identify the malformed MAP artifact or artifacts. P2-03 Store chronology acceptance: injected-clock fixtures must prove later observed UTC success, equal-millisecond refusal, backward-UTC refusal, and a genuinely future-dated current Store MAP that remains current while blocking successor publication. Every refusal must leave the chronology predecessor unchanged and publish no successor Store MAP. A historical-base fixture must derive requested state from an older eligible MAP while proving that the strict-greater-than comparison uses the actual current Store MAP as chronology predecessor, not the historical base. A deliberate analyst-removal fixture must move the future-dated current MAP out of the active Suitcase and prove deterministic reselection of the remaining structurally valid history; restoring that MAP must make ordinary greatest-UTC authority rules applicable again. Day 060 H-12: every equal/backward/future-predecessor Store-MAP chronology refusal in this acceptance set must emit DS-UTC-001 with exact map_profile: STORE , observed_host_utc , predecessor_map_filename , and predecessor_utc facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-006,Work Order chaining refusal acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must submit a structurally saved WKO containing a RUN or other recognized Work Order-invocation construct and prove that WASM-002 refuses it during validation before Stage 1, Stage 2, conversion, inventory, or other governed execution begins. The diagnostic/Help output must identify composition as deferred functionality. A separate multi-column MATERIALIZE fixture must still succeed, proving that multiple selected columns inside one Work Order are not misclassified as Work Order chaining.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-001,One explicit Work Order command surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser front end shall use the Work Order editor as the single human command-entry surface for governed execution. It shall not expose a second interactive command prompt or point-and-click analytical path that can become an independent source of analytical intent. The editable draft may be syntax-highlighted, validated, and saved, but it is not itself executable authority. The browser Run action operates only on one loaded/selected saved immutable WKO that is eligible under the governed Work Order registry rules. Run is a browser action, not a line that ordinary WASM-002 Work Orders must contain. If a WKO contains the reserved DS-STEPS RUN composition token, WASM-002 refuses before executing any child or top-level analytical operation because saved-Work-Order chaining is deferred. The token remains reserved so later ordered composition can be added without repurposing existing syntax. F-24 fresh-application state: each new Data Sculptor browser application instance begins without a selected Suitcase and without a restored unsaved Work Order draft. Initial page load and full reload therefore return the command surface to the pre-Suitcase gate. A previously selected folder, loaded WKO, or dirty WIP must not be silently reconstructed from browser-private persistence.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-002,Front end presents and authorizes; shared Rust core decides,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser front end may authorize files, edit and validate Work Orders, invoke the shared engine, display governed state, render diagnostics, and present generated artifacts. It must not independently decide analytical truth, silently reinterpret a Work Order, or implement a competing semantic path. Where front-end presentation and shared-core semantics disagree, the shared governed semantics and frozen requirements are authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-003,Visible Suitcase and governed run context,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser surface shall make the currently validated Suitcase visible and shall expose the visible files in that folder. Source and requested-column context become governed execution state only when a saved Work Order resolves them; the UI must not imply that directory presence alone means a source has been selected, scanned, certified, or materialized.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-004,Certification gate is visible and blocking,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The front end shall visibly represent strict whole-file UTF-8 certification as a required stage before analytical materialization. A certification refusal must stop the current analytical Work Order, prevent later materialization stages from being presented as successful, and provide the canonical diagnostic / Help path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-005,One-pass multi-column materialization is represented truthfully,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"When a valid Work Order requests multiple source columns, the front end shall represent them as one governed multi-column materialization request through one bounded structural CSV pass, not as unrelated per-column scans when the frozen engine contract performs one pass. Requested columns must be validated before data-row materialization begins, consistent with the materialization requirements.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-006,Visible Suitcase Directory is the artifact orientation surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"After Suitcase validation, the browser shall present a human-readable directory view of the visible files in the selected Suitcase, including physical filename, read-only governed alias where applicable, file type, and size. Governed artifacts created by a run shall appear in that same visible inventory after refresh or update. The directory is an orientation and metadata surface over the real flat Suitcase. It is not a hidden browser cache, a second persistence system, or an analytical command surface. CAT integration: this existing directory remains the sole WASM-002 artifact-orientation surface. CAT and MAP artifacts are first-ranked under W002-CAT-UI-001 through W002-CAT-UI-008; no second catalog browser is introduced.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-007,All user-facing Help flows through the Help Engine,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"All Data Sculptor-controlled user-facing Help messages, warnings, refusals, explanations, validation guidance, safe-next-action messages, and governed success/status messages that participate in the Help/status/evidence system shall be produced through the Help Engine from governed facts or canonical diagnostic events. Individual UI controls must not maintain an independent competing stock of semantic Help text. Governed success/status events in this system use canonical INFO diagnostics. Ordinary static labels, headings, decorative copy, and presentation-only UI text are not diagnostics and need not be routed through the diagnostic registry merely because they are visible. Help voice may change wording and depth but must not change diagnostic identity, evidence, severity, refusal/continue behavior, provenance, or safe next action. Durable Help Reports derive from the same governed truth. F-17 fallback behavior: when a complete registered diagnostic lacks an authored help_messages.json entry, the UI must show the deterministic Generic Technical Help rendering from W002-HELP-002.9 for Casual, Office Speak, and Technical selections rather than a blank state, guessed prose, or UI-local explanation. When diagnostic assembly itself fails its required-fact contract, the UI presents DS-HLP-001 ; it must not display the incomplete intended diagnostic as if valid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-008,Legacy encoding conversion remains a separate operation,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"If UTF-8 certification fails and the bytes are eligible for the separately governed Windows-1252 compatibility/conversion path, the front end may explain or help draft that separate conversion Work Order. It must not silently reinterpret the failed analytical Work Order as Windows-1252 and continue materialization. P3-08 front-end disclosure: after a successful conversion, the visible result/Help path must identify the exact published CVT filename and explain that it is a new source identity for later Store routing. When that CVT is subsequently chosen for first materialization, the front end must not present the action as a refresh of an earlier conversion-derived Store merely because the analyst-owned input filename is the same; it must preserve the governed Help disclosure that each distinct CVT is a distinct source artifact and lineage input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-009,Front-end branding is presentation-only,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser front end shall use the canonical built-in Red5Sorcery/Data Sculptor branding and approved presentation tokens without changing analytical or diagnostic meaning. The current Red5Sorcery identity treatment, including the red “5”, remains the active WASM-002 design direction. Configurable Brand Manifest loading, validation, selection, and substitution are deferred to V1-BACKLOG / a future build whose number is not yet assigned.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-010,WASM-002 front end must not preview deferred analytical features as available controls,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 front end shall stop at the capabilities allocated to the WASM-002 build slice. It shall not present filtering, grouping, sorting, Quick Viz, PRETTY Tables, DS-VERIFY, or later filter-driven build/export workflows as executable WASM-002 controls unless their individual requirement SCOPE is deliberately changed and frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PLAT-001,WASM-002/V1 browser and modest-hardware acceptance baseline,W002-PLAT,W002-PLAT,WASM-002,UNDER REVIEW,—,"The canonical modest-hardware acceptance machine for the WASM-002 browser release and the browser path carried into V1 is the project's 11-inch Windows 11 laptop with an Intel N100 processor, 16 GB RAM, and a 1920×1200 native display. Each acceptance record must capture the exact tested Windows build, browser version, Windows display scaling, browser zoom, and materially relevant machine configuration. Those observed version and presentation settings are acceptance evidence; they do not become timeless minimum-version requirements unless separately frozen. V1 browser support is scoped to certified desktop Chromium hosts that expose the user-selected writable-directory and file-publication capabilities required by the visible Suitcase contract. Microsoft Edge is the primary certified browser. Google Chrome is the secondary certified browser. Another Chromium-derived browser may work, but Data Sculptor must not claim it as a certified V1 browser until that browser has passed the applicable acceptance suite. Firefox and Safari are not supported V1 browser hosts under this contract and their lack of the required filesystem capability must not block V1 release. Supported-host acceptance must exercise the real browser filesystem path: explicit user-selected Suitcase access, CER validation, governed Work Order save/Run behavior, and governed artifact publication. Data Sculptor must not substitute OPFS, IndexedDB, download-only publication, a browser extension, or another hidden/different persistence model merely to make an unsupported browser appear supported. Required filesystem capability is feature-detected before folder validation begins. If the host cannot expose the governed writable-directory contract, Data Sculptor must treat that state as a host-capability refusal , keep governed save/Run/analytical controls locked, and route the explanation through the canonical diagnostic/Help path. It must not claim that a particular user folder failed validation when no folder could actually be tested.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-011,"Keyboard-operable, small-screen browser shell",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The required WASM-002 front-end interactions shall remain operable from a keyboard and usable on the canonical modest-hardware/small-screen baseline defined by W002-PLAT-001. At the display scaling and browser zoom recorded for acceptance, every required control and governed surface needed to complete the supported workflow must remain reachable without changing those settings merely to reveal an otherwise inaccessible control. Responsive reflow and ordinary scrolling are permitted; this requirement does not demand that every panel be visible simultaneously. Visible labels must carry meaning without relying on color alone. Exact shortcut assignments are presentation details unless separately frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-012,"Reference prototype is evidence, not a shadow specification",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Day 043 HTML prototype embedded below is retained as concrete design evidence for the WASM-002 browser workbench. Its layout, simulated analytical execution, illustrative Work Order grammar, current aliases, demo shortcuts, artifact examples, and other unfrozen literals do not become normative merely because they appear in the prototype. If the embedded prototype conflicts with a numbered requirement, the numbered requirement governs and the prototype must be revised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-013,Dedicated persistent Help / Diagnostic Surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The primary WASM-002 workspace must reserve a dedicated Help / Diagnostic Surface with stable layout presence. When a governed diagnostic is active, the analyst must be able to view its explanation without losing sight of the Work Order and the execution/source context required to understand it. The persistent surface is a viewport into canonical diagnostic truth; it is not a second state authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-014,Governed analytical refusals are not modal- or toast-only interactions,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,An application-controlled modal dialog must not be the primary presentation of a governed analytical refusal when it would obscure the Work Order or execution context. A transient toast or timed notification must not be the sole carrier of governed diagnostic truth. Browser- or operating-system-controlled permission/security dialogs are outside this requirement because Data Sculptor does not control their presentation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-015,Idle Help state remains semantically quiet,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"When no canonical diagnostic is active, the Help / Diagnostic Surface should communicate only restrained readiness/idle state rather than becoming a general dashboard for unrelated metrics, checkpoints, or project status. Exact wording such as “No active diagnostic. Ready.” is presentation detail unless separately frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-016,Help surface exposes a direct saved-report action,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"From an active governed diagnostic, including a non-run diagnostic, or from one governed Run whose diagnostic history is available to the Help surface, the browser Help / Diagnostic Surface must provide an explicit action to generate the durable HTML Help Report. Each explicit report request publishes exactly one HLP under W002-HELP-003.2 and W002-HELP-009. The generated report must become a visible Suitcase artifact governed by the Help, PRETTY, persistence, and provenance requirements and must use the canonical built-in Data Sculptor presentation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-017,Writable Suitcase validation is the first interaction gate,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Before Data Sculptor enables Work Order saving, governed Run, or analytical processing, the analyst must choose one Suitcase folder and Data Sculptor must validate that folder by successfully creating, completely writing, and closing one governed HTML Suitcase Validation Certificate under W002-STOR-022 through W002-STOR-022.3. Permission state or directory enumeration alone is not sufficient to pass the gate. The successful certificate remains visibly in the Suitcase as durable evidence. Validation does not require deleting or renaming the certificate. Until the certificate write/close succeeds, the analytical workspace remains locked except for Help and Suitcase selection. Browser- or operating-system-controlled refusal of protected directories is outside Data Sculptor presentation control and must be explained through the Help Engine when the host can observe the refusal. F-24 opening/selection lifecycle: merely loading Data Sculptor does not create a CER. A CER is published only after an explicit Suitcase selection successfully passes the governed validation gate. Reselecting and successfully validating the same physical Suitcase is a new certification event and publishes one new CER; all earlier CERs remain untouched. Data Sculptor does not remember the directory handle between application instances, so a new load/reload requires explicit Suitcase selection again before the workspace can unlock.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-018,Suitcase Directory enumerates visible files before analytical work,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Immediately after Suitcase validation, Data Sculptor shall enumerate the visible files available through the authorized directory handle and show them in the Suitcase Directory. No source, header, column, certification, or materialization state shall be inferred merely from the existence of those files.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-019,Directory inventory and displayed aliases must not become point-and-click analytical intent,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Suitcase Directory may expose file inventory and read-only human-facing metadata such as aliases, but it shall not provide alias-edit controls, “Use as source,” column-pick, materialize, filter, or equivalent governed-action controls. Source files, requested columns, alias mutations, and analytical operations are stated in saved Work Orders and resolved by the governed engine.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-020,Saved Work Orders are the only Run targets,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Work Order editor may create a new draft or load a saved Work Order TXT artifact from the validated Suitcase. A loaded saved Work Order is an immutable Run target and may be inspected or run directly. If the analyst changes its instruction text, the editor must transition to a new draft derived from that saved Work Order; the draft is not runnable until it is saved as a new immutable Work Order with a new governed physical identity. The original saved Work Order remains unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-021,User chooses the Suitcase; Data Sculptor chooses generated filenames,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"For Work Orders, materialized columns, Help Reports, receipts, maps, and other Data Sculptor-generated artifacts, the analyst chooses or has already chosen the validated Suitcase folder. The browser shall not require the analyst to supply an output filename for those governed artifacts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-022,"Execution Output is read-only observation, never command input",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser shall provide a read-only Execution Output surface that reports which saved Work Order was run, how its source and governed aliases resolved, which execution stages occurred, what was refused, and which governed artifacts were created or assigned. For WASM-002 it does not display a nested Work Order invocation chain because Work Order composition is deferred. The surface shall not accept commands, analytical text, or cursor-driven execution input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-023,The browser has no separate Work Order Description field,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser must not expose a standalone editable Description field for a saved or draft Work Order. Human-facing Work Order naming is authored in DS-STEPS with the required WORK ORDER AS ""..."" clause inside the Work Order itself. The Saved Work Order chooser and Suitcase Directory may display governed WKO alias/lifecycle information from the current structurally valid WKO MAP . Where lifecycle information is shown, CURRENT and DEPRECATED are read-only governed registry state, and the exact physical WKO filename must remain available/visible so human meaning, lifecycle authority, and physical identity remain distinct. Alias resolution uses the sole CURRENT row for the exact alias; a DEPRECATED row is historical evidence rather than the alias target. If that current registry references a missing physical WKO, the MAP remains current and the registry is repair-required; the browser must not silently display an older WKO MAP as though it had become current merely because of the missing reference. A structurally malformed newer WKO MAP never becomes current and is reported through Help/evidence surfaces. Editing a loaded saved WKO—including changing its alias or comments—creates a derived draft that must be saved as a new immutable WKO before it can Run. If that save would supersede the existing CURRENT target for the same alias, the save flow follows the exact Replace alias target / Cancel decision in W002-STOR-018.3; the UI must not provide a separate direct registry-edit gesture.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-024,Suitcase Directory aliases are read-only views of governed MAP profiles,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Alias displays in the Suitcase Directory are observation-only. Store, RID, and materialized-COL aliases are read from eligible Store MAP state. Saved Work Order alias and lifecycle state are read from the current structurally valid WKO MAP. The browser may aggregate those governed sources into one human-facing directory view while keeping exact physical filenames available for inspection. For WKO rows, CURRENT / DEPRECATED is read-only governed lifecycle metadata. A CURRENT row identifies the registry target for that exact alias; a DEPRECATED row remains historical registry evidence and must not be presented as the current alias target. The GUI must not expose an input, inline editor, context action, or other non-Work-Order path that directly mutates governed aliases or WKO lifecycle status. Store/RID/COL alias mutation remains Work-Order-governed. WKO aliases are authored inside immutable WKO text with WORK ORDER AS and enter or change WKO alias-registry authority only through a successful governed save transaction under W002-STOR-018.3.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-025,The browser has exactly two governed built-in presentation themes,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser presentation contract exposes exactly two governed theme choices: Modern Dark and Modern Light . Custom presentation is deferred to V1-BACKLOG / a future build not yet numbered. A Terminal theme is not part of the WASM-002/V1 browser contract and must not be exposed as a governed theme choice. Theme selection is presentation-only. It must not change Work Order semantics, source resolution, diagnostic identity or facts, continue/refuse decisions, analytical values, Receipt truth, or other governed execution meaning. The selected browser theme does not control durable HLP or CER presentation in WASM-002. Those governed HTML artifacts use the canonical built-in Red5Sorcery/Data Sculptor presentation regardless of whether the live browser is using Modern Dark or Modern Light. F-24 session default and persistence: Modern Dark is the canonical theme at the start of every new browser application instance. The analyst may switch to Modern Light during that instance, but WASM-002 retains the choice only in volatile runtime state and does not persist it in browser-private storage. A new application instance therefore returns to Modern Dark.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-026,Flight Recorder is a read-only derived Receipt-history surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser may present a Flight Recorder surface that is derived exclusively from governed RCP Receipt artifacts currently visible in the authorized Suitcase. The surface is read-only and regenerable. It must not create or maintain a second execution-history database, mutable log, hidden cache, browser-private history, or alternate chronology authority. The Flight Recorder may sort, filter, group, or summarize Receipt-derived facts for human orientation, but those presentation operations must not alter Receipt bytes, invent missing events, or become authoritative over the underlying immutable Receipts. Where no canonical Receipt exists because Receipt publication failed, the surface must not reconstruct a substitute original Receipt from UI state, console text, or memory.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-001,Single-command-surface and saved-run-target acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The acceptance check must show one Work Order editor that can hold either a new draft or a loaded saved Work Order and no second independent prompt, command-entry cursor, point-and-click source selector, or point-and-click column selector. A governed browser Run must read exactly one loaded/selected saved immutable WKO artifact that is eligible under the current registry rules. An unsaved WIP must not Run. Editing the instruction text of a loaded saved WKO must transition the editor to a new draft state that cannot Run until saved as a new immutable WKO. A fixture containing the exact reserved semantic token RUN as a Work Order composition construct must refuse before any governed operation executes and must reach the deferred-composition Help path. A near-synonym such as CALL , EXEC , or INCLUDE must not be silently accepted as composition syntax.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-002,Certification-refusal gating acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a source fixture that fails strict UTF-8 certification, the browser must show certification failure, leave later analytical stages unaccepted, produce no materialized analytical outputs, preserve the source unchanged, and expose the canonical Help path. The retained event/Receipt evidence must agree on STAGE1_UTF8_OUTCOME: FAIL , exact UTF8_FIRST_INVALID_BYTE_OFFSET , and UTF8_STOP_REASON: INVALID_UTF8_SEQUENCE . The canonical diagnostic event must expose the same meaning through lower-case facts first_invalid_byte_offset , source_filename , and stop_reason .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-003,Multi-column path acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a valid UTF-8 source and a Work Order requesting at least two source columns, the browser must show successful certification followed by one governed structural materialization pass and then expose the resulting visible Suitcase artifacts required by the build contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-004,Diagnostic/Help parity acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"For at least one real WASM-002 refusal path, the live message, each supported Help voice, and the durable HTML Help report must resolve from the same canonical diagnostic event and preserve the governed facts, severity, provenance, refusal behavior, and safe next action.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-005,Visible-persistence and Suitcase-directory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"A completed governed browser run must be auditable from the visible Suitcase artifacts required by the build contract, and newly created governed artifacts must become visible through the Suitcase Directory. Acceptance evidence must show that Data Sculptor did not intentionally persist project or analytical state in browser-private storage as a substitute for those artifacts. F-24 session/CER lifecycle acceptance: acceptance must begin from a clean application instance and prove all of the following in one controlled sequence: no Suitcase is selected or silently recovered; Work Order saving and governed Run remain gated; the live browser defaults to Modern Dark and Technical Help; explicitly selecting and successfully validating a writable Suitcase publishes exactly one fresh CER and unlocks the workspace; after switching to Modern Light and a non-Technical Help voice and creating a dirty unsaved WIP, an ordinary reload/navigation path triggers the browser-supported unsaved-change warning where the host permits it; after proceeding with reload, the Suitcase handle, non-default theme, non-default Help voice, and dirty WIP are not restored from Data Sculptor-controlled browser-private persistence; reselecting and successfully validating the same Suitcase publishes a second distinct CER while the first CER remains present under its original governed filename and exact bytes; and no automatic CER-history ZIP, compaction, replacement, or deletion occurs. The acceptance record must inspect the relevant Data Sculptor-controlled browser persistence surfaces and show that no persisted project/session record was used to restore the Suitcase handle, WIP, theme, or Help voice. WASM-002 does not claim dirty-draft warning or recovery after browser crash, forced process termination, operating-system failure, or power loss.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-006,Scope-surface acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The frozen WASM-002 browser build must not expose executable controls for requirements whose current SCOPE remains V1-BACKLOG, POST-V1, OUT-WASM-002, or otherwise outside the frozen WASM-002 build slice.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-007,"Small-screen, keyboard, and certified-browser acceptance",W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"On the canonical Intel N100 / 16 GB Windows 11 laptop and its 1920×1200 display, acceptance must record the Windows build, display scaling, browser zoom, and exact browser version. In the primary certified Microsoft Edge host, the required browser controls, Work Order editor, governed-stage status, artifact/result surface, and diagnostic/Help surface must remain reachable and usable without requiring an IDE or developer tools, and the required interaction path must be completable by keyboard. Ordinary scrolling and responsive reflow are allowed; changing scaling or zoom merely to expose an otherwise unreachable required control is not. The same canonical machine must also exercise the supported-host Suitcase → CER → Work Order save/Run → governed publication path in the secondary certified Google Chrome host. Chrome must satisfy the same governed filesystem and semantic contract; browser-specific presentation differences do not permit different analytical meaning or a different persistence model.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-008,Persistent diagnostic co-presence acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,Triggering a real governed refusal must leave the Work Order and relevant execution/source context available while the diagnostic is visible in the dedicated Help surface. The refusal must not depend on an application-controlled modal dialog or transient toast as its sole presentation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-009,Idle-state discipline acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"With no active diagnostic, the dedicated Help surface must remain present but semantically quiet and must not aggregate unrelated project/dashboard state as a substitute for its diagnostic purpose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-010,Saved-report action acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"From a displayed real diagnostic event, including a governed non-run diagnostic, the user must be able to invoke the Help-report action and obtain the corresponding durable HTML Help Report as one visible governed artifact without manually copying diagnostic text or reconstructing the event. A governed Run fixture containing multiple diagnostic events must also permit one explicit Run-level Help Report request and must produce exactly one HLP for that request. The HLP must identify the included diagnostics in deterministic event order and must not create one HLP automatically for each diagnostic.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-011,Suitcase-first gate and supported-host capability acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"With no Suitcase validated, Work Order saving, governed Run, and analytical processing controls must be unavailable. Acceptance first proves supported-host capability under W002-PLAT-001. Microsoft Edge and Google Chrome acceptance must each expose the required user-selected writable-directory path; Data Sculptor must not satisfy this gate through OPFS, IndexedDB, download-only output, a browser extension, or another substitute persistence model. Acceptance must enumerate every governed final-artifact filename form and SCR staging form that WASM-002 can emit, derive the longest canonical filename length, and verify that the current contract yields 73 ASCII bytes/characters . The canonical __DS__CER__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html form is one of the forms at that maximum and is used for the actual create/write/close folder-validation test. After the analyst selects a writable test folder on a supported host, Data Sculptor must create one retained governed certificate whose filename matches that canonical CER form, completely write and close it, and expose it in the visible Suitcase Directory. The certificate must contain the semantic fields and limitation statements required by W002-STOR-022.2. Only after that certificate operation succeeds may the workspace unlock. A failure to create, completely write, or close the certificate after actual folder selection must leave the workspace locked and surface the canonical diagnostic/Help path. Separately, a deterministic missing-capability acceptance fixture must prove that a host lacking the required writable-directory contract refuses before folder validation, leaves the workspace locked, and does not mislabel an untested folder as unwritable. Acceptance must not depend on a hard-coded operating-system path-length number, deletion of the certificate, or a validation-only rename. If the emitted-name inventory changes so that another form exceeds the CER maximum, this acceptance gate must fail until the new maximum is explicitly exercised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-012,Directory-is-inventory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"After Suitcase validation, the visible directory must list a mixed fixture set including at least one CSV and one non-CSV file with their physical names, types, and sizes. The directory must expose no “Use as source,” column-pick, or materialize action that bypasses the Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-013,Generated Work Order identity and immutability acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,Saving a valid draft must create a new TXT artifact whose physical name matches the frozen Work Order filename contract and must not open a filename-entry Save As path. Editing the draft and saving again must create a different Work Order identity; the first saved TXT bytes and filename must remain unchanged.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-014,Work-Order-only source and column selection acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a Suitcase containing multiple candidate files and a CSV with multiple headers, the analyst must be able to request the source and materialized column solely through a saved Work Order. Acceptance must show that the browser performs no separate point-and-click source or column selection. F-26 SOURCE eligibility fixtures: the acceptance set must prove all of the following under W002-WKO-009.1: analyst-owned root files ending .csv , .CSV , and a mixed-case equivalent are recognized as CSV candidates; the complete physical filename reference remains exact and case-sensitive under F-15; an analyst-created __DS__notes.csv is refused as an analyst-owned SOURCE; a valid published CVT is accepted; a canonical-looking or renamed file that does not satisfy the governed CVT validity/publication contract is refused; governed non-CVT classes including COL are refused as SOURCE; a non-CSV analyst-owned extension is refused even if its bytes are CSV-like; and path, traversal, subdirectory, URL/URI, and external-file references are refused.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-015,Read-only Execution Output acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The execution surface must display the selected saved Work Order, source resolution, relevant stage/refusal facts, and resulting artifact identity while accepting no command input. Keyboard focus in the execution surface must not create a second execution path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-016,Store-MAP snapshot persistence and read-only directory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Creating or changing governed alias/Store metadata through a saved Work Order must create one new immutable complete Store MAP in the same flat Suitcase while preserving earlier MAPs and leaving target artifact bytes and physical filenames unchanged. After a governed run that creates a new Store MAP, refreshing/reopening the Suitcase may display Store, RID, and COL aliases from the exact Store lineage and Store MAP resolved for that specific governed operation. The directory must not infer a global “current Store,” guess from unrelated newest MAP timestamps, or independently choose or mutate Store/MAP authority for execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-017,"Store-aware MAP selection, historical override, and anti-rebinding acceptance",W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"A saved materializing Work Order that does not explicitly name a MAP must use exact SOURCE matching against the one common source_filename carried by each routable Store lineage's Store MAP. A routable Store lineage is one with at least one structurally valid Store MAP, regardless of later Store-health state. A fixture with exactly one routable Store lineage must route to that lineage and, when its health permits materialization, inherit the Store's unique newest permitted MAP and record both the MAP identity and bound rid_filename in execution evidence. A fixture with no routable Store lineage and no structurally malformed Store-MAP-class artifact present may establish a new Store. A fixture with more than one routable Store lineage for the same source must refuse automatic selection. An explicit-MAP fixture must prove that SOURCE must exactly equal the selected MAP's common source_filename . A different source must refuse before materialization even when source/RID row counts happen to match. A separate all-MAPs-damaged fixture must leave one or more structurally malformed Store-MAP-class artifacts visible while no routable lineage can be established. The UI/run path must refuse before new-Store/RID creation and expose Help that identifies the malformed MAP artifact or artifacts; it must not present the condition as an unseen source. Another fixture must prove that explicitly naming an older valid MAP overrides the newer default for that same Store. More than one explicitly named MAP must refuse. An equal-greatest-timestamp ambiguity within the selected Store lineage must refuse automatic selection. Once an inherited Store MAP has been selected for a run, creation of a newer MAP during execution must not silently rebind that in-progress run. P2-03 authority/clock acceptance: the UI/evidence path must distinguish the selected operation base MAP from the chronology predecessor used for successor UTC validation. When a future-dated current MAP blocks publication, the UI must not label that MAP corrupt merely because of its timestamp, must identify it as the blocking current authority, and must route to Help describing the clock correction/wait/deliberate-removal choices without performing any automatic fallback or filesystem move.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-018,Help-Engine-only messaging acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"For representative Suitcase validation, Work Order validation, source-resolution, and analytical refusal cases, user-facing guidance must be traceable to the Help Engine/canonical diagnostic path. Acceptance must show no competing ad hoc semantic refusal text generated independently by individual analytical controls.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-019,No standalone Work Order Description acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Acceptance must prove the architecture that WASM-002 permits: the browser exposes no standalone editable Work Order Description field; no separate mutable or hidden Work Order-description store exists; editing any governed WKO byte transitions a loaded saved WKO into a derived draft; the predecessor WKO TXT bytes, physical filename, and UUID remain unchanged; and the derived draft cannot Run until saved as a new WKO identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-020,Theme semantic-invariance acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The same saved Work Order and governed diagnostic fixture must be exercised under Modern Dark and Modern Light. Acceptance evidence must show identical Work Order resolution, diagnostic ID and structured facts, continue/refuse decision, and analytical result/provenance across both themes, with only governed live-browser presentation differences. The browser must expose no Custom or Terminal governed theme choice in WASM-002. Acceptance must also verify that switching between Modern Dark and Modern Light does not change the canonical built-in presentation of a generated HLP or CER.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-021,Flight Recorder read-only derivation acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Acceptance must populate the Suitcase with governed RCP artifacts for at least one successful Run and one refused Run whose Receipt publication succeeded, then reconstruct the Flight Recorder surface solely from those Receipts. The rendered history must preserve each Receipt's governed execution outcome and lineage while allowing only read-only presentation operations. A separate fixture must represent a Run for which Receipt publication failed under W002-RCP-010 and prove that the Flight Recorder does not invent, backfill, or reconstruct a canonical Receipt from transient execution state. User interaction with the Flight Recorder must not modify, delete, rename, rewrite, supersede, or create RCP artifacts and must not create hidden persistent history state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-001,Certification interprets nothing analytically,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The certification stage establishes source-encoding validity and evidence; it does not perform analytical materialization.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-002,Materialization assumes nothing about encoding,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,Materialization proceeds only under the governed UTF-8-certified-source invariant and does not guess or silently change source encoding.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-003,Conversion is a separate transformation,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"Windows-1252-to-UTF-8 conversion is an explicit user-authorized operation producing a new artifact, not a hidden fallback.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-004,The fast path preserves strictness,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"ASCII-first acceleration is an optimization of strict UTF-8 certification, not a relaxation of validity rules. Every non-ASCII sequence remains subject to strict validation and EOF remains authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-005,Help is first-class,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The shared engine emits governed diagnostic truth; the Help Engine owns governed explanation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-006,PRETTY is first-class,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The PRETTY Engine owns deterministic human-facing rendering.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-008,One shared semantic core,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The WASM-first implementation must remain suitable for later use by a standalone native CLI host without creating a permanent second semantic engine.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-011,Open source and commercial service are separate layers,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The open-source analytical product and Red5Sorcery's optional paid automation must remain architecturally distinguishable. A paid service may save work; it must not become a hidden prerequisite for executing or understanding the delivered analytical software.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-014,WASM-002 and V1 analytical execution are sequential,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"WASM-002 must execute governed analytical operations sequentially and predictably. The product must not expose worker-count, thread-count, task-parallelism, or similar tuning controls, and it must not silently introduce a parallel analytical execution mode whose ordering or resource use changes the governed semantics. Sequential execution does not require inefficient repeated scans. One bounded structural source pass may process multiple requested columns together, and implementation may use ordinary low-level/runtime mechanisms that do not create user-visible analytical concurrency or change deterministic operation order. Any future analytical parallelism requires a separate measured experiment and explicit PRD decision.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-014.1,WASM-002 has a single-writer Suitcase contract,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"WASM-002 assumes one user, one active Suitcase, and one Data Sculptor writing execution context at a time . Multiple read-only views may observe the same Suitcase, but concurrent governed writers—including a second browser tab or window attempting governed writes against the same Suitcase—are outside the supported WASM-002 contract. WASM-002 does not implement cross-tab locks, filesystem leases, lockfiles, hidden coordination state, or multi-writer merge/rebase semantics. This is an explicit product boundary, not an implicit guarantee that concurrent writers are safe. Before a governed transaction reaches its authoritative commit point, Data Sculptor must re-resolve and revalidate the governing state on which the transaction depends. If relevant governed state has changed since the transaction established its basis, publication must refuse rather than overwrite the newer authority, silently rebase itself, synthesize another chronology, or report success. Candidates already created remain subject to the existing rollback and attributable SCR recovery-evidence rules. Help must explain the boundary in ordinary terms: do not run two writing Data Sculptor contexts against the same Suitcase at the same time. If a pre-commit guard detects changed authority, the safe next action is to refresh or reopen the current governed state and rerun deliberately. Acceptance evidence must inject a relevant Store-MAP and WKO-MAP authority change after transaction preparation but before commit and prove that the newer authority remains authoritative and the stale transaction refuses.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)

project_day,date,day_kind,cumulative_touched,cumulative_checkpoints,cumulative_requirement_accepted,evidence
63,2026-10-10,BUILD,2,0,0,Day063 log and CP001 evidence; initial ledger scope
64,2026-10-11,BUILD,2,0,0,Day064 Workbench BUILD prototype entry; no new IDs credited
65,2026-10-12,BUILD,9,7,0,Day065 CP007 frozen-scope ledger and banked checkpoint evidence
66,2026-10-13,BUILD,12,13,0,"Day066 CP008: git 346733a962192320e0d56271add15a47b6037b6b; 28 native tests; wasm32 build; 20/20 SHA-256; human accepted; requirement partial; CP009: git dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8; 36 native tests; wasm32 build; 22/22 SHA-256; human accepted; existing requirements deepened, no new IDs; CP010: git b7c515faa9bd000369d7656e09437310261290ae; 40/40 native tests; Rust 1.97.1 wasm32 build; primary 29/29 and supplementary 8/8 SHA-256; staged whitespace PASS with 3 limited evidence-only attribute exceptions; T-approved; first lexical touch W002-CONV-004 only; no SOURCE authority; CP011: git e84ae5baeee05f9d5d30284c65b86eebba3c0f6a; 6 RED/GREEN tests, 46/46 native tests; Rust 1.97.1 canonical wasm32 --lib PASS; Rustfmt PASS after correction; 36/36 recorded SHA-256/size checks; two scoped TXT whitespace exceptions; 27 files committed; T accepted; first-touch W002-STOR-023.1 and deepen W002-CONV-004 only; no SCR publication or SOURCE authority; CP012: git efca04392940e398020a5c06b9ee50296c8a1fdd; six new targeted tests, initial GREEN 5/6 failure with trailing-whitespace validation gap preserved, CP012-local correction, corrected GREEN 6/6 and full native 52/52; Rust 1.97.1 wasm32 --lib PASS; final rustfmt PASS; 29/29 initial + 4/4 supplementary SHA256/size inputs verified with an independently verified six-record post-staging hash amendment for scoped Git attributes; 28 committed files; T-approved; deepens existing PARTIAL W002-STOR-023.1 only, +0 first-touched IDs; Day066 OPEN; CP013: git 005a38ef5e876847c4c08901c18da9c18565fd6b (parent efca04392940e398020a5c06b9ee50296c8a1fdd); explicit SCR-to-RCP final filename candidate only; six RED/GREEN target tests; native 58/58 PASS; Rust 1.97.1 rustfmt and canonical wasm32 --lib build PASS; primary 21/21, supplementary 27/27 historical, post-normalization 32/32, closing 37/37, final commit 42/42 blob identity; Git CRLF whitespace and byte-preservation remediation tracked, full staged whitespace PASS; T-approved, 42 files banked, clean tree; deepens existing PARTIAL W002-STOR-023.1, W002-STOR-023 NOT_STARTED, +0 newly touched IDs; Day066 OPEN"
67,2026-10-14,BUILD,13,14,0,Day067 CP014: T-approved/Git banked f5038a183f1d3dc31b0065571bf8ac8814b5d8a9; RCP-002 lexical portion first touched; 6/6 targeted GREEN; 64/64 native; wasm32 lib build; 32/32 ZIP blobs; browser and independent QA pending; Day067 OPEN

CommitSHA,ParentSHA,CommitTime,Subject,ChangedFiles,GrossBytes,GrossKiB,NetBytes,EvidenceBytes,SourceBytes,TestBytes,OtherBytes
6b373ff782b97b751d63d44449320f72d05ba339,,2026-10-10T14:49:59-03:00,WASM-002: establish verified Rust 1.97.1 baseline,5,560,0.547,560,0,210,0,350
01580a1873cc51a675a2c2b560d2500cf5cf909f,6b373ff782b97b751d63d44449320f72d05ba339,2026-10-10T14:53:13-03:00,WASM-002: establish cross-platform line-ending policy,1,108,0.105,108,0,0,0,108
03201870b8ec68730a0c027c572db03ccd5eeaa8,01580a1873cc51a675a2c2b560d2500cf5cf909f,2026-10-10T15:27:19-03:00,WASM-002 CP-001: locally verified namespace recognizer candidate,10,19130,18.682,18920,6070,937,2006,10117
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,03201870b8ec68730a0c027c572db03ccd5eeaa8,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,22,37817,36.931,34874,33986,1175,2656,0
2d06f6259de93f5beaa8eb15f8f22f171127a10e,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T19:56:23-03:00,WASM-002 CP-003: classify governed artifact tokens,14,19801,19.337,18626,15481,2486,1834,0
12c02a0f2ff51fae72599adc09332f50fed62ce8,2d06f6259de93f5beaa8eb15f8f22f171127a10e,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,15,28321,27.657,25835,22349,4071,1901,0
cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:53:56-03:00,WASM-002 CP-005: validate Gregorian UTC timestamps,14,30466,29.752,26395,23272,5176,2018,0
aff54d08dcbacaa0c54d8869749344a504c5ad61,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,2026-10-12T21:20:03-03:00,WASM-002 CP-006: separate artifact class and serialization,14,31929,31.181,26753,22784,6143,3002,0
3c512df519f3a2431b363e4c57dc234c02378124,aff54d08dcbacaa0c54d8869749344a504c5ad61,2026-10-12T21:52:18-03:00,WASM-002 CP-007: construct canonical filenames without normalization,14,33565,32.778,27422,23864,6829,2872,0
346733a962192320e0d56271add15a47b6037b6b,3c512df519f3a2431b363e4c57dc234c02378124,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,18,33903,33.108,27074,23931,7783,2189,0
dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,346733a962192320e0d56271add15a47b6037b6b,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,15,35276,34.449,27493,20794,10093,4389,0
b7c515faa9bd000369d7656e09437310261290ae,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,28,75600,73.828,65507,62839,10589,2172,0
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,27,59139,57.753,48550,45802,11016,2321,0
efca04392940e398020a5c06b9ee50296c8a1fdd,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,28,66103,64.554,55087,52586,11541,1976,0
005a38ef5e876847c4c08901c18da9c18565fd6b,efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,42,302051,294.972,290510,287012,12312,2727,0
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-14,CP014: recognize canonical RCP filename candidates,34,54170,52.900,41858,38599,12915,2656,0

CommitSHA,CommitTime,Subject,Status,Category,OldPath,Path,BeforeBytes,AfterBytes,GrossBytes,NetBytes
6b373ff782b97b751d63d44449320f72d05ba339,2026-10-10T14:49:59-03:00,WASM-002: establish verified Rust 1.97.1 baseline,A,Other,.gitignore,.gitignore,0,8,8,8
6b373ff782b97b751d63d44449320f72d05ba339,2026-10-10T14:49:59-03:00,WASM-002: establish verified Rust 1.97.1 baseline,A,Other,Cargo.lock,Cargo.lock,0,162,162,162
6b373ff782b97b751d63d44449320f72d05ba339,2026-10-10T14:49:59-03:00,WASM-002: establish verified Rust 1.97.1 baseline,A,Other,Cargo.toml,Cargo.toml,0,89,89,89
6b373ff782b97b751d63d44449320f72d05ba339,2026-10-10T14:49:59-03:00,WASM-002: establish verified Rust 1.97.1 baseline,A,Other,rust-toolchain.toml,rust-toolchain.toml,0,91,91,91
6b373ff782b97b751d63d44449320f72d05ba339,2026-10-10T14:49:59-03:00,WASM-002: establish verified Rust 1.97.1 baseline,A,Source,src/lib.rs,src/lib.rs,0,210,210,210
01580a1873cc51a675a2c2b560d2500cf5cf909f,2026-10-10T14:53:13-03:00,WASM-002: establish cross-platform line-ending policy,A,Other,.gitattributes,.gitattributes,0,108,108,108
03201870b8ec68730a0c027c572db03ccd5eeaa8,2026-10-10T15:27:19-03:00,WASM-002 CP-001: locally verified namespace recognizer candidate,A,Other,DataSculptor_WASM002_Development_Log.html,DataSculptor_WASM002_Development_Log.html,0,10117,10117,10117
03201870b8ec68730a0c027c572db03ccd5eeaa8,2026-10-10T15:27:19-03:00,WASM-002 CP-001: locally verified namespace recognizer candidate,A,Evidence,Evidence/CP-001/CP001_GREEN2_Test_Output.txt,Evidence/CP-001/CP001_GREEN2_Test_Output.txt,0,1188,1188,1188
03201870b8ec68730a0c027c572db03ccd5eeaa8,2026-10-10T15:27:19-03:00,WASM-002 CP-001: locally verified namespace recognizer candidate,A,Evidence,Evidence/CP-001/CP001_GREEN_Test_Output.txt,Evidence/CP-001/CP001_GREEN_Test_Output.txt,0,965,965,965
03201870b8ec68730a0c027c572db03ccd5eeaa8,2026-10-10T15:27:19-03:00,WASM-002 CP-001: locally verified namespace recognizer candidate,A,Evidence,Evidence/CP-001/CP001_Hash_Inventory.txt,Evidence/CP-001/CP001_Hash_Inventory.txt,0,984,984,984
03201870b8ec68730a0c027c572db03ccd5eeaa8,2026-10-10T15:27:19-03:00,WASM-002 CP-001: locally verified namespace recognizer candidate,A,Evidence,Evidence/CP-001/CP001_Hash_Inventory_Verification.txt,Evidence/CP-001/CP001_Hash_Inventory_Verification.txt,0,422,422,422
03201870b8ec68730a0c027c572db03ccd5eeaa8,2026-10-10T15:27:19-03:00,WASM-002 CP-001: locally verified namespace recognizer candidate,A,Evidence,Evidence/CP-001/CP001_RED2_Test_Output.txt,Evidence/CP-001/CP001_RED2_Test_Output.txt,0,1530,1530,1530
03201870b8ec68730a0c027c572db03ccd5eeaa8,2026-10-10T15:27:19-03:00,WASM-002 CP-001: locally verified namespace recognizer candidate,A,Evidence,Evidence/CP-001/CP001_RED_Test_Output.txt,Evidence/CP-001/CP001_RED_Test_Output.txt,0,592,592,592
03201870b8ec68730a0c027c572db03ccd5eeaa8,2026-10-10T15:27:19-03:00,WASM-002 CP-001: locally verified namespace recognizer candidate,A,Evidence,Evidence/CP-001/CP001_WASM_Build_Output.txt,Evidence/CP-001/CP001_WASM_Build_Output.txt,0,389,389,389
03201870b8ec68730a0c027c572db03ccd5eeaa8,2026-10-10T15:27:19-03:00,WASM-002 CP-001: locally verified namespace recognizer candidate,M,Source,src/lib.rs,src/lib.rs,210,937,937,727
03201870b8ec68730a0c027c572db03ccd5eeaa8,2026-10-10T15:27:19-03:00,WASM-002 CP-001: locally verified namespace recognizer candidate,A,Tests,tests/artifact_namespace.rs,tests/artifact_namespace.rs,0,2006,2006,2006
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_Baseline_Cargo_Test_Output.txt,Evidence/CP-002/CP002_Baseline_Cargo_Test_Output.txt,0,2228,2228,2228
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_Day065_Repository_Inventory.txt,Evidence/CP-002/CP002_Day065_Repository_Inventory.txt,0,3152,3152,3152
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_Day065_Source_And_Tests_Baseline.txt,Evidence/CP-002/CP002_Day065_Source_And_Tests_Baseline.txt,0,6050,6050,6050
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_Day065_Starting_State.txt,Evidence/CP-002/CP002_Day065_Starting_State.txt,0,1560,1560,1560
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_Evidence_Organization.txt,Evidence/CP-002/CP002_Evidence_Organization.txt,0,387,387,387
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_Format_Output.txt,Evidence/CP-002/CP002_Format_Output.txt,0,214,214,214
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_Format_Retry_Output.txt,Evidence/CP-002/CP002_Format_Retry_Output.txt,0,26,26,26
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_GREEN_Source_Change.txt,Evidence/CP-002/CP002_GREEN_Source_Change.txt,0,513,513,513
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_GREEN_Test_Output.txt,Evidence/CP-002/CP002_GREEN_Test_Output.txt,0,936,936,936
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_Hash_Inventory.txt,Evidence/CP-002/CP002_Hash_Inventory.txt,0,2522,2522,2522
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_Hash_Inventory_Verification.txt,Evidence/CP-002/CP002_Hash_Inventory_Verification.txt,0,1158,1158,1158
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_Post_Format_Diff_Review.txt,Evidence/CP-002/CP002_Post_Format_Diff_Review.txt,0,6760,6760,6760
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_Post_Format_Test_Output.txt,Evidence/CP-002/CP002_Post_Format_Test_Output.txt,0,936,936,936
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_Post_Format_WASM_Build_Output.txt,Evidence/CP-002/CP002_Post_Format_WASM_Build_Output.txt,0,102,102,102
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_Precommit_Git_Review.txt,Evidence/CP-002/CP002_Precommit_Git_Review.txt,0,4315,4315,4315
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_RED_Test_Change.txt,Evidence/CP-002/CP002_RED_Test_Change.txt,0,2010,2010,2010
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_RED_Test_Output.txt,Evidence/CP-002/CP002_RED_Test_Output.txt,0,626,626,626
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_Rustfmt_Install_Output.txt,Evidence/CP-002/CP002_Rustfmt_Install_Output.txt,0,70,70,70
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_Verification_Completion.txt,Evidence/CP-002/CP002_Verification_Completion.txt,0,232,232,232
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,A,Evidence,Evidence/CP-002/CP002_WASM_Build_Output.txt,Evidence/CP-002/CP002_WASM_Build_Output.txt,0,189,189,189
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,M,Source,src/lib.rs,src/lib.rs,937,1175,1175,238
206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,M,Tests,tests/artifact_namespace.rs,tests/artifact_namespace.rs,2006,2656,2656,650
2d06f6259de93f5beaa8eb15f8f22f171127a10e,2026-10-12T19:56:23-03:00,WASM-002 CP-003: classify governed artifact tokens,A,Evidence,Evidence/CP-003/CP003_Format_Output.txt,Evidence/CP-003/CP003_Format_Output.txt,0,26,26,26
2d06f6259de93f5beaa8eb15f8f22f171127a10e,2026-10-12T19:56:23-03:00,WASM-002 CP-003: classify governed artifact tokens,A,Evidence,Evidence/CP-003/CP003_GREEN_Source_Change.txt,Evidence/CP-003/CP003_GREEN_Source_Change.txt,0,1626,1626,1626
2d06f6259de93f5beaa8eb15f8f22f171127a10e,2026-10-12T19:56:23-03:00,WASM-002 CP-003: classify governed artifact tokens,A,Evidence,Evidence/CP-003/CP003_GREEN_Test_Output.txt,Evidence/CP-003/CP003_GREEN_Test_Output.txt,0,1368,1368,1368
2d06f6259de93f5beaa8eb15f8f22f171127a10e,2026-10-12T19:56:23-03:00,WASM-002 CP-003: classify governed artifact tokens,A,Evidence,Evidence/CP-003/CP003_Hash_Inventory.txt,Evidence/CP-003/CP003_Hash_Inventory.txt,0,1749,1749,1749
2d06f6259de93f5beaa8eb15f8f22f171127a10e,2026-10-12T19:56:23-03:00,WASM-002 CP-003: classify governed artifact tokens,A,Evidence,Evidence/CP-003/CP003_Hash_Inventory_Verification.txt,Evidence/CP-003/CP003_Hash_Inventory_Verification.txt,0,790,790,790
2d06f6259de93f5beaa8eb15f8f22f171127a10e,2026-10-12T19:56:23-03:00,WASM-002 CP-003: classify governed artifact tokens,A,Evidence,Evidence/CP-003/CP003_Post_Format_Diff_Review.txt,Evidence/CP-003/CP003_Post_Format_Diff_Review.txt,0,4144,4144,4144
2d06f6259de93f5beaa8eb15f8f22f171127a10e,2026-10-12T19:56:23-03:00,WASM-002 CP-003: classify governed artifact tokens,A,Evidence,Evidence/CP-003/CP003_Post_Format_Test_Output.txt,Evidence/CP-003/CP003_Post_Format_Test_Output.txt,0,1362,1362,1362
2d06f6259de93f5beaa8eb15f8f22f171127a10e,2026-10-12T19:56:23-03:00,WASM-002 CP-003: classify governed artifact tokens,A,Evidence,Evidence/CP-003/CP003_Precommit_Git_Review.txt,Evidence/CP-003/CP003_Precommit_Git_Review.txt,0,1272,1272,1272
2d06f6259de93f5beaa8eb15f8f22f171127a10e,2026-10-12T19:56:23-03:00,WASM-002 CP-003: classify governed artifact tokens,A,Evidence,Evidence/CP-003/CP003_RED_Test_Change.txt,Evidence/CP-003/CP003_RED_Test_Change.txt,0,2044,2044,2044
2d06f6259de93f5beaa8eb15f8f22f171127a10e,2026-10-12T19:56:23-03:00,WASM-002 CP-003: classify governed artifact tokens,A,Evidence,Evidence/CP-003/CP003_RED_Test_Output.txt,Evidence/CP-003/CP003_RED_Test_Output.txt,0,710,710,710
2d06f6259de93f5beaa8eb15f8f22f171127a10e,2026-10-12T19:56:23-03:00,WASM-002 CP-003: classify governed artifact tokens,A,Evidence,Evidence/CP-003/CP003_Starting_State.txt,Evidence/CP-003/CP003_Starting_State.txt,0,201,201,201
2d06f6259de93f5beaa8eb15f8f22f171127a10e,2026-10-12T19:56:23-03:00,WASM-002 CP-003: classify governed artifact tokens,A,Evidence,Evidence/CP-003/CP003_WASM_Build_Output.txt,Evidence/CP-003/CP003_WASM_Build_Output.txt,0,189,189,189
2d06f6259de93f5beaa8eb15f8f22f171127a10e,2026-10-12T19:56:23-03:00,WASM-002 CP-003: classify governed artifact tokens,M,Source,src/lib.rs,src/lib.rs,1175,2486,2486,1311
2d06f6259de93f5beaa8eb15f8f22f171127a10e,2026-10-12T19:56:23-03:00,WASM-002 CP-003: classify governed artifact tokens,A,Tests,tests/artifact_class_disposition.rs,tests/artifact_class_disposition.rs,0,1834,1834,1834
12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,A,Evidence,Evidence/CP-004/CP004_Format_Output.txt,Evidence/CP-004/CP004_Format_Output.txt,0,363,363,363
12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,A,Evidence,Evidence/CP-004/CP004_GREEN_Source_Change.txt,Evidence/CP-004/CP004_GREEN_Source_Change.txt,0,1920,1920,1920
12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,A,Evidence,Evidence/CP-004/CP004_GREEN_Test_Output.txt,Evidence/CP-004/CP004_GREEN_Test_Output.txt,0,1960,1960,1960
12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,A,Evidence,Evidence/CP-004/CP004_Hash_Inventory.txt,Evidence/CP-004/CP004_Hash_Inventory.txt,0,2284,2284,2284
12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,A,Evidence,Evidence/CP-004/CP004_Hash_Inventory_Verification.txt,Evidence/CP-004/CP004_Hash_Inventory_Verification.txt,0,2400,2400,2400
12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,A,Evidence,Evidence/CP-004/CP004_Post_Format_Diff_Review.txt,Evidence/CP-004/CP004_Post_Format_Diff_Review.txt,0,4559,4559,4559
12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,A,Evidence,Evidence/CP-004/CP004_Post_Format_Test_Output.txt,Evidence/CP-004/CP004_Post_Format_Test_Output.txt,0,1966,1966,1966
12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,A,Evidence,Evidence/CP-004/CP004_Precommit_Git_Review.txt,Evidence/CP-004/CP004_Precommit_Git_Review.txt,0,2933,2933,2933
12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,A,Evidence,Evidence/CP-004/CP004_RED_Test_Change.txt,Evidence/CP-004/CP004_RED_Test_Change.txt,0,2206,2206,2206
12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,A,Evidence,Evidence/CP-004/CP004_RED_Test_Correction.txt,Evidence/CP-004/CP004_RED_Test_Correction.txt,0,394,394,394
12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,A,Evidence,Evidence/CP-004/CP004_RED_Test_Output.txt,Evidence/CP-004/CP004_RED_Test_Output.txt,0,633,633,633
12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,A,Evidence,Evidence/CP-004/CP004_Starting_State.txt,Evidence/CP-004/CP004_Starting_State.txt,0,372,372,372
12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,A,Evidence,Evidence/CP-004/CP004_WASM_Build_Output.txt,Evidence/CP-004/CP004_WASM_Build_Output.txt,0,359,359,359
12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,M,Source,src/lib.rs,src/lib.rs,2486,4071,4071,1585
12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,A,Tests,tests/artifact_filename_envelope.rs,tests/artifact_filename_envelope.rs,0,1901,1901,1901
cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,2026-10-12T20:53:56-03:00,WASM-002 CP-005: validate Gregorian UTC timestamps,A,Evidence,Evidence/CP-005/CP005_Format_Output.txt,Evidence/CP-005/CP005_Format_Output.txt,0,369,369,369
cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,2026-10-12T20:53:56-03:00,WASM-002 CP-005: validate Gregorian UTC timestamps,A,Evidence,Evidence/CP-005/CP005_GREEN_Source_Change.txt,Evidence/CP-005/CP005_GREEN_Source_Change.txt,0,2136,2136,2136
cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,2026-10-12T20:53:56-03:00,WASM-002 CP-005: validate Gregorian UTC timestamps,A,Evidence,Evidence/CP-005/CP005_GREEN_Test_Output.txt,Evidence/CP-005/CP005_GREEN_Test_Output.txt,0,2362,2362,2362
cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,2026-10-12T20:53:56-03:00,WASM-002 CP-005: validate Gregorian UTC timestamps,A,Evidence,Evidence/CP-005/CP005_Hash_Inventory.txt,Evidence/CP-005/CP005_Hash_Inventory.txt,0,2269,2269,2269
cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,2026-10-12T20:53:56-03:00,WASM-002 CP-005: validate Gregorian UTC timestamps,A,Evidence,Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,0,2388,2388,2388
cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,2026-10-12T20:53:56-03:00,WASM-002 CP-005: validate Gregorian UTC timestamps,A,Evidence,Evidence/CP-005/CP005_Post_Format_Diff_Review.txt,Evidence/CP-005/CP005_Post_Format_Diff_Review.txt,0,2342,2342,2342
cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,2026-10-12T20:53:56-03:00,WASM-002 CP-005: validate Gregorian UTC timestamps,A,Evidence,Evidence/CP-005/CP005_Post_Format_Test_Output.txt,Evidence/CP-005/CP005_Post_Format_Test_Output.txt,0,2392,2392,2392
cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,2026-10-12T20:53:56-03:00,WASM-002 CP-005: validate Gregorian UTC timestamps,A,Evidence,Evidence/CP-005/CP005_Precommit_Git_Review.txt,Evidence/CP-005/CP005_Precommit_Git_Review.txt,0,2778,2778,2778
cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,2026-10-12T20:53:56-03:00,WASM-002 CP-005: validate Gregorian UTC timestamps,A,Evidence,Evidence/CP-005/CP005_RED_Test_Change.txt,Evidence/CP-005/CP005_RED_Test_Change.txt,0,2369,2369,2369
cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,2026-10-12T20:53:56-03:00,WASM-002 CP-005: validate Gregorian UTC timestamps,A,Evidence,Evidence/CP-005/CP005_RED_Test_Output.txt,Evidence/CP-005/CP005_RED_Test_Output.txt,0,3092,3092,3092
cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,2026-10-12T20:53:56-03:00,WASM-002 CP-005: validate Gregorian UTC timestamps,A,Evidence,Evidence/CP-005/CP005_Starting_State.txt,Evidence/CP-005/CP005_Starting_State.txt,0,379,379,379
cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,2026-10-12T20:53:56-03:00,WASM-002 CP-005: validate Gregorian UTC timestamps,A,Evidence,Evidence/CP-005/CP005_WASM_Build_Output.txt,Evidence/CP-005/CP005_WASM_Build_Output.txt,0,396,396,396
cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,2026-10-12T20:53:56-03:00,WASM-002 CP-005: validate Gregorian UTC timestamps,M,Source,src/lib.rs,src/lib.rs,4071,5176,5176,1105
cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,2026-10-12T20:53:56-03:00,WASM-002 CP-005: validate Gregorian UTC timestamps,A,Tests,tests/artifact_utc_timestamp.rs,tests/artifact_utc_timestamp.rs,0,2018,2018,2018
aff54d08dcbacaa0c54d8869749344a504c5ad61,2026-10-12T21:20:03-03:00,WASM-002 CP-006: separate artifact class and serialization,A,Evidence,Evidence/CP-006/CP006_Format_Output.txt,Evidence/CP-006/CP006_Format_Output.txt,0,369,369,369
aff54d08dcbacaa0c54d8869749344a504c5ad61,2026-10-12T21:20:03-03:00,WASM-002 CP-006: separate artifact class and serialization,A,Evidence,Evidence/CP-006/CP006_GREEN_Source_Change.txt,Evidence/CP-006/CP006_GREEN_Source_Change.txt,0,1792,1792,1792
aff54d08dcbacaa0c54d8869749344a504c5ad61,2026-10-12T21:20:03-03:00,WASM-002 CP-006: separate artifact class and serialization,A,Evidence,Evidence/CP-006/CP006_GREEN_Test_Output.txt,Evidence/CP-006/CP006_GREEN_Test_Output.txt,0,2876,2876,2876
aff54d08dcbacaa0c54d8869749344a504c5ad61,2026-10-12T21:20:03-03:00,WASM-002 CP-006: separate artifact class and serialization,A,Evidence,Evidence/CP-006/CP006_Hash_Inventory.txt,Evidence/CP-006/CP006_Hash_Inventory.txt,0,2435,2435,2435
aff54d08dcbacaa0c54d8869749344a504c5ad61,2026-10-12T21:20:03-03:00,WASM-002 CP-006: separate artifact class and serialization,A,Evidence,Evidence/CP-006/CP006_Hash_Inventory_Verification.txt,Evidence/CP-006/CP006_Hash_Inventory_Verification.txt,0,2543,2543,2543
aff54d08dcbacaa0c54d8869749344a504c5ad61,2026-10-12T21:20:03-03:00,WASM-002 CP-006: separate artifact class and serialization,A,Evidence,Evidence/CP-006/CP006_Post_Format_Diff_Review.txt,Evidence/CP-006/CP006_Post_Format_Diff_Review.txt,0,1965,1965,1965
aff54d08dcbacaa0c54d8869749344a504c5ad61,2026-10-12T21:20:03-03:00,WASM-002 CP-006: separate artifact class and serialization,A,Evidence,Evidence/CP-006/CP006_Post_Format_Test_Output.txt,Evidence/CP-006/CP006_Post_Format_Test_Output.txt,0,2882,2882,2882
aff54d08dcbacaa0c54d8869749344a504c5ad61,2026-10-12T21:20:03-03:00,WASM-002 CP-006: separate artifact class and serialization,A,Evidence,Evidence/CP-006/CP006_Precommit_Git_Review.txt,Evidence/CP-006/CP006_Precommit_Git_Review.txt,0,2457,2457,2457
aff54d08dcbacaa0c54d8869749344a504c5ad61,2026-10-12T21:20:03-03:00,WASM-002 CP-006: separate artifact class and serialization,A,Evidence,Evidence/CP-006/CP006_RED_Test_Change.txt,Evidence/CP-006/CP006_RED_Test_Change.txt,0,3423,3423,3423
aff54d08dcbacaa0c54d8869749344a504c5ad61,2026-10-12T21:20:03-03:00,WASM-002 CP-006: separate artifact class and serialization,A,Evidence,Evidence/CP-006/CP006_RED_Test_Output.txt,Evidence/CP-006/CP006_RED_Test_Output.txt,0,792,792,792
aff54d08dcbacaa0c54d8869749344a504c5ad61,2026-10-12T21:20:03-03:00,WASM-002 CP-006: separate artifact class and serialization,A,Evidence,Evidence/CP-006/CP006_Starting_State.txt,Evidence/CP-006/CP006_Starting_State.txt,0,854,854,854
aff54d08dcbacaa0c54d8869749344a504c5ad61,2026-10-12T21:20:03-03:00,WASM-002 CP-006: separate artifact class and serialization,A,Evidence,Evidence/CP-006/CP006_WASM_Build_Output.txt,Evidence/CP-006/CP006_WASM_Build_Output.txt,0,396,396,396
aff54d08dcbacaa0c54d8869749344a504c5ad61,2026-10-12T21:20:03-03:00,WASM-002 CP-006: separate artifact class and serialization,M,Source,src/lib.rs,src/lib.rs,5176,6143,6143,967
aff54d08dcbacaa0c54d8869749344a504c5ad61,2026-10-12T21:20:03-03:00,WASM-002 CP-006: separate artifact class and serialization,A,Tests,tests/artifact_serialization_separation.rs,tests/artifact_serialization_separation.rs,0,3002,3002,3002
3c512df519f3a2431b363e4c57dc234c02378124,2026-10-12T21:52:18-03:00,WASM-002 CP-007: construct canonical filenames without normalization,A,Evidence,Evidence/CP-007/CP007_Format_Output.txt,Evidence/CP-007/CP007_Format_Output.txt,0,369,369,369
3c512df519f3a2431b363e4c57dc234c02378124,2026-10-12T21:52:18-03:00,WASM-002 CP-007: construct canonical filenames without normalization,A,Evidence,Evidence/CP-007/CP007_GREEN_Source_Change.txt,Evidence/CP-007/CP007_GREEN_Source_Change.txt,0,1535,1535,1535
3c512df519f3a2431b363e4c57dc234c02378124,2026-10-12T21:52:18-03:00,WASM-002 CP-007: construct canonical filenames without normalization,A,Evidence,Evidence/CP-007/CP007_GREEN_Test_Output.txt,Evidence/CP-007/CP007_GREEN_Test_Output.txt,0,3360,3360,3360
3c512df519f3a2431b363e4c57dc234c02378124,2026-10-12T21:52:18-03:00,WASM-002 CP-007: construct canonical filenames without normalization,A,Evidence,Evidence/CP-007/CP007_Hash_Inventory.txt,Evidence/CP-007/CP007_Hash_Inventory.txt,0,2464,2464,2464
3c512df519f3a2431b363e4c57dc234c02378124,2026-10-12T21:52:18-03:00,WASM-002 CP-007: construct canonical filenames without normalization,A,Evidence,Evidence/CP-007/CP007_Hash_Inventory_Verification.txt,Evidence/CP-007/CP007_Hash_Inventory_Verification.txt,0,2665,2665,2665
3c512df519f3a2431b363e4c57dc234c02378124,2026-10-12T21:52:18-03:00,WASM-002 CP-007: construct canonical filenames without normalization,A,Evidence,Evidence/CP-007/CP007_Post_Format_Diff_Review.txt,Evidence/CP-007/CP007_Post_Format_Diff_Review.txt,0,1870,1870,1870
3c512df519f3a2431b363e4c57dc234c02378124,2026-10-12T21:52:18-03:00,WASM-002 CP-007: construct canonical filenames without normalization,A,Evidence,Evidence/CP-007/CP007_Post_Format_Test_Output.txt,Evidence/CP-007/CP007_Post_Format_Test_Output.txt,0,3404,3404,3404
3c512df519f3a2431b363e4c57dc234c02378124,2026-10-12T21:52:18-03:00,WASM-002 CP-007: construct canonical filenames without normalization,A,Evidence,Evidence/CP-007/CP007_Precommit_Git_Review.txt,Evidence/CP-007/CP007_Precommit_Git_Review.txt,0,2398,2398,2398
3c512df519f3a2431b363e4c57dc234c02378124,2026-10-12T21:52:18-03:00,WASM-002 CP-007: construct canonical filenames without normalization,A,Evidence,Evidence/CP-007/CP007_RED_Test_Change.txt,Evidence/CP-007/CP007_RED_Test_Change.txt,0,3465,3465,3465
3c512df519f3a2431b363e4c57dc234c02378124,2026-10-12T21:52:18-03:00,WASM-002 CP-007: construct canonical filenames without normalization,A,Evidence,Evidence/CP-007/CP007_RED_Test_Output.txt,Evidence/CP-007/CP007_RED_Test_Output.txt,0,790,790,790
3c512df519f3a2431b363e4c57dc234c02378124,2026-10-12T21:52:18-03:00,WASM-002 CP-007: construct canonical filenames without normalization,A,Evidence,Evidence/CP-007/CP007_Starting_State.txt,Evidence/CP-007/CP007_Starting_State.txt,0,1148,1148,1148
3c512df519f3a2431b363e4c57dc234c02378124,2026-10-12T21:52:18-03:00,WASM-002 CP-007: construct canonical filenames without normalization,A,Evidence,Evidence/CP-007/CP007_WASM_Build_Output.txt,Evidence/CP-007/CP007_WASM_Build_Output.txt,0,396,396,396
3c512df519f3a2431b363e4c57dc234c02378124,2026-10-12T21:52:18-03:00,WASM-002 CP-007: construct canonical filenames without normalization,M,Source,src/lib.rs,src/lib.rs,6143,6829,6829,686
3c512df519f3a2431b363e4c57dc234c02378124,2026-10-12T21:52:18-03:00,WASM-002 CP-007: construct canonical filenames without normalization,A,Tests,tests/artifact_filename_construction.rs,tests/artifact_filename_construction.rs,0,2872,2872,2872
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Evidence,Evidence/CP-008/CP008_Final_Source_Review.txt,Evidence/CP-008/CP008_Final_Source_Review.txt,0,228,228,228
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Evidence,Evidence/CP-008/CP008_Final_Staging_Review.txt,Evidence/CP-008/CP008_Final_Staging_Review.txt,0,784,784,784
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Evidence,Evidence/CP-008/CP008_Full_Regression_Test_Output.txt,Evidence/CP-008/CP008_Full_Regression_Test_Output.txt,0,3948,3948,3948
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Evidence,Evidence/CP-008/CP008_GREEN_Test_Output.txt,Evidence/CP-008/CP008_GREEN_Test_Output.txt,0,849,849,849
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Evidence,Evidence/CP-008/CP008_Git_Whitespace_Check.txt,Evidence/CP-008/CP008_Git_Whitespace_Check.txt,0,34,34,34
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Evidence,Evidence/CP-008/CP008_Hash_Inventory.txt,Evidence/CP-008/CP008_Hash_Inventory.txt,0,2228,2228,2228
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Evidence,Evidence/CP-008/CP008_Hash_Inventory_Verification.txt,Evidence/CP-008/CP008_Hash_Inventory_Verification.txt,0,224,224,224
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Evidence,Evidence/CP-008/CP008_Post_Format_Test_Output.txt,Evidence/CP-008/CP008_Post_Format_Test_Output.txt,0,3829,3829,3829
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Evidence,Evidence/CP-008/CP008_Precommit_Git_Review.txt,Evidence/CP-008/CP008_Precommit_Git_Review.txt,0,6874,6874,6874
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Evidence,Evidence/CP-008/CP008_RED_Test_Output.txt,Evidence/CP-008/CP008_RED_Test_Output.txt,0,740,740,740
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Evidence,Evidence/CP-008/CP008_Rustfmt_Check_Output.txt,Evidence/CP-008/CP008_Rustfmt_Check_Output.txt,0,27,27,27
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Evidence,Evidence/CP-008/CP008_Rustfmt_Output.txt,Evidence/CP-008/CP008_Rustfmt_Output.txt,0,23,23,23
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Evidence,Evidence/CP-008/CP008_Staged_Whitespace_Diagnostic.txt,Evidence/CP-008/CP008_Staged_Whitespace_Diagnostic.txt,0,178,178,178
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Evidence,Evidence/CP-008/CP008_WASM_Build_Output.txt,Evidence/CP-008/CP008_WASM_Build_Output.txt,0,324,324,324
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Evidence,Evidence/CP-008/CP008_Whitespace_Exception_Review.txt,Evidence/CP-008/CP008_Whitespace_Exception_Review.txt,0,435,435,435
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Evidence,Evidence/Day066_Preflight_Native_Test_Output.txt,Evidence/Day066_Preflight_Native_Test_Output.txt,0,3206,3206,3206
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,M,Source,src/lib.rs,src/lib.rs,6829,7783,7783,954
346733a962192320e0d56271add15a47b6037b6b,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,A,Tests,tests/CP008_source_eligibility.rs,tests/CP008_source_eligibility.rs,0,2189,2189,2189
dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,A,Evidence,Evidence/CP-009/CP009_Baseline_Test_Output.txt,Evidence/CP-009/CP009_Baseline_Test_Output.txt,0,3818,3818,3818
dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,A,Evidence,Evidence/CP-009/CP009_Final_Staging_Review.txt,Evidence/CP-009/CP009_Final_Staging_Review.txt,0,825,825,825
dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,A,Evidence,Evidence/CP-009/CP009_Full_Regression_Test_Output.txt,Evidence/CP-009/CP009_Full_Regression_Test_Output.txt,0,4649,4649,4649
dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,A,Evidence,Evidence/CP-009/CP009_GREEN_Test_Output.txt,Evidence/CP-009/CP009_GREEN_Test_Output.txt,0,1015,1015,1015
dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,A,Evidence,Evidence/CP-009/CP009_Git_Whitespace_Check.txt,Evidence/CP-009/CP009_Git_Whitespace_Check.txt,0,28,28,28
dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,A,Evidence,Evidence/CP-009/CP009_Hash_Inventory.txt,Evidence/CP-009/CP009_Hash_Inventory.txt,0,2453,2453,2453
dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,A,Evidence,Evidence/CP-009/CP009_Hash_Inventory_Verification.txt,Evidence/CP-009/CP009_Hash_Inventory_Verification.txt,0,234,234,234
dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,A,Evidence,Evidence/CP-009/CP009_Post_Format_Test_Output.txt,Evidence/CP-009/CP009_Post_Format_Test_Output.txt,0,4656,4656,4656
dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,A,Evidence,Evidence/CP-009/CP009_Precommit_Git_Review.txt,Evidence/CP-009/CP009_Precommit_Git_Review.txt,0,1652,1652,1652
dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,A,Evidence,Evidence/CP-009/CP009_RED_Test_Output.txt,Evidence/CP-009/CP009_RED_Test_Output.txt,0,1092,1092,1092
dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,A,Evidence,Evidence/CP-009/CP009_Rustfmt_Check_Output.txt,Evidence/CP-009/CP009_Rustfmt_Check_Output.txt,0,27,27,27
dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,A,Evidence,Evidence/CP-009/CP009_Rustfmt_Output.txt,Evidence/CP-009/CP009_Rustfmt_Output.txt,0,21,21,21
dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,A,Evidence,Evidence/CP-009/CP009_WASM_Build_Output.txt,Evidence/CP-009/CP009_WASM_Build_Output.txt,0,324,324,324
dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,M,Source,src/lib.rs,src/lib.rs,7783,10093,10093,2310
dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,A,Tests,tests/CP009_exact_root_snapshot.rs,tests/CP009_exact_root_snapshot.rs,0,4389,4389,4389
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/.gitattributes,Evidence/CP-010/.gitattributes,0,272,272,272
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Closing_Git_Review.txt,Evidence/CP-010/CP010_Closing_Git_Review.txt,0,3487,3487,3487
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Final_Staging_Review.txt,Evidence/CP-010/CP010_Final_Staging_Review.txt,0,5675,5675,5675
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Full_Regression_Test_Output.txt,Evidence/CP-010/CP010_Full_Regression_Test_Output.txt,0,5031,5031,5031
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_GREEN_Implementation_Review.txt,Evidence/CP-010/CP010_GREEN_Implementation_Review.txt,0,1069,1069,1069
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_GREEN_Test_Output.txt,Evidence/CP-010/CP010_GREEN_Test_Output.txt,0,648,648,648
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Hash_Inventory.txt,Evidence/CP-010/CP010_Hash_Inventory.txt,0,3265,3265,3265
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Hash_Inventory_Corrected.txt,Evidence/CP-010/CP010_Hash_Inventory_Corrected.txt,0,3306,3306,3306
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Hash_Inventory_Verification.txt,Evidence/CP-010/CP010_Hash_Inventory_Verification.txt,0,3567,3567,3567
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Post_Format_Check_Output.txt,Evidence/CP-010/CP010_Post_Format_Check_Output.txt,0,173,173,173
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt,Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt,0,5053,5053,5053
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Precommit_Git_Review.txt,Evidence/CP-010/CP010_Precommit_Git_Review.txt,0,2854,2854,2854
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_RED_Test_Output.txt,Evidence/CP-010/CP010_RED_Test_Output.txt,0,1942,1942,1942
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt,Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt,0,663,663,663
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Rust_Toolchain_Verification.txt,Evidence/CP-010/CP010_Rust_Toolchain_Verification.txt,0,257,257,257
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Rustfmt_Application_Output.txt,Evidence/CP-010/CP010_Rustfmt_Application_Output.txt,0,360,360,360
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Rustfmt_Check_Output.txt,Evidence/CP-010/CP010_Rustfmt_Check_Output.txt,0,679,679,679
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Scope_Lock.txt,Evidence/CP-010/CP010_Scope_Lock.txt,0,752,752,752
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Staged_Whitespace_Diagnostic.txt,Evidence/CP-010/CP010_Staged_Whitespace_Diagnostic.txt,0,368,368,368
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Starting_State.txt,Evidence/CP-010/CP010_Starting_State.txt,0,17346,17346,17346
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Supplementary_Hash_Inventory.txt,Evidence/CP-010/CP010_Supplementary_Hash_Inventory.txt,0,1138,1138,1138
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt,Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt,0,1219,1219,1219
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Test_PreFormat_Snapshot.txt,Evidence/CP-010/CP010_Test_PreFormat_Snapshot.txt,0,2175,2175,2175
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_WASM_Build_Output.txt,Evidence/CP-010/CP010_WASM_Build_Output.txt,0,229,229,229
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Whitespace_Exception_Review.txt,Evidence/CP-010/CP010_Whitespace_Exception_Review.txt,0,802,802,802
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Evidence,Evidence/CP-010/CP010_Whitespace_Followup_Verification.txt,Evidence/CP-010/CP010_Whitespace_Followup_Verification.txt,0,509,509,509
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,M,Source,src/lib.rs,src/lib.rs,10093,10589,10589,496
b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,A,Tests,tests/CP010_cvt_filename_candidate.rs,tests/CP010_cvt_filename_candidate.rs,0,2172,2172,2172
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/.gitattributes,Evidence/CP-011/.gitattributes,0,236,236,236
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Closing_Git_Review.txt,Evidence/CP-011/CP011_Closing_Git_Review.txt,0,5510,5510,5510
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Final_Staging_Review.txt,Evidence/CP-011/CP011_Final_Staging_Review.txt,0,1852,1852,1852
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Full_Regression_Test_Output.txt,Evidence/CP-011/CP011_Full_Regression_Test_Output.txt,0,6032,6032,6032
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_GREEN_Source_Change.txt,Evidence/CP-011/CP011_GREEN_Source_Change.txt,0,1247,1247,1247
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_GREEN_Test_Output.txt,Evidence/CP-011/CP011_GREEN_Test_Output.txt,0,1100,1100,1100
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Hash_Inventory.txt,Evidence/CP-011/CP011_Hash_Inventory.txt,0,3339,3339,3339
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Hash_Inventory_Verification.txt,Evidence/CP-011/CP011_Hash_Inventory_Verification.txt,0,417,417,417
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt,Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt,0,6118,6118,6118
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt,Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt,0,684,684,684
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Precommit_Git_Review.txt,Evidence/CP-011/CP011_Precommit_Git_Review.txt,0,2982,2982,2982
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Preformat_Test_Snapshot.txt,Evidence/CP-011/CP011_Preformat_Test_Snapshot.txt,0,2344,2344,2344
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_RED_Test_Output.txt,Evidence/CP-011/CP011_RED_Test_Output.txt,0,942,942,942
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Rustfmt_Apply_Output.txt,Evidence/CP-011/CP011_Rustfmt_Apply_Output.txt,0,853,853,853
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Rustfmt_Check_Output.txt,Evidence/CP-011/CP011_Rustfmt_Check_Output.txt,0,2068,2068,2068
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt,Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt,0,571,571,571
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Scope_Lock.txt,Evidence/CP-011/CP011_Scope_Lock.txt,0,1138,1138,1138
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Staged_Whitespace_Diagnostic.txt,Evidence/CP-011/CP011_Staged_Whitespace_Diagnostic.txt,0,1751,1751,1751
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Staging_Recovery_Review.txt,Evidence/CP-011/CP011_Staging_Recovery_Review.txt,0,894,894,894
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Starting_State.txt,Evidence/CP-011/CP011_Starting_State.txt,0,404,404,404
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Supplementary_Hash_Inventory.txt,Evidence/CP-011/CP011_Supplementary_Hash_Inventory.txt,0,1370,1370,1370
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt,Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt,0,613,613,613
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Supplementary_Staging_Review.txt,Evidence/CP-011/CP011_Supplementary_Staging_Review.txt,0,1995,1995,1995
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_WASM_Build_Output.txt,Evidence/CP-011/CP011_WASM_Build_Output.txt,0,688,688,688
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Evidence,Evidence/CP-011/CP011_Whitespace_Exception_Review.txt,Evidence/CP-011/CP011_Whitespace_Exception_Review.txt,0,654,654,654
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,M,Source,src/lib.rs,src/lib.rs,10589,11016,11016,427
e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,A,Tests,tests/CP011_cvt_scr_candidate_identity.rs,tests/CP011_cvt_scr_candidate_identity.rs,0,2321,2321,2321
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/.gitattributes,Evidence/CP-012/.gitattributes,0,426,426,426
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_Closing_Git_Review.txt,Evidence/CP-012/CP012_Closing_Git_Review.txt,0,2353,2353,2353
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_EOF_Whitespace_Amendment.txt,Evidence/CP-012/CP012_EOF_Whitespace_Amendment.txt,0,1772,1772,1772
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_Final_Rustfmt_Check.txt,Evidence/CP-012/CP012_Final_Rustfmt_Check.txt,0,706,706,706
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_Final_Staging_Review.txt,Evidence/CP-012/CP012_Final_Staging_Review.txt,0,2228,2228,2228
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_Full_Regression_Test_Output.txt,Evidence/CP-012/CP012_Full_Regression_Test_Output.txt,0,6722,6722,6722
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_GREEN2_Test_Output.txt,Evidence/CP-012/CP012_GREEN2_Test_Output.txt,0,1279,1279,1279
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_GREEN_Correction_Review.txt,Evidence/CP-012/CP012_GREEN_Correction_Review.txt,0,1558,1558,1558
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_GREEN_Failure_Triage.txt,Evidence/CP-012/CP012_GREEN_Failure_Triage.txt,0,9465,9465,9465
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_GREEN_Rustfmt_Precheck.txt,Evidence/CP-012/CP012_GREEN_Rustfmt_Precheck.txt,0,0,0,0
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_GREEN_Source_Change.txt,Evidence/CP-012/CP012_GREEN_Source_Change.txt,0,1320,1320,1320
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_GREEN_Test_Output.txt,Evidence/CP-012/CP012_GREEN_Test_Output.txt,0,1596,1596,1596
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_Hash_Inventory.txt,Evidence/CP-012/CP012_Hash_Inventory.txt,0,3730,3730,3730
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_Hash_Inventory_Verification.txt,Evidence/CP-012/CP012_Hash_Inventory_Verification.txt,0,1492,1492,1492
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_Post_Staging_Hash_Amendment.txt,Evidence/CP-012/CP012_Post_Staging_Hash_Amendment.txt,0,1571,1571,1571
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_Post_Staging_Hash_Verification.txt,Evidence/CP-012/CP012_Post_Staging_Hash_Verification.txt,0,766,766,766
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_Precommit_Git_Review.txt,Evidence/CP-012/CP012_Precommit_Git_Review.txt,0,3086,3086,3086
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_RED_Test_Output.txt,Evidence/CP-012/CP012_RED_Test_Output.txt,0,1095,1095,1095
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_Scope_Lock.txt,Evidence/CP-012/CP012_Scope_Lock.txt,0,1317,1317,1317
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_Staged_Whitespace_Review.txt,Evidence/CP-012/CP012_Staged_Whitespace_Review.txt,0,1984,1984,1984
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_Starting_State.txt,Evidence/CP-012/CP012_Starting_State.txt,0,3699,3699,3699
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_Supplementary_Hash_Inventory.txt,Evidence/CP-012/CP012_Supplementary_Hash_Inventory.txt,0,1046,1046,1046
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_Supplementary_Hash_Verification.txt,Evidence/CP-012/CP012_Supplementary_Hash_Verification.txt,0,781,781,781
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_Test_Authoring_Format_Output.txt,Evidence/CP-012/CP012_Test_Authoring_Format_Output.txt,0,242,242,242
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_WASM_Build_Output.txt,Evidence/CP-012/CP012_WASM_Build_Output.txt,0,896,896,896
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Evidence,Evidence/CP-012/CP012_Whitespace_Exceptions_Review.txt,Evidence/CP-012/CP012_Whitespace_Exceptions_Review.txt,0,1456,1456,1456
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,M,Source,src/lib.rs,src/lib.rs,11016,11541,11541,525
efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,A,Tests,tests/CP012_scr_filename_candidate.rs,tests/CP012_scr_filename_candidate.rs,0,1976,1976,1976
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/.gitattributes,Evidence/CP-013/.gitattributes,0,547,547,547
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Approved_Scope_Lock.txt,Evidence/CP-013/CP013_Approved_Scope_Lock.txt,0,2236,2236,2236
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Closing_Git_Review.txt,Evidence/CP-013/CP013_Closing_Git_Review.txt,0,3386,3386,3386
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Closing_Hash_Amendment.txt,Evidence/CP-013/CP013_Closing_Hash_Amendment.txt,0,1496,1496,1496
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Closing_Hash_Verification.txt,Evidence/CP-013/CP013_Closing_Hash_Verification.txt,0,4148,4148,4148
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Final_Evidence_Staging_Review.txt,Evidence/CP-013/CP013_Final_Evidence_Staging_Review.txt,0,2986,2986,2986
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Final_Staging_Verification.txt,Evidence/CP-013/CP013_Final_Staging_Verification.txt,0,5064,5064,5064
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Full_Regression_Test_Output.txt,Evidence/CP-013/CP013_Full_Regression_Test_Output.txt,0,6617,6617,6617
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Full_Regression_Verification.txt,Evidence/CP-013/CP013_Full_Regression_Verification.txt,0,674,674,674
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_GREEN_Implementation_Report.txt,Evidence/CP-013/CP013_GREEN_Implementation_Report.txt,0,752,752,752
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_GREEN_Test_Output.txt,Evidence/CP-013/CP013_GREEN_Test_Output.txt,0,767,767,767
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_GREEN_Test_Verification.txt,Evidence/CP-013/CP013_GREEN_Test_Verification.txt,0,692,692,692
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt,Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt,0,6495,6495,6495
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt,Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt,0,7179,7179,7179
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt,Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt,0,10336,10336,10336
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Hash_Inventory.txt,Evidence/CP-013/CP013_Hash_Inventory.txt,0,2803,2803,2803
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Hash_Inventory_Verification.txt,Evidence/CP-013/CP013_Hash_Inventory_Verification.txt,0,1699,1699,1699
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Opening_Git_Preflight.txt,Evidence/CP-013/CP013_Opening_Git_Preflight.txt,0,340,340,340
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt,Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt,0,1472,1472,1472
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt,Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt,0,3666,3666,3666
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Precedent_Test_Inspection.txt,Evidence/CP-013/CP013_Precedent_Test_Inspection.txt,0,8512,8512,8512
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Precommit_Git_Review.txt,Evidence/CP-013/CP013_Precommit_Git_Review.txt,0,2907,2907,2907
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt,Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt,0,568,568,568
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_RED_Test_Output.txt,Evidence/CP-013/CP013_RED_Test_Output.txt,0,607,607,607
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_RED_Test_Verification.txt,Evidence/CP-013/CP013_RED_Test_Verification.txt,0,551,551,551
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt,Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt,0,5583,5583,5583
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Rustfmt_Check_Output.txt,Evidence/CP-013/CP013_Rustfmt_Check_Output.txt,0,0,0,0
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt,Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt,0,526,526,526
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Source_Inspection.txt,Evidence/CP-013/CP013_Source_Inspection.txt,0,15768,15768,15768
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Staged_Whitespace_Recovery_Output.txt,Evidence/CP-013/CP013_Staged_Whitespace_Recovery_Output.txt,0,0,0,0
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Staged_Whitespace_Recovery_Report.txt,Evidence/CP-013/CP013_Staged_Whitespace_Recovery_Report.txt,0,856,856,856
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Staging_Action_Report.txt,Evidence/CP-013/CP013_Staging_Action_Report.txt,0,181299,181299,181299
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt,Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt,0,1115,1115,1115
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt,Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt,0,2239,2239,2239
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Test_Authoring_Report.txt,Evidence/CP-013/CP013_Test_Authoring_Report.txt,0,446,446,446
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Test_Formatting_Report.txt,Evidence/CP-013/CP013_Test_Formatting_Report.txt,0,524,524,524
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Test_Rustfmt_Output.txt,Evidence/CP-013/CP013_Test_Rustfmt_Output.txt,0,0,0,0
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_WASM_Build_Output.txt,Evidence/CP-013/CP013_WASM_Build_Output.txt,0,159,159,159
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_WASM_Build_Verification.txt,Evidence/CP-013/CP013_WASM_Build_Verification.txt,0,713,713,713
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Evidence,Evidence/CP-013/CP013_Whitespace_Exception_Review.txt,Evidence/CP-013/CP013_Whitespace_Exception_Review.txt,0,1284,1284,1284
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,M,Source,src/lib.rs,src/lib.rs,11541,12312,12312,771
005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,A,Tests,tests/CP013_scr_rcp_candidate_identity.rs,tests/CP013_scr_rcp_candidate_identity.rs,0,2727,2727,2727
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Evidence_Preflight.txt.zip,Evidence/CP-014/ZIP/CP014_Evidence_Preflight.txt.zip,0,1980,1980,1980
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Full_Regression_Record.txt.zip,Evidence/CP-014/ZIP/CP014_Full_Regression_Record.txt.zip,0,587,587,587
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip,Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip,0,1913,1913,1913
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_GREEN_Run_Record.txt.zip,Evidence/CP-014/ZIP/CP014_GREEN_Run_Record.txt.zip,0,575,575,575
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip,Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip,0,547,547,547
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Git_Attributes_Amendment_Record.txt.zip,Evidence/CP-014/ZIP/CP014_Git_Attributes_Amendment_Record.txt.zip,0,593,593,593
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Git_Attributes_Diff_Recovery.txt.zip,Evidence/CP-014/ZIP/CP014_Git_Attributes_Diff_Recovery.txt.zip,0,386,386,386
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Git_Attributes_Recovery_Record.txt.zip,Evidence/CP-014/ZIP/CP014_Git_Attributes_Recovery_Record.txt.zip,0,654,654,654
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Git_Text_Policy_Inspection.txt.zip,Evidence/CP-014/ZIP/CP014_Git_Text_Policy_Inspection.txt.zip,0,614,614,614
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Hash_Inventory.txt.zip,Evidence/CP-014/ZIP/CP014_Hash_Inventory.txt.zip,0,1611,1611,1611
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Hash_Inventory_Verification.txt.zip,Evidence/CP-014/ZIP/CP014_Hash_Inventory_Verification.txt.zip,0,458,458,458
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Implementation_Record.txt.zip,Evidence/CP-014/ZIP/CP014_Implementation_Record.txt.zip,0,545,545,545
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Implementation_Surface.txt.zip,Evidence/CP-014/ZIP/CP014_Implementation_Surface.txt.zip,0,3401,3401,3401
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_RED_Run_Record.txt.zip,Evidence/CP-014/ZIP/CP014_RED_Run_Record.txt.zip,0,453,453,453
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_RED_Test_Output.txt.zip,Evidence/CP-014/ZIP/CP014_RED_Test_Output.txt.zip,0,500,500,500
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Rustfmt_Check_Output.txt.zip,Evidence/CP-014/ZIP/CP014_Rustfmt_Check_Output.txt.zip,0,158,158,158
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Rustfmt_Check_Record.txt.zip,Evidence/CP-014/ZIP/CP014_Rustfmt_Check_Record.txt.zip,0,545,545,545
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Rustfmt_Output.txt.zip,Evidence/CP-014/ZIP/CP014_Rustfmt_Output.txt.zip,0,146,146,146
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Scope_Inspection.txt.zip,Evidence/CP-014/ZIP/CP014_Scope_Inspection.txt.zip,0,1588,1588,1588
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Scope_Lock.txt.zip,Evidence/CP-014/ZIP/CP014_Scope_Lock.txt.zip,0,705,705,705
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Source_Diff.txt.zip,Evidence/CP-014/ZIP/CP014_Source_Diff.txt.zip,0,630,630,630
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Staged_Path_List.txt.zip,Evidence/CP-014/ZIP/CP014_Staged_Path_List.txt.zip,0,453,453,453
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Staged_Whitespace_Check.txt.zip,Evidence/CP-014/ZIP/CP014_Staged_Whitespace_Check.txt.zip,0,12668,12668,12668
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Staging_Command_Output.txt.zip,Evidence/CP-014/ZIP/CP014_Staging_Command_Output.txt.zip,0,257,257,257
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Staging_Record.txt.zip,Evidence/CP-014/ZIP/CP014_Staging_Record.txt.zip,0,528,528,528
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_Test_Format_Record.txt.zip,Evidence/CP-014/ZIP/CP014_Test_Format_Record.txt.zip,0,456,456,456
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_WASM_Build_Output.txt.zip,Evidence/CP-014/ZIP/CP014_WASM_Build_Output.txt.zip,0,293,293,293
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_WASM_Build_Record.txt.zip,Evidence/CP-014/ZIP/CP014_WASM_Build_Record.txt.zip,0,551,551,551
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_ZIP_Batch_Verification.txt.zip,Evidence/CP-014/ZIP/CP014_ZIP_Batch_Verification.txt.zip,0,3494,3494,3494
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Git_Add_Output.txt.zip,Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Git_Add_Output.txt.zip,0,166,166,166
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Git_Record.txt.zip,Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Git_Record.txt.zip,0,571,571,571
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Evidence,Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Verification.txt.zip,Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Verification.txt.zip,0,573,573,573
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,M,Source,src/lib.rs,src/lib.rs,12312,12915,12915,603
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14,CP014: recognize canonical RCP filename candidates,A,Tests,tests/CP014_rcp_filename_candidate_identity.rs,tests/CP014_rcp_filename_candidate_identity.rs,0,2656,2656,2656

ProjectDay,Date,DayKind,GitCommits,GitCheckpointCommits,LedgerCreditedCheckpoints,NewRequirementIDsTouched,GrossBytes,GrossKiB,EvidenceBytes,EvidenceKiB,SourceBytes,TestsBytes,OtherBytes,NetBytes,NetKiB,EvidencePercent
063,2026-10-10,BUILD,3,1,0,2,19798,19.334,6070,5.928,1147,2006,10575,19588,19.129,30.66
064,2026-10-11,BUILD,0,0,0,0,0,0.000,0,0.000,0,0,0,0,0.000,0.00
065,2026-10-12,BUILD,6,6,7,7,181899,177.636,141736,138.414,25880,14283,0,159905,156.157,77.92
066,2026-10-13,BUILD,6,6,6,3,572072,558.664,492964,481.410,63334,15774,0,514221,502.169,86.17
067,2026-10-14,BUILD,1,1,1,1,54170,52.900,38599,37.694,12915,2656,0,41858,40.877,71.26

WASM-002 / DAY067 / RECONCILED GIT VOLUME AND REQUIREMENT VELOCITY
Source baseline: Day066 CP013 read-only Git export at 005a38ef5e876847c4c08901c18da9c18565fd6b (15 commits; 267 file changes).
Day067 source: T-approved CP014 Git banking at f5038a183f1d3dc31b0065571bf8ac8814b5d8a9 (parent 005a38ef5e876847c4c08901c18da9c18565fd6b); 34 committed objects, of which 32 are ZIP files.
Technique: append CP014 object size deltas from the 32-entry staged-stat source, CP014 source append record and frozen test file bytes; not a fresh complete git rev-list or cat-file export.
Source file: previous committed blob 12,312 bytes + accepted source append 603 bytes = reconstructed CP014 src/lib.rs blob 12,915 bytes; 603 actual net growth. The final source SHA-256 was stable through acceptance and banking.
Test file: 2,656 bytes, matching the supplied test source artifact.
CP014 evidence ZIP bytes: 38,599; original 31 TXT evidence records total 135,916 bytes plus final batch TXT record 6,090 bytes = 142,006 plaintext bytes (locally preserved, not committed as TXT).
ZIP / original plaintext ratio: 27.18%. The 38,599 evidence bytes are actual ZIP blob sizes as staged and Git verified; plaintext counterfactual should not be compared as exact Git objects.
Commit calendar day 2026-10-14 is known; exact Git author/committer timestamp was not available in the provided post-banking files. No timestamp seconds are inferred.
Old Day063-Day066 Git volume figures remain untouched; new Day067 values contain compressed evidence. Category comparisons and gross evidence percentages are not like-for-like across packaging regimes.
Gross committed volume counts full newly added or content-modified blob versions. Net subtracts old replaced blob sizes. Git packed-disk size, hours, complexity, requirement completion, and ETA are not measured.
FROZEN_REQUIREMENTS=402
TOUCHED_PARTIAL=13
NOT_STARTED=389
FULLY_IMPLEMENTED=0
REQUIREMENT_ACCEPTED=0
INDEPENDENT_QA_CLEARED=0
BUILD_DAYS=5
BANKED_CHECKPOINTS=14
FIRST_TOUCH_VELOCITY=2.60 IDs per BUILD day
BANKED_CHECKPOINT_VELOCITY=2.80 CPs per BUILD day
GIT_FIRST_PARENT_COMMITS=16
GIT_CHANGED_FILE_RECORDS=301
GROSS_COMMITTED_BYTES=827939
NET_COMMITTED_BYTES=735572
EVIDENCE_GROSS_BYTES=679369
SOURCE_GROSS_BYTES=103276
TESTS_GROSS_BYTES=34719
OTHER_GROSS_BYTES=10575
EVIDENCE_GROSS_SHARE_PERCENT=82.06
CP014_GROSS_BYTES=54170
CP014_NET_BYTES=41858
CP014_ZIP_EVIDENCE_BYTES=38599
CP014_ZIP_EVIDENCE_SHARE_PERCENT=71.26
ACCEPTANCE=CP014 T-accepted and Git-banked; individual requirements remain only partially implemented.
DAY_067_FLIGHT=OPEN

CP015 FINAL ARCHIVE MANIFEST - DAY 067
Git baseline: f5038a183f1d3dc31b0065571bf8ac8814b5d8a9
Source SHA256: 538B918B634C5BFB04EFBB2DFE37257515C13094C09B4555820331C2987F9EE7
CP015 test SHA256: A4CA938D0B47E6DAA461C530FB19D7D17EF162D54AF8E69A1F53B7CA1FDDDD31
Initial ZIP report SHA256: A5A5510D1DF98FB9C0D2E16CB501301520024D5F8F5F6DE6BC4ED18715E01388
Original evidence archives: 15
Original evidence bytes: 15787
Initial ZIP bytes: 9123
One TXT entry per ZIP: VERIFIED
All extracted SHA256 hashes: VERIFIED
Manifest self-reference: NONE
Git banking: NOT AUTHORIZED

RAW_SHA256 | RAW_BYTES | ZIP_SHA256 | ZIP_BYTES | RAW_NAME | ZIP_NAME
B979714A4BB6374C744EBFFB998F4740299941632F79AABB58F7B5BA54C62FA1 | 692 | 37BCD43090AD7293D0CC561FB4A3D017C4B94CCFE27FC7324660B0672E95E5A1 | 649 | CP015_Formatting_Amendment_Verification.txt | CP015_Formatting_Amendment_Verification.txt.zip
93555C2705FC4BEFBCBA8EDBD7A0BD697C1E9CD177D17341FE33D1F13201106D | 7656 | BACD642F6F4CDD4502022CB0826BB1CA28DEC33E656F28337C7395FEF2C64EBD | 2010 | CP015_Full_Regression_Test_Output.txt | CP015_Full_Regression_Test_Output.txt.zip
0DE2E582AD0F69074768E6712597361F05A2DC254CCF149DEBAA6ABD66A27000 | 420 | B64A821C214F45301ABD102A80F6FE7A07907D5DF32ED7CB57D3118A2C012BAB | 490 | CP015_Full_Regression_Verification.txt | CP015_Full_Regression_Verification.txt.zip
1D9AC8A037E943F5E44EE603D361254FC48F7BD4C22BF61EB56467D0C238AF35 | 515 | 9BA7C7FEC72BAEB44778AC1B5B7B81BC524167464F44646E6B06CC05AEAE1BD1 | 472 | CP015_GREEN_Gate.txt | CP015_GREEN_Gate.txt.zip
73A9D713A6DF56531660B5D5022B80D598D55F3F2573F1C22E2EFFCF5B43BC14 | 797 | E6AC9BFB004F4F67AC790E291CA00218E42D4CB4E9179D79F3AD17B1CCDBFABC | 566 | CP015_GREEN_Test_Output.txt | CP015_GREEN_Test_Output.txt.zip
E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | 0 | BC8C830FD9486B81AC5A12300FE25725BD8AE48826B572BC81FF8C8EC188A7DA | 166 | CP015_PostAmend_Rustfmt_Output.txt | CP015_PostAmend_Rustfmt_Output.txt.zip
CE48864F68FB96D84A592CC7CE1AFDF19A366DC6087517D927FBEA709B5243F2 | 797 | 8CC7966AF0E76AD7E513247C2B8FF0603C5699E9F31A5EA80BBB472204E1B3DA | 575 | CP015_PostAmend_Test_Output.txt | CP015_PostAmend_Test_Output.txt.zip
3CDEAAC9981F9C58F43E21F4D14A8CD62D91F7DCC193616BB75B6F45B3D3CD1E | 345 | 7F056E54139D78683D453434E1F5FE43A701E33E23BAC6159323D7A84AA6E5E3 | 408 | CP015_RED_Gate.txt | CP015_RED_Gate.txt.zip
B6CADEEEEF423B1C4C710F5D12FEC3D2CB5A24D966D4C75E76B3B86D39473A46 | 635 | 7E996AC28A6DB2BADD1B0D5762B05F8F42C5C30B77343EF38EEE655F916B2A0C | 450 | CP015_RED_Test_Output.txt | CP015_RED_Test_Output.txt.zip
FDDCCD9E431D7972238A1BB3DF252185E69D43B08DD499E1529C0E3C457C32EC | 378 | 15CCF4A57C787B178EC52B8A7A37F2EABFAEE73C4A131D11EC5A4BCE3D0B237A | 448 | CP015_Rustfmt_Check_Gate.txt | CP015_Rustfmt_Check_Gate.txt.zip
3206CFA1FE9A2C01C4E0CD4BD71802396DAA568629C1539E3BC05A48FA1EFD14 | 1038 | 56F455B28E705648C541BD93340B38F63DCE8B5CDCDF09AE289D1D44323F5AFC | 612 | CP015_Rustfmt_Check_Output.txt | CP015_Rustfmt_Check_Output.txt.zip
612149D92F2134601248C07A445CDED7450FF6432B2F2759DC7E87246ADB09C8 | 159 | F1AE44D7BA2CA175D33ACD5E21082780FDB8D31950EE393AEB3D47690C6C1CA6 | 292 | CP015_WASM_Build_Output.txt | CP015_WASM_Build_Output.txt.zip
A59EE780C7AE762C854538A8E04F23740321C3199C9813ED834AB62C5AFAFB5C | 441 | D1EF96C47FEF6A235F32C971C57F0DA8770610398265BCFEDCF894F76F2D0990 | 504 | CP015_WASM_Build_Verification.txt | CP015_WASM_Build_Verification.txt.zip
FE906654A1CECEAA2CA362467676FDED5237B32FBE820E41191A89C6B3892359 | 1442 | 1DEB986AFC09AE198C2E8CAEC4CA9465105750ED5F3863A8AB22358D2076DDA0 | 954 | CP015_PreArchive_Hash_Inventory.txt | CP015_PreArchive_Hash_Inventory.txt.zip
D20E326D3D4331FEFEA255FE165583D487C41DF396B7B87A1E5B2E81A1261A44 | 472 | 1A470981AB5C104BCE986F20B8A501CEFAE63D2E0A2D2A0B2859E96A2380A86D | 527 | CP015_PreArchive_Hash_Verification.txt | CP015_PreArchive_Hash_Verification.txt.zip

CP015 FINAL ARCHIVE SEAL VERIFICATION - DAY 067
Git baseline: f5038a183f1d3dc31b0065571bf8ac8814b5d8a9
Original ZIPs reverified: 15
Final manifest ZIPs created: 1
Total ZIP archives: 16
Original evidence bytes: 15787
Initial archive bytes: 9123
Manifest SHA256: C998B6DB8C833DD8CE9DD10DBFBCE50067695FEC51D76FD143DF39568AAC1BDB
Manifest ZIP SHA256: 6083DAB41FFE75172F7AA06ACFD788511C7AD8C80E6FE470B78065CF7526028B
All entry names, lengths, and extracted SHA256 hashes: VERIFIED
Original TXT files rewritten: NO
Rust source and tests unchanged: YES
Result: PASS
Git staging: NOT AUTHORIZED
Git banking: NOT AUTHORIZED

CP015 APPROVED FORMATTING AMENDMENT - DAY 067
Git HEAD: f5038a183f1d3dc31b0065571bf8ac8814b5d8a9
Changes authorized by T: TWO LINE-WRAP CORRECTIONS
Original source SHA256: 31BE10641994ABA3D339C2A67773780F065162FBE0335C18D36D42E0213C2BA7
Amended source SHA256: 538B918B634C5BFB04EFBB2DFE37257515C13094C09B4555820331C2987F9EE7
Original test SHA256: 63F63780F57A5A28238470C992CE3E3DABF47B8441732AE5E9F2F2424C07019F
Amended test SHA256: A4CA938D0B47E6DAA461C530FB19D7D17EF162D54AF8E69A1F53B7CA1FDDDD31
Original source and tests backed up: YES
Rustfmt check exit: 0
Targeted test exit: 0
Six tests passed: True
Post-check hashes stable: True
Result: PASS
Git banking: NOT AUTHORIZED

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 2.20s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP008_source_eligibility.rs (target\debug\deps\CP008_source_eligibility-194c314726b26929.exe)

running 5 tests
test accepts_analyst_csv_final_extension_in_ascii_case_variants ... ok
test makes_no_case_or_unicode_normalization_claim ... ok
test refuses_paths_traversal_and_external_references ... ok
test refuses_reserved_namespace_even_if_name_looks_like_csv ... ok
test rejects_non_csv_or_nonfinal_csv_extensions ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP009_exact_root_snapshot.rs (target\debug\deps\CP009_exact_root_snapshot-b26a1b02e36e8f07.exe)

running 8 tests
test candidate_preflight_runs_before_root_matching ... ok
test duplicate_exact_entries_refuse_instead_of_picking_first ... ok
test finds_one_exact_reported_regular_file ... ok
test full_filename_match_is_exact_and_case_sensitive ... ok
test never_trims_to_find_a_different_physical_name ... ok
test reported_non_regular_entries_do_not_pass ... ok
test result_is_order_independent_and_empty_snapshot_is_not_found ... ok
test unicode_scalar_sequence_is_not_normalized ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP010_cvt_filename_candidate.rs (target\debug\deps\CP010_cvt_filename_candidate-ce216c0140f6b173.exe)

running 4 tests
test accepts_exact_canonical_cvt_csv_candidate ... ok
test refuses_paths_and_noncanonical_references ... ok
test refuses_wrong_classes_and_extensions ... ok
test refuses_malformed_canonical_identity ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP011_cvt_scr_candidate_identity.rs (target\debug\deps\CP011_cvt_scr_candidate_identity-8bc68fabbbb42eb4.exe)

running 6 tests
test derives_exact_corresponding_scr_identity ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_whitespace_and_noncanonical_names ... ok
test refuses_wrong_extension_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP012_scr_filename_candidate.rs (target\debug\deps\CP012_scr_filename_candidate-7c39746d8bb6fac7.exe)

running 6 tests
test accepts_canonical_scr_csv_candidate ... ok
test refuses_noncanonical_namespace_class_and_extension ... ok
test accepts_canonical_scr_txt_candidate ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_and_whitespace ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP013_scr_rcp_candidate_identity.rs (target\debug\deps\CP013_scr_rcp_candidate_identity-4f7c7bea8654150d.exe)

running 6 tests
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test derives_rcp_candidate_only_with_explicit_class ... ok
test refuses_invalid_identity_paths_and_whitespace ... ok
test refuses_non_scr_and_noncanonical_source_classes ... ok
test refuses_unsupported_or_incorrectly_cased_final_classes ... ok
test refuses_wrong_or_ambiguous_serialization_extensions ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP014_rcp_filename_candidate_identity.rs (target\debug\deps\CP014_rcp_filename_candidate_identity-249a1cd498442ced.exe)

running 6 tests
test accepts_canonical_rcp_txt_identity ... ok
test refuses_invalid_timestamp_uuid_and_envelope ... ok
test recognizes_existing_scr_to_rcp_derivation ... ok
test refuses_noncanonical_serialization ... ok
test refuses_paths_and_whitespace ... ok
test refuses_wrong_semantic_class_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\CP015_scr_rcp_filename_pair_identity.rs (target\debug\deps\CP015_scr_rcp_filename_pair_identity-526d10560ef9b891.exe)

running 6 tests
test refuses_paths_and_whitespace_on_either_side ... ok
test refuses_mismatched_uuid_even_when_both_names_are_canonical ... ok
test accepts_matching_canonical_scr_and_rcp_txt_names ... ok
test refuses_mismatched_utc_timestamp_even_when_both_names_are_canonical ... ok
test refuses_wrong_class_or_reversed_pair_order ... ok
test refuses_wrong_extensions_and_noncanonical_envelopes ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)

running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_registered_emittable_classes ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)

running 4 tests
test constructs_exact_canonical_filename_candidates ... ok
test preserves_extension_without_case_or_unicode_normalization ... ok
test refuses_noncanonical_class_without_repair ... ok
test refuses_invalid_timestamp_uuid_and_empty_extension ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)

running 3 tests
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)

running 6 tests
test recognizes_governed_namespace_and_class ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test rejects_invalid_class_boundaries ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)

running 4 tests
test extension_does_not_determine_semantic_class ... ok
test preserves_literal_tokens_without_claiming_authority ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok
test extracts_semantic_class_and_serialization_separately ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)

running 3 tests
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok
test rejects_nonexistent_gregorian_dates ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

CP015 FULL NATIVE REGRESSION - DAY 067
Git HEAD: f5038a183f1d3dc31b0065571bf8ac8814b5d8a9
Cargo exit code: 0
Test suites reported: 15
Tests passed: 70
Tests failed: 0
Expected tests: 70
Source SHA256: 538B918B634C5BFB04EFBB2DFE37257515C13094C09B4555820331C2987F9EE7
Test SHA256: A4CA938D0B47E6DAA461C530FB19D7D17EF162D54AF8E69A1F53B7CA1FDDDD31
Hashes unchanged: True
Result: PASS
Git banking: NOT AUTHORIZED

CP015 GREEN GATE - DAY 067
Git HEAD: f5038a183f1d3dc31b0065571bf8ac8814b5d8a9
Frozen test SHA256: 63F63780F57A5A28238470C992CE3E3DABF47B8441732AE5E9F2F2424C07019F
Source SHA256 before: B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236
Backup SHA256: B14F6EEE88762D467A704404587DE5F80C3F07444D09B3A45AE030687C6C5236
Source SHA256 after: 31BE10641994ABA3D339C2A67773780F065162FBE0335C18D36D42E0213C2BA7
Cargo exit code: 0
Six tests passed: True
Result: GREEN_PASS
Git banking: NOT AUTHORIZED

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 1.68s
     Running tests\CP015_scr_rcp_filename_pair_identity.rs (target\debug\deps\CP015_scr_rcp_filename_pair_identity-526d10560ef9b891.exe)

running 6 tests
test accepts_matching_canonical_scr_and_rcp_txt_names ... ok
test refuses_mismatched_uuid_even_when_both_names_are_canonical ... ok
test refuses_paths_and_whitespace_on_either_side ... ok
test refuses_mismatched_utc_timestamp_even_when_both_names_are_canonical ... ok
test refuses_wrong_class_or_reversed_pair_order ... ok
test refuses_wrong_extensions_and_noncanonical_envelopes ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

[master be997dc] CP015: verify canonical SCR-RCP filename pair identity
 18 files changed, 104 insertions(+)
 create mode 100644 Evidence/CP-015/ZIP/CP015_Final_Archive_Manifest.txt.zip
 create mode 100644 Evidence/CP-015/ZIP/CP015_Formatting_Amendment_Verification.txt.zip
 create mode 100644 Evidence/CP-015/ZIP/CP015_Full_Regression_Test_Output.txt.zip
 create mode 100644 Evidence/CP-015/ZIP/CP015_Full_Regression_Verification.txt.zip
 create mode 100644 Evidence/CP-015/ZIP/CP015_GREEN_Gate.txt.zip
 create mode 100644 Evidence/CP-015/ZIP/CP015_GREEN_Test_Output.txt.zip
 create mode 100644 Evidence/CP-015/ZIP/CP015_PostAmend_Rustfmt_Output.txt.zip
 create mode 100644 Evidence/CP-015/ZIP/CP015_PostAmend_Test_Output.txt.zip
 create mode 100644 Evidence/CP-015/ZIP/CP015_PreArchive_Hash_Inventory.txt.zip
 create mode 100644 Evidence/CP-015/ZIP/CP015_PreArchive_Hash_Verification.txt.zip
 create mode 100644 Evidence/CP-015/ZIP/CP015_RED_Gate.txt.zip
 create mode 100644 Evidence/CP-015/ZIP/CP015_RED_Test_Output.txt.zip
 create mode 100644 Evidence/CP-015/ZIP/CP015_Rustfmt_Check_Gate.txt.zip
 create mode 100644 Evidence/CP-015/ZIP/CP015_Rustfmt_Check_Output.txt.zip
 create mode 100644 Evidence/CP-015/ZIP/CP015_WASM_Build_Output.txt.zip
 create mode 100644 Evidence/CP-015/ZIP/CP015_WASM_Build_Verification.txt.zip
 create mode 100644 tests/CP015_scr_rcp_filename_pair_identity.rs

CP015 INITIAL ZIP VERIFICATION - DAY 067
Git HEAD: f5038a183f1d3dc31b0065571bf8ac8814b5d8a9
Original TXT files packaged: 15
ZIP files created: 15
ZIP entries per archive: 1
Extraction SHA256 matches original: YES
Original TXT files modified: NO
Rust source and tests modified: NO
Initial ZIP batch result: PASS
Final checkpoint sealing: PENDING
Git banking: NOT AUTHORIZED

RAW_SHA256 | RAW_BYTES | ZIP_SHA256 | ZIP_BYTES | RAW_NAME | ZIP_NAME
B979714A4BB6374C744EBFFB998F4740299941632F79AABB58F7B5BA54C62FA1 | 692 | 37BCD43090AD7293D0CC561FB4A3D017C4B94CCFE27FC7324660B0672E95E5A1 | 649 | CP015_Formatting_Amendment_Verification.txt | CP015_Formatting_Amendment_Verification.txt.zip
93555C2705FC4BEFBCBA8EDBD7A0BD697C1E9CD177D17341FE33D1F13201106D | 7656 | BACD642F6F4CDD4502022CB0826BB1CA28DEC33E656F28337C7395FEF2C64EBD | 2010 | CP015_Full_Regression_Test_Output.txt | CP015_Full_Regression_Test_Output.txt.zip
0DE2E582AD0F69074768E6712597361F05A2DC254CCF149DEBAA6ABD66A27000 | 420 | B64A821C214F45301ABD102A80F6FE7A07907D5DF32ED7CB57D3118A2C012BAB | 490 | CP015_Full_Regression_Verification.txt | CP015_Full_Regression_Verification.txt.zip
1D9AC8A037E943F5E44EE603D361254FC48F7BD4C22BF61EB56467D0C238AF35 | 515 | 9BA7C7FEC72BAEB44778AC1B5B7B81BC524167464F44646E6B06CC05AEAE1BD1 | 472 | CP015_GREEN_Gate.txt | CP015_GREEN_Gate.txt.zip
73A9D713A6DF56531660B5D5022B80D598D55F3F2573F1C22E2EFFCF5B43BC14 | 797 | E6AC9BFB004F4F67AC790E291CA00218E42D4CB4E9179D79F3AD17B1CCDBFABC | 566 | CP015_GREEN_Test_Output.txt | CP015_GREEN_Test_Output.txt.zip
E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | 0 | BC8C830FD9486B81AC5A12300FE25725BD8AE48826B572BC81FF8C8EC188A7DA | 166 | CP015_PostAmend_Rustfmt_Output.txt | CP015_PostAmend_Rustfmt_Output.txt.zip
CE48864F68FB96D84A592CC7CE1AFDF19A366DC6087517D927FBEA709B5243F2 | 797 | 8CC7966AF0E76AD7E513247C2B8FF0603C5699E9F31A5EA80BBB472204E1B3DA | 575 | CP015_PostAmend_Test_Output.txt | CP015_PostAmend_Test_Output.txt.zip
3CDEAAC9981F9C58F43E21F4D14A8CD62D91F7DCC193616BB75B6F45B3D3CD1E | 345 | 7F056E54139D78683D453434E1F5FE43A701E33E23BAC6159323D7A84AA6E5E3 | 408 | CP015_RED_Gate.txt | CP015_RED_Gate.txt.zip
B6CADEEEEF423B1C4C710F5D12FEC3D2CB5A24D966D4C75E76B3B86D39473A46 | 635 | 7E996AC28A6DB2BADD1B0D5762B05F8F42C5C30B77343EF38EEE655F916B2A0C | 450 | CP015_RED_Test_Output.txt | CP015_RED_Test_Output.txt.zip
FDDCCD9E431D7972238A1BB3DF252185E69D43B08DD499E1529C0E3C457C32EC | 378 | 15CCF4A57C787B178EC52B8A7A37F2EABFAEE73C4A131D11EC5A4BCE3D0B237A | 448 | CP015_Rustfmt_Check_Gate.txt | CP015_Rustfmt_Check_Gate.txt.zip
3206CFA1FE9A2C01C4E0CD4BD71802396DAA568629C1539E3BC05A48FA1EFD14 | 1038 | 56F455B28E705648C541BD93340B38F63DCE8B5CDCDF09AE289D1D44323F5AFC | 612 | CP015_Rustfmt_Check_Output.txt | CP015_Rustfmt_Check_Output.txt.zip
612149D92F2134601248C07A445CDED7450FF6432B2F2759DC7E87246ADB09C8 | 159 | F1AE44D7BA2CA175D33ACD5E21082780FDB8D31950EE393AEB3D47690C6C1CA6 | 292 | CP015_WASM_Build_Output.txt | CP015_WASM_Build_Output.txt.zip
A59EE780C7AE762C854538A8E04F23740321C3199C9813ED834AB62C5AFAFB5C | 441 | D1EF96C47FEF6A235F32C971C57F0DA8770610398265BCFEDCF894F76F2D0990 | 504 | CP015_WASM_Build_Verification.txt | CP015_WASM_Build_Verification.txt.zip
FE906654A1CECEAA2CA362467676FDED5237B32FBE820E41191A89C6B3892359 | 1442 | 1DEB986AFC09AE198C2E8CAEC4CA9465105750ED5F3863A8AB22358D2076DDA0 | 954 | CP015_PreArchive_Hash_Inventory.txt | CP015_PreArchive_Hash_Inventory.txt.zip
D20E326D3D4331FEFEA255FE165583D487C41DF396B7B87A1E5B2E81A1261A44 | 472 | 1A470981AB5C104BCE986F20B8A501CEFAE63D2E0A2D2A0B2859E96A2380A86D | 527 | CP015_PreArchive_Hash_Verification.txt | CP015_PreArchive_Hash_Verification.txt.zip

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.83s
     Running tests\CP015_scr_rcp_filename_pair_identity.rs (target\debug\deps\CP015_scr_rcp_filename_pair_identity-526d10560ef9b891.exe)

running 6 tests
test refuses_mismatched_utc_timestamp_even_when_both_names_are_canonical ... ok
test refuses_mismatched_uuid_even_when_both_names_are_canonical ... ok
test refuses_paths_and_whitespace_on_either_side ... ok
test accepts_matching_canonical_scr_and_rcp_txt_names ... ok
test refuses_wrong_class_or_reversed_pair_order ... ok
test refuses_wrong_extensions_and_noncanonical_envelopes ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

CP015 POST-COMMIT VERIFICATION - DAY 067
Human acceptance: APPROVED BY T
Previous HEAD: f5038a183f1d3dc31b0065571bf8ac8814b5d8a9
New HEAD: be997dc0dbd65fc370814c4a5f2d0f1254870572
Parent verified: f5038a183f1d3dc31b0065571bf8ac8814b5d8a9
Commit subject: CP015: verify canonical SCR-RCP filename pair identity
Git commit exit code: 0
Committed paths: 18
Expected committed paths: 18
Committed blob identity: 18/18 VERIFIED
Evidence ZIP blobs: 16/16 VERIFIED
Staged whitespace exit: 0
Git index empty: YES
Working tree clean: YES
Original TXT evidence committed: NO
Result: PASS
Day 067: OPEN
Git push: NOT PERFORMED

CP015 PRE-ACCEPTANCE GIT REVIEW - DAY 067
Git HEAD: f5038a183f1d3dc31b0065571bf8ac8814b5d8a9
Git working-tree entries: 18
Expected working-tree entries: 18
Rust source files affected: 2
Evidence ZIP files: 16
Original TXT evidence excluded: YES
Git ZIP filter equivalence: 16/16 PASS
Git whitespace check exit: 0
Git index empty: YES
Result: PASS
T acceptance: PENDING
Git staging: NOT AUTHORIZED
Git banking: NOT AUTHORIZED

WORKING TREE
 M src/lib.rs
?? Evidence/CP-015/ZIP/CP015_Final_Archive_Manifest.txt.zip
?? Evidence/CP-015/ZIP/CP015_Formatting_Amendment_Verification.txt.zip
?? Evidence/CP-015/ZIP/CP015_Full_Regression_Test_Output.txt.zip
?? Evidence/CP-015/ZIP/CP015_Full_Regression_Verification.txt.zip
?? Evidence/CP-015/ZIP/CP015_GREEN_Gate.txt.zip
?? Evidence/CP-015/ZIP/CP015_GREEN_Test_Output.txt.zip
?? Evidence/CP-015/ZIP/CP015_PostAmend_Rustfmt_Output.txt.zip
?? Evidence/CP-015/ZIP/CP015_PostAmend_Test_Output.txt.zip
?? Evidence/CP-015/ZIP/CP015_PreArchive_Hash_Inventory.txt.zip
?? Evidence/CP-015/ZIP/CP015_PreArchive_Hash_Verification.txt.zip
?? Evidence/CP-015/ZIP/CP015_RED_Gate.txt.zip
?? Evidence/CP-015/ZIP/CP015_RED_Test_Output.txt.zip
?? Evidence/CP-015/ZIP/CP015_Rustfmt_Check_Gate.txt.zip
?? Evidence/CP-015/ZIP/CP015_Rustfmt_Check_Output.txt.zip
?? Evidence/CP-015/ZIP/CP015_WASM_Build_Output.txt.zip
?? Evidence/CP-015/ZIP/CP015_WASM_Build_Verification.txt.zip
?? tests/CP015_scr_rcp_filename_pair_identity.rs

RUST SOURCE DIFF
diff --git a/src/lib.rs b/src/lib.rs
index 56916f9..8df0b4a 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -401,3 +401,21 @@ pub fn is_canonical_rcp_filename_candidate(filename: &str) -> bool {
                 && tokens.serialization_extension == "txt"
     )
 }
+
+/// Returns true when canonical SCR and RCP TXT filename candidates
+/// carry the same UTC and UUID identity, in that exact class order.
+///
+/// This is lexical pairing only. It does not inspect files, validate
+/// Receipt contents, promote staged artifacts, publish, or grant authority.
+pub fn is_matching_scr_rcp_filename_candidate_pair(scr_filename: &str, rcp_filename: &str) -> bool {
+    if !is_canonical_scr_filename_candidate(scr_filename)
+        || !is_canonical_rcp_filename_candidate(rcp_filename)
+    {
+        return false;
+    }
+
+    matches!(
+        build_final_filename_candidate_for_scr(scr_filename, "RCP"),
+        Some(expected) if expected == rcp_filename
+    )
+}

CP015 ORIGINAL TXT EVIDENCE INVENTORY - DAY 067
SHA256 | BYTES | FILENAME
B979714A4BB6374C744EBFFB998F4740299941632F79AABB58F7B5BA54C62FA1 | 692 | CP015_Formatting_Amendment_Verification.txt
93555C2705FC4BEFBCBA8EDBD7A0BD697C1E9CD177D17341FE33D1F13201106D | 7656 | CP015_Full_Regression_Test_Output.txt
0DE2E582AD0F69074768E6712597361F05A2DC254CCF149DEBAA6ABD66A27000 | 420 | CP015_Full_Regression_Verification.txt
1D9AC8A037E943F5E44EE603D361254FC48F7BD4C22BF61EB56467D0C238AF35 | 515 | CP015_GREEN_Gate.txt
73A9D713A6DF56531660B5D5022B80D598D55F3F2573F1C22E2EFFCF5B43BC14 | 797 | CP015_GREEN_Test_Output.txt
E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 | 0 | CP015_PostAmend_Rustfmt_Output.txt
CE48864F68FB96D84A592CC7CE1AFDF19A366DC6087517D927FBEA709B5243F2 | 797 | CP015_PostAmend_Test_Output.txt
3CDEAAC9981F9C58F43E21F4D14A8CD62D91F7DCC193616BB75B6F45B3D3CD1E | 345 | CP015_RED_Gate.txt
B6CADEEEEF423B1C4C710F5D12FEC3D2CB5A24D966D4C75E76B3B86D39473A46 | 635 | CP015_RED_Test_Output.txt
FDDCCD9E431D7972238A1BB3DF252185E69D43B08DD499E1529C0E3C457C32EC | 378 | CP015_Rustfmt_Check_Gate.txt
3206CFA1FE9A2C01C4E0CD4BD71802396DAA568629C1539E3BC05A48FA1EFD14 | 1038 | CP015_Rustfmt_Check_Output.txt
612149D92F2134601248C07A445CDED7450FF6432B2F2759DC7E87246ADB09C8 | 159 | CP015_WASM_Build_Output.txt
A59EE780C7AE762C854538A8E04F23740321C3199C9813ED834AB62C5AFAFB5C | 441 | CP015_WASM_Build_Verification.txt

CP015 PRE-ARCHIVE HASH VERIFICATION - DAY 067
Git HEAD: f5038a183f1d3dc31b0065571bf8ac8814b5d8a9
Original TXT files: 13
All original hashes verified: True
Inventory SHA256: FE906654A1CECEAA2CA362467676FDED5237B32FBE820E41191A89C6B3892359
Source SHA256: 538B918B634C5BFB04EFBB2DFE37257515C13094C09B4555820331C2987F9EE7
Test SHA256: A4CA938D0B47E6DAA461C530FB19D7D17EF162D54AF8E69A1F53B7CA1FDDDD31
Result: PASS
ZIP archives created: NO
Git banking: NOT AUTHORIZED

CP015 PRE-FLIGHT - Day 067

=== GIT HEAD ===
f5038a183f1d3dc31b0065571bf8ac8814b5d8a9

Exit code: 0

=== GIT STATUS (empty = clean) ===
Exit code: 0

=== RECENT SOURCE CODE ===
///

/// Extraction does not register a class, approve a serialization format,

/// validate artifact contents, or establish governed authority.

#[derive(Debug, Clone, Copy, PartialEq, Eq)]

pub struct ArtifactFilenameTokens<'a> {

    pub semantic_class: &'a str,

    pub serialization_extension: &'a str,

}



/// Extracts independent class and serialization tokens after envelope validation.

pub fn extract_artifact_filename_tokens(filename: &str) -> Option<ArtifactFilenameTokens<'_>> {

    if !is_canonical_immutable_artifact_filename(filename) {

        return None;

    }



    let rest = filename.strip_prefix("__DS__")?;

    let (semantic_class, rest) = rest.split_once("__")?;

    let (_, rest) = rest.split_once("__")?;

    let (_, serialization_extension) = rest.split_once('.')?;



    Some(ArtifactFilenameTokens {

        semantic_class,

        serialization_extension,

    })

}



/// Constructs a canonical immutable filename candidate from exact input tokens.

///

/// This function performs no case folding, trimming, Unicode normalization,

/// UUID allocation, filesystem operation, or artifact publication.

/// A successful candidate does not establish governed artifact authority.

pub fn build_immutable_artifact_filename_candidate(

    semantic_class: &str,

    utc: &str,

    uuid: &str,

    serialization_extension: &str,

) -> Option<String> {

    let filename = format!("__DS__{semantic_class}__{utc}__{uuid}.{serialization_extension}");



    if is_canonical_immutable_artifact_filename(&filename) {

        Some(filename)

    } else {

        None

    }

}



/// Recognizes a canonical governed CVT CSV SOURCE filename candidate.

///

/// Lexical recognition only. This does not verify physical existence,

/// publication, provenance, encoding, CSV validity, or SOURCE authority.

pub fn is_governed_cvt_source_filename_candidate(filename: &str) -> bool {

    matches!(

        extract_artifact_filename_tokens(filename),

        Some(tokens)

            if tokens.semantic_class == "CVT"

                && tokens.serialization_extension == "csv"

    )

}



/// Derives the SCR staging filename candidate corresponding to a canonical CVT.

///

/// Lexical construction only. This grants no filesystem, conversion,

/// publication, or SOURCE authority.

pub fn build_scr_candidate_filename_for_cvt(filename: &str) -> Option<String> {

    if !is_governed_cvt_source_filename_candidate(filename) {

        return None;

    }



    Some(filename.replacen("__DS__CVT__", "__DS__SCR__", 1))

}



/// Recognizes a canonical SCR staging filename candidate.

///

/// Lexical recognition only. This does not verify file existence,

/// contents, intended final class, publication, or authority.

pub fn is_canonical_scr_filename_candidate(filename: &str) -> bool {

    if filename

        .chars()

        .any(|ch| ch.is_whitespace() || ch == '/' || ch == '\\')

    {

        return false;

    }



    matches!(

        extract_artifact_filename_tokens(filename),

        Some(tokens) if tokens.semantic_class == "SCR"

    )

}



/// Derives a canonical RCP final filename candidate from an SCR staging name.

///

/// The intended final class must be supplied explicitly. This function only

/// constructs a lexical candidate; it does not validate contents, perform

/// filesystem operations, promote staged files, publish, or grant authority.

pub fn build_final_filename_candidate_for_scr(

    scr_filename: &str,

    intended_final_class: &str,

) -> Option<String> {

    if intended_final_class != "RCP" || !is_canonical_scr_filename_candidate(scr_filename) {

        return None;

    }



    let tokens = extract_artifact_filename_tokens(scr_filename)?;



    if tokens.serialization_extension != "txt" {

        return None;

    }



    Some(scr_filename.replacen("__DS__SCR__", "__DS__RCP__", 1))

}



/// Recognizes a canonical RCP Receipt filename candidate.

///

/// Lexical recognition only. This does not verify Receipt contents,

/// filesystem state, staging promotion, publication, or authority.

pub fn is_canonical_rcp_filename_candidate(filename: &str) -> bool {

    if filename

        .chars()

        .any(|ch| ch.is_whitespace() || ch == '/' || ch == '\\')

    {

        return false;

    }



    matches!(

        extract_artifact_filename_tokens(filename),

        Some(tokens)

            if tokens.semantic_class == "RCP"

                && tokens.serialization_extension == "txt"

    )

}


=== CP014 TESTS ===
// CP014 RED tests - Day 067

// Frozen anchors: W002-RCP-002, W002-STOR-023, W002-STOR-023.1.

// Lexical RCP filename recognition only.

// No content validation, filesystem activity, promotion, or authority.



use data_sculptor_core::{

    build_final_filename_candidate_for_scr, is_canonical_rcp_filename_candidate,

};



const RCP: &str = "__DS__RCP__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.txt";



const SCR: &str = "__DS__SCR__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.txt";



#[test]

fn accepts_canonical_rcp_txt_identity() {

    assert!(is_canonical_rcp_filename_candidate(RCP));



    assert!(is_canonical_rcp_filename_candidate(

        "__DS__RCP__20261013T173300000Z__123e4567-e89b-42d3-a456-426614174000.txt"

    ));

}



#[test]

fn recognizes_existing_scr_to_rcp_derivation() {

    let candidate = build_final_filename_candidate_for_scr(SCR, "RCP")

        .expect("CP013 should derive an RCP candidate");



    assert_eq!(candidate, RCP);

    assert!(is_canonical_rcp_filename_candidate(&candidate));

    assert!(!is_canonical_rcp_filename_candidate(SCR));

}



#[test]

fn refuses_wrong_semantic_class_and_case() {

    for filename in [

        RCP.replace("__DS__RCP__", "__DS__SCR__"),

        RCP.replace("__DS__RCP__", "__DS__CVT__"),

        RCP.replace("__DS__RCP__", "__DS__rcp__"),

        RCP.replace("__DS__RCP__", "__DS__Rcp__"),

        RCP.replace("__DS__RCP__", "__DS__RCV__"),

    ] {

        assert!(!is_canonical_rcp_filename_candidate(&filename));

    }

}



#[test]

fn refuses_noncanonical_serialization() {

    for filename in [

        RCP.replace(".txt", ".csv"),

        RCP.replace(".txt", ".TXT"),

        RCP.replace(".txt", ".html"),

        RCP.replace(".txt", ".txt.gz"),

        RCP.replace(".txt", "."),

        RCP.replace(".txt", ""),

    ] {

        assert!(!is_canonical_rcp_filename_candidate(&filename));

    }

}



#[test]

fn refuses_invalid_timestamp_uuid_and_envelope() {

    for filename in [

        RCP.replace("20261014", "20260230"),

        RCP.replace("T011203456Z", "T251203456Z"),

        RCP.replace("-41d4-", "-51d4-"),

        RCP.replace("-a716-", "-1716-"),

        RCP.replacen("__DS__", "__ds__", 1),

        "ordinary.txt".to_string(),

    ] {

        assert!(!is_canonical_rcp_filename_candidate(&filename));

    }

}



#[test]

fn refuses_paths_and_whitespace() {

    for filename in [

        format!("folder/{RCP}"),

        format!("folder\\{RCP}"),

        format!(" {RCP}"),

        format!("{RCP} "),

        format!("{RCP}\n"),

        format!("{RCP}\t"),

    ] {

        assert!(!is_canonical_rcp_filename_candidate(&filename));

    }

}

CP015 RED GATE - DAY 067
Git HEAD: f5038a183f1d3dc31b0065571bf8ac8814b5d8a9
Installed test SHA256: 63F63780F57A5A28238470C992CE3E3DABF47B8441732AE5E9F2F2424C07019F
Cargo exit code: 101
Unresolved import observed: True
Expected function referenced: True
Result: EXPECTED_RED
Implementation source changed: NO
Git banking: NOT AUTHORIZED

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
error[E0432]: unresolved import `data_sculptor_core::is_matching_scr_rcp_filename_candidate_pair`
 --> tests\CP015_scr_rcp_filename_pair_identity.rs:7:5
  |
7 | use data_sculptor_core::is_matching_scr_rcp_filename_candidate_pair;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `is_matching_scr_rcp_filename_candidate_pair` in the root

For more information about this error, try `rustc --explain E0432`.
error: could not compile `data_sculptor_core` (test "CP015_scr_rcp_filename_pair_identity") due to 1 previous error

CP015 RUSTFMT CHECK - DAY 067
Git HEAD: f5038a183f1d3dc31b0065571bf8ac8814b5d8a9
Rustfmt exit code: 1
Source SHA256: 31BE10641994ABA3D339C2A67773780F065162FBE0335C18D36D42E0213C2BA7
Test SHA256: 63F63780F57A5A28238470C992CE3E3DABF47B8441732AE5E9F2F2424C07019F
Hashes unchanged: True
Result: REVIEW_REQUIRED
Source modified by this check: NO
Git banking: NOT AUTHORIZED

Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\src\lib.rs:407:
 ///
 /// This is lexical pairing only. It does not inspect files, validate
 /// Receipt contents, promote staged artifacts, publish, or grant authority.
-pub fn is_matching_scr_rcp_filename_candidate_pair(
-    scr_filename: &str,
-    rcp_filename: &str,
-) -> bool {
+pub fn is_matching_scr_rcp_filename_candidate_pair(scr_filename: &str, rcp_filename: &str) -> bool {
     if !is_canonical_scr_filename_candidate(scr_filename)
         || !is_canonical_rcp_filename_candidate(rcp_filename)
     {
Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP015_scr_rcp_filename_pair_identity.rs:20:
     let other_rcp = RCP.replace("20261014T011203456Z", "20261013T173300000Z");
     let other_rcp = other_rcp.replace(UUID, OTHER_UUID);
     assert!(is_matching_scr_rcp_filename_candidate_pair(
-        &other_scr,
-        &other_rcp
+        &other_scr, &other_rcp
     ));
 }
 

CP015 STAGED GIT VERIFICATION - DAY 067
Git baseline HEAD: f5038a183f1d3dc31b0065571bf8ac8814b5d8a9
Human acceptance: APPROVED BY T
Staged paths: 18
Expected staged paths: 18
Rust files: 2
Evidence ZIPs: 16
Staged blob equivalence: 18/18 VERIFIED
Staged whitespace exit: 0
Unstaged tracked changes: 0
Original TXT evidence staged: NO
Source SHA256: 538B918B634C5BFB04EFBB2DFE37257515C13094C09B4555820331C2987F9EE7
Test SHA256: A4CA938D0B47E6DAA461C530FB19D7D17EF162D54AF8E69A1F53B7CA1FDDDD31
Manifest SHA256: C998B6DB8C833DD8CE9DD10DBFBCE50067695FEC51D76FD143DF39568AAC1BDB
Manifest ZIP SHA256: 6083DAB41FFE75172F7AA06ACFD788511C7AD8C80E6FE470B78065CF7526028B
Result: PASS
Git commit performed: NO
Commit pending staged review: YES

STAGED OBJECTS
8df0b4a5eca89f0a42d19db2dcf9ee8fe18d1a40 | src/lib.rs | VERIFIED
378274dfa3f1ce04bfb4ea7f822c861657d74624 | tests/CP015_scr_rcp_filename_pair_identity.rs | VERIFIED
e9a7ec36e666fd81ba2e2e89b3c39b2ab73c3314 | Evidence/CP-015/ZIP/CP015_Formatting_Amendment_Verification.txt.zip | VERIFIED
439a705b86e5bb6d347950773623c44d95d08b1f | Evidence/CP-015/ZIP/CP015_Full_Regression_Test_Output.txt.zip | VERIFIED
4290089fc2fea68961083be7817083eaa53ab3c2 | Evidence/CP-015/ZIP/CP015_Full_Regression_Verification.txt.zip | VERIFIED
76b31cc9255cc680846c6d99dd05b4f706c3efba | Evidence/CP-015/ZIP/CP015_GREEN_Gate.txt.zip | VERIFIED
d2c91f50c9ff90cfc8b289f6c3d16f6136c0a051 | Evidence/CP-015/ZIP/CP015_GREEN_Test_Output.txt.zip | VERIFIED
ef44dd3089858440bf96e9b6eb7685bf71c6dd46 | Evidence/CP-015/ZIP/CP015_PostAmend_Rustfmt_Output.txt.zip | VERIFIED
8113e058360eb56758a4db13ba5486ea51782ade | Evidence/CP-015/ZIP/CP015_PostAmend_Test_Output.txt.zip | VERIFIED
d867846a458e32adbf345c07f83dbd22c8746b6f | Evidence/CP-015/ZIP/CP015_RED_Gate.txt.zip | VERIFIED
7760a0634a9f942ccc86c9acac78ddc2d368fddf | Evidence/CP-015/ZIP/CP015_RED_Test_Output.txt.zip | VERIFIED
fa2c5f693e158c8ae50f93a7b5628c2845aa28d6 | Evidence/CP-015/ZIP/CP015_Rustfmt_Check_Gate.txt.zip | VERIFIED
946807f1782fba86f73bf18f7bc9ed6a3c13ab0f | Evidence/CP-015/ZIP/CP015_Rustfmt_Check_Output.txt.zip | VERIFIED
fea63c19dcfc9024b9aff604c50438465e4485d6 | Evidence/CP-015/ZIP/CP015_WASM_Build_Output.txt.zip | VERIFIED
eda75631f95f65e87148ace3352309693cdba609 | Evidence/CP-015/ZIP/CP015_WASM_Build_Verification.txt.zip | VERIFIED
f2040eb5ecbf42da44a8fe5ed41495e88ac9bbf5 | Evidence/CP-015/ZIP/CP015_PreArchive_Hash_Inventory.txt.zip | VERIFIED
ce5b75e7ee64fcd470475929c703864a433dda6c | Evidence/CP-015/ZIP/CP015_PreArchive_Hash_Verification.txt.zip | VERIFIED
1c4ed67614823082590a209de0eaba43ae3c0b18 | Evidence/CP-015/ZIP/CP015_Final_Archive_Manifest.txt.zip | VERIFIED

GIT STATUS
A  Evidence/CP-015/ZIP/CP015_Final_Archive_Manifest.txt.zip
A  Evidence/CP-015/ZIP/CP015_Formatting_Amendment_Verification.txt.zip
A  Evidence/CP-015/ZIP/CP015_Full_Regression_Test_Output.txt.zip
A  Evidence/CP-015/ZIP/CP015_Full_Regression_Verification.txt.zip
A  Evidence/CP-015/ZIP/CP015_GREEN_Gate.txt.zip
A  Evidence/CP-015/ZIP/CP015_GREEN_Test_Output.txt.zip
A  Evidence/CP-015/ZIP/CP015_PostAmend_Rustfmt_Output.txt.zip
A  Evidence/CP-015/ZIP/CP015_PostAmend_Test_Output.txt.zip
A  Evidence/CP-015/ZIP/CP015_PreArchive_Hash_Inventory.txt.zip
A  Evidence/CP-015/ZIP/CP015_PreArchive_Hash_Verification.txt.zip
A  Evidence/CP-015/ZIP/CP015_RED_Gate.txt.zip
A  Evidence/CP-015/ZIP/CP015_RED_Test_Output.txt.zip
A  Evidence/CP-015/ZIP/CP015_Rustfmt_Check_Gate.txt.zip
A  Evidence/CP-015/ZIP/CP015_Rustfmt_Check_Output.txt.zip
A  Evidence/CP-015/ZIP/CP015_WASM_Build_Output.txt.zip
A  Evidence/CP-015/ZIP/CP015_WASM_Build_Verification.txt.zip
M  src/lib.rs
A  tests/CP015_scr_rcp_filename_pair_identity.rs

STAGED RUST DIFF
diff --git a/src/lib.rs b/src/lib.rs
index 56916f9..8df0b4a 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -401,3 +401,21 @@ pub fn is_canonical_rcp_filename_candidate(filename: &str) -> bool {
                 && tokens.serialization_extension == "txt"
     )
 }
+
+/// Returns true when canonical SCR and RCP TXT filename candidates
+/// carry the same UTC and UUID identity, in that exact class order.
+///
+/// This is lexical pairing only. It does not inspect files, validate
+/// Receipt contents, promote staged artifacts, publish, or grant authority.
+pub fn is_matching_scr_rcp_filename_candidate_pair(scr_filename: &str, rcp_filename: &str) -> bool {
+    if !is_canonical_scr_filename_candidate(scr_filename)
+        || !is_canonical_rcp_filename_candidate(rcp_filename)
+    {
+        return false;
+    }
+
+    matches!(
+        build_final_filename_candidate_for_scr(scr_filename, "RCP"),
+        Some(expected) if expected == rcp_filename
+    )
+}
diff --git a/tests/CP015_scr_rcp_filename_pair_identity.rs b/tests/CP015_scr_rcp_filename_pair_identity.rs
new file mode 100644
index 0000000..378274d
--- /dev/null
+++ b/tests/CP015_scr_rcp_filename_pair_identity.rs
@@ -0,0 +1,86 @@
+// CP015 RED tests - Day 067 (2026-10-14)
+// T-approved scope: pure lexical SCR/RCP filename-candidate pairing.
+// Frozen anchors: W002-STOR-023.1 and W002-RCP-002.
+// No file reads/writes, Receipt-content validation, promotion, or authority.
+// This file is the test-first gate; preserve its original SHA-256.
+
+use data_sculptor_core::is_matching_scr_rcp_filename_candidate_pair;
+
+const SCR: &str = "__DS__SCR__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.txt";
+const RCP: &str = "__DS__RCP__20261014T011203456Z__550e8400-e29b-41d4-a716-446655440000.txt";
+const UUID: &str = "550e8400-e29b-41d4-a716-446655440000";
+const OTHER_UUID: &str = "123e4567-e89b-42d3-a456-426614174000";
+
+#[test]
+fn accepts_matching_canonical_scr_and_rcp_txt_names() {
+    assert!(is_matching_scr_rcp_filename_candidate_pair(SCR, RCP));
+
+    let other_scr = SCR.replace("20261014T011203456Z", "20261013T173300000Z");
+    let other_scr = other_scr.replace(UUID, OTHER_UUID);
+    let other_rcp = RCP.replace("20261014T011203456Z", "20261013T173300000Z");
+    let other_rcp = other_rcp.replace(UUID, OTHER_UUID);
+    assert!(is_matching_scr_rcp_filename_candidate_pair(
+        &other_scr, &other_rcp
+    ));
+}
+
+#[test]
+fn refuses_mismatched_utc_timestamp_even_when_both_names_are_canonical() {
+    let different_rcp = RCP.replace("20261014T011203456Z", "20261014T011203457Z");
+    assert!(!is_matching_scr_rcp_filename_candidate_pair(
+        SCR,
+        &different_rcp
+    ));
+}
+
+#[test]
+fn refuses_mismatched_uuid_even_when_both_names_are_canonical() {
+    let different_rcp = RCP.replace(UUID, OTHER_UUID);
+    assert!(!is_matching_scr_rcp_filename_candidate_pair(
+        SCR,
+        &different_rcp
+    ));
+}
+
+#[test]
+fn refuses_wrong_class_or_reversed_pair_order() {
+    for (scr, rcp) in [
+        (RCP.to_owned(), SCR.to_owned()),
+        (SCR.to_owned(), SCR.to_owned()),
+        (RCP.to_owned(), RCP.to_owned()),
+        (SCR.to_owned(), RCP.replace("__DS__RCP__", "__DS__CVT__")),
+        (SCR.replace("__DS__SCR__", "__DS__CVT__"), RCP.to_owned()),
+        (SCR.replace("__DS__SCR__", "__DS__scr__"), RCP.to_owned()),
+    ] {
+        assert!(!is_matching_scr_rcp_filename_candidate_pair(&scr, &rcp));
+    }
+}
+
+#[test]
+fn refuses_wrong_extensions_and_noncanonical_envelopes() {
+    for (scr, rcp) in [
+        (SCR.replace(".txt", ".csv"), RCP.to_owned()),
+        (SCR.to_owned(), RCP.replace(".txt", ".TXT")),
+        (SCR.to_owned(), RCP.replace(".txt", ".txt.gz")),
+        (SCR.replace("20261014", "20260230"), RCP.to_owned()),
+        (SCR.to_owned(), RCP.replace("-41d4-", "-51d4-")),
+        (SCR.to_owned(), "ordinary.txt".to_owned()),
+    ] {
+        assert!(!is_matching_scr_rcp_filename_candidate_pair(&scr, &rcp));
+    }
+}
+
+#[test]
+fn refuses_paths_and_whitespace_on_either_side() {
+    for (scr, rcp) in [
+        (format!("folder/{SCR}"), RCP.to_owned()),
+        (SCR.to_owned(), format!("folder\\{RCP}")),
+        (format!(" {SCR}"), RCP.to_owned()),
+        (SCR.to_owned(), format!("{RCP} ")),
+        (format!("{SCR}\n"), RCP.to_owned()),
+        (SCR.to_owned(), format!("{RCP}\t")),
+        (SCR.to_owned(), format!("{RCP}\u{00A0}")),
+    ] {
+        assert!(!is_matching_scr_rcp_filename_candidate_pair(&scr, &rcp));
+    }
+}

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.98s

CP015 CANONICAL WASM BUILD - DAY 067
Git HEAD: f5038a183f1d3dc31b0065571bf8ac8814b5d8a9
Toolchain: Rust 1.97.1
Target: wasm32-unknown-unknown
Build scope: --lib
Cargo exit code: 0
Source SHA256: 538B918B634C5BFB04EFBB2DFE37257515C13094C09B4555820331C2987F9EE7
Test SHA256: A4CA938D0B47E6DAA461C530FB19D7D17EF162D54AF8E69A1F53B7CA1FDDDD31
Hashes unchanged: True
Result: PASS
Browser runtime tested: NO
Git banking: NOT AUTHORIZED

requirement_id,title,family,major_family,scope,source_prd_status,source_build_flag,requirement_text,implementation_state,local_verification,independent_qa,requirement_acceptance,linked_checkpoints,checkpoint_disposition,git_commits,test_evidence,implementation_notes,last_evidence_day,source_revision
PB-STOR-001,Suitcase is the complete Data Sculptor-controlled persistence surface,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Every persistent project or analytical artifact intentionally created by Data Sculptor must be written into the visible, user-controlled Suitcase. Data Sculptor must not intentionally persist user data, analytical state, scratch state, logs, recovery state, or project metadata in hidden AppData-style locations or browser-private persistence such as OPFS. Incidental browser/OS runtime caches outside Data Sculptor control are explicitly outside this contract. F-24 browser-session persistence boundary: WASM-002 must not use IndexedDB, localStorage , OPFS, another browser-private database, or an equivalent hidden Data Sculptor-controlled persistence surface to remember a Suitcase directory handle, unsaved WIP text, project truth, analytical state, or live UI preferences between application instances. A later build may deliberately define a user-visible preferences or continuity mechanism, but WASM-002 does not create one implicitly. Volatile in-memory runtime state within the current application instance is permitted.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-002,No Data Sculptor-created subfolders,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor does not create scratch/cache subfolders inside the Suitcase. Logical organization is expressed by the flat filename grammar, open metadata, Store MAP, and human-facing aliases.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-004,__DS__ is the reserved Data Sculptor governed namespace,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Every artifact that Data Sculptor creates or intentionally interprets as one of its governed artifacts must use the exact visible prefix __DS__ . The prefix identifies participation in the Data Sculptor namespace; it does not imply that the artifact is temporary, scratch-only, or automatically generated.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-001,BANKED; separate requirement acceptance not claimed,03201870b8ec68730a0c027c572db03ccd5eeaa8,Evidence/CP-001/CP001_GREEN2_Test_Output.txt; Evidence/CP-001/CP001_WASM_Build_Output.txt,"CP001: bounded lexical artifact-class recognition via reserved_artifact_class(). Five native tests passed and Rust wasm32-target library built. No content/provenance/authority validation, persistence, or complete governed artifact contract implemented.",Day063,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-005,External inputs retain their identity; Data Sculptor derivatives enter the namespace,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"An analyst or external source file must not be renamed into __DS__ merely because Data Sculptor reads, fingerprints, certifies, or references it. If Data Sculptor creates a new governed derivative—such as an explicit converted source—the new artifact enters the __DS__ namespace under its semantic class. F-26 SOURCE boundary: a Suitcase-root file whose exact filename begins with the reserved prefix __DS__ is not treated as an analyst-owned source merely because it has a CSV-like extension or CSV-like bytes. It participates in the reserved Data Sculptor namespace and must satisfy the applicable governed-artifact contract before any governed role is granted.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-002,"T-ACCEPTED, BANKED; requirement remains partial",206dcd8b76af29edcb658a0c5a2dc40d87089fe3,Evidence/CP-002/CP002_Post_Format_Test_Output.txt; Evidence/CP-002/CP002_Post_Format_WASM_Build_Output.txt; Evidence/CP-002/CP002_Hash_Inventory_Verification.txt,CP002: exact __DS__ lexical prefix recognition via has_reserved_namespace_prefix(). Six native tests and wasm32-target compilation passed. The SOURCE boundary and governed CVT validation/emission rules in this requirement are NOT implemented.,Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-006,The governed semantic artifact-class registry is explicit and stable,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The token immediately following __DS__ must be an exact three-uppercase-letter semantic artifact class. The governed class tokens currently reserved by this PRD are: Class Meaning WKO Work Order RCP Receipt DGN Diagnostic Event — reserved; not emitted by WASM-002 HLP Help Report CER Certification Evidence CVT Converted Source RID Row Identity COL Materialized Column MAP Governed MAP artifact class — Store MAP and WKO MAP profiles CAT Store Catalog — collection-level orientation index across MAP-governed Stores INV Suitcase Inventory Snapshot SCR Scratch / Structural Support RCV Recovery Artifact — reserved; not emitted by WASM-002 BRD Brand Manifest — reserved; not emitted by WASM-002 LCK Suitcase Lock — reserved for the explicit later-V1 FINGERPRINT workflow; not emitted or maintained by ordinary WASM-002 WASM-002 emission boundary. DGN , RCV , BRD , and LCK are registered/reserved classes but are not emitted by WASM-002. Registration alone does not create a producer, serialization contract, validity contract, lifecycle, or acceptance surface. A later build that activates one of these classes must define those contracts explicitly before the class becomes emitted product behavior. The class states semantic role rather than serialization format. WIP is not an artifact class; it is the editable non-executable Work Order lifecycle state. The Flight Recorder defined by W002-STOR-012 is a derived chronological view of governed RCP artifacts and is not an additional semantic artifact class. Existing class tokens must not be silently reassigned to different meanings. A new class requires an explicit PRD revision.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-001; CP-003,CP-001 banked; CP-003 T-accepted and banked; requirement remains partial,03201870b8ec68730a0c027c572db03ccd5eeaa8; 2d06f6259de93f5beaa8eb15f8f22f171127a10e,Evidence/CP-001/CP001_GREEN2_Test_Output.txt; Evidence/CP-001/CP001_WASM_Build_Output.txt; Evidence/CP-003/CP003_Post_Format_Test_Output.txt,"CP001: bounded lexical artifact-class recognition via reserved_artifact_class(). Five native tests passed and Rust wasm32-target library built. No content/provenance/authority validation, persistence, or complete governed artifact contract implemented. CP003 adds locally verified lexical distinction between the 11 emittable-class tokens and four registered-but-not-emitted tokens; full governance/producer behavior not implemented.",Day063,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-007,Serialization is orthogonal to artifact class,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Filename extensions such as .toml , .html , .csv , .bin , and .txt describe physical serialization only and must not be used as semantic artifact classes. A governed HLP serialized as .html remains an HLP, and a governed WKO serialized as .txt remains a WKO. Any future BRD serialization must obey the same class-versus-format separation, but its format is not frozen by WASM-002.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-006,"T-ACCEPTED, BANKED; full class-specific serialization and authority contracts remain open",aff54d08dcbacaa0c54d8869749344a504c5ad61,Evidence/CP-006/CP006_RED_Test_Output.txt; Evidence/CP-006/CP006_Post_Format_Test_Output.txt; Evidence/CP-006/CP006_WASM_Build_Output.txt; Evidence/CP-006/CP006_Hash_Inventory_Verification.txt; Evidence/CP-006/CP006_Precommit_Git_Review.txt,"CP006: public ArtifactFilenameTokens and extract_artifact_filename_tokens() reuse the CP004/CP005 immutable filename validator and extract semantic_class and serialization_extension as separate borrowed lexical fields. Four new tests, total 19/19 native tests post-format; wasm32-target compilation exit 0; 20-file pre-verification SHA-256 inventory independently matched. Literal unknown class and extension values preserved without registration or approval. No class-specific extension allowlist, format contract, file contents, provenance, governed publication, trust, or authority implemented. T accepted CP006 and banked commit aff54d08dcbacaa0c54d8869749344a504c5ad61; independent Claude implementation QA remains pending. This is requirement PARTIAL, not fully closed.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-008,Namespace and class do not confer authority by themselves,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Renaming an arbitrary file to resemble a __DS__ artifact must not make it authoritative. Before treating a governed artifact as valid, Data Sculptor must validate the applicable filename grammar plus the content, provenance, fingerprint, lineage, or other evidence required by that artifact's contract. F-14/F-33 publication distinction: SCR-to-final promotion under W002-STOR-023 proves only that the artifact satisfied its class-specific publication predicate. It does not manufacture broader authority. In particular, WKO alias authority still comes from the committed WKO MAP, Store authority comes from the committed Store MAP, and CAT is orientation only. Retained SCR failure evidence remains non-authoritative, and the reserved RCV class is not emitted by WASM-002. F-26 SOURCE authority: a governed CVT is eligible as a WASM-002 SOURCE only when its exact canonical CVT identity and the publication predicate governed by W002-CONV-004 and W002-STOR-023 are satisfied. Filename resemblance, a .csv extension, or copied bytes alone do not confer CVT source authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,Cross-cutting constraint recognized in CP001/CP002 scope: filenames/classes alone convey no artifact authority. This requirement is NOT claimed implemented or touched.,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-009,Unknown and known-but-not-emitted Data Sculptor classes are preserved and reported,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"If WASM-002 encounters a syntactically valid __DS__ artifact whose three-letter semantic class is not allocated in the current registry, or whose class is a registered-but-not-emitted WASM-002 class ( DGN , RCV , BRD , or LCK ), Data Sculptor must preserve the physical file unchanged. It must not trust, execute, mutate, delete, rename, or reinterpret that file as a known emitted artifact merely because the filename has governed form. Unknown class does not mean invalid data; it means this build has no authority to interpret that class. A known-but-not-emitted class is likewise not an instruction to activate a dormant producer or lifecycle. Whenever a WASM-002 operation performs the governed Suitcase scan/enumeration relevant to such a file, the condition must be surfaced through a canonical INFO diagnostic rather than being silently ignored. INVENTORY must include the physical file under its existing metadata-only contract; if an existing classification field is rendered, an unknown class is identified as unknown/unrecognized and a known-but-not-emitted class is identified as reserved/not emitted without guessing additional semantics. F-33 adds no new Inventory schema field and does not pull the governed DIR feature into WASM-002.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-003,"T-ACCEPTED, BANKED; full preservation/INFO requirement not closed",2d06f6259de93f5beaa8eb15f8f22f171127a10e,Evidence/CP-003/CP003_Post_Format_Test_Output.txt; Evidence/CP-003/CP003_WASM_Build_Output.txt; Evidence/CP-003/CP003_Hash_Inventory_Verification.txt,"CP003: token-only Rust classify_artifact_class_token() returns registered/emittable, registered/not-emitted, unallocated, malformed-reserved, or outside-reserved disposition. Three new tests (27 cases) plus six prior regression tests passed, wasm32 compilation exit 0, 15-file historic SHA-256 inventory verified. No Suitcase scan, filesystem preservation, canonical INFO diagnostic, INVENTORY integration, full filename validity, or artifact authority implemented. RegisteredEmittable describes a class category; it does not authorize emission. Independent Claude QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-010,Namespace and class casing are canonical and exact,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor-generated names must use exact uppercase __DS__ and exact uppercase three-letter class tokens. Data Sculptor must not silently normalize variant namespace/class spellings into canonical governed artifacts. This rule applies even on case-insensitive filesystems. F-15 governed comparison rule: unless a requirement explicitly defines a different domain-specific comparison, WASM-002 semantic equality and textual reference resolution compare decoded strings by exact Unicode scalar-value sequence. Data Sculptor performs no case folding, locale folding, Unicode normalization, trimming, or host-filesystem equivalence before the comparison. Thus differently cased strings and canonically equivalent-but-differently-encoded Unicode strings remain distinct governed values. If a host filesystem cannot safely publish two physical names that the governed semantics distinguish, publication must refuse rather than merge or reinterpret the governed identities.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-007; CP-009; CP-010,"T-ACCEPTED, BANKED; exact lexical construction verified; full normative requirement remains partial; CP009 T-ACCEPTED, BANKED — pure exact-name root snapshot matching only; full requirement remains partial; CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open",3c512df519f3a2431b363e4c57dc234c02378124; dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8; b7c515faa9bd000369d7656e09437310261290ae,Evidence/CP-007/CP007_RED_Test_Output.txt; Evidence/CP-007/CP007_GREEN_Test_Output.txt; Evidence/CP-007/CP007_Post_Format_Test_Output.txt; Evidence/CP-007/CP007_WASM_Build_Output.txt; Evidence/CP-007/CP007_Hash_Inventory_Verification.txt; Evidence/CP-007/CP007_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Baseline_Test_Output.txt; Evidence/CP-009/CP009_RED_Test_Output.txt; Evidence/CP-009/CP009_GREEN_Test_Output.txt; Evidence/CP-009/CP009_Full_Regression_Test_Output.txt; Evidence/CP-009/CP009_Rustfmt_Check_Output.txt; Evidence/CP-009/CP009_Git_Whitespace_Check.txt; Evidence/CP-009/CP009_Post_Format_Test_Output.txt; Evidence/CP-009/CP009_WASM_Build_Output.txt; Evidence/CP-009/CP009_Hash_Inventory.txt; Evidence/CP-009/CP009_Hash_Inventory_Verification.txt; Evidence/CP-009/CP009_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Final_Staging_Review.txt; CP009_Git_Banking_Output.txt (separately archived post-commit evidence); Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived),"CP007: public build_immutable_artifact_filename_candidate() assembles exact class, UTC timestamp, UUID v4 and serialization extension tokens into an ordinary canonical immutable filename candidate; it delegates validation to the existing CP004/CP005 envelope validator and refuses malformed casing/identities rather than case-folding, trimming or normalizing input. Four new integration tests, total 23/23 native tests after Rustfmt; wasm32-target compilation exit 0; 21-entry SHA-256+byte inventory independently verified. Lexically valid unknown class tokens and unapproved extension tokens may be preserved as candidates; this grants no registration, serialization contract, authority, filesystem publication or content/provenance validation. The F-15 exact Unicode scalar-value semantic equality and host-filesystem collision/refusal requirements are NOT implemented. T approved and banked commit 3c512df519f3a2431b363e4c57dc234c02378124 (14 files), clean master; independent Claude adversarial implementation QA pending. Requirement remains PARTIAL, not fully closed. CP009 Day066: match_analyst_csv_root_snapshot(&str, &[RootSnapshotEntry]) -> RootSnapshotMatch applies CP008 analyst CSV candidate preflight, then exact Rust string equality (case, Unicode scalar sequence and whitespace preserved), reports no match, reported nonregular entry, ambiguous duplicate exact entries, or single caller-reported regular file. Entry origin and kind are caller assertions, not independently verified. Eight new tests; post-format full native regression 36/36; wasm32-unknown-unknown library compilation exit 0; SHA-256 inventory verified 22/22; staged whitespace exit 0; T approved and git banked 15 files, clean working tree. This is NOT actual root scanning, filesystem entry proof, browser permission, CSV/UTF-8 certification, governed CVT SOURCE eligibility or end-to-end requirement acceptance; independent Claude QA pending. CP010 Day066 also tests canonical uppercase __DS__/CVT tokens and exact lowercase .csv conversion-output extension, refusing variant prefix/class/extension spellings; existing canonical validator is reused without repair or normalization. Only lexical form is locally verified: no actual filesystem identity enforcement or publication collision handling. T accepted CP010; git b7c515faa9bd000369d7656e09437310261290ae; independent QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-011,Generated identity collisions regenerate the UUID and never overwrite,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor must never overwrite, rename, truncate, or mutate an existing artifact merely because a newly generated governed filename collides with it. For an ordinary immutable artifact using the governed UTC+UUID identity grammar, Data Sculptor must keep the originally established canonical UTC millisecond creation timestamp, generate a new canonical lowercase hyphenated UUID v4, reconstruct the candidate filename, and try creation again. Collision retry must not advance or falsify the artifact creation timestamp merely to obtain a different sort position. This retry may repeat until an unused valid identity is obtained. If UUID generation fails, the host cannot safely test/create the target, or another filesystem error prevents safe allocation, creation must refuse through the canonical diagnostic path rather than risk overwrite. Collision retry changes only the not-yet-created artifact's UUID. UUID is never used as a chronology field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-012,Names route; governed contents and provenance prove,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The filename must help humans and Data Sculptor identify the artifact's intended semantic role and route it to the correct validator. The artifact's governed content, lineage, receipt, fingerprint, provenance, and other required evidence establish what is actually true.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-013,Ordinary immutable governed artifacts use class → UTC millisecond → UUID v4 identity order,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The exact default filename grammar for an ordinary immutable Data Sculptor-governed artifact is: __DS__CCC__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.<extension> CCC is the governed semantic artifact class. YYYYMMDDTHHMMSSmmmZ is the artifact's governed UTC creation/publication timestamp at millisecond precision: four-digit year, two-digit month/day/hour/minute/second, exactly three millisecond digits, and literal T / Z . <uuid-v4> is a canonical lowercase hyphenated UUID v4. The extension is governed by the artifact's serialization contract. The token order is normative: namespace, semantic class, UTC timestamp, UUID, extension. UTC precedes UUID for every ordinary immutable class. Canonical UTC tokens with different values sort chronologically within the same class. UUID provides uniqueness and physical identity only; it must not be interpreted as a chronology tie-breaker when two artifacts share the same timestamp. When one governed all-or-refuse Store-state publication transaction creates multiple new analytical state artifacts, Data Sculptor establishes one canonical UTC millisecond publication-transaction timestamp before final identity allocation and uses that same UTC token for every newly published RID , COL , and MAP artifact created by that transaction. Each artifact receives its own UUID. Thus a first Store materialization gives the new RID, every newly materialized COL, and the successor MAP one shared transaction UTC; a later materialization gives only its newly created COL artifacts and successor MAP the new transaction UTC while the inherited RID and inherited COL artifacts retain their earlier identities. The shared transaction UTC is not the Work Order's authoring timestamp and does not require the Receipt filename UTC to match. RCP remains governed by W002-RCP-002 and carries its own receipt creation/publication timestamp. A shared transaction UTC expresses common publication membership, but MAP binding—not timestamp equality—remains authoritative for Store membership/current state. Source identity, source filename, run identity, parent identity, lineage, hashes, aliases, supersession, column identity, and other relationships must not be appended as ordinary identity tokens merely to make the filename descriptive; those facts belong in governed metadata and provenance. P2-03 successor-state UTC rule: when an operation will publish a successor Store MAP or successor WKO MAP, the transaction UTC remains a truthful observation of host UTC and must be strictly greater than the applicable chronology predecessor MAP UTC. Data Sculptor must not synthesize, increment, round forward, or otherwise fabricate a later UTC merely to satisfy chronology. UUID remains identity only and is never a chronology tie-breaker. The first MAP in a genuinely new Store lineage, and the first WKO MAP when no structurally valid WKO MAP exists, has no chronology predecessor and therefore uses the observed host UTC normally.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Immutable filename envelope, UTC and UUID syntax only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. Full requirement also governs true UTC millisecond identity, creation chronology, publication timestamp sharing, UUID identity semantics, and successor MAP chronology; none are implemented in CP004. Independent QA pending. CP005: CP005 now validates the timestamp token as a real Gregorian calendar date and ordinary UTC clock time (four-digit years 0001–9999, leap years, month lengths, 00–23 hours, 00–59 minutes/seconds, millisecond precision preserved lexically). Actual UTC issuance/publication, timestamp allocation, chronological truth, common transaction timestamp and identity authority are not implemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-014,Store-state publication transactions share UTC but never UUID identity,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Within one all-or-refuse Store-state publication transaction, every newly created RID , COL , and MAP final identity must carry the exact same canonical UTC millisecond transaction token and a distinct canonical UUID v4. UUID collision retry under PB-STOR-011 changes only the affected not-yet-created artifact UUID; it must not advance or alter the shared transaction UTC. Artifacts merely inherited or referenced by the transaction are not renamed, retimestamped, or assigned replacement UUIDs. A valid MAP may therefore bind artifacts created under several earlier transaction timestamps. Timestamp equality is evidence that artifacts were newly published by the same transaction; timestamp inequality is not evidence that artifacts belong to different Stores. P2-03 publication guard: for a successor Store-state transaction, the shared transaction UTC is established from truthful observed host UTC and is checked against the Store lineage's chronology predecessor before any newly created RID/COL/MAP artifact is promoted into its final governed class. If the observed transaction UTC is less than or equal to the chronology predecessor UTC, the publication refuses; the prior current MAP remains authoritative and no successor Store state commits.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-OPS-001,Permanent row identity after materialization,PB-OPS,PB-OPS,WASM-002,UNDER REVIEW,—,"Each logical Store has exactly one visible, deterministic RID artifact representing 1..N in governed logical CSV-record order. The header is excluded. Physical line count is not row identity: embedded newlines inside quoted fields remain inside one logical record. The RID is created when the first successful materialization establishes the Store and remains stable for the life of that Store. Every same-Store materialized or later aligned result column must contain exactly N data records in the same RID order. Multiple Stores may coexist in one Suitcase, and their RID values are unrelated; the meaningful row identity is therefore the pair (Store, RID) .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-OPS-002,Materialized columns preserve facts and alignment,PB-OPS,PB-OPS,WASM-002,UNDER REVIEW,—,Materialized columns preserve governed values in permanent row alignment. Materialization stores facts for reuse; it does not decide which rows are analytically interesting.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001,Flat Project Suitcase,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,The durable WASM-002 project model must not require semantic per-store subfolders. A logical store is represented by governed relationships among artifacts and metadata inside a flat project folder.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.1,The flat model must remain usable through ordinary filesystem tools.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.2,Native and browser hosts must use the same logical storage semantics even when their filesystem APIs differ.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.3,Folder placement must not be treated as the authoritative meaning of an artifact.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-002,Reserved Core namespace and sorting,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Every Data Sculptor Core-managed artifact must use the reserved __DS__ prefix. The prefix is deliberately visually distinctive and mechanically simple so Core artifacts cluster together under ordinary filename sorting in a mixed flat folder.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003,Three-character base-26 artifact class,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The class token must be exactly three uppercase ASCII letters A through Z, giving the fixed physical range AAA through ZZZ, and must immediately follow the reserved namespace within the frozen filename grammar.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.1,The three-character alphabetic class rule supersedes every earlier numeric class example.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.2,"Class ordering is positional base-26 using the alphabet A through Z: AAA, AAB, AAC, ... AAZ, ABA, ... ZZZ.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Ordinary lexical filename sorting therefore preserves the governed class order.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.3,"The namespace contains 26 cubed, or 17,576, possible class values while preserving one fixed-width token.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.4,Unallocated class tokens remain unassigned until explicitly allocated,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"WASM-002 does not reserve semantic meaning by numeric interval, lexical neighborhood, or implied class range. Any syntactically possible three-letter token that is not listed in the governed registry is unassigned for this build. A future artifact class may be allocated only by explicit PRD revision. Existing class meanings must never be shifted, renumbered, or reassigned merely to make room for later families.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.5,The WASM-002 artifact-class table is frozen by the governed registry,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The exact WASM-002 artifact-class table is the registry in PB-STOR-006. It is no longer a separate open storage freeze item. No additional reserved class ranges are defined by WASM-002. DGN , RCV , BRD , and LCK remain registered/reserved but are not emitted by WASM-002. Their presence in the registry does not create a WASM-002 producer, serialization contract, validity contract, lifecycle, or acceptance surface. Independent adversarial review must verify that every WASM-002-generated governed artifact uses a listed class that this build actually emits, that WIP remains a lifecycle state rather than a class, and that unknown/unallocated classes plus known-but-not-emitted classes are preserved and reported under PB-STOR-009 rather than silently interpreted or activated.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-004,Canonical Core filename envelope,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The default Core physical naming model for immutable governed artifacts is __DS__<CLASS>__<UTC>__<UUID>.<ext> . CLASS, UTC, and UUID are governed identity tokens. Human semantic labels are excluded from the physical identity envelope. A separately frozen artifact contract may define a well-known current-state singleton filename when that artifact must be updated in place and discovered by a stable name.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Default immutable filename-envelope structure only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. Singleton exception support, class-specific contracts and authority remain unimplemented. Syntactic success does not imply an authorized artifact. Independent QA pending. CP005: CP005 adds Gregorian calendar/UTC-clock validity to the already recognized immutable Core physical name. Singleton filenames, artifact-type extension rules and authorization remain unimplemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005,Canonical filename shape and fixed token lengths,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Every governed Core artifact type must have a canonical filename shape and total filename length so that a parser, browser host, native host, QA tool, or LLM can recognize malformed physical identity without interpreting variable human language. Under the Revision AH default immutable grammar, the canonical UTC token YYYYMMDDTHHMMSSmmmZ is exactly 19 ASCII characters and the canonical lowercase hyphenated UUID v4 token is exactly 36 ASCII characters. Class precedes UTC and UTC precedes UUID.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Fixed core lexical UTC (19 ASCII) and UUID v4 (36 ASCII) structure only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. No calendar validation, class/extension contract mapping, class-specific total length table, or filename publication gate is claimed. Independent QA pending. CP005: CP005 strengthens the fixed 19-ASCII-character UTC token with Gregorian calendar and UTC-clock range checks. Class-specific total filename lengths, extension mapping, and publication gates remain unimplemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.1,"If an artifact class has exactly one governed representation, all filenames in that class have one frozen total length.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.2,"If a future class permits more than one representation, each class/representation pair must still have a frozen total length.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.3,"Friendly store names, column names, aliases, and operation descriptions must never stretch or shorten a Core physical filename.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-006,Physical identity versus integrity,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,UUID identifies the governed artifact instance. SHA-256 records or verifies the exact bytes. The system must not overload one field to serve both identity and integrity.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007,Collision handling,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Physical filename collisions are expected to be rare but must be handled explicitly. Data Sculptor must never silently overwrite an existing governed artifact because a generated physical name already exists.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.1,"Before durable creation, the host must check whether the target physical name already exists.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.2,"On a UUID collision, the existing artifact is preserved and a fresh UUID is generated under the same relevant UTC/class context unless a later frozen rule requires a different deterministic response.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.3,Collision handling must be visible in the run Receipt/evidence when it occurs,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If governed identity allocation encounters one or more filename collisions before successfully allocating a non-colliding UUID identity, the canonical run Receipt must record that a collision retry occurred and the number of retries when the run reaches receipt publication. If identity allocation ultimately refuses, the refusal Receipt and diagnostic evidence must preserve the collision-failure fact without overwriting or mutating any pre-existing artifact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-008,Analyst-owned files remain analyst-owned,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Source files and analyst documents may retain their original filenames. Data Sculptor must not rename every input merely to fit the governed __DS__ namespace. For an ordinary WASM-002 analytical run, continuity between certification and materialization is established by the run-local source-binding contract, not by pretending a mutable source filename is permanent byte identity. Durable cross-run exact-byte verification requires separately governed integrity evidence such as the later V1 FINGERPRINT operation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-009,Store MAP as machine truth,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The Store MAP must provide the machine-readable relationship between governed physical artifacts and their logical meaning, including the fields required by the frozen schema for store identity, column identity, source reference/binding, run/materialization identity, row counts, status, lineage, supersession, and related provenance. Cryptographic hashes are recorded when a requirement or explicit operation actually produces them; the Store MAP contract must not imply that every source or artifact is automatically hashed during ordinary WASM-002 execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010,Aliases provide human orientation without a separate Store Index,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, human-facing orientation is provided by aliases exposed from governed Store MAP state and related governed artifacts. Aliases may help analysts navigate by meaning while preserving exact physical identities. WASM-002 does not publish or maintain a separate Store Index artifact. Richer directory/index presentation is carried by the governed DIR surface in WASM-003.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010.1,WASM-002 Store MAP profile is the unified Store metadata snapshot,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, the Store MAP profile of the governed MAP artifact class is the Store metadata snapshot. It records the Store's human-facing alias, Store-establishing source filename, exact RID artifact binding, RID alias, and the complete current materialized-column mappings and aliases governed by W002-STOR-019 through W002-STOR-019.12. WASM-002 must not create a second hidden or separately named Store-metadata file merely to bind the Store to its RID or aliases. The visible immutable __DS__MAP__...csv artifact is the authoritative governed Store MAP for this build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010.2,"Changing a friendly alias must not change physical identity, hashes, lineage, or historical provenance.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-011,"Store, row-universe, and future Boolean-selection-column rule",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Same-row derived columns and later aligned Boolean selection/filter columns remain within the same logical Store when row identity, row order, and cardinality are preserved. A future filter that evaluates every existing RID and writes one aligned two-valued Boolean result per RID does not by itself create a new row universe or a new logical Store. The canonical future selection tokens are 0 for FALSE and 1 for TRUE under PB-OPS-003 and PB-OPS-003.1. A new row universe is created only when a later governed operation actually changes which rows exist or their order—for example by building/exporting only selected rows, deduplicating rows, or otherwise materializing a different row set. Such an operation creates a new logical Store identity under the frozen row-identity contract. Filtering remains deferred from executable WASM-002 scope; this requirement freezes only the Store/RID compatibility rule that later filtering will rely upon.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-012,Current orientation and history are different truths,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Current Store orientation is represented by the applicable immutable MAP snapshot, while execution history is preserved by immutable RCP Receipts. For WASM-002, the Flight Recorder is the logical chronological view of published canonical RCP artifacts from actual Run invocations of saved immutable WKO Work Orders. It is not separately persisted and has no separate artifact class. Successful and refused runs contribute when Receipt publication succeeds; Receipt-publication failure is governed by W002-RCP-010 and must not be silently reconstructed as original evidence. Any Flight Recorder presentation is derived and regenerable from the authoritative Receipts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-013,Open representations,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Durable project artifacts should use documented open formats such as CSV, HTML, TXT, TOML, or other explicitly governed representations so that the Suitcase remains inspectable and portable outside Data Sculptor.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-014,LLM-readable storage grammar is a documentation principle,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The storage grammar, class table, Store MAP schema, current-state selection rule, and alias semantics must be documented clearly enough that an LLM collaborator can distinguish physical identity, logical meaning, integrity evidence, current state, and history without guessing. This is a documentation/readability principle for the Product Backlog PRD and related public product documentation. It does not create a new governed Suitcase artifact, require a new public-documentation file or publication operation, or add a separate WASM-002 acceptance deliverable beyond keeping the governing contract explicit and internally consistent.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-015,WASM-002 storage freeze status,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The current WASM-002 storage design preserves the resolved semantic artifact-class registry, canonical UTC millisecond rendering, class → UTC → UUID token order, UUID rendering/version, default immutable identity grammar, collision retry behavior, immutable one-Store-per-MAP versioning, Store-aware automatic MAP inheritance, complete-snapshot semantics, the exact eight-column Store MAP schema, deterministic Store/RID/COL alias defaults, rematerialization alias continuity, deterministic Store-MAP CSV serialization, Store-MAP eligibility/publication validation, materialization-coupled AS alias semantics, standalone alias maintenance using UPDATE ALIASES , explicit alias clearing with CLEAR ... ALIAS , deterministic default restoration with RESET ... ALIAS , exact historical Store-MAP selection using MAP ""<exact Store MAP filename>"" , canonical one-column COL serialization, the all-or-refuse materialization publication boundary, SCR -to-final-class host rename promotion, complete-set validation before promotion, new-Store RID-first promotion, inherited-RID reuse for existing-Store work, deterministic COL promotion, successor-MAP construction/validation as SCR , successor-MAP rename last as the Store-state commit point, rollback/recovery treatment for uncommitted promoted artifacts, the canonical RID CSV contract, the seven-operation Work Order execution surface, the canonical automatic TXT Receipt contract including exact WKO lineage, the Receipt-backed Flight Recorder, the governed HTML Suitcase Validation Certificate, the Work Order alias/comment contract plus WKO-MAP alias-registry profile, and the LCK reservation for explicit later-V1 FINGERPRINT evidence without automatic hashing in ordinary WASM-002. RID reconstruction/replacement is deliberately not part of the WASM-002 executable surface; RECOVER RID requirements are deferred to V1-BACKLOG. The Help-report provenance boundary is resolved: WASM-002 records governed HLP identity and lineage but does not automatically SHA-256 HLP bytes or create/refresh LCK evidence; exact-byte HLP integrity remains the later explicit FINGERPRINT/LCK workflow. Future branded Receipt rendering/Brand-Manifest integration remains outside the WASM-002 TXT-only Receipt contract. P2-04 closure: WASM-002 Store governance now has a complete two-tier artifact-validation model. Tier 1 supplies bounded Store-health checks for non-content-consuming paths; Tier 2 supplies full streaming RID/COL validation for content-consuming paths, candidate commit, and REPAIR MAP . The eight-column Store MAP remains unchanged and ordinary Store health makes no cryptographic claim of historical-byte identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-001,Every actual Run invocation of a saved WKO automatically produces one Receipt attempt,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"When the analyst invokes Run on a saved immutable WKO, Data Sculptor must automatically create one governed run-receipt attempt for that invocation. The Work Order must not require a RECEIPT , SAVE RECEIPT , or equivalent clause. An editable unsaved WIP is non-executable under the Work Order lifecycle contract and therefore cannot produce an execution Receipt. A saved WKO that is invoked and then refuses during validation or execution still has an execution outcome and must receive a refusal Receipt when receipt publication succeeds.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-002,The canonical WASM-002 Receipt is a governed TXT artifact with its own creation timestamp,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,The physical Receipt filename is: __DS__RCP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt The UTC token belongs to the Receipt artifact itself and represents the Receipt's governed creation/publication time under the canonical artifact-identity rules. It must not be copied from the authorizing WKO's filename merely to make the two filenames share a timestamp. The file is written visibly in the flat Suitcase under the governed RCP artifact class. Data Sculptor chooses the governed filename; the analyst does not supply it.,PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-014; CP-015,"CP014 T-ACCEPTED, GIT BANKED — canonical RCP TXT filename lexical recognizer only; own creation-time allocation, file emission, complete Receipt contract and publication unimplemented; CP015 T-ACCEPTED, GIT BANKED — pure lexical canonical SCR-to-RCP TXT filename-candidate pair matching only; no actual file/Receipt validation, promotion, publication or authority",f5038a183f1d3dc31b0065571bf8ac8814b5d8a9; be997dc0dbd65fc370814c4a5f2d0f1254870572,Evidence/CP-014/ZIP/CP014_RED_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_WASM_Build_Record.txt.zip; CP014_Git_Banking_Record.txt (external closeout); Evidence/CP-015/ZIP/CP015_RED_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_GREEN_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_PostAmend_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_Full_Regression_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_WASM_Build_Output.txt.zip; Evidence/CP-015/ZIP/CP015_Final_Archive_Manifest.txt.zip; CP015_PostCommit_Verification.txt (external closeout),"CP014 Day067: T-accepted, Git-banked lexical RCP .txt filename recognizer only. Pure is_canonical_rcp_filename_candidate(&str)->bool uses shared canonical envelope, rejects wrong class/extension/casing, malformed UTC/UUID, paths and whitespace. Six target GREEN passes; 64/64 native regression; Rustfmt and wasm32 library build PASS; 32 original-TXT-per-ZIP objects validated and committed unchanged. Commit f5038a183f1d3dc31b0065571bf8ac8814b5d8a9. No new Receipt timestamp generation, Receipt byte serialization, creation/promotion/publication or authority; independent implementation QA and browser runtime pending. CP015 Day067: T-approved pure is_matching_scr_rcp_filename_candidate_pair(&str,&str)->bool checks canonical SCR/RCP lowercase .txt candidates and exact timestamp/UUID pairing, reusing existing lexical recognizers and candidate derivation; rejects wrong classes/order, mismatched timestamps/UUID, paths, whitespace and noncanonical envelopes. Expected RED E0432 exit 101; six targeted GREEN PASS; T-approved formatting-only source+test amendment and recheck; full native regression 70/70 PASS, Rustfmt PASS, Rust 1.97.1 wasm32-unknown-unknown --lib compile PASS. Original TXT archived as 16 verified single-entry ZIPs; 18/18 committed Git blob identities checked; working tree clean. Banked at be997dc0dbd65fc370814c4a5f2d0f1254870572. No actual SCR/RCP file reads, Receipt content validation, timestamp generation, authority, promotion or publication; browser execution and independent implementation QA pending.",Day067,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-003,WASM-002 Receipts are TXT-only and independent of presentation state,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"For WASM-002, the canonical run Receipt is always plain TXT. Browser theme, built-in HTML presentation, Help voice, or other presentation state must not change whether the run Receipt is emitted as TXT or alter its governed facts. WASM-002 must not emit an HTML Receipt as an alternative to the canonical TXT Receipt. Configurable Brand Manifest behavior is deferred to a future build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-005,Canonical Receipt TXT serialization is deterministic,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The WASM-002 Receipt is UTF-8 without BOM and uses LF ( 0x0A ) line endings. Every Receipt ends with exactly one final LF. No serialized line carries trailing spaces, and no blank physical lines are emitted unless a later operation-specific grammar explicitly freezes them. It is a deterministic line-oriented KEY: VALUE document with a frozen core-key order followed by operation-specific fact sections in deterministic order. KEY is an uppercase ASCII field name. The separator is exactly one ASCII colon followed by exactly one ASCII space. KEY=VALUE is not valid canonical Receipt serialization. Fixed machine tokens and non-negative decimal integers are serialized unquoted. Human-authored text, filenames, aliases, headers, and other free text are serialized as double-quoted UTF-8 strings. Inside a quoted value, a literal double quote is represented by doubling it as """" . CR and LF are not permitted inside a single serialized value; each fact remains exactly one physical line. Enumerated values use the exact uppercase tokens frozen by the applicable requirement. Non-negative integers use ungrouped ASCII base-10 digits. This shared text rule is normative for all Receipt free-text values and is acceptance-tested byte-for-byte.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-006,Every Receipt records the fixed core execution facts and exact WKO lineage,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"Every canonical WASM-002 Receipt begins with the following common envelope keys in exactly this order: RECEIPT_VERSION RECEIPT_FILENAME RECEIPT_UTC WORK_ORDER_FILENAME OPERATION RUN_STARTED_UTC RUN_FINISHED_UTC RESULT DIAGNOSTIC_ID IDENTITY_COLLISION_RETRIES Day 060 H-02 version freeze: RECEIPT_VERSION is the unquoted integer 1 for the WASM-002 Receipt contract. RECEIPT_FILENAME is the exact physical governed RCP filename. RECEIPT_UTC is exactly the canonical UTC timestamp embedded in that filename and is distinct from the run start/finish timestamps. WORK_ORDER_FILENAME is the exact physical immutable WKO identity invoked and is the authoritative WKO→RCP lineage link. Day 060 H-09 / BM-06 truthful run-timestamp semantics RUN_STARTED_UTC and RUN_FINISHED_UTC are governed truthful host-UTC observations at millisecond precision. They are not decorative labels and are not synthesized from artifact filenames. RUN_STARTED_UTC is observed only after the exact saved WKO has been resolved and found eligible to Run, and immediately before operation-specific validation/execution begins. It therefore brackets operation validation, analytical work, publication attempts, refusal processing, and any governed rollback/cleanup performed by that Run. RUN_FINISHED_UTC is observed only after the operation has reached its final SUCCESS or REFUSED analytical outcome and all non-Receipt governed effects are settled: successful artifacts are committed, refusal state is established, and required rollback/cleanup or retained non-authoritative evidence classification is complete. Receipt publication begins only after this observation. For one Run, the truthful temporal invariant is: WKO_UTC ≤ RUN_STARTED_UTC ≤ each successfully published run-artifact UTC ≤ RUN_FINISHED_UTC ≤ RECEIPT_UTC where WKO_UTC is the governed UTC token embedded in the exact WORK_ORDER_FILENAME , and “run-artifact UTC” means the governed UTC embedded in each non-Receipt artifact successfully published by that Run, including a shared materialization transaction UTC where applicable. An operation that publishes no non-Receipt artifact simply has no middle artifact-UTC comparison. Equality is permitted because the canonical timestamp precision is milliseconds. Data Sculptor must not fabricate, increment, decrement, or reorder UTC values merely to make this invariant appear true. Receipt fixtures and retained acceptance evidence must use physically possible timelines under this rule. The existing rule that WKO and Receipt filename timestamps are not required to match remains unchanged: they are distinct events, but a WKO invoked by a Run must already exist as a governed artifact before that Run begins. RESULT is a closed WASM-002 vocabulary containing exactly SUCCESS and REFUSED . No other RESULT token is valid. DIAGNOSTIC_ID: NONE is used for an ordinary successful run; a refused run carries the exact governed diagnostic identity. The shared governed absence-state vocabulary is closed to these four tokens, with these exact meanings: NONE — the fact is applicable and definitively has no value in this event; NOT_RUN — the owning stage or operation was not executed; NOT_AVAILABLE — the fact is applicable or potentially applicable, but its value could not be obtained; NOT_APPLICABLE — the fact does not apply to this event, diagnostic, operation, or artifact. These states are semantically distinct and must not be substituted for one another. A count that was actually established as zero is serialized as the integer 0 , never as an absence token. The refusal-serialization matrix for every present operation-specific key is deterministic: State of the key's owning fact/stage at refusal Required serialization The fact was authoritatively established before refusal Serialize the exact governed value. The owning stage was never entered NOT_RUN . The owning stage ran and definitively produced no value/artifact for this event NONE . The fact applies but could not be obtained NOT_AVAILABLE . The fact does not apply to this event NOT_APPLICABLE . An applicable count was authoritatively established as zero 0 . A publication identity whose publication stage was never entered NOT_RUN , except where an earlier frozen operation-specific rule explicitly fixes another token. A publication identity whose publication stage was entered but no artifact of that identity successfully published NONE . A publication identity that successfully published The exact physical governed filename. For this contract, a fact is established only when its owning validation/stage has deterministically fixed the value and later execution cannot revise that fact. Candidate allocation, partial bytes, or an uncommitted publication does not establish a published-artifact identity. If parsing/validation refuses before one of the seven governed WASM-002 operations can be identified, the Receipt uses OPERATION: UNKNOWN_OPERATION , RESULT: REFUSED , and the applicable DIAGNOSTIC_ID . After the common envelope there is no operation-specific section; the Receipt proceeds directly to CREATED_ARTIFACT_COUNT: 0 . UNKNOWN_OPERATION is not an executable operation. After all operation-specific facts and indexed lists, every Receipt ends with: CREATED_ARTIFACT_COUNT: <N>
CREATED_ARTIFACT_001: ""...""
...
CREATED_ARTIFACT_N: ""..."" The created-artifact list contains only exact physical governed filenames successfully published by the run, excluding the Receipt itself. For this accounting, an artifact is successfully published only if it remains a committed governed artifact when the Run finishes; an artifact promoted and then rolled back, or left only as non-authoritative failure residue under All-or-Refuse, is excluded from CREATED_ARTIFACT_COUNT and its indexed list. Indexed suffixes are one-based decimal with a minimum width of three digits and no maximum width: 001 through 999 are zero-padded and 1000 onward uses the ordinary full ungrouped decimal form. When a count is zero, no indexed lines for that list appear. IDENTITY_COLLISION_RETRIES is always present and is 0 when no governed filename-allocation retry occurred. Receipt/WKO filename timestamps are not required to match. One immutable WKO may be run multiple times, each producing a distinct Receipt that points back to the same exact WORK_ORDER_FILENAME . F-08 DS-STEPS / Receipt token separation. Human-authored Work Orders use the readable terminal clauses below; the Receipt serializes the corresponding machine token in OPERATION . The two columns are not interchangeable spellings: DS-STEPS terminal clause Receipt OPERATION MATERIALIZE MATERIALIZE INVENTORY INVENTORY UPDATE ALIASES UPDATE_ALIASES REPAIR MAP REPAIR_MAP REPAIR WORK ORDER REGISTRY REPAIR_WORK_ORDER_REGISTRY CONVERT WINDOWS-1252 TO UTF-8 CONVERT_WINDOWS_1252_TO_UTF_8 CATALOG STORES CATALOG_STORES For example, REPAIR_MAP is not valid DS-STEPS syntax and REPAIR MAP is not the serialized Receipt token. UNKNOWN_OPERATION remains a refusal-only Receipt value when validation cannot identify one of these seven operations; it is not an executable operation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-007,"Materialization Receipts record Store, RID, Stage 1, Stage 2, and output facts",W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"For a WASM-002 MATERIALIZE run, after the common envelope the Receipt serializes these operation-specific keys in exactly this order: SOURCE_FILENAME BASE_MAP_FILENAME RID_FILENAME RID_ACTION STAGE1_UTF8_OUTCOME CERTIFIED_SOURCE_BYTE_COUNT STAGE1_ELAPSED_MS UTF8_FIRST_INVALID_BYTE_OFFSET UTF8_STOP_REASON WINDOWS_1252_COMPATIBILITY_OUTCOME WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET STAGE2_LOGICAL_ROW_COUNT STAGE2_ELAPSED_MS CSV_REFUSAL_CONDITION CSV_SOURCE_BYTE_OFFSET CSV_PHYSICAL_LINE CSV_LOGICAL_RECORD CSV_FIELD_ORDINAL REQUESTED_COLUMN_COUNT RESOLVED_COLUMN_COUNT PUBLISHED_COL_COUNT zero or more indexed published-COL filename lines whose exact key form is PUBLISHED_COL_<INDEX>_FILENAME (for example PUBLISHED_COL_001_FILENAME , PUBLISHED_COL_002_FILENAME ) SUCCESSOR_MAP_FILENAME OPERATIONAL_NAME_FALLBACK_COUNT zero or more indexed fallback triplets: OPERATIONAL_NAME_FALLBACK_001_COLUMN_ORDINAL , OPERATIONAL_NAME_FALLBACK_001_ASSIGNED_NAME , OPERATIONAL_NAME_FALLBACK_001_REASON , continuing under the common indexed-key rule. BASE_MAP_FILENAME: NONE denotes a newly established Store with no predecessor Store MAP. Day 060 H-11 / BM-08 RID_ACTION ownership and establishment RID_ACTION is a governed execution fact describing what this Run actually established for the Store RID path. It is never an intention, plan, or prediction. RID_ACTION: REUSED is established when routing has selected an existing Store, the exact inherited RID filename is known, and that inherited RID has passed the validation required to proceed. Because the RID already exists, this fact may be established before Stage 1 or Stage 2 completes. RID_ACTION: CREATED is established only when a new-Store RID candidate has successfully completed governed promotion into its final RID identity. Merely planning, allocating, writing, closing, validating, or naming an SCR candidate does not establish CREATED . Until either of those facts is established, the common refusal matrix governs RID_ACTION . For a new-Store path that refuses before successful RID promotion, RID_ACTION is NOT_RUN . If an existing-Store route is identified but the required inherited RID fact cannot be validly established, RID_ACTION is NOT_AVAILABLE . RID_FILENAME is a separate fact: for REUSED , it is the exact already-published inherited RID filename as soon as reuse is established; for CREATED , it is the exact governed final RID filename only after successful RID promotion; before new-RID promotion succeeds, no candidate/SCR filename may be serialized as though it were a published RID. With RID_ACTION: CREATED , RID_FILENAME records the RID identity successfully promoted during the Run even if that RID is later rolled back under All-or-Refuse; rollback does not erase the already-established RID_ACTION / RID_FILENAME execution facts. The refusal-boundary matrix is therefore: Materialization state RID_ACTION RID_FILENAME Validation/routing refuses before a Store/RID path is established NOT_RUN NOT_RUN or NOT_AVAILABLE only when an applicable routing fact could not be obtained under the common matrix New Store; Stage 1 refusal NOT_RUN NOT_RUN New Store; Stage 2 refusal NOT_RUN NOT_RUN New Store; post-Stage-2 gate refusal before RID promotion NOT_RUN NOT_RUN New Store; RID candidate/promotion has not successfully completed NOT_RUN NOT_RUN New Store; RID promotion succeeds CREATED exact published RID filename Existing Store; exact inherited RID selected and validated REUSED exact inherited RID filename Existing Store; later Stage 1, Stage 2, gate, or publication refusal after reuse was established REUSED exact inherited RID filename Existing lineage identified but required inherited RID cannot be validly established NOT_AVAILABLE NOT_AVAILABLE A refusal Receipt that says RID_ACTION: CREATED while RID_FILENAME is NONE or NOT_RUN and no RID was successfully promoted is invalid evidence. STAGE1_UTF8_OUTCOME has exactly two completed Stage-1 values: PASS and FAIL . If Stage 1 never ran, the value is NOT_RUN . If Stage 1 began but a separate failure prevented a governed PASS/FAIL determination, the value is NOT_AVAILABLE . NOT_APPLICABLE is not valid for this key. UTF8_FIRST_INVALID_BYTE_OFFSET and UTF8_STOP_REASON are refusal-only Stage-1 evidence. On STAGE1_UTF8_OUTCOME: FAIL , the offset is mandatory and is the exact zero-based absolute physical source-byte offset of the first byte of the invalid sequence, and the stop reason is mandatory and exactly INVALID_UTF8_SEQUENCE . Neither field may be NOT_AVAILABLE when the Stage-1 outcome is FAIL . On PASS , both fields are NOT_APPLICABLE . If Stage 1 never ran, both are NOT_RUN . If Stage 1 began but no UTF-8 PASS/FAIL conclusion was established because of a separate failure, both refusal-only fields are NOT_APPLICABLE . WINDOWS_1252_COMPATIBILITY_OUTCOME and WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET are the governed F-16 follow-on facts. They are evaluated only after STAGE1_UTF8_OUTCOME: FAIL . When the complete second pass reaches EOF with every byte mappable, the outcome is COMPATIBLE and the offset is NOT_APPLICABLE . When the pass encounters one of the undefined bytes frozen in W002-CONV-002.4, the outcome is INCOMPATIBLE and the offset is the exact zero-based absolute physical source-byte offset of the first such byte. If the pass begins but an independent failure prevents a conclusion, both fields are NOT_AVAILABLE . If Stage 1 did not conclude FAIL , the compatibility pass does not run and both fields are NOT_RUN . The five exact CSV refusal keys CSV_REFUSAL_CONDITION , CSV_SOURCE_BYTE_OFFSET , CSV_PHYSICAL_LINE , CSV_LOGICAL_RECORD , and CSV_FIELD_ORDINAL carry the exact structural CSV refusal condition and location oracle frozen in W002-MAT-002.8. If Stage 2 never ran, all five are NOT_RUN ; if Stage 2 completed without an applicable CSV refusal, all five are NOT_APPLICABLE ; on a CSV refusal, each established location fact is serialized and any applicable fact that could not be obtained is NOT_AVAILABLE . The MATERIALIZE refusal-stage matrix is: Refusal boundary Validation/routing and request facts Stage 1 facts Stage 2 facts Publication facts Validation, before Stage 1 Serialize each fact already established; an applicable fact that validation could not obtain is NOT_AVAILABLE . REQUESTED_COLUMN_COUNT is the actual count when the KEEP list parsed completely; otherwise NOT_AVAILABLE . RESOLVED_COLUMN_COUNT and fallback records are NOT_RUN until name/ordinal resolution has run. NOT_RUN for all Stage 1-owned facts. NOT_RUN for all Stage 2-owned facts. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Stage 1 refusal Established validation/routing facts are exact values. Serialize the exact Stage 1 outcome/timing and established refusal evidence; incomplete applicable facts are NOT_AVAILABLE . The Windows-1252 compatibility fields then serialize the exact complete assessment result under the rule above; if an independent assessment failure prevents a conclusion, they are NOT_AVAILABLE . NOT_RUN for all Stage 2-owned facts. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Stage 2 refusal Established validation/routing facts are exact values. Completed Stage 1 facts are exact values; UTF-8 refusal fields are NOT_APPLICABLE when no UTF-8 refusal occurred. Because Stage 1 passed, both Windows-1252 compatibility fields are NOT_RUN . STAGE2_ELAPSED_MS is the actual elapsed time when obtained; STAGE2_LOGICAL_ROW_COUNT is NOT_AVAILABLE unless the complete accepted logical row count was established; CSV refusal facts follow the rule above. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Post-Stage-2 gate refusal before publication All facts established through the gate are serialized exactly; non-applicable UTF-8/CSV refusal fields are NOT_APPLICABLE . Both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Publication refusal before the successor-MAP publication stage is entered All facts established before refusal are serialized exactly. This row includes a new-Store RID/COL identity-allocation or promotion refusal that occurs before the successor-MAP publication stage is entered. Completed Stage 1 and Stage 2 facts remain exact; non-applicable UTF-8/CSV refusal fields use their governed absence tokens, and both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. Under All-or-Refuse publication, PUBLISHED_COL_COUNT: 0 and no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN because the successor-MAP publication stage was never entered. A candidate filename is never serialized as a published identity. Publication refusal after the successor-MAP publication stage is entered All facts established before refusal are serialized exactly. Any RID fact already established before this later refusal remains governed by the RID_ACTION/RID_FILENAME matrix above. Completed Stage 1 and Stage 2 facts remain exact; non-applicable UTF-8/CSV refusal fields use their governed absence tokens, and both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. Under All-or-Refuse publication, PUBLISHED_COL_COUNT: 0 and no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NONE because the successor-MAP publication stage was entered but no successor MAP successfully published. A candidate filename is never serialized as a published identity. Success All applicable facts are exact values; refusal-only UTF-8/CSV fields are NOT_APPLICABLE . Both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. PUBLISHED_COL_COUNT is the actual count; indexed keys are exactly PUBLISHED_COL_001_FILENAME onward in resolved KEEP order; SUCCESSOR_MAP_FILENAME is the exact published successor MAP filename. Day 060 H-24 / BM-08 publication-boundary split: these two MATERIALIZE publication-refusal rows apply the common W002-RCP-006 ownership rule to the successor-MAP publication stage. NOT_RUN means that stage was never entered; NONE means it was entered but no successor MAP successfully published. The early boundary is exercised by the RID identity-allocation exhaustion fixture; the later boundary has its own byte-exact golden fixture. OPERATIONAL_NAME_FALLBACK_COUNT is NOT_RUN until operational-name resolution has run; afterward it is the established non-negative count, including literal 0 . Fallback records are ordered by ascending physical source-column ordinal. the exact fallback key OPERATIONAL_NAME_FALLBACK_<INDEX>_REASON is exactly SOURCE_HEADER_EXCEEDS_1024_SCALARS . For successful Store-establishing materialization, the common created-artifact list is ordered RID first, newly published COLs in resolved KEEP order, then successor MAP. For successful existing-Store materialization, the inherited RID is not newly created; the list contains newly published COLs in resolved KEEP order followed by the successor MAP. P3-09 Receipt oracle: when Stage 2 refuses because the certified source contains no logical CSV record, the five CSV refusal fields must serialize exactly as CSV_REFUSAL_CONDITION: NO_HEADER_RECORD , CSV_SOURCE_BYTE_OFFSET: <exact source byte length> , CSV_PHYSICAL_LINE: 1 , CSV_LOGICAL_RECORD: 1 , and CSV_FIELD_ORDINAL: 1 . Day 060 H-13 / BM-10 clarification: within those five governed CSV refusal fields, the zero-byte and UTF-8-BOM-only cases differ only in CSV_SOURCE_BYTE_OFFSET : 0 versus 3 . Their complete Receipt bytes also differ wherever the underlying source identity, certified source byte count, Work Order identity, run/Receipt timestamps, Receipt filename/UUID, or other fixture-specific governed facts differ. The complete Receipts must never be described as differing only by one field. F-20 operational-name Receipt oracle: OPERATIONAL_NAME_FALLBACK_COUNT counts selected/materialized columns whose exact source header exceeded 1,024 Unicode scalar values. Each corresponding ..._ASSIGNED_NAME stores the final deterministic operational/default-alias name after any permitted fallback collision disambiguation; ..._REASON remains exactly SOURCE_HEADER_EXCEEDS_1024_SCALARS . The Receipt does not copy the oversized exact source header merely to explain the fallback. The common indexed-key rule from W002-RCP-006 applies without a maximum width. A full-width KEEP is therefore representable through PUBLISHED_COL_16384_FILENAME (and corresponding fallback indexes when applicable); the three-digit examples are a minimum-width convention, not a 999-item ceiling.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-008,Other WASM-002 operations add deterministic operation-specific Receipt facts,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The same common envelope, closed RESULT/absence vocabulary, refusal matrix, created-artifact tail, and indexed-key rule apply to the other executable WASM-002 operations. Their operation-specific key tables are closed as follows. INVENTORY INVENTORY_FILENAME INVENTORY_ENTRY_COUNT Refusal boundary INVENTORY_ENTRY_COUNT INVENTORY_FILENAME Validation before inventory scan NOT_RUN NOT_RUN Inventory scan/measurement refusal Exact count if the complete count was established; otherwise NOT_AVAILABLE NOT_RUN Publication refusal after the snapshot facts were established Exact established count, including 0 NONE Success Exact established count Exact physical published INV filename UPDATE_ALIASES BASE_MAP_FILENAME SUCCESSOR_MAP_FILENAME Refusal boundary BASE_MAP_FILENAME SUCCESSOR_MAP_FILENAME Validation/routing before an exact base MAP is established NOT_AVAILABLE NOT_RUN Validation/gate refusal after the exact base MAP is established Exact base MAP filename NOT_RUN Publication refusal Exact base MAP filename NONE Success Exact base MAP filename Exact published successor MAP filename REPAIR_MAP TARGET_MAP_FILENAME RID_FILENAME BROKEN_COL_COUNT zero or more indexed broken-COL filename lines using exact key form BROKEN_COL_<INDEX>_FILENAME (for example BROKEN_COL_001_FILENAME , BROKEN_COL_002_FILENAME ) RETAINED_COL_COUNT SUCCESSOR_MAP_FILENAME Broken COL filenames are ordered by ascending exact UTF-8 filename bytes. RETAINED_COL_COUNT is the actual count once repair analysis completes, including literal 0 . Refusal boundary Target/RID facts Broken/retained facts SUCCESSOR_MAP_FILENAME Validation before an exact target MAP/RID is established Established facts are exact; otherwise NOT_AVAILABLE NOT_RUN NOT_RUN Repair-analysis refusal before a repair result is established Exact established values Exact values if established; otherwise the applicable unavailable/not-run token from the common matrix NOT_RUN All-COLs-broken refusal frozen under F-03/F-09 Exact values Exact broken count/list; RETAINED_COL_COUNT: 0 NONE — this earlier frozen named refusal remains an explicit operation-specific exception. Publication refusal Exact values Exact repair-analysis values NONE Success Exact values Exact repair-analysis values Exact published successor MAP filename REPAIR_WORK_ORDER_REGISTRY BASE_WKO_MAP_FILENAME REMOVED_STALE_ROW_COUNT zero or more indexed stale-WKO filename lines using exact key form REMOVED_STALE_WKO_<INDEX>_FILENAME (for example REMOVED_STALE_WKO_001_FILENAME , REMOVED_STALE_WKO_002_FILENAME ) REGISTERED_CURRENT_COUNT zero or more indexed current-WKO filename lines using exact key form REGISTERED_CURRENT_WKO_<INDEX>_FILENAME (for example REGISTERED_CURRENT_WKO_001_FILENAME , REGISTERED_CURRENT_WKO_002_FILENAME ) REGISTERED_DEPRECATED_COUNT zero or more indexed deprecated-WKO filename lines using exact key form REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME (for example REGISTERED_DEPRECATED_WKO_001_FILENAME , REGISTERED_DEPRECATED_WKO_002_FILENAME ) SUCCESSOR_WKO_MAP_FILENAME Each filename list is independently sorted by ascending exact UTF-8 filename bytes. If the bootstrap repair WKO is newly discovered and registered, it appears in the appropriate registered list under W002-STOR-018.3 and W002-STOR-018.4. Day 060 H-10 / BM-07 count semantics: REGISTERED_CURRENT_COUNT and REGISTERED_DEPRECATED_COUNT count only previously unregistered structurally valid WKOs that this repair Run newly adds to the successor WKO MAP with the stated status. They do not count surviving pre-existing rows already present in the base registry. The indexed filename lines list exactly the corresponding newly registered WKOs and no others. If the bootstrap repair WKO is one of those newly registered WKOs, it must appear in exactly one registered list. A successful repair Receipt that omits a newly registered bootstrap repair WKO is invalid evidence. Refusal boundary Base registry Repair-plan counts/lists SUCCESSOR_WKO_MAP_FILENAME Validation before the current structurally valid WKO MAP is established NOT_AVAILABLE NOT_RUN NOT_RUN Repair-analysis/gate refusal Exact base WKO MAP filename Exact values if the repair plan was established; otherwise the common matrix governs each present field NOT_RUN Publication refusal Exact base WKO MAP filename Exact established repair-plan values NONE Success Exact base WKO MAP filename Exact established repair-plan values Exact published successor WKO MAP filename CONVERT_WINDOWS_1252_TO_UTF_8 SOURCE_FILENAME SOURCE_ENCODING UNDEFINED_WINDOWS_1252_BYTE_OFFSET MATERIALIZED_ENCODING TRANSCODING SOURCE_CHANGED OUTPUT_FILENAME UNDEFINED_WINDOWS_1252_BYTE_OFFSET is the zero-based absolute physical source-byte offset of the first byte undefined by the frozen Windows-1252 mapping when that refusal occurs. If the compatibility stage never ran it is NOT_RUN ; if the stage ran and no undefined-byte refusal occurred it is NOT_APPLICABLE ; if the fact applies but could not be obtained it is NOT_AVAILABLE . Day 060 H-14 / BM-11 undefined-Windows-1252-byte refusal oracle For CONVERT WINDOWS-1252 TO UTF-8 , an undefined Windows-1252 byte is detected during the complete pre-transcoding compatibility assessment . Transcoding has not begun when this refusal is established. When the complete compatibility assessment encounters the first undefined byte, the Receipt must serialize these exact operation facts: SOURCE_ENCODING: WINDOWS-1252-INCOMPATIBLE
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: <exact zero-based absolute physical source-byte offset>
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE WINDOWS-1252-INCOMPATIBLE is the exact SOURCE_ENCODING token for this governed CONVERT refusal. OUTPUT_FILENAME: NONE means the operation definitively established that no CVT was published for the event. No CVT candidate may be reported as output. The compatibility scan reports the first undefined byte only. Later undefined bytes do not replace that offset. Permitted changes in scan buffer/window size or boundary placement must not change the reported absolute offset. Day 060 H-25 / BM-04 already-valid-UTF-8 refusal oracle. If the complete bound source passes strict UTF-8 validation, CONVERT refuses as unnecessary before Windows-1252 compatibility assessment or transcoding. The Receipt must serialize these exact operation facts: SOURCE_ENCODING: UTF-8
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: NOT_RUN
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE UTF-8 is the exact SOURCE_ENCODING token for this governed refusal. OUTPUT_FILENAME: NONE means the classification gate definitively established that this event publishes no CVT. The Windows-1252 compatibility stage is not entered. Refusal boundary Source/classification facts Conversion facts OUTPUT_FILENAME Validation/classification refusal before conversion begins Serialize each fact already established; an applicable fact that could not be obtained is NOT_AVAILABLE . The undefined-byte offset follows the rule above. MATERIALIZED_ENCODING and TRANSCODING are NOT_RUN when conversion did not run. SOURCE_CHANGED is the exact governed value once established. NONE only for either of the two definitively classified no-CVT cases: (1) the complete source is already valid strict UTF-8 and conversion is unnecessary; or (2) the complete Windows-1252 compatibility assessment finds an undefined byte. For other validation/classification refusals before conversion begins, OUTPUT_FILENAME: NOT_RUN unless another normative rule explicitly assigns a different closed token. Conversion/refusal after bounded transcoding begins but before publication Exact established source/classification facts Serialize exact established conversion facts; applicable incomplete facts use NOT_AVAILABLE . NOT_RUN Publication refusal Exact established facts Exact established conversion facts NONE Success SOURCE_ENCODING: WINDOWS-1252-COMPATIBLE ; undefined-byte offset NOT_APPLICABLE MATERIALIZED_ENCODING: UTF-8 ; TRANSCODING: BOUNDED_STREAMING ; SOURCE_CHANGED: NO Exact published CVT filename CATALOG_STORES CATALOG_ENTRY_COUNT CATALOG_FILENAME Refusal boundary CATALOG_ENTRY_COUNT CATALOG_FILENAME Validation/discovery refusal before the complete authoritative catalog row set is established NOT_AVAILABLE NOT_RUN Publication refusal after the complete catalog row set is established Exact established count, including 0 NONE Success Exact established count Exact physical published CAT filename On success, CATALOG_ENTRY_COUNT equals the number of data rows in the published CAT. CAT itself is the only new non-Receipt governed artifact produced by the operation. RECOVER RID / RECOVER_RID is not a valid executable WASM-002 operation in Revision BM.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-009,"Receipt truth is execution evidence, not presentation authority",W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The Receipt records what Data Sculptor actually attempted, observed, refused, and successfully published. It must not reinterpret the analyst's WKO, replace the Store MAP, or become a second analytical command surface. The WKO remains the durable authorization record; Store MAP/RID/COL artifacts remain the governed analytical state; diagnostic events remain the refusal/help truth; the Receipt cross-references those facts as the durable run ledger. The body of published canonical RCP artifacts is the authoritative evidence substrate for the Flight Recorder logical view defined in W002-STOR-012.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-010,Receipt-publication failure is itself a governed evidence failure,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"Data Sculptor must never claim that a durable Receipt exists until the RCP file has been successfully written and closed in the Suitcase. If host or filesystem failure prevents Receipt publication, the browser must surface a canonical diagnostic through the Help Engine stating that receipt evidence could not be persisted. A receipt-publication failure does not retroactively falsify analytical artifacts that were already successfully committed under their own publication contracts, but the user-facing run summary must clearly distinguish analytical outcome from receipt-persistence failure. Data Sculptor must not invent, backdate, or silently reconstruct a Receipt and present it as the original run artifact. F-14 publication path, reconciled by F-33: the RCP itself is first written as the corresponding SCR candidate under W002-STOR-023.1, closed, reopened and validated against the exact Receipt serialization/key contract before the class-token rename to RCP . If final RCP promotion fails, the candidate remains non-authoritative SCR evidence. Help may identify the exact retained SCR filename when that fact was established, but it must still state that the canonical Receipt was not persisted. WASM-002 does not emit an RCV artifact for this failure.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-001,Successful materialization Receipt and WKO-lineage acceptance,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,"A Store-establishing materialization fixture must run one saved WKO, publish exactly one canonical TXT RCP, and prove that the Receipt identifies the exact WKO through WORK_ORDER_FILENAME , source, RID_ACTION: CREATED , new RID, Stage 1 result/bytes/time, Stage 2 row count/time, all requested COL artifacts in resolved KEEP order, successor Store MAP, published-artifact count, timestamps, and RESULT: SUCCESS . The RCP filename UTC must represent the Receipt artifact's own creation/publication event and must not be required to equal the WKO filename UTC. The same immutable WKO must then be executable again in an appropriate fixture, producing a second distinct RCP with its own Receipt/run timestamps while both Receipts contain the same exact WORK_ORDER_FILENAME . A later same-Store materialization fixture must additionally prove RID_ACTION: REUSED and the original RID filename. The Store-establishing fixture must also prove that the newly created RID, every newly created COL, and the successor MAP carry one identical publication-transaction UTC token while each has a distinct UUID; the RCP filename UTC remains its own Receipt publication timestamp and is not required to equal that analytical transaction UTC. A later same-Store materialization must prove that newly created COLs and its successor MAP share the later transaction UTC while the inherited RID retains its original timestamp/UUID. F-07 Stage-1 success fixture: a successful materialization Receipt must serialize STAGE1_UTF8_OUTCOME: PASS , with UTF8_FIRST_INVALID_BYTE_OFFSET: NOT_APPLICABLE and UTF8_STOP_REASON: NOT_APPLICABLE . Separate refusal fixtures under W002-RCP-ACC-002 must prove FAIL plus the mandatory exact offset and INVALID_UTF8_SEQUENCE . F-20 maximum-width Receipt acceptance: a successful full-width materialization fixture must prove that published-COL indexed keys continue through PUBLISHED_COL_16384_FILENAME using the minimum-three-digit/no-maximum suffix rule. Oversized-header fixtures must prove the exact fallback count, source ordinal, assigned operational name, and SOURCE_HEADER_EXCEEDS_1024_SCALARS reason without embedding the oversized source-header text in the Receipt merely as fallback evidence. F-23 additional successful-Receipt coverage: acceptance must include a successful INVENTORY run whose RCP carries the exact governed INVENTORY operation-specific facts and a successful UPDATE_ALIASES run whose RCP carries the exact BASE_MAP_FILENAME and SUCCESSOR_MAP_FILENAME while reporting only actually published artifacts in the common created-artifact tail. F-23 UUID-collision seam: using a controlled UUID sequence, acceptance must force one or more governed filename collisions before successful allocation. Every pre-existing colliding artifact must remain byte-for-byte unchanged; allocation must retain the originally established governed UTC context while changing only the not-yet-created UUID as permitted; and the published Receipt must report the exact retry count in IDENTITY_COLLISION_RETRIES . Day 060 H-09 success-timeline acceptance Every retained successful Receipt fixture must satisfy the W002-RCP-006 temporal invariant using its actual embedded UTC tokens. Acceptance must mechanically prove: the invoked WKO UTC is less than or equal to RUN_STARTED_UTC ; every non-Receipt governed artifact successfully published by that Run has a governed artifact/transaction UTC between RUN_STARTED_UTC and RUN_FINISHED_UTC , inclusive; RUN_FINISHED_UTC is less than or equal to the Receipt filename/ RECEIPT_UTC ; and no fixture relies on an artifact timestamp that occurs after the Receipt that claims it, or before the Run that created it. A controlled-clock acceptance seam may be used to make equality and strict-order cases deterministic, but the fixture generator must not alter timestamps after the fact merely to satisfy the checker. Day 060 H-11 successful RID_ACTION acceptance A successful new-Store materialization Receipt may report RID_ACTION: CREATED only because the RID was actually promoted into its final governed RID identity during that Run. A successful existing-Store materialization Receipt reports RID_ACTION: REUSED and the exact inherited RID filename; no new RID candidate is created for that Run.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-002,Refusal Receipt acceptance,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,"A saved WKO that is actually Run and deterministically refuses must still produce one canonical TXT Receipt when Receipt publication itself remains available. The emitted bytes must conform to the closed RESULT vocabulary, the four governed absence tokens, the exact operation-specific key spelling/order, and the refusal matrix in W002-RCP-006 through W002-RCP-008. Acceptance must include byte-exact golden Receipt fixtures for every distinct refusal-boundary row required to exercise the serialization matrix for each of the seven executable WASM-002 operations: MATERIALIZE , INVENTORY , UPDATE_ALIASES , REPAIR_MAP , REPAIR_WORK_ORDER_REGISTRY , CONVERT_WINDOWS_1252_TO_UTF_8 , and CATALOG_STORES . Multiple Diagnostic IDs that map to the same refusal boundary and the same serialization row do not require duplicate byte fixtures merely because the Diagnostic ID differs. Acceptance must additionally include one byte-exact UNKNOWN_OPERATION refusal fixture proving the common envelope, OPERATION: UNKNOWN_OPERATION , RESULT: REFUSED , the exact diagnostic ID, absence of any operation-specific section, and immediate CREATED_ARTIFACT_COUNT: 0 . Fixtures must prove that NONE , NOT_RUN , NOT_AVAILABLE , and NOT_APPLICABLE retain distinct meanings; an established zero count is serialized as 0 ; no candidate filename is reported as a published identity; and every indexed key uses its complete frozen name and the minimum-three-digit/no-maximum suffix rule. An unsaved WIP must be proven unable to Run and therefore must not create an execution Receipt. F-16 materialization-refusal fixtures: byte-exact MATERIALIZE refusal Receipts must exercise the new compatibility pair in all four applicable states: NOT_RUN when Stage 1 did not fail; COMPATIBLE plus NOT_APPLICABLE offset; INCOMPATIBLE plus the exact first undefined-byte offset; and NOT_AVAILABLE / NOT_AVAILABLE when an independent compatibility-read failure prevents a conclusion. F-23 Receipt-publication failure fixture, reconciled by F-33: a controlled filesystem-fault seam must make canonical RCP publication fail after the underlying analytical/refusal outcome has been established. Acceptance must prove the W002-RCP-010 boundary exactly: no final RCP is fabricated or claimed, any retained candidate evidence follows the governed SCR retention/non-authority rules in W002-STOR-023.1, no RCV artifact is emitted, the user-facing diagnostic distinguishes analytical outcome from Receipt-persistence failure, and already committed analytical artifacts are not retroactively falsified solely because RCP persistence failed. F-23 ultimate identity-allocation failure fixture: with Receipt publication itself still available, a controlled identity-allocation seam must force a governed operation artifact to exhaust/fail safe allocation. The operation must refuse without overwriting or mutating any colliding pre-existing artifact, and the refusal Receipt/diagnostic evidence must preserve the established collision/allocation-failure facts under PB-STOR-011 and W002-STOR-007.3. Day 060 H-02 fixture binding: the retained golden corpus must use RECEIPT_VERSION: 1 and the fixture-pinned diagnostic allocations in W002-HELP-001.8. The corpus must contain one success Receipt for each of the seven executable operations, one refusal Receipt for every distinct refusal-boundary row in W002-RCP-007/W002-RCP-008, the three additional Stage-1 compatibility variants needed to cover COMPATIBLE , INCOMPATIBLE , and NOT_AVAILABLE after UTF-8 failure, and one UNKNOWN_OPERATION Receipt. Publication-refusal fixtures may use the operation-specific H-02 publication diagnostic and a non-zero IDENTITY_COLLISION_RETRIES value to satisfy the ultimate identity-allocation-failure acceptance boundary without inventing a second diagnostic solely for the same serialization row. Day 060 H-09 refusal-timeline acceptance Every retained refusal Receipt fixture must also satisfy the W002-RCP-006 temporal invariant. For a refusal with no successfully published non-Receipt artifact, acceptance proves WKO_UTC ≤ RUN_STARTED_UTC ≤ RUN_FINISHED_UTC ≤ RECEIPT_UTC . If a refusal legitimately leaves one or more successfully committed non-Receipt artifacts from an already-completed stage, each such artifact UTC must fall between Run start and Run finish and must be listed truthfully under the governing created-artifact rules. Day 060 H-11 / BM-08 RID_ACTION refusal acceptance Byte-exact MATERIALIZE refusal acceptance must distinguish new-Store and existing-Store RID paths: new-Store validation, Stage 1, Stage 2, and post-Stage-2 gate refusals before successful RID promotion serialize RID_ACTION: NOT_RUN and do not serialize a candidate as a published RID; a controlled new-Store refusal after RID promotion has successfully completed may serialize RID_ACTION: CREATED together with the exact published RID filename, but only if that RID was actually promoted and the remaining refusal/rollback evidence is truthful under the publication rules; an existing-Store refusal after the inherited RID has been selected and validated serializes RID_ACTION: REUSED and the exact inherited RID filename even when Stage 1, Stage 2, a later gate, or publication subsequently refuses; an existing lineage whose required inherited RID cannot be validly established serializes RID_ACTION: NOT_AVAILABLE and RID_FILENAME: NOT_AVAILABLE rather than claiming reuse. Acceptance must specifically reject the historical H-02 fixture pattern that reported RID_ACTION: CREATED while no RID existed and CREATED_ARTIFACT_COUNT: 0 . Day 060 H-12 H-02 publication-diagnostic scope The H-02 operation-specific publication diagnostics whose required facts are artifact_class and collision_retry_count are acceptance pins for governed filename identity-allocation collision exhaustion. They are not catch-all Diagnostic IDs for unrelated publication failures such as chronology guards, write/close/rename failures, or malformed predecessor state. Those distinct conditions use their own registry allocations; DS-UTC-001 is independently frozen for the strict monotonic-UTC guard. Day 060 H-13 / BM-10 zero-byte and BOM-only NO_HEADER_RECORD Receipt fixtures The retained golden corpus must contain two distinct byte-exact MATERIALIZE refusal Receipts for the P3-09 no-header boundary: Zero-byte source: the bound source has exact certified byte count 0 ; Stage 1 passes; Stage 2 refuses with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD ; CSV_SOURCE_BYTE_OFFSET: 0 ; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; and CSV_FIELD_ORDINAL: 1 . UTF-8-BOM-only source: the bound source consists exactly of bytes EF BB BF and has exact certified byte count 3 ; Stage 1 passes; Stage 2 refuses with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD ; CSV_SOURCE_BYTE_OFFSET: 3 ; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; and CSV_FIELD_ORDINAL: 1 . These two Receipt fixtures must carry their own truthful source filenames, Work Order identities, run timestamps, Receipt identities, and other governed facts. Only the five-field CSV refusal tuple has the narrower relationship stated in W002-RCP-007; the complete Receipt files are not otherwise required to be byte-identical. Day 060 H-14 / BM-11 CONVERT undefined-byte Receipt binding The coordinated golden Receipt corpus must include the byte-exact CONVERT_WINDOWS_1252_TO_UTF_8 refusal fixture from W002-CONV-ACC-002 using source bytes 41 81 42 . Its Receipt must carry UNDEFINED_WINDOWS_1252_BYTE_OFFSET: 1 and the exact pre-transcoding refusal values frozen in W002-RCP-008.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-003,Receipt TXT is invariant to presentation state in WASM-002,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,The same governed run must be exercised under materially different permitted browser presentation states. In each case the run Receipt must remain an RCP TXT artifact governed by the same receipt serialization and facts. Presentation must not convert it to HTML or alter execution truth in WASM-002. This acceptance gate does not require a configurable Brand Manifest; that capability is deferred.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-001,A Suitcase may contain multiple Stores and each current Store state binds exactly one RID,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The Suitcase is a workspace and may contain zero, one, or multiple logical Stores. Every committed Store state binds exactly one governed current RID artifact. RID values are unique only within their Store row universe; they are not Suitcase-global identifiers. Ordinary same-row-universe work reuses that RID unchanged. In WASM-002, a missing, unreadable, or invalid current RID makes the Store INVALID ; no executable WASM-002 operation regenerates or substitutes that RID. Read-only Help/evidence may explain analyst-owned restoration or lineage-retirement choices, but Data Sculptor does not publish a replacement RID. The stable logical row reference in WASM-002 is conceptually (Store lineage, RID value) ; the current physical RID identity is the exact rid_filename bound by the authoritative MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-002,The Store RID is generated automatically once and reused unchanged in WASM-002,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"When the first successful materialization establishes a new Store, Data Sculptor must automatically generate that Store's initial RID artifact as part of the same Stage 2 operation and the same all-or-refuse publication boundary. The analyst does not separately request ordinary RID generation. Before the RID SCR candidate is created, Data Sculptor establishes the materialization publication-transaction UTC under PB-STOR-013/PB-STOR-014 and allocates a RID-specific UUID. The canonical RID byte stream is then written as the visible governed SCR candidate whose filename already carries that exact UTC, UUID, and .csv extension intended for the final RID identity. Requested materialized columns likewise begin as governed SCR candidates whose distinct COL-specific UUIDs are allocated before those candidates are opened under the same transaction UTC. The new RID candidate and all requested COL candidates must reach EOF, reconcile to the same accepted Store row count N, and pass their required final validation before any candidate is promoted. After complete-set validation, Data Sculptor promotes the RID candidate first by host rename that changes only the three-letter semantic class token from SCR to RID . The candidate bytes, UTC token, UUID, and .csv extension must remain unchanged across that promotion. Requested COL candidates are promoted only after RID promotion succeeds. If later promotion or successor-MAP publication prevents transaction commit, the newly promoted RID is not committed Store state merely because an RID-looking file exists; it must be rolled back where safely possible or retained as attributable recovery evidence under the materialization failure contract. A first Store-establishing materialization commits exactly one RID regardless of how many requested COLs are materialized. Later ordinary materializations and other same-row-universe WASM-002 operations must reuse that RID unchanged. They must not create a new RID candidate, regenerate, replace, renumber, or silently supersede the inherited RID. RID reconstruction/replacement is not an executable WASM-002 operation. Any future governed RID-recovery design remains deferred and must be reintroduced by an explicit later PRD freeze.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-003,RID physical identity uses the governed RID filename grammar,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The physical RID filename must be: __DS__RID__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv The filename contains governed physical identity only. A Store name or friendly analyst alias must not be inserted into, substituted for, or used to rename this immutable physical RID filename.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-004,RID is a canonical one-column CSV containing the exact sequence 1 through N,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The RID artifact must serialize as a canonical one-column UTF-8 CSV with: exactly one UTF-8 BOM at byte zero; a structural first logical record exactly N=<value> , where <value> is the canonical unsigned base-10 representation of the Store's total logical data-row count N ; uppercase N , exactly one equals sign, no spaces, no sign, no leading zeroes except the single digit 0 , and no separators or locale formatting; LF ( 0x0A ) record terminators on every supported host; exactly N data records after the header, containing the consecutive unquoted decimal integers 1 through N in order; no zero RID data value, negatives, signs, thousands separators, decimal points, exponent notation, or leading zeroes; and a final LF after the last record. For N=0 , the canonical bytes are the UTF-8 BOM followed by N=0 and LF, with no data records. The N=<value> record is structural metadata and does not consume a Store row. The governed RID artifact class/filename and Store MAP binding identify the artifact as a RID; the literal header RID is not used by the frozen WASM-002 serialization.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-005,RID cardinality and order define same-Store column alignment,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"If a Store RID contains N data records, every governed column claimed to be aligned to that Store must contain exactly N data records in the same RID order. Data Sculptor must not describe a shorter, longer, reordered, duplicated, or row-shifted column as aligned to that Store. This invariant applies to materialized source columns in WASM-002 and is the stable contract that later calculated, Boolean-selection, verification, or left-join enrichment columns may rely upon.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-006,A different row universe requires a different Store and a new RID,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,An operation that changes which rows exist or changes their governed order does not mutate the existing Store RID. It establishes a different row universe and therefore requires a new logical Store identity and a new RID artifact beginning again at 1 for that new Store. Filtering that is represented only as a same-length aligned Boolean/selection column does not itself change the row universe; building a new reduced/reordered row set later would.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-007,The Store MAP gives RID a friendly alias without changing RID identity,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The physical RID artifact remains identified by its immutable governed filename and semantic RID class. Every valid Store MAP records that exact rid_filename and one current human-facing rid_alias . Changing the RID alias must not rename, rewrite, regenerate, or alter the meaning of the RID artifact. The same Store MAP also records the Store alias and materialized-column aliases, so the analyst-facing names and the physical Store spine remain explicitly connected in one visible governed artifact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-008,Ordinary RID generation is implicit Store infrastructure; RID reconstruction is deferred,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"WASM-002 materialization Work Orders specify the analyst's requested source columns and aliases. They must not require or expose a separate instruction such as RID , ROW INDEX , GENERATE RID , or an equivalent switch to create the Store row spine. Initial RID generation for a new Store is mandatory engine behavior implied by successful MATERIALIZE . WASM-002 must not provide an option to disable it. When ordinary materialization extends an existing Store, the engine must recognize and reuse that Store's existing RID. If that bound RID is missing or invalid, the Store is INVALID and ordinary Store operations refuse. WASM-002 exposes no RECOVER RID executable syntax. A future explicit recovery design may be considered in V1-BACKLOG, but it is not part of this build contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-001,Canonical RID byte serialization acceptance,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"An acceptance fixture with N=5 must prove exact governed bytes equivalent to a UTF-8 BOM followed by: N=5
1
2
3
4
5 Every record uses LF termination and the file ends with a final LF. A separate N=0 fixture must prove exact bytes equivalent to UTF-8 BOM + N=0 and no data records. The N=5 fixture repeated under different permitted source-window boundaries must produce byte-identical RID content apart from the governed physical filename allocated to the artifact. Full RID validation must also prove that the declared N , the number of following data records, and the exact sequence 1..N agree.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-002,Multiple Stores in one Suitcase retain independent RID spines,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,An acceptance fixture must establish at least two Stores with different row counts in the same Suitcase and prove that each Store publishes and retains exactly one distinct governed RID artifact. RID values may overlap numerically across Stores without collision because the Store identity disambiguates them.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-003,Later same-Store materialization reuses rather than regenerates RID,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"An acceptance fixture must establish a Store with an initial materialization, record the physical RID identity and exact RID bytes, then perform a later permitted materialization that adds at least one aligned COL without changing the row universe. The later run must reference and reuse the original RID artifact; no replacement RID may be published and the original RID bytes must remain unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-004,Implicit RID generation acceptance for single- and multi-column first materialization,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"Acceptance must execute two Store-establishing Work Orders that contain no RID or row-index syntax: one requesting exactly one source column and one requesting multiple source columns. Each successfully committed run must publish exactly one governed RID artifact regardless of the number of requested COL artifacts. The fixture must prove that RID creation occurs during the same Stage 2 source-record traversal that establishes the Store row count rather than by requiring a second source pass solely to construct RID. The RID row count must reconcile exactly with every requested COL row count and the final accepted Store N. Before RID candidate creation, acceptance must prove that the publication-transaction UTC and RID-specific UUID are already established, and that the governed SCR filename carries exactly the UTC, UUID, and .csv extension intended for the final RID identity. Before complete-set validation, the RID bytes must exist only as that governed SCR candidate. Acceptance must prove that the RID candidate is promoted by host rename only after the complete RID/COL candidate set validates, that the physical-name change is exactly the class token SCR to RID , that candidate bytes/UTC/UUID/extension are unchanged across promotion, that RID promotion precedes COL promotion, and that the resulting RID is not considered committed Store membership until the successor MAP is successfully promoted and binds that exact RID filename.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-001,INVENTORY is an explicit standalone WASM-002 Work Order operation,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 form is: SUITCASE: .
WORK ORDER AS ""Inventory this Suitcase""
INVENTORY INVENTORY reads the authorized Suitcase directory metadata and creates one governed Suitcase Inventory Snapshot. It is read-only with respect to pre-existing Suitcase files. In WASM-002, an INVENTORY Work Order must not also request materialization, conversion, fingerprinting, another analytical operation, or another Work Order invocation. F-08 structure freeze: after the common SUITCASE: . / WORK ORDER AS ""..."" preamble, INVENTORY is the sole semantic operation clause and is terminal. No SOURCE , MAP , KEEP , alias mutation, conversion, repair, catalog, or composition clause is valid in the same WKO.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-002,Suitcase Inventory uses the governed INV artifact class and canonical filename grammar,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"A successful inventory produces exactly one visible flat TXT artifact whose physical filename is: __DS__INV__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt The UTC and UUID tokens follow the existing governed artifact-identity rules. Data Sculptor must not create an inventory subfolder, hidden cache copy, or alternate private persistence. F-14 publication: the INV body is produced first under the matching W002-STOR-023.1 SCR identity with the same UTC, UUID and .txt extension intended for the final INV. Publication to INV occurs only after the complete scan and deterministic INV serialization validate successfully.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-003,"The lightweight inventory records filename, exact byte length, and last-modified metadata",W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"For every regular file present in the authorized flat Suitcase root at snapshot time, the inventory must record: the exact visible filename; the exact byte length reported by the host file object; and the host/browser-reported last-modified value rendered in the canonical UTC millisecond form when available. WASM-002 must not claim access to a true file-creation timestamp. It must not infer, fabricate, or substitute a creation time from the last-modified value. If usable last-modified metadata is unavailable, the inventory must represent that fact explicitly rather than invent a timestamp. P3-10 last-modified availability test: host/browser last-modified metadata is usable only when the host supplies a finite, non-negative whole-number millisecond value that can be represented in the canonical UTC millisecond timestamp form. If that test fails, the inventory must serialize the governed unavailable value rather than infer, round, substitute, or fabricate a timestamp.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-004,INVENTORY does not read file contents or compute content hashes,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The lightweight inventory must be produced from directory enumeration and file metadata only. Data Sculptor must not open and stream the contents of each listed file merely to create the inventory, and it must not compute SHA-256 or another content fingerprint as an implicit side effect. Its cost should therefore scale primarily with the number of directory entries and metadata calls, not with the aggregate byte size of the files. A 7 GB CSV and a 7 KB CSV each contribute one metadata entry rather than requiring their contents to be read.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-005,Inventory scope is the authorized flat Suitcase root,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"WASM-002 inventories regular files and immediate child directory entries in the directory denoted by SUITCASE: . . Data Sculptor must not recursively inspect, enumerate, size, hash, or otherwise inventory the contents of a child directory in this build. Each immediate child directory is recorded as a directory entry by its exact visible name only. Its nested contents and aggregate size are outside the WASM-002 Inventory contract. This rule preserves the flat-Suitcase storage model while making the presence of user-created directories explicit rather than silently omitting them. F-26 SOURCE distinction: inclusion in an Inventory is evidence that an entry was physically visible to the Inventory operation; it does not make that entry eligible for a Work Order SOURCE . SOURCE eligibility is the narrower contract in W002-WKO-009.1.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-006,Inventory serialization is deterministic UTF-8 TXT,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The INV artifact is a deterministic human-readable TXT document encoded as UTF-8 without BOM, using LF ( 0x0A ) line endings, the same KEY: VALUE line grammar, and the same quoted-text escaping rule frozen by W002-RCP-005. Every INV ends with exactly one final LF, contains no trailing spaces, and contains no blank physical lines. The exact V1 Inventory serialization order is: INVENTORY_VERSION INVENTORY_UTC WORK_ORDER_FILENAME SUITCASE ENTRY_COUNT for each regular-file entry in deterministic ascending exact-filename UTF-8 byte order, one contiguous indexed triplet: FILE_<INDEX> , FILE_<INDEX>_BYTE_LENGTH , FILE_<INDEX>_LAST_MODIFIED_UTC DIRECTORY_COUNT exactly DIRECTORY_COUNT directory-name records using contiguous indexed keys DIRECTORY_<INDEX> , ordered by ascending exact-directory-name UTF-8 bytes. INVENTORY_VERSION is the unquoted integer 1 for this contract. WORK_ORDER_FILENAME , SUITCASE , each FILE_<INDEX> filename, and each DIRECTORY_<INDEX> name use the common double-quoted UTF-8 text serialization. FILE_<INDEX>_BYTE_LENGTH is the exact non-negative ungrouped ASCII base-10 byte length. FILE_<INDEX>_LAST_MODIFIED_UTC is either the exact canonical UTC millisecond token governed by W002-INV-003 or the unquoted governed absence token NOT_AVAILABLE . Indexed suffixes are one-based decimal with a minimum width of three digits and no maximum width: 001 through 999 are zero-padded and 1000 onward uses the full ungrouped decimal form. When ENTRY_COUNT or DIRECTORY_COUNT is zero, no indexed lines for that list appear. ENTRY_COUNT remains the regular-file count. Directory records contain the exact immediate child directory name only and do not imply recursive inspection or a computed directory size. Filename and directory-name representations remain unambiguous even when a name contains whitespace, quotes, or delimiter-like characters because the common quote-doubling rule applies. P3-10 inventory timestamp binding: INVENTORY_UTC must equal the exact canonical UTC token embedded in the final governed __DS__INV__<UTC>__<uuid-v4>.txt filename, just as RECEIPT_UTC is bound to the governed Receipt filename UTC. The INV body and filename therefore cannot claim different capture times.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-007,The current inventory describes the pre-publication Suitcase state and excludes itself,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,Data Sculptor must enumerate and fix the inventory snapshot before publishing the new INV artifact. The INV artifact being created is therefore not one of its own listed entries. Any older INV artifact that already existed at snapshot time is an ordinary Suitcase file and is included like any other file. This pre-publication rule prevents recursive self-reference while preserving an accurate snapshot of the state that existed immediately before the new inventory evidence was added.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-008,"Help describes INVENTORY as a quick continuity aid, not byte-level proof",W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"Help must explain that an INV snapshot is useful for ordinary closeout and later orientation: it can reveal additions, removals, renames, size changes, or last-modified changes when snapshots or current metadata are compared. For an unexpected cross-session source problem, Help may direct the analyst to the relevant source entry in an earlier INV and ask whether its filename, exact byte length, or last-modified metadata differs. Help must also state that unchanged filename/size/last-modified metadata does not prove that file contents or row order are identical. When stronger assurance is warranted because files may change unexpectedly, Help may recommend the explicit later/deeper content-fingerprinting workflow; INVENTORY itself must never imply forensic or cryptographic assurance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-001,Large-file inventory acceptance proves metadata-only behavior,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"An acceptance fixture must place at least one multi-gigabyte file plus several small files in the authorized Suitcase, execute INVENTORY , and prove that the resulting INV records the correct filename, exact byte length, and last-modified metadata without reading the multi-gigabyte file contents. Evidence must demonstrate that inventory runtime and memory do not scale with the aggregate bytes of the listed files in the way a fingerprinting pass would. P3-10 metadata determinism: acceptance must include at least one file with usable host last-modified metadata and one test double/fixture in which the last-modified value fails the governed availability test. The first must serialize the exact canonical UTC millisecond value; the second must serialize exactly NOT_AVAILABLE . The accepted INV must also prove that INVENTORY_UTC exactly matches the UTC token in its final INV filename. Day 060 H-01 byte oracle: acceptance must include at least one byte-exact INV golden fixture using the complete W002-INV-006 key order, indexed suffix rule, quoted-text escaping rule, UTF-8/no-BOM physical form, LF-only line endings, and exactly one final LF. It must include at least two file records so deterministic filename ordering is observable, including one NOT_AVAILABLE last-modified value, and at least one directory record. Day 060 H-09 reachable-Suitcase INV golden fixture The byte-exact INV golden fixture used for WASM-002 review must depict a Suitcase state that could actually execute INVENTORY under the current contract rather than an isolated impossible file list. At minimum, immediately before the Inventory Run begins, the fixture Suitcase contains: one valid current Suitcase Validation Certificate ( CER ) authorizing the root; one structurally valid current WKO registry MAP; the exact saved immutable INVENTORY WKO referenced by WORK_ORDER_FILENAME , registered as runnable by that current WKO MAP; and the ordinary analyst files used to demonstrate inventory metadata, including the controlled last-modified-available and NOT_AVAILABLE cases. The INV snapshot is taken before publication of the new INV artifact and before its Receipt publication. Therefore the INV being created and the Receipt for that Run do not appear as pre-existing entries in their own inventory snapshot. For the retained minimal review fixture, the regular-file ENTRY_COUNT and indexed records must include the CER, current WKO MAP, exact INVENTORY WKO, and the two ordinary sample files, for a total of five regular-file rows, serialized in ascending exact-filename UTF-8 byte order. A later implementation fixture may use different exact governed filenames/UUIDs while preserving the same reachable-state requirement and deterministic ordering.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-002,Inventory snapshot membership and self-exclusion acceptance,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"An acceptance fixture must include ordinary analyst files, existing governed __DS__ artifacts, and at least one older INV artifact. The new inventory must include every qualifying pre-existing root file in deterministic order, include the older INV, and exclude only the newly generated INV because it did not exist in the fixed pre-publication snapshot. Adding an unrelated PDF or ZIP before a later inventory must appear as an added inventory entry and must not be treated as an analytical error.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-003,Inventory does not overclaim unchanged contents,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"Acceptance documentation and Help fixtures must demonstrate the limitation of metadata-only continuity. A case in which a file's bytes are changed while the observed filename, byte length, and last-modified metadata are preserved or restored must not be described as detectable by INVENTORY alone. The product must direct the analyst toward stronger explicit fingerprint evidence when byte-level assurance is required.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-016,Work Order filenames use the governed immutable identity grammar,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When Data Sculptor saves a new Work Order as a WKO, it shall assign the physical TXT filename. The analyst chooses the validated Suitcase but is not asked to choose or edit the WKO filename. The exact WKO filename shape is __DS__WKO__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt , using UTC at millisecond precision with exactly three millisecond digits and a canonical lowercase hyphenated UUID v4. UTC precedes UUID. If the generated name collides with an existing artifact, PB-STOR-011 governs UUID regeneration and safe retry. The saved WKO thereafter retains that physical identity and remains immutable under W002-STOR-017.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-017,Saved Work Orders are immutable artifacts,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"After a Work Order TXT artifact is saved, Data Sculptor shall not edit, overwrite, or rename that saved Work Order in place. Changing analytical instructions requires saving a new Work Order artifact with a new governed physical identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018,Work Order alias is immutable WKO content and governed MAP metadata,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A human-facing Work Order name is required immutable Work Order content for every executable/saved WASM-002 WKO, not separately editable browser metadata. The canonical declaration is WORK ORDER AS ""<alias>"" under W002-STEPS-001.1. The quoted alias must be non-empty UTF-8 text and may contain spaces and ordinary phrase punctuation subject to the governed string-literal rules. After the WKO TXT artifact is saved, Data Sculptor shall not edit the alias in place. Changing the alias, analytical instructions, or comments means creating and saving a new immutable WKO with a new governed physical identity. The physical WKO filename/UUID remains execution identity; the alias is human-facing metadata for display and governed name resolution. The browser must not maintain a separate mutable Description field or hidden description store. The alias declared by the WKO is also represented in the current governed WKO MAP under W002-STOR-018.1 through W002-STOR-018.4.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.1,The existing MAP class includes a distinct WKO alias-registry profile,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Revision BB does not add a new semantic artifact class. The existing MAP class has two explicitly distinguished governed profiles: Store MAP — the existing exact eight-column Store/RID/COL snapshot governed by W002-STOR-019 through W002-STOR-019.12; WKO MAP — a complete immutable snapshot that maps saved Work Order aliases and lifecycle status to exact immutable WKO filenames. Profile classification is determined by the exact CSV header before profile-specific validation. A valid WKO MAP must never be treated as an eligible Store MAP, and a Store MAP must never be treated as a WKO alias registry. Both remain visible flat-Suitcase MAP artifacts under the canonical immutable filename grammar.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.2,WKO MAP schema and serialization are exact and deterministic,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical WKO MAP is UTF-8 CSV without BOM, using LF record termination, with exactly this three-field header: wko_status,wko_alias,wko_filename Each row identifies one immutable governed WKO represented in that registry snapshot. wko_status is exactly CURRENT or DEPRECATED . wko_alias is the exact mandatory non-empty alias declared by that WKO's WORK ORDER AS clause. wko_filename is the exact governed physical WKO filename. Rows are written deterministically by ascending exact UTF-8 byte order of wko_filename . Duplicate wko_filename rows are invalid. Standard governed CSV quoting applies. For any exact wko_alias value, at most one row may have wko_status=CURRENT ; zero or more older rows for that same alias may have wko_status=DEPRECATED . Alias resolution uses the CURRENT row only. A WKO represented by a DEPRECATED row remains immutable historical evidence and is not renamed, rewritten, or deleted merely because its alias target was superseded. A WKO MAP containing more than one CURRENT row for the same exact alias is structurally invalid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.3,Saving a WKO and publishing its WKO MAP binding is one governed save transaction,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Saving a new immutable WKO begins from the current structurally valid WKO MAP in the Suitcase, or an empty WKO registry if no structurally valid WKO MAP exists. Data Sculptor validates the draft, including its mandatory non-empty WORK ORDER AS alias and comment syntax, and checks the governed alias/lifecycle constraints before commit. F-02 alias-lifecycle decision: if no CURRENT row in the predecessor WKO MAP uses the new WKO's exact alias, the successor registry adds the new WKO as CURRENT . If exactly one CURRENT row already owns that exact alias, Data Sculptor must present exactly two analyst choices before registry commit: Replace alias target or Cancel . Replace alias target constructs the successor WKO MAP by changing the former owner's row to DEPRECATED and adding the newly saved WKO as the sole CURRENT row for that alias; any older DEPRECATED rows remain unchanged. Cancel leaves the predecessor WKO MAP authoritative and does not commit the pending WKO/WKO-MAP pair as a registry update. Data Sculptor must not silently replace the alias target, auto-suffix the alias, or choose between competing owners. A predecessor WKO MAP with more than one CURRENT row for the same alias is structurally invalid under W002-STOR-018.2 and cannot be used as save authority. The former CURRENT WKO and every prior WKO MAP remain byte-for-byte immutable after replacement. Supersession changes only the lifecycle metadata represented in the newly published successor WKO MAP; it does not edit, rename, delete, or rewrite the historical WKO artifact. F-14 WKO publication predicate: the new immutable Work Order is first written under the W002-STOR-023.1 SCR identity using the UTC, UUID and .txt extension intended for its final WKO identity. The complete candidate is closed, reopened and validated as a saved WKO: required common preamble, exactly one non-whitespace WORK ORDER AS alias, governed lexical/comment rules, and complete parse under exactly one current WASM-002 executable operation grammar. Only then may the candidate be renamed from SCR to WKO . Save-time current-registry, alias-lifecycle and lifecycle gates remain transaction preconditions. A valid promoted WKO is not yet alias-registry authority; the successor WKO MAP promotion remains the save-transaction commit point. The WKO is persisted as a new immutable governed WKO artifact and the complete successor WKO MAP is constructed under SCR , closed, reopened, and validated for WKO MAP structural validity : exact profile/schema, exact governed serialization, filename/profile rules, lifecycle-row constraints, and internal row constraints. Whether every referenced physical WKO file is presently visible is a separate registry-health/publication check and is not part of WKO MAP structural validity. For an ordinary successful save transaction, every WKO referenced by the successor registry must be present at publication. The successor WKO MAP is promoted to MAP last; that successful MAP promotion is the alias-registry commit point for the save transaction. The WKO and successor WKO MAP created by one successful save transaction use one shared canonical transaction UTC while retaining distinct UUIDs. If successor WKO-MAP structural validation, referenced-file publication checking, or publication itself fails, the save must not be represented as a successfully committed alias-registry update. Data Sculptor must roll back the new WKO out of committed WKO state where safely possible or retain visible non-authoritative SCR failure evidence and report the failure through Help. F-02 repair-only bootstrap and stale-registry Save boundary When the current WKO registry is repair-required under W002-STOR-018.4, Data Sculptor may save one ordinary visible immutable WKO whose sole semantic operation is exactly REPAIR WORK ORDER REGISTRY . That saved repair-only WKO may Run by its exact physical WKO filename even though it is not yet represented in the current WKO MAP. The WKO must be structurally valid under the predicate below, must contain exactly one mandatory non-empty WORK ORDER AS , and must contain exactly the governed registry-repair operation and no second operation. The exception does not grant alias-based Run authority. The repair WKO is invoked only by exact physical WKO filename. No other visible but unregistered WKO gains Run eligibility from this exception. The exception ends once registry repair successfully publishes the successor WKO MAP. This is the sole WASM-002 bypass of ordinary current-registry membership for Run eligibility. Because the registry is already stale, Save of the repair-only WKO does not claim that the WKO has been registered, does not commit an ordinary successor WKO MAP, and does not represent the stale registry as healthy. The new immutable WKO remains visibly unregistered until the repair operation successfully publishes the successor WKO MAP containing its row. Save does not silently perform registry repair. F-02 governed WKO structural-validity predicate A visible WKO is structurally valid for registry purposes only when all of the following hold: it is a regular root-level Suitcase file; its physical filename conforms exactly to the governed WKO filename grammar; its bytes are valid UTF-8; LF and CRLF physical line endings are accepted; a lone CR line ending refuses; its content parses completely under exactly one defined WASM-002 executable Work Order grammar; it contains exactly one mandatory non-empty WORK ORDER AS clause; its required common and operation-specific structural clauses are present in their governed order/cardinality; and unknown syntax or prohibited operation mixing causes invalidity/refusal. Structural validity is not runtime success. A structurally valid WKO remains a valid governed artifact even when a runtime precondition is currently false, such as a referenced source file being absent. Runtime preconditions are checked at Run. P3-10 repair-bootstrap timing: during REPAIR WORK ORDER REGISTRY , the saved repair-only WKO participates in the bounded discovery performed by that repair run. It is not first “discovered after success.” Its governed registration becomes durable only when the complete successor WKO MAP containing that WKO row is successfully committed. Discovery during the run and registration in the committed successor registry are distinct events. P2-03 WKO-registry chronology guard: before a save or registry-repair transaction publishes a successor WKO MAP, Data Sculptor establishes the truthful observed transaction UTC and compares it with the chronology predecessor defined by W002-STOR-018.4. The observed UTC must be strictly greater. Equal or earlier UTC refuses before the new WKO/WKO-MAP pair is committed; Data Sculptor must not fabricate a later timestamp, silently wait/retry, skip the predecessor, or select an older registry merely to make publication succeed. F-13 single-writer pre-commit guard: immediately before the successor WKO MAP promotion that would commit the alias-registry update, Data Sculptor re-resolves the current WKO-registry authority and compares the relevant governing state with the state from which this transaction was derived. If another writing context or external filesystem action has changed that relevant authority, the transaction refuses publication. It must not overwrite the newer registry, silently rebase the pending save, or choose an older registry to make the commit succeed. The existing rollback / attributable SCR recovery-evidence rules apply to any WKO or candidate bytes already produced. If the save later refuses and an SCR candidate or other attributable staged evidence cannot be safely removed/restored, W002-STOR-023.1 governs retained SCR evidence and its non-authority boundary; WASM-002 does not emit RCV. An unregistered final WKO left by a failure is a valid immutable WKO artifact but does not become current registry authority merely by existing; the WKO MAP remains authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.4,Current WKO MAP selection is based on structural validity; missing referenced WKOs make the registry repair-required,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"WKO MAP structural validity is distinct from registry health. A WKO MAP is structurally valid when the MAP artifact itself satisfies the governed WKO MAP profile/schema, serialization, filename/profile rules, lifecycle-row constraints, and internal row constraints. The present existence of every physical WKO file named by its rows is not part of WKO MAP structural validity. Only structurally valid WKO MAP artifacts participate in current-registry selection. Among structurally valid WKO MAPs, the one with the greatest canonical UTC millisecond timestamp is the current WKO MAP snapshot and therefore the current governed Work Order alias registry. If two or more structurally valid WKO MAPs share that greatest timestamp, current-registry selection must refuse rather than break the tie by UUID, discovery order, filesystem modified time, or directory order. Registry-snapshot authority is distinct from alias-target status inside that snapshot. After the current WKO MAP snapshot is selected, an alias resolves only to its exact row whose wko_status is CURRENT . Rows marked DEPRECATED remain visible historical registry evidence but are not alias-resolution targets. The registry must never use the greatest WKO filename UTC, filesystem modified time, or discovery order to choose between rows for an alias. More than one CURRENT row for the same exact alias makes that WKO MAP structurally invalid under W002-STOR-018.2. If a newer WKO MAP artifact is structurally malformed, it never becomes current. Data Sculptor uses the greatest earlier structurally valid WKO MAP, if one exists, and reports the malformed newer artifact through Help/evidence surfaces. A malformed newer WKO MAP does not itself make the selected earlier registry repair-required. The current WKO registry is repair-required exactly when the current structurally valid WKO MAP contains one or more rows whose referenced physical WKO files are missing from the Suitcase. Such a MAP remains current ; Data Sculptor must not silently fall back to an older WKO MAP merely because a referenced WKO is missing. This preserves the latest registry authority while making the damage explicit and reachable through the governed REPAIR WORK ORDER REGISTRY path. F-02 deterministic registry reconciliation REPAIR WORK ORDER REGISTRY reconciles the current WKO MAP against visible WKO artifacts in the Suitcase and constructs one complete successor WKO MAP deterministically: Remove every row from the successor whose referenced physical WKO file is missing. A missing WKO is never reconstructed, inferred, copied from history, or replaced automatically by a deprecated WKO. Discover visible structurally valid WKOs that are absent from the current WKO MAP. If no surviving CURRENT row owns a discovered WKO's exact alias, register that discovered WKO as CURRENT . If a surviving CURRENT row already owns that exact alias, register the discovered WKO as DEPRECATED ; existing current authority is not silently displaced. If two or more previously unregistered structurally valid WKOs share the same alias and no surviving CURRENT owner exists, register all of those discovered WKOs as DEPRECATED . Data Sculptor must not choose a winner by UTC, filename, UUID, directory order, discovery order, or filesystem modified time. The repair WKO itself participates in the same discovery and registration process during the repair run. Its registration becomes durable only when the complete successor WKO MAP is committed. Predecessor WKO MAPs and surviving WKO files remain immutable historical evidence. Successor rows remain serialized in ascending exact UTF-8 byte order of wko_filename under W002-STOR-018.2. Day 060 H-10 / BM-07 registry-repair change-set counts The registry-repair operation distinguishes the successor registry state from the change set produced by this repair Run . The Receipt's REGISTERED_CURRENT_* and REGISTERED_DEPRECATED_* fields describe only the latter. REGISTERED_CURRENT_COUNT is the exact number of previously unregistered structurally valid WKO files newly added by this repair Run with wko_status=CURRENT . REGISTERED_CURRENT_WKO_<INDEX>_FILENAME lists exactly those newly registered CURRENT WKOs, ordered by ascending exact UTF-8 filename bytes. REGISTERED_DEPRECATED_COUNT is the exact number of previously unregistered structurally valid WKO files newly added by this repair Run with wko_status=DEPRECATED . REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME lists exactly those newly registered DEPRECATED WKOs, ordered by ascending exact UTF-8 filename bytes. Surviving rows that were already present in the base WKO MAP are not counted in either REGISTERED_* total, even though they appear in the successor WKO MAP. Rows removed because their referenced WKO is missing are represented only by REMOVED_STALE_ROW_COUNT and the corresponding stale-WKO filename list; they are not also reflected in either registered count. The bootstrap repair WKO participates exactly like any other newly discovered structurally valid unregistered WKO. If the repair commits it, that exact WKO must appear in one and only one of the two registered filename lists according to the ordinary alias-ownership rules. These counts therefore answer “what did this repair register?” rather than “how many CURRENT/DEPRECATED rows exist in the resulting registry?”. F-02 Run eligibility and alias authority Run by human-facing alias resolves only to the sole CURRENT WKO for that alias. A registered CURRENT WKO may Run by exact physical WKO filename, subject to ordinary runtime preconditions. A registered DEPRECATED WKO may also Run by exact physical WKO filename, subject to ordinary runtime preconditions, to support deliberate historical reproduction. An unregistered WKO may not Run merely because its file is visible, except for the single bounded repair-only bootstrap in W002-STOR-018.3. The browser may use the current structurally valid WKO MAP to show human-facing Work Order aliases together with read-only CURRENT / DEPRECATED lifecycle state while keeping exact physical WKO filenames visible/inspectable. Future Work Order composition may use the same registry to resolve a non-empty alias to exactly one immutable WKO artifact through its sole CURRENT row. This requirement does not pull deferred Work Order invocation/orchestration grammar into WASM-002; it establishes the governed alias-registry selection, lifecycle, and repair boundary that later composition can depend on. F-08 REPAIR WORK ORDER REGISTRY Work Order structure: SUITCASE: .
WORK ORDER AS ""Repair Work Order Registry""
REPAIR WORK ORDER REGISTRY After the common preamble, REPAIR WORK ORDER REGISTRY is the sole semantic operation clause and is terminal. It takes no analyst-supplied SOURCE , Store MAP , alias-mutation list, column selector, conversion source, or catalog clause. Its bounded unregistered-repair bootstrap remains governed by W002-STOR-018.3. The DS-STEPS phrase is distinct from the Receipt operation token REPAIR_WORK_ORDER_REGISTRY . P2-03 chronology predecessor: for any WKO-registry successor publication, the chronology predecessor is the unique current structurally valid WKO MAP immediately before that publication transaction. It is the MAP selected by the current-registry rule above, not an older registry used for inspection and not a filesystem-modified-time surrogate. If no structurally valid WKO MAP exists and the operation is legitimately establishing the first governed registry state, there is no predecessor UTC. Future-dated current WKO MAP: a structurally valid current WKO MAP whose governed UTC is later than truthful observed host UTC remains the current registry; the timestamp conflict does not by itself make the MAP malformed or repair-required. Successor WKO-MAP publication is blocked until the monotonic UTC precondition can be satisfied. Help must identify the exact blocking WKO MAP and explain the analyst-owned exits: correct an incorrect host clock; wait/rerun after truthful time advances beyond the predecessor; or, when the analyst deliberately determines that the active future-dated WKO MAP should no longer govern the Suitcase, move that exact MAP out of the active Suitcase root and reopen/rescan. That filesystem action is not a Data Sculptor repair operation. It may expose an older structurally valid WKO MAP as current, and restoring the moved future-dated MAP to the active Suitcase may make it current again under the ordinary greatest-UTC rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019,Store state is preserved as visible immutable MAP history,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each valid WASM-002 MAP is one complete immutable Store snapshot in the same flat Suitcase. Store state is not stored in hidden browser persistence and is not represented by a mutable well-known singleton. Each successful Store-establishing materialization or later governed Store-metadata/materialized-column update publishes a new immutable MAP under the canonical __DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv identity grammar. Earlier MAP artifacts remain visible history and are not overwritten or deleted merely because a newer Store state is created. Day 057 CAT reconciliation: the one-Store-per-MAP invariant is unchanged. A collection of independently MAP-governed Stores may additionally be summarized by a governed CAT Store Catalog for collection-level discovery and orientation. CAT does not govern Store semantics, lineage, health, repair, inheritance, or current-MAP selection. MAP remains authoritative for each Store.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.1,A Work Order may explicitly select at most one Store MAP,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each governed Work Order may explicitly identify at most one valid immutable Store MAP as its Store/inheritance base. If more than one MAP is explicitly specified, Data Sculptor must refuse before Store resolution, alias resolution, materialization, or mutation. An explicitly named valid MAP binds the run to exactly the Store identified by that MAP's rid_filename and overrides automatic Store-MAP discovery even when newer MAPs for that Store or other Stores exist.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.2,"Without an explicit MAP, materialization performs Store-aware MAP inheritance",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If a materializing Work Order does not explicitly identify a MAP, Data Sculptor must compare the exact Work Order SOURCE filename with the one common exact source_filename carried by every row of each routable Store lineage's structurally valid Store MAP. That common source_filename is the Store lineage's source identity for WASM-002 routing. The redundant ninth Store-source field from the superseded profile is not part of the canonical Store MAP. P3-07 routing term: for automatic source routing, a routable Store lineage is a Store lineage for which at least one structurally valid Store MAP exists, regardless of whether the lineage currently evaluates VALID , DEGRADED , or INVALID . Routing discovery must use this term rather than the ambiguous word eligible . Store health is evaluated only after the lineage has been discovered. If no routable Store lineage exists for the exact source filename, Data Sculptor may establish a new Store with a new RID and first Store MAP only if the active Suitcase contains no structurally malformed Store-MAP-class artifact . If exactly one routable Store lineage exists, Data Sculptor routes to that lineage. If its current state permits materialization, the current governed Store MAP is the inheritance base; if its current state is DEGRADED or INVALID , ordinary materialization refuses under the damaged-lineage rules below. If more than one distinct routable Store lineage exists for the same exact source filename, automatic inheritance must refuse rather than guess which Store the analyst intended. The analyst must explicitly select one permitted MAP. All-Store-MAPs-damaged guard: if exact- SOURCE routing finds no routable Store lineage but one or more structurally malformed Store-MAP-class artifacts are present in the active Suitcase, ordinary materialization must refuse before creating a new Store or RID. Data Sculptor must not infer that the absence of a structurally valid Store MAP proves that no prior Store lineage existed. Help must identify the malformed Store MAP artifact or artifacts that caused this guard. A damaged MAP therefore cannot silently turn Store damage into permission to create a replacement lineage. Store lineages are distinguished by their governed lineage identity. Current-MAP selection and Store-health evaluation are separate governed questions under this requirement and W002-STOR-019.10. If two or more structurally valid current MAP candidates for the one routed Store share the greatest canonical UTC millisecond timestamp, automatic inheritance must refuse rather than infer chronology from UUID, directory order, filesystem modified time, or discovery order. F-03 canonical evaluated Store-health states Store health is evaluated from the current structurally valid Store MAP and the presently visible governed artifacts it references, using the applicable validation tier in W002-STOR-019.10. WASM-002 has exactly three evaluated Store-health states: VALID — the current Store MAP is structurally valid; the referenced RID is valid; and every mapped non-RID COL is valid. DEGRADED — the current Store MAP is structurally valid; the referenced RID is valid; and one or more mapped non-RID COL artifacts are missing or invalid. INVALID — the current Store MAP is structurally valid, but its referenced RID is missing or invalid. There is no fourth ABANDONED Store-health status in WASM-002. F-03 status is evaluated, not persisted VALID , DEGRADED , and INVALID are evaluated states. WASM-002 does not write or maintain a mutable persisted Store-status flag. While a Store evaluates INVALID , Data Sculptor exposes no governed Store-recovery operation for that Store and never regenerates, substitutes, or infers a replacement RID. If the exact governed RID physical identity becomes visible again through analyst-owned external restoration and passes the validation tier required by the next operation, the Store is re-evaluated from the visible governed artifacts and may become VALID or DEGRADED . That is re-evaluation, not RID recovery by Data Sculptor. F-03 strict DEGRADED operation gate When a Store evaluates DEGRADED , REPAIR MAP is the only enabled Store mutation operation for that lineage . ordinary materialization into that Store refuses; extension with new columns refuses; alias mutation refuses; transformations and other Store mutations refuse; read-only Help, Inventory, status/orientation surfaces, CAT orientation, and evidence inspection remain available subject to their own contracts. F-03 no damaged-lineage fork If exact SOURCE routing identifies a lineage whose current Store evaluates DEGRADED , ordinary materialization refuses and directs the analyst to the governed REPAIR MAP path. If the routed Store evaluates INVALID , ordinary materialization refuses and WASM-002 provides no RID-recovery path. Neither condition permits Data Sculptor to treat the source as unseen or establish a replacement Store with a new RID for that routed lineage. Damaged-lineage routing: exact SOURCE routing must not treat a known damaged lineage as unseen merely because its current Store state cannot accept ordinary materialization. If routing identifies a DEGRADED or INVALID lineage, ordinary materialization refuses rather than silently creating a replacement Store for that same routed lineage. Help duty for an all-COLs-broken DEGRADED lineage: when the current structurally valid Store MAP references a valid RID but every mapped non-RID COL is missing or invalid, REPAIR MAP cannot publish a zero-COL successor and must refuse. Help must identify the exact blocked Store lineage and current MAP, then explain these analyst-owned exits: (1) externally restore at least one governed COL artifact under its original physical filename; Data Sculptor then applies the governed validation tier required by the next operation before the artifact can re-enter use, so Store health can be re-evaluated and REPAIR MAP may become available; (2) rename the analyst-owned source and materialize the renamed source to deliberately begin a new Store lineage with a new RID, without repairing, replacing, or erasing the damaged lineage; or (3) retire the damaged lineage from active Suitcase routing by moving all Store MAP artifacts belonging to that lineage out of the Suitcase root. Help must warn that moving only the latest MAP is insufficient because an older structurally valid MAP could otherwise become current. Help duty for an INVALID lineage: when the current structurally valid Store MAP references a missing or invalid RID, Help must identify the exact blocked Store lineage and current MAP, state that WASM-002 does not silently regenerate or substitute a RID as part of ordinary materialization, and explain these analyst-owned exits: (1) externally restore a governed RID artifact under its original physical filename; Data Sculptor then applies the governed validation tier required by the next operation before the artifact can re-enter use, so Store health can be re-evaluated; (2) rename the analyst-owned source and materialize the renamed source to deliberately begin a new Store lineage with a new RID while leaving the damaged lineage untouched; or (3) retire the damaged lineage from active Suitcase routing by moving all Store MAP artifacts belonging to that lineage out of the Suitcase root, again warning that moving only the latest MAP is insufficient. Renaming the source and retiring a lineage are distinct analyst choices. Renaming preserves the damaged lineage in the Suitcase and creates a separate lineage under a different source identity. Moving all lineage MAPs out removes that lineage from active routing while preserving the moved artifacts wherever the analyst chooses to keep them. These are analyst filesystem actions, not new Data Sculptor recovery operations. Assurance boundary: exact source-filename matching in this rule is a Store-routing/orientation mechanism, not proof that an analyst-owned source has identical bytes or row order across separate sessions. Ordinary WASM-002 materialization must not silently represent that filename equality as cryptographic continuity. P3-08 CVT source-identity boundary: a governed CVT is a new immutable source artifact whose Store-routing source identity is its exact physical CVT filename. Two different CVT filenames are different source identities even when both conversions began from analyst-owned files having the same original filename. WASM-002 does not carry the analyst-owned pre-conversion filename forward as hidden Store-lineage identity and does not infer continuity between separate CVT artifacts. First materialization of a CVT therefore establishes or routes only by that exact CVT filename under the normal rules above. P2-03 current Store-MAP chronology: within one routable Store lineage, the current structurally valid Store MAP is the unique structurally valid MAP carrying the greatest canonical UTC millisecond timestamp. If two or more structurally valid MAPs share that greatest timestamp, current authority is ambiguous and selection refuses rather than using UUID or discovery order. This current MAP is also the lineage's chronology predecessor for any new successor publication, even when the operation explicitly derives its requested new state from an older historical MAP. F-15 exact-source comparison and routing domain: the Work Order SOURCE value and each Store MAP's common source_filename are compared by exact Unicode scalar-value sequence under PB-STOR-010, with no case folding or Unicode normalization. Automatic routing compares only routable Store lineages whose structurally valid Store MAPs participate in that exact-source routing decision. Unrelated Suitcase files, non-Store artifact classes, filesystem enumeration order, and arrival order are outside the routing comparison domain and cannot create or remove a source match.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.3,"Any valid historical Store MAP may be selected explicitly with MAP ""<filename>""",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A governed Store-aware Work Order may explicitly identify any one structurally valid immutable Store MAP present in the Suitcase, including an older snapshot when newer MAPs for that Store also exist. The canonical clause is: MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv"" The quoted value must be the exact physical filename of one valid Store MAP. A WKO MAP profile, missing file, malformed MAP, or other MAP profile is invalid for this clause. Data Sculptor uses exactly the named Store MAP rather than silently substituting a later one. For materialization, SOURCE ""..."" remains required to identify the source file being read; the optional MAP ""..."" clause occurs immediately after SOURCE and before KEEP , overrides automatic Store-MAP inheritance, and supplies the exact Store-state base. The Work Order's exact SOURCE filename must match the selected lineage's governed source identity under the frozen source/Store compatibility rules or validation refuses. For an alias-only UPDATE ALIASES Work Order, MAP ""..."" may itself be the Store-state selector and no source-data read is required. Historical-MAP health gate. Explicit selection of a current or historical Store MAP never bypasses current Store-lineage health. The selected lineage must currently evaluate VALID , and every RID/COL binding referenced by the named MAP must currently be present and valid. If either condition fails, Data Sculptor refuses the operation. An older MAP cannot be used to hide present lineage damage. The same rule applies when UPDATE ALIASES uses a historical Store MAP as its base. Once selected, the exact MAP identity, Store RID binding, Store alias, RID alias, and materialized-column mapping state remain fixed for the governed run. The MAP filename is execution input, not a friendly alias. P2-03 base-versus-predecessor distinction: an explicitly selected historical MAP is the operation's base MAP —the Store snapshot from which requested new state is derived. It does not become the chronology predecessor merely because it was selected. If the operation publishes a new Store MAP, the chronology predecessor remains the Store lineage's current structurally valid MAP immediately before publication. The new transaction UTC must be strictly greater than that current MAP UTC. This preserves one chronological MAP history rather than creating a branch from the historical base. F-21 current-state consequence: merely selecting or validating a historical Store MAP does not change Store authority. If the governed run refuses or otherwise publishes no successor Store MAP, the lineage's pre-run current MAP remains current. If the run successfully publishes a successor derived from a historical base, that new MAP enters the same single chronological history and ordinary greatest-governed-UTC current-state selection applies. Because successor publication already requires a truthful transaction UTC strictly greater than the pre-publication chronology predecessor, the successfully published successor becomes current. The explicitly selected historical base and the formerly current MAP both remain immutable historical evidence. This behavior is deliberate state derivation, not a branch, rollback-in-place, overwrite, or mutation of prior MAPs. The operation base records which Store snapshot supplied the requested starting state ; chronology records when the new governed state was published . Those are distinct facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.4,"Store MAPs are complete snapshots, not delta logs",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each valid Store MAP represents one complete usable Store metadata and materialized-column mapping state for that version. It must not require replaying a chain of earlier MAP files merely to reconstruct the Store's current RID binding, aliases, or materialized-column mappings. A newer MAP created from an inherited older MAP contains the complete resulting Store snapshot after applying the governed Work Order's successful changes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.5,Materialization or governed Store metadata mutation emits one successor MAP,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When a governed Work Order materializes one or more columns or requests governed Store/RID/COL alias changes, Data Sculptor begins from the applicable governed Store-state base. Ordinary materialization uses the explicitly selected MAP or Store-aware automatic inheritance under W002-STOR-019.2. A new Store begins from newly established Store/RID metadata plus an empty materialized-column mapping set before requested materialization is applied. All successful updates in that Work Order are applied to one in-memory complete Store snapshot. The complete deterministic successor-MAP bytes must first be written under a governed SCR candidate identity, closed successfully, reopened, and fully validated while still an SCR candidate. Only a complete validated candidate may be promoted by host rename into one new immutable MAP artifact. The inherited MAP remains unchanged. The successful SCR -to- MAP rename is the Store-state commit point. A failed run must not create a valid successor MAP; a malformed, incomplete, or unpromoted MAP candidate remains visible non-authoritative SCR evidence rather than Store state. RID reconstruction/replacement is not a WASM-002 Store-mutation path. P2-03 successor publication precondition: before any final RID/COL/MAP promotion for a successor Store-state transaction, Data Sculptor identifies the lineage's chronology predecessor and establishes one truthful observed host transaction UTC. For an existing lineage, that UTC must be strictly greater than the current structurally valid Store MAP UTC, regardless of whether the Work Order's base MAP is current or historical. Equal or earlier observed UTC refuses publication; no artificial +1 ms , sleep-and-retry loop, UUID tie-break, older-predecessor fallback, or branch chronology is permitted. The chronology predecessor remains current and unchanged. Future-dated current Store MAP: a structurally valid current MAP with a governed UTC later than truthful observed host UTC is a clock-order conflict, not by itself Store corruption. It remains current and successor publication is blocked. Help must identify the exact blocking MAP and explain the analyst-owned exits: correct an incorrect host clock; wait/rerun after truthful time advances beyond the predecessor; or deliberately move that exact future-dated current Store MAP out of the active Suitcase root and reopen/rescan. Moving it is an analyst filesystem action, not a governed Data Sculptor mutation. An older structurally valid MAP may then become current; returning the future-dated MAP may restore its authority under the ordinary greatest-UTC rule. F-13 single-writer pre-commit guard: immediately before the final successor Store-MAP promotion, Data Sculptor re-resolves the relevant current Store authority and exact-source routing state on which the transaction depended. For an existing lineage, the current chronology predecessor must still be the authority against which the transaction was prepared; for a new-Store transaction, no newly established routable lineage may have appeared that changes the routing decision. If relevant governed state changed while the transaction was in flight, publication refuses. Data Sculptor must not overwrite the newer authority, silently rebase onto it, create a competing branch, or report success. Any RID/COL/candidate artifacts already produced are handled by the existing rollback / attributable recovery-evidence rules and do not become committed Store membership without the final valid MAP binding. F-21 historical-base publication rule: when the applicable Store-state base is a valid historical MAP rather than the pre-run current MAP, the complete successor snapshot is still derived from that explicitly selected base plus the current Work Order's requested changes. Publication does not silently merge later state from the formerly current MAP back into the successor. Therefore mappings or aliases introduced only after the selected historical base may be absent from the new successor when the requested operation does not recreate them. That is the deliberate consequence of using the historical base, not data loss caused by an implicit merge. The pre-run current MAP remains the chronology predecessor solely for monotonic publication ordering and stale-authority protection. Successful publication leaves both the historical base and the formerly current MAP byte-for-byte unchanged, publishes one new immutable successor MAP in the same lineage, and makes that successor current under the ordinary chronology rule. No branch identifier, hidden branch state, overwrite, in-place rollback, or automatic rebase is created.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.6,Store MAP CSV schema is exactly eight columns,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 Store MAP is a CSV whose header row is exactly: store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename Each data row describes one current logical materialized-column mapping: store_alias — current human-facing Store name; rid_filename — exact immutable governed RID artifact filename that physically anchors this Store lineage; rid_alias — current human-facing RID name; source_filename — exact visible source filename common to every row in this one-Store MAP and therefore the Store source identity; source_column_number — 1-based source-column ordinal; source_header — exact decoded CSV header value after governed parsing; alias — current human-facing COL name; and column_filename — exact physical governed COL artifact filename represented by the row. Every row in one valid Store MAP must carry the same exact rid_filename and the same exact source_filename . A MAP that mixes RID lineages or source filenames is invalid. The logical source-column key for COL alias continuity remains the exact triple (source_filename, source_column_number, source_header) . The Store is physically identified by the repeated exact rid_filename , not by mutable aliases. F-05/P2-01 reconciliation: the superseded redundant Store-source column is removed. One Store MAP represents exactly one Store lineage and exactly one source identity, so the common source_filename supplies the required source identity without a second Store-source field. P3-06 identity-evidence boundary: this eight-column MAP profile intentionally records governed physical filenames and mapping metadata, not per-artifact byte lengths, row counts, digests, or historical-content fingerprints. A MAP therefore cannot prove that a same-named RID or COL restored later is byte-for-byte identical to the earlier artifact. WASM-002 must not make that claim unless separate authoritative fingerprint evidence exists outside this MAP profile. P2-04 schema consequence: no byte-length, RID- N , digest, or per-artifact fingerprint columns are added to the eight-column Store MAP to close restoration validation. The MAP remains compact relationship/state metadata. Stronger byte-identity assurance remains the responsibility of explicit fingerprint evidence outside ordinary WASM-002 Store governance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.7,Source headers become default COL aliases on first materialization,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When a logical source column is materialized and its exact logical key does not already exist in the inherited Store MAP, its default COL alias is its operational column name . For an exact decoded source_header of at most 1,024 Unicode scalar values, the operational name is that exact header text. For an exact decoded source_header longer than 1,024 scalar values, the operational name begins as Column <LETTERS> from the column's 1-based physical source ordinal (for example Column A , Column Z , Column AA , through Column XFD ). The exact source_header remains unchanged in the Store MAP and physical COL header; the operational name exists only to provide a bounded human-facing/default-alias value. HEADER selection continues to match the exact decoded source header under W002-STEPS-002. If an oversized-header base fallback Column <LETTERS> would collide in the complete successor alias namespace, Data Sculptor deterministically tries Column <LETTERS> [<ordinal>] ; if that also collides, it appends -2 , -3 , and so on until the first available exact value is found. This is the only automatic alias-suffix rule in WASM-002. A short exact source-header default that is empty or collides still refuses unless the Work Order supplies an explicit valid alias; Data Sculptor must not suffix or rewrite it. If the same Work Order supplies an explicit alias for a newly materialized column, the explicit governed alias overrides the operational default and must pass the ordinary exact uniqueness/shadowing rules without automatic suffix repair. For a previously materialized COL, RESET COL ""<reference>"" ALIAS restores this same deterministic operational default from the exact recorded source_header and physical source ordinal. An oversized recorded header therefore restores its deterministic fallback/disambiguated operational name rather than inserting the potentially very long exact header into the alias field. A short empty/colliding source-header default still refuses rather than inventing a substitute.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.8,"Ordinary rematerialization preserves Store metadata, inherited RID, and inherited COL alias",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If a newly materialized column's exact logical key already exists in the inherited Store MAP, Data Sculptor must preserve that row's current COL alias unless the Work Order explicitly changes it. The successor MAP replaces only that logical row's column_filename with the newly created physical COL artifact filename. Ordinary rematerialization must preserve the inherited Store's exact common source_filename and rid_filename . It must not silently create a different Store, replace the Store RID, revert a user-facing Store/RID alias, or revert a COL alias to its source header. Every row in the successor MAP continues to carry that same common Store source_filename . WASM-002 has no executable operation that replaces rid_filename while preserving the same Store lineage. A different RID filename therefore cannot be introduced as ordinary successor-state continuity in this build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.9,Store MAP serialization is deterministic UTF-8 CSV,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Store MAP CSV files are encoded as UTF-8 without BOM and use LF ( 0x0A ) record termination. The exact eight-field header in W002-STOR-019.6 is written once as the first row. Fields use standard CSV quoting semantics: a field containing comma, double quote, CR, or LF is enclosed in double quotes, and embedded double quotes are doubled. No locale-dependent formatting is permitted. Every data row in one MAP must contain byte-for-byte identical values for store_alias , rid_filename , rid_alias , and source_filename . Mapping rows are written deterministically by ascending numeric source_column_number , then ascending UTF-8 byte order of source_header . Because one valid Store MAP has exactly one common source_filename , that field is not needed as a leading row-sort discriminator. Two rows with the same logical source-column key (source_filename, source_column_number, source_header) are invalid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.10,Only a complete validated Store MAP is eligible for inheritance,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A canonical MAP filename alone does not make a file a structurally valid Store MAP. For Store-MAP structural validity , the MAP artifact itself must be readable as complete UTF-8, have the exact eight-column schema, parse deterministically, satisfy Store-level consistency, lineage, deterministic row-order, mapping-key, and alias constraints, and carry structurally valid governed RID/COL filename bindings. The present health of the referenced RID/COL artifacts is a separate question and does not determine whether the MAP itself is structurally valid. A Store MAP remains part of governed Store history when its own bytes, schema, lineage facts, and deterministic structural rules are valid even if a referenced RID or COL later becomes missing or invalid. Referenced-artifact damage therefore does not make the current structurally valid Store MAP disappear and does not by itself cause fallback to an older MAP. F-03 current Store MAP selection Current-state selection is performed independently within one exact Store lineage. Only structurally valid Store MAP artifacts participate. Among those MAPs, the ordinary frozen chronology rule selects the unique structurally valid MAP with the greatest canonical UTC millisecond timestamp. A structurally malformed newer MAP is never current. If a newer canonical MAP artifact is structurally malformed, Data Sculptor uses the greatest earlier structurally valid Store MAP in that same lineage, if one exists, and reports the malformed newer artifact through governed Help/evidence surfaces. This fallback applies to structural MAP invalidity only. It does not apply merely because a structurally valid current MAP references a damaged RID or COL. If two or more structurally valid MAPs share the greatest canonical UTC millisecond timestamp, current authority is ambiguous and selection refuses rather than breaking the tie by UUID, discovery order, directory order, or filesystem modified time. P3-07 routing distinction: Store-MAP inheritance eligibility is stricter than lineage discovery. A Store lineage participates in exact- SOURCE routing when at least one Store MAP in that lineage is structurally valid, even if the current Store later evaluates DEGRADED or INVALID . Referenced RID/COL health is evaluated after routing and may cause refusal; it must not make an already discoverable lineage disappear. For successor publication, after the required RID/COL physical promotions have succeeded, Data Sculptor uses the already-established publication-transaction UTC and allocates a MAP-specific UUID before opening the complete deterministic MAP CSV under its governed SCR candidate identity. The SCR filename therefore already carries the exact UTC, UUID, and .csv extension intended for the final MAP identity. The candidate is closed successfully, reopened, and validated for bytes, schema, Store-level consistency, aliases, RID binding, COL bindings, deterministic row order, and all other MAP eligibility rules while it remains SCR . Only after that validation succeeds may Data Sculptor promote the candidate by host rename that changes only the three-letter semantic class token from SCR to MAP . The candidate bytes, UTC, UUID, and extension must remain unchanged across promotion. The successful rename is the publication/commit point. If validation or rename fails, no successor MAP becomes eligible/current; the candidate remains or is retained as visible non-authoritative SCR evidence. Store-aware automatic selection therefore continues to use the greatest earlier valid MAP in the same Store lineage, if one exists, while Help reports the failed candidate/publication rather than silently treating it as current state. P3-06 governed artifact-validation tiers. Store-health status and full content validity are distinct assurances. The following two tiers are normative for WASM-002: Tier 1 — Store-health structural validation. Used for routine Store status, source routing, historical-MAP health gates, inheritance decisions that do not consume analytical artifact contents, and alias-only maintenance. The selected Store MAP itself is fully parsed and structurally validated because it is the compact authority for the snapshot. A referenced RID passes Tier 1 only when the exact MAP-bound governed RID filename is present and readable, the bytes begin with exactly one UTF-8 BOM, the first logical record is a canonical N=<value> header, the final byte is LF, and the physical byte length equals the deterministic length implied by the canonical RID representation for that declared N . Tier 1 does not rescan every RID data record merely to perform routine status or alias work. A referenced COL passes Tier 1 only when the exact MAP-bound governed COL filename is present and readable, begins with exactly one UTF-8 BOM, exposes the canonical one-column CSV header whose decoded value exactly equals the MAP row's recorded source_header , and ends with LF. Tier 1 does not stream every COL value merely to establish routine Store health. Tier 2 — full artifact validation. Used whenever an operation actually consumes RID/COL contents, for complete validation of newly created candidates before commit, and by REPAIR MAP after the repair operation has been validly entered. A RID passes Tier 2 only when a full stream proves the canonical N=<value> header, exactly N data records, and exact ordered values 1..N . A COL passes Tier 2 only when a full stream proves canonical one-column CSV encoding/serialization, the exact expected header, and exactly N logical data records aligned to the Store RID. VALID , DEGRADED , and INVALID are Store-health states evaluated from the governed current snapshot using the required validation tier; they are not claims of cryptographic historical identity. When REPAIR MAP is validly invoked, it must perform Tier 2 validation of the RID and every mapped COL that would survive into the successor. The deterministic repair result removes exactly the mapped COL bindings that fail that Tier 2 check, subject to the separately frozen refusal when no mapped COL would remain. Two implementations presented with the same bytes must therefore identify the same repair set. External restoration boundary: a file placed back under an original governed RID/COL physical filename may re-enter use only when it passes the validation tier required by the operation. Filename equality plus governed validation is sufficient for operation eligibility under this WASM-002 boundary; it is not proof that the restored bytes are the historical original bytes. Stronger historical-byte identity requires separate authoritative fingerprint evidence. P3-10 terminology boundary: Store-state repair is REPAIR MAP . Work Order alias-registry repair is REPAIR WORK ORDER REGISTRY . These are distinct governed operations and the integrated specification must not describe a Store REPAIR MAP Work Order as a “registry-repair Work Order.” This corrects wording only; it does not change either operation's frozen semantics. F-08 / F-03 REPAIR MAP Work Order structure and target precondition: SUITCASE: .
WORK ORDER AS ""Repair Crime Store""
MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""
REPAIR MAP Exactly one MAP ""<filename>"" clause is mandatory. It names the exact physical filename of one structurally valid Store MAP. At Run time, that named MAP must be the current structurally valid Store MAP for exactly one lineage and the target Store must currently evaluate DEGRADED . A historical Store MAP, WKO MAP, missing MAP, malformed MAP, ambiguous equal-latest current state, MAP from an unsupported profile, or target Store that does not evaluate DEGRADED refuses. No SOURCE , Store/RID/COL alias selector or mutation, KEEP , materialization, conversion, Inventory, registry repair, cataloging, or composition clause is supplied in the same WKO. The analyst selects the Store by exact current Store MAP identity; Data Sculptor determines which mapped non-RID COL bindings are broken. The terminal DS-STEPS clause is REPAIR MAP ; the Receipt operation token is separately REPAIR_MAP . P2-03 monotonic eligibility boundary: structural validity/eligibility and chronology are separate. A structurally valid future-dated Store MAP remains a structurally valid MAP and participates in current-state selection. It is not demoted merely because the host clock is presently earlier. The monotonic guard applies when publishing a successor: truthful observed transaction UTC must be strictly greater than the chronology predecessor UTC before any successor state may commit. P2-04 closure — validation depth is now complete. The Tier-1/Tier-2 rules in this requirement are the complete WASM-002 oracle for deciding whether a MAP-bound RID/COL is sufficiently valid for the operation being attempted. Tier 1 is intentionally bounded and is used only by operations that do not consume RID/COL analytical contents. Tier 2 is a full streaming validation and is mandatory before an operation relies on RID/COL contents, for newly created candidates before commit, and for REPAIR MAP . REPAIR MAP determinism. Once a valid REPAIR MAP operation is entered, Data Sculptor performs Tier 2 on the Store RID and on every mapped COL. The repair successor removes exactly those mapped COL bindings whose physical COL artifacts fail Tier 2, preserves exactly those that pass Tier 2, and still refuses if zero mapped COL bindings would remain. No shallower Tier-1 result may decide the repair set. F-03 repair semantics: after target validation, Data Sculptor confirms the named MAP is current for exactly one Store lineage, confirms the referenced RID is valid, identifies every mapped non-RID COL that is missing or invalid under the required repair validation tier, preserves every valid COL binding unchanged, removes exactly the broken COL bindings from the successor candidate, preserves the exact Store lineage RID identity and remaining Store/RID metadata, validates the complete successor MAP candidate, and publishes the successor only if every repair gate succeeds. REPAIR MAP does not reread or regenerate the source CSV, rematerialize a lost COL, regenerate the RID, or edit the predecessor MAP in place. F-03 all-COLs-broken refusal: if removing the broken bindings would leave zero COL mapping rows, REPAIR MAP refuses. No zero-COL Store MAP is introduced, no special anchor row is invented, no successor MAP is published, and the Store remains DEGRADED . The existing current structurally valid MAP and RID continue to anchor the visible lineage. Identity boundary. Passing Tier 1 or Tier 2 proves only that the currently visible file under the exact governed filename satisfies the applicable WASM-002 validation contract. It does not prove that those bytes are historically identical to bytes previously present under that filename. Cryptographic historical-byte identity belongs to separately governed fingerprint evidence rather than ordinary Store health. F-15 reference-bounded eligibility: Store-MAP structural validity and inheritance eligibility are determined from the MAP artifact itself plus the governed artifacts and values that the MAP explicitly binds or that its profile explicitly requires for the validation tier being applied. Unrelated Suitcase files, unrelated Store lineages, WKOs, Receipts, Inventories, CAT/HLP/CER artifacts, analyst-owned files, directory enumeration order, and unrelated-file count cannot by their mere presence or later appearance make an already-published Store MAP eligible or ineligible. Alias-shadowing validation is a successor-publication check under W002-STOR-020; it is not a continuing ambient scan that retroactively invalidates historical MAPs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.11,The MAP-bound RID filename is the stable physical Store identity anchor in WASM-002,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, Data Sculptor does not allocate a second permanent Store UUID in addition to governed RID/MAP evidence. The exact governed rid_filename created when the Store is established is the stable physical anchor used to distinguish that Store's MAP lineage from other Stores in the same Suitcase, and every ordinary successor MAP repeats it exactly. Within any one MAP, every row must repeat the same exact current rid_filename ; disagreement is invalid. Across WASM-002 successor MAPs, a different RID filename denotes a different Store row universe and must not be silently treated as same-Store continuation. A later PRD revision may define an explicit governed recovery transition if Red5Sorcery chooses to support replacement of a damaged RID while preserving logical continuity. No such transition is executable in WASM-002.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.12,First Store MAP has deterministic Store and RID aliases,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When the first successful materialization establishes a Store, its first Store MAP must initialize store_alias to the exact common source_filename and rid_alias to the literal RID . Those are the deterministic Store and RID default aliases. A later alias-only Work Order may replace them with STORE AS ""<alias>"" and RID AS ""<alias>"" , clear them with CLEAR STORE ALIAS / CLEAR RID ALIAS , or restore these defaults with RESET STORE ALIAS / RESET RID ALIAS under W002-WKO-012.1 through W002-WKO-012.6. None of those operations changes the common source_filename , rid_filename , RID bytes, COL bytes, or prior MAP history.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-001,CAT is the governed collection-level Store Catalog artifact,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"WASM-002 shall define CAT as a governed Data Sculptor artifact class for cataloging a collection of CSV Stores inside one active Suitcase. CAT exists to let an analyst orient across many independently governed Stores without opening every MAP individually. The scaling invariant is: MAP governs locally; CAT orients globally. CAT is an index over governed Store state, not a replacement for MAP and not a second Store authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-002,CAT may reference many Stores while every MAP still governs exactly one Store,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"A CAT may contain entries for many Store lineages in the active Suitcase. Every MAP referenced by CAT still governs exactly one Store lineage under the frozen one-Store-per-MAP rule. CAT must not combine multiple Stores into one MAP, synthesize a shared Store state, or centralize Store semantics that remain governed independently by each Store's MAP lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-003,CAT has one governed CSV representation and immutable snapshot identity,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The WASM-002 Store Catalog has one durable representation: UTF-8 CSV. WASM-002 shall not emit separate HTML and CSV companion CAT artifacts for one catalog snapshot. Each successful catalog publication creates one immutable governed artifact named exactly __DS__CAT__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv . A later catalog run publishes a new CAT snapshot; earlier CAT artifacts remain visible history and are not overwritten or deleted merely because a newer snapshot exists. For orientation, the directory may identify the newest structurally valid CAT snapshot by the canonical UTC token. If two or more structurally valid CAT artifacts share the greatest canonical UTC timestamp, the UI must not invent chronology from UUID, discovery order, or filesystem modified time; it must surface the ambiguity and may present the tied CAT artifacts together until a later governed catalog run publishes an unambiguous newer snapshot. F-14 publication: CAT is first written as __DS__SCR__<UTC>__<UUID>.csv using the UTC/UUID intended for the final CAT. The complete candidate must close, reopen, and validate the exact five-column schema, deterministic row ordering, row count and CSV serialization before the class token may be renamed to CAT . A failed candidate remains SCR/non-authoritative and must not be selected as a catalog snapshot.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-004,CAT CSV schema and row order are exact and deterministic,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The canonical CAT header row is exactly: store_alias,source_filename,rid_filename,map_filename,store_health Each data row describes one routable Store lineage using values derived from the authoritative current structurally valid Store MAP selected under the existing Store rules: store_alias — current human-facing Store identity; source_filename — the one common exact source filename carried by that Store MAP and used for Store routing; rid_filename — exact immutable governed RID filename that physically identifies the Store lineage; map_filename — exact current structurally valid Store MAP used to derive the row; and store_health — the Store health evaluated during this CATALOG STORES run, exactly one of VALID , DEGRADED , or INVALID . store_health is snapshot orientation metadata, not MAP health and not an independent health authority. If the Suitcase later changes, an older CAT row continues to report the health value observed when that CAT was created. CAT rows are sorted by ascending exact UTF-8 bytes of map_filename . The header is not part of that ordering.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-005,CAT is reconstructible and never becomes Store authority,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"CAT shall be reconstructible from authoritative Store MAP artifacts and the governed Store-health evaluation applied when CATALOG STORES runs. CAT must never be consulted to decide Store routing, inheritance, Store health, repair eligibility, current MAP selection, RID/COL validity, or whether a new Store may be established. If a CAT row conflicts with authoritative MAP/Store state, current governed state wins and the CAT is stale/inconsistent. A stale CAT remains an inspectable historical governed artifact but must not be treated as current Store truth. CAT is not automatically updated by materialization, repair, alias change, or any other Store-changing operation. The analyst creates a fresh catalog explicitly by running a new CATALOG STORES Work Order; success publishes a new immutable CAT snapshot and leaves earlier CAT snapshots visible history.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-006,CATALOG STORES is the standalone governed Work Order operation,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 Work Order form is: SUITCASE: .
WORK ORDER AS ""Catalog Stores""
CATALOG STORES CATALOG STORES is one standalone top-level operation. It is initiated only by an explicit analyst Work Order. No materialization, repair, alias update, conversion, or other governed operation automatically creates, rewrites, or refreshes CAT. The operation scans authoritative governed Store MAP state, evaluates each cataloged Store's current health, and publishes one CAT snapshot plus the normal canonical Receipt. It does not mutate any Store or MAP. It must not also request materialization, conversion, alias mutation, repair, Inventory, Work Order composition, or another consequential operation in the same WKO. The canonical Receipt operation token is CATALOG_STORES .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-007,CATALOG STORES derives one row per routable Store lineage from authoritative MAP state,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The catalog scan shall identify every routable Store lineage using the same structurally-valid-MAP routing definition already frozen for WASM-002. For each routable lineage, Data Sculptor evaluates current Store health exactly under W002-STOR-019.2, using the current structurally valid Store MAP selected under W002-STOR-019.10 and the applicable validation tier, and records exactly one of VALID , DEGRADED , or INVALID . Catalog presence is orientation, not permission to perform another operation. Exactly one CAT row is emitted for each routable Store lineage, derived from that lineage's authoritative current structurally valid Store MAP and the Store-health result observed during this catalog run. If the complete authoritative collection state cannot be determined unambiguously, the operation must refuse rather than publish a knowingly incomplete or guessed CAT. CATALOG STORES is read-only with respect to all pre-existing Store, RID, COL, MAP, source, WKO, and other Suitcase artifacts. It does not repair or mutate them.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-008,CAT publication is all-or-refuse and historical CAT snapshots remain visible,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"After the complete deterministic CAT row set is established, publication follows the governed all-or-refuse artifact path: write the candidate under governed scratch, close and reopen it, validate its exact filename, UTF-8/LF CSV structure, exact header, deterministic row count/order, and row references, then promote the final CAT artifact. The CAT is not successfully published until final promotion succeeds. A publication refusal leaves prior CAT snapshots and all Store/MAP state unchanged. The Receipt records whether the catalog entry count was established and whether a final CAT filename was published.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-001,CAT and MAP discovery reuse the existing Suitcase Directory,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,WASM-002 shall reuse the existing Data Sculptor Suitcase Directory for CAT and MAP discovery and inspection. A separate CAT/MAP browser panel shall not be added.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-002,CAT and MAP artifacts are first-ranked in the existing directory,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The newest unambiguous structurally valid CAT snapshot, or any tied newest CAT candidates when chronology is ambiguous, and all Store MAP artifacts shall be surfaced prominently at the top of the existing Suitcase Directory ahead of ordinary Suitcase files. The presentation may be pinned, grouped, or otherwise first-ranked, provided the priority is obvious and deterministic.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-003,CAT and MAP contents are immediately viewable from the existing HTML UI,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,The analyst shall be able to select a visible CAT or MAP entry and inspect its contents through the existing read-only HTML UI without first locating or opening the artifact through the operating-system file browser.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-004,CAT/MAP prominence preserves ordinary read-only Suitcase filtering,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The Suitcase Directory may continue to provide read-only filtered views of other Suitcase files. CAT/MAP prominence must not remove, replace, or weaken the existing ability to inspect the rest of the flat Suitcase.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-005,Directory browsing and inspection do not require a Work Order,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"Browsing, sorting, UI filtering, selecting, opening, and viewing Suitcase files are read-only inspection actions and shall not require a Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-006,Read-only directory filtering is not governed SEARCH,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"Read-only UI filtering is not the same operation as governed SEARCH . Governed SEARCH, ZIP creation, metadata changes, repairs, CAT regeneration, and every other consequential state change remain subject to the applicable Work Order and Receipt discipline.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-007,"The directory cannot mutate CAT, MAP, Store, or Suitcase state",W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The Suitcase Directory shall not edit, rename, delete, repair, replace, regenerate, or otherwise mutate CAT, MAP, Store, or Suitcase state through direct GUI manipulation. Consequential changes occur only through explicit governed operations or analyst-owned filesystem actions already permitted by the canonical contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-008,The CAT/MAP directory view must remain practical at large collection scale,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The CAT/MAP presentation shall make collections containing dozens or hundreds of Stores practical to inspect. An analyst must be able to understand what Stores exist, which current MAP describes each Store, and which source file each Store governs without manually opening every MAP artifact through the operating-system file browser.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-ACC-001,CAT acceptance proves collection-scale orientation without centralizing Store authority,W002-CAT-ACC,W002-CAT,WASM-002,UNDER REVIEW,—,"Acceptance must include a MusicBrainz-scale fixture containing 177 routable CSV Store lineages, each with its own authoritative current Store MAP. One explicit analyst-run CATALOG STORES Work Order must publish exactly one CAT snapshot containing exactly 177 data rows under the frozen five-column schema store_alias,source_filename,rid_filename,map_filename,store_health and deterministic MAP-filename ordering. The fixture must include Stores that evaluate VALID , DEGRADED , and INVALID while retaining structurally valid current MAPs, and the CAT must record the exact health observed for each Store when the catalog run occurs. The CAT must not expose a separate MAP-health field. The existing Suitcase Directory must surface CAT and MAP artifacts ahead of ordinary files; the analyst must be able to open CAT, inspect the collection, select and view MAP artifacts, sort/filter the directory, and inspect other Suitcase files without a Work Order. No direct GUI mutation path may be exposed. Acceptance must alter authoritative MAP/Store state after the first CAT publication and prove that the earlier CAT is neither rewritten nor automatically refreshed. It remains visible and becomes stale/inconsistent where appropriate. Only a later explicit CATALOG STORES Work Order may reconstruct the collection and publish a new immutable CAT snapshot. The linked WASM-003 DIR behavior remains outside the WASM-002 implementation scope: later DIR requirements auto-populate human-readable CAT/MAP descriptions, but those descriptions never become authority over CAT, MAP, or Store semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-020,"Store, RID, and COL aliases remain human-facing metadata separate from physical identity",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Aliases are governed human-facing metadata. Creating, changing, clearing, or replacing an alias must not rename or rewrite the underlying artifact. Within one Store MAP, every non-empty COL alias and the non-empty rid_alias must be unambiguous within the row-addressable artifact alias namespace under the exact Unicode scalar-value comparison rule in PB-STOR-010. F-15 publication-time shadowing boundary: alias uniqueness and physical-name shadowing are validated when a candidate successor Store MAP is being published, against the comparison domain applicable to that one Store snapshot and the then-visible governed physical targets it makes row-addressable. If an alias would exactly collide with another addressable alias or physical filename in that publication domain, publication refuses. After a Store MAP has been validly published, the later appearance, disappearance, rename, or copying-in of an unrelated Suitcase file does not retroactively make that immutable MAP structurally invalid or ineligible. A later textual reference can still become ambiguous at resolution time under W002-STOR-021; that ambiguity causes the later operation to refuse rather than changing the historical MAP's validity. The store_alias names the Store as a whole and is separate from the field/COL alias namespace. Alias mutation occurs through a governed Work Order, not through an editable GUI field. Exact cross-Store Store-alias uniqueness and future selection-by-Store-alias syntax remain outside this freeze.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-021,Work Order resolution binds one exact Store MAP and physical targets,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A saved Work Order may refer to governed materialized columns by exact physical filename or by a unique COL alias from one selected Store MAP. The canonical explicit Store-MAP selector is MAP ""<exact Store MAP filename>"" under W002-STOR-019.3 and W002-WKO-012.3. If that clause is present and valid, exactly that Store snapshot is used. Otherwise Data Sculptor applies the Store-aware source-qualified selection rule in W002-STOR-019.2. All textual physical-filename and COL-alias comparisons in this resolution step use exact Unicode scalar-value sequence equality under PB-STOR-010: no case folding, Unicode normalization, trimming, locale equivalence, or filesystem enumeration heuristic is permitted. Resolution is bounded to the selected Store snapshot and the physical targets/aliases that are addressable through that snapshot. If the supplied text has no exact target, resolution refuses. If it has more than one exact possible target in that domain—for example because a currently visible physical filename and a current alias are both exact matches—resolution also refuses. Data Sculptor must not choose filename over alias, alias over filename, first-found entry, directory order, modified time, UUID, or any other tie-break heuristic. Before execution, Data Sculptor must record the exact physical Store MAP identity when one is used, bind the run to its exact rid_filename , and resolve aliases deterministically to physical COL artifacts. The selected Store MAP must remain fixed for the run even if a newer MAP is created during that same run. This protects Store/selection continuity but does not by itself claim that bytes stored under an analyst-owned source filename are cryptographically identical across different runs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022,Each successful Suitcase validation publishes one retained governed CER HTML certificate,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A selected directory becomes a validated Suitcase only when Data Sculptor successfully creates, completely writes, and closes one governed CER HTML Suitcase Validation Certificate in that directory. The certificate itself is the validation artifact and remains visible in the flat Suitcase as durable evidence. No validation-only delete or rename is required. Failure to create, completely write, or close the certificate means the directory has not passed Suitcase validation and analytical execution remains locked. F-14 CER exception: the CER is deliberately not staged as SCR . Suitcase validation is specifically the direct create/write/close test of the final canonical CER identity in the selected directory. Inserting an SCR-to-CER rename would test a different publication path and is therefore forbidden for this validation step. A successful CER does not pre-certify later SCR-to-final renames for other artifact classes. F-24 CER lifecycle: every successful explicit Suitcase selection and validation publishes exactly one fresh immutable CER with a new governed UTC+UUID identity. Data Sculptor must not satisfy a new validation event by reusing an earlier CER. Every prior valid CER remains a standalone historical artifact under its original governed filename and exact bytes. WASM-002 performs no automatic CER deletion, replacement, compaction, or CER-history ZIP packaging. Historical CERs are not housekeeping candidates merely because a newer CER exists. Any later archival or packaging capability must be separately governed and explicitly invoked; it is not part of the WASM-002 validation lifecycle.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.1,Suitcase Validation Certificate physical identity and longest-name path gate,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The exact certificate filename is __DS__CER__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html , using the canonical UTC millisecond token and canonical lowercase hyphenated UUID v4. Data Sculptor chooses the filename; the analyst does not supply or edit it. The CER create/write/close test begins only after the browser host has satisfied the required user-selected writable-directory capability in W002-PLAT-001. A browser that cannot expose that capability produces a host-capability refusal before folder validation; that condition is not evidence that any particular directory is unwritable or filename-incompatible. WASM-002 path/filename acceptance must derive the maximum filename length from every governed final-artifact filename form and every governed SCR staging form that this build can actually emit. Under the current contract, the maximum is 73 ASCII bytes/characters : the governed .html CER/HLP final forms and an SCR candidate reserved for a .html final artifact have that length. The canonical CER filename therefore exercises the current maximum emitted filename length during the create/write/close validation test. On a supported host, successful create/write/close of this canonical governed HTML filename is the WASM-002 folder filename/path compatibility test for the current emitted-name maximum. Data Sculptor does not maintain a product-level table of operating-system numeric path maxima and must not truncate, abbreviate, hash-shorten, or otherwise mutate a governed filename to fit a host path limitation. If the certificate cannot be created under its canonical name after a directory has actually been selected through the supported-host contract, the selected directory does not pass validation. If a future PRD revision introduces an emitted final or staging filename longer than the current CER/HLP/SCR-HTML maximum, acceptance must detect that change and explicitly exercise the new maximum before the build may rely on this path-compatibility claim.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.2,Suitcase Validation Certificate semantic content,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The HTML certificate uses the canonical built-in Data Sculptor presentation and must visibly contain, at minimum: SUITCASE VALIDATION CERTIFICATE RESULT: PASS SUITCASE: . UTC: <canonical certificate UTC> UUID: <certificate UUID> ARTIFACT: <full governed certificate filename> TEST: CREATE_WRITE_CLOSE It must state that Data Sculptor successfully created, completely wrote, and closed this governed HTML certificate in the selected Suitcase. It must state that this establishes that the selected directory was writable by Data Sculptor at the recorded UTC and accepted the governed artifact filename used for the certificate. It must also state that the certificate does not certify available disk capacity, guarantee success of future analytical operations, or certify later SCR -to-final-class publication/rename operations. The semantic record uses SUITCASE: . and must not persist an absolute machine-specific path merely to prove validation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.3,Suitcase Validation Certificate uses the canonical built-in presentation in WASM-002,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The certificate is a human-facing HTML CER artifact and uses the canonical built-in Red5Sorcery/Data Sculptor presentation in WASM-002. Presentation must never change RESULT , SUITCASE , UTC, UUID, artifact identity, TEST , validation meaning, or limitation facts. Configurable Brand Manifest application to CER artifacts is deferred to V1-BACKLOG / a future build and is not required for WASM-002 Suitcase validation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-023,Non-Store governed artifacts use class-specific all-or-refuse publication profiles,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Except for the deliberate CER Suitcase-validation path below, WASM-002 does not place a newly generated durable artifact into its final semantic class merely because candidate bytes exist. The complete candidate is first written under the governed SCR identity defined by W002-STOR-023.1, closed, reopened, and validated against the target class contract. Only a candidate that passes its class-specific publication predicate may be renamed into the intended final class. A final-class filename therefore records successful class publication, not broader authority where a separate MAP/registry relationship governs authority. F-33 reserved-class boundary: DGN , RCV , BRD , and LCK are registered but not emitted by WASM-002, so they do not appear as publication profiles in this table and have no WASM-002 producer here. Final class Final serialization / identity Publication predicate Authority boundary WKO __DS__WKO__<UTC>__<UUID>.txt The complete candidate obeys the saved-Work-Order lifecycle and parses completely under exactly one WASM-002 executable operation grammar with the required SUITCASE: . , exactly one non-whitespace WORK ORDER AS alias, and the governed lexical/comment rules. Applicable save-time alias/registry gates must also pass before the save transaction may commit. Promotion proves a valid immutable WKO artifact. Alias-registry authority is not committed until the complete successor WKO MAP is successfully published under W002-STOR-018.3. RCP __DS__RCP__<UTC>__<UUID>.txt The complete candidate validates against W002-RCP-005 through W002-RCP-008: exact deterministic TXT serialization, common envelope, applicable operation-specific key table, governed absence semantics, and created-artifact tail. Publication creates durable run evidence only. It does not retroactively create or change analytical state. HLP __DS__HLP__<UTC>__<UUID>.html The complete self-contained HTML satisfies the HLP disclosure, presentation, provenance, embedded-JSON, lineage and semantic-parity rules in W002-HELP-009 and related Help requirements. Publication creates durable Help/support evidence. It does not override the underlying diagnostic event or analytical state. CVT __DS__CVT__<UTC>__<UUID>.csv The bounded Windows-1252 conversion completes, the original analyst-owned source remains unchanged, the converted bytes pass the governed strict UTF-8 requirement, and the candidate closes/reopens successfully. Structural CSV interpretation remains a later certification/materialization concern. The published exact CVT filename is a new immutable governed source identity for later routing under W002-CONV-004. INV __DS__INV__<UTC>__<UUID>.txt The complete inventory scan has established the governed entry set and the candidate validates the deterministic INV serialization, count, metadata availability and ordering rules. Publication creates an immutable inventory snapshot; it is evidence/orientation, not Store authority. CAT __DS__CAT__<UTC>__<UUID>.csv The authoritative MAP discovery/evaluation pass has completed and the candidate validates the exact five-column CAT schema, row count, row ordering and deterministic CSV rules. Publication creates an immutable collection-level orientation snapshot. MAP remains authoritative for each Store. CER __DS__CER__<UTC>__<UUID>.html Deliberate exception: Suitcase validation directly creates, completely writes and successfully closes the final CER identity under W002-STOR-022 through W002-STOR-022.3. No SCR staging/rename is inserted into this test. The CER proves that canonical governed create/write/close succeeded in the selected directory at that recorded moment. It does not pre-certify later SCR-to-final publication. RID, COL, Store MAP and WKO MAP publication retain their specialized transaction/commit rules elsewhere in this PRD. W002-STOR-023 does not replace those state-publication contracts; W002-STOR-023.1 supplies the shared SCR candidate identity and retained-failure-evidence boundary they may reference.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-023.1,SCR candidates preserve intended final identity; retained failure evidence remains non-authoritative,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical candidate filename for a staged governed artifact is: __DS__SCR__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.<final-extension> The SCR candidate uses the exact UTC token, UUID and extension reserved for its intended final artifact. Successful publication changes only the three-letter semantic class token from SCR to the intended final class. For example, an RCP candidate __DS__SCR__20261006T190000000Z__<uuid>.txt may become __DS__RCP__20261006T190000000Z__<uuid>.txt only after the complete candidate has been closed, reopened and validated against the RCP publication predicate. The rename must not alter candidate bytes, UTC, UUID or extension. An SCR filename never by itself confers final-class validity, Store membership, registry authority, execution authority, or durable final-class evidence status. A retained SCR whose bytes happen to satisfy a target validator after an interrupted or refused transaction must not be auto-promoted, silently adopted, or treated as if the missing publication step occurred. F-33 retained-failure-evidence boundary: when a handled failure leaves one or more SCR candidates or other staged bytes that cannot be safely removed or restored, they must remain visible only as non-authoritative SCR evidence. WASM-002 does not publish an RCV recovery manifest. Retention must not complete or simulate the failed publication step, and the governed diagnostic/Help path must report the failure using only facts actually established. A retained or orphaned SCR remains non-authoritative even if its bytes later validate. Data Sculptor must not infer an intended final class solely from extension or byte content, must not rename or promote the SCR merely because it survives a later scan, and must not create a replacement RCV sidecar to manufacture attribution that the failed transaction did not durably preserve.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-011; CP-012; CP-013; CP-014; CP-015,"CP011 T-ACCEPTED, GIT BANKED — exact CVT-to-SCR candidate identity derivation only; full SCR lifecycle and publication contract remains open; CP012 T-ACCEPTED, GIT BANKED — canonical SCR staging filename recognition only; generic publication, recovery and authority remain unimplemented; CP013 T-ACCEPTED, GIT BANKED — explicit SCR-to-RCP final filename candidate derivation only; no complete SCR lifecycle, RCP validator, filesystem promotion, publication or authority; CP014 T-ACCEPTED, GIT BANKED — related RCP final-candidate lexical recognition only, no SCR creation or publication; CP015 T-ACCEPTED, GIT BANKED — pure lexical canonical SCR-to-RCP TXT filename-candidate pair matching only; no actual file/Receipt validation, promotion, publication or authority",e84ae5baeee05f9d5d30284c65b86eebba3c0f6a; efca04392940e398020a5c06b9ee50296c8a1fdd; 005a38ef5e876847c4c08901c18da9c18565fd6b; f5038a183f1d3dc31b0065571bf8ac8814b5d8a9; be997dc0dbd65fc370814c4a5f2d0f1254870572,"Evidence/CP-011/CP011_Scope_Lock.txt; Evidence/CP-011/CP011_RED_Test_Output.txt; Evidence/CP-011/CP011_GREEN_Test_Output.txt; Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt; Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt; Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt; Evidence/CP-011/CP011_Hash_Inventory_Verification.txt; Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt; Evidence/CP-011/CP011_Closing_Git_Review.txt; CP011_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-012/CP012_Scope_Lock.txt; Evidence/CP-012/CP012_RED_Test_Output.txt; Evidence/CP-012/CP012_GREEN_Test_Output.txt (initial 5/6, retained); Evidence/CP-012/CP012_GREEN_Failure_Triage.txt; Evidence/CP-012/CP012_GREEN_Correction_Review.txt; Evidence/CP-012/CP012_GREEN2_Test_Output.txt; Evidence/CP-012/CP012_Full_Regression_Test_Output.txt; Evidence/CP-012/CP012_WASM_Build_Output.txt; Evidence/CP-012/CP012_Final_Rustfmt_Check.txt; Evidence/CP-012/CP012_Hash_Inventory_Verification.txt; Evidence/CP-012/CP012_Supplementary_Hash_Verification.txt; Evidence/CP-012/CP012_Post_Staging_Hash_Verification.txt; Evidence/CP-012/CP012_Closing_Git_Review.txt; CP012_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-013/CP013_Approved_Scope_Lock.txt; Evidence/CP-013/CP013_RED_Test_Output.txt; Evidence/CP-013/CP013_GREEN_Test_Output.txt; Evidence/CP-013/CP013_Full_Regression_Test_Output.txt; Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt; Evidence/CP-013/CP013_WASM_Build_Verification.txt; Evidence/CP-013/CP013_Hash_Inventory_Verification.txt; Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt; Evidence/CP-013/CP013_Closing_Hash_Verification.txt; Evidence/CP-013/CP013_Final_Staging_Verification.txt; Evidence/CP-013/CP013_Closing_Git_Review.txt; CP013_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip; CP014_Git_Banking_Record.txt (external closeout); Evidence/CP-015/ZIP/CP015_RED_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_GREEN_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_PostAmend_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_Full_Regression_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_WASM_Build_Output.txt.zip; Evidence/CP-015/ZIP/CP015_Final_Archive_Manifest.txt.zip; CP015_PostCommit_Verification.txt (external closeout)","CP011 Day066: public pure helper build_scr_candidate_filename_for_cvt(&str)->Option<String> accepts an exact canonical governed CVT .csv filename (via CP010 recognizer) and derives the paired SCR filename by substituting only class token CVT -> SCR, preserving exact UTC, UUIDv4 and lowercase .csv bytes; rejects wrong classes, paths, whitespace, malformed clock/date/UUID, extension and class case. Six targeted tests; RED expected E0432 exit 101; GREEN 6/6; post-format native regression 46/46; rustfmt recheck PASS; Rust 1.97.1 wasm32-unknown-unknown --lib build PASS; original 28/28 and combined 36/36 SHA-256 records verified. Two local scoped .gitattributes whitespace exceptions preserve Rustfmt/Git diagnostic TXT bytes; final Git staged check PASS. T-approved and Git banked e84ae5baeee05f9d5d30284c65b86eebba3c0f6a, 27 committed files, working tree clean. Lexical candidate-name pairing ONLY; no SCR creation, bytes, converter, transaction, close/reopen, validation/publication, retained SCR adoption, SOURCE authority or browser execution. Independent Claude implementation QA pending. CP012 Day066: pure public bool recognizer is_canonical_scr_filename_candidate(&str) validates exact uppercase SCR staging class via shared canonical immutable filename-token parser, with local rejection of whitespace and both path separators; accepts canonical .csv and .txt SCR candidates without assuming extension or bytes confer intended final class, validity, publication or authority. RED expected missing import E0432 exit 101. Initial GREEN 5/6 exposed trailing whitespace acceptance through generic extension grammar, retained verbatim; controlled CP012-local correction yielded 6/6 PASS. Full native regression 52/52 PASS, Rustfmt 12 Rust files checked/0 modified, canonical Rust 1.97.1 wasm32-unknown-unknown --lib build PASS (not browser execution). Primary independent SHA256/size inventory 29/29 PASS; supplementary original 4/4 PASS; post-staging 6-record amendment independently verified following narrowly scoped trailing-space and blank-at-EOF git attributes for preserved diagnostic evidence; final staged Git whitespace exit 0. T approved and banked Git commit efca04392940e398020a5c06b9ee50296c8a1fdd (28 committed files; master clean). Previous generic canonical parser unchanged. W002-STOR-023.1 remains PARTIAL, no filesystem creation, close/reopen, class publication, retained/orphan SCR adoption or recovery, SOURCE authority, or independent Claude implementation QA claimed. CP013 Day066: pure public function build_final_filename_candidate_for_scr(&str, &str)->Option<String> accepts only a canonical SCR staging filename with exact lowercase .txt serialization and explicit intended_final_class == ""RCP""; derives RCP final filename candidate by substituting the SCR semantic-class token only, preserving original UTC token, UUID and extension. Rejects all other class intentions, malformed or non-SCR staging names, paths/whitespace, wrong extension or case. Six intentional RED tests (unresolved E0432 before implementation), six GREEN targeted passes; full native 58/58 PASS; Rust 1.97.1 rustfmt check PASS and wasm32-unknown-unknown --lib build PASS (not browser runtime). Primary 21/21, supplementary 27/27 before attribute revisions; post-normalization 32/32 and closing 37/37 SHA-256 identity/byte-preservation checks; 42/42 commit blobs verified, Git whitespace check exit 0 after directory-scoped CRLF-aware whitespace attributes and raw-byte preservation; staging failures and adjustments retained byte-for-byte. T accepted and Git banked 005a38ef5e876847c4c08901c18da9c18565fd6b (efca04392940e398020a5c06b9ee50296c8a1fdd parent), 42 files, clean tree and index. This covers only lexical candidate-name derivation under already-PARTIAL W002-STOR-023.1; W002-STOR-023 remains NOT_STARTED; no SCR creation, RCP contract validation, promotion, publication, retained/orphan handling, authority or recovery. No independent adversarial QA or accepted end-to-end requirements; Day066 OPEN. CP014 Day067: T-accepted, Git-banked lexical RCP .txt filename recognizer only. Pure is_canonical_rcp_filename_candidate(&str)->bool uses shared canonical envelope, rejects wrong class/extension/casing, malformed UTC/UUID, paths and whitespace. Six target GREEN passes; 64/64 native regression; Rustfmt and wasm32 library build PASS; 32 original-TXT-per-ZIP objects validated and committed unchanged. Commit f5038a183f1d3dc31b0065571bf8ac8814b5d8a9. No new Receipt timestamp generation, Receipt byte serialization, creation/promotion/publication or authority; independent implementation QA and browser runtime pending. CP015 Day067: T-approved pure is_matching_scr_rcp_filename_candidate_pair(&str,&str)->bool checks canonical SCR/RCP lowercase .txt candidates and exact timestamp/UUID pairing, reusing existing lexical recognizers and candidate derivation; rejects wrong classes/order, mismatched timestamps/UUID, paths, whitespace and noncanonical envelopes. Expected RED E0432 exit 101; six targeted GREEN PASS; T-approved formatting-only source+test amendment and recheck; full native regression 70/70 PASS, Rustfmt PASS, Rust 1.97.1 wasm32-unknown-unknown --lib compile PASS. Original TXT archived as 16 verified single-entry ZIPs; 18/18 committed Git blob identities checked; working tree clean. Banked at be997dc0dbd65fc370814c4a5f2d0f1254870572. No actual SCR/RCP file reads, Receipt content validation, timestamp generation, authority, promotion or publication; browser execution and independent implementation QA pending.",Day067,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001,Strict whole-file UTF-8 certification,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Before WASM-002 performs analytical CSV materialization, it must certify the complete selected source as valid UTF-8 using bounded processing.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.1,"Certification must examine the entire source, not merely a prefix, sample, BOM, or first analytical window.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.2,"UTF-8 validity must be determined across chunk boundaries, including incomplete multi-byte sequences that span adjacent input windows.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.3,"A UTF-8 BOM, when present, is parsing metadata and must not be treated as proof that the remainder of the source is valid UTF-8.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.4,Certification must preserve exact source-byte accounting.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.5,Certification must operate within the governed WASM memory budget.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Stage 1 UTF-8 certification must remain bounded independently of source byte length and must not buffer the complete source, CSV header, or CSV row set in memory. CSV column-count and operational-name rules belong to Stage 2 and must not be used to justify unbounded Stage-1 state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.6,Certification must produce deterministic PASS or FAIL for the same source bytes under the same frozen rules.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002,UTF-8 certification is a hard analytical gate,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,The WASM-002 analytical/materialization path must proceed only after successful UTF-8 certification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.1,"If UTF-8 certification fails, the current analytical Work Order must stop.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.2,The analytical engine must not silently switch to another decoder.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.3,The analytical engine must not continue materialization under an inferred or guessed source encoding.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.4,No Windows-1252 transcoding may occur as an implicit sub-step of the failed analytical Work Order.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003,Certification and materialization share one run-local selected source,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"For a governed WASM-002 analytical run, the browser host must resolve the Work Order source reference once and retain the same selected source instance across Stage 1 UTF-8 certification and Stage 2 materialization. The purpose of this binding is to prevent Stage 2 from accidentally consuming a different source than the one Stage 1 certified. It is a run-local continuity guarantee, not a claim of durable cryptographic identity across separate runs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.1,Stage 2 must not re-resolve or substitute the source,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"After Stage 1 begins, Stage 2 must not reacquire the analytical source by re-reading an alias mapping, re-resolving a filename/path, opening a newly selected browser file, or otherwise substituting another source instance. Stage 2 consumes the source instance already bound to the governed run.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.2,"Filename, alias, path, or byte length alone is not durable byte identity",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Filename equality, alias equality, path equality, timestamps, or exact byte length may be useful provenance facts but must not be presented as cryptographic proof that source bytes are identical across separate runs. WASM-002 makes no such automatic cross-run exact-byte claim.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.3,Ordinary WASM-002 source binding does not require automatic SHA-256,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,UTF-8 certification and ordinary column materialization must not automatically compute SHA-256 merely to establish WASM-002 source binding. The source-binding requirement is satisfied by preserving the same run-local selected source instance across the two stages. This rule does not prohibit SHA-256 where another explicit WASM-002 requirement governs integrity for a specific generated artifact. It applies to automatic hashing of ordinary analytical source data.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.4,Loss of run-local source continuity causes refusal,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"If the browser host cannot preserve the selected source instance from certification into materialization, or the source becomes unavailable before Stage 2 can consume it, the analytical run must refuse before materialization rather than silently reselect, substitute, or infer another source.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004,ASCII-first inline UTF-8 certification algorithm,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"WASM-002 must use an ASCII-first, strict inline UTF-8 certification algorithm or an equivalent implementation that preserves the same single-forward-scan semantics, bounded state, deterministic validity result, exact error location, and performance intent established by WASM-001b.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.1,The certifier must process the source in bounded windows and must not allocate memory proportional to source-file size.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.2,"The 4 MiB window used in WASM-001b is a proven reference point, not a frozen WASM-002 production constant.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Window size may be changed only if semantics and byte-identical certification outcomes remain invariant.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.3,"At the beginning of each window, any incomplete UTF-8 sequence carried from the preceding window must be resolved before the remaining bytes are treated as independent input.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.4,"When there is no pending cross-window sequence, consecutive bytes below 0x80 must be recognized as ASCII and certified directly because ASCII is a complete subset of UTF-8.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.5,An all-ASCII window with no pending cross-window sequence must be certifiable without submitting the same bytes to a second general UTF-8 decoder pass.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.6,"When a byte at or above 0x80 is encountered, the certifier must validate the UTF-8 sequence inline, then resume the ASCII-fast scan after the valid sequence.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.7,"The implementation must not require collecting all non-ASCII bytes, all non-ASCII runs, or all non-ASCII offsets for later validation.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.8,The implementation must not require a separate general-purpose string-decoder call for each non-ASCII sequence.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,An equivalent low-overhead strict validator is acceptable if it preserves the same governed result and bounded-state behavior.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.9,Cross-window state must be bounded to the information required for at most one incomplete UTF-8 sequence.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"No more than three source bytes may need to remain pending between windows, or an equivalent smaller state representation may be used.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.10,"On the first invalid UTF-8 sequence, certification must stop and report the exact absolute source-byte offset required by the frozen error contract.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"On the first invalid UTF-8 sequence, certification must stop and return FAIL . The governed UTF-8 refusal evidence is: FIRST_INVALID_BYTE_OFFSET — the zero-based absolute byte offset of the first byte of the invalid sequence , counted from the first physical source byte, including a permitted leading UTF-8 BOM when present; and STOP_REASON — exactly INVALID_UTF8_SEQUENCE . For an EOF-truncated multibyte sequence, FIRST_INVALID_BYTE_OFFSET is the absolute offset of that incomplete sequence's lead byte, not the EOF position. The certifier need not read the remainder of an already-invalid source. Input-window boundaries must not change the outcome, stop reason, or first-invalid offset. F-16 follow-on boundary: stopping strict UTF-8 certification at the first invalid sequence does not make the remainder of the source irrelevant to conversion advice. When the governing operation is MATERIALIZE and Stage 1 reaches FAIL , the analytical run remains refused; Data Sculptor then starts the separate read-only compatibility assessment in W002-CONV-002 from physical byte offset 0 of the same bound source instance. That second pass may read to EOF solely to determine converter compatibility. Stage 2 must not start.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.11,"At EOF, certification may return PASS only if every source byte has been consumed under the strict UTF-8 rules and no incomplete sequence remains pending.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"At EOF, certification may return PASS only if every physical source byte has been consumed under the strict UTF-8 rules and no incomplete sequence remains pending. The completed Stage-1 outcome vocabulary is exactly PASS and FAIL . PASS means strict whole-source UTF-8 certification completed successfully. FAIL means an invalid UTF-8 sequence was deterministically established under W002-ENC-004.10. The common Receipt absence tokens remain separate from those completed outcomes: NOT_RUN when Stage 1 never begins, and NOT_AVAILABLE when Stage 1 begins but a separate failure prevents a governed PASS/FAIL conclusion. NOT_APPLICABLE is not a completed value for STAGE1_UTF8_OUTCOME .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.12,"A UTF-8 BOM at absolute source offset zero may be recognized as BOM metadata after its bytes are validated, but the remaining source must still undergo complete certification.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.13,"The certifier must not perform CSV delimiter, quote, header, row, or analytical interpretation.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Certification answers only whether the complete source byte stream is valid UTF-8 under the frozen rules.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.14,Certification results must be independent of window boundaries.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Splitting the same valid or invalid source at different bounded window sizes must not change PASS/FAIL or the first invalid absolute byte offset.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.15,"The certifier must expose enough measured counters for acceptance evidence to reconcile source bytes read, windows/pushes processed, non-ASCII sequences encountered when counted, final pending state, and stop reason without requiring those counters to alter certification semantics.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005,Strict UTF-8 byte-sequence rules,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"The inline validator must implement strict modern UTF-8 validity, excluding overlong forms, UTF-16 surrogate code points, values above U+10FFFF, invalid lead bytes, invalid continuation bytes, and truncated sequences. F-07 stop-reason vocabulary: all strict UTF-8 invalidity classes governed by this requirement—lone continuation bytes, malformed continuation sequences, overlong forms, surrogate encodings, values above U+10FFFF, invalid lead bytes, and EOF-truncated sequences—serialize the single machine reason token INVALID_UTF8_SEQUENCE . The specific fixture category is acceptance evidence; the canonical stop reason intentionally does not duplicate validator-library-specific subcodes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.1,Single-byte ASCII is 0x00 through 0x7F.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.2,Two-byte sequences must begin with 0xC2 through 0xDF and be followed by exactly one continuation byte 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.3,"Three-byte sequences beginning with 0xE0 must use a second byte 0xA0 through 0xBF and a third byte 0x80 through 0xBF, preventing overlong encodings.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.4,Three-byte sequences beginning with 0xE1 through 0xEC or 0xEE through 0xEF must use two continuation bytes 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.5,"Three-byte sequences beginning with 0xED must use a second byte 0x80 through 0x9F and a third byte 0x80 through 0xBF, excluding UTF-16 surrogate halves.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.6,"Four-byte sequences beginning with 0xF0 must use a second byte 0x90 through 0xBF followed by two continuation bytes 0x80 through 0xBF, preventing overlong encodings.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.7,Four-byte sequences beginning with 0xF1 through 0xF3 must use three continuation bytes 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.8,"Four-byte sequences beginning with 0xF4 must use a second byte 0x80 through 0x8F followed by two continuation bytes 0x80 through 0xBF, preventing code points above U+10FFFF.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.9,Bytes 0x80 through 0xBF are invalid when encountered as lead bytes.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.10,Bytes 0xC0 and 0xC1 are invalid lead bytes because they can only introduce overlong encodings.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.11,Bytes 0xF5 through 0xFF are invalid UTF-8 lead bytes.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"ASCII-first inline UTF-8 certification algorithm READ NEXT BOUNDED WINDOW Reference evidence used 4 MiB windows RESOLVE PENDING CROSS-WINDOW STATE At most one incomplete UTF-8 sequence ASCII FAST SCAN Advance cheaply while every byte < 0x80 ASCII RUN Already valid UTF-8 RESUME SCAN Same window BYTE >= 0x80 Validate sequence inline STRICT UTF-8 Lead + continuation range rules VALID END OF WINDOW? Persist only bounded carry state MORE SOURCE? Yes: read next window; No: finish EOF + NO PENDING STATE UTF-8 PASS INVALID OR TRUNCATED UTF-8 FAIL No full-file allocation. No collection of all non-ASCII bytes. No per-sequence general string decode required. Figure 2. The WASM-001b-derived fast path certifies ASCII directly, validates only non-ASCII sequences inline, and carries only bounded state across windows.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-006,Measured evidence inherited from WASM-001b,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"The following measurements are non-normative evidence explaining why WASM-002 begins with the ASCII-first inline algorithm. They are not WASM-002 acceptance results and must not be represented as such. EVID-W001B-UTF8-001 On the 7,250,808,204-byte Statistics Canada source, the Day 039 distribution experiment observed 659,103 non-ASCII bytes, approximately 0.009090063% of the file, across 329,551 non-ASCII runs/sequences; the maximum observed non-ASCII run was three bytes. EVID-W001B-UTF8-002 The Day 039 non-ASCII-only experiment submitted only 659,103 bytes to strict UTF-8 validation and completed in 12.664716 seconds at 545.998 MiB/s; it proved the source valid but still incurred 329,551 strict validation calls. EVID-W001B-UTF8-003 A 1 GiB A/B test showed that reducing validated bytes alone was not enough: the selective per-run strategy submitted 115,839 bytes in 57,919 strict calls but took 503.7536 ms, while the baseline submitted 113,246,208 bytes in 27 strict calls and took 411.3590 ms. UNRESOLVED SOURCE DAMAGE: preserved authoritative text continues “This supported removing per-run general-validator call overhead rather than merely shrinking” but the remainder has not been recovered. No missing words are inferred or supplied. EVID-W001B-UTF8-004 The final native inline scan certified all 7,250,808,204 bytes in 10.377870 seconds at 666.313 MiB/s, observed 329,551 non-ASCII sequences and 659,103 non-ASCII bytes, and made zero std::str::from_utf8 calls. EVID-W001B-UTF8-005 The same inline design was exercised in Microsoft Edge/WASM with 4 MiB transfers: the valid 7,250,808,204-byte source completed with 1,729 pushes, UTF8_VALID=true, and EOF_ALL_BYTES_VALID. That experimental run took 30.5858 seconds including file I/O, JS-to-WASM copy, and WASM validation. EVID-W001B-UTF8-006 A full-size deliberately invalid Edge/WASM fixture stopped early after 2,936,012,800 bytes and 700 pushes with UTF8_VALID=false and STOP_REASON=INVALID_UTF8_SEQUENCE rather than reading to EOF. EVID-W001B-UTF8-007 WASM-001b also retained malformed UTF-8 fixtures for stray legacy bytes, truncated sequences, lone continuation bytes, overlong encodings, UTF-16 surrogate halves, and 0xFE/0xFF invalid bytes. WASM-002 should reuse or regenerate equivalent acceptance fixtures with known invalid offsets.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001,Stage 2 consumes the source instance certified by Stage 1,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The structural CSV parser and materializer operate under the explicit invariant that the same run-local selected source instance has already passed governed whole-file UTF-8 certification. Stage 2 must not independently re-resolve the analytical source. Stage 1 establishes encoding validity. Stage 2 establishes CSV structure, row identity, selected values, and governed outputs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.1,Stage 2 must not independently re-decide the source encoding.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.2,Stage 2 must not contain an automatic Windows-1252 fallback.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.3,Stage 2 may perform only those byte/character checks required for correct CSV structural parsing and frozen analytical semantics.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.4,"Any implementation shortcut that would weaken the certified-source invariant must be treated as a PRD change, not an optimization.",W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.5,Stage 2 restarts at byte offset zero of the same certified source instance,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"After Stage 1 returns PASS, Stage 2 must begin its structural pass from absolute source byte offset zero using the same run-local selected source instance. Rewinding/re-reading the existing source handle is permitted; performing a new filename, alias, path, picker, or directory resolution is not. If the host cannot re-read that same selected source instance for Stage 2, the Work Order must refuse under the run-local source-continuity contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.6,Stage 2 consumes an offset-zero UTF-8 BOM as metadata before header parsing,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"If the certified source begins with the UTF-8 BOM bytes EF BB BF , Stage 2 must consume those three bytes before parsing the first CSV header field. They must not become part of the first source header or selected value. The BOM is recognized only at absolute source offset zero. The fact that Stage 1 already saw the BOM does not permit Stage 2 to skip or reinterpret arbitrary later bytes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.7,Stage 2 parses the header once and then continues directly into the data-record scan,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Within the Stage 2 forward source scan, Data Sculptor must parse the complete first logical CSV record as the source header, construct ordered header metadata including exact decoded header text and 1-based source ordinal, resolve and validate all Work Order selectors/aliases, and then continue from the first data record without restarting the source. Header resolution therefore does not add a third whole-file pass. A header-only valid CSV yields a zero-row materialization; a source with no valid header record refuses. P3-09 no-header-record refusal: after Stage 1 has certified the source, if Stage 2 reaches end-of-source without establishing any logical CSV record from which a header could be parsed, materialization must refuse with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD . This is the eighth governed Stage-2 structural CSV refusal token in the canonical oracle defined by W002-MAT-002.8. Its governed location facts are: CSV_SOURCE_BYTE_OFFSET = exact source byte length; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; CSV_FIELD_ORDINAL: 1 . Therefore a zero-byte source reports offset 0 , and a source containing only the UTF-8 BOM bytes EF BB BF reports offset 3 . A first logical record that exists but is blank remains governed by the already-frozen BLANK_LOGICAL_RECORD condition and must not be reclassified as NO_HEADER_RECORD . F-20 source-width boundary: the established header record may contain at most 16,384 physical source columns. Exactly 16,384 is valid; a header record containing 16,385 or more fields must refuse deterministically during header resolution before the first data record is consumed. The bound applies to the complete physical source width, not merely the requested KEEP set. Header processing must remain bounded. Exact decoded source-header text is authoritative source evidence and must be preserved for every selected/materialized column, but the implementation is not required to retain the complete decoded text of every unselected header after selector resolution when bounded metadata is sufficient.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.8,Stage 2 relies on Stage 1 UTF-8 validity rather than revalidating the file,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 must not run a second whole-file UTF-8 certification algorithm over the source. It may inspect bytes and decoded field content only as required for CSV structure, header/selector semantics, governed field-size limits, output serialization, and diagnostics. Any implementation that reintroduces redundant whole-source UTF-8 validation into Stage 2 is a measurable architectural regression unless separately justified and accepted.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002,One-pass multi-column materialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"A valid Work Order may request multiple source columns for materialization during the same bounded structural pass. For WASM-002 DS-STEPS, the requested set is expressed by one KEEP block containing one or more HEADER and/or COLUMN selectors under W002-STEPS-001 through W002-STEPS-004. F-20 KEEP-width boundary: one governed KEEP block may resolve from 1 through 16,384 distinct source columns, subject to the source itself containing no more than 16,384 columns. An empty KEEP or a request that cannot resolve within that bound refuses before data-row materialization.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.1,Requested columns must be resolved and validated before data-row materialization begins,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Every HEADER and COLUMN selector in the governed KEEP block must resolve to exactly one source column before any data-row materialization begins. Missing headers, ambiguous duplicate-header matches, invalid/out-of-range ordinals, duplicate resolved selections, invalid aliases, and successor-MAP alias collisions must refuse before the structural data-row pass. The resolved selection cardinality must be an integer from 1 through 16,384 . Resolution/validation must finish before the first data record is consumed, including operational-name/default-alias derivation and any deterministic oversized-header fallback required by W002-STOR-019.7.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.2,All selected columns are emitted from one forward data-record scan,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"After header/selector resolution, Stage 2 must traverse the source data records once regardless of whether the Work Order selects one column or many. The engine must not perform one complete source rescan per requested column. During that scan, every source field is interpreted structurally, but only the fields required by the resolved selection set are materialized into governed COL outputs. F-20 one-pass boundary: “one forward data-record scan” means one traversal of the source data records for the MATERIALIZE operation. WASM-002 must not reread source data records in batches merely because the selected-column set is wide. An implementation may perform additional bounded passes over Data-Sculptor-owned SCR , spool, or staging structures after the source scan when needed to finalize many outputs within resource limits; such passes must not reread the source data records or change governed output semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.3,One 1-based logical row ordinal aligns every selected output,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The header is not a data row. The first accepted logical data record is row identity 1, the next is 2, and so on through N. The row counter advances exactly once per accepted logical CSV data record, not per physical line. Every selected COL produced by the run must contain exactly one logical data record for each accepted source data row and therefore exactly N data records in the same governed order. A multiline quoted field remains part of one logical record and must not advance row identity merely because it contains physical newline bytes. When the run establishes a new Store, this 1..N sequence is published as that Store's one governed RID artifact. When the run extends an existing Store without changing its row universe, the existing RID is reused and must not be regenerated or renumbered.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.4,Selected-column writer order follows resolved KEEP order,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Before the data-record scan begins, the validated selection set is placed in the same order in which its selectors appear in the governed KEEP block. That resolved order governs writer creation, per-row selected-field dispatch, progress/receipt presentation, deterministic backpressure-drain priority, and candidate COL identity allocation. The Store MAP's own CSV mapping-row ordering remains governed separately by W002-STOR-019.9 and must not be confused with Work Order selection order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.5,Multiple active COL outputs use bounded staging and explicit backpressure,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Each active materialized-column writer, or an equivalent shared multiplexed output structure, must have bounded staging capacity. The aggregate kernel-owned staging state for all active writers must remain inside the governed WASM memory budget and must not grow with source row count or total output size. If a required output writer cannot accept additional canonical bytes without exceeding its governed staging capacity, source consumption must pause while pending output is drained/written. When more than one writer requires service, drain priority follows resolved KEEP order. After sufficient space is available, parsing resumes from the same structural state. The exact tuned staging-buffer size is an implementation/benchmark constant rather than an analytical semantic constant; changing it must not change output bytes, row identity, selection results, or diagnostics for the same governed input. F-20 writer-resource bound: KEEP width and simultaneously active writable resources are distinct. The accepted build must declare a finite implementation bound on simultaneously active writable-output resources and retain acceptance evidence of both that configured bound and the observed peak. The engine may satisfy a wide selection by bounded shared/multiplexed staging or a Data-Sculptor-owned spool followed by bounded finalization passes, but it must not require one simultaneously open writer per selected column. Changing the writer-resource bound must not change final bytes, row order, selection identity, aliases, Receipts, or diagnostics for the same governed input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.6,Partial output sets are never published as a successful materialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"All requested materialized-column outputs begin as visible governed SCR candidates, not COL artifacts. On first materialization of a new Store, the automatically generated RID likewise begins as a governed SCR candidate. Before any new RID/COL SCR candidate is opened, Data Sculptor establishes one publication-transaction UTC under PB-STOR-013/PB-STOR-014 and allocates a distinct artifact-specific UUID for each new candidate. Each candidate filename therefore already carries the exact UTC, UUID, and final extension intended for that RID or COL identity. A materialization transaction may begin promotion only when every required RID/COL candidate reaches EOF successfully, all selected outputs reconcile to the same accepted data-row count N, and all required candidate finalization/validation succeeds. F-04 existing-Store cardinality gate: when materialization targets an existing VALID Store, after Stage 2 establishes the complete candidate logical data-row count N and before any requested COL candidate is promoted, Data Sculptor must read the expected N from the already-valid inherited RID header and compare the two values. If candidate N equals RID-header N , the cardinality gate passes and ordinary publication may continue. If candidate N differs, the Run must refuse before any SCR -to- COL promotion and before successor-MAP publication. The inherited RID, current MAP, and existing COL artifacts remain unchanged, and the existing Store remains VALID. Equal N proves cardinality compatibility only; it does not prove source-byte continuity, row-semantic identity, or permission for a different SOURCE to enter the lineage. Exact SOURCE/Store compatibility rules are prior gates. For a new Store, Data Sculptor promotes the validated RID candidate first by host rename that changes only the class token from SCR to RID ; the candidate bytes, shared transaction UTC, RID-specific UUID, and extension remain unchanged. That successful SCR-to-RID promotion is the event that establishes RID_ACTION: CREATED and the published RID_FILENAME fact for the Run. Before that promotion succeeds, the Run has not created a governed RID even if a candidate identity has been allocated. For an existing Store, the inherited RID is reused unchanged and no RID candidate/promotion occurs. Once routing has selected and validated that exact inherited RID, that event establishes RID_ACTION: REUSED and the exact inherited RID_FILENAME ; later refusal does not erase the already-established reuse fact. After the required RID state is established, Data Sculptor promotes each requested COL candidate in deterministic resolved KEEP order by changing only the class token from SCR to COL ; each candidate's bytes, shared transaction UTC, COL-specific UUID, and extension remain unchanged. If RID or COL promotion fails, Data Sculptor must refuse the run and roll any newly promoted RID/COL names back out of their final namespaces where safely possible. Candidate or rollback bytes that cannot be safely restored or removed must be retained visibly as non-authoritative SCR failure evidence. The existence of an unreferenced RID- or COL-looking file after interruption does not by itself make that artifact committed Store state. After all required RID/COL promotions succeed, Data Sculptor allocates a MAP-specific UUID before opening the complete successor-MAP SCR candidate. That candidate uses the same publication-transaction UTC, the allocated MAP UUID, and the final .csv extension, and is constructed using the exact final RID/COL filenames. It is closed successfully, reopened, and validated completely while it remains SCR . Only then may the MAP candidate be promoted by changing only the class token from SCR to MAP ; its bytes, UTC, UUID, and extension remain unchanged. The successful SCR -to- MAP rename is the materialization commit point. Until that commit point, the prior valid MAP remains authoritative for an existing Store; for a new Store, no committed Store state exists yet. If MAP validation or MAP rename fails, Data Sculptor must refuse and roll the newly promoted RID/COL set back out of the final namespaces where safely possible; otherwise affected bytes remain attributable recovery evidence and are not committed Store membership. Governed Store membership/current state is established by a valid MAP binding, not by a final-class filename or timestamp equality alone. Revision BB preserves the Revision AY staging/promotion mechanics and Revision AZ shared transaction-UTC rule for newly published RID/COL/MAP artifacts. Selected-folder support for the canonical governed filename/path form is established by the Suitcase Validation Certificate under W002-STOR-022 through W002-STOR-022.3 rather than by a frozen numeric host path-length table. Operation-specific host rename or publication failure remains a governed refusal under this requirement and is not pre-certified by Suitcase validation. F-14 shared candidate grammar, reconciled by F-33: every RID/COL/MAP SCR candidate in this transaction follows W002-STOR-023.1: its SCR name already carries the UTC, UUID and extension intended for the final RID/COL/MAP identity, and successful promotion changes only the class token. Any retained SCR candidates after a handled publication/rollback failure remain visible non-authoritative failure evidence under W002-STOR-023.1 and are reported through the governed diagnostic/Help path; WASM-002 does not emit an RCV manifest. An orphaned SCR remains non-authoritative even if its bytes later validate.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.7,Successful materialization publishes one complete Store MAP,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"A successful governed materialization that creates one or more COL artifacts must also publish exactly one new complete immutable Store MAP under W002-STOR-019 through W002-STOR-019.12. For a new Store, that MAP binds the automatically generated and promoted RID to the Store metadata and all newly materialized COL mappings. For an existing Store, it preserves the inherited RID binding and complete prior Store state while applying the successful materialization updates. All required RID/COL SCR candidates must complete and validate before promotion begins. On a new Store, RID promotion occurs first; on an existing Store, the inherited RID is reused unchanged. All requested COL promotions must then succeed before successor-MAP candidate construction begins. The complete successor MAP is written as SCR , closed, reopened, and fully validated before entering the MAP namespace. Its final host rename from SCR to the governed MAP filename occurs last and is the materialization commit point. The materialization run is not reported as successfully committed until that MAP rename succeeds. If MAP candidate validation or MAP rename fails after RID/COL promotion, the run must refuse and the newly promoted artifacts must be rolled back out of their final namespaces where safely possible. Any failure residue that cannot safely be removed or restored is governed by W002-STOR-023.1 and remains non-authoritative retained failure evidence; its survival must not be used to infer or manufacture attribution or to simulate the failed publication step. The prior valid MAP remains authoritative for an existing Store; no committed Store is established for a first materialization without a valid successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.8,Stage 2 enforces deterministic source-record shape,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The parsed header establishes the expected source field count. Every nonblank logical data record must contain exactly that many fields after CSV parsing. A nonblank ragged record with fewer or more fields must refuse rather than pad, truncate, or shift later values. An explicit empty field is valid data and preserves its ordinal. A bare blank logical data record occurring outside a quoted field must refuse and must not be silently skipped or converted into one empty field. A physical blank line inside a valid quoted multiline field is field content, not a blank record. F-06 canonical malformed-CSV refusal facts Every structural CSV refusal records these governed facts: REFUSAL_CONDITION
SOURCE_BYTE_OFFSET
PHYSICAL_LINE
LOGICAL_RECORD
FIELD_ORDINAL SOURCE_BYTE_OFFSET is the zero-based absolute byte offset from the first physical byte of the source file. A leading UTF-8 BOM, when present, occupies offsets 0–2 and therefore counts in subsequent absolute byte locations. PHYSICAL_LINE is one-based and equals one plus the number of LF bytes strictly before the governed refusal location. LF bytes inside quoted multiline fields still increment physical-line count. LOGICAL_RECORD is one-based CSV logical-record ordinal and includes the header as logical record 1. The first data record is therefore logical record 2. FIELD_ORDINAL is the one-based field position within that logical record. These facts describe the same first structural refusal regardless of permitted streaming-window size or boundary placement. Canonical structural refusal tokens The seven frozen F-06 malformed-CSV tokens are: UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD
INVALID_BYTE_AFTER_CLOSING_QUOTE
BARE_CR_OUTSIDE_QUOTED_FIELD
EOF_INSIDE_QUOTED_FIELD
BLANK_LOGICAL_RECORD
TOO_FEW_FIELDS
TOO_MANY_FIELDS P3-09 adds NO_HEADER_RECORD as the eighth governed Stage-2 structural CSV refusal token. Parser-library names, host exceptions, crate-specific error enums, or localized descriptions must not replace these governed tokens. Governed refusal location by condition Condition Governed refusal location UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD Offset of the offending "" byte. INVALID_BYTE_AFTER_CLOSING_QUOTE Offset of the first prohibited byte after the closing quote. BARE_CR_OUTSIDE_QUOTED_FIELD Offset of the CR byte itself. EOF_INSIDE_QUOTED_FIELD One-past-end offset, equal to the physical source byte length. BLANK_LOGICAL_RECORD First byte of the record terminator that proves the blank record: LF for LF termination; CR for CRLF termination. TOO_FEW_FIELDS First byte of the record terminator that closes the short record; at EOF, one-past-end offset equal to source byte length. TOO_MANY_FIELDS The comma delimiter that begins the first field beyond the expected header width. NO_HEADER_RECORD One-past-end offset equal to the exact physical source byte length, with physical line 1, logical record 1, and field ordinal 1, as frozen by W002-MAT-001.7. Field ordinal rules For TOO_FEW_FIELDS , FIELD_ORDINAL is the first missing field ordinal: expected-width position immediately after the last field actually present. For TOO_MANY_FIELDS , FIELD_ORDINAL is the first extra field ordinal: header-width + 1. For quote/CR/EOF structural conditions, FIELD_ORDINAL is the current field ordinal in which the malformed condition is established. For BLANK_LOGICAL_RECORD , FIELD_ORDINAL is 1. For NO_HEADER_RECORD , FIELD_ORDINAL is 1. Bare CR scope A bare CR outside a quoted field is malformed CSV and refuses with BARE_CR_OUTSIDE_QUOTED_FIELD . CR inside a valid quoted field is ordinary field content. LF inside a valid quoted field is ordinary field content. CRLF inside a valid quoted field is ordinary field content. Outside quoted fields, CRLF is one accepted logical-record terminator and LF is one accepted logical-record terminator. Outside quoted fields, a CR not immediately followed by LF is malformed. EOF while quoted If EOF is reached while the parser remains inside an open quoted field, the source refuses with EOF_INSIDE_QUOTED_FIELD . Data Sculptor must not synthesize a closing quote, truncate the field, reinterpret prior bytes as unquoted content, or otherwise repair the source. First-condition precedence Stage 2 evaluates structural CSV input in absolute source-byte order and reports the earliest refusal condition that becomes deterministically established. CSV grammar errors take precedence over later row-shape errors. BLANK_LOGICAL_RECORD takes precedence over TOO_FEW_FIELDS for a physically blank logical record. BARE_CR_OUTSIDE_QUOTED_FIELD takes precedence over INVALID_BYTE_AFTER_CLOSING_QUOTE when the post-quote offending byte is a CR that is not followed by LF. At EOF while still inside a quoted field, EOF_INSIDE_QUOTED_FIELD takes precedence over field-count evaluation. No implementation may choose a different error merely because of parser buffering, window boundaries, library behavior, or host platform. Delimiter boundary Comma remains the only WASM-002 field delimiter. Automatic delimiter detection is outside the WASM-002 CSV contract. A file whose rows contain semicolons, tabs, or other non-comma separators may still be valid under the comma-only grammar as a one-column CSV. Data Sculptor must not invent a malformed-CSV refusal merely because another application would treat those bytes as delimiters. When a requested HEADER cannot be resolved, Help may explain that WASM-002 uses comma as the CSV delimiter and that semicolon/tab exports may therefore be interpreted as one field per row. Interaction with UTF-8 diagnostics This structural CSV refusal oracle applies only after the source has passed the applicable encoding-certification boundary. Invalid UTF-8 remains governed by the separately frozen UTF-8 diagnostic contract. Its zero-based absolute source-byte orientation is intentionally aligned with SOURCE_BYTE_OFFSET so WASM-002 does not have competing byte-coordinate systems.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.9,Unselected field contents are not retained,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 must parse every field sufficiently to preserve CSV structure, field count, row boundaries, and governed safety checks, but it must not retain complete contents for unselected fields after those bytes are no longer structurally needed. The engine must not materialize a complete source row, complete table, or complete unselected column in memory merely to emit selected columns. Selected-field content may use bounded accumulation required by the frozen field-size/output rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.10,Individual decoded CSV fields are limited to 16 MiB,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"WASM-002 carries forward the established Data Sculptor field-buffer safety boundary: an individual CSV field may contain at most 16 MiB (16,777,216 bytes) of decoded UTF-8 field content. This is an engineering safety limit, not a semantic statement about CSV or an Excel cell limit. The limit must be enforced incrementally for header and data fields. The parser must not first accumulate an arbitrarily large field and then check it. If a field would exceed the limit, the run must refuse without truncating, repairing, discarding the remainder, or finalizing the candidate materialization. For an unselected field, Data Sculptor may count decoded field bytes without retaining the field value; the safety limit still applies so malformed unterminated fields cannot turn the structural scan into unbounded growth. F-20 operational column-name boundary: after an exact source header field is decoded, Data Sculptor measures its length in Unicode scalar values, not UTF-8 bytes or grapheme clusters. If the exact decoded source header contains at most 1,024 Unicode scalar values, its operational column name is that exact header text. If it contains more than 1,024 scalar values, the operational column name begins from the deterministic physical-ordinal fallback Column <LETTERS> , where the letters are the Excel-style 1-based source ordinal ( A through XFD for the WASM-002 width bound). This operational name is a bounded human-facing/default-alias construct; it does not replace or truncate the authoritative exact source header.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.11,Materialized COL artifacts use canonical one-column UTF-8 CSV serialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Each finalized materialized COL artifact is a one-column CSV. It begins with exactly one UTF-8 BOM ( EF BB BF ) and uses LF ( 0x0A ) as the record terminator on every supported host. The first logical record contains the exact decoded source header text for that physical source column; an alias assigned with AS lives in the governed MAP and does not rewrite the physical COL header. A deliberately empty source header is serialized as one explicit empty header field rather than as absence of a header record. Header and data fields use deterministic minimal CSV quoting: quote when the field contains comma, double quote, CR, or LF; double embedded double quotes; otherwise write the field without quotes. Embedded CR/LF that belong to a quoted field remain field content. For a one-column data record whose decoded value is the empty string, serialize the value explicitly as """" so the row cannot be confused with a bare blank logical record. For fixed source bytes and fixed governed semantics, changing input/output window boundaries must not change the finalized COL bytes. F-20 source-fidelity rule: the physical COL header record always serializes the exact decoded source header, even when that header exceeds the 1,024 -scalar operational-name boundary and the Store MAP/default alias therefore uses an operational fallback. The fallback name must never be substituted into the COL header record or into the MAP source_header field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003,Stage 2 processes the source through bounded reusable windows,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,Structural materialization must process the certified source through bounded reusable input windows compatible with browser/WASM memory constraints. Source size and row count must not require proportional WASM memory growth.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.1,"The 4 MiB WASM-001b window is a proven reference point, not a frozen production constant",W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The 4 MiB source window used successfully during the WASM-001b browser experiments is an evidence-backed starting/reference size. WASM-002 may tune the production input-window size using benchmark evidence, provided the governed memory budget and all window-invariance requirements remain satisfied.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.2,Changing source-window size or boundary placement must not change results,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"For the same certified source and Work Order, permitted changes in bounded Stage 2 input-window size or boundary placement must not change CSV interpretation, resolved headers/ordinals, accepted row count, row identity, aliases, canonical COL bytes, successor MAP contents apart from newly allocated physical identities/timestamps, or the first deterministic refusal condition. P3-09 window invariance: for a Stage-1-certified source containing no logical CSV record, every permitted Stage 2 window size and boundary placement must produce the same NO_HEADER_RECORD refusal and the same governed location tuple: source-byte offset equal to the exact source byte length, physical line 1, logical record 1, field ordinal 1. F-06 full refusal-oracle window invariance: for the same certified source bytes, changing any permitted Stage 2 input-window size or boundary placement must not change whether the source is accepted or refused; the first REFUSAL_CONDITION ; SOURCE_BYTE_OFFSET ; PHYSICAL_LINE ; LOGICAL_RECORD ; or FIELD_ORDINAL . This applies to every structural CSV refusal governed by W002-MAT-002.8.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.3,CSV structure must survive arbitrary input-window boundaries,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Input-window boundaries may occur between ordinary field bytes, delimiter bytes, quote/escaped-quote pairs, CR/LF record-ending bytes, inside quoted multiline fields, and inside already-certified multi-byte UTF-8 sequences. The Stage 2 parser must preserve equivalent structural meaning across those boundaries.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.4,Cross-window parser state is small and explicit,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 may carry only the bounded state needed to continue the current logical CSV parse, including the current logical row ordinal, current field ordinal, quoted/unquoted state, escaped-quote/quote-transition state as required by the parser, pending CR/LF state, decoded-field byte count, resolved selected-field dispatch metadata, and bounded selected-field/output staging. The parser must not retain previous complete rows or source windows merely because a CSV record crosses a window boundary.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.5,Input-window and output-drain sizes are independent implementation controls,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The source read window, WASM transfer window where applicable, selected-field accumulator bound, and output-drain window are separate controls. One must not be silently treated as the maximum for another merely because an earlier prototype used the same numeric value. Any tuning must preserve the Stage 2 memory, backpressure, byte, and window-invariance contracts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.6,Stage 2 uses direct structural parsing rather than a required structural sidecar,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The WASM-002 baseline performs its Stage 2 work directly from the certified source stream. It must not require a precomputed comma/quote/newline position map, binary structural index, hidden cache, or OPFS sidecar before materialization can proceed. The previously discussed structural-sidecar comparison remains a separate future experiment and must not be introduced into WASM-002 as an unmeasured dependency.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.7,The Stage 2 algorithm is browser-first shared Rust core behavior,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The structural parser, row-count semantics, selector dispatch, canonical field serialization, and bounded output-state machine defined by Stage 2 belong in the shared Rust semantic core proven through the browser/WASM path first. A later native CLI host must call the same governed core rather than reimplementing competing materialization semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001,Conversion is a separate governed operation,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Windows-1252-to-UTF-8 conversion is a distinct governed Work Order operation, separate from UTF-8 certification and separate from analytical materialization. The analyst must explicitly authorize it. The canonical WASM-002 form is: SUITCASE: .
WORK ORDER AS ""Convert legacy source to UTF-8""
SOURCE ""legacy_source.csv""
CONVERT WINDOWS-1252 TO UTF-8 CONVERT WINDOWS-1252 TO UTF-8 is the terminal operation clause. Exactly one SOURCE is permitted. The same WKO must not contain KEEP , MATERIALIZE , Store/RID/COL alias mutation, MAP , Inventory, repair, cataloging, Work Order composition, or another operation terminal clause. F-10 conversion entry precondition Before CONVERT WINDOWS-1252 TO UTF-8 may begin character transcoding, Data Sculptor must validate the complete bound source as strict UTF-8 under the same deterministic whole-source certification rules used elsewhere in WASM-002. If the complete source is already valid strict UTF-8, the conversion refuses as unnecessary and publishes no CVT . Only after complete strict UTF-8 validation reaches governed FAIL may Data Sculptor assess the same complete bound source against the frozen Windows-1252 compatibility mapping. Only a source that fails strict UTF-8 and passes the complete Windows-1252 compatibility assessment may proceed to conversion. A failed analytical Work Order, UTF-8 certification, or materialization never silently invokes this operation. The analyst must explicitly authorize the separate conversion WKO.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.1,A failed analytical Work Order must not automatically invoke conversion.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.2,The user must explicitly choose or submit the separate conversion task.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.3,The original source file must remain unchanged.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.4,Successful conversion must create a new UTF-8 artifact with its own governed identity and receipt/evidence.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002,Windows-1252 compatibility assessment,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"After strict whole-source UTF-8 certification returns FAIL , the current analytical operation remains refused and Stage 2 must not start. As refusal handling, Data Sculptor performs one separate read-only Windows-1252 compatibility assessment from physical byte offset 0 of the same run-local bound source instance. The compatibility assessment scans the complete source sequentially under W002-CONV-002.1 through W002-CONV-002.5. It does not transcode, publish a CVT, modify the analyst-owned source, resume materialization, or claim that Windows-1252 is the historical encoding. Its sole governed result is whether the entire byte stream is mappable by the frozen WASM-002 Windows-1252 converter. If strict UTF-8 certification returned PASS , or did not reach a governed FAIL conclusion, this compatibility assessment is not run. F-10 conversion classification gate The conversion operation itself repeats/executes the complete classification gate on its bound source before transcoding: validate the complete source as strict UTF-8; if strict UTF-8 passes, refuse conversion as unnecessary; only after strict UTF-8 fails, scan the complete source against the frozen Windows-1252 mapping; if any source byte is undefined or unsupported by that mapping, refuse rather than guess; and begin transcoding only when strict UTF-8 has failed and the complete Windows-1252 compatibility assessment has succeeded. An undefined/unsupported Windows-1252 byte is therefore a pre-transcoding compatibility-assessment refusal . No CVT candidate may be represented as successfully converted from a source whose compatibility scan found an undefined byte. The compatibility assessment must not substitute U+FFFD , reinterpret an undefined Windows-1252 byte as ISO-8859-1, or use permissive host/library decoder behavior to make an incompatible source convertible.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.1,Compatibility means that the supported deterministic converter can map the observed source bytes under the frozen Windows-1252 rules.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Compatibility means that every physical source byte can be mapped deterministically by the complete normative WASM-002 Windows-1252 mapping in W002-CONV-002.4 . Successful EOF produces the governed outcome COMPATIBLE . No statistical detector, locale rule, browser guess, replacement character, ISO-8859-1 substitution, best-effort decoder, or PRODUCT-scoped glossary text participates as normative authority in this determination.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.2,Compatibility must not be described as proof that Windows-1252 was historically or authoritatively the file's original encoding.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"COMPATIBLE means only that the complete byte stream is convertible under Data Sculptor's frozen Windows-1252 mapping. It must not be described as proof that Windows-1252 was historically, authoritatively, or intentionally the source file's original encoding.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.3,Bytes undefined by the frozen Windows-1252 mapping must cause the compatibility assessment or conversion task to refuse rather than guess.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"If the compatibility pass encounters a byte that W002-CONV-002.4 defines as undefined, the assessment stops at the first such byte and returns INCOMPATIBLE . Data Sculptor must not substitute a replacement character, reinterpret the byte under another code page, or continue as though conversion were safe. A later explicit conversion Work Order must apply the same complete WASM-002 mapping and the same refusal rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.4,Complete normative WASM-002 Windows-1252 byte mapping,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"This requirement is the complete normative Windows-1252 mapping authority for WASM-002 . It covers all 256 possible byte values. No PRODUCT-scoped glossary entry or host/library decoder is required to interpret compatibility or conversion. 0x00–0x7F Every byte 0x00 through 0x7F maps one-to-one to Unicode U+0000 through U+007F . 0x80–0x9F Byte Windows-1252 mapping Unicode 0x80 EURO SIGN U+20AC 0x81 UNDEFINED — 0x82 SINGLE LOW-9 QUOTATION MARK U+201A 0x83 LATIN SMALL LETTER F WITH HOOK U+0192 0x84 DOUBLE LOW-9 QUOTATION MARK U+201E 0x85 HORIZONTAL ELLIPSIS U+2026 0x86 DAGGER U+2020 0x87 DOUBLE DAGGER U+2021 0x88 MODIFIER LETTER CIRCUMFLEX ACCENT U+02C6 0x89 PER MILLE SIGN U+2030 0x8A LATIN CAPITAL LETTER S WITH CARON U+0160 0x8B SINGLE LEFT-POINTING ANGLE QUOTATION MARK U+2039 0x8C LATIN CAPITAL LIGATURE OE U+0152 0x8D UNDEFINED — 0x8E LATIN CAPITAL LETTER Z WITH CARON U+017D 0x8F UNDEFINED — 0x90 UNDEFINED — 0x91 LEFT SINGLE QUOTATION MARK U+2018 0x92 RIGHT SINGLE QUOTATION MARK U+2019 0x93 LEFT DOUBLE QUOTATION MARK U+201C 0x94 RIGHT DOUBLE QUOTATION MARK U+201D 0x95 BULLET U+2022 0x96 EN DASH U+2013 0x97 EM DASH U+2014 0x98 SMALL TILDE U+02DC 0x99 TRADE MARK SIGN U+2122 0x9A LATIN SMALL LETTER S WITH CARON U+0161 0x9B SINGLE RIGHT-POINTING ANGLE QUOTATION MARK U+203A 0x9C LATIN SMALL LIGATURE OE U+0153 0x9D UNDEFINED — 0x9E LATIN SMALL LETTER Z WITH CARON U+017E 0x9F LATIN CAPITAL LETTER Y WITH DIAERESIS U+0178 0xA0–0xFF Every byte 0xA0 through 0xFF maps one-to-one to Unicode U+00A0 through U+00FF . Undefined-byte rule The only undefined byte values in this frozen WASM-002 mapping are exactly 0x81 , 0x8D , 0x8F , 0x90 , and 0x9D . Encountering any one of them makes the complete compatibility assessment INCOMPATIBLE at the first such byte and causes an explicitly run conversion Work Order to refuse before transcoding rather than guess. These three ranges plus the 32-position table above exhaust the byte domain 0x00–0xFF . No unlisted byte value exists.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.5,The compatibility check must itself be bounded and deterministic.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"The compatibility check is one bounded-memory deterministic sequential pass from physical source byte offset 0 to EOF unless the first undefined Windows-1252 byte is encountered earlier. Buffer/window size must not change the compatibility outcome or the first undefined-byte offset. On INCOMPATIBLE , WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET is the zero-based absolute physical source-byte offset of the first undefined byte. On COMPATIBLE , that offset is NOT_APPLICABLE . If the assessment begins but an independent read/host failure prevents a governed compatibility conclusion, the outcome is NOT_AVAILABLE and the first-undefined-byte offset is NOT_AVAILABLE . The assessment itself publishes no converted output.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003,Help suggestion after failed UTF-8 certification,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Help may suggest the separate CONVERT WINDOWS-1252 TO UTF-8 Work Order only when the governed engine emits DS-CNV-001 after a complete compatibility assessment returned COMPATIBLE . The suggestion is therefore derived from a governed diagnostic fact, not from the UTF-8 failure itself. If the assessment returns INCOMPATIBLE , is NOT_AVAILABLE , or did not run, DS-CNV-001 is not emitted and Help must not invent the conversion recommendation. P3-08 Help disclosure: when conversion succeeds, Help must state that the published CVT is a new governed source artifact with its own source identity and that converting a refreshed legacy source later will publish another distinct CVT rather than refresh an earlier CVT-backed Store lineage. When a CVT is selected for first materialization, Help must disclose the same consequence before or with the normal materialization guidance: the Store lineage is anchored to the exact CVT filename, not to the analyst-owned pre-conversion filename. Help must not imply hidden lineage continuity across separate CVT artifacts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.1,The suggestion must state that the current analytical task has stopped.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must state that the current analytical task has already stopped/refused because strict UTF-8 certification failed. DS-CNV-001 is informational and must not be rendered as though materialization can continue from the failed run.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.2,The suggestion must state that the original source has not been changed.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must state that the compatibility assessment was read-only and that Data Sculptor did not change the analyst-owned source. Any later successful conversion publishes a separate governed CVT artifact rather than editing the original source in place.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.3,"The suggestion must describe the source as compatible with the supported Windows-1252 converter, not definitively identified as Windows-1252.",W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must describe the complete source as compatible with Data Sculptor's supported Windows-1252 converter . It must not say that the source was definitively identified as Windows-1252 or imply provenance that the compatibility pass cannot prove.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.4,The suggestion must make clear that conversion is a separate user-authorized task.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"The suggestion must make clear that conversion is a separate user-authorized Work Order. next_action: RUN_WINDOWS_1252_CONVERSION means that the separate operation is a governed safe option; it is not permission for Data Sculptor to silently transcode, modify the source, or reinterpret the refused analytical Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.5,"If the bytes are not compatible with the supported converter, Help must not recommend Windows-1252 conversion as though it were safe.",W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"If the compatibility outcome is INCOMPATIBLE , NOT_AVAILABLE , or NOT_RUN , Help must not recommend Windows-1252 conversion as though it were safe. In particular, the mere presence of DS-ENC-001 never authorizes that recommendation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004,Canonical conversion output,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"A successful Windows-1252 conversion task must produce canonical UTF-8 output suitable for later submission to the normal UTF-8 certification and materialization path. P3-08 lineage consequence: the successful conversion output is a new immutable governed CVT artifact with its own exact physical filename. That CVT filename is the source identity used by later Store routing. A later conversion, including one made from a refreshed analyst-owned legacy source with the same original filename, publishes a different CVT and therefore does not refresh, replace, or continue an earlier CVT-backed Store lineage merely by name association. On first materialization, each distinct CVT begins a new Store lineage unless that exact CVT filename already routes to an existing lineage under the normal Store rules. F-14 CVT identity and publication: the final converted-source filename is exactly __DS__CVT__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv . Conversion writes first to the corresponding W002-STOR-023.1 SCR identity with the same UTC, UUID and .csv extension. Only after bounded conversion completes, the candidate closes/reopens successfully, and the converted bytes satisfy the governed strict UTF-8 requirement may the class token be renamed to CVT . CSV structural interpretation remains governed by the later normal certification/materialization path; CVT publication does not assert that the converted source is structurally valid CSV. F-10 conversion semantics — encoding conversion only The conversion operation performs deterministic character transcoding only. It does not parse, repair, normalize, or reinterpret CSV structure. Commas remain commas. Double quotes remain double quotes. Ordinary ASCII bytes retain the same byte value. LF remains LF. CR remains CR. CRLF remains CRLF. Embedded CR/LF bytes are preserved in place; the converter does not decide whether they are record terminators or field content. Canonical UTF-8 output therefore means deterministic UTF-8 encoding of the accepted source characters, not normalization of line endings, quoting, delimiters, records, headers, or fields. F-10 BOM rule The published CVT is UTF-8 without a BOM ; Data Sculptor does not prepend EF BB BF . If the source failed strict UTF-8 classification, a leading source byte sequence EF BB BF is not blindly stripped as though it were a UTF-8 BOM. Under the Windows-1252 conversion path those source bytes are source data and are mapped according to the frozen Windows-1252 mapping. BOM interpretation remains subordinate to encoding classification rather than acting as a blind prefix-removal rule.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-010; CP-011,"CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open; CP011 T-ACCEPTED, GIT BANKED — CVT-to-SCR lexical staging-name pairing only; complete conversion requirement remains open",b7c515faa9bd000369d7656e09437310261290ae; e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,"Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived); Evidence/CP-011/CP011_Scope_Lock.txt; Evidence/CP-011/CP011_RED_Test_Output.txt; Evidence/CP-011/CP011_GREEN_Test_Output.txt; Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt; Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt; Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt; Evidence/CP-011/CP011_Hash_Inventory_Verification.txt; Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt; Evidence/CP-011/CP011_Closing_Git_Review.txt; CP011_Git_Banking_Output.txt (post-commit, separately preserved)","CP010 Day066 first-touches ONLY the F-14 canonical final CVT output filename grammar subconstraint: is_governed_cvt_source_filename_candidate(&str)->bool recognizes exact canonical __DS__CVT__<UTC>__<UUIDv4>.csv lexical form by reusing existing envelope validation. Four targeted tests + 40/40 full native regression PASS; wasm32-target build PASS; T accepted and banked b7c515faa9bd000369d7656e09437310261290ae. No encoding conversion, SCR creation, close/reopen, UTF-8 validation, CVT publication, immutable physical output, source authority, or CSV structural checks; entire W002-CONV-004 remains PARTIAL, independently unreviewed. CP011 Day066: public pure helper build_scr_candidate_filename_for_cvt(&str)->Option<String> accepts an exact canonical governed CVT .csv filename (via CP010 recognizer) and derives the paired SCR filename by substituting only class token CVT -> SCR, preserving exact UTC, UUIDv4 and lowercase .csv bytes; rejects wrong classes, paths, whitespace, malformed clock/date/UUID, extension and class case. Six targeted tests; RED expected E0432 exit 101; GREEN 6/6; post-format native regression 46/46; rustfmt recheck PASS; Rust 1.97.1 wasm32-unknown-unknown --lib build PASS; original 28/28 and combined 36/36 SHA-256 records verified. Two local scoped .gitattributes whitespace exceptions preserve Rustfmt/Git diagnostic TXT bytes; final Git staged check PASS. T-approved and Git banked e84ae5baeee05f9d5d30284c65b86eebba3c0f6a, 27 committed files, working tree clean. Lexical candidate-name pairing ONLY; no SCR creation, bytes, converter, transaction, close/reopen, validation/publication, retained SCR adoption, SOURCE authority or browser execution. Independent Claude implementation QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.1,The converted artifact must itself be certifiable as UTF-8.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.2,The conversion Receipt identifies the governed source encoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for a successful governed Windows-1252-compatible conversion must identify exactly SOURCE_ENCODING: WINDOWS-1252-COMPATIBLE . That operation-specific fact is carried within the canonical TXT Receipt governed by W002-RCP-001 through W002-RCP-010. Only that exact serialized spelling is permitted for this key/value pair.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.3,The conversion Receipt identifies the materialized UTF-8 encoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for a successful governed conversion must identify exactly MATERIALIZED_ENCODING: UTF-8 . This uses the canonical KEY: VALUE serialization frozen by W002-RCP-005. MATERIALIZED_ENCODING=UTF-8 is not valid canonical Receipt serialization.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.4,The conversion Receipt identifies bounded streaming transcoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for successful conversion must identify that transcoding was performed under the governed bounded/streaming conversion contract.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.5,No analytical column materialization occurs as part of this conversion operation.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001,Canonical diagnostic truth,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every governed user-visible failure or warning produced by WASM-002 must originate as a canonical diagnostic event. A diagnostic event must have a stable identity and structured facts independent of its final wording. Governed success/status events that participate in the Help/status/evidence system—such as a successfully saved Work Order or a successfully validated Suitcase—are canonical INFO diagnostic events and obey the same identity/fact/behavior contract. Ordinary static labels, headings, decorative copy, and presentation-only status text are not automatically diagnostics merely because they are visible in the UI.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.1,Canonical diagnostic IDs use the frozen DS-<DOMAIN>-<NNN> grammar,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry one stable identifier using the exact form DS-<DOMAIN>-<NNN> . DOMAIN is exactly three uppercase ASCII letters A through Z. NNN is exactly three decimal digits, zero-padded, in the range 001 through 999 . Examples include DS-ENC-001 , DS-WKO-001 , DS-STO-001 , DS-MAT-001 , and DS-HLP-001 . A diagnostic ID is permanent after allocation and must never be reused for a different diagnostic meaning. Severity, host, build/release, source filename, path, UUID, byte offset, row/column number, count, timestamp, occurrence ID, and other run-specific facts must not be encoded into the diagnostic ID; those values belong in structured diagnostic fields. The identifier is the canonical lookup key used by the Help message catalog. Day 060 H-04 pre-freeze identifier normalization: the Windows-1252 compatibility suggestion diagnostic is DS-CNV-001 . It follows the same exact three-letter DOMAIN grammar as every other diagnostic ID. No four-letter DOMAIN exception exists in the current WASM-002 contract. Any pre-H-04 draft spelling of this diagnostic is superseded and is not valid build-registry input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.2,Diagnostic severity uses one exact token set,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry exactly one severity token: INFO , WARNING , or ERROR . Severity classifies the condition for human and machine interpretation. It does not itself determine whether execution continues or refuses; that authority is carried separately by the canonical behavior field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.3,Diagnostic phase uses a stable uppercase token,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must identify the governed operation or phase using an uppercase ASCII snake-case token matching [A-Z][A-Z0-9]*(?:_[A-Z0-9]+)* . Examples include WORK_ORDER_VALIDATION , SOURCE_CERTIFICATION , MATERIALIZATION , STORE_PUBLICATION , and HELP_REPORT . These examples do not constitute a closed global phase list; the fixed phase for each allocated diagnostic is declared by that diagnostic's registry entry.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.4,Structured diagnostic facts are declared per diagnostic,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The canonical event carries diagnostic-specific evidence in a structured facts object. Fact keys use lowercase ASCII snake case matching [a-z][a-z0-9]*(?:_[a-z0-9]+)* . Each diagnostic registry entry declares disjoint required_facts and optional_facts sets. Every required fact must be present when that diagnostic is emitted. An optional fact key may be omitted when that fact is not emitted for the event, but omission itself has no governed absence-state meaning : it must not be interpreted as NONE , NOT_RUN , NOT_AVAILABLE , NOT_APPLICABLE , false , zero, or an empty string. An emitted fact key that is not declared for that diagnostic is invalid. For structured JSON diagnostic facts, an established ordinary value retains its native JSON type. When a present diagnostic fact must express one of the shared governed absence states, its value is the exact JSON string ""NONE"" , ""NOT_RUN"" , ""NOT_AVAILABLE"" , or ""NOT_APPLICABLE"" , with the meaning frozen by F-18. JSON null is not a generic encoding for diagnostic-fact absence; it is permitted only where a specific JSON schema explicitly declares a nullable field and defines what that null means, as W002-HELP-009 does for HLP lineage. A required diagnostic fact may not be silently omitted, defaulted, converted to null , guessed, or replaced by a Help-layer value. If Data Sculptor attempts to establish a registered diagnostic but cannot produce one or more facts declared required for that diagnostic, the intended diagnostic is not emitted . Instead the engine emits DS-HLP-001 under W002-HELP-001.8. The replacement event records the intended diagnostic ID and the complete sorted set of missing required fact names. No partially populated copy of the intended diagnostic may be presented beside it. This fail-closed substitution is a diagnostic-contract integrity rule, not a presentation fallback. It preserves the F-17 boundary that diagnostics own facts and Help renders only complete governed diagnostic truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.5,Execution behavior is explicitly CONTINUE or REFUSE,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry exactly one execution-behavior token: CONTINUE or REFUSE . This field is the governed continue/refuse decision for the event. Help wording, severity, UI color, or presentation must not independently weaken, strengthen, or reinterpret it.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.6,Safe next action uses a stable token rather than Help prose,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry a next_action token using uppercase ASCII snake case matching [A-Z][A-Z0-9]*(?:_[A-Z0-9]+)* . NONE is the canonical value when no safe governed next action applies. The token expresses stable machine-readable intent; Casual, Office Speak, and Technical wording for that action belongs to the Help layer. Run-specific values such as timestamps, paths, UUIDs, byte offsets, filenames, counts, or occurrence IDs remain structured facts and do not change the diagnostic identity or fixed next-action meaning. Damaged-Store guidance is part of the safe-next-action contract. When ordinary materialization refuses because exact source routing identifies an INVALID Store lineage, or a DEGRADED lineage whose every mapped COL is broken and therefore cannot be reduced to a non-empty successor by REPAIR MAP , the selected Help voice must preserve the same frozen choices and consequences rather than inventing a recovery operation. The explanation must identify the blocked lineage/current MAP and distinguish: external restoration under the original governed physical filename followed by the required governed validation tier; source rename to deliberately begin a separate new Store lineage; and analyst retirement of the damaged lineage by moving all of that lineage's Store MAPs out of the active Suitcase root. For retirement, Help must warn that moving only the latest MAP can expose an older structurally valid MAP as current. Help must not claim that matching the original filename proves historical byte identity, and must not describe any of these analyst filesystem actions as Data Sculptor-authored repair, deletion, RID regeneration, or silent lineage replacement. P3-07 malformed-MAP routing guard: when ordinary materialization refuses because no routable Store lineage can be established while one or more structurally malformed Store-MAP-class artifacts are present in the active Suitcase, Help must identify the malformed MAP artifact or artifacts and state that new-Store/RID creation was blocked to prevent a silent lineage fork. Help must not describe the missing structurally valid MAP as proof that the prior Store never existed, and must not invent a Data Sculptor repair or replacement operation for this condition. P3-10 delimiter-hint clarification: when Stage 2 refuses with INVALID_BYTE_AFTER_CLOSING_QUOTE and the offending byte is semicolon ( 0x3B ) or horizontal TAB ( 0x09 ), Help may include the governed delimiter-mismatch hint even though the refusal occurred before header-delimiter resolution. The hint is explanatory only: it must not change the canonical refusal condition, location facts, behavior, or safe-action boundary. F-16 conversion-suggestion boundary: strict UTF-8 refusal diagnostic DS-ENC-001 has fixed next_action: NONE . UTF-8 failure alone does not establish that any converter is safe. Only the separate compatibility diagnostic DS-CNV-001 , emitted after the complete governed Windows-1252 compatibility assessment returns COMPATIBLE , may carry next_action: RUN_WINDOWS_1252_CONVERSION . That token identifies a safe separately authorized option; it never resumes or rewrites the refused analytical Work Order. Day 060 H-12 damaged-lineage diagnostic binding ordinary MATERIALIZE refusal for a routed INVALID Store uses DS-MAT-014 and its declared facts; ordinary MATERIALIZE refusal for a DEGRADED Store whose every mapped COL is broken uses DS-MAT-015 and its declared facts; the no-routable-lineage / malformed-Store-MAP guard uses DS-MAT-016 and its declared facts. These specialized allocations are what permit closed-world Help to identify the blocked lineage/current MAP or malformed MAP artifacts without adding unrelated facts to the ordinary DS-MAT-010 validation diagnostic. Day 060 H-26 / BM-09 ordinary DEGRADED routing binding. When ordinary MATERIALIZE exact-source routing identifies a DEGRADED Store whose RID is valid and at least one mapped non-RID COL remains valid, the refusal uses DS-MAT-017 . Its fixed next_action is RUN_REPAIR_MAP because REPAIR MAP is the safe governed Store mutation for this repairable DEGRADED state. Help must use the diagnostic's declared current_map_filename as the exact MAP identity the analyst must name in the separate governed REPAIR MAP Work Order. The token does not run repair automatically and does not mutate the refused MATERIALIZE Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.7,"The governed engine emits the diagnostic semantic core, not voice-authored prose",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The shared Rust/WASM diagnostic path must provide the canonical semantic core required by Help: diagnostic_id , severity , phase , behavior , facts , and next_action . The fixed values and permitted fact-key sets for an allocated diagnostic are governed by diagnostics.json . Casual, Office Speak, and Technical prose belongs to the Help rendering layer rather than being duplicated as authored message sets inside the governed engine. Host/build/occurrence metadata may be carried by surrounding governed execution evidence, but it must not redefine the diagnostic semantic core. F-16 closed-world Help rule: Help may recommend the WASM-002 Windows-1252 conversion Work Order only when the governed engine emitted DS-CNV-001 . Help must not infer compatibility from DS-ENC-001 , byte appearance, file extension, locale, browser behavior, heuristic encoding detection, or prose outside the diagnostic facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.8,diagnostics.json is the canonical WASM-002 diagnostic registry build resource,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The human-inspectable development/build source for the WASM-002 diagnostic registry is exactly diagnostics.json , encoded as UTF-8 without BOM. It is Data Sculptor product/build content, not a Suitcase artifact; it must not use the __DS__ namespace, consume an artifact-class token, or be copied into an analyst's Suitcase merely because Data Sculptor runs. The top-level JSON object has exactly two fields: registry_version and diagnostics . registry_version is the string ""1"" . diagnostics is an array written in ascending UTF-8 byte order of diagnostic_id . Each diagnostic entry has exactly seven fields: diagnostic_id , severity , phase , behavior , next_action , required_facts , and optional_facts . Diagnostic IDs must be unique and satisfy W002-HELP-001.1. Severity, phase, behavior, and next-action values must satisfy W002-HELP-001.2 through W002-HELP-001.6. required_facts and optional_facts are arrays of canonical fact-key strings sorted in ascending UTF-8 byte order; keys must be unique within each array and the two arrays must be disjoint. {
  ""registry_version"": ""1"",
  ""diagnostics"": [
    {
      ""diagnostic_id"": ""DS-CNV-001"",
      ""severity"": ""INFO"",
      ""phase"": ""SOURCE_CERTIFICATION"",
      ""behavior"": ""CONTINUE"",
      ""next_action"": ""RUN_WINDOWS_1252_CONVERSION"",
      ""required_facts"": [""source_filename"", ""windows_1252_compatibility_outcome""],
      ""optional_facts"": []
    },
    {
      ""diagnostic_id"": ""DS-ENC-001"",
      ""severity"": ""ERROR"",
      ""phase"": ""SOURCE_CERTIFICATION"",
      ""behavior"": ""REFUSE"",
      ""next_action"": ""NONE"",
      ""required_facts"": [""first_invalid_byte_offset"", ""source_filename"", ""stop_reason""],
      ""optional_facts"": [""analytical_outputs_published"", ""materialization_started"", ""source_modified_by_data_sculptor"", ""store_state_committed""]
    },
    {
      ""diagnostic_id"": ""DS-HLP-001"",
      ""severity"": ""ERROR"",
      ""phase"": ""DIAGNOSTIC_ASSEMBLY"",
      ""behavior"": ""REFUSE"",
      ""next_action"": ""NONE"",
      ""required_facts"": [""intended_diagnostic_id"", ""missing_required_facts""],
      ""optional_facts"": []
    }
  ]
} The PRD does not need to enumerate every allocated WASM-002 diagnostic row. The complete registry delivered with the build is retained acceptance evidence. A diagnostic ID becomes permanent once allocated and must not later be reused for a different meaning. Build validation must fail on malformed JSON; extra/missing entry fields; duplicate or noncanonical diagnostic IDs; invalid fixed tokens; unsorted, duplicate, overlapping, or invalid fact-key declarations; engine diagnostic definitions whose fixed semantics disagree with the registry; engine diagnostic definitions absent from the registry; Help-catalog IDs absent from the registry; or Help placeholders that name facts not declared as required or optional by the matching diagnostic. F-07 DS-ENC-001 fact mapping: the canonical lower-case diagnostic facts for strict UTF-8 refusal are first_invalid_byte_offset , source_filename , and stop_reason . For this diagnostic, stop_reason is exactly INVALID_UTF8_SEQUENCE . The generic fact name byte_offset is retired for this UTF-8 refusal diagnostic. P2-03 clock-order diagnostic facts: whichever stable WASM-002 Diagnostic ID is allocated to refusal because a successor Store MAP or WKO MAP cannot satisfy the strict monotonic UTC publication guard must declare these exact lower-case required facts in its diagnostic-registry entry: map_profile , observed_host_utc , predecessor_map_filename , and predecessor_utc . map_profile has exactly two permitted values: STORE for a Store-MAP chronology guard and WKO for a Work-Order-registry-MAP chronology guard. These facts identify both the governed MAP profile, the blocking predecessor artifact, and the truthful clock observation that caused refusal. F-16 DS-CNV-001 allocation: DS-CNV-001 is emitted only when the complete read-only compatibility assessment under W002-CONV-002 through W002-CONV-002.5 reaches EOF with outcome COMPATIBLE . Its required fact windows_1252_compatibility_outcome is therefore exactly the JSON string ""COMPATIBLE"" . behavior: CONTINUE means this informational diagnostic introduces no additional refusal; it does not reverse the already-established DS-ENC-001 refusal or resume Stage 2. F-17 DS-HLP-001 allocation: DS-HLP-001 is the canonical fail-safe event when the engine cannot satisfy the complete required-fact contract of an intended registered diagnostic. intended_diagnostic_id is the exact canonical ID that was being assembled. missing_required_facts is a JSON array of every missing required fact-key string, sorted in ascending UTF-8 byte order with no duplicates. The intended diagnostic is suppressed rather than emitted incompletely. DS-HLP-001 always refuses and has next_action: NONE . F-22 QA-independence boundary: diagnostics.json is authoritative for the fixed semantic contract of an allocated Diagnostic ID — its ID, severity, phase, behavior, next action, and permitted required/optional fact keys — but the implementation-delivered registry is not, by itself, an independent oracle proving that every arbitrary runtime condition was mapped to the correct Diagnostic ID. WASM-002 does not require a second QA-owned registry duplicating every implementation allocation. Where this PRD independently freezes a condition-to-diagnostic mapping or exact required facts — including the named DS-ENC-001 , DS-CNV-001 , and DS-HLP-001 contracts and other explicitly pinned diagnostic facts — that PRD text remains normative and acceptance must test the mapping independently of the implementation registry. For allocations not independently pinned by the PRD, WASM-002 accepts the validated build registry as the build allocation while retaining all registry-shape, permanence, semantic-agreement, fact-discipline, and Help cross-validation gates. This is an explicit accepted QA-scope risk, not a claim of independent condition-to-ID verification. Day 060 H-02 fixture-pinned diagnostic allocations The following allocations are normative for the byte-exact Receipt acceptance corpus. They are genuine product diagnostics, not QA-only placeholder IDs. Every row has severity: ERROR , behavior: REFUSE , next_action: NONE , the phase shown below, the listed required facts, and an empty optional_facts array unless another requirement explicitly adds optional facts later. The existing DS-ENC-001 remains the Stage-1 invalid UTF-8 diagnostic and is reused by the H-02 Stage-1 compatibility-state fixtures. Diagnostic ID Severity Phase Behavior Next action Frozen meaning Required facts DS-WKO-001 ERROR WORK_ORDER_VALIDATION REFUSE NONE Work Order validation refuses before one of the seven governed operations can be identified. work_order_filename DS-MAT-010 ERROR MATERIALIZATION_VALIDATION REFUSE NONE Ordinary MATERIALIZE validation/routing refuses before Stage 1 begins after the source reference is established, excluding the specialized damaged-lineage and malformed-MAP routing conditions allocated by Day 060 H-12. source_filename DS-MAT-011 ERROR CSV_DECODING REFUSE NONE MATERIALIZE Stage 2 refuses on a governed structural CSV condition. source_filename csv_refusal_condition csv_source_byte_offset csv_physical_line csv_logical_record csv_field_ordinal DS-MAT-012 ERROR MATERIALIZATION_GATE REFUSE NONE MATERIALIZE post-Stage-2 gate refuses because existing-Store source cardinality does not match the inherited RID cardinality. source_filename base_map_filename rid_filename source_row_count rid_row_count DS-MAT-013 ERROR STORE_PUBLICATION REFUSE NONE MATERIALIZE governed Store-artifact filename identity allocation refuses after collision-retry exhaustion before any new Store artifact becomes authoritative. artifact_class collision_retry_count DS-INV-001 ERROR INVENTORY_VALIDATION REFUSE NONE INVENTORY validation refuses before the inventory scan begins. work_order_filename DS-INV-002 ERROR INVENTORY_SCAN REFUSE NONE INVENTORY scan/measurement refuses for an identified immediate Suitcase entry before a complete snapshot is established. entry_name DS-INV-003 ERROR INVENTORY_PUBLICATION REFUSE NONE INVENTORY governed INV filename identity allocation refuses after collision-retry exhaustion after the snapshot facts are established. artifact_class collision_retry_count DS-ALS-001 ERROR ALIAS_VALIDATION REFUSE NONE UPDATE ALIASES validation/routing refuses before an exact base Store MAP is established. work_order_filename DS-ALS-002 ERROR ALIAS_GATE REFUSE NONE UPDATE ALIASES refuses after the exact base Store MAP is established but before successor publication. base_map_filename DS-ALS-003 ERROR STORE_PUBLICATION REFUSE NONE UPDATE ALIASES successor-MAP filename identity allocation refuses after collision-retry exhaustion. artifact_class collision_retry_count DS-RPM-001 ERROR REPAIR_MAP_VALIDATION REFUSE NONE REPAIR MAP validation refuses before an exact target MAP/RID pair is established. work_order_filename DS-RPM-002 ERROR REPAIR_MAP_ANALYSIS REFUSE NONE REPAIR MAP analysis refuses before a complete repair result is established. target_map_filename DS-RPM-003 ERROR REPAIR_MAP_ANALYSIS REFUSE NONE REPAIR MAP deterministically refuses because every mapped COL is broken and retained COL count is zero. target_map_filename broken_col_count DS-RPM-004 ERROR STORE_PUBLICATION REFUSE NONE REPAIR MAP successor-MAP filename identity allocation refuses after collision-retry exhaustion after repair analysis is established. artifact_class collision_retry_count DS-WKR-001 ERROR WORK_ORDER_REGISTRY_VALIDATION REFUSE NONE REPAIR WORK ORDER REGISTRY validation refuses before the current structurally valid WKO MAP is established. work_order_filename DS-WKR-002 ERROR WORK_ORDER_REGISTRY_REPAIR REFUSE NONE REPAIR WORK ORDER REGISTRY repair-plan/gate processing refuses after the base WKO MAP is established. base_wko_map_filename DS-WKR-003 ERROR WORK_ORDER_REGISTRY_PUBLICATION REFUSE NONE REPAIR WORK ORDER REGISTRY successor-WKO-MAP filename identity allocation refuses after collision-retry exhaustion. artifact_class collision_retry_count DS-CVT-001 ERROR CONVERSION_VALIDATION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 validation/classification refuses before bounded transcoding begins. source_filename DS-CVT-002 ERROR CONVERSION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 refuses after bounded transcoding begins but before publication. source_filename DS-CVT-003 ERROR CONVERSION_PUBLICATION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 CVT filename identity allocation refuses after collision-retry exhaustion after conversion facts are established. artifact_class collision_retry_count DS-CAT-001 ERROR CATALOG_DISCOVERY REFUSE NONE CATALOG STORES validation/discovery refuses before the complete authoritative catalog row set is established. work_order_filename DS-CAT-002 ERROR CATALOG_PUBLICATION REFUSE NONE CATALOG STORES CAT filename identity allocation refuses after collision-retry exhaustion after the complete row set is established. artifact_class collision_retry_count Day 060 H-04 normalization: all allocated Diagnostic IDs in the current WASM-002 contract, including DS-CNV-001 , use exactly three ASCII uppercase letters in DOMAIN . No exception exists. Day 060 H-12 / BM-09 specialized diagnostic allocations The H-02 fixture diagnostics above are intentionally narrow. In particular, publication diagnostics whose required facts are only artifact_class and collision_retry_count mean identity-allocation collision exhaustion , not every possible publication failure. Other publication failures receive distinct registry allocations unless another requirement independently pins their Diagnostic ID. The following additional pre-freeze allocations are normative because existing Help duties require fact contracts that the broad H-02 fixture IDs cannot truthfully carry. Every row has severity: ERROR , behavior: REFUSE , and next_action: NONE except DS-MAT-017 , whose next_action is RUN_REPAIR_MAP . optional_facts is empty unless another requirement explicitly extends it. Diagnostic ID Severity Phase Behavior Next action Frozen meaning Required facts DS-MAT-014 ERROR MATERIALIZATION_ROUTING REFUSE NONE MATERIALIZE is blocked because exact source routing identifies a current INVALID Store lineage whose governed RID is missing or invalid. source_filename current_map_filename rid_filename store_health DS-MAT-015 ERROR MATERIALIZATION_ROUTING REFUSE NONE MATERIALIZE is blocked because exact source routing identifies a DEGRADED Store whose every mapped non-RID COL is missing or invalid, so REPAIR MAP cannot publish a non-empty successor. source_filename current_map_filename rid_filename store_health mapped_col_count broken_col_count DS-MAT-016 ERROR MATERIALIZATION_ROUTING REFUSE NONE New-Store creation is blocked because no routable Store lineage can be established while one or more structurally malformed Store-MAP-class artifacts are visible in the active Suitcase. source_filename malformed_map_filenames DS-MAT-017 ERROR MATERIALIZATION_ROUTING REFUSE RUN_REPAIR_MAP MATERIALIZE is blocked because exact source routing identifies a current DEGRADED Store whose governed RID is valid and whose mapped non-RID COL set contains at least one broken COL and at least one surviving valid COL, so a separate governed REPAIR MAP operation is available. source_filename current_map_filename rid_filename store_health broken_col_count DS-UTC-001 ERROR PUBLICATION_CHRONOLOGY REFUSE NONE A successor Store MAP or WKO MAP publication is blocked because truthful observed host UTC is not strictly greater than the canonical chronology predecessor UTC. map_profile observed_host_utc predecessor_map_filename predecessor_utc Day 060 H-26 / BM-09 allocation: DS-MAT-017 is the ordinary repairable-DEGRADED routing refusal. store_health is exactly DEGRADED ; broken_col_count is the exact number of mapped non-RID COL bindings that fail the applicable Store-health validation at this routing gate and is at least 1 . The condition excludes the all-COLs-broken case allocated to DS-MAT-015 . current_map_filename is the exact current structurally valid Store MAP that a separate REPAIR MAP Work Order must name. RUN_REPAIR_MAP is a safe next-action token only; it never causes automatic repair. Closed-world Help consequence: Help may render the richer damaged-lineage, malformed-MAP, and monotonic-UTC explanations only from the applicable specialized diagnostic event above. It must not borrow undeclared facts from DS-MAT-010 or from a collision-exhaustion publication diagnostic merely because those facts are available elsewhere at runtime. Cross-operation UTC rule: DS-UTC-001 has one stable semantic condition across Store-MAP and WKO-MAP successor publication. The required map_profile fact tells closed-world Help which governed MAP profile encountered the chronology guard: STORE means Store MAP and WKO means Work Order registry MAP. Help must select profile-appropriate explanation and analyst exits only from that declared fact and the other registered event facts; it must not infer the profile from filename shape, surrounding host state, or an undeclared operation field. The shared Diagnostic ID therefore does not need profile-specific clones.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002,Three-voice parity,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help Engine must support the three established Data Sculptor help voices. All three renderings must preserve the same diagnostic truth. Voice selection may change wording, sentence structure, degree of technical detail, and explanatory style. F-24 session default and persistence: Technical is the canonical Help voice at the start of every new browser application instance. The analyst may select Casual or Office Speak during that instance, but WASM-002 retains the selected voice only in volatile runtime state and does not persist the preference in browser-private storage. A new application instance therefore returns to Technical. This default does not alter the F-17 rule that a missing diagnostic-specific catalog entry visibly falls back to Generic Technical Help.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.1,Voice selection must not change diagnostic identity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.2,Voice selection must not change severity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.3,Voice selection must not change counts or evidence.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.4,Voice selection must not change whether execution continues or refuses.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.5,Voice selection must not change safe/unsafe action boundaries.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.6,Voice selection must not change provenance.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.7,Voice selection must not change the meaning of the recommended next step.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Tests must assert parity on the canonical event and structured facts, not brittle equality of prose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.8,One validated Help message catalog is the source of truth for all three voices,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help layer resolves a canonical diagnostic ID through one validated catalog that associates an authored ID with Casual, Office Speak, and Technical templates. The human-maintained development source is exactly help_messages.json , encoded as UTF-8 without BOM. help_messages.json is a Data Sculptor product/build resource, not a Suitcase artifact. It must not use the __DS__ governed artifact namespace, consume a semantic artifact-class token, or be copied into an analyst's Suitcase merely because Data Sculptor runs. Run-specific structured facts remain authoritative in the canonical diagnostic event and are supplied separately to the selected template. The three authored voices must not be maintained as unrelated message stores. F-17 coverage fallback: absence of an authored catalog entry for an otherwise complete registered diagnostic is permitted at run time and does not make the diagnostic incomplete. Data Sculptor must instead render the deterministic Generic Technical Help view defined by W002-HELP-002.9. The fallback consumes only the canonical event semantic core and its emitted governed facts; it is not a second message catalog and does not manufacture replacement diagnostic facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.9,WASM-002 may use mechanically generated placeholder voice text to prove Help wiring,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance does not require the complete production Help corpus. Authored catalog entries may use unmistakable placeholder strings, and placeholder entries may be generated mechanically from the validated diagnostics.json registry; no production prose authorship is required. Deterministic Generic Technical Help fallback. When a complete registered canonical diagnostic has no matching entry in help_messages.json , all selected Help voices fall back visibly to one Generic Technical rendering. The rendering must show, in this exact conceptual order, the diagnostic ID, severity, phase, behavior, next-action token, and then every emitted governed fact ordered by ascending UTF-8 byte order of fact key. It must state that no diagnostic-specific authored explanation is available. It must not infer cause beyond the diagnostic, invent remediation, default missing facts, inspect undeclared external state, or substitute prose for governed fact values. The Generic Technical fallback preserves the original diagnostic unchanged. Catalog incompleteness is therefore distinct from diagnostic incompleteness: a valid event can always be rendered generically, while inability to satisfy the event's own required_facts contract suppresses that intended event and produces DS-HLP-001 under W002-HELP-001.4 and W002-HELP-001.8. Acceptance must prove correct diagnostic-ID lookup, selected-voice resolution, structured-fact interpolation where a template exists, voice switching, deterministic Generic Technical fallback for a deliberately absent catalog entry, and semantic parity across authored voices. Final authored Help wording, examples, editorial polishing, and production-corpus quality remain deferred to a later Help-content milestone.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.10,help_messages.json has one deterministic WASM-002 source schema,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The top-level JSON object has exactly two fields: catalog_version and messages . catalog_version is the string ""1"" . messages is an array written in ascending UTF-8 byte order of diagnostic_id . Each message entry has exactly four fields: diagnostic_id , casual , office_speak , and technical . diagnostic_id must satisfy the canonical DS-<DOMAIN>-<NNN> grammar and must be unique in the catalog. Each voice field is a JSON string. A voice string may contain zero or more structured-fact placeholders using the exact form {fact_name} . Each catalog diagnostic_id must exist in the validated diagnostics.json registry, and each referenced placeholder must be declared in that diagnostic's required_facts or optional_facts . Duplicate IDs, missing voice fields, null voice values, malformed JSON, noncanonical or unregistered diagnostic IDs, or undeclared fact placeholders make catalog validation fail. The catalog is intentionally allowed to be non-exhaustive. A registered diagnostic with no message entry is rendered through the deterministic Generic Technical fallback in W002-HELP-002.9. Therefore a missing catalog entry for a registered diagnostic is not a build-validation failure and must not cause the engine to synthesize an authored entry or suppress the diagnostic. WASM-002 therefore does not require one global exhaustive fact-name table in the PRD. Fact-key authority is per diagnostic: the validated registry declares which fact names are legal for each stable diagnostic meaning. {
  ""catalog_version"": ""1"",
  ""messages"": [
    {
      ""diagnostic_id"": ""DS-ENC-001"",
      ""casual"": ""[CASUAL PLACEHOLDER] {source_filename}"",
      ""office_speak"": ""[OFFICE PLACEHOLDER] {source_filename}"",
      ""technical"": ""[TECHNICAL PLACEHOLDER] {source_filename} {first_invalid_byte_offset} {stop_reason}""
    }
  ]
} Later Help-content revisions may extend or version this schema only through an explicit PRD revision. F-07 placeholder mapping: Help for the strict UTF-8 refusal may render {first_invalid_byte_offset} and {stop_reason} because those exact fact names are declared by the canonical DS-ENC-001 diagnostic registry entry. The older generic {byte_offset} placeholder is not valid for DS-ENC-001. P2-03 Help rendering duty: Help for the monotonic-UTC refusal must identify the exact blocking predecessor MAP and show both predecessor UTC and truthful observed host UTC. It must distinguish an incorrect host clock from a genuinely future-dated governed MAP and may explain the approved analyst-owned choices: correct the clock, wait/rerun after truthful time advances, or deliberately move the exact future-dated current MAP out of the active Suitcase root with the warning that an older snapshot/registry may become current and that restoring the moved MAP may restore its authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.11,The validated Help catalog is embedded into the released HTML build and supplied to the shared core,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Before a WASM-002 browser build is accepted, the build must parse and validate help_messages.json , then serialize the validated catalog directly into the Data Sculptor HTML itself as one non-executable application/json payload with the exact element ID ds-help-catalog . The embedded JSON must be HTML-safe so catalog text cannot terminate the containing script element; at minimum, literal less-than characters in JSON string content must be escaped during embedding. At runtime, the browser host obtains this embedded payload and supplies the validated catalog to the shared Rust/WASM Help core. Browser JavaScript must not implement a competing template-selection, fact-interpolation, fallback, escaping, or HLP-semantic engine. The browser host must not fetch a Help catalog from the network, the filesystem, the Suitcase, or an adjacent deployment file. Missing or malformed embedded catalog JSON, or a build whose embedded catalog does not correspond to the validated build input, is a build-validation failure. The released HTML therefore remains one offline portable front door for the browser Help catalog. A later native host may supply the same governed catalog semantics to the same shared core from its own build-bundled resource; host packaging may differ, but Help semantics must not fork.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003,Message and report outputs,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The Help Engine must support both live and durable help surfaces.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003.1,The Help Engine must support a concise human-facing message suitable for the live browser surface.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The concise message is rendered in the dedicated browser Help / Diagnostic Surface when that surface is present; it is not required to be a modal or transient notification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003.2,"The Help Engine must support a durable HTML Help report using the canonical built-in Data Sculptor presentation suitable for saving with the Work Order, receipt, and output artifacts.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"A concise Help message for an individual diagnostic and any durable Help Report that includes that diagnostic must resolve from the same canonical diagnostic event. A durable Help Report request may cover one active governed diagnostic, including a non-run diagnostic, or one governed run containing one or more canonical diagnostic events. Exactly one HLP is published for each explicit Help Report request.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004,HTML Help report content,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,A saved Help report must be able to include the following elements when relevant.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.1,Product and brand identity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.2,Plain-language summary.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.3,Stable diagnostic ID.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.4,What Data Sculptor observed.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.5,Evidence and structured facts.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.6,What the user can safely do next.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.7,Source/Work-Order context is governed by the HLP disclosure allowlist.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The report may include only source and Work Order context permitted by W002-HELP-010. Durable HLP disclosure is intentionally stricter than transient local Help because the HLP is a portable support-handoff artifact. A relevant governed alias or source header may enter the HLP only under the necessity and disclosure rules in W002-HELP-010. Source-header text is eligible only when Data Sculptor has structurally established an actual CSV header record under the governed parser. Record position alone does not make text a header. When no valid header record has been established, including the headerless-source refusal case, the HLP must use structural evidence such as the 1-based column ordinal, diagnostic condition/location, or an applicable operational fallback name and must not substitute field data from the first data row. Absolute local paths, entire Work Orders, Work Order comments, source rows/values, unrelated headers/aliases/columns, and unrelated Suitcase contents are not automatically eligible merely because they are available to the running application.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.8,Report-generation metadata preserves HLP identity and lineage.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The report must carry its own governed HLP filename and generation UTC together with the diagnostic identity and applicable originating execution lineage. The exact HLP provenance contract is governed by W002-HELP-009.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.9,Selected Help voice and its human-facing explanation.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.10,A clearly labelled structured-facts block derived from the canonical diagnostic event.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.11,Four canonical Boolean facts describe the WASM-002 execution boundary.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When the governed diagnostic context can determine the execution boundary, the canonical fact names are exactly: source_modified_by_data_sculptor materialization_started analytical_outputs_published store_state_committed When one of these facts has an established Boolean value, the JSON/structured value is the native Boolean true or false , never the strings ""TRUE"" or ""FALSE"" . source_modified_by_data_sculptor states only whether Data Sculptor modified the analyst-owned source in place; it must not imply knowledge that no external process or analyst changed the source between sessions. materialization_started records whether the governed analytical materialization phase began. analytical_outputs_published records whether governed analytical outputs were successfully published for user use; transient SCR candidates or abandoned/uncommitted debris do not make this fact true. store_state_committed records whether the successor Store MAP commit point was crossed. If a present boundary fact must express governed absence rather than an established Boolean, its JSON/structured value is the exact applicable shared absence-state string ""NONE"" , ""NOT_RUN"" , ""NOT_AVAILABLE"" , or ""NOT_APPLICABLE"" . JSON null is not a valid encoding for these four boundary facts because it would discard the reason for absence. A boundary fact that is optional for a particular diagnostic may instead be omitted under W002-HELP-001.4; that omission carries no absence-state meaning. A missing, omitted, unavailable, or not-run fact must never be interpreted as false . If one of these facts is declared required for an intended diagnostic and the required value cannot be produced, it must not be silently defaulted; the intended diagnostic is suppressed and the fail-safe DS-HLP-001 contract in W002-HELP-001.4/W002-HELP-001.8 applies.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.12,Governed Work Order lineage sufficient to establish user intent.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,Included lineage must obey the disclosure boundary defined for Help reports and must not automatically expand into source-data disclosure.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-005,Deterministic rendering uses a closed governed input set,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Given the same canonical diagnostic event or ordered set of events, selected voice, PRETTY rules, validated Help catalog, and built-in presentation version, Help rendering must be deterministic except for explicitly permitted event/report-specific fields. The Help renderer may consume only the canonical diagnostic fields and fact keys declared by the applicable diagnostic registry entries plus fields explicitly defined by the applicable HLP provenance schema. It must not inspect or interpolate an open-ended host-state bag, undeclared browser state, unrelated Suitcase contents, or another value merely because it is available at runtime. A future configurable Brand Manifest may add another governed presentation input, but it is not part of the WASM-002 rendering contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-006,Host parity uses one shared Help semantic core,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help Engine must be designed for use by the browser host and the later native CLI host without changing diagnostic semantics. The shared Rust core owns diagnostic-to-template selection, governed fact interpolation, deterministic fallback behavior, governed escaping, and durable HLP semantic serialization. The WASM-002 browser host supplies the validated catalog embedded under W002-HELP-002.11. A later native host may supply the same governed catalog semantics from a build-bundled native resource. Host-specific presentation and packaging may differ, but they must not create a second Help semantic engine or change canonical diagnostic identity, facts, behavior, next action, voice semantics, disclosure policy, or HLP meaning.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-007,"Help surfaces are projections, not diagnostic authority",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The live Help / Diagnostic Surface and the saved HTML Help Report must render from the canonical diagnostic event. Neither surface may independently create, reinterpret, weaken, suppress, or override governed diagnostic truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008,HTML Help Report is a governed support-handoff artifact,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The user must be able to generate a styled, self-contained HTML Help Report from a governed diagnostic event for retention, IT/support handoff, or communication to another analyst. The report must support two audiences in one document: a human-readable explanation using the selected Help voice and a clearly inspectable structured-facts section that preserves the technical evidence required to understand the event.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008.1,"The report preserves the canonical execution-boundary facts, including relevant negative facts.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When relevant to the diagnostic, the report must render the governed values of source_modified_by_data_sculptor , materialization_started , analytical_outputs_published , and store_state_committed . These values originate from governed execution state rather than reassuring prose invented by the renderer. A missing/unavailable fact is not rendered as false .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008.2,The report preserves only the Work Order lineage needed to explain the diagnostic.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The report must identify the originating WKO physical filename when one applies and may include only the minimum executable Work Order clause or clauses needed to establish the governed operation, user intent, and trigger for the diagnostic. It must not automatically embed the entire Work Order or Work Order comments. All such context remains subject to the fixed disclosure boundary in W002-HELP-010.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-009,"WASM-002 establishes HLP identity, lineage, multiplicity, and one canonical embedded provenance payload.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"A durable generated Help Report is an immutable governed HLP artifact whose physical filename is: __DS__HLP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html The UTC token is the HLP's own governed generation/publication time. The report is the final self-contained HTML artifact using the canonical built-in Red5Sorcery/Data Sculptor presentation; no unstyled intermediate is the canonical HLP. Report-request multiplicity: one explicit Help Report request publishes exactly one HLP. The request may be bound to one active governed diagnostic, including a diagnostic that is not associated with a Run, or to one governed Run containing one or more canonical diagnostic events. A Run-level report includes the governed diagnostic events selected by that request in deterministic event order. HLP generation is never an automatic one-artifact-per-diagnostic side effect. Every HLP must expose a visible deterministic Provenance section and exactly one embedded non-executable application/json payload whose element ID is exactly ds-hlp-provenance . F-34 supersedes the earlier draft schema version ""1"" . For schema version ""2"" , the JSON top-level object contains exactly these ten fields: {
  ""schema_version"": ""2"",
  ""hlp_filename"": ""__DS__HLP__20260922T191500123Z__<uuid-v4>.html"",
  ""hlp_generation_utc"": ""20260922T191500123Z"",
  ""diagnostic_ids"": [""DS-ENC-001"", ""DS-MAT-004""],
  ""originating_wko_filename"": ""__DS__WKO__...txt"",
  ""originating_rcp_filename"": null,
  ""selected_help_voice"": ""technical"",
  ""presentation_id"": ""red5sorcery-data-sculptor"",
  ""presentation_version"": ""1"",
  ""data_sculptor_build"": ""<exact-build-id>""
} hlp_generation_utc must use the canonical fixed-width millisecond UTC form YYYYMMDDTHHMMSSmmmZ . diagnostic_ids is a non-empty JSON array containing one canonical diagnostic ID for each diagnostic event included in the report, in the same deterministic event order used by the report. Repeated IDs are permitted when distinct included events legitimately share one diagnostic type. selected_help_voice is exactly one of casual , office_speak , or technical , matching the Help catalog keys. For WASM-002 the built-in presentation identity is exactly red5sorcery-data-sculptor and its presentation version is exactly ""1"" . data_sculptor_build must contain the exact running build identifier used for the tested/released build; the literal scope label WASM-002 alone is not sufficient unless it is also the exact build identifier. originating_wko_filename and originating_rcp_filename are schema-declared nullable lineage fields . When the relationship exists and the exact physical filename is known, the value is that filename as a JSON string. When the relationship itself does not apply to this Help event/report request, the machine-readable value is JSON null . That null has one schema-defined meaning: the nullable relationship has no value, equivalent to Rust Option<T>::None and to the governed semantic state NOT_APPLICABLE . The visible Provenance section renders it as NOT APPLICABLE . If the lineage relationship does apply but the exact filename cannot be obtained, JSON null must not be used; the field value is the exact string ""NOT_AVAILABLE"" and the visible Provenance section renders NOT AVAILABLE . Empty strings, invented lineage, N/A , UNKNOWN , or another substitute are forbidden. For these two lineage fields, null and ""NOT_AVAILABLE"" are deliberately non-interchangeable. A non-run HLP may therefore legitimately carry JSON null for both lineage fields when neither relationship applies. This nullable-field rule is a schema-specific serialization choice, not a fifth absence state and not a generic JSON encoding rule. Other diagnostic JSON facts follow W002-HELP-001.4 and W002-HELP-004.11. The visible and machine-readable HLP provenance must express the same governed semantics even where their physical representations differ; a semantic mismatch is an HLP-generation failure and must not be silently tolerated. The embedded JSON must be HTML-safe so provenance text cannot terminate the containing script element; at minimum literal less-than characters in JSON string content must be escaped during embedding. The provenance payload remains subject to W002-HELP-010 and must not introduce source rows, source values, absolute local paths, arbitrary Work Order content, or other context excluded by the fixed HLP disclosure policy. WASM-002 does not automatically compute or embed a SHA-256 of the HLP, and saving an HLP must not create, refresh, or verify an LCK . The final HLP bytes remain eligible for exact-byte integrity evidence under the later explicit FINGERPRINT/LCK workflow. Configurable Brand Manifest provenance remains deferred to V1-BACKLOG / a future build. F-14 HLP publication: the complete self-contained report is first written as the corresponding SCR candidate under W002-STOR-023.1. It must close, reopen, and validate the required visible Provenance section, exact schema-version-2 embedded JSON shape, HTML-safe serialization, self-contained presentation and visible/machine semantic parity before the class token may be renamed from SCR to HLP . A partial or semantically mismatched candidate never becomes a canonical HLP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-010,Help Report disclosure uses one fixed WASM-002 allowlist.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Generating a Help Report must not silently become a data-export path. WASM-002 therefore uses one deterministic allowlist rather than collecting broad context and attempting to redact it afterward. There are no disclosure checkboxes, permissive export modes, or per-report overrides in WASM-002. Always eligible when present and applicable: diagnostic ID; severity/classification; governed operation/phase; continue/refuse decision; safe next action; selected Help voice; HLP identity and generation UTC; relevant governed artifact filenames; and the four canonical boundary facts from W002-HELP-004.11. Eligible only when necessary to explain the diagnostic: the exact source filename but not an absolute OS path; a relevant source column header only when Data Sculptor has structurally established an actual CSV header record; the relevant 1-based column number; a relevant governed Store/RID/COL alias only when that alias itself is necessary to explain the diagnostic, such as an alias collision, ambiguity, or governed alias mutation; byte offset, row/count, or byte-length evidence; Store/RID/COL/MAP/WKO physical filenames; and only the minimum executable Work Order clause or clauses needed to establish intent and the diagnostic trigger. If that minimum Work Order excerpt necessarily contains a governed alias, that alias is disclosed and counts as alias text included. Headerless boundary: record position alone never establishes a source header. If the governed parser has not established a valid header record, including a headerless-source refusal, HLP generation must not treat any field from the first data row or any later data record as header text. Structural evidence such as 1-based column ordinal, governed diagnostic/location facts, or an applicable operational fallback name must be used instead. Never included automatically: source rows; source field values or arbitrary data samples; field data mislabeled as header text; absolute local paths; unrelated source headers, aliases, or column names; the complete Work Order; Work Order comments; unrelated Suitcase contents; browser/environment internals not governed as diagnostic evidence; or raw ungoverned stack traces. Every generated HLP must contain a visible Disclosure section stating, at minimum: Source rows included: NO ; Source values included: NO ; Source header text included: YES or NO ; Governed alias text included: YES or NO ; Absolute local paths included: NO ; Work Order comments included: NO ; and Work Order excerpt: RELEVANT EXECUTABLE CLAUSES ONLY . The two YES/NO declarations must truthfully reflect the actual HLP bytes. A genuine established source header does not count as a source field value; this distinction applies only after the governed parser has established the header record. The renderer must not weaken any declaration when the underlying policy has not changed. This durable-HLP allowlist does not prohibit transient local Help from showing a relevant governed alias or a genuinely established source header when useful to explain the same canonical diagnostic event. Local presentation does not enlarge what the portable HLP may disclose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011,Help owns the cross-session source-continuity edge-case explanation,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When an unexpected analytical result, row-alignment concern, or support question raises the possibility that an analyst-owned source changed between sessions, Data Sculptor-controlled guidance must flow through the Help Engine. Help must not imply that the engine monitored or cryptographically protected the source when it did not. The explanation must distinguish ordinary analyst-controlled workflow from stronger optional evidence. It may ask whether the analyst edited, replaced, sorted, re-exported, synchronized, copied over, or otherwise changed the source after the Store was established.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011.1,Help presents continuity evidence in explicit assurance levels,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"For a suspected cross-session source change, Help must distinguish at least these evidence levels: No continuity evidence: state that cross-session byte continuity cannot be independently verified from filename/Store metadata alone. INVENTORY available: use filename, exact byte length, and last-modified metadata as lightweight clues; changed metadata may indicate that the source changed, while unchanged metadata must not be presented as proof of unchanged bytes. Explicit fingerprint evidence available: exact-byte SHA-256 evidence may establish whether the compared file bytes match or differ under the later governed FINGERPRINT workflow. Help must not collapse these levels into one generic statement of certainty.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011.2,WASM-002 does not impose automatic cross-session hashing or Suitcase surveillance,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Ordinary WASM-002 materialization and Store inheritance must not automatically SHA-256 the source, recursively fingerprint the Suitcase, or maintain hidden whole-Suitcase surveillance merely to guard against the possibility that an analyst-owned file changed between sessions. This is an intentional product boundary for the lone-office-analyst model. The product assumes the analyst normally controls the Suitcase, provides lightweight explicit INVENTORY evidence in WASM-002, preserves a later explicit FINGERPRINT path for stronger assurance, and relies on Help to explain unusual cross-session continuity questions proportionately. WASM-002 must not create, refresh, or silently verify an LCK Suitcase Lock as a side effect of Work Order save, materialization, Store inheritance, INVENTORY, alias maintenance, or ordinary project use. LCK publication belongs to the explicit later-V1 FINGERPRINT workflow. F-13 single-writer Help boundary: Help must distinguish cross-session continuity from concurrent writing. WASM-002 does not claim that two Data Sculptor tabs/windows can safely write the same Suitcase at once. User guidance must say to use one writing Data Sculptor context per Suitcase; read-only viewing is not itself a governed write. When a pre-commit guard detects that relevant governed state changed underneath an operation, Help must identify the changed authority where available and direct the analyst to refresh or reopen current state and rerun deliberately. It must not imply that Data Sculptor acquired a cross-tab lock, merged the competing work, or automatically rebased the refused transaction.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-001,Separation of truth and presentation,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,The PRETTY Engine must not decide analytical truth or reinterpret diagnostic meaning. It receives governed content and renders it into human-facing artifacts. WASM-002 conceptual boundary: ENGINE TRUTH -> HELP / REPORT CONTENT -> PRETTY ENGINE -> BUILT-IN DATA SCULPTOR PRESENTATION -> ARTIFACT. A future build may replace the built-in presentation source with a governed Brand Manifest without changing the analytical or diagnostic truth supplied to PRETTY.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-002,Shared renderer path,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"The PRETTY Engine must provide a common rendering path for Data Sculptor artifacts that require governed human presentation, including at minimum the WASM-002 Help HTML report. WASM-002 uses the canonical built-in Red5Sorcery/Data Sculptor presentation. The architecture must permit the same path to accept a configurable Brand Manifest in a future build without changing analytical semantics. The architecture must also permit later reuse for branded Receipt HTML, verification reports, tables, Quick Viz, and other PRETTY outputs. WASM-002 canonical run Receipts themselves remain TXT-only under W002-RCP-003.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003,Self-contained HTML,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"Durable HTML artifacts produced by PRETTY must be self-contained for ordinary viewing after generation. Self-containment requires semantic and functional portability, not pixel-identical rendering across operating systems or browsers; ordinary system-font substitution and browser rendering differences are acceptable when meaning, evidence, hierarchy, and accessibility remain intact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.1,A saved artifact must not require a network connection.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.2,A saved artifact must not require an external stylesheet.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.3,A saved artifact must not require a remote font.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.4,A saved artifact must not require a separately located logo file.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.5,A saved artifact must not require external presentation resources.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"Required CSS, SVG, and other built-in presentation assets needed for ordinary viewing must be embedded or otherwise resolved into the generated artifact at creation time. Future configurable Brand Manifest inputs, when implemented, must preserve this self-contained output rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-004,Accessibility and inspectability,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"PRETTY HTML must remain ordinary inspectable HTML. Presentation must not obscure the text, evidence, diagnostic code, provenance, or next-step guidance. The rendered artifact must remain usable without JavaScript when JavaScript is not required for its content.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-QA-001,Governed test-only seams and acceptance coverage,W002-QA,W002-QA,WASM-002,UNDER REVIEW,—,"Every material frozen WASM-002 behavior must have retained acceptance evidence sufficient to exercise the governed success, refusal, mutation, publication, or recovery boundary that makes the behavior meaningful. Related cases may share one fixture when the shared fixture proves each required condition explicitly; acceptance coverage must not rely on a behavior being difficult to reproduce under an uncontrolled host environment. Permitted deterministic test-only seams. WASM-002 acceptance may use controlled clock values; controlled UUID sequences and collision outcomes; controlled filesystem create/write/close/rename/promotion failures; and controlled run-local source-handle reread/substitution conditions. A seam supplies only the external condition required to reach the governed behavior. It must not bypass validation, alter the normative semantic result, change governed serialization, relax publication rules, rewrite diagnostic truth, or create a second analytical execution model. Release boundary. Test-only controls must not be invocable through the ordinary Data Sculptor UI, DS-STEPS, saved Work Orders, URL/query parameters, Suitcase configuration, or another analyst-facing product path. Compile-time exclusion, test-build configuration, or an isolated acceptance harness are permitted implementation techniques. Retained acceptance evidence must identify any seam used and must separately demonstrate that the accepted release surface cannot invoke that seam as a user feature. Named storage acceptance gaps. Acceptance must include a case-variant governed namespace/class fixture proving that Data Sculptor does not silently normalize the variant spelling into canonical governed identity; an unknown syntactically valid governed-class fixture proving that the file remains byte-for-byte unchanged while a canonical INFO diagnostic and INVENTORY surface the unknown/unrecognized class; and at least one known-but-not-emitted-class fixture drawn from DGN , RCV , BRD , or LCK proving the same preserve-and-report behavior without activating a producer, lifecycle, or interpretation path. Carried feature gates remain feature-owned. Mechanisms whose normative lifecycle is integrated in another package — including the F-02 Work Order-registry/alias-replacement behavior, the F-04 existing-Store cardinality refusal, and the F-24 CER-history decision — cannot be considered accepted without their corresponding feature acceptance gates. This requirement does not invent those feature semantics. If a proposed mechanism is removed from WASM-002 rather than integrated, no acceptance gate for that removed mechanism is required.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-001,UTF-8 certification pass,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,A valid multi-gigabyte UTF-8 fixture must complete whole-source certification with exact byte accounting under bounded memory.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-002,UTF-8 certification fail,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"A fixture containing an invalid UTF-8 sequence, including a sequence that crosses an input-window boundary, must deterministically produce STAGE1_UTF8_OUTCOME: FAIL , UTF8_STOP_REASON: INVALID_UTF8_SEQUENCE , and the exact governed zero-based UTF8_FIRST_INVALID_BYTE_OFFSET . Stage 2 must not begin and no analytical materialization output may be published. The same bytes tested under different permitted Stage-1 input-window sizes and boundary placements must yield the same outcome, stop-reason token, and first-invalid offset.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-003,Run-local source substitution refusal,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"An acceptance fixture must attempt to present Stage 2 with a different source instance/reference than the one retained from Stage 1. The run must refuse before materialization rather than accept the substitute merely because filename, alias, path, or byte length appears compatible. F-23 governed seam: this fixture must use the test-only source-handle substitution/reread seam permitted by W002-QA-001 so the different Stage-2 instance is injected without changing the analyst-visible SOURCE syntax or adding a product-level source-selection path. Release-surface evidence must demonstrate that an analyst cannot invoke this substitution seam through the normal UI, Work Order, URL/query, or Suitcase configuration.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-004,ASCII-only fast path,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,An all-ASCII fixture must certify successfully without invoking non-ASCII sequence validation and must produce exact byte accounting.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-005,Valid non-ASCII sequence matrix,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"Acceptance must cover valid two-byte, three-byte, and four-byte UTF-8 sequences, including sequences placed at window boundaries and split at every legal boundary position.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-006,Strict invalid-sequence matrix,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"Acceptance must reject at known exact offsets: lone continuation bytes, malformed continuation sequences, truncated sequences, overlong encodings, UTF-16 surrogate encodings, invalid lead bytes 0xC0 / 0xC1 , values introduced by 0xF5 - 0xFF , and code points above U+10FFFF. Every invalid fixture must serialize the same canonical UTF-8 stop reason INVALID_UTF8_SEQUENCE while preserving its fixture-specific exact first-invalid byte offset. For an EOF-truncated multibyte sequence, the expected offset is the lead byte of the incomplete sequence. Acceptance must include at least one malformed sequence crossing a Stage-1 input-window boundary and prove window invariance. Separate valid fixtures covering ASCII-only, valid multibyte UTF-8, and permitted leading-BOM forms must complete with STAGE1_UTF8_OUTCOME: PASS ; their UTF-8 refusal-only Receipt fields are NOT_APPLICABLE .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-007,Late invalidity,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,A source that is ASCII/valid UTF-8 until near EOF and becomes invalid late in the file must fail at the first invalid absolute offset; bounded-prefix success must not be treated as whole-file certification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-008,Window-size invariance,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,The same fixture matrix must return the same PASS/FAIL and first invalid absolute offset across at least two materially different bounded window sizes.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-009,EOF pending-state refusal,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,EOF with an incomplete UTF-8 sequence must fail deterministically and report the governed offset; no replacement character may be inserted.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-010,BOM behavior,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"A UTF-8 BOM at offset zero must be accepted as metadata while the remainder of the source is still fully certified; a BOM must not mask later invalid UTF-8. F-07 BOM coordinate fixture: when a permitted three-byte UTF-8 BOM precedes a later malformed UTF-8 sequence, the expected first-invalid offset counts the BOM's physical bytes. The BOM is excluded from analytical CSV content but included in the absolute physical source-byte coordinate system.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-001,Multi-column one-pass Stage 2 materialization,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Using a valid UTF-8 source and a Work Order requesting at least four source columns through a mixture of HEADER and COLUMN selectors, acceptance must prove that Stage 1 completes first, Stage 2 restarts at byte zero of the same run-local source instance, parses the header once, resolves all selectors before the first data row, and reads the source data records only once while producing all requested columns. Evidence must reconcile total source bytes read by Stage 2, logical data-row count N, per- COL data-record count N, selector-to-source ordinal/header resolution, resolved KEEP order, and the resulting successor MAP. A one-column rerun of the same source/column must produce the same canonical physical column bytes as that column produced inside the multi-column run, apart from governed artifact identity. F-20 width/one-pass acceptance: acceptance must include a maximum-width fixture whose valid source has exactly 16,384 columns and whose KEEP resolves all 16,384 distinct columns. Instrumentation must prove one source data-record traversal regardless of the implementation's bounded post-scan spool/finalization strategy. A companion 16,385 -column source must refuse during header resolution before the first data record is consumed.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002,"Automatic Store MAP creation, inheritance, and rematerialization continuity",W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must materialize four previously unseen source columns in one Store-establishing Work Order and prove that one successor Store MAP is created with four mapping rows. Every row must repeat identical Store-level fields, bind the newly created RID filename, default store_alias to the exact Store-establishing source filename, default rid_alias to RID , and default each COL alias to its exact source header. A later Work Order using the same exact SOURCE without explicitly naming a MAP must route under W002-STOR-019.2 . If exactly one routable Store lineage exists for that exact source filename and its current Store state permits materialization, the Work Order must inherit that lineage’s current structurally valid Store MAP, preserve the Store/RID metadata and four prior mappings, add a fifth default COL alias, and publish one new complete Store MAP. A later rematerialization of one earlier logical column must preserve its inherited COL alias while updating its column_filename . An explicit older MAP selection must instead use that historical Store state. Equal-latest-timestamp ambiguity within one routed lineage, malformed-newer-MAP fallback within the same Store lineage, no-routable-Store-lineage creation, and multiple-routable-Store-lineages-for-the-same-source refusal must also be exercised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.1,Exact eight-column Store MAP serialization acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must validate the exact Store MAP header store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename , UTF-8 without BOM, LF line endings, deterministic mapping-row order, standard governed CSV quoting, and byte-for-byte repetition of store_alias , rid_filename , rid_alias , and the common source_filename on every mapping row. The fixture must prove that a MAP with inconsistent repeated Store-level metadata, more than one rid_filename , more than one source_filename , a missing or invalid RID filename, a duplicate logical source-column key, or a non-eight-column schema is ineligible for inheritance. Source compatibility fixtures must prove that an explicit MAP may proceed only when the Work Order SOURCE exactly equals that MAP's common source_filename . A different source must refuse before materialization even when its row count equals the Store's RID cardinality; matching row count never creates a positional-join escape. P3-06 validation-tier fixtures: acceptance must distinguish Store-health Tier 1 from full Tier 2 validation. A same-named externally restored RID/COL may be treated as eligible only after it passes the tier required by the operation, and no fixture may label such an artifact “the exact original” solely from its physical filename. Tier-1 fixtures must prove the exact bounded checks in W002-STOR-019.10 without an end-to-end scan of every artifact value. Tier-2 fixtures must prove full RID sequence/cardinality validation and full COL canonical-form/header/cardinality validation. REPAIR MAP fixtures must demonstrate that the same input bytes yield one deterministic set of removed COL bindings under Tier 2. P2-04 closure fixtures: acceptance must include (1) a RID that satisfies Tier 1 but fails Tier 2 because the body does not contain the exact declared 1..N sequence; (2) a COL that satisfies Tier 1 but fails Tier 2 because its complete CSV body or logical-record count is invalid; (3) an externally supplied same-named RID/COL that passes the required governed tier without any assertion that it is the historical original bytes; and (4) a REPAIR MAP case with a mixture of Tier-2-valid and Tier-2-invalid COLs proving that the successor removes exactly the failing bindings. Repeating the same fixture bytes must yield the same repair set and successor mapping.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.2,Multiple Stores in one Suitcase remain distinct through RID-anchored MAP lineages,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must establish at least two Stores from different source files in the same Suitcase. Their Store MAP lineages must contain different immutable rid_filename values, and automatic routing for each source must choose only that source's routable Store lineage. The fixture must prove that a lineage remains routable when at least one Store MAP is structurally valid even if subsequent Store-health evaluation is DEGRADED or INVALID ; health may refuse the operation, but it must not make the lineage disappear from routing. Changing a human-facing store_alias or rid_alias in a later governed MAP must not change the Store's rid_filename , RID bytes, or lineage identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.3,WKO MAP profile and alias-registry publication acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must save at least three immutable WKO artifacts, each containing exactly one non-empty WORK ORDER AS clause: one with a multi-word alias, one whose alias is deliberately replaced under the frozen WKO lifecycle, and one with punctuation permitted by the governed string rules. The committed WKO MAP must satisfy the frozen current-registry schema and lifecycle rules, use UTF-8 without BOM and LF endings, preserve exact physical WKO references, and prove deterministic governed serialization. The fixture must prove that a WKO MAP cannot be treated as a Store MAP; duplicate physical WKO rows are invalid; conflicting current authority for the same non-empty alias is refused before commit; and equal-latest-timestamp ambiguity refuses current-registry selection. A saved/executable WKO without WORK ORDER AS is invalid in Revision BM and must refuse before execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.4,WORK ORDER AS and # comment lexical acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must prove that WORK ORDER AS ""Prepare monthly crime data"" is parsed as the immutable WKO alias, that whole-line and trailing # comments are ignored semantically, and that # inside double-quoted strings remains ordinary string content. The fixture must also prove that saved WKO bytes preserve comments exactly, that changing only a comment or Work Order alias requires a new WKO physical identity, and that no standalone browser Description value is required to reopen or display the governed alias. P3-10 alias fixture: acceptance must prove that WORK ORDER AS ""   "" refuses as a whitespace-only alias, while an otherwise valid alias containing leading or trailing whitespace is not silently trimmed or normalized and is preserved exactly in saved WKO bytes and the governed alias registry.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-003,Stage 2 structural window-invariance matrix,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Acceptance fixtures must force input boundaries at structurally difficult positions including before/after delimiters, before/after opening and closing quotes, between doubled quote bytes, between CR and LF, inside quoted multiline field content, at empty fields, and inside already-certified multi-byte UTF-8 sequences. Across permitted window sizes and boundary placements, the logical row count, selected values, canonical COL bytes, first refusal location/condition, and resolved mapping semantics must remain invariant. P3-09 fixtures: acceptance must include both byte forms identified by the Pass 3 finding: (1) an exactly zero-byte source and (2) a source containing only the three UTF-8 BOM bytes EF BB BF . Both must pass the applicable Stage 1 UTF-8 gate and then refuse in Stage 2 with NO_HEADER_RECORD . The exact expected location tuples are respectively (offset 0, physical line 1, logical record 1, field ordinal 1) and (offset 3, physical line 1, logical record 1, field ordinal 1) . The fixtures must also distinguish this case from an existing-but-blank first logical record, which remains BLANK_LOGICAL_RECORD . P3-10 delimiter-help fixture: acceptance must include a quoted semicolon-delimited form such as ""a"";""b"" and an equivalent TAB-delimited quoted form that reach INVALID_BYTE_AFTER_CLOSING_QUOTE . The canonical refusal condition and location facts must remain unchanged, while the Help rendering is permitted to surface the delimiter-mismatch hint for offending byte 0x3B or 0x09 . F-06 structural-refusal acceptance matrix An unexpected quote in an unquoted field must report the quote byte and UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD . A prohibited byte after a closing quote must report that byte and INVALID_BYTE_AFTER_CLOSING_QUOTE . A bare CR outside quoted content must report the CR byte and BARE_CR_OUTSIDE_QUOTED_FIELD . CR, LF, and CRLF inside valid quoted values must remain field content and must not trigger the bare-CR rule. EOF in an open quoted field must report the one-past-end source offset and EOF_INSIDE_QUOTED_FIELD . A blank logical record must report BLANK_LOGICAL_RECORD , not TOO_FEW_FIELDS . A short record must report the terminator/EOF location and the first missing field ordinal. A wide record must report the comma delimiter opening the first extra field and that extra field ordinal. All five refusal facts must remain identical across permitted source-window sizes and boundary placements. Fixtures must force boundaries around commas, opening and closing quotes, doubled-quote pairs, CR/LF pairs, quoted multiline content, empty fields, and already-certified multibyte UTF-8 sequences. A semicolon-separated file must not refuse solely because it uses semicolons; Help may explain comma-only interpretation when header selection fails. Day 060 H-13 Receipt-corpus binding for P3-09 The two analytical P3-09 source fixtures above must each have a corresponding byte-exact refusal Receipt under W002-RCP-ACC-002. The zero-byte and BOM-only cases therefore prove both the parser/refusal oracle and the Receipt serialization oracle independently.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-004,Canonical one-column COL serialization acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Golden-byte fixtures must cover ordinary ASCII, non-ASCII UTF-8, commas, embedded double quotes, CR, LF, CRLF inside quoted values, explicit empty data values, empty source headers, and header-only zero-row input. Acceptance must prove one UTF-8 BOM at file start, LF record termination independent of host platform, deterministic minimal quoting, doubled embedded quotes, """" for an empty one-column data value, no accidental inclusion of the source BOM in the first header, and byte-identical round-trip semantics through the Data Sculptor CSV reader. F-20 oversized-header serialization acceptance: fixtures at exactly 1,024 and 1,025 Unicode scalar values must prove that the physical COL header remains byte-faithful to the exact decoded source header while only the operational/default-alias name changes at the boundary. Scalar-count fixtures must include combining characters so acceptance cannot accidentally measure UTF-8 bytes or grapheme clusters instead.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-005,"Field-limit, ragged-record, blank-record, and failure-publication acceptance",W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Acceptance must include decoded field sizes exactly 16 MiB and 16 MiB + 1 byte, malformed runaway quoted-field cases, nonblank records with too few and too many fields, a bare blank logical data record, explicit empty fields, and a physical blank line inside a valid quoted multiline field. The first invalid case must refuse without truncation or silent repair. Publication evidence must additionally exercise both a new-Store multi-column materialization and a later existing-Store materialization. For the new Store, the shared publication-transaction UTC must be established before any new RID/COL SCR candidate is opened, and each candidate-specific UUID must be allocated before its candidate is created. RID and COL outputs must remain governed SCR until the complete candidate set validates; the RID must then promote first, requested COLs must promote in deterministic KEEP order, the successor MAP UUID must be allocated before its MAP SCR candidate is opened, that MAP candidate must be written/closed/reopened/validated while still SCR , and its final SCR -to- MAP rename must occur last. For every successfully promoted RID, COL, and MAP artifact, acceptance must prove that the candidate and final identity have the exact same UTC, UUID, extension, and bytes and differ in the governed filename only by the three-letter semantic class token. For the existing Store, the inherited RID must remain byte-for-byte and filename-identical with no new RID candidate. F-04 existing-Store cardinality acceptance: acceptance must include two otherwise valid existing-Store materializations using the same exact governed SOURCE identity. In the equal-cardinality fixture, Stage 2 candidate N must equal the inherited RID-header N and publication may proceed under the ordinary rules. In the mismatch fixture, candidate N must differ from RID-header N ; the Run must refuse before any candidate COL is promoted into the final COL namespace and before any successor MAP is published. The inherited RID, current MAP, existing COL artifacts, and Store health must remain unchanged, with the existing Store remaining VALID. The equal-cardinality case must not be represented as proof of source-byte or row-semantic identity. Forced failure cases must cover: failure before any promotion; RID-promotion failure; failure during COL promotion after RID and at least one COL have promoted; MAP-candidate write/close/reopen/validation failure; MAP final-rename failure; and interruption after physical RID/COL promotion but before MAP commit. Each case must prove rollback where safely possible or visible non-authoritative SCR failure evidence otherwise, must prove that unreferenced final-class-looking RID/COL files are not treated as committed Store membership, and must prove that the prior valid MAP remains authoritative for an existing Store or that no committed Store exists for an uncommitted first materialization. F-20 bounded-width/name acceptance: acceptance must cover exactly 16,384 versus 16,385 source columns; KEEP widths of 1 and 16,384 ; operational-name derivation at 1,024 versus 1,025 Unicode scalar values; physical ordinals producing Column A , Column Z , Column AA , and Column XFD ; and deterministic oversized-header fallback collisions proving [ordinal] then -2 progression. A separate short-header alias collision must prove refusal rather than automatic suffixing.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-006,Large-source browser materialization evidence,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance must include a browser run against the established Statistics Canada scale source or an equivalently retained scale fixture, recording source bytes, Stage 1 time, Stage 2 time, total time, selected-column count, logical row count, bytes written per COL , peak/bounded memory observations, output fingerprints, and browser/platform details. The retained Day 039 evidence established that Microsoft Edge could stream the 7,250,808,204-byte source through a small Rust/WASM materializer and materialize 29,014,718 VALUE data rows in practical time. Revision AM treats that result as engineering evidence and a comparison baseline, not as proof that WASM-002 is already implemented or as a frozen wall-time threshold. F-20 writer-resource evidence: retained acceptance evidence must identify the build's configured maximum simultaneously active writable-output resources and the observed peak for the run. Evidence must show that wide KEEP cardinality does not imply one simultaneously open writer per selected column and that any bounded spool/finalization strategy preserves the same governed output bytes and semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-ACC-001,Separate Windows-1252 conversion,W002-CONV-ACC,W002-CONV,WASM-002,UNDER REVIEW,—,"A non-UTF-8 fixture compatible with the supported Windows-1252 converter must cause the analytical task to stop, permit a Help suggestion, and succeed only when the separate conversion Work Order is explicitly run. P3-08 acceptance: the fixture set must convert an analyst-owned legacy source successfully, materialize the resulting CVT, then perform a second successful conversion from a refreshed legacy source using the same analyst-owned filename. The second conversion must publish a different CVT physical filename. First materialization of that second CVT must establish a distinct Store/RID lineage rather than inherit from the first CVT-backed Store. Acceptance must also prove that Help discloses this consequence at conversion success and again when the CVT is first materialized, and that no hidden original-source identity is used to join the two CVTs into one lineage. F-16 acceptance: the compatible non-UTF-8 fixture must prove that strict UTF-8 certification first emits DS-ENC-001 with next_action: NONE ; Stage 2 does not start; Data Sculptor restarts at byte 0 of the same bound source instance and scans the complete source under the frozen mapping; the Receipt records WINDOWS_1252_COMPATIBILITY_OUTCOME: COMPATIBLE and WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET: NOT_APPLICABLE ; and only then is DS-CNV-001 emitted with severity: INFO , behavior: CONTINUE , and next_action: RUN_WINDOWS_1252_CONVERSION . The refused MATERIALIZE run must remain refused. A separate valid-UTF-8 fixture must prove that both Windows-1252 compatibility Receipt fields are NOT_RUN and DS-CNV-001 is not emitted. F-10 conversion-gate and byte-output acceptance A source already valid as complete strict UTF-8 must refuse CONVERT WINDOWS-1252 TO UTF-8 as unnecessary and create no CVT . A source that fails strict UTF-8 but passes the complete Windows-1252 compatibility assessment may convert only when the separate conversion WKO is explicitly run. The analyst-owned source bytes must remain unchanged. The published CVT must pass complete strict UTF-8 certification. Source CR, LF, and CRLF bytes must be preserved in place rather than normalized. The conversion must remain bounded/streaming. The published CVT must not begin with a UTF-8 BOM introduced by Data Sculptor. The successful Receipt must contain the frozen conversion operation token and required conversion facts. Frozen minimal byte oracle: Windows-1252 source bytes:
63 61 66 E9 0D 0A

UTF-8 CVT bytes:
63 61 66 C3 A9 0D 0A This is café followed by CRLF. The expected CVT begins with byte 63 ; no EF BB BF prefix is present. Day 060 H-25 / BM-04 acceptance: the already-valid-UTF-8 CONVERT fixture must use a complete source whose byte stream is valid strict UTF-8 and must produce a byte-exact refused Receipt containing: SOURCE_ENCODING: UTF-8
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: NOT_RUN
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE The same fixture must prove that no Windows-1252 compatibility assessment runs, no transcoding begins, the analyst-owned source bytes remain unchanged, and no CVT file is created.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-ACC-002,Undefined Windows-1252 byte refusal,W002-CONV-ACC,W002-CONV,WASM-002,UNDER REVIEW,—,"A fixture containing a byte undefined by the frozen Windows-1252 mapping must not be silently converted. F-16 acceptance: use fixtures placing each of 0x81 , 0x8D , 0x8F , 0x90 , and 0x9D at controlled physical offsets, including across compatibility-buffer boundaries. The complete oracle must prove WINDOWS_1252_COMPATIBILITY_OUTCOME: INCOMPATIBLE , the exact first undefined-byte offset, no DS-CNV-001 emission, no conversion recommendation, and window-size invariance. A separate injected read-failure fixture after the compatibility pass begins must prove NOT_AVAILABLE for both compatibility Receipt fields and no conversion recommendation. F-10 conversion-operation undefined-byte acceptance The separate CONVERT WINDOWS-1252 TO UTF-8 operation must itself refuse before transcoding when its complete compatibility assessment encounters any byte undefined by the frozen Windows-1252 mapping. Such a refusal publishes no CVT . Acceptance must cover each frozen undefined byte value at a controlled absolute source offset and prove that no replacement-character, ISO-8859-1, or permissive-decoder fallback produces output. Day 060 H-14 / BM-11 byte-exact undefined-byte CONVERT fixture The golden CONVERT refusal fixture uses this exact analyst-owned source byte sequence: 41 81 42 The strict UTF-8 gate must fail, and the subsequent complete Windows-1252 compatibility assessment must encounter 0x81 as the first undefined byte at exact zero-based absolute physical source-byte offset 1 . The operation must refuse before transcoding begins. The byte-exact Receipt for this fixture must include: SOURCE_ENCODING: WINDOWS-1252-INCOMPATIBLE
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: 1
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE
RESULT: REFUSED The analyst-owned source bytes must remain exactly 41 81 42 ; no CVT is published; no replacement character is introduced; and no ISO-8859-1 or permissive-decoder fallback is permitted. A second acceptance form must place at least two undefined Windows-1252 bytes in one source and prove that the reported offset is always the first undefined byte. Buffer/window-boundary variants must preserve the same absolute offset.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-001,Canonical diagnostic event,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,At least one real governed WASM-002 failure path must emit a complete canonical diagnostic event with stable code and structured facts. A separate test-only fault-injection fixture must remove or withhold one required fact while the engine attempts to assemble a registered diagnostic. Acceptance must prove that the malformed intended diagnostic is not emitted and that exactly one canonical DS-HLP-001 replacement event is emitted with the exact intended diagnostic ID and the complete ascending-UTF-8 list of missing required fact keys.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-002,Three-voice rendering parity,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"A complete event with an authored catalog entry must be renderable in all three established Help voices. Automated checks must demonstrate invariant diagnostic truth across the three outputs. A separate complete registered diagnostic fixture must deliberately have no help_messages.json entry. Casual, Office Speak, and Technical selections must all resolve to the same deterministic Generic Technical Help fallback, preserving the original diagnostic semantic core and rendering emitted facts in ascending UTF-8 fact-key order without invented cause or remediation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-003,Saved HTML Help report using the canonical built-in Data Sculptor presentation,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,At least one complete HTML Help report using the canonical built-in Data Sculptor presentation must be generated and saved locally from that real event.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-004,Offline durability,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,The saved HTML report must remain readable with its canonical built-in Red5Sorcery/Data Sculptor presentation when opened without network access and without access to Data Sculptor or any external presentation resource.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-008,Support-handoff report acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"From a real governed refusal, Data Sculptor must generate one styled HTML Help Report that opens in an ordinary browser without Data Sculptor or network access and contains both a selected-voice explanation and the canonical structured facts needed by a technical reviewer.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-009,Canonical boundary-fact acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"An early-refusal fixture that stops before analytical materialization must demonstrate the exact four Boolean fact names from W002-HELP-004.11 and, when those are the true governed facts, values equivalent to: source_modified_by_data_sculptor = false
materialization_started = false
analytical_outputs_published = false
store_state_committed = false Acceptance must also exercise at least one boundary-fact case in which an established Boolean value is unavailable or otherwise carries an applicable governed absence state. The emitted value must use the exact shared JSON string token required by W002-HELP-004.11 (for example ""NOT_AVAILABLE"" ) and must not be coerced to false or JSON null . Where a boundary fact is optional and its key is omitted, acceptance must prove that omission is not interpreted as false or as any governed absence token. The same fixture family must prove that temporary SCR candidates or abandoned/uncommitted debris do not make analytical_outputs_published true.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-010,"HLP provenance, multiplicity, and no-automatic-hash acceptance",W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"Acceptance evidence must generate a final HLP using the built-in Red5Sorcery/Data Sculptor presentation and verify its governed __DS__HLP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html identity, its visible Provenance section, and exactly one embedded application/json payload with element ID ds-hlp-provenance . The embedded payload must contain exactly the schema-version-2 fields governed by W002-HELP-009 and must verify the same HLP filename/generation UTC, non-empty ordered diagnostic_ids array, WKO/RCP lineage semantics, selected Help voice, built-in presentation identifier red5sorcery-data-sculptor , built-in presentation version ""1"" , and the exact running Data Sculptor build identifier. Acceptance must cover: (1) an explicit request for a single diagnostic; (2) one governed Run with multiple included diagnostic events, proving exactly one HLP for the request and event-order parity with diagnostic_ids ; and (3) a non-run diagnostic such as Suitcase-validation or WKO-save refusal, proving that non-applicable WKO/RCP lineage is represented by JSON null and visible NOT APPLICABLE rather than invented Run lineage. Acceptance must also cover all three lineage representations permitted by W002-HELP-009: an exact physical filename when the relationship exists and is known; JSON null when the relationship does not apply; and the exact JSON string ""NOT_AVAILABLE"" when the relationship applies but its exact filename cannot be obtained. The fixture must prove that null and ""NOT_AVAILABLE"" are not interchangeable. Acceptance must prove that the visible Provenance section and machine-readable payload agree semantically; missing, duplicate, malformed, mismatched, non-HTML-safe, disclosure-violating, empty diagnostic_ids , or scope-label-only build provenance must not be accepted. The same acceptance must prove that ordinary HLP generation does not compute or embed an HLP SHA-256 and does not create, refresh, or verify an LCK . Exact-byte HLP integrity remains outside WASM-002 in the later explicit FINGERPRINT/LCK workflow.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-011,Fixed support-handoff disclosure acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"Acceptance must prove the fixed support-handoff disclosure boundary with both permitted-context and adversarial headerless fixtures. A permitted-context fixture must generate an HLP whose diagnostic requires a source filename, one genuinely established relevant source header and/or 1-based column number, bounded execution evidence, and a small executable Work Order excerpt. A governed alias may appear only when the alias itself is necessary to explain the diagnostic, such as an alias collision, ambiguity, or mutation; an unrelated alias must remain excluded. The report must include only the necessary permitted facts while excluding source rows/values, absolute local paths, unrelated headers/aliases/columns, the complete Work Order, Work Order comments, unrelated Suitcase contents, and raw ungoverned stack traces. A separate headerless-source fixture must place unmistakable sentinel text in the first data row and prove that none of that text appears in the HLP as a header or other disclosed source value. That HLP must show Source header text included: NO and Source values included: NO while still presenting sufficient structural evidence to explain the diagnostic. A genuine-header fixture must prove that a necessary established header may appear with Source header text included: YES . Alias fixtures must similarly prove truthful Governed alias text included: YES only when necessary and NO otherwise. Every fixture must verify the remaining frozen Disclosure declarations from W002-HELP-010. WASM-002 must expose no control that changes this fixed disclosure policy.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-012,Cross-session source-continuity Help acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"An acceptance fixture must present Help with a suspected cross-session source-change scenario and verify that the explanation asks whether the source may have been edited/replaced/sorted/re-exported/synchronized, distinguishes no evidence from INVENTORY metadata evidence and stronger explicit fingerprint evidence, and never claims that unchanged filename or unchanged INVENTORY metadata proves byte identity. A no-evidence fixture must state that continuity cannot be independently verified. An INVENTORY fixture with changed source byte length or last-modified metadata must describe the difference as evidence that the source may have changed, not as a cryptographic conclusion. The fixture must also confirm that ordinary WASM-002 materialization did not automatically hash the source as part of this edge-case protection.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-013,Diagnostic-registry and Help cross-validation acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance must retain the validated diagnostics.json used by the accepted build and verify its exact version-1 schema, canonical sort order, unique permanent IDs, fixed-token grammars, and disjoint required/optional fact declarations. At least one real governed diagnostic fixture must prove that the emitted semantic core matches the matching registry entry and that all required facts are present while no undeclared fact key is emitted. Negative build-validation fixtures must prove deterministic failure for malformed/duplicate registry entries, an engine diagnostic definition absent from the registry, fixed semantic disagreement, an undeclared emitted fact, a Help-catalog diagnostic ID absent from the registry, and a Help placeholder not declared for its matching diagnostic. F-17 runtime completeness fixtures: missing required facts are no longer treated as a malformed event that may leak to Help. Fault injection must prove deterministic substitution with DS-HLP-001 , including exact intended_diagnostic_id and sorted missing_required_facts , with no partially populated intended diagnostic emitted. Separately, a valid registered diagnostic omitted from help_messages.json must remain a valid build/runtime condition and must exercise the Generic Technical fallback rather than build failure or diagnostic suppression. F-22 QA-independence acceptance boundary: acceptance must prove the registry/engine/Help wiring and generic invariants without circularly presenting the implementation-delivered registry as an independent oracle for its own condition-to-Diagnostic-ID allocations. Representative governed fixtures must trace condition → emitted Diagnostic ID → matching registry semantic core → required/optional fact discipline → Help lookup/rendering. Every condition-to-ID or required-fact mapping explicitly frozen elsewhere in this PRD remains independently testable and must match that PRD contract. For allocations not independently pinned by this PRD, WASM-002 does not require a duplicate QA-owned registry that restates every condition-to-ID choice. Passing this acceptance gate therefore demonstrates registry integrity, engine↔registry semantic agreement, fact completeness/legality, Help-catalog wiring, F-17 fail-safe behavior, and representative end-to-end diagnostic routing; it must not be reported as exhaustive independent proof that every possible runtime condition was assigned the semantically correct Diagnostic ID. That residual independence limitation is an accepted WASM-002 risk. F-23 embedded Help-catalog release fixture: acceptance must build the released HTML from a validated help_messages.json , verify exactly one non-executable application/json payload with element ID ds-help-catalog , and include adversarial catalog text containing literal < / script-like delimiter content to prove HTML-safe embedding. Runtime instrumentation must prove that Help lookup reads only the embedded payload and performs no network, filesystem, Suitcase, or adjacent-file fetch for the Help catalog. A missing, malformed, mismatched, or unsafe embedded catalog must fail build acceptance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-007,Work Order syntax is the analytical contract,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"If a value, reference, option, or instruction changes what Data Sculptor analytically does, that intent must be represented in governed Work Order text or in a separately governed artifact explicitly referenced by that Work Order. Browser permission, directory selection, UI focus, a highlighted file, an alias display, or another GUI gesture must not silently become analytical intent. For WASM-002, every executable saved WKO begins with the common preamble: SUITCASE: .
WORK ORDER AS ""<non-whitespace alias>"" Ignoring blank lines and governed comments, the WKO must then parse completely under exactly one of these seven executable operation grammars: Operation Governed DS-STEPS structure after the common preamble MATERIALIZE SOURCE ""..."" ; optional MAP ""..."" ; KEEP ; one or more selectors; terminal MATERIALIZE . INVENTORY terminal INVENTORY only. UPDATE ALIASES exactly one Store-state selector: SOURCE ""..."" or MAP ""..."" ; one or more governed alias mutations; terminal UPDATE ALIASES . REPAIR MAP exactly one MAP ""<exact current Store MAP filename>"" ; terminal REPAIR MAP . REPAIR WORK ORDER REGISTRY terminal REPAIR WORK ORDER REGISTRY only. CONVERT WINDOWS-1252 TO UTF-8 exactly one SOURCE ""..."" ; terminal CONVERT WINDOWS-1252 TO UTF-8 . CATALOG STORES terminal CATALOG STORES only. Each operation-specific numbered requirement remains authoritative for its detailed selectors, preconditions, mutations, publication semantics, and acceptance behavior. This requirement freezes the cross-operation boundary: unknown semantic lines refuse; clauses from another operation grammar refuse unless the selected operation explicitly defines them; there is no best-effort interpretation and no silent cross-operation mixing. Lexical token separation. DS-STEPS keywords are matched ASCII case-insensitively; canonical examples render them uppercase. Wherever two adjacent lexical tokens would otherwise run together, they must be separated by one or more ASCII SPACE ( 0x20 ) or horizontal TAB ( 0x09 ) characters. Leading SPACE/TAB indentation is semantically neutral. Thus REPAIR MAP , SOURCE ""crime.csv"" , and COLUMN 7 are valid tokenizations, while REPAIRMAP , SOURCE""crime.csv"" , and UPDATE_ALIASES are not alternate DS-STEPS spellings. Quoted-string contents are never case-folded or whitespace-normalized merely because keywords are case-insensitive. The browser may authorize resources, edit text, validate, save, invoke Run, display evidence, and provide Help. Authorization to access a resource is not authorization to use that resource analytically.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-008,Every executable Work Order explicitly declares its Suitcase,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"For WASM-002, every executable saved Work Order must contain the exact portable declaration SUITCASE: . . The dot means the filesystem directory that physically contains the saved WKO artifact being executed. A Work Order lacking this declaration must not be treated as an executable WASM-002 Work Order. The declaration is analytical/execution syntax, not a substitute for browser filesystem permission. The host must still possess valid access to the directory before execution can proceed. Help obligation: Data Sculptor Help must explain SUITCASE: . in plain language: the saved Work Order uses the folder that contains that WKO as its Suitcase; the dot means “this folder”; ordinary Work Order file references are therefore portable and Suitcase-relative; and browser/host permission to the folder is granted separately. Help must not teach an absolute machine path as the normal replacement for . .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-009,Ordinary Work Order file references are Suitcase-relative,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Unless another numbered requirement explicitly governs a different reference mechanism, file references in an executable WASM-002 Work Order resolve relative to the declared Suitcase. A portable Work Order must not depend on an absolute machine-specific path to identify ordinary Suitcase files. Resolution must be deterministic in browser and later native hosts. Moving an intact Suitcase to another permitted filesystem location must not change the logical meaning of the Work Order solely because the parent machine path changed.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-009.1,WASM-002 SOURCE eligibility is exact and root-bounded,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"A WASM-002 SOURCE clause names exactly one physical regular file in the Suitcase root by exact filename only. It must not name an absolute path, drive or UNC path, subdirectory, path containing / or \ , traversal such as .. , URL/URI, or another external reference. Resolution uses the exact Unicode-scalar filename identity and reference-bounded rules frozen by F-15; no case-folding, normalization, trimming, or filesystem-equivalence search is permitted. The only eligible WASM-002 SOURCE kinds are: Analyst-owned CSV: a regular Suitcase-root file whose exact filename does not begin with the reserved exact prefix __DS__ and whose final extension is .csv under ASCII case-insensitive extension recognition. Thus .csv , .CSV , and mixed-case equivalents are candidate CSV extensions. This case-insensitivity applies only to extension recognition; the complete filename reference remains exact. If the physical file is crime.CSV , a differently cased full filename does not become an alternate reference to it. Governed converted source: a successfully published CVT whose exact canonical identity and class-specific publication/validity predicate satisfy W002-CONV-004, W002-STOR-023, and PB-STOR-008. A filename that merely resembles a CVT is not sufficient. No other governed semantic class is eligible as SOURCE in WASM-002, even when its physical serialization is CSV. In particular, COL , RID , MAP , CAT , INV , RCP , HLP , CER , SCR , RCV , and WKO artifacts cannot be reintroduced as SOURCE merely because their bytes or extension appear compatible. A recognized .csv extension establishes only candidate SOURCE form. It does not certify encoding or CSV structure; the normal strict UTF-8 and structural certification contracts still govern after source resolution. Conversely, CSV-like bytes stored under a non-CSV analyst-owned extension are not an eligible WASM-002 SOURCE.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-008; CP-009; CP-010,"T-ACCEPTED, BANKED; analyst-owned CSV filename candidate preflight only; full SOURCE eligibility remains partial; CP009 T-ACCEPTED, BANKED — pure exact-name root snapshot matching only; full requirement remains partial; CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open",346733a962192320e0d56271add15a47b6037b6b; dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8; b7c515faa9bd000369d7656e09437310261290ae,Evidence/CP-008/CP008_RED_Test_Output.txt; Evidence/CP-008/CP008_GREEN_Test_Output.txt; Evidence/CP-008/CP008_Full_Regression_Test_Output.txt; Evidence/CP-008/CP008_Post_Format_Test_Output.txt; Evidence/CP-008/CP008_Rustfmt_Check_Output.txt; Evidence/CP-008/CP008_WASM_Build_Output.txt; Evidence/CP-008/CP008_Hash_Inventory_Verification.txt; Evidence/CP-008/CP008_Precommit_Git_Review.txt; Evidence/CP-008/CP008_Final_Source_Review.txt; Evidence/CP-008/CP008_Whitespace_Exception_Review.txt; CP008_Git_Banking_Output.txt (separate post-commit evidence; archived outside repository); Evidence/CP-009/CP009_Baseline_Test_Output.txt; Evidence/CP-009/CP009_RED_Test_Output.txt; Evidence/CP-009/CP009_GREEN_Test_Output.txt; Evidence/CP-009/CP009_Full_Regression_Test_Output.txt; Evidence/CP-009/CP009_Rustfmt_Check_Output.txt; Evidence/CP-009/CP009_Git_Whitespace_Check.txt; Evidence/CP-009/CP009_Post_Format_Test_Output.txt; Evidence/CP-009/CP009_WASM_Build_Output.txt; Evidence/CP-009/CP009_Hash_Inventory.txt; Evidence/CP-009/CP009_Hash_Inventory_Verification.txt; Evidence/CP-009/CP009_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Final_Staging_Review.txt; CP009_Git_Banking_Output.txt (separately archived post-commit evidence); Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived),"CP008 Day066: public is_analyst_owned_csv_source_candidate(&str) -> bool recognizes the final .csv extension ASCII case-insensitively for exact Suitcase-root analyst-owned candidate names. It refuses empty stems, __DS__-reserved names, slash/backslash paths, colon-bearing references, and traversal-like double-dot forms; preserves full spelling, case and Unicode normalization distinctions. Five new tests and 23 prior tests passed, 28/28 after Rustfmt. WASM32-target library compilation passed; no standalone browser execution proven. 20/20 SHA-256 file inventory matched; staged Rust source/test whitespace check 0. Full staged whitespace check 2 due solely to two preserved archival trailing-space lines in the CP008 precommit TXT, documented with supplemental diagnostic. Human T approved; Git commit banked with 18 files and clean working tree. This is ONLY lexical analyst-owned CSV candidate form, NOT regular-file proof, exact physical filename resolution, governed CVT publication, CSV UTF-8 certification, full SOURCE eligibility, or requirement acceptance. Independent Claude implementation QA pending. CP009 Day066: match_analyst_csv_root_snapshot(&str, &[RootSnapshotEntry]) -> RootSnapshotMatch applies CP008 analyst CSV candidate preflight, then exact Rust string equality (case, Unicode scalar sequence and whitespace preserved), reports no match, reported nonregular entry, ambiguous duplicate exact entries, or single caller-reported regular file. Entry origin and kind are caller assertions, not independently verified. Eight new tests; post-format full native regression 36/36; wasm32-unknown-unknown library compilation exit 0; SHA-256 inventory verified 22/22; staged whitespace exit 0; T approved and git banked 15 files, clean working tree. This is NOT actual root scanning, filesystem entry proof, browser permission, CSV/UTF-8 certification, governed CVT SOURCE eligibility or end-to-end requirement acceptance; independent Claude QA pending. CP010 Day066 adds is_governed_cvt_source_filename_candidate(&str)->bool, requiring existing canonical immutable envelope validator, exact CVT class, and exact lowercase .csv serialization token. Four bounded tests pass and native full regression 40/40; wasm32-target library build PASS with Rust 1.97.1; format check PASS; primary 29/29 and supplementary 8/8 SHA-256 verification PASS; staged whitespace PASS with documented exact-file archival exceptions; T approval; git b7c515faa9bd000369d7656e09437310261290ae committed 28 files and clean working tree. No physical file checks, conversion execution, close/reopen, publication predicate, UTF-8/CSV certification, executable SOURCE authority or browser runtime proven. Independent Claude QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-010,WIP and WKO are distinct Work Order lifecycle states,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"WIP is the editable, non-executable Work Order state. WKO is the saved, validated, immutable Work Order artifact that may become a Run target. Validation establishes that a Work Order is structurally eligible to run; it does not guarantee that runtime conditions will succeed. Loading a WKO for inspection does not make it mutable. If its instruction text is changed, the editor must treat the edited text as a new WIP derived from the original WKO. The original WKO bytes and physical identity remain unchanged, and the derived WIP cannot Run until saved as a new WKO. F-08 Run distinction: the browser Run action invokes one selected saved immutable WKO that is eligible under the governed WKO-registry rules. No ordinary WASM-002 WKO contains a textual RUN line merely to execute itself. The DS-STEPS token RUN is reserved for future saved-Work-Order composition under W002-WKO-011 and is not repurposed as the browser execution trigger.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-013,WASM-002 executes one saved Work Order without Work Order chaining,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"For WASM-002, one saved immutable WKO is one top-level executable request. It must not invoke, include, chain, or execute another WKO. The governed RUN composition operation and equivalent nested-orchestration constructs are not executable in WASM-002. If a saved WKO contains composition syntax, validation must refuse before analytical execution begins. The canonical diagnostic and Help path must explain that Work Order composition is deferred rather than treating the syntax as arbitrary text, silently ignoring it, or partially executing surrounding instructions. This scope cut does not prohibit one Work Order from selecting and materializing multiple columns in the single Stage 2 operation defined by WASM-002.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012,Materialization COL alias assignment uses AS; standalone alias maintenance uses UPDATE ALIASES,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within the WASM-002 DS-STEPS materialization form, an analyst assigns or changes the alias of a selected materialized COL with the optional same-line clause AS ""alias"" under W002-STEPS-005. This syntax is part of the governed Work Order and is not a GUI gesture. A single KEEP block may therefore assign aliases to multiple selected columns in one governed materialization. Automatic source-header COL aliases and inherited rematerialization aliases are resolved first; explicit AS clauses then determine requested successor COL aliases before complete Store-MAP validation and publication. Revision BD freezes alias-only creation/replacement with UPDATE ALIASES and explicit historical Store-MAP selection with MAP ""<exact Store MAP filename>"" . Revision BE completes the bounded alias lifecycle with explicit CLEAR ... ALIAS and RESET ... ALIAS forms under W002-WKO-012.5 through W002-WKO-012.6. Empty-string AS """" is not the clearing syntax.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.1,Canonical standalone alias-maintenance Work Order uses UPDATE ALIASES,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"The canonical alias-only Store metadata forms are: SUITCASE: .
WORK ORDER AS ""Rename crime store""
SOURCE ""35100178.csv""
STORE AS ""Crime Statistics""
UPDATE ALIASES or, when the analyst intentionally selects one exact Store snapshot: SUITCASE: .
WORK ORDER AS ""Rename crime store""
MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""
STORE AS ""Crime Statistics""
UPDATE ALIASES UPDATE ALIASES is the explicit terminal commitment clause for an alias-only Work Order. The WKO must identify exactly one Store-state base using either SOURCE ""..."" for ordinary Store-aware current-state selection or MAP ""..."" for exact Store-MAP selection, never both. At least one supported alias mutation clause must occur after the Store-state selector and before UPDATE ALIASES . An alias-only Work Order must not contain KEEP , MATERIALIZE , INVENTORY , conversion, Store repair, Work Order registry repair, cataloging, deferred Work Order composition, or another operation's terminal clause. Alias maintenance changes governed human-facing metadata only.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.2,"STORE AS, RID AS, and COL ... AS are the canonical alias-replacement clauses",W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical mutation clauses are: STORE AS ""Crime Statistics""
RID AS ""Row Number""
COL ""Crime Rate"" AS ""Police-Reported Crime Rate"" STORE AS ""..."" replaces the selected Store snapshot's store_alias . RID AS ""..."" replaces its rid_alias . COL ""<reference>"" AS ""..."" replaces the alias of exactly one existing mapped COL. The COL reference resolves under W002-STOR-021: it may be the exact physical column_filename or one unique current COL alias from the selected Store MAP. Missing, ambiguous, non-COL, or conflicting resolution must refuse rather than guess. One Work Order may update the Store alias, RID alias, and multiple distinct COL aliases together, provided the complete successor state satisfies all existing alias uniqueness/shadowing rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.3,"MAP ""<filename>"" is the exact historical Store-MAP selector",W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"The canonical explicit Store-MAP selection clause is: MAP ""__DS__MAP__20260920T184512347Z__<uuid-v4>.csv"" The value is always the exact physical filename of one structurally valid immutable Store MAP. It is not a Store alias, WKO alias, timestamp shorthand, UUID-only selector, or latest expression. For MATERIALIZE, if present, the clause occurs immediately after SOURCE and before KEEP . It overrides automatic Store-MAP inheritance and binds the run to exactly the named Store snapshot. For alias-only maintenance, the Work Order uses either SOURCE ""..."" or MAP ""..."" as its Store-state selector, not both. For materialization, SOURCE ""..."" remains mandatory and an optional MAP ""..."" supplies the exact historical/current Store-state base. Validation must refuse an incompatible source/MAP pairing or a MAP that is not a valid Store-MAP profile. Health rule: explicit historical selection does not override the current Store-lineage health gate. The selected lineage must currently be VALID and every RID/COL binding referenced by the named MAP must currently be present and valid. Otherwise the operation refuses. This applies equally to MATERIALIZE and UPDATE ALIASES. F-05/P2-01 source-compatibility predicate: for materialization, an explicitly named MAP is compatible only when the mandatory Work Order SOURCE exactly equals the one common source_filename carried by that Store MAP. If the exact filenames differ, validation refuses before the F-04 existing-Store cardinality gate in W002-MAT-002.6. Equal row count never authorizes a different source to enter the selected Store lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.4,Alias-only execution publishes one complete successor Store MAP and no rewritten data artifacts,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"A successful UPDATE ALIASES operation begins from the selected complete Store MAP, applies only the requested alias replacements in memory, validates the complete resulting Store state, writes the successor MAP under governed SCR , closes and reopens it, validates it fully, and promotes it to a new immutable MAP last. That successful promotion is the alias-update commit point. The operation must preserve the selected Store's physical RID and COL filenames and bytes, source-column keys, row order, cardinality, and lineage except for the human-facing alias fields explicitly changed by the Work Order. It must not reread source data rows merely to change aliases, must not create RID/COL artifacts, and must not rewrite or delete the inherited MAP. The prior MAP remains visible historical state. If validation or MAP publication fails, no successor alias state becomes current. The failure is reported through the governed diagnostic/Help path and any incomplete candidate remains subject to the retained- SCR failure-evidence rules in W002-STOR-023.1; WASM-002 does not emit RCV. Revision BM E-02 integration: when the alias-only operation uses an explicitly named historical Store MAP, publication is permitted only if the Store lineage currently evaluates VALID and every RID/COL binding referenced by that named MAP is currently present and valid. An older MAP cannot be used to bypass current damage. P3-06 validation depth: because UPDATE ALIASES does not consume RID/COL analytical contents, its Store-health and binding checks use Tier 1 under W002-STOR-019.10. The operation must not scan every RID/COL record merely to change aliases. This does not weaken later operations that actually consume those artifacts; they must perform the applicable Tier 2 validation before relying on the contents.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-007,Standalone Store/RID/COL alias maintenance acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance must establish a Store with one RID and at least three materialized COLs, then execute an alias-only Work Order that changes the Store alias, RID alias, and at least two COL aliases in one UPDATE ALIASES operation. One COL must be targeted by its unique current alias and another by its exact physical COL filename. The fixture must prove that exactly one complete successor Store MAP becomes current; prior MAP, RID, and COL artifacts remain byte-for-byte unchanged; no source-data row read is required; no new RID/COL artifact is published; and the successor MAP contains exactly the requested aliases while preserving all physical bindings and logical source-column keys. Missing/ambiguous COL references and successor alias collisions must refuse without publishing a successor MAP. F-23 CLEAR/RESET alias fixtures: acceptance must separately exercise CLEAR STORE ALIAS , CLEAR RID ALIAS , CLEAR COL ""<reference>"" ALIAS , RESET STORE ALIAS , RESET RID ALIAS , and RESET COL ""<reference>"" ALIAS . Each CLEAR fixture must prove that the successor MAP stores the governed empty alias without renaming or rewriting the referenced artifact. Each RESET fixture must prove restoration of the exact deterministic default governed by W002-WKO-012.6 and W002-STOR-019.7, including the oversized-header operational fallback where applicable. The fixtures must prove that CLEAR and RESET require no source-data row read, publish exactly one complete successor Store MAP on success, leave the predecessor MAP/RID/COL bytes unchanged, and deterministically refuse duplicate mutation of the same alias field or a reset/default value that fails the complete successor alias validity/uniqueness/shadowing rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-008,Explicit historical Store-MAP selection acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance must create at least two valid Store MAP snapshots for one Store, then prove that a Work Order containing MAP ""<older exact Store MAP filename>"" binds to that exact older snapshot even though a newer valid MAP exists. An alias-only fixture must publish its successor from the explicitly named older base rather than from the newer automatic current state. A materialization fixture must retain mandatory SOURCE ""..."" while using the explicit MAP as its Store-state base. The tests must also prove refusal for a missing MAP, malformed MAP, WKO-MAP profile supplied as Store MAP, and source/MAP incompatibility. No implementation may substitute the newest MAP after an explicit MAP clause has validated. F-21 chronology acceptance: the fixture must use at least three successive valid MAP snapshots for one Store so that an explicitly selected older base and a distinct pre-run current MAP both exist. Merely selecting/validating the older MAP must leave current authority unchanged. A successful governed operation from that older base must then publish exactly one new successor whose requested state is derived from the named older base, whose publication UTC is later than the pre-run current chronology predecessor, and which becomes current under ordinary greatest-UTC selection. The selected historical MAP and the formerly current MAP must remain byte-for-byte unchanged. Acceptance must prove that later mappings/aliases present only in the formerly current MAP are not silently merged into the historical-base successor unless the Work Order explicitly recreates them. Receipt evidence must identify the exact operation base and exact published successor through the already-frozen operation-specific Receipt fields. No additional warning/permission gate or informational diagnostic is required merely because the analyst explicitly chose a historical base.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.5,CLEAR ... ALIAS deliberately removes a human-facing alias,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical clearing forms are: CLEAR STORE ALIAS
CLEAR RID ALIAS
CLEAR COL ""<reference>"" ALIAS CLEAR deliberately stores the empty string in the corresponding alias field of the successor Store MAP. It does not restore a default alias. An empty-string replacement such as STORE AS """" , RID AS """" , or COL ""..."" AS """" is not the canonical clearing form and must be rejected by the bounded WASM-002 grammar. For CLEAR COL , <reference> resolves against the selected pre-mutation Store MAP by exact physical column_filename or one unique current COL alias under W002-STOR-021. All COL references in one UPDATE ALIASES Work Order are resolved before any mutation is applied so clause order cannot change target identity. Missing, ambiguous, duplicate-target, or non-COL references must refuse. Clearing an alias never renames, rewrites, or deletes the underlying RID/COL artifact and never changes physical identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.6,RESET ... ALIAS restores the deterministic default alias,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical reset forms are: RESET STORE ALIAS
RESET RID ALIAS
RESET COL ""<reference>"" ALIAS RESET STORE ALIAS restores the Store MAP's common exact source_filename . RESET RID ALIAS restores the literal RID . RESET COL ""<reference>"" ALIAS restores that mapped COL's deterministic operational default defined by W002-STOR-019.7 from its exact recorded source_header and physical source ordinal: the exact header when it contains at most 1,024 Unicode scalar values, or the deterministic Column <LETTERS> fallback/disambiguation rule when the recorded header exceeds that boundary. RESET never substitutes the potentially oversized exact header into the alias field merely because that header remains authoritative source evidence. RESET is therefore distinct from CLEAR . The restored value must pass the same governed alias validity, uniqueness, and shadowing rules as any explicit alias. If the deterministic default is empty or conflicts in the complete successor Store MAP, RESET must refuse except for the narrow oversized-header fallback/disambiguation rule already frozen in W002-STOR-019.7; Data Sculptor must not otherwise invent a suffix, alternate spelling, or substitute. AS , CLEAR , and RESET mutations may coexist in one Work Order when they target distinct alias fields; duplicate mutation of the same alias field in one Work Order must refuse. A successful operation publishes exactly one complete successor Store MAP under the existing UPDATE ALIASES commit contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001,Canonical WASM-002 DS-STEPS materialization form,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 materialization Work Order form is: # Optional human comment
SUITCASE: .
WORK ORDER AS ""Prepare monthly crime data""
SOURCE ""crime.csv""
[MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""]

KEEP
  HEADER ""REF_DATE"" AS ""Year""      # reporting year
  HEADER ""GEO""
  COLUMN 7 AS ""Crime Rate""

MATERIALIZE SUITCASE: . is governed by W002-WKO-008. WORK ORDER AS ""..."" is mandatory for an executable/saved WASM-002 Work Order and declares the immutable human-facing WKO alias governed by W002-STEPS-001.1. SOURCE ""..."" names the exact Suitcase-root source file. MAP ""..."" is optional with cardinality 0..1. If present, it occurs immediately after SOURCE and before KEEP , names one exact physical governed Store MAP filename, and binds the run to that exact current or historical Store lineage subject to W002-STOR-019.3 and W002-WKO-012.3. If absent, the Store-aware exact-source routing rules apply. KEEP is the bare governed keyword and introduces one or more column selectors. KEEP: is not valid WASM-002 syntax. Each selector is either HEADER ""..."" or COLUMN n and may optionally end with AS ""..."" . MATERIALIZE is the explicit terminal commitment verb. Duplicate structural clauses refuse. An empty KEEP refuses. After MATERIALIZE , only blank lines or comments may follow; a trailing comment on the physical MATERIALIZE line is permitted because comments are removed from the semantic token stream. # comments are governed by W002-STEPS-001.2. No RID/row-index clause appears in the Work Order. If this materialization establishes a new Store, the engine automatically generates exactly one RID artifact under W002-RID-002 and W002-RID-008. If it extends an existing Store, the existing RID is reused subject to the Store health/cardinality rules. This requirement freezes the bounded keyword structure and selector forms shown above for BM integration. Other complete-language lexical features remain outside this bounded syntax freeze unless separately specified. F-08 common-grammar boundary: MATERIALIZE is one of the seven executable WASM-002 operation grammars governed by W002-WKO-007. Its optional MAP clause remains in the frozen position immediately after SOURCE and before KEEP . The terminal MATERIALIZE clause is DS-STEPS syntax; the browser's Run action is not written into the Work Order. F-20 bounded KEEP: the canonical KEEP block contains at least one and at most 16,384 selectors, and after resolution those selectors must identify at least one and at most 16,384 distinct source columns. This is the complete WASM-002 selection-width bound.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001.1,WORK ORDER AS declares the immutable human-facing Work Order alias,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"An executable or saved WASM-002 Work Order must contain exactly one top-level clause: WORK ORDER AS ""<alias>"" In canonical forms it appears after SUITCASE: . and before the operation-specific source/selector clauses. The decoded alias must be non-empty. The quoted alias may contain spaces and ordinary UTF-8 phrase text subject to the governed string-literal rules. The alias affects display and governed alias resolution only; it does not replace the WKO filename/UUID as physical execution identity. The alias is stored in the immutable WKO bytes and is published into the current WKO MAP when the WKO save transaction commits. Changing the alias therefore requires saving a new WKO under the frozen WKO lifecycle. No valid executable/saved WKO in WASM-002 is unaliased. P3-10 alias-content rule: “non-empty” means that, after decoding the quoted string literal, the alias must contain at least one non-whitespace character. An alias consisting only of whitespace refuses Work Order validation. Data Sculptor must not trim, collapse, normalize, or otherwise rewrite leading or trailing whitespace in an otherwise valid alias; the decoded alias text remains authoritative and is preserved exactly in the immutable WKO and governed WKO MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001.2,# introduces a DS-STEPS line comment outside double-quoted strings,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"Outside a double-quoted string, the first # on a line begins a comment that continues through the line's LF terminator. Whole-line comments and trailing comments are permitted. Comment text has no execution semantics and is ignored by the DS-STEPS parser after lexical recognition. A # inside a double-quoted string is ordinary string content and does not begin a comment; for example WORK ORDER AS ""Analysis #3"" and HEADER ""CATEGORY #"" preserve the hash character. WASM-002 defines no block-comment syntax. Comments are preserved byte-for-byte in the saved immutable WKO TXT. Editing, adding, or removing a comment changes the WKO bytes and therefore requires saving a new WKO artifact even though analytical semantics may remain unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-002,HEADER selects by exact decoded source-header value,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"HEADER ""name"" resolves against the exact decoded header values established for the certified source. Header equality is exact Unicode scalar-value sequence equality under PB-STOR-010: Data Sculptor performs no case folding, locale folding, Unicode normalization, trimming, or filesystem-style comparison. A selector that matches no source header must refuse. If the same exact decoded header sequence occurs in more than one source column, the header selector is ambiguous and must refuse rather than choose by position, discovery order, normalization, case-insensitive similarity, or another heuristic. An analyst can disambiguate duplicate exact header text with the 1-based COLUMN n selector. F-20 selector identity: HEADER always matches the authoritative exact decoded source header. It never matches an operational fallback name such as Column AA , a generated collision-disambiguation suffix, a COL alias, or a truncated form of the source header.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-003,COLUMN selects by 1-based source ordinal,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"COLUMN n identifies the source column by 1-based ordinal position. COLUMN 1 is the first source column. Zero, negative values, non-integers, and ordinals greater than the source width must refuse. Ordinal selection does not suppress source metadata: Data Sculptor must still resolve and record the selected column's actual decoded source header in the successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-004,HEADER and COLUMN selectors may be mixed but may not select one source column twice,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"One KEEP block may contain any supported mixture of HEADER and COLUMN selectors. Selector order expresses the analyst's requested selection order for the governed operation. After resolution, two or more selectors that identify the same physical source column constitute a duplicate selection and must refuse before materialization. Data Sculptor must not materialize the same source column twice merely because it was named once by header and once by ordinal.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-005,AS assigns the resulting materialized-column alias,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The optional clause AS ""alias"" belongs to the immediately preceding HEADER or COLUMN selector and expresses an intentional human-facing alias assignment in the governed Work Order. For a logical source column not present in the inherited MAP, omission of AS uses the exact source header as the default alias. For a logical source column already present in the inherited MAP, omission of AS preserves the inherited alias. An explicit AS overrides either default for the successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-006,The complete successor MAP must contain unique aliases,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"After inheritance, selector resolution, default-alias application, rematerialization continuity, and all explicit AS clauses are applied, every alias in the complete successor MAP must identify exactly one logical materialized column. If two different logical columns would have the same alias, including a collision with an inherited mapping, validation must refuse unless the Work Order has explicitly resolved the conflict through supported governed syntax. Data Sculptor must not invent suffixes such as Year_2 , use last-write-wins behavior, or silently shadow an existing alias. F-20 narrow generated-name exception: the prohibition on invented suffixes applies to ordinary source-header defaults and analyst-authored aliases. The only automatic suffixing permitted in WASM-002 is deterministic disambiguation of an oversized-header operational fallback under W002-STOR-019.7. That mechanism is not an alias-repair heuristic and must not be applied to an explicit AS value or to a short exact source-header default.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-007,MATERIALIZE commits the resolved KEEP set to the governed structural pass,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"MATERIALIZE is the explicit commitment verb for this WASM-002 DS-STEPS form. The KEEP selectors express which source columns belong in the operation; they do not themselves authorize data-row materialization. Before the bounded structural pass begins, the source, all selectors, actual source ordinals/headers, requested aliases, inherited alias state, and resulting alias uniqueness must be resolved and validated. Successful multi-column execution then follows the one-pass materialization contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-008,The Store MAP records resolved truth rather than selector spelling,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The successor Store MAP must record the fully resolved materialization result using the frozen eight-column schema store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename , regardless of whether the analyst selected a column with HEADER or COLUMN . For example, COLUMN 7 AS ""Crime Rate"" records the Store alias, RID filename/alias, common source filename, source ordinal 7 , the actual decoded header found at column 7, alias Crime Rate , and the newly generated physical COL filename. DS-STEPS expresses intent; the Store MAP persists the resolved durable mapping truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-009,DS-STEPS materialization syntax acceptance,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"Acceptance must cover: one column selected by exact header; one column selected by 1-based ordinal; mixed header/ordinal selectors in one KEEP block; multiple columns materialized in one governed structural pass; AS alias assignment; default header aliasing; inherited-alias preservation on rematerialization; explicit alias replacement on rematerialization; duplicate-header ambiguity refusal; invalid ordinal refusal; duplicate resolved-column refusal; and duplicate successor-alias refusal. Acceptance must also prove that the generated successor MAP records the same resolved source filename, source ordinal, actual source header, resulting alias, and physical COL identity whether a column was selected by header or by ordinal. For a new Store, both the single-column and multi-column materialization fixtures must contain no RID/row-index instruction yet must automatically publish exactly one RID artifact. For a later permitted same-Store materialization, the fixture must likewise contain no RID instruction and must reuse the original RID without publishing another. Damaged-lineage Help acceptance: fixtures must prove that exact source routing to an INVALID Store, and to a DEGRADED Store whose every mapped COL is broken, refuses ordinary materialization without silently treating the source as unseen. The canonical diagnostic/Help evidence must identify the blocked lineage/current MAP and preserve the frozen analyst-owned exits: external restoration under the original governed physical filename followed by governed validation; source rename to begin a distinct new Store lineage; or moving all lineage MAPs out of the active Suitcase to retire that lineage from routing. The all-COLs-broken fixture must warn that moving only the latest MAP is insufficient. No fixture may imply a new Data Sculptor recovery command, automatic RID regeneration, silent replacement of the damaged lineage, or historical byte identity based only on a restored filename. P3-06 validation-tier acceptance: acceptance must prove that a routine routing/status or alias-only path can use Tier 1 without an end-to-end scan of every RID/COL value, while an operation that consumes artifact contents performs Tier 2 before relying on them. Fixtures must include: a RID that passes Tier 1 but fails Tier 2 because its declared N /sequence is internally wrong beyond the Tier-1 boundary; a COL that passes Tier 1 but fails Tier 2 because its data-record count or CSV body is invalid beyond the Tier-1 boundary; and a REPAIR MAP fixture proving that the Tier-2 failure set determines exactly which COL bindings are removed. P3-07 routing acceptance: fixtures must prove that routing discovers a lineage from a structurally valid Store MAP regardless of whether later Store-health evaluation is VALID , DEGRADED , or INVALID . A separate fixture must present no routable lineage together with at least one structurally malformed Store-MAP-class artifact in the active Suitcase and prove that ordinary materialization refuses before publishing a new RID or first Store MAP, while Help identifies the malformed MAP artifact or artifacts. No fixture may treat an all-MAPs-damaged condition as permission for a silent replacement lineage. F-08 cross-operation grammar acceptance: fixtures must prove the common preamble, ASCII-case-insensitive keywords, exact quoted-value preservation, required SPACE/TAB token separation, unknown-line refusal, one-operation-per-WKO refusal, and separation between DS-STEPS terminal phrases and Receipt OPERATION tokens. At least one fixture for each of the seven executable operations must prove that its canonical structure validates while an otherwise similar WKO containing another operation's terminal clause refuses. Separate fixtures must prove that browser Run does not require a textual RUN clause and that parsed RUN composition syntax refuses as deferred before analytical execution. P2-04 restoration-language acceptance: Help, diagnostics, UI text, and acceptance evidence may say that a file restored under the exact governed physical filename passed the required validation tier and may therefore re-enter use. They must not state or imply that filename equality alone proves restoration of the historical original bytes. If stronger historical-byte identity is desired, Help may point to the separately governed explicit fingerprint/LCK direction rather than silently hashing ordinary Store artifacts. F-20 selector/name/width acceptance: fixtures must additionally prove that HEADER resolves only against exact decoded source-header text and never against an operational fallback/default alias; a KEEP selecting all 16,384 columns is valid; a source wider than 16,384 refuses before data-row materialization; and RESET of an oversized-header COL restores the deterministic operational fallback rather than the exact oversized header as alias text. F-03 Store-health and REPAIR MAP acceptance set Target required: REPAIR MAP without exactly one current Store MAP target refuses. Historical target: a structurally valid but non-current historical Store MAP refuses for repair. Wrong profile: a WKO MAP supplied as the repair target refuses. DEGRADED repair: one or more broken COL bindings are removed while every valid binding and the exact RID identity are preserved. All COLs broken: repair refuses, publishes no successor MAP, and the Store remains DEGRADED . Malformed newest MAP: current-state resolution falls back to the greatest earlier structurally valid MAP in the same lineage and reports the malformed artifact. Missing COL in current valid MAP: no fallback occurs; the current MAP remains current and the Store evaluates DEGRADED . Missing RID in current valid MAP: no fallback occurs; the current MAP remains current and the Store evaluates INVALID . Original RID externally restored: the Store is re-evaluated after governed validation without Data Sculptor creating or inferring a replacement RID. No silent fork: neither DEGRADED nor INVALID permits ordinary materialization to create a replacement Store for the same routed lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-003,Suitcase-relative Work Order portability acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must execute a saved WKO containing SUITCASE: . and ordinary Suitcase-relative file references, then move the intact fixture Suitcase to a different permitted parent path and execute the same saved WKO again. Resolution must identify the same logical Suitcase files without editing the WKO to insert the new absolute machine path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-004,WIP/WKO lifecycle acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance evidence must show that an editable WIP cannot Run; saving a valid WIP produces a distinct immutable WKO Run target; loading that WKO and changing instruction text creates a new non-runnable WIP; and the original WKO bytes, filename, identity, and provenance remain unchanged. F-02 alias-registry lifecycle acceptance: a first save for an unused alias must publish a successor WKO MAP containing exactly one CURRENT row for that alias. Saving a second valid WKO with the same exact alias must surface exactly Replace alias target and Cancel . The Cancel fixture must leave the predecessor WKO MAP authoritative and must not commit the pending WKO/WKO-MAP pair as a registry update. The Replace fixture must publish a successor WKO MAP in which the former owner is DEPRECATED , the new WKO is the sole CURRENT row for that alias, and any earlier deprecated history remains preserved. The former WKO bytes and filename and every predecessor WKO MAP must remain unchanged. Alias resolution against the successor registry must resolve to the new CURRENT row and never to a DEPRECATED row. A malformed fixture containing more than one CURRENT row for one exact alias must fail structural validation rather than choose by filename UTC, modified time, discovery order, or row order. P2-03 WKO-registry clock acceptance: using a deterministic injected clock seam, acceptance must prove that a successor WKO MAP publishes only when the observed transaction UTC is strictly greater than the current structurally valid WKO MAP UTC; equal-millisecond and backward/future-dated-predecessor cases refuse without committing the new WKO/registry state. The diagnostic must expose predecessor_map_filename , predecessor_utc , and observed_host_utc . A separate fixture must deliberately move the future-dated current WKO MAP out of the active Suitcase, rescan, and prove deterministic reselection of the remaining current structurally valid WKO MAP without Data Sculptor silently moving or deleting anything itself. Day 060 H-12: every equal/backward/future-predecessor chronology refusal in this acceptance set must emit DS-UTC-001 with exact map_profile: WKO , observed_host_utc , predecessor_map_filename , and predecessor_utc facts. F-23 save-transaction filesystem-fault fixture, reconciled by F-33: using a controlled create/write/close/rename/promotion failure at a deterministic point after a valid WIP has entered the governed save path, acceptance must prove that a failed WKO/WKO-MAP save is never represented as a committed alias-registry update. The pre-run current WKO MAP must remain authoritative; no malformed or unpromoted candidate may become current; and any rollback or retained SCR evidence must follow W002-STOR-018.3 and the shared non-Store publication/retained-evidence contract. No RCV artifact is emitted. F-02 registry-repair acceptance set Deadlock escape: with a repair-required current WKO MAP, a newly saved structurally valid repair-only WKO can Run by exact filename and successfully publish a repaired successor registry. No broad bypass: a newly saved unregistered WKO for any other operation remains ineligible to Run. Missing reference: repair removes a stale registry row but does not recreate the missing WKO, substitute a historical WKO, or promote an older WKO automatically. Discovered alias, no owner: one discovered valid WKO with an otherwise unowned alias becomes CURRENT . Discovered alias collision: a discovered WKO whose alias is already owned by a surviving CURRENT row becomes DEPRECATED . Several discovered WKOs, no owner: all become DEPRECATED ; no winner is inferred by UTC, filename, UUID, directory order, discovery order, or modified time. Mandatory alias: an unaliased WKO cannot be structurally valid. Line endings: otherwise-identical structurally valid WKO fixtures with LF and CRLF line endings are accepted; the lone-CR form refuses. Deterministic successor: repaired successor rows serialize in ascending UTF-8 byte order of exact wko_filename . Historical Run: a registered DEPRECATED WKO can Run by exact physical filename but not by alias. Receipt identity: a successful or refused registry-repair Receipt uses REPAIR_WORK_ORDER_REGISTRY as the operation token. Day 060 H-10 / BM-07 registry-repair Receipt-count acceptance Acceptance must include a successful repair-required-registry fixture in which the exact repair-only bootstrap WKO is initially visible and unregistered, runs by the bounded exact-filename bootstrap, and is then registered by the repair result. The committed successor WKO MAP must contain the repair WKO row. The successful Receipt must list that exact repair WKO under either REGISTERED_CURRENT_WKO_<INDEX>_FILENAME or REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME , according to the ordinary alias-ownership rule. The corresponding REGISTERED_*_COUNT must equal the number of newly registered rows in that status class, including the repair WKO when applicable. Pre-existing surviving CURRENT / DEPRECATED rows in the base registry must not inflate either registered count. A fixture containing both pre-existing surviving rows and newly registered rows must prove that the Receipt reports the repair change set while the successor MAP reports the complete resulting registry state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-005,"Store MAP inheritance, historical override, and immutable snapshot acceptance",W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must execute a saved Store-establishing Work Order containing multiple COL alias assignments when no routable Store lineage exists and no structurally malformed Store-MAP-class artifact is present , and prove that exactly one new immutable complete Store MAP is created while the GUI supplies no alias-edit gesture and target artifacts remain unchanged. A later Work Order with the same exact source and no explicit MAP must route to that Store's lineage and inherit its unique newest permitted MAP automatically. Another Work Order must explicitly select an older valid MAP even though newer MAPs for that Store exist and prove that Store/RID binding, alias resolution, and inheritance use exactly the named historical MAP instead. A fixture specifying more than one MAP must refuse. A fixture with two otherwise permitted current MAP candidates for the selected Store sharing the greatest UTC millisecond timestamp must refuse automatic inheritance rather than use UUID as chronology. A separate fixture must remove or corrupt every Store MAP in a prior lineage so that no structurally valid Store MAP remains while at least one malformed Store-MAP-class artifact remains visible in the active Suitcase. Re-running ordinary materialization must refuse before creating a new RID or first Store MAP, and Help must identify the malformed MAP artifact or artifacts. P2-03 Store chronology acceptance: injected-clock fixtures must prove later observed UTC success, equal-millisecond refusal, backward-UTC refusal, and a genuinely future-dated current Store MAP that remains current while blocking successor publication. Every refusal must leave the chronology predecessor unchanged and publish no successor Store MAP. A historical-base fixture must derive requested state from an older eligible MAP while proving that the strict-greater-than comparison uses the actual current Store MAP as chronology predecessor, not the historical base. A deliberate analyst-removal fixture must move the future-dated current MAP out of the active Suitcase and prove deterministic reselection of the remaining structurally valid history; restoring that MAP must make ordinary greatest-UTC authority rules applicable again. Day 060 H-12: every equal/backward/future-predecessor Store-MAP chronology refusal in this acceptance set must emit DS-UTC-001 with exact map_profile: STORE , observed_host_utc , predecessor_map_filename , and predecessor_utc facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-006,Work Order chaining refusal acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must submit a structurally saved WKO containing a RUN or other recognized Work Order-invocation construct and prove that WASM-002 refuses it during validation before Stage 1, Stage 2, conversion, inventory, or other governed execution begins. The diagnostic/Help output must identify composition as deferred functionality. A separate multi-column MATERIALIZE fixture must still succeed, proving that multiple selected columns inside one Work Order are not misclassified as Work Order chaining.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-001,One explicit Work Order command surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser front end shall use the Work Order editor as the single human command-entry surface for governed execution. It shall not expose a second interactive command prompt or point-and-click analytical path that can become an independent source of analytical intent. The editable draft may be syntax-highlighted, validated, and saved, but it is not itself executable authority. The browser Run action operates only on one loaded/selected saved immutable WKO that is eligible under the governed Work Order registry rules. Run is a browser action, not a line that ordinary WASM-002 Work Orders must contain. If a WKO contains the reserved DS-STEPS RUN composition token, WASM-002 refuses before executing any child or top-level analytical operation because saved-Work-Order chaining is deferred. The token remains reserved so later ordered composition can be added without repurposing existing syntax. F-24 fresh-application state: each new Data Sculptor browser application instance begins without a selected Suitcase and without a restored unsaved Work Order draft. Initial page load and full reload therefore return the command surface to the pre-Suitcase gate. A previously selected folder, loaded WKO, or dirty WIP must not be silently reconstructed from browser-private persistence.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-002,Front end presents and authorizes; shared Rust core decides,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser front end may authorize files, edit and validate Work Orders, invoke the shared engine, display governed state, render diagnostics, and present generated artifacts. It must not independently decide analytical truth, silently reinterpret a Work Order, or implement a competing semantic path. Where front-end presentation and shared-core semantics disagree, the shared governed semantics and frozen requirements are authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-003,Visible Suitcase and governed run context,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser surface shall make the currently validated Suitcase visible and shall expose the visible files in that folder. Source and requested-column context become governed execution state only when a saved Work Order resolves them; the UI must not imply that directory presence alone means a source has been selected, scanned, certified, or materialized.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-004,Certification gate is visible and blocking,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The front end shall visibly represent strict whole-file UTF-8 certification as a required stage before analytical materialization. A certification refusal must stop the current analytical Work Order, prevent later materialization stages from being presented as successful, and provide the canonical diagnostic / Help path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-005,One-pass multi-column materialization is represented truthfully,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"When a valid Work Order requests multiple source columns, the front end shall represent them as one governed multi-column materialization request through one bounded structural CSV pass, not as unrelated per-column scans when the frozen engine contract performs one pass. Requested columns must be validated before data-row materialization begins, consistent with the materialization requirements.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-006,Visible Suitcase Directory is the artifact orientation surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"After Suitcase validation, the browser shall present a human-readable directory view of the visible files in the selected Suitcase, including physical filename, read-only governed alias where applicable, file type, and size. Governed artifacts created by a run shall appear in that same visible inventory after refresh or update. The directory is an orientation and metadata surface over the real flat Suitcase. It is not a hidden browser cache, a second persistence system, or an analytical command surface. CAT integration: this existing directory remains the sole WASM-002 artifact-orientation surface. CAT and MAP artifacts are first-ranked under W002-CAT-UI-001 through W002-CAT-UI-008; no second catalog browser is introduced.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-007,All user-facing Help flows through the Help Engine,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"All Data Sculptor-controlled user-facing Help messages, warnings, refusals, explanations, validation guidance, safe-next-action messages, and governed success/status messages that participate in the Help/status/evidence system shall be produced through the Help Engine from governed facts or canonical diagnostic events. Individual UI controls must not maintain an independent competing stock of semantic Help text. Governed success/status events in this system use canonical INFO diagnostics. Ordinary static labels, headings, decorative copy, and presentation-only UI text are not diagnostics and need not be routed through the diagnostic registry merely because they are visible. Help voice may change wording and depth but must not change diagnostic identity, evidence, severity, refusal/continue behavior, provenance, or safe next action. Durable Help Reports derive from the same governed truth. F-17 fallback behavior: when a complete registered diagnostic lacks an authored help_messages.json entry, the UI must show the deterministic Generic Technical Help rendering from W002-HELP-002.9 for Casual, Office Speak, and Technical selections rather than a blank state, guessed prose, or UI-local explanation. When diagnostic assembly itself fails its required-fact contract, the UI presents DS-HLP-001 ; it must not display the incomplete intended diagnostic as if valid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-008,Legacy encoding conversion remains a separate operation,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"If UTF-8 certification fails and the bytes are eligible for the separately governed Windows-1252 compatibility/conversion path, the front end may explain or help draft that separate conversion Work Order. It must not silently reinterpret the failed analytical Work Order as Windows-1252 and continue materialization. P3-08 front-end disclosure: after a successful conversion, the visible result/Help path must identify the exact published CVT filename and explain that it is a new source identity for later Store routing. When that CVT is subsequently chosen for first materialization, the front end must not present the action as a refresh of an earlier conversion-derived Store merely because the analyst-owned input filename is the same; it must preserve the governed Help disclosure that each distinct CVT is a distinct source artifact and lineage input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-009,Front-end branding is presentation-only,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser front end shall use the canonical built-in Red5Sorcery/Data Sculptor branding and approved presentation tokens without changing analytical or diagnostic meaning. The current Red5Sorcery identity treatment, including the red “5”, remains the active WASM-002 design direction. Configurable Brand Manifest loading, validation, selection, and substitution are deferred to V1-BACKLOG / a future build whose number is not yet assigned.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-010,WASM-002 front end must not preview deferred analytical features as available controls,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 front end shall stop at the capabilities allocated to the WASM-002 build slice. It shall not present filtering, grouping, sorting, Quick Viz, PRETTY Tables, DS-VERIFY, or later filter-driven build/export workflows as executable WASM-002 controls unless their individual requirement SCOPE is deliberately changed and frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PLAT-001,WASM-002/V1 browser and modest-hardware acceptance baseline,W002-PLAT,W002-PLAT,WASM-002,UNDER REVIEW,—,"The canonical modest-hardware acceptance machine for the WASM-002 browser release and the browser path carried into V1 is the project's 11-inch Windows 11 laptop with an Intel N100 processor, 16 GB RAM, and a 1920×1200 native display. Each acceptance record must capture the exact tested Windows build, browser version, Windows display scaling, browser zoom, and materially relevant machine configuration. Those observed version and presentation settings are acceptance evidence; they do not become timeless minimum-version requirements unless separately frozen. V1 browser support is scoped to certified desktop Chromium hosts that expose the user-selected writable-directory and file-publication capabilities required by the visible Suitcase contract. Microsoft Edge is the primary certified browser. Google Chrome is the secondary certified browser. Another Chromium-derived browser may work, but Data Sculptor must not claim it as a certified V1 browser until that browser has passed the applicable acceptance suite. Firefox and Safari are not supported V1 browser hosts under this contract and their lack of the required filesystem capability must not block V1 release. Supported-host acceptance must exercise the real browser filesystem path: explicit user-selected Suitcase access, CER validation, governed Work Order save/Run behavior, and governed artifact publication. Data Sculptor must not substitute OPFS, IndexedDB, download-only publication, a browser extension, or another hidden/different persistence model merely to make an unsupported browser appear supported. Required filesystem capability is feature-detected before folder validation begins. If the host cannot expose the governed writable-directory contract, Data Sculptor must treat that state as a host-capability refusal , keep governed save/Run/analytical controls locked, and route the explanation through the canonical diagnostic/Help path. It must not claim that a particular user folder failed validation when no folder could actually be tested.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-011,"Keyboard-operable, small-screen browser shell",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The required WASM-002 front-end interactions shall remain operable from a keyboard and usable on the canonical modest-hardware/small-screen baseline defined by W002-PLAT-001. At the display scaling and browser zoom recorded for acceptance, every required control and governed surface needed to complete the supported workflow must remain reachable without changing those settings merely to reveal an otherwise inaccessible control. Responsive reflow and ordinary scrolling are permitted; this requirement does not demand that every panel be visible simultaneously. Visible labels must carry meaning without relying on color alone. Exact shortcut assignments are presentation details unless separately frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-012,"Reference prototype is evidence, not a shadow specification",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Day 043 HTML prototype embedded below is retained as concrete design evidence for the WASM-002 browser workbench. Its layout, simulated analytical execution, illustrative Work Order grammar, current aliases, demo shortcuts, artifact examples, and other unfrozen literals do not become normative merely because they appear in the prototype. If the embedded prototype conflicts with a numbered requirement, the numbered requirement governs and the prototype must be revised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-013,Dedicated persistent Help / Diagnostic Surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The primary WASM-002 workspace must reserve a dedicated Help / Diagnostic Surface with stable layout presence. When a governed diagnostic is active, the analyst must be able to view its explanation without losing sight of the Work Order and the execution/source context required to understand it. The persistent surface is a viewport into canonical diagnostic truth; it is not a second state authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-014,Governed analytical refusals are not modal- or toast-only interactions,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,An application-controlled modal dialog must not be the primary presentation of a governed analytical refusal when it would obscure the Work Order or execution context. A transient toast or timed notification must not be the sole carrier of governed diagnostic truth. Browser- or operating-system-controlled permission/security dialogs are outside this requirement because Data Sculptor does not control their presentation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-015,Idle Help state remains semantically quiet,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"When no canonical diagnostic is active, the Help / Diagnostic Surface should communicate only restrained readiness/idle state rather than becoming a general dashboard for unrelated metrics, checkpoints, or project status. Exact wording such as “No active diagnostic. Ready.” is presentation detail unless separately frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-016,Help surface exposes a direct saved-report action,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"From an active governed diagnostic, including a non-run diagnostic, or from one governed Run whose diagnostic history is available to the Help surface, the browser Help / Diagnostic Surface must provide an explicit action to generate the durable HTML Help Report. Each explicit report request publishes exactly one HLP under W002-HELP-003.2 and W002-HELP-009. The generated report must become a visible Suitcase artifact governed by the Help, PRETTY, persistence, and provenance requirements and must use the canonical built-in Data Sculptor presentation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-017,Writable Suitcase validation is the first interaction gate,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Before Data Sculptor enables Work Order saving, governed Run, or analytical processing, the analyst must choose one Suitcase folder and Data Sculptor must validate that folder by successfully creating, completely writing, and closing one governed HTML Suitcase Validation Certificate under W002-STOR-022 through W002-STOR-022.3. Permission state or directory enumeration alone is not sufficient to pass the gate. The successful certificate remains visibly in the Suitcase as durable evidence. Validation does not require deleting or renaming the certificate. Until the certificate write/close succeeds, the analytical workspace remains locked except for Help and Suitcase selection. Browser- or operating-system-controlled refusal of protected directories is outside Data Sculptor presentation control and must be explained through the Help Engine when the host can observe the refusal. F-24 opening/selection lifecycle: merely loading Data Sculptor does not create a CER. A CER is published only after an explicit Suitcase selection successfully passes the governed validation gate. Reselecting and successfully validating the same physical Suitcase is a new certification event and publishes one new CER; all earlier CERs remain untouched. Data Sculptor does not remember the directory handle between application instances, so a new load/reload requires explicit Suitcase selection again before the workspace can unlock.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-018,Suitcase Directory enumerates visible files before analytical work,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Immediately after Suitcase validation, Data Sculptor shall enumerate the visible files available through the authorized directory handle and show them in the Suitcase Directory. No source, header, column, certification, or materialization state shall be inferred merely from the existence of those files.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-019,Directory inventory and displayed aliases must not become point-and-click analytical intent,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Suitcase Directory may expose file inventory and read-only human-facing metadata such as aliases, but it shall not provide alias-edit controls, “Use as source,” column-pick, materialize, filter, or equivalent governed-action controls. Source files, requested columns, alias mutations, and analytical operations are stated in saved Work Orders and resolved by the governed engine.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-020,Saved Work Orders are the only Run targets,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Work Order editor may create a new draft or load a saved Work Order TXT artifact from the validated Suitcase. A loaded saved Work Order is an immutable Run target and may be inspected or run directly. If the analyst changes its instruction text, the editor must transition to a new draft derived from that saved Work Order; the draft is not runnable until it is saved as a new immutable Work Order with a new governed physical identity. The original saved Work Order remains unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-021,User chooses the Suitcase; Data Sculptor chooses generated filenames,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"For Work Orders, materialized columns, Help Reports, receipts, maps, and other Data Sculptor-generated artifacts, the analyst chooses or has already chosen the validated Suitcase folder. The browser shall not require the analyst to supply an output filename for those governed artifacts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-022,"Execution Output is read-only observation, never command input",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser shall provide a read-only Execution Output surface that reports which saved Work Order was run, how its source and governed aliases resolved, which execution stages occurred, what was refused, and which governed artifacts were created or assigned. For WASM-002 it does not display a nested Work Order invocation chain because Work Order composition is deferred. The surface shall not accept commands, analytical text, or cursor-driven execution input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-023,The browser has no separate Work Order Description field,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser must not expose a standalone editable Description field for a saved or draft Work Order. Human-facing Work Order naming is authored in DS-STEPS with the required WORK ORDER AS ""..."" clause inside the Work Order itself. The Saved Work Order chooser and Suitcase Directory may display governed WKO alias/lifecycle information from the current structurally valid WKO MAP . Where lifecycle information is shown, CURRENT and DEPRECATED are read-only governed registry state, and the exact physical WKO filename must remain available/visible so human meaning, lifecycle authority, and physical identity remain distinct. Alias resolution uses the sole CURRENT row for the exact alias; a DEPRECATED row is historical evidence rather than the alias target. If that current registry references a missing physical WKO, the MAP remains current and the registry is repair-required; the browser must not silently display an older WKO MAP as though it had become current merely because of the missing reference. A structurally malformed newer WKO MAP never becomes current and is reported through Help/evidence surfaces. Editing a loaded saved WKO—including changing its alias or comments—creates a derived draft that must be saved as a new immutable WKO before it can Run. If that save would supersede the existing CURRENT target for the same alias, the save flow follows the exact Replace alias target / Cancel decision in W002-STOR-018.3; the UI must not provide a separate direct registry-edit gesture.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-024,Suitcase Directory aliases are read-only views of governed MAP profiles,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Alias displays in the Suitcase Directory are observation-only. Store, RID, and materialized-COL aliases are read from eligible Store MAP state. Saved Work Order alias and lifecycle state are read from the current structurally valid WKO MAP. The browser may aggregate those governed sources into one human-facing directory view while keeping exact physical filenames available for inspection. For WKO rows, CURRENT / DEPRECATED is read-only governed lifecycle metadata. A CURRENT row identifies the registry target for that exact alias; a DEPRECATED row remains historical registry evidence and must not be presented as the current alias target. The GUI must not expose an input, inline editor, context action, or other non-Work-Order path that directly mutates governed aliases or WKO lifecycle status. Store/RID/COL alias mutation remains Work-Order-governed. WKO aliases are authored inside immutable WKO text with WORK ORDER AS and enter or change WKO alias-registry authority only through a successful governed save transaction under W002-STOR-018.3.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-025,The browser has exactly two governed built-in presentation themes,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser presentation contract exposes exactly two governed theme choices: Modern Dark and Modern Light . Custom presentation is deferred to V1-BACKLOG / a future build not yet numbered. A Terminal theme is not part of the WASM-002/V1 browser contract and must not be exposed as a governed theme choice. Theme selection is presentation-only. It must not change Work Order semantics, source resolution, diagnostic identity or facts, continue/refuse decisions, analytical values, Receipt truth, or other governed execution meaning. The selected browser theme does not control durable HLP or CER presentation in WASM-002. Those governed HTML artifacts use the canonical built-in Red5Sorcery/Data Sculptor presentation regardless of whether the live browser is using Modern Dark or Modern Light. F-24 session default and persistence: Modern Dark is the canonical theme at the start of every new browser application instance. The analyst may switch to Modern Light during that instance, but WASM-002 retains the choice only in volatile runtime state and does not persist it in browser-private storage. A new application instance therefore returns to Modern Dark.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-026,Flight Recorder is a read-only derived Receipt-history surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser may present a Flight Recorder surface that is derived exclusively from governed RCP Receipt artifacts currently visible in the authorized Suitcase. The surface is read-only and regenerable. It must not create or maintain a second execution-history database, mutable log, hidden cache, browser-private history, or alternate chronology authority. The Flight Recorder may sort, filter, group, or summarize Receipt-derived facts for human orientation, but those presentation operations must not alter Receipt bytes, invent missing events, or become authoritative over the underlying immutable Receipts. Where no canonical Receipt exists because Receipt publication failed, the surface must not reconstruct a substitute original Receipt from UI state, console text, or memory.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-001,Single-command-surface and saved-run-target acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The acceptance check must show one Work Order editor that can hold either a new draft or a loaded saved Work Order and no second independent prompt, command-entry cursor, point-and-click source selector, or point-and-click column selector. A governed browser Run must read exactly one loaded/selected saved immutable WKO artifact that is eligible under the current registry rules. An unsaved WIP must not Run. Editing the instruction text of a loaded saved WKO must transition the editor to a new draft state that cannot Run until saved as a new immutable WKO. A fixture containing the exact reserved semantic token RUN as a Work Order composition construct must refuse before any governed operation executes and must reach the deferred-composition Help path. A near-synonym such as CALL , EXEC , or INCLUDE must not be silently accepted as composition syntax.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-002,Certification-refusal gating acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a source fixture that fails strict UTF-8 certification, the browser must show certification failure, leave later analytical stages unaccepted, produce no materialized analytical outputs, preserve the source unchanged, and expose the canonical Help path. The retained event/Receipt evidence must agree on STAGE1_UTF8_OUTCOME: FAIL , exact UTF8_FIRST_INVALID_BYTE_OFFSET , and UTF8_STOP_REASON: INVALID_UTF8_SEQUENCE . The canonical diagnostic event must expose the same meaning through lower-case facts first_invalid_byte_offset , source_filename , and stop_reason .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-003,Multi-column path acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a valid UTF-8 source and a Work Order requesting at least two source columns, the browser must show successful certification followed by one governed structural materialization pass and then expose the resulting visible Suitcase artifacts required by the build contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-004,Diagnostic/Help parity acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"For at least one real WASM-002 refusal path, the live message, each supported Help voice, and the durable HTML Help report must resolve from the same canonical diagnostic event and preserve the governed facts, severity, provenance, refusal behavior, and safe next action.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-005,Visible-persistence and Suitcase-directory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"A completed governed browser run must be auditable from the visible Suitcase artifacts required by the build contract, and newly created governed artifacts must become visible through the Suitcase Directory. Acceptance evidence must show that Data Sculptor did not intentionally persist project or analytical state in browser-private storage as a substitute for those artifacts. F-24 session/CER lifecycle acceptance: acceptance must begin from a clean application instance and prove all of the following in one controlled sequence: no Suitcase is selected or silently recovered; Work Order saving and governed Run remain gated; the live browser defaults to Modern Dark and Technical Help; explicitly selecting and successfully validating a writable Suitcase publishes exactly one fresh CER and unlocks the workspace; after switching to Modern Light and a non-Technical Help voice and creating a dirty unsaved WIP, an ordinary reload/navigation path triggers the browser-supported unsaved-change warning where the host permits it; after proceeding with reload, the Suitcase handle, non-default theme, non-default Help voice, and dirty WIP are not restored from Data Sculptor-controlled browser-private persistence; reselecting and successfully validating the same Suitcase publishes a second distinct CER while the first CER remains present under its original governed filename and exact bytes; and no automatic CER-history ZIP, compaction, replacement, or deletion occurs. The acceptance record must inspect the relevant Data Sculptor-controlled browser persistence surfaces and show that no persisted project/session record was used to restore the Suitcase handle, WIP, theme, or Help voice. WASM-002 does not claim dirty-draft warning or recovery after browser crash, forced process termination, operating-system failure, or power loss.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-006,Scope-surface acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The frozen WASM-002 browser build must not expose executable controls for requirements whose current SCOPE remains V1-BACKLOG, POST-V1, OUT-WASM-002, or otherwise outside the frozen WASM-002 build slice.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-007,"Small-screen, keyboard, and certified-browser acceptance",W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"On the canonical Intel N100 / 16 GB Windows 11 laptop and its 1920×1200 display, acceptance must record the Windows build, display scaling, browser zoom, and exact browser version. In the primary certified Microsoft Edge host, the required browser controls, Work Order editor, governed-stage status, artifact/result surface, and diagnostic/Help surface must remain reachable and usable without requiring an IDE or developer tools, and the required interaction path must be completable by keyboard. Ordinary scrolling and responsive reflow are allowed; changing scaling or zoom merely to expose an otherwise unreachable required control is not. The same canonical machine must also exercise the supported-host Suitcase → CER → Work Order save/Run → governed publication path in the secondary certified Google Chrome host. Chrome must satisfy the same governed filesystem and semantic contract; browser-specific presentation differences do not permit different analytical meaning or a different persistence model.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-008,Persistent diagnostic co-presence acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,Triggering a real governed refusal must leave the Work Order and relevant execution/source context available while the diagnostic is visible in the dedicated Help surface. The refusal must not depend on an application-controlled modal dialog or transient toast as its sole presentation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-009,Idle-state discipline acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"With no active diagnostic, the dedicated Help surface must remain present but semantically quiet and must not aggregate unrelated project/dashboard state as a substitute for its diagnostic purpose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-010,Saved-report action acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"From a displayed real diagnostic event, including a governed non-run diagnostic, the user must be able to invoke the Help-report action and obtain the corresponding durable HTML Help Report as one visible governed artifact without manually copying diagnostic text or reconstructing the event. A governed Run fixture containing multiple diagnostic events must also permit one explicit Run-level Help Report request and must produce exactly one HLP for that request. The HLP must identify the included diagnostics in deterministic event order and must not create one HLP automatically for each diagnostic.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-011,Suitcase-first gate and supported-host capability acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"With no Suitcase validated, Work Order saving, governed Run, and analytical processing controls must be unavailable. Acceptance first proves supported-host capability under W002-PLAT-001. Microsoft Edge and Google Chrome acceptance must each expose the required user-selected writable-directory path; Data Sculptor must not satisfy this gate through OPFS, IndexedDB, download-only output, a browser extension, or another substitute persistence model. Acceptance must enumerate every governed final-artifact filename form and SCR staging form that WASM-002 can emit, derive the longest canonical filename length, and verify that the current contract yields 73 ASCII bytes/characters . The canonical __DS__CER__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html form is one of the forms at that maximum and is used for the actual create/write/close folder-validation test. After the analyst selects a writable test folder on a supported host, Data Sculptor must create one retained governed certificate whose filename matches that canonical CER form, completely write and close it, and expose it in the visible Suitcase Directory. The certificate must contain the semantic fields and limitation statements required by W002-STOR-022.2. Only after that certificate operation succeeds may the workspace unlock. A failure to create, completely write, or close the certificate after actual folder selection must leave the workspace locked and surface the canonical diagnostic/Help path. Separately, a deterministic missing-capability acceptance fixture must prove that a host lacking the required writable-directory contract refuses before folder validation, leaves the workspace locked, and does not mislabel an untested folder as unwritable. Acceptance must not depend on a hard-coded operating-system path-length number, deletion of the certificate, or a validation-only rename. If the emitted-name inventory changes so that another form exceeds the CER maximum, this acceptance gate must fail until the new maximum is explicitly exercised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-012,Directory-is-inventory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"After Suitcase validation, the visible directory must list a mixed fixture set including at least one CSV and one non-CSV file with their physical names, types, and sizes. The directory must expose no “Use as source,” column-pick, or materialize action that bypasses the Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-013,Generated Work Order identity and immutability acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,Saving a valid draft must create a new TXT artifact whose physical name matches the frozen Work Order filename contract and must not open a filename-entry Save As path. Editing the draft and saving again must create a different Work Order identity; the first saved TXT bytes and filename must remain unchanged.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-014,Work-Order-only source and column selection acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a Suitcase containing multiple candidate files and a CSV with multiple headers, the analyst must be able to request the source and materialized column solely through a saved Work Order. Acceptance must show that the browser performs no separate point-and-click source or column selection. F-26 SOURCE eligibility fixtures: the acceptance set must prove all of the following under W002-WKO-009.1: analyst-owned root files ending .csv , .CSV , and a mixed-case equivalent are recognized as CSV candidates; the complete physical filename reference remains exact and case-sensitive under F-15; an analyst-created __DS__notes.csv is refused as an analyst-owned SOURCE; a valid published CVT is accepted; a canonical-looking or renamed file that does not satisfy the governed CVT validity/publication contract is refused; governed non-CVT classes including COL are refused as SOURCE; a non-CSV analyst-owned extension is refused even if its bytes are CSV-like; and path, traversal, subdirectory, URL/URI, and external-file references are refused.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-015,Read-only Execution Output acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The execution surface must display the selected saved Work Order, source resolution, relevant stage/refusal facts, and resulting artifact identity while accepting no command input. Keyboard focus in the execution surface must not create a second execution path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-016,Store-MAP snapshot persistence and read-only directory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Creating or changing governed alias/Store metadata through a saved Work Order must create one new immutable complete Store MAP in the same flat Suitcase while preserving earlier MAPs and leaving target artifact bytes and physical filenames unchanged. After a governed run that creates a new Store MAP, refreshing/reopening the Suitcase may display Store, RID, and COL aliases from the exact Store lineage and Store MAP resolved for that specific governed operation. The directory must not infer a global “current Store,” guess from unrelated newest MAP timestamps, or independently choose or mutate Store/MAP authority for execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-017,"Store-aware MAP selection, historical override, and anti-rebinding acceptance",W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"A saved materializing Work Order that does not explicitly name a MAP must use exact SOURCE matching against the one common source_filename carried by each routable Store lineage's Store MAP. A routable Store lineage is one with at least one structurally valid Store MAP, regardless of later Store-health state. A fixture with exactly one routable Store lineage must route to that lineage and, when its health permits materialization, inherit the Store's unique newest permitted MAP and record both the MAP identity and bound rid_filename in execution evidence. A fixture with no routable Store lineage and no structurally malformed Store-MAP-class artifact present may establish a new Store. A fixture with more than one routable Store lineage for the same source must refuse automatic selection. An explicit-MAP fixture must prove that SOURCE must exactly equal the selected MAP's common source_filename . A different source must refuse before materialization even when source/RID row counts happen to match. A separate all-MAPs-damaged fixture must leave one or more structurally malformed Store-MAP-class artifacts visible while no routable lineage can be established. The UI/run path must refuse before new-Store/RID creation and expose Help that identifies the malformed MAP artifact or artifacts; it must not present the condition as an unseen source. Another fixture must prove that explicitly naming an older valid MAP overrides the newer default for that same Store. More than one explicitly named MAP must refuse. An equal-greatest-timestamp ambiguity within the selected Store lineage must refuse automatic selection. Once an inherited Store MAP has been selected for a run, creation of a newer MAP during execution must not silently rebind that in-progress run. P2-03 authority/clock acceptance: the UI/evidence path must distinguish the selected operation base MAP from the chronology predecessor used for successor UTC validation. When a future-dated current MAP blocks publication, the UI must not label that MAP corrupt merely because of its timestamp, must identify it as the blocking current authority, and must route to Help describing the clock correction/wait/deliberate-removal choices without performing any automatic fallback or filesystem move.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-018,Help-Engine-only messaging acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"For representative Suitcase validation, Work Order validation, source-resolution, and analytical refusal cases, user-facing guidance must be traceable to the Help Engine/canonical diagnostic path. Acceptance must show no competing ad hoc semantic refusal text generated independently by individual analytical controls.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-019,No standalone Work Order Description acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Acceptance must prove the architecture that WASM-002 permits: the browser exposes no standalone editable Work Order Description field; no separate mutable or hidden Work Order-description store exists; editing any governed WKO byte transitions a loaded saved WKO into a derived draft; the predecessor WKO TXT bytes, physical filename, and UUID remain unchanged; and the derived draft cannot Run until saved as a new WKO identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-020,Theme semantic-invariance acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The same saved Work Order and governed diagnostic fixture must be exercised under Modern Dark and Modern Light. Acceptance evidence must show identical Work Order resolution, diagnostic ID and structured facts, continue/refuse decision, and analytical result/provenance across both themes, with only governed live-browser presentation differences. The browser must expose no Custom or Terminal governed theme choice in WASM-002. Acceptance must also verify that switching between Modern Dark and Modern Light does not change the canonical built-in presentation of a generated HLP or CER.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-021,Flight Recorder read-only derivation acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Acceptance must populate the Suitcase with governed RCP artifacts for at least one successful Run and one refused Run whose Receipt publication succeeded, then reconstruct the Flight Recorder surface solely from those Receipts. The rendered history must preserve each Receipt's governed execution outcome and lineage while allowing only read-only presentation operations. A separate fixture must represent a Run for which Receipt publication failed under W002-RCP-010 and prove that the Flight Recorder does not invent, backfill, or reconstruct a canonical Receipt from transient execution state. User interaction with the Flight Recorder must not modify, delete, rename, rewrite, supersede, or create RCP artifacts and must not create hidden persistent history state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-001,Certification interprets nothing analytically,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The certification stage establishes source-encoding validity and evidence; it does not perform analytical materialization.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-002,Materialization assumes nothing about encoding,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,Materialization proceeds only under the governed UTF-8-certified-source invariant and does not guess or silently change source encoding.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-003,Conversion is a separate transformation,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"Windows-1252-to-UTF-8 conversion is an explicit user-authorized operation producing a new artifact, not a hidden fallback.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-004,The fast path preserves strictness,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"ASCII-first acceleration is an optimization of strict UTF-8 certification, not a relaxation of validity rules. Every non-ASCII sequence remains subject to strict validation and EOF remains authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-005,Help is first-class,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The shared engine emits governed diagnostic truth; the Help Engine owns governed explanation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-006,PRETTY is first-class,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The PRETTY Engine owns deterministic human-facing rendering.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-008,One shared semantic core,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The WASM-first implementation must remain suitable for later use by a standalone native CLI host without creating a permanent second semantic engine.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-011,Open source and commercial service are separate layers,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The open-source analytical product and Red5Sorcery's optional paid automation must remain architecturally distinguishable. A paid service may save work; it must not become a hidden prerequisite for executing or understanding the delivered analytical software.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-014,WASM-002 and V1 analytical execution are sequential,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"WASM-002 must execute governed analytical operations sequentially and predictably. The product must not expose worker-count, thread-count, task-parallelism, or similar tuning controls, and it must not silently introduce a parallel analytical execution mode whose ordering or resource use changes the governed semantics. Sequential execution does not require inefficient repeated scans. One bounded structural source pass may process multiple requested columns together, and implementation may use ordinary low-level/runtime mechanisms that do not create user-visible analytical concurrency or change deterministic operation order. Any future analytical parallelism requires a separate measured experiment and explicit PRD decision.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-014.1,WASM-002 has a single-writer Suitcase contract,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"WASM-002 assumes one user, one active Suitcase, and one Data Sculptor writing execution context at a time . Multiple read-only views may observe the same Suitcase, but concurrent governed writers—including a second browser tab or window attempting governed writes against the same Suitcase—are outside the supported WASM-002 contract. WASM-002 does not implement cross-tab locks, filesystem leases, lockfiles, hidden coordination state, or multi-writer merge/rebase semantics. This is an explicit product boundary, not an implicit guarantee that concurrent writers are safe. Before a governed transaction reaches its authoritative commit point, Data Sculptor must re-resolve and revalidate the governing state on which the transaction depends. If relevant governed state has changed since the transaction established its basis, publication must refuse rather than overwrite the newer authority, silently rebase itself, synthesize another chronology, or report success. Candidates already created remain subject to the existing rollback and attributable SCR recovery-evidence rules. Help must explain the boundary in ordinary terms: do not run two writing Data Sculptor contexts against the same Suitcase at the same time. If a pre-commit guard detects changed authority, the safe next action is to refresh or reopen the current governed state and rerun deliberately. Acceptance evidence must inject a relevant Store-MAP and WKO-MAP authority change after transaction preparation but before commit and prove that the newer authority remains authoritative and the stale transaction refuses.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)

CP016 CUSTODY CONTROL SEALING
DAY=068
CHECKPOINT=CP016
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
ORIGINAL_CUSTODY_ZIPS=31
ORIGINAL_ZIP_CONTENTS=REVERIFIED
CONTROLS=STAGING_MANIFEST_AND_TRANSFER_RECORD
CONTROL_ENTRY_FORMAT=ENTRY|SOURCE_SHA256|ZIP_SHA256|FILENAME
ENTRY|D19817B167DD622028BF443FBA3FB851F33A7EEDA2617FE3B970FCF1D7A3F7EF|E11A943BD8E9B2591D36226C6FA727A10D7B91CA027F563D16CC57D5DEFCC96B|CP016_Custody_ZIP_Staging_Record.txt
ENTRY|40B754D33DF4670F40EAC934C508DB95546D2F6F655866DC3064B0C0085688E9|1E15CC4C9B11EC7CD635903D11424CA0DE1C01BEFB9DE8E09EAE8A8CBCD61D1A|CP016_Custody_Transfer_Record.txt
FINAL_ZIP_COUNT=33
CONTROL_ZIPS=VERIFIED
GIT_BANKING=NOT_PERFORMED

CP016 ZIP EVIDENCE CUSTODY TRANSFER
DAY=068
CHECKPOINT=CP016
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
STAGING_MANIFEST_SHA256=D19817B167DD622028BF443FBA3FB851F33A7EEDA2617FE3B970FCF1D7A3F7EF
COPY_POLICY=PRESERVE ORIGINALS
ZIP_COUNT=31
COPIED_ZIP_CONTENTS=VERIFIED
DESTINATION=Evidence/CP-016/ZIP
STAGING_FOLDER=RETAINED
ORIGINAL_TXT_FILES=RETAINED
GIT_BANKING=NOT_PERFORMED

CP016 ZIP CUSTODY STAGING VERIFICATION
DAY=068
CHECKPOINT=CP016
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
SOURCE_INVENTORY_SHA256=CA6F2A5855258AB7887B308252FCE02449C78420C9BBF7133A7A5CAADBBD3A35
ZIP_POLICY=ONE ORIGINAL TXT PER ZIP
SOURCE_TXT_COUNT=31
STAGING_LOCATION=DOWNLOADS
GIT_STAGING=NOT_PERFORMED
ENTRY_FORMAT=ENTRY|SOURCE_SHA256|ZIP_SHA256|SOURCE_BYTES|ZIP_BYTES|SOURCE_FILENAME
ENTRY|323414623F563B967DC70DCECECDD4BD38EF76C364F178990A162AAD92CF0A48|E37674FF7C8847765A6D5388BC17701127AF90E01CCDCEB7F2CD6423F939E8FF|712|611|CP016_Formatting_Amendment_Installation_Record.txt
ENTRY|4C538648A51DC88BCC2169FB4EADF63E4477327883734E0DDD4C58B06865AE2C|EA25765622CB63C34CE855BD2DB34B978D6B3595E23DCBC4BB3CDC4E2E6761B0|785|560|CP016_Formatting_Candidate_Record.txt
ENTRY|E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855|040A1343C03FB50413254ACF2CD581ADB1BFB2813B65F8D2019972F73C8DC9AB|0|172|CP016_Formatting_Candidate_StdErr.txt
ENTRY|E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855|DCB3ADC4799B5C6A24A4140DC600277BA9BDEE75CC4CE2B3DF449A3D7182EC77|0|172|CP016_Formatting_Candidate_StdOut.txt
ENTRY|1D34568776D131887AA9C42B9E69B4CB285ED2975524E57B841EE53E2300112B|E6DDFBEAC95E0F9121A088383E954625B9F7511811C559D2340E14D394D27A3F|445|470|CP016_GREEN_Installation_Record.txt
ENTRY|DFD19A077DED5554AE281856DB8F4A6B0EF791AEF67755B3E2717DE78A23592F|632FDDBBB83F94E22ECE7DFB6E8560FDEF52475BEF26935763621D314262A657|337|403|CP016_GREEN_Reconciliation_Record.txt
ENTRY|0637BCA85B3CF01BDFC9851CF36805B95A5BCD5613449C85BC2D1D502CF291F9|BE0E3C43A396FB76C1B710538C80B921FBE57D68D3E41CE360E467177298E6D7|1088|656|CP016_GREEN_Refusal_Diagnostic.txt
ENTRY|07B4E2082D32EC4EA23FD7E5846847BD832DD6E493ED74229330C4824553F2F7|0DD93FB6EE3E11C85704451C0FD16372E26B8A5930B91070A9A2AFEB9AE21890|291|352|CP016_GREEN_StdErr.txt
ENTRY|6729744B5DC3448CC26017751AA242EBE75C0C2C7E79270E05D3B25AB3748849|1A5A203D329FF6513F696E67F2F530DBEC38E0D74CA3D0DE65CE9C88EA9D0E5F|618|465|CP016_GREEN_StdOut.txt
ENTRY|35EF75DFB76A633A5BF2DDFEBB05EC1B776D9BCF692F2DAC8213D41B0758F6AF|52350070D81D104204C2D9F4642B258241D14185F70523A727FB1BEB7A3D81AE|475|499|CP016_GREEN_Verification_Run_Record.txt
ENTRY|A583E05D0159B6645E48E58E29130636817EFACE6E306A69BAEDBF1D30B32980|164B5DA034286C3C4293E72416B1516A03D22B63CD97A8874BFEF2C66982DE1A|204|314|CP016_GREEN_Verification_StdErr.txt
ENTRY|03145F42E048239BF73864727EDEA97598F24F99011ABDCAFE6B184CFD7140D9|B338F1A9F4ED5AE1835A9B4E8378987B7FC3DEB0EE0D4F3F3EA5B732D3B35197|618|490|CP016_GREEN_Verification_StdOut.txt
ENTRY|701B955953A574F009C30C150B7257CD92D1D2E51FB30359D2D1449373DE4145|585DF9062D35330E881D7305905AE2C43F2187B1F7CD4053790634FC662B3171|499|533|CP016_PostAmendment_Regression_Run_Record.txt
ENTRY|977667140D7BF4709024221865E8409A87B67CE372F413AB82796C190F79F1B0|ABE662F6AAB8A693DB2D40AA85885D9CA4AA32AF32132C49B10961D136F1D2F8|2121|816|CP016_PostAmendment_Regression_StdErr.txt
ENTRY|BCC377042E9C613794EFA16CBD59EED6285F038434E1E4C15A77DAEDC95DEAD6|72354A7878E597F13C0103BEFAFEC5089862616A3AA9BA4F60DD5CEDE7C939AD|6429|1652|CP016_PostAmendment_Regression_StdOut.txt
ENTRY|66625015248D88508C85C6586214FC60548F3B9AFF5BC181649E522FEC58EB2C|006A2E9E4791F14CFF6D57D334F607603C7AE0C07CC9F72FB11A1F1C4A65C93F|470|446|CP016_PostFormat_Run_Record.txt
ENTRY|E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855|6565915A3413E1A6785BEE50D205D027BA98E79A9E6FD18C2BC518858F49907F|0|152|CP016_PostFormat_StdErr.txt
ENTRY|E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855|5FB72D6DE5164F7593527AAEEF2751874946591D734B6DE8812715C3328D9804|0|152|CP016_PostFormat_StdOut.txt
ENTRY|CA6F2A5855258AB7887B308252FCE02449C78420C9BBF7133A7A5CAADBBD3A35|0BEDB4175681E97BDCAAF2F65C55AB6CEE6F61913987A76061EE2188CF9DE3EC|3622|1728|CP016_PreCustody_Inventory.txt
ENTRY|1F3D312B4DC85938CBEB3A4C5337379A98D80B97AC8FFFFE20067783825EE469|5053B752EE768D64A932E2B540535529F5F1B00E5A0ABF52741214B7E2CEF9A8|460|462|CP016_RED_Run_Record.txt
ENTRY|80B1C35E94905F2522A541DF87DDB9DE30AD4F72F9B0A42A465C3B0E9BC04C52|31D20200D25BFE47DC4561CE41B08D7890EDB56298C391E160F2B6B028711C09|788|470|CP016_RED_StdErr.txt
ENTRY|E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855|FACE368AC745B67AE8C59C7CC2D5541CA82CA72C7AC386C856CC74F08C6CB398|0|138|CP016_RED_StdOut.txt
ENTRY|02AB46A2E4CEF2E9EB6C22BFEA172B17105E7FE3A7F6430AAED932FAACF951C2|75E189713797CC77004F671359E2A9721F3A2E1C13D42977445AD03966F0A84D|473|482|CP016_Regression_Run_Record.txt
ENTRY|AEAC8984FB12E18D7B98FE5780C53B6BB58519D90746C086A59F2AC8772C56CD|4FD62E24ED18EA9FEE9D562D01CE39FD9B4005BE4205304FCF217817A141D568|2121|788|CP016_Regression_StdErr.txt
ENTRY|01A1E149ABC83565B33308AFD7E052235EDA3E36746DB67BD38A7E3DD0070719|D5A1BD0DF6B73CAEB7AA72A63C042C9B43DEBA73E51E1239A2520195B823604C|6429|1627|CP016_Regression_StdOut.txt
ENTRY|078F1365A26ED51FCA265DED562DFB350C80504308C031C0EF3D955D99A47E85|527184E58503FDA888E52EF8A7C3771E2B1B7F9816E7D4B68148DFA1E8EF9293|591|473|CP016_Rustfmt_Run_Record.txt
ENTRY|E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855|FCB52C11A668F70E7B9247D2C41652C4B6293DB852A4E8D7E56B9427414865DC|0|146|CP016_Rustfmt_StdErr.txt
ENTRY|5EC045ECF10B589E7AF1A4952528AD6EBC077693EEA64277C237FF1BE93DE4D1|ED850E182AC529B1F630C04CDA31E95006A725E4FEF0E3CA54C3C4925DD830E8|6605|1483|CP016_Rustfmt_StdOut.txt
ENTRY|DB6864F6816883E927810A1854C9E34A67F7CBCEBB0D6D382F1A5A6CF9FC9764|BA61FB3400B606CE8D8D16418B0F5A4026B5FBBA39267DE46613A71CCBC8F7DB|809|621|CP016_WASM_Build_Run_Record.txt
ENTRY|6AD3D0DED9FDE31964BC0A536AE0E8B570152648166F13580EB46A1AA1425C36|3064A301187BA8536A2D359B824ABAFE6F66BAF8AF3A22D485700D4F868BA0A4|159|292|CP016_WASM_Build_StdErr.txt
ENTRY|E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855|DF0604F618250D1DAB37BFE740FDC7A7DB43AAA41DE1C1B2C187046A6B12B88C|0|152|CP016_WASM_Build_StdOut.txt
ZIP_COUNT=31
ALL_ZIP_CONTENT_HASHES=VERIFIED
ORIGINAL_TXT_FILES=UNCHANGED

CP016 FINAL CUSTODY ADDENDUM
DAY=068
CHECKPOINT=CP016
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
PREVIOUS_ZIP_COUNT=33
PREVIOUS_ZIP_HASHES=REVERIFIED
ADDITIONAL_ZIP_COUNT=2
ENTRY_FORMAT=ENTRY|SOURCE_SHA256|ZIP_SHA256|FILENAME
ENTRY|785C520C8C0B4AD2769E424F743C6AF55337B45B6BD8062F53E9B6A4B266EBB9|FD916AB08DB7DE515219F20206F60DCEBCE9B387E184DBC734AA3328E7839346|CP016_PreFormat_Frozen_Test.rs
ENTRY|4189A702B4B2E135AD1B6AD0C8F6751DDBEB467C1723414EA61EF36304D980A9|63763325CDE0DC5005D2FCCE2304B9EB78728E25508FF5447F1B9B0BBFEC369A|CP016_Custody_Control_Sealing_Record.txt
FINAL_ZIP_COUNT=35
FROZEN_RED_TEST_SOURCE=PRESERVED
SOURCE_AND_TEST=UNCHANGED
GIT_BANKING=NOT_PERFORMED

CP016 FINAL READ-ONLY PRECOMMIT REVIEW
DAY=068
CHECKPOINT=CP016
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
GIT_INDEX=EMPTY
TRACKED_CHANGE=src/lib.rs
NEW_TEST=tests/CP016_receipt_field_serialization.rs
GIT_DIFF_CHECK=PASS
SOURCE_SHA256=1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911
TEST_SHA256=BA13064905D2F8444F2E11A188FE7C4EBA30AE091947F19783E34FCE006A355C
ORIGINAL_TXT_COUNT=31
CUSTODY_ZIP_COUNT=36
TERMINAL_ZIP_SHA256=0921C073A4E36C4A7D1BD5E10DE6A6F842C96F411BD9EC43F554E79A8DCF116C
SOURCE_DIFF_SHA256=45003C621AD199DF2C746BB5A0E4E923A9B0BD44F94547B3798107E589492272
GIT_STAGING=NOT_PERFORMED
GIT_COMMIT=NOT_PERFORMED
STATUS_BEGIN
 M src/lib.rs
?? Evidence/CP-016/CP016_Formatting_Amendment_Installation_Record.txt
?? Evidence/CP-016/CP016_Formatting_Candidate_Record.txt
?? Evidence/CP-016/CP016_Formatting_Candidate_StdErr.txt
?? Evidence/CP-016/CP016_Formatting_Candidate_StdOut.txt
?? Evidence/CP-016/CP016_GREEN_Installation_Record.txt
?? Evidence/CP-016/CP016_GREEN_Reconciliation_Record.txt
?? Evidence/CP-016/CP016_GREEN_Refusal_Diagnostic.txt
?? Evidence/CP-016/CP016_GREEN_StdErr.txt
?? Evidence/CP-016/CP016_GREEN_StdOut.txt
?? Evidence/CP-016/CP016_GREEN_Verification_Run_Record.txt
?? Evidence/CP-016/CP016_GREEN_Verification_StdErr.txt
?? Evidence/CP-016/CP016_GREEN_Verification_StdOut.txt
?? Evidence/CP-016/CP016_PostAmendment_Regression_Run_Record.txt
?? Evidence/CP-016/CP016_PostAmendment_Regression_StdErr.txt
?? Evidence/CP-016/CP016_PostAmendment_Regression_StdOut.txt
?? Evidence/CP-016/CP016_PostFormat_Run_Record.txt
?? Evidence/CP-016/CP016_PostFormat_StdErr.txt
?? Evidence/CP-016/CP016_PostFormat_StdOut.txt
?? Evidence/CP-016/CP016_PreCustody_Inventory.txt
?? Evidence/CP-016/CP016_RED_Run_Record.txt
?? Evidence/CP-016/CP016_RED_StdErr.txt
?? Evidence/CP-016/CP016_RED_StdOut.txt
?? Evidence/CP-016/CP016_Regression_Run_Record.txt
?? Evidence/CP-016/CP016_Regression_StdErr.txt
?? Evidence/CP-016/CP016_Regression_StdOut.txt
?? Evidence/CP-016/CP016_Rustfmt_Run_Record.txt
?? Evidence/CP-016/CP016_Rustfmt_StdErr.txt
?? Evidence/CP-016/CP016_Rustfmt_StdOut.txt
?? Evidence/CP-016/CP016_WASM_Build_Run_Record.txt
?? Evidence/CP-016/CP016_WASM_Build_StdErr.txt
?? Evidence/CP-016/CP016_WASM_Build_StdOut.txt
?? Evidence/CP-016/ZIP/CP016_Custody_Control_Sealing_Record.txt.zip
?? Evidence/CP-016/ZIP/CP016_Custody_Transfer_Record.txt.zip
?? Evidence/CP-016/ZIP/CP016_Custody_ZIP_Staging_Record.txt.zip
?? Evidence/CP-016/ZIP/CP016_Final_Custody_Addendum_Record.txt.zip
?? Evidence/CP-016/ZIP/CP016_Formatting_Amendment_Installation_Record.txt.zip
?? Evidence/CP-016/ZIP/CP016_Formatting_Candidate_Record.txt.zip
?? Evidence/CP-016/ZIP/CP016_Formatting_Candidate_StdErr.txt.zip
?? Evidence/CP-016/ZIP/CP016_Formatting_Candidate_StdOut.txt.zip
?? Evidence/CP-016/ZIP/CP016_GREEN_Installation_Record.txt.zip
?? Evidence/CP-016/ZIP/CP016_GREEN_Reconciliation_Record.txt.zip
?? Evidence/CP-016/ZIP/CP016_GREEN_Refusal_Diagnostic.txt.zip
?? Evidence/CP-016/ZIP/CP016_GREEN_StdErr.txt.zip
?? Evidence/CP-016/ZIP/CP016_GREEN_StdOut.txt.zip
?? Evidence/CP-016/ZIP/CP016_GREEN_Verification_Run_Record.txt.zip
?? Evidence/CP-016/ZIP/CP016_GREEN_Verification_StdErr.txt.zip
?? Evidence/CP-016/ZIP/CP016_GREEN_Verification_StdOut.txt.zip
?? Evidence/CP-016/ZIP/CP016_PostAmendment_Regression_Run_Record.txt.zip
?? Evidence/CP-016/ZIP/CP016_PostAmendment_Regression_StdErr.txt.zip
?? Evidence/CP-016/ZIP/CP016_PostAmendment_Regression_StdOut.txt.zip
?? Evidence/CP-016/ZIP/CP016_PostFormat_Run_Record.txt.zip
?? Evidence/CP-016/ZIP/CP016_PostFormat_StdErr.txt.zip
?? Evidence/CP-016/ZIP/CP016_PostFormat_StdOut.txt.zip
?? Evidence/CP-016/ZIP/CP016_PreCustody_Inventory.txt.zip
?? Evidence/CP-016/ZIP/CP016_PreFormat_Frozen_Test.rs.zip
?? Evidence/CP-016/ZIP/CP016_RED_Run_Record.txt.zip
?? Evidence/CP-016/ZIP/CP016_RED_StdErr.txt.zip
?? Evidence/CP-016/ZIP/CP016_RED_StdOut.txt.zip
?? Evidence/CP-016/ZIP/CP016_Regression_Run_Record.txt.zip
?? Evidence/CP-016/ZIP/CP016_Regression_StdErr.txt.zip
?? Evidence/CP-016/ZIP/CP016_Regression_StdOut.txt.zip
?? Evidence/CP-016/ZIP/CP016_Rustfmt_Run_Record.txt.zip
?? Evidence/CP-016/ZIP/CP016_Rustfmt_StdErr.txt.zip
?? Evidence/CP-016/ZIP/CP016_Rustfmt_StdOut.txt.zip
?? Evidence/CP-016/ZIP/CP016_WASM_Build_Run_Record.txt.zip
?? Evidence/CP-016/ZIP/CP016_WASM_Build_StdErr.txt.zip
?? Evidence/CP-016/ZIP/CP016_WASM_Build_StdOut.txt.zip
?? tests/CP016_receipt_field_serialization.rs
STATUS_END

diff --git a/src/lib.rs b/src/lib.rs
index 8df0b4a..39d0a67 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -419,3 +419,55 @@ pub fn is_matching_scr_rcp_filename_candidate_pair(scr_filename: &str, rcp_filen
         Some(expected) if expected == rcp_filename
     )
 }
+
+/// One typed canonical Receipt field value, before whole-Receipt assembly.
+///
+/// This is an isolated formatting choice, not a claim that a field belongs to
+/// a frozen operation grammar or has been assigned a permitted vocabulary.
+#[derive(Debug, Clone, Copy, PartialEq, Eq)]
+pub enum ReceiptFieldValue<'a> {
+    MachineToken(&'a str),
+    NonNegativeInteger(u64),
+    QuotedText(&'a str),
+}
+
+/// Serializes exactly one canonical Receipt `KEY: VALUE` line with one LF.
+///
+/// Pure, deterministic formatting only: does not validate whole-Receipt
+/// ordering or semantics, access the filesystem, or authorize publication.
+/// An invalid identifier or embedded CR/LF in quoted text is refused.
+pub fn serialize_canonical_receipt_field_line(
+    key: &str,
+    value: ReceiptFieldValue<'_>,
+) -> Option<String> {
+    if !is_receipt_field_identifier(key) {
+        return None;
+    }
+
+    let encoded_value = match value {
+        ReceiptFieldValue::MachineToken(token) => {
+            if !is_receipt_field_identifier(token) {
+                return None;
+            }
+            token.to_owned()
+        }
+        ReceiptFieldValue::NonNegativeInteger(value) => value.to_string(),
+        ReceiptFieldValue::QuotedText(text) => {
+            if text.contains('\r') || text.contains('\n') {
+                return None;
+            }
+            format!("\"{}\"", text.replace('"', "\"\""))
+        }
+    };
+
+    Some(format!("{key}: {encoded_value}\n"))
+}
+
+/// Lexical form shared by field keys and machine-token values in this slice.
+/// Starts with uppercase ASCII A-Z; remaining bytes are A-Z, 0-9, or '_'.
+/// This is not an operation-specific closed-vocabulary membership check.
+fn is_receipt_field_identifier(value: &str) -> bool {
+    let mut bytes = value.bytes();
+    matches!(bytes.next(), Some(b'A'..=b'Z'))
+        && bytes.all(|byte| byte.is_ascii_uppercase() || byte.is_ascii_digit() || byte == b'_')
+}

// CP016 RED tests - Day 068 (2026-10-15)
// Proposed T-approval gate: deterministic serialization of ONE canonical Receipt field line.
// Frozen anchor: W002-RCP-005 (bounded PARTIAL portion only).
// No full Receipt schema, key ordering, operation vocabulary, filesystem I/O,
// WKO authority, staged publication, or claim that a durable Receipt exists.
// Preserve this original test file's SHA-256 after T approves the contract.

use data_sculptor_core::{serialize_canonical_receipt_field_line, ReceiptFieldValue};

#[test]
fn machine_tokens_have_exact_colon_space_and_single_lf() {
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "RESULT",
            ReceiptFieldValue::MachineToken("SUCCESS")
        ),
        Some("RESULT: SUCCESS\n".to_owned())
    );
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "ABSENCE",
            ReceiptFieldValue::MachineToken("NOT_AVAILABLE")
        ),
        Some("ABSENCE: NOT_AVAILABLE\n".to_owned())
    );
}

#[test]
fn non_negative_integers_use_ungrouped_ascii_decimal() {
    for (value, expected) in [
        (0_u64, "COUNT: 0\n"),
        (16, "COUNT: 16\n"),
        (1234567, "COUNT: 1234567\n"),
        (u64::MAX, "COUNT: 18446744073709551615\n"),
    ] {
        assert_eq!(
            serialize_canonical_receipt_field_line(
                "COUNT",
                ReceiptFieldValue::NonNegativeInteger(value)
            ),
            Some(expected.to_owned())
        );
    }
}

#[test]
fn filenames_and_utf8_free_text_are_double_quoted() {
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "WORK_ORDER_FILENAME",
            ReceiptFieldValue::QuotedText("__DS__WKO__20261015T123456789Z__550e8400-e29b-41d4-a716-446655440000.txt")
        ),
        Some("WORK_ORDER_FILENAME: \"__DS__WKO__20261015T123456789Z__550e8400-e29b-41d4-a716-446655440000.txt\"\n".to_owned())
    );
    assert_eq!(
        serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText("café 雪")),
        Some("DETAIL: \"café 雪\"\n".to_owned())
    );
}

#[test]
fn doubles_internal_quotes_without_backslash_escaping() {
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "DETAIL",
            ReceiptFieldValue::QuotedText("He said \"go\"")
        ),
        Some("DETAIL: \"He said \"\"go\"\"\"\n".to_owned())
    );
}

#[test]
fn refuses_cr_or_lf_inside_any_single_field_value() {
    for text in ["before\nafter", "before\rafter", "before\r\nafter"] {
        assert_eq!(
            serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText(text)),
            None
        );
    }
    for token in ["SUCCESS\n", "SUCCESS\r", "SUCCESS\r\n"] {
        assert_eq!(
            serialize_canonical_receipt_field_line(
                "RESULT",
                ReceiptFieldValue::MachineToken(token)
            ),
            None
        );
    }
}

#[test]
fn refuses_non_uppercase_ascii_field_keys() {
    for key in [
        "",
        "result",
        " Result",
        "RESULT ",
        "RESULT: X",
        "KEY=VALUE",
        "RÉSULT",
        "1RESULT",
        "RESULT\tOTHER",
        "RESULT\nOTHER",
    ] {
        assert_eq!(
            serialize_canonical_receipt_field_line(key, ReceiptFieldValue::MachineToken("SUCCESS")),
            None,
            "invalid key must refuse: {key:?}"
        );
    }
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "PUBLISHED_COL_001_FILENAME",
            ReceiptFieldValue::QuotedText("example.csv")
        ),
        Some("PUBLISHED_COL_001_FILENAME: \"example.csv\"\n".to_owned())
    );
}

#[test]
fn machine_token_spelling_must_be_lexically_canonical() {
    for token in [
        "",
        "success",
        "Success",
        " SUCCESS",
        "SUCCESS ",
        "NOT-AVAILABLE",
        "Café",
        "1SUCCESS",
        "SUCCESS\t",
    ] {
        assert_eq!(
            serialize_canonical_receipt_field_line(
                "RESULT",
                ReceiptFieldValue::MachineToken(token)
            ),
            None,
            "invalid token must refuse: {token:?}"
        );
    }
}

#[test]
fn text_is_preserved_without_trimming_and_document_bytes_are_deterministic() {
    let lines = [
        serialize_canonical_receipt_field_line(
            "RESULT",
            ReceiptFieldValue::MachineToken("SUCCESS"),
        )
        .unwrap(),
        serialize_canonical_receipt_field_line("COUNT", ReceiptFieldValue::NonNegativeInteger(0))
            .unwrap(),
        serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText(" a  b "))
            .unwrap(),
        serialize_canonical_receipt_field_line("EMPTY", ReceiptFieldValue::QuotedText("")).unwrap(),
    ];
    let output = lines.concat();
    assert_eq!(
        output.as_bytes(),
        b"RESULT: SUCCESS\nCOUNT: 0\nDETAIL: \" a  b \"\nEMPTY: \"\"\n"
    );
    assert!(output.ends_with('\n'));
    assert!(!output.ends_with("\n\n"));
    assert!(!output.contains("\r"));
    assert!(!output.contains("\n\n"));
    assert!(!output.as_bytes().starts_with(&[0xef, 0xbb, 0xbf]));
}

// CP016 RED tests - Day 068 (2026-10-15)
// Proposed T-approval gate: deterministic serialization of ONE canonical Receipt field line.
// Frozen anchor: W002-RCP-005 (bounded PARTIAL portion only).
// No full Receipt schema, key ordering, operation vocabulary, filesystem I/O,
// WKO authority, staged publication, or claim that a durable Receipt exists.
// Preserve this original test file's SHA-256 after T approves the contract.

use data_sculptor_core::{ReceiptFieldValue, serialize_canonical_receipt_field_line};

#[test]
fn machine_tokens_have_exact_colon_space_and_single_lf() {
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "RESULT",
            ReceiptFieldValue::MachineToken("SUCCESS")
        ),
        Some("RESULT: SUCCESS\n".to_owned())
    );
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "ABSENCE",
            ReceiptFieldValue::MachineToken("NOT_AVAILABLE")
        ),
        Some("ABSENCE: NOT_AVAILABLE\n".to_owned())
    );
}

#[test]
fn non_negative_integers_use_ungrouped_ascii_decimal() {
    for (value, expected) in [
        (0_u64, "COUNT: 0\n"),
        (16, "COUNT: 16\n"),
        (1234567, "COUNT: 1234567\n"),
        (u64::MAX, "COUNT: 18446744073709551615\n"),
    ] {
        assert_eq!(
            serialize_canonical_receipt_field_line(
                "COUNT",
                ReceiptFieldValue::NonNegativeInteger(value)
            ),
            Some(expected.to_owned())
        );
    }
}

#[test]
fn filenames_and_utf8_free_text_are_double_quoted() {
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "WORK_ORDER_FILENAME",
            ReceiptFieldValue::QuotedText("__DS__WKO__20261015T123456789Z__550e8400-e29b-41d4-a716-446655440000.txt")
        ),
        Some("WORK_ORDER_FILENAME: \"__DS__WKO__20261015T123456789Z__550e8400-e29b-41d4-a716-446655440000.txt\"\n".to_owned())
    );
    assert_eq!(
        serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText("café 雪")),
        Some("DETAIL: \"café 雪\"\n".to_owned())
    );
}

#[test]
fn doubles_internal_quotes_without_backslash_escaping() {
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "DETAIL",
            ReceiptFieldValue::QuotedText("He said \"go\"")
        ),
        Some("DETAIL: \"He said \"\"go\"\"\"\n".to_owned())
    );
}

#[test]
fn refuses_cr_or_lf_inside_any_single_field_value() {
    for text in ["before\nafter", "before\rafter", "before\r\nafter"] {
        assert_eq!(
            serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText(text)),
            None
        );
    }
    for token in ["SUCCESS\n", "SUCCESS\r", "SUCCESS\r\n"] {
        assert_eq!(
            serialize_canonical_receipt_field_line(
                "RESULT",
                ReceiptFieldValue::MachineToken(token)
            ),
            None
        );
    }
}

#[test]
fn refuses_non_uppercase_ascii_field_keys() {
    for key in [
        "",
        "result",
        " Result",
        "RESULT ",
        "RESULT: X",
        "KEY=VALUE",
        "RÉSULT",
        "1RESULT",
        "RESULT\tOTHER",
        "RESULT\nOTHER",
    ] {
        assert_eq!(
            serialize_canonical_receipt_field_line(key, ReceiptFieldValue::MachineToken("SUCCESS")),
            None,
            "invalid key must refuse: {key:?}"
        );
    }
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "PUBLISHED_COL_001_FILENAME",
            ReceiptFieldValue::QuotedText("example.csv")
        ),
        Some("PUBLISHED_COL_001_FILENAME: \"example.csv\"\n".to_owned())
    );
}

#[test]
fn machine_token_spelling_must_be_lexically_canonical() {
    for token in [
        "",
        "success",
        "Success",
        " SUCCESS",
        "SUCCESS ",
        "NOT-AVAILABLE",
        "Café",
        "1SUCCESS",
        "SUCCESS\t",
    ] {
        assert_eq!(
            serialize_canonical_receipt_field_line(
                "RESULT",
                ReceiptFieldValue::MachineToken(token)
            ),
            None,
            "invalid token must refuse: {token:?}"
        );
    }
}

#[test]
fn text_is_preserved_without_trimming_and_document_bytes_are_deterministic() {
    let lines = [
        serialize_canonical_receipt_field_line(
            "RESULT",
            ReceiptFieldValue::MachineToken("SUCCESS"),
        )
        .unwrap(),
        serialize_canonical_receipt_field_line("COUNT", ReceiptFieldValue::NonNegativeInteger(0))
            .unwrap(),
        serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText(" a  b "))
            .unwrap(),
        serialize_canonical_receipt_field_line("EMPTY", ReceiptFieldValue::QuotedText("")).unwrap(),
    ];
    let output = lines.concat();
    assert_eq!(
        output.as_bytes(),
        b"RESULT: SUCCESS\nCOUNT: 0\nDETAIL: \" a  b \"\nEMPTY: \"\"\n"
    );
    assert!(output.ends_with('\n'));
    assert!(!output.ends_with("\n\n"));
    assert!(!output.contains("\r"));
    assert!(!output.contains("\n\n"));
    assert!(!output.as_bytes().starts_with(&[0xef, 0xbb, 0xbf]));
}

CP016 FORMATTING AMENDMENT INSTALLATION
DAY=068
CHECKPOINT=CP016
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
ORIGINAL_TEST_SHA256=785C520C8C0B4AD2769E424F743C6AF55337B45B6BD8062F53E9B6A4B266EBB9
PRESERVED_BACKUP_SHA256=785C520C8C0B4AD2769E424F743C6AF55337B45B6BD8062F53E9B6A4B266EBB9
FIRST_FORMATTED_CANDIDATE_SHA256=ACF58CE5696618E7B50E7EE80AB8353BE7DE65510F5CE91317CFACD3C773EB7F
INSTALLED_REVISED_TEST_SHA256=BA13064905D2F8444F2E11A188FE7C4EBA30AE091947F19783E34FCE006A355C
SOURCE_SHA256=1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911
REV2_CHANGE=IMPORT_ORDER_ONLY
FORMATTING_DIFF_REVIEW=COMPLETE
INSTALLATION=PASS
POST_AMENDMENT_RUSTFMT=NOT_RUN
POST_AMENDMENT_REGRESSION=NOT_RUN

CP016 FORMATTING-ONLY CANDIDATE RECORD
DAY=068
CHECKPOINT=CP016
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
RUSTFMT_EXIT_CODE=0
ORIGINAL_TEST_SHA256=785C520C8C0B4AD2769E424F743C6AF55337B45B6BD8062F53E9B6A4B266EBB9
PRESERVED_BACKUP_SHA256=785C520C8C0B4AD2769E424F743C6AF55337B45B6BD8062F53E9B6A4B266EBB9
FORMATTED_CANDIDATE_SHA256=ACF58CE5696618E7B50E7EE80AB8353BE7DE65510F5CE91317CFACD3C773EB7F
REPOSITORY_TEST_SHA256_AFTER=785C520C8C0B4AD2769E424F743C6AF55337B45B6BD8062F53E9B6A4B266EBB9
SOURCE_SHA256_AFTER=1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911
STDOUT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
STDERR_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
FORMATTING_AMENDMENT=AWAITING_DIFF_REVIEW

CP016 GREEN INSTALLATION RECORD
DAY=068
CHECKPOINT=CP016
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
ORIGINAL_SOURCE_SHA256=538B918B634C5BFB04EFBB2DFE37257515C13094C09B4555820331C2987F9EE7
FROZEN_TEST_SHA256=785C520C8C0B4AD2769E424F743C6AF55337B45B6BD8062F53E9B6A4B266EBB9
INSTALLED_SOURCE_SHA256=1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911
ORIGINAL_BACKUP_VERIFIED=TRUE
INSTALLATION=PASS
GREEN_TEST_GATE=NOT_RUN

CP016 GREEN PREFLIGHT RECONCILIATION
DAY=068
FIRST_REFUSAL=EXPECTED STATUS OMITTED RED EVIDENCE
SECOND_REFUSAL=ERRONEOUS 65-CHARACTER EXPECTED SHA256
ACTUAL_DIAGNOSTIC_SHA256=0637BCA85B3CF01BDFC9851CF36805B95A5BCD5613449C85BC2D1D502CF291F9
SOURCE_AND_FROZEN_TEST_HASHES=VERIFIED
CORRECTED_PREFLIGHT=PASS
GREEN_TEST_GATE=NOT_YET_REVIEWED

CP016 GREEN REFUSAL DIAGNOSTIC
DAY=068
--- GIT HEAD ---
1966da4beeb9726739aee3517d6e2b2eb30af397
--- GIT STATUS ---
 M src/lib.rs
?? Evidence/CP-016/CP016_GREEN_Installation_Record.txt
?? Evidence/CP-016/CP016_RED_Run_Record.txt
?? Evidence/CP-016/CP016_RED_StdErr.txt
?? Evidence/CP-016/CP016_RED_StdOut.txt
?? tests/CP016_receipt_field_serialization.rs
--- UNSTAGED CHANGES ---
M	src/lib.rs
--- STAGED CHANGES ---
--- FILE HASHES ---
1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911  C:\Users\Admin\Downloads\DataSculptor-WASM002\src\lib.rs
785C520C8C0B4AD2769E424F743C6AF55337B45B6BD8062F53E9B6A4B266EBB9  C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP016_receipt_field_serialization.rs
1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911  C:\Users\Admin\Downloads\CP016_GREEN_lib_candidate.rs
538B918B634C5BFB04EFBB2DFE37257515C13094C09B4555820331C2987F9EE7  C:\Users\Admin\Downloads\CP016_PreGREEN_lib_baseline.rs
--- CP016 EVIDENCE FILES ---
CP016_GREEN_Installation_Record.txt
CP016_RED_Run_Record.txt
CP016_RED_StdErr.txt
CP016_RED_StdOut.txt

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 2.60s
     Running tests\CP016_receipt_field_serialization.rs (target\debug\deps\CP016_receipt_field_serialization-8c3a6628143f8cc6.exe)

running 8 tests
test doubles_internal_quotes_without_backslash_escaping ... ok
test filenames_and_utf8_free_text_are_double_quoted ... ok
test machine_tokens_have_exact_colon_space_and_single_lf ... ok
test machine_token_spelling_must_be_lexically_canonical ... ok
test non_negative_integers_use_ungrouped_ascii_decimal ... ok
test refuses_cr_or_lf_inside_any_single_field_value ... ok
test refuses_non_uppercase_ascii_field_keys ... ok
test text_is_preserved_without_trimming_and_document_bytes_are_deterministic ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s

CP016 GREEN INDEPENDENT VERIFICATION RUN
DAY=068
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
CARGO_EXIT_CODE=0
STDOUT_SHA256=03145F42E048239BF73864727EDEA97598F24F99011ABDCAFE6B184CFD7140D9
STDERR_SHA256=A583E05D0159B6645E48E58E29130636817EFACE6E306A69BAEDBF1D30B32980
SOURCE_SHA256=1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911
TEST_SHA256=785C520C8C0B4AD2769E424F743C6AF55337B45B6BD8062F53E9B6A4B266EBB9
GREEN_GATE=AWAITING_INDEPENDENT_REVIEW

    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.01s
     Running tests\CP016_receipt_field_serialization.rs (target\debug\deps\CP016_receipt_field_serialization-8c3a6628143f8cc6.exe)

running 8 tests
test doubles_internal_quotes_without_backslash_escaping ... ok
test filenames_and_utf8_free_text_are_double_quoted ... ok
test machine_token_spelling_must_be_lexically_canonical ... ok
test machine_tokens_have_exact_colon_space_and_single_lf ... ok
test non_negative_integers_use_ungrouped_ascii_decimal ... ok
test refuses_cr_or_lf_inside_any_single_field_value ... ok
test refuses_non_uppercase_ascii_field_keys ... ok
test text_is_preserved_without_trimming_and_document_bytes_are_deterministic ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

CP016 GIT BANKING RUN RECORD
DAY=068
DAY_STATUS=OPEN
CHECKPOINT=CP016
HUMAN_ACCEPTANCE=T APPROVED CP016
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
STAGING_REVIEW_SHA256=FCD64C8913CB9AE6ECCA18F57438C6A78FF8529A92B1C92431A757464A43C24C
PREFLIGHT=PASS
GIT_COMMIT_EXIT_CODE=0
POSTCOMMAND_HEAD=fde0f0a8b96c92f6cfb80b517396ff5512cccd13
POSTCOMMAND_PARENT=1966da4beeb9726739aee3517d6e2b2eb30af397
STDOUT_SHA256=532E633D332659F47085716626D7C99320851F70D87154F63B228303954B93B4
STDERR_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
POSTCOMMIT_VERIFICATION=AWAITING_INDEPENDENT_REVIEW

[master fde0f0a] CP016: canonical Receipt field-line serialization and evidence
 38 files changed, 220 insertions(+)
 create mode 100644 Evidence/CP-016/ZIP/CP016_Custody_Control_Sealing_Record.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_Custody_Transfer_Record.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_Custody_ZIP_Staging_Record.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_Final_Custody_Addendum_Record.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_Formatting_Amendment_Installation_Record.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_Formatting_Candidate_Record.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_Formatting_Candidate_StdErr.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_Formatting_Candidate_StdOut.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_GREEN_Installation_Record.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_GREEN_Reconciliation_Record.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_GREEN_Refusal_Diagnostic.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_GREEN_StdErr.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_GREEN_StdOut.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_GREEN_Verification_Run_Record.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_GREEN_Verification_StdErr.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_GREEN_Verification_StdOut.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_PostAmendment_Regression_Run_Record.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_PostAmendment_Regression_StdErr.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_PostAmendment_Regression_StdOut.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_PostFormat_Run_Record.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_PostFormat_StdErr.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_PostFormat_StdOut.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_PreCustody_Inventory.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_PreFormat_Frozen_Test.rs.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_RED_Run_Record.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_RED_StdErr.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_RED_StdOut.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_Regression_Run_Record.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_Regression_StdErr.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_Regression_StdOut.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_Rustfmt_Run_Record.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_Rustfmt_StdErr.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_Rustfmt_StdOut.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_WASM_Build_Run_Record.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_WASM_Build_StdErr.txt.zip
 create mode 100644 Evidence/CP-016/ZIP/CP016_WASM_Build_StdOut.txt.zip
 create mode 100644 tests/CP016_receipt_field_serialization.rs

CP016 POSTCOMMIT INTEGRITY VERIFICATION
DAY=068
DAY_STATUS=OPEN
CHECKPOINT=CP016
HUMAN_ACCEPTANCE=T APPROVED CP016
COMMIT_HEAD=fde0f0a8b96c92f6cfb80b517396ff5512cccd13
COMMIT_PARENT=1966da4beeb9726739aee3517d6e2b2eb30af397
COMMIT_SUBJECT=CP016: canonical Receipt field-line serialization and evidence
COMMITTED_FILE_COUNT=38
COMMITTED_RUST_FILES=2
COMMITTED_CUSTODY_ZIPS=36
COMMITTED_BLOBS_MATCH_WORKTREE=38
ZIP_SHA256_VERIFICATION=36_PASS
ORIGINAL_TXT_UNTRACKED=31
GIT_INDEX=CLEAN
TRACKED_WORKTREE=CLEAN
POSTCOMMIT_GATE=PASS
GIT_PUSH=NOT_PERFORMED
DAY_068=OPEN

CP016 CONTROLLED GIT STAGING REVIEW
DAY=068
DAY_STATUS=OPEN
CHECKPOINT=CP016
HUMAN_ACCEPTANCE=T APPROVED CP016
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
SOURCE_SHA256=1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911
TEST_SHA256=BA13064905D2F8444F2E11A188FE7C4EBA30AE091947F19783E34FCE006A355C
STAGED_FILE_COUNT=38
STAGED_ZIP_COUNT=36
ORIGINAL_TXT_UNTRACKED_COUNT=31
STAGED_WHITESPACE_CHECK=PASS
GIT_COMMIT=NOT_PERFORMED
STAGED_NAME_STATUS_BEGIN
A	Evidence/CP-016/ZIP/CP016_Custody_Control_Sealing_Record.txt.zip
A	Evidence/CP-016/ZIP/CP016_Custody_Transfer_Record.txt.zip
A	Evidence/CP-016/ZIP/CP016_Custody_ZIP_Staging_Record.txt.zip
A	Evidence/CP-016/ZIP/CP016_Final_Custody_Addendum_Record.txt.zip
A	Evidence/CP-016/ZIP/CP016_Formatting_Amendment_Installation_Record.txt.zip
A	Evidence/CP-016/ZIP/CP016_Formatting_Candidate_Record.txt.zip
A	Evidence/CP-016/ZIP/CP016_Formatting_Candidate_StdErr.txt.zip
A	Evidence/CP-016/ZIP/CP016_Formatting_Candidate_StdOut.txt.zip
A	Evidence/CP-016/ZIP/CP016_GREEN_Installation_Record.txt.zip
A	Evidence/CP-016/ZIP/CP016_GREEN_Reconciliation_Record.txt.zip
A	Evidence/CP-016/ZIP/CP016_GREEN_Refusal_Diagnostic.txt.zip
A	Evidence/CP-016/ZIP/CP016_GREEN_StdErr.txt.zip
A	Evidence/CP-016/ZIP/CP016_GREEN_StdOut.txt.zip
A	Evidence/CP-016/ZIP/CP016_GREEN_Verification_Run_Record.txt.zip
A	Evidence/CP-016/ZIP/CP016_GREEN_Verification_StdErr.txt.zip
A	Evidence/CP-016/ZIP/CP016_GREEN_Verification_StdOut.txt.zip
A	Evidence/CP-016/ZIP/CP016_PostAmendment_Regression_Run_Record.txt.zip
A	Evidence/CP-016/ZIP/CP016_PostAmendment_Regression_StdErr.txt.zip
A	Evidence/CP-016/ZIP/CP016_PostAmendment_Regression_StdOut.txt.zip
A	Evidence/CP-016/ZIP/CP016_PostFormat_Run_Record.txt.zip
A	Evidence/CP-016/ZIP/CP016_PostFormat_StdErr.txt.zip
A	Evidence/CP-016/ZIP/CP016_PostFormat_StdOut.txt.zip
A	Evidence/CP-016/ZIP/CP016_PreCustody_Inventory.txt.zip
A	Evidence/CP-016/ZIP/CP016_PreFormat_Frozen_Test.rs.zip
A	Evidence/CP-016/ZIP/CP016_RED_Run_Record.txt.zip
A	Evidence/CP-016/ZIP/CP016_RED_StdErr.txt.zip
A	Evidence/CP-016/ZIP/CP016_RED_StdOut.txt.zip
A	Evidence/CP-016/ZIP/CP016_Regression_Run_Record.txt.zip
A	Evidence/CP-016/ZIP/CP016_Regression_StdErr.txt.zip
A	Evidence/CP-016/ZIP/CP016_Regression_StdOut.txt.zip
A	Evidence/CP-016/ZIP/CP016_Rustfmt_Run_Record.txt.zip
A	Evidence/CP-016/ZIP/CP016_Rustfmt_StdErr.txt.zip
A	Evidence/CP-016/ZIP/CP016_Rustfmt_StdOut.txt.zip
A	Evidence/CP-016/ZIP/CP016_WASM_Build_Run_Record.txt.zip
A	Evidence/CP-016/ZIP/CP016_WASM_Build_StdErr.txt.zip
A	Evidence/CP-016/ZIP/CP016_WASM_Build_StdOut.txt.zip
M	src/lib.rs
A	tests/CP016_receipt_field_serialization.rs
STAGED_NAME_STATUS_END
ZIP_SHA256_BEGIN
ZIP|63763325CDE0DC5005D2FCCE2304B9EB78728E25508FF5447F1B9B0BBFEC369A|CP016_Custody_Control_Sealing_Record.txt.zip
ZIP|1E15CC4C9B11EC7CD635903D11424CA0DE1C01BEFB9DE8E09EAE8A8CBCD61D1A|CP016_Custody_Transfer_Record.txt.zip
ZIP|E11A943BD8E9B2591D36226C6FA727A10D7B91CA027F563D16CC57D5DEFCC96B|CP016_Custody_ZIP_Staging_Record.txt.zip
ZIP|0921C073A4E36C4A7D1BD5E10DE6A6F842C96F411BD9EC43F554E79A8DCF116C|CP016_Final_Custody_Addendum_Record.txt.zip
ZIP|E37674FF7C8847765A6D5388BC17701127AF90E01CCDCEB7F2CD6423F939E8FF|CP016_Formatting_Amendment_Installation_Record.txt.zip
ZIP|EA25765622CB63C34CE855BD2DB34B978D6B3595E23DCBC4BB3CDC4E2E6761B0|CP016_Formatting_Candidate_Record.txt.zip
ZIP|040A1343C03FB50413254ACF2CD581ADB1BFB2813B65F8D2019972F73C8DC9AB|CP016_Formatting_Candidate_StdErr.txt.zip
ZIP|DCB3ADC4799B5C6A24A4140DC600277BA9BDEE75CC4CE2B3DF449A3D7182EC77|CP016_Formatting_Candidate_StdOut.txt.zip
ZIP|E6DDFBEAC95E0F9121A088383E954625B9F7511811C559D2340E14D394D27A3F|CP016_GREEN_Installation_Record.txt.zip
ZIP|632FDDBBB83F94E22ECE7DFB6E8560FDEF52475BEF26935763621D314262A657|CP016_GREEN_Reconciliation_Record.txt.zip
ZIP|BE0E3C43A396FB76C1B710538C80B921FBE57D68D3E41CE360E467177298E6D7|CP016_GREEN_Refusal_Diagnostic.txt.zip
ZIP|0DD93FB6EE3E11C85704451C0FD16372E26B8A5930B91070A9A2AFEB9AE21890|CP016_GREEN_StdErr.txt.zip
ZIP|1A5A203D329FF6513F696E67F2F530DBEC38E0D74CA3D0DE65CE9C88EA9D0E5F|CP016_GREEN_StdOut.txt.zip
ZIP|52350070D81D104204C2D9F4642B258241D14185F70523A727FB1BEB7A3D81AE|CP016_GREEN_Verification_Run_Record.txt.zip
ZIP|164B5DA034286C3C4293E72416B1516A03D22B63CD97A8874BFEF2C66982DE1A|CP016_GREEN_Verification_StdErr.txt.zip
ZIP|B338F1A9F4ED5AE1835A9B4E8378987B7FC3DEB0EE0D4F3F3EA5B732D3B35197|CP016_GREEN_Verification_StdOut.txt.zip
ZIP|585DF9062D35330E881D7305905AE2C43F2187B1F7CD4053790634FC662B3171|CP016_PostAmendment_Regression_Run_Record.txt.zip
ZIP|ABE662F6AAB8A693DB2D40AA85885D9CA4AA32AF32132C49B10961D136F1D2F8|CP016_PostAmendment_Regression_StdErr.txt.zip
ZIP|72354A7878E597F13C0103BEFAFEC5089862616A3AA9BA4F60DD5CEDE7C939AD|CP016_PostAmendment_Regression_StdOut.txt.zip
ZIP|006A2E9E4791F14CFF6D57D334F607603C7AE0C07CC9F72FB11A1F1C4A65C93F|CP016_PostFormat_Run_Record.txt.zip
ZIP|6565915A3413E1A6785BEE50D205D027BA98E79A9E6FD18C2BC518858F49907F|CP016_PostFormat_StdErr.txt.zip
ZIP|5FB72D6DE5164F7593527AAEEF2751874946591D734B6DE8812715C3328D9804|CP016_PostFormat_StdOut.txt.zip
ZIP|0BEDB4175681E97BDCAAF2F65C55AB6CEE6F61913987A76061EE2188CF9DE3EC|CP016_PreCustody_Inventory.txt.zip
ZIP|FD916AB08DB7DE515219F20206F60DCEBCE9B387E184DBC734AA3328E7839346|CP016_PreFormat_Frozen_Test.rs.zip
ZIP|5053B752EE768D64A932E2B540535529F5F1B00E5A0ABF52741214B7E2CEF9A8|CP016_RED_Run_Record.txt.zip
ZIP|31D20200D25BFE47DC4561CE41B08D7890EDB56298C391E160F2B6B028711C09|CP016_RED_StdErr.txt.zip
ZIP|FACE368AC745B67AE8C59C7CC2D5541CA82CA72C7AC386C856CC74F08C6CB398|CP016_RED_StdOut.txt.zip
ZIP|75E189713797CC77004F671359E2A9721F3A2E1C13D42977445AD03966F0A84D|CP016_Regression_Run_Record.txt.zip
ZIP|4FD62E24ED18EA9FEE9D562D01CE39FD9B4005BE4205304FCF217817A141D568|CP016_Regression_StdErr.txt.zip
ZIP|D5A1BD0DF6B73CAEB7AA72A63C042C9B43DEBA73E51E1239A2520195B823604C|CP016_Regression_StdOut.txt.zip
ZIP|527184E58503FDA888E52EF8A7C3771E2B1B7F9816E7D4B68148DFA1E8EF9293|CP016_Rustfmt_Run_Record.txt.zip
ZIP|FCB52C11A668F70E7B9247D2C41652C4B6293DB852A4E8D7E56B9427414865DC|CP016_Rustfmt_StdErr.txt.zip
ZIP|ED850E182AC529B1F630C04CDA31E95006A725E4FEF0E3CA54C3C4925DD830E8|CP016_Rustfmt_StdOut.txt.zip
ZIP|BA61FB3400B606CE8D8D16418B0F5A4026B5FBBA39267DE46613A71CCBC8F7DB|CP016_WASM_Build_Run_Record.txt.zip
ZIP|3064A301187BA8536A2D359B824ABAFE6F66BAF8AF3A22D485700D4F868BA0A4|CP016_WASM_Build_StdErr.txt.zip
ZIP|DF0604F618250D1DAB37BFE740FDC7A7DB43AAA41DE1C1B2C187046A6B12B88C|CP016_WASM_Build_StdOut.txt.zip
ZIP_SHA256_END

CP016 POST-AMENDMENT FULL NATIVE REGRESSION
DAY=068
CHECKPOINT=CP016
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
CARGO_EXIT_CODE=0
PASSING_TEST_COUNT=78
STDOUT_SHA256=BCC377042E9C613794EFA16CBD59EED6285F038434E1E4C15A77DAEDC95DEAD6
STDERR_SHA256=977667140D7BF4709024221865E8409A87B67CE372F413AB82796C190F79F1B0
SOURCE_SHA256=1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911
TEST_SHA256=BA13064905D2F8444F2E11A188FE7C4EBA30AE091947F19783E34FCE006A355C
GATE=AWAITING_REVIEW

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.99s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)
     Running tests\CP008_source_eligibility.rs (target\debug\deps\CP008_source_eligibility-194c314726b26929.exe)
     Running tests\CP009_exact_root_snapshot.rs (target\debug\deps\CP009_exact_root_snapshot-b26a1b02e36e8f07.exe)
     Running tests\CP010_cvt_filename_candidate.rs (target\debug\deps\CP010_cvt_filename_candidate-ce216c0140f6b173.exe)
     Running tests\CP011_cvt_scr_candidate_identity.rs (target\debug\deps\CP011_cvt_scr_candidate_identity-8bc68fabbbb42eb4.exe)
     Running tests\CP012_scr_filename_candidate.rs (target\debug\deps\CP012_scr_filename_candidate-7c39746d8bb6fac7.exe)
     Running tests\CP013_scr_rcp_candidate_identity.rs (target\debug\deps\CP013_scr_rcp_candidate_identity-4f7c7bea8654150d.exe)
     Running tests\CP014_rcp_filename_candidate_identity.rs (target\debug\deps\CP014_rcp_filename_candidate_identity-249a1cd498442ced.exe)
     Running tests\CP015_scr_rcp_filename_pair_identity.rs (target\debug\deps\CP015_scr_rcp_filename_pair_identity-526d10560ef9b891.exe)
     Running tests\CP016_receipt_field_serialization.rs (target\debug\deps\CP016_receipt_field_serialization-8c3a6628143f8cc6.exe)
     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)
     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)
     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)
     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)
     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)
     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)
   Doc-tests data_sculptor_core

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 5 tests
test makes_no_case_or_unicode_normalization_claim ... ok
test accepts_analyst_csv_final_extension_in_ascii_case_variants ... ok
test refuses_paths_traversal_and_external_references ... ok
test refuses_reserved_namespace_even_if_name_looks_like_csv ... ok
test rejects_non_csv_or_nonfinal_csv_extensions ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 8 tests
test candidate_preflight_runs_before_root_matching ... ok
test duplicate_exact_entries_refuse_instead_of_picking_first ... ok
test finds_one_exact_reported_regular_file ... ok
test full_filename_match_is_exact_and_case_sensitive ... ok
test never_trims_to_find_a_different_physical_name ... ok
test reported_non_regular_entries_do_not_pass ... ok
test result_is_order_independent_and_empty_snapshot_is_not_found ... ok
test unicode_scalar_sequence_is_not_normalized ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test accepts_exact_canonical_cvt_csv_candidate ... ok
test refuses_malformed_canonical_identity ... ok
test refuses_paths_and_noncanonical_references ... ok
test refuses_wrong_classes_and_extensions ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test derives_exact_corresponding_scr_identity ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_whitespace_and_noncanonical_names ... ok
test refuses_wrong_extension_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test accepts_canonical_scr_csv_candidate ... ok
test accepts_canonical_scr_txt_candidate ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_noncanonical_namespace_class_and_extension ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_and_whitespace ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test derives_rcp_candidate_only_with_explicit_class ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_invalid_identity_paths_and_whitespace ... ok
test refuses_non_scr_and_noncanonical_source_classes ... ok
test refuses_unsupported_or_incorrectly_cased_final_classes ... ok
test refuses_wrong_or_ambiguous_serialization_extensions ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test recognizes_existing_scr_to_rcp_derivation ... ok
test accepts_canonical_rcp_txt_identity ... ok
test refuses_invalid_timestamp_uuid_and_envelope ... ok
test refuses_noncanonical_serialization ... ok
test refuses_paths_and_whitespace ... ok
test refuses_wrong_semantic_class_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s


running 6 tests
test refuses_mismatched_utc_timestamp_even_when_both_names_are_canonical ... ok
test accepts_matching_canonical_scr_and_rcp_txt_names ... ok
test refuses_mismatched_uuid_even_when_both_names_are_canonical ... ok
test refuses_paths_and_whitespace_on_either_side ... ok
test refuses_wrong_class_or_reversed_pair_order ... ok
test refuses_wrong_extensions_and_noncanonical_envelopes ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 8 tests
test doubles_internal_quotes_without_backslash_escaping ... ok
test machine_token_spelling_must_be_lexically_canonical ... ok
test filenames_and_utf8_free_text_are_double_quoted ... ok
test machine_tokens_have_exact_colon_space_and_single_lf ... ok
test non_negative_integers_use_ungrouped_ascii_decimal ... ok
test refuses_cr_or_lf_inside_any_single_field_value ... ok
test refuses_non_uppercase_ascii_field_keys ... ok
test text_is_preserved_without_trimming_and_document_bytes_are_deterministic ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_registered_emittable_classes ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test constructs_exact_canonical_filename_candidates ... ok
test preserves_extension_without_case_or_unicode_normalization ... ok
test refuses_noncanonical_class_without_repair ... ok
test refuses_invalid_timestamp_uuid_and_empty_extension ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test accepts_canonical_immutable_filename_envelopes ... ok
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test recognizes_governed_namespace_and_class ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_invalid_class_boundaries ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test extension_does_not_determine_semantic_class ... ok
test extracts_semantic_class_and_serialization_separately ... ok
test preserves_literal_tokens_without_claiming_authority ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok
test rejects_nonexistent_gregorian_dates ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

CP016 POST-AMENDMENT RUSTFMT CHECK
DAY=068
CHECKPOINT=CP016
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
RUSTFMT_EXIT_CODE=0
SOURCE_SHA256=1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911
TEST_SHA256=BA13064905D2F8444F2E11A188FE7C4EBA30AE091947F19783E34FCE006A355C
STDOUT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
STDERR_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
GATE=AWAITING_REVIEW

CP016 PRE-CUSTODY EVIDENCE INVENTORY
DAY=068
CHECKPOINT=CP016
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
SOURCE_SHA256=1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911
TEST_SHA256=BA13064905D2F8444F2E11A188FE7C4EBA30AE091947F19783E34FCE006A355C
GIT_INDEX=EMPTY
WASM_STDOUT_EMPTY=VERIFIED
EVIDENCE_FILE_COUNT=30
INVENTORY_EXCLUDES_SELF=YES
ENTRY_FORMAT=ENTRY|SHA256|BYTES|FILENAME
ENTRY|323414623F563B967DC70DCECECDD4BD38EF76C364F178990A162AAD92CF0A48|712|CP016_Formatting_Amendment_Installation_Record.txt
ENTRY|4C538648A51DC88BCC2169FB4EADF63E4477327883734E0DDD4C58B06865AE2C|785|CP016_Formatting_Candidate_Record.txt
ENTRY|E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855|0|CP016_Formatting_Candidate_StdErr.txt
ENTRY|E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855|0|CP016_Formatting_Candidate_StdOut.txt
ENTRY|1D34568776D131887AA9C42B9E69B4CB285ED2975524E57B841EE53E2300112B|445|CP016_GREEN_Installation_Record.txt
ENTRY|DFD19A077DED5554AE281856DB8F4A6B0EF791AEF67755B3E2717DE78A23592F|337|CP016_GREEN_Reconciliation_Record.txt
ENTRY|0637BCA85B3CF01BDFC9851CF36805B95A5BCD5613449C85BC2D1D502CF291F9|1088|CP016_GREEN_Refusal_Diagnostic.txt
ENTRY|07B4E2082D32EC4EA23FD7E5846847BD832DD6E493ED74229330C4824553F2F7|291|CP016_GREEN_StdErr.txt
ENTRY|6729744B5DC3448CC26017751AA242EBE75C0C2C7E79270E05D3B25AB3748849|618|CP016_GREEN_StdOut.txt
ENTRY|35EF75DFB76A633A5BF2DDFEBB05EC1B776D9BCF692F2DAC8213D41B0758F6AF|475|CP016_GREEN_Verification_Run_Record.txt
ENTRY|A583E05D0159B6645E48E58E29130636817EFACE6E306A69BAEDBF1D30B32980|204|CP016_GREEN_Verification_StdErr.txt
ENTRY|03145F42E048239BF73864727EDEA97598F24F99011ABDCAFE6B184CFD7140D9|618|CP016_GREEN_Verification_StdOut.txt
ENTRY|701B955953A574F009C30C150B7257CD92D1D2E51FB30359D2D1449373DE4145|499|CP016_PostAmendment_Regression_Run_Record.txt
ENTRY|977667140D7BF4709024221865E8409A87B67CE372F413AB82796C190F79F1B0|2121|CP016_PostAmendment_Regression_StdErr.txt
ENTRY|BCC377042E9C613794EFA16CBD59EED6285F038434E1E4C15A77DAEDC95DEAD6|6429|CP016_PostAmendment_Regression_StdOut.txt
ENTRY|66625015248D88508C85C6586214FC60548F3B9AFF5BC181649E522FEC58EB2C|470|CP016_PostFormat_Run_Record.txt
ENTRY|E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855|0|CP016_PostFormat_StdErr.txt
ENTRY|E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855|0|CP016_PostFormat_StdOut.txt
ENTRY|1F3D312B4DC85938CBEB3A4C5337379A98D80B97AC8FFFFE20067783825EE469|460|CP016_RED_Run_Record.txt
ENTRY|80B1C35E94905F2522A541DF87DDB9DE30AD4F72F9B0A42A465C3B0E9BC04C52|788|CP016_RED_StdErr.txt
ENTRY|E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855|0|CP016_RED_StdOut.txt
ENTRY|02AB46A2E4CEF2E9EB6C22BFEA172B17105E7FE3A7F6430AAED932FAACF951C2|473|CP016_Regression_Run_Record.txt
ENTRY|AEAC8984FB12E18D7B98FE5780C53B6BB58519D90746C086A59F2AC8772C56CD|2121|CP016_Regression_StdErr.txt
ENTRY|01A1E149ABC83565B33308AFD7E052235EDA3E36746DB67BD38A7E3DD0070719|6429|CP016_Regression_StdOut.txt
ENTRY|078F1365A26ED51FCA265DED562DFB350C80504308C031C0EF3D955D99A47E85|591|CP016_Rustfmt_Run_Record.txt
ENTRY|E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855|0|CP016_Rustfmt_StdErr.txt
ENTRY|5EC045ECF10B589E7AF1A4952528AD6EBC077693EEA64277C237FF1BE93DE4D1|6605|CP016_Rustfmt_StdOut.txt
ENTRY|DB6864F6816883E927810A1854C9E34A67F7CBCEBB0D6D382F1A5A6CF9FC9764|809|CP016_WASM_Build_Run_Record.txt
ENTRY|6AD3D0DED9FDE31964BC0A536AE0E8B570152648166F13580EB46A1AA1425C36|159|CP016_WASM_Build_StdErr.txt
ENTRY|E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855|0|CP016_WASM_Build_StdOut.txt

CP016 RED RUN RECORD
DAY=068
CHECKPOINT=CP016
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
TEST_SHA256=785C520C8C0B4AD2769E424F743C6AF55337B45B6BD8062F53E9B6A4B266EBB9
SOURCE_SHA256=538B918B634C5BFB04EFBB2DFE37257515C13094C09B4555820331C2987F9EE7
CARGO_EXIT_CODE=101
STDOUT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
STDERR_SHA256=80B1C35E94905F2522A541DF87DDB9DE30AD4F72F9B0A42A465C3B0E9BC04C52
RED_GATE=AWAITING_REVIEW

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
error[E0432]: unresolved imports `data_sculptor_core::serialize_canonical_receipt_field_line`, `data_sculptor_core::ReceiptFieldValue`
 --> tests\CP016_receipt_field_serialization.rs:8:26
  |
8 | use data_sculptor_core::{serialize_canonical_receipt_field_line, ReceiptFieldValue};
  |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^ no `ReceiptFieldValue` in the root
  |                          |
  |                          no `serialize_canonical_receipt_field_line` in the root

For more information about this error, try `rustc --explain E0432`.
error: could not compile `data_sculptor_core` (test "CP016_receipt_field_serialization") due to 1 previous error

CP016 FULL NATIVE REGRESSION
DAY=068
CHECKPOINT=CP016
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
CARGO_EXIT_CODE=0
STDOUT_SHA256=01A1E149ABC83565B33308AFD7E052235EDA3E36746DB67BD38A7E3DD0070719
STDERR_SHA256=AEAC8984FB12E18D7B98FE5780C53B6BB58519D90746C086A59F2AC8772C56CD
SOURCE_SHA256=1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911
TEST_SHA256=785C520C8C0B4AD2769E424F743C6AF55337B45B6BD8062F53E9B6A4B266EBB9
REGRESSION_GATE=AWAITING_REVIEW

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 3.45s
     Running unittests src\lib.rs (target\debug\deps\data_sculptor_core-de0091f1467e27b4.exe)
     Running tests\CP008_source_eligibility.rs (target\debug\deps\CP008_source_eligibility-194c314726b26929.exe)
     Running tests\CP009_exact_root_snapshot.rs (target\debug\deps\CP009_exact_root_snapshot-b26a1b02e36e8f07.exe)
     Running tests\CP010_cvt_filename_candidate.rs (target\debug\deps\CP010_cvt_filename_candidate-ce216c0140f6b173.exe)
     Running tests\CP011_cvt_scr_candidate_identity.rs (target\debug\deps\CP011_cvt_scr_candidate_identity-8bc68fabbbb42eb4.exe)
     Running tests\CP012_scr_filename_candidate.rs (target\debug\deps\CP012_scr_filename_candidate-7c39746d8bb6fac7.exe)
     Running tests\CP013_scr_rcp_candidate_identity.rs (target\debug\deps\CP013_scr_rcp_candidate_identity-4f7c7bea8654150d.exe)
     Running tests\CP014_rcp_filename_candidate_identity.rs (target\debug\deps\CP014_rcp_filename_candidate_identity-249a1cd498442ced.exe)
     Running tests\CP015_scr_rcp_filename_pair_identity.rs (target\debug\deps\CP015_scr_rcp_filename_pair_identity-526d10560ef9b891.exe)
     Running tests\CP016_receipt_field_serialization.rs (target\debug\deps\CP016_receipt_field_serialization-8c3a6628143f8cc6.exe)
     Running tests\artifact_class_disposition.rs (target\debug\deps\artifact_class_disposition-27b178107257d186.exe)
     Running tests\artifact_filename_construction.rs (target\debug\deps\artifact_filename_construction-5cf670a1ba53be29.exe)
     Running tests\artifact_filename_envelope.rs (target\debug\deps\artifact_filename_envelope-51974b55a7d36cd0.exe)
     Running tests\artifact_namespace.rs (target\debug\deps\artifact_namespace-4ae3f3dd863a12a4.exe)
     Running tests\artifact_serialization_separation.rs (target\debug\deps\artifact_serialization_separation-96fb32ea1270c8cd.exe)
     Running tests\artifact_utc_timestamp.rs (target\debug\deps\artifact_utc_timestamp-4837e24de0c59c23.exe)
   Doc-tests data_sculptor_core

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 5 tests
test accepts_analyst_csv_final_extension_in_ascii_case_variants ... ok
test makes_no_case_or_unicode_normalization_claim ... ok
test refuses_paths_traversal_and_external_references ... ok
test refuses_reserved_namespace_even_if_name_looks_like_csv ... ok
test rejects_non_csv_or_nonfinal_csv_extensions ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 8 tests
test finds_one_exact_reported_regular_file ... ok
test duplicate_exact_entries_refuse_instead_of_picking_first ... ok
test candidate_preflight_runs_before_root_matching ... ok
test full_filename_match_is_exact_and_case_sensitive ... ok
test never_trims_to_find_a_different_physical_name ... ok
test reported_non_regular_entries_do_not_pass ... ok
test result_is_order_independent_and_empty_snapshot_is_not_found ... ok
test unicode_scalar_sequence_is_not_normalized ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test accepts_exact_canonical_cvt_csv_candidate ... ok
test refuses_malformed_canonical_identity ... ok
test refuses_paths_and_noncanonical_references ... ok
test refuses_wrong_classes_and_extensions ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test derives_exact_corresponding_scr_identity ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_invalid_utc_and_uuid ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_whitespace_and_noncanonical_names ... ok
test refuses_wrong_extension_and_case ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test refuses_invalid_utc_and_uuid ... ok
test accepts_canonical_scr_csv_candidate ... ok
test accepts_canonical_scr_txt_candidate ... ok
test refuses_noncanonical_namespace_class_and_extension ... ok
test refuses_other_semantic_classes ... ok
test refuses_paths_and_whitespace ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test derives_rcp_candidate_only_with_explicit_class ... ok
test refuses_invalid_identity_paths_and_whitespace ... ok
test preserves_distinct_timestamp_and_uuid_tokens ... ok
test refuses_non_scr_and_noncanonical_source_classes ... ok
test refuses_unsupported_or_incorrectly_cased_final_classes ... ok
test refuses_wrong_or_ambiguous_serialization_extensions ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test recognizes_existing_scr_to_rcp_derivation ... ok
test refuses_noncanonical_serialization ... ok
test accepts_canonical_rcp_txt_identity ... ok
test refuses_invalid_timestamp_uuid_and_envelope ... ok
test refuses_wrong_semantic_class_and_case ... ok
test refuses_paths_and_whitespace ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test refuses_paths_and_whitespace_on_either_side ... ok
test refuses_mismatched_utc_timestamp_even_when_both_names_are_canonical ... ok
test refuses_mismatched_uuid_even_when_both_names_are_canonical ... ok
test accepts_matching_canonical_scr_and_rcp_txt_names ... ok
test refuses_wrong_class_or_reversed_pair_order ... ok
test refuses_wrong_extensions_and_noncanonical_envelopes ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 8 tests
test doubles_internal_quotes_without_backslash_escaping ... ok
test filenames_and_utf8_free_text_are_double_quoted ... ok
test machine_token_spelling_must_be_lexically_canonical ... ok
test machine_tokens_have_exact_colon_space_and_single_lf ... ok
test non_negative_integers_use_ungrouped_ascii_decimal ... ok
test refuses_cr_or_lf_inside_any_single_field_value ... ok
test refuses_non_uppercase_ascii_field_keys ... ok
test text_is_preserved_without_trimming_and_document_bytes_are_deterministic ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test distinguishes_malformed_reserved_names_and_external_names ... ok
test distinguishes_registered_emittable_classes ... ok
test distinguishes_reserved_not_emitted_and_unallocated_classes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test constructs_exact_canonical_filename_candidates ... ok
test refuses_invalid_timestamp_uuid_and_empty_extension ... ok
test refuses_noncanonical_class_without_repair ... ok
test preserves_extension_without_case_or_unicode_normalization ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test rejects_malformed_namespace_class_and_timestamp_tokens ... ok
test rejects_noncanonical_uuid_and_missing_extension ... ok
test accepts_canonical_immutable_filename_envelopes ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 6 tests
test recognizes_governed_namespace_and_class ... ok
test recognizes_remaining_frozen_registry_classes ... ok
test rejects_invalid_class_boundaries ... ok
test recognizes_reserved_but_nonemitting_classes ... ok
test rejects_noncanonical_prefix_and_unknown_class ... ok
test reserved_prefix_is_independent_of_registered_class ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 4 tests
test extension_does_not_determine_semantic_class ... ok
test refuses_tokens_when_filename_envelope_is_invalid ... ok
test extracts_semantic_class_and_serialization_separately ... ok
test preserves_literal_tokens_without_claiming_authority ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 3 tests
test accepts_valid_gregorian_dates_and_time_boundaries ... ok
test rejects_invalid_clock_values_and_unapproved_leap_seconds ... ok
test rejects_nonexistent_gregorian_dates ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

CP016 RUSTFMT VERIFICATION
DAY=068
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
EXIT_CODE=1
SOURCE_BEFORE=1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911
SOURCE_AFTER=1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911
TEST_BEFORE=785C520C8C0B4AD2769E424F743C6AF55337B45B6BD8062F53E9B6A4B266EBB9
TEST_AFTER=785C520C8C0B4AD2769E424F743C6AF55337B45B6BD8062F53E9B6A4B266EBB9
STDOUT_SHA256=5EC045ECF10B589E7AF1A4952528AD6EBC077693EEA64277C237FF1BE93DE4D1
STDERR_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
GATE=AWAITING_REVIEW

Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP016_receipt_field_serialization.rs:5:
 // WKO authority, staged publication, or claim that a durable Receipt exists.
 // Preserve this original test file's SHA-256 after T approves the contract.
 
-use data_sculptor_core::{serialize_canonical_receipt_field_line, ReceiptFieldValue};
+use data_sculptor_core::{ReceiptFieldValue, serialize_canonical_receipt_field_line};
 
 #[test]
 fn machine_tokens_have_exact_colon_space_and_single_lf() {
Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP016_receipt_field_serialization.rs:12:
     assert_eq!(
-        serialize_canonical_receipt_field_line("RESULT", ReceiptFieldValue::MachineToken("SUCCESS")),
+        serialize_canonical_receipt_field_line(
+            "RESULT",
+            ReceiptFieldValue::MachineToken("SUCCESS")
+        ),
         Some("RESULT: SUCCESS\n".to_owned())
     );
     assert_eq!(
Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP016_receipt_field_serialization.rs:17:
-        serialize_canonical_receipt_field_line("ABSENCE", ReceiptFieldValue::MachineToken("NOT_AVAILABLE")),
+        serialize_canonical_receipt_field_line(
+            "ABSENCE",
+            ReceiptFieldValue::MachineToken("NOT_AVAILABLE")
+        ),
         Some("ABSENCE: NOT_AVAILABLE\n".to_owned())
     );
 }
Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP016_receipt_field_serialization.rs:28:
         (u64::MAX, "COUNT: 18446744073709551615\n"),
     ] {
         assert_eq!(
-            serialize_canonical_receipt_field_line("COUNT", ReceiptFieldValue::NonNegativeInteger(value)),
+            serialize_canonical_receipt_field_line(
+                "COUNT",
+                ReceiptFieldValue::NonNegativeInteger(value)
+            ),
             Some(expected.to_owned())
         );
     }
Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP016_receipt_field_serialization.rs:52:
 #[test]
 fn doubles_internal_quotes_without_backslash_escaping() {
     assert_eq!(
-        serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText("He said \"go\"")),
+        serialize_canonical_receipt_field_line(
+            "DETAIL",
+            ReceiptFieldValue::QuotedText("He said \"go\"")
+        ),
         Some("DETAIL: \"He said \"\"go\"\"\"\n".to_owned())
     );
 }
Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP016_receipt_field_serialization.rs:67:
     }
     for token in ["SUCCESS\n", "SUCCESS\r", "SUCCESS\r\n"] {
         assert_eq!(
-            serialize_canonical_receipt_field_line("RESULT", ReceiptFieldValue::MachineToken(token)),
+            serialize_canonical_receipt_field_line(
+                "RESULT",
+                ReceiptFieldValue::MachineToken(token)
+            ),
             None
         );
     }
Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP016_receipt_field_serialization.rs:76:
 #[test]
 fn refuses_non_uppercase_ascii_field_keys() {
     for key in [
-        "", "result", " Result", "RESULT ", "RESULT: X", "KEY=VALUE",
-        "RÉSULT", "1RESULT", "RESULT\tOTHER", "RESULT\nOTHER",
+        "",
+        "result",
+        " Result",
+        "RESULT ",
+        "RESULT: X",
+        "KEY=VALUE",
+        "RÉSULT",
+        "1RESULT",
+        "RESULT\tOTHER",
+        "RESULT\nOTHER",
     ] {
         assert_eq!(
             serialize_canonical_receipt_field_line(key, ReceiptFieldValue::MachineToken("SUCCESS")),
Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP016_receipt_field_serialization.rs:96:
 
 #[test]
 fn machine_token_spelling_must_be_lexically_canonical() {
-    for token in ["", "success", "Success", " SUCCESS", "SUCCESS ", "NOT-AVAILABLE", "Café", "1SUCCESS", "SUCCESS\t"] {
+    for token in [
+        "",
+        "success",
+        "Success",
+        " SUCCESS",
+        "SUCCESS ",
+        "NOT-AVAILABLE",
+        "Café",
+        "1SUCCESS",
+        "SUCCESS\t",
+    ] {
         assert_eq!(
-            serialize_canonical_receipt_field_line("RESULT", ReceiptFieldValue::MachineToken(token)),
+            serialize_canonical_receipt_field_line(
+                "RESULT",
+                ReceiptFieldValue::MachineToken(token)
+            ),
             None,
             "invalid token must refuse: {token:?}"
         );
Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP016_receipt_field_serialization.rs:108:
 #[test]
 fn text_is_preserved_without_trimming_and_document_bytes_are_deterministic() {
     let lines = [
-        serialize_canonical_receipt_field_line("RESULT", ReceiptFieldValue::MachineToken("SUCCESS")).unwrap(),
-        serialize_canonical_receipt_field_line("COUNT", ReceiptFieldValue::NonNegativeInteger(0)).unwrap(),
-        serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText(" a  b ")).unwrap(),
+        serialize_canonical_receipt_field_line(
+            "RESULT",
+            ReceiptFieldValue::MachineToken("SUCCESS"),
+        )
+        .unwrap(),
+        serialize_canonical_receipt_field_line("COUNT", ReceiptFieldValue::NonNegativeInteger(0))
+            .unwrap(),
+        serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText(" a  b "))
+            .unwrap(),
         serialize_canonical_receipt_field_line("EMPTY", ReceiptFieldValue::QuotedText("")).unwrap(),
     ];
     let output = lines.concat();
Diff in \\?\C:\Users\Admin\Downloads\DataSculptor-WASM002\tests\CP016_receipt_field_serialization.rs:117:
-    assert_eq!(output.as_bytes(), b"RESULT: SUCCESS\nCOUNT: 0\nDETAIL: \" a  b \"\nEMPTY: \"\"\n");
+    assert_eq!(
+        output.as_bytes(),
+        b"RESULT: SUCCESS\nCOUNT: 0\nDETAIL: \" a  b \"\nEMPTY: \"\"\n"
+    );
     assert!(output.ends_with('\n'));
     assert!(!output.ends_with("\n\n"));
     assert!(!output.contains("\r"));

CP016 WASM LIBRARY BUILD
DAY=068
CHECKPOINT=CP016
COMMAND=cargo build --target wasm32-unknown-unknown --lib
BASELINE_HEAD=1966da4beeb9726739aee3517d6e2b2eb30af397
CARGO_VERSION=cargo 1.97.1 (c980f4866 2026-06-30)
RUSTC_VERSION=rustc 1.97.1 (8bab26f4f 2026-07-14)
CARGO_EXIT_CODE=0
SOURCE_SHA256_BEFORE=1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911
SOURCE_SHA256_AFTER=1CC873DF106FE75B3BF8349707B8EE37DB4B4025174856CDB155BD99B3149911
TEST_SHA256_BEFORE=BA13064905D2F8444F2E11A188FE7C4EBA30AE091947F19783E34FCE006A355C
TEST_SHA256_AFTER=BA13064905D2F8444F2E11A188FE7C4EBA30AE091947F19783E34FCE006A355C
STDOUT_SHA256=E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
STDERR_SHA256=6AD3D0DED9FDE31964BC0A536AE0E8B570152648166F13580EB46A1AA1425C36
WASM_BUILD_GATE=AWAITING_REVIEW

   Compiling data_sculptor_core v0.1.0 (C:\Users\Admin\Downloads\DataSculptor-WASM002)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 2.13s

// CP016 RED tests - Day 068 (2026-10-15)
// Proposed T-approval gate: deterministic serialization of ONE canonical Receipt field line.
// Frozen anchor: W002-RCP-005 (bounded PARTIAL portion only).
// No full Receipt schema, key ordering, operation vocabulary, filesystem I/O,
// WKO authority, staged publication, or claim that a durable Receipt exists.
// Preserve this original test file's SHA-256 after T approves the contract.

use data_sculptor_core::{serialize_canonical_receipt_field_line, ReceiptFieldValue};

#[test]
fn machine_tokens_have_exact_colon_space_and_single_lf() {
    assert_eq!(
        serialize_canonical_receipt_field_line("RESULT", ReceiptFieldValue::MachineToken("SUCCESS")),
        Some("RESULT: SUCCESS\n".to_owned())
    );
    assert_eq!(
        serialize_canonical_receipt_field_line("ABSENCE", ReceiptFieldValue::MachineToken("NOT_AVAILABLE")),
        Some("ABSENCE: NOT_AVAILABLE\n".to_owned())
    );
}

#[test]
fn non_negative_integers_use_ungrouped_ascii_decimal() {
    for (value, expected) in [
        (0_u64, "COUNT: 0\n"),
        (16, "COUNT: 16\n"),
        (1234567, "COUNT: 1234567\n"),
        (u64::MAX, "COUNT: 18446744073709551615\n"),
    ] {
        assert_eq!(
            serialize_canonical_receipt_field_line("COUNT", ReceiptFieldValue::NonNegativeInteger(value)),
            Some(expected.to_owned())
        );
    }
}

#[test]
fn filenames_and_utf8_free_text_are_double_quoted() {
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "WORK_ORDER_FILENAME",
            ReceiptFieldValue::QuotedText("__DS__WKO__20261015T123456789Z__550e8400-e29b-41d4-a716-446655440000.txt")
        ),
        Some("WORK_ORDER_FILENAME: \"__DS__WKO__20261015T123456789Z__550e8400-e29b-41d4-a716-446655440000.txt\"\n".to_owned())
    );
    assert_eq!(
        serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText("café 雪")),
        Some("DETAIL: \"café 雪\"\n".to_owned())
    );
}

#[test]
fn doubles_internal_quotes_without_backslash_escaping() {
    assert_eq!(
        serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText("He said \"go\"")),
        Some("DETAIL: \"He said \"\"go\"\"\"\n".to_owned())
    );
}

#[test]
fn refuses_cr_or_lf_inside_any_single_field_value() {
    for text in ["before\nafter", "before\rafter", "before\r\nafter"] {
        assert_eq!(
            serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText(text)),
            None
        );
    }
    for token in ["SUCCESS\n", "SUCCESS\r", "SUCCESS\r\n"] {
        assert_eq!(
            serialize_canonical_receipt_field_line("RESULT", ReceiptFieldValue::MachineToken(token)),
            None
        );
    }
}

#[test]
fn refuses_non_uppercase_ascii_field_keys() {
    for key in [
        "", "result", " Result", "RESULT ", "RESULT: X", "KEY=VALUE",
        "RÉSULT", "1RESULT", "RESULT\tOTHER", "RESULT\nOTHER",
    ] {
        assert_eq!(
            serialize_canonical_receipt_field_line(key, ReceiptFieldValue::MachineToken("SUCCESS")),
            None,
            "invalid key must refuse: {key:?}"
        );
    }
    assert_eq!(
        serialize_canonical_receipt_field_line(
            "PUBLISHED_COL_001_FILENAME",
            ReceiptFieldValue::QuotedText("example.csv")
        ),
        Some("PUBLISHED_COL_001_FILENAME: \"example.csv\"\n".to_owned())
    );
}

#[test]
fn machine_token_spelling_must_be_lexically_canonical() {
    for token in ["", "success", "Success", " SUCCESS", "SUCCESS ", "NOT-AVAILABLE", "Café", "1SUCCESS", "SUCCESS\t"] {
        assert_eq!(
            serialize_canonical_receipt_field_line("RESULT", ReceiptFieldValue::MachineToken(token)),
            None,
            "invalid token must refuse: {token:?}"
        );
    }
}

#[test]
fn text_is_preserved_without_trimming_and_document_bytes_are_deterministic() {
    let lines = [
        serialize_canonical_receipt_field_line("RESULT", ReceiptFieldValue::MachineToken("SUCCESS")).unwrap(),
        serialize_canonical_receipt_field_line("COUNT", ReceiptFieldValue::NonNegativeInteger(0)).unwrap(),
        serialize_canonical_receipt_field_line("DETAIL", ReceiptFieldValue::QuotedText(" a  b ")).unwrap(),
        serialize_canonical_receipt_field_line("EMPTY", ReceiptFieldValue::QuotedText("")).unwrap(),
    ];
    let output = lines.concat();
    assert_eq!(output.as_bytes(), b"RESULT: SUCCESS\nCOUNT: 0\nDETAIL: \" a  b \"\nEMPTY: \"\"\n");
    assert!(output.ends_with('\n'));
    assert!(!output.ends_with("\n\n"));
    assert!(!output.contains("\r"));
    assert!(!output.contains("\n\n"));
    assert!(!output.as_bytes().starts_with(&[0xef, 0xbb, 0xbf]));
}

requirement_id,title,family,major_family,scope,source_prd_status,source_build_flag,requirement_text,implementation_state,local_verification,independent_qa,requirement_acceptance,linked_checkpoints,checkpoint_disposition,git_commits,test_evidence,implementation_notes,last_evidence_day,source_revision
PB-STOR-001,Suitcase is the complete Data Sculptor-controlled persistence surface,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Every persistent project or analytical artifact intentionally created by Data Sculptor must be written into the visible, user-controlled Suitcase. Data Sculptor must not intentionally persist user data, analytical state, scratch state, logs, recovery state, or project metadata in hidden AppData-style locations or browser-private persistence such as OPFS. Incidental browser/OS runtime caches outside Data Sculptor control are explicitly outside this contract. F-24 browser-session persistence boundary: WASM-002 must not use IndexedDB, localStorage , OPFS, another browser-private database, or an equivalent hidden Data Sculptor-controlled persistence surface to remember a Suitcase directory handle, unsaved WIP text, project truth, analytical state, or live UI preferences between application instances. A later build may deliberately define a user-visible preferences or continuity mechanism, but WASM-002 does not create one implicitly. Volatile in-memory runtime state within the current application instance is permitted.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-002,No Data Sculptor-created subfolders,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor does not create scratch/cache subfolders inside the Suitcase. Logical organization is expressed by the flat filename grammar, open metadata, Store MAP, and human-facing aliases.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-004,__DS__ is the reserved Data Sculptor governed namespace,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Every artifact that Data Sculptor creates or intentionally interprets as one of its governed artifacts must use the exact visible prefix __DS__ . The prefix identifies participation in the Data Sculptor namespace; it does not imply that the artifact is temporary, scratch-only, or automatically generated.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-001,BANKED; separate requirement acceptance not claimed,03201870b8ec68730a0c027c572db03ccd5eeaa8,Evidence/CP-001/CP001_GREEN2_Test_Output.txt; Evidence/CP-001/CP001_WASM_Build_Output.txt,"CP001: bounded lexical artifact-class recognition via reserved_artifact_class(). Five native tests passed and Rust wasm32-target library built. No content/provenance/authority validation, persistence, or complete governed artifact contract implemented.",Day063,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-005,External inputs retain their identity; Data Sculptor derivatives enter the namespace,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"An analyst or external source file must not be renamed into __DS__ merely because Data Sculptor reads, fingerprints, certifies, or references it. If Data Sculptor creates a new governed derivative—such as an explicit converted source—the new artifact enters the __DS__ namespace under its semantic class. F-26 SOURCE boundary: a Suitcase-root file whose exact filename begins with the reserved prefix __DS__ is not treated as an analyst-owned source merely because it has a CSV-like extension or CSV-like bytes. It participates in the reserved Data Sculptor namespace and must satisfy the applicable governed-artifact contract before any governed role is granted.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-002,"T-ACCEPTED, BANKED; requirement remains partial",206dcd8b76af29edcb658a0c5a2dc40d87089fe3,Evidence/CP-002/CP002_Post_Format_Test_Output.txt; Evidence/CP-002/CP002_Post_Format_WASM_Build_Output.txt; Evidence/CP-002/CP002_Hash_Inventory_Verification.txt,CP002: exact __DS__ lexical prefix recognition via has_reserved_namespace_prefix(). Six native tests and wasm32-target compilation passed. The SOURCE boundary and governed CVT validation/emission rules in this requirement are NOT implemented.,Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-006,The governed semantic artifact-class registry is explicit and stable,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The token immediately following __DS__ must be an exact three-uppercase-letter semantic artifact class. The governed class tokens currently reserved by this PRD are: Class Meaning WKO Work Order RCP Receipt DGN Diagnostic Event — reserved; not emitted by WASM-002 HLP Help Report CER Certification Evidence CVT Converted Source RID Row Identity COL Materialized Column MAP Governed MAP artifact class — Store MAP and WKO MAP profiles CAT Store Catalog — collection-level orientation index across MAP-governed Stores INV Suitcase Inventory Snapshot SCR Scratch / Structural Support RCV Recovery Artifact — reserved; not emitted by WASM-002 BRD Brand Manifest — reserved; not emitted by WASM-002 LCK Suitcase Lock — reserved for the explicit later-V1 FINGERPRINT workflow; not emitted or maintained by ordinary WASM-002 WASM-002 emission boundary. DGN , RCV , BRD , and LCK are registered/reserved classes but are not emitted by WASM-002. Registration alone does not create a producer, serialization contract, validity contract, lifecycle, or acceptance surface. A later build that activates one of these classes must define those contracts explicitly before the class becomes emitted product behavior. The class states semantic role rather than serialization format. WIP is not an artifact class; it is the editable non-executable Work Order lifecycle state. The Flight Recorder defined by W002-STOR-012 is a derived chronological view of governed RCP artifacts and is not an additional semantic artifact class. Existing class tokens must not be silently reassigned to different meanings. A new class requires an explicit PRD revision.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-001; CP-003,CP-001 banked; CP-003 T-accepted and banked; requirement remains partial,03201870b8ec68730a0c027c572db03ccd5eeaa8; 2d06f6259de93f5beaa8eb15f8f22f171127a10e,Evidence/CP-001/CP001_GREEN2_Test_Output.txt; Evidence/CP-001/CP001_WASM_Build_Output.txt; Evidence/CP-003/CP003_Post_Format_Test_Output.txt,"CP001: bounded lexical artifact-class recognition via reserved_artifact_class(). Five native tests passed and Rust wasm32-target library built. No content/provenance/authority validation, persistence, or complete governed artifact contract implemented. CP003 adds locally verified lexical distinction between the 11 emittable-class tokens and four registered-but-not-emitted tokens; full governance/producer behavior not implemented.",Day063,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-007,Serialization is orthogonal to artifact class,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Filename extensions such as .toml , .html , .csv , .bin , and .txt describe physical serialization only and must not be used as semantic artifact classes. A governed HLP serialized as .html remains an HLP, and a governed WKO serialized as .txt remains a WKO. Any future BRD serialization must obey the same class-versus-format separation, but its format is not frozen by WASM-002.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-006,"T-ACCEPTED, BANKED; full class-specific serialization and authority contracts remain open",aff54d08dcbacaa0c54d8869749344a504c5ad61,Evidence/CP-006/CP006_RED_Test_Output.txt; Evidence/CP-006/CP006_Post_Format_Test_Output.txt; Evidence/CP-006/CP006_WASM_Build_Output.txt; Evidence/CP-006/CP006_Hash_Inventory_Verification.txt; Evidence/CP-006/CP006_Precommit_Git_Review.txt,"CP006: public ArtifactFilenameTokens and extract_artifact_filename_tokens() reuse the CP004/CP005 immutable filename validator and extract semantic_class and serialization_extension as separate borrowed lexical fields. Four new tests, total 19/19 native tests post-format; wasm32-target compilation exit 0; 20-file pre-verification SHA-256 inventory independently matched. Literal unknown class and extension values preserved without registration or approval. No class-specific extension allowlist, format contract, file contents, provenance, governed publication, trust, or authority implemented. T accepted CP006 and banked commit aff54d08dcbacaa0c54d8869749344a504c5ad61; independent Claude implementation QA remains pending. This is requirement PARTIAL, not fully closed.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-008,Namespace and class do not confer authority by themselves,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Renaming an arbitrary file to resemble a __DS__ artifact must not make it authoritative. Before treating a governed artifact as valid, Data Sculptor must validate the applicable filename grammar plus the content, provenance, fingerprint, lineage, or other evidence required by that artifact's contract. F-14/F-33 publication distinction: SCR-to-final promotion under W002-STOR-023 proves only that the artifact satisfied its class-specific publication predicate. It does not manufacture broader authority. In particular, WKO alias authority still comes from the committed WKO MAP, Store authority comes from the committed Store MAP, and CAT is orientation only. Retained SCR failure evidence remains non-authoritative, and the reserved RCV class is not emitted by WASM-002. F-26 SOURCE authority: a governed CVT is eligible as a WASM-002 SOURCE only when its exact canonical CVT identity and the publication predicate governed by W002-CONV-004 and W002-STOR-023 are satisfied. Filename resemblance, a .csv extension, or copied bytes alone do not confer CVT source authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,Cross-cutting constraint recognized in CP001/CP002 scope: filenames/classes alone convey no artifact authority. This requirement is NOT claimed implemented or touched.,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-009,Unknown and known-but-not-emitted Data Sculptor classes are preserved and reported,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"If WASM-002 encounters a syntactically valid __DS__ artifact whose three-letter semantic class is not allocated in the current registry, or whose class is a registered-but-not-emitted WASM-002 class ( DGN , RCV , BRD , or LCK ), Data Sculptor must preserve the physical file unchanged. It must not trust, execute, mutate, delete, rename, or reinterpret that file as a known emitted artifact merely because the filename has governed form. Unknown class does not mean invalid data; it means this build has no authority to interpret that class. A known-but-not-emitted class is likewise not an instruction to activate a dormant producer or lifecycle. Whenever a WASM-002 operation performs the governed Suitcase scan/enumeration relevant to such a file, the condition must be surfaced through a canonical INFO diagnostic rather than being silently ignored. INVENTORY must include the physical file under its existing metadata-only contract; if an existing classification field is rendered, an unknown class is identified as unknown/unrecognized and a known-but-not-emitted class is identified as reserved/not emitted without guessing additional semantics. F-33 adds no new Inventory schema field and does not pull the governed DIR feature into WASM-002.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-003,"T-ACCEPTED, BANKED; full preservation/INFO requirement not closed",2d06f6259de93f5beaa8eb15f8f22f171127a10e,Evidence/CP-003/CP003_Post_Format_Test_Output.txt; Evidence/CP-003/CP003_WASM_Build_Output.txt; Evidence/CP-003/CP003_Hash_Inventory_Verification.txt,"CP003: token-only Rust classify_artifact_class_token() returns registered/emittable, registered/not-emitted, unallocated, malformed-reserved, or outside-reserved disposition. Three new tests (27 cases) plus six prior regression tests passed, wasm32 compilation exit 0, 15-file historic SHA-256 inventory verified. No Suitcase scan, filesystem preservation, canonical INFO diagnostic, INVENTORY integration, full filename validity, or artifact authority implemented. RegisteredEmittable describes a class category; it does not authorize emission. Independent Claude QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-010,Namespace and class casing are canonical and exact,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor-generated names must use exact uppercase __DS__ and exact uppercase three-letter class tokens. Data Sculptor must not silently normalize variant namespace/class spellings into canonical governed artifacts. This rule applies even on case-insensitive filesystems. F-15 governed comparison rule: unless a requirement explicitly defines a different domain-specific comparison, WASM-002 semantic equality and textual reference resolution compare decoded strings by exact Unicode scalar-value sequence. Data Sculptor performs no case folding, locale folding, Unicode normalization, trimming, or host-filesystem equivalence before the comparison. Thus differently cased strings and canonically equivalent-but-differently-encoded Unicode strings remain distinct governed values. If a host filesystem cannot safely publish two physical names that the governed semantics distinguish, publication must refuse rather than merge or reinterpret the governed identities.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-007; CP-009; CP-010,"T-ACCEPTED, BANKED; exact lexical construction verified; full normative requirement remains partial; CP009 T-ACCEPTED, BANKED — pure exact-name root snapshot matching only; full requirement remains partial; CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open",3c512df519f3a2431b363e4c57dc234c02378124; dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8; b7c515faa9bd000369d7656e09437310261290ae,Evidence/CP-007/CP007_RED_Test_Output.txt; Evidence/CP-007/CP007_GREEN_Test_Output.txt; Evidence/CP-007/CP007_Post_Format_Test_Output.txt; Evidence/CP-007/CP007_WASM_Build_Output.txt; Evidence/CP-007/CP007_Hash_Inventory_Verification.txt; Evidence/CP-007/CP007_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Baseline_Test_Output.txt; Evidence/CP-009/CP009_RED_Test_Output.txt; Evidence/CP-009/CP009_GREEN_Test_Output.txt; Evidence/CP-009/CP009_Full_Regression_Test_Output.txt; Evidence/CP-009/CP009_Rustfmt_Check_Output.txt; Evidence/CP-009/CP009_Git_Whitespace_Check.txt; Evidence/CP-009/CP009_Post_Format_Test_Output.txt; Evidence/CP-009/CP009_WASM_Build_Output.txt; Evidence/CP-009/CP009_Hash_Inventory.txt; Evidence/CP-009/CP009_Hash_Inventory_Verification.txt; Evidence/CP-009/CP009_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Final_Staging_Review.txt; CP009_Git_Banking_Output.txt (separately archived post-commit evidence); Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived),"CP007: public build_immutable_artifact_filename_candidate() assembles exact class, UTC timestamp, UUID v4 and serialization extension tokens into an ordinary canonical immutable filename candidate; it delegates validation to the existing CP004/CP005 envelope validator and refuses malformed casing/identities rather than case-folding, trimming or normalizing input. Four new integration tests, total 23/23 native tests after Rustfmt; wasm32-target compilation exit 0; 21-entry SHA-256+byte inventory independently verified. Lexically valid unknown class tokens and unapproved extension tokens may be preserved as candidates; this grants no registration, serialization contract, authority, filesystem publication or content/provenance validation. The F-15 exact Unicode scalar-value semantic equality and host-filesystem collision/refusal requirements are NOT implemented. T approved and banked commit 3c512df519f3a2431b363e4c57dc234c02378124 (14 files), clean master; independent Claude adversarial implementation QA pending. Requirement remains PARTIAL, not fully closed. CP009 Day066: match_analyst_csv_root_snapshot(&str, &[RootSnapshotEntry]) -> RootSnapshotMatch applies CP008 analyst CSV candidate preflight, then exact Rust string equality (case, Unicode scalar sequence and whitespace preserved), reports no match, reported nonregular entry, ambiguous duplicate exact entries, or single caller-reported regular file. Entry origin and kind are caller assertions, not independently verified. Eight new tests; post-format full native regression 36/36; wasm32-unknown-unknown library compilation exit 0; SHA-256 inventory verified 22/22; staged whitespace exit 0; T approved and git banked 15 files, clean working tree. This is NOT actual root scanning, filesystem entry proof, browser permission, CSV/UTF-8 certification, governed CVT SOURCE eligibility or end-to-end requirement acceptance; independent Claude QA pending. CP010 Day066 also tests canonical uppercase __DS__/CVT tokens and exact lowercase .csv conversion-output extension, refusing variant prefix/class/extension spellings; existing canonical validator is reused without repair or normalization. Only lexical form is locally verified: no actual filesystem identity enforcement or publication collision handling. T accepted CP010; git b7c515faa9bd000369d7656e09437310261290ae; independent QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-011,Generated identity collisions regenerate the UUID and never overwrite,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Data Sculptor must never overwrite, rename, truncate, or mutate an existing artifact merely because a newly generated governed filename collides with it. For an ordinary immutable artifact using the governed UTC+UUID identity grammar, Data Sculptor must keep the originally established canonical UTC millisecond creation timestamp, generate a new canonical lowercase hyphenated UUID v4, reconstruct the candidate filename, and try creation again. Collision retry must not advance or falsify the artifact creation timestamp merely to obtain a different sort position. This retry may repeat until an unused valid identity is obtained. If UUID generation fails, the host cannot safely test/create the target, or another filesystem error prevents safe allocation, creation must refuse through the canonical diagnostic path rather than risk overwrite. Collision retry changes only the not-yet-created artifact's UUID. UUID is never used as a chronology field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-012,Names route; governed contents and provenance prove,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The filename must help humans and Data Sculptor identify the artifact's intended semantic role and route it to the correct validator. The artifact's governed content, lineage, receipt, fingerprint, provenance, and other required evidence establish what is actually true.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-013,Ordinary immutable governed artifacts use class → UTC millisecond → UUID v4 identity order,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"The exact default filename grammar for an ordinary immutable Data Sculptor-governed artifact is: __DS__CCC__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.<extension> CCC is the governed semantic artifact class. YYYYMMDDTHHMMSSmmmZ is the artifact's governed UTC creation/publication timestamp at millisecond precision: four-digit year, two-digit month/day/hour/minute/second, exactly three millisecond digits, and literal T / Z . <uuid-v4> is a canonical lowercase hyphenated UUID v4. The extension is governed by the artifact's serialization contract. The token order is normative: namespace, semantic class, UTC timestamp, UUID, extension. UTC precedes UUID for every ordinary immutable class. Canonical UTC tokens with different values sort chronologically within the same class. UUID provides uniqueness and physical identity only; it must not be interpreted as a chronology tie-breaker when two artifacts share the same timestamp. When one governed all-or-refuse Store-state publication transaction creates multiple new analytical state artifacts, Data Sculptor establishes one canonical UTC millisecond publication-transaction timestamp before final identity allocation and uses that same UTC token for every newly published RID , COL , and MAP artifact created by that transaction. Each artifact receives its own UUID. Thus a first Store materialization gives the new RID, every newly materialized COL, and the successor MAP one shared transaction UTC; a later materialization gives only its newly created COL artifacts and successor MAP the new transaction UTC while the inherited RID and inherited COL artifacts retain their earlier identities. The shared transaction UTC is not the Work Order's authoring timestamp and does not require the Receipt filename UTC to match. RCP remains governed by W002-RCP-002 and carries its own receipt creation/publication timestamp. A shared transaction UTC expresses common publication membership, but MAP binding—not timestamp equality—remains authoritative for Store membership/current state. Source identity, source filename, run identity, parent identity, lineage, hashes, aliases, supersession, column identity, and other relationships must not be appended as ordinary identity tokens merely to make the filename descriptive; those facts belong in governed metadata and provenance. P2-03 successor-state UTC rule: when an operation will publish a successor Store MAP or successor WKO MAP, the transaction UTC remains a truthful observation of host UTC and must be strictly greater than the applicable chronology predecessor MAP UTC. Data Sculptor must not synthesize, increment, round forward, or otherwise fabricate a later UTC merely to satisfy chronology. UUID remains identity only and is never a chronology tie-breaker. The first MAP in a genuinely new Store lineage, and the first WKO MAP when no structurally valid WKO MAP exists, has no chronology predecessor and therefore uses the observed host UTC normally.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Immutable filename envelope, UTC and UUID syntax only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. Full requirement also governs true UTC millisecond identity, creation chronology, publication timestamp sharing, UUID identity semantics, and successor MAP chronology; none are implemented in CP004. Independent QA pending. CP005: CP005 now validates the timestamp token as a real Gregorian calendar date and ordinary UTC clock time (four-digit years 0001–9999, leap years, month lengths, 00–23 hours, 00–59 minutes/seconds, millisecond precision preserved lexically). Actual UTC issuance/publication, timestamp allocation, chronological truth, common transaction timestamp and identity authority are not implemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-STOR-014,Store-state publication transactions share UTC but never UUID identity,PB-STOR,PB-STOR,WASM-002,UNDER REVIEW,—,"Within one all-or-refuse Store-state publication transaction, every newly created RID , COL , and MAP final identity must carry the exact same canonical UTC millisecond transaction token and a distinct canonical UUID v4. UUID collision retry under PB-STOR-011 changes only the affected not-yet-created artifact UUID; it must not advance or alter the shared transaction UTC. Artifacts merely inherited or referenced by the transaction are not renamed, retimestamped, or assigned replacement UUIDs. A valid MAP may therefore bind artifacts created under several earlier transaction timestamps. Timestamp equality is evidence that artifacts were newly published by the same transaction; timestamp inequality is not evidence that artifacts belong to different Stores. P2-03 publication guard: for a successor Store-state transaction, the shared transaction UTC is established from truthful observed host UTC and is checked against the Store lineage's chronology predecessor before any newly created RID/COL/MAP artifact is promoted into its final governed class. If the observed transaction UTC is less than or equal to the chronology predecessor UTC, the publication refuses; the prior current MAP remains authoritative and no successor Store state commits.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-OPS-001,Permanent row identity after materialization,PB-OPS,PB-OPS,WASM-002,UNDER REVIEW,—,"Each logical Store has exactly one visible, deterministic RID artifact representing 1..N in governed logical CSV-record order. The header is excluded. Physical line count is not row identity: embedded newlines inside quoted fields remain inside one logical record. The RID is created when the first successful materialization establishes the Store and remains stable for the life of that Store. Every same-Store materialized or later aligned result column must contain exactly N data records in the same RID order. Multiple Stores may coexist in one Suitcase, and their RID values are unrelated; the meaningful row identity is therefore the pair (Store, RID) .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
PB-OPS-002,Materialized columns preserve facts and alignment,PB-OPS,PB-OPS,WASM-002,UNDER REVIEW,—,Materialized columns preserve governed values in permanent row alignment. Materialization stores facts for reuse; it does not decide which rows are analytically interesting.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001,Flat Project Suitcase,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,The durable WASM-002 project model must not require semantic per-store subfolders. A logical store is represented by governed relationships among artifacts and metadata inside a flat project folder.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.1,The flat model must remain usable through ordinary filesystem tools.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.2,Native and browser hosts must use the same logical storage semantics even when their filesystem APIs differ.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-001.3,Folder placement must not be treated as the authoritative meaning of an artifact.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-002,Reserved Core namespace and sorting,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Every Data Sculptor Core-managed artifact must use the reserved __DS__ prefix. The prefix is deliberately visually distinctive and mechanically simple so Core artifacts cluster together under ordinary filename sorting in a mixed flat folder.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003,Three-character base-26 artifact class,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The class token must be exactly three uppercase ASCII letters A through Z, giving the fixed physical range AAA through ZZZ, and must immediately follow the reserved namespace within the frozen filename grammar.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.1,The three-character alphabetic class rule supersedes every earlier numeric class example.,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.2,"Class ordering is positional base-26 using the alphabet A through Z: AAA, AAB, AAC, ... AAZ, ABA, ... ZZZ.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Ordinary lexical filename sorting therefore preserves the governed class order.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.3,"The namespace contains 26 cubed, or 17,576, possible class values while preserving one fixed-width token.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.4,Unallocated class tokens remain unassigned until explicitly allocated,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"WASM-002 does not reserve semantic meaning by numeric interval, lexical neighborhood, or implied class range. Any syntactically possible three-letter token that is not listed in the governed registry is unassigned for this build. A future artifact class may be allocated only by explicit PRD revision. Existing class meanings must never be shifted, renumbered, or reassigned merely to make room for later families.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-003.5,The WASM-002 artifact-class table is frozen by the governed registry,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The exact WASM-002 artifact-class table is the registry in PB-STOR-006. It is no longer a separate open storage freeze item. No additional reserved class ranges are defined by WASM-002. DGN , RCV , BRD , and LCK remain registered/reserved but are not emitted by WASM-002. Their presence in the registry does not create a WASM-002 producer, serialization contract, validity contract, lifecycle, or acceptance surface. Independent adversarial review must verify that every WASM-002-generated governed artifact uses a listed class that this build actually emits, that WIP remains a lifecycle state rather than a class, and that unknown/unallocated classes plus known-but-not-emitted classes are preserved and reported under PB-STOR-009 rather than silently interpreted or activated.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-004,Canonical Core filename envelope,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The default Core physical naming model for immutable governed artifacts is __DS__<CLASS>__<UTC>__<UUID>.<ext> . CLASS, UTC, and UUID are governed identity tokens. Human semantic labels are excluded from the physical identity envelope. A separately frozen artifact contract may define a well-known current-state singleton filename when that artifact must be updated in place and discovered by a stable name.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Default immutable filename-envelope structure only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. Singleton exception support, class-specific contracts and authority remain unimplemented. Syntactic success does not imply an authorized artifact. Independent QA pending. CP005: CP005 adds Gregorian calendar/UTC-clock validity to the already recognized immutable Core physical name. Singleton filenames, artifact-type extension rules and authorization remain unimplemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005,Canonical filename shape and fixed token lengths,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Every governed Core artifact type must have a canonical filename shape and total filename length so that a parser, browser host, native host, QA tool, or LLM can recognize malformed physical identity without interpreting variable human language. Under the Revision AH default immutable grammar, the canonical UTC token YYYYMMDDTHHMMSSmmmZ is exactly 19 ASCII characters and the canonical lowercase hyphenated UUID v4 token is exactly 36 ASCII characters. Class precedes UTC and UTC precedes UUID.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-004; CP-005,"CP004 and CP005 T-ACCEPTED, BANKED; full normative requirement remains partial",12c02a0f2ff51fae72599adc09332f50fed62ce8; cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,Evidence/CP-004/CP004_RED_Test_Output.txt; Evidence/CP-004/CP004_Post_Format_Test_Output.txt; Evidence/CP-004/CP004_WASM_Build_Output.txt; Evidence/CP-004/CP004_Hash_Inventory_Verification.txt; Evidence/CP-005/CP005_RED_Test_Output.txt; Evidence/CP-005/CP005_Post_Format_Test_Output.txt; Evidence/CP-005/CP005_WASM_Build_Output.txt; Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,"CP004: Fixed core lexical UTC (19 ASCII) and UUID v4 (36 ASCII) structure only. Native tests 12/12 passed; wasm32-target compilation succeeded; inventory 19/19 file hashes and sizes verified; 15 source/test/evidence files committed. No calendar validation, class/extension contract mapping, class-specific total length table, or filename publication gate is claimed. Independent QA pending. CP005: CP005 strengthens the fixed 19-ASCII-character UTC token with Gregorian calendar and UTC-clock range checks. Class-specific total filename lengths, extension mapping, and publication gates remain unimplemented. Three integration tests with 40 timestamp cases and 12 prior regressions: 15/15 native tests PASS after Rustfmt; wasm32 compile PASS; 19/19 SHA-256+byte integrity PASS; 14 files committed. UTC leap-second 60 rejection is PROVISIONAL implementation assumption requiring QA/spec clarification; no browser runtime demonstrated. Independent Claude implementation QA pending.",Day065,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.1,"If an artifact class has exactly one governed representation, all filenames in that class have one frozen total length.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.2,"If a future class permits more than one representation, each class/representation pair must still have a frozen total length.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-005.3,"Friendly store names, column names, aliases, and operation descriptions must never stretch or shorten a Core physical filename.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-006,Physical identity versus integrity,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,UUID identifies the governed artifact instance. SHA-256 records or verifies the exact bytes. The system must not overload one field to serve both identity and integrity.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007,Collision handling,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,Physical filename collisions are expected to be rare but must be handled explicitly. Data Sculptor must never silently overwrite an existing governed artifact because a generated physical name already exists.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.1,"Before durable creation, the host must check whether the target physical name already exists.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.2,"On a UUID collision, the existing artifact is preserved and a fresh UUID is generated under the same relevant UTC/class context unless a later frozen rule requires a different deterministic response.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-007.3,Collision handling must be visible in the run Receipt/evidence when it occurs,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If governed identity allocation encounters one or more filename collisions before successfully allocating a non-colliding UUID identity, the canonical run Receipt must record that a collision retry occurred and the number of retries when the run reaches receipt publication. If identity allocation ultimately refuses, the refusal Receipt and diagnostic evidence must preserve the collision-failure fact without overwriting or mutating any pre-existing artifact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-008,Analyst-owned files remain analyst-owned,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Source files and analyst documents may retain their original filenames. Data Sculptor must not rename every input merely to fit the governed __DS__ namespace. For an ordinary WASM-002 analytical run, continuity between certification and materialization is established by the run-local source-binding contract, not by pretending a mutable source filename is permanent byte identity. Durable cross-run exact-byte verification requires separately governed integrity evidence such as the later V1 FINGERPRINT operation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-009,Store MAP as machine truth,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The Store MAP must provide the machine-readable relationship between governed physical artifacts and their logical meaning, including the fields required by the frozen schema for store identity, column identity, source reference/binding, run/materialization identity, row counts, status, lineage, supersession, and related provenance. Cryptographic hashes are recorded when a requirement or explicit operation actually produces them; the Store MAP contract must not imply that every source or artifact is automatically hashed during ordinary WASM-002 execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010,Aliases provide human orientation without a separate Store Index,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, human-facing orientation is provided by aliases exposed from governed Store MAP state and related governed artifacts. Aliases may help analysts navigate by meaning while preserving exact physical identities. WASM-002 does not publish or maintain a separate Store Index artifact. Richer directory/index presentation is carried by the governed DIR surface in WASM-003.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010.1,WASM-002 Store MAP profile is the unified Store metadata snapshot,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, the Store MAP profile of the governed MAP artifact class is the Store metadata snapshot. It records the Store's human-facing alias, Store-establishing source filename, exact RID artifact binding, RID alias, and the complete current materialized-column mappings and aliases governed by W002-STOR-019 through W002-STOR-019.12. WASM-002 must not create a second hidden or separately named Store-metadata file merely to bind the Store to its RID or aliases. The visible immutable __DS__MAP__...csv artifact is the authoritative governed Store MAP for this build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-010.2,"Changing a friendly alias must not change physical identity, hashes, lineage, or historical provenance.",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-011,"Store, row-universe, and future Boolean-selection-column rule",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Same-row derived columns and later aligned Boolean selection/filter columns remain within the same logical Store when row identity, row order, and cardinality are preserved. A future filter that evaluates every existing RID and writes one aligned two-valued Boolean result per RID does not by itself create a new row universe or a new logical Store. The canonical future selection tokens are 0 for FALSE and 1 for TRUE under PB-OPS-003 and PB-OPS-003.1. A new row universe is created only when a later governed operation actually changes which rows exist or their order—for example by building/exporting only selected rows, deduplicating rows, or otherwise materializing a different row set. Such an operation creates a new logical Store identity under the frozen row-identity contract. Filtering remains deferred from executable WASM-002 scope; this requirement freezes only the Store/RID compatibility rule that later filtering will rely upon.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-012,Current orientation and history are different truths,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Current Store orientation is represented by the applicable immutable MAP snapshot, while execution history is preserved by immutable RCP Receipts. For WASM-002, the Flight Recorder is the logical chronological view of published canonical RCP artifacts from actual Run invocations of saved immutable WKO Work Orders. It is not separately persisted and has no separate artifact class. Successful and refused runs contribute when Receipt publication succeeds; Receipt-publication failure is governed by W002-RCP-010 and must not be silently reconstructed as original evidence. Any Flight Recorder presentation is derived and regenerable from the authoritative Receipts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-013,Open representations,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Durable project artifacts should use documented open formats such as CSV, HTML, TXT, TOML, or other explicitly governed representations so that the Suitcase remains inspectable and portable outside Data Sculptor.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-014,LLM-readable storage grammar is a documentation principle,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The storage grammar, class table, Store MAP schema, current-state selection rule, and alias semantics must be documented clearly enough that an LLM collaborator can distinguish physical identity, logical meaning, integrity evidence, current state, and history without guessing. This is a documentation/readability principle for the Product Backlog PRD and related public product documentation. It does not create a new governed Suitcase artifact, require a new public-documentation file or publication operation, or add a separate WASM-002 acceptance deliverable beyond keeping the governing contract explicit and internally consistent.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-015,WASM-002 storage freeze status,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The current WASM-002 storage design preserves the resolved semantic artifact-class registry, canonical UTC millisecond rendering, class → UTC → UUID token order, UUID rendering/version, default immutable identity grammar, collision retry behavior, immutable one-Store-per-MAP versioning, Store-aware automatic MAP inheritance, complete-snapshot semantics, the exact eight-column Store MAP schema, deterministic Store/RID/COL alias defaults, rematerialization alias continuity, deterministic Store-MAP CSV serialization, Store-MAP eligibility/publication validation, materialization-coupled AS alias semantics, standalone alias maintenance using UPDATE ALIASES , explicit alias clearing with CLEAR ... ALIAS , deterministic default restoration with RESET ... ALIAS , exact historical Store-MAP selection using MAP ""<exact Store MAP filename>"" , canonical one-column COL serialization, the all-or-refuse materialization publication boundary, SCR -to-final-class host rename promotion, complete-set validation before promotion, new-Store RID-first promotion, inherited-RID reuse for existing-Store work, deterministic COL promotion, successor-MAP construction/validation as SCR , successor-MAP rename last as the Store-state commit point, rollback/recovery treatment for uncommitted promoted artifacts, the canonical RID CSV contract, the seven-operation Work Order execution surface, the canonical automatic TXT Receipt contract including exact WKO lineage, the Receipt-backed Flight Recorder, the governed HTML Suitcase Validation Certificate, the Work Order alias/comment contract plus WKO-MAP alias-registry profile, and the LCK reservation for explicit later-V1 FINGERPRINT evidence without automatic hashing in ordinary WASM-002. RID reconstruction/replacement is deliberately not part of the WASM-002 executable surface; RECOVER RID requirements are deferred to V1-BACKLOG. The Help-report provenance boundary is resolved: WASM-002 records governed HLP identity and lineage but does not automatically SHA-256 HLP bytes or create/refresh LCK evidence; exact-byte HLP integrity remains the later explicit FINGERPRINT/LCK workflow. Future branded Receipt rendering/Brand-Manifest integration remains outside the WASM-002 TXT-only Receipt contract. P2-04 closure: WASM-002 Store governance now has a complete two-tier artifact-validation model. Tier 1 supplies bounded Store-health checks for non-content-consuming paths; Tier 2 supplies full streaming RID/COL validation for content-consuming paths, candidate commit, and REPAIR MAP . The eight-column Store MAP remains unchanged and ordinary Store health makes no cryptographic claim of historical-byte identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-001,Every actual Run invocation of a saved WKO automatically produces one Receipt attempt,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"When the analyst invokes Run on a saved immutable WKO, Data Sculptor must automatically create one governed run-receipt attempt for that invocation. The Work Order must not require a RECEIPT , SAVE RECEIPT , or equivalent clause. An editable unsaved WIP is non-executable under the Work Order lifecycle contract and therefore cannot produce an execution Receipt. A saved WKO that is invoked and then refuses during validation or execution still has an execution outcome and must receive a refusal Receipt when receipt publication succeeds.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-002,The canonical WASM-002 Receipt is a governed TXT artifact with its own creation timestamp,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,The physical Receipt filename is: __DS__RCP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt The UTC token belongs to the Receipt artifact itself and represents the Receipt's governed creation/publication time under the canonical artifact-identity rules. It must not be copied from the authorizing WKO's filename merely to make the two filenames share a timestamp. The file is written visibly in the flat Suitcase under the governed RCP artifact class. Data Sculptor chooses the governed filename; the analyst does not supply it.,PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-014; CP-015,"CP014 T-ACCEPTED, GIT BANKED — canonical RCP TXT filename lexical recognizer only; own creation-time allocation, file emission, complete Receipt contract and publication unimplemented; CP015 T-ACCEPTED, GIT BANKED — pure lexical canonical SCR-to-RCP TXT filename-candidate pair matching only; no actual file/Receipt validation, promotion, publication or authority",f5038a183f1d3dc31b0065571bf8ac8814b5d8a9; be997dc0dbd65fc370814c4a5f2d0f1254870572,Evidence/CP-014/ZIP/CP014_RED_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_WASM_Build_Record.txt.zip; CP014_Git_Banking_Record.txt (external closeout); Evidence/CP-015/ZIP/CP015_RED_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_GREEN_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_PostAmend_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_Full_Regression_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_WASM_Build_Output.txt.zip; Evidence/CP-015/ZIP/CP015_Final_Archive_Manifest.txt.zip; CP015_PostCommit_Verification.txt (external closeout),"CP014 Day067: T-accepted, Git-banked lexical RCP .txt filename recognizer only. Pure is_canonical_rcp_filename_candidate(&str)->bool uses shared canonical envelope, rejects wrong class/extension/casing, malformed UTC/UUID, paths and whitespace. Six target GREEN passes; 64/64 native regression; Rustfmt and wasm32 library build PASS; 32 original-TXT-per-ZIP objects validated and committed unchanged. Commit f5038a183f1d3dc31b0065571bf8ac8814b5d8a9. No new Receipt timestamp generation, Receipt byte serialization, creation/promotion/publication or authority; independent implementation QA and browser runtime pending. CP015 Day067: T-approved pure is_matching_scr_rcp_filename_candidate_pair(&str,&str)->bool checks canonical SCR/RCP lowercase .txt candidates and exact timestamp/UUID pairing, reusing existing lexical recognizers and candidate derivation; rejects wrong classes/order, mismatched timestamps/UUID, paths, whitespace and noncanonical envelopes. Expected RED E0432 exit 101; six targeted GREEN PASS; T-approved formatting-only source+test amendment and recheck; full native regression 70/70 PASS, Rustfmt PASS, Rust 1.97.1 wasm32-unknown-unknown --lib compile PASS. Original TXT archived as 16 verified single-entry ZIPs; 18/18 committed Git blob identities checked; working tree clean. Banked at be997dc0dbd65fc370814c4a5f2d0f1254870572. No actual SCR/RCP file reads, Receipt content validation, timestamp generation, authority, promotion or publication; browser execution and independent implementation QA pending.",Day067,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-003,WASM-002 Receipts are TXT-only and independent of presentation state,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"For WASM-002, the canonical run Receipt is always plain TXT. Browser theme, built-in HTML presentation, Help voice, or other presentation state must not change whether the run Receipt is emitted as TXT or alter its governed facts. WASM-002 must not emit an HTML Receipt as an alternative to the canonical TXT Receipt. Configurable Brand Manifest behavior is deferred to a future build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-005,Canonical Receipt TXT serialization is deterministic,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The WASM-002 Receipt is UTF-8 without BOM and uses LF ( 0x0A ) line endings. Every Receipt ends with exactly one final LF. No serialized line carries trailing spaces, and no blank physical lines are emitted unless a later operation-specific grammar explicitly freezes them. It is a deterministic line-oriented KEY: VALUE document with a frozen core-key order followed by operation-specific fact sections in deterministic order. KEY is an uppercase ASCII field name. The separator is exactly one ASCII colon followed by exactly one ASCII space. KEY=VALUE is not valid canonical Receipt serialization. Fixed machine tokens and non-negative decimal integers are serialized unquoted. Human-authored text, filenames, aliases, headers, and other free text are serialized as double-quoted UTF-8 strings. Inside a quoted value, a literal double quote is represented by doubling it as """" . CR and LF are not permitted inside a single serialized value; each fact remains exactly one physical line. Enumerated values use the exact uppercase tokens frozen by the applicable requirement. Non-negative integers use ungrouped ASCII base-10 digits. This shared text rule is normative for all Receipt free-text values and is acceptance-tested byte-for-byte.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-016,"CP016 T-ACCEPTED, GIT BANKED — pure canonical single Receipt field-line formatting only; whole-Receipt grammar, ordering, fixed operation vocabularies, durable creation and publication NOT implemented",fde0f0a8b96c92f6cfb80b517396ff5512cccd13,Evidence/CP-016/ZIP/CP016_RED_StdErr.txt.zip; Evidence/CP-016/ZIP/CP016_GREEN_Verification_StdOut.txt.zip; Evidence/CP-016/ZIP/CP016_PostFormat_Run_Record.txt.zip; Evidence/CP-016/ZIP/CP016_PostAmendment_Regression_StdOut.txt.zip; Evidence/CP-016/ZIP/CP016_WASM_Build_Run_Record.txt.zip; Evidence/CP-016/ZIP/CP016_PreFormat_Frozen_Test.rs.zip; Evidence/CP-016/ZIP/CP016_Final_Custody_Addendum_Record.txt.zip; CP016_Git_Postcommit_Integrity_Record.txt (external closeout),"CP016 Day068: T-approved and Git banked pure serialize_canonical_receipt_field_line(key, ReceiptFieldValue) and typed MachineToken, NonNegativeInteger(u64), QuotedText values. Exactly one KEY: VALUE\n line; uppercase ASCII lexical keys and machine tokens; ungrouped decimal u64; doubled interior quote; quoted UTF-8; CR/LF rejected within values. Eight frozen tests passed, 78/78 complete native regression, rustfmt check exit 0 after separately authorized formatting-only frozen-test amendment, wasm32-unknown-unknown --lib build exit 0. 36 individually verified evidence ZIPs Git banked; 31 original TXT evidence retained untracked. No whole-Receipt assembly, full document BOM/end-of-document acceptance, operation-specific core-key ordering, semantic token vocabulary, filesystem I/O, run invocation, authority, or publication. Independent adversarial implementation QA remains NOT_REVIEWED; no complete requirement acceptance.",Day068,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-006,Every Receipt records the fixed core execution facts and exact WKO lineage,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"Every canonical WASM-002 Receipt begins with the following common envelope keys in exactly this order: RECEIPT_VERSION RECEIPT_FILENAME RECEIPT_UTC WORK_ORDER_FILENAME OPERATION RUN_STARTED_UTC RUN_FINISHED_UTC RESULT DIAGNOSTIC_ID IDENTITY_COLLISION_RETRIES Day 060 H-02 version freeze: RECEIPT_VERSION is the unquoted integer 1 for the WASM-002 Receipt contract. RECEIPT_FILENAME is the exact physical governed RCP filename. RECEIPT_UTC is exactly the canonical UTC timestamp embedded in that filename and is distinct from the run start/finish timestamps. WORK_ORDER_FILENAME is the exact physical immutable WKO identity invoked and is the authoritative WKO→RCP lineage link. Day 060 H-09 / BM-06 truthful run-timestamp semantics RUN_STARTED_UTC and RUN_FINISHED_UTC are governed truthful host-UTC observations at millisecond precision. They are not decorative labels and are not synthesized from artifact filenames. RUN_STARTED_UTC is observed only after the exact saved WKO has been resolved and found eligible to Run, and immediately before operation-specific validation/execution begins. It therefore brackets operation validation, analytical work, publication attempts, refusal processing, and any governed rollback/cleanup performed by that Run. RUN_FINISHED_UTC is observed only after the operation has reached its final SUCCESS or REFUSED analytical outcome and all non-Receipt governed effects are settled: successful artifacts are committed, refusal state is established, and required rollback/cleanup or retained non-authoritative evidence classification is complete. Receipt publication begins only after this observation. For one Run, the truthful temporal invariant is: WKO_UTC ≤ RUN_STARTED_UTC ≤ each successfully published run-artifact UTC ≤ RUN_FINISHED_UTC ≤ RECEIPT_UTC where WKO_UTC is the governed UTC token embedded in the exact WORK_ORDER_FILENAME , and “run-artifact UTC” means the governed UTC embedded in each non-Receipt artifact successfully published by that Run, including a shared materialization transaction UTC where applicable. An operation that publishes no non-Receipt artifact simply has no middle artifact-UTC comparison. Equality is permitted because the canonical timestamp precision is milliseconds. Data Sculptor must not fabricate, increment, decrement, or reorder UTC values merely to make this invariant appear true. Receipt fixtures and retained acceptance evidence must use physically possible timelines under this rule. The existing rule that WKO and Receipt filename timestamps are not required to match remains unchanged: they are distinct events, but a WKO invoked by a Run must already exist as a governed artifact before that Run begins. RESULT is a closed WASM-002 vocabulary containing exactly SUCCESS and REFUSED . No other RESULT token is valid. DIAGNOSTIC_ID: NONE is used for an ordinary successful run; a refused run carries the exact governed diagnostic identity. The shared governed absence-state vocabulary is closed to these four tokens, with these exact meanings: NONE — the fact is applicable and definitively has no value in this event; NOT_RUN — the owning stage or operation was not executed; NOT_AVAILABLE — the fact is applicable or potentially applicable, but its value could not be obtained; NOT_APPLICABLE — the fact does not apply to this event, diagnostic, operation, or artifact. These states are semantically distinct and must not be substituted for one another. A count that was actually established as zero is serialized as the integer 0 , never as an absence token. The refusal-serialization matrix for every present operation-specific key is deterministic: State of the key's owning fact/stage at refusal Required serialization The fact was authoritatively established before refusal Serialize the exact governed value. The owning stage was never entered NOT_RUN . The owning stage ran and definitively produced no value/artifact for this event NONE . The fact applies but could not be obtained NOT_AVAILABLE . The fact does not apply to this event NOT_APPLICABLE . An applicable count was authoritatively established as zero 0 . A publication identity whose publication stage was never entered NOT_RUN , except where an earlier frozen operation-specific rule explicitly fixes another token. A publication identity whose publication stage was entered but no artifact of that identity successfully published NONE . A publication identity that successfully published The exact physical governed filename. For this contract, a fact is established only when its owning validation/stage has deterministically fixed the value and later execution cannot revise that fact. Candidate allocation, partial bytes, or an uncommitted publication does not establish a published-artifact identity. If parsing/validation refuses before one of the seven governed WASM-002 operations can be identified, the Receipt uses OPERATION: UNKNOWN_OPERATION , RESULT: REFUSED , and the applicable DIAGNOSTIC_ID . After the common envelope there is no operation-specific section; the Receipt proceeds directly to CREATED_ARTIFACT_COUNT: 0 . UNKNOWN_OPERATION is not an executable operation. After all operation-specific facts and indexed lists, every Receipt ends with: CREATED_ARTIFACT_COUNT: <N>
CREATED_ARTIFACT_001: ""...""
...
CREATED_ARTIFACT_N: ""..."" The created-artifact list contains only exact physical governed filenames successfully published by the run, excluding the Receipt itself. For this accounting, an artifact is successfully published only if it remains a committed governed artifact when the Run finishes; an artifact promoted and then rolled back, or left only as non-authoritative failure residue under All-or-Refuse, is excluded from CREATED_ARTIFACT_COUNT and its indexed list. Indexed suffixes are one-based decimal with a minimum width of three digits and no maximum width: 001 through 999 are zero-padded and 1000 onward uses the ordinary full ungrouped decimal form. When a count is zero, no indexed lines for that list appear. IDENTITY_COLLISION_RETRIES is always present and is 0 when no governed filename-allocation retry occurred. Receipt/WKO filename timestamps are not required to match. One immutable WKO may be run multiple times, each producing a distinct Receipt that points back to the same exact WORK_ORDER_FILENAME . F-08 DS-STEPS / Receipt token separation. Human-authored Work Orders use the readable terminal clauses below; the Receipt serializes the corresponding machine token in OPERATION . The two columns are not interchangeable spellings: DS-STEPS terminal clause Receipt OPERATION MATERIALIZE MATERIALIZE INVENTORY INVENTORY UPDATE ALIASES UPDATE_ALIASES REPAIR MAP REPAIR_MAP REPAIR WORK ORDER REGISTRY REPAIR_WORK_ORDER_REGISTRY CONVERT WINDOWS-1252 TO UTF-8 CONVERT_WINDOWS_1252_TO_UTF_8 CATALOG STORES CATALOG_STORES For example, REPAIR_MAP is not valid DS-STEPS syntax and REPAIR MAP is not the serialized Receipt token. UNKNOWN_OPERATION remains a refusal-only Receipt value when validation cannot identify one of these seven operations; it is not an executable operation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-007,"Materialization Receipts record Store, RID, Stage 1, Stage 2, and output facts",W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"For a WASM-002 MATERIALIZE run, after the common envelope the Receipt serializes these operation-specific keys in exactly this order: SOURCE_FILENAME BASE_MAP_FILENAME RID_FILENAME RID_ACTION STAGE1_UTF8_OUTCOME CERTIFIED_SOURCE_BYTE_COUNT STAGE1_ELAPSED_MS UTF8_FIRST_INVALID_BYTE_OFFSET UTF8_STOP_REASON WINDOWS_1252_COMPATIBILITY_OUTCOME WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET STAGE2_LOGICAL_ROW_COUNT STAGE2_ELAPSED_MS CSV_REFUSAL_CONDITION CSV_SOURCE_BYTE_OFFSET CSV_PHYSICAL_LINE CSV_LOGICAL_RECORD CSV_FIELD_ORDINAL REQUESTED_COLUMN_COUNT RESOLVED_COLUMN_COUNT PUBLISHED_COL_COUNT zero or more indexed published-COL filename lines whose exact key form is PUBLISHED_COL_<INDEX>_FILENAME (for example PUBLISHED_COL_001_FILENAME , PUBLISHED_COL_002_FILENAME ) SUCCESSOR_MAP_FILENAME OPERATIONAL_NAME_FALLBACK_COUNT zero or more indexed fallback triplets: OPERATIONAL_NAME_FALLBACK_001_COLUMN_ORDINAL , OPERATIONAL_NAME_FALLBACK_001_ASSIGNED_NAME , OPERATIONAL_NAME_FALLBACK_001_REASON , continuing under the common indexed-key rule. BASE_MAP_FILENAME: NONE denotes a newly established Store with no predecessor Store MAP. Day 060 H-11 / BM-08 RID_ACTION ownership and establishment RID_ACTION is a governed execution fact describing what this Run actually established for the Store RID path. It is never an intention, plan, or prediction. RID_ACTION: REUSED is established when routing has selected an existing Store, the exact inherited RID filename is known, and that inherited RID has passed the validation required to proceed. Because the RID already exists, this fact may be established before Stage 1 or Stage 2 completes. RID_ACTION: CREATED is established only when a new-Store RID candidate has successfully completed governed promotion into its final RID identity. Merely planning, allocating, writing, closing, validating, or naming an SCR candidate does not establish CREATED . Until either of those facts is established, the common refusal matrix governs RID_ACTION . For a new-Store path that refuses before successful RID promotion, RID_ACTION is NOT_RUN . If an existing-Store route is identified but the required inherited RID fact cannot be validly established, RID_ACTION is NOT_AVAILABLE . RID_FILENAME is a separate fact: for REUSED , it is the exact already-published inherited RID filename as soon as reuse is established; for CREATED , it is the exact governed final RID filename only after successful RID promotion; before new-RID promotion succeeds, no candidate/SCR filename may be serialized as though it were a published RID. With RID_ACTION: CREATED , RID_FILENAME records the RID identity successfully promoted during the Run even if that RID is later rolled back under All-or-Refuse; rollback does not erase the already-established RID_ACTION / RID_FILENAME execution facts. The refusal-boundary matrix is therefore: Materialization state RID_ACTION RID_FILENAME Validation/routing refuses before a Store/RID path is established NOT_RUN NOT_RUN or NOT_AVAILABLE only when an applicable routing fact could not be obtained under the common matrix New Store; Stage 1 refusal NOT_RUN NOT_RUN New Store; Stage 2 refusal NOT_RUN NOT_RUN New Store; post-Stage-2 gate refusal before RID promotion NOT_RUN NOT_RUN New Store; RID candidate/promotion has not successfully completed NOT_RUN NOT_RUN New Store; RID promotion succeeds CREATED exact published RID filename Existing Store; exact inherited RID selected and validated REUSED exact inherited RID filename Existing Store; later Stage 1, Stage 2, gate, or publication refusal after reuse was established REUSED exact inherited RID filename Existing lineage identified but required inherited RID cannot be validly established NOT_AVAILABLE NOT_AVAILABLE A refusal Receipt that says RID_ACTION: CREATED while RID_FILENAME is NONE or NOT_RUN and no RID was successfully promoted is invalid evidence. STAGE1_UTF8_OUTCOME has exactly two completed Stage-1 values: PASS and FAIL . If Stage 1 never ran, the value is NOT_RUN . If Stage 1 began but a separate failure prevented a governed PASS/FAIL determination, the value is NOT_AVAILABLE . NOT_APPLICABLE is not valid for this key. UTF8_FIRST_INVALID_BYTE_OFFSET and UTF8_STOP_REASON are refusal-only Stage-1 evidence. On STAGE1_UTF8_OUTCOME: FAIL , the offset is mandatory and is the exact zero-based absolute physical source-byte offset of the first byte of the invalid sequence, and the stop reason is mandatory and exactly INVALID_UTF8_SEQUENCE . Neither field may be NOT_AVAILABLE when the Stage-1 outcome is FAIL . On PASS , both fields are NOT_APPLICABLE . If Stage 1 never ran, both are NOT_RUN . If Stage 1 began but no UTF-8 PASS/FAIL conclusion was established because of a separate failure, both refusal-only fields are NOT_APPLICABLE . WINDOWS_1252_COMPATIBILITY_OUTCOME and WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET are the governed F-16 follow-on facts. They are evaluated only after STAGE1_UTF8_OUTCOME: FAIL . When the complete second pass reaches EOF with every byte mappable, the outcome is COMPATIBLE and the offset is NOT_APPLICABLE . When the pass encounters one of the undefined bytes frozen in W002-CONV-002.4, the outcome is INCOMPATIBLE and the offset is the exact zero-based absolute physical source-byte offset of the first such byte. If the pass begins but an independent failure prevents a conclusion, both fields are NOT_AVAILABLE . If Stage 1 did not conclude FAIL , the compatibility pass does not run and both fields are NOT_RUN . The five exact CSV refusal keys CSV_REFUSAL_CONDITION , CSV_SOURCE_BYTE_OFFSET , CSV_PHYSICAL_LINE , CSV_LOGICAL_RECORD , and CSV_FIELD_ORDINAL carry the exact structural CSV refusal condition and location oracle frozen in W002-MAT-002.8. If Stage 2 never ran, all five are NOT_RUN ; if Stage 2 completed without an applicable CSV refusal, all five are NOT_APPLICABLE ; on a CSV refusal, each established location fact is serialized and any applicable fact that could not be obtained is NOT_AVAILABLE . The MATERIALIZE refusal-stage matrix is: Refusal boundary Validation/routing and request facts Stage 1 facts Stage 2 facts Publication facts Validation, before Stage 1 Serialize each fact already established; an applicable fact that validation could not obtain is NOT_AVAILABLE . REQUESTED_COLUMN_COUNT is the actual count when the KEEP list parsed completely; otherwise NOT_AVAILABLE . RESOLVED_COLUMN_COUNT and fallback records are NOT_RUN until name/ordinal resolution has run. NOT_RUN for all Stage 1-owned facts. NOT_RUN for all Stage 2-owned facts. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Stage 1 refusal Established validation/routing facts are exact values. Serialize the exact Stage 1 outcome/timing and established refusal evidence; incomplete applicable facts are NOT_AVAILABLE . The Windows-1252 compatibility fields then serialize the exact complete assessment result under the rule above; if an independent assessment failure prevents a conclusion, they are NOT_AVAILABLE . NOT_RUN for all Stage 2-owned facts. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Stage 2 refusal Established validation/routing facts are exact values. Completed Stage 1 facts are exact values; UTF-8 refusal fields are NOT_APPLICABLE when no UTF-8 refusal occurred. Because Stage 1 passed, both Windows-1252 compatibility fields are NOT_RUN . STAGE2_ELAPSED_MS is the actual elapsed time when obtained; STAGE2_LOGICAL_ROW_COUNT is NOT_AVAILABLE unless the complete accepted logical row count was established; CSV refusal facts follow the rule above. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Post-Stage-2 gate refusal before publication All facts established through the gate are serialized exactly; non-applicable UTF-8/CSV refusal fields are NOT_APPLICABLE . Both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. PUBLISHED_COL_COUNT: 0 ; no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN . Publication refusal before the successor-MAP publication stage is entered All facts established before refusal are serialized exactly. This row includes a new-Store RID/COL identity-allocation or promotion refusal that occurs before the successor-MAP publication stage is entered. Completed Stage 1 and Stage 2 facts remain exact; non-applicable UTF-8/CSV refusal fields use their governed absence tokens, and both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. Under All-or-Refuse publication, PUBLISHED_COL_COUNT: 0 and no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NOT_RUN because the successor-MAP publication stage was never entered. A candidate filename is never serialized as a published identity. Publication refusal after the successor-MAP publication stage is entered All facts established before refusal are serialized exactly. Any RID fact already established before this later refusal remains governed by the RID_ACTION/RID_FILENAME matrix above. Completed Stage 1 and Stage 2 facts remain exact; non-applicable UTF-8/CSV refusal fields use their governed absence tokens, and both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. Under All-or-Refuse publication, PUBLISHED_COL_COUNT: 0 and no indexed published-COL filename lines; SUCCESSOR_MAP_FILENAME: NONE because the successor-MAP publication stage was entered but no successor MAP successfully published. A candidate filename is never serialized as a published identity. Success All applicable facts are exact values; refusal-only UTF-8/CSV fields are NOT_APPLICABLE . Both Windows-1252 compatibility fields are NOT_RUN because Stage 1 passed. PUBLISHED_COL_COUNT is the actual count; indexed keys are exactly PUBLISHED_COL_001_FILENAME onward in resolved KEEP order; SUCCESSOR_MAP_FILENAME is the exact published successor MAP filename. Day 060 H-24 / BM-08 publication-boundary split: these two MATERIALIZE publication-refusal rows apply the common W002-RCP-006 ownership rule to the successor-MAP publication stage. NOT_RUN means that stage was never entered; NONE means it was entered but no successor MAP successfully published. The early boundary is exercised by the RID identity-allocation exhaustion fixture; the later boundary has its own byte-exact golden fixture. OPERATIONAL_NAME_FALLBACK_COUNT is NOT_RUN until operational-name resolution has run; afterward it is the established non-negative count, including literal 0 . Fallback records are ordered by ascending physical source-column ordinal. the exact fallback key OPERATIONAL_NAME_FALLBACK_<INDEX>_REASON is exactly SOURCE_HEADER_EXCEEDS_1024_SCALARS . For successful Store-establishing materialization, the common created-artifact list is ordered RID first, newly published COLs in resolved KEEP order, then successor MAP. For successful existing-Store materialization, the inherited RID is not newly created; the list contains newly published COLs in resolved KEEP order followed by the successor MAP. P3-09 Receipt oracle: when Stage 2 refuses because the certified source contains no logical CSV record, the five CSV refusal fields must serialize exactly as CSV_REFUSAL_CONDITION: NO_HEADER_RECORD , CSV_SOURCE_BYTE_OFFSET: <exact source byte length> , CSV_PHYSICAL_LINE: 1 , CSV_LOGICAL_RECORD: 1 , and CSV_FIELD_ORDINAL: 1 . Day 060 H-13 / BM-10 clarification: within those five governed CSV refusal fields, the zero-byte and UTF-8-BOM-only cases differ only in CSV_SOURCE_BYTE_OFFSET : 0 versus 3 . Their complete Receipt bytes also differ wherever the underlying source identity, certified source byte count, Work Order identity, run/Receipt timestamps, Receipt filename/UUID, or other fixture-specific governed facts differ. The complete Receipts must never be described as differing only by one field. F-20 operational-name Receipt oracle: OPERATIONAL_NAME_FALLBACK_COUNT counts selected/materialized columns whose exact source header exceeded 1,024 Unicode scalar values. Each corresponding ..._ASSIGNED_NAME stores the final deterministic operational/default-alias name after any permitted fallback collision disambiguation; ..._REASON remains exactly SOURCE_HEADER_EXCEEDS_1024_SCALARS . The Receipt does not copy the oversized exact source header merely to explain the fallback. The common indexed-key rule from W002-RCP-006 applies without a maximum width. A full-width KEEP is therefore representable through PUBLISHED_COL_16384_FILENAME (and corresponding fallback indexes when applicable); the three-digit examples are a minimum-width convention, not a 999-item ceiling.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-008,Other WASM-002 operations add deterministic operation-specific Receipt facts,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The same common envelope, closed RESULT/absence vocabulary, refusal matrix, created-artifact tail, and indexed-key rule apply to the other executable WASM-002 operations. Their operation-specific key tables are closed as follows. INVENTORY INVENTORY_FILENAME INVENTORY_ENTRY_COUNT Refusal boundary INVENTORY_ENTRY_COUNT INVENTORY_FILENAME Validation before inventory scan NOT_RUN NOT_RUN Inventory scan/measurement refusal Exact count if the complete count was established; otherwise NOT_AVAILABLE NOT_RUN Publication refusal after the snapshot facts were established Exact established count, including 0 NONE Success Exact established count Exact physical published INV filename UPDATE_ALIASES BASE_MAP_FILENAME SUCCESSOR_MAP_FILENAME Refusal boundary BASE_MAP_FILENAME SUCCESSOR_MAP_FILENAME Validation/routing before an exact base MAP is established NOT_AVAILABLE NOT_RUN Validation/gate refusal after the exact base MAP is established Exact base MAP filename NOT_RUN Publication refusal Exact base MAP filename NONE Success Exact base MAP filename Exact published successor MAP filename REPAIR_MAP TARGET_MAP_FILENAME RID_FILENAME BROKEN_COL_COUNT zero or more indexed broken-COL filename lines using exact key form BROKEN_COL_<INDEX>_FILENAME (for example BROKEN_COL_001_FILENAME , BROKEN_COL_002_FILENAME ) RETAINED_COL_COUNT SUCCESSOR_MAP_FILENAME Broken COL filenames are ordered by ascending exact UTF-8 filename bytes. RETAINED_COL_COUNT is the actual count once repair analysis completes, including literal 0 . Refusal boundary Target/RID facts Broken/retained facts SUCCESSOR_MAP_FILENAME Validation before an exact target MAP/RID is established Established facts are exact; otherwise NOT_AVAILABLE NOT_RUN NOT_RUN Repair-analysis refusal before a repair result is established Exact established values Exact values if established; otherwise the applicable unavailable/not-run token from the common matrix NOT_RUN All-COLs-broken refusal frozen under F-03/F-09 Exact values Exact broken count/list; RETAINED_COL_COUNT: 0 NONE — this earlier frozen named refusal remains an explicit operation-specific exception. Publication refusal Exact values Exact repair-analysis values NONE Success Exact values Exact repair-analysis values Exact published successor MAP filename REPAIR_WORK_ORDER_REGISTRY BASE_WKO_MAP_FILENAME REMOVED_STALE_ROW_COUNT zero or more indexed stale-WKO filename lines using exact key form REMOVED_STALE_WKO_<INDEX>_FILENAME (for example REMOVED_STALE_WKO_001_FILENAME , REMOVED_STALE_WKO_002_FILENAME ) REGISTERED_CURRENT_COUNT zero or more indexed current-WKO filename lines using exact key form REGISTERED_CURRENT_WKO_<INDEX>_FILENAME (for example REGISTERED_CURRENT_WKO_001_FILENAME , REGISTERED_CURRENT_WKO_002_FILENAME ) REGISTERED_DEPRECATED_COUNT zero or more indexed deprecated-WKO filename lines using exact key form REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME (for example REGISTERED_DEPRECATED_WKO_001_FILENAME , REGISTERED_DEPRECATED_WKO_002_FILENAME ) SUCCESSOR_WKO_MAP_FILENAME Each filename list is independently sorted by ascending exact UTF-8 filename bytes. If the bootstrap repair WKO is newly discovered and registered, it appears in the appropriate registered list under W002-STOR-018.3 and W002-STOR-018.4. Day 060 H-10 / BM-07 count semantics: REGISTERED_CURRENT_COUNT and REGISTERED_DEPRECATED_COUNT count only previously unregistered structurally valid WKOs that this repair Run newly adds to the successor WKO MAP with the stated status. They do not count surviving pre-existing rows already present in the base registry. The indexed filename lines list exactly the corresponding newly registered WKOs and no others. If the bootstrap repair WKO is one of those newly registered WKOs, it must appear in exactly one registered list. A successful repair Receipt that omits a newly registered bootstrap repair WKO is invalid evidence. Refusal boundary Base registry Repair-plan counts/lists SUCCESSOR_WKO_MAP_FILENAME Validation before the current structurally valid WKO MAP is established NOT_AVAILABLE NOT_RUN NOT_RUN Repair-analysis/gate refusal Exact base WKO MAP filename Exact values if the repair plan was established; otherwise the common matrix governs each present field NOT_RUN Publication refusal Exact base WKO MAP filename Exact established repair-plan values NONE Success Exact base WKO MAP filename Exact established repair-plan values Exact published successor WKO MAP filename CONVERT_WINDOWS_1252_TO_UTF_8 SOURCE_FILENAME SOURCE_ENCODING UNDEFINED_WINDOWS_1252_BYTE_OFFSET MATERIALIZED_ENCODING TRANSCODING SOURCE_CHANGED OUTPUT_FILENAME UNDEFINED_WINDOWS_1252_BYTE_OFFSET is the zero-based absolute physical source-byte offset of the first byte undefined by the frozen Windows-1252 mapping when that refusal occurs. If the compatibility stage never ran it is NOT_RUN ; if the stage ran and no undefined-byte refusal occurred it is NOT_APPLICABLE ; if the fact applies but could not be obtained it is NOT_AVAILABLE . Day 060 H-14 / BM-11 undefined-Windows-1252-byte refusal oracle For CONVERT WINDOWS-1252 TO UTF-8 , an undefined Windows-1252 byte is detected during the complete pre-transcoding compatibility assessment . Transcoding has not begun when this refusal is established. When the complete compatibility assessment encounters the first undefined byte, the Receipt must serialize these exact operation facts: SOURCE_ENCODING: WINDOWS-1252-INCOMPATIBLE
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: <exact zero-based absolute physical source-byte offset>
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE WINDOWS-1252-INCOMPATIBLE is the exact SOURCE_ENCODING token for this governed CONVERT refusal. OUTPUT_FILENAME: NONE means the operation definitively established that no CVT was published for the event. No CVT candidate may be reported as output. The compatibility scan reports the first undefined byte only. Later undefined bytes do not replace that offset. Permitted changes in scan buffer/window size or boundary placement must not change the reported absolute offset. Day 060 H-25 / BM-04 already-valid-UTF-8 refusal oracle. If the complete bound source passes strict UTF-8 validation, CONVERT refuses as unnecessary before Windows-1252 compatibility assessment or transcoding. The Receipt must serialize these exact operation facts: SOURCE_ENCODING: UTF-8
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: NOT_RUN
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE UTF-8 is the exact SOURCE_ENCODING token for this governed refusal. OUTPUT_FILENAME: NONE means the classification gate definitively established that this event publishes no CVT. The Windows-1252 compatibility stage is not entered. Refusal boundary Source/classification facts Conversion facts OUTPUT_FILENAME Validation/classification refusal before conversion begins Serialize each fact already established; an applicable fact that could not be obtained is NOT_AVAILABLE . The undefined-byte offset follows the rule above. MATERIALIZED_ENCODING and TRANSCODING are NOT_RUN when conversion did not run. SOURCE_CHANGED is the exact governed value once established. NONE only for either of the two definitively classified no-CVT cases: (1) the complete source is already valid strict UTF-8 and conversion is unnecessary; or (2) the complete Windows-1252 compatibility assessment finds an undefined byte. For other validation/classification refusals before conversion begins, OUTPUT_FILENAME: NOT_RUN unless another normative rule explicitly assigns a different closed token. Conversion/refusal after bounded transcoding begins but before publication Exact established source/classification facts Serialize exact established conversion facts; applicable incomplete facts use NOT_AVAILABLE . NOT_RUN Publication refusal Exact established facts Exact established conversion facts NONE Success SOURCE_ENCODING: WINDOWS-1252-COMPATIBLE ; undefined-byte offset NOT_APPLICABLE MATERIALIZED_ENCODING: UTF-8 ; TRANSCODING: BOUNDED_STREAMING ; SOURCE_CHANGED: NO Exact published CVT filename CATALOG_STORES CATALOG_ENTRY_COUNT CATALOG_FILENAME Refusal boundary CATALOG_ENTRY_COUNT CATALOG_FILENAME Validation/discovery refusal before the complete authoritative catalog row set is established NOT_AVAILABLE NOT_RUN Publication refusal after the complete catalog row set is established Exact established count, including 0 NONE Success Exact established count Exact physical published CAT filename On success, CATALOG_ENTRY_COUNT equals the number of data rows in the published CAT. CAT itself is the only new non-Receipt governed artifact produced by the operation. RECOVER RID / RECOVER_RID is not a valid executable WASM-002 operation in Revision BM.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-009,"Receipt truth is execution evidence, not presentation authority",W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"The Receipt records what Data Sculptor actually attempted, observed, refused, and successfully published. It must not reinterpret the analyst's WKO, replace the Store MAP, or become a second analytical command surface. The WKO remains the durable authorization record; Store MAP/RID/COL artifacts remain the governed analytical state; diagnostic events remain the refusal/help truth; the Receipt cross-references those facts as the durable run ledger. The body of published canonical RCP artifacts is the authoritative evidence substrate for the Flight Recorder logical view defined in W002-STOR-012.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-010,Receipt-publication failure is itself a governed evidence failure,W002-RCP,W002-RCP,WASM-002,UNDER REVIEW,—,"Data Sculptor must never claim that a durable Receipt exists until the RCP file has been successfully written and closed in the Suitcase. If host or filesystem failure prevents Receipt publication, the browser must surface a canonical diagnostic through the Help Engine stating that receipt evidence could not be persisted. A receipt-publication failure does not retroactively falsify analytical artifacts that were already successfully committed under their own publication contracts, but the user-facing run summary must clearly distinguish analytical outcome from receipt-persistence failure. Data Sculptor must not invent, backdate, or silently reconstruct a Receipt and present it as the original run artifact. F-14 publication path, reconciled by F-33: the RCP itself is first written as the corresponding SCR candidate under W002-STOR-023.1, closed, reopened and validated against the exact Receipt serialization/key contract before the class-token rename to RCP . If final RCP promotion fails, the candidate remains non-authoritative SCR evidence. Help may identify the exact retained SCR filename when that fact was established, but it must still state that the canonical Receipt was not persisted. WASM-002 does not emit an RCV artifact for this failure.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-001,Successful materialization Receipt and WKO-lineage acceptance,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,"A Store-establishing materialization fixture must run one saved WKO, publish exactly one canonical TXT RCP, and prove that the Receipt identifies the exact WKO through WORK_ORDER_FILENAME , source, RID_ACTION: CREATED , new RID, Stage 1 result/bytes/time, Stage 2 row count/time, all requested COL artifacts in resolved KEEP order, successor Store MAP, published-artifact count, timestamps, and RESULT: SUCCESS . The RCP filename UTC must represent the Receipt artifact's own creation/publication event and must not be required to equal the WKO filename UTC. The same immutable WKO must then be executable again in an appropriate fixture, producing a second distinct RCP with its own Receipt/run timestamps while both Receipts contain the same exact WORK_ORDER_FILENAME . A later same-Store materialization fixture must additionally prove RID_ACTION: REUSED and the original RID filename. The Store-establishing fixture must also prove that the newly created RID, every newly created COL, and the successor MAP carry one identical publication-transaction UTC token while each has a distinct UUID; the RCP filename UTC remains its own Receipt publication timestamp and is not required to equal that analytical transaction UTC. A later same-Store materialization must prove that newly created COLs and its successor MAP share the later transaction UTC while the inherited RID retains its original timestamp/UUID. F-07 Stage-1 success fixture: a successful materialization Receipt must serialize STAGE1_UTF8_OUTCOME: PASS , with UTF8_FIRST_INVALID_BYTE_OFFSET: NOT_APPLICABLE and UTF8_STOP_REASON: NOT_APPLICABLE . Separate refusal fixtures under W002-RCP-ACC-002 must prove FAIL plus the mandatory exact offset and INVALID_UTF8_SEQUENCE . F-20 maximum-width Receipt acceptance: a successful full-width materialization fixture must prove that published-COL indexed keys continue through PUBLISHED_COL_16384_FILENAME using the minimum-three-digit/no-maximum suffix rule. Oversized-header fixtures must prove the exact fallback count, source ordinal, assigned operational name, and SOURCE_HEADER_EXCEEDS_1024_SCALARS reason without embedding the oversized source-header text in the Receipt merely as fallback evidence. F-23 additional successful-Receipt coverage: acceptance must include a successful INVENTORY run whose RCP carries the exact governed INVENTORY operation-specific facts and a successful UPDATE_ALIASES run whose RCP carries the exact BASE_MAP_FILENAME and SUCCESSOR_MAP_FILENAME while reporting only actually published artifacts in the common created-artifact tail. F-23 UUID-collision seam: using a controlled UUID sequence, acceptance must force one or more governed filename collisions before successful allocation. Every pre-existing colliding artifact must remain byte-for-byte unchanged; allocation must retain the originally established governed UTC context while changing only the not-yet-created UUID as permitted; and the published Receipt must report the exact retry count in IDENTITY_COLLISION_RETRIES . Day 060 H-09 success-timeline acceptance Every retained successful Receipt fixture must satisfy the W002-RCP-006 temporal invariant using its actual embedded UTC tokens. Acceptance must mechanically prove: the invoked WKO UTC is less than or equal to RUN_STARTED_UTC ; every non-Receipt governed artifact successfully published by that Run has a governed artifact/transaction UTC between RUN_STARTED_UTC and RUN_FINISHED_UTC , inclusive; RUN_FINISHED_UTC is less than or equal to the Receipt filename/ RECEIPT_UTC ; and no fixture relies on an artifact timestamp that occurs after the Receipt that claims it, or before the Run that created it. A controlled-clock acceptance seam may be used to make equality and strict-order cases deterministic, but the fixture generator must not alter timestamps after the fact merely to satisfy the checker. Day 060 H-11 successful RID_ACTION acceptance A successful new-Store materialization Receipt may report RID_ACTION: CREATED only because the RID was actually promoted into its final governed RID identity during that Run. A successful existing-Store materialization Receipt reports RID_ACTION: REUSED and the exact inherited RID filename; no new RID candidate is created for that Run.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-002,Refusal Receipt acceptance,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,"A saved WKO that is actually Run and deterministically refuses must still produce one canonical TXT Receipt when Receipt publication itself remains available. The emitted bytes must conform to the closed RESULT vocabulary, the four governed absence tokens, the exact operation-specific key spelling/order, and the refusal matrix in W002-RCP-006 through W002-RCP-008. Acceptance must include byte-exact golden Receipt fixtures for every distinct refusal-boundary row required to exercise the serialization matrix for each of the seven executable WASM-002 operations: MATERIALIZE , INVENTORY , UPDATE_ALIASES , REPAIR_MAP , REPAIR_WORK_ORDER_REGISTRY , CONVERT_WINDOWS_1252_TO_UTF_8 , and CATALOG_STORES . Multiple Diagnostic IDs that map to the same refusal boundary and the same serialization row do not require duplicate byte fixtures merely because the Diagnostic ID differs. Acceptance must additionally include one byte-exact UNKNOWN_OPERATION refusal fixture proving the common envelope, OPERATION: UNKNOWN_OPERATION , RESULT: REFUSED , the exact diagnostic ID, absence of any operation-specific section, and immediate CREATED_ARTIFACT_COUNT: 0 . Fixtures must prove that NONE , NOT_RUN , NOT_AVAILABLE , and NOT_APPLICABLE retain distinct meanings; an established zero count is serialized as 0 ; no candidate filename is reported as a published identity; and every indexed key uses its complete frozen name and the minimum-three-digit/no-maximum suffix rule. An unsaved WIP must be proven unable to Run and therefore must not create an execution Receipt. F-16 materialization-refusal fixtures: byte-exact MATERIALIZE refusal Receipts must exercise the new compatibility pair in all four applicable states: NOT_RUN when Stage 1 did not fail; COMPATIBLE plus NOT_APPLICABLE offset; INCOMPATIBLE plus the exact first undefined-byte offset; and NOT_AVAILABLE / NOT_AVAILABLE when an independent compatibility-read failure prevents a conclusion. F-23 Receipt-publication failure fixture, reconciled by F-33: a controlled filesystem-fault seam must make canonical RCP publication fail after the underlying analytical/refusal outcome has been established. Acceptance must prove the W002-RCP-010 boundary exactly: no final RCP is fabricated or claimed, any retained candidate evidence follows the governed SCR retention/non-authority rules in W002-STOR-023.1, no RCV artifact is emitted, the user-facing diagnostic distinguishes analytical outcome from Receipt-persistence failure, and already committed analytical artifacts are not retroactively falsified solely because RCP persistence failed. F-23 ultimate identity-allocation failure fixture: with Receipt publication itself still available, a controlled identity-allocation seam must force a governed operation artifact to exhaust/fail safe allocation. The operation must refuse without overwriting or mutating any colliding pre-existing artifact, and the refusal Receipt/diagnostic evidence must preserve the established collision/allocation-failure facts under PB-STOR-011 and W002-STOR-007.3. Day 060 H-02 fixture binding: the retained golden corpus must use RECEIPT_VERSION: 1 and the fixture-pinned diagnostic allocations in W002-HELP-001.8. The corpus must contain one success Receipt for each of the seven executable operations, one refusal Receipt for every distinct refusal-boundary row in W002-RCP-007/W002-RCP-008, the three additional Stage-1 compatibility variants needed to cover COMPATIBLE , INCOMPATIBLE , and NOT_AVAILABLE after UTF-8 failure, and one UNKNOWN_OPERATION Receipt. Publication-refusal fixtures may use the operation-specific H-02 publication diagnostic and a non-zero IDENTITY_COLLISION_RETRIES value to satisfy the ultimate identity-allocation-failure acceptance boundary without inventing a second diagnostic solely for the same serialization row. Day 060 H-09 refusal-timeline acceptance Every retained refusal Receipt fixture must also satisfy the W002-RCP-006 temporal invariant. For a refusal with no successfully published non-Receipt artifact, acceptance proves WKO_UTC ≤ RUN_STARTED_UTC ≤ RUN_FINISHED_UTC ≤ RECEIPT_UTC . If a refusal legitimately leaves one or more successfully committed non-Receipt artifacts from an already-completed stage, each such artifact UTC must fall between Run start and Run finish and must be listed truthfully under the governing created-artifact rules. Day 060 H-11 / BM-08 RID_ACTION refusal acceptance Byte-exact MATERIALIZE refusal acceptance must distinguish new-Store and existing-Store RID paths: new-Store validation, Stage 1, Stage 2, and post-Stage-2 gate refusals before successful RID promotion serialize RID_ACTION: NOT_RUN and do not serialize a candidate as a published RID; a controlled new-Store refusal after RID promotion has successfully completed may serialize RID_ACTION: CREATED together with the exact published RID filename, but only if that RID was actually promoted and the remaining refusal/rollback evidence is truthful under the publication rules; an existing-Store refusal after the inherited RID has been selected and validated serializes RID_ACTION: REUSED and the exact inherited RID filename even when Stage 1, Stage 2, a later gate, or publication subsequently refuses; an existing lineage whose required inherited RID cannot be validly established serializes RID_ACTION: NOT_AVAILABLE and RID_FILENAME: NOT_AVAILABLE rather than claiming reuse. Acceptance must specifically reject the historical H-02 fixture pattern that reported RID_ACTION: CREATED while no RID existed and CREATED_ARTIFACT_COUNT: 0 . Day 060 H-12 H-02 publication-diagnostic scope The H-02 operation-specific publication diagnostics whose required facts are artifact_class and collision_retry_count are acceptance pins for governed filename identity-allocation collision exhaustion. They are not catch-all Diagnostic IDs for unrelated publication failures such as chronology guards, write/close/rename failures, or malformed predecessor state. Those distinct conditions use their own registry allocations; DS-UTC-001 is independently frozen for the strict monotonic-UTC guard. Day 060 H-13 / BM-10 zero-byte and BOM-only NO_HEADER_RECORD Receipt fixtures The retained golden corpus must contain two distinct byte-exact MATERIALIZE refusal Receipts for the P3-09 no-header boundary: Zero-byte source: the bound source has exact certified byte count 0 ; Stage 1 passes; Stage 2 refuses with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD ; CSV_SOURCE_BYTE_OFFSET: 0 ; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; and CSV_FIELD_ORDINAL: 1 . UTF-8-BOM-only source: the bound source consists exactly of bytes EF BB BF and has exact certified byte count 3 ; Stage 1 passes; Stage 2 refuses with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD ; CSV_SOURCE_BYTE_OFFSET: 3 ; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; and CSV_FIELD_ORDINAL: 1 . These two Receipt fixtures must carry their own truthful source filenames, Work Order identities, run timestamps, Receipt identities, and other governed facts. Only the five-field CSV refusal tuple has the narrower relationship stated in W002-RCP-007; the complete Receipt files are not otherwise required to be byte-identical. Day 060 H-14 / BM-11 CONVERT undefined-byte Receipt binding The coordinated golden Receipt corpus must include the byte-exact CONVERT_WINDOWS_1252_TO_UTF_8 refusal fixture from W002-CONV-ACC-002 using source bytes 41 81 42 . Its Receipt must carry UNDEFINED_WINDOWS_1252_BYTE_OFFSET: 1 and the exact pre-transcoding refusal values frozen in W002-RCP-008.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RCP-ACC-003,Receipt TXT is invariant to presentation state in WASM-002,W002-RCP-ACC,W002-RCP,WASM-002,UNDER REVIEW,—,The same governed run must be exercised under materially different permitted browser presentation states. In each case the run Receipt must remain an RCP TXT artifact governed by the same receipt serialization and facts. Presentation must not convert it to HTML or alter execution truth in WASM-002. This acceptance gate does not require a configurable Brand Manifest; that capability is deferred.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-001,A Suitcase may contain multiple Stores and each current Store state binds exactly one RID,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The Suitcase is a workspace and may contain zero, one, or multiple logical Stores. Every committed Store state binds exactly one governed current RID artifact. RID values are unique only within their Store row universe; they are not Suitcase-global identifiers. Ordinary same-row-universe work reuses that RID unchanged. In WASM-002, a missing, unreadable, or invalid current RID makes the Store INVALID ; no executable WASM-002 operation regenerates or substitutes that RID. Read-only Help/evidence may explain analyst-owned restoration or lineage-retirement choices, but Data Sculptor does not publish a replacement RID. The stable logical row reference in WASM-002 is conceptually (Store lineage, RID value) ; the current physical RID identity is the exact rid_filename bound by the authoritative MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-002,The Store RID is generated automatically once and reused unchanged in WASM-002,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"When the first successful materialization establishes a new Store, Data Sculptor must automatically generate that Store's initial RID artifact as part of the same Stage 2 operation and the same all-or-refuse publication boundary. The analyst does not separately request ordinary RID generation. Before the RID SCR candidate is created, Data Sculptor establishes the materialization publication-transaction UTC under PB-STOR-013/PB-STOR-014 and allocates a RID-specific UUID. The canonical RID byte stream is then written as the visible governed SCR candidate whose filename already carries that exact UTC, UUID, and .csv extension intended for the final RID identity. Requested materialized columns likewise begin as governed SCR candidates whose distinct COL-specific UUIDs are allocated before those candidates are opened under the same transaction UTC. The new RID candidate and all requested COL candidates must reach EOF, reconcile to the same accepted Store row count N, and pass their required final validation before any candidate is promoted. After complete-set validation, Data Sculptor promotes the RID candidate first by host rename that changes only the three-letter semantic class token from SCR to RID . The candidate bytes, UTC token, UUID, and .csv extension must remain unchanged across that promotion. Requested COL candidates are promoted only after RID promotion succeeds. If later promotion or successor-MAP publication prevents transaction commit, the newly promoted RID is not committed Store state merely because an RID-looking file exists; it must be rolled back where safely possible or retained as attributable recovery evidence under the materialization failure contract. A first Store-establishing materialization commits exactly one RID regardless of how many requested COLs are materialized. Later ordinary materializations and other same-row-universe WASM-002 operations must reuse that RID unchanged. They must not create a new RID candidate, regenerate, replace, renumber, or silently supersede the inherited RID. RID reconstruction/replacement is not an executable WASM-002 operation. Any future governed RID-recovery design remains deferred and must be reintroduced by an explicit later PRD freeze.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-003,RID physical identity uses the governed RID filename grammar,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The physical RID filename must be: __DS__RID__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv The filename contains governed physical identity only. A Store name or friendly analyst alias must not be inserted into, substituted for, or used to rename this immutable physical RID filename.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-004,RID is a canonical one-column CSV containing the exact sequence 1 through N,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The RID artifact must serialize as a canonical one-column UTF-8 CSV with: exactly one UTF-8 BOM at byte zero; a structural first logical record exactly N=<value> , where <value> is the canonical unsigned base-10 representation of the Store's total logical data-row count N ; uppercase N , exactly one equals sign, no spaces, no sign, no leading zeroes except the single digit 0 , and no separators or locale formatting; LF ( 0x0A ) record terminators on every supported host; exactly N data records after the header, containing the consecutive unquoted decimal integers 1 through N in order; no zero RID data value, negatives, signs, thousands separators, decimal points, exponent notation, or leading zeroes; and a final LF after the last record. For N=0 , the canonical bytes are the UTF-8 BOM followed by N=0 and LF, with no data records. The N=<value> record is structural metadata and does not consume a Store row. The governed RID artifact class/filename and Store MAP binding identify the artifact as a RID; the literal header RID is not used by the frozen WASM-002 serialization.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-005,RID cardinality and order define same-Store column alignment,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"If a Store RID contains N data records, every governed column claimed to be aligned to that Store must contain exactly N data records in the same RID order. Data Sculptor must not describe a shorter, longer, reordered, duplicated, or row-shifted column as aligned to that Store. This invariant applies to materialized source columns in WASM-002 and is the stable contract that later calculated, Boolean-selection, verification, or left-join enrichment columns may rely upon.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-006,A different row universe requires a different Store and a new RID,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,An operation that changes which rows exist or changes their governed order does not mutate the existing Store RID. It establishes a different row universe and therefore requires a new logical Store identity and a new RID artifact beginning again at 1 for that new Store. Filtering that is represented only as a same-length aligned Boolean/selection column does not itself change the row universe; building a new reduced/reordered row set later would.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-007,The Store MAP gives RID a friendly alias without changing RID identity,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"The physical RID artifact remains identified by its immutable governed filename and semantic RID class. Every valid Store MAP records that exact rid_filename and one current human-facing rid_alias . Changing the RID alias must not rename, rewrite, regenerate, or alter the meaning of the RID artifact. The same Store MAP also records the Store alias and materialized-column aliases, so the analyst-facing names and the physical Store spine remain explicitly connected in one visible governed artifact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-008,Ordinary RID generation is implicit Store infrastructure; RID reconstruction is deferred,W002-RID,W002-RID,WASM-002,UNDER REVIEW,—,"WASM-002 materialization Work Orders specify the analyst's requested source columns and aliases. They must not require or expose a separate instruction such as RID , ROW INDEX , GENERATE RID , or an equivalent switch to create the Store row spine. Initial RID generation for a new Store is mandatory engine behavior implied by successful MATERIALIZE . WASM-002 must not provide an option to disable it. When ordinary materialization extends an existing Store, the engine must recognize and reuse that Store's existing RID. If that bound RID is missing or invalid, the Store is INVALID and ordinary Store operations refuse. WASM-002 exposes no RECOVER RID executable syntax. A future explicit recovery design may be considered in V1-BACKLOG, but it is not part of this build contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-001,Canonical RID byte serialization acceptance,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"An acceptance fixture with N=5 must prove exact governed bytes equivalent to a UTF-8 BOM followed by: N=5
1
2
3
4
5 Every record uses LF termination and the file ends with a final LF. A separate N=0 fixture must prove exact bytes equivalent to UTF-8 BOM + N=0 and no data records. The N=5 fixture repeated under different permitted source-window boundaries must produce byte-identical RID content apart from the governed physical filename allocated to the artifact. Full RID validation must also prove that the declared N , the number of following data records, and the exact sequence 1..N agree.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-002,Multiple Stores in one Suitcase retain independent RID spines,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,An acceptance fixture must establish at least two Stores with different row counts in the same Suitcase and prove that each Store publishes and retains exactly one distinct governed RID artifact. RID values may overlap numerically across Stores without collision because the Store identity disambiguates them.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-003,Later same-Store materialization reuses rather than regenerates RID,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"An acceptance fixture must establish a Store with an initial materialization, record the physical RID identity and exact RID bytes, then perform a later permitted materialization that adds at least one aligned COL without changing the row universe. The later run must reference and reuse the original RID artifact; no replacement RID may be published and the original RID bytes must remain unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-RID-ACC-004,Implicit RID generation acceptance for single- and multi-column first materialization,W002-RID-ACC,W002-RID,WASM-002,UNDER REVIEW,—,"Acceptance must execute two Store-establishing Work Orders that contain no RID or row-index syntax: one requesting exactly one source column and one requesting multiple source columns. Each successfully committed run must publish exactly one governed RID artifact regardless of the number of requested COL artifacts. The fixture must prove that RID creation occurs during the same Stage 2 source-record traversal that establishes the Store row count rather than by requiring a second source pass solely to construct RID. The RID row count must reconcile exactly with every requested COL row count and the final accepted Store N. Before RID candidate creation, acceptance must prove that the publication-transaction UTC and RID-specific UUID are already established, and that the governed SCR filename carries exactly the UTC, UUID, and .csv extension intended for the final RID identity. Before complete-set validation, the RID bytes must exist only as that governed SCR candidate. Acceptance must prove that the RID candidate is promoted by host rename only after the complete RID/COL candidate set validates, that the physical-name change is exactly the class token SCR to RID , that candidate bytes/UTC/UUID/extension are unchanged across promotion, that RID promotion precedes COL promotion, and that the resulting RID is not considered committed Store membership until the successor MAP is successfully promoted and binds that exact RID filename.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-001,INVENTORY is an explicit standalone WASM-002 Work Order operation,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 form is: SUITCASE: .
WORK ORDER AS ""Inventory this Suitcase""
INVENTORY INVENTORY reads the authorized Suitcase directory metadata and creates one governed Suitcase Inventory Snapshot. It is read-only with respect to pre-existing Suitcase files. In WASM-002, an INVENTORY Work Order must not also request materialization, conversion, fingerprinting, another analytical operation, or another Work Order invocation. F-08 structure freeze: after the common SUITCASE: . / WORK ORDER AS ""..."" preamble, INVENTORY is the sole semantic operation clause and is terminal. No SOURCE , MAP , KEEP , alias mutation, conversion, repair, catalog, or composition clause is valid in the same WKO.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-002,Suitcase Inventory uses the governed INV artifact class and canonical filename grammar,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"A successful inventory produces exactly one visible flat TXT artifact whose physical filename is: __DS__INV__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt The UTC and UUID tokens follow the existing governed artifact-identity rules. Data Sculptor must not create an inventory subfolder, hidden cache copy, or alternate private persistence. F-14 publication: the INV body is produced first under the matching W002-STOR-023.1 SCR identity with the same UTC, UUID and .txt extension intended for the final INV. Publication to INV occurs only after the complete scan and deterministic INV serialization validate successfully.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-003,"The lightweight inventory records filename, exact byte length, and last-modified metadata",W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"For every regular file present in the authorized flat Suitcase root at snapshot time, the inventory must record: the exact visible filename; the exact byte length reported by the host file object; and the host/browser-reported last-modified value rendered in the canonical UTC millisecond form when available. WASM-002 must not claim access to a true file-creation timestamp. It must not infer, fabricate, or substitute a creation time from the last-modified value. If usable last-modified metadata is unavailable, the inventory must represent that fact explicitly rather than invent a timestamp. P3-10 last-modified availability test: host/browser last-modified metadata is usable only when the host supplies a finite, non-negative whole-number millisecond value that can be represented in the canonical UTC millisecond timestamp form. If that test fails, the inventory must serialize the governed unavailable value rather than infer, round, substitute, or fabricate a timestamp.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-004,INVENTORY does not read file contents or compute content hashes,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The lightweight inventory must be produced from directory enumeration and file metadata only. Data Sculptor must not open and stream the contents of each listed file merely to create the inventory, and it must not compute SHA-256 or another content fingerprint as an implicit side effect. Its cost should therefore scale primarily with the number of directory entries and metadata calls, not with the aggregate byte size of the files. A 7 GB CSV and a 7 KB CSV each contribute one metadata entry rather than requiring their contents to be read.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-005,Inventory scope is the authorized flat Suitcase root,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"WASM-002 inventories regular files and immediate child directory entries in the directory denoted by SUITCASE: . . Data Sculptor must not recursively inspect, enumerate, size, hash, or otherwise inventory the contents of a child directory in this build. Each immediate child directory is recorded as a directory entry by its exact visible name only. Its nested contents and aggregate size are outside the WASM-002 Inventory contract. This rule preserves the flat-Suitcase storage model while making the presence of user-created directories explicit rather than silently omitting them. F-26 SOURCE distinction: inclusion in an Inventory is evidence that an entry was physically visible to the Inventory operation; it does not make that entry eligible for a Work Order SOURCE . SOURCE eligibility is the narrower contract in W002-WKO-009.1.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-006,Inventory serialization is deterministic UTF-8 TXT,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"The INV artifact is a deterministic human-readable TXT document encoded as UTF-8 without BOM, using LF ( 0x0A ) line endings, the same KEY: VALUE line grammar, and the same quoted-text escaping rule frozen by W002-RCP-005. Every INV ends with exactly one final LF, contains no trailing spaces, and contains no blank physical lines. The exact V1 Inventory serialization order is: INVENTORY_VERSION INVENTORY_UTC WORK_ORDER_FILENAME SUITCASE ENTRY_COUNT for each regular-file entry in deterministic ascending exact-filename UTF-8 byte order, one contiguous indexed triplet: FILE_<INDEX> , FILE_<INDEX>_BYTE_LENGTH , FILE_<INDEX>_LAST_MODIFIED_UTC DIRECTORY_COUNT exactly DIRECTORY_COUNT directory-name records using contiguous indexed keys DIRECTORY_<INDEX> , ordered by ascending exact-directory-name UTF-8 bytes. INVENTORY_VERSION is the unquoted integer 1 for this contract. WORK_ORDER_FILENAME , SUITCASE , each FILE_<INDEX> filename, and each DIRECTORY_<INDEX> name use the common double-quoted UTF-8 text serialization. FILE_<INDEX>_BYTE_LENGTH is the exact non-negative ungrouped ASCII base-10 byte length. FILE_<INDEX>_LAST_MODIFIED_UTC is either the exact canonical UTC millisecond token governed by W002-INV-003 or the unquoted governed absence token NOT_AVAILABLE . Indexed suffixes are one-based decimal with a minimum width of three digits and no maximum width: 001 through 999 are zero-padded and 1000 onward uses the full ungrouped decimal form. When ENTRY_COUNT or DIRECTORY_COUNT is zero, no indexed lines for that list appear. ENTRY_COUNT remains the regular-file count. Directory records contain the exact immediate child directory name only and do not imply recursive inspection or a computed directory size. Filename and directory-name representations remain unambiguous even when a name contains whitespace, quotes, or delimiter-like characters because the common quote-doubling rule applies. P3-10 inventory timestamp binding: INVENTORY_UTC must equal the exact canonical UTC token embedded in the final governed __DS__INV__<UTC>__<uuid-v4>.txt filename, just as RECEIPT_UTC is bound to the governed Receipt filename UTC. The INV body and filename therefore cannot claim different capture times.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-007,The current inventory describes the pre-publication Suitcase state and excludes itself,W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,Data Sculptor must enumerate and fix the inventory snapshot before publishing the new INV artifact. The INV artifact being created is therefore not one of its own listed entries. Any older INV artifact that already existed at snapshot time is an ordinary Suitcase file and is included like any other file. This pre-publication rule prevents recursive self-reference while preserving an accurate snapshot of the state that existed immediately before the new inventory evidence was added.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-008,"Help describes INVENTORY as a quick continuity aid, not byte-level proof",W002-INV,W002-INV,WASM-002,UNDER REVIEW,—,"Help must explain that an INV snapshot is useful for ordinary closeout and later orientation: it can reveal additions, removals, renames, size changes, or last-modified changes when snapshots or current metadata are compared. For an unexpected cross-session source problem, Help may direct the analyst to the relevant source entry in an earlier INV and ask whether its filename, exact byte length, or last-modified metadata differs. Help must also state that unchanged filename/size/last-modified metadata does not prove that file contents or row order are identical. When stronger assurance is warranted because files may change unexpectedly, Help may recommend the explicit later/deeper content-fingerprinting workflow; INVENTORY itself must never imply forensic or cryptographic assurance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-001,Large-file inventory acceptance proves metadata-only behavior,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"An acceptance fixture must place at least one multi-gigabyte file plus several small files in the authorized Suitcase, execute INVENTORY , and prove that the resulting INV records the correct filename, exact byte length, and last-modified metadata without reading the multi-gigabyte file contents. Evidence must demonstrate that inventory runtime and memory do not scale with the aggregate bytes of the listed files in the way a fingerprinting pass would. P3-10 metadata determinism: acceptance must include at least one file with usable host last-modified metadata and one test double/fixture in which the last-modified value fails the governed availability test. The first must serialize the exact canonical UTC millisecond value; the second must serialize exactly NOT_AVAILABLE . The accepted INV must also prove that INVENTORY_UTC exactly matches the UTC token in its final INV filename. Day 060 H-01 byte oracle: acceptance must include at least one byte-exact INV golden fixture using the complete W002-INV-006 key order, indexed suffix rule, quoted-text escaping rule, UTF-8/no-BOM physical form, LF-only line endings, and exactly one final LF. It must include at least two file records so deterministic filename ordering is observable, including one NOT_AVAILABLE last-modified value, and at least one directory record. Day 060 H-09 reachable-Suitcase INV golden fixture The byte-exact INV golden fixture used for WASM-002 review must depict a Suitcase state that could actually execute INVENTORY under the current contract rather than an isolated impossible file list. At minimum, immediately before the Inventory Run begins, the fixture Suitcase contains: one valid current Suitcase Validation Certificate ( CER ) authorizing the root; one structurally valid current WKO registry MAP; the exact saved immutable INVENTORY WKO referenced by WORK_ORDER_FILENAME , registered as runnable by that current WKO MAP; and the ordinary analyst files used to demonstrate inventory metadata, including the controlled last-modified-available and NOT_AVAILABLE cases. The INV snapshot is taken before publication of the new INV artifact and before its Receipt publication. Therefore the INV being created and the Receipt for that Run do not appear as pre-existing entries in their own inventory snapshot. For the retained minimal review fixture, the regular-file ENTRY_COUNT and indexed records must include the CER, current WKO MAP, exact INVENTORY WKO, and the two ordinary sample files, for a total of five regular-file rows, serialized in ascending exact-filename UTF-8 byte order. A later implementation fixture may use different exact governed filenames/UUIDs while preserving the same reachable-state requirement and deterministic ordering.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-002,Inventory snapshot membership and self-exclusion acceptance,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"An acceptance fixture must include ordinary analyst files, existing governed __DS__ artifacts, and at least one older INV artifact. The new inventory must include every qualifying pre-existing root file in deterministic order, include the older INV, and exclude only the newly generated INV because it did not exist in the fixed pre-publication snapshot. Adding an unrelated PDF or ZIP before a later inventory must appear as an added inventory entry and must not be treated as an analytical error.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-INV-ACC-003,Inventory does not overclaim unchanged contents,W002-INV-ACC,W002-INV,WASM-002,UNDER REVIEW,—,"Acceptance documentation and Help fixtures must demonstrate the limitation of metadata-only continuity. A case in which a file's bytes are changed while the observed filename, byte length, and last-modified metadata are preserved or restored must not be described as detectable by INVENTORY alone. The product must direct the analyst toward stronger explicit fingerprint evidence when byte-level assurance is required.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-016,Work Order filenames use the governed immutable identity grammar,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When Data Sculptor saves a new Work Order as a WKO, it shall assign the physical TXT filename. The analyst chooses the validated Suitcase but is not asked to choose or edit the WKO filename. The exact WKO filename shape is __DS__WKO__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt , using UTC at millisecond precision with exactly three millisecond digits and a canonical lowercase hyphenated UUID v4. UTC precedes UUID. If the generated name collides with an existing artifact, PB-STOR-011 governs UUID regeneration and safe retry. The saved WKO thereafter retains that physical identity and remains immutable under W002-STOR-017.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-017,Saved Work Orders are immutable artifacts,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"After a Work Order TXT artifact is saved, Data Sculptor shall not edit, overwrite, or rename that saved Work Order in place. Changing analytical instructions requires saving a new Work Order artifact with a new governed physical identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018,Work Order alias is immutable WKO content and governed MAP metadata,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A human-facing Work Order name is required immutable Work Order content for every executable/saved WASM-002 WKO, not separately editable browser metadata. The canonical declaration is WORK ORDER AS ""<alias>"" under W002-STEPS-001.1. The quoted alias must be non-empty UTF-8 text and may contain spaces and ordinary phrase punctuation subject to the governed string-literal rules. After the WKO TXT artifact is saved, Data Sculptor shall not edit the alias in place. Changing the alias, analytical instructions, or comments means creating and saving a new immutable WKO with a new governed physical identity. The physical WKO filename/UUID remains execution identity; the alias is human-facing metadata for display and governed name resolution. The browser must not maintain a separate mutable Description field or hidden description store. The alias declared by the WKO is also represented in the current governed WKO MAP under W002-STOR-018.1 through W002-STOR-018.4.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.1,The existing MAP class includes a distinct WKO alias-registry profile,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Revision BB does not add a new semantic artifact class. The existing MAP class has two explicitly distinguished governed profiles: Store MAP — the existing exact eight-column Store/RID/COL snapshot governed by W002-STOR-019 through W002-STOR-019.12; WKO MAP — a complete immutable snapshot that maps saved Work Order aliases and lifecycle status to exact immutable WKO filenames. Profile classification is determined by the exact CSV header before profile-specific validation. A valid WKO MAP must never be treated as an eligible Store MAP, and a Store MAP must never be treated as a WKO alias registry. Both remain visible flat-Suitcase MAP artifacts under the canonical immutable filename grammar.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.2,WKO MAP schema and serialization are exact and deterministic,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical WKO MAP is UTF-8 CSV without BOM, using LF record termination, with exactly this three-field header: wko_status,wko_alias,wko_filename Each row identifies one immutable governed WKO represented in that registry snapshot. wko_status is exactly CURRENT or DEPRECATED . wko_alias is the exact mandatory non-empty alias declared by that WKO's WORK ORDER AS clause. wko_filename is the exact governed physical WKO filename. Rows are written deterministically by ascending exact UTF-8 byte order of wko_filename . Duplicate wko_filename rows are invalid. Standard governed CSV quoting applies. For any exact wko_alias value, at most one row may have wko_status=CURRENT ; zero or more older rows for that same alias may have wko_status=DEPRECATED . Alias resolution uses the CURRENT row only. A WKO represented by a DEPRECATED row remains immutable historical evidence and is not renamed, rewritten, or deleted merely because its alias target was superseded. A WKO MAP containing more than one CURRENT row for the same exact alias is structurally invalid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.3,Saving a WKO and publishing its WKO MAP binding is one governed save transaction,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Saving a new immutable WKO begins from the current structurally valid WKO MAP in the Suitcase, or an empty WKO registry if no structurally valid WKO MAP exists. Data Sculptor validates the draft, including its mandatory non-empty WORK ORDER AS alias and comment syntax, and checks the governed alias/lifecycle constraints before commit. F-02 alias-lifecycle decision: if no CURRENT row in the predecessor WKO MAP uses the new WKO's exact alias, the successor registry adds the new WKO as CURRENT . If exactly one CURRENT row already owns that exact alias, Data Sculptor must present exactly two analyst choices before registry commit: Replace alias target or Cancel . Replace alias target constructs the successor WKO MAP by changing the former owner's row to DEPRECATED and adding the newly saved WKO as the sole CURRENT row for that alias; any older DEPRECATED rows remain unchanged. Cancel leaves the predecessor WKO MAP authoritative and does not commit the pending WKO/WKO-MAP pair as a registry update. Data Sculptor must not silently replace the alias target, auto-suffix the alias, or choose between competing owners. A predecessor WKO MAP with more than one CURRENT row for the same alias is structurally invalid under W002-STOR-018.2 and cannot be used as save authority. The former CURRENT WKO and every prior WKO MAP remain byte-for-byte immutable after replacement. Supersession changes only the lifecycle metadata represented in the newly published successor WKO MAP; it does not edit, rename, delete, or rewrite the historical WKO artifact. F-14 WKO publication predicate: the new immutable Work Order is first written under the W002-STOR-023.1 SCR identity using the UTC, UUID and .txt extension intended for its final WKO identity. The complete candidate is closed, reopened and validated as a saved WKO: required common preamble, exactly one non-whitespace WORK ORDER AS alias, governed lexical/comment rules, and complete parse under exactly one current WASM-002 executable operation grammar. Only then may the candidate be renamed from SCR to WKO . Save-time current-registry, alias-lifecycle and lifecycle gates remain transaction preconditions. A valid promoted WKO is not yet alias-registry authority; the successor WKO MAP promotion remains the save-transaction commit point. The WKO is persisted as a new immutable governed WKO artifact and the complete successor WKO MAP is constructed under SCR , closed, reopened, and validated for WKO MAP structural validity : exact profile/schema, exact governed serialization, filename/profile rules, lifecycle-row constraints, and internal row constraints. Whether every referenced physical WKO file is presently visible is a separate registry-health/publication check and is not part of WKO MAP structural validity. For an ordinary successful save transaction, every WKO referenced by the successor registry must be present at publication. The successor WKO MAP is promoted to MAP last; that successful MAP promotion is the alias-registry commit point for the save transaction. The WKO and successor WKO MAP created by one successful save transaction use one shared canonical transaction UTC while retaining distinct UUIDs. If successor WKO-MAP structural validation, referenced-file publication checking, or publication itself fails, the save must not be represented as a successfully committed alias-registry update. Data Sculptor must roll back the new WKO out of committed WKO state where safely possible or retain visible non-authoritative SCR failure evidence and report the failure through Help. F-02 repair-only bootstrap and stale-registry Save boundary When the current WKO registry is repair-required under W002-STOR-018.4, Data Sculptor may save one ordinary visible immutable WKO whose sole semantic operation is exactly REPAIR WORK ORDER REGISTRY . That saved repair-only WKO may Run by its exact physical WKO filename even though it is not yet represented in the current WKO MAP. The WKO must be structurally valid under the predicate below, must contain exactly one mandatory non-empty WORK ORDER AS , and must contain exactly the governed registry-repair operation and no second operation. The exception does not grant alias-based Run authority. The repair WKO is invoked only by exact physical WKO filename. No other visible but unregistered WKO gains Run eligibility from this exception. The exception ends once registry repair successfully publishes the successor WKO MAP. This is the sole WASM-002 bypass of ordinary current-registry membership for Run eligibility. Because the registry is already stale, Save of the repair-only WKO does not claim that the WKO has been registered, does not commit an ordinary successor WKO MAP, and does not represent the stale registry as healthy. The new immutable WKO remains visibly unregistered until the repair operation successfully publishes the successor WKO MAP containing its row. Save does not silently perform registry repair. F-02 governed WKO structural-validity predicate A visible WKO is structurally valid for registry purposes only when all of the following hold: it is a regular root-level Suitcase file; its physical filename conforms exactly to the governed WKO filename grammar; its bytes are valid UTF-8; LF and CRLF physical line endings are accepted; a lone CR line ending refuses; its content parses completely under exactly one defined WASM-002 executable Work Order grammar; it contains exactly one mandatory non-empty WORK ORDER AS clause; its required common and operation-specific structural clauses are present in their governed order/cardinality; and unknown syntax or prohibited operation mixing causes invalidity/refusal. Structural validity is not runtime success. A structurally valid WKO remains a valid governed artifact even when a runtime precondition is currently false, such as a referenced source file being absent. Runtime preconditions are checked at Run. P3-10 repair-bootstrap timing: during REPAIR WORK ORDER REGISTRY , the saved repair-only WKO participates in the bounded discovery performed by that repair run. It is not first “discovered after success.” Its governed registration becomes durable only when the complete successor WKO MAP containing that WKO row is successfully committed. Discovery during the run and registration in the committed successor registry are distinct events. P2-03 WKO-registry chronology guard: before a save or registry-repair transaction publishes a successor WKO MAP, Data Sculptor establishes the truthful observed transaction UTC and compares it with the chronology predecessor defined by W002-STOR-018.4. The observed UTC must be strictly greater. Equal or earlier UTC refuses before the new WKO/WKO-MAP pair is committed; Data Sculptor must not fabricate a later timestamp, silently wait/retry, skip the predecessor, or select an older registry merely to make publication succeed. F-13 single-writer pre-commit guard: immediately before the successor WKO MAP promotion that would commit the alias-registry update, Data Sculptor re-resolves the current WKO-registry authority and compares the relevant governing state with the state from which this transaction was derived. If another writing context or external filesystem action has changed that relevant authority, the transaction refuses publication. It must not overwrite the newer registry, silently rebase the pending save, or choose an older registry to make the commit succeed. The existing rollback / attributable SCR recovery-evidence rules apply to any WKO or candidate bytes already produced. If the save later refuses and an SCR candidate or other attributable staged evidence cannot be safely removed/restored, W002-STOR-023.1 governs retained SCR evidence and its non-authority boundary; WASM-002 does not emit RCV. An unregistered final WKO left by a failure is a valid immutable WKO artifact but does not become current registry authority merely by existing; the WKO MAP remains authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-018.4,Current WKO MAP selection is based on structural validity; missing referenced WKOs make the registry repair-required,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"WKO MAP structural validity is distinct from registry health. A WKO MAP is structurally valid when the MAP artifact itself satisfies the governed WKO MAP profile/schema, serialization, filename/profile rules, lifecycle-row constraints, and internal row constraints. The present existence of every physical WKO file named by its rows is not part of WKO MAP structural validity. Only structurally valid WKO MAP artifacts participate in current-registry selection. Among structurally valid WKO MAPs, the one with the greatest canonical UTC millisecond timestamp is the current WKO MAP snapshot and therefore the current governed Work Order alias registry. If two or more structurally valid WKO MAPs share that greatest timestamp, current-registry selection must refuse rather than break the tie by UUID, discovery order, filesystem modified time, or directory order. Registry-snapshot authority is distinct from alias-target status inside that snapshot. After the current WKO MAP snapshot is selected, an alias resolves only to its exact row whose wko_status is CURRENT . Rows marked DEPRECATED remain visible historical registry evidence but are not alias-resolution targets. The registry must never use the greatest WKO filename UTC, filesystem modified time, or discovery order to choose between rows for an alias. More than one CURRENT row for the same exact alias makes that WKO MAP structurally invalid under W002-STOR-018.2. If a newer WKO MAP artifact is structurally malformed, it never becomes current. Data Sculptor uses the greatest earlier structurally valid WKO MAP, if one exists, and reports the malformed newer artifact through Help/evidence surfaces. A malformed newer WKO MAP does not itself make the selected earlier registry repair-required. The current WKO registry is repair-required exactly when the current structurally valid WKO MAP contains one or more rows whose referenced physical WKO files are missing from the Suitcase. Such a MAP remains current ; Data Sculptor must not silently fall back to an older WKO MAP merely because a referenced WKO is missing. This preserves the latest registry authority while making the damage explicit and reachable through the governed REPAIR WORK ORDER REGISTRY path. F-02 deterministic registry reconciliation REPAIR WORK ORDER REGISTRY reconciles the current WKO MAP against visible WKO artifacts in the Suitcase and constructs one complete successor WKO MAP deterministically: Remove every row from the successor whose referenced physical WKO file is missing. A missing WKO is never reconstructed, inferred, copied from history, or replaced automatically by a deprecated WKO. Discover visible structurally valid WKOs that are absent from the current WKO MAP. If no surviving CURRENT row owns a discovered WKO's exact alias, register that discovered WKO as CURRENT . If a surviving CURRENT row already owns that exact alias, register the discovered WKO as DEPRECATED ; existing current authority is not silently displaced. If two or more previously unregistered structurally valid WKOs share the same alias and no surviving CURRENT owner exists, register all of those discovered WKOs as DEPRECATED . Data Sculptor must not choose a winner by UTC, filename, UUID, directory order, discovery order, or filesystem modified time. The repair WKO itself participates in the same discovery and registration process during the repair run. Its registration becomes durable only when the complete successor WKO MAP is committed. Predecessor WKO MAPs and surviving WKO files remain immutable historical evidence. Successor rows remain serialized in ascending exact UTF-8 byte order of wko_filename under W002-STOR-018.2. Day 060 H-10 / BM-07 registry-repair change-set counts The registry-repair operation distinguishes the successor registry state from the change set produced by this repair Run . The Receipt's REGISTERED_CURRENT_* and REGISTERED_DEPRECATED_* fields describe only the latter. REGISTERED_CURRENT_COUNT is the exact number of previously unregistered structurally valid WKO files newly added by this repair Run with wko_status=CURRENT . REGISTERED_CURRENT_WKO_<INDEX>_FILENAME lists exactly those newly registered CURRENT WKOs, ordered by ascending exact UTF-8 filename bytes. REGISTERED_DEPRECATED_COUNT is the exact number of previously unregistered structurally valid WKO files newly added by this repair Run with wko_status=DEPRECATED . REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME lists exactly those newly registered DEPRECATED WKOs, ordered by ascending exact UTF-8 filename bytes. Surviving rows that were already present in the base WKO MAP are not counted in either REGISTERED_* total, even though they appear in the successor WKO MAP. Rows removed because their referenced WKO is missing are represented only by REMOVED_STALE_ROW_COUNT and the corresponding stale-WKO filename list; they are not also reflected in either registered count. The bootstrap repair WKO participates exactly like any other newly discovered structurally valid unregistered WKO. If the repair commits it, that exact WKO must appear in one and only one of the two registered filename lists according to the ordinary alias-ownership rules. These counts therefore answer “what did this repair register?” rather than “how many CURRENT/DEPRECATED rows exist in the resulting registry?”. F-02 Run eligibility and alias authority Run by human-facing alias resolves only to the sole CURRENT WKO for that alias. A registered CURRENT WKO may Run by exact physical WKO filename, subject to ordinary runtime preconditions. A registered DEPRECATED WKO may also Run by exact physical WKO filename, subject to ordinary runtime preconditions, to support deliberate historical reproduction. An unregistered WKO may not Run merely because its file is visible, except for the single bounded repair-only bootstrap in W002-STOR-018.3. The browser may use the current structurally valid WKO MAP to show human-facing Work Order aliases together with read-only CURRENT / DEPRECATED lifecycle state while keeping exact physical WKO filenames visible/inspectable. Future Work Order composition may use the same registry to resolve a non-empty alias to exactly one immutable WKO artifact through its sole CURRENT row. This requirement does not pull deferred Work Order invocation/orchestration grammar into WASM-002; it establishes the governed alias-registry selection, lifecycle, and repair boundary that later composition can depend on. F-08 REPAIR WORK ORDER REGISTRY Work Order structure: SUITCASE: .
WORK ORDER AS ""Repair Work Order Registry""
REPAIR WORK ORDER REGISTRY After the common preamble, REPAIR WORK ORDER REGISTRY is the sole semantic operation clause and is terminal. It takes no analyst-supplied SOURCE , Store MAP , alias-mutation list, column selector, conversion source, or catalog clause. Its bounded unregistered-repair bootstrap remains governed by W002-STOR-018.3. The DS-STEPS phrase is distinct from the Receipt operation token REPAIR_WORK_ORDER_REGISTRY . P2-03 chronology predecessor: for any WKO-registry successor publication, the chronology predecessor is the unique current structurally valid WKO MAP immediately before that publication transaction. It is the MAP selected by the current-registry rule above, not an older registry used for inspection and not a filesystem-modified-time surrogate. If no structurally valid WKO MAP exists and the operation is legitimately establishing the first governed registry state, there is no predecessor UTC. Future-dated current WKO MAP: a structurally valid current WKO MAP whose governed UTC is later than truthful observed host UTC remains the current registry; the timestamp conflict does not by itself make the MAP malformed or repair-required. Successor WKO-MAP publication is blocked until the monotonic UTC precondition can be satisfied. Help must identify the exact blocking WKO MAP and explain the analyst-owned exits: correct an incorrect host clock; wait/rerun after truthful time advances beyond the predecessor; or, when the analyst deliberately determines that the active future-dated WKO MAP should no longer govern the Suitcase, move that exact MAP out of the active Suitcase root and reopen/rescan. That filesystem action is not a Data Sculptor repair operation. It may expose an older structurally valid WKO MAP as current, and restoring the moved future-dated MAP to the active Suitcase may make it current again under the ordinary greatest-UTC rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019,Store state is preserved as visible immutable MAP history,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each valid WASM-002 MAP is one complete immutable Store snapshot in the same flat Suitcase. Store state is not stored in hidden browser persistence and is not represented by a mutable well-known singleton. Each successful Store-establishing materialization or later governed Store-metadata/materialized-column update publishes a new immutable MAP under the canonical __DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv identity grammar. Earlier MAP artifacts remain visible history and are not overwritten or deleted merely because a newer Store state is created. Day 057 CAT reconciliation: the one-Store-per-MAP invariant is unchanged. A collection of independently MAP-governed Stores may additionally be summarized by a governed CAT Store Catalog for collection-level discovery and orientation. CAT does not govern Store semantics, lineage, health, repair, inheritance, or current-MAP selection. MAP remains authoritative for each Store.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.1,A Work Order may explicitly select at most one Store MAP,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each governed Work Order may explicitly identify at most one valid immutable Store MAP as its Store/inheritance base. If more than one MAP is explicitly specified, Data Sculptor must refuse before Store resolution, alias resolution, materialization, or mutation. An explicitly named valid MAP binds the run to exactly the Store identified by that MAP's rid_filename and overrides automatic Store-MAP discovery even when newer MAPs for that Store or other Stores exist.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.2,"Without an explicit MAP, materialization performs Store-aware MAP inheritance",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If a materializing Work Order does not explicitly identify a MAP, Data Sculptor must compare the exact Work Order SOURCE filename with the one common exact source_filename carried by every row of each routable Store lineage's structurally valid Store MAP. That common source_filename is the Store lineage's source identity for WASM-002 routing. The redundant ninth Store-source field from the superseded profile is not part of the canonical Store MAP. P3-07 routing term: for automatic source routing, a routable Store lineage is a Store lineage for which at least one structurally valid Store MAP exists, regardless of whether the lineage currently evaluates VALID , DEGRADED , or INVALID . Routing discovery must use this term rather than the ambiguous word eligible . Store health is evaluated only after the lineage has been discovered. If no routable Store lineage exists for the exact source filename, Data Sculptor may establish a new Store with a new RID and first Store MAP only if the active Suitcase contains no structurally malformed Store-MAP-class artifact . If exactly one routable Store lineage exists, Data Sculptor routes to that lineage. If its current state permits materialization, the current governed Store MAP is the inheritance base; if its current state is DEGRADED or INVALID , ordinary materialization refuses under the damaged-lineage rules below. If more than one distinct routable Store lineage exists for the same exact source filename, automatic inheritance must refuse rather than guess which Store the analyst intended. The analyst must explicitly select one permitted MAP. All-Store-MAPs-damaged guard: if exact- SOURCE routing finds no routable Store lineage but one or more structurally malformed Store-MAP-class artifacts are present in the active Suitcase, ordinary materialization must refuse before creating a new Store or RID. Data Sculptor must not infer that the absence of a structurally valid Store MAP proves that no prior Store lineage existed. Help must identify the malformed Store MAP artifact or artifacts that caused this guard. A damaged MAP therefore cannot silently turn Store damage into permission to create a replacement lineage. Store lineages are distinguished by their governed lineage identity. Current-MAP selection and Store-health evaluation are separate governed questions under this requirement and W002-STOR-019.10. If two or more structurally valid current MAP candidates for the one routed Store share the greatest canonical UTC millisecond timestamp, automatic inheritance must refuse rather than infer chronology from UUID, directory order, filesystem modified time, or discovery order. F-03 canonical evaluated Store-health states Store health is evaluated from the current structurally valid Store MAP and the presently visible governed artifacts it references, using the applicable validation tier in W002-STOR-019.10. WASM-002 has exactly three evaluated Store-health states: VALID — the current Store MAP is structurally valid; the referenced RID is valid; and every mapped non-RID COL is valid. DEGRADED — the current Store MAP is structurally valid; the referenced RID is valid; and one or more mapped non-RID COL artifacts are missing or invalid. INVALID — the current Store MAP is structurally valid, but its referenced RID is missing or invalid. There is no fourth ABANDONED Store-health status in WASM-002. F-03 status is evaluated, not persisted VALID , DEGRADED , and INVALID are evaluated states. WASM-002 does not write or maintain a mutable persisted Store-status flag. While a Store evaluates INVALID , Data Sculptor exposes no governed Store-recovery operation for that Store and never regenerates, substitutes, or infers a replacement RID. If the exact governed RID physical identity becomes visible again through analyst-owned external restoration and passes the validation tier required by the next operation, the Store is re-evaluated from the visible governed artifacts and may become VALID or DEGRADED . That is re-evaluation, not RID recovery by Data Sculptor. F-03 strict DEGRADED operation gate When a Store evaluates DEGRADED , REPAIR MAP is the only enabled Store mutation operation for that lineage . ordinary materialization into that Store refuses; extension with new columns refuses; alias mutation refuses; transformations and other Store mutations refuse; read-only Help, Inventory, status/orientation surfaces, CAT orientation, and evidence inspection remain available subject to their own contracts. F-03 no damaged-lineage fork If exact SOURCE routing identifies a lineage whose current Store evaluates DEGRADED , ordinary materialization refuses and directs the analyst to the governed REPAIR MAP path. If the routed Store evaluates INVALID , ordinary materialization refuses and WASM-002 provides no RID-recovery path. Neither condition permits Data Sculptor to treat the source as unseen or establish a replacement Store with a new RID for that routed lineage. Damaged-lineage routing: exact SOURCE routing must not treat a known damaged lineage as unseen merely because its current Store state cannot accept ordinary materialization. If routing identifies a DEGRADED or INVALID lineage, ordinary materialization refuses rather than silently creating a replacement Store for that same routed lineage. Help duty for an all-COLs-broken DEGRADED lineage: when the current structurally valid Store MAP references a valid RID but every mapped non-RID COL is missing or invalid, REPAIR MAP cannot publish a zero-COL successor and must refuse. Help must identify the exact blocked Store lineage and current MAP, then explain these analyst-owned exits: (1) externally restore at least one governed COL artifact under its original physical filename; Data Sculptor then applies the governed validation tier required by the next operation before the artifact can re-enter use, so Store health can be re-evaluated and REPAIR MAP may become available; (2) rename the analyst-owned source and materialize the renamed source to deliberately begin a new Store lineage with a new RID, without repairing, replacing, or erasing the damaged lineage; or (3) retire the damaged lineage from active Suitcase routing by moving all Store MAP artifacts belonging to that lineage out of the Suitcase root. Help must warn that moving only the latest MAP is insufficient because an older structurally valid MAP could otherwise become current. Help duty for an INVALID lineage: when the current structurally valid Store MAP references a missing or invalid RID, Help must identify the exact blocked Store lineage and current MAP, state that WASM-002 does not silently regenerate or substitute a RID as part of ordinary materialization, and explain these analyst-owned exits: (1) externally restore a governed RID artifact under its original physical filename; Data Sculptor then applies the governed validation tier required by the next operation before the artifact can re-enter use, so Store health can be re-evaluated; (2) rename the analyst-owned source and materialize the renamed source to deliberately begin a new Store lineage with a new RID while leaving the damaged lineage untouched; or (3) retire the damaged lineage from active Suitcase routing by moving all Store MAP artifacts belonging to that lineage out of the Suitcase root, again warning that moving only the latest MAP is insufficient. Renaming the source and retiring a lineage are distinct analyst choices. Renaming preserves the damaged lineage in the Suitcase and creates a separate lineage under a different source identity. Moving all lineage MAPs out removes that lineage from active routing while preserving the moved artifacts wherever the analyst chooses to keep them. These are analyst filesystem actions, not new Data Sculptor recovery operations. Assurance boundary: exact source-filename matching in this rule is a Store-routing/orientation mechanism, not proof that an analyst-owned source has identical bytes or row order across separate sessions. Ordinary WASM-002 materialization must not silently represent that filename equality as cryptographic continuity. P3-08 CVT source-identity boundary: a governed CVT is a new immutable source artifact whose Store-routing source identity is its exact physical CVT filename. Two different CVT filenames are different source identities even when both conversions began from analyst-owned files having the same original filename. WASM-002 does not carry the analyst-owned pre-conversion filename forward as hidden Store-lineage identity and does not infer continuity between separate CVT artifacts. First materialization of a CVT therefore establishes or routes only by that exact CVT filename under the normal rules above. P2-03 current Store-MAP chronology: within one routable Store lineage, the current structurally valid Store MAP is the unique structurally valid MAP carrying the greatest canonical UTC millisecond timestamp. If two or more structurally valid MAPs share that greatest timestamp, current authority is ambiguous and selection refuses rather than using UUID or discovery order. This current MAP is also the lineage's chronology predecessor for any new successor publication, even when the operation explicitly derives its requested new state from an older historical MAP. F-15 exact-source comparison and routing domain: the Work Order SOURCE value and each Store MAP's common source_filename are compared by exact Unicode scalar-value sequence under PB-STOR-010, with no case folding or Unicode normalization. Automatic routing compares only routable Store lineages whose structurally valid Store MAPs participate in that exact-source routing decision. Unrelated Suitcase files, non-Store artifact classes, filesystem enumeration order, and arrival order are outside the routing comparison domain and cannot create or remove a source match.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.3,"Any valid historical Store MAP may be selected explicitly with MAP ""<filename>""",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A governed Store-aware Work Order may explicitly identify any one structurally valid immutable Store MAP present in the Suitcase, including an older snapshot when newer MAPs for that Store also exist. The canonical clause is: MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv"" The quoted value must be the exact physical filename of one valid Store MAP. A WKO MAP profile, missing file, malformed MAP, or other MAP profile is invalid for this clause. Data Sculptor uses exactly the named Store MAP rather than silently substituting a later one. For materialization, SOURCE ""..."" remains required to identify the source file being read; the optional MAP ""..."" clause occurs immediately after SOURCE and before KEEP , overrides automatic Store-MAP inheritance, and supplies the exact Store-state base. The Work Order's exact SOURCE filename must match the selected lineage's governed source identity under the frozen source/Store compatibility rules or validation refuses. For an alias-only UPDATE ALIASES Work Order, MAP ""..."" may itself be the Store-state selector and no source-data read is required. Historical-MAP health gate. Explicit selection of a current or historical Store MAP never bypasses current Store-lineage health. The selected lineage must currently evaluate VALID , and every RID/COL binding referenced by the named MAP must currently be present and valid. If either condition fails, Data Sculptor refuses the operation. An older MAP cannot be used to hide present lineage damage. The same rule applies when UPDATE ALIASES uses a historical Store MAP as its base. Once selected, the exact MAP identity, Store RID binding, Store alias, RID alias, and materialized-column mapping state remain fixed for the governed run. The MAP filename is execution input, not a friendly alias. P2-03 base-versus-predecessor distinction: an explicitly selected historical MAP is the operation's base MAP —the Store snapshot from which requested new state is derived. It does not become the chronology predecessor merely because it was selected. If the operation publishes a new Store MAP, the chronology predecessor remains the Store lineage's current structurally valid MAP immediately before publication. The new transaction UTC must be strictly greater than that current MAP UTC. This preserves one chronological MAP history rather than creating a branch from the historical base. F-21 current-state consequence: merely selecting or validating a historical Store MAP does not change Store authority. If the governed run refuses or otherwise publishes no successor Store MAP, the lineage's pre-run current MAP remains current. If the run successfully publishes a successor derived from a historical base, that new MAP enters the same single chronological history and ordinary greatest-governed-UTC current-state selection applies. Because successor publication already requires a truthful transaction UTC strictly greater than the pre-publication chronology predecessor, the successfully published successor becomes current. The explicitly selected historical base and the formerly current MAP both remain immutable historical evidence. This behavior is deliberate state derivation, not a branch, rollback-in-place, overwrite, or mutation of prior MAPs. The operation base records which Store snapshot supplied the requested starting state ; chronology records when the new governed state was published . Those are distinct facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.4,"Store MAPs are complete snapshots, not delta logs",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Each valid Store MAP represents one complete usable Store metadata and materialized-column mapping state for that version. It must not require replaying a chain of earlier MAP files merely to reconstruct the Store's current RID binding, aliases, or materialized-column mappings. A newer MAP created from an inherited older MAP contains the complete resulting Store snapshot after applying the governed Work Order's successful changes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.5,Materialization or governed Store metadata mutation emits one successor MAP,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When a governed Work Order materializes one or more columns or requests governed Store/RID/COL alias changes, Data Sculptor begins from the applicable governed Store-state base. Ordinary materialization uses the explicitly selected MAP or Store-aware automatic inheritance under W002-STOR-019.2. A new Store begins from newly established Store/RID metadata plus an empty materialized-column mapping set before requested materialization is applied. All successful updates in that Work Order are applied to one in-memory complete Store snapshot. The complete deterministic successor-MAP bytes must first be written under a governed SCR candidate identity, closed successfully, reopened, and fully validated while still an SCR candidate. Only a complete validated candidate may be promoted by host rename into one new immutable MAP artifact. The inherited MAP remains unchanged. The successful SCR -to- MAP rename is the Store-state commit point. A failed run must not create a valid successor MAP; a malformed, incomplete, or unpromoted MAP candidate remains visible non-authoritative SCR evidence rather than Store state. RID reconstruction/replacement is not a WASM-002 Store-mutation path. P2-03 successor publication precondition: before any final RID/COL/MAP promotion for a successor Store-state transaction, Data Sculptor identifies the lineage's chronology predecessor and establishes one truthful observed host transaction UTC. For an existing lineage, that UTC must be strictly greater than the current structurally valid Store MAP UTC, regardless of whether the Work Order's base MAP is current or historical. Equal or earlier observed UTC refuses publication; no artificial +1 ms , sleep-and-retry loop, UUID tie-break, older-predecessor fallback, or branch chronology is permitted. The chronology predecessor remains current and unchanged. Future-dated current Store MAP: a structurally valid current MAP with a governed UTC later than truthful observed host UTC is a clock-order conflict, not by itself Store corruption. It remains current and successor publication is blocked. Help must identify the exact blocking MAP and explain the analyst-owned exits: correct an incorrect host clock; wait/rerun after truthful time advances beyond the predecessor; or deliberately move that exact future-dated current Store MAP out of the active Suitcase root and reopen/rescan. Moving it is an analyst filesystem action, not a governed Data Sculptor mutation. An older structurally valid MAP may then become current; returning the future-dated MAP may restore its authority under the ordinary greatest-UTC rule. F-13 single-writer pre-commit guard: immediately before the final successor Store-MAP promotion, Data Sculptor re-resolves the relevant current Store authority and exact-source routing state on which the transaction depended. For an existing lineage, the current chronology predecessor must still be the authority against which the transaction was prepared; for a new-Store transaction, no newly established routable lineage may have appeared that changes the routing decision. If relevant governed state changed while the transaction was in flight, publication refuses. Data Sculptor must not overwrite the newer authority, silently rebase onto it, create a competing branch, or report success. Any RID/COL/candidate artifacts already produced are handled by the existing rollback / attributable recovery-evidence rules and do not become committed Store membership without the final valid MAP binding. F-21 historical-base publication rule: when the applicable Store-state base is a valid historical MAP rather than the pre-run current MAP, the complete successor snapshot is still derived from that explicitly selected base plus the current Work Order's requested changes. Publication does not silently merge later state from the formerly current MAP back into the successor. Therefore mappings or aliases introduced only after the selected historical base may be absent from the new successor when the requested operation does not recreate them. That is the deliberate consequence of using the historical base, not data loss caused by an implicit merge. The pre-run current MAP remains the chronology predecessor solely for monotonic publication ordering and stale-authority protection. Successful publication leaves both the historical base and the formerly current MAP byte-for-byte unchanged, publishes one new immutable successor MAP in the same lineage, and makes that successor current under the ordinary chronology rule. No branch identifier, hidden branch state, overwrite, in-place rollback, or automatic rebase is created.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.6,Store MAP CSV schema is exactly eight columns,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 Store MAP is a CSV whose header row is exactly: store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename Each data row describes one current logical materialized-column mapping: store_alias — current human-facing Store name; rid_filename — exact immutable governed RID artifact filename that physically anchors this Store lineage; rid_alias — current human-facing RID name; source_filename — exact visible source filename common to every row in this one-Store MAP and therefore the Store source identity; source_column_number — 1-based source-column ordinal; source_header — exact decoded CSV header value after governed parsing; alias — current human-facing COL name; and column_filename — exact physical governed COL artifact filename represented by the row. Every row in one valid Store MAP must carry the same exact rid_filename and the same exact source_filename . A MAP that mixes RID lineages or source filenames is invalid. The logical source-column key for COL alias continuity remains the exact triple (source_filename, source_column_number, source_header) . The Store is physically identified by the repeated exact rid_filename , not by mutable aliases. F-05/P2-01 reconciliation: the superseded redundant Store-source column is removed. One Store MAP represents exactly one Store lineage and exactly one source identity, so the common source_filename supplies the required source identity without a second Store-source field. P3-06 identity-evidence boundary: this eight-column MAP profile intentionally records governed physical filenames and mapping metadata, not per-artifact byte lengths, row counts, digests, or historical-content fingerprints. A MAP therefore cannot prove that a same-named RID or COL restored later is byte-for-byte identical to the earlier artifact. WASM-002 must not make that claim unless separate authoritative fingerprint evidence exists outside this MAP profile. P2-04 schema consequence: no byte-length, RID- N , digest, or per-artifact fingerprint columns are added to the eight-column Store MAP to close restoration validation. The MAP remains compact relationship/state metadata. Stronger byte-identity assurance remains the responsibility of explicit fingerprint evidence outside ordinary WASM-002 Store governance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.7,Source headers become default COL aliases on first materialization,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When a logical source column is materialized and its exact logical key does not already exist in the inherited Store MAP, its default COL alias is its operational column name . For an exact decoded source_header of at most 1,024 Unicode scalar values, the operational name is that exact header text. For an exact decoded source_header longer than 1,024 scalar values, the operational name begins as Column <LETTERS> from the column's 1-based physical source ordinal (for example Column A , Column Z , Column AA , through Column XFD ). The exact source_header remains unchanged in the Store MAP and physical COL header; the operational name exists only to provide a bounded human-facing/default-alias value. HEADER selection continues to match the exact decoded source header under W002-STEPS-002. If an oversized-header base fallback Column <LETTERS> would collide in the complete successor alias namespace, Data Sculptor deterministically tries Column <LETTERS> [<ordinal>] ; if that also collides, it appends -2 , -3 , and so on until the first available exact value is found. This is the only automatic alias-suffix rule in WASM-002. A short exact source-header default that is empty or collides still refuses unless the Work Order supplies an explicit valid alias; Data Sculptor must not suffix or rewrite it. If the same Work Order supplies an explicit alias for a newly materialized column, the explicit governed alias overrides the operational default and must pass the ordinary exact uniqueness/shadowing rules without automatic suffix repair. For a previously materialized COL, RESET COL ""<reference>"" ALIAS restores this same deterministic operational default from the exact recorded source_header and physical source ordinal. An oversized recorded header therefore restores its deterministic fallback/disambiguated operational name rather than inserting the potentially very long exact header into the alias field. A short empty/colliding source-header default still refuses rather than inventing a substitute.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.8,"Ordinary rematerialization preserves Store metadata, inherited RID, and inherited COL alias",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"If a newly materialized column's exact logical key already exists in the inherited Store MAP, Data Sculptor must preserve that row's current COL alias unless the Work Order explicitly changes it. The successor MAP replaces only that logical row's column_filename with the newly created physical COL artifact filename. Ordinary rematerialization must preserve the inherited Store's exact common source_filename and rid_filename . It must not silently create a different Store, replace the Store RID, revert a user-facing Store/RID alias, or revert a COL alias to its source header. Every row in the successor MAP continues to carry that same common Store source_filename . WASM-002 has no executable operation that replaces rid_filename while preserving the same Store lineage. A different RID filename therefore cannot be introduced as ordinary successor-state continuity in this build.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.9,Store MAP serialization is deterministic UTF-8 CSV,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Store MAP CSV files are encoded as UTF-8 without BOM and use LF ( 0x0A ) record termination. The exact eight-field header in W002-STOR-019.6 is written once as the first row. Fields use standard CSV quoting semantics: a field containing comma, double quote, CR, or LF is enclosed in double quotes, and embedded double quotes are doubled. No locale-dependent formatting is permitted. Every data row in one MAP must contain byte-for-byte identical values for store_alias , rid_filename , rid_alias , and source_filename . Mapping rows are written deterministically by ascending numeric source_column_number , then ascending UTF-8 byte order of source_header . Because one valid Store MAP has exactly one common source_filename , that field is not needed as a leading row-sort discriminator. Two rows with the same logical source-column key (source_filename, source_column_number, source_header) are invalid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.10,Only a complete validated Store MAP is eligible for inheritance,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A canonical MAP filename alone does not make a file a structurally valid Store MAP. For Store-MAP structural validity , the MAP artifact itself must be readable as complete UTF-8, have the exact eight-column schema, parse deterministically, satisfy Store-level consistency, lineage, deterministic row-order, mapping-key, and alias constraints, and carry structurally valid governed RID/COL filename bindings. The present health of the referenced RID/COL artifacts is a separate question and does not determine whether the MAP itself is structurally valid. A Store MAP remains part of governed Store history when its own bytes, schema, lineage facts, and deterministic structural rules are valid even if a referenced RID or COL later becomes missing or invalid. Referenced-artifact damage therefore does not make the current structurally valid Store MAP disappear and does not by itself cause fallback to an older MAP. F-03 current Store MAP selection Current-state selection is performed independently within one exact Store lineage. Only structurally valid Store MAP artifacts participate. Among those MAPs, the ordinary frozen chronology rule selects the unique structurally valid MAP with the greatest canonical UTC millisecond timestamp. A structurally malformed newer MAP is never current. If a newer canonical MAP artifact is structurally malformed, Data Sculptor uses the greatest earlier structurally valid Store MAP in that same lineage, if one exists, and reports the malformed newer artifact through governed Help/evidence surfaces. This fallback applies to structural MAP invalidity only. It does not apply merely because a structurally valid current MAP references a damaged RID or COL. If two or more structurally valid MAPs share the greatest canonical UTC millisecond timestamp, current authority is ambiguous and selection refuses rather than breaking the tie by UUID, discovery order, directory order, or filesystem modified time. P3-07 routing distinction: Store-MAP inheritance eligibility is stricter than lineage discovery. A Store lineage participates in exact- SOURCE routing when at least one Store MAP in that lineage is structurally valid, even if the current Store later evaluates DEGRADED or INVALID . Referenced RID/COL health is evaluated after routing and may cause refusal; it must not make an already discoverable lineage disappear. For successor publication, after the required RID/COL physical promotions have succeeded, Data Sculptor uses the already-established publication-transaction UTC and allocates a MAP-specific UUID before opening the complete deterministic MAP CSV under its governed SCR candidate identity. The SCR filename therefore already carries the exact UTC, UUID, and .csv extension intended for the final MAP identity. The candidate is closed successfully, reopened, and validated for bytes, schema, Store-level consistency, aliases, RID binding, COL bindings, deterministic row order, and all other MAP eligibility rules while it remains SCR . Only after that validation succeeds may Data Sculptor promote the candidate by host rename that changes only the three-letter semantic class token from SCR to MAP . The candidate bytes, UTC, UUID, and extension must remain unchanged across promotion. The successful rename is the publication/commit point. If validation or rename fails, no successor MAP becomes eligible/current; the candidate remains or is retained as visible non-authoritative SCR evidence. Store-aware automatic selection therefore continues to use the greatest earlier valid MAP in the same Store lineage, if one exists, while Help reports the failed candidate/publication rather than silently treating it as current state. P3-06 governed artifact-validation tiers. Store-health status and full content validity are distinct assurances. The following two tiers are normative for WASM-002: Tier 1 — Store-health structural validation. Used for routine Store status, source routing, historical-MAP health gates, inheritance decisions that do not consume analytical artifact contents, and alias-only maintenance. The selected Store MAP itself is fully parsed and structurally validated because it is the compact authority for the snapshot. A referenced RID passes Tier 1 only when the exact MAP-bound governed RID filename is present and readable, the bytes begin with exactly one UTF-8 BOM, the first logical record is a canonical N=<value> header, the final byte is LF, and the physical byte length equals the deterministic length implied by the canonical RID representation for that declared N . Tier 1 does not rescan every RID data record merely to perform routine status or alias work. A referenced COL passes Tier 1 only when the exact MAP-bound governed COL filename is present and readable, begins with exactly one UTF-8 BOM, exposes the canonical one-column CSV header whose decoded value exactly equals the MAP row's recorded source_header , and ends with LF. Tier 1 does not stream every COL value merely to establish routine Store health. Tier 2 — full artifact validation. Used whenever an operation actually consumes RID/COL contents, for complete validation of newly created candidates before commit, and by REPAIR MAP after the repair operation has been validly entered. A RID passes Tier 2 only when a full stream proves the canonical N=<value> header, exactly N data records, and exact ordered values 1..N . A COL passes Tier 2 only when a full stream proves canonical one-column CSV encoding/serialization, the exact expected header, and exactly N logical data records aligned to the Store RID. VALID , DEGRADED , and INVALID are Store-health states evaluated from the governed current snapshot using the required validation tier; they are not claims of cryptographic historical identity. When REPAIR MAP is validly invoked, it must perform Tier 2 validation of the RID and every mapped COL that would survive into the successor. The deterministic repair result removes exactly the mapped COL bindings that fail that Tier 2 check, subject to the separately frozen refusal when no mapped COL would remain. Two implementations presented with the same bytes must therefore identify the same repair set. External restoration boundary: a file placed back under an original governed RID/COL physical filename may re-enter use only when it passes the validation tier required by the operation. Filename equality plus governed validation is sufficient for operation eligibility under this WASM-002 boundary; it is not proof that the restored bytes are the historical original bytes. Stronger historical-byte identity requires separate authoritative fingerprint evidence. P3-10 terminology boundary: Store-state repair is REPAIR MAP . Work Order alias-registry repair is REPAIR WORK ORDER REGISTRY . These are distinct governed operations and the integrated specification must not describe a Store REPAIR MAP Work Order as a “registry-repair Work Order.” This corrects wording only; it does not change either operation's frozen semantics. F-08 / F-03 REPAIR MAP Work Order structure and target precondition: SUITCASE: .
WORK ORDER AS ""Repair Crime Store""
MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""
REPAIR MAP Exactly one MAP ""<filename>"" clause is mandatory. It names the exact physical filename of one structurally valid Store MAP. At Run time, that named MAP must be the current structurally valid Store MAP for exactly one lineage and the target Store must currently evaluate DEGRADED . A historical Store MAP, WKO MAP, missing MAP, malformed MAP, ambiguous equal-latest current state, MAP from an unsupported profile, or target Store that does not evaluate DEGRADED refuses. No SOURCE , Store/RID/COL alias selector or mutation, KEEP , materialization, conversion, Inventory, registry repair, cataloging, or composition clause is supplied in the same WKO. The analyst selects the Store by exact current Store MAP identity; Data Sculptor determines which mapped non-RID COL bindings are broken. The terminal DS-STEPS clause is REPAIR MAP ; the Receipt operation token is separately REPAIR_MAP . P2-03 monotonic eligibility boundary: structural validity/eligibility and chronology are separate. A structurally valid future-dated Store MAP remains a structurally valid MAP and participates in current-state selection. It is not demoted merely because the host clock is presently earlier. The monotonic guard applies when publishing a successor: truthful observed transaction UTC must be strictly greater than the chronology predecessor UTC before any successor state may commit. P2-04 closure — validation depth is now complete. The Tier-1/Tier-2 rules in this requirement are the complete WASM-002 oracle for deciding whether a MAP-bound RID/COL is sufficiently valid for the operation being attempted. Tier 1 is intentionally bounded and is used only by operations that do not consume RID/COL analytical contents. Tier 2 is a full streaming validation and is mandatory before an operation relies on RID/COL contents, for newly created candidates before commit, and for REPAIR MAP . REPAIR MAP determinism. Once a valid REPAIR MAP operation is entered, Data Sculptor performs Tier 2 on the Store RID and on every mapped COL. The repair successor removes exactly those mapped COL bindings whose physical COL artifacts fail Tier 2, preserves exactly those that pass Tier 2, and still refuses if zero mapped COL bindings would remain. No shallower Tier-1 result may decide the repair set. F-03 repair semantics: after target validation, Data Sculptor confirms the named MAP is current for exactly one Store lineage, confirms the referenced RID is valid, identifies every mapped non-RID COL that is missing or invalid under the required repair validation tier, preserves every valid COL binding unchanged, removes exactly the broken COL bindings from the successor candidate, preserves the exact Store lineage RID identity and remaining Store/RID metadata, validates the complete successor MAP candidate, and publishes the successor only if every repair gate succeeds. REPAIR MAP does not reread or regenerate the source CSV, rematerialize a lost COL, regenerate the RID, or edit the predecessor MAP in place. F-03 all-COLs-broken refusal: if removing the broken bindings would leave zero COL mapping rows, REPAIR MAP refuses. No zero-COL Store MAP is introduced, no special anchor row is invented, no successor MAP is published, and the Store remains DEGRADED . The existing current structurally valid MAP and RID continue to anchor the visible lineage. Identity boundary. Passing Tier 1 or Tier 2 proves only that the currently visible file under the exact governed filename satisfies the applicable WASM-002 validation contract. It does not prove that those bytes are historically identical to bytes previously present under that filename. Cryptographic historical-byte identity belongs to separately governed fingerprint evidence rather than ordinary Store health. F-15 reference-bounded eligibility: Store-MAP structural validity and inheritance eligibility are determined from the MAP artifact itself plus the governed artifacts and values that the MAP explicitly binds or that its profile explicitly requires for the validation tier being applied. Unrelated Suitcase files, unrelated Store lineages, WKOs, Receipts, Inventories, CAT/HLP/CER artifacts, analyst-owned files, directory enumeration order, and unrelated-file count cannot by their mere presence or later appearance make an already-published Store MAP eligible or ineligible. Alias-shadowing validation is a successor-publication check under W002-STOR-020; it is not a continuing ambient scan that retroactively invalidates historical MAPs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.11,The MAP-bound RID filename is the stable physical Store identity anchor in WASM-002,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"For WASM-002, Data Sculptor does not allocate a second permanent Store UUID in addition to governed RID/MAP evidence. The exact governed rid_filename created when the Store is established is the stable physical anchor used to distinguish that Store's MAP lineage from other Stores in the same Suitcase, and every ordinary successor MAP repeats it exactly. Within any one MAP, every row must repeat the same exact current rid_filename ; disagreement is invalid. Across WASM-002 successor MAPs, a different RID filename denotes a different Store row universe and must not be silently treated as same-Store continuation. A later PRD revision may define an explicit governed recovery transition if Red5Sorcery chooses to support replacement of a damaged RID while preserving logical continuity. No such transition is executable in WASM-002.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-019.12,First Store MAP has deterministic Store and RID aliases,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"When the first successful materialization establishes a Store, its first Store MAP must initialize store_alias to the exact common source_filename and rid_alias to the literal RID . Those are the deterministic Store and RID default aliases. A later alias-only Work Order may replace them with STORE AS ""<alias>"" and RID AS ""<alias>"" , clear them with CLEAR STORE ALIAS / CLEAR RID ALIAS , or restore these defaults with RESET STORE ALIAS / RESET RID ALIAS under W002-WKO-012.1 through W002-WKO-012.6. None of those operations changes the common source_filename , rid_filename , RID bytes, COL bytes, or prior MAP history.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-001,CAT is the governed collection-level Store Catalog artifact,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"WASM-002 shall define CAT as a governed Data Sculptor artifact class for cataloging a collection of CSV Stores inside one active Suitcase. CAT exists to let an analyst orient across many independently governed Stores without opening every MAP individually. The scaling invariant is: MAP governs locally; CAT orients globally. CAT is an index over governed Store state, not a replacement for MAP and not a second Store authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-002,CAT may reference many Stores while every MAP still governs exactly one Store,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"A CAT may contain entries for many Store lineages in the active Suitcase. Every MAP referenced by CAT still governs exactly one Store lineage under the frozen one-Store-per-MAP rule. CAT must not combine multiple Stores into one MAP, synthesize a shared Store state, or centralize Store semantics that remain governed independently by each Store's MAP lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-003,CAT has one governed CSV representation and immutable snapshot identity,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The WASM-002 Store Catalog has one durable representation: UTF-8 CSV. WASM-002 shall not emit separate HTML and CSV companion CAT artifacts for one catalog snapshot. Each successful catalog publication creates one immutable governed artifact named exactly __DS__CAT__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv . A later catalog run publishes a new CAT snapshot; earlier CAT artifacts remain visible history and are not overwritten or deleted merely because a newer snapshot exists. For orientation, the directory may identify the newest structurally valid CAT snapshot by the canonical UTC token. If two or more structurally valid CAT artifacts share the greatest canonical UTC timestamp, the UI must not invent chronology from UUID, discovery order, or filesystem modified time; it must surface the ambiguity and may present the tied CAT artifacts together until a later governed catalog run publishes an unambiguous newer snapshot. F-14 publication: CAT is first written as __DS__SCR__<UTC>__<UUID>.csv using the UTC/UUID intended for the final CAT. The complete candidate must close, reopen, and validate the exact five-column schema, deterministic row ordering, row count and CSV serialization before the class token may be renamed to CAT . A failed candidate remains SCR/non-authoritative and must not be selected as a catalog snapshot.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-004,CAT CSV schema and row order are exact and deterministic,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The canonical CAT header row is exactly: store_alias,source_filename,rid_filename,map_filename,store_health Each data row describes one routable Store lineage using values derived from the authoritative current structurally valid Store MAP selected under the existing Store rules: store_alias — current human-facing Store identity; source_filename — the one common exact source filename carried by that Store MAP and used for Store routing; rid_filename — exact immutable governed RID filename that physically identifies the Store lineage; map_filename — exact current structurally valid Store MAP used to derive the row; and store_health — the Store health evaluated during this CATALOG STORES run, exactly one of VALID , DEGRADED , or INVALID . store_health is snapshot orientation metadata, not MAP health and not an independent health authority. If the Suitcase later changes, an older CAT row continues to report the health value observed when that CAT was created. CAT rows are sorted by ascending exact UTF-8 bytes of map_filename . The header is not part of that ordering.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-005,CAT is reconstructible and never becomes Store authority,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"CAT shall be reconstructible from authoritative Store MAP artifacts and the governed Store-health evaluation applied when CATALOG STORES runs. CAT must never be consulted to decide Store routing, inheritance, Store health, repair eligibility, current MAP selection, RID/COL validity, or whether a new Store may be established. If a CAT row conflicts with authoritative MAP/Store state, current governed state wins and the CAT is stale/inconsistent. A stale CAT remains an inspectable historical governed artifact but must not be treated as current Store truth. CAT is not automatically updated by materialization, repair, alias change, or any other Store-changing operation. The analyst creates a fresh catalog explicitly by running a new CATALOG STORES Work Order; success publishes a new immutable CAT snapshot and leaves earlier CAT snapshots visible history.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-006,CATALOG STORES is the standalone governed Work Order operation,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 Work Order form is: SUITCASE: .
WORK ORDER AS ""Catalog Stores""
CATALOG STORES CATALOG STORES is one standalone top-level operation. It is initiated only by an explicit analyst Work Order. No materialization, repair, alias update, conversion, or other governed operation automatically creates, rewrites, or refreshes CAT. The operation scans authoritative governed Store MAP state, evaluates each cataloged Store's current health, and publishes one CAT snapshot plus the normal canonical Receipt. It does not mutate any Store or MAP. It must not also request materialization, conversion, alias mutation, repair, Inventory, Work Order composition, or another consequential operation in the same WKO. The canonical Receipt operation token is CATALOG_STORES .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-007,CATALOG STORES derives one row per routable Store lineage from authoritative MAP state,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"The catalog scan shall identify every routable Store lineage using the same structurally-valid-MAP routing definition already frozen for WASM-002. For each routable lineage, Data Sculptor evaluates current Store health exactly under W002-STOR-019.2, using the current structurally valid Store MAP selected under W002-STOR-019.10 and the applicable validation tier, and records exactly one of VALID , DEGRADED , or INVALID . Catalog presence is orientation, not permission to perform another operation. Exactly one CAT row is emitted for each routable Store lineage, derived from that lineage's authoritative current structurally valid Store MAP and the Store-health result observed during this catalog run. If the complete authoritative collection state cannot be determined unambiguously, the operation must refuse rather than publish a knowingly incomplete or guessed CAT. CATALOG STORES is read-only with respect to all pre-existing Store, RID, COL, MAP, source, WKO, and other Suitcase artifacts. It does not repair or mutate them.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-008,CAT publication is all-or-refuse and historical CAT snapshots remain visible,W002-CAT,W002-CAT,WASM-002,UNDER REVIEW,—,"After the complete deterministic CAT row set is established, publication follows the governed all-or-refuse artifact path: write the candidate under governed scratch, close and reopen it, validate its exact filename, UTF-8/LF CSV structure, exact header, deterministic row count/order, and row references, then promote the final CAT artifact. The CAT is not successfully published until final promotion succeeds. A publication refusal leaves prior CAT snapshots and all Store/MAP state unchanged. The Receipt records whether the catalog entry count was established and whether a final CAT filename was published.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-001,CAT and MAP discovery reuse the existing Suitcase Directory,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,WASM-002 shall reuse the existing Data Sculptor Suitcase Directory for CAT and MAP discovery and inspection. A separate CAT/MAP browser panel shall not be added.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-002,CAT and MAP artifacts are first-ranked in the existing directory,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The newest unambiguous structurally valid CAT snapshot, or any tied newest CAT candidates when chronology is ambiguous, and all Store MAP artifacts shall be surfaced prominently at the top of the existing Suitcase Directory ahead of ordinary Suitcase files. The presentation may be pinned, grouped, or otherwise first-ranked, provided the priority is obvious and deterministic.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-003,CAT and MAP contents are immediately viewable from the existing HTML UI,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,The analyst shall be able to select a visible CAT or MAP entry and inspect its contents through the existing read-only HTML UI without first locating or opening the artifact through the operating-system file browser.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-004,CAT/MAP prominence preserves ordinary read-only Suitcase filtering,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The Suitcase Directory may continue to provide read-only filtered views of other Suitcase files. CAT/MAP prominence must not remove, replace, or weaken the existing ability to inspect the rest of the flat Suitcase.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-005,Directory browsing and inspection do not require a Work Order,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"Browsing, sorting, UI filtering, selecting, opening, and viewing Suitcase files are read-only inspection actions and shall not require a Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-006,Read-only directory filtering is not governed SEARCH,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"Read-only UI filtering is not the same operation as governed SEARCH . Governed SEARCH, ZIP creation, metadata changes, repairs, CAT regeneration, and every other consequential state change remain subject to the applicable Work Order and Receipt discipline.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-007,"The directory cannot mutate CAT, MAP, Store, or Suitcase state",W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The Suitcase Directory shall not edit, rename, delete, repair, replace, regenerate, or otherwise mutate CAT, MAP, Store, or Suitcase state through direct GUI manipulation. Consequential changes occur only through explicit governed operations or analyst-owned filesystem actions already permitted by the canonical contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-UI-008,The CAT/MAP directory view must remain practical at large collection scale,W002-CAT-UI,W002-CAT,WASM-002,UNDER REVIEW,—,"The CAT/MAP presentation shall make collections containing dozens or hundreds of Stores practical to inspect. An analyst must be able to understand what Stores exist, which current MAP describes each Store, and which source file each Store governs without manually opening every MAP artifact through the operating-system file browser.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CAT-ACC-001,CAT acceptance proves collection-scale orientation without centralizing Store authority,W002-CAT-ACC,W002-CAT,WASM-002,UNDER REVIEW,—,"Acceptance must include a MusicBrainz-scale fixture containing 177 routable CSV Store lineages, each with its own authoritative current Store MAP. One explicit analyst-run CATALOG STORES Work Order must publish exactly one CAT snapshot containing exactly 177 data rows under the frozen five-column schema store_alias,source_filename,rid_filename,map_filename,store_health and deterministic MAP-filename ordering. The fixture must include Stores that evaluate VALID , DEGRADED , and INVALID while retaining structurally valid current MAPs, and the CAT must record the exact health observed for each Store when the catalog run occurs. The CAT must not expose a separate MAP-health field. The existing Suitcase Directory must surface CAT and MAP artifacts ahead of ordinary files; the analyst must be able to open CAT, inspect the collection, select and view MAP artifacts, sort/filter the directory, and inspect other Suitcase files without a Work Order. No direct GUI mutation path may be exposed. Acceptance must alter authoritative MAP/Store state after the first CAT publication and prove that the earlier CAT is neither rewritten nor automatically refreshed. It remains visible and becomes stale/inconsistent where appropriate. Only a later explicit CATALOG STORES Work Order may reconstruct the collection and publish a new immutable CAT snapshot. The linked WASM-003 DIR behavior remains outside the WASM-002 implementation scope: later DIR requirements auto-populate human-readable CAT/MAP descriptions, but those descriptions never become authority over CAT, MAP, or Store semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-020,"Store, RID, and COL aliases remain human-facing metadata separate from physical identity",W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Aliases are governed human-facing metadata. Creating, changing, clearing, or replacing an alias must not rename or rewrite the underlying artifact. Within one Store MAP, every non-empty COL alias and the non-empty rid_alias must be unambiguous within the row-addressable artifact alias namespace under the exact Unicode scalar-value comparison rule in PB-STOR-010. F-15 publication-time shadowing boundary: alias uniqueness and physical-name shadowing are validated when a candidate successor Store MAP is being published, against the comparison domain applicable to that one Store snapshot and the then-visible governed physical targets it makes row-addressable. If an alias would exactly collide with another addressable alias or physical filename in that publication domain, publication refuses. After a Store MAP has been validly published, the later appearance, disappearance, rename, or copying-in of an unrelated Suitcase file does not retroactively make that immutable MAP structurally invalid or ineligible. A later textual reference can still become ambiguous at resolution time under W002-STOR-021; that ambiguity causes the later operation to refuse rather than changing the historical MAP's validity. The store_alias names the Store as a whole and is separate from the field/COL alias namespace. Alias mutation occurs through a governed Work Order, not through an editable GUI field. Exact cross-Store Store-alias uniqueness and future selection-by-Store-alias syntax remain outside this freeze.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-021,Work Order resolution binds one exact Store MAP and physical targets,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A saved Work Order may refer to governed materialized columns by exact physical filename or by a unique COL alias from one selected Store MAP. The canonical explicit Store-MAP selector is MAP ""<exact Store MAP filename>"" under W002-STOR-019.3 and W002-WKO-012.3. If that clause is present and valid, exactly that Store snapshot is used. Otherwise Data Sculptor applies the Store-aware source-qualified selection rule in W002-STOR-019.2. All textual physical-filename and COL-alias comparisons in this resolution step use exact Unicode scalar-value sequence equality under PB-STOR-010: no case folding, Unicode normalization, trimming, locale equivalence, or filesystem enumeration heuristic is permitted. Resolution is bounded to the selected Store snapshot and the physical targets/aliases that are addressable through that snapshot. If the supplied text has no exact target, resolution refuses. If it has more than one exact possible target in that domain—for example because a currently visible physical filename and a current alias are both exact matches—resolution also refuses. Data Sculptor must not choose filename over alias, alias over filename, first-found entry, directory order, modified time, UUID, or any other tie-break heuristic. Before execution, Data Sculptor must record the exact physical Store MAP identity when one is used, bind the run to its exact rid_filename , and resolve aliases deterministically to physical COL artifacts. The selected Store MAP must remain fixed for the run even if a newer MAP is created during that same run. This protects Store/selection continuity but does not by itself claim that bytes stored under an analyst-owned source filename are cryptographically identical across different runs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022,Each successful Suitcase validation publishes one retained governed CER HTML certificate,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"A selected directory becomes a validated Suitcase only when Data Sculptor successfully creates, completely writes, and closes one governed CER HTML Suitcase Validation Certificate in that directory. The certificate itself is the validation artifact and remains visible in the flat Suitcase as durable evidence. No validation-only delete or rename is required. Failure to create, completely write, or close the certificate means the directory has not passed Suitcase validation and analytical execution remains locked. F-14 CER exception: the CER is deliberately not staged as SCR . Suitcase validation is specifically the direct create/write/close test of the final canonical CER identity in the selected directory. Inserting an SCR-to-CER rename would test a different publication path and is therefore forbidden for this validation step. A successful CER does not pre-certify later SCR-to-final renames for other artifact classes. F-24 CER lifecycle: every successful explicit Suitcase selection and validation publishes exactly one fresh immutable CER with a new governed UTC+UUID identity. Data Sculptor must not satisfy a new validation event by reusing an earlier CER. Every prior valid CER remains a standalone historical artifact under its original governed filename and exact bytes. WASM-002 performs no automatic CER deletion, replacement, compaction, or CER-history ZIP packaging. Historical CERs are not housekeeping candidates merely because a newer CER exists. Any later archival or packaging capability must be separately governed and explicitly invoked; it is not part of the WASM-002 validation lifecycle.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.1,Suitcase Validation Certificate physical identity and longest-name path gate,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The exact certificate filename is __DS__CER__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html , using the canonical UTC millisecond token and canonical lowercase hyphenated UUID v4. Data Sculptor chooses the filename; the analyst does not supply or edit it. The CER create/write/close test begins only after the browser host has satisfied the required user-selected writable-directory capability in W002-PLAT-001. A browser that cannot expose that capability produces a host-capability refusal before folder validation; that condition is not evidence that any particular directory is unwritable or filename-incompatible. WASM-002 path/filename acceptance must derive the maximum filename length from every governed final-artifact filename form and every governed SCR staging form that this build can actually emit. Under the current contract, the maximum is 73 ASCII bytes/characters : the governed .html CER/HLP final forms and an SCR candidate reserved for a .html final artifact have that length. The canonical CER filename therefore exercises the current maximum emitted filename length during the create/write/close validation test. On a supported host, successful create/write/close of this canonical governed HTML filename is the WASM-002 folder filename/path compatibility test for the current emitted-name maximum. Data Sculptor does not maintain a product-level table of operating-system numeric path maxima and must not truncate, abbreviate, hash-shorten, or otherwise mutate a governed filename to fit a host path limitation. If the certificate cannot be created under its canonical name after a directory has actually been selected through the supported-host contract, the selected directory does not pass validation. If a future PRD revision introduces an emitted final or staging filename longer than the current CER/HLP/SCR-HTML maximum, acceptance must detect that change and explicitly exercise the new maximum before the build may rely on this path-compatibility claim.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.2,Suitcase Validation Certificate semantic content,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The HTML certificate uses the canonical built-in Data Sculptor presentation and must visibly contain, at minimum: SUITCASE VALIDATION CERTIFICATE RESULT: PASS SUITCASE: . UTC: <canonical certificate UTC> UUID: <certificate UUID> ARTIFACT: <full governed certificate filename> TEST: CREATE_WRITE_CLOSE It must state that Data Sculptor successfully created, completely wrote, and closed this governed HTML certificate in the selected Suitcase. It must state that this establishes that the selected directory was writable by Data Sculptor at the recorded UTC and accepted the governed artifact filename used for the certificate. It must also state that the certificate does not certify available disk capacity, guarantee success of future analytical operations, or certify later SCR -to-final-class publication/rename operations. The semantic record uses SUITCASE: . and must not persist an absolute machine-specific path merely to prove validation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-022.3,Suitcase Validation Certificate uses the canonical built-in presentation in WASM-002,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The certificate is a human-facing HTML CER artifact and uses the canonical built-in Red5Sorcery/Data Sculptor presentation in WASM-002. Presentation must never change RESULT , SUITCASE , UTC, UUID, artifact identity, TEST , validation meaning, or limitation facts. Configurable Brand Manifest application to CER artifacts is deferred to V1-BACKLOG / a future build and is not required for WASM-002 Suitcase validation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-023,Non-Store governed artifacts use class-specific all-or-refuse publication profiles,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"Except for the deliberate CER Suitcase-validation path below, WASM-002 does not place a newly generated durable artifact into its final semantic class merely because candidate bytes exist. The complete candidate is first written under the governed SCR identity defined by W002-STOR-023.1, closed, reopened, and validated against the target class contract. Only a candidate that passes its class-specific publication predicate may be renamed into the intended final class. A final-class filename therefore records successful class publication, not broader authority where a separate MAP/registry relationship governs authority. F-33 reserved-class boundary: DGN , RCV , BRD , and LCK are registered but not emitted by WASM-002, so they do not appear as publication profiles in this table and have no WASM-002 producer here. Final class Final serialization / identity Publication predicate Authority boundary WKO __DS__WKO__<UTC>__<UUID>.txt The complete candidate obeys the saved-Work-Order lifecycle and parses completely under exactly one WASM-002 executable operation grammar with the required SUITCASE: . , exactly one non-whitespace WORK ORDER AS alias, and the governed lexical/comment rules. Applicable save-time alias/registry gates must also pass before the save transaction may commit. Promotion proves a valid immutable WKO artifact. Alias-registry authority is not committed until the complete successor WKO MAP is successfully published under W002-STOR-018.3. RCP __DS__RCP__<UTC>__<UUID>.txt The complete candidate validates against W002-RCP-005 through W002-RCP-008: exact deterministic TXT serialization, common envelope, applicable operation-specific key table, governed absence semantics, and created-artifact tail. Publication creates durable run evidence only. It does not retroactively create or change analytical state. HLP __DS__HLP__<UTC>__<UUID>.html The complete self-contained HTML satisfies the HLP disclosure, presentation, provenance, embedded-JSON, lineage and semantic-parity rules in W002-HELP-009 and related Help requirements. Publication creates durable Help/support evidence. It does not override the underlying diagnostic event or analytical state. CVT __DS__CVT__<UTC>__<UUID>.csv The bounded Windows-1252 conversion completes, the original analyst-owned source remains unchanged, the converted bytes pass the governed strict UTF-8 requirement, and the candidate closes/reopens successfully. Structural CSV interpretation remains a later certification/materialization concern. The published exact CVT filename is a new immutable governed source identity for later routing under W002-CONV-004. INV __DS__INV__<UTC>__<UUID>.txt The complete inventory scan has established the governed entry set and the candidate validates the deterministic INV serialization, count, metadata availability and ordering rules. Publication creates an immutable inventory snapshot; it is evidence/orientation, not Store authority. CAT __DS__CAT__<UTC>__<UUID>.csv The authoritative MAP discovery/evaluation pass has completed and the candidate validates the exact five-column CAT schema, row count, row ordering and deterministic CSV rules. Publication creates an immutable collection-level orientation snapshot. MAP remains authoritative for each Store. CER __DS__CER__<UTC>__<UUID>.html Deliberate exception: Suitcase validation directly creates, completely writes and successfully closes the final CER identity under W002-STOR-022 through W002-STOR-022.3. No SCR staging/rename is inserted into this test. The CER proves that canonical governed create/write/close succeeded in the selected directory at that recorded moment. It does not pre-certify later SCR-to-final publication. RID, COL, Store MAP and WKO MAP publication retain their specialized transaction/commit rules elsewhere in this PRD. W002-STOR-023 does not replace those state-publication contracts; W002-STOR-023.1 supplies the shared SCR candidate identity and retained-failure-evidence boundary they may reference.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STOR-023.1,SCR candidates preserve intended final identity; retained failure evidence remains non-authoritative,W002-STOR,W002-STOR,WASM-002,UNDER REVIEW,—,"The canonical candidate filename for a staged governed artifact is: __DS__SCR__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.<final-extension> The SCR candidate uses the exact UTC token, UUID and extension reserved for its intended final artifact. Successful publication changes only the three-letter semantic class token from SCR to the intended final class. For example, an RCP candidate __DS__SCR__20261006T190000000Z__<uuid>.txt may become __DS__RCP__20261006T190000000Z__<uuid>.txt only after the complete candidate has been closed, reopened and validated against the RCP publication predicate. The rename must not alter candidate bytes, UTC, UUID or extension. An SCR filename never by itself confers final-class validity, Store membership, registry authority, execution authority, or durable final-class evidence status. A retained SCR whose bytes happen to satisfy a target validator after an interrupted or refused transaction must not be auto-promoted, silently adopted, or treated as if the missing publication step occurred. F-33 retained-failure-evidence boundary: when a handled failure leaves one or more SCR candidates or other staged bytes that cannot be safely removed or restored, they must remain visible only as non-authoritative SCR evidence. WASM-002 does not publish an RCV recovery manifest. Retention must not complete or simulate the failed publication step, and the governed diagnostic/Help path must report the failure using only facts actually established. A retained or orphaned SCR remains non-authoritative even if its bytes later validate. Data Sculptor must not infer an intended final class solely from extension or byte content, must not rename or promote the SCR merely because it survives a later scan, and must not create a replacement RCV sidecar to manufacture attribution that the failed transaction did not durably preserve.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-011; CP-012; CP-013; CP-014; CP-015,"CP011 T-ACCEPTED, GIT BANKED — exact CVT-to-SCR candidate identity derivation only; full SCR lifecycle and publication contract remains open; CP012 T-ACCEPTED, GIT BANKED — canonical SCR staging filename recognition only; generic publication, recovery and authority remain unimplemented; CP013 T-ACCEPTED, GIT BANKED — explicit SCR-to-RCP final filename candidate derivation only; no complete SCR lifecycle, RCP validator, filesystem promotion, publication or authority; CP014 T-ACCEPTED, GIT BANKED — related RCP final-candidate lexical recognition only, no SCR creation or publication; CP015 T-ACCEPTED, GIT BANKED — pure lexical canonical SCR-to-RCP TXT filename-candidate pair matching only; no actual file/Receipt validation, promotion, publication or authority",e84ae5baeee05f9d5d30284c65b86eebba3c0f6a; efca04392940e398020a5c06b9ee50296c8a1fdd; 005a38ef5e876847c4c08901c18da9c18565fd6b; f5038a183f1d3dc31b0065571bf8ac8814b5d8a9; be997dc0dbd65fc370814c4a5f2d0f1254870572,"Evidence/CP-011/CP011_Scope_Lock.txt; Evidence/CP-011/CP011_RED_Test_Output.txt; Evidence/CP-011/CP011_GREEN_Test_Output.txt; Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt; Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt; Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt; Evidence/CP-011/CP011_Hash_Inventory_Verification.txt; Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt; Evidence/CP-011/CP011_Closing_Git_Review.txt; CP011_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-012/CP012_Scope_Lock.txt; Evidence/CP-012/CP012_RED_Test_Output.txt; Evidence/CP-012/CP012_GREEN_Test_Output.txt (initial 5/6, retained); Evidence/CP-012/CP012_GREEN_Failure_Triage.txt; Evidence/CP-012/CP012_GREEN_Correction_Review.txt; Evidence/CP-012/CP012_GREEN2_Test_Output.txt; Evidence/CP-012/CP012_Full_Regression_Test_Output.txt; Evidence/CP-012/CP012_WASM_Build_Output.txt; Evidence/CP-012/CP012_Final_Rustfmt_Check.txt; Evidence/CP-012/CP012_Hash_Inventory_Verification.txt; Evidence/CP-012/CP012_Supplementary_Hash_Verification.txt; Evidence/CP-012/CP012_Post_Staging_Hash_Verification.txt; Evidence/CP-012/CP012_Closing_Git_Review.txt; CP012_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-013/CP013_Approved_Scope_Lock.txt; Evidence/CP-013/CP013_RED_Test_Output.txt; Evidence/CP-013/CP013_GREEN_Test_Output.txt; Evidence/CP-013/CP013_Full_Regression_Test_Output.txt; Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt; Evidence/CP-013/CP013_WASM_Build_Verification.txt; Evidence/CP-013/CP013_Hash_Inventory_Verification.txt; Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt; Evidence/CP-013/CP013_Closing_Hash_Verification.txt; Evidence/CP-013/CP013_Final_Staging_Verification.txt; Evidence/CP-013/CP013_Closing_Git_Review.txt; CP013_Git_Banking_Output.txt (post-commit, separately preserved); Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip; Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip; CP014_Git_Banking_Record.txt (external closeout); Evidence/CP-015/ZIP/CP015_RED_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_GREEN_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_PostAmend_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_Full_Regression_Test_Output.txt.zip; Evidence/CP-015/ZIP/CP015_WASM_Build_Output.txt.zip; Evidence/CP-015/ZIP/CP015_Final_Archive_Manifest.txt.zip; CP015_PostCommit_Verification.txt (external closeout)","CP011 Day066: public pure helper build_scr_candidate_filename_for_cvt(&str)->Option<String> accepts an exact canonical governed CVT .csv filename (via CP010 recognizer) and derives the paired SCR filename by substituting only class token CVT -> SCR, preserving exact UTC, UUIDv4 and lowercase .csv bytes; rejects wrong classes, paths, whitespace, malformed clock/date/UUID, extension and class case. Six targeted tests; RED expected E0432 exit 101; GREEN 6/6; post-format native regression 46/46; rustfmt recheck PASS; Rust 1.97.1 wasm32-unknown-unknown --lib build PASS; original 28/28 and combined 36/36 SHA-256 records verified. Two local scoped .gitattributes whitespace exceptions preserve Rustfmt/Git diagnostic TXT bytes; final Git staged check PASS. T-approved and Git banked e84ae5baeee05f9d5d30284c65b86eebba3c0f6a, 27 committed files, working tree clean. Lexical candidate-name pairing ONLY; no SCR creation, bytes, converter, transaction, close/reopen, validation/publication, retained SCR adoption, SOURCE authority or browser execution. Independent Claude implementation QA pending. CP012 Day066: pure public bool recognizer is_canonical_scr_filename_candidate(&str) validates exact uppercase SCR staging class via shared canonical immutable filename-token parser, with local rejection of whitespace and both path separators; accepts canonical .csv and .txt SCR candidates without assuming extension or bytes confer intended final class, validity, publication or authority. RED expected missing import E0432 exit 101. Initial GREEN 5/6 exposed trailing whitespace acceptance through generic extension grammar, retained verbatim; controlled CP012-local correction yielded 6/6 PASS. Full native regression 52/52 PASS, Rustfmt 12 Rust files checked/0 modified, canonical Rust 1.97.1 wasm32-unknown-unknown --lib build PASS (not browser execution). Primary independent SHA256/size inventory 29/29 PASS; supplementary original 4/4 PASS; post-staging 6-record amendment independently verified following narrowly scoped trailing-space and blank-at-EOF git attributes for preserved diagnostic evidence; final staged Git whitespace exit 0. T approved and banked Git commit efca04392940e398020a5c06b9ee50296c8a1fdd (28 committed files; master clean). Previous generic canonical parser unchanged. W002-STOR-023.1 remains PARTIAL, no filesystem creation, close/reopen, class publication, retained/orphan SCR adoption or recovery, SOURCE authority, or independent Claude implementation QA claimed. CP013 Day066: pure public function build_final_filename_candidate_for_scr(&str, &str)->Option<String> accepts only a canonical SCR staging filename with exact lowercase .txt serialization and explicit intended_final_class == ""RCP""; derives RCP final filename candidate by substituting the SCR semantic-class token only, preserving original UTC token, UUID and extension. Rejects all other class intentions, malformed or non-SCR staging names, paths/whitespace, wrong extension or case. Six intentional RED tests (unresolved E0432 before implementation), six GREEN targeted passes; full native 58/58 PASS; Rust 1.97.1 rustfmt check PASS and wasm32-unknown-unknown --lib build PASS (not browser runtime). Primary 21/21, supplementary 27/27 before attribute revisions; post-normalization 32/32 and closing 37/37 SHA-256 identity/byte-preservation checks; 42/42 commit blobs verified, Git whitespace check exit 0 after directory-scoped CRLF-aware whitespace attributes and raw-byte preservation; staging failures and adjustments retained byte-for-byte. T accepted and Git banked 005a38ef5e876847c4c08901c18da9c18565fd6b (efca04392940e398020a5c06b9ee50296c8a1fdd parent), 42 files, clean tree and index. This covers only lexical candidate-name derivation under already-PARTIAL W002-STOR-023.1; W002-STOR-023 remains NOT_STARTED; no SCR creation, RCP contract validation, promotion, publication, retained/orphan handling, authority or recovery. No independent adversarial QA or accepted end-to-end requirements; Day066 OPEN. CP014 Day067: T-accepted, Git-banked lexical RCP .txt filename recognizer only. Pure is_canonical_rcp_filename_candidate(&str)->bool uses shared canonical envelope, rejects wrong class/extension/casing, malformed UTC/UUID, paths and whitespace. Six target GREEN passes; 64/64 native regression; Rustfmt and wasm32 library build PASS; 32 original-TXT-per-ZIP objects validated and committed unchanged. Commit f5038a183f1d3dc31b0065571bf8ac8814b5d8a9. No new Receipt timestamp generation, Receipt byte serialization, creation/promotion/publication or authority; independent implementation QA and browser runtime pending. CP015 Day067: T-approved pure is_matching_scr_rcp_filename_candidate_pair(&str,&str)->bool checks canonical SCR/RCP lowercase .txt candidates and exact timestamp/UUID pairing, reusing existing lexical recognizers and candidate derivation; rejects wrong classes/order, mismatched timestamps/UUID, paths, whitespace and noncanonical envelopes. Expected RED E0432 exit 101; six targeted GREEN PASS; T-approved formatting-only source+test amendment and recheck; full native regression 70/70 PASS, Rustfmt PASS, Rust 1.97.1 wasm32-unknown-unknown --lib compile PASS. Original TXT archived as 16 verified single-entry ZIPs; 18/18 committed Git blob identities checked; working tree clean. Banked at be997dc0dbd65fc370814c4a5f2d0f1254870572. No actual SCR/RCP file reads, Receipt content validation, timestamp generation, authority, promotion or publication; browser execution and independent implementation QA pending.",Day067,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001,Strict whole-file UTF-8 certification,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Before WASM-002 performs analytical CSV materialization, it must certify the complete selected source as valid UTF-8 using bounded processing.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.1,"Certification must examine the entire source, not merely a prefix, sample, BOM, or first analytical window.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.2,"UTF-8 validity must be determined across chunk boundaries, including incomplete multi-byte sequences that span adjacent input windows.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.3,"A UTF-8 BOM, when present, is parsing metadata and must not be treated as proof that the remainder of the source is valid UTF-8.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.4,Certification must preserve exact source-byte accounting.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.5,Certification must operate within the governed WASM memory budget.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Stage 1 UTF-8 certification must remain bounded independently of source byte length and must not buffer the complete source, CSV header, or CSV row set in memory. CSV column-count and operational-name rules belong to Stage 2 and must not be used to justify unbounded Stage-1 state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-001.6,Certification must produce deterministic PASS or FAIL for the same source bytes under the same frozen rules.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002,UTF-8 certification is a hard analytical gate,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,The WASM-002 analytical/materialization path must proceed only after successful UTF-8 certification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.1,"If UTF-8 certification fails, the current analytical Work Order must stop.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.2,The analytical engine must not silently switch to another decoder.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.3,The analytical engine must not continue materialization under an inferred or guessed source encoding.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-002.4,No Windows-1252 transcoding may occur as an implicit sub-step of the failed analytical Work Order.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003,Certification and materialization share one run-local selected source,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"For a governed WASM-002 analytical run, the browser host must resolve the Work Order source reference once and retain the same selected source instance across Stage 1 UTF-8 certification and Stage 2 materialization. The purpose of this binding is to prevent Stage 2 from accidentally consuming a different source than the one Stage 1 certified. It is a run-local continuity guarantee, not a claim of durable cryptographic identity across separate runs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.1,Stage 2 must not re-resolve or substitute the source,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"After Stage 1 begins, Stage 2 must not reacquire the analytical source by re-reading an alias mapping, re-resolving a filename/path, opening a newly selected browser file, or otherwise substituting another source instance. Stage 2 consumes the source instance already bound to the governed run.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.2,"Filename, alias, path, or byte length alone is not durable byte identity",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"Filename equality, alias equality, path equality, timestamps, or exact byte length may be useful provenance facts but must not be presented as cryptographic proof that source bytes are identical across separate runs. WASM-002 makes no such automatic cross-run exact-byte claim.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.3,Ordinary WASM-002 source binding does not require automatic SHA-256,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,UTF-8 certification and ordinary column materialization must not automatically compute SHA-256 merely to establish WASM-002 source binding. The source-binding requirement is satisfied by preserving the same run-local selected source instance across the two stages. This rule does not prohibit SHA-256 where another explicit WASM-002 requirement governs integrity for a specific generated artifact. It applies to automatic hashing of ordinary analytical source data.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-003.4,Loss of run-local source continuity causes refusal,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"If the browser host cannot preserve the selected source instance from certification into materialization, or the source becomes unavailable before Stage 2 can consume it, the analytical run must refuse before materialization rather than silently reselect, substitute, or infer another source.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004,ASCII-first inline UTF-8 certification algorithm,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"WASM-002 must use an ASCII-first, strict inline UTF-8 certification algorithm or an equivalent implementation that preserves the same single-forward-scan semantics, bounded state, deterministic validity result, exact error location, and performance intent established by WASM-001b.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.1,The certifier must process the source in bounded windows and must not allocate memory proportional to source-file size.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.2,"The 4 MiB window used in WASM-001b is a proven reference point, not a frozen WASM-002 production constant.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Window size may be changed only if semantics and byte-identical certification outcomes remain invariant.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.3,"At the beginning of each window, any incomplete UTF-8 sequence carried from the preceding window must be resolved before the remaining bytes are treated as independent input.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.4,"When there is no pending cross-window sequence, consecutive bytes below 0x80 must be recognized as ASCII and certified directly because ASCII is a complete subset of UTF-8.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.5,An all-ASCII window with no pending cross-window sequence must be certifiable without submitting the same bytes to a second general UTF-8 decoder pass.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.6,"When a byte at or above 0x80 is encountered, the certifier must validate the UTF-8 sequence inline, then resume the ASCII-fast scan after the valid sequence.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.7,"The implementation must not require collecting all non-ASCII bytes, all non-ASCII runs, or all non-ASCII offsets for later validation.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.8,The implementation must not require a separate general-purpose string-decoder call for each non-ASCII sequence.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,An equivalent low-overhead strict validator is acceptable if it preserves the same governed result and bounded-state behavior.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.9,Cross-window state must be bounded to the information required for at most one incomplete UTF-8 sequence.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"No more than three source bytes may need to remain pending between windows, or an equivalent smaller state representation may be used.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.10,"On the first invalid UTF-8 sequence, certification must stop and report the exact absolute source-byte offset required by the frozen error contract.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"On the first invalid UTF-8 sequence, certification must stop and return FAIL . The governed UTF-8 refusal evidence is: FIRST_INVALID_BYTE_OFFSET — the zero-based absolute byte offset of the first byte of the invalid sequence , counted from the first physical source byte, including a permitted leading UTF-8 BOM when present; and STOP_REASON — exactly INVALID_UTF8_SEQUENCE . For an EOF-truncated multibyte sequence, FIRST_INVALID_BYTE_OFFSET is the absolute offset of that incomplete sequence's lead byte, not the EOF position. The certifier need not read the remainder of an already-invalid source. Input-window boundaries must not change the outcome, stop reason, or first-invalid offset. F-16 follow-on boundary: stopping strict UTF-8 certification at the first invalid sequence does not make the remainder of the source irrelevant to conversion advice. When the governing operation is MATERIALIZE and Stage 1 reaches FAIL , the analytical run remains refused; Data Sculptor then starts the separate read-only compatibility assessment in W002-CONV-002 from physical byte offset 0 of the same bound source instance. That second pass may read to EOF solely to determine converter compatibility. Stage 2 must not start.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.11,"At EOF, certification may return PASS only if every source byte has been consumed under the strict UTF-8 rules and no incomplete sequence remains pending.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"At EOF, certification may return PASS only if every physical source byte has been consumed under the strict UTF-8 rules and no incomplete sequence remains pending. The completed Stage-1 outcome vocabulary is exactly PASS and FAIL . PASS means strict whole-source UTF-8 certification completed successfully. FAIL means an invalid UTF-8 sequence was deterministically established under W002-ENC-004.10. The common Receipt absence tokens remain separate from those completed outcomes: NOT_RUN when Stage 1 never begins, and NOT_AVAILABLE when Stage 1 begins but a separate failure prevents a governed PASS/FAIL conclusion. NOT_APPLICABLE is not a completed value for STAGE1_UTF8_OUTCOME .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.12,"A UTF-8 BOM at absolute source offset zero may be recognized as BOM metadata after its bytes are validated, but the remaining source must still undergo complete certification.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.13,"The certifier must not perform CSV delimiter, quote, header, row, or analytical interpretation.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Certification answers only whether the complete source byte stream is valid UTF-8 under the frozen rules.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.14,Certification results must be independent of window boundaries.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,Splitting the same valid or invalid source at different bounded window sizes must not change PASS/FAIL or the first invalid absolute byte offset.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-004.15,"The certifier must expose enough measured counters for acceptance evidence to reconcile source bytes read, windows/pushes processed, non-ASCII sequences encountered when counted, final pending state, and stop reason without requiring those counters to alter certification semantics.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005,Strict UTF-8 byte-sequence rules,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"The inline validator must implement strict modern UTF-8 validity, excluding overlong forms, UTF-16 surrogate code points, values above U+10FFFF, invalid lead bytes, invalid continuation bytes, and truncated sequences. F-07 stop-reason vocabulary: all strict UTF-8 invalidity classes governed by this requirement—lone continuation bytes, malformed continuation sequences, overlong forms, surrogate encodings, values above U+10FFFF, invalid lead bytes, and EOF-truncated sequences—serialize the single machine reason token INVALID_UTF8_SEQUENCE . The specific fixture category is acceptance evidence; the canonical stop reason intentionally does not duplicate validator-library-specific subcodes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.1,Single-byte ASCII is 0x00 through 0x7F.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.2,Two-byte sequences must begin with 0xC2 through 0xDF and be followed by exactly one continuation byte 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.3,"Three-byte sequences beginning with 0xE0 must use a second byte 0xA0 through 0xBF and a third byte 0x80 through 0xBF, preventing overlong encodings.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.4,Three-byte sequences beginning with 0xE1 through 0xEC or 0xEE through 0xEF must use two continuation bytes 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.5,"Three-byte sequences beginning with 0xED must use a second byte 0x80 through 0x9F and a third byte 0x80 through 0xBF, excluding UTF-16 surrogate halves.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.6,"Four-byte sequences beginning with 0xF0 must use a second byte 0x90 through 0xBF followed by two continuation bytes 0x80 through 0xBF, preventing overlong encodings.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.7,Four-byte sequences beginning with 0xF1 through 0xF3 must use three continuation bytes 0x80 through 0xBF.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.8,"Four-byte sequences beginning with 0xF4 must use a second byte 0x80 through 0x8F followed by two continuation bytes 0x80 through 0xBF, preventing code points above U+10FFFF.",W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.9,Bytes 0x80 through 0xBF are invalid when encountered as lead bytes.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.10,Bytes 0xC0 and 0xC1 are invalid lead bytes because they can only introduce overlong encodings.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-005.11,Bytes 0xF5 through 0xFF are invalid UTF-8 lead bytes.,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"ASCII-first inline UTF-8 certification algorithm READ NEXT BOUNDED WINDOW Reference evidence used 4 MiB windows RESOLVE PENDING CROSS-WINDOW STATE At most one incomplete UTF-8 sequence ASCII FAST SCAN Advance cheaply while every byte < 0x80 ASCII RUN Already valid UTF-8 RESUME SCAN Same window BYTE >= 0x80 Validate sequence inline STRICT UTF-8 Lead + continuation range rules VALID END OF WINDOW? Persist only bounded carry state MORE SOURCE? Yes: read next window; No: finish EOF + NO PENDING STATE UTF-8 PASS INVALID OR TRUNCATED UTF-8 FAIL No full-file allocation. No collection of all non-ASCII bytes. No per-sequence general string decode required. Figure 2. The WASM-001b-derived fast path certifies ASCII directly, validates only non-ASCII sequences inline, and carries only bounded state across windows.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-006,Measured evidence inherited from WASM-001b,W002-ENC,W002-ENC,WASM-002,UNDER REVIEW,—,"The following measurements are non-normative evidence explaining why WASM-002 begins with the ASCII-first inline algorithm. They are not WASM-002 acceptance results and must not be represented as such. EVID-W001B-UTF8-001 On the 7,250,808,204-byte Statistics Canada source, the Day 039 distribution experiment observed 659,103 non-ASCII bytes, approximately 0.009090063% of the file, across 329,551 non-ASCII runs/sequences; the maximum observed non-ASCII run was three bytes. EVID-W001B-UTF8-002 The Day 039 non-ASCII-only experiment submitted only 659,103 bytes to strict UTF-8 validation and completed in 12.664716 seconds at 545.998 MiB/s; it proved the source valid but still incurred 329,551 strict validation calls. EVID-W001B-UTF8-003 A 1 GiB A/B test showed that reducing validated bytes alone was not enough: the selective per-run strategy submitted 115,839 bytes in 57,919 strict calls but took 503.7536 ms, while the baseline submitted 113,246,208 bytes in 27 strict calls and took 411.3590 ms. UNRESOLVED SOURCE DAMAGE: preserved authoritative text continues “This supported removing per-run general-validator call overhead rather than merely shrinking” but the remainder has not been recovered. No missing words are inferred or supplied. EVID-W001B-UTF8-004 The final native inline scan certified all 7,250,808,204 bytes in 10.377870 seconds at 666.313 MiB/s, observed 329,551 non-ASCII sequences and 659,103 non-ASCII bytes, and made zero std::str::from_utf8 calls. EVID-W001B-UTF8-005 The same inline design was exercised in Microsoft Edge/WASM with 4 MiB transfers: the valid 7,250,808,204-byte source completed with 1,729 pushes, UTF8_VALID=true, and EOF_ALL_BYTES_VALID. That experimental run took 30.5858 seconds including file I/O, JS-to-WASM copy, and WASM validation. EVID-W001B-UTF8-006 A full-size deliberately invalid Edge/WASM fixture stopped early after 2,936,012,800 bytes and 700 pushes with UTF8_VALID=false and STOP_REASON=INVALID_UTF8_SEQUENCE rather than reading to EOF. EVID-W001B-UTF8-007 WASM-001b also retained malformed UTF-8 fixtures for stray legacy bytes, truncated sequences, lone continuation bytes, overlong encodings, UTF-16 surrogate halves, and 0xFE/0xFF invalid bytes. WASM-002 should reuse or regenerate equivalent acceptance fixtures with known invalid offsets.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001,Stage 2 consumes the source instance certified by Stage 1,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The structural CSV parser and materializer operate under the explicit invariant that the same run-local selected source instance has already passed governed whole-file UTF-8 certification. Stage 2 must not independently re-resolve the analytical source. Stage 1 establishes encoding validity. Stage 2 establishes CSV structure, row identity, selected values, and governed outputs.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.1,Stage 2 must not independently re-decide the source encoding.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.2,Stage 2 must not contain an automatic Windows-1252 fallback.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.3,Stage 2 may perform only those byte/character checks required for correct CSV structural parsing and frozen analytical semantics.,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.4,"Any implementation shortcut that would weaken the certified-source invariant must be treated as a PRD change, not an optimization.",W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.5,Stage 2 restarts at byte offset zero of the same certified source instance,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"After Stage 1 returns PASS, Stage 2 must begin its structural pass from absolute source byte offset zero using the same run-local selected source instance. Rewinding/re-reading the existing source handle is permitted; performing a new filename, alias, path, picker, or directory resolution is not. If the host cannot re-read that same selected source instance for Stage 2, the Work Order must refuse under the run-local source-continuity contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.6,Stage 2 consumes an offset-zero UTF-8 BOM as metadata before header parsing,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"If the certified source begins with the UTF-8 BOM bytes EF BB BF , Stage 2 must consume those three bytes before parsing the first CSV header field. They must not become part of the first source header or selected value. The BOM is recognized only at absolute source offset zero. The fact that Stage 1 already saw the BOM does not permit Stage 2 to skip or reinterpret arbitrary later bytes.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.7,Stage 2 parses the header once and then continues directly into the data-record scan,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Within the Stage 2 forward source scan, Data Sculptor must parse the complete first logical CSV record as the source header, construct ordered header metadata including exact decoded header text and 1-based source ordinal, resolve and validate all Work Order selectors/aliases, and then continue from the first data record without restarting the source. Header resolution therefore does not add a third whole-file pass. A header-only valid CSV yields a zero-row materialization; a source with no valid header record refuses. P3-09 no-header-record refusal: after Stage 1 has certified the source, if Stage 2 reaches end-of-source without establishing any logical CSV record from which a header could be parsed, materialization must refuse with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD . This is the eighth governed Stage-2 structural CSV refusal token in the canonical oracle defined by W002-MAT-002.8. Its governed location facts are: CSV_SOURCE_BYTE_OFFSET = exact source byte length; CSV_PHYSICAL_LINE: 1 ; CSV_LOGICAL_RECORD: 1 ; CSV_FIELD_ORDINAL: 1 . Therefore a zero-byte source reports offset 0 , and a source containing only the UTF-8 BOM bytes EF BB BF reports offset 3 . A first logical record that exists but is blank remains governed by the already-frozen BLANK_LOGICAL_RECORD condition and must not be reclassified as NO_HEADER_RECORD . F-20 source-width boundary: the established header record may contain at most 16,384 physical source columns. Exactly 16,384 is valid; a header record containing 16,385 or more fields must refuse deterministically during header resolution before the first data record is consumed. The bound applies to the complete physical source width, not merely the requested KEEP set. Header processing must remain bounded. Exact decoded source-header text is authoritative source evidence and must be preserved for every selected/materialized column, but the implementation is not required to retain the complete decoded text of every unselected header after selector resolution when bounded metadata is sufficient.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-001.8,Stage 2 relies on Stage 1 UTF-8 validity rather than revalidating the file,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 must not run a second whole-file UTF-8 certification algorithm over the source. It may inspect bytes and decoded field content only as required for CSV structure, header/selector semantics, governed field-size limits, output serialization, and diagnostics. Any implementation that reintroduces redundant whole-source UTF-8 validation into Stage 2 is a measurable architectural regression unless separately justified and accepted.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002,One-pass multi-column materialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"A valid Work Order may request multiple source columns for materialization during the same bounded structural pass. For WASM-002 DS-STEPS, the requested set is expressed by one KEEP block containing one or more HEADER and/or COLUMN selectors under W002-STEPS-001 through W002-STEPS-004. F-20 KEEP-width boundary: one governed KEEP block may resolve from 1 through 16,384 distinct source columns, subject to the source itself containing no more than 16,384 columns. An empty KEEP or a request that cannot resolve within that bound refuses before data-row materialization.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.1,Requested columns must be resolved and validated before data-row materialization begins,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Every HEADER and COLUMN selector in the governed KEEP block must resolve to exactly one source column before any data-row materialization begins. Missing headers, ambiguous duplicate-header matches, invalid/out-of-range ordinals, duplicate resolved selections, invalid aliases, and successor-MAP alias collisions must refuse before the structural data-row pass. The resolved selection cardinality must be an integer from 1 through 16,384 . Resolution/validation must finish before the first data record is consumed, including operational-name/default-alias derivation and any deterministic oversized-header fallback required by W002-STOR-019.7.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.2,All selected columns are emitted from one forward data-record scan,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"After header/selector resolution, Stage 2 must traverse the source data records once regardless of whether the Work Order selects one column or many. The engine must not perform one complete source rescan per requested column. During that scan, every source field is interpreted structurally, but only the fields required by the resolved selection set are materialized into governed COL outputs. F-20 one-pass boundary: “one forward data-record scan” means one traversal of the source data records for the MATERIALIZE operation. WASM-002 must not reread source data records in batches merely because the selected-column set is wide. An implementation may perform additional bounded passes over Data-Sculptor-owned SCR , spool, or staging structures after the source scan when needed to finalize many outputs within resource limits; such passes must not reread the source data records or change governed output semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.3,One 1-based logical row ordinal aligns every selected output,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The header is not a data row. The first accepted logical data record is row identity 1, the next is 2, and so on through N. The row counter advances exactly once per accepted logical CSV data record, not per physical line. Every selected COL produced by the run must contain exactly one logical data record for each accepted source data row and therefore exactly N data records in the same governed order. A multiline quoted field remains part of one logical record and must not advance row identity merely because it contains physical newline bytes. When the run establishes a new Store, this 1..N sequence is published as that Store's one governed RID artifact. When the run extends an existing Store without changing its row universe, the existing RID is reused and must not be regenerated or renumbered.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.4,Selected-column writer order follows resolved KEEP order,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Before the data-record scan begins, the validated selection set is placed in the same order in which its selectors appear in the governed KEEP block. That resolved order governs writer creation, per-row selected-field dispatch, progress/receipt presentation, deterministic backpressure-drain priority, and candidate COL identity allocation. The Store MAP's own CSV mapping-row ordering remains governed separately by W002-STOR-019.9 and must not be confused with Work Order selection order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.5,Multiple active COL outputs use bounded staging and explicit backpressure,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Each active materialized-column writer, or an equivalent shared multiplexed output structure, must have bounded staging capacity. The aggregate kernel-owned staging state for all active writers must remain inside the governed WASM memory budget and must not grow with source row count or total output size. If a required output writer cannot accept additional canonical bytes without exceeding its governed staging capacity, source consumption must pause while pending output is drained/written. When more than one writer requires service, drain priority follows resolved KEEP order. After sufficient space is available, parsing resumes from the same structural state. The exact tuned staging-buffer size is an implementation/benchmark constant rather than an analytical semantic constant; changing it must not change output bytes, row identity, selection results, or diagnostics for the same governed input. F-20 writer-resource bound: KEEP width and simultaneously active writable resources are distinct. The accepted build must declare a finite implementation bound on simultaneously active writable-output resources and retain acceptance evidence of both that configured bound and the observed peak. The engine may satisfy a wide selection by bounded shared/multiplexed staging or a Data-Sculptor-owned spool followed by bounded finalization passes, but it must not require one simultaneously open writer per selected column. Changing the writer-resource bound must not change final bytes, row order, selection identity, aliases, Receipts, or diagnostics for the same governed input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.6,Partial output sets are never published as a successful materialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"All requested materialized-column outputs begin as visible governed SCR candidates, not COL artifacts. On first materialization of a new Store, the automatically generated RID likewise begins as a governed SCR candidate. Before any new RID/COL SCR candidate is opened, Data Sculptor establishes one publication-transaction UTC under PB-STOR-013/PB-STOR-014 and allocates a distinct artifact-specific UUID for each new candidate. Each candidate filename therefore already carries the exact UTC, UUID, and final extension intended for that RID or COL identity. A materialization transaction may begin promotion only when every required RID/COL candidate reaches EOF successfully, all selected outputs reconcile to the same accepted data-row count N, and all required candidate finalization/validation succeeds. F-04 existing-Store cardinality gate: when materialization targets an existing VALID Store, after Stage 2 establishes the complete candidate logical data-row count N and before any requested COL candidate is promoted, Data Sculptor must read the expected N from the already-valid inherited RID header and compare the two values. If candidate N equals RID-header N , the cardinality gate passes and ordinary publication may continue. If candidate N differs, the Run must refuse before any SCR -to- COL promotion and before successor-MAP publication. The inherited RID, current MAP, and existing COL artifacts remain unchanged, and the existing Store remains VALID. Equal N proves cardinality compatibility only; it does not prove source-byte continuity, row-semantic identity, or permission for a different SOURCE to enter the lineage. Exact SOURCE/Store compatibility rules are prior gates. For a new Store, Data Sculptor promotes the validated RID candidate first by host rename that changes only the class token from SCR to RID ; the candidate bytes, shared transaction UTC, RID-specific UUID, and extension remain unchanged. That successful SCR-to-RID promotion is the event that establishes RID_ACTION: CREATED and the published RID_FILENAME fact for the Run. Before that promotion succeeds, the Run has not created a governed RID even if a candidate identity has been allocated. For an existing Store, the inherited RID is reused unchanged and no RID candidate/promotion occurs. Once routing has selected and validated that exact inherited RID, that event establishes RID_ACTION: REUSED and the exact inherited RID_FILENAME ; later refusal does not erase the already-established reuse fact. After the required RID state is established, Data Sculptor promotes each requested COL candidate in deterministic resolved KEEP order by changing only the class token from SCR to COL ; each candidate's bytes, shared transaction UTC, COL-specific UUID, and extension remain unchanged. If RID or COL promotion fails, Data Sculptor must refuse the run and roll any newly promoted RID/COL names back out of their final namespaces where safely possible. Candidate or rollback bytes that cannot be safely restored or removed must be retained visibly as non-authoritative SCR failure evidence. The existence of an unreferenced RID- or COL-looking file after interruption does not by itself make that artifact committed Store state. After all required RID/COL promotions succeed, Data Sculptor allocates a MAP-specific UUID before opening the complete successor-MAP SCR candidate. That candidate uses the same publication-transaction UTC, the allocated MAP UUID, and the final .csv extension, and is constructed using the exact final RID/COL filenames. It is closed successfully, reopened, and validated completely while it remains SCR . Only then may the MAP candidate be promoted by changing only the class token from SCR to MAP ; its bytes, UTC, UUID, and extension remain unchanged. The successful SCR -to- MAP rename is the materialization commit point. Until that commit point, the prior valid MAP remains authoritative for an existing Store; for a new Store, no committed Store state exists yet. If MAP validation or MAP rename fails, Data Sculptor must refuse and roll the newly promoted RID/COL set back out of the final namespaces where safely possible; otherwise affected bytes remain attributable recovery evidence and are not committed Store membership. Governed Store membership/current state is established by a valid MAP binding, not by a final-class filename or timestamp equality alone. Revision BB preserves the Revision AY staging/promotion mechanics and Revision AZ shared transaction-UTC rule for newly published RID/COL/MAP artifacts. Selected-folder support for the canonical governed filename/path form is established by the Suitcase Validation Certificate under W002-STOR-022 through W002-STOR-022.3 rather than by a frozen numeric host path-length table. Operation-specific host rename or publication failure remains a governed refusal under this requirement and is not pre-certified by Suitcase validation. F-14 shared candidate grammar, reconciled by F-33: every RID/COL/MAP SCR candidate in this transaction follows W002-STOR-023.1: its SCR name already carries the UTC, UUID and extension intended for the final RID/COL/MAP identity, and successful promotion changes only the class token. Any retained SCR candidates after a handled publication/rollback failure remain visible non-authoritative failure evidence under W002-STOR-023.1 and are reported through the governed diagnostic/Help path; WASM-002 does not emit an RCV manifest. An orphaned SCR remains non-authoritative even if its bytes later validate.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.7,Successful materialization publishes one complete Store MAP,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"A successful governed materialization that creates one or more COL artifacts must also publish exactly one new complete immutable Store MAP under W002-STOR-019 through W002-STOR-019.12. For a new Store, that MAP binds the automatically generated and promoted RID to the Store metadata and all newly materialized COL mappings. For an existing Store, it preserves the inherited RID binding and complete prior Store state while applying the successful materialization updates. All required RID/COL SCR candidates must complete and validate before promotion begins. On a new Store, RID promotion occurs first; on an existing Store, the inherited RID is reused unchanged. All requested COL promotions must then succeed before successor-MAP candidate construction begins. The complete successor MAP is written as SCR , closed, reopened, and fully validated before entering the MAP namespace. Its final host rename from SCR to the governed MAP filename occurs last and is the materialization commit point. The materialization run is not reported as successfully committed until that MAP rename succeeds. If MAP candidate validation or MAP rename fails after RID/COL promotion, the run must refuse and the newly promoted artifacts must be rolled back out of their final namespaces where safely possible. Any failure residue that cannot safely be removed or restored is governed by W002-STOR-023.1 and remains non-authoritative retained failure evidence; its survival must not be used to infer or manufacture attribution or to simulate the failed publication step. The prior valid MAP remains authoritative for an existing Store; no committed Store is established for a first materialization without a valid successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.8,Stage 2 enforces deterministic source-record shape,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The parsed header establishes the expected source field count. Every nonblank logical data record must contain exactly that many fields after CSV parsing. A nonblank ragged record with fewer or more fields must refuse rather than pad, truncate, or shift later values. An explicit empty field is valid data and preserves its ordinal. A bare blank logical data record occurring outside a quoted field must refuse and must not be silently skipped or converted into one empty field. A physical blank line inside a valid quoted multiline field is field content, not a blank record. F-06 canonical malformed-CSV refusal facts Every structural CSV refusal records these governed facts: REFUSAL_CONDITION
SOURCE_BYTE_OFFSET
PHYSICAL_LINE
LOGICAL_RECORD
FIELD_ORDINAL SOURCE_BYTE_OFFSET is the zero-based absolute byte offset from the first physical byte of the source file. A leading UTF-8 BOM, when present, occupies offsets 0–2 and therefore counts in subsequent absolute byte locations. PHYSICAL_LINE is one-based and equals one plus the number of LF bytes strictly before the governed refusal location. LF bytes inside quoted multiline fields still increment physical-line count. LOGICAL_RECORD is one-based CSV logical-record ordinal and includes the header as logical record 1. The first data record is therefore logical record 2. FIELD_ORDINAL is the one-based field position within that logical record. These facts describe the same first structural refusal regardless of permitted streaming-window size or boundary placement. Canonical structural refusal tokens The seven frozen F-06 malformed-CSV tokens are: UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD
INVALID_BYTE_AFTER_CLOSING_QUOTE
BARE_CR_OUTSIDE_QUOTED_FIELD
EOF_INSIDE_QUOTED_FIELD
BLANK_LOGICAL_RECORD
TOO_FEW_FIELDS
TOO_MANY_FIELDS P3-09 adds NO_HEADER_RECORD as the eighth governed Stage-2 structural CSV refusal token. Parser-library names, host exceptions, crate-specific error enums, or localized descriptions must not replace these governed tokens. Governed refusal location by condition Condition Governed refusal location UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD Offset of the offending "" byte. INVALID_BYTE_AFTER_CLOSING_QUOTE Offset of the first prohibited byte after the closing quote. BARE_CR_OUTSIDE_QUOTED_FIELD Offset of the CR byte itself. EOF_INSIDE_QUOTED_FIELD One-past-end offset, equal to the physical source byte length. BLANK_LOGICAL_RECORD First byte of the record terminator that proves the blank record: LF for LF termination; CR for CRLF termination. TOO_FEW_FIELDS First byte of the record terminator that closes the short record; at EOF, one-past-end offset equal to source byte length. TOO_MANY_FIELDS The comma delimiter that begins the first field beyond the expected header width. NO_HEADER_RECORD One-past-end offset equal to the exact physical source byte length, with physical line 1, logical record 1, and field ordinal 1, as frozen by W002-MAT-001.7. Field ordinal rules For TOO_FEW_FIELDS , FIELD_ORDINAL is the first missing field ordinal: expected-width position immediately after the last field actually present. For TOO_MANY_FIELDS , FIELD_ORDINAL is the first extra field ordinal: header-width + 1. For quote/CR/EOF structural conditions, FIELD_ORDINAL is the current field ordinal in which the malformed condition is established. For BLANK_LOGICAL_RECORD , FIELD_ORDINAL is 1. For NO_HEADER_RECORD , FIELD_ORDINAL is 1. Bare CR scope A bare CR outside a quoted field is malformed CSV and refuses with BARE_CR_OUTSIDE_QUOTED_FIELD . CR inside a valid quoted field is ordinary field content. LF inside a valid quoted field is ordinary field content. CRLF inside a valid quoted field is ordinary field content. Outside quoted fields, CRLF is one accepted logical-record terminator and LF is one accepted logical-record terminator. Outside quoted fields, a CR not immediately followed by LF is malformed. EOF while quoted If EOF is reached while the parser remains inside an open quoted field, the source refuses with EOF_INSIDE_QUOTED_FIELD . Data Sculptor must not synthesize a closing quote, truncate the field, reinterpret prior bytes as unquoted content, or otherwise repair the source. First-condition precedence Stage 2 evaluates structural CSV input in absolute source-byte order and reports the earliest refusal condition that becomes deterministically established. CSV grammar errors take precedence over later row-shape errors. BLANK_LOGICAL_RECORD takes precedence over TOO_FEW_FIELDS for a physically blank logical record. BARE_CR_OUTSIDE_QUOTED_FIELD takes precedence over INVALID_BYTE_AFTER_CLOSING_QUOTE when the post-quote offending byte is a CR that is not followed by LF. At EOF while still inside a quoted field, EOF_INSIDE_QUOTED_FIELD takes precedence over field-count evaluation. No implementation may choose a different error merely because of parser buffering, window boundaries, library behavior, or host platform. Delimiter boundary Comma remains the only WASM-002 field delimiter. Automatic delimiter detection is outside the WASM-002 CSV contract. A file whose rows contain semicolons, tabs, or other non-comma separators may still be valid under the comma-only grammar as a one-column CSV. Data Sculptor must not invent a malformed-CSV refusal merely because another application would treat those bytes as delimiters. When a requested HEADER cannot be resolved, Help may explain that WASM-002 uses comma as the CSV delimiter and that semicolon/tab exports may therefore be interpreted as one field per row. Interaction with UTF-8 diagnostics This structural CSV refusal oracle applies only after the source has passed the applicable encoding-certification boundary. Invalid UTF-8 remains governed by the separately frozen UTF-8 diagnostic contract. Its zero-based absolute source-byte orientation is intentionally aligned with SOURCE_BYTE_OFFSET so WASM-002 does not have competing byte-coordinate systems.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.9,Unselected field contents are not retained,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 must parse every field sufficiently to preserve CSV structure, field count, row boundaries, and governed safety checks, but it must not retain complete contents for unselected fields after those bytes are no longer structurally needed. The engine must not materialize a complete source row, complete table, or complete unselected column in memory merely to emit selected columns. Selected-field content may use bounded accumulation required by the frozen field-size/output rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.10,Individual decoded CSV fields are limited to 16 MiB,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"WASM-002 carries forward the established Data Sculptor field-buffer safety boundary: an individual CSV field may contain at most 16 MiB (16,777,216 bytes) of decoded UTF-8 field content. This is an engineering safety limit, not a semantic statement about CSV or an Excel cell limit. The limit must be enforced incrementally for header and data fields. The parser must not first accumulate an arbitrarily large field and then check it. If a field would exceed the limit, the run must refuse without truncating, repairing, discarding the remainder, or finalizing the candidate materialization. For an unselected field, Data Sculptor may count decoded field bytes without retaining the field value; the safety limit still applies so malformed unterminated fields cannot turn the structural scan into unbounded growth. F-20 operational column-name boundary: after an exact source header field is decoded, Data Sculptor measures its length in Unicode scalar values, not UTF-8 bytes or grapheme clusters. If the exact decoded source header contains at most 1,024 Unicode scalar values, its operational column name is that exact header text. If it contains more than 1,024 scalar values, the operational column name begins from the deterministic physical-ordinal fallback Column <LETTERS> , where the letters are the Excel-style 1-based source ordinal ( A through XFD for the WASM-002 width bound). This operational name is a bounded human-facing/default-alias construct; it does not replace or truncate the authoritative exact source header.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-002.11,Materialized COL artifacts use canonical one-column UTF-8 CSV serialization,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Each finalized materialized COL artifact is a one-column CSV. It begins with exactly one UTF-8 BOM ( EF BB BF ) and uses LF ( 0x0A ) as the record terminator on every supported host. The first logical record contains the exact decoded source header text for that physical source column; an alias assigned with AS lives in the governed MAP and does not rewrite the physical COL header. A deliberately empty source header is serialized as one explicit empty header field rather than as absence of a header record. Header and data fields use deterministic minimal CSV quoting: quote when the field contains comma, double quote, CR, or LF; double embedded double quotes; otherwise write the field without quotes. Embedded CR/LF that belong to a quoted field remain field content. For a one-column data record whose decoded value is the empty string, serialize the value explicitly as """" so the row cannot be confused with a bare blank logical record. For fixed source bytes and fixed governed semantics, changing input/output window boundaries must not change the finalized COL bytes. F-20 source-fidelity rule: the physical COL header record always serializes the exact decoded source header, even when that header exceeds the 1,024 -scalar operational-name boundary and the Store MAP/default alias therefore uses an operational fallback. The fallback name must never be substituted into the COL header record or into the MAP source_header field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003,Stage 2 processes the source through bounded reusable windows,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,Structural materialization must process the certified source through bounded reusable input windows compatible with browser/WASM memory constraints. Source size and row count must not require proportional WASM memory growth.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.1,"The 4 MiB WASM-001b window is a proven reference point, not a frozen production constant",W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The 4 MiB source window used successfully during the WASM-001b browser experiments is an evidence-backed starting/reference size. WASM-002 may tune the production input-window size using benchmark evidence, provided the governed memory budget and all window-invariance requirements remain satisfied.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.2,Changing source-window size or boundary placement must not change results,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"For the same certified source and Work Order, permitted changes in bounded Stage 2 input-window size or boundary placement must not change CSV interpretation, resolved headers/ordinals, accepted row count, row identity, aliases, canonical COL bytes, successor MAP contents apart from newly allocated physical identities/timestamps, or the first deterministic refusal condition. P3-09 window invariance: for a Stage-1-certified source containing no logical CSV record, every permitted Stage 2 window size and boundary placement must produce the same NO_HEADER_RECORD refusal and the same governed location tuple: source-byte offset equal to the exact source byte length, physical line 1, logical record 1, field ordinal 1. F-06 full refusal-oracle window invariance: for the same certified source bytes, changing any permitted Stage 2 input-window size or boundary placement must not change whether the source is accepted or refused; the first REFUSAL_CONDITION ; SOURCE_BYTE_OFFSET ; PHYSICAL_LINE ; LOGICAL_RECORD ; or FIELD_ORDINAL . This applies to every structural CSV refusal governed by W002-MAT-002.8.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.3,CSV structure must survive arbitrary input-window boundaries,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Input-window boundaries may occur between ordinary field bytes, delimiter bytes, quote/escaped-quote pairs, CR/LF record-ending bytes, inside quoted multiline fields, and inside already-certified multi-byte UTF-8 sequences. The Stage 2 parser must preserve equivalent structural meaning across those boundaries.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.4,Cross-window parser state is small and explicit,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"Stage 2 may carry only the bounded state needed to continue the current logical CSV parse, including the current logical row ordinal, current field ordinal, quoted/unquoted state, escaped-quote/quote-transition state as required by the parser, pending CR/LF state, decoded-field byte count, resolved selected-field dispatch metadata, and bounded selected-field/output staging. The parser must not retain previous complete rows or source windows merely because a CSV record crosses a window boundary.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.5,Input-window and output-drain sizes are independent implementation controls,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The source read window, WASM transfer window where applicable, selected-field accumulator bound, and output-drain window are separate controls. One must not be silently treated as the maximum for another merely because an earlier prototype used the same numeric value. Any tuning must preserve the Stage 2 memory, backpressure, byte, and window-invariance contracts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.6,Stage 2 uses direct structural parsing rather than a required structural sidecar,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The WASM-002 baseline performs its Stage 2 work directly from the certified source stream. It must not require a precomputed comma/quote/newline position map, binary structural index, hidden cache, or OPFS sidecar before materialization can proceed. The previously discussed structural-sidecar comparison remains a separate future experiment and must not be introduced into WASM-002 as an unmeasured dependency.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-003.7,The Stage 2 algorithm is browser-first shared Rust core behavior,W002-MAT,W002-MAT,WASM-002,UNDER REVIEW,—,"The structural parser, row-count semantics, selector dispatch, canonical field serialization, and bounded output-state machine defined by Stage 2 belong in the shared Rust semantic core proven through the browser/WASM path first. A later native CLI host must call the same governed core rather than reimplementing competing materialization semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001,Conversion is a separate governed operation,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Windows-1252-to-UTF-8 conversion is a distinct governed Work Order operation, separate from UTF-8 certification and separate from analytical materialization. The analyst must explicitly authorize it. The canonical WASM-002 form is: SUITCASE: .
WORK ORDER AS ""Convert legacy source to UTF-8""
SOURCE ""legacy_source.csv""
CONVERT WINDOWS-1252 TO UTF-8 CONVERT WINDOWS-1252 TO UTF-8 is the terminal operation clause. Exactly one SOURCE is permitted. The same WKO must not contain KEEP , MATERIALIZE , Store/RID/COL alias mutation, MAP , Inventory, repair, cataloging, Work Order composition, or another operation terminal clause. F-10 conversion entry precondition Before CONVERT WINDOWS-1252 TO UTF-8 may begin character transcoding, Data Sculptor must validate the complete bound source as strict UTF-8 under the same deterministic whole-source certification rules used elsewhere in WASM-002. If the complete source is already valid strict UTF-8, the conversion refuses as unnecessary and publishes no CVT . Only after complete strict UTF-8 validation reaches governed FAIL may Data Sculptor assess the same complete bound source against the frozen Windows-1252 compatibility mapping. Only a source that fails strict UTF-8 and passes the complete Windows-1252 compatibility assessment may proceed to conversion. A failed analytical Work Order, UTF-8 certification, or materialization never silently invokes this operation. The analyst must explicitly authorize the separate conversion WKO.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.1,A failed analytical Work Order must not automatically invoke conversion.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.2,The user must explicitly choose or submit the separate conversion task.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.3,The original source file must remain unchanged.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-001.4,Successful conversion must create a new UTF-8 artifact with its own governed identity and receipt/evidence.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002,Windows-1252 compatibility assessment,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"After strict whole-source UTF-8 certification returns FAIL , the current analytical operation remains refused and Stage 2 must not start. As refusal handling, Data Sculptor performs one separate read-only Windows-1252 compatibility assessment from physical byte offset 0 of the same run-local bound source instance. The compatibility assessment scans the complete source sequentially under W002-CONV-002.1 through W002-CONV-002.5. It does not transcode, publish a CVT, modify the analyst-owned source, resume materialization, or claim that Windows-1252 is the historical encoding. Its sole governed result is whether the entire byte stream is mappable by the frozen WASM-002 Windows-1252 converter. If strict UTF-8 certification returned PASS , or did not reach a governed FAIL conclusion, this compatibility assessment is not run. F-10 conversion classification gate The conversion operation itself repeats/executes the complete classification gate on its bound source before transcoding: validate the complete source as strict UTF-8; if strict UTF-8 passes, refuse conversion as unnecessary; only after strict UTF-8 fails, scan the complete source against the frozen Windows-1252 mapping; if any source byte is undefined or unsupported by that mapping, refuse rather than guess; and begin transcoding only when strict UTF-8 has failed and the complete Windows-1252 compatibility assessment has succeeded. An undefined/unsupported Windows-1252 byte is therefore a pre-transcoding compatibility-assessment refusal . No CVT candidate may be represented as successfully converted from a source whose compatibility scan found an undefined byte. The compatibility assessment must not substitute U+FFFD , reinterpret an undefined Windows-1252 byte as ISO-8859-1, or use permissive host/library decoder behavior to make an incompatible source convertible.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.1,Compatibility means that the supported deterministic converter can map the observed source bytes under the frozen Windows-1252 rules.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Compatibility means that every physical source byte can be mapped deterministically by the complete normative WASM-002 Windows-1252 mapping in W002-CONV-002.4 . Successful EOF produces the governed outcome COMPATIBLE . No statistical detector, locale rule, browser guess, replacement character, ISO-8859-1 substitution, best-effort decoder, or PRODUCT-scoped glossary text participates as normative authority in this determination.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.2,Compatibility must not be described as proof that Windows-1252 was historically or authoritatively the file's original encoding.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"COMPATIBLE means only that the complete byte stream is convertible under Data Sculptor's frozen Windows-1252 mapping. It must not be described as proof that Windows-1252 was historically, authoritatively, or intentionally the source file's original encoding.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.3,Bytes undefined by the frozen Windows-1252 mapping must cause the compatibility assessment or conversion task to refuse rather than guess.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"If the compatibility pass encounters a byte that W002-CONV-002.4 defines as undefined, the assessment stops at the first such byte and returns INCOMPATIBLE . Data Sculptor must not substitute a replacement character, reinterpret the byte under another code page, or continue as though conversion were safe. A later explicit conversion Work Order must apply the same complete WASM-002 mapping and the same refusal rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.4,Complete normative WASM-002 Windows-1252 byte mapping,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"This requirement is the complete normative Windows-1252 mapping authority for WASM-002 . It covers all 256 possible byte values. No PRODUCT-scoped glossary entry or host/library decoder is required to interpret compatibility or conversion. 0x00–0x7F Every byte 0x00 through 0x7F maps one-to-one to Unicode U+0000 through U+007F . 0x80–0x9F Byte Windows-1252 mapping Unicode 0x80 EURO SIGN U+20AC 0x81 UNDEFINED — 0x82 SINGLE LOW-9 QUOTATION MARK U+201A 0x83 LATIN SMALL LETTER F WITH HOOK U+0192 0x84 DOUBLE LOW-9 QUOTATION MARK U+201E 0x85 HORIZONTAL ELLIPSIS U+2026 0x86 DAGGER U+2020 0x87 DOUBLE DAGGER U+2021 0x88 MODIFIER LETTER CIRCUMFLEX ACCENT U+02C6 0x89 PER MILLE SIGN U+2030 0x8A LATIN CAPITAL LETTER S WITH CARON U+0160 0x8B SINGLE LEFT-POINTING ANGLE QUOTATION MARK U+2039 0x8C LATIN CAPITAL LIGATURE OE U+0152 0x8D UNDEFINED — 0x8E LATIN CAPITAL LETTER Z WITH CARON U+017D 0x8F UNDEFINED — 0x90 UNDEFINED — 0x91 LEFT SINGLE QUOTATION MARK U+2018 0x92 RIGHT SINGLE QUOTATION MARK U+2019 0x93 LEFT DOUBLE QUOTATION MARK U+201C 0x94 RIGHT DOUBLE QUOTATION MARK U+201D 0x95 BULLET U+2022 0x96 EN DASH U+2013 0x97 EM DASH U+2014 0x98 SMALL TILDE U+02DC 0x99 TRADE MARK SIGN U+2122 0x9A LATIN SMALL LETTER S WITH CARON U+0161 0x9B SINGLE RIGHT-POINTING ANGLE QUOTATION MARK U+203A 0x9C LATIN SMALL LIGATURE OE U+0153 0x9D UNDEFINED — 0x9E LATIN SMALL LETTER Z WITH CARON U+017E 0x9F LATIN CAPITAL LETTER Y WITH DIAERESIS U+0178 0xA0–0xFF Every byte 0xA0 through 0xFF maps one-to-one to Unicode U+00A0 through U+00FF . Undefined-byte rule The only undefined byte values in this frozen WASM-002 mapping are exactly 0x81 , 0x8D , 0x8F , 0x90 , and 0x9D . Encountering any one of them makes the complete compatibility assessment INCOMPATIBLE at the first such byte and causes an explicitly run conversion Work Order to refuse before transcoding rather than guess. These three ranges plus the 32-position table above exhaust the byte domain 0x00–0xFF . No unlisted byte value exists.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-002.5,The compatibility check must itself be bounded and deterministic.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"The compatibility check is one bounded-memory deterministic sequential pass from physical source byte offset 0 to EOF unless the first undefined Windows-1252 byte is encountered earlier. Buffer/window size must not change the compatibility outcome or the first undefined-byte offset. On INCOMPATIBLE , WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET is the zero-based absolute physical source-byte offset of the first undefined byte. On COMPATIBLE , that offset is NOT_APPLICABLE . If the assessment begins but an independent read/host failure prevents a governed compatibility conclusion, the outcome is NOT_AVAILABLE and the first-undefined-byte offset is NOT_AVAILABLE . The assessment itself publishes no converted output.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003,Help suggestion after failed UTF-8 certification,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"Help may suggest the separate CONVERT WINDOWS-1252 TO UTF-8 Work Order only when the governed engine emits DS-CNV-001 after a complete compatibility assessment returned COMPATIBLE . The suggestion is therefore derived from a governed diagnostic fact, not from the UTF-8 failure itself. If the assessment returns INCOMPATIBLE , is NOT_AVAILABLE , or did not run, DS-CNV-001 is not emitted and Help must not invent the conversion recommendation. P3-08 Help disclosure: when conversion succeeds, Help must state that the published CVT is a new governed source artifact with its own source identity and that converting a refreshed legacy source later will publish another distinct CVT rather than refresh an earlier CVT-backed Store lineage. When a CVT is selected for first materialization, Help must disclose the same consequence before or with the normal materialization guidance: the Store lineage is anchored to the exact CVT filename, not to the analyst-owned pre-conversion filename. Help must not imply hidden lineage continuity across separate CVT artifacts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.1,The suggestion must state that the current analytical task has stopped.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must state that the current analytical task has already stopped/refused because strict UTF-8 certification failed. DS-CNV-001 is informational and must not be rendered as though materialization can continue from the failed run.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.2,The suggestion must state that the original source has not been changed.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must state that the compatibility assessment was read-only and that Data Sculptor did not change the analyst-owned source. Any later successful conversion publishes a separate governed CVT artifact rather than editing the original source in place.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.3,"The suggestion must describe the source as compatible with the supported Windows-1252 converter, not definitively identified as Windows-1252.",W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The suggestion must describe the complete source as compatible with Data Sculptor's supported Windows-1252 converter . It must not say that the source was definitively identified as Windows-1252 or imply provenance that the compatibility pass cannot prove.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.4,The suggestion must make clear that conversion is a separate user-authorized task.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"The suggestion must make clear that conversion is a separate user-authorized Work Order. next_action: RUN_WINDOWS_1252_CONVERSION means that the separate operation is a governed safe option; it is not permission for Data Sculptor to silently transcode, modify the source, or reinterpret the refused analytical Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-003.5,"If the bytes are not compatible with the supported converter, Help must not recommend Windows-1252 conversion as though it were safe.",W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"If the compatibility outcome is INCOMPATIBLE , NOT_AVAILABLE , or NOT_RUN , Help must not recommend Windows-1252 conversion as though it were safe. In particular, the mere presence of DS-ENC-001 never authorizes that recommendation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004,Canonical conversion output,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,"A successful Windows-1252 conversion task must produce canonical UTF-8 output suitable for later submission to the normal UTF-8 certification and materialization path. P3-08 lineage consequence: the successful conversion output is a new immutable governed CVT artifact with its own exact physical filename. That CVT filename is the source identity used by later Store routing. A later conversion, including one made from a refreshed analyst-owned legacy source with the same original filename, publishes a different CVT and therefore does not refresh, replace, or continue an earlier CVT-backed Store lineage merely by name association. On first materialization, each distinct CVT begins a new Store lineage unless that exact CVT filename already routes to an existing lineage under the normal Store rules. F-14 CVT identity and publication: the final converted-source filename is exactly __DS__CVT__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv . Conversion writes first to the corresponding W002-STOR-023.1 SCR identity with the same UTC, UUID and .csv extension. Only after bounded conversion completes, the candidate closes/reopens successfully, and the converted bytes satisfy the governed strict UTF-8 requirement may the class token be renamed to CVT . CSV structural interpretation remains governed by the later normal certification/materialization path; CVT publication does not assert that the converted source is structurally valid CSV. F-10 conversion semantics — encoding conversion only The conversion operation performs deterministic character transcoding only. It does not parse, repair, normalize, or reinterpret CSV structure. Commas remain commas. Double quotes remain double quotes. Ordinary ASCII bytes retain the same byte value. LF remains LF. CR remains CR. CRLF remains CRLF. Embedded CR/LF bytes are preserved in place; the converter does not decide whether they are record terminators or field content. Canonical UTF-8 output therefore means deterministic UTF-8 encoding of the accepted source characters, not normalization of line endings, quoting, delimiters, records, headers, or fields. F-10 BOM rule The published CVT is UTF-8 without a BOM ; Data Sculptor does not prepend EF BB BF . If the source failed strict UTF-8 classification, a leading source byte sequence EF BB BF is not blindly stripped as though it were a UTF-8 BOM. Under the Windows-1252 conversion path those source bytes are source data and are mapped according to the frozen Windows-1252 mapping. BOM interpretation remains subordinate to encoding classification rather than acting as a blind prefix-removal rule.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-010; CP-011,"CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open; CP011 T-ACCEPTED, GIT BANKED — CVT-to-SCR lexical staging-name pairing only; complete conversion requirement remains open",b7c515faa9bd000369d7656e09437310261290ae; e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,"Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived); Evidence/CP-011/CP011_Scope_Lock.txt; Evidence/CP-011/CP011_RED_Test_Output.txt; Evidence/CP-011/CP011_GREEN_Test_Output.txt; Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt; Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt; Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt; Evidence/CP-011/CP011_Hash_Inventory_Verification.txt; Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt; Evidence/CP-011/CP011_Closing_Git_Review.txt; CP011_Git_Banking_Output.txt (post-commit, separately preserved)","CP010 Day066 first-touches ONLY the F-14 canonical final CVT output filename grammar subconstraint: is_governed_cvt_source_filename_candidate(&str)->bool recognizes exact canonical __DS__CVT__<UTC>__<UUIDv4>.csv lexical form by reusing existing envelope validation. Four targeted tests + 40/40 full native regression PASS; wasm32-target build PASS; T accepted and banked b7c515faa9bd000369d7656e09437310261290ae. No encoding conversion, SCR creation, close/reopen, UTF-8 validation, CVT publication, immutable physical output, source authority, or CSV structural checks; entire W002-CONV-004 remains PARTIAL, independently unreviewed. CP011 Day066: public pure helper build_scr_candidate_filename_for_cvt(&str)->Option<String> accepts an exact canonical governed CVT .csv filename (via CP010 recognizer) and derives the paired SCR filename by substituting only class token CVT -> SCR, preserving exact UTC, UUIDv4 and lowercase .csv bytes; rejects wrong classes, paths, whitespace, malformed clock/date/UUID, extension and class case. Six targeted tests; RED expected E0432 exit 101; GREEN 6/6; post-format native regression 46/46; rustfmt recheck PASS; Rust 1.97.1 wasm32-unknown-unknown --lib build PASS; original 28/28 and combined 36/36 SHA-256 records verified. Two local scoped .gitattributes whitespace exceptions preserve Rustfmt/Git diagnostic TXT bytes; final Git staged check PASS. T-approved and Git banked e84ae5baeee05f9d5d30284c65b86eebba3c0f6a, 27 committed files, working tree clean. Lexical candidate-name pairing ONLY; no SCR creation, bytes, converter, transaction, close/reopen, validation/publication, retained SCR adoption, SOURCE authority or browser execution. Independent Claude implementation QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.1,The converted artifact must itself be certifiable as UTF-8.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.2,The conversion Receipt identifies the governed source encoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for a successful governed Windows-1252-compatible conversion must identify exactly SOURCE_ENCODING: WINDOWS-1252-COMPATIBLE . That operation-specific fact is carried within the canonical TXT Receipt governed by W002-RCP-001 through W002-RCP-010. Only that exact serialized spelling is permitted for this key/value pair.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.3,The conversion Receipt identifies the materialized UTF-8 encoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for a successful governed conversion must identify exactly MATERIALIZED_ENCODING: UTF-8 . This uses the canonical KEY: VALUE serialization frozen by W002-RCP-005. MATERIALIZED_ENCODING=UTF-8 is not valid canonical Receipt serialization.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.4,The conversion Receipt identifies bounded streaming transcoding,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,The canonical RCP for successful conversion must identify that transcoding was performed under the governed bounded/streaming conversion contract.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-004.5,No analytical column materialization occurs as part of this conversion operation.,W002-CONV,W002-CONV,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001,Canonical diagnostic truth,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every governed user-visible failure or warning produced by WASM-002 must originate as a canonical diagnostic event. A diagnostic event must have a stable identity and structured facts independent of its final wording. Governed success/status events that participate in the Help/status/evidence system—such as a successfully saved Work Order or a successfully validated Suitcase—are canonical INFO diagnostic events and obey the same identity/fact/behavior contract. Ordinary static labels, headings, decorative copy, and presentation-only status text are not automatically diagnostics merely because they are visible in the UI.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.1,Canonical diagnostic IDs use the frozen DS-<DOMAIN>-<NNN> grammar,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry one stable identifier using the exact form DS-<DOMAIN>-<NNN> . DOMAIN is exactly three uppercase ASCII letters A through Z. NNN is exactly three decimal digits, zero-padded, in the range 001 through 999 . Examples include DS-ENC-001 , DS-WKO-001 , DS-STO-001 , DS-MAT-001 , and DS-HLP-001 . A diagnostic ID is permanent after allocation and must never be reused for a different diagnostic meaning. Severity, host, build/release, source filename, path, UUID, byte offset, row/column number, count, timestamp, occurrence ID, and other run-specific facts must not be encoded into the diagnostic ID; those values belong in structured diagnostic fields. The identifier is the canonical lookup key used by the Help message catalog. Day 060 H-04 pre-freeze identifier normalization: the Windows-1252 compatibility suggestion diagnostic is DS-CNV-001 . It follows the same exact three-letter DOMAIN grammar as every other diagnostic ID. No four-letter DOMAIN exception exists in the current WASM-002 contract. Any pre-H-04 draft spelling of this diagnostic is superseded and is not valid build-registry input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.2,Diagnostic severity uses one exact token set,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry exactly one severity token: INFO , WARNING , or ERROR . Severity classifies the condition for human and machine interpretation. It does not itself determine whether execution continues or refuses; that authority is carried separately by the canonical behavior field.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.3,Diagnostic phase uses a stable uppercase token,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must identify the governed operation or phase using an uppercase ASCII snake-case token matching [A-Z][A-Z0-9]*(?:_[A-Z0-9]+)* . Examples include WORK_ORDER_VALIDATION , SOURCE_CERTIFICATION , MATERIALIZATION , STORE_PUBLICATION , and HELP_REPORT . These examples do not constitute a closed global phase list; the fixed phase for each allocated diagnostic is declared by that diagnostic's registry entry.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.4,Structured diagnostic facts are declared per diagnostic,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The canonical event carries diagnostic-specific evidence in a structured facts object. Fact keys use lowercase ASCII snake case matching [a-z][a-z0-9]*(?:_[a-z0-9]+)* . Each diagnostic registry entry declares disjoint required_facts and optional_facts sets. Every required fact must be present when that diagnostic is emitted. An optional fact key may be omitted when that fact is not emitted for the event, but omission itself has no governed absence-state meaning : it must not be interpreted as NONE , NOT_RUN , NOT_AVAILABLE , NOT_APPLICABLE , false , zero, or an empty string. An emitted fact key that is not declared for that diagnostic is invalid. For structured JSON diagnostic facts, an established ordinary value retains its native JSON type. When a present diagnostic fact must express one of the shared governed absence states, its value is the exact JSON string ""NONE"" , ""NOT_RUN"" , ""NOT_AVAILABLE"" , or ""NOT_APPLICABLE"" , with the meaning frozen by F-18. JSON null is not a generic encoding for diagnostic-fact absence; it is permitted only where a specific JSON schema explicitly declares a nullable field and defines what that null means, as W002-HELP-009 does for HLP lineage. A required diagnostic fact may not be silently omitted, defaulted, converted to null , guessed, or replaced by a Help-layer value. If Data Sculptor attempts to establish a registered diagnostic but cannot produce one or more facts declared required for that diagnostic, the intended diagnostic is not emitted . Instead the engine emits DS-HLP-001 under W002-HELP-001.8. The replacement event records the intended diagnostic ID and the complete sorted set of missing required fact names. No partially populated copy of the intended diagnostic may be presented beside it. This fail-closed substitution is a diagnostic-contract integrity rule, not a presentation fallback. It preserves the F-17 boundary that diagnostics own facts and Help renders only complete governed diagnostic truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.5,Execution behavior is explicitly CONTINUE or REFUSE,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry exactly one execution-behavior token: CONTINUE or REFUSE . This field is the governed continue/refuse decision for the event. Help wording, severity, UI color, or presentation must not independently weaken, strengthen, or reinterpret it.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.6,Safe next action uses a stable token rather than Help prose,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Every canonical diagnostic event must carry a next_action token using uppercase ASCII snake case matching [A-Z][A-Z0-9]*(?:_[A-Z0-9]+)* . NONE is the canonical value when no safe governed next action applies. The token expresses stable machine-readable intent; Casual, Office Speak, and Technical wording for that action belongs to the Help layer. Run-specific values such as timestamps, paths, UUIDs, byte offsets, filenames, counts, or occurrence IDs remain structured facts and do not change the diagnostic identity or fixed next-action meaning. Damaged-Store guidance is part of the safe-next-action contract. When ordinary materialization refuses because exact source routing identifies an INVALID Store lineage, or a DEGRADED lineage whose every mapped COL is broken and therefore cannot be reduced to a non-empty successor by REPAIR MAP , the selected Help voice must preserve the same frozen choices and consequences rather than inventing a recovery operation. The explanation must identify the blocked lineage/current MAP and distinguish: external restoration under the original governed physical filename followed by the required governed validation tier; source rename to deliberately begin a separate new Store lineage; and analyst retirement of the damaged lineage by moving all of that lineage's Store MAPs out of the active Suitcase root. For retirement, Help must warn that moving only the latest MAP can expose an older structurally valid MAP as current. Help must not claim that matching the original filename proves historical byte identity, and must not describe any of these analyst filesystem actions as Data Sculptor-authored repair, deletion, RID regeneration, or silent lineage replacement. P3-07 malformed-MAP routing guard: when ordinary materialization refuses because no routable Store lineage can be established while one or more structurally malformed Store-MAP-class artifacts are present in the active Suitcase, Help must identify the malformed MAP artifact or artifacts and state that new-Store/RID creation was blocked to prevent a silent lineage fork. Help must not describe the missing structurally valid MAP as proof that the prior Store never existed, and must not invent a Data Sculptor repair or replacement operation for this condition. P3-10 delimiter-hint clarification: when Stage 2 refuses with INVALID_BYTE_AFTER_CLOSING_QUOTE and the offending byte is semicolon ( 0x3B ) or horizontal TAB ( 0x09 ), Help may include the governed delimiter-mismatch hint even though the refusal occurred before header-delimiter resolution. The hint is explanatory only: it must not change the canonical refusal condition, location facts, behavior, or safe-action boundary. F-16 conversion-suggestion boundary: strict UTF-8 refusal diagnostic DS-ENC-001 has fixed next_action: NONE . UTF-8 failure alone does not establish that any converter is safe. Only the separate compatibility diagnostic DS-CNV-001 , emitted after the complete governed Windows-1252 compatibility assessment returns COMPATIBLE , may carry next_action: RUN_WINDOWS_1252_CONVERSION . That token identifies a safe separately authorized option; it never resumes or rewrites the refused analytical Work Order. Day 060 H-12 damaged-lineage diagnostic binding ordinary MATERIALIZE refusal for a routed INVALID Store uses DS-MAT-014 and its declared facts; ordinary MATERIALIZE refusal for a DEGRADED Store whose every mapped COL is broken uses DS-MAT-015 and its declared facts; the no-routable-lineage / malformed-Store-MAP guard uses DS-MAT-016 and its declared facts. These specialized allocations are what permit closed-world Help to identify the blocked lineage/current MAP or malformed MAP artifacts without adding unrelated facts to the ordinary DS-MAT-010 validation diagnostic. Day 060 H-26 / BM-09 ordinary DEGRADED routing binding. When ordinary MATERIALIZE exact-source routing identifies a DEGRADED Store whose RID is valid and at least one mapped non-RID COL remains valid, the refusal uses DS-MAT-017 . Its fixed next_action is RUN_REPAIR_MAP because REPAIR MAP is the safe governed Store mutation for this repairable DEGRADED state. Help must use the diagnostic's declared current_map_filename as the exact MAP identity the analyst must name in the separate governed REPAIR MAP Work Order. The token does not run repair automatically and does not mutate the refused MATERIALIZE Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.7,"The governed engine emits the diagnostic semantic core, not voice-authored prose",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The shared Rust/WASM diagnostic path must provide the canonical semantic core required by Help: diagnostic_id , severity , phase , behavior , facts , and next_action . The fixed values and permitted fact-key sets for an allocated diagnostic are governed by diagnostics.json . Casual, Office Speak, and Technical prose belongs to the Help rendering layer rather than being duplicated as authored message sets inside the governed engine. Host/build/occurrence metadata may be carried by surrounding governed execution evidence, but it must not redefine the diagnostic semantic core. F-16 closed-world Help rule: Help may recommend the WASM-002 Windows-1252 conversion Work Order only when the governed engine emitted DS-CNV-001 . Help must not infer compatibility from DS-ENC-001 , byte appearance, file extension, locale, browser behavior, heuristic encoding detection, or prose outside the diagnostic facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-001.8,diagnostics.json is the canonical WASM-002 diagnostic registry build resource,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The human-inspectable development/build source for the WASM-002 diagnostic registry is exactly diagnostics.json , encoded as UTF-8 without BOM. It is Data Sculptor product/build content, not a Suitcase artifact; it must not use the __DS__ namespace, consume an artifact-class token, or be copied into an analyst's Suitcase merely because Data Sculptor runs. The top-level JSON object has exactly two fields: registry_version and diagnostics . registry_version is the string ""1"" . diagnostics is an array written in ascending UTF-8 byte order of diagnostic_id . Each diagnostic entry has exactly seven fields: diagnostic_id , severity , phase , behavior , next_action , required_facts , and optional_facts . Diagnostic IDs must be unique and satisfy W002-HELP-001.1. Severity, phase, behavior, and next-action values must satisfy W002-HELP-001.2 through W002-HELP-001.6. required_facts and optional_facts are arrays of canonical fact-key strings sorted in ascending UTF-8 byte order; keys must be unique within each array and the two arrays must be disjoint. {
  ""registry_version"": ""1"",
  ""diagnostics"": [
    {
      ""diagnostic_id"": ""DS-CNV-001"",
      ""severity"": ""INFO"",
      ""phase"": ""SOURCE_CERTIFICATION"",
      ""behavior"": ""CONTINUE"",
      ""next_action"": ""RUN_WINDOWS_1252_CONVERSION"",
      ""required_facts"": [""source_filename"", ""windows_1252_compatibility_outcome""],
      ""optional_facts"": []
    },
    {
      ""diagnostic_id"": ""DS-ENC-001"",
      ""severity"": ""ERROR"",
      ""phase"": ""SOURCE_CERTIFICATION"",
      ""behavior"": ""REFUSE"",
      ""next_action"": ""NONE"",
      ""required_facts"": [""first_invalid_byte_offset"", ""source_filename"", ""stop_reason""],
      ""optional_facts"": [""analytical_outputs_published"", ""materialization_started"", ""source_modified_by_data_sculptor"", ""store_state_committed""]
    },
    {
      ""diagnostic_id"": ""DS-HLP-001"",
      ""severity"": ""ERROR"",
      ""phase"": ""DIAGNOSTIC_ASSEMBLY"",
      ""behavior"": ""REFUSE"",
      ""next_action"": ""NONE"",
      ""required_facts"": [""intended_diagnostic_id"", ""missing_required_facts""],
      ""optional_facts"": []
    }
  ]
} The PRD does not need to enumerate every allocated WASM-002 diagnostic row. The complete registry delivered with the build is retained acceptance evidence. A diagnostic ID becomes permanent once allocated and must not later be reused for a different meaning. Build validation must fail on malformed JSON; extra/missing entry fields; duplicate or noncanonical diagnostic IDs; invalid fixed tokens; unsorted, duplicate, overlapping, or invalid fact-key declarations; engine diagnostic definitions whose fixed semantics disagree with the registry; engine diagnostic definitions absent from the registry; Help-catalog IDs absent from the registry; or Help placeholders that name facts not declared as required or optional by the matching diagnostic. F-07 DS-ENC-001 fact mapping: the canonical lower-case diagnostic facts for strict UTF-8 refusal are first_invalid_byte_offset , source_filename , and stop_reason . For this diagnostic, stop_reason is exactly INVALID_UTF8_SEQUENCE . The generic fact name byte_offset is retired for this UTF-8 refusal diagnostic. P2-03 clock-order diagnostic facts: whichever stable WASM-002 Diagnostic ID is allocated to refusal because a successor Store MAP or WKO MAP cannot satisfy the strict monotonic UTC publication guard must declare these exact lower-case required facts in its diagnostic-registry entry: map_profile , observed_host_utc , predecessor_map_filename , and predecessor_utc . map_profile has exactly two permitted values: STORE for a Store-MAP chronology guard and WKO for a Work-Order-registry-MAP chronology guard. These facts identify both the governed MAP profile, the blocking predecessor artifact, and the truthful clock observation that caused refusal. F-16 DS-CNV-001 allocation: DS-CNV-001 is emitted only when the complete read-only compatibility assessment under W002-CONV-002 through W002-CONV-002.5 reaches EOF with outcome COMPATIBLE . Its required fact windows_1252_compatibility_outcome is therefore exactly the JSON string ""COMPATIBLE"" . behavior: CONTINUE means this informational diagnostic introduces no additional refusal; it does not reverse the already-established DS-ENC-001 refusal or resume Stage 2. F-17 DS-HLP-001 allocation: DS-HLP-001 is the canonical fail-safe event when the engine cannot satisfy the complete required-fact contract of an intended registered diagnostic. intended_diagnostic_id is the exact canonical ID that was being assembled. missing_required_facts is a JSON array of every missing required fact-key string, sorted in ascending UTF-8 byte order with no duplicates. The intended diagnostic is suppressed rather than emitted incompletely. DS-HLP-001 always refuses and has next_action: NONE . F-22 QA-independence boundary: diagnostics.json is authoritative for the fixed semantic contract of an allocated Diagnostic ID — its ID, severity, phase, behavior, next action, and permitted required/optional fact keys — but the implementation-delivered registry is not, by itself, an independent oracle proving that every arbitrary runtime condition was mapped to the correct Diagnostic ID. WASM-002 does not require a second QA-owned registry duplicating every implementation allocation. Where this PRD independently freezes a condition-to-diagnostic mapping or exact required facts — including the named DS-ENC-001 , DS-CNV-001 , and DS-HLP-001 contracts and other explicitly pinned diagnostic facts — that PRD text remains normative and acceptance must test the mapping independently of the implementation registry. For allocations not independently pinned by the PRD, WASM-002 accepts the validated build registry as the build allocation while retaining all registry-shape, permanence, semantic-agreement, fact-discipline, and Help cross-validation gates. This is an explicit accepted QA-scope risk, not a claim of independent condition-to-ID verification. Day 060 H-02 fixture-pinned diagnostic allocations The following allocations are normative for the byte-exact Receipt acceptance corpus. They are genuine product diagnostics, not QA-only placeholder IDs. Every row has severity: ERROR , behavior: REFUSE , next_action: NONE , the phase shown below, the listed required facts, and an empty optional_facts array unless another requirement explicitly adds optional facts later. The existing DS-ENC-001 remains the Stage-1 invalid UTF-8 diagnostic and is reused by the H-02 Stage-1 compatibility-state fixtures. Diagnostic ID Severity Phase Behavior Next action Frozen meaning Required facts DS-WKO-001 ERROR WORK_ORDER_VALIDATION REFUSE NONE Work Order validation refuses before one of the seven governed operations can be identified. work_order_filename DS-MAT-010 ERROR MATERIALIZATION_VALIDATION REFUSE NONE Ordinary MATERIALIZE validation/routing refuses before Stage 1 begins after the source reference is established, excluding the specialized damaged-lineage and malformed-MAP routing conditions allocated by Day 060 H-12. source_filename DS-MAT-011 ERROR CSV_DECODING REFUSE NONE MATERIALIZE Stage 2 refuses on a governed structural CSV condition. source_filename csv_refusal_condition csv_source_byte_offset csv_physical_line csv_logical_record csv_field_ordinal DS-MAT-012 ERROR MATERIALIZATION_GATE REFUSE NONE MATERIALIZE post-Stage-2 gate refuses because existing-Store source cardinality does not match the inherited RID cardinality. source_filename base_map_filename rid_filename source_row_count rid_row_count DS-MAT-013 ERROR STORE_PUBLICATION REFUSE NONE MATERIALIZE governed Store-artifact filename identity allocation refuses after collision-retry exhaustion before any new Store artifact becomes authoritative. artifact_class collision_retry_count DS-INV-001 ERROR INVENTORY_VALIDATION REFUSE NONE INVENTORY validation refuses before the inventory scan begins. work_order_filename DS-INV-002 ERROR INVENTORY_SCAN REFUSE NONE INVENTORY scan/measurement refuses for an identified immediate Suitcase entry before a complete snapshot is established. entry_name DS-INV-003 ERROR INVENTORY_PUBLICATION REFUSE NONE INVENTORY governed INV filename identity allocation refuses after collision-retry exhaustion after the snapshot facts are established. artifact_class collision_retry_count DS-ALS-001 ERROR ALIAS_VALIDATION REFUSE NONE UPDATE ALIASES validation/routing refuses before an exact base Store MAP is established. work_order_filename DS-ALS-002 ERROR ALIAS_GATE REFUSE NONE UPDATE ALIASES refuses after the exact base Store MAP is established but before successor publication. base_map_filename DS-ALS-003 ERROR STORE_PUBLICATION REFUSE NONE UPDATE ALIASES successor-MAP filename identity allocation refuses after collision-retry exhaustion. artifact_class collision_retry_count DS-RPM-001 ERROR REPAIR_MAP_VALIDATION REFUSE NONE REPAIR MAP validation refuses before an exact target MAP/RID pair is established. work_order_filename DS-RPM-002 ERROR REPAIR_MAP_ANALYSIS REFUSE NONE REPAIR MAP analysis refuses before a complete repair result is established. target_map_filename DS-RPM-003 ERROR REPAIR_MAP_ANALYSIS REFUSE NONE REPAIR MAP deterministically refuses because every mapped COL is broken and retained COL count is zero. target_map_filename broken_col_count DS-RPM-004 ERROR STORE_PUBLICATION REFUSE NONE REPAIR MAP successor-MAP filename identity allocation refuses after collision-retry exhaustion after repair analysis is established. artifact_class collision_retry_count DS-WKR-001 ERROR WORK_ORDER_REGISTRY_VALIDATION REFUSE NONE REPAIR WORK ORDER REGISTRY validation refuses before the current structurally valid WKO MAP is established. work_order_filename DS-WKR-002 ERROR WORK_ORDER_REGISTRY_REPAIR REFUSE NONE REPAIR WORK ORDER REGISTRY repair-plan/gate processing refuses after the base WKO MAP is established. base_wko_map_filename DS-WKR-003 ERROR WORK_ORDER_REGISTRY_PUBLICATION REFUSE NONE REPAIR WORK ORDER REGISTRY successor-WKO-MAP filename identity allocation refuses after collision-retry exhaustion. artifact_class collision_retry_count DS-CVT-001 ERROR CONVERSION_VALIDATION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 validation/classification refuses before bounded transcoding begins. source_filename DS-CVT-002 ERROR CONVERSION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 refuses after bounded transcoding begins but before publication. source_filename DS-CVT-003 ERROR CONVERSION_PUBLICATION REFUSE NONE CONVERT WINDOWS-1252 TO UTF-8 CVT filename identity allocation refuses after collision-retry exhaustion after conversion facts are established. artifact_class collision_retry_count DS-CAT-001 ERROR CATALOG_DISCOVERY REFUSE NONE CATALOG STORES validation/discovery refuses before the complete authoritative catalog row set is established. work_order_filename DS-CAT-002 ERROR CATALOG_PUBLICATION REFUSE NONE CATALOG STORES CAT filename identity allocation refuses after collision-retry exhaustion after the complete row set is established. artifact_class collision_retry_count Day 060 H-04 normalization: all allocated Diagnostic IDs in the current WASM-002 contract, including DS-CNV-001 , use exactly three ASCII uppercase letters in DOMAIN . No exception exists. Day 060 H-12 / BM-09 specialized diagnostic allocations The H-02 fixture diagnostics above are intentionally narrow. In particular, publication diagnostics whose required facts are only artifact_class and collision_retry_count mean identity-allocation collision exhaustion , not every possible publication failure. Other publication failures receive distinct registry allocations unless another requirement independently pins their Diagnostic ID. The following additional pre-freeze allocations are normative because existing Help duties require fact contracts that the broad H-02 fixture IDs cannot truthfully carry. Every row has severity: ERROR , behavior: REFUSE , and next_action: NONE except DS-MAT-017 , whose next_action is RUN_REPAIR_MAP . optional_facts is empty unless another requirement explicitly extends it. Diagnostic ID Severity Phase Behavior Next action Frozen meaning Required facts DS-MAT-014 ERROR MATERIALIZATION_ROUTING REFUSE NONE MATERIALIZE is blocked because exact source routing identifies a current INVALID Store lineage whose governed RID is missing or invalid. source_filename current_map_filename rid_filename store_health DS-MAT-015 ERROR MATERIALIZATION_ROUTING REFUSE NONE MATERIALIZE is blocked because exact source routing identifies a DEGRADED Store whose every mapped non-RID COL is missing or invalid, so REPAIR MAP cannot publish a non-empty successor. source_filename current_map_filename rid_filename store_health mapped_col_count broken_col_count DS-MAT-016 ERROR MATERIALIZATION_ROUTING REFUSE NONE New-Store creation is blocked because no routable Store lineage can be established while one or more structurally malformed Store-MAP-class artifacts are visible in the active Suitcase. source_filename malformed_map_filenames DS-MAT-017 ERROR MATERIALIZATION_ROUTING REFUSE RUN_REPAIR_MAP MATERIALIZE is blocked because exact source routing identifies a current DEGRADED Store whose governed RID is valid and whose mapped non-RID COL set contains at least one broken COL and at least one surviving valid COL, so a separate governed REPAIR MAP operation is available. source_filename current_map_filename rid_filename store_health broken_col_count DS-UTC-001 ERROR PUBLICATION_CHRONOLOGY REFUSE NONE A successor Store MAP or WKO MAP publication is blocked because truthful observed host UTC is not strictly greater than the canonical chronology predecessor UTC. map_profile observed_host_utc predecessor_map_filename predecessor_utc Day 060 H-26 / BM-09 allocation: DS-MAT-017 is the ordinary repairable-DEGRADED routing refusal. store_health is exactly DEGRADED ; broken_col_count is the exact number of mapped non-RID COL bindings that fail the applicable Store-health validation at this routing gate and is at least 1 . The condition excludes the all-COLs-broken case allocated to DS-MAT-015 . current_map_filename is the exact current structurally valid Store MAP that a separate REPAIR MAP Work Order must name. RUN_REPAIR_MAP is a safe next-action token only; it never causes automatic repair. Closed-world Help consequence: Help may render the richer damaged-lineage, malformed-MAP, and monotonic-UTC explanations only from the applicable specialized diagnostic event above. It must not borrow undeclared facts from DS-MAT-010 or from a collision-exhaustion publication diagnostic merely because those facts are available elsewhere at runtime. Cross-operation UTC rule: DS-UTC-001 has one stable semantic condition across Store-MAP and WKO-MAP successor publication. The required map_profile fact tells closed-world Help which governed MAP profile encountered the chronology guard: STORE means Store MAP and WKO means Work Order registry MAP. Help must select profile-appropriate explanation and analyst exits only from that declared fact and the other registered event facts; it must not infer the profile from filename shape, surrounding host state, or an undeclared operation field. The shared Diagnostic ID therefore does not need profile-specific clones.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002,Three-voice parity,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help Engine must support the three established Data Sculptor help voices. All three renderings must preserve the same diagnostic truth. Voice selection may change wording, sentence structure, degree of technical detail, and explanatory style. F-24 session default and persistence: Technical is the canonical Help voice at the start of every new browser application instance. The analyst may select Casual or Office Speak during that instance, but WASM-002 retains the selected voice only in volatile runtime state and does not persist the preference in browser-private storage. A new application instance therefore returns to Technical. This default does not alter the F-17 rule that a missing diagnostic-specific catalog entry visibly falls back to Generic Technical Help.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.1,Voice selection must not change diagnostic identity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.2,Voice selection must not change severity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.3,Voice selection must not change counts or evidence.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.4,Voice selection must not change whether execution continues or refuses.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.5,Voice selection must not change safe/unsafe action boundaries.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.6,Voice selection must not change provenance.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.7,Voice selection must not change the meaning of the recommended next step.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Tests must assert parity on the canonical event and structured facts, not brittle equality of prose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.8,One validated Help message catalog is the source of truth for all three voices,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help layer resolves a canonical diagnostic ID through one validated catalog that associates an authored ID with Casual, Office Speak, and Technical templates. The human-maintained development source is exactly help_messages.json , encoded as UTF-8 without BOM. help_messages.json is a Data Sculptor product/build resource, not a Suitcase artifact. It must not use the __DS__ governed artifact namespace, consume a semantic artifact-class token, or be copied into an analyst's Suitcase merely because Data Sculptor runs. Run-specific structured facts remain authoritative in the canonical diagnostic event and are supplied separately to the selected template. The three authored voices must not be maintained as unrelated message stores. F-17 coverage fallback: absence of an authored catalog entry for an otherwise complete registered diagnostic is permitted at run time and does not make the diagnostic incomplete. Data Sculptor must instead render the deterministic Generic Technical Help view defined by W002-HELP-002.9. The fallback consumes only the canonical event semantic core and its emitted governed facts; it is not a second message catalog and does not manufacture replacement diagnostic facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.9,WASM-002 may use mechanically generated placeholder voice text to prove Help wiring,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance does not require the complete production Help corpus. Authored catalog entries may use unmistakable placeholder strings, and placeholder entries may be generated mechanically from the validated diagnostics.json registry; no production prose authorship is required. Deterministic Generic Technical Help fallback. When a complete registered canonical diagnostic has no matching entry in help_messages.json , all selected Help voices fall back visibly to one Generic Technical rendering. The rendering must show, in this exact conceptual order, the diagnostic ID, severity, phase, behavior, next-action token, and then every emitted governed fact ordered by ascending UTF-8 byte order of fact key. It must state that no diagnostic-specific authored explanation is available. It must not infer cause beyond the diagnostic, invent remediation, default missing facts, inspect undeclared external state, or substitute prose for governed fact values. The Generic Technical fallback preserves the original diagnostic unchanged. Catalog incompleteness is therefore distinct from diagnostic incompleteness: a valid event can always be rendered generically, while inability to satisfy the event's own required_facts contract suppresses that intended event and produces DS-HLP-001 under W002-HELP-001.4 and W002-HELP-001.8. Acceptance must prove correct diagnostic-ID lookup, selected-voice resolution, structured-fact interpolation where a template exists, voice switching, deterministic Generic Technical fallback for a deliberately absent catalog entry, and semantic parity across authored voices. Final authored Help wording, examples, editorial polishing, and production-corpus quality remain deferred to a later Help-content milestone.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.10,help_messages.json has one deterministic WASM-002 source schema,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The top-level JSON object has exactly two fields: catalog_version and messages . catalog_version is the string ""1"" . messages is an array written in ascending UTF-8 byte order of diagnostic_id . Each message entry has exactly four fields: diagnostic_id , casual , office_speak , and technical . diagnostic_id must satisfy the canonical DS-<DOMAIN>-<NNN> grammar and must be unique in the catalog. Each voice field is a JSON string. A voice string may contain zero or more structured-fact placeholders using the exact form {fact_name} . Each catalog diagnostic_id must exist in the validated diagnostics.json registry, and each referenced placeholder must be declared in that diagnostic's required_facts or optional_facts . Duplicate IDs, missing voice fields, null voice values, malformed JSON, noncanonical or unregistered diagnostic IDs, or undeclared fact placeholders make catalog validation fail. The catalog is intentionally allowed to be non-exhaustive. A registered diagnostic with no message entry is rendered through the deterministic Generic Technical fallback in W002-HELP-002.9. Therefore a missing catalog entry for a registered diagnostic is not a build-validation failure and must not cause the engine to synthesize an authored entry or suppress the diagnostic. WASM-002 therefore does not require one global exhaustive fact-name table in the PRD. Fact-key authority is per diagnostic: the validated registry declares which fact names are legal for each stable diagnostic meaning. {
  ""catalog_version"": ""1"",
  ""messages"": [
    {
      ""diagnostic_id"": ""DS-ENC-001"",
      ""casual"": ""[CASUAL PLACEHOLDER] {source_filename}"",
      ""office_speak"": ""[OFFICE PLACEHOLDER] {source_filename}"",
      ""technical"": ""[TECHNICAL PLACEHOLDER] {source_filename} {first_invalid_byte_offset} {stop_reason}""
    }
  ]
} Later Help-content revisions may extend or version this schema only through an explicit PRD revision. F-07 placeholder mapping: Help for the strict UTF-8 refusal may render {first_invalid_byte_offset} and {stop_reason} because those exact fact names are declared by the canonical DS-ENC-001 diagnostic registry entry. The older generic {byte_offset} placeholder is not valid for DS-ENC-001. P2-03 Help rendering duty: Help for the monotonic-UTC refusal must identify the exact blocking predecessor MAP and show both predecessor UTC and truthful observed host UTC. It must distinguish an incorrect host clock from a genuinely future-dated governed MAP and may explain the approved analyst-owned choices: correct the clock, wait/rerun after truthful time advances, or deliberately move the exact future-dated current MAP out of the active Suitcase root with the warning that an older snapshot/registry may become current and that restoring the moved MAP may restore its authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-002.11,The validated Help catalog is embedded into the released HTML build and supplied to the shared core,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Before a WASM-002 browser build is accepted, the build must parse and validate help_messages.json , then serialize the validated catalog directly into the Data Sculptor HTML itself as one non-executable application/json payload with the exact element ID ds-help-catalog . The embedded JSON must be HTML-safe so catalog text cannot terminate the containing script element; at minimum, literal less-than characters in JSON string content must be escaped during embedding. At runtime, the browser host obtains this embedded payload and supplies the validated catalog to the shared Rust/WASM Help core. Browser JavaScript must not implement a competing template-selection, fact-interpolation, fallback, escaping, or HLP-semantic engine. The browser host must not fetch a Help catalog from the network, the filesystem, the Suitcase, or an adjacent deployment file. Missing or malformed embedded catalog JSON, or a build whose embedded catalog does not correspond to the validated build input, is a build-validation failure. The released HTML therefore remains one offline portable front door for the browser Help catalog. A later native host may supply the same governed catalog semantics to the same shared core from its own build-bundled resource; host packaging may differ, but Help semantics must not fork.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003,Message and report outputs,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The Help Engine must support both live and durable help surfaces.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003.1,The Help Engine must support a concise human-facing message suitable for the live browser surface.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The concise message is rendered in the dedicated browser Help / Diagnostic Surface when that surface is present; it is not required to be a modal or transient notification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-003.2,"The Help Engine must support a durable HTML Help report using the canonical built-in Data Sculptor presentation suitable for saving with the Work Order, receipt, and output artifacts.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"A concise Help message for an individual diagnostic and any durable Help Report that includes that diagnostic must resolve from the same canonical diagnostic event. A durable Help Report request may cover one active governed diagnostic, including a non-run diagnostic, or one governed run containing one or more canonical diagnostic events. Exactly one HLP is published for each explicit Help Report request.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004,HTML Help report content,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,A saved Help report must be able to include the following elements when relevant.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.1,Product and brand identity.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.2,Plain-language summary.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.3,Stable diagnostic ID.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.4,What Data Sculptor observed.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.5,Evidence and structured facts.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.6,What the user can safely do next.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.7,Source/Work-Order context is governed by the HLP disclosure allowlist.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The report may include only source and Work Order context permitted by W002-HELP-010. Durable HLP disclosure is intentionally stricter than transient local Help because the HLP is a portable support-handoff artifact. A relevant governed alias or source header may enter the HLP only under the necessity and disclosure rules in W002-HELP-010. Source-header text is eligible only when Data Sculptor has structurally established an actual CSV header record under the governed parser. Record position alone does not make text a header. When no valid header record has been established, including the headerless-source refusal case, the HLP must use structural evidence such as the 1-based column ordinal, diagnostic condition/location, or an applicable operational fallback name and must not substitute field data from the first data row. Absolute local paths, entire Work Orders, Work Order comments, source rows/values, unrelated headers/aliases/columns, and unrelated Suitcase contents are not automatically eligible merely because they are available to the running application.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.8,Report-generation metadata preserves HLP identity and lineage.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,The report must carry its own governed HLP filename and generation UTC together with the diagnostic identity and applicable originating execution lineage. The exact HLP provenance contract is governed by W002-HELP-009.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.9,Selected Help voice and its human-facing explanation.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.10,A clearly labelled structured-facts block derived from the canonical diagnostic event.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.11,Four canonical Boolean facts describe the WASM-002 execution boundary.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When the governed diagnostic context can determine the execution boundary, the canonical fact names are exactly: source_modified_by_data_sculptor materialization_started analytical_outputs_published store_state_committed When one of these facts has an established Boolean value, the JSON/structured value is the native Boolean true or false , never the strings ""TRUE"" or ""FALSE"" . source_modified_by_data_sculptor states only whether Data Sculptor modified the analyst-owned source in place; it must not imply knowledge that no external process or analyst changed the source between sessions. materialization_started records whether the governed analytical materialization phase began. analytical_outputs_published records whether governed analytical outputs were successfully published for user use; transient SCR candidates or abandoned/uncommitted debris do not make this fact true. store_state_committed records whether the successor Store MAP commit point was crossed. If a present boundary fact must express governed absence rather than an established Boolean, its JSON/structured value is the exact applicable shared absence-state string ""NONE"" , ""NOT_RUN"" , ""NOT_AVAILABLE"" , or ""NOT_APPLICABLE"" . JSON null is not a valid encoding for these four boundary facts because it would discard the reason for absence. A boundary fact that is optional for a particular diagnostic may instead be omitted under W002-HELP-001.4; that omission carries no absence-state meaning. A missing, omitted, unavailable, or not-run fact must never be interpreted as false . If one of these facts is declared required for an intended diagnostic and the required value cannot be produced, it must not be silently defaulted; the intended diagnostic is suppressed and the fail-safe DS-HLP-001 contract in W002-HELP-001.4/W002-HELP-001.8 applies.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-004.12,Governed Work Order lineage sufficient to establish user intent.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,Included lineage must obey the disclosure boundary defined for Help reports and must not automatically expand into source-data disclosure.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-005,Deterministic rendering uses a closed governed input set,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Given the same canonical diagnostic event or ordered set of events, selected voice, PRETTY rules, validated Help catalog, and built-in presentation version, Help rendering must be deterministic except for explicitly permitted event/report-specific fields. The Help renderer may consume only the canonical diagnostic fields and fact keys declared by the applicable diagnostic registry entries plus fields explicitly defined by the applicable HLP provenance schema. It must not inspect or interpolate an open-ended host-state bag, undeclared browser state, unrelated Suitcase contents, or another value merely because it is available at runtime. A future configurable Brand Manifest may add another governed presentation input, but it is not part of the WASM-002 rendering contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-006,Host parity uses one shared Help semantic core,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The Help Engine must be designed for use by the browser host and the later native CLI host without changing diagnostic semantics. The shared Rust core owns diagnostic-to-template selection, governed fact interpolation, deterministic fallback behavior, governed escaping, and durable HLP semantic serialization. The WASM-002 browser host supplies the validated catalog embedded under W002-HELP-002.11. A later native host may supply the same governed catalog semantics from a build-bundled native resource. Host-specific presentation and packaging may differ, but they must not create a second Help semantic engine or change canonical diagnostic identity, facts, behavior, next action, voice semantics, disclosure policy, or HLP meaning.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-007,"Help surfaces are projections, not diagnostic authority",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The live Help / Diagnostic Surface and the saved HTML Help Report must render from the canonical diagnostic event. Neither surface may independently create, reinterpret, weaken, suppress, or override governed diagnostic truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008,HTML Help Report is a governed support-handoff artifact,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The user must be able to generate a styled, self-contained HTML Help Report from a governed diagnostic event for retention, IT/support handoff, or communication to another analyst. The report must support two audiences in one document: a human-readable explanation using the selected Help voice and a clearly inspectable structured-facts section that preserves the technical evidence required to understand the event.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008.1,"The report preserves the canonical execution-boundary facts, including relevant negative facts.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When relevant to the diagnostic, the report must render the governed values of source_modified_by_data_sculptor , materialization_started , analytical_outputs_published , and store_state_committed . These values originate from governed execution state rather than reassuring prose invented by the renderer. A missing/unavailable fact is not rendered as false .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-008.2,The report preserves only the Work Order lineage needed to explain the diagnostic.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"The report must identify the originating WKO physical filename when one applies and may include only the minimum executable Work Order clause or clauses needed to establish the governed operation, user intent, and trigger for the diagnostic. It must not automatically embed the entire Work Order or Work Order comments. All such context remains subject to the fixed disclosure boundary in W002-HELP-010.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-009,"WASM-002 establishes HLP identity, lineage, multiplicity, and one canonical embedded provenance payload.",W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"A durable generated Help Report is an immutable governed HLP artifact whose physical filename is: __DS__HLP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html The UTC token is the HLP's own governed generation/publication time. The report is the final self-contained HTML artifact using the canonical built-in Red5Sorcery/Data Sculptor presentation; no unstyled intermediate is the canonical HLP. Report-request multiplicity: one explicit Help Report request publishes exactly one HLP. The request may be bound to one active governed diagnostic, including a diagnostic that is not associated with a Run, or to one governed Run containing one or more canonical diagnostic events. A Run-level report includes the governed diagnostic events selected by that request in deterministic event order. HLP generation is never an automatic one-artifact-per-diagnostic side effect. Every HLP must expose a visible deterministic Provenance section and exactly one embedded non-executable application/json payload whose element ID is exactly ds-hlp-provenance . F-34 supersedes the earlier draft schema version ""1"" . For schema version ""2"" , the JSON top-level object contains exactly these ten fields: {
  ""schema_version"": ""2"",
  ""hlp_filename"": ""__DS__HLP__20260922T191500123Z__<uuid-v4>.html"",
  ""hlp_generation_utc"": ""20260922T191500123Z"",
  ""diagnostic_ids"": [""DS-ENC-001"", ""DS-MAT-004""],
  ""originating_wko_filename"": ""__DS__WKO__...txt"",
  ""originating_rcp_filename"": null,
  ""selected_help_voice"": ""technical"",
  ""presentation_id"": ""red5sorcery-data-sculptor"",
  ""presentation_version"": ""1"",
  ""data_sculptor_build"": ""<exact-build-id>""
} hlp_generation_utc must use the canonical fixed-width millisecond UTC form YYYYMMDDTHHMMSSmmmZ . diagnostic_ids is a non-empty JSON array containing one canonical diagnostic ID for each diagnostic event included in the report, in the same deterministic event order used by the report. Repeated IDs are permitted when distinct included events legitimately share one diagnostic type. selected_help_voice is exactly one of casual , office_speak , or technical , matching the Help catalog keys. For WASM-002 the built-in presentation identity is exactly red5sorcery-data-sculptor and its presentation version is exactly ""1"" . data_sculptor_build must contain the exact running build identifier used for the tested/released build; the literal scope label WASM-002 alone is not sufficient unless it is also the exact build identifier. originating_wko_filename and originating_rcp_filename are schema-declared nullable lineage fields . When the relationship exists and the exact physical filename is known, the value is that filename as a JSON string. When the relationship itself does not apply to this Help event/report request, the machine-readable value is JSON null . That null has one schema-defined meaning: the nullable relationship has no value, equivalent to Rust Option<T>::None and to the governed semantic state NOT_APPLICABLE . The visible Provenance section renders it as NOT APPLICABLE . If the lineage relationship does apply but the exact filename cannot be obtained, JSON null must not be used; the field value is the exact string ""NOT_AVAILABLE"" and the visible Provenance section renders NOT AVAILABLE . Empty strings, invented lineage, N/A , UNKNOWN , or another substitute are forbidden. For these two lineage fields, null and ""NOT_AVAILABLE"" are deliberately non-interchangeable. A non-run HLP may therefore legitimately carry JSON null for both lineage fields when neither relationship applies. This nullable-field rule is a schema-specific serialization choice, not a fifth absence state and not a generic JSON encoding rule. Other diagnostic JSON facts follow W002-HELP-001.4 and W002-HELP-004.11. The visible and machine-readable HLP provenance must express the same governed semantics even where their physical representations differ; a semantic mismatch is an HLP-generation failure and must not be silently tolerated. The embedded JSON must be HTML-safe so provenance text cannot terminate the containing script element; at minimum literal less-than characters in JSON string content must be escaped during embedding. The provenance payload remains subject to W002-HELP-010 and must not introduce source rows, source values, absolute local paths, arbitrary Work Order content, or other context excluded by the fixed HLP disclosure policy. WASM-002 does not automatically compute or embed a SHA-256 of the HLP, and saving an HLP must not create, refresh, or verify an LCK . The final HLP bytes remain eligible for exact-byte integrity evidence under the later explicit FINGERPRINT/LCK workflow. Configurable Brand Manifest provenance remains deferred to V1-BACKLOG / a future build. F-14 HLP publication: the complete self-contained report is first written as the corresponding SCR candidate under W002-STOR-023.1. It must close, reopen, and validate the required visible Provenance section, exact schema-version-2 embedded JSON shape, HTML-safe serialization, self-contained presentation and visible/machine semantic parity before the class token may be renamed from SCR to HLP . A partial or semantically mismatched candidate never becomes a canonical HLP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-010,Help Report disclosure uses one fixed WASM-002 allowlist.,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Generating a Help Report must not silently become a data-export path. WASM-002 therefore uses one deterministic allowlist rather than collecting broad context and attempting to redact it afterward. There are no disclosure checkboxes, permissive export modes, or per-report overrides in WASM-002. Always eligible when present and applicable: diagnostic ID; severity/classification; governed operation/phase; continue/refuse decision; safe next action; selected Help voice; HLP identity and generation UTC; relevant governed artifact filenames; and the four canonical boundary facts from W002-HELP-004.11. Eligible only when necessary to explain the diagnostic: the exact source filename but not an absolute OS path; a relevant source column header only when Data Sculptor has structurally established an actual CSV header record; the relevant 1-based column number; a relevant governed Store/RID/COL alias only when that alias itself is necessary to explain the diagnostic, such as an alias collision, ambiguity, or governed alias mutation; byte offset, row/count, or byte-length evidence; Store/RID/COL/MAP/WKO physical filenames; and only the minimum executable Work Order clause or clauses needed to establish intent and the diagnostic trigger. If that minimum Work Order excerpt necessarily contains a governed alias, that alias is disclosed and counts as alias text included. Headerless boundary: record position alone never establishes a source header. If the governed parser has not established a valid header record, including a headerless-source refusal, HLP generation must not treat any field from the first data row or any later data record as header text. Structural evidence such as 1-based column ordinal, governed diagnostic/location facts, or an applicable operational fallback name must be used instead. Never included automatically: source rows; source field values or arbitrary data samples; field data mislabeled as header text; absolute local paths; unrelated source headers, aliases, or column names; the complete Work Order; Work Order comments; unrelated Suitcase contents; browser/environment internals not governed as diagnostic evidence; or raw ungoverned stack traces. Every generated HLP must contain a visible Disclosure section stating, at minimum: Source rows included: NO ; Source values included: NO ; Source header text included: YES or NO ; Governed alias text included: YES or NO ; Absolute local paths included: NO ; Work Order comments included: NO ; and Work Order excerpt: RELEVANT EXECUTABLE CLAUSES ONLY . The two YES/NO declarations must truthfully reflect the actual HLP bytes. A genuine established source header does not count as a source field value; this distinction applies only after the governed parser has established the header record. The renderer must not weaken any declaration when the underlying policy has not changed. This durable-HLP allowlist does not prohibit transient local Help from showing a relevant governed alias or a genuinely established source header when useful to explain the same canonical diagnostic event. Local presentation does not enlarge what the portable HLP may disclose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011,Help owns the cross-session source-continuity edge-case explanation,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"When an unexpected analytical result, row-alignment concern, or support question raises the possibility that an analyst-owned source changed between sessions, Data Sculptor-controlled guidance must flow through the Help Engine. Help must not imply that the engine monitored or cryptographically protected the source when it did not. The explanation must distinguish ordinary analyst-controlled workflow from stronger optional evidence. It may ask whether the analyst edited, replaced, sorted, re-exported, synchronized, copied over, or otherwise changed the source after the Store was established.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011.1,Help presents continuity evidence in explicit assurance levels,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"For a suspected cross-session source change, Help must distinguish at least these evidence levels: No continuity evidence: state that cross-session byte continuity cannot be independently verified from filename/Store metadata alone. INVENTORY available: use filename, exact byte length, and last-modified metadata as lightweight clues; changed metadata may indicate that the source changed, while unchanged metadata must not be presented as proof of unchanged bytes. Explicit fingerprint evidence available: exact-byte SHA-256 evidence may establish whether the compared file bytes match or differ under the later governed FINGERPRINT workflow. Help must not collapse these levels into one generic statement of certainty.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HELP-011.2,WASM-002 does not impose automatic cross-session hashing or Suitcase surveillance,W002-HELP,W002-HELP,WASM-002,UNDER REVIEW,—,"Ordinary WASM-002 materialization and Store inheritance must not automatically SHA-256 the source, recursively fingerprint the Suitcase, or maintain hidden whole-Suitcase surveillance merely to guard against the possibility that an analyst-owned file changed between sessions. This is an intentional product boundary for the lone-office-analyst model. The product assumes the analyst normally controls the Suitcase, provides lightweight explicit INVENTORY evidence in WASM-002, preserves a later explicit FINGERPRINT path for stronger assurance, and relies on Help to explain unusual cross-session continuity questions proportionately. WASM-002 must not create, refresh, or silently verify an LCK Suitcase Lock as a side effect of Work Order save, materialization, Store inheritance, INVENTORY, alias maintenance, or ordinary project use. LCK publication belongs to the explicit later-V1 FINGERPRINT workflow. F-13 single-writer Help boundary: Help must distinguish cross-session continuity from concurrent writing. WASM-002 does not claim that two Data Sculptor tabs/windows can safely write the same Suitcase at once. User guidance must say to use one writing Data Sculptor context per Suitcase; read-only viewing is not itself a governed write. When a pre-commit guard detects that relevant governed state changed underneath an operation, Help must identify the changed authority where available and direct the analyst to refresh or reopen current state and rerun deliberately. It must not imply that Data Sculptor acquired a cross-tab lock, merged the competing work, or automatically rebased the refused transaction.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-001,Separation of truth and presentation,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,The PRETTY Engine must not decide analytical truth or reinterpret diagnostic meaning. It receives governed content and renders it into human-facing artifacts. WASM-002 conceptual boundary: ENGINE TRUTH -> HELP / REPORT CONTENT -> PRETTY ENGINE -> BUILT-IN DATA SCULPTOR PRESENTATION -> ARTIFACT. A future build may replace the built-in presentation source with a governed Brand Manifest without changing the analytical or diagnostic truth supplied to PRETTY.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-002,Shared renderer path,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"The PRETTY Engine must provide a common rendering path for Data Sculptor artifacts that require governed human presentation, including at minimum the WASM-002 Help HTML report. WASM-002 uses the canonical built-in Red5Sorcery/Data Sculptor presentation. The architecture must permit the same path to accept a configurable Brand Manifest in a future build without changing analytical semantics. The architecture must also permit later reuse for branded Receipt HTML, verification reports, tables, Quick Viz, and other PRETTY outputs. WASM-002 canonical run Receipts themselves remain TXT-only under W002-RCP-003.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003,Self-contained HTML,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"Durable HTML artifacts produced by PRETTY must be self-contained for ordinary viewing after generation. Self-containment requires semantic and functional portability, not pixel-identical rendering across operating systems or browsers; ordinary system-font substitution and browser rendering differences are acceptable when meaning, evidence, hierarchy, and accessibility remain intact.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.1,A saved artifact must not require a network connection.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.2,A saved artifact must not require an external stylesheet.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.3,A saved artifact must not require a remote font.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.4,A saved artifact must not require a separately located logo file.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-003.5,A saved artifact must not require external presentation resources.,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"Required CSS, SVG, and other built-in presentation assets needed for ordinary viewing must be embedded or otherwise resolved into the generated artifact at creation time. Future configurable Brand Manifest inputs, when implemented, must preserve this self-contained output rule.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PRETTY-004,Accessibility and inspectability,W002-PRETTY,W002-PRETTY,WASM-002,UNDER REVIEW,—,"PRETTY HTML must remain ordinary inspectable HTML. Presentation must not obscure the text, evidence, diagnostic code, provenance, or next-step guidance. The rendered artifact must remain usable without JavaScript when JavaScript is not required for its content.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-QA-001,Governed test-only seams and acceptance coverage,W002-QA,W002-QA,WASM-002,UNDER REVIEW,—,"Every material frozen WASM-002 behavior must have retained acceptance evidence sufficient to exercise the governed success, refusal, mutation, publication, or recovery boundary that makes the behavior meaningful. Related cases may share one fixture when the shared fixture proves each required condition explicitly; acceptance coverage must not rely on a behavior being difficult to reproduce under an uncontrolled host environment. Permitted deterministic test-only seams. WASM-002 acceptance may use controlled clock values; controlled UUID sequences and collision outcomes; controlled filesystem create/write/close/rename/promotion failures; and controlled run-local source-handle reread/substitution conditions. A seam supplies only the external condition required to reach the governed behavior. It must not bypass validation, alter the normative semantic result, change governed serialization, relax publication rules, rewrite diagnostic truth, or create a second analytical execution model. Release boundary. Test-only controls must not be invocable through the ordinary Data Sculptor UI, DS-STEPS, saved Work Orders, URL/query parameters, Suitcase configuration, or another analyst-facing product path. Compile-time exclusion, test-build configuration, or an isolated acceptance harness are permitted implementation techniques. Retained acceptance evidence must identify any seam used and must separately demonstrate that the accepted release surface cannot invoke that seam as a user feature. Named storage acceptance gaps. Acceptance must include a case-variant governed namespace/class fixture proving that Data Sculptor does not silently normalize the variant spelling into canonical governed identity; an unknown syntactically valid governed-class fixture proving that the file remains byte-for-byte unchanged while a canonical INFO diagnostic and INVENTORY surface the unknown/unrecognized class; and at least one known-but-not-emitted-class fixture drawn from DGN , RCV , BRD , or LCK proving the same preserve-and-report behavior without activating a producer, lifecycle, or interpretation path. Carried feature gates remain feature-owned. Mechanisms whose normative lifecycle is integrated in another package — including the F-02 Work Order-registry/alias-replacement behavior, the F-04 existing-Store cardinality refusal, and the F-24 CER-history decision — cannot be considered accepted without their corresponding feature acceptance gates. This requirement does not invent those feature semantics. If a proposed mechanism is removed from WASM-002 rather than integrated, no acceptance gate for that removed mechanism is required.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-001,UTF-8 certification pass,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,A valid multi-gigabyte UTF-8 fixture must complete whole-source certification with exact byte accounting under bounded memory.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-002,UTF-8 certification fail,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"A fixture containing an invalid UTF-8 sequence, including a sequence that crosses an input-window boundary, must deterministically produce STAGE1_UTF8_OUTCOME: FAIL , UTF8_STOP_REASON: INVALID_UTF8_SEQUENCE , and the exact governed zero-based UTF8_FIRST_INVALID_BYTE_OFFSET . Stage 2 must not begin and no analytical materialization output may be published. The same bytes tested under different permitted Stage-1 input-window sizes and boundary placements must yield the same outcome, stop-reason token, and first-invalid offset.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-003,Run-local source substitution refusal,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"An acceptance fixture must attempt to present Stage 2 with a different source instance/reference than the one retained from Stage 1. The run must refuse before materialization rather than accept the substitute merely because filename, alias, path, or byte length appears compatible. F-23 governed seam: this fixture must use the test-only source-handle substitution/reread seam permitted by W002-QA-001 so the different Stage-2 instance is injected without changing the analyst-visible SOURCE syntax or adding a product-level source-selection path. Release-surface evidence must demonstrate that an analyst cannot invoke this substitution seam through the normal UI, Work Order, URL/query, or Suitcase configuration.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-004,ASCII-only fast path,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,An all-ASCII fixture must certify successfully without invoking non-ASCII sequence validation and must produce exact byte accounting.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-005,Valid non-ASCII sequence matrix,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"Acceptance must cover valid two-byte, three-byte, and four-byte UTF-8 sequences, including sequences placed at window boundaries and split at every legal boundary position.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-006,Strict invalid-sequence matrix,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"Acceptance must reject at known exact offsets: lone continuation bytes, malformed continuation sequences, truncated sequences, overlong encodings, UTF-16 surrogate encodings, invalid lead bytes 0xC0 / 0xC1 , values introduced by 0xF5 - 0xFF , and code points above U+10FFFF. Every invalid fixture must serialize the same canonical UTF-8 stop reason INVALID_UTF8_SEQUENCE while preserving its fixture-specific exact first-invalid byte offset. For an EOF-truncated multibyte sequence, the expected offset is the lead byte of the incomplete sequence. Acceptance must include at least one malformed sequence crossing a Stage-1 input-window boundary and prove window invariance. Separate valid fixtures covering ASCII-only, valid multibyte UTF-8, and permitted leading-BOM forms must complete with STAGE1_UTF8_OUTCOME: PASS ; their UTF-8 refusal-only Receipt fields are NOT_APPLICABLE .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-007,Late invalidity,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,A source that is ASCII/valid UTF-8 until near EOF and becomes invalid late in the file must fail at the first invalid absolute offset; bounded-prefix success must not be treated as whole-file certification.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-008,Window-size invariance,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,The same fixture matrix must return the same PASS/FAIL and first invalid absolute offset across at least two materially different bounded window sizes.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-009,EOF pending-state refusal,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,EOF with an incomplete UTF-8 sequence must fail deterministically and report the governed offset; no replacement character may be inserted.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ENC-ACC-010,BOM behavior,W002-ENC-ACC,W002-ENC,WASM-002,UNDER REVIEW,—,"A UTF-8 BOM at offset zero must be accepted as metadata while the remainder of the source is still fully certified; a BOM must not mask later invalid UTF-8. F-07 BOM coordinate fixture: when a permitted three-byte UTF-8 BOM precedes a later malformed UTF-8 sequence, the expected first-invalid offset counts the BOM's physical bytes. The BOM is excluded from analytical CSV content but included in the absolute physical source-byte coordinate system.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-001,Multi-column one-pass Stage 2 materialization,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Using a valid UTF-8 source and a Work Order requesting at least four source columns through a mixture of HEADER and COLUMN selectors, acceptance must prove that Stage 1 completes first, Stage 2 restarts at byte zero of the same run-local source instance, parses the header once, resolves all selectors before the first data row, and reads the source data records only once while producing all requested columns. Evidence must reconcile total source bytes read by Stage 2, logical data-row count N, per- COL data-record count N, selector-to-source ordinal/header resolution, resolved KEEP order, and the resulting successor MAP. A one-column rerun of the same source/column must produce the same canonical physical column bytes as that column produced inside the multi-column run, apart from governed artifact identity. F-20 width/one-pass acceptance: acceptance must include a maximum-width fixture whose valid source has exactly 16,384 columns and whose KEEP resolves all 16,384 distinct columns. Instrumentation must prove one source data-record traversal regardless of the implementation's bounded post-scan spool/finalization strategy. A companion 16,385 -column source must refuse during header resolution before the first data record is consumed.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002,"Automatic Store MAP creation, inheritance, and rematerialization continuity",W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must materialize four previously unseen source columns in one Store-establishing Work Order and prove that one successor Store MAP is created with four mapping rows. Every row must repeat identical Store-level fields, bind the newly created RID filename, default store_alias to the exact Store-establishing source filename, default rid_alias to RID , and default each COL alias to its exact source header. A later Work Order using the same exact SOURCE without explicitly naming a MAP must route under W002-STOR-019.2 . If exactly one routable Store lineage exists for that exact source filename and its current Store state permits materialization, the Work Order must inherit that lineage’s current structurally valid Store MAP, preserve the Store/RID metadata and four prior mappings, add a fifth default COL alias, and publish one new complete Store MAP. A later rematerialization of one earlier logical column must preserve its inherited COL alias while updating its column_filename . An explicit older MAP selection must instead use that historical Store state. Equal-latest-timestamp ambiguity within one routed lineage, malformed-newer-MAP fallback within the same Store lineage, no-routable-Store-lineage creation, and multiple-routable-Store-lineages-for-the-same-source refusal must also be exercised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.1,Exact eight-column Store MAP serialization acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must validate the exact Store MAP header store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename , UTF-8 without BOM, LF line endings, deterministic mapping-row order, standard governed CSV quoting, and byte-for-byte repetition of store_alias , rid_filename , rid_alias , and the common source_filename on every mapping row. The fixture must prove that a MAP with inconsistent repeated Store-level metadata, more than one rid_filename , more than one source_filename , a missing or invalid RID filename, a duplicate logical source-column key, or a non-eight-column schema is ineligible for inheritance. Source compatibility fixtures must prove that an explicit MAP may proceed only when the Work Order SOURCE exactly equals that MAP's common source_filename . A different source must refuse before materialization even when its row count equals the Store's RID cardinality; matching row count never creates a positional-join escape. P3-06 validation-tier fixtures: acceptance must distinguish Store-health Tier 1 from full Tier 2 validation. A same-named externally restored RID/COL may be treated as eligible only after it passes the tier required by the operation, and no fixture may label such an artifact “the exact original” solely from its physical filename. Tier-1 fixtures must prove the exact bounded checks in W002-STOR-019.10 without an end-to-end scan of every artifact value. Tier-2 fixtures must prove full RID sequence/cardinality validation and full COL canonical-form/header/cardinality validation. REPAIR MAP fixtures must demonstrate that the same input bytes yield one deterministic set of removed COL bindings under Tier 2. P2-04 closure fixtures: acceptance must include (1) a RID that satisfies Tier 1 but fails Tier 2 because the body does not contain the exact declared 1..N sequence; (2) a COL that satisfies Tier 1 but fails Tier 2 because its complete CSV body or logical-record count is invalid; (3) an externally supplied same-named RID/COL that passes the required governed tier without any assertion that it is the historical original bytes; and (4) a REPAIR MAP case with a mixture of Tier-2-valid and Tier-2-invalid COLs proving that the successor removes exactly the failing bindings. Repeating the same fixture bytes must yield the same repair set and successor mapping.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.2,Multiple Stores in one Suitcase remain distinct through RID-anchored MAP lineages,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must establish at least two Stores from different source files in the same Suitcase. Their Store MAP lineages must contain different immutable rid_filename values, and automatic routing for each source must choose only that source's routable Store lineage. The fixture must prove that a lineage remains routable when at least one Store MAP is structurally valid even if subsequent Store-health evaluation is DEGRADED or INVALID ; health may refuse the operation, but it must not make the lineage disappear from routing. Changing a human-facing store_alias or rid_alias in a later governed MAP must not change the Store's rid_filename , RID bytes, or lineage identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.3,WKO MAP profile and alias-registry publication acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must save at least three immutable WKO artifacts, each containing exactly one non-empty WORK ORDER AS clause: one with a multi-word alias, one whose alias is deliberately replaced under the frozen WKO lifecycle, and one with punctuation permitted by the governed string rules. The committed WKO MAP must satisfy the frozen current-registry schema and lifecycle rules, use UTF-8 without BOM and LF endings, preserve exact physical WKO references, and prove deterministic governed serialization. The fixture must prove that a WKO MAP cannot be treated as a Store MAP; duplicate physical WKO rows are invalid; conflicting current authority for the same non-empty alias is refused before commit; and equal-latest-timestamp ambiguity refuses current-registry selection. A saved/executable WKO without WORK ORDER AS is invalid in Revision BM and must refuse before execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-002.4,WORK ORDER AS and # comment lexical acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"An acceptance fixture must prove that WORK ORDER AS ""Prepare monthly crime data"" is parsed as the immutable WKO alias, that whole-line and trailing # comments are ignored semantically, and that # inside double-quoted strings remains ordinary string content. The fixture must also prove that saved WKO bytes preserve comments exactly, that changing only a comment or Work Order alias requires a new WKO physical identity, and that no standalone browser Description value is required to reopen or display the governed alias. P3-10 alias fixture: acceptance must prove that WORK ORDER AS ""   "" refuses as a whitespace-only alias, while an otherwise valid alias containing leading or trailing whitespace is not silently trimmed or normalized and is preserved exactly in saved WKO bytes and the governed alias registry.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-003,Stage 2 structural window-invariance matrix,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Acceptance fixtures must force input boundaries at structurally difficult positions including before/after delimiters, before/after opening and closing quotes, between doubled quote bytes, between CR and LF, inside quoted multiline field content, at empty fields, and inside already-certified multi-byte UTF-8 sequences. Across permitted window sizes and boundary placements, the logical row count, selected values, canonical COL bytes, first refusal location/condition, and resolved mapping semantics must remain invariant. P3-09 fixtures: acceptance must include both byte forms identified by the Pass 3 finding: (1) an exactly zero-byte source and (2) a source containing only the three UTF-8 BOM bytes EF BB BF . Both must pass the applicable Stage 1 UTF-8 gate and then refuse in Stage 2 with NO_HEADER_RECORD . The exact expected location tuples are respectively (offset 0, physical line 1, logical record 1, field ordinal 1) and (offset 3, physical line 1, logical record 1, field ordinal 1) . The fixtures must also distinguish this case from an existing-but-blank first logical record, which remains BLANK_LOGICAL_RECORD . P3-10 delimiter-help fixture: acceptance must include a quoted semicolon-delimited form such as ""a"";""b"" and an equivalent TAB-delimited quoted form that reach INVALID_BYTE_AFTER_CLOSING_QUOTE . The canonical refusal condition and location facts must remain unchanged, while the Help rendering is permitted to surface the delimiter-mismatch hint for offending byte 0x3B or 0x09 . F-06 structural-refusal acceptance matrix An unexpected quote in an unquoted field must report the quote byte and UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD . A prohibited byte after a closing quote must report that byte and INVALID_BYTE_AFTER_CLOSING_QUOTE . A bare CR outside quoted content must report the CR byte and BARE_CR_OUTSIDE_QUOTED_FIELD . CR, LF, and CRLF inside valid quoted values must remain field content and must not trigger the bare-CR rule. EOF in an open quoted field must report the one-past-end source offset and EOF_INSIDE_QUOTED_FIELD . A blank logical record must report BLANK_LOGICAL_RECORD , not TOO_FEW_FIELDS . A short record must report the terminator/EOF location and the first missing field ordinal. A wide record must report the comma delimiter opening the first extra field and that extra field ordinal. All five refusal facts must remain identical across permitted source-window sizes and boundary placements. Fixtures must force boundaries around commas, opening and closing quotes, doubled-quote pairs, CR/LF pairs, quoted multiline content, empty fields, and already-certified multibyte UTF-8 sequences. A semicolon-separated file must not refuse solely because it uses semicolons; Help may explain comma-only interpretation when header selection fails. Day 060 H-13 Receipt-corpus binding for P3-09 The two analytical P3-09 source fixtures above must each have a corresponding byte-exact refusal Receipt under W002-RCP-ACC-002. The zero-byte and BOM-only cases therefore prove both the parser/refusal oracle and the Receipt serialization oracle independently.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-004,Canonical one-column COL serialization acceptance,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Golden-byte fixtures must cover ordinary ASCII, non-ASCII UTF-8, commas, embedded double quotes, CR, LF, CRLF inside quoted values, explicit empty data values, empty source headers, and header-only zero-row input. Acceptance must prove one UTF-8 BOM at file start, LF record termination independent of host platform, deterministic minimal quoting, doubled embedded quotes, """" for an empty one-column data value, no accidental inclusion of the source BOM in the first header, and byte-identical round-trip semantics through the Data Sculptor CSV reader. F-20 oversized-header serialization acceptance: fixtures at exactly 1,024 and 1,025 Unicode scalar values must prove that the physical COL header remains byte-faithful to the exact decoded source header while only the operational/default-alias name changes at the boundary. Scalar-count fixtures must include combining characters so acceptance cannot accidentally measure UTF-8 bytes or grapheme clusters instead.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-005,"Field-limit, ragged-record, blank-record, and failure-publication acceptance",W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"Acceptance must include decoded field sizes exactly 16 MiB and 16 MiB + 1 byte, malformed runaway quoted-field cases, nonblank records with too few and too many fields, a bare blank logical data record, explicit empty fields, and a physical blank line inside a valid quoted multiline field. The first invalid case must refuse without truncation or silent repair. Publication evidence must additionally exercise both a new-Store multi-column materialization and a later existing-Store materialization. For the new Store, the shared publication-transaction UTC must be established before any new RID/COL SCR candidate is opened, and each candidate-specific UUID must be allocated before its candidate is created. RID and COL outputs must remain governed SCR until the complete candidate set validates; the RID must then promote first, requested COLs must promote in deterministic KEEP order, the successor MAP UUID must be allocated before its MAP SCR candidate is opened, that MAP candidate must be written/closed/reopened/validated while still SCR , and its final SCR -to- MAP rename must occur last. For every successfully promoted RID, COL, and MAP artifact, acceptance must prove that the candidate and final identity have the exact same UTC, UUID, extension, and bytes and differ in the governed filename only by the three-letter semantic class token. For the existing Store, the inherited RID must remain byte-for-byte and filename-identical with no new RID candidate. F-04 existing-Store cardinality acceptance: acceptance must include two otherwise valid existing-Store materializations using the same exact governed SOURCE identity. In the equal-cardinality fixture, Stage 2 candidate N must equal the inherited RID-header N and publication may proceed under the ordinary rules. In the mismatch fixture, candidate N must differ from RID-header N ; the Run must refuse before any candidate COL is promoted into the final COL namespace and before any successor MAP is published. The inherited RID, current MAP, existing COL artifacts, and Store health must remain unchanged, with the existing Store remaining VALID. The equal-cardinality case must not be represented as proof of source-byte or row-semantic identity. Forced failure cases must cover: failure before any promotion; RID-promotion failure; failure during COL promotion after RID and at least one COL have promoted; MAP-candidate write/close/reopen/validation failure; MAP final-rename failure; and interruption after physical RID/COL promotion but before MAP commit. Each case must prove rollback where safely possible or visible non-authoritative SCR failure evidence otherwise, must prove that unreferenced final-class-looking RID/COL files are not treated as committed Store membership, and must prove that the prior valid MAP remains authoritative for an existing Store or that no committed Store exists for an uncommitted first materialization. F-20 bounded-width/name acceptance: acceptance must cover exactly 16,384 versus 16,385 source columns; KEEP widths of 1 and 16,384 ; operational-name derivation at 1,024 versus 1,025 Unicode scalar values; physical ordinals producing Column A , Column Z , Column AA , and Column XFD ; and deterministic oversized-header fallback collisions proving [ordinal] then -2 progression. A separate short-header alias collision must prove refusal rather than automatic suffixing.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-MAT-ACC-006,Large-source browser materialization evidence,W002-MAT-ACC,W002-MAT,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance must include a browser run against the established Statistics Canada scale source or an equivalently retained scale fixture, recording source bytes, Stage 1 time, Stage 2 time, total time, selected-column count, logical row count, bytes written per COL , peak/bounded memory observations, output fingerprints, and browser/platform details. The retained Day 039 evidence established that Microsoft Edge could stream the 7,250,808,204-byte source through a small Rust/WASM materializer and materialize 29,014,718 VALUE data rows in practical time. Revision AM treats that result as engineering evidence and a comparison baseline, not as proof that WASM-002 is already implemented or as a frozen wall-time threshold. F-20 writer-resource evidence: retained acceptance evidence must identify the build's configured maximum simultaneously active writable-output resources and the observed peak for the run. Evidence must show that wide KEEP cardinality does not imply one simultaneously open writer per selected column and that any bounded spool/finalization strategy preserves the same governed output bytes and semantics.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-ACC-001,Separate Windows-1252 conversion,W002-CONV-ACC,W002-CONV,WASM-002,UNDER REVIEW,—,"A non-UTF-8 fixture compatible with the supported Windows-1252 converter must cause the analytical task to stop, permit a Help suggestion, and succeed only when the separate conversion Work Order is explicitly run. P3-08 acceptance: the fixture set must convert an analyst-owned legacy source successfully, materialize the resulting CVT, then perform a second successful conversion from a refreshed legacy source using the same analyst-owned filename. The second conversion must publish a different CVT physical filename. First materialization of that second CVT must establish a distinct Store/RID lineage rather than inherit from the first CVT-backed Store. Acceptance must also prove that Help discloses this consequence at conversion success and again when the CVT is first materialized, and that no hidden original-source identity is used to join the two CVTs into one lineage. F-16 acceptance: the compatible non-UTF-8 fixture must prove that strict UTF-8 certification first emits DS-ENC-001 with next_action: NONE ; Stage 2 does not start; Data Sculptor restarts at byte 0 of the same bound source instance and scans the complete source under the frozen mapping; the Receipt records WINDOWS_1252_COMPATIBILITY_OUTCOME: COMPATIBLE and WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET: NOT_APPLICABLE ; and only then is DS-CNV-001 emitted with severity: INFO , behavior: CONTINUE , and next_action: RUN_WINDOWS_1252_CONVERSION . The refused MATERIALIZE run must remain refused. A separate valid-UTF-8 fixture must prove that both Windows-1252 compatibility Receipt fields are NOT_RUN and DS-CNV-001 is not emitted. F-10 conversion-gate and byte-output acceptance A source already valid as complete strict UTF-8 must refuse CONVERT WINDOWS-1252 TO UTF-8 as unnecessary and create no CVT . A source that fails strict UTF-8 but passes the complete Windows-1252 compatibility assessment may convert only when the separate conversion WKO is explicitly run. The analyst-owned source bytes must remain unchanged. The published CVT must pass complete strict UTF-8 certification. Source CR, LF, and CRLF bytes must be preserved in place rather than normalized. The conversion must remain bounded/streaming. The published CVT must not begin with a UTF-8 BOM introduced by Data Sculptor. The successful Receipt must contain the frozen conversion operation token and required conversion facts. Frozen minimal byte oracle: Windows-1252 source bytes:
63 61 66 E9 0D 0A

UTF-8 CVT bytes:
63 61 66 C3 A9 0D 0A This is café followed by CRLF. The expected CVT begins with byte 63 ; no EF BB BF prefix is present. Day 060 H-25 / BM-04 acceptance: the already-valid-UTF-8 CONVERT fixture must use a complete source whose byte stream is valid strict UTF-8 and must produce a byte-exact refused Receipt containing: SOURCE_ENCODING: UTF-8
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: NOT_RUN
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE The same fixture must prove that no Windows-1252 compatibility assessment runs, no transcoding begins, the analyst-owned source bytes remain unchanged, and no CVT file is created.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-CONV-ACC-002,Undefined Windows-1252 byte refusal,W002-CONV-ACC,W002-CONV,WASM-002,UNDER REVIEW,—,"A fixture containing a byte undefined by the frozen Windows-1252 mapping must not be silently converted. F-16 acceptance: use fixtures placing each of 0x81 , 0x8D , 0x8F , 0x90 , and 0x9D at controlled physical offsets, including across compatibility-buffer boundaries. The complete oracle must prove WINDOWS_1252_COMPATIBILITY_OUTCOME: INCOMPATIBLE , the exact first undefined-byte offset, no DS-CNV-001 emission, no conversion recommendation, and window-size invariance. A separate injected read-failure fixture after the compatibility pass begins must prove NOT_AVAILABLE for both compatibility Receipt fields and no conversion recommendation. F-10 conversion-operation undefined-byte acceptance The separate CONVERT WINDOWS-1252 TO UTF-8 operation must itself refuse before transcoding when its complete compatibility assessment encounters any byte undefined by the frozen Windows-1252 mapping. Such a refusal publishes no CVT . Acceptance must cover each frozen undefined byte value at a controlled absolute source offset and prove that no replacement-character, ISO-8859-1, or permissive-decoder fallback produces output. Day 060 H-14 / BM-11 byte-exact undefined-byte CONVERT fixture The golden CONVERT refusal fixture uses this exact analyst-owned source byte sequence: 41 81 42 The strict UTF-8 gate must fail, and the subsequent complete Windows-1252 compatibility assessment must encounter 0x81 as the first undefined byte at exact zero-based absolute physical source-byte offset 1 . The operation must refuse before transcoding begins. The byte-exact Receipt for this fixture must include: SOURCE_ENCODING: WINDOWS-1252-INCOMPATIBLE
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: 1
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE
RESULT: REFUSED The analyst-owned source bytes must remain exactly 41 81 42 ; no CVT is published; no replacement character is introduced; and no ISO-8859-1 or permissive-decoder fallback is permitted. A second acceptance form must place at least two undefined Windows-1252 bytes in one source and prove that the reported offset is always the first undefined byte. Buffer/window-boundary variants must preserve the same absolute offset.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-001,Canonical diagnostic event,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,At least one real governed WASM-002 failure path must emit a complete canonical diagnostic event with stable code and structured facts. A separate test-only fault-injection fixture must remove or withhold one required fact while the engine attempts to assemble a registered diagnostic. Acceptance must prove that the malformed intended diagnostic is not emitted and that exactly one canonical DS-HLP-001 replacement event is emitted with the exact intended diagnostic ID and the complete ascending-UTF-8 list of missing required fact keys.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-002,Three-voice rendering parity,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"A complete event with an authored catalog entry must be renderable in all three established Help voices. Automated checks must demonstrate invariant diagnostic truth across the three outputs. A separate complete registered diagnostic fixture must deliberately have no help_messages.json entry. Casual, Office Speak, and Technical selections must all resolve to the same deterministic Generic Technical Help fallback, preserving the original diagnostic semantic core and rendering emitted facts in ascending UTF-8 fact-key order without invented cause or remediation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-003,Saved HTML Help report using the canonical built-in Data Sculptor presentation,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,At least one complete HTML Help report using the canonical built-in Data Sculptor presentation must be generated and saved locally from that real event.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-004,Offline durability,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,The saved HTML report must remain readable with its canonical built-in Red5Sorcery/Data Sculptor presentation when opened without network access and without access to Data Sculptor or any external presentation resource.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-008,Support-handoff report acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"From a real governed refusal, Data Sculptor must generate one styled HTML Help Report that opens in an ordinary browser without Data Sculptor or network access and contains both a selected-voice explanation and the canonical structured facts needed by a technical reviewer.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-009,Canonical boundary-fact acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"An early-refusal fixture that stops before analytical materialization must demonstrate the exact four Boolean fact names from W002-HELP-004.11 and, when those are the true governed facts, values equivalent to: source_modified_by_data_sculptor = false
materialization_started = false
analytical_outputs_published = false
store_state_committed = false Acceptance must also exercise at least one boundary-fact case in which an established Boolean value is unavailable or otherwise carries an applicable governed absence state. The emitted value must use the exact shared JSON string token required by W002-HELP-004.11 (for example ""NOT_AVAILABLE"" ) and must not be coerced to false or JSON null . Where a boundary fact is optional and its key is omitted, acceptance must prove that omission is not interpreted as false or as any governed absence token. The same fixture family must prove that temporary SCR candidates or abandoned/uncommitted debris do not make analytical_outputs_published true.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-010,"HLP provenance, multiplicity, and no-automatic-hash acceptance",W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"Acceptance evidence must generate a final HLP using the built-in Red5Sorcery/Data Sculptor presentation and verify its governed __DS__HLP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html identity, its visible Provenance section, and exactly one embedded application/json payload with element ID ds-hlp-provenance . The embedded payload must contain exactly the schema-version-2 fields governed by W002-HELP-009 and must verify the same HLP filename/generation UTC, non-empty ordered diagnostic_ids array, WKO/RCP lineage semantics, selected Help voice, built-in presentation identifier red5sorcery-data-sculptor , built-in presentation version ""1"" , and the exact running Data Sculptor build identifier. Acceptance must cover: (1) an explicit request for a single diagnostic; (2) one governed Run with multiple included diagnostic events, proving exactly one HLP for the request and event-order parity with diagnostic_ids ; and (3) a non-run diagnostic such as Suitcase-validation or WKO-save refusal, proving that non-applicable WKO/RCP lineage is represented by JSON null and visible NOT APPLICABLE rather than invented Run lineage. Acceptance must also cover all three lineage representations permitted by W002-HELP-009: an exact physical filename when the relationship exists and is known; JSON null when the relationship does not apply; and the exact JSON string ""NOT_AVAILABLE"" when the relationship applies but its exact filename cannot be obtained. The fixture must prove that null and ""NOT_AVAILABLE"" are not interchangeable. Acceptance must prove that the visible Provenance section and machine-readable payload agree semantically; missing, duplicate, malformed, mismatched, non-HTML-safe, disclosure-violating, empty diagnostic_ids , or scope-label-only build provenance must not be accepted. The same acceptance must prove that ordinary HLP generation does not compute or embed an HLP SHA-256 and does not create, refresh, or verify an LCK . Exact-byte HLP integrity remains outside WASM-002 in the later explicit FINGERPRINT/LCK workflow.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-011,Fixed support-handoff disclosure acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"Acceptance must prove the fixed support-handoff disclosure boundary with both permitted-context and adversarial headerless fixtures. A permitted-context fixture must generate an HLP whose diagnostic requires a source filename, one genuinely established relevant source header and/or 1-based column number, bounded execution evidence, and a small executable Work Order excerpt. A governed alias may appear only when the alias itself is necessary to explain the diagnostic, such as an alias collision, ambiguity, or mutation; an unrelated alias must remain excluded. The report must include only the necessary permitted facts while excluding source rows/values, absolute local paths, unrelated headers/aliases/columns, the complete Work Order, Work Order comments, unrelated Suitcase contents, and raw ungoverned stack traces. A separate headerless-source fixture must place unmistakable sentinel text in the first data row and prove that none of that text appears in the HLP as a header or other disclosed source value. That HLP must show Source header text included: NO and Source values included: NO while still presenting sufficient structural evidence to explain the diagnostic. A genuine-header fixture must prove that a necessary established header may appear with Source header text included: YES . Alias fixtures must similarly prove truthful Governed alias text included: YES only when necessary and NO otherwise. Every fixture must verify the remaining frozen Disclosure declarations from W002-HELP-010. WASM-002 must expose no control that changes this fixed disclosure policy.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-012,Cross-session source-continuity Help acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"An acceptance fixture must present Help with a suspected cross-session source-change scenario and verify that the explanation asks whether the source may have been edited/replaced/sorted/re-exported/synchronized, distinguishes no evidence from INVENTORY metadata evidence and stronger explicit fingerprint evidence, and never claims that unchanged filename or unchanged INVENTORY metadata proves byte identity. A no-evidence fixture must state that continuity cannot be independently verified. An INVENTORY fixture with changed source byte length or last-modified metadata must describe the difference as evidence that the source may have changed, not as a cryptographic conclusion. The fixture must also confirm that ordinary WASM-002 materialization did not automatically hash the source as part of this edge-case protection.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-HP-ACC-013,Diagnostic-registry and Help cross-validation acceptance,W002-HP-ACC,W002-HP,WASM-002,UNDER REVIEW,—,"WASM-002 acceptance must retain the validated diagnostics.json used by the accepted build and verify its exact version-1 schema, canonical sort order, unique permanent IDs, fixed-token grammars, and disjoint required/optional fact declarations. At least one real governed diagnostic fixture must prove that the emitted semantic core matches the matching registry entry and that all required facts are present while no undeclared fact key is emitted. Negative build-validation fixtures must prove deterministic failure for malformed/duplicate registry entries, an engine diagnostic definition absent from the registry, fixed semantic disagreement, an undeclared emitted fact, a Help-catalog diagnostic ID absent from the registry, and a Help placeholder not declared for its matching diagnostic. F-17 runtime completeness fixtures: missing required facts are no longer treated as a malformed event that may leak to Help. Fault injection must prove deterministic substitution with DS-HLP-001 , including exact intended_diagnostic_id and sorted missing_required_facts , with no partially populated intended diagnostic emitted. Separately, a valid registered diagnostic omitted from help_messages.json must remain a valid build/runtime condition and must exercise the Generic Technical fallback rather than build failure or diagnostic suppression. F-22 QA-independence acceptance boundary: acceptance must prove the registry/engine/Help wiring and generic invariants without circularly presenting the implementation-delivered registry as an independent oracle for its own condition-to-Diagnostic-ID allocations. Representative governed fixtures must trace condition → emitted Diagnostic ID → matching registry semantic core → required/optional fact discipline → Help lookup/rendering. Every condition-to-ID or required-fact mapping explicitly frozen elsewhere in this PRD remains independently testable and must match that PRD contract. For allocations not independently pinned by this PRD, WASM-002 does not require a duplicate QA-owned registry that restates every condition-to-ID choice. Passing this acceptance gate therefore demonstrates registry integrity, engine↔registry semantic agreement, fact completeness/legality, Help-catalog wiring, F-17 fail-safe behavior, and representative end-to-end diagnostic routing; it must not be reported as exhaustive independent proof that every possible runtime condition was assigned the semantically correct Diagnostic ID. That residual independence limitation is an accepted WASM-002 risk. F-23 embedded Help-catalog release fixture: acceptance must build the released HTML from a validated help_messages.json , verify exactly one non-executable application/json payload with element ID ds-help-catalog , and include adversarial catalog text containing literal < / script-like delimiter content to prove HTML-safe embedding. Runtime instrumentation must prove that Help lookup reads only the embedded payload and performs no network, filesystem, Suitcase, or adjacent-file fetch for the Help catalog. A missing, malformed, mismatched, or unsafe embedded catalog must fail build acceptance.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-007,Work Order syntax is the analytical contract,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"If a value, reference, option, or instruction changes what Data Sculptor analytically does, that intent must be represented in governed Work Order text or in a separately governed artifact explicitly referenced by that Work Order. Browser permission, directory selection, UI focus, a highlighted file, an alias display, or another GUI gesture must not silently become analytical intent. For WASM-002, every executable saved WKO begins with the common preamble: SUITCASE: .
WORK ORDER AS ""<non-whitespace alias>"" Ignoring blank lines and governed comments, the WKO must then parse completely under exactly one of these seven executable operation grammars: Operation Governed DS-STEPS structure after the common preamble MATERIALIZE SOURCE ""..."" ; optional MAP ""..."" ; KEEP ; one or more selectors; terminal MATERIALIZE . INVENTORY terminal INVENTORY only. UPDATE ALIASES exactly one Store-state selector: SOURCE ""..."" or MAP ""..."" ; one or more governed alias mutations; terminal UPDATE ALIASES . REPAIR MAP exactly one MAP ""<exact current Store MAP filename>"" ; terminal REPAIR MAP . REPAIR WORK ORDER REGISTRY terminal REPAIR WORK ORDER REGISTRY only. CONVERT WINDOWS-1252 TO UTF-8 exactly one SOURCE ""..."" ; terminal CONVERT WINDOWS-1252 TO UTF-8 . CATALOG STORES terminal CATALOG STORES only. Each operation-specific numbered requirement remains authoritative for its detailed selectors, preconditions, mutations, publication semantics, and acceptance behavior. This requirement freezes the cross-operation boundary: unknown semantic lines refuse; clauses from another operation grammar refuse unless the selected operation explicitly defines them; there is no best-effort interpretation and no silent cross-operation mixing. Lexical token separation. DS-STEPS keywords are matched ASCII case-insensitively; canonical examples render them uppercase. Wherever two adjacent lexical tokens would otherwise run together, they must be separated by one or more ASCII SPACE ( 0x20 ) or horizontal TAB ( 0x09 ) characters. Leading SPACE/TAB indentation is semantically neutral. Thus REPAIR MAP , SOURCE ""crime.csv"" , and COLUMN 7 are valid tokenizations, while REPAIRMAP , SOURCE""crime.csv"" , and UPDATE_ALIASES are not alternate DS-STEPS spellings. Quoted-string contents are never case-folded or whitespace-normalized merely because keywords are case-insensitive. The browser may authorize resources, edit text, validate, save, invoke Run, display evidence, and provide Help. Authorization to access a resource is not authorization to use that resource analytically.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-008,Every executable Work Order explicitly declares its Suitcase,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"For WASM-002, every executable saved Work Order must contain the exact portable declaration SUITCASE: . . The dot means the filesystem directory that physically contains the saved WKO artifact being executed. A Work Order lacking this declaration must not be treated as an executable WASM-002 Work Order. The declaration is analytical/execution syntax, not a substitute for browser filesystem permission. The host must still possess valid access to the directory before execution can proceed. Help obligation: Data Sculptor Help must explain SUITCASE: . in plain language: the saved Work Order uses the folder that contains that WKO as its Suitcase; the dot means “this folder”; ordinary Work Order file references are therefore portable and Suitcase-relative; and browser/host permission to the folder is granted separately. Help must not teach an absolute machine path as the normal replacement for . .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-009,Ordinary Work Order file references are Suitcase-relative,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Unless another numbered requirement explicitly governs a different reference mechanism, file references in an executable WASM-002 Work Order resolve relative to the declared Suitcase. A portable Work Order must not depend on an absolute machine-specific path to identify ordinary Suitcase files. Resolution must be deterministic in browser and later native hosts. Moving an intact Suitcase to another permitted filesystem location must not change the logical meaning of the Work Order solely because the parent machine path changed.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-009.1,WASM-002 SOURCE eligibility is exact and root-bounded,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"A WASM-002 SOURCE clause names exactly one physical regular file in the Suitcase root by exact filename only. It must not name an absolute path, drive or UNC path, subdirectory, path containing / or \ , traversal such as .. , URL/URI, or another external reference. Resolution uses the exact Unicode-scalar filename identity and reference-bounded rules frozen by F-15; no case-folding, normalization, trimming, or filesystem-equivalence search is permitted. The only eligible WASM-002 SOURCE kinds are: Analyst-owned CSV: a regular Suitcase-root file whose exact filename does not begin with the reserved exact prefix __DS__ and whose final extension is .csv under ASCII case-insensitive extension recognition. Thus .csv , .CSV , and mixed-case equivalents are candidate CSV extensions. This case-insensitivity applies only to extension recognition; the complete filename reference remains exact. If the physical file is crime.CSV , a differently cased full filename does not become an alternate reference to it. Governed converted source: a successfully published CVT whose exact canonical identity and class-specific publication/validity predicate satisfy W002-CONV-004, W002-STOR-023, and PB-STOR-008. A filename that merely resembles a CVT is not sufficient. No other governed semantic class is eligible as SOURCE in WASM-002, even when its physical serialization is CSV. In particular, COL , RID , MAP , CAT , INV , RCP , HLP , CER , SCR , RCV , and WKO artifacts cannot be reintroduced as SOURCE merely because their bytes or extension appear compatible. A recognized .csv extension establishes only candidate SOURCE form. It does not certify encoding or CSV structure; the normal strict UTF-8 and structural certification contracts still govern after source resolution. Conversely, CSV-like bytes stored under a non-CSV analyst-owned extension are not an eligible WASM-002 SOURCE.",PARTIAL,PORTION_VERIFIED,NOT_REVIEWED,NOT_ACCEPTED,CP-008; CP-009; CP-010,"T-ACCEPTED, BANKED; analyst-owned CSV filename candidate preflight only; full SOURCE eligibility remains partial; CP009 T-ACCEPTED, BANKED — pure exact-name root snapshot matching only; full requirement remains partial; CP010 T-ACCEPTED, GIT BANKED — lexical CVT candidate only; complete requirement remains open",346733a962192320e0d56271add15a47b6037b6b; dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8; b7c515faa9bd000369d7656e09437310261290ae,Evidence/CP-008/CP008_RED_Test_Output.txt; Evidence/CP-008/CP008_GREEN_Test_Output.txt; Evidence/CP-008/CP008_Full_Regression_Test_Output.txt; Evidence/CP-008/CP008_Post_Format_Test_Output.txt; Evidence/CP-008/CP008_Rustfmt_Check_Output.txt; Evidence/CP-008/CP008_WASM_Build_Output.txt; Evidence/CP-008/CP008_Hash_Inventory_Verification.txt; Evidence/CP-008/CP008_Precommit_Git_Review.txt; Evidence/CP-008/CP008_Final_Source_Review.txt; Evidence/CP-008/CP008_Whitespace_Exception_Review.txt; CP008_Git_Banking_Output.txt (separate post-commit evidence; archived outside repository); Evidence/CP-009/CP009_Baseline_Test_Output.txt; Evidence/CP-009/CP009_RED_Test_Output.txt; Evidence/CP-009/CP009_GREEN_Test_Output.txt; Evidence/CP-009/CP009_Full_Regression_Test_Output.txt; Evidence/CP-009/CP009_Rustfmt_Check_Output.txt; Evidence/CP-009/CP009_Git_Whitespace_Check.txt; Evidence/CP-009/CP009_Post_Format_Test_Output.txt; Evidence/CP-009/CP009_WASM_Build_Output.txt; Evidence/CP-009/CP009_Hash_Inventory.txt; Evidence/CP-009/CP009_Hash_Inventory_Verification.txt; Evidence/CP-009/CP009_Precommit_Git_Review.txt; Evidence/CP-009/CP009_Final_Staging_Review.txt; CP009_Git_Banking_Output.txt (separately archived post-commit evidence); Evidence/CP-010/CP010_Scope_Lock.txt; Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt; Evidence/CP-010/CP010_GREEN_Test_Output.txt; Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt; Evidence/CP-010/CP010_WASM_Build_Output.txt; Evidence/CP-010/CP010_Post_Format_Check_Output.txt; Evidence/CP-010/CP010_Hash_Inventory_Verification.txt; Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt; Evidence/CP-010/CP010_Closing_Git_Review.txt; CP010_Git_Banking_Output.txt (post-commit; separately archived),"CP008 Day066: public is_analyst_owned_csv_source_candidate(&str) -> bool recognizes the final .csv extension ASCII case-insensitively for exact Suitcase-root analyst-owned candidate names. It refuses empty stems, __DS__-reserved names, slash/backslash paths, colon-bearing references, and traversal-like double-dot forms; preserves full spelling, case and Unicode normalization distinctions. Five new tests and 23 prior tests passed, 28/28 after Rustfmt. WASM32-target library compilation passed; no standalone browser execution proven. 20/20 SHA-256 file inventory matched; staged Rust source/test whitespace check 0. Full staged whitespace check 2 due solely to two preserved archival trailing-space lines in the CP008 precommit TXT, documented with supplemental diagnostic. Human T approved; Git commit banked with 18 files and clean working tree. This is ONLY lexical analyst-owned CSV candidate form, NOT regular-file proof, exact physical filename resolution, governed CVT publication, CSV UTF-8 certification, full SOURCE eligibility, or requirement acceptance. Independent Claude implementation QA pending. CP009 Day066: match_analyst_csv_root_snapshot(&str, &[RootSnapshotEntry]) -> RootSnapshotMatch applies CP008 analyst CSV candidate preflight, then exact Rust string equality (case, Unicode scalar sequence and whitespace preserved), reports no match, reported nonregular entry, ambiguous duplicate exact entries, or single caller-reported regular file. Entry origin and kind are caller assertions, not independently verified. Eight new tests; post-format full native regression 36/36; wasm32-unknown-unknown library compilation exit 0; SHA-256 inventory verified 22/22; staged whitespace exit 0; T approved and git banked 15 files, clean working tree. This is NOT actual root scanning, filesystem entry proof, browser permission, CSV/UTF-8 certification, governed CVT SOURCE eligibility or end-to-end requirement acceptance; independent Claude QA pending. CP010 Day066 adds is_governed_cvt_source_filename_candidate(&str)->bool, requiring existing canonical immutable envelope validator, exact CVT class, and exact lowercase .csv serialization token. Four bounded tests pass and native full regression 40/40; wasm32-target library build PASS with Rust 1.97.1; format check PASS; primary 29/29 and supplementary 8/8 SHA-256 verification PASS; staged whitespace PASS with documented exact-file archival exceptions; T approval; git b7c515faa9bd000369d7656e09437310261290ae committed 28 files and clean working tree. No physical file checks, conversion execution, close/reopen, publication predicate, UTF-8/CSV certification, executable SOURCE authority or browser runtime proven. Independent Claude QA pending.",Day066,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-010,WIP and WKO are distinct Work Order lifecycle states,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"WIP is the editable, non-executable Work Order state. WKO is the saved, validated, immutable Work Order artifact that may become a Run target. Validation establishes that a Work Order is structurally eligible to run; it does not guarantee that runtime conditions will succeed. Loading a WKO for inspection does not make it mutable. If its instruction text is changed, the editor must treat the edited text as a new WIP derived from the original WKO. The original WKO bytes and physical identity remain unchanged, and the derived WIP cannot Run until saved as a new WKO. F-08 Run distinction: the browser Run action invokes one selected saved immutable WKO that is eligible under the governed WKO-registry rules. No ordinary WASM-002 WKO contains a textual RUN line merely to execute itself. The DS-STEPS token RUN is reserved for future saved-Work-Order composition under W002-WKO-011 and is not repurposed as the browser execution trigger.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-013,WASM-002 executes one saved Work Order without Work Order chaining,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"For WASM-002, one saved immutable WKO is one top-level executable request. It must not invoke, include, chain, or execute another WKO. The governed RUN composition operation and equivalent nested-orchestration constructs are not executable in WASM-002. If a saved WKO contains composition syntax, validation must refuse before analytical execution begins. The canonical diagnostic and Help path must explain that Work Order composition is deferred rather than treating the syntax as arbitrary text, silently ignoring it, or partially executing surrounding instructions. This scope cut does not prohibit one Work Order from selecting and materializing multiple columns in the single Stage 2 operation defined by WASM-002.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012,Materialization COL alias assignment uses AS; standalone alias maintenance uses UPDATE ALIASES,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within the WASM-002 DS-STEPS materialization form, an analyst assigns or changes the alias of a selected materialized COL with the optional same-line clause AS ""alias"" under W002-STEPS-005. This syntax is part of the governed Work Order and is not a GUI gesture. A single KEEP block may therefore assign aliases to multiple selected columns in one governed materialization. Automatic source-header COL aliases and inherited rematerialization aliases are resolved first; explicit AS clauses then determine requested successor COL aliases before complete Store-MAP validation and publication. Revision BD freezes alias-only creation/replacement with UPDATE ALIASES and explicit historical Store-MAP selection with MAP ""<exact Store MAP filename>"" . Revision BE completes the bounded alias lifecycle with explicit CLEAR ... ALIAS and RESET ... ALIAS forms under W002-WKO-012.5 through W002-WKO-012.6. Empty-string AS """" is not the clearing syntax.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.1,Canonical standalone alias-maintenance Work Order uses UPDATE ALIASES,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"The canonical alias-only Store metadata forms are: SUITCASE: .
WORK ORDER AS ""Rename crime store""
SOURCE ""35100178.csv""
STORE AS ""Crime Statistics""
UPDATE ALIASES or, when the analyst intentionally selects one exact Store snapshot: SUITCASE: .
WORK ORDER AS ""Rename crime store""
MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""
STORE AS ""Crime Statistics""
UPDATE ALIASES UPDATE ALIASES is the explicit terminal commitment clause for an alias-only Work Order. The WKO must identify exactly one Store-state base using either SOURCE ""..."" for ordinary Store-aware current-state selection or MAP ""..."" for exact Store-MAP selection, never both. At least one supported alias mutation clause must occur after the Store-state selector and before UPDATE ALIASES . An alias-only Work Order must not contain KEEP , MATERIALIZE , INVENTORY , conversion, Store repair, Work Order registry repair, cataloging, deferred Work Order composition, or another operation's terminal clause. Alias maintenance changes governed human-facing metadata only.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.2,"STORE AS, RID AS, and COL ... AS are the canonical alias-replacement clauses",W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical mutation clauses are: STORE AS ""Crime Statistics""
RID AS ""Row Number""
COL ""Crime Rate"" AS ""Police-Reported Crime Rate"" STORE AS ""..."" replaces the selected Store snapshot's store_alias . RID AS ""..."" replaces its rid_alias . COL ""<reference>"" AS ""..."" replaces the alias of exactly one existing mapped COL. The COL reference resolves under W002-STOR-021: it may be the exact physical column_filename or one unique current COL alias from the selected Store MAP. Missing, ambiguous, non-COL, or conflicting resolution must refuse rather than guess. One Work Order may update the Store alias, RID alias, and multiple distinct COL aliases together, provided the complete successor state satisfies all existing alias uniqueness/shadowing rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.3,"MAP ""<filename>"" is the exact historical Store-MAP selector",W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"The canonical explicit Store-MAP selection clause is: MAP ""__DS__MAP__20260920T184512347Z__<uuid-v4>.csv"" The value is always the exact physical filename of one structurally valid immutable Store MAP. It is not a Store alias, WKO alias, timestamp shorthand, UUID-only selector, or latest expression. For MATERIALIZE, if present, the clause occurs immediately after SOURCE and before KEEP . It overrides automatic Store-MAP inheritance and binds the run to exactly the named Store snapshot. For alias-only maintenance, the Work Order uses either SOURCE ""..."" or MAP ""..."" as its Store-state selector, not both. For materialization, SOURCE ""..."" remains mandatory and an optional MAP ""..."" supplies the exact historical/current Store-state base. Validation must refuse an incompatible source/MAP pairing or a MAP that is not a valid Store-MAP profile. Health rule: explicit historical selection does not override the current Store-lineage health gate. The selected lineage must currently be VALID and every RID/COL binding referenced by the named MAP must currently be present and valid. Otherwise the operation refuses. This applies equally to MATERIALIZE and UPDATE ALIASES. F-05/P2-01 source-compatibility predicate: for materialization, an explicitly named MAP is compatible only when the mandatory Work Order SOURCE exactly equals the one common source_filename carried by that Store MAP. If the exact filenames differ, validation refuses before the F-04 existing-Store cardinality gate in W002-MAT-002.6. Equal row count never authorizes a different source to enter the selected Store lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.4,Alias-only execution publishes one complete successor Store MAP and no rewritten data artifacts,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"A successful UPDATE ALIASES operation begins from the selected complete Store MAP, applies only the requested alias replacements in memory, validates the complete resulting Store state, writes the successor MAP under governed SCR , closes and reopens it, validates it fully, and promotes it to a new immutable MAP last. That successful promotion is the alias-update commit point. The operation must preserve the selected Store's physical RID and COL filenames and bytes, source-column keys, row order, cardinality, and lineage except for the human-facing alias fields explicitly changed by the Work Order. It must not reread source data rows merely to change aliases, must not create RID/COL artifacts, and must not rewrite or delete the inherited MAP. The prior MAP remains visible historical state. If validation or MAP publication fails, no successor alias state becomes current. The failure is reported through the governed diagnostic/Help path and any incomplete candidate remains subject to the retained- SCR failure-evidence rules in W002-STOR-023.1; WASM-002 does not emit RCV. Revision BM E-02 integration: when the alias-only operation uses an explicitly named historical Store MAP, publication is permitted only if the Store lineage currently evaluates VALID and every RID/COL binding referenced by that named MAP is currently present and valid. An older MAP cannot be used to bypass current damage. P3-06 validation depth: because UPDATE ALIASES does not consume RID/COL analytical contents, its Store-health and binding checks use Tier 1 under W002-STOR-019.10. The operation must not scan every RID/COL record merely to change aliases. This does not weaken later operations that actually consume those artifacts; they must perform the applicable Tier 2 validation before relying on the contents.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-007,Standalone Store/RID/COL alias maintenance acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance must establish a Store with one RID and at least three materialized COLs, then execute an alias-only Work Order that changes the Store alias, RID alias, and at least two COL aliases in one UPDATE ALIASES operation. One COL must be targeted by its unique current alias and another by its exact physical COL filename. The fixture must prove that exactly one complete successor Store MAP becomes current; prior MAP, RID, and COL artifacts remain byte-for-byte unchanged; no source-data row read is required; no new RID/COL artifact is published; and the successor MAP contains exactly the requested aliases while preserving all physical bindings and logical source-column keys. Missing/ambiguous COL references and successor alias collisions must refuse without publishing a successor MAP. F-23 CLEAR/RESET alias fixtures: acceptance must separately exercise CLEAR STORE ALIAS , CLEAR RID ALIAS , CLEAR COL ""<reference>"" ALIAS , RESET STORE ALIAS , RESET RID ALIAS , and RESET COL ""<reference>"" ALIAS . Each CLEAR fixture must prove that the successor MAP stores the governed empty alias without renaming or rewriting the referenced artifact. Each RESET fixture must prove restoration of the exact deterministic default governed by W002-WKO-012.6 and W002-STOR-019.7, including the oversized-header operational fallback where applicable. The fixtures must prove that CLEAR and RESET require no source-data row read, publish exactly one complete successor Store MAP on success, leave the predecessor MAP/RID/COL bytes unchanged, and deterministically refuse duplicate mutation of the same alias field or a reset/default value that fails the complete successor alias validity/uniqueness/shadowing rules.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-008,Explicit historical Store-MAP selection acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance must create at least two valid Store MAP snapshots for one Store, then prove that a Work Order containing MAP ""<older exact Store MAP filename>"" binds to that exact older snapshot even though a newer valid MAP exists. An alias-only fixture must publish its successor from the explicitly named older base rather than from the newer automatic current state. A materialization fixture must retain mandatory SOURCE ""..."" while using the explicit MAP as its Store-state base. The tests must also prove refusal for a missing MAP, malformed MAP, WKO-MAP profile supplied as Store MAP, and source/MAP incompatibility. No implementation may substitute the newest MAP after an explicit MAP clause has validated. F-21 chronology acceptance: the fixture must use at least three successive valid MAP snapshots for one Store so that an explicitly selected older base and a distinct pre-run current MAP both exist. Merely selecting/validating the older MAP must leave current authority unchanged. A successful governed operation from that older base must then publish exactly one new successor whose requested state is derived from the named older base, whose publication UTC is later than the pre-run current chronology predecessor, and which becomes current under ordinary greatest-UTC selection. The selected historical MAP and the formerly current MAP must remain byte-for-byte unchanged. Acceptance must prove that later mappings/aliases present only in the formerly current MAP are not silently merged into the historical-base successor unless the Work Order explicitly recreates them. Receipt evidence must identify the exact operation base and exact published successor through the already-frozen operation-specific Receipt fields. No additional warning/permission gate or informational diagnostic is required merely because the analyst explicitly chose a historical base.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.5,CLEAR ... ALIAS deliberately removes a human-facing alias,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical clearing forms are: CLEAR STORE ALIAS
CLEAR RID ALIAS
CLEAR COL ""<reference>"" ALIAS CLEAR deliberately stores the empty string in the corresponding alias field of the successor Store MAP. It does not restore a default alias. An empty-string replacement such as STORE AS """" , RID AS """" , or COL ""..."" AS """" is not the canonical clearing form and must be rejected by the bounded WASM-002 grammar. For CLEAR COL , <reference> resolves against the selected pre-mutation Store MAP by exact physical column_filename or one unique current COL alias under W002-STOR-021. All COL references in one UPDATE ALIASES Work Order are resolved before any mutation is applied so clause order cannot change target identity. Missing, ambiguous, duplicate-target, or non-COL references must refuse. Clearing an alias never renames, rewrites, or deletes the underlying RID/COL artifact and never changes physical identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-012.6,RESET ... ALIAS restores the deterministic default alias,W002-WKO,W002-WKO,WASM-002,UNDER REVIEW,—,"Within an alias-only UPDATE ALIASES Work Order, the canonical reset forms are: RESET STORE ALIAS
RESET RID ALIAS
RESET COL ""<reference>"" ALIAS RESET STORE ALIAS restores the Store MAP's common exact source_filename . RESET RID ALIAS restores the literal RID . RESET COL ""<reference>"" ALIAS restores that mapped COL's deterministic operational default defined by W002-STOR-019.7 from its exact recorded source_header and physical source ordinal: the exact header when it contains at most 1,024 Unicode scalar values, or the deterministic Column <LETTERS> fallback/disambiguation rule when the recorded header exceeds that boundary. RESET never substitutes the potentially oversized exact header into the alias field merely because that header remains authoritative source evidence. RESET is therefore distinct from CLEAR . The restored value must pass the same governed alias validity, uniqueness, and shadowing rules as any explicit alias. If the deterministic default is empty or conflicts in the complete successor Store MAP, RESET must refuse except for the narrow oversized-header fallback/disambiguation rule already frozen in W002-STOR-019.7; Data Sculptor must not otherwise invent a suffix, alternate spelling, or substitute. AS , CLEAR , and RESET mutations may coexist in one Work Order when they target distinct alias fields; duplicate mutation of the same alias field in one Work Order must refuse. A successful operation publishes exactly one complete successor Store MAP under the existing UPDATE ALIASES commit contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001,Canonical WASM-002 DS-STEPS materialization form,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The canonical WASM-002 materialization Work Order form is: # Optional human comment
SUITCASE: .
WORK ORDER AS ""Prepare monthly crime data""
SOURCE ""crime.csv""
[MAP ""__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv""]

KEEP
  HEADER ""REF_DATE"" AS ""Year""      # reporting year
  HEADER ""GEO""
  COLUMN 7 AS ""Crime Rate""

MATERIALIZE SUITCASE: . is governed by W002-WKO-008. WORK ORDER AS ""..."" is mandatory for an executable/saved WASM-002 Work Order and declares the immutable human-facing WKO alias governed by W002-STEPS-001.1. SOURCE ""..."" names the exact Suitcase-root source file. MAP ""..."" is optional with cardinality 0..1. If present, it occurs immediately after SOURCE and before KEEP , names one exact physical governed Store MAP filename, and binds the run to that exact current or historical Store lineage subject to W002-STOR-019.3 and W002-WKO-012.3. If absent, the Store-aware exact-source routing rules apply. KEEP is the bare governed keyword and introduces one or more column selectors. KEEP: is not valid WASM-002 syntax. Each selector is either HEADER ""..."" or COLUMN n and may optionally end with AS ""..."" . MATERIALIZE is the explicit terminal commitment verb. Duplicate structural clauses refuse. An empty KEEP refuses. After MATERIALIZE , only blank lines or comments may follow; a trailing comment on the physical MATERIALIZE line is permitted because comments are removed from the semantic token stream. # comments are governed by W002-STEPS-001.2. No RID/row-index clause appears in the Work Order. If this materialization establishes a new Store, the engine automatically generates exactly one RID artifact under W002-RID-002 and W002-RID-008. If it extends an existing Store, the existing RID is reused subject to the Store health/cardinality rules. This requirement freezes the bounded keyword structure and selector forms shown above for BM integration. Other complete-language lexical features remain outside this bounded syntax freeze unless separately specified. F-08 common-grammar boundary: MATERIALIZE is one of the seven executable WASM-002 operation grammars governed by W002-WKO-007. Its optional MAP clause remains in the frozen position immediately after SOURCE and before KEEP . The terminal MATERIALIZE clause is DS-STEPS syntax; the browser's Run action is not written into the Work Order. F-20 bounded KEEP: the canonical KEEP block contains at least one and at most 16,384 selectors, and after resolution those selectors must identify at least one and at most 16,384 distinct source columns. This is the complete WASM-002 selection-width bound.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001.1,WORK ORDER AS declares the immutable human-facing Work Order alias,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"An executable or saved WASM-002 Work Order must contain exactly one top-level clause: WORK ORDER AS ""<alias>"" In canonical forms it appears after SUITCASE: . and before the operation-specific source/selector clauses. The decoded alias must be non-empty. The quoted alias may contain spaces and ordinary UTF-8 phrase text subject to the governed string-literal rules. The alias affects display and governed alias resolution only; it does not replace the WKO filename/UUID as physical execution identity. The alias is stored in the immutable WKO bytes and is published into the current WKO MAP when the WKO save transaction commits. Changing the alias therefore requires saving a new WKO under the frozen WKO lifecycle. No valid executable/saved WKO in WASM-002 is unaliased. P3-10 alias-content rule: “non-empty” means that, after decoding the quoted string literal, the alias must contain at least one non-whitespace character. An alias consisting only of whitespace refuses Work Order validation. Data Sculptor must not trim, collapse, normalize, or otherwise rewrite leading or trailing whitespace in an otherwise valid alias; the decoded alias text remains authoritative and is preserved exactly in the immutable WKO and governed WKO MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-001.2,# introduces a DS-STEPS line comment outside double-quoted strings,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"Outside a double-quoted string, the first # on a line begins a comment that continues through the line's LF terminator. Whole-line comments and trailing comments are permitted. Comment text has no execution semantics and is ignored by the DS-STEPS parser after lexical recognition. A # inside a double-quoted string is ordinary string content and does not begin a comment; for example WORK ORDER AS ""Analysis #3"" and HEADER ""CATEGORY #"" preserve the hash character. WASM-002 defines no block-comment syntax. Comments are preserved byte-for-byte in the saved immutable WKO TXT. Editing, adding, or removing a comment changes the WKO bytes and therefore requires saving a new WKO artifact even though analytical semantics may remain unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-002,HEADER selects by exact decoded source-header value,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"HEADER ""name"" resolves against the exact decoded header values established for the certified source. Header equality is exact Unicode scalar-value sequence equality under PB-STOR-010: Data Sculptor performs no case folding, locale folding, Unicode normalization, trimming, or filesystem-style comparison. A selector that matches no source header must refuse. If the same exact decoded header sequence occurs in more than one source column, the header selector is ambiguous and must refuse rather than choose by position, discovery order, normalization, case-insensitive similarity, or another heuristic. An analyst can disambiguate duplicate exact header text with the 1-based COLUMN n selector. F-20 selector identity: HEADER always matches the authoritative exact decoded source header. It never matches an operational fallback name such as Column AA , a generated collision-disambiguation suffix, a COL alias, or a truncated form of the source header.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-003,COLUMN selects by 1-based source ordinal,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"COLUMN n identifies the source column by 1-based ordinal position. COLUMN 1 is the first source column. Zero, negative values, non-integers, and ordinals greater than the source width must refuse. Ordinal selection does not suppress source metadata: Data Sculptor must still resolve and record the selected column's actual decoded source header in the successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-004,HEADER and COLUMN selectors may be mixed but may not select one source column twice,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"One KEEP block may contain any supported mixture of HEADER and COLUMN selectors. Selector order expresses the analyst's requested selection order for the governed operation. After resolution, two or more selectors that identify the same physical source column constitute a duplicate selection and must refuse before materialization. Data Sculptor must not materialize the same source column twice merely because it was named once by header and once by ordinal.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-005,AS assigns the resulting materialized-column alias,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The optional clause AS ""alias"" belongs to the immediately preceding HEADER or COLUMN selector and expresses an intentional human-facing alias assignment in the governed Work Order. For a logical source column not present in the inherited MAP, omission of AS uses the exact source header as the default alias. For a logical source column already present in the inherited MAP, omission of AS preserves the inherited alias. An explicit AS overrides either default for the successor MAP.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-006,The complete successor MAP must contain unique aliases,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"After inheritance, selector resolution, default-alias application, rematerialization continuity, and all explicit AS clauses are applied, every alias in the complete successor MAP must identify exactly one logical materialized column. If two different logical columns would have the same alias, including a collision with an inherited mapping, validation must refuse unless the Work Order has explicitly resolved the conflict through supported governed syntax. Data Sculptor must not invent suffixes such as Year_2 , use last-write-wins behavior, or silently shadow an existing alias. F-20 narrow generated-name exception: the prohibition on invented suffixes applies to ordinary source-header defaults and analyst-authored aliases. The only automatic suffixing permitted in WASM-002 is deterministic disambiguation of an oversized-header operational fallback under W002-STOR-019.7. That mechanism is not an alias-repair heuristic and must not be applied to an explicit AS value or to a short exact source-header default.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-007,MATERIALIZE commits the resolved KEEP set to the governed structural pass,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"MATERIALIZE is the explicit commitment verb for this WASM-002 DS-STEPS form. The KEEP selectors express which source columns belong in the operation; they do not themselves authorize data-row materialization. Before the bounded structural pass begins, the source, all selectors, actual source ordinals/headers, requested aliases, inherited alias state, and resulting alias uniqueness must be resolved and validated. Successful multi-column execution then follows the one-pass materialization contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-008,The Store MAP records resolved truth rather than selector spelling,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"The successor Store MAP must record the fully resolved materialization result using the frozen eight-column schema store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename , regardless of whether the analyst selected a column with HEADER or COLUMN . For example, COLUMN 7 AS ""Crime Rate"" records the Store alias, RID filename/alias, common source filename, source ordinal 7 , the actual decoded header found at column 7, alias Crime Rate , and the newly generated physical COL filename. DS-STEPS expresses intent; the Store MAP persists the resolved durable mapping truth.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-STEPS-009,DS-STEPS materialization syntax acceptance,W002-STEPS,W002-STEPS,WASM-002,UNDER REVIEW,—,"Acceptance must cover: one column selected by exact header; one column selected by 1-based ordinal; mixed header/ordinal selectors in one KEEP block; multiple columns materialized in one governed structural pass; AS alias assignment; default header aliasing; inherited-alias preservation on rematerialization; explicit alias replacement on rematerialization; duplicate-header ambiguity refusal; invalid ordinal refusal; duplicate resolved-column refusal; and duplicate successor-alias refusal. Acceptance must also prove that the generated successor MAP records the same resolved source filename, source ordinal, actual source header, resulting alias, and physical COL identity whether a column was selected by header or by ordinal. For a new Store, both the single-column and multi-column materialization fixtures must contain no RID/row-index instruction yet must automatically publish exactly one RID artifact. For a later permitted same-Store materialization, the fixture must likewise contain no RID instruction and must reuse the original RID without publishing another. Damaged-lineage Help acceptance: fixtures must prove that exact source routing to an INVALID Store, and to a DEGRADED Store whose every mapped COL is broken, refuses ordinary materialization without silently treating the source as unseen. The canonical diagnostic/Help evidence must identify the blocked lineage/current MAP and preserve the frozen analyst-owned exits: external restoration under the original governed physical filename followed by governed validation; source rename to begin a distinct new Store lineage; or moving all lineage MAPs out of the active Suitcase to retire that lineage from routing. The all-COLs-broken fixture must warn that moving only the latest MAP is insufficient. No fixture may imply a new Data Sculptor recovery command, automatic RID regeneration, silent replacement of the damaged lineage, or historical byte identity based only on a restored filename. P3-06 validation-tier acceptance: acceptance must prove that a routine routing/status or alias-only path can use Tier 1 without an end-to-end scan of every RID/COL value, while an operation that consumes artifact contents performs Tier 2 before relying on them. Fixtures must include: a RID that passes Tier 1 but fails Tier 2 because its declared N /sequence is internally wrong beyond the Tier-1 boundary; a COL that passes Tier 1 but fails Tier 2 because its data-record count or CSV body is invalid beyond the Tier-1 boundary; and a REPAIR MAP fixture proving that the Tier-2 failure set determines exactly which COL bindings are removed. P3-07 routing acceptance: fixtures must prove that routing discovers a lineage from a structurally valid Store MAP regardless of whether later Store-health evaluation is VALID , DEGRADED , or INVALID . A separate fixture must present no routable lineage together with at least one structurally malformed Store-MAP-class artifact in the active Suitcase and prove that ordinary materialization refuses before publishing a new RID or first Store MAP, while Help identifies the malformed MAP artifact or artifacts. No fixture may treat an all-MAPs-damaged condition as permission for a silent replacement lineage. F-08 cross-operation grammar acceptance: fixtures must prove the common preamble, ASCII-case-insensitive keywords, exact quoted-value preservation, required SPACE/TAB token separation, unknown-line refusal, one-operation-per-WKO refusal, and separation between DS-STEPS terminal phrases and Receipt OPERATION tokens. At least one fixture for each of the seven executable operations must prove that its canonical structure validates while an otherwise similar WKO containing another operation's terminal clause refuses. Separate fixtures must prove that browser Run does not require a textual RUN clause and that parsed RUN composition syntax refuses as deferred before analytical execution. P2-04 restoration-language acceptance: Help, diagnostics, UI text, and acceptance evidence may say that a file restored under the exact governed physical filename passed the required validation tier and may therefore re-enter use. They must not state or imply that filename equality alone proves restoration of the historical original bytes. If stronger historical-byte identity is desired, Help may point to the separately governed explicit fingerprint/LCK direction rather than silently hashing ordinary Store artifacts. F-20 selector/name/width acceptance: fixtures must additionally prove that HEADER resolves only against exact decoded source-header text and never against an operational fallback/default alias; a KEEP selecting all 16,384 columns is valid; a source wider than 16,384 refuses before data-row materialization; and RESET of an oversized-header COL restores the deterministic operational fallback rather than the exact oversized header as alias text. F-03 Store-health and REPAIR MAP acceptance set Target required: REPAIR MAP without exactly one current Store MAP target refuses. Historical target: a structurally valid but non-current historical Store MAP refuses for repair. Wrong profile: a WKO MAP supplied as the repair target refuses. DEGRADED repair: one or more broken COL bindings are removed while every valid binding and the exact RID identity are preserved. All COLs broken: repair refuses, publishes no successor MAP, and the Store remains DEGRADED . Malformed newest MAP: current-state resolution falls back to the greatest earlier structurally valid MAP in the same lineage and reports the malformed artifact. Missing COL in current valid MAP: no fallback occurs; the current MAP remains current and the Store evaluates DEGRADED . Missing RID in current valid MAP: no fallback occurs; the current MAP remains current and the Store evaluates INVALID . Original RID externally restored: the Store is re-evaluated after governed validation without Data Sculptor creating or inferring a replacement RID. No silent fork: neither DEGRADED nor INVALID permits ordinary materialization to create a replacement Store for the same routed lineage.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-003,Suitcase-relative Work Order portability acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must execute a saved WKO containing SUITCASE: . and ordinary Suitcase-relative file references, then move the intact fixture Suitcase to a different permitted parent path and execute the same saved WKO again. Resolution must identify the same logical Suitcase files without editing the WKO to insert the new absolute machine path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-004,WIP/WKO lifecycle acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"Acceptance evidence must show that an editable WIP cannot Run; saving a valid WIP produces a distinct immutable WKO Run target; loading that WKO and changing instruction text creates a new non-runnable WIP; and the original WKO bytes, filename, identity, and provenance remain unchanged. F-02 alias-registry lifecycle acceptance: a first save for an unused alias must publish a successor WKO MAP containing exactly one CURRENT row for that alias. Saving a second valid WKO with the same exact alias must surface exactly Replace alias target and Cancel . The Cancel fixture must leave the predecessor WKO MAP authoritative and must not commit the pending WKO/WKO-MAP pair as a registry update. The Replace fixture must publish a successor WKO MAP in which the former owner is DEPRECATED , the new WKO is the sole CURRENT row for that alias, and any earlier deprecated history remains preserved. The former WKO bytes and filename and every predecessor WKO MAP must remain unchanged. Alias resolution against the successor registry must resolve to the new CURRENT row and never to a DEPRECATED row. A malformed fixture containing more than one CURRENT row for one exact alias must fail structural validation rather than choose by filename UTC, modified time, discovery order, or row order. P2-03 WKO-registry clock acceptance: using a deterministic injected clock seam, acceptance must prove that a successor WKO MAP publishes only when the observed transaction UTC is strictly greater than the current structurally valid WKO MAP UTC; equal-millisecond and backward/future-dated-predecessor cases refuse without committing the new WKO/registry state. The diagnostic must expose predecessor_map_filename , predecessor_utc , and observed_host_utc . A separate fixture must deliberately move the future-dated current WKO MAP out of the active Suitcase, rescan, and prove deterministic reselection of the remaining current structurally valid WKO MAP without Data Sculptor silently moving or deleting anything itself. Day 060 H-12: every equal/backward/future-predecessor chronology refusal in this acceptance set must emit DS-UTC-001 with exact map_profile: WKO , observed_host_utc , predecessor_map_filename , and predecessor_utc facts. F-23 save-transaction filesystem-fault fixture, reconciled by F-33: using a controlled create/write/close/rename/promotion failure at a deterministic point after a valid WIP has entered the governed save path, acceptance must prove that a failed WKO/WKO-MAP save is never represented as a committed alias-registry update. The pre-run current WKO MAP must remain authoritative; no malformed or unpromoted candidate may become current; and any rollback or retained SCR evidence must follow W002-STOR-018.3 and the shared non-Store publication/retained-evidence contract. No RCV artifact is emitted. F-02 registry-repair acceptance set Deadlock escape: with a repair-required current WKO MAP, a newly saved structurally valid repair-only WKO can Run by exact filename and successfully publish a repaired successor registry. No broad bypass: a newly saved unregistered WKO for any other operation remains ineligible to Run. Missing reference: repair removes a stale registry row but does not recreate the missing WKO, substitute a historical WKO, or promote an older WKO automatically. Discovered alias, no owner: one discovered valid WKO with an otherwise unowned alias becomes CURRENT . Discovered alias collision: a discovered WKO whose alias is already owned by a surviving CURRENT row becomes DEPRECATED . Several discovered WKOs, no owner: all become DEPRECATED ; no winner is inferred by UTC, filename, UUID, directory order, discovery order, or modified time. Mandatory alias: an unaliased WKO cannot be structurally valid. Line endings: otherwise-identical structurally valid WKO fixtures with LF and CRLF line endings are accepted; the lone-CR form refuses. Deterministic successor: repaired successor rows serialize in ascending UTF-8 byte order of exact wko_filename . Historical Run: a registered DEPRECATED WKO can Run by exact physical filename but not by alias. Receipt identity: a successful or refused registry-repair Receipt uses REPAIR_WORK_ORDER_REGISTRY as the operation token. Day 060 H-10 / BM-07 registry-repair Receipt-count acceptance Acceptance must include a successful repair-required-registry fixture in which the exact repair-only bootstrap WKO is initially visible and unregistered, runs by the bounded exact-filename bootstrap, and is then registered by the repair result. The committed successor WKO MAP must contain the repair WKO row. The successful Receipt must list that exact repair WKO under either REGISTERED_CURRENT_WKO_<INDEX>_FILENAME or REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME , according to the ordinary alias-ownership rule. The corresponding REGISTERED_*_COUNT must equal the number of newly registered rows in that status class, including the repair WKO when applicable. Pre-existing surviving CURRENT / DEPRECATED rows in the base registry must not inflate either registered count. A fixture containing both pre-existing surviving rows and newly registered rows must prove that the Receipt reports the repair change set while the successor MAP reports the complete resulting registry state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-005,"Store MAP inheritance, historical override, and immutable snapshot acceptance",W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must execute a saved Store-establishing Work Order containing multiple COL alias assignments when no routable Store lineage exists and no structurally malformed Store-MAP-class artifact is present , and prove that exactly one new immutable complete Store MAP is created while the GUI supplies no alias-edit gesture and target artifacts remain unchanged. A later Work Order with the same exact source and no explicit MAP must route to that Store's lineage and inherit its unique newest permitted MAP automatically. Another Work Order must explicitly select an older valid MAP even though newer MAPs for that Store exist and prove that Store/RID binding, alias resolution, and inheritance use exactly the named historical MAP instead. A fixture specifying more than one MAP must refuse. A fixture with two otherwise permitted current MAP candidates for the selected Store sharing the greatest UTC millisecond timestamp must refuse automatic inheritance rather than use UUID as chronology. A separate fixture must remove or corrupt every Store MAP in a prior lineage so that no structurally valid Store MAP remains while at least one malformed Store-MAP-class artifact remains visible in the active Suitcase. Re-running ordinary materialization must refuse before creating a new RID or first Store MAP, and Help must identify the malformed MAP artifact or artifacts. P2-03 Store chronology acceptance: injected-clock fixtures must prove later observed UTC success, equal-millisecond refusal, backward-UTC refusal, and a genuinely future-dated current Store MAP that remains current while blocking successor publication. Every refusal must leave the chronology predecessor unchanged and publish no successor Store MAP. A historical-base fixture must derive requested state from an older eligible MAP while proving that the strict-greater-than comparison uses the actual current Store MAP as chronology predecessor, not the historical base. A deliberate analyst-removal fixture must move the future-dated current MAP out of the active Suitcase and prove deterministic reselection of the remaining structurally valid history; restoring that MAP must make ordinary greatest-UTC authority rules applicable again. Day 060 H-12: every equal/backward/future-predecessor Store-MAP chronology refusal in this acceptance set must emit DS-UTC-001 with exact map_profile: STORE , observed_host_utc , predecessor_map_filename , and predecessor_utc facts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-WKO-ACC-006,Work Order chaining refusal acceptance,W002-WKO-ACC,W002-WKO,WASM-002,UNDER REVIEW,—,"An acceptance fixture must submit a structurally saved WKO containing a RUN or other recognized Work Order-invocation construct and prove that WASM-002 refuses it during validation before Stage 1, Stage 2, conversion, inventory, or other governed execution begins. The diagnostic/Help output must identify composition as deferred functionality. A separate multi-column MATERIALIZE fixture must still succeed, proving that multiple selected columns inside one Work Order are not misclassified as Work Order chaining.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-001,One explicit Work Order command surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser front end shall use the Work Order editor as the single human command-entry surface for governed execution. It shall not expose a second interactive command prompt or point-and-click analytical path that can become an independent source of analytical intent. The editable draft may be syntax-highlighted, validated, and saved, but it is not itself executable authority. The browser Run action operates only on one loaded/selected saved immutable WKO that is eligible under the governed Work Order registry rules. Run is a browser action, not a line that ordinary WASM-002 Work Orders must contain. If a WKO contains the reserved DS-STEPS RUN composition token, WASM-002 refuses before executing any child or top-level analytical operation because saved-Work-Order chaining is deferred. The token remains reserved so later ordered composition can be added without repurposing existing syntax. F-24 fresh-application state: each new Data Sculptor browser application instance begins without a selected Suitcase and without a restored unsaved Work Order draft. Initial page load and full reload therefore return the command surface to the pre-Suitcase gate. A previously selected folder, loaded WKO, or dirty WIP must not be silently reconstructed from browser-private persistence.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-002,Front end presents and authorizes; shared Rust core decides,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser front end may authorize files, edit and validate Work Orders, invoke the shared engine, display governed state, render diagnostics, and present generated artifacts. It must not independently decide analytical truth, silently reinterpret a Work Order, or implement a competing semantic path. Where front-end presentation and shared-core semantics disagree, the shared governed semantics and frozen requirements are authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-003,Visible Suitcase and governed run context,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser surface shall make the currently validated Suitcase visible and shall expose the visible files in that folder. Source and requested-column context become governed execution state only when a saved Work Order resolves them; the UI must not imply that directory presence alone means a source has been selected, scanned, certified, or materialized.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-004,Certification gate is visible and blocking,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The front end shall visibly represent strict whole-file UTF-8 certification as a required stage before analytical materialization. A certification refusal must stop the current analytical Work Order, prevent later materialization stages from being presented as successful, and provide the canonical diagnostic / Help path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-005,One-pass multi-column materialization is represented truthfully,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"When a valid Work Order requests multiple source columns, the front end shall represent them as one governed multi-column materialization request through one bounded structural CSV pass, not as unrelated per-column scans when the frozen engine contract performs one pass. Requested columns must be validated before data-row materialization begins, consistent with the materialization requirements.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-006,Visible Suitcase Directory is the artifact orientation surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"After Suitcase validation, the browser shall present a human-readable directory view of the visible files in the selected Suitcase, including physical filename, read-only governed alias where applicable, file type, and size. Governed artifacts created by a run shall appear in that same visible inventory after refresh or update. The directory is an orientation and metadata surface over the real flat Suitcase. It is not a hidden browser cache, a second persistence system, or an analytical command surface. CAT integration: this existing directory remains the sole WASM-002 artifact-orientation surface. CAT and MAP artifacts are first-ranked under W002-CAT-UI-001 through W002-CAT-UI-008; no second catalog browser is introduced.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-007,All user-facing Help flows through the Help Engine,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"All Data Sculptor-controlled user-facing Help messages, warnings, refusals, explanations, validation guidance, safe-next-action messages, and governed success/status messages that participate in the Help/status/evidence system shall be produced through the Help Engine from governed facts or canonical diagnostic events. Individual UI controls must not maintain an independent competing stock of semantic Help text. Governed success/status events in this system use canonical INFO diagnostics. Ordinary static labels, headings, decorative copy, and presentation-only UI text are not diagnostics and need not be routed through the diagnostic registry merely because they are visible. Help voice may change wording and depth but must not change diagnostic identity, evidence, severity, refusal/continue behavior, provenance, or safe next action. Durable Help Reports derive from the same governed truth. F-17 fallback behavior: when a complete registered diagnostic lacks an authored help_messages.json entry, the UI must show the deterministic Generic Technical Help rendering from W002-HELP-002.9 for Casual, Office Speak, and Technical selections rather than a blank state, guessed prose, or UI-local explanation. When diagnostic assembly itself fails its required-fact contract, the UI presents DS-HLP-001 ; it must not display the incomplete intended diagnostic as if valid.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-008,Legacy encoding conversion remains a separate operation,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"If UTF-8 certification fails and the bytes are eligible for the separately governed Windows-1252 compatibility/conversion path, the front end may explain or help draft that separate conversion Work Order. It must not silently reinterpret the failed analytical Work Order as Windows-1252 and continue materialization. P3-08 front-end disclosure: after a successful conversion, the visible result/Help path must identify the exact published CVT filename and explain that it is a new source identity for later Store routing. When that CVT is subsequently chosen for first materialization, the front end must not present the action as a refresh of an earlier conversion-derived Store merely because the analyst-owned input filename is the same; it must preserve the governed Help disclosure that each distinct CVT is a distinct source artifact and lineage input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-009,Front-end branding is presentation-only,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser front end shall use the canonical built-in Red5Sorcery/Data Sculptor branding and approved presentation tokens without changing analytical or diagnostic meaning. The current Red5Sorcery identity treatment, including the red “5”, remains the active WASM-002 design direction. Configurable Brand Manifest loading, validation, selection, and substitution are deferred to V1-BACKLOG / a future build whose number is not yet assigned.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-010,WASM-002 front end must not preview deferred analytical features as available controls,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 front end shall stop at the capabilities allocated to the WASM-002 build slice. It shall not present filtering, grouping, sorting, Quick Viz, PRETTY Tables, DS-VERIFY, or later filter-driven build/export workflows as executable WASM-002 controls unless their individual requirement SCOPE is deliberately changed and frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-PLAT-001,WASM-002/V1 browser and modest-hardware acceptance baseline,W002-PLAT,W002-PLAT,WASM-002,UNDER REVIEW,—,"The canonical modest-hardware acceptance machine for the WASM-002 browser release and the browser path carried into V1 is the project's 11-inch Windows 11 laptop with an Intel N100 processor, 16 GB RAM, and a 1920×1200 native display. Each acceptance record must capture the exact tested Windows build, browser version, Windows display scaling, browser zoom, and materially relevant machine configuration. Those observed version and presentation settings are acceptance evidence; they do not become timeless minimum-version requirements unless separately frozen. V1 browser support is scoped to certified desktop Chromium hosts that expose the user-selected writable-directory and file-publication capabilities required by the visible Suitcase contract. Microsoft Edge is the primary certified browser. Google Chrome is the secondary certified browser. Another Chromium-derived browser may work, but Data Sculptor must not claim it as a certified V1 browser until that browser has passed the applicable acceptance suite. Firefox and Safari are not supported V1 browser hosts under this contract and their lack of the required filesystem capability must not block V1 release. Supported-host acceptance must exercise the real browser filesystem path: explicit user-selected Suitcase access, CER validation, governed Work Order save/Run behavior, and governed artifact publication. Data Sculptor must not substitute OPFS, IndexedDB, download-only publication, a browser extension, or another hidden/different persistence model merely to make an unsupported browser appear supported. Required filesystem capability is feature-detected before folder validation begins. If the host cannot expose the governed writable-directory contract, Data Sculptor must treat that state as a host-capability refusal , keep governed save/Run/analytical controls locked, and route the explanation through the canonical diagnostic/Help path. It must not claim that a particular user folder failed validation when no folder could actually be tested.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-011,"Keyboard-operable, small-screen browser shell",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The required WASM-002 front-end interactions shall remain operable from a keyboard and usable on the canonical modest-hardware/small-screen baseline defined by W002-PLAT-001. At the display scaling and browser zoom recorded for acceptance, every required control and governed surface needed to complete the supported workflow must remain reachable without changing those settings merely to reveal an otherwise inaccessible control. Responsive reflow and ordinary scrolling are permitted; this requirement does not demand that every panel be visible simultaneously. Visible labels must carry meaning without relying on color alone. Exact shortcut assignments are presentation details unless separately frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-012,"Reference prototype is evidence, not a shadow specification",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Day 043 HTML prototype embedded below is retained as concrete design evidence for the WASM-002 browser workbench. Its layout, simulated analytical execution, illustrative Work Order grammar, current aliases, demo shortcuts, artifact examples, and other unfrozen literals do not become normative merely because they appear in the prototype. If the embedded prototype conflicts with a numbered requirement, the numbered requirement governs and the prototype must be revised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-013,Dedicated persistent Help / Diagnostic Surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The primary WASM-002 workspace must reserve a dedicated Help / Diagnostic Surface with stable layout presence. When a governed diagnostic is active, the analyst must be able to view its explanation without losing sight of the Work Order and the execution/source context required to understand it. The persistent surface is a viewport into canonical diagnostic truth; it is not a second state authority.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-014,Governed analytical refusals are not modal- or toast-only interactions,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,An application-controlled modal dialog must not be the primary presentation of a governed analytical refusal when it would obscure the Work Order or execution context. A transient toast or timed notification must not be the sole carrier of governed diagnostic truth. Browser- or operating-system-controlled permission/security dialogs are outside this requirement because Data Sculptor does not control their presentation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-015,Idle Help state remains semantically quiet,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"When no canonical diagnostic is active, the Help / Diagnostic Surface should communicate only restrained readiness/idle state rather than becoming a general dashboard for unrelated metrics, checkpoints, or project status. Exact wording such as “No active diagnostic. Ready.” is presentation detail unless separately frozen.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-016,Help surface exposes a direct saved-report action,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"From an active governed diagnostic, including a non-run diagnostic, or from one governed Run whose diagnostic history is available to the Help surface, the browser Help / Diagnostic Surface must provide an explicit action to generate the durable HTML Help Report. Each explicit report request publishes exactly one HLP under W002-HELP-003.2 and W002-HELP-009. The generated report must become a visible Suitcase artifact governed by the Help, PRETTY, persistence, and provenance requirements and must use the canonical built-in Data Sculptor presentation.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-017,Writable Suitcase validation is the first interaction gate,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Before Data Sculptor enables Work Order saving, governed Run, or analytical processing, the analyst must choose one Suitcase folder and Data Sculptor must validate that folder by successfully creating, completely writing, and closing one governed HTML Suitcase Validation Certificate under W002-STOR-022 through W002-STOR-022.3. Permission state or directory enumeration alone is not sufficient to pass the gate. The successful certificate remains visibly in the Suitcase as durable evidence. Validation does not require deleting or renaming the certificate. Until the certificate write/close succeeds, the analytical workspace remains locked except for Help and Suitcase selection. Browser- or operating-system-controlled refusal of protected directories is outside Data Sculptor presentation control and must be explained through the Help Engine when the host can observe the refusal. F-24 opening/selection lifecycle: merely loading Data Sculptor does not create a CER. A CER is published only after an explicit Suitcase selection successfully passes the governed validation gate. Reselecting and successfully validating the same physical Suitcase is a new certification event and publishes one new CER; all earlier CERs remain untouched. Data Sculptor does not remember the directory handle between application instances, so a new load/reload requires explicit Suitcase selection again before the workspace can unlock.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-018,Suitcase Directory enumerates visible files before analytical work,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Immediately after Suitcase validation, Data Sculptor shall enumerate the visible files available through the authorized directory handle and show them in the Suitcase Directory. No source, header, column, certification, or materialization state shall be inferred merely from the existence of those files.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-019,Directory inventory and displayed aliases must not become point-and-click analytical intent,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Suitcase Directory may expose file inventory and read-only human-facing metadata such as aliases, but it shall not provide alias-edit controls, “Use as source,” column-pick, materialize, filter, or equivalent governed-action controls. Source files, requested columns, alias mutations, and analytical operations are stated in saved Work Orders and resolved by the governed engine.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-020,Saved Work Orders are the only Run targets,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The Work Order editor may create a new draft or load a saved Work Order TXT artifact from the validated Suitcase. A loaded saved Work Order is an immutable Run target and may be inspected or run directly. If the analyst changes its instruction text, the editor must transition to a new draft derived from that saved Work Order; the draft is not runnable until it is saved as a new immutable Work Order with a new governed physical identity. The original saved Work Order remains unchanged.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-021,User chooses the Suitcase; Data Sculptor chooses generated filenames,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"For Work Orders, materialized columns, Help Reports, receipts, maps, and other Data Sculptor-generated artifacts, the analyst chooses or has already chosen the validated Suitcase folder. The browser shall not require the analyst to supply an output filename for those governed artifacts.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-022,"Execution Output is read-only observation, never command input",W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser shall provide a read-only Execution Output surface that reports which saved Work Order was run, how its source and governed aliases resolved, which execution stages occurred, what was refused, and which governed artifacts were created or assigned. For WASM-002 it does not display a nested Work Order invocation chain because Work Order composition is deferred. The surface shall not accept commands, analytical text, or cursor-driven execution input.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-023,The browser has no separate Work Order Description field,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The browser must not expose a standalone editable Description field for a saved or draft Work Order. Human-facing Work Order naming is authored in DS-STEPS with the required WORK ORDER AS ""..."" clause inside the Work Order itself. The Saved Work Order chooser and Suitcase Directory may display governed WKO alias/lifecycle information from the current structurally valid WKO MAP . Where lifecycle information is shown, CURRENT and DEPRECATED are read-only governed registry state, and the exact physical WKO filename must remain available/visible so human meaning, lifecycle authority, and physical identity remain distinct. Alias resolution uses the sole CURRENT row for the exact alias; a DEPRECATED row is historical evidence rather than the alias target. If that current registry references a missing physical WKO, the MAP remains current and the registry is repair-required; the browser must not silently display an older WKO MAP as though it had become current merely because of the missing reference. A structurally malformed newer WKO MAP never becomes current and is reported through Help/evidence surfaces. Editing a loaded saved WKO—including changing its alias or comments—creates a derived draft that must be saved as a new immutable WKO before it can Run. If that save would supersede the existing CURRENT target for the same alias, the save flow follows the exact Replace alias target / Cancel decision in W002-STOR-018.3; the UI must not provide a separate direct registry-edit gesture.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-024,Suitcase Directory aliases are read-only views of governed MAP profiles,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"Alias displays in the Suitcase Directory are observation-only. Store, RID, and materialized-COL aliases are read from eligible Store MAP state. Saved Work Order alias and lifecycle state are read from the current structurally valid WKO MAP. The browser may aggregate those governed sources into one human-facing directory view while keeping exact physical filenames available for inspection. For WKO rows, CURRENT / DEPRECATED is read-only governed lifecycle metadata. A CURRENT row identifies the registry target for that exact alias; a DEPRECATED row remains historical registry evidence and must not be presented as the current alias target. The GUI must not expose an input, inline editor, context action, or other non-Work-Order path that directly mutates governed aliases or WKO lifecycle status. Store/RID/COL alias mutation remains Work-Order-governed. WKO aliases are authored inside immutable WKO text with WORK ORDER AS and enter or change WKO alias-registry authority only through a successful governed save transaction under W002-STOR-018.3.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-025,The browser has exactly two governed built-in presentation themes,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser presentation contract exposes exactly two governed theme choices: Modern Dark and Modern Light . Custom presentation is deferred to V1-BACKLOG / a future build not yet numbered. A Terminal theme is not part of the WASM-002/V1 browser contract and must not be exposed as a governed theme choice. Theme selection is presentation-only. It must not change Work Order semantics, source resolution, diagnostic identity or facts, continue/refuse decisions, analytical values, Receipt truth, or other governed execution meaning. The selected browser theme does not control durable HLP or CER presentation in WASM-002. Those governed HTML artifacts use the canonical built-in Red5Sorcery/Data Sculptor presentation regardless of whether the live browser is using Modern Dark or Modern Light. F-24 session default and persistence: Modern Dark is the canonical theme at the start of every new browser application instance. The analyst may switch to Modern Light during that instance, but WASM-002 retains the choice only in volatile runtime state and does not persist it in browser-private storage. A new application instance therefore returns to Modern Dark.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-026,Flight Recorder is a read-only derived Receipt-history surface,W002-UI,W002-UI,WASM-002,UNDER REVIEW,—,"The WASM-002 browser may present a Flight Recorder surface that is derived exclusively from governed RCP Receipt artifacts currently visible in the authorized Suitcase. The surface is read-only and regenerable. It must not create or maintain a second execution-history database, mutable log, hidden cache, browser-private history, or alternate chronology authority. The Flight Recorder may sort, filter, group, or summarize Receipt-derived facts for human orientation, but those presentation operations must not alter Receipt bytes, invent missing events, or become authoritative over the underlying immutable Receipts. Where no canonical Receipt exists because Receipt publication failed, the surface must not reconstruct a substitute original Receipt from UI state, console text, or memory.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-001,Single-command-surface and saved-run-target acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The acceptance check must show one Work Order editor that can hold either a new draft or a loaded saved Work Order and no second independent prompt, command-entry cursor, point-and-click source selector, or point-and-click column selector. A governed browser Run must read exactly one loaded/selected saved immutable WKO artifact that is eligible under the current registry rules. An unsaved WIP must not Run. Editing the instruction text of a loaded saved WKO must transition the editor to a new draft state that cannot Run until saved as a new immutable WKO. A fixture containing the exact reserved semantic token RUN as a Work Order composition construct must refuse before any governed operation executes and must reach the deferred-composition Help path. A near-synonym such as CALL , EXEC , or INCLUDE must not be silently accepted as composition syntax.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-002,Certification-refusal gating acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a source fixture that fails strict UTF-8 certification, the browser must show certification failure, leave later analytical stages unaccepted, produce no materialized analytical outputs, preserve the source unchanged, and expose the canonical Help path. The retained event/Receipt evidence must agree on STAGE1_UTF8_OUTCOME: FAIL , exact UTF8_FIRST_INVALID_BYTE_OFFSET , and UTF8_STOP_REASON: INVALID_UTF8_SEQUENCE . The canonical diagnostic event must expose the same meaning through lower-case facts first_invalid_byte_offset , source_filename , and stop_reason .",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-003,Multi-column path acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a valid UTF-8 source and a Work Order requesting at least two source columns, the browser must show successful certification followed by one governed structural materialization pass and then expose the resulting visible Suitcase artifacts required by the build contract.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-004,Diagnostic/Help parity acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"For at least one real WASM-002 refusal path, the live message, each supported Help voice, and the durable HTML Help report must resolve from the same canonical diagnostic event and preserve the governed facts, severity, provenance, refusal behavior, and safe next action.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-005,Visible-persistence and Suitcase-directory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"A completed governed browser run must be auditable from the visible Suitcase artifacts required by the build contract, and newly created governed artifacts must become visible through the Suitcase Directory. Acceptance evidence must show that Data Sculptor did not intentionally persist project or analytical state in browser-private storage as a substitute for those artifacts. F-24 session/CER lifecycle acceptance: acceptance must begin from a clean application instance and prove all of the following in one controlled sequence: no Suitcase is selected or silently recovered; Work Order saving and governed Run remain gated; the live browser defaults to Modern Dark and Technical Help; explicitly selecting and successfully validating a writable Suitcase publishes exactly one fresh CER and unlocks the workspace; after switching to Modern Light and a non-Technical Help voice and creating a dirty unsaved WIP, an ordinary reload/navigation path triggers the browser-supported unsaved-change warning where the host permits it; after proceeding with reload, the Suitcase handle, non-default theme, non-default Help voice, and dirty WIP are not restored from Data Sculptor-controlled browser-private persistence; reselecting and successfully validating the same Suitcase publishes a second distinct CER while the first CER remains present under its original governed filename and exact bytes; and no automatic CER-history ZIP, compaction, replacement, or deletion occurs. The acceptance record must inspect the relevant Data Sculptor-controlled browser persistence surfaces and show that no persisted project/session record was used to restore the Suitcase handle, WIP, theme, or Help voice. WASM-002 does not claim dirty-draft warning or recovery after browser crash, forced process termination, operating-system failure, or power loss.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-006,Scope-surface acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The frozen WASM-002 browser build must not expose executable controls for requirements whose current SCOPE remains V1-BACKLOG, POST-V1, OUT-WASM-002, or otherwise outside the frozen WASM-002 build slice.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-007,"Small-screen, keyboard, and certified-browser acceptance",W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"On the canonical Intel N100 / 16 GB Windows 11 laptop and its 1920×1200 display, acceptance must record the Windows build, display scaling, browser zoom, and exact browser version. In the primary certified Microsoft Edge host, the required browser controls, Work Order editor, governed-stage status, artifact/result surface, and diagnostic/Help surface must remain reachable and usable without requiring an IDE or developer tools, and the required interaction path must be completable by keyboard. Ordinary scrolling and responsive reflow are allowed; changing scaling or zoom merely to expose an otherwise unreachable required control is not. The same canonical machine must also exercise the supported-host Suitcase → CER → Work Order save/Run → governed publication path in the secondary certified Google Chrome host. Chrome must satisfy the same governed filesystem and semantic contract; browser-specific presentation differences do not permit different analytical meaning or a different persistence model.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-008,Persistent diagnostic co-presence acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,Triggering a real governed refusal must leave the Work Order and relevant execution/source context available while the diagnostic is visible in the dedicated Help surface. The refusal must not depend on an application-controlled modal dialog or transient toast as its sole presentation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-009,Idle-state discipline acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"With no active diagnostic, the dedicated Help surface must remain present but semantically quiet and must not aggregate unrelated project/dashboard state as a substitute for its diagnostic purpose.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-010,Saved-report action acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"From a displayed real diagnostic event, including a governed non-run diagnostic, the user must be able to invoke the Help-report action and obtain the corresponding durable HTML Help Report as one visible governed artifact without manually copying diagnostic text or reconstructing the event. A governed Run fixture containing multiple diagnostic events must also permit one explicit Run-level Help Report request and must produce exactly one HLP for that request. The HLP must identify the included diagnostics in deterministic event order and must not create one HLP automatically for each diagnostic.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-011,Suitcase-first gate and supported-host capability acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"With no Suitcase validated, Work Order saving, governed Run, and analytical processing controls must be unavailable. Acceptance first proves supported-host capability under W002-PLAT-001. Microsoft Edge and Google Chrome acceptance must each expose the required user-selected writable-directory path; Data Sculptor must not satisfy this gate through OPFS, IndexedDB, download-only output, a browser extension, or another substitute persistence model. Acceptance must enumerate every governed final-artifact filename form and SCR staging form that WASM-002 can emit, derive the longest canonical filename length, and verify that the current contract yields 73 ASCII bytes/characters . The canonical __DS__CER__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html form is one of the forms at that maximum and is used for the actual create/write/close folder-validation test. After the analyst selects a writable test folder on a supported host, Data Sculptor must create one retained governed certificate whose filename matches that canonical CER form, completely write and close it, and expose it in the visible Suitcase Directory. The certificate must contain the semantic fields and limitation statements required by W002-STOR-022.2. Only after that certificate operation succeeds may the workspace unlock. A failure to create, completely write, or close the certificate after actual folder selection must leave the workspace locked and surface the canonical diagnostic/Help path. Separately, a deterministic missing-capability acceptance fixture must prove that a host lacking the required writable-directory contract refuses before folder validation, leaves the workspace locked, and does not mislabel an untested folder as unwritable. Acceptance must not depend on a hard-coded operating-system path-length number, deletion of the certificate, or a validation-only rename. If the emitted-name inventory changes so that another form exceeds the CER maximum, this acceptance gate must fail until the new maximum is explicitly exercised.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-012,Directory-is-inventory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"After Suitcase validation, the visible directory must list a mixed fixture set including at least one CSV and one non-CSV file with their physical names, types, and sizes. The directory must expose no “Use as source,” column-pick, or materialize action that bypasses the Work Order.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-013,Generated Work Order identity and immutability acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,Saving a valid draft must create a new TXT artifact whose physical name matches the frozen Work Order filename contract and must not open a filename-entry Save As path. Editing the draft and saving again must create a different Work Order identity; the first saved TXT bytes and filename must remain unchanged.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-014,Work-Order-only source and column selection acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Using a Suitcase containing multiple candidate files and a CSV with multiple headers, the analyst must be able to request the source and materialized column solely through a saved Work Order. Acceptance must show that the browser performs no separate point-and-click source or column selection. F-26 SOURCE eligibility fixtures: the acceptance set must prove all of the following under W002-WKO-009.1: analyst-owned root files ending .csv , .CSV , and a mixed-case equivalent are recognized as CSV candidates; the complete physical filename reference remains exact and case-sensitive under F-15; an analyst-created __DS__notes.csv is refused as an analyst-owned SOURCE; a valid published CVT is accepted; a canonical-looking or renamed file that does not satisfy the governed CVT validity/publication contract is refused; governed non-CVT classes including COL are refused as SOURCE; a non-CSV analyst-owned extension is refused even if its bytes are CSV-like; and path, traversal, subdirectory, URL/URI, and external-file references are refused.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-015,Read-only Execution Output acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The execution surface must display the selected saved Work Order, source resolution, relevant stage/refusal facts, and resulting artifact identity while accepting no command input. Keyboard focus in the execution surface must not create a second execution path.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-016,Store-MAP snapshot persistence and read-only directory acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Creating or changing governed alias/Store metadata through a saved Work Order must create one new immutable complete Store MAP in the same flat Suitcase while preserving earlier MAPs and leaving target artifact bytes and physical filenames unchanged. After a governed run that creates a new Store MAP, refreshing/reopening the Suitcase may display Store, RID, and COL aliases from the exact Store lineage and Store MAP resolved for that specific governed operation. The directory must not infer a global “current Store,” guess from unrelated newest MAP timestamps, or independently choose or mutate Store/MAP authority for execution.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-017,"Store-aware MAP selection, historical override, and anti-rebinding acceptance",W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"A saved materializing Work Order that does not explicitly name a MAP must use exact SOURCE matching against the one common source_filename carried by each routable Store lineage's Store MAP. A routable Store lineage is one with at least one structurally valid Store MAP, regardless of later Store-health state. A fixture with exactly one routable Store lineage must route to that lineage and, when its health permits materialization, inherit the Store's unique newest permitted MAP and record both the MAP identity and bound rid_filename in execution evidence. A fixture with no routable Store lineage and no structurally malformed Store-MAP-class artifact present may establish a new Store. A fixture with more than one routable Store lineage for the same source must refuse automatic selection. An explicit-MAP fixture must prove that SOURCE must exactly equal the selected MAP's common source_filename . A different source must refuse before materialization even when source/RID row counts happen to match. A separate all-MAPs-damaged fixture must leave one or more structurally malformed Store-MAP-class artifacts visible while no routable lineage can be established. The UI/run path must refuse before new-Store/RID creation and expose Help that identifies the malformed MAP artifact or artifacts; it must not present the condition as an unseen source. Another fixture must prove that explicitly naming an older valid MAP overrides the newer default for that same Store. More than one explicitly named MAP must refuse. An equal-greatest-timestamp ambiguity within the selected Store lineage must refuse automatic selection. Once an inherited Store MAP has been selected for a run, creation of a newer MAP during execution must not silently rebind that in-progress run. P2-03 authority/clock acceptance: the UI/evidence path must distinguish the selected operation base MAP from the chronology predecessor used for successor UTC validation. When a future-dated current MAP blocks publication, the UI must not label that MAP corrupt merely because of its timestamp, must identify it as the blocking current authority, and must route to Help describing the clock correction/wait/deliberate-removal choices without performing any automatic fallback or filesystem move.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-018,Help-Engine-only messaging acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"For representative Suitcase validation, Work Order validation, source-resolution, and analytical refusal cases, user-facing guidance must be traceable to the Help Engine/canonical diagnostic path. Acceptance must show no competing ad hoc semantic refusal text generated independently by individual analytical controls.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-019,No standalone Work Order Description acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Acceptance must prove the architecture that WASM-002 permits: the browser exposes no standalone editable Work Order Description field; no separate mutable or hidden Work Order-description store exists; editing any governed WKO byte transitions a loaded saved WKO into a derived draft; the predecessor WKO TXT bytes, physical filename, and UUID remain unchanged; and the derived draft cannot Run until saved as a new WKO identity.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-020,Theme semantic-invariance acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"The same saved Work Order and governed diagnostic fixture must be exercised under Modern Dark and Modern Light. Acceptance evidence must show identical Work Order resolution, diagnostic ID and structured facts, continue/refuse decision, and analytical result/provenance across both themes, with only governed live-browser presentation differences. The browser must expose no Custom or Terminal governed theme choice in WASM-002. Acceptance must also verify that switching between Modern Dark and Modern Light does not change the canonical built-in presentation of a generated HLP or CER.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-UI-ACC-021,Flight Recorder read-only derivation acceptance,W002-UI-ACC,W002-UI,WASM-002,UNDER REVIEW,—,"Acceptance must populate the Suitcase with governed RCP artifacts for at least one successful Run and one refused Run whose Receipt publication succeeded, then reconstruct the Flight Recorder surface solely from those Receipts. The rendered history must preserve each Receipt's governed execution outcome and lineage while allowing only read-only presentation operations. A separate fixture must represent a Run for which Receipt publication failed under W002-RCP-010 and prove that the Flight Recorder does not invent, backfill, or reconstruct a canonical Receipt from transient execution state. User interaction with the Flight Recorder must not modify, delete, rename, rewrite, supersede, or create RCP artifacts and must not create hidden persistent history state.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-001,Certification interprets nothing analytically,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The certification stage establishes source-encoding validity and evidence; it does not perform analytical materialization.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-002,Materialization assumes nothing about encoding,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,Materialization proceeds only under the governed UTF-8-certified-source invariant and does not guess or silently change source encoding.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-003,Conversion is a separate transformation,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"Windows-1252-to-UTF-8 conversion is an explicit user-authorized operation producing a new artifact, not a hidden fallback.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-004,The fast path preserves strictness,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"ASCII-first acceleration is an optimization of strict UTF-8 certification, not a relaxation of validity rules. Every non-ASCII sequence remains subject to strict validation and EOF remains authoritative.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-005,Help is first-class,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The shared engine emits governed diagnostic truth; the Help Engine owns governed explanation.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-006,PRETTY is first-class,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The PRETTY Engine owns deterministic human-facing rendering.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-008,One shared semantic core,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The WASM-first implementation must remain suitable for later use by a standalone native CLI host without creating a permanent second semantic engine.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-011,Open source and commercial service are separate layers,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,The open-source analytical product and Red5Sorcery's optional paid automation must remain architecturally distinguishable. A paid service may save work; it must not become a hidden prerequisite for executing or understanding the delivered analytical software.,NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-014,WASM-002 and V1 analytical execution are sequential,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"WASM-002 must execute governed analytical operations sequentially and predictably. The product must not expose worker-count, thread-count, task-parallelism, or similar tuning controls, and it must not silently introduce a parallel analytical execution mode whose ordering or resource use changes the governed semantics. Sequential execution does not require inefficient repeated scans. One bounded structural source pass may process multiple requested columns together, and implementation may use ordinary low-level/runtime mechanisms that do not create user-visible analytical concurrency or change deterministic operation order. Any future analytical parallelism requires a separate measured experiment and explicit PRD decision.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)
W002-ARCH-014.1,WASM-002 has a single-writer Suitcase contract,W002-ARCH,W002-ARCH,WASM-002,UNDER REVIEW,—,"WASM-002 assumes one user, one active Suitcase, and one Data Sculptor writing execution context at a time . Multiple read-only views may observe the same Suitcase, but concurrent governed writers—including a second browser tab or window attempting governed writes against the same Suitcase—are outside the supported WASM-002 contract. WASM-002 does not implement cross-tab locks, filesystem leases, lockfiles, hidden coordination state, or multi-writer merge/rebase semantics. This is an explicit product boundary, not an implicit guarantee that concurrent writers are safe. Before a governed transaction reaches its authoritative commit point, Data Sculptor must re-resolve and revalidate the governing state on which the transaction depends. If relevant governed state has changed since the transaction established its basis, publication must refuse rather than overwrite the newer authority, silently rebase itself, synthesize another chronology, or report success. Candidates already created remain subject to the existing rollback and attributable SCR recovery-evidence rules. Help must explain the boundary in ordinary terms: do not run two writing Data Sculptor contexts against the same Suitcase at the same time. If a pre-commit guard detects changed authority, the safe next action is to refresh or reopen the current governed state and rerun deliberately. Acceptance evidence must inject a relevant Store-MAP and WKO-MAP authority change after transaction preparation but before commit and prove that the newer authority remains authoritative and the stale transaction refuses.",NOT_STARTED,NOT_TESTED,NOT_REVIEWED,NOT_ACCEPTED,,,,,,,Revision BM Day 060 H-31 (frozen WASM-002 scope)

ProjectDay,CommitSHA,ParentSHA,CommitTime,Subject,ChangedPathRecords,GrossBytes,EvidenceBytes,SourceBytes,TestsBytes,OtherBytes,NetBytes
063,6b373ff782b97b751d63d44449320f72d05ba339,,2026-10-10T14:49:59-03:00,WASM-002: establish verified Rust 1.97.1 baseline,5,560,0,210,0,350,560
063,01580a1873cc51a675a2c2b560d2500cf5cf909f,6b373ff782b97b751d63d44449320f72d05ba339,2026-10-10T14:53:13-03:00,WASM-002: establish cross-platform line-ending policy,1,108,0,0,0,108,108
063,03201870b8ec68730a0c027c572db03ccd5eeaa8,01580a1873cc51a675a2c2b560d2500cf5cf909f,2026-10-10T15:27:19-03:00,WASM-002 CP-001: locally verified namespace recognizer candidate,10,19130,6070,937,2006,10117,18920
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,03201870b8ec68730a0c027c572db03ccd5eeaa8,2026-10-12T18:55:44-03:00,WASM-002 CP-002: reserve Data Sculptor filename namespace,22,37817,33986,1175,2656,0,34874
065,2d06f6259de93f5beaa8eb15f8f22f171127a10e,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,2026-10-12T19:56:23-03:00,WASM-002 CP-003: classify governed artifact tokens,14,19801,15481,2486,1834,0,18626
065,12c02a0f2ff51fae72599adc09332f50fed62ce8,2d06f6259de93f5beaa8eb15f8f22f171127a10e,2026-10-12T20:22:47-03:00,WASM-002 CP-004: validate immutable filename envelope,15,28321,22349,4071,1901,0,25835
065,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,12c02a0f2ff51fae72599adc09332f50fed62ce8,2026-10-12T20:53:56-03:00,WASM-002 CP-005: validate Gregorian UTC timestamps,14,30466,23272,5176,2018,0,26395
065,aff54d08dcbacaa0c54d8869749344a504c5ad61,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,2026-10-12T21:20:03-03:00,WASM-002 CP-006: separate artifact class and serialization,14,31929,22784,6143,3002,0,26753
065,3c512df519f3a2431b363e4c57dc234c02378124,aff54d08dcbacaa0c54d8869749344a504c5ad61,2026-10-12T21:52:18-03:00,WASM-002 CP-007: construct canonical filenames without normalization,14,33565,23864,6829,2872,0,27422
066,346733a962192320e0d56271add15a47b6037b6b,3c512df519f3a2431b363e4c57dc234c02378124,2026-10-13T15:35:46-03:00,WASM-002 CP-008: screen analyst-owned CSV SOURCE filename candidates,18,33903,23931,7783,2189,0,27074
066,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,346733a962192320e0d56271add15a47b6037b6b,2026-10-13T16:05:03-03:00,WASM-002 CP-009: match exact CSV SOURCE names in root snapshots,15,35276,20794,10093,4389,0,27493
066,b7c515faa9bd000369d7656e09437310261290ae,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,2026-10-13T17:20:42-03:00,WASM-002 CP-010: recognize canonical governed CVT CSV filename candidates,28,75600,62839,10589,2172,0,65507
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,b7c515faa9bd000369d7656e09437310261290ae,2026-10-13T18:41:56-03:00,CP011: canonical CVT-to-SCR candidate identity,27,59139,45802,11016,2321,0,48550
066,efca04392940e398020a5c06b9ee50296c8a1fdd,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,2026-10-13T20:18:43-03:00,CP012: canonical SCR filename candidate recognition,28,66103,52586,11541,1976,0,55087
066,005a38ef5e876847c4c08901c18da9c18565fd6b,efca04392940e398020a5c06b9ee50296c8a1fdd,2026-10-13T22:01:42-03:00,CP013: explicit SCR-to-RCP filename candidate derivation,42,302051,287012,12312,2727,0,290510
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,005a38ef5e876847c4c08901c18da9c18565fd6b,2026-10-14T15:59:03-03:00,CP014: recognize canonical RCP filename candidates,34,54147,38599,12915,2633,0,41835
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,2026-10-14T22:34:18-03:00,CP015: verify canonical SCR-RCP filename pair identity,18,28110,11260,13602,3248,0,15195
068,1966da4beeb9726739aee3517d6e2b2eb30af397,be997dc0dbd65fc370814c4a5f2d0f1254870572,2026-10-15T16:38:44-03:00,chore: remove development log from Rust repository,1,0,0,0,0,0,-10117
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,1966da4beeb9726739aee3517d6e2b2eb30af397,2026-10-15T18:46:27-03:00,CP016: canonical Receipt field-line serialization and evidence,38,44935,24216,15525,5194,0,31333

ProjectDay,CommitSHA,ChangeStatus,Path,Category,OldBlobSHA,NewBlobSHA,OldBlobBytes,NewBlobBytes,GrossBytes,NetBytes
063,6b373ff782b97b751d63d44449320f72d05ba339,A,.gitignore,Other,,ea8c4bf7f35f6f77f75d92ad8ce8349f6e81ddba,0,8,8,8
063,6b373ff782b97b751d63d44449320f72d05ba339,A,Cargo.lock,Other,,b9643d7917e04ca36548b492bc1f7ccc26af9c14,0,162,162,162
063,6b373ff782b97b751d63d44449320f72d05ba339,A,Cargo.toml,Other,,21740dea770d0e5819624abe1ec911dff53810be,0,89,89,89
063,6b373ff782b97b751d63d44449320f72d05ba339,A,rust-toolchain.toml,Other,,24a305c5bc05d30509e7a7ce9f4762db61cffbfb,0,91,91,91
063,6b373ff782b97b751d63d44449320f72d05ba339,A,src/lib.rs,Source,,b93cf3ffd9cc9c59f584a92d7bd1459d5521ef4e,0,210,210,210
063,01580a1873cc51a675a2c2b560d2500cf5cf909f,A,.gitattributes,Other,,b38a50cffe91de544a19394058247f901ff1d7eb,0,108,108,108
063,03201870b8ec68730a0c027c572db03ccd5eeaa8,A,DataSculptor_WASM002_Development_Log.html,Other,,93850238eef288f9938432c274c581dd9df6d30f,0,10117,10117,10117
063,03201870b8ec68730a0c027c572db03ccd5eeaa8,A,Evidence/CP-001/CP001_GREEN2_Test_Output.txt,Evidence,,b1d8eb3a39cdcef868072f03b7cfaab857add22c,0,1188,1188,1188
063,03201870b8ec68730a0c027c572db03ccd5eeaa8,A,Evidence/CP-001/CP001_GREEN_Test_Output.txt,Evidence,,61e1f5377d959ed800e6eebd58b285955994f430,0,965,965,965
063,03201870b8ec68730a0c027c572db03ccd5eeaa8,A,Evidence/CP-001/CP001_Hash_Inventory.txt,Evidence,,971ec8d684cd73ec918e79d1e666c920273a9f4c,0,984,984,984
063,03201870b8ec68730a0c027c572db03ccd5eeaa8,A,Evidence/CP-001/CP001_Hash_Inventory_Verification.txt,Evidence,,9613849b9bedf7f3cd481582e4330047bf0c6ae2,0,422,422,422
063,03201870b8ec68730a0c027c572db03ccd5eeaa8,A,Evidence/CP-001/CP001_RED2_Test_Output.txt,Evidence,,40697b50798c303fa10e97536305b796b140158d,0,1530,1530,1530
063,03201870b8ec68730a0c027c572db03ccd5eeaa8,A,Evidence/CP-001/CP001_RED_Test_Output.txt,Evidence,,fe65d767360cc820d5cc24de30dfec80577d2640,0,592,592,592
063,03201870b8ec68730a0c027c572db03ccd5eeaa8,A,Evidence/CP-001/CP001_WASM_Build_Output.txt,Evidence,,f83e7fe4069381004f3502dd6a2da976ff25296f,0,389,389,389
063,03201870b8ec68730a0c027c572db03ccd5eeaa8,M,src/lib.rs,Source,b93cf3ffd9cc9c59f584a92d7bd1459d5521ef4e,136860d8f5cd1d5873c3425d501ba5179c1b5e1a,210,937,937,727
063,03201870b8ec68730a0c027c572db03ccd5eeaa8,A,tests/artifact_namespace.rs,Tests,,5ca77fb06c28a74e05ae58b494b1091a45fdd927,0,2006,2006,2006
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_Baseline_Cargo_Test_Output.txt,Evidence,,a2bda14bb5af4f3cb6947c874f45887e13c4e92b,0,2228,2228,2228
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_Day065_Repository_Inventory.txt,Evidence,,f3ea338530bf7965d6bad641be198214f8ef058c,0,3152,3152,3152
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_Day065_Source_And_Tests_Baseline.txt,Evidence,,85b4a0880fc2dd569b12834a4bb3dc66ab65b8bf,0,6050,6050,6050
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_Day065_Starting_State.txt,Evidence,,de518795108c1b1dc6cf6679daaad38f6b4ff381,0,1560,1560,1560
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_Evidence_Organization.txt,Evidence,,d6f3ccc48b93ab567bf4cf1a52eed68a4b8b230d,0,387,387,387
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_Format_Output.txt,Evidence,,7d11dc772be6a68dedbd0580770a369a6113a850,0,214,214,214
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_Format_Retry_Output.txt,Evidence,,c78e6355e9ddc40e8d29b2eb0fd1f72f0e5a7e4a,0,26,26,26
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_GREEN_Source_Change.txt,Evidence,,20d15c8e8021e70ba22f2704d449868b421c17d9,0,513,513,513
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_GREEN_Test_Output.txt,Evidence,,abba62383f0270823c497be5897b2382bd3df895,0,936,936,936
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_Hash_Inventory.txt,Evidence,,8e74cb9929c6ac6a63e50e9e39c0a2e77008de3b,0,2522,2522,2522
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_Hash_Inventory_Verification.txt,Evidence,,d002fc2e1ce1ea7e043fbe7acf0fd7abf85726e9,0,1158,1158,1158
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_Post_Format_Diff_Review.txt,Evidence,,a218405d2799095a534c42817aed4a4220c74c54,0,6760,6760,6760
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_Post_Format_Test_Output.txt,Evidence,,77148140a55763cdbd427acde95fdcadf93c87f9,0,936,936,936
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_Post_Format_WASM_Build_Output.txt,Evidence,,b5a593e97f9e302faf7df523f7e1232d0c8a1bbd,0,102,102,102
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_Precommit_Git_Review.txt,Evidence,,5870c42cfdfad7f1e1a29bb3853af19dc1044658,0,4315,4315,4315
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_RED_Test_Change.txt,Evidence,,6112b2b4f6e1c5080386044392efbe0afc7c4cff,0,2010,2010,2010
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_RED_Test_Output.txt,Evidence,,172c9bd251c661a64b12926c9bf98406585f040b,0,626,626,626
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_Rustfmt_Install_Output.txt,Evidence,,467f9f49b410ba6ce983041d175d9af21cb8541d,0,70,70,70
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_Verification_Completion.txt,Evidence,,2a461ccfe5c95d0b453714844ac5773135077faa,0,232,232,232
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,A,Evidence/CP-002/CP002_WASM_Build_Output.txt,Evidence,,42622151954fcb971e47b642014eb194f436a8bb,0,189,189,189
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,M,src/lib.rs,Source,136860d8f5cd1d5873c3425d501ba5179c1b5e1a,86bd60944d62ad527db8b37f1717a8b99d4bdc62,937,1175,1175,238
065,206dcd8b76af29edcb658a0c5a2dc40d87089fe3,M,tests/artifact_namespace.rs,Tests,5ca77fb06c28a74e05ae58b494b1091a45fdd927,e4a6d48898dd9f7f398284fe895c58077d77754f,2006,2656,2656,650
065,2d06f6259de93f5beaa8eb15f8f22f171127a10e,A,Evidence/CP-003/CP003_Format_Output.txt,Evidence,,c78e6355e9ddc40e8d29b2eb0fd1f72f0e5a7e4a,0,26,26,26
065,2d06f6259de93f5beaa8eb15f8f22f171127a10e,A,Evidence/CP-003/CP003_GREEN_Source_Change.txt,Evidence,,f09a49a284e76a74f75e2376980f23aef06d1b6f,0,1626,1626,1626
065,2d06f6259de93f5beaa8eb15f8f22f171127a10e,A,Evidence/CP-003/CP003_GREEN_Test_Output.txt,Evidence,,c4b4c733bd4f85e5f76c2448c4ce46ead3985615,0,1368,1368,1368
065,2d06f6259de93f5beaa8eb15f8f22f171127a10e,A,Evidence/CP-003/CP003_Hash_Inventory.txt,Evidence,,4827bec91e4e04144facebdd6833b98410de9937,0,1749,1749,1749
065,2d06f6259de93f5beaa8eb15f8f22f171127a10e,A,Evidence/CP-003/CP003_Hash_Inventory_Verification.txt,Evidence,,e2fd26f961f90ffe53d3f33d9e6e901f3223dc21,0,790,790,790
065,2d06f6259de93f5beaa8eb15f8f22f171127a10e,A,Evidence/CP-003/CP003_Post_Format_Diff_Review.txt,Evidence,,ca3b3ba1f88e843291998753acd25e9ac910111f,0,4144,4144,4144
065,2d06f6259de93f5beaa8eb15f8f22f171127a10e,A,Evidence/CP-003/CP003_Post_Format_Test_Output.txt,Evidence,,f5f26d61020ea50b8ea25d709566aad4b08deb9f,0,1362,1362,1362
065,2d06f6259de93f5beaa8eb15f8f22f171127a10e,A,Evidence/CP-003/CP003_Precommit_Git_Review.txt,Evidence,,8b93c7e1c4da2b19d8b03c37d260c5782250479d,0,1272,1272,1272
065,2d06f6259de93f5beaa8eb15f8f22f171127a10e,A,Evidence/CP-003/CP003_RED_Test_Change.txt,Evidence,,bb16cee3cdd826f48ee1cf85a5b65dd7f3cb9828,0,2044,2044,2044
065,2d06f6259de93f5beaa8eb15f8f22f171127a10e,A,Evidence/CP-003/CP003_RED_Test_Output.txt,Evidence,,7fb2e4c6d844d5d82d1838c73d2b025cf0795408,0,710,710,710
065,2d06f6259de93f5beaa8eb15f8f22f171127a10e,A,Evidence/CP-003/CP003_Starting_State.txt,Evidence,,80cd5ecd3b6baf220f495aea0d7694fd5c30661c,0,201,201,201
065,2d06f6259de93f5beaa8eb15f8f22f171127a10e,A,Evidence/CP-003/CP003_WASM_Build_Output.txt,Evidence,,1d73dab33f24a206e0e343cda87eadd7c0b1f54a,0,189,189,189
065,2d06f6259de93f5beaa8eb15f8f22f171127a10e,M,src/lib.rs,Source,86bd60944d62ad527db8b37f1717a8b99d4bdc62,1c892af8c754d863b999ad89b70f6d9a8e9679b6,1175,2486,2486,1311
065,2d06f6259de93f5beaa8eb15f8f22f171127a10e,A,tests/artifact_class_disposition.rs,Tests,,c716299c5d9d37915b48af5fe1c0920fbd3c2fca,0,1834,1834,1834
065,12c02a0f2ff51fae72599adc09332f50fed62ce8,A,Evidence/CP-004/CP004_Format_Output.txt,Evidence,,476d33320010a20ffe94b48c56706927a28dd523,0,363,363,363
065,12c02a0f2ff51fae72599adc09332f50fed62ce8,A,Evidence/CP-004/CP004_GREEN_Source_Change.txt,Evidence,,7f5dc436a23baa7a725be9e881e6b7f149b8c4b3,0,1920,1920,1920
065,12c02a0f2ff51fae72599adc09332f50fed62ce8,A,Evidence/CP-004/CP004_GREEN_Test_Output.txt,Evidence,,fd4f42e41e8f589a19499b72e52dc731695eea07,0,1960,1960,1960
065,12c02a0f2ff51fae72599adc09332f50fed62ce8,A,Evidence/CP-004/CP004_Hash_Inventory.txt,Evidence,,1d4f19c2ee1b3d00c937a5eb5705b3bff95a5fe3,0,2284,2284,2284
065,12c02a0f2ff51fae72599adc09332f50fed62ce8,A,Evidence/CP-004/CP004_Hash_Inventory_Verification.txt,Evidence,,90249957b78115d57e8cbb3ea1be4837fe916ac8,0,2400,2400,2400
065,12c02a0f2ff51fae72599adc09332f50fed62ce8,A,Evidence/CP-004/CP004_Post_Format_Diff_Review.txt,Evidence,,cfad91a85107750689de136548f04e2cd5a9123b,0,4559,4559,4559
065,12c02a0f2ff51fae72599adc09332f50fed62ce8,A,Evidence/CP-004/CP004_Post_Format_Test_Output.txt,Evidence,,7fd319c29d24100826e3649257c79f31f5992b8f,0,1966,1966,1966
065,12c02a0f2ff51fae72599adc09332f50fed62ce8,A,Evidence/CP-004/CP004_Precommit_Git_Review.txt,Evidence,,002928c873c225dc88c39f452750271ab461d0da,0,2933,2933,2933
065,12c02a0f2ff51fae72599adc09332f50fed62ce8,A,Evidence/CP-004/CP004_RED_Test_Change.txt,Evidence,,8c475e709efd0adb7abbac94fe8b2ae14c6a17d9,0,2206,2206,2206
065,12c02a0f2ff51fae72599adc09332f50fed62ce8,A,Evidence/CP-004/CP004_RED_Test_Correction.txt,Evidence,,dc0a4f6d8181bffcef7b2b3f5442c56d74dbef01,0,394,394,394
065,12c02a0f2ff51fae72599adc09332f50fed62ce8,A,Evidence/CP-004/CP004_RED_Test_Output.txt,Evidence,,74ee01f7bbe765115b74a79c078862dcb967564d,0,633,633,633
065,12c02a0f2ff51fae72599adc09332f50fed62ce8,A,Evidence/CP-004/CP004_Starting_State.txt,Evidence,,a1ec2a398a5328afc9e26c0230192a7e8e2843f6,0,372,372,372
065,12c02a0f2ff51fae72599adc09332f50fed62ce8,A,Evidence/CP-004/CP004_WASM_Build_Output.txt,Evidence,,cd565663c1ce411af533306dda79719f386e948c,0,359,359,359
065,12c02a0f2ff51fae72599adc09332f50fed62ce8,M,src/lib.rs,Source,1c892af8c754d863b999ad89b70f6d9a8e9679b6,d1ea916643d322a5cea89e2cd9adade5b0d18b8d,2486,4071,4071,1585
065,12c02a0f2ff51fae72599adc09332f50fed62ce8,A,tests/artifact_filename_envelope.rs,Tests,,cb85ee69259d0bd9bf4f7341fbc1b3dd12241318,0,1901,1901,1901
065,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,A,Evidence/CP-005/CP005_Format_Output.txt,Evidence,,06a1fb0574bcf34bac3ccfa49cc55e01bcecc1d5,0,369,369,369
065,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,A,Evidence/CP-005/CP005_GREEN_Source_Change.txt,Evidence,,8bb68f20e58c1efefa3db22a0366f299280397fe,0,2136,2136,2136
065,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,A,Evidence/CP-005/CP005_GREEN_Test_Output.txt,Evidence,,17cf734ada9b1cf75830d3406992986d85a12c56,0,2362,2362,2362
065,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,A,Evidence/CP-005/CP005_Hash_Inventory.txt,Evidence,,ab8d8d174b3e93063b9422c616a60a77dc859873,0,2269,2269,2269
065,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,A,Evidence/CP-005/CP005_Hash_Inventory_Verification.txt,Evidence,,27ca03f9a295696a24c0dd7b5d2051ae35f9c646,0,2388,2388,2388
065,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,A,Evidence/CP-005/CP005_Post_Format_Diff_Review.txt,Evidence,,f1f6065271b72291426ee89162c4a1a61e53d1bc,0,2342,2342,2342
065,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,A,Evidence/CP-005/CP005_Post_Format_Test_Output.txt,Evidence,,d4d72da232b804269d0726472310328e7141088a,0,2392,2392,2392
065,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,A,Evidence/CP-005/CP005_Precommit_Git_Review.txt,Evidence,,5e3af79afde1d1ac9678ed6bca6a944a4a84e8b9,0,2778,2778,2778
065,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,A,Evidence/CP-005/CP005_RED_Test_Change.txt,Evidence,,8c299a90b0969b30ea9f1b590da17e47b18bea29,0,2369,2369,2369
065,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,A,Evidence/CP-005/CP005_RED_Test_Output.txt,Evidence,,98ab88a08ef0e7ab77e995424e6d498653894a15,0,3092,3092,3092
065,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,A,Evidence/CP-005/CP005_Starting_State.txt,Evidence,,44018fbdd9fe3752189ee2dd7bf49e123548a5b3,0,379,379,379
065,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,A,Evidence/CP-005/CP005_WASM_Build_Output.txt,Evidence,,c83d35a82e7d70515448c1de5d334346056c603a,0,396,396,396
065,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,M,src/lib.rs,Source,d1ea916643d322a5cea89e2cd9adade5b0d18b8d,57e06e4d008fca340bb9ded0c450a547e51b5c7c,4071,5176,5176,1105
065,cedd5d54506b8f3f879b96c5e64fefc9365b6eb0,A,tests/artifact_utc_timestamp.rs,Tests,,9ff6d3359d9fe71bf8465d16f6444577b0e455db,0,2018,2018,2018
065,aff54d08dcbacaa0c54d8869749344a504c5ad61,A,Evidence/CP-006/CP006_Format_Output.txt,Evidence,,0c53687dae27aaaeff945dc928d5a47b4cddfd0f,0,369,369,369
065,aff54d08dcbacaa0c54d8869749344a504c5ad61,A,Evidence/CP-006/CP006_GREEN_Source_Change.txt,Evidence,,40b377b632b85b840c34dde655b2dbd64ac0c4fb,0,1792,1792,1792
065,aff54d08dcbacaa0c54d8869749344a504c5ad61,A,Evidence/CP-006/CP006_GREEN_Test_Output.txt,Evidence,,50218ffb1a00b3217c2285f06031df94035f34f3,0,2876,2876,2876
065,aff54d08dcbacaa0c54d8869749344a504c5ad61,A,Evidence/CP-006/CP006_Hash_Inventory.txt,Evidence,,ac901fbec04fd341f00d8ec5628452a6db76d4f7,0,2435,2435,2435
065,aff54d08dcbacaa0c54d8869749344a504c5ad61,A,Evidence/CP-006/CP006_Hash_Inventory_Verification.txt,Evidence,,cb23c73230a069b0ba9bd3d6ace90bb8b382b274,0,2543,2543,2543
065,aff54d08dcbacaa0c54d8869749344a504c5ad61,A,Evidence/CP-006/CP006_Post_Format_Diff_Review.txt,Evidence,,e1f31f0d3374f01d5be03621510eafc1c44da863,0,1965,1965,1965
065,aff54d08dcbacaa0c54d8869749344a504c5ad61,A,Evidence/CP-006/CP006_Post_Format_Test_Output.txt,Evidence,,0606e884584a4697891f8a6a090db9d03bdca5b3,0,2882,2882,2882
065,aff54d08dcbacaa0c54d8869749344a504c5ad61,A,Evidence/CP-006/CP006_Precommit_Git_Review.txt,Evidence,,e32f8f1fdb5f7a359e190d39ed00b25c1d2cc11b,0,2457,2457,2457
065,aff54d08dcbacaa0c54d8869749344a504c5ad61,A,Evidence/CP-006/CP006_RED_Test_Change.txt,Evidence,,d6e9a9ee9d406e1bd5b79df18188ba4dc0b265e2,0,3423,3423,3423
065,aff54d08dcbacaa0c54d8869749344a504c5ad61,A,Evidence/CP-006/CP006_RED_Test_Output.txt,Evidence,,2a2d8758a2fe859a56c39996972d2df5c5e721ee,0,792,792,792
065,aff54d08dcbacaa0c54d8869749344a504c5ad61,A,Evidence/CP-006/CP006_Starting_State.txt,Evidence,,fc081759c6581094af67cfee710be2bf778bf4e1,0,854,854,854
065,aff54d08dcbacaa0c54d8869749344a504c5ad61,A,Evidence/CP-006/CP006_WASM_Build_Output.txt,Evidence,,e0910f50b7073865ebe1a7531fb2b77b67b3b502,0,396,396,396
065,aff54d08dcbacaa0c54d8869749344a504c5ad61,M,src/lib.rs,Source,57e06e4d008fca340bb9ded0c450a547e51b5c7c,5510381a2b93fd2d31a90fef69f85d0d17a34256,5176,6143,6143,967
065,aff54d08dcbacaa0c54d8869749344a504c5ad61,A,tests/artifact_serialization_separation.rs,Tests,,13abc14c330b7e14ebde5976267b3a7b86041a91,0,3002,3002,3002
065,3c512df519f3a2431b363e4c57dc234c02378124,A,Evidence/CP-007/CP007_Format_Output.txt,Evidence,,9996c9163c7ea4ba484e9b78788b611cafdc6b4b,0,369,369,369
065,3c512df519f3a2431b363e4c57dc234c02378124,A,Evidence/CP-007/CP007_GREEN_Source_Change.txt,Evidence,,9ea8de96b48e4e40481884ca3a7c39b332652ec0,0,1535,1535,1535
065,3c512df519f3a2431b363e4c57dc234c02378124,A,Evidence/CP-007/CP007_GREEN_Test_Output.txt,Evidence,,dd7919d1b825cada76f1eaaabb61ece38c24ab50,0,3360,3360,3360
065,3c512df519f3a2431b363e4c57dc234c02378124,A,Evidence/CP-007/CP007_Hash_Inventory.txt,Evidence,,6754da0ce5bf6671e2ef1d5fb2685baf222f1837,0,2464,2464,2464
065,3c512df519f3a2431b363e4c57dc234c02378124,A,Evidence/CP-007/CP007_Hash_Inventory_Verification.txt,Evidence,,adc110f59f92418e1e809a2eaa0ff78194e5fc90,0,2665,2665,2665
065,3c512df519f3a2431b363e4c57dc234c02378124,A,Evidence/CP-007/CP007_Post_Format_Diff_Review.txt,Evidence,,799b87c248462986cfa95dd95ed8fee0b2ba2a09,0,1870,1870,1870
065,3c512df519f3a2431b363e4c57dc234c02378124,A,Evidence/CP-007/CP007_Post_Format_Test_Output.txt,Evidence,,02aab7f9cd28e5a04309b40f4e66878628c7911f,0,3404,3404,3404
065,3c512df519f3a2431b363e4c57dc234c02378124,A,Evidence/CP-007/CP007_Precommit_Git_Review.txt,Evidence,,22cac489c2b164254836f8cfd7f1f1b49fef1049,0,2398,2398,2398
065,3c512df519f3a2431b363e4c57dc234c02378124,A,Evidence/CP-007/CP007_RED_Test_Change.txt,Evidence,,44c405ee0c5a246b87edb842ee1b893e01ca4b8b,0,3465,3465,3465
065,3c512df519f3a2431b363e4c57dc234c02378124,A,Evidence/CP-007/CP007_RED_Test_Output.txt,Evidence,,7cabf7699bb1e7d379a5ab53ace455354df6dba2,0,790,790,790
065,3c512df519f3a2431b363e4c57dc234c02378124,A,Evidence/CP-007/CP007_Starting_State.txt,Evidence,,d3c0fe2d7cac7ffc5bdef26d895ca2421bfffb26,0,1148,1148,1148
065,3c512df519f3a2431b363e4c57dc234c02378124,A,Evidence/CP-007/CP007_WASM_Build_Output.txt,Evidence,,8474ffd4a53b3e77b94b451d6607dde3c074db04,0,396,396,396
065,3c512df519f3a2431b363e4c57dc234c02378124,M,src/lib.rs,Source,5510381a2b93fd2d31a90fef69f85d0d17a34256,72e48f366affca3fb82002ac17689c31021479e1,6143,6829,6829,686
065,3c512df519f3a2431b363e4c57dc234c02378124,A,tests/artifact_filename_construction.rs,Tests,,740709f838954fe71efcb77fb6065b18a41d6502,0,2872,2872,2872
066,346733a962192320e0d56271add15a47b6037b6b,A,Evidence/CP-008/CP008_Final_Source_Review.txt,Evidence,,b1b19f1f2b96329d9f8eb1047739a492d7539fd9,0,228,228,228
066,346733a962192320e0d56271add15a47b6037b6b,A,Evidence/CP-008/CP008_Final_Staging_Review.txt,Evidence,,f7fb9db3002ed08d5527551953830d8a2f0aa0a5,0,784,784,784
066,346733a962192320e0d56271add15a47b6037b6b,A,Evidence/CP-008/CP008_Full_Regression_Test_Output.txt,Evidence,,aa449ecb44cae74c3700835f3523238a09e641e4,0,3948,3948,3948
066,346733a962192320e0d56271add15a47b6037b6b,A,Evidence/CP-008/CP008_GREEN_Test_Output.txt,Evidence,,d07292ee74dcb140610188c62d7a3cb29483aabe,0,849,849,849
066,346733a962192320e0d56271add15a47b6037b6b,A,Evidence/CP-008/CP008_Git_Whitespace_Check.txt,Evidence,,4d4559eed2c772e664a4878e77a79be444f6b464,0,34,34,34
066,346733a962192320e0d56271add15a47b6037b6b,A,Evidence/CP-008/CP008_Hash_Inventory.txt,Evidence,,37fc3d4d68c13f48c804b9213daf29017154f4b0,0,2228,2228,2228
066,346733a962192320e0d56271add15a47b6037b6b,A,Evidence/CP-008/CP008_Hash_Inventory_Verification.txt,Evidence,,bf2c01f629585b34b88a36b3a039f60cf09150c3,0,224,224,224
066,346733a962192320e0d56271add15a47b6037b6b,A,Evidence/CP-008/CP008_Post_Format_Test_Output.txt,Evidence,,5cace47cff5efb42de4670c7c4375c2712a249f7,0,3829,3829,3829
066,346733a962192320e0d56271add15a47b6037b6b,A,Evidence/CP-008/CP008_Precommit_Git_Review.txt,Evidence,,f8ac194e361e05cc346893b8c33562a57ccc2186,0,6874,6874,6874
066,346733a962192320e0d56271add15a47b6037b6b,A,Evidence/CP-008/CP008_RED_Test_Output.txt,Evidence,,6bf890f284c5eb2fd8456fd4b011b144c32a140c,0,740,740,740
066,346733a962192320e0d56271add15a47b6037b6b,A,Evidence/CP-008/CP008_Rustfmt_Check_Output.txt,Evidence,,5bc3d7fc1c574ac01b941ecef2ce9e01c1a5f25b,0,27,27,27
066,346733a962192320e0d56271add15a47b6037b6b,A,Evidence/CP-008/CP008_Rustfmt_Output.txt,Evidence,,8b996c5591b37c5033aeb1bcb103460277935d3f,0,23,23,23
066,346733a962192320e0d56271add15a47b6037b6b,A,Evidence/CP-008/CP008_Staged_Whitespace_Diagnostic.txt,Evidence,,ccc97896d7e6f40cc604bef95621d9390e0015c0,0,178,178,178
066,346733a962192320e0d56271add15a47b6037b6b,A,Evidence/CP-008/CP008_WASM_Build_Output.txt,Evidence,,32482972022db9718f9210a42d3c278c1815ad6d,0,324,324,324
066,346733a962192320e0d56271add15a47b6037b6b,A,Evidence/CP-008/CP008_Whitespace_Exception_Review.txt,Evidence,,bf3762d7d582b5c0941e3de72987d70143d28e87,0,435,435,435
066,346733a962192320e0d56271add15a47b6037b6b,A,Evidence/Day066_Preflight_Native_Test_Output.txt,Evidence,,8528c2b10150b18f9d6b9f32b29477703f77eac2,0,3206,3206,3206
066,346733a962192320e0d56271add15a47b6037b6b,M,src/lib.rs,Source,72e48f366affca3fb82002ac17689c31021479e1,65e21fd80b432b5e0e7d3d8cacab003fd0493f0e,6829,7783,7783,954
066,346733a962192320e0d56271add15a47b6037b6b,A,tests/CP008_source_eligibility.rs,Tests,,9278693ef83ad52956b539171fbcfdf895d3dd32,0,2189,2189,2189
066,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,A,Evidence/CP-009/CP009_Baseline_Test_Output.txt,Evidence,,fd88873115f385ed14cd395b21bd2a0da25497d0,0,3818,3818,3818
066,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,A,Evidence/CP-009/CP009_Final_Staging_Review.txt,Evidence,,d90ed77a0f92307a9d439e99cfd5859739217f89,0,825,825,825
066,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,A,Evidence/CP-009/CP009_Full_Regression_Test_Output.txt,Evidence,,2e68f7db786bc0296f776db9a991ec69f5965a80,0,4649,4649,4649
066,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,A,Evidence/CP-009/CP009_GREEN_Test_Output.txt,Evidence,,61233472da8f1bd151f616201cdc8e1032dbbefc,0,1015,1015,1015
066,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,A,Evidence/CP-009/CP009_Git_Whitespace_Check.txt,Evidence,,e095be04cdf05fbc68e933752b7a2c8054026beb,0,28,28,28
066,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,A,Evidence/CP-009/CP009_Hash_Inventory.txt,Evidence,,5fe14512f0947a7934f600d02f228d6c150a4b9f,0,2453,2453,2453
066,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,A,Evidence/CP-009/CP009_Hash_Inventory_Verification.txt,Evidence,,1467a4f273ccd7223cdc3e1ad9786ea1467fbccf,0,234,234,234
066,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,A,Evidence/CP-009/CP009_Post_Format_Test_Output.txt,Evidence,,7571215b47f0b491cd10c871b6a432979ef2f4bb,0,4656,4656,4656
066,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,A,Evidence/CP-009/CP009_Precommit_Git_Review.txt,Evidence,,48cb0a3943dd88f9e73ea24dd237e4420b8250d5,0,1652,1652,1652
066,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,A,Evidence/CP-009/CP009_RED_Test_Output.txt,Evidence,,c7b2b310fc96acaceacca4a81afa44e18069d438,0,1092,1092,1092
066,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,A,Evidence/CP-009/CP009_Rustfmt_Check_Output.txt,Evidence,,5bc3d7fc1c574ac01b941ecef2ce9e01c1a5f25b,0,27,27,27
066,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,A,Evidence/CP-009/CP009_Rustfmt_Output.txt,Evidence,,88a7e2765a7aaa5d28b27cc75cd34f4f4cc58733,0,21,21,21
066,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,A,Evidence/CP-009/CP009_WASM_Build_Output.txt,Evidence,,6960faf880906e9c53838d6d7dfa032df2ceee79,0,324,324,324
066,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,M,src/lib.rs,Source,65e21fd80b432b5e0e7d3d8cacab003fd0493f0e,2ded0d2f53fb859cab42fd74e8b1ed383ccfc471,7783,10093,10093,2310
066,dc6ee5d1e547a730e5acdc79d53e56ec5d1c00d8,A,tests/CP009_exact_root_snapshot.rs,Tests,,96ea9db830da3c85673e66b19c68461c720637e5,0,4389,4389,4389
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/.gitattributes,Evidence,,d0683947576aca2864d72d1e8af8f6775ead0ec2,0,272,272,272
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Closing_Git_Review.txt,Evidence,,f1fe50b40fe3ccc902257e7a7b7723e0c88c20a0,0,3487,3487,3487
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Final_Staging_Review.txt,Evidence,,1ab8df42a3225defbabd244043df4525139c116e,0,5675,5675,5675
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Full_Regression_Test_Output.txt,Evidence,,24d43849a2f17455867aa5b3b9e0efff1d9dfa16,0,5031,5031,5031
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_GREEN_Implementation_Review.txt,Evidence,,fb077ad0961d7a8f8851e224b00aa040bcf38d14,0,1069,1069,1069
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_GREEN_Test_Output.txt,Evidence,,26529baf4b4694a86e3b59984fb837430faf59ee,0,648,648,648
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Hash_Inventory.txt,Evidence,,62365429ffa803c0df90c005360e258ff3296de7,0,3265,3265,3265
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Hash_Inventory_Corrected.txt,Evidence,,a4c1b3c5ee7d695eb4177917f7abacca0f09677f,0,3306,3306,3306
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Hash_Inventory_Verification.txt,Evidence,,cba759227fdb9c89d3cea58c2d50420882d449ef,0,3567,3567,3567
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Post_Format_Check_Output.txt,Evidence,,7cc519126ea5088748376a68c501518099f5a845,0,173,173,173
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Post_Format_Regression_Test_Output.txt,Evidence,,f750ac7402ce6e74181e6fc3988b1e09155bfa3d,0,5053,5053,5053
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Precommit_Git_Review.txt,Evidence,,e95dddb7d58ca9b840760042fc4fb921a18733f1,0,2854,2854,2854
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_RED_Test_Output.txt,Evidence,,b84ef3b95215f07a135831b65f8b193668dd5c71,0,1942,1942,1942
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_RED_Test_Output_CMD_Corrected.txt,Evidence,,147d0a7e89f194ce50a8f80fed701d226a982599,0,663,663,663
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Rust_Toolchain_Verification.txt,Evidence,,6639110d91ed7a331390fd9cae501c39acfe8743,0,257,257,257
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Rustfmt_Application_Output.txt,Evidence,,dc10ae88e9544fa159c1fe930695cd89da141dd3,0,360,360,360
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Rustfmt_Check_Output.txt,Evidence,,6714fba35eaf64870fd9235aea9f3987e374d305,0,679,679,679
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Scope_Lock.txt,Evidence,,1e9e9f2fecf72919632ec8888decd6d287b04288,0,752,752,752
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Staged_Whitespace_Diagnostic.txt,Evidence,,f862176d6db242947bb3c0aafbb83353a87e3f66,0,368,368,368
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Starting_State.txt,Evidence,,275a8acaba41ee65d540a126201f0c26ff3abbaf,0,17346,17346,17346
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Supplementary_Hash_Inventory.txt,Evidence,,fd27eda23202a90aeac3890cb3415e28e2decdc8,0,1138,1138,1138
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Supplementary_Hash_Verification.txt,Evidence,,9e05bd6a03dbee9a23b9552f8f417887bb904cb0,0,1219,1219,1219
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Test_PreFormat_Snapshot.txt,Evidence,,c52f8f7d004ee04725739fe1d578b4e077ce0712,0,2175,2175,2175
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_WASM_Build_Output.txt,Evidence,,6f7f3a5330d879836a8275a24cb83a32bbcf77b5,0,229,229,229
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Whitespace_Exception_Review.txt,Evidence,,df0a9b28fe7f928bb9d7accf50c3bb4a767ab765,0,802,802,802
066,b7c515faa9bd000369d7656e09437310261290ae,A,Evidence/CP-010/CP010_Whitespace_Followup_Verification.txt,Evidence,,5a4a210d333bd63dd2a941a6fb39bfda4db74324,0,509,509,509
066,b7c515faa9bd000369d7656e09437310261290ae,M,src/lib.rs,Source,2ded0d2f53fb859cab42fd74e8b1ed383ccfc471,715a1c1bcf0224aed17f29520b9da1cbc4a1da35,10093,10589,10589,496
066,b7c515faa9bd000369d7656e09437310261290ae,A,tests/CP010_cvt_filename_candidate.rs,Tests,,e90bdbe35e6310179c3455500212328f80a48b6d,0,2172,2172,2172
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/.gitattributes,Evidence,,649ed1a988cc8ba161da69aed759e22de76691ef,0,236,236,236
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Closing_Git_Review.txt,Evidence,,c82da5c35c344adaeb7dd608f7457154937e42f1,0,5510,5510,5510
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Final_Staging_Review.txt,Evidence,,7df97718d8faf438c00ea6060e280c5d7a7f3717,0,1852,1852,1852
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Full_Regression_Test_Output.txt,Evidence,,a5c6491314eb4eff0cf5da2b8c735cb44ed6f8fa,0,6032,6032,6032
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_GREEN_Source_Change.txt,Evidence,,54b202983ba2e9bd53db7c7b869e99fe19fa1b02,0,1247,1247,1247
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_GREEN_Test_Output.txt,Evidence,,abe5438532969bfbd74611eea574690632176114,0,1100,1100,1100
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Hash_Inventory.txt,Evidence,,e2f305517de429fb2d1a2ac295bb6453753a9b43,0,3339,3339,3339
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Hash_Inventory_Verification.txt,Evidence,,629854464b21b9359294200dff3e3aa541b2d6b2,0,417,417,417
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Post_Format_Regression_Test_Output.txt,Evidence,,ad512ffe2edb40bf74f52fc8b24c8bc40d2a213d,0,6118,6118,6118
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Post_Format_WASM_Build_Output.txt,Evidence,,69e795bede47568bf0d6813302f35768a6a2255a,0,684,684,684
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Precommit_Git_Review.txt,Evidence,,acc260e55dd2f58a6e4fd55f6dd996cb9c9bb62f,0,2982,2982,2982
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Preformat_Test_Snapshot.txt,Evidence,,e6e73530a3ec903552333301759740f28bea576a,0,2344,2344,2344
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_RED_Test_Output.txt,Evidence,,5a426f932110a363050a6ac5b8a67da0ab2a0c11,0,942,942,942
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Rustfmt_Apply_Output.txt,Evidence,,a4ab67ad599f808b7470402be9914cfebc8ccb42,0,853,853,853
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Rustfmt_Check_Output.txt,Evidence,,e84f62f2c279181a64ca9451095b59d1b132083d,0,2068,2068,2068
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Rustfmt_Recheck_Output.txt,Evidence,,ec38f67b236d8cb7b040b7865c0d46a4a8ee39c9,0,571,571,571
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Scope_Lock.txt,Evidence,,ef2f4312c2dc775d4d4aca37ba9d7b8e90f18ed8,0,1138,1138,1138
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Staged_Whitespace_Diagnostic.txt,Evidence,,5404ae346d592ea46e48dfedeecf8d4f21650d8e,0,1751,1751,1751
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Staging_Recovery_Review.txt,Evidence,,dd6baee7ad47334f949d97c5dc6f4122569f1fff,0,894,894,894
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Starting_State.txt,Evidence,,2197256c5bd0cddc881aef7759ad5ea0cc1c98b8,0,404,404,404
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Supplementary_Hash_Inventory.txt,Evidence,,c605d7ab10607f64dd646fd346f5023925af6ff7,0,1370,1370,1370
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Supplementary_Hash_Verification.txt,Evidence,,162ad73d2acf38dc9e5a4cb6bd558d346b50b8f5,0,613,613,613
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Supplementary_Staging_Review.txt,Evidence,,47d908145b329130c035cef3061e0b6b1002d366,0,1995,1995,1995
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_WASM_Build_Output.txt,Evidence,,cb1c73489afb77d281eca531f8457df298f84ea4,0,688,688,688
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,Evidence/CP-011/CP011_Whitespace_Exception_Review.txt,Evidence,,204b16b1cdeb733804c62f2d4e0562979c722c26,0,654,654,654
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,M,src/lib.rs,Source,715a1c1bcf0224aed17f29520b9da1cbc4a1da35,e08d25b4bd1defa4d82f4fe0a357da30eb8c19d0,10589,11016,11016,427
066,e84ae5baeee05f9d5d30284c65b86eebba3c0f6a,A,tests/CP011_cvt_scr_candidate_identity.rs,Tests,,bd21f27207b44fe930d05b137e856016c77d42a5,0,2321,2321,2321
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/.gitattributes,Evidence,,7916e6463d8cae2dd491e5d14cdd7519ef8ecd0e,0,426,426,426
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_Closing_Git_Review.txt,Evidence,,6ac4af3af9cbd3b3011ce123cfc7e758c23c18b6,0,2353,2353,2353
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_EOF_Whitespace_Amendment.txt,Evidence,,6d76606ed20b383d2ca6efb1f5485b0d54f722d4,0,1772,1772,1772
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_Final_Rustfmt_Check.txt,Evidence,,d5262a74e28a3ed7336728911624cf5c8b628ba4,0,706,706,706
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_Final_Staging_Review.txt,Evidence,,77f525a1b32a475ea5f2465d3ada6bda20e266b8,0,2228,2228,2228
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_Full_Regression_Test_Output.txt,Evidence,,8f874357902e01fa2e65a81b5d8e0fc59feecf0b,0,6722,6722,6722
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_GREEN2_Test_Output.txt,Evidence,,da9effb99ae548566c0bcd074f991c643bc053d0,0,1279,1279,1279
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_GREEN_Correction_Review.txt,Evidence,,f75335fb8aaf99d20527240e8c8fac21a5d18507,0,1558,1558,1558
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_GREEN_Failure_Triage.txt,Evidence,,adfebbbbff732ec071255727f622f1e9aa21043f,0,9465,9465,9465
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_GREEN_Rustfmt_Precheck.txt,Evidence,,,0,0,0,0
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_GREEN_Source_Change.txt,Evidence,,2b0cb2a6e4d4d31eab9631a29e59b10596d72dd3,0,1320,1320,1320
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_GREEN_Test_Output.txt,Evidence,,408eb5f299006c88679e8558e60634d3fa2673c7,0,1596,1596,1596
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_Hash_Inventory.txt,Evidence,,c3a7c0ed4527a5c56fd99b8607ead89cb381dbee,0,3730,3730,3730
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_Hash_Inventory_Verification.txt,Evidence,,a0c4d70ea3c688dfbeed584349c5cc853785216e,0,1492,1492,1492
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_Post_Staging_Hash_Amendment.txt,Evidence,,1e476209c5a78c553da345a7618902c531c5b7a1,0,1571,1571,1571
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_Post_Staging_Hash_Verification.txt,Evidence,,f65368fe8b14ede17f811bdc3e11013cb566f3a0,0,766,766,766
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_Precommit_Git_Review.txt,Evidence,,d833fd9cbb1b3cf21c8f2bfb5019d83e6b9549b6,0,3086,3086,3086
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_RED_Test_Output.txt,Evidence,,104a078454ffc8264e5bf887387d3b95aa0e1336,0,1095,1095,1095
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_Scope_Lock.txt,Evidence,,ebba1e22a9f9a58a5f280b3172c4b838392bf69c,0,1317,1317,1317
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_Staged_Whitespace_Review.txt,Evidence,,9a51129eb7e957df1a8e901581454472b434eb4c,0,1984,1984,1984
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_Starting_State.txt,Evidence,,e6b486609e6241aa581677f3cb851019f426d7dc,0,3699,3699,3699
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_Supplementary_Hash_Inventory.txt,Evidence,,1275f93b8726e6322a195a1a5035af7694be8952,0,1046,1046,1046
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_Supplementary_Hash_Verification.txt,Evidence,,6d44e087e5411141deb10021155867e1fb1cd9b3,0,781,781,781
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_Test_Authoring_Format_Output.txt,Evidence,,07cc6a4a5b30e68694900e6f0e19e5f38c836b5e,0,242,242,242
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_WASM_Build_Output.txt,Evidence,,2291d67a76838073a894425cbeb26554402e6bce,0,896,896,896
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,Evidence/CP-012/CP012_Whitespace_Exceptions_Review.txt,Evidence,,72a264f99347aa0008fb2988890891104520c0e4,0,1456,1456,1456
066,efca04392940e398020a5c06b9ee50296c8a1fdd,M,src/lib.rs,Source,e08d25b4bd1defa4d82f4fe0a357da30eb8c19d0,b59ee4678de5c956107766f75e867dd1c1f4a352,11016,11541,11541,525
066,efca04392940e398020a5c06b9ee50296c8a1fdd,A,tests/CP012_scr_filename_candidate.rs,Tests,,39389b66b88d947c3146e5f0710b95c9e8d5deab,0,1976,1976,1976
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/.gitattributes,Evidence,,8d3a12dc9988365eb06c13d3d8204414afdc97a6,0,547,547,547
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Approved_Scope_Lock.txt,Evidence,,b8bc3bd6c76f89dd2b9666de8be27e63fbba3a43,0,2236,2236,2236
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Closing_Git_Review.txt,Evidence,,f40b328d99141f6957177c7beea915af8c05b927,0,3386,3386,3386
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Closing_Hash_Amendment.txt,Evidence,,a05a3768adb7c7067ea90aecff54e67ad46d15ea,0,1496,1496,1496
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Closing_Hash_Verification.txt,Evidence,,82c57faa151d5c12bf3759ea8a5e76f778f654e4,0,4148,4148,4148
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Final_Evidence_Staging_Review.txt,Evidence,,7cd60f441ebe866fdf03f9395ed098f9397eebdf,0,2986,2986,2986
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Final_Staging_Verification.txt,Evidence,,03ca63b29b802a69e028e2937cd031466fd5a921,0,5064,5064,5064
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Full_Regression_Test_Output.txt,Evidence,,f5a449cf20643c9ab32ffa70fd42ba598bc35a8a,0,6617,6617,6617
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Full_Regression_Verification.txt,Evidence,,4632d651638cd57e9da841bfef854dcebc645683,0,674,674,674
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_GREEN_Implementation_Report.txt,Evidence,,4d79c7eb970b267a9328638008a9c2df3cbddb6d,0,752,752,752
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_GREEN_Test_Output.txt,Evidence,,c319ce343f8a09041ecfaa85c5fa7d190dc6aa57,0,767,767,767
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_GREEN_Test_Verification.txt,Evidence,,32e085d02532cfa358e7d6940bcc0d12ea25354f,0,692,692,692
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Git_Byte_Preservation_Correction.txt,Evidence,,01395098a88f9feced444983f3e9f81e30f76095,0,6495,6495,6495
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Git_Byte_Preservation_Preflight.txt,Evidence,,203d5c62dff3e9d7e244eca005a29101615ea8c4,0,7179,7179,7179
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Git_Normalization_Diagnostic.txt,Evidence,,92ae84193d99d78c9c379ca86052b48333f879f7,0,10336,10336,10336
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Hash_Inventory.txt,Evidence,,a1f5df08f90d5d4ea5be238d52251dd855ae9b0b,0,2803,2803,2803
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Hash_Inventory_Verification.txt,Evidence,,4eb11024534c02c46bbd0b8331bfd81ee6d98017,0,1699,1699,1699
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Opening_Git_Preflight.txt,Evidence,,51aeaf3e50206991f3ccf49053968ed7e1338c1a,0,340,340,340
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Post_Normalization_Hash_Amendment.txt,Evidence,,490fa0c07fbfb2122232c9946bb1152b5a3f0a8d,0,1472,1472,1472
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Post_Normalization_Hash_Verification.txt,Evidence,,8720da037e07fb1288c7ff119415e846f8483782,0,3666,3666,3666
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Precedent_Test_Inspection.txt,Evidence,,154133126e4498a2f50515dd638cd32e9af73b27,0,8512,8512,8512
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Precommit_Git_Review.txt,Evidence,,5bf9c20483d8228e10a7605d1f48f10c5b61e799,0,2907,2907,2907
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_RED_Test_Hash_Lock.txt,Evidence,,5ddc7d90b0f61505b9cab336fb1629ccb0f50a80,0,568,568,568
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_RED_Test_Output.txt,Evidence,,0651f6c49f27cbc79a39cbb3bb283e2e4c1b38d0,0,607,607,607
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_RED_Test_Verification.txt,Evidence,,7bf907adb2824596adb7586b973aefebc0b31c85,0,551,551,551
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Raw_Evidence_Whitespace_Preflight.txt,Evidence,,99c0646006eb5158d61fc0a48d94bb0fc13bc25d,0,5583,5583,5583
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Rustfmt_Check_Output.txt,Evidence,,,0,0,0,0
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Rustfmt_Check_Verification.txt,Evidence,,fb6e89b73db5e992391a73321d8562ae21a8e176,0,526,526,526
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Source_Inspection.txt,Evidence,,65dcb70d89d638f34ab76e0a30aec04a3b65d528,0,15768,15768,15768
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Staged_Whitespace_Recovery_Output.txt,Evidence,,,0,0,0,0
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Staged_Whitespace_Recovery_Report.txt,Evidence,,c4e1c38ec42377e5c1a252465718b29fce30dbcd,0,856,856,856
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Staging_Action_Report.txt,Evidence,,ddc2cc3f566ed4ed3e0d927c5cfe51c2cf0fcd79,0,181299,181299,181299
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Supplementary_Hash_Inventory.txt,Evidence,,124fc8d216d41773fe373fa46226568a2aa8066a,0,1115,1115,1115
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Supplementary_Hash_Verification.txt,Evidence,,a11d3b59a1cdf118be9dc3b88662b6baa5f45eb3,0,2239,2239,2239
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Test_Authoring_Report.txt,Evidence,,9b5ba5b6f8ff81ee40a0cc13d7b064139398f5d7,0,446,446,446
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Test_Formatting_Report.txt,Evidence,,18037ce47355fb21b656d3d14735a957c3b8123e,0,524,524,524
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Test_Rustfmt_Output.txt,Evidence,,,0,0,0,0
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_WASM_Build_Output.txt,Evidence,,6f56aedba8899dc42cefc4d1e6f741cc09871c48,0,159,159,159
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_WASM_Build_Verification.txt,Evidence,,87586e87ae33a0dabc8ed078ab939af9b1b8daf1,0,713,713,713
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,Evidence/CP-013/CP013_Whitespace_Exception_Review.txt,Evidence,,718b425f6e80e1a1ea313e7e85ad32663f9acb37,0,1284,1284,1284
066,005a38ef5e876847c4c08901c18da9c18565fd6b,M,src/lib.rs,Source,b59ee4678de5c956107766f75e867dd1c1f4a352,b2df81ba4946220e85543b44bd8ab33e3a341f9e,11541,12312,12312,771
066,005a38ef5e876847c4c08901c18da9c18565fd6b,A,tests/CP013_scr_rcp_candidate_identity.rs,Tests,,f512948ac406169c9c2e454a3814103b75bf3e24,0,2727,2727,2727
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Evidence_Preflight.txt.zip,Evidence,,a310e356f3be36dce8c40c42c7cd454925a80e5b,0,1980,1980,1980
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Full_Regression_Record.txt.zip,Evidence,,2e9c2a52ab6d684f18c151f9cae19a5fd1855ca8,0,587,587,587
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Full_Regression_Test_Output.txt.zip,Evidence,,79cbf74526bfc0c6f811ee113af1d9cb054ca34c,0,1913,1913,1913
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_GREEN_Run_Record.txt.zip,Evidence,,0460ce3e6ea383792cbd534bb4dfba231583de18,0,575,575,575
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_GREEN_Test_Output.txt.zip,Evidence,,b60a91accecc7c7e67aa6d7e9a7839ce2a24697d,0,547,547,547
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Git_Attributes_Amendment_Record.txt.zip,Evidence,,dc870a4724ae08ecc22f9584e30b49ecf1ce2816,0,593,593,593
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Git_Attributes_Diff_Recovery.txt.zip,Evidence,,4e0d267710c12f956196a3d5ed6ada1f75586d18,0,386,386,386
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Git_Attributes_Recovery_Record.txt.zip,Evidence,,0581808d3a5a3204c75ea7224235c3a807ddc6a3,0,654,654,654
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Git_Text_Policy_Inspection.txt.zip,Evidence,,2ac1c6b3c9b3b1d1061c8b45b34fd36b07a45b12,0,614,614,614
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Hash_Inventory.txt.zip,Evidence,,39ce42f7bae0412cef05f420357d5e9409497e70,0,1611,1611,1611
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Hash_Inventory_Verification.txt.zip,Evidence,,5ceac0a014bcffb233e8271906b92f8bdd90daa5,0,458,458,458
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Implementation_Record.txt.zip,Evidence,,93dcc2358240ff84cde0eac6cc027de7d621b9bc,0,545,545,545
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Implementation_Surface.txt.zip,Evidence,,bdb223bb982bced6919253bf8512856922a0a5cb,0,3401,3401,3401
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_RED_Run_Record.txt.zip,Evidence,,0bac9153ce90edf974b29a73cb8d5af8c59dda42,0,453,453,453
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_RED_Test_Output.txt.zip,Evidence,,a9f8c41c934fd173b7a020e3eca8da03e1f3e0e6,0,500,500,500
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Rustfmt_Check_Output.txt.zip,Evidence,,c56f93c64b6bf4cde623544d582528129da17ae6,0,158,158,158
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Rustfmt_Check_Record.txt.zip,Evidence,,3ae5253de673d3e3ed5f2b4190a4067f26491464,0,545,545,545
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Rustfmt_Output.txt.zip,Evidence,,eefd51e878c1c832f35e50866a663ada3d66e3b2,0,146,146,146
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Scope_Inspection.txt.zip,Evidence,,bf2e644644f6f45d4490218ea5224c7559217725,0,1588,1588,1588
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Scope_Lock.txt.zip,Evidence,,83a1ecb59915044f7457ae8c1f013cf359a895f3,0,705,705,705
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Source_Diff.txt.zip,Evidence,,ef563010c132ff6ce42a8b69f7542c20e32ecfc2,0,630,630,630
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Staged_Path_List.txt.zip,Evidence,,e67046776ce5a241cde2c188193db92252004427,0,453,453,453
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Staged_Whitespace_Check.txt.zip,Evidence,,a46161c2583031567708955cf6d1d32628257f6c,0,12668,12668,12668
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Staging_Command_Output.txt.zip,Evidence,,c9b25e67a759a531b3fe2154d0cf9db5fc0cfafd,0,257,257,257
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Staging_Record.txt.zip,Evidence,,7a5a9ad31f814516de9851e914103650c3cd19c2,0,528,528,528
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_Test_Format_Record.txt.zip,Evidence,,02b6b7ee3676384521be0488ee977e2d7eb3013c,0,456,456,456
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_WASM_Build_Output.txt.zip,Evidence,,8fa0f362ec151fc8cad538c795465bf310c0afb2,0,293,293,293
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_WASM_Build_Record.txt.zip,Evidence,,c3ecc912c39c4e90207a8aabf457d02b5d8b56a2,0,551,551,551
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_ZIP_Batch_Verification.txt.zip,Evidence,,a0db08db8962dea3cf64b74e381d914ce090caf7,0,3494,3494,3494
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Git_Add_Output.txt.zip,Evidence,,fe3bd771fe521d852ac1d894bc6d2eb88ab31926,0,166,166,166
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Git_Record.txt.zip,Evidence,,0a185b4321360f495ca2611bb70618dbd8a305a3,0,571,571,571
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,Evidence/CP-014/ZIP/CP014_ZIP_Pilot_Verification.txt.zip,Evidence,,7937e1f6b1ab4a6db98eca06882e5b98e7cdc288,0,573,573,573
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,M,src/lib.rs,Source,b2df81ba4946220e85543b44bd8ab33e3a341f9e,56916f9a9d682e9ec6b0d95c60dc27013dd30b78,12312,12915,12915,603
067,f5038a183f1d3dc31b0065571bf8ac8814b5d8a9,A,tests/CP014_rcp_filename_candidate_identity.rs,Tests,,f5d6552ebdb25a15a689f345b248613084963bbb,0,2633,2633,2633
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,Evidence/CP-015/ZIP/CP015_Final_Archive_Manifest.txt.zip,Evidence,,1c4ed67614823082590a209de0eaba43ae3c0b18,0,2137,2137,2137
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,Evidence/CP-015/ZIP/CP015_Formatting_Amendment_Verification.txt.zip,Evidence,,e9a7ec36e666fd81ba2e2e89b3c39b2ab73c3314,0,649,649,649
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,Evidence/CP-015/ZIP/CP015_Full_Regression_Test_Output.txt.zip,Evidence,,439a705b86e5bb6d347950773623c44d95d08b1f,0,2010,2010,2010
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,Evidence/CP-015/ZIP/CP015_Full_Regression_Verification.txt.zip,Evidence,,4290089fc2fea68961083be7817083eaa53ab3c2,0,490,490,490
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,Evidence/CP-015/ZIP/CP015_GREEN_Gate.txt.zip,Evidence,,76b31cc9255cc680846c6d99dd05b4f706c3efba,0,472,472,472
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,Evidence/CP-015/ZIP/CP015_GREEN_Test_Output.txt.zip,Evidence,,d2c91f50c9ff90cfc8b289f6c3d16f6136c0a051,0,566,566,566
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,Evidence/CP-015/ZIP/CP015_PostAmend_Rustfmt_Output.txt.zip,Evidence,,ef44dd3089858440bf96e9b6eb7685bf71c6dd46,0,166,166,166
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,Evidence/CP-015/ZIP/CP015_PostAmend_Test_Output.txt.zip,Evidence,,8113e058360eb56758a4db13ba5486ea51782ade,0,575,575,575
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,Evidence/CP-015/ZIP/CP015_PreArchive_Hash_Inventory.txt.zip,Evidence,,f2040eb5ecbf42da44a8fe5ed41495e88ac9bbf5,0,954,954,954
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,Evidence/CP-015/ZIP/CP015_PreArchive_Hash_Verification.txt.zip,Evidence,,ce5b75e7ee64fcd470475929c703864a433dda6c,0,527,527,527
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,Evidence/CP-015/ZIP/CP015_RED_Gate.txt.zip,Evidence,,d867846a458e32adbf345c07f83dbd22c8746b6f,0,408,408,408
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,Evidence/CP-015/ZIP/CP015_RED_Test_Output.txt.zip,Evidence,,7760a0634a9f942ccc86c9acac78ddc2d368fddf,0,450,450,450
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,Evidence/CP-015/ZIP/CP015_Rustfmt_Check_Gate.txt.zip,Evidence,,fa2c5f693e158c8ae50f93a7b5628c2845aa28d6,0,448,448,448
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,Evidence/CP-015/ZIP/CP015_Rustfmt_Check_Output.txt.zip,Evidence,,946807f1782fba86f73bf18f7bc9ed6a3c13ab0f,0,612,612,612
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,Evidence/CP-015/ZIP/CP015_WASM_Build_Output.txt.zip,Evidence,,fea63c19dcfc9024b9aff604c50438465e4485d6,0,292,292,292
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,Evidence/CP-015/ZIP/CP015_WASM_Build_Verification.txt.zip,Evidence,,eda75631f95f65e87148ace3352309693cdba609,0,504,504,504
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,M,src/lib.rs,Source,56916f9a9d682e9ec6b0d95c60dc27013dd30b78,8df0b4a5eca89f0a42d19db2dcf9ee8fe18d1a40,12915,13602,13602,687
067,be997dc0dbd65fc370814c4a5f2d0f1254870572,A,tests/CP015_scr_rcp_filename_pair_identity.rs,Tests,,378274dfa3f1ce04bfb4ea7f822c861657d74624,0,3248,3248,3248
068,1966da4beeb9726739aee3517d6e2b2eb30af397,D,DataSculptor_WASM002_Development_Log.html,Other,93850238eef288f9938432c274c581dd9df6d30f,,10117,0,0,-10117
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_Custody_Control_Sealing_Record.txt.zip,Evidence,,ad15fa60a473f8fbba9afa3c8ca2172760b8234b,0,629,629,629
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_Custody_Transfer_Record.txt.zip,Evidence,,fbbebc2d18ad26c8aab9e6dd1b4f57ad99fbbfd5,0,446,446,446
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_Custody_ZIP_Staging_Record.txt.zip,Evidence,,764b3fae5be41d347bf70c1503e3a08f425aaafc,0,3099,3099,3099
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_Final_Custody_Addendum_Record.txt.zip,Evidence,,f674e1dc3512cf49d9638f4f0c4d134df06ec636,0,647,647,647
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_Formatting_Amendment_Installation_Record.txt.zip,Evidence,,f3bd0b57b699a3d62c132b117d65225221617ad4,0,611,611,611
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_Formatting_Candidate_Record.txt.zip,Evidence,,94eae76f42287b80d467c8b470e5238916114035,0,560,560,560
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_Formatting_Candidate_StdErr.txt.zip,Evidence,,87cdbdc6c0f805d8e70e7a2aed6b4fd3f9345721,0,172,172,172
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_Formatting_Candidate_StdOut.txt.zip,Evidence,,17d0cf5b76071f28d58b30efeb60228cfd5c2a77,0,172,172,172
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_GREEN_Installation_Record.txt.zip,Evidence,,5f14e4ed602b2ee0309ef681df9c56b0f85fa477,0,470,470,470
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_GREEN_Reconciliation_Record.txt.zip,Evidence,,d19297dd1390ec68cdee5e5ee4c296d93b172839,0,403,403,403
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_GREEN_Refusal_Diagnostic.txt.zip,Evidence,,40bb260b701790c9c58190c746ba829ed5e32e8f,0,656,656,656
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_GREEN_StdErr.txt.zip,Evidence,,e1fb5d967fb1c8ac3045b5745b488ca5feb5cd5a,0,352,352,352
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_GREEN_StdOut.txt.zip,Evidence,,9c82c51c6efc3c9b8747f62495da9daab51acd3b,0,465,465,465
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_GREEN_Verification_Run_Record.txt.zip,Evidence,,496649730aaadedb64278a06c0534611382019e3,0,499,499,499
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_GREEN_Verification_StdErr.txt.zip,Evidence,,7581b3a99191dc5b8358a302cac33fb4e886c2f4,0,314,314,314
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_GREEN_Verification_StdOut.txt.zip,Evidence,,77f4b24ff43d27707abecfa19ccb457b7079d711,0,490,490,490
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_PostAmendment_Regression_Run_Record.txt.zip,Evidence,,708ee279d28b3562ef9b617c87d3a64d48af2ad4,0,533,533,533
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_PostAmendment_Regression_StdErr.txt.zip,Evidence,,678861584c9931c7667d82207fdb71c948fb5a62,0,816,816,816
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_PostAmendment_Regression_StdOut.txt.zip,Evidence,,5eacf17dcde716f087e8d2d27a99983de78649a1,0,1652,1652,1652
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_PostFormat_Run_Record.txt.zip,Evidence,,4527bbb1e93f28538368e86a952dfef133030985,0,446,446,446
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_PostFormat_StdErr.txt.zip,Evidence,,a49c4f4265ca31e7c9b47da93a8bafcd96d3c43a,0,152,152,152
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_PostFormat_StdOut.txt.zip,Evidence,,42fea9a8dd1f274b8602fba27b0b87d0ec92e6c7,0,152,152,152
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_PreCustody_Inventory.txt.zip,Evidence,,0fb64895f010ee89732ad1cf137135450300942f,0,1728,1728,1728
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_PreFormat_Frozen_Test.rs.zip,Evidence,,4a31ddc2c5cec15a71cc283fd3a3c98d427c4431,0,1618,1618,1618
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_RED_Run_Record.txt.zip,Evidence,,2be07d3783fe4f3aaba03884b5112f919368dfc9,0,462,462,462
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_RED_StdErr.txt.zip,Evidence,,ec4a0e1ab0eb4d5cebd63aff04aed46e1805dffe,0,470,470,470
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_RED_StdOut.txt.zip,Evidence,,8730d573d9756ee3cbdf1d9bd15d9867e4821ad6,0,138,138,138
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_Regression_Run_Record.txt.zip,Evidence,,b9ced42ee9edfef708825df64a0474a9ea2fbd3c,0,482,482,482
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_Regression_StdErr.txt.zip,Evidence,,3148419e5cda556aa4edfe2e6e54886afa9e2e5a,0,788,788,788
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_Regression_StdOut.txt.zip,Evidence,,f19f837a9f4deab3bc53f163a17d5c62ddfaa50d,0,1627,1627,1627
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_Rustfmt_Run_Record.txt.zip,Evidence,,b04de7c4f42dbf1cffad302f70d955f165555db9,0,473,473,473
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_Rustfmt_StdErr.txt.zip,Evidence,,94a02fe0561edf3f615b18141dbbc5e8f686d149,0,146,146,146
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_Rustfmt_StdOut.txt.zip,Evidence,,c27b56ee0a2d2de4c125ba295644fadd72af8fee,0,1483,1483,1483
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_WASM_Build_Run_Record.txt.zip,Evidence,,4b5559ae4f01914f8d9e7874a90999f9a331f32f,0,621,621,621
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_WASM_Build_StdErr.txt.zip,Evidence,,67d449418f0d1c1fecbaba98c1ec4f7d8e220348,0,292,292,292
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,Evidence/CP-016/ZIP/CP016_WASM_Build_StdOut.txt.zip,Evidence,,d0634bf221b6dc47f998eec18953cf246ec90dd1,0,152,152,152
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,M,src/lib.rs,Source,8df0b4a5eca89f0a42d19db2dcf9ee8fe18d1a40,39d0a674dcf55ac2244fbe2333ab0b0cd15d54c9,13602,15525,15525,1923
068,fde0f0a8b96c92f6cfb80b517396ff5512cccd13,A,tests/CP016_receipt_field_serialization.rs,Tests,,74e3b402f559e2b3213820ddbd009502e4916ece,0,5194,5194,5194

ProjectDay,GitCommits,GitCPCommits,CreditedCPs,ChangedPathRecords,GrossBytes,EvidenceBytes,SourceBytes,TestsBytes,OtherBytes,NetBytes
063,3,1,0,16,19798,6070,1147,2006,10575,19588
064,0,0,0,0,0,0,0,0,0,0
065,6,6,7,93,181899,141736,25880,14283,0,159905
066,6,6,6,158,572072,492964,63334,15774,0,514221
067,2,2,2,52,82257,49859,26517,5881,0,57030
068,2,1,1,39,44935,24216,15525,5194,0,21216

WASM-002 DEVELOPMENT LOG — DAY 068 GIT OBJECT VOLUME RECONCILIATION
STATUS=DERIVED READ-ONLY AUDIT; NOT A GIT COMMIT OR RUN RECEIPT
SOURCE=User-supplied DataSculptor-WASM002.zip (includes .git object database)
SOURCE_ZIP_SHA256=4778D59CF5409956D1D4EFF960BF6E284DEF47C57972117E0C0028D259B5FC0A
SOURCE_GIT_HEAD=fde0f0a8b96c92f6cfb80b517396ff5512cccd13
METHOD=git rev-list --reverse HEAD; git diff-tree --root -r --raw --no-renames; git cat-file -s <blobOID>
RECORDS=19 commits; 358 file-change records; 6 project-day rows
GROSS_BYTES=900961
NET_BYTES=771960
EVIDENCE_BYTES=714845
SOURCE_BYTES=132403
TEST_BYTES=43138
OTHER_BYTES=10575
GROSS_RULE=For each new/modified tracked blob, count full new object bytes; deletion contributes zero to gross.
NET_RULE=For each path change, subtract old Git blob byte length from new Git blob byte length. Deleted files contribute negative bytes.
CATEGORIES=Evidence/ => Evidence; src/*.rs => Rust source; tests/*.rs => Tests; all others => Other.
UNIT=KiB is 1024 bytes. Displayed figures are rounded; authoritative values are integer byte totals.
DAY_063=3 Git commits, 0 credited CPs (CP001 was committed on Day063 but credited Day065).
DAY_064=0 Git commits, 0 credited CPs; Workbench prototype BUILD still counts as a BUILD day.
DAY_065=6 Git commits, 7 credited CPs.
DAY_066=6 Git commits, 6 credited CPs.
DAY_067=2 Git commits, 2 credited CPs (CP014, CP015); 82257 gross, 57030 net bytes.
DAY_068=2 Git commits, 1 credited CP (CP016) plus one housekeeping deletion; 44935 gross, 21216 net bytes.
DAY_068_DELETE_COMMIT=1966da4beeb9726739aee3517d6e2b2eb30af397 deleted DataSculptor_WASM002_Development_Log.html, 10117 previous Git bytes.
CP015=be997dc0dbd65fc370814c4a5f2d0f1254870572; 28110 gross, 15195 net; 18 file-change records.
CP016=fde0f0a8b96c92f6cfb80b517396ff5512cccd13; 44935 gross, 31333 net; 38 file-change records.
CP014_PRIOR_REPORT_DISCREPANCY=Historical Day067 CP014 summary reported 54170 gross and 41858 net bytes; direct Git blobs report 54147 gross and 41835 net (23 bytes lower in each). Historical CP014 test contribution reported 2656 bytes; actual committed test blob is 2633 bytes. The preserved earlier report is not rewritten; refreshed totals use Git-object measurements.
PACKAGING_DISCONTINUITY=Day067 began storing diagnostic evidence as compressed ZIPs, unlike most preceding TXT evidence. Volume is not a productivity/effort/quality/ETA measure.
LIMITS=No independent browser or adversarial implementation QA claimed. The uploaded ZIP establishes the Git history available within that snapshot, not a remote publication.
DAY_068_STATUS=OPEN; HOLDING PATTERN; NO NEW GIT OPERATIONS