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

{claude_code_kit-0.79.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.79.0",
+      "version": "0.80.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

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

@@ -1,7 +1,7 @@
 {
   "name": "claude-kit",
   "displayName": "Claude Kit SDLC",
-  "version": "0.79.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.79.0 → claude_code_kit-0.80.0}/CHANGELOG.md

@@ -4,6 +4,76 @@ 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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: claude-code-kit
-Version: 0.79.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.79.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.79.0 → claude_code_kit-0.80.0}/catalog/stacks.yaml

@@ -112,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

{claude_code_kit-0.79.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.79.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.79.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.79.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

{claude_code_kit-0.79.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.

{claude_code_kit-0.79.0 → claude_code_kit-0.80.0}/docs/stack-skills/README.md

@@ -13,6 +13,12 @@ These fifty-seven Claude Code skills encode production-proven engineering conven
 | **python-dao-and-database** | Data access layer patterns — BaseDao abstraction, async SQLAlchemy 1.4 vs 2.0 session lifecycle, pagination, bulk operations, transactions, MongoDB static-class DAO | [SKILL.md](../../skills/python-dao-and-database/SKILL.md) |
 | **pydantic-schema-patterns** | Pydantic v1 and v2 idioms — BaseSettings singleton, request/response schemas, field validation, ORM mode configuration, field aliasing, migration guide | [SKILL.md](../../skills/pydantic-schema-patterns/SKILL.md) |
 | **async-python-patterns** | Async Python best practices — asyncio coordination (gather/wait_for/TaskGroup), cancellation handling, resource lifecycle, connection pool management, structured concurrency | [SKILL.md](../../skills/async-python-patterns/SKILL.md) |
+| **django-service-patterns** | Django project conventions — two-tier `config/settings/{base,local,production}` layering with django-environ, apps as domain units, a custom user model from the first migration, fat models / thin views / `services.py`, ORM discipline, pytest-django; includes a cookiecutter-django bring-up reference | [SKILL.md](../../skills/django-service-patterns/SKILL.md) |
+| **django-rest-framework-patterns** | The DRF API layer — the request-flow ladder (routing → auth → permissions → throttle → view → serializer), thin ViewSets, explicit serializer `fields`, N+1 fixed in `get_queryset()`, `django_assert_num_queries`, pagination/filtering/JWT/CORS, drf-spectacular; Django Ninja as the documented alternative | [SKILL.md](../../skills/django-rest-framework-patterns/SKILL.md) |
+| **django-rest-framework-packages** | Which third-party DRF package to adopt rather than hand-roll — need → package across auth, permissions, schema, filtering, serializers, async, errors, renderers, with ACTIVE/STALE/ABANDONED maintenance labels, a dated do-not-adopt list of packages DRF's own docs still link, and how to re-verify status | [SKILL.md](../../skills/django-rest-framework-packages/SKILL.md) |
+| **django-migrations** | Migration safety — schema and data never mixed, reviewing what `makemigrations` guessed (renames emitted as drop+add), a `makemigrations --check` CI gate, idempotent batched `RunPython` under `atomic = False`, expand/contract for zero downtime, and the six-step safe squash sequence | [SKILL.md](../../skills/django-migrations/SKILL.md) |
+| **django-async-patterns** | When ASGI actually beats WSGI (and when it is a liability) — the `a`-prefixed QuerySet API and `AsyncPaginator`, `CONN_MAX_AGE = 0`, the `sync_to_async` transaction trap vs `database_sync_to_async`, the ~1 ms crossing cost, Django 6.0 Tasks vs Celery, and async DRF via `adrf` with its limits | [SKILL.md](../../skills/django-async-patterns/SKILL.md) |
+| **django-react-integration** | Wiring an SPA to Django — same-origin (bundled asset pipeline) vs separate-origin topologies, `CorsMiddleware` above `CommonMiddleware`, session-cookie vs JWT for a browser client, a generated TypeScript client from drf-spectacular, the `:3000` dev-port trap, and the production static/media split | [SKILL.md](../../skills/django-react-integration/SKILL.md) |
 | **kafka-config-driven** | Config-driven Kafka producer/consumer infrastructure — JSON DSL topic/consumer config, message handling abstraction, aiokafka vs confluent_kafka, GSSAPI/SASL_SSL auth | [SKILL.md](../../skills/kafka-config-driven/SKILL.md) |
 | **temporal-config-driven** | Config-driven Temporal workflow/activity orchestration — JSON DSL workflow registry, worker launcher, schedule/cron management, RetryPolicy patterns | [SKILL.md](../../skills/temporal-config-driven/SKILL.md) |
 | **temporal-developer** | Temporal *fundamentals* (language-agnostic; complement to temporal-config-driven) — durable execution, why workflows must be deterministic (history replay), signals/queries/updates, safe versioning of running workflows (patching/worker versioning), testing (time-skipping/replay), gotchas, the `temporal` CLI dev loop, + Python/Go/TS starters; re-derived from the MIT temporalio/skill-temporal-developer | [SKILL.md](../../skills/temporal-developer/SKILL.md) |
@@ -76,6 +82,9 @@ These fifty-seven Claude Code skills encode production-proven engineering conven
 
 3. **Trigger phrases (examples):**
    - "scaffold a new FastAPI backend" → **backend-repo-architecture**, **fastapi-service-patterns**
+   - "scaffold a new Django backend" → **backend-repo-architecture**, **django-service-patterns**
+   - "build this DRF endpoint" → **django-rest-framework-patterns**; "which package for JWT?" → **django-rest-framework-packages**
+   - "backfill a column without downtime" → **django-migrations**
    - "set up SQLAlchemy DAO" → **python-dao-and-database**
    - "implement Kafka consumer" → **kafka-config-driven**
    - "add Temporal workflow" → **temporal-config-driven**
@@ -132,4 +141,5 @@ These fifty-seven Claude Code skills encode production-proven engineering conven
 
 - **Source:** These skills are derived from real-world production Python/FastAPI and React services as of June 2026. They reflect real-world conventions, including some anti-patterns that are documented for awareness.
 - **Stack coverage:** Python FastAPI + SQLAlchemy (1.4 and 2.0) + Kafka + Temporal + Redis (caching); layered configuration (configargparse + YAML + Pydantic); GCS file ops + Excel/CSV reporting; LLM integration (Claude on Vertex AI via AnthropicVertex + Langfuse tracing); Node/Express + Objection/Knex + Joi; React + Vite + TypeScript (Zustand, TanStack Query, react-hook-form + Zod, Radix + Tailwind, Vitest + RTL + MSW); limited MongoDB (sync pymongo + aggregation/bulk/index patterns); BigQuery/GCS data pipelines; Strawberry GraphQL (backend) + Apollo Client (frontend); Docker + docker-compose + k8s; Cloud Run + GitHub Actions CI/CD; pytest + pytest-asyncio + Playwright; OpenTelemetry + Sentry + Prometheus + NewRelic; Grafana dashboards + unified alerting (Prometheus/Tempo/Pyroscope/managed-cloud datasources); argon2 + JWT + pyotp; Alembic migrations; multi-provider email/SMS notifications; OWASP ZAP VAPT/DAST scanning with automated PDF reporting; Shannon autonomous white-box AI pentesting (an external AGPL-3.0 CLI — documented, not bundled); Strix open-source AI penetration testing (an external Apache-2.0 CLI — documented, not bundled); PentesterFlow human-in-the-loop agentic pentesting (an external Apache-2.0 CLI — documented, not bundled); edge-to-service HMAC-signed forwarded-identity trust boundary; Kubernetes runtime/manifest hardening (securityContext, NetworkPolicy, PodSecurity, RBAC, digest-pinned images); scheduled/recurring jobs (Kubernetes CronJob declared in Helm values + Temporal Schedules); kubectl day-2 operations (full command surface, output formatting/JSONPath, contexts/RBAC, debugging playbooks).
-- **What's NOT covered:** SQLModel, Tortoise ORM, beanie/motor (async MongoDB), Django, Flask, and non-Express Node frameworks (NestJS, Fastify). These were absent (or single-repo only) in the analyzed codebases and were deliberately not created.
+- **What's NOT covered:** SQLModel, Tortoise ORM, beanie/motor (async MongoDB), Flask, and non-Express Node frameworks (NestJS, Fastify). These were absent (or single-repo only) in the analyzed codebases and were deliberately not created.
+- **Django was in that list until 0.80.0.** It was absent from the analyzed codebases, so no skill was extracted from them; the six `django-*` skills above were written against upstream Django 6.1, DRF, and cookiecutter-django instead. Provenance differs from the rest of this collection — see [GAP-ANALYSIS.md](GAP-ANALYSIS.md).

{claude_code_kit-0.79.0 → claude_code_kit-0.80.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.79.0"
+version = "0.80.0"
 description = "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."
 readme = "README.md"
 requires-python = ">=3.9"

{claude_code_kit-0.79.0 → claude_code_kit-0.80.0}/scripts/evals/tier_a_config.py

@@ -302,9 +302,6 @@ def fam_strictness(tmp: pathlib.Path) -> tuple[list[dict], dict[str, str]]:
 PLANNED = {
     "stack:frontend:vue": dict(frontend_framework="vue"),
     "stack:frontend:svelte": dict(frontend_framework="svelte"),
-    "stack:backend:python-django": dict(
-        backend_language="python", backend_framework="django"
-    ),
     "stack:backend-language:node": dict(
         backend_language="node", backend_framework="express"
     ),
@@ -383,6 +380,12 @@ OVERLAY = {
         dict(frontend_framework="react", frontend_language="typescript"),
         dict(frontend_framework="none"),
     ),
+    # The "off" arm is the sibling Python framework, not a different language: that is what
+    # proves the gate keys on the framework axis rather than merely on `backend_language`.
+    "django": (
+        dict(backend_language="python", backend_framework="django"),
+        dict(backend_language="python", backend_framework="fastapi"),
+    ),
 }
 
 

claude_code_kit-0.80.0/skills/django-async-patterns/README.md

@@ -0,0 +1,34 @@
+# django-async-patterns
+
+Encodes when async Django is worth it and how to do it safely: the WSGI-vs-ASGI decision, the
+`a`-prefixed queryset API, why `CONN_MAX_AGE` must be zero under ASGI, the transaction trap in
+`sync_to_async`, Django 6.0's Tasks framework versus Celery, and the real state of async DRF.
+
+Much of this skill is about *not* going async. Async is not a performance upgrade for
+database-bound Django — it relocates the concurrency ceiling rather than raising it.
+
+## What this skill covers
+
+- A decision table for WSGI vs ASGI, including the workloads where WSGI is the right answer
+- The ~1 ms cost of each sync/async context switch, and why it dominates chatty views
+- `CONN_MAX_AGE = 0` under ASGI — the failure that hides in development and appears under load
+- `aget` / `acreate` / `aexists` / `async for`, `AsyncPaginator`, and `SynchronousOnlyOperation`
+  as a feature rather than an obstacle
+- `sync_to_async` opening its own transaction context, and collapsing multi-write work into one
+  sync function
+- `channels.db.database_sync_to_async` for long-lived consumers
+- Django 6.0 Tasks (DB-backed enqueue, **no worker process**) vs Celery for scheduling, chains,
+  and retries
+- Async DRF via `adrf`, its partial coverage, and the three honest options
+
+## Provenance
+
+Written for **Django 6.1**; the Tasks framework is noted as 6.0+. `adrf` is third-party
+(github.com/em1208/adrf) and is presented with its limits rather than as a drop-in.
+
+## How to apply
+
+1. Start with the decision table. If the answer is WSGI, stop — the rest is not needed.
+2. If deploying ASGI, set `CONN_MAX_AGE = 0` before anything else.
+3. Keep transactional work inside a single sync function crossed once via `sync_to_async`.
+4. For the API layer, see `django-rest-framework-patterns`.

claude_code_kit-0.80.0/skills/django-async-patterns/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: django-async-patterns
+description: Async Django — when ASGI beats WSGI, async views, the a-prefixed QuerySet API, disabling CONN_MAX_AGE, sync_to_async vs database_sync_to_async, Tasks vs Celery, async DRF via adrf. Use when adding async views or choosing ASGI.
+---
+
+Async Django is worth it for a specific set of workloads and a liability everywhere else. This
+skill is mostly about telling those apart, then doing it correctly when the answer is yes.
+
+Targets **Django 6.1**. Features newer than the 5.2 LTS name their version.
+
+## When to use
+
+- Deciding between WSGI and ASGI for a deployment
+- Adding an `async def` view, or converting a sync one
+- A view that fans out to several slow HTTP calls
+- Choosing between Django 6.0's Tasks framework and Celery
+- Making DRF work in an async project
+- Debugging `SynchronousOnlyOperation` or connection exhaustion under ASGI
+
+## First: do you actually need ASGI?
+
+| Workload | Answer |
+|---|---|
+| CRUD over a database, server-rendered or JSON | **WSGI.** gunicorn with sync workers is correct and simpler. |
+| WebSockets, Server-Sent Events, long-lived connections | **ASGI.** WSGI cannot express these. |
+| One view fanning out to several slow third-party APIs | **ASGI**, for that view. Concurrency is the point. |
+| High request volume, all database-bound | **WSGI.** The bottleneck is the database and its connections, and async does not add any. |
+| "It feels more modern" | **WSGI.** |
+
+Async is not a performance upgrade for database-bound Django. It moves the concurrency limit from
+worker processes to the connection pool, and if the pool is the constraint you have gained a more
+complicated way to hit the same ceiling.
+
+Each transition between sync and async context costs roughly **1 ms**. A view that crosses that
+boundary a handful of times per request has spent more than it saved.
+
+## Running under ASGI
+
+```bash
+uv run uvicorn config.asgi:application --host 0.0.0.0 --reload --reload-include '*.html'
+```
+
+`--reload-include '*.html'` is needed because uvicorn's reloader watches Python files only;
+without it template edits do not refresh.
+
+### Disable `CONN_MAX_AGE`
+
+```python
+DATABASES["default"]["CONN_MAX_AGE"] = 0
+```
+
+Persistent connections must be **off** under async. `CONN_MAX_AGE` binds a connection to a thread,
+and the async request path does not have the same thread-per-request guarantee, so connections leak
+and the pool exhausts under load. Use the database backend's own pooling instead.
+
+This is the single most common way an async Django deployment fails in production rather than in
+development, because low traffic hides it.
+
+## The async ORM surface
+
+Every queryset method has an `a`-prefixed async twin:
+
+```python
+order = await Order.objects.aget(pk=pk)
+await Order.objects.acreate(customer=user, total=0)
+orders = [o async for o in Order.objects.filter(status="open")]
+exists = await Order.objects.filter(pk=pk).aexists()
+```
+
+`AsyncPaginator` and `AsyncPage` are the paginator equivalents.
+
+Querysets are still lazy; `async for` is what evaluates them. Forgetting the `await` on `aget()`
+yields a coroutine that fails somewhere later and confusingly.
+
+Calling the sync ORM from async context raises `SynchronousOnlyOperation`. That error is a
+feature — it is Django refusing to block the event loop.
+
+### `sync_to_async` and its transaction trap
+
+`sync_to_async` opens **its own transaction context**. Code that needs transactional semantics
+should therefore be a single sync function called through one `sync_to_async`, not several
+separate calls that each get their own transaction:
+
+```python
+# Wrong — three transactions, no atomicity across them
+await sync_to_async(order.save)()
+await sync_to_async(payment.save)()
+
+# Right — one sync function, one transaction, one crossing
+@transaction.atomic
+def _place(order, payment):
+    order.save()
+    payment.save()
+
+await sync_to_async(_place)(order, payment)
+```
+
+This also minimises the ~1 ms crossings.
+
+In a long-lived consumer (a WebSocket handler), use `channels.db.database_sync_to_async` instead.
+It is `sync_to_async` plus `close_old_connections()`, which is what prevents a consumer from
+holding a stale connection for the life of the socket.
+
+## Background work: Tasks vs Celery
+
+**Django 6.0** shipped a built-in Tasks framework (`django.tasks`) with database-backed enqueue.
+It has **no built-in worker process** — enqueueing is solved, execution is not, and you still
+supply infrastructure to run the tasks.
+
+| Need | Use |
+|---|---|
+| Fire-and-forget, already have a worker story | `django.tasks` (6.0+) |
+| Periodic / scheduled jobs | **Celery** (+ django-celerybeat) |
+| Chains, groups, chords | **Celery** |
+| Per-task retry policies, backoff | **Celery** |
+| Result backend, monitoring (Flower) | **Celery** |
+
+Tasks is not a Celery replacement for anything beyond simple enqueue. cookiecutter-django still
+offers Celery for exactly this reason.
+
+## DRF in an async project
+
+DRF has **no first-class async support**. Its views, permissions, and serializers are sync.
+
+[`adrf`](https://github.com/em1208/adrf) bridges the gap with async class- and function-based
+views. It works, but it is third-party, it does not cover the whole DRF surface, and mixing async
+views with sync permission classes reintroduces the crossings you were trying to avoid.
+
+Three honest options:
+
+1. **Keep DRF sync under WSGI**, and run genuinely async work elsewhere. Best for a mostly-CRUD
+   API with a few slow endpoints.
+2. **DRF + `adrf`** for the handful of views that need it. Accept the partial coverage.
+3. **Django Ninja** if the API is async throughout. It is async-first on Pydantic v2 — see
+   `django-rest-framework-patterns` for the tradeoff.
+
+Do not convert an entire DRF API to `adrf` expecting a speedup. A database-bound API gets slower,
+because every ORM call becomes a boundary crossing.
+
+## Anti-patterns to avoid
+
+1. **`CONN_MAX_AGE` left non-zero under ASGI** — connection leak that only appears under load.
+2. **Sync ORM calls in an `async def` view** — `SynchronousOnlyOperation`, or a blocked event loop
+   if wrapped carelessly.
+3. **Several `sync_to_async` calls where one transaction was needed** — each gets its own
+   transaction context.
+4. **`sync_to_async` in a long-lived consumer** — use `database_sync_to_async` so connections are
+   closed.
+5. **Choosing ASGI for a database-bound CRUD app** — moves the ceiling without raising it.
+6. **Sprinkling `async def` on views that only touch the ORM** — pure overhead.
+7. **Treating `django.tasks` as a Celery replacement** — no worker, no scheduling, no chains.
+8. **Converting a whole DRF API to `adrf`** — partial coverage and more crossings.
+9. **Forgetting `await` on an `a`-prefixed call** — fails later, far from the cause.
+10. **Blocking calls (`requests`, `time.sleep`) in an async view** — stalls the entire event loop,
+    not just that request.
+
+## References
+
+- `django-rest-framework-patterns` — the sync DRF layer and the Ninja alternative
+- `django-service-patterns` — the services layer these views call
+- `.claude/rules/django-patterns.md` — the installed overlay rule, incl. the WSGI/ASGI decision

claude_code_kit-0.80.0/skills/django-migrations/README.md

@@ -0,0 +1,34 @@
+# django-migrations
+
+Encodes migration safety for Django: keeping schema and data changes in separate migrations,
+reviewing what `makemigrations` guessed, writing idempotent batched `RunPython` backfills under
+`atomic = False`, sequencing expand/contract so a rolling deploy never sees an invalid state, and
+the multi-deploy squash sequence that does not strand a lagging environment.
+
+## What this skill covers
+
+- One migration, one thing — why mixing schema and data has no clean recovery
+- Reviewing generated migrations: rename-as-drop-plus-add, defaults on large tables, `unique=True`
+  on populated columns
+- `makemigrations --check --dry-run` as a CI gate
+- Data migrations: `apps.get_model`, filtering to un-migrated rows, `.iterator()` + `bulk_update`,
+  and always supplying a reverse (even `noop`)
+- Why `atomic = False` makes the idempotent filter mandatory rather than nice to have
+- Expand → backfill → deploy → contract for adding a non-nullable column; reverse order for drops
+- The six-step safe squash, and why steps 2–6 cannot collapse into one deploy
+
+## Provenance
+
+Written for **Django 6.1**. Notes that zero-downtime migration backends improve schema and `RunSQL`
+operations but do not change `RunPython` semantics — a distinction that is easy to assume away when
+such a backend is installed.
+
+## How to apply
+
+1. Read before writing any migration that touches a populated table.
+2. Split schema from data as the first move, not as cleanup.
+3. Add the `makemigrations --check` step to CI once, so the rule is enforced rather than
+   remembered.
+4. For the models these migrations act on, see `django-service-patterns`.
+5. Migrations classify as sensitive under `.claude/rules/risk-classification.md`; high-risk ones
+   need rollback notes before they ship.