Enforce governed FAVA recall visibility and atomic supersession

[timeleft--]

Parent

• https://github.com/MachineWisdomAI/WisdomLoop/issues/38

Canonical boundary

FAVA Trails is canonical for governed decisions, observations, validation, and lineage. It is not the primary operational working-context store; that role belongs to OpenViking.

What to build

Make ordinary shared FAVA recall return governed current truth: approved records that have not been replaced by an approved successor. Keep draft/proposed authoring retrieval explicit and narrow, and keep human/operator archaeology explicit for historical statuses and superseded records. Do not describe either mode as a general working-memory system.

Correct replacement semantics at the same public boundary. Proposing a replacement must not hide an approved original. The original becomes historical only when the replacement is durably approved. Approval provenance must distinguish explicit human approval from LLM advisory review.

Apply the contract consistently to single-scope recall, multi-scope recall, MCP schemas, and operator-facing consumers such as Rich Views.

Acceptance criteria

• Default shared recall returns only approved, current governed records.
• Default shared recall excludes draft, proposed, rejected, tombstoned, and superseded records.
• Draft/proposed retrieval is explicit, scoped to authoring/review, and never presented as primary operational memory.
• One agent cannot claim another agent's identity or retrieve private authoring records.
• Explicit operator/history mode can retrieve selected lifecycle statuses and superseded records for archaeology.
• Single-scope and multi-scope recall enforce the same visibility semantics.
• Proposing a replacement leaves the approved original visible as current.
• Approving a replacement atomically makes the replacement current and original historical.
• Failed approval/persistence leaves the original current without half-applied supersession.
• Approval provenance distinguishes explicit human approval from advisory LLM review.
• MCP schemas and guidance explain governed, authoring, and history modes without calling FAVA the operational working-context store.
• Tests cover identities, lifecycle statuses, both recall scopes, proposal, approval, and interrupted persistence.

Blocked by

None. This is independent FAVA governance work and does not block the laptop pilot.

Delivery verification — 2026-09-07

All criteria are satisfied by merged governance PR #93 (0f4228127495c12e202f6aaf4c7cc49ba71586c5), reader PR #92 (043902c40e57a221dca7712021a47b9d70af785e), and compatible MCP registration PR #94 (d8a09dc01bc62451ece0849463972cc4d26ebac8). Independent code review and the815-test combined suite cover ordinary and operator identities, all lifecycle statuses, single/multiple scopes, draft ownership, delayed supersession, durable approval, interrupted persistence/recovery, and distinct human versus LLM approval provenance. Reader behavior and installed-package MCP protocols were independently checked.

The private gateway now uses an explicit ordinary process identity with operator mode disabled. Real private acceptance verified approved-only recall, hidden drafts, own-authoring access, denied identity spoofing/history/rollback, real configured LLM review, approved readback, and ordinary sync. The connected FAVA tool retrieved the approved synthetic record after a gateway-only restart. This delivery does not perform or approve the separately tracked destructive duplicate-data migration (#74).