Repository navigation
Files Changed: persist atomic receipt and assessment records #1088
Description
Important
Problem — #1076 couples durable receipt schema, operation publication, and assessment history too broadly for one independently verifiable implementation.
Approach — Establish the root-owned SQLite schema and a typed storage boundary that atomically publishes immutable operation/receipt facts and appends assessments.
Scope — in: migrations, typed tables, operation lifecycle, receipt ordering, assessment history, restart behavior · out: evidence files, quotas, legacy adapters, retention.
Assumptions — #1075 lineage roots and typed edges are available.
Acceptance Criteria
- A root can atomically publish one operation group and all its immutable receipts, or publish none.
- Receipt creation sequence is immutable and unique within a root.
- Assessments append confidence, net state, evidence state, revision, and expiry without rewriting receipt facts.
- Database restart preserves committed groups, receipts, and assessment history.
Testing Decisions
Extend database migration and session lifecycle coverage with transaction rollback, multi-receipt ordering, append-only assessments, and restart cases.
Key Decisions
Operation groups progress through prepared, evidence-ready, and committed states; this slice persists the state machine but does not write evidence.
Constraints & Invariants
Ledger infrastructure is internal and emits no session-visible mutation receipt. No browser or legacy wire surface changes here.
Prior Art
#1075 lineage persistence; existing session database migration conventions; #1076 design record.
Activity