coilyco-flight-deck/ward

Fork 0

warded advisor dispatch launches context-less: no issue ref or question in the advisor prompt (empty preflight dir), though the reply routes correctly #548

New issue

Closed

opened 2026-07-03 06:05:07 +00:00 by coilysiren · 3 comments

coilysiren commented

2026-07-03 06:05:07 +00:00

Owner

Symptom

warded advisor coilyco-gaming/eco-ops#26 "<read-only investigation question>" fired from a warded director surface. The broker accepted it and forwarded the correct command to host ward:

ward agent advisor coilyco-gaming/eco-ops#26 --driver claude --thoroughness standard <full question text>

But the launched advisor reported it had no issue ref and no question text in its instructions, and its working directory was an empty ward-preflight temp folder (C:\Users\firem\AppData\Local\Temp\ward-preflight-...) with no repo checkout. So it did no research and posted a "please give me the ref" comment.

The tell

The reply still routed to the correct issue - the comment landed on coilyco-gaming/eco-ops#26. So the issue ref reaches the reply-router but not the advisor's research prompt or working context. The clone / context-injection step is where it breaks, not the routing.

Impact

Every warded advisor <ref> "question" dispatch is a no-op that posts a confusing "I need the ref" comment onto the target issue.
Blocks the eco o11y dispatch plan: eco-ops#26 (verify telemetry) could not run, and eco-ops#25 / ward#547 sit behind it.

Evidence

Comment by coilyco-ops on coilyco-gaming/eco-ops#26 at 2026-07-03T06:03:18Z ("the working directory is empty ... no issue reference ... I don't have anything to research").
Director-side broker forward line shows the ref + question were present in the forwarded command.
Host run log: C:\Users\firem\.ward\agent-logs\dispatch\20260703T054857Z-session-claude-e1af15ad-coilyco-gaming-eco-ops-26.log.

To pin down

Is the freeform question's quoting lost in the broker forward (one quoted arg → many trailing bare args)? Even if so, the bare issue ref alone should still drive a clone + issue-fetch, which also did not happen.
Does warded engineer <ref> (which clones the repo) hit the same context gap, or is this advisor-freeform-specific?

ward#547 (director observe capability - same dispatch/tooling neighborhood)
ward#539 (ward-kdl -> ward migration)

## Symptom `warded advisor coilyco-gaming/eco-ops#26 "<read-only investigation question>"` fired from a warded director surface. The broker accepted it and forwarded the correct command to host ward: ``` ward agent advisor coilyco-gaming/eco-ops#26 --driver claude --thoroughness standard <full question text> ``` But the launched advisor reported it had **no issue ref and no question text in its instructions**, and its working directory was an **empty ward-preflight temp folder** (`C:\Users\firem\AppData\Local\Temp\ward-preflight-...`) with no repo checkout. So it did no research and posted a "please give me the ref" comment. ## The tell The reply still routed to the correct issue - the comment landed on coilyco-gaming/eco-ops#26. So **the issue ref reaches the reply-router but not the advisor's research prompt or working context.** The clone / context-injection step is where it breaks, not the routing. ## Impact - Every `warded advisor <ref> "question"` dispatch is a no-op that posts a confusing "I need the ref" comment onto the target issue. - Blocks the eco o11y dispatch plan: eco-ops#26 (verify telemetry) could not run, and eco-ops#25 / ward#547 sit behind it. ## Evidence - Comment by `coilyco-ops` on coilyco-gaming/eco-ops#26 at 2026-07-03T06:03:18Z ("the working directory is empty ... no issue reference ... I don't have anything to research"). - Director-side broker forward line shows the ref + question were present in the forwarded command. - Host run log: `C:\Users\firem\.ward\agent-logs\dispatch\20260703T054857Z-session-claude-e1af15ad-coilyco-gaming-eco-ops-26.log`. ## To pin down - Is the freeform question's quoting lost in the broker forward (one quoted arg → many trailing bare args)? Even if so, the bare issue ref alone should still drive a clone + issue-fetch, which also did not happen. - Does `warded engineer <ref>` (which clones the repo) hit the same context gap, or is this advisor-freeform-specific? ## Related - ward#547 (director observe capability - same dispatch/tooling neighborhood) - ward#539 (ward-kdl -> ward migration)

coilyco-ops commented

2026-07-03 06:15:41 +00:00

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-548 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-03T06:15:10Z). 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 `engineer-claude-ward-548` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-03T06:15:10Z). 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 commented

2026-07-03 06:16:14 +00:00

Author

Owner

Director dispatched warded engineer coilyco-flight-deck/ward#548 at 2026-07-03T06:14Z (broker-forwarded to host ward; host log 20260703T061435Z-session-claude-188b0fe8-...-ward-548.log).

This run doubles as the live diagnostic for this ticket's own open question — does warded engineer <ref> hit the same context gap as advisor-freeform, or is the bug advisor-specific? Read the outcome accordingly:

If this engineer run clones the repo, sees #548, and lands a fix → the gap is advisor-freeform-specific (quoting/context-injection on the freeform path only), and the fix here should cover advisor too.
If this engineer run also launches context-less (empty preflight dir, no ref in its prompt) → the bug is universal to the dispatch/context-injection step, not advisor-specific, and it self-demonstrates on this very ticket.

Dispatched under Kai's go (session moved from file-tickets mode into fix-dispatch for the keystone blocker).

