geneseed 4.9.4 → 4.10.0

package/CHANGELOG.md

@@ -8,6 +8,27 @@ label. For the capability ↔ spec map, see [SHIPPED.md](SHIPPED.md).
 
 ## [Unreleased]
 
+## [4.10.0] — 2026-10-20
+
+Minor: opt-in kits (and a first one, `spring-boot`), credits for adapted content, a weekly upstream-drift check, and a web Kits tab.
+
+### Upgrade notes
+- Run `geneseed rebuild-all` once after updating. Default installs are unchanged (no kit is on); enable one with `geneseed build --kits spring-boot` or the new **Installs → Kits** tab.
+
+### Added
+- **Kits: opt-in bundles of skills, agents and rules** (#343). `src/kits/<kit>.json` declares a kit; `--kits a,b` turns kits on (`none` turns all off), the install records `Active kits:` and `rebuild-all`, `update`, `migrate` and the web console keep it. A plain build warns before it drops a kit an install has; `status` lists kits and files you edited that were kept from a kit turned off. The doctor gates kit membership, links (kit → core only), registry rows and each kit's rules budget.
+- **The `spring-boot` kit** (#349), adapted from piomin/claude-ai-spring-boot (Apache-2.0) and rewritten for Spring Boot 4: skills `spring-boot`, `spring-data-jpa`, `spring-testing`; agents `spring-boot-engineer`, `spring-reviewer` and `spring-security` (both read-only), `kubernetes-specialist`, `docker-expert`, `devops-engineer`; kit rules. A banned-API gate keeps removed Boot APIs (`@MockBean`, `javax.persistence`, …) out of kit files.
+- **Credits for adapted content** (#342). `src/upstreams.json` records each upstream's repo, commit, author and licence; a `{{CREDIT:key:path}}` token renders an "Adapted from … modified." line and the skill ships the licence beside it. Superpowers, Matt Pocock's skills and vibe-wise ports are now credited; the README gains a Credits section, gated by the doctor.
+- **Weekly upstream-drift check** (#344, #351). A CI job compares every pinned upstream with its HEAD on the files Geneseed uses and keeps one tracking issue per upstream; vendored skills are compared on their folder only, and `"frozen": true` entries are skipped.
+- **Web console: Installs → Kits** (#350). One row per global and project install, a switch per kit, apply through the usual confirm and rebuild job.
+
+### Changed
+- `react-view-transitions` re-vendored at upstream HEAD (Next.js no longer needs the `experimental.viewTransition` flag; back/forward navigation and shared-element guidance updated) (#351).
+- `debug` proves a forced red landed by diffing against a pristine copy; `geneseed-code-review` searches the repo for its standards files (#351).
+
+### Fixed
+- The web install action no longer re-themes an install you are not viewing (#350).
+
 ## [4.9.4] — 2026-10-18
 
 Patch: `git reset --hard` asks only when it would abandon existing commits, not over uncommitted work.

package/README.md

@@ -367,6 +367,19 @@ Three things that bite when you don't know them:
 - **The version has one owner: `harness.config.json`.** `package.json` mirrors it and a test fails the fork. Never `npm version` — it edits one of the two.
 - **Publishing is deliberate and manual.** `.github/workflows/publish.yml` uses npm trusted publishing (OIDC); there is no `NPM_TOKEN` in this repository and there must not be one. It runs only from Actions → publish → Run workflow, and the npm-side trusted publisher is keyed on that workflow's **filename** — renaming the file breaks publishing with no local symptom, which is why the file names itself in its own header and a test asserts the two agree.
 
+## 🙏 Credits
+
+Some skills and agents are adapted from other open-source skill collections, under the MIT or Apache-2.0 licence (named on each entry below). Each adapted skill names its source in its own text, and ships that upstream's licence beside it. `src/upstreams.json` pins every upstream to a commit.
+
+- `daydream` — [glebis/claude-skills](https://github.com/glebis/claude-skills) by Gleb Kalinin (MIT): the vendored `daydream` skill.
+- `react-view-transitions` — [vercel-labs/agent-skills](https://github.com/vercel-labs/agent-skills) by Vercel Engineering (MIT): the vendored `react-view-transitions` skill.
+- `mattpocock-skills` — [mattpocock/skills](https://github.com/mattpocock/skills) by Matt Pocock (MIT): the vocabulary and procedures behind codebase-design, wayfinder, prototype, develop, handoff and research, the spec pass of geneseed-code-review, the question rounds of brainstorm, the slicing of plan, and the reproduction step of debug.
+- `mattpocock-skills-frozen` — [mattpocock/skills](https://github.com/mattpocock/skills) by Matt Pocock (MIT), pinned at 391a2701, the last commit carrying `resolving-merge-conflicts` (deleted upstream since): the merge-conflict step of git-history, from a skill upstream has since deleted, so the weekly drift check skips it.
+- `mattpocock-skills-2509` — [mattpocock/skills](https://github.com/mattpocock/skills) by Matt Pocock (MIT), a second key for the same repo, at the same pin as `mattpocock-skills` today (5beb35b0): the PR body of ship and the guardrail clause of rule.
+- `superpowers` — [obra/superpowers](https://github.com/obra/superpowers) by Jesse Vincent (MIT): the core of debug, the size step and builder check of brainstorm, the plan rules of plan, the reviewer brief behind geneseed-code-review and the reviewer agent, the review-handling steps of review-response, and the ruling format of pipeline and parallel-agents.
+- `vibe-wise` — [nykooi1/vibe-wise](https://github.com/nykooi1/vibe-wise) by Noah Kim (MIT): the state file, levels and checkpoints of learn-mode.
+- `piomin-spring-boot` — [piomin/claude-ai-spring-boot](https://github.com/piomin/claude-ai-spring-boot) by Piotr Mińkowski (Apache-2.0): the Spring Boot kit's skills and agents, rewritten and condensed for Boot 4.
+
 ## 📄 License
 
 [MIT](LICENSE) — built by [@Arylmera](https://github.com/Arylmera).

package/SHIPPED.md

@@ -20,7 +20,7 @@ historical references, not files distributed with the repo.
 > **On version numbers.** [`harness.config.json`](harness.config.json)'s `version` is a
 > human-readable label only. The canonical identity of an installed harness is the
 > **source fingerprint** stamped in `.geneseed-version` (see `geneseed version`), not the
-> string. Current label: **4.9.4**.
+> string. Current label: **4.10.0**.
 
 ## Capabilities
 

package/docs/README.md

@@ -42,7 +42,7 @@
 
 **Memory** — [Memory](concepts/memory.md) · [Notebook](concepts/notebook.md)
 
-**Configuration** — [Footprint](concepts/footprint.md) · [Themes](concepts/themes.md) · [Exclusions](concepts/exclusions.md) · [Code intelligence (LSP)](concepts/lsp.md)
+**Configuration** — [Footprint](concepts/footprint.md) · [Themes](concepts/themes.md) · [Exclusions](concepts/exclusions.md) · [Kits](concepts/kits.md) · [Code intelligence (LSP)](concepts/lsp.md)
 
 **Working together** — [Collaboration](concepts/collaboration.md) · [Foreman mode](concepts/foreman-mode.md)
 

package/docs/concepts/collaboration.md

@@ -1,6 +1,6 @@
 ---
 group: concepts
-order: 14
+order: 15
 title: "Collaboration"
 kind: "concept"
 section: "Working together"

package/docs/concepts/enforcement-table.md

@@ -1,6 +1,6 @@
 ---
 group: concepts
-order: 24
+order: 25
 title: "Rule enforcement, by host"
 kind: "concept"
 section: "Harness"

package/docs/concepts/foreman-mode.md

@@ -1,6 +1,6 @@
 ---
 group: concepts
-order: 15
+order: 16
 title: "Foreman mode"
 kind: "concept"
 section: "Working together"

package/docs/concepts/kits.md

@@ -0,0 +1,79 @@
+---
+group: concepts
+order: 13
+title: "Kits"
+kind: "concept"
+section: "Configuration"
+description: "Opt-in bundles of skills, agents and rules for one stack, off unless you name them."
+---
+A **kit** is an opt-in bundle of skills, agents and rules for one stack. Kits are off by default and switched on per install, project or global, on every host. An install without a kit pays nothing for it. Inside an install that has it on, a kit's skills and agents are ordinary: the model picks them as it picks any other.
+
+> **You already know this:** an optional dependency group, like `pip install pkg[postgres]`. The core install stays small, and you opt into the extra parts for your stack.
+
+The first kit is `spring-boot`, for Spring Boot 4 (Spring Framework 7, Java 21+) projects. It adds nine members:
+
+| Member | Kind | What it is for |
+|---|---|---|
+| `spring-boot` | skill | Building a Spring Boot service: web layer, configuration, security, HTTP clients, logging, cloud-native packaging, and a table of Boot 4 pitfalls |
+| `spring-data-jpa` | skill | Spring Data JPA and Hibernate: entities, repositories, transactions, N+1 and fetch problems, migrations |
+| `spring-testing` | skill | Spring Boot tests: slices, `MockMvcTester`, `@MockitoBean`, Testcontainers with `@ServiceConnection` |
+| `spring-boot-engineer` | agent | Implements a Spring Boot feature end to end |
+| `spring-reviewer` | agent | Framework-aware review: layering, transactions, JPA, configuration, test slices |
+| `spring-security` | agent | Security pass on a Spring Security change |
+| `kubernetes-specialist` | agent | Kubernetes manifests, probes, resources and rollout for a Spring Boot service |
+| `docker-expert` | agent | Dockerfile, layered or native image for a Spring Boot service |
+| `devops-engineer` | agent | Build and delivery pipeline, on whatever CI the project already uses |
+
+The kit is adapted from [piomin/claude-ai-spring-boot](https://github.com/piomin/claude-ai-spring-boot) by Piotr Mińkowski (Apache-2.0), rewritten and condensed for Boot 4. Each of its skill folders ships `LICENSE-piomin-spring-boot.txt`, and each agent carries a credit line.
+
+### Switching kits on and off
+
+```bash
+geneseed build --emit claude-global --kits spring-boot
+geneseed build --emit claude-global --kits none
+```
+
+`--kits` takes a comma-separated list. `none` and an empty value both mean no kits. An unknown kit name is refused with exit code 2, and the error lists the kits this Geneseed ships. `none` is reserved and can never name a kit. The flag's row is in the [CLI reference](../reference/cli.md), under `build`.
+
+A build does exactly what its flags say. A plain `build` without `--kits` therefore turns off a kit the install has on. Before it does, it warns: `this install has kit <k>; this build turns it off — pass --kits <k> to keep it`.
+
+The setup wizard asks one question listing the kits, with the install's current kits as the default. It asks it only when at least one kit exists.
+
+### What an install records
+
+An install with a kit on records it in its instructions file, under the skill section: `Active kits: spring-boot`. The line is written only when at least one kit is on. A missing line means no kits, so an install built before kits existed reads as having none.
+
+`geneseed rebuild-all`, `geneseed update` and `geneseed migrate` read the line back and rebuild with the same kits. `geneseed diff` and the web console read it too, so they compare against or rebuild that same set. `geneseed validate` does not read it: pass `--kits` to dry-run a kit build. A plain `build` does not read it; it only warns, as above. If the line names a kit this Geneseed no longer ships, the rebuild drops that kit with a notice and keeps the others. It never fails `rebuild-all`. A retired kit name is never reused for a new kit.
+
+`geneseed status` shows `kits: spring-boot` on the install's row, and `status --json` carries the same list.
+
+In the web console, **Installs → Kits** (`#/installs/kits`) lists every install (disabled ones read-only) with one switch per kit. Toggling stages the set; **Apply** asks for confirmation, then rebuilds that one install with exactly that set as a console job (replace, not replay). Files you edited in a kit that is now off are kept, and the row names them so you can delete them by hand.
+
+### What a kit adds to an install
+
+- **Its skills and agents.** They are written like any core skill or agent. The members of a kit that is off are not written at all.
+- **A Kits block in the instructions file**, after the doctrine layer. It holds each active kit's rules, the same text at either [footprint](footprint.md).
+- **Its catalogue rows**, as the last rows of the skills table and of the agents table, only where the host does not list that kind natively. The plain bundle (`--emit files`) gets both, Bob gets the agent rows (it lists skills natively), and Claude Code, OpenClaude and OpenCode get none: their instructions file keeps its pointer.
+
+`--exclude-skills` still applies: it can drop one kit skill while the rest of the kit stays on, and the exclusion wins. A kit's links to its own skills do not stop that, but a kit file's link to a core skill still protects that core skill from `--exclude-skills`, as any link from the harness does. Kit agents cannot be left out one by one. See [Exclusions](exclusions.md).
+
+### Turning a kit off
+
+Rebuild with `--kits none`, or with a list that leaves the kit out. The kit's files are removed from the install, its block and catalogue rows go, and the `Active kits:` line goes when no kit is left.
+
+A kit file you edited is kept, as with any file Geneseed wrote and you changed. `geneseed status` names it on a row of its own, `kept from inactive kit <kit>: <files>`, and `status --json` lists it under `keptKitFiles`. Delete it by hand if you no longer want it.
+
+### Kits are not doctrine packs
+
+A [doctrine pack](rules.md) is part of the constitution. Kits are not:
+
+- A kit's rules are plain text. They have no rule ids, cannot be excluded one at a time with `--exclude-rules`, and have no row in the hook ledger. No hook gate enforces them.
+- A kit is not a pack. A missing `Active packs:` line reads as every pack, but a missing `Active kits:` line reads as no kits, so an old install never turns a kit on by accident.
+
+### What a kit costs
+
+- **Hooks:** nothing. The hook binary does not read kits, so a kit adds no time to a tool call.
+- **The instructions file:** the Kits block. Each kit has its own word budget for its rules, set in its manifest and checked by `doctor`, so a kit never eats into the core ceiling.
+- **The skill listing:** one line per kit skill, every session, while the kit is on. That is the same price as a core skill.
+
+The cost of authoring one, file by file, is in [Extending](../extending.md#3bis--adding-a-kit).

package/docs/concepts/loop-branch.md

@@ -2,7 +2,7 @@
 group: concepts
 kind: "concept"
 section: "Loops"
-order: 23
+order: 24
 title: "LOOP.md, trailers and the loop branch"
 description: "The loop's state file, the trailers on every commit, the loop/* branch exemption, and the console's view."
 ---

package/docs/concepts/loop-bricks.md

@@ -2,7 +2,7 @@
 group: concepts
 kind: "concept"
 section: "Loops"
-order: 18
+order: 19
 title: "Bricks and their origins"
 description: "What a brick is, how templates wire bricks, and how project and global bricks override shipped ones."
 ---

package/docs/concepts/loop-contracts.md

@@ -2,7 +2,7 @@
 group: concepts
 kind: "concept"
 section: "Loops"
-order: 22
+order: 23
 title: "Contracts and ignored deletions"
 description: "The contract globs that always raise risk, the deletions a template ignores, and the glob dialect."
 ---

package/docs/concepts/loop-gates.md

@@ -2,7 +2,7 @@
 group: concepts
 kind: "concept"
 section: "Loops"
-order: 21
+order: 22
 title: "Human gates"
 description: "Bricks that hold for a person whatever the score, and how ok, no and amend answer them."
 ---

package/docs/concepts/loop-notes.md

@@ -2,7 +2,7 @@
 group: concepts
 kind: "concept"
 section: "Loops"
-order: 19
+order: 20
 title: "Notes and rules"
 description: "What survives an iteration in LOOP.md's notes, and the rules a template hands every brick."
 ---

package/docs/concepts/loop-risk.md

@@ -2,7 +2,7 @@
 group: concepts
 kind: "concept"
 section: "Loops"
-order: 20
+order: 21
 title: "Risk, trust and validation levels"
 description: "How a loop scores a change, the trust presets, and the silent, soft and blocking levels."
 ---

package/docs/concepts/loop-templates.md

@@ -2,7 +2,7 @@
 group: concepts
 kind: "concept"
 section: "Loops"
-order: 17
+order: 18
 title: "Loop templates"
 description: "Every shipped loop template, what it is for, and the notes that matter when you pick one."
 ---

package/docs/concepts/loops.md

@@ -2,7 +2,7 @@
 group: concepts
 kind: "concept"
 section: "Loops"
-order: 16
+order: 17
 title: "Loops"
 link: {"hash":"#/docs/loop-actions","label":"The geneseed loop actions →"}
 description: "What a loop is, the ring of bricks it runs, and how it differs from foreman mode."

package/docs/concepts/lsp.md

@@ -1,6 +1,6 @@
 ---
 group: concepts
-order: 13
+order: 14
 title: "Code intelligence (LSP, OpenCode)"
 kind: "concept"
 section: "Configuration"

package/docs/extending.md

@@ -389,10 +389,31 @@ emit leaves the prior install intact.
    never fires. Hand-run, spends model calls on your own login, not part of the suite.
 
 **A vendored skill folder** (`src/skills/<name>/SKILL.md`) is a different shape: add it to
-`VENDORED_SKILL_DIRS` (`js/hosts/native.mjs:37` — the literal is frozen in
-`tests/unit/authoring_gates.test.mjs:312`), write a `VENDOR.md` carrying `**Upstream:**`,
-`**Commit:**` (a 40-hex commit, never a moving branch) and `**License:**`, add the registry row —
-and **skip steps 2, 4, 6, 7**: the flat-spec globs only see `*.md` at the top level.
+`VENDORED_SKILL_DIRS` (`js/hosts/native.mjs:48` — the literal is frozen in
+`tests/unit/authoring_gates.test.mjs:421`), add a `src/upstreams.json` entry (`repo`, `commit` —
+a 40-hex commit, never a moving branch — `author`, `license`, and `licenseFile`, a path under
+`src/` or `null`; an optional `"frozen": true` marks text left at its pin on purpose: the weekly drift job skips it, `creditProblems` still validates it), write a `VENDOR.md` carrying `**Upstream key:** <that key>` and a
+`{{CREDIT:<key>:<upstream path>}}` line, which renders the attribution into every install (the
+folder ships its upstream's own LICENSE, so it gets no `LICENSE-<key>.txt` copy; a first-party
+folder writes `**Upstream:** this repository` and a `**License:**` instead, and has no entry),
+add the registry row — and **skip steps 2, 4, 6, 7**: the flat-spec globs only see `*.md` at the
+top level. The doctor (`vendorPinProblems`, `creditProblems`) refuses a key with no entry, an
+entry nothing credits, an entry missing `repo`/`author`/`license`, a bad commit, and a licence
+file that is missing or outside `src/`.
+
+**Porting a flat skill or an agent from another repository** is steps 1–9 plus a
+`{{CREDIT:}}` token. Only an upstream not yet in `src/upstreams.json` needs a new entry, as
+above, with the upstream's licence text at `src/licenses/<key>.txt` as its `licenseFile` (never
+`null` here; two keys from one repo may share a file); a port from a listed upstream reuses its
+key. Put
+`{{CREDIT:<key>:<upstream path>}}` on its own line under the purpose blockquote; the render turns
+it into `` *Adapted from [repo](url) (`path`) by author — license, modified.* ``, and for a skill the
+emit adds `skills/<name>/LICENSE-<key>.txt` (an agent is one file, so it gets the line only). A
+skill drawn from two upstreams carries two tokens, as `debug` does. A new entry also needs a
+`` `<key>` `` bullet under README `## 🙏 Credits` — `proseMirrorProblems` gates that list both
+ways. Do it in
+the commit that brings the text in: no gate can find an unmarked port afterwards, because nothing
+distinguishes it from first-party text.
 
 Two traps worth knowing before you write the spec:
 
@@ -435,6 +456,89 @@ because a code span is not a link. Measured on 2026-10-08, with the neutral them
 footprint: debug's SKILL.md went from 1.64k to 1.18k tokens and rule's from 2.33k to 1.83k
 (chars/4).
 
+---
+
+## 3bis — Adding a KIT
+
+A kit is an opt-in bundle of skills, agents and rules for one stack, off unless an install names
+it with `--kits` ([Kits](concepts/kits.md)). Nothing in the mechanism is specific to one stack.
+
+**The manifest is the sole writer of membership.** `src/kits/<kit>.json`:
+
+```json
+{
+  "description": "One line: what the kit is for.",
+  "skills": ["<skill>"],
+  "agents": ["<agent>"],
+  "rules": "kits/<kit>/rules.md",
+  "rulesWordBudget": 300,
+  "catalogue": {
+    "skills": ["| [<skill>]({{DIR_SKILLS}}/<skill>.md) | when to reach for it |"],
+    "agents": ["| [<agent>]({{DIR_AGENTS}}/<agent>.md) | when to delegate to it |"]
+  }
+}
+```
+
+- `banned` (optional): strings no member file may contain, in the skill and agent specs, a skill's side files (flat, `skills/<m>/*.md`) and the kit's `rules.md`; `doctor` refuses each hit, naming file and line. A line carrying `<!-- banned: ok -->` is exempt (a rule that names the construct in order to forbid it).
+
+`loadKits` (`js/build/source.mjs`) reads every `src/kits/*.json`; `src/kits/` itself never ships
+(`NOT_BUNDLED` in `js/build/render.mjs`). The members stay **flat** in `src/skills/` and
+`src/agents/`, never in a `src/kits/<kit>/skills/` folder: every host's native layer accepts only
+`skills/<x>.md` and `agents/<x>.md` and would drop a nested file silently, and every check that
+enumerates skills would miss it. `src/kits/<kit>/` holds only `rules.md`.
+
+**Per-kit cost:**
+
+1. **Each member is a skill or an agent first.** §3 applies to it, with these differences:
+   - **No row in `AGENT.md.tmpl`.** Its catalogue row, a table row of the same shape, goes in
+     the manifest's `catalogue`. With the kit on, the render inserts the skill rows as the last
+     rows of the §4 skills table (before the folder-skills list) and the agent rows at the end of
+     the §3 agents table, on a host that does not catalogue that kind natively.
+     `countTableProblems` checks the template's links and the kits' catalogue rows together
+     against the flat specs, and `kitProblems` refuses a catalogue row for a non-member.
+   - **No README badge and no `SHIPPED.md` count.** Core counts exclude kit members, so
+     skip §3 steps 6 and 7.
+   - **Still** a `DESC_<NAME>` in every theme, a `SKILL_CLASS` entry for a skill (the members are
+     flat, so `srcStems('skills')` sees them), and a `registry.json` row.
+   - **An agent's web glyph, required:** an entry in `GLYPHS`
+     (`web/src/components/AgentGlyph.jsx`), then rebuild and commit `web/dist`.
+     `web/src/__tests__/agentGlyph.test.jsx` gates every `src/agents/*.md`, kit members included.
+2. **The manifest**, above.
+3. **`src/kits/<kit>/rules.md`**, the kit's rules. The render puts it in the carrier's Kits block,
+   after §2, only while the kit is on. It is plain text, not doctrine machinery: no rule ids, no
+   per-rule exclusion, no hook-ledger row, and the same text at either footprint.
+   `doctor` holds it to the manifest's `rulesWordBudget` (300 when unset).
+4. **Membership and links.** `doctor` (`kitProblems`) refuses a member listed in two kits, a
+   core skill listed in a kit, a member with no file or no registry row, a core file that links
+   to a kit member (it would dangle in an install without the kit), and a kit file that links to
+   another kit's member. Links run kit → core only. A kit's links to its own members do not
+   protect them from `--exclude-skills`; its link to a core skill still protects that skill.
+5. **The setup wizard.** It asks its kits question only when at least one kit exists. The shipped
+   `spring-boot` kit therefore added one answer line to the stdin strings in
+   `tests/unit/wizard.test.mjs`, and the `wizard-no-kit` job holds that the question is skipped on a
+   tree with no kit.
+6. **Golden cells**: the matrix (`tests/helpers/matrix/emit.*.json`) carries kit on for `claude` and
+   `opencode`, the kit-off baseline (`kits: []`, spelled `--kits none`), and three deletion cells
+   (kit on to off). One deletion cell sets `edit` (a map of sandbox path to appended text) so a member
+   is the user's own before the kit goes off, and `sovereign` excuses it: the prune keeps it (R6).
+
+**What a kit costs an install** — what to weigh before adding one:
+
+- **Hooks: zero.** The hook binary never reads a kit, so a kit adds no time to any tool call.
+- **The carrier:** the Kits block. Each kit is measured against its own
+  `rulesWordBudget`, not the core carrier ceiling, which stays measured on core alone.
+- **The skill listing:** one description per kit skill, every session, while the kit is on.
+- **An install without the kit: nothing.** Its members are not written, and a default build
+  stays byte-identical, with no `Active kits:` line.
+
+**Retiring a kit** puts its id in `RETIRED_KIT_IDS` (`js/build/source.mjs`), with the reason
+beside it. An install whose `Active kits:` line names it drops it wherever that line is read back
+(`rebuild-all`, `update`, `migrate`, `diff`, the web console), without failing; `rebuild-all`, `update` and `migrate` print a notice. `doctor` refuses a retired id on a new kit. `none` is
+already there: `--kits none` means no kits.
+
+**Kits are not packs.** Never add a kit to `PACK_ORDER`. A missing `Active packs:` line reads as
+every pack, so a kit there would switch itself on in every install built before it existed.
+
 
 ---
 

package/docs/guides/install-scripted.md

@@ -12,7 +12,7 @@ description: "The build command to run in a script, a CI job, or a shell with no
 geneseed build --emit opencode-global --theme neutral
 ```
 
-`geneseed build` takes the same flags as the generator `geneseed-build`. `--emit` picks the host and its scope: `files`, `opencode`, `opencode-global`, `claude`, `claude-global`, `bob`, `bob-global`, `openclaude` or `openclaude-global`. A `-global` emit writes into the tool's own config directory. A project emit writes into the repo you name with `--out <repo> --root <repo>`. All the other flags (`--theme`, `--footprint`, `--posture`, `--mode`, `--trust`, `--doctrines`, `--exclude-rules`) are covered in [Choose your setup](choose-your-setup.md) and the two pages after it. `--exclude-skills` leaves skills you never use out of the install; see [Exclusions](../concepts/exclusions.md).
+`geneseed build` takes the same flags as the generator `geneseed-build`. `--emit` picks the host and its scope: `files`, `opencode`, `opencode-global`, `claude`, `claude-global`, `bob`, `bob-global`, `openclaude` or `openclaude-global`. A `-global` emit writes into the tool's own config directory. A project emit writes into the repo you name with `--out <repo> --root <repo>`. All the other flags (`--theme`, `--footprint`, `--posture`, `--mode`, `--trust`, `--doctrines`, `--exclude-rules`) are covered in [Choose your setup](choose-your-setup.md) and the two pages after it. `--exclude-skills` leaves skills you never use out of the install; see [Exclusions](../concepts/exclusions.md). `--kits <kit>` switches on an opt-in kit, and `--kits none` switches every kit off; see [Kits](../concepts/kits.md).
 
 To test a build before writing anything, use `geneseed validate` with the same flags. See [Verify](verify.md).
 

package/docs/reference/glossary.md

@@ -28,6 +28,7 @@ Every word Geneseed uses that you would not find in a general programming glossa
 | Posture | — | the relationship register the agent works in (peer, mentor, expert, assistant, artisan) | pairing style |
 | Mode | — | how work gets executed — direct (the agent works every task itself) or foreman (substantial tasks spawn an isolated pipeline) | solo vs. delegating to a sub-team |
 | Footprint | — | how much of the Rules loads inline each turn (full vs lean) | eager vs. lazy loading |
+| Kit | — | an opt-in bundle of skills, agents and rules for one stack, switched on per install with `--kits`; not a doctrine pack | an optional dependency group (`pkg[extra]`) |
 | Loop | — | a requirement worked as small, validated, committed iterations on their own branch, driven by `geneseed loop` | a state machine over a ticket's steps |
 | Iteration | — | one cycle of a loop back to its head; closes into its own commit | one sprint-of-one through a checklist |
 | Brick | — | one node of a loop graph: a prompt for one agent or skill, reporting one of a declared set of outcomes | a step in a runbook |

package/docs/web-ui.md

@@ -194,6 +194,10 @@ streams the output of background jobs and keeps their history across reloads.
     card (shown once a global install exists) manages sovereign repos — folders where every
     global harness goes dormant (hooks stay silent, the global preamble never loads);
     add or remove one here, the web mirror of `harness exclude add|remove|list`.
+- **Kits** (`#/installs/kits`) — every install (disabled ones read-only) as a card with one switch per kit.
+  Toggling only stages the set; **Apply** asks first, then rebuilds that install with
+  exactly that set as a console job. Files you edited in a kit that is now off are kept,
+  and the row lists them.
 - **Settings** (`#/settings`) — a **Console direction** picker (the visual flavour of the
   console: Cultivar, Operator, Matrix or Atlas) with a **Dashboard layout** control (Auto follows each theme's designed Status
   lens; Cultivar / Greenhouse / Operator / Journal force one regardless of skin), the

package/harness.config.json

@@ -2,5 +2,5 @@
   "_comment": "version is a human-readable release label only; the canonical identity of an installed harness is the source fingerprint stamped in .geneseed-version (see `harness version`), not this string.",
   "theme": "neutral",
   "product": "Geneseed",
-  "version": "4.9.4"
+  "version": "4.10.0"
 }

package/js/build/args.mjs

@@ -11,7 +11,8 @@ import { parseArgs as nodeParseArgs } from 'node:util';
 import { withPlatformNewlines } from '../lib/fs.mjs';
 import path from 'node:path';
 import {
-  CONFIG, discoverNames, GATE_SWITCHES, PACK_ORDER, knownRuleIds, knownSkillIds, linkedSkillIds, resolveSkillNames,
+  CONFIG, discoverNames, GATE_SWITCHES, PACK_ORDER, SRC, knownRuleIds, knownSkillIds, linkedSkillIds, loadKits,
+  resolveSkillNames, skillAliases,
 } from './source.mjs';
 // The loop engine's trust presets — the `--trust` choices. `score.mjs` imports nothing, which is
 // what lets it sit inside this module's `child_process` ban.
@@ -32,7 +33,7 @@ const EMITS = ['files', 'opencode', 'opencode-global', 'claude', 'claude-global'
 export function configDefaults() {
   const d = {
     theme: 'neutral', posture: 'peer', mode: 'direct', trust: DEFAULT_PRESET,
-    doctrines: [...PACK_ORDER], excludeRules: [], excludeSkills: [],
+    doctrines: [...PACK_ORDER], excludeRules: [], excludeSkills: [], kits: [],
   };
   if (!existsSync(CONFIG)) return d;
   try {
@@ -96,6 +97,7 @@ export function configDefaults() {
 const VALUED = {
   '--theme': 'theme', '--posture': 'posture', '--mode': 'mode', '--trust': 'trust',
   '--doctrines': 'doctrines', '--exclude-rules': 'excludeRules', '--exclude-skills': 'excludeSkills',
+  '--kits': 'kits',
   '--out': 'out', '--target': 'out', '--emit': 'emit',
   '--footprint': 'footprint', '--root': 'root', '--config-dir': 'cfgDir',
 };
@@ -196,13 +198,13 @@ function parseExcludeRules(value) {
  * through `resolveSkillNames` and leave one stderr line each; the linked refusal stays for a
  * name typed as itself.
  */
-function parseExcludeSkills(value) {
+export function parseExcludeSkills(value, src = SRC) {
   const s = value.trim();
   if (s === 'none' || s === '') return [];
-  const known = knownSkillIds();
-  const linked = linkedSkillIds();
+  const known = knownSkillIds(src);
+  const linked = linkedSkillIds(src);
   const names = s.split(',').map((x) => x.trim()).filter(Boolean);
-  const { ids, notices, unknown } = resolveSkillNames(names, { known, linked });
+  const { ids, notices, unknown } = resolveSkillNames(names, { known, linked, aliases: skillAliases(src) });
   if (unknown.length) {
     die(2, `argument --exclude-skills: unknown skill '${unknown[0]}' (choose from `
       + `${known.filter((k) => !linked.includes(k)).join(', ')}, or 'none')`);
@@ -216,6 +218,23 @@ function parseExcludeSkills(value) {
   return ids;
 }
 
+/**
+ * `--kits a,b` / `--kits none` -> the cfg's kit list, sorted and deduped for the same marker
+ * stability as `--exclude-skills`. `none` and '' mean no kits; an unknown kit is refused, naming
+ * the known ones (spec R1). No `harness.config.json` key feeds it, for `excludeSkills`' reason.
+ */
+export function parseKits(value, known = [...loadKits().keys()]) {
+  const s = value.trim();
+  if (s === 'none' || s === '') return [];
+  const names = [...new Set(s.split(',').map((x) => x.trim()).filter(Boolean))].sort();
+  const unknown = names.find((n) => !known.includes(n));
+  if (unknown) {
+    const choices = known.length ? `${known.join(', ')}, or 'none'` : "'none'";
+    die(2, `argument --kits: unknown kit '${unknown}' (choose from ${choices})`);
+  }
+  return names;
+}
+
 /**
  * `--doctrines craft,rigor` / `--doctrines none` -> the cfg's pack array.
  *
@@ -313,6 +332,7 @@ export function parseArgs(argv, defaults) {
     doctrines: defaults.doctrines,
     excludeRules: defaults.excludeRules,
     excludeSkills: defaults.excludeSkills ?? [],
+    kits: defaults.kits ?? [],
     out: 'Harness', emit: 'files', footprint: 'lean', root: null,
     syncThemes: false, validateOnly: false, verbose: false,
     ...Object.fromEntries(GATE_SWITCHES.map((g) => [g.arg, false])),
@@ -356,6 +376,7 @@ export function parseArgs(argv, defaults) {
   if (typeof args.doctrines === 'string') args.doctrines = parseDoctrines(args.doctrines);
   if (typeof args.excludeRules === 'string') args.excludeRules = parseExcludeRules(args.excludeRules);
   if (typeof args.excludeSkills === 'string') args.excludeSkills = parseExcludeSkills(args.excludeSkills);
+  if (typeof args.kits === 'string') args.kits = parseKits(args.kits);
   return args;
 }
 

package/js/build/driver.mjs

@@ -65,6 +65,7 @@ import {
 // registry to find every install it must re-emit, and a CLI verb may not reach into a driver
 // for a reader. See js/inspect/registry.mjs.
 import { registryRecord, registryRoots } from '../inspect/registry.mjs';
+import { kitsOfDir } from '../hosts/installs.mjs';
 
 // P2. `--sync-themes` crossed into its own module rather than into this file: it is 90 lines
 // of textual surgery over committed files with a corpus of its own, and it is the half of the
@@ -651,12 +652,12 @@ const PROJECT_EMITS = {
  * carry straight past the parameter default.
  */
 function axesCfg({
-  posture, mode, trust, doctrines, excludeRules, excludeSkills, ...gates
+  posture, mode, trust, doctrines, excludeRules, excludeSkills, kits, ...gates
 }) {
   return makeCfg({
     ...(posture ? { posture } : {}), ...(mode ? { mode } : {}), ...(trust ? { trust } : {}),
     ...(doctrines ? { doctrines } : {}), ...(excludeRules ? { excludeRules } : {}),
-    ...(excludeSkills ? { excludeSkills } : {}),
+    ...(excludeSkills ? { excludeSkills } : {}), ...(kits ? { kits } : {}),
     // The gate switches (`GATE_SWITCHES` keys): only an explicit `false` disarms; `null` (no
     // opinion) keeps the gate.
     ...Object.fromEntries(GATE_SWITCHES.filter((g) => gates[g.key] === false).map((g) => [g.arg, true])),
@@ -665,7 +666,7 @@ function axesCfg({
 
 export function emitProjectInto(host, {
   theme, out, root, footprint = 'full', posture = null, mode = null, trust = null,
-  doctrines = null, excludeRules = null, excludeSkills = null, ...gates
+  doctrines = null, excludeRules = null, excludeSkills = null, kits = null, ...gates
 }) {
   const emit = PROJECT_EMITS[host];
   // The axes ride the same rail into every `*Into`, and for the same reason: a drift reader
@@ -674,7 +675,7 @@ export function emitProjectInto(host, {
   // checked an all-packs render nobody asked for.
   return withPlatformNewlines(() => emit(
     axesCfg({
-      posture, mode, trust, doctrines, excludeRules, excludeSkills, ...gates }),
+      posture, mode, trust, doctrines, excludeRules, excludeSkills, kits, ...gates }),
     { theme, footprint, root }, out,
   ));
 }
@@ -689,16 +690,16 @@ export function emitProjectInto(host, {
  */
 export function buildInto({
   theme, out, footprint = 'lean', posture = null, mode = null, trust = null, doctrines = null,
-  excludeRules = null, excludeSkills = null, ...gates
+  excludeRules = null, excludeSkills = null, kits = null, ...gates
 }) {
   return withPlatformNewlines(() => build(axesCfg({
-    posture, mode, trust, doctrines, excludeRules, excludeSkills, ...gates }),
+    posture, mode, trust, doctrines, excludeRules, excludeSkills, kits, ...gates }),
     theme, out, { footprint, nativeCatalog: false }));
 }
 
 export function emitGlobalInto(host, {
   theme, out, cfgDir, footprint, posture = null, mode = null, doctrines = null, trust = null,
-  excludeRules = null, excludeSkills = null, ...gates
+  excludeRules = null, excludeSkills = null, kits = null, ...gates
 }) {
   // `build.HOSTS.get(host, build.HOSTS["opencode"])` — an unknown host falls back rather than
   // raising, because the host comes from a marker file a user can edit.
@@ -715,7 +716,7 @@ export function emitGlobalInto(host, {
   // the same scar the footprint left in `diffCollect`, one axis over each time.
   return withPlatformNewlines(() => emit(
     axesCfg({
-      posture, mode, trust, doctrines, excludeRules, excludeSkills, ...gates }),
+      posture, mode, trust, doctrines, excludeRules, excludeSkills, kits, ...gates }),
     { theme, footprint, root: null, cfgDir }, out,
   ));
 }
@@ -749,6 +750,25 @@ export function main(argv) {
   });
 }
 
+/**
+ * Spec B3: a build does what its flags say, so one without `--kits` turns off a kit the target
+ * install has on. Said BEFORE the emit rewrites the marker. The target is the emit's own: the
+ * config dir for a `-global` emit, `out` otherwise. `kitsOfDir` has already dropped a kit this
+ * checkout no longer ships, so the advice never names one `--kits` would refuse. Best-effort.
+ */
+function warnDroppedKits(args, out) {
+  try {
+    const global = args.emit.endsWith('-global');
+    const host = global ? args.emit.slice(0, -'-global'.length) : (args.emit === 'files' ? null : args.emit);
+    const target = global ? (args.cfgDir ?? HOSTS.find((h) => h.host === host).configDir()) : out;
+    for (const k of kitsOfDir(target, host).filter((x) => !args.kits.includes(x))) {
+      process.stderr.write(`[geneseed] WARN: this install has kit ${k}; this build turns it off — `
+        + `pass --kits ${k} to keep it
+`);
+    }
+  } catch { /* a warning never fails a build */ }
+}
+
 function run(argv) {
   const args = parseArgs(argv, configDefaults());
 
@@ -783,6 +803,7 @@ function run(argv) {
     args.cfgDir = resolveOut(args.cfgDir);
   }
   const cfg = makeCfg(args);
+  warnDroppedKits(args, out);
 
   // The marker directory is the emit's TARGET, which for a global emit is the config dir it
   // just rendered into and not `--out` at all — so the emit returns it rather than the