決定記録
このファイルは各
pjr-XXXX-<topic>.md（個票）から生成された派生ビューです。正本は個票の Frontmatter であり、このファイルは再生成可能です。
| ID | ステータス | タイトル | 説明 | 分類 | 優先度 | 担当 | 登録日 | 期限 | 完了日 | 結論 | 個票 | depends_on |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PJR-0119 | decided | プロジェクト憲章の承認 | prj-charter の立ち上げ認可と権限委譲を PO として承認する | decision | high | PO | _TODO_ | 2026-07-17 | 2026-07-17 | コミットce44286c時点の憲章を承認。立ち上げ認可と権限委譲を確定 | pjr-0119-charter-approval | - |
| PJR-0120 | decided | 初期公開の範囲・ライセンス・貢献導線の確定 | 初期公開の対象範囲、ライセンス、貢献導線を PO の判断で確定する（旧 ACD-D03） | decision | high | PO | _TODO_ | - | 2026-07-24 | 採用ライセンスを MIT、貢献導線を GitHub issue / pull request として確定 | pjr-0120-item | - |
| PJR-0121 | decided | 公開先・公開範囲・変更提案受付方法の確定 | 公開リポジトリの公開先、公開範囲、変更提案の受付方法を確定し、公開資料に機密情報や対象外の業務情報が含まれないことを確認する（旧 ACD-D04） | decision | high | PO | _TODO_ | - | 2026-07-24 | 公開先を GitHub + GitHub Pages、変更提案の受付方法を GitHub issue / pull request として確定 | pjr-0121-item | - |
| PJR-0154 | decided | シビックテックサービスの運用設計（090-operationsドメイン）の対応時期を決定 | 運用設計について、prj-0001での対応方針を決定する | decision | medium | PO | _TODO_ | 2026-08-31 | 2026-08-04 | シビックテックサービスの運用設計（090-operations相当）はprj-0001の対象外とし、代表試行（SC-01〜SC-03）確認後の後続プロジェクトで検討する | pjr-0154-operations-domain-timing | - |
| PJR-0ZAS | decided | ローカル LLM を Ollama と gemma・qwen の役割の分担に整理する | ローカル LLM の基盤を Ollama にし、reporter は gemma26、小さな修正の executor は作業の種類で gemma-executor（31B）と qwen-executor を使い分ける。thinking on の executor、gemma26 の executor、使っていない定義は無効にする | decision | medium | DEV | 2026-10-18 | _TODO_ | 2026-10-18 | ローカル LLM の基盤を Ollama にし、reporter は gemma26-reporter、小さな修正の executor は plan で決まった作業に gemma-executor（31B）、内容を組み立てる作業に qwen-executor を使う。thinking on の executor・gemma26 の executor・使っていない定義は無効にし、名簿の変更は PJR-8MPY で行う | pjr-0zas-local-llm-consolidation | - |
| PJR-1F46 | decided | 成果物カタログはkata整備のため最大セットで作成し、実装・運用はSC-01〜SC-03へテーラリングする | 全19ドメイン238件の成果物カタログを、prj-0001自身の最小スコープではなくkata（rulebook/recipe/sample/template）整備・検証を兼ねて最大セットで作成した。evidence_refs（コード・テスト）とbased_on（prj-*/pm-*文書）による裏付けでAI生成の捏造リスクを抑える方針とし、prj-scope.mdの該当箇所（初期公開に含めるもの2、スコープ外表）を更新済み。 | decision | medium | _TODO_ | 2026-08-14 | _TODO_ | 2026-08-14 | kataは広く整備し、成果物本体の完成はSC-01〜SC-03に必要な範囲へテーラリングする。prj-scope.md更新済み。 | pjr-1f46-kata-sc-01-sc-03 | - |
| PJR-1SXK | decided | Refs trailer の ID を <project-id>:<item-id> に修飾する | commit message の Refs: trailer は、登録簿の ID（PJR-XXXX）だけで書いてきた。登録簿の ID はプロジェクトごとに乱数で振るため、プロジェクトの中でしか一意ではない。1 つのプロジェクトリポジトリには複数のプロジェクトを置ける。また、別リポジトリ構成（既定）では、プロダクトリポジトリの履歴から登録簿の項目へたどるときに、どのプロジェクトの項目かを特定できない。 | decision | high | ARC | 2026-10-01 | _TODO_ | 2026-10-01 | Refs trailer の値を <project-id>:<item-id> とし、プロダクトとプロジェクトの両リポジトリに適用する。過去の履歴は書き換えない | pjr-1sxk-refs-trailer-project-qualified-id | - |
| PJR-2ZMY | open | 文書の編集ツール（図・プレゼン・表）の方針を決める | 人との連携を重視し、図・プレゼン・表をどのツールと形式で書くかを決める。local の編集環境の検討レポート（2026-10-17）は draw.io・Slidev・CSV を推奨するが、agent が書いて直す運用との相性もあるため、継続して検討する | decision | medium | ARC | 2026-10-23 | _TODO_ | - | - | pjr-2zmy-document-editing-toolset | - |
| PJR-2ZVS | decided | grade と review の役割分担を evaluation 区分で定義し、評価経路を統合する | grade は routine（夜間）で kata と成果物を評価し、sidecar へ level / score / findings を書く。schedule の review はフェーズとして実行され、ロール別の観点で verdict を出す。両者は独立した経路だが、実際には同じ資産を共有している。 | decision | high | ARC | 2026-09-23 | 2026-10-17 | 2026-09-26 | grade は成果物の品質、review はタスクの完了可否を判定する別の経路とする。評価は grade が 1 回だけ行い、review は文書を再評価せず grade を事実として受け取って完了可否を判断する。観点は 28 件を共通とし continuous を廃止する。review phase は評価を持たないため Action へ移す。 | pjr-2zvs-grade-review-integration | - |
| PJR-3DY1 | decided | 夜の間に承認済みの todo を実行・確認・close まで自動で進める方針を決める | register の todo の実行では、orchestrator が次の 7 つを行っている。夜の間は orchestrator の確認と close で作業が止まる（2026-10-17 の夜は、上限で止まった実行の再開も止まった）。 | decision | high | ARC | 2026-10-18 | - | 2026-10-18 | 承認済みの todo の並びを夜の間に実行・確認・close まで自動で進める（段階 B）。実行のあとの review の agent と自動の close（段階 A）から入れ、夜の orchestrator は印のある個票だけを流し、見つけた問題は derived_from を付けて承認待ちとして起票する | pjr-3dy1-night-orchestrator-autopilot | - |
| PJR-3N21 | decided | 実践の型の要否と所在の正本を分ける | 実践の型の宣言が成果物カタログと rulebook frontmatter の2か所にあり、意味が混ざっている。カタログには文書 ID が書かれ、bps-sample が29件の成果物へ重複するなど、系統単位で決まる情報を成果物ごとに持つ二重管理になっている。要否（その成果物にその型が必要か）と所在（実体がどの文書か）で正本を分けるかを決める。 | decision | medium | ARC | 2026-08-24 | 2026-08-31 | 2026-08-24 | 実践の型の要否と所在は、いずれも rulebook frontmatter を正本とする（選択肢A）。成果物カタログは型の宣言を持たず rulebook の宣言のみを保持する。kind が generated の成果物には型を適用せず、宣言ではなく kind から導出する。rulebook を持たない成果物は rulebook: not-needed で表現し型の宣言を不要とする。所在が rulebook の外に置かれた例が実在せず、PJR-VV3M の方針も3種すべてが系統単位の判断であるため。要否の4状態と判断基準は置き場所を変えるのみで意味は変えない。移行は別途起票する。 | pjr-3n21-kata-declaration-ssot-split | - |
| PJR-3S8Q | decided | 実行コマンドを定義する設定ファイルは agent の書き込み範囲に含めない | 親 runner の parent_validations は固定 argv（npm run test:integration）で起動するが、実行される内容は package.json の script 本体である。lefthook.yml のコマンドも commit 時に親コンテキストで実行される。したがって edit agent にこれらの書き込みを許すと、設定できるのは ID だけで任意の command や引数を注入できないという exec-defaults の設計前提が無効になり、サンドボックス外での任意コード実行につながる。PJR-CMYX の対応中に一度 allow へ追加したが取り消し、agent は変更が必要な場合に result へ申し送りとして記録し、人間または orchestrator が適用する運用とする。 | decision | high | ARC | 2026-08-21 | 2026-08-31 | 2026-08-21 | 実行コマンドを定義する設定ファイル（package.json、lefthook.yml、.specdojo/**、commitlint 設定、CI 設定）は agent の書き込み範囲に含めず、必要な変更は result の申し送りとして人間または orchestrator が適用する運用に確定した。決定だけでは provider の sandbox 方式に依存して守られないことが PJR-0DA8 で判明したため、PJR-Y3KP で provider 非依存の強制手段を実装し、対象一覧と例外手順を exec 設定ガイドへ明記した。 | pjr-3s8q-agent-writable-config-scope | - |
| PJR-5822 | decided | 1 つの項目で複数リポジトリを変更する exec の方針を決める | 既定の別リポジトリ構成では、プロジェクトリポジトリ（app1-specdojo/）とプロダクトリポジトリ（app1/）を分ける。現行の exec は、プロジェクトリポジトリ 1 つと worktree 1 組だけを扱う。このため、プロダクトの実装やプロダクト文書を変更する項目は exec run で扱えない（docs-structure-guide の「現行実装の境界」）。v0.3.0 で、1 つの項目が複数のリポジトリを変更する exec を実現する。N 個のリポジトリを扱える設計とし、まずプロジェクトリポジトリ 1 つとプロダクトリポジトリ 1 つで動かす。複数プロダクトの論点は prj-0001:pjr-p7hy-multi-repo-single-item にある。 | decision | high | ARC | 2026-10-01 | _TODO_ | 2026-10-01 | 推奨案を採択し、論点 2.1. は N 個のリポジトリを v0.3.0 で実装・保証する形に変更した | pjr-5822-multi-repo-item-design | - |
| PJR-65DS | decided | 成果物の文脈の渡し方と draft approach を定める | PJR-166T の調査で、成果物を作るときの前提（技術スタックなど）を agent に渡す場所が無く、fully-guided の plan 雛形が草案作成と磨き込みを兼ねて説明と食い違っていることが分かった。tsd-*.md を「静的サイトで主流の技術スタックで書く」といった指示で作れるようにしたい。 | decision | high | _TODO_ | 2026-10-29 | _TODO_ | 2026-10-29 | 1-C と 2-B を採用。雛形→人が文脈を記入→draft→fully-guided→finalize とし、文脈は成果物内の _CONTEXT_、個票の入力（--input）、カタログの brief で渡す | pjr-65ds-deliverable-context-draft-approach | - |
| PJR-8QT0 | decided | 追加の kata のパッケージ（variant package）の扱いを決める | 規則では業界や用途ごとの kata の一式を別の authority のパッケージ（variant package）として持てるとしているが、置き場所・公開の仕方・利用者のリポジトリから読む仕組み・authority の登録の仕方が決まっておらず、実装もない。coderdojo-lessons で育てる edu-scratch の kata を将来配る前提で決める | decision | medium | ARC | 2026-10-23 | _TODO_ | 2026-10-23 | 公式の variant は specdojo のリポジトリの packages/kata-<authority> に置き別のパッケージとして公開する。利用者は設定に読むパッケージを並べ、各パッケージが authority を宣言する。specdojo は core 専用。育てた kata は id もパスも変えずに移す。置き場所は docs/ja/specdojo/<種類>s/<authority>/（core は種類のディレクトリの直下） | pjr-8qt0-variant-kata-packages | - |
| PJR-9G9Y | decided | 体系の用語と標語を見直す | 成果物体系・実践体系・遂行体系と Kata・Waza・Ryu の名前が重なって分かりにくい。標語を「記して、形にして、磨き続ける。」へ改め、遂行体系を PDCA × register・schedule・routine + Job のマトリクスで説明する案を検討する。routine + Job の行は PJR-MD3C の task.review を前提にする。Quick Start の「設計書」と workspace/ もあわせて直す | decision | medium | BA | 2026-10-12 | 2026-10-31 | 2026-10-12 | 選択肢 C。3 つの体系を成果物・型（Kata）・技（Waza）に改め、流（Ryu）をそれらをつなぐ属性とする。標語・PDCA マトリクス・仕様書の語・app1-workspace/ もあわせて改める | pjr-9g9y-practice-execution-terminology | - |
| PJR-9Y7G | decided | 登録簿の正本を1項目1ファイルへ移し pjr-index を生成ビュー化する | 登録項目の正本を個票 frontmatter へ一本化し、pjr-index.md を generated の派生ビューへ変更するかを判断する。表の差分レビュー喪失の代替手段も選択肢比較に含める。 | decision | high | PO | 2026-08-09 | 2026-08-31 | 2026-08-09 | 選択肢Bを採択。個票 frontmatter を正本とし pjr-index を生成ビュー化する | pjr-9y7g-register-item-file-as-ssot | - |
| PJR-BNMV | decided | プロダクトのリポジトリの commit とブランチの形を運用に合わせて選べるようにする | プロダクトのリポジトリ（repos で宣言したもの）へ exec が積む commit は、1 行目が exec(register <ID>): <タイトル> に、merge commit のメッセージも同じ形に、作業ブランチの名前が exec/<project-id>-<ID> に、コードで固定されている。統合先は integration_branch と --integration-branch で feature ブランチにできるが、履歴の見た目は git-flow や GitHub flow にならない。 | decision | medium | DEV | 2026-10-31 | 2026-11-30 | 2026-10-31 | 案 A を採る。プロダクトのリポジトリごとの設定で作業ブランチの名前・commit の 1 行目・merge commit の書式と統合の形（merge・branch-only・ff）を選べるようにし、commit の type と scope は個票で項目ごとに持つ。git-flow の例は feature/{topic} とし、ブランチ名が別の項目と重なったら run の開始時に止める | pjr-bnmv-product-repo-git-workflow | - |
| PJR-BZSN | decided | agent skills の扱いを見直す（SpecDojo の skill の配布と外部の skill の利用） | plan・result・git を契約とし Kata を知識の正本とする中心は保ったまま、SpecDojo が配る skill の範囲と生成の仕組み、外部の skill を使う条件（一覧・記録・版の固定）、既存の 3 件の skill の扱いを決める | decision | medium | _TODO_ | 2026-10-28 | _TODO_ | 2026-10-31 | plan を契約、Kata を正本とする中心を保ち、skill は補助とする。SpecDojo は SSOT から生成する CLI の入口とオーケストレーターの skill を配る。外部の skill はプロダクトのリポジトリに入れて版を固定し、repos[] での宣言と plan での参照で使い、plan と evidence に記録する。既存の 3 件の skill は使われていないため消した | pjr-bzsn-agent-skills-policy | - |
| PJR-E8TT | decided | 初期リリースの差別化軸を定める | Gas Town / Gas City の調査を踏まえ、初期リリースで前面に出すものを決める。exec 層は実行基盤として規模で先行されているため機能比較に持ち込まない。register は task tracker ではなく、判断・観測・保留を含めて記録する場である点を差別化として扱う。orchestrator の規律、成果物 kata の網羅範囲と合わせて位置づけを定める。devcontainer と tmux の扱いも併せて決める。 | decision | high | ARC | 2026-09-24 | 2026-10-10 | 2026-09-24 | 初期リリースで前面に出すのは register の記録範囲、対話型 orchestrator、成果物 kata の網羅範囲の 3 つとする。exec 層は機能比較に持ち込まず成果物体系を維持する手段として説明する。tmux を agent runtime として採らず、devcontainer は常時稼働環境の構成例として補強材料に位置づける。 | pjr-e8tt-initial-release-positioning | - |
| PJR-EWWX | decided | 複数人開発に備えて人が書いた変更を feature ブランチ経由に統一する | 現行の運用では、exec の自動実行だけが exec/prj-0001-<task-id> で隔離され、人とオーケストレーターが書いた変更は project/prj-0001/develop へ直接 commit している。直近 60 commit の first-parent では、21 件が exec の merge commit、残り約 35 件が直接 commit である。 | decision | medium | ARC | 2026-09-23 | 2026-10-31 | 2026-09-23 | develop へ入る経路を exec ブランチ / feature ブランチ / 記帳の直接 commit の 3 層に分ける。人が内容を書いた変更は feature から PR で統合し、register の記帳は develop 直 commit を許容する。 | pjr-ewwx-feature-branch-policy | - |
| PJR-FKN1 | decided | kata の配布方式を node_modules 参照を既定とし eject で上書きする方式に決める | npm 公開後、利用プロジェクトは npm install specdojo と npx specdojo config init から Detached Unit を立ち上げる。空のリポジトリで実測したところ、register 系は単独で動作するが、次が動かない。 | decision | high | ARC | 2026-09-23 | 2026-10-03 | 2026-09-23 | kata と schema は node_modules 参照を既定とし、上書きしたいものだけ eject する。exec-templates と schemas は参照固定、規範文書と成果物テンプレートは eject 可、全量コピーは docs サイト配信向けの選択肢として残す。 | pjr-fkn1-kata-distribution-method | - |
| PJR-GX9D | decided | VS Code 関連機能を SpecDojo 拡張へ集約する方針を定める | SpecDojo の編集支援機能が複数の場所へ分散している。 | decision | medium | ARC | 2026-09-06 | 2026-09-30 | 2026-09-14 | VS Code 依存の編集支援機能（表整形、[[id]] のリンク表示と遷移）を packages/vscode-specdojo 拡張へ集約し、Marketplace 配布を正とする。fmt-md-table.ts は拡張へ移して削除済み、tasks.json のタスクは移行期間中は拡張コマンドへ委譲する形で残す。実装が決定どおり揃っていることを確認し、公開（PJR-0143）と導入手順（PJR-0142）は個別に追跡する。 | pjr-gx9d-vscode-extension-consolidation | - |
| PJR-H220 | decided | 観点の document_kinds を rulebook ID 列挙で保守し続けるか決める | PJR-AG7B では、観点がどの種類の文書に当てはまるかを document_kinds の include / exclude で宣言する仕組みを入れた。対象は rulebook ID で列挙する。 | decision | medium | DEV | 2026-09-27 | _TODO_ | 2026-09-27 | 選択肢 B を採択。document_kinds は rulebook ID の列挙を維持し、観点ごとに判断漏れの rulebook を一覧化する検証を追加する。実装は PJR-VJP8 | pjr-h220-viewpoint-document-kinds-maintenance | - |
| PJR-H72A | decided | register の todo から approach を使って成果物と kata を作る・直す方針を決める | approach（fully-guided・recipe-guided・retrofit・rulebook-maintenance など。src/shared/agent-types.ts の Approach）を使った成果物の作成と、kata（rulebook・recipe・sample・template）の生成・修正は、schedule のタスクからしか実行できない。利用者から、register の todo から実行できるようにする提案があった（2026-10-17）。 | decision | medium | ARC | 2026-10-17 | - | 2026-10-17 | 個票に approach と対象を書き、exec run --register が schedule と同じ plan の作り方を使う。DCT の done_criteria を基本に個票の完了条件を加え、owner は個票の owner、kata は id と保守の approach で指定する。exec run --deliverable は互換のため残す | pjr-h72a-register-approach-execution | - |
| PJR-NJJ7 | decided | register を業務の起点とし、track の仕事を epic 型で管理する | register を業務の起点・着手承認・完了判断の層とし、track ごとの epic（新しい type）から子 todo で catalog・sch-strategy・sch-track を作成し、schedule で流す構成へ変える | decision | medium | _TODO_ | 2026-10-28 | _TODO_ | 2026-10-28 | 案 C を採用。register を業務の起点とし、track ごとに新しい type の epic を起票して子 todo でカタログ・sch-strategy・sch-track を作り schedule で流す | pjr-njj7-register-epic-track-governance | - |
| PJR-NYZR | decided | SpecDojo の普及戦略を決める | v0.3.0 の公開に向けて、SpecDojo の位置づけ、入口、最初に狙う利用者、段階的な計画と指標を決める。根拠は prj-0001:pjr-36qg-competitive-landscape-and-release の「v0.3.0 の機能と SDD のツールの比較（2026-10-08）」と「設計文書・判断の記録・文書の維持の領域の比較（2026-10-08）」である。 | decision | high | PO | 2026-10-08 | - | 2026-10-08 | 選択肢 B。仕様と設計の基盤として、register を仕様の判断台帳として入口にし、kata・grade へ順に進める。最初に狙う利用者は設計書を作り保守する日本のチーム | pjr-nyzr-adoption-strategy | - |
| PJR-Q761 | decided | exec-run.ts の分割方針を決める | 2026-10-08 時点で 7,948 行の src/exec-run.ts を、準備・agent の起動・親検証・統合・再開の段階ごとのモジュールへ分ける方針と、初回と再開の経路を 1 つの状態遷移にまとめる方法を決める（v0.3.0 の公開後） | decision | medium | ARC | 2026-10-02 | _TODO_ | 2026-10-08 | 選択肢 C（現行の挙動のまま下位の層から段階的に切り出し、characterization test を加えてから開始段の判定を純粋な遷移関数へ寄せる）を採る。実施は v0.3.0 の公開後 | pjr-q761-exec-run-module-split | - |
| PJR-QESV | decided | 実践の型は必要なものだけ作り、不要と判断した結果を宣言に残す | どの成果物にどの実践の型（rulebook / recipe / sample / template）を作るかの基準が存在せず、整合性を担保できない。各 authoring standard は既に作ると決めたものの書き方しか定めておらず、kata-guide と practice-system-composition-guide は役割と使い分けを説明するだけである。結果として recipe だけが 84 種別中 19 件という分布になり、その理由が記録されていない。作らない判断と未整備の区別も付かないため、棚卸しのたびに同じ議論が繰り返される。 | decision | high | BA | 2026-08-23 | 2026-08-31 | 2026-08-23 | 実践の型は4種すべてを機械的に作らず、種別ごとの作る条件・作らない条件で要否を判断する。必要な型は成果物カタログへ文書IDを宣言し、不要と判断した型は not-needed と宣言する。項目なしは要否未判断であり not-needed とは区別する。要否は初回の bootstrap で判断する。基準は kata-guide に記載し、catalog build が宣言の実在性を検証、schedule assessment が not-needed の型を維持タスクの対象から外す。実装は PJR-K4TA で完了した。 | pjr-qesv-kata-creation-criteria | - |
| PJR-QGP4 | decided | SpecDojo の呼び方を仕様道（Spec-Dō）にする | README・docs サイトのトップ・概要ガイドは、SpecDojo を「仕様駆動開発のためのドキュメントフレームワーク」と呼んでいる。仕様駆動開発（Spec-Driven Development, SDD）は、2026 年の市場では仕様から AI にコードを書かせる手法を指し、Spec Kit・Kiro・OpenSpec が代表である。prj-0001:pjr-nyzr-adoption-strategy で SpecDojo を「仕様と設計を作り、運用まで保つ基盤」と位置づけ、SDD のツールとは名乗らないと決めたため、この呼び方は位置づけと矛盾する。 | decision | high | PO | 2026-10-08 | - | 2026-10-08 | SpecDojo を仕様道（Spec-Dō、the way of specification）の道場と呼ぶ。仕様駆動開発とは名乗らない。表記・標語・比喩の範囲と、守破離と approach の対応を定めた | pjr-qgp4-naming-spec-do | - |
| PJR-QQKY | decided | src の機能どうしの循環する依存をほどく方針を決める | prj-0001:pjr-x8y9-src-dependency-direction-rules の調査（2026-10-17）で、src の機能どうしの循環する依存が 6 組見つかった。 | decision | low | ARC | 2026-10-17 | - | 2026-10-17 | exec の汎用の部品のうち他の機能が使う部分を src/shared へ移し、残る循環を 1 件ずつ直し、循環がなくなった組から依存の向きの規則を足す | pjr-qqky-src-feature-cycles | - |
| PJR-RTD5 | decided | 用途別のひな型（スターター）の範囲と提供の形を決める | Next.js と Cloudflare、scratch-lesson、ランディングページなど用途別のひな型で onboarding のハードルを下げる。3 層の構成、追加の設定の渡し方、GitHub の template repository での提供、定期的な作り直し、複製後の初期化、セキュリティの自動チェックを決める | decision | medium | _TODO_ | 2026-10-28 | _TODO_ | 2026-10-31 | ひな型は生成・追加の設定・SpecDojo の 3 層とし、追加の設定は CLI と recipe を併用し（案 C）、GitHub の template repository を主な入口にする。作り直しは Actions の定期実行で PR にし、初期化とセキュリティの自動チェックを備える。最初はランディングページ、次に Next.js と Cloudflare を作る | pjr-rtd5-starter-templates | - |
| PJR-RYK8 | decided | 成果物の type の値の範囲と rulebook との対応を見直す | 要件・用語集に当たる type がなく、プロダクトの仕様の sample の多くが project になっている。type の値の範囲、各 rulebook が扱う成果物の type の対応、その宣言の方法を決める | decision | medium | _TODO_ | 2026-10-28 | _TODO_ | 2026-10-28 | 1-B と 2-B を採用。type に requirement と glossary を足し project は管理文書に限る。rulebook の frontmatter で扱う成果物の type を宣言し、成果物・sample・テンプレートの type を lint で照合する。古い値は移行期間なしでエラーにする | pjr-ryk8-deliverable-type-taxonomy | - |
| PJR-T7ZQ | decided | Registerの状態遷移に対するcommit policyを選定する | PJR-TPY9 で Register の状態遷移を追記型 event として記録できるようにした後、遷移ごとにコミットする現行の運用を見直す。per-event、per-item、batch、related-change、manual などの候補を評価し、採用する policy、既定値、設定方法、人手・Agent・routine・worktree 実行時の扱いを決める。event が履歴を保持するならコミット頻度を下げられるため、PJR-TPY9 の完了を前提とする。 | decision | medium | ARC | 2026-08-24 | 2026-10-31 | 2026-08-28 | 遷移時の commit policy は per-event を維持し、雑音の削減は develop から main への昇格境界で行う。register start のコミットは worktree 隔離の構造上の要件であり、コミットしないと worktree の個票が着手前の状態のままとなり agent が誤読する。当初の課題はプロダクト変更を追う Git 履歴の信号対雑音比であり、main が読みやすければ目的を果たす。develop の細かさは実行記録として意味を持つ。push 済み履歴は書き換えず force-push を伴う rebase は行わない。まとめ方の具体は squash merge に祖先関係が記録されない副作用があるため検証を伴い、PJR-199G で確定する。PJR-TPY9 の完了後に有効となる。 | pjr-t7zq-register-commit-policy | - |
| PJR-V23P | decided | src を機能ごとのサブディレクトリに分ける | リファクタリング（prj-0001:pjr-y8p9-large-source-files-split など）で大きなファイルを分けた結果、src/ の直下のファイルは 167 になった（2026-10-16）。ファイル名の接頭辞が実質的にディレクトリの代わりになっている。 | decision | medium | ARC | 2026-10-16 | - | 2026-10-16 | src を機能ごとのサブディレクトリ（exec・register・grade・catalog・schedule・dashboard・job・routine・kata・deliverable・devcontainer・review・docs と共通の shared）へ移し、ディレクトリと重なる接頭辞を外す。移動は codemod で 1 件ずつ行い、依存の向きの規則は移した後に入れる | pjr-v23p-src-subdirectory-layout | - |
| PJR-V2W5 | decided | kata を新しく作る approach の名前と仕組みを決める | register の approach では、既存の kata を直すことと、成果物と kata を一組で作ること（bootstrap）はできるが、既存の成果物から新しい kata を起こすことと、kata だけを新しく作ることができない。approach の名前、対象の指定、利用者のリポジトリでの新しい kata の置き場所と id、カタログの参照の付け替えを決める | decision | medium | ARC | 2026-10-22 | _TODO_ | 2026-10-22 | kata を新しく作る approach を rulebook-authoring など 4 つとし、--target の 1 つ目に新しい kata の id、2 つ目以降に手本の成果物を書く。利用者の kata は specdojo: 以外のリポジトリ単位の名前空間とし、カタログの undecided の参照は同じ実行で付け替える | pjr-v2w5-kata-authoring-approach | - |
| PJR-VV3M | decided | 実践の型は種別ごとに作成方針を変える | PJR-QESV は4種すべてを機械的に作らず要否を判断すると定めたが、種別ごとの性質の違いを扱っていない。PJR-K4TA の宣言結果を確認したところ、4種を同じ枠組みで判断させた結果、未作成の成果物171件が根拠のないまま not-needed となった。種別ごとに判断の前提条件が異なることを踏まえ、判断の枠組みを具体化する。 | decision | high | BA | 2026-08-23 | 2026-08-31 | 2026-08-26 | 種別ごとに作成方針を変える方針を実装まで完了した。sample は rulebook がある系統へ一律に作り要否を判断しない。template は rulebook 系統単位で持ち骨組みが固定の系統に作る。recipe は品質差が出る系統のみ他の型と独立して判断する。rulebook は従来どおり判断して作る。sample を作らない条件は構造が schema で完全に決まる YAML 成果物に限定した。実装は PJR-JT1Y でガイドへ反映、PJR-1Z1H で宣言の欠落を解消、PJR-K9KG で実在成果物の要否を確定、PJR-5N64 で template の解決と代表系統の整備を行った。宣言先は PJR-3N21 の決定により rulebook frontmatter へ一本化されている。 | pjr-vv3m-kata-creation-policy-by-type | - |
| PJR-WA3R | decided | exec の plan の共通の規約を本文への差し込みから参照へ改める | exec の plan は、共通の規約（記法・成果物規約）を docs/ja/specdojo/templates/ の断片から作るたびに本文へ差し込む（injectCommonConventions）。差し込みにしたのは、agent に plan の本文が標準入力で渡されるだけで、.github/instructions/ は Claude・Copilot にしか届かないため、どの agent にも確実に届くのが plan の本文だけだったからである。 | decision | medium | ARC | 2026-10-17 | - | 2026-10-17 | plan の本文には異常終了の条件と共通の規約の要点だけを残し、詳細は worktree から読める別ファイルを参照させる | pjr-wa3r-exec-plan-common-conventions-reference | - |
| PJR-WVNS | decided | 計画成果物をカタログへ載せ、専用の planning ドメインとトラックで所有する | timeline、dct-index、dct-plan、sch-assessment、sch-strategy、sch-track の一部がカタログ未登録で、Schedule に載っていない。トラックのスコープはドメイン単位でしか絞れず、また sch-track-X は sch-strategy-X から生成されるため、あるトラックの計画物を同じトラック自身で生成することはできない。計画物の所有トラック、カタログへの登録範囲、トラック別ファイルの粒度を決める。 | decision | high | ARC | 2026-08-22 | 2026-08-31 | 2026-08-22 | 計画成果物は新設の planning ドメインと planning トラックが所有する。人や agent が判断して書く入力は work、sch-track と sch-milestones は generated として登録し、dct-<domain>.yaml と表示用生成物は登録しない。トラック別ファイルは具体的な local_id で個別登録し、着手時に追加する。planning 自身の strategy は control として循環を避ける。実装は PJR-QF7T で完了した。 | pjr-wvns-planning-artifacts-catalog-scope | - |
| PJR-ZDVQ | decided | プロダクトリポジトリのブランチ戦略を SpecDojo は求めない | 別リポジトリ構成で、SpecDojo はプロダクトリポジトリにブランチ戦略を求めず、プロダクト側のルール（GitHub flow・git flow など）で決めた統合先だけを受け取る。merge の方式は問わず、追跡は SHA ではなく trace key（Refs:）を主にする | decision | medium | BA | 2026-10-12 | 2026-10-31 | 2026-10-12 | 選択肢 B。プロダクトリポジトリにブランチ戦略を求めず、プロダクト側のルールで決めた統合先だけを受け取る。merge の方式は問わず、追跡は trace key（Refs:）を主にする。ガイドへの節の追加と、足りない機能 2 つは派生項目で扱う | pjr-zdvq-product-repo-branch-strategy | - |
| PJR-ZM1K | decided | agent の名簿を model と役割の実体と別名の 2 段構成にする | .specdojo/agent-members.yaml には 37 の member があり、名前は provider と格と役割（claude-expert-executor など）で付けている。model の指定は provider ごとに次の場所へ分散している（2026-10-15 時点）。 | decision | medium | ARC | 2026-10-15 | - | 2026-10-15 | agent の名簿を、provider・model・effort・役割を持つ実体（opus-executor など、model の系統で命名）と、実体を指す別名（今の名前を残す）の 2 段構成にする。0.4.0 の対象とし、Y8P9 の完了後に実装する | pjr-zm1k-agent-members-model-alias | - |