mixeme
4d014e2f45
Reviewing the project used to mean re-stating what to look at every time. docs/REVIEW.md now holds that agenda once — nine areas, each anchored to this codebase — and both entry points point at it rather than copying it: the /review-project command in .claude/commands, and a section in CLAUDE.md so a plain-language review request lands in the same place. STANDARDS.md gains a "Config file compatibility" section. The project has applied the same rule three times (Theme, JobListView, TimeoutSeconds) without ever writing it down: a new Config field is omitempty and its zero value means the previous behavior, a meaningful zero is never backfilled on load, and an unrecognised enum value reads as the default through one shared helper. With no migration step and hand-editable files, that is what keeps older configs working. Also removes docs/PLAN-compact-job-list.md, implemented in edabc57 — everything but the version bump, which now waits for the release along with the rest of the Unreleased section. .claude/settings.local.json is ignored so the shared command can be tracked without per-developer permissions. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.3 KiB
1.3 KiB
description
| description |
|---|
| Review the project as a whole against the agenda in docs/REVIEW.md |
Perform a whole-project review of GoSentry.
Read docs/REVIEW.md first — it is the agenda, and its nine sections are the areas to cover. Read docs/STANDARDS.md and docs/ARCHITECTURE.md for the rules and contracts the code is checked against.
$ARGUMENTS narrows the review when given — a package path, a file, or the name
of an agenda section. With no arguments, sweep the whole src/ tree.
Rules for the report:
- Anything listed under "Intentional behavior" in STANDARDS.md is not a finding. If you believe such an entry is now wrong, say so explicitly as a challenge to the decision rather than reporting it as a bug.
- Verify before reporting. Read the surrounding code and, where cheap, confirm the behavior with a test rather than reasoning about it alone.
- Group findings by agenda section, most severe first, each with the file and line and what would actually go wrong.
- Report honestly that a section is clean rather than inventing something for it.
- Do not fix anything during the review. Report first; apply fixes only when asked, following "What happens to the findings" in REVIEW.md.