@haposoft/cafekit 0.15.1 → 0.16.0-rc.1

package/src/claude/skills/develop/references/quality-gate.md

@@ -10,6 +10,28 @@ Green tests are NOT enough. The gate requires four proofs:
 
 `--flash` is the explicit fast path. It bypasses this full gate and uses the Flash Gate defined below.
 
+Executable policy source: `src/claude/scripts/workflow-policy.cjs` (installed as `.claude/scripts/workflow-policy.cjs`). Use its tier delegation, verdict consumer, flash conflict, and promotion semantics; do not duplicate policy in prose or tests.
+
+## Tier input (from develop Delegation policy)
+
+Quality-gate input MUST include `execution_tier` and `ship_point`:
+
+- **Light:** main session runs verification commands and the same spec-compliance checklist. Spawn zero `test-runner` or `code-auditor` subagents.
+- **Standard:** main session runs tests and spec checks. At the ship point, run exactly one combined `code-auditor` review for spec compliance plus code quality.
+- **Deep / `--parallel`:** retain the documented per-worktree Stage A+B chain in Track A. Do not treat that chain as a permanent product contract.
+
+Checklist and FAIL conditions stay identical for every tier; tier changes only who executes each check and when.
+
+## Spec compliance review
+
+Stage A applies same spec compliance review checklist for every tier: scope, requirements, completion criteria, evidence, and runtime reachability. A missing or unreachable deliverable is a FAIL.
+
+
+- **Specific-task mode:** requested task is ship point. Review that task packet and its diff exactly once.
+- **Full-spec Standard:** intermediate tasks receive only the main-session gate. After the final task and Final Integration Scout, run one combined auditor over the cumulative feature diff, all acceptance criteria, and runtime reachability.
+- Do not set feature-level `code_done` or completion before combined auditor returns `PASS`.
+- Auditor `FAIL` maps each finding to its owning task/surface. Fix only affected evidence, then rerun affected checks and the combined review; do not replay unrelated gates already passed.
+
 ## Automation Semantics
 
 - If the task names exact commands in `## Evidence` (legacy heading aliases still parse), those exact commands are mandatory and must run before any fallback repo defaults.
@@ -38,6 +60,8 @@ Use this only when `/hapo:develop ... --flash` is present.
   - `Mode: --flash`
   - `Tests: skipped by user request`
   - `Evidence: FLASH_UNVERIFIED`
+  - `Status: in_progress`
+  - `Blocker: awaiting /hapo:test <feature>`
   - `Next verification: /hapo:test <feature>`
 
 Terminal log:
@@ -65,46 +89,42 @@ START_LOOP:
   ---------------------------------------------------------------
   STAGE A: Test + SPEC COMPLIANCE review
   ---------------------------------------------------------------
