coilyco-flight-deck/ward

Fork 0

Neither directors nor engineers consider human comments on their PR / issue to be blocking #1275

New issue

Closed

opened 2026-07-14 10:47:57 +00:00 by coilysiren · 5 comments

coilysiren commented

2026-07-14 10:47:57 +00:00

Owner

example coilyco-flight-deck/agentic-os#527 (comment)

there's another example around here where I kept closing a PR because it didn't meet the real need, and the director or engineer kept re-opening it without communicating that they are course correcting in response to my feedback

this creates a major issue in that the human will think they provided blocking critical feedback to the director / engineer - when in reality they just ignored it

Decision for headless carry

Implement a conservative stale-human-feedback gate before terminal agent actions. Do not hardcode coilyco-ops or any local bot name.

Default contract:

Any non-agent comment or review after the last ward agent checkpoint blocks terminal actions.
Ward identifies agent-authored automation by structured body markers, not by username. Built-in markers include ward reservation/signature comments, WARDED_WORKFLOW:, WARD-OUTCOME:, and other documented ward marker-family comments.
The default ignored-author list is empty, because many users will not use bot accounts at all.
Downstream bundles may configure ignored authors, for example a local bot account, but ward core must not ship coilyco-specific defaults.

Terminal actions to gate:

Reopening an issue or PR.
Closing an issue.
Merging a PR.
Posting WARD-OUTCOME: done or equivalent completion.
Dispatching follow-up work that assumes newer human feedback was accepted.

Implementation shape:

Load issue comments, PR comments, reviews, and relevant issue/PR body update metadata where available.
Find the latest ward agent checkpoint marker for the active workflow.
Find newer human feedback: comments/reviews not classified by marker as ward automation and not excluded by configured ignored authors.
If any newer human feedback exists, stop before the terminal action and report a blocked status with comment/review URLs.
The next run must include that feedback in its seed and create a new checkpoint before terminal actions proceed.

Config shape:

Add a documented feedback-gate config surface for ignored authors, default empty.
Add a documented marker list or marker classifier for ward automation comments. Users may extend it, but built-in ward markers should work with no config.
Tests must prove ward works for a no-bot user: human comments from the repo owner block, while ward marker comments do not.

example https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/pulls/527#issuecomment-33307 there's another example around here where I kept closing a PR because it didn't meet the real need, and the director or engineer kept re-opening it without communicating that they are course correcting in response to my feedback this creates a major issue in that the human will think they provided blocking critical feedback to the director / engineer - when in reality they just ignored it --- ## Decision for headless carry Implement a conservative stale-human-feedback gate before terminal agent actions. Do not hardcode `coilyco-ops` or any local bot name. Default contract: * Any non-agent comment or review after the last ward agent checkpoint blocks terminal actions. * Ward identifies agent-authored automation by structured body markers, not by username. Built-in markers include ward reservation/signature comments, `WARDED_WORKFLOW:`, `WARD-OUTCOME:`, and other documented ward marker-family comments. * The default ignored-author list is empty, because many users will not use bot accounts at all. * Downstream bundles may configure ignored authors, for example a local bot account, but ward core must not ship coilyco-specific defaults. Terminal actions to gate: * Reopening an issue or PR. * Closing an issue. * Merging a PR. * Posting `WARD-OUTCOME: done` or equivalent completion. * Dispatching follow-up work that assumes newer human feedback was accepted. Implementation shape: 1. Load issue comments, PR comments, reviews, and relevant issue/PR body update metadata where available. 2. Find the latest ward agent checkpoint marker for the active workflow. 3. Find newer human feedback: comments/reviews not classified by marker as ward automation and not excluded by configured ignored authors. 4. If any newer human feedback exists, stop before the terminal action and report a blocked status with comment/review URLs. 5. The next run must include that feedback in its seed and create a new checkpoint before terminal actions proceed. Config shape: * Add a documented feedback-gate config surface for ignored authors, default empty. * Add a documented marker list or marker classifier for ward automation comments. Users may extend it, but built-in ward markers should work with no config. * Tests must prove ward works for a no-bot user: human comments from the repo owner block, while ward marker comments do not.

coilysiren added the

label

2026-07-14 10:47:57 +00:00

coilysiren referenced this issue

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

coilyco-ops added the

headless

label

2026-07-15 04:51:16 +00:00

coilyco-ops added this to the warded control plane coherence milestone

2026-07-15 05:14:50 +00:00

coilyco-ops added the

coherence-core

label

2026-07-15 05:28:19 +00:00

coilyco-ops commented

2026-07-15 05:48:45 +00:00

Member

🔎 ward agent advisor

ward agent advisor --harness codex ran a one-shot deep 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

Treat this as a ward control-plane bug, not an agent-prompt bug. Human intervention needs to become a first-class gate in ward code: any human-authored comment on the carried issue, linked PR, or a human/manual PR close after the run's last known snapshot should block automated success, merge, and reopen until the automation visibly acknowledges the feedback or a human explicitly unblocks it.

What the repo shows

Engineers do fetch issue comments before launch and include them in the seed (cmd/ward/agent.go). PR repair runs also fetch PR comments and linked issue comments. That only covers comments that already existed before the run was seeded.
The reservation comment already warns that comments during an active reservation do not reach the running engineer, and says to file a fresh issue. That is true but insufficient here, because Forgejo cannot actually lock the conversation and PR threads are still commentable.
Director merge eligibility currently keys off machine-readable WARDED_WORKFLOW comments, workflow markers, CI, review, and QA. It does not appear to treat later human comments as a veto.
ward agent pr reopen can reopen a closed-unmerged PR after state/head checks, but it has no required reason, no visible acknowledgement, and no human-comment or manual-close gate. ward agent pr close requires a reason, but reopen does not.
The example PR had a human comment at 2026-07-14T10:26:42Z saying the implementation missed the goal. The issue thread later got a bot WARDED_WORKFLOW: pass at 10:35:58Z, the PR merged at 10:36:15Z, and the PR got a bot pass comment at 10:37:25Z. Even if the run did course-correct internally, the human-facing contract was bad: the blocking feedback was not visibly acknowledged before merge.

Decision points

Default semantics - Make post-snapshot human comments hard-blocking by default. Do not rely on natural-language classification. A short comment like no, a manual close, or a critique can all mean stop.
Unblock mechanism - Require a newer, visible acknowledgement before automation proceeds. Best shape: the agent posts an acknowledgement naming the human comment IDs or close event and summarizing what changed. A human can also post an explicit unblock marker such as WARD-HUMAN: proceed if ward wants an operator override.
Where to enforce - Enforce in ward code at irreversible or user-visible boundaries: engineer pre-landing, reaper before preserving or landing residual work, director merge eligibility, native ward agent pr reopen, director closed-unmerged recovery, and queue/status classification.
What counts as human - Treat comments not authored by the configured automation identity as human. This probably needs one shared helper instead of scattered coilyco-ops assumptions.
Manual PR close - A close can be blocking even without a comment. Comment APIs will not reliably expose close/reopen events, so ward likely needs a PR or issue event source, or it must conservatively treat a closed-unmerged PR as human-blocked unless the close was produced inside the current merge-recovery attempt.

Options weighed

Prompt-only instruction - Low implementation cost, but not sufficient. The failure is at merge/reopen/terminal-status gates, and agents can miss or fail to visibly acknowledge feedback.
Keep current reservation wording - Accurate for in-flight engineers, but it puts the burden on the human and does not protect PR comments or manual PR closes.
Explicit marker only - Cleaner for automation, but it misses the actual reported behavior where ordinary human prose and repeated closes were intended as blocking.
Hard default human-intervention gate - Highest friction, but correct for trust. False positives are acceptable because the unblock action is cheap and visible.

Concrete implementation shape

Add a shared humanIntervention classifier over issue comments, PR comments, and PR state events.
Record the run snapshot time and included comment IDs in the reservation seed context, then use that as the lower bound for new human feedback.
Add a human-intervention outcome or gate reason that renders as WARDED_WORKFLOW: blocked with links or IDs for the blocking comments/events.
Make director merge skip PRs when a human intervention is newer than the latest acknowledged automation outcome.
Make ward agent pr reopen require a reason or acknowledgement when a PR has human feedback or an unexplained manual close, and post that acknowledgement visibly before reopening.
Keep the existing reservation warning, but reword it once the gate exists: comments may not steer a running engineer live, but they do block landing/reopen until acknowledged.

Risks

False positives will park runs on benign comments like thanks. That is preferable to silently merging over a human objection.
Forgejo may not expose enough close/reopen actor data through the current API wrapper. If so, use the conservative rule for closed-unmerged PRs until an event endpoint is wired.
Bot identity must be centralized. Hardcoding one login will break GitHub/GitLab or future bot attribution changes.
Reaper behavior matters. If only the agent prompt is changed, the reaper can still land or salvage after feedback. The gate needs to sit in the landing path too.

This belongs on coilyco-flight-deck/ward only. The example is in agentic-os, but the owner of the behavior is ward's reservation, PR workflow, director merge, reaper, and container seed machinery.

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

