Enforce bounded operation guardrails

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a028de-e2c8-7732-8521-46a7fc5db82f

INTENT.md

@@ -1,7 +1,7 @@
 ---
 domain: capabilities
 repo: activity-core
-updated: "2026-08-18"
+updated: "2026-08-23"
 ---
 
 # INTENT
@@ -35,8 +35,23 @@ activity-core answers three questions and only three:
 2. **What** — given current org context, what work must be created?
 3. **Where** — which repo, service, or agent should each work item land?
 
-It does not execute the work. It does not track task lifecycle. It does not
-manage projects or campaigns. Those belong to other systems.
+It does not execute general domain work. It does not track workplan, tracker,
+or human task lifecycle. It does not manage projects or campaigns. Those belong
+to other systems.
+
+Two narrow runtime mechanisms support the three answers without adding a
+fourth responsibility:
+
+- an `ops_run` is a durable delivery record for one automation fire. Its
+  open/claim/lease/outcome state is runtime operations data, not a Task,
+  Commitment, assignment, or project record; and
+- a code-registered **bounded operation** may perform the declared maintenance
+  outcome directly only under ACT-ADR-007: fixed/bounded targets, explicit
+  mutation intent, operation-specific idempotency/retry rules, routed
+  credentials, and mandatory non-secret evidence.
+
+Neither mechanism is permission to accept arbitrary commands, execute agent
+loops, edit repositories, or grow task/project semantics here.
 
 This constraint is intentional and load-bearing. An orchestrator that also
 stores task state, manages project phases, or executes work becomes a God object
@@ -71,6 +86,14 @@ It is an event loop governed by declarative rules and LLM instructions:
   records the spawn event as an audit trail — not as the authoritative task
   record. Downstream **executors** (per-repo workers, agent-harness) perform
   the work.
+- **Runtime delivery**: internal automation work may also be represented by a
+  claimable `ops_run`. activity-core owns its delivery lease and normalized
+  outcome evidence, while Glas/reins or per-repo workers perform the domain
+  work.
+- **Bounded operations**: a small code-owned registry permits maintenance whose
+  whole purpose is a fixed, reviewable operation such as controlled SBOM ingest,
+  package retention, or backup. Context resolution remains read-only; the
+  mutation runs in an explicit workflow stage governed by ACT-ADR-007.
 
 ---
 
@@ -89,7 +112,8 @@ It is an event loop governed by declarative rules and LLM instructions:
 | Mixed coordination read model (until retirement) | state-hub (STATE-WP-0079 strangler; not a permanent peer) |
 | Project and initiative management | `prj-*` repos + GOAL.md |
 | Repository capability profiling | repo-scoping |
-| Execution of domain work | per-repo workers / rein-aharness claiming ops_runs |
+| General execution of domain work | Glas/reins and per-repo workers claiming `ops_runs` |
+| Bounded maintenance operation implementation | activity-core only for ACT-ADR-007 registered operations; otherwise platform owner |
 | Event broker infrastructure | NATS (org infrastructure) |
 
 activity-core does not compete with those owners. It **schedules and evaluates**;
@@ -115,9 +139,11 @@ When activity-core is in place, Bernd can:
   domain standards" — and have an LLM agent make that judgement reproducibly.
 - Set up a one-off reminder — "on 2026-09-01, create a review task for the
   Q3 architecture retrospective" — without managing a separate reminder system.
-- Observe a complete audit trail of every activation: what triggered it, what
-  rules matched, what tasks were created, and (for instructions) what prompt
-  and model produced the output.
+- Observe a bounded, non-secret audit trail of every activation: what triggered
+  it, what definition version and context were used, what rules matched, what
+  outputs were emitted, and (for instructions) the model, validation result,
+  and SHA-256 hash of the rendered prompt. The hash is an integrity reference,
+  not storage or guaranteed reconstruction of the raw prompt.
 
 The Coulomb org gains **structured, auditable automation** that scales with the
 number of repos and domains without scaling the coordination burden on Bernd.
@@ -136,10 +162,15 @@ instructions when the condition is fully expressible. Instructions are reserved
 for genuine judgement cases. This keeps most automation fast, cheap, testable,
 and auditable.
 
-**No task state ownership.** activity-core holds a spawn audit trail, not task
-state. The moment it starts tracking whether tasks are complete, blocked, or
-re-assigned, it has become a task database — that belongs to issue-core or
-fleet work-record systems, not here.
+**No work-item state ownership.** activity-core holds spawn audit plus runtime
+delivery state for `ops_runs`, not Task/Commitment state. The moment it starts
+tracking whether workplan or tracker tasks are assigned, blocked, completed,
+dependent, or re-assigned, it has become a task database — that belongs to
+issue-core or fleet work-record systems, not here.
+
+**Explicit bounded operations only.** Context adapters read. A mutation may run
+only through the ACT-ADR-007 registry and workflow phase; unknown operation
+names and incomplete safety declarations fail during definition admission.
 
 **Safe sinks for internal findings.** Automated internal coordination must not
 default to silent Forgejo/Gitea issues. Prefer State Hub progress / work-record