日本語 · English（未訳）

Kairos 言語仕様 — RC 履歴

リリース候補（RC）宣言ごとの差分と追補の記録。README（最新ステータス） の前段から移した 当時の記録（追記型・古い順）で、旧仮称や当時の宿題表記はそのまま残す。現況の正本は spec 本文・ 命名の確定状況は §5.4・宿題は ../design/90-open-questions.md。

RC1 → RC2（2026-07-07）

通読レビューで ADR-29/30 の反映漏れと章間齟齬を修正（EBNF へ labels: を追補、前文を独立文とするスコープの EBNF 修正、高階関数の記述修正ほか）、射影一族ほか六語の命名確定、宿題の分類再確認（DoD）。

RC2 追補（2026-07-07）

リファレンス実装（../impl/）の綻び F43〜F50 を解消——例の不整合修正（F45〜F48）と ADR-31（grid の 既定整列＋anchor:・紀元 epoch:・stride 一族の from: 必須化）・ADR-32（文字列リテラル。 tz: "Asia/Tokyo"）。

RC2 → RC3（2026-07-08）

頻出しながら未定義だった土台の明文化と、最後の未確定機構の確定。受理の締め 2 件（23:59:60 は字句エラー・DST の隙間と重複に落ちる時刻リテラルは明示エラー）。ADR-30/31 に改訂節。標準 premise は 4 本。

ADR-33（TZ の定義）＝射影パラメータモデル

• 基底 chronos は TZ 非依存。TZ は市民座標への版付き写像で、「錨」は射影に付く。
• 市民日は「その日付になる最初の瞬間」からの半開区間。
• chronos はうるう秒を持たない一様な理想化軸。UTC の各日を 86,400 秒と数える（23:59:60 は字句エラー）。
• DST の隙間・重複に落ちる時刻リテラルは明示エラー。解決規約は将来の opt-in。
• 紀元の tz 相対性を明文化。

ADR-34（label: 付与式の束縛規則）

• ラムダは窓の先頭点を受ける。
• 意味論は定義的等式「名前(d) ≡ 付与式(先頭点)」（射影時・遅延評価）。
• 点±幅算術は導入しない。

あわせて

• ADR-30/31 に改訂節。「別点の窓参照」の精密化・データ由来窓の epochOrdinal は存在する最初の窓が 0（F60）・div/mod の負数は floor（F63）。
• 用語集に TZ の項を新設。§3.6 の「うるう秒で 23〜25 時間」の誤記を修正。
• 標準 premise は 4 本に拡充済み（../stdlib/——Fiscal・ISOWeek・Kyureki と暦座標糖衣）。ISO 週番号が label: なしの確定語彙で書ける発見 F57 を含む。

RC3 → RC4（2026-07-08）

最後まで残っていた二つの継続項目の確定。新構文はゼロ（ADR-35）。整列の静的検査を導入（ADR-36）。参照実装は実体・標準導出・整列検査まで追随し 147 テスト全通過（doctest の標準前提も実体経由）。新出の宿題は F67〜F70（../design/40-examples/90-findings.md）。

ADR-35（カレンダー実体の宣言・§3.9 新設）

• calendar: に立てる実体は、予約公開語 nonWorking（仮称）を持つ premise。新構文ゼロ。
• 正体判定（ADR-19 の延長）は nonWorking の day 整列と tz: 宣言（内側固定の執行点）まで要求する。
• bizDay は言語規定の標準導出（calendar: 在圏の予約名）。
• 軸位置の premise 名（on: TSE）は正体判定＋標準導出への読み替え（F53 解消）。
• 修飾ピンの member 解決規則（定義側優先）を明文化。

ADR-36（結合子・軸所属の粒度整合・§4.5）

• 整列（alignment）の静的検査を導入（F56/F54 解消）。
• 整列＝「全点が原子グリッド G（幅・正規化位相・tz 名）の目盛り上」という導出構造からの主張。
• &/\/filter(on:)/roll(on:)/shift(unit: 点列軸)/stride は両辺同一 G を要求。黙って空振りする形を静的エラーに。
• snapTo が明示の再整列。和 | は不問（混合スケジュール保護）。
• tz 名はリテラル文字列の等値。

あわせて

• ADR-05 に注記（整列は型でなく静的性質）。I8 の字面に結合子を追補。
• glossary に整列／カレンダー実体／nonWorking／bizDay を追加。reference に nonWorking.md を新設。

RC4 → RC5（2026-07-08）

評価註釈（I6・ADR-15）の初めての具体化（F61 解消）。EBNF に covering-list と束縛後置を追加。参照実装は註釈の区間輸送・包含検査・分類器・被覆サマリまで追随し 188 テスト全通過。

ADR-37（範囲外出自と covering: の活性化）

• covering: は「範囲内は完全・範囲外は未知」の二面の主張。値には触れない。
• 列の全要素の包含は静的検査。当初案の clip は敵対検証の致命反例で却下。
• 範囲外出自は結果に並走する区間註釈〔[a,b)・種・源・covering・asof〕。
• 相殺は自動でなく明示の被覆主張（束縛後置 covering:）のみ。
• エラーの分類器＝実効被覆域。外なら「落として註釈」、内なら従来どおり硬エラー。

輸送表（§4.10 新設）

• 伝播は core 全演算子の輸送表で定める。
• 結合子は和・shift は平行移動像・roll は依存像・選択子は窓拡幅・stride は位相汚染。
• segmentBy の edges: 発火は覆域端＝実効被覆域。

器と covering の表現域

• 器は二つ。評価範囲にクリップする区間註釈と、クリップしない被覆サマリ（源・covering・asof・完結主張・残走路）。
• covering の表現域を拡張。開端（2021..・..＝完結主張・統治つき）と区間リスト（中抜けの申告）。

あわせて

• ADR-15/26 に改訂節（空の出自→区間の出自）。I6 の字面更新。
• EBNF（covering-list・束縛後置）。glossary 5 項追加。
• bizDay 標準導出の「データの尽きた先の黙った退化」（ADR-35 判断 3）が退化するが観測可能になる。
• 実装検証で判断 5 の必要条件検査を精密化（ADR-37 改訂）。判断 1 の tz: 必須の執行のみ宿題。

RC5 追補 1（2026-07-08）——所属の意味論の縁の確定

F68・F70 解消。ADR-38。述語 coincides を新設し、stride のシグネチャから軸引数を削除（入力相対）。ADR-37 判断 4 の filter 輸送行を精密化。

(a) 窓所属の述語 coincides(S, w, d)（§4.9 射影一族）

• 仮称三語目。値式の有界存在量化。
• 時刻付き・混合スケジュールへの例外日適用の受け皿（filter(t => not coincides(closures, day, t))——発火時刻を保存して「日」で除く）。
• 確定は証人規則。真＝非註釈区間の証人のみ・偽＝窓が実効被覆域内。
• S の市民時 tz と w の tz 名の不一致は静的エラー（クロス tz の裏口封じ）。
• 整列要求は課さない（区間所属＝ADR-36 判断 7 免除系へ）。

(b) stride は入力相対

• 軸引数を削除。n ≥ 1 の整数。from: 以上の最初の入力点が第 0 歩。
• ADR-36 の stride 整列検査は削除。

あわせて

• ADR-37 判断 4 の filter 輸送行を逆像拡幅に精密化（F75——窓越し述語の過小近似の穴）。
• 使い分けの規範「同じ点なら結合子〈snapTo で整合〉・同じ所属なら coincides」を §4.5 とエラー文言に整備。

RC5 追補 2（2026-07-08）——並行リストの結びの確定

F62 解消。ADR-39＝テーブルの labels: を segmentBy 窓列へ一般化。新語ゼロ。ADR-30 に改訂節。

意味論（§4.2）

• 三ラベル源の対称完成——点データ／窓規則／窓データ。
• 読みは束縛名射影。
• 整列は専用の窓列序数。実効被覆域内の先頭マーカー窓が 0。epochOrdinal とは紀元跨ぎで食い違うため相乗りしない。
• 同長性検査＝リスト長 == 覆域基準の窓数。評価範囲非依存＝正確。窓束縛の評価と同時。
• 前提＝マーカー有限・無註釈の単一覆域。

締め

