第 1 日：診断、学習法と環境

模範解答および実行トレース：
1. 予測出力：
Case 1: [1, 2, 3, 4]
Case 2: [1, 2, 3, 4, 5]
Case 3: True False
2. 根本原因の分析：
- b = a により a と b は同一のオブジェクトを参照します（id(a) == id(b)）。b.append(4) による変更は同じリストに反映されるため、a の内容も更新されます。
- a + [5] は新しいリストオブジェクトを割り当てて c にバインドします。したがって a is c は False となり、a 自体は不変のまま保たれます。
3. 極小再現例 (MRE):

x = []
   y = x
   y.append(1)
   assert x == [1] and x is y  # 破壊的変更が共有参照に波及する

参考実行記録（新規シェルの bash/zsh。パスは例）：

$ python3 --version
Python 3.14.8
$ python3 -c "import sys; print(sys.executable); print(sys.prefix); ..."
/usr/bin/python3         # 開始前の状態：基底インタプリタ、venv は未有効化
/usr
/usr
True                     # 新規シェルでは prefix == base_prefix
$ mkdir venv-sandbox && cd venv-sandbox && printf 'marker\n' > marker.txt && python3 -m venv .venv
$ . .venv/bin/activate
$ echo "$VIRTUAL_ENV"
.../venv-sandbox/.venv
$ python -c "import sys; print(sys.executable); print(sys.prefix); ..."
.../venv-sandbox/.venv/bin/python   # 呼び出しパス（シンボリックリンクの可能性）— prefix で確認
.../venv-sandbox/.venv
/usr
False                    # prefix != base_prefix → インタプリタが分離
$ python -c "print(open('marker.txt').read().strip())"
marker                   # venv の Python が .venv 外のファイルを読める → ファイルシステムのサンドボックスではない
$ python -m pip --version
pip 26.2.1 from .../venv-sandbox/.venv/lib/python3.14/site-packages/pip (python 3.14)
$ deactivate
$ python3 -c "import sys; print(sys.executable); print(sys.prefix); ..."
/usr/bin/python3         # 記録した開始前の状態に戻った
/usr
/usr
True

不変条件が成り立つ理由：sys.prefix は実行中インタプリタが属する環境を、sys.base_prefix は常に基底インストールを示します。venv 内ではこの2つが異なり、これが分離の確認可能な特徴です。sys.executable は呼び出しに使われたパスを示し .venv 内のシンボリックリンクの場合があるため、確認は解決済み実行パスではなく prefix の値で行います。python -m pip は有効なインタプリタ経由で pip を解決します。$VIRTUAL_ENV と PATH の変更が有効化の機構であり、deactivate がそれを戻し、終了プローブは記録した開始前の状態と一致しなければなりません。

境界：この分離はインタプリタとパッケージに限られます — venv インタプリタ自身が .venv 外の marker.txt を読み marker を表示したとおり、ファイルシステムのサンドボックスではありません。.venv は作成に使ったインタプリタに結び付いたままです。

参考実行記録（抜粋。ハッシュや main/master 名は環境で変化）：

$ git status
... Untracked files: notes.txt            # 新規ファイル、まだ未ステージ
$ git add notes.txt && git diff --cached
+first line                              # ステージ済みの追加が見える
$ git commit -m "Add notes file"
[main (root-commit) 8bddb5d] Add notes file
$ printf 'second line\n' >> notes.txt && git status --porcelain
 M notes.txt                             # 変更済み、まだ未ステージ
$ git diff
+second line                             # 未ステージ差分が見える
$ git add notes.txt && git commit -m "Append a second line to notes"
[main a0d6969] Append a second line to notes
$ git log --oneline
a0d6969 Append a second line to notes    # 新しい順
8bddb5d Add notes file

コミットはステージ済みツリーのスナップショットに、0個以上の親コミットIDとメタデータを加えたものです（最初のルートコミットには親がありません）。git log がそのスナップショットの存在を検証します。git status は未追跡（??）、未ステージ変更（ M）、ステージ済みを区別し、git diff は未ステージ差分、git diff --cached はステージ済み差分を示します。作者情報は --global なしの git config で設定したため、この使い捨てリポジトリの .git/config にのみ存在します。git-sandbox/ 以外には触れておらず、破壊的コマンドも不要でした。

記入例（参考であり、転写用テンプレートではありません）：

第1段階 - 無支援の想起（参照資料は閉じた状態）：
- b = a は b に同じリストを参照させるので b.append は a を変える。
  a + [5] は c 用の新しいリストを作る。
- venv は分離を与える。「プログラム全体をサンドボックスする」と書いた — 誤り。
- git add はファイルをスナップショットし、commit が保存する。
第2段階 - 参照確認と修正（ここで参照資料を開く）：
誤解：仮想環境はプログラムが自分のファイルを読むのを防ぐ。
本日実際に観測した根拠：有効化した .venv の中で venv インタプリタ自身の python が
marker.txt を読み 'marker' を表示した — .venv の外だが使い捨てサンドボックス内のファイル。
venv プローブで変わったのは sys.executable/sys.prefix と pip が使う
site-packages であり、ファイルアクセスは遮断されていない。これは
インタプリタ/パッケージの分離であり、ファイルシステムのサンドボックスではない。
想起できなかった項目：python -m pip が裸の pip より推奨される理由
（推測せず正直に記録）。
第3段階 - 新たな無支援チェック（再び参照資料を閉じる）：
ノートなしの新例：d = [9]; e = d; e.append(0) — 無支援の予測：e が同じリストオブジェクトを
参照するので d == [9, 0]。その後実際に実行して [9, 0] を観測——記憶上の主張ではなく
実際の出力による確認結果である。
第4段階 - 復習ステップ：
明日 09:00、Day 02 開始前に b = a と a + [5] を記憶から再導出し、
不明なら sys.prefix != sys.base_prefix のプローブを再実行する。

ルーブリックとの自己照合：第1段階は2つの概念を独自の言い回しで再述し、第2段階は誤解1件を本日実際に観測したコマンド出力と対で記録しています（見つからなかった場合は「誤解なし」の記録と、根拠つきで棄却した一般的な誤解を書きます）。第3段階は新たな無支援チェックと結果を記録し、第4段階は日時指定の復習ステップを予定しています。「全部正しかった」だけの申告はルーブリックの証拠項目を満たしません。