日本語 · English（未訳）

構文仕様（初版・作業中）

本書は本体層の構文の作業中ドラフト。記法はすべて暫定（仮称）であり、確定した事項と未確定の事項を区別して記す。 根拠は各 ADR。

1. 確定している方針

1.1 記号の三役（ADR-22）

1.2 基本形

本体式はパイプ主体で、各段の引数は名前付き、必要に応じ括弧で確定する混成。

生成子 |> 点変換 |> 選択子 |> …

1.3 前文と本体の分離（ADR-18）

premise 宣言（前文）と本体式は分割する。本体式は可能な限り一行、前文は一行にこだわらない。前文は @名前（軽量形）または premise { ... }（完全形）で premise を供給する（具体構文は §1.6）。危険な premise （カレンダー・ロール規約）が前文でも段でも解決できなければ静的エラー（ADR-16）。

1.4 core 族と糖衣（ADR-23）

日常は糖衣で短く書き、意味論は core 族で厳密に定義する。糖衣は core への展開で定義され、消せる。

1.5 窓記法（ADR-06/07/08/24, I4/I5）

窓は二種を別演算子に分ける（ADR-08）。パーティション型は窓名を、区間列型はマーカーのストリームを 取り、引数の種類が根本的に違うため一本化しない。

パーティション型 within(w) — 軸を余さず分割する窓。w は窓名（day/week/month/quarter/ year、またはユーザ定義のパーティション窓。ADR-07）で、現在の premise（暦法・WKST 等）の下に解決 される（ADR-17）。網羅・無重複が検査可能（I5）。

everyDay |> within(month) |> last          # 各月の最終日

区間列型 segmentBy(m, edges:, empties:) — 任意ストリームのマーカーで切る窓。m はマーカーの ストリーム式（決算期・月相など。ADR-07）。窓は隣り合うマーカーの半開区間。網羅は保証されないため、 隙間の意味を明示する引数を必須とする（I5「隙間の意味を明示」の構文適用）。

隙間ポリシーの省略はサイレントな誤結果（データ欠損で静かに発報が消える。ADR-15）を招くため、宣言必須 （ADR-16 の危険な省略）。よく使う組は将来 gaps: strict 等の糖衣で畳める（ADR-23）。

everyDay |> segmentBy(fiscalCloses, edges: clip, empties: keep) |> first

選択子のレベル nth(n, of: w)／first(of: w)／last(of: w) — 選択子は既定で最内窓（直近の within/segmentBy）に束縛される。入れ子で対象が曖昧なときのみ of: w で窓を明示する。名指しした窓が WKST 等の premise を背負い、「第 N」の起点を定める（ADR-24 の二段依存＝選択子 → 窓 → WKST を局所化）。 窓なしの選択子は型エラー（I4）、曖昧なまま of: を省くのは静的エラー（ADR-16）。

everyDay |> within(quarter) |> within(month) |> nth(2, of: month)  # 各月窓の第 2
everyDay |> within(quarter) |> first(of: quarter)

1.6 前文（premise 宣言）の構文（ADR-16/17/18/19）

前文は ADR-16 のスコープ階層（既定 → 評価文脈 → ブロック宣言 → 段引数、最内優先）のうち評価文脈・ ブロック宣言の層を書く。ドメインモデル §1 の「同一の束縛操作の長短三形」を次の三形で与える。

定義（premise 層 / DDL・多行可） — @名前 が束ねる中身を定義する。

premise JP {
  calendar-system: Gregorian      # 暦法（構造）
  calendar:        TSE            # カレンダー（方針・営業日）
  tz:              "Asia/Tokyo"
  wkst:            Mon
  asof:            latest
  source:          "cao.go.jp/official"
}

軽量形（本体層 / DML） — 定義済みの束を前文に敷く。@名前 は単一値の別名（@TSE）でも 多メンバーの束（@JP）でも同じ参照（ADR-17/20）。

@JP
monthEnd |> roll(Preceding, on: bizDay) |> shift(-3, unit: bizDay)

完全形インライン — 名前を付けずその場で前文にする。

premise { calendar-system: Gregorian; calendar: TSE; tz: "Asia/Tokyo"; wkst: Mon }
monthEnd |> roll(Preceding, on: bizDay) |> ...

スコープ — 前文は以降の本体式を統べ、次の前文まで有効（契約の recitals に同型。ADR-16 の評価文脈層）。 範囲を明示的に括るときは @名前 { …本体式… } のブロック形（ブロック宣言層）。段引数は最内で前文を上書きする。

メンバー枠と省略の統治（ADR-16） — メンバーは暦法・カレンダー・ロール・粒度・TZ・asof・wkst・source。 危険なメンバー（取り違えがサイレント誤結果を生むもの）は宣言必須寄り、安全なメンバーは既定可。前文でも段でも 解決できない危険メンバーは静的エラー。

メンバー 省略時 危険性の根拠
calendar-system（暦法） 既定可（Gregorian） 取り違えは名前曖昧性で検出（ADR-17）
calendar（営業日カレンダー） 宣言必須 万能な既定が無い／別日を黙って出す
axis（軸） 宣言必須（言語既定なし） 軸取り違えで別結果（shift の 3 日／3 営業日）。§1.7
roll（ロール規約） 宣言必須 ADR-16 代表例・サイレント誤結果
wkst 宣言必須寄り 「第 N」反転（ADR-24）
tz 宣言必須寄り ローカル日がずれる（ADR-02）
source（出所） 宣言必須寄り 公式版／ローカル上書きの混同（90-open-questions）
granularity（粒度） 既定可（「日」） 明示でも既定でも結果不変が多い
asof 既定可（評価時点） 再現性重視なら宣言推奨

1.7 スコープ既定（on:/unit: の畳み込み。ADR-16/21）

on:（roll・filter）と unit:（shift）は、操作する軸を premise 相対に名指す （bizDay／day／hour…。cycle 名〈weekday〉はラベルでありストリームに解決されないので軸には 立てない。ADR-21。stride は入力相対＝軸を取らない——ADR-38）。軸は在圏の calendar: に解決される （bizDay は @JP なら TSE の営業日。ADR-17）。 特定カレンダーを直に固定する on: TSE も可。軸位置の premise 名の型は ADR-35 判断 4 の読み替え規約で 埋まる（F53 解消）: 束縛として解決できれば通常解決・premise 名としてだけ解決できれば読み替え（両方は曖昧＝静的エラー）、P が カレンダー実体であることを正体判定で要求し、「その段（またはそのスコープ）だけ calendar: を P に 上書きして標準導出 bizDay を読む」＝everyDay \ P.nonWorking（everyDay は在圏解決）。実体でない premise 名は静的エラー。calendar: 在圏では bizDay は言語予約の導出名（手動束縛は静的エラー）。

複数段が同じ軸を書く冗長は、軸を前文メンバー axis: に一度だけ宣言して畳む。省略した段は在圏の axis: から解決する。これは ADR-16 のレキシカルなスコープ既定（既定 → 評価文脈 → ブロック宣言 → 段引数、最内優先） であり、後段推論ではないため各段の局所性は保たれる（ADR-21）。

供給元はスコープ全域、最内優先で解決する。

  1. 束定義 premise JP { axis: bizDay } — 文脈全体で一つの軸を使うとき。
  2. 軽量形の後置 @JP axis: bizDay — 束は共有しつつ軸だけ本体寄りに与える（軸は本体ごとに変わり @JP は 安定、という粒度差に沿う置き所）。束定義に無ければここで供給、有ればここで上書き。
  3. 外側の評価文脈 — ファイル頭などの広域宣言。
  4. 段の明示 on:/unit: — その段だけ別軸に（最内、前文を上書き）。

axis: は宣言必須寄り（言語既定を持たない）。軸取り違えはサイレントな誤結果（shift の「3 日」と「3 営業日」は 別物）を生むため。畳み込みに頼る段があるのにどのスコープにも axis: が無ければ静的エラー。全段が on:/unit: を明示する本体は軸既定を要しない（各段自足）。同じ機構で roll:（規約）も前文メンバーとして束/後置で宣言し 段が継承できる。ただし危険メンバーゆえ規約は明示を推奨。

# 明示（軸を各段に書く）
@JP
monthEnd |> roll(Preceding, on: bizDay) |> shift(-3, unit: bizDay)

# 畳んだ姿（軸の既定を後置で本体に与える）
@JP axis: bizDay
monthEnd |> roll(Preceding) |> shift(-3)

# その段だけ別軸（最内優先で上書き）
@JP axis: bizDay
monthEnd |> roll(Preceding) |> shift(-3, unit: day)

1.8 結合子（和・積・差と優先度付き上書き。ADR-01/04/22）

結合子はストリーム × ストリーム → ストリーム。premise 層のカレンダー構築（祝日の増減）と本体層の横合成・ 例外日の両方で同じ記号を使う（ADR-18）。

優先度付き上書き（カスケード。ADR-01/04）は独立記号を持たず、和・差の左結合順序適用で表す。 宣言順 （後の項）が優先＝CSS レイヤーの後勝ち。ADR-01 が却下したのは「差・積だけの純フィルター」であり、和を含む 順序適用は対象外。加算（国民の休日）・移動（振替休日は元日を残し翌日を足す）＝和、反転（調休）・例外（ある年 だけ営業に）＝差、と分解できる。

# 非営業日カスケード（premise 層、後勝ち）
weekends | statutory | substitutes \ specialBiz

# 本体層（横合成・例外日）
tokyoBiz | osakaBiz          # 和
schedule \ blackoutDays      # 差

結合子はすべて同一優先度・左結合とし、優先度は式の順序で表す。&（積）が絡む混在は意味が順序に依存する ため、括弧で明示する（ADR-16 の明示志向）。

粒度整合（ADR-36・F56 解消）: &・\（と軸所属 filter(on:)/roll(on:)/shift(unit: 点列軸)）は、 両辺の整列（全点が同一の原子グリッド G＝幅・正規化位相・tz 名の目盛り上にある、 という導出構造からの静的主張）を要求する（stride は入力相対の確定＝ADR-38 で対象外に）。不一致・ 「なし」は静的エラー、整合の明示は意図で分ける——同じ点なら snapTo・同じ所属（日）なら coincides（§1.21・ADR-38）。和 | は不問（混合出力は整列なし）。詳細は ADR-36（改訂含む）・spec §4.5。

1.9 ストライド（走査して間引く。ADR-10/11）

ストライドは走査しながら数えて間引く状態付きオンライン変換（ADR-11）で、選択子とは別族。選択子（nth/last）が 窓を消費して窓相対に「第 N」を選ぶ（各窓→1 点・窓ごとリセット。I4）のに対し、ストライドは窓を消費せず「N ごと」に 間引く（境界を無視して連続・リセットしない）。「月境界を無視して N 営業日ごと」は選択子では書けず（窓リセット）、 これがストライドの存在意義（ADR-11）。「第 N」ではなく「N ごと」。

引数の種類で二演算子に割る（ADR-08 の窓分割と同じ教訓：軸単位の整数 vs 複数軸の物理量）。

演算子 引数 数えるもの 例
stride(n, from:) 入力カウント 1 以上の整数（違反は静的エラー） 入力ストリームの点（軸引数なし＝ADR-38・F70。何を数えるかは前段が決める） filter(on: bizDay) \|> stride(3, from: …)＝3 営業日ごと
strideBy(w, from:) 幅刻み 幅＝複数軸の物理量 幅（絶対量・DST 等は幅の規約 ADR-12） strideBy(24h39m35.244s, from: …)＝1 sol ごと（ADR-19） 
@JP
everyDay |> filter(on: bizDay) |> stride(3, from: 2026-01-05)    # 3 営業日ごと（入力相対＝前段が決める）
everyInstant |> strideBy(24h39m35.244s, from: 2026-01-01)        # 1 sol ごと（幅刻み）

数え起点は「from: 以上の最初の入力点」（第 0 歩＝残る。from: が入力の点であることは要求しない。 ADR-38）。

起点（位相アンカー） は from: で必ず明示する（無ければ静的エラー。位相の取り違えはサイレント誤結果。 ADR-16/I3）。かつての「前段の窓の起点から供給」は、窓が複数あるとき多義で評価範囲依存（I7 と緊張）のため ADR-31（F49）で廃止した。リセットは既定しない（境界無視・連続。ADR-11）。窓ごとに数え直す版は ordinalIn への還元（§1.17・ADR-27）で書く。

1.10 値式・変数（ADR-25）

premise 層は時間ストリームでない値式を持つ（ADR-25）。値型は数値・論理・列挙（Mon・Preceding 等）・ 文字列（"Asia/Tokyo"。ADR-32 で導入）。本体層の引数変数（将来の shift(n) の n）も同じレイヤー。演算子は 既存記号と衝突しないよう選ぶ（ADR-25 の統廃合）。

種別 記号
算術 + - * /、剰余 mod（語。論理と同じく英単語系）
比較 < <= > >= == !=
論理 and・or・not（語。記号 &／\| は結合子に温存）
条件 三項 cond ? a : b
束縛／等値 = は束縛（定義）、== は等値比較

述語と変数 — 述語は対象の各要素をラムダで束縛する。矢印は =>（型記法 -> と区別）。where は filter に統合し、filter が premise 述語（on:）と値式述語（ラムダ）の両方を取る（ADR-25）。束縛名で参照するので 入れ子でも曖昧にならない（ADR-16 明示志向）。

