台帳ビュー（担当者別）
このファイルは各
pjr-XXXX-<topic>.md（個票）から生成された派生ビューです。正本は個票の Frontmatter であり、このファイルは再生成可能です。
1. 担当者別
1.1. ARC
| ID | ステータス | タイトル | 説明 | 分類 | 優先度 | 担当 | 登録日 | 期限 | 完了日 | 結論 | 個票 | depends_on |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PJR-JR2Z | done | tsd-ollama-opencode の接続確認の例で考える過程を止める | 接続確認の例に reasoning_effort: none を足し、本文が返ることを期待値として書く。tsd-ollama の確認の例も同じかを確かめる | todo | low | ARC | 2026-10-31 | _TODO_ | 2026-10-31 | tsd-ollama-opencode の接続確認の例に reasoning_effort: none を足し、期待する結果と、付けないと本文が空になりうることを書いた。tsd-ollama の確認の例は OpenAI 互換の API ではないため変えていない | pjr-jr2z-ollama-check-reasoning-off | PJR-AHXK |
| PJR-05GN | done | tsd-recipe を作る | 見直した tsd-rulebook に沿って、技術領域ごとの TSD を書く手順を recipe にする。 | todo | medium | ARC | 2026-10-27 | _TODO_ | 2026-10-27 | tsd-recipe を作成し、tsd-rulebook の recipe に宣言した。template は作らない | pjr-05gn-tsd-recipe-authoring | - |
| PJR-9SXH | done | tsd-index-sample を新しい tsd-index-rulebook に合わせて見直す | tsd-index-sample を、見直した tsd-index-rulebook の技術スタック一覧の列（区分、採用技術、担当責務、版・正本、適用範囲）と参照の要件に合わせて見直す。 | todo | medium | ARC | 2026-10-27 | _TODO_ | 2026-10-27 | tsd-index-sample を新しい tsd-index-rulebook に合わせ、tsd-sample の題材を PostgreSQL の詳細定義に決めた | pjr-9sxh-tsd-index-sample-maintenance | - |
| PJR-AHXK | done | tsd-ollama-opencode のモデルのタグの食い違いを直す | tsd-ollama-opencode は設定例で gemma4:e4b-mlx-light-8k を登録する一方、接続確認の要求では gemma4:e4b-light-8k を使っている。対象環境での正しい登録名を確かめ、どちらかに揃える。 | todo | low | ARC | 2026-10-27 | _TODO_ | 2026-10-31 | 軽作業用の 8k のモデル名を MLX 版の gemma4:e4b-mlx-light-8k にそろえ、tsd-ollama-opencode の接続確認の例を直した。母艦では利用者が同名のモデルを作成した | pjr-ahxk-tsd-ollama-opencode-model-tag | - |
| PJR-EVAE | done | tsd-sample を新しい tsd-rulebook に合わせて見直す | tsd-sample は技術の一覧を並べる初期の作りのままで、見直した tsd-rulebook の技術領域ごとの詳細定義（構成、採用設定、導入、動作確認、継続利用）と合っていない。rulebook に沿った完成例に作り直す。 | todo | medium | ARC | 2026-10-27 | _TODO_ | 2026-10-27 | tsd-sample を PostgreSQL / Prisma の詳細定義の完成例に作り直した | pjr-evae-tsd-sample-maintenance | - |
| 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-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-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-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-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-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-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-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-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 | - |
| PJR-VQZA | done | 定期実行の出力を実行後に commit する | routine が起動する Job（grade など）は本体の作業場所で出力を作るが commit せず、人や orchestrator が後から手で記録している。実行後に出力を commit する仕組みを、ブランチを切る方式と統合先へ直接 commit する方式を比較して決め、実装する | todo | medium | ARC | 2026-10-12 | 2026-10-31 | 2026-10-12 | routine が起動する Job Run を worktree で実行し、runner の commit・review・verdict による統合を経る流れを入れた | pjr-vqza-routine-commit-after-run | - |
| PJR-N02E | done | Antigravity 経由の claude と GPT が各社直の利用枠と別勘定かを実測する | agy CLI には利用枠を確認するコマンドがないため、Anthropic 直か OpenAI 直の枠を使い切った状態で agy-claude-* / agy-gpt-executor を起動し、実行できるかを確かめる。別勘定なら利用制限で exec が止まったときの退避経路にする。rate limit の文言を観測したら rate_limit_detection へ反映する。 | todo | low | ARC | 2026-10-11 | 2026-10-31 | 2026-10-31 | Antigravity 経由の claude と GPT（gpt-oss-120b）は Google AI のプランの枠で数えられ、Anthropic 直・OpenAI 直の利用枠とは別勘定である。直の枠で止まったときの退避経路に使える | pjr-n02e-antigravity-quota-separation | - |
| PJR-4Y48 | done | orchestrator launch が Ctrl-C で先に終了し provider の CLI が取り残される | specdojo orchestrator launch は SIGINT の既定動作で即座に終了し、Ctrl-C を入力の取り消しに使う claude や codex の CLI だけが動き続けて端末の操作が壊れる。子の実行中は SIGINT/SIGQUIT を無視し、SIGTERM/SIGHUP を転送する。 | issue | high | ARC | 2026-10-10 | 2026-10-31 | 2026-10-10 | orchestrator launch は子の実行中に SIGINT/SIGQUIT を無視し、SIGTERM/SIGHUP を子へ転送する。終了コードは子の終了コード、シグナル終了なら 128 + シグナル番号。子の終了後にハンドラを外す。偽の provider で、SIGINT では子の正常終了まで待ち（code 0）、SIGTERM では転送して 143 で終わることを確認した。 | pjr-4y48-orchestrator-launch-signal | - |
| PJR-P08H | done | devcontainer scaffold が親ディレクトリをマウントせずプロダクトリポジトリが見えない | templates/devcontainer/devcontainer.json に workspaceMount が無く、生成したコンテナからは app1-specdojo/ しか見えない。../app1 と ../app1-specdojo-worktrees を使えるよう、親ディレクトリをマウントする。 | issue | high | ARC | 2026-10-10 | 2026-10-31 | 2026-10-10 | devcontainer scaffold が親ディレクトリを /workspaces/specdojo-workspace へマウントし、workspaceFolder をプロジェクトリポジトリへ向けるようにした。post-create は親配下を safe.directory（<親>/*、Git 2.46 以降で有効。テンプレートの typescript-node:22 は trixie で満たす）へ登録する。unit test と command-reference・remote-host-development-guide・CHANGELOG を更新した。 | pjr-p08h-devcontainer-parent-mount | - |
| PJR-ZGJ4 | done | orchestrator の起動に宣言済みのプロダクトリポジトリへのアクセスを付ける | orch:* の起動コマンドは repos を読まないため、orchestrator から app1/ を参照・変更できない。exec と同じく宣言済みのリポジトリだけを provider ごとの方法で許可する。 | issue | high | ARC | 2026-10-10 | 2026-10-31 | 2026-10-10 | specdojo orchestrator launch を追加し、orch:* を経由させた。repos に宣言したリポジトリ本体だけを exec と同じ規則（agentExtraRootArguments）で許可し、opencode は OPENCODE_CONFIG_CONTENT で external_directory と edit を注入する（agent 定義の規則は残ることを opencode debug agent で確認）。シグナル処理は PJR-4Y48 で修正。orchestrator 本文に宣言済みリポジトリの扱いを加えた（60b57173f）。 | pjr-zgj4-orchestrator-product-repo-access | - |
| 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-WPR3 | done | exec-run.ts の分割方針の調査と選択肢の比較 | exec-run.ts の関数・依存・初回と再開の重複を調べ、モジュールの境界と状態遷移の選択肢と推奨案を exec-run.ts の分割方針の決定の個票へ書く。決定はしない（v0.3.0 の公開後） | todo | medium | ARC | 2026-10-02 | _TODO_ | 2026-10-08 | exec-run.ts の関数の分類・依存・重複・状態遷移を調べ、3 案を PJR-Q761 で比較した。利用者が選択肢 C を選んだ | pjr-wpr3-exec-run-split-investigation | - |
| 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-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-FZC4 | done | 複数リポジトリ対応の調査と選択肢の比較 | PJR-5822 の決定に必要な調査として、現行実装の変更箇所を一覧にし、論点ごとの選択肢と推奨案を PJR-5822 の個票に書く。決定はしない（v0.3.0） | todo | high | ARC | 2026-10-01 | _TODO_ | 2026-10-01 | 現行実装の変更箇所を一覧にし、10 の論点の選択肢と推奨案を PJR-5822 に記録した | pjr-fzc4-multi-repo-design-investigation | - |
| PJR-B7DG | done | rulebook から削除した例が sample に含まれるかの確認と grade による比較 | PJR-GWYJ で 52 件の rulebook から削除したサンプル章の要点が既存の sample に含まれるかを確かめ、欠けるものだけを反映する。外出しの前後を grade で比べ、vp-qe-kata-conformance と vp-arc-conciseness の finding を記録する | todo | medium | ARC | 2026-09-30 | _TODO_ | 2026-10-28 | 削除した例の有無を 50 件判定し、欠ける 43 件の rulebook は例を復元した。grade の外出し前後の比較では 2 観点に明確な差はなかった（評価条件は前後で異なる）。雛形の sample の作り直しは PJR-2W38 から必要なときに起票する | pjr-b7dg-rulebook-sample-coverage-check | - |
| PJR-0FK2 | done | config scaffoldに各Agentのパーミッション設定機能を追加 | 現状 npx specdojo config scaffold は orchestrator.md のみを生成するが、各エージェントがスムーズかつ安全に動作するためのパーミッション設定（settings.json 等）も合わせて準備すべきである。 Claude（.claude/）のようにプロジェクトローカルで完結するものは設定ファイルの生成を行い、Antigravity（~/.gemini/）のようにユーザーディレクトリを必要とするものは、既存設定を破壊せずに必要なパーミッション（allow / deny 等）を追記（マージ）する方式で実装する。 | todo | medium | ARC | 2026-09-29 | 2026-10-31 | 2026-09-29 | config scaffold --provider antigravity --global で ~/.gemini/antigravity-cli/settings.json へ permission rule を差分表示・バックアップ付きでマージするようにした。グローバルの allow は読み取りの git コマンドだけに絞った | pjr-0fk2-config-scaffold-agent | - |
| PJR-N8AW | done | オーケストレーターの起票時対話サポート機能の追加 | オーケストレーターを介した register add において、利用者がコマンドの引数（担当や期限など）を正確に把握していなくてもスムーズに起票できるようにする。 orchestrator.md のプロンプトを見直し、「不足している項目があれば推奨値を提示してヒアリングする」「起票後に自動生成される個票の _TODO_ 部分（概要や完了条件）について、会話の文脈から記述案を作成し、利用者の承認を得た上でファイルを自動更新する」といった行動ルールを追加する。 | todo | medium | ARC | 2026-09-29 | 2026-10-31 | 2026-09-29 | 起票の前に会話から項目を読み取り足りないものだけ質問し、担当と期限は推測で埋めない。起票後は _TODO_ の案を会話の事実から作り、承認後に書き込む手順を定義へ加えた | pjr-n8aw-item | - |
| PJR-00QV | done | データストア名へ概念の英語名を併記し cdfd-rulebook の禁止事項に注記を加える | CDFD のデータストア名が日本語のみのため、実装を知る読み手が対応する語を特定できない。実行計画 と plan は同じ概念の日本語名と英語名であり、併記できる。cdfd-rulebook の禁止事項が実装名を禁じているが、概念の英語名はこれに当たらないため、誤解を避ける注記を加える。 | todo | medium | ARC | 2026-09-26 | _TODO_ | 2026-09-26 | - | pjr-00qv-cdfd-rulebook | - |
| PJR-6WFA | done | register 由来の plan へ targets を持たせて対象網羅の検証を効かせる | prj-0001:pjr-1y9p-resume-executor-plan で resume 後の対象網羅の検証を実装したが、register 由来の plan には targets がないため検証が効かない。発端となった prj-0001:pjr-xzeq-cdfd-overview-cdfd-check-cdfd-action-grade-review も register 由来であり、**同じ事象が再発しても検出できない。** | todo | medium | ARC | 2026-09-26 | _TODO_ | 2026-09-26 | - | pjr-6wfa-register-plan-targets | - |
| PJR-8TEN | done | bps-sample を実例として作り直し bps-template と bps-recipe を整備する | bps-sample.md は grade で fail（61 点、blocker 1 件）である。業務プロセスの実例ではなく「サンプルの構成を説明するメタ文書」になっており、sample として機能していない。prj-0001:pjr-t3nn-bps-rulebook-rulebook-authoring-standard で rulebook を確定した後、sample を実例として作り直し、あわせて template と recipe の要否を決めて整備する。 | todo | high | ARC | 2026-09-26 | _TODO_ | 2026-09-26 | - | pjr-8ten-bps-sample-bps-template-bps-recipe | - |
| PJR-AG7B | done | 観点の適用範囲を文書の種類で宣言し check の場当たり的な除外条件を移す | 観点がどの種類の文書に当てはまるかを宣言する仕組みがなく、観点側が check の文面へ場当たり的に除外条件を書き込んで補っている。grade_targets（kata / deliverable の 2 値）を文書の種類へ細かく分け、除外条件を宣言へ移す。prj-0001:pjr-k351-continuous-abolition-all-viewpoints で 28 観点へ広げる前提である。 | todo | high | ARC | 2026-09-26 | _TODO_ | 2026-09-26 | - | pjr-ag7b-viewpoint-applicability-by-document-kind | - |
| PJR-AY1R | done | fully-guided が sample を参照できるようにし rulebook のサンプル章を外出しする | 完成例の正本を sample に一本化する方針を rulebook-authoring-standard.md へ明記した。実現には xep-fully-guided-template.md の参照範囲を変える必要がある。現在 fully-guided は sample を読み込まないため、rulebook から サンプル 章を外すと例が参照できなくなる。参照範囲を変えたうえで、既存 rulebook の サンプル 章を一括で外出しする。 | todo | medium | ARC | 2026-09-26 | _TODO_ | 2026-09-29 | 第 1 段を完了した。fully-guided の plan が sample を参照できるようにし（recipe-guided は対象外）、bps・stsd のサンプル章を外出しした。試行の grade で finding の悪化はなかった。残りは PJR-GWYJ | pjr-ay1r-fully-guided-sample-rulebook | - |
| PJR-BB92 | done | cdfd-overview の変更を下位 CDFD へ追従させる | 1d735942 で cdfd-overview.md の Do へ Schedule（track） を加え、Schedule（track）がタスクの状態を持たないと訂正した。どちらも実装と一致するが、**下位の CDFD へ反映していなかった。** prj-0001:pjr-f1jg-cdfd-overview-runner-qe の grade で cdfd-overview の major として検出された。cdfd-rulebook は全体概要を名称と区分の正本とするため、下位を追従させる。 | todo | high | ARC | 2026-09-26 | _TODO_ | 2026-09-27 | - | pjr-bb92-cdfd-overview-propagation | - |
| PJR-F1JG | done | cdfd-overview の評価結果の確定者を runner から QE へ戻す | cdfd-overview.md の Check 概要が「runner が grade・finding を確定する」と記述しており、cdfd-check.md（QE が確定）、cdfd-uc-deliverable.md と cdfd-uc-register.md（QE が確定）、bps-deliverable-evaluation（S-03 担当 QE）と矛盾する。prj-0001:pjr-xzeq-cdfd-overview-cdfd-check-cdfd-action-grade-review の変更で評価の**実行者**と**確定者**を混同したことが原因である。cdfd-overview.md の 1 文を修正する。 | todo | high | ARC | 2026-09-26 | _TODO_ | 2026-09-26 | - | pjr-f1jg-cdfd-overview-runner-qe | - |
| PJR-T3NN | done | bps-rulebook を rulebook-authoring-standard 準拠で作り直す | bps-rulebook.md は 2026-08-24 が最終更新で、現行の rulebook-authoring-standard.md に準拠していない。章構成、埋め込みサンプルの Frontmatter 形式、見出し番号の書式が規約と食い違う。部分修正では sample の作り直しと絡み合うため、**bootstrap 相当で作り直す**。 | todo | high | ARC | 2026-09-26 | _TODO_ | 2026-09-26 | - | pjr-t3nn-bps-rulebook-rulebook-authoring-standard | - |
| PJR-XZEQ | done | cdfd-overview と cdfd-check と cdfd-action へ grade と review の関係を反映する | prj-0001:pjr-h4h7-bps-grade-review で作成した BPS 2 件が設計の正本になった。cdfd-check.md は「review から独立して」と記述しており、BPS の「grade を事実として受け取る」と矛盾する。cdfd-overview.md は review phase の所属を示していない。CDFD 3 本を BPS へ整合させる。 | todo | high | ARC | 2026-09-26 | _TODO_ | 2026-09-26 | - | pjr-xzeq-cdfd-overview-cdfd-check-cdfd-action-grade-review | - |
| PJR-DKX8 | done | vp-arc-conciseness と vp-ux-user-flow の check へ判定規準を書き込む | vp-arc-conciseness と vp-ux-user-flow は、prj-0001:pjr-wpwb-viewpoint-evaluation-criteria の基準で discretionary（判定者が規準を持ち込む）に分類される。check に判定規準を書き込めば referential（参照との照合）へ移せる。同じ扱いの vp-arc-single-responsibility と vp-ux-readability が先例になる。 | todo | medium | ARC | 2026-09-25 | _TODO_ | 2026-09-27 | - | pjr-dkx8-vp-arc-conciseness-vp-ux-user-flow-check | - |
| PJR-EBTZ | done | vp-arc-cross-document-consistency の突き合わせ先を target 別に絞り kata-conformance との境界を定める | vp-arc-cross-document-consistency は grade_targets を指定していないため、kata と成果物の両方へ 6 つの突き合わせ先（成果物カタログ、Schedule、RACI、組織定義、メンバー定義、生成物）を宣言している。grade 対象の 86% は kata であり、**kata はカタログに 1 件も登録されていない**。宣言した突き合わせ先が適用できないため、agent は判定対象を kata 内部の整合へ差し替えており、vp-qe-kata-conformance と重複している。 | todo | high | ARC | 2026-09-25 | _TODO_ | 2026-09-26 | - | pjr-ebtz-vp-arc-cross-document-consistency-target-kata-conformance | - |
| PJR-K351 | done | continuous を廃止し 28 観点すべてを grade の対象にする | continuous を廃止し、28 観点すべてを grade の対象にする。grade と review が同じ観点集合を見るという prj-0001:pjr-2zvs-grade-review-integration の最終結論を実装する。rubric の重みを 4 category から 9 category へ広げるため、**既存の score がすべて変わる**。一度しか起こせない変更なので、観点定義を安定させてから行う。 | todo | high | ARC | 2026-09-25 | _TODO_ | 2026-09-27 | continuous を廃止し 28 観点を grade の対象にした。rubric を v2（9 category）とし pass_score を 75 に改めた。旧形式はエラーで拒否する。標本の試行で既存 finding の質の低下はなかった | pjr-k351-continuous-abolition-all-viewpoints | - |
| PJR-WPWB | done | 観点の evaluation の区分基準を定義し、名前と割り当てを揃える | viewpoint の evaluation（deterministic / agent / human）は、**軸が混在し、値の名前が実態と合っていない**。区分の基準そのものが文書化されていないため、基準の定義・命名・現在の割り当ての再確認を一体で行う。 | todo | high | ARC | 2026-09-25 | 2026-10-31 | 2026-09-27 | evaluation を deterministic / referential / discretionary（判定規準の所在）へ改名し 7 観点を再分類した。grade は referential と discretionary を agent で判定し、continuousViewpoints から human 条件を外した。旧値は新値を示すエラーで失敗する。版は据え置き | pjr-wpwb-viewpoint-evaluation-criteria | - |
| PJR-D4KG | open | 文書へ owner または RACI を宣言させるかを決める | schedule を持たない最小構成では review の観点セットを選ぶ根拠が無く、文書の責任者も schedule の owner_rules を辿らないと分からない。frontmatter へ owner を持たせる案と RACI を持たせる案があるが、pm-raci.yaml との二重管理をどう避けるかという論点が生じる。grade の判定軸としては不要であることが PJR-2ZVS の見直しで判明しているため、review と可読性の観点だけで判断する。 | question | low | ARC | 2026-09-24 | 2026-11-14 | - | - | pjr-d4kg-document-owner-declaration | - |
| 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-Q3W9 | open | Gas Town との設計思想の対比と理解の負債 | 競合比較（prj-0001:pjr-36qg-competitive-landscape-and-release）は機能の対応を扱う。本 note は設計思想の対比と、そこから生じる「理解の負債」という論点を記録する。位置づけの判断（prj-0001:pjr-e8tt-initial-release-positioning）を見直すときの材料とする。 | note | medium | ARC | 2026-09-24 | _TODO_ | - | - | pjr-q3w9-gastown-design-philosophy | - |
| PJR-TD1G | decided | grade と review の記録構造を統合するかを決める | 観点別の判定を grade は sidecar の YAML（level / score / findings）、review は result の Markdown（result / evidence / notes）で持ち、同じ関心を別形式で記録している。findings も grade は構造化、review は自由記述で集計できない。done_criteria の判定も grade の criteria ファイルと review の観点表で二重に行う。統合すれば集計と追跡が揃うが、review result が人の読む Markdown であることの価値を失う可能性がある。語彙の統一（PJR-XXXX）とは切り離して判断する。 | question | medium | ARC | 2026-09-24 | 2026-11-21 | 2026-09-26 | 統合しない。grade は成果物の品質、review はタスクの完了可否という別の対象を判定し、review は観点ごとの記録を持たなくなるため、記録構造を揃える必要がない。 | pjr-td1g-grade-review-record-structure | - |
| PJR-06RE | done | kata 保守タスクへ review フェーズを追加する | PJR-2ZVS の決定のうち schedule 経路を実装する。sch-strategy-launch.yaml の recipe-consolidate / rulebook-consolidate / sample-consolidate / template-consolidate へ review フェーズを追加し、既存の xrp-*-maintenance テンプレートを使う。owner ロールは各 edit タスクの owner を踏襲し、観点セットに vp-qe-kata-conformance を必ず含める。 | todo | medium | ARC | 2026-09-23 | 2026-11-14 | 2026-09-27 | sch-strategy-launch の recipe/rulebook/sample/template-consolidate へ review フェーズを追加し、schedule build で 14 成果物×4 の review タスク 56 件を生成した。owner は edit タスクを踏襲 | pjr-06re-kata-maintenance-review-phase | - |
| 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-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-F4C9 | decided | npm の公開を staged publishing へ戻すかを決める | 0.2.0 の公開時に trusted publisher の Allowed actions で直接 publish を許可したが、npm は stage-only を推奨している。staged publishing では CI が npm stage publish で保留状態に登録し、maintainer が 2FA 付きで承認して初めて公開される。agent が src を書く本プロジェクトでは公開直前の確認段が有効に働く可能性がある一方、リリースごとに承認操作が増える。次のリリース前に判断する。 | question | medium | ARC | 2026-09-23 | 2026-10-24 | 2026-09-24 | 候補 B を採り stage-only へ戻した。workflow を npm stage publish へ変更し、npm CLI 11.15.0 以上の確保と承認手順の表示を加えた。npm 側の Allowed actions の変更は人が行う。 | pjr-f4c9-npm-staged-publishing | - |
| 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-FRZB | open | CLI の入口を短くする方法を決める | npx specdojo は打鍵が長い。短い bin 名（sd など）の配布、gradlew 型の wrapper スクリプト、文書での alias / PATH 案内のいずれを採るかを決める。sd は npm に別パッケージが登録済みで、未導入ディレクトリでの npx sd が無関係なパッケージを取得する危険と、Rust 製 sd を黙って置き換える問題がある。 | question | low | ARC | 2026-09-23 | 2026-10-31 | - | - | pjr-frzb-cli-entrypoint-shortcut | - |
| PJR-ME20 | done | Antigravity と codex を trial で比較し agy member の priority / proficiency を確定する | PJR-2T2S で Antigravity CLI（agy）を provider として追加したが、pm-members.yaml の agy-* member の priority（3〜4）と proficiency は暫定値のままで、自動選択では選ばれない。同一 plan を codex と並走させて実測し、確定させる。 | todo | medium | ARC | 2026-09-23 | 2026-10-17 | 2026-10-11 | 同一 plan（PJR-ZGJ4）の exec trial で agy-expert は親検証 3 種に失敗（codex-expert は 7 種通過、690 秒対 838 秒）し、未実行のテストを通過と報告した。agy-* の priority・proficiency は据え置き、自動選択の対象に加えない。rate limit の文言は未観測。利用枠の別勘定の実測は PJR-N02E へ切り出した。 | pjr-me20-antigravity-codex-trial | - |
| PJR-2T2S | done | Antigravity CLI（agy）を executor / reporter の provider として使えるようにする | この 1 週間で codex は 3 回、claude は 1 回、利用制限で exec が止まった。devcontainer に導入した Antigravity CLI（agy 1.2.7、認証は ~/.gemini ボリュームで永続化済み）を第 3 の frontier 経路として SpecDojo の executor / reporter に組み込み、by-name（PJR-7WFE）で枠を割り当てられるようにする。 | todo | high | ARC | 2026-09-21 | 2026-10-05 | 2026-09-23 | Antigravity CLI（agy）を provider として追加し、Gemini に加え claude / GPT モデルも by_nickname で指名できるようにした。作業 4（codex との trial 比較）は別途実施する。 | pjr-2t2s-antigravity-provider | - |
| PJR-YM9Y | done | mermaid rulebook 2 本と cdfd / stsd sample の grade 指摘を解消する | PJR-EQDB の再周回後の評価（MANUAL-eqdb6-20260921b、codex 単段）で cdfd-rulebook 89 と stsd-rulebook 86 は pass になったが、改訂で派生した指摘が 4 件に残った。finding は docs/ja/projects/prj-0001/execution/grade/results/specdojo.<id>.yaml にある。 | todo | medium | ARC | 2026-09-21 | 2026-10-10 | 2026-09-22 | - | pjr-ym9y-kata-mermaid-sample-findings | - |
| PJR-TBHH | done | 利用プロジェクトの既定構成を Detached Unit にする | prj-0001 の実測では、2026-09-13 以降の 253 commit のうち exec の記帳（register の遷移、prepare / apply、merge）が 182 件（72%）を占めた。これは SpecDojo の仕組み上の性質であり、利用プロジェクトでも同じ比率になる。プロダクトの Git 履歴が記帳で埋まるのは、SpecDojo を導入する代償として大きすぎる。 | todo | medium | ARC | 2026-09-20 | 2026-09-30 | 2026-09-21 | - | pjr-tbhh-detached-unit-default | - |
| PJR-XKKS | done | grade の結果と finding を成果物から切り離しサイドカーへ移す | grade は成果物の frontmatter（specdojo.grade: verdict / score / viewpoints / content_hash / findings 件数）と本文（<!-- specdojo:finding … -->）に評価を書き込む。この設計が次の問題を生んでいる。 | todo | high | ARC | 2026-09-20 | 2026-09-30 | 2026-09-21 | - | pjr-xkks-grade-sidecar | - |
| PJR-Y013 | done | exec の記帳 commit を merge commit に畳み develop の本線を 1 タスク 1 commit にする | 2026-09-13 以降の develop の 253 commit のうち、exec の記帳が 182 件（72%）を占める。register 1 件の worktree 実行で、develop の第一親線に次の 5〜6 commit が並ぶ。 | todo | medium | ARC | 2026-09-20 | 2026-09-30 | 2026-09-21 | - | pjr-y013-exec-commit-folding | - |
| PJR-7WFE | done | Schedule の phase に agent の by-name 指定を追加する | Schedule（sch-strategy-<track>.yaml）の phase は agent_pipeline.stages[].proficiency と capability による自動選択だけで agent を決めており、nickname を埋め込まない設計になっている。自動選択は「条件を満たす agent を priority 順に選ぶ」だけで、provider ごとの利用制限（rate limit）の枠を計画できない。実際に次の状況が起きている。 | todo | medium | ARC | 2026-09-18 | 2026-09-30 | 2026-09-19 | - | pjr-7wfe-schedule-agent-by-name | - |
| PJR-W5JT | done | grade を codex 単段にし定期実行を夜間へ寄せる | grade は gemma（1・2 段）→ codex-expert（3 段、1・2 段が pass かつ 96 点以上のときだけ）の 3 段構成で運用してきたが、実測で 1・2 段目が門番として機能していない。 | todo | high | ARC | 2026-09-18 | 2026-09-25 | 2026-09-21 | - | pjr-w5jt-grade-single-stage-nightly | - |
| PJR-EQDB | done | cdfd-rulebook と stsd 系 rulebook の grade 指摘を解消する | PJR-ZA91（STSD/CSTD 統合）で変更した Kata を 16 時の定期評価 rtn-grade-recheck（JBR-grade-kata-8a8333596f2e、3 段目 codex-expert）で評価した結果、rulebook 3 件が needs-work となった。recipe 4 件（96〜100）と cdfd-uc-rulebook（84）、cdfd-overview-rulebook（84）は本 todo の対象外とする。 | todo | medium | ARC | 2026-09-17 | 2026-09-30 | 2026-09-21 | - | pjr-eqdb-kata-cdfd-stsd-rulebook-findings | - |
| PJR-JSWE | open | agent ワークフローを plan/result/git に置き skills 等の agent 固有機能へ依存しない方針の分析 | _TODO_ | note | low | ARC | 2026-09-17 | - | - | - | pjr-jswe-agent-workflow-plan-vs-skills | - |
| PJR-ZA91 | done | STSD と CSTD を STSD へ統合し状態一覧と状態遷移図を 1 文書で扱う | ステータス定義（STSD）と概念状態遷移図（CSTD）は、どちらも「1 対象 = 1 ファイル」で常に 1:1 に対応し、CSTD の必須章「状態の説明」が STSD の状態定義と重複している。分けたままでは片方が空洞化するか二重管理になるため、状態一覧と状態遷移図を STSD 1 文書で扱う形へ統合する。 | todo | medium | ARC | 2026-09-17 | 2026-09-30 | 2026-09-17 | - | pjr-za91-stsd-cstd-merge | - |
| PJR-5KPC | done | grade pipeline 状態の同一性判定が grade 自身の finding 挿入で崩れる | PJR-0W8S の pipeline 状態は content_hash（stableContentHash）の一致で有効性を判定するが、grade apply は段ごとに finding コメントを除去して挿入し直し、ブロック直前に空行を補うため、finding を除いた本文でも空行の位置と数が段の間で変わる。手動起動した成果物評価で cdfd-action の 2 段目が「stage 2 must immediately follow completed stage 0」で失敗し Job Run 全体が失敗した。pipeline 状態のハッシュを空行を無視する正規化に変えて解消する。 | todo | high | ARC | 2026-09-16 | 2026-09-30 | 2026-09-19 | - | pjr-5kpc-grade-pipeline-hash-blank-lines | - |
| PJR-05GC | done | exec plan の depends_on / targets の doc id を成果物の配置に応じて解決する | src/exec-plans.ts は depends_on と targets の doc id を常に <project-id>:<local_id> で組み立てるが、id-and-file-naming-standard ではプロダクト文書（docs/ja/product/）はローカル ID、プロジェクト文書は <project-id>:<local-id> である。product 配下の 17 文書はすべて修飾なしのため、cdfd-action など product 成果物の plan では depends_on の [[prj-0001:cdfd-overview]] が索引で解決できず executor にパスが渡らない。plan frontmatter の targets も作成される文書の ID と食い違う。旧 cdfd 10 件だけが標準に反して修飾付きだったため表面化していなかった。カタログの解決済みパスから frontmatter の id を読むか、配置で修飾の有無を決めて解決する。 | todo | high | ARC | 2026-09-15 | 2026-09-30 | 2026-09-16 | exec plan の depends_on と targets の doc id を、カタログの解決済みパスと配置（product はローカル ID、project は project 修飾）から解決するようにした。data-flow-pdca の author タスクで Unresolved ID reference が消え、targets が cdfd-action、project 文書の plan では prj-0001:dct-index になることを確認した。 | pjr-05gc-exec-plan-doc-id-qualification | - |
| PJR-19HX | done | reporter の result が commit 時の prettier で壊れて統合段で block する問題を防ぐ | data-flow-pdca の cdfd-check-010 で、executor・reporter・親検証がすべて成功したのに統合段の commit が失敗して block した。reporter が result に書いた文に、インラインコードで囲まれていない depends_on（_ を含む識別子）と _TODO_/_ASSUMPTION_ が同居し、commit 時の prettier が _on から _TODO までを強調と解釈して \_TODO*/_ASSUMPTION_ に書き換え、markdownlint の MD049 で pre-commit が失敗した。prettier には強調の正規化を止めるオプションが無い。履歴ファイル（exec の result・plan）を .prettierignore で整形対象から外し、markdownlint は残す。あわせて reporter・executor の指示に「_ を含む識別子はインラインコードで囲む」を加え、runner が commit の前に markdownlint を実行して明確な理由で止めるようにする。 | todo | high | ARC | 2026-09-15 | 2026-09-30 | 2026-09-16 | .prettierignore で exec の plan・result を整形対象から外し、executor・reporter の指示に識別子のインラインコード化を加え、runner が commit 前に result の markdownlint を実行して記法違反として block するようにした。副作用として露出した生成 plan の行末空白（MD009）と result の末尾改行不足（MD047）は、expandTemplate と事前検査の空白正規化で orchestrator が直接解消した。data-flow-pdca の author 8 件で運用を確認した。 | pjr-19hx-result-prettier-emphasis-mangling | - |
| PJR-J3G0 | done | Schedule タスクの統合段だけを再開できるようにする | worktree で実行した Schedule タスクが executor・reporter 成功後の commit・merge で失敗して block した場合、register 項目の --resume にある統合段の再開に相当する経路が無い。exec resume --task は executor を再実行しようとするため、cdfd-check-010 では exec worktree commit / merge / remove と exec complete を手で順に実行して回復した。pipeline-state.json の executor・reporter が succeeded なら agent を起動せず統合だけを行う再開を exec resume に追加し、統合段の状態を Schedule タスクの pipeline-state にも記録する。 | todo | medium | ARC | 2026-09-15 | 2026-09-30 | 2026-09-20 | - | pjr-j3g0-exec-resume-integrate-schedule-task | - |
| PJR-VEQ4 | done | evidence_refs の陳腐化を refactor 側の commit で検知し、参照を安定した入口に寄せる | 成果物カタログの evidence_refs は src/ 配下の 69 ファイルを指しており、refactor で rename・削除されると陳腐化する。catalog validate は存在しないパスをエラーにするが、pre-commit hook の catalog-validate は glob が docs/ja/projects/** のため src だけを変える commit では走らず、CI にも含まれていない。hook の glob に src/**、tools/**、packages/** を加え、CI に validate:catalog を入れて refactor 側で検知する。あわせて dct-rulebook の evidence_refs 規約に「コマンドの入口や責務単位のディレクトリを指し、内部ヘルパーは指さない」を追記し、既存参照を見直す。 | todo | medium | ARC | 2026-09-15 | 2026-09-30 | 2026-09-16 | lefthook の catalog-validate の glob に src/**・tools/**・packages/** を加え、CI に validate:catalog を入れて evidence_refs の陳腐化を refactor 側の commit で検知するようにした。dct-rulebook の evidence_refs 規約に入口・責務単位を指し内部ヘルパーを指さない指針を追記し、既存カタログの参照を見直した。 | pjr-veq4-evidence-refs-staleness-detection | - |
| PJR-0W8S | done | grade の段が失敗した文書を次回の定期再評価で失敗した段から再試行する | run-per-document.sh は同じ --run-id での再実行なら失敗した段から再開できるが、定期再評価は毎回新しい Job Run になるため、失敗した段は引き継がれない。段が失敗すると直前の段の判定が content_hash 付きで残り、内容が変わらない限り --changed-only でも --ungraded でも再選択されないため、codex の 3 段目だけが拒否された文書は gemma の判定のまま確定する。9/14 0 時の run では 10 件中 4 件で段が失敗し、cdfd-uc-rulebook と cdfd-mermaid-rulebook が 3 段目未実施のまま pass 100 で残った。段の失敗を文書の評価状態として記録し、次回の選択で拾って失敗した段から再試行する。 | todo | medium | ARC | 2026-09-14 | 2026-09-30 | 2026-09-14 | 段の到達状況を execution/grade/pipeline/<doc>.json（stage_completed / stage_failed / consecutive_failures / max_failures）に記録し、grade list --incomplete と run-per-document.sh --incomplete で失敗した段から再試行するようにした。両 routine の inputs に incomplete を追加し、schema と validate:schema を整備した。実機で昨夜段が失敗した 4 件が --incomplete で選択されることを確認した。 | pjr-0w8s-grade-retry-failed-stage | - |
| PJR-1D5G | done | grade の成果物選択から trash 配下の非推奨文書を除外する | grade list / grade plan の --target deliverable は成果物カタログの全エントリを対象にするため、deliverable trash で docs/ja/product/trash/ へ退避した非推奨文書も評価対象に含まれる。旧領域別 CDFD 10 件を退避して status を deprecated にした際に content_hash がずれ、rtn-grade-deliverable-recheck が退避済み 11 件を再評価対象に選ぶ。catalog-plan.ts の isTrashedPath と同じ判定で trash 配下を選択から除外し、明示的な --path 指定も拒否する。 | todo | high | ARC | 2026-09-14 | 2026-09-30 | 2026-09-14 | isTrashedPath を catalog-paths.ts に共通化し、grade の成果物候補生成から trash 配下を除外、--path での明示指定を拒否するようにした。実機で grade list --target deliverable の trash 件数が 11 から 0 になり、明示指定が trashed documents cannot be graded で拒否されることを確認した。 | pjr-1d5g-grade-exclude-trash | - |
| PJR-AH2P | done | cdfd-overview-rulebook の grade finding 8 件（sample との保管先重複・完成判定の網羅性・用語）を解消する | 9/14 0 時の定期再評価で cdfd-overview-rulebook が needs-work 66 点となった。codex の 3 段目の finding 8 件はいずれも実在する不整合で、(a) rulebook の「保管先は別のデータストアと重ならない」という判定基準を cdfd-overview-sample の「顧客台帳」「つけ台帳」（どちらも常連客ノート）が満たしていない、(b) 完成判定が「他節の条件をここに集約」と宣言しながら Frontmatter 必須キー・導入文・対象者・領域表の必須列・データストアの区分・詳細 CDFD 一覧の列・PO 承認記録を欠く、(c) ノード総数の数え方が rulebook（代表ノード＋データストア）と sample（外部主体を含め 16）で一致しない、(d) STSD / CSTD / PO / retrofit / Orchestrator が定義なしで使われている。rulebook と sample を局所修正して解消する。 | todo | medium | ARC | 2026-09-14 | 2026-09-30 | 2026-09-14 | cdfd-overview-rulebook の finding 8 件と cdfd-overview 本体の finding 4 件を解消した。保管先は物理媒体の共有を注記付きで許す条件を加えて sample を顧客欄・つけ欄に分離、完成判定を 16 項目へ拡充、ノード総数は外部主体を含めないと明記、用語表に STSD / CSTD / retrofit / Orchestrator を追加、参加者由来の入力はエッジ対応の対象外と規定、overview の担当列を Role code 主体で実担当を併記する形に統一した。 | pjr-ah2p-cdfd-overview-rulebook-findings | - |
| PJR-S190 | done | strategy の scope を成果物単位にし、1 ドメインを複数トラックで分担・再修正できるようにする | sch-strategy の scope はカタログファイル単位（catalogs と include_kinds）しかなく、approach_rules と owner_rules は scope 内の全 work 成果物を網羅する必要がある。このため同じカタログを 2 つ目の track に入れると全成果物のタスクが再生成され、事実上 1 ドメイン 1 トラックの運用になる。track-design-guide はドメインとトラックが 1 対 1 でないことを明記しており、実装後に業務仕様を直す・横断パスで複数ドメインを直すといった現実の修正に合わない。scope に成果物（local_id）単位の選択を追加し、rules の網羅要件を選択した部分集合に限定する。 | todo | medium | ARC | 2026-09-14 | 2026-10-31 | 2026-09-14 | sch-strategy の scope.catalogs[] に任意の local_ids を追加し、指定時はその成果物だけを scope として approach_rules / owner_rules の網羅検査とタスク生成を行うようにした。省略時は従来どおり全件。同じ成果物を複数 track が選択でき、track ごとに独立した task ID を持つ。schedule strategy generate も同じ選択に従い、track-design-guide・schedule-design-guide・sch-rulebook に分担・再修正の意味を記述した。 | pjr-s190-strategy-scope-local-ids | - |
| PJR-3J5D | done | grade テストの docs 配下への一時ファイル作成をやめ mermaid プラグインを ENOENT に耐えるようにする | tests/src/grade.test.ts の generated 除外テストが実リポジトリの docs/ja/specdojo/samples/generated/ 配下に一時 Markdown を作成・削除するため、npm test が走るたび（pre-commit hook、exec run の親検証、手動実行）に VitePress dev サーバーの watcher が add を検知し、250 ms 後の mermaid SVG 生成で fs.statSync が ENOENT を投げてプロセスが落ちる。テストは tmpdir で検証できるようにし、mermaid プラグインはファイル単位で例外を捕捉して ENOENT をスキップし、unlink を処理し、generated/ 配下を対象外にする。 | todo | medium | ARC | 2026-09-13 | 2026-09-30 | 2026-09-13 | grade テストの一時ファイルを tmpdir へ移し（discoverGradeTargets のルート注入）、mermaid 生成器は存在しない・generated 配下の Markdown を正常系としてスキップし manifest から除去、VitePress プラグインはファイル単位で例外を捕捉し unlink も処理するようにした。存在しないパスを渡しても例外にならないことと、テスト 50 件の成功を確認した。 | pjr-3j5d-grade-test-tmpdir-mermaid-enoent | - |
| PJR-3KBG | done | grade apply の finding 挿入が prettier-ignore と表を分断し content_hash がずれる | grade apply は finding コメントを指摘行を含む最上位ブロックの直前へ挿入するが、ブロックの直前に <!-- prettier-ignore --> があると、その後ろ（ディレクティブと表の間）に入る。ディレクティブが効かなくなった表は commit 時の lefthook（prettier --write）で整形され、本文が content_hash と食い違って --changed-only で再選択される。成果物評価の 2 回目で評価済みの cdfd-agent-config-operation と cdfd-catalog-planning が再選択されたのはこれが原因で、grade validate でも content changed after the last grade として検出される。finding コメントは直前のディレクティブコメントより前に挿入し、既存の挿入済み文書も整える。 | todo | medium | ARC | 2026-09-13 | 2026-09-30 | 2026-09-13 | insertFindings が finding コメントを対象ブロック直前のディレクティブコメント（prettier-ignore など）より前へ挿入するよう修正し、ディレクティブと表が分断されなくなった。分断していた cdfd 3 件と cdfd-template を整えて content_hash を再計算し、grade validate のずれ 0 件、prettier check 通過を確認した。 | pjr-3kbg-grade-finding-insertion-prettier-ignore | - |
| PJR-4NXR | done | cdfd-rulebook と recipe・sample・template をプロセスグループ別 CDFD へ改訂する | cdfd-overview は詳細 CDFD をプロセスグループ別（cdfd-<group>）とユースケース別（cdfd-uc-<topic>）に再定義したが、cdfd-rulebook / cdfd-recipe / cdfd-sample / cdfd-template は旧来の領域別（1 領域 1 文書、cdfd-<domain>）のままである。cdfd-rulebook をプロセスグループ別 CDFD 専用に改め、章構成と記述レベルを cdfd-overview に合わせて recipe・sample・template を追従させる。状態遷移の正本は stsd / cstd とし CDFD は参照に留める。product 成果物の ID はプロジェクト修飾なしとする。 | todo | medium | ARC | 2026-09-13 | 2026-09-30 | 2026-09-13 | cdfd-rulebook をプロセスグループ別 CDFD 専用へ改訂し、対象プロセス領域章、P-<領域 ID>-<nn> のプロセス ID、cdfd-<group> の命名、データストア一覧との名称一致、グループ外委譲、状態遷移の STSD / CSTD 参照を規定した。template・sample・recipe を追従させ、sample は仕入グループ（P-01〜P-02）の詳細化へ書き直した。cdfd-overview の詳細 CDFD 一覧と overview 側 kata、reference・命名標準も同じ方針に揃えた。 | pjr-4nxr-cdfd-rulebook-process-group | - |
| PJR-V8FV | done | CDFD 3 レベルの章構成を前半共通（目的・適用範囲・プロセス領域・データストア・概念データフロー）に揃える | cdfd-overview、プロセスグループ別 CDFD、ユースケース別 CDFD の章構成が 3 章以降で食い違い、読み方が揃わない。1 目的、2 適用範囲、3 プロセス領域（対象単位ごとの節: 説明文 → 主要入力・主要出力・データストアの箇条書き → 表）、4 データストア（overview の一覧と同じ名称・区分の部分集合）、5 概念データフロー（図直後の注記）を 3 レベル共通の骨組みとし、6 章以降にレベル固有の章、末尾に未決事項を置く。cdfd-rulebook / cdfd-uc-rulebook とそれぞれの template・sample・recipe を揃える。 | todo | medium | ARC | 2026-09-13 | 2026-09-30 | 2026-09-13 | cdfd-overview、プロセスグループ別、ユースケース別の 3 レベルで、1 目的 / 2 適用範囲 / 3 プロセス領域（対象単位ごとの節） / 4 データストア（マスタ・構成／トランザクション） / 5 概念データフローを共通の骨組みとし、6 章以降をレベル固有、末尾を未決事項に揃えた。cdfd-rulebook と cdfd-uc-rulebook、overview-rulebook、template・sample・recipe 各 3 本を更新し、cdfd-overview の 4 章名を「データストア」に統一した。 | pjr-v8fv-cdfd-common-chapter-skeleton | - |
| PJR-ZKNA | done | ユースケース別 CDFD の cdfd-uc-rulebook と recipe・sample・template を新設する | cdfd-overview が定義するユースケース別 CDFD（cdfd-uc-<topic>）は、複数のプロセスグループをまたぐ順序と引き渡し条件だけを定め、グループ内部のプロセスは再掲しない。一ノード一プロセスを契約とする cdfd-rulebook では表現できないため、専用の cdfd-uc-rulebook と recipe・sample・template を新設する。章構成と記述レベルは cdfd-overview に合わせ、ID はプロジェクト修飾なしとする。 | todo | medium | ARC | 2026-09-13 | 2026-09-30 | 2026-09-13 | ユースケース別 CDFD の cdfd-uc-rulebook を新設し、複数のプロセスグループをまたぐ順序と引き渡し条件だけを定める契約、cdfd-uc-<topic> の命名、C-01 形式のケース ID、グループ内部・状態遷移を扱わない境界を規定した。template・sample（欠品から補充まで）・recipe を一式作成し、cdfd-overview-rulebook・cdfd-mermaid-rulebook・deliverables-reference・命名標準へ種別と命名を追記した。 | pjr-zkna-cdfd-uc-rulebook | - |
| PJR-2BXD | done | grade plan の既定保存先を execution/grade/generated/ 配下へ変更する | grade plan の既定保存先 execution/grade/plans/<target>/ は generated/ の規約（.gitignore の docs/**/generated/*、doc-index の generated 除外）の外にあり、8/30 の grade 開発中に手動実行した plan 7 件が commit されたまま陳腐化していた（b114d998 で削除済み）。plan は対象文書から決定的に再生成でき、同じ対象は同じファイルへ上書きされる派生生成物のため、既定を execution/grade/generated/plans/<target>/ へ変更して規約に揃える。 | todo | low | ARC | 2026-09-12 | 2026-09-30 | 2026-09-12 | grade plan の既定保存先を execution/grade/generated/plans/<target>/ へ変更し、generated/ の規約（git 管理外・索引除外）に揃えた。command-reference と directory-layout-reference を更新し、実行して保存先・gitignore・索引除外を確認した。run-per-document.sh の経路は --out 指定のため影響なし。 | pjr-2bxd-grade-plan-generated-default | - |
| PJR-33SB | done | grade の定期再評価で選択 0 件のときは Job Run の記録を残さない | rtn-grade-recheck（1 日 3 回）と rtn-grade-deliverable-recheck（1 日 1 回）は、変更済み・未評価の文書が無くても Job Run を生成し、plan / result / evidence / run の 4 ファイルと analysis reporter の起動（約 2 分）が発生する。kata 254 件の評価が完了した現在は no-op が常態で、9/12 だけで 3 回の no-op 記録が積み上がった。選択が 0 件のときは Job Run を作らず、routine-state.json の last_run だけを更新する方式に変える。 | todo | medium | ARC | 2026-09-12 | 2026-09-30 | 2026-09-12 | Job Definition に task.precondition（command と skip_when）を追加し、Job Run 作成前に grade list で選択を判定して 0 件なら Job Run・plan・result・evidence を作らず skipped を返すようにした。routine は skipped を routine-state.json に記録する。job-grade-kata と job-grade-deliverable に適用し、実機で選択 0 件の Job 起動が 1 秒で記録なしに終了することを確認した。 | pjr-33sb-grade-recheck-skip-empty-selection | - |
| PJR-08K1 | done | 成果物の評価を grade へ寄せ review result の同期問題を解消する | kata は grade が定期的に変更を検知し、出来栄えの確認から次のアクションへ繋がる。成果物には 同じ循環がない。review は一度きりで、対象が後から変わっても気づけない。 | todo | medium | ARC | 2026-09-10 | 2026-09-30 | 2026-09-12 | grade --target deliverable が成果物カタログの done_criteria を条件別に評価し、Frontmatter に要約、grade/criteria/ に成果物別の詳細 YAML を保存するようにした。score/verdict と条件充足は独立した軸として保ち、content_hash で変更検知して rtn-grade-deliverable-recheck から毎日最大 5 件を再評価する。既存の review result は合意形成履歴として維持し、最新状態は grade で判定する。 | pjr-08k1-deliverable-grade-done-criteria | - |
| PJR-6776 | done | エージェント作業用 worktree のブランチ命名を統一する | エージェント作業用 worktree のブランチ名が揺れている。接頭辞の有無が agent によって異なり、 script の指定と実際のブランチが一致しない箇所もある。 | todo | low | ARC | 2026-09-10 | 2026-09-30 | 2026-09-11 | - | pjr-6776-worktree-branch-naming | - |
| PJR-7VKR | done | specdojo を npm へ公開する | specdojo 0.1.0 は 2026-04-05 に公開済みだが、別リポジトリの初期実装で現在とは実質別物である。 同梱範囲を確定して 0.2.0 を公開する。 | todo | high | ARC | 2026-09-10 | 2026-09-30 | 2026-09-23 | specdojo 0.2.0 を Trusted Publishing（provenance 付き）で npm へ公開し、@specdojo/docs-lint 0.1.0 も公開した。空ディレクトリで npm 導入から exec plan まで到達することを確認した。 | pjr-7vkr-npm-release | - |
| PJR-9M5N | done | npm 導入後のセットアップ導線を整備する | npm install specdojo で導入した利用者が、インストール後に何をすればよいか分からない。 コマンドの配置と README の双方に問題がある。 | todo | high | ARC | 2026-09-10 | 2026-09-30 | 2026-09-10 | - | pjr-9m5n-npm-onboarding-path | - |
| PJR-9S8F | done | 文書サイト機能を別パッケージへ分離する | Mermaid 図の生成が Chromium を必要とする。CLI 本体には不要な依存であり、同梱すると利用者が Mermaid 生成時に Chromium の取得へ直面する。文書サイト構築に必要な一式を分離する。 | todo | medium | ARC | 2026-09-10 | 2026-09-30 | 2026-09-12 | VitePress と Mermaid 生成器を packages/docs-site（@specdojo/docs-site）へ分離し、CLI 本体の package.json から vitepress / vitepress-sidebar / @mermaid-js/mermaid-cli を除去した。docs:dev / docs:build は分離パッケージへ委譲し、deploy.yml と post-create.sh を追随させた。保護対象の設定は orchestrator が申し送りを確認して develop へ適用し、実機で npm run docs:build の全量ビルドが成功することを確認した。 | pjr-9s8f-split-docs-site-package | - |
| PJR-A12B | done | 呼び出し元のない lefthook-docs-build.ts を削除する | tools/docs/src/lefthook-docs-build.ts はリポジトリ内のどこからも呼ばれていない。 | todo | low | ARC | 2026-09-10 | 2026-09-30 | 2026-09-10 | - | pjr-a12b-remove-dead-lefthook-docs-build | - |
| PJR-BKQ0 | done | finding 除去後の空行が畳まれず生成物が lint に失敗する | prj-0001:pjr-say1-template-finding-comments で生成時に specdojo:finding コメントを除去した が、除去後の空行が畳まれない。生成物に連続空行が残り lint:md が MD012 で失敗する。 | issue | medium | ARC | 2026-09-10 | 2026-09-30 | 2026-09-10 | - | pjr-bkq0-generated-blank-after-finding-removal | - |
| PJR-VFD0 | done | 保護機構でブロックされた executor を再開できない | agent-config-write が保護対象の設定変更を検知すると executor 段が failed となり、 --resume が拒否される。 | issue | medium | ARC | 2026-09-10 | 2026-09-30 | 2026-09-10 | - | pjr-vfd0-exec-resume-protection-blocked | - |
| PJR-MRJT | done | 実行の同一性を period から組み立てており日次実行できない | job のコマンドが --run-id を入力から組み立てているため、実行の同一性がスケジュールの粒度に 依存する。週次を日次へ変えると 2 晩目以降が空振りする。 | issue | high | ARC | 2026-09-09 | 2026-09-30 | 2026-09-10 | - | pjr-mrjt-job-run-identity-from-period | - |
| PJR-TX1G | done | rate limit で中断した executor を再開できない | executor が rate_limited のまま残った run は --resume が拒否し、--force-restart で worktree ごと破棄するしか手段がなかった。 | issue | high | ARC | 2026-09-09 | 2026-09-30 | 2026-09-09 | - | pjr-tx1g-exec-resume-rate-limited-executor | - |
| PJR-5HHS | done | 統合後に exec ブランチが削除されず蓄積する | exec run --worktree の統合後に exec/prj-0001-PJR-XXXX ブランチが残る。worktree は削除されて いるが、ブランチだけが残存する。確認時点で 8 本が蓄積していた。 | issue | medium | ARC | 2026-09-08 | 2026-09-30 | 2026-09-10 | - | pjr-5hhs-exec-branch-not-deleted | - |
| PJR-78MQ | done | routine の action.kind を job へ統合する | routine の action.kind は 5 種あるが、実装の構造が同じである。job がコマンドを決定論的に 実行できるようになれば、すべてを job として定義できる。 | todo | medium | ARC | 2026-09-08 | 2026-09-30 | 2026-09-09 | - | pjr-78mq-routine-action-kind-unification | - |
| PJR-9QZ2 | done | 中断した exec の executor 段が running のまま残り resume できない | exec run のプロセスが異常終了すると、pipeline-state.json の executor 段が running のまま 残る。--resume は再開を拒否し、--force-restart で worktree ごと破棄して全体を再実行する しか手段がない。 | issue | high | ARC | 2026-09-08 | 2026-09-30 | 2026-09-08 | - | pjr-9qz2-exec-stale-running-stage | - |
| PJR-GWY4 | done | job のコマンド実行を決定論的にする | job の実行は、agent が description を解釈してシェルコマンドを組み立て、実行する形になって いる。コマンドの実行自体は決定論的であり、agent の判断を要しない。 | todo | high | ARC | 2026-09-08 | 2026-09-30 | 2026-09-09 | - | pjr-gwy4-job-deterministic-command | - |
| PJR-M35P | done | 保護機構が gitignore 済みの生成物を設定変更として検知する | agent-config-write が .specdojo/doc-index.json の変更を保護対象の設定改変として検知し、 PJR-MBVM の統合をブロックした。 | issue | high | ARC | 2026-09-08 | 2026-09-30 | 2026-09-08 | - | pjr-m35p-protection-false-positive-generated | - |
| PJR-T2KK | done | 修正済み文書の再評価を routine で実行できるようにする | finding に沿って修正した文書を再評価する作業が手動のまま残っている。これを routine から起動 できるようにする。 | todo | medium | ARC | 2026-09-08 | 2026-09-30 | 2026-09-09 | - | pjr-t2kk-grade-recheck-routine | - |
| PJR-20DV | done | grade の content_hash を整形に依存しない正規化で計算する | grade apply が保存する content_hash が、commit 済みの文書内容と一致しない。--changed-only による再評価対象の判定が機能しない。 | todo | high | ARC | 2026-09-07 | 2026-09-30 | 2026-09-08 | - | pjr-20dv-grade-content-hash-normalization | - |
| PJR-HF4N | done | maintenance の根拠が finding の性質と噛み合わない | <kind>-maintenance は「成果物・review result・対象領域の慣行」を根拠に kata を見直す設計である。 一方 grade が記録する finding には、rulebook との構成不整合を指摘するものが含まれる。この場合 根拠は rulebook にあり、成果物ではない。 | todo | high | ARC | 2026-09-07 | 2026-09-30 | 2026-09-07 | finding が指す規範を根拠に含め、成果物の欠落だけでは見送らないようにした。br-sample.md の章構成が rulebook と一致することを確認した。 | pjr-hf4n-maintenance-approach-evidence | - |
| PJR-KK07 | done | テンプレートを同梱パッケージ側へフォールバックさせる | specdojoRootDir() は利用者リポジトリのルートを返すため、npm でインストールした利用者の リポジトリに docs/ja/specdojo/templates が存在せず Template not found で失敗する。 利用者リポジトリに無い場合は同梱パッケージ側のテンプレートを解決する経路を設ける。 | todo | high | ARC | 2026-09-07 | 2026-09-30 | 2026-09-08 | - | pjr-kk07-template-resolution-fallback | - |
| PJR-MBVM | done | grade の対象選択から generated 配下を除外する | grade validate / grade plan の文書選択が docs/ja/specdojo/*/generated/ 配下を対象に含めて いる。--changed-only の走査で 47 件が specdojo.grade is missing として報告される。 | todo | medium | ARC | 2026-09-07 | 2026-09-30 | 2026-09-08 | - | pjr-mbvm-grade-exclude-generated | - |
| PJR-RP1K | done | maintenance と bootstrap の plan で finding を修正の根拠に据える | maintenance と bootstrap の exec テンプレートは finding へ言及するが、記述が指示として弱い。 agent が finding コメントを削除するだけで完了と解釈する余地がある。 | todo | high | ARC | 2026-09-07 | 2026-09-30 | 2026-09-07 | 5テンプレートで finding を手順へ組み込み、修正を主目的とする記述へ改めた。実行による検証は PJR-T3VQ の解決後に行う。 | pjr-rp1k-maintenance-finding-instruction | - |
| PJR-SAY1 | done | 同梱テンプレートから finding コメントを除去する | grade apply がテンプレートへ挿入した specdojo:finding コメントが、そのテンプレートから 生成されるすべての文書へ複製される。 | todo | high | ARC | 2026-09-07 | 2026-09-30 | 2026-09-08 | - | pjr-say1-template-finding-comments | - |
| PJR-SRQZ | rejected | 登録簿項目へ依存関係と着手可能判定を導入する | beads との比較から、register 項目に依存関係の表現と着手可能判定がないことを欠落として起票した。 判定の結果、前提が誤っていたため却下する。 | todo | medium | ARC | 2026-09-07 | 2026-09-30 | 2026-09-07 | - | pjr-srqz-register-dependencies | - |
| PJR-T3VQ | done | maintenance の plan が編集対象の kata パスを示さない | <kind>-maintenance の plan が示す path は成果物であり、編集対象である kata のパスを含まない。 agent は「対象成果物に紐づく kata」を自力で探す必要がある。 | todo | high | ARC | 2026-09-07 | 2026-09-30 | 2026-09-07 | plan へ編集対象の kata パスと state を追加した。節名も実態へ合わせた。修正が進まない件は approach の設計問題として分離した。 | pjr-t3vq-maintenance-plan-target-path | - |
| PJR-36QG | open | 競合状況 | Spec-Driven Development（SDD）と AI を用いた開発方式・成果物管理の競合状況を記録する。位置づけと差別化の判断材料とする。 | note | high | ARC | 2026-09-06 | _TODO_ | - | - | pjr-36qg-competitive-landscape-and-release | - |
| PJR-88K2 | done | grade apply が本文末尾に余分な空行を残す | grade apply が評価結果を書き込むとき、本文末尾に余分な空行が残る。lint:md が MD012/no-multiple-blanks で失敗する。 | todo | medium | ARC | 2026-09-06 | 2026-09-30 | 2026-09-08 | - | pjr-88k2-grade-apply-trailing-blank | - |
| 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-K513 | done | VS Code 拡張の配置とビルド成果物の扱いを整える | tools/vscode-specdojo に置かれていた拡張を packages/vscode-specdojo へ移し、ビルド成果物の 扱いとルートからの実行経路を整える。Marketplace へ公開する前に必要な作業であり、 prj-0001:pjr-gx9d-vscode-extension-consolidation の前提となる。 | todo | medium | ARC | 2026-09-06 | 2026-09-30 | 2026-09-06 | 拡張を packages/ へ移し、ルートから install / build / package を実行できるようにした。vsix は tracking しない。 | pjr-k513-vscode-extension-layout | - |
| PJR-P7HY | done | 1つの項目が複数リポジトリを変更する場合の統合を扱う | 別リポジトリ構成で1つの SpecDojo が複数のプロダクトリポジトリを管理する場合、単一の登録簿項目が 複数のプロダクトを同時に変更する状況が生じうる。この場合の統合順序と回復手順が定まっていない。 | todo | high | ARC | 2026-09-06 | 2026-09-30 | 2026-10-07 | 後続の PJR-5822・PJR-9KST・PJR-6RN3・PJR-V96B・PJR-69VP で、統合順序・失敗パターンごとの回復・リポジトリ別の親検証・部分状態の扱い・実構成での確認がすべて満たされた。本項目での実装はない | pjr-p7hy-multi-repo-single-item | - |
| PJR-2W38 | open | sample の品質が他種別より著しく低い | kata の走査で、sample の評価が他種別より著しく低い。走査は継続中のため確定値ではないが、 判断材料を失わないよう途中観測を記録する。 | note | high | ARC | 2026-09-05 | _TODO_ | - | - | pjr-2w38-sample-quality-observation | - |
| PJR-9PY9 | rejected | maintenance と bootstrap の plan へ finding を載せる | grade apply は要修正箇所を specdojo:finding の HTML コメントとして本文へ記録する。 一方、kata を手入れする <kind>-maintenance と bootstrap の approach は plan にこの finding を 載せない。評価結果が修正へ渡らない。 | todo | high | ARC | 2026-09-04 | 2026-09-30 | 2026-09-07 | 前提が誤っていた。maintenance と bootstrap のテンプレート5件すべてに finding を参照する指示が既に存在する。 | pjr-9py9-maintenance-plan-findings | - |
| PJR-BBPC | done | 3段評価の既定リファレンスが対象種別に追従しない | tools/grade/run-per-document.sh は --kind で評価対象の種別を選ぶが、1段目の既定リファレンス は種別に追従せず prj-overview-rulebook.md のままである。 | todo | medium | ARC | 2026-09-04 | 2026-09-30 | 2026-09-08 | - | pjr-bbpc-stage1-reference-kind-default | - |
| PJR-E6QJ | done | worktree 実行で生成物が用意されず親検証が失敗する | worktree 実行の準備処理は npm ci で依存を用意するが、生成物は作らない。生成物は .gitignore の docs/**/generated/* により追跡対象外で、worktree へ複製されない。 | todo | high | ARC | 2026-09-03 | 2026-09-30 | 2026-09-03 | worktree の依存インストール直後に生成物をまとめて作るようにし、生成物を前提とする検証が成果物と無関係に失敗する状態を解消した。 | pjr-e6qj-worktree-generated-artifacts | - |
| PJR-G1QZ | done | grade の finding コメントが Markdown lint を壊さないようにする | grade apply は指摘箇所を specdojo:finding の HTML コメントとして本文へ挿入する。挿入位置 によっては Markdown の構造を壊し、lint:md が失敗する。 | todo | high | ARC | 2026-09-03 | 2026-09-30 | 2026-09-04 | finding コメントの挿入位置を Markdown AST のブロック境界へ変更し、構造を分断しないようにした。既存7文書の違反は orchestrator が修正した。 | pjr-g1qz-grade-finding-comment-lint | - |
| PJR-QHKA | done | 別リポジトリ構成（Detached Unit）のドキュメント化 | SpecDojo の成果物をプロダクトと同じリポジトリに置かず、別リポジトリ（app1-specdojo/）で 運用する構成を docs-structure-guide.md へ追記する。採用条件、ディレクトリレイアウト、 result への app commit hash 記録によるトレーサビリティ方式を規定する。 | todo | medium | ARC | 2026-09-03 | 2026-09-30 | 2026-09-12 | docs-structure-guide に別リポジトリ構成（Detached Unit）の章を追記し、採用条件、ディレクトリレイアウト、result への app commit hash 記録によるトレーサビリティ方式を規定した。 | pjr-qhka-docs-structure-detached-unit | - |
| PJR-REDS | done | 統合処理が削除ファイルを含む変更を commit できない | worktree 実行の統合処理は、commit 対象へ git add -A -- <paths> を実行する。対象に削除された ファイルが含まれ、その削除が既に index へ入っている場合、この呼び出しが pathspec 不一致で 失敗する。 | todo | high | ARC | 2026-09-03 | 2026-09-30 | 2026-09-03 | staged 済みの削除を git add の対象から除外し、削除を含む変更を統合できるようにした。commit の pathspec は HEAD も照合するため削除は記録される。 | pjr-reds-integrate-staged-deletion | - |
| PJR-QM88 | done | schema の enum 網羅を rulebook に対して検査する | rulebook は成果物の規範を定める正本だが、schema や実装が変わったときに追従が保証されて いない。status: ready であっても実装との乖離が残る。 | todo | high | ARC | 2026-09-02 | 2026-09-30 | 2026-09-02 | schema の enum 網羅を rulebook に対して検査する lint を追加し、validate:schema へ統合した。検出された既存の乖離2件も修正した。 | pjr-qm88-rulebook-schema-enum-lint | - |
| PJR-VH6R | done | 保護機構の block 時に申し送りの記入を強制する | agent-config-write は、agent が package.json / lefthook.yml / .specdojo/exec-defaults.yaml などの検証設定を自ら書き換えることを防ぐ保護機構である。agent は変更を提案するだけに留め、 人または対話型 orchestrator が確認して適用する。 | todo | medium | ARC | 2026-09-02 | 2026-09-30 | 2026-09-03 | 保護機構が block した時点で対象と提案差分を result へ自動記録し、agent 由来の理由と検証は未記入であることを明示するようにした。 | pjr-vh6r-agent-config-write-handoff | - |
| PJR-3XNM | done | grade の忠実性検証で表記の揺れと内容の改変を区別する | grade apply --analysis-from は、reporter の GradeSubmission と executor の marker 出力を 機械照合し、finding の追加・欠落・改変を拒否する。判定主体は executor であり、reporter が 判定を書き換えないことを保証するための検証である。 | todo | high | ARC | 2026-09-01 | 2026-09-30 | 2026-09-02 | finding message の忠実性照合に句読点・空白・NFC の正規化を追加し、表記の揺れと内容の改変を区別できるようにした。 | pjr-3xnm-grade-fidelity-normalization | - |
| PJR-5ERG | done | orchestrator 本文の環境間同期を検証可能にする | orchestrator の指示本文は .agents/specdojo-orchestrator.agent.md を正本とし、環境ごとの 薄いラッパーが frontmatter を付けて同じ本文を持つ構成である。しかし本文が一致しているかを 検証する仕組みがなく、手作業での同期に依存している。 | todo | medium | ARC | 2026-09-01 | 2026-09-30 | 2026-09-04 | SSOT と5ラッパーの本文一致を機械検証する lint を追加し、乖離していた codex 版を同期した。 | pjr-5erg-orchestrator-body-sync | - |
| PJR-9RWG | done | register のイベントを個票の Frontmatter から分離する | register_events が個票の Frontmatter を肥大化させている。イベントは状態遷移のたびに増えるため、比率は悪化し続ける。 | todo | medium | ARC | 2026-09-01 | 2026-09-30 | 2026-09-01 | register のイベントを個票の Frontmatter から controls/project-register/events/ へ項目ごとのファイルとして分離した。285 件すべてを移行し、個票からは register_events が消えている。PJR-AKJ4 では個票が 251 行から 95 行、Frontmatter が 174 行から 18 行になった。ファイル名は topic を含めず pjr-xxxx.yaml とし、register update --topic での追随を不要にしている。 | pjr-9rwg-register-events-separation | - |
| PJR-9S41 | done | exec 系テンプレートを成果物テンプレートから分離する | exec と result のテンプレート 31 件は、成果物テンプレートと役割が異なるにもかかわらず同じ docs/ja/specdojo/templates/ に置かれている。 | todo | medium | ARC | 2026-09-01 | 2026-09-30 | 2026-09-01 | exec と result のテンプレート 31 件を docs/ja/specdojo/exec-templates/ へ分離した。template-authoring-standard の適用範囲を成果物テンプレートに限定し、exec 系は plan/result ライフサイクルガイドに従う旨を明記した。grade はこれまで Frontmatter を持たない exec 系まで対象に含めて全件走査が停止していたが、分離により 248 文書の走査が通るようになった。統合テストの fixture は exec-templates だけを複製していたため register add が読む pjr-*-template.md が欠けて 7 件が失敗した。2 つのディレクトリが必要になったため templates も複製するよう修正した。lefthook.yml の glob 追加は保護された設定のため result の申し送りへ記録し、オーケストレーターが適用した。 | pjr-9s41-exec-templates-separation | - |
| PJR-EXCV | done | grade の3段評価を文書単位で回す実行経路を作る | grade の 3 段評価（reference あり → reference なし → codex 確認）は、現在「段」を外側、 「文書」を内側にしたループで実行される。この順序では codex への呼び出しが最終段に集中し、 301 件が連続する burst となって rate limit を招く。また中断するとその段の進捗を失う。 | todo | high | ARC | 2026-09-01 | 2026-09-30 | 2026-09-02 | 文書単位で3段を回す run-per-document.sh を追加した。受け入れ時に検出した作業ディレクトリ起因の重複ID不具合は orchestrator が修正し、実 agent で1件通して確認した。 | pjr-excv-grade-per-document-pipeline | - |
| PJR-FMZ2 | done | 統合失敗時のエラーに git stderr を残す | 統合の失敗理由は git <args> failed: <stderr> の形で組み立てられるが、args に commit 対象の pathspec が全件並ぶため文字列が長くなり、記録先で切り詰められて末尾の stderr が失われる。 | todo | medium | ARC | 2026-09-01 | 2026-09-30 | 2026-09-02 | git 失敗メッセージで stderr を先頭付近へ置き、pathspec を件数へ要約した。切り詰めが起きても失敗原因が残る。 | pjr-fmz2-integrate-error-stderr | - |
| PJR-JHSC | done | exec のイベント粒度の理由を確認し規範文書へ記録する | exec のイベントはイベント単位でファイルへ分けられ、606 ファイルに達している。しかしこの粒度を選んだ理由が、文書にもコードのコメントにも残っていない。 | todo | medium | ARC | 2026-09-01 | 2026-09-30 | 2026-09-01 | exec のイベント粒度の理由を sysd-cross-cutting-policy の scp-STA-001 と exec-operation-guide へ記録した。並行性は理由ではない。project 単位の実行ロックと task の claim があるため、task ごとの 1 ファイルへ集約しても排他は設計できる。1 event 1 JSON を維持する理由は、状態変更を既存ファイルの read-modify-write ではなく新規ファイルの追加として表し、1 回の状態遷移を Git の 1 ファイル追加として確認でき、malformed event をファイル単位で特定でき、訂正を過去 event の書換えではなく後続 event として残せることにある。集約は技術的に可能だが互換でない変更であり、606 ファイル 227,784 byte で運用上の問題が確認されていないため現時点では行わない。将来はファイル数ではなく影響指標と移行時の fold 結果一致を受入条件として判断する。 | pjr-jhsc-exec-events-granularity | - |
| PJR-S5YA | done | 登録簿の type 別に状態遷移の指針を定める | pjr-rulebook は文書成熟度を示す status の遷移基準を定めているが、item_type ごとに item_status の終端をどう扱うかを定めていない。 | todo | medium | ARC | 2026-09-01 | 2026-09-30 | 2026-09-01 | pjr-rulebook へ type 別の通常終端と判定基準、例外的な rejected と deferred の使用条件を追加した。note は終端せず open が生きている記録を意味すること、対応や回答や判断が必要になった場合は別項目を起票して note 自体は参照元として保持することを明記した。question と decision は decided、todo と risk と issue と change-request は done を通常終端とする。register-operation-guide の状態遷移表にも note の例外を反映した。既存個票のうち終端済みだった note 3 件を内容に応じて todo または decision へ分類訂正している。 | pjr-s5ya-register-item-type-lifecycle | - |
| PJR-TA5C | done | plan を agent へ渡し stdout を得る agent run を公開する | grade の 3 段評価を shell script 化するために必要な primitive が CLI として公開されていない。 「plan を指定した agent へ渡し、その stdout をファイルへ得る」操作である。 | todo | high | ARC | 2026-09-01 | 2026-09-30 | 2026-09-01 | specdojo agent run を追加し、plan を指定 agent へ渡して stdout を得る primitive を公開した。 | pjr-ta5c-agent-run-primitive | - |
| PJR-WZMA | done | job の責務を agent への委譲に限定する | grade 系 3 つの job の task.description を読むと、対象文書の選択、agent の呼び分け、 1 件ごとの grade apply 実行、段の順序制御がすべて自然言語で書かれている。判断を要する 記述は一つもなく、実質は日本語で書かれた shell script である。 | todo | medium | ARC | 2026-09-01 | 2026-09-30 | 2026-09-03 | job の責務を判断へ限定し、決定論的な手順を script へ移した。agent は task.agent で構造化して指定する。 | pjr-wzma-job-responsibility-boundary | - |
| PJR-Y0AH | done | 統合段のみを再試行できる再開経路を設ける | worktree 実行では、executor と reporter が成功しても最後の統合（commit と merge）が 失敗することがある。この状態から回復する経路が現状ない。 | todo | high | ARC | 2026-09-01 | 2026-09-30 | 2026-09-02 | executor と reporter が成功済みで統合だけ失敗した run を、agent を起動せず統合段から再試行できるようにした。 | pjr-y0ah-integrate-only-resume | - |
| PJR-21E8 | done | grade の Frontmatter をフロースタイルで出力する | grade を記録すると Frontmatter が 51 行になり、本文より長くなる文書が生じる。categories と viewpoints は各項目が level と score だけを持つため、1 項目あたり 2 行を占める。 | todo | medium | ARC | 2026-08-31 | 2026-09-30 | 2026-09-01 | grade の Frontmatter をフロースタイルで出力するようにした。categories と viewpoints は各項目の score や level をフローにし、findings は深さが異なるため個別に dump して差し込む。grade 以外の Frontmatter には影響しない。実測では 51 行から 26 行へ半減した。Prettier 適用後もフロースタイルが維持されること、連続適用がバイト単位で冪等であることをテストで固定している。 | pjr-21e8-grade-frontmatter-flow-style | - |
| PJR-3D7Q | done | grade の対象選択に判定結果による絞り込みを追加する | grade の対象選択は --path と --changed-only しかなく、前回の判定結果で絞り込めない。 | todo | medium | ARC | 2026-08-31 | 2026-09-30 | 2026-08-31 | discoverGradeTargets へ verdict、finding 件数の上限、未評価の各フィルターを追加し、既存条件との AND 結合を実装した。grade plan / apply / validate に --verdict、--max-findings、--ungraded を公開している。評価済み 6 件で検証し、--verdict pass --max-findings 1 が ifx-index のみを抽出することを確認した。指摘のある mm と gl は pass でも除外され、条件の組み合わせが機能している。 | pjr-3d7q-grade-target-filter | - |
| PJR-GA2K | done | routine の action で複数段の順次実行を可能にする | routine の action は単一オブジェクトのみを受け付けるため、複数の処理を順に実行できない。 | todo | medium | ARC | 2026-08-31 | 2026-09-30 | 2026-08-31 | routine の action を oneOf で単一オブジェクトと配列の双方を受け付ける形へ拡張した。配列の場合は先頭から順に全段を実行し、段ごとに異なる kind と引数をそのまま委譲する。途中で失敗や skip が生じても後続を続行し、全体結果と段別結果を記録する。単一 action の実行経路と state 形式は維持したため、既存 routine 6 件の移行は不要である。キー名は単数形のままとし、単一を基本として配列も許容する rulebook frontmatter の sample と同じ形に揃えた。 | pjr-ga2k-routine-sequential-actions | - |
| PJR-Q3JG | done | exec 系テンプレートを grade の対象から除外する | xep / xer / xrp / xrr 系のテンプレート 31 件は、先頭が _FRONTMATTER_ のプレースホルダである。生成時に実際の Frontmatter へ置換される設計であり、テンプレート自体は Frontmatter を持たない。 | todo | medium | ARC | 2026-08-31 | 2026-09-30 | 2026-09-01 | PJR-9S41 へ統合し単独では対応しない。grade 側で本文の先頭を判定して除外する方針だったが、exec 系テンプレートを exec-templates ディレクトリへ分離すればディレクトリ単位で対象から外せる。成果物テンプレートは rulebook から宣言され実践の型の一部を成すが、exec 系を宣言する rulebook は 0 件であり、kata として評価する前提が成り立たない。分離が根本解決にあたるため除外だけを別に実装する意味がない。 | pjr-q3jg-grade-exclude-exec-templates | - |
| PJR-23DT | done | grade plan へ良い実例をリファレンスとして渡す | 記載水準の判定には比較対象が要る。現在の plan は対象文書、対応する実践の型、抽象的な rubric、viewpoint の定義を含むが、良い文書の実例を含まない。 | todo | medium | ARC | 2026-08-30 | 2026-09-30 | 2026-08-31 | grade plan へ比較リファレンスを含められるようにした。同種別かつ status: ready の文書から選び、同種別に候補がない場合は種別を跨がずリファレンスなしで評価する。種別が違うと構造も目的も異なり基準として誤りを招くためである。既定では付けず、--reference <path> で固定するか --random-reference で無作為に選ぶ。判定に用いたリファレンスは specdojo.grade.reference へ文書 ID で記録する。実測では同じ文書がリファレンスの有無で score が最大 19 ポイント動き、閾値 70 を下回る文書が 2 件現れた。抽象的な rubric だけでは記載水準を判断できていなかったことを確認した。 | pjr-23dt-grade-reference-examples | - |
| PJR-25F4 | done | grade の段階的な運用を設計する | ローカルモデルは判定が甘く、単独では見落としが生じる。dec-rulebook.md はローカル構成（qwen を executor、gemma を reporter）で verdict が pass、score が 96 と判定されたが、codex-expert-executor は単独で 12 件、claude-expert-executor は 23 件の指摘を出している。 | todo | medium | ARC | 2026-08-30 | 2026-09-30 | 2026-08-31 | grade を3段で回す運用を設計し実装した。1段目はリファレンスありで全件をローカル評価し、2段目はリファレンスなしで1段目の失敗を拾いつつ指摘を確認する。3段目は pass かつ score 96 以上で finding 1 件以下のものと、未評価のものだけを codex-expert-executor が確認する。rtn-grade-kata を3つの Job の配列 action へ変更し、前段の成否にかかわらず後段を実行する。あわせて grade へ --min-score を追加し、verdict と finding 件数と AND で組み合わせられるようにした。--ungraded とは保存済み grade の有無が矛盾するため併用を拒否する。routine の有効化は人が判断するため enabled: false を維持している。 | pjr-25f4-grade-two-stage-filter | - |
| PJR-6XNJ | done | grade の graded_by を CLI 側で確定させる | GradeSubmission の graded_by は agent が自己申告するため、値が安定しない。同一 agent の連続実行でも異なる値が記録される。 | todo | medium | ARC | 2026-08-30 | 2026-09-30 | 2026-08-30 | grade apply --by <nickname> を追加し、指定値を pm-members.yaml と照合してから specdojo.grade.graded_by へ記録するようにした。agent が GradeSubmission で自己申告した値は保存に使わず、新規 plan から自己申告欄を削除した。既存の GradeSubmission にある graded_by は引き続き解析でき、保存済み grade の schema も変更していない。 | pjr-6xnj-grade-graded-by | - |
| PJR-ANKR | done | grade を executor と reporter の2段構成へ分ける | grade は1つの agent へ分析と JSON 構造化の両方を求めているため、どちらかが犠牲になる。 | todo | medium | ARC | 2026-08-30 | 2026-09-30 | 2026-08-30 | grade plan が1文書ごとに executor plan と reporter plan を生成するようにした。executor plan から JSON 契約を除き、各 viewpoint の LEVEL と FINDING を軽量 marker で申告させる。reporter plan は対象文書を再評価せず、executor の申告を追加・省略・変更せず JSON へ写す責務に限定した。grade apply --analysis-from により reporter の忠実性を機械照合し、level の変更や finding の追加・省略を適用前に拒否する。qwen を executor、gemma を reporter として検証し、所要時間が 1 段構成の 18 分から 27 分に対し 6.5 分へ短縮され、構文破損も解消することを確認した。--analysis-from を省略する 1 段構成も維持している。 | pjr-ankr-grade-executor-reporter | - |
| PJR-X40M | done | grade plan へ前回の finding を引き継ぎ解消を確認させる | 再評価時に前回の判定結果を完全に上書きしているため、前回どの問題を指摘したかが agent に伝わらない。6 つの agent を比較したところ、同一文書に対する finding 件数は 1 件から 19 件まで分かれた。単独実行では agent ごとに網羅性が大きく異なる。 | todo | medium | ARC | 2026-08-30 | 2026-09-30 | 2026-08-30 | grade plan の生成時に対象文書の既存 specdojo:finding コメントを解析し、rule / severity / message を前回の指摘として plan へ含めるようにした。level、score、verdict、finding ID、解消履歴は引き継がない。plan には前回指摘の解消確認、未解消 finding の再掲、前回指摘にない問題の検出、各 viewpoint の独立評価を明記した。評価結果を最新状態へ上書きする既存方針は維持している。 | pjr-x40m-grade-previous-findings | - |
| PJR-Z8T1 | done | 未解消の finding は前回の severity を維持する | grade を累積実行すると severity が格下げされ、繰り返すほど評価が甘くなる。 | todo | high | ARC | 2026-08-30 | 2026-09-30 | 2026-08-30 | 前回の finding コメントから severity を message ごとに収集し、前回のほうが重い場合はそれを採用する preservePreviousFindingSeverities を追加した。severity から導かれる level 上限も再適用する。維持は agent の申告に委ねず CLI 側で強制する。codex-expert で評価した後に gemma で再評価する累積実行により、major 8 件が維持され verdict が needs-work、score が 55 のまま変化しないことを確認した。修正前は同じ手順で全件が minor へ落ち pass となっていた。 | pjr-z8t1-grade-finding-severity | - |
| PJR-2KPN | done | register update に個票の topic 変更手段を追加する | 個票のファイル名と文書 ID は pjr-XXXX-<topic> 形式であり、<topic> は対象領域や論点が分かる短い名称とすることが pjr-rulebook で定められている。しかし検討が進んで項目の主題が変わると、<topic> が実態と合わなくなる。 | todo | medium | ARC | 2026-08-29 | 2026-09-30 | 2026-08-29 | register update --topic を追加し、個票ファイル名と文書 ID の変更、参照の更新、event 記録、生成ビューの再生成を一度のコマンドで完結させた。topic は英小文字・数字を単一ハイフンで区切る形式に限定し、変更先ファイルが存在する場合は計画段階で停止する。参照の更新範囲は既存の register renumber と揃え、生成物を除く docs/ja 配下の旧文書 ID を自動更新する。event の action は新設せず update を用い、changes の id へ変更前後の完全な文書 ID を保存する。 | pjr-2kpn-register-update-topic | - |
| PJR-49D2 | done | rulebook/sample/recipe/template の品質評価コマンドを設計・実装する | rulebook / sample / recipe / template には agent が機械的に生成したものが含まれ、品質にばらつきがある。既存の lint:md / lint:fm / validate:schema は形式のみを検証するため、内容品質のばらつきは検出できない。 | todo | medium | ARC | 2026-08-29 | 2026-09-30 | 2026-08-29 | specdojo grade prompt / apply / validate を追加した。評価観点は共通 viewpoint 正本へ一本化し、冗長性・簡潔性を vp-arc-conciseness として加えた。agent は共通 rubric による意味判定のみを返し、対象探索・決定的観点・スコア算出・verdict・書き込みは CLI が担う。結果は Frontmatter の specdojo.grade へ冪等に上書きし、要修正箇所は specdojo:finding コメントで記録する。job-grade-kata と無効状態の rtn-grade-kata により定期実行の経路を用意し、schedule assessment の facts へ grade を取り込んだ。 | pjr-49d2-quality-assessment | - |
| PJR-4TZ7 | done | grade を1文書単位の評価へ変更し plan として保存する | grade prompt は --path で指定された全対象を1つの prompt にまとめる。対象数に比例してコンテキストが膨張し、分割の仕組みもないため、kata 285 件を対象にすると破綻する。--changed-only で絞る前提だが、初回実行、共通 viewpoint や rubric の更新後、一括修正の後はいずれも全件が対象になる。 | todo | medium | ARC | 2026-08-29 | 2026-09-30 | 2026-08-29 | grade prompt を grade plan へ改称し、対象1件ごとに exec 互換の plan を生成・保存する構成へ変更した。kata のメタデータを索引化し、参照と逆参照から対応する rulebook / recipe / sample / template を解決して参考資料として plan へ含める。参考資料は評価対象には含めない旨を plan へ明記する。plan は execution/grade/plans/<target>/ へ対象由来の固定ファイル名で冪等に保存する。Job は1件の判定ごとに apply を実行するため、後続の失敗時も既存の grade と finding は失われない。 | pjr-4tz7-grade-per-document | - |
| PJR-9XVG | done | grade plan を全文埋め込みからパス参照へ変更し exec plan と構造を揃える | grade plan は評価対象と参考資料の全文を埋め込む。そのためサイズが対象の分量に依存し、opr-batch-sample.md（22 行）を対象にした場合は参考資料の opr-rulebook.md（483 行）を含めて 63,631 文字となった。旧バッチ方式の 46,673 文字を上回っており、評価単位を1文書へ縮小した意図が損なわれている。 | todo | medium | ARC | 2026-08-29 | 2026-09-30 | 2026-08-30 | grade plan を全文埋め込みからパス参照へ変更し、frontmatter と章構成を exec plan へ揃えた。参考資料はパスで列挙し、全文を読んで実行ログに読み取り操作を残すよう plan へ明記した。opr-batch-sample を対象とした plan は 63,631 文字から 8,798 文字へ縮小し、対象の分量に依存しなくなった。 | pjr-9xvg-grade-plan-link-style | - |
| PJR-AKJ4 | done | agent の JSON 応答を確実に解析できるようにする | agent に JSON を返させる箇所で、生の応答をそのまま解析していたため、前置きやコードフェンスが付くと失敗していた。plan で「JSON だけを出力する」と契約しても、provider やモデルによって前後に文字列が付く。 | todo | medium | ARC | 2026-08-29 | 2026-09-30 | 2026-08-30 | plan へ最終応答契約を追加して agent 定義の最終報告指示に優先させ、qwen が GradeSubmission JSON を出力するようにした。あわせて src/agent-response.ts の extractJsonText を追加し、grade と exec-reporter の両方でコードフェンスや前置きを伴う応答から JSON 本体を取り出すようにした。抽出できない応答は従来どおりエラーとし、schema 検証と既存の検証規則は緩めていない。qwen の生出力が手作業なしで grade apply に受理されることを実モデルで確認した。 | pjr-akj4-agent-json-response | - |
| PJR-JFTC | done | sch-assessment の廃止可否を判断し approach の決定論的導出へ移行する | sch-assessment は track 単位で成果物と kata の整備状況を評価し、recommended_approach を導く。schema の description が示すその存在理由は、agent が書いた judgment を保存し、後続の生成器が agent を再実行せずに済むようにすることである。 | todo | medium | ARC | 2026-08-29 | 2026-09-30 | 2026-08-29 | sch-assessment を廃止し、strategy の approach_rules による intent 宣言、都度収集する成果物・Kata facts、保存済み grade から approach を決定論的に導出する構造へ移行した。7 種の intent はすべて approach_rules[].intent で表現でき、local_ids により同一 phase set 内で intent が分かれる場合も宣言できる。専用 schema、CLI の schedule assessment、agent prompt、実データ 3 件、専用テストを削除し、approach 決定から agent 起動を排除した。入力が欠ける場合は undecided を保存せずエラー停止する。 | pjr-jftc-sch-assessment-retirement | - |
| PJR-KCE0 | done | レビュー観点を共通集合として定義しプロジェクトが継承する仕組みへ移行する | レビュー観点は本来プロジェクト横断で共通であり、プロジェクト固有なのは例外的な追加分だけである。しかし現在の exec scaffold は pm-review-viewpoints-template.yaml をプロジェクトへコピーする方式であり、コピー後は共通ひな形とプロジェクト側が独立して変化する。 | todo | medium | ARC | 2026-08-29 | 2026-09-30 | 2026-08-29 | 共通レビュー観点を specdojo:pm-review-viewpoints として docs/ja/specdojo/defaults/ に正本化し、プロジェクトは extends による1段継承と差分宣言のみを保持する構成へ移行した。kata 用観点 vp-qe-kata-conformance を共通側へ新設し、prj-0001 の固有差分はすべて共通へ昇格した。共通正本の更新は再生成なしで次回の plan 生成へ反映される。 | pjr-kce0-review-viewpoints-inheritance | - |
| PJR-VQB5 | open | grade 判定の agent 比較結果 | 同一の grade plan を6つの agent へ渡し、判定結果を比較した実測記録である。kata 285 件の定期評価にどの agent を使うかを判断するために行った。 | note | medium | ARC | 2026-08-29 | 2026-09-30 | - | - | pjr-vqb5-agent-grade-comparison | - |
| PJR-ZYFZ | done | 文書責務の単一性を見る viewpoint を追加する | 1つの文書が複数の独立した主題を同居させている状態を検出する観点が、既存の viewpoint に存在しない。 | todo | medium | ARC | 2026-08-29 | 2026-09-30 | 2026-08-30 | 共通正本へ vp-arc-single-responsibility を追加し、ARC の role_viewpoint_sets へ組み込んだ。分量や対応する実践の型の数だけでは不備とせず、複数主題の案内自体を責務とする index・catalog・overview は分割対象から除外する。同一主張の反復は vp-arc-conciseness で扱い、本観点とは境界を分ける。分割が必要と判定された場合は人が確認して PJR 起票を判断する運用とし、判断手順をレビューガイドへ記載した。opr-rulebook を level 2 / major と判定できることを確認した。 | pjr-zyfz-single-responsibility-viewpoint | - |
| PJR-199G | done | develop から main への昇格時にコミットをまとめる方式を確定する | PJR-T7ZQ の決定により、遷移時の commit policy は変更せず、雑音の削減は develop から main への昇格境界で行うこととした。まとめ方の具体は検証を伴うため本項目で確定する。squash merge は祖先関係が記録されず、次回の昇格で develop の過去コミットが未マージ扱いとなり競合が繰り返される。main から develop への逆マージも履歴にあるため、双方向のマージが成立する方式を選ぶ必要がある。push 済み履歴の書き換えは行わない。PJR-TPY9 の完了後に有効となる。 | todo | medium | ARC | 2026-08-28 | 2026-10-31 | 2026-08-28 | develop から main への昇格は develop の先端を第2 parent とする merge commit を必ず作り、squash merge と rebase merge は使用しない方式に確定した。物理的なコミット数を減らすのではなく、git log --first-parent main を正規の履歴として読む軸を変える方式である。これにより祖先関係が保たれ、次回の昇格で過去コミットが未マージ扱いにならず、main から develop への逆マージも成立し、push 済み履歴も書き換えない。使い捨て clone で2回の昇格と逆マージを再現し、対照実験で squash merge が完了条件を満たさないことも確認した。レビューで適用範囲の制約が判明した。実リポジトリの main 先端 b4203fc0 は第1 parent が develop 側であり、過去の昇格は develop 上で merge して main を fast-forward した形のため、現在の first-parent 系列は2,675件中2,289件が表示され集約されていない。既存部分の集約には push 済み履歴の書き換えが必要で本規約が禁止するため、そのまま残す。本方式は次回の昇格から有効になる。この制約と、merge の向きを逆にしない注意を Gitブランチ標準とブランチワークフローガイドへ追記した。 | pjr-199g-promotion-commit-consolidation | - |
| PJR-76AG | done | テストがgitフック配下でGIT_DIRを引き継ぎ実リポジトリを破壊する事故が3度目の再発をした | PJR-TPY9 の実行結果をコミットした際、lefthook の pre-commit が npm test を起動し、その中で新規追加されたテストが一時ディレクトリのつもりで git init / add / commit を実行した。git フック配下では親の git が GIT_DIR / GIT_INDEX_FILE を環境変数へ設定するため、env を渡さずに git を起動すると実リポジトリへ適用される。共有 config へ core.bare=true と user.name=test が書き込まれ、worktree ブランチへ不正コミットが作られた。いずれも復旧済みで push 済み履歴には到達していない。PJR-X3E8、PJR-A99J に続く3度目の同型再発であり、規約の記述だけでは再発を止められないことが確認された。 | issue | high | ARC | 2026-08-28 | 2026-09-30 | 2026-08-28 | テスト実行の入口でrepositoryの位置を決める環境変数を除去する構造にした。GIT_LOCAL_ENV_VARSをsrc/git-environment.tsへ集約し、gitEnvironment()とVitest setupが同じ正本を参照する。3つのvitest設定すべてに共通setupを入れ、各workerがtest moduleを読み込む前にGIT_DIR・GIT_INDEX_FILE・GIT_WORK_TREE等を除去するため、個々のテストがenvを渡し忘れても汚染しない。PJR-EX5Eのidentity注入は維持している。検査は文字列走査からTypeScript AST解析へ置き換え、env: process.envを不合格とし、gitEnvironment()由来であることを追跡する。検証として、envを意図的に渡さないテストをGIT_DIRを設定して実行し使い捨てリポジトリが無傷であることと、setupFilesを外すと回帰テストが失敗することを確認した。3度の再発それぞれで見落とした境界も記録した。復旧手順はexec運用ガイドへ記載した。 | pjr-76ag-test-git-env-leak-repo-corruption | - |
| PJR-G2F4 | done | qwen-reporterへ構造化出力を指定してJSON単体出力を強制する | qwen-reporter は JSON 自体は生成できるが前後に散文が付き、SpecDojo の単一 JSON 解析に失敗する。指示文へ JSON オブジェクト単体で出力する旨と no_think を明示したが、3回とも同じ失敗で効果がなかった。opencode.json のスキーマにはモデル単位の options が任意オブジェクトとして定義されており、Ollama の OpenAI 互換 API へ response_format を渡せる可能性がある。JSON モードを強制すれば構造上前置きを出力できなくなる。ただし同じモデルを executor でも使っているため、モデル設定では両者を分離できない。別名登録などの分離方法とあわせて検証する。 | todo | medium | ARC | 2026-08-28 | 2026-09-30 | 2026-08-30 | 構造化出力の指定は採用せず、応答から JSON を抽出する方式で解決した。対処は PJR-AKJ4 で実施済みである。exec-reporter.ts の JSON.parse(raw.trim()) を extractJsonText 経由へ変更し、コードフェンスと前置きを除去してから解析する。本項目が記録した失敗例と同じ形状の応答が受理されることを確認した。Ollama の構造化出力は provider 固有で claude と codex へ適用できず、thinking を有効化した agent と競合しうるため採らない。モデル設定を変更していないため reporter と executor を分離する課題も生じない。 | pjr-g2f4-qwen-reporter-structured-output | - |
| PJR-QW5T | done | mainへの直接pushとsquash/rebase mergeを機械的に禁止する | 規約は develop から main への昇格で merge commit を必須とし squash / rebase merge を禁止したが、GitHub のリポジトリ設定は squash と rebase を許可したままであり PR 画面から選べる。選ばれた時点で祖先関係が失われ、規約が警告するとおり次回の昇格で競合が繰り返される。またローカルの pre-push フックは lefthook のスタブが置かれているだけで定義がなく実質無効であり、main への直接 push を止める手段がローカルに存在しない。CLI 自体は push を一切実行せず、agent も provider ごとに deny されているが、provider 設定に依存しない一律の防護柵がない。 | todo | medium | ARC | 2026-08-28 | 2026-09-30 | 2026-08-28 | GitHub 設定で squash merge と rebase merge を無効化し（PO が 2026-08-28 に実施、mergeCommitAllowed のみ true）、規約が禁止した方式を PR 画面から選べない状態にした。あわせて Lefthook の pre-push に protect-main を追加し、Git が標準入力へ渡す各更新の remote ref を検査してリモート名にかかわらず refs/heads/main への更新を拒否する。develop・feature・exec への push は妨げない。拒否メッセージは base を main、head を project develop とする PR を作り merge commit で昇格するよう案内する。実 push の --dry-run で main が拒否され develop が通ることを確認した。main の削除と push --all 相当も拒否する。これは防護柵でありアクセス制御の境界ではなく、--no-verify で迂回でき Lefthook 未導入環境では動かないこと、実際の境界は branch protection であることを Gitブランチ標準へ明記した。lefthook.yml は保護対象のため agent の commit では適用されず、内容を確認したうえでオーケストレーターが適用した。 | pjr-qw5t-protect-main-push-and-merge-method | - |
| PJR-078K | done | YAMLのschema定義をmodelineへ集約する | YAML の schema 対応が3か所に分散している。.vscode/settings.json の yaml.schemas が13パターン、package.json の検証スクリプトが13本、rulebook frontmatter の schema 宣言が2本である。前二者は同じ対応を別形式で持ち、既に6件が片方にしか存在しない。rulebook 経由の解決は106本中2本しか宣言がなく、未宣言だと plan から schema 検証の指示が落ちる。yaml-language-server の modeline を正本とし、各 YAML が自身の schema を宣言する形へ集約する。_SCHEMA_REF_ も modeline から展開する。VS Code のライブ検証はツール側が modeline を優先するため設定なしで効き、他のツールからも同じ宣言を読める。 | todo | medium | ARC | 2026-08-27 | 2026-09-30 | 2026-08-28 | YAML の schema 定義を yaml-language-server の modeline へ集約した。docs 配下の86ファイルへ modeline を付与し、テンプレート30本にも付与して生成物へ引き継がれるようにした。テンプレートはプレースホルダを含むため検証対象外、サンプルは完成例のため対象とする。modeline の欠落とパスの誤りを検出する検証を追加し、書き忘れが黙って対象から外れない状態にした。_SCHEMA_REF_ は rulebook frontmatter ではなく対象ファイルの modeline から解決する。package.json の validate:schema:* 個別12本を削除し --modeline による全YAML走査へ集約した。validate:schema:file は単一ファイル検証、validate:schema:job-run は対象がJSONでmodelineを持てないため残した。保護対象の package.json と .specdojo/exec-defaults.yaml は agent が変更せず、オーケストレーターが承認のうえ適用した。settings.json と検証スクリプトの食い違い6件も解消した。 | pjr-078k-yaml-schema-modeline-ssot | - |
| PJR-44CW | done | git状態の検知がrunner自身の操作を誤検知して実行を止める | PJR-A99J で追加した検知機構が、agent の操作と runner 自身の操作を区別できていない。PJR-07M5 と PJR-EX5E の2回連続で実行が停止したが、いずれも成果物に問題はなく、検知された HEAD の変化は exec の register 遷移コミット（start / wait）という runner 自身の操作であった。正当な実行が毎回止まると、そのたびにオーケストレーターの代行が必要になり運用の妨げになる。検知の目的である事故の防止を保ちながら、runner 自身の操作を除外する。 | todo | high | ARC | 2026-08-27 | 2026-09-30 | 2026-08-27 | 誤検知の原因は2つあった。local config 側は VS Code が runner 作成の worktree branch を発見した際に付与する branch のメタデータであり、HEAD 側は比較対象が実リポジトリになっていたため runner の register 遷移コミットを拾っていた。前者は当該メタデータのみを除外し、順序と重複は保持して同名設定の順序依存の変化を引き続き検知できるようにした。後者は除外規則を設けず、比較対象を agent の cwd で解決した worktree へ限定することで解決した。網羅的な除外リストは設けていない。広く除外すると検知すべき変更を見逃すためである。検知の範囲は弱めておらず、agent が worktree 内で作ったコミットと core.bare の変更は引き続き検知する。runner のコミットと agent の変更が混在する場合も検知できることを含め、双方向のテストを追加した。修正が適用されるのは次回の実行からであり、実運用での裏付けはそこで得られる。 | pjr-44cw-git-state-guard-false-positive | - |
| PJR-6AAX | rejected | assessment validateが正しい判定に対して誤警告を出す | schedule assessment validate が、判定の根拠として status draft を挙げていない箇所に対して「status draft であること自体は利用不能の根拠にならない」という警告を出す。PJR-ENK0 で生成した sch-assessment-planning.yaml の dct-index / kata.template が該当したが、実際の根拠は target-fit と internal-consistency の失敗であり、draft には言及していない。判定の checks に draft という語が含まれるかどうかなど、機械的な条件で誤検知していると見られる。正しい判定に警告が出るとレビューのたびに確認の手間がかかる。 | todo | low | ARC | 2026-08-27 | 2026-10-31 | 2026-09-04 | PJR-JFTC で sch-assessment が廃止され、誤警告を出す判定処理そのものが失われたため前提不成立。修正対象がない。 | pjr-6aax-assessment-validate-false-warning | - |
| PJR-ENK0 | done | sch-strategy-planningをassessmentから再生成する | docs/ja/projects/prj-0001/schedule/sch-strategy-planning.yaml は手書きで作成されており、全フェーズが approach: fully-guided の一律指定になっている。本来は sch-assessment-planning.yaml の判定に基づいて決定論的に生成されるべきである。現状の assessment は facts が実態と一致せず（3件）、判定も1件も入っていない骨組みの状態で、strategy 生成は blocking open question により停止する。assessment の事実を最新化し、agent による判定を経て strategy を再生成する。既存ファイルには手書きの owner_rules 8件と group_milestones が含まれるため、生成結果との差分を確認して失われる情報がないかを検証する。 | todo | medium | ARC | 2026-08-27 | 2026-09-30 | 2026-08-27 | assessment の事実を最新化し判定を実施したうえで、sch-strategy-planning.yaml を決定論的に再生成した。approach は fully-guided 一律ではなく、guided-pass / freeform-pass / refine-pass / review-pass / finalize-pass の5つへ分かれ、track では判定に応じて振り分けられている。freeform は1件のみで、実践の型が整っていない成果物に限定されている。手書きの owner_rules 8件は同一 owner の集約により2ルールとなり、group_milestones も保持された。失われた情報はない。assessment は以前あった facts 不一致3件のエラーが解消し、エラーなく通る。sch-track-planning.yaml と sch-milestones.yaml も更新した。残る警告は検証側の誤警告であり、判定の根拠は status draft ではなく target-fit と internal-consistency の実質的な不整合である。 | pjr-enk0-sch-strategy-planning-regenerate | - |
| PJR-EX5E | done | テストとagentによるgit identity設定が実リポジトリへ及ぶ経路を隔離する | PJR-07M5 の実行で agent が git の local config（user.name / user.email）を設定しようとし、PJR-A99J の検知機構が作動して停止した。検知は正しく働き実リポジトリへの影響はなかったが、設定しようとする経路自体は残っている。あわせて本体リポジトリの local config にテスト用の識別情報が残っており、global 設定を上書きしていた。その結果、複数のコミットがテスト用の author で記録されている。tests 配下に git config user.name を実行する箇所が複数あり、隔離されていない経路を特定して塞ぐ。過去のコミットの author は履歴の改変になるため書き換えない。 | todo | high | ARC | 2026-08-27 | 2026-09-30 | 2026-08-27 | テストが直接実行していた git config user.name / user.email を全廃し、共通の TEST_GIT_ENVIRONMENT を worker と子プロセスへ渡して identity を供給する方式へ変更した。config へ書き込む限り書き込み先を誤れば同じ事故が起きるため、そもそも config を変更しない方式を選んだ。実リポジトリの local config へ identity が書き込まれないことを検証するテストを追加し、テスト実行後も user.name / user.email が0件であることを確認した。PJR-A99J の検知機構は変更しておらず、検知を弱めずに漏洩経路を塞いだ。過去のコミット1,877件は履歴の改変になるため author を書き換えていない。 | pjr-ex5e-git-identity-isolation | - |
| PJR-07M5 | done | trialで親検証が実行されず成果の検証が不完全になる問題を解消する | exec trial は親検証を実行しない。src/exec-trial.ts に runConfiguredParentValidations の呼び出しがなく、実際の比較でも source が runner の記録は残らなかった。executor が親検証に設定された ID のコマンドを not_run とするのは規約どおりだが、trial ではその後に誰も実行しないため、test-unit・validate-schema・test-integration が一度も走らない。agent の振る舞いを比較する目的には支障ないが、trial の成果を採用する場合は検証が不足する。あわせて、完了条件が求める検証を executor が実施したかを客観指標として記録できるようにする。現状は成功した検証の数しか見ておらず、実施しなかった検証が指標に現れない。 | todo | medium | ARC | 2026-08-26 | 2026-09-30 | 2026-08-27 | trial から親検証を実行し、結果を source が runner の記録として中央 evidence へ保存するようにした。親検証が失敗した trial は採用不可とし、検証が不足したまま成果を採用することを防ぐ。executor へ設定済みの親検証 ID を渡して二重実行を防ぐ。比較記録では executor の所要時間と親検証の所要時間を分けて保存し、親検証の時間が agent の性能評価へ混ざらないようにした。executor の検証報告総数と passed / failed / not_run を runner の件数から分離し、理由付きの not_run により意図して省いた検証と単に実施しなかった検証を区別できるようにした。本実行は agent が git identity を設定しようとして PJR-A99J の検知機構が作動し停止したが、成果物とは無関係であり実リポジトリへの影響もなかった。 | pjr-07m5-trial-validation-completeness | - |
| PJR-0XEJ | done | claude系agentの設定ディレクトリを分離して並行実行できるようにする | PJR-E6HG で特定したとおり、Claude Code は起動のたびに共有の設定ファイルを書き換えるため、複数の claude プロセスが並行すると競合して JSON パースに失敗する。Claude Code 側に修正の予定はない。CLAUDE_CONFIG_DIR で設定ディレクトリを分離すると、実測では設定ファイル・セッション・バックアップまで含めて分離されることを確認した。ただし分離先は未認証状態であるため、専用プロファイルの認証をどう扱うかが課題となる。分離により claude 系 agent をオーケストレーターの待機なしで実行できるようにする。 | todo | medium | ARC | 2026-08-26 | 2026-10-31 | 2026-09-11 | 並行実行時の ~/.claude.json 競合は Claude Code 2.1.259 で上流修正されており、2.1.268 へ更新して TUI 稼働中に claude -p を 14 回並行起動しても、また PJR-08K1 を claude-expert-executor で 12 分実行しながら並行作業しても、JSON 破損・workspace trust のリセット・MCP/project 設定の消失は発生しなかった。CLAUDE_CONFIG_DIR による設定ディレクトリの分離は不要と判断し実装しない。再発時は再起票する。 | pjr-0xej-claude-config-dir-isolation | - |
| PJR-5YW6 | done | trialで完了済みtodoを起点に指定しreporterも比較できるようにする | PJR-NW9V で新設した exec trial には2つの制約がある。試行の起点が HEAD 固定のため、完了済みの todo を使うと作業が既に統合済みで比較にならない。また reporter は全試行で共有されるため、executor の差だけを切り出せる一方で LLM 全体の性能を比較できない。起点コミットを指定できるようにし、executor と reporter を組で指定する方式も選べるようにする。reporter の成否を客観指標として記録し、構造化出力を返せたかや形式リトライの回数を比較できるようにする。 | todo | high | ARC | 2026-08-26 | 2026-08-31 | 2026-08-26 | exec trial run へ --base を追加し、起点コミットを指定できるようにした。省略時は従来どおり HEAD を使う。plan が参照するリポジトリ相対パスを抽出し、起点コミットのツリーに存在するかを実行前に確認して、欠落一覧と警告を比較記録へ保存する。従来の --agent と共有 --reporter-by を維持したまま、代替として --pair executor=reporter を追加し、reporter_mode として none / shared / paired を記録する。paired では組ごとに独立した trial ID・worktree・branch・reporter command を使う。reporter の客観指標へ状態、形式再試行回数、失敗分類（reported_blocked / invalid_output / invocation_failure / rate_limit）を追加した。実リポジトリの Git 状態を変更する処理は追加せず、PJR-A99J の隔離と前後検査を維持している。 | pjr-5yw6-agent-trial-base-and-reporter | - |
| PJR-A99J | done | agentのgit操作が実リポジトリを破壊する事象が再発した | PJR-5YW6 の実行で、メインリポジトリの core.bare が true に変更され作業ツリーが操作不能になった。あわせて worktree へテスト用フィクスチャのコミット2件が混入し、docs/register-item.md という実在しないファイルが追加された。実装の成果はなく worktree は破棄した。同種の事象は PJR-X3E8 で一度発生しており、テストで git を扱う際は隔離した環境変数を渡す規約を設けたが、再発を防げていない。agent の git 操作が実リポジトリの設定と履歴へ影響しないようにする。 | issue | high | ARC | 2026-08-26 | 2026-08-31 | 2026-08-26 | 原因は PJR-X3E8 の対処が個別テストの隔離に留まり、agent 起動環境そのものが GIT_DIR などを子プロセスへ渡していたことであった。exec-run・exec-trial・exec-worktree-command の全 agent 起動を gitEnvironment 経由へ統一し、job と e2e ツールの直接 Git 実行も揃えた。あわせて exec-agent-git-state を新設し、agent の各試行の前後で HEAD と local config を比較して、差分があれば親検証・reporter・commit・merge へ進む前に失敗させる。予防と検知の2層とした。agent による commit と core.bare 変更の検知、および危険な GIT_DIR が agent へ継承されないことを確認する回帰テストを追加した。統合テストは83件へ増えた。 | pjr-a99j-agent-git-isolation-breach | - |
| PJR-NW9V | done | 同一タスクを複数agentで試行し性能を比較できるようにする | agent の実力を把握する手段がない。実際のタスクで一度試すしかなく、結果は個別の result に散在して比較できない。同じタスクを worktree を分けて複数の agent で実行し、結果を比較できるようにする。現状は worktree 名とブランチ名が task ID から決まるため同一タスクの並行実行が衝突し、register の状態遷移も1つの実行しか想定していない。比較には同じ plan を与える必要がある点にも配慮する。 | todo | medium | ARC | 2026-08-26 | 2026-10-31 | 2026-08-26 | exec trial として新設した。run で同一 plan を複数 agent へ与えて試行し、status で状況を確認、rate で人が判断の質・文章の質・範囲の遵守を1〜5で記入、adopt で1つを採用、discard で破棄する。plan は必須で生成せず、agent 間で指示が揺れない。register の状態遷移には触れず試行が本来のタスクの状態を進めない。worktree とブランチは比較IDと agent 名を含む別系統の命名とし、既存の命名処理は変更していない。客観指標と主観評価は分けて記録する。1回の比較では agent 選定を自動変更せず、繰り返しの証跡が揃った時点で人が pm-members.yaml を更新する方針とした。実地での比較実行は未実施であり、dry-run で動作を確認した。 | pjr-nw9v-agent-comparison-trial | - |
| 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-5W8C | open | RegisterとGitHub Issues/Projectsの連携を実装する | GitHub Issues/Projects を任意の共同作業UIとして利用できる連携境界を設け、Gitのみで完結する運用とGitHubを利用する運用の双方を選択できるようにする。none、一方向のpublish/import、参照のみのlinked などの候補を評価し、方式・正本側・ID対応・同期失敗・競合・認証情報の境界を定める。方式の採用は decision として起票し承認を得る。外部ツール連携の共通契約とGitHub固有処理を分離し、将来 GitLab や Jira などのアダプターを追加するときに Register 本体の状態遷移・履歴モデルを変更しなくてよい境界にする。GitHub 以外のアダプターの実装・接続試験・運用文書は本項目の対象外とし、必要になった時点で別途起票する。同期対象が Register event となるため PJR-TPY9 の完了を前提とする。 | todo | low | ARC | 2026-08-24 | 2026-12-31 | - | - | pjr-5w8c-register-github-integration | - |
| PJR-KAQV | done | agent失敗時の生のstderrを保全する | PJR-E6HG の調査では、失敗した実行の stderr ログに原因を示すメッセージが残っておらず、stdout の切り詰められた要約行だけが手がかりだった。そのため原因を推測に頼らざるを得ず、初回の結論が誤りとなった。agent が非ゼロ終了した場合に生の stdout と stderr を evidence の一部として保全し、失敗理由の要約とは別に参照できるようにする。認証情報などの秘密が混入しうる点を踏まえ、保全先と取り扱いもあわせて定める。 | todo | high | ARC | 2026-08-24 | 2026-08-31 | 2026-08-25 | reporter の各形式試行の stdout と stderr を試行番号付きのファイルへ分離保存し、evidence.json の log_refs から参照できるようにした。保存前に既存の redactSensitiveText を適用し、既存と同じ64KiB上限で切り詰めて bytes と truncated を記録する。stdout と stderr を別枠にしたのは、一方の大量出力で原因を含む他方が失われることを避けるためである。executor 側の保全処理も共通化した。evidence 配下は Git 管理対象とし、既知パターン以外の秘密が残る可能性があるため外部共有前の確認を運用上の前提とした。 | pjr-kaqv-agent-raw-stderr-retention | - |
| 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-TPY9 | done | Register履歴をGitコミット粒度から分離する | Registerの状態遷移を追記型eventとして記録し、register historyがGitコミットの粒度に依存しない構造にする。 | todo | medium | ARC | 2026-08-24 | 2026-09-30 | 2026-08-28 | Registerの状態遷移を個票内の追記型event（register_events）として記録する構造を実装した。現在値は個票frontmatter、変更履歴は同じ個票のevent配列を正本とし、1項目1ファイルのままのためファイルは増えない。register historyはeventを優先し、未移行の期間だけGit履歴へフォールバックする。3遷移を1コミットへまとめても各遷移を復元できることをテストで確認した。register migrateは既存Git履歴を決定的なevent IDへ変換し、実データで260項目・762eventの復元が可能であることを確認した。移行は別途実施する。レビューで、未設定フィールドが空から表示用の-への変更としてadd eventに記録される問題と、概念データフロー図が履歴の入力をGit commitのままとしていた点を修正した。実行中に新テストがgitフック配下でGIT_DIRを引き継ぎ実リポジトリを初期化する事故が起きたため、gitEnvironment()経由へ修正し、envを渡さないgit起動を検出するテストを追加した。 | pjr-tpy9-register-git-github | - |
| PJR-X2Q7 | done | 失敗時のブロック理由が個票のconclusionを上書きする問題を解消する | exec run が失敗すると、その時点のブロック理由が個票の conclusion へ書き込まれる。実行が成功して完了した後も古いブロック理由が残るため、PJR-JT1Y・PJR-E6HG・PJR-Q828・PJR-1Z1H の4件連続で手作業による書き換えが必要になった。conclusion は項目の結論を記録する欄であり、途中の失敗理由を保持する場所として適切ではない。ブロック理由の記録先を分けるか、完了時に上書きされるようにする。あわせて register update に conclusion を更新するオプションがなく、直接編集が必要である点も解消する。 | todo | high | ARC | 2026-08-24 | 2026-08-31 | 2026-08-26 | ブロック理由を conclusion とは別の block_reason へ分離した。失敗した実行が項目の最終結果を置き換えられないようにしつつ、理由自体は残る。register wait は --reason を新設し、--conclusion は非推奨の別名として残して既存の呼び出しを壊さない。register update に --conclusion を追加し、直接編集せずに更新でき、ハイフン指定で削除もできる。register history はブロック理由の変化を追える。既存個票に残る過去のブロック理由は本項目では書き換えていない。 | pjr-x2q7-register-conclusion-overwrite | - |
| PJR-XGJK | done | 実践の型の宣言をrulebook frontmatterへ移行する | PJR-3N21 の決定に従い、実践の型の要否と所在の正本を rulebook frontmatter へ一本化する。成果物カタログ208件から型宣言を削除して rulebook の宣言のみを残し、要否を rulebook 側へ移す。src/kata.ts の解決をカタログ優先から rulebook 正本へ変更し、kind が generated の成果物には型を適用しない導出を実装する。schema と検証も決定内容に合わせる。PJR-K4TA と PJR-JT1Y で導入した要否の4状態と判断基準は意味を変えず、置き場所のみを移す。 | todo | high | ARC | 2026-08-24 | 2026-08-31 | 2026-08-25 | PJR-3N21 の決定に従い、実践の型の要否と所在の正本を rulebook frontmatter へ一本化した。成果物カタログの型宣言634件を削除し rulebook 宣言242件のみを残し、非生成成果物が参照する89本の rulebook へ要否を移した。移行前スナップショットとの突き合わせで判断の欠落がないことを確認した。要否が割れていた6系統は系統全体を確定扱いせず undecided へ集約し、旧 not-needed の存在を記録して PJR-K9KG で追跡する。kind が generated の成果物への非適用を kind からの導出として実装し、schema は成果物側の型宣言を拒否する。慣例ファイル探索は宣言を正本とする決定および項目の省略を必要だが未整備とする定義と矛盾するため廃止した。これは完了条件の範囲外の仕様変更であり申し送りへ明記した。単体1278件・統合79件が成功する。 | pjr-xgjk-kata-declaration-migrate-to-rulebook | - |
| PJR-0FCT | done | 共通規約のtest実行に関する記述の矛盾を解消する | 起票時の課題は「test:unit は1回だけ実行する」規約が、失敗を修正した後の再検証まで禁止すると解釈され、executor が失敗を抱えたまま終了する事象であった。この事象は PJR-QVGX により解消している。test-unit が親検証へ移り、executor は npm run test:unit を実行しなくなったためである。実行3件の evidence でも executor 側は not_run で、親 runner が実行している。 | todo | high | ARC | 2026-08-23 | 2026-08-31 | 2026-08-26 | 共通規約の test 実行に関する記述の矛盾を解消した。親検証に設定された ID のコマンドは対応表よりも優先し executor は実行しないことを明記し、対応表の該当行を条件付きの記述へ改めた。test-unit が親検証に設定されている場合と設定されていない場合の双方で、executor が何を実行すべきかが一意に定まる。全件を1回だけ実行する制約は executor が sandbox 内で実行する test script に対するものであり、親検証のコマンドは対象外であることも明記した。当初の課題であった1回限定規約による再検証の禁止は PJR-QVGX で既に解消しており、例外規定の追加は行っていない。 | pjr-0fct-test-unit-rerun-after-fix | - |
| PJR-17S7 | done | executor が unit test を二度実行し、Vitest の終了待ちが収束しない | executor が対象限定の npm run test:unit を実行した後、続けて全件の npm run test:unit を実行すると、先行実行で残った Vitest プロセスとの競合で終了待ちが収束せず中断する。vitest.unit.config.ts は maxWorkers を 2 に固定しており、残存ワーカーがあると新しい実行がスロットを確保できない。PJR-ZJZD と PJR-AQ9G の2回で再現しており、いずれもアサーション失敗ではなく環境要因である。実装は完了しているのに検証未完として block されるため、実行の締めくくりが人手に依存する。共通規約で二度実行を避けるよう指示を整理する。 | issue | medium | ARC | 2026-08-23 | 2026-08-31 | 2026-08-23 | plan へ注入する共通規約へ、executor は npm run test:unit を1回だけ実行し前後に対象限定の実行を行わない旨を明記した。回帰テストで規約が plan に含まれることを固定している。規約の効果は、次に src または tests を変更するタスクを実行したときに確認する。本タスクの実行自体は旧規約の plan で動いたため二度実行が起き、orchestrator が1回だけの実行で全件成功を確認した。 | pjr-17s7-unit-test-double-run-hang | - |
| PJR-6HF3 | done | git hook から呼ぶスクリプトが devDependency に依存し、新規 worktree で失敗する | post-checkout hook が npm run build:if-stale を実行し、その実体は tsx src/build-if-stale.ts である。exec run --worktree が新規 worktree を作る時点では node_modules が無く、tsx を解決できずに hook が非ゼロ終了する。その結果 git worktree add が失敗し、checkpoint failed として claim がロールバックされる。build-if-stale.ts には linked worktree なら何もしない判定を入れてあるが、その判定へ到達する前に起動が失敗しており、ガードが自分の前提条件に依存する構造になっている。routine 経由の自動実行が claim と release を繰り返す状態になっている。 | issue | high | ARC | 2026-08-23 | 2026-08-31 | 2026-08-23 | hook から起動する入口を Node 標準だけで動く tools/build-if-stale.mjs へ置き換えた。linked worktree と依存未インストールを委譲より前に判定するため、node_modules の無い新規 worktree でも hook が失敗しない。tsx の CLI は package.json の bin から解決し、PATH やパッケージ内部のレイアウトに依存しない。 | pjr-6hf3-hook-script-dependency-free-entry | - |
| PJR-AQ9G | done | plan 生成でも山括弧プレースホルダをインラインコード化する | 個票の説明文は exec plan の本文へそのまま流し込まれるため、dct-<domain>.yaml のような素の山括弧プレースホルダが plan へ現れる。PJR-ZWMH では索引の表セル（register build）と frontmatter の検知を対応したが、plan 生成は対象外だった。実際に PJR-ZWMH 自身の plan が lint:fm の警告として検出されている。register build と同じ規則で plan 本文の展開時にもインラインコード化する。 | todo | medium | ARC | 2026-08-23 | 2026-08-31 | 2026-08-23 | register build の変換処理を exec-shared へ切り出し、plan 生成にも適用した。個票由来の値に含まれる素の山括弧プレースホルダは、連結範囲ごとインラインコード化される。既存の残置 plan も修正し、lint:fm が成功する状態へ戻した。再適用しても二重化しないことをテストで固定している。 | pjr-aq9g-exec-plan-angle-placeholder-escape | - |
| PJR-B1SJ | done | 山括弧プレースホルダのインラインコード化を個票本文とfrontmatterへ広げる | PJR-ZWMH は登録簿索引の山括弧プレースホルダをインラインコード化したが、register add の description は個票本文へそのまま書き込まれるため未エスケープのまま残る。PJR-QVGX で実際に混入し、remark-no-unescaped-angle-placeholder のテストが統合ブランチで失敗した。 | todo | high | ARC | 2026-08-23 | 2026-08-31 | 2026-08-26 | 検知の仕組みは frontmatter にも対応済みだったが、報告が warning のため lint:fm では失敗せず、単体テストでのみ検出される状態だった。message.fatal を設定して error 化し、コミット前に失敗するようにした。既存文書に違反が残っていないことも確認した。混入経路3つ（register add の description、exec の失敗理由から frontmatter の conclusion、索引の conclusion セル）へ既存の inlineCodeAnglePlaceholders を適用し、未エスケープのまま書き込まれないようにした。実装は PJR-ZWMH の既存関数を再利用しており分散していない。 | pjr-b1sj-angle-placeholder-escape-scope | - |
| PJR-E6HG | done | claude-reporterがJSON解析失敗で再現性をもってブロックする | claude-reporter が PJR-K4TA で3回、PJR-JT1Y で3回、いずれも is not valid JSON を理由に失敗した。変更規模はそれぞれ79ファイルと61ファイルで、出力が長大になる条件で再現する疑いがある。設定ファイルはいずれも妥当な JSON であり、worktree にも存在することを確認済みである。現状 claude-reporter は reporter として使えず、codex-reporter への差し替えで回避している。原因を特定して解消する。 | issue | high | ARC | 2026-08-23 | 2026-08-31 | 2026-08-26 | 根本原因は Claude Code の既知の不具合で、~/.claude.json への並行書き込みが競合し不完全な内容を読んだプロセスで JSON.parse が失敗する。SpecDojo 側の問題ではない。issue #15608 や #40226 として報告されており、2.1.61 のホットフィックスは過剰な書き込みのみを対象とし根本の競合は未対応、2.1.86 で再報告された #40226 は closed as not planned のため修正の見込みがない。バージョンアップでは解決しない。適用範囲は reporter に限らず claude provider の agent 全般であり、実行時間の長い executor の方が競合に当たる機会は多い。回避策は、claude 系を使う実行中はオーケストレーターが待機するか、codex 系で統一することである。 | pjr-e6hg-claude-reporter-json-failure | - |
| PJR-Q828 | done | reporterが解消済みの検証失敗を再評価できない問題を解消する | reporter は executor の evidence.json に記録された検証結果のみを読み、worktree を再検証しない。そのため失敗の原因が解消されていても評価は変わらず、正当な理由でブロックし続ける。PJR-K4TA と PJR-JT1Y の2回連続でオーケストレーターによる代行記入が必要になった。失敗原因が実行環境に起因する場合や解消済みの場合に reporter が再検証できる手段、または再検証済みであることを reporter へ伝える手段を用意する。関連して PJR-0FCT の再実行例外と PJR-QVGX のsandbox制約も同じ詰まりに寄与している。 | todo | high | ARC | 2026-08-23 | 2026-08-31 | 2026-08-24 | reporter に worktree の実行権限を与えず、親 runner が parent_validations の固定許可リストだけを再実行する方式を採用した。source が runner の failed / not_run のみ再評価して置換し、source が executor の検証は成果物側として保持することで実行環境起因の失敗と区別する。再検証後も失敗する場合は従来どおりブロックする。実行時に失敗した否定側テストは実装ではなく期待値の誤りで、worktree 側の result を参照するよう修正した。source が executor の検証は再評価対象外のため、同種の詰まりは PJR-0FCT と PJR-QVGX の対応が必要である。 | pjr-q828-reporter-revalidation | - |
| PJR-QVGX | done | codex sandboxで子プロセスが成立せず検証が常に失敗する問題を解消する | codex-expert-executor の sandbox 内では tsx が IPC ソケット /tmp/tsx-1000/<pid>.pipe を作成できず EPERM となり、npm run validate:schema が成果物の内容と無関係に常に failed となる。PJR-K4TA では reporter のブロック理由の一つになった。 | todo | high | ARC | 2026-08-23 | 2026-08-31 | 2026-08-25 | sandbox 内で子プロセスの生成・通信・終了が成立しない検証を、sandbox を緩めずに親 runner へ移した。parent_validations の固定許可リストへ validate-schema と test-unit を追加し、schema の列挙値として定義した。共通規約を親検証に設定された ID のコマンドは executor が sandbox 内で実行しないと改め、prompt にも ID と対応コマンドを明示して二重実行を防ぐ。.specdojo/exec-defaults.yaml は agent の保護対象のため executor が更新できず、オーケストレーターが承認を得て適用した。sandbox の設定は変更しておらず隔離は弱まっていない。sandbox 内で子プロセスが成立しない原因そのものは特定しておらず、影響を回避した対処である。 | pjr-qvgx-codex-sandbox-tsx-ipc-eperm | - |
| PJR-ZPJZ | done | 破棄された実行試行を表す result status superseded を追加する | exec-result の status は in_progress、complete、blocked の3値しかなく、再実行によって後続の実行に置き換えられた試行を表せない。PJR-DCTG では1回目の実行が checkpoint 失敗で成果を残さず終了し、2回目が成功したが、1回目の result は in_progress のまま残っている。実行中に見える in_progress も、解決すべきブロックに見える blocked も実態と合わない。SpecDojo は resume や force-restart など再実行を前提とした設計であり、破棄された試行は今後も発生する。schema へ superseded を追加し、誰がいつ設定するかを含めて運用を定める。 | todo | medium | ARC | 2026-08-23 | 2026-08-31 | 2026-08-23 | exec-result の status へ superseded を追加した。新しい result を scaffold する際に、同一タスクで残っている in_progress と blocked の先行 result を遷移させる。complete の記録は書き換えない。固定名 result を再利用する実行は対象外とする。既存の残置 result（PJR-DCTG の1回目）も移行済み。 | pjr-zpjz-exec-result-superseded-status | - |
| PJR-269Z | done | dct-index.md を dct-index.yaml から自動生成し、順序とグループ分割を宣言で制御する | dct-index.md は現在すべて人が編集しており、ドメイン一覧表の並び順とグループ分割を宣言的に制御できない。表の4列のうち domain とカタログへのリンクは dct-*.yaml から導出できるが、名称・概要・並び順・グループの出典が存在しない。順序とグループはドメイン横断の編集意図であるため、各ドメインファイルへ分散させず dct-index.yaml に集約し、catalog build が generated/dct-index.md を生成する方式へ移行する。共通ルールの散文は register の pjr-index-template.md と同じ template 方式で保持する。 | todo | medium | ARC | 2026-08-22 | 2026-08-31 | 2026-08-22 | dct-index.yaml を正本として catalog build が generated/dct-index.md を生成する構成へ移行した。グループごとの表分割と宣言順の反映、物理分割ドメインの1行集約、宣言と実体の双方向突き合わせ、size の一本化（フォールバックなし）を実装し、共通ルールの散文は dct-index-template.md で保持する。旧 dct-index.md を削除し doc id は生成物へ引き継いだ。 | pjr-269z-dct-index-generation | - |
| PJR-8PJ4 | done | 成果物カタログのサイドバー表示名と新規 schema のエディタ関連付けを整える | サイドバーは親ノードが成果物カタログであるにもかかわらず、各アイテムも成果物カタログを繰り返していた。また大半のアイテムは生成物 H1 由来のためドメイン slug 表記だった。あわせて PJR-269Z で追加した dct-index.schema.yaml が .vscode/settings.json の yaml.schemas に登録されておらず、dct-index.yaml が汎用の dct.schema.yaml で検証されてエディタ上でエラーになっていた。表示名は dct-index.yaml の name を正本として内容だけを表示し、schema は専用マッピングを追加して汎用パターンから除外する。 | todo | low | ARC | 2026-08-22 | 2026-08-31 | 2026-08-22 | サイドバー表示名を dct-index.yaml の name を正本とする内容のみの表示へ変更し、dct-index と dct-plan の schema をエディタの yaml.schemas へ関連付けて汎用パターンから extglob で除外した。schema 追加時に package.json と .vscode/settings.json の両方を更新する旨を document-metadata-standard へ追記した。 | pjr-8pj4-catalog-sidebar-and-schema-mapping | - |
| PJR-AAR2 | done | sch-milestones の status が最後に build したトラックの strategy に引きずられる | sch-milestones.yaml はプロジェクト全トラックのマイルストーンを集約する単一ファイルだが、schedule build は毎回 doc.status を対象トラックの strategy の status で上書きする。そのため draft の strategy を持つトラック（新設直後の planning など）を build すると、ready だったプロジェクト全体のマイルストーンが draft へ降格する。逆に draft のまま ready のトラックを build すると ready へ昇格する。集約ファイルの status が最後に build したトラックに依存し、人が昇格させた状態も保持されない。 | issue | medium | ARC | 2026-08-22 | 2026-08-31 | 2026-08-23 | schedule build が集約ファイルの status を書き換えないようにした。新規作成時のみ draft を書き、既存ファイルでは保持する。対象トラックの strategy の status を集約ファイルへ反映しないため、build 順による降格も自動昇格も起きない。draft の planning トラックを build しても ready が維持されることを実機で確認した。 | pjr-aar2-milestones-status-follows-last-built-track | - |
| PJR-JG9Q | done | strategy が更新されたトラックを exec cycle で自動再生成する | 計画物として sch-strategy-<track> を更新しても、sch-track-<track> を再生成しない限り次のトラックのタスクは現れない。exec validate は strategy が track より新しいことを既に検出して警告するが、exec cycle の手順は resume・doc-index・validate と refresh・auto ループの4段で、schedule build を含まない。鮮度検知の結果を使って自動再生成することで、設定面を増やさずに次トラックへ自動で進めるようにする。preprocess や postprocess を宣言できる仕組みは、鮮度では表せない要求が出るまで導入しない。 | todo | medium | ARC | 2026-08-22 | 2026-08-31 | 2026-08-23 | exec cycle に stale トラックの自動再生成を追加し、手順を5段へ拡張した。判定は既存の鮮度検知を再利用するため設定項目は増やしていない。再生成は auto ループより前に完了し、失敗した場合はタスク実行へ進まず中断する。再生成が不要な場合は何も出力しない。preprocess や postprocess を宣言する仕組みは導入していない。 | pjr-jg9q-auto-rebuild-stale-tracks | - |
| PJR-QF7T | done | planning ドメインとトラックを新設し、計画成果物をカタログとScheduleへ載せる | PJR-WVNS の決定に基づき、計画成果物を所有する planning ドメインと planning トラックを新設する。tml-index、dct-index、sch-defaults などを project-management から移設し、着手済みトラックの sch-assessment と sch-strategy を登録する。sch-track と sch-milestones は generated として登録し、dct-<domain>.yaml と generated 配下の表示用生成物は登録しない。planning トラック自身の strategy は循環を避けるため scope から外すか control として扱う。 | todo | high | ARC | 2026-08-22 | 2026-08-31 | 2026-08-22 | planning ドメインと planning トラックを新設し、tml-index・dct-index・sch-defaults を project-management から移設した。着手済み3トラックの assessment と strategy を work、sch-track と sch-milestones を generated として登録し、sch-strategy-planning は control として循環を回避した。schedule build で計画成果物8件がタスク化され、生成物と control はタスク化されないことを実機で確認した。 | pjr-qf7t-planning-domain-and-track | - |
| PJR-T1JW | done | 設定変更ガードが gitignore 済み生成物を誤検知する問題を解消する | PJR-Y3KP で追加した設定変更ガードは .specdojo/ ディレクトリ全体を保護対象にしていたため、gitignore 済みの生成物である .specdojo/doc-index.json まで検知していた。agent は共通規約に従って docs/ 配下の変更後に index build を実行するため、規約どおりに作業しただけで必ず block され、docs を変更するすべての exec タスクが完了できない状態になっていた。PJR-269Z の実行で顕在化した。保護判定から gitignore 済みのパスを除外する。 | todo | high | ARC | 2026-08-22 | 2026-08-31 | 2026-08-22 | 保護判定から gitignore 済みのパスを除外し、agent が共通規約どおり index build を実行しても違反にならないようにした。除外条件は未追跡ではなく ignore 済みとし、未追跡の新規設定ファイルによるすり抜けを防いでいる。git が使えない場合は除外せず全候補を保護する fail closed とした。 | pjr-t1jw-protected-config-gitignore-false-positive | - |
| 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-X3E8 | done | テストの git 実行が環境を隔離せず、メインリポジトリを bare 化する | PJR-T1JW で追加した exec-agent-protected-config のテストが、git 実行時に gitEnvironment() を経由していなかった。lefthook の pre-commit が npm test を実行する経路では git が GIT_DIR を設定するため、worktree 内での commit 時は GIT_DIR が linked worktree の gitdir を指す。その状態で git init を実行すると、cwd の一時ディレクトリではなく GIT_DIR 側が bare として再初期化され、共有されているメインリポジトリの config へ core.bare=true が書き込まれる。PJR-ZJZD の実行でこれが発火し、統合処理が this operation must be run in a work tree で失敗した。 | issue | high | ARC | 2026-08-22 | 2026-08-31 | 2026-08-22 | テストの git 実行へ gitEnvironment() を渡し、hook 由来の GIT_DIR を除去した。GIT_DIR が linked worktree の gitdir を指す状態で git init を実行すると、その gitdir が bare として再初期化され共有 config へ core.bare=true が書き込まれることを再現実験で特定し、修正後は同条件でも変化しないことを確認した。テストから git を扱う際の規約も vitest.instructions.md へ明記した。 | pjr-x3e8-test-git-env-bare-repository | - |
| PJR-ZJZD | done | dct-index にサブグループ階層を追加し、成果物リファレンスの節構成へ揃える | dct-index.yaml の groups は 1 段固定で、生成物も ### の見出しと表しか出せない。成果物リファレンスは 2 章の下に 2.1 業務仕様などの節を持つ二階層構造のため、リファレンスへ正確に揃えられない。groups[].groups[] によるサブグループを許可し、生成物で #### 2.2.1. 業務仕様 のような見出しと表を出せるようにする。Markdown 記述ルールで H5 以下は禁止のため、追加できる階層は 1 段までとする。 | todo | medium | ARC | 2026-08-22 | 2026-08-31 | 2026-08-22 | dct-index に1段のサブグループ階層を追加し、ルートグループを H3、サブグループを親番号継承の H4 として出力できるようにした。schema でグループの domains と groups を排他にし、2段目のサブグループを構造的に許可しないことで H4 上限を保証している。dct-index.yaml を成果物リファレンスの章構成へ再編し、既存の1段構成の後方互換とサイドバー表示名の解決も維持した。 | pjr-zjzd-dct-index-nested-groups | - |
| PJR-ZWMH | done | 登録簿の索引生成で山括弧プレースホルダをインラインコード化し、frontmatter でも検知する | 個票 frontmatter の conclusion などに dct-<domain>.yaml のような山括弧プレースホルダをインラインコードにせず書くと、register build がそのまま表セルへ展開し、generated/pjr-index.md で HTML タグとして解釈されて VitePress ビルドが失敗する。remark の山括弧検査は本文の html ノードだけを対象とし、markdownlint も frontmatter を見ず、生成物は gitignore で lint:md の対象外のため、ビルドまで誰も検知できない。生成側でインラインコード化して塞ぎ、あわせて frontmatter 側でも検知できるようにする。 | todo | high | ARC | 2026-08-22 | 2026-08-31 | 2026-08-23 | register build が索引の表セルへ展開する全項目で、コードスパン外の山括弧プレースホルダをインラインコード化するようにした。連結範囲は拡張子のドットまで含め、文末の句点はコードの外へ戻す。あわせて remark プラグインを拡張し、frontmatter の文字列値に素の山括弧があればビルド前に検知できるようにした。読み戻しはコードスパンを保持したまま扱う。 | pjr-zwmh-register-index-angle-placeholder-escape | - |
| PJR-0DA8 | done | claude-reporter の mode を report に分離し reporter 専用の最小権限 settings を用意する | claude の command_template は settings.{mode}.json を解決するため、claude-reporter は mode: review を流用している。しかし reporter は成果物も result も自分で書かず、runner が renderReporterResult で反映するため、review 用 settings の Edit 権限は不要である。reporter 候補の選定は stage_role で行い mode は eligibility に影響しないため、mode: report へ分離しても選定と --reporter-by の解決は変わらない。pm-members.schema.yaml の enum に report を追加し、Edit を持たない settings.report.json を用意して、名前と権限を実態に合わせる。 | todo | medium | ARC | 2026-08-21 | 2026-08-31 | 2026-08-21 | pm-members.schema.yaml の mode enum に report を追加して起動プロファイルとして再定義し、claude-reporter を mode: report へ分離した。Edit と Write を全面 deny する settings.report.json を .specdojo と templates の双方に用意し、実装・テスト・ドキュメントを更新した。実際の起動コマンドが settings.report.json を指すことを確認済み。 | pjr-0da8-claude-reporter-mode-and-settings | - |
| 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-Y3KP | done | agent による設定ファイル変更を provider 非依存で実効的に止める | PJR-3S8Q で、実行コマンドを定義する設定ファイルは agent の書き込み範囲に含めないと決定した。しかし claude は allow リスト方式で守られる一方、codex は sandbox workspace-write のため物理的に書き込める。実際に PJR-0DA8 の実行で codex-expert-executor が .specdojo/claude/settings.report.json を直接作成し、register 実行の commit 対象が除外方式であるためコミットと merge まで通過した。provider の sandbox 方式に依存せず、対象パスへの agent 由来の変更を検知して止める仕組みを用意する。 | todo | high | ARC | 2026-08-21 | 2026-08-31 | 2026-08-21 | provider 非依存の保護パス定義と内容差分検査を src/exec-agent-protected-config.ts に実装し、agent 実行後の検査で親検証と reporter の起動を止め、commit 前の再検査で register 由来の除外リスト方式でも commit と merge を停止するようにした。codex と claude の双方で阻止されること、人間と orchestrator の変更は妨げられないことを検証済み。例外時は result の申し送りと人手適用に統一し、運用手順を文書化した。 | pjr-y3kp-agent-config-write-enforcement | - |
| PJR-6VFN | done | exec run --register で executor 成功後に reporter だけを再開できるようにする | register 由来の exec 実行には resume の概念が無く、reporter が rate limit などで失敗すると、タスク全体を再実行するしかない。再実行は discardStaleExecWorktree により worktree と exec ブランチを強制削除するため、executor が生成した未コミットの成果を失う。一方で pipeline-state.json には stage 別の状態が、evidence.json には executor の変更一覧・検証結果・final message が残っており、reporter の再開に必要な入力は揃っている。executor が succeeded の run を検出し、reporter 段だけを再実行して result 記入から統合・register 遷移までを完了できるようにする。 | todo | medium | ARC | 2026-08-20 | 2026-08-31 | 2026-08-21 | exec run --register --worktree --resume を追加し、executor 成功後に reporter だけを再開できるようにした。executor 成功分が未コミットのまま全体再実行しようとした場合は中断し、破棄には --force-restart を要求する。unit / integration テストと運用ドキュメントを整備した。in-place 実行の再開は未対応として残課題に記載している。 | pjr-6vfn-exec-run-register-executor-reporter | - |
| PJR-CMYX | done | exec 実行が古い dist ビルドを使い設定済み parent_validations が実行されない | specdojo の bin は dist/specdojo.js を指すため、npm run build を再実行しない限り古い挙動で exec run が動く。PJR-STRG の run（2026-08-18）では dist が 2026-08-15 12:33 のビルド（コミット be20ceb2 相当）で、parent_validations 機能を追加した 19eea172（2026-08-16）を含んでいなかった。その結果 exec-defaults.yaml の pipeline.parent_validations: [test-integration] が設定済みにもかかわらず npm run test:integration が実行されず、evidence にも記録が残らなかった。設定した検証が沈黙して省略されるため、恒久対応が必要である。なお docs/ja/specdojo は package.json の files に含まれる配布物であり、利用者環境には src が存在しないため、配布ドキュメントや orchestrator 指示書の呼び出しを tsx 直接実行へ変更する対応は採れない。本件は配布側ではなく開発チェックアウト固有の問題として扱う。 | issue | high | ARC | 2026-08-20 | 2026-08-31 | 2026-08-21 | CLI 起動時の dist 鮮度ガード、routine 実行時の自動再ビルド、post-merge / post-checkout での build-if-stale 配線を追加し、古い dist のまま exec を起動して parent_validations が沈黙して省略される事象を防げるようにした。bin・files・配布ドキュメントの呼び出し記法は変更していない。 | pjr-cmyx-exec-dist-parent-validations | - |
| PJR-DCTG | done | data-flow等からDCT成果物インスタンスを判定するagentの実装 | Timeline が着手対象として示す product 系ドメインについて、DCT template と確定済みの上流成果物、特に data-flow を agent が読み、template の placeholder 値、必要な成果物インスタンス、採用しない候補を構造化判定する処理を実装する。判定結果は、後続の決定論的ジェネレーターが同じ入力から再生成できるよう、バージョン管理対象の dct-plan-<domain>.yaml として保存する。 | todo | medium | ARC | 2026-08-16 | 2026-08-31 | 2026-08-23 | dct-plan-<domain>.yaml の schema を定義し、正準配置をカタログ配下の plans/ とした。catalog plan prompt / scaffold / validate を追加し、agent 判定の入力と出力を機械可読に扱えるようにした。パターンA とパターンB を iteration_pattern で区別し、未解決 placeholder はエラーとして open_questions へ誘導する。既存 plan は --force なしで保護する。テスト50件とドキュメントを整備した。成果は PJR-STRG の catalog scaffold --plan が前提として利用している。 | pjr-dctg-data-flow-dct-instance-analysis | - |
| PJR-KATA | done | 成果物・Kataの利用可能性と推奨フローを判定するagentの実装 | 成果物カタログの各 kind: work を対象に、成果物本体と Kata（rulebook / recipe / sample / template）の存在、文書状態、内容の利用可能性、既存実装エビデンスの有無を判定する agent 処理を実装する。結果は track 単位のバージョン管理対象 sch-assessment-<track>.yaml として保存し、後続コードが標準 strategy profile と approach を決定論的に選択する入力にする。 | todo | medium | ARC | 2026-08-16 | 2026-08-31 | 2026-08-19 | sch-assessment のschema・CLI・テスト・関連ガイドを実装し、typecheck・lint・unit testを通過。review完了。 | pjr-kata-artifact-kata-readiness-assessment | - |
| PJR-STRG | done | DCTとsch-strategyの決定論的ジェネレーター実装 | agent が保存した dct-plan-<domain>.yaml と sch-assessment-<track>.yaml を入力に、成果物カタログと sch-strategy-<track>.yaml をコードで決定論的に生成する。agent の責務は意味判断と根拠整理に限定し、YAML 構造、ID、パス、owner、フェーズ、ゲート、依存関係、schema 適合性は generator が保証する。 | todo | medium | ARC | 2026-08-16 | 2026-08-31 | 2026-08-20 | catalog scaffold --plan と schedule strategy generate を実装し、DCT と sch-strategy を決定論的に生成できるようにした。異常系・再生成安定性を含むテストと、rulebook・設計ガイド・コマンドリファレンスの更新を完了した。 | pjr-strg-deterministic-dct-strategy-generation | - |
| PJR-SEQC | done | timelineをgantt-chartへ改名し、timelineをトラック順序計画として新設する | 現状のtimeline（sch-track群から生成するGantt可視化）をgantt-chartへ改名し、空いたtimelineという名前を、成果物カタログ作成〜トラック実行までのマクロな順序を人間が決めて記録する新しい成果物種別（tml-）として新設する。設計判断は本チケットで確定済みのため、以降の実装はAI Agentが本文の仕様に沿って進めてよい。 | todo | medium | ARC | 2026-08-15 | 2026-08-31 | 2026-08-15 | - | pjr-seqc-timeline-gantt-chart-timeline | - |
| PJR-TNDH | done | exec run --register をexecutor/reporterパイプラインに対応させる | exec run --register（PJR個票のAI Agent実行）は単一エージェントが編集からresult記入までを完結する前提だが、現行pm-members.yamlは全provider（opencode/claude/codex/copilot）のstage_role: executorメンバーが「成果物の編集・検証のみを担当し、resultは更新しない」設計に統一されている。この不整合により、どのexecutorメンバーで--registerを実行してもresult未記入のままwaiting（blocked扱い）に陥る。PJR-SEQCの実行（claude-expert-executor使用）で実際に発生を確認した。Schedule タスクの agent_pipeline（executor→reporterの2段階固定）と同じモデルを--registerにも適用し、この構造的ギャップを解消する。 | todo | medium | ARC | 2026-08-15 | 2026-08-31 | 2026-08-15 | - | pjr-tndh-exec-run-register-executor-reporter | - |
| PJR-T7EM | done | ifx-cmd（外部コマンド連携仕様）の新設 | esil.schema.yaml の interfaces[].kind が API／ファイル／メッセージの3値固定で、CLIコマンド起動型の外部連携（AI provider CLI、Git/GitHub等）を表す区分が無い。ifx-cmd-rulebook.md を新設し、esil.schema.yaml のkind・spec_refパターンを拡張する。 | todo | medium | ARC | 2026-08-14 | 2026-08-31 | 2026-08-16 | ifx-cmd kata一式とESIL関連仕様を更新。schema・catalog・register・index・lint検証に成功し、旧生成物のdead link 16件を除去後 npm run docs:build も成功。全体テストは1085/1086成功、時刻分解能に依存したheartbeat 1件は単独再実行で4/4成功。 | pjr-t7em-ifx-cmd | - |
| PJR-ZP0B | done | system-design: sysd-<term> 新設と sysd-agent-settings 系の再構成 | sysd-index／sysd-critical-flows／sysd-cross-cutting-policy の最小3種構成では、既存のマルチエージェント実行設計（sysd-agent-settings 系4件・sysd-job-execution）を収める場所が無い。tsd-index／tsd-rulebook に倣い sysd-rulebook（hub＋子構成を許容する個別設計トピック用rulebook）を新設し、既存文書を横断ルール・運用手順・個別設計トピックへ再配置する。 | todo | medium | ARC | 2026-08-14 | 2026-08-31 | 2026-08-16 | 個別SYSD体系を新設し、agent実行設計をhub・横断ルール・重要フロー・運用手順へ再構成した | pjr-zp0b-system-design-sysd-term-sysd-agent-settings | - |
| PJR-HZ4C | done | tmuxのterminalからnpm run docs:devを起動してもport forwardingを機能させる | 現状、npm run docs:devはvscodeのterminalで実行し、vscodeのport forwarding機能でホスト/リモート端末からWebページを表示している。tmuxのterminalから起動した場合も同様にport forwardingできるようにする。 | todo | medium | ARC | 2026-08-13 | 2026-08-31 | 2026-08-13 | devcontainer.jsonのforwardPortsをappPort（Dockerレベルの固定ポート公開）へ変更し、リモート端末からのアクセスはVS CodeのPorts機能ではなくtmux接続用Hostエントリへのssh local forwardingで対応。Mac自身・リモート端末（ThinkPad）双方のブラウザで実機確認済み。 | pjr-hz4c-tmux-terminal-npm-run-docs-dev-port-forwarding | - |
| PJR-AQMW | done | fully-guided(refine-pass)の指示にrulebook不適合の修正を追加 | xep-fully-guided-template.mdの「4.2 既存記述の扱い」およびryu-guide.mdの「1.3 参照の共通原則」で、修正対象をdepends_onとの矛盾だけでなく、手順1で確認するrulebookの必須要素・禁止事項（章構成を含む）への不適合も含めるよう修正する。retrofit側（xep-retrofit-template.mdの判断基準表）にrulebook適合を判断基準として追加するかも合わせて検討する。フレームワーク共通ファイルのため他プロジェクトへの影響を確認のうえ反映する。 | todo | medium | ARC | 2026-08-12 | 2026-08-31 | 2026-08-12 | - | pjr-aqmw-fully-guided-refine-pass-rulebook | - |
| PJR-EZ9G | open | sch-strategy: bootstrap後にhuman review ゲートを追加 | cdfd-overview/cdfd-initのbootstrap完了後、cross_deliverable_passesでhuman review（approach: bootstrap-finalize流用、after_gate: G-DATA-FLOW-bootstrap-pass、before_phase_set: retrofit-pass）を挟み、Kata・代表成果物の品質を8成果物への複製前に確認する。次回sch-strategy-data-flow.yaml改訂時に反映する。適用前にcross_deliverable_passes x execution:humanの組み合わせをdry-runで検証すること。 | note | medium | ARC | 2026-08-12 | - | - | - | pjr-ez9g-sch-strategy-bootstrap-human-review | - |
| PJR-SDXB | done | bootstrapテンプレートに仕上げ品質チェックを追加 | xep-bootstrap-template.mdの完了手順に、内容の質を上げる基本操作（不要記述の削除・重複記述の統合・可読性のための分割・論理整合の確認）を単発の仕上げチェックとして追加する。観点別自己レビュー・修正ループとは区別し、既存の禁止事項と矛盾しないよう記述する。フレームワーク共通ファイルのため他プロジェクトへの影響を確認のうえ反映する。 | todo | medium | ARC | 2026-08-12 | 2026-08-31 | 2026-08-12 | - | pjr-sdxb-bootstrap | - |
| PJR-ZFFZ | done | cdfd 3ファイルの状態・分類詳細をstsd/cstd等へ移設 | cdfd-register-lifecycle.md（2.1/2.2/2.3）、cdfd-routine.md（2.1/2.2）、cdfd-reporting.md（2.1）にある状態定義・type分類・データ正本の詳細記載は、対応するステータス定義（stsd）・データストア定義（cdsd）等の文書を作成する際に、そちらへ移設し、cdfd側は参照へ簡潔化する。状態一覧と状態遷移図は STSD 一文書へ統合する。 | todo | medium | ARC | 2026-08-12 | 2026-09-30 | 2026-09-28 | cdfd 3 ファイルの状態・分類の詳細を stsd-register-entry・stsd-routine-run・cdsd-planning・cdsd-execution・cdsd-sharing へ移設し、移設元は参照だけにした。note の扱いは pjr-rulebook どおり終端しない定義とした | pjr-zffz-cdfd-3-stsd-cstd | - |
| PJR-3M8S | done | exec完了ガードがresultのfrontmatter破壊を検出できない | downgradeUnfilledResult/isResultUnfilled は result 本文の _TODO_ 残存有無のみを検証し、result frontmatter の必須フィールド（id/task_id/project_id/agent/approach/targets 等）の欠落・改変を検出しない。ローカルモデル等が _TODO_ を消しつつ frontmatter を独自形式へ書き換えた場合、success として扱われ commit/merge/complete まで進んでしまう（T-DATA-FLOW-cdfd-agent-config-operation-070 で実際に発生）。frontmatter 必須フィールドの非空・scaffold 値との一致検証を追加する。 | issue | high | ARC | 2026-08-10 | 2026-08-31 | 2026-08-10 | result frontmatterの破壊検出を全exec経路へ追加し、rate-limit再開時はrunner管理項目だけを許容する二段階照合で誤blockを解消 | pjr-3m8s-exec-result-frontmatter | - |
| PJR-7MXJ | done | パイプラインの再実行と復旧制御を実装する | pipeline-stateを永続化し、reporter失敗時はexecutorを再実行せずreporterから再開できるようにする。ステージ別agent指定CLIも追加する。 | todo | medium | ARC | 2026-08-10 | 2026-08-31 | 2026-08-11 | run-scoped pipeline-state.jsonの永続化・検証、exec resumeでのreporterのみ再開（executor再実行抑止）、--executor-by/--reporter-byを実装。運用・設定ガイドへ復旧手順を反映。対象57件成功。 | pjr-7mxj-pipeline-resume-recovery | - |
| PJR-H95R | done | exec complete失敗時にworktree merge/削除が巻き戻されず状態不整合になる | resume等でclaiming actorと異なるactorとして完了させると、spawnComplete(exec complete)がactor不一致で失敗してもcommitWorktreeChanges/mergeWorktreeIntoCurrent/removeWorktreeは既に完了しており、schedule状態はdoingのまま成果物だけmerge済みという不整合が生じる。complete失敗時の巻き戻し、またはmerge前のactor一致検証を検討する。 | issue | high | ARC | 2026-08-10 | 2026-08-31 | 2026-08-10 | Schedule taskの完了可否をGit統合前に検証し、actorまたはstate不一致時はworktreeを保持して統合を中止 | pjr-h95r-exec-complete-worktree-merge | - |
| PJR-JFWQ | done | executor / reporterパイプラインのスキーマを設計する | sch-strategyのagent_pipelineとpm-membersのstage_roleを定義し、既存strategyおよび既存agent設定との後方互換性を維持する。 | todo | medium | ARC | 2026-08-10 | 2026-08-31 | 2026-08-11 | sch-strategyのagent_pipeline.stagesとpm-membersのstage_roleをschema化し、既存strategy/rosterとの後方互換性を単体テストで固定。対象37件・全体993件成功（worktree系16件はsandbox制約、この実行環境では全1050件成功を確認済み）。 | pjr-jfwq-executor-reporter-pipeline-schema | - |
| PJR-JXV7 | done | executorステージとevidence収集を実装する | executorには成果物編集だけを担当させ、差分、変更ファイル、検証結果、ログ参照を構造化evidenceとして保存する。 | todo | medium | ARC | 2026-08-10 | 2026-08-31 | 2026-08-11 | executor stageの選択・専用promptとevidence.json生成（差分統計・検証・ログ抜粋・秘匿化・上限）をrunnerに実装。exec-evidence.schema.yaml追加。対象48件成功、typecheck/lint/schema検証成功。 | pjr-jxv7-executor-evidence-collection | - |
| PJR-NSXT | done | executor / reporter用エージェントを追加する | 既存のopencode-edit-agent等を変更せず、opencode-executor、opencode-reporter、codex-expert-executor等の設定と役割別プロンプトを追加する。 | todo | medium | ARC | 2026-08-10 | 2026-08-31 | 2026-08-11 | pm-members.yamlにstage_role付きのopencode-executor/opencode-reporter/codex-expert-executorを追加し、既存agent定義は変更せず候補選択を分離。対象34件成功、provider scaffold dry-runでも配布対象を確認済み。 | pjr-nsxt-executor-reporter-agent-definitions | - |
| PJR-RG7C | done | reporterステージとresult生成を実装する | reporterへplanとevidenceを引き渡し、厳格な構造化出力を検証してからrunnerがfrontmatterとresult Markdownを決定的に生成する。 | todo | medium | ARC | 2026-08-10 | 2026-08-31 | 2026-08-11 | reporterの厳格な出力契約（Ajv 2020 strict schema検証・形式不正時3回再試行）とresult決定的描画をexec-reporter.ts/exec-results.tsに実装。frontmatter不変・review RVP順序一致を確認。対象85件成功。 | pjr-rg7c-reporter-result-generation | - |
| PJR-TC43 | done | executor / reporterパイプラインのE2E検証と文書化を行う | 従来フローとの後方互換、ローカルLLM構成、クラウドagent構成、失敗・再開経路をテストし、設定例と運用手順を文書化する。 | todo | medium | ARC | 2026-08-10 | 2026-08-31 | 2026-08-11 | 従来フロー・ローカルLLM・クラウドexecutor構成・失敗/再開経路のE2Eテスト9件を追加し、exec設定/運用ガイドへpipeline構成と復旧手順を文書化。typecheck/lint/test 1050件成功、schema/catalog/index検証成功。 | pjr-tc43-executor-reporter-e2e-docs | - |
| PJR-0001 | done | スケジュール展開スクリプト | 成果物カタログからスケジュールを展開するスクリプトを開発する | todo | high | ARC | _TODO_ | 2026-05-10 | 2026-05-17 | wbsの削除やrolesの役割変更などを反映 | pjr-0001-item | - |
| PJR-0004 | done | pjr-*->generated展開スクリプト | pjr-* を generated に展開するスクリプトを開発する | todo | high | ARC | _TODO_ | 2026-05-10 | 2026-05-23 | PJR-0059で対応 | pjr-0004-pjr-generated | - |
| PJR-0006 | done | sch-<TRACK>-<DOMAIN>-<ARTIFACT>にした影響 | スクリプトへの影響を確認する | todo | high | ARC | _TODO_ | 2026-05-10 | 2026-05-04 | スクリプト影響なし | pjr-0006-sch-track-domain-artifact | - |
| PJR-0007 | done | pjr-indexのスキーマ | pjr-indexをvalidationできるようスキーマを作成する | todo | high | ARC | _TODO_ | 2026-05-10 | 2026-05-23 | PJR-0058で対応 | pjr-0007-pjr-index | - |
| PJR-0008 | done | sch-config-<track>.yamlのスキーマ | 完了したtaskやtask分解ルールを設定できるように修正 | todo | high | ARC | _TODO_ | 2026-05-10 | 2026-05-23 | PJR-0037 | pjr-0008-sch-config-track-yaml | - |
| PJR-0009 | rejected | WBS作成プロンプト | WBS統合により不要 | todo | high | ARC | _TODO_ | 2026-05-10 | 2026-05-17 | WBS統合により却下 | pjr-0009-wbs | - |
| PJR-0010 | done | claude, codex対応 | claude, codexで使えるように.agent/に設定をまとめる | todo | high | ARC | _TODO_ | 2026-05-10 | 2026-05-05 | .agent/設定を整備 | pjr-0010-claude-codex | - |
| PJR-0011 | done | StakeholderのID体系 | StakeholderのIDをわかりやすい体系に修正する | todo | high | ARC | _TODO_ | 2026-05-10 | 2026-05-04 | ID体系を修正済み | pjr-0011-stakeholder-id | - |
| PJR-0012 | done | claudeのSKILL対応 | .agent/skillsにSKILLを格納して.claude/skillsから参照する構成に変更する | todo | high | ARC | _TODO_ | 2026-05-10 | 2026-05-05 | 構成変更済み | pjr-0012-claude-skill | - |
| PJR-0013 | done | prj-overview-*作成 | rulebookを作成して、instruction, sampleへ展開する | todo | high | ARC | _TODO_ | 2026-05-10 | 2026-05-05 | rulebook/instruction/sample作成済み | pjr-0013-prj-overview | - |
| PJR-0014 | done | prj-stakeholder-register-*作成 | rulebookを作成して、instruction, sampleへ展開する | todo | high | ARC | _TODO_ | 2026-05-10 | 2026-05-05 | rulebook/instruction/sample作成済み | pjr-0014-prj-stakeholder-register | - |
| PJR-0015 | done | prj-charter-*作成 | rulebookを作成して、instruction, sampleへ展開する | todo | high | ARC | _TODO_ | 2026-05-10 | 2026-05-05 | rulebook/instruction/sample作成済み | pjr-0015-prj-charter | - |
| PJR-0029 | done | devcontainerの見直し | claude, codex, copilot用にdevcontainerの設定を見直す | todo | high | ARC | _TODO_ | 2026-05-10 | 2026-05-05 | devcontainer設定更新済み | pjr-0029-devcontainer | - |
| PJR-0030 | rejected | wbs to schedule strategyの見直し | WBS統合により不要 | todo | high | ARC | _TODO_ | 2026-05-10 | 2026-05-17 | WBS統合により却下 | pjr-0030-wbs-to-schedule-strategy | - |
| PJR-0031 | done | wbs strategyの見直し | deliverable wbsへの展開をドメイン別に作成するように見直し | todo | high | ARC | _TODO_ | 2026-05-10 | 2026-05-15 | ドメイン別展開方針を策定済み | pjr-0031-wbs-strategy | - |
| PJR-0032 | done | wbs を成果物カタログに統合 | 成果物カタログをyaml化して統合 | todo | high | ARC | _TODO_ | 2026-05-17 | 2026-05-17 | dct-*.yaml として統合完了 | pjr-0032-wbs | - |
| PJR-0033 | done | 成果物カタログのyamlからmd生成 | 可読性向上のため、yamlからmdへの変換を自動化 | todo | high | ARC | _TODO_ | 2026-05-17 | 2026-05-17 | specdojo catalog build で自動生成 | pjr-0033-yaml-md | - |
| PJR-0034 | done | wbsの削除 | 不要になったwbsファイルとその記述を削除 | todo | high | ARC | _TODO_ | 2026-05-17 | 2026-05-16 | wbs関連ファイル・記述をすべて削除済み | pjr-0034-wbs | - |
| PJR-0035 | done | dct-<domain>雛形作成 | dct-<domain>のプロジェクト横断での雛形を作成 | todo | high | ARC | _TODO_ | 2026-05-17 | 2026-05-16 | docs/specdojo/templates/ に small/medium/large 対応テンプレートを作成 | pjr-0035-dct-domain | - |
| PJR-0036 | done | pjr-indexの一覧見直し | 一覧に完了日や結果を記入する欄の追加検討 | todo | high | ARC | _TODO_ | 2026-05-17 | 2026-05-16 | 完了日 と 結論 列を追加 | pjr-0036-pjr-index | - |
| PJR-0037 | done | schedule strategyの検討 | スケジュール展開戦略の追加の検討 | todo | high | ARC | _TODO_ | 2026-05-17 | 2026-05-17 | strategy yamlを作成 | pjr-0037-schedule-strategy | - |
| PJR-0038 | done | pjr-<domain>.mdにdone_criteria追加 | done_criteriaをMarkdownに追加 | todo | high | ARC | _TODO_ | 2026-05-17 | 2026-05-17 | done_criteriaの追加をscriptで自動化 | pjr-0038-pjr-domain-md-done-criteria | - |
| PJR-0039 | done | frontmatterのtypeの見直し | deliverables-catalogなどを追加するかを検討 | todo | high | ARC | _TODO_ | 2026-05-17 | 2026-05-18 | productの小分類を見直し | pjr-0039-frontmatter-type | - |
| PJR-0040 | done | pjrの個票雛形作成 | todoなどのpjrの個票の雛形を作成 | todo | high | ARC | _TODO_ | 2026-05-17 | 2026-05-18 | 種類ごとの個票テンプレートを作成 | pjr-0040-pjr | - |
| PJR-0042 | done | pm-roles, pm-membersのschema作成 | schemaを作成して、rolesとmembersの構造を定義 | todo | high | ARC | _TODO_ | 2026-05-17 | 2026-05-17 | schemaを作成し、rolesとmembersの構造を定義 | pjr-0042-pm-roles-pm-members-schema | - |
| PJR-0043 | done | specdojo scheduleコマンドの作成 | 成果物カタログ、strategyからスケジュールを生成するコマンドを作成 | todo | high | ARC | _TODO_ | 2026-05-17 | 2026-05-17 | scheduleコマンドでスケジュール生成を自動化 | pjr-0043-specdojo-schedule | - |
| PJR-0044 | done | specdojo commandの稼働確認 | コマンドが実行できるか一通り確認 | todo | high | ARC | _TODO_ | 2026-05-17 | 2026-05-17 | buildまで確認 | pjr-0044-specdojo-command | - |
| PJR-0045 | done | viewpoint_resultsの追加 | レビュー結果の記録を追加 | todo | high | ARC | _TODO_ | 2026-05-19 | 2026-05-24 | review resultコマンドの追加 | pjr-0045-viewpoint-results | - |
| PJR-0046 | done | draft agentの作成 | たたき台の内容を作成するAgentのinstructionを作成 | todo | high | ARC | _TODO_ | 2026-05-19 | 2026-06-07 | pm-members.yamlにagentを定義 | pjr-0046-draft-agent | - |
| PJR-0047 | done | guidelines/ -> guides/へ変更 | ディレクトリ名とリンクの更新 | todo | high | ARC | _TODO_ | 2026-05-19 | 2026-05-19 | guidelines/ を guides/ にリネームし全参照を更新 | pjr-0047-guidelines-guides | - |
| PJR-0048 | done | pm-review-policy.mdの要否確認 | pm-review-policy.mdの必要性を確認 | todo | high | ARC | _TODO_ | 2026-05-19 | 2026-05-18 | 不要なため削除 | pjr-0048-pm-review-policy-md | - |
| PJR-0049 | done | specdojo reviewコマンドの作成 | reviewのplan作成などのコマンドを作成 | todo | high | ARC | _TODO_ | 2026-05-19 | 2026-05-21 | specdojo review plan等を作成 | pjr-0049-specdojo-review | - |
| PJR-0050 | done | review-viewpointsのtemplate化 | review-viewpointsをテンプレートに加える | todo | high | ARC | _TODO_ | 2026-05-19 | 2026-05-18 | テンプレートとスキーマを作成 | pjr-0050-review-viewpoints-template | - |
| PJR-0051 | done | specdojo reviewコマンドの仕様作成 | reviewコマンドの仕様を作成 | todo | high | ARC | _TODO_ | 2026-05-20 | 2026-05-19 | command usage guideに仕様を作成 | pjr-0051-specdojo-review | - |
| PJR-0052 | done | idからパスを解決するコマンドの作成 | idからファイルのパスを解決するためのDB構築と検索コマンドを作成 | todo | high | ARC | _TODO_ | 2026-05-20 | 2026-05-21 | specdojo index コマンドを作成 | pjr-0052-id | - |
| PJR-0053 | done | templateのプレースホルダーの変更 | *CAPITAL_CASE*の形式に見直し | todo | high | ARC | _TODO_ | 2026-05-20 | 2026-05-21 | PJR-0055, 0056が残件 | pjr-0053-template | - |
| PJR-0054 | done | idのリンクをMarkdown previewへ反映 | Markdown previewにidリンクを反映する機能を追加 | todo | high | ARC | _TODO_ | 2026-05-20 | 2026-05-21 | Markdown preview,VitePressにidリンクを反映 | pjr-0054-id-markdown-preview | - |
| PJR-0055 | done | pjr個票生成コマンド作成 | pjr個票をテンプレートから生成するコマンドとvalidationを作成 | todo | high | ARC | _TODO_ | 2026-05-24 | 2026-05-23 | specdojo register addを追加 | pjr-0055-pjr | - |
| PJR-0056 | done | レビュー観点生成コマンド作成 | レビュー観点yamlをテンプレートから生成するコマンドとvalidationを作成 | todo | high | ARC | _TODO_ | 2026-05-24 | 2026-05-21 | specdojo review scaffoldを作成 | pjr-0056-item | - |
| PJR-0057 | done | [[id]]を別名表示できるようにする | [[id|alt]]と別名を併記できるようにする | todo | high | ARC | _TODO_ | 2026-05-24 | 2026-05-21 | |でaltを指定可能に変更 | pjr-0057-id | - |
| PJR-0058 | done | pjr-indexのスキーマ作成 | pjr-indexのフォーマットチェックできるようにする | todo | high | ARC | _TODO_ | 2026-05-24 | 2026-05-23 | templateとスキーマを作成 | pjr-0058-pjr-index | - |
| PJR-0059 | done | pjrのscaffold | pjr-index等を自動生成するためのscaffoldを作成 | todo | high | ARC | _TODO_ | 2026-05-24 | 2026-05-23 | specdojo register scaffold, buildを追加 | pjr-0059-pjr-scaffold | - |
| PJR-0060 | done | pjr-indexのvscodeでのリアルタイム検証 | .remarkrc.yamlに追加してvscodeでリアルタイム検証 | todo | high | ARC | _TODO_ | 2026-05-24 | 2026-05-23 | remark-md-content.cjsを追加し.remarkrc.yamlに設定 | pjr-0060-pjr-index-vscode | - |
| PJR-0061 | done | sch-defaultsにあるstart_dateをsch-strategyへ移行 | sch-defaultsにはdefault_start_dateを設定、sch-strategyにはstart_dateを設定 | todo | high | ARC | _TODO_ | 2026-05-24 | 2026-05-23 | default_start_date、start_dateを設定 | pjr-0061-sch-defaults-start-date-sch-strategy | - |
| PJR-0063 | rejected | sch-strategyの名前変更 | sch-strategyをsch-configにリネーム | todo | high | ARC | _TODO_ | 2026-05-24 | 2026-05-23 | claudeからstrategyの方が適切と指摘を受けた | pjr-0063-sch-strategy | - |
| PJR-0064 | done | register.tsのTABLE_HEADERのリファクタ | TABLE_HEADERが決め打ちになっているのを修正 | todo | medium | ARC | _TODO_ | 2026-05-24 | 2026-07-23 | TABLE_HEADERをpjr-index.md由来に一本化し、章番号アンカーと派生ビューのtemplate駆動化で日本語ハードコードを除去（コミット18fc83db） | pjr-0064-register-ts-table-header | - |
| PJR-0065 | done | srcとtoolsが分かれているのを再考 | tools以下のコードもspecdojoのsrcに含めてもいいかを検討 | todo | medium | ARC | _TODO_ | 2026-05-24 | 2026-05-23 | 依存しているコードを再整理。validate-templates.tsのテスト化が残 | pjr-0065-src-tools | - |
| PJR-0066 | done | テスト環境の構築 | vitestを導入 | todo | medium | ARC | _TODO_ | 2026-05-23 | 2026-05-23 | vitestを導入し、instructionsを整備 | pjr-0066-item | - |
| PJR-0067 | done | validate-templatesをテスト化 | validate-templatesをテストに移行 | todo | medium | ARC | _TODO_ | 2026-05-24 | 2026-05-23 | catalog-scaffold, register, review-planのテストへ分解 | pjr-0067-validate-templates | - |
| PJR-0068 | done | auto-generateを追加 | ファイルの変更を検知して自動生成する機能を追加 | todo | medium | ARC | _TODO_ | 2026-05-24 | 2026-05-23 | specdojo watchコマンドを追加 | pjr-0068-auto-generate | - |
| PJR-0069 | done | register close reject等を追加 | registerのコマンドを拡張 | todo | medium | ARC | _TODO_ | 2026-05-24 | 2026-05-24 | start/wait/review/close/reject/defer/reopen/updateを追加 | pjr-0069-register-close-reject | - |
| PJR-0070 | done | sch-strategyに作成済み成果物を設定 | scheduleを生成するときに作成済みの成果物を考慮する | todo | medium | ARC | _TODO_ | 2026-05-24 | 2026-05-23 | sch-strategyにinitial_stateを追加 | pjr-0070-sch-strategy | - |
| PJR-0071 | done | specdojo buildコマンドの追加 | 生成物の一括ビルドを行うコマンドを追加 | todo | medium | ARC | _TODO_ | 2026-05-24 | 2026-05-23 | specdojo buildコマンドを実装 | pjr-0071-specdojo-build | - |
| PJR-0072 | done | 単体テストの追加 | specdojoコマンドの単体テストを追加 | todo | medium | ARC | _TODO_ | 2026-05-24 | 2026-05-24 | vitestのコードを追加 | pjr-0072-item | - |
| PJR-0073 | done | opencode用のagent memberを見直し | openspecに合わせたmemberに見直し | todo | medium | ARC | _TODO_ | 2026-05-24 | 2026-06-07 | pm-members.yamlに定義 | pjr-0073-opencode-agent-member | - |
| PJR-0074 | done | claude用のagent memberを見直し | claudeに合わせたmemberに見直し | todo | medium | ARC | _TODO_ | 2026-05-24 | 2026-06-07 | pm-members.yamlに定義 | pjr-0074-claude-agent-member | - |
| PJR-0075 | done | worktreeに合わせたdevcontainer設定の変更 | マウントの変更等を実施 | todo | medium | ARC | _TODO_ | 2026-05-24 | 2026-05-24 | specdojo-workspaceに配置するよう見直し | pjr-0075-worktree-devcontainer | - |
| PJR-0076 | done | 完了成果物をscheduleへ反映 | specdojo scheduleに完了成果物を反映して初期値をずらす | todo | medium | ARC | _TODO_ | 2026-05-26 | 2026-05-30 | 初期値をずらすのとgateの処理を追加 | pjr-0076-schedule | - |
| PJR-0077 | done | specdojo exec runの追加 | agentの実行を管理するためのコマンドを追加 | todo | medium | ARC | _TODO_ | 2026-05-26 | 2026-05-27 | specdojo exec runコマンドを実装 | pjr-0077-specdojo-exec-run | - |
| PJR-0078 | done | scheduleにgateを導入 | first_pass後にsecond_passに進めるよう、phase_gatesを導入 | todo | medium | ARC | _TODO_ | 2026-05-31 | 2026-05-30 | phase_gatesを導入、yamlとtsを修正 | pjr-0078-schedule-gate | - |
| PJR-0079 | done | taskをstep-by-stepで実行 | agentで実行する前にtaskをステップごとに実行 | todo | medium | ARC | _TODO_ | 2026-05-31 | 2026-07-22 | LAUNCH track実行の中で検証 | pjr-0079-task-step-by-step | - |
| PJR-0080 | done | 成果物のscaffoldの追加 | 成果物をprojectサイズ別に一括生成するコマンドを追加 | todo | medium | ARC | _TODO_ | 2026-05-31 | 2026-07-23 | catalog generateコマンドを追加 | pjr-0080-scaffold | - |
| PJR-0081 | deferred | metadata.jsonの要否確認 | 少なくとも更新日付は不要、ファイル自体の用途も確認 | todo | medium | ARC | _TODO_ | 2026-05-31 | - | 人向けなのでしばらく運用して不要であれば削除 | pjr-0081-metadata-json | - |
| PJR-0082 | done | pjr-by-*の統合を検討 | コミットの変更が複数で発生するので統合を検討 | todo | medium | ARC | _TODO_ | 2026-05-31 | 2026-05-30 | pjr-viewsに統合 | pjr-0082-pjr-by | - |
| PJR-0083 | done | milestoneをtimelineの上部に表示 | milestoneの表示位置をtimelineの上部に変更 | todo | medium | ARC | _TODO_ | 2026-05-31 | 2026-05-30 | 上部へ移動 | pjr-0083-milestone-timeline | - |
| PJR-0084 | done | gateをtimelineに表示 | gateをtimelineのtaskの中に表示する | todo | medium | ARC | _TODO_ | 2026-05-31 | 2026-05-30 | phase_gateをtaskの中に行表示 | pjr-0084-gate-timeline | - |
| PJR-0085 | done | specdojo:docs-structure-guideの不整合修正 | ネーミングなどの不整合を修正 | todo | medium | ARC | _TODO_ | 2026-05-31 | 2026-05-30 | guideの内容とファイル配置を修正 | pjr-0085-specdojo-docs-structure-guide | - |
| PJR-0086 | done | catalog-scaffold.test.tsの見直し | schemaでチェックできるようにしたのでテストは不要かどうかを検討 | todo | medium | ARC | _TODO_ | 2026-05-31 | 2026-07-22 | schemaチェックもtestに追加 | pjr-0086-catalog-scaffold-test-ts | - |
| PJR-0087 | done | dct-*-template.yamlのmarkdownの自動生成追加 | yamlでは可読性が低いのでmarkdown形式を自動生成する | todo | medium | ARC | _TODO_ | 2026-05-31 | 2026-07-23 | yaml-pages の dct テンプレ表示ページを catalog build と同じ表形式（成果物表＋完了条件）で描画する実装を追加（コミットd8e1b346） | pjr-0087-dct-template-yaml-markdown | - |
| PJR-0088 | done | agent-config-guideを追加 | エージェントの設定を一箇所で記述 | todo | medium | ARC | _TODO_ | 2026-05-31 | 2026-05-30 | exec-config-guide.mdに記述。設定ファイルも変更 | pjr-0088-agent-config-guide | - |
| PJR-0089 | done | claude-agent-settingsの見直し | capability, proficiencyに対応して記述を見直し | todo | medium | ARC | _TODO_ | 2026-06-05 | 2026-06-02 | agent file含めて整備 | pjr-0089-claude-agent-settings | - |
| PJR-0090 | done | agent-briefとreview planの見直し | 重複している部分があり、完全分離か統合を検討 | todo | medium | ARC | _TODO_ | 2026-06-05 | 2026-06-02 | reviewをexecに統合 | pjr-0090-agent-brief-review-plan | - |
| PJR-0091 | done | taskのcompleteとcommit,pushの整理 | taskはcompleteで終了するが、その後のcommit, pushの関係を整理 | todo | medium | ARC | _TODO_ | 2026-06-05 | 2026-07-22 | complete後にcommit, pushを実行する運用で当面実行 | pjr-0091-task-complete-commit-push | - |
| PJR-0092 | done | VitePressのルートをrepoルートに変更 | 将来的にソースコードへのリンクを容易にするため。また、vscodeの絶対パスとの整合性も保てる | todo | medium | ARC | _TODO_ | 2026-06-07 | 2026-06-10 | .vitepressをルートに移動 | pjr-0092-vitepress-repo | - |
| PJR-0093 | done | sch-strategyのexecutionのautoを見直し | executionはauto/manualになっているがautoが単語として適切か確認 | todo | medium | ARC | _TODO_ | 2026-06-07 | 2026-06-03 | manual/autoではなくhuman/agentに変更 | pjr-0093-sch-strategy-execution-auto | - |
| PJR-0094 | done | sch-strategyのexecutionが後続に反映されているか | executionがmanualの場合、agentが実行しないなど適切に処理がされるかを確認 | todo | medium | ARC | _TODO_ | 2026-06-07 | 2026-06-07 | executionをhuman,agentに見直し後続へ反映 | pjr-0094-sch-strategy-execution | - |
| PJR-0095 | done | specdojo exec buildの出力ログの修正 | ログで出力されるディレクトリが古い仕様なので修正 | todo | medium | ARC | _TODO_ | 2026-06-07 | 2026-06-02 | ログとその他の出力を修正 | pjr-0095-specdojo-exec-build | - |
| PJR-0096 | done | edit-planのfrontmatter, based_onのエラー修正 | frontmatter typeの追加とbased_onで何も表示されない不具合を修正 | todo | medium | ARC | _TODO_ | 2026-06-07 | 2026-06-02 | .remarkrc.yamlでのschema適用優先順も含め修正 | pjr-0096-edit-plan-frontmatter-based-on | - |
| PJR-0097 | done | xep-rulebookの追加 | edit plan用のrulebookを追加 | todo | medium | ARC | _TODO_ | 2026-06-07 | 2026-07-23 | xep, xrpについては自動生成のためrulebook不要 | pjr-0097-xep-rulebook | - |
| PJR-0098 | done | specdojo exec auto選択時にcapabilitiesのロジック変更 | 最小剰余を使用してcapabilitiesを選択->制約条件に変更 | todo | medium | ARC | _TODO_ | 2026-06-07 | 2026-06-07 | priorityに基づいて選択するように変更 | pjr-0098-specdojo-exec-auto-capabilities | - |
| PJR-0099 | done | exec planをcreation_mode毎に出力変更 | creation_modeを反映し、planテンプレートから生成 | todo | medium | ARC | _TODO_ | 2026-06-13 | 2026-06-10 | creation_modeをapproach_modeに変更してmode毎にテンプレート作成 | pjr-0099-exec-plan-creation-mode | - |
| PJR-0100 | done | *-instruction.mdを削除 | *-instruction.mdを廃止 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-13 | *-instruction.mdを廃止し、rulebook、標準、Skill、サイドバー、関連文書からinstruction参照を削除 | pjr-0100-instruction-md | - |
| PJR-0101 | done | xep-freeform-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0101-xep-freeform-template | - |
| PJR-0102 | done | xep-fully-guided-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0102-xep-fully-guided-template | - |
| PJR-0103 | done | xep-recipe-guided-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0103-xep-recipe-guided-template | - |
| PJR-0104 | done | xep-recipe-maintenance-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0104-xep-recipe-maintenance-template | - |
| PJR-0105 | done | xep-rulebook-maintenance-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0105-xep-rulebook-maintenance-template | - |
| PJR-0106 | done | xep-sample-maintenance-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0106-xep-sample-maintenance-template | - |
| PJR-0107 | done | xep-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0107-xep-template | - |
| PJR-0108 | done | xer-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0108-xer-template | - |
| PJR-0109 | done | xrp-freeform-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0109-xrp-freeform-template | - |
| PJR-0110 | done | xrp-fully-guided-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0110-xrp-fully-guided-template | - |
| PJR-0111 | done | xrp-recipe-guided-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0111-xrp-recipe-guided-template | - |
| PJR-0112 | done | xrp-recipe-maintenance-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0112-xrp-recipe-maintenance-template | - |
| PJR-0113 | done | xrp-rulebook-maintenance-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0113-xrp-rulebook-maintenance-template | - |
| PJR-0114 | done | xrp-sample-maintenance-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0114-xrp-sample-maintenance-template | - |
| PJR-0115 | done | xrp-template-maintenance-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0115-xrp-template-maintenance-template | - |
| PJR-0116 | done | xrp-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0116-xrp-template | - |
| PJR-0117 | done | xrr-templateの拡充 | agentへの指示を明確化 | todo | medium | ARC | _TODO_ | 2026-06-14 | 2026-06-21 | idや参考資料の参照を見直し | pjr-0117-xrr-template | - |
| PJR-0118 | done | Debian chromium 150のヘッドレス描画クラッシュ対応 | arm64 full版chromium 150.0.7871.46がヘッドレス描画時にbrk #0でクラッシュしmermaid SVG生成が失敗。chromium-headless-shellへ切替(Dockerfile変更済み)。 | issue | high | ARC | _TODO_ | 2026-07-08 | 2026-07-08 | Dockerfileを修正 | pjr-0118-debian-chromium-150 | - |
| PJR-0125 | done | specdojo:pjr-todo-templateのH1プレースホルダ不整合を修正 | pjr-todo-template.mdのH1がTASK_TITLE表記で、register addの生成ロジック（TODO_TITLE）と不一致。todo個票のタイトルが未置換で残る。他type同様のTYPE_TITLE規約へ揃える | todo | medium | ARC | _TODO_ | 2026-07-31 | 2026-07-24 | pjr-todo-template.mdのH1を_TODO_TITLE_へ修正。他type同様にタイトルが置換されることを確認 | pjr-0125-specdojo-pjr-todo-template-h1 | - |
| PJR-0141 | done | guide/reference-content.schema.yamlを言語別に整備 | schemaを言語別に分けてチェックできるように変更（.remarkrc.yamlで設定） | todo | medium | ARC | _TODO_ | 2026-07-31 | 2026-08-05 | content系schema（guide/reference/philosophy）をdocs/ja/specdojo/schemas/v1へ言語別に分離し、.remarkrc.yamlで言語別に適用済み。英語版schemaはdocs/en立ち上げ時に別途対応 | pjr-0141-guide-reference-content-schema-yaml | - |
| PJR-0142 | done | ドキュメント編集ガイドにVS Code拡張とSpecDojo拡張の説明を追加 | specdojo:docs-editing-guide に、文書編集で用いる VS Code 拡張と SpecDojo 拡張の説明を追加する。 | todo | low | ARC | _TODO_ | 2026-10-31 | 2026-09-15 | docs-editing-guide に「VS Code 拡張を準備する」を新設し、必要な拡張 4 件（remark、markdownlint、Markdown All in One、SpecDojo）の ID・役割・扱い、SpecDojo 拡張の VSIX からの導入手順と公開後の差し替え、提供機能 3 件（リンク表示・遷移、ID で開く、表整形）を記載した。guide-authoring-standard のタスク参照は拡張のコマンドへ追従済み。.vscode/extensions.json への追加は未公開 ID を推奨に入れないため公開後（PJR-0143 作業 6）とする。 | pjr-0142-vs-code-specdojo | - |
| PJR-0143 | open | VS Code拡張のMarketplace登録 | packages/vscode-specdojo 拡張を Visual Studio Marketplace へ公開する。 | todo | medium | ARC | _TODO_ | 2026-10-31 | - | - | pjr-0143-vs-code-marketplace | - |
| PJR-0144 | done | fmt-md-table を VS Code 拡張へ統合 | 現在 .vscode/tasks.json のタスク Format Markdown Table として提供している fmt-md-table を、 packages/vscode-specdojo 拡張のコマンドとして提供する。 | todo | medium | ARC | _TODO_ | 2026-10-31 | 2026-09-06 | 表整形を拡張コマンドへ移し、旧 CLI 実装を削除した。tasks.json は拡張コマンドへ委譲する形で残した。 | pjr-0144-fmt-md-table-vs-code | - |
| PJR-1D0C | done | 個票のpart_ofとwikilinkがprj-0001:pjr-indexを参照できない | prj-0001:pjr-rzr3-pjr-index-as-generated-view が追跡対象の pjr-index.md を generated/ 配下の非追跡ビューへ移し、prj-0001:pjr-9p5q-migrate-existing-register-items（2026-08-09）が追跡版 pjr-index.md 本体を削除した。これにより、文書ID prj-0001:pjr-index を参照する箇所（個票 60 件の part_of と、本文中の wikilink 10 箇所。PJR-9P5Q・PJR-RZR3 自身の 5. 関連ドキュメント を含む）が解決不能になっている。 | issue | high | ARC | 2026-08-09 | 2026-08-31 | 2026-08-09 | - | pjr-1d0c-pjr-index-wikilink-broken | - |
| PJR-37WN | done | ID 予約などの競合回避機構を撤去し renumber を縮小する | PJR-ES57 の分割5。統合ブランチ自動ルーティング・予約経路・同期 script を撤去し、renumber を乱数 ID 衝突の救済のみへ縮小する。 | todo | high | ARC | 2026-08-09 | 2026-08-31 | 2026-08-09 | 統合ブランチ自動ルーティング・予約経路・同期scriptを撤去し、renumberを乱数ID衝突の救済のみへ縮小した。 | pjr-37wn-remove-id-reservation-mechanisms | - |
| PJR-9P5Q | done | 既存登録項目を個票 frontmatter へ一括移行する | prj-0001:pjr-es57-register-file-ssot-migration の分割4。現行の登録項目一覧に存在する全行を個票へ移行する。個票を持たない項目には新たに個票を生成し、既に個票を持つ項目には表の構造化フィールドを frontmatter へ移す。 | todo | high | ARC | 2026-08-09 | 2026-08-31 | 2026-08-09 | - | pjr-9p5q-migrate-existing-register-items | - |
| PJR-BJ97 | done | CODEOWNERS 未整備により PR 承認の職務分離が強制されていない | .github/CODEOWNERS が存在せず branch protection の Code Owners 承認を強制できないため、PR 強制3ケースで自己承認が成立してしまう。 | issue | medium | ARC | 2026-08-09 | 2026-08-31 | 2026-08-26 | .github/CODEOWNERS を作成し、リポジトリ全体の承認者として @naoji3x を宣言した。独立した所有者が割り当てられた時点でより限定的なルールを追加する方針をコメントで残している。branch-workflow-guide へ、管理者が実施する branch protection の設定手順と確認項目、および統合専用 actor のみが bypass できる設計を追記した。独立した承認者がいない期間は PR 強制3ケースを承認待ちとし、作成者自身の approve と管理者権限の bypass を承認として扱わないことを明記した。緊急対応で bypass する場合も承認済みとせず例外として記録する。branch protection の設定と PR 強制3ケースの検証は GitHub 上の操作であり、リポジトリ管理者が実施する。実施後は対応結果へ追記する。 | pjr-bj97-codeowners-and-branch-protection | - |
| PJR-C0B7 | done | exec plan 共通規約へ project context の based_on 転記禁止と pre-commit 事前チェックを明記する | xep-common-conventions-template.md へ、plan のプロジェクトコンテキストを成果物 frontmatter の based_on へ転記しない旨と、完了前に pre-commit 相当の検査（prettier / markdownlint / typecheck / test / catalog validate 等）を実行し失敗を修正する旨を追記する | todo | medium | ARC | 2026-08-09 | 2026-08-31 | 2026-08-09 | xep-common-conventions-template.md へ project context を based_on へ転記しない規約と、終了前に pre-commit 相当の検査を実行する規約（変更ファイル種別と検査コマンドの対応表付き）を追記。catalog validate のメッセージ改善は既存文言で要件が示されているため見送り | pjr-c0b7-plan-context-and-precommit-check | - |
| PJR-EQAQ | done | 登録簿日時をregistered_at・completed_atへ移行する | 登録簿の起票・完了時刻をUTCのRFC 3339秒精度で記録する。既存項目はGit履歴から可能な範囲で復元し、時刻不明時は既存日付の21:00（プロジェクトタイムゾーン）として移行する。 | todo | medium | ARC | 2026-08-09 | 2026-08-31 | 2026-08-09 | - | pjr-eqaq-register-timestamps | - |
| PJR-ES57 | done | 登録簿を1項目1ファイル正本へ移行し pjr-index を生成ビュー化する | PJR-9Y7G の決定（選択肢B）に基づき、個票 frontmatter を正本、pjr-index.md を generated の派生ビューへ移行する。CLI・スキーマ・rulebook・テンプレート・既存項目移行を対象とする。 | todo | high | ARC | 2026-08-09 | 2026-08-31 | 2026-08-09 | 8件の分割先すべてが完了し、個票frontmatterを唯一の正本とする移行が完了した。 | pjr-es57-register-file-ssot-migration | - |
| PJR-GH26 | done | 台帳の差分レビュー代替手段を決めて実装する | PJR-ES57 の分割8。一覧が非追跡になることで失われる台帳全体の差分レビューについて、代替手段を決めて運用ガイドへ反映する。 | todo | high | ARC | 2026-08-09 | 2026-08-31 | 2026-08-09 | - | pjr-gh26-ledger-review-alternative | - |
| PJR-GQFX | done | register close の未記入 _TODO_ 検出がインラインコード内の文字列を誤検出する | 個票本文でインラインコードとして記述した _TODO_ を未記入欄と誤判定し、close 時に個票が ready へ昇格しない。 | issue | medium | ARC | 2026-08-09 | 2026-08-31 | 2026-08-09 | - | pjr-gqfx-todo-marker-false-positive-in-inline-code | - |
| PJR-RDNC | done | rulebook・運用ガイド・テンプレートを個票正本へ更新する | PJR-ES57 の分割7。index と個票の同期規則を削除し、個票分離基準の二分を廃止して、テンプレートを新構成へ揃える。 | todo | high | ARC | 2026-08-09 | 2026-08-31 | 2026-08-09 | - | pjr-rdnc-update-docs-for-ticket-ssot | - |
| PJR-RF3B | done | 登録項目の個票 frontmatter スキーマを定義する | PJR-ES57 の分割1。処理状態・優先度・担当・期限・完了日・結論・分類を個票 frontmatter へ定義し、共通スキーマで検証できるようにする。 | todo | high | ARC | 2026-08-09 | 2026-08-31 | 2026-08-09 | - | pjr-rf3b-register-item-frontmatter-schema | - |
| PJR-RZR3 | done | pjr-index を generated 配下の生成ビューへ移す | prj-0001:pjr-es57-register-file-ssot-migration の分割3。個票群から登録項目一覧を生成し、pjr-index.md を generated/ 配下の非追跡な派生ビューへ移す。既存の派生ビュー（状態別・優先度別・担当者別、controls 全体の type 別ビュー）も同じ入力から生成されるようにする。 | todo | high | ARC | 2026-08-09 | 2026-08-31 | 2026-08-09 | - | pjr-rzr3-pjr-index-as-generated-view | - |
| PJR-TT4J | done | register CLI の読み書き先を個票 frontmatter へ変更する | PJR-ES57 の分割2。add・状態遷移・update が pjr-index.md ではなく個票 frontmatter を読み書きするようにする。 | todo | high | ARC | 2026-08-09 | 2026-08-31 | 2026-08-09 | - | pjr-tt4j-register-cli-write-to-tickets | - |
| PJR-VC94 | done | 検証とテストを個票正本の構成へ更新する | PJR-ES57 の分割6。表専用スキーマの廃止に伴う検証経路の付け替えと、移行後の挙動を検証するテストを整備する。 | todo | high | ARC | 2026-08-09 | 2026-08-31 | 2026-08-09 | - | pjr-vc94-update-validation-and-tests | - |
| PJR-XXBC | done | result の「実践の型の活用」を「進め方と実践の型の適用」へ改称する | xer-template.md の見出しと、それを参照する xep-* テンプレート10ファイル・テストの文言を改称する。approach 由来の記録（retrofit の実装参照、freeform のプロジェクト文脈優先など）を名称で包含できるようにする | todo | low | ARC | 2026-08-09 | 2026-08-31 | 2026-08-09 | xer-template.md 第4章を「進め方と実践の型の適用」へ改称し、本文も両者を求める記述へ調整。plan テンプレート9ファイル26箇所とテスト3箇所を追随、旧名称の残存0件 | pjr-xxbc-result-approach-section-rename | - |
| PJR-0XXZ | done | pjr-indexへ登録日列を追加しタイムゾーン設定を導入する | pjr-index.mdにはID採番順序が失われた(英数字ランダムID化)ため起票順を追える列がない。登録日列(YYYY-MM-DD)を追加し、register add実行時に自動記入する。日付計算はOS/コンテナのTZに依存させず、SpecDojoRunConfigに register*date_timezone(既定UTC)を追加してIntl.DateTimeFormatで明示解決する。既存の完了日デフォルトも同じヘルパーへ統一する。手動でpjr-index.mdを直接編集する場合は不明なら_TODO*のままでよい(既存の担当・期限と同じ運用)。 | todo | medium | ARC | _TODO_ | 2026-08-31 | 2026-08-08 | - | pjr-0xxz-pjr-index | - |
| PJR-NWPC | done | register whereのエラー出力をstderrへ分離する | register whereはエラー時にprintCommandError慣例でstdoutへメッセージを書くため、npm script(register:sync-pull/register:sync-push)経由で統合ブランチworktree未用意時にgit -Cへ誤ったパス文字列として渡り、分かりにくい二重エラーになる（gitがpath不正で失敗するため実害はないがUXが悪い）。register whereのエラー出力のみstderrへ分離する。 | todo | low | ARC | _TODO_ | 2026-08-31 | 2026-08-08 | - | pjr-nwpc-register-where-stderr | - |
| PJR-25SF | done | register系タスクへのAIレビューフェーズ導入を検討する | catalog成果物はedit/review2段階のagent実行があるが、register(PJR)系タスクはeditのみでcloseの可否確認が人間任せになっている。review-agentによる自動レビューパスの導入価値と設計（対象item_type、レビュー失敗時の遷移、必須/任意、レビュー用planテンプレートと個票「完了条件」のdone_criteria相当としての参照方法）を検討する。 | todo | medium | ARC | _TODO_ | 2026-08-31 | 2026-08-08 | 自動レビューパスは任意導入(オプトイン)、対象はedit区分に限定、否時は既存register waitへ差し戻し、完了条件節をdone_criteria相当として活用する方針。実装は別途todo化する。 | pjr-25sf-register-ai | - |
| PJR-0163 | done | register addのID採番方式見直しと統合ブランチ予約のfetch同期 | PJR-IDの採番を数字4桁の連番から、曖昧文字・母音を一部除いた英大文字+数字4桁のランダムIDへ変更する。統合ブランチworktreeへの予約経路(reservePjrIdOnIntegration)はそのまま維持し、予約直前にfetch+ff-only mergeを自動実行して他マシンとの採番ズレを軽減する。push はspecdojoに含めず人間が明示実行する。衝突検知・復旧は新規フォーマットを作らず既存のregister renumberを流用する。 | todo | medium | ARC | _TODO_ | _TODO_ | 2026-08-08 | - | pjr-0163-register-add-id-fetch | - |
| PJR-4AHZ | done | routineでexec resumeからautoを順次実行可能にする | 定時実行でrate limitからの再開、状態再計算、Ready taskのauto loop実行を単一project lock内で順次処理できる仕組みを追加する。ファイル名順や時刻差に依存せず、busy・失敗・再延期・結果集約の挙動を設計し、routine定義、CLI、schema、ガイド、テストへ反映する。 | todo | medium | ARC | 2026-08-08 | 2026-08-31 | 2026-08-08 | - | pjr-4ahz-routine-exec-cycle-sequential-execution | - |
| PJR-8QA1 | done | waza-guide.md新設(cli-overview-guide.mdをWaza名称へ改称)とサイドバー・相互参照リンク更新 | cli-overview-guide.mdをwaza-guide.mdへリネームし、id・frontmatter・H1(遂行の技活用ガイド/Waza Guide)を更新する。サイドバー表示名(遂行の技活用)と、約30ファイルに及ぶ相互参照リンクを追従修正する。 | todo | medium | ARC | 2026-08-08 | _TODO_ | 2026-08-08 | - | pjr-8qa1-waza-guide-md-cli-overview-guide-md-waza | - |
| PJR-A45T | done | ryu-guide.md新設(kata-guide.mdからapproachの説明を分離)とサイドバー・相互参照リンク更新 | kata-guide.mdの進め方(approach)に関する章をryu-guide.mdへ分離し、id・frontmatter・H1(実践の進め方ガイド/Ryu Guide)を新設する。kata-guide.mdは型(rulebook/recipe/sample/template)の使い分けに焦点を絞る。サイドバー表示名(実践の進め方)と相互参照リンクを追従修正する。 | todo | medium | ARC | 2026-08-08 | _TODO_ | 2026-08-08 | - | pjr-a45t-ryu-guide-md-kata-guide-md-approach | - |
| PJR-PP0D | done | exec plan生成時にアンダースコア識別子や_TODO_がMarkdown強調記号として誤解釈され破損する | 登録簿の説明文などに含まれるregister_date_timezoneのようなアンダースコア入り識別子や_TODO_/_ASSUMPTION_プレースホルダが、exec plan生成パイプラインを通る際にバッククォートでエスケープされず、Markdownの強調記号として誤って解釈され一部が破損する（例: register_date_timezone が register*date_timezone のように壊れる）。結果としてmarkdownlintのMD049エラーでcommitがブロックされる（PJR-0XXZのclose時に実際に発生し手動修正した）。plan生成時に識別子・プレースホルダ相当の文字列を適切にエスケープ（バッククォート化）する。 | todo | medium | ARC | 2026-08-08 | 2026-08-31 | 2026-08-08 | exec-shared.tsにescapeMarkdownInlineを追加し、register add/updateの自由記述列(title/description)由来のアンダースコア/アスタリスクを含むASCIIトークンをcode span化してplan生成時のMD049誤解釈を防止。再実行(--worktree)で正常完了を確認。 | pjr-pp0d-exec-plan-todo-markdown | - |
| PJR-Q88A | done | register系コマンド全体のエラー出力をstdoutからstderrへ統一する | registerサブコマンド(add/start/wait/review/close/reject/defer/reopen/update/renumber等)はほぼ全てprintCommandError慣例でエラーをstdoutへ出す。PJR-NWPCでregister whereのみstderrへ分離したが、他のサブコマンドはstdoutのまま残っている。内部呼び出し元(spawnSelf/spawnRegisterTransition等)はstdio inherit+終了コードのみで成否判定しておりstdout内容を解析していないため、stderrへ変更しても既存の内部呼び出しへの影響はない。printCommandErrorを呼ぶ全箇所をstderrへ揃え、既存テストのstdout検証も合わせて更新する。catalog.ts/schedule.tsにも同種のstdout一本化が見られるが、対象はregister系に限定し、他コマンドへの拡張は別途判断する。 | todo | medium | ARC | 2026-08-08 | 2026-08-31 | 2026-08-08 | printCommandErrorをstderr出力へ変更し、printWhereErrorと統合(削除)。register系全サブコマンドのエラー出力がstderrに統一された。内部呼び出し元はstdio inherit+終了コード判定のため影響なし。command-referenceへ反映。 | pjr-q88a-register-stdout-stderr | - |
| PJR-ZRXG | done | register系失敗理由の文字列にANSIエスケープコードが混入し登録簿が破損する | sanitizeRegisterConclusion（src/exec-register.ts）は改行とパイプ文字のみ除去し長さを制限するが、ANSIエスケープコード（ターミナル制御文字）は除去しない。checkpoint commit失敗時（src/exec-worktree-ops.ts）はcommitted.stdout/stderrを生のまま連結してエラーメッセージにするため、lefthook等が色付き出力を返す失敗ではANSIエスケープコードがそのままpjr-index.mdの結論列やresultのblocked理由に書き込まれ表示が壊れる（PJR-PP0Dのcheckpoint失敗で実際に発生）。sanitizeRegisterConclusionにANSIエスケープコード除去を追加し、同様に生のsubprocess出力をユーザ向け文字列として扱う他の箇所（exec-worktree-opsのチェックポイント/commit/merge失敗メッセージ等）も洗い出して対応する。 | todo | medium | ARC | 2026-08-08 | 2026-08-31 | 2026-08-08 | stripTerminalControlSequences(src/exec-shared.ts)を追加し、sanitizeRegisterConclusion・checkpoint失敗メッセージ・block_reason書き出しの3箇所でANSIエスケープコード等を除去。実装レビューで正規表現に生の制御バイトが直接埋め込まれgitがバイナリ扱いする不備を発見し、\uXXXXエスケープ表記へ修正済み。 | pjr-zrxg-register-ansi | - |
| PJR-0162 | done | 旧agent指定フラグの撤去（--cmd/--agent-cmd/--edit-agent/--review-agent） | PJR-0159で導入したdeprecated aliasを、deprecation期間（1〜2リリース）後に物理撤去する。exec run/resumeの--cmd/--agent-cmd/--edit-agent/--review-agent、exec worktree agentの--agent-cmd、生コマンド受理経路（resolveAgentOverrideのagentCmdOverride分岐・auto-agentフォールバック）、--cmdによるバッチ起動判定を除去し、worktree agentのcommand供給を--by nickname解決へ付け替える。関連テストとdocsを更新する。 | todo | medium | ARC | _TODO_ | _TODO_ | 2026-08-08 | 旧agent指定フラグ(--cmd/--agent-cmd/--edit-agent/--review-agent)を物理撤去。exec run/resume/worktree agentをnickname(--by/--edit-by/--review-by/--auto)一本化。全878テスト成功を確認。 | pjr-0162-exec-agent-flag-removal | - |
| PJR-0159 | done | exec の agent 指定フラグを --by 系へ統一（--cmd/--agent-cmd 撤廃、--edit-agent/--review-agent を --edit-by/--review-by へ改名） | exec run/resume/worktree の agent 指定フラグを nickname 一本化・--by 系へ統一する。--cmd/--agent-cmd（生コマンド指定）を撤廃し agent 指定は roster nickname のみ、バッチ起動は --auto に一本化、--edit-agent/--review-agent を --edit-by/--review-by へ改名。旧フラグは deprecated alias を経て撤去。 | change-request | medium | ARC | _TODO_ | 2026-08-31 | 2026-08-07 | agent指定を --by 系（--by/--edit-by/--review-by）＋--auto へ統一。旧フラグは deprecated alias＋警告で維持し normalizeAgentFlags に集約。物理撤去は PJR-0162 で実施。 | pjr-0159-exec-agent-flag-by-unification | - |
| PJR-0157 | done | CLI生成系動詞の用語整理と破壊的リネーム | exec build→exec refresh、catalog generate→deliverable scaffoldへ改名し、生成系動詞(scaffold/build/refresh/run)の用語標準を明文化する | todo | medium | ARC | _TODO_ | 2026-08-31 | 2026-08-07 | 生成系動詞を整理し破壊的リネームを実施。exec build→exec refresh、catalog generate→deliverable scaffold(独立サブコマンド)へ改名し、schedule buildは据え置き。用語標準をguideへ明文化、コード・lefthook・docs・tests・schemaを更新、旧名はエラー化。全819テスト成功。オーケストレーターSSOT+4ラッパーも同期済み。 | pjr-0157-cli-verb-taxonomy | - |
| PJR-0156 | done | dctカタログmergeの同名group結合対応 | 同一domainの複数dctファイルで同名groupを1章へ結合し、種別ごと物理分割時の章重複を解消する | todo | medium | ARC | _TODO_ | 2026-08-31 | 2026-08-06 | mergeDomainCatalogsに同名group結合(決定的・再帰的)を実装。data-modelテンプレートをbdd/cdsd/sld/stsd/cld/ccd/cstdの7種別へ分割し、マージ後は業務データ辞書・概念モデルの2章に再構成。catalog-mergeテスト11件含め全対象テスト成功。 | pjr-0156-dct-merge-same-name-group | - |
| PJR-0155 | done | dctカタログの1 domain複数ファイル分割（物理分割）対応 | domain一意制約を緩和し、同一domainの複数dctファイルをbuild時にマージ可能にする | todo | medium | ARC | _TODO_ | 2026-08-31 | 2026-08-06 | catalog buildで同一domainの複数dctファイルをファイル名昇順でマージする機能を実装。dct.schema.yaml・dct-rulebook（物理分割の命名/ID規約とテンプレート分割）を更新し、tests/src/catalog-merge.test.ts等を追加。全テスト通過。 | pjr-0155-dct-domain-multifile | - |
| PJR-0153 | rejected | dct.schema.yaml: done_criteria のデフォルト指定(group/top)を可能にする | done_criteria を local_id 単位だけでなく、group 単位およびトップレベルでデフォルトとして指定できるようにスキーマを拡張する。 | todo | medium | ARC | _TODO_ | 2026-08-31 | 2026-08-04 | 既存dctは全件で成果物ごとにdone_criteriaを個別記述しており、group/topレベルの共通デフォルトは設計方針（成果物内容に即した検証可能な条件）と逆行するため見送り。dct-data-flow.yaml側の重複はdone_criteriaの個別化で解消済み | pjr-0153-dct-schema-yaml-done-criteria-group-top | - |
| PJR-0152 | done | 未エスケープの山括弧プレースホルダ（<lang>等）を検知するlintルールの追加 | markdown.instructions.mdは山括弧付きプレースホルダをインラインコードで囲むことを必須としているが、機械的な検知手段がない。MD033(インラインHTML禁止)は<br>や<details>等の正規HTML利用と衝突するため有効化できない。実在HTMLタグ名の許可リストを用いたカスタムルールを、既存のremarkプラグイン基盤(tools/docs/src配下、.remarkrc.yaml、lint:fm)またはmarkdownlintのcustomRulesに追加し、docs:build失敗(Vueコンパイラのタグ未クローズエラー)を未然に防ぐ | todo | medium | ARC | _TODO_ | 2026-08-31 | 2026-08-05 | 未エスケープ山括弧プレースホルダ検知のremarkプラグイン(remark-no-unescaped-angle-placeholder)を実装しroot .remarkrc.yamlへ配線。HTMLタグ許可リストで正規HTML(br/details等)を非検知、<lang>/<topic>等を検知。unit test10件・全docs誤検知ゼロ・npm run check通過を確認 | pjr-0152-lint-unescaped-angle-bracket-placeholder | - |
| PJR-0151 | done | specdojo index buildの重複ID「あと勝ち」をエラー検知に変更 | src/doc-index.tsのID登録処理(scanFile/collectFromFields)は既存キーの存在チェックをせず、Markdown/YAML/ネストIDいずれも無条件上書き(あと勝ち)になっている。同一Unit内の重複IDをエラーにし、衝突したIDと全ファイルパスを表示し、Markdown/YAML/ネストIDを同じ基準で検証し、specdojo index buildと総合validateの両方で失敗させるようにする。あわせて多言語文書(docs/en等)を言語別インデックスにするか同一論理IDの言語variantとして扱うかを決定する | todo | medium | ARC | _TODO_ | 2026-08-31 | 2026-08-07 | 多言語IDは同一論理ID＋言語スコープ解決に決定し、doc-index を言語スコープ対応に実装。標準へ反映済み。 | pjr-0151-index-build-duplicate-id-error-detection | - |
| PJR-0150 | done | pm-members.yaml のnicknameスキーマ検証欠落によるcommand_templateインジェクションリスクの解消 | pm-members.schema.yamlはnicknameに安全な文字パターン^[a-z0-9][a-z0-9_-]{0,62}$を定義しているが、loadMemberRoster(src/specdojo-config.ts)はyaml.loadのみで検証せず、package.jsonのvalidate:schema集約にもpm-members.schema.yamlが含まれていない。resolveMemberCommand(src/exec-agent-config.ts)はnicknameをcommand_templateへ無エスケープでプレースホルダ展開しshell:trueで実行するため、pm-members.yamlの書き換え権限があればコマンドインジェクションが可能。validate:schemaへのpm-members追加と、resolveMemberCommand側での再検証を行う | todo | medium | ARC | _TODO_ | 2026-08-31 | 2026-08-02 | resolveMemberCommandにnickname再検証を追加し多層防御を実装。validate:schemaへpm-members追加済み。specdojo:exec-config-guideへ反映済み | pjr-0150-pm-members-nickname-schema-validation-gap | - |
| PJR-0149 | done | 各プロジェクトにダッシュボードページを追加（schedule進捗・register状況・routine実行状況の一覧化） | 現状、プロジェクトの状況確認は、Scheduleの進捗・日程を示す execution/generated/gantt-chart.md / gantt-chart.svg、トラックの着手順序を示す Timeline（timeline/tml-index.yaml と timeline/generated/）、registerの登録・消化状況、routineの実行状況に分散しており、一目で全体像を把握できるページがない。 | todo | medium | ARC | _TODO_ | 2026-08-31 | 2026-08-18 | プロジェクトダッシュボード実装、無限ループ修正、資源枯渇の再発防止、全検証を完了 | pjr-0149-project-dashboard-page | - |
| PJR-0148 | done | docs/外への[[id]]（wikilink）解決範囲拡張の要否検討 | 現状specdojo index buildの走査対象はdocs/配下のみで、.github/instructions/やREADME.md等docs/外のファイルは[[id]]で参照できない。docs/外への[[id]]解決範囲拡張が必要かどうかを、走査対象拡大に伴う除外ロジック変更・frontmatter契約の非互換・ID衝突リスク等を踏まえて検討する | todo | low | ARC | _TODO_ | 2026-09-30 | 2026-09-05 | docs/ 外への wikilink 拡張は現時点では行わない。参照需要は実在するが、改名実績が 6 ファイル中 1 件と少なく、追従は一括置換で対処できるため。 | pjr-0148-extend-wikilink-id-resolution-beyond-docs-scope | - |
| PJR-0147 | done | 実装先行（コード先行）時に設計書/仕様書/要件書へ反映・新設するapproachの整備 | 実装が既に存在するにもかかわらず対応する設計書/仕様書/要件書が未整備、または内容が乖離している場合に、実装内容を既存文書へ反映するか、文書が存在しない場合は新設するための判断基準・手順（approach）を策定する | todo | medium | ARC | _TODO_ | 2026-08-31 | 2026-08-07 | retrofit approachとevidence_refsを実装。型/CLI/schema/edit・review planテンプレート整備、data-flow全10成果物へ適用、関連ガイド反映、125テスト通過 | pjr-0147-retrofit-design-docs-for-existing-implementation | - |
| PJR-0146 | done | 履歴蓄積ファイル（plan/result/pjr-NNNN-<topic>等）はMarkdownリンクを禁止し[[id]]/パス表記に統一するルール化 | plan/result/pjr-NNNN-<topic>等の履歴として蓄積されるファイルは、リンク先のファイル名変更時に修正が発生してしまうため、Markdownリンク[]()を使わず、docs/配下の参照は[[id]]、docs/外の参照・外部URLはパス表記/URLのままとするルールを定め、関連する記述ルール文書（例: markdown.instructions.md等）へ反映する | todo | medium | ARC | _TODO_ | 2026-08-31 | 2026-08-05 | 履歴蓄積ファイル(plan/result/個票)のMarkdownリンク禁止・[[id]]/パス表記統一ルールをmarkdown.instructions.mdへ追加し、検知CLI(validate-history-links)とunit testを実装、npm run checkへ組み込み。既存違反0件のため一括遡及移行は不要 | pjr-0146-forbid-links-in-history-files | - |
| PJR-0140 | done | register commitがhook整形差分と失敗残骸を取りこぼす | pathspec commitでhookの整形差分がindexに残り、次ID実行の開始前スナップショットに載って commit 対象から丸ごと除外される。失敗試行の残骸とrunner自身の状態遷移も同様に取りこぼす | issue | high | ARC | _TODO_ | 2026-07-31 | 2026-07-26 | hook整形差分が出る場合は再度commitするように変更 | pjr-0140-register-commit-missed-paths | - |
| PJR-0139 | done | 個票frontmatterのstatus遷移を自動化 | 個票のstatus遷移時期が規約に無くコマンドも更新しないため全件がdraftのまま残る。close/rejectで個票をready/deprecatedへ更新し、遷移基準をrulebookへ明記する | todo | medium | ARC | _TODO_ | 2026-07-31 | 2026-07-26 | 個票frontmatterのstatus遷移をcloseで実行 | pjr-0139-register-ticket-status-transition | - |
| PJR-0137 | done | pjr-indexの重複ID検知と再採番 | 並行作業でPJR-IDが重複しても検知できないため、schemaでID一意性を検証し、重複時に表・個票ファイル名・リンク・plan/resultのtargetsを一括更新するrenumberコマンドを追加する | todo | medium | ARC | _TODO_ | 2026-07-31 | 2026-07-26 | PJR idの重複検知と再採番を追加 | pjr-0137-register-id-uniqueness | - |
| PJR-0138 | done | 起票を統合ブランチへ委譲するregister add | 作業worktreeを離れずにPJR-IDを予約できるよう、register addが統合ブランチのworktreeへ登録行だけを追記・commitするモードを追加し、表末尾の追記競合を解消する | todo | low | ARC | _TODO_ | 2026-07-31 | 2026-07-26 | idの--reserveオプションを追加 | pjr-0138-register-add-on-integration-branch | - |
| PJR-0124 | done | human実行時のplan非生成とresultへの統合 | execution:humanはplanを読まないため、human時はplanを生成せずresultへ統合し、commitスコープをresult由来に切替える | todo | medium | ARC | _TODO_ | 2026-07-31 | 2026-07-25 | human実行時のplan生成を廃止し、done_criteria確認をresultへ集約。commitスコープはhumanではresult frontmatterのtargets由来へ切替え（コミット0e0db54a） | pjr-0124-human-plan-integrate-result | - |
| PJR-0128 | done | exec planへproject contextを伝播 | 全ての対象成果物生成でprj-overviewを参照できるよう、depends_onと分離したproject contextをexec planへ追加する | todo | high | ARC | _TODO_ | 2026-07-31 | 2026-07-26 | project contextをtemplateに追加 | pjr-0128-propagate-project-context | - |
| PJR-0129 | done | Why-What-How作成原則をrecipeへ反映 | Why・What・How・Traceを章順ではなく論理の骨格として定義し、各成果物recipeへ重複なく適用する | todo | medium | ARC | _TODO_ | 2026-07-31 | 2026-07-26 | specdojo:recipe-authoring-standardにWhy/What/How/Traceを論理の骨格として定義し、全16 recipeへ成果物固有の問いと委譲境界を反映（コミット67f8049d） | pjr-0129-why-what-how-recipes | - |
| PJR-0131 | done | 簡潔な文書作成の共通原則をdocumentation policyへ追加 | 文書全体に適用する簡潔性・重複回避・正本参照・文章量の目安をdocumentation policyの共通原則として定義する | todo | medium | ARC | _TODO_ | 2026-07-31 | 2026-07-26 | 簡潔な文書作成の共通原則を追加 | pjr-0131-concise-documentation-policy | - |
| PJR-0133 | done | bootstrap後に成果物間の重複を整理する横断passを追加 | bootstrap完了後、refine前に成果物群を横断して正本を選択し、重複記述を要約と参照へ置き換える直列passを設ける | todo | high | ARC | _TODO_ | 2026-07-31 | 2026-07-26 | 横断pass, dedup approachを追加 | pjr-0133-cross-deliverable-dedup-pass | - |
| PJR-0134 | done | exec run --autoを連続worker pool化 | parallel実行でagentが完了するたびに空いた実行枠へ次のReady taskを投入できるようにする | todo | high | ARC | _TODO_ | 2026-07-31 | 2026-07-26 | 連続worker pool方式へ変更 | pjr-0134-exec-auto-worker-pool | - |
| PJR-0135 | done | exec run --registerの複数ID直列実行 | 複数のPJR-IDを指定順に実行し、ID単位のcommit有無と失敗時の継続方針を選択できるようにする | todo | high | ARC | _TODO_ | 2026-07-31 | 2026-07-25 | exec run --register を複数PJR-IDの指定順直列実行へ拡張し、ID単位commitと失敗時の停止・継続を選択可能にした | pjr-0135-exec-register-multiple-ids | - |
| PJR-0136 | done | agent利用制限後の自動再開 | 利用制限で継続できないtaskの再開可能時刻を記録し、定時routineから安全に再実行できるようにする | todo | high | ARC | _TODO_ | 2026-07-31 | 2026-07-26 | 利用制限に達した場合にroutineで再開 | pjr-0136-exec-limit-resume | - |
1.2. BA
| ID | ステータス | タイトル | 説明 | 分類 | 優先度 | 担当 | 登録日 | 期限 | 完了日 | 結論 | 個票 | depends_on |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PJR-FMJ5 | done | v0.5.0 を公開する | 0.4.7 以降の変更（成果物 type の移行という破壊的変更を含む）を v0.5.0 として検証し、main へ昇格して npm に公開する | todo | high | BA | 2026-10-29 | 2026-10-31 | 2026-10-29 | PR #25 で main へ昇格し、specdojo 0.5.0 と @specdojo/docs-lint・@specdojo/docs-site 0.3.0 を npm に公開した。npm latest、タグの workflow 4 件、npm からの導入と init を確認した | pjr-fmj5-release-v0-5-0 | PJR-0QW0 |
| PJR-E6QA | done | v0.4.7 を公開する | PJR-6WQY・P14M・K87Y・MB92・TVGA を v0.4.7 として検証し、main へ昇格して npm に公開する。 | todo | high | BA | 2026-10-26 | 2026-10-31 | 2026-10-26 | PR #24 で main へ昇格し、v0.4.7 を npm に公開した。npm latest、タグの workflow、npm からの導入と init を確認した。 | pjr-e6qa-release-v0-4-7 | - |
| PJR-34F2 | done | 体系の名前を成果物・型・技に改め、標語と PDCA マトリクスを文書へ反映する | PJR-9G9Y の決定（C、名前は成果物・型・技）に従い、全体概要ガイドの 3 つの体系を成果物・型（Kata）・技（Waza）に改め、流（Ryu）をそれらをつなぐ属性として説明する。標語・遂行の PDCA マトリクス・「仕様書」の語・app1-workspace/ を文書へ反映する | todo | high | BA | 2026-10-12 | 2026-10-31 | 2026-10-12 | 体系の名前を成果物・型・技に改め、標語・PDCA マトリクス・仕様書の語・app1-workspace/ を文書へ反映した | pjr-34f2-terminology-kata-waza-docs | - |
| 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-EVAX | done | README と全体概要ガイドの冒頭を「Spec道（仕様道）の道場」に揃える | LP の Hero の小見出しを「Spec道（仕様道）の道場」とした。README・ドキュメントサイトのトップ・全体概要ガイド・遂行の技活用ガイドの「仕様道（Spec-Dō）の道場」を同じ表記に揃える | todo | medium | BA | 2026-10-12 | 2026-10-31 | 2026-10-19 | README・ドキュメントサイトのトップ・全体概要ガイド・技のガイドの 4 か所を「Spec道（仕様道）の道場」にそろえた。CHANGELOG の過去の記載と package.json の英語の説明は変えていない。gemma（2 回）と qwen は README.md を編集する権限がなく（opencode の executor の edit は docs・src・tests だけ）、README は agy-expert-executor で直した | pjr-evax-spec-do-notation | - |
| PJR-S64H | done | 用語集 gl-common に記帳と起票を加える | 起票（1 件の項目を新しく作ること）と記帳（起票・状態遷移・結論の記録・commit を含む、台帳への書き込み全般。register の Waza としての呼び名）の使い分けを、用語集 gl-common に定義する | todo | medium | BA | 2026-10-12 | 2026-10-31 | 2026-10-18 | 用語集 gl-common に tm-filing（起票）と tm-record-keeping（記帳）を加え、起票が記帳の一部であることと、register の技としての呼び名が記帳であることを notes に書いた | pjr-s64h-glossary-kicho-kihyo | - |
| PJR-WJE6 | done | ブランチワークフローガイドにプロダクトリポジトリの節を加える | PJR-ZDVQ の決定にもとづき、プロダクトリポジトリにはブランチ戦略を求めず、プロダクト側のルールで決めた統合先（integration_branch）を指定することを書く。GitHub flow と git flow での選び方の例と、merge の方式ごとの Refs: の残り方を示す | todo | medium | BA | 2026-10-12 | 2026-10-31 | 2026-10-19 | branch-workflow-guide に「10. プロダクトリポジトリの統合先を指定する」を加え、統合先の指定、GitHub flow と git flow での選び方、merge の方式ごとの Refs: と SHA の残り方、trace key での追跡を書いた。GitHub flow の例の誤りと、登録簿への参照などの 4 点は PJR-8C6E で直す | pjr-wje6-product-repo-branch-guide | - |
| 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-6V3D | done | bps-sample の業務ロジックの不整合と存在しない参照先を解消する | bps-sample.md は prj-0001:pjr-t3nn-bps-rulebook-rulebook-authoring-standard で作り直され、blocker は解消したが needs-work（64 点、major 4 件）である。残る指摘は業務ロジックの不整合と用語の未定義であり、rulebook や template の問題ではない。sample 自体の品質として解消する。 | todo | medium | BA | 2026-09-26 | _TODO_ | 2026-09-27 | 確定の定義を S-03 承認・終了点を S-04 引き渡しに揃え、CDFD 列を P-06 に統一、未完了依頼の欠落時の例外と E-03 の受入観点を加え、補充必要数の算出を br-reorder-point へ委ねた。grade は 64→91（pass、major 0） | pjr-6v3d-bps-sample | - |
| PJR-MH9E | done | 成果物カタログの BPS 29 件を現行 CDFD の 14 領域へ追従させる | dct-business-model-bps.yaml の BPS 29 件は、cdfd-overview.md を 14 領域へ書き換える前の**旧 10 領域体系**の P 番号を overview に記載している。同じ P 番号が現行では別の領域を指すため、カタログの記述から対象プロセスを特定できない。29 件の分割と overview を現行 CDFD へ追従させる。 | todo | high | BA | 2026-09-26 | _TODO_ | 2026-09-26 | - | pjr-mh9e-bps-29-cdfd-14 | - |
| PJR-QD81 | done | 用語集 gl-common を作成し概念名と英語名の対応を確定する | カタログ dct-glossary.yaml は gl-common（用語集・共通）を定義するが未作成である。prj-0001:pjr-00qv-cdfd-rulebook で、データストア名のうち 5 件は単一の英語名を確定できず併記を見送った。概念名と英語名の対応は用語集が正本であり、CDFD 側へ分散させると乖離する。用語集を作成して対応を確定する。 | todo | medium | BA | 2026-09-26 | _TODO_ | 2026-09-29 | gl-common.yaml を作成し、gl-rulebook の terms に englishName を加えた。単一名を持たない実行記録・評価結果は構成要素を個別に定義し、総称と分類の用語も加えて 22 語とした。対象は cdfd-overview のデータストアとその構成要素 | pjr-qd81-gl-common | - |
| PJR-6PD7 | in-progress | 詳細 CDFD をプロセスグループ別・ユースケース別へ再作成する | cdfd-overview を見直し、詳細化先を「領域別 CDFD（1 領域 1 文書）」から「プロセスグループ別 CDFD（Onboarding／Plan／Do／Check／Action／Orchestrator の 6 文書）＋横断ユースケース別 CDFD」へ改めた。これに伴い、プロセスグループ別 CDFD 6 件とユースケース別 CDFD 2 件（cdfd-uc-register: 登録簿起票から完了まで、cdfd-uc-deliverable: 成果物の作成から完了まで）を新規に作成し、現行の領域別 CDFD 10 件は非推奨化して trash へ退避する。 | todo | medium | BA | 2026-09-13 | 2026-09-30 | - | - | pjr-6pd7-cdfd-overview | - |
| PJR-1Z1H | done | rulebookのsample未宣言55本と成果物のrulebook未宣言10件を突き合わせる | sample の実ファイルは107本あり rulebook 106本とほぼ1対1だが、rulebook frontmatter で sample を宣言しているのは51本のみで、bps や bac など55本は実ファイルがあるのに未宣言である。実践の型の宣言箇所が rulebook frontmatter と成果物カタログの2か所にあり、片方が更新されていない。あわせてカタログ側で rulebook を宣言していない散文成果物10件も調査して宣言する。 | todo | medium | BA | 2026-08-23 | 2026-08-31 | 2026-08-24 | rulebook 55本へ sample 宣言を追加し、宣言済みを106本中101本とした。残る5本は sample の実ファイルが存在しないため宣言しない。成果物カタログへ rulebook 宣言を8件追加し、宣言と実ファイルの食い違いを検知する双方向の検証を catalog-build へ追加した。kata.ts の解決順序のコメントを実装に合わせて修正し、解決処理そのものは変更していない。複数の sample を持つ系統が12本あったため sample の配列宣言に対応した。この点は当初の完了条件が1系統1sampleを前提としており実態と合っていなかった。実行時の統合テスト失敗は追加した検証がディレクトリ不在を考慮していなかったことによる退行で、ガードを追加して解消した。 | pjr-1z1h-rulebook-sample-declaration-gap | - |
| PJR-5N64 | done | templateをrulebook宣言から解決し系統単位の標準templateを整備する | catalog-generate.ts の findTemplate はカタログの template 宣言を参照せず、local_id 命名規約でのみ解決するため、同一 rulebook 系統に複数件が並ぶ成果物へ template を共有できない。rulebook の多くが本文構成の章に見出しの羅列を持ち、実質 template を人間にしか読めない形で保持している。 | todo | high | BA | 2026-08-23 | 2026-08-31 | 2026-08-26 | template の解決元を local_id 命名規約から rulebook frontmatter の宣言へ変更し、同一系統の成果物が1つの template を共有できるようにした。正本が rulebook であるため命名規約による解決は意図的に残していない。4状態のうち文書IDは使用し、not-needed・undecided・項目の省略はカタログ情報による最小雛形へ退避する。成果物情報を展開するプレースホルダを追加し、代表として OPR 系統を template 化して rulebook の本文構成章を規約へ整理した。本文構成を持つ92本すべての template 化は範囲外とし、固定骨組みを持たない系統まで切り出すと undecided の意味を失うことを理由として記録した。命名規約の廃止で到達不能になる成果物用 template がないことも確認した。 | pjr-5n64-template-declaration-resolution | - |
| PJR-JT1Y | done | 未着手成果物の実践の型の要否を未判断として区別できるようにする | PJR-K4TA では未作成の散文成果物171件に not-needed を宣言したが、PJR-QESV は要否を初回の bootstrap で判断すると決めており、bootstrap 前に不要と確定するのは決定と矛盾する。原因は基準が「項目なし」を要否未判断と必要だが未整備の2つの状態に兼用しており、未判断を表す値がないことにある。undecided 相当の明示値を追加して3状態を区別し、未着手171件の not-needed を撤回する。 | todo | high | BA | 2026-08-23 | 2026-08-31 | 2026-08-24 | 実践の型の要否と整備状況を undecided・項目の省略・文書ID・not-needed の4通りで区別できるようにし、schema と検証・生成処理を対応させた。PJR-VV3M の種別ごとの作成方針を実践の型ガイドへ反映し、sample は rulebook がある系統へ一律に作る、template は rulebook 系統単位で判断する、recipe は独立して判断する、を明記した。未作成の散文成果物155件を undecided へ移行し、実在する成果物の宣言は変更していない。新規プロジェクトのカタログ雛形にも同じ移行を適用した。 | pjr-jt1y-kata-undecided-state | - |
| PJR-K4TA | done | 実践の型の要否宣言を導入し、既存の実践の型を棚卸しする | PJR-QESV の決定に基づき、成果物カタログへ実践の型の要否を宣言できるようにする。作らないと判断した型は not-needed として記録し、未整備と区別する。strategy 生成では not-needed の型に対応する maintenance フェーズを生成しない。あわせて ryu-guide の bootstrap と freeform の記述を決定内容へ揃え、既存の rulebook 106 件、recipe 19 件、sample 107 件、template 93 件を基準に照らして分類する。 | todo | high | BA | 2026-08-23 | 2026-08-31 | 2026-08-24 | 成果物カタログの各成果物へ rulebook / recipe / sample / template の要否を宣言できるようにし、不要と判断した型は not-needed と明示する仕組みを導入した。kata-guide に4種それぞれの作る条件と作らない条件を追加し、catalog build が宣言の実在性を検証、schedule assessment が not-needed の型を維持タスクの対象から外すようにした。prj-0001 の全成果物へ要否を宣言し、ID宣言496件はすべて実在する型へ解決する。未作成成果物への一律の not-needed は PJR-JT1Y で undecided へ移行した。 | pjr-k4ta-kata-not-needed-declaration | - |
| PJR-K9KG | done | 実在する成果物が参照する rulebook 系統の実践の型の要否を確定する | 実物がある成果物は基準を適用して要否を確定できる。PJR-XGJK により要否の宣言先は rulebook frontmatter へ移り、判断の単位も成果物ごとから rulebook 系統ごとへ変わった。本項目は、実在する成果物が参照する系統のうち要否が未確定のものを確定させる。 | todo | medium | BA | 2026-08-23 | 2026-08-31 | 2026-08-25 | 実在成果物が参照する5系統（opr、sysd-index、sysd-critical-flows、sysd-cross-cutting-policy、tsd）の recipe と template の要否を、実物の章構成と反復構造に照らして確定した。多くは必要だが未整備として項目を省略し、sysd-index の recipe と tsd の template は不要と判断した。sample: not-needed は8系統から4系統へ減らし、schema が構造を完全に規定する YAML 成果物3系統と include 専用 rulebook 1系統に限定して理由と適用範囲を記録した。not-needed としながら sample が実在した ccd-mermaid と ifd-mermaid は文書ID の宣言へ改め、双方向検証の警告を解消した。型そのものの新規作成は範囲外とした。 | pjr-k9kg-kata-requirement-existing-deliverables | - |
| 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-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-MWXS | deferred | uis-index / bds-index の実践の型（kata）一式の新設 | uis-index・bds-index 成果物向けのHub専用 rulebook が存在しない。bes-index-rulebook.md に倣い、rulebook だけでなく recipe・sample・template を含む kata 一式を新設する。 | todo | medium | BA | 2026-08-14 | 2026-08-31 | - | bootstrap approachへ委譲。user-interface-modelトラックがtml-rulebook.mdの定める順序でSchedule化され、sch-strategy-user-interface-model.yamlにuis-index/bds-indexのowner_rulesが定義された時点で、approach: bootstrapのタスクとして再開する | pjr-mwxs-uis-index-rulebook-bds-index-rulebook | - |
| PJR-0127 | done | prj-overviewのプロジェクトWhyを明確化 | 後続文書の論点を安定させるため、対象者・課題・中心仮説・価値仮説・判断原則をプロジェクト概要の正本として明確化する | todo | high | BA | _TODO_ | 2026-07-31 | 2026-07-26 | IDを付与してトレースを明確化 | pjr-0127-clarify-project-why | - |
1.3. DEV
| ID | ステータス | タイトル | 説明 | 分類 | 優先度 | 担当 | 登録日 | 期限 | 完了日 | 結論 | 個票 | depends_on |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PJR-5EN3 | done | docs-lint の md-content を設定なしで使うと落ちる | remark/md-content を options なしで読み込むと options.schemas の読み取りで TypeError になるため、options がないときは空として扱う。 | todo | high | DEV | 2026-10-31 | 2026-11-30 | 2026-10-31 | remark/md-content を options なしで読み込んだときに空の options として扱うようにし、_CONTEXT_ の検出が動くことを単体テストで確かめた。ほかの公開プラグインの options なしの動きも確かめた | pjr-5en3-docs-lint-md-content-no-options | - |
| PJR-73KT | done | 雛形作成の案内を deliverable scaffold --target の形にそろえる | schedule-design-guide・xer-human-draft-template・plans-planning.ts に残る deliverable scaffold --project <project-id> --dct <catalog> の案内を、成果物を 1 つだけ作る --target の形に直す。 | todo | medium | DEV | 2026-10-31 | 2026-11-30 | 2026-10-31 | schedule-design-guide・xer-human-draft-template・plans-planning.ts の雛形作成の案内を deliverable scaffold --target の形にそろえ、関連するテストの文言を合わせた | pjr-73kt-scaffold-target-guidance | - |
| PJR-790T | done | 入力の章がない種類の個票で入力の見出しに番号を付ける | decision など 入力 の章がない種類の個票へ --input を書くと、番号のない ## 入力 が末尾に足されるため、番号付きの章として適切な位置に入れる。 | todo | medium | DEV | 2026-10-31 | 2026-11-30 | 2026-10-31 | 入力の章がない個票へ --input を書くと、最初の章の直後に番号付きの入力の章を入れ、後ろの章と小節の番号を繰り下げるようにした。PJR-BNMV の番号のない入力の章を直した | pjr-790t-register-input-heading-number | - |
| 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-FK0Y | done | 負荷で時間切れになる単体テストを直す | 統合のときの全件テストの負荷で 5 秒の上限を超える catalogless-target.test.ts と grade-per-document.test.ts を、上限の延長かテストの軽量化で安定させる。 | todo | medium | DEV | 2026-10-31 | 2026-11-30 | 2026-10-31 | catalogless-target.test.ts のスイートと grade-per-document.test.ts の該当テストに限って上限を 30 秒に延ばした。原因の調査と、同じ形で時間切れになりうるテストの一覧を個票に残した | pjr-fk0y-unit-test-timeout-under-load | - |
| PJR-M1DH | done | プロダクトのリポジトリの作業ブランチの名前を設定で選べるようにし、早送りの統合を足す | repos[].branch_template で作業ブランチの名前を選べるようにし、run と作業ブランチの対応を runner の記録で持ち、名前の重なりを run の開始時に検査し、統合の形に ff を足す。 | todo | medium | DEV | 2026-10-31 | 2026-11-30 | 2026-10-31 | repos[].branch_template で作業ブランチの名前を選べるようにし、run と作業ブランチの対応をプロダクトの git の管理ディレクトリの記録で持つようにした。名前の重なりを start の前に検査し、exec run --branch と integration_strategy: ff を足した | pjr-m1dh-product-branch-template-ff | PJR-TC62, PJR-Z7GX |
| PJR-TC62 | done | 個票に commit の type と scope を持たせる | プロダクトのリポジトリの commit の type と scope を項目ごとに選べるよう、個票に commit_type と commit_scope を持たせ、register add と update で指定できるようにする。 | todo | medium | DEV | 2026-10-31 | 2026-11-30 | 2026-10-31 | 個票に commit_type と commit_scope を足し、register add と update の --commit-type と --commit-scope で指定と消去をできるようにした。指定がないときは項目の type から決め、対応は project と repos[] の commit_types で上書きできる。後続の項目から引く関数を設けた | pjr-tc62-item-commit-type-scope | - |
| PJR-Z7GX | done | プロダクトのリポジトリの commit と merge commit の書式を設定で選べるようにする | repos[] の commit_subject_template と merge_message_template で、プロダクトのリポジトリへ exec が積む commit の 1 行目と merge commit のメッセージを、運用に合わせて選べるようにする。 | todo | medium | DEV | 2026-10-31 | 2026-11-30 | 2026-10-31 | repos[] の commit_subject_template と merge_message_template で、プロダクトのリポジトリの commit の 1 行目と merge commit を選べるようにした。末尾の Refs は常に付き、空の scope は括弧ごと除く。未設定の merge の既定は互換のため今の exec(register ...) を保ち、Merge branch の形はテンプレートで選ぶ | pjr-z7gx-product-commit-message-template | PJR-TC62 |
| PJR-P9ZC | done | 接続のスクリプトが、対象の devcontainer が止まっていると別の container へ入ろうとして失敗する | specdojo-tmux.sh.sample の find_container は、ラベルで見つからないと vsc- で始まる最初の container を選ぶ。そのため対象の devcontainer が止まっていると、別の container へ docker exec して「chdir to cwd ... no such file or directory」で止まる。ラベルの一致だけで探し、見つからなければ devcontainer up するように直す | issue | high | DEV | 2026-10-29 | 2026-10-31 | 2026-10-31 | specdojo-tmux.sh.sample の find_container を、ラベル devcontainer.local_folder が一致する container だけを返す形にし、見つからなければ devcontainer up を流すようにした。docker exec の前に作業ディレクトリの有無を確かめ、ガイドと冒頭のコメントにラベルの扱いを書いた | pjr-p9zc-remote-tmux-wrong-container | - |
| PJR-0D0T | done | YAML の成果物の type を原則に沿った値にそろえる | bdd の domain を data、ifx-cmd・ifx-msg の command・message を api にするなど、YAML の type を成果物の type の値にそろえ、schema・rulebook・テンプレート・sample を直す。古い値はエラーにし、置き換え先を示す。YAML の表示用ページは YAML の type を引き継ぐ | todo | low | DEV | 2026-10-27 | _TODO_ | 2026-10-28 | bdd を data、ifx-cmd・ifx-msg を api、gl を glossary にそろえ、旧値は置き換え先を示してエラーにした。YAML の検証でも rulebook の宣言と照合し、表示用ページは YAML の type を引き継ぐ | pjr-0d0t-yaml-deliverable-type-alignment | PJR-484B |
| PJR-8NWR | done | grade の結果ファイルが別リポジトリの同じ ID の文書で重なる | grade の結果は results/<文書 ID>.yaml に保存され、ID はプロダクトリポジトリの成果物では project の修飾を持たない。project.repos の複数のリポジトリや本リポジトリに同じ ID の文書があると、結果が黙って上書きされ、plan も別の文書の前回の結果を読む。repos のリポジトリの文書は results/<repo 名>/<ID>.yaml に分けて保存する。 | issue | medium | DEV | 2026-10-27 | _TODO_ | 2026-10-28 | project.repos のリポジトリの文書の grade の結果を results/<repo 名>/<文書 ID>.yaml に分けて保存するようにした | pjr-8nwr-grade-result-path-repo-collision | - |
| PJR-B5TY | done | Mermaid の図の構文を lint で検査する | markdownlint と remark は Mermaid の中身を検査せず、図の構文エラーは docs:build か docs:dev で図を描くまで分からない。sandbox の executor も気づけない。変更した Markdown の Mermaid を構文解析する検査を lint の段に加える。 | todo | low | DEV | 2026-10-27 | _TODO_ | 2026-10-31 | ブラウザを使わずに mermaid.parse で Markdown の Mermaid の構文を検査する tools/lint-mermaid.mjs を追加した。docs-site と同じ mermaid 12 を使い、本リポジトリの 8 種類 189 個の図はすべて通った。npm の script・lefthook・親の検証への組み込みは保護された設定のため案を個票に残し、利用者の承認のもとで反映する | pjr-b5ty-mermaid-syntax-lint | - |
| PJR-H988 | done | plan が grade の finding の anchor を Markdown のまま書き出す | src/exec/plans-core.ts と src/exec/plans-storage.ts は finding の anchor を引用符で囲んで plan に書く。対象の行に Markdown リンクがあると plan が validate:history-links に落ち、npm run check が失敗する。anchor（と message）をインラインコードなどで無害化して書き出す。 | issue | medium | DEV | 2026-10-27 | _TODO_ | 2026-10-28 | plan に書く finding の anchor と本文をインラインコードで書き出し、Markdown リンクを含んでも履歴リンクの検査を通るようにした | pjr-h988-plan-finding-anchor-escape | - |
| PJR-N9JC | done | Mermaid の構文エラーで docs:dev と docs:build が止まる | @specdojo/docs-site の gen-mermaid-svg.ts は、ファイルがない場合以外の図の生成のエラーを投げ直すため、1 つの図の構文エラーで dev サーバーとビルドが止まる。エラーの図を警告して飛ばし、ほかのページを表示できるようにする。ビルドで失敗として扱うかは対応時に決める。 | issue | medium | DEV | 2026-10-27 | _TODO_ | 2026-10-28 | dev は構文エラーの図を警告して飛ばし、build はすべての図を処理してからまとめて失敗するようにした | pjr-n9jc-docs-site-mermaid-error-tolerance | - |
| PJR-XSM8 | done | sample-maintenance の起票が sample の type 判定で止まる | register add / update の sample-maintenance は、対象の frontmatter の type が sample であることを求める。同梱の Markdown の sample 98 件のうち 93 件と YAML の sample 11 件は見本にする成果物の type（project など）を使うため、起票できない。sample の判定を命名（*-sample）に揃え、sample の type の原則を規約に定める。 | issue | high | DEV | 2026-10-27 | _TODO_ | 2026-10-27 | sample-maintenance の判定を ID の末尾 -sample に改め、sample の type は見本にする成果物の type とする原則を document-metadata-standard を正本に定めた | pjr-xsm8-sample-maintenance-target-kind | - |
| PJR-50YH | done | scaffold の markdownlint 設定のせいで、VS Code でファイルごとの規則を当てられない | init --lefthook が生成する .markdownlint.jsonc があると、VS Code の拡張（markdownlint-cli2）は .markdownlint-cli2.yaml の overrides を当てないため、Slidev のスライドなど一部のファイルにだけ別の規則を当てられない。 | issue | medium | DEV | 2026-10-25 | 2026-10-31 | 2026-10-25 | init --lefthook は .markdownlintrc と、それを読む .markdownlint-cli2.yaml を作り、--slidev は cli2 の overrides の先頭に Slidev 用の規則を入れるようにした。hook と result の検査は .markdownlintignore で Slidev の kata を外す | pjr-50yh-markdownlint-cli2-overrides | - |
| PJR-6HS2 | done | kata のディレクトリにある付属のファイルが、別の kata として一覧に出る | kata list と kata status は kata のディレクトリのファイルをすべて kata として数えるため、sample に付けた CSS などの付属のファイルが、ファイル名を ID とする別の kata（kata status では package-missing）として表示される。 | issue | medium | DEV | 2026-10-25 | 2026-10-31 | 2026-10-25 | ID を持つ形式のファイルだけを kata として数え、同じ名前のファイルとディレクトリを付属のファイルとして eject で一緒に写すようにした | pjr-6hs2-kata-companion-files | - |
| PJR-6WQY | done | 成果物カタログがなくても fully-guided などで成果物を作れるようにする | カタログのない project でも、作るファイルの置き場所と rulebook を個票に指定するか、既存の文書の frontmatter から辿ることで、fully-guided・recipe-guided・freeform・retrofit・bootstrap・finalize・bootstrap-finalize の plan を作れるようにする | todo | medium | DEV | 2026-10-25 | 2026-10-31 | 2026-10-26 | カタログなしの7種の成果物approachについて、起票・対象解決・plan生成を実装した。 | pjr-6wqy-catalog-less-deliverable-approach | - |
| PJR-84F7 | done | Slidev の kata を検証できるよう、scaffold で Slidev を選んで入れられるようにする | 利用者が Slidev の sample・template の kata を作るとき、SpecDojo を入れたリポジトリに Slidev がないとビルドして表示を確かめられない。init / config scaffold で Slidev と関連の設定を選んで入れられるようにする。 | todo | medium | DEV | 2026-10-25 | 2026-10-31 | 2026-10-25 | init と config scaffold に --slidev を加え、full の preset では既定で入れるようにした。既存の設定は上書きしない | pjr-84f7-scaffold-slidev | - |
| PJR-J44D | done | 本リポジトリの文書を丸ごと使う単体テストが時間切れで毎回落ちる | doc-index.test.ts の登録簿の参照の解決のテストが docs を丸ごと一時のディレクトリへコピーして索引を作るため、文書が増えて単独でも 24 秒かかり上限の 20 秒を超える。register-plan-escape.test.ts の成果物の approach のテストも 5〜15 秒かかり上限の 5 秒の前後にある。develop の test-unit が毎回失敗し、すべての run の親の検証が止まる | issue | high | DEV | 2026-10-25 | _TODO_ | 2026-10-25 | doc-index.test.ts の登録簿の参照のテストを、本リポジトリの docs の丸ごとのコピーから 3 文書の fixture に、register-plan-escape.test.ts の成果物の approach のテストを一時のリポジトリと最小のテンプレートに、remark の山括弧の検査のテストを固定の入力に置き換えた。製品のコードと時間の上限は変えていない | pjr-j44d-slow-unit-tests-real-docs | - |
| PJR-JJBY | done | authoring の kata ができた後、register update が担当や期限の変更でも止まる | register update は変更しない approach と target も毎回検証し直すため、authoring の個票は kata ができた後、担当や期限だけを変える場合も「kata id already exists」で止まる。 | issue | medium | DEV | 2026-10-25 | 2026-10-31 | 2026-10-25 | approach・target・source を変えない register update では approach と target を検証し直さないようにした。変える update と add は従来どおり検証する | pjr-jjby-update-authoring-revalidation | - |
| PJR-MB92 | done | OpenCode scaffold に Ollama 接続設定と work-64k モデル設定を補う | scaffold が ollama-local の接続設定を生成せず、provider が見つからない。接続・モデル設定を補い、gemma・qwen は原則 *-work-64k を使う。派生タグ作成と既存環境の修正手順を整える。 | issue | high | DEV | 2026-10-25 | 2026-10-31 | 2026-10-25 | OpenCode scaffold の ollama-local 接続設定を補い、配布する Gemma 31B・26B と Qwen 27B のモデル ID を *-mlx-work-64k に統一した。空リポジトリの生成設定と既存設定保護、3モデルの実接続・短い推論応答、親の検証7項目を確認した。 | pjr-mb92-opencode-scaffold-ollama-work-64k | - |
| PJR-NTWD | done | v0.4.6 を公開する | 0.4.6 の範囲（9482・EVAQ・SS72・PM2R・68KR・J44D・R1FB・84F7・JJBY・6HS2・XTE6・50YH・ZG0A・SNHK）を main へ昇格し、npm へ公開する | todo | high | DEV | 2026-10-25 | - | 2026-10-25 | PR #23 で main へ昇格し、v0.4.6（fbf3a8754）のタグから npm へ公開した。npm の dist-tag latest は 0.4.6 | pjr-ntwd-release-v0-4-6 | - |
| PJR-R1FB | done | orchestrator が register の完了条件で executor の記録の書き先を誤る | orchestrator の指示文は、完了条件で「result に書く」と指示させる。一方、executor/reporter の pipeline では executor の記録は result の申し送りに届かず、条件が果たせない。書き先の指示・close の確かめ方・報告の形式・plan の雛形を直す。 | issue | medium | DEV | 2026-10-25 | 2026-10-31 | 2026-10-25 | executor の報告に handoff を加え result の申し送りへ転記し、plan の雛形とオーケストレーターの本文の書き先を個票の対応結果と handoff に合わせた | pjr-r1fb-completion-record-destination | - |
| PJR-SNHK | done | register-plan-escape の共通の規約の test が負荷で 5 秒の上限を超えて落ちる | tests/src/exec/register-plan-escape.test.ts の「approach の有無によらず、共通の規約は参照パスと要点だけを本文に載せる」が、負荷のある実行で Vitest の既定の上限（5 秒）を超えて落ちる。変更と関係のない項目の統合を止め、やり直しが要る。 | todo | high | DEV | 2026-10-25 | _TODO_ | 2026-10-25 | 時間のほぼすべてがカタログ付きの 2 回目の generateRegisterPlan（約 1.5 秒）にかかると分かった。この test に限って上限を 30 秒へ広げ、設定全体と確かめる内容は変えていない | pjr-snhk-flaky-plan-escape-test | - |
| PJR-TVGA | done | devcontainer scaffold の shutdownAction を補う | scaffold の devcontainer 雛形に shutdownAction がない。none を明示し、空のリポジトリで生成結果を確認する。既存環境の修正手順も記載する。 | issue | high | DEV | 2026-10-25 | 2026-10-31 | 2026-10-25 | shutdownAction: "none" を devcontainer の雛形へ反映し、空リポジトリでの生成結果、既存環境の修正手順、親の検証7項目の成功を確認した。利用者の指示により、ホストでの切断動作確認は close の条件としない。 | pjr-tvga-devcontainer-scaffold-shutdown-action | - |
| PJR-XC5P | open | coderdojo-lessons への申し送り：v0.4.6 で直った項目と移行の手順 | specdojo 0.4.6 を 2026-10-25 に公開した（PJR-NTWD、npm の dist-tag latest）。利用者の project（coderdojo-lessons-specdojo の prj-0001）から報告された次の項目が直っている。 | note | medium | DEV | 2026-10-25 | _TODO_ | - | - | pjr-xc5p-coderdojo-handoff-v0-4-6 | - |
| PJR-XTE6 | done | executor が未完了と報告しても、正常終了と親の検証の通過で review になる | executor が作業を途中で止めて報告に「未完了」と書いても、終了コード 0 で終わり、親の検証が通れば、runner は項目を review にして統合する。未完了の変更が統合先へ入り、オーケストレーターが差分を読むまで気づけない。 | issue | high | DEV | 2026-10-25 | _TODO_ | 2026-10-25 | executor の報告に completion_status を加え、incomplete なら親の検証と reporter の前で waiting に戻し、統合せず worktree を残すようにした。欄のない報告は完了として扱う | pjr-xte6-executor-incomplete-report | - |
| PJR-ZG0A | done | 登録簿に項目がないと、担当者別と状態別の派生ビューが markdownlint の MD012 に当たる | 登録簿に項目が 1 件もないと、register build が生成する担当者別と状態別の派生ビューの空の章に空行が 2〜3 行続き、markdownlint の MD012（no-multiple-blanks）に当たる。 | issue | high | DEV | 2026-10-25 | _TODO_ | 2026-10-25 | 項目のない章には「該当なし」を書くようにし、項目が 0 件の登録簿の派生ビューが markdownlint を通るようにした | pjr-zg0a-empty-register-views-blank-lines | - |
| PJR-68KR | done | checkpoint の commit の失敗の要約が、失敗していない step を挙げる | 着手の checkpoint と待ち状態の記帳の commit が hook で失敗したとき、runner の要約と block_reason が、成功した prettier の step を失敗として挙げる。 | issue | medium | DEV | 2026-10-24 | 2026-10-31 | 2026-10-25 | 着手の checkpoint・待ち状態の記帳・統合の commit のすべてで、hook の失敗の要約に PJR-0EFN と同じ処理を使い、lefthook の summary で失敗の印が付いた step と最初の error の行を挙げるようにした | pjr-68kr-checkpoint-failure-summary | - |
| PJR-9482 | done | 配布する名簿の雛形を GPT-6 と expert の 2 段にそろえる | 雛形の codex の実体は gpt-5.6-terra の terra だけで、expert の段（sol・opus）もない。codex は normal を gpt-6-luna の luna、expert を gpt-6.1-sol の sol、claude は normal を sonnet、expert を opus とし、codex-expert-executor と claude-expert-executor の別名を加える。init の振り分けの表と orch の script も合わせる | todo | medium | DEV | 2026-10-24 | _TODO_ | 2026-10-24 | 配布する名簿の雛形を、claude は sonnet（normal）と opus（expert）、codex は luna（gpt-6-luna、normal）と sol（gpt-6.1-sol、expert）の 2 段にし、codex-expert-executor・claude-expert-executor などの別名を加えた。init の振り分けの表は hard を expert、medium と easy を normal にし、codex の orch は orch:sol と orch:luna にした。既存の利用者の名簿と package.json は書き換えない | pjr-9482-init-roster-gpt6-expert-tier | - |
| PJR-C95G | done | init の小さいカタログの空の groups で catalog build が止まり worktree の実行ができない | init --catalog small が作るカタログのうち 15 個が成果物のない groups: [] になり、catalog build が空の groups をエラーにするため specdojo build が失敗する。worktree の準備が止まり、カタログを作ったリポジトリで exec run --register --worktree が実行できない。0.4.0 から公開中の 0.4.3 まで同じ | issue | high | DEV | 2026-10-24 | _TODO_ | 2026-10-24 | 成果物カタログ（type: project）の空の groups を受け付け、groups がない・配列でない場合のエラーは残した。init --catalog small の直後の specdojo build が通る | pjr-c95g-catalog-empty-groups-build | - |
| PJR-EVAQ | done | codex の agent の定義のモデルを GPT-6 に上げる | codex の agent の定義（本リポジトリの .codex/agents と配布する templates/codex/agents）のモデルが gpt-5.6-terra などのままで、GPT-6 の系統には terra がない。orch の script は -m でモデルを渡すため今は影響しないが、agent の定義だけで起動したときに古いモデルが使われる | todo | low | DEV | 2026-10-24 | _TODO_ | 2026-10-24 | 配布する templates/codex/agents の model を、codex-executor・codex-review-executor は gpt-6-luna、codex-expert-executor・codex-expert-review-executor と specdojo-orchestrator は gpt-6.1-sol にした。外れた gpt-5.4-mini・gpt-5.5 と gpt-5.6 は残っていない。既存の利用者の書き換え方を codex の README に書いた | pjr-evaq-codex-agent-defs-gpt6 | - |
| PJR-H8BC | done | v0.4.5 を公開する | v0.4.5 の範囲（ZV60・JTJF）を main へ昇格し、specdojo 0.4.5 を npm に公開する | todo | high | DEV | 2026-10-24 | _TODO_ | 2026-10-24 | specdojo 0.4.5 を npm に公開した（latest）。PR #22 を merge commit で main へ取り込み、v0.4.5 のタグで npm の公開と GitHub Pages の更新が通った。npm から入れた 0.4.5 で、init と、プロダクトリポジトリのパターンを --source に書いた rulebook-authoring の起票を確かめた | pjr-h8bc-release-v0-4-5 | - |
| PJR-JTJF | done | 配布するコードが dependencies にないパッケージを読み込んでも検査で気づけない | PJR-ZV60 で src が tinyglobby を読み込んだが devDependencies にしかなく、npm から入れたリポジトリで init などが落ちた。本リポジトリでは開発用の依存として入っているため、テストでも検証でも気づけなかった。src が読み込むパッケージがすべて dependencies にあることを npm run check で確かめる | issue | high | DEV | 2026-10-24 | _TODO_ | 2026-10-24 | src の静的・動的な読み込みと再 export を TypeScript の構文解析で調べ、dependencies・peerDependencies・node: の標準モジュール以外のパッケージを読み込んでいれば失敗する検査を加え、npm run check から流れるようにした。CONTRIBUTING.md に規則を書いた | pjr-jtjf-src-imports-in-dependencies | - |
| PJR-PM2R | done | external_projects で SpecDojo のリポジトリへ起票を任せられない | external_projects の起票の委譲は相手の node_modules/.bin/specdojo を呼ぶが、SpecDojo 自身のリポジトリには npm install 後もこの実行ファイルがないため、利用者のリポジトリから本家へ起票できない。 | issue | medium | DEV | 2026-10-24 | 2026-10-31 | 2026-10-24 | external_projects の委譲で、相手に node_modules/.bin/specdojo がなく package.json の name が specdojo のときは、相手の dist/specdojo.js を Node で起動するようにした。未ビルドなら npm run build を案内して止まる。インストール済みの CLI を優先し、版の確かめは今のまま | pjr-pm2r-external-project-specdojo-repo | - |
| PJR-QYKJ | done | v0.4.4 を公開する | v0.4.4 の範囲（EKRW・4J4A・C95G）を main へ昇格し、specdojo 0.4.4 を npm に公開する | todo | high | DEV | 2026-10-24 | _TODO_ | 2026-10-24 | specdojo 0.4.4 を npm に公開した（latest）。PR #20 と、CHANGELOG を main の内容に合わせる PR #21 を merge commit で main へ取り込み、v0.4.4 のタグで npm の公開と GitHub Pages の更新が通った。npm から入れた 0.4.4 で、init --catalog small の直後の specdojo build、kata_authority での rulebook-authoring の起票、オーケストレーターの本文の修正を確かめた | pjr-qykj-release-v0-4-4 | - |
| PJR-SS72 | done | rulebook-maintenance の plan が markdownlint（MD036）で止まる | カタログと pm-roles のない利用者の project で、kata の見直しの plan のレビュー観点の欄が _MISSING_ だけの段落になり、着手の checkpoint の commit が hook の markdownlint（MD036）で止まる。 | issue | high | DEV | 2026-10-24 | 2026-10-31 | 2026-10-25 | owner の role に当てはまる観点がないときの plan の値を、強調だけの段落ではなく箇条書きの 1 項目（- _MISSING_）にした。値の側で直したため、*-maintenance の 4 つの雛形すべてに効く。*-authoring の雛形も、手本がないときに同じ形にした | pjr-ss72-maintenance-plan-md036 | - |
| PJR-YYSD | done | codex のオーケストレーターが存在しない Skill のファイルを探しにいく | npm run orch:sol:work で起動した codex が、渡されたオーケストレーターの本文を Skill の指示と受け取り、存在しない .agents/skills/specdojo-orchestrator/SKILL.md を読もうとして警告を出す。本文の冒頭に、この文書そのものが指示であり別のファイルを探さないことを書く | issue | low | DEV | 2026-10-24 | _TODO_ | 2026-10-24 | 同梱のオーケストレーターの本文の冒頭に、この文書そのものが指示の全体であり、同じ名前の Skill や agent の定義のファイルを別に探さないことを加え、10 か所の写しへ同期した | pjr-yysd-orchestrator-body-no-skill-lookup | - |
| PJR-ZH10 | done | orch の work の script が worktree の依存のなさで起動できない | PJR-SAZC で orch の work の script を worktree の中で手元のソースから orchestrator launch を起動する形にしたが、固定の worktree には node_modules がなく、commander が見つからずに落ちる。本体のソースを指して起動するよう直す | issue | high | DEV | 2026-10-24 | _TODO_ | 2026-10-24 | 本リポジトリの orch の work の script 8 本を、本体のソースと本体の依存で orchestrator launch を起動する形（tsx に本体の src/specdojo.ts を絶対パスで渡す）に直した。作業の場所は worktree のまま、設定は本体の場所から読む | pjr-zh10-orch-work-scripts-deps | - |
| PJR-ZV60 | done | kata を作るときの手本を、カタログの外やプロダクトリポジトリのファイルからも指定できるようにする | rulebook-authoring などの手本は、カタログに載っている成果物の doc id でしか指定できず、カタログがないリポジトリや、成果物がプロダクトリポジトリにある場合に使えない。手本を --source で、doc id・プロジェクトリポジトリのパス・repo とパスの組（パターンを含む）で指定できるようにする | todo | medium | DEV | 2026-10-24 | _TODO_ | 2026-10-24 | kata の手本を --source で、doc id・プロジェクトリポジトリのパス・repo とパスの組（パターンを含む）で指定できるようにした。カタログがなくても kata を作れ、付け替えは手本がカタログの成果物で参照が undecided のときだけ行う。--target の 2 つ目以降の手本も互換で受け付ける | pjr-zv60-kata-authoring-sources | - |
| PJR-4J4A | done | 登録簿の一覧のセルで素の URL が囲まれず lint-md が止まる | 一覧の生成はセルの説明や結論に書かれた URL をそのまま描くため、markdownlint の MD034 に当たり、develop から分かれた run の親の検証がすべて止まる。PJR-Y6DG の結論の specdojo.org の URL で起きた | issue | high | DEV | 2026-10-23 | _TODO_ | 2026-10-23 | 一覧・派生ビュー・PM ログの表のセルで、素の http・https の URL を山括弧で囲むようにした。全角の括弧や句読点の手前で URL を区切り、既に囲まれたもの・リンク・コードの書式の中は変えない。作り直した develop の生成物は markdownlint を通る | pjr-4j4a-register-index-bare-url | - |
| PJR-EKRW | done | 利用者の kata の置き場所を authority ごとのディレクトリに直す | 0.4.3 では利用者の kata を docs/ja/kata の下に作るが、authority がディレクトリに出ず本体とも形が違う。PJR-8QT0 の決定に従い、docs/ja/specdojo の種類ごとのディレクトリの下の authority のサブディレクトリに置くよう直す | todo | medium | DEV | 2026-10-23 | _TODO_ | 2026-10-24 | specdojo 以外の authority の kata の置き場所を docs/ja/specdojo/<種類>s/<authority>/ にした（core は種類のディレクトリの直下のまま）。0.4.4 のあいだは古い docs/ja/kata/ も読み、移すよう案内する。core の kata をたどる処理が authority のサブディレクトリを数えないようにした | pjr-ekrw-kata-authority-directory | - |
| PJR-QF45 | done | Mermaid の既定のレイアウトを ELK に切り替え、図の絵文字の文字化けを直す | Mermaid 12 で ELK が同梱され既定になったが、docs-site の mermaid-config.json が dagre を明示している。ELK に切り替え、ノードの絵文字が文字化けする問題を直す。中心に集める図の描き方（architecture 図）も docs の書き方の文書に書く | todo | medium | DEV | 2026-10-23 | _TODO_ | 2026-10-23 | docs-site の Mermaid の既定のレイアウトを ELK にし、fontFamily と devcontainer・GitHub Pages のビルドに絵文字のフォントを加えた。図の大きさの目安と、architecture 図・block 図の使い分けを docs-editing-guide に書いた | pjr-qf45-mermaid-elk-layout | - |
| PJR-Y6DG | done | v0.4.3 を公開する | v0.4.3 の範囲（5B42・ZH7Q・47S6・98SQ・QF45・CT6G）を main へ昇格し、specdojo 0.4.3 を npm に公開する | todo | high | DEV | 2026-10-23 | _TODO_ | 2026-10-23 | specdojo 0.4.3 を npm に公開した（latest、homepage は https://specdojo.org）。PR #19 を merge commit で main へ取り込み、v0.4.3 のタグで npm の公開と GitHub Pages の更新が通った。npm から入れた 0.4.3 で init（Dev Container と lefthook）と最初の commit、起票を確かめた | pjr-y6dg-release-v0-4-3 | - |
| PJR-47S6 | done | devcontainer の preset に minimal と full を加え、init で選べるようにする | 推奨 preset（recommended）だけでは、軽くしたい人とローカル LLM や routine まで使う人に合わない。provider の選択とは別の軸として、minimal（CLI と最低限だけ）と full（recommended に加えて開発用の道具・Ollama への接続・cron）を加え、init の Dev Container の質問で選べるようにする | todo | medium | DEV | 2026-10-22 | _TODO_ | 2026-10-22 | devcontainer の preset に minimal と full を加え、init で minimal・recommended・full から選べるようにした。preset を指定しないときと --devcontainer-preset none は minimal と同じ | pjr-47s6-devcontainer-preset-minimal-full | - |
| PJR-5B42 | done | 別のリポジトリの project の登録簿へ起票できるようにする | PJR-W93C は同じリポジトリの中の project に限られる。設定で別のリポジトリの project を別名付きで宣言し、register add でその別名を指定すると、相手のリポジトリの specdojo を起動して起票させる。project ID の衝突を別名で避け、orchestrator launch で相手のリポジトリへの編集を許可する | todo | medium | DEV | 2026-10-22 | _TODO_ | 2026-10-22 | 設定の external_projects に別名ごとに相手のリポジトリのパス（相対）と project ID を宣言し、register add --project <別名> --commit で相手のリポジトリの specdojo（0.4.2 以上）に起票を任せるようにした。--from <別名>:PJR-XXXX は相手の project ID に変換して渡し、orchestrator launch は宣言したリポジトリにも編集を許可する。状態遷移は対象外 | pjr-5b42-cross-repo-register-add | - |
| PJR-62T2 | done | lefthook の markdownlint で対象のファイルがないとき使い方の説明が出ないようにする | PJR-7H7N の hook は、commit した Markdown がすべて除外の設定で外れると、ファイルなしで markdownlint を呼び、使い方の説明が出る。対象がないときは markdownlint を呼ばずに終える | todo | low | DEV | 2026-10-22 | _TODO_ | 2026-10-22 | lefthook の hook で、.markdownlintignore で対象のファイルがなくなったときは markdownlint を呼ばずに成功で終えるようにした。対象があるときは今までどおり違反で止まる | pjr-62t2-lefthook-markdownlint-empty-files | - |
| PJR-98P8 | done | ドキュメントサイトから exec の plan と result を外し、リンクを GitHub の表示に置き換える | PJR-G85C の調査で、plan と result がサイトの約 6 割を占め、手元の docs:build がメモリ不足で落ちることが分かった。推奨の案（サイトから外し、実行の記録の一覧などからのリンクを GitHub のファイル表示へ置き換える）を実装する | todo | high | DEV | 2026-10-22 | _TODO_ | 2026-10-22 | ドキュメントサイトから全 project の exec の plan と result を外し、それらへの相対リンクと wikilink をサイトのビルドのときだけ GitHub のファイル表示へ置き換えた。リポジトリの文書と生成物は変えていない | pjr-98p8-docs-site-exclude-exec-records | - |
| PJR-98SQ | done | Quick Start を register のユースケース別の使い方を中心に組み替える | Quick Start は register の使い方が最初の体験とカタログ作成への道筋に分かれ、approach・difficulty・post-review・夜間の実行・別の project への起票などの使い方が載っていない。register のユースケース別に、こんなとき・チャットでの頼み方・具体的なコマンドを並べる章を中心に置き、カタログと schedule 以降は発展として後ろに回す | todo | high | DEV | 2026-10-22 | _TODO_ | 2026-10-22 | Quick Start に register のユースケース別の章（13 節）を置き、カタログと schedule、worktree、routine を発展として後ろに回した。各節に、こんなとき・チャットでの頼み方・そのまま打てるコマンドをそろえた | pjr-98sq-quick-start-register-use-cases | - |
| PJR-BF76 | done | v0.4.2 を公開する | 0.4.2 の範囲（W93C・6SQH・2ASZ・STB4・7H7N・T30J・98P8・G85C・Q4CD・62T2・CNNT）を main へ昇格し、specdojo 0.4.2 を npm に公開する | todo | high | DEV | 2026-10-22 | _TODO_ | 2026-10-22 | specdojo 0.4.2 を npm に公開した（latest）。PR #18 を merge commit で main へ取り込み、v0.4.2 のタグで npm の公開と GitHub Pages の更新が通った。npm から入れた 0.4.2 で init --lefthook と最初の commit、起票を確かめた | pjr-bf76-release-v0-4-2 | - |
| PJR-CNNT | done | plan の名前の末尾の乱数が短く、同じ秒に作ると名前がぶつかることがある | plan と in-place の stem、イベントの名前の末尾の乱数が 2 バイト（16 進 4 桁）しかなく、同じ slug で同じ秒に 2 回作ると 6 万 5 千分の 1 の確率でぶつかる。PJR-T30J の検証で単体テストが 1 回落ちた | issue | medium | DEV | 2026-10-22 | _TODO_ | 2026-10-22 | plan・in-place の stem・イベントの名前の末尾の乱数を 4 バイトにし、それでもぶつかったときは連番を付けるようにした。既存の 4 桁の名前と新しい名前の両方を読める。テストは乱数と時刻を差し替えて決定的に確かめる | pjr-cnnt-plan-stem-random-collision | - |
| PJR-CT6G | done | kata を新しく作る approach（rulebook-authoring など）を実装する | PJR-V2W5 の決定に従い、rulebook-authoring など 4 つの approach、--target の 1 つ目に新しい kata の id と 2 つ目以降に手本の成果物を書く指定、利用者のリポジトリ単位の kata の authority、カタログの undecided の参照の付け替えを実装する | todo | medium | DEV | 2026-10-22 | _TODO_ | 2026-10-23 | rulebook-authoring・recipe-authoring・sample-authoring・template-authoring を加えた。--target の 1 つ目に新しい kata の id、2 つ目以降に手本の成果物を書く。利用者の kata は設定の kata_authority の authority で docs/ja/kata の下に作り、specdojo: は本体専用とする。手本の成果物のカタログの参照が undecided か未記入なら付け替える。schedule では使わない（register 専用） | pjr-ct6g-kata-authoring-approach-impl | - |
| PJR-P3HF | rejected | 生成される登録簿の一覧で Markdown の記号をエスケープしていない | register build が個票の conclusion などを一覧の表へそのまま書くため、orch:* のような * を含む値が強調記号と解釈され、lint-md（MD037）が失敗する。PJR-SAZC の結論で起き、prj-0002 の PJR-0WFV の run が親の検証で止まった。一覧の生成で Markdown の記号をエスケープするか、コードの書式にする | issue | medium | DEV | 2026-10-22 | 2026-10-31 | 2026-10-24 | PJR-6SQH（0.4.2）で、一覧・派生ビュー・PM ログの表のセルの強調の記号（アスタリスクとアンダースコア）をエスケープするよう直っている。素の URL は PJR-4J4A（0.4.4）で囲むようになった。prj-0002 で起きたのは、prj-0002 の作業ツリーの CLI が 0.4.2 より古いため | pjr-p3hf-register-view-markdown-escape | - |
| PJR-Q4CD | done | schedule から dashboard への import を外し、3 機能をまたぐ循環をほどく | PJR-T30J で、schedule → dashboard → exec → schedule と schedule → dashboard → routine → exec → schedule の 2 組の循環が見つかった。どちらも schedule/strategy-generate-scope.ts から dashboard/timeline-build.ts への import 1 か所を通るため、これを外して 2 組をほどき、依存の向きを ESLint で検査する | todo | medium | DEV | 2026-10-22 | _TODO_ | 2026-10-22 | schedule と dashboard が共有する Timeline index とカタログの探索を src/shared へ移し、schedule から dashboard への import をなくした。3 機能以上をまたぐ循環は 0 組になり、schedule は dashboard を import しない向きを ESLint で検査する | pjr-q4cd-untangle-schedule-dashboard-cycle | - |
| PJR-WWQH | done | exec run の親の検証に SPECDOJO_PROJECT が漏れ、テストが失敗する | SPECDOJO_PROJECT=prj-0002 のシェル（orchestrator launch の手順どおり）から exec run を流すと、親の検証の test-unit に環境変数が引き継がれ、テストが作る仮のリポジトリの設定に prj-0002 がないため Unknown project で 65 件が失敗する。runner の親の検証の環境またはテストの共通 setup で SPECDOJO_PROJECT を切り離す | issue | high | DEV | 2026-10-22 | 2026-10-31 | 2026-10-26 | 共通テスト setup で継承した SPECDOJO_PROJECT を除去し、別 project 環境で単体・統合テストが通ることを確認した。 | pjr-wwqh-parent-validation-specdojo-project-env | - |
| PJR-ZH7Q | done | 推奨 preset に gh を加え、agent の push と gh の書き込み操作を止める | 推奨 preset に gh を入れ、ログイン情報を名前付きボリュームに残す。コンテナの中でログインすると同じ利用者で動く agent からも認証が使えるため、配布する agent の権限設定に git push と gh の書き込み操作を止める規則を加え、ガイドに注意を書く | todo | medium | DEV | 2026-10-22 | _TODO_ | 2026-10-22 | 推奨 preset に gh とログイン情報の名前付きボリュームを加えた。配布する executor と reporter の権限設定で git push と gh を全面的に止め、オーケストレーターには専用の settings.orchestrator.json を渡して gh の読み取りだけを許し、書き込みと git push を止めた。保護された設定の編集は禁じない | pjr-zh7q-devcontainer-gh-and-agent-deny | - |
| PJR-2ASZ | done | 配布する名簿の雛形の gemma の reporter を 26b にし、モデル名を利用者の環境に合わせる | init が作る名簿の雛形では gemma の executor と reporter がすべて 31b を指し、モデル名も手元の Ollama で作ったタグ（mlx-work-64k）のままで、利用者の環境にそのままでは無い。既定の reporter を 26b にし、モデル名の決め方と用意の仕方を利用者が分かる形にする | todo | medium | DEV | 2026-10-21 | _TODO_ | 2026-10-21 | 名簿の雛形の gemma-reporter を ollama-local/gemma4:26b、gemma-executor・gemma-review-executor と opencode のオーケストレーターを ollama-local/gemma4:31b にし、手元で作ったタグ（mlx-work-64k）をなくした。文脈を広げる別タグを Modelfile と ollama create で作る手順と、導入済みの名簿の書き換え方を opencode の README に書いた | pjr-2asz-init-gemma-reporter-26b | - |
| PJR-6SQH | done | 登録簿の一覧のセルで強調の記号がエスケープされず lint-md が止まる | 一覧の生成はセルの縦棒はエスケープするが、アスタリスクとアンダースコアはしない。説明や結論に orch: のあとにアスタリスクを付けた書き方が 2 つあると強調と解釈され、MD037 で親の検証の lint-md が止まり、develop から分かれた run がすべて止まる | issue | high | DEV | 2026-10-21 | _TODO_ | 2026-10-21 | 一覧・派生ビュー・PM ログの表のセルで、コードの書式の外にある未エスケープのアスタリスクとアンダースコアをエスケープするようにした。コードの書式の中とエスケープ済みの記号は変えない。作り直した develop の生成物は markdownlint を通る | pjr-6sqh-register-index-escape-emphasis | - |
| PJR-7P27 | done | README の会話例でオーケストレーターが内容を日本語で確かめる形にする | README の「会話で操作する」の例では、オーケストレーターがコマンドを見せて「次を実行します。よろしいですか。」と聞いている。0.4.1 のオーケストレーター（PJR-C50G）は、何を・どんな内容で・何に影響するかを日本語で聞く形に変わったため、例をそれに合わせる | todo | medium | DEV | 2026-10-21 | _TODO_ | 2026-10-21 | README の「会話で操作する」の例を、何をするか・中身・影響を日本語で示して承認を求める形にし、コマンドは求めたときに見せる説明を加えた | pjr-7p27-readme-orchestrator-approval-dialog | - |
| PJR-P14M | done | project ごとに共有の親の検証を置き換えられるようにする | projects.<id>.run.parent_validations は共有の exec-defaults の親の検証へ追記するだけで減らせない。文書と LP だけを変える prj-0002 の run で本体の全テスト（test-unit・test-integration など）が走らないよう、exec-defaults.yaml を複製せずに project ごとに共有の親の検証を置き換える、または除外できるようにする（prj-0002 の PJR-B3W9 から起票） | todo | medium | DEV | 2026-10-21 | 2026-10-31 | 2026-10-26 | projectごとの親検証除外を実装し、共有設定の継承とprj-0002向けの絞り込みをテストで確認した。 | pjr-p14m-per-project-parent-validations-replace | - |
| PJR-STB4 | done | opencode の README に Apple シリコン向けの mlx 版の gemma の案内を加える | 名簿の雛形は環境を選ばない gemma4:26b と gemma4:31b を既定にした（PJR-2ASZ）。Mac の Apple シリコンでは Ollama の公式の mlx 版（gemma4:26b-mlx など）が使えるため、選び方と書き換え方を opencode の README に一言添える | todo | low | DEV | 2026-10-21 | _TODO_ | 2026-10-22 | opencode の README に、Apple シリコンでは公式の mlx 版（gemma4:26b-mlx・gemma4:31b-mlx）を pull して使えること、名簿の model と Modelfile の FROM の書き換え方、既定は無印のタグのままであることを書いた | pjr-stb4-opencode-readme-gemma-mlx | - |
| PJR-W93C | done | 別の project の登録簿へ起票できるようにする | project ごとに統合ブランチと作業ツリーが分かれているため、ある project の作業ツリーから別の project の todo などを起票できず、--from で別の project の項目も指せない。register add --project で相手の project の統合ブランチへ直接記帳し、project 付きの --from を使えるようにする | todo | medium | DEV | 2026-10-21 | _TODO_ | 2026-10-21 | 別の project の作業ツリーから register add --project <id> --commit で、相手の統合ブランチ（integration_branch、既定は project/<id>/develop）へ記帳できるようにした。相手のブランチを開いた作業ツリーがなければ一時的な worktree を使う。--commit なし、相手の未 commit の変更、ブランチがない場合、別の project への状態遷移は書き込み前に止める。--from は project 付きで別の project の項目を指せる | pjr-w93c-cross-project-register-add | - |
| PJR-0M7W | done | devcontainer の scaffold が作るシェルスクリプトの動きを、docker なしでテストする | specdojo-tmux.sh.sample と post-create.sh を、偽物の docker・devcontainer・sudo・curl と組み合わせて実際に動かし、PATH の追加（ssh の RemoteCommand と同じ最小の PATH で）・docker exec の利用者と tmux の引数・~/.local の持ち主の戻し方と ~/.local/bin の作成・見つからないときの案内を確かめる統合テストを足す。生成したシェルスクリプトは bash -n と shellcheck でも確かめる（2026-10-20、利用者が承認。0.4.1 の範囲） | todo | high | DEV | 2026-10-20 | _TODO_ | 2026-10-20 | tests/src/devcontainer/scaffold.integration.test.ts に、生成した specdojo-tmux.sh と post-create.sh を偽物の docker・devcontainer・sudo・curl と組み合わせて動かす統合テストを加えた。ssh の RemoteCommand と同じ最小の PATH での CLI の見つけ方と docker exec の引数、見つからないときの案内、~/.local の持ち主の戻し方とインストーラより前の ~/.local/bin の作成、2 つのスクリプトの文法を確かめる。6 件が通った | pjr-0m7w-devcontainer-script-behavior-tests | - |
| PJR-16S0 | done | 配布する orch の script の名前を model の系統にそろえる | init が作る orch の script は、claude だけ model の系統（orch:opus・orch:sonnet）で、codex・antigravity は provider の名前（orch:codex・orch:agy）で model も指定していない。ZM1K の名付けに合わせ、codex は orch:sol・orch:terra、antigravity は orch:flash にし、model を指定する。opencode はローカルの model が利用者の環境ごとに違うため orch:opencode のままとする（2026-10-20、利用者が提案） | todo | medium | DEV | 2026-10-20 | _TODO_ | 2026-10-20 | 配布する orch の script を orch:opus・orch:sonnet・orch:sol・orch:terra・orch:flash・orch:opencode・orch:copilot にし、codex と antigravity は model を指定した。既存の package.json は書き換えず、古い orch:codex・orch:agy からの移り方をガイドと CHANGELOG に書いた。executor が本リポジトリの package.json も改名したため worktree で戻し、本リポジトリの改名は利用者の承認を得て orchestrator が行った（99e73edda）。LP は prj-0002 の PJR-SGM6 で直す | pjr-16s0-orch-scripts-model-family-names | - |
| PJR-2DA0 | done | ホストの devcontainer の E2E を tsx なしで動かす案内に直す | tools/e2e/devcontainer-host-e2e.ts の使い方の表示とガイドは node --import tsx で動かすよう案内しているが、ホストの Mac ではコンテナと共有する node_modules の esbuild が Linux 用のため tsx が動かない。スクリプトは Node の標準ライブラリしか使わず、Node 24 なら node で直接動くため、案内を node tools/e2e/devcontainer-host-e2e.ts に直す（2026-10-20、利用者がホストで流して確かめた） | todo | low | DEV | 2026-10-20 | _TODO_ | 2026-10-20 | devcontainer の E2E のスクリプトの冒頭のコメントと使い方の表示、ガイドの実行の方法を node tools/e2e/devcontainer-host-e2e.ts に改め、ホストとコンテナで node_modules を共有しているため tsx が使えないことを書いた。コンテナの中で --help が使い方を表示することを確かめた | pjr-2da0-host-e2e-usage-without-tsx | - |
| PJR-3K1X | done | register の --by の actor が名簿と照らし合わされず、書き方がばらばらになっている | register の --by に渡した値は、項目別のイベントの actor にそのまま記録され、人の名簿（pm-members.yaml）とも agent の名簿（agent-members.yaml）とも照らし合わされない。本リポジトリのイベントでは、オーケストレーターが orchestrator・claude-orchestrator・specdojo-orchestrator、人が naoji3x・manual・PO（役割の名前）、同じ agent が 2 段構成の前後で codex-expert-executor と sol-executor と記録され、誰が決めて誰が close したかを名簿からたどれない（2026-10-20、利用者の質問で分かった） | issue | medium | DEV | 2026-10-20 | _TODO_ | 2026-10-20 | register の --by を人と agent の名簿と予約名（SpecDojo・specdojo-orchestrator・night-orchestrator）で確かめ、alias は実体名で記録する。名簿にない名前は記帳の前に止める。オーケストレーター本文の規則は PJR-C50G で書いた | pjr-3k1x-register-actor-roster-validation | - |
| PJR-3RXY | done | ホストで本物の devcontainer を作って確かめる E2E のスクリプトを用意する | ホストの Mac（docker と Dev Container CLI がある）で実行し、一時ディレクトリに scaffold した devcontainer を devcontainer up で作り、devcontainer exec で利用者が node であること、~/.local/bin が node の持ち物であること、tmux・vim・emacs と agent の CLI が入ったことを確かめ、最後に container と volume を片づけるスクリプトを用意する。開発用の container には docker を入れない（agent にホストの権限を与えないため。2026-10-20、利用者が案 C を選んだ） | todo | medium | DEV | 2026-10-20 | _TODO_ | 2026-10-20 | tools/e2e/devcontainer-host-e2e.ts を加え、ホストで init から devcontainer up・devcontainer exec の項目別の確認と片づけまでを流せるようにした。利用者がホストの Mac で流して PASS した（2026-10-20）。ホストの node_modules はコンテナの Linux 用のため tsx が動かず、node で直接動かす必要がある。使い方の表示とガイドの直しは PJR-2DA0 で行う | pjr-3rxy-host-devcontainer-e2e-script | - |
| PJR-5HYP | done | 作業の難しさで agent を振り分ける設定を加える | exec-defaults.yaml に、難しさ（hard・medium・easy）ごとの executor・reporter・rate limit のときの扱い・代わりの agent を書く振り分けの表を加え、個票に difficulty を持たせる。exec run --register で agent を指定しないときと夜間の orchestrator は、この表で agent を選ぶ。今の自動選択は priority の小さい順で、普通の難しさに qwen-executor が選ばれるため、あわせて直す（2026-10-20、利用者が承認） | todo | high | DEV | 2026-10-20 | _TODO_ | 2026-10-20 | 個票の difficulty と exec-defaults の routing で agent を振り分けるようにした。CLI の指定は表より優先し、difficulty や表がない場合は今の自動選択のまま。統合後の動作は PJR-JSEY で確認した | pjr-5hyp-agent-routing-by-difficulty | - |
| PJR-5JRJ | done | devcontainer で後から開く端末に ~/.local/bin が PATH に入らない | GHBP で post-create.sh の中では ~/.local/bin を PATH に足したが、devcontainer.json に remoteEnv がないため、container の作成の後に開く端末や VS Code の terminal では ~/.local/bin が PATH に入らず、そこに入った Claude Code などの CLI が見つからない（2026-10-20、v0.4.0 の環境の直し方を確かめる中で見つかった） | issue | high | DEV | 2026-10-20 | _TODO_ | 2026-10-20 | 生成する devcontainer.json の remoteEnv で /home/<remoteUser>/.local/bin を PATH の先頭に足すようにし、単体テストを加えた。ホストの E2E のスクリプトに、ログインシェルで command -v claude が ~/.local/bin/claude を返す確認を足し、ガイドに v0.4.0 の環境の直し方を書いた | pjr-5jrj-devcontainer-remote-env-local-bin | - |
| PJR-7H7N | done | 利用者向けに git の hook（lefthook）を scaffold する | 利用者のリポジトリでも、commit の前に Prettier・markdownlint・SpecDojo の検証（register build・catalog validate など）を流せるよう、lefthook の設定を scaffold する。どの検査を流すかの案を作り、完了条件を決めてから行う（2026-10-20、利用者が devcontainer の preset とは別の項目にすることを承認） | todo | low | DEV | 2026-10-20 | _TODO_ | 2026-10-22 | init --lefthook と config scaffold --lefthook で、lefthook.yml・hook の入口・markdownlint の設定と除外を作るようにした。commit の前に、変えた Markdown と YAML の Prettier、Markdown の markdownlint、登録簿の register build、カタログの catalog validate を流す。既定は作らず、既存のファイルと package.json の項目は上書きしない | pjr-7h7n-lefthook-scaffold-for-users | - |
| PJR-C50G | done | オーケストレーターの本文に、実行の運び方・close の前の確かめ方・止まったときの対処を書く | 2026-10-18〜20 の運用で分かった一般的な勘どころを、配布するオーケストレーターの本文（.agents/specdojo-orchestrator.agent.md と 4 つのラッパー）に書く。実行の運び方（worktree・並行の上限・background と通知・自分に一致する pkill を避ける・dist の作り直し）、commit の作法（register の --commit を使い、統合中は普通の commit を避ける）、close の前の確かめ方（完了条件と差分の突き合わせ、agent の報告を実物で確かめる、保護された設定、runner を変えた項目の動作確認）、止まったときの対処の表、完了条件の書き方、agent は振り分けの設定に従って選ぶこと（2026-10-20、利用者が承認） | todo | high | DEV | 2026-10-20 | _TODO_ | 2026-10-21 | オーケストレーター本文に、承認の聞き方・実行の運び方・close の前の確かめ方・止まったときの対処・完了条件の書き方・agent の選び方と、--by で受け付ける名前を加え、10 か所の写しへ同期した | pjr-c50g-orchestrator-prompt-operations | - |
| PJR-DKD8 | done | ローカル LLM につながらないとき reporter が切り替わらずに止まる | 2026-10-20 06:33 に PJR-16S0 の reporter（gemma26-reporter）が、ホストの Ollama が止まっていたため Cannot connect to API で失敗し、--fallback-reporter-by claude-reporter を指定していたのに切り替わらずに waiting になった。切り替えは rate limit のときだけ働き、つながらないエラーは対象にしていない | issue | medium | DEV | 2026-10-20 | _TODO_ | 2026-10-20 | provider ごとの connection_error_detection を加え、agent がつながらないエラーで失敗したとき、指定した代わりの executor・reporter へ 1 回だけ切り替えるようにした（--on-rate-limit とは独立）。イベントに trigger: connection_error を記録する。本リポジトリの exec-defaults.yaml にも opencode の検出を orchestrator が加えた（b60d459b2）。統合後の JSEY が通った | pjr-dkd8-reporter-fallback-on-connection-error | - |
| PJR-EJ4F | done | 接続のスクリプトを ssh から動かすと Dev Container CLI が見つからない | specdojo-tmux.sh.sample を ssh の RemoteCommand で動かすと、ログインも対話もしないシェルで動くため、Mac の端末で読み込まれる Homebrew・nvm などの PATH の設定が入らず、「Dev Container CLI is not installed」で止まる（2026-10-20、利用者が報告）。サンプルは PATH の追加をコメントで書いているだけで、自宅の Mac 向けの設計書の helper にある node_bin_dir と /opt/homebrew/bin・/usr/local/bin の追加が引き継がれていない | issue | high | DEV | 2026-10-20 | _TODO_ | 2026-10-20 | specdojo-tmux.sh.sample に node_bin_dir の変数を設け、/opt/homebrew/bin・/usr/local/bin と合わせて PATH の先頭に足すようにした。値の確かめ方と Homebrew・nvm・mise の例をコメントに書き、devcontainer や docker が見つからないときは PATH を表示する。生成したサンプルは bash -n と shellcheck を通った | pjr-ej4f-remote-tmux-sample-path | - |
| PJR-EN6M | done | devcontainer の scaffold に推奨の設定をまとめて入れる preset を加える | devcontainer scaffold に --preset recommended を加え、emacs と vim（.vimrc の雛形を新しく足す）、tmux、SpecDojo の文書の作業に効く VS Code の拡張（git graph・markdownlint・YAML・Prettier・remark・Markdown All in One・Code Spell Checker・EditorConfig・Error Lens・Even Better TOML）と設定（保存時の整形、YAML の schema の紐づけ）、.vscode/extensions.json の推奨の拡張をまとめて入れる。init の対話では devcontainer を選んだときだけ推奨の設定を入れるかを聞く（2026-10-20、利用者が推奨案を承認。0.4.1 の範囲） | todo | medium | DEV | 2026-10-20 | _TODO_ | 2026-10-20 | devcontainer scaffold に --preset recommended を加え、tmux・emacs-nox・vim-nox・ripgrep、emacs と vim の設定の雛形（既にある設定は上書きしない）、推奨の VS Code の拡張 10 個と選んだ provider の拡張、Markdown と YAML の保存時の整形と YAML の schema の紐づけ、.vscode/extensions.json の推奨の拡張をまとめて入れるようにした。init は --devcontainer-preset で選べ、devcontainer を選んだときの既定は recommended | pjr-en6m-devcontainer-recommended-preset | - |
| PJR-GHBP | done | devcontainer の雛形で ~/.local/bin を作れず、tmux のスクリプトが root で入る | init の scaffold で作った devcontainer で、opencode の volume を ~/.local/share/opencode に mount すると Docker が親の ~/.local を root の持ち物として作り、post-create.sh は mount 先しか持ち主を戻さないため、node が ~/.local/bin を作れず Claude Code などのインストーラが失敗する。また specdojo-tmux.sh.sample は docker exec に利用者を指定しないため、container の既定の root で入る（2026-10-20、利用者が報告） | issue | high | DEV | 2026-10-20 | _TODO_ | 2026-10-20 | post-create.sh で ~/.local・~/.local/share の持ち主を戻して ~/.local/bin を作ってから CLI を入れ、specdojo-tmux.sh.sample の docker exec に -u node を付けた。利用者がホストの Mac で tools/e2e/devcontainer-host-e2e.ts を流し、本物の devcontainer で node の利用者・~/.local/bin の持ち主・Claude Code の導入が通った（2026-10-20、Dev Container host E2E: PASS） | pjr-ghbp-devcontainer-local-bin-and-tmux-user | - |
| PJR-JCGS | done | v0.4.1 を公開する | 0.4.0 の公開の後に統合した不具合の修正と追加機能（統合後の review と夜間の orchestrator、devcontainer の推奨の設定、orch の script の名前の統一など）と A6PV を範囲とし、CHANGELOG を見直して develop を main へ昇格し v0.4.1 を公開する（2026-10-20、利用者が推奨の流れを承認） | todo | high | DEV | 2026-10-20 | _TODO_ | 2026-10-21 | specdojo 0.4.1 を npm に公開した（latest）。PR #17 を merge commit で main へ取り込み、v0.4.1 のタグで npm の公開と GitHub Pages の更新が通った。npm から入れた 0.4.1 で init・推奨 preset・振り分けの表・difficulty 付きの起票を確かめた | pjr-jcgs-release-v0-4-1 | - |
| PJR-S7JJ | done | prj-0001 のオーケストレーターの運用メモを書く | 配布する本文に入れないこの環境ならではの事情（runner を変えたら JSEY で確かめる、opencode の executor は docs・src・tests だけ編集できる、gemma は確かめずに完了と報告しがち、agy の opus の割り当ては数日単位、夜間の列の分け方など）を prj-0001 の文書にまとめ、本文から参照させる。orchestrator（claude-orchestrator）が書く（2026-10-20、利用者が承認） | todo | medium | DEV | 2026-10-20 | _TODO_ | 2026-10-22 | prj-0001 のオーケストレーターの運用メモ（pm-orchestrator-playbook）を書き、CLAUDE.md と AGENTS.md から参照するようにした。実行の列、agent の癖、再開の使い分け、JSEY、落とし穴、別の project との分担、リリースの手順を、0.4.1 と 0.4.2 の運用に基づいて書いた | pjr-s7jj-prj-0001-orchestrator-playbook | - |
| PJR-SVHF | done | quick start に Dev Container の推奨 preset を入れる | Quick Start ガイドの導入の手順を、Dev Container を作り推奨の preset（tmux・emacs・vim・推奨の VS Code 拡張）を入れる例にそろえる。今は Dev Container を作らない例と、preset のない scaffold の例のままになっている | todo | medium | DEV | 2026-10-20 | _TODO_ | 2026-10-21 | Quick Start ガイドの体験の手順を Dev Container と推奨 preset を選ぶ例にし、入るものと開き方、使わない場合の進め方を書いた。個別に設定する場合の例を --preset recommended 付きにし、init --yes --devcontainer で推奨 preset が入ることを書いた | pjr-svhf-quick-start-devcontainer-preset | - |
| PJR-0EFN | done | 統合後の review の result が markdownlint で落ち、close の記帳が commit されない | 2026-10-19 01:01 の PJR-JSEY の --post-review で、review の agent が判断の根拠に自分で番号（1. 2. 3.）を付け、runner がそれを箇条書き（- ）として result に描いたため、- 1. の形が入れ子の番号付きリストとして markdownlint の MD029 に当たった。pre-commit の hook で post-review の記帳の commit が失敗し、close の記帳（個票・イベント・review の plan と result）が作業ツリーに残った。runner は失敗を git commit failed: format: の 1 行目だけで報告した | issue | high | DEV | 2026-10-19 | _TODO_ | 2026-10-19 | result の箇条書きに描く reporter の文の先頭の番号や記号（1.・1)・-・*・+）を外すようにした。commit の失敗の要約が、成功した最初の段（format）ではなく失敗の印の付いた段と最初のエラーの行を報告するようにし、post-review の記帳の commit が失敗したときは残ったファイルと hook の全出力のログを残す。統合後に JSEY を --post-review で流し、review の agent の close の記帳が commit まで通った | pjr-0efn-post-review-result-markdown-lint | - |
| PJR-283N | done | 夜間の承認の印がない個票の plan に空行が重なり、register の run の commit が止まる | 6DHY で xep-register-template に _AUTOPILOT_CONSTRAINTS_ の段落を足した。夜間の承認の印（autopilot）がない個票ではこれが空に展開され、前後の空行と合わせて空行が 3 行続く。plan を commit する pre-commit の hook が markdownlint の MD012 で落ちるため、6DHY の統合（2026-10-19 01:18）の後の exec run --register は記帳の commit で止まる（01:34 の PJR-JSEY で確認） | issue | high | DEV | 2026-10-19 | _TODO_ | 2026-10-19 | orchestrator の最小の修正（register の plan の空行をまとめる）を、全雛形が通る expandTemplate へ移し、2 行以上続く空行を 1 行にまとめるようにした。Job・保守系の approach などの雛形でも空に展開される箇所があり、まとめて直った。印のある個票とない個票の plan に MD012 が出ないことをテストで確かめた。統合後の JSEY で plan の commit が通った | pjr-283n-register-plan-blank-lines-autopilot | - |
| PJR-8C6E | done | ブランチ運用ガイドのプロダクトリポジトリの節の誤りを直す | WJE6 で足した branch-workflow-guide の「10. プロダクトリポジトリの統合先を指定する」に、GitHub flow の統合先の例が main になっている誤り、プロジェクトの内部の事情（派生項目として起票中）と登録簿の項目への参照、実在の項目 ID を使った git log の例が残っている。配布するガイドなので、利用者の環境で意味が通る形に直す | todo | medium | DEV | 2026-10-19 | _TODO_ | 2026-10-19 | branch-workflow-guide の 10 の節で、GitHub flow の例を feature/<topic> に直し、内部の事情（派生項目として起票中）と登録簿への参照を消し、git log の例を仮の値にした。ほかの記述は変えていない | pjr-8c6e-branch-guide-product-section-fixes | - |
| PJR-A6PV | done | result に書く検査の理由の文で * などがエスケープされず、統合の前に止まる | 2026-10-19 03:07 の PJR-EVAX で、executor が validate:schema:file の not_applicable の理由に「No *.yaml or *.yml files were changed」と書き、runner がそれをそのまま result に描いたため、_.yaml or * が強調と読まれて markdownlint の MD037 に当たり、統合の前の記法の検査で止まった。8WBN・Z104 の後は executor が not_applicable の理由を書くことが増えたため起きやすい | issue | medium | DEV | 2026-10-19 | _TODO_ | 2026-10-20 | result に描く自由記述の文に既存の escapeMarkdownInline を適用し、* や _ を含む語をコードの書式で囲むようにした。既にコードの書式の部分は変えない。統合後の JSEY が通った | pjr-a6pv-result-validation-reason-markdown-escape | - |
| PJR-G90K | done | 統合の git 操作が index.lock の一時的な取り合いで待たずに失敗する | 2026-10-19 01:32 と 01:41 に、PJR-EVAX の統合が git restore failed: Unable to create .git/index.lock で失敗した。並行の run の統合や記帳と同じ時刻に重なったためで、ロックはすぐに外れる一時的なものだった。runner の統合の git 操作は index.lock を待たずに失敗し、run を waiting にする。並行の run が多い夜間の自動実行では起こりやすい | issue | medium | DEV | 2026-10-19 | _TODO_ | 2026-10-19 | 既存のやり直しの仕組み（runGitWithTransientRetry）で、index.lock の取り合いを 1.5 秒おきに最大 10 回やり直すようにした。翻訳されたメッセージも見分け、上限に達したらロックのパスを添えて失敗を報告する。ロックのファイルは消さない。統合後の JSEY が通った | pjr-g90k-integrate-index-lock-retry | - |
| PJR-T30J | done | shared の機能固有のモジュールを戻し、3 機能以上をまたぐ循環をほどく | WSET の見直しで、src/shared/ に 1 機能からしか使われない 6 モジュール（catalog-paths・template-resolution・schedule-paths・random・yaml-schema-modeline・specdojo-gitignore）と機能固有の 2 モジュール（catalog-render・schedule-index）が残ることが分かった。あわせて schedule → dashboard → exec → schedule のような 3 機能以上をまたぐ循環が残っている。どこまで戻すか・ほどくかは完了条件を決めてから行う | todo | low | DEV | 2026-10-19 | _TODO_ | 2026-10-22 | shared の 8 モジュールの利用元を数え、kata だけが使う yaml-schema-modeline を src/kata へ移した。残る 7 つは shared の別のモジュールが使うか 2 つ以上の機能が使うため残した。3 つ以上の機能をまたぐ循環 2 組は、ほどかずに起票の案を残した | pjr-t30j-shared-scope-and-multi-feature-cycles | - |
| PJR-0JJB | done | pipeline-e2e の統合テストが負荷で 20 秒の上限を超えて親の検証を落とす | tests/src/exec/pipeline-e2e.integration.test.ts の再開のテストは 1 件あたり約 2 秒で、単独なら 16 件が 36 秒で通るが、テストの中で 20 秒の上限を指定しているため、並行の run やローカル LLM と重なると上限を超える。2026-10-18 に BHMH・FXPH・H06F・JSEY の親の検証や統合の hook がこれで落ちた。W2EB の統合テスト全体の 30 秒の上限も、テストの中の指定で上書きされている | issue | high | DEV | 2026-10-18 | - | 2026-10-18 | pipeline-e2e のテストの中の 20 秒の上限 4 件を外して全体の上限 30 秒に従わせ、kata の approach のテストを一時ディレクトリの中で完結させた。単独の時間は pipeline-e2e が約 36 秒から約 25 秒、register-plan-escape が約 1.3 秒になった。並行の run が多いと全体の上限も超えるため、並行は少数に抑える | pjr-0jjb-pipeline-e2e-test-timeout | - |
| 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-6DHY | done | 夜の orchestrator が承認済みの todo の並びを流しきる仕組みを作る | 段階 B。人が完了条件を承認した個票に印を付け、夜の orchestrator が決まった権限と手順の中で順に流し、見つけた問題は derived_from を付けて承認待ちとして起票し、朝に結果をまとめる。 PJR-3DY1 の決定に基づく | todo | high | DEV | 2026-10-18 | - | 2026-10-19 | register update --autopilot approved で承認の印を付け、orchestrator night が印のある open の todo・issue だけを worktree・post-review・並行の wave で流すようにした。件数・並行数・連続失敗の停止・rate limit の切り替えを設定でき、承認の範囲外の失敗は derived_from 付きで起票し、朝の報告にまとめる。2 時の routine は enabled: false のまま加えた。雛形の空行の不具合は PJR-283N で直した | pjr-6dhy-night-orchestrator-approved-queue | - |
| PJR-6EF8 | done | npm init の仮の test script があると not_applicable が退けられて最初の実行が止まる | npm init -y は package.json に test の仮の script（echo "Error: no test specified" && exit 1）を入れる。LP の手順どおりに作ったリポジトリで 0.4.0 の tarball を試すと、executor は npm test を not_applicable と報告したが、runner は test の script があるため当てはまると判定して退け、executor validation failed or not run: npm test で waiting にした（2026-10-18）。LP の手順で導入した利用者は全員がここで止まる | issue | high | DEV | 2026-10-18 | _TODO_ | 2026-10-18 | runner が npm test の not_applicable を確かめるとき、npm init の仮の test script（引用符・空白の違いを含む）は script がないものとみなすようにし、共通の規約の検査の表にも同じ扱いを書いた。本物の script は今までどおり退ける。npm init -y で作った空のリポジトリで、0.4.0 の tarball の最初の実行が close まで通った | pjr-6ef8-npm-init-placeholder-test-script | - |
| PJR-7AW0 | done | 親検証の検査を executor が not_applicable と報告すると runner が退けて止まる | 2026-10-18 23:45 に PJR-WJE6 を qwen-executor で流したところ、qwen は親 runner が流す検査（npm run lint:md など 7 件）を、規約どおり自分では流さず not_applicable（理由: parent runner runs）と報告した。runner は script があるため当てはまると判定して not_applicable を退け、親検証の 7 件はすべて通っていたのに executor validation failed or not run で waiting にした。親検証に設定された検査についての executor の報告は、親 runner の結果で置き換えるか無視するべきである | issue | high | DEV | 2026-10-18 | _TODO_ | 2026-10-19 | 親検証に設定された検査について executor が not_run か not_applicable と報告しても、親 runner が流して通した場合は run を失敗にせず、親 runner の結果を正とするようにした。executor の failed は打ち消さない。共通の規約の要点にも書いた。qwen-executor の WJE6 が、この修正の後の再開で通った | pjr-7aw0-parent-validation-not-applicable-rejected | - |
| PJR-7WME | done | 個票に起票の元になった項目（derived_from）を記録できるようにする | 個票の frontmatter に derived_from（元になった項目の ID の一覧。project をまたぐ場合は prj-0001:PJR-XXXX）を加え、register add --from で指定できるようにする。元の項目の側から派生先の一覧を辿れるようにし、decision の追跡先も同じ関係で表す。 | todo | high | DEV | 2026-10-18 | - | 2026-10-18 | 個票の frontmatter に derived_from を加え、register add・update の --from（繰り返し可）で指定できるようにした。存在しない項目は理由を出して止める。派生先は generated/pjr-derived-items.md と history で辿れる。CHANGELOG への記載は PJR-HZW3 で補う | pjr-7wme-register-derived-from | - |
| PJR-8WBN | done | 変更の種類で決まる検査の not_applicable を runner が script の有無だけで退ける | 2026-10-18 23:50 に PJR-WSET を agy-expert-executor で流したところ、agy は npm run validate:schema:file を「YAML の成果物を変えていない」として not_applicable と報告した（規約の「YAML 成果物を編集した場合」に従った判断）。runner は script が package.json にあるため当てはまると判定して退け、親検証 7 件が通っていたのに executor validation failed or not run で waiting にした。規約の検査の多くは変更したファイルの種類で当てはまるかが決まるが、runner は script の有無しか見ていない | issue | high | DEV | 2026-10-18 | _TODO_ | 2026-10-19 | 規約の検査の表のうち、変更したファイルの種類で当てはまるかが決まる検査（validate:schema:file・Prettier・markdownlint など）は、該当する変更がなければ not_applicable を受け付けるようにした。修正前の runner はこの修正そのものの run を退けたため、8WBN の worktree で作った dist で reporter と統合を流した（親検証 7 件は修正前の runner で通っていた）。統合後の runner で JSEY が --post-review で通った | pjr-8wbn-conditional-not-applicable-rejected | - |
| PJR-BHMH | done | agent を指定した実行で、上限のときに待つか代わりの agent へ切り替えるかを選べるようにする | exec run --register などで --executor-by により agent を指定した実行は、上限に達すると waiting で止まり、人が --resume するまで再開しない。解ける時刻まで待って同じ agent で再開する（wait）か、指定した代わりの agent へ切り替えて続ける（fallback）かを、コマンドの引数と exec-defaults の既定で選べるようにする | todo | high | DEV | 2026-10-18 | - | 2026-10-18 | agent を指定した実行で、上限のときの扱いを --on-rate-limit（stop・wait・fallback）と exec-defaults の rate_limit_policy.pinned で選べるようにした。wait は解ける時刻まで待って同じ agent で再開し、fallback は --fallback-executor-by・--fallback-reporter-by の agent へ切り替える。既定は従来どおり stop | pjr-bhmh-pinned-agent-rate-limit-policy | - |
| PJR-CCXN | done | devcontainer の scaffold で常時稼働ホストへの接続のサンプルを作る | devcontainer scaffold（init --devcontainer を含む）で、常時稼働ホストで devcontainer を起動して tmux へ入る接続用のスクリプトと、接続元の ssh の config（alias と devcontainer の公開ポートの LocalForward）のサンプルを .devcontainer/remote-host/ に作り、最後の案内で置き場所とコピー先を示す。今は自宅の Mac 向けの設計書にしかなく、利用者に届いていない（2026-10-18、ポートの転送の不足で開発サーバへつながらなかった件を受けて） | todo | medium | DEV | 2026-10-18 | _TODO_ | 2026-10-18 | devcontainer scaffold が .devcontainer/remote-host/ に、devcontainer を起動して tmux へ入る specdojo-tmux.sh.sample と、alias・RemoteCommand・公開ポートの LocalForward を含む ssh-config.sample を作り、最後の案内で置き場所を示すようにした。init --devcontainer は tmux を入れる。ガイドとコマンドリファレンスも合わせた。スクリプトのパスは仮の値のままで、container が見つからないときは vsc- で始まる最初の container を使うため、複数あると取り違えるおそれがある | pjr-ccxn-devcontainer-remote-host-samples | - |
| PJR-FXPH | done | register build が表のセルの | をエスケープせず一覧の表が壊れる | 個票のタイトル・説明・結論に | があると、register build が生成する一覧（pjr-index.md と派生ビュー）の表の列がずれ、lint-md の MD056 で失敗する。2026-10-18 に PJR-BHMH の結論の stop|wait|fallback で起き、並行して動いていた 2 件の run の親の検証が落ちた | issue | medium | DEV | 2026-10-18 | - | 2026-10-18 | register build が表のセルの | をエスケープし、エスケープ済みのものは二重にしないよう直した。テストを加え、親検証は通過した | pjr-fxph-register-build-pipe-escape | - |
| PJR-G5AB | done | init の対話からカタログの質問をなくす | 対話式の init で成果物カタログの size（small など）を選ぶと、全ドメインの dct-*.yaml が一度に展開され、導入直後の利用者には何を残すかが分からない。導入直後に必要なのは register だけのため、対話からカタログの質問をなくし、--catalog の指定でだけ作る。成果物が定まったら catalog scaffold で足すよう案内する（2026-10-18、利用者が案 B を選んだ） | todo | medium | DEV | 2026-10-18 | _TODO_ | 2026-10-18 | 対話式の init から成果物カタログの質問を除き、--catalog を指定したときだけ作るようにした。最後の案内で後から catalog scaffold で足せることを示し、quick start ガイドとコマンドリファレンスを合わせた。案内が参照する quick-start-guide のパスは利用者のリポジトリにはない（node_modules/specdojo の中）ため、URL にするかは後で決める | pjr-g5ab-init-without-catalog-prompt | - |
| PJR-HTAP | open | ローカル LLM の executor の試行の結果（WJE6、2026-10-18） | 同じ todo（WJE6、ガイドへの節の追加）を、Ollama の gemma26（64k・128k）・gemma4 31B（thinking off・on）・qwen3.8 27B（thinking off・on）と agy で exec trial にかけた。gemma26 はツールの失敗から立て直せず止まり、thinking を on にすると遅くなるだけで中身は良くならなかった | note | medium | DEV | 2026-10-18 | _TODO_ | - | - | pjr-htap-local-llm-executor-trial | - |
| PJR-HZW3 | done | v0.4.0 を公開する | 0.4.0 の範囲（agent の名簿の 2 段構成の EANK・YK1C・TSP6・8MPY・8TGQ と、7WME・SJ0G・4Z6N・0JJB）を終えた後、CHANGELOG の記載漏れを補い、develop を main へ昇格して v0.4.0 を公開する | todo | high | DEV | 2026-10-18 | _TODO_ | 2026-10-18 | 範囲の 14 件を close し、specdojo 0.4.0 と @specdojo/docs-lint 0.2.1 を 2026-10-18 に公開した（PR #16 の merge commit 445e611d0、npm run check を通した develop の d56af8fc8 と同じ内容）。公開の workflow と GitHub Pages の deploy は成功し、公開された 0.4.0 を空のリポジトリへ入れて init で 2 段構成の名簿と接続のサンプルが作られることを確かめた。tarball での導入の確認で、新しいリポジトリの最初の実行が止まる不具合 2 件（PJR-Z104・PJR-6EF8）を見つけて公開前に直した | pjr-hzw3-release-v0-4-0 | - |
| PJR-NJ6J | done | --on-rate-limit wait が codex の usage limit で待たずに止まる | 2026-10-18 19:04 に PJR-8TGQ を --on-rate-limit wait と codex-expert-executor で流したところ、codex が「try again at 11:17 PM」の usage limit を返し、runner は Pinned-agent wait skipped: resume time is invalid or exceeds 28800s を出して待たずに waiting で止まった。解除までは約 4 時間で、待てる上限（28,800 秒）より短い。src/exec/limit.ts の解除時刻の読み取りはこの形に対応しているように見えるため、どこで解除時刻が失われるかを調べて直す | issue | high | DEV | 2026-10-18 | _TODO_ | 2026-10-18 | 解除の時刻を出力の全体の最初の一致で読んでいたため、codex が作業中に表示した exec-defaults.yaml のコメントの例（resets 4:10am (UTC)）を本物の通知（try again at 11:17 PM）より先に拾っていた。末尾の行から読むようにし、agy の Resets in 4h36m50s の形も読むようにした。待機を飛ばすときのログを、読み取れない・過ぎている・上限を超えるに分けた。統合後の runner で JSEY が通った | pjr-nj6j-pinned-wait-skipped-usage-limit | - |
| PJR-NSZT | done | 統合後の review の判定のテストを補う | T46Y の完了条件のうち、verdict が complete・complete-with-findings のときに close すること、decision・question を close しないことを確かめる単体テストが入っていない（tests/src/exec/register-post-review.test.ts には incomplete と runner のコードを変えた項目の 2 件だけがある） | todo | medium | DEV | 2026-10-18 | _TODO_ | 2026-10-19 | register-post-review のテストに、complete と complete-with-findings で todo・issue を close する判定（指摘が理由に残ること）と、decision・question は verdict にかかわらず close しない判定を加えた。本番のコードは変えていない | pjr-nszt-post-review-verdict-tests | - |
| PJR-SJ0G | done | register の plan が大きい一覧を読ませ、一覧のパスも誤っている | register の todo の plan（xep-register-template・xep-register-investigate-template）は、進め方の最初で登録簿の一覧の該当行を読ませ、対象項目に一覧のパスを挙げている。一覧は約 479KB あり、文脈が 64k のローカル LLM（gemma26-executor）は分けて読むうちに文脈を使い切り、何も変更せずに終わった（WJE6 の試行 wje6-local-llm）。挙げているパスも controls/project-register/pjr-index.md で、実際の生成先 generated/pjr-index.md と違う。作業に必要なのは個票だけである | issue | medium | DEV | 2026-10-18 | _TODO_ | 2026-10-18 | register の plan の 2 つの雛形から一覧のパスを外し、進め方の最初を個票を読むことにして一覧は読まないと明記した。生成した plan に一覧のパスが含まれないことを単体テストで確かめた。CHANGELOG への記載は PJR-HZW3 で補う | pjr-sj0g-register-plan-index-input | - |
| PJR-T46Y | done | register の実行のあとに review の agent が判定し、todo と issue を自動で close する | 段階 A。統合の後に review の agent が個票の完了条件・result・差分・検証の結果を照らして verdict を出し、complete なら close、incomplete なら waiting に戻す。runner 自身のコードを変えた項目の動作確認の扱いも決める。 PJR-3DY1 の決定に基づく | todo | high | DEV | 2026-10-18 | - | 2026-10-19 | exec run --register の統合の後に、review の agent（既定は claude-expert-review-executor）が完了条件・result・差分・検証の結果を照らして verdict を出す段を加えた。既定では動かさず、--post-review か register_post_review で有効にする。complete・complete-with-findings なら close、incomplete なら waiting に戻し、runner のコードを変えた項目は人の close に残す。JSEY を --post-review で流し、incomplete で waiting に戻る場合と complete-with-findings で close される場合の両方を確かめた。complete と decision のテストは PJR-NSZT で補う | pjr-t46y-register-post-run-review-auto-close | - |
| PJR-Z104 | done | plan の要点に検査の扱いがなく、新しいリポジトリの最初の実行が止まる | 2219 で plan の共通の規約を参照へ改めた後、plan の本文に残す要点に検査の扱い（当てはまる検査を流し、当てはまらない検査は not_applicable と理由を報告する）が入っていない。0.4.0 の tarball を空のリポジトリへ入れて exec run --register --worktree を流すと、executor（sonnet-executor）は参照先を読まずに command none・not_run と報告し、runner は executor validation failed or not run で waiting にした（2026-10-18）。0.3.1 では同じ手順で通っていた | issue | high | DEV | 2026-10-18 | _TODO_ | 2026-10-18 | 共通の規約の要点に検査の扱い（適用条件で流す検査を決め、当てはまらない検査は not_applicable と理由、not_run は流せたのに流さなかった検査に限る）を移し、詳細側は要点を参照する形にした。6EF8 とあわせて、npm init -y で作った空のリポジトリで 0.4.0 の tarball の最初の実行が close まで通った | pjr-z104-plan-essentials-validation-rule | - |
| PJR-2219 | done | plan の共通の規約を参照にする | plan の本文には異常終了の条件と共通の規約の要点だけを残し、詳細は worktree から読める別ファイルを参照させる。PJR-WA3R の決定に基づく | todo | medium | DEV | 2026-10-17 | - | 2026-10-18 | plan の本文には、共通の規約の断片の印で囲んだ要点と、詳細の参照パス・作業前に読む指示だけを載せるようにした。要点は詳細から機械的に取り出し、原本は断片の 1 か所。印のない断片は全文を載せる。参照先は利用者のリポジトリでは node_modules/specdojo の中で、worktree の npm ci で読める | pjr-2219-exec-plan-conventions-reference | - |
| PJR-4Z6N | done | register から approach で実行する手順をガイドに書く | register の todo から approach を使って成果物と kata を作る・直す手順と、exec run --deliverable との違いを exec のガイドに書く。PJR-H72A の決定に基づく | todo | medium | DEV | 2026-10-17 | - | 2026-10-18 | exec-operation-guide に、register の todo から approach で成果物と kata を作る・直す手順の節を加えた。approach と target の指定、kata の approach の選び方、組み合わせの誤りのエラー、exec run --deliverable との違いを書き、register-operation-guide から参照した | pjr-4z6n-register-approach-guide | - |
| PJR-613H | done | ENOBUFS のテストが負荷によって失敗する | tests/src/exec/worktree.test.ts の reports ENOBUFS のテストは、子プロセスに 64 KB を書かせて maxBuffer 1 KB で止められることを確かめる。負荷が高いと子プロセスが止められる前に書き終えて終了コード 0 になり、status が null でなくなって失敗する | issue | medium | DEV | 2026-10-17 | - | 2026-10-17 | ENOBUFS のテストの子プロセスが止められるまで書き続けるようにし、確かめる中心を result.error の ENOBUFS にした。src の動作は変えていない | pjr-613h-enobufs-test-flaky | - |
| PJR-6CDS | done | grade の単体テストがリポジトリの実際の評価結果に左右される | tests/src/grade.test.ts の plan の生成のテストが、リポジトリの本物のサンプルと保存済みの評価結果を読む。定期評価で opr-batch-sample の指摘の anchor に見出しが入り、plan に載ったため、2026-10-17 05:00 の kata の Run の review の検証で失敗した。Run を統合すると develop でも失敗する | issue | high | DEV | 2026-10-17 | - | 2026-10-17 | grade の plan のテストを fixture の評価対象と参照で確かめる形に直し、保存済みの評価結果に左右されないようにした | pjr-6cds-grade-test-depends-on-stored-results | - |
| PJR-8GQ4 | done | devcontainer の作業ディレクトリが /workspaces/specdojo-workspace に固定されている | devcontainer scaffold の雛形が、親のディレクトリを /workspaces/specdojo-workspace にマウントし、作業ディレクトリを /workspaces/specdojo-workspace/<repo> にする。利用者の親のディレクトリが app1-workspace でも specdojo-workspace という名前になるため、親のディレクトリの名前（例: /workspaces/app1-workspace/app1-specdojo）に合わせる | issue | medium | DEV | 2026-10-17 | - | 2026-10-17 | devcontainer scaffold が作業ディレクトリに親のディレクトリの名前を使い、--workspace-name で上書きできるようにした。パスに使えない名前は理由を出して止める。CHANGELOG の記載は公開済みの 0.3.1 の節に入っていたため、0.4.0 の節へ移した（73a28cecd） | pjr-8gq4-devcontainer-workspace-dir-fixed | - |
| PJR-8TS6 | done | result の変更ファイルの説明が「reporter の説明がないため」で埋まる | reporter が変更ファイルごとの説明を返さないと、runner が result の変更ファイルの欄を「reporter の説明がないため、変更差分を参照」で埋める。PJR-XP0J の result では多くの行がこの文で、何を変えたかが result から読めない | issue | low | DEV | 2026-10-17 | - | 2026-10-18 | reporter が説明を返さなかった変更ファイルに、git から分かる変更の種類と行数を書くようにした。50 件を超えるとディレクトリごとの件数にまとめる。reporter の指示と雛形も見直した。空の catch と略した変数名、本リポジトリの .claude/agents/claude-reporter.md への指示の反映は残っている | pjr-8ts6-reporter-changed-files-missing-description | - |
| PJR-B3XQ | done | specdojo init で provider の入力を誤ると最初から入力し直しになる | 対話式の specdojo init で agent の provider の設定を誤ると、プロジェクトや名簿などの入力を含めて最初からやり直しになる。誤った provider の設定だけを入力し直せるようにする | issue | medium | DEV | 2026-10-17 | - | 2026-10-17 | 対話式の init で、各質問の直後に答えを検証し、誤りなら理由を出してその質問だけを聞き直すようにした。非対話では従来どおり誤りで終える。Claude Code を選んだときの最後の案内を orch:opus に揃えた | pjr-b3xq-init-provider-retry-restarts | - |
| PJR-BZ9J | done | src/exec の run と schedule をサブディレクトリへ分ける | src/exec の 74 ファイルのうち、run- の 18 ファイルを src/exec/run/、schedule- の 11 ファイルを src/exec/schedule/ へ codemod で移す。残りは src/exec に置く。PJR-V23P の決定の 4（移した後の実態を見て決める）に基づく | todo | low | DEV | 2026-10-17 | - | 2026-10-17 | codemod で src/exec の run の 18 ファイルを src/exec/run、schedule の 11 ファイルを src/exec/schedule へ移し、テストも同じ構成にした。src/exec の直下は 45 ファイルになった。全 106 コマンドの --help は移す前と一致し、分割後の runner で PJR-JSEY が統合まで通った | pjr-bz9j-src-exec-run-schedule-subdirs | - |
| PJR-CY80 | done | checkpoint の確認の git の失敗が原因を残さない | src/exec/worktree-ops-lifecycle.ts は checkpoint の前に git diff --cached --quiet で変更を確かめ、終了コードが 0 と 1 以外なら Failed to inspect execution checkpoint changes. とだけ出す。git の終了コードと stderr を記録しないため、2026-10-17 の PJR-GBWW で止まった原因を特定できなかった | issue | medium | DEV | 2026-10-17 | - | 2026-10-17 | checkpoint の確認の git の失敗で、終了コード・stdout・stderr を失敗のログに残し、エラーのメッセージに原因の要約を含めるようにした。src/exec の同じように原因を残さない箇所も直した | pjr-cy80-checkpoint-inspect-failure-no-detail | - |
| PJR-DT3Q | done | git の一時的な失敗の再試行が worktree の作成で失敗する | src/exec/worktree.ts は dubious ownership などの一時的な git の失敗を再試行する。git worktree add -b は最初の試みで worktree と branch を作ったうえで失敗を返すことがあり、再試行が branch がすでにあるで失敗して run が waiting になる。2026-10-17 の PJR-MX4F で起きた | issue | medium | DEV | 2026-10-17 | - | 2026-10-17 | 一時的な git の失敗の再試行の前に目的の状態を照合する仕組みを加え、git worktree add では作成済みなら続行し、branch だけの作りかけは片付けて再試行し、別の commit を指す branch は消さずに失敗させるようにした | pjr-dt3q-transient-git-retry-not-idempotent | - |
| PJR-E025 | done | 汎用の部品の移動の後に残る循環をほどく | register から exec/worktree-ops・exec/slot-lock、job から exec/plans、grade から exec/schedule-index、exec から grade/result などの残りを 1 件ずつ見て、shared へ移すか依存の向きを逆にする。 PJR-QQKY の決定に基づく。動作は変えない | todo | low | DEV | 2026-10-17 | - | 2026-10-18 | 4 組の循環（register→exec/worktree-ops・slot-lock、job→exec/plans、grade→exec/schedule-index、exec→grade/result）を、ロック・git・plan の雛形・schedule の索引・grade の result の型などを src/shared へ移してほどいた。register・job・grade から exec、exec から grade への import はなくなった。result に組ごとの判断と --help の一致の記録がないため、orchestrator が import を数えて確かめ、統合後の runner で JSEY を流した。schedule-index など機能に属するものを shared に置いた是非は PJR-WSET で見直す | pjr-e025-src-remaining-cycles | - |
| PJR-GBWW | done | exec の汎用の部品を src/shared へ移す | exec/shared の補助関数、exec/types の共通の型、exec/worktree の git と worktree の操作のうち、exec 以外の機能から使われる部分を src/shared へ移す。 PJR-QQKY の決定に基づく。動作は変えない | todo | low | DEV | 2026-10-17 | - | 2026-10-17 | exec の汎用の補助関数を src/shared の fs・time・text・artifact-path、共通の型を src/shared/agent-types.ts、git の起動と再試行を src/shared/git.ts へ移した。循環は 6 組から 5 組になり、exec と schedule の循環が解け、register から exec は 12 件から 3 件に減った | pjr-gbww-exec-shared-parts-to-shared | - |
| PJR-H06F | done | exec run --register で approach の plan の作り方を使う | 個票に approach があれば、schedule と同じ plan の作り方（approach のテンプレート、kata の参照、DCT の done_criteria）を使い、個票の完了条件を追加の条件として載せる。kata の id を対象にした保守の approach にも対応する。PJR-H72A の決定に基づく | todo | medium | DEV | 2026-10-17 | - | 2026-10-18 | 個票に approach があれば schedule と同じ plan の作り方（approach のテンプレート・kata・DCT の完了条件）を使うようにした。plan の内容は一時 worktree で、runner の動作は JSEY で確かめた | pjr-h06f-register-approach-plan-generation | - |
| PJR-MX4F | done | 記帳の衝突を解いた統合のあとに dist が作り直されない | exec の統合で登録簿の記帳の衝突を解くと、runner は git commit --no-verify で merge を完了させる。post-merge の hook（build-if-stale）は git merge が完了したときにしか動かないため、この経路では dist が作り直されず、以後の runner が古いコードで動く。2026-10-17 の PJR-BZ9J と PJR-X8Y9 で起きた | issue | high | DEV | 2026-10-17 | - | 2026-10-17 | 統合の完了後に、衝突の有無によらず runner が tools/build-if-stale.mjs を起動して dist の鮮度を判定するようにした。dist を bin とする開発のリポジトリだけを対象とし、失敗しても統合を失敗させない。記帳の衝突を解く統合の後に起動されることを統合テストで確かめた | pjr-mx4f-integrate-conflict-commit-skips-dist-rebuild | - |
| PJR-S9QF | done | approach のない result の第 4 章を「進め方」に改める | approach のない実行（register の todo など）の result では、見出しを「4. 進め方」にし、記入の指示をどう進めたか・根拠にした文書や規約に変える。approach のある実行は今のまま | todo | medium | DEV | 2026-10-17 | - | 2026-10-18 | approach のない実行の result の第 4 章を「4. 進め方」にし、どう進めたかと根拠にした文書・規約を書く指示に変えた。approach のある実行は今の見出しのまま。eject した古い雛形でも見出しを差し替える。本件自身の result は修正前の runner が作ったため旧い見出しのまま | pjr-s9qf-result-approach-section-for-register | - |
| PJR-WSET | done | 循環のなくなった機能の組に依存の向きの規則を足す | 循環がなくなった機能の組（register は exec を import しない、など）の依存の向きを ESLint の規則として error で足す。 PJR-QQKY の決定に基づく。動作は変えない | todo | low | DEV | 2026-10-17 | - | 2026-10-19 | 循環がなくなった 6 組（register・schedule・job・grade は exec を、review は grade を、docs は catalog を import しない）の依存の向きを ESLint の no-restricted-imports に error で加え、今のコードの違反が 0 件であることと、規則が効くことを確かめた。shared に置くものを見直し、1 機能からしか使われない 6 モジュールと機能固有の 2 モジュールを戻す候補にした。--help の出力は全 123 コマンドで一致した。3 機能以上をまたぐ循環は対象外として残った | pjr-wset-src-feature-direction-rules | - |
| PJR-Y79W | done | README・LP・init のガイドの内容を揃え、README に specdojo.org へのリンクを加える | README、ランディングページ（specdojo-lp、specdojo.org）、specdojo init のガイドの導入の手順と説明が食い違ってきている。内容を突き合わせて揃え、README から specdojo.org へリンクする | todo | medium | DEV | 2026-10-17 | - | 2026-10-17 | LP を正として、README の始め方を app1-workspace/app1-specdojo の構成と npx specdojo init に揃え、docs-lint を任意の手順に、config init と config scaffold を個別の設定の章に移し、specdojo.org へリンクした。quick-start-guide と use-case-guide も揃えた。init の最後の案内が orch:sonnet を勧める点は PJR-B3XQ で直す | pjr-y79w-readme-lp-init-guide-alignment | - |
| PJR-YFBW | done | オーケストレーターの運用ガイドに plan モードと register の使い分けを書く | Claude Code などの plan モードの plan（会話の中の下書き、既定で約 30 日で消える）と、register（ID・種類・状態の遷移・exec の plan と result への接続・decision の承認の記録）の違いと使い分けを、オーケストレーターの運用ガイドに書く。plan モードは下書きとし、残す判断は decision、作業の範囲は todo の完了条件へ書き写す流れを示す | todo | low | DEV | 2026-10-17 | - | 2026-10-18 | オーケストレーターの運用ガイドに「plan モードと register の使い分け」の節を加え、識別・種類・状態・実行とのつながり・承認の記録・履歴・一覧の観点の対比と、plan モードの下書きから decision と todo へ書き写す運用の流れを書いた | pjr-yfbw-guide-plan-mode-vs-register | - |
| PJR-Z4PM | done | review と grade、docs と catalog の循環をほどく | review から grade/result と、docs から catalog/build の 1 件ずつの依存を直す。 PJR-QQKY の決定に基づく。動作は変えない | todo | low | DEV | 2026-10-17 | - | 2026-10-18 | review/grade.ts が使う grade の結果を src/shared/grade-result.ts、yaml-pages が使うカタログの描画とパスを src/shared/catalog-render.ts・catalog-paths.ts へ移し、grade と review、catalog と docs の循環をほどいた。残る循環は exec と grade・register・job の 3 組 | pjr-z4pm-src-small-cycles | - |
| PJR-ZJXQ | done | 個票に approach と対象を書けるようにする | 個票の frontmatter と schema に approach と targets（成果物の local_id か kata の id）を加え、register add --approach --target で指定でき、組み合わせの誤りを起票の時点で止める。PJR-H72A の決定に基づく | todo | medium | DEV | 2026-10-17 | - | 2026-10-18 | 個票の frontmatter に approach を加え、register add・update の --approach・--target で書けるようにした。approach を書いた個票は対象を 1 件必須とし、成果物の approach の対象は成果物カタログで、kata の approach の対象は文書の索引で解決し、組み合わせの誤りを起票の時点で止める | pjr-zjxq-register-approach-fields | - |
| PJR-2CQR | done | 実行中の routine が前回の結果のまま表示される | routine run は開始時に routine-state.json の last_run だけを更新し、前回の last_result と last_reason を残す。実行中の routine list は今回の開始時刻と前回の結果（failure など）を並べて表示するため、実行中の Run が失敗したように見える | issue | low | DEV | 2026-10-16 | - | 2026-10-18 | routine run が開始時に last_result を running にし、前回の結果と理由を表示しないようにした。終了時に今回の結果で上書きする。運用ガイドの状態の説明も直した | pjr-2cqr-routine-state-running-shows-previous-result | - |
| PJR-G5S2 | done | src の移動の codemod を作る | 移す前後のパスの対応表を入力に、git mv による src と tests のファイルの移動、相対 import の書き換え、dist のパスを参照する箇所の検出を機械的に行うスクリプトを作る。 PJR-V23P の決定に基づく | todo | medium | DEV | 2026-10-16 | - | 2026-10-16 | tools/src-move-codemod.mjs を作った。対応表を入力に git mv による src と tests の移動、相対 import の書き換え、自分の位置からパスを組み立てる箇所と文字列のパスの検出を行い、--dry-run と未 commit の変更での停止を備える。検出の一覧に履歴のファイル（個票・evidence）が含まれる点は改善点として残る | pjr-g5s2-src-move-codemod | - |
| PJR-KECW | done | job・routine・kata・deliverable・devcontainer・review・docs を移す | codemod で小さい機能のファイルを src/job/・src/routine/・src/kata/・src/deliverable/・src/devcontainer/・src/review/・src/docs/ へ移す。 PJR-V23P の決定に基づく | todo | medium | DEV | 2026-10-16 | - | 2026-10-16 | codemod で job・routine・kata・deliverable・devcontainer・review・docs の 21 ファイルとテスト 13 件を各ディレクトリへ移した。git は 34 件を rename と認識し、dist の古い出力は残らず、--help（23 コマンド）は移す前の 0.3.1 と一致した | pjr-kecw-src-move-small-features | - |
| PJR-MHHP | done | 共通の処理を src/shared へ移す | codemod で yaml・git-environment・specdojo-config・spawn-self などの共通の処理を src/shared/ へ移す。 PJR-V23P の決定に基づく | todo | medium | DEV | 2026-10-16 | - | 2026-10-17 | codemod でコマンドの実装 5 ファイルを src/commands、共通の処理 11 ファイルを src/shared、テスト 17 件を各ディレクトリへ移し、hook の入口（tools/build-if-stale.mjs）と自分の位置から求めるパスを直した。全 106 コマンドの --help は移す前の 0.3.1 と一致し、分割後の runner で PJR-JSEY が統合まで通った | pjr-mhhp-src-move-shared | - |
| PJR-SMK5 | done | schedule と catalog を src/schedule・src/catalog へ移す | codemod で schedule と catalog のファイルを各ディレクトリへ移す。 PJR-V23P の決定に基づく | todo | medium | DEV | 2026-10-16 | - | 2026-10-17 | codemod で schedule と catalog の 19 ファイルとテスト 13 件を src/schedule・src/catalog へ移した。git は 32 件を rename と認識し、--help（10 コマンド）は移す前の 0.3.1 と一致し、移す前後のコードの build の生成物に差分はなかった | pjr-smk5-src-move-schedule-catalog | - |
| PJR-W9RK | done | dashboard と timeline を src/dashboard へ移す | 最初の移動として、codemod で dashboard と timeline を src/dashboard/ へ移し、手順と検証を確かめる。 PJR-V23P の決定に基づく | todo | medium | DEV | 2026-10-16 | - | 2026-10-16 | codemod で dashboard と timeline の 7 ファイルとテスト 2 件を src/dashboard・tests/src/dashboard へ移し、検出の一覧から履歴のファイルを除くよう codemod を直した。git は 9 件を rename と認識し、dist の古い出力は残らず、--help は移す前の 0.3.1 と一致した | pjr-w9rk-src-move-dashboard | - |
| PJR-X8Y9 | done | src の機能の間の依存の向きの規則を入れる | 移動の後に、shared/ が他の機能を import しないことなど、機能の間の依存の向きを ESLint の no-restricted-imports などで検査する。 PJR-V23P の決定に基づく | todo | medium | DEV | 2026-10-16 | - | 2026-10-17 | src/shared/specdojo-config.ts の src/exec への依存をなくし（型を src/shared/agent-types.ts、provider-scaffold を src/shared へ移した）、src/shared が他の機能を、機能が src/commands と src/specdojo.ts を import しない規則を ESLint の no-restricted-imports で error として入れた。機能どうしの循環は PJR-QQKY で扱う | pjr-x8y9-src-dependency-direction-rules | - |
| PJR-XP0J | done | exec を src/exec へ移す | codemod で exec の 73 ファイルを src/exec/ へ移し、移した後の exec/ の中をさらに分けるかを判断する。 PJR-V23P の決定に基づく | todo | medium | DEV | 2026-10-16 | - | 2026-10-17 | codemod で exec の 73 ファイルと role-types を src/exec、テスト 66 件を tests/src/exec へ移し、src の直下は specdojo.ts だけになった。全 106 コマンドの --help は移す前の 0.3.1 と一致し、hook の入口が動き、分割後の runner で PJR-JSEY が統合まで通った。src/exec の 74 ファイルは run 18・schedule 11・worktree 6 などで、さらに分けるかは別に判断する | pjr-xp0j-src-move-exec | - |
| PJR-YH9Q | done | grade と register を src/grade・src/register へ移す | codemod で grade と register のファイルを各ディレクトリへ移す。 PJR-V23P の決定に基づく | todo | medium | DEV | 2026-10-16 | - | 2026-10-17 | codemod で grade の 13 ファイルと register の 16 ファイル、テスト 14 件を src/grade・src/register へ移した。--help（25 コマンド）は移す前の 0.3.1 と一致した。src/grade.ts は再 export だけの 22 行で import のパスがすべて変わったため、git は rename ではなく追加と削除と判定した | pjr-yh9q-src-move-grade-register | - |
| PJR-13M6 | done | exec-worktree-ops.ts・exec-repo-integration.ts・exec-reporter.ts を分ける | worktree の操作、プロダクトリポジトリの統合、reporter の処理（合わせて 3,748 行）を責務ごとのモジュールへ移す。 動作は変えない | todo | low | DEV | 2026-10-15 | - | 2026-10-15 | exec-worktree-ops を commit・lifecycle・merge、exec-repo-integration を git・sync、exec-reporter を output のモジュールへ分け、すべて 1,000 行以下にした。export と --help は分割の前後で一致し、分割後の runner で PJR-JSEY が統合まで通った | pjr-13m6-exec-worktree-integration-split | - |
| PJR-3P4W | done | job.ts・routine.ts を分ける | Job と routine の処理（合わせて 2,644 行）を責務ごとのモジュールへ移す。 動作は変えない | todo | low | DEV | 2026-10-15 | - | 2026-10-15 | job.ts と routine.ts の定義の読み込みと検証を job-definition・routine-definition へ移し、すべて 1,000 行以下にした。export と job・routine の 9 コマンドの --help は分割の前後で一致し、routine 9 件と job 8 件の validate が通った | pjr-3p4w-job-routine-split | - |
| PJR-8MPY | done | 本リポジトリの agent の名簿を 2 段構成へ移す | 本リポジトリの agent-members.yaml と exec-defaults.yaml を実体と別名の 2 段へ移し、今の名前を別名として残す。Job・routine の指定が別名で動くことを確かめる。 PJR-ZM1K の決定に基づく（Y8P9 の完了後、0.4.0） | todo | medium | DEV | 2026-10-15 | - | 2026-10-18 | 本リポジトリの名簿を実体 39・別名 18 の 2 段へ移し、今の名前をすべて別名として残した。exec-defaults の起動のコマンドを役割の定義と {model} で組み立てる形にした。0ZAS に従い thinking を有効にした executor・gemma26 の executor・oMLX の定義を無効にした。Job 8 件・routine 9 件の検証が通り、Job と routine の名前は別名で正しい起動のコマンドになる | pjr-8mpy-agent-members-migration | - |
| PJR-8TGQ | done | 配布する agent の雛形を 2 段構成へ改める | config scaffold・init などが生成する agent の名簿と定義の雛形を 2 段構成へ改め、ガイドと移行の手順を更新する。CHANGELOG の 0.4.0 に記載する。 PJR-ZM1K の決定に基づく（Y8P9 の完了後、0.4.0） | todo | medium | DEV | 2026-10-15 | - | 2026-10-18 | init --exec と config scaffold が配布する名簿と定義の雛形を、実体（sonnet・terra・gemma・flash の系統と役割）と今の名前の別名の 2 段構成に改め、起動のコマンドを --agent {agent} --model {model} にした。既存の 1 段の名簿はそのまま動き、移行の手順を exec-config-guide に書いた。空のリポジトリで init --yes --exec を流し、別名から起動のコマンドが組み立てられることを確かめた。opencode の既定の model は本リポジトリの Ollama の名前（gemma4:31b-mlx-work-64k）のままで、利用者の環境に合わせて書き換える必要がある | pjr-8tgq-agent-members-templates-update | - |
| PJR-EANK | done | agent の名簿の schema に実体の model と別名を加える | agent-members の schema に、実体の provider・model・effort と、別名（実体を指す名前）を加え、検証（別名の循環・存在しない実体・無効な実体を指す別名）を入れる。 PJR-ZM1K の決定に基づく（Y8P9 の完了後、0.4.0） | todo | medium | DEV | 2026-10-15 | - | 2026-10-18 | agent-members の schema に実体の model・effort と、実体を指す別名（aliases、alias_of）を加えた。名簿の読み込みで別名の循環・存在しない実体・無効な実体を指す別名を、名簿のファイルと名前を含めてエラーにする。今の 1 段の名簿もそのまま読める。名前の解決は PJR-YK1C で行う | pjr-eank-agent-members-alias-schema | - |
| PJR-JSEY | done | runner 変更後の exec run 動作を確かめる | runner・register・exec のコード変更を統合した後に exec run --register を 1 件流し、executor・親の検証・reporter・統合まで終わることを確かめるための動作確認用の項目 | todo | low | DEV | 2026-10-15 | - | 2026-10-31 | PJR-B5TY の組み込みの後、exec run --register が start から review まで通り、親の検証で lint-mermaid が流れて通った | pjr-jsey-exec-run-split-smoke | - |
| PJR-NA04 | done | exec-plans.ts・exec.ts・exec-trial.ts を分ける | exec の plan の生成、exec のコマンドの登録、trial（合わせて 4,045 行）を責務ごとのモジュールへ移す。 動作は変えない | todo | low | DEV | 2026-10-15 | - | 2026-10-15 | exec-plans を core・generation・storage、exec を core・commands、exec-trial を core・commands のモジュールへ分け、すべて 1,000 行以下にした。export と exec の 18 コマンドの --help は分割の前後で一致し、分割後の runner で PJR-JSEY が統合まで通った | pjr-na04-exec-plans-trial-split | - |
| PJR-P038 | done | register.ts の残りのドメインの処理を分ける | src/register.ts（2,418 行）に残る登録簿のドメインの処理（移行・番号の振り直し・派生ビュー・項目の更新など）を責務ごとのモジュールへ移す。 動作は変えない | todo | low | DEV | 2026-10-15 | - | 2026-10-15 | register.ts の残りのドメインの処理を core・migration・renumber・update・views の 5 モジュールへ移し、register.ts は 2,418 行から 629 行になった。--help と export は分割の前後で一致した | pjr-p038-register-domain-split | - |
| PJR-R0K4 | done | dashboard.ts・catalog-build.ts・schedule-strategy-generate.ts を分ける | dashboard、カタログの build、schedule の戦略の生成（合わせて 3,832 行）を責務ごとのモジュールへ移す。 動作は変えない | todo | low | DEV | 2026-10-15 | - | 2026-10-15 | dashboard・catalog-build・schedule-strategy-generate を責務ごとのモジュールへ分け、すべて 1,000 行以下にした。export と 14 コマンドの --help は分割の前後で一致し、分割の前後のコードで build を流した生成物の差分は生成時刻と本件の状態だけだった | pjr-r0k4-dashboard-catalog-schedule-split | - |
| PJR-TMAW | done | result の frontmatter の block_reason に改行があると不正な YAML になる | exec-results.ts が frontmatter を文字列の連結で書き、block_reason を二重引用符で囲むだけのため、改行を含む理由の 2 行目以降が字下げされず YAML として不正になる。js-yaml 4 は読めたが 5 では deficient indentation で失敗し、3 件の過去の result が lint:fm で落ちる | issue | medium | DEV | 2026-10-15 | - | 2026-10-16 | result の frontmatter の文字列の値を YAML として正しく書くようにし、過去の result 3 件を値を変えずに直した | pjr-tmaw-result-frontmatter-block-reason-yaml | - |
| PJR-TSP6 | done | agent の定義を役割ごとの 1 ファイルにまとめる | claude・opencode の agent の定義を model ごとの複製から役割（executor・review executor・reporter など）ごとの 1 ファイルにまとめ、model は --model で渡す。 PJR-ZM1K の決定に基づく（Y8P9 の完了後、0.4.0） | todo | medium | DEV | 2026-10-15 | - | 2026-10-18 | claude と opencode の agent の定義を、model ごとの複製から役割ごとの 1 ファイルにまとめ、model は --model {model} で渡すようにした。名簿の移行と同時でないと起動できないため、PJR-8MPY と 1 つの変更にして develop へ入れた。統合後に claude・opencode・codex の起動を JSEY と E025 の実行で確かめた | pjr-tsp6-agent-role-definitions-merge | - |
| PJR-X60A | done | 配布する雛形と文書の agy の model の ID が提供終了のものになっている | init が生成する exec-defaults の雛形・antigravity の雛形・ガイドが、agy 1.3.5 で提供されていない gemini-3.1-pro-high・claude-sonnet-4-6・claude-opus-4-6-thinking を指す。0.3.0 で init から agy を設定した利用者は expert の agy が invalid model selection で起動しない。0.3.1 で直す | issue | high | DEV | 2026-10-15 | - | 2026-10-15 | init の雛形・antigravity の雛形と README・ガイド 2 件・設計書・本リポジトリの orch:agy の agy の model の ID を提供中のものへ置き換え、agy models で確かめる旨を書き、init の雛形のテストを加えた。CHANGELOG の 0.3.1 に記載した | pjr-x60a-agy-model-ids-in-templates | - |
| PJR-YK1C | done | agent の別名の解決と記録を実装する | --executor-by などの指定と自動選択で別名を実体へ解決し、model を command_template の {model} で CLI へ渡す。イベントと result の actor には実体の名前を記録する。 PJR-ZM1K の決定に基づく（Y8P9 の完了後、0.4.0） | todo | medium | DEV | 2026-10-15 | - | 2026-10-18 | --executor-by などの指定と自動選択で、別名を実体へ解決するようにした（無効な実体は使わない）。実体の model を command_template の {model} で渡し、model のない今の名簿は command_params のまま動く。イベントと result の actor には実体の名前を記録する。統合後の runner で JSEY が通った | pjr-yk1c-agent-alias-resolution | - |
| PJR-2JFM | done | exec-run.ts の schedule・in-place・job の実行モードを分ける | src/exec-run.ts のうち、schedule のタスクの実行（prepareSingleTask・runPreparedTask・batch・manual）、in-place の実行、Job の実行をモードごとのモジュールへ移す。動作は変えない | todo | medium | DEV | 2026-10-14 | - | 2026-10-15 | schedule のタスクの実行を準備・実行・モードの 3 モジュール、in-place と Job をそれぞれのモジュールへ移し、exec-run.ts は 6,949 行から 3,531 行になった。--help と export は分割の前後で一致し、分割後の runner で PJR-JSEY が統合まで通った | pjr-2jfm-exec-run-split-modes | - |
| PJR-3W2N | done | exec-run.ts の共通部と agent の pipeline を分ける | src/exec-run.ts（8,584 行）のうち、実行モードに共通の型・agent の解決・worker pool・再試行と、executor / reporter の pipeline（runAgentPipeline・runReporterStage）を別のモジュールへ移す。動作は変えない | todo | medium | DEV | 2026-10-14 | - | 2026-10-15 | exec-run.ts の共通部を exec-run-shared・exec-run-agent、pipeline を exec-run-agent-pipeline へ移し、exec-run.ts は 8,584 行から 6,949 行になった。--help と export は分割の前後で一致し、分割後の runner で PJR-JSEY が統合まで通った | pjr-3w2n-exec-run-split-shared | - |
| PJR-GBPX | done | exec-run.ts の register の実行とコマンドの登録を分ける | src/exec-run.ts のうち、register の実行（worktree での実行・統合・再開）と、run・cycle・resume のコマンドの登録を別のモジュールへ移す。動作は変えない | todo | medium | DEV | 2026-10-14 | - | 2026-10-15 | register の実行を core・state・mode・worktree・resume・command の 6 モジュール、run・cycle・resume のコマンドの登録を lifecycle-commands へ移し、exec-run.ts は 66 行の再 export になった。--help と export は分割の前後で一致し、分割後の runner で PJR-JSEY が統合まで通った | pjr-gbpx-exec-run-split-register | - |
| PJR-RY4C | done | 未追跡のファイルが多いと register の --commit が git status failed で止まる | gitResult の spawnSync が maxBuffer を指定しないため、git status --porcelain の出力が既定の上限（1 MB）を超えると失敗し、原因を示さない git status failed になる。2026-10-14 に未追跡のファイル 8,575 個で register close --commit が止まった | issue | medium | DEV | 2026-10-14 | - | 2026-10-14 | gitResult の spawnSync に maxBuffer（256 MiB）を指定し、ENOBUFS・signal・起動の失敗を失敗メッセージに含めるようにした | pjr-ry4c-register-commit-git-status-buffer | - |
| PJR-CA0S | done | docs-site のビルド結果が node_modules の中へ出力される | @specdojo/docs-site 0.2.0 は outDir と cacheDir を package の中（node_modules/@specdojo/docs-site/.vitepress/dist）に置くため、利用者はビルドしたサイトを見つけにくく、npm ci で消える。README にも出力先の記載がない | issue | high | DEV | 2026-10-13 | - | 2026-10-14 | docs-site のビルド結果と cache を workspace 直下の .vitepress/ へ移し、deploy.yml と README を合わせて、本リポジトリと空のリポジトリで出力先を確かめた | pjr-ca0s-docs-site-output-in-node-modules | - |
| PJR-EA20 | done | docs-site のビルドが docs/en のないリポジトリで失敗する | 公開済みの @specdojo/docs-site 0.2.0 は、docs/en がないと sidebar の走査で The path to scan does not exist になり build と dev が止まる。config init は docs/ja だけを作るため、README の手順どおりに導入した利用者が最初のビルドで失敗する | issue | high | DEV | 2026-10-13 | - | 2026-10-13 | docs/<locale> がない locale の sidebar の走査を飛ばすようにし、docs/ja だけ・docs/en だけの workspace と本リポジトリで docs-site のビルドが通ることを確かめた | pjr-ea20-docs-site-requires-en-locale | - |
| PJR-NMSH | done | agy がモデル名を一時的に受け付けず grade が失敗する | agy-expert-executor が --model gemini-3.1-pro-high を「既知のモデルでも custom model でもない」として拒否し exit 1 で失敗した。同じ Run で同じ設定の 12 件は成功しており、一時的な失敗と見られる。再試行や切り分けの方法を決める | issue | medium | DEV | 2026-10-13 | _TODO_ | 2026-10-16 | agy の提供終了の model の ID を agy models の一覧にある ID へ置き換え、直した後の最初の定期実行の grade が統合まで通った | pjr-nmsh-agy-model-not-recognized | - |
| PJR-VGNG | done | 一部の文書が失敗した Job Run が完了分も含めて統合されない | grade の Job Run で一部の文書の評価が失敗すると Job Run 全体が failed になり、review が incomplete と判定して、評価できた文書の結果も統合されない。完了した文書の結果を統合し、失敗した文書は次の Run へ回すことを review の判定で選べるようにする | issue | medium | DEV | 2026-10-13 | _TODO_ | 2026-10-18 | Job Run の状態に partial を加え、Job 定義の partial_exit_code（grade は 2）に一致した終了を部分成功として review・統合するようにした。partial の review は complete-with-findings だけを受け入れ、全件失敗・上限・中断は従来どおり waiting にする。実際の定期実行での確認は次の grade の Run で行う | pjr-vgng-job-run-partial-failure-integration | - |
| PJR-2GZE | done | プロダクトリポジトリの検証を not_run の委譲先として満たせない | executor が not_run と記録したプロダクトリポジトリの検証（例: npm --prefix specdojo-lp run build）は、runner がプロジェクト側で同じコマンドを通した場合しか満たされず、repo 指定の親検証でも解消できないため run が必ず止まる | issue | medium | DEV | 2026-10-12 | _TODO_ | 2026-10-12 | repo を割り当てた親検証の結果で、同じリポジトリの executor の not_run を満たせるようにした | pjr-2gze-product-validation-not-run-delegation | - |
| PJR-4VAC | done | Job Run の review の result が末尾改行を欠き commit 前の検査で統合が止まる | Job Run の review の後に runner が verdict を書き込む fillIncompleteJobReviewResult と overrideJobReviewDecision が result を整形せず末尾改行を欠くため、review の記録の commit が markdownlint の MD047 で失敗し、すべての Job Run が統合されない | issue | high | DEV | 2026-10-12 | _TODO_ | 2026-10-12 | runner が書き換えた Job Run の review の result を整形し、末尾の改行の欠落で commit が止まらないようにした | pjr-4vac-job-review-result-trailing-newline | - |
| PJR-87XS | done | repos の設定から VS Code のマルチルートワークスペースを作れるようにする | 別リポジトリ構成では、プロジェクトリポジトリとプロダクトリポジトリを VS Code で同時に開く必要がある。repos の宣言から <project-id>.code-workspace を作る機能（config scaffold など）を加え、利用者が手で書かなくて済むようにする | todo | medium | DEV | 2026-10-12 | 2026-10-31 | 2026-10-20 | config scaffold --workspace で repos の設定から <project-id>.code-workspace を作れるようにした。repos のない project はエラーにし、既存のファイルは --force がない限り上書きしない。prj-0002 の手作りのものと folders が同じになる | pjr-87xs-code-workspace-scaffold | - |
| PJR-BJTC | done | Job Run の review で executor の not_run が統合を止める | Job Run の review（mode: review）でも、executor が実行しなかった任意の確認を not_run と記録すると edit と同じ規則で run が止まり、verdict が complete-with-findings でも統合されない。review では verdict で統合を判断し、not_run では止めない | issue | high | DEV | 2026-10-12 | _TODO_ | 2026-10-12 | Job Run の review では executor の not_run で止めず、verdict で統合を判断するようにした | pjr-bjtc-job-review-not-run-blocks | - |
| PJR-DXDC | done | --scheduled-at なしの exec run --job で worktree と実行の Run ID が食い違う | task.review を宣言した Job を --scheduled-at なしで手動実行すると、worktree の作成時と worktree 内の子プロセスの実行時に別々に現在時刻を実行枠に使うため Run ID が食い違い、Job Run record was not created in worktree で失敗する | issue | high | DEV | 2026-10-12 | _TODO_ | 2026-10-12 | --scheduled-at なしの手動実行で、親で確定した実行枠を worktree 内の実行へ渡し Run ID を一致させた | pjr-dxdc-job-manual-run-id-mismatch | - |
| PJR-E412 | done | SPECDOJO_REPO_* で指定したプロダクトリポジトリのコマンドを not_applicable の判定が認識しない | runner は agent に SPECDOJO_REPO_<NAME> でプロダクトリポジトリの場所を渡すが、not_applicable の判定（productRepoCommand）は --prefix <repo> と <repo>:<path> しか認識しない。$SPECDOJO_REPO_SPECDOJO_LP/... のコマンドがプロジェクトリポジトリの package.json で判定され、正しい not_applicable が却下されて run が止まる | issue | medium | DEV | 2026-10-12 | 2026-10-31 | 2026-10-19 | $SPECDOJO_REPO_<NAME> と ${SPECDOJO_REPO_<NAME>} の両方の書き方を、not_applicable の判定でそのプロダクトリポジトリのコマンドとして扱うようにした。長い別の環境変数名と取り違えない。テストとガイドも合わせた | pjr-e412-not-applicable-repo-env-path | - |
| PJR-EXH2 | done | プロダクトリポジトリを merge せず exec branch を残す統合方式を選べるようにする | プロダクト側の統合はローカルの merge commit しかない。GitHub flow で PR によるレビューを必須にするプロダクトのため、プロダクト側は merge せず exec branch を残し、PR はプロダクト側で作る方式を repos の設定で選べるようにする | todo | medium | DEV | 2026-10-12 | 2026-10-31 | 2026-10-28 | repos[].integration_strategy に merge / branch-only を追加した。branch-only では exec branch に commit して統合先へ merge せず branch を残し、result に未統合と branch 名・trace key を記録する。push と PR の作成は範囲外 | pjr-exh2-product-repo-branch-only-integration | - |
| PJR-G85C | done | VitePress のビルド対象に exec の plan と result が含まれページ数が増え続ける | Markdown 2489 ページのうち約 1450 ページが exec の plan と result で、exec の実行ごとに 2 ページ増えてビルド時間が伸び続ける。dashboard や個票からのリンクへの影響を確認し、ビルド対象から外すか dev 時のみ外すかを決める | issue | medium | DEV | 2026-10-12 | _TODO_ | 2026-10-22 | plan と result をドキュメントサイトのビルド対象から外し、リンクを GitHub のファイル表示へ置き換えた（PJR-98P8）。手元の docs:build がメモリの上限を広げずに約 113 秒で通る | pjr-g85c-vitepress-exclude-exec-records | - |
| PJR-GRMK | done | pre-commit の catalog-validate が catalog_path のない project で失敗する | lefthook の catalog-validate は project を指定せずに catalog validate を実行するため、SPECDOJO_PROJECT が catalog_path のない project（prj-0002 など）を指すシェルでは、register の記帳だけの commit でも失敗する。 | issue | medium | DEV | 2026-10-12 | 2026-10-31 | 2026-10-12 | catalog_path のない project では pre-commit の catalog-validate を飛ばすようにした | pjr-grmk-catalog-validate-hook-without-catalog | - |
| PJR-HE9R | done | project ごとに parent_validations を足せるようにする | exec-defaults.yaml は project 間で共有され、プロダクトリポジトリ向けの { id, repo } を足すと、その repos を持たない project の run で検証が failed になる。exec-defaults を複製せずに、project ごとに親 runner の検証を足せるようにする（projects.<id>.run での追加や、exec-defaults の引き継ぎなど） | todo | medium | DEV | 2026-10-12 | 2026-10-31 | 2026-10-21 | specdojo.config.json の projects.<id>.run.parent_validations で、共有の exec-defaults の親の検証に project ごとの検証を足せるようにした。指定しない project の動きは変わらない | pjr-he9r-per-project-parent-validations | - |
| PJR-MTFA | done | v0.3.0 の CHANGELOG に 10 月 11 日以降の変更と既知の問題を追記する | PJR-HRMS の完了後に入った変更（複数リポジトリの worktree 準備と統合の修正、routine の Job Run の worktree 実行と統合前 review、Job の review agent 指名、register の agent 自動選択、not_applicable と not_run の判定、config init の .gitignore など）と、公開時点で残る既知の問題を CHANGELOG の 0.3.0 へ追記する | todo | high | DEV | 2026-10-12 | _TODO_ | 2026-10-12 | CHANGELOG の 0.3.0 に 10 月 11 日以降の変更と既知の問題を追記し、移行ガイドに 3 行を加えた | pjr-mtfa-v030-changelog-additions | - |
| PJR-NS8Y | done | parent_validations の許可リストにプロダクトリポジトリ向けの build と format の ID がない | parent_validations の { id, repo } でプロダクトリポジトリの検証を親 runner に任せられるが、許可リストは validate-schema・typecheck・test-unit・test-integration・lint-ts・lint-fm・lint-md だけで、build や format:check がない。agent の sandbox では npm を実行できないため、プロダクトリポジトリのビルドと整形の検査は毎回人が確認している | issue | medium | DEV | 2026-10-12 | 2026-10-31 | 2026-10-19 | 親検証の許可リストに build（npm run build）と format-check（npm run format:check）を加え、プロダクトリポジトリへ割り当てられるようにした。schema・init・ガイド・リファレンスを合わせ、テストを加えた | pjr-ns8y-parent-validation-build-format-ids | - |
| PJR-SAZC | done | 本リポジトリの orch:* の script を orchestrator launch 経由にする | 本リポジトリの package.json の orch:opus などは provider の CLI を直接起動し、specdojo orchestrator launch を経由しないため、repos で宣言したプロダクトリポジトリが --add-dir などで許可されない。config scaffold が利用者に作る script と同じく launch 経由にし、:work の付く script の扱いも決める | todo | medium | DEV | 2026-10-12 | 2026-10-31 | 2026-10-21 | 本リポジトリの orch:* と orch:*:work を orchestrator launch 経由にした。:work は open-agent-worktree.sh が本体の場所を launch へ渡し、worktree の中からも repos の path が本体の隣へ解ける。prj-0002 では LP と assets のリポジトリへの --add-dir と編集の許可が付く | pjr-sazc-orch-scripts-via-launch | - |
| PJR-SZGZ | review | devcontainer に specdojo-lp 用の VS Code 拡張機能を加える | 作業場所の devcontainer で specdojo-lp も開いているが、Astro・Tailwind CSS IntelliSense・ESLint の拡張機能が入っていない。devcontainer.json の customizations.vscode.extensions に加え、作り直したときに自動で入るようにする | todo | medium | DEV | 2026-10-12 | 2026-10-31 | - | - | pjr-szgz-devcontainer-lp-extensions | - |
| PJR-WP44 | done | not_applicable の理由の条件が分かりにくく正当な対象外が失敗扱いになる | catalog_path を設定していない project の catalog validate を executor が not_applicable と記録しても、理由が条件を満たさず失敗扱いになり run が止まる。条件が executor へ伝わっていない | issue | medium | DEV | 2026-10-12 | _TODO_ | 2026-10-12 | プロダクトリポジトリのコマンドはそのリポジトリの package.json で、specdojo コマンドは対象 project の設定で not_applicable を判定するよう直した | pjr-wp44-not-applicable-reason-criteria | - |
| PJR-XRAB | done | exec run でプロダクトリポジトリの統合先を run ごとに指定できるようにする | integration_branch は project の設定に固定され、GitHub flow ではトピックが変わるたびに設定ファイルを書き換える必要がある。exec run に --integration-branch <repo>=<branch> の指定を加え、run ごとに統合先を選べるようにする。 | todo | medium | DEV | 2026-10-12 | 2026-10-31 | 2026-10-21 | exec run --register の worktree の実行に --integration-branch <repo>=<branch> を加え、run ごとにプロダクトリポジトリの統合先を指定できるようにした。優先順位は run の指定、repos の integration_branch、現在のブランチの順で、指定しない場合の動きは変わらない | pjr-xrab-exec-integration-branch-override | - |
| PJR-XY4C | done | devcontainer scaffold の codex でシステムの bubblewrap が sandbox を失敗させる | scaffold が使う typescript-node:22 のイメージに /usr/bin/bwrap があり、codex が同梱の bwrap ではなくそれを使うため codex sandbox が /proc のマウントで失敗する（PJR-27Z9 と同じ事象）。codex の provider を選んだ場合はシステムの bubblewrap を外し、同梱の bwrap を使わせる | issue | high | DEV | 2026-10-12 | _TODO_ | 2026-10-13 | codex を指定した scaffold の post-create でシステムの bubblewrap を削除し、生成した devcontainer で codex の sandbox が動くことを実機で確かめた | pjr-xy4c-devcontainer-codex-system-bwrap | - |
| PJR-1DKD | done | 統合テストが生成済みテンプレートの有無に依存する | exec-register-pipeline-e2e の並列実行の 2 件が、実リポジトリの作業ツリーにある git 管理外の生成済みテンプレートをコピーする前提で書かれており、生成物のない新しい checkout では必ず失敗する | issue | medium | DEV | 2026-10-11 | _TODO_ | 2026-10-14 | fixture が登録簿の生成物を自分で作って commit し、実リポジトリからのテンプレートのコピーでは generated/ を除くようにして、生成物のない checkout でも並列実行の 2 件が通るようにした | pjr-1dkd-integration-test-depends-on-generated-templates | - |
| PJR-86Q5 | done | プロダクトリポジトリの worktree に依存が導入されない | worktree 準備はプロジェクト側の依存だけを導入し、プロダクト worktree では npm ci を行わない。executor の sandbox では npm も実行できないため、プロダクトのビルドや検証を exec 内で確認できない | issue | medium | DEV | 2026-10-11 | _TODO_ | 2026-10-12 | プロダクトの worktree に package-lock.json があれば npm ci で依存を導入するようにした | pjr-86q5-product-worktree-deps-not-installed | - |
| PJR-ADZ6 | done | register の実行で pipeline 用でない agent が自動で選ばれる | exec run --register を --executor-by/--reporter-by なしで起動すると、owner の role で agent が見つからない場合に stage_role を持たない翻訳専用の agent（gemma26-translator）が選ばれる | issue | medium | DEV | 2026-10-11 | _TODO_ | 2026-10-12 | pipeline の指定がない register 実行で stage_role を持つ agent だけを自動選択するようにした | pjr-adz6-register-run-non-pipeline-agent-fallback | - |
| PJR-B2EC | done | 再開時の同期で内容が同じ未追跡ファイルを戻せず再開が拒否される | --resume の同期で、統合先に入れた保護対象と同じ内容の未追跡ファイルが worktree に残ると stash から戻せず再開を拒否する。exec-operation-guide は内容が同じなら解消すると記載している | issue | medium | DEV | 2026-10-11 | _TODO_ | 2026-10-12 | 再開時の同期で、統合先から入った同じ内容の未追跡ファイルを解消済みとして扱うようにした | pjr-b2ec-resume-identical-untracked-restore | - |
| PJR-BJH6 | done | プロダクトリポジトリの package.json も agent の保護対象になる | agent-config-write の保護対象パスがプロダクトリポジトリにも同じく適用され、プロダクトの依存定義を agent が作れない。初期構成や依存追加の作業が必ず block される | issue | medium | DEV | 2026-10-11 | _TODO_ | 2026-10-12 | 保護は残し、申し送りの提案差分を exec handoff apply で確認つきで統合先へ適用できるようにした | pjr-bjh6-product-package-json-protected | - |
| PJR-GBVM | done | 空のプロダクトリポジトリで最上位の新規ファイルが commit 範囲外になる | register 由来タスクのプロダクト worktree では、最上位に作った新規ファイル（.gitignore・設定・README）が targets なしでは commit されず統合前検査で止まる。追跡済みディレクトリの無い初期構成の作業で必ず起きる | issue | medium | DEV | 2026-10-11 | _TODO_ | 2026-10-12 | 使い捨てのファイルを tmp/ に置くよう指示し、tmp/ を除外し、最上位の新規ファイルを commit して申し送りに列挙するようにした | pjr-gbvm-product-root-new-files-out-of-scope | - |
| PJR-NN43 | done | repos を持つ project の worktree 実行がプロダクトの worktree 作成前の build で失敗する | repos を宣言した project で exec run --worktree を行うと、project/ の worktree で specdojo build が設定を読む時点で兄弟のプロダクト worktree がまだなく、repos[].path の存在検査で失敗する | issue | high | DEV | 2026-10-11 | _TODO_ | 2026-10-11 | プロダクトの worktree を project 側の build より先に作る順序に改め、統合テストを 2 件追加した | pjr-nn43-worktree-build-before-product-worktree | - |
| PJR-W2EB | done | npm test の一括実行で負荷によりテストがタイムアウトする | npm test（vitest run）は単体と統合をまとめて既定の並列数で流すため、毎回別のテストが 1〜2 件タイムアウトで失敗する（10/11 に 2 回、exec-pipeline-e2e・exec-worktree-ops・doc-index）。test:unit と test:integration を分けて流すと全件通過する。npm run check が公開判定の基準 2 を満たせない。 | issue | high | DEV | 2026-10-11 | _TODO_ | 2026-10-13 | vitest を unit と integration の project に分けて maxWorkers を 2 に抑え、統合テストの timeout を 30 秒にした。統合後の npm test は 2228 件が通った | pjr-w2eb-npm-test-load-timeout | - |
| PJR-WJ83 | done | project が複数あると specdojo build の index build が他 project の登録簿の欠落で失敗する | --project なしの specdojo build は current_project の登録簿しか生成しないが、index build は全 project の generated/pjr-index.md を要求するため、生成物のない新しい worktree では project が複数あると必ず失敗する | issue | high | DEV | 2026-10-11 | _TODO_ | 2026-10-11 | --project なしの specdojo build が全 project の登録簿を生成するよう修正し、prj-0002 の worktree 準備で通過を確認した | pjr-wj83-multi-project-build-index-register | - |
| PJR-2GFH | done | 公開物の試用で見えた申し送りと反証の細かな問題 | 2026-10-09 の公開物の試用で、(1) reporter が runner の適用外の判定と矛盾する申し送り（catalog validate を実行せよ）を書く、(2) claude の executor が個票を更新したと報告し、変更の一覧に出ないため毎回確認の申し送りが付く、(3) 引数付きの npm run が適用外の申告の反証から漏れる、の 3 点を観測した。 | issue | medium | DEV | 2026-10-09 | _TODO_ | 2026-10-09 | runner の適用外の判定と、executor が変えた runner 管理の記録を reporter の入力（runner_context）へ渡し、矛盾した申し送りと不要な確認依頼を止めた。引数付きの npm run も not_applicable の反証の対象にした。 | pjr-2gfh-exec-handoff-clarity | - |
| PJR-755T | done | 適用外の検査の判定が specdojo のサブコマンドを誤って反証し、not_run の記録も救えない | 公開物の試用（2026-10-09）で、codex は catalog_path のない project の npx specdojo catalog validate を理由付きの not_applicable と記録したが、specdojo が依存にあるため A0NE の反証が block した。claude（sonnet）は未導入の prettier と catalog validate を not_run と記録して止まった。specdojo のサブコマンドは設定で適用条件を判定し、機械的に適用外と分かる not_run は runner が適用外として扱う方式を検討する。 | issue | high | DEV | 2026-10-09 | _TODO_ | 2026-10-09 | specdojo の検査は設定で適用を判定し（catalog validate は catalog_path の有無）、依存の有無で反証しないようにした。機械的に適用外と分かる not_run は runner の判定として申し送りへ出し、block しない。 | pjr-755t-specdojo-not-run | - |
| PJR-DJFT | done | 公開物では grade を通しで実行できない（run-per-document.sh が同梱されない） | 公開物の試用（2026-10-09）で、文書ごとの grade の実行を担う tools/grade/run-per-document.sh（約 1,300 行の bash）が npm package の files に含まれず、利用者は grade plan と grade apply の部品しか使えないことを確認した。案内文書はこのスクリプトを前提にしている。v0.3.0 では grade を部品のみ・試験的と明記するか、CLI に grade run として取り込むかを決める。 | issue | high | DEV | 2026-10-09 | _TODO_ | 2026-10-09 | v0.3.0 の grade を試験的と明記し、run-per-document.sh が package に含まれないこと、catalog_path が要ることを README・CHANGELOG・案内文書へ書いた。部品だけで 1 文書を評価する手順を command-reference に示した。 | pjr-djft-grade-run-per-document-sh | - |
| PJR-PJBN | done | 定期実行の grade がメインの作業ツリーにステージ済みのファイルを残し、exec run が止まる | cron の routine run --due で動く grade のジョブが evidence をメインの作業ツリーで git add したまま commit せずに終わる。その後の exec run --register は checkpoint で Root index has staged changes となり waiting になる（2026-10-09 の PJR-HQKV で発生）。routine の出力を commit するか、ステージしないか、exec 側の扱いを決める。 | issue | high | DEV | 2026-10-09 | _TODO_ | 2026-10-09 | worktree 作成前の検査を checkpoint の対象との重なりに絞り、失敗時の reset を対象のパスに限った。runner の commit または hook が失敗したときにステージを残す 2 経路を特定し、対象だけを戻すように直した。 | pjr-pjbn-grade-exec-run | - |
| PJR-XBDB | done | devcontainer scaffold の Emacs の設定が ~/.emacs.d があると読まれない | devcontainer scaffold --editor emacs の post-create は、init.el がどこにもないときテンプレートを ~/.config/emacs/init.el に置く。Emacs は ~/.emacs.d があると init.el がなくても ~/.config/emacs を読まないため、Emacs を起動したことがある環境やホームを引き継ぐ構成ではテンプレートが黙って無視される（2026-10-09 に実機で確認）。 | issue | medium | DEV | 2026-10-09 | _TODO_ | 2026-10-09 | 生成する post-create を、~/.emacs・~/.emacs.el・~/.emacs.d/init.el・~/.config/emacs/init.el のいずれかがあれば何もせず、なければ ~/.emacs.d の有無で実際に読まれる場所へ置くように直した。一時的な HOME で 3 通りを unit test で確かめた。 | pjr-xbdb-devcontainer-emacs-init-location | - |
| PJR-0WYM | done | README と概要の呼び方を仕様道（Spec-Dō）に改める | prj-0001:pjr-qgp4-naming-spec-do で、SpecDojo を「仕様道（Spec-Dō）の道場」と呼び、技（CLI の機能）と流（approach）に道場の名前を付けることを決めた。README・docs サイトのトップ・概要ガイドは、まだ「仕様駆動開発のためのドキュメントフレームワーク」と呼んでいる。決定に従って、冒頭の文と説明を改める。 | todo | high | DEV | 2026-10-08 | - | 2026-10-08 | README・docs サイトのトップ・概要ガイド・ryu-guide・waza-guide・package.json の説明を、仕様道（Spec-Dō）の呼び方と技・流の名前に改めた。CLI の値は変えていない | pjr-0wym-naming-spec-do-apply | - |
| PJR-17HH | done | 日本語のタイトルから作る個票のファイル名の topic が意味を失う | register add で --topic を省き、タイトルが日本語の場合、topic が item や readme のように英字の部分だけから作られる（例: 「支払い方法をどこまで扱うか」→ pjr-55ww-item.md）。公開物での実地の確認（2026-10-08）で観測。日本語のタイトルでの既定の topic の作り方を見直す。 | issue | low | DEV | 2026-10-08 | - | 2026-10-09 | topic を作れないタイトルでは警告を出して --topic と register update --topic を案内するようにした。オーケストレーターの定義にも、日本語のタイトルでは英語の --topic を渡す手順を加えた（feature/prj-0001/orchestrator-topic-guidance、548a14a87）。 | pjr-17hh-japanese-title-topic-slug | - |
| PJR-44J9 | done | exec plan の共通規約が、新しい利用者の環境で実行できない検査を求める | 公開物での実地の確認（2026-10-08）で、init で作った新しいリポジトリで exec run を流すと、作業は済んだのに executor の検証の失敗で waiting になった。共通規約（xep-common-conventions-template.md）が、Markdown の変更に npx markdownlint（SpecDojo の依存ではない）を、docs/ja/projects/ 配下の変更に specdojo catalog validate（catalog_path がないと実行できない）を一律に求めるため。 | issue | high | DEV | 2026-10-08 | - | 2026-10-08 | 共通規約の検査に適用の条件（package.json の依存の有無、catalog_path の設定など）を付け、条件に当たらない検査は実行も記録もしないようにした。公開物での claude の試しでは、別の問題（PJR-TM1B・PJR-A0NE）で止まった | pjr-44j9-plan-conventions-unavailable-checks | - |
| PJR-5TZS | open | 規模別の kata の組を用意する | 106 種の rulebook から選ぶ負担を減らすため、規模や用途別に 3〜5 種類から始める kata の組（例: 小規模の Web システムの基本設計の一式）を用意し、成果物カタログの初期化で選べるようにする。 | todo | medium | DEV | 2026-10-08 | - | - | - | pjr-5tzs-kata-presets-by-scale | - |
| PJR-6QDA | done | 選択式の specdojo init で、オーケストレーターと agent の実行までの設定を行う | 公開物での実地の確認で、オーケストレーターや exec を使うまでに、provider ごとの scaffold、起動コマンドと agent の名簿の手書き、人の名簿の作成など手作業が多いと分かった。質問に答えるだけで、これらの設定を済ませる選択式の init を v0.3.0 に入れる。 | todo | high | DEV | 2026-10-08 | - | 2026-10-08 | specdojo init を追加した。質問（または --yes とオプション）で設定・登録簿・人の名簿・provider の scaffold・起動コマンドと agent の名簿・カタログ・devcontainer を作る。公開物で init が期待どおり動くことを確かめた | pjr-6qda-interactive-init | - |
| PJR-A0NE | done | 適用されない検査を executor が not_run と記録すると、作業が済んでいても止まる | 公開物での実地の確認（2026-10-08、claude）で、executor が共通規約の「適用条件を満たさない検査は記録しない」に従わず、prettier を「package.json にないので適用外」として not_run と記録し、runner の判定で waiting になった。agent が規約に従わないと止まるため、適用外を表す検証の状態（例: not_applicable）を加えて block しないようにするか、規約の伝え方を強めるかを決める。利用者の判断を待つ。 | issue | high | DEV | 2026-10-08 | - | 2026-10-09 | 検証の状態 not_applicable（理由必須）を加え、package.json に script や依存がある検査の申告と理由のない申告は機械的に block するようにした。適用外の検査は result の申し送りへ出る。共通規約も not_applicable と理由を書く形に改めた。 | pjr-a0ne-not-applicable-check-blocks | - |
| PJR-DQ9E | open | 駄菓子屋のデモのリポジトリを用意する | 共通サンプル文脈（駄菓子屋）で、register・kata・grade の一連の流れを見せるデモのリポジトリを用意する。クイックスタートと発表の記事・動画で使う。 | todo | medium | DEV | 2026-10-08 | - | - | - | pjr-dq9e-demo-repository-dagashiya | - |
| PJR-HQKV | done | 本体の実行時の依存 fast-glob 経由で braces の high の脆弱性が残る | npm audit --omit=dev で、直接の依存 fast-glob → micromatch → braces のサービス不能攻撃の脆弱性が high 3 件として出る（2026-10-08）。修正版はまだない。CHANGELOG の v0.3.0 は依存の脆弱性に対応したと書いている。fast-glob を別の実装（Node 標準の glob など）に置き換えるか、既知の問題として CHANGELOG に書くかを決める。 | issue | high | DEV | 2026-10-08 | - | 2026-10-09 | 本体の fast-glob を依存なしの再帰走査に、docs-lint を tinyglobby に置き換えた。npm ls braces --omit=dev は空、npm audit --omit=dev は 0 件。 | pjr-hqkv-fast-glob-braces-vulnerability | - |
| PJR-HRMS | done | v0.3.0 の CHANGELOG と移行ガイドを最終化する | CHANGELOG の v0.3.0 は 2026-09-29 付けのままで、その後に入った利用者に見える変更（requires_human、--resume-from executor、grade の英語正本と翻訳、合成コマンドの判定など）が載っていない。公開の前に CHANGELOG と移行ガイドを最終化する。 | todo | high | DEV | 2026-10-08 | - | 2026-10-09 | CHANGELOG の v0.3.0 を最終化し、移行ガイドが破壊的変更をすべて扱うことを確認した。公開日の記入は公開当日に PO が行う。 | pjr-hrms-v030-changelog-finalize | - |
| PJR-J29X | done | README とトップに新しい標語と道場の言葉を反映する | 標語を「決めて、書いて、鍛え続ける。」に改め（PJR-QGP4）、README の見出しと冒頭に道場の言葉（記帳・型・実戦・評定・講評・流）を加えて、比喩と機能を結びつける。 | todo | high | DEV | 2026-10-08 | - | 2026-10-08 | README・トップ・概要ガイドの標語を「決めて、書いて、鍛え続ける」に改め、README に道場の言葉の表と記帳・型と実戦・評定と講評の見出しを加えた。package.json の説明も合わせた | pjr-j29x-readme-dojo-vocabulary | - |
| PJR-P8TK | done | 公開前に exec の未解決の不具合を棚卸しし、公開の判定基準を決める | v0.3.0 の公開前に、exec の再開・統合・判定まわりの未解決の不具合と既知の問題を棚卸しし、公開してよいかの判定基準（未解決を許す範囲など）を決める。 | todo | high | DEV | 2026-10-08 | - | 2026-10-14 | 必須の判定基準 7 件をすべて満たし、2026-10-14 に v0.3.0 を npm（provenance 付き）と GitHub Pages へ公開した。docs-lint 0.2.0 と docs-site 0.2.1 も同時期に公開した | pjr-p8tk-release-stabilization-criteria | - |
| PJR-Q7GJ | done | 並列実行で統合の commit のフックのテストが一時的に失敗する | exec run --parallel で 3 件を並べて流したとき、PJR-PG6W の統合段の commit で lefthook の pre-commit が実行する全テストが失敗した。同じ worktree で全テストを実行し直すと 2039 件すべて通り、--resume で統合できた。並列の親検証・統合とフックのテストが重なり、資源の競合で一時的に失敗したとみられる。原因の特定か、統合の commit でのフックの扱いの見直しが要る。 | issue | medium | DEV | 2026-10-08 | - | 2026-10-09 | hook の並列の生成（register-build・index-build）と、実リポジトリの generated/pjr-index.md を読む doc-index のテストの競合を原因と特定し、テストを一時ディレクトリの fixture へ移した。commit・merge の失敗時は hook の出力の全文を integrate.log へ保存し、要約に FAIL と集計の行を残す。 | pjr-q7gj-parallel-integration-hook-flaky | - |
| PJR-SDWF | done | executor が npm run check を not_run とすると、中身が通っていても block される | executor が npm run check を「親 runner の検証と重複する」として not_run と記録すると、runner は check という合成コマンドを実行しないため、中身（typecheck・lint・schema・test など）が runner と executor の検証ですべて通っていても block する。PJR-EZAF と PJR-WPR3 で発生。check の中身を展開して判定する。 | issue | high | DEV | 2026-10-08 | - | 2026-10-08 | 合成コマンドの not_run を、構成するコマンドが runner か executor の検証で通っていれば満たすようにした。PJR-EZAF と PJR-WPR3 が再開で review へ進んだ | pjr-sdwf-composite-check-not-run-block | - |
| PJR-TM1B | done | claude の provider の既定の書き込み許可が狭く、利用者のリポジトリの多くの作業ができない | 公開物での実地の確認（2026-10-08）で、init が claude 用に作る .specdojo/claude/settings.edit.json の許可が Edit(docs/**)・Edit(src/**)・Edit(tests/**) だけのため、README.md への 1 行の追記もできず項目が waiting になった。ルートのファイルや app/・lib/ など別のディレクトリの成果物も編集できない。保護機構（agent-config-write の検査）との兼ね合いで、既定でどこまで書き込みを許すか（例: リポジトリ全体を許し、保護対象は deny と runner の検査で守る）を決める必要がある。利用者の判断を待つ。 | issue | high | DEV | 2026-10-08 | - | 2026-10-09 | claude の edit の既定をリポジトリ全体の Edit 許可にし、保護対象を deny で拒否した。deny と runner の保護対象の一致を unit test で固定した。 | pjr-tm1b-claude-edit-allowlist-too-narrow | - |
| PJR-VX97 | done | 一時的な dubious ownership で git diff が失敗し、再試行されない | worktree で Git が一時的に dubious ownership を返すとき、git diff は「fatal: detected dubious ownership」ではなく「warning: Not a git repository. Use --no-index ...」を出して失敗する。exec-worktree.ts の再試行は前者の文言だけを検出するため、git diff は再試行されず、再開前の統合先の取り込みが拒否される。PJR-EZAF の再開（2026-10-08）で発生した。 | issue | medium | DEV | 2026-10-08 | - | 2026-10-08 | 作業ディレクトリに .git がある場合に限り、Not a git repository の失敗も dubious ownership と同じ間隔・上限で再試行するようにした。.git がない場合は従来どおりすぐ失敗する | pjr-vx97-git-diff-dubious-ownership-retry | - |
| PJR-WZYW | done | agent の定義の分離が、新しい利用者の導入の経路に追従していない | 公開物（npm pack の tarball）での実地の確認（2026-10-08）で判明。(1) loadMemberRoster は project に members_path がないと何も読まずに返すため、config init の既定の設定では .specdojo/agent-members.yaml の agent が読まれず、exec で agent を使えない。(2) templates の codex・copilot・antigravity の README と pm-members-snippet.yaml が、agent の定義を pm-members.yaml へ書くよう案内したままで、そのとおりにすると読み込みがエラーになる。(3) 名簿の schema 違反などの読み込みのエラーを exec run が「agent nickname not found」とだけ表示し、原因が利用者に伝わらない。 | issue | high | DEV | 2026-10-08 | - | 2026-10-08 | members_path がなくても .specdojo/agent-members.yaml の agent を読み込み、名簿の読み込みのエラーの原因を表示するようにした。codex・copilot・antigravity のテンプレートの案内を agent-members.yaml へ改め、スニペットを agent-members-snippet.yaml に改名した | pjr-wzyw-agent-members-onboarding-gap | - |
| PJR-XMQH | done | 仕様の判断台帳としてのクイックスタートを作る | question の起票 → decision で決める → 設計書を 1 つ更新 → 後日 change-request で直す、までを 10 分で体験できるクイックスタートを作る。kata を事前に用意しなくても始められることを示す。 | todo | high | DEV | 2026-10-08 | - | 2026-10-08 | quick-start ガイドの冒頭に、init から question・decision・設計書の更新・change-request・ログの確認までを 10 分で体験する流れを加えた。公開物で手順どおりに動くことを確かめた | pjr-xmqh-quickstart-decision-register | - |
| PJR-BK4K | done | sandbox の外で行う確認を executor が not_run と記録すると完了できない | executor が実 agent CLI の起動など sandbox の外で人が行う確認を not_run と正しく記録すると、runner が同じコマンドを実行しないため、親検証がすべて通っても必ず waiting になる。PJR-69VP の 3 回目の実行で発生し、orchestrator が確認を実行して手で取り込んだ。人の確認として申し送る区分か、reporter 段の再開前に人の確認の結果を記録する手段が要る。 | issue | medium | DEV | 2026-10-07 | - | 2026-10-07 | executor の検証の状態に requires_human を加えた。sandbox の外で人が行う確認に限って使い、機械判定で block せず、result の申し送りに「人の確認が必要」として機械的に載せる。failed と runner が満たさない not_run は従来どおり block する | pjr-bk4k-executor-not-run-human-check | - |
| PJR-J7WE | done | devcontainer scaffold で Emacs の設定をテンプレートから展開する | prj-0001:pjr-2h5f-devcontainer-scaffold の specdojo devcontainer scaffold は、利用リポジトリに devcontainer を生成する。本リポジトリの devcontainer（prj-0001:pjr-fpcm-devcontainer-editor-toolchain）は Emacs と LSP サーバーを入れているが、Emacs の設定は利用者の dotfiles に任せている。 | todo | medium | DEV | 2026-10-07 | - | 2026-10-12 | devcontainer scaffold の --editor emacs で Emacs の設定をテンプレートから展開し、実機で C-h と eglot の LSP 接続を確かめた | pjr-j7we-devcontainer-emacs-template | - |
| PJR-PZPA | done | grade の既定の翻訳の agent を gemma26-translator へ切り替える | prj-0001:pjr-wafc-grade-translation-no-added-code の実モデルでの確認で、gemma26-reporter は翻訳の指示で禁じても英語の語句をバッククォートで囲み、訳さずに残した。原因は reporter 向けの「識別子はインラインコードで囲む」指示とみられる。翻訳だけを担う gemma26-translator（.opencode/agents/gemma26-translator.md、名簿にも追加済み）を orchestrator が追加した。 | todo | medium | DEV | 2026-10-07 | - | 2026-10-07 | grade の既定の翻訳の agent を gemma26-translator に切り替えた。実モデルで 13 件中 12 件が翻訳され、gemma26-reporter（7 件）より改善した | pjr-pzpa-grade-translation-default-translator | - |
| PJR-2T63 | done | agent の定義を pm-members.yaml から保護された設定へ分ける | pm-members.yaml には、人の名簿と agent の定義（provider・モデル・役割、起動コマンドを上書きする command）が同居している。command と provider の command_template は shell 経由で実行されるため、agent が名簿を書き換えられると任意のコマンドを実行できる。そのため b99b3042f で pm-members.yaml を agent の書き込み禁止対象にしたが、人の名簿（ロールや連絡先）まで agent から編集できなくなった。また loadMemberRoster は名簿を schema で検証せずに読む。 | todo | medium | DEV | 2026-10-06 | - | 2026-10-07 | agent の定義を .specdojo/agent-members.yaml へ分け、名簿の読み込みで両ファイルを schema 検証して合成する。pm-members.yaml の agent はエラーにし（案 A）、pm-members.yaml の保護を外した。本リポジトリの agent 37 件を移行し、失われたコメントを補った | pjr-2t63-agent-members-split | - |
| PJR-979N | done | executor が親 runner へ委ねた検証を runner が通しても block される | deriveReporterFacts は executor の passed 以外の検証を一律に失敗とみなす。codex が sandbox で実行できない検証を not_run（親 runner へ委譲）と記録し、runner が同じコマンドを実行して passed になっても block される。PJR-27Y0 で発生。 | issue | high | DEV | 2026-10-06 | - | 2026-10-06 | 親 runner が project で同じコマンドを通した executor の not_run を満たされたものとして扱うよう修正した（73de62d3b） | pjr-979n-delegated-validation-block | - |
| PJR-JWXK | done | grade の翻訳でモデルに印を書かせず、各件をコードで点検する | prj-0001:pjr-27y0-grade-english-canonical-translation の finding の翻訳は、token 付きの文字列配列をモデルに渡し、token の書き写しで順序を検証している。2026-10-06 に pm-risk-register-rulebook.md を codex（判定）と gemma26（翻訳）で実際に流したところ、gemma26 は 13 件すべてを自然な日本語に訳したが、10 件目の token を [T010] ではなく [T10] と書いたため、翻訳全体が捨てられ表示が英語のままになった。 | todo | high | DEV | 2026-10-06 | - | 2026-10-07 | 翻訳の印をコードで管理し、件数・仮名・インラインコードを件ごとに点検、不合格の件だけ1件ずつ訳し直すようにした。実モデルで13件すべて点検に通ることを確認した | pjr-jwxk-grade-translation-code-tokens | - |
| PJR-PG6W | done | register の resume は executor 段へ戻れず、executor 段の再開でも統合先を取り込まない | 親検証の失敗後の resume は reporter 段から始まり、executor に直させる経路がない（--force-restart は worktree ごと捨てる）。executor 段から再開するときは統合先を merge しないため、保護された設定を人が develop へ適用する手順と噛み合わず、手で merge する必要がある。PJR-27Y0 で両方が起きた。 | issue | high | DEV | 2026-10-06 | - | 2026-10-07 | --resume-from executor で reporter 段の run を executor 段から再開でき、失敗の理由を申し送る。すべての段の再開で統合先を取り込む。保護された設定を人が統合先へ適用して再開する流れ（同じ変更なら通り、異なれば衝突として拒否）を integration test で確認した | pjr-pg6w-resume-stage-and-sync | - |
| PJR-R8WR | done | 親検証が失敗したとき、出力の全文を evidence に残し、要約に末尾を含める | 親検証の出力は evidence に先頭から 1,000 文字までの要約としてだけ保存される（src/exec-parent-validation.ts の truncate）。vitest などは失敗したケースの名前と件数を出力の末尾に出すため、失敗の肝心な部分が毎回切り捨てられ、全文も残らない。2026-10-04〜06 の PJR-GBEV・PJR-D0KF・PJR-7MF6 の調査では、作業者がテストを流し直すかテストを一時的に書き換えて出力を取り出す必要があった。PJR-7MF6 の一時的な統合テストの失敗は、再開で evidence が上書きされ特定できなくなった | todo | high | DEV | 2026-10-06 | - | 2026-10-07 | 失敗した親検証の stdout / stderr を秘匿処理のうえ各 1MiB まで evidence のログ（parent-validation-output）に保存し、resume ごとに attempt 番号で追記する。要約は先頭と末尾を残して中間を省略する。成功時は要約だけを残す | pjr-r8wr-parent-validation-failure-output | - |
| PJR-WAFC | done | grade の翻訳で英語の語句をバッククォートで残させない | prj-0001:pjr-jwxk-grade-translation-code-tokens の仕組みで 2026-10-06 に pm-risk-register-rulebook.md の英語の finding 13 件を gemma26 で翻訳したところ、すべて点検に通った。しかし元の英語の文にはバッククォートがないにもかかわらず、gemma26 は decision owner、decision state のように英語の語句をバッククォートで囲み、訳さずに残した。17 件中の大半がこの形で、日本語として読みにくい。 | todo | high | DEV | 2026-10-06 | - | 2026-10-07 | 翻訳の指示で新たなバッククォートを禁じ、訳文のインラインコードが元の文と一致することを点検に加えた。gemma26-reporter では指示が守られないため、翻訳専用の agent への切り替えを後続の todo で扱う | pjr-wafc-grade-translation-no-added-code | - |
| PJR-ZSJQ | done | oMLX の Qwen3.6 を grade の executor として評価する | 2026-10-06、利用者が oMLX に Qwen3.6 35B-A3B（4bit）を導入した。opencode.json の omlx の provider には、モデル qwen3.6-35b-a3b（context 131072、output 32768、thinking ON、Qwen の推奨サンプリング）が定義済みである。一方、Qwen3.6 を使う opencode の agent と、pm-members.yaml の member はまだない。 | todo | medium | DEV | 2026-10-06 | - | 2026-10-07 | Qwen3.6 は grade の判定に使わない。thinking ON は判定が甘く、OFF は Ornith と同程度の精度で約2倍遅く、oMLX の memory guard に拒否されやすい。member は disabled にした | pjr-zsjq-qwen36-grade-evaluation | - |
| PJR-0ECY | done | reporter の変更ファイルの説明の件数がずれると、結果の作成が失敗する | PJR-GBEV で、changed_files のパスは runner が evidence から作り、reporter は同じ件数・同じ順序の説明だけを返す契約にした。LLM の reporter は件数をそろえるのが苦手で、2026-10-05 の並列実行で gemma26-reporter が 4 件に対し 3 件、14 件に対し 6 件を返し、reporter result rendering failed で PJR-86JE と PJR-27Y0 が waiting になった。変更ファイルが多い exec ほど失敗し、今後のすべての exec に影響する | issue | high | DEV | 2026-10-05 | - | 2026-10-06 | reporter の changed_files をパスと説明の組にし、runner がパスで突き合わせるようにした。件数・順序のずれで result 作成が失敗しない。orchestrator がテストの fixture と runner 管理パスの除外（exec/ 全体）を補修した | pjr-0ecy-reporter-changed-files-count-mismatch | - |
| PJR-26K4 | done | grade plan に評価対象と参考資料の本文を埋め込むオプションを追加する | grade plan は評価対象と参考資料をパスで渡すため、executor が自分で読みに行き、対象外のファイルまで読んで遅くなり、読む範囲の違いで判定がばらつく。2026-10-04 の ornith の計測で、本文を行番号付きで埋め込みファイルを読ませない plan にしたところ、tool call が 2〜10 回から 0〜1 回になり、2 回実行した score の差が 5 点から 1〜3 点に縮まった。prj-0001:pjr-9xvg-grade-plan-link-style で全文埋め込みからパス参照へ移した経緯（plan が対象の分量に依存して 6 万字を超える、対象の更新で plan の再生成が必要になる）があるため、既定は変えずにオプションとして追加する | todo | medium | DEV | 2026-10-04 | - | 2026-10-04 | grade plan --embed-documents を追加し、評価対象と参考資料を行番号付きで埋め込めるようにした。既定はパス参照のまま。実際の grade と npm run check で確認した | pjr-26k4-grade-plan-embed-documents | - |
| PJR-27Y0 | done | grade の英語の判定を正本として保存し、gemma26 で日本語へ翻訳する | Ornith の grade の判定を英語で出力させると、日本語より判定が厳しくなり、中国語の字体が混ざらず、検証通過が 5/6 になった（2026-10-04）。grade の記録は日本語の文書で読まれるため、英語の判定を正本として保存し、finding の文だけを gemma26（日本語がきれいで速い）で日本語に翻訳して表示に使う流れを設計する。前回の指摘の引き継ぎは英語の文の一致で行う | todo | medium | DEV | 2026-10-04 | - | 2026-10-07 | grade の英語の判定を正本（message）、日本語の翻訳を表示用（message_ja）として保存する仕組みと、level の下方向の補正を実装した。翻訳の方式は PJR-JWXK・PJR-WAFC で改良した | pjr-27y0-grade-english-canonical-translation | - |
| PJR-27Z9 | done | codex 0.160 の bubblewrap sandbox が devcontainer 内で /proc をマウントできず exec と grade が失敗する | 2026-10-03 のリビルドで codex が 0.160.0 になり、Linux sandbox が bubblewrap 必須になった。devcontainer 内では bwrap: Can't mount proc on /proc: Operation not permitted で起動に失敗し、codex の executor はファイルを読めず異常終了する（codex sandbox linux -- ls -d / でも再現する）。旧方式の landlock（features.use_legacy_landlock）は、ファイル制限を伴う実行で「bubblewrap が必要」として panic するため回避策にならない。codex-* member を使う exec と grade が失敗する。 | issue | high | DEV | 2026-10-04 | - | 2026-10-04 | システムの bubblewrap を外し codex 同梱の bwrap を使わせて解決した。systempaths=unconfined は隔離を弱めるため採用しない。codex sandbox と codex-expert-executor の grade を確認済み | pjr-27z9-codex-bwrap-proc-mount | - |
| PJR-4RR8 | done | qwen と gemma のサンプリングを公式推奨値へ合わせて grade の executor の改善を計測する | qwen と gemma の expert executor は temperature 0.2、Modelfile は top_p 0.9・repeat_penalty 1.05 で、公式推奨（Qwen の thinking・コーディング向け: temperature 0.6 / top_p 0.95 / top_k 20 / repeat_penalty 1.0、Gemma: temperature 1.0 / top_p 0.95 / top_k 64）から大きく外れている。Qwen は thinking で貪欲に近いデコードを避けるよう明記しており、qwen の executor が最大 1,952 秒かかった一因の可能性がある。gemma が良否を区別できない（3 件とも 100）ことや、repeat_penalty による書き写しの崩れにも関係しうる。推奨値の派生モデルを作り、同じ条件で計測して採否を決める | todo | medium | DEV | 2026-10-04 | - | 2026-10-04 | 推奨サンプリングは qwen で速くならず形式が崩れ、gemma は良否を区別できず形式も崩れたため採用しない。grade の用途には現行の低い温度が合う。計測用の agent と登録は削除した | pjr-4rr8-ollama-sampling-recommended-params | - |
| PJR-7MF6 | done | 並列の register 実行で、失敗した項目の遷移が他の項目の統合を妨げる | exec run --register A B --worktree --parallel 2 で A が親検証に失敗すると、A の waiting への遷移と plan・result がメインの作業ツリーに未 commit のまま残り、B の統合の git merge が「ローカルの変更が上書きされる」で失敗する（2026-10-04 の PJR-DAW8 と PJR-KEQQ）。resume では2件の統合 commit が同時に走り、pre-commit の全テストが並行して失敗した。直列に resume し直すと成功した | issue | medium | DEV | 2026-10-04 | - | 2026-10-06 | 並列実行で片方が失敗しても失敗の遷移をそれぞれ commit し、他の項目の統合を妨げないようにした。2026-10-05 の第1陣（3並列）で、3件とも失敗した際に遷移が個別に commit され統合が妨げられないことを実地で確認した | pjr-7mf6-parallel-register-run-integration | - |
| PJR-86JE | done | 日本語の文書に中国語の字体が混ざったことを検出する lint を追加する | ローカル LLM（oMLX の Ornith など）は日本語の出力に中国語の字体・語彙（业、为、时、这个、问题 など）を混ぜることがあり、2026-10-04 の grade の計測では executor の出力の 6 回中 3〜4 回に現れた。agent が日本語の文書を書くと、そのままコミットされる。どの agent が混ぜても検出できるよう、docs-lint に中国語でしか使わない字体を検出する規則を追加する | todo | medium | DEV | 2026-10-04 | - | 2026-10-06 | markdownlint のカスタムルール MD061（no-chinese-glyphs）を追加し、日本語と字形の異なる簡体字 20 字を検出する。コードと URL は対象外、意図した箇所は disable コメントで除外する。統合後に残った 3 件の検出は orchestrator が修正した（d27af7c89） | pjr-86je-docs-lint-chinese-glyphs | - |
| PJR-D0KF | done | exec run --register の既定を worktree にし、in-place を明示指定にする | exec run --register は既定で in-place に実行される。in-place の実行中にメインの作業ツリーで commit すると HEAD 検査（agent-git-state-write）で成功した作業が waiting になり、失敗時の変更が作業ツリーに残って後続の実行も止まる（2026-10-04 の PJR-SMET）。worktree なら作業ツリーが分かれ、失敗時の隔離と --resume が使える。既定を worktree にし、in-place は明示指定にする | todo | medium | DEV | 2026-10-04 | - | 2026-10-06 | exec run --register の実行場所の既定を exec-defaults の run.register_execution で設定できるようにし、本プロジェクトの既定を worktree にした。in-place は --in-place で明示する。--worktree なしの実行が worktree で行われることを実地で確認した | pjr-d0kf-exec-register-worktree-default | - |
| PJR-DAW8 | done | register の自動 commit がタイトルの長さで commitlint に拒否される | exec run --register --register-commit は個票タイトルから exec(register PJR-XXXX): <title> のヘッダーを作るが、長さを調整しない。PJR-27Z9（109 文字）で header-max-length（100）に拒否され、executor・親検証・reporter が成功した実行が commit incomplete として waiting になった | issue | medium | DEV | 2026-10-04 | - | 2026-10-06 | register の自動 commit のヘッダーを header-max-length 内に収めるようにした（超える場合は末尾を … に置き換える）。unit test・integration test と npm run check で確認した。100 文字を超えるタイトルでの実地の確認は未実施 | pjr-daw8-register-commit-header-length | - |
| PJR-E9H3 | done | grade の reporter を LLM から executor の marker の機械変換に置き換える | grade の reporter は executor の [VIEWPOINT] / [DONE_CRITERIA] marker を GradeSubmission JSON へ一字一句写すだけだが、LLM が担うため書き写しの誤り（例: 三箇所→三箇会）、JSON の構文破損、根拠のない JSON の生成が起き、時間もかかる。grade apply は既に executor の分析を parse して忠実性を検証しているため、同じ parse から GradeSubmission を機械的に生成すれば、reporter 起因の失敗をなくし、executor の選択肢も広げられる | todo | medium | DEV | 2026-10-04 | - | 2026-10-04 | grade の reporter の既定を executor の marker の機械変換（machine）にした。grade apply は --analysis-from だけで反映でき、拒否時は executor を1回再実行する。実際の grade 1 件で LLM の reporter を起動せずに記録できることを確認した | pjr-e9h3-grade-deterministic-reporter | - |
| PJR-EZAF | done | devcontainer テンプレートで codex の sandbox が動くか確認し、必要な設定を加える | specdojo devcontainer scaffold のテンプレートはシステムの bubblewrap を入れないため、PJR-27Z9 の /proc の問題は起きない見込みである。一方、runArgs を持たず Docker 既定の seccomp が名前空間の作成（unshare / clone の名前空間フラグ）を禁止するため、codex 同梱の bwrap が sandbox を作れない可能性が高い。Docker が必要なため Host Mac で実際に確認し、問題があれば codex provider の指定時だけ設定を加える | todo | medium | DEV | 2026-10-04 | - | 2026-10-13 | codex 指定時に seccomp=unconfined とシステムの bubblewrap の削除を scaffold が加え、生成した devcontainer で codex の sandbox が動き外への書き込みが拒否されることを確かめた | pjr-ezaf-devcontainer-template-codex-sandbox | - |
| PJR-GBEV | done | exec の reporter の事実項目を evidence から機械生成し、LLM は要約だけに使う | exec の reporter（LLM）は、changed_files のパス・outcome・block_reason という evidence に正確な値がある事実項目まで書き写しており、誤りや根拠のない出力の原因になっている。事実項目は runner が evidence から機械生成し、LLM の reporter は summary などの文章項目だけに使う。review の verdict など判定は executor の申告を正とする方向も検討する。grade の reporter は PJR-E9H3 で機械変換へ置き換え済み | todo | medium | DEV | 2026-10-04 | - | 2026-10-06 | reporter の事実項目（変更パス・outcome・block_reason）を runner が evidence から機械生成するようにした。その後の不具合は PJR-0ECY（件数ずれ）と PJR-979N（委譲した検証の扱い）で修正済み | pjr-gbev-exec-reporter-machine-facts | - |
| PJR-GHKD | done | worktree の resume 前の同期で、衝突確認の git diff がリポジトリ外で実行される | exec run --register --resume は、reporter の再開前に integration target（project/prj-0001/develop）を worktree へ同期する。worktree に未 commit の変更があり develop に新しい commit がある状態で再開すると、同期後の衝突確認 git diff --name-only --diff-filter=U -z が Not a git repository で失敗し、resume refused になる（2026-10-04 の PJR-GBEV）。develop の変更（3 ファイル）と worktree の変更は重ならず、作業者が worktree で git merge を手で行うと衝突なく成功し、その後の resume も成功した | issue | medium | DEV | 2026-10-04 | - | 2026-10-06 | Git 実行ヘルパーの cwd を対象リポジトリへ固定し、resume 前の同期が実行ディレクトリに依存しないようにした。PJR-27Y0 の resume で同期（merge）が成功することを実地で確認した | pjr-ghkd-resume-sync-git-diff-outside-repo | - |
| PJR-KEQQ | done | devcontainer テンプレートの named volume を本体とそろえ、共有の方針を決める | specdojo devcontainer scaffold のテンプレートは、opencode provider でも ~/.local/share/opencode を named volume にしないため、リビルドで OpenCode の API key（auth.json）が消える（本体は PJR-MP2P までに specdojo-opencode-data で対応済み）。volume 名は本体と同じ specdojo-* に固定され、利用リポジトリと本体で認証情報や git 設定を共有する。GitHub CLI の volume もない。テンプレートで作るコンテナの保存先の一覧と、dotfiles が VS Code のユーザー設定で自動導入されることも文書にない | todo | medium | DEV | 2026-10-04 | - | 2026-10-04 | scaffold の named volume を <repository>-specdojo-* としてリポジトリごとに分離し、OpenCode のデータと GitHub CLI の volume を追加した。保存先の一覧、分離の理由、dotfiles の自動導入、volume 名の衝突の注意をコマンドリファレンスに記載した | pjr-keqq-devcontainer-template-volumes | - |
| PJR-SMET | done | review や start への遷移で block_reason が残る | register review で waiting から review へ戻しても、frontmatter の block_reason が残る（PJR-27Z9 で観測）。register update にも block_reason を消す手段がなく、解消済みの理由が表示され続ける | issue | low | DEV | 2026-10-04 | - | 2026-10-04 | waiting 以外への遷移で block_reason を消し、変更前の理由はイベントに残すようにした。register update --block-reason を追加した。実際の遷移と npm run check で確認した | pjr-smet-register-stale-block-reason | - |
| PJR-WJPX | done | gemma4 26B（MoE）を導入し、速度・日本語・判定を計測して使い道を決める | Ornith-1.5（Qwen 系 MoE）は速いが、日本語に中国語の字体が混ざる（2026-10-04 の計測で 6 回中 3〜4 回）。gemma4 31B（dense）は同じ計測で 0 回だった。gemma4 26B-A4B は全 25.2B・動作 3.8B の MoE で Ornith と同程度の速さが見込め、日本語の質は 31B に近いと期待できる。Ollama の gemma4:26b-mlx（18GB）を導入し、grade の executor としての速さ・形式・中国語の字体・判定を計測して使い道を決める。sliding window 主体で長い context に強いため、参考資料付きの評価で 128K の効果も確かめる | todo | medium | DEV | 2026-10-04 | - | 2026-10-04 | gemma4 26B は 31B の約3倍速く日本語に中国語の字体が混ざらないが、判定は甘く参考資料・128K・判定例でも改善しないため、grade の executor には採用せず reporter の要約に使う。gemma26-reporter を追加し tsd-ollama を更新した | pjr-wjpx-gemma4-26b-moe-evaluation | - |
| PJR-MGNW | done | oMLX の手順をアプリ版のメニューバーと Admin UI の操作に直す | tsd-omlx と tsd-omlx-opencode は、インストールはアプリ版を前提にしながら、起動と設定を CLI の omlx serve で説明している。アプリ版の初期設定・メニューバーからの起動・Admin UI での設定（待ち受け・API key・同時リクエスト数・モデル alias）に書き直し、CLI は別の手段として短くまとめる | todo | medium | DEV | 2026-10-03 | _TODO_ | 2026-10-06 | tsd-omlx と tsd-omlx-opencode を macOS アプリと Admin UI の操作を本筋とする手順へ書き直した。残っていた _TODO_（メニューバーの表示名）は利用者が実機で設定しながら解消した（40eb6b03b） | pjr-mgnw-omlx-app-gui-setup | - |
| PJR-MP2P | done | devcontainer の設定の保存先（named volume・コンテナ内のみ・母艦と共有）を文書に明記する | devcontainer の各設定・認証情報が named volume に残るか、リビルドで消えるか、母艦と共有・コピーされるかが文書にない。opencode の API key（~/.local/share/opencode/auth.json）が named volume の外にありリビルドで消えていた件（specdojo-opencode-data を追加して対応済み）を受け、保存先の一覧と、リビルド後に必要な再設定を guide か設計書に明記する | todo | medium | DEV | 2026-10-03 | - | 2026-10-04 | tsd-home-mac-dev-server に設定・認証情報の保存先を named volume・コンテナ内のみ・母艦と共有/コピー・母艦のみの4分類で整理し、再作成後の作業を記載した。tsd-home-mac-dev-server-usage の一覧は正本への参照に置き換えた。docs:build と利用者の確認を経て close した | pjr-mp2p-devcontainer-config-persistence | - |
| PJR-WRE7 | done | oMLX の Ornith のコンテキストを 64K にする | Ornith-1.5（qwen3_5_moe）は 40 層中 10 層だけが通常の attention で、64K × 2 並列でも KV cache は約 2.7GB に収まる。tsd-omlx と tsd-omlx-opencode のコンテキストの既定を 32K から 64K にし、KV cache の見積もりと、メモリより prefill の時間と品質を見る判断の書き方に直す | todo | medium | DEV | 2026-10-03 | _TODO_ | 2026-10-03 | tsd-omlx と tsd-omlx-opencode のコンテキストの既定を 64K にし、config.json に基づく KV cache の見積もり（64K × 2 で約 2.7GB、合計約 24GB）と、prefill の時間・品質を見る判断の書き方に直した | pjr-wre7-omlx-context-64k | - |
| PJR-6RN3 | done | 再開前の統合先の取り込みが統合済みのプロダクトの merge commit を作り直す | PJR-GENJ の再開前の統合先の取り込みが、統合済みのプロダクトの exec branch にも merge を作り、PJR-9KST の統合済みのリポジトリを作り直さない動作と食い違う。develop で両方を合わせた後、9KST の e2e 2 件（app2・project の失敗後の再開）が失敗する | issue | high | DEV | 2026-10-02 | _TODO_ | 2026-10-02 | bookkeepingPaths の呼び出しの型エラーを直し、再開前の統合先の取り込みから統合済みのリポジトリを除外した | pjr-6rn3-resume-sync-remerges-integrated-products | - |
| PJR-FPCM | done | devcontainer に Neovim と Emacs 用の開発ツールを導入する | 開発用 devcontainer に Neovim 0.12（release の tarball）と、両エディタで共通に使う LSP（TypeScript・JSON/ESLint・YAML・Bash・Markdown）・tree-sitter CLI・C コンパイラ・lazygit・git-delta を導入する。エディタの設定とプラグインはイメージに含めず dotfiles と named volume で扱う | todo | medium | DEV | 2026-10-02 | _TODO_ | 2026-10-13 | Dockerfile へ Neovim・LSP・lazygit などを版固定で導入し、dotfiles で設定を入れる構成に変えて、再ビルド後に両エディタの LSP と lazygit を確かめた | pjr-fpcm-devcontainer-editor-toolchain | - |
| PJR-H9R2 | done | 再開前の統合先の取り込みが worktree の未 commit の変更と重なると再開できない | PJR-GENJ の再開前の取り込みは、executor が worktree に残した未 commit の変更と統合先の変更が同じファイルに及ぶと、git merge が上書きを拒み再開できない。executor の成果を退避または commit してから取り込み、衝突は現行どおり理由を示して止める | issue | medium | DEV | 2026-10-02 | _TODO_ | 2026-10-02 | 再開前の取り込みの前に executor の成果を stash で退避し、取り込み後に index を復元せずに戻す。衝突した場合は成果を失わずに止める | pjr-h9r2-resume-sync-uncommitted-overlap | - |
| PJR-K1ZD | done | opencode が生成するプラグインの導入ファイルを保護設定の検査が検出する | opencode の reporter が worktree の .opencode/ にプラグインを自動導入し、package.json・package-lock.json・node_modules とそれらを ignore する .gitignore を生成する。保護設定の検査がこれらを agent による変更として検出し、exec run が止まる。git が ignore する opencode の導入ファイルだけを安全なものとして除外する | issue | high | DEV | 2026-10-02 | _TODO_ | 2026-10-02 | opencode の導入ファイルが git に ignore されている場合だけ保護設定の検査から除外し、agent 定義は引き続き保護する | pjr-k1zd-opencode-plugin-bootstrap-protected-false-positive | - |
| PJR-K6KB | done | grade.ts の責務ごとの分割 | src/grade.ts（3,561 行）を CLI の登録・対象の探索・plan の生成・適用の責務ごとに分ける。動作は変えない（v0.3.0 の公開後） | todo | medium | DEV | 2026-10-02 | _TODO_ | 2026-10-14 | grade.ts を値の扱い・対象の探索・pipeline の状態・plan の生成・適用・Markdown・コマンドの登録の 11 モジュールへ移し、grade.ts は 22 行の再 export になった。--help と既存の export は分割の前後で保たれた。再 export が export * のため、内部用だった 52 の関数も grade.ts から見えるようになった点は改善点として残る | pjr-k6kb-grade-module-split | - |
| PJR-QCMP | done | register.ts のサブコマンドごとの分割 | src/register.ts の registerRegisterCommands（752 行）をサブコマンドごとのモジュールへ分ける。動作は変えない（v0.3.0 の公開後） | todo | medium | DEV | 2026-10-02 | _TODO_ | 2026-10-14 | registerRegisterCommands の 14 のサブコマンドの登録を作成・遷移・保守の 3 モジュールへ移し、依存はインターフェース経由で受け取る形にした。register.ts は 3,156 行から 2,418 行になり、--help の出力は分割の前後で一致した | pjr-qcmp-register-commands-split | - |
| PJR-TH4B | done | ESLint の max-lines と max-lines-per-function を warn で導入する | ファイルと関数の行数の上限を ESLint の warn で導入し、大きくなりすぎたファイルと関数を見えるようにする。上限値は分割後の実態を見て決める（v0.3.0 の公開後） | todo | medium | DEV | 2026-10-02 | _TODO_ | 2026-10-15 | src/**/*.ts に max-lines（1,000 行）と max-lines-per-function（200 行）を warn で入れ、TypeScript の実装ルールに上限と warn の扱いを書いた。warn はファイル 0 件・関数 25 件で、lint:ts は warn では失敗しない | pjr-th4b-eslint-max-lines-guard | - |
| PJR-Y8P9 | done | 1,000 行を超える残りのソースの分割 | dashboard.ts・exec-worktree-ops.ts・exec-plans.ts・exec.ts・job.ts・exec-trial.ts・catalog-build.ts など 1,000 行を超えるファイルを必要に応じて分ける。動作は変えない（v0.3.0 の公開後） | todo | low | DEV | 2026-10-02 | _TODO_ | 2026-10-15 | 1,000 行を超える残りのソースを 5 件に分けて分割し、src に 1,000 行を超えるファイルはなくなった（最大 983 行） | pjr-y8p9-large-source-files-split | - |
| PJR-0WAA | done | 複数リポジトリの統合と再開 | commit 対象の算出と統合をリポジトリごとに行い、宣言順（プロダクト先行）で統合する。統合済みの範囲を pipeline state に記録し、失敗した位置から再開する（v0.3.0） | todo | high | DEV | 2026-10-01 | _TODO_ | 2026-10-01 | リポジトリごとに commit 対象を算出し、事前検査の後に宣言順でプロダクト、最後にプロジェクトを統合する。リポジトリ別の統合状態を記録し、失敗位置から再開する | pjr-0waa-multi-repo-integration-resume | - |
| PJR-30SW | done | プロダクト側 commit の Refs 付与と result の trace 記録 | プロダクト側の commit に Refs: <project-id>:<item-id> を自動で付け、統合後の commit snapshot・PR 参照を result の trace 表へ自動で記録する（v0.3.0） | todo | high | DEV | 2026-10-01 | _TODO_ | 2026-10-01 | runner がプロダクト側の commit と merge commit、プロジェクト側の merge commit に Refs: <project-id>:<item-id> を付け、統合後の trace 表を result に記録するようにした | pjr-30sw-multi-repo-refs-trace | - |
| PJR-69VP | done | 複数リポジトリ構成の実構成検証と文書の更新 | 2 リポジトリの統合テストと e2e で動作を確かめ、docs-structure-guide・exec のガイド・CHANGELOG・移行ガイドを更新する（v0.3.0） | todo | high | DEV | 2026-10-01 | _TODO_ | 2026-10-07 | 3 リポジトリ構成の e2e・失敗と再開・回帰を統合テストで確かめ、文書と CHANGELOG を更新した。実 agent CLI（claude・codex・antigravity）でプロダクトリポジトリへの書き込みを確認する script を追加し、3 つとも成功した | pjr-69vp-multi-repo-e2e-docs | - |
| PJR-98G4 | done | タスク単位の複数 worktree と agent の作業ディレクトリ | <task-id>/ の下にリポジトリごとの worktree を作り、agent の作業ディレクトリと各 provider の sandbox の許可を複数のルートへ広げる（v0.3.0） | todo | high | DEV | 2026-10-01 | _TODO_ | 2026-10-01 | repos を持つ project で <task-id>/project/ と <task-id>/<name>/ の worktree を作り、agent への追加ディレクトリ・環境変数、保護設定と Git 状態の検査、evidence をリポジトリ別に扱うようにした | pjr-98g4-multi-repo-worktree-agent | - |
| PJR-9KST | done | 複数リポジトリの統合を再開すると waiting の記帳が事前検査を妨げる | 統合の途中で失敗して waiting に戻った項目を exec run --resume で再開すると、runner がプロジェクト側に書いた waiting の記帳（個票と event）が、事前検査で merge の対象と重なる未 commit の変更と判定され、統合できない。初回の統合と同じく releasePaths として除外する（v0.3.0） | issue | high | DEV | 2026-10-01 | _TODO_ | 2026-10-02 | 再開経路でも runner の記帳を初回と同じ基準で releasePaths として扱い、trace の文章を result の Markdown 検査に合わせた。2 製品構成の CLI 経路で失敗位置ごとの再開を確かめた | pjr-9kst-multi-repo-resume-precheck-register-records | - |
| PJR-A9NC | done | register add のタイトルに素の山括弧プレースホルダを入れられる | register add / update の --title と --description に、インラインコードで囲まない山括弧プレースホルダを入れると、個票の H1 が lint:fm に反し docs:build も失敗する。入力時に検出してエラーにするか、自動でインラインコードへ囲む | issue | medium | DEV | 2026-10-01 | _TODO_ | 2026-10-02 | register add / update のタイトルと説明で、コードスパン外の山括弧プレースホルダを自動でインラインコードに囲む | pjr-a9nc-register-title-placeholder-check | - |
| PJR-GENJ | done | reporter 段からの再開で develop を取り込む前に親検証を実行する | exec run --resume で reporter 段から再開すると、統合先ブランチの最新を worktree へ取り込む前に親検証を実行する。統合先で直した不具合が反映されず、同じ失敗を繰り返す。親検証の前に取り込むか、取り込み後に検証し直す | issue | medium | DEV | 2026-10-01 | _TODO_ | 2026-10-02 | reporter 段・統合段からの再開で、親検証の前に統合先の最新を worktree へ取り込むようにした | pjr-genj-resume-validation-before-develop-sync | - |
| PJR-HQBK | done | 複数リポジトリの宣言と targets・paths の解決 | specdojo.config.json の project にリポジトリの宣言を加え、task の targets と job の paths をリポジトリ付き（例: app1:src/...）で解決する（v0.3.0） | todo | high | DEV | 2026-10-01 | _TODO_ | 2026-10-01 | specdojo.config.json の project に repos を宣言でき、schema と読み込みで検証する。<repo>:<path> の解決関数を加えた | pjr-hqbk-multi-repo-config-resolution | - |
| PJR-V96B | done | 親検証のリポジトリ別の割り当て | 親検証の ID ごとに実行するリポジトリ（cwd）を宣言し、ソースの test はプロダクト側、文書の lint と schema 検証はプロジェクト側で実行する（v0.3.0） | todo | high | DEV | 2026-10-01 | _TODO_ | 2026-10-01 | parent_validations の要素に { id, repo } を許し、割り当てたリポジトリの worktree で実行して evidence にリポジトリ名を記録するようにした | pjr-v96b-multi-repo-parent-validations | - |
| PJR-6TKA | done | 範囲内の依存の更新と dotenv 18 への更新 | js-yaml の下限を 4.3.2 に上げ、ルート・docs-site・docs-lint で npm audit fix（--force なし）と npm update を行い、dotenv を 18 に上げる（v0.3.0） | todo | high | DEV | 2026-09-30 | _TODO_ | 2026-09-30 | js-yaml を 4.3.2、dotenv を 18 に上げ、範囲内の依存を更新した。ルートの本番依存の脆弱性は 0 件。prettier 3.9 の整形も反映した | pjr-6tka-deps-in-range-update-dotenv18 | - |
| PJR-7GAK | done | docs-lint の依存の脆弱性への対応 | docs-lint に残る high 6 件・moderate 3 件（markdownlint-cli 0.48 経由の markdown-it・smol-toml・js-yaml、remark-lint-frontmatter-schema 経由の json-schema-ref-parser・ajv・minimatch・yaml）を、markdownlint-cli 0.49 への更新と上流の対応状況の確認で解消する（v0.3.0） | todo | high | DEV | 2026-09-30 | _TODO_ | 2026-10-01 | markdownlint-cli を 0.49.1 に上げ、未使用の remark-lint-frontmatter-schema を外した。docs-lint の 9 件のうち 8 件が解消し、js-yaml の moderate 1 件は上流の対応待ち | pjr-7gak-docs-lint-dependency-vulnerabilities | - |
| PJR-CBQV | done | @specdojo/docs-site を npm へ公開する | docs-site は npm に未公開で、docs-editing-guide・移行ガイド・docs-site の README の npm install の手順が失敗する。publish-docs-site.yml を追加した。npm 側の trusted publisher の設定と、staged publishing の承認による初回公開、導入の確認が残る | todo | high | DEV | 2026-09-30 | _TODO_ | 2026-10-14 | @specdojo/docs-site 0.2.1 を trusted publishing で公開し（provenance 付き、latest）、空のリポジトリで README の手順どおりに導入とビルドができることを確かめた | pjr-cbqv-docs-site-npm-publish | - |
| PJR-K1Z5 | done | runner の親検証に lint:ts・lint:fm・lint:md を加える | 親検証の固定許可リスト（ParentValidationId）に lint:ts・lint:fm・lint:md を追加し、exec-defaults の parent_validations で有効にする。agent の段階で lint エラーを検出し、統合後の npm run check まで持ち越さない | todo | medium | DEV | 2026-09-30 | _TODO_ | 2026-10-01 | 親検証の許可リストに lint-ts・lint-fm・lint-md を追加し、exec-defaults で有効にした | pjr-k1z5-parent-validations-lint | - |
| PJR-Q3F0 | deferred | 開発用依存の major 更新 | TypeScript 7、vitest 5、@types/node（Node の下限に合わせ 22 系）、@vscode/vsce 4 への更新と、docs-lint の json-schema-ref-parser の上流対応の確認を行う（リリースと切り離す） | todo | low | DEV | 2026-09-30 | _TODO_ | - | typescript-eslint が TypeScript 7 に未対応（<6.1.0）のため延期する。typescript-eslint が対応したら再開する | pjr-q3f0-dev-dependencies-major-update | - |
| PJR-RCVS | done | js-yaml 5 への移行 | named import への書き換え、引用符なしの日付が文字列になること、既定 schema から merge key が消えることへの対応を行い、js-yaml を 5 に上げる（v0.3.0 の次の版） | todo | medium | DEV | 2026-09-30 | _TODO_ | 2026-10-16 | js-yaml を 5.4.3 へ上げ、import を YAML 1.1 互換の読み込みをするラッパーへ寄せて、引用符なしの日付と merge key の読み込み結果を 4 系と同じにした | pjr-rcvs-js-yaml-5-migration | - |
| PJR-XMMA | done | docs-site の puppeteer 25 と mermaid-cli 12 への更新と Node 下限の引き上げ | high の脆弱性 extract-zip を除くため docs-site の puppeteer を 25、mermaid-cli を 12 に上げ、specdojo・docs-lint・docs-site の engines を Node 22.13 以上にそろえる（v0.3.0） | todo | high | DEV | 2026-09-30 | _TODO_ | 2026-09-30 | docs-site を puppeteer 25 と mermaid-cli 12 に上げ、3 パッケージの Node の下限を 22.13 にそろえた。SVG キャッシュは版と設定の変更で描き直すようにした | pjr-xmma-docs-site-puppeteer25-mermaid12 | - |
| PJR-1JJD | done | register の plan が関連ドキュメントとして参照しただけの文書の grade finding を解消対象に展開する | register 項目の plan（xep-register-template.md の「grade result から展開された finding」）は、src/exec-plans.ts の registerGradeFindingsText が生成する。この関数は、個票の「関連ドキュメント」の章にある wikilink をすべて対象とし、各文書の grade の finding を展開して「viewpoint ID の判定根拠に照らして解消する」と指示する。 | issue | high | DEV | 2026-09-29 | _TODO_ | 2026-09-29 | register の plan が finding を展開する対象を、個票の関連ドキュメントの wikilink から frontmatter の targets に改めた。targets のない個票では展開しない | pjr-1jjd-register-plan-expands-referenced-findings | - |
| PJR-2H5F | done | specdojo devcontainer scaffold で利用リポジトリに devcontainer を生成する | PJR-E8TT（初期リリースで前面に出すものの決定）は、devcontainer を初期リリースから外した。理由は「現行の .devcontainer/ が本リポジトリ専用（ollama、agy、claude、codex、6 個のボリューム、cron）で、配布には設計作業を要する」ためであり、価値を否定したものではない。 | todo | high | DEV | 2026-09-29 | _TODO_ | 2026-10-12 | specdojo devcontainer scaffold で利用リポジトリに devcontainer を生成し、実機で orchestrator の起動を確かめた | pjr-2h5f-devcontainer-scaffold | - |
| PJR-5DM3 | done | gl-rulebook を rulebook-authoring-standard に準拠させる | PJR-QD81（用語集 gl-common の作成）の検討事項「作業の分割」で、gl-rulebook の是正を QD81 に含めるか別項目に分けるかを判断することになっていた。利用者は、推奨どおり別項目に分けると判断した（2026-09-29）。 | todo | medium | DEV | 2026-09-29 | _TODO_ | 2026-09-29 | gl-rulebook.md を rulebook-authoring-standard に準拠させた | pjr-5dm3-gl-rulebook-conformance | - |
| PJR-5PTX | done | v0.3.0 のリリースノートと移行ガイドを作成し版を 0.3.0 に上げる | v0.2.1 から develop までに 424 commit があり、登録簿の項目で 63 件が関係する。その中に、利用者の設定や記録に影響する破壊的変更がある。WPWB と K351 では「package.json の版はリリースのときに判断する」として据え置いた。 | todo | high | DEV | 2026-09-29 | _TODO_ | 2026-09-29 | CHANGELOG.md（package に同梱）と v0.3.0 の移行ガイドを作成し、README から辿れるようにした。specdojo を 0.3.0、@specdojo/docs-site を 0.2.0 に上げた。npm run check と docs:build（98 秒）の成功を確認。main への PR・merge・公開は人の作業 | pjr-5ptx-release-v0-3-0-notes-migration | - |
| PJR-9XG4 | done | register の記帳コマンドに統合と記帳の枠を取って commit するオプションを加える | exec run は、メインの作業ツリーで register の遷移の記帳と統合の merge を行う。PJR-4HBG で、これらを別プロセスの run の間でも直列化する枠（exec slots の register lifecycle）を導入した。 | todo | medium | DEV | 2026-09-29 | _TODO_ | 2026-09-29 | register の記帳コマンドに --commit を加え、register lifecycle の枠を取って記帳・register build・commit を行うようにした。run と並行した記帳の統合テストを追加した。オーケストレーター定義への取り込みは未実施 | pjr-9xg4-register-commit-under-lifecycle-lock | - |
| PJR-A4PY | done | 9XG4・2H5F・0FK2 の変更を利用者向けドキュメントへ反映する | PJR-F346 と PJR-G8TB に続き、2026-09-29 に入れた次の 3 つの機能を、利用者向けのドキュメントへ揃える。 | todo | medium | DEV | 2026-09-29 | _TODO_ | 2026-09-29 | 9XG4・2H5F・0FK2 の 3 機能について README・ガイド 5 本・コマンドリファレンスを実装に合わせて更新した | pjr-a4py-docs-sync-9xg4-2h5f-0fk2 | - |
| PJR-AVSR | done | grade の reporter が finding の severity と level の矛盾で形式の検査に落ちる | grade の reporter の出力を grade apply が検証するとき、finding の severity に応じて level の上限を課している（src/grade.ts の finding severity caps level at <n>）。reporter が、minor 以上の finding を残したまま観点の level を上限より高く付けると、この検証で失敗し、その文書の評価が未完了になる。 | issue | medium | DEV | 2026-09-29 | _TODO_ | 2026-09-29 | grade の reporter の plan に severity ごとの level の上限を明示し、apply の検証で失敗したときに 1 回だけ出し直させるようにした | pjr-avsr-grade-reporter-level-severity-mismatch | - |
| PJR-C44H | done | plan の frontmatter の name に個票の H1 のエスケープが残り YAML が不正になる | register 項目の plan の frontmatter の name は、src/exec-register.ts で次のように生成している。 | issue | medium | DEV | 2026-09-29 | _TODO_ | 2026-09-30 | plan・result・job の frontmatter の name を JSON.stringify で出力し、H1 のエスケープが残らず YAML として正しくなった | pjr-c44h-plan-frontmatter-name-yaml-escape | - |
| PJR-C915 | deferred | exec run --resume で executor の成果を残したまま plan を作り直せるようにする | exec run --register ... --worktree --resume は、止まった段（executor / reporter / 統合）から再開する。このとき、plan は最初の実行で生成したものをそのまま使う。 | todo | medium | DEV | 2026-09-29 | _TODO_ | - | v0.3.0 には入れず次の版で再開する。再開時は agy・claude の 2 回の失敗（RunOpts に replan がない、RegisterResumeTarget に evidence・initialChanges がない型エラーと統合テストの失敗、範囲外の Job 実行記録の変更）を完了条件に加えてから実行する | pjr-c915-exec-resume-replan | - |
| PJR-CF15 | done | 用語集の relatedTerms と category が用語集内の ID を指すことを検証する | PJR-Y06Y で用語集の schema（docs/specdojo/schemas/v1/gl.schema.yaml）を作り、gl-sample.yaml と gl-common.yaml を validate:schema で検証できるようにした。ただし、次の参照は schema では表せず、未検証のままである。 | todo | low | DEV | 2026-09-29 | _TODO_ | 2026-09-30 | docs-lint に glossary-references を追加し、用語集の category・relatedTerms の参照先と用語 ID の重複を検証する。validate:schema に組み込んだ | pjr-cf15-glossary-term-reference-check | - |
| PJR-G8TB | done | 4HBG・36CN・E2Q3 の変更を利用者向けドキュメントへ反映する | PJR-F346 で 2026-09-26〜28 の変更を利用者向けドキュメントへ反映したが、着手時点で未完了だった次の 3 件は対象外とした。各項目の executor が関係するガイドとリファレンスの一部を更新しているが、概要・入門のガイドなど横断的な文書への反映は確認していない。 | todo | medium | DEV | 2026-09-29 | _TODO_ | 2026-09-29 | 4HBG・36CN・E2Q3 の変更を Quick Start ガイド・登録簿運用ガイド・レビューガイドへ反映した | pjr-g8tb-docs-sync-4hbg-36cn-e2q3 | - |
| PJR-GRB5 | done | 利用上限で止まった直後に保護の検査が再生成可能な生成物を誤検知する | 2026-09-28 の PJR-36CN の実行で、claude-expert-executor が You've hit your session limit · resets 11:10pm (Asia/Tokyo) で止まった直後に、agent-config-write: protected configuration changes detected; paths=.specdojo/doc-index.json で blocked になった。 | issue | medium | DEV | 2026-09-29 | _TODO_ | 2026-09-29 | git check-ignore が判定不能なときに除外する生成物を .specdojo/doc-index.json に限り、36CN の誤検知を解消した。利用上限で止まった実行も保護の検査を行い、止まった理由の先頭に利用上限を記録する | pjr-grb5-protected-config-false-positive-after-limit | - |
| PJR-GWYJ | done | 残りの rulebook のサンプル章を sample へ外出しする（AY1R 第 2 段） | PJR-AY1R の第 2 段である。第 1 段で、fully-guided の plan が sample を参照できるようにし（recipe-guided は対象外）、bps-rulebook と stsd-rulebook のサンプル章を外出しして試行した。本項目では、残りの rulebook のサンプル章を sample へ外出しする。 | todo | medium | DEV | 2026-09-29 | _TODO_ | 2026-09-30 | 54 件の rulebook のサンプル章を外出しし、sample を持たなかった tml・ifx-index は sample を新設した。sample の網羅の確認と grade による比較は PJR-B7DG へ切り出した | pjr-gwyj-rulebook-sample-chapter-extraction-phase2 | - |
| PJR-M8NA | done | executor の sandbox で docs:build が tsx の IPC で EPERM になる | npm run docs:build は、docs:generate（tsx src/specdojo.ts build）を実行してから docs サイトをビルドする。codex の executor の sandbox では、tsx が IPC ソケットを作れず EPERM で止まる。 | issue | medium | DEV | 2026-09-29 | _TODO_ | 2026-09-29 | docs:generate を node --import tsx src/specdojo.ts build に改め、tsx の CLI の IPC を使わないようにした。共通規約にも回避方法を追記した。開発環境の docs:build は成功（151 秒）。sandbox での成功は次に codex で docs:build を実行したときに確認する | pjr-m8na-sandbox-docs-build-tsx-eperm | - |
| PJR-NJRH | done | オーケストレーター定義の記帳手順で register の --commit を使う | PJR-9XG4 で、register add / close / reject / defer / update / reopen などの記帳コマンドに --commit が入った。register lifecycle の枠を取ってから記帳・register build・commit を行うため、exec run の実行中でも安全に記帳できる。 | todo | medium | DEV | 2026-09-29 | _TODO_ | 2026-09-29 | オーケストレーター定義の記帳手順を register の --commit を使う形に改め、各環境へ同期した | pjr-njrh-orchestrator-use-register-commit | - |
| PJR-T2M6 | done | register close・reject・defer で note を拒否する | PJR-GDQC の回答（候補 A）を実装する。pjr-rulebook は note を終端させず open のまま追記すると定めているが、register close / reject / defer は type を区別しておらず（src/register-item.ts に note 固有の扱いがない）、note も終端させられる。 | todo | medium | DEV | 2026-09-29 | _TODO_ | 2026-09-29 | register close・reject・defer が type note の項目を拒否し、別 type の起票を案内する。範囲外だった template_dispatch などの変更は orchestrator が取り除いた | pjr-t2m6-register-reject-note-terminal | - |
| PJR-Y06Y | done | 用語集（gl-*.yaml）の schema を作成する | 用語集（gl-*.yaml）には schema がない。docs/ja/specdojo/samples/gl-sample.yaml は先頭に # specdojo-schema: none reason=schema-not-defined を置いて validate:schema の対象から外している。2026-09-29 に PJR-QD81 で作成した docs/ja/product/010-business-specs/060-glossary/gl-common.yaml も、validate-schema の失敗を受けて同じ指定を付けた。 | todo | medium | DEV | 2026-09-29 | _TODO_ | 2026-09-29 | gl.schema.yaml を作成し、gl-sample.yaml と gl-common.yaml を schema で検証する形に改めた。用語 ID の参照の検証は別項目へ切り出した | pjr-y06y-glossary-schema | - |
| PJR-36CN | done | 統合時の記帳競合でイベントを和集合で合わせる | PJR-CTV4 で、統合 merge の競合が項目自身の記帳ファイル（個票・イベント・plan・result・登録簿）だけに収まる場合は、exec branch 側の内容で解決して統合を完了するようにした（resolveConflictsWithBranchPaths）。 | todo | medium | DEV | 2026-09-28 | _TODO_ | 2026-09-29 | 統合時にイベントファイルが競合した場合、両側のイベントを和集合（同一 id は 1 件、時刻順）で解決する register-event-merge を追加した。waiting 中に統合先で追記されたイベントが統合後も残ることを統合テストで確認した | pjr-36cn-integrate-bookkeeping-event-union | - |
| PJR-BVPS | done | 旧 rubric の grade 結果を選ぶ条件を追加し夜間に少しずつ評価し直す | PJR-K351 で、grade の rubric を grade-rubric-v2（9 category、pass_score 75）に改め、対象の観点を 28 に広げた（定義は docs/ja/specdojo/defaults/pm-review-viewpoints.yaml）。既存の grade 結果は旧 rubric（v1、4 category、8〜12 観点）で付けたもので、点数を v2 と比べられない。 | todo | medium | DEV | 2026-09-28 | _TODO_ | 2026-09-28 | grade list と run-per-document.sh に --rubric-outdated を追加し、Job 定義と両 routine で有効にした。変更時点の旧 rubric の結果は kata 232 件、成果物 19 件で、夜間に limit の範囲で評価し直す | pjr-bvps-grade-rubric-outdated-selector | - |
| PJR-CTV4 | done | waiting を複数回経た項目の再開時の統合で記帳ファイルが競合し merge が途中で残る | PJR-N22N は、次の経過で 3 回 waiting を経た。 | issue | high | DEV | 2026-09-28 | _TODO_ | 2026-09-28 | 統合 merge の競合が項目自身の記帳ファイルだけの場合は exec branch 側で解決して完了し、それ以外は中止する。merge --abort の前に index を更新する。waiting を 2 回経た再開の統合を含む 3 件の統合テストを追加した | pjr-ctv4-resume-integrate-bookkeeping-conflict | - |
| PJR-E2Q3 | done | exec run --plan で review を executor と reporter の構成で実行できるようにする | PJR-KCMH の完了条件（review を agent で 1 件実行し、plan と result を確かめる）のため、2026-09-28 に orchestrator が次を実行した。 | todo | medium | DEV | 2026-09-28 | _TODO_ | 2026-09-29 | exec run --plan と --deliverable で --executor-by / --reporter-by を指定すると executor/reporter の 2 段で実行するようにし、--by に pipeline 用の agent を指定した場合は実行前に案内のエラーにした。review を 1 件実行し、reporter が新しい書式で result を記入することを確認した | pjr-e2q3-exec-plan-review-agent-pipeline | - |
| PJR-F346 | done | 2026-09-26〜28 の変更を利用者向けドキュメントへ反映する | 2026-09-26〜28 に多くの項目を close した。各項目の executor は関係するガイドを部分的に更新したが、項目をまたいだ整合や、概要・入門のガイドへの反映は確認していない。利用者向けのドキュメントが実装と食い違っていないかを横断的に確認し、古い記述を直す。 | todo | medium | DEV | 2026-09-28 | _TODO_ | 2026-09-28 | 9/26〜28 に完了した変更について guides・references・README を横断確認し、11 文書を更新した（grade と review の役割分担、rubric v2 と --rubric-outdated、docs サイト、orchestrator 同期など）。旧語彙は移行説明と別義の用例だけが残る。4HBG・36CN・E2Q3 は着手時点で未完了のため対象外 | pjr-f346-docs-sync-recent-changes | - |
| PJR-2F3Y | done | grade の unreviewed 契機を内容の変化がある文書に絞る | PJR-N03W で追加した grade list --unreviewed（src/grade.ts）は、schedule のタスクが割り当てられていない文書を選ぶ。ただし、評価結果の有無や content_hash の一致を見ないため、評価済みで内容が変わっていない文書も毎回すべて選ぶ。 | todo | high | DEV | 2026-09-27 | _TODO_ | 2026-09-27 | grade list --unreviewed を未評価または content_hash 不一致の文書に絞り、routine の unreviewed を有効に戻した。対象は kata 262→0 件、成果物 19→1 件 | pjr-2f3y-grade-unreviewed-content-hash | - |
| PJR-3HHW | done | 並行実行中の runner 検証を同時に走らせないようにする | exec run --register ... --worktree --parallel <n> では、executor の終了後に各項目の worktree で runner の検証（pipeline.parent_validations の test-integration、executor が実行する test-unit など）が走る。複数項目の executor がほぼ同時に終わると、検証も同時に走る。vitest はそれぞれが複数の worker を起動するため、コンテナ（16 コア、メモリ 11GB）の負荷が高まり、テストが時間切れで失敗する。 | todo | high | DEV | 2026-09-27 | _TODO_ | 2026-09-27 | ParentValidationGate で 1 回の exec run 内の親検証を既定 1 本に直列化し、pipeline.parent_validation_concurrency で同時数を設定できるようにした。executor と reporter は並列のまま。別プロセスは exec-run.lock に委ね対象外とし、ガイドへ記載 | pjr-3hhw-serialize-parent-validations | - |
| PJR-5RS9 | done | bps-task-review-finalize の local_id を中身に合わせ cdfd-overview の不整合を直す | 夜間作業の評価で、次の 2 つの不整合を確認した。 | todo | medium | DEV | 2026-09-27 | _TODO_ | 2026-09-27 | local_id を bps-task-verification へ改め参照元3件を追随、cdfd-overview の Check への要求を評価・報告・生成要求にし、Plan/Do/Check/Action から Orchestrator への応答4本を cdfd-orchestrator と一致させた | pjr-5rs9-bps-review-finalize-and-cdfd-overview | - |
| PJR-7ZNH | done | schedule build が track と milestones の schema modeline を消さないようにする | schedule build は sch-track-<track>.yaml と sch-milestones.yaml を、yaml.dump の結果だけで書き出していた。先頭の # yaml-language-server: $schema=... modeline が再生成のたびに消えるため、validate:schema が missing yaml-language-server $schema modeline で失敗する。 | todo | high | DEV | 2026-09-27 | _TODO_ | 2026-09-27 | schedule build の track と milestones の書き出しへ schema modeline を付けるようにした | pjr-7znh-schedule-build-keep-schema-modeline | - |
| PJR-E8FY | done | docs:build のサイドバーから実行記録を外しパスごとに分割する | npm run docs:build が既定ヒープでメモリ不足になる。NODE_OPTIONS=--max-old-space-size=8192 では通るが、193 秒かかる。 | todo | medium | DEV | 2026-09-27 | _TODO_ | 2026-09-27 | サイドバーから実行記録を外しパス別に分割、metaChunk でサイト設定を切り出した。既定ヒープで docs:build が成功し dist は 2.9GB→568MB、代表ページは 1.4MB→120KB。実行記録は exec-records.md から辿れる | pjr-e8fy-docs-build-sidebar-scope | - |
| PJR-FFPK | done | agent の一時ファイルが register 実行の commit に入り統合前の検査も誤って止める | agy-expert-executor は、成果物の編集にリポジトリ直下の作業用スクリプトを使い、終了後も残す。2026-09-27 の実行で観測した事例は次のとおり。 | todo | high | DEV | 2026-09-27 | _TODO_ | 2026-09-27 | register 由来タスクの commit 範囲を、HEAD に無い新規ファイルは成果物ディレクトリと targets に限るよう絞り、除外した変更は commit-scope 警告と integrate.log に残す。ready 昇格検査は commit 対象だけを見る。共通規約に一時ファイルの置き場所と削除を追記した | pjr-ffpk-agent-scratch-files-in-commit | - |
| PJR-GDQC | decided | register close で note の終端を拒否するかを決める | register close などの終端操作で、type が note の項目を拒否するか。 | question | low | DEV | 2026-09-27 | _TODO_ | 2026-09-29 | 候補 A。register close / reject / defer は note を拒否し、別の type での起票を案内する。実装は PJR-T2M6 | pjr-gdqc-register-close-reject-note | - |
| 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-HG98 | done | config init で生成物を除外する .gitignore を作り register の並行実行の衝突を防ぐ | config init は利用者のリポジトリに、生成物を git の管理から外す .gitignore を作らない。README の手順どおりに始めると登録簿の生成物（generated/pjr-index.md など）が git で管理され、**register を並行実行すると、統合の段で生成物が add/add で衝突する。** config init で .gitignore を用意する。 | todo | high | DEV | 2026-09-27 | _TODO_ | 2026-09-27 | config init が設定から導いた生成物の除外パターンを .gitignore へ冪等に追記し、管理済み生成物を外す手順を案内する。並行実行の統合テストは config init を使う形にした。README と参照文書へ記載 | pjr-hg98-config-init-gitignore-generated | - |
| PJR-QJAD | done | grade が未完了の文書を残して終わった場合に終了コード 1 を返す | tools/grade/run-per-document.sh は、処理の最後に grade pipeline complete: ... incomplete=<n> ... を出力し、そのあと incomplete の件数に関係なく終了コード 0 で終わる。 | todo | medium | DEV | 2026-09-27 | _TODO_ | 2026-09-27 | run-per-document.sh は走りきって incomplete が残ると未完了文書と再開方法を stderr へ出し exit 1 で終わる。routine では Job 失敗として記録される | pjr-qjad-grade-incomplete-exit-code | - |
| PJR-QQXP | done | VitePress のローカル検索から不要な文書を外して高速化する | サイト（VitePress）の検索が遅い。ローカル検索は、ビルド時に作ったインデックスを検索を開いたときにブラウザが読み込んで展開する方式である。2026-09-26 のビルドで、ja のインデックス（@localSearchIndexja.*.js）は 9,783,822 byte、9,133 セクションあった。 | todo | medium | DEV | 2026-09-27 | _TODO_ | 2026-09-27 | renderSearchHtml へパスパターンの除外を加え、登録簿は pjr-index だけを検索対象に残した。ja 検索インデックスは 9,783,822→5,927,919 byte、9,133→5,621 セクション | pjr-qqxp-docs-search-index-scope | - |
| PJR-R0XA | done | waiting からの再開前の develop 取り込みが統合時に他項目の成果を消す | waiting になった register 項目では、runner の syncExecBranchAfterWait（src/exec-run.ts）が、統合先ブランチを exec branch へ -s ours で merge する（commit メッセージは record <branch> wait ancestry）。 | issue | high | DEV | 2026-09-27 | _TODO_ | 2026-09-27 | syncExecBranchAfterWait の -s ours を通常 merge に改め、記帳ファイルの競合だけ統合先側で解決し、それ以外の競合は中断して worktree を保持する。ブランチ作成後に統合先へ入った成果が再開・統合後も残ることを統合テストで確認した | pjr-r0xa-wait-ancestry-ours-merge-reverts | - |
| PJR-VJP8 | done | 観点の document_kinds で判断漏れの rulebook を検出する検証を追加する | PJR-H220 の決定（選択肢 B）を実装する。 | todo | medium | DEV | 2026-09-27 | _TODO_ | 2026-09-27 | document_kinds に confirmed_default を追加し、観点ごとに判断漏れ・存在しない ID・重複を error で報告する検証を npm test（npm run check に含まれる）で実行する。既存 107 件の判断を適用結果を変えずに記録し、作成手順とガイドへ記載した | pjr-vjp8-viewpoint-document-kinds-coverage-check | - |
| PJR-XW9M | done | オーケストレーター定義の種別表で note を終端しない記録に直す | オーケストレーター定義の「登録簿（register）の使い方」にある type の表は、note の終端状態を done としている。一方、pjr-rulebook.md の type 別の扱い（157〜166 行）は、note を終端させず open のまま新しい事実・知見を追記し、done / decided / rejected / deferred へ遷移させないと定めている。register-operation-guide.md も「note は終端させない」としている。 | todo | medium | DEV | 2026-09-27 | _TODO_ | 2026-09-28 | SSOT（.agents/specdojo-orchestrator.agent.md）の種別表で note の終端を「なし」に改め、close 手順の後に note を終端させない旨を追記し、orchestrator:sync で 10 か所へ同期した | pjr-xw9m-orchestrator-note-type-non-terminal | - |
| PJR-1Y9P | done | resume 後の executor が plan の未完了作業を引き継がず成功扱いになる | rate limit で中断した executor 段を --resume で再開したとき、再開後の executor が plan の未完了作業を引き継がず、着手済みの一部だけで succeeded を返した。pipeline は成功扱いとなり、register は review へ遷移して統合まで進んだ。**完了していない作業が完了として記録される。** | todo | high | DEV | 2026-09-26 | _TODO_ | 2026-09-26 | - | pjr-1y9p-resume-executor-plan | - |
| PJR-4HBG | done | 実行中の exec run へ後から項目を追加して並行実行できるようにする | exec run は project 単位の実行ロックを run 全体で保持するため、実行中に別の項目を並行で走らせられない。並行実行は --parallel で起動時にまとめて指定する場合にしか使えず、**後から項目を追加できない**。実際に PJR-T3NN の実行中に PJR-00QV を並行させたい場面が発生し、--if-busy wait で順次実行するしかなかった。 | todo | medium | DEV | 2026-09-26 | _TODO_ | 2026-09-28 | 案 C を実装した。--join を付けた exec run --register --worktree は実行中の run に合流して並行開始でき、上限は run.max_concurrent_runs。provider の同時実行数・root での遷移と統合・親検証をプロセスを跨いで枠で直列化し、exec slots で使用状況を確認できる | pjr-4hbg-exec-run | - |
| PJR-9PZ7 | done | grade の打ち切りが検出されず終了コード 0 で完了扱いになる | tools/grade/run-per-document.sh が対象の一部だけを処理して終了しても、終了コード 0 を返す。利用者は完了したと誤認する。実際に 5 文書を指定した実行が 2 文書で打ち切られ、終了コード 0 になった。 | todo | high | DEV | 2026-09-26 | _TODO_ | 2026-09-26 | - | pjr-9pz7-grade-0 | - |
| PJR-K332 | done | register の並行実行で項目ごとに executor を指定できるようにする | exec run --register A B C --worktree --parallel 3 は項目を並行で走らせるが、--executor-by は全項目で 1 つしか指定できない。複数の provider に作業を分散できず、**rate limit が 1 つの provider に集中する。** 項目ごとに executor を指定できるようにする。 | todo | medium | DEV | 2026-09-26 | _TODO_ | 2026-09-27 | - | pjr-k332-per-item-executor-assignment | - |
| PJR-PPYF | done | targets を宣言しない register 項目でも 1 回目の変更集合を下限として網羅を検証する | prj-0001:pjr-6wfa-register-plan-targets で、個票が targets を宣言すれば register 由来の plan でも網羅の検証が働くようにした。**宣言しない個票は、引き続き検証されない。** 1 回目の実行で変更されたファイルを下限として記録し、resume のときに「少なくともこれらは確認せよ」と使えるようにする。 | todo | medium | DEV | 2026-09-26 | _TODO_ | 2026-09-27 | - | pjr-ppyf-register-targets-from-first-attempt | - |
| PJR-RPSX | done | config scaffold で provider に応じたオーケストレーター起動スクリプトを package.json へ加える | オーケストレーターの起動は provider ごとにコマンドが長い（codex "$(cat .specdojo/codex/orchestrator.md)" など）。このリポジトリの package.json には orch:opus などの起動スクリプトがあるが、SpecDojo を導入した人の package.json には何も加わらない。config scaffold --provider のときに、provider に応じた起動スクリプトを加える。 | todo | medium | DEV | 2026-09-26 | _TODO_ | 2026-09-26 | - | pjr-rpsx-scaffold-orchestrator-npm-scripts | - |
| PJR-TDB0 | done | task 経路の resume で rate limit 後の executor が再起動しない | exec resume --task <id> で rate limit 後の executor が再起動しない。再開条件 canResumeBlockedPipeline は executor を含むが、rate limit 後のタスク状態または pipeline_state_ref の meta 書き込みが条件を満たしていない。prj-0001:pjr-1y9p-resume-executor-plan の統合テスト 1 件を it.skip として残しており、本項目で解明する。 | todo | medium | DEV | 2026-09-26 | _TODO_ | 2026-09-26 | - | pjr-tdb0-task-resume-rate-limit-executor | - |
| PJR-8MYJ | done | 常時稼働の母艦へリモート接続して agent を動かす構成例のガイドを書く | SpecDojo は自律実行を前提とする。routine は cron で定期実行され、exec run は 1 回あたり 10〜30 分かかる。ノート PC を閉じると止まるため、**常時稼働する実行環境が要る**。 | todo | medium | DEV | 2026-09-24 | 2026-10-24 | 2026-09-24 | 常時稼働ホストへリモート接続する構成例のガイドを新設した。役割と代替手段で一般化し、構成例として位置づけ、採らない選択も明示した。 | pjr-8myj-remote-host-development-guide | - |
| PJR-BX79 | done | 統合段の dubious ownership を 1 回だけ再試行する | 統合段の git コマンドが次で失敗する事象が 2 回発生した。 | todo | medium | DEV | 2026-09-24 | 2026-10-17 | 2026-09-26 | - | pjr-bx79-integrate-dubious-ownership-retry | - |
| PJR-NFV7 | done | result の末尾改行を runner 側で正規化する | 2026-09-23 夜間の grade routine が生成した result のうち 2 件に末尾改行が無く、npm run lint:md が MD047（Files should end with a single newline character）で失敗した。 | todo | low | DEV | 2026-09-24 | 2026-10-24 | 2026-09-24 | plan と result の書き出し共通経路へ末尾改行の正規化を入れた。冪等で、Prettier 対象外のファイルも通る。 | pjr-nfv7-result-trailing-newline | - |
| PJR-XTAN | done | 判定語彙を判定対象ごとに整理し 同じ対象の語彙だけを統一する | 判定に使う語彙が 4 種類ある。当初は prj-0001:pjr-2zvs-grade-review-integration の決定 3.3 に従い、すべてを verdict_definitions へ統一する予定だった。しかし同項目の最終結論で、**grade と review は違う対象を判定する**ことが分かった。違う対象を同じ語彙にすると、かえって混同を招く。4 語彙を判定の対象で分け、**同じ対象を判定している語彙だけを統一する**。 | todo | high | DEV | 2026-09-24 | 2026-10-31 | 2026-09-28 | review 側の完了可否の語彙を 6 値（complete / complete-with-findings / incomplete / grade-stale / grade-unavailable / changed-during-review）へ統一し、REVIEW_VERDICTS を正本とした。grade の語彙と level からの写像は残し、旧値は移行先を示すエラーで拒否する | pjr-xtan-unify-verdict-vocabulary | - |
| PJR-YSDV | done | README 冒頭を PJR-E8TT の差別化軸へ揃える | prj-0001:pjr-e8tt-initial-release-positioning で初期リリースの差別化軸を決めたが、README 冒頭は旧来の説明のままである。 | todo | high | DEV | 2026-09-24 | 2026-10-03 | 2026-09-24 | README 冒頭を PJR-E8TT の 3 つの主張へ揃え、register から始めて必要な分だけ広げる順序へ組み替えた。 | pjr-ysdv-readme-positioning-intro | - |
| PJR-03M3 | done | git-branching-standard に 3 層の切り分けと運用規模別の条件を明記する | prj-0001:pjr-ewwx-feature-branch-policy で、develop へ入る経路を 3 層に分けることを決めた。specdojo:git-branching-standard は feature/<project-id>/<topic> を必須ブランチとして定義しているが、「どの変更を feature に載せ、どの変更を develop へ直接 commit してよいか」を規定していない。単独運用ではその区別が不要だったため、標準と実運用が乖離している。 | todo | medium | DEV | 2026-09-23 | 2026-10-10 | 2026-09-23 | git-branching-standard へ 3 層の変更経路と運用規模ごとの必須条件を新設し、branch-workflow-guide へ feature 分岐前の base push と PR 表示再計算の対処を追加した。 | pjr-03m3-branch-standard-three-layers | - |
| PJR-09KK | done | npm 導入から exec までの導線を README と quick-start へ反映する | prj-0001:pjr-fkn1-kata-distribution-method の第 4 段階。npm 公開後の利用者が、npm install specdojo から Detached Unit を立ち上げて exec まで到達できる導線を文書へ反映する。 | todo | high | DEV | 2026-09-23 | 2026-10-31 | 2026-09-23 | README と quick-start-guide を npm 導入で完結する導線へ改め、設定キーの reference を新設した。config init の Next steps と catalog scaffold のエラーから参照先へ辿れる。 | pjr-09kk-npm-onboarding-path | - |
| PJR-49JK | done | README の onboarding を orchestrator 経由の導線へ書き換える | README は npx specdojo を直接叩く手順を案内している。SpecDojo の想定する使い方は対話型オーケストレーターへ会話で指示することなので、導線を組み替える。 | todo | high | DEV | 2026-09-23 | 2026-10-17 | 2026-09-24 | README の onboarding を orchestrator 経由の導線へ改め、provider ごとの配置と起動、会話での操作例を示した。CLI の直接利用は選択肢として残した。 | pjr-49jk-readme-orchestrator-onboarding | - |
| PJR-8XQZ | done | orchestrator を config scaffold で配布し SSOT の記述を実態へ合わせる | npm 導入した利用者が対話型オーケストレーターを入手できない。 | todo | high | DEV | 2026-09-23 | 2026-10-10 | 2026-09-23 | SSOT から生成する方式へ変え、claude / codex / opencode / antigravity へ配布原本を追加した。規範の記述を npx specdojo 前提へ改め、導入直後の進め方・登録簿の使い方・kata の扱いを追加した。 | pjr-8xqz-orchestrator-distribution-and-ssot | - |
| PJR-AAK1 | done | kata サブコマンド（list / show / status / eject / install）を追加する | prj-0001:pjr-fkn1-kata-distribution-method の第 2 段階。prj-0001:pjr-ypns-kata-resolution で解決順序が入った後、利用者が「今どの kata を参照しているか」「何を上書きしたか」を確認し、必要なものを取得できるようにする。 | todo | high | DEV | 2026-09-23 | 2026-10-24 | 2026-09-23 | kata list / show / status / eject / install を追加した。参照固定の exec-template と schema は eject を拒否して理由を表示し、--all で一覧から辿れるようにした。 | pjr-aak1-kata-subcommands | - |
| PJR-G8M9 | done | eject されていない kata の wikilink と index build の解決方針を決めて実装する | prj-0001:pjr-fkn1-kata-distribution-method の第 3 段階。kata を node_modules から参照する構成では、利用者の成果物に書かれた [[specdojo:xxx-rulebook]] の実体がリポジトリ外になる。index build は docs/ 配下を走査して ID インデックスを作るため、eject されていない kata の ID が未解決になる。 | todo | medium | DEV | 2026-09-23 | 2026-10-31 | 2026-09-23 | index build が resolver 由来の package kata も走査し、利用リポジトリと package をスコープで分けて重複判定するようにした。eject 後も index build が成功する。 | pjr-g8m9-kata-wikilink-resolution | - |
| PJR-KCMH | done | review フェーズで grade を実行し結果を plan へ提示する | prj-0001:pjr-2zvs-grade-review-integration の決定のうち review 経路を実装する。review フェーズの前段で runner が対象文書へ grade を実行し、その結果を review plan へ提示する。content_hash が既存 sidecar と一致する場合は再実行しない。 | todo | high | DEV | 2026-09-23 | 2026-11-07 | 2026-09-28 | review の前に runner が grade の鮮度を確認し、content_hash が一致すれば既存の結果を使い、plan の評価結果章へ確定済みの事実として提示する。review-guide を観点別評価しない形に改めた。試行で plan と判断は意図どおりと確認し、result の記入経路は PJR-E2Q3 へ引き継ぐ。N03W の経過措置は理由を記録して残す | pjr-kcmh-review-grade-verdict | - |
| PJR-KEFK | done | オーケストレーター規範に feature ブランチ経由の commit 方針を反映する | prj-0001:pjr-ewwx-feature-branch-policy で、develop へ入る経路を exec ブランチ / feature ブランチ / 記帳の直接 commit の 3 層に分けることを決めた。オーケストレーター規範の現行記述は commit の承認方針しか定めておらず、どのブランチで commit するかを指示していない。このままではオーケストレーターは develop へ commit し続ける。 | todo | high | DEV | 2026-09-23 | 2026-09-30 | 2026-09-23 | オーケストレーター規範へ commit 先ブランチの選び方を追記し、SSOT と 5 環境のラッパーを同期した。feature ブランチ経由の PR #6 で統合した。 | pjr-kefk-orchestrator-feature-branch-rule | - |
| PJR-MWWP | done | dashboard の表セルへ埋める理由を整形し、表が壊れないようにする | dashboard の 要対応（解除待ち） は、register の block_reason や exec の block 理由をそのまま表セルへ埋める。理由は agent や git の出力から作られるため、制御文字・パイプ・長文が混ざりうる。 | todo | medium | DEV | 2026-09-23 | 2026-10-10 | 2026-09-24 | dashboard の表セルへ埋める値を sanitizeDashboardCell で整形するようにした。制御文字の除去、パイプのエスケープ、200 文字での打ち切りを行い、event 由来の値が入る全セルへ適用した。 | pjr-mwwp-dashboard-cell-sanitize | - |
| PJR-N03W | done | grade の定期実行を変化検知に限定する | prj-0001:pjr-2zvs-grade-review-integration の決定のうち、定期実行の契機を実装する。依存先の content_hash 変化、kata 更新後の遡及確認、review 経路を持たない文書の 3 契機に限定し、全件の時間契機実行をやめる。 | todo | high | DEV | 2026-09-23 | 2026-11-14 | 2026-09-27 | grade の定期実行に dependency_changed・rulebook_changed・unreviewed の 3 契機を加え、KCMH 完了まで changed_only・ungraded・incomplete を経過措置として残した。unreviewed は内容の変化を見ないため routine では無効にし、修正を PJR-2F3Y へ分けた | pjr-n03w-grade-role-and-triggers | - |
| PJR-R1N2 | done | CLI の --version を package.json から読み、ハードコードをやめる | prj-0001:pjr-7vkr-npm-release の 0.2.0 公開後、npm 経由で導入した環境で確認したところ、CLI が報告する版とインストールされている版が食い違った。 | todo | high | DEV | 2026-09-23 | 2026-09-30 | 2026-09-23 | CLI の version を package.json から読むようにし、直書きを廃止した。npm version の更新へ自動で追従する。 | pjr-r1n2-cli-version-from-package-json | - |
| PJR-SJ3X | done | docs-site のビルド前に package の kata をステージングしてサイトへ含める | prj-0001:pjr-fkn1-kata-distribution-method で kata を package 参照既定としたため、eject していない kata は利用リポジトリの docs/ 配下に存在しない。@specdojo/docs-site は srcDir を呼び出し元 workspace に固定しているため、参照中の kata はサイトに含まれず、成果物から辿る [[specdojo:xxx-rulebook]] のリンクが 404 になる。 | todo | medium | DEV | 2026-09-23 | 2026-11-21 | 2026-09-27 | docs-site の設定読み込み時に package 同梱の docs/ja/specdojo を specdojo-kata-staging/ へ複製し、eject 済みを優先して /ja/specdojo/ で配信する。kata を持たない一時 workspace でビルドと wikilink 解決を確認した | pjr-sj3x-docs-site-kata-staging | - |
| PJR-T84C | done | 保護対象のうち agent 実行時に生成されるディレクトリを除外する | prj-0001:pjr-2t2s-antigravity-provider の作業 9 で、agent が自分の指示を書き換えられないよう .agents/rules、.agents/skills、.claude、.codex、.opencode、.github/agents、AGENTS.md、CLAUDE.md、GEMINI.md を保護対象へ加えた。ディレクトリ単位で指定したため、agent が実行時に生成するファイルまで検知対象になっている。 | todo | high | DEV | 2026-09-23 | 2026-09-26 | 2026-09-23 | agent の実行時生成物を、既知の生成物かつ ignore 済みという二条件で保護検知から除外した。指示ファイルの保護は維持し、PJR-03M3 の再開で reporter の完走を確認した。 | pjr-t84c-protected-config-runtime-artifacts | - |
| PJR-TR8G | done | git コマンド失敗の理由から進捗表示を除き、原因行を block reason へ残す | PJR-G8M9 の worktree 作成が失敗した際、block_reason が次のようになり原因を特定できなかった。 | todo | high | DEV | 2026-09-23 | 2026-09-30 | 2026-09-23 | git の失敗理由から進捗表示を除き、原因を示す行を優先して残すようにした。全文は GitCommandError が保持する。ログへの書き出しは必要が生じた時点で別途扱う。 | pjr-tr8g-git-failure-reason-progress | - |
| PJR-YPNS | done | kata と schema の解決順序を実装する | prj-0001:pjr-fkn1-kata-distribution-method で決めた「参照を既定、上書きしたいものだけ eject」の第 1 段階を実装する。現在 CLI は specdojoRootDir()（利用者のリポジトリルート）直下の固定パスで kata と schema を探すため、kata が無いリポジトリでは exec plan が Template not found で止まる。 | todo | high | DEV | 2026-09-23 | 2026-10-10 | 2026-09-23 | kata と schema の解決を利用リポジトリ優先・package フォールバックへ集約し、kata を持たないリポジトリで exec plan まで到達できるようにした。解決と列挙を区別し、grade の対象列挙は利用リポジトリ限定とした。 | pjr-ypns-kata-resolution | - |
| PJR-2M84 | done | 統合の merge commit 失敗時に merge を中断して develop を merge 途中のまま残さない | worktree 統合（finalizeRegisterWorktreeRun および Schedule タスクの統合段）は、exec ブランチを git merge --no-ff で develop へ取り込む。merge commit の作成が pre-commit hook で失敗すると、runner は merge を中断せずに失敗処理へ進む。develop は「conflict なし・merge 途中（MERGE_HEAD あり）」の状態で残り、続く wait 遷移の commit が fatal: cannot do a partial commit during a merge で失敗する。結果として develop は merge 途中のまま、register も waiting になり、人が git commit で merge を完了するしかない（PJR-YWPH、2026-09-21）。 | todo | high | DEV | 2026-09-21 | 2026-10-05 | 2026-09-22 | - | pjr-2m84-integrate-merge-abort | - |
| PJR-DPVV | done | 文書 lint を @specdojo/docs-lint として分離する | specdojo の package.json の files は tools/docs/src と tools/docs/tsconfig.json を同梱しているが、次の理由で利用者側では機能しない。 | todo | medium | DEV | 2026-09-21 | 2026-10-10 | 2026-09-21 | - | pjr-dpvv-docs-lint-package | - |
| PJR-W66B | done | 親検証に typecheck を加え、型エラーを commit hook まで持ち越さない | pipeline.parent_validations（.specdojo/exec-defaults.yaml）は test-integration / validate-schema / test-unit の 3 つで、typecheck を含まない。Vitest は型検査を行わないため、executor が残した TypeScript の型エラーは親検証を通過し、統合時の pre-commit hook（typecheck）で初めて失敗する。PJR-YWPH では新規テストの mockImplementation の型不一致がこの経路で hook まで持ち越され、PJR-2M84 の merge 途中残留と重なった。 | todo | medium | DEV | 2026-09-21 | 2026-10-05 | 2026-09-23 | - | pjr-w66b-parent-validation-typecheck | - |
| PJR-YWPH | done | register の todo 用 plan に関連文書の grade finding を展開する | PJR-XKKS で grade の結果と finding は成果物の本文コメントから execution/grade/results/<doc-id>.yaml のサイドカーへ移った。agent への finding 提示は plan 生成時の展開（_GRADE_FINDINGS_）に一本化したが、展開が入っているのは fully-guided と maintenance 系・bootstrap の exec テンプレート 6 本だけで、register の todo 用 plan（xep-register-template）にはない。 | todo | low | DEV | 2026-09-21 | 2026-10-15 | 2026-09-22 | - | pjr-ywph-register-plan-grade-findings | - |
1.4. OPS
| ID | ステータス | タイトル | 説明 | 分類 | 優先度 | 担当 | 登録日 | 期限 | 完了日 | 結論 | 個票 | depends_on |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PJR-TATP | open | worktrees と node_modules を共有フォルダから named volume へ移す | ワークスペース全体が virtiofs の bind mount 上にあり、16 個の node_modules と exec の worktree（計 8GB 程度）がファイル I/O を遅くしている。worktrees/ と各 node_modules を Docker の named volume へ移し、routine cron と exec のパス解決への影響を設計する | todo | medium | OPS | 2026-10-12 | _TODO_ | - | - | pjr-tatp-devcontainer-named-volumes | - |
| PJR-CJQM | open | 統合専用 actor を用意し main と develop に branch protection を設定する | prj-0001:pjr-ewwx-feature-branch-policy の決定を運用へ反映する。specdojo:git-branching-standard は main と project/<project-id>/develop に branch protection を求めているが、現在は未設定である。標準は「統合専用 actor を分離できない間は develop の保護を有効化しない」として猶予を認めており、本項目はその猶予を終わらせるための作業を扱う。 | todo | low | OPS | 2026-09-23 | 2026-12-31 | - | - | pjr-cjqm-branch-protection-setup | - |
| PJR-WJZD | done | @specdojo/docs-lint を npm へ公開できるようにする | prj-0001:pjr-09kk-npm-onboarding-path で整えた導線は、文書 lint の導入をこう案内する。 | todo | high | OPS | 2026-09-23 | 2026-10-03 | 2026-10-12 | @specdojo/docs-lint 0.2.0 を trusted publisher 経由で npm へ公開し、導入と動作を確かめた | pjr-wjzd-publish-docs-lint | - |
| PJR-1Y0G | done | devcontainer に残る vscode-server の残骸プロセスを抑止・掃除する | devcontainer は "shutdownAction": "none" でコンテナを生かし続ける運用のため、VS Code の再接続や更新のたびに旧 commit の server-main.js、親を失った extension host・language server・拡張のデーモン（openai.chatgpt の codex など）がコンテナ内に残り、メモリを圧迫していた。grade の background job がメモリ不足で停止した際、VS Code 系だけで約 3 GB（12 GB 中）を占めていた。 | todo | medium | OPS | 2026-09-18 | 2026-09-30 | 2026-09-23 | init: true と kill-stale-vscode.sh により残骸プロセスの蓄積を解消。rebuild 後に PID 1 が docker-init になり、接続時の自動掃除も動作することを確認した。 | pjr-1y0g-devcontainer-stale-vscode-server | - |
1.5. PM
| ID | ステータス | タイトル | 説明 | 分類 | 優先度 | 担当 | 登録日 | 期限 | 完了日 | 結論 | 個票 | depends_on |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PJR-2JYE | done | dashboard に routine の実行状況・着手可能な登録項目のおすすめ順・要対応一覧を追加し毎朝 5 時に更新する | 現行の dashboard（Schedule / タイムライン / 登録簿の件数 / routine の最終実行）には「今日なにをすべきか」を判断する情報がない。次の 3 節を追加し、毎朝 5:00 に routine で再生成する。 | todo | medium | PM | 2026-09-18 | 2026-09-30 | 2026-09-21 | - | pjr-2jye-dashboard-daily-briefing | - |
| PJR-0126 | done | PO承認をpull requestベースにする承認フロー整備 | decision起票のみでは証跡が弱いため、charter等のPO留保事項の承認をpull requestレビューで行う運用を整備する。対象範囲・branch保護/CODEOWNERS・承認証跡の書き戻しを検討 | todo | medium | PM | _TODO_ | 2026-07-31 | 2026-07-26 | pull requestで承認する運用を明記 | pjr-0126-pr-based-po-approval | - |
1.6. PO
| ID | ステータス | タイトル | 説明 | 分類 | 優先度 | 担当 | 登録日 | 期限 | 完了日 | 結論 | 個票 | depends_on |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PJR-2FV2 | in-progress | 0.6.0 でリリースする | specdojo 0.6.0 と @specdojo/docs-lint 0.4.0 を公開する。@specdojo/docs-site は変更がないため 0.3.0 のままとする。 | todo | high | PO | 2026-10-31 | 2026-11-30 | - | - | pjr-2fv2-release-v0-6-0 | - |
| 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-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-0002 | done | Launch スケジュール | Track=Launch のスケジュールを作成 | todo | high | PO | _TODO_ | 2026-05-10 | 2026-05-24 | sch-strategy-launchを作成 | pjr-0002-launch | - |
| PJR-0003 | done | 役割・担当者の定義方法 | 役割と担当者の定義方法を整理する | todo | high | PO | _TODO_ | 2026-05-10 | 2026-07-22 | pm-roles, pm-membersに設定 | pjr-0003-item | - |
| PJR-0005 | done | specdojo:pjr-rulebook作成のtask化 | specdojo:pjr-rulebookの作成をスケジュールに記述 | todo | high | PO | _TODO_ | 2026-05-10 | 2026-07-23 | specdojo:pjr-rulebookを個別に作成 | pjr-0005-specdojo-pjr-rulebook-task | - |
| PJR-0016 | done | prj-scope-*作成 | rulebookを作成して、instruction, sampleへ展開する | todo | high | PO | _TODO_ | 2026-05-10 | 2026-05-24 | このtodoはschで管理 | pjr-0016-prj-scope | - |
| PJR-0017 | done | prj-success-criteria-and-acceptance-criteria-*作成 | rulebookを作成して、instruction, sampleへ展開する | todo | high | PO | _TODO_ | 2026-05-10 | 2026-05-24 | このtodoはschで管理 | pjr-0017-prj-success-criteria-and-acceptance-criteria | - |
| PJR-0018 | done | prj-issues-and-approach-*作成 | rulebookを作成して、instruction, sampleへ展開する | todo | high | PO | _TODO_ | 2026-05-10 | 2026-05-24 | このtodoはschで管理 | pjr-0018-prj-issues-and-approach | - |
| PJR-0019 | done | prj-assumptions-constraints-dependencies-*作成 | rulebookを作成して、instruction, sampleへ展開する | todo | high | PO | _TODO_ | 2026-05-10 | 2026-05-24 | このtodoはschで管理 | pjr-0019-prj-assumptions-constraints-dependencies | - |
| PJR-0020 | done | prj-comparison-of-alternatives-*作成 | rulebookを作成して、instruction, sampleへ展開する | todo | high | PO | _TODO_ | 2026-05-10 | 2026-05-24 | このtodoはschで管理 | pjr-0020-prj-comparison-of-alternatives | - |
| PJR-0021 | done | pm-plan-*作成 | rulebookを作成して、instruction, sampleへ展開する | todo | high | PO | _TODO_ | 2026-05-10 | 2026-05-24 | このtodoはschで管理 | pjr-0021-pm-plan | - |
| PJR-0022 | done | pm-communication-plan-*作成 | rulebookを作成して、instruction, sampleへ展開する | todo | high | PO | _TODO_ | 2026-05-10 | 2026-05-24 | このtodoはschで管理 | pjr-0022-pm-communication-plan | - |
| PJR-0023 | done | pm-quality-management-plan-*作成 | rulebookを作成して、instruction, sampleへ展開する | todo | high | PO | _TODO_ | 2026-05-10 | 2026-05-24 | このtodoはschで管理 | pjr-0023-pm-quality-management-plan | - |
| PJR-0024 | done | pm-roles-*作成 | yamlを作る前提でrulebookを作成して、instruction, sampleへ展開する | todo | high | PO | _TODO_ | 2026-05-10 | 2026-05-05 | rulebook/instruction/sample作成済み | pjr-0024-pm-roles | - |
| PJR-0025 | done | pm-members-*作成 | rulebookを作成して、instruction, sampleへ展開する | todo | high | PO | _TODO_ | 2026-05-10 | 2026-05-05 | rulebook/instruction/sample作成済み | pjr-0025-pm-members | - |
| PJR-0026 | done | pm-raci-*作成 | rulebookを作成して、instruction, sampleへ展開する | todo | high | PO | _TODO_ | 2026-05-10 | 2026-05-05 | rulebook/instruction/sample作成済み | pjr-0026-pm-raci | - |
| PJR-0027 | done | プロジェクト名の見直し | 旧プロジェクト名となっている箇所を SpecDojo へ見直し | todo | high | PO | _TODO_ | 2026-05-10 | 2026-05-05 | 関連ドキュメントを更新済み | pjr-0027-item | - |
| PJR-0028 | done | pm-organization-*作成 | rulebookを作成して、instruction, sampleへ展開する | todo | high | PO | _TODO_ | 2026-05-10 | 2026-05-05 | rulebook/instruction/sample作成済み | pjr-0028-pm-organization | - |
| PJR-0041 | done | roles, membersの見直し | rolesに全ロールを記述して、membersに兼務を反映するように変更 | todo | high | PO | _TODO_ | 2026-05-17 | 2026-05-17 | rolesとmembers, 関連文書を見直し | pjr-0041-roles-members | - |
| 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-0145 | done | README.md / docs/index.md / docs/<lang>/index.md の責務再整理と記述見直し | README.md、docs/index.md、docs/<lang>/index.md の役割分担を整理し、記述内容を見直す。 | todo | medium | PO | _TODO_ | 2026-10-31 | 2026-09-05 | README と docs 配下 index の責務を分離し、重複4節を参照で解消した。英語版は未翻訳であることと日本語版への導線を明示する構成にした。 | pjr-0145-readme-md-docs-index-md-docs-lang-index-md | - |
| 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-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-0119 | decided | プロジェクト憲章の承認 | prj-charter の立ち上げ認可と権限委譲を PO として承認する | decision | high | PO | _TODO_ | 2026-07-17 | 2026-07-17 | コミットce44286c時点の憲章を承認。立ち上げ認可と権限委譲を確定 | pjr-0119-charter-approval | - |
| PJR-0122 | done | launch trackの振り返り | workflowの改善点を振り返りまとめる。 | todo | medium | PO | _TODO_ | 2026-07-31 | 2026-07-26 | 改善点を一通り反映 | pjr-0122-review-launch | - |
1.7. QE
| ID | ステータス | タイトル | 説明 | 分類 | 優先度 | 担当 | 登録日 | 期限 | 完了日 | 結論 | 個票 | depends_on |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PJR-BWYW | done | BPS 2 件の grade 指摘を解消する | prj-0001:pjr-h5z7-cdfd-3-bps-2-grade-finding で BPS 2 件を評価した。bps-task-completion は pass（96 点）、bps-deliverable-evaluation は needs-work（92 点）で、指摘は 4 件ある。いずれも構造上の問題ではなく記述の整理である。 | todo | low | QE | 2026-09-26 | _TODO_ | 2026-09-27 | - | pjr-bwyw-bps-2-grade | - |
| PJR-H4H7 | done | 成果物評価の BPS を作成し grade と review の関係を定義する | prj-0001:pjr-2zvs-grade-review-integration で確定した grade と review の関係を、業務プロセス仕様として記述する。個票の決定は経緯を含むため設計の正本にならない。BPS を正本とし、cdfd-* の修正とテンプレート改訂はこれを根拠に展開する。 | todo | high | QE | 2026-09-26 | _TODO_ | 2026-09-26 | - | pjr-h4h7-bps-grade-review | - |
| PJR-H5Z7 | done | CDFD 3 本と BPS 2 件の grade を実行し finding を確認する | grade と review の関係を確定する一連の作業で、CDFD 3 本を変更し BPS 2 件を新規作成した。いずれも grade を実行していない。5 文書の評価結果を確認し、変更が finding を増やしていないこと、新規 2 件が基準を満たすことを確かめる。 | todo | medium | QE | 2026-09-26 | _TODO_ | 2026-09-26 | - | pjr-h5z7-cdfd-3-bps-2-grade-finding | - |
| PJR-N22N | done | xrp と xrr テンプレートを review が評価しない前提へ改訂する | prj-0001:pjr-h4h7-bps-grade-review で確定した設計では、review は成果物を再評価せず、grade を事実として受け取ってタスクの完了可否を判断する。現在の xrp-* テンプレートはレビュー観点ごとに pass / fail / unclear を判定する指示であり、**review が評価を行う前提**で書かれている。12 本のテンプレートを改訂する。 | todo | high | QE | 2026-09-26 | _TODO_ | 2026-09-28 | xrp 10 本と xrr を、観点ごとに評価せず grade の結果を入力にタスクの完了可否を判断する形へ改訂し、観点別詳細テンプレート 2 本を削除した。review の verdict を bps-task-completion の 6 区分に合わせ、共通規約に判断手順を集めた。review の試行と review-guide の追従は PJR-KCMH へ引き継ぐ | pjr-n22n-xrp-xrr-review | - |
| PJR-Z47X | done | grade の changed_only が照合型観点の突き合わせ先の変更を検出しない | grade --changed-only は、**対象成果物の内容だけ**から計算した content_hash で再評価の要否を決める。照合型の観点は他の成果物と突き合わせて判定するため、突き合わせ先が変わっても対象成果物の hash は変わらず、**古い評価結果が残り続ける**。実運用の routine は changed_only: "true" で動くため、この経路が既定である。 | todo | medium | QE | 2026-09-25 | _TODO_ | 2026-09-28 | 観点に comparison_sources を宣言し、grade result の source_hashes で突き合わせ先の変更を changed_only の契機にした。dependency_changed も依存先の内容の hash で判定する。全件の再評価は定期経路にせず手動で行う | pjr-z47x-grade-changed-only | - |
| PJR-0123 | done | registerの個票の内容を見直し | idや基本情報を見直し | todo | medium | QE | _TODO_ | 2026-07-31 | 2026-07-26 | 重複した記述や個票間での違いを修正 | pjr-0123-register | - |
| PJR-0130 | done | Whyの明確性を既存review viewpointsへ反映 | 重複観点を増やさず、目的整合・業務価値・可読性の既存観点にWhyの判定基準と証拠を具体化する | todo | medium | QE | _TODO_ | 2026-07-31 | 2026-07-26 | whyの明確性をreview viewpointsに反映 | pjr-0130-clarify-why-review-viewpoints | - |
1.8. UX
| ID | ステータス | タイトル | 説明 | 分類 | 優先度 | 担当 | 登録日 | 期限 | 完了日 | 結論 | 個票 | depends_on |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PJR-34MQ | done | リポジトリ構成を平易な名前へ改め README を初めての人に分かる形にする | npm の README は、初めて SpecDojo を使う人に向けた導入の説明で、説明のない用語が多い。とくに「Detached Unit」は定義がなく、なぜ別のリポジトリにするのかも書かれていない。リポジトリ構成を平易な名前へ改め、README を初めての人が読んで分かる形にする。 | todo | high | UX | 2026-09-26 | _TODO_ | 2026-09-26 | - | pjr-34mq-plain-repository-naming-readme | - |
| PJR-0132 | done | 既存review viewpointで文書の冗長性を検出 | 新しい観点を重複追加せず、vp-ux-readabilityに反復・一般論・表と本文の重複・正本の過剰再掲を検出する基準を追加する | todo | medium | UX | _TODO_ | 2026-07-31 | 2026-07-26 | review-viewpointsに反映 | pjr-0132-detect-document-redundancy | - |
1.9. TODO
| ID | ステータス | タイトル | 説明 | 分類 | 優先度 | 担当 | 登録日 | 期限 | 完了日 | 結論 | 個票 | depends_on |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PJR-YKYK | done | template のない rulebook の雛形の type を deliverable_type にする | deliverable scaffold の一括生成と --target の両方で、template のない rulebook の最小の雛形の type を rulebook の deliverable_type にし、宣言がない場合は project のままにする。 | todo | medium | _TODO_ | 2026-10-31 | _TODO_ | 2026-10-31 | template のない rulebook の最小の雛形の type を rulebook の deliverable_type にし、宣言がない場合は project のままにした。一括生成と --target の両方に効き、テストを足した | pjr-ykyk-scaffold-fallback-deliverable-type | - |
| PJR-S23T | done | deliverable scaffold で成果物を 1 つだけ雛形にできるようにする | --target で成果物を 1 つだけ指定して雛形を作り、カタログにない成果物は --target-path と --target-rulebook で作れるようにする。 | todo | medium | _TODO_ | 2026-10-30 | _TODO_ | 2026-10-30 | deliverable scaffold に --target・--target-path・--target-rulebook を追加し、成果物を 1 件だけ雛形にできるようにした。パスの検証は register と共通の関数にし、context-pass の説明・command-reference・CHANGELOG を直した | pjr-s23t-deliverable-scaffold-target | - |
| PJR-0QW0 | done | markdownlint の設定がない利用リポジトリで result の commit 前検査が MD013 で統合を止める | docs-lint を入れた利用リポジトリでは markdownlint の既定設定（MD013）が効き、日本語の result が必ず統合前に止まる。設定がなくても SpecDojo の規則で検査し、init が設定を作るようにする | todo | high | _TODO_ | 2026-10-29 | _TODO_ | 2026-10-29 | 設定がない場合は result の commit 前検査に SpecDojo の基本規則（MD013・MD024・MD033・MD036・MD041・MD060 を無効）を使い、既存設定を優先する。init と config init は .markdownlint.yaml を上書きせずに生成する。空のリポジトリで init の生成と、設定なしでの exec run --register の review までの通過を確認した | pjr-0qw0-result-markdownlint-default-config | - |
| PJR-166T | done | 成果物を作るときの前提（技術スタックなど）を agent に渡す場所がない | approach plan が読める範囲に作成の前提を書く欄がなく、個票は完了条件しか plan に入らない。fully-guided の雛形は磨き込み専用の書き方で草案作成と食い違い、人が先に書いて磨く手順も文書化されていない | issue | high | _TODO_ | 2026-10-29 | _TODO_ | 2026-10-31 | PJR-65DS の流れ（雛形・文脈の記入・draft・fully-guided・finalize）と文脈の置き場所（_CONTEXT_・入力・brief）を、3MY5・JRSY・6DD7・YKMA・E45K・6A2B・D0GB・S23T・YKYK・73KT で実装と文書に反映し、調査結果の問題をすべて解消した | pjr-166t-deliverable-input-brief | - |
| PJR-3MY5 | done | draft approach を設け、fully-guided を磨き込み専用・宣言された参照に改める | 文脈で任された範囲を調べて下書きする draft を追加し、fully-guided の plan・review 雛形を磨き込み専用にして参照範囲に based_on・入力・brief を加える | todo | medium | _TODO_ | 2026-10-29 | _TODO_ | 2026-10-29 | draft approach（plan 雛形・schema・CLI の検証）を追加し、fully-guided の plan・review 雛形を磨き込み専用・宣言された参照（based_on・入力・brief を含む）に改めた。schedule の guided-pass の草案の段が fully-guided のままになる食い違いは PJR-E45K の完了条件に加えて直す | pjr-3my5-draft-approach | - |
| 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-6A2B | done | 文脈を渡して成果物を作る流れをガイドにまとめる | scaffold・文脈の記入・draft・fully-guided・finalize の流れと、_CONTEXT_・--input・brief の使い分けを関連ガイドと tsd-recipe に書く | todo | medium | _TODO_ | 2026-10-29 | _TODO_ | 2026-10-31 | 文脈を渡して成果物を作る流れ（雛形・文脈の記入・draft・fully-guided・finalize）と、_CONTEXT_・--input・brief の使い分けを exec-operation-guide・ryu-guide・tsd-recipe に書いた。雛形の例は deliverable scaffold --target の形にし、ID は project で修飾し、finalize の担当は役割にした | pjr-6a2b-context-draft-guides | PJR-JRSY, PJR-6DD7, PJR-YKMA, PJR-E45K, PJR-S23T, PJR-YKYK |
| PJR-6DD7 | done | 個票の入力節と register の --input を設ける | 対話で得た前提を個票の入力節へ記録する --input を add/update に追加し、register 経由の plan の参照範囲に入れる | todo | medium | _TODO_ | 2026-10-29 | _TODO_ | 2026-10-29 | 個票の入力節と register add/update の --input（反復・一覧置換・- で全削除、event 記録）を追加し、register 経由の plan に完了条件と別の前提として載せた。オーケストレーターの指示への追記は利用者の承認のもと feature ブランチで反映した | pjr-6dd7-register-input | PJR-3MY5 |
| PJR-D0GB | done | ready 以外の文書の _CONTEXT_ の検出を情報に下げ、--frail で lint:fm を落とさない | 下書きに _CONTEXT_ を書くと --frail の lint:fm が warning で失敗し、draft までの間すべての exec run の親の検証が止まる。ready 以外は file.info とし、ready の error は維持する | todo | high | _TODO_ | 2026-10-29 | _TODO_ | 2026-10-29 | ready 以外の文書の _CONTEXT_ を file.info で報告し --frail の lint:fm を落とさないようにした。ready の文書では error のまま。規約・README・テスト・CHANGELOG を更新した | pjr-d0gb-context-marker-info-level | - |
| PJR-E45K | done | 雛形・文脈・draft・磨き込みを並べる schedule の profile を追加する | 雛形と人による文脈の記入、draft、refine、review、finalize の順で段を並べる strategy profile を追加する | todo | medium | _TODO_ | 2026-10-29 | _TODO_ | 2026-10-30 | intent: draft-with-context で選べる draft profile（雛形作成・文脈記入（human）→ draft → refine → review → finalize）を追加し、guided-pass の草案の段を draft に替えた。人の段の result 雛形、schedule-design-guide と sch-rulebook を更新した | pjr-e45k-schedule-context-draft-profile | PJR-3MY5, PJR-JRSY |
| PJR-JRSY | done | 成果物の文脈の目印 _CONTEXT_ を設ける | _CONTEXT_ の書き方を規約に加え、draft が反映後に消して result へ写し、finalize と lint で残りを検出する | todo | medium | _TODO_ | 2026-10-29 | _TODO_ | 2026-10-29 | _CONTEXT_ の書き方を記述規約と document-metadata-standard に加え、draft・fully-guided の plan、finalize・bootstrap-finalize の確認チェックリスト、docs-lint の検出（ready で error、それ以外は warning）に反映した。--frail で warning も失敗になる点は別項目で扱う | pjr-jrsy-context-marker | PJR-3MY5 |
| PJR-SC8T | done | deliverable_type の照合が rulebook の一覧をファイルごとに作り直し lint:fm が遅い | remark がファイルごとにプラグインを読み込み直すため、PJR-484B の照合が rulebook の一覧（約 0.34 秒）を毎回作り、lint:fm が 7 分かかって親の検証の上限に迫る。一覧をワークスペースごとに 1 回だけ作る | todo | high | _TODO_ | 2026-10-29 | _TODO_ | 2026-10-29 | deliverable_type の照合で rulebook の一覧をワークスペースごとに 1 回だけ作るようにし、lint:fm が 421 秒から 25 秒になった。docs-lint 0.3.1 の hotfix を main から用意した | pjr-sc8t-deliverable-type-index-cache | - |
| PJR-YKMA | done | カタログの成果物に brief を設ける | 成果物の外から継続して渡す前提を dct の brief に書けるようにし、schedule と register の両経路の plan に入れる | todo | medium | _TODO_ | 2026-10-29 | _TODO_ | 2026-10-30 | dct.schema.yaml の成果物に brief を追加し、schedule と register の両経路の plan に前提として載せた。dct-rulebook・sample・ryu-guide に overview・done_criteria との使い分けと YAML アンカーでの共有を書いた | pjr-ykma-catalog-brief | PJR-3MY5 |
| PJR-484B | done | 成果物の type に requirement と glossary を足し、rulebook の宣言と lint で照合する | schema に requirement と glossary を足し、rulebook 107 件の frontmatter に扱う成果物の type を宣言させる。Markdown の成果物・sample・テンプレートの type を宣言にそろえ、違えば lint でエラーにする | todo | medium | _TODO_ | 2026-10-28 | _TODO_ | 2026-10-28 | type に requirement と glossary を足し、rulebook 107 件に deliverable_type を宣言した。Markdown の sample 50 件を宣言にそろえ、lint:fm が成果物・sample・テンプレートの type を宣言と照合する | pjr-484b-deliverable-type-declaration | - |
| PJR-4FP2 | done | VS Code からオーケストレーターを使う手順を案内する | Copilot Chat の agent の選択、Claude Code の拡張での既定の agent の設定、Codex の拡張での使い方を、orchestrator-operation-guide・クイックスタート・templates/copilot/README.md に書き、onboarding の間口を広げる | todo | medium | _TODO_ | 2026-10-28 | _TODO_ | 2026-10-28 | orchestrator-operation-guide に VS Code から使う節（Copilot Chat の agent の選択、Claude Code の settings の agent キー、Codex の拡張で本文を渡す使い方）を足し、クイックスタートと Copilot の README から案内した | pjr-4fp2-orchestrator-vscode-guide | - |
| PJR-6RVJ | done | register の項目に順番の依存（depends_on）を追加する | 個票の frontmatter に depends_on を足し、先行の項目が終端でなければ exec run --register・routine の sweep・夜間の queue で実行を飛ばす。存在しない ID・自己参照・循環を検証し、一覧と逆引きのビューに出す | todo | high | _TODO_ | 2026-10-28 | _TODO_ | 2026-10-28 | depends_on を追加した。add/update の --depends-on、未存在・自己参照・循環の検証、先行が未終端の項目の実行停止と sweep・夜間 queue のスキップ、一覧の列と逆引きビューを実装した | pjr-6rvj-register-depends-on | - |
| PJR-AB1Y | done | ガイドを register を起点とする構成へ書き換える | register-operation、exec-operation の実行経路の使い分け、timeline-design、command-reference を、register と epic を起点とする構成へ書き換える | todo | medium | _TODO_ | 2026-10-28 | _TODO_ | 2026-10-28 | register-operation・exec-operation・timeline-design・specdojo-overview・quick-start の 5 本を、register と epic を起点とし schedule を子とする構成へ書き換えた | pjr-ab1y-register-centric-guides | PJR-WAGY |
| PJR-B4Y4 | done | register に epic の type を追加する | schema・個票のテンプレート・register の各コマンドで epic を扱い、exec run --register の対象から外す。子 todo を --from でたどる一覧を出す | todo | high | _TODO_ | 2026-10-28 | _TODO_ | 2026-10-28 | epic の type を追加した。track の記帳と tml-index での検証、個票テンプレート、exec run --register と夜間 queue からの除外、epic ごとの子項目のビューを実装した。orchestrator の指示への反映案は対応結果に残した | pjr-b4y4-register-epic-type | - |
| 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-FZ06 | done | MD060 の review テンプレートのテストが負荷で 5 秒の上限を超える | tests/src/exec/review-template-table.test.ts の MD060 のテストが、親の検証の負荷で 5.0〜5.7 秒かかり時間切れになる。PJR-EVAE・PJR-484B・PJR-0D0T の実行で落ち、そのたびに親の検証をやり直した | issue | medium | _TODO_ | 2026-10-28 | _TODO_ | 2026-10-28 | MD060 のテストを markdownlint の CLI の起動から同一プロセスの lint API に変え、検査の範囲を保ったまま負荷の下でも数十ミリ秒で終わるようにした | pjr-fz06-md060-test-timeout | - |
| 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-R7MW | done | tml-index の data-flow-pdca の order が依存先と同じで timeline build が止まる | data-flow-pdca が depends_on の data-flow と同じ order 3 を持ち、timeline build が order の矛盾で停止する。3ae6b0596（2026-09-15）で track を切り出したときからの不整合 | issue | medium | _TODO_ | 2026-10-28 | _TODO_ | 2026-10-28 | data-flow-pdca の order を 4 にし、timeline build が通るようにした | pjr-r7mw-tml-data-flow-pdca-order | - |
| 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-WAGY | done | カタログと strategy を作るための approach を追加する | 子 todo からカタログの判定と生成（catalog plan・scaffold --plan）と schedule strategy generate を流せるようにし、todo の close から catalog_status を導く | todo | medium | _TODO_ | 2026-10-28 | _TODO_ | 2026-10-28 | catalog-planning と strategy-planning の approach を追加した。--target domain:/track: で対象を指し、plan に kata とカタログの参照と完了条件を展開する。timeline build と strategy 生成が register から catalog_status を導き、tml-index は書き換えない | pjr-wagy-catalog-strategy-approach | PJR-B4Y4 |
| PJR-JJJB | rejected | init が .gitignore に node_modules を追加しない | specdojo init は生成物の除外行だけを .gitignore に追記する。npm init 直後のリポジトリで git add -A すると node_modules まで commit され、worktree 実行の前提となる commit 手順と相性が悪い | issue | medium | _TODO_ | 2026-10-13 | _TODO_ | 2026-10-14 | PJR-J2AS の重複。config init と init は同じ既定の一覧から node_modules/ を .gitignore へ追記する（develop・main で修正済み）。検証に J2AS の修正を含まない版（npm の specdojo 0.2.1 など）を使ったとみられる | pjr-jjjb-init-gitignore-node-modules | - |
| PJR-HJ99 | done | executor が実行できない index build の not_run で run が止まる | .specdojo/doc-index.json は agent の書き込み禁止対象のため、executor は specdojo index build を not_run と記録するしかない。index は worktree の準備で runner が再生成しているが、その結果は not_run を満たす根拠として扱われず run が止まる（PJR-ADZ6 で発生）。runner が担う検証として満たしたとみなす | issue | medium | _TODO_ | 2026-10-12 | _TODO_ | 2026-10-12 | index build を runner が担う検証とし、catalog validate の適用を変更範囲でも判定するようにした | pjr-hj99-index-build-not-run-blocks | - |
| PJR-J2AS | done | config init が .gitignore に node_modules/ を加えない | README の導入手順（npm init -y → npm install --save-dev specdojo → config init）で、config init は SpecDojo の生成物だけを .gitignore に追記し node_modules/ を加えない。git add . で node_modules が commit される | issue | high | _TODO_ | 2026-10-12 | _TODO_ | 2026-10-12 | config init が .gitignore に node_modules/ を追記するようにした | pjr-j2as-config-init-gitignore-node-modules | - |
| PJR-MD3C | done | Job Run の review agent と統合前 review の宣言を Job で指定する | routine が起動する Job Run の review agent が自動選択になっており、routine からも指定できない。review agent の指名と、review を経て統合することの宣言を Job Definition の責務として追加し、routine の action.commit は互換として残す。grade の 2 Job で claude-expert-review-executor と claude-reporter を指名する | todo | high | _TODO_ | 2026-10-12 | _TODO_ | 2026-10-12 | Job の task.review で統合前 review の宣言と review agent の指名をできるようにし、grade の 2 Job で claude-expert を指名した | pjr-md3c-job-review-agent | - |
| PJR-PV5B | open | devcontainer scaffold の実機確認で気づいた点 | scaffold の devcontainer は親フォルダを /workspaces/specdojo-workspace に固定でマウントし、利用者のフォルダ名と無関係な名前になる。--tmux などの任意機能は指定しないと入らず、完了時の案内からも分からない（tmux が無いことにコンテナの作成後に気づいた） | note | medium | _TODO_ | 2026-10-12 | _TODO_ | - | - | pjr-pv5b-devcontainer-scaffold-observations | - |
| 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-T0VQ | done | PJR-ID の桁数は4桁で十分（衝突可能性を評価済み） | 32^4=1,048,576 の ID 空間と再抽選方式の評価結果を記録する。通常経路では衝突せず、桁数拡張は後方互換で後から可能。 | todo | low | _TODO_ | 2026-08-09 | - | 2026-08-09 | 32^4の空間と再抽選方式により通常経路では衝突しないと評価。桁数拡張は後方互換で後から可能 | pjr-t0vq-pjr-id-length-evaluation | - |
| PJR-0161 | done | 登録簿承認typeの承認フローとPR/commit使い分けの規約化 | 承認を要するtype(change-request/decision/risk/question/issue)の承認フローをregister状態遷移(review→close等)へ明文化し、承認方式を既定commit＋限定PRで規約化する。PR強制はdevelop→main昇格/change-request承認/不可逆・高リスク・schema破壊的変更に限定。branch protectionとCODEOWNERSで承認者を強制、decision/questionテンプレに承認者欄を追加。関連文書はbranch-workflow-guide/git-branching-standard/register-operation-guide/pjr-rulebook。 | todo | high | _TODO_ | _TODO_ | _TODO_ | 2026-08-08 | - | pjr-0161-register-approval-workflow-policy | - |
| PJR-0160 | done | 登録簿type dependencyの要否見直し(廃止 or Assumption Log化 or 明文化) | dependencyはPMBOK非標準でexec実行区分/生成PMログなし・実績0件。waitingステータスおよびprj-assumptions-constraints-dependencies成果物と役割が重複。廃止/assumption type化/rulebook明文化のいずれかを決定し対応する。enum変更はschema・VALID_TYPES・exec-registerのSet・テンプレ・docsの同時修正を伴う破壊的変更。 | todo | medium | _TODO_ | _TODO_ | _TODO_ | 2026-08-07 | 案A（dependency type 廃止）を採択。enum・VALID_TYPES・テンプレート・schema・docs・テストを一貫更新。実績0件のため移行不要。必要時は後方互換の追加で再導入。 | pjr-0160-register-dependency-type-review | - |
| PJR-0158 | done | exec runにproject単位の実行ロックを追加しroutineのbusy-skipを実現 | exec run全体をproject単位のheartbeatロックで排他。--if-busy skip/wait/fail(手動fail/routine skip)。routine-state.jsonにlast_result=skippedを追加。retryは次のcron tickに委ね待機なし。 | todo | high | _TODO_ | _TODO_ | _TODO_ | 2026-08-08 | - | pjr-0158-exec-run-project-lock | - |
1.10. indie
| ID | ステータス | タイトル | 説明 | 分類 | 優先度 | 担当 | 登録日 | 期限 | 完了日 | 結論 | 個票 | depends_on |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PJR-9ZN5 | done | @specdojo/docs-siteが生成するpublic/mermaid等を.vitepress配下に集約する | 現在 @specdojo/docs-site (packages/docs-site) の build / dev / mermaid 実行時に、Mermaid SVG の出力先（public/mermaid）や kata ステージング（specdojo-kata-staging）が利用リポジトリのワークスペース直下に生成されるため、利用側のルートディレクトリが散らかり .gitignore にも複数のエントリ追加が必要になっている。これらの一時・生成ディレクトリを .vitepress/ 配下（例: .vitepress/mermaid や .vitepress/kata-staging 等）に集約し、VitePress 側の静的配信設定および README / config init の .gitignore テンプレートを整理する。 | todo | medium | indie | 2026-10-26 | _TODO_ | 2026-10-27 | 生成物を .vitepress 配下へ集約し、既存 URL、eject 優先、Git 除外を維持した。全体検査と通常導入した配布版の描画・build・dev・HTTP を確認した。 | pjr-9zn5-consolidate-docs-site-generated-dirs-under-vitepress | - |
| PJR-K87Y | done | gradeの単一文書評価パイプライン（run-per-document.sh相当）をspecdojoコマンド本体へ統合する | exec run のレビュー前 grade 実行（ensureReviewGrade）が外部スクリプト tools/grade/run-per-document.sh に依存しているため、specdojo grade run サブコマンドとして CLI 本体へ統合する。あわせて今回のマルチリポジトリ運用で確認された関連課題（1. ensureReviewGrade から grade plan -> agent run -> grade apply のネイティブ実行とエージェント自動選択/引き継ぎ、2. dist/grade/targets.js の project.repos マルチリポジトリ相対パス ../ 許容、3. ワークツリー分岐前の grade 結果/criteria サイドカーのチェックポイント対象化、4. exec scaffold --project 時の pm-review-viewpoints.yaml 参照先 standards/ -> defaults/ 修正および viewpoints_path 未設定時の specdojo:pm-review-viewpoints フォールバック、5. xrp-*-template.md の done_criteria 表で発生する markdownlint MD060 警告の解消）を解消する。 | todo | high | indie | 2026-10-25 | _TODO_ | 2026-10-26 | 単一文書gradeをCLI本体へ統合し、配布版・実agent評価・レビュー前grade・runner統合後の動作を確認した。 | pjr-k87y-integrate-grade-run-per-document | - |