claude-code-kit 0.72.0__tar.gz → 0.74.0__tar.gz

{claude_code_kit-0.72.0 → claude_code_kit-0.74.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.72.0",
+      "version": "0.74.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

{claude_code_kit-0.72.0 → claude_code_kit-0.74.0}/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.72.0",
+  "version": "0.74.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.72.0 → claude_code_kit-0.74.0}/CHANGELOG.md

@@ -4,6 +4,181 @@ 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.74.0] — 2026-07-28
+
+**The kit learns to build AI products, not just to be one — 63 attributed digests from a 72-item
+reading list, four new LLM-application skills, and three targeted extensions to existing guidance.**
+The measured thesis of the pass: the kit covered AI thoroughly from the *"I am an agent"* side and
+almost not at all from the *"I am building an AI product"* side.
+
+### Added
+
+- **Four new stack-collection skills** carrying the 39 LLM-application digests:
+  - **`llm-inference-optimization`** (16 digests) — the prefill/decode phase split as the first
+    diagnostic, quantization's *task-shaped* accuracy cost, speculative-decoding economics, KV-cache
+    sizing, prefix-cache reuse and eviction. Where the sources disagree (they do, on five points
+    including INT4 accuracy loss and whether spec-decoding composes with quantization) the skill says
+    so rather than picking a winner.
+  - **`rag-and-model-tuning`** (10) — the retrieve-vs-tune adaptation ladder, structural chunking,
+    hybrid dense+lexical search with rank fusion, reranking, and the separation of retrieval quality
+    from answer quality in evaluation.
+  - **`llm-gateway-and-routing`** (8) — request tiering, fallback chains, health-aware failover,
+    model deprecation as a planned event rather than an incident, and schema-constrained outputs as
+    the contract that makes provider substitution safe.
+  - **`llm-caching-strategies`** (5) — provider prompt/prefix caching versus application-side semantic
+    caching, and the correctness rule that a similarity score can *never* authorize a cache hit on its
+    own, because an embedding encodes no tenant, permission set, or document version.
+- **[`docs/ai-engineering-articles.md`](docs/ai-engineering-articles.md)** — coverage map for all 72
+  maintainer-supplied URLs. Every row is accounted for, including the ones that shipped nothing.
+- **63 attributed `aie-*` reference digests** — 24 into six existing skills' `references/`
+  (`context-engineering` 10, `langfuse-llm-tracing` 6, `security-and-hardening` 5, and one each in
+  `threat-model`, `multi-tenancy-patterns`, `debugging-and-error-recovery`), 39 into the four new
+  skills above.
+
+### Changed
+
+- **`rules/agent-guardrails.md` §4** — a tool's *definition* is now treated as untrusted input, not
+  only its output. All 20 prior MCP mentions framed MCP as a supply-chain intake problem; this adds
+  the layer the model re-reads every turn: description-borne instructions, **rug-pull** mutability
+  after approval (re-verify at invocation, not only at load), cross-server **name shadowing**, and
+  read primitives escalating into write primitives.
+- **`skills/multi-tenancy-patterns`** — a new *Agent and LLM Tenancy* section. The skill was entirely
+  database-layer; an agent boundary miss is unbounded because leaked rows become reasoning and then
+  actions. Covers structural (non-adversarial) retrieval leakage, re-applying authorization on every
+  expansion hop, prefix/semantic caches as cross-tenant side channels, and telemetry as its own leak
+  surface.
+- **`rules/goal-setting-and-monitoring.md` §4** — silent-failure attribution. Correction is not
+  attribution: a retry that succeeds travels an independent path and explains nothing. Adds
+  prefix-preserving replay, faithfulness gating, and *earliest decisive step* targeting — plus the
+  instrumentation consequence that spans must record enough to **replay** a node, not merely read it.
+- **`docs/stack-skills/README.md`** — collection count **53 → 57**, four catalog rows, four routing
+  hints.
+
+### The measured finding
+
+Coverage was lopsided in a way that was worth measuring before writing anything: **33 files already
+touch OpenTelemetry, 20 touch MCP, 5 prompt injection, 4 structured output — while RAG, prompt/semantic
+caching and quantization had literally zero.** Accordingly 14 of the 20 agent-operation articles came
+back as *reinforces* rather than *new*, and the genuinely-new core gaps are narrow and specific:
+
+- **Harness guarantees as replayable certificates** decoupled from model choice — claimed as a gap by
+  the digests, and the one that did not survive verification (see below).
+- **MCP as a protocol with its own security model** (OAuth delegation; read-only Resources escalating
+  into privileged Tool calls) rather than only a supply-chain intake problem, which is how all 20
+  existing MCP mentions frame it.
+- **Agent-tenant isolation as a compute concern** — `multi-tenancy-patterns` is entirely database-layer
+  (RLS, per-tenant schemas, tenant-scoped caching).
+- **Silent-failure attribution in agent traces** — `debugging-and-error-recovery` cannot reach these
+  because its triage begins at "Reproduce".
+
+Each was re-verified by grep rather than taken on the digesting agent's word — and that verification
+**killed one of the four and narrowed another**. `rules/tool-design.md` already cites the canonical
+harness article by name, so the certificates gap was largely illusory; and
+`rules/goal-setting-and-monitoring.md` already names the GenAI semantic conventions (an earlier grep
+missed it only because the phrase wraps a line), leaving a much narrower gap than the digests claimed.
+Three of four shipped; the fourth was dropped on the evidence.
+
+### Not adopted (deliberately)
+
+- **A fourth `catalog/stacks.yaml` kind for LLM applications.** This was the original plan and it was
+  wrong on a point of fact: `stacks.yaml` supports exactly `frontend`/`backend`/`database`,
+  `models.Selection` hard-codes five stack fields, and `catalog.py` carries dedicated
+  `_frontend()`/`_backend()` functions — so a fourth axis is a **code** change across `Selection`,
+  `prompts.py`, `resolve()` (which golden rule #7 requires stay branch-free), `render.py` and
+  `export.py`, not the data change it appeared to be. Every existing stack id is a language,
+  framework, or engine; none is a *domain*. The stack **collection** already hosts LLM content
+  (`anthropic-vertex-integration`, `langfuse-llm-tracing`) and needs no catalog change at all, so
+  that is where this went.
+- **Harness guarantees as replayable certificates.** Dropped after verification, not after debate —
+  `tool-design.md` already cites that source, and a near-duplicate section is exactly how skill
+  auto-selection gets diluted.
+- **LLM-serving guidance in the stack-agnostic core.** Quantization and KV-cache policy are domain
+  knowledge, not SDLC practice — they belong in the collection, which is opt-in, never in the
+  always-installed rule set.
+- **Six sources whose hosts refuse automated clients** — `preprints.org` (×2), `media.defense.gov`,
+  `deepchecks.com`, `tblocks.com`, and an OpenReview paper behind a Cloudflare challenge. Recorded as
+  honest not-fetched rows, never bypassed. The digesting agent for the OpenReview paper declined to
+  substitute a similarly-titled arXiv paper it could not confirm was the same work.
+- **Raw captures.** Never committed; the gitignored scratch is deleted, and each digest carries a
+  three-item fidelity check instead of quotations.
+
+## [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

{claude_code_kit-0.72.0 → claude_code_kit-0.74.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.72.0
+Version: 0.74.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
@@ -146,9 +146,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 + **111** context-activated skills (58 core + 53 stack-collection), pulled into context on demand |
+| 📐 **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 |
-| 🛠️ **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, 29 agents, 111 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, 115 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.72.0 → claude_code_kit-0.74.0}/README.md

@@ -113,9 +113,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 + **111** context-activated skills (58 core + 53 stack-collection), pulled into context on demand |
+| 📐 **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 |
-| 🛠️ **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, 29 agents, 111 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, 115 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.72.0 → claude_code_kit-0.74.0}/agents/pr-raiser.md