# 閏年規則（値述語）と月の非一様境界。窓生成語は §1.11 で確定（ボトムアップ集約が主）
isLeap      = y => y mod 4 == 0 and not(y mod 100 == 0 and y mod 400 != 0)
daysInMonth = m => monthLengths(isLeap(yearOf(m)))[monthOf(m)]   # 閏は m から値計算（year 窓を見ない）
month       = day   span daysInMonth
year        = month span (_ => 12) phase: 0

1.11 原始的定義の窓生成語と公開語（ADR-07/10/11/19/20/25）

原始的定義（Gregorian 等・派生元を持たない根。ADR-19）は、連続時間軸（基底。ADR-10）を窓へ刻んで暦法を 組み立て、公開語を生む。窓生成語は三系統＋一（窓を作る grid/span/split と、窓でなくラベルを生む cycle）。窓を作る三語はいずれもパーティション型窓（ADR-08）を作り、網羅・無重複が構造的に保証される（I5）。 依存はボトムアップ集約を主とする：原子 day を month に束ね、その month を year に束ねる（month が基本の括り）。year の従属窓（quarter）だけは year を split で割って作り、 year の変化に自動追従させる。この向きの選択には理由がある（下記「閏は窓でなく値」）。

語（仮称） 種別 意味 例
grid(w) 一様分割 連続軸を幅 w（物理量・DST は幅の規約 ADR-12）で等幅にタイル。暦の原子を作る。strideBy と幅概念を共有するが grid は網羅分割・strideBy は間引き（ADR-11/25） day = chronos grid 1d
span(f) 可変集約（ボトムアップ） 細かい単位の列を連続窓へ束ねる。f = n => 個数 は生成中の窓の序数 n（premise の紀元起点）を束縛し、束ねる単位個数を返す。個数は可変でも定数でもよい（month は日数可変、year は 12 定数） month = day span daysInMonth ／ year = month span (_ => 12)
split(g) by: u 可変分割（トップダウン） 親窓を連続部分窓へ割る。g = y => [幅…] は親の序数 y を束縛し部分窓幅のリストを返す。by: u は幅の単位を明示（「3 月」対「3 日」の取り違えはサイレント誤結果ゆえ ADR-16 明示）。幅総和が親に一致することは I5 で検査可能。従属窓（親に自動追従させたい quarter 等）に使う quarter = year split (_ => [3,3,3,3]) by: month
cycle(labels) anchor: 並列ラベル 単位窓に反復ラベルを付す。年・月に入れ子でなく並列に回る（曜日。ADR-03）。窓ではなくラベルを生む点で span/split と別。anchor: が位相（どの実日が先頭ラベルか）を固定。WKST（§1.6 の premise メンバー）とは別で、cycle は律動を・WKST は週選択子の「第一」を担う（ADR-24） weekday = day cycle [Mon,…,Sun] anchor: 2000-01-03

ラムダ束縛は §1.10 の => をそのまま用いる（新規判断なし）。span は生成中の窓の序数を、split は親窓の序数を 束縛する（向きの差＝ボトムアップは束ねる窓自身の序数／トップダウンは親窓の序数、がそのまま引数に出る）。

閏は窓でなく値（依存方向を決める要） — 「2 月は 28 日か 29 日か」は year という窓への依存に見えるが、 実際には month の通し番号 m から算出できる値依存である（m から暦年と月位置を割り出し isLeap で判定。 下の daysInMonth）。だから month を year 窓に依存させる必要がなく、month を基本の括り（day を束ねる）に 置ける。もし month を year の子（year split）にすると、派生（会計暦。§1.12）で year を month から束ね直す とき month ↔ year が循環する。閏を値依存と見て month を親に置けば循環は最初から生じない。これが上の ボトムアップを主とする選択の理由であり、§1.12 の会計暦が一行で・回避策なしに書ける根拠。

公開語（premise メンバー） — ブロック top-level の束縛だけが公開され、Gregorian.month のように . で参照 される（ADR-22・ADR-17）。窓束縛（month＝パーティション、within(month) で使う）と境界束縛を書き分ける。 境界は本体層の選択子を再利用して導く（新機構ゼロ）:

monthStart = month |> first     # 各月窓の先頭点
monthEnd   = month |> last      # 各月窓の末尾点（＝暦日の月末 5-31）

これにより §2.1 の生成子 monthEnd（暦法純粋・5-31 を出す。ADR-20・I8）の正体が判明する：それは公開境界語 Gregorian.monthEnd = month |> last そのもの。「生成子」は原始的定義の公開境界語である（別機構ではない）。 本体層は現在 premise 下で裸名を解決し（ADR-17）、曖昧なら Gregorian.month と修飾する。派生的定義（ADR-19・ 次段）はこの公開語をパイプ変換する（会計暦＝Gregorian.monthStart |> shiftBoundary(+3)）。

Gregorian（抜粋）:

premise Gregorian {
  day     = chronos grid 1d                                 # 原子（連続軸を市民日で分割）
  weekday = day cycle [Mon, Tue, Wed, Thu, Fri, Sat, Sun] anchor: 2000-01-03

  isLeap      = y => y mod 4 == 0 and not(y mod 100 == 0 and y mod 400 != 0)   # 値述語（§1.10）
  daysInMonth = m => monthLengths(isLeap(yearOf(m)))[monthOf(m)]  # 閏は m から値計算（year 窓を見ない）
  month   = day   span daysInMonth                          # 基本の括り：day を束ねる（year 非依存）
  year    = month span (_ => 12) phase: 0                   # month を 12 ずつ束ねる
  quarter = year  split (_ => [3, 3, 3, 3]) by: month       # year の従属窓（会計暦で自動追従）

  monthStart = month |> first                               # 公開境界語（選択子の再利用）
  monthEnd   = month |> last
  yearStart  = year  |> first
}

補助値関数 yearOf(m)／monthOf(m) は month の通し番号 m から暦年と月位置（0–11）を、monthLengths(bool) は 閏真偽から 12 か月の日数リストを返す（いずれも値式・§1.10。year 窓を参照しない＝閏は値依存）。ブロック内の 束縛は依存順に解決する（day → month → year → quarter）。相互参照は可、循環はエラー。名前・記号はすべて 仮（grid/by:/axis/日付リテラル等は第 4 節の残件）。

1.12 派生的定義（premise → premise の閉包。ADR-19/23/25）

派生的定義は、既存 premise（Gregorian 等）の公開語を上書き・追加して新しい premise を作る。premise → premise の閉包であり、本体層の stream → stream 閉包と対称（ADR-19）。典型は暦法の派生（会計暦）で、結果は元と同じ 資格で使える（calendar-system: Fiscal）。

core は with 上書き — base を土台に、指定した公開語だけ差し替え、残りは継承する。

premise Fiscal = Gregorian with {
  year = month span (_ => 12) phase: 3   # 暦月を 4 月始まりで 12 ずつ束ね直す
  # month は触れないので暦月・月末は不動（Gregorian のまま継承）
  # quarter は継承定義（year split by month）が新 year に自動追従 → 会計四半期 Apr-Jun/…
  # yearStart = year |> first も新 year に追従（4 月 1 日群）
}

名前解決（機構 A・ADR-17）:

日付は動かない（基底固定 ADR-09・I1） — 派生が動かすのは窓の切れ目だけ（ADR-19 の解釈 P）。暦日・ day/month/week・monthStart は不動。2026-03-01 は「3 月 1 日」のまま、所属する年窓だけが変わる （2025 年度＝Apr2025–Mar2026）。軸ごと平行移動する解釈 Q（Gregorian |> shiftBoundary(+9) で Oct が Jan に なる類）は却下済み（ADR-19）。Oct は Oct のまま、会計年度内の第 1 月という序数になるだけ。

パイプは糖衣、展開は span の位相ずらし一発 — 日常形は premise Fiscal = Gregorian |> shiftBoundary(+3, on: year, unit: month)。|> は premise 層では premise → premise を繋ぐ（閉包の対称。ADR-22 の段連結の premise 版）。shiftBoundary は上の with 上書きへ展開する糖衣（ADR-23）で、 展開規則は一般に：

shiftBoundary(δ, on: W, unit: U)  ≡  W = U span (_ => k) phase: (φ₀ + δ)
#   k  = W が含む U の個数（year ⊃ month なら 12）
#   φ₀ = base での W の位相（Gregorian の year は 0）

W を「U を k 個ずつ束ねる span」と見て、その位相を δ だけ進めるだけ。§1.11 をボトムアップに組み替えた （month が親）ことで、旧稿で懸念した split の分割リスト回転や k 可変の扱いは不要になった。k が定数でない 組（month ⊃ day を day 単位でずらす等）はそもそも「括りを単位個数でずらす」会計暦型の操作ではなく、 shiftBoundary の射程外（必要なら別演算子。§4 残件）。

直交する別ノブ（追跡） — 「2025 年度」の番号付け（開始暦年ラベル／US FY は終了暦年）は窓の切断とは独立した 序数・ラベルの射影で、規約が国ごとに違う。shiftBoundary に埋め込まず別論点として扱う（90-open-questions）。

名前・記号は仮（with・phase:・shiftBoundary）。phase: は §1.11 の窓生成語（span/split）の位相起点引数。

1.13 糖衣定義（core への展開規則。ADR-23）

糖衣（monthEnd・businessDays・nextWeekday 等）は core 族の合成に名前を付けた略記で、core への展開で消せる （片方向依存。ADR-23）。その定義を書く構文をここで確定する。要点は「専用の新構文は要らない」：既存の束縛 =（§1.10）に、右辺として core のパイプ列を書くだけ。§1.10 の値関数 isLeap = y => …、§1.11 の premise 公開語 monthStart = month |> first と、同じ = 束縛機構が右辺の型（値／premise／変換）を変えて現れているだけ。

基底 B（ラムダ明示） — 前段ストリームを s => で束縛し、s |> で core 列に流す。|> は「値 → 変換の適用」の 一義（§1.10 のラムダの素直な再利用、意味論が最小）。

businessDays(on: p) = s => s |> filter(on: p)
nextWeekday(d)      = s => s |> roll(Following, on: (everyDay |> filter(x => weekday(x) == d)))

（nextWeekday の展開先は当初 within(week) |> selectWeekday(d) としていたが、F30/F31 の綻びにより 前方 roll に改めた。§1.16 補を参照。）

略記 A（ポイントフリー） — 前段 s が素直に流れるだけ（先頭が s |> で s が他に現れない）なら s => を 省ける。これは B の eta 簡約であり、糖衣定義それ自体の糖衣（ADR-23 の自己相似が糖衣定義構文にも現れる）。省くと |> の左に変換が来るので、|> は「変換 |> 変換＝合成」も担う。ADR-22 の |>＝「段の連結」の枠内で、適用と合成は 型（値か変換か）で区別され一義は保たれる。§1.11 の公開語 monthStart = month |> first と見た目も揃う。

businessDays(on: p) = filter(on: p)
nextWeekday(d)      = roll(Following, on: (everyDay |> filter(x => weekday(x) == d)))

前段を名前で使う（分岐・再結合する）糖衣は A に畳めないので B で書く。

aroundMonthEnd(k) = s => (s |> within(month) |> last) | (s |> within(month) |> last |> shift(-k))

宣言印は付けない — 「これは糖衣だ（core へ展開できる）」ことは、右辺が core 語（＋既定糖衣）だけに依存する ことから依存解析で自動判定できる。sugar 等のキーワードは置かず = 束縛のまま（§1.10/§1.11 との統一）。core 語 （生成子・点変換・結合子・フィルタ・窓・選択子・ストライド）は言語組み込みの予約で、それ以外の名前付き束縛が 糖衣・公開語。core 語を再定義する束縛（片方向依存を破る。ADR-23）は静的エラー。

premise は焼き込まず遅延解決 — 糖衣は定義時に premise を固定せず、呼び出し時の在圏 premise で解決する （ADR-17）。nextWeekday の weekday ラベルは呼び出し文脈の暦法から解決され、糖衣自身は暦法を知らない （ADR-23・ADR-24）。week 窓の wkst 参照（§1.16 補）も同じ規則。複雑さは展開先の core が背負い、糖衣は薄い。

展開＝右辺の機械的差し込み — x |> nextWeekday(Fri) は定義右辺を差し込んで x |> roll(Following, on: (everyDay |> filter(x => weekday(x) == Fri))) に開く。全糖衣を展開すれば core だけが 残る（ADR-23）。premise 層のパイプ糖衣（shiftBoundary。§1.12）も同じ片方向展開で、そちらは premise → premise の with に開く。

1.14 暫定語彙（サンプル検証用・すべて仮）

40-examples/ の表現力検証（既知スケジュールのサンプル記述＝綻び出し）で使う、既出だが未定義の語を ここに一括で仮置きする。すべて（暫定）であり確定ではない。表記をここに固定するのは、サンプルごとにその場 発明すると表記が割れ、綻びの分析が濁るため。対応する宿題は 90-open-questions.md に登録済み。

