日本語 · English（未訳）

1.0 宣言の条件（DoD）と宣言時作業

決定（2026-07-24）: 1.0 宣言の条件は下記「宣言条件」の 5 項——運用信号の初実発火と external の実運用を見て宣言する（比較 3 案〈全信号の自然発火待ち／信号初発火＋external 実運用／ 早期宣言〉から中間案を選択。時期の目安 2026-11 頃・前倒し検証が成立すれば早まる）。本書がその正本。

前提——すでに揃っている材料（2026-07-24 時点）

仕様側——意味論は固まっている。

• 意味論を変える宿題ゼロ（90-open-questions の分類——全項が ［純命名］［追加拡張］［スコープ外連動］［明文化］のいずれか。RC 以降維持）。
• RC5＋追補 8（ADR-46）まで確定・466 テスト・doctest 既定厳格（#~> 註釈照合込み）。

外部検証——表現力と品質・決定性の実証が揃っている。

• 表現力の外部検証: 40-examples 判定マトリクス（01〜08）・日本の業務定型 25 種の外部再検証 （21/25 が現行語彙で記述可＝還流第 3 便・残り 4 件も 3 件は既存語彙で可と実測）・縁の確認 （月相の三段整理・多段世代バックアップ・注入起点の分業）。
• 品質・決定性の外部実証: 発報層還流＝doctest 写経 50 ブロック全一致・実環境 E2E 一致。
  • 決定性の実運用実証（運用観測台帳第一期＝2026-07-23 の初回本番配信が 10 日前の実体化予告 どおり・予定比 +0.7 秒〈配信を予約した時刻の差＝発火はそれ以前・送信完了はそれより後。2026-10-08 寒露便 §1-1 の訂正〉。日次再実体化 10 日・再起動 2 回を跨いで予定不変）。

宣言条件（DoD）

1. 運用信号の初実発火の観測——残走路（runway）警告の実発火と、誤報・見逃しの有無の実例確認。
   • 経路は二つ: (a) staging の前倒し検証（閾値の一時操作・短い covering フィクスチャ・供給エラー の劣化運転。供給側へ依頼済み＝2026-07-24）、(b) 本番の自然発火（2026-10 中旬の残走路割れ・ 2027-01 の covering 切れ）。
   • 宣言のゲートは (a) で足りる——(b) は宣言後も継続観測として受領。

   ✅ 充足（2026-07-26）——材料＝信号台帳（第 7 便・収蔵 08）。

   • 3 シナリオ全実発火（runway 警告・annotatedNow 交差・SupplyError 劣化運転と復帰）・全て真陽性・誤報なし・ 見逃し側も確認（源単位分離・交差警告の正しい沈黙）。
   • 残走路の基準（評価 to から）は仕様と一致を照合済み。
   • (b) 本番自然発火は宣言後の継続観測として従来どおり受領する。