@@ -128,6 +128,11 @@ After the PR is created, **close the tickets**: set each to DONE and record the
 on the ticket and in `docs/project/tickets/index.json` (`ticketing-and-traceability`). Skip when no
 local ticket store is in use.
 
+If the `claude-kit` CLI is available, run `claude-kit tickets <PREFIX>-<N>` before closing and copy the
+final figures (requests, tokens, cache, model, elapsed) into the ticket's work log. They are derived
+from the session transcript, which lives outside the repo and will not survive it — writing them onto
+the ticket is what makes the cost part of the permanent record.
+
 ### Step 7: Report
 Return to the Orchestrator:
 - PR URL

{claude_code_kit-0.72.0 → claude_code_kit-0.74.0}/catalog/profiles.yaml

@@ -104,7 +104,9 @@ profiles:
     # NOTE: the agent-side capture hooks (capture-learnings / -catchup / -stop) are deliberately NOT
     # listed here — they are installed by the init-time `capture_mode` choice via catalog/capture.yaml
     # (see catalog._apply_capture_mode), not by profile membership. load-learnings (recall) stays.
-    hooks: [load-continuity, load-learnings, load-autonomy, guard-rm-rf, guard-push-main, guard-destructive-git, protect-secrets, guard-commit-secrets, warn-shared-modules, warn-llm-io, lint-fix, type-check]
+    # capture-ticket-telemetry rides with the ticketing-and-traceability skill above: it is unrelated
+    # to capture_mode, self-throttles, and no-ops until a ticket store exists.
+    hooks: [load-continuity, load-learnings, load-autonomy, guard-rm-rf, guard-push-main, guard-destructive-git, protect-secrets, guard-commit-secrets, warn-shared-modules, warn-llm-io, lint-fix, type-check, capture-ticket-telemetry]
 
   enterprise:
     label: "Enterprise — adds DevOps, Observability, full audit + acceptance"

