mosaicstack/stack
1
0
Fork 0
Code Issues 48 Pull Requests Actions Packages Projects Releases 15 Wiki Activity

Runtime-neutral Mos identity and fenced cross-harness failover #754

New Issue
Open
opened 2026-07-14 17:25:10 +00:00 by jason.woltje · 0 comments
jason.woltje commented 2026-07-14 17:25:10 +00:00
Owner
Copy Link

Parent context: Tess #706-#711 and jarvis-brain runtime-portability #53-#56.

Objective

Make Mos a logical Mosaic identity that can move safely among Claude Code, Pi, Codex, and future harnesses while preserving canonical mission state, communication binding, authority, and exactly-once effects. Runtime/provider adapters remain replaceable; Mosaic Gateway remains the policy/audit boundary.

Qualification basis

Independent Sol/Pi review at origin/main d0771835: 124/124 focused tests passed, typecheck 42/42, lint 23/23, format PASS, CI 1796 green, but current Tess capability is replacement/rebinding rather than identity-continuous failover. Existing gaps: no logical Mos identity independent of harness session IDs; no exclusive connector lease or fencing epoch; no stale-holder rejection; no normalized Claude/Pi/Codex checkpoints; coordination is in-memory; tmux drops runtime idempotency keys; no cross-harness fault/rollback E2E.

Work packages

  1. Logical identity and security fencing — server-derived tenant/logicalAgentId/connectorId/harness/leaseEpoch/scopes/expiry; signed or MAC-bound execution grant; stale, forged, expired, and cross-tenant grants denied and audited.
  2. Durable connector lease — PostgreSQL CAS lease with monotonic epoch, TTL/heartbeat, explicit takeover, and gateway rejection of stale holders. One communication binding consumer at a time.
  3. Canonical handoff/checkpoint — versioned, sealed schema with mission/task/git refs, checkpoint digest, causal sequence, capability requirements, pending/ambiguous operation refs, source/destination acknowledgements; secrets and raw harness transcripts excluded.
  4. Exactly-once connector journal — durable operation IDs/receipts, idempotency propagated through every adapter, Matrix transaction mapping, receiver-side dedupe for tmux or replacement transport, ambiguous effects held for authorized reconciliation.
  5. Harness adapters — Claude Code, Pi, and Codex export/import normalized checkpoint and heartbeat/lease state behind AgentRuntimeProvider/IProviderAdapter; no harness schema in core.
  6. Failover/rollback E2E — move one Mos identity Claude Code → Pi → Codex → Claude Code; inject crashes before/after lease transfer, checkpoint persistence, send, and acknowledgement; prove stale connector fencing, no duplicate side effects, canonical state continuity, and exercised rollback.
  7. Gateway ADR — evaluate LiteLLM ChatGPT-subscription OAuth and Bifrost virtual-key/budget/failover concepts as optional egress adapters only. Cover terms, credential lifecycle, revocation, tenant mapping, budgets, and failover semantics. Neither becomes Mosaic identity/core or receives direct channel calls.

Security invariants

  • Gateway is the single API/policy surface.
  • Authority is granted server-side; handoff authority requests are not self-authorizing.
  • Connector credentials never enter handoffs/checkpoints/logs.
  • Monotonic fencing rejects old harnesses after takeover.
  • One channel consumer per binding. Shadow canaries have ingress disabled.
  • Fail closed on provider/lease/checkpoint uncertainty.

Acceptance gate

A real Discord/CLI-bound Mos identity survives Claude Code → Pi → Codex → Claude Code transfer and rollback with the same canonical mission/task state; each transfer has durable lease/checkpoint/receipt evidence; stale connectors cannot reply or execute tools; no duplicated outbound reply/tool effect occurs; security abuse tests, crash injection, independent code/security review, CI, docs, and operational rollback all pass.

Known adjacent cleanup

Reconcile stale Tess ledgers (M4/M5 status and #707-#709 issue state), operationalize production provider registration, replace in-memory Mos coordination, and remove tmux idempotency loss. Keep these traceable rather than silently folding them away.

Parent context: Tess #706-#711 and jarvis-brain runtime-portability #53-#56. ## Objective Make Mos a logical Mosaic identity that can move safely among Claude Code, Pi, Codex, and future harnesses while preserving canonical mission state, communication binding, authority, and exactly-once effects. Runtime/provider adapters remain replaceable; Mosaic Gateway remains the policy/audit boundary. ## Qualification basis Independent Sol/Pi review at origin/main d0771835: 124/124 focused tests passed, typecheck 42/42, lint 23/23, format PASS, CI 1796 green, but current Tess capability is replacement/rebinding rather than identity-continuous failover. Existing gaps: no logical Mos identity independent of harness session IDs; no exclusive connector lease or fencing epoch; no stale-holder rejection; no normalized Claude/Pi/Codex checkpoints; coordination is in-memory; tmux drops runtime idempotency keys; no cross-harness fault/rollback E2E. ## Work packages 1. **Logical identity and security fencing** — server-derived tenant/logicalAgentId/connectorId/harness/leaseEpoch/scopes/expiry; signed or MAC-bound execution grant; stale, forged, expired, and cross-tenant grants denied and audited. 2. **Durable connector lease** — PostgreSQL CAS lease with monotonic epoch, TTL/heartbeat, explicit takeover, and gateway rejection of stale holders. One communication binding consumer at a time. 3. **Canonical handoff/checkpoint** — versioned, sealed schema with mission/task/git refs, checkpoint digest, causal sequence, capability requirements, pending/ambiguous operation refs, source/destination acknowledgements; secrets and raw harness transcripts excluded. 4. **Exactly-once connector journal** — durable operation IDs/receipts, idempotency propagated through every adapter, Matrix transaction mapping, receiver-side dedupe for tmux or replacement transport, ambiguous effects held for authorized reconciliation. 5. **Harness adapters** — Claude Code, Pi, and Codex export/import normalized checkpoint and heartbeat/lease state behind AgentRuntimeProvider/IProviderAdapter; no harness schema in core. 6. **Failover/rollback E2E** — move one Mos identity Claude Code → Pi → Codex → Claude Code; inject crashes before/after lease transfer, checkpoint persistence, send, and acknowledgement; prove stale connector fencing, no duplicate side effects, canonical state continuity, and exercised rollback. 7. **Gateway ADR** — evaluate LiteLLM ChatGPT-subscription OAuth and Bifrost virtual-key/budget/failover concepts as optional egress adapters only. Cover terms, credential lifecycle, revocation, tenant mapping, budgets, and failover semantics. Neither becomes Mosaic identity/core or receives direct channel calls. ## Security invariants - Gateway is the single API/policy surface. - Authority is granted server-side; handoff authority requests are not self-authorizing. - Connector credentials never enter handoffs/checkpoints/logs. - Monotonic fencing rejects old harnesses after takeover. - One channel consumer per binding. Shadow canaries have ingress disabled. - Fail closed on provider/lease/checkpoint uncertainty. ## Acceptance gate A real Discord/CLI-bound Mos identity survives Claude Code → Pi → Codex → Claude Code transfer and rollback with the same canonical mission/task state; each transfer has durable lease/checkpoint/receipt evidence; stale connectors cannot reply or execute tools; no duplicated outbound reply/tool effect occurs; security abuse tests, crash injection, independent code/security review, CI, docs, and operational rollback all pass. ## Known adjacent cleanup Reconcile stale Tess ledgers (M4/M5 status and #707-#709 issue state), operationalize production provider registration, replace in-memory Mos coordination, and remove tmux idempotency loss. Keep these traceable rather than silently folding them away.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
jason.woltje
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#754
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?