• edges: clip／empties: drop／label: 同居／cycle／gen 語はすべて静的エラー。
• 未知の名前付き引数の黙殺も封止。
• 守るのは長さのみ。中身の照合は doctest・coincides の分担。

あわせて

• ADR-30 に改訂節（適用先一般化・補助束縛パターンの再配置）。

RC5 追補 3（2026-07-08）——日付ラベル保存の再錨と多 TZ の実行検証

F69 解消。ADR-40＝点変換 rebase(to: "tz")（仮称・§4.4）。ADR-36 改訂 2。参照実装は IANA tz を依存ゼロで実装し、多 TZ を実行検証。

rebase（§4.4）

• 日付ラベルを保存して、to tz の同日付の市民日先頭へ写す。
• snapTo＝chronos 所属・rebase＝ラベル対応の二本立てで、ADR-36 の整合手段が完成（TSE×NYSE の共通営業日が書ける）。
• w=day 固定。非存在日付（Pacific/Apia 2011-12-30）は明示エラー。
• 免除系の tz 名検査を同時拡張（ADR-36 改訂 2）。

参照実装

• IANA tz を依存ゼロで実装。
• DST 切替日の 23/25h（ADR-11/12 幅規約の初の実行検証）・premise 相対 day グリッド・tz: 必須の全面執行。

RC5 追補 4（2026-07-09）——営業時間の供給規約と標準導出

F67 本体と F79 の決定。ADR-41＝カレンダー実体の細粒度層（§3.9）。あわせて ADR-31 改訂 2（F81/F83）。

供給規約と標準導出（§3.9）

• 実体の予約公開語の対 sessionOpens/sessionCloses（仮称）。実体 tz の市民座標＝壁時計で宣言・任意・with 継承込みで対判定。
• セッション＝半開区間の和。
• 整合性検査: 結合実効被覆域∩実体化範囲での局所交互・端の切り欠き合法・同時刻対は両点保持。
• 標準導出 bizOpen/bizClose/isOpen（実体相対）。

ADR-31 改訂 2

• 時刻付き anchor:/from: の窓境界: 壁時計ラベル読み・隙間→最初の瞬間・重複→最初。
• shift の経過保存を明文化（F81/F83）。

RC5 追補 5（2026-07-09）——位置依存の名前解釈と窓インスタンス参照

F64/F9 解消。ADR-42。新語彙ゼロ。EBNF は stream-atom の修飾適用形（Gregorian.year(2020)）のみ追補。

適用の型規則（§2.7 新設）

• 名前の解釈は候補集合を出現位置の期待型で絞る。複数残れば曖昧エラー。
• 三面: 軸位置の premise 名〈ADR-35〉・点引数＝束縛名射影〈ADR-34〉・値引数＝窓インスタンス参照。
• dispatch は糖衣展開後・実引数束縛後の引数式の型で分岐。

窓インスタンス参照 W(v)（§4.9）

• 逆像。W(v) ≡ W の要素点列 |> filter(d => W(d) == v)。
• year(2020)＝その年の日々。marineDay & year(2020) の正準形。
• 標準ラベル＝year/month（Gregorian）＋year（Fiscal——上書きはラベルを継承しないため同時付与）。
• ゼロマッチは空。静的に列挙できるラベル値域の域外は静的エラー（month(2020) 級のタイポ封じ）。

RC5 追補 6（2026-07-09）——純命名の一括確定とリテラルの締め

F51・F66/F97。仮称 9 語のうち 8 語を正式名に確定。ADR-43＝リテラルの締め 3 件。

命名の確定

• 仮称 9 語のうち 8 語を正式名に確定。供給の対のみ opens/closes → sessionOpens/sessionCloses に改名（ADR-41 改訂）。
• 残る仮称は shiftBoundary 一語＝1.0 送り継続。

ADR-43（リテラルの締め）

• (a) 日付リテラルの値域は字句エラー。2026-02-30 級を拒否する。実装が黙って 2026-03-02 へロールオーバーしていたサイレント面を封じる。
• (b) 固定オフセット TZ は厳格一意形 "±HH:MM" のみ。ADR-36 の「リテラル字面の等値」が依存する一意性。
• (c) 時点は値型の一員。裸の値束縛 d0 = 2026-05-15 が合法＝F97 解消。ADR-42 の dispatch 表は「点以外の値→インスタンス参照」に精密化。

RC5 追補 7（2026-07-14）——空テーブルリテラル（実装系還流の初便）

ADR-45＝F98 解消。EBNF は変更なし（要素列は既に省略可能——意味論注記のみ改稿）。既存の式の意味は不変（静的エラーだった形の合法化＝追加拡張）。

背景（F98）

• 発報層実装からの第一次還流で出た綻び。「点ゼロだが覆域は主張したい」束縛の一次形が無く、恒偽 filter の回避形が迂遠だった。

空テーブルリテラル

• 空リスト [] は covering: 後置に限り時間ストリーム定数（空テーブル）に昇格する。
• 空形は covering 明示必須。省略既定「列の端」が空列で定義できない。
• labels: [] のみ合法。包含／昇順／同長の各検査は空虚に成立。
• 整列は空虚適合の第三状態（ADR-36 改訂 3）。全整列に適合し検査に通る。結合は相手を継承。

あわせて

• 検証の副産物として roll 空軸の依存像の実装欠陥（F99）を発見・修正。

RC5 追補 8（2026-07-14）——外部供給宣言 external（socket の確定）

ADR-46。宣言語 external を採用（2026-07-14 決定）。EBNF は param-key に kind/source を追加のみ。既存の式の意味は不変（追加拡張）。ADR-26 改訂 3。

背景

• 発報層還流第一次の実測痛点 2 件（静的ソース不可・統治の焼き忘れ）。socket の要否込みで判断し、採用。

設計の核＝実行時に解決されるテーブルリテラル

• 新型・新代数ゼロ。
• リテラルが字面で運ぶ静的性質を宣言（kind:＝整列の主張・labels:＝値域の列挙）が先取りする。
• 解決値に同一の統治検査（covering/asof 必須・包含・昇順・同長・日付の実在）を供給契約として課す。
• premise 束縛の右辺（先頭）限定。
• 解決は評価文脈の随伴。一評価一解決・要求駆動・定義側 premise 単位のスナップショット。
• 解決失敗は供給エラー（機械可読な部分類）。「まだ無い」〈ADR-45〉と型で区別する。

あわせて

• §7.8 の決定性は「同一スナップショット相対」の条件を明記。
• ADR-26 改訂 3（式に埋める／器で受ける、の使い分け確定）。

RC5 追補 9（2026-07-25）——テーブル後置の順序自由化と窓列被覆域の精密化（発報層還流 第 5 便）

第 3 の適用ドメイン（暦×占い）の実運用検証（発報層還流 第 5 便）が炙り出した 2 件。EBNF §5.6 を改訂（受理拡大）。正しく評価できていた式の意味は不変。

テーブルリテラル後置の順序自由化（F104）

• covering:／labels: の後置を順序自由・各一回とする。EBNF §5.6 を { covering | labels } 形に改訂。
• 従来文法は固定順（covering → labels）。実装は逆順の covering: をラベルリストの後置として黙って捨てていた。
• 受理拡大による封じ。二重指定は構文エラー。
• 既存の式の意味は不変（追加拡張）。

窓列の実効被覆域の精密化（F105・ADR-37 改訂 3）

• segmentBy の窓列は「窓の張られた範囲」だけを語る。
• マーカー覆域内でも窓のない区間（edges: drop/error の頭側・empties: drop の中抜け）は窓列由来の範囲外註釈。
• labels 射影・coincides の読みには「落として註釈」で応える。従来は硬エラーで、filter 派生マーカー〔覆域始端 < 最初のマーカー〕で filter 正準形が評価不能だった。
• エラー→註釈の緩和方向のみ。正しく評価できていた式の意味は不変。

RC5 追補 10（2026-07-25）——窓列への周期ラベル labels: cycle（ADR-47）

segmentBy の labels: の値位置に周期形 cycle リスト anchor: 実日 を追加。新語彙ゼロ。EBNF は segment-labels/cycle-labels を追加。既存の式の意味は不変（追加拡張）。

背景

