Revisions, pending inputs and changelog

Load when: changing the SOP, or checking what's pending.

1. How versions work

One place for the version number: the header of CLAUDE.md.
Minor version (1.0 to 1.1): adds a rule, fills a pending slot, or clarifies wording without changing what an existing rule requires.
Major version (1.x to 2.0): changes or removes what an existing rule requires.
Adopted versions are frozen. A change makes a new version, never a silent edit. Before a major version, copy CLAUDE.md and docs/sop/ into docs/sop/archive/v<old version>/. Once git exists, a tag replaces the copy.
File names stay the same across versions, so links never need updating.
Some files are versioned separately:
definitions.md has its own versions: v0 is the draft, v1 the frozen version.
The registers in docs/research/ are dated logs that grow without a version.

You correct a rule or add one.
An adversarial review finds a rule that caused a mistake.
A pending input arrives (section 4).
Research finds a platform change that a rule depends on.
A milestone is reached:
the spec page arrives
the definitions freeze
the 4-week proof run ends
the history becomes long enough for the statistics left out of v1
A rule doesn't fit a situation. Say so in the answer, follow your instruction, and propose a revision. Never drift from the SOP silently.

Propose: give the exact before and after text, the file, the reason and the version bump. A direct instruction from you skips this step.
Apply after your yes: edit the one file that holds the rule.
Record: bump the version in CLAUDE.md and add a changelog entry with the date, version, change and reason. If the change came from you, quote your words verbatim.
Sweep: search the SOP, the skills and memory for anything that repeats or points to the changed rule, and fix it.
Memory: update or delete memories the change supersedes.

Adding a module: create docs/sop/<name>.md with a "Load when" line at the top, add a row to CLAUDE.md section 9, and log the change.

Adding a skill: create .claude/skills/<name>/SKILL.md, list it in CLAUDE.md section 9, and log the change.

Reusing this SOP in another project: these parts are general and carry over:

Everything else is specific to BlueBoost.

#	Waiting for	Blocks	From	Lands in
2	Confirmation of Claude's reading of "I have replaced onyx": Claude owns the architecture, tools and build plan, under your direction	The build-vs-buy cost basis, which becomes your review time plus AI usage instead of Onyx's hours	You	CLAUDE.md, section 2
3	Who now logs hours and expenses to SYS-2026-032 (7.5)	Cost tracking	You	data-rules.md, section 10
4	The market definition: buyers, area, services, price band	Market-forces research, the prompt library, the keyword list	You and Ammon	research.md, section 4
5	How market-forces research ranks against the proof run's Musts	Research scheduling	You	research.md, section 4
6	Metric definitions	Data collection design	A pilot run, then you and Ammon	definitions.md
7	Whether Search Console's Generative AI report can be pulled automatically	Unattended tracking of our Google AI citations (7.2)	Research	sources.md
8	Whether blueforeststudios.com is included in "Search generative AI features" in Search Console	Eligibility for AI Overviews and AI Mode	Whoever has Search Console access	events.md
9	Access to Blair and its database layout	Building 6.1 and 6.2	You	engineering.md
10	HubSpot access, for its pipeline reports and its built-in AEO feature (7.1)	Market research and the build-vs-buy decision	You	research.md and the build-vs-buy doc

When an item arrives, put it where "Lands in" says, delete its row, and log the change as a minor version.

Version	Date	Change	Why
1.0	2026-10-21	First version, built from operating-manual-review.md and your approvals of 2026-10-21	You said: "Write the SOP but make it flexible and adaptable to future revisions."
1.2	2026-10-24	Pending input #1 filled: Out of scope and Decisions copied word for word from https://blueboost.pages.dev/ into spec.md, with three conflicts with the build listed there for you to rule on. The Decisions hold no metric definitions, so #6 stays open. Pending input #11 closed: git was set up locally on 2026-10-22 and the first local commit was made on 2026-10-24 (no GitHub). engineering.md section 4 updated to match.	The task that started this session, relaying your ask: "Copy them into `docs/spec.md` with the source and date. Update pending input #1", and "Make the repository's first local commit on `main`"
1.1	2026-10-21	Pending input #1 partly filled: the spec's Definition of done and its "What done could look like" sample arrived as two screenshots and are transcribed in spec.md. Out of scope and Decisions are still missing.	You said: "I uploaded 2 new screenshots which should be commited to memory on what done looks like."