Measured 2026-08-29 while writing the PR body for #13043 (PR #13069). Filed unassigned, bare for triage.
What the recorded rule says
.claude/skills/pm-dispatch/references/platform-readings.md, under "写侧实测行为 · issue body", records one exclamation-mark case and gives it a less-than precondition:
「less-than + 感叹号 + 左方括号」序列(markup-declaration 开标记)里的感叹号在存储层被删,幸存文本仍像代码但意义已变;裸「less-than + 感叹号」存活。
Closed card #9621 is the measurement behind it — a negative-lookbehind literal, which is open-paren, question mark, less-than, exclamation mark, left bracket. Both name the sequence as starting with a less-than, i.e. as the markup-declaration open tag. An author reading either one concludes that text with no less-than in it is not exposed.
What is actually measured
The less-than is not required. The trigger is an exclamation mark immediately followed by a left bracket, with an ordinary identifier in front of it.
Written into the PR body of #13069, in four places, was the TypeScript non-null assertion form: the identifier m, then an exclamation mark, then a bracketed index — the ordinary spelling of a regex capture in this repo's own test code (packages/spec/scripts/liveness/check-liveness.test.ts uses it in the assertions that PR quotes). No less-than anywhere in those spans.
Read back through two independent channels, both agree the exclamation mark is gone from the STORED body:
- MCP
pull_request_read returned expect(Number(m[1])).toBeGreaterThan(0); - the rendered page (fetched with curl, zero quota) rendered and clipboard-exported the same corrupted text
The files on disk are unchanged, so this is a write-side storage loss, not a read artifact — the same distinction the reference already draws for the entity-escaping case.
Fenced blocks do not protect it. Two of the four occurrences were inside a triple-backtick fence and two were in inline code spans; all four lost the character. That matches the reference's existing warning that fences do not protect tag-shaped tokens, and extends it to this token.
Why it matters more than it looks
The corruption is silent, survives review, and lands on the exact text an author is trying to be precise about. In this case a PR whose whole subject is deleting two named assertions quoted those assertions wrongly — a citation that "LOOKS precise" while being false is the failure mode the liveness ledger this repo maintains exists to prevent, reproduced one layer up in the PR prose.
The population is not exotic. git grep for the non-null assertion followed by a bracket over packages/**/*.test.ts finds it across the workspace; any agent quoting one of those lines into a PR body, an issue, or a review comment writes a wrong quote and gets a success response.
Suggested disposition (not executed)
Widen the recorded rule to the measured trigger — an exclamation mark before a left bracket, less-than or not — and give it an author-side spelling remedy beside the existing ones (spell the operator out in words, or use a placeholder token and define it once, which is what PR #13069 does). The reference already carries the right home for it; this is a correction to a clause, not a new section.
Not in scope for #13043's PR, which records the observation in its own body and works around it.
Dedup (searched 2026-08-29)
Two targeted semantic searches, both returning non-empty result sets, so the channel is self-validating. #9621 (closed) is the less-than-prefixed lookbehind case this card measures as under-specified. #10770 (closed) is the comment-body truncation class. #9778 (closed) banked two other platform readings. #12886 (OPEN) and #12909 (closed) are the attribution-footer behaviour, a different clause — that one reproduced on this PR too, and is deliberately NOT re-filed here because #12886 already carries it. No open card covers the exclamation-mark trigger.
Channel note: repo-scoped REST reads return HTTP 403 from this dev seat (probed this session: GET /repos/objectstack-ai/objectstack answered 403 "GitHub access is not enabled for this session", and gh is absent), so the REST-first dedup rule could not be followed; this used two targeted MCP semantic searches.
Measured 2026-08-29 while writing the PR body for #13043 (PR #13069). Filed unassigned, bare for triage.
What the recorded rule says
.claude/skills/pm-dispatch/references/platform-readings.md, under "写侧实测行为 · issue body", records one exclamation-mark case and gives it a less-than precondition:Closed card #9621 is the measurement behind it — a negative-lookbehind literal, which is open-paren, question mark, less-than, exclamation mark, left bracket. Both name the sequence as starting with a less-than, i.e. as the markup-declaration open tag. An author reading either one concludes that text with no less-than in it is not exposed.
What is actually measured
The less-than is not required. The trigger is an exclamation mark immediately followed by a left bracket, with an ordinary identifier in front of it.
Written into the PR body of #13069, in four places, was the TypeScript non-null assertion form: the identifier
m, then an exclamation mark, then a bracketed index — the ordinary spelling of a regex capture in this repo's own test code (packages/spec/scripts/liveness/check-liveness.test.tsuses it in the assertions that PR quotes). No less-than anywhere in those spans.Read back through two independent channels, both agree the exclamation mark is gone from the STORED body:
pull_request_readreturnedexpect(Number(m[1])).toBeGreaterThan(0);The files on disk are unchanged, so this is a write-side storage loss, not a read artifact — the same distinction the reference already draws for the entity-escaping case.
Fenced blocks do not protect it. Two of the four occurrences were inside a triple-backtick fence and two were in inline code spans; all four lost the character. That matches the reference's existing warning that fences do not protect tag-shaped tokens, and extends it to this token.
Why it matters more than it looks
The corruption is silent, survives review, and lands on the exact text an author is trying to be precise about. In this case a PR whose whole subject is deleting two named assertions quoted those assertions wrongly — a citation that "LOOKS precise" while being false is the failure mode the liveness ledger this repo maintains exists to prevent, reproduced one layer up in the PR prose.
The population is not exotic.
git grepfor the non-null assertion followed by a bracket overpackages/**/*.test.tsfinds it across the workspace; any agent quoting one of those lines into a PR body, an issue, or a review comment writes a wrong quote and gets a success response.Suggested disposition (not executed)
Widen the recorded rule to the measured trigger — an exclamation mark before a left bracket, less-than or not — and give it an author-side spelling remedy beside the existing ones (spell the operator out in words, or use a placeholder token and define it once, which is what PR #13069 does). The reference already carries the right home for it; this is a correction to a clause, not a new section.
Not in scope for #13043's PR, which records the observation in its own body and works around it.
Dedup (searched 2026-08-29)
Two targeted semantic searches, both returning non-empty result sets, so the channel is self-validating. #9621 (closed) is the less-than-prefixed lookbehind case this card measures as under-specified. #10770 (closed) is the comment-body truncation class. #9778 (closed) banked two other platform readings. #12886 (OPEN) and #12909 (closed) are the attribution-footer behaviour, a different clause — that one reproduced on this PR too, and is deliberately NOT re-filed here because #12886 already carries it. No open card covers the exclamation-mark trigger.
Channel note: repo-scoped REST reads return HTTP 403 from this dev seat (probed this session:
GET /repos/objectstack-ai/objectstackanswered 403 "GitHub access is not enabled for this session", andghis absent), so the REST-first dedup rule could not be followed; this used two targeted MCP semantic searches.