The Brief

What changes here. Up to now each step told you what to build. This is the specification, and the how is yours.

The application. A publishing platform where people write posts, organize them with tags and categories, and read each other's work. Accounts, ownership, drafts, and a public archive.

Acceptance criteria. Every one is checkable by another person, on your deployed URL, without reading your code.

1. Anyone can read published posts, browse by tag, and by author.

2. A visitor can create an account, sign in, and sign out.

3. A signed-in person can create, edit and delete their own posts, and only their own.

4. A draft is invisible to everyone except its author and staff, on pages and through the API.

5. Every list is paginated, and paging preserves any active filter.

6. Every form validates, shows errors next to the fields, and preserves what was typed.

7. Deleting requires confirmation and happens over POST.

8. Every address is meaningful, and no template contains a hard-coded path.

9. The admin is configured well enough to run the site from.

10. Tests cover all four permission rules and pass.

11. check --deploy is clean, DEBUG is False, and no secret is in the repository.

12. It is deployed, static files are served, and a stranger can use it end to end.

✦ The order that tends to finish

Deploy something trivial on day one, before the features exist. A site that is live and half-built is in a far better position than a complete site that has never been deployed, because deployment is where the surprises are and you want to meet them early and often rather than all at once at the end.

Reviewing your own work. Leave it a day, then reread it and notice what you have to work out again. That is what needs a better name.

Then ask: is there a view here where I check permission after fetching, rather than filtering? Is there a query inside a template loop? Is there a field in a form that nobody should be able to set? Is there anything I marked safe that a person typed?

Then write the README. What it does in one sentence a non-programmer would understand, how to run it, one decision you made and why, and one thing you would do differently. That last part is what reads as an engineer rather than a student.