singularity-forge/TODO.md
Mikael Hugo 3e652a9fd6
Some checks are pending
CI / detect-changes (push) Waiting to run
CI / docs-check (push) Blocked by required conditions
CI / lint (push) Blocked by required conditions
CI / build (push) Blocked by required conditions
CI / integration-tests (push) Blocked by required conditions
CI / windows-portability (push) Blocked by required conditions
CI / rtk-portability (linux, blacksmith-4vcpu-ubuntu-2404) (push) Blocked by required conditions
CI / rtk-portability (macos, macos-15) (push) Blocked by required conditions
CI / rtk-portability (windows, blacksmith-4vcpu-windows-2025) (push) Blocked by required conditions
TODO: triage should escalate Tier 1 items to real milestones
Today's triage run confirmed the manual `/todo triage` workflow works,
but it stops at tier-listing items in BUILD_PLAN.md — doesn't scaffold
.sf/milestones/MNNN/ dirs for the Tier 1 ones. That's the gap that
needs closing for the autonomous flow to actually create milestones
from raw TODO dumps.

Also captures the non-fatal phases-helpers.js extension load error
that appeared at the top of the triage run output.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-11 19:15:33 +02:00

2.4 KiB

TODO

Dump anything here.


Triage should auto-promote Tier 1 items into real milestones

Confirmed today: /todo triage works — it produces a plan doc and tiers items into BUILD_PLAN.md. But it stops at tiering. Tier 1 items — the ones marked blocking / correctness — should additionally trigger the milestone-creation path so they land as .sf/milestones/MNNN/ scaffolds, not just tier-list rows that have to be promoted by hand.

Concretely: at the end of triageTodoDump() in src/resources/extensions/sf/commands-todo.js, after items are inserted into triage_runs/triage_items and reflected in BUILD_PLAN.md, iterate items where tier === "T1" (or some configured threshold) and call into the same milestone-creation flow that /sf new-milestone uses. Each Tier-1 triage item's context (the already-LLM-rationalised "Why" + "Implementation note") becomes the spec for one milestone.

Two design decisions to make:

  1. Auto-create vs queue. Safer default is "queue, await human approval before scaffolding files" — so triage emits a small triage_milestone_candidates row and a follow-up command (/sf triage-milestones approve <id>) does the actual scaffold. More aggressive: skip the human gate when there's high confidence from the triage LLM that the item is well-scoped.

  2. What counts as Tier 1. The triage LLM already decides this based on the spec wording. Document the criteria so it's stable across model swaps (e.g. "correctness / blocking / safety = T1; ergonomics / nice-to-have = T2-3").

When this ships, today's seven triage items (recorded in docs/plans/todo-triage-2026-05-11-plan.md) should retroactively get milestones for the two Tier 1 entries (headless unattended fix + adversarial-collaborative probes).

Triage runner had an extension load error

Today's /todo triage run printed at the top of its output:

[sf] Extension load error Error: Failed to load extension
"/home/mhugo/.sf/agent/extensions/sf/index.js":
The requested module './phases-helpers.js' does not provide an
export named 'closeoutAndStop'

Triage itself still completed successfully, so it's non-fatal — but some extension in the agent harness expected closeoutAndStop from phases-helpers.js and didn't find it. Either the symbol was renamed and a caller wasn't updated, or npm run copy-resources didn't sync the right file. Likely caught by a test if there's one for the phases-helpers exports list.