coilyco-flight-deck/ward

Archived

Watch

when posting an issue comment on a closed issue, respond with a warning that the issue is closed #380

Closed

opened 2026-06-26 08:24:37 +00:00 by coilysiren · 2 comments

coilysiren commented

2026-06-26 08:24:37 +00:00

Owner

needs to be possible entirely via ward KDL

coilysiren added the

priority

autonomy

headless

labels

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

coilyco-ops commented

2026-07-01 04:44:51 +00:00

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-380 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-01T04:44:49Z). 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-380` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-01T04:44:49Z). 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 referenced this issue from a commit

2026-07-01 04:57:25 +00:00

feat(ops): warn when commenting on a closed forgejo issue (closes #380)

coilysiren closed this issue

2026-07-01 04:57:41 +00:00

coilysiren commented

2026-07-01 04:58:27 +00:00

Author

Owner

WARD-OUTCOME: done - ward ops forgejo issue comment now warns (non-zero exit) when the target issue is closed, authored purely in the ward-kdl guardfile.

Retrospective (posted via the new action itself, against this now-closed issue - so if you're reading a non-zero exit on my side, that's the feature working):

The "entirely via ward KDL" constraint was the whole puzzle, and it turned out to be the good kind. cli-guard already had every primitive I needed: a mount action that shadows a leaf (like view issue), multi-call data-flow, and fail-when over a JMESPath. So this became a get-then-comment call action with fail-when "$issue.state == 'closed'" - no Go composite, which is exactly what the issue asked for.

What fought back a little: fail-when is the only conditional exit in the grammar, so the "warning" is a non-zero exit, not a soft notice - the comment still posts, the exit code is the loud signal. I convinced myself $issue.state (variable sub-field access) actually evaluates before building anything by probing the real respfmt evaluator - glad I did, it's the load-bearing line. The other wrinkle: a mount call action always renders every as binding, so issue comment output changed from the bare comment to {comment, issue}. That's a minor v0.x API break, noted in the commit.

Confidence: high on the mechanics - build/test/vet green, dry-run plan correct, predicate probed, and this very comment is the live closed-path test. The rough edge worth a follow-up: the fail-when message is cli-guard's generic "predicate matched" rather than a tailored "issue #N is closed" - a custom fail-when { message ... } in cli-guard would make the warning speak for itself, but that's upstream and out of this container's granted scope.

WARD-OUTCOME: done - `ward ops forgejo issue comment` now warns (non-zero exit) when the target issue is closed, authored purely in the ward-kdl guardfile. Retrospective (posted via the new action itself, against this now-closed issue - so if you're reading a non-zero exit on my side, that's the feature working): The "entirely via ward KDL" constraint was the whole puzzle, and it turned out to be the good kind. cli-guard already had every primitive I needed: a mount `action` that shadows a leaf (like `view issue`), multi-`call` data-flow, and `fail-when` over a JMESPath. So this became a get-then-comment call action with `fail-when "$issue.state == 'closed'"` - no Go composite, which is exactly what the issue asked for. What fought back a little: `fail-when` is the only conditional exit in the grammar, so the "warning" is a non-zero exit, not a soft notice - the comment still posts, the exit code is the loud signal. I convinced myself `$issue.state` (variable sub-field access) actually evaluates before building anything by probing the real respfmt evaluator - glad I did, it's the load-bearing line. The other wrinkle: a mount call action always renders every `as` binding, so `issue comment` output changed from the bare comment to `{comment, issue}`. That's a minor v0.x API break, noted in the commit. Confidence: high on the mechanics - build/test/vet green, dry-run plan correct, predicate probed, and this very comment is the live closed-path test. The rough edge worth a follow-up: the fail-when message is cli-guard's generic "predicate matched" rather than a tailored "issue #N is closed" - a custom `fail-when { message ... }` in cli-guard would make the warning speak for itself, but that's upstream and out of this container's granted scope.

Commenting is not possible because the repository is archived.

No milestone

No project

No assignees

2 participants

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/ward#380

No description provided.

Rows
Columns