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

New issue

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

headless

labels

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

coilyco-ops commented

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

Member

🔒 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.