The review path behind each project note
Each field note follows the same editorial discipline, but not the same wording. The point is to preserve a consistent review standard while letting each project keep its own failure modes and deployment story.
The four-pass review
1. Project boundary
What problem does the project actually solve, and what problem does it merely make easier to demo?
2. Deployment reality
What must exist before the first command: Docker, Python, GPU, ports, persistent volumes, credentials, or external APIs?
3. Verification route
What small action proves the installation is genuinely working rather than just showing a green startup screen?
4. Failure triage
When the first run fails, which layer should be checked before changing prompts, models, or configuration blindly?
Why the notes are opinionated
Open-source projects are often presented through the shortest happy path. These notes intentionally slow that down. A project can be excellent and still be the wrong choice for a small machine, a small team, or a production environment without operational ownership.