2. external の実運用（ADR-46 の実地検証）——供給側の乗り換え（第二段）後、少なくとも 1 サイクル（次回データ実取得〜配信）の安定稼働。
   • 見るもの＝供給契約の検査・供給エラーの部分類・一評価一解決の実挙動・生成方式との対比 （「宣言 1 行の価値は写経される統治の量」仮説の検証）。
   • 経過（2026-07-28）: 時期確定＝第 8 便（収蔵 09）——本番反映は 8/7 より前・external 新方式の 初本番配信 2026-08-07（立秋）・「1 サイクル安定稼働」は 8 月下旬に揃う見込み（立秋→処暑の 2 発火・parity PASS×3 と統合 6 本 green の準備状態・台帳第二期で還流予定）。

   ✅ 充足（2026-08-23・第 11 便＝収蔵 14）——1 サイクル完結の実測受領。

   • 立秋→処暑の 2 配信連続成立（処暑は VPS 初・予定比 +0.032 秒〈予約の時刻・同上〉・冪等 1 行・missed-fire 0）。
   • 環境横断の決定性 3 例目（hostname 10 種・ローカル→VPS 正切替跨ぎで next 不変）・冪等キー成分独立の実測 3 例・ 供給スナップショット解決 3 回で劣化運転/SupplyError なし。
   • 実行既定 tz=UTC の VPS でも定義側 tz 明示で無風＝premise 明示の本番実証つき。
   • 残る添付＝一次台帳（貴 §6-3/§6-4）のハイライト検証（次回）——宣言の裁定は設計者（残作業は条件 4・5 の機械的作業）。

   継続観測の材料受領（宣言後も受領を続ける）。

   • 2026-09-07・2026-09-08 定期便＝収蔵 23: at 形（ADR-51）での初の本番配信が白露 9/7 に成立 （予定比 +0.037 秒〈予約の時刻・同上〉・冪等キーで再実行 2 回とも再送なし・horizon-clip 0 件＝機構は演繹的に確認、統計的裏付けは秋分 9/23 以降）。 ADR-53 追随も供給側で 3 段階完了（追記 5）。第 11 便の「処暑当日 4 件」は 3 件へ訂正（当方の宣言材料に影響なし）。
   • 寒露 10/8（2026-10-08 定期便＝収蔵 34）: at 形 3 例目＝予約 +0.060 秒・冪等 1 行・評価警告 0・残走路 396。同便で発報の値の意味の訂正を受領 ——大暑〜秋分の予定比はすべて「配信を予約した時刻」の差で、発火の時刻（それ以前）も送信完了の時刻（それより後）も未記録。立冬 11/7 から両方が記録される。
3. shiftBoundary の命名裁定——最後の仮称（純命名・k 可変組の射程外問題と連動)。
   • 裁定材料の比較表は整理済み＝30-syntax/01-shiftboundary-naming.md （2026-07-24・候補 5 語・確認事項 3 点）。
   • ✅ 充足（2026-07-26・前倒し）——rephase に確定（旧仮称 shiftBoundary）。 全コーパス一括置換・CHANGELOG 追補 11・仮称ゼロ。
   • 宣言時作業 1（正式名への一括置換）もこれで前倒し完了——宣言時に残るのは表記更新・タグ付け・同期のみ。

4. 意味論宿題ゼロの最終再確認——90-open-questions の全項再点検（RC の DoD と同じ手順）。

5. 文書整合の全通過——npm test（doctest・doc-consistency 検査）・公開層ガード。

1.0 をブロックしない項（明示的スコープ外）

すべて意味論不変の分類（［追加拡張］等）で、1.0 後に需要駆動で足せる:

• F11（nth 複数序数）・F16（cycle の積 zip）・F26（範囲 shift の可変幅 fold）・of: の匿名窓 ラベル付け・location: メンバー・sin/cos（見送り寄り）・標準糖衣の整備（onMonthDay 級・F1）
• F78（壁時計の時刻値射影・保留）・F90（帰属ノブ・需要待ち）

判断の済んだ項と射程外の項（同じく意味論不変・1.0 後に需要駆動で足せる）:

• 発火点列への値随伴出力（第 5 便 §4・追認済み＋含み——90-open-questions に記録） （窓列への周期ラベルは ADR-47 で確定・実装済み 2026-07-25＝ブロック要因から消化）
• F77（dailyAt 級糖衣）＝見送り裁定済み（2026-07-24——糖衣需要は実装期に集中する分布と判明し 頻度待ちでは閉じない構造のため裁定で完結。再開は 1.0 後の新規実装局面での再頻出＝需要駆動）
• rephase（旧仮称 shiftBoundary）の k 可変組（射程外・必要になれば別演算子）・DST gap/overlap の解決規約（opt-in premise の将来拡張）・tzdb の版供給（スコープ外連動）

宣言時の作業一覧

1. shiftBoundary の正式名への一括置換 → 前倒し完了（2026-07-26・rephase に裁定＝条件 3・ 全コーパス置換済み・CHANGELOG 追補 11）

