docs(TelegramSecretary): 裸数値の網を手順と仕様に載せる（v1.15.0）

Stage 1-2 で入れた lint-numbers は、掛ける手順が無ければ誰も掛けない。
送信前チェックの並び（send-reply / proactive-send の両経路）に「納品物は
原稿 md へ掛け、裸の行に計器を書いてから送る」を置き、なぜ presence だけを
見るのか・なぜ納品物だけに張るのかを DESIGN §3.13 に残す。

網を納品物側に限るのは、handoff 側で分析ノート運用が現に効いており、効いて
いる側に二重の関門を足すのが加算バイアスだから。納品物は読み手が第三者まで
届く分だけ誤読コストが非対称で、かつ裸率が一度も測られていなかった。

裸の有無を exit code に載せないことと、裸 0 件でも JSON を 1 行出すことを
仕様側にも明記する。前者は外部契約（exit 0-4）に新しい意味を重ねないため、
後者は黙る計器が「掛け忘れ」と「全緑」を区別させないため。

STRUCTURE の domain/ は number_lint.py の追記ついでに、既存の記載漏れ
（output_scan.py / rate_limit.py）も backfill した。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: web-flow

.claude-plugin/marketplace.json

@@ -117,7 +117,7 @@
       "name": "TelegramSecretary",
       "source": "./TelegramSecretary",
       "description": "Telegram Bot API の long-polling を cloud routine 上で常駐させ、認可済みチャットからのメッセージに秘書エージェント（SecretaryRole）が即応する対話チャネル",
-      "version": "1.14.0",
+      "version": "1.15.0",
       "author": {
         "name": "Weave @ TelegramSecretary"
       },

