D2 と smart3pm のハーネスで何が起きるかを答える10問です。どの問いも、今日のプチ演習で起こしたことから出ます。
解き方
解き方
10問とも、D2(d2_harness_20260828)か smart3pm(smart3pm-harness-review)の実物のハーネスの話です。問いの頭に、どちらのハーネスかを書いています。前提には、そのハーネスのファイルが何を見て何を返すかを書いています。
どの問いも、今日のプチ演習で自分の手で起こしたことと同じ形です。1問1点で、8点以上を目安にしてください。解説は、全部解いた後に開きます。
10問
rules/core.mdは、どのセッションでも開始時に全文が読み込まれるルールのファイル。上限は80行と決めているharness/check-guidelines.shが、コミットの前と push の前に動く。core.md の行数をwc -lで数え、80行を超えていたら止める
- core.md は今79行。1行が600文字のルールを1本足して、80行にした。これをコミットする
check-guidelines.sh の行数の検査はどうなる?
- A. 通る。80行を超えていないので、コミットできる
- B. 止まる。1行が長すぎる
- C. 止まる。上限の80行ちょうどになった
- D. 警告だけが出て、コミットできる
正解と解説(解いた後に開く)
正解 A
根拠: check-guidelines.sh の検査1(wc -l の行数だけを上限と比べる。178-185行目)
誤答: B は文字数も見ているという思い込み。C は「80行まで」を「80行未満」と取り違え。D は検査が知らせるだけだという思い込み
プチ演習1(ハンズオンガイド)で、自分の CLAUDE.md に600文字の1行を足し、行数だけの検査が通すのを見ました。
- CLAUDE.md の中に
@ファイル名と書いたファイルは、セッションを開いた時点で中身ごと読み込まれる - D2 の CLAUDE.md は、7行目の
@AGENTS.mdで AGENTS.md を読み込んでいる - AGENTS.md の「読み分けガイド」には、「コーディングの前に agents/03(コーディング規約)を読むこと」と文章で書いてある。
@は付いていない - 開始時に動くフック
sessionstart_info.ps1が出すのは、ブランチ名と変更の状態だけ
- D2 のリポジトリで新しいセッションを開いた。まだ何も頼んでいない
この時点で、agents/03 の中身は読み込まれている?
- A. 読み込まれている。AGENTS.md と一緒に読み込まれる
- B. 読み込まれていない。コーディングを頼まれたときに、読むかどうかを Claude が決める
- C. 読み込まれていない。最初の依頼を送ったときに、フックが読み込ませる
- D. 読み込まれている。開始時のフックが全文を読み込ませる
正解と解説(解いた後に開く)
正解 B
根拠: CLAUDE.md:7(@ は AGENTS.md の1本だけ)、AGENTS.md:76-78(読み分けガイドは文章の指示)、sessionstart_info.ps1(出すのはブランチとステータス)
D2 自身も agents/07:76-77 で「入口のトリガーが弱い」と書いている
誤答: A は @ の取り込みが、文章で書いた参照にまで連なると思う誤解。C と D はフックが知識を入れると思う誤解
プチ演習2(ハンズオンガイド)で、名前で指しただけの REVIEW.md を、Claude が後から開く表示を見ました。
- D2 では、
DB/(SQL ファイルの置き場)を書き換えてよいのは develop と master のブランチだけ .claude/hooks/guard_db_branch.ps1は、Edit と Write の実行前(PreToolUse)に動くフック。今のブランチが develop と master 以外で、書き先が DB/ の中なら、理由を stderr に書いて終了コード 2 を返す
feature/s6000/s6010_d2_documentブランチで、Claude が Write でDB/sql/x.sqlを新しく作ろうとした
どうなる?
- A. 何も起きず、そのまま作られる
- B. 作られた後で、警告だけが Claude に返る
- C. 作られる前に止まり、止めた理由が Claude に返る
- D. 確認の画面が出て、人が許可すれば作られる
正解と解説(解いた後に開く)
正解 C
根拠: guard_db_branch.ps1:40-43(DB/ 配下は develop・master 以外で exit 2)、cases db-feat-01
誤答: B は実行後の検査と混同。D は終了コード 2 を確認の依頼と思う誤解
プチ演習3(ハンズオンガイド)で、guard_paths が書く前に止め、理由を返すのを見ました。
- 既存の migration(
app/Database/Migrations/の中)は書き換えず、新しく足す決まり。backend ユニットの.claude/immutable-paths(書き換え禁止の一覧)に載っている guard-write-scope.shは、Edit と Write の実行前に動く。書き先が担当範囲の外か、immutable-paths に載っていれば止めるguard-bash-write.shは、Bash の実行前に動く。止める条件は、書き先が担当範囲の外であることだけapp/Database/Migrations/は、backend ユニットの担当範囲の中にある
- Claude が Bash で
sed -i 's/old/new/' app/Database/Migrations/001_init.phpを実行しようとした(確認の画面は出ない設定とする)
どうなる?
- A. guard-bash-write.sh が、immutable-paths に載っているとして止める
- B. guard-bash-write.sh が、担当範囲の外への書き込みとして止める
- C. どちらのフックも止めず、ファイルが書き換わる
- D. guard-write-scope.sh が、Bash の書き込みも見て止める
正解と解説(解いた後に開く)
正解 C
根拠: guard-write-scope.sh:150(immutable-paths を見るのは Edit 系だけ)、guard-bash-write.sh:189-208(スコープの判定だけ)
誤答: A は Edit と同じ一覧を見ると思う誤解。D はフックがどのツールにも効くと思う誤解
プチ演習4(ハンズオンガイド)で、Edit を止めるフックだけのときに、シェルの書き込みが通るのを見ました。
- D2 では、テキストファイルの改行は CRLF と決めている
.claude/hooks/check_crlf_bom.ps1は、Edit と Write の実行後(PostToolUse)に動くフック。LF だけの改行を見つけると、理由を stderr に書いて終了コード 2 を返す
feature/s6000/s6010_d2_documentブランチで、Claude が Write で、LF 改行のdoc/notes/memo.mdを新しく作った
どうなる?
- A. ファイルは作られたまま残り、検査の結果が Claude に返る
- B. 書く前に止められ、ファイルは作られない
- C. 書いた後で、フックが自動で CRLF に直す
- D. 何も起きず、LF のまま残る
正解と解説(解いた後に開く)
正解 A
根拠: check_crlf_bom.ps1:38-43(単独の LF で exit 2)、cases cb-02
誤答: B は実行前と実行後の混同。C は検査が直すと思う誤解。D は実行後のフックの結果が捨てられると思う誤解
プチ演習5(ハンズオンガイド)で、check-phpver が、ファイルを残したまま結果を返すのを見ました。
- ハーネスのフックの本体(正本)は、
smart3pm_guidelinesフォルダに1つだけある - 各ユニットの
.claude/settings.jsonのフックは、親のフォルダをたどって正本を探し、見つけた本体を呼ぶ短いコマンドになっている。Bash の実行前に動くコマンドの要所は[ -r "$H" ] || { …; exit 2; } $Hは見つけた本体のパス。[ -r "$H" ]は「そのファイルが読めるか」を確かめる書き方で、読めなければ||の後ろが動く
- 親のどこにも
smart3pm_guidelinesが無い場所でユニットを開いた。Claude が最初に Bash でlsを実行しようとした
どうなる?
- A.
lsは実行され、エラーの文が画面に出るだけ - B. 確認の画面が出て、人が決める
- C.
lsは実行され、その後で Claude に警告が返る - D.
lsは実行されず、正本が見つからないことが Claude に返る
正解と解説(解いた後に開く)
正解 D
根拠: harness/settings.backend の Bash 用 command([ -r "$H" ] || { …; exit 2; })、design/harness-reference-type.md:33,71
誤答: A は、安全装置が無くても作業は進むと思う誤解(設計原則の Fail loud に反する)。C は実行前と実行後の混同
プチ演習8(ハンズオンガイド)で、フックの本体が無いとき、直接の登録では素通りし、ラッパーを挟むと止まるのを見ました。
- D2 の作業の順番は、実装 → レビュー②(人が行う2回目のレビュー)→ マージ待ち → マージ
.claude/agents/d2-code-reviewer.mdは、レビュー②の前に差分を読むサブエージェント。定義ファイルで permissionMode を plan(読むだけ)にし、「コードを直さない」「人が確かめる点を分けて書く」と決めている
- 実装が終わり、d2-code-reviewer を動かした
実際に起こるのはどれ?
- A. 見つけた誤りを、レビュー役がその場で直してコミットする
- B. 指摘が無ければ、状態が自動でマージ待ちに進む
- C. 重大な指摘があれば、実装の担当に自動で差し戻される
- D. 差分の問題点が根拠つきで報告される。コードは変わらず、次に進めるかは人が決める
正解と解説(解いた後に開く)
正解 D
根拠: d2-code-reviewer.md「報告の契約」(コードを直さない、要人間確認を分ける)、CLAUDE.md:23、d2-task-start/SKILL.md:35(レビュー②待ちは人の手番)
誤答: A は「AI レビュー = AI が直す」という期待。B と C はレビュー②を機械の工程と思う誤解
プチ演習6(ハンズオンガイド)で、AI レビューが指摘を書くだけで、コードを変えないのを見ました。
- ゲート①は、人が計画書を承認する工程。承認すると
new-approval-receipt.shが、計画書の sha256 をレシートに書く - sha256 は、ファイルの中身から計算する指紋のような値。1文字でも変わると別の値になる
verify-approval-receipt.shは、作業フォルダにある今の計画書から sha256 を計算し直し、レシートの値と比べる
- 承認(レシートの発行とコミット)の後で、担当ユニットの
plan-backend.mdの誤字を1文字直した。まだコミットしていない
verify-approval-receipt.sh の結果は?
- A. レシートが自動で書き直され、有効のまま
- B. 警告は出るが、有効(終了コード 0)
- C. 失効(終了コード 1)
- D. まだコミットしていないので、変更は見られず有効(終了コード 0)
正解と解説(解いた後に開く)
正解 C
根拠: verify-approval-receipt.sh(作業ツリーの sha256 を計算し直す)、plan-feature.md:73-91
誤答: A はレシートが計画書に追いつくと思う誤解。D はコミット済みだけを見ると思う誤解
プチ演習9(ハンズオンガイド)で、承認の後に1文字直すと INVALID になるのを見ました。
- D2 では、push、マージ、ブランチ作成は人の作業と決めている
.claude/settings.jsonの deny にBash(git push:*)とPowerShell(git push:*)があるguard_shell_policy.ps1も、Bash と PowerShell の実行前に git push を見つけると、終了コード 2 を返す
- 夜、誰も画面を見ていない状態で Claude に Issue を実装させた。実装の後で、Claude が
git push origin feature/s7000/s7001_xを実行しようとした
どうなる?
- A. 確認の画面が出て、朝に人が許可するまで待ち続ける
- B. 実行の前に拒否される。push は人の作業として残る
- C. push された後で、ログに警告が出る
- D. 夜間の実行では deny が効かず、push される
正解と解説(解いた後に開く)
正解 B
根拠: settings.json:17,21(deny)、guard_shell_policy.ps1 の git guard(push を exit 2)
誤答: A は deny と ask の混同。D は、人がいないと決まりが緩むと思う誤解
プチ演習10(ハンズオンガイド)で、deny は確認なしで止まり、ask は確認のダイアログが出るのを見比べました。
- smart3pm の最後の検査は、git の pre-push フック。push の直前に、手元の PC で動く
- GitLab 側(サーバ)には検査を置いていない(design/harness-server-free.md)
- ワークスペースでセッションを開くと、検査を通っていない push があれば警告を出す
- 人が端末で
git push --no-verifyを実行した
何が起こる?
- A. 検査を通らずに push される。あとでセッションを開いたときに警告が出る
- B. pre-push のフックが止め、push は失敗する
- C. GitLab 側の検査が止め、push は拒否される
- D. Claude Code の確認の画面が出て、人が決める
正解と解説(解いた後に開く)
正解 A
根拠: design/harness-server-free.md:252(git push --no-verify は素通り。事後の検知だけ)、harness/check-pushed-state.sh(ワークスペースの SessionStart で警告)
誤答: B は --no-verify がフックを飛ばすことを知らない。C は前提のサーバ側の検査を見落とし。D は Claude のセッションの外の操作だと気づいていない
プチ演習7(ハンズオンガイド)で、手元の pre-commit を --no-verify で飛ばし、GitLab の check-rules で止まるのを見ました。
答え合わせの一覧
一覧を開く(解いた後に)
| 問 | ハーネス | 正解 | 起こしたプチ演習 |
|---|---|---|---|
| Q1 | smart3pm-harness-review | A | プチ演習1 |
| Q2 | d2_harness_20260828 | B | プチ演習2 |
| Q3 | d2_harness_20260828 | C | プチ演習3 |
| Q4 | smart3pm-harness-review | C | プチ演習4 |
| Q5 | d2_harness_20260828 | A | プチ演習5 |
| Q6 | smart3pm-harness-review | D | プチ演習8 |
| Q7 | d2_harness_20260828 | D | プチ演習6 |
| Q8 | smart3pm-harness-review | C | プチ演習9 |
| Q9 | d2_harness_20260828 | B | プチ演習10 |
| Q10 | smart3pm-harness-review | A | プチ演習7 |
