Capstone Verification & Code Defense

Core path: multiple sessions

This is the final build-and-prove phase.

Working code is necessary. It is not the whole assessment.

Your capstone must be traceable from requirement to implementation to evidence, and you must be able to explain the system without hiding behind the interface, framework, or AI tool that may have helped build it.

Freeze scope before the final push

Confirm:

REQUIRED
OPTIONAL
OUT OF SCOPE

Then record the baseline:

python -m pytest
git status
git diff

If your project uses different verification commands, record those instead or in addition.

Do not spend the final sessions inventing new features because the required system suddenly feels too ordinary. Finished and verified beats ambitious and half-broken.

Complete the Requirement Matrix

Map every required behavior to implementation and evidence:

If a required behavior has no meaningful verification evidence, the matrix is incomplete.

A screenshot of the menu is not evidence that persistence works.

Audit boundaries and edge cases

Test at least two boundary values or edge cases that matter to your project.

Examples:

exact threshold values
empty collection
missing file
invalid user selection
no search result
malformed external data

Choose cases tied to requirements, not random weird inputs merely to increase a test count.

Run one controlled failure

Create one reversible, authorized failure, such as:

• missing local data file;
• invalid supplied fixture;
• unreachable test endpoint;
• malformed input file; or
• invalid boundary input.

Record:

EXPECTED BEHAVIOR:
ACTUAL BEHAVIOR:
EVIDENCE PRODUCED:
RECOVERY OR KNOWN LIMITATION:

Do not use real credentials, private data, destructive commands, or unauthorized services for a failure drill.

Audit dependencies and AI assistance

Explain every dependency that remains in your project declaration.

If a package is unused, remove it deliberately and verify the project again.

If AI or an agent assisted the build, document:

one useful candidate contribution
one human modification
one suggestion/plan rejected
how accepted code was independently verified

If no AI was used, state that plainly. AI use is not required.

Finalize architecture and README

Your README should let another developer answer:

• what the project does;
• how to select/create the environment;
• how to install dependencies;
• how to run the program;
• how to run the tests;
• what files/modules own major responsibilities;
• what persistent/external data exists; and
• what limitations remain.

Include an architecture diagram or model showing meaningful module relationships or data flow.

If you cannot explain every box and arrow, simplify it.

Reach a clean, explainable final state

Run:

python -m pytest
git diff
git status

Resolve or explicitly document anything unexpected.

Create the final verified checkpoint using the Git workflow appropriate for your environment.

Do not blindly stage unrelated working-tree changes merely to make git status look clean.

Perform the Code Defense

Use the mode selected in Lesson 3:

Live

A teacher, mentor, or peer selects prompts and may ask follow-ups.

Recorded

Record your response to the selected prompt deck with source/test/Git evidence visible where useful.

Self-audited

Answer the selected prompts in writing and link every important claim to inspectable evidence.

All modes use the same technical criteria.

100-point capstone rubric

Appearance does not earn Code Defense points by itself.

The learner must explain the selected evidence.

Completion evidence

The capstone is complete when:

• required scope is complete;
• the Requirement Matrix is traceable;
• the suite passes or known failures are explicitly documented and justified;
• controlled-failure evidence exists;
• Git history is understandable;
• setup/run/test documentation survives the handoff check;
• architecture is explainable;
• known limitations are explicit; and
• the selected Code Defense mode has been completed with linked evidence.

The course ends the same way it began: the machine does what is actually there, not what we meant to build.