-  → Agent(subagent_type="test-runner",
-        prompt="Run task-aware verification for the recently implemented code. Read the active task file(s) and execute the exact verification commands named there first, in order. Preflight compile/typecheck/build failures must be reported as PRECHECK_FAIL and take precedence over NO_TESTS. After that, run any additional repo-level typecheck/test/build checks needed for confidence. Inspect named artifacts/runtime outputs and prove runtime reachability from declared entrypoints/callers. For multi-service tasks, verify the flow does not rely on process-local stand-ins masquerading as shared state. Return PASS only if automated checks and task evidence both pass. Mark anything unexecuted as UNVERIFIED. Treat NO_TESTS as non-passing unless the task did not require a dedicated test suite.",
-        description="Test [feature]")
-
-  → Agent(subagent_type="code-auditor",
-        prompt="SPEC COMPLIANCE REVIEW ONLY. Do not trust the implementer's report. Read the active task file(s), scope_lock, referenced requirements, design contracts, task-aware scout report, and actual code. Verify line by line that every scoped requirement and completion criterion is implemented, nothing out-of-scope was added, and every runtime-facing artifact is reachable from the declared entrypoint/caller or explicitly deferred to a named later task. Missing deliverables, placeholder-only wiring, orphan components/services, unmounted UI, unregistered routes, uncalled loaders, missing runtime entrypoints, overscope edits outside the task packet, silent replacement of named technologies/contracts, or fake cross-service proof via process-local state are Critical even if build/tests pass. Return SPEC_PASS or SPEC_FAIL, critical count, file:line findings, and evidence gaps.",
-        description="Spec review [feature]")
-
-  Wait for BOTH to return results.
-
-  CASE 1 — PRECHECK_FAIL OR Automated FAIL OR required command missing OR Evidence FAIL / UNVERIFIED OR Reachability FAIL / SPEC_FAIL OR NO_TESTS when tests were required:
-    - Increment retry_count++
-    - If retry_count >= 3:
-        → COLLAPSE! AskUserQuestion: "Quality gate cannot prove this task is complete! User intervention required!"
-    - If retry_count < 3:
-        → Return to Step 3 (god-developer). Fix the failing checks, spec gaps, or missing evidence first.
-        → GOTO START_LOOP
-
-  CASE 2 — Test PASS + Evidence PASS + SPEC_PASS:
-    → Proceed to STAGE B code quality review.
+  → Light: main session executes exact Evidence commands, spec checklist,
+    artifact checks, and reachability checks; spawn 0 subagents.
+  → Standard: main session executes exact Evidence commands and spec checklist;
+    defer one combined auditor to the ship point.
+  → Deep / --parallel: run the documented per-task sequence `inspector → implementer → test-runner → code-auditor` in the
+    task worktree, then preserve its documented merge/integration gates.
+
+  Test result and review result use the review enum only: PASS | FAIL | BLOCKED.
+  PASS proceeds. FAIL returns actionable findings to implementer. BLOCKED means
+  execution proof, permissions, environment, or a user-owned decision is missing:
+  stop immediately and do not blind-retry.
+
+  Standard specific-task ship point:
+    → run exactly one combined code-auditor review after Stage A PASS.
+  Standard full-spec ship point:
+    → run exactly one combined code-auditor review after the final task and
+      Final Integration Scout over the cumulative feature diff.
+
+  CASE 1 — PRECHECK_FAIL OR Automated FAIL OR required command missing OR Evidence FAIL / UNVERIFIED OR Reachability FAIL:
+    - For FAIL: increment retry_count; return to implementation while retry_count < 3.
+    - For BLOCKED: stop without retry; record blocker and await resolution.
+    - If retry_count >= 3: COLLAPSE and ask for user intervention.
+
+  CASE 2 — Test PASS + Evidence PASS + spec checklist PASS:
+    → Proceed to the ship-point review for Standard, or the Deep Stage B review.
 
 STAGE B:
   ---------------------------------------------------------------
   CODE QUALITY REVIEW (only after spec compliance passes)
   ---------------------------------------------------------------
-  → Agent(subagent_type="code-auditor",
-        prompt="CODE QUALITY REVIEW. Spec compliance already passed. Review recently written code for security, logic correctness, architecture, YAGNI/KISS/DRY, maintainability, tests, and project conventions. Also re-check that no recent edits broke dependents found by the task-aware scout report. Return score (X/10), critical count, warning list, and concrete file:line findings.",
-        description="Quality review [feature]")
-
-  CASE 3 — Code quality review FAIL (Score < 9.5 OR Critical > 0):
-    - Increment retry_count++
-    - If retry_count >= 3:
-        → COLLAPSE! AskUserQuestion: "Code does not meet minimum standards! User intervention required!"
-    - If retry_count < 3:
-        → Fix each review issue.
-        → GOTO START_LOOP unless the fix is prose-only and cannot affect evidence; otherwise re-run Stage B.
-
-  CASE 4 — Test PASS + Evidence PASS + SPEC_PASS + Code quality review PASS (Score >= 9.5 AND Critical = 0):
-    → PASS! Auto-approved.
-    → PROCEED to completion report with a verification receipt summarizing exact commands executed, artifact/runtime/reachability proof, spec review result, and code quality review result.
+  Standard uses the combined auditor described above; Deep retains the existing
+  Stage B quality review chain inside each worktree.
+  → PASS = no Critical, no High, at most one Medium; proceed to sync.
+  → FAIL = findings mapped to task/surface; fix affected scope and rerun only
+    affected evidence plus this combined review.
+  → BLOCKED = missing proof/permission/environment/user decision; stop, no blind retry.
 ```
 
 ## Critical Issue Definitions
@@ -124,10 +144,10 @@ STAGE B:
 
 Must log the Quality Gate result to the terminal for user visibility:
 
-- **Quick Pass:** `✓ Step 4 Quality Gate: Test PASS + Evidence PASS + Spec PASS + Review 9.5/10 - Auto-Approved`
-- **Hard-Won Pass:** `✓ Step 4 Quality Gate: Failed 2 rounds → Test PASS + Evidence PASS + Spec PASS + Review 9.6/10`
+- **Quick Pass:** `✓ Step 4 Quality Gate: Test PASS + Evidence PASS + Spec PASS + Review PASS (no Critical, no High, at most one Medium) - Auto-Approved`
+- **Hard-Won Pass:** `✓ Step 4 Quality Gate: Failed 2 rounds → Test PASS + Evidence PASS + Spec PASS + Review PASS (no Critical, no High, at most one Medium)`
 - **Preflight Fail:** `[x] Step 4 Quality Gate: PRECHECK_FAIL → compile/typecheck/build failed before tests mattered`
-- **Fix Needed:** `[~] Step 4 Quality Gate: Tests/spec/evidence failed → returned to god-developer`
+- **Fix Needed:** `[~] Step 4 Quality Gate: Tests/spec/evidence failed → returned to implementer`
 - **Awaiting Rescue:** `[!] Step 4 Quality Gate: Failed 3 rounds! Awaiting user intervention...`
 
 ## Working directory (parallel mode)

package/src/claude/skills/develop/references/subagent-patterns.md

@@ -15,7 +15,7 @@ Agent(subagent_type="inspector", prompt="Scan and identify all files related to
 
 ## Code Implementation Phase
 ```
