From 4c1b2a1fdafe62f30d8a0a44970a19af4d3949c5 Mon Sep 17 00:00:00 2001 From: mos-dt-0 Date: Wed, 5 Aug 2026 15:20:46 -0500 Subject: [PATCH] =?UTF-8?q?docs(remediation):=20bank=20D-55d=20=E2=80=94?= =?UTF-8?q?=20I=20measured=20both=20fields,=20analysed=20one,=20and=20hid?= =?UTF-8?q?=20the=20answer?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The rule resolves on two fields: author = poster, committer = merger. Both roles are recorded, in different fields. Re-verified on all four mosaicstack rows: #1027, #1033 and #1032 fit on both fields; #1041 is the sole anomaly and sits in the same repo on the same instance as #1027, which kills the estate- or instance-dependent hypothesis. No mechanism proposed — one anomalous row does not earn one. My error is a third distinct variant of tonight's class. I collected committer in my own measurement, printed it in my own raw output, and then dropped the column when I tabulated and reported the finding. My table read poster, merged_by, squash_author, supports — four columns, internally consistent, missing the one field that resolved the question. I framed it as an unresolved contradiction while holding the resolution in my scrollback. Three variants, three seats, one hour: the coordinator reused a control across a changed question, I reused an exclusion across a changed question, and then I discarded a measured field during summarisation. The third is the most insidious because nothing was wrong with the measurement, only with the summary of it — D-33's shape exactly, where a summary that resembles an enumeration is more dangerous than one that obviously summarises. A four-column table looks like the data. Rule banked: when a question changes, re-derive the control, re-check the exclusions, and re-read the RAW measurement rather than the table you made of it, because the table was built to answer the previous question. This de-escalates tl-mosaic's alarm: a dedicated merge-gate merger does not systematically destroy authorship, because the merger lands in committer while author survives, and git log and git shortlog read author. #1027 is the direct case. The alarm was still right to raise; its premise was an unestablished claim, not its reasoning. Also recorded as a blocking gap: installed pr-merge.sh sends a fixed squash payload with no message field and the role allowlist excludes MergeMessageField, so the trailer mitigation cannot be executed by the seat merging is reserved to. That gates #1030's trailers at merge time — which is precisely why the trade was also recorded in the PR body, where nothing needs to execute for it to survive. Co-authored-by: tl-mosaic Co-Authored-By: Claude Opus 5 (1M context) --- docs/remediation/TASKS.md | 58 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) diff --git a/docs/remediation/TASKS.md b/docs/remediation/TASKS.md index 198e146b..5cb653bc 100644 --- a/docs/remediation/TASKS.md +++ b/docs/remediation/TASKS.md @@ -736,6 +736,64 @@ that survives a counterexample the alternative fails is better endorsed than one lose that reason** — if the squash takes the merger, rotation protects nothing. Decisions stand on their other reasons; **the reason that _felt_ decisive is the one that was not measured.** +### D-55d — I MEASURED both fields, ANALYSED one, and thereby hid the answer for an hour + +**The rule resolves on TWO fields: `author` = POSTER, `committer` = MERGER. Both roles are recorded, in +different fields.** Confirmed across two estates and two repos, and re-verified on all four mosaicstack +rows: + +| PR | `author`==poster | `committer`==merger | verdict | +| --------- | ---------------- | ------------------- | ----------- | +| **#1027** | ✅ | ✅ | **FITS** | +| **#1033** | ✅ | ✅ | **FITS** | +| **#1032** | ✅ | ✅ | **FITS** | +| **#1041** | ❌ | ✅ | **ANOMALY** | + +**3 of my 4 fit; `#1041` is the sole exception — and it sits in the SAME repo on the SAME instance as +`#1027`, which fits.** So the "path- or instance-dependent by estate" hypothesis is dead: whatever +`#1041` is, it varies **within** one repo. **No mechanism is proposed — one anomalous row does not earn +one.** + +> **★ MY ERROR, AND IT IS A THIRD DISTINCT VARIANT OF TONIGHT'S CLASS. I collected `committer` in my own +> measurement, printed it in my own raw output, AND THEN DROPPED THE COLUMN when I tabulated the finding +> and reported it.** My table to the coordinator read `poster | merged_by | squash_author | supports` — +> four columns, internally consistent, and **missing the one field that resolved the question.** I then +> framed the whole thing as an unresolved poster-vs-merger contradiction **while holding the resolution +> in the terminal scrollback.** + +**Three variants of one class, three seats, one hour:** + +| seat | error | +| ------------------ | --------------------------------------------------- | +| coordinator | reused a **control** across a changed question | +| this seat (first) | reused an **exclusion** across a changed question | +| this seat (second) | **discarded a measured field during summarisation** | + +**The third is the most insidious, because nothing was wrong with the measurement — only with the +summary of it.** That is **D-33's shape exactly**: _a summary that resembles an enumeration is more +dangerous than one that obviously summarises._ A four-column table **looks** like the data. + +> **RULE: when a question changes, re-derive the CONTROL, re-check the EXCLUSIONS, and re-read the RAW +> MEASUREMENT — not the table you made of it.** The table was built to answer the previous question. + +**Consequence for `tl-mosaic`'s alarm — substantially de-escalated:** a dedicated `merge-gate` merger +does **NOT** systematically destroy authorship, because the merger lands in `committer` while `author` +survives — and `git log` default output and `git shortlog` read `author`. `#1027` is the direct case: +`Mos` merged it, `Mos` is the committer, `mos-dt-0` retained authorship. **The alarm was still right to +raise; the premise it rested on was an unestablished claim, not its reasoning.** + +**UNCHANGED AND STILL CARRYING EVERY DECISION: the BRANCH commit author is discarded.** Trailers remain +required. + +> **★ BLOCKING GAP ON THE TRAILER MITIGATION (`merge-gate`, queued to the coordinator with #1019): +> installed `pr-merge.sh` sends a fixed `{"Do":"squash"}` with NO message field, and the role-authorized +> payload allowlist excludes `MergeMessageField`.** **So the mitigation the fleet just ruled CANNOT BE +> EXECUTED by the seat the contract reserves merging to** — the fourth unsatisfiable gate tonight. +> Refusing GO is correct; **frozen heads must NOT be amended as a workaround** (amending voids the +> reviews and every gate behind them). **This directly gates #1030: its trailers cannot be applied at +> merge until `pr-merge.sh` accepts a squash message — which is exactly why the trade was ALSO recorded +> in the PR body, where nothing needs to execute for it to survive.** + ### D-55b — two parties quoting a third is not corroboration The coordinator wrote _"installer-7's live-panel GREEN was the last thing before the command"_ **having