2. ✅ 機械化済み（2026-09-04）＝非公開ツール層の宣言スクリプト declare-1.0.mjs（dry-run 既定・--apply で書込）。
   • 一括差し替えの対象＝状態行 5・Playground 注記 2・CHANGELOG「1.0」節・impl/package.json と lock の name/version （アンカー 7/7 実在・残存 RC 表記 0 件を dry-run で確認済み）。
   • RC5 残存検査は doc-consistency に休眠形で新設済み（状態行が「リリース候補」でなくなると自動で起きる・許容リスト 4 ファイル）。
   • 当日は --apply → impl/ で typecheck＋全スイート → コミット。手動は 70-release と設計記録の記述のみ （検定側も同型の follow-1.0.mjs で機械化＝2026-09-04・下記）。

   （旧記述）spec/README の RC5→1.0 表記更新・spec/CHANGELOG に「RC5→1.0」節。

   • 対象は spec だけでなく「RC5」を名乗る全入口——README 英日・llms.txt・en/spec/README・Playground の RC 注記・ 検定側（教本 3 冊/README の「RC5 準拠」表記）を同時更新する。
   • doc-consistency に「RC5」残存検査を足して宣言コミットに同梱する（テスト数 4 入口一致と同型の網＝第 9 回レビュー提案・ 更新漏れを構造的に防ぐ）。

3. 英語版の追従（全章訳済み 2026-07-24＝前倒し完了・rephase 置換も英日同時済み——1.0 時に 残るのは最終改稿の追従・source_sha 更新のみ。ドリフトは doc-consistency 検査が自動検出）

4. git タグ付け・公開同期（publish.sh＝設計者の手動実行）・GitHub Release。
   • 公開ページを改名・削除する場合は旧 URL に redirect_from を張る（2026-07-27 常設化＝外部レビュー第 5 回 N4）。
   • Release 本文の英語草稿＝ローンチ計画書（非公開層）§6 に起草済み（2026-09-04）——当日は追補数・ テスト数・日付を実数へ。

   SEA バイナリの添付（2026-09-04 決定）: 1.0 の Release には添付しない。Windows 単体 exe は 1.0.x で「Windows 管理者・Excel 利用者向けガイド」と同時に出す （コマンドが打てる非開発者向けの導線＝ローンチ計画書〈非公開層〉Phase D の 2 本目の軌道・1.0 の Release 本文に「近日」は書かない）。

   • 材料（記録）: 現行 HEAD で SEA ビルドが green（2026-09-04 実測＝27 秒・Linux 118.0 MB・list の出力バイト一致・next –json 一致）＝技術的には添付可。
   • 1.0 で添付しない理由（開発者レーン向け）＝①主導線は npm（Node 20+・npx kairos-lang）で足りる ②Windows exe は注入で署名が無効になり SmartScreen 警告が第一印象になる ③macOS 台が無く非対称 ④ビルドは非公開ツール層＝利用者が再現できない生成物を配る形 ⑤patch 版ごとに再ビルド・再添付の運用が増える。
   • 1.0.x で出す形＝Windows x64 単体（壊れた署名を剥がして未署名に揃え・zip＋SHA256・Release 本文で npm と 並記）・Linux 単体は需要待ち。想定問答 6（production）では「SEA も可能」を即応材料として保持（押し付けない）。

5. 設計ジャーナル（非公開）に宣言記録・90-open-questions の最終スナップショット確認