-Agent(subagent_type="god-developer", prompt="Implement the sub-tasks from [tasks-directory] based on the specification in [spec.json]", description="Code Feature [feature]")
+Agent(subagent_type="implementer", prompt="Implement the sub-tasks from [tasks-directory] based on the specification in [spec.json]", description="Code Feature [feature]")
 ```
 
 ## UI Implementation Phase
@@ -25,7 +25,7 @@ Agent(subagent_type="ui-ux-designer", prompt="Implement the frontend code for [f
 
 ## Code Review Phase
 ```
-Agent(subagent_type="code-auditor", prompt="Review all recently written code. Check for security holes, performance issues, and adherence to YAGNI/KISS/DRY. Return score (X/10), list of critical issues, warnings, and suggestions.", description="Review [phase]")
+Agent(subagent_type="code-auditor", prompt="Review all recently written code. Check for security holes, performance issues, and adherence to YAGNI/KISS/DRY. Return a verdict (PASS = no Critical, no High, at most one Medium), severity-classified findings, and concrete suggestions.", description="Review [phase]")
 ```
 
 ## Test Execution Phase

package/src/claude/skills/git/SKILL.md

@@ -8,59 +8,53 @@ keywords: [git, commits, pr, worktree]
 argument-hint: "commit | push | pr | finish | worktree <feature-desc>"
 metadata:
   author: haposoft
-  version: "1.0.0"
+  version: "1.1.0"
 ---
 # Git Operations & Worktree
 
-This skill merges Version Control Systems (VSC) capabilities and parallel Worktree management into a single, clean-room execution engine utilizing pure Bash commands rather than proprietary Node scripts.
+Git operations and worktree management using plain `git` commands.
 
-**Mantra:** Secure, Conventional, and Isolated.
+## Default (no arguments)
+Present options via AskUserQuestion — header "Git Operation": commit / push / pr / finish / worktree.
 
 ## Commands
-
-### 1. Version Control Engine
-- **`commit`**: Scan secrets, analyze diff, auto-split chunks into conventional commits.
-- **`push`**: Securely push to the current branch.
-- **`pr`**: Propose merging current feature into `develop` or `main`.
-- **`finish`**: Verify current branch/worktree, then present explicit finish options.
-
-### 2. Worktree Engine (Safe Parallel Development)
-- **`worktree <feature-description>`**: Creates a sibling directory alongside the current repo to isolate dependencies and database contexts without dirtying the main worktree.
-
-## Core Directives 
-
-### 1. Native Bash Execution Only
-- DO NOT rely on external JS/CJS scripts to evaluate git. Use pure system `git` CLI logic in bash.
-- Always check the status first: `git status && git diff --cached --stat`
-
-### 2. Pre-Commit Security Audit
-- Always run secret detection before creating a commit:
-  ```bash
-  git diff --cached | grep -iE "(api[_-]?key|token|password|secret|credential)"
-  ```
-- If a secret is matched: **HALT!** Refuse to commit. Demand the user add the file to `.gitignore` and run `git rm --cached <file>`.
-
-### 3. Smart Worktree Strategy
-- Never run branching logic within the same root if the task requires heavy, isolated setup.
-- Worktrees MUST be created as *sibling directories*: `../<project-name>-<feature-branch>`.
-
-### 4. Finish Branch Protocol
-- Before merge, push, PR, or discard, run a fresh status and verification check:
-  ```bash
-  git status --short
-  git branch --show-current
-  ```
-- If uncommitted changes exist, route through `commit` or ask whether to keep them unstaged.
-- Present explicit finish options:
-  1. Merge locally into the target branch.
-  2. Push current branch and open/update a PR.
-  3. Keep the branch/worktree for later.
-  4. Discard branch/worktree only after typed confirmation.
-- Never force-push or delete worktrees without explicit user confirmation.
-- If running inside a git worktree, detect it with `git worktree list` and clean up only the worktree created for this task.
-
-## References & Protocols
-
-- `references/commit-protocols.md`: Strict rules for analyzing Git Diffs and determining commit splitting behavior.
-- `references/finish-branch.md`: Finish branch / PR / worktree closeout protocol.
-- `references/worktree-blueprint.md`: The 4-step Bash process to accurately construct an out-of-bounds Git Worktree Environment.
+- `commit`: run installed secret scanner → analyze diff → split into conventional commits.
+- `push`: push current branch.
+- `pr`: push + open PR. Target = repo's integration branch — detect via
+  `gh repo view --json defaultBranchRef` or `origin/HEAD`; never assume `main`/`develop`.
+- `finish`: fresh `git status` + verification, then present exactly 4 options:
+  merge locally / push + PR / keep branch-worktree / discard (typed confirmation).
+- `worktree <desc>`: sibling dir `../<project>-<branch>` for isolated setup.
+
+## Secret scan (before every commit)
+```bash
+node .claude/scripts/scan-staged-secrets.cjs
+```
+The helper parses `git diff --cached --unified=0 --no-color --diff-filter=ACMR`, checks added lines only, maps hunks to source lines, and prints only file, line, and identifier. It never prints secret values or context.
+
+Match → STOP. For an untracked secret, add an appropriate `.gitignore` rule. For a tracked secret, stop, rotate it, and ask the user before changing history or index state.
+
+## Split rules
+Split when: mixed types (feat+fix), mixed scopes, config/deps mixed with code, >10 unrelated files.
+Single commit when: same type+scope, ≤3 files, ≤50 lines.
+
+## Output
+```
+✓ staged: N files (+X/-Y)
+✓ secrets: none
+✓ commit: <hash> type(scope): description
+✓ pushed: yes|no
+```
+
+## Errors
+| Error | Action |
+|---|---|
+| Secrets matched | Block; report only file/source line/identifier. Never show secret value, diff line, or surrounding context. |
+| Nothing staged | Exit cleanly |
+| Push rejected | Suggest `git pull --rebase` |
+| Conflicts | List files; never auto-resolve |
+
+Never force-push or delete a worktree without explicit confirmation.
+
+## References
+- `references/commit-protocols.md` · `references/finish-branch.md` · `references/worktree-blueprint.md`

package/src/claude/skills/hotfix/SKILL.md

@@ -17,7 +17,7 @@ Kill bugs systematically. No guessing. Evidence first, fix second.
 ## Arguments
 
 - `--quick` - Reduced-depth path for trivial issues (lint, type errors, syntax); still scout-first
-- `--parallel` - Spawn multiple `god-developer` agents for independent issues
+- `--parallel` - Spawn multiple `implementer` agents for independent issues
 - `--from-debug` - Start from an existing `hapo:debug` report and validate its root-cause contract
 
 Default: deterministic scout-first hotfix. There is no initial mode selection step.
@@ -26,6 +26,8 @@ Default: deterministic scout-first hotfix. There is no initial mode selection st
 Do NOT propose or implement fixes before completing Steps 1-2 (Scout + `hapo:debug` diagnosis).
 Symptom fixes are FAILURE. Find the root cause first.
 The exact root-cause contract is mandatory: symptom, reproduction, expected/actual, root cause file:line or config/env source, why now, evidence chain, blast radius.
+Answer each item in one concrete sentence.
+If any answer contains 'probably', 'I think', 'something with', or 'maybe' — it is not an answer; gather evidence instead.
 The side-effect gate is mandatory before completion.
 If 3+ fix attempts fail → STOP. Question the architecture. Discuss with user.
 Exception: `--quick` mode only abbreviates depth; it never skips scout, pre-fix evidence, diagnosis, or before/after verification.
@@ -51,10 +53,10 @@ The fix is not done until Step 5 proves:
 5. Public contracts are unchanged unless intentionally called out: function signatures, exported types, response shapes, DB schemas, env vars.
 
 If verification reveals a side effect or regression, STOP and present 2-4 concrete options to the user:
-- Revert this fix and try a different root-cause angle.
-- Narrow the fix scope to remove the regression.
-- Keep the fix and update named dependent files/contracts.
-- Accept the behavior change intentionally.
+- Revert this fix and try a different root-cause angle
+- Keep the fix and update <dependent files> to match the new contract
+- Narrow the fix to <subset> so the regression disappears
+- Accept the change — the old behavior was itself a bug
 Do not silently patch around the regression.
 </HARD-GATE-NO-SIDE-EFFECTS>
 
@@ -166,7 +168,7 @@ If any field is vague (`probably`, `maybe`, `I think`, or missing file:line/conf
 | **Trivial** | Single file, clear error, type/lint/syntax | Quick: straight to fix |
 | **Standard** | Multi-file, root cause identified via diagnosis | Standard: fix + regression test |
 | **Complex** | System-wide, architecture impact, unclear boundaries | Deep: research + plan + fix |
-| **Parallel** | 2+ independent issues OR `--parallel` flag | Spawn `god-developer` agents per issue |
+| **Parallel** | 2+ independent issues OR `--parallel` flag | Spawn `implementer` agents per issue |
 
 **Task Orchestration (Standard+ only):**
 - Use `TaskCreate` with dependencies to track fix phases
@@ -203,7 +205,7 @@ If any field is vague (`probably`, `maybe`, `I think`, or missing file:line/conf
 
 ### Parallel Workflow
 1. Create separate `TaskCreate` per independent issue
-2. Spawn `god-developer` subagents — one per issue
+2. Spawn `implementer` subagents — one per issue
 3. Each agent follows Steps 1-5 independently
 4. Aggregate results upon completion
 
@@ -274,7 +276,7 @@ Unified step markers (emit after each step):
 | `hapo:code-review` | After fix, quality check (Step 5) |
 | `git-ops` | Commit changes (Step 6) |
 | `docs-keeper` | Update docs if behavior changed (Step 6) |
-| `god-developer` | Parallel independent issues (each gets own agent) |
+| `implementer` | Parallel independent issues (each gets own agent) |
 
 ## Specialized Paths
 

package/src/claude/skills/hotfix/references/parallel-patterns.md

@@ -9,7 +9,7 @@ How to effectively leverage multiple subagents (the `Agent` tool) and native tas
 | Searching for root cause across 3+ directories | Parallel scout | `Explore` × 2-3 |
 | Testing 2-3 diagnostic hypotheses simultaneously | Parallel hypothesis test | `Explore` × 2-3 |
 | Verifying fix (typecheck + lint + build + test) | Parallel verification | `Bash` × 3-4 |
-| Fixing 2+ independent bugs in one session | Parallel issue trees | `god-developer` × N |
+| Fixing 2+ independent bugs in one session | Parallel issue trees | `implementer` × N |
 | Deep workflow: scout + diagnose + research together | Parallel investigation | Mixed |
 
 ## Pattern A: Parallel Scouting
@@ -71,7 +71,7 @@ B4 = TaskCreate(subject="[Auth] Verify + test",             addBlockedBy=[B3])
 TaskCreate(subject="Integration verification",              addBlockedBy=[A4, B4])
 ```
 