語（暫定） 仮の定義 既出箇所
日付リテラル ISO 8601 サブセット 2000-01-03（日）・2026-02-11T09:00（時刻付き）。TZ は埋め込まず在圏 premise の tz: で錨を打つ（I6） anchor:（§1.11）で使用中
幅リテラル 数値＋単位接尾の並び。d＝市民日（規約幅）、h/m/s＝経過時間。例 1d・24h39m35.244s。市民時と経過時間の区別は ADR-12 の規約集合 grid 1d（§1.11）・strideBy（§1.9）
div 整数除算（mod と同族の語） yearOf(m)＝紀元年 + m div 12（stdlib/gregorian.md）
リストリテラル […]・添字 l[i] 値式のリスト構築と 0 起点アクセス monthLengths(...)[monthOf(m)]（§1.11・stdlib）
everyInstant 連続基底の全点を流す生成子（strideBy と併用） §1.9 の sol 例
cycle ラベルの述語参照 cycle 束縛名を「点 → ラベル」の値関数として読む: filter(x => weekday(x) == Mon)。cycle の律動（§1.11）と値式（§1.10）の接続 stdlib/gregorian.md §4.4 が説明文中で使用
selectWeekday(d) 糖衣 filter(x => weekday(x) == d) → 検証で綻び（F30/F31）: filter 形は入力要素自身を濾すだけで「窓内の d ラベル点へ写す」にならない。nextWeekday の決着は §1.16 補（roll のラベル軸版）へ §1.13
week 窓 WKST 位相の 7 日並列窓（月・年に非入れ子）。決着は §1.16 補（wkst: 遅延解決の segmentBy 定義） within(week)（§1.13・spec §7.2）
単位窓以外への cycle cycle の適用対象を任意のパーティション窓に読む（year cycle […]・month cycle […]）。anchor: は「anchor の属する窓が先頭ラベル」と解釈 例は weekday（day）のみ

1.15 データの持ち込み口（テーブルリテラル。ADR-26）

表現力検証（40-examples）で確定した最大の欠落は、周期規則から生成できない列（官報の春分秋分・朔・ 二十四節気・調休の特例日）を premise へ持ち込む口が無いことだった（F5）。受け皿（segmentBy・結合子・ カスケード）は既存語彙で足りる。設計は次の通り（ADR-26 で確定）。

テーブルリテラル — 時点リテラルのリストは時間ストリーム定数に昇格する。構文は値リスト（§1.14）と 同一で、型は要素で決まる（数値要素→値リスト、時点要素→時間ストリーム。要素ゼロは covering: の 有無で決まる——空テーブルの合法化は §1.26＝ADR-45）。列は昇順を要求（乱順・重複は 静的エラー。無限ストリームのマージ（結合子）が有限定数列でも成り立つための整列則）。

premise JPGazette {
  source: "cao.go.jp/official"
  asof:   2025-02-03
  vernalEquinoxDay = [2025-03-20, 2026-03-20, 2027-03-21] covering: 2025..2027
}

1.16 cycle の一般化（確定。ADR-27 に同居）

検証（40-examples 02）で cycle は周期長・適用先の一般化に耐えた。暫定（§1.14）を次の通り確定する。

§1.16 補: week 窓と nextWeekday の決着（F30/F31）

week 窓は Gregorian の公開語として次で定義する——右辺が前文メンバー wkst: を参照し、使用時の 在圏 premise で遅延解決する（糖衣と同じ規則。ADR-17）。wkst: 未宣言の premise 下で within(week) を 使うと静的エラー（宣言必須寄りの統治がそのまま効く）:

weekStart = day |> filter(d => weekday(d) == wkst)              # wkst は前文メンバー（遅延解決）
week      = day |> segmentBy(weekStart, edges: clip, empties: error)

生成は segmentBy（区間列型）だが、weekday の巡回により網羅・無重複が I5 で検査証明できるので within(week) に使える——「パーティション性は生成語でなく検査で立つ」。専用の窓生成語（span 位相版 or cycle 由来。§4 の宿題）は不要になった。層またぎ（§1.15）・ラベル述語（§1.16）・遅延解決（§1.13）の 合成だけで立つのがこの決着の要点。

nextWeekday は within(week) 展開を撤回し、roll のラベル軸版で定義する:

nextWeekday(d) = roll(Following, on: (everyDay |> filter(x => weekday(x) == d)))

理由（F31）: 旧展開 within(week) |> selectWeekday(d) は「同じ週窓の d 曜」を選ぶため、点が週後半に あると過去へ選択が飛び得る（wkst: Mon の下で土曜の点の「同週金曜」は前日）。要求「翌週金曜＝次の 金曜へ進む」の意味論は前方 roll そのもの。導出ストリームを軸に渡せる（§1.15・ADR-26）ので新語は不要、 selectWeekday は廃語。この定義は WKST 非依存になる（週窓を経由しないため）——「第 2 週の金曜」の ような窓序数依存の式だけが WKST を要する、という整理に揃う（stdlib/gregorian.md §4.4 と整合）。

1.17 窓→値の射影一族（候補設計。ADR-27）

六曜（旧暦月＋日の剰余）・旧暦の月名・ISO 週番号・年度ラベル・イースターの時点化・固定日祝日は、 検証の結果すべて同一の欠落に還元された（F2/F17/F18/F21/F23/F28）: 点から「属する窓」を経由して 値を読む手段が無い。選択子（窓 → 点）の双対として、射影（窓 → 値）を一族で導入する。

語（仮称） 型 意味
ordinalIn(w, d) 点 → 数値 点 d が属する w 窓の中で第何要素か（1 起点・窓ごとにリセット）。nth の逆向き
labelOf(w, d) 点 → ラベル/値 点 d の属する w 窓のラベル。cycle ラベル読み（§1.16）の一般形
snapTo(w) ストリーム変換 各点をその属する w 窓の先頭点へ写す（floor。節気の瞬間→日）。窓の属性（境界点）を読む射影のストリーム版
epochOrdinal(w, d) 点 → 数値 属する w 窓の紀元からの通し序数（§1.11 の窓序数 n・m と同じ座標）。yearOf/monthOf（stdlib）と接続

綻び出しの結果（40-examples/04-projections.md・F34〜F42） — 01〜03 の「要補完」を射影で書き直して 穴を炙り出した。暦座標 yearNo/monthNo/dayNo は epochOrdinal＋ordinalIn＋既存値関数の糖衣で 導ける（新規語は epochOrdinal・ordinalIn の二つで足りる）ことが確認できた。一方、次の六点が未決の まま残り、これらが決まらないと六曜の月名・ISO 週番号・年度ラベル・節気名が書けない（次段の設計対象）:

  1. ordinalIn/epochOrdinal の引数設計（数える対象と枠が引数で絡む。二窓引数 ordinalIn(数える窓, 枠窓, d) への一本化を検討。F34）。
  2. 射影値は入力ストリームの粒度に依存する（ordinalIn(month, d) は入力が日なら「第何日」・瞬間なら 「第何瞬間」）。「窓の下位窓を数える」粒度非依存版を分けるか（F35・F42）。
  3. labelOf が読むラベルの源が三種（cycle 由来／label: 付与／暦座標糖衣）で未区別。「窓はラベルを 一つ持ち源は生成時に決まる」モデルの明文化が要る（F36）。
  4. label: 付与式の表現力: 隣接窓参照は射程外（F37）だが、ISO 週番号・年度ラベルは別の点の窓（週の 木曜が属する年）を参照する。付与式がどの点の窓まで見てよいかの設計（F40）。
  5. ラベル付きテーブルリテラル（時点＋名前＋黄経の三つ組）。ADR-26 の「時点のみ」を列を持つ表へ拡張。 節気 24 名の 1 対 1 ラベルは cycle（律動）でなく表の列（F38・F39）。
  6. snapTo(w) は「点 → 属する w 窓 > first」の糖衣にできる（w|>first・公開境界語との重複解消。F41）。

読む側の中核は epochOrdinal・ordinalIn の二語に絞れた。labelOf と label:（付与）が本体で、上記 3〜5 がその設計。snapTo は糖衣化で新規語から外せる見込み。

確定（ADR-30・2026-07-07） — 上記六点を次のように決めた。読む側の中核は epochOrdinal・ordinalIn の 二語＋束縛名射影で、labelOf は廃語、snapTo は基本語として残す。

  1. ordinalIn は二窓引数 ordinalIn(u, w, d)＝「点 d が属する w 窓の中で、d が属する u 窓が 第何番目か」（1 起点）。ordinalIn(day, month, d)＝月内の第何日。数える単位 u を明示するので入力 ストリームの粒度に依存しない（F35/F42 解決）。epochOrdinal(u, d) は枠を紀元にした版。
  2. labelOf は廃止。ラベルは「点 → 値の射影」で、ラベルを持つ窓/サイクルの束縛名を点に適用して 読む（weekday(d)・sekki(d)・lunarMonthNo(d)。束縛名がそのまま射影名＝F48）。§1.16 の「cycle 束縛名は点→ラベルの値関数」を label: 付与窓・データ列に一般化しただけ。汎用語は要らない。
  3. 点はラベルを格納しない。時間ストリームの点は基底位置（時刻）のみを持ち、ラベルは点→値の射影 として外にある。その源は (i) cycle の律動（暦独立・無限）、(ii) テーブルのラベル列（有限データ・1 対 1）、 (iii) 暦座標の値関数、の三つだが、読む側は一様に 名前(d)。時間ストリーム型も値型も拡張しない （レコード型を新設しない）。
  4. ラベル付きテーブルリテラルは時点列に並行ラベル列 labels: を添える（同長・位置対応）＝(3) の源(ii)の 定義データ。sekki = [2026-01-05T17:23, …] labels: [小寒, 大寒, …] で sekki(d) が定義される （束縛名がそのまま射影名。F48 で字面を統一）。 cycle（無限律動）と表のラベル列（有限データ）は源が違うだけ（F38/F39）。
  5. label: 付与式は本体層の式（窓内の点の射影・他窓参照）を書ける。ISO 週番号・年度ラベルの「別の点の 窓を参照」（週の木曜が属する年）は可。隣接窓（前後の同種窓）参照は射程外（I7 純粋遅延・F37）。 ——のち ADR-34 で「別点」は先頭点（代表点）への参照に精密化（「週の木曜」は点±幅算術が無く 字義どおりには書けないが、ISO 週番号自体が F57 の等価変形で label: 不要になった）。
  6. snapTo は点変換として残す（「点→属する窓の先頭点」）。公開境界語（窓→点）とは入口が違い重複でなく 補完。糖衣化は「点→属する窓」語を要するため見送り、基本語のまま（F41 の重複懸念は役割分離で解消）。

1.18 字句と値式の追補（ADR-28）

1.19 カレンダー実体の束の宣言（確定＝ADR-35・F10。粒度整合は ADR-36）

calendar: メンバーに与える実体（TSE・JPCal）を定義する構文。ADR-26 で型は確定済み—— 「非稼働日ストリーム＋出所・版」の束。40-examples 01 §1.7 で「holidays を作った後、それを カレンダーとして登録する接続が書けない」（F10）が残っていた。ADR-35 で確定（2026-07-08。 正体判定の追加要件＝nonWorking は day 整列・引数なし・実体は tz: 必須、bizDay は calendar: 在圏で言語予約、軸位置の解決順、member 解決規則、派生の source: 上書き必須寄り——詳細は ADR-35。 粒度整合の検査は ADR-36）。以下は起草時の候補設計の記録。

候補（案 1・推奨→ADR-35 で採用）: 実体は premise そのもの＝予約公開語を持つ premise

観察——「ストリーム束縛＋source:・asof:」を束ねる構文は既にある。premise 定義（§1.6）と 層またぎ規則（§1.15）がそれで、カレンダー実体に固有なのは「どの束縛が非稼働日か」の指名だけ。 ゆえに新構文ゼロで、予約公開語 nonWorking（仮称）を持つ premise をカレンダー実体と認める:

premise TSE {
  calendar-system: Gregorian          # weekday の解決に要る（satSun の定義）
  tz:     "Asia/Tokyo"                # 非稼働「日」がどの市民日かを確定（F54）
  source: "jpx.co.jp/trading-calendar"
  asof:   2026-01-05

  satSun     = everyDay |> filter(d => weekday(d) == Sat or weekday(d) == Sun)
  holidays   = [2026-01-01, 2026-01-12, …] covering: 2026..2026
  nonWorking = satSun | holidays      # 予約公開語（仮称）＝実体の「正体」
}

premise JP {
  calendar-system: Gregorian
  calendar:        TSE                # nonWorking を公開する premise だけがここに立てる
  tz:              "Asia/Tokyo"
  wkst:            Mon
}

却下・比較案:

この設計で出た綻び（F51〜F54。正本は 40-examples/90-findings.md）と、レビューの裁定（2026-07-07）:

レビューで新出した綻び（正本は 90-findings）:

1.20 範囲外出自と covering: の活性化（候補設計。F61・評価註釈 I6/ADR-15 の初めての具体化）

データは尽きる（暦要項は年次告示・取引所カレンダーは翌年分まで）。尽きた先の評価を「黙って空」に すればサイレント故障（ADR-15 の背景そのもの）、「エラーで止める」にすれば覆域に一部でも掛かる評価が 全滅する。ADR-15/26 は第三の道——範囲外の出自を評価註釈に流す——を予約していたが、註釈の実体は 未設計だった（F61）。ADR-35 判断 3 で優先度が上がった: bizDay = everyDay \ C.nonWorking の標準導出は、 祝日データの尽きた先で everyDay \ satSun へ黙って退化する——出自を落とすと退化が観測できない。 以下、棚卸し済みの 8 論点（INDEX）に対応する候補設計。

