Leave the Project So Someone Else Can Trust It

Core path: 30 minutes

A project is not really finished when you can run it.

It is finished when another person can understand what it is, reproduce the environment, run the important checks, and identify the known risks without needing your memory as a dependency.

That is the final engineering habit in this course: handoff.

Imagine you disappear from the project tomorrow

Another developer receives only the repository.

They do not have your browser history.

They do not have your AI chat.

They do not remember which file you were "supposed" to run.

They do not know that the missing JSON file is intentional unless you wrote it down.

What can the repository tell them?

That question exposes weak documentation very quickly.

Run the cold-start test

Pretend the project is new to you.

From the README alone, answer:

What does this project do?
Which Python version/environment does it expect?
How do I install dependencies?
Which command starts it?
Which command runs tests?
Where does persistent data live?
What external services or fixtures exist?
What limitations should I know about?

If the README cannot answer those questions, fix the README.

Do not write a novel. Write the information the next developer actually needs.

Delete assumptions, not evidence

Your final repository should not depend on invisible local state such as:

an untracked configuration file nobody documented
packages installed globally but missing from requirements.txt
an environment folder committed by accident
absolute paths to your machine
manual data edits only you know about

Inspect:

git status

Then review the project tree.

Ask which files are source, data, generated output, environment state, or temporary artifacts.

The organization should tell a story.

Build a known-limitations section that is useful

Bad:

There may be bugs.

That is true of almost every piece of software ever written and tells nobody anything.

Better:

Known limitations
- Duplicate system names are allowed.
- Malformed JSON produces a visible validation error and must be repaired manually.
- The project uses a local fixture when the classroom network blocks the test API.
- The console UI has not been designed for screen widths below X characters.

A known limitation should describe a real boundary of the current system.

It is not a confession. It is part of the design record.

Leave a map of the architecture

Your architecture model should help the next reader answer:

Where does execution begin?
Which module owns core data/behavior?
Where does persistence happen?
Where do external requests happen?
Where are reports/UI generated?
Where do tests attach to the system?

Do not add boxes because the diagram looks empty.

If a box exists, you should be able to point to the corresponding file, object, function group, or external boundary.

Arrows need meaning too:

function call
data passed
file read/write
HTTP request/response

A diagram that cannot explain its arrows is decoration.

Build the maintenance note

Create HANDOFF.md or an equivalent section in the README:

# Project Handoff

## Current verified state
Last verified test command:
Result:

## Architecture
Entry point:
Core modules:
Storage:
External dependencies/services:

## Known limitations
- ...

## Next safe improvement
- ...

## Do not change casually
- ...

## Evidence locations
Tests:
Git history:
Requirement Matrix:
AI/build log, if used:

The phrase Next safe improvement is intentional.

Do not leave the next developer a random wishlist of ten features. Name one improvement that makes sense from the current stable state.

Do a final archaeology test

Pick one feature from the finished project.

Use only repository evidence to reconstruct:

requirement
        ↓
implementation file/function
        ↓
test or manual evidence
        ↓
Git commit/history
        ↓
current documented behavior

If one link is missing, decide whether the project needs better evidence or whether the feature should be documented differently.

The final Matrix lesson

At the beginning of the course, we used the idea that the computer in your head and the computer actually executing code are not always the same machine.

By Week 18, the same principle applies to an entire project.

The project in your memory is not the project.

The project on disk, its tests, history, dependencies, documentation, and observable behavior are the project.

The interface is one layer.

The evidence underneath it is what survives after you walk away.

Leave that evidence clean.

Run the code to see output.