-Spawn one `god-developer` agent per issue tree. Each agent claims tasks via `TaskUpdate(status="in_progress")` and completes via `TaskUpdate(status="completed")`.
+Spawn one `implementer` agent per issue tree. Each agent claims tasks via `TaskUpdate(status="in_progress")` and completes via `TaskUpdate(status="completed")`.
 
 ## Pattern E: Deep Workflow — Parallel Investigation Phase
 

package/src/claude/skills/hotfix/references/review-cycle.md

@@ -4,53 +4,58 @@ How to handle code review results after a fix is implemented. Ensures quality wi
 
 ## Default Review Handling
 
-The agent reviews its own fix using `hapo:code-review` and decides automatically:
+The agent reviews its own fix using `hapo:code-review` and decides automatically. Every review returns exactly one verdict: `PASS | FAIL | BLOCKED`.
 
 ```
 attempt = 0
 LOOP:
-  1. Trigger hapo:code-review → receives: score, critical_issues[], warnings[]
+  1. Trigger hapo:code-review → receives: verdict and severity-classified findings
 
   2. Evaluate:
-     IF score >= 9.0 AND len(critical_issues) == 0:
-       → ACCEPT. Log: "✓ Review [score]/10 — auto-approved"
+     IF verdict == PASS (no Critical, no High, at most one Medium):
+       → ACCEPT. Log: "✓ Review PASS — auto-approved"
        → Proceed to Step 6 (Finalize)
 
-     ELSE IF len(critical_issues) > 0 AND attempt < 3:
-       → AUTO-REMEDIATE critical issues only
+     ELSE IF verdict == BLOCKED:
+       → TERMINAL STOP. Do not blind-retry.
+       → Present the blocker and required execution proof, permission, environment,
+         or user-owned decision to the user.
+
+     ELSE IF verdict == FAIL AND attempt < 3:
+       → AUTO-REMEDIATE the reported findings
        → Re-run verification (typecheck + lint + test)
        → attempt += 1
        → GOTO LOOP
 
-     ELSE IF attempt >= 3:
+     ELSE IF verdict == FAIL AND attempt >= 3:
        → HALT. Present findings to user:
-         "3 auto-fix cycles exhausted. [N] critical issues remain."
+         "3 auto-fix cycles exhausted. [N] blocking findings remain."
          Options: "Fix manually" | "Approve with known issues" | "Abort"
-
-     ELSE (score < 9.0, zero critical):
-       → ACCEPT with advisory. Log: "✓ Review [score]/10 — approved, [N] warnings noted"
-       → Proceed to Step 6
 ```
 