判断 1（covering: の意味論——値に触れない。論点 5）: covering: は「範囲内は完全・範囲外は 未知」という二面の主張であり、値には一切触れない——テーブルの値は書かれた列そのもの。 主張が値と食い違わないことは静的検査で保証する: 列の全要素は covering に包含（違反は乱順・重複と 同格の静的エラー——覆域外の要素はほぼ確実に誤記か覆域の書き漏らし）。この検査により「覆域外に点は 無い」が静的に立ち、覆域外の評価は結果として「空＋範囲外註釈」になる——が、値を切る刃は言語に 存在しない（当初案の clip は敵対検証で致命と判明し廃止——覆域外の支持点アンカー〈旧暦 newMoons の 2024-12-31〉を黙って抹消し、F60 の窓序数が繰り上がって並行リストが全ずれ、覆域内・註釈ゼロのまま 全期間誤答する。値は列が決め、註釈は covering が決める——分離が正しい）。値と註釈の分離は I6 の 字面どおり: 註釈は評価の随伴であって値の要素データではない（点はラベルを格納しない ADR-30 と 同じ据え方）。覆域の端は premise の tz の市民日で解決し（テーブルの tz は内側固定＝ADR-33 判断 10）、 covering: または日付テーブルを持つ premise は tz: 宣言必須（執行点は宣言時——ADR-35 判断 2 の 実体要件の延長。無宣言だと覆域＝註釈区間が利用側 tz で動く）。省略時は列の端（閉区間 [先頭要素, 末尾要素]）が覆域（ADR-26 既定のまま——安全はうるさい側に倒す。空テーブルは端が 無いため covering: 明示必須＝§1.26・ADR-45）。

判断 2（出自の値域。論点 1）: 註釈の種は「範囲外」（out-of-coverage）一種から始める。 属性は〔区間・源（premise.束縛名）・その covering・asof〕。「正当な空」は註釈なしの空として 表現され、専用の種を持たない（該当なしは正常結果）。ただし字面に注意——註釈なしは「既知の データ端に起因しない」ことを言うだけで、正当性の証明ではない（タイポの全落ち・供給未投入は 註釈ゼロの空のまま外部判定に渡る。証拠の不在を不在の証拠に格上げしない——この一文は判定器の 文書にも義務づける）。「事故の空」の判定は言語の責務外のまま（ADR-15）——主要な事故種＝データ 切れが「範囲外」で観測可能になる、が本設計の前進のすべて。種の集合は開放的に設計する（将来: asof: の版差・観測データの未確定域〈40-examples 05〉が同じ器に入る）が、今回規定するのは一種のみ。

判断 3（註釈の付き先。論点 2・★裁定対象）: 区間註釈——結果ストリームに、chronos 上の 註釈区間の列〔[a, b) ごとの種と属性〕が並走する。点註釈は不可（範囲外の本質は「点が無いかも しれない」こと——存在しない点には付けられない）。ストリーム全体フラグは粗すぎる（覆域に一部でも 掛かる評価が全体不信になり、信頼できる部分範囲が識別できない——「狭い評価範囲を殺す」の再発）。 註釈は空でない結果にも付く——範囲外区間に satSun 由来の点は出続ける（nonWorking の例）。 ADR-15 の「空の出自」から「区間の出自」への一般化であり、ADR-15 に改訂節を足す。

判断 4（伝播の代数＝註釈の輸送表。論点 3・★裁定対象）: 規範は一つ——「結果が覆域外データに 依存し得る区間を漏らさない」（過小近似は不可・過大近似は許容）。当初案の「入力点が註釈区間内 なら着地点へ写す」は検証で過小と判明した——註釈区間には定義上点が無い（判断 1 の包含検査）ので 点渡しの伝播は空振りし、shift が依存領域を平行移動させる形（満了 90 日前通知）で漏れる。よって 点でなく区間そのものを輸送する。ADR-36 の統治表と同型に、core 全演算子に輸送行を義務づける （行の無い演算子は註釈を通せない＝新演算子追加時は輸送行の定義が必須。構造的に漏れを塞ぐ）:

なお「単調（太ることはあっても痩せない）」は結合子の性質であり、輸送は区間を移す——正しい 不変量はスローガンでなく冒頭の規範（依存区間を漏らさない）。過大近似の裏面も明記する: roll・filter 通過後の太った註釈区間では、本物のプログラミングエラーが判断 6 で「範囲外」へ軟化され得る （安全方向の選択の対価。分類の一次基準はあくまで実効被覆域）。

判断 5（「判定は外部」の器。論点 4）: 言語仕様が定めるのは「実装表面は結果とともに註釈を 提示しなければならない」（I6）まで。対処（失敗させる・警告する・進む）は呼び手の責務（ADR-15）。 器は二つに分ける:

正準形では annotations・coverage は results と同格のフィールド（註釈を捨てる短絡アクセスを既定に しない。実装は註釈非空時の非零終了などの厳格モードを提供してよい——それは呼び手の判定の実装であって 言語の判定ではない）。CLI は結果の後に註釈ブロックと被覆サマリを表示する。純値文脈（label: の 表示等）の覆域外射影は「値なし」スロットを導入せず範囲外分類の明示エラーに落とす（属性〔源・ covering・asof〕をメッセージが運ぶ。部分定義値を持ち込まない——本体式の値形対応の設計時に 「値なし＋註釈」形を再検討）。

判断 6（硬エラー 2 種の移行。論点 6）: 実効被覆域がエラーの分類器になる——失敗した参照の 点が、その参照が実際に読む束縛の実効被覆域の外（＝判断 4 の輸送で計算された註釈区間の内）に あれば「範囲外」（ストリーム文脈は落として註釈・純値文脈は判断 5 の明示エラー）、実効被覆域の内に あれば従来どおり硬エラー（取り違え＝プログラミングエラー。ADR-16 の統治のまま。例: 実効被覆域内の テーブル射影で点が列にない・I4 の窓の外）。基準を生テーブルの covering にしないのが要—— 派生構造（窓列）の実効被覆域は輸送でずれる（segmentBy の頭の edges: 領域など）ので、生 covering で 分類すると「覆域内・窓なし」の帯で系統的に誤爆する。細則:

impl の「計算範囲（to＋約 400 日）越え」の硬エラーは snapTo だけでなく roll 終端・shift（窓語／ 点列軸）を含む 4 サイトが同族——言語の地平線ではない（判断 8）ので、共通の三分岐に統一して降格する: ①点/着地が計算範囲以遠→クリップ＋実装警告（warnings・機械可読）、②実効被覆域外→落として註釈 （本判断）、③それ以外→硬エラー維持。

判断 7（ADR-16 との整理。論点 7）: 危険の種類で層を分ける——構造の危険（取り違え・省略・ 曖昧名・整列不一致）は静的エラー（ADR-16/17/36。定義から判定できる）、データの端（範囲の危険）は 評価註釈（評価範囲に依存し静的に判定できない。覆域内だけの評価は註釈ゼロで走る）。「黙って空」は サイレント故障・「エラーで止める」は覆域内の正しい結果も殺す——註釈＋外部判定はその中間ではなく、 値の確定と危険の報告を直交させる第三の軸である（値は常に確定・危険は常に観測可能）。

判断 8（二重の地平線。論点 8）: 混同しない——(a) データ被覆域（covering:）は言語概念で 註釈の源、(b) 評価範囲（from/to）は評価の需要域で註釈のクリップ枠（評価しない領域の註釈は 出さない。覆域内に収まる狭い評価は註釈ゼロ——「狭い評価範囲を殺さない」の実現形。ただし註釈ゼロは 判断 2 の字面のとおり安全証明ではなく、to 直後のデータ切れは判断 5 の被覆サマリが担う）。クリップは 表面（結果組み立て）で一度だけ行い、内部伝播は非クリップで走らせる——葉で先にクリップすると、輸送 （shift の平行移動・roll の依存像）で覆域外から評価範囲内へ入ってくる註釈を取りこぼす。impl の 実体化範囲（to＋約 400 日）は第三の、プロトタイプ限りの近似地平線であり、言語には存在しない （impl/README の制約に留まる。判断 6 の①がその執行形）。

追補（開端・区間リストの covering:・★裁定対象）: 二つの表現拡張。

意味の対比を明文化する: 省略＝列の端（最狭の主張）・covering: ..＝全域完結（最広の主張）—— 正反対であることに注意（混同の芽として glossary に注記）。省略既定は非空では変えない（単発テーブルの 恒常註釈は covering: .. を書かせることで解消する——黙って完結扱いにすると官報表の書き忘れが データ切れの黙認になる。うるさい側が安全側。空テーブルは省略が定義不能のため明示必須＝§1.26・ADR-45）。

却下した案:

この設計が実行を変える例（rokuyo.kairos ヘッダの運用注意「評価範囲もデータ内で使うこと」が不要になる。 covering は包含検査に合わせ実端へ広げる＝2024-12-31..2027-12-31）:

# newMoons covering: 2024-12-31..2027-12-31 のもとで --from 2026-01-01 --to 2029-01-01
lunarMonth |> first
#=> 2026〜2027 の朔日列（2027-12-28 起点の最終窓まで確定＝edges: の発火は覆域端）
#   ⚠ 範囲外 2028-01-01..2029-01-01（Kyureki.newMoons covering ..2027-12-31, asof 2026-02-02）
#   被覆サマリ: Kyureki.newMoons covering 2024-12-31..2027-12-31 asof 2026-02-02（残走路 to から −366 日）

検証の記録（2026-07-08・4 視点並列＝整合性・コーパス全数掃引・実装可能性・敵対的、指摘約 40 件を 反映）: 当初案からの構造修正は四つ——(1) clip 廃止＋包含の静的検査（敵対の致命反例）、(2) 点渡し 伝播→区間輸送表（shift の平行移動・roll の依存像・選択子の窓拡幅・stride の位相汚染——過小近似の 穴を演算子ごとに閉じる）、(3) edges: の発火を覆域端に規定＝実効被覆域（「覆域内・窓なし」帯の 解消・判断 6 の分類基準）、(4) 明示の被覆主張と被覆サマリ（恒常註釈の狼少年化と「to 直後の データ切れが知れない」への器）。実装は GridTag（ADR-36）同型の値随伴伝播＋純値文脈の例外チャネルで 400〜600 行級・既存 153 テスト無風の見込み。

設計者裁定が要る核: 判断 1（covering は値に触れない＝clip 廃止・包含検査）・判断 3（付き先＝区間）・ 判断 4（輸送表＋自動相殺なし＋明示被覆主張）・追補（開端・区間リスト covering と統治）。裁定後に ADR 化（ADR-15 に改訂節〈空の出自→区間の出自〉・ADR-26 の「範囲外」字面を本設計へ接続・ADR-35 判断 3 の伝播の具体化）。

1.21 窓所属の述語と stride の入力相対（候補設計。F68＋F70）

ADR-36（整列）が顕在化させた「所属の意味論の縁」二つを確定する。F68＝時刻付き・混合スケジュールへの 例外日適用が等値の結合子では書けない（従来は黙って空振り・現在は安全側の静的エラー）。F70＝stride(n) の 数え方が「軸の点列を n 歩」か「入力の点を n 個ごと」かで二義（文書と実装は入力相対・§1.9 の字面は軸相対）。

判断 1（F68 の受け皿＝窓所属述語・★裁定対象）: 新しい結合子でも専用段でもなく、値関数一語を 射影一族（§1.17・ADR-27/30）に足す:

coincides(S, w, d)    # 仮称。点 d の属する w 窓の中に、ストリーム S の点が少なくとも一つ在るか（論理値）

F68 の正準形は filter との合成:

# 毎営業日 9 時の通知から、祝日の「日」に落ちるものを除く
notices |> filter(d => not coincides(holidays, day, d))

却下した案（F68）:

判断 2（F70 の確定＝stride は入力相対・★裁定対象）: stride(n, from:) は入力ストリームの点を 数える。軸引数を持たない——§1.9 の表の「在圏 axis:（on: で上書き）」行を削除する （表面の削減。コーパスの使用例 2 件——filter(on: bizDay) |> stride(3)・sekkiInstants |> stride(2)——は どちらも入力相対で、on: 上書きの使用例はゼロ。reference/stride.md の記述・impl の実装も入力相対）。

F70 の帰結の波及（検証で増補・全数）: draft §1.7（on:/unit: の列挙から stride を外す）・§1.8 （検査リスト）・§1.9（表・例の前文 @JP axis: bizDay も無用化）・§3 暫定シグネチャ（stride 行—— 「起点は前段窓 or from:」という ADR-31 以前の残骸も併存・同時修正）・spec §3.3（軸の列挙)・ §4.5（検査リスト）・§4.7（表）・§5.4・40-grammar「演算子シグネチャ」・glossary（stride 行・「軸」行）・ domain-model §2.7・reference/stride.md（表題「軸相対に」・落とし穴）・strideBy.md・README 索引・ impl/README（stride 検査不発の制約削除）。意味論の変更はコーパス上ゼロ（［明文化］＋表面の削減＋ n 域の検査追加）。

設計者裁定が要る核: 判断 1（受け皿＝値述語一語で良いか・糖衣の見送り・証人規則と tz 検査は安全側で 確定寄り）・判断 2（入力相対の確定と on: 行の削除・n ≥ 1 静的エラー）。裁定後に ADR 化 （F68＋F70 で一本の新 ADR・ADR-36 判断 3/7 と ADR-37 判断 4〈filter 行の逆像拡幅〉/判断 6 〈失敗種追記〉に改訂節）。

1.22 窓列への並行ラベル列（候補設計。F62）