• 発報層還流 第 5 便 §3 の実需。節切り月の十二支・月家九星・月星座など「窓列＝暦の単位・ラベル＝固定周期」の形。
• 候補設計を 4 視点で検証し、3 件の決定（2026-07-25）を経て採用。

意味論

• 窓束縛 cycle と同一「anchor の属する窓が先頭ラベル」＝ list[(i − i₀) mod N]。
• 同長性検査は課さない。covering が伸びても式不変＝ADR-46 静的ソース原則との整合。
• 守るのは位相の宣言のみ。マーカー中途増減・非周期列への誤用は機械検出されない（照合は doctest・coincides の分担）。
• anchor は窓列のいずれかの窓に区間所属。頭側・範囲外は明示エラー。
• 締めは静的 labels: と同一を継承。

あわせて

• named-arg の重複指定を静的エラーに一般化。

RC5 追補 11（2026-07-26）——最後の仮称を rephase に裁定・命名完全確定

窓境界の位相ずらし糖衣の正式名を rephase に確定（旧仮称 shiftBoundary）。2026-07-26 決定。当初「1.0 宣言時」としていた条件 3 を前倒し。意味論・展開・シグネチャは不変（純命名）。これで全語彙が正式名——仮称ゼロ。

根拠（三点）

• (1) 展開の実体（span の phase: 差し替え）と名が一致。rephase(δ, on: W, unit: U) ≡ W = U span (_ => k) phase: ((φ₀+δ) mod k)。
• (2) rebase（点の再錨）・anchor:（位相を留める実日）との re-／錨・位相語彙系の対称。ADR-47 で「位相」が利用者向け語彙に昇格したことが後押し。
• (3) 簡潔（13 字→7 字）。点変換 shift との同語幹回避。

不採用の候補

• shiftBoundary 昇格・shiftPhase・offsetBoundary/moveBoundary。経緯は design/30-syntax/01。
• boundary の語は k 可変組を扱う将来の別演算子（スコープ外）に温存。

置換

• 全コーパス一括置換。spec・reference〈ページ改名 shiftBoundary.md→rephase.md〉・stdlib・impl・図版・英語ミラー。

RC5 追補 12（2026-08-17）——take・split 親受理拡張・hour 窓と整合検査（ADR-48/49/50）

「書けない」実例調査（40-examples/11＝収集 32 項目・実測 17 本）が駆動した三点。参照実装は 552 テスト。

take(n, from:) 新設（ADR-49・§4.7）

• ストライドの数える側の第 3 語＝先頭 N 選択（COUNT 相当）。実需要の初証拠は rrule.js #456。
• 除外後に数えるが合成順で出るため、COUNT の轍を踏まない。
• 輸送表に take 行（stride 同型＋第 n 点確定後の縮小）。
• 窓付き入力は誘導つき静的エラー。
• §1.2 の「できないこと」表から当該行を解消。

split の親受理拡張（ADR-48・§3.6）

• 規則マーカー由来の実効パーティション（glossary 新設）を親・by: に受ける。F109——標準 week 自体が弾かれていた非対称の解消。
• データ由来親・empties: drop・cycle は不受理。
• 境界整合検査を新設。I5 総和はエラーへ昇格。

hour 窓の標準化と ordinalIn 整合検査（ADR-50・§4.9）

• Gregorian に経過 1 時間タイル hour を追加。
• 経過幅単位×市民枠窓の境界不整合を per-instance の明示エラーに。
• 破れの述語は「紀元差」。Kolkata は整列・Singapore/Kathmandu/Lord_Howe が破れの実測。
• ADR-36 判断 7 の免除の精密化。

テスト

• 552 テスト。

RC5 追補 13（2026-08-21）——単独時刻リテラルと at・takeLast（ADR-51/52）

還流第 12 便（供給側の運用報告＝収蔵 13）が駆動した二点。字句に単独時刻リテラル Thh:mm を追加。参照実装は 603 テスト。

補記（2026-08-26・第 11 回レビュー G の補綴）

• 本追補の前日 2026-08-20 に F110＝糖衣定義の循環検出 が入っている。自己・相互再帰を経路つき静的エラーへ。従来は JS 生エラーで落ちていた挙動変更を含む。
• 同時に reference「糖衣定義」ページ新設〈doctest 3 本〉と spec §4.8 の循環明文化。
• 追補相当の変更だが番号を持たず、記録がこの欄から漏れていた。

単独時刻リテラル Thh:mm と stdlib 糖衣 at（ADR-51・§5.5・stdlib §2）

• 「日集合→その日の壁時計 H 時」の正準形（壁時計 tick＋coincides・F76 の受け皿）を最短形にする。
• T 接頭形限定。裸 hh:mm は三項条件と衝突＝互換保持を実測。
• epoch 錨日 1970-01-01。tzdb 悉皆で遷移ゼロ・帯 [紀元, 錨) の欠落ゼロ。
• DST は F81 継承（糖衣は展開先の意味を継承）。
• 供給側の経過算術形（発火点数分の horizon-clip）からの乗り換え先。

takeLast(n, until:) 新設（ADR-52・§4.7）

• ストライドの数える側の第 4 語＝末尾 N 選択（直近 N 発火）。
• ADR-49 判断 6 の見送りを、実需要第 1 号（レシピ発火例・366 日窓の代替運用）を受けて改訂。until: の明示錨が「covering 依存」の却下理由を構造的に解消。
• 輸送は判断 5 の鏡像（条件付き縮小）。
• 実装地平線ガード 2 面（until ≥ 計算範囲・実体化下限）。
• until: は点包含。正道＝数える段は日の層・時刻付与は後。

テスト

• 603 テスト。

RC5 追補 14（2026-08-26）——標準糖衣 at の名指し検査（ADR-51 追記）

還流第 15 便（供給側の追随実装知見 5 件＝収蔵 16・全件を参照実装で再現確認）が駆動。標準語彙 at に展開前の名指し検査を追加（§5.5・stdlib §2）。参照実装は 607 テスト。

問題

• at の展開形は入力を述語として読み直す。入力が運んでいた窓・覆域註釈のかかった点・endless の由来が出力へ引き継がれない。
• うち「利用者が黙って誤結果を得る」2 形を展開前の名指し検査で塞ぐ。

名指し検査（§5.5・stdlib §2）

• (a) 窓付き入力は誘導つき静的エラー。ADR-49 の窓ガードが 1 段で素通りし、通し数えに化ける形。正道＝窓は at の後で切る（外延同値）。
• (c) 引数は単独時刻リテラルに限る。日付つきの錨〈日時・裸日付とも〉は前方専用で、錨より前が黙って空。
• 検査は標準語彙の名の防御。利用側 premise の同名再定義には掛からない（糖衣原理 ADR-23 の例外ではなく展開前の適格性検査）。

規約の内と訂正

• 覆域外の点の at 段での脱落と endless 由来の警告偽陽性は規約の内（糖衣は展開先の意味を継承）。reference の落とし穴へ実測込みで文書化。
• 判断 6 の括弧書き（tick 生成域）は実装事実に合わせ追記で訂正。horizon-clip が出ない論拠は「単位窓列を実体化しない」の側。

テスト

• 607 テスト。

RC5 追補 15（2026-08-26）——束縛右辺の名前解決境界とメモ化の正しさ（ADR-53）

還流第 16 便（供給側のメモ化追随の敵対的レビュー＝収蔵 17・全 9 再現形を参照実装で確認）が駆動。ADR-53。呼び出し側ラムダ変数への捕獲を静的エラーに（§4.8）。参照実装は 617 テスト。

バグ 2 件

• ①右辺が呼び出し側ラムダ変数を掴む束縛で、最初に評価された点（実体化原点 epoch）の値が全点に焼き付く。エラーも警告も無く点集合が変わる。
• ②ADR-40 の tz 名検査が文の並び順・単一文内の整列切替で有効／無効が変わる。

処置 (1) 束縛右辺の名前解決境界（§4.8）

• 束縛右辺の名前解決は「束縛・premise 語・前文メンバー・列挙」で閉じる。
• 呼び出し側ラムダ変数への捕獲は誘導つき静的エラー。点依存は引数付き束縛 T(x) = … で明示。
• 根拠: マクロ捕獲は「定義の意味が使用箇所の変数名に依存する」＝定義単体で読める思想への反。既存コーパスに該当形ゼロの実測。推移形も遮断が根で断つ。
• メモ化はこれで正となる（焼き付きが構造的に不可能に）。

