# Your environment decision

Complete this record before you install bootcamp tools. Use facts from official documentation for your exact operating-system version and CPU architecture.

## What this worksheet teaches

> I can make, test, and explain an environment decision from constraints and evidence instead of copying somebody else's preference.

Work in this order: predict, observe, compare, decide, test, and explain. Keep your original predictions visible when evidence disproves them; the mismatch is part of what you are learning.

## 1. Your non-negotiable constraints

**Idea in plain English:** A constraint makes an option infeasible; a preference only makes one option more pleasant. Mark each item as observed, required, or preferred before comparing environments.

- Current computer and operating system:
- CPU architecture (for example, x64 or arm64):
- Available memory and free disk:
- Administrator or sudo access:
- Virtualization available and permitted:
- Reliable internet available:
- You must be able to work offline: yes / no
- Maximum workspace cost: $0 / other:
- Required workplace, accessibility, or device software:

### Exact host inventory

Complete the fields for the environment you actually selected. For a remote VM, run the inventory inside the VM rather than in Cloud Shell or your local terminal.

**Before you check:** Predict each value in a separate note. Replace no prediction with a guess presented as fact.

- Distribution or operating-system edition and exact release:
- Distribution lookup keys (`ID`, `VERSION_ID`, and `ID_LIKE`, when Linux):
- CPU architecture:
- Installed or usable memory total:
- Currently available memory:
- Workspace file-system size, available disk, usage percentage, and mount point:
- Current desktop session, installed desktop sessions, and default boot target, when Linux:
- Package manager or approved installer path:
- Administrator or non-interactive sudo result:
- Inventory date:
- Redactions applied before sharing:

**Explain it back:** Describe your support tuple—exact release, architecture, resources, package family, and privilege boundary—and explain which later software choice each fact affects.

## 2. Your option check

For every viable option, add the official source you checked and the date you checked it.

**What this teaches:** You are applying the same requirements to multiple options. A rejection must name a failed constraint; a surviving option must cite current support evidence.

### Windows + PowerShell

- Constraints it satisfies:
- Constraints it fails:
- Official support source and date:
- Risk you would need to manage:

### Windows + WSL 2

- Constraints it satisfies:
- Constraints it fails:
- Official support source and date:
- Risk you would need to manage:

### macOS

- Constraints it satisfies:
- Constraints it fails:
- Official support source and date:
- Risk you would need to manage:

### Linux

- Constraints it satisfies:
- Constraints it fails:
- Official support source and date:
- Risk you would need to manage:

### Browser or remote workspace

- Constraints it satisfies:
- Constraints it fails:
- Official support and billing sources and date:
- Risk you would need to manage:

**Explain it back:** Name one rejected option, its failed constraint, and the exact evidence that caused the rejection.

## 3. Your decision

**What this teaches:** This is a small architecture decision record. It preserves the reason, tradeoff, fallback, and revisit trigger so the choice can be reviewed later.

- Primary environment:
- Primary shell:
- Editor:
- Project file-system location:
- Why this option fits your constraints:
- Options you rejected and the failed constraint for each:
- Your fallback environment:
- The exact failure that would make you switch:
- The date you will review this decision again:

**Common trap:** Do not record only the winner. Without rejected options, risk, and a switch trigger, a reader cannot tell a deliberate decision from an accident.

## 4. Your Week 0 fit check

Run every command yourself from a new shell and paste redacted output. Never include tokens, account details, or personal absolute paths.

Before each command, write the expected result and whether it should change files. Use the command lesson on your selected environment path to read each part and interpret the result.

- [ ] `java --version` reports the required Java version, proving which runtime this new shell resolves.
- [ ] `javac --version` reports the matching compiler version, proving that the JDK—not only a runtime—is available.
- [ ] Your selected Python launcher reports the required Python version, proving which interpreter the launcher selects.
- [ ] `git --version` succeeds, proving which Git installation the shell resolves without changing a repository.
- [ ] Your project-local Python virtual environment survives a new shell, proving you can recreate the project context without accidental session state.
- [ ] Your Maven Wrapper test succeeds using the script for your shell, proving the project-owned build entry point works.
- [ ] Your workspace survives a computer restart, separating persistent setup from one terminal's state.
- [ ] Your repository contains no secrets or personal absolute paths, protecting privacy and portability.
- [ ] You recorded a feasible local or remote Docker and minikube path for the later module without installing those tools early, separating planning from premature infrastructure work.

## 5. Your decision result

**What this teaches:** Test evidence can confirm or falsify the original decision. Keep or switch because of an observed result, not because setup felt unfamiliar.

- Keep this environment / move to your fallback:
- Evidence for the result:
- One next action:

**Explain it back:** State what your evidence proves, what it does not prove, the main remaining risk, and the exact condition that activates your fallback.