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 id: daily-triage-report
trusted_fields: trusted_fields:
- context.daily_triage_digest - 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: | prompt: |
Produce the Daily State Hub WSJF triage report from this curated digest. 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 - security posture changes without an explicit approval path
- canon promotion - 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 ## Notes
This file lives in `the-custodian/activity-definitions/` because the 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" title: "Activity-Core Daily Triage Runner Cutover"
domain: custodian domain: custodian
repo: the-custodian repo: the-custodian
status: blocked status: active
owner: custodian owner: custodian
topic_slug: custodian topic_slug: custodian
planning_priority: high planning_priority: high
@@ -237,13 +237,10 @@ paused Temporal schedule while disabled.
```task ```task
id: CUST-WP-0045-T06 id: CUST-WP-0045-T06
status: blocked status: in_progress
priority: high priority: high
depends_on: [CUST-WP-0045-T05] depends_on: [CUST-WP-0045-T05]
state_hub_task_id: "545162d7-0198-4519-a30b-06e88c6db915" 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. 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` `memory/working/daily-triage-2026-05-19-2164cb88.md`
- State Hub progress event: `e42c0ada-8111-4d88-9791-821252cd04a2` - State Hub progress event: `e42c0ada-8111-4d88-9791-821252cd04a2`
The real Claude-backed llm-connect trigger was not run. The execution wrapper The real Claude-backed llm-connect trigger was not run in that pass. The
blocked it because private State Hub workstream/task digest data would be sent execution wrapper blocked it because private State Hub workstream/task digest
to an external LLM provider. Therefore the Codex app automation remains the data would be sent to an external LLM provider. The operator then clarified that
only enabled runner, the ActivityDefinition remains `enabled: false`, and T06 `llm-connect` is the intended backend boundary for LLM providers and depth
is blocked until there is either an approved local/private LLM backend or an tuning. Follow-up implementation keeps that boundary explicit: activity-core
explicit operator decision to allow that external data flow. 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: Verification:
@@ -396,6 +411,15 @@ Verification:
- activity-core full suite after T06 fixes: - activity-core full suite after T06 fixes:
`uv run pytest -q`: `uv run pytest -q`:
110 passed, 1 skipped 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 ## Acceptance Criteria