Use llm-connect profile for daily triage

This commit is contained in:
2026-05-19 20:56:07 +02:00
parent d6640f297b
commit ed6a13c8d7
2 changed files with 60 additions and 12 deletions

View File

@@ -90,7 +90,12 @@ human-readable report.
id: daily-triage-report
trusted_fields:
- context.daily_triage_digest
model: gpt-5.2
model: custodian-triage-balanced
temperature: 0.2
max_tokens: 1400
max_depth: 2
model_params:
reasoning_effort: medium
prompt: |
Produce the Daily State Hub WSJF triage report from this curated digest.
@@ -150,6 +155,25 @@ Daily triage may recommend but must not execute:
- security posture changes without an explicit approval path
- canon promotion
## LLM Backend And Depth
The model backend for this activity is `llm-connect`. activity-core passes the
instruction's `model`, `temperature`, `max_tokens`, `max_depth`, and
`model_params` values through the llm-connect HTTP boundary; provider choice,
API keys, model routing, and local-vs-remote backend policy stay behind that
boundary.
This definition starts with a balanced daily-triage profile:
- `model: custodian-triage-balanced`
- `max_depth: 2`
- `model_params.reasoning_effort: medium`
Tune these values from observed report quality during the three-run calibration
in `CUST-WP-0044`. Especially critical cases, such as very high gain combined
with high effort, may later use a deeper llm-connect profile or deterministic
pre-scoring without changing the scheduling substrate.
## Notes
This file lives in `the-custodian/activity-definitions/` because the

View File

@@ -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