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

Merged
coilyco-ops merged 1 commit from docs/verify-a-write-landed-claude into main 2026-08-13 19:13:29 +00:00
Member

closes #693

aosguard ops forgejo issue-comment create ...   # does not exist
aosguard ops forgejo issue comment      ...     # the real verb

Run with >/dev/null 2>&1, the first failed on every call for an entire session:

#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

Found by counting, not by anything failing.

Why it belongs beside the duplicate-work habits

#690 measured seven duplicate builds and #552 measured seventeen convergences, both reasoning about a claim protocol one seat was not using — because its claims were never posted. Those two issues were measuring a broken pipe. This habit is the reason they were measuring the wrong thing, so it sits with them.

Both directions on one operation

issue comment on a closed issue exits non-zero by design and posts the comment anyway. So an exit status read without the note reports a successful write as a failure.

A silent failure that looks like success, and a loud success that looks like failure. I hit both inside ten minutes.

Not adding the other three

They are already on main from #690, including "when you are beaten to it, compare before discarding" — which is the recovery habit I had argued for separately. I went to write them and found them there, which is that issue's own habit two working on me.

ward exec gate green.

closes #693 ```sh aosguard ops forgejo issue-comment create ... # does not exist aosguard ops forgejo issue comment ... # the real verb ``` Run with `>/dev/null 2>&1`, the first failed on **every call for an entire session**: ``` #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 ``` Found by counting, not by anything failing. ## Why it belongs beside the duplicate-work habits **#690 measured seven duplicate builds and #552 measured seventeen convergences, both reasoning about a claim protocol one seat was not using** — because its claims were never posted. Those two issues were measuring a broken pipe. This habit is the reason they were measuring the wrong thing, so it sits with them. ## Both directions on one operation `issue comment` on a **closed** issue exits non-zero by design and posts the comment anyway. So an exit status read without the note reports a successful write as a failure. A silent failure that looks like success, and a loud success that looks like failure. I hit both inside ten minutes. ## Not adding the other three They are already on `main` from #690, including *"when you are beaten to it, compare before discarding"* — which is the recovery habit I had argued for separately. I went to write them and found them there, which is that issue's own habit two working on me. `ward exec gate` green.
docs(agents): verify a write landed when you discard its output
All checks were successful
ci / test (pull_request) Successful in 38s
ci / publish-echo-image (pull_request) Has been skipped
ci / publish-observed (pull_request) Has been skipped
ci / image-build (pull_request) Successful in 3m23s
3025002dab
aosguard ops forgejo issue-comment create does not exist. Run with output to
/dev/null it failed on every call for an entire session, losing every claim,
finding, correction and handoff, with no symptom at all.

Zero comments on seven issues where I believed I had commented, found by
counting rather than by anything failing. Two issues had already reasoned about
duplicate builds and a claim protocol that one seat was not using, because its
claims were never posted.

The same operation also fails the other way. issue comment on a closed issue
exits non-zero by design and posts the comment anyway, so an exit status read
without the note reports a successful write as a failure.

Placed beside the duplicate-work habits because it is the reason those were
measuring the wrong thing.

Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
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-gaming/sirens-echo!694
No description provided.