the-custodian/docs/daily-triage-stabilization-status.md

Daily-Triage Stabilization Status

Updated: 2026-06-30

Purpose

Track the current daily-triage blocker chain for CUST-WP-0051-T04 without duplicating the source activity-core workplans.

Current Evidence

State Hub daily_triage progress shows the scheduled activity-core runner is alive and can write both State Hub progress and working-memory notes.

Recent scheduled run evidence:

Date	State Hub event	Result
2026-06-24	8b4c16ee-ac47-4581-b3ee-a23fc1f682e6	schema-valid daily triage, working memory written
2026-06-25	cbba6bc0-14cb-492b-ab23-74b9349326c8	schema-valid daily triage, working memory written
2026-06-26	97fd20a0-eee0-45ea-8290-6d91874e1515	validation failed at char 5268, working memory written
2026-06-27	c5ab50a8-404b-4e30-849f-841b059ace65	validation failed at char 5246, working memory written
2026-06-28	f0d8477e-1db9-4c07-bb8c-d28cbb868abc	schema-valid daily triage, working memory written; still emitted 10 recommendations
2026-06-29	176d2ea7-f0e3-48cd-999b-4ab6055c6a55	schema-valid daily triage, working memory written; still emitted 10 recommendations
2026-06-30	27d695b2-a537-481b-ada6-ca84ec24cd96	schema-valid daily triage, working memory written; still emitted 10 recommendations

The 2026-06-26 and 2026-06-27 failures are both overlong malformed JSON responses from daily-triage-report. They are not missed schedules and they are not silent sink failures. The 2026-06-28 through 2026-06-30 events restore a three-run schema-valid streak, but they do not prove the bounded WP-0016 contract because the reports still emit 10 recommendations instead of the targeted top-N framing.

Current Blocker

The old ACTIVITY-WP-0010 State Hub bridge note is partially superseded by the newer evidence: scheduled runs are reaching State Hub and the working-memory sink. The current primary blocker is that the live activity-core runtime still uses an output path that can discard the whole report when the model emits a malformed tail.

ACTIVITY-WP-0016 has the repo-side mitigation:

• strict bounded report schema;
• item-granular recovery and quarantine;
• producer guardrails and ADR-004;
• regression tests for the 2026-06-26 failure shape.

The remaining gate is the live contract/smoke path:

1. Deploy the WP-0016 code and schema together.
2. Update the Railiance runtime prompt bundle with bounded top-N instructions, per-item framing, value vocabularies, and sufficient max_tokens headroom.
3. Run a live daily-triage smoke on railiance01 and confirm malformed-tail output degrades to partial valid output with quarantined items.
4. Record the 2026-06-28 / 2026-06-29 / 2026-06-30 three-clean-run calibration result with the caveat that top-N contract adoption is still pending.

Hygiene Note

The State Hub task index currently shows stale duplicate tasks for ACTIVITY-WP-0016 in addition to the source-file task records. Before relying on activity-core task counts for triage ranking, run activity-core consistency sync and prune or reconcile any stale generated task rows that are no longer linked from the workplan file.

2026-06-27 status-normalization: ACTIVITY-WP-0016 source task blocks now match the progress notes for T04 (done) and T05 (progress). Remaining hygiene is to remove or reconcile stale duplicate task rows from the State Hub index.

2026-06-27 gate cleanup: ACTIVITY-WP-0010-T02 is now done because scheduled runner evidence proves the State Hub sink and working-memory path are reachable. The live human-needed notes now sit on the post-deployment smoke, WP-0016 live proof, and three-clean-run calibration tasks.

2026-06-30 recheck: State Hub now has schema-valid scheduled daily_triage events for 2026-06-28 (f0d8477e-1db9-4c07-bb8c-d28cbb868abc), 2026-06-29 (176d2ea7-f0e3-48cd-999b-4ab6055c6a55), and 2026-06-30 (27d695b2-a537-481b-ada6-ca84ec24cd96), all with working-memory notes. This is enough to bank the scheduling/sink/schema-validity streak for calibration, but not enough to close the WP-0016 live-proof gate: the reports still contain 10 recommendations rather than the bounded top-N contract, and the local activity-core worktree already has separate in-flight diagnostic/status changes that should be committed by their owner before Custodian treats them as source truth.