Daily triage stuff

docs/daily-statehub-wsjf-calibration-2026-06-04.md

@@ -0,0 +1,60 @@
+# Daily State Hub WSJF Calibration - 2026-06-04
+
+## Source Runs
+
+| Date | Run id | Source | Main work-next recommendations |
+|------|--------|--------|--------------------------------|
+| 2026-06-02 | `f9b97749` | activity-core manual canary | `cust-wp-0044`, `cust-wp-0045` |
+| 2026-06-03 | `6d2737e3` | activity-core daily run | `cust-wp-0044`, `cust-wp-0045`, WHI card |
+| 2026-06-04 | `65e273bf` | activity-core daily run | `cust-wp-0044`, `cust-wp-0045`, `cust-wp-0003` |
+
+The three runs were consecutive activity-core-generated Custodian daily triage
+notes under `memory/working/`. They are sufficient to calibrate
+`CUST-WP-0044-T06` and `CUST-WP-0045-T08` because none of the three came from
+the old Codex app automation fallback.
+
+## Findings
+
+- The top recommendations were stable and actionable. The system repeatedly
+  identified the triage loop itself (`CUST-WP-0044`) and the activity-core
+  runner cutover (`CUST-WP-0045`) as the highest-value next work.
+- The recommendations matched actual follow-up work: `CUST-WP-0045-T07` was
+  closed through the State Hub WSJF review surface, and this calibration closes
+  the remaining `CUST-WP-0044-T06` / `CUST-WP-0045-T08` loop.
+- The action vocabulary is useful. `work-next`, `needs-human`, `revisit`,
+  `needs-consistency-sync`, and `close-out` all appeared in sensible places.
+- The maximum recommendation count is about right. Seven to nine items were
+  enough to surface the important work without turning the note into a backlog.
+- Stale or blocked work should remain explicit recommendations, not automatic
+  status changes. The daily run should continue to recommend `revisit`,
+  `park`, or `needs-human` and leave canonical edits to implementation
+  sessions.
+- The current JSON reports were too thin for the stated WSJF contract. They
+  explained why candidates were selected but did not include component scores.
+  The schema and ActivityDefinition prompt now require rank and WSJF component
+  scores for future runs.
+- The ActivityDefinition body still described the old disabled/fallback
+  posture even though frontmatter had `enabled: true`. The runner-status text
+  was corrected during calibration.
+
+## Calibration Decisions
+
+- Keep equal WSJF factor weights for now.
+- Keep the recommendation cap at 10.
+- Keep `max_depth: 2` and the balanced triage profile for ordinary daily runs.
+- Increase the runner `max_tokens` from 1400 to 1800 to make room for WSJF
+  component scores without losing recommendations.
+- Require explicit WSJF fields in the executable JSON schema:
+  `score`, `strategic_value`, `time_criticality`, `risk_reduction`,
+  `opportunity_enablement`, and `job_size`.
+- Treat stale-but-intentionally-parked work as a recommendation quality issue,
+  not a status automation issue.
+- Use the State Hub WSJF review page plus activity-core metadata as the normal
+  "did it run today?" surface.
+
+## Result
+
+The daily activity-core WSJF triage loop is useful enough to continue as a
+standing Custodian habit. The next executable recommendation after this
+closeout is `CUST-WP-0003` / WHI KPI card work, unless a human-gated item is
+explicitly approved first.