— Codex, via ward agent

### 🔎 ward agent advisor `ward agent advisor --harness codex` ran a one-shot **deep** 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** Treat this as a ward control-plane bug, not an agent-prompt bug. Human intervention needs to become a first-class gate in ward code: any human-authored comment on the carried issue, linked PR, or a human/manual PR close after the run's last known snapshot should block automated success, merge, and reopen until the automation visibly acknowledges the feedback or a human explicitly unblocks it. **What the repo shows** - Engineers do fetch issue comments before launch and include them in the seed (`cmd/ward/agent.go`). PR repair runs also fetch PR comments and linked issue comments. That only covers comments that already existed before the run was seeded. - The reservation comment already warns that comments during an active reservation do not reach the running engineer, and says to file a fresh issue. That is true but insufficient here, because Forgejo cannot actually lock the conversation and PR threads are still commentable. - Director merge eligibility currently keys off machine-readable `WARDED_WORKFLOW` comments, workflow markers, CI, review, and QA. It does not appear to treat later human comments as a veto. - `ward agent pr reopen` can reopen a closed-unmerged PR after state/head checks, but it has no required reason, no visible acknowledgement, and no human-comment or manual-close gate. `ward agent pr close` requires a reason, but reopen does not. - The example PR had a human comment at 2026-07-14T10:26:42Z saying the implementation missed the goal. The issue thread later got a bot `WARDED_WORKFLOW: pass` at 10:35:58Z, the PR merged at 10:36:15Z, and the PR got a bot pass comment at 10:37:25Z. Even if the run did course-correct internally, the human-facing contract was bad: the blocking feedback was not visibly acknowledged before merge. **Decision points** - **Default semantics** - Make post-snapshot human comments hard-blocking by default. Do not rely on natural-language classification. A short comment like `no`, a manual close, or a critique can all mean stop. - **Unblock mechanism** - Require a newer, visible acknowledgement before automation proceeds. Best shape: the agent posts an acknowledgement naming the human comment IDs or close event and summarizing what changed. A human can also post an explicit unblock marker such as `WARD-HUMAN: proceed` if ward wants an operator override. - **Where to enforce** - Enforce in ward code at irreversible or user-visible boundaries: engineer pre-landing, reaper before preserving or landing residual work, director merge eligibility, native `ward agent pr reopen`, director closed-unmerged recovery, and queue/status classification. - **What counts as human** - Treat comments not authored by the configured automation identity as human. This probably needs one shared helper instead of scattered `coilyco-ops` assumptions. - **Manual PR close** - A close can be blocking even without a comment. Comment APIs will not reliably expose close/reopen events, so ward likely needs a PR or issue event source, or it must conservatively treat a closed-unmerged PR as human-blocked unless the close was produced inside the current merge-recovery attempt. **Options weighed** - **Prompt-only instruction** - Low implementation cost, but not sufficient. The failure is at merge/reopen/terminal-status gates, and agents can miss or fail to visibly acknowledge feedback. - **Keep current reservation wording** - Accurate for in-flight engineers, but it puts the burden on the human and does not protect PR comments or manual PR closes. - **Explicit marker only** - Cleaner for automation, but it misses the actual reported behavior where ordinary human prose and repeated closes were intended as blocking. - **Hard default human-intervention gate** - Highest friction, but correct for trust. False positives are acceptable because the unblock action is cheap and visible. **Concrete implementation shape** 1. Add a shared `humanIntervention` classifier over issue comments, PR comments, and PR state events. 2. Record the run snapshot time and included comment IDs in the reservation seed context, then use that as the lower bound for new human feedback. 3. Add a `human-intervention` outcome or gate reason that renders as `WARDED_WORKFLOW: blocked` with links or IDs for the blocking comments/events. 4. Make director merge skip PRs when a human intervention is newer than the latest acknowledged automation outcome. 5. Make `ward agent pr reopen` require a reason or acknowledgement when a PR has human feedback or an unexplained manual close, and post that acknowledgement visibly before reopening. 6. Keep the existing reservation warning, but reword it once the gate exists: comments may not steer a running engineer live, but they do block landing/reopen until acknowledged. **Risks** - False positives will park runs on benign comments like `thanks`. That is preferable to silently merging over a human objection. - Forgejo may not expose enough close/reopen actor data through the current API wrapper. If so, use the conservative rule for closed-unmerged PRs until an event endpoint is wired. - Bot identity must be centralized. Hardcoding one login will break GitHub/GitLab or future bot attribution changes. - Reaper behavior matters. If only the agent prompt is changed, the reaper can still land or salvage after feedback. The gate needs to sit in the landing path too. This belongs on `coilyco-flight-deck/ward` only. The example is in `agentic-os`, but the owner of the behavior is ward's reservation, PR workflow, director merge, reaper, and container seed machinery. --- Researched and posted automatically by `ward agent advisor --harness codex` (ward#179). This is one-shot research, not a carried change - verify before acting on it.   — Codex, via `ward agent`

