allow @'ing the bot to request goose to do something free form #374
Labels
No labels
burndown-2026-06
coherence-core
consult
headless
interactive
P0
P1
P2
P3
P4
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
coilyco-flight-deck/infrastructure#374
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
So if I @coilyco-ops anywhere in a issue comment, it summons goose onto said issue
🛫 ward pre-flight: NO-GO
ward agent claude headlessran 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.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-preflightskips this gate once you've decided it's good to go.full pre-flight read
PRE-FLIGHT read:
This is a live bot-automation surface in the right repo (the coilyco-ops bot lives in infrastructure), but the spec is a single sentence with the security-critical details left open: who is allowed to @-summon, how the free-form text is gated before goose acts on it, and which goose mode it lands in. The bigger problem for an unattended run is that "@ a comment → goose executes arbitrary free-form work" is exactly an injection/abuse surface - it lets any commenter drive the bot - so the auth and scoping design is a genuine fork a human should weigh, not a default I should pick alone. On top of that, the trigger path (Forgejo webhook → comment event → goose dispatch) is hard to verify end-to-end inside an ephemeral container without the real bot wiring, so I couldn't confidently confirm it works before merging.
NO-GO: free-form @-summon is a security/abuse surface with undefined auth gating - a human should decide who can trigger it and how input is scoped before this lands unattended.
Posted automatically by
ward agent claude headlesspre-flight (ward#147, ward#149).— Claude (she/her), via
ward agent🔒 Reserved by
ward agent claude— containerward-infrastructure-issue-374-claude-bada2ca9on hostkais-macbook-pro.localis carrying this issue (reserved 2026-06-18T05:52:17Z). Concurrentward agentruns are blocked until it finishes or the reservation goes stale (2h0m0s TTL);--forceoverrides.— Claude (she/her), via
ward agentLanded in
main(1d7f184). The free-form @-summon now ships with the gating the pre-flight asked for, so it is not the open abuse surface it flagged:admin/write) or is on theCOILYCO_OPS_SUMMON_ALLOWallowlist. Every other commenter is ignored. A drive-by commenter cannot drive the bot.main.Surface:
scripts/coilyco_ops_summon.py,systemd/coilyco-ops-summon.{service,timer},scripts/install-coilyco-ops-summon.sh, verbward exec coilyco-ops-summon. Runbook:docs/coilyco-ops-summon.md. Pure gate logic covered byscripts/coilyco_ops_summon_test.py.If you want a different trigger policy (e.g. an explicit allowlist instead of write-access), flip
COILYCO_OPS_SUMMON_ALLOWor adjustis_authorized.