@haposoft/cafekit 0.18.0 → 0.18.2

package/src/claude/settings/settings.json

@@ -63,7 +63,7 @@
     ],
     "PreToolUse": [
       {
-        "matcher": "Read|Write|Edit|MultiEdit|Bash|Glob|Grep",
+        "matcher": "Read|Write|Edit|MultiEdit|NotebookEdit|Bash|Glob|Grep|mcp__.*",
         "hooks": [
           {
             "type": "command",

package/src/claude/skills/agent-browser/SKILL.md

@@ -236,7 +236,7 @@ agent-browser snapshot -i
 agent-browser fill @e1 "user@example.com"
 agent-browser fill @e2 "password123"
 agent-browser click @e3  # Submit button
-agent-browser wait url "/dashboard"
+agent-browser wait --url "/dashboard"
 ```
 
 ### State Persistence (Auth)

package/src/claude/skills/ai-multimodal/scripts/check_setup.py

@@ -5,7 +5,6 @@ Validate ai-multimodal skill setup and configuration.
 Checks:
 - API key presence and format
 - Python dependencies
-- Centralized resolver availability
 - Directory structure
 """
 
@@ -85,69 +84,16 @@ def check_dependencies():
     return True
 
 
-def check_centralized_resolver():
-    """Check if centralized resolver is available."""
-    print_header("Checking Centralized Resolver")
-
-    claude_root = Path(__file__).parent.parent.parent.parent
-    resolver_path = claude_root / 'scripts' / 'resolve_env.py'
-
-    if resolver_path.exists():
-        print_success(f"Centralized resolver found: {resolver_path}")
-
-        # Try to import it
-        sys.path.insert(0, str(resolver_path.parent))
-        try:
-            from resolve_env import resolve_env
-            print_success("Centralized resolver can be imported")
-            return True
-        except ImportError as e:
-            print_error(f"Centralized resolver exists but cannot be imported: {e}")
-            return False
-    else:
-        print_warning(f"Centralized resolver not found: {resolver_path}")
-        print_info("Skill will use fallback resolution logic")
-        return True  # Not critical, fallback works
-
-
 def find_api_key():
-    """Find and validate API key using centralized resolver."""
+    """Find the API key in the runtime environment."""
     print_header("Checking API Key Configuration")
-
-    # Try to use centralized resolver
-    claude_root = Path(__file__).parent.parent.parent.parent
-    sys.path.insert(0, str(claude_root / 'scripts'))
-    try:
-        from resolve_env import resolve_env
-
-        print_info("Using centralized resolver...")
-        api_key = resolve_env('GEMINI_API_KEY', skill='ai-multimodal')
-
-        if api_key:
-            print_success("API key found via centralized resolver")
-            print_info(f"Key preview: {api_key[:20]}...{api_key[-4:]}")
-
-            # Show hierarchy
-            print_info("\nTo see where the key was found, run:")
-            print_info("python ~/packages/spec/src/claude/scripts/resolve_env.py GEMINI_API_KEY --skill ai-multimodal --verbose")
-
-            return api_key
-        else:
-            print_error("API key not found in any location")
-            return None
-
-    except ImportError:
-        print_warning("Centralized resolver not available, using fallback")
-
-        # Fallback: check environment
-        api_key = os.getenv('GEMINI_API_KEY')
-        if api_key:
-            print_success("API key found in process.env")
-            print_info(f"Key preview: {api_key[:20]}...{api_key[-4:]}")
-            return api_key
-        else:
-            print_error("API key not found")
-            return None
+    api_key = os.getenv('GEMINI_API_KEY')
+    if api_key:
+        print_success("API key found in process.env")
+        print_info(f"Key preview: {api_key[:20]}...{api_key[-4:]}")
+        return api_key
+    print_error("API key not found")
+    return None
 
 
 def validate_api_key_format(api_key):
@@ -250,9 +196,6 @@ def provide_setup_instructions():
     print("\n3. Verify setup:")
     print(f"   $ python {Path(__file__)}")
 
-    print("\n4. Debug if needed:")
-    print(f"   $ python ~/packages/spec/src/claude/scripts/resolve_env.py --show-hierarchy --skill ai-multimodal")
-    print(f"   $ python ~/packages/spec/src/claude/scripts/resolve_env.py GEMINI_API_KEY --skill ai-multimodal --verbose")
 
 
 def main():
@@ -265,9 +208,6 @@ def main():
     if not check_directory_structure():
         all_passed = False
 
-    # Check centralized resolver
-    check_centralized_resolver()
-
     # Check dependencies
     if not check_dependencies():
         all_passed = False

package/src/claude/skills/ai-multimodal/scripts/gemini_batch_process.py

@@ -23,19 +23,10 @@ from typing import List, Dict, Any, Optional
 import csv
 import shutil
 
-# Import centralized environment resolver (works for both local and global installs)
-CLAUDE_ROOT = Path(__file__).parent.parent.parent.parent
-sys.path.insert(0, str(CLAUDE_ROOT / 'scripts'))
 try:
-    from resolve_env import resolve_env
-    CENTRALIZED_RESOLVER_AVAILABLE = True
+    from dotenv import load_dotenv
 except ImportError:
-    # Fallback if centralized resolver not available
-    CENTRALIZED_RESOLVER_AVAILABLE = False
-    try:
-        from dotenv import load_dotenv
-    except ImportError:
-        load_dotenv = None
+    load_dotenv = None
 
 # Import key rotation support
 sys.path.insert(0, str(Path(__file__).parent.parent.parent / 'common'))
@@ -74,10 +65,7 @@ IMAGEN_MODELS = {
 
 
 def find_api_key() -> Optional[str]:
-    """Find Gemini API key using centralized resolver or fallback.
-
-    Uses ~/packages/spec/src/claude/scripts/resolve_env.py for consistent resolution across all skills.
-    Falls back to local resolution if centralized resolver not available.
+    """Find Gemini API key using local environment resolution.
 
     Priority order (highest to lowest):
     1. process.env (runtime environment variables)
@@ -88,11 +76,6 @@ def find_api_key() -> Optional[str]:
     6. ~/packages/spec/src/claude/skills/.env (user shared)
     7. ~/packages/spec/src/claude/.env (user global)
     """
-    if CENTRALIZED_RESOLVER_AVAILABLE:
-        # Use centralized resolver (recommended)
-        return resolve_env('GEMINI_API_KEY', skill='ai-multimodal')
-
-    # Fallback: Local resolution (legacy)
     api_key = os.getenv('GEMINI_API_KEY')
     if api_key:
         return api_key
@@ -751,18 +734,13 @@ def batch_process(
         print("Error: GEMINI_API_KEY not found in any location")
         print("\nSearched locations (highest to lowest priority):")
         print("  1. OS environment (process.env)")
-        if CENTRALIZED_RESOLVER_AVAILABLE:
-            from resolve_env import get_env_file_paths
-            for i, (desc, path) in enumerate(get_env_file_paths('ai-multimodal'), 2):
-                exists = "[OK]" if path.exists() else "[  ]"
-                print(f"  {i}. {exists} {path}")
-        else:
-            print("  2-7. .env files (centralized resolver unavailable)")
+        print("  2. Runtime .env file")
+        print("  3. Shared skills .env file")
+        print("  4. Skill-specific .env file")
         print("\nQuick fix — add your key to any .env file above:")
         print("  echo 'GEMINI_API_KEY=your-key' >> ~/packages/spec/src/claude/.env")
         print("\nOther options:")
         print("  - Run setup checker: python scripts/check_setup.py")
-        print("  - Show full hierarchy: python ~/packages/spec/src/claude/scripts/resolve_env.py --show-hierarchy --skill ai-multimodal -v")
         print("\nFor key rotation, add multiple keys to any .env:")
         print("   GEMINI_API_KEY=key1")
         print("   GEMINI_API_KEY_2=key2")

package/src/claude/skills/chrome-devtools/SKILL.md

@@ -52,8 +52,7 @@ Browser visibility is resolved automatically by `resolveHeadless()` in `lib/brow
 
 Override with `--headless true` or `--headless false` on any script.
 
-- Run multiple scripts/sessions in parallel to simulate real user interactions.
-- Run multiple scripts/sessions in parallel to simulate different device types (mobile, tablet, desktop).
+Scripts share one browser and its first tab through `.browser-session.json`, so run them one at a time; parallel runs drive the same page.
 
 ## ARIA Snapshot (Element Discovery)
 
@@ -104,7 +103,6 @@ node "$SKILL_DIR/aria-snapshot.js" --url https://example.com --output ./packages
 
 ### Interact by Ref
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
 Use `select-ref.js` to interact with elements by their ref:
 
 ```bash
@@ -129,7 +127,6 @@ node "$SKILL_DIR/select-ref.js" --ref e5 --action hover
 
 ### Store Snapshots
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
 Store snapshots for analysis in `<project>/packages/spec/src/claude/chrome-devtools/snapshots/`:
 
 ```bash
@@ -162,7 +159,6 @@ node "$SKILL_DIR/aria-snapshot.js" --url https://example.com --output packages/s
 
 ## Local HTML Files
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
 **IMPORTANT**: Never browse local HTML files via `file://` protocol. Always serve via local server:
 **Why**: `file://` protocol blocks many browser features (CORS, ES modules, fetch API, service workers). Local server ensures proper HTTP behavior.
 
@@ -176,7 +172,7 @@ python -m http.server 3000 --directory ./dist &
 node "$SKILL_DIR/navigate.js" --url http://localhost:3000
 ```
 
-**Note**: when port 3000 is busy, find an available port with `lsof -i :3000` and use a different one.
+**Note**: when port 3000 is busy, find its owner with `lsof -i :3000`; stop it if you started it, otherwise ask the user. Do not move to another port (`rules/process-management.md`).
 
 ## Quick Start
 
@@ -207,11 +203,10 @@ chrome-devtools auto-detects Chrome at standard OS paths and uses it automatical
 
 ### Manual Configuration
 
-To force a specific Chrome installation, copy `.env.example` to `.env` and set `CHROME_EXECUTABLE_PATH`:
+To force a specific Chrome installation, export `CHROME_EXECUTABLE_PATH` (or `PUPPETEER_EXECUTABLE_PATH`) in the shell that runs the scripts; they read the environment, not a `.env` file:
 
 ```bash
-cp "$SKILL_DIR/.env.example" "$SKILL_DIR/.env"
-# Edit .env and set CHROME_EXECUTABLE_PATH to your Chrome executable
+export CHROME_EXECUTABLE_PATH="/path/to/chrome"
 ```
 
 ### Skip Chromium Download
@@ -249,7 +244,6 @@ node "$SKILL_DIR/navigate.js" --url about:blank --close true
 
 ## Available Scripts
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
 All in `packages/spec/src/claude/skills/chrome-devtools/scripts/`:
 
 | Script | Purpose |
@@ -281,15 +275,14 @@ All in `packages/spec/src/claude/skills/chrome-devtools/scripts/`:
 
 ## Writing Custom Test Scripts
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
-For complex automation, write scripts to `<project>/packages/spec/src/claude/chrome-devtools/tmp/`:
+For complex automation, write scripts to `$SKILL_DIR/../tmp/` (beside `scripts/`, so the `../scripts/lib/browser.js` import resolves):
 
 ```bash
 # Create tmp directory for test scripts
-mkdir -p $SKILL_DIR/packages/spec/src/claude/chrome-devtools/tmp
+mkdir -p "$SKILL_DIR/../tmp"
 
 # Write a test script
-cat > $SKILL_DIR/packages/spec/src/claude/chrome-devtools/tmp/login-test.js << 'EOF'
+cat > "$SKILL_DIR/../tmp/login-test.js" << 'EOF'
 import { getBrowser, getPage, disconnectBrowser, outputJSON } from '../scripts/lib/browser.js';
 
 async function loginTest() {
@@ -315,7 +308,7 @@ loginTest();
 EOF
 
 # Run the test
-node $SKILL_DIR/packages/spec/src/claude/chrome-devtools/tmp/login-test.js
+node "$SKILL_DIR/../tmp/login-test.js"
 ```
 
 **Key principles for custom scripts**:
@@ -327,11 +320,7 @@ node $SKILL_DIR/packages/spec/src/claude/chrome-devtools/tmp/login-test.js
 
 ## Screenshots
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
-
-**IMPORTANT:** Store browser artifacts in a project-local screenshots or reports folder and include exact output paths in the final report.
-
-Store screenshots for analysis in `<project>/packages/spec/src/claude/chrome-devtools/screenshots/`:
+Store screenshots in `<project>/packages/spec/src/claude/chrome-devtools/screenshots/` and give their exact output paths in the final report:
 
 ```bash
 # Basic screenshot
@@ -356,15 +345,13 @@ node "$SKILL_DIR/screenshot.js" --url https://example.com --output ./packages/sp
 node "$SKILL_DIR/screenshot.js" --url https://example.com --output ./packages/spec/src/claude/chrome-devtools/screenshots/page.png --max-size 3
 
 # Disable compression
-node "$SKILL_DIR/screenshot.js" --url https://example.com --output ./packages/spec/src/claude/chrome-devtools/screenshots/page.png --no-compress
+node "$SKILL_DIR/screenshot.js" --url https://example.com --output ./packages/spec/src/claude/chrome-devtools/screenshots/page.png --no-compress true
 ```
 
 Store screenshots for analysis in `<project>/packages/spec/src/claude/chrome-devtools/screenshots/`.
 
 ## Console Log Collection & Analysis
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
-
 ### Capture Logs
 
 ```bash
@@ -407,7 +394,6 @@ node "$SKILL_DIR/console.js" --url https://example.com --types error --duration
 
 ## Finding Elements
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
 Use `snapshot.js` to discover selectors before interacting:
 
 ```bash
@@ -423,12 +409,11 @@ node "$SKILL_DIR/snapshot.js" --url https://example.com | jq '.elements[] | sele
 
 ## Error Recovery
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
 If script fails:
 
 ```bash
 # 1. Capture current state (without navigating to preserve state)
-node "$SKILL_DIR/screenshot.js" --output ./packages/spec/src/claude/skills/chrome-devtools/screenshots/debug.png
+node "$SKILL_DIR/screenshot.js" --output ./packages/spec/src/claude/chrome-devtools/screenshots/debug.png
 
 # 2. Get console errors
 node "$SKILL_DIR/console.js" --url about:blank --types error --duration 1000
@@ -469,22 +454,20 @@ node "$SKILL_DIR/performance.js" --url https://example.com | jq '.vitals'
 All scripts support:
 - `--headless true/false` - Override auto-detected headless mode (default: auto by OS)
 - `--close true` - Close browser completely (default: stay running)
-- `--timeout 30000` - Set timeout (ms)
-- `--wait-until networkidle2` - Wait strategy
+- `--wait-until networkidle2` - Wait strategy when the script loads `--url`
+- `--timeout <ms>` - read by the scripts that load a page or wait for one (`navigate.js`, `click.js`, `fill.js`, `connect-chrome.js`, `import-cookies.js`, `inject-auth.js`)
 
 `navigate.js` additionally supports:
 - `--wait-for-login <pattern>` - Interactive login: open headed, wait for URL regex match
 - `--login-timeout <ms>` - Max wait for login completion (default: 300000 = 5 min)
 
 ## Troubleshooting
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
-
 | Error | Solution |
 |-------|----------|
 | `Cannot find package 'puppeteer'` | Run `npm install` in scripts directory |
 | `libnss3.so` missing (Linux) | Run `./install-deps.sh` |
 | Element not found | Use `snapshot.js` to find correct selector |
-| Script hangs | Use `--timeout 60000` or `--wait-until load` |
+| Script hangs | Use `--wait-until load`, or `--timeout 60000` on a script that reads it |
 | Screenshot >5MB | Auto-compressed; use `--max-size 3` for lower |
 | Session stale | Delete `.browser-session.json` and retry |
 

package/src/claude/skills/code-review/SKILL.md

@@ -12,118 +12,50 @@ metadata:
 ---
 # Code Review — correctness and compliance owner
 
-Review evaluates correctness, security, scope, architecture, and specification
-compliance. It does not execute the test suite, create a canonical execution
-receipt, or turn a missing test result into a review-owned proof. `cf:test`
-owns execution proof; the single closeout owner combines both results.
+Review evaluates correctness, security, scope, architecture, and specification compliance. It does not execute the test suite, create a canonical execution receipt, or turn a missing test result into a review-owned proof. `cf:test` owns execution proof; the single closeout owner combines both results.
 
 ## Input and depth
 
-With no argument, review the pending diff. Supported targets are a PR, commit,
-pending changes, or an explicit path. Load only current target bytes and needed
-references. For a valid process-first target, read `plan.md`, the active flat
-`task-NN-*.md`, and the controller-validated `test-proof-v1` handoff. Mixed,
-orphaned, malformed, symlinked, nonregular, or identity-conflicting packet state
-is `BLOCKED`; review never migrates it.
+With no argument, review the pending diff. Supported targets are a PR, commit, pending changes, or an explicit path. Load only current target bytes and needed references. For a valid process-first target, read `plan.md`, the active flat `task-NN-*.md`, and the controller-validated `test-proof-v1` handoff. Orphaned, malformed, symlinked, nonregular, or identity-conflicting packet state is `BLOCKED`; review never migrates it.
 
-For process-first proof consumption, this skill's `## Execution-proof boundary`
-is authoritative. Do not load or follow legacy separate-receipt paragraphs from
-references; they apply only to a legacy packet.
+For proof consumption, this skill's `## Execution-proof boundary` is authoritative.
 
-Select review depth from `assurance_level`, risk, and blast radius. Lane is a
-derived view:
+Select review depth from risk and blast radius: for a process-first task, its coverage-profile Risk/evidence. Lane is a derived view:
 
 - Direct: targeted correctness/security/spec check;
 - Standard: bounded feature review at closeout;
 - Critical: independent, adversarial review covering every required obligation.
 
-Do not use file count as the depth selector. `execution_tier` is a read-only
-legacy adapter and cannot choose a review sequence. The review contract has no
-fixed Light/Standard/Deep sequence.
+Do not use file count as the depth selector. The review contract has no fixed Light/Standard/Deep sequence.
 
-## Review stages
+## Standards
 
-### 1. Specification compliance
+**Specification compliance.** For process-first work, compare the diff with current plan scope and the active task's Outcome, Scope, Coverage, Ownership, Acceptance, Dependencies, Verification Plan, and declared runtime reachability. Identify missing behavior, unjustified extras, contract substitution, orphaned outputs, and incorrect completion claims. If a design image or document carries requirements, load its multimodal reference only when needed; do not guess from a filename.
 
-For process-first work, compare the diff with current plan scope and the active
-task's Outcome, Scope, Coverage, Ownership, Acceptance, Dependencies,
-Verification Plan, and declared runtime reachability. Identify missing behavior,
-unjustified extras, contract substitution, orphaned outputs, and incorrect
-completion claims. If a design image or document carries requirements, load its
-multimodal reference only when needed; do not guess from a filename.
+**Correctness and security.** Trace changed entrypoints and callers. Check boundary validation, error paths, resource handling, race assumptions, secrets, authorization, persistence, and failure recovery in proportion to risk. Apply YAGNI/KISS/DRY as maintainability signals, not as a numeric score.
 
-### 2. Correctness and security
-
-Trace changed entrypoints and callers. Check boundary validation, error paths,
-resource handling, race assumptions, secrets, authorization, persistence, and
-failure recovery in proportion to risk. Apply YAGNI/KISS/DRY as maintainability
-signals, not as a numeric score.
-
-### 3. Adversarial checks
-
-Try empty, malformed, unauthorized, duplicate, stale, boundary, and concurrent
-inputs where the changed contract makes them relevant. For Critical obligations,
-review the required independent evidence and provenance. A marker such as
-`Audit: PASS` is not independent evidence.
-
-The independent-audit proof must be a durable object with exactly
-`schema_version: "1"`, distinct concrete `reviewer_session_id` and
-`implementation_session_id`, `expected_provenance: { base, head }` matching the
-runtime binding, concrete `evidence`, and literal `verdict: "PASS"`.
-`independent: true`, `PASS_WITH_WARNINGS`, missing binding, or reused session
-provenance is insufficient.
+**Adversarial checks.** Try empty, malformed, unauthorized, duplicate, stale, boundary, and concurrent inputs where the changed contract makes them relevant. For Critical obligations, review the required independent evidence and provenance. A marker such as `Audit: PASS` is not independent evidence.
 
 ## Test-run boundary
 
-Review reads code; it does not run tests. Never run the project's test suite or a
-test file, not even as a sanity check. A read-only run of the reviewed code (for
-example `node -e` on the changed function) may reproduce a defect; cite it as a
-reproduction, never as test evidence. Never report a test result, pass count, or
-exit code as the review's evidence. Without a `test-proof-v1` handoff, write the
-proof line exactly as `**Execution proof:** unavailable (owned by cf:test)` and do
-not otherwise say whether tests pass; the review still returns its correctness
-verdict.
+Review reads code; it does not run tests. Never run the project's test suite or a test file, not even as a sanity check. A read-only run of the reviewed code (for example `node -e` on the changed function) may reproduce a defect; cite it as a reproduction, never as test evidence. Never report a test result, pass count, or exit code as the review's evidence. Without a `test-proof-v1` handoff, write the proof line exactly as `**Execution proof:** unavailable (owned by cf:test)` and do not otherwise say whether tests pass; the review still returns its correctness verdict.
 
 ## Execution-proof boundary
 
-For process-first work, consume only the controller-validated `test-proof-v1`
-handoff. Require its exact closed schema, stable digest, current Base/Head,
-target task, exact command, exit/counts, raw output, reachability, proof level,
-artifacts, branches, and redactions. Unknown keys/verdicts, duplicate or missing
-branches, stale provenance, zero execution, required skips, unsafe redaction, or
-`PASS_WITH_WARNINGS` remain unfinished. Never create or search for a separate
-process-first receipt; Develop alone writes Status and inline `## Receipt` after
-proof and review are both literal `PASS`.
-
-Never rerun commands to manufacture proof. If execution proof is missing or
-invalid, write the proof line from the test-run boundary and leave closeout
-unfinished; do not claim feature PASS from review alone. A review may still return a correctness
-verdict when its review inputs are complete, but that verdict is not execution
-proof or GATE-DONE approval.
+For process-first work, consume only the controller-validated `test-proof-v1` handoff. Require its exact closed schema, stable digest, current Base/Head, target task, exact command, exit/counts, raw output, reachability, proof level, artifacts, branches, and redactions. Unknown keys/verdicts, duplicate or missing branches, stale provenance, zero execution, required skips, unsafe redaction, or `PASS_WITH_WARNINGS` remain unfinished. Never create or search for a separate process-first receipt; Develop alone writes Status and inline `## Receipt` after proof and review are both literal `PASS`.
+
+Never rerun commands to manufacture proof. If execution proof is missing or invalid, write the proof line from the test-run boundary and leave closeout unfinished; do not claim feature PASS from review alone. A review may still return a correctness verdict when its review inputs are complete, but that verdict is not execution proof or GATE-DONE approval.
 
 ## Severity
 
-Rate each finding by its production impact. Write the labels `Critical`, `High`,
-`Medium`, and `Low` verbatim in English, whatever language the report uses.
-
-- Critical: a concrete failure a user or operator hits that loses or corrupts
-  data, breaks security, or stops the product (a login bypass).
-- High: a concrete wrong result a user or operator hits (an order exactly at a
-  tier boundary priced with the wrong discount).
-- Medium: a real risk with a failure scenario that has not reached users (a
-  changed boundary with no test; a leftover debug log).
-- Low: cleanup, clarity, or a question (a naming nit; a behavior the change's
-  README or docs state as intended).
-
-A leftover debug log is at most Medium; if it prints a secret or credential,
-report that exposure as a separate security finding at its own severity. A
-behavior the change's README or docs state as intended is not a Medium or
-heavier defect; raise it as Low or a question. Task and spec compliance findings
-are Critical only when a task or spec is supplied, and there `UNVERIFIED` means
-supplied proof that failed, never proof that is unavailable. A blocking Medium is
-one with a concrete failure before merge. A review whose heaviest remaining
-finding is a non-blocking Medium returns `PASS_WITH_WARNINGS`; one with only Low
-findings returns `PASS`.
+Rate each finding by its production impact. Write the labels `Critical`, `High`, `Medium`, and `Low` verbatim in English, whatever language the report uses.
+
+- Critical: a concrete failure a user or operator hits that loses or corrupts data, breaks security, or stops the product (a login bypass).
+- High: a concrete wrong result a user or operator hits (an order exactly at a tier boundary priced with the wrong discount).
+- Medium: a real risk with a failure scenario that has not reached users (a changed boundary with no test; a leftover debug log).
+- Low: cleanup, clarity, or a question (a naming nit; a behavior the change's README or docs state as intended).
+
+A leftover debug log is at most Medium; if it prints a secret or credential, report that exposure as a separate security finding at its own severity. A behavior the change's README or docs state as intended is not a Medium or heavier defect; raise it as Low or a question. Task and spec compliance findings are Critical only when a task or spec is supplied, and there `UNVERIFIED` means supplied proof that failed, never proof that is unavailable. A blocking Medium is one with a concrete failure before merge. A review whose heaviest remaining finding is a non-blocking Medium returns `PASS_WITH_WARNINGS`; one with only Low findings returns `PASS`.
 
 ## Verdict
 
@@ -131,19 +63,9 @@ Use the shared adapter surface exactly:
 
 `PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED`
 
-Legacy adapter inputs may include `PASS | FAIL | BLOCKED`, but they are
-normalized to the shared surface and no second enum is allowed. `PASS` means no
-Critical, High, or Medium finding remains; Low findings may remain.
-`PASS_WITH_WARNINGS` means the heaviest remaining finding is a non-blocking
-Medium. `FAIL` means a Critical, High, or blocking Medium finding requires
-remediation. Finding count never selects depth or overrides missing execution
-proof. A review `PASS_WITH_WARNINGS` remains an unfinished
-closeout result; only literal `PASS` can finish a task. `BLOCKED` means the review input or a user-owned
-decision is unavailable.
+No second verdict enum is allowed. `PASS` means no Critical, High, or Medium finding remains; Low findings may remain. `PASS_WITH_WARNINGS` means the heaviest remaining finding is a non-blocking Medium. `FAIL` means a Critical, High, or blocking Medium finding requires remediation. Finding count never selects depth or overrides missing execution proof. A review `PASS_WITH_WARNINGS` remains an unfinished closeout result; only literal `PASS` can finish a task. `BLOCKED` means the review input or a user-owned decision is unavailable.
 
-Copy the header line `# Code Review Results [cf:code-review]`, the field labels,
-and the severity labels verbatim in English; write the content in the user's
-language.
+Copy the header line `# Code Review Results [cf:code-review]`, the field labels, and the severity labels verbatim in English; write the content in the user's language.
 
 ```markdown
 # Code Review Results [cf:code-review]
@@ -163,15 +85,10 @@ language.
 - Reachability/provenance review: PASS | WARN | FAIL
 ```
 
-Do not add a test command, a fabricated receipt, or an `Audit: PASS` marker to
-make the review look complete. Return unresolved questions at the end.
+Do not add a test command, a fabricated receipt, or an `Audit: PASS` marker to make the review look complete. Return unresolved questions at the end.
 
 ## References
 
-- `references/spec-compliance-review.md` — load only its detailed scope checks;
-  its separate-receipt paragraph is Legacy-only.
+- `references/spec-compliance-review.md` — load for its detailed scope checks.
 - `references/pre-landing-checklists.md` — load for the selected risk surface.
 - `references/adversarial-review.md` — load for Critical/adversarial depth.
-- `references/verification-gate.md` — Legacy separate-receipt consumption only;
-  process-first proof uses this skill's execution-proof boundary. Execution
-  always stays with `cf:test`.

package/src/claude/skills/code-review/references/spec-compliance-review.md

@@ -24,15 +24,12 @@ Do not attempt a standard text-based review if the project includes Visual Specs
    - requirement bullets
    - task `Outcome`, `Scope`, `Anchors and Ownership`, `Changes`, `Acceptance`,
      `Dependencies`, and `Verification Plan`
-   - typed `coordination.boundaries` as the only ownership/DAG/proof/parallel authority
-   - task `Verification Plan`
-   - canonical contracts/invariants from `design.md`
+   - the plan's acceptance criteria and coverage profile rows the task references
    Then verify the changed files against those concrete obligations.
 
-Execution proof is separate from the task plan. Consume
-`receipts/<task-basename>.md` first and legacy `## Evidence` only as fallback;
-conflicting proof identities fail closed. Review never creates a receipt and
-never treats a receipt as approval, readiness, audit status, or semantic judgment.
+Execution proof is separate from the task plan and lives only in the task's
+inline `## Receipt`. Review never creates a receipt and never treats a receipt as
+approval, readiness, audit status, or semantic judgment.
 
 ## 3. Verdict Scale