61 lines
3.1 KiB
Markdown
61 lines
3.1 KiB
Markdown
# 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.
|