coilyco-flight-deck/agentic-os

Fork 0

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

New issue

Open

opened 2026-06-25 09:24:03 +00:00 by coilysiren · 1 comment

coilysiren commented

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

Owner

What

agentic-os#245 named blocked-on-dependency as a readiness state in the triage taxonomy (automation-mode-axis): an issue that is correctly scoped and intrinsically headless-eligible, but not runnable now because its resolver is another repo's release/issue, not a human. That landed as doc-only - the vocabulary and the fail-closed semantics. This issue tracks the enforcing half: making the state actually do something.

Scope

Three pieces, in dependency order:

Classifier detection - teach the goose-triage mode pass (and/or a readiness sub-pass) to recognize "blocked, auto-resumes on upstream" and apply the blocked-on-dependency label alongside headless, capturing the blocker pointer (the upstream issue whose close unblocks it).
Pre-flight reasoning - teach the ward agent claude headless pre-flight to distinguish "blocked, auto-resumes" from "consult, needs a human" in its NO-GO text, so a blocked-headless issue reads as a defer-and-wake, not a kick-to-human. (The original ward#124 NO-GO mislabeled it a cross-repo release-sequencing fork - the bug agentic-os#245 was filed against.)
Auto-resume wake mechanism (the heavy part) - when a blocker issue closes, re-enter every dependent blocked-on-dependency issue into the headless dispatch queue with no human re-triage. Needs a blocker->dependent index and a close-event trigger that crosses repos (the triggering case is a ward issue blocked on a cli-guard release).

Why split from #245

#245 captured the distinction so the prioritization-doc refactor stays clean. The wake mechanism is a genuine cross-repo build (close-event plumbing into the dispatch queue) with a real design fork, not a headless doc burn. Naming the state first lets the classifier and wake work land against a settled vocabulary.

agentic-os#245 - names the readiness state (this issue's parent).
agentic-os#246 - the automation-mode dispatch ceiling gate + org-label rollout.
ward#124 - the triggering blocked-headless case.

## What agentic-os#245 named **`blocked-on-dependency`** as a readiness state in the triage taxonomy ([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)): an issue that is correctly scoped and intrinsically `headless`-eligible, but not runnable now because its resolver is another repo's release/issue, not a human. That landed as **doc-only** - the vocabulary and the fail-closed semantics. This issue tracks the **enforcing half**: making the state actually do something. ## Scope Three pieces, in dependency order: 1. **Classifier detection** - teach the `goose-triage` mode pass (and/or a readiness sub-pass) to recognize "blocked, auto-resumes on upstream" and apply the `blocked-on-dependency` label alongside `headless`, capturing the blocker pointer (the upstream issue whose close unblocks it). 2. **Pre-flight reasoning** - teach the `ward agent claude headless` pre-flight to distinguish "blocked, auto-resumes" from "consult, needs a human" in its NO-GO text, so a blocked-headless issue reads as a defer-and-wake, not a kick-to-human. (The original ward#124 NO-GO mislabeled it a cross-repo release-sequencing *fork* - the bug agentic-os#245 was filed against.) 3. **Auto-resume wake mechanism** (the heavy part) - when a blocker issue closes, re-enter every dependent `blocked-on-dependency` issue into the `headless` dispatch queue with no human re-triage. Needs a blocker->dependent index and a close-event trigger that crosses repos (the triggering case is a ward issue blocked on a cli-guard release). ## Why split from #245 #245 captured the distinction so the prioritization-doc refactor stays clean. The wake mechanism is a genuine cross-repo build (close-event plumbing into the dispatch queue) with a real design fork, not a headless doc burn. Naming the state first lets the classifier and wake work land against a settled vocabulary. ## Related - agentic-os#245 - names the readiness state (this issue's parent). - agentic-os#246 - the automation-mode dispatch ceiling gate + org-label rollout. - ward#124 - the triggering blocked-headless case.

coilysiren referenced this issue

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

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

coilysiren added the

interactive

labels

2026-07-01 04:29:19 +00:00

coilyco-ops added

and removed

labels

2026-07-09 21:39:00 +00:00

coilyco-ops referenced this issue

2026-07-09 21:49:52 +00:00

Define the blocked-on-dependency contract: marker syntax, blocker pointer, and wake semantics #394

coilyco-ops referenced this issue from coilyco-flight-deck/ward

2026-07-09 21:49:53 +00:00

Implement blocked-on-dependency in triage, pre-flight, and director auto-resume #872

coilyco-ops commented

2026-07-09 21:49:55 +00:00

Member

🔎 ward agent advisor - cross-repo fan-out

ward agent advisor --harness codex ran a one-shot standard research pass on this question:

Read the issue title, body, and comment thread below as the research brief. Identify the decisions, options, open questions, and risks, then give a clear advisory recommendation that can be posted back on the issue.

Recommendation

Split this into 2 tracked issues, not 3:

agentic-os to freeze the contract and metadata shape for blocked-on-dependency.
ward to implement detection, pre-flight wording, and auto-resume.

The current evidence does not justify a separate cli-guard issue yet. The enforcement points this issue names are all in ward, and cli-guard has no durable backlog/ledger/wake mechanism today.

Findings

The vocabulary already exists in docs, but only as semantics. See .agents/skills/tooling-issue-prioritization/references/automation-mode-axis.md and readiness-axis.md in this repo.
The classifier that could detect this state is currently in ward, not agentic-os: /substrate/ward/cmd/ward/agent_director_triage.go only classifies tier + mode today.
The headless pre-flight that currently misreads this as a human bounce is also in ward: /substrate/ward/cmd/ward/agent.go (preflightPrompt, runPreflight, preflightNoGoComment). Its only terminal verdicts today are effectively GO, NO-GO, and WRONG-REPO.
The auto-resume substrate already partly exists in ward: the director has a durable per-repo backlog ledger and already re-queues some machine-resolved states such as pre-launch death (prelaunch-death-requeued) in /substrate/ward/cmd/ward/agent_director.go. What it lacks is a readiness dimension plus a blocker pointer.
The generic cli-guard dispatch path only has owner/state/mode-ceiling checks plus a consumer preflight hook (/substrate/cli-guard/cli/dispatch/dispatch.go, preflight.go). It does not own a durable queue or cross-repo wake loop.
The original motivating example, ward#124, is already closed as of 2026-07-09. That lowers urgency and means implementation should use a synthetic fixture or a new real blocker pair for tests, not the original live case.

Advisory decisions

Keep blocked-on-dependency as readiness, not mode. The correct shape remains headless + blocked-on-dependency.
Do not encode the blocker pointer in a label alone. Labels can say what kind of state this is, but not which upstream issue closes it.
Prefer a machine-readable issue-thread or issue-body marker as the source of truth, with ward caching it into its backlog ledger for runtime efficiency. A host-local-only index would be fragile across restarts and directors.
Implement wake-up in ward's director polling loop first, not as a webhook/event system. The director already polls, persists ledger state, and re-queues other machine-resolved cases. That is the lowest-risk place to add this behavior.
Keep cli-guard out of scope unless you later decide that non-ward dispatchers also need the same readiness/wake semantics.

Options considered

Label-only pointer: reject. Good for classification, bad for precise dependency identity.
Webhook / push-event wake: possible later, but it adds infra and failure modes before the product semantics are proven.
Forgejo native issue dependencies: maybe usable later, but the checked-in schema here only clearly surfaced the repo setting enable_issue_dependencies; this research did not find an existing ward-owned read/write surface for per-issue dependency edges. Treat native deps as a later optimization, not the first contract.

Open questions

What is the canonical metadata shape for the blocker pointer?
- Best current candidate: a hidden marker in the issue body or a dedicated bot comment, e.g. .
What event should wake dependents?
- Default recommendation: upstream issue closes.
- Do not broaden to "release published" or "PR merged" in v1 unless the pointer type explicitly supports those targets.
Should blocked work stay visible in the headless lane?
- Recommendation: keep mode=headless, but keep readiness separate so the director does not dispatch it while blocked.
How should triage confidence work?
- Recommendation: fail closed. If the classifier cannot name a concrete blocker ref, leave the issue as ordinary consult or plain headless and do not infer wake behavior.

Main risks

False wake if the blocker pointer is ambiguous or points at the wrong issue.
Permanent park if the pointer is missing or stale.
Duplicate dispatch if multiple directors observe the same unblocking transition. Reservation logic should cap damage, but this needs explicit tests.
Semantic drift if pre-flight, triage, and director each invent their own blocked-state wording instead of sharing one contract.

Bottom line

This should be treated as one cross-repo feature with a 2-repo split:

agentic-os defines the contract and marker syntax.
ward implements the behavior.

I would not open a third cli-guard issue unless the team explicitly wants readiness semantics to become a generic dispatch-engine concept instead of a ward-director concept.

The work spans multiple repos, so it was filed as 2 tracked issue(s), in dependency order:

coilyco-flight-deck/agentic-os#394 - Define the blocked-on-dependency contract: marker syntax, blocker pointer, and wake semantics
coilyco-flight-deck/ward#872 - Implement blocked-on-dependency in triage, pre-flight, and director auto-resume

Researched and posted automatically by ward agent advisor --harness codex (ward#424). This is one-shot research, not a carried change - verify before acting on it.

— Codex, via ward agent

### 🔎 ward agent advisor - cross-repo fan-out `ward agent advisor --harness codex` ran a one-shot **standard** research pass on this question: > Read the issue title, body, and comment thread below as the research brief. Identify the decisions, options, open questions, and risks, then give a clear advisory recommendation that can be posted back on the issue. ## Recommendation Split this into **2 tracked issues, not 3**: 1. **`agentic-os`** to freeze the contract and metadata shape for `blocked-on-dependency`. 2. **`ward`** to implement detection, pre-flight wording, and auto-resume. The current evidence does **not** justify a separate `cli-guard` issue yet. The enforcement points this issue names are all in `ward`, and `cli-guard` has no durable backlog/ledger/wake mechanism today. ## Findings - The vocabulary already exists in docs, but only as semantics. See `.agents/skills/tooling-issue-prioritization/references/automation-mode-axis.md` and `readiness-axis.md` in this repo. - The **classifier** that could detect this state is currently in `ward`, not `agentic-os`: `/substrate/ward/cmd/ward/agent_director_triage.go` only classifies **tier + mode** today. - The **headless pre-flight** that currently misreads this as a human bounce is also in `ward`: `/substrate/ward/cmd/ward/agent.go` (`preflightPrompt`, `runPreflight`, `preflightNoGoComment`). Its only terminal verdicts today are effectively `GO`, `NO-GO`, and `WRONG-REPO`. - The **auto-resume substrate already partly exists in `ward`**: the director has a durable per-repo backlog ledger and already re-queues some machine-resolved states such as pre-launch death (`prelaunch-death-requeued`) in `/substrate/ward/cmd/ward/agent_director.go`. What it lacks is a readiness dimension plus a blocker pointer. - The **generic cli-guard dispatch path** only has owner/state/mode-ceiling checks plus a consumer preflight hook (`/substrate/cli-guard/cli/dispatch/dispatch.go`, `preflight.go`). It does not own a durable queue or cross-repo wake loop. - The original motivating example, **`ward#124`, is already closed as of 2026-07-09**. That lowers urgency and means implementation should use a synthetic fixture or a new real blocker pair for tests, not the original live case. ## Advisory decisions - Keep `blocked-on-dependency` as **readiness**, not mode. The correct shape remains **`headless` + `blocked-on-dependency`**. - Do **not** encode the blocker pointer in a label alone. Labels can say *what kind of state this is*, but not *which upstream issue closes it*. - Prefer a **machine-readable issue-thread or issue-body marker as the source of truth**, with `ward` caching it into its backlog ledger for runtime efficiency. A host-local-only index would be fragile across restarts and directors. - Implement wake-up in **`ward`'s director polling loop first**, not as a webhook/event system. The director already polls, persists ledger state, and re-queues other machine-resolved cases. That is the lowest-risk place to add this behavior. - Keep `cli-guard` out of scope unless you later decide that non-ward dispatchers also need the same readiness/wake semantics. ## Options considered - **Label-only pointer**: reject. Good for classification, bad for precise dependency identity. - **Webhook / push-event wake**: possible later, but it adds infra and failure modes before the product semantics are proven. - **Forgejo native issue dependencies**: maybe usable later, but the checked-in schema here only clearly surfaced the repo setting `enable_issue_dependencies`; this research did not find an existing ward-owned read/write surface for per-issue dependency edges. Treat native deps as a later optimization, not the first contract. ## Open questions - What is the canonical metadata shape for the blocker pointer? - Best current candidate: a hidden marker in the issue body or a dedicated bot comment, e.g. ``. - What event should wake dependents? - **Default recommendation: upstream issue closes.** - Do **not** broaden to "release published" or "PR merged" in v1 unless the pointer type explicitly supports those targets. - Should blocked work stay visible in the headless lane? - Recommendation: keep `mode=headless`, but keep readiness separate so the director does **not** dispatch it while blocked. - How should triage confidence work? - Recommendation: fail closed. If the classifier cannot name a concrete blocker ref, leave the issue as ordinary `consult` or plain `headless` and do not infer wake behavior. ## Main risks - **False wake** if the blocker pointer is ambiguous or points at the wrong issue. - **Permanent park** if the pointer is missing or stale. - **Duplicate dispatch** if multiple directors observe the same unblocking transition. Reservation logic should cap damage, but this needs explicit tests. - **Semantic drift** if pre-flight, triage, and director each invent their own blocked-state wording instead of sharing one contract. ## Bottom line This should be treated as **one cross-repo feature with a 2-repo split**: - `agentic-os` defines the contract and marker syntax. - `ward` implements the behavior. I would **not** open a third `cli-guard` issue unless the team explicitly wants readiness semantics to become a generic dispatch-engine concept instead of a ward-director concept. --- The work spans multiple repos, so it was filed as 2 tracked issue(s), in dependency order: 1. [coilyco-flight-deck/agentic-os#394](https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/issues/394) - Define the `blocked-on-dependency` contract: marker syntax, blocker pointer, and wake semantics 2. [coilyco-flight-deck/ward#872](https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/872) - Implement `blocked-on-dependency` in triage, pre-flight, and director auto-resume --- Researched and posted automatically by `ward agent advisor --harness codex` (ward#424). This is one-shot research, not a carried change - verify before acting on it.   — Codex, via `ward agent`

coilysiren referenced this issue from coilyco-flight-deck/ward

2026-07-10 04:03:12 +00:00

ward release race condition #935

coilyco-ops added

consult

and removed

interactive

labels

2026-07-10 08:59:43 +00:00

coilysiren referenced this issue from coilyco-flight-deck/ward

2026-07-14 15:27:09 +00:00

director should emit colorized, space buffered, visually distinct messages about the categories of actions its performing on startup #1283