You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[finding] post-stamped.mjs's header declares the issue-body footer cell UNMEASURED while platform-readings carries the measurement — every seat-post refresh prints a MUTATED warning #18693
Class b — the file's own stated condition for moving a cell is met, and the cell has not moved.
Reading
scripts/pm/post-stamped.mjs docblock on main1bc22b3dc, around :247: 「whether the platform synthesises a footer for a footer-less ISSUE BODY is unmeasured, and an unmeasured cell is not a cell this tool forgives — a footer on a body read-back stays MUTATED until somebody measures it」. The pin at :1662 (「⭐ THE CONTROL: the same append in BODY mode stays MUTATED — an unmeasured cell is not forgiven」) holds it there.
Measured by the skills seat on every seat-post refresh today (--body=7623): sent 35850 → stored 35908; sent 39022 → stored 39080; sent 12331 → stored 12389. The difference is the declared 58-byte footer each time. The four landing records posted on cards at 15:04Z read 「sent 1091 byte(s), stored 1091 — MUTATED」 with the first difference at the trailing rule: the re-anchor form, net zero bytes.
Why this is a defect, not a preference
The header says the cell moves when somebody measures it. It has been measured, in the governed table, on both the create side and the re-anchor side. So --body prints a MUTATED warning on nearly every write — the noise #18296 removed for the other classes — and a warning that fires on every write is one nobody reads, which defeats the read-back. PR #18690 (#18663) now measures the re-anchor as benign FOR THE EXIT CODE (footerReAnchoring, exit 0), so after it lands the tool says two things about the same bytes: 「everything sent is on the platform」 in $? and 「MUTATED」 on stderr.
Remedy (the successor's, not ruled here)
Move the body-mode footer append and the trailing-rule re-anchor out of mutated into a benign class — the comment-mode footer-appended class already exists, and footerReAnchoring from PR #18690 is the one spelling of the comparison — citing :357 and :410 as the measurement, and re-pin :1662 to the new verdict. Or, if the tool keeps the cell as it is, rewrite the header so it stops calling a measured cell unmeasured. Serial on scripts/pm/post-stamped.mjs behind PR #18690 (in flight) and #18543 (queued on the same file).
Provenance
Raised independently by the dev of #18663 (report 5716492346, class b) and the dev of #18426 (report 5716488532, noted and not filed); filed once by the skills seat. Dedupe words: post-stamped, classifyReadBack, footer-appended, issue body, unmeasured cell, platform-readings. Checked against the 533 open issues at 15:10Z: #18467 (the table side, landing in PR #18689), #18543 (the {{NOW}} substitution inside a quotation) and #18663 (the exit code) are neighbours; none is this.
Class b — the file's own stated condition for moving a cell is met, and the cell has not moved.
Reading
scripts/pm/post-stamped.mjsdocblock onmain1bc22b3dc, around :247: 「whether the platform synthesises a footer for a footer-less ISSUE BODY is unmeasured, and an unmeasured cell is not a cell this tool forgives — a footer on a body read-back stays MUTATED until somebody measures it」. The pin at :1662 (「⭐ THE CONTROL: the same append in BODY mode stays MUTATED — an unmeasured cell is not forgiven」) holds it there..claude/skills/pm-dispatch/references/platform-readings.md:410 「建卡走 RESTPOST /issues:带页脚存活,无页脚合成恰一条(+58);回读后PATCH重送逐字节存下。」 (create side; PR docs(pm-skills): adopt eight measured platform readings into the governed fact table, each paid in place #18689 refines it in place) and, landing in PR docs(pm-skills): adopt eight measured platform readings into the governed fact table, each paid in place #18689 as the operating half of [finding] a full---+ footer BLOCK sent to an issue body through bare REST is RE-ANCHORED, not doubled — one newline moves, the net is zero bytes, and post-stamped reads the whitespace asmutated#18467, :357 「送全块即触发该归一 ⇒post-stamped的body档把这点空白判mutated,净零字节良性告警。」.--body=7623): sent 35850 → stored 35908; sent 39022 → stored 39080; sent 12331 → stored 12389. The difference is the declared 58-byte footer each time. The four landing records posted on cards at 15:04Z read 「sent 1091 byte(s), stored 1091 — MUTATED」 with the first difference at the trailing rule: the re-anchor form, net zero bytes.Why this is a defect, not a preference
The header says the cell moves when somebody measures it. It has been measured, in the governed table, on both the create side and the re-anchor side. So
--bodyprints a MUTATED warning on nearly every write — the noise #18296 removed for the other classes — and a warning that fires on every write is one nobody reads, which defeats the read-back. PR #18690 (#18663) now measures the re-anchor as benign FOR THE EXIT CODE (footerReAnchoring, exit 0), so after it lands the tool says two things about the same bytes: 「everything sent is on the platform」 in$?and 「MUTATED」 on stderr.Remedy (the successor's, not ruled here)
Move the body-mode footer append and the trailing-rule re-anchor out of
mutatedinto a benign class — the comment-modefooter-appendedclass already exists, andfooterReAnchoringfrom PR #18690 is the one spelling of the comparison — citing :357 and :410 as the measurement, and re-pin :1662 to the new verdict. Or, if the tool keeps the cell as it is, rewrite the header so it stops calling a measured cell unmeasured. Serial onscripts/pm/post-stamped.mjsbehind PR #18690 (in flight) and #18543 (queued on the same file).Provenance
Raised independently by the dev of #18663 (report 5716492346, class b) and the dev of #18426 (report 5716488532, noted and not filed); filed once by the skills seat. Dedupe words: post-stamped, classifyReadBack, footer-appended, issue body, unmeasured cell, platform-readings. Checked against the 533 open issues at 15:10Z: #18467 (the table side, landing in PR #18689), #18543 (the
{{NOW}}substitution inside a quotation) and #18663 (the exit code) are neighbours; none is this.Generated by Claude Code