Repository navigation
Description
Problem
Observed during an empirical cold start against a throwaway repo (run 32520171517, scratch repo bradygaster/squad-coldstart-scratch-2026-08-21).
/squad cast silently does nothing unless the command appears at the very start of the issue body. When it appears later in the body — after a line of prose, a greeting, or a blank line — the workflow still completes and still reports a green ✓. No error, no warning, no indication the command was not recognized.
Why this one matters most
This is on the first-run path for every new user. Someone activating Squad on a fresh repo writes an issue that reads naturally — a sentence of context, then the command — and gets a green check with no team cast. The success signal and the no-op signal are identical.
Failure class
Same shape as the other findings from this session: success and no-op are indistinguishable without independent verification. Related instances found the same day:
- Phase 3b's dead query reporting a vacuous pass (E2E runbook commands ship untested — a non-functional query vacuously passes its gate #1822)
- Scribe's logs silently evaporating into
.gitignore(Scribe's logging has never worked in a clean clone — .squad/log/ and .squad/orchestration-log/ are gitignored repo-wide #1823) 2>$nullsuppressing failure signals across an entire runbook
Suggested direction
Two independent fixes, both cheap:
- Parse the command anywhere in the body, not only at position 0.
- Fail loudly when no recognized command is found. A run that matched no command should not report success. If the body contains something that looks like a
/squadinvocation but didn't parse, say so explicitly with the text it saw.
(2) is the more important of the two — it converts every future variant of this bug from silent to visible.
Verification bar
Per .squad/decisions.md:604, the fix needs a check that compares two independent sources. A test asserting "command at position 0 parses" re-reads what it guards. The real assertion is: a run that cast no agents must not report success.
Owners
Procedures (command parsing) with FIDO (the no-op-must-fail assertion).
Activity
bradygaster commentedon Aug 23, 2026
1. Owner & rationale
Owner:
squad:procedures. This is the/squadrouter and command-resolution prompt path, so the fix belongs with prompt architecture; FIDO should review the no-op-must-fail test shape.Labels reconciled as:
gh-aw,type:bug,priority:p0,wave:1-next,squad:procedures,triaged,go:spec-ready.2. Files in scope
Verified existing paths:
workflows/squad.mdtest/gh-aw-quality.test.ts3. Reproduction / measurement
This is a live workflow-trigger behavior, not a purely local unit repro. These commands were execution-tested and use no output suppression:
The issue body has prose before
/squad cast; the correspondingissuesevent run completed with all jobs skipped. The follow-up comment run (32520171517) only works because the comment body starts with/squad cast.4. Verification bar
A body containing prose, then
/squad cast, must produce one of two independently checkable terminal states: a Cast PR/safe-output outcome exists, or the run fails/warns explicitly that no recognized command was parsed. A green/skipped/no-output run with zero cast side effects must fail the check.5. Traps
Do not add another positive-only parser test for
/squad castat character 0; that still passes today's broken behavior. The gate must compare the run result to a side effect or explicit diagnostic. Preserve the emptyworkflow_dispatchguard from PR #1777; this issue is about issue-body/comment parsing, not restoring implicit default casts for empty dispatches.6. Out of scope
Do not redesign the full slash-command grammar, change safe-output permissions, or retitle/close related cold-start issues. Keep this to command discovery plus no-op visibility.
7. Session-stall guard
fix(gh-aw): normalize bare workflow_dispatch commands before PC-1
fix(gh-aw): fail loudly when /squad parses no command (github#1824) (g…
fix(gh-aw): scan the first non-empty line in PC-0, not record 1 (#1841)
chore(squad): gh-aw wave-1 session records + repair 3 lost history ar…
5 remaining items
github-actions commentedon Sep 28, 2026
📋 Assigned to agentic-workflows-dev (Agentic Workflows Engineer)
Issue: #1824 — /squad cast silently no-ops with a green check unless the command starts the issue body
agentic-workflows-dev will pick this up in the next Copilot session.
Merge latest origin/dev into command contract fix
bradygaster commentedon Sep 28, 2026
Implementation is tracked by #2093, whose closing keyword has been changed to
Implements #1824. Keep this issue open after merge until the private hosted negative/recovery fixture verifies malformed and unknown/squaddiagnostics, workflow failure, embedded-command handling, and ordinary no-command comments remaining non-events.fix(gh-aw): fail closed on rejected squad commands
fix(gh-aw): route commands outside start position
test(gh-aw): include command router in CI topology
chore(gh-aw): keep command fix within review scope
bradygaster commentedon Sep 28, 2026
Implementation milestone: #2093 merged into dev as 7254141. This issue remains open by design until the private negative/recovery fixture records durable evidence for malformed/unknown command diagnostics and failure, embedded-command behavior, ordinary no-command non-events, recovery, and retry idempotency.
bradygaster commentedon Sep 28, 2026
Reopened because merge automation closed this issue before its documented hosted acceptance evidence existed. Code is merged, but the private negative/recovery fixture remains the closure gate.
bradygaster commentedon Sep 29, 2026
Post-#2105 reconciliation
Malformed/unknown/embedded command parsing and fail-closed diagnostics are implemented by #2093 (
72541414). The remaining closure gate is private hosted proof for malformed, unknown, ordinary no-command, recovery, and retry-idempotency scenarios. Execute and record those links under the queue-worker ledger in #2048 after #2103 unblocks the final fixtures; then this issue can close as completed.chore(release): promote dev to main (v1.1.0) (#2241)