Queue-flake anchor: src/email-service.queue-delivery.test.ts

[github-actions]

src/email-service.queue-delivery.test.ts has ejected 2 pull requests from the merge
queue within a rolling 24 hours — 2 independent hits once
GitHub's speculative stacking is accounted for. This issue is the single place for
that conversation; it is refreshed by the merge-queue-triage workflow on every
further ejection.

PR	stack	queue build
#16369	independent	34072528482
#16442	independent	34086147182

This issue is a NAME, not a diagnosis. The workflow that files it reads the
failing test file path out of the job logs and counts PRs; it does not
know whether this is a flake, a load/timing cliff, a semantic conflict between
queued PRs, or a real regression, and it does not act on any of those. No test is
skipped, quarantined or re-queued by it, and no PR is labelled by it — weakening
a gate stays a human act.

What to do with it: read one victim PR's triage comment for the failure REASON
line beside the FAIL line (a timeout and an assertion are the same FAIL line and
opposite diagnoses), decide the cause, and close this issue with the fix or with
the reason it is not one.

Last refreshed by queue build 34086147182 (PR #16442).

---

Filed by the merge-queue-triage workflow (#4859, aggregation #10128).

[claude]

Diagnosis, measured — this is one assertion, not a flaky test, and the fix is one line

domain:engine dispatching seat, session session_01ARYe3yQTQCUFm5qPYNgKaJ, 2026-09-07T05:5xZ. ⛔ Observation only — no grading, no domain:*, no priority, no label written, and ⛔ nothing pushed. Posted here because this issue's own text asks a reader to "decide the cause", and this seat holds the measurement (it owns #16442, the second victim).

The failure REASON line, for both victims

Error: Test timed out in 5000ms. — a timeout, ⛔ not an AssertionError. In #16442's queue build the shard had exactly one failing test and zero assertion-shaped failures; the other three queue workflows on that branch were green.

⭐ It is not diffuse "load". It is a 650× outlier inside its own file

Run locally on an idle machine (vitest run src/email-service.queue-delivery.test.ts --reporter=verbose, origin/main, deps built with turbo):

test	duration
still refuses the queue for attachments OVER the limit, and stores nothing (#5177)	648 ms
every other test in the file (18 of them)	0–1 ms
the two next-slowest	101 ms, 6 ms

22 passed, whole file 4.21 s of which 772 ms is tests. ⇒ this one test is ~84 % of the file's test time, and its siblings are the firing control: they run the same service, the same fakes and the same fixtures, and cost nothing.

At 648 ms idle it needs only a ~7.7× slowdown to cross 5000 ms — which is an ordinary amount of contention for one of six parallel shards on a shared runner. That is why it ejects a PR occasionally rather than always.

⭐⭐ Where the 648 ms goes — isolated three ways

SYS_EMAIL_ATTACHMENT_LIMIT_BYTES = 256 * 1024 (sys-email-payload.ts:76), so the fixture is a 256 KiB + 1 Buffer. Three legs, same file, same runner:

leg	what was timed	cost
A	Buffer.alloc(LIMIT + 1, 0x41) alone	0 ms
B	expect(send).toHaveBeenCalledWith(expect.objectContaining({ attachments: [{ filename, content: huge }] }))	679 ms
C	identity instead: read send.mock.calls[0][0], then expect(arg.attachments[0].content).toBe(huge)	0 ms

⇒ the allocation is free; the entire cost is the deep-equality walk over a 256 KiB Buffer inside toHaveBeenCalledWith + objectContaining. Leg B alone (679 ms) accounts for the whole 648 ms the test spends.

The fix, and why it asserts more rather than less

The assertion's stated intent is the comment right above it — 「Pre-#5177 behaviour, unchanged: delivered inline and delivered WHOLE」. Deep-equality is the weaker test of that: it passes for a copy too. Identity (toBe) proves the exact Buffer instance travelled through untouched, which is what "whole" means. Sketch, at email-service.queue-delivery.test.ts:279:

// was: expect(transport.send).toHaveBeenCalledWith(expect.objectContaining({
//        attachments: [{ filename: 'big.bin', content: huge }],
//      }));
const arg = transport.send.mock.calls[0][0];
expect(arg.attachments).toHaveLength(1);
expect(arg.attachments[0].filename).toBe('big.bin');
expect(arg.attachments[0].content).toBe(huge);   // identity: the SAME buffer, not a copy

⛔ Deliberately NOT the tempting fixes, and each is worse:

• raising testTimeout — hides a 650× outlier instead of removing it, and converts a visible ejection into a slow suite nobody looks at;
• shrinking the fixture — the test's subject is the over-limit boundary, so the size is the point;
• skipping / quarantining — ⛔ never, and unnecessary: the cost is removable without weakening the assertion.

Relationship to #16434 — related, ⛔ not the same defect

#16434 reports the pattern (packages running live or expensive suites under vitest's default 5000 ms with no testTimeout), and plugin-email is its second instance. But the two causes are different and only one of them is a budget question: driver-sql's is 24 real round-trips to two live servers, where the budget genuinely may be too small; this one is a single accidental O(n) assertion, and the right fix removes the cost rather than raising the ceiling. ⇒ closing this issue does not close #16434, and #16434's eventual budget decision must not be read as covering this.

⚠️ What this seat did NOT do

⛔ No push. The fix belongs to plugin-email's owner on this issue, not as a rider on the @objectstack/core narrowing (#16442) this ejected — that PR changes 8 files, 0 of them under plugin-email. ⛔ And per this repo's own triage checklist (item 2: 「已有汇总 issue ⇒ … 修好前重排只会再烧一轮全队列」) #16442 has not been re-queued while this stands.

Re-check:

grep -n 'SYS_EMAIL_ATTACHMENT_LIMIT_BYTES =' packages/plugins/plugin-email/src/sys-email-payload.ts   # 256 * 1024
pnpm --filter @objectstack/plugin-email exec vitest run src/email-service.queue-delivery.test.ts --reporter=verbose
grep -c testTimeout packages/plugins/plugin-email/vitest.config.ts                                   # 0

---

Generated by Claude Code

[claude]

Dispatched — under an explicit maintainer authorisation, because this card is outside the dispatching seat's lane

domain:engine dispatching seat, session session_01ARYe3yQTQCUFm5qPYNgKaJ, 2026-09-07T06:0xZ.

Why this needed an authorisation at all, stated so the exception does not become a habit

This card carries no domain:* and no priority — it is an auto-filed queue-flake anchor, and by this seat's own standing rule that makes it not dispatchable by it: dispatching an ungraded card settles its grading by default, which is exactly the trap this seat refuses. So the seat did not take it. It measured the cause (comment above), put the choice to the maintainer with the alternatives costed, and the maintainer authorised this one fix.

⇒ The dispatch is scoped to exactly that: the single assertion at email-service.queue-delivery.test.ts:279. ⛔ The round is instructed not to grade this card, not to add a domain:* or priority:* label, not to fix neighbouring tests, and not to widen anywhere else in plugin-email. pm:dispatched is added because a dispatch state is only true while a round is running; that bit is not a grade.

What the round is told to do — and the one thing it is told to check first

Replace the deep-equality assertion with an identity assertion on the captured call argument. ⭐ The justification is not speed — it is that identity is the stronger test of what the comment above it claims (「delivered WHOLE」): deep-equality passes for a copy, toBe proves the exact Buffer instance travelled through untouched.

⚠️ The round has been told this may be wrong, and to establish it before shipping: if EmailService copies or slices the attachment on this path, transport.send never receives the same instance, toBe would be wrong, and the correct assertion is a different shape (and possibly still O(n)). It must answer that from the code, and prove the replacement still goes red under a reverse mutation that violates the property — with a byte-exact restore proof.

Explicitly forbidden in this round

⛔ Skipping, disabling or quarantining the test. ⛔ Raising testTimeout in plugin-email/vitest.config.ts or adding a per-test timeout — the cost is removable, and raising the ceiling would convert a visible ejection into a slow suite nobody looks at. ⛔ Shrinking the fixture — the over-limit boundary is the test's subject.

⛔ What this does not do

It does not close #16434. That card reports the pattern (suites under vitest's default 5000 ms with no testTimeout) and its driver-sql instance is a genuinely different cause — 24 real round-trips to two live servers, where the budget may actually be too small. ⚠️ This fix must not be read as covering it, and #16434's eventual budget decision must not be read as covering this.

And it does not re-queue #16442. That stays withdrawn per this repo's own triage checklist until this lands.

---

Generated by Claude Code

[claude]

Claim: os-dev round, dispatched by the domain:engine PM seat under the maintainer's explicit per-card authorisation for this one fix.

Branch: claude/issue-16506-attachment-identity-assertion

Session: https://claude.ai/code/session_01ARYe3yQTQCUFm5qPYNgKaJ

Scope, exactly as authorised: the single deep-equality assertion over the 256 KiB + 1 attachment Buffer in
packages/plugins/plugin-email/src/email-service.queue-delivery.test.ts, replaced by an identity assertion on the
captured call argument. No grading, no domain:* / priority:* label, no neighbouring test touched, no
testTimeout raised, no fixture shrunk, nothing skipped or quarantined.

PR: #16521 (draft)

Clause-②: no

Measured, not predicted. The diff is one *.test.ts file. Ablation on @objectstack/plugin-email,
whose files[] is dist: built at head, swapped that one file back to the merge base c383352cb,
rebuilt -- all 6 published files byte-identical (index.d.ts, index.d.mts, index.js, index.mjs
and both sourcemaps). The rebuild is proven live by dist/index.js mtime moving 1788762853 to
1788762860, and the restore by the blob returning to the HEAD blob with git diff HEAD empty.
Corroborated two ways: the published sourcemaps list 18 and 17 sources and 0 are .test.ts (firing
control: src/email-service.ts IS among them), and untouched text taken from the edited test file
appears in 0 of the 6 published files while non-test controls appear in 4 and 6 of them.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 16506,
  "status": "done",
  "branch": "claude/issue-16506-attachment-identity-assertion",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/16521",
  "premise_still_valid": true,
  "clause2": "no -- derived, not predicted. Ablation on @objectstack/plugin-email (files[] = dist): built at head 7d8103600, swapped the single changed *.test.ts back to merge base c383352cb, rebuilt. All 6 published files byte-identical (index.d.ts, index.d.mts, index.js, index.mjs, index.js.map, index.mjs.map). Rebuild proven live by dist/index.js mtime 1788762853 -> 1788762860; restore proven by blob == HEAD blob AND empty `git diff HEAD`. Corroborated: published sourcemaps list 18 and 17 sources, 0 of them *.test.ts, with src/email-service.ts as a FIRING control present in both; three untouched-text controls from the edited test file appear in 0 of the 6 published files, as does this diff's own new text, while two non-test controls appear in 4 and 6. Declared in the claim comment 5565807557 in the bare fixed spelling; `check-clause2-carriers.mjs --pair 16521` REAL_EXIT=0, captured by redirect-then-read.",
  "zone2": {
    "2.1_entire_650ms_is_that_assertion": "HELD (magnitudes re-derived, PM's numbers not inherited). My own run, this container, under the shared verify lock, --reporter=verbose: target test 674 ms BEFORE, 1-2 ms AFTER; its file 800 ms -> 125 ms of test time over the same 22 tests; whole package 2287 ms -> 1537 ms over the same 468. Its 21 siblings total 126 ms between them (20 at 0-6 ms, one at 102 ms -- so 'siblings are 0-1 ms' is very slightly optimistic). NOTE on legs A/B/C: I did not time them as three separate stopwatch legs. The fixture allocation is IDENTICAL on both of my legs (unchanged by design), so anything retained on both costs at most the AFTER figure: leg A + leg C <= 2 ms and leg B ~= 672 ms. That is a derivation from the experiment's construction, not three independent timings -- stated so it is not read as more than it is.",
    "2.2_limit_is_256KiB": "HELD. `export const SYS_EMAIL_ATTACHMENT_LIMIT_BYTES = 256 * 1024;` at packages/plugins/plugin-email/src/sys-email-payload.ts:76 -- line number exact. Fixture is Buffer.alloc(LIMIT + 1, 0x41) = 262145 bytes, unchanged by this PR.",
    "2.3_identity_does_not_weaken": "HELD, and argued rather than asserted. (a) The SAME instance arrives: normalizeMessage assigns `msg.attachments = input.attachments` (email-service.ts:300) with no copy, and deliverNormalized passes that same object to `this.options.transport.send(normalized)` (email-service.ts:1128); on this path offloadAttachments returns early (no storage mounted) and never rewrites it. The empirical half is that `toBe(huge)` PASSES. So `toBe` is correct and `.equals()` + a length check is NOT needed -- the fix keeps its shape. (b) Reverse mutation, 5 legs, each with the mutation proven on disk by whole-line anchor counts (old=0/new=1) plus a blob != HEAD blob check, and each restore proven by blob == HEAD blob AND empty `git diff HEAD`. THE DECISIVE LEG: make normalizeMessage hand the transport a byte-identical COPY, then run the two assertions against that same mutated tree -- OLD deep-equality assertion PASSES (656 ms, blind to the copy); NEW identity assertion FAILS with `expected Buffer[...] to be Buffer[...] // Object.is equality` and `Received: serializes to the same string`. That is a direct measurement that the replacement is STRICTLY STRONGER, not merely faster.",
    "2.4_nothing_else_this_shape": "HELD, two instruments each with its own positive control. (i) A multiline regex for a deep-equality assertion carrying a large-buffer identifier across all 25 plugin-email/src/*.test.ts returns EXACTLY ONE hit -- the one this PR changes, so the census fires on its own target. NOTE: my first, single-line grep returned ZERO for that same file because the assertion spans lines; I discarded it as a non-census rather than banking the zero. (ii) Behavioural census over all 468 package tests: after the change the top entries are 172/163/122/101 ms. The former runner-up (317 ms before, 163 ms after) is `produces a byte-identical MIME message, inline vs row round trip`, whose cost is a real MIME round trip through onTheWire and which already asserts with toBe -- a different shape, NOT the same defect. Nothing else was touched.",
    "2.5_clause2_is_no": "HELD -- re-derived independently, see the `clause2` key. Declared by me, not inherited.",
    "2.6_bump_level_is_patch": "FALSIFIED, and this is the one to read. Deriving from .github/workflows/pr-automation.yml as instructed lands on route 2, NOT on a bump level: a diff that 'releases nothing (... tests-only, and the like)' takes the `skip-changeset` label, which that file marks as the PREFERRED route, and the WHICH LEVEL question is scoped to route 1 (a PR that releases something). My clause-2 measurement is exactly route 2's evidence: no published byte moves. scripts/check-changeset-no-major.mjs adds the cost of getting it wrong -- every publishable package sits in the Changesets `fixed` group, so a `patch` here would version the WHOLE lockstep group for a diff no consumer can observe. So: `skip-changeset` label applied (additively, read back comparatively: labels went [] -> ['size/s','skip-changeset'], nothing stripped), NO changeset file. Your note that the gate only refuses `major` is correct and is why this needed deriving rather than defaulting."
  },
  "timings": "MY OWN RUN, not the PM's. plugin-email, --reporter=verbose, --maxWorkers=2, under scripts/pm/os-verify-lock.sh. Target test `still refuses the queue for attachments OVER the limit, and stores nothing (#5177)': BEFORE 674 ms (file-scoped run) / 668 ms (package-wide run) -> AFTER 1 ms (file-scoped) / 2 ms (package-wide). File total 800 ms -> 125 ms, 22 passed both legs. Package total 2287 ms -> 1537 ms, 468 passed both legs; the target falls out of the package top 5 entirely. Ratio, which survives contention where absolutes do not: the target went from 84 percent of its file's test time and 29 percent of the package's to under 0.2 percent. CAVEAT stated because the box is shared: one ablation leg recorded an 878051 ms per-test duration under heavy contention -- absolutes measured here are shared-box seconds, never idle-machine figures.",
  "reverse_mutation": "5 legs on packages/plugins/plugin-email/src/email-service.ts, all after committing the implementation (7d8103600) so the restore leg had a real reference. Anchor uniqueness verified in both directions before measuring (whole-line count 1 at HEAD, mutation text 0 at HEAD). Each leg: mutate -> PROVE on disk (old-line=0, new-line=1, git hash-object != HEAD blob) -> measure -> restore -> PROVE restore (git hash-object == HEAD blob AND `git diff HEAD` empty), all in ONE shell, with `trap restore EXIT INT TERM` and absolute paths from `git rev-parse --show-toplevel`. No build step is owed: the test imports './email-service.js', a relative specifier inside src/, so vitest compiles the source -- and the mutations turning the suite RED is itself the proof the source was live. RESULTS: (1) COPY in normalizeMessage (Buffer.from, bytes identical) -> new assertion RED, `Object.is equality`, `Received: serializes to the same string`; (1b) the SAME copy mutation with the OLD deep-equality assertion restored -> PASSES, 656 ms, so the old assertion provably cannot see a copy; (2) TRUNCATE in normalizeMessage (subarray(0,10)) -> RED, but at `res.status` ('queued' vs 'sent'), because truncating under the limit changes the ROUTING before the content is ever read -- reported precisely rather than claimed for the identity assertion; (3) DROP at the transport seam -> RED, `Target cannot be null or undefined` on toHaveLength(1); (4) TRUNCATE at the transport seam -> RED on content identity; (5) REPLACE at the transport seam (same length, 0x42) -> RED on content identity and it is the ONLY failure in the run. All 5 restores proven byte-exact to blob 0198f7acae20f191a4b9a3db4a8ca72d3a3f931c; tree confirmed clean afterwards and the suite re-run green (22 passed, target 2 ms).",
  "closes_or_part_of": "Part of #16506 -- deliberately NOT a closing keyword, and consistent between the commit trailer and the PR body so a squash cannot contradict itself. Reasons: the card is a standing anchor the merge-queue-triage workflow refreshes on every further ejection, its own text asks a HUMAN to decide whether it closes, and Zone 1 forbids me grading it. PM/maintainer call. (Note: the commit was already pushed with `Part of`, and force-push is forbidden, so switching to `Fixes` in the body alone would have produced exactly the squash contradiction the standing rules warn about.)",
  "gates_run": "All at the final head 7d8103600 (nothing changed after the gate union; `git rev-parse --short HEAD` = 7d8103600). (1) Dependency closure: `pnpm --filter '@objectstack/plugin-email^...' build` exit 0. (2) `pnpm --filter @objectstack/plugin-email run typecheck` exit 0 -- tsc --noEmit PLUS check:test-typecheck reporting `0 file(s) / 0 error(s)`; the edited test file is PROVEN inside the swept population by `tsc --listFiles` on both tsconfig.json and tsconfig.test.json, so this is a reading about my file and not a vacuous green. (3) `pnpm --filter @objectstack/plugin-email exec vitest run` -- 30 files, 468 passed. (4) 56 gate families derived by `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack` from the real change set (no hand-built path list); each run with redirect-then-capture, never through a pipe. 53 exit 0. The other 3 are NOT MEASURED, not red, and two say so in their own text: check:dual-build-cjs-loads and check:published-readme-exports both exit 3, `PREREQUISITE NOT MET -- this gate reads built output, and some package has no dist/`, naming 51 unbuilt packages none of which this diff touches; check:react-declaration-parity exits 1 needing a browser-produced SDUI manifest. All three read built output or a browser artefact, and the clause-2 ablation shows this diff's built output is byte-identical, so their verdicts are invariant under it -- DECLARED narrowing, CI runs the farm. (5) Anchor/census family, run because this diff changes a file's line count: `git grep` finds ZERO references to `email-service.queue-delivery` outside its own package, and the same grep shape on `registry.ts:` returns hits across 5+ files so the zero is a reading; the only plugin-email/src/*.ts:NNN anchors in the repo name email-plugin.ts:117 and email-template-provenance.ts:54, neither of which is the edited file. (6) check:nul-bytes exit 0 plus a direct control-character scan of the edited file: no hits. (7) PM-flagged red re-derived myself: `check:partof-closing-keyword` REAL_EXIT=1 on PR #16521, run with the REAL inputs (PR_NUMBER, PR_BODY from the posted body, PR_COMMITS_FILE from /pulls/16521/commits) and redirect-then-read -- NOT the vacuous PR_NUMBER-only pass. One finding, RULE 2: commit 7d8103600 carries a `Part of #16506` trailer in its MESSAGE. CONTROL, same body and same commit with only that trailer line deleted: exit 0. So the trailer is the SOLE cause, and the body passes RULE 1 and RULE 3 as posted -- no body edit can clear this red, and the prose mentions of other card numbers in the body are not implicated.",
  "mcp_calls": "0 -- every read and write went over REST through the agent proxy with curl (issue read, PM comment read, claim comment create/patch/read-back, PR create/patch/read-back, label add + comparative read-back, carrier check). No MCP GitHub call was made.",
  "summary": "Replaced one deep-equality assertion over a 256 KiB + 1 Buffer with an identity assertion on the captured transport.send argument, in the single test named by the authorisation. The justification is strength, not speed, and it is measured: under a mutation that hands the transport a byte-identical COPY, the old assertion PASSES and the new one FAILS -- so identity strictly dominates deep equality here, and 'delivered WHOLE' (the comment above it) is now actually asserted. The speed is the consequence: 674 ms -> 1-2 ms, the file 800 -> 125 ms, the package 2287 -> 1537 ms across an unchanged 468 tests. Nothing was skipped, no timeout raised, the over-limit fixture is untouched, and no neighbouring test or label was touched. One incidental change inside the same test: its transport fake now declares its parameter, because vi.fn(async () => ...) has an empty parameter tuple and reading mock.calls[0][0] is otherwise a type error under the package's test-layer typecheck (TS2493 + 3x TS18048) -- that is why the diff is 2 hunks rather than 1. Two things for the PM: 2.6 is FALSIFIED (the repo routes a tests-only diff to the skip-changeset label, which is applied, NOT to a patch changeset -- a patch would version the whole lockstep fixed group for a diff no consumer can observe), and GitHub's renderer silently ate the `!` in `attachments!` before a bracket INSIDE a fenced code block in the first PR body, which I caught on read-back and repaired. PM-flagged red addressed: `check:partof-closing-keyword` is genuinely red and it is my defect (a card-relation trailer in the commit message as well as the body), but I did NOT amend and force-push. The gate's own runtime output and docblock forbid that repair in those words, AGENTS.md and my standing rules forbid force-push unconditionally, and the PM's own quoted block contains the sentence 'The repair is NOT a history rewrite'. The relation is correctly stated once in the body; the gate places the repair at merge (the merger takes the squash message from the body). See the `partof_gate_red` key -- it includes the control run that proves the trailer is the sole cause and that no body edit can clear it, and it names the one green-producing route (a replacement PR) as a PM call rather than taking it unilaterally.",
  "partof_gate_red": {
    "verdict": "REAL, my defect, and NOT repaired by a force-push. I did not amend or force-push, and I am flagging the conflict rather than silently picking a side.",
    "what_i_did_wrong": "I wrote `Part of #16506` into the commit message as well as the PR body. My own standing os-dev rules already forbid exactly this (a squashed branch declares the card relation ONCE, in the body; commits carry no card trailer) -- the gate's error text even cites .claude/agents/os-dev.md for it. Straightforward miss on my part.",
    "why_i_did_not_amend_and_force_push": "FOUR independent texts forbid it, and the PM's own message quotes the sentence that refutes the amend route. (1) The gate's RUNTIME OUTPUT, verbatim: 'Remedy: move this relation into the PR body, where it is stated once, and take the squash message from that body at merge. Do NOT amend, rebase or force-push to remove it -- rewriting pushed history is forbidden here, and it is not what fixes this.' (2) The gate's DOCBLOCK: 'Nothing in this gate's output asks anyone to rewrite history: amend, rebase and force-push are forbidden here, and a red on an already-pushed branch is repaired the way this repo's merges already repair it, in the body and at the merge.' (3) AGENTS.md multi-agent discipline item 3: 'Never git push --force / --force-with-lease'. (4) My own os-dev standing rules: force-push forbidden, unconditional -- and those rules state that where the dispatch prompt and the standing file conflict, the FILE wins and the conflict is reported rather than silently resolved. NOTE on the PM's quote: the line 'Pushing the reworded commits re-runs this check.' is immediately followed, in the same block the PM pasted, by 'The repair is NOT a history rewrite'. The first sentence describes what happens IF commits are reworded; the second forbids rewording pushed ones.",
    "state_now": "The relation is stated exactly once, correctly, in the PR body (`Part of #16506`). The red stands on head 7d8103600 as a documented state whose remedy the gate places AT MERGE: the merger takes the squash message from the body, so the commit trailer never reaches the landed message. Recorded on the PR as comment 5566242274, with the measurement and the control, so no one has to re-derive it.",
    "the_one_route_to_a_green_and_why_it_is_not_mine_to_take": "If a green check run is required rather than a documented red, the only route that does not rewrite pushed history is a REPLACEMENT branch and a replacement PR carrying the identical tree with a clean commit message. That trades PR #16521's identity for a green, so it is a PM/maintainer call. I have not done it. Say the word and it is about five minutes.",
    "the_generalisable_bit": "The gate is the authority on its own repair and it prints that repair on every failure. Reading its output before choosing a remedy was cheaper than the remedy, and in this case it inverted the answer."
  }
}

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 16506,
  "status": "done",
  "branch": "claude/issue-16506-identity-assertion-v2 (replacement; superseded claude/issue-16506-attachment-identity-assertion, whose branch is left untouched)",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/16522",
  "premise_still_valid": true,
  "clause2": "no -- derived, not predicted. Ablation on @objectstack/plugin-email (files[] = dist): built at head 7d8103600, swapped the single changed *.test.ts back to merge base c383352cb, rebuilt. All 6 published files byte-identical (index.d.ts, index.d.mts, index.js, index.mjs, index.js.map, index.mjs.map). Rebuild proven live by dist/index.js mtime 1788762853 -> 1788762860; restore proven by blob == HEAD blob AND empty `git diff HEAD`. Corroborated: published sourcemaps list 18 and 17 sources, 0 of them *.test.ts, with src/email-service.ts as a FIRING control present in both; three untouched-text controls from the edited test file appear in 0 of the 6 published files, as does this diff's own new text, while two non-test controls appear in 4 and 6. Declared in the claim comment 5565807557 in the bare fixed spelling; `check-clause2-carriers.mjs --pair 16521` REAL_EXIT=0, captured by redirect-then-read.",
  "zone2": {
    "2.1_entire_650ms_is_that_assertion": "HELD (magnitudes re-derived, PM's numbers not inherited). My own run, this container, under the shared verify lock, --reporter=verbose: target test 674 ms BEFORE, 1-2 ms AFTER; its file 800 ms -> 125 ms of test time over the same 22 tests; whole package 2287 ms -> 1537 ms over the same 468. Its 21 siblings total 126 ms between them (20 at 0-6 ms, one at 102 ms -- so 'siblings are 0-1 ms' is very slightly optimistic). NOTE on legs A/B/C: I did not time them as three separate stopwatch legs. The fixture allocation is IDENTICAL on both of my legs (unchanged by design), so anything retained on both costs at most the AFTER figure: leg A + leg C <= 2 ms and leg B ~= 672 ms. That is a derivation from the experiment's construction, not three independent timings -- stated so it is not read as more than it is.",
    "2.2_limit_is_256KiB": "HELD. `export const SYS_EMAIL_ATTACHMENT_LIMIT_BYTES = 256 * 1024;` at packages/plugins/plugin-email/src/sys-email-payload.ts:76 -- line number exact. Fixture is Buffer.alloc(LIMIT + 1, 0x41) = 262145 bytes, unchanged by this PR.",
    "2.3_identity_does_not_weaken": "HELD, and argued rather than asserted. (a) The SAME instance arrives: normalizeMessage assigns `msg.attachments = input.attachments` (email-service.ts:300) with no copy, and deliverNormalized passes that same object to `this.options.transport.send(normalized)` (email-service.ts:1128); on this path offloadAttachments returns early (no storage mounted) and never rewrites it. The empirical half is that `toBe(huge)` PASSES. So `toBe` is correct and `.equals()` + a length check is NOT needed -- the fix keeps its shape. (b) Reverse mutation, 5 legs, each with the mutation proven on disk by whole-line anchor counts (old=0/new=1) plus a blob != HEAD blob check, and each restore proven by blob == HEAD blob AND empty `git diff HEAD`. THE DECISIVE LEG: make normalizeMessage hand the transport a byte-identical COPY, then run the two assertions against that same mutated tree -- OLD deep-equality assertion PASSES (656 ms, blind to the copy); NEW identity assertion FAILS with `expected Buffer[...] to be Buffer[...] // Object.is equality` and `Received: serializes to the same string`. That is a direct measurement that the replacement is STRICTLY STRONGER, not merely faster.",
    "2.4_nothing_else_this_shape": "HELD, two instruments each with its own positive control. (i) A multiline regex for a deep-equality assertion carrying a large-buffer identifier across all 25 plugin-email/src/*.test.ts returns EXACTLY ONE hit -- the one this PR changes, so the census fires on its own target. NOTE: my first, single-line grep returned ZERO for that same file because the assertion spans lines; I discarded it as a non-census rather than banking the zero. (ii) Behavioural census over all 468 package tests: after the change the top entries are 172/163/122/101 ms. The former runner-up (317 ms before, 163 ms after) is `produces a byte-identical MIME message, inline vs row round trip`, whose cost is a real MIME round trip through onTheWire and which already asserts with toBe -- a different shape, NOT the same defect. Nothing else was touched.",
    "2.5_clause2_is_no": "HELD -- re-derived independently, see the `clause2` key. Declared by me, not inherited.",
    "2.6_bump_level_is_patch": "FALSIFIED, and this is the one to read. Deriving from .github/workflows/pr-automation.yml as instructed lands on route 2, NOT on a bump level: a diff that 'releases nothing (... tests-only, and the like)' takes the `skip-changeset` label, which that file marks as the PREFERRED route, and the WHICH LEVEL question is scoped to route 1 (a PR that releases something). My clause-2 measurement is exactly route 2's evidence: no published byte moves. scripts/check-changeset-no-major.mjs adds the cost of getting it wrong -- every publishable package sits in the Changesets `fixed` group, so a `patch` here would version the WHOLE lockstep group for a diff no consumer can observe. So: `skip-changeset` label applied (additively, read back comparatively: labels went [] -> ['size/s','skip-changeset'], nothing stripped), NO changeset file. Your note that the gate only refuses `major` is correct and is why this needed deriving rather than defaulting."
  },
  "timings": "MY OWN RUN, not the PM's. plugin-email, --reporter=verbose, --maxWorkers=2, under scripts/pm/os-verify-lock.sh. Target test `still refuses the queue for attachments OVER the limit, and stores nothing (#5177)': BEFORE 674 ms (file-scoped run) / 668 ms (package-wide run) -> AFTER 1 ms (file-scoped) / 2 ms (package-wide). File total 800 ms -> 125 ms, 22 passed both legs. Package total 2287 ms -> 1537 ms, 468 passed both legs; the target falls out of the package top 5 entirely. Ratio, which survives contention where absolutes do not: the target went from 84 percent of its file's test time and 29 percent of the package's to under 0.2 percent. CAVEAT stated because the box is shared: one ablation leg recorded an 878051 ms per-test duration under heavy contention -- absolutes measured here are shared-box seconds, never idle-machine figures.",
  "reverse_mutation": "5 legs on packages/plugins/plugin-email/src/email-service.ts, all after committing the implementation (7d8103600) so the restore leg had a real reference. Anchor uniqueness verified in both directions before measuring (whole-line count 1 at HEAD, mutation text 0 at HEAD). Each leg: mutate -> PROVE on disk (old-line=0, new-line=1, git hash-object != HEAD blob) -> measure -> restore -> PROVE restore (git hash-object == HEAD blob AND `git diff HEAD` empty), all in ONE shell, with `trap restore EXIT INT TERM` and absolute paths from `git rev-parse --show-toplevel`. No build step is owed: the test imports './email-service.js', a relative specifier inside src/, so vitest compiles the source -- and the mutations turning the suite RED is itself the proof the source was live. RESULTS: (1) COPY in normalizeMessage (Buffer.from, bytes identical) -> new assertion RED, `Object.is equality`, `Received: serializes to the same string`; (1b) the SAME copy mutation with the OLD deep-equality assertion restored -> PASSES, 656 ms, so the old assertion provably cannot see a copy; (2) TRUNCATE in normalizeMessage (subarray(0,10)) -> RED, but at `res.status` ('queued' vs 'sent'), because truncating under the limit changes the ROUTING before the content is ever read -- reported precisely rather than claimed for the identity assertion; (3) DROP at the transport seam -> RED, `Target cannot be null or undefined` on toHaveLength(1); (4) TRUNCATE at the transport seam -> RED on content identity; (5) REPLACE at the transport seam (same length, 0x42) -> RED on content identity and it is the ONLY failure in the run. All 5 restores proven byte-exact to blob 0198f7acae20f191a4b9a3db4a8ca72d3a3f931c; tree confirmed clean afterwards and the suite re-run green (22 passed, target 2 ms).",
  "closes_or_part_of": "Part of #16506 -- deliberately NOT a closing keyword, and consistent between the commit trailer and the PR body so a squash cannot contradict itself. Reasons: the card is a standing anchor the merge-queue-triage workflow refreshes on every further ejection, its own text asks a HUMAN to decide whether it closes, and Zone 1 forbids me grading it. PM/maintainer call. (Note: the commit was already pushed with `Part of`, and force-push is forbidden, so switching to `Fixes` in the body alone would have produced exactly the squash contradiction the standing rules warn about.)",
  "gates_run": "All at the final head 7d8103600 (nothing changed after the gate union; `git rev-parse --short HEAD` = 7d8103600). (1) Dependency closure: `pnpm --filter '@objectstack/plugin-email^...' build` exit 0. (2) `pnpm --filter @objectstack/plugin-email run typecheck` exit 0 -- tsc --noEmit PLUS check:test-typecheck reporting `0 file(s) / 0 error(s)`; the edited test file is PROVEN inside the swept population by `tsc --listFiles` on both tsconfig.json and tsconfig.test.json, so this is a reading about my file and not a vacuous green. (3) `pnpm --filter @objectstack/plugin-email exec vitest run` -- 30 files, 468 passed. (4) 56 gate families derived by `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack` from the real change set (no hand-built path list); each run with redirect-then-capture, never through a pipe. 53 exit 0. The other 3 are NOT MEASURED, not red, and two say so in their own text: check:dual-build-cjs-loads and check:published-readme-exports both exit 3, `PREREQUISITE NOT MET -- this gate reads built output, and some package has no dist/`, naming 51 unbuilt packages none of which this diff touches; check:react-declaration-parity exits 1 needing a browser-produced SDUI manifest. All three read built output or a browser artefact, and the clause-2 ablation shows this diff's built output is byte-identical, so their verdicts are invariant under it -- DECLARED narrowing, CI runs the farm. (5) Anchor/census family, run because this diff changes a file's line count: `git grep` finds ZERO references to `email-service.queue-delivery` outside its own package, and the same grep shape on `registry.ts:` returns hits across 5+ files so the zero is a reading; the only plugin-email/src/*.ts:NNN anchors in the repo name email-plugin.ts:117 and email-template-provenance.ts:54, neither of which is the edited file. (6) check:nul-bytes exit 0 plus a direct control-character scan of the edited file: no hits. (7) PM-flagged red re-derived myself: `check:partof-closing-keyword` REAL_EXIT=1 on PR #16521, run with the REAL inputs (PR_NUMBER, PR_BODY from the posted body, PR_COMMITS_FILE from /pulls/16521/commits) and redirect-then-read -- NOT the vacuous PR_NUMBER-only pass. One finding, RULE 2: commit 7d8103600 carries a `Part of #16506` trailer in its MESSAGE. CONTROL, same body and same commit with only that trailer line deleted: exit 0. So the trailer is the SOLE cause, and the body passes RULE 1 and RULE 3 as posted -- no body edit can clear this red, and the prose mentions of other card numbers in the body are not implicated. (8) At the replacement head 91092fbb3, whose tree is byte-identical (fb2e339a...) so no content-reading gate can differ: check:partof-closing-keyword exit 0 (the one that could differ, since it reads commit messages), plus check:nul-bytes, check:cross-package-test-inputs, check:test-source-alias and check:published-files all exit 0.",
  "mcp_calls": "0 -- every read and write went over REST through the agent proxy with curl (issue read, PM comment read, claim comment create/patch/read-back, PR create/patch/read-back, label add + comparative read-back, carrier check). No MCP GitHub call was made.",
  "summary": "Replaced one deep-equality assertion over a 256 KiB + 1 Buffer with an identity assertion on the captured transport.send argument, in the single test named by the authorisation. The justification is strength, not speed, and it is measured: under a mutation that hands the transport a byte-identical COPY, the old assertion PASSES and the new one FAILS -- so identity strictly dominates deep equality here, and 'delivered WHOLE' (the comment above it) is now actually asserted. The speed is the consequence: 674 ms -> 1-2 ms, the file 800 -> 125 ms, the package 2287 -> 1537 ms across an unchanged 468 tests. Nothing was skipped, no timeout raised, the over-limit fixture is untouched, and no neighbouring test or label was touched. One incidental change inside the same test: its transport fake now declares its parameter, because vi.fn(async () => ...) has an empty parameter tuple and reading mock.calls[0][0] is otherwise a type error under the package's test-layer typecheck (TS2493 + 3x TS18048) -- that is why the diff is 2 hunks rather than 1. Two things for the PM: 2.6 is FALSIFIED (the repo routes a tests-only diff to the skip-changeset label, which is applied, NOT to a patch changeset -- a patch would version the whole lockstep fixed group for a diff no consumer can observe), and GitHub's renderer silently ate the `!` in `attachments!` before a bracket INSIDE a fenced code block in the first PR body, which I caught on read-back and repaired. PM-flagged red addressed: `check:partof-closing-keyword` is genuinely red and it is my defect (a card-relation trailer in the commit message as well as the body), but I did NOT amend and force-push. The gate's own runtime output and docblock forbid that repair in those words, AGENTS.md and my standing rules forbid force-push unconditionally, and the PM's own quoted block contains the sentence 'The repair is NOT a history rewrite'. The relation is correctly stated once in the body; the gate places the repair at merge (the merger takes the squash message from the body). See the `partof_gate_red` key -- it includes the control run that proves the trailer is the sole cause and that no body edit can clear it, and it names the one green-producing route (a replacement PR) as a PM call rather than taking it unilaterally. REPLACEMENT DELIVERED on the PM's authorisation: PR #16522 carries a provably identical tree (both trees hash fb2e339a1904da01469ce1981e1a6303e82a64ad) with a commit message stripped of the card trailer; check:partof-closing-keyword exits 0 against its real posted body and real API commit list, pre-push and post-creation. #16521 is closed and its branch left alone. The `Refs` question is answered from source AND measured: RULE 2 forbids Part of, Refs AND closing keywords on any commit, and backticks or a code fence do not neutralise any of them -- see `refs_question_answered` for the exact boilerplate correction, including why 'no #N token at all in a commit message' is the more checkable rule to write.",
  "partof_gate_red": {
    "verdict": "REAL, my defect, and NOT repaired by a force-push. I did not amend or force-push, and I am flagging the conflict rather than silently picking a side.",
    "what_i_did_wrong": "I wrote `Part of #16506` into the commit message as well as the PR body. My own standing os-dev rules already forbid exactly this (a squashed branch declares the card relation ONCE, in the body; commits carry no card trailer) -- the gate's error text even cites .claude/agents/os-dev.md for it. Straightforward miss on my part.",
    "why_i_did_not_amend_and_force_push": "FOUR independent texts forbid it, and the PM's own message quotes the sentence that refutes the amend route. (1) The gate's RUNTIME OUTPUT, verbatim: 'Remedy: move this relation into the PR body, where it is stated once, and take the squash message from that body at merge. Do NOT amend, rebase or force-push to remove it -- rewriting pushed history is forbidden here, and it is not what fixes this.' (2) The gate's DOCBLOCK: 'Nothing in this gate's output asks anyone to rewrite history: amend, rebase and force-push are forbidden here, and a red on an already-pushed branch is repaired the way this repo's merges already repair it, in the body and at the merge.' (3) AGENTS.md multi-agent discipline item 3: 'Never git push --force / --force-with-lease'. (4) My own os-dev standing rules: force-push forbidden, unconditional -- and those rules state that where the dispatch prompt and the standing file conflict, the FILE wins and the conflict is reported rather than silently resolved. NOTE on the PM's quote: the line 'Pushing the reworded commits re-runs this check.' is immediately followed, in the same block the PM pasted, by 'The repair is NOT a history rewrite'. The first sentence describes what happens IF commits are reworded; the second forbids rewording pushed ones.",
    "state_now": "RESOLVED by replacement, on the PM's explicit authorisation. PR #16522 carries the identical tree with a trailer-free commit message and the gate exits 0 against its real posted body and real commit list. PR #16521 is closed, its branch untouched. The original entry below records why the amend/force-push route was refused; the PM has since re-read the gate at source and withdrawn that instruction.",
    "the_one_route_to_a_green_and_why_it_is_not_mine_to_take": "If a green check run is required rather than a documented red, the only route that does not rewrite pushed history is a REPLACEMENT branch and a replacement PR carrying the identical tree with a clean commit message. That trades PR #16521's identity for a green, so it is a PM/maintainer call. I have not done it. Say the word and it is about five minutes.",
    "the_generalisable_bit": "The gate is the authority on its own repair and it prints that repair on every failure. Reading its output before choosing a remedy was cheaper than the remedy, and in this case it inverted the answer."
  },
  "replacement_pr": {
    "why": "PM authorised it after re-reading the gate at the primary source and agreeing the amend/force-push route was wrong. A documented red was not acceptable because required-check status is a 403 from this seat (an ABSENT reading, not a 'no'), and the PM's firing control found 14 of the 30 most recently closed PRs carry this same check with 0 of them merging red -- 14/14 green at merge.",
    "tree_identity": "PROVEN, not asserted. New branch cut from the SAME base c383352cb, the one validated file restored from 7d8103600. Both commit trees hash to fb2e339a1904da01469ce1981e1a6303e82a64ad, and `git diff 7d8103600` is empty. So every measurement in this report -- timings, ablation, clause-2, the 56 gate families -- is a reading about PR #16522's tree, and the diff was NOT re-litigated.",
    "commit": "91092fbb3, message identical to 7d8103600's minus the `Part of #16506` trailer line. The measurements, the 'identity is the stronger assertion; removing the O(n) walk is a consequence, not the reason' framing, `Co-Authored-By:` and `Claude-Session:` all kept. The message now contains ZERO `#N` tokens of any kind.",
    "gate_proof": "Run twice with REAL inputs and redirect-then-read, never a pipe and never the PR_NUMBER-only vacuous pass. PRE-PUSH: real body + the real local commit -> REAL_EXIT=0. POST-CREATION: the real POSTED body fetched back from /pulls/16522 + the real commit list from /pulls/16522/commits -> REAL_EXIT=0, `1 commit message(s) carry no card-relation trailer`. Also re-ran check:nul-bytes, check:cross-package-test-inputs, check:test-source-alias and check:published-files at the new head: all exit 0.",
    "body": "`Part of #16506` appears EXACTLY ONCE and nowhere else (counted in the posted body, not the draft). The Notes-for-triage paragraphs carried over verbatim: the standing-anchor reasoning for not using a closing keyword, and the #16434 separation. Posted body verified byte-exact against what I sent, the only delta being the server-appended session-URL footer. One incidental repair carried over: a rank written as a bare hash-one was reworded to 'slowest of 468' so it could not render as a cross-reference to issue 1.",
    "old_pr": "#16521 now sits in the closed state. The comment left on it names its replacement, links it, and records why the trailer could not be removed without a forbidden history rewrite, together with the actual/control measurement. Its branch is left in place, untouched, as instructed.",
    "label": "skip-changeset applied additively to #16522 and read back comparatively: [] -> ['size/s','skip-changeset','tests'], nothing stripped. No changeset file, per the 2.6 finding."
  },
  "refs_question_answered": {
    "answer": "YES -- RULE 2 forbids ALL THREE card-relation trailer kinds on any commit of a PR, `Refs #N` included, and neither backticks nor a fenced code block neutralises any of them.",
    "read_from_source": "scripts/check-partof-closing-keyword.mjs:475 `commitRelations` is the UNION of three extractors: partOfTargets (`Part of #N`), refsTargets (`Refs #N`) and closingKeywordTargets (Fixes/Closes/Resolves and inflections). Its docblock states the reason in full: 'All three relations, because all three are the PR body's to declare: a closing keyword acts on merge, and Part-of and Refs are read by this repo's own board tooling, so a commit carrying either tells the board something its author only meant to tell the pull request.' All three are called with `markdown: false`, which the import note calls a measured contract -- 'a commit message is not markdown, so backticks do not neutralise a keyword there'. The gate's own self-test pins both halves: one case feeds a message carrying a Part-of, a Refs and a closing-keyword trailer bound to three different card numbers and asserts all three relations come back, and another asserts that 'a trailer inside a fenced block in a COMMIT is still a finding'. (The literal card numbers in that fixture are not reproduced here, because quoting a bound closing keyword in a GitHub comment mints a live cross-reference to whatever card it names.)",
    "measured_not_only_read": "I ran the gate over four synthetic commit messages built from my own clean message, same body, redirect-then-read: clean -> exit 0; plus `Refs #16506` plain -> exit 1; the same backticked -> exit 1; the same inside a triple-fence -> exit 1. Each of the three reds names `Refs #16506` as the carried relation.",
    "for_the_dispatch_boilerplate": "The correction to write is: a commit message on a PR carries NO card reference of any relation kind -- not `Fixes`, not `Part of`, not `Refs` -- and hiding one in backticks or a code fence does not help. The relation is declared once, in the PR body. Worth adding that the safest formulation is simply that no `#N` token belongs in a commit message on a PR at all: my replacement commit contains zero of them, which is trivially checkable by the author with one grep before committing, whereas 'no relation KEYWORD bound to a number' asks the author to reproduce three extractors from memory."
  }
}

---

Generated by Claude Code