Align activity-core scope boundaries

2026-06-18 15:11:48 +02:00
parent 78eed5f942
commit 977a3bd97f
7 changed files with 530 additions and 56 deletions
--- a/workplans/ACTIVITY-WP-0009-intent-gap-closure.md
+++ b/workplans/ACTIVITY-WP-0009-intent-gap-closure.md
@@ -0,0 +1,250 @@
+---
+id: ACTIVITY-WP-0009
+type: workplan
+title: "Intent gap closure"
+domain: custodian
+repo: activity-core
+status: blocked
+owner: codex
+topic_slug: custodian
+created: "2026-06-16"
+updated: "2026-06-18"
+state_hub_workstream_id: "d64cfbba-6da7-4737-afb9-866afa0e9cda"
+---
+
+# ACTIVITY-WP-0009 - Intent gap closure
+
+## Context
+
+The 2026-06-16 review of activity-core against `INTENT.md` found that the repo
+matches the intended Event Bridge shape, but several production and contract
+gaps remain before the implementation fully satisfies the operational promise:
+
+- recurring scheduled work must be trusted without manual coordination
+- live task creation must be proven through issue-core, not only null-sink audit
+- `review_required` semantics must either be implemented or documented as
+  metadata only
+- ops evidence must either remain explicitly fallback-first or activate the
+  Inter-Hub / ops-hub backend behind operator-owned secrets
+- the `TaskExecutorWorkflow` stub must not become a back door into execution
+  ownership
+- the internal FastAPI surface needs an explicit production access decision
+
+The preserved analysis lives in:
+
+`history/2026-06-16-intent-gap-analysis.md`
+
+## Close Daily Triage Scheduled-Run Trust Gap
+
+```task
+id: ACTIVITY-WP-0009-T01
+status: wait
+priority: high
+state_hub_task_id: "7012e4fd-2530-49b7-9c2f-1d949809a144"
+```
+
+Close the scheduled-run trust gap identified in `ACTIVITY-WP-0006-T03`.
+
+Acceptance criteria:
+
+- activity-core has three clean consecutive scheduled daily State Hub WSJF
+  triage runs after the June 7 runtime projection failure
+- each run has matching Temporal workflow history, `activity_runs` row, State
+  Hub `daily_triage` progress, and working-memory report note
+- calibration feedback is recorded in State Hub
+- `ACTIVITY-WP-0006-T03` can move from `wait` to `done`
+
+Current wait reason: as of 2026-06-16, State Hub `daily_triage` progress and
+working-memory `daily-triage-*` notes only show activity-core evidence through
+2026-06-06.
+
+2026-06-18 update: activity-core now consumes the verified in-cluster
+llm-connect Service URL in `k8s/railiance/20-runtime.yaml`:
+`LLM_CONNECT_URL=http://llm-connect.activity-core.svc.cluster.local:8080` with
+`LLM_CONNECT_TIMEOUT_SECONDS=300`. This removes the activity-core repo-side URL
+gap. Closure still waits on the operator-owned provider Secret for llm-connect,
+a schema-valid fixture smoke, and three clean scheduled daily triage runs with
+matching State Hub and working-memory evidence.
+
+2026-06-18 follow-up: State Hub message
+`6a098e1e-65de-4309-ab4a-446aba2f3587` reports that the llm-connect side is now
+complete: the provider Secret has a populated key count and the in-namespace
+fixture smoke passed. The remaining work is the activity-core / Railiance
+runtime reconciliation and daily-triage evidence collection path captured in
+`ACTIVITY-WP-0010`.
+
+## Promote Issue-Core Task Emission Safely
+
+```task
+id: ACTIVITY-WP-0009-T02
+status: wait
+priority: high
+state_hub_task_id: "3854677b-32b4-43f8-a6ca-5a2b25a08dd9"
+```
+
+Move selected production-safe definitions from `ISSUE_SINK_TYPE=null` audit mode
+toward real issue-core task creation.
+
+Acceptance criteria:
+
+- issue-core endpoint, credentials, and duplicate-handling posture are approved
+  for the target environment
+- one known-safe definition is run first in null-sink mode and its task specs are
+  reviewed
+- the same definition creates exactly the expected issue-core task(s) through
+  `IssueCoreRestSink`
+- `task_spawn_log` records the real returned task references
+- rollback to null-sink mode is documented
+
+Current wait reason: production Railiance currently uses null-sink audit mode;
+live issue-core credentials/access and duplicate-handling are not yet verified
+for this repo.
+
+## Resolve Review-Required Contract Drift
+
+```task
+id: ACTIVITY-WP-0009-T03
+status: done
+priority: medium
+state_hub_task_id: "1eafe5e4-8412-4104-a417-933efe8e7bbd"
+```
+
+Resolve the mismatch between ADR language and current code for
+`review_required`.
+
+Options:
+
+- implement an issue-core-owned pending review queue contract and route
+  `review_required=true` instruction outputs there, or
+- update ADR/docs to state that `review_required` is currently audit/report
+  metadata only
+
+Acceptance criteria:
+
+- `docs/adr/adr-003-rule-instruction-model.md`, `SCOPE.md`, and tests describe
+  the same behavior
+- no ActivityDefinition implies a review queue exists unless that downstream
+  contract is live
+- report/spawn metadata remains available for operator review either way
+
+2026-06-16: Completed by aligning ADR-003 with the implemented behavior:
+`review_required` is audit/report metadata only until issue-core owns a pending
+review queue contract. `SCOPE.md` already had the same boundary, and
+`tests/test_issue_sink.py` now asserts the REST issue sink does not send a
+`review_required` field as though a review queue existed.
+
+## Decide And Gate Ops Evidence Backend
+
+```task
+id: ACTIVITY-WP-0009-T04
+status: done
+priority: medium
+state_hub_task_id: "61300966-c119-4ebf-af89-a6c50df93ac8"
+```
+
+Decide whether the `ops-inventory` evidence path should remain State Hub
+fallback-first for now or activate Inter-Hub / ops-hub submission.
+
+Acceptance criteria:
+
+- the decision is recorded in State Hub and the relevant docs/workplans
+- if fallback-first remains the chosen mode, docs explicitly say State Hub
+  `ops_inventory_probe` progress is the accepted closure path
+- if Inter-Hub is activated, `OPS_HUB_KEY` is provisioned outside Git, widget /
+  capability mapping is configured, and live submission is tested without
+  printing or storing secrets
+
+2026-06-16: Completed the current posture decision. State Hub decision
+`7c235bbb-ee6f-4c3e-b1dd-74717eac9082` records that State Hub
+`ops_inventory_probe` progress is the accepted live evidence backend for now.
+Inter-Hub / ops-hub per-entity submission remains future work gated on
+operator-owned `OPS_HUB_KEY` custody, widget mapping, and production intake
+smoke tests. `docs/runbook.md` documents the fallback-first posture.
+
+## Remove Or Rehome TaskExecutor Stub Risk
+
+```task
+id: ACTIVITY-WP-0009-T05
+status: done
+priority: medium
+state_hub_task_id: "fbe3e822-1a7c-4fe6-8251-cc8a782b9516"
+```
+
+Reduce the chance that `TaskExecutorWorkflow` attracts real execution work
+inside activity-core.
+
+Acceptance criteria:
+
+- decide whether the stub should stay registered, be removed, or be moved to an
+  execution-owned repo/workplan
+- if it stays, docs and comments explicitly mark it as non-production and
+  outside the activity-core ownership boundary
+- no production ActivityDefinition or workflow path depends on `task_instances`
+  as task lifecycle state
+
+2026-06-16: Completed by deciding to keep `TaskExecutorWorkflow` registered only
+as a compatibility/idempotency stub. `src/activity_core/workflows.py` and
+`docs/conventions.md` now mark it as non-production and outside activity-core's
+execution boundary. No production ActivityDefinition uses `task_instances` for
+task lifecycle state.
+
+## Decide FastAPI Production Access Posture
+
+```task
+id: ACTIVITY-WP-0009-T06
+status: done
+priority: medium
+state_hub_task_id: "99e1e301-296b-4f78-8843-2a39e59ecd7d"
+```
+
+Choose and document the production access posture for the FastAPI admin surface.
+
+Acceptance criteria:
+
+- operator decides whether the API remains ClusterIP-only or receives an
+  authenticated ingress
+- if ingress is chosen, hostname, auth layer, allowed users/agents, and audit
+  expectations are documented before exposure
+- runbook and Railiance deployment docs match the chosen posture
+
+2026-06-16: Completed the current access posture decision. State Hub decision
+`9ffaf7a9-227a-4e39-92e3-cd93d8cda1f2` records that the FastAPI admin surface
+remains ClusterIP-only until a separate authenticated ingress/access-policy work
+item chooses hostname, auth layer, allowed users/agents, and audit expectations.
+`docs/runbook.md` and `k8s/railiance/README.md` now agree on this posture.
+
+## Completion Criteria
+
+- The historical findings are preserved under `history/`.
+- `SCOPE.md`, ADRs, workplans, and implementation agree on activity-core's
+  boundary.
+- Daily scheduled triage has real consecutive-run calibration evidence.
+- At least one production-safe task creation path is proven against issue-core,
+  or null-sink mode is explicitly accepted as the current production posture.
+- Ops evidence backend posture is explicit and tested in the chosen mode.
+- No registered workflow or API path invites activity-core to own execution,
+  task lifecycle, project state, or privileged ops control.
+
+## Implementation Pass - 2026-06-16
+
+Agent-actionable closure is complete for T03, T04, T05, and T06.
+
+Remaining waits:
+
+- T01 waits on real scheduled daily triage run evidence.
+- T02 waits on issue-core production endpoint/credentials and duplicate-handling
+  approval.
+
+Verification:
+
+```bash
+.venv/bin/pytest tests/test_issue_sink.py tests/rules/test_executor.py -k "review_required or issue_core_rest_sink"
+```
+
+Result: 3 passed, 24 deselected.
+
+After this workplan is synced by the custodian operator, run from `~/state-hub`:
+
+```bash
+make fix-consistency REPO=activity-core
+```