Files
activity-core/history/2026-06-16-intent-gap-analysis.md

119 lines
4.2 KiB
Markdown

---
type: history
title: "activity-core INTENT gap analysis"
date: "2026-06-16"
author: codex
repo: activity-core
related_workplan: ACTIVITY-WP-0009
---
# activity-core INTENT Gap Analysis - 2026-06-16
## Context
This note preserves the findings from a repository review against `INTENT.md`.
The review refreshed `SCOPE.md` for the current repo state and identified the
remaining gaps between the intended Event Bridge boundary and the implemented /
deployed surface.
Files and surfaces reviewed:
- `INTENT.md`
- `SCOPE.md`
- `src/activity_core/`
- `activity-definitions/`
- `docs/runbook.md`
- `docs/issue-core-emission-boundary.md`
- `k8s/railiance/`
- `workplans/ACTIVITY-WP-0006-post-triage-operational-hardening.md`
- `workplans/ACTIVITY-WP-0007-ops-inventory-probe-runner.md`
- `workplans/ACTIVITY-WP-0008-weekly-coding-retro.md`
## Summary
activity-core matches the core INTENT boundary in shape: it owns trigger
durability, context resolution, rule/instruction evaluation, outbound
task/report/evidence emission, and local audit records. It still must avoid
owning task lifecycle, project state, privileged ops execution, or service
inventory authority.
The current implementation has grown a useful bounded report/evidence surface:
instruction reports can write working-memory notes and State Hub progress, and
`ops-inventory` context sources can emit compact non-secret
`ops_inventory_probe` summaries. This is still consistent with INTENT as long as
those outputs remain records of activity-core activations rather than an
authoritative task, project, or ops control plane.
## Findings
### 1. Scheduled-run trust gap
`INTENT.md` expects recurring coordination work to run without Bernd as the
manual coordination layer. The daily State Hub WSJF triage path is implemented
and has produced validated reports, but `ACTIVITY-WP-0006-T03` still lacks
three clean consecutive scheduled runs after the June 7 runtime projection
failure.
Current evidence as of 2026-06-16:
- State Hub `daily_triage` progress only shows activity-core entries through
2026-06-06.
- `/home/worsch/the-custodian/memory/working` only has `daily-triage-*` notes
for 2026-06-02 through 2026-06-06.
Impact: daily triage is production-backed, but not yet fully proven as a
standing substrate.
### 2. Live task creation gap
`INTENT.md` says each activation emits task creation requests to issue-core and
records only the spawn audit trail. The REST issue sink exists, but Railiance is
currently configured with `ISSUE_SINK_TYPE=null`, so production runs record
synthetic audit references instead of consistently creating live issue-core
tasks.
Impact: the task emission boundary is implemented but not yet broadly proven in
the production deployment.
### 3. Review queue gap
The original ADR text described `review_required` as routing instruction output
to a pending review queue. Current code records `review_required` in
report/spawn metadata but does not integrate with an issue-core review queue.
Impact: current behavior is safe as metadata. As of the ACTIVITY-WP-0009
implementation pass, ADR-003 and SCOPE.md have been aligned to that behavior.
### 4. Evidence backend gap
The State Hub fallback evidence path works for `ops_inventory_probe`, and
`ACTIVITY-WP-0007` has live Railiance evidence. Inter-Hub / ops-hub submission
is intentionally deferred behind operator-owned `OPS_HUB_KEY` custody, widget
mapping, and approval.
Impact: activity-core can preserve non-secret continuity evidence, but richer
per-entity ops evidence publication is not yet live.
### 5. Execution-boundary residue
`TaskExecutorWorkflow` remains registered as a stub that persists a done
`task_instances` row. INTENT explicitly says activity-core must not execute the
work or track lifecycle state.
Impact: low immediate risk because the workflow is inert, but it is an attractive
wrong hook for future execution creep.
### 6. API exposure gap
The FastAPI admin surface is useful for internal CRUD and manual triggers.
Railiance docs keep it as ClusterIP until an authenticated ingress and access
policy are chosen.
Impact: operationally acceptable for now, but production access posture remains
an explicit decision.
## Follow-up
`workplans/ACTIVITY-WP-0009-intent-gap-closure.md` was created to turn these
findings into tracked closure work.