Kairos ドキュメントレビュー（第14回）— 1.0.12

収蔵（2026-10-26・kairos-project）: 対象＝公開 azathothx/kairos-lang HEAD 43e3734（版 1.0.12・Release v1.0.12）と検定 azathothx/kairos-lang-exam HEAD 937256a。レビュー日 2026-10-26。方法＝指示書 tools/cloud-sessions/review-14-clean-room.md の 5 観点＋検定の抜き取り 10 問を、正本を知らない 6 本の新規の機械レビュー（手元・各観点 1 本・読むのは公開 2 本の clone だけ）に分担させた。所見は各観点の原文のまま（番号は観点つき＝①-H1 …。収蔵の正規化＝原文の相対リンクはコードスパンに置き換え、役割語の検査に掛かる語 2 つを言い換えた）。統合の総評と実測サマリは当方。裏取りと処置は末尾「処置の記録」。

0. 総評（統合＝当方）

件数＝HIGH 3・MEDIUM 21・LOW 41。テスト数の突合は一致（880・typecheck 緑）、相対リンク 261 本と公開 URL 41 本は欠損 0、検定の抜き取り 10 問は全問一致。
HIGH 3 件はいずれも文書の例と実物の不一致＝①-H1 日本語 README の冒頭例（calendar: TSE）が実行不能・③-H1 spec §4.9 の「域外は静的エラー」の例 month(2020) が実物では空・ ④-H1 英語の 40-examples/11 (l) が hour を現在形で「標準に無い」と断言（日本語は ADR-50 で標準化と追記済み）。
MEDIUM の芯は 3 つ＝(a) 入口の導線（クイックスタートの警告と註釈の読み方・--tz・レシピの @JP は doctest 専用）(b) 1.0.12 の出口のラベルの規則が「字面の直接参照」であることが文書に無い（②-M1・③-M3・②-M3）(c) Playground の業務の例の固定窓が尽きている（⑤-M1）。
観点④（英語ミラー）は LOW 18 件＝訳語の揺れが主で、kairos フェンスの同一性は検査が守っている。

実測サマリ（統合）

項目	結果
`npm test`／`typecheck`（HEAD 43e3734）	880 本 PASS・typecheck PASS＝README 日英・llms.txt・impl/README の記載と一致
相対リンク／公開 URL	261 本欠損 0／41 本すべて 200
追補 29 の 5 点の実走（②）	主張どおり動く。文書の抜け＝ラベルの「字面」規則・`.ics` の題の複数式形
仕様の突合（③）	ラベル・評価註釈・終了コード・`at`・`take`・`within` は一致。例示の不一致 1（`month(2020)`）・`of:` の曖昧エラー・`Modified` 未実装の注記
英語ミラー（④）	kairos フェンス日英同一。意味ズレ 1（`hour`）・索引の抜け
鮮度（⑤）	祝日表 2026／2027・exe・MCP・llms.txt は一致。Playground の固定窓・「プロトタイプ」の語（1.1.0 で処置済み）
検定の抜き取り（⑥）	10 問全行一致・版の名乗りは 1.0.12 で一致

観点① 新規読者の導線（＋テスト数の突合）

レビュー日 2026-10-26。対象＝ azathothx/kairos-lang HEAD 43e3734（1.0.12）・azathothx/kairos-lang-exam HEAD 937256a。立場＝公開物だけを読む外部レビュアー（初見の利用者＋仕様を検査する技術者）。実行環境＝ Node v24.16.0・npm 11.13.0・機械の tz は Asia/Tokyo。

実測サマリ

検証項目	結果	根拠
`cd impl && npm test`（`TZ=UTC`）	39 ファイル・880 本すべて PASS（56.7 s・終了コード 0）	`Test Files 39 passed (39)` / `Tests 880 passed (880)`
`npm run typecheck`	PASS（終了コード 0・出力なし）	`tsc --noEmit`
テスト数の記載 vs 実数	一致＝ README.md:209「880 tests」・README.ja.md:37「880 テスト」・llms.txt:21「880 tests」・impl/README.md:234「39 ファイル・880 本」・en/spec/README.md「880 tests」	上記の実測 880
同・npm に公開済みの README（kairos-lang@1.0.12）	「39 ファイル・862 本」＝ HEAD と 18 本ずれ（公開時点の文面。L3）	`npm pack kairos-lang@1.0.12` → package/README.md:234
導線 1: README（英）	読める。ただし hero 例を機械 tz のまま走らせると時刻付きで出る（M2）・付録 A のリンクが日本語版（M4）	本文
導線 1: README（日）	最初のコード例が実行できない（H1）	`calendar: が指す premise が未定義: TSE`
導線 2: Playground（公開 URL）	日英とも 200・配信中の `IMPL_VERSION = '1.0.12'`・例 8 本・app.js／core.js／js/index.js すべて 200	`curl https://kairos-lang.org/playground/js/build-info.js`
導線 3: レシピ（recipes/・en/recipes/）	日英 9 ページ対称・Playground リンクは前提込みで decode→CLI 実走＝ doctest の期待値と一致。本文の `@JP` ブロックは貼ると動かない（M3）	下記 M3 の再現
導線 4: CLI	`npx -y kairos-lang@1.0.12 --version` → `1.0.12`・`node impl/dist/cli.js` で payday／jp-holidays／rokuyo 3 例とも終了 0・開発路 `node src/cli.ts --version` → `1.0.12`（Node 24）	本文
導線 5: MCP	`npx -y kairos-lang-mcp@1.0.12 --version` → `1.0.12`・stdio で initialize OK（serverInfo kairos-lang 1.0.12・proto 2025-06-18）・tool 4 本（kairos_list／next／validate／reference）・resources 2 種・kairos_list／next／validate／reference とも応答・`tz` 省略は入力検証エラー	本文
相対リンク（README 日英・llms.txt・mcp README 日英・recipes 日英全 18 ページ・impl/README・SKILL.md 日英・MAINTENANCE.md＝29 ファイル）	261 本・欠損 0	自作スクリプト（存在検査・ディレクトリは README／index の有無も検査）
公開 URL（上記文書から抽出・許可ホストのみ）	29 本すべて 200（kairos-lang.org 13・exam 1・github.com 4・raw.githubusercontent.com 15）。別途 `/README.ja`・`/mcp/README.ja`・`/skills/kairos-authoring/SKILL`（日英）・`/recipes/`・`/en/recipes/`・`/spec/60-…`・`/en/spec/61-…` も 200。未検査（指示のホスト外）＝ developercertificate.org・modelcontextprotocol.io・registry.modelcontextprotocol.io の 3 本	`curl -L -o /dev/null -w '%{http_code}'`
Release	`releases/tag/v1.0.12` 200・`releases/latest` → v1.0.12（302）・資産 `kairos-1.0.12-win-x64.zip`（36,225,004 B）＋ `.sha256`	GitHub API
npm	kairos-lang latest 1.0.12（2026-10-26T00:07Z）・kairos-lang-mcp latest 1.0.12（同 00:12Z）。公開物の依存は `kairos-lang: ^1.0.11`（HEAD の mcp/package.json は `^1.0.12`。M5）	`npm view kairos-lang-mcp dependencies`
版番号の古さ	README.md:58／README.ja.md:102／llms.txt:106「reference CLI 1.0.5」・llms.txt:93「1.0.2」。引用文 5 本は 1.0.12 で一字一句再現（L1）	下記 L1
ADR 数	README.md:221「53 ADRs」・README.ja.md:50「ADR-01〜53」・llms.txt:204「53」＝ design/20-adr の実数 53 と一致	`grep -rl "^# ADR" design \\| wc -l` → 53

HIGH

①-H1 日本語 README の最初のコード例が、CLI・MCP・Playground のどれでも実行できない

何が: README.ja.md:11-16 の冒頭の例
```
premise JP { calendar-system: Gregorian; calendar: TSE; tz: "Asia/Tokyo"; wkst: Mon }

@JP
monthEnd |> roll(Preceding, on: bizDay) |> shift(-3, unit: bizDay)   # 毎月末の 3 営業日前
```
は calendar: TSE を参照するが、TSE というカレンダー実体は npm パッケージの stdlib（gregorian／fiscal／isoweek の 3 本）にも Playground（playground/core.js・app.js に calendar: TSE は 0 件）にも存在しない。英語 README（README.md:18-26）と llms.txt:60-68 の同じ趣旨の例は祝日表と bizDay 導出を書いた自己完結形で、こちらは実行できる。
どこで: README.ja.md:12（calendar: TSE）。日本語を正とする言語の、日本語 README の最初の例。
再現:
```
$ node impl/dist/cli.js list readme-ja.kairos --from 2026-01-01 --to 2026-07-01
calendar: が指す premise が未定義: TSE
EXIT=1
```
MCP kairos_validate（npx -y kairos-lang-mcp@1.0.12・同じ source）→ {"ok":false,"version":"1.0.12","diagnostics":[{"kind":"static","message":"calendar: が指す premise が未定義: TSE"}]}。比較: README.md:19-25 を同じ条件で → 2026-01-27T14:00 … 2026-06-25T13:00（6 点・終了 0。時刻付きで出る件は M2）。
影響: 新規読者が README.ja.md の例を Playground に貼ると最初の一歩で静的エラーに当たる。README.ja.md:60「まずブラウザで試す」の直後に起きる。TSE が spec の説明用の名前（spec/20-premise-layer.md:43・spec/90-examples.md:61・reference/README.md:76 の doctest 標準前提）であることは、README だけを読む人には分からない。
直し方の案: README.ja.md の例を README.md と同じ自己完結形（表 covering: 2026..2026 ＋ satSun／bizDay 導出）に差し替える。短さを保ちたいなら、例の直後に「TSE は利用者が定義するカレンダー実体。動く形は Playground の「月末の 3 営業日前」を参照」の 1 行を足す。doc-consistency の検査に「README のコードブロックは doctest で実行する」項を加えると再発しない。

MEDIUM

①-M1 クイックスタートの実出力に、README に説明のない警告・註釈・負の残走路が出る

何が: README.md:158-159／README.ja.md:67-68・172-175 の推奨コマンドをそのまま走らせると、最初に目に入るのが未説明の 警告:／# ⚠／残走路 -25 日 になる。
どこで: README.md:149-176「Quick start」・README.ja.md:58-88「クイックスタート」。README にはこれらの読み方が無い（説明は recipes/logistics-delivery.md:206・recipes/windows-admin.md:266・spec/61-supply-profile.md:164・Playground の脚注にある）。

再現（2026-10-26・Asia/Tokyo）:

$ node impl/dist/cli.js list impl/examples/jp-holidays.kairos --from 2026-01-01 --to 2027-01-01
警告: window-clip: shift(-1) 2026-01-01 → 2025-12-31（評価範囲 from, to) の外へ動いた点は出力に含まれない——範囲を広げて評価する。§7.8）
2026-01-01
…
# ⚠ 範囲外 2026-01-01..2026-01-02（statutory covering 2026-01-01..2026-12-31）
# ⚠ 範囲外 2026-12-31..2027-01-01（statutory covering 2026-01-01..2026-12-31）

$ node impl/dist/cli.js next -n 3 impl/examples/payday.kairos
2026-11-25
2026-12-25
2027-01-25
# ⚠ 範囲外 2027-01-01..2027-01-26（holidays2026 covering 2026-01-01..2026-12-31）
# 被覆サマリ
#   holidays2026 covering 2026-01-01..2026-12-31 残走路 -25 日

--json でも "runwayDays": -25。payday の例は 2026 年の表しか持たないので、今日以降に走らせる限り next -n 3 の 3 点目は必ず表の外になる（2027-01-25 は祝日表の裏付けなしの値）。

影響: 「黙らない」という設計の長所が、初見には「サンプルが警告を出す」と映る。window-clip は例ファイルの先頭コメント（jp-holidays.kairos:4-5）に理由があるが、README を読んでコマンドを打つ人はそこを見ない。
直し方の案: クイックスタート直下に 3 行——「# ⚠ 範囲外 ＝祝日表の外側で計算した区間」「残走路 ＝表の残り日数。負は過ぎている」「警告: window-clip ＝範囲の端で外へ動いた点があった（範囲を 1 日広げれば消える）」。あわせて jp-holidays の推奨コマンドを --from 2025-12-31 にすると警告自体が出ない。

①-M2 README の hero 例を README どおりに CLI で走らせると、日付ではなく時刻付きで出る（`--tz` の案内が README に無い）

何が: README.md:18-26 の例は tz: "America/New_York"。CLI の既定は機械の tz（impl/README.md:37-38・llms.txt:90 に記述）なので、NY 以外の機械では日粒度の点が 2026-01-27T14:00 のように印字される。README.md のクイックスタート（149-180 行）には --tz が一度も出てこない。

再現:

$ node impl/dist/cli.js list readme-en.kairos --from 2026-01-01 --to 2026-07-01      # JST 機
2026-01-27T14:00
2026-02-24T14:00
2026-03-26T13:00
…
$ node impl/dist/cli.js list readme-en.kairos --from 2026-01-01 --to 2026-04-01 --tz America/New_York
2026-01-27
2026-02-24
2026-03-26

値そのものは正しい（1/31 土→1/30 金→3 営業日前 1/27）。

影響: 「3 business days before month-end」の答えとして T14:00 と T13:00（DST で 1 時間ずれる）が並ぶと、初見には誤りに見える。--json の dates も同じ表示（llms.txt:33「dates are one-to-one civil labels」）。
直し方の案: クイックスタートの最初のコマンドに --tz（「ラベルの tz。既定は機械の tz。定義の premise と違うと時刻付きになる」）を 1 行で。README.md:165 の前後に置くと英語読者に届く。

①-M3 レシピ本文の最初の `kairos` ブロックは、貼っても動かない（`@JP` の標準前提は doctest 専用）

何が: 各レシピの「Kairos で書く」節の最初のブロックは @JP だけで始まる（例: recipes/cron-last-day-of-month.md:28-33）。@JP の premise は doctest が自動で前置するもの（recipes/README.md:21-22 に記述）で、Playground・CLI・MCP には無い。ページ本文には「このブロック単体では動かない。下の Playground リンクが前提込み」という注意が無い（同ページ 26 行目は「@JP の標準前提（…）で:」とだけ言う）。
再現:
```
$ printf '@JP\nbizDay |> within(month) |> last\n' > jp-asis.kairos
$ node impl/dist/cli.js list jp-asis.kairos --from 2026-01-01 --to 2026-07-01
未定義の premise: @JP
EXIT=1
```
MCP kairos_validate（source @JP\nmonthEnd |> roll(on: bizDay)）→ 未定義の premise: @JP。一方、同ページ 111 行目の Playground リンク（#s=…&f=2026-01-01&t=2026-07-01）を base64 decode すると premise と祝日表込みの自己完結形で、CLI 実走は 2026-01-30 2026-02-27 2026-03-31 2026-04-30 2026-05-29 2026-06-30＝ブロックの #=> と一致。
影響: 英語版も同じ構造（en/recipes/cron-last-day-of-month.md）。MCP 経由で AI が本文のブロックをそのまま kairos_list に渡すと、この診断で止まる。
直し方の案: 各ページの最初の @JP ブロックの直前に 1 行——「@JP は doctest の標準前提。手で動かすときは下の Playground リンク（前提込み）を使う」。あるいはブロック内の 1 行コメント # @JP = 標準前提（Playground リンクに展開済み）。

①-M4 README（英）は付録 A を「(Japanese)」として日本語ページにリンクするが、英訳が存在する

