| title | ドキュメント索引 | |||
|---|---|---|---|---|
| status | current | |||
| scope | 全体 | |||
| audience |
|
|||
| updated | 2026-09-02 | |||
| supersedes | ||||
| related |
|
ここが唯一の入口。 目的の文書はこのページから引く。文書一覧ではなくタスク起点の案内である。 文書の書き方・
statusの意味・腐り防止の約束は 00_ドキュメント規約。
| やること | 読むもの |
|---|---|
| 次に何をやるか知る／作業を再開する | 05_実装計画と現在地（「次にやること」だけ読めば再開できる） |
| 会計の正しさを確かめる（仕訳・訂正・締め・繰越） | 04_会計ドメイン設計 — 複式簿記の正しさはここで担保する |
| 消費税を実装する | 06_消費税設計 → 消費税リサーチ |
| 画面を作る・利用者に見せる文言を書く | 09_画面の原則（押す前に見せる・です・ます調・内部表現を出さない） → ADR-0017（「仕訳」「伝票」の使い分け） → ../Designer/Project.md（CLB での書き方） |
| 制度・市販ソフトを調べる | 10_調査の原則（いつ・何を調べ、どこまで調べたかをどう書くか） → 00 §4-9（根拠の格付けと出典の書式） → research/ |
| 取引先マスタに何を持つか決める | 07_取引先設計 → 取引先の識別番号と公表システム（法人番号は持てる・個人番号は持てない） |
| 登録番号の写しをいつの登録で引くか | 07_取引先設計 §4-1 → 登録の効力を失う日（公表される日付が最終日か初日かは未確認。境界は含める側に倒した） |
| スキーマを変える・稼働 DB へ配る | migrations README（変える手順・書き方の規則） → ddl README（正典）。方式の経緯は ADR-0020 |
| 新しいマスタをどこに置くか決める | ADR-0029（**「会計をやめても存在し続けるか」**を先に問う）→ 08_マスタ台帳（各マスタの現在形に行を足す） |
| 部品として分けるかを決める | ADR-0029（基準）→ ADR-0025（取引先への適用例） |
| 画面を誰に見せるかを決める・PageFrame を足す | ADR-0034（役割の軸）→ ADR-0035（フレームと玄関）→ ADR-0036（権限をどこに書くか）→ ADR-0033（読み取りを誰に開くか）→ qa/01 の F-18〜F-24・F-30（権限を書く前に必ず読む） |
| 一覧の見せ方が標準では足りない | ADR-0027（ラップモジュール ＋ クエリモジュール）→ ADR-0022（帳簿の場合） |
| 取引先の名寄せを実装する | 07 §2（規則）→ ADR-0028（なぜ深さ 1 か） |
| 帳簿に何を残すか判断する | ADR-0018（記載事項は写して固定・資格は有効期間で持つ） → 消費税リサーチ §6・§8 |
| 帳簿を作る・法定検索を確かめる | 電帳法リサーチ §3.5・§13.1 → 取引金額での検索の調査。帳簿は明細 1 行＝1 レコードのクエリモジュールで作る（Designer/Design/Modules/Accounting/Books/。ADR-0022） |
| 新しい機能を検討する | 03_機能スコープ → 該当する ADR |
| 「この機能は入れるのか」を判断する | 02_ペルソナ → 03_機能スコープ |
| CLB の書き方を調べる | ../Designer/CLAUDE.md → ../Designer/ClaudeCodeForDesigner/CLAUDE.md（仕様リファレンス） |
| CLB の制約・「静かな失敗」を避ける | qa/01_CLB静かな失敗 |
| 判断の経緯を知りたい | decisions/README（ADR。仕様書は What、経緯はこちら） |
| やること | 読むもの |
|---|---|
| デザインの静的検査 | designcheck CLI（../Designer/CLAUDE.md） |
| 公開前チェック | python tools/docs/lint_secrets.py |
| ドキュメント規約の検査 | python tools/docs/lint_docs.py |
| SQL・DDL テストの強さを測る | qa/05_観点網羅の計器（計画） |
| デプロイして実機で確認する | pwsh -NoProfile -File tools/clb/deploy.ps1 → tools/README |
| やること | 読むもの |
|---|---|
| 「何を・なぜ作っているか」を説明する | 01_企画概要 → 02_ペルソナ |
| 制度・法令の根拠を示す | research/（一次情報。出典 URL と確認日つき） |
| CLB へのフィードバックを見る | 11_CLB改善提案/ |
各文書の status が current 以外なら読まなくてよい。
番号は連番であって読む順ではない。役割で読む。
| ファイル | 役割 | 内容 |
|---|---|---|
| 01_企画概要 | 企画 | 何を・なぜ作るか。前回プロジェクトとの違い・品質目標 |
| 02_ペルソナ | 企画 | 株式会社アルタイルシステムズ（架空）— 全機能判断の基準 |
| 03_機能スコープ | スコープ | 含める／含めないの正典 |
| 04_会計ドメイン設計 | 設計（会計コア） | 科目・仕訳・税・締め・繰越。複式簿記の正しさの担保 |
| 05_実装計画と現在地 | 進行管理 | **毎回の起点。**現在地と次にやること |
| 06_消費税設計 | 設計（会計コア） | 税区分・用途区分・税額計算方式・端数・経過措置・控除方式 |
| 07_取引先設計 | 設計（取引先部品） | 識別・名寄せ・適格請求書発行事業者の登録・計上時に写すもの |
| 08_マスタ台帳 | 設計（会計コア） | 各マスタの仕様の正典。所有・誰が編集・更新のきっかけ・版と削除・初期データ |
| 09_画面の原則 | 原則 | 画面が満たすこと。押す前に見せる・文言・一覧と帳簿・揃え・用語 |
| 10_調査の原則 | 原則 | いつ・何を調べ、どこまで調べたかをどう書くか。市販ソフトの使い方 |
| ディレクトリ | 内容 |
|---|---|
| 00_ドキュメント規約/ | 文書の書き方・status・腐り防止の約束。総則（§1・§2・§5〜§7）／フロントマター（§3）／本文の書き方（§4）。節番号は 3 冊を通して一意 |
| decisions/ | ADR（判断ログ）。1 件 1 ファイル・番号順 |
| research/ | 制度・技術のリサーチ記録（出典 URL と確認日つき） |
| qa/ | 品質保証。01 CLB の静かな失敗／02 自己レビュー記録／03 テストで漏らした実例／04 実機操作テスト／05 観点網羅の計器（計画） |
| 11_CLB改善提案/ | CLB 本体・マニュアルへの改善提案（FB-nnn / DOC-nnn） |
| ファイル | 内容 |
|---|---|
../CLAUDE.md |
ミッションブリーフ（最上位の指示書） |
../README.md |
リポジトリの概要・セットアップ |
../Designer/CLAUDE.md |
CLB デザインワークスペースの運用ルール |
../Designer/Project.md |
プロジェクト固有ルール（DB・命名・フォルダ・デプロイ手順）と、画面の原則の CLB での書き方（原則そのものは 09） |
../Designer/ClaudeCodeForDesigner/CLAUDE.md |
CLB 仕様リファレンス（生成物・手で編集しない） |
../Designer/ddl/README.md |
DB スキーマの正典（現在形の DDL） |
../Designer/seed/README.md |
初期データ |
../Designer/migrations/README.md |
スキーマ変更の配り方（差分） |
../tools/README.md |
開発スクリプト（コミット前フックの 7 段もここ） |
../LocalData/README.md |
実行環境データ（DB・デプロイ zip）の構成。Git 追跡外なので各自の環境にのみある |
開発者に確認したいこと。 決まったらここから消し、決定は ADR か仕様書へ移す（00 §4-4）。
行数は書かない（触るたびに動き、書いた瞬間から腐るため）。
いまの値は python tools/docs/lint_docs.py --stats が出す。
行数超過の項目は開発者に問うものではない（Claude の自己保守）。他の項目と読み分けること。
- 2026-08-28
docs/07_取引先設計が目安の 250 行を大きく超えている。 インボイス登録（§3・§4）を別の文書へ切り出すか、削るかを決める （00 §5）。フェーズ 2.5 の終わり—— 2026-09-02 にフェーズ 2.5 が終わったので、いま決める番である - 2026-09-02 計上済みの伝票の詳細が、取引先欄に「いまのマスタの名前」を出す。 帳簿は計上時の写しを出すので、同じ伝票を 2 か所で見ると名前が違う （実測。qa/04 §4 の 2026-09-02）。 ADR-0018 が決めたのは 帳簿の記載事項までで、伝票詳細の参照欄の見せ方は決めていない。 帳簿の正典性（写し）とマスタへの導線（現在名）のどちらを重く見るかを決める
- 2026-08-29
docs/04_会計ドメイン設計が目安を超えた。 05 §2 から計上の関門と会計年度の決まり方を引き取ったため。 複式簿記の正しさの正典なので安易に削れない。 消費税に寄った節を 06 へ寄せられないかを見る。フェーズ 3 の着手前
個別の文書が抱える保留は、その文書の末尾にある—— 03_機能スコープ・06_消費税設計・07_取引先設計・ seed。実装の未決事項は 05 §5、 計器の実装時の保留は qa/05 §8。