90 lines
5.1 KiB
Markdown
90 lines
5.1 KiB
Markdown
# 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.
|