Assistant/docs/CONTINUITY_ACTION_ENVELOPE_PROPOSAL.md

Continuity Action Envelope Proposal

Status: ACCEPTED — recorded by ADR-0003

Task: ARCH-000001, revision 1

Base: 543b93105bacc8617ece73d9879410ffb4d1d586

Objective

Enable one explicit Creator-initiated Continuity state transition without allowing the UI, gateway, Commit Runtime, or another module to write Continuity canonical storage directly.

Required path:

Creator session → owner validation → live Authority validation → durable Commit → Executor → Continuity owner CAS → durable attempt/outcome → reconciliation

Observed architecture gaps

1. commit.ActionProposal.Target is only a work.TaskTarget. It can express the live Work justification but cannot identify a Continuity subject, expected Prospective revision, or requested transition without conflating semantic identifiers.
2. commit.authorized_actions persists only action ID, intent ID, state, and revision. The immutable proposal, grant/scope evidence, operation subject, expected revision, and operation parameters are lost after restart.
3. Commit Runtime exposes authorization and terminal-attempt insertion, but no execution endpoint invokes commitdomain.Execute with a production Executor.
4. The only Executor is the deterministic test adapter. There is no remote Continuity executor with idempotent delivery and read-only reconciliation.
5. Continuity persistence uses an upsert. A mutation command needs an owner-local atomic compare-and-swap on ID, owner Principal, current state, and expected revision.
6. Creator authentication is not consumed by Commit Runtime. Actor, Principal, and Grant must be constructed from a validated session/server policy, not accepted as trusted browser fields.
7. Authority V1 validates an active grant and scope but does not constrain CapabilityID + Operation. A non-empty arbitrary operation currently passes domain validation.
8. V1 does not specify which Prospective transition a Creator may request, what evidence is required, or whether the command changes only Prospective state or also Commitment state.

Proposed minimum contracts

Durable authorized envelope

Persist an immutable envelope before execution with:

• AuthorizedActionID, ActionIntentID, Actor, Principal;
• Authority grant ID and revision, Scope ID;
• Work justification target: Task ID, Goal ID, Scope ID, revision;
• operation capability and typed operation name;
• typed operation subject: ProspectiveItemID and expected Prospective revision;
• requested target state and optional evidence reference;
• authorization time and envelope revision.

The Work target remains justification. The ProspectiveItem remains the operation subject. They must not reuse one identifier field.

Continuity owner command

Continuity Runtime should accept only an internal typed executor request containing the committed envelope identity and operation subject. The owner must:

• validate the permitted state transition in Continuity domain code;
• atomically update with WHERE id = ? AND owner_principal_id = ? AND state = ? AND revision = ?;
• increment revision exactly once;
• record or return an idempotency receipt keyed by ActionIntentID;
• return conflict for stale state/revision without mutation.

Executor and reconciliation

The isolated Commit Runtime owns a Continuity HTTP Executor adapter. A timeout records UNKNOWN_OUTCOME; it never blindly retries. Reconciliation performs a read-only receipt/result query by ActionIntentID and creates a new attempt record.

Creator command boundary

The public Creator command endpoint must:

• validate the bounded Creator session through Identity;
• derive Actor and Principal server-side;
• use a server-selected Grant policy;
• require an explicit Work justification target and its current revision;
• require the selected ProspectiveItem and current revision;
• never accept arbitrary capability or operation strings from the browser;
• return committed action/attempt identities and outcome state.

Accepted decisions

1. The first allowed transition is DELIVERED → SATISFIED with a required evidence reference.
2. Commit stores the full immutable authorized envelope and typed operation subject.
3. Continuity owns the idempotency receipt keyed by ActionIntentID.
4. The only initial mapping is Creator grant + capability continuity-transition + operation satisfy-delivered.
5. The operation changes only ProspectiveItem; it does not automatically change Commitment.

Proposed implementation slices after acceptance

1. Accepted ADR/registry-compatible contract decision and Tier E guardrail review.
2. Commit envelope contract plus Commit-owned migration and restart recovery tests.
3. Continuity transition command, CAS persistence, idempotency receipt, and owner tests.
4. Commit Executor/reconciler adapter with injected timeout and no-blind-retry tests.
5. Session-authenticated Creator command orchestration with revoked/stale/adversarial tests.
6. Gateway allowlist and explicit confirmation UI.

Resolution

The architecture gap is resolved by ADR-0003. Implementation proceeds under separate Tier D task packets. Read-only Creator APIs and the deployed console remain valid and operational during delivery.