claude-code-kit 0.43.0__tar.gz → 0.44.0__tar.gz

{claude_code_kit-0.43.0 → claude_code_kit-0.44.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.43.0",
+      "version": "0.44.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

{claude_code_kit-0.43.0 → claude_code_kit-0.44.0}/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.43.0",
+  "version": "0.44.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.43.0 → claude_code_kit-0.44.0}/CHANGELOG.md

@@ -4,6 +4,36 @@ 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.44.0] — 2026-06-27
+
+**Token-economy pass** — cut claude-kit's eager per-session context cost without removing any SDLC
+capability. Grounded in the official Claude Code cost/settings/hooks/memory docs and a measured audit
+of the kit's own footprint; full state stays on disk, full pipeline detail stays in the on-demand
+rules, and **no** model/effort/thinking levers were changed (every gate keeps its current model).
+
+- **SessionStart hooks no longer dump whole files into context.** `hooks/scripts/load-continuity.sh`
+  replaced its unbounded `cat CONTINUITY.md` (the single largest eager cost — a mature working-memory
+  file ran ~33 KB / ~8,300 tokens **every** session) with a bounded head+tail digest that preserves
+  both ends (Current Phase / Active Tasks at the top, Next Steps / Blocked / Test-Build Status at the
+  bottom) and trims only the unbounded middle; a 49 KB file now injects ~7.9 KB. Small files are
+  emitted unchanged. `load-learnings.sh` gained the same cap on the learnings index. The full files
+  stay on disk and are pointed to in the trimmed output.
+- **The scaffolded `settings.json` now ships token-budget defaults** (added in `build_settings()`, so
+  both the pip-installed file and the no-pip `templates/settings.json` starter carry them, enforced by
+  a new parity test): `env.CLAUDE_CODE_DISABLE_TERMINAL_TITLE=1` (skips a background Haiku title call
+  in headless/subagent runs), explicit `autoCompactEnabled: true` (the kit's
+  CONTINUITY-survives-compaction design depends on it), and `maxSkillDescriptionChars: 1100` (above the
+  longest current skill description of ~973 chars, so nothing truncates today while capping the
+  per-turn skill-listing as the catalog grows). Deliberately **not** baked in:
+  `model`/`fallbackModel`/`effortLevel`/`MAX_THINKING_TOKENS` — those would silently lower reasoning on
+  judgment-heavy gates (left for an explicit opt-in profile later).
+- **`templates/CLAUDE.md` trimmed 246 → 157 lines** (~3.2 KB off the one file loaded in full every
+  session). The pipeline prose that merely restated `mandatory-workflow.md` / `quality-gates.md`
+  (already read on-demand by the agents) is collapsed to a tight phase index that defers to those
+  rules; every `.claude/rules/*.md` citation is kept, the per-task "Coding Behavior" guidance is kept
+  verbatim, and a `## Compact instructions` section was added so auto-compaction preserves the
+  resume-critical state. Meets the official sub-200-line CLAUDE.md guideline.
+
 ## [0.43.0] — 2026-06-26
 
 **New `otel-tracing` collection skill** — vendor-neutral distributed tracing with OpenTelemetry and

