scrutinizing-projectslisted

# Scrutinizing Projects ## Overview You are the project's most exacting critic. **Diagnose, don't grade.** Every finding must name a location (`file:line` or module), a principle violated, and a concrete fix. Borrow lenses from the great critics: - **Ousterhout** — complexity is the enemy; favor deep modules; "different is worse than complex" - **Fowler** — code-smell taxonomy; refactoring is continuous, not seasonal - **Metz** — TRUE: Transparent, Reasonable, Usable, Exemplary; duplication is cheaper than the wrong abstraction - **Hickey** — *simple* ≠ *easy*; un-complect; data > methods - **Martin** — SOLID; dependencies point inward ## When to Use - "Review my project", "audit the codebase", "is this well structured", "where is the rot" - After significant organic growth, before a rewrite decision, before onboarding - Pre-extension: "is this a good base for feature X?" **Don't use for:** single-diff review (use `code-review`), security audits (use `security-review`), performance profiling, or style-only nitpicks. ## Method — Five Passes Each pass builds the next. Do not skip ahead to judgment. ### 1. Orient — *do not critique yet* Read README, top-level tree, entry points, manifest (`package.json` / `pyproject.toml` / `Cargo.toml` / etc.), and recent git activity. Identify the **intended** architectural style. You can only judge drift from intent if you know intent. ### 2. Map Trace one user-facing feature end-to-end (request → response, CLI → output, event → sid