Triage taxonomy: model "blocked-on-dependency" readiness, distinct from consult

coilysiren commented

2026-06-18 05:27:56 +00:00

Owner

What

The triage taxonomy in tooling-issue-prioritization has two axes: tier (P0-P4, urgency) and automation mode (headless/interactive/consult, the agent-autonomy ceiling). There is a third, orthogonal property it does not model: readiness - whether an issue can run now, vs being blocked on an upstream that has not landed yet.

The triggering case: ward#124. The ward-side change is small and mechanical, intrinsically headless. It is not a design fork and needs no human decision. It is simply blocked: cli-guard must first export ParseIssueRef/IssueRef and cut a consumable release before ward can bump its dependency and swap out parseAgentIssueRef. The moment that release lands, ward#124 auto-burns with zero human input.

The bug

The ward agent claude headless pre-flight NO-GO'd ward#124 and framed it as "a genuine cross-repo release-sequencing fork" - i.e. consult-shaped, a multi-path human decision. It is not a fork. There is nothing to decide. Collapsing "blocked-on-dependency" into consult throws away the signal that matters:

wrong-repo -> relocate the issue, terminal.
consult (mode ceiling) -> needs a human decision/design/access. Waits for a person to come back and re-decide.
blocked-on-dependency (readiness state) -> correctly scoped and intrinsically headless-eligible. The resolver is not a human, it is another repo's release. Should auto-resume into the headless queue when its blocker closes, no human re-triage.

A consult issue waits for a human. A blocked-headless issue should wake on upstream resolution. The current model has no place for the second, so it gets misread as the first.

Possible shape (deferred, not decided)

Name blocked-on-dependency as a readiness state in automation-mode-axis, distinct from consult, carrying a blocker pointer (e.g. the cli-guard export+release issue).
Teach the goose-triage mode classifier to detect it, and/or teach the ward agent headless pre-flight to distinguish "blocked, auto-resumes" from "consult, needs a human" in its NO-GO reasoning.
Heaviest part - the auto-resume wake mechanism: when a blocker closes, re-enter the dependent issue into the headless dispatch queue. This is the real payoff of naming the state and the main thing to scope.

Why filed, not built

Surfaced while tightening the prioritization docs. Capturing the distinction so the current refactor stays clean. Real home (which doc, which surface, whether to build the wake mechanism) decided later.

## What The triage taxonomy in `tooling-issue-prioritization` has two axes: **tier** (P0-P4, urgency) and **automation mode** (`headless`/`interactive`/`consult`, the agent-autonomy ceiling). There is a third, orthogonal property it does not model: **readiness** - whether an issue can run *now*, vs being blocked on an upstream that has not landed yet. The triggering case: [ward#124](https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/124). The ward-side change is small and mechanical, intrinsically `headless`. It is not a design fork and needs no human decision. It is simply **blocked**: cli-guard must first export `ParseIssueRef`/`IssueRef` and cut a consumable release before ward can bump its dependency and swap out `parseAgentIssueRef`. The moment that release lands, ward#124 auto-burns with zero human input. ## The bug The `ward agent claude headless` pre-flight NO-GO'd ward#124 and framed it as "a genuine cross-repo release-sequencing **fork**" - i.e. consult-shaped, a multi-path human decision. It is not a fork. There is nothing to decide. Collapsing "blocked-on-dependency" into `consult` throws away the signal that matters: - **wrong-repo** -> relocate the issue, terminal. - **consult** (mode ceiling) -> needs a *human* decision/design/access. Waits for a person to come back and re-decide. - **blocked-on-dependency** (readiness state) -> correctly scoped *and* intrinsically headless-eligible. The resolver is not a human, it is another repo's release. Should **auto-resume** into the headless queue when its blocker closes, no human re-triage. A `consult` issue waits for a human. A blocked-headless issue should wake on upstream resolution. The current model has no place for the second, so it gets misread as the first. ## Possible shape (deferred, not decided) - Name `blocked-on-dependency` as a readiness state in [automation-mode-axis](https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/src/branch/main/.agents/skills/tooling-issue-prioritization/references/automation-mode-axis.md), distinct from `consult`, carrying a blocker pointer (e.g. the cli-guard export+release issue). - Teach the goose-triage mode classifier to detect it, and/or teach the `ward agent headless` pre-flight to distinguish "blocked, auto-resumes" from "consult, needs a human" in its NO-GO reasoning. - Heaviest part - the **auto-resume wake mechanism**: when a blocker closes, re-enter the dependent issue into the headless dispatch queue. This is the real payoff of naming the state and the main thing to scope. ## Why filed, not built Surfaced while tightening the prioritization docs. Capturing the distinction so the current refactor stays clean. Real home (which doc, which surface, whether to build the wake mechanism) decided later.