旧暦の月番号イディオム monthNos[epochOrdinal(lunarMonth, d)] は、値リストと窓列の結びが書き手の 頭の中にしかない——朔を 1 件書き漏らすと窓が減り、リストが窓数より長い方向のずれは黙って全月番号が ずれる（短い方向は添字外の硬エラーで止まるが、長い方向は検査面が無い。ADR-16 の危険基準）。 優先度は二度上がった: ADR-37 の覆域端確定で実際に窓が 37→38 になり monthNos の追記が要った（実例）、 ADR-38 の coincides（閏月検出）が照合の道具を提供した。検査は宣言に錨するしかない——一般の値式 list[expr] に「このリストはあの窓列と並行」という意図は読めない。なお本設計が守るのは長さであり、 同長の位置ずれ（先頭に朔を足しラベルを末尾に足す誤更新）は検査を通る——中身の照合は従来どおり doctest（旧正月照合）と coincides（閏月検出＝ADR-38）の分担。F62 の処置は「解消」でなく 「検査を運ぶ器と正準形の確定」（ordinalIn 還元と同じパターン）と呼ぶのが正確。

判断 1（受け皿＝segmentBy の labels: 引数・★裁定対象）: テーブルの並行ラベル列 labels: （ADR-30）を窓列へ一般化する。新しい語は増えない（確定語 labels: の適用先が増えるだけ）:

lunarMonth = day |> segmentBy(lunarStart, edges: drop, empties: error, labels: monthNos)

判断 2（整列規則と前提条件）: 意味論は定義的等式一行——名前(d) ≡ labels[窓列序数(d の属する窓)]。 窓列序数は本設計の専用座標: 実効被覆域内の先頭マーカー起点の窓が 0。epochOrdinal（F60）とは マーカー列が紀元に届かない場合に一致するが、紀元を跨ぐ歴史データでは epochOrdinal が負になるのに対し 窓列序数は常に 0 起点——相乗りしない（検証で確定）。前提条件と締め:

判断 3（複数の並行列）: labels: は一列（束縛名射影の一意性）。旧暦は monthNos（番号）と monthNames（月名）の二列が要る——正準形は同じマーカーで別の窓束縛を立てる:

lunarMonth = day |> segmentBy(lunarStart, edges: drop, empties: error, labels: monthNos)
kyuMonth   = day |> segmentBy(lunarStart, edges: drop, empties: error, labels: monthNames)

重複は軽く（マーカー共有）、検査が二重に効く（両リストとも窓数に照合される——従来イディオムでは monthNames 側が無検査だった）。ADR-34 の label: ラムダ経由（monthNames[epochOrdinal(…)]）は 「labels: に乗らない計算ラベル用」に位置づけを降格して残す（ADR-34 判断 5 の補助束縛パターンの 主用途は本設計で消える——ADR-30 改訂節で再配置）。二重束縛の相互整合（monthNos と monthNames が 同じ窓を指すこと）は本検査の射程外——正準はマーカーの束縛名を共有すること（lunarStart を両方に 書く。束縛名の同一は目視で立つ・将来の警告級検査の候補）。「既存の窓束縛へのラベル後置」 （kyuMonth = lunarMonth labels: monthNames 級＝窓列の同一性が構文で立つ形）は将来候補として記録 （ADR-34 帰結「within で被せた別名からは読まない」との線引きの再整理が要るため今回は見送り）。

判断 4（旧イディオムの扱い）: 生の list[epochOrdinal(w, d)] は値式として合法のまま（一般の 添字を禁じる理由はない）。F62 の保護は宣言形を使うことで得る——ordinalIn への還元（ADR-27）と同じ 「正準形が検査を運ぶ」パターン。kyureki の公開文書は labels: 形へ書き換える。

却下した案:

検証の記録（2026-07-08・2 視点＝整合性＋敵対／コーパス＋実装、指摘 22 件を反映): 主要修正は 四つ——(1) epochOrdinal への相乗りを廃し専用の窓列序数（紀元跨ぎで F60 座標と食い違う）、 (2) 前提条件の明文化（マーカー点列の有限性＝規則マーカー segmentBy を締める・無註釈の覆域＝合成 マーカーの三値の縁）、(3) 窓数は覆域基準（評価範囲非依存＝検査は近似でなく正確）、(4) 主張の 較正（守るのは長さのみ・「解消」でなく「器の確定」）。ティティの clip 依存が「偶然に頼った番号」で あることも判明——drop＋labels: への移行で除去（期待値不変）。実装見積もり: parser 0 行・eval 約 50 行・テスト 12〜15 本・既存 208 テスト波及ゼロ。F64（同名適用の二義）の面積が labels: 束縛の 常態化で広がる点は open-questions に追記。

設計者裁定が要る核: 判断 1（受け皿＝segmentBy の labels: 一般化で良いか）・判断 2 の締め （clip/drop/同居/規則マーカーを全て静的エラー——緩める案は「clip 擬似窓はラベルなし・読みは 硬エラー」だが黙ってずれる面が残り、ティティも drop 移行で足りる）。裁定後に ADR 化 （ADR-30 に改訂節＝labels: の適用先一般化と判断 5 の再配置）。

1.23 日付ラベル保存の再錨（候補設計。F69）

クロス tz の「同じ日付」合成——TSE（Asia/Tokyo）と NYSE（America/New_York）の共通営業日——は chronos 等値では原理的に書けない（ADR-36 帰結・F69）。snapTo の整合は「chronos 上の重なりを 利用側の日界で読む」意味であり、東京の日先頭は NY の前日に floor される（系統的 1 日ずれ）。 coincides（ADR-38）も chronos 所属であり、tz 検査が安全側で止める——「同じ日付ラベル」の所属は 未充足のまま送られてきた。要るのは日付ラベルを保存して別 tz の同ラベル窓へ写す演算。

判断 1（受け皿＝点変換の第 4 メンバー・★裁定対象）: roll/shift/snapTo に並ぶ点変換として

rebase(to: "America/New_York")    # 仮称。各点（day 整列）を「同じ日付ラベルを持つ、to tz の市民日の先頭点」へ写す

を足す。共通営業日は

(tseBiz |> rebase(to: "America/New_York")) & nyseBiz    # 出力は NY の日付列（& は両辺 NY day 整列 ✓）

——rebase が「ラベル対応」の再整列を宣言し、& は既存の等値のまま。ADR-36 の整合手段が二本に なる: snapTo ＝ chronos 所属（同じ瞬間を含む窓）・rebase ＝ ラベル対応（同じ日付）。どちらを 意図しているかが字面で立つ（ADR-36/38 の分岐案内に三本目の枝）。

却下した案:

検証の記録（2026-07-08・整合性＋敵対 1 視点・発見 8 件反映）: 当初案からの修正は四つ—— (1) w=day 固定（month/year は多対一で単射性が破れ・「市民ラベルを持つ窓」は導出構造で判定 不能——市民ラベル＝tz 写像の座標成分 Y-M-D に直結する day だけが健全）、(2) 存在しない日付は 明示エラー（Pacific/Apia 2011-12-30——「全 tz に全日付」は tzdb 上偽）、(3) 免除系の tz 検査 拡張（rebase がクロス tz 整列を常態化させ、within/ordinalIn/選択子/値射影のラベルずれが黙って 通る既存の潜在穴が主要動線になる）、(4) 入力前提の精密化（既定整列の day グリッドに限定—— 時刻オフセットつき市民 G のすり抜け封じ）と註釈輸送の操作化（floor/ceil 拡幅）。

設計者裁定が要る核: 判断 1（受け皿＝点変換 rebase・day 固定・時刻保存は将来拡張・免除系 tz 検査の 同時拡張）。裁定後に ADR 化（ADR-36 帰結の F69 送りを閉じる・ADR-36 判断 7 に改訂 2・輸送表と 整列表に行を追加）。命名は仮称（rebase——ADR-36 が「再錨（rebase）」と呼んだ語をそのまま。 ほか relabel・sameDate を比較候補に）。

1.24 営業時間の供給規約と標準導出（候補設計・検証済み。F67 本体＝F79、あわせて F81/F83 の規定）

前提: 綻び出し（40-examples/06）で読む側は確定語彙のみで全部書けると実証済み。裁定 3 件 （2026-07-08）——(1) F79＝標準導出を規定する（実体に開閉時刻の供給規約を指名し、bizDay と 同格の導出を言語規定）、(2) F76 の据え方＝premise 層の問題（「DST で時刻をずらすかそのままかは 文化＝premise の決まり」——開閉時刻は市民座標〈壁時計〉で宣言し DST 挙動は premise の tz 規則 から従う・経過は明示の特殊形）、(3) F81/F83＝ADR-31 改訂で規定。 起草後に 4 視点検証（整合性・コーパス掃引・実装可能性・敵対的、指摘 39 件）を通し、当初案の 構造欠陥 4 件（F86〜F89）を修正済み——修正の要点は各判断に付記、記録は節末の「検証の記録」。

判断 1（候補）: 供給規約＝実体の予約公開語の対 sessionOpens・sessionCloses（いずれも仮称）

カレンダー実体（ADR-35）は、nonWorking に加えて開場列 sessionOpens・閉場列 sessionCloses（時間 ストリーム型・引数なしの束縛）を宣言できる。宣言は対（片方だけは静的エラー。with 派生では 継承込みで判定——sessionOpens だけ上書きし sessionCloses を継承する派生は合法）・宣言自体は任意（無ければ 細粒度導出が使えないだけ）。点は実体 tz の市民座標の事実（壁時計。裁定 (2)——規則は時刻付き anchor の市民グリッド〈F81 で規定〉か strideBy の市民時幅、例外データは時刻付きテーブル。 ADR-33 判断 10 の内側固定はそのまま効く）:

premise TSE {
  calendar-system: Gregorian
  tz:     "Asia/Tokyo"
  source: "jpx.co.jp/trading-calendar"
  satSun     = everyDay |> filter(d => weekday(d) == Sat or weekday(d) == Sun)
  holidays   = [2026-01-01] covering: 2026..2026
  nonWorking = satSun | holidays

  # 営業時間 9:00–11:30・12:30–15:00（二部制）。半日休（大納会級）は前場のみ
  am9   = chronos grid 1d anchor: 2026-01-01T09:00
  pm30  = chronos grid 1d anchor: 2026-01-01T12:30
  am30c = chronos grid 1d anchor: 2026-01-01T11:30
  pm3c  = chronos grid 1d anchor: 2026-01-01T15:00
  halfDays = [2026-12-30] covering: 2026..2026

  sessionOpens  = (am9 |> first) | (pm30 |> first |> filter(t => not coincides(halfDays, day, t)))
  sessionCloses = (am30c |> first) | (pm3c |> first |> filter(t => not coincides(halfDays, day, t)))
}

セッションの意味論は区間の和: sessionOpens/sessionCloses は半開区間 [open_i, close_i) の列（セッション）を 定める。この読みから整合性の規則が全部出る:

判断 2（候補・F89 で実体相対に修正）: 標準導出＝bizOpen・bizClose（導出ストリーム）と isOpen(t)（導出値述語。いずれも仮称）。在圏 calendar: の実体 C が sessionOpens/sessionCloses を宣言して いるとき、言語が一律に規定（calendar: 在圏で予約名——手動束縛は静的エラー。bizDay と同格）:

bizOpen   =  C.sessionOpens のうち「開場点の属する C-tz の市民日が C の営業日」の点
             （C の営業日 ＝ C.everyDay \ C.nonWorking を C の内側で読む）
bizClose  =  各 bizOpen セッションの閉場点（区間の和の右端）
isOpen(t) =  t が bizOpen セッションの区間の和に入っているか（半開・Bool）

判断 3（候補）: bizHour 級の点列は導出しない。「営業中の毎正時」の 1h は式の側の粒度選択 であってカレンダーの属性ではない（30 分毎・15 分毎も同格）。hourly |> filter(t => isOpen(t)) の 合成で書く。セッション内序数（第 n 営業時間）が要るときは 06 §6.3 の帯を手元で張って ordinalIn—— gappy な窓列（営業側だけの窓列）は窓の型の新設になるため導出しない（却下案 (v)）。

判断 4（候補・F87 で「現行一致」の主張を撤回）: ADR-31 改訂＝F81（時刻付き anchor の市民 グリッドの窓境界）。市民時幅 nd の grid に時刻付き anchor: を与えたとき、窓境界は「anchor の 属する市民日から n 日ごとの各市民日で、anchor の壁時計時刻（ラベル読み）を最初に読む瞬間」—— (a) その時刻が存在しない市民日（DST の隙間）は隙間明けの最初の瞬間（ADR-33 判断 4 の時刻版）、 (b) 二度ある市民日（秋戻し）は最初の出現、(c) 存在しない市民日（Pacific/Apia 2011-12-30 級の 丸一日スキップ）には目盛りを置かない（窓は存在する市民日で数える＝impl の現行）。窓幅は市民日と 同じく伸縮する。「anchor 点からの経過時間タイル」の読みは幅規約（1d＝市民日・ADR-11/12）が既に 排除している。注意（F87）: impl の現行は anchor の日内オフセットを経過 ms で計算しており、 anchor が DST 切替日に落ちると全目盛りが壁時計からずれる（NY で anchor: 2026-03-08T09:00 → 全日 08:00 発火・anchor 自身を通らない。同じ壁時計の 2 本の grid が整列不一致になる副作用も実測）—— 本改訂はこの挙動の修正を含む（「既存の式の意味を変えない追加規定」ではない。通常日 anchor では 不変）。strideBy の時刻付き from: も同じ規定に従う（整列同一視の維持）。

判断 5（候補・裁定要。検証で推奨を (a) へ反転＝F88）: ADR-31 改訂＝F83（shift(unit: 市民窓語) の窓内オフセット）。候補:

統治・検査のまとめ: 対宣言（継承込みで判定・片方欠け＝静的エラー）・整合性検査（結合実効 被覆域∩実体化範囲・局所交互・端の切り欠き合法・同時刻対は相殺・データ相対の層・細粒度導出の 初回使用時）・calendar: 在圏の bizOpen/bizClose/isOpen 手動束縛＝静的エラー・sessionOpens/sessionCloses 未宣言の実体で導出語＝静的エラー・派生の source: 上書き必須寄り（判断 1）・循環検査の延長 （判断 1）・覆域は証人規則の三分岐（判断 2）。C.sessionOpens の修飾ピンによる生読みは合法（実体 tz の 事実の直接利用——結合すれば既存の整列・tz 検査網に掛かる）。

却下・比較案:

命名（すべて仮称・F51 の一括確定に合流）: sessionOpens/sessionCloses（比較: openings/closings・ sessionOpens）・bizOpen/bizClose（比較: openTick・sessionStart）・isOpen（比較: openAt・withinHours・trading）。予約公開語は「偶然の同名束縛と衝突しにくい」観点（ADR-35 帰結）を F51 で併せて適用——sessionOpens/sessionCloses は一般英単語で衝突面が広い（検証指摘）ため、確定時に 要注意。

検証の記録（2026-07-08・4 視点＝整合性/コーパス/実装可能性/敵対的・指摘 39 件反映）: 当初案 からの修正は四つ——(1) 整合性検査の全面修正（F86＝「open 始まりの厳密交互・実体化範囲上」は 両無限列で定義不能・深夜営業を範囲頭で誤エラー・和の上では同時刻対が観測不能・覆域制限なしでは 正当な実体が止まる → 局所交互＋結合実効被覆域＋端の切り欠き＋対ストリーム上の相殺＋データ相対の 層へ）、(2) F81 の「現行一致」撤回（F87＝impl は anchor を経過 ms で計算・切替日 anchor で 全目盛りがずれる欠陥——改訂は修正を含む）、(3) F83 の推奨反転（F88＝候補 (b) は秋戻しの併合・ 往復非可逆・Santiago 級の day 整列破れ——ADR-40 が時刻保存を据え置いた理由と同根。壁時計の用途は F67 導出が引き受け、shift は (a) 経過保存の明文化を推奨）、(4) 導出の実体相対化（F89＝利用側 bizDay 経由はクロス tz の自然な問いを塞ぐ → C の内側で解決する chronos 述語へ）。ほか: 24h 営業は 器の外（作法）・帰属は開場日固定（CME 型トレード日は F90 宿題）・相殺規則が接するセッションの 融合と DST 縮退の救済を兼ねる・「規則なら覆域無限」の誤り訂正（混合供給は例外テーブルの covering に 頭打ち＝保守側）・束縛右辺の複数行継続の構文が無い（F91 宿題）。

設計者裁定 3 件で確定（2026-07-09）: (1) F83＝(a) chronos 側の算術（経過保存の明文化。 設計者の読み「中身は chronos＝UTC 相当・読みは premise の射影」＝ADR-33 のモデルから自然に 導出——ずらす算術は chronos・壁時計に貼り付く決まりは premise 層の宣言、という役割分担）、 (2) 同時刻の open/close＝両点保持（順序は交互性から一意・発火の扱いは処理系の領分——相殺案は 取り下げ）、(3) isOpen＝実体の文化で解決（実体相対。東証が開いているかは東証の文化だけで 決まる事実・別文化圏の事実の利用は常に実体の名指し経由）。 → ADR-41（F67 本体）・ADR-31 改訂 2（F81/F83）・ADR-38 改訂（正準例）・ ADR-35 改訂（予約語の対・派生統治・循環の延長）として確定。

1.25 位置依存の名前解釈と窓インスタンス参照（候補設計・検証済み。F64＋F9）

問題: 三つの規則が別々の場所に立っている。(a) 束縛名射影 year(d)＝点→値（ADR-30/34/39）、 (b) 宿題 F9 の窓インスタンス参照 year(2020)＝値→「その年の日々」（未定義）、(c) 軸位置の premise 名 on: TSE＝実体の標準導出への読み替え（ADR-35 判断 4）。(a)(b) は同名適用の二義 （F64）で、規定しないまま両方入れるとサイレント取り違えの芽。ADR-39 で「窓語かつ射影名」の 二役束縛が常態化し、面積は既に広い。統一の受け皿（型規則）ごと設計する（90-open-questions の 持ち上げ・2026-07-08）。

設計原理（受け皿）: 名前の解釈は候補集合を出現位置の期待型で絞り、絞った後に複数の解釈が 残るなら黙って選ばない＝曖昧エラー（ADR-17・ADR-35 判断 4 と同じ統治）。三面はこの原理の実例:

位置 名前の種別 解釈 出典
軸位置（on:/unit:/axis:） premise 名 実体の正体判定＋標準導出への読み替え ADR-35 判断 4（確定済み・不変）
適用・点引数 W(d) ラベル源つき束縛 束縛名射影（点→値） ADR-30/34/39（確定済み・不変）
適用・値引数 W(v) ラベル源つき窓束縛 窓インスタンス参照（値→点列）＝逆像 本節（新設）

判断候補（検証 3 視点〈整合性コーパス・敵対・実装〉の指摘を反映済み。★は裁定点）:

  1. 意味論＝逆像。ADR-34 の定義的等式（点→値）の対として一行で立てる:

    W(v)  ≡  W の要素点列 |> filter(d => W(d) == v)

    「W の要素点列」＝W の定義が窓に束ねた入力点列のうち、W の窓に属する点（内部概念—— ユーザーが直接書く語は増えない）。grid/span/split 連鎖では原子グリッド（ADR-36 の 整列 G）の目盛りと同値、segmentBy では入力ストリームの点（当初案の「原子グリッドの 目盛り」は未 snap マーカーの窓〈ティティ級〉で G＝なしとなり未定義・濾過入力では窓の実要素で ない点が混入する構造欠陥——検証で発見・入力点列ベースに修正）。結果の整列は入力の整列を filter 保存で継承（lunarMonth(6)＝day 整列・tithiW(3)＝整列なし→ & は ADR-36 が安全側で 止め coincides の S 位置では使える）。空窓（欠ティティ級）は空を返す（ADR-15・正当な値）。 解決値は時間ストリーム（型は増えない・I2）。ラベルが一意でなければ全マッチの和 （kyuMonth("六月")＝毎年の六月。番号ラベルは一意キーではない——lunarMonth(6) は閏六月 〈前月番号の繰り返し〉を含む。これは全マッチ和の正しい帰結で、一意が要る問いは名前ラベル 側か filter＋序数で）、ゼロマッチは空。輸送行を一行新設: 「窓列→要素点列」の出力の註釈 区間＝窓列の実効被覆域の補集合（ADR-37 の segmentBy 行の継承・F82 の 4 サイトに続く第 5 の 窓リーダーサイト。これが無いとマーカー覆域の外＝要素点そのものが無い側で註釈の湧き口が消え、 F61 と同型の黙った退化になる——検証で発見）。規則由来の窓（year/month）は覆域完全なので 註釈ゼロ＝既存例に波及なし。それ以外の輸送・覆域・整列は filter の既存規則（ADR-37 輸送表・ F75 逆像拡幅・F82）からすべて従う——評価器の新機構は輸送一行を除きゼロ・新語彙ゼロ。

  2. 適用範囲＝窓束縛のみ（表現力の必然基準）。cycle・ラベル付きテーブルの逆像は台の点列が 手元にあり filter 一行で書ける（everyDay |> filter(d => weekday(d) == Mon)・ sekki |> filter(s => sekki(s) == 立春)——コーパス全数掃引で全用例が既にこの形＝退行ゼロ）。 窓束縛だけは要素点列が premise 相対（原子が day とは限らない）で、書き手が原子を知らずに 済む自己完結の式が現行に無い——ここだけが表現力の穴。cycle・テーブルへの対称拡張は将来糖衣の 枠として空けておく（意味論は判断 1 がそのまま延びる）。
  3. 射影値の源＝ラベル源（label:/labels:）を持つ窓束縛に限る。持たない窓束縛への値引数 適用は静的エラー（「label: を付けるか filter で書く」誘導つき。ISOWeek 級は filter(d => isoYearNo(d) == 2026) へ——誘導先は全て実在をコーパスで確認済み）。 ★stdlib へ標準ラベルを追加: Gregorian の year に label: (p => yearNo(p))・month に label: (p => monthNo(p))——month(5) & year(2026)（2026 年 5 月の日々）の合成が立つ。 Fiscal の year 上書き行にも同時付与が必須（fiscal.md §5 の字面を §1 の正式定義へ昇格）: 上書きはラベルを継承しない（label: は定義の一部）ため、放置すると (a) Gregorian で動き Fiscal で 落ちる非一貫、(b) shiftBoundary は base の label: を保存する（F65）ため「year 一行と同じ 展開」の等価主張が観測可能に破れる——検証で発見。quarter・week は見送り（week は WKST・ ISO 系と絡む・quarter は需要待ち——誘導エラーで書き手に見える）。impl 試作で year/month の label: 追加は自己参照検査に掛からず 301 テスト無傷を確認済み。
  4. ★dispatch＝F64 の型規則。引数式の型（ADR-25 の三型）で一意に分岐——点なら射影、 値（数値・列挙・文字列）ならインスタンス参照。ラムダ変数の型は束縛サイトの文脈で確定する （filter/label: のラムダは点・span のラムダは窓序数＝数値・値関数は本体の型付けから ——「ラムダ変数＝点型」という当初の字面は誤りで検証が棄却）。自由なラッパ （f = v => year(v)）は定義体単独で引数型が定まらない——判定時点を「糖衣展開後・実引数 束縛後」と定める（ADR-36 が整列を同じ時点で計算する先例。判定時点では実引数の型は常に 一意なので、統治の曖昧エラーはここでは構造上発火しない）か、型が一意に付かない束縛を静的 エラーにするかは裁定。year(2026-05-15)＝射影＝2026（日付リテラルは点。なお日付リテラルの 裸の値束縛〈d0 = 2026-05-15〉の型は未規定の既存穴——F66 と束ねて宿題）。 W(v) はストリーム期待位置のすべてで合法（頭位置・結合子被演算子・on:/unit:・ coincides の S スロット等）。純値位置（x = year(2020) + 1）のみ型エラー——ストリームは 値式に混ざれない（ADR-18 の型分離から従う。coincides の S はストリーム期待位置なので filter(d => coincides(year(2020), day, d)) は合法）。EBNF はほぼ変更なし——頭位置の name(args) は stream-atom に既在（糖衣適用が使用中）で、弁別は意味規則（束縛の種別と引数 型）。唯一の追補は stream-atom への修飾適用形 C.W(v)（機構 A の修飾ピン Gregorian.year(2020)——Fiscal 下で暦年を指す唯一の手——が現行文法で頭位置に書けない穴の 解消。修飾ピンは射影・インスタンス参照の両面に同一に効く）。
  5. 静的検査群: (a) ラベル源なし窓束縛への値引数（判断 3・誘導つき）、(b) 窓束縛以外（cycle・ テーブル・点列束縛）への値引数＝filter 正準形へ誘導（判断 2）、(c) ラベル値の型域と引数型の 不一致（数値ラベルに文字列等）、(d) 細粒度ストリームとの & は既存の整列検査がそのまま守る （誘導: 粒度が違うなら値述語 yearNo(t) == 2020 か coincides——ADR-38 の使い分け規範に 合流）、(e) 窓束縛へのストリーム引数（year(mondays) 級）＝静的エラー、(f) label: 付与式内の自束縛への値引数適用も ADR-34 判断 6 の自己参照ガードの対象（逆像は射影を内包 するため・相互参照含む——ガード拡張を ADR-34 改訂ポインタで）、★(g) ラベル値域が静的に 列挙できる束縛（labels: リテラル）では域外の値引数＝静的エラー（month(2020)・month(0) 級のタイポが「註釈なしの空」で黙って流れるのを封じる。計算ラベル〈label: 式〉は列挙不能 なので空＝正当のまま）——採否は裁定。

却下案:

正準例（判断 1〜4 の帰結。検証でコーパス整合を修正済み）:

# F9 の元例: 2020 年だけ海の日を移動（東京五輪）——「移動元」を式で指す
# covering: .. ＝全域完結の主張（2020..2020 だと 2020 外が恒常註釈になる——ADR-37 判断 9 (a)）
marineDayActual = (marineDay \ year(2020)) | [2020-07-23] covering: ..
# 旧暦の六月の日々（毎年・名前ラベル。閏六月は「閏六月」で別）
kyuMonth("六月")            # 番号引き lunarMonth(6) は閏六月を含む（全マッチ和の帰結）
# 2026 年 5 月——インスタンス参照どうしの積（同一 G・day 整列）
month(5) & year(2026)

実装ノート（impl 試作で確認済み・約 70 行で全正準例動作・301 テスト無傷）: 窓束縛は内部で WindowsV（gen-expr 由来）と StreamV＋wins（segmentBy 由来）の二表現——dispatch・逆像は対で実装。 逆像は「ラベルは窓ごとに一定」（ADR-34 の構造保証）から窓単位評価に最適化でき外延等価 （naive filter の 1/5〜1/25・year(2020) 実測 29ms）。切れ端窓（impl 制約）のラベルずれは インスタンス参照で「別の年への漏れ」に増幅される——除外か警告（impl/README 注記）。繰り返し 使う参照は premise 束縛に置く誘導（F80・本体層は defCache されない）。