+`BLOCKED` is terminal for this review cycle. Only `FAIL` may enter remediation retry; never retry a blocked review unchanged.
+
 ## Required User Pause
 
 When the fix touches production-critical code, changes public contracts, introduces a behavior change, or the user explicitly requests review control:
 
-1. Run `hapo:code-review` → collect score + findings
+1. Run `hapo:code-review` → collect verdict + severity findings
 2. Present a structured summary to user:
    ```
    ┌──────────────────────────────────┐
-   │ Review Score: [X]/10             │
+   │ Review Verdict: [PASS | FAIL | BLOCKED] │
    ├──────────────────────────────────┤
-   │ Critical: [list or "none"]      │
-   │ Warnings: [list or "none"]      │
-   │ Suggestions: [list or "none"]   │
+   │ Critical: [list or "none"]       │
+   │ High: [list or "none"]           │
+   │ Medium: [list or "none"]         │
+   │ Low: [list or "none"]            │
    └──────────────────────────────────┘
    ```
 3. Ask user for direction:
-   - If critical issues exist → "Fix critical" | "Fix all" | "Approve anyway" | "Abort"
-   - If no critical issues → "Approve" | "Address warnings" | "Abort"
-4. Execute user's choice. Max 3 remediation cycles.
+   - If verdict is `BLOCKED` → resolve the blocker; do not retry this review cycle unchanged.
+   - If verdict is `FAIL` with Critical or High findings → "Fix blocking findings" | "Fix all" | "Approve anyway" | "Abort"
+   - If verdict is `FAIL` with only Medium/Low findings → "Approve" | "Address findings" | "Abort"
+4. Execute user's choice. Max 3 remediation cycles for `FAIL`; `BLOCKED` never enters this retry limit.
 
 ## When To Pause vs Continue
 
@@ -64,7 +69,7 @@ When the fix touches production-critical code, changes public contracts, introdu
 
 ## Blocking Issues (Never Auto-Approve)
 
-Regardless of score, always flag and pause for these:
+Regardless of verdict, always flag and pause for these:
 - Injection vulnerabilities (SQL, XSS, command injection)
 - Authentication/authorization bypasses
 - Unbounded resource consumption (∞ loops, uncontrolled allocations)

package/src/claude/skills/inspect/SKILL.md

@@ -1,14 +1,14 @@
 ---
 name: hapo:inspect
-description: "Fast codebase discovery using parallel agents. Use for file discovery, task context gathering, quick searches across directories. Supports internal (Explore) and external (Gemini) agents."
+description: "Fast codebase discovery using parallel agents. Use for file discovery, task context gathering, quick searches across directories. Supports internal Explore agents."
 user-invocable: true
 when_to_use: "Invoke for fast parallel codebase discovery and file location."
 category: discovery
 keywords: [discovery, search, explore, context]
-argument-hint: "[search-target] [ext]"
+argument-hint: "[search-target]"
 metadata:
   author: haposoft
-  version: "2.0.0"
+  version: "2.1.0"
 ---
 # Inspect
 
@@ -16,7 +16,6 @@ Fast, token-efficient codebase discovery using parallel agents to find files nee
 
 ## Arguments
 - Default: Inspect using built-in Explore subagents in parallel (`./references/internal-inspection.md`)
-- `ext`: Inspect using external Gemini CLI tool in parallel (`./references/external-gemini-inspection.md`)
 
 ## When to Use
 
@@ -24,9 +23,9 @@ Fast, token-efficient codebase discovery using parallel agents to find files nee
 - Debugging that needs file relationships; project structure questions
 - Before multi-area changes, review, debug, or impact analysis
 
-## Preflight Scope Gate (MANDATORY - All Modes)
+## Preflight Scope Gate (MANDATORY)
 
