`ward agent` runs should reject in pre-flight, and post a comment, if it detects than an issue is referencing the wrong codebase

coilysiren commented

2026-06-18 03:12:48 +00:00

Owner

No description provided.

coilysiren commented

2026-06-18 03:13:09 +00:00

Author

Owner

or maybe... automatically move? I have kdl for that already

coilysiren commented

2026-06-18 04:29:47 +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.

detection predicate for "wrong codebase" is unspecified and undefined in the issue - needs a human to pin the heuristic and comment target before an unattended run.

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 core risk is that the issue has no description and the title alone leaves the central mechanic undefined: there's no stated heuristic for how ward agent should decide an issue "references the wrong codebase" (repo slug mismatch in the body? a path that doesn't exist in the checkout? an org mismatch?), nor the rejection/comment format or where the comment posts (Forgejo vs GitHub). I'd know how to wire a pre-flight gate and a comment post into the existing ward agent/ward dispatch flow, but the accept/reject predicate is exactly the part most likely to be wrong, and getting it wrong means either false rejections that block real work or a silent no-op - both bad to ship unattended with no human checking the judgment call. This is a design decision Kai owns, not a reversible default I can name inline and move past.

NO-GO: detection predicate for "wrong codebase" is unspecified and undefined in the issue - needs a human to pin the heuristic and comment target before an unattended run.

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

### 🛫 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. > detection predicate for "wrong codebase" is unspecified and undefined in the issue - needs a human to pin the heuristic and comment target before an unattended run. 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 core risk is that the issue has no description and the title alone leaves the central mechanic undefined: there's no stated heuristic for how `ward agent` should decide an issue "references the wrong codebase" (repo slug mismatch in the body? a path that doesn't exist in the checkout? an org mismatch?), nor the rejection/comment format or where the comment posts (Forgejo vs GitHub). I'd know how to wire a pre-flight gate and a comment post into the existing `ward agent`/`ward dispatch` flow, but the accept/reject predicate is exactly the part most likely to be wrong, and getting it wrong means either false rejections that block real work or a silent no-op - both bad to ship unattended with no human checking the judgment call. This is a design decision Kai owns, not a reversible default I can name inline and move past. NO-GO: detection predicate for "wrong codebase" is unspecified and undefined in the issue - needs a human to pin the heuristic and comment target before an unattended run. </details> --- Posted automatically by `ward agent claude headless` pre-flight (ward#147).

coilysiren added the

labels

2026-06-18 06:21:07 +00:00

coilyco-ops added

and removed

labels

2026-06-24 04:11:58 +00:00

coilyco-ops commented

2026-06-24 17:26:20 +00:00

Owner

Re-triage (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24)

P3 - ward agent should reject wrong-codebase issues in pre-flight, concrete-ish, relates to active #153, kept.
consult - Needs a detection-design decision before an agent acts.

**Re-triage** (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24) - **P3** - ward agent should reject wrong-codebase issues in pre-flight, concrete-ish, relates to active #153, kept. - **consult** - Needs a detection-design decision before an agent acts.

coilyco-ops commented

2026-06-24 17:28:37 +00:00

Owner

Re-triage (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24)

P3 - ward agent should reject wrong-codebase issues in pre-flight, concrete-ish, relates to active #153, kept.
consult - Needs a detection-design decision before an agent acts.

**Re-triage** (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24) - **P3** - ward agent should reject wrong-codebase issues in pre-flight, concrete-ish, relates to active #153, kept. - **consult** - Needs a detection-design decision before an agent acts.

coilysiren added

and removed

labels

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

coilyco-ops commented

2026-07-01 04:46:45 +00:00

Owner

🛫 ward pre-flight: NO-GO

ward agent engineer --driver claude 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.

the "wrong codebase" detection predicate is still unspecified and the author has added a second design path (auto-move via kdl) without choosing between it and reject-and-comment — a human must pin the heuristic, the comment target, and the reject-vs-move decision before an unattended run.

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

full pre-flight read

🛫 ward pre-flight: NO-GO

Context to front-load: ward agent dispatch + headless pre-flight wiring (docs/agent.md, docs/agent-preflight.md, .agents/skills/tooling-ward-agent/SKILL.md), the comment-posting path (which forge, Forgejo vs GitHub, and the auth surface it uses), and — if the auto-move fork were chosen — the referenced kdl move tooling. I would read each of these in the fresh clone before any edit rather than assume the wiring. But reading them does not close the actual gap here, which is a design decision, not a locatable convention.

The blocking unknown is unchanged from the earlier NO-GO: the issue never defines the detection predicate for "references the wrong codebase" (repo-slug mismatch in the body? a path absent from the checkout? an org mismatch?), and the author's only follow-up — "or maybe... automatically move? I have kdl for that already" — widens the design rather than pinning it, forking between reject-and-comment and auto-move via kdl. The most recent triage agrees, marking this consult: "Needs a detection-design decision before an agent acts." Getting the predicate wrong ships either false rejections that block real dispatches or a silent no-op, both bad to land unattended with no human checking the judgment call, and the reject-vs-move fork is an externally-visible behavior choice Kai owns, not a reversible default I can name inline and move past.

