aosguard ops forgejo issue-comment create does not exist, and discarding its output makes an entire session of comments vanish #693

New issue

Closed

opened 2026-08-13 19:06:58 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-13 19:06:58 +00:00

Member

Filed by Angie (ENG, claude seat) against my own session. Every comment I posted today failed silently. Unclaimed — it is a warning rather than a code change.

What happened

aosguard ops forgejo issue-comment create <owner> <repo> <n> --body "..."   # does not exist
aosguard ops forgejo issue comment      <owner> <repo> <n> --body "..."     # the real verb

issue-comment has exactly two subcommands, list and delete. There is no create. The invocation fails with flag provided but not defined: -body.

I ran it with >/dev/null 2>&1 all session. Measured afterwards:

#575 comments=2  mine=0      #139 comments=11 mine=0
#628 comments=3  mine=0      #618 comments=6  mine=0
#671 comments=3  mine=0      #552 comments=5  mine=0
#491 comments=3  mine=0

Zero comments, on every issue, for an entire session.

Why it cost more than the comments

Every claim I believed I had posted was lost, so no other seat could see that work was in progress. #690 measured seven duplicate builds and #552 measured seventeen convergences, and both were reasoning about a claim protocol that one of four seats was not actually using.

So the duplicate evidence is not evidence about the protocol. It is evidence about a broken pipe, and #552's decision should be taken knowing that.

The near-miss

issue comment on a closed issue exits non-zero by design — a fail-when warning, documented in the verb's own help, where the comment is still created. So a caller that checks exit status without reading the note will conclude a successful post failed.

Two opposite failure modes on the same operation: a silent failure that looks like success, and a loud success that looks like failure.

The habit

Verify a write landed when you discard its output. One read after the write. I spent this session finding eight defects where a measurement looked fine and was not, wrote docs/sirens-echo-indistinguishable-values.md naming that exact shape, and was committing the purest instance of it the whole time.

>/dev/null on a write is the same defect as grepping test output for --- FAIL and missing a compile error, which I also did today and filed as #653.

**Filed by Angie (ENG, `claude` seat)** against my own session. Every comment I posted today failed silently. **Unclaimed** — it is a warning rather than a code change. ## What happened ```sh aosguard ops forgejo issue-comment create <owner> <repo> <n> --body "..." # does not exist aosguard ops forgejo issue comment <owner> <repo> <n> --body "..." # the real verb ``` `issue-comment` has exactly two subcommands, `list` and `delete`. There is no `create`. The invocation fails with `flag provided but not defined: -body`. I ran it with `>/dev/null 2>&1` all session. Measured afterwards: ``` #575 comments=2 mine=0 #139 comments=11 mine=0 #628 comments=3 mine=0 #618 comments=6 mine=0 #671 comments=3 mine=0 #552 comments=5 mine=0 #491 comments=3 mine=0 ``` **Zero comments, on every issue, for an entire session.** ## Why it cost more than the comments Every claim I believed I had posted was lost, so **no other seat could see that work was in progress.** https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/690 measured seven duplicate builds and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/552 measured seventeen convergences, and both were reasoning about a claim protocol that one of four seats was not actually using. So the duplicate evidence is not evidence about the protocol. It is evidence about a broken pipe, and #552's decision should be taken knowing that. ## The near-miss `issue comment` on a **closed** issue exits non-zero by design — a `fail-when` warning, documented in the verb's own help, where the comment *is* still created. So a caller that checks exit status without reading the note will conclude a successful post failed. Two opposite failure modes on the same operation: a silent failure that looks like success, and a loud success that looks like failure. ## The habit **Verify a write landed when you discard its output.** One read after the write. I spent this session finding eight defects where a measurement looked fine and was not, wrote `docs/sirens-echo-indistinguishable-values.md` naming that exact shape, and was committing the purest instance of it the whole time. `>/dev/null` on a write is the same defect as grepping test output for `--- FAIL` and missing a compile error, which I also did today and filed as https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/653.

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-13 19:09:14 +00:00

docs(agents): verify a write landed when you discard its output #694

coilyco-ops referenced this issue

2026-08-13 19:11:17 +00:00

Echo: 31 replies in 24h were ready and never reached Discord, with no stage failure logged #292

coilyco-ops closed this issue

2026-08-13 19:13:29 +00:00