6. npm publish（✅ 配布形式は 2026-09-04 決定＝案 A→A′・準備完了）——当初の決定は案 A（.ts を 型剥がしで直実行）だったが、Node は node_modules 配下の .ts を型剥がししない （ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING・最小実験で確認）ため、A の趣旨（束ねない・実行時 依存ゼロ・最小工数）を保った A′＝tsc の素通し変換で実装済み。
   • 構成＝tsconfig.build.json（outDir dist・rewriteRelativeImportExtensions・declaration）・bin: {kairos: dist/cli.js} （src/cli.ts に shebang）・exports/types＝dist/index.js/.d.ts・files: [dist, stdlib, README.md, LICENSE, NOTICE] （LICENSE/NOTICE を impl/ に同梱）・engines: node >=20・prepack: npm run build（pack/publish 時に自動ビルド・dist は gitignore）。
   • 検証＝dist 直・node_modules 配下の模擬コピーの両方で --version/list/next 実走一致・630 テスト green。

   配布経路の実害を事前に検出・修正（2026-09-07）: pack した tarball を別ディレクトリへ install して .bin/kairos を実走 したところ無出力で終了。

   • 原因＝npm の bin はシンボリックリンクで、isMain ガード（URL の文字列一致）が argv[1]〈リンク側〉と import.meta.url〈実体側〉の不一致で偽に落ちていた（9/4 の検証は cp 模擬で見逃し）。
   • 処置＝realpath 比較へ修正・リンク経由の witness を cli.test.ts に追加（旧コードで赤を実測）・SEA も再検証 green。
   • CI に pack→install→実走のジョブを新設（3 OS × Node 20＝engines 下限）＝publish 前から publish 後と同じ経路を機械検査。 当日はこの CI が green であることが前提。

   当日チェックリスト（事前の準備と確認・当日の書き換え）:

   • ✅① WSL 側で npm login（2026-09-04 完了＝--browser=false で URL を手動で開く形・npm whoami＝azathothx・~/.npmrc 600）
   • ✅② npm アカウントの 2FA（mode: auth-and-writes を確認済み＝publish 時に OTP・認証アプリを手元に）
   • ③ npm view kairos-lang が E404 のまま（空き・9/4 再確認済み）
   • ④ impl/package.json の name→kairos-lang・version→1.0.0

   当日チェックリスト（実施と事後）:

   • ⑤ npm pack --dry-run で同梱物を目視（dist/stdlib/README/LICENSE/NOTICE・test と node_modules を含まない）
   • ⑥ 公開クローンを v1.0.0 タグ時点に同期してから npm publish（初回は手動・OTP 入力）
   • ⑦ 検証＝別ディレクトリで npx kairos-lang@1.0.0 --version → 1.0.0・next -n 3 実走
   • ⑧ 以後の版は Trusted Publishing（GitHub Actions OIDC）へ移行可（初回 publish 後にパッケージ設定で構成・任意）
   • 取り消しは 72 時間以内・依存なしの場合のみ——誤りは unpublish でなく patch 版で上書きする。

   1.0.2 で確定した手順（2026-09-24）: WSL では npm login --browser=false に加えて npm publish --browser=false（2FA の Web 認証 URL を手動で開く。--browser=false 無しは BROWSER 未設定エラーで止まる）。

宣言日（確定）と宣言週の段取り

宣言日＝2026-09-14（月）（2026-08-26 決定・験担ぎ＝大安×一粒万倍日。選定は Kairos 自身の実測——六曜〈公開 doctest 済み rokuyo.kairos の式・2026 大安 61 件〉×一粒万倍 〈供給側の公表暦 64 日照合済み実式・節切り月×日支〉の交差で、目安内の唯一日。三重照合＝当方 交差式・大安 61 件・供給側照合値がいずれも 9/14 を含む。式と実測は設計記録側に保存 〈2026-08-26〉）。次候補は 9/26（土・目安の中旬を超過）。

宣言前の段取り

