日本語 · English（未訳）

宿題・保留事項

確定していない論点、後で扱うと決めて棚上げした事項を集約する。着手時に該当 ADR/構文へ移す。

分類（RC の DoD: 全宿題が「意味論を変えない」ことの再確認・2026-07-07 実施）——各項に次のいずれかを付す。 ［純命名］＝名前の一括置換で済み意味論不変。［追加拡張］＝新語・新構文の追加で、既存の式の意味は不変。 ［スコープ外連動］＝言語外（実装系・供給側）との接続で、言語仕様には器・規格のみが返る。 ［明文化］＝既存規範の字面の確定のみで意味論不変（2026-07-08 追加・F70 用）。全項がこのいずれかに 落ちることを確認済み——意味論を変える宿題は残っていない。 （補助タグ: ［実装宿題／実装最適化］＝言語仕様に触れない実装課題・［記録のみ］＝受け皿記録。 いずれも意味論不変の側。）

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 に差分確認を行う）。

設計上の宿題

• 窓列への周期ラベル付け（labels: の cycle 形） → ADR-47 で確定・実装済み （2026-07-25・候補設計 draft §1.28＝4 視点並列検証→設計者裁定 3 件→ADR 化・実装・テスト 15 本・ reference 英日まで即日貫通。守るのは位相の宣言のみ〈同長性検査なし〉・照合は doctest/coincides の分担。第 5 便 §3 の実需への回答——次便で供給側へ案内する）。

• TZ の定義（F55） → ADR-33 で確定（2026-07-08・設計者裁定 3 件＝射影パラメータモデル・ DST 隙間/重複リテラルは 1.0 明示エラー・chronos はうるう秒を持たない一様な理想化軸＝UTC の各日を 86,400 秒と数える）。F54 の統治は ADR-36 で確定（整列検査の tz 名不一致・同日に F56 も確定）。 残る帰結の宿題: DST の解決規約（gap＝ロール規約と同形・overlap＝選択子と同形の opt-in premise メンバー）は将来拡張として口だけ確保＝［追加拡張］。tzdb の版供給（socket・実装系同梱）は ［スコープ外連動］。

• 出所 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 の実践の型）。

