ADR-40: 日付ラベル保存の再錨（rebase・仮称）と免除系の tz 検査

判断: クロス tz の「同じ日付」合成（F69）の受け皿を次のとおり確定する（draft §1.23 の候補設計＝検証 1 視点（発見 8 件）・設計者裁定（2026-07-08）を経た ADR 化）。

受け皿は点変換の第 4 メンバー rebase(to: "tz")（仮称）——roll/shift/snapTo に並ぶ。各点（source tz の市民日の先頭点）の日付ラベルを取り、to tz の同日付の市民日の先頭点へ写す。着地は「その日付になる最初の瞬間」（ADR-33 判断 4 の既定規則——DST の隙間に真夜中が落ちる日も定義済み）。日付順は tz に依らず同順なので単射・順序保存（I7 オンライン）。共通営業日は (tseBiz |> rebase(to: "America/New_York")) & nyseBiz——rebase がラベル対応の再整列を宣言し & は既存の等値のまま。ADR-36 の整合手段が二本になる: snapTo＝chronos 所属（同じ瞬間を含む窓）・rebase＝ラベル対応（同じ日付）——どちらの意図かが字面で立つ（分岐案内に三本目の枝）。
day 固定（w 引数を取らない・検証の帰結）: month/year への一般化は同窓の全点が同一点へ潰れる多対一で単射性が破れ、「市民ラベルを持つ窓」は導出構造で判定不能（会計暦の phase ずらし month が系譜判定を素通り・ISO 週の W ラベルは tz 写像の座標成分でない）。市民ラベル＝tz 写像の座標成分（Y-M-D）に直結する day だけが健全に定義できる。一般化は実例が出たら単射性の主張ごと再設計。
存在しない日付は明示エラー（データ相対＝ADR-33 判断 9 の層）: 日付変更線の移動で丸ごと消えた日（Pacific/Apia 2011-12-30 等）への再錨。「全 tz に全日付が在る」は tzdb 上偽（検証で発見）。
入力は既定整列の day グリッド（G＝幅 1d・日内オフセット 0・tz 名つき）を要求——それ以外（整列なし・anchor つき・時刻オフセットつき市民 G）は静的エラー。時刻保存の再錨は DST の隙間・重複で ADR-33 リテラル規則と同じ穴を踏むため将来拡張——時刻つきクロス tz の絞りは rebase＋同 tz 化後の coincides の合成で書ける（表現力の穴は無い・検証で確認）。
出力整列は to tz の day グリッド（構成的・ADR-36 の整列表に行を追加）。source == to は恒等。 to: の統治: to: は文字列リテラル。tz は版付き写像（ADR-33）——rebase は写像を二つ（source＝整列から・to＝名指し）参照する変換で、版・隙間規則は在圏の評価文脈に従う。to: は評価文脈の供給でなく変換の対象座標系の名指し（shift の n と同じ引数の層）——I6 と衝突しない。
免除系の tz 検査を同時に拡張（ADR-36 判断 7 の改訂 2）: rebase はクロス tz 整列のストリームを常態化させる——to tz グリッドの出力を在圏 premise の within(month)・ordinalIn・選択子・ cycle/値射影（weekday(d)）に流すと、免除系は tz を見ずラベル 1 日ずれの束ね・曜日読みが黙って通る（東京 3/1 の日先頭は NY premise の within(month) で 2 月窓へ・weekday は前日を返す）。 市民グリッド入力 × 窓要素グリッドの tz 名検査を免除系へ拡張する（snapTo は chronos 所属が文書化済みの意味なので除外。ADR-38 判断 5 の根拠「tz は日付座標系そのもの」の一般化——既存の潜在穴でもあり、rebase 導入と同時に塞ぐ）。
註釈の輸送: 端点を source の day 窓へ floor/ceil で膨らませてからラベル対応で写す（過大近似許容——端点は任意の chronos 位置で day 先頭とは限らない。ADR-37 輸送表に行を追加）。規範: shift/roll は rebase の前段で（rebase 後の窓語 unit は在圏解決で整列が乱れる—— 分岐案内・reference に一行）。I8: tz は暦法・カレンダーと独立の射影パラメータ——点変換ファミリーの位置で整合（ADR-21 の「同じ点変換族・各段が自足」に適合）。

背景: ADR-36 帰結が F69 として送った「クロス tz の同じ日付ラベルの合成は chronos 等値で原理的に書けない」（snapTo は chronos 重なりの意味で東京の日先頭が NY の前日に floor される・coincides の tz 検査〈ADR-38 判断 5〉も正しく止める側）。impl の多 TZ 対応（ADR-33 の premise 相対 TZ・DST）と同時に確定した。

却下した案:

結合子の日付等値モード（記号三役違反・ADR-38 と同根）。
日付ラベルの値化＋述語（三重突合は冗長・突合相手側の探索が述語では書けない）。
snapTo の tz 引数拡張: chronos 所属とラベル対応は意味の違う演算——同名は取り違え面（ADR-16）。
premise 側で解く: 一つの premise に二つの日界は立たない（ADR-33）。
to: に premise 名: premise は暦法・カレンダーも束ねる——tz だけの名指しに使うと「何に合わせたか」の取り違え面。tz 文字列が正。

帰結:

spec: §4.4（点変換に rebase 追加・分岐案内の三本目）・§4.5（整列表に rebase 行・免除系の tz 名検査）・§4.10（輸送表に rebase 行）・glossary。仮称は四語に（shiftBoundary・nonWorking・ coincides・rebase——relabel・sameDate を比較候補に記録）。
ADR-36 判断 7 に改訂 2（免除系の tz 名検査）。
リファレンス実装: rebase（day 整列検査・最初の瞬間・非存在日付エラー・恒等最適化）・免除系の tz 名検査・輸送行。多 TZ 実装（ADR-33 の実行検証）が前提。
90-open-questions: F69 解消。時刻保存 rebase・w 一般化を将来候補に記録。

改訂（2026-07-09・純命名の確定＝F51）

点変換 rebase を正式名に確定（仮称解除・設計者裁定。帰結の比較候補 relabel/sameDate は不採用——ラベルは保存され変わるのは錨なので relabel は逆・sameDate は述語に見える）。正本は spec §5.4。