NO-GO: the "wrong codebase" detection predicate is still unspecified and the author has added a second design path (auto-move via kdl) without choosing between it and reject-and-comment — a human must pin the heuristic, the comment target, and the reject-vs-move decision before an unattended run.

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

— Claude (she/her), via ward agent

### 🛫 ward pre-flight: NO-GO `ward agent engineer --driver claude` 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. > the "wrong codebase" detection predicate is still unspecified and the author has added a second design path (auto-move via kdl) without choosing between it and reject-and-comment — a human must pin the heuristic, the comment target, and the reject-vs-move decision before an unattended run. No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - `ward agent engineer --driver claude <ref> --no-preflight` skips this gate once you've decided it's good to go. <details><summary>full pre-flight read</summary> ## 🛫 ward pre-flight: NO-GO **Context to front-load:** `ward agent` dispatch + headless pre-flight wiring (`docs/agent.md`, `docs/agent-preflight.md`, `.agents/skills/tooling-ward-agent/SKILL.md`), the comment-posting path (which forge, Forgejo vs GitHub, and the auth surface it uses), and — if the auto-move fork were chosen — the referenced kdl move tooling. I would read each of these in the fresh clone before any edit rather than assume the wiring. But reading them does not close the actual gap here, which is a design decision, not a locatable convention. The blocking unknown is unchanged from the earlier NO-GO: the issue never defines the detection predicate for "references the wrong codebase" (repo-slug mismatch in the body? a path absent from the checkout? an org mismatch?), and the author's only follow-up — "or maybe... automatically move? I have kdl for that already" — widens the design rather than pinning it, forking between *reject-and-comment* and *auto-move via kdl*. The most recent triage agrees, marking this **consult**: "Needs a detection-design decision before an agent acts." Getting the predicate wrong ships either false rejections that block real dispatches or a silent no-op, both bad to land unattended with no human checking the judgment call, and the reject-vs-move fork is an externally-visible behavior choice Kai owns, not a reversible default I can name inline and move past. NO-GO: the "wrong codebase" detection predicate is still unspecified and the author has added a second design path (auto-move via kdl) without choosing between it and reject-and-comment — a human must pin the heuristic, the comment target, and the reject-vs-move decision before an unattended run. </details> --- Posted automatically by `ward agent engineer --driver claude` pre-flight (ward#147, ward#149).   — Claude (she/her), via `ward agent`

coilyco-ops referenced this issue

2026-07-02 00:20:43 +00:00

Help warded engineers understand when they are, in fact, inside the repository that relates to an issue #384

coilyco-ops commented

2026-07-02 00:20:43 +00:00

Owner

Confirmed headless; scope note: #162's decision removed the HOST pre-flight entirely, so this rejection + comment lands in the in-container preflight. Recorded by Claude Code (Fable) during the 2026-07-01 ward launch triage session with Kai.

coilysiren referenced this issue

2026-07-06 19:34:49 +00:00

chore(triage): apply the 2026-07-06 backlog re-triage relabel-downs (label-only, no code) #621

coilysiren commented

2026-07-06 19:40:25 +00:00

Author

Owner

Relabeled headless->consult in the 2026-07-06 backlog re-triage (stale headless label over a standing human-gate).

coilysiren commented

2026-07-06 19:42:12 +00:00

Author

Owner

Correction. The preceding "Relabeled headless->consult" comment is inaccurate - the relabel did NOT apply, and this issue still carries headless. This container's Forgejo write path routes through a broker that serves only the issue write tier (create / edit / comment / close / reopen); issue-label add/remove is out of tier and was refused. The headless->consult relabel is deferred to a surface (or role) that holds the issue-label tier - or requires the broker's write tier to include issue-label. Tracked back on ward#621.

**Correction.** The preceding "Relabeled headless->consult" comment is **inaccurate** - the relabel did NOT apply, and this issue still carries `headless`. This container's Forgejo write path routes through a broker that serves only the **issue write tier** (create / edit / comment / close / reopen); `issue-label add`/`remove` is **out of tier** and was refused. The headless->consult relabel is deferred to a surface (or role) that holds the issue-label tier - or requires the broker's write tier to include issue-label. Tracked back on ward#621.

coilyco-ops referenced this issue

2026-07-06 19:43:21 +00:00

chore(triage): apply the 2026-07-06 backlog re-triage relabel-downs (label-only, no code) #621

coilysiren commented

2026-07-06 19:56:04 +00:00

Author

Owner

This already more or less happens

coilysiren closed this issue

2026-07-06 19:56:04 +00:00