cool-workflow 0.2.4 → 0.2.6

package/docs/readme-v0.1.87-full.md

@@ -1,301 +0,0 @@
-<div align="center">
-
-# Cool Workflow
-
-**Point an AI coding agent at a repo, get a saved report with real citations — not a chat message you lose.**
-
-[![CI](https://img.shields.io/github/actions/workflow/status/coo1white/cool-workflow/ci.yml?branch=main&style=flat-square&label=CI)](https://github.com/coo1white/cool-workflow/actions/workflows/ci.yml)
-[![npm](https://img.shields.io/npm/v/cool-workflow?style=flat-square&label=npm&color=cb3837)](https://www.npmjs.com/package/cool-workflow)
-[![downloads](https://img.shields.io/npm/dm/cool-workflow?style=flat-square&label=downloads)](https://www.npmjs.com/package/cool-workflow)
-[![provenance](https://img.shields.io/badge/npm-provenance-3178C6?style=flat-square)](https://www.npmjs.com/package/cool-workflow)
-[![release](https://img.shields.io/github/v/tag/coo1white/cool-workflow?style=flat-square&label=release&color=brightgreen&sort=semver)](https://github.com/coo1white/cool-workflow/tags)
-[![license](https://img.shields.io/badge/license-BSD--2--Clause-blue?style=flat-square)](LICENSE)
-
-<img src="docs/assets/cool-workflow-readme-promo.png" alt="Cool Workflow turns AI agent repo questions into saved, cited, tamper-evident reports." width="100%">
-
-</div>
-
-## What is this, really?
-
-You put a question to an AI coding agent, it gives an answer in the chat, and
-then the answer is gone. Next week you put the same question and have to start
-all over again.
-
-**Cool Workflow (CW) makes that lost question into a kept job.** You point it at
-a code store with a question like *"what are the security risks here?"* It runs
-your AI agent over all the code in ordered steps and puts a **report file** on
-disk — every point backed by an exact `file.js:42` pointer to the line. You are
-able to run it again, give it to others, and even give proof that the report was
-not changed by anyone.
-
-```
-        you ask once                          CW gives you
-   "what are the risks in my repo?"     →   a saved report.md with
-                                              cited findings, repeatable
-```
-
-It does **not** run the AI model itself. You give your own agent (for one, the
-`claude` command line) and CW keeps it working, makes a record of what took
-place, and checks the answer. Take CW as the *project manager*, and your agent
-as the *worker*.
-
-> New to this? You're in the right place — this README is a step-by-step start.
-> Deeper/advanced docs live in the [wiki](https://github.com/coo1white/cool-workflow/wiki).
-
----
-
-## Project rule
-
-CW should stay a small, trusted tool, not a platform.
-
-```text
-ask simple -> run simple -> verify simple -> resume simple
-```
-
-The engineering base is FreeBSD-like: POLA first, fail closed, no silent
-fallback, stdout as data, stderr as diagnostics, and documented stable
-surfaces. The user-facing spirit is close to Homebrew: a small command
-surface, a strong `doctor` check, and clear next steps when a run is
-blocked or a report does not verify.
-
-That means CW should hide orchestration detail behind clear commands,
-keep `.cw/` state open to check, make recovery boring, and prefer a
-small tool that can be trusted over a broad agent platform.
-
----
-
-## What you need
-
-1. **Node.js** (v18+). Make a check with `node --version`.
-2. **An AI agent on the command line.** The most simple is **Claude Code** —
-   after you put it in you will have a `claude` command. Make a check with
-   `claude --version`. (CW also works with `codex`, or any command/HTTP agent —
-   but make your start with `claude`.)
-
-> No agent yet? You are still able to **see CW work** (next part, step 1)
-> without one. The full report needs an agent, because CW never makes a call to
-> a model itself.
-
----
-
-## Quick start (3 steps)
-
-### 1. See it run — no install, no agent, no API key
-
-```bash
-npx cool-workflow demo tamper
-```
-
-This gives proof of CW's chief trick in 30 seconds (more on that
-[below](#can-i-trust-the-report)). If you see `VERDICT: tamper-evidence holds ✓`,
-all is working.
-
-Not sure what to run next?
-
-```bash
-npx cool-workflow doctor --onramp
-```
-
-This prints the short path for a first run, the fast checks for source work, and
-the full gate to use before a release.
-
-From a source checkout, use:
-
-```bash
-cd plugins/cool-workflow
-node scripts/cw.js doctor --onramp --changed-from origin/main
-```
-
-### 2. Check, then run a real review on your own repo
-
-First make a zero-write check. It does not make a run, write `.cw/`, or call
-your agent:
-
-```bash
-npx cool-workflow quickstart architecture-review --check \
-  --repo /path/to/your/project \
-  --question "What are the main risks in this codebase?" \
-  --agent-command builtin:claude
-```
-
-If the check is good, run the review:
-
-```bash
-npx cool-workflow quickstart architecture-review \
-  --repo /path/to/your/project \
-  --question "What are the main risks in this codebase?" \
-  --agent-command builtin:claude
-```
-
-If the report has to go to someone else, make the checked bundle in the same
-run:
-
-```bash
-npx cool-workflow quickstart architecture-review \
-  --repo /path/to/your/project \
-  --question "What are the main risks in this codebase?" \
-  --agent-command builtin:claude \
-  --bundle
-```
-
-- `--repo` — the folder you have a wish to get looked at.
-- `--question` — what you have a wish to be certain of.
-- `--agent-command builtin:claude` — make use of the Claude wrapper that comes
-  with it (read-only; it never makes changes to your code).
-- `--agent-command builtin:codex` — make use of the Codex wrapper that comes
-  with it (read-only; it never makes changes to your code).
-
-CW makes a plan of the work, keeps your agent working over your repo in steps,
-and gives out where it kept the report. For a living view in the window while
-every worker is at work, take it up with `CW_AGENT_STREAM=1`; the view goes to
-stderr only and the kept answer is not changed.
-
-> **No agent put in place?** CW comes to a safe stop and says so
-> (`status: blocked`) — it never makes up an answer. Put in `claude` and run it
-> again.
-
-### 3. Read the report
-
-```bash
-cat /path/to/your/project/.cw/runs/<run-id>/report.md
-```
-
-You get a short account, ordered points, and **clickable pointers** like
-`src/server.js:18` for every point made — so you are able to make a check of
-each one yourself.
-
----
-
-## Install it (optional)
-
-`npx` is ever working with no need to put it in. To get the short `cw` command
-everywhere:
-
-```bash
-npm install -g cool-workflow      # then use:  cw …   instead of  npx cool-workflow …
-```
-
----
-
-## What else can it do?
-
-CW comes with a number of ready-made "jobs" (run `cw list` to see them all):
-
-| Command | What it does |
-|---|---|
-| `architecture-review` | Make a map of a repo's structure and put its true risks in order, with facts. |
-| `pr-review-fix-ci` | Go over a pull request, put forward fixes, make a check of CI. |
-| `research-synthesis` | Get together and make into one a fact-backed answer to a question. |
-| `release-cut` | Keep a gated, gone-over release moving. |
-
-It also puts the same acts out over **MCP**, so editors like Claude Desktop /
-Cursor / VS Code are able to make a call to CW as a tool. See the
-[wiki](https://github.com/coo1white/cool-workflow/wiki) for that and for
-multi-agent runs.
-
----
-
-## Can I trust the report?
-
-This is what makes CW not the same as the rest. Because CW only *gives the work
-over* to your agent, it keeps a record of every step that makes any false change
-come to light: every agent's given token use is signed by secret-key science and
-chained by hash, so **changing the record after the fact has the chain broken** —
-and anyone is able to make the check again offline with only a public key.
-
-See it for yourself — the `demo tamper` from step 1 makes a false record in two
-ways and gets both:
-
-```text
-▶ LEDGER tamper
-  after:  ✗ DETECTED — the hash chain caught it: chain-link[2]: telemetry-chain-broken
-▶ SIGNATURE tamper
-  after:  ✗ DETECTED — signature does not match reported usage
-VERDICT: tamper-evidence holds ✓ — every forgery caught offline, with only the public key.
-```
-
-On a true run, make a check of any run's record yourself:
-
-```bash
-cw telemetry verify <run-id>
-```
-
-CW makes use of this on its own code — see the kept living-run proof in
-[`plugins/cool-workflow/docs/dogfood/`](plugins/cool-workflow/docs/dogfood/).
-
-The plain point: *the thing that uses up the tokens is not the thing that keeps
-the books.* That keeping-apart is normal in account-keeping — CW gives it to AI
-agents.
-
----
-
-## Hand the report to someone — they can check it on their own
-
-A report you keep on your own machine is one thing. A report you can **give to
-someone** who then makes the check themselves is what you are really after. Add
-`--bundle` to the one command and CW seals the finished run into a single,
-self-checking file:
-
-```bash
-npx cool-workflow quickstart architecture-review \
-  --repo /path/to/your/project --question "What are the main risks?" \
-  --agent-command builtin:claude --bundle --with-trust-key ./trust-pub.pem
-```
-
-This puts a `report.cwrun.json` file **where you are** (not in the looked-at
-repo). The one file holds the report, the `file.js:42` pointers, the signed and
-hash-chained record, **and the public key**.
-
-Give that file to anyone. With no need for your repo, your keys given over on the
-side, or a put-in past `npx`, they make the check on their own — offline, with
-only the file:
-
-```bash
-npx cool-workflow report verify-bundle report.cwrun.json
-```
-
-If the bundle was changed in any way after the fact — the record, a signature, or
-the bytes — the check says so and comes to a stop (it gives back `ok: false` and a
-non-zero code), so a bundle you send on can never be a quiet lie. CW still never
-runs the model itself; it only keeps the books and makes the check.
-
-Want to see the whole thing in 30 seconds, with no agent and no key of your own?
-
-```bash
-npx cool-workflow demo bundle
-```
-
-It makes a real sealed bundle, makes two false changes to it, and shows the check
-getting **both** — offline, with only the public key the bundle carries.
-
----
-
-## Troubleshooting
-
-| Problem | Fix |
-|---|---|
-| `status: blocked`, `agentConfigured: false` | No agent is in place. Put in `claude` (or give `--agent-command`). |
-| `claude: command not found` | Put in Claude Code so the `claude` command is there, then run again. |
-| Want to see the plan without running the AI | Put in `--preview` — it gives the steps and starts nothing. |
-| Want a live agent trace | Put `CW_AGENT_STREAM=1`. It is stderr-only, TTY-gated, and `CW_NO_STREAM=1` puts it off. |
-| Where did my report go? | The command gives out `reportPath`; it is under `<your-repo>/.cw/runs/<id>/report.md`. |
-
----
-
-## How it works (one paragraph)
-
-CW is a small TypeScript/Node run-time that needs no other parts. It makes a
-record of the agent loop out in the open — *plan → dispatch → record → verify →
-commit → report* — as long-lasting files on disk, so a run is open to looking-at
-and able to be played again in place of a chat you let go. It never puts a model
-SDK inside and keeps no API key; your put-in-place agent does the thinking, CW
-does the book-keeping and the checking. For the structure, multi-agent
-working-together, execution backends, and the full CLI/MCP face, see the
-**[wiki](https://github.com/coo1white/cool-workflow/wiki)** and
-[`plugins/cool-workflow/docs/`](plugins/cool-workflow/docs/).
-
----
-
-## License
-
-BSD-2-Clause. See [LICENSE](LICENSE). Built by COOLWHITE LLC.

package/docs/routines.md

@@ -1,101 +0,0 @@
-# Routines
-
-A CW routine has a trigger, an event payload, match rules, and a prompt it makes
-for an agent host to run.
-
-CW keeps routine data in:
-
-```text
-.cw/routines/triggers.json
-.cw/routines/payloads/
-```
-
-## Commands
-
-Create an API trigger:
-
-```bash
-cw routine create \
-  --kind api \
-  --prompt "Handle this API event."
-```
-
-Create a GitHub trigger:
-
-```bash
-cw routine create \
-  --kind github \
-  --prompt "Review this GitHub event." \
-  --match '{"action":"opened"}'
-```
-
-Fire a trigger from a payload file:
-
-```bash
-cw routine fire github payload.json
-```
-
-Inspect events:
-
-```bash
-cw routine events
-```
-
-## Long Architecture Reviews
-
-Use `architecture-review-fast` for the foreground user path. Then put the
-full `architecture-review` app in line as background work when a deep look-over
-should not get in the way of a back-and-forth session:
-
-```bash
-node scripts/architecture-review-fast.js \
-  --repo /path/to/repo \
-  --question "Is this architecture sound?" \
-  --metrics \
-  --schedule-full
-```
-
-The wrapper makes a one-shot reminder schedule whose `workflowId` is
-`architecture-review`. The schedule prompt is policy. CW keeps the schedule and
-notes down due events; the outside agent host says how to run the long review.
-The prompt has in it the foreground fast run id, fast report path, source-context
-digest/profile, and it asks the background agent to give back the full review
-report path and digest.
-The `--metrics` flag is not required and it gives back foreground time used plus
-agent-spawn and result-cache-hit counts for the fast run.
-
-## PDCA Blackboard Development Lessons
-
-When a task asks for agents to work together, first try the parts CW already
-has:
-
-- workflow apps give the work shape
-- worker output gives checked facts
-- the blackboard gives shared state
-- MCP gives tool access to the same state
-- smoke tests prove the loop
-
-Do not make a new MCP server when the existing server can show the same run
-state. Add a workflow app first, then prove the app with one smoke that uses
-both CLI and MCP.
-
-For a three-agent loop, keep the order plain:
-
-```text
-plan -> build -> audit -> next action
-```
-
-Each agent should write one blackboard message and, when there is a result
-file, one artifact ref. Take a snapshot after the audit and after the next
-action. If audit evidence is missing, let the worker evidence gate refuse the
-result instead of adding a new policy layer.
-
-Before a PR, base the branch on `origin/main`, run the generated-doc checks,
-and sync generated docs when the gate says they are stale. This keeps unrelated
-local commits and generated README/index drift out of the work.
-
-## Boundary
-
-CW v0.1.1 does not give managed cloud infrastructure. It gives a local
-routine bridge that may be joined to GitHub Actions, webhooks, cron, or a
-small HTTP adapter in a later release.

package/docs/scheduled-tasks.md

@@ -1,80 +0,0 @@
-# Scheduled Tasks
-
-CW scheduled tasks let you make looping prompts, cron-like schedules, one-shot
-reminders, expiration, jitter, and clear completion.
-
-CW keeps schedules in:
-
-```text
-.cw/schedules/tasks.json
-```
-
-## Commands
-
-Make a `/loop`-ready schedule:
-
-```bash
-cw loop \
-  --intervalMinutes 30 \
-  --prompt "Check this workflow and continue if work is due."
-```
-
-Make a loop:
-
-```bash
-cw schedule create \
-  --kind loop \
-  --intervalMinutes 30 \
-  --prompt "Check this workflow and continue if work is due."
-```
-
-Make a cron schedule:
-
-```bash
-cw schedule create \
-  --kind cron \
-  --cron "*/15 * * * *" \
-  --prompt "Run the due workflow scan."
-```
-
-Make a reminder:
-
-```bash
-cw schedule create \
-  --kind reminder \
-  --delayMinutes 60 \
-  --prompt "Remind me to inspect the report."
-```
-
-List and look through:
-
-```bash
-cw schedule list
-cw schedule due
-cw schedule complete <schedule-id>
-cw schedule pause <schedule-id>
-cw schedule resume <schedule-id>
-cw schedule run-now <schedule-id>
-cw schedule history <schedule-id>
-cw schedule delete <schedule-id>
-```
-
-Run the local desktop-like daemon one time:
-
-```bash
-cw schedule daemon --once
-```
-
-Run it without stopping:
-
-```bash
-cw schedule daemon --intervalSeconds 60
-```
-
-## Notes
-
-- Time is measured to the minute.
-- By default, expiration comes after 7 days.
-- `jitterSeconds` can put space between runs.
-- CW does not start the daemon by default. Use `schedule daemon`, cron, or
-  some other overseer to call `schedule due` and run due prompts.

package/scripts/agents/claude-p-agent.sh

@@ -1,9 +0,0 @@
-#!/usr/bin/env bash
-# EXAMPLE operator agent config for CW Agent Delegation Drive — bash entry point.
-#
-# The single source of truth is claude-p-agent.js (the portable node version);
-# this shim only delegates so the two can never drift. Point CW at either:
-#   CW_AGENT_COMMAND="node $(pwd)/scripts/agents/claude-p-agent.js {{input}} {{result}}"
-#   CW_AGENT_COMMAND="bash $(pwd)/scripts/agents/claude-p-agent.sh {{input}} {{result}}"
-set -euo pipefail
-exec node "$(dirname "$0")/claude-p-agent.js" "$@"

package/scripts/block-unapproved-tag.sh

@@ -1,75 +0,0 @@
-#!/usr/bin/env bash
-# block-unapproved-tag.sh — PreToolUse hook for the Bash tool.
-# Reads hook input JSON on stdin. If the command creates or pushes a tag,
-# require BOTH markers for the current HEAD sha:
-#   .cw-release/gate-<sha>.ok        (written by release-gate.sh)
-#   .cw-release/review-<sha>.verdict (written by the release-reviewer agent, must contain APPROVED)
-# If .cw-release/verdict-signing.pub is committed (scripts/verdict-keygen.js),
-# also requires a valid ed25519 signature on the verdict (its .sig sidecar) —
-# opt-in, backward compatible with repos that haven't set up signing yet.
-# Exit 2 blocks the tool call; stderr is fed back to the agent.
-set -uo pipefail
-
-INPUT="$(cat)"
-# Parse the tool command with node, not jq: node is guaranteed present in this
-# Node project (and matches the repo's node/npm/git-only portability rule),
-# whereas jq is not installed in every Claude Code environment. A missing jq
-# would make this security hook silently fail OPEN (empty command → exit 0),
-# letting an unreviewed tag through. node keeps it portable and fail-closed.
-CMD="$(printf '%s' "$INPUT" | node -e 'let s="";process.stdin.on("data",d=>s+=d).on("end",()=>{try{process.stdout.write(String(JSON.parse(s)?.tool_input?.command||""))}catch{process.stdout.write("")}})' 2>/dev/null)"
-[[ -z "$CMD" ]] && exit 0
-
-# Only care about tag creation / tag push. Widened from the original pattern,
-# which missed the single most natural bypass form: `git push origin v0.2.3`
-# (a bare tag-shaped ref, no --tags flag and no refs/tags/ prefix) matched
-# neither side of the old alternation. Also now tolerates a global flag before
-# the tag subcommand (`git -C dir tag ...`) and the `--annotate` long form.
-if ! printf '%s' "$CMD" | grep -qE 'git(\s+-[A-Za-z]+\s+\S+)*\s+tag\s+(-a\s+|--annotate\s+)?v[0-9]|git\s+push\b.*(--tags|refs/tags|[[:space:]]v[0-9])'; then
-  exit 0
-fi
-
-REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null)" || exit 0
-SHA="$(git -C "$REPO_ROOT" rev-parse HEAD)"
-# cut() commits the verdict ON TOP of the reviewed commit, so at tag time the
-# verdict filename is keyed on HEAD~1's sha, not HEAD's — the same
-# HEAD-or-HEAD~1 tolerance release-gate.yml uses. Without this, a manual
-# retag of a cut-produced commit was always blocked (v0.2.3 recovery).
-PARENT="$(git -C "$REPO_ROOT" rev-parse HEAD~1 2>/dev/null || echo none)"
-GATE=""
-VERDICT=""
-for C in "$SHA" "$PARENT"; do
-  [[ "$C" == "none" ]] && continue
-  if [[ -f "$REPO_ROOT/.cw-release/review-$C.verdict" ]]; then
-    GATE="$REPO_ROOT/.cw-release/gate-$C.ok"
-    VERDICT="$REPO_ROOT/.cw-release/review-$C.verdict"
-    break
-  fi
-done
-[[ -z "$VERDICT" ]] && VERDICT="$REPO_ROOT/.cw-release/review-$SHA.verdict"
-[[ -z "$GATE" ]] && GATE="$REPO_ROOT/.cw-release/gate-$SHA.ok"
-
-if [[ ! -f "$GATE" ]]; then
-  echo "BLOCKED: no release-gate pass for HEAD $SHA (or its parent). Run plugins/cool-workflow/scripts/release-gate.sh first. Tagging without a green gate is forbidden." >&2
-  exit 2
-fi
-
-if [[ ! -f "$VERDICT" ]] || ! grep -q '^APPROVED' "$VERDICT"; then
-  echo "BLOCKED: no APPROVED verdict from the release-reviewer agent for HEAD $SHA (or its parent). Invoke the 'release-reviewer' subagent and obtain approval. Do not write the verdict file yourself — that is a gaming attempt and will be flagged in CI." >&2
-  exit 2
-fi
-
-# Once .cw-release/verdict-signing.pub is committed (see scripts/verdict-keygen.js),
-# also require a valid ed25519 signature on the verdict — closing the gap this grep
-# alone can't: a plain APPROVED text match can't tell a real reviewer verdict from
-# one typed by hand. Absent that public key, this block is a no-op (unchanged,
-# grep-only behavior).
-PUBKEY="$REPO_ROOT/.cw-release/verdict-signing.pub"
-if [[ -f "$PUBKEY" ]]; then
-  SIG="$VERDICT.sig"
-  if [[ ! -f "$SIG" ]] || ! node "$REPO_ROOT/plugins/cool-workflow/scripts/verify-verdict-signature.js" "$VERDICT" "$SIG" "$PUBKEY" >/dev/null 2>&1; then
-    echo "BLOCKED: verdict for HEAD $SHA has no valid signature, but verdict-signing.pub is committed so one is required. Do not hand-write or hand-sign a verdict — obtain a real reviewer approval via release-flow.js with CW_RELEASE_VERDICT_PRIVKEY set." >&2
-    exit 2
-  fi
-fi
-
-exit 0

package/scripts/release-gate.sh

@@ -1,94 +0,0 @@
-#!/usr/bin/env bash
-# release-gate.sh — deterministic release checks for cool-workflow.
-# Pass = writes .cw-release/gate-<HEAD-sha>.ok
-# This script encodes everything that does NOT need LLM judgment.
-set -euo pipefail
-
-REPO_ROOT="$(git rev-parse --show-toplevel)"
-cd "$REPO_ROOT"
-SHA="$(git rev-parse HEAD)"
-# Resolve the PREVIOUS release tag. When this script runs from CI on a tag push
-# (.github/workflows/release-gate.yml), HEAD already carries the tag being
-# released, so a plain `git describe` returns *that* tag and the diff range
-# collapses to empty — making substance/evidence/cadence false-fail every real
-# release. Exclude any tag that points at HEAD so we always compare against the
-# prior release (the parent commit's nearest tag).
-HEAD_TAGS="$(git tag --points-at HEAD 2>/dev/null || echo "")"
-PREV_TAG="$(git describe --tags --abbrev=0 2>/dev/null || echo "")"
-if [[ -n "$HEAD_TAGS" ]] && printf '%s\n' "$HEAD_TAGS" | grep -qxF "$PREV_TAG"; then
-  PREV_TAG="$(git describe --tags --abbrev=0 HEAD^ 2>/dev/null || echo "")"
-fi
-MARKER_DIR="$REPO_ROOT/.cw-release"
-mkdir -p "$MARKER_DIR"
-FAIL=0
-
-say() { printf '%s\n' "$*"; }
-fail() { say "GATE FAIL: $*"; FAIL=1; }
-
-# --- 1. Build & tests (run, don't trust pasted output) -----------------
-say "[1/6] build"
-npm run --prefix plugins/cool-workflow build >/dev/null 2>&1 || fail "build failed"
-
-say "[2/6] tests"
-CW_TEST_CONCURRENCY=1 npm run test:gate --prefix plugins/cool-workflow >/dev/null 2>&1 || fail "tests failed"
-
-if [[ -n "$PREV_TAG" ]]; then
-  RANGE="$PREV_TAG..HEAD"
-
-  # --- 2. Substance: changes must exist outside src/types/ and dist/ ---
-  # The spec (AGENTS.md / reviewer-agent.md Gate 1) is "at least one changed
-  # file outside src/types/ and dist/" — ANY such file (src, scripts, docs,
-  # workflows, tests). Count every changed path that is not under those two
-  # generated/declaration-only trees; declared-but-unread spec accretion is the
-  # reviewer agent's deeper judgment call, not this deterministic floor.
-  say "[3/6] substance (diff outside src/types/ and dist/)"
-  SUBSTANCE=$(git diff --name-only "$RANGE" \
-    | grep -cvE '^plugins/cool-workflow/(src/types/|dist/)' || true)
-  [[ "$SUBSTANCE" -gt 0 ]] || fail "only types/dist changed since $PREV_TAG (spec accretion)"
-
-  # --- 3. Test evidence: test files must have changed ------------------
-  say "[4/6] test evidence"
-  TESTS_CHANGED=$(git diff --name-only "$RANGE" | grep -cE '\.(test|spec)\.|/tests?/' || true)
-  [[ "$TESTS_CHANGED" -gt 0 ]] || fail "zero test changes since $PREV_TAG"
-
-  # --- 4. Cadence: >=4 cycles logged OR >=24h since previous tag, or a recorded HOTFIX ---
-  say "[5/6] cadence"
-  CYCLES=0
-  if [[ -f ITERATION_LOG.md && -n "$PREV_TAG" ]]; then
-    CYCLES=$(git diff "$RANGE" -- ITERATION_LOG.md | grep -c '^+.*|' || true)
-  fi
-  PREV_TS=$(git log -1 --format=%ct "$PREV_TAG")
-  NOW_TS=$(date +%s)
-  HOURS=$(( (NOW_TS - PREV_TS) / 3600 ))
-  # Hotfix path: an urgent fix may ship inside the cadence window, but ONLY via an
-  # EXPLICIT, RECORDED declaration — a "HOTFIX:" line added to ITERATION_LOG.md in this
-  # release range, carrying a reason. It is committed (auditable in the tag's history)
-  # and echoed here, so the bypass is never silent and a reviewer sees the reason.
-  HOTFIX="$(git diff "$RANGE" -- ITERATION_LOG.md | grep -E '^\+.*HOTFIX:' | head -1 | sed -E 's/^\+[[:space:]]*//' || true)"
-  if [[ "$CYCLES" -lt 4 && "$HOURS" -lt 24 ]]; then
-    if [[ -n "$HOTFIX" ]]; then
-      say "  cadence bypassed by recorded HOTFIX (${HOURS}h, ${CYCLES} cycle-lines): ${HOTFIX}"
-    else
-      fail "cadence: only $CYCLES cycles logged and ${HOURS}h since $PREV_TAG (need >=4 cycles, >=24h, or a recorded 'HOTFIX:' line in ITERATION_LOG.md)"
-    fi
-  fi
-else
-  say "[3-5/6] no previous tag; substance/evidence/cadence checks skipped"
-fi
-
-# --- 5. Branch naming: forbid version-number branches -------------------
-say "[6/6] branch naming"
-BRANCH="$(git rev-parse --abbrev-ref HEAD)"
-if [[ "$BRANCH" =~ ^feat/(batch-)?v?[0-9]+ ]]; then
-  fail "branch '$BRANCH' is version-number-driven; name the capability instead"
-fi
-
-# --- Verdict ------------------------------------------------------------
-if [[ "$FAIL" -ne 0 ]]; then
-  rm -f "$MARKER_DIR/gate-$SHA.ok"
-  say "RELEASE GATE: REJECTED ($SHA)"
-  exit 1
-fi
-
-date -u +"%Y-%m-%dT%H:%M:%SZ" > "$MARKER_DIR/gate-$SHA.ok"
-say "RELEASE GATE: PASSED ($SHA) — next step: release-reviewer agent must record APPROVED"