Every ticket as the root of its provenance graph — goal, patch, approval, runs and (as the ticket-class build lands) mandate, manifestations, guarantees, journey, artifacts and children. Rendered through the <<<TicketGraphList>>> tag.
User wants the task/ticket list stored on an immutable blockchain. We ALREADY have append-only+trigger-enforced immutability (0029, verified: DELETE/identity-UPDATE refused). Research what a blockchain ADDS beyond that: (a) tamper-EVIDENT hash-chaining of ticket_events (each event carries prev-hash -> Merkle/DAG), cheap and local, vs (b) a real distributed chain (consensus, cost, telemetry concerns). Recommend the lightest design that gives cryptographic tamper-evidence without external services. DELIVERABLE: design ticket comparing hash-chain-in-sqlite vs external chain.
patch
none
approval
unapproved
runs
no runs recorded
mandate (clauses)
not yet recorded — lands with the ticket-class build
manifestations
not yet recorded — lands with the ticket-class build
guarantees
not yet recorded — lands with the ticket-class build
journey (blunders & successes)
not yet recorded — lands with the ticket-class build
artifacts (forge)
not yet recorded — lands with the ticket-class build