claude-code-kit 0.50.0__tar.gz → 0.51.0__tar.gz

{claude_code_kit-0.50.0 → claude_code_kit-0.51.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.50.0",
+      "version": "0.51.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

{claude_code_kit-0.50.0 → claude_code_kit-0.51.0}/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.50.0",
+  "version": "0.51.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.50.0 → claude_code_kit-0.51.0}/CHANGELOG.md

@@ -4,6 +4,72 @@ 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.51.0] — 2026-06-28
+
+**Adopt the verified wins from an exhaustive review of the entire `google` GitHub org** (all **2,881**
+repos). Every repo was surveyed (60 agents over every page — no repo skipped), the top ~300 candidates
+deep-read for license + transferable practice, and the shortlist **adversarially verified** against the
+live source. The verify pass *dropped a third* of the shortlist: `deps.dev` (a REST/gRPC API, **not** an
+MCP server), `licensecheck` (license *classification*, not the claimed compatibility gate), the
+Go/Rust/C++-locked tools `capslock` · `rust-crate-audits` · `fuzztest` · `libprotobuf-mutator` (not
+re-derivable stack-agnostic), `sqlcommenter` (archived → donated to OpenTelemetry), and `ax` (too early —
+"major breaking changes prior to stable"). Everything is re-derived **in prose, never vendored**; all
+sources Apache-2.0 / BSD-3-Clause / MIT except one CC-BY-4.0 book (concept-only). **21 adoptions, all
+extensions to existing files — 0 new agents/skills/rules** (skill counts unchanged at 104/56/48); only the
+**MCP fragment count rises 13 → 17**.
+
+Rules:
+
+- **`human-in-the-loop.md`** — a new **multi-party authorization** section: the two-person rule for the
+  highest-stakes actions, context-bound (multi-factor) approval, and **breakglass-with-auditing** (loud
+  emergency override + mandatory after-the-fact review), extending the simple approval gate beyond a
+  single approver (concept-only from the CC-BY-4.0 *Building Secure & Reliable Systems*,
+  `google/building-secure-and-reliable-systems`).
+- **`testing.md`** — four techniques beyond example-based tests: **parameterized/table-driven** tests
+  (`google/patrick`); **semantic-equality & structured-diff** assertions, float tolerance over brittle
+  deep-equality (`google/go-cmp`); a **Fuzzing** section — coverage-guided + structure-aware + **continuous
+  fuzzing as a CI gate** (`google/atheris` · `google/honggfuzz` · `google/clusterfuzzlite`); and
+  **parallel execution + repeated-run flakiness detection** (`google/gtest-parallel`).
+- **`linting-and-formatting.md`** — a **compile-time logic-bug analysis** layer (find bugs the type
+  checker accepts — `google/error-prone`), **license-header enforcement** as a check-mode CI gate
+  (`google/addlicense`), and **deterministic block sorting** via marker comments to cut merge conflicts
+  (`google/keep-sorted`).
+- **`devops-observability.md`** — **multi-window burn-rate alerting** (alert on error-budget burn across
+  paired short/long windows, not raw error rate — `google/prometheus-slo-burn-example`) and **high-volume
+  logging** patterns (call-site rate-limiting + lazy argument evaluation — `google/flogger`).
+- **`reasoning-techniques.md`** — **prompt-as-code**: treat a reusable prompt as a versioned, schema-validated,
+  testable artifact (`google/dotprompt`).
+- **`tool-design.md`** — the §8 atomic-state note gains the **atomicity-vs-durability** nuance
+  (fsync-before-rename, same-filesystem, temp cleanup — `google/renameio`).
+
+Skills:
+
+- **`security-and-hardening`** — **reproducible-build verification** (independent rebuild → normalize
+  benign differences → attest equivalence — `google/oss-rebuild`); **source-level missing-patch detection**
+  for vendored/forked code via OSV-derived signatures (`google/vanir`); **secure-by-construction injection
+  defense** (compile-time-constant query text + typed trusted/untrusted wrappers — `google/safe-active-record`
+  · `google/mug`); **archive-extraction safety** (zip-slip / symlink — `google/safearchive`); and **ReDoS
+  defense** for untrusted regex input (`google/re2`).
+- **`context-engineering`** — a **Long-Document Extraction** section: overlapping chunks → parallel
+  schema-constrained passes → source-interval grounding → multi-pass recall (`google/langextract`).
+- **`performance-optimization`** — a **statistical browser benchmarking** discipline: interleaved repeated
+  sampling, 95 % confidence intervals, auto-sample-until-significance (`google/tachometer`).
+- **`api-integration`** — a **record-replay** pattern for deterministic external-API tests (record real
+  responses with secrets redacted → replay offline → re-record on drift — `google/test-server`).
+
+Catalog:
+
+- **`catalog/mcp.yaml`** — **4 first-party Google Security Operations MCP fragments** (one upstream repo,
+  `google/mcp-security`, Apache-2.0): **secops** (Chronicle SIEM), **gti** (Google Threat Intelligence /
+  VirusTotal), **scc** (Security Command Center / cloud posture), **secops_soar** (SecOps SOAR) — the
+  SOC/operational-security capability domain the catalog had no entry for. Run via pinned `uvx`; each needs
+  a paid Google SecOps backend + ADC and is **referenced, never bundled** (like `sentry`/`repowise`).
+
+What we **did not** add (already covered, or fails the bar): property-based testing (already in
+`test-driven-development` §property-based, 0.38) — the new Fuzzing section builds on it; pre-add dependency
+evaluation (already `library-review` + `dependency-verification`); SBOM/CVE supply-chain (already
+`security-and-hardening`, 0.39/0.50); the dropped shortlist items above.
+
 ## [0.50.0] — 2026-06-28
 
 **Adopt the verified wins from an exhaustive review of the entire `microsoft` GitHub org** (all **8,147**

{claude_code_kit-0.50.0 → claude_code_kit-0.51.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.50.0
+Version: 0.51.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
@@ -89,7 +89,7 @@ Quick start) for the full breakdown of any row.
 | 🎚️ **Profiles, scopes & org** | **3** rigor profiles · **3** scopes · **5** autonomy levels · **7** org packs + **10** policy rules |
 | 🧠 **Memory & learning** | Working memory across context compaction + a cost-aware learnings loop (`capture_mode`) so the same mistake isn't repeated |
 | 🛠️ **Hooks & guards** | **17** event hooks — blocking safety guards vs. advisory warnings — that no-op gracefully without `jq` |
-| 📦 **Distribution & lifecycle** | Plugin **and** pip from one source, **13** ready MCP fragments, and edit-preserving `upgrade` |
+| 📦 **Distribution & lifecycle** | Plugin **and** pip from one source, **17** ready MCP fragments, and edit-preserving `upgrade` |
 | ♻️ **Reuse-first by design** | Adopt-only-the-new reviews, opt-in LLM/AI security (OWASP LLM Top 10), a worked example + self-test matrix |
 
 ---
@@ -196,7 +196,7 @@ config — nothing else:
 3. **Backend language** (default: Python) → **backend framework** (default: FastAPI)
 4. **Database** (PostgreSQL · MongoDB)
 5. **SDLC profile** (`lean` · `standard` · `enterprise`)
-6. **Optional MCP integrations** (GitHub · Jira/Linear · Azure DevOps · Postgres/Mongo · Playwright · Docs/MS Learn · Azure · Wassette) — a
+6. **Optional MCP integrations** (GitHub · Jira/Linear · Azure DevOps · Postgres/Mongo · Playwright · Docs/MS Learn · Azure · Wassette · Google SecOps) — a
    project-root `.mcp.json` is written **only** if you select any (env placeholders, never secrets)
 
 Non-interactive equivalents: `--defaults`, or `--config init.yaml` (flat or nested YAML). What lands:
@@ -356,7 +356,7 @@ need.
 - **Two channels, one source** — a first-class Claude Code **plugin** *and* a `pip` scaffolder
   (`claude-kit` / `ckit` / `claude-sdlc`) generate identical config.
 - **Catalog-driven extensibility** — adding a stack, framework, database, profile, MCP server, or org
-  pack is a [`catalog/`](catalog/) YAML edit, never a code change; 13 MCP server fragments ship ready.
+  pack is a [`catalog/`](catalog/) YAML edit, never a code change; 17 MCP server fragments ship ready.
 - **MCP servers are third-party** — each fragment runs an external package or hosted endpoint that
   claude-kit references but does not vendor or audit; the `npx` commands are **pinned to an exact
   version** (not `@latest`) for reproducible, supply-chain-aware installs. Review a server's source and
@@ -518,6 +518,7 @@ non-duplicative gaps**, minimally and catalog-wired.
 | **[alibaba](https://github.com/alibaba) org review** (all 542 repos) | Staged leak-resistant evals; agent-operation authorization; tool-set orchestration + atomic state; agent-run span-tree instrumentation; live-attach debugging | `evals` §7, `agent-guardrails` §5, `tool-design` §8, `goal-setting-and-monitoring` §4, and live-attach debugging in `debugging-and-error-recovery` (from atrex-bench · open-agent-auth · app-controller · loongsuite-js · arthas) | `0.47.0` |
 | **[alibaba/open-code-review](https://github.com/alibaba/open-code-review)** | Partition-for-coverage review — deterministic full-file coverage on large changesets, related-file bundling, plan-before-deep-pass | The "Cover Every Changed File" section in `code-review-and-quality` + a Coverage category in `sdlc-code-reviewer` | `0.48.0` |
 | **[microsoft](https://github.com/microsoft) org review** (all 8,147 repos) | OWASP Agentic Top-10 (ASI01–ASI10) agent threats; agent-aware evals (multi-judge panels, multi-turn degradation, tool-vs-response grading); validator-in-the-loop + Medprompt prompting; sandbox policy schema & layered prompt-injection defense; approval-gate implementation; security-lint layer & SBOM; operationalized GenAI red-teaming; priority-based prompt pruning; quantified-lines PR sizing; first-party MCP servers | Extensions across `agent-guardrails` (ASI01–ASI10 + sandbox policy + injection layers), `evals` (§3 panels, §8 multi-turn), `reasoning-techniques`, `human-in-the-loop`, `linting-and-formatting`, `threat-model`, `security-and-hardening` (SBOM), `context-engineering`, `code-review-and-quality` + 4 MCP fragments (Azure · Azure DevOps · MS Learn · Wassette) — **0 new agents/skills/rules** (from agent-governance-toolkit · mxc · llmail-inject-challenge · lost_in_conversation · llm-as-judge · EvalsforAgentsInterop · promptbase · dsl-copilot · agents-humanoversight · PyRIT · eslint-plugin-sdl · sbom-tool · vscode-prompt-tsx · PullRequestQuantifier) | `0.50.0` |
+| **[google](https://github.com/google) org review** (all 2,881 repos) | Reproducible-build verification & source-level missing-patch detection; secure-by-construction injection defense; archive-extraction & ReDoS hardening; multi-party authorization / breakglass; coverage-guided & continuous fuzzing; parameterized + semantic-equality + parallel/flaky testing; compile-time logic-bug & license-header lint layers + deterministic block sorting; multi-window burn-rate alerting & log rate-limiting; long-document extraction; prompt-as-code; statistical browser benchmarking; durable atomic writes; record-replay API testing; first-party SecOps MCP servers | Prose extensions across `security-and-hardening` (reproducible-build · missing-patch · secure-by-construction · archive · ReDoS), `human-in-the-loop` (MPA/breakglass), `testing` (fuzzing · parameterized · semantic-equality · parallel/flaky), `linting-and-formatting` (logic-bug + license-header layers · block sorting), `devops-observability` (burn-rate · log rate-limit), `context-engineering` (long-doc extraction), `reasoning-techniques` (prompt-as-code), `performance-optimization` (statistical benchmarking), `tool-design` (durable atomic writes), `api-integration` (record-replay) + **4 first-party SecOps MCP fragments** (Chronicle SIEM · GTI · SCC · SOAR) — **0 new agents/skills/rules** (from oss-rebuild · vanir · safe-active-record/mug · safearchive · re2 · building-secure-and-reliable-systems · patrick · go-cmp · atheris/honggfuzz/clusterfuzzlite · gtest-parallel · error-prone · addlicense · keep-sorted · prometheus-slo-burn · flogger · langextract · dotprompt · tachometer · renameio · test-server · mcp-security) | `0.51.0` |
 
 > Each adoption is detailed in the [CHANGELOG](CHANGELOG.md) — including, for every review, what we
 > deliberately **did not** add because the kit already covered it.
@@ -527,15 +528,6 @@ non-duplicative gaps**, minimally and catalog-wired.
 
 <br>
 
-**🧭 alibaba org review → 5 agentic patterns (0.47.0).** We reviewed **all 542 repos** in the Alibaba
-org (survey every repo → deep-dive every candidate → adversarially verify). The overwhelming majority —
-Java middleware, ML/inference, mobile, frontend frameworks — carried nothing transferable to a config
-scaffolder, and the verify pass *dropped* a sixth candidate (`p3c`) as unsubstantiated and already
-covered. Five survived: staged leak-resistant evals (`evals` §7), agent-operation authorization
-(`agent-guardrails` §5), tool-set orchestration + atomic state (`tool-design` §8), agent-run span-tree
-instrumentation (`goal-setting-and-monitoring` §4), and live-attach debugging
-(`debugging-and-error-recovery`).
-
 **🔍 alibaba/open-code-review → coverage-partition review (0.48.0).** A detailed read showed most of its
 methodology (multi-axis review, line-level grounding + re-verify, severity, multi-model) was *already*
 in `code-review-and-quality`. The one genuine gap: **complete file coverage on large changesets** —
@@ -559,6 +551,26 @@ panels in §3, multi-turn degradation in §8) in `evals`; validator-in-the-loop
 sizing in `code-review-and-quality`; and **4 first-party MCP fragments** (Azure · Azure DevOps · MS
 Learn · Wassette).
 
+**🔴 google org review → 21 hardening & testing patterns (0.51.0).** We reviewed **all 2,881 repos** in
+the Google org (60 survey agents over every page → deep-dive the top ~300 candidates → adversarially
+verify the shortlist). The vast majority — Android/Kotlin, C++ libraries, ML frameworks, language
+runtimes, GCP product code — carried nothing transferable, and the verify pass *dropped* a third of the
+shortlist: `deps.dev` (a REST/gRPC API, **not** an MCP server, despite the claim), `licensecheck`
+(license *classification*, not the claimed compatibility gate), the Go/Rust/C++-locked tools
+(`capslock`, `rust-crate-audits`, `fuzztest`, `libprotobuf-mutator` — can't be re-derived stack-agnostic),
+`sqlcommenter` (archived → donated to OpenTelemetry), and `ax` (too early — "major breaking changes
+prior to stable"). The survivors are **all prose extensions to existing files, zero new
+agents/skills/rules**: reproducible-build verification, source-level missing-patch detection,
+secure-by-construction injection defense, archive-extraction & ReDoS hardening in `security-and-hardening`;
+multi-party authorization / breakglass in `human-in-the-loop`; coverage-guided & continuous fuzzing,
+parameterized, semantic-equality, and parallel/flaky testing in `testing`; compile-time logic-bug &
+license-header lint layers plus deterministic block sorting in `linting-and-formatting`; multi-window
+burn-rate alerting & log rate-limiting in `devops-observability`; long-document extraction in
+`context-engineering`; prompt-as-code in `reasoning-techniques`; statistical browser benchmarking in
+`performance-optimization`; durable atomic writes in `tool-design`; record-replay API testing in
+`api-integration`; and **4 first-party Google Security Operations MCP fragments** (Chronicle SIEM · GTI ·
+SCC · SOAR).
+
 </details>
 
 > **Comparing claude-kit to native subagents / Agent Teams, agent collections, spec-kit, or

{claude_code_kit-0.50.0 → claude_code_kit-0.51.0}/README.md

@@ -59,7 +59,7 @@ Quick start) for the full breakdown of any row.
 | 🎚️ **Profiles, scopes & org** | **3** rigor profiles · **3** scopes · **5** autonomy levels · **7** org packs + **10** policy rules |
 | 🧠 **Memory & learning** | Working memory across context compaction + a cost-aware learnings loop (`capture_mode`) so the same mistake isn't repeated |
 | 🛠️ **Hooks & guards** | **17** event hooks — blocking safety guards vs. advisory warnings — that no-op gracefully without `jq` |
-| 📦 **Distribution & lifecycle** | Plugin **and** pip from one source, **13** ready MCP fragments, and edit-preserving `upgrade` |
+| 📦 **Distribution & lifecycle** | Plugin **and** pip from one source, **17** ready MCP fragments, and edit-preserving `upgrade` |
 | ♻️ **Reuse-first by design** | Adopt-only-the-new reviews, opt-in LLM/AI security (OWASP LLM Top 10), a worked example + self-test matrix |
 
 ---
@@ -166,7 +166,7 @@ config — nothing else:
 3. **Backend language** (default: Python) → **backend framework** (default: FastAPI)
 4. **Database** (PostgreSQL · MongoDB)
 5. **SDLC profile** (`lean` · `standard` · `enterprise`)
-6. **Optional MCP integrations** (GitHub · Jira/Linear · Azure DevOps · Postgres/Mongo · Playwright · Docs/MS Learn · Azure · Wassette) — a
+6. **Optional MCP integrations** (GitHub · Jira/Linear · Azure DevOps · Postgres/Mongo · Playwright · Docs/MS Learn · Azure · Wassette · Google SecOps) — a
    project-root `.mcp.json` is written **only** if you select any (env placeholders, never secrets)
 
 Non-interactive equivalents: `--defaults`, or `--config init.yaml` (flat or nested YAML). What lands:
@@ -326,7 +326,7 @@ need.
 - **Two channels, one source** — a first-class Claude Code **plugin** *and* a `pip` scaffolder
   (`claude-kit` / `ckit` / `claude-sdlc`) generate identical config.
 - **Catalog-driven extensibility** — adding a stack, framework, database, profile, MCP server, or org
-  pack is a [`catalog/`](catalog/) YAML edit, never a code change; 13 MCP server fragments ship ready.
+  pack is a [`catalog/`](catalog/) YAML edit, never a code change; 17 MCP server fragments ship ready.
 - **MCP servers are third-party** — each fragment runs an external package or hosted endpoint that
   claude-kit references but does not vendor or audit; the `npx` commands are **pinned to an exact
   version** (not `@latest`) for reproducible, supply-chain-aware installs. Review a server's source and
@@ -488,6 +488,7 @@ non-duplicative gaps**, minimally and catalog-wired.
 | **[alibaba](https://github.com/alibaba) org review** (all 542 repos) | Staged leak-resistant evals; agent-operation authorization; tool-set orchestration + atomic state; agent-run span-tree instrumentation; live-attach debugging | `evals` §7, `agent-guardrails` §5, `tool-design` §8, `goal-setting-and-monitoring` §4, and live-attach debugging in `debugging-and-error-recovery` (from atrex-bench · open-agent-auth · app-controller · loongsuite-js · arthas) | `0.47.0` |
 | **[alibaba/open-code-review](https://github.com/alibaba/open-code-review)** | Partition-for-coverage review — deterministic full-file coverage on large changesets, related-file bundling, plan-before-deep-pass | The "Cover Every Changed File" section in `code-review-and-quality` + a Coverage category in `sdlc-code-reviewer` | `0.48.0` |
 | **[microsoft](https://github.com/microsoft) org review** (all 8,147 repos) | OWASP Agentic Top-10 (ASI01–ASI10) agent threats; agent-aware evals (multi-judge panels, multi-turn degradation, tool-vs-response grading); validator-in-the-loop + Medprompt prompting; sandbox policy schema & layered prompt-injection defense; approval-gate implementation; security-lint layer & SBOM; operationalized GenAI red-teaming; priority-based prompt pruning; quantified-lines PR sizing; first-party MCP servers | Extensions across `agent-guardrails` (ASI01–ASI10 + sandbox policy + injection layers), `evals` (§3 panels, §8 multi-turn), `reasoning-techniques`, `human-in-the-loop`, `linting-and-formatting`, `threat-model`, `security-and-hardening` (SBOM), `context-engineering`, `code-review-and-quality` + 4 MCP fragments (Azure · Azure DevOps · MS Learn · Wassette) — **0 new agents/skills/rules** (from agent-governance-toolkit · mxc · llmail-inject-challenge · lost_in_conversation · llm-as-judge · EvalsforAgentsInterop · promptbase · dsl-copilot · agents-humanoversight · PyRIT · eslint-plugin-sdl · sbom-tool · vscode-prompt-tsx · PullRequestQuantifier) | `0.50.0` |
+| **[google](https://github.com/google) org review** (all 2,881 repos) | Reproducible-build verification & source-level missing-patch detection; secure-by-construction injection defense; archive-extraction & ReDoS hardening; multi-party authorization / breakglass; coverage-guided & continuous fuzzing; parameterized + semantic-equality + parallel/flaky testing; compile-time logic-bug & license-header lint layers + deterministic block sorting; multi-window burn-rate alerting & log rate-limiting; long-document extraction; prompt-as-code; statistical browser benchmarking; durable atomic writes; record-replay API testing; first-party SecOps MCP servers | Prose extensions across `security-and-hardening` (reproducible-build · missing-patch · secure-by-construction · archive · ReDoS), `human-in-the-loop` (MPA/breakglass), `testing` (fuzzing · parameterized · semantic-equality · parallel/flaky), `linting-and-formatting` (logic-bug + license-header layers · block sorting), `devops-observability` (burn-rate · log rate-limit), `context-engineering` (long-doc extraction), `reasoning-techniques` (prompt-as-code), `performance-optimization` (statistical benchmarking), `tool-design` (durable atomic writes), `api-integration` (record-replay) + **4 first-party SecOps MCP fragments** (Chronicle SIEM · GTI · SCC · SOAR) — **0 new agents/skills/rules** (from oss-rebuild · vanir · safe-active-record/mug · safearchive · re2 · building-secure-and-reliable-systems · patrick · go-cmp · atheris/honggfuzz/clusterfuzzlite · gtest-parallel · error-prone · addlicense · keep-sorted · prometheus-slo-burn · flogger · langextract · dotprompt · tachometer · renameio · test-server · mcp-security) | `0.51.0` |
 
 > Each adoption is detailed in the [CHANGELOG](CHANGELOG.md) — including, for every review, what we
 > deliberately **did not** add because the kit already covered it.
@@ -497,15 +498,6 @@ non-duplicative gaps**, minimally and catalog-wired.
 
 <br>
 
-**🧭 alibaba org review → 5 agentic patterns (0.47.0).** We reviewed **all 542 repos** in the Alibaba
-org (survey every repo → deep-dive every candidate → adversarially verify). The overwhelming majority —
-Java middleware, ML/inference, mobile, frontend frameworks — carried nothing transferable to a config
-scaffolder, and the verify pass *dropped* a sixth candidate (`p3c`) as unsubstantiated and already
-covered. Five survived: staged leak-resistant evals (`evals` §7), agent-operation authorization
-(`agent-guardrails` §5), tool-set orchestration + atomic state (`tool-design` §8), agent-run span-tree
-instrumentation (`goal-setting-and-monitoring` §4), and live-attach debugging
-(`debugging-and-error-recovery`).
-
 **🔍 alibaba/open-code-review → coverage-partition review (0.48.0).** A detailed read showed most of its
 methodology (multi-axis review, line-level grounding + re-verify, severity, multi-model) was *already*
 in `code-review-and-quality`. The one genuine gap: **complete file coverage on large changesets** —
@@ -529,6 +521,26 @@ panels in §3, multi-turn degradation in §8) in `evals`; validator-in-the-loop
 sizing in `code-review-and-quality`; and **4 first-party MCP fragments** (Azure · Azure DevOps · MS
 Learn · Wassette).
 
+**🔴 google org review → 21 hardening & testing patterns (0.51.0).** We reviewed **all 2,881 repos** in
+the Google org (60 survey agents over every page → deep-dive the top ~300 candidates → adversarially
+verify the shortlist). The vast majority — Android/Kotlin, C++ libraries, ML frameworks, language
+runtimes, GCP product code — carried nothing transferable, and the verify pass *dropped* a third of the
+shortlist: `deps.dev` (a REST/gRPC API, **not** an MCP server, despite the claim), `licensecheck`
+(license *classification*, not the claimed compatibility gate), the Go/Rust/C++-locked tools
+(`capslock`, `rust-crate-audits`, `fuzztest`, `libprotobuf-mutator` — can't be re-derived stack-agnostic),
+`sqlcommenter` (archived → donated to OpenTelemetry), and `ax` (too early — "major breaking changes
+prior to stable"). The survivors are **all prose extensions to existing files, zero new
+agents/skills/rules**: reproducible-build verification, source-level missing-patch detection,
+secure-by-construction injection defense, archive-extraction & ReDoS hardening in `security-and-hardening`;
+multi-party authorization / breakglass in `human-in-the-loop`; coverage-guided & continuous fuzzing,
+parameterized, semantic-equality, and parallel/flaky testing in `testing`; compile-time logic-bug &
+license-header lint layers plus deterministic block sorting in `linting-and-formatting`; multi-window
+burn-rate alerting & log rate-limiting in `devops-observability`; long-document extraction in
+`context-engineering`; prompt-as-code in `reasoning-techniques`; statistical browser benchmarking in
+`performance-optimization`; durable atomic writes in `tool-design`; record-replay API testing in
+`api-integration`; and **4 first-party Google Security Operations MCP fragments** (Chronicle SIEM · GTI ·
+SCC · SOAR).
+
 </details>
 
 > **Comparing claude-kit to native subagents / Agent Teams, agent collections, spec-kit, or

{claude_code_kit-0.50.0 → claude_code_kit-0.51.0}/catalog/mcp.yaml

@@ -138,3 +138,49 @@ servers:
       type: stdio
       command: repowise
       args: ["mcp", "${REPOWISE_PROJECT_ROOT}", "--transport", "stdio"]
+  # Google Security Operations cluster (github.com/google/mcp-security, Apache-2.0) — four first-party
+  # Google MCP servers covering the SOC/operational-security domain the catalog otherwise has no entry
+  # for (Sentry above is error-monitoring, not threat-intel/SIEM/SOAR/CSPM):
+  #   • secops      — Chronicle SIEM: search/UDM events, detections, IoC matches, case context
+  #   • gti         — Google Threat Intelligence (VirusTotal): file/URL/domain/IP reputation & relationships
+  #   • scc         — Security Command Center: cloud-security posture, findings, asset risk
+  #   • secops_soar — SecOps SOAR (Siemplify): cases, playbooks, response actions
+  # These are Python servers run with `uvx` (install `uv` first: https://docs.astral.sh/uv/), pinned to
+  # exact PyPI versions (snapshot 2026-06-28; do not float). NOT bundled — claude-kit only references
+  # them. Each needs a PAID Google SecOps/Chronicle (or VirusTotal) backend and its own credentials —
+  # auth is via Application Default Credentials (`gcloud auth application-default login`, or a
+  # GOOGLE_APPLICATION_CREDENTIALS service-account file) plus the per-server env vars below; no
+  # credentials are generated here. Enable only the server(s) whose backend you actually have.
+  secops:
+    label: "Google SecOps / Chronicle SIEM (paid Chronicle backend + ADC required)"
+    config:
+      type: stdio
+      command: uvx
+      args: ["--from", "google-secops-mcp==0.7.0", "secops_mcp"]
+      env:
+        CHRONICLE_PROJECT_ID: "${CHRONICLE_PROJECT_ID}"
+        CHRONICLE_CUSTOMER_ID: "${CHRONICLE_CUSTOMER_ID}"
+        CHRONICLE_REGION: "${CHRONICLE_REGION}"
+  gti:
+    label: "Google Threat Intelligence / VirusTotal (needs VT_APIKEY)"
+    config:
+      type: stdio
+      command: uvx
+      args: ["--from", "gti-mcp==0.1.2", "gti_mcp"]
+      env:
+        VT_APIKEY: "${VT_APIKEY}"
+  scc:
+    label: "Security Command Center — cloud security posture (ADC required)"
+    config:
+      type: stdio
+      command: uvx
+      args: ["--from", "scc-mcp==0.1.0", "scc_mcp"]
+  secops_soar:
+    label: "Google SecOps SOAR / Siemplify (paid SOAR backend; needs SOAR_URL + SOAR_APP_KEY)"
+    config:
+      type: stdio
+      command: uvx
+      args: ["--from", "secops-soar-mcp==0.1.1", "secops_soar_mcp"]
+      env:
+        SOAR_URL: "${SOAR_URL}"
+        SOAR_APP_KEY: "${SOAR_APP_KEY}"

{claude_code_kit-0.50.0 → claude_code_kit-0.51.0}/pyproject.toml

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

{claude_code_kit-0.50.0 → claude_code_kit-0.51.0}/rules/devops-observability.md

@@ -49,6 +49,46 @@ Ensures the feature is **operable in production**: you can tell when it breaks a
 
 Findings classified by `.claude/rules/quality-gates.md` severity; Critical/High/Medium block.
 
+### Multi-window burn-rate alerting (alert on the error budget, not raw error rate)
+
+A static "error rate > X%" alert forces a bad trade-off: tight enough to catch a real outage means it
+pages on every transient blip; loose enough to be quiet means slow burns go unnoticed until the budget
+is gone. The SRE pattern is to alert on **how fast the SLO's error budget is burning**, across
+**multiple time windows** at once:
+
+- **Burn rate = (observed error ratio) ÷ (1 − SLO target).** A burn rate of 1 exactly exhausts the
+  budget over the SLO window; 14.4 exhausts it in ~2 % of the window.
+- **Fast-burn (page):** a high burn rate confirmed over a **short *and* a medium** window (e.g. 14.4×
+  over 1h **and** 5m) — catches acute outages fast while the second window suppresses single-spike
+  false positives.
+- **Slow-burn (ticket, not page):** a lower burn rate over **longer** windows (e.g. 6× over 6h/30m,
+  3× over 24h/2h, 1× over 3d/6h) — catches a steady leak that would otherwise quietly drain the budget.
+- Require **both** windows of a tier to fire (the long window detects, the short window confirms it's
+  still happening) so an alert clears quickly once the issue stops. Tie each tier's severity/owner to
+  the "Alerts" gate item above.
+
+> Stack-agnostic adaptation of multi-window, multi-burn-rate SLO alerting (per the Google SRE Workbook)
+> from the Apache-2.0
+> [`google/prometheus-slo-burn-example`](https://github.com/google/prometheus-slo-burn-example).
+> Re-derived in prose; not vendored — the windows/multipliers are a starting point to tune per SLO.
+
+### High-volume logging: rate-limit and defer
+
+Logging on a hot path or in an error burst can become its own incident — the log call dominates CPU, or
+a flood of identical lines buries the signal and runs up ingestion cost. Two patterns keep logging cheap
+under load:
+
+- **Rate-limit repetitive log statements at the call site** — emit "at most every N seconds" or "1 in
+  every N" for a given line, rather than once per iteration, so a tight loop or a sustained error
+  doesn't flood. (Aggregate the suppressed count so you still know the true volume.)
+- **Defer the cost of expensive log arguments** until logging is *known to be enabled* at that level —
+  pass a lazily-evaluated value (a thunk/lambda), not an eagerly-built expensive string, so a disabled
+  `debug` log costs nothing. This pairs with the "no secrets/PII" structured-logging gate item above.
+
+> Stack-agnostic adaptation of log rate-limiting (`atMostEvery`) and lazy argument evaluation from the
+> Apache-2.0 [`google/flogger`](https://github.com/google/flogger). Re-derived in prose; not vendored —
+> the patterns apply to any logging framework.
+
 ---
 
 ## Notes

{claude_code_kit-0.50.0 → claude_code_kit-0.51.0}/rules/human-in-the-loop.md

@@ -65,6 +65,38 @@ pause for a human — so the pause is enforced by the system, not left to the ag
 > [`microsoft/agents-humanoversight`](https://github.com/microsoft/agents-humanoversight). Re-derived in
 > prose; not vendored.
 
+## Multi-party authorization for the highest-stakes actions (MPA · breakglass)
+
+For most stops a *single* human approval is right. But the most dangerous actions — deleting production
+data, changing access control, deploying to a regulated system, rotating root credentials — should not
+be unlockable by **one** person (or one person + a coerced/compromised agent). Raise the bar past a
+single gate:
+
+- **Multi-party authorization (MPA): require two.** A high-stakes action needs a *second independent
+  approver* who is not the requester — the "two-person rule." Beyond stopping a single bad actor, it
+  forces the requester to articulate the action clearly enough that a peer will sign it, which catches
+  honest mistakes. Make the second approval a real review (the approver sees *what* will run), not a
+  rubber stamp.
+- **Bind approval to context, not just identity.** Stronger still: tie sensitive operations to a
+  trusted device/role/environment, so an approval also proves *where* and *how* it was given — not only
+  *who* gave it. (The principle behind "multi-factor / multi-channel" authorization: don't let one
+  stolen credential be sufficient.)
+- **Breakglass, with auditing.** Keep a deliberate emergency override for when the normal path is down
+  (the on-call can't reach a second approver during an incident) — but make it *loud*: it requires a
+  written justification, it is heavily logged, and it triggers a **mandatory after-the-fact review**.
+  Breakglass is an exception that must be accounted for, never a quiet bypass.
+- **Least privilege + separation of duties make MPA affordable.** The fewer actions that *need* two
+  approvers, the more meaningful each one is. Reserve MPA for genuinely irreversible / high-blast-radius
+  operations (see reversibility below); don't dilute it across routine changes.
+
+These map onto the gate mechanics above: MPA is "the declarative gate, but the policy requires N≥2
+distinct approvals," and breakglass is "the timeout/absence path, made auditable instead of fail-open."
+
+> Stack-agnostic adaptation of multi-party / multi-factor authorization, breakglass-with-auditing, and
+> separation-of-duties from *Building Secure & Reliable Systems* (Google/O'Reilly, CC-BY-4.0;
+> [`google/building-secure-and-reliable-systems`](https://github.com/google/building-secure-and-reliable-systems)),
+> Ch. 5 ("Design for Least Privilege") & Ch. 21. Concept-only (CC-BY); re-derived in prose, not vendored.
+
 ## Gate the depth of review to reversibility
 
 Not every stop deserves the same ceremony. Before a consequential decision, classify it by how hard it

{claude_code_kit-0.50.0 → claude_code_kit-0.51.0}/rules/linting-and-formatting.md

@@ -109,6 +109,39 @@ of eyes in review.
 > enforced lint errors). Re-derived in prose; not vendored — the patterns generalize beyond any one
 > linter.
 
+### Compile-Time Logic-Bug Analysis (error)
+
+A style linter checks formatting and idiom; a *type checker* checks types. Between them sits a third,
+higher-value layer: **static analyzers that catch real logic bugs the type checker accepts** — code
+that compiles and is type-correct but is almost certainly wrong. Examples (stack-agnostic):
+
+- an equality/`==` check that can never be true because the operands are incompatible types;
+- a format string whose placeholders don't match its arguments;
+- a returned value or `Future`/`Promise` that is silently dropped (forgotten `await`);
+- a collection mutated while iterated; a `@CheckReturnValue`/`#[must_use]` result ignored.
+
+Enable your stack's analyzer for this class and treat its findings as build-breaking, distinct from
+both the type checker and the security-lint layer above: Error Prone (Java), `clippy` (Rust),
+`staticcheck`/`go vet` (Go), type-aware ESLint rules (TypeScript), Infer / clang-analyzer (C/C++),
+Pyright/mypy strict + Ruff's bug-prone (`B`) rules (Python). The point is the *category* — "find bugs,
+not style" — not any one tool.
+
+> Stack-agnostic adaptation of compile-time logic-bug analysis as a distinct enforcement layer (beyond
+> style + type checking) from the Apache-2.0 [`google/error-prone`](https://github.com/google/error-prone).
+> Re-derived in prose; not vendored — every major ecosystem has an equivalent analyzer.
+
+### License-Header Enforcement (error)
+
+Where the project (or its org) requires source files to carry a copyright + SPDX license header, make
+it a **mechanical, enforced check**, not a manual review item: a CI / pre-commit step verifies every
+source file has the expected header and **fails the build** on a missing or malformed one (a `--check`
+mode that exits non-zero), with an auto-fix mode that inserts the header locally. This keeps license
+hygiene from rotting silently as new files are added.
+
+> Stack-agnostic adaptation of license-header enforcement as a check-mode CI/pre-commit gate from the
+> Apache-2.0 [`google/addlicense`](https://github.com/google/addlicense). Re-derived in prose; not
+> vendored.
+
 ## Framework-Specific Hook Rules (if applicable)
 
 For reactive frameworks (React, Vue, Svelte, SolidJS, etc.), enforce hook/reactivity rules:
@@ -204,6 +237,30 @@ cd frontend && <run frontend linter>
 
 **Formatting is not negotiable.** Configure your editor to format on save, or rely on pre-commit hooks. Never commit unformatted code.
 
+### Deterministic Block Sorting
+
+Lists that many contributors append to — dependency arrays, import groups, enum/constant lists, config
+allowlists — are a recurring source of **merge conflicts** (two branches both append to the end) and of
+"is X already here?" scanning cost. Keep such blocks **deterministically sorted** so additions land in a
+predictable place and diffs stay minimal. A language-agnostic, marker-comment formatter does this
+without needing the surrounding file to be machine-sortable:
+
+```
+# keep-sorted start
+  alpha
+  bravo
+  charlie
+# keep-sorted end
+```
+
+The tool re-sorts only between the markers (with options for grouping, case, and numeric ordering) and
+runs in the same pre-commit / CI auto-fix step as the formatter. Apply it to frequently-edited lists;
+don't impose it on sequences whose order is meaningful.
+
+> Stack-agnostic adaptation of marker-comment deterministic block sorting (reduce merge conflicts on
+> append-heavy lists) from the Apache-2.0 [`google/keep-sorted`](https://github.com/google/keep-sorted).
+> Re-derived in prose; not vendored.
+
 ## Ignored Paths
 
 Configure the linter to exclude:

{claude_code_kit-0.50.0 → claude_code_kit-0.51.0}/rules/reasoning-techniques.md

@@ -44,6 +44,32 @@ Two techniques earn their cost on hard, repeated tasks:
 > feedback loop) and [`microsoft/promptbase`](https://github.com/microsoft/promptbase) (Medprompt).
 > Re-derived in prose; not vendored.
 
+### Treat a reusable prompt as a versioned, testable artifact
+
+A prompt you rely on repeatedly — the instruction that drives an agent, a skill, or a recurring
+extraction/classification step — is **code**, and it deserves the same discipline. An ad-hoc string
+buried in a function is impossible to review, diff, or regression-test; the moment a prompt matters,
+lift it into a first-class artifact:
+
+- **Declare the contract, don't bury it.** Keep the model/config (model, temperature, etc.) and an
+  explicit **input and output schema** *with* the prompt text — so callers know what it expects and what
+  it returns, and the output can be **schema-validated** (pairs with validator-in-the-loop above:
+  reject/repair output that doesn't match the schema).
+- **Separate template from data.** Parameterize the prompt with named variables rather than
+  string-concatenating values in; this keeps the reusable logic stable and the per-call data explicit
+  (and avoids accidental injection of untrusted text into the instruction — see `agent-guardrails.md`).
+- **Version it and test it.** Store the prompt as a file under version control so changes are
+  reviewable and diffable, and write **evals** against it (`.claude/rules/evals.md`) so a "small wording
+  tweak" can't silently regress behavior. A prompt without a test is an untested code path.
+
+This is exactly what the kit's own agents and skills already are — Markdown with YAML frontmatter, under
+version control. The discipline generalizes: any prompt important enough to reuse is important enough to
+schema-check, version, and test.
+
+> Stack-agnostic adaptation of the prompt-as-code discipline (frontmatter model/config + schema-driven
+> I/O validation + templating + versioned, testable `.prompt` artifacts) from the Apache-2.0
+> [`google/dotprompt`](https://github.com/google/dotprompt). Re-derived in prose; not vendored.
+
 ## Reasoning hygiene
 
 1. **Make the reasoning inspectable.** A reviewer (or the next agent) should be able to follow *why*,

{claude_code_kit-0.50.0 → claude_code_kit-0.51.0}/rules/testing.md

@@ -419,6 +419,102 @@ For component-based UI frameworks:
 
 See `.claude/rules/responsive-and-accessibility.md` for UI-specific accessibility requirements.
 
+## Parameterized / Table-Driven Tests
+
+When the *same* assertion logic runs across many input/expectation pairs, don't copy-paste the test
+body — drive one test template from a table of cases. It cuts duplication, makes the covered cases
+visible at a glance, and makes adding a case a one-line change. Use your framework's mechanism:
+`@pytest.mark.parametrize` (Python), `it.each` / `test.each` (Jest/Vitest), JUnit `@ParameterizedTest`,
+Go table-driven subtests (`for _, tc := range cases { t.Run(... ) }`), RSpec shared examples.
+
+```python
+@pytest.mark.parametrize("raw, expected", [
+    (1234.5, "$1,234.50"),   # positive
+    (0,      "$0.00"),       # zero
+    (-500,   "-$500.00"),    # negative
+])
+def test_format_currency(raw, expected):
+    assert format_currency(raw) == expected
+```
+
+- **Name each case** (or include the input in the assertion message) so a failure says *which* row
+  failed, not just "case 3."
+- Reach for it especially on pure functions, validators, and boundary tables (see *Cover edge cases*).
+
+> Stack-agnostic adaptation of parameterized/table-driven testing (one template, many input/expectation
+> rows) from the Apache-2.0 [`google/patrick`](https://github.com/google/patrick). Re-derived in prose;
+> not vendored — the pattern is supported natively across test frameworks.
+
+## Semantic Equality and Structured Assertions
+
+Asserting deep equality with the default operator is brittle: floating-point results need *tolerance*,
+some fields are legitimately unordered, and a raw "expected != actual" failure on a big struct is
+unreadable. Assert on the *meaning*, and surface a readable diff:
+
+- **Use tolerant comparison for floats** (`abs(a-b) < eps` / `pytest.approx` / `assertAlmostEqual`),
+  and define explicit equality for domain types (NaN handling, set-vs-list, ignore server-set
+  timestamps/ids) rather than comparing raw representations.
+- **Prefer a structured diff** on failure — assert with a matcher that prints *what differs*
+  (field-by-field), not two opaque blobs. Most ecosystems have one (`assertEqual` deep-diff,
+  `jest`'s object diff, `deepdiff` in Python, custom comparers).
+- **Don't snapshot-compare to dodge this** — a tolerant, intention-revealing comparator beats a
+  brittle golden file (see *Never Test → Snapshot tests*).
+
+> Stack-agnostic adaptation of semantic-equality testing (custom comparators with float tolerance /
+> domain equality, structured diffs over raw deep-equality) from the BSD-3-Clause
+> [`google/go-cmp`](https://github.com/google/go-cmp). Re-derived in prose; not vendored.
+
+## Fuzzing (and continuous fuzzing in CI)
+
+Example-based and even property-based tests (see the property-based testing section in
+`.claude/skills/test-driven-development`) only exercise inputs you *thought of*. **Fuzzing** generates
+inputs you didn't — it mutates a seed corpus under **coverage feedback**, steering toward new code
+paths, and flags any input that crashes, hangs, or trips an assertion/sanitizer. It is the highest-value
+technique for code that parses or decodes **untrusted input** (parsers, deserializers, protocol/codec
+handlers, anything taking bytes from the network or a file) and complements the ReDoS / input-validation
+hardening in `.claude/skills/security-and-hardening`.
+
+- **Write a fuzz target:** a single entry point that takes an arbitrary byte string / structured input
+  and feeds it through the code under test. Most ecosystems ship a coverage-guided fuzzer — Go
+  `testing.F`, Rust `cargo-fuzz`, Python `atheris`, JS `jazzer.js`, JVM `Jazzer`, C/C++ libFuzzer/AFL++.
+- **Seed and grow a corpus.** Start from valid example inputs; the fuzzer evolves them. Keep the corpus
+  (and any crash reproducers) in the repo so findings are reproducible and regressions are caught.
+- **Structure-aware fuzzing for structured inputs.** For inputs behind a schema (protobuf, JSON Schema,
+  a typed AST), generate *semantically valid* inputs from the schema so the fuzzer spends its budget on
+  logic, not on getting past the parser.
+- **Make it continuous, as a CI gate.** Run a short, code-change-scoped fuzz pass on each PR (catches
+  regressions cheaply — a few minutes), and a longer batch run on a schedule to build the corpus and
+  reach deeper bugs. Every crash becomes a regression test. (Wire the PR pass into
+  `.claude/rules/ci-cd-and-automation.md` alongside lint/test.)
+
+> Stack-agnostic adaptation of coverage-guided fuzzing and **continuous fuzzing as a CI gate**
+> (PR-scoped code-change runs + scheduled batch + corpus/crash management) from the Apache-2.0
+> [`google/atheris`](https://github.com/google/atheris),
+> [`google/honggfuzz`](https://github.com/google/honggfuzz), and
+> [`google/clusterfuzzlite`](https://github.com/google/clusterfuzzlite). Re-derived in prose; not
+> vendored — the discipline maps onto each ecosystem's native fuzzer.
+
+## Parallel Execution and Flakiness Detection
+
+As a suite grows, two things matter beyond correctness: it must run **fast** and it must be
+**deterministic**.
+
+- **Run tests in parallel.** Shard across workers (≈ CPU cores) — most runners do this with a flag
+  (`pytest -n auto`, `go test` package parallelism + `t.Parallel()`, `jest`/`vitest` default workers).
+  Parallelism is only safe if tests are **isolated**: no shared mutable global, DB row, temp file, or
+  port between tests (see *No test interdependence*). Flakiness that appears *only* under parallelism is
+  a hidden shared-state bug — fix the isolation, don't serialize to hide it.
+- **Hunt flakiness deliberately.** A test that passes 99 % of the time is a latent failure. Periodically
+  **repeat** the suite (or a suspect test) many times and treat any nondeterministic result as a defect
+  to fix, not a flake to retry. Run with repetition and randomized ordering (`--count=N` /
+  `pytest-repeat` / `--shuffle`) so order-dependence and timing races surface in CI, not in production.
+- The usual root causes: time/clock assumptions (use the condition-waiting discipline in *Async/
+  Event-Loop Systems*, never `sleep`), order dependence, shared fixtures, and unawaited async work.
+
+> Stack-agnostic adaptation of parallel test sharding + repeated-run flakiness detection from the
+> Apache-2.0 [`google/gtest-parallel`](https://github.com/google/gtest-parallel). Re-derived in prose;
+> not vendored.
+
 ## Integration with Workflow
 
 This file defines unit testing standards. Integration and end-to-end testing are covered separately: