Finish the System, Not the Fantasy

The capstone is not the moment to prove you can invent more features.

It is the moment to prove that the system you already built has a clear scope, verified behavior, understandable architecture, and an honest boundary around what it does not handle.

Define done from requirements, not exhaustion

A project is not done because:

it ran once
it looks polished
you ran out of time
an AI said the task was complete
there are many files

A useful Definition of Done connects the specification to evidence.

For example:

REQUIRED
- add a task
- complete a task
- save tasks
- reload tasks
- show pending tasks

DONE WHEN
- each required behavior has a test or explicit runtime check
- important boundary/failure cases are recorded
- setup/run/test instructions work from a clean start
- Git state contains no unexplained changes
- architecture and limitations can be explained

Freeze the feature boundary

Classify every remaining idea:

REQUIRED
OPTIONAL
OUT OF SCOPE

Suppose your task manager still has a save/load bug and somebody proposes:

user accounts
dark mode
cloud sync
AI-generated task summaries

Those features may be interesting.

They do not become required because they appeared near the deadline.

Fix the persistence contract first.

Scope freeze is an engineering decision that protects verification time.

Build a gap list from the evidence you already have

Do not start the final Unit by reading every source file from line one.

Start from claims:

Which requirements are not yet verified?
Which tests are failing?
Which important failures have never been exercised?
Which module boundaries are hard to explain?
Which setup step has not been tested from a clean environment?
Which Git changes are still unexplained?

Create a gap list:

Now your last changes have a reason to exist.

Verify the current baseline before final edits

Run the relevant project checks:

python -m pytest
git status
git diff

Also run the application through its main workflow.

Record the baseline.

If a test already fails before your last capstone change, you need to know that. Otherwise you can blame the wrong edit later.

Requirement coverage is not the same as code coverage

You may hear about code-coverage tools that report which lines executed during tests.

That can be useful, but the capstone question is more fundamental:

Do the tests and runtime checks demonstrate the behavior the project promises?

A suite could execute every line while still failing to test the exact boundary where the rule changes.

For this course, requirement-to-evidence traceability matters more than chasing a percentage.

Known limitations are part of a mature Definition of Done

Every project has limits.

Examples:

supports one local user only
expects UTF-8 JSON
no concurrent file writes
no network cache
rejects malformed records instead of repairing them
requires Python 3.x and listed dependencies

A known limitation is not automatically a defect that must be fixed before completion.

It becomes dangerous when the limitation exists but your documentation implies the system handles that case.

Remove dead ambition

Capstone cleanup can include deletion.

Look for:

• abandoned experimental files;
• unused dependencies;
• duplicate functions;
• commented-out old implementations;
• debug prints that no longer serve a diagnostic purpose;
• AI-generated helpers that nobody uses; and
• speculative features that never became part of the requirement.

Do not remove material blindly. Use Git/diff evidence so you can see what the cleanup changed.

Freeze a final verification candidate

When required gaps are closed, declare a candidate final state.

From that point, changes should be driven by failed verification or documentation/handoff defects, not by new feature ideas.

That gives you a stable target for the remaining lessons:

Lesson 2 -> build requirement/evidence package
Lesson 3 -> prepare and perform Code Defense
Lesson 4 -> run full capstone verification
Lesson 5 -> test cold-start handoff and reproducibility

Completion decision

Before moving to Lesson 2, write:

REQUIRED FEATURES COMPLETE: yes / no
FAILING REQUIRED TESTS: ...
UNVERIFIED REQUIRED CLAIMS: ...
KNOWN LIMITATIONS: ...
OPTIONAL FEATURES DEFERRED: ...

If the first line is no, your next task is not presentation design.

It is finishing the required system.