-Before scanning with ANY mode (internal or external):
+Before scanning:
 1. Detect repo-root or root-wide scans such as `.`, `/`, `./`, `**/*`, `**/*.ts`, or similar broad patterns without a scoped directory.
 2. Apply the built-in no-scan lists below.
 3. Prefer file-type or glob hints whenever possible.
@@ -38,14 +37,14 @@ Before scanning with ANY mode (internal or external):
 Spawn **one scout** to map top-level layout before dividing work:
 1. List immediate children of the scope root (dirs + key config; monorepo markers)
 2. Rough file count per discovered directory
-3. Return a division plan of 1–6 logical sub-scopes (path/glob, est. files, focus)
+3. Return a division plan of 1–10 logical sub-scopes (path/glob, est. files, focus)
 
 Wait for Scout before Phase 2.
 
 ### Phase 2 — Parallel Explore Agents (Based on Scout Results)
 
 1. Follow Scout's plan; merge scopes < 10 files; split scopes > 100 files
-2. Spawn parallel Explore agents (SCALE 3–6 recommended), one per sub-scope
+2. Spawn parallel Explore agents, one per sub-scope
 3. Aggregate into the Inspect Report; offer deeper follow-up on specific areas
 
 **Fallback to AskUserQuestion:** if Scout is ambiguous (flat layout, < 3 areas), offer 2–4 concrete scopes from findings, then re-invoke with the chosen scope.
@@ -60,19 +59,6 @@ Wait for Scout before Phase 2.
 - private keys, token dumps, credential exports, `.env` secrets
 - generated bundles, binary blobs
 
-## Configuration
-
-Read from `.claude/runtime.json`:
-```json
-{
-  "gemini": {
-    "model": "gemma-4-31b-it"
-  }
-}
-```
-
-Default model: `gemma-4-31b-it` (installed with `npx @haposoft/cafekit`).
-
 ## Workflow
 
 ### 1. Analyze Task
@@ -86,7 +72,7 @@ SCALE = ceil(estimated_files_to_scan / 50)
 
 - Min SCALE = 1; Max SCALE = 10
 - SCALE 1-2: focused (< 100 files)
-- SCALE 3-5: medium (suitable for external Gemini CLI)
+- SCALE 3-5: medium
 - SCALE 6-10: large (internal Explore agents)
 
 ### 2. Divide and Conquer
@@ -101,16 +87,13 @@ SCALE = ceil(estimated_files_to_scan / 50)
 
 | Condition | Mode |
 |---|---|
-| No `ext` argument | Internal Explore agents |
-| `ext` + SCALE ≤ 5 | Gemini CLI (if available + scope gate passed) |
-| `ext` + SCALE ≥ 6 | Internal Explore agents |
-| Gemini unavailable/fails | Fallback to internal Explore |
+| Always | Internal Explore agents |
 
-Load: **Internal** `./references/internal-inspection.md` or **External** `./references/external-gemini-inspection.md`.
+Load: **Internal** `./references/internal-inspection.md`.
 
 ### 5. Spawn Parallel Agents
 
-**Internal mode:** dispatch native Explore agents with breadth medium/very-thorough + the Scope Gate above. Details: `./references/internal-inspection.md`.
+Dispatch native Explore agents with breadth medium/very-thorough + the Scope Gate above. Details: `./references/internal-inspection.md`.
 
 - `TaskUpdate` each task to `in_progress` before spawn
 - Prompt each subagent with exact directories/files; each has < 200K context
