Release: working-process 0.18.0, project-memory 0.6.0, python-standards 0.4.0, salesforce-standards 0.5.0

.claude-plugin/marketplace.json

@@ -7,7 +7,7 @@
     {
       "name": "working-process",
       "source": "./plugins/working-process",
-      "description": "Spec-driven working process on top of superpowers: grilling-session, architect-session, system-designer-session, process-status and sync-rules skills, architect and plan-adversary verdict agents, architect-consult and system-designer-consult consultation agents, propagation-auditor and integrity-auditor audit agents, plus distributed process rules"
+      "description": "Spec-driven working process on top of superpowers: grilling-session, architect-session, system-designer-session, process-status, process-setup and sync-rules skills, architect and plan-adversary verdict agents, architect-consult and system-designer-consult consultation agents, propagation-auditor and integrity-auditor audit agents, plus distributed process rules"
     },
     {
       "name": "python-standards",

.claude/rules/plugin-versioning.md

@@ -30,22 +30,35 @@ paths:
   the PR body is assembled from the entries that changed.
 - Dogfooding unreleased content needs a changed version string — the
   plugin cache keys content by version. A topic branch that dogfoods a
-  plugin sets `X.Y.Z-dev.<discriminator>` on it — the issue number the
-  branch name carries, or the branch short-name when the topic has no
-  issue (e.g. `-dev.design-personas`). The suffix hangs off a version
-  above the one `develop` currently carries — never a re-suffix of a
-  version already minted. Widening the discriminator instead of minting
-  another channel keeps one channel for one purpose; the discriminator
-  only needs to be unique among parallel topics. The suffix flows into
-  develop as-is. A topic that does not dogfood never
-  touches the version. On a version-line merge conflict between parallel
-  topics, the merging topic's own `-dev.<discriminator>` wins — both
-  strings are provisional. The release PR strips every `-dev` suffix
-  while minting the final numbers; the `release-guard` workflow fails
-  any PR to master that carries a prerelease version or a changed plugin
+  plugin sets `X.Y.Z-dev.<n>.<discriminator>` on it. The discriminator
+  is the issue number the branch name carries, or the branch short-name
+  when the topic has no issue (e.g. `-dev.4.design-personas`); it only
+  needs to be unique among parallel topics. The suffix hangs off a
+  version above the one `develop` currently carries — never a re-suffix
+  of a version already minted. A topic that does not dogfood never
+  touches the version. The release PR strips every `-dev` suffix while
+  minting the final numbers; the `release-guard` workflow fails any PR
+  to master that carries a prerelease version or a changed plugin
   without a bump.
-- Prerelease grammar: `-<channel>.<discriminator>`. Defined channels:
-  `dev.<discriminator>` (topic-branch dogfooding, above) and
+- `<n>` separates the successive dogfood releases of successive topics,
+  and `develop` owns it: `n` is one above the highest `-dev.<n>.` the
+  plugin carries in develop's history, and the increment happens as a
+  topic merges. A topic takes the number optimistically when it starts
+  dogfooding and re-takes it at merge if develop moved meanwhile, which
+  is what makes two parallel topics safe — they may hold the same
+  number while unmerged, and the merge order settles it. Deriving the
+  counter from develop rather than from a topic is what gives it an
+  owner; a counter nobody owns walks backwards.
+  On a version-line merge conflict between parallel topics, the merging
+  topic's own string wins and takes the next free number — both strings
+  are provisional until merge.
+  The number is its own dot-separated identifier on purpose. Semver
+  compares numeric identifiers numerically and alphanumeric ones as
+  text, so `dev.1.x` < `dev.2.x` < `dev.10.x` sorts correctly, while
+  `dev.<n>-<slug>` would fold the number into an alphanumeric
+  identifier and sort `1 < 10 < 2`. Measured, not assumed.
+- Prerelease grammar: `-<channel>.<identifiers>`. Defined channels:
+  `dev.<n>.<discriminator>` (topic-branch dogfooding, above) and
   `rc.<n>` (release candidate — a freeze of develop dogfooded as one
   bundle when a release warrants whole-unit validation; minted by a
   release-prep commit and stripped by the release PR like any

.gitignore

@@ -1,2 +1,3 @@
 .claude/settings.local.json
 .claude/worktrees/
+__pycache__/

CLAUDE.md

@@ -27,6 +27,15 @@ happen (see the plugin-versioning rule). When an isolated workspace is
 used, its git worktree lives at `.claude/worktrees/<short-name>/` —
 one per topic branch, git-ignored.
 
+## Technical designs
+
+This repository does not get the technical-design offer by default. Its
+product is prose: a part's name is its path and behaviour is already the
+shape of the contract, so a technical design here would restate the
+design spec and the plan. The declaration switches the default offer
+off; it is not a ban. Ask for a technical design explicitly and the
+step runs as it would anywhere else.
+
 ## Authoring skills
 
 When creating or editing a skill in any plugin, use the `skill-creator`

README.md

@@ -16,7 +16,7 @@ Marketplace of [Claude Code](https://code.claude.com) plugins by Missing Bits.
 
 | Plugin | Docs | Description |
 |--------|------|-------------|
-| `working-process` | [README](plugins/working-process/README.md) | Spec-driven working process: grilling-session, architect-session, system-designer-session, process-status and sync-rules skills, architect and plan-adversary verdict agents, two verdict-free consultation agents, propagation-auditor and integrity-auditor audit agents, distributed process rules |
+| `working-process` | [README](plugins/working-process/README.md) | Spec-driven working process: grilling-session, architect-session, system-designer-session, process-status, process-setup and sync-rules skills, architect and plan-adversary verdict agents, two verdict-free consultation agents, propagation-auditor and integrity-auditor audit agents, distributed process rules |
 | `python-standards` | [README](plugins/python-standards/README.md) | Python coding standards for uv + ruff + pytest + pyright: area skills, code-review stack, plan-review checklist, distributed toolchain rule |
 | `salesforce-standards` | [README](plugins/salesforce-standards/README.md) | Salesforce coding standards for the sf CLI toolchain: area skills (Apex, Apex triggers, LWC, Flow, data/security model, legacy UI), code-review stack, plan-review checklist, distributed toolchain rule |
 | `project-memory` | [README](plugins/project-memory/README.md) | In-repo project memory: committed Team memory (`docs/memory/`) and per-user Private memory (`.claude/memory/`), with `memory-review-session`, `migrate-memory`, and `redirect-memory` skills, distributed as a Rules payload |

docs/domain/adr/0004-ceremonies-follow-the-reader.md

@@ -0,0 +1,41 @@
+---
+ticket: none
+---
+
+# A document's ceremonies follow its next reader
+
+The lifecycle rule branches between specs and plans in several places —
+when a re-review offer comes due, what a stale `integrity:` stamp means
+at a gate, who owns an unresolved verdict, how chain debt is discharged.
+Every one of those branches is binary, and none of them is really about
+the file's name. They divide documents by who reads them next. A spec is
+read next by a reader who still judges it: the plan-writer who must turn
+it into tasks, and the plan-adversary who names the origin of every
+finding it makes. A plan is read next by whoever executes it — who may
+well notice a mistake, but is promised to no reading of the plan as a
+whole.
+
+So the ceremonies a class owes follow not from the existence of a later
+reader but from what that reader is guaranteed to read. A judged
+document has one: plan-writing reads it whole to turn it into tasks, and
+the plan-adversary reads it far enough to name the origin of what it
+finds. So that class may close its review chain by an offered pair and
+may discharge the debt by declining — the risk accepted is bounded,
+since a scheduled reader still faces the part no round re-read. Nothing
+after a plan is guaranteed to read the plan whole, so that class owes a
+mandatory confirming round instead. A new document class answers these
+questions by naming its next reader rather than by negotiating each
+branch separately: the technical design is read next by the plan-writer
+and the plan-adversary, so it takes the spec's side of every one of
+them. What the class settles is what a document owes, never how many
+dispatches discharge it. A technical design owes the integrity check
+like any judged document; one audit reading it together with its design
+spec discharges that debt for both, and the reader is why — the
+plan-writer takes the two as one basis, so the question of whether that
+basis suffices is one question about a pair. The two sides are named in
+the glossary — a **judged document** against an **implementation plan**
+— and the rule's branches say which class they mean rather than which
+filename. The class is not called a design document, though three agent
+cards and the plugin README use that phrase today: a design
+spec and a technical design both carry "design" in their names, so the
+phrase reads as one of them rather than as both.