• カレンダーデータの供給モデル［スコープ外連動］: 更新主体は言語が規定しない（ADR-15 でデータ供給を切り離したため外部で自由に 選べる）。出所を明示できれば中央集権不要で、分散供給（リポジトリ・モデル。出所ごとに独立供給者、利用者が選んで 重ねる）が可能。言語は規格（差し込み口＋出所表記）だけ決める。AI は出所の加工役にはなれるが、真正性の出所 そのものにはなれない（設計上の線引き）。 供給側の実装は外部の定期取得基盤で検討中（非公開の別プロジェクト。「源を定期取得→正規化→ 差分検知→発報」型の基盤に、暦要項を年次取得する供給部を足す形）。取得結果は Kairos の テーブルリテラル（時点列＋labels:。ADR-26/30）へ流し込むデータ源になり、source:＝NAOJ、 asof:＝取得年/取得日時が供給側の保存時刻に対応する。Kairos の器（テーブルリテラル・source/asof）と 供給側（取得・保存・鮮度）の接続が socket（下記・外部供給宣言）の具体像。実装は供給側の課題で Kairos 言語のスコープ外。 追記（2026-07-09・適用検討 01）: 消費側（実装系ランタイムの定期実行定義＝発報層）の検討を 適用検討 01（非公開）で実施。PoC は「DB → Kairos ソース文字列を生成して前置」（実体 premise に source/asof/covering を焼く）で成立——external() 宣言が無くても供給は回るという対比が socket の 要否判断の材料（宣言 1 行の価値は「生成コードの排除」と「整列の主張の器」に絞られる）。 追記（2026-07-13・発報層還流第一次＝実装の実測）: 生成方式の痛点 2 件が確定—— (1) ソースは静的でいられない（日次再実体化ごとに DB から再生成が必要＝プロバイダ形 string | (() => Promise<string>) への拡張が必須だった。socket なら「式は静的・データは実行時 解決」に分離でき、再実体化は同じソースの再評価で済む——生成方式では差分検査で決定性を担保する 回り道）、(2) 統治の焼き忘れが起きうる（前文 asof: を生成器に焼く工夫を足すまで、註釈・ 被覆サマリがデータ観測日を運ばなかった）。実装後の見立て＝「socket 宣言 1 行の価値は生成器に 写経される統治の量（covering 必須・asof 焼き込み・昇順正規化）に比例」。判断材料は本 2 点＋ F98（空データの一次形・下記）。受領収蔵＝適用検討 03（非公開）。 判断済み（2026-07-14）: 外部供給宣言は external として採用・確定（ADR-46——下記 socket 項参照）。生成方式は引き続き合法（external は乗り換え可能な上位互換の器）。 追記（2026-07-24・発報層還流第二次第一期＝運用観測台帳）: 初の完全サイクルを実測受領 （実データ取得→10 日前の実体化で発火予定を予告→予告どおり配信・予定比 +0.7 秒。日次再実体化 10 日と再起動 2 回を跨いで予定不変＝決定性〈spec §7.8〉の実運用実証）。運用信号（runway 警告・範囲外註釈の実発火）は未観測（次の観測点=2026-10 中旬の残走路割れ・2027-01 の covering 切れ）——ADR-37 系の実地検証と external への乗り換え（供給側の第二段予定＝ADR-46 の実地検証）は 第二期以降の台帳で受領する。収蔵＝適用検討 05（非公開）。 追記（2026-08-08・発報層還流第 10 便第一部＝external 初本番と予実照合の実装報告）: external 新方式の初本番配信（2026-08-07 立秋）が成立——予定どおり発火・冪等 1 行・ホスト 7 種の入替を跨いで next 不変・asof 成分更新による再通知なし（ADR-46／イベント同一性設計の 実運用実証・第一部。次候補日の第二部で 1 サイクル完結予定）。運用側は「予定側テーブルなしの 予実照合」（定義＋供給からの決定的再評価 × 冪等台帳）を実装し検証 green——CLI の JSON 出力（CliReport）互換をエコシステム側が採用した実績 1 件目。需要 1 件（急がない・実装期 需要）: CLI に供給注入の口——external の解決子を静的束で渡す --supply <file.json> （{dates|instants, covering, asof} の束）。無いと供給依存定義が CLI 単体で評価できず、消費側に 評価グルーの二重保守が生じる。既存の器との対応＝公開 API RunOptions.resolve（ADR-46）と doctest # resolve:（dates wire）が既にあり実装は薄い見立て。論点＝(a) キーは source 名か 束縛名か（named-arg 上書きで source は多対一になり得る——束縛名が一意で安全）・(b) instants wire の JSON 表現。収蔵＝適用検討 12（非公開）。→ 採用・実装済み（同日 2026-08-08・ 設計者裁定「1.0 の前に」）: CLI --supply <file.json>——キーは束縛名（"premise.束縛名" 修飾が優先）・instants は epoch ms 数値列（CliReport の points と同規約）・CLI は JSON の形のみ 検査し供給契約 12 種は評価器の検査に委譲・--supply 無しの解決は従来どおり供給エラー。 被覆サマリの asof/残走路は供給値から出る（impl/README に文書化・507 テスト）。

• WKST の非二択性 → 反映済みで閉じた（記録として残す）: 週の開始は月曜／日曜の二択ではない。土曜始まりの 組織が実在する。WKST は premise として扱い、取り違えがサイレントな誤結果を生むため宣言必須寄り（ADR-24 に反映 済み。構文でも確定＝前文の宣言必須寄りメンバー wkst:。30-syntax §1.6）。

構文レベルの未確定事項

（詳細は 30-syntax/00-syntax-draft.md の第 4 節）

