claude-code-kit 0.78.0__tar.gz → 0.80.0__tar.gz

{claude_code_kit-0.78.0 → claude_code_kit-0.80.0}/.claude-plugin/marketplace.json

@@ -11,7 +11,7 @@
       "displayName": "Claude Kit SDLC",
       "source": "./",
       "description": "Evidence-gated SDLC for Claude Code, installed as configuration (no app code, no Docker): install CLAUDE.md + .claude/ (rules, the profile's agents/skills, hooks, artifact templates) + optional .mcp.json, then run /sdlc to drive spec → review → build → test → security → ship through profile-aware quality gates with a tamper-evident gate ledger, working memory, and a self-improving learnings loop.",
-      "version": "0.78.0",
+      "version": "0.80.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

{claude_code_kit-0.78.0 → claude_code_kit-0.80.0}/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "claude-kit",
   "displayName": "Claude Kit SDLC",
-  "version": "0.78.0",
+  "version": "0.80.0",
   "description": "Evidence-gated SDLC for Claude Code, installed as configuration (no app code, no Docker). `claude-kit init` asks ordered questions and installs CLAUDE.md + .claude/ (rules, the profile's agents/skills, hooks, artifact templates) + optional .mcp.json; run /sdlc to drive spec → review → build → test → security → ship through profile-aware quality gates with a tamper-evident gate ledger, working memory, and a self-improving learnings loop.",
   "author": {
     "name": "Arjunsingh Yadav",

{claude_code_kit-0.78.0 → claude_code_kit-0.80.0}/CHANGELOG.md

@@ -4,6 +4,168 @@ All notable changes to claude-kit are documented here. The format follows
 [Keep a Changelog](https://keepachangelog.com/), and the project uses
 [semantic versioning](https://semver.org/).
 
+## [0.80.0] — 2026-08-14
+
+**Django is selectable.** The second Python framework goes live as a pure catalog change plus
+overlay content — no branch in `catalog.resolve()`, no `django-react` combo axis, no application
+code. `backend: {language: python, framework: django}` now resolves to a path-scoped overlay rule,
+six Django skills, and seven canonical commands including both migration verbs.
+
+Builds on [#85](https://github.com/ajyadav013/claude-kit/pull/85) by
+[@mohamedmenaa892-eng](https://github.com/mohamedmenaa892-eng), whose catalog flip and first draft
+of `django-patterns.md` are preserved in this branch's history.
+
+### Added
+
+- **Python/Django is a live stack** (`catalog/stacks.yaml`). Six skills install with it —
+  `django-service-patterns`, `django-rest-framework-patterns`, `django-rest-framework-packages`,
+  `django-migrations`, `django-async-patterns`, `django-react-integration` — alongside the shared
+  `api-and-interface-design`, `backend-repo-architecture`, `testing-conventions`, and
+  `dockerfile-backend`. Targets **Django 6.1**; every claim newer than the 5.2 LTS names the
+  release it landed in, so a project on the LTS can tell what does not yet apply.
+- **`django-patterns.md` overlay rule**, path-scoped to `**/*.py`: two-tier
+  `config/settings/{base,local,production}` layering with django-environ, a custom user model from
+  the first migration, the view → service → manager → model ladder, the WSGI-vs-ASGI decision
+  table, N+1 fixed in `get_queryset()`, and `makemigrations --check --dry-run` as a CI gate.
+- **Both migration command keys are populated.** `migrate` and `make_migration` were already in
+  `_BACKEND_CMD_KEYS`, but no live stack had used them — FastAPI leaves migrations to Alembic.
+  Django owns them through `manage.py`, so they now surface in the rendered `CLAUDE.md` Commands
+  block.
+- **`async-python-patterns` is deliberately absent from the Django lane.** `django-async-patterns`
+  supersedes it here (ASGI, the `a`-prefixed ORM, `CONN_MAX_AGE`), and the generic one is
+  FastAPI-owned.
+- **Tests:** `test_django_backend_is_live_and_resolves`; a `django` bucket in `_STACK_SKILLS` with
+  the arrival assertion parametrised over both Python frameworks (they are mutually exclusive
+  selections, so a single plan cannot prove both lanes); and a `django` entry in the Tier-A
+  `OVERLAY` eval whose "off" arm is **FastAPI**, not another language — that is what proves the
+  gate keys on the framework axis rather than merely on `backend_language`. `live_matrix()` is
+  catalog-driven, so Django joins the full profile × stack × scope sweep with no test edit.
+
+### Fixed
+
+- **Three transcription defects in the contributed `django-patterns.md`**: an unclosed ` ```bash `
+  fence that swallowed the end of the file, a `\Vert{}` LaTeX artifact where grep's `\|`
+  alternation belonged, and a missing trailing newline.
+
+### Not adopted (deliberately)
+
+- **A `django-react` combo stack, combo axis, or resolver branch.** The React+Django topology is
+  real, and it is exactly what `django-react-integration` documents — but a skill that
+  self-describes "when a React/SPA frontend is present" costs nothing, while a combo axis
+  multiplies the catalog by every frontend × backend pair and puts the first stack-specific branch
+  into a resolver whose whole value is being branch-free. The skill installs on the Django
+  selection alone and simply has nothing to say when there is no frontend.
+- **`django-ninja` as its own catalog framework entry.** It is async-first on Pydantic v2 and a
+  genuine alternative to DRF, so it is documented as one inside `django-rest-framework-patterns`
+  and `django-async-patterns`. A catalog entry would mean a third Python framework with its own
+  overlay rule and skill set, to serve a choice most projects make once — and make *inside* Django
+  rather than instead of it.
+- **`mcp_suggested: postgres` on the Django entry.** Added, then removed: the key is only ever set
+  on *database* entries, and Django + MongoDB is a valid selection the live matrix exercises.
+  Suggesting a database from the framework axis would be incoherent, not merely redundant.
+- **Django Channels / WebSockets beyond a pointer.** `django-async-patterns` names
+  `database_sync_to_async` and why a long-lived consumer needs it, which is the part that bites
+  people who are not otherwise doing Channels. The routing/consumer/layer surface is a topic of its
+  own and would go mostly unread by the projects installing this stack.
+- **MySQL, deployment targets, and generated application code.** Out of scope by the same rule as
+  every other stack: the kit ships configuration, never an app skeleton and never a Dockerfile it
+  did not have to.
+- **Teaching `detect.py` to recognise Django** (`manage.py` plus a `django` dependency). A
+  worthwhile heuristic, but detection is advisory and non-blocking, so it does not gate this
+  release and belongs in its own change rather than riding along with a catalog flip.
+
+## [0.79.0] — 2026-08-08
+
+**Two ways the installer could destroy a file it had no business touching, and the escape hatch
+that made the richest profile the least targeted one.** All three came out of an external audit of
+the repo. The first two are the kind of bug a scaffolder must not have: it writes into other
+people's projects, so "we only delete our own files" has to be true by construction, not by
+convention.
+
+### Fixed
+
+- **A recorded path in `init-options.json` could reach outside the project root.** The manifest
+  lives *inside* the project being upgraded, which makes it untrusted input — and `upgrade` joins
+  its `files[].path` entries onto the project root before copying, overwriting, and `unlink()`-ing
+  the result. A manifest containing `{"path": "../VICTIM.txt", "owner": "kit"}` made
+  `claude-kit upgrade` delete a file *above* the project, reporting it as
+  `- ../VICTIM.txt (orphan removed)`. `init --defaults` shared the same `_diff_actions` path.
+
+  Paths are now validated where the manifest is parsed (`models.contained_relpath`): absolute,
+  drive-qualified, and `..`-containing paths are refused, and backslashes are normalised first so a
+  Windows-style `..\..\x` cannot slip past a POSIX segment check and then be re-read as a separator
+  by `pathlib`. A rejected path surfaces through the existing corrupt-manifest route, so the
+  operator gets a `FAIL` with a remedy rather than a silent deletion. The orphan loop — the only
+  branch that deletes — additionally re-checks containment at the moment of use
+  (`upgrader._inside`), because a *symlinked* directory inside the project can make a perfectly
+  innocent relative path resolve outside it. Threat model: clone a repo, run `claude-kit upgrade`.
+
+- **`--force` silently deleted user files from kit-owned directories.** `_copy_tree` did an
+  unconditional `shutil.rmtree(dest)` before copying, and it is called on `.claude/rules/`,
+  `.claude/templates/`, `.claude/skills/<name>/` and `.claude/org-packs/<pack>/`. A hand-written
+  `.claude/rules/team-conventions.md` was gone after a `--force` re-init — no backup, no log line,
+  and no coverage from the upgrader's checksum/sidecar machinery, which only protects files the kit
+  itself recorded. The `--force` help text promised only to "overwrite existing CLAUDE.md /
+  settings.json / .mcp.json".
+
+  Files a directory-replacing install will not rewrite are now **moved** into `.claude-kit.bak-N/`
+  — the same convention `upgrade` already uses — mirroring their project-relative path, and the
+  install log names them. The backup directory is created lazily, so a fresh install and the
+  sandbox render used by merge/upgrade still produce none. Overlay and org rules are declared as
+  `also_shipped` because they are written into `.claude/rules/` *after* the core tree is replaced;
+  without that they read as user additions on every re-install, which would fill the backup with
+  kit files and tell the user their content was preserved when none of it was theirs. `--force`'s
+  help text now describes what it actually does.
+
+### Changed
+
+- **`enterprise` enumerates its skills instead of declaring `skills: all`.** `all` meant "every
+  directory under `skills/`", which made the richest profile the least targeted one: resolving
+  **Go + no frontend + no database + enterprise** installed 115 skills / 6.1 MB, among them
+  `alembic-migrations`, `fastapi-service-patterns`, `react-hook-form-zod-patterns` and
+  `dockerfile-frontend` — ~55k lines of content for stacks the project does not use, every one of
+  them competing in the skill picker. 67 skills were reachable *only* through `all`.
+
+  The 25 stack-flavored skills now ride `catalog/stacks.yaml`'s `skills:` union — the mechanism the
+  react and fastapi entries already used — so they install only when that stack is selected. No
+  files moved, no resolver change, and `resolve()` stays branch-free. That same Go selection now
+  resolves to 92 skills with **zero** stack-irrelevant ones; react + fastapi + postgres still gets
+  113. `lean ⊂ standard ⊂ enterprise` still holds, and every skill in the payload is still
+  reachable by some live selection (the two Node ones are gated behind `status: planned`, as
+  intended). This is the "stack-aware skill filter" `docs/skill-audit.md` recommended and then
+  deferred; that document now records the outcome.
+
+  **This changes what an enterprise install contains.** Adding a directory to `skills/` no longer
+  installs it by default — name it in a profile (stack-agnostic) or a `stacks.yaml` union
+  (stack-specific). Existing installs pick the new set up on `claude-kit upgrade`, which backs up
+  anything you edited.
+
+- **The corrupt-manifest message names both causes** — malformed JSON, or a path that is not
+  project-relative — since the fix differs even though the remedy (repair or re-init) does not.
+
+### Added
+
+- `tests/test_containment.py`, `tests/test_scaffold_rescue.py`, `tests/test_skill_relevance.py` —
+  regression coverage for all three, including a guard that no profile may reintroduce
+  `skills: all` and a check that enumerating orphaned no skill.
+
+### Not adopted (deliberately)
+
+- **Removing `object-oriented-design` (464 KB) and `system-design-patterns` (599 KB) from
+  enterprise.** They are interview-prep and engineering-blog digests — ~1 MB, ~17% of the payload —
+  and they are the strongest remaining argument that the skill corpus has drifted from "SDLC kit".
+  But they are stack-agnostic, so the relevance gating this release adds does not reach them, and
+  cutting them is a scope decision about what claude-kit *is*, not a bug fix. Left installed and
+  flagged; the `license-note: ideas absorbed in own words` provenance line appears 278 times across
+  them and deserves a separate look.
+- **`hooks: all`.** Kept. The hook registry is small, closed, and every hook is stack-neutral, so
+  "all of them" is a real statement of intent rather than an accident of directory creation. The
+  header comment in `profiles.yaml` now says why the token is right there and wrong for skills.
+- **Making the gate ledger tamper-evident.** `gate_history` entries are unchained, so a deleted or
+  reordered entry is undetectable, and `_blocking_findings()` reads `open_findings` from the
+  snapshot the agent itself wrote. Both are real, both are out of scope for a fix release, and
+  neither is what the ledger is currently sold as doing.
+
 ## [0.78.0] — 2026-08-08
 
 **Two decisions carried out of the 0.77.0 evaluation, one of which only half works.** Both are

{claude_code_kit-0.78.0 → claude_code_kit-0.80.0}/PKG-INFO

@@ -1,6 +1,6 @@
-Metadata-Version: 2.4
+Metadata-Version: 2.5
 Name: claude-code-kit
-Version: 0.78.0
+Version: 0.80.0
 Summary: Evidence-gated SDLC for Claude Code, installed as configuration (no app code, no Docker). Asks ordered questions and installs CLAUDE.md + .claude/ (rules, the chosen profile's agents/skills, hooks, artifact templates) + optional .mcp.json; run /sdlc to drive spec → review → build → test → security → ship through profile-aware quality gates with a tamper-evident gate ledger, working memory, and a self-improving learnings loop.
 Project-URL: Homepage, https://github.com/ajyadav013/claude-kit
 Project-URL: Repository, https://github.com/ajyadav013/claude-kit
@@ -161,8 +161,8 @@ claude-kit init --defaults      # non-interactive: React + Python/FastAPI + Post
 |------|--------------|
 | 🔁 **Pipeline & quality gates** | Gate-enforced progression — a phase advances only with zero open Critical/High/Medium findings — plus a fast-track for small changes and an anti-sycophancy `devils-advocate` pass |
 | 🤖 **Agent roster** | **29** tiered agents led by an Orchestrator that never writes code, plus per-database overlay agents and 6 org personas ([full roster](docs/agents.md)) |
-| 📐 **Rules & skills** | **25** stack-agnostic core rules + **115** context-activated skills (58 core + 57 stack-collection), pulled into context on demand |
-| 🧱 **Stacks & overlays** | A stack-agnostic core + **13** overlay rule files (React · FastAPI · Go · Postgres · Mongo) wired to your exact commands and path-scoped to load only when you touch matching files |
+| 📐 **Rules & skills** | **25** stack-agnostic core rules + **121** context-activated skills (58 core + 63 stack-collection), pulled into context on demand |
+| 🧱 **Stacks & overlays** | A stack-agnostic core + **14** overlay rule files (React · FastAPI · Django · Go · Postgres · Mongo) wired to your exact commands and path-scoped to load only when you touch matching files |
 | 🛠️ **Hooks & guards** | **20** event hooks — deterministic safety guards and advisory warnings — that no-op gracefully without `jq` |
 | 📊 **Traceability & live board** | A git-native ticket per story with a work-log and commit linkage, plus `claude-kit tickets` — a terminal chart and a browser Kanban board showing each lane's status, agent, model, tokens and elapsed time ([below](#parallel-lanes-and-the-live-ticket-board)) |
 | 📦 **Distribution & lifecycle** | Plugin **and** pip from one source, **24** ready MCP fragments (version-pinned), edit-preserving `upgrade`, and a root `AGENTS.md` at init so non-Claude agents share the same standards |
@@ -325,7 +325,7 @@ that matters most: **native gives you the agents; claude-kit gives you the gover
 | **[wshobson/agents](https://github.com/wshobson/agents)** & similar collections | Large libraries of individual subagent prompts you pick from | A smaller, opinionated set wired into a sequenced pipeline — agents are stages that hand off and block on each other, not a menu |
 | **[GitHub spec-kit](https://github.com/github/spec-kit)** | Spec-driven development as a platform: constitution → spec → tasks → analyze, plus label-driven CI stages | The same coverage-gate idea absorbed into a broader in-session lifecycle — review, security, build, test, release, and observability gates with enforced severity blocking. Complementary: their CI stages, this kit's gate depth ([details](docs/autonomous-operation.md)) |
 | **claude-flow / multi-agent runtimes** | Runtime orchestrators that *execute* swarms of agents | Portable configuration, not a running process — no daemon, no lock-in, no app code |
-| **dotfiles / `CLAUDE.md` starters** | A single rules file or settings snippet | A catalog-driven generator: resolves your stack/profile/scope into the right subset of 25 rules, 29 agents, 115 skills, gates, and hooks — kept upgradeable with your edits preserved |
+| **dotfiles / `CLAUDE.md` starters** | A single rules file or settings snippet | A catalog-driven generator: resolves your stack/profile/scope into the right subset of 25 rules, 29 agents, 121 skills, gates, and hooks — kept upgradeable with your edits preserved |
 
 **Choose claude-kit when** you want a consistent, gate-enforced autonomous-SDLC setup that's the
 same across every repo and stack, installs in seconds, and ships nothing you have to run. It is

{claude_code_kit-0.78.0 → claude_code_kit-0.80.0}/README.md

@@ -128,8 +128,8 @@ claude-kit init --defaults      # non-interactive: React + Python/FastAPI + Post
 |------|--------------|
 | 🔁 **Pipeline & quality gates** | Gate-enforced progression — a phase advances only with zero open Critical/High/Medium findings — plus a fast-track for small changes and an anti-sycophancy `devils-advocate` pass |
 | 🤖 **Agent roster** | **29** tiered agents led by an Orchestrator that never writes code, plus per-database overlay agents and 6 org personas ([full roster](docs/agents.md)) |
-| 📐 **Rules & skills** | **25** stack-agnostic core rules + **115** context-activated skills (58 core + 57 stack-collection), pulled into context on demand |
-| 🧱 **Stacks & overlays** | A stack-agnostic core + **13** overlay rule files (React · FastAPI · Go · Postgres · Mongo) wired to your exact commands and path-scoped to load only when you touch matching files |
+| 📐 **Rules & skills** | **25** stack-agnostic core rules + **121** context-activated skills (58 core + 63 stack-collection), pulled into context on demand |
+| 🧱 **Stacks & overlays** | A stack-agnostic core + **14** overlay rule files (React · FastAPI · Django · Go · Postgres · Mongo) wired to your exact commands and path-scoped to load only when you touch matching files |
 | 🛠️ **Hooks & guards** | **20** event hooks — deterministic safety guards and advisory warnings — that no-op gracefully without `jq` |
 | 📊 **Traceability & live board** | A git-native ticket per story with a work-log and commit linkage, plus `claude-kit tickets` — a terminal chart and a browser Kanban board showing each lane's status, agent, model, tokens and elapsed time ([below](#parallel-lanes-and-the-live-ticket-board)) |
 | 📦 **Distribution & lifecycle** | Plugin **and** pip from one source, **24** ready MCP fragments (version-pinned), edit-preserving `upgrade`, and a root `AGENTS.md` at init so non-Claude agents share the same standards |
@@ -292,7 +292,7 @@ that matters most: **native gives you the agents; claude-kit gives you the gover
 | **[wshobson/agents](https://github.com/wshobson/agents)** & similar collections | Large libraries of individual subagent prompts you pick from | A smaller, opinionated set wired into a sequenced pipeline — agents are stages that hand off and block on each other, not a menu |
 | **[GitHub spec-kit](https://github.com/github/spec-kit)** | Spec-driven development as a platform: constitution → spec → tasks → analyze, plus label-driven CI stages | The same coverage-gate idea absorbed into a broader in-session lifecycle — review, security, build, test, release, and observability gates with enforced severity blocking. Complementary: their CI stages, this kit's gate depth ([details](docs/autonomous-operation.md)) |
 | **claude-flow / multi-agent runtimes** | Runtime orchestrators that *execute* swarms of agents | Portable configuration, not a running process — no daemon, no lock-in, no app code |
-| **dotfiles / `CLAUDE.md` starters** | A single rules file or settings snippet | A catalog-driven generator: resolves your stack/profile/scope into the right subset of 25 rules, 29 agents, 115 skills, gates, and hooks — kept upgradeable with your edits preserved |
+| **dotfiles / `CLAUDE.md` starters** | A single rules file or settings snippet | A catalog-driven generator: resolves your stack/profile/scope into the right subset of 25 rules, 29 agents, 121 skills, gates, and hooks — kept upgradeable with your edits preserved |
 
 **Choose claude-kit when** you want a consistent, gate-enforced autonomous-SDLC setup that's the
 same across every repo and stack, installs in seconds, and ships nothing you have to run. It is

{claude_code_kit-0.78.0 → claude_code_kit-0.80.0}/catalog/profiles.yaml

@@ -3,7 +3,13 @@
 #
 # Each profile lists agents / skills / gates / hooks. `inherit: <profile>` composes on top of
 # another profile (this profile's lists are unioned with the inherited ones). The special value
-# `all` means "every available item discovered in the payload" (agents/, skills/, hooks/).
+# `all` means "every available item discovered in the payload".
+#
+# `all` is appropriate for `hooks:` — the hook registry is small, closed, and every hook is
+# stack-neutral, so "all of them" is a real statement of intent. It is NOT appropriate for
+# `skills:`: skills are numerous and many are stack-flavored, so `all` silently turned every new
+# directory in skills/ into an enterprise install and put it in the skill picker. Enumerate skills;
+# gate the stack-specific ones through catalog/stacks.yaml's `skills:` union instead.
 #
 # ORDER CONVENTION for `gates:` — gates are the one list where order is data: the resolved list
 # lands execution-ordered in stack-catalog.snapshot.yaml and `claude-kit pipeline close-gate`
@@ -128,6 +134,70 @@ profiles:
       - auditor
       - incident-responder
       - risk-classifier
-    skills: all
+    # ENUMERATED, not `all`. `skills: all` used to mean "every directory in skills/", which made the
+    # richest profile the least targeted one: a Go service with no frontend and no database still
+    # received React, FastAPI and Alembic skills — ~55k lines of content for a stack the project
+    # does not use, all of it competing in the skill picker. Everything stack-flavored now rides
+    # catalog/stacks.yaml's `skills:` union instead (installed only when that stack is selected),
+    # and what remains here is what an enterprise pipeline needs regardless of stack.
+    #
+    # Adding a skill to the payload therefore no longer installs it by default — name it in a
+    # profile (stack-agnostic) or in a stacks.yaml union (stack-specific). That is the point:
+    # membership is a decision, not a side effect of creating a directory.
+    skills:
+      # Operate / run: the stages enterprise adds over standard (pipeline-green, observability-ready).
+      - ci-cd-and-automation
+      - observability-and-logging
+      - otel-tracing
+      - grafana-dashboards-and-alerts
+      - kubectl-operations
+      - kubernetes-workload-hardening
+      - containerization-and-deployment
+      - docker-compose
+      - docker-shared
+      - gcp-cloud-run-github-actions
+      - cron-and-scheduled-jobs
+      # Design / architecture reference used by technical-architect and the auditor.
+      - design-patterns-and-conventions
+      - distributed-systems-patterns
+      - object-oriented-design
+      - system-design-patterns
+      - safety-critical-patterns
+      - multi-tenancy-patterns
+      - edge-to-service-trust-boundary
+      - auth-and-rbac
+      - api-pagination-filtering-sorting
+      - graphql-patterns
+      - redis-caching-patterns
+      - notifications-and-messaging
+      - file-export-and-reporting
+      # Change management: the auditor / risk-classifier surface.
+      - dependency-verification
+      - deprecation-and-migration
+      - modernization-and-migration
+      - library-review
+      - shell-review
+      # Data / eventing platforms.
+      - kafka-config-driven
+      - temporal-config-driven
+      - temporal-developer
+      - data-engineering-bigquery-gcs
+      - gcs-file-storage-patterns
+      # LLM-product engineering.
+      - anthropic-vertex-integration
+      - langfuse-llm-tracing
+      - llm-caching-strategies
+      - llm-gateway-and-routing
+      - llm-inference-optimization
+      - rag-and-model-tuning
+      # Delivery workflow.
+      - sprint
+      - backlog
+      - archive-sprint
+      - triage
+      - shipping-and-launch
+      - consolidate-learnings
+      - doc-consolidation
+      - playwright-verification
     gates: [spec-complete, em-approved, code-review, build-green, contract-clear, test-coverage, security-clear, pipeline-green, observability-ready, acceptance]
     hooks: all

{claude_code_kit-0.78.0 → claude_code_kit-0.80.0}/catalog/stacks.yaml

@@ -34,7 +34,25 @@ frontend:
       # frontend-specific (component/hook tests, client-side data fetching, headed-browser QA), so
       # they install only when a frontend exists. Backend testing is covered by the universal
       # test-driven-development core skill.
-      skills: [frontend-ui-engineering, component-design, ui-ux-design, unit-test, api-integration, manual-test]
+      #
+      # The library-specific patterns below follow the same rule: a project with no React frontend
+      # has no use for Zustand or TanStack Query docs, so they are gated here rather than named by a
+      # profile. This is what keeps the profiles stack-agnostic while the skills stay concrete.
+      skills:
+        - frontend-ui-engineering
+        - component-design
+        - ui-ux-design
+        - unit-test
+        - api-integration
+        - manual-test
+        - frontend-repo-architecture
+        - design-system-ops
+        - radix-tailwind-component-patterns
+        - react-hook-form-zod-patterns
+        - tanstack-react-query-patterns
+        - vitest-rtl-msw-patterns
+        - zustand-state-patterns
+        - dockerfile-frontend
       stack_dir: frontend/react
       commands:
         install: "npm install"
@@ -71,7 +89,20 @@ backend:
           label: "FastAPI"
           overlay_rules: [fastapi-patterns.md]
           overlay_agents: []
-          skills: [api-and-interface-design]
+          # Python/FastAPI-specific skills are gated here, not named by a profile: a Go or Node
+          # project has no use for Alembic migrations or Pydantic schema patterns, and shipping
+          # them anyway is what made `skills: all` install ~55k lines of irrelevant content.
+          skills:
+            - api-and-interface-design
+            - backend-repo-architecture
+            - fastapi-service-patterns
+            - pydantic-schema-patterns
+            - python-dao-and-database
+            - alembic-migrations
+            - async-python-patterns
+            - configargparse-yaml-env-layering
+            - testing-conventions
+            - dockerfile-backend
           stack_dir: backend/python/fastapi
           commands:
             install: "pip install -e '.[dev]'"
@@ -81,8 +112,37 @@ backend:
             format: "ruff format ."
         django:
           label: "Django"
-          status: planned
+          overlay_rules: [django-patterns.md]
+          overlay_agents: []
+          # Gated here for the same reason as FastAPI's list. `async-python-patterns` is
+          # deliberately absent: `django-async-patterns` supersedes it for this lane (ASGI,
+          # the a-prefixed ORM, CONN_MAX_AGE) and the generic one is FastAPI-owned.
+          skills:
+            - api-and-interface-design
+            - backend-repo-architecture
+            - django-service-patterns
+            # Two DRF skills, split by question rather than by topic: `-patterns` is how to
+            # build the layer, `-packages` is which third-party dependency to adopt (and the
+            # abandoned ones DRF's own docs still link). Keep the descriptions on that seam.
+            - django-rest-framework-patterns
+            - django-rest-framework-packages
+            - django-migrations
+            - django-async-patterns
+            - django-react-integration
+            - testing-conventions
+            - dockerfile-backend
           stack_dir: backend/python/django
+          # uv is cookiecutter-django's dependency manager and the ecosystem default as of
+          # Django 6.x. The ASGI/uvicorn variant of `dev` lives in the overlay rule, since a
+          # stack carries one canonical command per key.
+          commands:
+            install: "uv sync"
+            dev: "uv run python manage.py runserver 0.0.0.0:8000"
+            test: "uv run pytest"
+            lint: "uv run ruff check . && uv run mypy ."
+            format: "uv run ruff format ."
+            migrate: "uv run python manage.py migrate"
+            make_migration: "uv run python manage.py makemigrations"
     node:
       label: "Node.js"
       status: planned
@@ -91,6 +151,7 @@ backend:
         express:
           label: "Express"
           status: planned
+          skills: [backend-repo-architecture, node-express-service, node-objection-knex, dockerfile-backend]
           stack_dir: backend/node/express
     go:
       label: "Go"
@@ -100,7 +161,7 @@ backend:
           label: "net/http (stdlib)"
           overlay_rules: [go-patterns.md]
           overlay_agents: []
-          skills: [api-and-interface-design]
+          skills: [api-and-interface-design, backend-repo-architecture, dockerfile-backend]
           stack_dir: backend/go/net-http
           commands:
             install: "go mod download"

{claude_code_kit-0.78.0 → claude_code_kit-0.80.0}/docs/install.md

@@ -122,8 +122,8 @@ README.claude-sdlc.md
 
 - **Stack-agnostic core** — the pipeline assumes no language or framework; it never writes your app
   code and never needs Docker.
-- **13 stack overlay rule files** layer matching guidance on top — React, FastAPI, Go/net-http,
-  PostgreSQL, MongoDB — wired to your exact lint/test/build commands. Overlays are **path-scoped**
+- **14 stack overlay rule files** layer matching guidance on top — React, FastAPI, Django,
+  Go/net-http, PostgreSQL, MongoDB — wired to your exact lint/test/build commands. Overlays are **path-scoped**
   (`paths:` frontmatter) so they enter context only when Claude touches matching files; MongoDB's
   stays always-on (a document store has no reliable file signal to scope by).
 - **Installs are stack-true** — every lane offers `none` (backend-only, frontend-only, no-database

{claude_code_kit-0.78.0 → claude_code_kit-0.80.0}/docs/launch/road-to-1.0.md

@@ -14,17 +14,17 @@ This document catalogues the gaps, explains why each matters, and defines what "
 
 ### 1. Stack coverage
 
-**The gap:** Only **React**, **Python/FastAPI**, **Go/net-http**, **PostgreSQL**, and **MongoDB** have shipped overlay content (rules, agents, skills) and are selectable. **Vue**, **Svelte**, **Django**, and **Node/Express** are listed in `catalog/stacks.yaml` with `status: planned` — they appear as "coming soon" but cannot be chosen; no overlay rules exist under `templates/stacks/` for them.
+**The gap:** Only **React**, **Python/FastAPI**, **Python/Django**, **Go/net-http**, **PostgreSQL**, and **MongoDB** have shipped overlay content (rules, agents, skills) and are selectable. **Vue**, **Svelte**, and **Node/Express** are listed in `catalog/stacks.yaml` with `status: planned` — they appear as "coming soon" but cannot be chosen; no overlay rules exist under `templates/stacks/` for them.
 
-**Why it matters:** A stack-agnostic scaffolder that only supports five stacks is misleading. The current catalog is honest (planned entries are marked and gates block their selection), but a 1.0 should either ship the common stacks or prune the planned list to reflect realistic scope.
+**Why it matters:** A stack-agnostic scaffolder that only supports six stacks is misleading. The current catalog is honest (planned entries are marked and gates block their selection), but a 1.0 should either ship the common stacks or prune the planned list to reflect realistic scope.
 
 **What "done" looks like:**
 
 - The standard web/API combinations (React/Vue/Svelte × FastAPI/Django/Express × Postgres/MongoDB) are selectable and have overlay rules that pass the `pytest` profile × stack × scope matrix, OR
 - The planned entries are removed from the catalog with a documented rationale (e.g., "focused on React + Python/Go; other frameworks via generic core rules only"), OR
-- A documented hybrid: React + Python/Go + Postgres/MongoDB are first-class (full overlays); Vue/Svelte/Django/Express remain planned and are explicitly listed as future additions with a public tracker.
+- A documented hybrid: React + Python/Go + Postgres/MongoDB are first-class (full overlays); Vue/Svelte/Express remain planned and are explicitly listed as future additions with a public tracker.
 
-Current status: **5 of 9** catalogued stacks are live.
+Current status: **6 of 9** catalogued stacks are live (Django shipped in 0.80.0).
 
 ### 2. Enforcement honesty: agent protocols vs. mechanical gates
 
@@ -115,7 +115,7 @@ Current status: `upgrade` preserves edits and is convergent; the `init-options.j
 
 ### 7. Test and CI surface: keep the matrix green and grow it as stacks land
 
-**The gap:** The `pytest` suite runs a **profile × stack × scope self-test matrix** — it scaffolds into temp directories, asserts the no-Docker invariant, checks profile subset inclusion, validates MCP gating, and verifies upgrade safety. The test surface is solid; it needs to **grow as stacks are added** (currently React, Python/FastAPI, Go/net-http, Postgres, Mongo are tested; Vue/Svelte/Django/Express will need tests when they ship).
+**The gap:** The `pytest` suite runs a **profile × stack × scope self-test matrix** — it scaffolds into temp directories, asserts the no-Docker invariant, checks profile subset inclusion, validates MCP gating, and verifies upgrade safety. The test surface is solid; it needs to **grow as stacks are added** (currently React, Python/FastAPI, Python/Django, Go/net-http, Postgres, Mongo are tested; Vue/Svelte/Express will need tests when they ship).
 
 **Why it matters:** A green CI suite that only tests five stacks is insufficient when the catalog advertises nine. Each new stack overlay must be mechanically verified to not leak Docker/app-code and to compose with all three profiles.
 
@@ -129,7 +129,7 @@ Current status: `upgrade` preserves edits and is convergent; the `init-options.j
   - Upgrade convergence (run `upgrade` twice; second is a no-op).
 - A `CONTRIBUTING.md` note that states: "Adding a stack requires a pytest case; CI will fail without it."
 
-Current status: the pytest self-test matrix (`tests/_helpers.py::live_matrix`) sweeps every live stack combination — React × {FastAPI, Go/net-http} × {Postgres, MongoDB} — across all three profiles (lean/standard/enterprise) and the team + organization scopes, install-and-validating each. All five live stacks are exercised. CI is green. No Vue/Svelte/Django/Express tests (those stacks are planned but not shipped).
+Current status: the pytest self-test matrix (`tests/_helpers.py::live_matrix`) sweeps every live stack combination — React × {FastAPI, Django, Go/net-http} × {Postgres, MongoDB} — across all three profiles (lean/standard/enterprise) and the team + organization scopes, install-and-validating each. All six live stacks are exercised; `live_matrix` is catalog-driven, so a stack joins the sweep the moment it goes live. CI is green. No Vue/Svelte/Express tests (those stacks are planned but not shipped).
 
 ---
 
@@ -148,7 +148,7 @@ Being honest about scope is as important as closing gaps. A 1.0 release will **n
 
 Contributions that close the above gaps are welcome. High-value areas:
 
-1. **Ship the planned stacks** (Vue, Svelte, Django, Node/Express) — overlay rules + pytest case. See [`CONTRIBUTING.md`](../../CONTRIBUTING.md).
+1. **Ship the planned stacks** (Vue, Svelte, Node/Express) — overlay rules + pytest case. See [`CONTRIBUTING.md`](../../CONTRIBUTING.md).
 2. **Capture more real runs** across stacks/profiles/scopes. Run `/sdlc` on a real feature, then `scripts/capture-sdlc-run.sh`. Document the provenance (stack, profile, verdict, defect if any). See [`docs/capture-a-real-run.md`](../capture-a-real-run.md).
 3. **Improve hook portability** — pure-Python guard equivalents or a bundled minimal JSON parser for Windows.
 4. **Expand mechanical enforcement** — parse test-runner output (exit codes, JUnit XML, coverage JSON) and merge it with agent verdicts.
@@ -156,7 +156,7 @@ Contributions that close the above gaps are welcome. High-value areas:
 
 Issues tracking these gaps (map 1:1 to the numbered gaps above):
 
-1. Ship the planned stacks — [Vue #67](https://github.com/ajyadav013/claude-kit/issues/67) · [Svelte #68](https://github.com/ajyadav013/claude-kit/issues/68) · [Django #69](https://github.com/ajyadav013/claude-kit/issues/69) · [Express #70](https://github.com/ajyadav013/claude-kit/issues/70)
+1. Ship the planned stacks — [Vue #67](https://github.com/ajyadav013/claude-kit/issues/67) · [Svelte #68](https://github.com/ajyadav013/claude-kit/issues/68) · [Express #70](https://github.com/ajyadav013/claude-kit/issues/70) *(Django [#69](https://github.com/ajyadav013/claude-kit/issues/69) shipped in 0.80.0)*
 2. [Capture three real /sdlc runs across stacks/profiles/scopes — #72](https://github.com/ajyadav013/claude-kit/issues/72)
 3. [Improve hook portability (Windows, pure-Python guards) — #73](https://github.com/ajyadav013/claude-kit/issues/73)
 4. [Expand mechanical gate enforcement (parse test-runner output) — #74](https://github.com/ajyadav013/claude-kit/issues/74)

{claude_code_kit-0.78.0 → claude_code_kit-0.80.0}/docs/launch/seed-issues.md

@@ -96,10 +96,15 @@ Medium. Requires understanding the Svelte ecosystem (Svelte 4/5, TypeScript, Sve
 
 ---
 
-## Issue 3: Add Django Stack Overlay (Backend, Python)
+## Issue 3: Add Django Stack Overlay (Backend, Python) — ✅ SHIPPED in 0.80.0
 
 **Labels:** `good first issue`, `stack`, `help wanted`
 
+> **Closed.** Django went live in 0.80.0: the catalog entry dropped `status: planned`,
+> `templates/stacks/backend/python/django/rules/django-patterns.md` ships as a path-scoped overlay
+> rule, and six `django-*` skills install with the stack. The original brief is kept below as the
+> template for the remaining stack issues.
+
 ### Context
 
 Django is a planned backend framework for Python (marked `status: planned` in `catalog/stacks.yaml`, line 70). The catalog entry exists with `stack_dir: backend/python/django`, but there is no overlay content yet, so it cannot be selected during `claude-kit init`.

{claude_code_kit-0.78.0 → claude_code_kit-0.80.0}/docs/skill-audit.md

@@ -8,6 +8,11 @@ This document analyzes claude-kit's skill inventory — classification, sizing,
 **Version audited:** 0.57.0
 **Total skills on disk:** 111 (58 core + 53 stack-collection)
 
+> **Snapshot, not current state.** The figures and lane list below describe 0.57.0. Since then the
+> inventory has grown to 121 skills (58 core + 63 stack-collection) and **Python/Django went live
+> in 0.80.0** — so where this audit lists Django among the `status: planned` stacks, read that as
+> what was true when it was written. The analysis and its conclusions are unchanged.
+
 ---
 
 ## Method
@@ -62,7 +67,22 @@ Measured on a `react + fastapi + postgres` project with `--scope individual`:
 
 ## Finding: Enterprise Over-Install of Stack-Collection Skills
 
-The enterprise profile uses `skills: all` in `catalog/profiles.yaml`, which installs **every skill in the payload** — including all 51 stack-collection skills, regardless of whether the project selected those stacks.
+> **Status: resolved.** `skills: all` is gone. The enterprise profile now enumerates its skills, and
+> the stack-flavored ones are gated through `catalog/stacks.yaml`'s `skills:` union — the
+> "stack-aware skill filter" this audit recommended below, built on the mechanism the react and
+> fastapi stacks already used rather than a new `stack-relevant` token. Measured after the change:
+>
+> | selection | skills | on-disk |
+> |---|---|---|
+> | enterprise, react + fastapi + postgres | 113 | ~5.6 MB |
+> | enterprise, Go, no frontend, no database | 92 | ~4.6 MB |
+>
+> The Go project no longer receives React, FastAPI, Alembic, Pydantic, Zustand or TanStack content
+> — 0 stack-irrelevant skills, down from 32. `tests/test_skill_relevance.py` pins this, including a
+> guard that no profile may reintroduce `skills: all`. The rest of this section is the original
+> finding, kept as the record of why the change was made.
+
+The enterprise profile used `skills: all` in `catalog/profiles.yaml`, which installed **every skill in the payload** — including all 51 stack-collection skills, regardless of whether the project selected those stacks.
 
 **Impact:**
 
@@ -107,7 +127,7 @@ The following skills are candidates for **review** (not deletion). They plausibl
 
 ## Recommendations
 
-### Default (this audit takes)
+### Default (this audit took) — since superseded
 
 **Leave `catalog/profiles.yaml` as-is and document the trade-off.**
 
@@ -115,6 +135,14 @@ The following skills are candidates for **review** (not deletion). They plausibl
 - The on-demand activation model bounds the context cost of the extra files.
 - Document the enterprise skill footprint in the profile description so the trade-off is visible before a user picks it.
 
+> **Superseded.** Option 1 below ("stack-aware skill filter") was implemented instead, in the form
+> the constraints already allowed: no new `stack-relevant` token and no resolver change — the
+> stack-flavored skills simply moved into the `skills:` unions in `catalog/stacks.yaml` that the
+> react and fastapi entries were already using, and enterprise enumerates the rest. The
+> "deliberate choice for multi-stack orgs" argument did not survive contact with the numbers: the
+> cost fell on every *single*-stack enterprise user, which is most of them, and a multi-stack org
+> can still name any skill it wants in a profile.
+
 ### Optional (recommend evaluating, not implemented here)
 
 **Evaluate a config-level opt-in that installs only stack-relevant collection skills.**

{claude_code_kit-0.78.0 → claude_code_kit-0.80.0}/docs/stack-skills/GAP-ANALYSIS.md

@@ -84,7 +84,10 @@ The following technologies were **absent** in the analyzed production codebases
 1. **SQLModel** — Not used in any service; all services use SQLAlchemy ORM + Pydantic schemas separately.
 2. **Tortoise ORM** — Not used in any service; SQLAlchemy is the standard ORM.
 3. **beanie / motor (async MongoDB)** — Only one service uses MongoDB, which uses **sync pymongo** with a static-class DAO. No async MongoDB drivers detected.
-4. **Django** — Not used; FastAPI is the standard framework.
+4. **Django** — Not used; FastAPI is the standard framework. *(Still true of the analyzed
+   codebases. Since 0.80.0 the kit ships six `django-*` skills anyway — written against upstream
+   Django 6.1, DRF, and cookiecutter-django, not extracted from these repos. This entry records
+   what the analysis saw, not what the kit covers.)*
 5. **Flask** — Not used; FastAPI is the standard framework.
 6. **Celery** — Not used; async work is delegated to **Temporal** or **Kafka**, not Celery queues.
 7. **RabbitMQ / AWS SQS** — Not used; Kafka is the standard message broker.