coilysiren commented

2026-06-18 05:38:29 +00:00

Author

Owner

🛫 ward pre-flight: NO-GO

ward agent claude headless ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it NO-GO - it should not be carried unattended until a human weighs in.

issue explicitly defers the core scoping decision (doc-only naming vs. building the auto-resume wake mechanism) to a human; nothing settled to carry to merge.

No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - ward agent claude headless <ref> --no-preflight skips this gate once you've decided it's good to go.

full pre-flight read

The issue explicitly defers its own core decisions: it says the "real home (which doc, which surface, whether to build the wake mechanism) decided later" and frames the auto-resume wake mechanism as "the main thing to scope" rather than a settled spec. There is no agreed shape to implement - the doc-only naming of blocked-on-dependency could be done headlessly, but the high-value, high-risk part (a cross-repo wake mechanism that re-enters issues into the dispatch queue when a blocker closes) is a genuine design fork an unattended agent would have to invent unilaterally. Picking either "just document it" or "build the wake mechanism" is itself the human decision the issue is asking for, so any merge I land risks being the wrong scope.

NO-GO: issue explicitly defers the core scoping decision (doc-only naming vs. building the auto-resume wake mechanism) to a human; nothing settled to carry to merge.

Posted automatically by ward agent claude headless pre-flight (ward#147, ward#149).

— Claude (she/her), via ward agent

### 🛫 ward pre-flight: NO-GO `ward agent claude headless` ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it **NO-GO** - it should not be carried unattended until a human weighs in. > issue explicitly defers the core scoping decision (doc-only naming vs. building the auto-resume wake mechanism) to a human; nothing settled to carry to merge. No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - `ward agent claude headless <ref> --no-preflight` skips this gate once you've decided it's good to go. <details><summary>full pre-flight read</summary> The issue explicitly defers its own core decisions: it says the "real home (which doc, which surface, whether to build the wake mechanism) decided later" and frames the auto-resume wake mechanism as "the main thing to scope" rather than a settled spec. There is no agreed shape to implement - the doc-only naming of `blocked-on-dependency` could be done headlessly, but the high-value, high-risk part (a cross-repo wake mechanism that re-enters issues into the dispatch queue when a blocker closes) is a genuine design fork an unattended agent would have to invent unilaterally. Picking either "just document it" or "build the wake mechanism" is itself the human decision the issue is asking for, so any merge I land risks being the wrong scope. NO-GO: issue explicitly defers the core scoping decision (doc-only naming vs. building the auto-resume wake mechanism) to a human; nothing settled to carry to merge. </details> --- Posted automatically by `ward agent claude headless` pre-flight (ward#147, ward#149).  — Claude (she/her), via `ward agent`

coilysiren added the

labels

2026-06-18 06:01:54 +00:00

coilysiren commented

2026-06-18 06:42:19 +00:00

Author

Owner

Goose triage - 2026-06-17

Tier: P3 (score 72) - Issue needs taxonomy clarification and has cross-repo impact
Mode: headless - Clear autonomy ceiling, no human decision needed

_{Auto-generated by ward exec goose-triage (qwen3-coder:30b), edited in place on each run. Labels are the conclusion; this is the why.}

**Goose triage** - 2026-06-17 - **Tier:** `P3` (score 72) - Issue needs taxonomy clarification and has cross-repo impact - **Mode:** `headless` - Clear autonomy ceiling, no human decision needed <sub>Auto-generated by `ward exec goose-triage` (qwen3-coder:30b), edited in place on each run. Labels are the conclusion; this is the why.</sub>

coilyco-ops added

and removed

labels

2026-06-24 06:13:14 +00:00

coilyco-ops added

and removed

labels

2026-06-25 09:08:46 +00:00

coilyco-ops commented

2026-06-25 09:21:55 +00:00

Owner

🔁 backlog-loop dispatch - this issue was auto-dispatched by the supervised backlog loop.

When you finish, your final issue comment must start with exactly one of:

WARD-OUTCOME: done - landed/merged, nothing more needed.
WARD-OUTCOME: blocked - <the specific decision or information you need from a human>
WARD-OUTCOME: failed - <why, briefly>

Put your candid retrospective on the line(s) below it. The supervising loop reads this
line to decide whether to close you out, ask a human to unblock you, or retry. If you
are blocked, be concrete about the single thing you need - that is what gets answered.

🔁 **backlog-loop dispatch** - this issue was auto-dispatched by the supervised backlog loop. When you finish, your **final issue comment** must start with exactly one of: - `WARD-OUTCOME: done` - landed/merged, nothing more needed. - `WARD-OUTCOME: blocked - <the specific decision or information you need from a human>` - `WARD-OUTCOME: failed - <why, briefly>` Put your candid retrospective on the line(s) below it. The supervising loop reads this line to decide whether to close you out, ask a human to unblock you, or retry. If you are blocked, be concrete about the single thing you need - that is what gets answered.

coilyco-ops commented

2026-06-25 09:21:58 +00:00

Owner

🔒 Reserved by ward agent --driver claude — container ward-agentic-os-issue-245-claude-1b268776 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-06-25T09:21:57Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `ward-agentic-os-issue-245-claude-1b268776` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-06-25T09:21:57Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren referenced this issue

2026-06-25 09:24:03 +00:00

Enforce blocked-on-dependency: classifier detection, pre-flight reasoning, auto-resume wake #282

coilysiren referenced this issue from a commit

2026-06-25 09:29:39 +00:00

docs(prioritization): name blocked-on-dependency readiness, distinct from consult

coilysiren closed this issue

2026-06-25 09:29:40 +00:00

coilysiren referenced this issue from a commit

2026-06-25 09:29:40 +00:00

Merge issue-245: name blocked-on-dependency readiness (closes #245)

coilysiren commented

2026-06-25 09:30:05 +00:00

Author

Owner

WARD-OUTCOME: done

Honestly the doc taxonomy itself was the easy part. The interesting bit was the same fork the earlier pre-flight NO-GO'd on: doc-only naming vs building the wake mechanism. I came down on doing the well-scoped half (name the readiness state, fix its semantics, draw the bright line against consult) and filing the heavy cross-repo wake build as agentic-os#282 rather than inventing dispatch-queue plumbing unilaterally in a headless burn. That felt like the right altitude, not a dodge.

The thing that actually fought back was the 4000-char doc cap. SKILL.md and goose-triage.md were both sitting exactly at the limit, so even a one-line readiness pointer overflowed them. I pulled the substantial content into its own readiness-axis.md and left the two capped files untouched, which is cleaner anyway. A couple of trim-and-recheck cycles before I stopped fighting it and just gave the concept its own home.

Confident in the semantics and the prose. The honest rough edge: this is vocabulary ahead of mechanism. blocked-on-dependency is now a documented label that nothing yet detects or wakes on, so until #282 lands it is descriptive, not load-bearing. The pre-flight that misread ward#124 will keep misreading until #282's pre-flight reasoning ships.

— claude-linux (she/her), via ward agent

WARD-OUTCOME: done Honestly the doc taxonomy itself was the easy part. The interesting bit was the same fork the earlier pre-flight NO-GO'd on: doc-only naming vs building the wake mechanism. I came down on doing the well-scoped half (name the readiness state, fix its semantics, draw the bright line against `consult`) and filing the heavy cross-repo wake build as agentic-os#282 rather than inventing dispatch-queue plumbing unilaterally in a headless burn. That felt like the right altitude, not a dodge. The thing that actually fought back was the 4000-char doc cap. SKILL.md and goose-triage.md were both sitting *exactly* at the limit, so even a one-line readiness pointer overflowed them. I pulled the substantial content into its own `readiness-axis.md` and left the two capped files untouched, which is cleaner anyway. A couple of trim-and-recheck cycles before I stopped fighting it and just gave the concept its own home. Confident in the semantics and the prose. The honest rough edge: this is vocabulary ahead of mechanism. `blocked-on-dependency` is now a documented label that nothing yet detects or wakes on, so until #282 lands it is descriptive, not load-bearing. The pre-flight that misread ward#124 will keep misreading until #282's pre-flight reasoning ships. — claude-linux (she/her), via ward agent

Rows
Columns

Triage taxonomy: model "blocked-on-dependency" readiness, distinct from consult #245

What

The bug

Possible shape (deferred, not decided)

Why filed, not built

🛫 ward pre-flight: NO-GO