課題ログ
このファイルは各
pjr-XXXX-<topic>.md（個票）から生成された派生ビューです。正本は個票の Frontmatter であり、このファイルは再生成可能です。
| ID | ステータス | タイトル | 説明 | 分類 | 優先度 | 担当 | 登録日 | 期限 | 完了日 | 結論 | 個票 | depends_on |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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 | - |