activity-core/workplans/ADHOC-2026-06-01.md

id, type, title, domain, repo, status, owner, topic_slug, created, updated, state_hub_workstream_id

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
ADHOC-2026-06-01	workplan	Ad hoc — activity-core opportunistic fixes 2026-06-01	custodian	activity-core	ready	custodian	custodian	2026-06-01	2026-06-01	36162ff0-9b47-47c4-8602-56767f9b7a1c

ADHOC-2026-06-01 — activity-core opportunistic fixes

Captured during the CUST-WP-0045 T06 cutover prep session. The dev worker was brought up and surfaced an unrelated, pre-existing bug in the state-hub context resolver that is independent of the daily triage canary.

Tasks

T01 - Fix repo_sbom_status resolver route and params

id: ADHOC-2026-06-01-T01
status: todo
priority: low
state_hub_task_id: "87b56da9-e692-4350-9aff-47080414ec06"

src/activity_core/context_resolvers/state_hub.py resolves query: repo_sbom_status by calling GET /sbom/status?repo={repo_slug}, but State Hub does not expose /sbom/status at all. Actual SBOM routes are /sbom/, /sbom/{repo_slug}, /sbom/snapshots/, /sbom/snapshots/{id}, /sbom/ingest/, /sbom/report/licences/.

Compounding bug: the only ActivityDefinition using this query is activity-definitions/weekly-sbom-staleness.md, which passes params: { repos: all }. The resolver reads params.get("repo_slug", ""), so the lookup URL collapses to /sbom/status?repo= regardless of the ActivityDefinition value.

Symptom: every Monday at 09:00 Europe/Berlin (and on worker startup after a missed Monday tick), the weekly-sbom-staleness workflow runs and the resolver logs HTTP/1.1 404 Not Found for GET /sbom/status?repo=. The _fetch_json helper swallows the error and returns {}, so the workflow continues but the downstream rule evaluates context.repos.sbom_age_days > 30 against an empty dict and never spawns the intended SBOM rescan tasks. The weekly SBOM staleness check has been silently no-op for as long as this route mismatch has existed.

Fix scope:

1. Decide the contract — single-repo lookup (current parameter shape suggests this) versus multi-repo bulk lookup (repos: all suggests this).
2. Update the resolver to call the actual State Hub route(s):
   • single repo: GET /sbom/{repo_slug} (or /sbom/{repo_slug}/status if a status-shaped projection is preferred and exists).
   • bulk: iterate the State Hub /repos/ list and call /sbom/{repo_slug} per repo, returning a list bound to context.repos.
3. Update activity-definitions/weekly-sbom-staleness.md to match: either pass a real repo_slug per definition (multiple definitions, one per repo) or keep repos: all and let the resolver fan out.
4. Update the rule expression to traverse the resulting shape — currently context.repos.sbom_age_days assumes a single object; if the resolver returns a list, the rule needs any(repo.sbom_age_days > 30 for repo in context.repos) or an equivalent per-repo evaluation.
5. Add a resolver unit test that asserts the resolver hits a route State Hub actually serves, and an integration test against a fixture State Hub response so this regression cannot repeat.

Out of scope for this adhoc:

• Decoupling SBOM staleness rules from the state hub resolver.
• Rewriting the SBOM ingestion pipeline or sbom_source policy.
• Promoting this to a full workplan unless the multi-repo decision turns out to need design discussion.

Done when weekly-sbom-staleness runs cleanly against a live State Hub on Monday and either spawns SBOM rescan tasks for stale repos or leaves a clear "all SBOMs fresh" audit row — not a 404 log line and a silent no-op.