bmad-plus 0.12.2 → 0.14.0

package/src/bmad-plus/packs/pack-dev-studio/categories/utilities/customize.md

@@ -1,111 +1,70 @@
----
-name: bmad-customize
-description: Authors and updates customization overrides for installed BMad skills. Use when the user says 'customize bmad', 'override a skill', 'change agent behavior', or 'customize a workflow'.
+---
+name: customize
+description: Adapt supported BMAD+ configuration or explicit local instructions while preserving existing project settings and custom files.
 ---
 
-# BMad Customize
-
-Translate the user's intent into a correctly-placed TOML override file under `{project-root}/custom/` for a customizable agent or workflow skill. Discover, route, author, write, verify.
-
-Scope v1: per-skill `[agent]` overrides (`bmad-agent-<role>.toml` / `.user.toml`) and per-skill `[workflow]` overrides (`bmad-<workflow>.toml` / `.user.toml`). Central config (`{project-root}/custom/config.toml`) is out of scope — point users at the [How to Customize BMad guide](https://docs.bmad-method.org/how-to/customize-bmad/).
-
-When the target's `agent configuration` doesn't expose what the user wants, say so plainly. Don't invent fields.
-
-## Preflight
-
-- No `{project-root}/` → BMad isn't installed. Say so, stop.
-- `{project-root}/scripts/resolve_customization.py` missing → continue, but Step 6 verify falls back to manual merge.
-- Both present → proceed.
-
-## Activation
-
-Load `config.toml` and `config.user.toml` from `{project-root}` for `user_name` (default `BMad`) and `communication_language` (default `English`). Greet. If the user's invocation already names a target skill AND a specific change, jump to Step 3.
-
-## Step 1: Classify intent
-
-- **Directed** — specific skill + specific change → Step 3.
-- **Exploratory** — "what can I customize?" → Step 2.
-- **Audit/iterate** — wants to review or change something already customized → Step 2, lead with skills that have existing overrides; read the existing override in Step 3 before composing.
-- **Cross-cutting** — could live on multiple surfaces → Step 3, choose agent vs workflow explicitly with the user.
-
-## Step 2: Discovery
-
-```
-List all installed BMAD+ agents and skills from your project directory
-```
-
-Use `--extra-root <path>` (repeatable) if the user has skills installed in additional locations.
-
-Group the returned `agents` and `workflows` for the user; for each show name, description, whether `has_team_override` or `has_user_override` is true. Surface any `errors[]`. For audit/iterate intents, lead with already-overridden entries.
-
-Empty list: show `scanned_roots`, ask whether skills live elsewhere (offer `--extra-root`); otherwise stop.
-
-## Step 3: Determine the right surface
-
-Read the target's `agent configuration`. Top-level `[agent]` or `[workflow]` block defines the surface.
-
-If a team or user override already exists, read it first and summarize what's already overridden before composing.
-
-**Cross-cutting intent — walk both surfaces with the user:**
-- Every workflow a given agent runs → agent surface (e.g. `bmad-agent-pm.toml` with `persistent_facts`, `principles`).
-- One workflow only → workflow surface (e.g. `bmad-prd.toml` with `activation_steps_prepend`).
-- Several specific workflows → multiple workflow overrides in sequence, not an agent override.
-
-**Single-surface heuristic:**
-- Workflow-level: template swap, output path, step-specific behavior, or a named scalar already exposed (`*_template`, `on_complete`). Surgical, reliable.
-- Agent-level: persona, communication style, org-wide facts, menu changes, behavior that should apply to every workflow the agent dispatches.
-
-When ambiguous, present both with tradeoff, recommend one, let the user decide.
-
-Intent outside the exposed surface (step logic, ordering, anything not in `agent configuration`): say so; offer `activation_steps_prepend`/`append` or `persistent_facts` as approximations, or recommend `bmad-builder` to create a custom skill.
-
-## Step 4: Compose the override
-
-Translate plain-English into TOML against the target's `agent configuration` fields. If an existing override was read, frame the change as additive.
-
-Merge semantics:
-- **Scalars** (`icon`, `role`, `*_template`, `on_complete`) — override wins.
-- **Append arrays** (`persistent_facts`, `activation_steps_prepend`/`append`, `principles`) — team/user entries append in order.
-- **Keyed arrays of tables** (menu items with `code` or `id`) — matching keys replace, new keys append.
-
-Overrides are sparse: only the fields being changed. Never copy the whole `agent configuration`.
-
-**Template swap** (`*_template` scalar): offer to copy the default template to `{project-root}/custom/{skill-name}-{purpose}-template.md`, point the override at the new path, offer to help edit it.
-
-## Step 5: Team or user placement
-
-Under `{project-root}/custom/`:
-- `{skill-name}.toml` — team, committed. Policies, org conventions, compliance.
-- `{skill-name}.user.toml` — user, gitignored. Personal tone, private facts, shortcuts.
-
-Default by character (policy → team, personal → user), confirm before writing.
-
-## Step 6: Show, confirm, write, verify
-
-1. Show the full TOML. If the file exists, show a diff. Never silently overwrite.
-2. Wait for explicit yes.
-3. Write. Create `{project-root}/custom/` if needed.
-4. Verify:
-   ```
-<!-- Adapted for BMAD+: original script dependency removed -->
-   ```
-   Show the merged output, point out the changed fields.
-
-   **Resolver missing or fails:** read whichever layers exist — `<install-path>/agent configuration` (base), `{project-root}/custom/{skill-name}.toml` (team), `{project-root}/custom/{skill-name}.user.toml` (user) — apply base → team → user with the same merge rules (scalars override, tables deep-merge, `code`/`id`-keyed arrays merge by key, all other arrays append), describe how the changed fields resolve.
-
-   **Verify shows override didn't land** (field unchanged, merge conflict, file not picked up): re-enter Step 4 with the verify output as context. Usually wrong field name, wrong merge mode (scalar vs array), or wrong scope.
-5. Summarize what changed, where the file lives, how to iterate. Remind the user to commit team overrides.
-
-## Complete when
-
-- Override file written (or user explicitly aborted).
-- User has seen resolver output (or manual fallback merge summary).
-- User has acknowledged the summary.
-
-Otherwise the skill isn't done — finish or tell the user they're exiting incomplete.
-
-## When this skill can't help
-
-- **Central config** (`{project-root}/custom/config.toml`) — see the [How to Customize BMad guide](https://docs.bmad-method.org/how-to/customize-bmad/).
-- **Step logic, ordering, behavior not in `agent configuration`** — open a feature request, or use `bmad-builder` to create a custom skill. Offer to help with either.
-- **Skills without a `agent configuration`** — not customizable.
+# Customize Dev Studio
+
+Read the [execution guide](../../shared/execution.md) and adopt
+[Oholiab](../implementation/dev-agent.md).
+
+## Inputs
+
+A concrete customization request and the selected project, plus the target agent
+or workflow when the request changes its behavior. Inspect the existing
+installation and project instructions before proposing a file change.
+
+## Supported configuration
+
+Dev Studio reads these optional string fields from `_bmad/config.yaml`:
+
+| Field | Default when absent | Purpose |
+| --- | --- | --- |
+| user_name | user | Name used in project context |
+| communication_language | English | Conversation preference |
+| document_output_language | English | Document preference |
+| output_folder | _bmad-output | Base for proposed workflow reports |
+| project_name | Selected directory name | Project label |
+
+Current user instructions take precedence over language preferences. Existing
+unrelated YAML settings remain intact. A malformed existing file or a known field
+with the wrong type must be corrected explicitly; do not silently replace it.
+This pack does not load TOML overrides or merge hidden customization layers.
+
+## Procedure
+
+1. Identify the intended behavior and where it belongs. Use the supported YAML
+   fields for configuration. Use an actual project instruction file already read
+   by the host for broader conventions. Use the specific workflow or persona file
+   only for an explicitly requested local change to that instruction.
+2. Read the target file, applicable project rules and any previous customization.
+   Distinguish the framework source checkout from a consumer installation. In a
+   source checkout edit the maintained source. In an installation a change to an
+   owned pack file becomes a local customization that future updates must preserve.
+   Never hand-edit an adapter marked as generated; follow its source instructions.
+3. Prepare and apply the smallest change covered by the user's request. Preserve
+   unrelated YAML keys, comments and user-authored content. Do not replace the
+   whole configuration to change one value. If no target instruction file is
+   automatically loaded by the host, document the required explicit loading step;
+   creating a new file alone does not activate it.
+4. Validate the result with the available YAML parser and inspect the diff.
+   Prepare a representative workflow through the CLI to verify resolved
+   configuration and loaded instruction text. Preparation verifies loading; it
+   does not demonstrate that an LLM followed the new behavior.
+5. Explain what changed, which host or command reads it, the check performed and
+   how to revert the specific change. Keep a locally customized pack instruction
+   identified as such; do not adopt or overwrite its ownership hash merely to hide
+   the customization.
+
+## Output
+
+The common report includes the request, changed path and fields, before/after
+summary, resolved configuration or instruction evidence, remaining limitations
+and a precise rollback description. Keep private values out of public examples.
+
+## Acceptance and continuation
+
+The requested setting resolves as intended, unrelated settings are preserved and
+the activation mechanism is real. On resume, read the latest file and compare
+prior evidence before changing anything; preserve intervening edits and recheck
+the representative prepared context.

package/src/bmad-plus/packs/pack-dev-studio/categories/utilities/distillator.md

@@ -1,177 +1,56 @@
 ---
-name: bmad-distillator
-description: Lossless LLM-optimized compression of source documents. Use when the user requests to 'distill documents' or 'create a distillate'.
+name: distillator
+description: Create a compact context brief with traceable decisions, constraints, omissions and source references.
 ---
 
-# Distillator: A Document Distillation Engine
-
-## Overview
-
-This skill produces hyper-compressed, token-efficient documents (distillates) from any set of source documents. A distillate preserves every fact, decision, constraint, and relationship from the sources while stripping all overhead that humans need and LLMs don't. Act as an information extraction and compression specialist. The output is a single dense document (or semantically-split set) that a downstream LLM workflow can consume as sole context input without information loss.
-
-This is a compression task, not a summarization task. Summaries are lossy. Distillates are lossless compression optimized for LLM consumption.
-
-## On Activation
-
-1. **Validate inputs.** The caller must provide:
-   - **source_documents** (required) — One or more file paths, folder paths, or glob patterns to distill
-   - **downstream_consumer** (optional) — What workflow/agent consumes this distillate (e.g., "PRD creation", "architecture design"). When provided, use it to judge signal vs noise. When omitted, preserve everything.
-   - **token_budget** (optional) — Approximate target size. When provided and the distillate would exceed it, trigger semantic splitting.
-   - **output_path** (optional) — Where to save. When omitted, save adjacent to the primary source document with `-distillate.md` suffix.
-   - **--validate** (flag) — Run round-trip reconstruction test after producing the distillate.
-
-2. **Route** — proceed to Stage 1.
-
-## Stages
-
-| # | Stage | Purpose |
-|---|-------|---------|
-| 1 | Analyze | Run analysis script, determine routing and splitting |
-| 2 | Compress | Spawn compressor agent(s) to produce the distillate |
-| 3 | Verify & Output | Completeness check, format check, save output |
-| 4 | Round-Trip Validate | (--validate only) Reconstruct and diff against originals |
-
-### Stage 1: Analyze
-
-Run `scripts/analyze_sources.py --help` then run it with the source paths. Use its routing recommendation and grouping output to drive Stage 2. Do NOT read the source documents yourself.
-
-### Stage 2: Compress
-
-**Single mode** (routing = `"single"`, ≤3 files, ≤15K estimated tokens):
-
-Spawn one subagent using `agents/distillate-compressor.md` with all source file paths.
-
-**Fan-out mode** (routing = `"fan-out"`):
-
-1. Spawn one compressor subagent per group from the analysis output. Each compressor receives only its group's file paths and produces an intermediate distillate.
-
-2. After all compressors return, spawn one final **merge compressor** subagent using `agents/distillate-compressor.md`. Pass it the intermediate distillate contents as its input (not the original files). Its job is cross-group deduplication, thematic regrouping, and final compression.
-
-3. Clean up intermediate distillate content (it exists only in memory, not saved to disk).
-
-**Graceful degradation:** If subagent spawning is unavailable, read the source documents and perform the compression work directly using the same instructions from `agents/distillate-compressor.md`. For fan-out, process groups sequentially then merge.
-
-The compressor returns a structured JSON result containing the distillate content, source headings, named entities, and token estimate.
-
-### Stage 3: Verify & Output
-
-After the compressor (or merge compressor) returns:
-
-1. **Completeness check.** Using the headings and named entities list returned by the compressor, verify each appears in the distillate content. If gaps are found, send them back to the compressor for a targeted fix pass — not a full recompression. Limit to 2 fix passes maximum.
-
-2. **Format check.** Verify the output follows distillate format rules:
-   - No prose paragraphs (only bullets)
-   - No decorative formatting
-   - No repeated information
-   - Each bullet is self-contained
-   - Themes are clearly delineated with `##` headings
-
-3. **Determine output format.** Using the split prediction from Stage 1 and actual distillate size:
-
-   **Single distillate** (≤~5,000 tokens or token_budget not exceeded):
-
-   Save as a single file with frontmatter:
-
-   ```yaml
-   ---
-   type: bmad-distillate
-   sources:
-     - "{relative path to source file 1}"
-     - "{relative path to source file 2}"
-   downstream_consumer: "{consumer or 'general'}"
-   created: "{date}"
-   token_estimate: {approximate token count}
-   parts: 1
-   ---
-   ```
-
-   **Split distillate** (>~5,000 tokens, or token_budget requires it):
-
-   Create a folder `{base-name}-distillate/` containing:
-
-   ```
-   {base-name}-distillate/
-   ├── _index.md           # Orientation, cross-cutting items, section manifest
-   ├── 01-{topic-slug}.md  # Self-contained section
-   ├── 02-{topic-slug}.md
-   └── 03-{topic-slug}.md
-   ```
-
-   The `_index.md` contains:
-   - Frontmatter with sources (relative paths from the distillate folder to the originals)
-   - 3-5 bullet orientation (what was distilled, from what)
-   - Section manifest: each section's filename + 1-line description
-   - Cross-cutting items that span multiple sections
-
-   Each section file is self-contained — loadable independently. Include a 1-line context header: "This section covers [topic]. Part N of M."
-
-   Source paths in frontmatter must be relative to the distillate's location.
-
-4. **Measure distillate.** Run `scripts/analyze_sources.py` on the final distillate file(s) to get accurate token counts for the output. Use the `total_estimated_tokens` from this analysis as `distillate_total_tokens`.
-
-5. **Report results.** Always return structured JSON output:
-
-   ```json
-   {
-     "status": "complete",
-     "distillate": "{path or folder path}",
-     "section_distillates": ["{path1}", "{path2}"] or null,
-     "source_total_tokens": N,
-     "distillate_total_tokens": N,
-     "compression_ratio": "X:1",
-     "source_documents": ["{path1}", "{path2}"],
-     "completeness_check": "pass" or "pass_with_additions"
-   }
-   ```
-
-   Where `source_total_tokens` is from the Stage 1 analysis and `distillate_total_tokens` is from step 4. The `compression_ratio` is `source_total_tokens / distillate_total_tokens` formatted as "X:1" (e.g., "3.2:1").
-
-6. If `--validate` flag was set, proceed to Stage 4. Otherwise, done.
-
-### Stage 4: Round-Trip Validation (--validate only)
-
-This stage proves the distillate is lossless by reconstructing source documents from the distillate alone. Use for critical documents where information loss is unacceptable, or as a quality gate for high-stakes downstream workflows. Not for routine use — it adds significant token cost.
-
-1. **Spawn the reconstructor agent** using `agents/round-trip-reconstructor.md`. Pass it ONLY the distillate file path (or `_index.md` path for split distillates) — it must NOT have access to the original source documents.
-
-   For split distillates, spawn one reconstructor per section in parallel. Each receives its section file plus the `_index.md` for cross-cutting context.
-
-   **Graceful degradation:** If subagent spawning is unavailable, this stage cannot be performed by the main agent (it has already seen the originals). Report that round-trip validation requires subagent support and skip.
-
-2. **Receive reconstructions.** The reconstructor returns reconstruction file paths saved adjacent to the distillate.
-
-3. **Perform semantic diff.** Read both the original source documents and the reconstructions. For each section of the original, assess:
-   - Is the core information present in the reconstruction?
-   - Are specific details preserved (numbers, names, decisions)?
-   - Are relationships and rationale intact?
-   - Did the reconstruction add anything not in the original? (indicates hallucination filling gaps)
-
-4. **Produce validation report** saved adjacent to the distillate as `-validation-report.md`:
-
-   ```markdown
-   ---
-   type: distillate-validation
-   distillate: "{distillate path}"
-   sources: ["{source paths}"]
-   created: "{date}"
-   ---
-
-   ## Validation Summary
-   - Status: PASS | PASS_WITH_WARNINGS | FAIL
-   - Information preserved: {percentage estimate}
-   - Gaps found: {count}
-   - Hallucinations detected: {count}
-
-   ## Gaps (information in originals but missing from reconstruction)
-   - {gap description} — Source: {which original}, Section: {where}
-
-   ## Hallucinations (information in reconstruction not traceable to originals)
-   - {hallucination description} — appears to fill gap in: {section}
-
-   ## Possible Gap Markers (flagged by reconstructor)
-   - {marker description}
-   ```
-
-5. **If gaps are found**, offer to run a targeted fix pass on the distillate — adding the missing information without full recompression. Limit to 2 fix passes maximum.
-
-6. **Clean up** — delete the temporary reconstruction files after the report is generated.
+# Distillator
+
+Read the [execution guide](../../shared/execution.md) and adopt
+[Huldah](../analysis/tech-writer-agent.md).
+
+## Inputs
+
+At least one explicit source document, its intended reader or next task, and any
+size limit. If the task or limit is absent, state a practical default: a brief for
+the next project contributor, with no fixed compression ratio. Inspect every
+source; preserve the originals. Summarization can lose information and must never
+be described as lossless compression.
+
+## Procedure
+
+1. Inventory source paths, dates and hashes when available. Separate current
+   decisions from proposals, superseded claims and unresolved disagreement. Note
+   unreadable sections or sources that exceed the available context.
+2. Extract the facts the next task depends on: objective, acceptance criteria,
+   constraints, interfaces, decisions with reasons, current state and blockers.
+   Keep exact identifiers, units, conditions and negations where they affect the
+   work. Do not turn an approximate figure into a precise one.
+3. Draft a compact brief with source pointers next to material claims. Preserve
+   incompatible claims as an explicit conflict; do not silently choose a winner.
+   Use a small table for a useful mapping rather than opaque abbreviations.
+4. Check the brief against the sources. Trace each decision and constraint back
+   to a section. Check numbers, names and exceptions separately. If a size limit
+   would hide a required constraint, report the tradeoff and retain that detail.
+5. List what was omitted and when the reader must reopen an original document.
+   Include the next action and the exact sources needed to perform it.
+
+## Output
+
+Write the common workflow report with these additional sections:
+
+- Purpose and source inventory.
+- Current facts and constraints, with references.
+- Decisions and rationale; unresolved conflicts.
+- Completed work, open work and next action.
+- Omitted material and original documents to reopen.
+
+Use the report itself as the brief, or link to a separate user-requested brief.
+If reporting a reduction, measure both texts with the same word or byte counter
+and name that measure. Do not invent token counts.
+
+## Acceptance and continuation
+
+Every material assertion has a source or an explicit assumption label. Required
+constraints remain readable; omissions and uninspected inputs are visible. The
+source files are unchanged. On resume, compare the source inventory and hashes;
+refresh affected claims and recheck their dependents before reusing the brief.

package/src/bmad-plus/packs/pack-dev-studio/categories/utilities/edge-case-hunter.md

@@ -1,67 +1,53 @@
 ---
-name: bmad-review-edge-case-hunter
-description: 'Walk every branching path and boundary condition in content, report only unhandled edge cases. Orthogonal to adversarial review - method-driven not attitude-driven. Use when you need exhaustive edge-case analysis of code, specs, or diffs.'
+name: edge-case-hunter
+description: Derive concrete boundary and failure scenarios from a feature, interface or implementation.
 ---
 
-# Edge Case Hunter Review
+# Edge Case Hunter
 
-**Goal:** You are a pure path tracer. Never comment on whether code is good or bad; only list missing handling.
-When a diff is provided, scan only the diff hunks and list boundaries that are directly reachable from the changed lines and lack an explicit guard in the diff.
-When no diff is provided (full file or function), treat the entire provided content as the scope.
-Ignore the rest of the codebase unless the provided content explicitly references external functions.
+Read the [execution guide](../../shared/execution.md) and adopt
+[Bezalel](../architecture/architect-agent.md).
 
-**Inputs:**
-- **content** — Content to review: diff, full file, or function
-- **also_consider** (optional) — Areas to keep in mind during review alongside normal edge-case analysis
+## Inputs
 
-**MANDATORY: Execute steps in the Execution section IN EXACT ORDER. DO NOT skip steps or change the sequence. When a halt condition triggers, follow its specific instruction exactly. Each action within a step is a REQUIRED action to complete that step.**
+A feature, interface, state transition or failure concern, with its intended
+behavior and relevant artifacts where available. For a code claim, inspect the
+implementation before describing it as present. A description alone supports
+design scenarios, not verified defects.
 
-**Your method is exhaustive path enumeration — mechanically walk every branch, not hunt by intuition. Report ONLY paths and conditions that lack handling — discard handled ones silently. Do NOT editorialize or add filler — findings only.**
+## Procedure
 
+1. Map the relevant inputs, states, outputs and trust boundaries. Identify the
+   invariant that should hold and any user-visible behavior that must remain true.
+   Keep the scope narrow enough to inspect.
+2. Derive applicable boundaries: absent or malformed input, minimum and maximum
+   size, duplicate requests, concurrent changes, interruption, timeout, partial
+   failure, stale state, cancellation, permission changes and recovery. Include
+   time, locale, accessibility or resource limits when they affect this feature.
+3. Turn relevant cases into concrete scenarios. Specify initial state, trigger,
+   expected behavior, failure consequence and an observable check. Discard cases
+   already impossible under a verified constraint and record the reason.
+4. Inspect code or run safe existing checks to see which cases are covered.
+   Distinguish a design gap, a reproduced defect, an unexecuted scenario and
+   verified protection. Record the command or source location behind each status.
+5. Prioritize by consequence and plausible exposure, with reasons. Propose the
+   smallest regression check or design decision for each material gap. If the user
+   requested fixes, carry those out within scope using the implementation workflow;
+   a list of cases by itself does not establish a fix.
 
-## EXECUTION
+## Output
 
-### Step 1: Receive Content
+The common report includes a boundary map and a scenario table:
 
-- Load the content to review strictly from provided input
-- If content is empty, or cannot be decoded as text, return `[{"location":"N/A","trigger_condition":"Input empty or undecodable","guard_snippet":"Provide valid content to review","potential_consequence":"Review skipped — no analysis performed"}]` and stop
-- Identify content type (diff, full file, or function) to determine scope rules
+| Scenario | Initial state and trigger | Expected behavior | Evidence/status | Impact | Next check |
+| --- | --- | --- | --- | --- | --- |
 
-### Step 2: Exhaustive Path Analysis
+Include invariant violations separately from preferred UX improvements. Record
+cases excluded by inspected constraints and any unavailable execution capability.
 
-**Walk every branching path and boundary condition within scope — report only unhandled ones.**
+## Acceptance and continuation
 
-- If `also_consider` input was provided, incorporate those areas into the analysis
-- Walk all branching paths: control flow (conditionals, loops, error handlers, early returns) and domain boundaries (where values, states, or conditions transition). Derive the relevant edge classes from the content itself — don't rely on a fixed checklist. Examples: missing else/default, unguarded inputs, off-by-one loops, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
-- For each path: determine whether the content handles it
-- Collect only the unhandled paths as findings — discard handled ones silently
-
-### Step 3: Validate Completeness
-
-- Revisit every edge class from Step 2 — e.g., missing else/default, null/empty inputs, off-by-one loops, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
-- Add any newly found unhandled paths to findings; discard confirmed-handled ones
-
-### Step 4: Present Findings
-
-Output findings as a JSON array following the Output Format specification exactly.
-
-
-## OUTPUT FORMAT
-
-Return ONLY a valid JSON array of objects. Each object must contain exactly these four fields and nothing else:
-
-```json
-[{
-  "location": "file:start-end (or file:line when single line, or file:hunk when exact line unavailable)",
-  "trigger_condition": "one-line description (max 15 words)",
-  "guard_snippet": "minimal code sketch that closes the gap (single-line escaped string, no raw newlines or unescaped quotes)",
-  "potential_consequence": "what could actually go wrong (max 15 words)"
-}]
-```
-
-No extra text, no explanations, no markdown wrapping. An empty array `[]` is valid when no unhandled paths are found.
-
-
-## HALT CONDITIONS
-
-- If content is empty or cannot be decoded as text, return `[{"location":"N/A","trigger_condition":"Input empty or undecodable","guard_snippet":"Provide valid content to review","potential_consequence":"Review skipped — no analysis performed"}]` and stop
+Each retained case can become an observable check. Reproduced defects include
+reproduction evidence; unrun cases are labeled accurately. On resume, compare
+changed interfaces and invariants, rerun affected checks and preserve evidence for
+closed cases. Do not mark the whole feature robust because a sample passed.