{claude_code_kit-0.43.0 → claude_code_kit-0.44.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.43.0
+Version: 0.44.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

{claude_code_kit-0.43.0 → claude_code_kit-0.44.0}/hooks/scripts/load-continuity.sh

@@ -29,7 +29,23 @@ fi
 
 echo "## Working memory (.claude/CONTINUITY.md) — read before acting; write back before the turn ends:"
 echo
-cat "$LIVE"
+
+# Bound the injected size. This file is dumped into context on EVERY session start, and a mature
+# CONTINUITY.md can grow to tens of KB. Cap it to a digest that keeps BOTH ends — the top
+# (Current Phase / Active Tasks) and the bottom (Next Steps / Blocked / Test-Build Status) — and trims
+# only the middle (the unbounded Completed / Decisions / Modified-Files lists). The full file is always
+# on disk; agents open it directly when they need the trimmed detail. Small files are emitted unchanged.
+CAP=8000          # ~2,000 tokens
+SIZE=$(wc -c <"$LIVE" 2>/dev/null || echo 0)
+SIZE=${SIZE//[!0-9]/}
+SIZE=${SIZE:-0}
+if [ "$SIZE" -le "$CAP" ]; then
+  cat "$LIVE"
+else
+  head -c 5500 "$LIVE"
+  printf '\n\n...[middle of CONTINUITY.md trimmed to save context — %s bytes total; open .claude/CONTINUITY.md for the full working memory]...\n\n' "$SIZE"
+  tail -c 2000 "$LIVE"
+fi
 echo
 echo "Resume from \"Next Steps\". If you change phase or finish work, update CONTINUITY.md before ending the turn. Promote durable lessons to .claude/agent-memory/ via the remember skill."
 

{claude_code_kit-0.43.0 → claude_code_kit-0.44.0}/hooks/scripts/load-learnings.sh

@@ -21,7 +21,20 @@ ENTRIES=${ENTRIES:-0}
 
 echo "## Accumulated learnings (from .claude/agent-memory/) — apply these before relevant work:"
 echo
-cat "$INDEX"
+
+# Bound the injected index. It is dumped into context on EVERY session start and grows with each
+# learning; cap it so an aged repo's index can't quietly become a per-session tax. The full index is
+# always on disk (.claude/agent-memory/MEMORY.md); the consolidation nudge below keeps it lean.
+CAP=8000          # ~2,000 tokens
+ISIZE=$(wc -c <"$INDEX" 2>/dev/null || echo 0)
+ISIZE=${ISIZE//[!0-9]/}
+ISIZE=${ISIZE:-0}
+if [ "$ISIZE" -le "$CAP" ]; then
+  cat "$INDEX"
+else
+  head -c "$CAP" "$INDEX"
+  printf '\n\n...[learnings index trimmed to save context — %s bytes total; open .claude/agent-memory/MEMORY.md for the full index]...\n' "$ISIZE"
+fi
 echo
 echo "Before design or implementation, open the category file whose \"applies when\" matches the current task and follow it. New learnings are captured automatically; you may also use the /remember skill."
 

{claude_code_kit-0.43.0 → claude_code_kit-0.44.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.43.0"
+version = "0.44.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.43.0 → claude_code_kit-0.44.0}/src/claude_kit/__init__.py

@@ -7,4 +7,4 @@ Docker): ``claude-kit init`` asks ordered questions and lays down ``CLAUDE.md``
 as a plugin. Extensibility is data-driven via the ``catalog/`` (stacks, profiles, MCP).
 """
 
-__version__ = "0.43.0"
+__version__ = "0.44.0"

{claude_code_kit-0.43.0 → claude_code_kit-0.44.0}/src/claude_kit/hooks.py

@@ -287,6 +287,23 @@ _STARTER_COMMENT = (
     "existing settings.json as needed."
 )
 
+#: Token-budget defaults baked into every assembled settings.json (the pip-installed file AND the
+#: no-pip starter, since both go through :func:`build_settings`). These trim per-session/per-turn
+#: context cost without lowering reasoning on any gate — we deliberately do NOT set
+#: ``model``/``effortLevel``/``MAX_THINKING_TOKENS`` here, as those would cut capability on the
+#: judgment-heavy review/security stages.
+#:  - ``env.CLAUDE_CODE_DISABLE_TERMINAL_TITLE`` skips the background Haiku title request in
+#:    headless/subagent runs (the SDLC pipeline spawns many subagents).
+#:  - ``autoCompactEnabled`` is already the Claude Code default; set explicitly because the kit's
+#:    CONTINUITY-survives-compaction design depends on auto-compaction staying on.
+#:  - ``maxSkillDescriptionChars`` bounds the per-turn skill listing; 1100 sits above the kit's
+#:    longest current skill description (~973 chars) so nothing truncates today while capping growth.
+_TOKEN_BUDGET: dict[str, Any] = {
+    "env": {"CLAUDE_CODE_DISABLE_TERMINAL_TITLE": "1"},
+    "autoCompactEnabled": True,
+    "maxSkillDescriptionChars": 1100,
+}
+
 #: Event ordering for a stable, readable settings.json.
 _EVENT_ORDER = (
     "SessionStart",
@@ -362,6 +379,7 @@ def build_settings(
     ]
     return {
         "$comment": comment or _INSTALLED_COMMENT,
+        **_TOKEN_BUDGET,
         "hooks": _hooks_block(specs),
     }
 

claude_code_kit-0.44.0/templates/CLAUDE.md

@@ -0,0 +1,157 @@
+# Engineering Delivery Rules
+
+These rules are mandatory for all work in this repository. They define an autonomous,
+agent-driven software development lifecycle (SDLC): every change moves through spec →
+review → implementation → code review → testing → security → delivery, with quality
+gates between phases.
+
+> Installed by **claude-kit**. This file is the entry point and is loaded into context every
+> session, so it is kept lean — the full pipeline, gating rules, agent roles, and rule details
+> live on-demand in `.claude/rules/`, `.claude/agents/`, and `.claude/skills/` (cited inline below).
+
+---
+
+## Coding Behavior (applies to ALL implementation work)
+
+**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
+
+### Think Before Coding
+
+**Don't assume. Don't hide confusion. Surface tradeoffs.**
+
+Before implementing:
+- State your assumptions explicitly. If uncertain, ask.
+- If multiple interpretations exist, present them — don't pick silently.
+- If a simpler approach exists, say so. Push back when warranted.
+- If something is unclear, stop. Name what's confusing. Ask.
+
+### Simplicity First
+
+**Minimum code that solves the problem. Nothing speculative.**
+
+- No features beyond what was asked.
+- No abstractions for single-use code.
+- No "flexibility" or "configurability" that wasn't requested.
+- No error handling for impossible scenarios.
+- If you write 200 lines and it could be 50, rewrite it.
+
+Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
+
+### Surgical Changes
+
+**Touch only what you must. Clean up only your own mess.**
+
+When editing existing code:
+- Don't "improve" adjacent code, comments, or formatting.
+- Don't refactor things that aren't broken.
+- Match existing style, even if you'd do it differently.
+- If you notice unrelated dead code, mention it — don't delete it.
+
+When your changes create orphans:
+- Remove imports/variables/functions that YOUR changes made unused.
+- Don't remove pre-existing dead code unless asked.
+
+When you replace code:
+- Delete the path you superseded — don't leave a backwards-compat shim "just in case." Keep one only
+  when backward compatibility is an actual, stated requirement (and say why).
+- Validate inputs at the boundary (entry point / public function), not redundantly in every internal
+  layer that already received validated data.
+- Comments explain *why*, never narrate *what just changed* ("// added this") — see
+  `.claude/rules/documentation.md` §6. Reference code as `path:line` in notes and handoffs.
+
+The test: Every changed line should trace directly to the user's request.
+
+### Goal-Driven Execution
+
+**Define success criteria. Loop until verified.**
+
+Transform tasks into verifiable goals:
+- "Add validation" → "Write tests for invalid inputs, then make them pass"
+- "Fix the bug" → "Write a test that reproduces it, then make it pass"
+- "Refactor X" → "Ensure tests pass before and after"
+
+For multi-step tasks, state a brief plan with a verification check per step.
+
+Strong success criteria let you loop independently. Weak criteria ("make it work")
+require constant clarification.
+
+---
+
+## The SDLC pipeline
+
+Every non-trivial change moves through these phases, each **gated** (a gate passes only with zero open
+Critical/High/Medium findings). This is the map only — the **full** step-by-step pipeline (agent roles,
+gating rules, parallel-lane handling, the defect-loop protocol) lives in
+`.claude/rules/mandatory-workflow.md`, and the severity/review/gate model lives in
+`.claude/rules/quality-gates.md`. Read those before driving a phase.
+
+1. **Spec first** — no implementation code until a written spec exists; update the spec if the task
+   changes. (Spec & Doc Writer; for UI work the UI Designer drafts a design spec first — screen states,
+   interactions, empty/loading/error states, responsive behavior, accessibility.)
+2. **Review chain** — Senior Developer → Technical Architect → Engineering Manager review the spec
+   before any code. Independent work streams (the canonical example is a backend lane and a frontend
+   lane, but it applies to any split) run their review chains **in parallel**, joined by a Merge
+   Reviewer at shared-contract / integration points.
+3. **Implementation** — only after reviews pass; one isolated worktree per parallel stream, each with
+   its own Code Reviewer.
+4. **Testing** — Tester → Senior Tester (parallel lanes for multi-stream work), then a test-coverage
+   merge review confirming every acceptance criterion is covered with no gaps.
+5. **Security** — the `security-reviewer` dispatches `secret-scanner`, `dependency-scanner`,
+   `owasp-reviewer`, and `policy-validator`, and gates **Security Clear**.
+6. **Delivery & operability** — for deployable/observable changes, `devops-engineer` (Pipeline Green)
+   and `observability-engineer` (Observability Ready) run after testing and before the PR Raiser.
+
+**Defect loop:** on any failure / regression / spec-mismatch, document and classify it by work stream,
+update the spec if expected behavior is unclear, then re-run **only the affected stream(s)** through
+their chain → merge review → Tester → Senior Tester. Don't patch defects outside the process; don't
+re-run unaffected lanes.
+
+**Roles** map to agents in `.claude/agents/` (Spec & Doc Writer, UI Designer, Senior Developer,
+Technical Architect, Engineering Manager, Developer, Code Reviewer, Tester, Senior Tester, Unit/E2E
+Tester, Security Reviewer + sub-scanners, Devil's Advocate, Merge Reviewer, DevOps Engineer,
+Observability Engineer, PR Raiser, Orchestrator). The Orchestrator coordinates and gates — it never
+writes code. State which role is being simulated at each stage when it helps clarity.
+
+**Fast-track:** for bug fixes, typos, single-component changes, or config updates (< 5 files), skip the
+spec/design/review chain and go straight to Developer → Code Reviewer → Tester → PR Raiser. If asked
+for speed on larger work, you may compress the process but must preserve the sequence and outputs.
+
+## Quality bar & documentation
+
+- **Optimize for:** simplicity, correctness, scalability, reliability, maintainability, observability,
+  testability, security, and user experience.
+- **Documentation is mandatory** for every change: a module/file header on every new/modified source
+  file, a docstring on every public function (arguments, return value, errors), full type annotations
+  on public signatures, named typed structures over opaque maps, API metadata on every endpoint where
+  applicable, and a README update when endpoints, env vars, structure, or architecture change. See
+  `.claude/rules/documentation.md`.
+
+## Working memory, self-check & gates
+
+- **Working memory:** read/write `.claude/CONTINUITY.md` every turn and at each stage transition so
+  work survives context compaction and new sessions. Distinct from `.claude/agent-memory/` (durable
+  learnings). See `.claude/rules/continuity.md`.
+- **RARV:** every agent runs Reason → Act → Reflect → Verify and shows a green Verify before handoff.
+  See `.claude/rules/rarv-cycle.md`.
+- **Severity & review:** classify every finding Critical/High/Medium/Low/Cosmetic; a gate passes only
+  with zero Critical/High/Medium open. A unanimous PASS triggers the `devils-advocate` agent before the
+  gate counts. See `.claude/rules/quality-gates.md`.
+- **DevOps & Observability gates** run after testing and before the PR for deployable/observable
+  surfaces. See `.claude/rules/devops-observability.md`.
+
+## Compact instructions
+
+When compacting this conversation, preserve: the current phase and which gate is open, the contents of
+`.claude/CONTINUITY.md` (working memory), unresolved Critical/High/Medium findings, the active spec and
+its acceptance criteria, and any in-flight defect loop. Keep auto-compaction enabled — the
+working-memory protocol above is what lets a compacted or fresh session resume exactly where the last
+one left off.
+
+---
+
+## Project-specific rules
+
+> Add your stack's conventions here (language style, framework patterns, naming, directory
+> layout, test commands). The pipeline is stack-agnostic; this section is where you make it
+> yours. Add matching rule files under `.claude/rules/` and reference them from the relevant
+> agents.

{claude_code_kit-0.43.0 → claude_code_kit-0.44.0}/templates/settings.json

@@ -1,5 +1,10 @@
 {
   "$comment": "Recommended Claude Code settings installed by claude-kit. Hooks wire the SDLC working-memory, learnings, guardrails, and quality checks to the scripts in .claude/hooks/. Merge with your existing settings.json as needed.",
+  "env": {
+    "CLAUDE_CODE_DISABLE_TERMINAL_TITLE": "1"
+  },
+  "autoCompactEnabled": true,
+  "maxSkillDescriptionChars": 1100,
   "hooks": {
     "SessionStart": [
       {

claude_code_kit-0.43.0/templates/CLAUDE.md

@@ -1,246 +0,0 @@
-# Engineering Delivery Rules
-
-These rules are mandatory for all work in this repository. They define an autonomous,
-agent-driven software development lifecycle (SDLC): every change moves through spec →
-review → implementation → code review → testing → security → delivery, with quality
-gates between phases.
-
-> Installed by **claude-kit**. The full pipeline, agents, skills, and rule details live in
-> `.claude/rules/`, `.claude/agents/`, and `.claude/skills/`. This file is the entry point.
-
----
-
-## Coding Behavior (applies to ALL implementation work)
-
-**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
-
-### Think Before Coding
-
-**Don't assume. Don't hide confusion. Surface tradeoffs.**
-
-Before implementing:
-- State your assumptions explicitly. If uncertain, ask.
-- If multiple interpretations exist, present them — don't pick silently.
-- If a simpler approach exists, say so. Push back when warranted.
-- If something is unclear, stop. Name what's confusing. Ask.
-
-### Simplicity First
-
-**Minimum code that solves the problem. Nothing speculative.**
-
-- No features beyond what was asked.
-- No abstractions for single-use code.
-- No "flexibility" or "configurability" that wasn't requested.
-- No error handling for impossible scenarios.
-- If you write 200 lines and it could be 50, rewrite it.
-
-Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
-
-### Surgical Changes
-
-**Touch only what you must. Clean up only your own mess.**
-
-When editing existing code:
-- Don't "improve" adjacent code, comments, or formatting.
-- Don't refactor things that aren't broken.
-- Match existing style, even if you'd do it differently.
-- If you notice unrelated dead code, mention it — don't delete it.
-
-When your changes create orphans:
-- Remove imports/variables/functions that YOUR changes made unused.
-- Don't remove pre-existing dead code unless asked.
-
-When you replace code:
-- Delete the path you superseded — don't leave a backwards-compat shim "just in case." Keep one only
-  when backward compatibility is an actual, stated requirement (and say why).
-- Validate inputs at the boundary (entry point / public function), not redundantly in every internal
-  layer that already received validated data.
-- Comments explain *why*, never narrate *what just changed* ("// added this") — see
-  `.claude/rules/documentation.md` §6. Reference code as `path:line` in notes and handoffs.
-
-The test: Every changed line should trace directly to the user's request.
-
-### Goal-Driven Execution
-
-**Define success criteria. Loop until verified.**
-
-Transform tasks into verifiable goals:
-- "Add validation" → "Write tests for invalid inputs, then make them pass"
-- "Fix the bug" → "Write a test that reproduces it, then make it pass"
-- "Refactor X" → "Ensure tests pass before and after"
-
-For multi-step tasks, state a brief plan with a verification check per step.
-
-Strong success criteria let you loop independently. Weak criteria ("make it work")
-require constant clarification.
-
----
-
-## 1) Spec-first rule
-Do not write implementation code until a written spec exists.
-
-Before coding:
-- identify whether a relevant spec already exists
-- if not, draft one first
-- if the task changes, update the spec before continuing
-
-A task is not ready for implementation until the spec is explicit enough to review.
-
-## 2) Review workflow before implementation
-Before writing code, follow this workflow:
-
-1. **Spec & Doc Writer** writes specification + developer documentation in a single pass
-2. **UI Designer** (if UI work) — drafts and self-reviews the design spec
-3. Spec is reviewed by the appropriate **Senior Developer** (per work stream)
-4. Spec is reviewed by the **Technical Architect** — validates system design, scalability, integration
-5. Spec is reviewed by the **Engineering Manager** — final strategic and completeness check
-6. **Implementation** starts only after all reviews are complete
-
-At any stage, reviewers may request corrections. If anything is missing, update the spec
-and re-run the affected review.
-
-### Parallel execution for multi-stream work
-When a task spans two or more **independent work streams** (the canonical example is a
-backend lane and a frontend lane, but it applies to any split — service A vs. service B,
-API vs. client, data layer vs. UI):
-
-- Each stream's review chain (Senior Developer → Technical Architect → EM) runs **in parallel**.
-- After all review chains pass, a **Merge Reviewer** verifies cross-stream consistency
-  (shared contracts, data models, shared state).
-- Implementation then runs **in parallel**, one stream per isolated worktree, each with
-  its own **Code Reviewer**.
-- After all implementations pass code review and unit tests, the **Merge Reviewer** verifies
-  integration compatibility.
-- Only then does integration testing proceed.
-
-Independent work streams must never block each other. Merge-reviewer gates ensure
-consistency at join points.
-
-## 3) Design-first workflow for UI changes
-For any frontend, UI, UX, or interaction change:
-
-1. the **UI Designer** drafts a design spec (includes self-review against a quality checklist)
-2. the design spec describes: screen states, interactions, component behavior,
-   empty/loading/error states, responsive behavior, accessibility
-3. UI implementation begins only after the design spec is complete
-
-Do not start UI implementation from a vague request when a design spec is required.
-
-## 4) Required roles
-Each role maps to a dedicated agent in `.claude/agents/`:
-
-**Spec & Documentation:** Spec & Doc Writer · UI Designer
-**Review chain (per work stream):** Senior Developer · Technical Architect · Engineering Manager
-**Implementation & code review:** Developer · Code Reviewer
-**Testing:** Tester · Senior Tester · Unit Tester · E2E Tester
-**Security:** Security Reviewer + sub-scanners (Secret · Dependency · OWASP · Policy)
-**Review rigor:** Devil's Advocate (anti-sycophancy, on a unanimous PASS)
-**Integration:** Merge Reviewer
-**Delivery & operability:** DevOps Engineer · Observability Engineer · PR Raiser
-**Coordination:** Orchestrator (never writes code — only delegates and gates)
-
-State which role is being simulated at each stage when it helps clarity.
-
-## 5) Testing workflow
-After implementation, testing runs in parallel lanes for multi-stream work:
-
-- **Tester phase (parallel):** API/contract tester · UI tester · integration (end-to-end) tester
-- **Senior Tester phase (parallel, after testers):** each independently verifies a tester's
-  coverage and findings
-- **Test-coverage merge review:** the Merge Reviewer confirms every acceptance criterion is
-  covered across lanes, with no gaps and no contradictions
-
-For single-stream or small features, a single Tester + single Senior Tester is sufficient.
-Testing is not complete until senior verification AND the coverage merge review pass.
-
-## 6) Defect loop
-If any failure, defect, regression, or spec mismatch is found:
-
-1. document the issue clearly and classify it by work stream
-2. update the spec if expected behavior is unclear
-3. re-run **only the affected stream(s)** through their chain
-4. re-run the Merge Reviewer for cross-stream consistency
-5. then re-run Tester → Senior Tester for the affected lanes only
-
-Do not patch defects informally outside the process. Do not re-run unaffected lanes.
-
-## 7) Output expectations
-For each meaningful task, produce outputs in this order unless explicitly overridden:
-
-1. feature spec + developer documentation
-2. design spec (if UI work)
-3. review notes (senior developer → technical architect → EM, per stream)
-4. merge review (spec consistency) — multi-stream only
-5. implementation / code changes
-6. code review notes (per stream)
-7. merge review (code integration) — multi-stream only
-8. tester reports → senior tester verification → test-coverage merge review
-9. security review (Security Clear)
-10. DevOps (Pipeline Green) + Observability (Observability Ready) — for deployable/observable changes
-11. final summary with open issues, if any
-
-## 8) Quality bar
-Optimize for: simplicity, correctness, scalability, reliability, maintainability,
-observability, testability, security, and user experience.
-
-## 9) Documentation standard
-Every change must maintain or improve documentation. See `.claude/rules/documentation.md`.
-
-Mandatory for every change:
-- **Module/file docstring or header** in every new/modified source file
-- **Docstring on every public function** (arguments, return value, errors/exceptions raised)
-- **Full type annotations** where the language supports them — no untyped public signatures
-- **No bare/loose container types** — prefer named, typed structures over opaque maps
-- **README updated** when endpoints, env vars, project structure, or architecture change
-- **API metadata** (summary, response schema, status codes) on every endpoint, where applicable
-
-## 10) Guardrails
-Do not:
-- skip the spec + dev-doc stage
-- skip the design flow for UI work
-- skip the senior developer, technical architect, or EM review
-- skip the code review
-- mark work complete without tester validation
-- mark testing complete without senior tester verification
-- skip the merge reviewer at join points for multi-stream work
-- submit code with missing docstrings or type annotations
-- submit code without updating the README when endpoints or architecture changed
-
-If the user asks for speed, you may compress the process but must preserve the sequence
-and outputs.
-
-**Fast-track mode:** For bug fixes, typos, single-component changes, or config updates
-(< 5 files), skip the spec/design/review chain and go straight to:
-Developer → Code Reviewer → Tester → PR Raiser.
-
-See `.claude/rules/mandatory-workflow.md` for the full step-by-step pipeline with agent
-roles, gating rules, and the defect-loop protocol.
-
----
-
-## 11) Working memory, self-check & quality gates
-
-- **Working memory:** read/write `.claude/CONTINUITY.md` every turn and at each stage
-  transition so work survives context compaction and new sessions. Distinct from
-  `.claude/agent-memory/` (durable learnings). See `.claude/rules/continuity.md`.
-- **RARV:** every agent runs Reason → Act → Reflect → Verify and shows a green Verify
-  before handoff. See `.claude/rules/rarv-cycle.md`.
-- **Severity model:** classify every finding Critical/High/Medium/Low/Cosmetic; a gate
-  passes only with zero Critical/High/Medium open. See `.claude/rules/quality-gates.md`.
-- **Blind review + Devil's Advocate:** parallel reviewers assess independently; a unanimous
-  PASS triggers the `devils-advocate` agent before the gate counts. See `.claude/rules/quality-gates.md`.
-- **Security review:** the `security-reviewer` dispatches `secret-scanner`,
-  `dependency-scanner`, `owasp-reviewer`, and `policy-validator`, and gates **Security Clear**
-  before delivery. See `.claude/rules/quality-gates.md`.
-- **DevOps & Observability:** for changes touching a deployable/observable surface, the
-  `devops-engineer` (Pipeline Green) and `observability-engineer` (Observability Ready)
-  gates run after testing and before the PR. See `.claude/rules/devops-observability.md`.
-
----
-
-## Project-specific rules
-
-> Add your stack's conventions here (language style, framework patterns, naming, directory
-> layout, test commands). The pipeline is stack-agnostic; this section is where you make it
-> yours. Add matching rule files under `.claude/rules/` and reference them from the relevant
-> agents.