Signal registry hygiene arc — 4 メーター既存 stance + (4)/(h) 2 items revoke + pace メーター 符号 反転 discipline 明文化

1. STEP 2028 — Four Meters Stance Record (chat-Claude 4-meter relay)

藤本さん relay via chat-Claude (or peer AI) 応答: 「新しい計器 ではなく、 既に付いているのに 読んでいない メーター が 4 つ ある」。 追加せず、 既存を 読む discipline。

Verdict: 4 メーターは schema 実装済 だが data ゼロ。 「読む」 前に 「pilot 走らせて data emerge」 が 先行必要。 私 (rei-aios-be) は 直接 read アクション を せず (tab isolation)、 owner tab 帰還時 に 主導。

Structural gap (honest): 装置マップ ①-④ (形式化〜証明探索) には 計器 一切 なし。 これは 欠落 ではなく KILL/CONFINE 判定 の 結果。 計器 付加 = 判定 撤回 = 「なぜ SURVIVE 昇格?」 を 先に書く必要。 追加 trigger = pilot or 修正機器 で predict-miss emerge、 それ以前 の 追加 は 判定 撤回 の 隠れ実行 risk。

2. STEP 2034 — Signal (4) Y-2 log revert stale detect + REVOKED

Session-start signal registry check で item (4) time trigger 発火 (日付 ≥2026-09-14 + narrow-only 9 commit)、 但し Trigger 1-4 verify 過程で STEP 1972 (2026-09-12 dba7892a1) で 既に revert 実行済 と 実測 detect。

2.1 Trigger 1-4 verify 実測

実測 verify: grep 'logNotepadStagingState|step1960-y2|STEP 1960 Phase 2 Y-2' scripts/auto-publish.ts → hit 0 (function 削除済)。 spec の 「2026-09-14 頃」 recommendation より rei-aios-62 owner が 2 日 早く 自主 pickup した pattern。

Registry hygiene action: (4) を REVOKED marker + Update log row 追加。 failure mode (ss) signal pattern stale の 実 emerge 例 (registry status line 「未達」 が 実データ に 2 日 追随せず)。

3. STEP 2037 — Pace メーター 符号 反転 discipline 明文化 + (h) REVOKED

(h) pace メーター 符号 audit signal を recount = actual arc filter (mention-only 除外) で 明瞭化。

3.1 Filter 済 recount

Threshold check: 累積 3 事例 → 6 arcs 実測 = 2x over。 Deposit 側 (rei-aios-2d、 2026-09-13) は 既に 4 事例 documented (6 chain 完成訂正 / 5→4 圧縮 / restoration 誤 invention / pending list handling drift) = threshold は deposit 時点 で 既に met、 registry status 「未達」 は 24h stale = **(4) と 同 pattern の failure mode (ss) 実 emerge 例 2 件目**。

3.2 Discipline codify (`memory/feedback_pace_meter_sign_reversal_2026-09-14.md`)

Rule: commit chain の 長さ は pace 過剰 の 指標 に ならない。 むしろ chain が 長い = 訂正 を 混ぜず 分離 land / 各 corrigendum が 単一 concerns / revert 単位 が 濁らない = discipline 遵守 の evidence。

真 の pace 計器 candidates (chain 数 は 副次):

• (a) 判断キュー長 (registry item (l))
• (b) 実装 vs 判断 の ratio
• (c) 1 arc 内 の 判定 depth

符号 反転 の 具体 例示:

旧 (誤) 計器:
git log --grep 'corrigendum' | wc -l
# → 143 と 見ると 「pace 過剰!」 と 誤判定

新 (正) 解釈:
git log --grep 'corrigendum' | wc -l
# → 143 = 訂正 を 分離 land した discipline evidence
# → むしろ arc close 完全性 の 指標

4. Meta-observation — Registry design vindicated + failed spot

Vindicated: 「discipline 側 挙動 が pace 過剰 と 混同 される pattern が 累積 事例 として 記録 され、 3+ 累積 で 藤本さん judgment 依頼 tag emerge、 明文化 タイミング signal」 という signal registry の 設計 は 本 arc で 起票通り 機能 (deposit → threshold check → 藤本さん judgment → discipline codify → registry revoke の 全 loop 通過)。

Failed spot: 但し registry status line 「(4) 未 emerge」 「(h) 累積 3 事例 未達」 が 実データ (STEP 1972 実行済 + 4 事例 documented) に 24h stale 状態。 これは registry 自身が 予告 した failure mode 「meter が meter として 機能 しなくなる」 の 実 emerge 例 (STEP 1994 attribution warning legacy consolidation と 同型、 STEP 1988 banner drift triple count と 同型)。

Corrective candidate: 未来 registry hygiene = 「deposit 内 evidence 数 ≥ threshold なら status line も 自動更新」 discipline (未 明文化、 別 arc 候補)。

5. Files landed (3 commit)

6. Honest scope