• 年度ラベル・序数の射影 → ADR-27/30 で解消（2025 年度＝開始暦年／US FY＝終了暦年で規約が異なる）: 独立機構でなく窓ラベル付与（label: 引数）のラベル式の与え方の問題に変わり（ADR-27）、付与式の設計 （別点の窓参照は可・隣接窓は射程外）も ADR-30 で確定した（のち ADR-34 で「別点」は先頭点＝代表点への 参照に精密化）。
• rephase（旧仮称 shiftBoundary）の射程外＝k（W ⊃ U の個数）可変な組（month ⊃ day を day 単位で ずらす等）の別演算子（必要になれば。§1.12。boundary の語はそちらに温存＝rephase 裁定 2026-07-26）。 ［追加拡張］（既存 rephase の意味は不変）
• 命名: 完全確定・仮称ゼロ（2026-07-26 完了・spec §5.4）［純命名・完了］——grid/span/split/cycle・ anchor:/phase:/by:・with は RC1 で確定（40-examples の検証で綻びなし）。 (a) axis の二義 → ADR-29 で解消: 基底の字句名は chronos（型名 Chronos）、操作軸 axis: は そのまま正式名に確定。 (c) 射影一族の名 → RC2 で確定: ordinalIn/epochOrdinal/snapTo・label:/labels:・covering: を 正式名に確定（内部設計の確定＝ADR-30 と綻び出し＝04-projections で名への綻びが出なかったため。labelOf は ADR-30 で廃語）。 F51 の一括確定（2026-07-09・設計者裁定）: nonWorking・coincides・rebase・ bizOpen/bizClose/isOpen はそのまま正式名に、供給の対は sessionOpens/sessionCloses に 改名して確定（ADR-41 改訂・正本は spec §5.4）。 (b) shiftBoundary → rephase に裁定・命名完全確定（2026-07-26・設計者裁定＝1.0 宣言時 予定を前倒し）: 展開の実体（span の phase: 差し替え）との一致・rebase/anchor: との 語彙系対称・簡潔（7 字）の三点。比較表と経緯は 30-syntax/01-shiftboundary-naming.md（裁定結果を追記済み）。 これで仮称はゼロ——命名の宿題は完了。 （日付・幅リテラルの字句は ADR-28 で確定済み）。
• 並列 week 窓の生成語 → §1.16 補で解消: 専用生成語は不要。week = day |> segmentBy(weekStart)（weekStart ＝wkst ラベル日、前文メンバーの遅延解決）で立ち、パーティション性は I5 検査で証明。nextWeekday は within(week) 展開を撤回し前方 roll（ラベル軸）で再定義（F30/F31。selectWeekday は廃語）。
• of: が匿名窓（segmentBy の窓）を指すときのラベル付け。裸ストリームへの of: 付き選択子の窓解決規約 （40-examples F27）もここに合流。［追加拡張］（現状は曖昧＝静的エラーの安全側。参照手段の追加）
• ストライドを窓ごとにリセットして数え直す版の記法 → ADR-27 で解消: ordinalIn への還元で専用記法を 設けない（filter(d => (ordinalIn(w, d) - 1) mod n == 0)）。
• 射影一族の内部設計（04-projections.md の綻び出しで六点） → ADR-30 で確定（2026-07-07）: (1) ordinalIn は二窓引数（粒度非依存）、(2) labelOf 廃止＝束縛名で読む、(3) 点はラベルを格納せず射影で 読む（型を拡張しない）、(4) ラベル付きテーブルは labels:、(5) label: は別点窓参照可・隣接窓は射程外、 (6) snapTo は点変換として残す。名も RC2 で確定した（spec §5.4）。
• カレンダー実体の束の宣言構文 → ADR-35 で確定（2026-07-08）: 実体＝予約公開語 nonWorking（正式名に確定＝F51・2026-07-09）を持つ premise（新構文ゼロ・正体判定に day 整列と tz: 必須を追加・ bizDay 標準導出は言語規定で calendar: 在圏の予約名・軸位置の premise 名＝F53 の読み替え規約・ member 解決規則＝定義側優先・派生の source: 上書き必須寄り）。粒度整合（F56）も ADR-36 で確定 （整列の静的検査。F54 の詳細＝tz 名のリテラル等値も同時確定）。impl 実装済み・147 テスト通過。 設計検証（7 視点・指摘 70 件）で新綻び F67〜F70 が新出（下記・正本は 40-examples/90-findings）。