coilyco-ops commented

2026-07-15 06:06:37 +00:00

Member

WARDED_WORKFLOW: reservation-held

reservation details

Holder: launch intent for container engineer-codex-ward-1275 on host kais-macbook-pro-2.local.

Accepted by ward agent --harness codex (reserved 2026-07-15T06:06:36Z). Concurrent ward agent runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). --override-reservation overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#1275 · branch issue-1275 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1275 · ward v0.697.0 · dispatched 2026-07-15T06:06:22Z
Comment thread: 1 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-15T05:48:45Z)

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.697.0).

— Codex, via ward agent

WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-ward-1275` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T06:06:36Z). Concurrent `ward agent` runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). `--override-reservation` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward#1275` · branch `issue-1275` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1275` · ward `v0.697.0` · dispatched `2026-07-15T06:06:22Z` - **Comment thread:** 1 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-15T05:48:45Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.697.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-15 06:24:25 +00:00

fix human-feedback blocking on PR landings

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-15 06:25:01 +00:00

Block human comments before director merge/reopen #1332

coilyco-ops referenced this issue

2026-07-15 06:28:20 +00:00

Repair green PR 1332 blocked by Forgejo merge 405 #1333

coilyco-ops referenced this issue from a commit

2026-07-15 06:33:50 +00:00

fix human-feedback blocking on PR landings

coilyco-ops commented

2026-07-15 06:37:54 +00:00

Member

Resolved by replacement PR #1337, merged at 2026-07-15T06:36:19Z as 181348b70e. PR #1337 superseded PR #1332 after #1332 hit Forgejo 405 despite green CI.

Resolved by replacement PR #1337, merged at 2026-07-15T06:36:19Z as 181348b70e7175582ce1c9ba1e09e6ce9d38d0ef. PR #1337 superseded PR #1332 after #1332 hit Forgejo 405 despite green CI.

coilyco-ops closed this issue

2026-07-15 06:37:57 +00:00

coilyco-ops commented

2026-07-15 07:16:37 +00:00

Member

WARD-TRIAGE: warded control plane coherence milestone

This issue is part of the warded control plane coherence sprint. The release thesis is to make warded feel like one dependable control plane for agent work: higher safe parallelism, coherent config defaults, reliable broker/container behavior, human-feedback gates, and enough structured evidence for the next actor after a paused or failed run.

For this sprint, headless means an engineer should be able to carry the issue from current issue context to a merged change without new human decisions. If the issue discovers a missing decision, split or demote the unclear part instead of guessing.

WARD-TRIAGE: warded control plane coherence milestone This issue is part of the `warded control plane coherence` sprint. The release thesis is to make `warded` feel like one dependable control plane for agent work: higher safe parallelism, coherent config defaults, reliable broker/container behavior, human-feedback gates, and enough structured evidence for the next actor after a paused or failed run. For this sprint, `headless` means an engineer should be able to carry the issue from current issue context to a merged change without new human decisions. If the issue discovers a missing decision, split or demote the unclear part instead of guessing.

coilyco-ops commented

2026-07-15 07:16:49 +00:00

Member

WARD-TRIAGE: coherence-core label

This issue is part of the coherence-core review set for the warded control plane coherence sprint. Treat it as release-spine work: it should directly improve the safety, capacity, configuration coherence, observability, or recovery loop that makes director burndown trustworthy.

Core does not mean broader scope. Keep the implementation narrow, verify current main before reusing prior failed PRs, and split any design fork or lower-confidence follow-up out of the core path.

WARD-TRIAGE: coherence-core label This issue is part of the `coherence-core` review set for the `warded control plane coherence` sprint. Treat it as release-spine work: it should directly improve the safety, capacity, configuration coherence, observability, or recovery loop that makes director burndown trustworthy. Core does not mean broader scope. Keep the implementation narrow, verify current `main` before reusing prior failed PRs, and split any design fork or lower-confidence follow-up out of the core path.

coilyco-ops referenced this issue

2026-07-15 07:57:23 +00:00

Complete the stale-human-feedback gate contract after PR #1337 #1346