claude_code_kit-0.74.0/docs/ai-engineering-articles.md

@@ -0,0 +1,170 @@
+# AI-engineering articles — coverage map
+
+Source: a reading list of 72 AI-engineering URLs supplied directly by the maintainer on 2026-07-28
+(articles © their respective publishers). Fetched via a browser User-Agent; five hosts refuse
+automated clients and one sits behind a Cloudflare challenge — those are honest "not fetched" rows,
+never bypassed. Ideas absorbed in the kit's own words with attribution; no text or code reproduced
+(see `docs/influences.md`). Digests are named `aie-*.md`, numbered by this map's global row index.
+
+Digests for **agent-operation** topics ship into the owning skill's `references/`. Digests for
+**LLM-application engineering** (quantization, KV cache, caching, RAG, gateways, provider failover)
+ship into four new **stack-collection skills** — `llm-inference-optimization`,
+`llm-caching-strategies`, `rag-and-model-tuning`, and `llm-gateway-and-routing`. That material is
+stack-specific domain knowledge, and golden rule #1 keeps it out of the stack-agnostic core; the
+collection is where such knowledge already lives, so no `catalog/stacks.yaml` change was needed.
+
+## Harness engineering
+
+| # | Item | Fetched | Digest | Kit outcome |
+|---|------|---------|--------|-------------|
+| 1 | [Harness Engineering for LLM Agents: A Survey](https://openreview.net/forum?id=1VJLY0hAFT) | no | — | not fetched (cloudflare challenge) — honest row, no digest |
+| 2 | [What is an AI Agent Harness?](https://www.databricks.com/blog/ai-harness) | yes | `skills/context-engineering/references/aie-002-what-is-an-ai-agent-harness.md` | reference digest in `context-engineering` |
+| 3 | [Harness Engineering as Categorical Architecture: Structural Guarantees Are Harness-Level Properties](https://arxiv.org/html/2605.12239v1) | yes | `skills/context-engineering/references/aie-003-harness-engineering-as-categorical-architecture.md` | reference digest in `context-engineering` |
+| 4 | [Harness Engineering: The Missing Layer Between LLMs and Production Systems](https://ranjankumar.in/harness-engineering-the-missing-layer-between-llms-and-production-systems) | yes | `skills/context-engineering/references/aie-004-harness-engineering-the-missing-layer-between-llms-and-pro.md` | reference digest in `context-engineering` |
+| 5 | [A lot of conversation around Harness Engineering, what does that even mean? (Reddit r/AI_Agents)](https://www.reddit.com/r/AI_Agents/comments/1ujigq2/a_lot_of_conversation_around_harness_engineering/) | yes | `skills/context-engineering/references/aie-005-a-lot-of-conversation-around-harness-engineering-what-does.md` | reference digest in `context-engineering` |
+| 6 | [Harness Engineering for LLM Agents: A Survey (preprints.org)](https://www.preprints.org/manuscript/202606.2203) | no | — | deduplicated — duplicate of the OpenReview row above (same survey) |
+
+## Context engineering vs prompt engineering
+
+| # | Item | Fetched | Digest | Kit outcome |
+|---|------|---------|--------|-------------|
+| 1 | [Context engineering vs. prompt engineering](https://www.elastic.co/search-labs/blog/context-engineering-vs-prompt-engineering) | yes | `skills/context-engineering/references/aie-007-context-engineering-vs-prompt-engineering-elastic.md` | reference digest in `context-engineering` |
+| 2 | [Context engineering vs prompt engineering: the difference](https://redis.io/blog/context-engineering-vs-prompt-engineering/) | yes | `skills/context-engineering/references/aie-008-context-engineering-vs-prompt-engineering-the-difference-r.md` | reference digest in `context-engineering` |
+| 3 | [Context engineering vs prompt engineering: key differences explained](https://www.glean.com/perspectives/context-engineering-vs-prompt-engineering-key-differences-explained) | yes | `skills/context-engineering/references/aie-009-context-engineering-vs-prompt-engineering-key-differences.md` | reference digest in `context-engineering` |
+| 4 | [Context Engineering vs Prompt Engineering (DataHub)](https://datahub.com/blog/context-engineering-vs-prompt-engineering/) | yes | `skills/context-engineering/references/aie-010-context-engineering-vs-prompt-engineering-datahub.md` | reference digest in `context-engineering` |
+| 5 | [Context Engineering vs Prompt Engineering (Abstracta)](https://abstracta.us/blog/ai/context-engineering-vs-prompt-engineering) | yes | `skills/context-engineering/references/aie-011-context-engineering-vs-prompt-engineering-abstracta.md` | reference digest in `context-engineering` |
+
+## LLM and agent observability
+
+| # | Item | Fetched | Digest | Kit outcome |
+|---|------|---------|--------|-------------|
+| 1 | [OpenTelemetry for AI Observability: What It Covers and Where It Stops](https://www.fiddler.ai/blog/opentelemetry-ai-observability-guide) | yes | `skills/langfuse-llm-tracing/references/aie-012-opentelemetry-for-ai-observability-what-it-covers-and-wher.md` | reference digest in `langfuse-llm-tracing` |
+| 2 | [OpenTelemetry for LLMs: how we instrument a multi-provider AI gateway](https://www.truefoundry.com/blog/opentelemetry-llm-gateway-instrumentation) | yes | `skills/langfuse-llm-tracing/references/aie-013-opentelemetry-for-llms-instrumenting-a-multi-provider-ai-g.md` | reference digest in `langfuse-llm-tracing` |
+| 3 | [4 best LLM gateways for observability: tracing, cost attribution, and debuggability](https://www.braintrust.dev/articles/best-llm-gateways-observability-2026) | yes | `skills/langfuse-llm-tracing/references/aie-014-best-llm-gateways-for-observability-tracing-cost-attributi.md` | reference digest in `langfuse-llm-tracing` |
+| 4 | [LLM Observability with OpenTelemetry — unified AI application tracing guide](https://docs.base14.io/guides/ai-observability/llm-observability/) | yes | `skills/langfuse-llm-tracing/references/aie-015-llm-observability-with-opentelemetry-unified-tracing-guide.md` | reference digest in `langfuse-llm-tracing` |
+| 5 | [LLM Observability (glossary)](https://www.guild.ai/glossary/llm-observability) | yes | `skills/langfuse-llm-tracing/references/aie-016-llm-observability-glossary.md` | reference digest in `langfuse-llm-tracing` |
+| 6 | [The 2026 Guide To Agent Observability Tools](https://montecarlo.ai/blog-agent-observability-tools) | yes | `skills/langfuse-llm-tracing/references/aie-017-the-2026-guide-to-agent-observability-tools.md` | reference digest in `langfuse-llm-tracing` |
+
+## Model routing, failover and gateways
+
+| # | Item | Fetched | Digest | Kit outcome |
+|---|------|---------|--------|-------------|
+| 1 | [LLM routing in production: choosing the right model for every request](https://blog.logrocket.com/llm-routing-right-model-for-requests/) | yes | `skills/llm-gateway-and-routing/references/aie-018-llm-routing-in-production-choosing-the-right-model-for-eve.md` | reference digest in `llm-gateway-and-routing` |
+| 2 | [LLM Failover & Load Balancing for Provider Outages](https://www.truefoundry.com/blog/llm-failover-load-balancing-provider-outages) | yes | `skills/llm-gateway-and-routing/references/aie-019-llm-failover-and-load-balancing-for-provider-outages.md` | reference digest in `llm-gateway-and-routing` |
+| 3 | [Adaptive Model Routing and Fallback Logic: routing around LLM provider outages with Bifrost](https://dev.to/kuldeep_paul/adaptive-model-routing-and-fallback-logic-routing-around-llm-provider-outages-with-bifrost-4g3m) | yes | `skills/llm-gateway-and-routing/references/aie-020-adaptive-model-routing-and-fallback-logic-routing-around-p.md` | reference digest in `llm-gateway-and-routing` |
+| 4 | [Build an LLM Fallback Layer Before Your Model Vanishes](https://theroadtoenterprise.com/blog/model-agnostic-ai-layer-fallbacks) | yes | `skills/llm-gateway-and-routing/references/aie-021-build-an-llm-fallback-layer-before-your-model-vanishes.md` | reference digest in `llm-gateway-and-routing` |
+| 5 | [Three-Tier LLM Routing: Fast, Smart, and Power Model Stacks](https://www.mindstudio.ai/blog/set-up-ai-model-router-llm-stack-c2610) | yes | `skills/llm-gateway-and-routing/references/aie-022-three-tier-llm-routing-fast-smart-and-power-model-stacks.md` | reference digest in `llm-gateway-and-routing` |
+| 6 | [What our provider fallback actually looks like after a few months in prod (Reddit r/LLMDevs)](https://www.reddit.com/r/LLMDevs/comments/1ulbef7/what_our_provider_fallback_actually_looks_like/) | yes | `skills/llm-gateway-and-routing/references/aie-023-what-our-provider-fallback-actually-looks-like-after-month.md` | reference digest in `llm-gateway-and-routing` |
+
+## Agent and MCP security
+
+| # | Item | Fetched | Digest | Kit outcome |
+|---|------|---------|--------|-------------|
+| 1 | [Security Best Practices (Model Context Protocol, official)](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices) | yes | `skills/security-and-hardening/references/aie-024-model-context-protocol-security-best-practices.md` | reference digest in `security-and-hardening` |
+| 2 | [Systematization of Knowledge: Security and Safety in the Model Context Protocol Ecosystem](https://arxiv.org/html/2512.08290v2) | yes | `skills/threat-model/references/aie-025-sok-security-and-safety-in-the-model-context-protocol-ecos.md` | reference digest in `threat-model` |
+| 3 | [Prompt Injection in Production Agents: 2026 Taxonomy](https://www.digitalapplied.com/blog/prompt-injection-production-agents-2026-taxonomy) | yes | `skills/security-and-hardening/references/aie-026-prompt-injection-in-production-agents-a-2026-taxonomy.md` | reference digest in `security-and-hardening` |
+| 4 | [Model Context Protocol: Security Risks & Mitigations](https://socprime.com/blog/mcp-security-risks-and-mitigations/) | yes | `skills/security-and-hardening/references/aie-027-model-context-protocol-security-risks-and-mitigations.md` | reference digest in `security-and-hardening` |
+| 5 | [AI Agent Data Leakage: Secrets Management and Privacy Risks](https://rafter.so/blog/ai-agent-data-leakage-secrets-management) | yes | `skills/security-and-hardening/references/aie-028-ai-agent-data-leakage-secrets-management-and-privacy-risks.md` | reference digest in `security-and-hardening` |
+| 6 | [Multi-tenant isolation for AI agents: security architecture guide](https://blaxel.ai/blog/multi-tenant-isolation-ai-agents) | yes | `skills/multi-tenancy-patterns/references/aie-029-multi-tenant-isolation-for-ai-agents-security-architecture.md` | reference digest in `multi-tenancy-patterns` |
+| 7 | [LLM Security — Prompt Injection, Data Leakage & Compliance (2026)](https://myengineeringpath.dev/genai-engineer/llm-security/) | yes | `skills/security-and-hardening/references/aie-030-llm-security-prompt-injection-data-leakage-and-compliance.md` | reference digest in `security-and-hardening` |
+| 8 | [Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation (CSI)](https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF) | no | — | not fetched (http=403) — honest row, no digest |
+
+## Structured outputs
+
+| # | Item | Fetched | Digest | Kit outcome |
+|---|------|---------|--------|-------------|
+| 1 | [LLM Structured Outputs: Schema Validation for Real Pipelines (2026)](https://collinwilkins.com/articles/structured-output) | yes | `skills/llm-gateway-and-routing/references/aie-032-llm-structured-outputs-schema-validation-for-real-pipeline.md` | reference digest in `llm-gateway-and-routing` |
+| 2 | [guidance-ai/llguidance: super-fast structured outputs](https://github.com/guidance-ai/llguidance) | yes | `skills/llm-gateway-and-routing/references/aie-033-llguidance-super-fast-structured-outputs.md` | reference digest in `llm-gateway-and-routing` |
+
+## Agent failure attribution
+
+| # | Item | Fetched | Digest | Kit outcome |
+|---|------|---------|--------|-------------|
+| 1 | [REFLECT: Intervention-Supported Error Attribution for Silent Failures in LLM Agent Traces](https://arxiv.org/html/2606.09071v1) | yes | `skills/debugging-and-error-recovery/references/aie-034-reflect-intervention-supported-error-attribution-for-silen.md` | reference digest in `debugging-and-error-recovery` |
+
+## Multi-agent architecture
+
+| # | Item | Fetched | Digest | Kit outcome |
+|---|------|---------|--------|-------------|
+| 1 | [How I Built an AI Agent Architecture — a practical multi-agent LLM for newsletter generation](https://thomasthelliez.com/blog/how-i-built-an-ai-agent-architecture/) | yes | `skills/context-engineering/references/aie-035-how-i-built-an-ai-agent-architecture-a-practical-multi-age.md` | reference digest in `context-engineering` |
+
+## Quantization
+
+| # | Item | Fetched | Digest | Kit outcome |
+|---|------|---------|--------|-------------|
+| 1 | [Accelerating LLM inference with post-training weight and activation quantization using AWQ and GPTQ on Amazon SageMaker AI](https://aws.amazon.com/blogs/machine-learning/accelerating-llm-inference-with-post-training-weight-and-activation-using-awq-and-gptq-on-amazon-sagemaker-ai/) | yes | `skills/llm-inference-optimization/references/aie-038-accelerating-llm-inference-with-post-training-quantization.md` | reference digest in `llm-inference-optimization` |
+| 2 | [LLM Quantization Explained: INT4, INT8, FP8, AWQ, and GPTQ in 2026](https://vrlatech.com/llm-quantization-explained-int4-int8-fp8-awq-and-gptq-in-2026/) | yes | `skills/llm-inference-optimization/references/aie-039-llm-quantization-explained-int4-int8-fp8-awq-and-gptq.md` | reference digest in `llm-inference-optimization` |
+| 3 | [LLM Quantization: BF16 vs FP8 vs INT4](https://aimultiple.com/llm-quantization) | yes | `skills/llm-inference-optimization/references/aie-040-llm-quantization-bf16-vs-fp8-vs-int4.md` | reference digest in `llm-inference-optimization` |
+
+## Speculative decoding
+
+| # | Item | Fetched | Digest | Kit outcome |
+|---|------|---------|--------|-------------|
+| 1 | [Faster, cheaper, just as smart: improving the economics of LLM inference with speculative decoding](https://www.redhat.com/en/blog/solving-economics-llm-inference-speculative-decoding) | yes | `skills/llm-inference-optimization/references/aie-041-improving-the-economics-of-llm-inference-with-speculative.md` | reference digest in `llm-inference-optimization` |
+| 2 | [Speculative Decoding, Quantization, and Distillation Tradeoffs](https://redpumpkin.ai/blog/speculative-decoding-quantization-and-distillation-tradeoffs) | yes | `skills/llm-inference-optimization/references/aie-042-speculative-decoding-quantization-and-distillation-tradeof.md` | reference digest in `llm-inference-optimization` |
+| 3 | [Speculative Decoding and Quantization — LLM Inference](https://theorempath.com/topics/speculative-decoding-and-quantization) | yes | `skills/llm-inference-optimization/references/aie-043-speculative-decoding-and-quantization-llm-inference.md` | reference digest in `llm-inference-optimization` |
+
+## Prefill vs decode
+
+| # | Item | Fetched | Digest | Kit outcome |
+|---|------|---------|--------|-------------|
+| 1 | [Prefill and Decode: a technical guide to the two phases of inference](https://www.weka.io/learn/ai-ml/prefill-and-decode/) | yes | `skills/llm-inference-optimization/references/aie-044-prefill-and-decode-a-technical-guide-to-the-two-phases-of.md` | reference digest in `llm-inference-optimization` |
+| 2 | [Prefill vs Decode: LLM inference phases explained](https://redis.io/blog/prefill-vs-decode/) | yes | `skills/llm-inference-optimization/references/aie-045-prefill-vs-decode-llm-inference-phases-explained.md` | reference digest in `llm-inference-optimization` |
+| 3 | [Prefill vs Decode: LLM Inference Optimization (Outcome School)](https://outcomeschool.com/blog/prefill-vs-decode-llm-inference-optimization) | yes | `skills/llm-inference-optimization/references/aie-046-prefill-vs-decode-llm-inference-optimization.md` | reference digest in `llm-inference-optimization` |
+| 4 | [LLM Inference Optimization — Prefill vs Decode (Towards AI)](https://pub.towardsai.net/llm-inference-optimization-prefill-vs-decode-6e003d48b2ca) | yes | `skills/llm-inference-optimization/references/aie-047-llm-inference-optimization-prefill-vs-decode.md` | reference digest in `llm-inference-optimization` |
+| 5 | [The LLM Inference Optimization Stack: quantization to speculative decoding, part 1](https://www.digitalocean.com/community/tutorials/llm-inference-optimization-stack-part-1) | yes | `skills/llm-inference-optimization/references/aie-048-the-llm-inference-optimization-stack-quantization-to-specu.md` | reference digest in `llm-inference-optimization` |
+
+## KV cache management
+
+| # | Item | Fetched | Digest | Kit outcome |
+|---|------|---------|--------|-------------|
+| 1 | [Automatic Prefix Caching — design (vLLM docs)](https://docs.vllm.ai/en/stable/design/prefix_caching/) | yes | `skills/llm-inference-optimization/references/aie-049-automatic-prefix-caching-design-in-vllm.md` | reference digest in `llm-inference-optimization` |
+| 2 | [PEEK: Predictive Queue-Informed KV Cache Management for LLM Serving](https://arxiv.org/html/2607.02525v1) | yes | `skills/llm-inference-optimization/references/aie-050-peek-predictive-queue-informed-kv-cache-management-for-llm.md` | reference digest in `llm-inference-optimization` |
+| 3 | [EpiCache: Episodic KV Cache Management for Long-Term Conversation on Resource-Constrained Environments](https://icml.cc/virtual/2026/poster/65405) | yes | `skills/llm-inference-optimization/references/aie-051-epicache-episodic-kv-cache-management-for-long-term-conver.md` | reference digest in `llm-inference-optimization` |
+| 4 | [Automatic Prefix Caching — implementation details (vLLM v0.6.2)](https://docs.vllm.ai/en/v0.6.2/automatic_prefix_caching/details.html) | yes | `skills/llm-inference-optimization/references/aie-052-automatic-prefix-caching-implementation-details-vllm.md` | reference digest in `llm-inference-optimization` |
+| 5 | [Understanding vLLM KV cache (forum thread)](https://discuss.vllm.ai/t/understanding-vllm-kv-cache/2061) | yes | `skills/llm-inference-optimization/references/aie-053-understanding-vllm-kv-cache.md` | reference digest in `llm-inference-optimization` |
+
+## Prompt and semantic caching
+
+| # | Item | Fetched | Digest | Kit outcome |
+|---|------|---------|--------|-------------|
+| 1 | [Prompt caching vs semantic caching: how to make AI agents faster](https://redis.io/blog/prompt-caching-vs-semantic-caching/) | yes | `skills/llm-caching-strategies/references/aie-054-prompt-caching-vs-semantic-caching-how-to-make-ai-agents-f.md` | reference digest in `llm-caching-strategies` |
+| 2 | [The Cache Has Layers: prompt caching, semantic caching, and when each one betrays you](https://acethecloud.com/blog/prompt-caching-semantic-caching-tradeoffs/) | yes | `skills/llm-caching-strategies/references/aie-055-the-cache-has-layers-prompt-caching-semantic-caching-and-w.md` | reference digest in `llm-caching-strategies` |
+| 3 | [Prompt Caching in 2026: cut LLM costs, keep quality](https://www.digitalapplied.com/blog/prompt-caching-2026-cut-llm-costs-engineering-guide) | yes | `skills/llm-caching-strategies/references/aie-056-prompt-caching-cut-llm-costs-keep-quality.md` | reference digest in `llm-caching-strategies` |
+| 4 | [Semantic Caching: boost LLM speed & reduce costs](https://www.truefoundry.com/blog/semantic-caching) | yes | `skills/llm-caching-strategies/references/aie-057-semantic-caching-boost-llm-speed-and-reduce-costs.md` | reference digest in `llm-caching-strategies` |
+| 5 | [Optimize LLM response costs and latency with effective caching](https://aws.amazon.com/blogs/database/optimize-llm-response-costs-and-latency-with-effective-caching/) | yes | `skills/llm-caching-strategies/references/aie-058-optimize-llm-response-costs-and-latency-with-effective-cac.md` | reference digest in `llm-caching-strategies` |
+
+## Distillation and fine-tuning
+
+| # | Item | Fetched | Digest | Kit outcome |
+|---|------|---------|--------|-------------|
+| 1 | [Distillation with Programmatic Data Curation: smarter LLMs, 5-30x cheaper inference](https://www.tensorzero.com/blog/distillation-programmatic-data-curation-smarter-llms-5-30x-cheaper-inference/) | yes | `skills/rag-and-model-tuning/references/aie-059-distillation-with-programmatic-data-curation-cheaper-infer.md` | reference digest in `rag-and-model-tuning` |
+| 2 | [Efficient Knowledge Injection in LLMs via Self-Distillation](https://arxiv.org/html/2412.14964v2) | yes | `skills/rag-and-model-tuning/references/aie-060-efficient-knowledge-injection-in-llms-via-self-distillatio.md` | reference digest in `rag-and-model-tuning` |
+| 3 | [Distilling Many-Shot In-Context Learning into a Cheat Sheet (ACL Findings EMNLP 2025)](https://aclanthology.org/2025.findings-emnlp.930.pdf) | yes | `skills/rag-and-model-tuning/references/aie-061-distilling-many-shot-in-context-learning-into-a-cheat-shee.md` | reference digest in `rag-and-model-tuning` |
+| 4 | [LLM Fine-tuning: customize large language models](https://billtcheng2013.medium.com/llm-fine-tuning-7986bb8e939f) | yes | `skills/rag-and-model-tuning/references/aie-062-llm-fine-tuning-customize-large-language-models.md` | reference digest in `rag-and-model-tuning` |
+
+## Retrieval-augmented generation
+
+| # | Item | Fetched | Digest | Kit outcome |
+|---|------|---------|--------|-------------|
+| 1 | [The Architect's Guide to Production RAG: navigating challenges and building scalable AI](https://www.ragie.ai/blog/the-architects-guide-to-production-rag-navigating-challenges-and-building-scalable-ai) | yes | `skills/rag-and-model-tuning/references/aie-063-the-architects-guide-to-production-rag.md` | reference digest in `rag-and-model-tuning` |
+| 2 | [RAG Best Practices: chunking, hybrid search, reranking](https://codewheel.ai/blog/rag-architecture-guide/) | yes | `skills/rag-and-model-tuning/references/aie-064-rag-best-practices-chunking-hybrid-search-reranking.md` | reference digest in `rag-and-model-tuning` |
+| 3 | [Fine Tuning vs. Retrieval Augmented Generation for Less Popular Knowledge (v3)](https://arxiv.org/html/2403.01432v3) | yes | `skills/rag-and-model-tuning/references/aie-065-fine-tuning-vs-retrieval-augmented-generation-for-less-pop.md` | reference digest in `rag-and-model-tuning` |
+| 4 | [Fine Tuning vs. Retrieval Augmented Generation for Less Popular Knowledge (v1)](https://arxiv.org/html/2403.01432v1) | yes | — | deduplicated — duplicate of `aie-065` (same paper, v3) |
+| 5 | [Building Production-Grade RAG Architecture: the engineering playbook](https://www.cloudaeon.com/insights/building-production-grade-rag-architecture:-the-engineering-playbook) | yes | `skills/rag-and-model-tuning/references/aie-067-building-production-grade-rag-architecture-the-engineering.md` | reference digest in `rag-and-model-tuning` |
+| 6 | [Best RAG Tools, Frameworks, and Libraries](https://aimultiple.com/retrieval-augmented-generation) | yes | `skills/rag-and-model-tuning/references/aie-068-best-rag-tools-frameworks-and-libraries.md` | reference digest in `rag-and-model-tuning` |
+| 7 | [RAG Evaluation Metrics: improve RAG](https://customgpt.ai/rag-evaluation-metrics/) | yes | `skills/rag-and-model-tuning/references/aie-069-rag-evaluation-metrics.md` | reference digest in `rag-and-model-tuning` |
+| 8 | [RAG Evaluation Metrics: answer relevancy, faithfulness, and real-world accuracy](https://deepchecks.com/rag-evaluation-metrics-answer-relevancy-faithfulness-accuracy/) | no | — | not fetched (http=403) — honest row, no digest |
+| 9 | [RAG Framework Explained for Enterprise AI and LLMs](https://tblocks.com/guides/rag-framework/) | no | — | not fetched (http=403) — honest row, no digest |
+| 10 | [Building a Security and Reliability Evaluation Suite for Retrieval-Augmented Generation (RAG) Systems](https://www.preprints.org/manuscript/202510.0418/v1) | no | — | not fetched (http=403) — honest row, no digest |
+
+## Not articles
+
+| # | Item | Fetched | Digest | Kit outcome |
+|---|------|---------|--------|-------------|
+| 1 | [AI Insights Archives (category index page)](https://sudoall.com/category/ai-insights/) | yes | — | not absorbed — index page, not an article |
+| 2 | [David Saliba, Author at SudoAll (author index page)](https://sudoall.com/author/admin/) | yes | — | not absorbed — index page, not an article |
+
+---
+
+*72 items noted; 63 shipped digests — 24 into six existing skills, 39 into four new stack-collection skills.*