TelegramSecretary/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "TelegramSecretary",
-  "version": "1.14.0",
+  "version": "1.15.0",
   "description": "Telegram Bot API の long-polling を cloud routine 上で常駐させ、認可済みチャットからのメッセージに秘書エージェント（SecretaryRole）が即応する対話チャネル",
   "author": {
     "name": "Weave @ TelegramSecretary"

TelegramSecretary/README.md

@@ -100,6 +100,7 @@ python scripts/main.py lease release
 | `send-reply --chat-id --update-id --text-file [--file ...] [--reply-to] [--owner]` | 返信送信。`--file` で添付、`--reply-to` で threading | 0, 1=送信失敗, 2=添付不正, 3=auth, 4=lease |
 | `proactive-send --chat-id --text-file [--file ...] [--reply-to] [--owner]` | 秘書からの能動送信（inbound 非依存の outbound push、offset 非干渉）。**`--update-id` 無し**が send-reply との差分。`--file` で添付、`--reply-to` で threading | 0, 1=送信失敗, 2=添付不正, 3=auth, 4=lease |
 | `render-pdf --path (--text \| --pages N-M)` | 受信済み PDF のオンデマンド抽出（`--text`=全文テキスト / `--pages`=指定ページ画像化） | 0, 2=不在/引数不正 |
+| `lint-numbers <path>` | 納品物（原稿 md）の裸数値スキャン。数字を含む各行に計器トークン（`実測` / `見込み` / `出典` 等の出所マーカー）が同じ行にあるかを二値判定し JSON 1 行で emit（`path` / `number_lines` / `covered` / `bare` / `bare_lines`）。presence の検査であって正しさの検査ではない。read-only、裸 0 件でも 1 行出す。裸の有無は exit code でなく JSON の値（DESIGN §3.13） | 0=OK（裸の有無に依らず）, 2=不在/不可読 |
 | `test --chat-id` | 疎通テスト（owner chat に ping 送信） | 0, 1, 3 |
 | `cleanup-media` | retention 超過の保存 media を削除（`watch` は自動発火、手動/cron 用） | 0, 2 |
 | `individuals\|tasks\|knowledge\|subjects\|abilities\|profile\|goals\|steps {list\|get\|add\|remove\|import}` | 管理表 CRUD（8 表、値オブジェクトで入力検証、不正は exit 2）。`add` / `import` はトップレベル未知キーを exit 2 で弾く（fail-closed。read 経路は警告どまりで読める）、`import --json-file` は全件置換（全件検証→置換ゆえ 1 件でも不正なら無置換）。`registry_sync` 有効時は add/remove/import 後に commit&push | 0, 2 |

TelegramSecretary/commands/telegram-secretary.md

@@ -24,6 +24,7 @@ description: cloud routine 常駐 Telegram 秘書の登録・設定・管理表
 | `artifacts-sync` | 成果物層 `artifacts/`（申し送りの `handoff/` ブロックを含む）を固定ブランチへ commit & push | `scripts/main.py` |
 | `handoff-archive <name>...` | 消化済みの申し送りブロックを `handoff/archive/` へ卒業させる（以後 orientation に載らない） | `scripts/main.py` |
 | `role-status` | P×A 役割（秘書/執事/コーチ/守護霊）のデータ駆動判定 | `scripts/main.py` |
+| `lint-numbers <path>` | 納品物（原稿 md）の裸数値スキャン（数字の行に出所の計器トークンが同じ行にあるかの二値、read-only）。presence の検査であって正しさの検査ではない | `scripts/main.py` |
 | `test --chat-id` | owner chat への疎通 ping | `scripts/main.py test` |
 
 > 詳細な引数・exit code・env vars は [`SKILL.md`](../skills/telegram-secretary/SKILL.md) の Subcommands 表が SSoT。

TelegramSecretary/docs/CHANGELOG.md

@@ -2,6 +2,64 @@
 
 すべての主要な変更をこのファイルに記録する。形式は [Keep a Changelog](https://keepachangelog.com/ja/1.1.0/)、バージョニングは [Semantic Versioning](https://semver.org/lang/ja/) に準拠する。
 
+## [1.15.0] - 2026-09-02 — 納品物の裸数値に機械の網を張る：網は誤読コストの非対称な側にだけ張る
+
+数値に出所（実測なのか見込みなのか継承なのか）が添えられていないと、読み手はどの数を
+信じてよいか決められない。この「裸の数値」を拾う `lint-numbers` を足す。ただし拾うのは
+**同じ行に計器トークンがあるか**という presence だけで、対象も**納品物だけ**に絞る。
+
+### 機序
+
+**問題は表記ではなく注意の配分だった。** handoff 34 件の実測で裸率は 0〜58.3% に振れ、
+降下と再発を 2 周した。表記の癖なら一度直せば収束する——振れるということは、書き手の
+注意が他へ向いた枠で再発するということである。ゆえにゼロを目標に置かない（残差は漸近
+消滅しない）。網は「根絶する装置」ではなく「注意が逸れた枠で気づかせる装置」である。
+
+**納品物側だけに張るのは、誤読コストが非対称だから。** handoff 側は分析ノート運用が現に
+効いており（分母が 30〜50 帯から 84/96/104 へ増えても裸は 4〜8 のまま）、効いている側に
+二重の関門を足すのは加算バイアスになる。一方、納品物は読み手が大環主とその先の第三者で、
+誤読のコストが書き手に返ってこない——かつ裸率が一度も測られていなかった。
+
+**presence だけを見るのは、正しさが形状に現れないから。** 除外規則（ID・日付を候補から
+外す）を書き始めた瞬間、それは妥当性判定の入口になり、決定論の世界に置くべきでない判断が
+コードへ漏れる。数字を含む行はすべて候補とし、linter は当たり付けどまりに留める。
+**偽陰性 ＞ 偽陽性**——偽陽性は読み直し一回で済むが、偽陰性は「緑を信じる」危険に直結する
+ので、一文字・高頻度語は計器トークンに採らない（迷ったら外す＝偽陽性側へ倒す）。
+
+### Added
+
+- `lint-numbers <path>` — 納品物（原稿 md）の裸数値スキャン。JSON 1 行で stdout
+  （`path` / `number_lines` / `covered` / `bare` / `bare_lines`）。read-only で config /
+  lease / レジストリに触れない。**裸 0 件でも 1 行出す**（黙る計器は掛け忘れと全緑を
+  区別させない）。走査完了なら裸の有無に関わらず exit 0——二値は JSON 内の値で、
+  外部契約である exit 0-4 に新しい意味を重ねない。パスが読めないときだけ exit 2
+- `scripts/domain/number_lint.py` — 行走査の純関数と計器トークン定数（`GAUGE_TOKENS`
+  20 語）。語彙の校正はこの定数 1 箇所の追補で済み、コード構造に触れない
+
+### Changed
+
+- `DESIGN.md` §3.13（新設）— presence-only と納品物限定の設計根拠 SSoT
+- `SKILL.md` / `README.md` / `commands/telegram-secretary.md` — Subcommands 表に 1 行。
+  SKILL の Failure Modes に「裸検出は exit に載らない」の注記
+- `ROUTINE_PROMPT.md` — 送信前チェックに「納品物は**原稿 md** に `lint-numbers` を掛け、
+  裸の行に計器を書いてから送る」を追加（send-reply / proactive-send の両経路）。
+  **納品物側と handoff 側の裸率は別々に報告し、合算しない**（母集団が違う）
+- `STRUCTURE.md` — `domain/` に `number_lint.py`。併せて既存の記載漏れ
+  （`output_scan.py` / `rate_limit.py`）を backfill
+
+### 互換性
+
+**後方互換**（新規 subcommand の追加のみ。既存の受信・送信・管理表の経路に変更は無い）。
+掛けるのは**秘書の手順**であって送信経路のフックではない——`send-reply` /
+`proactive-send` に自動ブロックは組み込まない（判断を決定論の側へ移さない）。
+
+> **本番到達には別操作が要る**（本版のコミットだけでは本番に届かない）。cloud routine は
+> 基本設定リポを fresh clone するため、(a) コードは **HW 本体側の junction 追従コミット
+> （`Expertises/TelegramSecretary`）と PR マージ**を経て初めてコンテナに載る。(b) 秘書が
+> 実際に送信前へ掛けるようになるのは、**ROUTINE_PROMPT の body を RemoteTrigger で再登録
+> した後**である（リポ内の md を直しただけでは稼働中の routine の手順は変わらない）。
+> 到達経路は clone 起点ゆえ、**タグは不要**。(a)(b) はいずれも本タスクの外で実施する。
+
 ## [1.14.0] - 2026-08-28 — TASKS の終端に `cancelled` を足す：取り止めを「やり遂げた」と記録しない
 
 TASKS の終端は `done` 一つだった。依頼が取り下げられても要件が消滅しても、閉じる語は

TelegramSecretary/docs/DESIGN.md

@@ -20,6 +20,7 @@
   - [3.10 なぜ artifacts を成果物層として持つか（決定論の管理表と分ける理由）](#310-なぜ-artifacts-を成果物層として持つか決定論の管理表と分ける理由)
   - [3.11 なぜ P×A 直交2軸で役割が進化するか（PROFILE/GOALS/STEPS・データ駆動判定・占術スキル接続）](#311-なぜ-pa-直交2軸で役割が進化するかprofilegoalsstepsデータ駆動判定占術スキル接続)
   - [3.12 なぜ起動時ロードは orientation ダイジェストか（沈黙失敗と上流配置）★起動時オリエンテーション SSoT](#312-なぜ起動時ロードは-orientation-ダイジェストか沈黙失敗と上流配置起動時オリエンテーション-ssot)
+  - [3.13 なぜ presence-only か・なぜ納品物だけか（裸数値 lint）★lint-numbers 設計根拠 SSoT](#313-なぜ-presence-only-かなぜ納品物だけか裸数値-lintlint-numbers-設計根拠-ssot)
 - [4. Scope: 公式 plugin（/channels）との差分と採否](#4-scope-公式-pluginchannelsとの差分と採否)
   - [構造的要約](#構造的要約)
   - [今後の判断指針](#今後の判断指針)
@@ -276,6 +277,20 @@ individuals/tasks/knowledge が「事実データ」（誰と・何を頼まれ
 
 > 消化（handoff → knowledge への結晶化）と卒業（archive）のサイクルは v1.6.0 で載った。分離（第一段）が「読む量を切る」だったのに対し、消化と卒業は**母数そのものを減らす**——選択（何を結晶化し、何を卒業させるか）＝α は秘書の判断に残し、移動と読み筋だけをコードが持つ（§2 の踏襲）。
 
+### 3.13 なぜ presence-only か・なぜ納品物だけか（裸数値 lint）★lint-numbers 設計根拠 SSoT
+
+数値に出所（実測なのか見込みなのか継承なのか）が添えられていないと、読み手はどの数を信じてよいか決められない。`lint-numbers` はこの「裸の数値」を機械で拾うが、**拾うのは presence だけ**であり、対象も納品物だけに絞ってある。両方とも消極的な設計判断ではなく、実測から出た線である。
+
+- **問題は表記ではなく注意の配分だった（T0015 の実測）**: handoff 34 件を数えたところ、裸率は 0〜58.3% の幅で振れ、**降下と再発を 2 周**した。表記の癖なら一度直せば収束するはずで、振れるということは書き手の注意が他に向いた枠で再発するということ——**ゼロを目標に置かない**（残差は漸近消滅しない）。ゆえに機械の網は「根絶する装置」ではなく「注意が逸れた枠で気づかせる装置」として設計する
+- **なぜ納品物だけか（誤読コストの非対称）**: handoff 側は分析ノート運用（案2）が現に効いている——分母が 30〜50 帯から 84/96/104 へ増えても裸は 4〜8 のまま抑えられた。一方**納品物側は読み手が大環主とその先の第三者**であり、誤読の costs が自分に返ってこない。加えて納品物の裸率は一度も測られていなかった。**網は誤読コストの非対称な側にだけ張る**——効いている側に二重の関門を足すのは加算バイアスである（適用拡大は `number_lint.py` の `cc-defer` にトリガーを刻んである）
+- **なぜ presence-only か（正しさは形状に現れない）**: 「同じ行に計器トークンがあるか」は形状で決まるが、「その数が正しいか」は形状に現れない。除外規則（ID・日付・セッション名を候補から外す）を書き始めた瞬間、それは妥当性判定の入口になり、決定論の世界に置くべきでない判断がコードへ漏れる。ゆえに**数字を含む行はすべて候補**にし、linter の役割は**当たり付け（候補分析）どまり**とする。読んで分類するのはエージェントの手順であって、コードのフックではない（`output_scan.py` と同じ境界宣言：形状で決まるものだけ機械化する）
+- **偽陰性 ＞ 偽陽性（緑の危険）**: 誤りの二方向はコストが等しくない。偽陽性（covered なのに bare と呼ばれる）は読み直し一回で済む。**偽陰性（部分文字列の偶然一致で bare が covered に化ける）は「緑を信じる」危険に直結する**——掛けた本人は確認済みのつもりで送る。ゆえに計器トークンは一文字・高頻度語を採らない（「約」は 契約 / 約款 / 予約 に包含される、「数え」は「手柄に数えない」を緑にする）。**迷ったら外す＝偽陽性側に倒す**。同じ理由で**裸 0 件でも JSON 1 行を出す**——安全側で黙る計器は「掛け忘れ」と「全緑」を区別させない
+- **なぜ exit code に載せないか**: 二値は JSON 内の値とし、走査が完了すれば裸の有無に関わらず exit 0 とする。exit 0-4 は SKILL.md / `bootstrap.sh` が分岐する**外部契約**で、「裸あり=1」は fetch 失敗と衝突する。新しい意味を既存コードに重ねない（`exit_codes.py` の SSoT を割らない）
+- **なぜ原稿 md 側に掛けるか**: 納品物は md 原稿と html の対で作られる運用実態がある。生 HTML に行走査を掛けると属性値・px・hex 色でほぼ全行が候補化し、**ノイズに慣れて緑を読み飛ばす**状態を自前で作る（T0015 が案1の難点として挙げた再現）。タグ剥がしは判定の入口なので実装しない——**HTML しか無い納品物で候補ノイズが出るのは仕様**とし、原稿 md に掛けるのを正規手順とする（手順は ROUTINE_PROMPT）
+- **校正はデータ 1 箇所で行う**: 計器トークンの SSoT は T0015 分析ノートの実践語彙（「同じ行に計器か導出元か継承の別を名指していれば添えた」の三分類）で、linter はそれを語形の部分文字列一致で近似する。納品物側の語彙は未測定（34 件は全て handoff）なので、運用で偽陽性が偏る語が見えたら `GAUGE_TOKENS` の追補で直す——**定義の校正がコード構造に触れない**形にしてある
+
+> 掛けるのは秘書の手順であって送信経路のフックではない。`send-reply` / `proactive-send` に自動ブロックを組み込むと、判断（この数に出所は要るか）が決定論の側へ移ってしまう——**関門を置いてよいのは決定論の世界にだけ**という §2 の線を、ここでも踏襲する。
+
 ---
 
 ## 4. Scope: 公式 plugin（/channels）との差分と採否