README + One-Command Run

You have a clean layout and real tests. The last mile is the part reviewers actually hit first: the README and the one command that runs the thing. A project that takes ten minutes of guessing to start feels broken even when it works. A project you can clone and run with a single line feels professional even when it is small. Same code -> wildly different impression.

The README is a contract. A reader skims it top to bottom, and they expect a predictable shape: the project's name as the title, then how to install it, then how to use it, then how to test it. Concretely, a strong README has a top-level title line (# Something), then these sections in this order:

# Triage Copilot

## Setup
pip install -e .            # editable install
cp .env.example .env        # then paste your real key into .env

## Usage
python -m triage            # the one-command run

## Tests
pytest

Order matters because a reader follows it as steps. Usage before Setup is confusing -> you cannot use what you have not installed. So you write a checker, validate_readme(text), that returns True only if a #  title appears, followed by ## Setup, then ## Usage, then ## Tests, each after the previous one. A missing section, or sections out of order, returns False. The trick: walk the lines once, keep a "cursor" of where you are, and require each section to appear at a position after the cursor.

The one-command run. Notice the ## Usage line above is a single command. That is the goal of a Makefile or justfile target like make run -> one memorable command that launches the project, so nobody has to remember the full invocation. Write make_run(name) that returns that command string for a project, e.g. python -m triage (or make run). It must embed the project name, normalized the same way as the package directory, so a different project yields a different command.

Two honest, not-graded notes for the real repo. First, secrets: the cp .env.example .env step exists because your real API key goes in .env, which you add to .gitignore and never commit. You commit only .env.example -> the shape of the config with placeholder values. Leaking a key to a public repo is the classic portfolio-project mistake. Second, deploying this: to put it online you would write a small Dockerfile (copy the repo, pip install, set the run command as the entrypoint) and push to a PaaS like Render, Railway, or Fly. That part cannot run or be graded in your browser -> it is yours to do when you publish. Press Run to validate a complete README and print the run command.