Record daily triage activity-core canary blocker

memory/working/daily-triage-2026-05-19-2164cb88.md

@@ -0,0 +1,20 @@
+---
+type: working-memory
+source: activity-core
+activity_id: 6fca51fa-387a-4fd0-bc4e-d62c29eb859a
+activity_core_run_id: 2164cb88-8415-5c96-9e31-e47a41cf4e67
+instruction_id: daily-triage-report
+scheduled_for: 2026-05-19T18:02:27.787640+00:00
+created: 2026-05-19T18:02:36.669876+00:00
+---
+
+# Daily State Hub WSJF Triage - 2026-05-19
+
+ok
+
+```json
+{
+  "recommendations": [],
+  "summary": "ok"
+}
+```

workplans/CUST-WP-0045-activity-core-daily-triage-runner.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Activity-Core Daily Triage Runner Cutover"
 domain: custodian
 repo: the-custodian
-status: ready
+status: blocked
 owner: custodian
 topic_slug: custodian
 planning_priority: high
@@ -237,10 +237,13 @@ paused Temporal schedule while disabled.
 
 ```task
 id: CUST-WP-0045-T06
-status: todo
+status: blocked
 priority: high
 depends_on: [CUST-WP-0045-T05]
 state_hub_task_id: "545162d7-0198-4519-a30b-06e88c6db915"
+blocking_reason: "Needs an approved non-external LLM path for private State Hub digest data, or explicit operator approval for the external llm-connect backend."
+needs_human: true
+intervention_note: "Real cutover needs an approved non-external LLM path for private State Hub digest data, or explicit human approval for the external llm-connect backend after review."
 ```
 
 Run the cutover safely.
@@ -346,6 +349,36 @@ message bodies, and other free-text command surfaces. The digest also carries a
 move especially high-gain/high-effort candidate scoring into code without
 changing the ActivityDefinition contract.
 
+T06 is partially validated but blocked before cutover. A local activity-core
+dev stack was started, the Custodian ActivityDefinition directory synced into
+activity-core, and the paused Temporal schedule for the disabled daily triage
+definition was created. The first sync exposed reusable activity-core gaps that
+were fixed there instead of bypassed here:
+
+- file-authored ActivityDefinition slug ids now map to stable UUIDv5 DB ids
+- schedule sync no longer uses raw `NOT IN :ids` SQL that asyncpg rejects
+- ADR-style context sources without an explicit `name` validate against the
+  domain model
+- the worker now registers the existing instruction/report activities
+
+Manual trigger canary evidence, using a local-only llm-connect mock response so
+no State Hub digest data left the workstation:
+
+- workflow id:
+  `activity-6fca51fa-387a-4fd0-bc4e-d62c29eb859a:manual-6a6e5950-2338-45c4-9054-573dda9c87cc`
+- Temporal status: `COMPLETED`
+- activity-core run id: `2164cb88-8415-5c96-9e31-e47a41cf4e67`
+- working-memory note:
+  `memory/working/daily-triage-2026-05-19-2164cb88.md`
+- State Hub progress event: `e42c0ada-8111-4d88-9791-821252cd04a2`
+
+The real Claude-backed llm-connect trigger was not run. The execution wrapper
+blocked it because private State Hub workstream/task digest data would be sent
+to an external LLM provider. Therefore the Codex app automation remains the
+only enabled runner, the ActivityDefinition remains `enabled: false`, and T06
+is blocked until there is either an approved local/private LLM backend or an
+explicit operator decision to allow that external data flow.
+
 Verification:
 
 - `uv run pytest tests/test_state_hub_context_resolver.py -q`:
@@ -356,6 +389,13 @@ Verification:
   report sinks
 - `uv run pytest -q` in activity-core:
   107 passed, 1 skipped
+- activity-core focused T06 validation:
+  `uv run pytest tests/test_sync_activity_definitions.py
+  tests/test_instruction_evaluation.py tests/test_report_sinks.py -q`:
+  10 passed
+- activity-core full suite after T06 fixes:
+  `uv run pytest -q`:
+  110 passed, 1 skipped
 
 ## Acceptance Criteria