Build the System Status Console in Verified Slices

Core path: multiple sessions

This is the week where speed becomes tempting.

You have enough Python to ask an AI tool for a whole application and get something that looks impressively complete in seconds.

Do not do that.

You are going to build a multi-file System Status Console in slices small enough to inspect, test, commit, and recover independently.

AI assistance is optional. The bounded build process is not.

Freeze the specification before generation

Each simulated system has:

name
status: ONLINE / OFFLINE / MAINTENANCE
battery
temperature

Required behavior:

• add and view systems;
• search by name;
• identify low battery at <= 20;
• identify overheating at >= 80;
• save/load JSON;
• generate a summary report.

Constraints:

• Python standard library only;
• console application;
• multiple modules;
• pytest tests;
• beginner-readable code you can explain.

Use simulated data only. Do not paste credentials, private repository material, student records, or confidential information into an AI tool.

Write the boundary tests first

At minimum, define:

battery 20 → low
battery 21 → not low
temperature 79 → not overheating
temperature 80 → overheating

Add the other acceptance criteria your design needs.

Then establish a Git baseline:

git add .
git commit -m "Define system console specification"

Plan architecture without implementation

Ask an approved AI tool for an architecture proposal without code, or inspect the supplied classroom plan.

A reasonable small structure might be:

main.py
system.py
storage.py
reports.py
tests/

Reject proposals that add unrelated frameworks, databases, authentication systems, network services, or other infrastructure outside the specification.

A sophisticated-looking addition can still be scope creep.

Slice 1 — model

Implement only system.py and its tests.

Verify:

• status values;
• battery threshold;
• temperature threshold;
• readable object behavior.

Inspect the diff before committing.

Do not let this slice also redesign storage or menus.

Slice 2 — persistence

Add JSON save/load in storage.py.

Test:

create data
save
stop program
load
compare restored state

Do not let the persistence slice rewrite the model unless the model contract genuinely needs revision and you document why.

Commit when stable.

Slice 3 — reports

Add report logic.

Test:

• normal data;
• exact thresholds;
• empty collection.

If generated code becomes clever enough that you cannot explain it, simplify it.

Readable code is a project constraint, not a beginner embarrassment.

Slice 4 — main workflow

Connect the modules in main.py.

Run:

python -m pytest

Then perform one complete manual workflow.

Automated tests and manual interaction answer different questions. Use both.

Adversarial review

Try:

• duplicate names;
• empty fleet;
• exact threshold values;
• malformed save data;
• missing save file;
• unexpected status value.

Document what the program handles and what remains a known limitation.

A limitation you can name is better than a failure you pretend does not exist.

Build log

Keep a Verified Vibe Build Log containing:

specification
acceptance criteria
architecture plan
proposal rejected/revised
slice 1 diff + tests + commit
slice 2 diff + tests + commit
slice 3 diff + tests + commit
slice 4 diff + full verification
known limitations

Success evidence

The project is complete when:

• the written specification and final behavior agree;
• the full suite passes;
• each slice has a focused checkpoint;
• unrelated generated complexity was rejected;
• known limitations are documented; and
• you can explain every module that remains.

Fast generation is useful. Recoverable generation is better.