処置 (2) メモ化ヒット時の再検査

• メモ化ヒット時に記録済みの tz 名検査を現在の文脈で再実行（defCache 全 3 経路）。
• 検査の順序独立性と、解決値のクロージャ同一性（labelStack ガードの前提）を両立。
• align をキーに足す案・メモ化スキップ案は、同一性の破れを実測して不採（ADR-53 判断 6）。

テスト

• 617 テスト。

RC5 追補 16（2026-08-28）——ADR-53 の完遂と記録条件の精密化（還流第 17 便）

供給側の ADR-53 追随レビュー（収蔵 19）が駆動。仕様の字面変更なし（§4.8 の明文に実装が追いつく形）。テスト 5 本追加＝623 テスト。

①判断 3 の完遂

• 引数付き束縛の呼び出し経路（evalCall）の遮断漏れを補綴。
• T(x) = dayNo(d) が使用箇所の変数名に依存する形（改名で挙動が変わる・引数無視）が静的エラーに。
• spec §4.8 の明文どおりへ実装が追随。誘導文言も両状況対応へ。

②判断 5 の記録条件の精密化

• tz 名検査の記録を「fromPredicate 明示（predicateAlign 由来の 5 呼び出し元だけ）∧ 束縛評価開始時 align と一致」の二重条件へ。
• 値由来検査の誤記録が生んでいた診断の誤帰属・within 形の偽陽性・右辺内で完結した検査の過剰停止を封止。
• 第 16 便の順序独立 3 形は不変量のまま。

テスト

• 5 本追加＝623 テスト。

追補 16 補綴（同日）——EBNF の棚卸し（第 11 回レビュー LOW・文法凍結前の一度きり）

受理言語の実態は不変＝文法記述の精密化のみ。日英同時。

• ①未定義非終端の補定義。digit/digit2/digit4/digits/letter——参照のみで定義が無かった。
• ②width-literal を実装の受理形へ。旧 elapsed-width は空文字列を導出でき、順序固定が実装〈セグメント 1 回以上の列〉より狭かった。width-seg の 1 回以上繰り返しに統一。civil/elapsed の分類は検査の層と明記。
• ③束縛後置の covering: を引数なし束縛の分岐に限定。実装の静的エラー「被覆主張は引数なしの束縛にのみ付く」と文法を一致。

RC5 追補 17（2026-08-28）——順序独立の完全化: ヒット時再実行の再記録（還流第 18 便）

追補 16 の記録条件精密化が作った退行の修正。供給側の追随レビューが検出し、叩き台 3 行を採用。値は正しく、壊れたのは警告の一貫性。witness 3 本追加＝626 テスト。

退行

• ヒット時再実行の 3 経路が fromPredicate を渡していなかった。
• 間接参照 B = T で内側束縛がキャッシュヒットすると、検査が外側エントリへ伝播しない。
• 先行の単独評価 1 行で危険な文が黙って通る「並び順」依存が再来していた。

修正

• 再実行検査を評価中の外側フレームへ再記録。
• baseAlign 条件は維持＝追補 16 の過剰停止封止と両立。

あわせて

• bizDay 導出経路の別種非対称（align オブジェクト共有の偶然一致）は観測として 90-open-questions に採録（1.0 後の精密化候補）。
• witness 3 本追加＝626 テスト。

RC5 追補 18（2026-08-31）——テストの網の補強: 診断全文の固定と bizDay 経路 witness（還流第 19 便）

受理言語・意味論・診断文言とも不変（テスト側のみ）。供給側の変異試験が検出した 3 件を手当て。627 テスト。ADR-53 追記 4。

検出 3 件と手当て

• ①追補 17 の witness 3 本のうち、単一文内切替形は追補 17 の退行を検出しない。別面の witness と位置づけを明記。
• ②ADR-40 診断の期待値が部分一致で、入力／窓の左右取り違えを内容で捕まえるテストが 0 本だった。全文アンカー固定へ。変異 3 種で 7 本が赤。
• ③defCache 第 3 経路（bizDay 標準導出）の再記録に witness が無かった。間接参照 B = bizDay の witness 1 本追加。

テスト

• 627 テスト。ADR-53 追記 4。

1.0（2026-09-14）——RC5 から 1.0 へ

受理言語・意味論・演算子族・文法（EBNF）・字句を 1.0 として凍結する。RC5（2026-07-08 宣言）から 追補 18（2026-08-31）までの精密化はすべて「受理言語を変えない」制約の下で行われ、本節はそれを版として 封じる宣言である。参照実装は npm kairos-lang 1.0.0（プロトタイプ・実行時依存ゼロ）。以後の変更は 「1.0 追補 N」として本ファイルに追記する（状態行の追補番号検査は同じ網で読み替える）。

1.0 追補 19（2026-09-24）——派生 premise の前文メンバー継承・roll: メンバー・正準例の改名（還流 2026-09-23 の 2 便）

受理言語・字句・文法は不変。参照実装 npm kairos-lang 1.0.2。

派生 premise の前文メンバー継承（ADR-35 改訂 3・spec §3.7）

• premise Mine = Base with { … } を @ の入口にしたとき、本体層が直接引く calendar:・axis:・tz: が Base の宣言を見ず、tz は黙って機械の tz に落ちていた。
• 登録時に基底連鎖のメンバーを継承し、ブロックの宣言が上書きする形に。入口の本体層が見る集合を、公開語の内側が見る集合と同じにする。
• source: も同じ集合。

前文メンバー roll:（spec §3.3）

• 規約の位置引数が無いとき、在圏の roll: に落ちる。明示推奨の但し書きは不変。

正準例の改名（reference/segmentBy.md）

• 補助関数名 monthNo → monthLabelNo。標準 Gregorian の monthNo と同名で衝突し、with 派生では月番号の読み出しが既定枝の値に潰れていた（警告なし）。
• 註記と、label: 形の長さ検査の落とし穴を日英に追加。
• 標準語の再定義への警告は言語側では採らない（design/90-open-questions.md）。

テスト

• witness 9 本。修正を落とすと 6 本が赤（内訳は追補 21 に註記）。657 テスト。

1.0 追補 20（2026-09-29）——strideBy の 0 幅を静的エラーに・CLI の stdout 欠落を修正（レッドチーム監査の指摘 2 件）

受理言語・字句・文法は不変。参照実装 npm kairos-lang 1.0.3。

strideBy の 0 幅は静的エラー（F112）

• strideBy(0s, …)・strideBy(0d, …) は評価が前進せず止まらなかった（実測はタイムアウト）。
• stride(0) の「黙って空」根絶（ADR-38 判断 12）の strideBy 版。診断は「幅は正の量」へ誘導する。

CLI の stdout 欠落（F113）

• stdout をパイプへ流すとき、大きな出力の末尾が欠落していた。入口の process.exit が未送出分を捨てていた（604,800 行中 467,147 行・--json は 65,536 バイトで切れた）。
• process.exitCode に置き換えて排出を待つ。SEA のエントリスタブも同じ。

テスト

• witness 3 本（0s・0d・86,400 点の JSON がパイプ先で完全）。exit に戻すと赤。660 テスト。
• 出所: 2026-09-29 の外部の敵対的レビュー 5 件を実測で検証し、成立した 1 件と検証中に見つけた 1 件を修正。

1.0 追補 21（2026-09-29）——メモ化の文脈キーに前文メンバー全語と在圏 premise を含める・前文メンバーの自己参照を誘導つきエラーに（還流 2026-09-28 定期便）

受理言語・字句・文法は不変。参照実装 npm kairos-lang 1.0.4。

メモ化の文脈キー（F114）

• 公開語・トップ束縛・bizDay／bizOpen の標準導出のメモ化鍵が手書きの 8 語で、granularity: と epoch: を欠いていた。within(granularity) を読む右辺の値が評価順で変わった（@Base の bizDay を先に評価すると @Mine が基底の 27 点を返す。単独なら 24 点）。
• bizDay の鍵に在圏 premise が無く、day を上書きした派生の整列エラーが、基底を先に評価すると消えた。
• 鍵の語を parser の前文メンバー全語（10 語）に揃え、標準導出の鍵に在圏 premise 名を加える。§7.7 の決定性は「同じ定義・同じデータ・同じ範囲」で評価順を含まない。実装の欠陥。

前文メンバーの自己参照（F115）

• roll: roll・axis: axis・相互参照は、名前解決の無限再帰で RangeError になっていた。
• 解決中の値の再入で止め、誘導つきエラーに。spec §3.3 に「前文メンバー名は値にならない」を明文。

文書

• spec §3.7 の前文メンバーの括弧書きを全 10 語に精密化。
• 追補 19 の「修正を落とすと 6 本が赤」の内訳: witness 5 本＋Playground の指紋照合 1 本。継承の 1 行だけを落とすと witness 4 本＋指紋照合 1 本。

テスト

• witness 21 本（評価順の独立 5・自己参照 9・roll: の写経 7）。681 テスト。

1.0 追補 22（2026-09-29）——list の 0 点表示・window-clip 警告・入口の Limits 節（レッドチーム監査の手当て (a)〜(c)）

文法（EBNF）は不変。1.0.4 で評価できる定義の点の集合は 1.0.5 でも変わらない。変わるのは表示と警告、黙って通っていた形がエラーになること、偽エラーだった 2 形（F144・F145）が評価できること。参照実装 npm kairos-lang 1.0.5。

list の 0 点は黙らない

• 単一式の 0 点は stdout に # 0 点（[from, to) に該当なし）（--lang en は # 0 points (nothing in [from, to))）。# 接頭なので機械処理はコメントとして落とせる。
• exit 0 は不変（空は正当な結果。next の exit 2 とは別）。複数式の見出し行と --json は不変。
• Playground も同じ行を出す。表示は CLI の list と行単位で同じ。

window-clip 警告

• 評価範囲 [from, to) の内側の点が roll・shift・snapTo で外側へ動くと、その点は出力に含まれない（§7.8 の切り取り）。旧実装は黙って 0 点にしていた。
• warnings に window-clip: roll(Preceding) 2026-08-01 → 2026-07-31（…） を積む。from 側・to 側とも。実体化地平線の horizon-clip とは別。
• spec §7.8 と reference の roll／shift／snapTo の落とし穴に明文（日英）。

入口の Limits 節

• llms.txt と README（日英）に「しないこと」を集約: 先発グレゴリオの理想化・うるう秒なし・年 4 桁・DST は壁時計保存・参照実装は 1970 以降と to+400 日・点数上限なし・射程外。正本は spec の各節。

境界チェックリストで見つかった 31 件（F116〜F146）

• 出所: 機械的実測の一巡目 135 件・二巡目 110 件・三巡目 137 件（design/60-reviews/2026-09-29-boundary-checklist.md）、Playground 評価器との差分 317 件、--json の不変条件 30 本、Playground の UI 層 64 項目。
• 統治外エラー 1 件: F116 shift の非整数 n。
• 黙って通っていた形をエラーに 21 件: F117 評価範囲の逆順・F118 tz: ""・F120 nth(0) など・F121 年 5 桁・F122 前文メンバーの二重宣言・F123 premise の同名再定義・F124 型の違う等値比較・F125 0 除算・F126 本体式の無いファイル・F127〜F129 span／split／phase: の非整数・F130 chronos grid 0d・F131 入れ子 200 段・F132／F133 ラムダと射影の引数の個数・F134 束縛の再定義・F135 cycle の空ラベル列・F138 市民日の幅の小数・F139 ms 未満の幅・F141 covering: の年の桁。
• 読み飛ばし・資源・契約 7 件: F119 先頭の BOM・F136 covering: の個数・F137 点数の実体化は診断つきで止まる・F140 表せない instants・F142 入力ファイルの文字コード・F143 解決子の戻り値・F146 Playground の「URL に固定」。
• 偽エラーの解消 2 件: F144 市民日への snapTo は計算範囲の先の点も日の先頭へ寄せる（segmentBy(labels:) の偽エラー）・F145 empties: error は実体化範囲の窓だけを判定。
• 各件の内容と処置: design/40-examples/90-findings.md。

文言

• 未解決の名前に原因を添える・CLI の引数の誤りは日本語（--lang en は原文）・--help は終了 0・見えない文字と引用符の「不明な文字」に符号位置と直し方・診断の長さは 2,000 字で切る。

テスト

• witness 49 本（0 点表示 4・window-clip 7・shift 整数 3・境界 10・二巡目 9・三巡目 14・地平線 1・Playground 1）。730 テスト。

1.0 追補 23（2026-10-01〜06）——覆域端で閉じた最終窓の終端は未確定（ADR-37 改訂 6）・機械可読の契約（JSON Schema・source/line・エラー JSON・--explain・表示形の一意性）

点集合は不変（註釈の追加と出力形式の追加のみ）。参照実装 npm kairos-lang 1.0.6。

覆域端で閉じた最終窓の終端は未確定（ADR-37 改訂 6）

• データ由来の窓列（朔で切る旧暦など）の最終窓は覆域端まで張る（F72）が、その終端は次のマーカー（覆域外）に依存する。旧実装は lunarMonth |> last が覆域の最終日を註釈なしで「月末」として返していた。
• 終端を読む段（last・要素の足りない nth・既知部分が空の first／nth・証人の無い coincides）は最終窓を覆域端の註釈区間に接するものとして扱い、窓全域に註釈を添える。coincides は偽と確定せず範囲外。始端と所属を読む段は従来どおり。
• 計算範囲で切れた形は実装地平線の領分のまま。
• spec §4.9／§4.10・reference（segmentBy・last・nth・first・coincides）・stdlib/kyureki.md §7 に明文（日英）。spec §4.8 に「糖衣は展開先の意味を継承する」を明文。

機械可読の契約（2026-10-05〜06 決定）

• JSON Schema 2 本: schema/cli-report.schema.json（--json の出力）と schema/supply.schema.json（--supply の入力）。draft 2020-12・後方互換の改訂のみ。witness は ajv（devDependency・実行時依存ゼロは不変）。
• results[].source に式の字面と line（1 起点の行番号）。
• --json のエラーは stdout に JSON（{command, version, error: {kind, message}}）。終了コード 1 は不変。
• --explain: 各段の後の点数・先頭と末尾・交差する窓数・註釈数を # explain: 行（--json では results[].stages）に出す。
• 表示形の一意性: 秒未満は ms が 0 でないときだけ .SSS。DST の重複はオフセット ±HH:MM を添える。dates は points と一対一。
• spec §3.8 に「asof は版の識別子＝同一性比較のみ・順序を読まない」を明文。供給 JSON の asof は任意の非空文字列。
• next の探索窓は 7 日から倍々（旧: 1 年から）。1 秒刻みの列は依然重い（design/90-open-questions.md 2-4）。
• Playground: 本体式の無い定義に CLI と同じ 1 行を出す。画面の下に参照実装の版と指紋。

テスト

• 最終窓の witness 8 本と契約の witness 25 本（Schema 7・source/line 2・explain 3・表示形 4・エラー JSON 5・next 3・Playground 1）。変異 3 系統で赤を実測。763 テスト。
• 詳細: impl/README.md の --json・--explain の節と schema の説明文。

1.0 追補 24（2026-10-06）——.ics 書き出し（CLI --ics・Playground「カレンダーに入れる」）と暮らしの例の導線

言語は不変（文法・意味論・spec の本文に変更なし）。参照実装 npm kairos-lang 1.0.7。

--ics（list／next・--json と排他）

• 評価結果を iCalendar（RFC 5545）に展開する。1 点＝1 VEVENT。日粒度の点は終日（DTSTART;VALUE=DATE）。時刻付きの点は UTC の瞬間の 0 分の予定（DTEND＝DTSTART）に VALARM（TRIGGER:PT0M）。
• 予定 0 件なら何も書かず stderr に知らせて終了コード 2。予定は TRANSP:TRANSPARENT。--explain は出ない。
• --ics-series: 1 式 1 つの繰り返し予定（DTSTART＋RDATE）。削除は「すべての予定」の 1 回。RDATE を読まないアプリでは初回だけになる（追補 25）。
• 区間註釈は終日の予定として載る（表の外は黙らない＝ADR-37 判断 5 の写像）。
• RRULE は書かない。展開点列のみで、規則の近似を出さない。
• 決定性: DTSTAMP は各予定の DTSTART。UID は式の字面・順番・tz・点から決まる（FNV-1a 64）。時計を読まない。
• CRLF・75 オクテット折り返し・TEXT のエスケープ。実装は impl/src/ics.ts（依存ゼロ・CLI と Playground が共有）。
• パッケージは kairos-lang/cli（CLI のコマンド関数と CliReport の型）を公開。埋め込み用。

Playground「カレンダーに入れる（.ics）」（日英）

• 同じ関数でブラウザ内に作って保存する（送信なし）。予定 0 件なら作らない。既定は series（スマホの既定は追補 25 で改定）。

暮らしの例

• Playground の例の先頭に「暮らしの例（そのままカレンダーに入れられる）」の群: 資源ごみ（第 1・第 3 水曜）・給料日（15 日と月末・休日なら前営業日）・目覚まし（平日 6:30・土曜と祝日 8:00・評価範囲は選んだ日から 4 週間）。英語版は米国連邦祝日と America/New_York。
• 式を読まずに「例を選ぶ→カレンダーに入れる」で使える最短経路。既存 5 本は「業務の例」の群へ。

テスト

• witness 15 本と公開前レビューの 4 本。変異 4 系統で赤を実測。778 テスト。
• 詳細: impl/README.md の --ics の節。

1.0 追補 25（2026-10-08）——.ics の実機知見（Google カレンダー）: 折り返しの堅牢化・同じ UID の取り込み直しは更新・スマホの Google カレンダーアプリでは「1 点ずつ」が既定

言語は不変。参照実装 npm kairos-lang 1.0.8。1.0.7 公開直後の実機取り込み（PC の Google カレンダー Web と Android のアプリ・2026-10-08）の反映。

折り返しの堅牢化

• 75 オクテットの折り返しで、エスケープ列（\ と次の文字）を別の物理行に分けない。RFC 5545 §3.1 では任意の位置で折り返せるが、取り込み側の堅牢性のため。

同じ UID の取り込み直しは「更新」

• series で期間を延ばしたファイルを取り込み直すと、回が追加され重複しない。削除後の取り込み直しも通る。1.0.7 の「丸ごと置き換わる」をこの表現に改める。

スマホの Google カレンダーアプリは RDATE を読まない

• series は初回の 1 回だけの単発予定になる。その後は同じ UID の繰り返し予定を PC からも取り込めなくなる。
• 「1 点ずつ別の予定にする」は PC でもスマホでも全件入る。
• Playground の既定: スマホ（タッチ主体のポインタか幅 700px 未満）では「1 点ずつ」、PC では series（2026-10-08 決定）。説明文に注意書き（日英）。

文書とテスト

• impl/README・Playground 日英・llms.txt・1.0.7 の Release 本文を訂正。
• witness 1 本（スマホの既定）と、折り返しの境界 3 形と全行検査を既存 witness に追加。779 テスト。

1.0 追補 26（2026-10-10）——--json の results[].uid・Playground の例の祝日表を 2027 年まで

言語は不変。参照実装 npm kairos-lang 1.0.9。

--json に results[].uid（2026-10-08 決定）

• 式ごとの指紋。FNV-1a 64 の 12 桁 hex を kairos-<指紋>-series@kairos-lang.org の形で返す。
• 鍵は results 内の順番・式の字面・報告の tz。--ics-series が書く繰り返し予定の UID と同じ値。
• 1 点 1 予定（--ics）の UID は -series@ を -<ms>@ に。区間註釈の予定は -ann-<fromMs>-<toMs>@。
• 用途: .ics を経由しない実装が同じ鍵で予定を更新できる。取り込み側の RDATE／RRULE の解釈に依らない（1.0.8 の実機知見の帰結）。
• 指紋であって同一性ではない。式の字面・順番・tz のどれかを変えれば別の値。アプリは自前の記録 id を正とし、uid は「同じ定義か」の判定に使う。
• JSON Schema schema/cli-report.schema.json に uid（必須）を追加。追加のみで後方互換。additionalProperties: false の厳格な検証器は schema の更新が要る。
• 実装: 鍵の計算は ics.ts の uidKey／seriesUid／pointUid／annotationUid に一本化（.ics の出力は不変）。mcp の報告にも付く。
• 詳細: impl/README.md の --json 節と schema の説明文。

Playground の例の祝日表を 2027 年まで（2026-10-09 決定）

• 対象: 表 7 箇所（暮らしの例の national／federal・業務の例の holidays／federal・cascade の statutory〈祝日のみ〉）を covering: 2026..2027 に。
• 出所: 内閣府「国民の祝日について」の一覧（2026-10-09 取得・休日 3/22 を含む 17 件）と OPM Federal Holidays（observed・11 件）。前文のコメント行に明記。
• 方針: 言語は年で腐るデータを配布しない（2026-10-07 の線引き）。例の表は「例の資産」として毎年延ばす。
• binding 名から年を外した（holidays2026→holidays・federal2026→federal）。
• 表を延ばしても .ics の UID は不変（鍵は式から決まる）。取り込み直しは更新になる。
• 検査: 鮮度の witness（表の終端が「今日＋28 日＋余裕 60 日」より手前なら赤）と内容の witness（2027 年分が出所と一致・名前に年を含めない）。.github/workflows/freshness.yml が毎月 1 日に鮮度を検査。
• CLI の例（impl/examples）は 2026 年の表のまま。表が尽きたときの ⚠ を見せるため。

テスト

• uid の witness 2 本（.ics の 3 形の UID との一致・順番／tz／字面で別・決定性）と schema の必須と形。
• 祝日表の witness 2 本。いずれも変異で赤を実測。
• 公開文書の検査に「露出の上限」を 1 本（2026-10-10）。設計の経緯や発言の引用を公開ツリーに増やさない。
• 784 テスト。

1.0 追補 27（2026-10-16）——CLI --tsv（表形式の書き出し・言語不変）

言語は不変。参照実装 npm kairos-lang 1.0.10。

CLI --tsv（2026-10-12 決定）

• list／next の結果を 1 点 1 行のタブ区切りで stdout に書き出す。--json・--ics・--ics-series と排他（stdout は 1 つの形・同時指定は使い方エラー）。
• 1 行目は見出し行。列は固定順の 7 つ: expr（本体式の番号・1 起点）・source（式の字面・タブ・改行・復帰は空白に）・uid（results[].uid）・date（YYYY-MM-DD）・time（時刻・DST の重複はオフセット込み・日粒度の点は空）・epoch_ms（points[]）・note（点が入る区間註釈の本文・複数は ; ・無ければ空）。
• 日付と時刻を分けるのは Excel がそのまま日付型・時刻型に読むため。
• stdout は見出し行と点の行だけ。被覆サマリ・区間註釈・警告・# explain:・0 点の知らせ・next の ⚠ 地平線行は stderr（Excel や PowerShell の Import-Csv が # 行を行として読むため）。
• 0 点は見出し行だけで終了コード 0（list）。next の要求件数未達は従来どおり 2。
• --lang en は行に影響しない（言語中立＝--json と同じ線引き）。note の註釈文は日本語が正。UTF-8・BOM なし・クォートなし・改行は \n。
• 用途: Excel の利用者・Windows 管理者（PowerShell の Import-Csv -Delimiter "`t"・VBA から CLI を叩いて行単位で読む層）向けの出力の橋。
• 使い方（--help・日英）の list／next の行は [--json|--ics|--tsv]。
• 詳細: impl/README.md の --tsv 節（列・実走例・Excel／PowerShell／VBA での読み方）。

テスト

• --tsv の witness 30 本（単体 15＝renderTsv の構造・実走 15＝サブプロセスで stdout／stderr の割り当てと終了コード）。見出し行と列の固定順・date／time の分離（秒・ms・DST 重複のオフセット・日粒度の点にオフセットが付く tz でも time は空）・note の区間 [fromMs, toMs)（右端は含まない）・0 点・排他（list／next）・--lang en の不変。変異で赤を実測してから数えた。
• 823 テスト（公開時 816。公開後に Excel 対照レシピの doctest 6 本と図の用語検査 1 本を追加）。

1.0 追補 28（2026-10-19）——error.kind: 解決値の契約違反を supply に（言語不変）

言語は不変。参照実装 npm kairos-lang 1.0.11・kairos-lang-mcp も同じ関数を使うので揃う。

変更（2026-10-15 決定）

• --json（と MCP の kairos_list／kairos_next）のエラー面 error.kind で、供給の解決値が契約を破る違反を supply に分類する。 これまでは評価の途中で割れるため static（定義の誤り）に落ちていた。

対象＝評価器の契約検査が割るもの全部:

• 昇順・重複なし。covering の包含。labels の同長と宣言値域。
• kind: dates／instants の形（日付の形式・実在・epoch ms の範囲）。covering／asof の欠落。

変わらないもの:

• usage（引数・ファイル・--supply の JSON 自体の誤り）と static（字句・構文・静的・評価のエラー）の範囲。
• メッセージの文言（「契約違反: …」）と終了コード 1。
• schema/cli-report.schema.json の説明文（supply: the supply contract (external) was violated）。実装がこれに揃った。

理由: 消費側（供給側）が「自分のデータが悪い」と「定義が悪い」を kind で見分けられなかった。 発報層プロファイル（付録 A A.4）の「supply では止めず劣化運転」の規則が、契約違反のデータでも効くようになる。

同梱物と配布（1.0.11 で配布・言語不変）

• kairos-lang-mcp の同梱 reference（resources で配る文書）の相対リンクと画像を、公開サイトの絶対 URL に書き換えて同梱する（外部レビュー第 13 回 E5）。MCP クライアントが文書だけを受け取っても参照先が切れない。
• kairos-lang-mcp の依存 kairos-lang を ^1.0.10（lock 1.0.10）に（同 E6）。
• kairos-lang-mcp の README 日英に、公式 MCP Registry（io.github.azathothx/kairos-lang-mcp）への登録済みの 1 行。
• Windows 単体 exe を公開 workflow が組む。npm 公開の成功後に windows-latest で nodejs.org の node.exe（SHASUMS256.txt で照合）から署名を剥がし、SEA を注入し、参照実装と出力バイト一致を実走で確かめてから kairos-<版>-win-x64.zip（exe＋README 日英）と .sha256 を Release の資産に添付する。1.0.10 は手作業だった。道具は impl/scripts/build-sea.mjs・strip-authenticode.mjs（公開リポジトリから呼べる位置に移した）。
• 開発依存の更新（Dependabot 月次）: vitest 5・@types/node・esbuild・zod。TypeScript は 6 系に留める（7.0 は lib/typescript.js を同梱せず、Playground 構築の transpileModule が使えない）。CI の actions/checkout・setup-node は v7（実行基盤 Node 24）。配布物に影響なし。

テスト

• witness 4 本（impl/test/schema-and-explain.test.ts＝昇順・covering の外・labels の同長・宣言値域の外）。追補前の実装に戻すと 4 本とも static で赤。
• 827 テスト。

1.0 追補 29（2026-10-26）——範囲外シグナルの構築を軽く・結果の出口にラベル・next の警告・.ics の註釈・文言の揃え（言語不変）

言語は不変。参照実装 npm kairos-lang 1.0.12・kairos-lang-mcp も同じ評価器を使うので揃う。束は 5 点＝範囲外シグナルの構築を軽く・next の確定再評価は window-clip を報告しない・--ics は点 0・註釈だけの範囲でも註釈の予定を書く・結果の出口にラベル・運用信号の文言と文書の揃え。小節は決定順。

範囲外シグナルの構築を軽く（2026-10-18）

• 評価器の内部シグナル OutOfCoverageSignal（範囲外の分類。ADR-37 判断 6）を組み立てる間だけ Error.stackTraceLimit を 0 にして、スタック採取を止める。組み立てが終わったら元の値に必ず戻す（try/finally）。
• 対象はこの 1 クラスだけ。他のエラー（KairosError・SupplyError）は 1 回限りの診断なので、従来どおりスタックを持つ。

変わらないもの:

• 結果（点・註釈・警告・被覆サマリ）と、--json／--tsv／.ics／MCP の出力。文言も同じ。
• 範囲外の分類と輸送（filter の「落として註釈」・窓の逆像への拡幅）。捕捉側は instanceof と entries／window しか読まない。
• 変わるのは速度と、このシグナルを例外として捕まえたときの stack 文字列（先頭行だけになる）。利用者の面には出ない。

理由: at 展開の内部述語は、覆域つき入力を参照すると覆域外の点を万単位で評価する。点ごとに投げる範囲外シグナルの構築（スタック採取）が支配項になっていた（実運用側の profile で自己時間の首位・33.9%）。採取を止めると出力は同じで 2.0〜2.5 倍（design/90-open-questions.md 2-1 ①。② tick 生成域の絞り込みは別途）。

next の確定再評価は window-clip を報告しない（2026-10-19）

• next は見つかった後に [from, 最終発火日の翌日) で確定再評価する。右端は答えから決まるので、shift(+1) で最終発火日の翌日へ動く中間点が毎回 window-clip 警告になっていた（同梱例 jp-holidays.kairos の next 既定で再現）。値は正しいが、助言「範囲を広げて評価する」は next では実行できない。
• 確定再評価の window-clip を報告しない。外へ動いた点は from より前（次の発火ではない）か最終発火日の翌日以降（N 件の後）で、答えの N 件に含まれない。
• 変わらないもの: 点・註釈・残走路・to・終了コード。list の window-clip、地平線まで探して不足のときの next（to＝地平線＝--horizon で広げられる）、horizon-clip は従来どおり。--json／--tsv／.ics／MCP は同じ報告から出るので揃う。
• 採らなかった案: to を 1 日余らせる。shift(+2) や roll の週末越えには届かず、残走路と註釈の右端が 1 日ずれる。
• 文書: 発火層プロファイル A.4 の警告の註（日英）・impl/README.md の next。design/90-open-questions.md 2-6。

--ics／--ics-series: 点 0・註釈だけの範囲は註釈の予定だけを書く（2026-10-19）

• 評価範囲に点が 1 つも無くても、範囲外の区間註釈があれば、註釈の予定（終日・TRANSP:TRANSPARENT）だけの .ics を stdout に書いて終了コード 0。stderr に「⚠ 点 0（[from, to) に点がない）・範囲外の註釈 N 件＝註釈の予定だけを書く」を知らせる（--lang en は英語形）。
• 点も註釈も 0 のときだけ従来どおり何も書かず、「⚠ 予定 0 件（[from, to) に点も範囲外の註釈もない）——.ics は書き出さない」で終了コード 2（VEVENT の無い VCALENDAR は出さない）。
• 件数の数え方（icsEventCount）を「点の総数」から「点＋範囲外の註釈」（予定の総数）に。Playground の「カレンダーに入れる」も同じ関数なので揃う（点 0・註釈だけでも作る。series の保存メッセージの「回数」は点の数のまま・点 0 のときは「予定 N 件」の形で知らせる）。
• 理由: 文書は「区間註釈は終日の予定として載る。表の外は黙らない」と言うのに、点が 0 の範囲では何も載らなかった。発火層プロファイル A.4（範囲外は信号であって評価不能ではない）に沿う。例: 同梱例 jp-holidays.kairos を [2026-12-01, 2027-02-01) で --ics すると、範囲外の帯 2026-12-31..2027-02-01 の 1 件だけの .ics になる。
• 変わらないもの: 点がある範囲の出力（予定・UID・名前・行の形）・--json／--tsv・MCP。言語は不変。
• 文書: --help（日英）・impl/README.md（--ics／--ics-series 節・終了コードの要約に --ics の予定 0 件＝2 を明記）・recipes/windows-admin.md（日英）。design/90-open-questions.md 1-6・5-3 (1)(2)。

結果の出口にラベルを添える（2026-10-19）

規則は 2 行:

• 本体式が参照するラベル付き束縛（external／テーブルリテラルの labels:・cycle・segmentBy の labels:）がちょうど 1 つのとき、結果の各点 d に既存の射影 B(d) を評価して添える。
• ラベルの無い点（表に無い＝shift の後など・窓の外・範囲外）は null。参照が 0 か 2 つ以上なら添えない。

出口だけが変わる:

• --json（と MCP の kairos_list／kairos_next）: results[].labels（dates と同長・string | null・添えないときは鍵ごと無い）。schema/cli-report.schema.json に追加（必須ではない）。
• --tsv: 固定順の 7 列の後ろに 8 列目 label（無ければ空）。見出し行も label が付く。7 列で読む既存の取り込みはそのまま使える。
• --ics: 1 点 1 予定の形で、ラベルのある点は SUMMARY（と通知の文）が「名前 · ラベル」（「二十四節気 · 立春」）。名前を残すのは、12 のような短いラベルだけでは予定が読めないため。UID は不変。--ics-series の 1 予定は名前のまま。
• 変わらないもの: 点・註釈・警告・被覆サマリ・人間表示。言語は不変（値層の点はラベルを持たない。読みは射影のまま＝ADR-30/39/47）。
• 出口の射影は後続の式の観測面を変えない: 射影が初めて強制した束縛のメモ化も巻き戻す（2026-10-24・レビュー所見）。準備中の版では、0 点の filter の述語内の名前を先行する式が射影で強制すると、後続の式の被覆サマリからその束縛の登録が消えていた（1.0.11 には出ていた）。
• --tsv の label 列はタブ・改行を空白に（source と同じ・2026-10-24）。言語のラベルは名前だけでタブを含めないが、renderTsv は任意の CliReport を受ける。
• 人間表示と next の探索窓では射影を計算しない（RunOptions.labels: false・結果は不変・2026-10-24）。
• label: 付与式（計算ラベル）はラベル付き束縛に数えない。cycle（weekday など）は数える＝everyDay |> filter(d => weekday(d) == Wed) の各点に Wed が付く。
• 文書: --help（日英）・impl/README.md（--json・--tsv・--ics 節）・recipes/excel-workday.md（日英・見出し行）。design/90-open-questions.md 2-7。

運用信号の文言と文書を揃える（2026-10-19）

文書の訂正（言語・実装は不変）。表の終端跨ぎの実地検証（同梱例 jp-holidays.kairos を 2026-12〜2027-02 で評価）で見えた 3 点:

• 残走路の起点: 発火層プロファイル A.4 の註・A.9・用語集（日英）に 1 文——起点は covering 末尾の翌日 0 時（排他端）。表示の末尾（閉端）から演繹すると 1 日ずれる。例: covering ..2026-12-31 を to 2027-02-01 で評価すると −31 日（12-31 から数えると −32）。coverage[].runwayDays の値は変えない。
• 範囲外の註釈が表の最終日（12-31）から始まる機序: reference/shift.md の落とし穴（日英）と同梱例 jp-holidays.kairos の頭註に 1 文——shift(-1, unit: day) の平行移動像と roll(Following) の依存像が各 1 日手前へ広がり、| の和で残る（素の表と shift(+1) は 01-01 開始。ADR-37 判断 4・spec §4.10）。
• asof 欠落の診断は経路で 2 文言（--supply の束の形の検査＝「asof（文字列）が必須」／評価器の契約検査＝「契約違反: asof がない——external …」）。1 本に寄せず、両方を witness で固定。どちらも error.kind: supply。
• design/90-open-questions.md 5-3 (3)(4)(5)（(1)(2) は --ics の小節で済み）。

テスト

• witness 1 本（impl/test/window-clip.test.ts＝同梱例 jp-holidays の next で window-clip が出ず点・to・残走路は不変・同じ範囲の list では出る・from 側も同じ・地平線まで探して不足のときは従来どおり出る）。抑止を外すと next の warnings で赤・to を 1 日余らせると to と残走路で赤・接頭辞を変えると赤。
• witness 1 本（impl/test/annotations.test.ts＝構築後に Error.stackTraceLimit が元の値に戻る・シグナルの stack がフレーム行を持たない・filter の実経路を通しても戻る）。追補前の実装に戻すと stack の行数で赤・戻しを落とすと値で赤。註釈の出力が変わらないことは既存の黄金出力（impl/test/cli.test.ts）が担う。
• witness（impl/test/ics.test.ts）＝新設 1 本（点 0・註釈 1 の範囲で --ics／--ics-series とも註釈の予定 1 件・終了コード 0・stderr の知らせ（日英）・同梱例 jp-holidays の再現）・既存の予定 0 件の 1 本を「点も註釈も 0」の文言と --ics-series・点がある範囲では知らせないことまで広げ・Playground の buildIcs も点 0・註釈だけで件数 1。件数を点だけに戻すと終了コードで赤・判定を点だけにすると赤・知らせの条件を外すと点がある範囲で赤・知らせを落とすと赤・文言を変えると赤。
• witness（impl/test/result-labels.test.ts・新設）＝external の labels: で各点にラベル・部分集合（filter）も同じ射影・2 束縛参照（weekday と表・表 2 つ）で無し・shift 後の点は表に無ければ null（segmentBy の窓なら属する窓のラベル・窓の外は null）・cycle だけの式・--tsv の 8 列目と見出し・.ics の SUMMARY＝「名前 · ラベル」（ラベルだけの題は出ない・UID 不変・series は名前のまま）・next の切り詰め・Schema（null は通り数値は通らない・実物の --json が通る）・出口が被覆サマリと警告を変えない・同梱例 rokuyo。hook を外す・2 つでも添える・null を空文字に・列を落とす・題を名前のままに・題をラベルだけに・next の切り詰めを外す・被覆サマリの復元を外す・Schema の型を絞る、の変異で赤を実測。impl/test/tsv.test.ts は 8 列に合わせた。
• witness 1 本（impl/test/schema-and-explain.test.ts＝asof 欠落の 2 文言: --supply の束の検査の文言と kind supply・評価器の文言（run() の解決子で SupplyError）・空白だけの asof は CLI でも評価器の文言で kind supply）。cli.ts か eval.ts の文言を変えると赤・評価器の検査を外すと赤・束の検査を外すと欠落が評価器へ届いて文言が変わり赤。
• witness 4 本（result-labels.test.ts 3 本＝メモ化の巻き戻し〈後続の式の被覆サマリが 1.0.11 と同じ〉・labels: false の run／cmdList／cmdNext、tsv.test.ts 1 本＝label 列の無害化）＝2026-10-24 のレビュー所見の処置。変異（巻き戻しを外す・フラグを無視する・置換を外す）で赤を実測。
• 879 テスト（物流レシピの doctest 10 本・レビュー所見の witness 4 本・記述スキルの doctest 17 本を含む。公開時点は 862）。

文書

• レシピ「休配日と着日——物流の営業日カレンダーを定義から作る」（recipes/logistics-delivery.md・日英・doctest・Playground リンク）を追加。
• 付録 A（発報層プロファイル）A.7 の観測例に、2026-10-23 の節気配信の 3 つの時刻（発火 +0.001 秒・配信の予約 +0.048 秒・送信完了 +3.568 秒）の標本を日英で追加。発火 ≤ 予約 ≤ 送信完了の順序が本番で揃った最初の標本（供給側の事前確認済み・2026-10-24）。
• タグライン「決めたら、いつでも。／Write the rule once; list the dates.」を README（日英）・サイトの設定・Playground（日英）・llms.txt・npm の説明（kairos-lang・kairos-lang-mcp）と README に掲げた（2026-10-20 決定・言語不変）。
• 付録 B「供給側プロファイル」（spec/61-supply-profile.md・日英）を追加。表を配る側の契約＝静的束の形・covering＝完全性の主張・asof＝版の識別子・URL と版・更新の作法・受け入れ試験 4 本。schema/supply.schema.json の labels を文字列の配列に狭める（CLI の検査と一致）。ADR-46 に改訂 1（契約違反の error.kind は supply＝追補 28 への追従）。文書の追随 4 点（§3.8 の図の註記・combinators の落とし穴「段の連結は結合子より先」・§4.7 の from:／until: の双対・90-open 3-17）。
• 記述スキル「Kairos を書く——要件から定義へ」（skills/kairos-authoring/SKILL.md・日英・2026-10-26）を追加。人にも AI にも向けた書き方の手順＝要件の型と式の型 14 本（実行例は doctest で固定）・書いてはいけない形と直し方・診断の読み方・検算・語彙。README（日英）と llms.txt から導線。

This site is open source. Improve this page.