Files

T

mixeme 4d014e2f45 docs: add a review agenda and config compatibility rules

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>

2026-07-26 22:44:30 +03:00

2.3 KiB

Raw Blame History

GoSentry — instructions for Claude Code

Cross-platform desktop scheduler (Go + Fyne GUI). Single process: GUI, application service, scheduler, storage, and command runner in one binary.

Read before changing code

docs/STANDARDS.md — required. Code-quality rules and the list of intentional behavior. Do not "fix" anything listed there as intentional; if a change contradicts it, update the document in the same commit.
docs/ARCHITECTURE.md — package contracts and event flow.
docs/TESTS.md — test layout and conventions.
docs/ROADMAP.md — deliberately out of scope.

Reviewing the project

When the user asks for a review of the project (rather than of a specific diff), follow docs/REVIEW.md — it is the agenda, and the /review-project command runs the same thing. Do not improvise a checklist.

Key rules (full list in STANDARDS.md)

src/app.Service is the sole owner of job and runtime state; the UI reads it through typed events, never through shared mutable state.
User-facing errors go to dialog.ShowError or a History event — never a silent return.
Pure helpers get a unit test in the same package; fixes of severity ≥ medium get a regression test.
UI view constructors accept an injected *app.Service; app.Open() is called only from run.go.
Off-main-thread widget updates must go through fyne.Do (Fyne v2.7.4).

Build and test

CGO is required — the Fyne GUI links native libraries. On Windows the toolchain is MSYS2 UCRT64; the default shell environment here has CGO off, so set it explicitly:

$env:Path = 'C:\msys64\ucrt64\bin;' + $env:Path; $env:CGO_ENABLED = '1'

Then:

scripts\test.bat

which runs go vet ./... and go test -race ./.... Release binaries come from scripts\build-windows.bat / scripts/build-linux.sh — see docs/DEVELOPMENT.md.

Repository conventions

Commit directly to main; do not create feature branches.
Notable changes get a docs/CHANGELOG.md entry under the current version.
The window/taskbar icon comes from the gosentry.ico PE resource — regenerate it from the PNGs whenever an icon changes, not just the embedded asset.

2.3 KiB Raw Blame History