Migrated from Method backlog

This issue was created from a legacy filesystem backlog card. GitHub Issues are now the live work tracker; repository docs remain Method evidence.

Source backlog: docs/method/backlog/inbox/PLATFORM_wesley-boundary-grammar.md
Original lane: inbox
Original legend: PLATFORM

Original backlog card

Wesley Boundary Grammar

Milestone: Backlog | Priority: Unscheduled

Remaining work on Wesley as a boundary grammar — canonical AST, schema hashing, schema evolution vocabulary, and provenance query semantics. These are foundational to the Phase 2 roadmap.

Issues: flyingrobots/echo#174, flyingrobots/echo#193, flyingrobots/echo#194, flyingrobots/echo#198

T-10-7-1: Hashable View Artifacts (#174)

User Story: As the Wesley pipeline, I want canonical AST hashing for view artifacts so that any change to a schema produces a detectable and verifiable hash change.

Requirements:

• R1: Define the canonical AST normalization rules (ordering, whitespace, comments stripped)
• R2: Implement hash_artifact(ast) -> SHA-256 over the normalized form
• R3: Hash must be deterministic across platforms (byte-exact canonical form)
• R4: Integrate hashing into the Wesley compile pipeline so every artifact gets a hash
• R5: Store hashes in the IR output

Acceptance Criteria:

• AC1: hash_artifact() produces identical hashes for semantically identical schemas
• AC2: Reordering fields in source produces the same hash (canonical ordering)
• AC3: Adding a comment does not change the hash
• AC4: Changing a type name does change the hash
• AC5: Hashes appear in Wesley IR output

Definition of Done:

• Code reviewed and merged
• Tests pass (CI green)
• Documentation updated (if applicable)

Scope: AST normalization, hashing, IR integration.
Out of Scope: Hash chain pinning (T-10-7-2), schema evolution, proof objects.

Test Plan:

• Goldens: Hash values for a suite of known schemas
• Failures: n/a (hashing is total)
• Edges: Empty schema, schema with only comments, schema with maximum nesting depth
• Fuzz/Stress: Property test: hash(normalize(a)) == hash(normalize(b)) when a and b are syntactic variants

Blocked By: none
Blocking: T-10-7-2

Est. Hours: 5h
Expected Complexity: ~350 LoC

T-10-7-2: Schema Hash Chain Pinning (#193)

User Story: As an operator replaying a simulation, I want schema hashes pinned in receipts so that I can verify the exact schema version used at each tick.

Requirements:

• R1: Define the hash chain format: H(n) = SHA-256(H(n-1) || artifact_hash(n))
• R2: Record hash chain entries in tick receipts
• R3: Verification function: given a receipt and the schema artifacts, recompute and compare
• R4: Handle the genesis case (first schema, no prior hash)

Acceptance Criteria:

• AC1: Tick receipts include a schema_hash_chain field
• AC2: verify_schema_chain(receipts, artifacts) -> bool returns true for valid chains
• AC3: Tampering with a schema artifact causes verification failure
• AC4: Chain works across schema upgrades (new schema extends the chain)

Definition of Done:

• Code reviewed and merged
• Tests pass (CI green)
• Documentation updated (if applicable)

Scope: Hash chain computation, receipt integration, verification.
Out of Scope: Chain storage backend, pruning old chain entries.

Test Plan:

• Goldens: Hash chain values for a known sequence of schema versions
• Failures: Tampered artifact, missing chain entry, out-of-order entries
• Edges: Single-schema chain (genesis only), rapid schema changes (10 changes in 10 ticks)
• Fuzz/Stress: n/a

Blocked By: T-10-7-1
Blocking: none

Est. Hours: 4h
Expected Complexity: ~250 LoC

T-10-7-3: SchemaDelta Vocabulary (#194)

User Story: As a schema author, I want a read-only schema delta vocabulary so that I can preview what would change before applying a schema migration.

Requirements:

• R1: Define SchemaDelta type with variants: AddField, RemoveField, ChangeType, RenameField, AddEntity, RemoveEntity
• R2: Implement diff(old_ir, new_ir) -> Vec<SchemaDelta>
• R3: Implement wesley patch --dry-run that prints deltas without applying them
• R4: Output format is human-readable and machine-parseable (JSON lines)

Acceptance Criteria:

• AC1: diff() correctly identifies all six delta variants
• AC2: wesley patch --dry-run prints deltas and exits without modifying anything
• AC3: JSON lines output is parseable by jq
• AC4: Tests cover each delta variant individually and in combination

Definition of Done:

• Code reviewed and merged
• Tests pass (CI green)
• Documentation updated (if applicable)

Scope: Delta types, diff function, dry-run CLI.
Out of Scope: Apply/migrate logic, rollback, three-way merge.

Test Plan:

• Goldens: Delta output for known schema pairs
• Failures: Diffing identical schemas (should produce empty delta list)
• Edges: Schema with only renames, schema with only additions, schema with only deletions
• Fuzz/Stress: n/a

Blocked By: none
Blocking: none

Est. Hours: 5h
Expected Complexity: ~350 LoC

T-10-7-4: Provenance as Query Semantics (#198)

User Story: As a simulation analyst, I want provenance tracking built into query semantics so that every query result carries proof of its derivation.

Requirements:

• R1: Define tick directive that annotates a query with the simulation tick it refers to
• R2: Define proof object structure (references to source data, transformations applied)
• R3: Implement deterministic cursors that can be replayed to reproduce the query result
• R4: Proof objects reference schema hash chain entries (from T-10-7-2)

Acceptance Criteria:

• AC1: Queries with @tick(n) return results scoped to tick n
• AC2: Query results include a proof object with derivation chain
• AC3: Replaying the cursor from the proof object produces an identical result
• AC4: Proof objects include schema hash chain reference

Definition of Done:

• Code reviewed and merged
• Tests pass (CI green)
• Documentation updated (if applicable)

Scope: Tick directive, proof objects, deterministic cursors.
Out of Scope: Proof verification UI, proof compression, cross-simulation provenance.

Test Plan:

• Goldens: Proof object contents for a known query at a known tick
• Failures: Query at a tick that doesn't exist, query with invalid cursor
• Edges: Query at tick 0 (genesis), query spanning a schema change boundary
• Fuzz/Stress: n/a

Blocked By: T-10-7-2
Blocking: none

Est. Hours: 6h
Expected Complexity: ~450 LoC