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

{claude_code_kit-0.79.0 → claude_code_kit-0.81.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.81.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

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

@@ -1,7 +1,7 @@
 {
   "name": "claude-kit",
   "displayName": "Claude Kit SDLC",
-  "version": "0.79.0",
+  "version": "0.81.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.81.0}/CHANGELOG.md

@@ -4,6 +4,140 @@ 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.81.0] — 2026-08-15
+
+**The board shows up on its own, and it shows the whole ticket.** Two things were wrong with
+`claude-kit tickets --html`: nothing in a `/sdlc` run ever created it, and a card carried far less
+than the terminal detail view already knew. Both are fixed — `/sdlc` opens a browser board at
+ticket creation, and clicking a card now opens a full issue view.
+
+### Added
+
+- **`/sdlc` opens the board at Stage TK.** The orchestrator runs `claude-kit tickets --open` right
+  after the tickets are written and before the first implementation agent spawns — tickets exist,
+  work is about to start, the human wants to watch. This is also what switches the live refresh on:
+  the `capture-ticket-telemetry` Stop hook's opt-in signal is simply that the file exists
+  (`[ -f "$BOARD" ]`), so one command at Stage TK makes the rest of the run watchable. Never a
+  gate — a missing CLI is reported and the pipeline carries on.
+- **`claude-kit tickets --open`** writes the board and launches the default browser. It **implies
+  `--html`** rather than erroring without it, opens **once** under `--watch` rather than once per
+  tick, and fails soft: a raising or `False`-returning `webbrowser.open` prints the `file://` URL
+  and still exits 0, so SSH, CI and containers get the path instead of a broken exit code.
+- **A per-ticket issue view.** Every ticket now renders a full panel below the board carrying what
+  the terminal `render_detail` already knew and the browser did not: status, branch, spec, design,
+  pipeline stage and last gate passed, blockers, non-gating lineage (`child_of`/`parent_of`),
+  commits, declared files, per-agent telemetry with the shared-branch caveat, and the work log.
+  Cards are anchors to it; a `× close` anchor dismisses it; the browser back button works.
+- **A sprint-style status strip** across the top — the gate chain with the current position marked
+  and an `N/M` tally — rendered from `pipeline_stage()` and `installed_gates()`. It is omitted
+  entirely when there is no active run, rather than rendering an empty chain.
+- **Text avatars.** Each card carries the acting agent's initials in a CSS circle
+  (`developer` → DE, `sdlc-code-reviewer` → SR). Text, not an image — see below.
+
+### Changed
+
+- `pipeline.installed_gates()` is public (was `_installed_gates`). Three eval scripts already
+  reached into the private name; naming it honestly beat adding a wrapper around it.
+- `render_html()` takes optional `stage=` and `gates=`, following the existing injectable
+  `generated_at=` convention so the renderer stays pure and testable.
+- `commands/sdlc.md` gains `Bash` in `allowed-tools`. The orchestrator has its own, so the normal
+  path already worked; this closes the latent gap in the skill's documented fallback ("if the
+  `orchestrator` agent is unavailable, act as the orchestrator yourself"), which could not shell
+  out.
+
+### Not adopted (deliberately)
+
+- **No JavaScript — so no filter-as-you-type and no drag-to-reorder.** Both were on the table and
+  both were dropped. `tests/test_board_html.py` asserts `"<script" not in html`, and that single
+  line is doing double duty: it is the self-containment guard *and* the XSS guard. A board with no
+  script tag at all cannot execute an injected one, whatever a ticket title contains. Adding one
+  `<script>` for filtering would demote that absolute into a per-sink review of every interpolated
+  string. The interactivity that survived is CSS-only (`:target` reveal, anchors as click targets),
+  which costs nothing to audit. Avatars are text in a circle for the same reason: `<img>` is pinned
+  out alongside `http://`, `<link>` and `@import` so the file stays one artifact you can email.
+- **No two-pane layout.** A persistent detail rail would mean either a fixed viewport split (bad at
+  1280px with five columns) or JS-driven resizing. Click-through gives the full width to whichever
+  view you are actually reading.
+- **No real JIRA integration.** This is a rendering of the local git-native store, not a client.
+  Pushing tickets to an external tracker stays `task-tracker-sync` plus the opt-in Atlassian MCP
+  server; the local store remains the source of truth in both directions.
+- **No assignee field.** The board attributes work from transcript telemetry (`agentName`), which
+  is a record of who *did* act. There is no assignment model in the ticket store, and inventing an
+  assignee dropdown would show a field that nothing writes and nothing reads.
+- **No hook change.** The refresh already keys off the file existing; creating it once at Stage TK
+  flips that switch for the whole run. Editing a hook would have meant regenerating `hooks.json`
+  and `settings.json` for no behavioural gain.
+
+## [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.81.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: claude-code-kit
-Version: 0.79.0
+Version: 0.81.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,10 +161,10 @@ 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)) |
+| 📊 **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 click-through browser Kanban board (gate strip, per-ticket issue view, agent/model/token/timing figures) that `/sdlc` opens for you when it creates the tickets ([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 |
 
 Profiles (`lean` · `standard` · `enterprise`), team scopes, autonomy levels, and org capability
@@ -275,13 +275,21 @@ claude-kit tickets --graph        # dependency DAG — what is blocked by what
 claude-kit tickets --graph-git    # the commit graph with each commit's ticket attached
 claude-kit tickets CKIT-74        # one ticket: full work log + per-lane telemetry
 claude-kit tickets --html         # a Kanban board in your browser
+claude-kit tickets --open         # the same board, opened for you
 ```
 
-`--html` writes a self-contained page to `.claude/state/ticket-board.html` and prints a `file://` URL.
+`--html` writes a self-contained page to `.claude/state/ticket-board.html` and prints a `file://` URL;
+`--open` does that and launches your browser (and quietly falls back to the printed path on a headless
+box). **`/sdlc` runs `--open` for you** the moment it creates the tickets, before any implementation
+agent starts — so you watch the run rather than reading chat for status.
+
 It is a **file, not a server** — the page refreshes itself and the `capture-ticket-telemetry` Stop hook
-rewrites it after each turn, so an open tab tracks a running pipeline live with nothing daemonised:
+rewrites it after each turn, so an open tab tracks a running pipeline live with nothing daemonised.
+A header strip shows which gate the pipeline is on, and clicking any card opens a full issue view —
+spec, design, stage, files, commits, per-agent telemetry and the work log — all with **no JavaScript
+at all**, so the page makes zero network requests and leaks nothing:
 
-![The claude-kit ticket board — Kanban columns for in progress, in review, actionable, blocked and done, each card showing model, tokens, cache, elapsed time and commit](docs/images/ticket-board.png)
+![The claude-kit ticket board — a pipeline gate strip above Kanban columns for in progress, in review, actionable, blocked and done, each card showing model, tokens, cache, elapsed time, branch, commits and the acting agent's initials; below the board, one ticket's issue view is open with its status, spec, design, stage, files, commits, per-agent telemetry and work log](docs/images/ticket-board.png)
 
 Token counts are **deduplicated by request id** — streaming rewrites the same usage block many times,
 and a naive sum overstates output by ~3× — and cache reads are counted separately from fresh input
@@ -325,7 +333,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.81.0}/README.md

@@ -128,10 +128,10 @@ 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)) |
+| 📊 **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 click-through browser Kanban board (gate strip, per-ticket issue view, agent/model/token/timing figures) that `/sdlc` opens for you when it creates the tickets ([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 |
 
 Profiles (`lean` · `standard` · `enterprise`), team scopes, autonomy levels, and org capability
@@ -242,13 +242,21 @@ claude-kit tickets --graph        # dependency DAG — what is blocked by what
 claude-kit tickets --graph-git    # the commit graph with each commit's ticket attached
 claude-kit tickets CKIT-74        # one ticket: full work log + per-lane telemetry
 claude-kit tickets --html         # a Kanban board in your browser
+claude-kit tickets --open         # the same board, opened for you
 ```
 
-`--html` writes a self-contained page to `.claude/state/ticket-board.html` and prints a `file://` URL.
+`--html` writes a self-contained page to `.claude/state/ticket-board.html` and prints a `file://` URL;
+`--open` does that and launches your browser (and quietly falls back to the printed path on a headless
+box). **`/sdlc` runs `--open` for you** the moment it creates the tickets, before any implementation
+agent starts — so you watch the run rather than reading chat for status.
+
 It is a **file, not a server** — the page refreshes itself and the `capture-ticket-telemetry` Stop hook
-rewrites it after each turn, so an open tab tracks a running pipeline live with nothing daemonised:
+rewrites it after each turn, so an open tab tracks a running pipeline live with nothing daemonised.
+A header strip shows which gate the pipeline is on, and clicking any card opens a full issue view —
+spec, design, stage, files, commits, per-agent telemetry and the work log — all with **no JavaScript
+at all**, so the page makes zero network requests and leaks nothing:
 
-![The claude-kit ticket board — Kanban columns for in progress, in review, actionable, blocked and done, each card showing model, tokens, cache, elapsed time and commit](docs/images/ticket-board.png)
+![The claude-kit ticket board — a pipeline gate strip above Kanban columns for in progress, in review, actionable, blocked and done, each card showing model, tokens, cache, elapsed time, branch, commits and the acting agent's initials; below the board, one ticket's issue view is open with its status, spec, design, stage, files, commits, per-agent telemetry and work log](docs/images/ticket-board.png)
 
 Token counts are **deduplicated by request id** — streaming rewrites the same usage block many times,
 and a naive sum overstates output by ~3× — and cache reads are counted separately from fresh input
@@ -292,7 +300,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.81.0}/agents/orchestrator.md

@@ -360,6 +360,14 @@ starting work" discipline. Using `ticketing-and-traceability`:
 - **Fast-track (Mode D)**: collapse to a single ticket for the change rather than one per story.
 - **Not installed**: if `ticketing-and-traceability` isn't in the active profile (e.g. lean), skip
   this stage and note the skip in CONTINUITY.md — the pipeline proceeds unchanged.
+- **Open the board — once, here.** With the tickets written, run
+  `claude-kit tickets --open` and report the printed `file://` path in chat. This is the
+  right moment: the tickets exist and no implementation has started, so the human gets a live
+  view of the whole run before any of it happens. From then on the `capture-ticket-telemetry`
+  Stop hook refreshes that file after every turn — **its opt-in signal is the file existing**, so
+  this one command is what makes the rest of the run visible. Do not re-run it per stage; the page
+  reloads itself. If the CLI is unavailable, say so once and continue — the board is an
+  observability aid and never a gate.
 
 The ticket id assigned here rides with the work: implementation lanes append work-log entries to it
 (VALIDATE / JOIN below), and the PR stage links its commits and closes it.

{claude_code_kit-0.79.0 → claude_code_kit-0.81.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.81.0}/commands/sdlc.md

@@ -1,7 +1,7 @@
 ---
 description: Run the full autonomous SDLC pipeline on a task via the orchestrator
 argument-hint: "<feature or task description>"
-allowed-tools: Skill, Agent, Read, Glob, Grep, TaskCreate, TaskGet, TaskList, TaskUpdate
+allowed-tools: Skill, Agent, Bash, Read, Glob, Grep, TaskCreate, TaskGet, TaskList, TaskUpdate
 ---
 
 Run the claude-kit autonomous SDLC pipeline for:

{claude_code_kit-0.79.0 → claude_code_kit-0.81.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
@@ -132,6 +132,19 @@ README.claude-sdlc.md
 - **A full React design system** — picking React installs design tokens, UX patterns, and
   mobile/Capacitor guidelines that the UI skills and `ui-designer` agent read.
 
+## Watching a run
+
+`/sdlc` opens the ticket board for you. At Stage TK — after the stories are approved and the
+tickets are written, before any implementation agent starts — the orchestrator runs `claude-kit
+tickets --open`, which writes `.claude/state/ticket-board.html` and launches your browser. From
+then on the `capture-ticket-telemetry` Stop hook refreshes that file after every turn, so the page
+tracks the run live with nothing daemonised. The board is a single self-contained file: no
+JavaScript, no network requests, no server.
+
+Outside a run, `claude-kit tickets` renders the same store as a terminal chart, `--html` writes the
+board without opening it, and `claude-kit tickets <PREFIX>-<N>` prints one ticket's detail. If no
+browser can be launched (SSH, CI, a container), `--open` prints the `file://` URL and exits 0.
+
 ## Memory & continuous learning
 
 - **Working memory across sessions** — `CONTINUITY.md` survives context compaction so the pipeline

{claude_code_kit-0.79.0 → claude_code_kit-0.81.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.81.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.81.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.81.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.81.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.81.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.79.0"
+version = "0.81.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.81.0}/scripts/evals/tier_a_config.py

@@ -84,7 +84,7 @@ def fam_gates(tmp: pathlib.Path) -> list[dict]:
     out-of-order bug would manufacture a false positive against documented behaviour.
     """
     d = install(sel(profile="enterprise"), tmp, "gates")
-    gates = pipeline._installed_gates(d)
+    gates = pipeline.installed_gates(d)
     if not gates:
         return [
             row("gate:*", False, "no gates in the install snapshot -- nothing to walk")
@@ -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"),
+    ),
 }
 
 
@@ -594,7 +597,7 @@ def fam_schemas(tmp: pathlib.Path) -> list[dict]:
     d = install(sel(), tmp, "schema")
     ev = d / "e.txt"
     ev.write_text("x\n", encoding="utf-8")
-    gates = pipeline._installed_gates(d)
+    gates = pipeline.installed_gates(d)
     seeded, why = pipeline.close_gate(d, gates[0], str(ev))
     if not seeded:
         return [

{claude_code_kit-0.79.0 → claude_code_kit-0.81.0}/scripts/evals/tier_a_lifecycle.py

@@ -470,7 +470,7 @@ def c_pipeline_abort(tmp: pathlib.Path, neg: bool) -> dict:
     d, _ = fresh(tmp, "ab")
     ev = d / "e.txt"
     ev.write_text("x\n", encoding="utf-8")
-    gates = pipeline._installed_gates(d)
+    gates = pipeline.installed_gates(d)
     pipeline.close_gate(d, gates[0], str(ev))
     ok, msgs = pipeline.abort(d)
     snap = json.loads(read(pipeline._snapshot_path(d)) or "{}")