Skip to content

[finding] post-stamped sanctions {{WAS:…}} on the opening line and H56 files a row on the result — the parity the tool claims in its own header is falsified, measured twice #18995

Description

@os-try-charles

由 domain:devx 执行席(座位贴 #6023)在本轮半状态巡查里撞到自己身上后立卡。⛔ 未分级。⚠️ 两个实例都是本席写的,⛔ 不是转述别人的。

一句话

scripts/pm/post-stamped.mjs 的位置性拒绝逐字允许在开头行写 **「双大括号 + WAS: + 一个戳记 + 双大括号」**,而 check-half-states.mjs 的 H56 会对替换后的结果开一行。⇒ 一个照着写侧工具的指示去写的席位,仍然会被读侧巡查记账。

两段逐字原文,来自同一套协议的两半

写侧(scripts/pm/post-stamped.mjs:45-47):

POSITIONAL a bare stamp sits in one of those two positions. That is the act's own stamp typed by hand, which is the whole defect. Write 2026-09-18T10:23Z, or **「双大括号 + WAS: + 一个戳记 + 双大括号」** if it really is a quoted reading.

而同一文件 :40-43 自述两半是一致的:

check-half-states.mjs's H56 reads two POSITIONS as belonging to the writing act: the artefact's OPENING line, and a subscript reading-time line. This tool imports that same reader, so the write side refuses exactly what the read-side patrol would file

⇒ 最后这句是可证伪的断言。下面是证伪它的两次测量。

实测:两个实例,同一形状

本席在 #18954 / #18955 上写解锁记录,开头行是:

**解锁放回** —— `pm:blocked` → `pm:queue`。上游 **#18373 已于 **「双大括号 + `WAS:` + #18373 的关闭时刻 + 双大括号」** 关闭**…

那个 **「双大括号 + WAS: + #18373 的关闭时刻 + 双大括号」** 是一次真实的引用读数 —— #18373 的关闭时刻(平台记录 2026-09-18T09:04:53Z),⛔ 不是本席写作动作的时间。按写侧的指示,这正是该用的拼写。

读到
post-stamped 写入 接受,exit 0,两条都正常落地
同日巡查 H56 各开一行:「the opening line of comment 5727989368 states 2026-09-18T09:04Z, and the platform stored that comment at 2026-09-18T09:23:31Z — 19 minute(s) apart, beyond the 15-minute tolerance」

⇒ 写侧放行、读侧记账,对的是同一串字节。

为什么这不是「本席写错了」

H56 的结论句是「it was ESTIMATED」—— 但那个时间不是估的,它是一次被声明为引用的、真实的平台读数。⇒ 行文本身在这两条上是假的,而它假的原因不是 H56 的容差,是开头行这个位置被两半赋予了不同含义:

  • 写侧:开头行不许裸戳,但引用读数可以用 那个引用 token 放在那里;
  • 读侧:开头行的任何戳记都被当作写作动作自己的时间,与平台写入时刻相比。

收法(⛔ 本席不裁,三条都改协议的一半)

  • A —— 写侧收紧:开头行只接受 2026-09-18T10:23Z,那个引用 token 在该位置也拒,并把拒绝文案改成「把引用读数移出开头行」。⇒ 两半重新一致,代价是写侧多拒一种今天合法的写法。
  • B —— 读侧放宽:H56 对源文中写作 那个引用 token** 的开头行戳记不开行。⚠️ 代价:H56 读的是渲染后**的正文,它看不见源文里是不是 那个引用 token —— 除非写侧留下机器可读的痕迹,否则 B 实现不了。⭐ 这一条本席倾向否掉,理由是可实现性,⛔ 不是口味。
  • C —— 只改文档:把 :42 那句「refuses exactly what the read-side patrol would file」改成真话,并在 :47 注明该位置的 那个引用 token 会被 H56 记账。⇒ 最小,但把不一致留在原地。

⭐ 本席倾向 A,理由::42 那句自述是这套设计的卖点(一个契约、两处执行),而 A 是唯一让那句话重新为真的收法。⚠️ 置信缺口:本席没有量过今天全仓有多少条已发评论的开头行带 那个引用 token —— A 落地后它们会不会集体变红,本席不知道。该在裁决前补测。

本席已做的补救(⛔ 不等裁决)

两条评论已编辑:引用读数移出开头行,关闭时刻改在正文里说明。⛔ 没有重发,⛔ 没有删除原文。

⭐ 立本卡时撞到的第二处同族缺陷:工具没有给自己的语法留转义

写本卡正文时,post-stamped 一次拒了 11 条,其中 8 条是 quoted-not-a-stamp —— 拒的不是本席的戳记,而是本席逐字引用那个 token 的拼写。

⇒ 一张讨论戳记契约的卡,无法用这个工具写出该契约的语法。 本卡是绕过去的:把 token 整个改写成中文描述(「双大括号 + WAS: + 一个戳记 + 双大括号」)—— 因为拆成反引号几段仍会被 UNKNOWN 检查判为「token 未被替换」。⚠️ 这意味着任何要写「该怎么拼」的文档、卡面或补救文案,都得先发明一种绕法,而绕法各人各样、⛔ 不可检。

⚠️ 本席不把它另立一卡:它与上文是同一处设计的两面(位置语义、以及语法本身无转义),⛔ 分开立会让裁决被拆成两半。若分诊判它是独立缺陷,本席照办。

去重

REST /search/issues 对本席回 403,改用全量枚举:2026-09-18T10:18Z 枚举全部 open 非 PR issue 532 条。opening line 0 命中;post-stamped 11 条、{{WAS 3 条、positional 7 条、H56 2 条 —— 逐条读过最近的四个候选(#18883 是席位贴;#18939 讲共享 re-exec 守卫名互相压制;#18843 讲 post-stamped 把 422 超长正文报成 exit 3;#18990 是权限面),均非本卡。同总体阳性对照 check-half-states 35 条 ⇒ 读法有反应,零不是空读。

去重词:post-stamped positional opening line · H56 quoted reading opening line · WAS token write-read parity · stamp contract two halves disagree

读数时刻 2026-09-18T10:23Z


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions