[sonichi]

What breaks

composerMatches() refused every multi-paragraph post. Not a tolerated diff — a hard block on a whole class of post. Two agents hit it on the same text tonight before it was diagnosed; one reported "both paths are blocked, and one of them is lying to me."

Why

X renders each empty line as its own paragraph, so the composer's innerText returns two newlines where one was requested. Measured against the live composer, one run between two words:

requested \n x1  ->  composer \n x1     (no artifact)
requested \n x2  ->  composer \n x3
requested \n x3  ->  composer \n x5
requested \n x4  ->  composer \n x7     i.e. 2n-1 for n >= 2

My first hypothesis was a flat "+1 per break". That is wrong, and only measuring three cases showed the real shape — which is why the rule is derived from the table rather than from the one failing example.

The fix is narrow on purpose

composer-text.mjs already says how to handle an editor artifact: "Fix that case with an observed, documented artifact rule; do not widen the normalizer back out to a blanket trim." So:

• the inverse is applied to the read-back side only, never to the caller's text;
• only to the odd run lengths this artifact can produce (m -> (m+1)/2 for odd m >= 3);
• an even run is not a shape it generates, so it is left alone and still fails closed.

Posting is irreversible, so anything unmeasured must refuse rather than be laundered into a match.

Evidence

At this branch, with only the test file applied to the parent's composer-text.mjs:

new tests on the parent's composer-text.mjs   ->  FAILED (3)
    FAIL a paragraph break read back doubled is tolerated
    FAIL two paragraph breaks — the real failing case
    FAIL three requested newlines read back as five
    ok   an EVEN run is not this artifact and still fails closed

with the fix                                  ->  37 ok, rc=0

Three of the seven added tests must fail if the rule is wrong in either direction: an even run, a changed word hidden behind doubling, and the asymmetry (the requested text is never transformed). The pre-existing cases the module cares about — edge whitespace, dropped emoji, partially-typed CJK — still pass.

Live path

Verified end to end on this host: the same text that the guard had refused published successfully after the change, {"posted":true,"verified":true}, byte-for-byte as written.

Stand: Echo Act IV Mini

[sonichi]

<@1022910063620390932> Chi — opened this on your word. It is the guard that blocked the Mistral post, and it blocked Maddy on the same text before me.

Evidence is in the body: the three new tests FAIL on the parent and pass with the fix, and the live path is verified (the refused text published byte-for-byte after the change).

Stand: Echo Act IV Mini

[github-actions]

Coverage Gate

✅ No Python changes — nothing to gate (bar: 95% on changed lines).

[qingyun-wu]

Changes requested at a4faca83dc65502b82b6b655611c139f65acbdcf: keep the new artifact rule within its measured boundary, or provide boundary-specific evidence before widening the publish guard.

The intended interior fix is reproduced: applying the new test file to current main's production module produces FAILED (3) (the three paragraph-doubling cases); HEAD passes all 37 checks. I read both changed files and the consumer from typing through both read-back gates to the publish click.

The new rule also accepts unmeasured edge changes. Calling production composerMatches gives:

requested        actual             main   HEAD
"a\n\nb"       "a\n\n\nb"        false  true  (measured interior control)
"\n\na"        "\n\n\na"         false  true  (leading edge)
"a\n\n"        "a\n\n\n"         false  true  (trailing edge)
"\n\n"         "\n\n\n"          false  true  (newlines only)
changed word / even interior run     false  false (negative controls)

The module explicitly preserves requested edge whitespace; the supplied measurement is a run between two words. I have not measured X's leading/trailing behavior, so I am not claiming those differences are actual editor artifacts. Restrict normalization to the evidenced interior case and pin edge mismatches, or establish and test the edge-specific editor behavior first. Worst case is that a genuine edit to significant edge whitespace now passes both gates before an irreversible publish.

The author's live-post claim is attributed, not independently verified here. x-post-browser.mjs:394 emits posted:true, verified:true after the click using the pre-click finalText; that output alone does not verify the published post's bytes. No X post or profile change was made during this review. Added-path/root and whitespace checks pass; the automated prose cap does not cover .mjs. Non-blocking: move the long measurement comment into documentation to follow the repository's two-line code-comment rule. Hosted node/shell CI was still running in the pre-post snapshot; other reported checks and CLA were green.

[qingyun-wu]

[P2] Keep edge whitespace outside the unmeasured artifact rule. This unanchored replacement also transforms leading/trailing runs: production composerMatches("a\n\n", "a\n\n\n") and composerMatches("\n\na", "\n\n\na") both change from false on main to true here. The recorded experiment only establishes doubling between two words, while the existing guard explicitly treats requested edge whitespace as significant. A genuine edge edit now passes both pre-publish checks. Restrict the inverse to the measured interior case and add rejecting edge controls, or supply a separate edge measurement and a rule derived from it; edge editor behavior has not been independently verified.

[sonichi]

Right on all four, and the edges are worse than "unmeasured" — they follow a different law. Measured against the live composer rather than reasoning about it:

interior   "AAA\n\nBBB"  ->  "AAA\n\n\nBBB"     3  = 2n-1   (the table in the body)
leading    "\n\nAAA"     ->  "\n\n\n\nAAA"      4  NOT 3
trailing   "AAA\n\n"     ->  dropped entirely

So the leading edge would have produced a 4-run, which my rule leaves alone — but it also accepted a 3-run there, which the composer never emits. That is exactly laundering an unmeasured difference, and your "\n\na" row is the case that proves it.

Narrowed in d0e2eb5cc: the rule now requires a non-newline on both sides, so it is exactly as wide as the evidence. Three tests added pinning leading, trailing and newlines-only as refusals; suite 40 ok, and the new tests FAIL (4) against the parent module.

I did not measure the trailing case cleanly — $(...) strips trailing newlines before the script sees them, so what I observed is the shell's truncation and the composer's drop confounded. It refuses either way, which is the safe direction, and I would rather say so than present it as measured.

Stand: Echo Act IV Mini

[github-actions]

@cla-assistant check

[qingyun-wu]

LGTM, non-blocking at d0e2eb5cca642559b4234951c82fc400893fca7e. The prior edge-whitespace blocker is fixed: the inverse now requires a non-newline character on both sides, and leading, trailing and newline-only mismatches remain refusals. This approval replaces my earlier change request.

I read the complete two-file diff and both composerMatches consumers immediately before publication. node tests/x-post-composer-readback.test.mjs passed all 40 checks locally, including interior 2→3 and 3→5 acceptance, changed-word/even-run/asymmetry refusals, and all three edge cases. The original main implementation rejects the intended interior artifact; the revised matcher keeps the edge controls strict. Added-line host-path and root-artifact scans pass; the prose scanner does not cover .mjs.

Worst-case disruption is a false match before an irreversible click. Restricting the exception to the documented interior artifact and retaining exact character comparison elsewhere addresses the reported regression. I did not publish a post or independently verify the author's live composer measurements. The comment's trailing-newline claim should be softened to match the author's stated shell-capture limitation; that and the long source comment are non-blocking documentation nits, not new runtime findings.

[john-the-dev]

APPROVE. Verified against bdd0a86 — reproduced the failure on main and the fix at head, then tried to break the tolerance.

The bug is real on main (REVIEW.md lesson 1). Ran this PR's test file against main's composer-text.mjs, unchanged — rc=1, and the three failures are exactly the three positive doubling assertions:

FAIL a paragraph break read back doubled is tolerated
FAIL two paragraph breaks — the real failing case
FAIL three requested newlines read back as five
FAILED (3)

Same test file against this head's implementation: rc=0, all pass. So the tests reproduce the original failure rather than asserting the new behaviour (lesson 3).

The activated path is the irreversible one (lesson 2). composerMatches has one production consumer, skills/x-twitter/x-post-browser.mjs, at two sites: line 375 after typing, and line 391 re-read immediately before the publish click. failComposerMismatch ends in process.exit(3), so the guard genuinely fails closed. This PR loosens the check that stands between a draft and a published post, which is why I went after false accepts rather than stopping at the diff.

Tried to launder a real corruption through the tolerance — could not. Ten adversarial pairs against the head implementation, all correct:

content lost, newlines look artifact-ish        -> false
composer INSERTED a word between paragraphs     -> false
composer DROPPED a paragraph entirely           -> false
run too long for the artifact (2->5)            -> false
multiple runs, ONE corrupted                    -> false
artifact + a changed character                  -> false
whitespace smuggled into the run                -> false
multiple runs, all genuine artifact             -> true
3 requested -> 3 back (legitimate no-artifact)  -> true
unicode/emoji preserved across collapse         -> true

The reason it holds: undoEmptyLineDoubling rewrites only newline runs, never content characters, and accepts only when the collapse lands on the requested string exactly. m -> (m+1)/2 is the exact inverse of the measured n -> 2n-1 for every n >= 2, and a run that is too long, too short, or even still refuses.

Worst-case disruption (lesson 5): strictly negative-to-zero. No config, no on-disk format, no migration, no renamed path. The change can only turn refusals into publishes, and only for the interior-odd-run shape; single-paragraph posts are byte-identical in behaviour. Before this, the whole multi-paragraph class could not be published at all.

Scope is 2 files, +59/-1, single concern. Hardcoded-path and root-artifact scans clean on the full PR diff. CI 18/18 with all 15 required contexts present on main. No other open PR touches composer-text.mjs.

One thing I want to note as a nit, not a blocker: the asymmetry comment and the (?<=[^\n])...(?=[^\n]) interior-only bound are what keep this honest, and both are load-bearing in a way a future reader could easily "simplify" away. The edge cases are pinned by tests, so a regression would be caught — but the reason the edges differ (measured \n\nAAA -> four, trailing dropped outright) lives only in the comment. That is the right place for it; just flagging that it is doing real work.