• 外部供給宣言（socket） → external として確定（ADR-46・2026-07-14・設計者裁定＝採用・ 宣言語 external）: 実行時に解決されるテーブルリテラル——kind:（整列の主張＝ADR-36 帰結の解決）・ labels:（値域の列挙）・covering/asof は解決値が必ず運ぶ（供給契約）・解決は評価文脈の随伴（一評価 一解決・要求駆動）・解決失敗は供給エラー（機械可読な部分類——「まだ無い」〈ADR-45 の空テーブル〉 と型で区別）。判断材料＝発報層還流第一次の実測痛点 2 件（静的ソース不可・統治の焼き忘れ）＋F98。 候補設計 draft §1.27（3 視点検証・致命 0）→ ADR-46。正本は ADR-46・spec §3.8・reference/external.md。

• 空ストリームの被覆主張の一次形（F98） → ADR-45 で確定（2026-07-14・設計者裁定 2026-07-13＝候補 3 形〈空テーブル合法化・empty 生成子・恒偽の標準述語〉から (a) を選択→ 候補設計 draft §1.26→3 視点検証〈致命 0〉→ADR 化）: 「点ゼロだが覆域は主張したい」束縛の 一次形（発報層還流第一次 §1-1＝還流ルート初便の新綻び）は空テーブルリテラル [] covering: … で確定。covering 明示必須（省略既定「列の端」が空列で定義できない）・ labels: [] のみ合法・各検査は空虚に成立・整列は空虚適合の第三状態（ADR-36 改訂 3）。 生成器はテーブル直書きなら行数 0..N で同一の出力形（行ゼロ分岐が消える）。検証の副産物＝ F99（roll 空軸の依存像の impl 欠陥・解消済み）。socket（上記）の要否判断の前提が揃った。
• 細粒度カレンダー軸の予約語・導出形（F67） → ADR-41 で確定（2026-07-09・設計者裁定 3 件＝標準導出を規定・同時刻対は両点保持・isOpen は実体相対）: 供給規約＝実体の予約公開語の対 opens/closes（仮称・市民座標の壁時計宣言）・標準導出 bizOpen/bizClose/isOpen（実体相対）・ 整合性検査（局所交互・結合実効被覆域・データ相対層）。F81/F83 は ADR-31 改訂 2（時刻付き anchor の 窓境界＝壁時計ラベル読み〈F87 の impl 修正込み〉・shift は経過保存の明文化）。残件: F90（帰属ノブ・ 需要待ち）・F91（束縛右辺の複数行継続）・F77/F78（糖衣・射影は従来どおり）。旧記録: nonWorking は day 整列の予約語に確定 （ADR-35）。半日休・営業時間帯（同じ実体の中の別束縛）を読む bizHour 級の標準導出は未設計。 追記（2026-07-08・論点 (1) 完了）: 既存語彙の書き味を 40-examples/06-business-hours.md で 実行検証——毎営業日 9 時（壁時計＝strideBy(1d, from: …T09:00) の規定済み語彙）・営業時間内の 毎時・営業帯＋半日休（11:30 引け）・DST 切替日・深夜営業の帰属、いずれも確定語彙のみで 書けた（doctest 通過）。新しい予約語・新構文・新射影は表現力の必然としては不要。 敵対的検証 4 視点（指摘 20 件・全反映）で impl 欠陥 1 件も発見・修正（F82＝窓リーダーの覆域検査）。 (a) F79＝置き場所の作法か標準導出か・(b) F81/F83＝未規定の器の規定・(c) F76＝経過/壁時計の 二意味論と既存正準例の扱い → ADR-41／ADR-31 改訂 2 で確定・反映済み（2026-07-09・上記 裁定 3 件の内訳＝F79 は標準導出を規定〈isOpen を作法に留める案は却下〉・F76 は設計原理「文化は premise 層の決まり」で正準例を壁時計形へ差し替え〈ADR-38 改訂・coincides.md〉・F81/F83 は器の 規定。反映先リストも全件消化＝90-findings F76〜F85 節末尾）。残るのは (d) F77＝帯構築の糖衣（F1 の器・頻出確認後） → 見送りで閉じた（2026-07-24・設計者裁定＝ 1.0 前の完結）: 初期観察＝発報層還流第一次で日内時刻オフセットの同型定型が 3 出現、第二次第一期 〈2026-07-24〉＝運用期の新規 0——糖衣需要は実装期に集中する分布と判明し、頻度待ちでは自然に 閉じない構造のため裁定で閉じる。再開条件＝1.0 後、新規実装局面（新アプリ・新ジョブ群）で同型が 再頻出したら需要駆動で（運用観測台帳のカウント受領は継続）。残るのは (e) F78＝壁時計の時刻値射影（保留寄り・需要待ち）。
• 窓所属ベースの結合（F68） → ADR-38 で確定（2026-07-08・設計者裁定＝値述語一語）: 窓所属述語 coincides(S, w, d)（仮称・射影一族＝値式の有界存在量化）。証人規則の三分岐（真＝ 非註釈区間の証人・範囲外・偽＝実効被覆域内）・tz 名の静的検査（クロス tz の裏口封じ・F69 は 引き続き宿題）・窓語 S / cycle 名 w は静的エラー。糖衣（except 級）は頻出確認後に F1 の器で。 検証で F75（filter 輸送の逆像拡幅——ADR-37 改訂 2 で解消）が新出。命名は仮称三語目 （比較候補 hits・anyIn・sharesWindow を ADR-38 判断 9 に記録）。
• 日付ラベル保存の再錨（F69） → ADR-40 で確定（2026-07-08・設計者裁定＝点変換）: rebase(to: "tz")（仮称四語目）——day 固定（month/year は多対一で単射性が破れる）・着地は「最初の 瞬間」・存在しない日付（Pacific/Apia 2011-12-30）は明示エラー・免除系の tz 名検査を同時拡張 （ADR-36 改訂 2＝既存の潜在穴）。将来候補: 時刻保存の再錨（rebase＋同 tz 化後の coincides の合成で 当面書ける）・w 一般化（単射性の主張ごと再設計）。
• 値式の三角関数（sin/cos）［追加拡張・見送り寄り］: 真の朔弦望（Meeus 級）を言語内で 計算する唯一の欠け（2026-07-11・月相の三段整理＝40-examples/03 §3.4 追記）。平均朔望月の算術 近似は現行語彙で書ける（実行検証済み・NAOJ 朔日と 8/12 一致）が、精密計算は周期項の総和に 三角関数が要る。導入しても官暦との一致（真正性）は買えず、係数列の持ち込みは実質データと 同型のため見送り寄り——需要が立ったら再考。
• location:（地点）メンバーの第一級化［追加拡張］: 日の出・日没系のデータ premise は地点依存 （40-examples/05）。現状は地点ごとの premise ＋ source: に地点を含める形で表せるため、第一級 メンバー化は糖衣候補（tz: と同様の文脈値になる見込み。socket の供給モデルとも連動）。
• stride(n) の軸相対カウントの操作的意味（F70） → ADR-38 で確定（2026-07-08・設計者 裁定＝入力相対）: 軸引数なし（§1.9 の on: 行削除＝表面の削減）・from: 以上の最初の入力点が第 0 歩・ n は 1 以上の整数（stride(0)＝黙って空の既存バグを封止）。ADR-36 の stride 整列検査は削除（改訂）。

