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>
27 lines
1.3 KiB
Markdown
27 lines
1.3 KiB
Markdown
---
|
|
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](../../docs/REVIEW.md) first — it is the agenda, and its
|
|
nine sections are the areas to cover. Read [docs/STANDARDS.md](../../docs/STANDARDS.md)
|
|
and [docs/ARCHITECTURE.md](../../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.
|