Day 01: Diagnosis, Learning Methods, and Environment

Instructions

In programming and model debugging, blind prompting and repeated guessing conceal real gaps in understanding. This activity requires you to analyze an object mutation and reference problem using the Prediction-Experiment-Review cycle.

Instructions

Assessed on a POSIX shell (bash or zsh on Linux/macOS). Start in a fresh terminal where no virtual environment is active — the before-state probe must print True; record the executable and prefix paths it reports. Windows equivalents are given at the end but were not executed in this material.

python3 --version
python3 -c "import sys; print(sys.executable); print(sys.prefix); print(sys.base_prefix); print(sys.prefix == sys.base_prefix)"
mkdir venv-sandbox && cd venv-sandbox
printf 'marker\n' > marker.txt
python3 -m venv .venv
. .venv/bin/activate          # bash/zsh; cmd.exe and PowerShell differ (below)
echo "$VIRTUAL_ENV"
python -c "import sys; print(sys.executable); print(sys.prefix); print(sys.base_prefix); print(sys.prefix == sys.base_prefix)"
python -c "print(open('marker.txt').read().strip())"
python -m pip --version
deactivate
python3 -c "import sys; print(sys.executable); print(sys.prefix); print(sys.base_prefix); print(sys.prefix == sys.base_prefix)"

Expected invariants:
- python3 --version reports Python 3.12 or later before you build on it.
- In a fresh shell the before-state probe prints sys.prefix == sys.base_prefix as True; record those paths as your before-state.
- After activation, $VIRTUAL_ENV names the .venv directory, sys.executable resolves inside .venv, and sys.prefix equals the .venv path while sys.base_prefix keeps pointing at the base installation — that inequality is the isolation check. sys.executable reports the invoked path, which may be a symlink, so rely on the prefix values rather than resolving a physical executable.
- the venv interpreter itself reads marker.txt and prints marker: a Python process inside the venv still reads a file outside .venv in the working directory — interpreter/package isolation, not a filesystem sandbox.
- python -m pip --version reports pip from .venv's site-packages; python -m pip keeps pip paired with the active interpreter.
- After deactivate, the closing probe prints the same values as your recorded before-state (sys.prefix == sys.base_prefix again).

Windows equivalents (reference commands, not executed in this material): create with py -m venv .venv; activate with .venv\Scripts\Activate.ps1 (PowerShell) or .venv\Scripts\activate.bat (cmd.exe); diagnostics are $env:VIRTUAL_ENV in PowerShell, %VIRTUAL_ENV% in cmd.exe, and where.exe python in place of command -v/echo $PATH. deactivate, python -c, and the sys.prefix/sys.base_prefix checks are the same.

If no supported Python is available, follow the recorded fallback in the exercise instead of claiming the environment portion.

Scope note: a virtual environment isolates the Python interpreter and its installed packages via sys.prefix/sys.path. It is not a filesystem or security sandbox — as the venv Python's marker read shows, programs run inside it can still read your files — and it does not pin Python itself.

Instructions

Assessed task — independent: perform the whole cycle yourself in a newly created, disposable directory; never inside this project or any existing work. Do not use destructive commands (reset --hard, clean, push --force). If a commit fails because no author identity exists, set it locally inside that repository only, as shown.

mkdir git-sandbox && cd git-sandbox
git init
git config user.name "Learner"
git config user.email "[email protected]"
printf 'first line\n' > notes.txt
git status
git add notes.txt
git diff --cached
git commit -m "Add notes file"
printf 'second line\n' >> notes.txt
git status
git diff
git add notes.txt
git commit -m "Append a second line to notes"
git log --oneline
git status

Expected invariants:
- git status lists notes.txt as untracked before git add; after staging, git diff --cached shows the new lines prefixed +.
- After a modification, git status/git status --porcelain shows the file as modified-unstaged ( M), and git diff shows the unstaged change.
- git log --oneline lists both commits, newest first; the final git status reports a clean working tree.
- git config user.name/user.email without --global writes only this repository's .git/config, so your machine-wide identity is untouched.

Record each command and observed output in your log.

Optional, unassessed orientation — outside this check: you may open the Agent Tool Track page to preview which agent tool you will use later. Orientation is not part of this Independent Mastery Check and contributes no evidence to it.

Instructions

Do this unaided, with the lesson and your notes closed.
Step 1 — unaided recall (references closed): write what you recall about each of today's three threads — object references and mutation, virtual-environment isolation, and the Git modify–stage–commit cycle — without looking anything up.
Step 2 — reference check and correction: only now open the reference answers, mark where your recall was wrong or incomplete, and handle one misconception as the rubric requires. Annotate rather than overwrite your Step 1 text so the unaided attempt stays distinguishable.
Step 3 — fresh unaided check (references closed again): apply one corrected or recalled concept to a new small case — predict output on fresh code or re-derive a check — and record the result.
Step 4 — schedule a short recovery step: a specific time and trigger for re-testing the weakest items before starting Day 02.

Rubric — your log must satisfy all four items:
- at least two Day 01 concepts restated in your own words during the unaided recall step, not copied phrasing;
- either one actual misconception recorded with the concrete evidence that corrected it, or — if none was found — an explicit statement that none was found plus one plausible common misconception you reject with the evidence that justifies the rejection;
- the fresh unaided transfer/retrieval check from Step 3 with its result recorded — a bare 'everything correct' claim establishes nothing;
- one scheduled recovery step with a specific time and trigger.
Raw length is not evidence: a short log satisfying the rubric outranks a long summary.