Use llm-connect profile for daily triage

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: blocked
+status: active
 owner: custodian
 topic_slug: custodian
 planning_priority: high
@@ -237,13 +237,10 @@ paused Temporal schedule while disabled.
 
 ```task
 id: CUST-WP-0045-T06
-status: blocked
+status: in_progress
 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.
@@ -372,12 +369,30 @@ no State Hub digest data left the workstation:
   `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.
+The real Claude-backed llm-connect trigger was not run in that pass. The
+execution wrapper blocked it because private State Hub workstream/task digest
+data would be sent to an external LLM provider. The operator then clarified that
+`llm-connect` is the intended backend boundary for LLM providers and depth
+tuning. Follow-up implementation keeps that boundary explicit: activity-core
+passes model/depth configuration through llm-connect, provider routing remains
+inside llm-connect, and the ActivityDefinition declares a balanced
+`custodian-triage-balanced` profile for calibration.
+
+The llm-connect depth path is now reusable instead of daily-triage-specific:
+
+- activity-core `InstructionDef` accepts `temperature`, `max_tokens`,
+  `max_depth`, and `model_params`
+- activity-core sends those values to llm-connect as `RunConfig`
+- llm-connect server mode now preserves the full `RunConfig` via
+  `RunConfig.from_dict`
+- the daily triage ActivityDefinition starts with
+  `model: custodian-triage-balanced`, `max_depth: 2`, and
+  `model_params.reasoning_effort: medium`
+
+Remaining T06 work is now operational cutover: run the real llm-connect backend
+selected by the operator, verify real report quality, pause Codex automation,
+set the ActivityDefinition to `enabled: true`, sync schedules, and check the
+next 07:20 run.
 
 Verification:
 
@@ -396,6 +411,15 @@ Verification:
 - activity-core full suite after T06 fixes:
   `uv run pytest -q`:
   110 passed, 1 skipped
+- activity-core llm-connect depth pass-through full suite:
+  `uv run pytest -q`:
+  114 passed, 1 skipped
+- llm-connect focused server validation:
+  `uv run pytest tests/test_server.py -q`:
+  10 passed
+- llm-connect full suite:
+  `PYTHONPATH=. uv run pytest -q`:
+  173 passed
 
 ## Acceptance Criteria