@activatus/code-standards 3.0.1 → 3.0.2

package/docs/Guides/setup.md

@@ -83,6 +83,7 @@ Then wait for the answer.
 
 - **A number is never reused.** A removed standard keeps its number in the list, marked "Removed in version N", so a project's old choices still point at the right thing.
 - **A new standard takes the number of the standard it sits closest to, plus a decimal:** a new styling standard after 11 is 11.1, then 11.2, up to 11.9. The list stays short, and nothing after it moves.
+- **A removed decimal standard keeps its number too**, marked the same way: `11.2. Removed in version N`.
 - **Skip the removed ones** when applying the standards. There is nothing to do for them.
 
 | The person says                         | Do                            |
@@ -129,6 +130,8 @@ The other standards are rules for how code is written. There is nothing to insta
 
 The project already follows the standards, and a newer version is out.
 
+**A patch keeps the same version number.** When only the last number changes, such as 3.0.0 → 3.0.1, the project's version in `AGENTS.md` stays the same, but there may still be work to do. Update the package, then read that version's **Fixes** list and do anything it asks for the project's version. Check it every time the package is updated, even when the version number has not changed.
+
 1. **Note the project's version.** Read `**Code standards version:**` in `AGENTS.md`. This is the version the code follows.
 2. **Update the package:**
 

package/docs/Standards/lint-errors.md

@@ -132,4 +132,4 @@ Nothing else is switched off. If another rule seems impossible to satisfy, the c
 
 **Work is not finished until `pnpm lint` passes.** That goes for people and AI agents alike: an agent fixes every lint error before it says a task is done.
 
-How a project makes sure of it, such as a git hook or a check that runs on every change, is the project's own choice. See [Project workflow](/Standards/agent-specs#project-workflow).
+Most projects check it automatically on every change, with a CI job that runs `pnpm lint` (often with `pnpm test` and the build) or with a git hook. Which one, if any, is the project's own choice. See [Project workflow](/Standards/agent-specs#project-workflow).

package/docs/version-history.md

@@ -24,6 +24,8 @@ sidebar_label: "Version History"
 5. **Run `pnpm lint`, `pnpm test` and the build** after each change.
 6. **Update the version number** in `AGENTS.md` once every change is done.
 
+**A patch keeps the same version number.** When only the last number changes, such as 3.0.0 → 3.0.1, the project's version in `AGENTS.md` stays the same, but there may still be work to do. Update the package, then read that version's **Fixes** list and do anything it asks for the project's version. Check it every time the package is updated, even when the version number has not changed.
+
 **When a change does not fit the project**, for example it renames a folder the project does not have, skip it. If you are not sure, ask; do not guess.
 
 ## Adding a version
@@ -36,15 +38,21 @@ Anyone changing the standards adds a version, alongside the change:
 - **If a project has nothing to do, say so.**
 - **Newest version at the top.**
 - **Work in progress goes under `## Version N — not released yet`**, with a line saying projects should not apply it yet. Changes can be added to it over time. To release it: drop "not released yet", add the **Released** date and **Updates from** line, set `package.json` to `N.0.0`, then publish.
-- **Fixing a released version** bumps only the last number: `3.0.0` → `3.0.1`. Update the version's changes in place, and list what was fixed under its **Fixes**. Projects keep the same version number in `AGENTS.md`.
+- **Fixing a released version** bumps only the last number: `3.0.0` → `3.0.1`. Update the version's changes in place, and list what was fixed under its **Fixes**. Projects keep the same version number in `AGENTS.md`. Write each fix so a project already on that version knows what to do.
 
 ---
 
 ## Version 3
 
-**Released:** 2026-10-17 · **Updates from:** version 2 · **Latest fix:** 3.0.1
+**Released:** 2026-10-17 · **Updates from:** version 2 · **Latest fix:** 3.0.2
+
+Install it with `pnpm add -D @activatus/code-standards@3.0.2`. Do change 1 first: it says which parts of the project's `AGENTS.md` are now the project's own to write.
+
+**Fixes in 3.0.2.** Nothing to do in a project:
 
-Install it with `pnpm add -D @activatus/code-standards@3.0.1`. Do change 1 first: it says which parts of the project's `AGENTS.md` are now the project's own to write.
+- The update steps say how to pick up a patch: the version number in `AGENTS.md` stays the same, so always read the version's Fixes list after updating the package.
+- A removed decimal standard keeps its number, such as `11.2. Removed in version N`.
+- [When lint must pass](/Standards/lint-errors#when-lint-must-pass) names the usual ways projects check it: a CI job or a git hook.
 
 **Fixes in 3.0.1.** If the project already applied 3.0.0, check these:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@activatus/code-standards",
-  "version": "3.0.1",
+  "version": "3.0.2",
   "description": "The Activatus code standards: the rules as Markdown, and the config files to copy. Install it so an AI agent can read the standards from node_modules.",
   "repository": {
     "type": "git",