Skip to content

Expose restart-stable occurrence relation readings #854

Description

@flyingrobots

1. Background Context

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

Current scope and disposition: Implement bounded public occurrence rehydration and causal-pair readings after restart. Entity retention already works; do not block on the independent #869 proof.

Discussion evidence, including corrections:

Additional source requirements/context:

Required boundary:
Provide a public, storage-neutral occurrence reading that:

  • accepts opaque occurrence references plus a named Lane/basis;
  • recovers the referenced occurrences after process restart;
  • reports same | before | after | concurrent from retained causal context;
  • reports deterministic ordering separately and labels it explicitly non-causal;
  • returns bounded evidence and completeness for the requested occurrence pair; and
  • refuses missing, malformed, unreachable, or wrong-Lane references with typed outcomes.

The TypeScript API owns the runtime-backed domain objects. CLI/MCP adapters may project canonical JSON, but consumers must not parse occurrence ids, Git object ids, refs, private patch layout, or process-local objects.

2. Problem Description

Implement bounded public occurrence rehydration and causal-pair readings after restart. Entity retention already works; do not block on the independent #869 proof.

Historical source report; the current disposition above supersedes obsolete claims:
An admitted entity.add write returns a runtime-backed EntityOccurrence in-process, but the public JSON boundary retains only its opaque id and subject. After the process exits, an independent consumer cannot recover the historical occurrence or ask Git WARP for its causal relation to another occurrence. The consumer would have to parse private coordinates, inspect storage, or mistake deterministic order for causality.

Observed against origin/main at 7466fe667589aa7f58081f5a1110bc1ece276280:

  1. two independent writers admitted distinct entity.add intents through the public CLI;
  2. both exact payloads remained readable after all writer processes exited;
  3. git warp occurrence relate ... --json failed with E_USAGE: Unknown command: occurrence.

The RED is therefore at the public restart/rehydration boundary, not at admission or payload retention.

2b. Proposed Solution

Implement bounded public occurrence rehydration and causal-pair readings after restart. Entity retention already works; do not block on the independent #869 proof.

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

  • Two independently admitted occurrences survive process restart and remain recoverable through the public boundary.
  • Their pairwise relation remains concurrent when retained causal context says so, regardless of process or deterministic display order.
  • Reversing the pair preserves causality and reverses only deterministic order.
  • The result names its bounded basis, carries support for both requested occurrences, and makes its completeness claim explicit.
  • Missing, malformed, unreachable, and wrong-Lane occurrence references fail closed with typed evidence.
  • Public TypeScript and CLI integration tests exercise restart; CLI documentation and generated capability surfaces agree.

2e. Test Plan

Golden: Run known-answer queries against the public provider/reading boundary.

Edges: Empty/disconnected graphs, duplicate neighbors, missing facts, cursor boundaries and basis changes.

Known failure modes: Refusal stays typed; cancellation and failing providers cannot return a falsely complete reading.

Fuzz and stress: Bounded adversarial generators with deadlines; verify termination and demand without collecting the whole source.

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.

3. Prerequisites

No unsatisfied open-issue prerequisite established by this review. This is not proof that an unresolved design or external readiness condition is satisfied.

4. Scope

In: Implement bounded public occurrence rehydration and causal-pair readings after restart. Entity retention already works; do not block on the independent #869 proof.

Source scope and exclusions:
This issue does not define application event semantics, Continuum profiles, raw source custody, cross-runtime interoperability, occurrence enumeration, or a general substrate migration.

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 queries.

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. git-warp contributors and consumers rely on this domain’s supported contract and reproducible evidence.

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.

Activity

  1. added
    type:featureNew capability or product behavior.
    priority:asapImmediate release pressure.
    status:activeSomeone is actively working this issue.
    area:apiPrimary work area: api.
    priority:nextNext in line after active work.
    status:availableOpen and available for prioritization; not blocked or actively in progress.
    and removed
    priority:asapImmediate release pressure.
    status:activeSomeone is actively working this issue.
    on Aug 24, 2026
  2. added this to the v19.2.0 milestone on Aug 25, 2026
  3. flyingrobots commented on Aug 25, 2026

    @flyingrobots
    MemberAuthor

    Release-scope reconciliation: this remains a valid next-line API feature, but it is explicitly outside the v19.1.0 performance/release-determinism thesis. Moving it to v19.2.0 as priority:next/status:available keeps the current performance release guard honest without weakening or closing this work.

  4. modified the milestones: v19.2.0, v19.3.0 on Sep 7, 2026
  5. self-assigned this
    on Oct 1, 2026
  6. modified the milestones: v19.3.0, v20.1.0 on Oct 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:apiPrimary work area: api.domain:queriespriority:nextNext in line after active work.status:availableOpen and available for prioritization; not blocked or actively in progress.template:featureCard template: featuretype:featureNew capability or product behavior.

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions