steid

docs: report completions in terms of what the user can now do

Reports have been drifting toward what was built rather than what it enables, which is
the exact blind spot that let two previous attempts spend five milestones on plumbing
that felt like progress. Requiring the rundown makes a step with no user-visible
capability say so out loud, which is the useful signal — the first commit under this
rule would have had to admit it enables nothing yet.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

JamesPatrickGill authored 24 days agoparent02eb2e4Browse files19fbf90ea963b2cc6d7ef44586f8b726f880538e

1 file changed+12 −0

CLAUDE.md+12 −0View file

		@@ -123,6 +123,18 @@ Verify behaviour rather than asserting it. A passing unit test is not evidence t
123	123	page works; the session-cookie bug passed every test and failed silently in the
124	124	browser. Say plainly what was checked and what wasn't.
125	125
	126	+### End with what it now lets the user do
	127	+
	128	+Close every completion report with a short rundown in user terms: what can be done now
	129	+that couldn't be before, and how — the URL, the command, the thing to click.
	130	+
	131	+If the answer is "nothing yet", say so plainly, and name what is still missing
	132	+before the capability appears. A step that adds no user-visible capability is normal
	133	+and expected; going several steps without noticing is not. Two attempts died inside
	134	+plumbing that felt like progress, and this is the check against a third.
	135	+
	136	+It is a rundown of capability, not of files touched — that is the commit message's job.
	137	+
126	138	## Gotchas
127	139
128	140	- Topcoat 0.5 needs rustc ≥ 1.95. On older toolchains `cargo add topcoat` silently