• 〜9/13: 定常（8/27 第 17 弾実測・8/31 第 18 弾）・第 13 便（8/30 前後）受領→回答・ 白露 9/7 →実測便（9/8 前後）受領→回答。条件 4 の初回点検は 8/26 実施済み→宣言直前に差分確認。
• 外部レビュー第 11 回（最終・8/26 受領＝名目 8/27）＝必修 A〜D・MEDIUM E〜L 全消化済み（同日）→ 第 12 回（同夜・名目 8/28）＝修正確認・本体ドキュメント 1.0 出荷 GO 確定（レビューサイクル閉幕。 残＝検定側 J の公開同期のみ〈正本は処置済み・下記の検定追従バッチに同梱〉）。
  • RC5 残存検査の許容リスト（レビュー §4 の棚卸し）: 歴史表記として残す 4 行＝§5.4 経緯 2 （spec/40-grammar・en）＋ reference/table-literal.md の「RC5 追補 9」引用（日英）——宣言 コミットの「RC5」残存検査にはこのリストを除外指定する。
  • 当日更新＝本体 11 行（状態行 4 は追補番号検査が守る・llms.txt・Playground 注記 2・70-release 内 3） ＋検定側＝follow-1.0.mjs（2026-09-04 機械化・dry-run 既定・--apply --head v1.0.0＝教本 3 冊の版行＋公開 README の 4 行・bank 90 問の spec_head→版タグ・残存 RC 走査。scratch 複製で –apply→verify.mjs 全 PASS を事前実証済み）→ verify.mjs 再実走 → 公開同期（第 11 回レビュー J もこれで解消）。
  • 9/14 までの残 LOW（任意）: ✅ EBNF の既存非終端棚卸し（追補 16 補綴 8/28 で処置）・✅ impl/README の 機構列挙とテスト一覧の現行化（ADR-52 まで列挙済み・テスト数 637＝9/7）・✅ 検証録 11 の「555 テスト」記録齟齬の注記 （8/28 に注記済みと 9/7 確認）・✅ 検定 README v1/L1 教本 v1.1 の表記統一・✅ L3 教本リテラル一覧へ Thh:mm（いずれも 2026-09-04 処置・検定側は 9/14 の公開同期で出る）。
• 9/14（宣言当日）: 条件 4 差分確認→条件 5（npm test・検査・公開層ガード）→宣言時作業 1〜5（下記）→ npm publish（パッケージ名 kairos-lang に裁定済み＝2026-08-28・404 で空き実測・ 素の kairos は既存 v2.1.3 のため回避・CLI コマンド名は kairos）。
  • Show HN は宣言日から切り離し 9/22〜24（裁定 2026-09-06＝npm の慣らし・米選挙日レシピ・README の npm 形の後。 段取りはローンチ計画書〈非公開層〉Phase D 冒頭）。
• 白露実測便が 9/8 前後に届かない場合も宣言は 9/14 で進める（条件 2 は充足済み・追送は 継続観測として受領）。

実施の記録

• ✅ 9/14 実施済み（2026-09-14 0〜1 時台）: 条件 4・5 通過→declare-1.0.mjs –apply→638 green→正本 c13f062＋タグ→公開 68348d4＋タグ v1.0.0→ GitHub Release「Kairos 1.0」→検定 follow-1.0→verify 全問 PASS→公開 3c108da→npm kairos-lang 1.0.0（設計者の端末で npm publish --browser=false＝2FA は Web 承認）→ npx 実走が参照実装とバイト一致→dev.to 2 本公開。記録は設計記録 2026-09-14。
• ✅ 1.0.1（同日 3 時台）: CLI の既定 tz を機械の tz へ（1.0.0 は Asia/Tokyo 固定＝npm 慣らし初日の Windows 実走で検出・NZ premise で窓が 0 件）。 witness 3 本・641 テスト・公開 aaceba6＋タグ v1.0.1＋Release・npm 1.0.1（設計者の端末）・dev.to ガイド更新。言語・評価は不変＝CHANGELOG 追補なし。
• ✅ 検定サイト exam.kairos-lang.org は 2026-09-04 に稼働（Pages 化＋サブドメイン割当＝同時実施・https 強制・ sitemap 23 URL・GSC 送信済み・本体 README 英日と llms.txt に導線。残り任意＝verified domains〈設計者〉）。
  • 裁定 2026-09-04（計画は検定側 design/20-domain-plan.md・7/30 策定）。トリガー (a)「宣言準備と束ねる」の窓が転記漏れで 過ぎていたため、(b)「対外告知の前」＝ローンチ週に URL が拡散する前に恒久 URL を立てる。
  • フェーズ 1（Pages 一式・表示検査とリンク検査の移植・公開同期＝当方・9/4 着手）→ フェーズ 2（設計者: DNS に CNAME exam → azathothx.github.io を 1 本・Pages 有効化＋Enforce HTTPS・verified domains）→ フェーズ 3（当方: 200・証明書・ canonical・sitemap・robots の実測・GSC ドメインプロパティの包含確認・本体からの導線）。
  • 稼働後の 9/14 検定追従バッチは「稼働中サイトの内容更新」になる。Release 本文・ローンチ記事からの参照は任意。