reference への分岐案内（ADR 化後の反映先）: sekkiW("立春")＝節の期間の日々 vs sekki |> filter ＝節気点の対比・coincides の S 位置エラー文言に「特定インスタンスなら W(v)」・ roll の軸に短い軸（on: year(2020)）を渡すと着地なしは註釈なしの空・premise 相対の罠 （Fiscal 下の year(2020) は年度——逃げは修飾ピン Gregorian.year(2020)）・year(d) と yearNo(d) の二綴りは暦座標糖衣が正準（label: は主に逆像の資格付与）。

spec の受け皿（検証の提案）: 統一原理＋dispatch 表は §2（型と層）に新設小節（三面が premise 層と本体層に跨るため・「型は増えない」宣言群と同居）、逆像の意味論本体は §4.9 に 束縛名射影の双対として追記（射影一族の表に行を足す最小差分）。EBNF は stream-atom の修飾適用 のみ・glossary に「窓インスタンス参照」「要素点列」。spec §4.9 の残骸 lunarMonthNo(d) （ADR-39 で廃止済みの語）も同時に修正。

設計者裁定 4 件で確定（2026-07-09）: (1) 意味論＝逆像で確定（入力点列ベースの要素点列・ 全マッチ和・空は正当・輸送行の新設込み）、(2) dispatch＝展開後判定（糖衣展開後・実引数束縛後 ——ADR-36 が整列を計算するのと同じ時点。判定時点では実引数の型が常に一意で曖昧は構造上発火せず、 自由なラッパは呼び出しごとに型確定＝多相を許容）、(3) 標準ラベル＝year＋month＋Fiscal.year （quarter/week は見送り・誤導つきエラーで需要待ち）、(4) ゼロマッチ＝域外は静的エラー （labels: リテラル等の静的列挙可能なラベル値域では域外値引数を静的エラー・計算ラベルは 「該当なし＝空」のまま＝多マッチ設計の裏面として明文化）。→ ADR-42 として確定。

1.26 空テーブルリテラルの合法化（候補設計・検証済み。F98＝発報層還流第一次 → ADR-45）

動機（F98）: 「点ゼロだが覆域は主張したい」束縛の一次形が無い。発報層は DB 未投入でも boot が 通る合法ソースを要し（boot throw はソース不正のみに限定——適用検討 03〈非公開〉の実測）、データ 供給層の「まだ何も無い」は初回 boot・年替わりの定常状態。回避形＝恒偽 filter への束縛後置の 被覆主張 (everyDay |> filter(d => 1 == 2)) covering: …（ADR-37 判断 5）は観測面では意図どおり （点ゼロ・runway 即負の運用信号）だが、恒偽が迂遠で読み手に意図が伝わらず、ソース生成器に 行ゼロ分岐を強いる。

設計者裁定（2026-07-13・方向）: 候補 3 形（本形・empty 生成子・恒偽の標準述語＝比較は 90-open-questions が正本）から空テーブルリテラルの合法化を設計に進める。socket の要否判断は F98 確定後（同日裁定）。

規定（検証済み・ADR-45 で確定）:

  1. 昇格規則の拡張（ADR-26 改訂）: 空リスト [] は covering: が後置されたときに限り 時間ストリーム定数（空テーブル）に昇格する。covering の無い [] の型は従来どおり空の値 リスト（値位置では現に合法——in [] 等）で、ストリーム期待位置に置くと静的エラー（従来 どおり・誘導文言を追加＝「covering: を付ければ空テーブル」）。labels: だけ付けた [] も誘導 つき静的エラー（「空テーブルは covering: を明示する」）——省略既定「列の端＝閉区間 [先頭要素, 末尾要素]」（ADR-37 判断 1）が空列で定義できないため、覆域の主張なしに空テーブルは書けない （うるさい側が安全側＝判断 9 の省略既定と同じ統治）。segmentBy(labels:) の空リスト不可 （ADR-39——窓列側）と cycle/split 等のリスト引数の扱いは本節の射程外・従来どおり。
  2. 静的検査は空虚に成立: 包含（列の全要素 ⊆ covering・ADR-37 判断 1）・昇順/重複（ADR-26）・ labels: 同長（ADR-30——labels: [] は 0=0 で合法・空でない labels は同長違反の静的エラー。 ADR-39 の「空リスト不可」は窓列〈segmentBy〉側の規定と改訂で限定する）。ソース生成器は テーブル直書き生成に限り行数 0..N で同一の出力形になる（F98 の実駆動〈sekki テーブル〉は これで救われる。segmentBy＋labels: 生成形〈kyureki 型〉の空マーカーは従来どおり硬エラー＝ 射程外・需要が立てば別綻び）。
  3. 整列＝空虚適合の第三状態（ADR-36 改訂）: 空テーブルは全ての整列に空虚適合（違反しうる 点が無い＝空虚な真）。規定の射程は判断 2〜4 に及ぶ——(i) 判断 2 の「G か『なし』の二値」宣言に 第三状態を追加、(ii) 判断 3 の検査は相手が「なし」でも通す（「なし」は主張できない＝検査に 落ちる・空虚適合は検査に通る——F93 の未 snap マーカー窓との対比）、(iii) 判断 4 の和の出力 規則・&/\ の出力整列は相手側を継承（空虚適合|B ＝ B。「両辺同一でなければなし」の字面 より優先）、(iv) 保存系の段（filter・選択子・shift 窓語・roll・snapTo・rebase〈点ゼロは恒等〉）は 空虚適合を保存。カレンダー実体の day 整列要件（ADR-35 正体判定）も空虚に通る＝空 nonWorking の実体が boot し bizDay = everyDay（覆域内）。tz 名検査（ADR-36 改訂 2）は市民グリッド同士の 規定のため空虚適合には掛からない（点ゼロに 1 日ずれは起き得ない）。
  4. 意味論: 値は空列・covering は通常どおり二面の主張（「範囲内は完全＝点が無いことは知識・ 範囲外は未知」＝判断 1 の字面の空列読みそのもの）。範囲外評価は範囲外註釈・被覆サマリに〔源・ covering・asof・残走路〕——回避形と動的観測（点・註釈・サマリ・残走路）で等価。静的には 受理域が広がる（回避形は day 整列・本形は空虚適合——経過グリッド相手の &/\ が本形では通る）。 束縛名射影の失敗分類は判断 6 のまま不変——完全主張は分類を軟化しない（覆域内の sekki(d) 失敗は従来どおり硬エラー＝取り違え検出。「正当な該当なし」と混同しない）。規則性 （endless）は有限＝テーブル由来が正（回避形〈everyDay 由来＝無限〉との唯一の静的差。 ADR-39 の規則マーカー検査で空テーブル合成が正しく受理される側に倒れる）。開端 [] covering: .. は「全時間で恒空」の完全主張（単発除外テーブル [点] covering: .. の双対。判断 9 の統治＝ source:/asof: 宣言必須寄り・被覆サマリ常時表示が同様に掛かる。boot 用途は閉端で書くのが 作法——残走路信号を恒久に消さない）。区間リスト covering も可。tz: 宣言必須は従来どおり （覆域端の市民日解決＝ADR-37 判断 1。premise の日付テーブル判定は covering 後置で発火）。
  5. EBNF は変更なし: list-literal = "[" , [ list-elem , … ] , "]" は要素列が既に省略可能 （spec §5.6）で、空を弾いているのは意味層。「空⇒covering 必須」も静的検査に置く（エラー文言の 質のため——文法エラーは誘導を語れない）。変更は §5.6 の意味論注記（「型が要素で決まる」→空は covering: の有無で決まる・束縛後置注記「テーブルの属性と同義」→「テーブル属性として読む」）。
  6. 束縛後置の被覆主張（判断 5）との関係: [] covering: はリテラル自身の覆域（データの主張・ 包含検査の側）。束縛後置は合成への検証不能な主張（必要条件検査の側）のまま別物——「rhs が裸の テーブルリテラルなら listLiteral が先に食う」の既存規則も不変。

書ける形（doctest は reference/table-literal.md）:

sekki = [] covering: 2026-07-13..2026-07-13   # 点ゼロ・覆域は主張——boot 可・runway 即負の運用信号

検証（2026-07-13・3 視点＝整合性/コーパス全数掃引/敵対的・実装可能性）: 構造欠陥 0・要修正 7 （本節に反映済み＝裸 [] の線引き・ADR-39 との字面衝突の限定・射影失敗分類の明文化・EBNF 前提の 誤り・整列第三状態の射程・§5.6 束縛後置注記・行ゼロ分岐消滅の限定）・注記 4（動的観測等価の限定・ 0 行→1 行で整列が変わる非連続は字面ベース整列の原理的帰結〈ADR の限界に明記〉・開端の統治・掃引 リスト増補）。検証の副産物＝F99: roll の空軸で依存像（ADR-37 判断 4 roll 行）の早期 return が 保守拡張を殺し、「有限 covering＝空＋註釈」と「開端＝註釈なしの空」の観測差が消えていた既存 impl 欠陥——修正済み（90-findings F99）。impl 実装済み・全消費位置の掃引テスト 23 本 （empty-table.test.ts）を含め全テスト通過。

1.27 外部供給宣言（socket）——実行時に解決されるテーブルリテラル（確定 → ADR-46。裁定 2026-07-14＝採用・宣言語 external）

動機: 発報層還流第一次（適用検討 03・非公開）でソース生成方式の実測痛点 2 件が確定—— (1) ソースが静的でいられない（日次再実体化ごとに DB から再生成＝プロバイダ形への拡張が必須。 決定性の担保がソース差分検査の回り道になる）、(2) 統治の焼き忘れ（covering 必須・asof 焼き込み・ 昇順正規化を生成器が写経し続け、漏れると観測面が欠ける）。実装後の見立て＝「socket 宣言 1 行の 価値は生成器に写経される統治の量に比例」。方向提示は §1.15（external(kind:, source:)・器だけ 規定）と 90-open-questions（ADR-36 帰結＝器は整列の主張を含むこと）が既存。

設計の核——「socket ＝実行時に解決されるテーブルリテラル」: 新しい型・新しい代数は導入しない。 socket 束縛の解決値はテーブル値そのもの（点列・covering・asof・labels?）であり、テーブル リテラルが字面で運ぶ静的性質だけを、字面が無い代わりに宣言で先取りする。解決値には テーブルリテラルと同一の統治検査（包含・昇順/重複・labels: 同長・covering 必須）を課す—— 生成方式で生成器が写経していた統治が、そのまま言語の供給契約になる。

