綻びログ集約（F1〜F105）
表現力検証（01〜06）とリファレンス実装の試作（impl/）、カレンダー実体の候補設計（draft §1.19）と そのレビュー、stdlib 拡充（Fiscal・ISOWeek・Kyureki）、TZ・label: の確定（ADR-33/34）、 カレンダー実体・粒度整合の確定（ADR-35/36）、範囲外出自・窓所属述語・rebase の確定 （ADR-37〜40）とその検証、細粒度カレンダー軸の綻び出し（06-business-hours）、発報層実装からの 還流（第一次・適用検討 03＝非公開）、業務定型 25 種の記述可否還流（第 3 便・適用検討 04＝非公開）で 出た綻びの全件表と、補完機構への写像。 番号は初出ファイルの記載順。「処置」は draft の設計節（§1.15〜）・ADR 候補・90-open-questions （宿題送り）への振り分け。
全件表
| # | 綻び | 初出 | 処置 | |
|---|---|---|---|---|
| F1 | 「毎年 M 月 D 日」が素の core で回りくどい（標準糖衣 onMonthDay 級の頻度） |
01 §1.1 | 標準糖衣候補（stdlib 送り） | |
| F2 | 点→月ラベルの射影が Gregorian に無い（monthName を派生で自作） |
01 §1.1 | §1.17（射影一族）＋stdlib 拡充 | |
| F3 | 単位窓以外への cycle（month）を初実使用——問題なし | 01 §1.1 | §1.16 で確定に格上げ | |
| F4 | cycle ラベルの述語参照が無いと最頻出パターンが書けない——暫定は機能した | 01 §1.2 | §1.16 で確定に格上げ | |
| F5 | テーブルリテラル（日付リスト→ストリーム）が無い | 01 §1.3 | §1.15 → ADR-26 | |
| F6 | データの尽きる端で列が黙って途切れる（ADR-15「事故の空」の実需） | 01 §1.3 | §1.15 に有効範囲の設計を含める | |
| F7 | 導出ストリームを roll の軸に渡せるかが未規定 | 01 §1.4 | §1.15 で軸とストリームの型関係を明文化 | |
| F8 | 振替の再帰（連続振替）は書けない——固定回数展開で実用上足りる | 01 §1.4 | 記録のみ（射程外と明記） | |
| F9 | 特定の窓インスタンス参照（year(2020) の日々）が無い |
01 §1.6 | 確定（ADR-42・2026-07-09）: 窓インスタンス参照＝逆像 W(v) ≡ 要素点列 \|> filter(d => W(d) == v)（ラベル源つき窓束縛のみ・時間ストリームで返す） |
|
| F10 | カレンダー実体（calendar: に与える休日集合）の登録構文が未規定 |
01 §1.7 | 確定（ADR-35・2026-07-08）: 実体＝予約公開語 nonWorking（仮称）を持つ premise・新構文ゼロ・bizDay 標準導出は言語規定 |
|
| F11 | nth の複数序数（nth([1,3])）は列挙するしかない |
01 §1.8 | 宿題送り（糖衣で足りる） | |
| F12 | 日付リテラルの範囲（a..b）が無い |
01 §1.9 | §1.15（テーブルリテラルの糖衣） | |
| F13 | cycle の anchor は権威データ（規則とデータの境界が premise 内を走る） | 02 §2.1 | §1.15 の設計原則に記載 | |
| F14 | 非 ASCII（漢字）ラベルの字句が未定義 | 02 §2.1 | §1.18（字句規則） | |
| F15 | ラベルは窓に付き述語は点で読む——「点→属する窓→ラベル」の二段解決の明文化。派生で窓が動くとラベルが変わる問題は Base. ピンで解決 |
02 §2.2 | §1.16 で明文化 | |
| F16 | cycle の積（zip）は無い——述語合成で代替可、優先度低 | 02 §2.3 | 宿題送り | |
| F17 | 窓内序数の値射影 ordinalIn(w, d) が無い |
02 §2.4 | §1.17 → ADR-27 | |
| F18 | 窓ラベルの値射影（読む側）が無い | 02 §2.4 | §1.17 → ADR-27 | |
| F19 | 選日の対応表も権威データ | 02 §2.5 | §1.15 の適用例 | |
| F20 | リスト所属述語 in が値式に無い |
02 §2.5 | §1.18（値式の追補） | |
| F21 | 点→窓先頭への射影（snap/floor） が無い | 03 §3.1 | §1.17 → ADR-27 | |
| F22 | 粗い単位列を細かいマーカーで切るときの所属規約（segmentBy）が未明文 | 03 §3.1 | §1.15 で明文化（→ spec §4.2 追補） | |
| F23 | 窓へのラベル付与（書く側。旧暦月名・ISO 週番号・年度ラベルが同族）が無い | 03 §3.2 | §1.17 → ADR-27 | |
| F24 | 隣接窓の値への参照（閏月の「前月名を継ぐ」）が無い——データ側に倒すのが現実解 | 03 §3.2 | 記録のみ（射程外と明記） | |
| F25 | premise 層で本体層演算子を使う層またぎ規則が未明文（旧暦の成立がこれに掛かる） | 03 §3.2 | §1.15 で明文化（要 RC） | |
| F26 | 範囲 shift（±k 日）は列挙になる。可変幅は fold が無く不可 | 03 §3.3 | 宿題送り | |
| F27 | 裸ストリームへの of: 付き選択子の窓解決規約が際どい |
03 §3.3 | spec §4.3 の明文化（フェーズ 4） | |
| F28 | 値→時点の持ち上げ（dateOf）か点→値の射影（yearNo 等）のどちらかが要る——射影を先に、持ち上げは保留が筋 | 03 §3.5 | §1.17 → ADR-27 | |
| F29 | premise ブロック外の値束縛の置き場が未明文 | 03 §3.5 | §1.18 で明文化 | |
| F30 | 暫定 selectWeekday(d) = filter(…) は誤り: 入力要素自身を濾すだけで「窓内の d ラベル点へ写す」写像にならない（機構設計中に発見） |
設計時 | §1.16 補で廃語 | |
| F31 | nextWeekday の旧展開 within(week) \|> selectWeekday(d) は同週選択のため週後半の点で過去へ飛ぶ。要求（次の d 曜へ進む）の意味論は前方 roll——roll(Following, on: 導出ラベルストリーム) で新語ゼロ・WKST 非依存に |
設計時 | §1.16 補で確定（spec §4.8/§7.2 の書き直し要） | |
| F32 | 中気抽出 stride(2) は暦年順の先頭が節気（小寒）のため起点をずらさないと節気を拾う。黄経ラベルで filter するのが厳密（実データ投入で判明） |
03 §3.2 | §1.17（labelOf）＝群 2 | |
| F33 | 実データで判明: 「立春＝各年最初の節気」は誤り。暦年の最初の節気は小寒。特定の節気（立春＝黄経 315°）を選ぶには点→節気名/黄経の射影（labelOf）とラベル付きテーブル（時点のみのテーブルリテラルでは序数でしか選べない）が要る | 03 §3.3 | §1.17（labelOf）＋ADR-26 拡張＝群 2 | |
| F34 | 射影に二つの「番号」（epochOrdinal＝紀元通し／ordinalIn＝窓内リセット）があり、ordinalIn(w,d) は d が w の要素・epochOrdinal(w,d) は d が w に属する、で d の意味がずれる。二窓引数 ordinalIn(数える窓, 枠窓, d) に一本化の余地 |
04 §4.1 | §1.17 改稿（引数設計） | |
| F35 | 射影値は入力ストリームの粒度に依存（ordinalIn(month,d) は入力が日なら「第何日」、瞬間なら「第何瞬間」）。「窓の下位窓を数える」版（粒度非依存）が別に要る |
04 §4.2 | §1.17 改稿（粒度非依存版） | |
| F36 | labelOf が読むラベルの源が三種（cycle 由来／label: 付与／暦座標糖衣）で、現行案は未区別。「窓はラベルを一つ持ち源は生成時に決まる」モデルが要る |
04 §4.3 | §1.17 改稿（ラベル源モデル） | |
| F37 | 閏月番号「前月名を継ぐ」＝隣接窓参照（F24・射程外）。label: の付与式が前の窓の値を読めないと貼れない → 旧暦月名はテーブルリテラル（月名列）に倒すのが現実解 |
04 §4.3 | 射程外確認（データへ） | |
| F38 | ラベル付きテーブルリテラルが要る（時点＋名前＋黄経の三つ組）。ADR-26 の「時点のみ」を列を持つ表へ拡張 | 04 §4.4 | ADR-26 拡張 | |
| F39 | データ列への 1 対 1 ラベル付け（節気 24 名）は cycle（暦独立の律動）でなく表の列（源 2）。cycle と label: の役割境界の整理 | 04 §4.4 | §1.16/§1.17 境界整理 | |
| F40 | ISO 週番号・年度ラベルは label: 付与式が別の点の窓（週の木曜が属する年）を参照する。射影が「d の属する窓」だけでなく関係点の窓を要求する初例。付与式の表現力設計 |
04 §4.5 | §1.17（label: 表現力）。追記（F57・2026-07-07）: ISO 週番号は label: 不要の等価変形が見つかり「初例」から外れた（残る動機は年度ラベル表記・旧暦月名・節気名） | |
| F41 | snapTo(w)・w|>first・公開境界語・labelOf(境界版) が同じ「窓の先頭点」を別経路で読む（重複）。snapTo(w) を「点→属する w 窓 |
> first」の糖衣にすれば新規語から外せる | 04 §4.6 | §1.17（snapTo 糖衣化） |
| F42 | 「n 個ごと窓リセット」の還元（ADR-27 の主張）は成立するが、数える対象は入力粒度依存（F35 の横断的再確認）。暦日で数えたいのに営業日列だと書けない | 04 §4.7 | §1.17（F35 と同根） |
リファレンス実装の試作で出た綻び（F43〜F50・2026-07-07）
impl/ のパーサ・評価器で spec §7 全例＋暦要項実データを動かして炙り出した。実行は全例成功
（39 テスト通過）——以下は動かすために実装が独自に決めた未規定点（F43/F44/F49/F50）と、
spec の例と規則の不整合（F45〜F48）。前者は追加規定（既存の確定意味論は不変）、後者は例・字面の修正。
| # | 綻び | 初出 | 処置 |
|---|---|---|---|
| F43 | grid の位相（アンカー）が未規定——grid(w) がどこから刻み始めるか。1d は TZ 真夜中と読めるが一般幅（10d 等）では位相が結果を変える。span/stride は phase:/from: を持つのに grid だけ位相引数が無い。実装は紀元（TZ の 1970-01-01T00:00）に固定 |
impl | 確定（ADR-31）: 既定整列（市民時幅＝tz 真夜中・経過時間幅＝紀元）＋anchor: 上書き |
| F44 | 紀元が未規定——span の「窓の序数 n（紀元起点）」・epochOrdinal の紀元がどの時点か spec に無い。stdlib の yearOf も「紀元年 + m div 12」と抽象のまま。epochOrdinal の 0/1 起点も未規定（ordinalIn は 1 起点と明記済み）。実装は 1970-01-01・0 起点に固定 |
impl | 確定（ADR-31）: 言語既定 1970-01-01・原始的定義のメンバー epoch: で上書き可・序数は 0 起点 |
| F45 | §7.2 の糖衣は生成子位置で破綻——businessDays(on: p) = filter(on: p)（変換）を式の先頭に置くと「展開＝右辺の機械的差し込み」（§4.8）で core 形の everyDay が出てこない。§7.2 の糖衣例と展開規則が不整合。実装は生成子形 everyDay \|> filter(on: p) に修正して通した |
impl | 修正済み（2026-07-07）: §7.2/draft の例を everyDay \|> businessDays(…) に。定義は変換のまま（カレンダー依存の生成子は ADR-20 の却下案） |
| F46 | day segmentBy(…) の並置が EBNF から導出できない——spec §3.6・stdlib の week 定義は \|> なしの並置だが、EBNF の並置（gen-expr）は grid/span/split/cycle のみ。実装は並置 stage を特例で受けた |
impl | 修正済み（2026-07-07）: 全例を day \|> segmentBy(…) に統一（並置は窓生成語 4 語のみ）。実装も並置受理を撤去 |
| F47 | §4.2 の everyInstant \|> strideBy(…) 例は起点規則と矛盾——前段窓も from: も無く、§4.7「どちらも無ければ静的エラー」に抵触 |
impl | 修正済み（2026-07-07）: §4.2/draft の例に from: を追補（everyInstant は前段窓を持たないため必須） |
| F48 | ラベル付きテーブルの射影名の導出が不明確——ADR-30 の例は sekki = […] labels: […] で「sekkiName(d) が立つ」と書くが、束縛名から Name 接尾辞を導く規則はどこにも無い。「束縛名で読む」の素直な帰結は束縛名そのもの（sekki(d)）。実装は束縛名を採用 |
impl | 修正済み（2026-07-07）: 規則は「束縛名がそのまま射影名」＝sekki(d)。ADR-30 に改訂追記・spec §3.8/§4.9/glossary/draft/03 を同期 |
| F49 | stride の「前段窓の起点」は多義——窓が複数あるとき（within(month) の月々）どの窓の起点か。「最初の窓」と読むと評価範囲に依存し I7（純粋）と緊張。実装は from: を推奨し窓起点は最内窓の最初の区間で近似 |
impl | 確定（ADR-31）: from: 必須化（窓からの起点供給は廃止）。stride/strideBy 一族共通 |
| F50 | tz:/source: メンバー値の字句が識別子と衝突——Asia/Tokyo の /（除算）・cao.go.jp/official の .// は value-expr として読めず、EBNF の member = member-key ":" value-expr が成り立たない。実装は当該メンバーを行末までの生文字列で読んだ |
impl | 確定（ADR-32）: 文字列リテラル "…" を導入、tz:/source: は文字列を取る |
カレンダー実体の候補設計で出た綻び（F51〜F54・2026-07-07）
draft §1.19（実体＝予約公開語 nonWorking（仮）を持つ premise・新構文ゼロ）の執筆で炙り出した。
候補設計はレビュー（2026-07-07・方向承認）を経て ADR-35/36 で確定した（2026-07-08。F55 は
ADR-33 で確定済み）。
| # | 綻び | 初出 | 処置 |
|---|---|---|---|
| F51 | 予約公開語の名（nonWorking は仮称）。実体の正体判定に使う語なので取り違え面の検討が要る |
§1.19 | 確定（2026-07-09・一括純命名の設計者裁定）: nonWorking・coincides・rebase・bizOpen/bizClose/isOpen はそのまま正式名・供給の対は sessionOpens/sessionCloses に改名（ADR-41 改訂）。残る仮称は shiftBoundary 一語（1.0 送り継続）。正本は spec §5.4 |
| F52 | §1.19 | 裁定（2026-07-07・時刻も射程内）→ ADR-35 判断 2 で確定（2026-07-08）: nonWorking は day 整列の予約語（「日粒度で読む」の操作的定義）・細粒度は同実体の別の束縛として射程内。残り半分（細粒度軸の導出形）は F67 |
|
| F53 | on: TSE の直固定（§1.7 で許可済み）は on: が軸＝ストリームを取るのと型が合わない。「premise 名が軸位置に立ったら bizDay 導出を適用」の一行規約が要る |
§1.19 | 確定（ADR-35 判断 4・2026-07-08）: 束縛は通常解決・premise 名だけなら実体の正体判定＋標準導出への読み替え・両方は曖昧エラー。on: TSE ≡ calendar: TSE 下の on: bizDay（bizDay は calendar: 在圏で言語予約） |
| F54 | 実体と利用側の tz: が食い違うと集合差が黙って空振りする（ADR-16 の危険基準） |
§1.19 | 確定（ADR-36・2026-07-08）: 整列の tz 名成分の不一致として静的エラー（名前等値＝リテラル文字列・リンク解決前）。実体は tz: 宣言必須（ADR-35 正体判定＝内側固定の執行点）。snapTo 整合は「chronos の重なり」の意味（「同じ日付ラベル」は F69） |
§1.19 の設計者レビューで出た綻び（F55〜F56・2026-07-07）
| # | 綻び | 初出 | 処置 |
|---|---|---|---|
| F55 | 用語 TZ・前文メンバー tz: の定義が仕様に無い。I1「TZ で錨を打った時間軸」・ADR-28「錨は tz: が打つ」・ADR-31「市民時幅＝tz 真夜中」が正体を前提するが、正体（IANA 識別子との関係・chronos→市民座標の写像・DST/うるう秒・市民日境界と日付リテラル解釈）はどこにも規定されていない |
レビュー | 確定（ADR-33・2026-07-08）: 射影パラメータモデル＝基底は TZ 非依存・TZ は市民座標への版付き写像（premise 相対）。市民日は「最初の瞬間」規則・うるう秒はスコープ外・DST 隙間/重複リテラルは明示エラー。I1/glossary/spec の字面を現況更新 |
| F56 | 結合子（§4.5）に粒度整合の規定が無い——粒度のそろわない二流の演算（everyDay \ 瞬間列）は点が一致せず黙って空振り（ADR-16 危険基準）。F22（segmentBy 所属→snapTo で粒度をそろえる）と同形の問題の結合子版。F52 の裁定（細粒度も射程内）・F54（TZ 不一致）はこの「点の一致規則」に合流する |
レビュー | 確定（ADR-36・2026-07-08）: 整列（幅・正規化位相・tz 名の原子グリッド G への静的主張）を導入。&/\/軸所属は両辺同一 G を要求（違反は静的エラー・細分の自動整合なし）・snapTo が明示の再整列・和 \| は不問。F52 は「nonWorking＝day 整列の予約語・細粒度は別束縛」（ADR-35）で整合 |
stdlib 拡充（Fiscal・ISOWeek・Kyureki）で出た綻び（F57〜F63・2026-07-07〜08）
標準 premise の拡充（解説ページ 3 枚＋同梱化＋doctest 全例検証）で出た。設計上の発見 1 件（F57）・ 仕様・統治の穴 5 件（F58/F60/F63 は解消・確定済み・F61〜F62 は宿題）・実装の穴 1 件（F59・修正済み）。
| # | 綻び | 初出 | 処置 |
|---|---|---|---|
| F57 | ISO 週番号は label: 不要と判明——等価変形「W01 の月曜は必ず 12/29〜1/4 に落ちる」（任意の連続 7 日は月曜をちょうど 1 つ含む）により、filter＋segmentBy＋二窓 ordinalIn＋三項条件の確定語彙のみで書ける。isocalendar との全数照合（2024〜2028）で実証。F40 の「label: の初例」という位置づけが変わり、label: の残る動機は年度ラベルの表記・旧暦月名・節気名 |
stdlib | 解消（stdlib/iso-week.md §4 に還元の論証・F40 に追記）。値関数形は「週内で値が一貫」が式の正しさ依存というトレードオフも同所に記録 |
| F58 | 暦座標糖衣 yearNo/monthNo/dayNo は spec §4.9 が「糖衣」と予告するのみで正式な束縛場所が無かった（stdlib にも impl にも不在） |
stdlib | 解消: Gregorian の公開語に追加（stdlib/gregorian.md §1・impl 同梱） |
| F59 | 実装アーティファクト——span phase:>0 の頭・split 末尾に切れ端窓が張られず、ordinalIn/epochOrdinal が「枠窓の外」を誤報（会計月番号 ordinalIn(month, year, d)・素の ordinalIn(month, quarter, d) が書けなかった）。言語意味論（I5 全域パーティション）は明確で仕様は不変 |
stdlib | 解消: impl 修正（実体化の端に切れ端窓を張る）＋回帰テスト（stdlib-premises.test.ts） |
| F60 | データ由来窓（segmentBy 窓）への epochOrdinal の意味が spec 未規定——実装は「実体化された窓列の添字（先頭窓 = 0）」を返す。Kyureki の月番号（monthNos[epochOrdinal(lunarMonth, d)]）が公開文書としてこの意味に依存した。ADR-31 の紀元（1970）との関係の明文化が要る |
stdlib | 確定（ADR-31 改訂・2026-07-08）: 統一則「存在する窓列の通し序数（先頭 = 0）」——窓列が紀元まで届かないデータ由来窓では存在する最初の窓が 0 |
| F61 | 被覆域・計算範囲の外の点の扱いが未整理——値射影はデータ被覆域外の点で硬エラー（everyDay 起点で書けず lunarMonth 起点に倒す）・テーブル時点が計算範囲（to＋約 400 日）を越えると snapTo が硬エラー（狭い評価範囲が書けない）。I6/ADR-15 の「範囲外」出自に流すのが筋では。covering: が実装で不活性なことも同根 |
stdlib | 確定（ADR-37・2026-07-08）: 範囲外出自＝区間註釈・輸送表・実効被覆域の分類器・器の二形（註釈＋被覆サマリ）。計算範囲越えはクリップ＋実装警告に降格 |
| F62 | 並行値リスト（monthNos）と窓数の同長性検査が無い——labels: には同長検査があるのに、値リストを窓列の添字で引く形は照合されず、リストが窓数より長い方向のずれ（朔の書き漏らし等）は黙って月番号がずれる（短い方向は添字範囲外の硬エラーで止まる。ADR-16 の危険基準） |
stdlib | 確定（ADR-39・2026-07-08）: segmentBy の labels: 一般化＝結びを宣言に変え同長性検査（覆域基準・正確）を錨する。守るのは長さのみ（中身は doctest＋coincides の分担）——「器と正準形の確定」 |
| F63 | 値式 div・mod の負の被除数の意味論が未規定——spec は「整数除算」としか言わず floor か trunc かが決まらない。実装は floor（mod は数学的剰余）で、Fiscal の fiscalYearNo が紀元直後（1970-01〜03＝月序数 −3〜−1）で正しく 1969 を返すのは floor だから。trunc 実装なら黙って 1970 に化ける |
stdlib | 確定（ADR-31 改訂・2026-07-08）: div は floor・mod は数学的剰余と明文化（回帰テストで挙動固定済み） |
TZ の定義・label: 束縛規則の確定（ADR-33/34）とその検証で出た綻び（F64〜F66・2026-07-08）
| # | 綻び | 初出 | 処置 |
|---|---|---|---|
| F64 | 束縛名射影と窓インスタンス参照の同名適用の二義の芽——label: つき year を採ると year(d)（点→年度ラベル）が立つ一方、宿題 F9 は year(2020)（値→その年の窓の日々）を望んでいる。引数の型（点か値か）で振り分け可能だが、規定しないまま両方入れるとサイレントな取り違え（I3 違反）の芽 |
ADR-34 | 確定（ADR-42・2026-07-09）: 引数式の型で dispatch（点→射影・値→インスタンス参照）・判定時点は糖衣展開後・実引数束縛後（設計者裁定）。統一原理「位置依存の名前解釈」（ADR-35 判断 4 も同族）の受け皿ごと確定 |
| F65 | shiftBoundary の負合成位相——φ₀+δ < 0（US 型を δ=−3 で書く等）で実装が生の TypeError で落ちていた（検証で発見）。位相は周期 k を法として合成するのが意味論的に自然 |
検証 | 確定: 展開は phase: (φ₀+δ) mod k（§3.7・impl 修正済み）。素の span の負位相は明示エラー |
| F66 | 字句の残る未規定 2 点——(a) 日付部の値域（2025-02-30 等の非実在日の検査層＝字句か静的か。時刻部だけ規定して非対称が顕在化）、(b) 固定オフセット TZ 表記の字句形（ADR-33 は「"+09:00" 級」止まり） |
検証 | 確定（ADR-43・2026-07-09）: (a) 日付部の値域は字句エラー（2026-02-30 級の拒否——impl が黙って 2026-03-02 へロールオーバーしていた実バグを封じる）・(b) 固定オフセットは厳格一意形 "±HH:MM" のみ（HH 00–14・MM 00–59・ゼロ埋め必須。"Z"/"+0900"/"UTC+9" は字句エラー・UTC は IANA 名） |
カレンダー実体・粒度整合の確定（ADR-35/36）とその検証で出た綻び（F67〜F70・2026-07-08）
設計案の敵対的検証（7 視点・指摘 70 件）と実装で出た。いずれも既存の式の意味を変えない宿題 （追加拡張・明文化）。
| # | 綻び | 初出 | 処置 |
|---|---|---|---|
| F67 | 細粒度カレンダー軸（bizHour 級）の予約語・導出形が未設計——F52 裁定（時刻も射程内）の残り半分。nonWorking を day 整列の予約語に確定した（ADR-35 判断 2＝標準導出と整列検査の整合）帰結として、半日休・営業時間帯は同じ実体の中の別の束縛に置くが、それを読む標準導出はまだ無い |
ADR-35 検証 | 宿題［追加拡張］（90-open-questions）。追記（2026-07-08）: 論点 (1) は 06-business-hours で完了（F76〜F85・下節）——新語彙は表現力の必然としては不要・残る裁定は F79（＋規定 F81/F83） |
| F68 | 窓所属ベースの結合が無い——時刻付き・混合スケジュールに例外日を適用する形（「毎営業日 9 時の通知から祝日の日を除く」）は等値の差 \ では書けず、snapTo は発火時刻を潰すので修理形にならない。従来は黙って空振りしていた形が ADR-36 の検査で顕在化（安全側エラー）した |
ADR-36 検証 | 確定（ADR-38・2026-07-08）: 窓所属述語 coincides(S, w, d)（仮称・射影一族）＋証人規則＋tz 名検査。正準形は filter(t => not coincides(closures, day, t)) |
| F69 | 日付ラベル保存の再錨（rebase）が無い——クロス tz の「同じ日付」合成（TSE と NYSE の共通営業日）は chronos 等値では原理的に書けない。snapTo の整合は「chronos 上の重なりを利用側の日界で読む」別の問いへの答えで、東京の日先頭は NY の前日に floor される（系統的 1 日ずれ） |
ADR-36 検証 | 確定（ADR-40・2026-07-08）: 点変換 rebase(to:)（仮称・day 固定・最初の瞬間規則・非存在日付は明示エラー）。免除系の tz 名検査も同時に拡張（ADR-36 改訂 2） |
| F70 | stride(n) の軸相対カウントの操作的意味が二義——「在圏軸の単位数で n ごと」（§1.9）が「軸の点列上を n 歩ずつ」か「入力の点を n 個ごと」かは入力＝軸のとき一致するが、入力が軸の真部分集合だと割れる。reference/stride.md は入力相対の運用（先に filter）を示し、impl も入力相対の近似（ADR-36 の stride 検査は不発） |
ADR-36 検証 | 確定（ADR-38・2026-07-08）: 入力相対（軸引数なし・from: 以上の最初の入力点が第 0 歩・n ≥ 1）。ADR-36 の stride 検査は削除（改訂）。検証で stride(0)＝黙って空の既存バグも発見・封止 |
範囲外出自の確定（ADR-37）とその検証で出た綻び（F71〜F74・2026-07-08）
候補設計（draft §1.20）の 4 視点並列検証（整合性・コーパス全数掃引・実装可能性・敵対的、指摘約 40 件）で 出た。いずれも ADR-37 に取り込んで解消済み（当初案の構造欠陥の記録として残す）。
| # | 綻び | 初出 | 処置 |
|---|---|---|---|
| F71 | clip（当初案）の致命反例——covering が値を切ると、覆域外の支持点アンカー（旧暦 newMoons の 2024-12-31）が黙って消え、F60 の窓序数繰り上がり＋F62 無検査の並行リスト経由で、旗艦例 rokuyo.kairos が覆域内・エラーゼロ・註釈ゼロのまま全期間誤答（「黙って違う結果」の再生産） | ADR-37 検証（敵対） | 解消: covering は値に触れない＋包含の静的検査（判断 1）。kyureki の covering は実端へ拡幅 |
| F72 | 点渡し伝播の過小近似——「入力点が註釈区間内なら着地へ写す」は、註釈区間には定義上点が無いため空振り。shift が依存領域を平行移動させる形（満了 90 日前通知）・roll の覆域始端で漏れる。あわせて edges: がマーカー「列の端」で発火すると「覆域内・窓なし」帯が生じ分類器が誤爆 | ADR-37 検証（コーパス・敵対） | 解消: 区間そのものの輸送表（判断 4）＋ edges: の発火は覆域端＝実効被覆域（判断 4/6） |
| F73 | 年別テーブルの \| 合成が恒常註釈——覆域の積の補集合≒全時間で狼少年化（読まれない註釈＝サイレント故障の再来）。自動相殺は偽陰性を作る |
ADR-37 検証（敵対） | 解消: 明示の被覆主張＝束縛後置 covering:（判断 5。source/asof 同格の統治・必要条件検査つき） |
| F74 | クリップ済み註釈では「to 直後のデータ切れ」が観測できない——発報運用はデータ更新のリードタイムを知る必要があるのに、覆域は静的に判明していながら捨てられていた。開端 covering（完結主張）が「註釈を黙らせるスイッチ」になる危険も同根 | ADR-37 検証（敵対） | 解消: クリップしない被覆サマリ（源・covering・asof・完結主張・残走路）を器の第二形に（判断 7）。完結主張は常時表示 |
窓所属述語・stride 確定（ADR-38）とその検証で出た綻び（F75・2026-07-08）
| # | 綻び | 初出 | 処置 |
|---|---|---|---|
| F75 | filter 輸送行（ADR-37 判断 4）の過小近似——述語が読むのは点 d 自身とは限らず d の属する窓の全域（coincides・データ由来窓越しの ordinalIn）。「依存束縛の註釈区間∩評価域」の従来行では、窓が覆域端を跨ぐ点の落ちが無註釈になる（規範「過小近似は不可」違反）。coincides の設計が強制事例になったが、既存の窓越し ordinalIn 述語にも潜在していた | ADR-38 検証（整合性） | 解消（ADR-37 改訂 2）: 輸送を「述語が読んだ領域（窓）の逆像へ拡幅」に一般化（選択子行と同型） |
細粒度カレンダー軸の綻び出し（06-business-hours・F76〜F85・2026-07-08）
F67 の設計論点 (1)——既存語彙での書き味——を 06-business-hours.md で実行検証した結果。
「書けない構造」は無く（毎営業日 9 時の壁時計・営業時間内の毎時・営業帯＋半日休 11:30 引け・
DST 切替日の壁時計保存・深夜営業の帰属、いずれも確定語彙のみ・doctest 通過）、新しい予約語・
新構文・新射影は表現力の必然としては不要と判明。起草後の敵対的検証 4 視点（指摘 20 件・全反映）で
impl の欠陥 1 件（F82・修正済み）と未規定の姉妹穴（F83）・使用上の罠 2 件（F84/F85）が加わった。
| # | 綻び | 初出 | 処置 |
|---|---|---|---|
| F76 | 「時刻」の二意味論の取り違え面（経過時間 vs 壁時計）——hour 序数（ordinalIn(hour, day, t)＝正確には紀元整列 hour 窓の日内序数）と窓単位 shift(unit: hour) は経過時間側で、壁時計と一致するのは紀元（1970・在圏 tz）以降のオフセット改定がすべて 1 時間の整数倍の tz に限る（DST 切替日に割れる実測: NY 2026-03-08 で shift(+9, unit: hour) が 10:00 に着地。非整数時間改定の Asia/Kathmandu〈1986 に +05:30→+05:45〉では hour 窓自体が :15 整列になり壁時計とも日開始経過とも一致しない——実測）。壁時計は市民時幅の歩進（strideBy(1d, from: …T09:00)・規定済み）か時刻付き anchor grid（F81）。営業時間は壁時計概念なのに、既存の正準例（ADR-38 判断 8・reference/coincides.md の毎営業日 9 時）は経過側——ただし bizDay 形では米国式「日曜切替＋土日週末」だと切替日が常に非営業日で顕在化せず、顕在化は切替日が営業日に落ちる tz・週末構成 |
06 §6.1 | |
| F77 | 帯構築の定型は糖衣候補——開閉の壁時計 tick → segmentBy 帯 → 証人判定 coincides(openTick, band, t) の三段は、意図（営業時間 9:00–17:00）に対して器の組み立てが長い。表現力は足りる（06 §6.3）ので、畳むなら糖衣の器（F1）で意味論不変。器にはマーカー交互性の検査（F84）を含める材料あり |
06 §6.3 | 宿題［追加拡張・糖衣］——except 級と同じく頻出確認後。追記（2026-07-13・発報層還流第一次）: 日内時刻オフセットの同型定型がジョブ 3 種で既に 3 出現（strideBy 形・毎正時 filter 形・snapTo＋shift 形＝いずれも書けた）。頻度カウントは第二次報告で継続。追記（2026-07-24・発報層還流第二次第一期）: 運用期（07-13〜07-23）の新規 0＝糖衣需要は実装期に集中する頻度分布の観測（適用検討 05・非公開）——頻出判定は「書く回数」でなく実装局面の密度で読む材料。追記（2026-07-24・設計者裁定）: 見送りで閉じた（1.0 前の完結——頻度待ちでは自然に閉じない構造のため。再開条件＝1.0 後の新規実装局面で同型が再頻出したら需要駆動で。台帳のカウント受領は継続） |
| F78 | 壁時計の時刻値射影（clockHour(t) 級）が無い——「9 時から 17 時」を述語一発で書く直感形は書けず、tick の和か帯の構築が要る。壁時計 tick（strideBy 形）で代替できるため必須ではないが、導入するなら射影一族（ADR-30 の骨格）。ただし「tz 相対の値」を値式に持ち込む新面（どの premise の tz で読むかの統治）を開く |
06 §6.1 | 宿題［追加拡張・保留寄り］——必要が実例で立つまで見送り |
| F79 | 細粒度束縛の置き場所の作法が未確定——06 §6.3 は営業時間の「規則」（開閉の壁時計 tick・帯＝strideBy 形なら利用側 premise の普通の束縛）と「例外データ」（halfDayCloses＝実体）の二層で書けた。ただし時刻付き anchor grid で書くと営業定数が暦法定義 premise に混入する（grid は暦法定義者の語——reference/grid.md）——形の選択が置き場所を変える。分担の規約が無く、実体側に開閉時刻も持たせて供給規約を指名するなら bizHour 級の標準導出（ADR-35 判断 3 の細粒度版）が立てられ、指名しないなら作法（解説層）に留まる——F67 の残る裁定の本体 |
06 §6.3 | |
| F80 | impl 制約の定量（有界実体化と defCache）——hour \|> first は hour 窓の全実体化（1970〜・約 49 万窓）で例 1 本 12〜22 秒、everyInstant \|> strideBy(1h, from:) は from: 以降のみで 1 秒級（from: がグリッド上なら同じ点列——紀元以降に非整数時間のオフセット改定がある tz では乗らず別点列）。本体層の束縛は defCache されず、値述語から参照されると点ごとに再評価される（同一例で premise 束縛 1 秒 → 本体層束縛 50 秒）。doctest の hour 級の例は strideBy 形＋premise 束縛で書く運用（ADR-36 判断 8「1h 級まで」の定量） |
06 §6.2/6.3 | impl/README に追記（本体層束縛のメモ化は impl の改善候補・仕様の乖離ではない）。追記（2026-07-13・発報層還流第一次 §3-3 への回答）: 実体化起点を評価窓起点へ寄せる最適化は仕様適合——実体化範囲は言語概念でなく（ADR-37 判断 8）・位相は anchor/紀元から剰余算術で復元でき（ADR-31）・観測基準は spec §7.8 の決定性＋註釈/被覆サマリの同一性。市民幅は tz 射影で境界計算（本行の「別点列」の罠と同根）・後ろ向き演算の需要は遡り実体化で満たす（正本＝適用検討 03〈非公開〉の受領処置節） |
| F81 | 時刻付き anchor: の市民グリッドの窓境界定義が spec 未規定——ADR-31 が規定するのは幅ごとの既定整列と anchor: の上書き口まで。時刻付き anchor（chronos grid 1d anchor: 2026-01-01T09:00）の窓境界「各市民日開始＋壁時計オフセット」（壁時計保存・DST 隙間は最初の瞬間へ）は現状 impl の確定挙動（impl/README「残る近似」）のみ。「経過時間タイル」という別読みは幅規約（1d＝市民日・ADR-11/12）が既に排除しているので二読みが開いているわけではなく、壁時計 tick 自体は strideBy（規定済み）で書ける——「要石」ではない。ただし spec §4.5 が strideBy(w, from: p) 由来を「anchor 付きグリッド」と整列同一視する以上、目盛り幾何の明文規定（多日幅＋時刻 anchor・隙間着地の細目も同じ穴）は F67 の確定と併せて要る |
06 §6.1 | 規定事項——ADR-31 改訂か F67 の ADR で（06 の doctest が実行検証を先に固定済み） |
| F82 | 窓リーダーの覆域検査の欠落（impl 欠陥・critical→修正済み）——合成マーカー（openTick \| closeTick 級）の帯は、片成分の covering が尽きた側では生き残った成分だけから窓が張られ「黙って 24 時間帯」になるのに、coincides（と ordinalIn・epochOrdinal・ラベル射影）は S の註釈しか見ず窓列自身の註釈区間（マーカー覆域の補集合＝ADR-37 判断 4 の実効被覆域）を照会していなかった——覆域外で確信付きの誤答（規範「過小近似は不可」違反）。敵対的検証の実行で発見 |
06 検証（敵対） | 修正済み: 窓リーダー共通の覆域検査 winCovOrOut を 4 サイトに追加（覆域外に張られた窓の読みは証人・序数の判定以前に範囲外＝filter は落として註釈）。回帰テスト追加（coincides.test.ts）・266→272 テスト |
| F83 | shift(unit: 市民窓語) の窓内オフセット保存の定義が spec 未規定（F81 の姉妹穴）——reference/shift.md の「窓内のオフセット（時刻）は保存される」は DST 切替日の実挙動と食い違う: 実測（NY）で [2026-03-07T09:00] \|> shift(+1, unit: day) → 3/8 10:00（経過オフセット保存＝壁時計は非保存）、[2026-03-07T23:30] \|> shift(+1, unit: day) → 3/9 00:30（オフセットが 23 時間日の窓幅を超え、着地が +1 窓の外＝「属する窓の添字を動かす」も破れる）。spec §4 は「U 単位で n だけ動かす」のみでオフセット規則を持たない |
06 検証（仕様整合） | 規定事項——F81 と同時に（経過か壁時計か・窓幅超過時の挙動。reference/shift.md の「（時刻）」の字面も規定後に修正） |
| F84 | 帯マーカーの順序前提の黙った破れ——帯の器は「開 < 閉が同一市民日で交互」を検査しない。半日休の引けが開場以前（8:30）・開場と同時刻（9:00）・翌日深夜（翌 2:00 のつもり）だと当該帯が黙って開→翌開の 24 時間帯に化け、翌日 0:00–8:00 まで営業として流出（エラー・註釈ゼロ＝ADR-16 の「黙って違う結果」。実測 3 態）。証人パターンの頑健さは「どの窓が営業側か」まで——窓割り自体の妥当性は守らない | 06 検証（敵対） | 06 §6.3 の落とし穴に明記済み。糖衣・標準導出（F77/F79）の器にマーカー交互性検査を含める材料 |
| F85 | 日を跨ぐ帯の営業日帰属——深夜営業（開 22:00・閉 03:00）で coincides(bizDay, day, t) は「t の属する暦日」で判定し両側で誤る（金曜夜の尾部＝土曜 0:00–2:00 が落ち、日曜夜の尾部＝月曜 0:00–2:00 が混入。DST 無関係・東京でも実測）。意図は「セッションの開始日の営業日性」。修理形は証人パターンの二段掛け——bizOpenTick = openTick \|> filter(coincides(bizDay, day, ·)) を証人にする（06 §6.4 で実行検証・doctest 化） |
06 検証（敵対） | 06 §6.4 に修理形ごと明記済み（糖衣を立てるなら既定の帰属をどちらにするかが F79 の裁定材料） |
F67 本体の候補設計（draft §1.24）の検証で出た綻び（F86〜F92・2026-07-08〜09。F92 は ADR-41 実装期の追記）
候補設計（供給規約 opens/closes・標準導出 bizOpen/bizClose/isOpen・ADR-31 改訂候補）の 4 視点 検証（整合性・コーパス掃引・実装可能性・敵対的、指摘 39 件）で出た。F86〜F89 は当初案の構造欠陥 （§1.24 に修正済み・F71〜F74 と同じ記録扱い）、F90/F91 は宿題。
| # | 綻び | 初出 | 処置 |
|---|---|---|---|
| F86 | 整合性検査の当初形（「open 始まりの厳密交互・実体化範囲上」）が破綻——(i) 両無限の規則列に「先頭」は定義不能、(ii) 深夜営業（開 22:00・閉翌 03:00）は任意の範囲頭がセッション中に落ち必ず close 始まり＝偽エラー、(iii) 和 opens \| closes は点集合の併合で同時刻対が観測不能（検査が自分の禁止対象を見えない）、(iv) 覆域制限なしでは例外データの covering が尽きた側の「落ちて註釈」が open, open, … に見え正当な実体が止まる、(v) マーカー位置はデータ・tz 依存で「静的」の層（ADR-36）に置けない |
§1.24 検証 | 解消（§1.24 修正）: 局所交互（各マーカーの直前は逆種）＋定義域＝結合実効被覆域∩実体化範囲＋端の孤立 close/open は切り欠き合法＋検査・相殺は対のストリーム上＋データ相対の層（ADR-33 判断 9）＋同時刻 open/close 対は相殺（接するセッションの融合と DST 縮退の救済を兼ねる） |
| F87 | F81 の裁定根拠「impl の現行挙動と一致」が偽——impl は anchor の日内オフセットを経過 ms（anchor − 日開始）で計算しており、anchor が DST 切替日に落ちると全目盛りが壁時計からずれる（実測: NY anchor: 2026-03-08T09:00 → 全日 08:00 発火・グリッドが anchor 自身を通らない・同壁時計の 2 本の grid が整列不一致エラー）。strideBy の時刻付き from: も同経路 |
§1.24 検証（impl） | ADR-31 改訂はこの挙動の修正を含むと明記（壁時計＝ラベル読み。通常日 anchor は不変）。impl 修正は ADR 確定後（eval.ts の off 計算をラベル基準へ） |
| F88 | F83 候補 (b)（市民オフセット保存）の構造難——(i) 秋戻しの重複ラベル（01:00 EDT / 01:00 EST＝chronos 別点）が同一着地へ併合（点集合として黙って消える・順序反転）＝ADR-40 が時刻保存 rebase を将来拡張へ送った理由と同根（単射・順序保存の喪失）、(ii) 往復可逆性（+n→−n 恒等）を失う、(iii) 真夜中遷移 tz（America/Santiago 級＝日開始 01:00 の日）で窓開始点の着地が日開始でなくなり day 整列が壊れる（ADR-36 の「& の黙った空振り」再導入・救済特例で規則が複合化） | §1.24 検証 | 推奨を (a) 経過オフセット保存の明文化へ反転（壁時計の用途は F67 導出＋F81 tick が引き受ける・shift は単射/順序/往復を守る）。裁定へ |
| F89 | 標準導出の当初案（利用側 bizDay 経由）はクロス tz の自然な問いを塞ぐ——「いま TSE は開いているか」は chronos 述語として tz 非依存に定まるのに、利用側の day 経由だと tz 検査で全滅 | §1.24 検証（敵対） | 解消（§1.24 修正）: bizOpen/bizClose/isOpen は実体相対（C の内側＝C.everyDay \ C.nonWorking・C-tz で解決）。bizDay（利用側相対）との非対称は glossary で明示 |
| F90 | セッションの営業日帰属のノブが無い——既定は「開場日（実体 tz）」固定。CME Globex 級の「トレード日帰属」（日曜 17:00 開場＝月曜取引日）はこの既定と食い違う。実体側の供給合成で書けるため直ちには困らない | §1.24 検証（敵対） | 宿題［追加拡張・需要待ち］——帰属ノブは実例が立ってから |
| F91 | premise 束縛の右辺の複数行継続の構文が無い——opens/closes の右辺（成分の和＋濾過）は一行が長大になるが、行頭 \| の継続は構文エラー。§1.3「前文は一行にこだわらない」と実挙動が食い違う |
§1.24 検証（コーパス） | 確定（ADR-44・2026-07-09）: 区切りは改行・継続は (1) 括弧内の自由改行と (2) 行末/行頭の \|>・結合子（文は結合子で始まれないため一義）。継続記号・インデント法は却下 |
| F92 | opens/closes の対で実体化の頭が揃わない規則供給の交互性誤エラー——片方が strideBy(from: 2026…)・片方が grid（紀元から）だと、註釈のない「from: 以前のマーカー不在」区間が検査の定義域に入り、交互性検査が誤エラーを出しうる（規則枝の実効被覆域と strideBy の from: 以前の関係が未規定） |
ADR-41 実装 | 明文化済み（2026-07-09）: 供給の作法（対は実体化の頭を揃える——両方 grid か、両方 strideBy の from: を同日に）を reference/isOpen.md の落とし穴に追記。規定は実例が立ってから（据え置き） |
ADR-41/ADR-31 改訂 2 の実装検証（2026-07-09・299 テスト全通過）で追加確定: 市民日開始点の anchor は日整列と読む特例（ADR-31 改訂 2 に明文化）・往復可逆の但し書き（窓幅超過点では破れる・ 同）・幅 0 セッションの open は bizOpen に残る（isOpen・bizClose には現れない）・最初のマーカー 以前は「閉」で確定・尾の孤立 open は実体化端まで「開」。
裁定後の反映先——全件消化済み（2026-07-09・ADR-41/ADR-31 改訂 2 の確定と同時に反映。 isOpen.md 新設・coincides.md 正準例差し替え・shift.md 経過保存の明文・grid.md 壁時計 anchor と 第二の書き手・nonWorking.md 細粒度参照・impl/README 昇格）。旧リスト: F76 裁定時＝reference/coincides.md の 2 例と ADR-38 判断 8 の正準例（但し書き or 差し替え）・ reference/shift.md:「（時刻）」の但し書き（F83 の規定と同時）。F81/F83 規定時＝reference/grid.md の anchor: 節・reference/shift.md・impl/README「残る近似」からの昇格。F77 裁定時＝ reference/segmentBy.md に帯＋証人パターンの例。F79 裁定時＝reference/nonWorking.md の 「細粒度軸は F67・宿題」の注記更新。F82 は確定済み規範の帰結のため reference/coincides.md の 落とし穴に追補済み。
F64＋F9 本体の候補設計（draft §1.25）の検証で出た綻び（F93〜F97・2026-07-09）
検証（整合性＋コーパス全数掃引・敵対的・実装可能性の 3 視点、指摘計約 40 件）で出た。F93〜F95 は 当初案の構造欠陥で ADR-42 の確定前に修正済み。
| # | 綻び | 初出 | 処置 |
|---|---|---|---|
| F93 | 「W の要素点列」の当初定義（原子グリッドの目盛り）が segmentBy 窓で立たない——未 snap マーカーの窓（ティティ級）は整列 G＝「なし」で未定義・濾過入力（mondays \|> segmentBy(…) 型）では窓の実要素でない点が混入する（「要素点列」の字面と矛盾・黙って違う結果のクラス） |
§1.25 検証 | 解消（§1.25 修正→ADR-42 判断 2）: 要素点列＝「定義が窓に束ねた入力点列の窓所属」に再定義（grid/span/split 連鎖では原子グリッド目盛りと同値・segmentBy では入力点。整列は入力整列の filter 保存継承） |
| F94 | 「窓列→要素点列」の輸送行の欠け——マーカー覆域の外は要素点そのものが無く filter が一度も走らないため註釈の湧き口が消え、kyuMonth("六月") が covering の先で註釈なしの空になる（F61 と同型の黙った退化。「新機構ゼロ」は註釈体系の観点では過大主張だった） |
§1.25 検証 | 解消（ADR-42 判断 3）: 輸送行を一行新設——出力の註釈区間＝窓列の実効被覆域の補集合（segmentBy 行の継承・F82 の 4 サイトに続く第 5 の窓リーダーサイト） |
| F95 | dispatch の根拠「ラムダ変数＝点型」が偽——span のラムダは窓序数・値関数のラムダは数値を束縛し、自由なラッパ f = v => year(v) は定義体単独で引数型が決まらない（ADR-25 はラムダの型規則を持たない） |
§1.25 検証 | 解消（ADR-42 判断 4・設計者裁定）: 判定時点＝糖衣展開後・実引数束縛後（ADR-36 が整列を計算する時点と同じ）。ラッパは呼び出しごとに型確定＝多相許容。「型不定束縛は静的エラー」案は型推論の新機構が要るため却下 |
| F96 | Fiscal の year 上書きがラベルを継承せず、shiftBoundary 形との等価主張が観測可能に破れる——上書きは label: を継承しない（定義の一部）が、shiftBoundary は base の label: を保存する（F65）ため、「year 一行と同じ展開」と宣言された二形が year(2020)/year(d) の合法性で割れる |
§1.25 検証 | 解消（ADR-42 判断 6）: Gregorian への標準ラベル付与と同時に Fiscal の year 上書き行にも付与（fiscal 解説 §5 の字面を §1 正式定義へ昇格）。「上書きはラベルを継承しない」を統治として明文化 |
| F97 | 日付リテラルの裸の値束縛（d0 = 2026-05-15）の型が未規定——EBNF の値式 atom は date-literal を含む（anchor:/from: が値式経由で受けるため）が、三型体系に点の値スロットは無く、dispatch 表の「値変数→インスタンス参照」が「点は値束縛できない」というどこにも書かれていない前提に乗っている |
§1.25 検証 | 確定（ADR-43・2026-07-09）: 裸の値束縛を正式に認める——時点は値型の一員（型は増えない・内訳の明文化）・ADR-42 の dispatch 表は「点→射影・点以外の値→インスタンス参照」に精密化 |
裁定後の反映先——ADR-42 の帰結節が正本（spec §2 新設小節・§4.9 双対・EBNF stream-atom 修飾 適用・glossary 2 項・stdlib 字面・reference 分岐案内 5 点・impl）。反映は後続の同期 タスク（INDEX 参照）。
発報層の実装還流（第一次）で出た綻び（F98〜F99・2026-07-13〜14）
分業モデル（適用検討 01 裁定 §9・非公開）の還流ルートの初便（受領収蔵＝適用検討 03・非公開）。 実装期に確定した知見のうち新綻びは 1 件——ほかは注記提案 1 件（reference/table-literal.md に 反映済み）・F77 の初期観察（行に追記）・F80 連動の仕様照会（行に回答を追記）。F99 は F98 の 候補設計検証（3 視点）の副産物＝既存 impl 欠陥。
| # | 綻び | 初出 | 処置 |
|---|---|---|---|
| F98 | 「点ゼロだが覆域は主張したい」束縛の一次形が無い——空リストはテーブルに昇格せず [] covering: .. は静的エラー（labels:/covering: は時点列にのみ付く）。回避形＝恒偽 filter への束縛後置の被覆主張 (everyDay \|> filter(d => 1 == 2)) covering: …（ADR-37 判断 5）は意図どおり動く（点ゼロ・runway 即負の運用信号）が、恒偽が迂遠で読み手に意図が伝わらない。データ供給層の「まだ何も無い」は発報層の定常状態（初回 boot・年替わり）で、ソース生成器の行ゼロ分岐の源 |
適用検討 03 §1-1（非公開） | 確定（ADR-45・2026-07-14）: 空テーブルリテラル [] covering: … の合法化（covering 明示必須・labels: [] のみ合法・各検査は空虚に成立・整列は空虚適合の第三状態＝ADR-36 改訂 3）。候補設計 draft §1.26＝3 視点検証（致命 0・要修正 7 反映）。impl 実装・掃引テスト 23 本・doctest 例（reference/table-literal.md） |
| F99 | roll 空軸の依存像が過小近似——rollImageAnn/dependImageAnn の空軸 early return が「覆域端の註釈帯を直前/直後の既知軸点まで拡張」（ADR-37 判断 4 roll 行）を丸ごとスキップし、有限 covering の空軸への roll で覆域内の入力点が点も註釈も無しに落ちていた（開端 covering と観測不能に縮退＝「範囲外は未知」と「無いことは知識」の区別が消える。回避形でも再現する既存欠陥で、F98 合法化が常用形に昇格させるため先行修正） |
draft §1.26 検証（敵対） | 解消（2026-07-14）: dependImageAnn の early return を削除（一般則が空軸を正しく処理＝既知軸点が無ければ帯は ±∞ へ・開端は拡張対象なしで「註釈なしの空」保存）。rollImageAnn 側の early return は健全と確認し維持（未知軸点への着地依存は依存像の担当）。回帰テスト＝empty-table.test.ts の F99 節 |
業務定型 25 種の記述可否還流で出た綻び（F100〜F103・2026-07-15）
還流ルートの第 3 便（受領収蔵＝適用検討 04・非公開）。日本の B2B 業務定型 25 種を実装系アプリ側の
評価器（公開 HEAD 29585ef 追随・2026 実祝日フィクスチャ）で 1 件ずつ実評価した記述可否報告——
21/25 は現行言語で記述可能（うち 9 種は挙動固定テスト付きでアプリの標準カタログに登録＝
40-examples の判定マトリクスを実務定型で外部再検証した形）。残る 4 種が下記——受領翌日の実測
検証で 4 件中 3 件（F100/F102/F103）は既存語彙で記述可能と判明（報告側の語彙認識ギャップ＝
発見性の問題として reference に doctest を追補・設計者裁定 2026-07-15＝回答で閉じる）。F101 のみ
stdlib へ糖衣を同梱。付随の仕様確認（roll(on:) の匿名軸）は保証——named-arg は stream-expr を
受け（§5.6）導出ストリームは軸と同型（F7）＝reference/roll.md に doctest 化。
| # | 綻び | 初出 | 処置 |
|---|---|---|---|
| F100 | calendar 実体のメンバー（holidays/nonWorking）を本体式から参照できない——祝前日リマインド holidays \|> shift(-1, unit: day) が 未解決の名前（premise 相対解決）。データは実体としてそこに在るのに消費者式から読めない。「祝日の前日に締めを前倒す」「連休前の在庫確認」は総務・物流の定番＝業務価値高。候補: ①calendar 在圏で bizDay 同様に holidays/nonWorking を言語予約の導出名として公開（ADR-35 の対称拡張・最小）②calendarOf(...) 級アクセサ |
適用検討 04 G1（非公開） | 回答で確定（2026-07-15）: 既存語彙で記述可——修飾参照 Cal.holidays \|> shift(-1, unit: day)（ADR-17「曖昧なら修飾」・実測一致）。裸名の自動公開はしない（premise 相対解決＝設計どおり・衝突規約が不要）。doctest 追補＝reference/nonWorking.md |
| F101 | 点から月長（daysInMonth）を引けない——daysInMonth は月序数引数で点を渡せず、「月の後半のみ」が dayNo(d) > 15 の近似になる（28〜31 日月で意味がずれる）。候補: 点引数の stdlib 糖衣 daysInMonthOf = d => daysInMonth(epochOrdinal(month, d))——yearNo/monthNo/dayNo と同じ §4.9 糖衣ファミリの欠落に見える |
適用検討 04 G2（非公開） | 確定（2026-07-15・設計者裁定＝stdlib 同梱）: daysInMonthOf = d => daysInMonth(epochOrdinal(month, d)) を Gregorian に追加（§4.9 糖衣ファミリの対称完成）。doctest 追補＝stdlib/gregorian.md |
| F102 | 「窓内の第 N 要素」の直接選択がない——ordinalIn の軸は窓系のみ（派生ストリーム不可）・segmentBy は empties: に skip がなく窓端の空窓で落ちる。回避形 monthStart \|> roll(Following, on: bizDay) \|> shift(+N-1, unit: bizDay) は動くが「営業日 N 日未満の月」の縁ケース保証が filter 型と違い自明でない。「第 N 営業日」「第 2 月曜（ハッピーマンデー）」は日本の制度日程の基本語彙＝業務価値高。候補: ①nth(N, in: month) 級の選択子②segmentBy の empties: skip 追加＋first/last 合成。F11（nth の複数序数）と隣接 |
適用検討 04 G3（非公開） | 回答で確定（2026-07-15）: 既存語彙で記述可——正準形 within＋nth bizDay \|> within(month) \|> nth(2)（営業日 N 日未満の月は正当な空＝I15・filter 型と同じ縁ケース保証。実測一致）。専用選択子・empties: skip は不要。F11（複数序数）は独立の宿題のまま。doctest 追補＝reference/nth.md |
| F103 | 特定日起点の隔週（bi-weekly anchored）が書けない——現行最善 week \|> filter(w => ordinalIn(week, year, w) mod 2 == 0) は年アンカーの偶奇＝年の週数（52/53）で年跨ぎ位相が反転し得る。「2026-01-05 起点の隔週」の指定は不可。月 2 回型（第 2・第 4 水曜）で代替されがち＝優先度は F100/F102 より下。候補: cycle の anchor:（weekday が既に持つ構文）を週より粗い周期へ一般化 |
適用検討 04 G4（非公開） | 回答で確定（2026-07-15）: 既存語彙で記述可——stride(2, from: 特定日)（位相は from: が持つ＝ADR-31/38。年跨ぎ位相反転なし・実測一致）。anchor 一般化は不要。doctest 追補＝reference/stride.md |
| F104 | テーブルリテラルで labels: の後に書いた covering: が黙って捨てられる——labels: の値リストを後置つきでパースするため、後続の covering: が「ラベルリストの後置」として内側に付き誰にも読まれない（覆域は既定〈列の端〉に落ちる無検査受理）。EBNF の固定順（covering→labels）の外の書き方が黙殺される＝ADR-39「黙殺の封止」方針と同型の穴。第 5 便 §2 の最小再現形も実はこの穴を踏んでいた（既定と同値のため観測不能だった） |
発報層還流 第 5 便 §2（適用検討 06）の調査で検出 | 確定（2026-07-25・設計者裁定＝順序自由化）: 後置は順序自由・各一回（二重指定は構文エラー）。labels: の値は後置なしでパースし外側で受ける。EBNF を { covering \| labels } 形へ改訂（RC5 追補 9・受理拡大＝意味不変）。テスト table-postfix.test.ts |
| F105 | segmentBy 窓列の labels 射影が「覆域内・窓なし」の頭側で硬エラーになり filter 正準形が評価不能——edges: drop/error で覆域始端 < 最初のマーカーの構成（filter 派生マーカーの典型）では、頭側 [覆域始端..最初のマーカー) が「実効被覆域内だが窓がない」。filter は実体化範囲全域の点を述語評価するため必ず頭側を踏み、分類器の「被覆域内＝硬エラー」で ラベル射影: 点が窓の外 に落ちる（第 5 便 §2 のバグ疑い＝実測どおり・当時実装は ADR-37 判断 4 に忠実） |
発報層還流 第 5 便 §2（適用検討 06） | 確定（2026-07-25・設計者裁定＝覆域の精密化）: 窓列の実効被覆域は「窓の張られた範囲」——窓のない区間（頭側・empties: drop の中抜け）は窓列由来の註釈とし「落として註釈」で応える（ADR-37 改訂 3・F72 の頭側対称・緩和方向のみで正常系不変）。テスト window-labels.test.ts |
補完機構への写像（フェーズ 3 の設計対象）
綻びは三群＋周辺に集約される。
群 1: データの持ち込み口 → draft §1.15 → ADR-26
F5・F6・F7・F10・F12・F13・F19・F22・F25。 テーブルリテラル（時点リスト→ストリーム定数）を核に、出所（source:）・版（asof:）・有効範囲・ 「事故の空」（ADR-15）との接続、層またぎ規則（premise 束縛の右辺に書けるもの）、カレンダー実体の 登録までを一節で設計する。外部供給宣言（socket）は方向提示に留める（設計者決定）。
群 2: 窓→値の射影一族 → draft §1.17 → ADR-27
F2・F17・F18・F21・F23・F28・F32・F33。 「点の属する窓」を経由する値の読み書き——窓内序数（ordinalIn）・窓ラベル（読み/付与）・窓境界点 （snap）・点の暦座標（yearNo/monthNo/dayNo）。六曜・旧暦月名・ISO 週番号・年度ラベル・イースター・ 固定日祝日が全てここに還元される。選択子（窓→点）の双対（窓→値）として一族で設計する。 実データ照合（NAOJ 令和8年暦要項）で群 2 が補強された: 節気を「立春」という意味的位置で選ぶには 点→節気名/黄経の射影（labelOf）と、時点だけでなくラベルを持つデータ（テーブルリテラルの拡張）が要る （F32/F33）。時点のみの列では「暦年で最初の節気」＝小寒しか序数で取れず、立春を選べない。
射影一族の綻び出し（04-projections.md）で群 2 の内部設計が六点に絞れた（F34〜F42）: 暦座標
（yearNo/monthNo/dayNo）は epochOrdinal＋ordinalIn＋既存値関数の糖衣で導ける（新規語は二つで足りる）
一方、(a) ordinalIn/epochOrdinal の引数（数える対象と枠。二窓引数への一本化 F34）、(b) 射影値の入力
粒度依存（F35/F42）、(c) labelOf のラベル源三分類（cycle／label:／暦座標。F36）、(d) label: 付与式の
表現力（隣接窓は射程外 F37、別点の窓参照 ISO 週/年度は要設計 F40）、(e) ラベル付きテーブルリテラル
（ADR-26 拡張。F38/F39）、(f) snapTo の糖衣化（F41）——が次段の設計対象。labelOf と label: が本体で、
そこが未決だと六曜月名・ISO 週番号・年度ラベル・節気名が書けない。
群 3: cycle の一般化の確定 → draft §1.16 → ADR-27 に同居（または個別 ADR）
F3・F4・F15・F30・F31。
周期長任意・適用先任意（単位窓以外も可）・anchor の窓解釈・ラベルの述語参照（束縛名の値関数読み）・
派生との相互作用（Base. ピン）。検証で全て機能したので、暫定→確定への格上げが主。設計中に week 窓と
nextWeekday も決着（§1.16 補）: week は segmentBy＋wkst 遅延解決で専用生成語不要、nextWeekday は
同週選択の欠陥（F31）を廃して前方 roll に再定義、selectWeekday は廃語。
周辺（字句・値式の追補） → draft §1.18 → ADR-28
F14（非 ASCII ラベル）・F20（in）・F29（値束縛の置き場）＋日付/幅リテラルの字句確定（§1.14 から昇格）。
宿題送り（RC を止めない）
F1（標準糖衣）・F8（振替の再帰=射程外明記）・F9（窓インスタンス参照）・F11（nth 複数序数）・ F16（cycle の積）・F24（隣接窓参照=射程外明記）・F26（範囲 shift）。→ 90-open-questions に転記。