Prove session-event retention across authority paths #869

1. Background Context

Source: git-warp #869. Audited against main 94b40dac64034cd8caab9bb05efe14a0c22bd735. Template: feature; work type: type:maintenance.

Current scope and disposition: The CLI surfaces needed by this proof already exist. Local conformance was reported complete, but the owner explicitly records #870 as preventing publication; retain it until bounded browser shutdown clears that gate. Do not add #854 occurrence relations, which this card excludes.

Discussion evidence, including corrections:

• Comment ABQmg29A

2. Problem Description

The CLI surfaces needed by this proof already exist. Local conformance was reported complete, but the owner explicitly records #870 as preventing publication; retain it until bounded browser shutdown clears that gate. Do not add #854 occurrence relations, which this card excludes.

Historical source report; the current disposition above supersedes obsolete claims:
Prove through the public v19 CLI that an opaque, complete consumer event entity survives process restart and remains correctly evidenced across both supported authority profiles:

• direct admission into an authoritative worldline;
• candidate admission into independent Strands followed by exact-frontier settlement.

2b. Proposed Solution

The CLI surfaces needed by this proof already exist. Local conformance was reported complete, but the owner explicitly records #870 as preventing publication; retain it until bounded browser shutdown clears that gate. Do not add #854 occurrence relations, which this card excludes.

Historical approach to reconcile:
Current architecture rules take precedence: parsing/encoding stays at adapters, domain concepts are runtime-backed, no trust casts are introduced, and tests run in Docker.
Prove through the public v19 CLI that an opaque, complete consumer event entity survives process restart and remains correctly evidenced across both supported authority profiles:

• direct admission into an authoritative worldline;
• candidate admission into independent Strands followed by exact-frontier settlement.

2c. Alternatives considered and rejected

No additional alternatives are recorded as decided. Reject duplicate ownership, private-import escape hatches and a broken intermediate mainline; retain original alternatives below when present.

2d. Acceptance Criteria

• The write receipt preserves application intent identity, application subject identity, graph subject identity, and causal occurrence identity without conflating them.
• One entity birth returns one patch-support witness and exact opaque bytes are recoverable by graph subject after restart.
• A candidate at an unchanged fork basis settles with the exact derived classification and complete settlement evidence.
• A second candidate from the stale common basis is obstructed with git-warp.settlement-common-basis-required on both preview and apply.
• The settled entity is visible in the target while both settled and obstructed source entities remain recoverable in their source Strands.
• Negative target readings remain basis-bound.

2e. Test Plan

Golden: Exercise the stated admission/merge or evidence contract with explicit basis and expected outcome.

Edges: Concurrent and stale bases, empty input, obstruction, plurality and repeated requests where supported.

Known failure modes: No partial publication or forced winner when the contract requires refusal/plurality.

Fuzz and stress: Deterministic multi-writer fixtures and provenance-preserving replay; keep all harness execution in Docker.

All tests and benchmarks execute in COPY-based Docker containers without host repository or Git-directory mounts. This planning audit does not claim those checks were run.

Existing evidence / proposed witnesses (retain their original temporal scope):
The conformance suite must run through public CLI process boundaries, include witnessed RED calibrations for load-bearing assertions, pass under PYTHONOPTIMIZE=1, and leave production source unchanged.

3. Prerequisites

Completion prerequisites; preparatory work may start earlier.

• #870: The implementation owner reports that the required pre-push Mermaid gate hangs on browser shutdown and prevents publication of this conformance work. This is a documented delivery prerequisite, not a general blocker on every PR.

4. Scope

In: The CLI surfaces needed by this proof already exist. Local conformance was reported complete, but the owner explicitly records #870 as preventing publication; retain it until bounded browser shutdown clears that gate. Do not add #854 occurrence relations, which this card excludes.

Source scope and exclusions:

• Do not add an occurrence-id decoder or pairwise occurrence relation command unless a named consumer claim cannot be supported by existing entity, receipt, basis, and settlement evidence.
• Do not implement consumer-specific semantic conflict or supersession rules in Git WARP.
• Do not treat process independence as candidate-Strand authority by default.

Safe intermediate state: the PR builds and passes relevant checks after its listed prerequisites; existing supported behavior remains usable. Any preparatory step must be independently mergeable.

5. Why now

Maintainer ordering: memory correctness first, supported attachments next, then land eligible PRs. Preserve this card’s existing priority unless a separately recorded scope decision changes it.

6. Risks

Main risk: implementing the historical description instead of the current runtime contract. Preserve compatibility, causal/ownership invariants and bounded behavior relevant to admission-merge.

7. Definition of Done

The issue-specific acceptance checks pass, relevant validation evidence is attached, and the issue links the coherent PR and resulting mainline integration commit. No open item is hidden in a later repair PR.

8. Stakeholders

James Ross: maintainer, assignee and acceptance owner. Graft/TTD and other consumers rely on lawful admission and witnessed merge outcomes.

9. Related Issues

No additional downstream blocker is established. Shared domain membership alone is not a prerequisite.

Historical paths, counts, release names and shell examples in source material are evidence to reconcile, not authority to restore retired documentation or run host tests.