• 40-examples の綻びからの小粒宿題 ［いずれも追加拡張］: 標準糖衣の整備（onMonthDay・nthWeekdayOfMonth 級。F1。糖衣は core への展開で意味論不変。hour 窓は ADR-50 で確定・実装済み〈2026-08-17・ 4 視点検証が初版較正を実測棄却→全面改稿→同日 ADR 化・実装＝Gregorian に hour 追加＋ordinalIn 整合検査新設・テスト 6 本〉）、特定の窓インスタンス参照（year(2020) の日々。F9） → ADR-42 で確定（2026-07-09）、nth の 複数序数（F11）、cycle の積 zip（F16。述語合成で代替可）、範囲 shift の可変幅＝fold（F26）。振替の再帰（F8）と 隣接窓参照（F24）は射程外と確認（ADR-27）。

• 「列の先頭 N 個」の選択語（COUNT 相当） → ADR-49 で確定・実装済み（2026-08-17・ 需要の初証拠〈rrule.js #456〉→候補設計 §1.30→4 視点検証〈全視点支持〉→同日 ADR 化・実装 take(n, from:)・テスト 8 本。spec §1.2 の「できないこと」表から当該行を解消）。

• 点と日付リテラルの順序比較（d >= 2026-06-29）［記録のみ・F 採番なし］: 値層に無い（「数値ではない」）。 受け皿＝評価範囲の分離（第一）と epochOrdinal 序数比較（11 §(n) で実測）。ADR-34「点±幅算術を導入しない」 と同じ統治の帰結と読めるが、順序は算術と別問題ではある——需要が続けば糖衣候補。

• 「日集合に時刻を付与する」標準糖衣（atTime 級） → ADR-51 で確定・実装済み（2026-08-21・ 単独時刻リテラル Thh:mm＋stdlib 糖衣 at・4 視点並列検証→裁定「案 C」→同日実装。以下は経緯）: 還流第 12 便 B-1③（収蔵 13・ 2026-08-21）——供給側の配信系 12 箇所が snapTo(day) |> shift(+H, unit: hour) 形で、時単位窓の 実体化域照合により horizon-clip 警告が発火点数分（数百件）出る運用報告。壁時計正準形 （strideBy(1d, from: …T H:MM)＋coincides）は糖衣定義 1 本で畳めることを実測済み （§4.8——at7 = s => (everyInstant |> strideBy(1d, from: …T07:00)) |> filter(t => coincides(s, day, t)) で 3 形一致・警告ゼロ）＝今日から利用側で可能。裁定（2026-08-21）＝候補設計着手（draft §1.32）→ 4 視点検証（条件付き支持 4/4）→裁定「案 C」→ ADR-51。

• 「後ろから N 個」（take の過去方向・直近 N 発火） → ADR-52 で確定・実装済み（2026-08-21・ takeLast(n, until:)・4 視点並列検証→裁定→同日実装。以下は経緯）: ADR-49 判断 6 は需要未確認で 導入見送り——還流第 12 便 A-3/B-3（収蔵 13）が実需要の第 1 号（レシピの「直近の発火例」 表示・年数回レシピで 366 日窓評価の代替運用中）。導入するなら「終端起点の数えが covering 依存に なる」論点（ADR-49 記載）ごと裁定。裁定（2026-08-21）＝候補設計着手（draft §1.33）→ 4 視点検証 （支持）→ ADR-52（until: の明示錨が covering 依存の却下理由を構造的に解消）。

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

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

• 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 後。

• 静的 labels の窓数検査 × 実装地平線の交差（狭い評価窓での偽エラー）［実装宿題・意味論不変］: マーカー実体化が計算範囲（to+400 日）で切られるため、覆域がその先まで延びるテーブルマーカー ＋静的 labels: の束縛を狭い評価窓で評価すると「ラベル数 ≠ 窓数」の偽エラーになる （spec §4.2 の建前は「覆域基準＝評価範囲非依存・exact」——実装が仕様に追いついていない面。 2026-08-26 の宣言日実測〈朔 38 点×20 日窓〉で当方も実地に踏んだ・第 15 便 §2 の「labels: の 窓数検査が先に立ち 45 日窓では届かない」と同じ既知面）。回避＝通年評価。是正候補＝マーカー 実体化のみ覆域端まで延ばす／検査を実装地平線に気づかせて horizon-clip 警告へ落とす。1.0 後。

• 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 は 「再記録が効く」側を守るもので、この非対称は封じていない。

• at 後段での註釈区間内の点の脱落——素の列（点保持＋註釈）との規約差［1.0 後・規約統一の 要否］: 結合子（|・&・\）で覆域つきの表と結合した列に at を置くと、各項の実効被覆域の 共通部分の外の点が at の展開（coincides の証人規則＝註釈区間の点を証人に採らない）で落ちる。 素の列は同じ点を註釈つきで保持するため、時刻付与の前後で点集合が変わる（還流第 15 便 (e)・ 第 20 便 §3 で 3 結合子とも実測・警告なし・註釈は残る）。第 15 便回答の裁定「恒久の防御は覆域の側」 は維持——ただし「註釈区間の点を出すか落とすか」の規約が段によって違うのは説明責任の対象。 候補＝①at 段も点保持＋註釈に揃える（証人規則の緩和）②素の列も落とす（不採＝データの端で言う原則に 反する）③現状維持＋文書（reference/at.md・combinators.md に明文化済み・2026-09-03）。1.0 後に需要と 実害で判断。

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

• 表記の統一（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 化の際に一括統一が筋。
• label: 付与式の具体形 → ADR-34 で確定（2026-07-08・設計者裁定＝ラムダは窓の先頭点を 受ける）: 意味論は定義的等式「名前(d) ≡ 付与式(先頭点)」（射影時・遅延）・点±幅算術は導入しない・ 自己参照は禁止・「別点の窓参照」は代表点への参照に精密化（ADR-30 改訂）。データ由来窓の epochOrdinal（F60）・div/mod の floor（F63）も ADR-31 改訂で同時確定。 派生宿題: 束縛名射影 year(d) と F9 year(2020) の同名適用の型規則（F64・F9） → ADR-42 で確定（2026-07-09・設計者裁定 4 件＝逆像・展開後 dispatch・標準ラベル year/month/Fiscal.year・域外静的エラー）: 統一原理「位置依存の名前解釈」（軸位置＝ADR-35 判断 4・点引数＝射影・値引数＝窓インスタンス参照の三面）の受け皿ごと確定。検証で当初案の 構造欠陥 F93〜F95・stdlib 波及 F96 を裁定前に修正、新宿題 F97（下記）。 検証で追加確定・新出（ADR-34 期）: shiftBoundary の合成位相は k を法に正規化・base の label: を保存（F65・確定済み）。字句の残る未規定（F66）と F97（日付リテラルの裸の値束縛） → ADR-43 で確定（2026-07-09・設計者裁定 3 件）: (a) 日付部の値域は字句エラー（2026-02-30 級の 拒否——impl の黙ったロールオーバーを封じる）、(b) 固定オフセット tz は厳格一意形 "±HH:MM" のみ （ADR-36 のリテラル字面等値が依存する一意性・"Z"/"+0900" 級は字句エラー）、(c) 時点は値型の 一員（裸の値束縛は合法＝F97 解消・ADR-42 の dispatch 表は「点以外の値」に精密化）。
• stdlib 拡充で出た仕様の穴（F60〜F63）［追加拡張］: (a) データ由来窓の epochOrdinal（F60） と (d) div/mod の負数＝floor（F63） は ADR-31 改訂で確定（2026-07-08）。 (b) 被覆域・計算範囲の外の点の扱い（F61） は ADR-37 で確定（2026-07-08・設計者裁定 4 件）: 範囲外出自＝区間註釈（covering は値に触れない・包含の静的検査・輸送表・実効被覆域の分類器・ 註釈＋被覆サマリの器の二形・開端/区間リスト covering・束縛後置の被覆主張）。検証で出た当初案の 構造欠陥 4 件は F71〜F74（90-findings・解消済み）。残り: (c) 並行値リストと窓数の同長性検査（F62） → ADR-39 で確定（2026-07-08・設計者裁定 2 件）: segmentBy の labels: 一般化（三ラベル源の対称完成・窓列序数・覆域基準の同長性検査・整列を崩す 組み合わせは全部静的エラー＝clip/drop/同居/規則マーカー・未知 named-arg 検査も同時に規定）。 守るのは長さのみ——中身の照合は doctest＋coincides の分担（「解消」でなく「器と正準形の確定」）。 将来候補: 窓束縛へのラベル後置（kyuMonth = lunarMonth labels: … 級・二重束縛の相互整合を構文で 立てる形）・マーカー束縛名共有の警告級検査。
• ADR-37 実装の残件［実装宿題］ → 全消化: (a) 判断 1 の tz: 宣言必須の執行は解消 （2026-07-08・多 TZ 実装で全面執行。stdlib との衝突は杞憂だった——規則だけの premise は日付テーブルを 持たず対象外・データ入り premise は宣言済み。base 連鎖の宣言可＝内側固定と整合）。(b) doctest の 註釈照合規約も解消（2026-07-13）: #~> 行を新設（区間註釈＝CLI と共有の正準一行形 formatAnnotation・警告＝警告: 前置・出現順照合）、既定は厳格＝行が無ければ「註釈ゼロ・警告 ゼロ」の主張（ADR-39 の黙殺封止と同じ作法）。導入時の掃引で既存例 11 ブロックの正当な退化（データ端の 範囲外出自）が即検出され #~> を明示——「退化するが観測可能」が文書の実行例にも貫通した。規約の正本は reference/README.md。

• リファレンス実装の試作で出た綻び F43〜F50 → 全件解消（2026-07-07・正本は 40-examples/90-findings.md）: 未規定 4 件は ADR-31（grid の既定整列＋anchor:・紀元＝言語既定 1970-01-01＋epoch: メンバー・stride/strideBy の from: 必須化）と ADR-32（文字列リテラル導入＝ tz: "Asia/Tokyo"）で確定。例の不整合 4 件（F45〜F48）は字面修正で解消済み。

• 業務定型記述可否還流の記述ギャップ 4 件（F100〜F103） → 全件確定（2026-07-15・受領翌日の 実測検証＋設計者裁定＝「回答＋doctest 追補で閉じる」）: 4 件中 3 件は既存語彙で記述可能だった （報告側の語彙認識ギャップ＝発見性の問題として reference に定型例の doctest を追補）—— F100 修飾参照 Cal.holidays |> shift(-1, unit: day)（nonWorking.md）・F102 within＋nth の正準形 （nth.md）・F103 stride(2, from: 特定日)（stride.md）。F101 のみ stdlib へ同梱（daysInMonthOf ＝§4.9 糖衣ファミリの対称完成・gregorian）。付随の仕様確認＝roll(on:) 匿名軸は保証 （§5.6＋F7 の帰結・roll.md に doctest 化）。言語変更ゼロ。正本は 90-findings F100〜F103。

再検討候補（統廃合した語・実例で綻びたら戻す）

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

• where → filter の統合（spec §3.5） → 統合維持で閉じた（2026-07-09・設計者確認）: 再分岐の基準は「両層の実例で綻ぶなら」だったが、filter は両層で既に広く実戦使用（39 ファイル・ premise 層でも stdlib・実体定義で常用）され、複数回の敵対的検証でも可読性の綻びは一度も出なかった ——基準充足。where の再分岐はしない（filter 一語で確定）。
• |> に合成の意味も持たせた件（spec §4.8 の略記 A）［糖衣の削減＝core 意味論不変］: ポイントフリー糖衣で |> が「値→変換の適用」に加え「変換→変換の合成」も担う。型で区別され一義とみなす立場だが、実装・可読性で 綻ぶなら基底 B（s => 明示）のみに戻す余地。

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

• 発報・タスクの実行・管理（列の解釈、ジョブの起動、リトライ、状態追跡）。言語 Kairos は発報すべき時点の集合 （外延）を定義するところまで。その列を解釈して Chronos 上で実際に発報・登録・起動するのは実装系の責務。 但し書き（2026-07-11・設計者の洞察）: 「実行起点相対」のうちスコープ外はフィードバック （前回完了ごとの無限ストリーム）だけ——注入された時点からの次回計算は射程内で、現行語彙の 純関数として書ける（新語彙ゼロ・実行検証済み。spec §7.7・40-examples/07）。
• 発火点列への値随伴出力（点にラベル・射影値〈六曜名・干支名等〉を随伴させて出力する手段） ——配信ペイロードの構成は供給側／実行系の責務（発報層還流 第 5 便 §4 で照会・2026-07-25 追認）。 但し含みを残す（設計者考察）: 点列出力の「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）。

This site is open source. Improve this page.