何が: README.md:142-144 「The conformance profile for firing layers … is [spec appendix A（spec/60-firing-layer-profile.md） (Japanese).」。しかし en/spec/60-firing-layer-profile.md は存在し（ls en/spec/ で確認）、llms.txt:160 と en/spec/README.md はそちらにリンクしている。直後の付録 B（README.md:147）は英訳にリンクしており、付録 A だけが取り残されている。
再現: ls en/spec/ → 60-firing-layer-profile.md あり。curl https://kairos-lang.org/en/spec/60-firing-layer-profile は未検査だが、raw.githubusercontent.com の同ファイルは 200（公開 URL 表）。
直し方の案: README.md:144 を spec appendix A（en/spec/60-firing-layer-profile.md） (日本語（spec/60-firing-layer-profile.md）) に（付録 B と同じ形）。

①-M5 公開済み kairos-lang-mcp@1.0.12 の依存は `kairos-lang: ^1.0.11`、リポジトリ HEAD は `^1.0.12`

何が: mcp/README.md:116「The server’s version tracks kairos-lang (same number, same contract)」。しかし npm に公開された 1.0.12 の dependencies は kairos-lang: ^1.0.11。HEAD の mcp/package.json は ^1.0.12（公開後に更新された形）。
再現:
```
$ npm view kairos-lang-mcp dependencies
{ zod: '^4.0.0', 'kairos-lang': '^1.0.11', '@modelcontextprotocol/sdk': '^1.32.1' }
```
公開時刻は kairos-lang 1.0.12 が 00:07:06Z・mcp 1.0.12 が 00:12:15Z なので、新規に npx -y kairos-lang-mcp する限り 1.0.12 に解決する（実測: kairos_list の version は 1.0.12）。
影響: 実害は限定的（推測ではなく上記の実測）。ただし lock で kairos-lang 1.0.11 を固定した環境で mcp だけ 1.0.12 に上げると、1.0.12 の機能（results[].labels・next の window-clip 抑止）が無い評価器と組む余地が残る。「same number」の約束と公開物が一致していない。
直し方の案: 次版から公開前に mcp/package.json の依存を同版に揃える（CI で dependencies["kairos-lang"] == "^" + version を検査）。1.0.12 については mcp README に「1.0.12 の公開物は ^1.0.11。評価器の版は応答の version で確認できる」と 1 行。

LOW

①-L1 「reference CLI 1.0.5」「1.0.2」の実物引用は 1.0.12 でも同文だが、版の表記が古い

どこで: README.md:58「Three real ones from the reference CLI 1.0.5」・README.ja.md:102「参照実装 1.0.5 の実物を 3 本」・llms.txt:93「two real ones from the reference CLI 1.0.2」・llms.txt:106「1.0.5」。
再現（1.0.12 で 5 本とも一字一句一致）:
- monthEnd |> roll(on: bizDay) → roll は規約が必要（I3）——位置引数で Following/Preceding を書くか前文で roll: を宣言
- everyInstant |> strideBy(0s, from: 2026-01-01) → strideBy: 幅は正の量（0 幅は前進しない＝無限ループ。1s・1d のような正の幅を書く。ADR-38 判断 12）
- everyDay |> stride(0, from: 2026-01-05) → stride: n は 1 以上の整数（0 は不可。ADR-38 判断 12）
- monthEnd |> shift(-3, unit: bizDay) → shift: 点が軸上にない（先に roll で有効点へ寄せる）
- monthEnd |> roll(Preceding) → roll: 軸がない（on:/unit: を書くか前文で axis: を宣言。§3.3 は宣言必須）
補足（llms.txt:97-100）: 5 本目の引用文は「軸を書かなかった」場合のもの。同じ段落の「a misspelt named argument (axis: for on:) is rejected」は別の診断になる——monthEnd |> roll(Preceding, axis: bizDay) → roll: 未知の名前付き引数 axis:（黙って捨てない——ADR-39）。読者が axis: で再現すると引用と違う文が出る。
直し方の案: 「1.0.5 以降同文（1.0.12 で確認）」とするか版を外す。llms.txt は「Raised by roll(Preceding) with no axis; a misspelt axis: gets roll: 未知の名前付き引数 axis:…」に分ける。

①-L2 npm 配布の CLI でも `--help` の 1 行目が「kairos ＝ node src/cli.ts」・例ファイルの実行コメントも開発路

再現: node impl/dist/cli.js --help → 使い方（kairos ＝ node src/cli.ts）:、--help --lang en → Usage (kairos = node src/cli.ts):。npx kairos-lang --help の利用者は src/cli.ts を持たない。impl/examples/payday.kairos:2・jp-holidays.kairos:2 の # 実行: node src/cli.ts examples/… も同じ。
直し方の案: 「kairos（npm）／node src/cli.ts（開発）」と併記。例ファイルのコメントは kairos list impl/examples/payday.kairos … を先に。

①-L3 npm の kairos-lang@1.0.12 の README はテスト数 862、リポジトリ HEAD は 880

再現: npm pack kairos-lang@1.0.12 → package/README.md:234「39 ファイル・862 本」。HEAD の impl/README.md:234 は 880。差分はこの 1 行だけ（diff で確認）。README.md／README.ja.md／llms.txt／en/spec/README.md の 880 は実測と一致している。
影響: npm のページを読む人と GitHub を読む人で数字が違う。公開後に doctest（記述スキル 17 本＋1 本）が増えた結果で、誤りではない。
直し方の案: 記録のみ。次版で揃う。公開日の文書同期で impl/README のテスト数を触るなら、npm 側は版を切るまで旧値であることを runbook に 1 行。

①-L4 `playground/` に README が無く、GitHub 上でレシピの Playground リンクを踏むとソース一覧になる

どこで: recipes/README.md:24 Playground（../playground/）・en/recipes/README.md:34。サイト（kairos-lang.org）では index.html が出るが、GitHub のファイル閲覧では app.js core.js index.html js/ の一覧。
直し方の案: playground/README.md を 2 行（「公開 URL は https://kairos-lang.org/playground/ ・en は /en/playground/ 」）置く。README.md:151 のように絶対 URL にしてもよい。

①-L5 Windows 単体 exe（Release 資産）が README の導入節に無い

どこで: README.md:149-176・README.ja.md:58-88 の導入は npm と TypeScript 直実行の 2 経路のみ。kairos-1.0.12-win-x64.zip（Release v1.0.12 の資産・SHA256 付き）への案内は recipes/windows-admin.md:15-17 だけ。
影響: Node.js を入れられない Windows 利用者は README から exe に辿り着けない（Release ページを自分で開く必要がある）。
直し方の案: クイックスタートに「Windows（Node 不要）: Release の kairos-<版>-win-x64.zip → Windows 管理者のための Kairos（recipes/windows-admin.md）」を 1 行。

良かった点

数字が揃っている: テスト数 880 は README 日英・llms.txt・impl/README・en/spec/README の 5 か所と実測が一致し、typecheck も通る。ADR 数 53 も 3 か所と実数が一致。
リンクが切れていない: 導線上の 29 ファイル・相対リンク 261 本に欠損なし。公開 URL 29 本＋追加 12 本がすべて 200。Release の latest は v1.0.12 を指し、資産に sha256 が添えてある。
版が一本に揃っている: Playground の配信中 IMPL_VERSION・npx kairos-lang --version・npx kairos-lang-mcp --version・MCP の serverInfo・CliReport.version・検定 README の「参照実装 1.0.12・2026-10-26 追従」がすべて 1.0.12。
レシピの Playground リンクは自己完結で、本文の期待値と一致する: リンクを decode して CLI で走らせた結果が #=> の 6 点と一致した。doctest で検証しているという主張が外からも確かめられる。
診断文の引用が実物と一致する: README・llms.txt に引用された 5 本の診断文は 1.0.12 で一字一句再現した。「誤った日付ではなくエラーが出る」という主張は、そのとおりに動く。
MCP の tz 必須が入力検証で守られている: tz を省くと評価に入る前に Invalid arguments … expected string, received undefined at tz で止まる。README の「tz is required」が実装で担保されている。

観点② 1.0.12 の新しい面の実走検証

対象: 公開リポジトリ azathothx/kairos-lang HEAD 43e3734（impl/dist/cli.js --version → 1.0.12）。レビュー日 2026-10-26。全スイートは走らせず、同梱例（impl/examples/*.kairos）と文書の doctest を CLI で個別に実走した。比較対照として npm registry の kairos-lang@1.0.11（npm pack で取得・依存ゼロなのでそのまま node package/dist/cli.js）を同じ入力で走らせ、「変わらないもの」の主張を差分で確かめた。以下、コマンドはすべて clone のルートで node impl/dist/cli.js … の形（impl/examples/ の例を examples/… と略記）。

実測サマリ

項目	CHANGELOG の主張（spec/CHANGELOG.md 追補 29）	実測	判定
(a) `--json` `results[].labels`	ラベル付き束縛がちょうど 1 つのとき `dates` と同長・`string \\| null`・添えないときは鍵ごと無い（L792-797）	`examples/rokuyo.kairos` 3 式とも `labels` あり（12 件・13 件・61 件、`null` 0）。`payday`・`jp-holidays` は鍵なし。`shift(+1, unit: day)` 後は全点 `null`。表 2 つの参照で鍵なし。`next -n 2` では 2 件に切り詰め。schema（ajv draft 2020-12）に 5 本の実物が通り、ラベルを数値に変異させると通らない	一致
(a) `--tsv` 8 列目 `label`	見出しに `label`・無ければ空（L798）	見出し `expr source uid date time epoch_ms note label`。`rokuyo` の式 1 は `12`・`1`・`2`…（impl/README.md:119 のとおり）。`payday` は空。`--lang en` でも行は同一。1.0.11 の 7 列と先頭 7 列が全行一致（3 例）	一致
(a) `.ics` の題	1 点 1 予定で「名前 · ラベル」・`UID` 不変・series は名前のまま（L799）	1 式のファイルで `SUMMARY:二十四節気（抜粋） · 小寒`、時刻付き（`--tz UTC`）では `VALARM` の `DESCRIPTION` も同じ題。series は名前のみ。`UID` 集合は 1.0.11 と一致（jp-holidays 20・payday 13・rokuyo 86）。ただし式が複数のファイルでは「名前 · 式 · ラベル」（②-M2）	ほぼ一致（文書の抜け）
(a) `external` のラベル	`external` の `labels:` も数える（L792）	`--supply` で `labels` を渡すと `--json`／`--tsv`／`.ics` にラベルが乗る（`小寒大寒立春雨水`）	一致
(b) 範囲外シグナルの構築	`Error.stackTraceLimit` を一時的に 0 にし必ず戻す・出力不変（L760-769）	ライブラリ API で `stackTraceLimit=7`／`3` を設定して評価 → 評価後も 7／3。`jp-holidays` 2026-01〜2028-01 の点・註釈・警告は 1.0.11 と一致。参考: `bizDay \\|> at(T09:00)` 1 年は 1.0.11 1,257 ms → 1.0.12 664 ms（プロセス起動込み・3 回の最小）	一致
(c) `next` の `window-clip` 抑止	確定再評価では報告しない・`list` は従来どおり・地平線不足のときは従来どおり（L771-775）	`next --from 2026-10-26 examples/jp-holidays.kairos` → `warnings: []`（1.0.11 は `window-clip: shift(1) 2026-11-03 → 2026-11-04` を出す）。同じ範囲の `list --to 2026-11-04` は 1.0.12 でも出す。点・`to`・残走路は両版で同一。`everyDay \\|> shift(+1, unit: day)` を `next -n 400 --horizon 1` すると不足（365 件）で `window-clip` が出る	一致
(d) 註釈だけの `.ics`	点 0・註釈ありなら註釈の予定だけ・終了コード 0・stderr の知らせ（日英）・点も註釈も 0 なら書かず 2（L779-786）	`list --ics --from 2026-12-01 --to 2027-02-01 examples/jp-holidays.kairos` → `VEVENT` 1 件（`20261231`〜`20270201`・`TRANSP:TRANSPARENT`）・exit 0・stderr「⚠ 点 0（[2026-12-01, 2027-02-01) に点がない）・範囲外の註釈 1 件＝註釈の予定だけを書く」。`--lang en`／`--ics-series` も同じ。`payday` の `--from 2026-03-02 --to 2026-03-03` は何も書かず exit 2。1.0.11 は同じ入力で exit 2・0 バイト	一致
(e) 残走路の起点	covering `..2026-12-31` を `to` 2027-02-01 で評価すると −31（L811）	`coverage[0].runwayDays: -31`。A.4 の註（spec/60:139）・用語集（spec/50:28・en 38）・A.9 の表（spec/60:280）に同じ 1 文	一致
(e) asof 欠落の 2 文言	`--supply` の形の検査＝「asof（文字列）が必須」／評価器＝「契約違反: asof がない——external …」・どちらも `kind: supply`（L813）	asof 無し → `--supply … の "holidays": asof（文字列）が必須`、asof `" "` → `契約違反: asof がない——external HRDB.holidays（…ADR-46）`。どちらも `error.kind: "supply"`・exit 1	一致
(e) 12-31 開始の機序	`reference/shift.md` の落とし穴と `jp-holidays` の頭註（L812）	shift.md:65-66・jp-holidays.kairos:4-5 に記載。実走の註釈は `2026-12-31..2027-02-01`	一致
文書の doctest（機械抜き取り）	各ページの例は実行検証済み（reference/README.md:7）	自作の抜き取り器で `# eval:` ブロックを `.kairos` に書き出し、`list --json --from --to [--tz] [--supply]` と人間表示の両方で照合。reference 66／66・stdlib 28／28・recipes 37／37・skills/kairos-authoring 18／18＝149 ブロック全一致（`#=>` の点列・`#~>` の註釈と警告・人間表示の行）	一致

未検証（この clone では確かめられないもの）: MCP（kairos_list／kairos_next）の labels（mcp/ は未ビルドで npm の kairos-lang ^1.0.12 に依存）、Playground の buildIcs（ブラウザ）、--tsv の label 列のタブ無害化（言語のラベルはタブを含めないので CLI から作れない）。

所見

HIGH はなし。

②-M1 「本体式が参照するラベル付き束縛」の数え方は字面の直接参照であり、中間束縛を経由すると付かない——文書に書かれていない

何が: ラベルを添える規則を CHANGELOG（spec/CHANGELOG.md:792「本体式が参照するラベル付き束縛…がちょうど 1 つのとき」）・impl/README.md:51・schema/cli-report.schema.json:172（”refers to exactly one labelled binding”）・--help（impl/src/cli.ts:359・386）はすべて「参照する」と書く。実装は本体式の字面に直接現れる自由名だけを数え（impl/src/eval.ts:777「参照は字面（本体式の自由名）で数える」）、各名前の評価値がラベル付きかで判定する。結果、同じ集合を表す式でも書き方でラベルの有無が変わる。

再現（work/lab-multi.kairos＝表 sekki〈labels: 付き〉・sekki2・spring = sekki |> filter(…)・wed = everyDay |> filter(d => weekday(d) == Wed) を定義し 9 式を評価。list --json --from 2026-01-01 --to 2026-04-01）:

sekki |> filter(s => sekki(s) == 立春 or sekki(s) == 春分) | n=2 | labels=["立春","春分"]
spring                                                    | n=2 | labels=(none)     ← 同じ式を束縛名にしただけ
everyDay |> filter(d => weekday(d) == Wed)                | n=12 | labels=["Wed",…]
wed                                                       | n=12 | labels=(none)
sekki |> filter(s => weekday(s) == Mon)                   | n=1 | labels=(none)     ← 表＋cycle＝2 つ
sekki & wed                                               | n=1 | labels=["立春"]   ← 同じ集合だが wed 経由なので 1 つ

影響: 式を整理して名前を付けた途端に --json の鍵が消え、--tsv の label 列が空になる。点は正しいので誤った日付には至らないが、ラベル列を読む取り込み（Excel・PowerShell）や --json の消費側が黙って壊れる。witness（CHANGELOG:821）は「2 束縛参照で無し」までで、中間束縛の経路は書かれていない。
直し方の案: 文書 4 箇所（CHANGELOG・impl/README --json／--tsv 節・schema の description・--help 日英）に 1 文——「数えるのは本体式の字面に直接現れる名前。中間の束縛（spring = sekki |> filter(…) の spring）は、その値が表・cycle・ラベル付き窓列でなければ数えない＝ラベルが要るなら本体式に表の名前を直接書く」。あわせて result-labels.test.ts に中間束縛の 1 本を足す。規則そのものの是非は論じない。

②-M2 `.ics` の題は式が複数のファイルでは「名前 · 式 · ラベル」になる——README の `--ics` 節は「名前 · ラベル」としか書かない

何が: impl/README.md:68「予定の名前（SUMMARY）は定義の先頭コメント行（# …）→ファイル名の順」・:69「SUMMARY（と通知の文）が『名前 · ラベル』になる」。実装は本体式が複数なら名前に「 · 式の字面」を足す（impl/src/ics.ts:24 のコメント・:138 many ? \${title} · ${srcLine}` : title）。この「· 式」は README・CHANGELOG・–help のどこにも書かれていない（grep「式が複数」「名前 · 式」で 0 件）。README がラベル列の例に使う同梱例 rokuyo.kairos`（3 式）がまさにこの形になる。
再現: list --ics --from 2026-01-01 --to 2026-04-01 examples/rokuyo.kairos（75 オクテット折り返しを戻した SUMMARY）:
```
SUMMARY:旧暦と六曜: 朔データで月を切り、(月番号 + 日番号) mod 6 で六曜を出す（stdlib/kyureki.md） · lunarMonth |> first · 12
```
1 式のファイル（work/lab-single.kairos）では SUMMARY:二十四節気（抜粋） · 小寒 で文書どおり。1.0.11 との差分は rokuyo の 86 予定すべてが … · lunarMonth |> first → … · lunarMonth |> first · 12 の形（UID は全件一致）。
直し方の案: README --ics 節の「予定の名前」の行に「本体式が複数なら『名前 · 式』」を足し、ラベルの行を「（式が複数なら『名前 · 式 · ラベル』）」とする。CHANGELOG:799 も同様。カレンダーの題が長くなる点（rokuyo は 60 字超＋式＋ラベル）は 1.1 の論点として 90-open に置くのがよい（判断は設計者）。

②-M3 Excel 対照レシピは `label` 列を「ラベル付きの表（`labels:`）を 1 つ参照するとき」と書くが、`cycle` も数える

何が: recipes/excel-workday.md:180-181「label（1.0.12 から）は、式がラベル付きの表（labels:）を 1 つ参照するときにその点のラベル（節気名など）が入る列」・en/recipes/excel-workday.md:211-212 “when the expression refers to exactly one labelled table (labels:)”。CHANGELOG:804「cycle（weekday など）は数える」・--help「labels:／cycle」と食い違う。レシピの読者（Excel・PowerShell の利用者）は「毎週金曜」の定義で label 列が Fri で埋まる理由を文書から読めない。
再現: work/lab-multi.kairos 式 6 everyDay |> filter(d => weekday(d) == Wed) → --tsv の label 列が全行 Wed（上の ②-M1 の出力 6 行目）。reference の doctest でも roll.md#2（Wed）・stride.md#2（Mon×4）・cycle.md#1（午）が labels を持つ（抜き取り器の記録 work/doctest-reference.json）。
直し方の案: レシピ日英の 1 文を「ラベル付きの束縛（labels: 付きの表・weekday などの cycle）を 1 つ参照するとき」に揃える。design/90-open-questions.md:41 は「cycle を数える規則は用途を見て 1.1 で再考」と書いているので、再考までの間は文書を実物に合わせるのが筋。

②-L1 `.ics` の `X-KAIROS-LABEL` は市民日のラベルで、1.0.12 の「ラベル」（結果の出口のラベル）と語が衝突する

何が: 1 予定の中に SUMMARY:… · 小寒（結果のラベル）と X-KAIROS-LABEL:2026-01-04T15:00（表示ラベル＝dates の値・impl/src/ics.ts:167・186）が並ぶ。X-KAIROS-* 属性は impl/README.md に説明がない（grep 0 件）。取り込み側の実装者が X-KAIROS-LABEL を「ラベル」と読み違える余地がある。
再現: list --ics --tz UTC --from 2026-01-01 --to 2026-04-01 work/lab-single.kairos の最初の VEVENT（SUMMARY:二十四節気（抜粋） · 小寒 / X-KAIROS-LABEL:2026-01-04T15:00）。
直し方の案: 互換のため属性名は変えず、README の --ics 節に X-KAIROS-POINT（epoch ms）・X-KAIROS-LABEL（市民日の表示ラベル＝dates・結果のラベルではない）・X-KAIROS-VERSION／TZ／RANGE／SOURCE の 1 行ずつを足す。

②-L2 地平線不足の `next` に残る `window-clip` の助言「範囲を広げて評価する」は、`next` では `--horizon` を指す

何が: CHANGELOG:773 自身が「助言『範囲を広げて評価する』は next では実行できない」と書いて確定再評価の分だけ抑止した。地平線まで探して不足のときは従来どおり出す（:775）ので、next の利用者がこの助言を見る場面は残る。そこでの「範囲」は --horizon のこと。
再現: next -n 400 --horizon 1 --from 2026-01-01 work/shift-next.kairos（everyDay |> shift(+1, unit: day)）→ 警告: window-clip: shift(1) 2026-12-31 → 2027-01-01（評価範囲 [from, to) の外へ動いた点は出力に含まれない——範囲を広げて評価する。§7.8） と ⚠ 地平線 1 年以内の発火は 365 件（要求 400 件）・exit 2。
直し方の案: 文言は変えず（witness が文言で固定されている）、impl/README.md の next の箇条書きに「地平線不足で window-clip が出たときの『範囲を広げる』は --horizon」の 1 文を足す。

良かった点

文書の例が本当に動く: reference・stdlib・recipes・記述スキルの # eval: ブロック 149 本を、テストスイートではなく CLI（--json と人間表示の両方・# resolve: は --supply の JSON に変換）で機械的に再現して全件一致した。#~> の無いブロックが「註釈ゼロ・警告ゼロ」の主張として実際に成り立っていることも確かめられた。
「変わらないもの」の主張が差分で裏づく: 1.0.11 と 1.0.12 で同梱例 3 本の --json（labels 以外）・--tsv の先頭 7 列・.ics の UID 集合・--ics-series（版表記 2 行以外）が一致した。出口だけが変わったという追補 29 の中心の主張は実物で成立している。
Schema が実物を受け、変異を弾く: 公開 schema（draft 2020-12）に labels あり／なし・next・註釈だけの報告の 5 本が通り、ラベルを数値にした変異は弾かれた。
退行の再現が同梱例でできる: next --from 2026-10-26 examples/jp-holidays.kairos の 1 本で、1.0.11 の不要な window-clip と 1.0.12 の抑止、点・to・残走路の不変を第三者が確かめられる。

作業ファイル（clone 外・参照用）: 抜き取り器 …/scratchpad/review14/work/doctest-run.mjs・結果 work/doctest-*.json・版間比較 work/compare-1011.mjs・検証用定義 work/lab-single.kairos・work/lab-multi.kairos・work/shift-next.kairos・scratch-ext/ext2.kairos＋supply2.json。

観点③ 仕様の内部矛盾

対象: azathothx/kairos-lang HEAD 43e3734（版 1.0.12）。レビュー日 2026-10-26。
読んだ範囲: spec/00〜90・spec/60（付録 A）・spec/61（付録 B）・spec/CHANGELOG.md（追補 22・23・28・29）・reference/ 全 32 ページ・stdlib/ 5 ページ・impl/README.md・schema/cli-report.schema.json・CLI --help。入口（README.ja.md／README.md／llms.txt／mcp/README*／recipes/windows-admin.md）は終了コードと警告の記述だけ grep で突き合わせた。
方法: 同じ語の説明を文書間で突き合わせ、食い違いの候補は node impl/dist/cli.js で実物を走らせて確かめた。再現は前文 premise TSE { calendar-system: Gregorian; tz: "Asia/Tokyo"; source: "example"; satSun = everyDay |> filter(d => weekday(d) == Sat or weekday(d) == Sun); holidays = [2026-01-01, 2026-01-12, …, 2026-11-23] covering: 2026..2026; nonWorking = satSun | holidays }＋premise JP { calendar-system: Gregorian; calendar: TSE; tz: "Asia/Tokyo"; wkst: Mon }＋@JP の下に本体式を置き、list --tz Asia/Tokyo で評価した（以下「標準前文」）。全スイートは走らせていない。

実測サマリ

語	突き合わせた文書	実測	判定
ラベル（`labels:` テーブル／`labels:` 窓列／`label:` ラムダ／`cycle`／束縛名射影 `B(d)`）	spec §3.8（20:309-313）・§4.2（30:50-64）・§4.9（30:339-379）、用語集 6.5（50:141-142）、reference/table-literal・segmentBy・cycle、stdlib/gregorian §1-2・kyureki §1、impl/README `--json` の `labels`（impl/README:51）、schema	射影の意味論は一致（`lunarMonth(1)`・`sekki(s)`・`weekday(d)`）。出口 `labels` は式の字面に名前が現れる束縛だけを数える（a2・a4・a9 は付く／q1・s1・s2・a7・a8・q3・q4 は付かない）。`labels:` 窓の域外値引数は静的エラー（p1・p2）、`month(2020)`・`month(13)`・`year(99999)` は黙って 0 点（g3〜g5・p4）	③-H1・③-M3
評価註釈（範囲外）	spec §4.10、reference/README 正準一行形（:67-68）、付録 B B.6	`# ⚠ 範囲外 2028-01-01..2028-02-01（JP.holidays covering 2026-01-01..2027-12-31, asof 2026-10-22）`＝B.6 (3) の期待字面と一致。takeLast の頭側註釈も範囲が頭を含めば出る（r2）	一致
被覆サマリ・残走路	spec §4.10（30:469-473）、用語集（50:28）、付録 A A.4（60:139）・A.9（60:280）、付録 B B.2（61:83）・B.6・B.9（61:229）	covering `..2027-12-31`／to 2028-01-01 → `残走路 0 日`、to 2028-02-01 → `-31 日`、covering `..2026-01-31`／to 2026-03-01 → `-28 日`、`..2026-12-31`／to 2026-03-01 → `306 日`（排他端起点）	数値は一致。B.2／B.9 の言い回しだけ ③-L3
`window-clip`／`horizon-clip`	spec §7.8（90:178-181）、付録 A A.4（60:162-164）、impl/README:42・223、CHANGELOG 追補 22（:559-563）・29（:771-777）、reference/roll:72-73・shift:68-69・snapTo:61-62・takeLast:54-55	`list`: `警告: window-clip: roll(Preceding) 2026-02-01 → 2026-01-30（…§7.8）`。同じ式の `next` では出ない。`takeLast` の下限側 `horizon-clip: takeLast 1970-01-02（実体化下限で切れ——n=3 個中 2 個のみ…）`、上限側は件数なし	一致。文言の範囲だけ ③-L5
終了コード 0／1／2	impl/README:44・55・72-73・98、`--help` 末尾、付録 B B.6（61:145・154・167-180）、mcp/README:50・README.ja:56、recipes/windows-admin:86・216、llms.txt:44	静的エラー→1（`--json` は `error.kind: static`）、契約違反 3 種→1（`kind: supply`、診断冒頭は B.6 の表と一字一致）、`next -n 3 --horizon 1` 不足→2（`found: 1`）、`--ics` 点 0・註釈 0→2、点 0・註釈 1→`VEVENT` 2 行で 0、`list`／`--tsv` の 0 点→0	一致
`at` の検査（引数・窓付き入力）	spec §5.5（40:155-161）、用語集（50:136-137）、reference/at:3・47-53・79-80、stdlib/gregorian:37-38・99	`at(2026-01-01T17:00)`→静的エラー（誘導つき）、`within(month) \\|> at(T07:00)`→静的エラー（誘導つき）、`at(T07:30:15.250)`→受理、`.2505`→字句エラー、`T07:3`→誘導つき字句エラー、`T07:300`→構文エラー（誘導なし）、`T7:30`→`at: 引数が不足`	一致。字句の形の記述ゆれ ③-L1・誘導の範囲 ③-L2
`take`／`takeLast`	spec §4.7（30:215-239）・§5.2（40:51-55）、用語集（50:105-106・134-135）、reference/take・takeLast	窓付き入力→静的エラー（take・takeLast とも誘導つき）、`takeLast(…, from:)`→専用診断、`take(0)`→静的エラー、`takeLast` 覆域内は註釈なし（r2）	一致
`within`／`nth`／`first`	spec §4.3（30:74-79）・I4、用語集 6.4（50:90）、reference/within:34・45-47・nth:7-12・49・first:8	入れ子は常に最内窓（`within(quarter) \\|> within(month) \\|> nth(2)`→各月 2 日、逆順→四半期の 2 日目、within→segmentBy も最内）。`of: year` が連鎖に無い→`of: year に該当する窓がない`。`nth(0)`→静的エラー。`everyDay \\|> first`→I4 型エラー。`wkst` 未宣言の `within(week)`→`未解決の名前: wkst`	「曖昧＝静的エラー」の実現形なし ③-M1・`I15` ③-M4
`roll(Modified)`／`epoch:`	spec §4.4（30:95）・§5.2（40:40）・§3.6（20:190-193）・§5.3（40:66）、用語集（50:70・149）、reference/roll:20・epochOrdinal:11-12、stdlib/gregorian:55-56、impl/README:213・230	`roll(Modified, on: bizDay)`→`Modified は未実装（プロトタイプ）`、`epoch: 2000-01-06`→`プロトタイプは既定紀元（1970-01-01）のみ対応`	③-M2・③-L8
`coincides` の S に窓語	spec §4.9（30:316）、reference/coincides:13-16・119	`coincides(month, day, d)`→静的エラー（誘導つき）	一致

HIGH

③-H1 窓インスタンス参照の「域外の値引数は静的エラー」の例 `month(2020)` が、実物では黙って空になる

どこで: spec/30-body-layer.md:357-358「ただし labels: リテラル等でラベル値域が静的に列挙できる束縛では域外の値引数は静的エラー（month(2020) 級のタイポが黙って空になるのを封じる。計算ラベルは「該当なし＝空」）」。spec/50-glossary.md:98「静的列挙可能なラベル値域の域外は静的エラー」。同じ §4.9 の 30:362-364 は「標準 premise では year・month（Gregorian）…が標準ラベルを持つ」と書き、stdlib/gregorian.md:24-25 の完全定義では month／year のラベルは label: (p => monthNo(p))／label: (p => yearNo(p))＝計算ラベルである。

再現（標準前文・--from 2026-01-01 --to 2026-04-01）:

month(2020)            → # 0 点（[2026-01-01, 2026-04-01) に該当なし）   exit 0
month(13)              → # 0 点（…）                                   exit 0
year(99999)            → # 0 点（…）                                   exit 0
Gregorian.month(2020)  → # 0 点（…）                                   exit 0

一方 labels: リテラルの窓列では規則どおり止まる:

newMoons = [2026-01-19, 2026-02-17, 2026-03-19, 2026-04-17] covering: 2026-01-19..2026-04-30
lunarMonth = everyDay |> segmentBy(newMoons, edges: drop, empties: error, labels: [12, 1, 2, 3])
lunarMonth(99)
→ 窓束縛 lunarMonth(99): ラベル値域（labels: リテラル）の外——域外の値引数は静的エラー（タイポが「註釈なしの空」で流れるのを封じる。ADR-42 判断 7 (g)。計算ラベル〈label: 式〉は列挙不能なので該当なし＝空）   exit 1

何が食い違うか: 仕様が「封じる」と言って挙げた例（month(2020)）は、仕様自身の但し書き（計算ラベルは空）と参照実装の診断文の両方で「封じない」側に分類される。読み手は month(13) のタイポが静的エラーで止まると期待するが、実物は註釈なしの 0 点で通る。規則の本体（labels: リテラルの窓）は実物と一致しているので、誤っているのは例示と「標準ラベル」の説明の接続。
直し方（文書側）: §4.9 の例を labels: 窓のもの（lunarMonth(13)・kyuMonth("十三月") 級）に差し替え、続けて 1 文「標準の month／year のラベルは label: 式（計算ラベル）なので値域は列挙されず、month(13) は静的エラーにならず空になる」を置く。用語集 6.4「窓インスタンス参照」の行と stdlib/gregorian.md §2（:94-95・102-104 の month(5)／year(2026) の説明）にも同じ一文を添える。標準 month／year を列挙可能として守る意図なら、それは実装側の論点であり本観点の外（ADR-42 判断 7 (g) の射程の判断になる）。

MEDIUM

③-M1 §4.3「曖昧なまま `of:` を省くのは静的エラー」に対応する形が無く、他の文書は「既定は最内窓」としか書かない

どこで: spec/30-body-layer.md:76-79「既定で最内窓（直近の within/segmentBy）に束縛される。入れ子で対象が曖昧なときのみ of: w で窓を明示する。…窓なしの選択子は型エラー（I4）、曖昧なまま of: を省くのは静的エラー」。reference/within.md:34「入れ子にすると選択子は既定で最内窓に束縛される。曖昧なら of: で明示する」、reference/nth.md:7-8・first.md:8、spec/50-glossary.md:90「既定は最内窓、of: で明示」。

再現（標準前文・--from 2026-01-01 --to 2026-04-01）:

everyDay |> within(quarter) |> within(month) |> nth(2)   → 2026-01-02 2026-02-02 2026-03-02   exit 0
everyDay |> within(month) |> within(quarter) |> nth(2)   → 2026-01-02                         exit 0
everyDay |> within(month) |> segmentBy((everyDay |> filter(d => weekday(d) == Mon)), edges: clip, empties: error) |> first
                                                          → 2026-01-05 2026-01-12 2026-01-19 2026-01-26   exit 0
everyDay |> within(month) |> nth(2, of: year)             → of: year に該当する窓がない           exit 1

何が食い違うか: 「既定は最内窓」が常に成り立つなら「曖昧」な状態は構造上生じない。実物も入れ子の順を問わず最内窓に束縛して受理し、of: に関する静的エラーは「名指した窓が連鎖に無い」の一種だけ。仕様のこの一文はどの形を指すのか定義されておらず、reference・用語集にも対応物が無い。
直し方: 30:78-79 の「曖昧なまま of: を省くのは静的エラー」を削るか、「of: で名指した窓が入れ子の連鎖に無いときは静的エラー（of: year に該当する窓がない）」に置き換える。within.md／nth.md の落とし穴にも同じ 1 行を足すと、唯一の of: 診断が引ける。

③-M2 `Modified` ロール規約は spec・reference で通常の規約として説明され、参照実装では未実装——reference/roll.md に注記が無い

どこで: spec/30-body-layer.md:95「Modified は上位窓を引数に取り、その窓内に留める」、spec/40-grammar.md:40、spec/50-glossary.md:149、reference/roll.md:16-20（規約表に Modified を並記・注記なし）。対して impl/README.md:213「未実装: Modified ロール」、README.ja.md:125-126「Modified ロール規約と everyInstant の一般合成は未実装（impl/README）」。
再現（標準前文）: monthEnd |> roll(Modified, on: bizDay) → Modified は未実装（プロトタイプ）、exit 1。
何が食い違うか: 記述語リファレンス（本書は「解説層」で例は実行検証済みと reference/README.md:7 が謳う）だけが未実装の事実を持たない。入口の README には書いてあるので実害は小さいが、roll.md から入った読者は書いてから知る。あわせて診断文と impl/README.md:1・:203 は「プロトタイプ」、spec/README.md:36・付録 A・B・README.ja.md は「参照実装／リファレンス実装」と呼び名が割れている。
直し方: reference/roll.md の規約表の Modified 行末に「（参照実装 1.0.12 では未実装＝impl/README）」、spec §4.4 の同箇所に脚注 1 つ。呼び名は「参照実装」に揃える（診断文の「（プロトタイプ）」も同じ）。

③-M3 出口のラベル `labels` の「本体式が参照するラベル付き束縛」の「参照」の範囲が未定義——字面に現れる名前だけを数える

どこで: impl/README.md:51「本体式が参照するラベル付き束縛（external／テーブルリテラルの labels:・cycle・segmentBy の labels:）がちょうど 1 つのとき、各点にその束縛の射影 B(d) のラベルを添える」。spec/CHANGELOG.md:792-793・:804、schema/cli-report.schema.json の $defs.result.properties.labels.description（”refers to exactly one labelled binding”）、--help の --tsv 行も同じ言い回し。

再現（標準前文・--json・--from 2026-01-01 --to 2026-03-01。hasLabels＝results[0] に labels 鍵があるか）:

everyDay |> filter(d => weekday(d) == Mon) |> shift(+1, unit: day)        → labels ["Tue", …]        （字面に weekday）
x = everyDay |> filter(d => weekday(d) == Mon)
x |> shift(+1, unit: day)                                                 → labels 無し              （同じ外延。weekday は x の右辺）
isMon = d => weekday(d) == Mon
everyDay |> filter(d => isMon(d))                                         → labels 無し              （値関数の中）
lunarMonth = everyDay |> segmentBy(newMoons, …, labels: [12, 1, 2, 3])
lunarMonth |> first                                                       → labels ["12", "1", "2"]  （字面に lunarMonth）
lunarDayNo = d => ordinalIn(day, lunarMonth, d)
everyDay |> filter(d => lunarDayNo(d) == 1)                               → labels 無し              （lunarMonth は値関数の中）
bizDay |> within(month) |> last                                           → labels 無し              （TSE.satSun の weekday は辿らない）
everyDay |> within(month) |> first                                        → labels 無し              （month は label: 式＝計算ラベル）

何が食い違うか: 「参照する」を「式が依存する束縛」と読むと q1／s1／s2 にもラベルが付くはずだが、実物は本体式の字面に現れる束縛名だけを数え、束縛の右辺・値関数の中・カレンダー実体・標準導出は辿らない。同じ外延の 2 式で --tsv の label 列と .ics の SUMMARY が変わる。label:（計算ラベル）の窓を数えない規則は CHANGELOG（:804）にだけあり、impl/README の --json 節と schema には無い。
直し方: impl/README:51 と schema の説明を「本体式の字面に現れるラベル付き束縛名（external／テーブルの labels:・cycle・segmentBy の labels:）がちょうど 1 つのとき。束縛の右辺・値関数の内側・calendar: の実体・bizDay 標準導出は辿らない。label: 式（計算ラベル。標準の month／year を含む）は数えない」に書き換える。--help の --tsv 行にも「字面に」を 1 語足す。

③-M4 `reference/nth.md:37` の「正当な空（I15）」——仕様の不変条件は I1〜I8 までで I15 は存在しない

どこで: reference/nth.md:37「営業日が N 日に満たない月は正当な空（I15）＝filter 型と同じ縁ケース保証が選択子で立つ」。不変条件の一覧は spec/10-types.md §2.6（I1〜I8）と spec/50-glossary.md:152-163 §6.7（I1〜I8）。I15 の字句は公開ツリーでは design/40-examples/90-findings.md:365（F102 の回答欄）にしか現れない。同じ nth.md の :12 は同じ事実を「空は正当・ADR-15」と書いている。
何が食い違うか: 仕様に無い番号を引いており、読者は辿れない。意味は ADR-15（空は正当な値）の取り違えと推測する（推測）。
直し方: 「（I15）」→「（空は正当＝ADR-15）」。first.md:10 と同じ書き方に揃う。

LOW

③-L1 単独時刻リテラルの形の記述が 3 通り

spec/40-grammar.md:155「Thh:mm(:ss(.f+)?)?」、spec/50-glossary.md:137「Thh:mm(:ss)?」、reference/at.md:3「a は単独時刻リテラル Thh:mm」、stdlib/gregorian.md:37「a は単独時刻リテラル Thh:mm」。
実測: everyDay |> at(T07:30:15.250) → 2026-01-01T07:30:15.250 …（受理）、T07:30:15.2505 → 字句エラー（秒の小数は 3 桁まで）。§5.5 が正。
直し方: 用語集と at.md／gregorian.md を「Thh:mm(:ss(.fff)?)?（§5.5）」に揃える。

③-L2 不正形の時刻字句の「誘導つき」の範囲

spec/40-grammar.md:161「T\d\d: に続く不正形は誘導つき字句エラー（黙って識別子に落とさない）」、reference/at.md:47「他は誘導つき静的エラー」。
実測: at(T07:3) → 字句エラー(11:16): 単独時刻リテラルの形は Thh:mm（例 T07:00・秒まで書くなら Thh:mm:ss。ADR-51）（誘導あり）。at(T07:300) → 構文エラー(11:22): ) を期待（'0' の位置）（T07:30 を切り出した残りの 0 で止まり誘導なし）。at(T7:30) → at: 引数が不足（T7 が識別子＝named-arg の鍵に落ちる）。
直し方: at.md の落とし穴に「誘導が出るのは T\d\d: 形の崩れだけ。T7:30 は識別子に読まれ at: 引数が不足 になる」を 1 行。字句側で T\d: も捕まえるなら §5.5 の規定を広げる（実装の論点）。

③-L3 残走路の定義の言い回し（付録 B）が、付録 A が「1 日ずれる」と戒めた形

spec/61-supply-profile.md:83「残走路＝評価範囲の to から covering の末尾までの日数」、:229（B.9）同文。対して spec/60-firing-layer-profile.md:139・:280、spec/50-glossary.md:28「起点は covering 末尾の翌日 0 時（排他端）＝表示の末尾（閉端）から演繹すると 1 日ずれる」。
実測: B.6 の数値（0 日・−31 日）は排他端起点で正しく出る。言い回しだけが割れている。
直し方: B.2・B.9 に「（起点は末尾の翌日 0 時＝排他端。付録 A A.4）」を括弧で足す。

③-L4 impl/README の CLI 概要行が `--help` と合わない

impl/README.md:36「list [--from] [--to] [--tz] [--json|--ics|--tsv] [--explain] <file>」・:39（next）に --supply・--lang en・--ics-series が無い。--help の実物と同 README の後続節（:76・:139・:148）には 3 つとも載る。
直し方: 概要行を --help の 1 行目・3 行目と同じ並びにする。

③-L5 `takeLast` の horizon-clip 文言「n 個中 k 個のみ」は下限側だけ

reference/takeLast.md:54-55「生成子入力で until: が計算範囲や実体化下限に掛かると horizon-clip 警告（「n 個中 k 個のみ」まで明示…）」。
実測: 下限 everyDay |> takeLast(3, until: 1970-01-02)（--from 1970-01-01）→ horizon-clip: takeLast 1970-01-02（実体化下限で切れ——n=3 個中 2 個のみ。…F107）。上限 everyDay |> takeLast(3, until: 2027-12-31)（--to 2026-02-01）→ horizon-clip: takeLast until 2027-12-31（計算範囲 to+400日の実体化地平線——実体化済みの末尾から数える。…）（件数なし）。
直し方: 「（実体化下限側は「n 個中 k 個のみ」まで明示）」と限定する。

③-L6 用語集 6.5 の `anchor:` の説明が `cycle` だけ

spec/50-glossary.md:133「anchor: cycle のラベル位相（どの実日が先頭ラベルか）」。同じ用語集 :69（grid(w)）・reference/grid.md:18-24（ADR-31 の位相上書き）・reference/segmentBy.md:76-98（labels: cycle … anchor:）・EBNF（40:239）では grid と周期形 labels: cycle も anchor: を取る。

直し方: 「cycle／labels: cycle のラベル位相・grid の位相（ADR-31）」に広げる。

③-L7 `reference/nth.md:36-45` の「第 2 月曜も同形:」の直後の例が第 2 営業日

:38「「第 2 月曜」（ハッピーマンデー級）も同形（月曜列 |> within(month) |> nth(2)）:」に続くコードが bizDay |> within(month) |> nth(2)（第 2 営業日。:27-32 の例の評価範囲違い）。
実測: everyDay |> filter(d => weekday(d) == Mon) |> within(month) |> nth(2)（標準前文・--from 2026-01-01 --to 2026-03-01）→ 2026-01-12 2026-02-09。
直し方: 上の式と期待値に差し替える（doctest になる）。

③-L8 `epoch:` の上書きを勧める箇所に参照実装の制約の参照が無い

spec/20-premise-layer.md:190-192・spec/40-grammar.md:66・spec/50-glossary.md:70・reference/epochOrdinal.md:11-12・stdlib/gregorian.md:55-56 は「原始的定義のメンバー epoch: で上書きできる」とだけ書く。impl/README.md:230「epoch: の既定以外の値は未対応（宣言すると静的エラー）」。
実測: premise Mars { epoch: 2000-01-06; day = chronos grid 1d } → プロトタイプは既定紀元（1970-01-01）のみ対応（epoch: の別値は未実装。ADR-31）、exit 1。
直し方: epochOrdinal.md と gregorian.md の該当文に「（参照実装 1.0.12 は既定紀元のみ＝impl/README）」。

良かった点

終了コードの契約は全文書で一致し、実物とも一致した。 impl/README.md:44・--help・付録 B B.6・mcp README・recipes/windows-admin.md の 0／1／2 の割り当てを、静的エラー（kind: static・exit 1）・契約違反 3 種（kind: supply・exit 1・診断冒頭が B.6 の表と一字一致）・next 不足（exit 2・found < requested）・--ics の予定 0 件（exit 2）・点 0＋註釈あり（VEVENT 2 行・exit 0）・list／--tsv の 0 点（exit 0）で確かめ、食い違いは無かった。
付録 B の受け入れ試験 (2)(3) は期待出力が字面まで再現する。 残走路 0 日・# 0 点・# ⚠ 範囲外 2028-01-01..2028-02-01（JP.holidays covering 2026-01-01..2027-12-31, asof 2026-10-22）・残走路 -31 日 が書いてあるとおりに出た。供給側がこの文書だけで自己検査できる。
at・take／takeLast・coincides の静的検査は spec・reference・実物の三者で説明が揃い、診断文が直し方まで言う（at(2026-01-01T17:00)→「日の調整は日の層で」、窓付き take→「within の後の nth」、takeLast(from:)→「錨は until:」）。window-clip が list で出て next で出ない 1.0.12 の変更も、impl/README・付録 A・CHANGELOG・実物で一致していた。

観点④ 英語ミラーの意味ズレ

対象: azathothx/kairos-lang HEAD 43e3734（版 1.0.12）の en/ 配下と、en/ を外した同じパスの日本語正本。レビュー日 2026-10-26。読んだのは公開リポジトリの内容だけ。

方法: (1) 自作スクリプトで全組の front matter source_sha・ ``kairos ` フェンス・他言語フェンス・見出し数・数値トークン（版・日付・ADR・F・§・MUST・追補）・リンク先を機械比較、(2) レシピの Playground リンク（#s= の base64url）を復号してプログラム本体を比較、(3) 62 組すべてを段落単位で読み合わせ（並列の読み手に分担し、挙がった所見は当方が両ファイルの該当行を開いて再確認した。確認できなかったものは載せていない）。スクリプトと中間出力はリポジトリの外（scratchpad/review14/tools・out）に置き、リポジトリには書き込んでいない。

実測サマリ

項目	実測
`en/` 配下の Markdown	63 ファイル（spec 10・reference 32・recipes 10・stdlib 4・skills 1・design/40-examples 2・en/README.md 1）
対訳のある組	62 組（en/README.md は索引ページで日本語の対がない。日本語のみのページ＝spec/CHANGELOG.md・stdlib/kyureki.md は en 側で「Japanese-only」と明記されている）
`source_sha` の宣言	60 ページに宣言・60/60 一致（sha256 の先頭 12 桁＝impl/test/doc-consistency.test.ts:297-310 と同じ定義で独立に再計算）。宣言なし＝en/README.md・en/spec/README.md
` ```kairos ` フェンス	日英とも 162 本・全組で本数一致。コメント行を除いた正規化で 162/162 同一。バイト一致 159／コメント（翻訳）だけ違うもの 3（en/reference/cycle.md 1・en/recipes/windows-admin.md 2）
他のフェンス（text・mermaid・ebnf・powershell・plain）	全組で本数一致。差はコメント・ラベル・散文の翻訳のみ。EBNF（spec/40-grammar）は `(* … *)` と `? … ?` 内の散文を除き規則本体が同一。PowerShell（recipes/windows-admin）はコマンド・引数・パスが同一（エラー文字列の翻訳のみ）
Playground リンク（recipes 9 ページ）	25 組。18 組はペイロードまで同一、7 組（excel 1・logistics 5・windows-admin 1）は先頭コメントの翻訳のみでコード同一。en 側は `kairos-lang.org/en/playground/` を指し、`en/playground/` は実在
見出し数	全組一致（例外: en/design/40-examples/README.md ＝ ja 6／en 5 → ④-M4）
数値トークン（版・日付・ADR・F・§・MUST・追補）	spec 10 組・stdlib 3 組・recipes 9 組・skills 1 組で多重集合一致。不一致は reference/take（ADR-52）・spec/50-glossary（追補 11）・takeLast（判断 6）・40-examples 2 件のみ（下記所見）
spec/60 MUST／SHOULD／MAY	34／35／2 で日英一致。A.8 チェックリスト 21 項目一致
spec/61 MUST／SHOULD／MAY・受け入れ試験	15／12／2・試験 4 本・B.8 チェックリスト 9 項目で一致。URL の形（最新・版つき）も同一
固定訳語の機械検査（doc-consistency.test.ts:357-380）の対象	en/spec・en/reference・en/stdlib・en/recipes（en/skills・en/design/40-examples は対象外）
フェンス同一性の機械検査（同 :313-335）の対象	en/spec・en/reference・en/stdlib・en/design/40-examples・en/recipes（en/skills は対象外 → ④-M3）

結論: 意味・数値・手順の差は 62 組でほぼ無く、ミラーの品質は高い。利用者が誤る差は 1 件（調査研究 11 の hour 窓）、抜け・不整合が 4 件、訳語の揺れ・表現が 18 件。

HIGH

④-H1 `hour` 窓を「Gregorian 標準に無い」と現在形で断言（日本語は「当時は無かった→ADR-50 で標準化」）

何が: 1.0.12 では hour は Gregorian 標準の窓（stdlib/gregorian.md:13 hour = chronos grid 1h … ADR-50・同 :123「### 2.1 hour の落とし穴（ADR-50）」、en/stdlib/gregorian.md:24・:148 も同じ）。日本語の (l) 節はその経緯を「実測当時は無かった・ADR-50 で標準化・以下は当時の書き方のまま残す」と書き換え済みだが、英語の (l) 節は改訂前の文のまま。
どこで: design/40-examples/11-impossible-schedules.md:314-316 ／ en/design/40-examples/11-impossible-schedules.md:341-342
引用（ja:314-316）: 「hour 窓は実測当時の Gregorian 標準に無かった（本節の実測が需要根拠となり ADR-50 で標準化＝§11.5。以下は当時の書き方のまま残す——暦の原子は 1 行で張れる〈grid・ADR-41 の第二用途〉の実演として今も有効）:」
引用（en:341-342）: “There is no hour window in the Gregorian standard, but a calendar atom is one line away (grid; the second use sanctioned by ADR-41):”
補足: 同ページの §11.5 相当（en:510 “the hour window → ADR-50 (standardization plus the new ordinalIn alignment check)”）は追従しているので、英語ページ内で (l) と §11.5 が矛盾している。source_sha は一致＝日本語の改訂と同時に sha だけ更新され、段落の訳が落ちたと推測。読者への実害は「標準語を無いと思い込み自前で grid 1h を張る」程度（結果は同じ）だが、現状と意味が逆なので HIGH に置く。
注: このページは本観点の主対象（spec・reference・recipes・stdlib・skills）の外だが、en/ ミラーで source_sha を持ち、en/recipes/README.md:36-37 から「study 11」として案内される入口なので載せる。
直し方: en:341-342 を ja:314-316 の訳に差し替える（例: “At the time of this measurement there was no hour window in the Gregorian standard; this section’s measurement became the demand evidence and ADR-50 standardized it (§11.5). The original form is kept below — still valid as a demonstration that a calendar atom is one line away (grid; the second use sanctioned by ADR-41):”）。

MEDIUM

④-M1 `take` の「関連」から ADR-52 が落ちている（本文は双方とも ADR-52 に言及）

どこで: reference/take.md:47-49 ／ en/reference/take.md:63-65
引用（ja:49）: 「filter（filter.md）・ADR-31/38/49/52。」
引用（en:65）: “(window-relative “the Nth” — the dual) · filter（filter.md） · ADR-31/38/49.”
ずれ: 英語の関連行だけ ADR-52（takeLast 導入）が無い。本文は両方とも takeLast＝ADR-52 と書いている（ja:42-43／en:57-59）ので、関連行が takeLast 追加前のまま。あわせて en:63 と en:65 の両方に “— the dual” が付き（ja:47 では双対は takeLast だけ、ja:48 の nth は「窓相対の「第 N」」のみ）、「双対」が 2 つ立っている。
直し方: en:65 を “ADR-31/38/49/52.” に。en:65 の nth の “— the dual” を削る。

④-M2 英語の索引ページ（en/README.md・en/spec/README.md）に recipes と skills が無い

どこで: en/README.md:7-11（spec・reference・stdlib の 3 項目のみ）、en/spec/README.md:35-44「Where things live」（reference・stdlib・design・root README のみ）
対して: README.md:215「recipes/（en/recipes/） — Recipes …」・README.md:217「skills/（en/skills/kairos-authoring/SKILL.md） — Authoring skill …」、README.ja.md:46、llms.txt:174-181 はいずれも両方を案内している。
ずれ: en/recipes/README.md（10 ページ）と en/skills/kairos-authoring/SKILL.md（1.0.12 対象の新しいページ）は英語ミラーとして存在するのに、「English mirror of the Kairos documentation」を名乗る en/README.md から辿れない。英語読者がリポジトリの root README を経由せず en/ に入ると見つからない。
直し方: en/README.md の箇条に “Recipes（recipes/README.md）” と “Authoring skill（skills/kairos-authoring/SKILL.md）” を足す。en/spec/README.md「Where things live」にも 1 行ずつ。

④-M3 「コードブロックの乖離も機械検査で止まる」という説明と、検査の対象範囲が食い違う（en/skills が同一性検査の外）

どこで: en/README.md:3-5 ／ impl/test/doc-consistency.test.ts:325-326・372-373
引用（en/README.md:3-5）: “every page under en/ is a translation that follows them (each chapter records its source revision as source_sha, and an automated consistency check flags stale translations and diverging code blocks).”
引用（doc-consistency.test.ts:325-326）: for (const p of [...mdFiles('en/spec/'), ...mdFiles('en/reference/'), ...mdFiles('en/stdlib/'), ...mdFiles('en/design/40-examples/'), ...mdFiles('en/recipes/')]) —— ``kairos ` 同一性検査の走査に en/skills/kairos-authoring/ が無い（source_sha 検査 :301-303 には有る）。固定訳語の検査（:372-373）も en/skills と en/design/40-examples を見ていない。
ずれ: 現時点では SKILL.md の 18 本は 18/18 バイト一致（当方の実測）なので実害は無いが、記述スキルは 1.0.12 で 2-15 が足されたばかりの動くページで、英語側だけの編集や再同期漏れを機械が止められない。en/README.md の説明は「全ページ」と読める。
直し方: doc-consistency.test.ts:325-326 の配列に ...mdFiles('en/skills/kairos-authoring/') を足す（固定訳語検査 :372-373 にも）。あるいは en/README.md の文を「code blocks in spec/reference/stdlib/recipes」と限定する。

④-M4 en/design/40-examples/README.md は「記法の規約」節と 2 文が無く、「Translated from」の体裁と合っていない

どこで: design/40-examples/README.md:39-44「## 記法の規約」（五点セット・@JP 既定・暫定語彙の注記）、同 :20-21「実データ投入により…（F32/F33）が新たに露見し、射影一族（labelOf）の必要性が具体的に裏づけられた」、同 :36-37「01〜04 の本文例の順次 doctest 化…は進行中の宿題」／ en/design/40-examples/README.md には対応する節・文が無い（見出し ja 6／en 5）。逆に en:99-100 “All of it fed the design and is settled in the spec” は ja:94-96 に無い。
ずれ: ページ冒頭（en:10-13）で「this page is the English index of what was verified」と索引であることは宣言しているが、同じ囲みで “Translated from the canonical Japanese catalog … source_sha” とも書いており、読者は全文訳と受け取る。抜けている節は読み方の規約（例の既定前文）なので、study 11 を英語で読む人には要る情報。
注: 主対象の外（design/）だが source_sha 付きのミラーなので載せる。
直し方: 「記法の規約」を訳して足す（3 箇条）か、冒頭の囲みに “abridged: the notation conventions and the in-progress notes are omitted” と明記する。

LOW

④-L1 「在圏」が in-scope と resident に割れる

en/reference/at.md:27 “in the resident tz”（ja reference/at.md:16「（在圏 tz）」）・en/spec/50-glossary.md:147 “in the resident tz”（ja:137）・en/stdlib/gregorian.md:175 “the resident tz’s civil epoch”（ja:146「在圏 tz の市民紀元」）。他は一貫して in-scope（例: en/reference/epochOrdinal.md:22 が同じ「（在圏 tz）」を “in the in-scope tz” と訳す・en/reference/everyDay.md:5・en/stdlib/fiscal.md:33）。
直し方: 3 箇所を in-scope に。

④-L2 「還流第 N 便」「実装系還流」の訳が 4 通り

“reflux mail 15 (e)”／”reflux mail 20 §3”（en/reference/at.md:71・81・90、combinators.md:87、segmentBy.md:146・175・190・219）、”the third feedback batch”（nonWorking.md:102、nth.md:48-49、stride.md:47）、”implementation feedback’s third batch”（roll.md:66）、”feedback, 5th delivery”（table-literal.md:91-92）、”runtime-side reflux”（cycle.md:70、ja:54「実装系還流 2026-08」）。
直し方: 1 語に揃える（例: “feedback batch N”）。番号はすべて一致しているので置換だけで済む。

④-L3 「発報層」が同一ページ内で firing layer と alerting-layer

en/reference/table-literal.md:32 “the firing layer’s implementation feedback”（ja:17）／同 :91-92 “the alerting-layer feedback, 5th delivery”（ja:68「発報層還流第 5 便」）。spec・README は firing layer で統一されている（en/spec/README.md:27 “Firing layer profile”）。
直し方: :91-92 を firing layer に。

④-L4 「利用側」の訳が user side／caller／consumer

「利用側相対」は consumer-relative で固定（検査あり: en/reference/isOpen.md:35・131、nonWorking.md:126、en/spec/20-premise-layer.md:542）。単独の「利用側」は “user side”（nonWorking.md:33-35・127-130、epochOrdinal.md:24、en/spec/20-premise-layer.md:213・236・346・464・491・513）、”caller”（sugar-definition.md:27・39）、”consumer”（takeLast.md:24）。同じ nonWorking.md の中で「利用側＝user side」と「利用側相対＝consumer-relative」の語幹が分かれる。
直し方: 単独の「利用側」も consumer に寄せるか、用語集に「consumer (利用側)」の見出しを置いて対応を明示する。

④-L5 「前文メンバー」が preamble member と premise members

en/spec/20-premise-layer.md:267 “Premise members are inherited along the base chain”（ja:219「前文メンバーも基底連鎖から継承し」）。他は “preamble member(s)”（同 en:91・94・95・235・489、en/spec/60-firing-layer-profile.md:81 “the eight preamble members”）。en/reference/with.md:15（図の alt）”the 10 premise members” も同じ（ja:6「前文メンバー 10 語」）。
直し方: preamble members に。

④-L6 「十二支」が “the sexagenary cycle”（六十干支）

spec/20-premise-layer.md:145「十二支は year cycle […]」／ en/spec/20-premise-layer.md:175 “the sexagenary cycle is year cycle […]“。十二支は周期 12、sexagenary は周期 60。例としてはどちらも year cycle で書けるので利用者は誤らないが、語が別物。
直し方: “the twelve Earthly Branches (the Chinese zodiac) are year cycle […]“。

④-L7 「覆域」が takeLast だけ covering

en/reference/takeLast.md:39 “the covering tail”・:59 “the head of the covering”・:62-63 “the covering tail … The covering head”（ja:27・45・47-48「覆域の尾／頭」）。他ページは coverage（例: en/reference/first.md:51 “coverage edge”、nth.md:69、snapTo.md:66 “effective coverage”）。covering: は構文キーワードなので、概念語に同じ字を使うと混ざる。
直し方: coverage tail／coverage head に。

④-L8 「先頭点」が span.md の 1 箇所だけ head instant

en/reference/span.md:74 “(computed from the head instant)”（ja:57「先頭点から計算」）。同ページ :57-58 と他ページは “first point”（検査の正でもある）。
直し方: first point に。

④-L9 stdlib 内の訳語の揺れ 3 組

「据え置きピン」: en/stdlib/fiscal.md:121 “a keep-in-place pin like month = Gregorian.month” ／ en/stdlib/gregorian.md:324-325 “no holding pin such as month = Gregorian.month“（ja は同文）。
「射程外」: en/stdlib/fiscal.md:281・296・334 “out of reach” ／ en/stdlib/iso-week.md:144-145 “adjacent windows are out of range”（ja:118「隣接窓は射程外」）。range は「範囲外（out-of-coverage）」と紛れる。
「紀元差」: en/stdlib/gregorian.md:112 “epoch offset difference” ／同 :173・180-181 “epoch difference”。
直し方: それぞれ 1 語に。

④-L10 「出所」と「出自」が provenance／source／origin に跨がる

「出所（source: の値）」: en/spec/00-intro.md:66 “Provenance governance (source: / asof:)”・en/spec/10-types.md:43 “provenance” に対し、用語集の見出しは en/spec/50-glossary.md:64 “source（出所）”・:85 “source governance”・:134。
「出自（註釈区間の由来）」: en/spec/10-types.md:125-127 “out-of-coverage origin” に対し en/spec/50-glossary.md:171（I6）”out-of-coverage provenance“。en/spec/30-body-layer.md の §4.10 見出しは “origin”。
ずれ: 用語集から本文へ引き戻すときに語が繋がらない。意味の誤りではない。
直し方: 出所＝provenance、出自＝origin で固定し、用語集の見出し語を揃える。

④-L11 用語集冒頭の「CHANGELOG 追補 11」参照が英語に無い

spec/50-glossary.md:4-5「最後の rephase 裁定〈2026-07-26・旧仮称 shiftBoundary・CHANGELOG 追補 11〉」／ en/spec/50-glossary.md:12-15 “the final rephase ruling of 2026-07-26, formerly shiftBoundary, completed the set” ——追補番号が落ちている（辿り先が 1 つ減る）。
直し方: “(CHANGELOG addendum 11)” を補う。

④-L12 takeLast の「ADR-49 判断 6」が “the ADR-49 deferral”

reference/takeLast.md:8-9「ADR-49 判断 6 の見送りを…改訂」／ en/reference/takeLast.md:18 “revising the ADR-49 deferral”。副番号が無い。
直し方: “the deferral in ADR-49 decision 6”。

④-L13 ordinalIn の条件が「単位幅の整数倍」から「時間の整数」に狭まる

reference/ordinalIn.md:40「紀元差が単位幅の整数倍でない tz（Kathmandu・Singapore・Lord_Howe）」／ en/reference/ordinalIn.md:54 “time zones whose offset drifted from the epoch by a non-integral number of hours”。u が hour 以外の経過幅のときの条件が英語では読めない（同じ箇条の例は hour なので実害は小さい）。
直し方: “by a non-integral multiple of the unit width (e.g. hours)”。

④-L14 windows-admin の小さな欠落 3 点

recipes/windows-admin.md:92 > C:\kairos\out.json ／ en/recipes/windows-admin.md:99 > out.json（出力先が絶対／相対。どちらも動く。落とし穴表 ja:260／en:268 は両方 > out.json）。
ja:13「npx -y kairos-lang list …（初回はダウンロードが走る）」／ en:20 は括弧書きなし。
ja:94「…先に [Console]::OutputEncoding = …。kairos は UTF-8 で書く。」／ en:101 は末尾の一文なし（スクリプト内コメント en:122 # kairos writes UTF-8 には残る）。
直し方: ja に合わせて補う（または ja:92 を > out.json に揃える）。

④-L15 イースターの定義文の精度差（英語の方が正確）

recipes/easter-schedule.md:3「春分後の最初の満月の次の日曜」／ en/recipes/easter-schedule.md:10-11 “the first Sunday after the first full moon on or after the spring equinox”。式と出力は同一。
直し方: 日本語側を「春分以後」に寄せると一致する（正本の修正提案）。

④-L16 段落・箇条の配置が違う（内容は同一）3 件

spec/30-body-layer.md §4.8: ja は ADR-53（:293-297）→ F110「展開は有限」（:299-300）→「展開＝右辺の機械的差し込み」（:302-305）、en は F110（:367-369）→「Premises are not baked in」（:371-375）→ ADR-53（:377-384）→（:386-390）。
reference/split.md: 「週の平日部と週末部」の例が ja では「## label:（ADR-34）」の下（:52-66）、en では「## Examples」の 3 例目（:67-77）に移り「## label: (ADR-34)」（:79-83）は説明だけ。
spec/60-firing-layer-profile.md:72 の 1 つの SHOULD 箇条（キャッシュ鍵＋評価範囲の註）が en:81-82 で “SHOULD” と “Note:” の 2 箇条に分かれる（SHOULD 本数は 35 で不変、註の数は 18 対 19）。
直し方: 本数を突き合わせる読者のため、どちらかに揃える（優先度低）。

④-L17 `source_sha` の意味は伝わるが、読者が自分で確かめる手がかりが無い

各ページの定型句（例: en/spec/00-intro.md:6-8 “The source_sha above records the source revision; a consistency check flags this page when the Japanese original changes.”）と en/README.md:3-5 で仕組みは説明されている。en/reference/README.md:64-69 は「doctest は日本語正本で走り、同一性検査でこのミラーのブロックを同一に保つ」まで書いていて良い。ただし値の正体（日本語ファイルの SHA-256 先頭 12 桁。git のコミット／blob ハッシュではない）はどこにも無く、読者が source_sha と手元の日本語ファイルを突き合わせる手段が無い。また en/README.md と en/spec/README.md は source_sha を持たないので、ja の spec/README.md の状態行（追補番号・ADR 数）が動いても機械では止まらない（テスト数・追補番号だけは doc-consistency.test.ts:211-239 の別検査が見る）。
直し方: en/README.md の 1 文に “(source_sha = the first 12 hex digits of the SHA-256 of the Japanese file, e.g. sha256sum spec/00-intro.md | cut -c1-12)” を足す。en/spec/README.md にも source_sha を付けて検査に乗せる。

④-L18 その他の訳語・見出しの揺れ（まとめ）

「宣言必須寄り」: en/spec/20-premise-layer.md:271 “declaration leaning towards required” ／他は “declaration-required leaning”（同 :66-67・254・337、en/stdlib/gregorian.md ほか）。
「悪化」（coincides への書き換えの評価）: en/reference/coincides.md:147 “a worsening” ／ en/reference/combinators.md:78-79 “a regression”。
「実装系」: en/reference/external.md:42・52・83 “the implementation” ／ en/reference/cycle.md:70 “runtime-side”。
「範囲外」の gloss（recipes）: en/recipes/excel-workday.md:158・en/recipes/logistics-delivery.md:241-242 “out of coverage” ／ en/recipes/windows-admin.md:77 “out of range”（reference は out-of-coverage で統一）。
「残走路」: en/recipes/excel-workday.md:184・logistics-delivery.md:244 “remaining runway” ／ windows-admin.md:78・89・274 “runway”（reference は runway）。
見出し「射程の明示」: en/recipes/easter-schedule.md:51 “Scope, stated explicitly” ／ patch-tuesday.md:178・us-election-day-and-thanksgiving.md:104 “Scope”。
「調査研究 11」: 6 ページで “study 11”、en/recipes/patch-tuesday.md:209 だけ “Study 11”。
「束縛名(d)」の表記: en/reference/segmentBy.md:65 name(d) ／ en/reference/table-literal.md:101 bindingName(d)。
直し方: 用語集（en/spec/50-glossary.md）か訳語検査（doc-consistency.test.ts:357-380 の banned 配列）に 1 行ずつ足せば再発しない。

参考（日英の差ではないが、読み合わせで見えたもの）

stdlib/gregorian.md:268「rephase 展開形は base の label: を保存する（F65）」に対し、stdlib/fiscal.md:37 と gregorian.md:267 は同じ事実を F96 としている。英語（en/stdlib/gregorian.md:329）は F65 を忠実に写している。正本側の誤記の可能性（推測）。
当方の粗い正規表現では reference/README.md:52 と design/40-examples/11-impossible-schedules.md の本文中の「 kairos ` フェンス」という字句をフェンス開始と誤認した。doc-consistency.test.ts:323 の正規表現（`/kairos\n/）は行末を要求するので誤認しない。上のサマリの 162 本はこの 2 件を除いた数。

良かった点

コードは 1 文字もずれていない: ` ```kairos ` 162 本が全組で本数一致・正規化後 162/162 同一（159 本はバイト一致）。レシピの Playground リンク 25 組もプログラム本体が同一で、英語版は /en/playground/ に正しく向いている。EBNF の規則本体、PowerShell のコマンド・引数、spec/60・61 の MUST／SHOULD／MAY の本数とチェックリストの項目数、受け入れ試験 4 本の期待値（終了コード・残走路の日数）まで一致している。
source_sha は 60/60 一致で、英語の各ページ冒頭の定型句と en/README.md が仕組みを読者に説明している。en/reference/README.md:64-69 は「doctest は日本語正本で走り、同一性検査でこのミラーのブロックを同一に保つから保証が引き継がれる」と、機械検査の設計まで読者に見せている。
日本語のまま残すべきものを残し、訳注で補っている: #~> 行の正準形（en/reference/README.md:93-95 の Translator’s note）、診断文（en/skills/kairos-authoring/SKILL.md:261-271 は CLI の実出力を日本語のまま置き、直後に英語の gloss を順に添える）、被覆サマリ／⚠ 範囲外（同 :289-290）。英語読者が実機の出力と照合できる。
記述スキルの英語版は 1.0.12 の正本と段落単位で一致（手順 5 歩・2-1〜2-15・禁則表 11 行・語彙表 9 行・書かないこと 4 箇条）。新しいページなのに取りこぼしが無い。
固定訳語（註釈 annotation・覆域 coverage・範囲外 out-of-coverage・標準導出 standard derivation・予約公開語 reserved public word・公開境界語 public boundary word・窓相対 window-relative・実体相対 entity-relative・証人 witness・残走路 runway）は reference 32 ページで一貫している。
Kyureki が日本語のみであることは en/README.md・en/spec/README.md:40-42・en/stdlib/README.md:38-42 の 3 箇所で明記され、英語読者が探し回らずに済む。

観点⑤ 鮮度と陳腐化

対象: 公開リポジトリ azathothx/kairos-lang HEAD 43e3734（版 1.0.12）。レビュー日 2026-10-26。外部の値は GitHub Release／API・npm registry・kairos-lang.org の配信物を同日に取得した。実行は作業用 clone の node impl/dist/cli.js（--version → 1.0.12）。全スイートは走らせていない。

実測サマリ

#	検証項目	見たもの（ファイル:行・外部の値）	結果
(1)	祝日表の年・`covering:`・残走路の見せ方	Playground `playground/core.js`: 7 表すべて `covering: 2026..2027`（:54, :105, :127, :149, :193, :242, :262）＋空表の教材 `holidays2027 = [] covering: 2027..2027`（:176, :289）。2027 年分は内閣府・OPM の値と一致（3/21 春分→3/22 振替・9/23 秋分・OPM observed 6/18・7/5・12/24）。witness `impl/test/next-window-and-playground.test.ts:102-121`（鮮度＝終端が今日＋88 日より先・内容＝2027 年分の照合）。配信中の `core.js`・`js/build-info.js`（IMPL_VERSION 1.0.12）は HEAD とバイト一致。recipes: 大半が `covering: 2026..2026`（例 `recipes/excel-workday.md:146`・`cron-last-day-of-month.md:61`）で doctest が期待値を固定し、2027 年に掛かる例は `#~> 範囲外 …` を本文に見せる教材。`logistics-delivery.md:228,230` は 2026..2027。stdlib: `stdlib/kyureki.md` は朔データ `covering: 2024-12-31..2027-12-31`／`asof: 2026-02-02`（7 箇所）・Gregorian/Fiscal/ISOWeek は表を持たない。`impl/examples/.kairos` は 2026..2026（⚠ を見せる教材と MAINTENANCE §1 に明記）。残走路の見せ方*: CLI は `# <表> covering A..B 残走路 N 日`（`--json` は `coverage[].runwayDays`）。Playground は `core.js:18-20/34-36` で同じ 2 行形（日英）。`recipes/windows-admin.md:62-68` の例（`残走路 -59 日`）を同形の定義で再現＝出力形式・値とも一致	表は現行。ただし業務の例の固定窓が尽きている／尽きる（⑤-M1）
(2)	Windows ガイドの exe の版・Release 資産名・sha256	`recipes/windows-admin.md:15-17`／`en/recipes/windows-admin.md:22-24`: Release v1.0.12・`kairos-1.0.12-win-x64.zip`・「SHA256 は同じ場所の `.sha256`」・npm `kairos-lang@1.0.12` と同一ソース。`gh release view v1.0.12` → 資産 2 点 `kairos-1.0.12-win-x64.zip`（36,225,004 B）と `.sha256`（92 B）。`.sha256` の値 `6eabea03…b41ed` ＝取得した zip の `sha256sum` ＝ Release 本文の記載。zip の中身は `kairos.exe`（最上位）と `README-windows.txt`（「Kairos 1.0.12」・Node v24.22.1・ガイド URL 日英）。`releases/latest` も v1.0.12	一致
(3)	MCP README の版・導入コマンド・npm の最新版	`mcp/README.md:20-43`／`README.ja.md:20-43`: 導入は `npx -y kairos-lang-mcp`・`claude mcp add kairos-lang -- npx -y kairos-lang-mcp`・デスクトップアプリの JSON。版は本文に書かず「`kairos-lang` と同番」（:116）。HEAD `mcp/package.json` 1.0.12・`server.json` 1.0.12。npm `kairos-lang-mcp` dist-tags `latest: 1.0.12`（2026-10-26T00:12Z）・`kairos-lang` `latest: 1.0.12`（00:07Z）・両 1.0.12 の shasum は取得した tarball と一致。README の上限（10 年・n 1000・horizonYears 10・64 KB）＝`mcp/src/server.ts:23`、リソース `kairos://llms.txt`／`kairos://reference/{lang}/{word}`＝:167,173、tool 入力＝:83-127 と一致。npm 公開物の README は HEAD と同一	一致。同梱 `docs/llms.txt` と依存指定だけ公開後の HEAD とずれ（⑤-L2）。Registry 掲載の真偽は許可された参照先の外＝未検証
(4)	llms.txt の版・テスト数・リンク	`llms.txt:13` 1.0（2026-09-14）・`:21` 880 tests・`:204` 53 ADR（`design/20-adr/` に 53 ファイル・INDEX「ADR-01〜53」）。raw.githubusercontent 16 本＋github tree 2 本のリンク先は HEAD に全部実在（`en/skills/kairos-authoring/SKILL.md`・`en/spec/61-supply-profile.md` 含む）。配信中の https://kairos-lang.org/llms.txt は HEAD と `diff` 無し（16,087 B）。`:85` の残走路例の形は CLI 出力と同形	一致
(5)	「準備中」「予定」「coming」等の残置	`design/` を除く公開面を grep。「準備中」1 件＝`spec/CHANGELOG.md:801`（⑤-L1）。「coming soon／in preparation／forthcoming／TBD／TODO／WIP／次の版／次版」0 件。「English（未訳）」（`_includes/docs-topbar.html:50`）は英訳の無いページだけに出る分岐＝適正。「将来拡張／将来の opt-in」（`reference/rebase.md:63`・`spec/40-grammar.md:163`・`impl/README.md:136,209`）は仕様が意図して据え置く旨の表明＝適正。「予定」は .ics の「予定（イベント）」の意味のみ	残置は実質 1 件（LOW）
(6)	README 日英・spec/README の状態行 vs CHANGELOG	`README.md:207`「Version 1.0 (declared 2026-09-14; addenda through no. 29, 2026-10-26)」・`README.ja.md:35`「追補 29〈2026-10-26〉」・`spec/README.md:6` 同・`en/spec/README.md:7` 同。`spec/CHANGELOG.md:754`「## 1.0 追補 29（2026-10-26）」が最終（追補 30 は無い）。テスト数 880 は入口 6 箇所（README 日英・llms.txt・en/spec/README・impl/README:234「39 ファイル・880 本」・CHANGELOG:824）で一致、`impl/test/*.test.ts` は 39 本。CI（`.github/workflows/ci.yml:33-35`）は JSON レポートで実数と突合し、43e3734 の CI は success（2026-10-26T03:29Z）	一致

テスト数の補足（推測を含む）: 全スイートは走らせていないので、npx vitest list（静的収集）で 688 項目を得た。うち test/doctest.test.ts はループ生成のため 1 項目として数えられる（${sub}/${f} のまま表示）。doctest の対象 5 ディレクトリの # eval: 付き ```kairos ブロックを同じ正規表現で数えると 192（reference 66・stdlib 28・design/40-examples 43・recipes 37・skills 18）→ 688 − 1 + 192 ＝ 879 が下限。他ファイルにもループ生成の項目が 1 件以上あれば 880 に届く。CI の突合が緑であることと併せ、880 は実スイートと一致していると判断する（断定は CI の結果に依る）。

所見

HIGH

該当なし。公開面の記載（版・資産名・sha256・テスト数・状態行・リンク）と実物（Release・npm・配信中のサイト・CLI）の不一致は見つからなかった。

MEDIUM

⑤-M1 Playground の業務の例「給料日（25 日）」は固定窓がすでに尽きており、他の固定窓も 2027-01-01 で尽きる。年次手順に窓の更新が無い。

どこで: playground/core.js:89-90（日本語 payday: from: '2026-07-01', to: '2026-11-01'）・:228-229（英語 payday: 同じ窓）。:111-112／:248-249（monthend3: 2026-08-01..2026-12-01）。garbage／pay15／cascade／friday13 と playground/index.html:40-41・en/playground/index.html:42-43 の既定値は 2026-01-01..2027-01-01。hn/payday.md の redirect 先も同じ窓（f=2026-07-01&t=2026-11-01）。
再現: 同じ定義を CLI で list --from 2026-07-01 --to 2026-11-01 --tz Asia/Tokyo → 2026-07-24 2026-08-25 2026-09-25 2026-10-23＋残走路 426 日。レビュー日 2026-10-26 時点で 4 点とも過去。monthend3 は 2026-12-01 以降、残りの固定窓と既定値は 2027-01-01 以降、過去の日付だけになる。
根拠: MAINTENANCE.md:6-35 の年次作業（毎年 2 月）は「表の行を足し covering: の右端を延ばす」だけで、from／to の更新を含まない。鮮度 witness（impl/test/next-window-and-playground.test.ts:102）も表の終端しか見ない。core.js:79 のコメント自身が「固定の範囲だと 11 月以降は過去の予定だけになる」と認識し、alarm だけを window: 28 にしている。
影響: 表は正しいのに、入口の例を開いた人が「過去の給料日の一覧」を見る。式を読まない利用者には壊れて見える（MAINTENANCE §1 の言葉どおり）。誤った日付ではないので MEDIUM。
直し方の案: (a) 業務の例も window: 型（選んだ日から N 日）にするか、from を「今日の月初」から相対で決める。(b) 固定窓を残すなら、MAINTENANCE §1 の手順に「例と既定値の from／to を翌年へ」を 1 行足し、鮮度 witness に「窓の終端 > 今日」を加える。(c) hn/payday は投稿当時の写しなら hn/README.md にその旨を注記、そうでなければ窓を現行に合わせる。

⑤-M2 README（日英）の構成表と impl/README.md が参照実装を「プロトタイプ／prototype」と呼び、他の公開面の「1.0.12 の参照実装」と調子が合わない。

どこで: README.md:219「Reference implementation (TypeScript, zero runtime deps; prototype — Japanese)」・README.ja.md:48「リファレンス実装（TypeScript・実行時依存ゼロ。プロトタイプ）」・impl/README.md:1「# Kairos リファレンス実装（プロトタイプ）」・:203「## プロトタイプの制約（仕様との既知の乖離）」。
対照: llms.txt:21,134「Reference implementation …」、npm kairos-lang の description「Reference implementation (CLI + evaluator…)」、Release v1.0.12 本文、mcp/README.md:10「thin wrapper over the reference implementation’s CLI」、recipes/windows-admin.md:15-16（exe は同一ソース）。1.0 宣言（2026-09-14）から追補 29 まで、npm／exe／MCP Registry で配布されている実物に対して「プロトタイプ」は古い自己評価に読める。
影響: 導入を検討する読者が「本番で使ってよいか」を判断しにくい。記載と実物の不一致ではないので MEDIUM。
直し方の案: 構成表は「リファレンス実装（TypeScript・実行時依存ゼロ）」とし、未実装項目は impl/README.md の「仕様との既知の乖離」節へのリンクで示す。impl/README.md:1 の見出しと :203 の節名も「既知の乖離」に寄せる。

LOW

⑤-L1 spec/CHANGELOG.md:801 の「準備中の版では」は、1.0.12 公開後は指示対象が曖昧。

文: 「準備中の版では、0 点の filter の述語内の名前を先行する式が射影で強制すると、…（1.0.11 には出ていた）」。公開前の作業版に限って存在した不具合の記録だが、公開後に読むと「準備中の版」がどの版か分からない。
直し方: 「1.0.12 の公開前の作業版（未公開）では」に置き換える。追記型の記録でも指示語の補足は許される。

⑤-L2 npm kairos-lang-mcp@1.0.12 の同梱 docs/llms.txt（MCP リソース kairos://llms.txt）と依存指定が、公開後の HEAD と食い違う。

実測: tarball の docs/llms.txt:21 は「862 tests」、付録 B（en/spec/61-supply-profile.md）と記述スキルの行が無い（HEAD/配信中の llms.txt との diff 3 箇所）。公開物の dependencies.kairos-lang は ^1.0.11、HEAD mcp/package.json は ^1.0.12（解決先はどちらも 1.0.12 なので動作差は無い）。
評価: 公開時点の写しとして自然なずれ。mcp/README.md:121「bundled … are copies from the same repository」は正しいが「公開時点の」とは書いていない。
直し方: README に「同梱の写しは公開時点のもの。最新は https://kairos-lang.org/llms.txt」と 1 行、または次版で同期（自動で揃う）。

⑤-L3 Windows ガイド（日英）は Release の版・zip 名を本文に直書きしている（現在は一致）。

どこで: recipes/windows-admin.md:15-16・en/recipes/windows-admin.md:22-23（Release v1.0.12・kairos-1.0.12-win-x64.zip・kairos-lang@1.0.12）。zip 同梱の README-windows.txt も同じ値を持つ。
評価: 今回は Release・npm・zip と完全一致。ただし版を出すたびに 2 言語 × 2 箇所の手修正が要り、ずれると「記載の zip が無い」という HIGH になる構造。
直し方: 本文は releases/latest へのリンク＋「zip 名の版は Release ページのとおり」とし、版番号は 1 箇所（例: 入口の「動作確認は kairos --version」）に留める。現状維持なら公開手順の点検項目に残す。

⑤-L4 MAINTENANCE.md:15「期限は 10 月初め。鮮度の検査（下の 2）が赤になる」は、検査の閾値と 1 か月ずれる。

実装: impl/test/next-window-and-playground.test.ts:104-107 は「終端 > 今日＋88 日」。freshness.yml は毎月 1 日 21:00 UTC（2 日 06:00 JST）に実行。終端 2027-12-31 の表は、2027-10-02 JST の実行では今日＋88 日＝2027-12-29 で緑、2027-11-02 JST の実行で初めて赤。
直し方: 「赤になるのは 11 月初めの実行。作業は 2 月の公示後に済ませ、遅くとも 10 月中に」のように、検査が赤になる時期と作業の期限を分けて書く。英語要約（:80）は「within today + 4 weeks + 60 days」と正確なので日本語側だけ。

⑤-L5 hn/ の短縮リンクは 2026 年のみの表と尽きた窓を埋め込む。

実測: hn/payday.md の redirect 先を復号すると holidays2026 = […] covering: 2026..2026・窓 2026-07-01..2026-11-01。開くと全点過去（⑤-M1 と同じ値）。hn/README.md は「the targets are the same links as in the post’s first comment」とあり、投稿当時の写しを保つ意図と読める。
直し方: 意図どおりなら hn/README.md に「投稿当時（2026 年）の定義のまま」と 1 行。そうでなければ redirect 先だけ現行の Playground 既定に揃える（短縮 URL 自体は不変）。

良かった点

配布物の三点照合が通る。Windows ガイド（日英）の記述 → Release v1.0.12 の資産名 → .sha256 の値 → 取得した zip の実測 sha256 → zip 内 kairos.exe＋README-windows.txt（1.0.12・Node v24.22.1・ガイド URL）が一本の線で一致した。ガイドの註釈例（# ⚠ 範囲外 …／残走路 -59 日）も CLI の実出力と同形・同値。
llms.txt が「配信中＝HEAD」で、リンク 18 本が全部実在。AI 読者向けの面が最新で、状態行（1.0・2026-09-14・追補 29〈2026-10-26〉）が README 日英・spec/README 日英・CHANGELOG の 5 箇所で一致している。テスト数は入口 6 箇所一致に加え、CI が JSON レポートで実数と突合する（手で書く数字を機械で止める設計）。
英語ミラーの鮮度が機械で担保されている。en/**/*.md 61 本のうち front matter を持つ 59 本の source_sha を日本語側の sha256 先頭 12 桁と照合し、陳腐化 0。
祝日表の年次更新が「表の出所・対象 7 箇所・手順・検査」まで文書化され、2027 年分は上流（内閣府 CSV・OPM observed）と一致する witness を持つ。表の外を黙らせない設計（covering:＋残走路）が、Playground・CLI・--json・ガイドの例で同じ形に揃っている。

観点⑥ 検定の抜き取り（10 問）

レビュー日 2026-10-26。対象＝検定リポジトリ azathothx/kairos-lang-exam HEAD 937256a（公開サイト https://exam.kairos-lang.org ）と、本体 azathothx/kairos-lang HEAD 43e3734（impl/dist/cli.js ＝ --version 1.0.12）。すべて公開物だけを読み、CLI は教材の「検証」節の定義をそのままファイルに写して list --from … --to … --tz Asia/Tokyo で走らせた（README.md:47 の指示どおり）。再現用の定義ファイルと実出力は …/scratchpad/review14/work6/（exp/ が教材の期待・out/ が実出力・tb/ が教本だけの例）。

実測サマリ

抜き取り 10 問（級が偏らないよう 3 級 3・2 級 4・1 級 3）——10 問すべて一致。 比較は点の行だけでなく # 0 点・# ⚠ 範囲外・# 被覆サマリ の行まで、教材の text ブロックと diff で全行一致を見た。

#	id	級	形式	評価範囲（教材）	教材の期待	CLI 実出力	判定
1	L3-004	3	出力予測	2026-01-05..2026-01-26	01-05, 01-12, 01-19	同	一致
2	L3-011	3	出力予測	2026-08-10..2026-08-17	08-10, 08-12, 08-13, 08-14 ＋被覆サマリ（残走路 16 日）	同（サマリ行も一致）	一致
3	L3-013	3	出力予測	2026-09-01..2026-10-01	09-04, 09-11, 09-18, 09-25（4 点＝(b)）	同	一致
4	L2-003	2	作文	2026-01-01..2026-04-01	01-09, 02-13, 03-13	同	一致
5	L2-009	2	作文	2026-08-01..2026-12-01	08-28, 09-25, 10-30, 11-27	同（別解 `within(month) \\|> last` も同一出力を実測）	一致
6	L2-014	2	作文	2026-08-01..2026-12-01	08-31, 09-30, 10-30, 11-30 ＋サマリ（残走路 31 日）	同（別解 `bizDay \\|> within(month) \\|> last` も同一）	一致
7	L2-015	2	作文	2026-07-01..2026-11-01	07-27, 08-25, 09-25, 10-26 ＋サマリ（残走路 61 日）	同	一致
8	L1-002	1	出力予測	2027-01-04..2027-01-11	01-04〜01-08 の 5 点＋サマリ（残走路 355 日・註釈なし）	同	一致
9	L1-011	1	出力予測	2028-01-01..2028-06-01	`# 0 点` ＋ `# ⚠ 範囲外 2028-01-01..2028-03-31（…）` ＋サマリ（残走路 214 日）	同（3 行とも文字一致）	一致
10	L1-012	1	出力予測	窓 A 2026-01-01..02-01／窓 B 01-15..03-01	A: 01-05, 01-19／B: 01-19, 02-02, 02-16（重なり＝01-19 のみ）	同	一致

再現コマンドの形（例 #7）:

$ node impl/dist/cli.js list --from 2026-07-01 --to 2026-11-01 --tz Asia/Tokyo L2-015.kairos
2026-07-27
2026-08-25
2026-09-25
2026-10-26
# 被覆サマリ
#   holidays2026 covering 2026-01-01..2026-12-31 残走路 61 日

追加で走らせたもの（表の外・すべて一致）: 残りの実行可能サンプル 4 問（L3-001・L2-011・L2-013・L1-015【A】【B】——【A】の # ⚠ 範囲外 … 残走路 -151 日・【B】の「註釈なし・残走路 ∞」まで一致）、教本だけにある例 7 本（L3 第 2 章の字句エラー文・第 3 章 last・第 4 章の二前提 # 式 1（2 件）／# 式 2（2 件）・L2 第 1 章 Preceding 形・第 3 章の二式・L1 第 1 章の boot 作法 残走路 -161 日・第 5 章の供給エラー文）。教本 L1 第 2 章が引用する警告文 警告: horizon-clip: shift 〈点〉（計算範囲 to+400日の実体化地平線——言語の地平線ではない。ADR-37 判断 8） も、shift(500, unit: day) を走らせて実装の文言と一字一句一致することを確かめた。教本 L3 第 2 章の主張 3 点（1d12h は字句エラー／at(T09:00) で時刻付きになる／2026-01 は引き算に読まれる）も CLI で成立。

版の確認（一致）

面	名乗り	根拠
検定 README	「Playground と同じ版（参照実装 1.0.12・2026-10-26 追従）」	README.md:52
教本 3 冊	「言語 1.0 準拠〈2026-10-26 追従〉・spec_head: v1.0.12」	textbook/L3.md:3・L2.md:3・L1.md:3
問題 19 問	front matter `spec_head: v1.0.12`、公開ページのメタ行「追従: v1.0.12 ／検証: impl」	全 L/.md:7、`_layouts/default.html:17`、https://exam.kairos-lang.org/L3/001-first-of-month.html の実 HTML
CLI	`--version` → `1.0.12`	本体 impl/package.json:3
本番 Playground	`IMPL_VERSION = '1.0.12'`（画面にも表示＝core.js:337）	`curl https://kairos-lang.org/playground/js/build-info.js`；本番 `core.js` の sha256 は本体リポジトリの `playground/core.js` と同一（89d00b34…）

導線（説明だけで辿れるか）: トップ README → 教本 README → 各教本 → 章末「演習」→ サンプル問題 → 級 README → トップ、の相互リンクは公開サイトで全部 .html に変換されている（トップの内部 href 27 本・教本 L3 の演習リンク・級 README を実 HTML で確認、.md の残存リンクは「Improve this page」の GitHub 編集リンクのみ）。.md 直叩きは 404 だが、ページ内リンクには現れない。

Playground リンク: 教本 3 冊の 18 本すべてを base64url 復号し、復元されるソースが本文の kairos ブロック（行内コメント含む）と同一・f／t が # eval: の範囲と同一であることを確認。Playground の restore()（本体 playground/core.js:391-399）は s／f／t／z を読む実装で、リンクはその形に合う。curl https://kairos-lang.org/playground/ は 200。3 本の例＝textbook/L3.md:39（コメント付き premise・f=2026-01-01・t=2026-04-01）、textbook/L2.md:147（二式・673 バイト）、textbook/L1.md:203（covering 中抜けの shift）。なお「ブラウザで開いて目視」まではしていない（復号と復元コードの静的確認）。

所見

HIGH: なし（期待出力と実物の不一致は 0／版の不一致は 0）。

MEDIUM

⑥-M1 サンプル問題には Playground リンクが 1 本もない——級 README の「Playground で再現できる」が説明だけでは辿れない

どこで: L3/README.md:13-14、L2/README.md:13-14、L1/README.md:14-15（「末尾の「検証」節を…Playground で再現できる」）。実態＝grep -o 'playground/#s=' textbook/*.md | wc -l → 18、L1/*.md L2/*.md L3/*.md → 0。
何が: 学習者は「検証」ブロックを手で貼り、# eval: a..b を自分で from／to に写し替える必要がある（手順はどこにも書かれていない）。教本の例と同じ定義の問題は教本側のリンクで代用できるが、L3-004（評価範囲が教本と違う）・L3-013・L2-003・L2-014 の 4 問は教本に同じ式のリンクが無く、Playground での再現は自力になる。
直し方の案: 各問題の「検証」ブロック直下に教本と同じ「▶ Playground で開く」を 1 行添える（符号化は教本と同じ base64url＋&f=&t=）。最低限、級 README に「# eval: の a..b を Playground の from／to に入れる」の 1 文。

⑥-M2 CLI での再現手順（コマンドの形と --tz Asia/Tokyo）がトップ README の 1 箇所にしかなく、教本・級 README からは辿れない

どこで: README.md:45-47 だけが --tz Asia/Tokyo の注意を持つ。教本の前書き（textbook/L3.md:10-12・L2.md:9・L1.md:9-10）と級 README（L3/README.md:13・L2/README.md:13-14・L1/README.md:14）は「リファレンス実装で再現できる」とだけ書き、リンク先は GitHub リポジトリのトップ（英語）。コマンドの形 kairos list --from … --to … --tz … file は検定側のどこにも無い（grep -n "kairos list\|npx" README.md textbook/*.md L*/README.md → 該当なし）。
再現: 日本以外の既定 tz で --tz を付けないと日粒度の点が前日の時刻付きで出る。
```
$ TZ=UTC node impl/dist/cli.js list --from 2026-07-01 --to 2026-11-01 L2-015.kairos
2026-07-26T15:00
2026-08-24T15:00
2026-09-24T15:00
2026-10-25T15:00
…
```
期待（07-27, 08-25, 09-25, 10-26）と日付が 1 日ずれて見え、L1-011 では註釈区間も 2028-01-01..2028-03-30T15:00 になる。--tz Asia/Tokyo を付ければ UTC 環境でも全問一致する（実測）。2 級は「自分の答えと模範解の出力を見比べる」判定なので、この見え方の差を「自分の式が違う」と誤読し得る。
直し方の案: 教本の前書きと級 README に 1 行＝「CLI は npx kairos-lang list --from a --to b --tz Asia/Tokyo 定義.kairos（# eval: a..b の a・b を入れる。tz は必ず付ける）」。なお # eval: 行をファイルに残したままでも CLI はコメントとして通る（実測・rc=0）ので「行を消せ」は不要。

⑥-M3 問題ページの中で検証の日付と版が二重になっている（ヘッダ＝v1.0.12・2026-10-26／本文＝7〜8 月の「公開 HEAD」）

どこで: 解説末尾の「impl 実走検証済み（2026-07-28・公開 HEAD 46a7730）」の類が 13 問（L3/001:41、L3/004:36、L3/011:40、L3/013:42、L2/003:27-28、L2/009:32、L2/011:32、L2/013:32、L2/014:48、L2/015:50、L1/011:47、L1/012:47、L1/015:50）。同じページの上部メタ行は「追従: v1.0.12 ／検証: impl」、トップ README は「2026-10-26 追従」。
何が: 採点者・学習者の目には「どの版で検証したのか」が二通りに読める（46a7730 等がどのリポジトリのコミットかも書かれていない）。今回の実測では v1.0.12 で全問一致しているので実害は無いが、次に出力が変わる版が来たとき、本文の古い日付が「検証済み」の根拠として残り続ける。
直し方の案: 本文の日付・HEAD は落とし、検証の事実は front matter（spec_head／verified）とページのメタ行に一本化する。残すなら「v1.0.12 で再検証（2026-10-26）」に揃える。

LOW

⑥-L1 解説に内部台帳の番号（F7・F11・F98・F66・I4）と ADR 番号がリンク無しで出る

どこで: L3/001:40「窓相対＝I4」、L2/009:29「保証済み＝F7」、L2/013:29「言語の宿題＝F11」、L1/002:44「ADR-45＝F98」、L3/007:27「ADR-43＝F66 (a)」、L2/013:31「ADR-53」。
何が: F 番号は公開仕様に索引が無く（F7・F11 は spec に 0 件、reference に各 1 件、F98 は spec/CHANGELOG のみ）、ADR は https://kairos-lang.org/design/ は 200 だが個別 URL は問題に書かれていない。学習者には辿れない記号で、3 級の問題（L3-001・L3-007）では特に重い。
直し方の案: 解説からは台帳番号を外す（§ と reference のリンクで足りる）か、design/ の索引へ 1 本リンクする。

⑥-L2 L2-003 の spec_refs「§7.2」は別の定番形（第 2 営業日の次の金曜）

どこで: L2/003-second-friday.md:6 spec_refs: [… "§7.2"]。本体 spec/90-examples.md:22「## 7.2 毎月第 2 営業日の次の金曜」（businessDays |> within(month) |> nth(2) |> nextWeekday(Fri)）。
何が: 「第 2 金曜」の根拠を §7.2 に求めた学習者は別の式を読むことになる（filter → within → nth の順序という共通点はあるが、本文で触れていない）。
直し方の案: 「§7.2（nth の前に絞る点が同型）」と添えるか、reference/nth.md に差し替える。

⑥-L3 boot 作法の例日 2026-08-02 が「執筆日」であることが書かれていない

どこで: L1/002-empty-table.md:50-51「[] covering: 2026-08-02..2026-08-02 級」、textbook/L1.md:75（同じ日付で実走・残走路 -161 日）。
何が: 本文は「観測日当日のみの最小主張」と言うが、2026-10-26 に読む学習者には 8 月 2 日が何の日か分からない（教材の作成日と推測される——推測）。
直し方の案: 「（例では執筆日 2026-08-02 を観測日とした）」の一句。

良かった点

抜き取り 10 問＋追加 4 問＋別解 2 本＋教本だけの例 7 本の計 23 本が、点の行だけでなく # 0 点・# ⚠ 範囲外・# 被覆サマリ・残走路の数字・字句エラー／供給エラーの文言まで v1.0.12 の CLI と全行一致した。1 級の「空の三分岐」（L1-015）のように註釈の有無が答えそのものである問題でも、教材の text ブロックがそのまま採点基準に使える。
版の一本化が実際に成立している: 検定 README・教本・全問題の front matter・CLI・本番 Playground の build-info.js がすべて 1.0.12 を指し、本番 Playground の core.js は本体リポジトリと sha256 まで同一。Playground は版を画面に出す（core.js:337）ので、学習者が「同じ版か」を自分で確かめられる。
教本の 18 本の Playground リンクは、復号すると本文の kairos ブロックと行内コメントまで同一で、評価範囲も # eval: と一致している。教本 L1 第 2 章の horizon-clip 警告文の引用が実装の出力と一字一句同じだった点も、教材が実走で保たれている証拠として印象に残った。
公開サイトの相互リンクは .md → .html の変換漏れが無く、404 ページからも教本・級 README に戻れる。

処置の記録（kairos-project・2026-10-26〜）

（裏取りと処置は下に追記する。番号は所見の番号。公開面の修正は main＝1.0.12 の文書同期、評価器に関わるものは rc-1.1＝1.1.0。）

裏取り

HIGH 3 件と MEDIUM 21 件は、所見の再現コマンドを当方でも走らせて確かめた（①-H1＝README.ja の冒頭例は CLI で静的エラー・差し替え後は 12 点／③-H1＝month(13) は 0 点で通る／④-H1＝en の (l) 節が現在形）。テスト数（880）・リンク（261＋41）・検定 10 問の実測は所見のとおり。

処置（公開面＝main の文書同期・1.0.12）

番号	処置
①-H1	README.ja の冒頭例を自己完結形（2026 年の祝日表＋`bizDay` 導出）に＝CLI で 12 点。README のコードブロックの doctest 化は見送り（README は例示の層＝```text・同じ内容は Playground の例で担保）
①-M1・M2	クイックスタート直下に「出力の読み方」4 行（範囲外・残走路・window-clip・`--tz`）を日英で
①-M3	全レシピ（日英 18 本）の最初の kairos ブロックの前に「`@JP` は doctest の標準前提＝Playground リンクの前提込みの形を使う」の注記
①-M4	README.md の付録 A のリンクを英訳（`en/spec/60`）＋日本語に
①-M5	記録のみ＝npm の kairos-lang-mcp 1.0.12 は公開時点の `^1.0.11`。HEAD の `^1.0.12` は次の公開（1.1.0）で揃う（runbook のゲート）
②-M1・③-M3	「本体式の字面に現れる束縛名だけを数える（中間の束縛・値関数の中は辿らない）」を impl/README・CHANGELOG 追補 29・schema の description に明文化。`--help` の文言は 1.1.0（rc-1.1）
②-M2	`.ics` の題「名前 · 式 · ラベル」（式が複数）を impl/README と CHANGELOG に
②-M3	Excel 対照レシピ日英＝`label` 列は「ラベル付きの束縛（`labels:` の表・`weekday` などの cycle）」
③-H1	spec §4.9 日英の例を `lunarMonth(13)` に差し替え、「標準の `month`／`year` は計算ラベル＝域外は空」の 1 文を §4.9・用語集 6.4・stdlib/gregorian §2（日英）に
③-M1	spec §4.3 日英＝「`of:` で名指した窓が連鎖に無いときは静的エラー（既定は常に最内窓＝曖昧は生じない）」
③-M2	reference/roll 日英・spec §4.4 日英の `Modified` に「参照実装 1.0.12 では未実装」の注記
③-M4	reference/nth 日英の「I15」→「空は正当＝ADR-15」
④-H1	en の 40-examples/11 (l) を日本語（ADR-50 で標準化・当時の書き方）の訳に
④-M1	en/reference/take の Related に ADR-52
④-M2	見送り＝日本語の spec/README にも recipes／skills は無い（ミラーの差ではなく索引の設計。入口は README 日英と llms.txt）
④-M3	doc-consistency のフェンス同一性検査に `en/skills/kairos-authoring/` を追加
④-M4	en 40-examples/README に「Notation conventions」節
⑤-M1	Playground の payday／monthend3（日英）を `window: 120`（選んだ日から 120 日）に。MAINTENANCE に補足
⑤-M2	README 日英・impl/README の「プロトタイプ」を外した（1.1.0 の文言を前倒し。診断文の語は 1.1.0 で）
⑥-M1	見送り（記録）＝問題ページの Playground リンクは生成器（playground-links.mjs）を問題にも広げる作業＝次の追従で
⑥-M2	教本 3 冊の前書きと級 README に CLI の再現手順（`--tz Asia/Tokyo` 必須）
⑥-M3	公開問題の本文の日付・HEAD の二重記述を落とし front matter（spec_head／verified）に一本化（bank 30 問）
LOW 41	今回は見送り。妥当なもの（①-L5 Windows exe の導入節・③-L4 impl/README の概要行・③-L7 nth の例の見出しなど）は次の文書同期で順次

検査＝doc-consistency・doctest・全スイート 880（publish.sh のゲート）・検定 verify（108 問＋教本 18 例全問 PASS）。

Kairos ドキュメントレビュー（第14回）— 1.0.12

0. 総評（統合＝当方）

実測サマリ（統合）

観点① 新規読者の導線（＋テスト数の突合）

実測サマリ

HIGH

①-H1 日本語 README の最初のコード例が、CLI・MCP・Playground のどれでも実行できない

MEDIUM

①-M1 クイックスタートの実出力に、README に説明のない警告・註釈・負の残走路が出る

①-M2 README の hero 例を README どおりに CLI で走らせると、日付ではなく時刻付きで出る（--tz の案内が README に無い）

①-M3 レシピ本文の最初の kairos ブロックは、貼っても動かない（@JP の標準前提は doctest 専用）

①-M4 README（英）は付録 A を「(Japanese)」として日本語ページにリンクするが、英訳が存在する

①-M5 公開済み kairos-lang-mcp@1.0.12 の依存は kairos-lang: ^1.0.11、リポジトリ HEAD は ^1.0.12

LOW

①-L1 「reference CLI 1.0.5」「1.0.2」の実物引用は 1.0.12 でも同文だが、版の表記が古い

①-L2 npm 配布の CLI でも --help の 1 行目が「kairos ＝ node src/cli.ts」・例ファイルの実行コメントも開発路

①-L3 npm の kairos-lang@1.0.12 の README はテスト数 862、リポジトリ HEAD は 880

①-L4 playground/ に README が無く、GitHub 上でレシピの Playground リンクを踏むとソース一覧になる

①-L5 Windows 単体 exe（Release 資産）が README の導入節に無い

良かった点

観点② 1.0.12 の新しい面の実走検証

実測サマリ

所見

②-M1 「本体式が参照するラベル付き束縛」の数え方は字面の直接参照であり、中間束縛を経由すると付かない——文書に書かれていない

②-M2 .ics の題は式が複数のファイルでは「名前 · 式 · ラベル」になる——README の --ics 節は「名前 · ラベル」としか書かない

②-M3 Excel 対照レシピは label 列を「ラベル付きの表（labels:）を 1 つ参照するとき」と書くが、cycle も数える

②-L1 .ics の X-KAIROS-LABEL は市民日のラベルで、1.0.12 の「ラベル」（結果の出口のラベル）と語が衝突する

②-L2 地平線不足の next に残る window-clip の助言「範囲を広げて評価する」は、next では --horizon を指す

良かった点

観点③ 仕様の内部矛盾

実測サマリ

HIGH

③-H1 窓インスタンス参照の「域外の値引数は静的エラー」の例 month(2020) が、実物では黙って空になる

MEDIUM

③-M1 §4.3「曖昧なまま of: を省くのは静的エラー」に対応する形が無く、他の文書は「既定は最内窓」としか書かない

③-M2 Modified ロール規約は spec・reference で通常の規約として説明され、参照実装では未実装——reference/roll.md に注記が無い

③-M3 出口のラベル labels の「本体式が参照するラベル付き束縛」の「参照」の範囲が未定義——字面に現れる名前だけを数える

③-M4 reference/nth.md:37 の「正当な空（I15）」——仕様の不変条件は I1〜I8 までで I15 は存在しない

LOW

③-L1 単独時刻リテラルの形の記述が 3 通り

③-L2 不正形の時刻字句の「誘導つき」の範囲

③-L3 残走路の定義の言い回し（付録 B）が、付録 A が「1 日ずれる」と戒めた形

③-L4 impl/README の CLI 概要行が --help と合わない

③-L5 takeLast の horizon-clip 文言「n 個中 k 個のみ」は下限側だけ

③-L6 用語集 6.5 の anchor: の説明が cycle だけ

③-L7 reference/nth.md:36-45 の「第 2 月曜も同形:」の直後の例が第 2 営業日

③-L8 epoch: の上書きを勧める箇所に参照実装の制約の参照が無い

良かった点

観点④ 英語ミラーの意味ズレ

実測サマリ

HIGH

④-H1 hour 窓を「Gregorian 標準に無い」と現在形で断言（日本語は「当時は無かった→ADR-50 で標準化」）

MEDIUM

④-M1 take の「関連」から ADR-52 が落ちている（本文は双方とも ADR-52 に言及）

④-M2 英語の索引ページ（en/README.md・en/spec/README.md）に recipes と skills が無い

④-M3 「コードブロックの乖離も機械検査で止まる」という説明と、検査の対象範囲が食い違う（en/skills が同一性検査の外）

④-M4 en/design/40-examples/README.md は「記法の規約」節と 2 文が無く、「Translated from」の体裁と合っていない

LOW

④-L1 「在圏」が in-scope と resident に割れる

④-L2 「還流第 N 便」「実装系還流」の訳が 4 通り

④-L3 「発報層」が同一ページ内で firing layer と alerting-layer

④-L4 「利用側」の訳が user side／caller／consumer

④-L5 「前文メンバー」が preamble member と premise members

④-L6 「十二支」が “the sexagenary cycle”（六十干支）

④-L7 「覆域」が takeLast だけ covering

④-L8 「先頭点」が span.md の 1 箇所だけ head instant

④-L9 stdlib 内の訳語の揺れ 3 組

④-L10 「出所」と「出自」が provenance／source／origin に跨がる

④-L11 用語集冒頭の「CHANGELOG 追補 11」参照が英語に無い

④-L12 takeLast の「ADR-49 判断 6」が “the ADR-49 deferral”

④-L13 ordinalIn の条件が「単位幅の整数倍」から「時間の整数」に狭まる

④-L14 windows-admin の小さな欠落 3 点

④-L15 イースターの定義文の精度差（英語の方が正確）

④-L16 段落・箇条の配置が違う（内容は同一）3 件

④-L17 source_sha の意味は伝わるが、読者が自分で確かめる手がかりが無い

④-L18 その他の訳語・見出しの揺れ（まとめ）

参考（日英の差ではないが、読み合わせで見えたもの）

良かった点

観点⑤ 鮮度と陳腐化

実測サマリ

①-M2 README の hero 例を README どおりに CLI で走らせると、日付ではなく時刻付きで出る（`--tz` の案内が README に無い）

①-M3 レシピ本文の最初の `kairos` ブロックは、貼っても動かない（`@JP` の標準前提は doctest 専用）

①-M5 公開済み kairos-lang-mcp@1.0.12 の依存は `kairos-lang: ^1.0.11`、リポジトリ HEAD は `^1.0.12`

①-L2 npm 配布の CLI でも `--help` の 1 行目が「kairos ＝ node src/cli.ts」・例ファイルの実行コメントも開発路

①-L4 `playground/` に README が無く、GitHub 上でレシピの Playground リンクを踏むとソース一覧になる

②-M2 `.ics` の題は式が複数のファイルでは「名前 · 式 · ラベル」になる——README の `--ics` 節は「名前 · ラベル」としか書かない

②-M3 Excel 対照レシピは `label` 列を「ラベル付きの表（`labels:`）を 1 つ参照するとき」と書くが、`cycle` も数える

②-L1 `.ics` の `X-KAIROS-LABEL` は市民日のラベルで、1.0.12 の「ラベル」（結果の出口のラベル）と語が衝突する

②-L2 地平線不足の `next` に残る `window-clip` の助言「範囲を広げて評価する」は、`next` では `--horizon` を指す

③-H1 窓インスタンス参照の「域外の値引数は静的エラー」の例 `month(2020)` が、実物では黙って空になる

③-M1 §4.3「曖昧なまま `of:` を省くのは静的エラー」に対応する形が無く、他の文書は「既定は最内窓」としか書かない

③-M2 `Modified` ロール規約は spec・reference で通常の規約として説明され、参照実装では未実装——reference/roll.md に注記が無い

③-M3 出口のラベル `labels` の「本体式が参照するラベル付き束縛」の「参照」の範囲が未定義——字面に現れる名前だけを数える

③-M4 `reference/nth.md:37` の「正当な空（I15）」——仕様の不変条件は I1〜I8 までで I15 は存在しない

③-L4 impl/README の CLI 概要行が `--help` と合わない

③-L5 `takeLast` の horizon-clip 文言「n 個中 k 個のみ」は下限側だけ

③-L6 用語集 6.5 の `anchor:` の説明が `cycle` だけ

③-L7 `reference/nth.md:36-45` の「第 2 月曜も同形:」の直後の例が第 2 営業日

③-L8 `epoch:` の上書きを勧める箇所に参照実装の制約の参照が無い

④-H1 `hour` 窓を「Gregorian 標準に無い」と現在形で断言（日本語は「当時は無かった→ADR-50 で標準化」）

④-M1 `take` の「関連」から ADR-52 が落ちている（本文は双方とも ADR-52 に言及）

④-L17 `source_sha` の意味は伝わるが、読者が自分で確かめる手がかりが無い