Build your learning environment

WHAT YOU DO

1. Open the environment guide and write your non-negotiable constraints before downloading anything: host version, CPU architecture, memory, disk, permissions, virtualization, internet, offline needs, accessibility, and maximum cost.
2. Eliminate options that fail a constraint. Choose one primary environment, one shell, one project file system, and one fallback; record official support links and the date you checked them.
3. Open the separate Windows, WSL 2, macOS, Linux, or Codespaces path for your choice. Follow only that path's file-system boundary, shell syntax, official install links, commands, checkpoints, and fallback trigger.
4. Follow the path's official instructions for your exact operating system and architecture. Install Java 17 yourself, close the shell, open a new one, and verify both java and javac.
5. Install the required Python version from an official distribution. Choose the launcher that reaches that interpreter, create a project-local virtual environment, activate it, and install pytest inside it rather than globally.
6. Install or verify Git, set only the identity needed for your own commits, and choose any editor that can preserve UTF-8 text and line endings without adding personal workspace files to the repository.
7. Run each verification from the project directory in a new shell. Record the command, exact observed version, exit result, and a redacted excerpt of output.
8. Inspect Node, Docker, and PostgreSQL requirements without installing them early. Node 24 is required by Week 9; Docker and PostgreSQL may remain deferred until their modules.
9. If a check fails, read the exact message, confirm the official requirement and PATH or file-system boundary, make one bounded correction, and rerun only that check.
10. Keep the environment when every hard fit check passes. Move to your recorded fallback only when an unsupported version or architecture, unavailable privilege, insufficient future container capacity, or unacceptable remote cost remains.

WHAT YOU KEEP

• Your selected environment path, decision record, and exact observed versions
• Redacted output for java, javac, Python, Node, Docker, Git, and PostgreSQL
• One sentence explaining why project-local dependencies matter

WHAT YOU DO

1. Create java-gradebook-cli outside your private course-records repository.
2. Author a minimal pom.xml targeting Java 17 with JUnit 5. Generate the standard only-script Maven 3.9.11 Wrapper yourself.
3. Add one placeholder toolchain test, run the Wrapper test command for your shell, and add a suitable .gitignore.
4. Confirm that no tracked file contains an absolute personal path.

WHAT YOU KEEP

• A passing Maven Wrapper test run
• Your explanation of why the Wrapper is used after setup
• A clean tracked-file check with no personal absolute paths

WHAT YOU DO

1. Create a private repository for course records and a separate repository for java-gradebook-cli. Keep the project private until the privacy check passes.
2. Create a GitHub Project with Backlog, This week, In progress, and Done states.
3. Write and pin your Product Goal and Definition of Done.
4. Create your Week 1 and Week 2 Issues from the released route sheets.

WHAT YOU KEEP

• Repository and Project links kept in your private records
• A visible Product Goal and Definition of Done
• Week 1 and Week 2 backlog items with acceptance criteria

WHAT YOU DO

1. Keep progress notes, review records, AI logs, assessment material, secrets, and personal data in the private course repository.
2. Use synthetic gradebook data only in the project repository.
3. Inspect staged and tracked files plus Git history before changing the project repository to public.
4. Enable the free security features available for the visibility you choose.

WHAT YOU KEEP

• A completed privacy checklist
• A clean public-history inspection
• Confirmation that all test data is synthetic

WHAT YOU DO

1. Close assistants and generated-code tools before starting the clock.
2. Read the tested Python behavior, predict the supplied tests, then run and trace one success path and one exception path.
3. Reproduce all three functions in Java 17. Use explicit loops for the score summary.
4. Write JUnit tests for every supplied case plus one additional boundary per function.
5. Record one Python-to-Java type contrast and one error-handling contrast. Stop at 75 minutes even if work remains.

WHAT YOU KEEP

• Your prediction and two traces
• Your Java and JUnit commit in the separate project
• Passing Wrapper output or an honest incomplete-work record
• A two-minute explain-back and one Rosetta note

WHAT YOU DO

1. Open every external Week 1 and Week 2 link in a browser and record whether access remains free.
2. Choose exercise slugs without copying platform solutions into either repository.
3. Confirm that each can-do target, prerequisite, timebox, acceptance criterion, test command, and evidence location is usable in your environment.
4. Keep unseen assessment tasks sealed until their clocks begin; never store an answer key in the course or project repository.

WHAT YOU KEEP

• A dated link and free-access check
• Reviewed Week 1 and Week 2 route records
• Scheduled assessment release times and a sealed review result

WHAT YOU DO

1. Contact a potential Gate 1 reviewer and tentatively hold later review windows.
2. Complete the GitHub Actions quickstart yourself and annotate event → workflow → job → runner → steps.
3. Verify free AWS and Azure learning access. Select one possible no-cost Week 14 lab and define a strict $0 rule.
4. Do not create cloud resources, enter payment details, or let an assistant configure an account during setup.

WHAT YOU KEEP

• A reviewer contact attempt
• Your annotated GitHub Actions run graph
• A recorded provider-learning choice and $0 safety rule