[spec][Trinity S08] Define durable sessions, memory and provenance using existing organism contracts #3570

Parent epic: gHashTag/trinity#988

Work package: S08. Canonical authoring repository: gHashTag/t27. Proposed new paths become canonical only after S01 records ownership; extend existing domain specifications in place.

Problem

The organism proposal already exists, but bodyless declarations and undeclared test helpers are not a working persistence model. Trinity sessions/checkpoints and the separate experimental tmem contracts must have an explicit compatibility boundary.

Existing work to reuse

• specs/organism/mozg.tri
• specs/organism/dna.tri
• specs/brain/unified_state.t27
• specs/memory/

Related existing issues (not replaced):

• chore(spec): propose organism .tri specs (mozg + dna) upstream in t27 trinity#604
• [spec] specs/memory/tmem: Trinity Memory contracts (types, Bridge, TensorPack, Stream Compute, Conformance Lab, Edge Demo) #3561
• Zig-бэкенд: сигнатуры без тела делают вывод некомпилируемым (0 из 9 спек) #3472

Scope and deliverables

• Map existing mozg/dna concepts to actual session, memory, checkpoint, compaction and provenance fields; migrate/extend canonical specs instead of copying them.
• Specify versioned serialization, atomic writes, recovery after interruption, stale/invalid records, retention and source/compiler ancestry.
• Decide how tmem fits as an optional adapter to existing state contracts; reuse its issue and APIs rather than reproducing the experiment.
• State which data is private and which sanitized evidence can be published to Queen.

Acceptance criteria

• Save/resume and crash-recovery fixtures preserve required state across restart; corrupt or incompatible data fails visibly.
• Compaction preserves required tool/result and permission context; truncation/replay cannot fabricate a completed action.
• Provenance links are verified by hashes and invalid ancestry is rejected.
• Negative tests use explicit implementations of their helpers; declaration-only compatibility remains unverified until target compile/runtime evidence exists.

Every executable claim must name its source/spec/compiler/dependency revisions, actual command, generated artifact and checked runtime result. Catalog presence, source parsing, typecheck.ok, an empty test set or a module shell cannot substitute for this evidence. Declared/unsupported behavior must remain labeled.

Dependencies

#3563
#3564
#3569

Existing issue references are reuse/blocker links, not new ownership of their implementation. Assess the applicable upstream blocker before enabling a capability.

Audited implementation anchors

Trinity baseline: 03ae2f93f5af2fd4fa23e4c613a3c0e19ac51530; t27 baseline: bff21b85b206a0dd367876343e56dcd8312d81ba. Refresh the pinned inventory before implementing if upstream changed.

• src/tri-api/session_store.zig
• src/tri-api/checkpoint.zig
• src/tri-api/memory.zig
• src/tri-api/context.zig

Boundary

• specs/brain/unified_state.t27
• specs/organism/dna.tri
• specs/organism/mozg.tri
• src/tri-api/checkpoint.zig
• src/tri-api/context.zig
• src/tri-api/memory.zig
• src/tri-api/session_store.zig