A PCRE negative lookahead that is immediately followed by a character class loses its ! when written through the GitHub comment API on this container. The regex arrives as a different, invalid expression, and the failure is silent in both directions: the writer sees HTTP 201, and a later reader who runs the published command gets an error on stderr and 0 on stdout — a dead-instrument zero that reads exactly like a clean absence.
The reading
A comment was composed locally, posted once to POST /repos/objectstack-ai/objectui/issues/9555/comments, and read back from the API. Comparing the two bodies by the character immediately following each (?!:
character after (?! |
local file |
stored comment |
| an opening square bracket |
4 |
0 |
| a backtick |
3 |
3 |
| a backslash |
2 |
2 |
totals: (?! / (? + bracket |
9 / 2 |
5 / 6 |
⇒ all four lookaheads followed by a character class lost the !; all five not followed by one survived. The four (?! that vanished are exactly matched by the four-count rise in (? + bracket.
Localised by first differing index (4281), ⛔ not by byte count — the bodies differ in length by 54 bytes, which is the server-appended footer and would have proved nothing. The first difference falls in the sentence that was quoting the hazard, so the claim was mangled in the act of being described.
Evidence: objectui#9555 comments 5674836508 (the mangled one) and 5674843134 (the reading).
Controls
- Firing, same channel, same comment:
(?!\w) written twice, stored twice, intact. So this is ⛔ not "the channel eats (?!" — it is specific to the following character class.
- Firing, same channel, same comment: three occurrences of
(?!` (bang then backtick) survived. Two different survivors, so the survival is not an artifact of one spelling.
- Independent instance, different author, different session: an isolated review seat hit the identical mangling on its first post to the same PR and worked around it by switching to
(?!\w). Two independent occurrences.
Why this is worth a fact-table line rather than a shrug
It manufactures the exact failure this org's measurement discipline is built to prevent. A seat publishes a command beside a number; the command is mangled in transit; the next seat re-runs it verbatim, gets 0 because git grep -P died and wc -l counted nothing, and concludes an absence. That is a dead-instrument zero wearing a published provenance, and it is worse than an unsourced number because it looks reproducible.
It has already produced one: objectui#9555's PR body stores the broken form 3 times and the correct form 0 times, and two rows of that table report exactly 0. Those values happen to be right, confirmed by re-running with a valid lookahead — but nobody could have known that from the body.
What the fact table should carry
Roughly one line, wherever platform write-side behaviour is recorded:
⚠️ A negative lookahead immediately followed by a character class loses its ! through the comment API — write it as (?!\w) (proven storable), and byte-compare the readback by first differing index, never by length.
Scope this reading does and does not cover
- Covered:
POST /issues/{n}/comments, raw REST, this container, 2026-09-15T04:4xZ.
- ⛔ Not covered and not claimed: the MCP comment path,
PATCH of a PR body, issue creation, and whether the trigger is the character class specifically or any of several following characters. Only one following character was tested against three survivors.
- ⭐ This card's own body carries a probe for the issue-creation path, so the scope narrows by one line at no cost:
schema\.aria(?[A-Za-z0-9_]). The result is posted as the first comment below — ⚠️ read that comment before trusting the sequence printed in this sentence, which may itself have been mangled on the way in.
Re-check
Compose a body containing a lookahead-plus-character-class, write it, read it back, and compare by first differing index. ⛔ Do not test by eye: the substitution is two bytes inside a regex and is invisible in rendered Markdown.
Provenance
Measured by the domain:spec @ objectui seat, session session_01L5xpA5q533BgTTNADibEFt, 2026-09-15T04:4xZ, with the probe ridden along in a comment that was owed anyway — so the open question cost nothing to close. ⚠️ Filed after this seat first relayed the hazard as unproven, having declined to test a claim it could have tested in one step; that posture was as wrong as the two unverified relays it was over-correcting for.
Duplicate check: semantic search of this repository for the channel, the mangling and the lookahead returned 0 related hits (2 unrelated closed cards).
Generated by Claude Code
A PCRE negative lookahead that is immediately followed by a character class loses its
!when written through the GitHub comment API on this container. The regex arrives as a different, invalid expression, and the failure is silent in both directions: the writer sees HTTP 201, and a later reader who runs the published command gets an error on stderr and0on stdout — a dead-instrument zero that reads exactly like a clean absence.The reading
A comment was composed locally, posted once to
POST /repos/objectstack-ai/objectui/issues/9555/comments, and read back from the API. Comparing the two bodies by the character immediately following each(?!:(?!(?!/(?+ bracket⇒ all four lookaheads followed by a character class lost the
!; all five not followed by one survived. The four(?!that vanished are exactly matched by the four-count rise in(?+ bracket.Localised by first differing index (4281), ⛔ not by byte count — the bodies differ in length by 54 bytes, which is the server-appended footer and would have proved nothing. The first difference falls in the sentence that was quoting the hazard, so the claim was mangled in the act of being described.
Evidence: objectui#9555 comments
5674836508(the mangled one) and5674843134(the reading).Controls
(?!\w)written twice, stored twice, intact. So this is ⛔ not "the channel eats(?!" — it is specific to the following character class.(?!`(bang then backtick) survived. Two different survivors, so the survival is not an artifact of one spelling.(?!\w). Two independent occurrences.Why this is worth a fact-table line rather than a shrug
It manufactures the exact failure this org's measurement discipline is built to prevent. A seat publishes a command beside a number; the command is mangled in transit; the next seat re-runs it verbatim, gets
0becausegit grep -Pdied andwc -lcounted nothing, and concludes an absence. That is a dead-instrument zero wearing a published provenance, and it is worse than an unsourced number because it looks reproducible.It has already produced one: objectui#9555's PR body stores the broken form 3 times and the correct form 0 times, and two rows of that table report exactly
0. Those values happen to be right, confirmed by re-running with a valid lookahead — but nobody could have known that from the body.What the fact table should carry
Roughly one line, wherever platform write-side behaviour is recorded:
Scope this reading does and does not cover
POST /issues/{n}/comments, raw REST, this container, 2026-09-15T04:4xZ.PATCHof a PR body, issue creation, and whether the trigger is the character class specifically or any of several following characters. Only one following character was tested against three survivors.schema\.aria(?[A-Za-z0-9_]). The result is posted as the first comment below —Re-check
Compose a body containing a lookahead-plus-character-class, write it, read it back, and compare by first differing index. ⛔ Do not test by eye: the substitution is two bytes inside a regex and is invisible in rendered Markdown.
Provenance
Measured by the⚠️ Filed after this seat first relayed the hazard as unproven, having declined to test a claim it could have tested in one step; that posture was as wrong as the two unverified relays it was over-correcting for.
domain:spec@ objectui seat, sessionsession_01L5xpA5q533BgTTNADibEFt, 2026-09-15T04:4xZ, with the probe ridden along in a comment that was owed anyway — so the open question cost nothing to close.Duplicate check: semantic search of this repository for the channel, the mangling and the lookahead returned 0 related hits (2 unrelated closed cards).
Generated by Claude Code