Implement generic approval runtime

docs/APPROVALS_DOMAIN_BOUNDARY.md

@@ -1,44 +1,50 @@
-# Approvals Domain Boundary
+# Approvals domain boundary and operations
 
-## Purpose
+Approvals owns generic, reusable sign-off chains. A request freezes an exact
+module-owned subject revision, ordered steps, eligible actor selectors,
+required counts, rejection behavior, due dates, signature requirements,
+separation-of-duties rules, and policy references.
 
-Generic approval and sign-off chains with delegation, substitution, four-eyes principle, escalation, and signatures.
+Approvals does not own the subject's business state. A Campaign remains a
+Campaign and a Decision remains a Decision. Consumers call
+`approvals.requests.check_approved` with the exact subject identity and version
+before performing their consequential transition. A previously approved
+request cannot authorize a changed subject revision.
 
-## Owns
+## Actor and decision semantics
 
-- approval requests
-- sign-off chains
-- delegation and substitution facts
-- four-eyes constraints
-- escalation state
-- signature references
+Selectors can target an account, group, role, function assignment, or any
+authenticated account. They are evaluated against trusted principal claims.
+Delegated decisions are accepted only when the principal already carries the
+matching acting-for account. The actual and represented account plus the
+trusted delegation identifier are retained.
 
-## Does Not Own
+Requests can prohibit requester self-approval and can require distinct actors
+across steps. Each decision is append-only, reasoned, optimistic-concurrency
+protected, and idempotent. Signature-required steps store a provider-owned
+signature reference; Approvals does not implement document signing or key
+custody. A fail-fast rejection ends the request. Due steps can enter an
+explicit escalated state without silently changing their outcome.
 
-- module-specific business decisions
-- workflow orchestration engine
-- identity and RBAC primitives
+## Recovery and scale-out
 
-## Integration Candidates
+All API and worker nodes use the logically shared database. Back up and restore
+these tables as one consistency unit:
 
-- workflow
-- audit
-- files
-- notifications
+- `approval_request_revisions`
+- `approval_decision_records`
+- `approval_lifecycle_events`
+- `approval_replays`
 
-## Seed State
+After restore, verify one current revision per tenant/request, contiguous event
+sequences, unique actor decisions per step, decision receipt hashes, and exact
+subject bindings. Consumers must re-run `check_approved`; they must not infer
+approval from cached UI state. Before destructive retirement, snapshot the
+database and reconcile every module object that retains an Approval reference.
 
-The current repository state is intentionally small:
+## Optional integrations
 
-- module manifest and entry point
-- tenant-level permission definitions
-- manager and viewer role templates
-- documentation topic describing the module boundary
-- Gitea issue workflow templates
-- manifest contract test
-
-No runtime API, database model, migration, WebUI route, or navigation item is registered yet. The first implementation slice should preserve the boundary above and only add user-visible surfaces once the workflow model is clear.
-
-## First Implementation Slice
-
-Define reusable approval request, step, actor, delegation, substitution, and decision result contracts for consuming modules.
+Workflow Engine may wait for completion and Notifications may announce an
+assignment, due date, escalation, or outcome. Audit may retain additional
+cross-domain evidence. Policy may provide chain templates. These integrations
+use capabilities and events; none reads Approval tables directly.