ワークスペース制限をデフォルトOFF・オプションONに変更する提案 #20

背景

書籍の全章ハンズオンを読者視点で実行した結果、ワークスペース制限（WORKSPACE_ROOT = cwd()/workspace）により以下の問題が発生しました。

• nano-codeのIssue駆動テストで、src/tools/execCommand.tsなどの修正Issueを作成したが、エージェントがワークスペース外のファイルを読み書きできず失敗
• 1.2節で言及している「Nano Code自身のソースコードを渡せば、自分自身を修正するPRを作成することも可能」が、現在の設計では実現できない
• 05-agent-demoのプロンプトでworkspace/greeting.txtと書くとworkspace/workspace/greeting.txtに二重ネストされるなど、パス指定の混乱が発生

提案

ワークスペース制限をデフォルトOFF、CLIオプションでONにする設計への変更。

# デフォルト: リポジトリルート全体が作業対象
$ bun run agent "src/tools/execCommand.tsのdescriptionを修正して"

# --workspace指定時のみ制限を有効化
$ bun run agent --workspace ./workspace "calculator.tsにテストを追加して"

書籍本文への影響

直接影響するのは2箇所のみ:

1. 4.3節のサンドボックス設計 — 「Nano Codeの活動範囲をworkspaceに限定する」がこの節の主題。パス制限のコード例が--workspaceオプション付きの動作になる
2. 8.4節の攻撃シナリオ — 「作業ディレクトリ外への書き込みが失敗する」デモは--workspace指定時の動作として説明

影響しない箇所:

• 3章（LLM API抽象化）、5章（思考ループ）、6章（CLI）、7章（GitHub Actions）の本文フローはworkspace制限に依存していない
• execCommandのホワイトリスト、承認ポリシー、bubblewrapは独立した防御層

読者の学習効果

• src/配下のnano-code自身のコードを読み書きでき、「エージェントが自分自身を修正する」体験ができる（1.2節で言及済みの体験）
• 4章・8章では--workspaceフラグを使う例としてサンドボックスの意義を説明できる
• Issue駆動で「src/が読めない」問題が起きなくなる

サポートサイトでの補足

書籍の本文は編集できないため、サポートサイト（gh-pages）で「ワークスペースをリポジトリルートに設定する方法」を補足情報として追記する。