Skip to content

[finding] post-stamped exits 4 (EXIT_NOT_STORED) on a comment that DID land — the platform moves the trailing newline to before the seat's own --- footer (net zero bytes) and sentBodyLanded reads that as a lost byte #18709

Description

@os-justin

Class a — reproducible on every comment the skills seat posts with its own attribution footer, since PR #18690 (#18663) landed at 15:58Z. The write lands; the tool says it did not.

Reading (nine comments, 15:59Z–16:03Z, main 2fd23d098 and after)

Every seat record posted after PR #18690 reached main exits 4. The tool's own read-back line on each: 「sent N byte(s), stored N — MUTATED … first difference at byte K: sent …---\n_Generated by [Claude Code](https://claude.ai/code)_\n | stored …\n---\n_Generated by [Claude Code](https://claude.ai/code)_ — ⛔ a byte this act sent is NOT the byte stored at that offset — the write did NOT land. Exit 4.」 Equal length, every time.

Byte-exact, from comment 5717446818 on #18426 (sent 1591, stored 1591, first difference at 1534, identical before it):

sent   tail: ' same act.\n\n---\n_Generated by [Claude Code](https://claude.ai/code)_\n'
stored tail: ' same act.\n\n\n---\n_Generated by [Claude Code](https://claude.ai/code)_'

The platform strips the trailing newline and inserts one blank line before the rule: one byte moved, zero lost. The same nine comments read back intact before that offset (the seat compared each). This is exactly the shape platform-readings.md :357 records as 「送全块即触发该归一 ⇒ post-stampedbody 档把这点空白判 mutated,净零字节良性告警」 — the benign re-anchor — and PR #18690's own report described it as the shape the seat hits on every seat-post refresh.

Why the predicate misses it

sentBodyLanded(readBack) (scripts/pm/post-stamped.mjs :952) forgives class mutated only when footerReAnchored === true, and footerReAnchoring(sent, stored) (:931) answers non-null only when the stored body is the sent body, or its newline-trimmed form, followed by EXACTLY PLATFORM_COMMENT_FOOTER — an APPENDED footer. A body that already carries the footer and gets its blank lines normalised around the rule matches neither arm: the first difference lands inside the sent body, so the offset test says 「a byte this act sent is not there」. The #18690 battery pinned 「a body-mode footer re-anchoring ⇒ exit 0」 for the appended-footer shape, not for the moved-newline shape on a body that already ends in the footer. Offline, the simpler shape (sent X\n + footer + \n, stored X\n\n---… with no blank-line insertion) classifies as trailing-newline-stripped and passes; the live shape has the extra blank line and does not.

Consequence

Every seat artefact with a footer now reads NOT STORED in $?. A caller that obeys the new contract (「exit 4 ⇒ do not retry, read the artefact」) stops on every write; a caller that ignores it has learned to ignore exit 4, which is the state PR #18690 existed to end. The skills seat's landing script aborted its ready/auto-merge step on the ACCEPT's exit 4 this hour (PR #18700; the seat re-read the comment and armed by hand).

Remedy (the successor's)

Teach footerReAnchoring the second re-anchor shape: stored equals sent with the trailing newline removed and one newline inserted immediately before the final \n---\n + footer (equal length, one byte moved), for both modes; pin it byte-for-byte from the read-back above, with the appended-footer case and a real-loss control (a byte missing before the rule still exits 4). Serial on scripts/pm/post-stamped.mjs behind #18543 and #18693, or folded into #18693, which touches the same normalisation set.

Provenance

Skills seat session_01Gqi43smmqjJ5sUrhfoPeKu, measured on its own writes. Dedupe words: post-stamped exit 4, EXIT_NOT_STORED false positive, footerReAnchoring, trailing newline moved before rule, sentBodyLanded. Checked against the 533 open issues at 15:10Z plus #18693 (the header's unmeasured cell — the body-mode warning, not the exit code) and the closed #18663 (the fix that introduced the code); none is this.


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions