claude-code-kit 0.69.0__tar.gz → 0.73.0__tar.gz

{claude_code_kit-0.69.0 → claude_code_kit-0.73.0}/.claude-plugin/marketplace.json

@@ -10,7 +10,7 @@
       "name": "claude-kit",
       "source": "./",
       "description": "Cookiecutter-style scaffolder for an autonomous Claude Code SDLC config (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, working memory, and a self-improving learnings loop.",
-      "version": "0.69.0",
+      "version": "0.73.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

{claude_code_kit-0.69.0 → claude_code_kit-0.73.0}/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.69.0",
+  "version": "0.73.0",
   "description": "Cookiecutter-style scaffolder for an autonomous Claude Code SDLC config (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 working memory and a self-improving learnings loop.",
   "author": {
     "name": "Arjunsingh Yadav",

{claude_code_kit-0.69.0 → claude_code_kit-0.73.0}/CHANGELOG.md

@@ -4,6 +4,245 @@ 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.73.0] — 2026-07-28
+
+**A runtime ticket chart — `claude-kit tickets` shows which ticket is in flight and what it cost**
+(user request: *"a chart to show which ticket is in progress and its details — how many tokens were
+used, which model, time, status, agent used … runtime and not a pic or screenshot"*). 0.72.0 recorded
+what changed and why; this answers what the work cost, live.
+
+### Added
+
+- **`claude-kit tickets`** — a text board, one row per ticket: ID · TITLE · STATUS · AGENT · MODEL ·
+  TOKENS · CACHE · TIME · COMMITS, ordered in-progress first. Variants: `--graph` (ticket dependency
+  graph), `--graph-git` (commit graph annotated with each commit's ticket), `PROJ-12` (detail view with
+  the per-ticket work log and full telemetry), `--watch N` (re-render every N seconds), `--json`.
+- **`claude-kit tickets --html`** — the same data as a **browser Kanban board**
+  (IN PROGRESS · IN REVIEW · ACTIONABLE · BLOCKED · DONE), written to the gitignored
+  `.claude/state/ticket-board.html`. It is a *file, not a server*: a `<meta refresh>` tag plus the Stop
+  hook rewriting the file gives live progress with no daemon and no port. Fully self-contained — inline
+  CSS, no JavaScript, no fonts, no images, no CDN — so opening it makes zero network requests and
+  ticket titles never leave the machine. Respects OS light/dark preference; `--refresh N` tunes the
+  reload (`0` = static snapshot). Every interpolated value is HTML-escaped.
+- **`src/claude_kit/telemetry.py`** — read-only, metadata-only aggregation of Claude Code session
+  transcripts, attributed to tickets by `gitBranch`. Deduplicates by `requestId`: streaming repeats each
+  usage block, so a naive sum overstated output tokens **3.3×** (622 raw records → 219 real requests on
+  the session this was measured against). Cache reads get their own counter rather than being folded
+  into input, because they routinely exceed fresh input by three orders of magnitude.
+- **`src/claude_kit/tickets.py`** — ticket store loader and renderers. Relation model adopted from
+  [quazardous/aiball](https://github.com/quazardous/aiball) (MIT, © 2026 David Berlioz — concepts
+  re-expressed, no code copied): `depends_on`/`blocks` **gate** whether a ticket is actionable, while
+  `child_of`/`parent_of` lineage deliberately does not. Adds a derived **BLOCKED** display status, and
+  the board header always prints the open count beside actionable so a fully-gated backlog can never
+  read as "nothing to do".
+- **`capture-ticket-telemetry.sh`** (Stop hook, standard profile) — persists the figures into the
+  gitignored `.claude/state/ticket-telemetry.json` so history survives transcript pruning, and
+  refreshes the HTML board **only if that file already exists**, so its presence is the opt-in and
+  terminal-only users never pay to render a page they don't look at. Detached,
+  throttled to once per 60s (`CLAUDE_KIT_TELEMETRY_INTERVAL`), no-ops without `jq`, without the
+  `claude-kit` CLI, or before a ticket store exists; opt out with `CLAUDE_KIT_NO_TELEMETRY=1`. It shells
+  out to `tickets --json` rather than re-deriving totals in `jq`, so the dedupe rule has exactly one
+  tested implementation instead of two that can drift.
+
+### Changed
+
+- Hook scripts 18 → **19**. Rules (25), agents (29), and skills (111) are unchanged — this release adds
+  no skill, no agent, and no rule.
+- **README gains a "Parallel lanes and the live ticket board" section** — how the orchestrator forks
+  independent stories into concurrent lanes, joins them at the merge-reviewer gate, fans out to the
+  testing agents, and how the board makes that visible — with a screenshot of the rendered board
+  (`docs/images/ticket-board.png`; `docs/` is not bundled into the wheel).
+- **`agentName` is now read from records that carry no usage block.** It never co-occurs with
+  `requestId` + `usage` in a transcript, so reading it only from billed turns left the AGENT column
+  structurally unfillable. Each agent is credited strictly to the branch its own record names —
+  inferring across a file smears them (one sampled transcript held 18 agent names against 54 branches).
+- Telemetry is **branch-scoped**, since `gitBranch` is the only ticket-shaped key a transcript carries.
+  Tickets sharing a branch therefore show that branch's totals, and both the board and the detail view
+  say so explicitly rather than implying the figure belongs to one ticket.
+- **`BLOCKED` only overrides `OPEN`.** A ticket that is already IN PROGRESS or IN REVIEW has someone on
+  it, so reporting it as "blocked" would replace the more useful fact with a less useful one; the unmet
+  dependency is still named on the graph, the detail view, and the HTML card. Relatedly, a **closed
+  ticket now reports no blockers at all** — a DONE card previously rendered the contradiction
+  "DONE · blocked by X".
+
+### Not adopted (deliberately)
+
+- **aiball's daemon and PTY proxy**, and a long-running server for the board. The kit ships
+  configuration, not a running service — so the browser view is a generated file plus a meta-refresh,
+  which needs no port, no process, and no lifecycle to manage. (A `--serve` mode remains possible
+  later if polling ever proves insufficient.)
+- **Hardcoded model pricing.** A cost column would need a price table that silently rots; tokens and
+  model id are reported instead, and any rate table stays the user's to supply.
+- **Message content.** Only usage counters, model ids, agent names, timestamps, and the branch are read
+  — never prompt or response text, matching the learning-capture posture in `SECURITY.md`.
+- **A per-turn full rescan.** Re-reading every transcript on each Stop was measured at ~0.9s over
+  200 MB; the hook throttles instead.
+- **`--graph=git` as an optional-value flag.** `--graph` with an inline value depends on Click's
+  `flag_value`, which is deprecated in the Click that typer 0.26 vendors and errors on a bare `--graph`.
+  Two plain booleans (`--graph` / `--graph-git`) behave identically across the supported typer range.
+
+## [0.72.0] — 2026-07-27
+
+**Ticket-first traceability — a local git-native ticket store, per-change work-log, project wiki, and
+ticket↔commit linkage** (user request: *"the orchestrator … post consulting the personas [should] create
+a ticket before starting any work, document every step — what it changed, why, which files, what
+decisions — update the wiki with functional/technical docs and decision records, and link tickets to
+commits so you can trace any change back to its reasoning"*). The orchestrator already consulted the
+personas, critiqued the plan, and broke it into stories; what was missing was the traceability spine that
+ties an approved plan to the commits that implement it. This adds one, git-native and in-repo, modelled on
+[Claude-Project-Tracker](https://github.com/rpostulart/Claude-Project-Tracker) (ideas only — that repo has
+no license, so **zero code was copied**).
+
+### Added
+
+- **`ticketing-and-traceability` skill** (core; SKILL.md) — defines a **local git-native ticket store**
+  under `docs/project/tickets/` (one Markdown ticket per story + a JSON index), the `<PREFIX>-<N>` id
+  scheme (PREFIX derived from the project, N allocated from the index), the `OPEN → IN PROGRESS → IN
+  REVIEW → DONE` lifecycle, the **work-log discipline** (append what/why/which-files/decisions per step),
+  the three-page **wiki** (functional → the spec, technical → dev docs + design spec, decisions → the
+  ADRs — indexes that link, never duplicate), the **ticket↔commit linkage** convention, and the optional
+  hand-off to `task-tracker-sync` for mirroring to an external tracker. Zero setup, no server, no account.
+- **Orchestrator `Stage TK: Ticket Creation`** — a new pipeline step *after* the persona consultation +
+  plan approval + story-breakdown coverage gate and *before* implementation lanes: one OPEN ticket per
+  story, wiki updated, optional external mirror. Work-log entries are appended at the VALIDATE/JOIN steps;
+  tickets close at the PR stage. Advisory — skipped (with a noted reason) where the skill isn't installed.
+
+### Changed
+
+- **Advisory discipline (no new hooks, no new rule):** `rules/mandatory-workflow.md` gains a **step 1g —
+  Ticket Creation & Traceability** and a rewritten *Commit & ticket format* section (link every commit to
+  its ticket id; the PR Raiser reads the id from the local store rather than asking); `rules/documentation.md`
+  gains a *Project wiki* note. Rules stay at **25**.
+- **Reused-skill wiring (reuse-first):** `git-workflow-and-versioning` gains a *Linking Commits to Tickets*
+  subsection; `documentation-and-adrs` notes ADRs are the wiki's decisions pillar; `task-tracker-sync` notes
+  it mirrors the local store outward (local store = source of truth).
+- **Agent wiring:** `pr-raiser` reads the ticket id from `docs/project/tickets/`, writes `[<PREFIX>-N]`
+  into commits, adds a *Ticket* line to the PR template, and closes tickets to DONE; `story-planner` notes
+  each story maps to one ticket; `spec-doc-writer` notes its `_spec.md` is the functional/technical wiki
+  source; `orchestrator` adds a *Ticketing / traceability* skill-routing row.
+- **Catalog:** `ticketing-and-traceability` installed at the **standard** profile (enterprise inherits;
+  lean stays fast-track). Preserves `lean ⊂ standard ⊂ enterprise`.
+- **Counts:** skills **110 → 111** (**58** core + 53 collection); agents unchanged at 29, rules at 25.
+  Docs updated (`README.md`, `docs/skill-audit.md`, `docs/influences.md`).
+
+### Not adopted (deliberately)
+
+- **The reference repo's Deno server + web Kanban/list/wiki UI (`server.ts`, `ui/`)** — claude-kit ships
+  configuration and prose, not a running service; the store is plain Markdown + JSON you read with git.
+- **Blocking enforcement hooks** — the discipline is **advisory** (a pipeline step + a rule + a skill), by
+  explicit user choice; no hook refuses work without a ticket or rejects an un-tagged commit, so
+  `gen_hooks.py --check` and the hook surface are unchanged.
+- **A competing external-tracker skill** — the local store is the source of truth and the existing
+  `task-tracker-sync` handles the optional GitHub/Linear/Jira mirror; no duplication (golden rule #8).
+- **Per-user id counters / assignee boards / status columns** from the reference — the git-native ticket
+  file + JSON index already give a full audit trail; the rest is UI the kit doesn't ship.
+- **Copying any Claude-Project-Tracker code** — it carries no license (all rights reserved); the ideas were
+  re-expressed in the kit's own terms and stack-agnostic form, with nothing vendored.
+
+## [0.71.0] — 2026-07-27
+
+**Third pentest tool — a `pentesterflow-pentest` skill for human-in-the-loop pentesting** (user
+request: *"check PentesterFlow/agent for pen test as well… make sure to have all shannon, pentesterflow
+and strix while doing penetration testing"*). The 0.70.0 pentest lane covered **autonomous** AI
+pentesting (Strix, Shannon) and **DAST** (ZAP) but had no **human-in-the-loop / analyst-controlled**
+option — the supervised, approval-gated mode that scoped engagements and bug bounty rely on. This adds
+[PentesterFlow](https://github.com/PentesterFlow/agent) as a fourth tool the `pentest-scanner` agent can
+drive, so Strix, Shannon, and PentesterFlow are all available for penetration testing.
+
+### Added
+
+- **`pentesterflow-pentest` skill** (collection; SKILL.md + README.md + `references/operating-guide.md`)
+  — a **documentation-only** driver for [PentesterFlow](https://github.com/PentesterFlow/agent), the
+  open-source (**Apache-2.0**) human-in-the-loop agentic offensive-security CLI `pentesterflow`. Covers
+  install (`install.sh` standalone binary — **no Docker**), local/hosted backends (Ollama, LM Studio,
+  Kimi, Groq, OpenRouter, DeepSeek, Gemini, OpenAI-compatible), the approval-gated permission model,
+  `--target`/`--resume`/`--burp`/`--yolo` flags + slash commands, built-in skills (recon, webvuln, ssrf,
+  ssti, jwt, graphql, race, takeover, supabase, deserialize), evidence-backed `confirm_finding` reports
+  (`./findings/*.md`), the Burp bridge + `pentesterflow-browser-mcp`, memory/coverage, and safety.
+
+### Changed
+
+- **`pentest-scanner` agent** now drives **four** tools — its tool-selection table, preflight probe, and
+  description add **PentesterFlow** (the supervised, no-Docker, local-model / Burp-friendly option)
+  alongside Strix, Shannon, and ZAP. The conditional, authorization-gated, non-blocking preflight is
+  unchanged; the Docker requirement is now noted as tool-specific (PentesterFlow needs none).
+- **Wiring:** the skill is referenced from `security-reviewer`, `orchestrator` (Stage 5.4 + the Security
+  skill-routing row), and `tester`, and installed at the **standard** profile alongside the other pentest
+  skills.
+- **Counts:** skills **109 → 110** (57 core + **53** collection); agents unchanged at 29. Docs updated
+  (`README.md`, `docs/agents.md`, `docs/stack-skills/README.md`, `docs/skill-audit.md`,
+  `docs/influences.md`).
+
+### Not adopted (deliberately)
+
+- **Vendoring PentesterFlow's source** — even though Apache-2.0 permits it, claude-kit ships prose, not
+  tools; the skill stays documentation-only and you install the `pentesterflow` binary yourself (same
+  posture as the other three pentest skills).
+- **A separate agent** — `pentest-scanner` is already tool-agnostic, so PentesterFlow is a new tool it
+  can select, not a new agent (no roster growth, no gate-behavior change).
+- **A `pentesterflow-browser-mcp` catalog fragment** — the browser-capture MCP is documented in the
+  skill; it is not added to `catalog/mcp.yaml` (no always-on agent consumer, and it is engagement-local).
+- **`--yolo` / auto-approval in any default flow** — PentesterFlow's value is the human-in-the-loop
+  approval gate; the skill and agent keep it approval-gated (YOLO is flagged labs-only).
+
+## [0.70.0] — 2026-07-26
+
+**Dynamic penetration testing — a `strix-ai-pentest` skill + a first-class `pentest-scanner` agent
+that drives Strix, Shannon, or ZAP** (user request: *"use [usestrix/strix] to do penetration testing…
+when the user asks for testing, or the testing agent is provoked by the orchestrator, it should have an
+agent doing penetration testing… make sure we do Shannon as well as Strix."*). The kit's security stage
+was entirely **static** (secret / dependency / OWASP / policy readers), and pentesting was
+documentation-only (`shannon-ai-pentest` / `zap-vapt-scanning`) with **no agent that actually runs one**.
+This adds the missing dynamic, exploit-validation lane — reachable both on an explicit user request and
+via the orchestrator's security stage.
+
+### Added
+
+- **`strix-ai-pentest` skill** (collection; SKILL.md + README.md + `references/operating-guide.md`) —
+  a **documentation-only** driver for [Strix](https://github.com/usestrix/strix) (usestrix), the
+  open-source (**Apache-2.0**) AI penetration-testing CLI `strix-agent`. Covers install
+  (`pipx install strix-agent`), Docker sandbox, LiteLLM provider config
+  (OpenAI/Anthropic/Vertex/Bedrock/Azure/local/ChatGPT-sub), targets (repo/URL/domain/IP,
+  `--target-list`, `--mount`), `--scan-mode quick|standard|deep`, `--scope-mode diff`/`--diff-base`,
+  `--instruction[-file]`, headless `-n` with CI exit codes, `--max-budget-usd`, the `strix view`
+  dashboard + live steering, output layout, GitHub Actions/GitLab/Jenkins CI, and safety.
+- **`pentest-scanner` agent** (security sub-scanner, tier `specialist`) — a **dynamic** scanner that
+  runs a real, **PoC-validated** penetration test by driving whichever authorized tool is installed:
+  **Strix** (flexible default), **Shannon** (white-box source→exploit), or **ZAP** (DAST + PDF). It is
+  **conditional and authorization-gated**: an explicit **preflight** (dynamic pentest requested + an
+  authorized **non-production** target + Docker + tool + LLM key) must pass, otherwise it returns
+  `SKIPPED` and **does not block** the Security Clear gate — so pipelines without pentest tooling behave
+  exactly as before. Reports only; PoC-proven Critical/High findings feed the gate and route via the
+  Defect Loop.
+
+### Changed
+
+- **Wiring (both entry paths):** `security-reviewer` now lists `pentest-scanner` as the optional fifth
+  (dynamic) scanner and dispatches it conditionally; `orchestrator` Stage 5.4 documents the conditional
+  dispatch and adds the three pentest skills to its Security skill-routing row; `tester` points a user's
+  *pentest* request to `pentest-scanner` (out of the functional-testing lane).
+- **Profile promotion:** `pentest-scanner` + the three pentest skills (`strix-ai-pentest`,
+  `shannon-ai-pentest`, `zap-vapt-scanning`) are now installed at the **standard** tier (previously
+  Shannon/ZAP were enterprise-only), co-locating the agent with the skills it drives. `lean ⊂ standard ⊂
+  enterprise` is preserved.
+- **Counts:** agents **28 → 29**, skills **108 → 109** (57 core + **52** collection). Docs updated
+  (`README.md`, `docs/agents.md`, `docs/stack-skills/README.md`, `docs/skill-audit.md`,
+  `docs/influences.md`).
+
+### Not adopted (deliberately)
+
+- **Vendoring Strix's source** — even though Apache-2.0 permits it, claude-kit ships configuration/prose,
+  not tools; the skill stays documentation-only and you install `strix-agent` yourself (same posture as
+  the AGPL `shannon-ai-pentest` and the bundled-but-thin `zap-vapt-scanning`).
+- **Making pentest a mandatory gate scanner** — it would break every pipeline lacking Docker, an LLM key,
+  or an authorized target, and would risk auto-attacking targets. It is opt-in and non-blocking instead.
+- **Auto-running against live targets** — the `pentest-scanner` preflight refuses production / unstated
+  authorization / untrusted targets; a real pentest only runs on explicit request against an authorized
+  non-production target.
+- **A bundled Strix GitHub Actions workflow or a Strix-platform/MCP integration** — the skill documents
+  the CI patterns and the managed platform ([app.strix.ai](https://app.strix.ai)) rather than shipping a
+  workflow file or a new MCP fragment (no agent consumer, avoids vendor sprawl).
+
 ## [0.69.0] — 2026-07-26
 
 **Absorption pass over [pborenstein/handoff](https://github.com/pborenstein/handoff) (user-named

{claude_code_kit-0.69.0 → claude_code_kit-0.73.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.69.0
+Version: 0.73.0
 Summary: Cookiecutter-style scaffolder for an autonomous Claude Code SDLC 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, 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
@@ -145,10 +145,11 @@ claude-kit init --defaults      # non-interactive: React + Python/FastAPI + Post
 | Area | What you get |
 |------|--------------|
 | 🔁 **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** | **28** 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 + **108** context-activated skills (57 core + 51 stack-collection), pulled into context on demand |
+| 🤖 **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 + **111** context-activated skills (58 core + 53 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 |
-| 🛠️ **Hooks & guards** | **18** event hooks — deterministic safety guards and advisory warnings — that no-op gracefully without `jq` |
+| 🛠️ **Hooks & guards** | **19** 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 |
 
 Profiles (`lean` · `standard` · `enterprise`), team scopes, autonomy levels, and org capability
@@ -216,6 +217,64 @@ capture your own publishable run: [`docs/capture-a-real-run.md`](docs/capture-a-
 
 ---
 
+## Parallel lanes and the live ticket board
+
+The orchestrator never writes code — it splits work, spawns agents, and refuses to advance a gate.
+Once the spec clears the EM gate, `story-planner` produces stories and marks which ones are
+**independent**. Each independent story becomes a **lane**: its own ticket, its own branch, its own
+implement → review → test loop, running at the same time as the others.
+
+```mermaid
+flowchart LR
+    STORY["story-planner<br/>(marks independents)"] --> TK["One OPEN ticket per story"]
+    TK --> L1["Lane A — backend<br/>senior-backend-dev → code-review"]
+    TK --> L2["Lane B — frontend<br/>senior-frontend-dev → code-review"]
+    TK --> L3["Lane C — …"]
+    L1 --> MR{{"Gate: Merge Reviewer<br/>(the join)"}}
+    L2 --> MR
+    L3 --> MR
+    MR --> T1["unit-tester"]
+    MR --> T2["e2e-tester"]
+    MR --> T3["senior-tester<br/>(independent verification)"]
+    T1 --> TCG{{"Gate: Test coverage<br/>+ Devil's Advocate"}}
+    T2 --> TCG
+    T3 --> TCG
+    TCG --> DONE["Tickets → DONE,<br/>commits linked"]
+```
+
+Two things make this observable rather than a black box:
+
+- **A ticket is opened before any lane starts** and accumulates a work-log entry per meaningful step —
+  what changed, why, which files, what was decided (`ticketing-and-traceability`). Commits carry the
+  ticket id, so `git log --grep=` walks it in either direction.
+- **Lanes are branches, and telemetry is keyed on the branch.** `claude-kit tickets` reads the Claude
+  Code session transcripts (metadata only — usage counters, model id, agent name, timestamp) and
+  attributes tokens, cache, elapsed time, and the agent that ran to whichever ticket names that branch.
+
+### The board
+
+```bash
+claude-kit tickets                # board: one row per ticket, in-progress first
+claude-kit tickets --watch 5      # re-render every 5s while a run is in flight
+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
+```
+
+`--html` writes a self-contained page to `.claude/state/ticket-board.html` and prints a `file://` URL.
+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:
+
+![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)
+
+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
+because they routinely differ by three orders of magnitude. Full reference:
+[`docs/cli.md`](docs/cli.md#the-ticket-chart-claude-kit-tickets).
+
+---
+
 ## Profiles & what lands in your project
 
 The profile you pick decides how much lands in `.claude/`. Measured on a React + FastAPI +
@@ -251,7 +310,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, 28 agents, 108 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, 111 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.69.0 → claude_code_kit-0.73.0}/README.md

@@ -112,10 +112,11 @@ claude-kit init --defaults      # non-interactive: React + Python/FastAPI + Post
 | Area | What you get |
 |------|--------------|
 | 🔁 **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** | **28** 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 + **108** context-activated skills (57 core + 51 stack-collection), pulled into context on demand |
+| 🤖 **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 + **111** context-activated skills (58 core + 53 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 |
-| 🛠️ **Hooks & guards** | **18** event hooks — deterministic safety guards and advisory warnings — that no-op gracefully without `jq` |
+| 🛠️ **Hooks & guards** | **19** 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 |
 
 Profiles (`lean` · `standard` · `enterprise`), team scopes, autonomy levels, and org capability
@@ -183,6 +184,64 @@ capture your own publishable run: [`docs/capture-a-real-run.md`](docs/capture-a-
 
 ---
 
+## Parallel lanes and the live ticket board
+
+The orchestrator never writes code — it splits work, spawns agents, and refuses to advance a gate.
+Once the spec clears the EM gate, `story-planner` produces stories and marks which ones are
+**independent**. Each independent story becomes a **lane**: its own ticket, its own branch, its own
+implement → review → test loop, running at the same time as the others.
+
+```mermaid
+flowchart LR
+    STORY["story-planner<br/>(marks independents)"] --> TK["One OPEN ticket per story"]
+    TK --> L1["Lane A — backend<br/>senior-backend-dev → code-review"]
+    TK --> L2["Lane B — frontend<br/>senior-frontend-dev → code-review"]
+    TK --> L3["Lane C — …"]
+    L1 --> MR{{"Gate: Merge Reviewer<br/>(the join)"}}
+    L2 --> MR
+    L3 --> MR
+    MR --> T1["unit-tester"]
+    MR --> T2["e2e-tester"]
+    MR --> T3["senior-tester<br/>(independent verification)"]
+    T1 --> TCG{{"Gate: Test coverage<br/>+ Devil's Advocate"}}
+    T2 --> TCG
+    T3 --> TCG
+    TCG --> DONE["Tickets → DONE,<br/>commits linked"]
+```
+
+Two things make this observable rather than a black box:
+
+- **A ticket is opened before any lane starts** and accumulates a work-log entry per meaningful step —
+  what changed, why, which files, what was decided (`ticketing-and-traceability`). Commits carry the
+  ticket id, so `git log --grep=` walks it in either direction.
+- **Lanes are branches, and telemetry is keyed on the branch.** `claude-kit tickets` reads the Claude
+  Code session transcripts (metadata only — usage counters, model id, agent name, timestamp) and
+  attributes tokens, cache, elapsed time, and the agent that ran to whichever ticket names that branch.
+
+### The board
+
+```bash
+claude-kit tickets                # board: one row per ticket, in-progress first
+claude-kit tickets --watch 5      # re-render every 5s while a run is in flight
+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
+```
+
+`--html` writes a self-contained page to `.claude/state/ticket-board.html` and prints a `file://` URL.
+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:
+
+![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)
+
+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
+because they routinely differ by three orders of magnitude. Full reference:
+[`docs/cli.md`](docs/cli.md#the-ticket-chart-claude-kit-tickets).
+
+---
+
 ## Profiles & what lands in your project
 
 The profile you pick decides how much lands in `.claude/`. Measured on a React + FastAPI +
@@ -218,7 +277,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, 28 agents, 108 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, 111 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.69.0 → claude_code_kit-0.73.0}/agents/orchestrator.md

@@ -338,6 +338,28 @@ code is written.
 
 ---
 
+### Stage TK: Ticket Creation (after story breakdown, before implementation)
+
+With the plan approved by the personas and the story breakdown past its coverage gate, open a ticket
+for each story **before** spawning any implementation agent — this is the "create a ticket before
+starting work" discipline. Using `ticketing-and-traceability`:
+
+- **Create** one **OPEN** ticket per story at `docs/project/tickets/<PREFIX>-<N>-<slug>.md` (allocate
+  `N` from `docs/project/tickets/index.json`), seeded from the story: the *why* (traced to the spec
+  requirement ids), links to the spec / design-spec / any ADRs, and the story's declared file scope.
+- **Update the wiki** indexes under `docs/project/wiki/` (functional → the spec, technical → the
+  design-spec, decisions → the ADRs) so they point at the new documents — index, never duplicate.
+- **Optional external mirror**: if the project runs an issue tracker, hand the tickets to
+  `task-tracker-sync` to reflect them in GitHub/Linear/Jira; the local store stays authoritative.
+- **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.
+
+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.
+
+---
+
 ### FORK POINT 2: Implementation (Mode B only)
 
 #### Lane A (Frontend Implementation):
@@ -354,6 +376,9 @@ code is written.
   with the offending file list. The lane does not reach the Code Reviewer until *your own* run
   is green. (Structural form of the evidence rule: a verdict must be backed by output you
   captured — `.claude/rules/quality-gates.md` §2.5.)
+- **Work-log the step** on the story's ticket (`ticketing-and-traceability`): what changed, why, and
+  the files from `git diff --name-only`; advance the ticket `OPEN → IN PROGRESS`. Skip silently if the
+  ticket store isn't in use.
 
 **[4b-FE] SDLC Code Reviewer:**
 - **Spawn**: `sdlc-code-reviewer` for the frontend diff.
@@ -397,6 +422,7 @@ Developer before any reviewer spawns.
   - Shared types/enums are consistent
   - README.md and documentation updated for both stacks
 - **Gate**: `VERIFIED` signal from merge-reviewer.
+- On `VERIFIED`, advance each implemented story's ticket to **IN REVIEW** (`ticketing-and-traceability`).
 
 ---
 
@@ -466,7 +492,8 @@ For backend-only or frontend-only tasks, spawn a single tester in `full` mode
 
 ### Stage 5.4: Security (gate: Security Clear) — after test coverage, before DevOps
 - **Spawn**: `security-reviewer` with the merged code + spec.
-- It dispatches four sub-scanners **in parallel** — `secret-scanner`, `dependency-scanner`, `owasp-reviewer`, `policy-validator` — and aggregates findings by severity.
+- It dispatches four **static** sub-scanners **in parallel** — `secret-scanner`, `dependency-scanner`, `owasp-reviewer`, `policy-validator` — and aggregates findings by severity.
+- **Dynamic pentest (conditional)**: when the user requests a penetration test, or an authorized **non-production** target is available, `security-reviewer` also dispatches `pentest-scanner` — a real, dynamic pentest driving `strix-ai-pentest` / `shannon-ai-pentest` / `pentesterflow-pentest` / `zap-vapt-scanning` and returning **PoC-validated** findings. It self-runs a preflight (authorized non-prod target + Docker + tool + LLM key) and returns `SKIPPED` (**non-blocking**) when not applicable; its proven Critical/High findings join the gate. This also serves an explicit user "run a pentest" request.
 - **Project-specific auto-Criticals** (never downgrade): authorization leak (missing scoping for multi-tenant systems), hardcoded secret, secret/PII in logs, banned blocking calls in async code paths (if project is async).
 - On Critical/High/Medium → route to the relevant dev lane via the **Defect Loop**; re-run only the affected scanner after the fix (max 2 security cycles).
 - **Gate**: `SECURITY CLEAR`.
@@ -500,6 +527,8 @@ For backend-only or frontend-only tasks, spawn a single tester in `full` mode
 ### Stage 6: PR Raiser (Always Sequential)
 - **Spawn**: `pr-raiser` with all code + test evidence.
 - Documentation checks, lint, build, tests, commit formatting.
+- **Tickets**: `pr-raiser` references each commit's ticket id, records the commits + PR URL on the
+  tickets, and moves them to **DONE** (`ticketing-and-traceability`). Skip when the ticket store isn't in use.
 - **Expected output**: PR URL + status report.
 - **On failure**: Route back to the appropriate Developer lane.
 
@@ -610,15 +639,16 @@ decision tree is the fallback router). Baseline map:
 |----------------|--------------------|
 | Spec & dev docs | `spec-driven-development` · `interview-me` (if ambiguous) · `scope` |
 | Story planning | `planning-and-task-breakdown` |
+| Ticketing / traceability (Stage TK) | `ticketing-and-traceability` · `documentation-and-adrs` (link ADRs) · `task-tracker-sync` (optional external mirror) |
 | Design (UI) | `ui-ux-design` · `component-design` |
 | Implementation | `incremental-implementation` · `context-engineering` · the stack overlay skills for the lane (e.g. API lane → `api-and-interface-design`; UI lane → `frontend-ui-engineering`) · `doubt-driven-development` when stakes are high/unfamiliar |
 | Code review | `code-review-and-quality` · `over-engineering-review` (when warranted) |
 | Testing | `test-driven-development` · `unit-test` · `browser-testing-with-devtools` (UI) · `test-plan-review` (senior) |
-| Security | `security-and-hardening` · `security-verification` · `threat-model` (new surface) |
+| Security | `security-and-hardening` · `security-verification` · `threat-model` (new surface) · `strix-ai-pentest` / `shannon-ai-pentest` / `pentesterflow-pentest` / `zap-vapt-scanning` (dynamic pentest — on request / authorized target) |
 | Audit workers (Mode E Wave 0) | read-only exploration + `scope`; report format per the manifest |
 | Gate runners | `smoke-test` / `manual-test` / the project's regression suite |
 | Debugging / defect loop | `debugging-and-error-recovery` · `bug-hunt` |
-| PR / delivery | `git-workflow-and-versioning` · `shipping-and-launch` |
+| PR / delivery | `git-workflow-and-versioning` · `ticketing-and-traceability` (link commits · close tickets) · `shipping-and-launch` |
 | Knowledge closeout (Mode E final wave) | `refresh-docs` · `documentation-and-adrs` · `remember` · `consolidate-learnings` |
 
 Only route to skills that are actually installed (profiles install different subsets); when a listed