Use llm-connect profile for daily triage
This commit is contained in:
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user