@haposoft/cafekit 0.15.3 → 0.16.0-rc.1

package/src/claude/skills/develop/references/parallel-waves.md

@@ -15,6 +15,33 @@ live worktree-subagent behavior (spec `develop-parallel-wave`,
    the standard **sequential fallback**.
 3. `--parallel N`: **wave cap** = N clamped to 1..5; default 3. Never exceed 5 —
    each subagent carries a ~200K context budget (orchestrator.md resource rule).
+4. The destination tree must be clean (`git status --porcelain` is empty) and
+   compatible with the selected base before dispatch. Record the destination
+   `base_sha` and stop without mutation when cleanliness, repository, or base
+   compatibility checks fail.
+5. Before dispatch, state whether `--parallel` consent authorizes worker commits
+   and orchestrator cherry-picks. If that consent is not explicit, obtain the
+   separate confirmation before creating worktrees or asking workers to commit.
+
+### Receipt contract (required per wave/task)
+
+Every task and wave receipt records these exact fields:
+
+```text
+base_sha: <destination commit before dispatch>
+head_sha: <latest worker/integration commit>
+branch: <worker branch>
+worktree_path: <retained or merged worktree path>
+commit_range: <base_sha>..<head_sha>
+retention: retained|released
+cleanup_authorization: pending|explicit-discard|merged-release
+```
+
+Reviewer and tester commands MUST inspect `git diff <base_sha>..<head_sha>` (or
+`git diff --stat <base_sha>..<head_sha>`), never an ambient working-tree diff.
+Every fix is a new commit: advance `head_sha`, replace `commit_range`, and rerun
+only affected gates plus the wave integration check. A receipt without these
+fields is incomplete.
 
 ## 2. Wave planning (normative)
 
@@ -22,14 +49,25 @@ live worktree-subagent behavior (spec `develop-parallel-wave`,
 ready(t) = t.status == "pending" AND every dep in task_registry[t].dependencies
            has status == "done"
 candidates = ready tasks in task_registry order
-wave = first ≤cap candidates, EXCLUDING any task that shares a Create or Modify
-       path (exact normalized string match over its Related Files table) with an
-       earlier task already in the wave — the excluded task returns to the pool
+wave = first ≤cap candidates, EXCLUDING any task that conflicts with an
+       earlier task already in the wave under the conflict graph below
 ```
 
-**Single writer per file per wave** is absolute. `Read` rows never conflict.
-If the wave is empty but pending tasks remain, dependencies are unsatisfiable in
-parallel — finish them with the sequential loop and say so.
+**Conflict graph.** A pair conflicts when either task writes the same exact file,
+one writes a directory another writes, or either touches a shared mutable surface:
+lockfiles, manifests/export barrels, migrations/registries, generated artifacts,
+or shared state writers. `Create`/`Modify`/`Delete` rows are writers; `Read` rows
+are still conflicts when they consume a mutable generated or registry surface.
+Normalize paths before comparison. If overlap is uncertain, classify it as a
+conflict and defer the task to the sequential fallback; never guess that two
+writers are independent.
+
+**Single writer per file per wave** remains absolute. Read-only tasks can still
+be deferred when they inspect a directory or shared generated state that a sibling
+writes.
+
+If the wave is empty but pending tasks remain, dependencies or conflicts are
+unsatisfiable in parallel — finish them with the sequential loop and say so.
 
 ### Worked example
 
@@ -39,7 +77,7 @@ Registry: A (deps: –), B (deps: –), C (deps: A), D (deps: – but shares
 - Wave 1 = A, B (D excluded: path collision with B; C excluded: dep on A)
 - Wave 2 = C, D (A done unblocks C; B done releases D's path)
 
-## 3. Dispatch (one god-developer per wave task)
+## 3. Dispatch (one implementer per wave task)
 
 Every dispatch uses worktree isolation + background execution and a
 self-contained prompt per `rules/orchestrator.md` (task file content, design and
@@ -52,16 +90,32 @@ these mandatory lines:
 4. "When done, `git add` your changes and `git commit -m \"task(<id>): <title>\"` —
    an uncommitted worktree cannot be merged."
 5. End with the standard `Status: DONE|CONCERNS|BLOCKED|NEEDS_INFO` block, plus
-   your worktree path, branch, and commit hash(es).
+   the receipt fields from §1, including worktree path, branch, and commit range.
+6. If a worker fails or blocks, do not remove its worktree or delete its branch.
+   Mark `retention: retained` and `cleanup_authorization: pending` until merge
+   succeeds or the user gives explicit discard authorization.
 
-The Agent result returns `worktreePath` and `worktreeBranch` — record both per task.
+The orchestrator records `base_sha` immediately before dispatch. The worker's
+first accepted commit becomes `head_sha`; no receipt may use a moving ambient
+HEAD as a substitute. The Agent result returns `worktreePath` and
+`worktreeBranch`; record both in the receipt.
 
 ## 4. Quality gate — inside the worktree, before merge
 
 Run the unchanged Stage A + Stage B gate (`references/quality-gate.md`) per task
-**with the task's worktree as working directory**. Gate evidence from that run
-feeds the task receipt. 3 failed rounds → COLLAPSE protocol for that task only;
-sibling tasks in the wave keep running.
+**with the task's worktree as working directory**. Before reviewing, tester and
+reviewer commands must inspect the receipt's immutable range:
+
+```bash
+git diff --stat "$BASE_SHA..$HEAD_SHA"
+git diff "$BASE_SHA..$HEAD_SHA"
+```
+
+Do not replace this range with `git diff`, `git status`, or another ambient
+working-tree view. Gate evidence from that run feeds the task receipt. Three
+failed rounds → COLLAPSE protocol for that task only; sibling tasks in the wave
+keep running. Any fix creates a new commit and updates `head_sha`/`commit_range`
+before affected gates rerun.
 
 ## 5. Merge protocol (spike-verified — do not improvise)
 
@@ -69,27 +123,50 @@ sibling tasks in the wave keep running.
 (`worktree.baseRef: "fresh"` default), NOT the session HEAD. On repos whose origin
 default diverges, `git merge <agent-branch>` explodes into unrelated conflicts.
 
-Therefore, for each gate-passed task, **sequentially** (one at a time, registry order):
+Therefore, for each gate-passed task, sequentially (one at a time, registry order):
 
 ```bash
 git cherry-pick <agent-commit>       # base-agnostic: applies only the agent's diff
 # conflict? → git cherry-pick --abort
 #   → task_registry[task].status = "blocked", blocker = one-line conflict summary
-#   → continue with the next passed task
-git worktree remove --force .claude/worktrees/agent-<id>   # NOT auto-cleaned —
-git branch -D worktree-agent-<id>                          # explicit cleanup, always
+#   → retain the worktree/branch; receipt says retention=retained
 ```
 
-Cleanup runs for unchanged/failed worktrees too (spike: even a read-only run
-leaves its worktree and branch behind). Optionally set `worktree.baseRef: "head"`
-in settings; cherry-pick remains the recipe regardless.
+A successful merge may release the worktree and branch only after the receipt
+records `head_sha` at the merge result, the new `commit_range`, and
+`cleanup_authorization: merged-release`:
+
+```bash
+git worktree remove .claude/worktrees/agent-<id>
+git branch -d worktree-agent-<id>
+```
+
+Never use `--force` cleanup for failed or blocked work. Retain its identifiable
+worktree and branch for inspect/resume until the merge succeeds or the user
+explicitly authorizes discard; record `cleanup_authorization: explicit-discard`
+when that happens. Optionally set `worktree.baseRef: "head"` in settings;
+cherry-pick remains the recipe regardless.
 
 ## 6. Post-merge integration check (per wave)
 
-After the wave's last cherry-pick: run the project build or the affected test
-subset (never the full suite mid-flight — that runs once at develop completion).
-Failure = fix before computing the next wave. This is the wave gate of
-`quality-gate.md`.
+After the wave's last cherry-pick, run an affected integration command derived
+from the task's `## Evidence` and repository contract (build or affected test
+subset; never the full suite mid-flight). Record command, `base_sha`, `head_sha`,
+range, and result in the wave receipt. Failure blocks the next wave.
+
+After the final wave, run an explicit feature/full integration command derived
+from the repository contract — for example the feature's exact Evidence suite
+or the repository's documented full test/build command. A final scout is not a
+substitute. Classify every failure before acting as exactly one of:
+
+- `baseline` — reproduces from the recorded destination `base_sha`;
+- `environment` — tool, dependency, permission, or service unavailable;
+- `spec` — requirement, acceptance, or evidence contract mismatch;
+- `code` — implementation or integration regression.
+
+Do not blind-retry. Fix `code`/`spec` failures with a new commit and affected
+gates; record `baseline`/`environment` blockers and escalate or use the
+sequential fallback according to the task contract.
 
 ## 7. State sync — orchestrator is the single writer
 
@@ -106,7 +183,9 @@ unchanged — a receipt-less done blocks the turn. After syncing the wave, recom
 |---|---|
 | Escape hatch on / not a git repo / no isolation | Sequential fallback + stated reason |
 | Same-wave path collision | Defer the later task to next wave (§2) |
-| Gate fails 3× for a task | COLLAPSE for that task; wave continues |
-| Cherry-pick conflict | Abort pick; task `blocked` + conflict blocker; wave continues |
-| Post-merge check fails | No next wave until fixed |
+| Gate fails 3× for a task | COLLAPSE for that task; retain worktree/branch and receipt; wave continues |
+| Worker failure or blocked task | Retain identifiable worktree/branch; no force-remove; classify and await resume or explicit discard |
+| Cherry-pick conflict | Abort pick; task `blocked` + conflict blocker; retain worktree/branch; wave continues |
+| Post-merge check fails | Classify baseline/environment/spec/code; no next wave until resolved or explicitly blocked |
+| Final integration fails | Record failure class and stop; do not claim completion from a final scout |
 | Empty wave, tasks pending | Sequential loop for the remainder + notice |

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)