@@ -147,5 +130,4 @@ Load: **Internal** `./references/internal-inspection.md` or **External** `./refe
 
 ## References
 
-- `./references/internal-inspection.md` - Using Explore subagents
-- `./references/external-gemini-inspection.md` - Using Gemini CLI
+- `./references/internal-inspection.md` - Using Explore subagents

package/src/claude/skills/mobile-development/SKILL.md

@@ -31,8 +31,8 @@ Production-ready mobile development with modern frameworks, best practices, and
 ## Technology Selection Guide
 
 **Cross-Platform Frameworks:**
-- **React Native**: JavaScript expertise, web code sharing, mature ecosystem (121K stars, 67% familiarity)
-- **Flutter**: Performance-critical apps, complex animations, fastest-growing (170K stars, 46% adoption)
+- **React Native**: JavaScript expertise, web code sharing, mature ecosystem
+- **Flutter**: Performance-critical apps, complex animations, fastest-growing
 
 **Native Development:**
 - **iOS (Swift/SwiftUI)**: Maximum iOS performance, latest features, Apple ecosystem integration
@@ -44,7 +44,7 @@ See: `references/mobile-frameworks.md` for detailed framework comparisons
 
 **The 10 Commandments of Mobile Development:**
 
-1. **Performance is Foundation, Not Feature** - 70% abandon apps >3s load time
+1. **Performance is Foundation, Not Feature** - Slow load times can drive users away
 2. **Every Kilobyte, Every Millisecond Matters** - Mobile constraints are real
 3. **Offline-First by Default** - Network is unreliable, design for it
 4. **User Context > Developer Environment** - Think real-world usage scenarios
@@ -72,7 +72,7 @@ See: `references/mobile-mindset.md` for thinking patterns and decision framework
 ## Key Best Practices (2024-2025)
 
 **Performance Targets:**
-- App launch: <2 seconds (70% abandon if >3s)
+- App launch: <2 seconds; slow launches risk abandonment
 - Memory usage: <100MB for typical screens
 - Network requests: Batch and cache aggressively
 - Battery impact: Respect Doze Mode and background restrictions
@@ -92,7 +92,7 @@ See: `references/mobile-mindset.md` for thinking patterns and decision framework
 - Implement proper session management
 
 **Testing Strategy:**
-- Unit tests: 70%+ coverage for business logic
+- Unit tests: meaningful coverage for business logic
 - Integration tests: Critical user flows
 - E2E tests: Detox (React Native), Appium (cross-platform), XCUITest (iOS), Espresso (Android)
 - Real device testing mandatory before release
@@ -101,7 +101,7 @@ See: `references/mobile-mindset.md` for thinking patterns and decision framework
 - Fastlane for automation across platforms
 - Staged rollouts: Internal → Closed → Open → Production
 - Mandatory: iOS 17 SDK (2024), Android 15 API 35 (Aug 2025)
-- CI/CD saves 20% development time
+- CI/CD saves development time
 
 ## Quick Decision Matrix
 
@@ -121,9 +121,9 @@ See: `references/mobile-mindset.md` for thinking patterns and decision framework
 
 | Criterion | React Native | Flutter | Swift/SwiftUI | Kotlin/Compose |
 |-----------|--------------|---------|---------------|----------------|
-| **Stars** | 121K | 170K | N/A | N/A |
-| **Adoption** | 35% | 46% | iOS only | Android only |
-| **Performance** | 80-90% native | 85-95% native | 100% native | 100% native |
+| **Community footprint** | Large | Large | Apple ecosystem | Android ecosystem |
+| **Adoption** | Established | Established | iOS only | Android only |
+| **Performance** | Near-native when profiled | Near-native when profiled | Native baseline | Native baseline |
 | **Dev Speed** | Fast (hot reload) | Very fast (hot reload) | Fast (Xcode Previews) | Fast (Live Edit) |
 | **Learning Curve** | Easy (JavaScript) | Medium (Dart) | Medium (Swift) | Medium (Kotlin) |
 | **UI Paradigm** | Component-based | Widget-based | Declarative | Declarative |
@@ -148,7 +148,7 @@ See: `references/mobile-mindset.md` for thinking patterns and decision framework
 - Image optimization → Lazy loading → Memory profiling → Network optimization → Battery testing → Launch time optimization
 
 **Quality:**
-- Unit tests (70%+) → Integration tests → E2E tests → Accessibility testing → Performance testing → Security audit
+- Unit tests → Integration tests → E2E tests → Accessibility testing → Performance testing → Security audit
 
 **Security:**
 - Secure storage → Authentication flow → Network security → Input validation → Session management → Encryption
@@ -179,7 +179,7 @@ See: `references/mobile-mindset.md` for thinking patterns and decision framework
 3. **No offline handling** - Network failures will happen
 4. **Poor memory management** - Leads to crashes and poor UX
 5. **Hardcoded credentials** - Security vulnerability
-6. **No accessibility** - Excludes 15%+ of users
+6. **No accessibility** - Can exclude users
 7. **Premature optimization** - Optimize based on metrics, not assumptions
 8. **Over-engineering** - Start simple, scale as needed
 9. **Skipping real device testing** - Simulators don't show battery/network issues
@@ -193,7 +193,7 @@ See: `references/mobile-mindset.md` for thinking patterns and decision framework
 - **Screen load**: <1 second for cached data
 - **Network request**: <3 seconds for API calls
 - **Memory**: <100MB for typical screens, <200MB peak
-- **Battery**: <5% drain per hour of active use
+- **Battery**: Minimize drain during active use
 - **Frame rate**: 60 FPS (16.67ms per frame)
 
 ## Resources