Director dispatched `warded engineer coilyco-flight-deck/ward#548` at 2026-07-03T06:14Z (broker-forwarded to host ward; host log `20260703T061435Z-session-claude-188b0fe8-...-ward-548.log`). This run doubles as the live diagnostic for this ticket's own open question — **does `warded engineer <ref>` hit the same context gap as advisor-freeform, or is the bug advisor-specific?** Read the outcome accordingly: - If this engineer run **clones the repo, sees #548, and lands a fix** → the gap is advisor-freeform-specific (quoting/context-injection on the freeform path only), and the fix here should cover advisor too. - If this engineer run **also launches context-less** (empty preflight dir, no ref in its prompt) → the bug is universal to the dispatch/context-injection step, not advisor-specific, and it self-demonstrates on this very ticket. Dispatched under Kai's go (session moved from file-tickets mode into fix-dispatch for the keystone blocker).

coilysiren referenced this issue from a commit

2026-07-03 06:37:25 +00:00

fix(agent): feed the host one-shot prompt on stdin, not the command line (closes #548)

coilysiren closed this issue

2026-07-03 06:37:25 +00:00

coilysiren commented

2026-07-03 06:38:06 +00:00

Author

Owner

WARD-OUTCOME: done - host one-shot prompt now rides stdin, not the command line, so a multi-line advisor/preflight read can't be truncated on Windows.

Landed on main at commit b941183.

How it felt: the diagnosis was the whole job, the fix was four lines of plumbing. The symptom looked like a routing/quoting bug, but urfave/cli parsing and the broker forward all checked out fine under test - the ref and question survive to the host advisor command intact. What actually broke was one layer down: every host one-shot (advisor research, engineer pre-flight, route survey, triage/heartbeat) is only ever run by claude, and ward handed it the long multi-line prompt as the final claude -p <prompt> argv element. On a Windows host that argument gets truncated at its first newline, so claude saw only the preamble - and the issue ref + question sit below it. The tell that clinched it: this ticket dispatched an engineer run (my own container) as a live diagnostic, and I had full context - because the container seed is a separate channel from the host one-shot. So engineer masks the bug, advisor exposes it.

Fix: lift the prompt off the command line onto the child's stdin at the single chokepoint. claude -p reads a piped, non-TTY stdin as the prompt, so it's a no-op where the argv form already worked (macOS/Linux) and immune to Windows arg/batch-shim mangling.

Confidence: high on the mechanism and the direction; the two new tests lock the invariant (prompt never on argv; it round-trips through a /bin/cat child's stdin). The one thing I could not exercise from a Linux container is the actual Windows truncation or a live claude -p stdin read - both are reasoned, not observed. If a Windows host is handy, a single real warded advisor <ref> "q" is the real confirmation.

Rough edges / fought back: the repo-wide code-comments pre-commit hook was already red on main (five over-cap comment blocks from the recent Windows-build commits, which landed via merge commits that skip the hook). Since it's not diff-aware and --no-verify is off the table, I had to condense those five to land green - and main had independently condensed the same blocks mid-flight, so the merge conflicted on comment text only (took main's side). Worth a follow-up: that hook being non-diff-aware means any pre-existing violation blocks every unrelated commit - a papercut that will bite the next agent too.

WARD-OUTCOME: done - host one-shot prompt now rides stdin, not the command line, so a multi-line advisor/preflight read can't be truncated on Windows. Landed on `main` at commit b941183. How it felt: the diagnosis was the whole job, the fix was four lines of plumbing. The symptom looked like a routing/quoting bug, but urfave/cli parsing and the broker forward all checked out fine under test - the ref and question survive to the host `advisor` command intact. What actually broke was one layer down: every host one-shot (advisor research, engineer pre-flight, route survey, triage/heartbeat) is only ever run by `claude`, and ward handed it the long multi-line prompt as the final `claude -p <prompt>` argv element. On a Windows host that argument gets truncated at its first newline, so claude saw only the preamble - and the issue ref + question sit below it. The tell that clinched it: this ticket dispatched an *engineer* run (my own container) as a live diagnostic, and I had full context - because the container seed is a separate channel from the host one-shot. So engineer masks the bug, advisor exposes it. Fix: lift the prompt off the command line onto the child's stdin at the single chokepoint. `claude -p` reads a piped, non-TTY stdin as the prompt, so it's a no-op where the argv form already worked (macOS/Linux) and immune to Windows arg/batch-shim mangling. Confidence: high on the mechanism and the direction; the two new tests lock the invariant (prompt never on argv; it round-trips through a `/bin/cat` child's stdin). The one thing I could not exercise from a Linux container is the actual Windows truncation or a live `claude -p` stdin read - both are reasoned, not observed. If a Windows host is handy, a single real `warded advisor <ref> "q"` is the real confirmation. Rough edges / fought back: the repo-wide `code-comments` pre-commit hook was already red on `main` (five over-cap comment blocks from the recent Windows-build commits, which landed via merge commits that skip the hook). Since it's not diff-aware and `--no-verify` is off the table, I had to condense those five to land green - and `main` had independently condensed the same blocks mid-flight, so the merge conflicted on comment text only (took `main`'s side). Worth a follow-up: that hook being non-diff-aware means any pre-existing violation blocks every unrelated commit - a papercut that will bite the next agent too.

coilysiren referenced this issue

2026-07-03 08:29:59 +00:00

fix(agent): Windows pre-flight silently no-ops - cmd.exe shim truncates the multi-line prompt at the first newline #560

coilysiren referenced this issue

2026-07-03 09:10:47 +00:00

advisor: default warded advisor to --tailnet (live-observe access) so ref-mode research can verify live signal #562