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