Expand rule actions for per-repo tasks

Add safe action interpolation and for_each binding for rule fan-out, update the weekly SBOM definition, cover the new evaluation path, and reconcile activity-core scope/workplans for the State Hub sync.

SCOPE.md

@@ -1,7 +1,7 @@
 ---
 domain: capabilities
 repo: activity-core
-updated: "2026-05-14"
+updated: "2026-06-03"
 ---
 
 # SCOPE
@@ -52,11 +52,17 @@ The two evaluation modes:
 - **Context resolution adapters**: repo-scoping (repository capability queries),
   state hub (domain and workstream state), extensible for other sources.
 - **Rule evaluator**: sandboxed AST walker for Python-like boolean expressions
-  over event attributes and resolved context. No `exec()`.
+  over event attributes and resolved context. Rule actions support safe
+  `context.*` / `event.*` interpolation and explicit `for_each` per-item
+  binding. No `exec()`.
 - **Instruction executor**: trusted-field prompt rendering, LLM call via
-  llm-connect, structured output validation, optional curator review queue.
+  llm-connect, structured output validation, optional curator review queue,
+  and deterministic report sinks.
 - **Task emission adapter**: abstraction over issue-core; current transport is
   REST; designed to migrate to NATS subscription without code changes.
+- **Report sinks**: instruction report outputs can be persisted to bounded
+  local working memory and posted as State Hub progress events. These are
+  reporting outputs, not task lifecycle ownership.
 - **Spawn audit log**: every task emission recorded with rule/instruction id,
   triggering event id, model and prompt hash (instructions), issue-core task ref.
 - **Webhook receiver**: HTTP endpoint normalising inbound Gitea/GitHub webhook
@@ -111,16 +117,57 @@ The two evaluation modes:
 
 ## Current State
 
-- **Status**: active — WP-0001 (Foundation) and WP-0002 (Triggers & Ops) complete.
-- **Implementation**: core is functional. `RunActivityWorkflow`, `TaskExecutorWorkflow`
-  (stub), PostgreSQL schema (activity_definitions, activity_runs, task_instances),
-  Temporal Schedules (cron), NATS Event Router, FastAPI admin API, Prometheus
-  metrics, and operational runbook are all implemented.
-- **Next**: WP-0003 — event type registry, rule/instruction model, task emission
-  adapter, webhook receiver, one-off `scheduled` trigger type, INTENT.md and
-  SCOPE.md rewrite (this file). Architecture established in ACT-ADR-001/002/003.
-- **Stability**: core workflow is stable; the rule/instruction layer and registry
-  are not yet implemented.
+- **Status**: active production-backed service. Foundation, triggers/ops,
+  event bridge, Railiance deployment, and the production service workplans are
+  complete. The stale March WP-0002 handoff note has been reconciled and
+  archived.
+- **Implementation**: core is functional. `RunActivityWorkflow`,
+  `TaskExecutorWorkflow` (stub), PostgreSQL schema, Temporal Schedules, NATS
+  Event Router, FastAPI admin API, Prometheus metrics, event type registry,
+  markdown ActivityDefinition parser/sync, rule evaluator, instruction
+  executor, context resolvers, issue sink, report sinks, Kubernetes deployment,
+  and operational runbook are all implemented.
+- **Operational proof**: the daily State Hub WSJF triage cutover has completed
+  far enough that activity-core is now the trusted scheduled substrate for the
+  routine report. Recent hardening fixed the State Hub SBOM resolver contract,
+  made slow LLM activity timeouts configurable, and added safe rule action
+  interpolation plus explicit `for_each` binding for per-repo SBOM staleness
+  tasks.
+- **Stability**: construction risk has shifted to operational hardening risk.
+  The full test suite passed on 2026-06-03 (`125 passed, 1 skipped`). The
+  remaining work is mostly observability, status-canon adaptation, contract
+  documentation, and broader production adoption rather than first
+  implementation.
+- **Next**: `ACTIVITY-WP-0006` — post-triage operational hardening and scope
+  alignment.
+
+---
+
+## Assessment Against Intent
+
+activity-core now matches the core intent: it answers **when** coordination
+work should happen, **what** work should be created from current org context,
+and **where** each work item should land. The daily WSJF triage is the clearest
+judgement-oriented proof point; weekly SBOM staleness is the clearest
+deterministic-rule proof point.
+
+The governing boundary still matters. activity-core should keep owning trigger
+durability, context resolution, rule/instruction evaluation, report/task
+emission, and spawn/report audit. It should not become the task lifecycle
+database, the project planner, or a general execution worker. The local
+`TaskExecutorWorkflow` remains a stub and should stay that way unless a future
+workplan explicitly rehomes execution responsibility.
+
+One boundary nuance is now explicit: activity-core may post State Hub progress
+events as a configured report sink. That is acceptable because it records the
+result of an activity-core activation; it is not ownership of State Hub state,
+task lifecycle, or workstream planning.
+
+The main drift risk is convenience creep: adding direct task tracking,
+project-phase state, or bespoke operational scripts because the Temporal
+substrate is already nearby. Future work should prefer declarative
+ActivityDefinitions, bounded context resolvers, and outbound adapters over
+new one-off control paths.
 
 ---
 
@@ -130,20 +177,19 @@ The two evaluation modes:
 [NATS JetStream]  ←  publishers: state hub, Gitea webhooks, Temporal signals, cron
        ↓
 [activity-core]   ←  event type registry, rule evaluator, instruction executor
-       ↓
-[issue-core]      ←  task lifecycle, assignment, tracking (Gitea / SQLite / GitHub)
-       ↓
-[repos/services]  ←  execution: actual code changes, scans, operations
+[activity-core]   →  [issue-core]  →  [repos/services]
+[activity-core]   →  [report sinks]
 ```
 
 - **Upstream**: NATS (event bus), Temporal (durable workflow engine), PostgreSQL
   (definitions and audit log), repo-scoping (context adapter), state hub (context
   adapter and event publisher).
-- **Downstream**: issue-core (task management). Agents and humans pick up tasks
-  from issue-core and do the actual work.
+- **Downstream**: issue-core (task management) and configured report sinks.
+  Agents and humans pick up tasks from issue-core and do the actual work.
 - **Coordinates with**: the state hub delegates maintenance automations to
-  activity-core by publishing lifecycle events; activity-core never writes to
-  the state hub directly.
+  activity-core by publishing lifecycle events or by being resolved as context.
+  activity-core may post progress events as report outputs, but it does not own
+  State Hub task/workstream state.
 
 ---
 
@@ -203,8 +249,7 @@ The two evaluation modes:
   `src/activity_core/event_router.py` (NATS → Temporal),
   `src/activity_core/schedule_manager.py` (Temporal Schedules),
   `src/activity_core/api.py` (FastAPI admin).
-- Definition files (WP-0003): `event-types/` and `activity-definitions/`
-  (not yet created — coming in WP-0003).
+- Definition files: `event-types/`, `activity-definitions/`, and `tasks/`.
 - Dev environment: `docker-compose.dev.yml` (Temporal + PostgreSQL + NATS).
 - Entry points: `uv run python -m activity_core.worker` (Temporal worker),
   `uv run uvicorn activity_core.api:app --port 8010` (admin API).