規定（検証済み → ADR-46 で確定）:

  1. 形: 束縛名 = external(kind: 種別 [, labels: [値域]] [, source: "…"])（語はすべて仮の 呼び名——命名比較は判断 9）。premise 束縛の rhs 限定（本体層直書きは意味層の静的エラー・ 誘導つき——source: 統治が premise に居るため。文法で縛らない＝「文法エラーは誘導を語れない」 ADR-45 判断 5 と同型）。パイプ合成は可（external(…) |> snapTo(day) 等——「テーブルリテラルと 同格」は統治検査の面の同格。出自の焼印は external 評価点で束縛名を焼く〔パイプ中間で 無名化しない〕）。external は予約語（core 語再定義エラーの面に載せる）。EBNF の変更は param-key への kind（と source）の追加のみ（頭位置 name(args) は stream-atom で既に 導出可・kind 値は列挙ラベルと同じ「位置依存のキーワード解釈」＝ADR-42 の統一原理）。
  2. kind: ＝整列の主張（静的・宣言が字面の代役）: ADR-36 判断 2 のテーブル規則は字面から整列を 推論する。socket は字面が無いためその二分類そのものを宣言する——kind: dates（定義側 tz の 市民日グリッド整列）／kind: instants（整列なし）。整列は宣言から静的に決まり、解決値の 行数・中身に依存しない（空でも宣言どおり。ADR-45 の空虚適合は字面規則の帰結であり socket には適用しない——宣言があるのに使わないのは主張の放棄。帰結として、ADR-45 が原理的限界として 引き受けた「0 行→1 行で整列が変わる」非連続を socket は宣言で解消する）。契約検査は字面 でなく幾何——解決値の全点が宣言整列 G の目盛り上（dates＝定義側 tz の各市民日の最初の瞬間。 DST 隙間日の 01:00 開始も正しく通り、壁時計 h==0 判定は誤り）。
  3. labels: ＝値域の列挙宣言: 有無フラグでは足りない——ラベル語彙は静的知識（裸名 filter(s => sekki(s) == 立春) の名前解決・ADR-42 判断 7 の域外静的検査が要る）のため、 labels: [立春, 雨水, …] と値域を列挙して宣言する。解決値のラベルは宣言値域内（域外＝ 契約違反）・無宣言の socket にラベルが到着したら契約違反（ADR-39「未知の named-arg を黙って 捨てない」と同じ統治）。
  4. 統治の随伴——「要求は器・内容はデータ」: source: は必須（premise メンバーで宣言・ 束縛ごとの上書きは external(source: "…") の named-arg——premise 単位の with 上書き〈ADR-35〉 とは別の束縛単位機構として明記）。covering と asof は解決値が必ず運ぶ（どちらも欠落＝契約 違反——第一次還流の痛点 (2)〈asof 焼き忘れ〉を契約で消すには asof も必須でなければならない。 ADR-37 帰結「socket の器は被覆主張を含む」の精密化＝器が含むのは被覆の要求・主張の内容は データが運ぶ）。解決値 asof の効力は当該束縛の出自属性（註釈・被覆サマリの asof 欄）に 限る——premise の静的 asof:（版ピン）と食い違うときは被覆サマリに常時表示（黙って 上書きしない・ADR-16）。socket 束縛を持つ premise は tz: 宣言必須（ADR-37 判断 1 の 延長——covering 端と dates の錨は定義側 tz で解決＝ADR-35 判断 8）。束縛後置の covering: （ADR-37 判断 5＝合成への被覆主張）は従来どおり付けられる（必要条件検査は解決時に走る）。
  5. 解決の意味論（純粋性 I7 との整理）: 解決は評価文脈の随伴であり評価中の副作用ではない ——先例が既に二つある（asof: latest＝評価時点の環境入力・tzdb の版供給〈ADR-33 判断 3〉）。 要求駆動＝評価内の初回参照時に一回解決（ADR-33 判断 8 の tz と同型。未参照の socket は 解決されない——解決子が無くてもエラーにならない）。スナップショットの単位は〔定義側 premise（base 連鎖の解決後）・束縛名・上書き後の source:〕ごと——with 派生・多文脈・修飾 参照はすべて同一スナップショットを見る（解決子に渡すのも定義側 premise 名）。錨打ち・ covering 端の解決（変換）は評価文脈ごと（リテラルの再錨と同型・tz が違えば違って正しい）。 スナップショット識別（解決値 asof）はメモ化の文脈キーに参加（ADR-35 帰結「参照した文脈 メンバーをキーに含める」の延長——常駐評価器での版差の誤共有を封じる）。評価はスナップショット 相対で純粋・決定的。解決の手段は言語が規定しない（ADR-15——言語は器〈宣言・契約検査・ エラー分類〉まで。DB・ファイル・HTTP は実装系の責務）。
  6. 契約検査（解決時・リテラルと同一の文言体系）: covering 欠落・asof 欠落・kind 不一致 （幾何＝判断 2）・乱順/重複・包含（全点 ⊆ covering・ADR-37 判断 1）・labels 同長/域外/ 無宣言到着・日付の実在（2026-02-30 級——リテラルでは字句層〈ADR-43〉が守るが解決値は字句を 経ないため再執行が必須。黙ったロールオーバーの再発防止）・数値の有限性（ms wire）。 根拠法は ADR-33 判断 9（データ相対エラーの並置は「拡張であって矛盾ではない」）。wire 形式は kind ごと——dates＝市民日付（年月日）で受けて言語側が錨打ちする（派生の tz 上書きで再錨 できる・DST 隙間日の day 開始も言語側 civilDayStart に一元化）・instants＝epoch ms で受ける （壁時計字面は DST 重複で二意になり得るため）。
  7. エラー分類: (a) 解決失敗（解決子なし・供給側不達）＝評価エラーの機械可読な部分類（供給 エラー）——実装系はこの部分類を boot throw から除外して劣化運転に落としてよい（還流 §3-1 の 実測「インフラ失敗を boot throw に含めるとプラットフォーム全体を巻き込む」に適合するための 識別の器。言語が規定するのは「黙って空にしない」まで）、(b) 契約違反（判断 6）＝評価エラー （ソース／契約の不正＝boot throw 対象）、(c) 空データ（0 行＋covering）＝正当な値（ADR-45。 「まだ無い」と「解決失敗」が型で区別される）。
  8. 既存機構は全部そのまま乗る: 範囲外註釈・被覆サマリ・残走路（ADR-37）・整列検査・coincides・ 束縛名射影（テーブルへの値引数は従来どおり静的エラー＝ADR-42 判断 5——socket でも filter が 正準）。実体の正体判定（nonWorking = external(kind: dates)）は全項目が解決前に静的に通る （存在・型・引数なし・day 整列＝宣言 kind・tz: 宣言——ADR-36 帰結〈器は整列の主張を含む〉の 解決）。新しい観測面はゼロ。
  9. 参照実装の器と命名（裁定事項）: run(source, opts) に同期の解決子フック （resolve(定義側premise名, 束縛名, 宣言) → データ）。契約検査はリテラルの検査部 （evalList 後半）を括り出して共用（文言体系の一致が構造で立つ）。doctest は # resolve: ディレクティブ（テーブルリテラル字面の流用＋asof ミニ構文）で書ける——契約違反の実行例だけは エラー期待の照合形が要る（任意・第二段）。命名: 宣言語 external（§1.15 初出形）／socket （通称——ただし英語版 ADR-15 の “socket”〈器の比喩〉と同綴り別義になるため external 推奨）。 kind 値 dates/instants（everyInstant・date-literal と語感整合・衝突なしを掃引確認済み）。

書ける形（候補確定後の想定）:

premise EphDB {
  source: "supplier-db/eph_event"
  tz:     "Asia/Tokyo"
  sekki    = external(kind: instants, labels: [小寒, 大寒, 立春, 雨水])  # 時刻付き・ラベル値域を宣言
  holidays = external(kind: dates)                                       # 日付列＝市民日グリッド整列
}

要否の判断材料（裁定の本体・検証で較正済み）:

検証（2026-07-14・3 視点＝整合性/コーパス全数掃引/敵対的・実装可能性）: 構造欠陥 0。要修正 16（本節に反映済み——主なもの: 空解決値の整列は宣言どおり〈視点間の衝突を裁定——ADR-36 の 「整列は静的・データの値に依存しない」原則が、リテラルとの空形観測等価より優る〉・解決失敗の 機械可読部分類〈boot throw 線引きの器〉・asof 必須化と上書き射程・tz: 必須の拡張・labels は値域 列挙・契約検査の幾何化と F66 再執行・スナップショット三層粒度・要求駆動の明記・EBNF は param-key 追加のみ・価値主張の較正 2 点・対価に監査責務を追加）・注記 7（ADR-42 誤引用の修正・被覆主張の 「要求／内容」整理・代替案 (d) の追加ほか）。実装差分の見積もり＝src +160〜210 行・全変更が 加算的（parser 差分ゼロ＝既存 call 構文で読める）・テスト 25〜35 本＋観測等価スイート。socket 言及の既存字面は 34 箇所（採用時要更新 13・不採用時 12——掃引リスト確保済み）。

1.28 窓列への周期ラベル——labels: の cycle 形（候補設計・検証済み。発報層還流 第 5 便 §3。裁定 3 件済み 2026-07-25・ADR 化と実装は指示待ち）

動機: 「窓列＝暦の単位・ラベル＝固定周期」の形（節切り月の十二支・月家九星・月星座の 12 宮巡回） で、現行の静的 labels: は同長性検査（リスト長＝窓数＝マーカー数）を課すため、covering が複数年に 伸びるとリストを年数分（24・36…個）並べ直す必要がある。これは ADR-46 の静的ソース原則（式は静的・ データは実行時解決）と衝突する——マーカーが external で増減するたびに式（labels 列）の改稿が要る。 第 3 の適用ドメイン（暦×占い）の主要形で実需が立った（第 5 便 §3）。

設計の核: segmentBy の labels: の値位置に cycle 形を許す——

sekkiMonth = everyDay |> segmentBy((setsu |> snapTo(day)), edges: drop, empties: error,
                                   labels: cycle [寅, 卯, 辰, 巳, 午, 未, 申, 酉, 戌, 亥, 子, 丑]
                                   anchor: 2026-02-04)

意味論は窓束縛への cycle（ADR-03/30）と同一——「anchor の属する窓が先頭ラベル」（実装の 定義式 labels[(idx − anchor) mod N]〈eval 1808〉と同型。「先頭」とは list[0] が anchor の窓の ラベルになるという意味であり、リストの回転は anchor を取り直さない限り別の暦——reference/cycle.md の旧落とし穴文の誤りは本検証で検出し訂正済み）。対象が「パーティション束縛」から「窓列」に変わる だけで、cycle の既存規約（リストは巡回順・anchor が位相を留める実日・読みは束縛名射影）を再利用 する。新語彙ゼロ（cycle・anchor: とも既存語）。

定義:

守備範囲の較正（裁定 2026-07-25＝トレードオフ受け入れ）: cycle 形が守るのは位相の宣言 のみ。同長性検査（F62 の器）を外すため、(a) マーカーの中途挿入・欠落（external の節気重複・ 欠測・供給側訂正）は挿入点の片側の全ラベルが黙って一斉に回る、(b) 非周期列への誤用（旧暦 月番号——閏月は前月番号の繰り返しで周期でない）は閏のたび永続ずれが累積する——いずれも照合相手の リストが存在せず機械検出は原理的に不可能（静的 labels: なら同長性検査が割れていたクラス）。 中身と周期性の照合は doctest・coincides の分担（ADR-39 判断 6「守るのは長さのみ」と同じ 線——cycle 形では「守るのは位相のみ」）。reference には使い分け（周期→cycle 形・非周期データ→ 静的 labels:）と誤用時の症状（無エラーの黙走）・反例 doctest を必置する。

対比検討（不採用・第 5 便裁定）: (a) cycle のオペランド拡張（sekkiMonth cycle […]）は、窓 （windows 値・暦法純粋の律動）と窓列（stream+wins・データ由来）の型差を跨ぐ——cycle の暦法 純粋（I8）の性格を壊し、影響範囲も広い。labels: の器内で閉じる (b) を採る。

縁の確認（コーパス検証 2026-07-25・全一致）:

構文（EBNF 案・segmentBy の named-arg 限定）:

segment-labels = "labels" , ":" , ( list-literal | name | cycle-labels ) ;
cycle-labels   = "cycle" , ( list-literal | name ) , "anchor" , ":" , date-literal ;

テーブルリテラルの labels: には入れない（テーブルは点への 1 対 1——周期を貼りたい点列は「テーブル でなく cycle」の既存誘導が立つ）。cycle は spec §5.4 で premise 層の窓生成語——本体層 segmentBy の named-arg 値位置への出現は位置依存のキーワード解釈（ADR-42 統一原理）として §5.4 に配置 注記を足す。

実装スケッチ（実装可能性検証 2026-07-25 反映）: AST に { t: 'cycleLabels', list, anchor } ノード新設（Arg は Expr 単値のため anchor を同ノードに畳む）・parser は labels: キーで cycle を 先読み分岐（現行は name atom→index 後置と誤解釈して ParseError——先読みが必須）・scanVocab に cycleLabels 分岐（欠くと列挙名が語彙に入らず「未解決の名前: 寅」で落ちる——検証で検出済み）・ WinLevel に別フィールド labelsCycle?: { list; i0 } を足し参照 8 サイトに mod 分岐（既存 labels に 窓数分実体化する近道は W(v) の域外検査を壊すため不可）・既存エラー文言 2 箇所（eval 2256/2031 の 「周期ラベルは cycle へ」）を「窓束縛 cycle」へ書き分け。規模概算＝実装 3 ファイル（ast 約 2 行・ parser 15-20 行・eval 60-80 行）・文書 4-6 ファイル・テスト 12-15 本。

検証記録（2026-07-25）: 4 視点並列（整合性・コーパス・実装可能性・敵対）＝指摘 32 件（critical 2〈パース経路・語彙収集〉・major 10・minor/規定不足ほか）→全件を本節に反映済み。設計者裁定 3 件＝ ①同長性検査喪失のトレードオフ受け入れ（較正明文化）②リスト値域は束縛名も許す③anchor 窓消失は 一般評価エラー（同位相付け替え候補の提示つき）。付随修正＝reference/cycle.md 落とし穴の既存誤り （「リストを書き換えても anchor が同じなら同一の暦」——実装・spec と矛盾）を訂正。

2. 代表例（core と糖衣の対応）

2.1 毎月末の 3 営業日前

# 糖衣
@JP
monthEnd |> roll(Preceding, on: bizDay) |> shift(-3, unit: bizDay)

# core 展開
@JP
everyDay |> within(month) |> last |> roll(Preceding, on: bizDay) |> shift(-3, unit: bizDay)

意味: 全日を月ごとに束ね、各月の最終日を採り、営業日でなければ前営業日へ寄せ、そこから 3 営業日戻す。 monthEnd は暦法純粋（I8）なので 5-31 を出す。営業日への調整は後段の roll が担う（ADR-20）。on: bizDay は @JP の calendar: TSE に解決される（ADR-17）。軸を後置に畳めば @JP axis: bizDay の下で on:/unit: を省ける（§1.7）。

2.2 毎月第 2 営業日の次の金曜

# 糖衣
@JP
everyDay |> businessDays(on: bizDay) |> within(month) |> nth(2) |> nextWeekday(Fri)

# core 展開
@JP
everyDay |> filter(on: bizDay) |> within(month) |> nth(2)
         |> roll(Following, on: (everyDay |> filter(x => weekday(x) == Fri)))

意味: 全日から営業日だけ残し、月ごとに束ね、各月窓の第 2 を採り、次の金曜へ進める。nextWeekday(Fri) の 展開先は前方 roll（§1.16 補。旧 within(week) 展開は F31 で撤回）で、WKST 非依存。

3. 演算子の暫定シグネチャ（作業中）

premise 層・原始的定義の窓生成語（§1.11。名は確定＝spec §5.4）:

premise 層・派生的定義（§1.12。with は確定・旧仮称 shiftBoundary は rephase に裁定済み〈2026-07-26〉）:

糖衣定義（§1.13。専用構文なし＝既存の = 束縛）:

4. 未確定事項（構文レベル）

宿題の正本は ../90-open-questions.md（RC 時点の整理済み一覧）。構文レベルの残りは:

This site is open source. Improve this page.