時期の目安と継続観測

2026-09 上旬〜中旬（2026-07-28 再計算＝第 8 便の時期確定を受けて従来の 2026-11 頃から前倒し。 根拠: 条件 1・3 は 2026-07-26 に前倒し充足済み・条件 2 の観測材料が 8 月下旬に揃う見込み〈立秋 8/7→処暑 8/23 の 2 発火〉・台帳第二期の受領検証後に残るのは条件 4・5 の機械的作業のみ。 宣言の裁定は設計者——台帳第二期の検証結果を添えて裁定を仰ぐ）。条件 1(b) の本番自然発火と 2027-02-02 の年次データ取得の初回自動発火は宣言後の継続観測として運用観測台帳（期ごと受領・ 非公開収蔵）で追う——宣言は「機構の実証が揃った」の宣言であり、観測の終了ではない。

1.0.x のリリース方針（2026-09-29 裁定）

間隔が短すぎるリリースが多いと信用を無くす。公開はなるべくまとめて行う。似たような修正だと他所から思われるようなものは なるべくまとめる。1.0.1〜1.0.4 は 9/14〜9/29 の 15 日間に 4 回（tz 既定・継承・F112/113・F114/115）＝多すぎた。以後の運用:

• 非公開の正本では追補・版上げを準備してよい（状態行・package.json は先行して構わない）。公開はまとめる。
• 間隔の目安＝おおよそ 2 日（2026-09-29 決定＝同じ日に 1.0.3・1.0.4 を立て続けに出したため、その日にさらに 1.0.5 は出さず、 おおよそ 2 日は間を空ける＝1.0.5 は 10/1 頃）。リリース前に他の綻びが出るなら時間的にはむしろ都合がよい＝待ち時間は綻び探しに使う。
• 別パッケージは分けて出す（2026-10-06 決定＝別パッケージは分けて出し、以降も同じ律動）＝impl の版（kairos-lang）を先に出し、2〜3 日 様子を見てから別パッケージ（kairos-lang-mcp 等）を本番の経路（npm の実物に対する install→lock→CI）で出す。Release 本文と告知も分ける。 mcp の初回＝1.0.7 の 2〜3 日後（10/10〜11 目安・手順は非公開の手順書に記録）。
• 例外は「黙って誤った日付を返す」級の欠陥のみ（決定性の破れ・供給側の本番に影響する形）。それ以外の綻びは次のまとめ公開に乗せる。
• 公開手順は不変（publish.sh → push → CI → tag → Release → npm は設計者）。Release 本文は束ねた追補を一覧にする。

まとめ公開の実績

• 1.0.5（追補 22）＝入口の介入 1 件目（診断の実例節）と束ねて 2026-10-01 0 時に公開（87 段 1 は間に合わず）。
• 1.0.6（追補 23＝最終窓の終端は未確定・§4.8 糖衣の継承）＋87 段 1（JSON Schema・--explain）＝2026-10-06 に 1 回で公開（4 点成立）。
• 1.0.7（追補 24＝.ics 書き出し・Playground「カレンダーに入れる」・暮らしの例の導線・778 テスト）＝2026-10-08 0 時過ぎに公開（4 点成立）。
• 1.0.8（追補 25＝.ics の実機知見・779 テスト。バグ修正は同日に出してよい＝決定済み）＝公開予定 2026-10-08 （10/6 に 1.0.6 を公開した直後のため最短で 10/8）→ 2026-10-08 に公開（4 点成立）。
• 1.0.9（追補 26＝--json の results[].uid〈2026-10-08 決定〉＋Playground の例の祝日表 2027〈10/9〉）＝2026-10-10 公開（E・D・TSV は次以降）。
• 1.0.10（追補 27＝CLI --tsv・mcp の登録簿の名札・Issue フォーム・npm への公開を GitHub Actions から〈trusted publishing・来歴〉）＝2026-10-16 公開。同日に Windows 単体 exe（未署名・Release の資産）・公式 MCP Registry 登録・E プロファイル（付録 A）・Excel 対照レシピ。

This site is open source. Improve this page.