日本語 · English（未訳）

宿題・保留事項

確定していない論点と、後で扱うと決めて棚上げした事項の正本。現役の項だけを置く。着手時に該当 ADR/構文へ移す。 解消済みの項と経緯の記録は 91-closed-questions.md（2026-09-30 の整理で移設——本文は移設時のまま）。

読み方: 下の「一覧」で状態を見て、本文は同じ番号の節を読む。番号は本書の中だけの通し（1-1 は「1. 裁定待ち」の 1 項目）。

分類（RC の DoD: 全宿題が「意味論を変えない」ことの再確認・2026-07-07 実施）——各項に次のいずれかを付す。

• ［純命名］＝名前の一括置換で済み意味論不変。
• ［追加拡張］＝新語・新構文の追加で、既存の式の意味は不変。
• ［スコープ外連動］＝言語外（実装系・供給側）との接続で、言語仕様には器・規格のみが返る。
• ［明文化］＝既存規範の字面の確定のみで意味論不変（2026-07-08 追加・F70 用）。
• 補助タグ: ［実装宿題／実装最適化］＝言語仕様に触れない実装課題・［記録のみ］＝受け皿記録。いずれも意味論不変の側。
• ［裁定待ち］＝選択肢が並んでいて判断待ちの項（2026-09-30 追加）。このうち 1-1・1-4 は、選ぶ案によっては評価結果が変わる ——分類は裁定時に確定する（末尾「点検の記録」の注記）。

全項がこのいずれかに落ちることを確認済み——意味論を変える宿題は残っていない。

一覧（現役 28 項・2026-10-19 時点）

1. 裁定待ち——判断すれば閉じる

番号	項	選択肢	状態
1-6	--ics で点が 0・註釈だけの範囲を書き出すか	(a) 現状＝書かず exit 2 (b) 註釈の予定だけの .ics を書く	2026-10-18 の観測で採録（CLI の表面だけ・言語不変）

（1-1〜1-5 は裁定済み。1-1・1-4＝2026-10-01、1-2・1-3・1-5＝2026-10-05〜06・1.0 追補 23 で処置。仕分けの観点と裁定票・裁定は 91）

2. 実装宿題——言語仕様に触れない

番号	項	状態	次の一手
2-1	at 展開の tick 生成域の最適化	①シグナル構築の軽量化＝実装・検証済み（2026-10-18・1.0.12 で配布）／②tick 生成域の絞り込み＝未着手	②は 2-4 と同根
2-2	tz 名検査の記録条件（bizDay 導出経路の順序非対称）	値は正しい・警告の一貫性だけが順序で変わる	右辺評価中の整列の変更を追跡する精密化
2-3	日以外の窓への snapTo を経たマーカーの実装地平線	日への snapTo は 1.0.5 で処置済み・残りは実例なし	実例が出たら
2-4	next の探索窓と計算範囲の実体化	探索窓は 7 日から倍々に処置（1.0 追補 23）・残りは to+400 日の実体化（1 秒刻みで約 35 秒）	実体化の遅延か strideBy の計算範囲の絞り込み（2-1 と同根）
2-5	covering の表示形の長さ	記録のみ（実用の覆域は数区間）	切るなら表示だけ
2-6	next の確定再評価が自ら出す window-clip	値は正しい・助言「範囲を広げる」が next では実行できない	確定再評価の to を 1 日余らせるか、next 由来の警告を抑える。witness 1 本
2-7	結果の出口にラベルを添える（--json・--tsv・.ics・MCP）	2026-10-19 採録・wire の規約・言語不変・1.0.12 候補	源が単一のラベル付きストリームのときの形から

3. 追加拡張の候補——需要が立ったら（現行語彙で書ける）

番号	項	いまの書き方・受け皿	状態
3-1	DST の解決規約（隙間・重複の opt-in）	隙間・重複に落ちる時刻リテラルは明示エラー（ADR-33）	口だけ確保
3-2	出所 premise の深いモデル	source: を前文の第一級メンバーに（浅い置き場は確定）	継続・実需の観測 1 件
3-3	rephase の射程外（k 可変な組）	受け皿なし（別演算子の語として boundary を温存）	必要になれば
3-4	of: が匿名窓を指すときのラベル付け（F27）	曖昧は静的エラー（安全側）	参照手段の追加
3-5	値式の三角関数	平均朔望月の算術近似は書ける・精密計算はデータで持ち込む	見送り寄り
3-6	location:（地点）メンバーの第一級化	地点ごとの premise と source:	糖衣候補
3-7	小粒の糖衣群（F1・F11・F16・F26）	列挙・述語合成・糖衣定義で書ける	需要待ち
3-8	点と日付リテラルの順序比較	評価範囲の分離・epochOrdinal の序数比較	需要 2 例・1.1 RC 草稿あり（時点の順序比較＋since／before・判断待ち）
3-9	窓内の逆向き序数（lastN 級）	within＋last・窓境界点からの shift(-k) の和	記録のみ
3-10	列挙ラベルの序数射影（ord 級）	列挙名から数への関数を premise に置く（三項のネスト）	需要 1 例・1.1 RC 草稿あり（labelOrdinal(B, x)・判断待ち）
3-11	壁時計の時刻値射影（F78）	壁時計 tick の和・帯の構築	保留寄り
3-12	セッションの営業日帰属のノブ（F90）	実体側の供給合成	需要待ち
3-13	coincides の糖衣（except 級）	filter(d => not coincides(…))	頻出確認後
3-14	rebase の一般化	rebase＋同 tz 化後の coincides	将来候補
3-15	窓束縛へのラベル後置・マーカー束縛名共有の検査	同じ窓列を 2 束縛で書き、doctest と coincides で照合	将来候補

4. スコープ外との接続——言語には器・規格だけが返る

番号	項	状態
4-1	tzdb の版供給	実装系の同梱・差し込みの領分
4-2	カレンダーデータの供給モデル（分散供給）	差し込み口（external・--supply）は確定。残りは運用信号の実地検証と分散供給の実例

5. 明文化・表記

番号	項	状態
5-1	表記の統一（day 起点と everyDay 起点・暦座標の二綴り・ラベル字句）	検証例 01〜04 の doctest 化の際に一括
5-2	パイプ演算子に合成の意味も持たせた件	再検討候補（実装・可読性で綻ぶなら基底形のみに戻す）
5-3	運用信号の文言と文書の揃え（5 点）	2026-10-18 の観測で採録・文書だけ

6. 見送り・却下で確定したもの（記録）

番号	項	確定
6-1	labels: cycle 誤用への言語側検査	見送り継続（2026-08-21）
6-2	帯構築の糖衣（F77）	見送りで閉じた（2026-07-24）・再開条件＝新規実装局面での再頻出
6-3	標準語を premise 内で再定義したときの警告	言語側は採らない（2026-09-24）

「スコープ外として確認済み（宿題ではない）」は 7 節。

1. 裁定待ち

仕分けの観点（2026-10-01）: 5 件のうちいくつかは、グレゴリオ暦（の日時表記）に由来する特有の問題ではないか——時間ストリームの 中身が六十干支だったら、その裁定は発生するのか。

• 言語は時間ストリームを「基底 Chronos 上の点の列」（spec §2）と定義し、点の表記をグレゴリオ暦の日時に限るとも、表記の型も定めていない （点の正準表記は実装系の裁量＝7 節）。
• グレゴリオ暦の表記に由来する項は言語の裁定ではなく参照実装の表示・wire の規約として扱える可能性がある（参照実装が TypeScript で 動く必要はあるので、実装の決めは別途要る）。
• 次回、この観点で 5 件を仕分けてから裁定に掛ける。

仕分けの結果（2026-10-01・上の観点で 5 件に「中身が六十干支だったら発生するか」を問うた）

• 言語の裁定＝1-1・1-4。覆域と窓・述語の意味論＝暦法に依らず発生する。1-1 は干支を cycle で規則生成するなら覆域の端が無く 発生しない——発生の条件は「窓がデータ由来か」であって暦法ではない。1-4 は覆域つきの表と結合した列なら干支でも同じ。
• 参照実装の表示・wire の規約＝1-2・1-3・1-5。グレゴリオ暦の市民ラベル YYYY-MM-DD… が人間表示・--json の dates・供給 JSON に 出ている形。干支なら 1-2 は「同じ日の点は同じラベル」が自明で誰も表示を点の同一性と読まない・1-3 は版の識別子が日付である必要が ない・1-5 は CLI の形。
• 根拠＝spec §2.2（時間ストリームは基底 Chronos 上の点の列・表記は未規定）・ADR-11（粒度は表示射影で型に乗せない）・本書 7 節 （正準表記は実装系の裁量）・表示形の唯一の出所は参照実装の rt.fmt（impl/src/eval.ts）・asof は参照実装も文字列の同一性比較 （宣言 asof との不一致検出）と表示・メモ化鍵にしか使わず日付として読まない（eval.ts asofOf・loadExternal）。
• 処置＝1-2・1-3・1-5 は 87 §6 の裁定（8・9・新設 10）へ合流し JSON Schema と同じ公開で決める→ 2026-10-05〜06 に決定・1.0 追補 23 で 処置（Schema 2 本・source／line・エラー JSON・表示形の一意性・asof の明文）→ 91 へ移設。
• 言語側に残るのは明文化候補 2 行——(a) 点の表示は射影＝同一性は点が担う（ADR-11・7 節の既存原則の確認）(b) asof は版の識別子＝ 同一性比較のみで順序を読まない（spec §3.8）——だけで意味論不変。
• 1-1・1-4 は同日に決定。1-1＝案 A〈覆域端で閉じた最終窓の終端は未確定・ADR-37 改訂 6・1.0 追補 23＝点集合は変えず註釈だけを足す〉／ 1-4＝案 ③〈現状維持＋spec §4.8 明文〉。裁定票と経緯は 91。
• at を上位区分内の位置指定として premise の責務にする案（2026-10-01 の回顧）は 3-16 に採録。

1-6 --ics で点が 0・註釈だけの範囲を書き出すか

• ［裁定待ち・CLI の表面だけ・言語不変］ 2026-10-18 の観測（4-2）で採録。
• 現状: --ics／--ics-series は予定の件数を点の総数で数える（impl/src/ics.ts の icsEventCount）。評価範囲が丸ごと表の外（点 0・範囲外註釈 1）だと、.ics を書かず stderr に「⚠ 予定 0 件（… 範囲外の註釈 1 件）——.ics は書き出さない」を出して exit 2。
• 一方、文書は「区間註釈は終日の予定として載る。表の外は黙らない」（impl/README・--help）。点がある範囲では註釈の予定が載るが、点が 0 の範囲では何も載らない。
• 選択肢: (a) 現状を保ち、文書に「点 0 のときは註釈も予定にならない」を明記する。(b) 註釈だけの .ics を書く（カレンダーに「⚠ 範囲外」の帯だけが出る）。exit は 0 か 2 か。
• どちらも言語不変。発報層プロファイル A.4 の「範囲外は信号であって評価不能ではない」に沿うのは (b)。

2. 実装宿題

2-1 at 展開の tick 生成域の最適化

• at 展開の tick 生成域の最適化（範囲外シグナル構築の軽量化込み）［実装最適化・意味論不変］: 還流第 15 便 (d)（収蔵 16・2026-08-26）。
• 機序＝strideBy の市民 1d tick は epoch 錨から計算範囲（to+400 日）まで生成され、覆域つき入力を参照する at の内部述語が覆域外の点を 万単位で評価する形で OutOfCoverageSignal 構築が支配項になる（先方 profile 実測＝自己時間が総 890ms の 33.9%・首位。覆域つきテーブル× at 形で旧形比 2.1 倍・覆域なしでは at 形がむしろ速い）。
• 是正候補＝①シグナル構築の間だけ Error.stackTraceLimit = 0（先方実装で 2.0〜2.5 倍・当方 impl でも外付け実測 580→306ms・出力完全同一の 確認済み）②tick 生成の評価範囲近傍への絞り込み。
• ADR-51 判断 6 の括弧書きは追記で訂正済み（horizon-clip 不在の論拠は「単位窓列を実体化しない」の側・生成域の記述は実装事実に整合させた）。 処置は 1.0 後。
• ①＝実装・検証済み（2026-10-18・1.0 追補 29・1.0.12 で配布）: OutOfCoverageSignal の構築の間だけ Error.stackTraceLimit を 0 に（try/finally で戻す）。 witness 1 本（戻し・フレーム無し・filter の実経路）。CLI 117 本の出力が変更前と byte 同一。1 年分の payday × at(T09:00) で構築 20,858 回・in-process で 2.4〜3.6 倍 （CLI の壁時計は起動時間が分母に乗るので 1.4 倍程度）。②は未着手。

2-2 tz 名検査の記録条件——bizDay 導出経路の順序非対称

• tz 名検査の記録条件——bizDay 導出経路の順序非対称（align オブジェクト共有の偶然一致）［実装宿題・意味論不変＝診断の一貫性］: ADR-53 追記 3（還流第 18 便処置・2026-08-28）の同時観測。
• 現象＝標準導出 bizDay を everyDay 文脈で先に評価すると別 tz 参照で止まり、別 tz 文脈で先に評価すると両順とも通る。
• 機序＝「右辺内 filter が確定した align」と「呼び出し文脈の align」が everyDay align のオブジェクト共有で偶然参照一致し、右辺内で 完結した検査（追記 2 の裁定では記録対象外）が記録される側の非対称。
• 完全に切るには「右辺評価中に predicateAlign が変更されたか」の追跡が要る。追記 2 の先行精密化が追記 3 の退行を生んだ教訓から 最小修正を優先して深追いせず採録。1.0 後の精密化候補（値は align 非依存で正しく、壊れうるのは警告の一貫性のみ）。
• 供給側でも同形を再現（還流第 19 便 §5・2026-08-28・前文 C6/G8＋B = bizDay・K 先行で 22 点通過／everyDay 先行で ERR＝当方観測と 一致）。先方はテスト名を「順序独立が保たれる」から「再記録が効く」へ改めた（名前が中身より多くを約束しない）。
• 追記 4 の第 3 経路 witness は「再記録が効く」側を守るもので、この非対称は封じていない。

2-3 日以外の窓への snapTo を経たマーカーの実装地平線

• 日以外の窓への snapTo を経たマーカー［実装宿題・意味論不変］: テーブル |> snapTo(day) のマーカーは 1.0.5（F144）で 計算範囲（to+400 日）の先まで寄せるようになり、静的 labels: の同長性検査は評価範囲によらず正確になった（spec §4.2 の 「覆域基準＝評価範囲非依存」に実装が追いついた）。
• 残り＝snapTo(month) のように日以外の窓へ寄せたマーカーは従来どおり地平線で切れる（horizon-clip 警告）。その形に静的 labels: を 付けると、狭い評価窓で「ラベル列の長さ ≠ 窓数」の偽エラーになりうる。実例は未観測。
• 是正するなら、窓の生成規則から解析的に寄せる（生成語ごとの実装）か、検査を地平線に気づかせる。同根の empties: error の偽エラーは F145 で処置済み。経緯（2026-08-26 の採録から処置まで）は 91。

2-4 next の探索窓の初期幅と計算範囲の実体化

• next の探索窓の初期幅と計算範囲の実体化——cmdNext の探索窓は 1.0 追補 23 で 7 日から倍々（〜224 日→1 年から倍々→地平線）に した（確定再評価の意味論は不変）。
• しかし everyInstant |> strideBy(1s, …) のような細かい列では残る支配項が計算範囲（to+400 日）までの実体化（1 秒刻みで約 3,500 万点＝ 次の 1 点に約 35 秒。旧は 1 年窓＋400 日で約 6,600 万点）で、実用上は依然重い（境界チェックリスト二巡目 2026-09-30・資源の境界＝言語の 欠陥ではない）。
• 改善候補＝実体化の遅延（評価範囲の需要に応じて伸ばす）か、strideBy の計算範囲を評価範囲の近傍に絞る（ADR-37 判断 8 の実装地平線の 設計の領分・2-1 の tick 生成域の絞り込みと同根）。実装宿題・優先度低。

2-5 covering の表示形の長さ

• covering の表示形の長さ［記録のみ・資源］: 表示形は区間の数に比例する（5 万区間で註釈 1 行が約 1.2 MB）。 実用の覆域は数区間。註釈の同一性キーにも使っているので、切るなら表示だけ。

2-6 next の確定再評価が自ら出す window-clip

• ［実装宿題・意味論不変＝診断の助言の一貫性］ 2026-10-18 の観測（4-2）で採録。
• 現象: next（既定）が 警告: window-clip: shift(1) 2026-11-03 → 2026-11-04（… 範囲を広げて評価する。§7.8） を出す（同梱例 jp-holidays・4 表面で同文・1.0.10 以前から）。
• 機序: cmdNext の確定再評価は to＝最終発火日の翌日（impl/src/cli.ts）。shift(+1) で最終発火日の翌日に動く中間点が [from, to) の外に出て、評価器の window-clip（impl/src/eval.ts の inWin）に掛かる。値は正しい。助言「範囲を広げて評価する」は next の利用者には実行できない。
• 是正候補: 確定再評価の to を 1 日余らせる／next 由来の to に対する window-clip を抑える／文言を next 向けに変える。どの案でも next＋shift(+1) の witness を 1 本置く（impl/test/window-clip.test.ts は list だけ）。発報層プロファイル A.4 の window-clip の註に next の一文。

2-7 結果の出口にラベルを添える

• ［実装宿題・wire の規約・言語不変］ 2026-10-19 採録。
• 発端: ラベルは入口では既に点に付いている（external(kind: instants, labels: […]) の供給 JSON は dates と labels の並行配列＝ADR-46。二十四節気の権威データも受け取った時点で ラベル付きの点列）。計算ではストリーム名を名前空間にした射影 sekki(d) で他ストリームのラベルを読む（ADR-30）。ところが出口は点の列だけで、ラベルが落ちる。
• 線引き: 値層の点にラベルを属性として持たせない。同一性は瞬間が担う（ADR-11・1-2 の裁定）・|／&／\ の重複排除・shift 後のラベルの規則が要る・他ストリームのラベルは 結局 射影でしか取れない（ADR-30 が汎用の labelOf(点) を廃した理由）。宣言 labels: と射影は計算のために残る。足すのは出口だけ。
• 形（案）: --json に results[].labels[]（dates と並行・追加のみ＝uid と同じ型の schema 変更）・--tsv に label 列・.ics の予定の題にラベル・MCP は同じ報告なので揃う。
• 添える条件（案）: 本体式の源が単一のラベル付きストリーム（external の labels:・segmentBy／cycle の labels:）で、点がその窓に属するとき。filter は部分集合なので源の射影で 求まる。shift／roll の後は点の源が変わるので添えない（または源の射影を点ごとに評価して添える＝規則を 1 本決める）。
• 判断点: 源が複数（sekki | rokuyo）のとき＝添えない／{source, label} の組で添える。ラベルのない点は空か null か。--lang en でもラベルは日本語のまま（註釈文と同じ線）。
• 期待される用途: カレンダーに「立春」「大安」が題で出る・Excel に節気名の列・AI クライアントがラベルを読める・検定の教材で出力の行にラベルが見える。 何かができそうだという直観が発端＝用途は使いながら見つける。

3. 追加拡張の候補

3-1 DST の解決規約（隙間・重複の opt-in）

• DST の解決規約［追加拡張］: 時刻付きリテラルが在圏 tz の DST の隙間・重複に落ちると、1.0 は明示エラーにする（ADR-33）。 将来の拡張として、隙間＝ロール規約と同形・重複＝選択子と同形の opt-in の premise メンバーの口だけを確保してある。 需要が立ったら設計する（TZ の定義そのもの＝F55 は ADR-33 で確定——経緯は 91）。

3-2 出所 premise の深いモデル

• 出所 premise（provenance source）［追加拡張・スコープ外連動］: カレンダーは asof（時間版）に加え、出所（誰の権威のデータか。内閣府 公式／有志／自組織の上書き）も premise として帯びるべき、という宿題。
• 同じ「日本の祝日」でも公式版と組織ローカルの上書き版は別物で、asof だけでは区別できない。「ある年だけ祝日を営業日に」という上書きが 公式データと混ざる危険を防ぐため。ADR-15 の asof の管に source を並置する形が有力。（発端: TSE の更新主体をめぐる議論）
• 浅い置き場は確定: source を前文の第一級メンバー（宣言必須寄り）に昇格した（30-syntax §1.6）。深いモデル（下記の分散供給・出所加工の 線引き）は宿題を継続。
• 材料追記（2026-08-21・還流第 12 便 B-6＝収蔵 13）: 供給側が非権威 anchor（日干支・F13）の利用者表示を verified 二値（照合済み/参考版）で 分けて運用中——「権威の有無・照合状態」の表明語彙への実需の観測 1 件（現行回答＝source: 字面への正直表明・95 の実践の型）。

3-3 rephase の射程外（k 可変な組）

• rephase（旧仮称 shiftBoundary）の射程外＝k（W ⊃ U の個数）可変な組（month ⊃ day を day 単位で ずらす等）の別演算子（必要になれば。§1.12。boundary の語はそちらに温存＝rephase 裁定 2026-07-26）。 ［追加拡張］（既存 rephase の意味は不変）

3-4 of: が匿名窓を指すときのラベル付け

• of: が匿名窓（segmentBy の窓）を指すときのラベル付け。裸ストリームへの of: 付き選択子の窓解決規約 （40-examples F27）もここに合流。［追加拡張］（現状は曖昧＝静的エラーの安全側。参照手段の追加）

3-5 値式の三角関数

• 値式の三角関数（sin/cos）［追加拡張・見送り寄り］: 真の朔弦望（Meeus 級）を言語内で 計算する唯一の欠け（2026-07-11・月相の三段整理＝40-examples/03 §3.4 追記）。平均朔望月の算術 近似は現行語彙で書ける（実行検証済み・NAOJ 朔日と 8/12 一致）が、精密計算は周期項の総和に 三角関数が要る。導入しても官暦との一致（真正性）は買えず、係数列の持ち込みは実質データと 同型のため見送り寄り——需要が立ったら再考。

3-6 location:（地点）メンバーの第一級化

• location:（地点）メンバーの第一級化［追加拡張］: 日の出・日没系のデータ premise は地点依存 （40-examples/05）。現状は地点ごとの premise ＋ source: に地点を含める形で表せるため、第一級 メンバー化は糖衣候補（tz: と同様の文脈値になる見込み。socket の供給モデルとも連動）。

3-7 小粒の糖衣群

• 小粒の糖衣群（40-examples の綻びから）［いずれも追加拡張］: 標準糖衣の整備（onMonthDay・nthWeekdayOfMonth 級。F1—— 糖衣は core への展開で意味論不変。「時分秒の窓」も材料＝40-examples/11）・nth の複数序数（F11。列挙で書ける）・ cycle の積 zip（F16。述語合成で代替できる）・範囲 shift の可変幅＝fold（F26。列挙で書ける）。いずれも現行語彙で書けるので 需要待ち。解消済みの部分（hour 窓＝ADR-50・窓インスタンス参照＝ADR-42）と射程外の確認（振替の再帰 F8・隣接窓参照 F24）は 91。

3-8 点と日付リテラルの順序比較

• 点と日付リテラルの順序比較（d >= 2026-06-29）［記録のみ・F 採番なし］: 値層に無い（「数値ではない」）。 受け皿＝評価範囲の分離（第一）と epochOrdinal 序数比較（11 §(n) で実測）。ADR-34「点±幅算術を導入しない」 と同じ統治の帰結と読めるが、順序は算術と別問題ではある——需要が続けば糖衣候補。
• 需要の例（2026-10-12）: 「締め切りまでの残り営業時間」＝今の時刻から来週火曜の締め切りまでの営業時間内の正時を数える。評価範囲は日付 単位なので時刻起点は式で切る: hourly |> filter(t => isOpen(t) and epochOrdinal(hour, t) >= epochOrdinal(hour, 2026-10-13T11:00))（実測＝ 受け皿で書ける・読みやすさは劣る）。残り営業日数は bizDay を評価範囲で切って点数を数えるだけ（締め切り日は next で求める＝2 段）。
• 糖衣の構想（2026-10-15・記録のみ）: 上の序数比較を since(日時)／until(日時) 級の 1 語に畳む標準糖衣。核への展開で意味論は不変だが、 単位（hour／day／instant）をどう読むかと名前を決めてから。本項の題は日付リテラル（グレゴリオ暦の表記）を名指しているが、問題は 「点と、どの暦法で書かれた瞬間とも順序比較できない」こと＝暦法に依らない（10/1 の仕分けの観点）。需要は 2 例目（締め切りまでの残り営業時間の 記事）まで。需要が続けば候補に上げる。

3-9 窓内の逆向き序数（lastN 級）

• 窓内の逆向き序数（「窓ごとの最後の N」・lastN 級）［追加拡張・記録のみ］: ADR-52 検証で採録—— 現行の正道は「最後の 1」＝within＋last・「最後の N」＝窓境界点からの shift(-k, unit: 軸) の和 （nth は前方 1 起点のみ・F11 の系）。takeLast の窓付き入力エラーからの誘導先が 1 段で書けない 非対称が残る——需要が続けば nth 負値 or lastN の裁定材料。

3-10 列挙ラベルの序数射影

• 列挙ラベルの序数射影（列挙名→番号）［追加拡張］（2026-09-07・還流 2026-09-08 定期便 §3＝収蔵 23。2026-09-24 追記: 正準例の 補助関数名 monthNo が標準語と衝突したため monthLabelNo に改名〈収蔵 28〉——ord() が入ればこの三項関数と命名問題は消える）: labels: の 値域は列挙名で、external の labels: は識別子のみ（ADR-30 の静的知識）。ラベルを算術に使う定義（供給側の大安・ 不成就日＝旧暦月番号）は列挙名→数の関数を premise 内に置く三項 12 段のネストになる（実測で成立・可読性の代償）。 labels: の宣言順は序数を定めているので、序数を取る射影 1 語（ord(lunar(d)) の類）があればネストは消える。需要 1 例・ 語彙追加＝1.0 をブロックしない・1.0 後に需要と実害で判断。正準形は reference/segmentBy.md label: 節に文書化（同日）。

3-11 壁時計の時刻値射影（F78）

• 壁時計の時刻値射影（clockHour(t) 級。F78）［追加拡張・保留寄り］: 「9 時から 17 時」を述語一発で書く直感形は書けず、 壁時計 tick（strideBy 形）の和か帯の構築で書く。代替があるので必須ではない——導入するなら射影一族（ADR-30 の骨格）。 必要が実例で立つまで見送り（綻びログ F78。細粒度カレンダー軸＝F67 の確定の経緯は 91）。

3-12 セッションの営業日帰属のノブ（F90）

• セッションの営業日帰属のノブ（F90）［追加拡張・需要待ち］: 既定は「開場日（実体 tz）」固定。CME Globex 級の 「トレード日帰属」（日曜 17:00 開場＝月曜取引日）はこの既定と食い違う。実体側の供給合成で書けるため直ちには困らない—— 帰属ノブは実例が立ってから（綻びログ F90）。

3-13 coincides の糖衣（except 級）

• coincides の糖衣［追加拡張］: 窓所属述語 coincides(S, w, d) は ADR-38 で確定した。「その窓に S の点がある日を除く」 級の定型を 1 語にする糖衣は、頻出を確認してから糖衣定義（F1 の器）で（F68 の確定の経緯は 91）。

3-14 rebase の一般化

• rebase の一般化［追加拡張］: 日付ラベル保存の再錨は ADR-40 で day 固定として確定した。将来候補＝時刻保存の再錨 （当面は rebase＋同 tz 化後の coincides の合成で書ける）・w 一般化（month/year は多対一で単射性が破れるので、単射性の 主張ごと再設計が要る）。F69 の確定の経緯は 91。

3-15 窓束縛へのラベル後置・マーカー束縛名共有の検査

• 窓束縛へのラベル後置・マーカー束縛名共有の検査［追加拡張］: segmentBy の labels: は ADR-39 で確定した（守るのは長さ のみ・中身の照合は doctest＋coincides の分担）。将来候補＝窓束縛へのラベル後置（kyuMonth = lunarMonth labels: … 級—— 同じ窓列への二重束縛の相互整合を構文で立てる形）・マーカー束縛名共有の警告級検査。F60〜F63 の確定の経緯は 91。

3-16 at を上位区分内の位置指定として premise の責務にする案（設計者の回顧・2026-10-01）

• at の再定義案［追加拡張・記録］: 1-4（at 後段での註釈区間内の点）を案 ③ で閉じた際の回顧（2026-10-01）。
• 回顧の内容＝at はもとより糖衣なのだから、求める時点が属する区分を含む premise において、その区分のひとつ上位の区分のある時点を A としたとき [A, A+1) の間のどこかを指すもの、としておけばよかったのかもしれない。そうすればそれは その premise の責務とできた。
• 現行の展開（tick＋coincides＝ADR-51）は市民日グリッドの tick に述語を重ねる形で、入力を点の集合でなく述語として読み直す。1-4 の 点脱落も、窓付き入力の禁止（ADR-51 追記 1）も、endless の素通し（第 15 便 (b)）も、この述語形に由来する。
• 回顧の定義なら at は窓内位置の射影＝点変換（輸送行は「像」＝点を保持して註釈を通す）になり、三つの落とし穴が同時に消える。
• 壁時計の位置（DST の隙間・重複の規約）は premise の射影の責務（ADR-33 の TZ＝premise 相対の写像と同じ置き場）で、グレゴリオ以外の premise（六十干支＋十二時辰 等）でも同じ器で書ける＝1-4 は「展開がグレゴリオの日グリッドに依っていた」という意味で暦法由来、という 見立てはこの層で正しい。
• 要るもの＝「上位区分の窓内の位置」を premise が提供する core の射影語 1 本（現行語彙には無い——経過算術形 snapTo(day) |> shift(+h, unit: hour) は DST でずれる＝ADR-51 の出発点）と、at の展開のその語への差し替え（ADR-51 改訂）。
• 外延は註釈区間の外で現行と同値・註釈区間では点が残る（現行は落ちる）＝追加の方向。状態＝記録のみ（1.x の追加拡張として需要が 立ったら。供給側の第 15・20 便は観測のみで実害なし）。

4. スコープ外との接続

4-1 tzdb の版供給

• tzdb の版供給［スコープ外連動］: どの版の tz データで評価したかの供給（差し込み・実装系の同梱）は実装系の領分で、 言語には器・規格だけが返る（ADR-33 の帰結）。

4-2 カレンダーデータの供給モデル

• カレンダーデータの供給モデル［スコープ外連動］: 更新主体は言語が規定しない（ADR-15 でデータ供給を切り離したため外部で自由に 選べる）。
• 出所を明示できれば中央集権不要で、分散供給（リポジトリ・モデル。出所ごとに独立供給者、利用者が選んで重ねる）が可能。言語は規格 （差し込み口＋出所表記）だけ決める。AI は出所の加工役にはなれるが、真正性の出所そのものにはなれない（設計上の線引き）。
• 供給側の実装は外部の定期取得基盤で検討中（非公開の別プロジェクト。「源を定期取得→正規化→差分検知→発報」型の基盤に、暦要項を 年次取得する供給部を足す形）。
• 取得結果は Kairos のテーブルリテラル（時点列＋labels:。ADR-26/30）へ流し込むデータ源になり、source:＝NAOJ、asof:＝取得年/ 取得日時が供給側の保存時刻に対応する。Kairos の器（テーブルリテラル・source/asof）と供給側（取得・保存・鮮度）の接続が socket（下記・ 外部供給宣言）の具体像。実装は供給側の課題で Kairos 言語のスコープ外。

• 現況（2026-09-30）: 差し込み口は external（ADR-46）と CLI --supply で確定・実装済み（2026-07-09〜08-08 の追記の原文は 91）。 残る観測点＝運用信号の実地検証（残走路の警告・範囲外註釈の実発火——2026-10 中旬の残走路割れ・2027-01 の covering 切れ）と、 分散供給（出所ごとの独立供給者）の実例。

• 観測（2026-10-18・表の終端跨ぎの実地検証）: 同梱例 impl/examples/jp-holidays.kairos（statutory の表 covering 2026..2026）を 5 表面（CLI 人間形・CLI 機械形・ MCP・公開 npm 1.0.10・--supply）で評価。表面間で一致（差は version のみ）。

  • list [2026-12-01, 2027-02-01)＝# 0 点・# ⚠ 範囲外 2026-12-31..2027-02-01（statutory covering 2026-01-01..2026-12-31）・残走路 -31 日。 next 既定（今日起点）＝11-03・残走路 58 日。next --from 2026-12-20＝0 件・註釈 2026-12-31..2036-12-20・残走路 -3641 日・exit 2。

  • 残走路は全値「排他端（2027-01-01）− 評価 to」（impl/src/index.ts）。表示の covering 末尾は閉端（12-31）なので、字面から演繹すると 1 日ずれる＝5-3。

  • 範囲外が 12-31 から始まるのは、shift(-1, unit: day) の平行移動像と roll(Following) の依存像が各 1 日手前へ広げ | の和で残るため（ADR-37 判断 4・impl/src/eval.ts）。 素の表と shift(+1) は 01-01 開始。roll 側は spec §4.10 の図が示す。

  • horizon-clip は shift(+500, unit: day) でだけ観測。完結主張・asof 不一致・区間リスト covering・空テーブルの「まだ無い」は入力に該当形が無く未観測。

  • 副産物＝1-6（--ics は点 0 なら註釈だけでは書かず exit 2）・2-6（next が自ら出す window-clip）・5-3（文言と文書の揃え）。供給経路では asof 欠落・乱順・覆域外の 3 種とも error.kind: supply（1.0.11 追補 28）。

5. 明文化・表記

5-1 表記の統一

• 表記の統一（day |> / everyDay・暦座標二綴り・ラベル字句）［明文化］: 還流第 12 便 B-2/§C・ F111——premise 束縛右辺の day |> と everyDay |> は同義（spec §4.1 の everyDay 定義・実装は everyDay ≡ day の要素点列の写し・実測外延一致）だが正準表記は未宣言で文書内混在。11 の month(d) 形と暦座標糖衣（monthNo）の混在・03 の文字列ラベル形（F111）と合わせ、 01〜04 doctest 化の際に一括統一が筋。

5-2 パイプ演算子に合成の意味も持たせた件（再検討候補）

名前の統廃合や語の多重定義は、時間ストリーム型では自然でも別の型・別の層に適用すると語感が綻ぶことがある。 純粋な命名（仮称。spec §5.4）と分け、実例が増えたら再評価する。

• |> に合成の意味も持たせた件（spec §4.8 の略記 A）［糖衣の削減＝core 意味論不変］: ポイントフリー糖衣で |> が「値→変換の適用」に加え「変換→変換の合成」も担う。型で区別され一義とみなす立場だが、実装・可読性で 綻ぶなら基底 B（s => 明示）のみに戻す余地。

5-3 運用信号の文言と文書の揃え

• ［明文化・文書だけ］ 2026-10-18 の観測（4-2）で採録。5 点。

• (1) impl/README.md の終了コードの要約（0・1・2＝next の要求未達）に「--ics／--ics-series の予定 0 件＝2」が無い。--help には有る。

• (2) impl/README.md の --ics 節に「点が 0 のときは註釈も予定にならず .ics は書かれない」が無い（1-6 の裁定に従って書く）。

• (3) 残走路の起点: spec/60（A.4・A.9）と用語集は「covering 末尾までの日数」と書くが、実装は排他端（末尾の翌日 0 時）起点。表示の末尾（閉端）から演繹すると 1 日ずれる。 「末尾の翌日 0 時（排他端）起点」を 1 文。

• (4) 範囲外註釈が表の最終日（12-31）から始まる機序（shift(-1, unit: day) 側）の 1 文を reference/shift.md の落とし穴か同梱例 jp-holidays.kairos の頭註に。 spec §4.10 の図は roll(Following) 側だけを示す。

• (5) asof 欠落の診断が経路で 2 文言（--supply の束の検査＝impl/src/cli.ts／評価器＝impl/src/eval.ts）。どちらも kind: supply。1 本に寄せるか、両方を witness で固定する。

6. 見送り・却下で確定したもの

6-1 labels: cycle 誤用への言語側検査

• labels: cycle 誤用への言語側検査［追加拡張］: 還流第 12 便 B-7（収蔵 13）——非周期列への cycle が黙って回る非対称（reference/segmentBy ADR-47 節に明記済み）は暦注プロダクトの年次更新 リスク面、という運用報告。防御の現行正準＝全年スナップショット固定（供給側実践・doctest と同型）。 一般の周期性検査は意味論的性質で不可能・限定形（anchor 整合・窓数照合等）はあり得るが守備範囲が 狭い。裁定（2026-08-21）＝記録のみ・見送り継続で確定（ADR-47 の「照合は doctest/coincides の 分担」を維持）。

6-2 帯構築の糖衣（F77）

• 帯構築の糖衣（F77）［見送りで閉じた・2026-07-24 決定］: 日内時刻オフセットの同型の定型は実装期に集中して現れ、 運用期の新規は 0 だった——頻度待ちでは自然に閉じない構造なので裁定で閉じた。再開条件＝新規実装局面（新アプリ・ 新ジョブ群）で同型が再頻出したら需要駆動で。原文は 91（細粒度カレンダー軸＝F67 の項の (d)）。

6-3 標準語を premise 内で再定義したときの警告

• 標準語（stdlib の公開語）を premise 内で再定義したときの警告［却下方針・2026-09-24 決定］: 還流 2026-09-23 緊急便（収蔵 28）を 受けた項。
• 発端＝正準例の monthNo が標準 Gregorian の monthNo と同名で、with 派生では機構 A の再解決により標準 month のラベル射影まで 差し替わり月番号の読み出しが既定枝の値に潰れた・警告 0。供給側は自社実装に「保存時の警告（禁止ではない）」を裁定。
• 言語側は採らない。同名の定義は後（直前の定義）が勝ち、裸名は派生スコープで再解決される（spec §3.7 機構 A・§4.5 の後勝ち）のは、 本文を省略して書ける Kairos の利点そのものであり仕様。
• 標準語を上書きする自由（Fiscal が year 一行で書ける）と「偶然の同名」は言語には区別できず、警告は当たり前のことへの過剰な親切。 名前選びは書き手の責任（既存の ADR に警告の可否の明文は無く、本項が明示の却下記録）。実装系が自前で警告を出すのは自由（供給側の裁定を 妨げない）。

7. スコープ外として確認済み（宿題ではない）

• 発報・タスクの実行・管理（列の解釈、ジョブの起動、リトライ、状態追跡）。言語 Kairos は発報すべき時点の集合 （外延）を定義するところまで。その列を解釈して Chronos 上で実際に発報・登録・起動するのは実装系の責務。
  • 但し書き（2026-07-11）: 「実行起点相対」のうちスコープ外はフィードバック（前回完了ごとの無限ストリーム）だけ—— 注入された時点からの次回計算は射程内で、現行語彙の純関数として書ける（新語彙ゼロ・実行検証済み。spec §7.7・40-examples/07）。
• 発火点列への値随伴出力（点にラベル・射影値〈六曜名・干支名等〉を随伴させて出力する手段） ——配信ペイロードの構成は供給側／実行系の責務（発報層還流 第 5 便 §4 で照会・2026-07-25 追認）。含みと設計材料は次の 2 項。
• 値随伴出力——但し含みを残す（考察）: 点列出力の「2026-07-25」という表示自体が暦座標への射影（＝ラベル）であり、Chronos の点の 正準表記は言語仕様で規定していない（表示は実装系の裁量）。中身が〈月・水・金〉でも今週という範囲では発火時点集合の定義として 機能する——出力の座標表現と値随伴は連続した問題で、1.0 後の検討候補として記録（暦×占い系アプリが初の実需候補）。
• 値随伴出力——実装系還流の設計材料（2026-08-02・第 9 便 §2＝収蔵 10）: 実運用の点同定は「Chronos 点そのもの」でなく「点が属する 暦日（premise の TZ で）」が実用単位だった。正準表記に「点→所属暦日（どの calendar-system・どの TZ か込み）」の写像を含めるかが 実務側の論点（ms 精度の表記だけだと供給データとの突き合わせで暦日への丸めが各自再発明される）。暦日成分は ADR-33 により premise 相対＝表記に含めるなら premise（tz・暦法）の明示が必須成分になる。
• カレンダーデータの真正性判定（差し込む器は用意する）。
• 実行起点に相対な窓（前回完了からの相対等。I7）。
• 複数物理時間軸の相対論的調停（地球時と火星固有時のズレ等。I1）。
• 実体化点数の上限（資源ガード）——言語側には持たない（2026-09-29 決定＝敵対的レビューの手当て候補 (e)）。理由＝扱う相手は 時間という無限の存在であり、そこから切り出すのだから結果が現実の機械に収まりきらないことがあるのは当たり前。
  • 実装面で上限を持たせることは否定しないが必須ではない（参照実装は置かない＝入口の Limits 節に「上限なし・範囲は呼び手が決める」を 明記。実測 1s×7 日＝60 万点で 2.4 秒・1.1 GB。有界実体化の性質は ADR-36 判断 8）。
  • 設計材料＝評価時に見込み点数を判断して警告を出す（SQL の影響件数の類推・場合によっては重宝される）——実装系の任意機能として採録、 言語の語彙にはしない。

点検の記録

1.0 条件 4 の初回点検（2026-08-26・宣言 9/14 に向けて）: 全項を再通読。

• 現役項は DST 解決規約・tzdb 版供給・出所 premise 深部・供給モデル・of: 匿名窓・F78・F90・三角関数・location:・小粒糖衣群 （F11/F16/F26 含む）・順序比較・cycle 誤用検査（見送り裁定済み）・lastN・tick 生成域最適化・表記統一・labels 後置候補・rephase k 可変組・ |> 合成再検討の 18 系統。
• 全て［追加拡張］［スコープ外連動］［明文化］［実装宿題／最適化］［記録のみ］のいずれか＝意味論を変える宿題ゼロを再確認 （ADR-48〜53 期の新規項も含む。宣言直前 9/14 に差分確認を行う）。

2026-09-30 の整理時の注記: 8/26 以降に加わった項は「一覧」のとおり（1-1〜1-5・2-2〜2-5・3-10 ほか）。

• このうち裁定待ちの 1-1（最終窓の終端）と 1-4（at 後段の註釈点）は、選ぶ案によっては評価結果が変わる——1-1 の「落として註釈」案と 1-4 の「点保持に揃える」案。「現状を明文する」案なら意味論は変わらない。
• 分類は裁定時に確定する（「意味論を変える宿題ゼロ」の再確認は、この 2 項の裁定を含めて行う）。1-2・1-5 は表示形と JSON の形＝表面の 契約で、時点の集合は変わらない。

2026-10-01 の裁定後

• 1-4 は案 ③（現状維持＋spec §4.8 明文）＝［明文化］で意味論不変。
• 1-1 は案 A＝ADR-37 判断 4 の規範「過小近似は不可」の適用（改訂 6）——実装してみると点集合は変わらず註釈が増えるだけ （選択子行は点を保持して拡幅・coincides は偽の確定を範囲外へ）で、評価結果の差は註釈のみ。
• 「意味論を変える宿題ゼロ」は維持（裁定票の「落として註釈・評価結果が変わる」は選択子行の字面の読み違いで、実装は選択子行どおり）。
• 1-2・1-3・1-5 は 87 へ合流（言語側は明文化 2 行のみ）。現役 27 項。

This site is open source. Improve this page.