fix: the findings of the release review of 6.3.0

The review of v6.2.0..f669b87 (BLOCK: 1 BLOCKER, 12 MAJOR, 1 MINOR), each
fixed behind a test that failed first, or, for the two missing tests, a test
shown to fail on a stub of the branch it covers.

- Review steps appended by /trekexecute Phase 7.2 are held to the step rules
  on any plan version: plan-validator --steps-from <N> (on a plan below 1.8 a
  template review step validated and was executed).
- The guard refuses where no one can be asked also when its rules will not
  load; the wave merge path names that refusal instead of MERGE_REFUSED.
  Tests for the classifier-error refusal and post-approval-log's own check.
- release-check: the version files may change only in their version after
  the review (JSON compared without it), README diff lines are read inside
  hunks only, an unreadable diff is exit 2, and npm test runs without
  NODE_TEST_CONTEXT.
- What counts as a step of only tests: a note in parentheses is not a path,
  and a data file under specs/ is not a test. End-to-end: rides on the last
  step that builds behaviour (validator hint, trekplan, template).
- A removed line is cited as <rev>:<path>:<line> (findings-schema hint,
  trekreview re-ask).
- skill-lint counts a trailing newline as no line; regression-check takes
  commandEnv from lib/util/command-env.mjs; CLAUDE.md names four mode-read
  exemptions.
- /security-review, older than v6.2.0: the criteria runner refuses git
  --output, which writes a file.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

commands/trekexecute.md

@@ -915,7 +915,13 @@ in this order:
   a merge when the branch is main), so that answer is the one question for the
   merge (operator decision 2026-10-08; it was two when `--gates` added a pause
   of its own). A declined guard question means the call did not run: stop and
-  report it like `MERGE_REFUSED`, keeping `wave.json`.
+  report it like `MERGE_REFUSED`, keeping `wave.json`. In the permission mode
+  that shows no prompts the guard does not ask: it refuses the push and the
+  merge (exit 2, "no one to ask"). Then stop, keep `wave.json`, and report that
+  the guard refused because no one can be asked, not that local changes are in
+  the way: the operator runs this session's push-and-merge block by hand, or
+  switches to a mode that asks and re-runs. A re-run in the same mode is
+  refused again.
 
 **Merge session branches back (SEQUENTIAL, one at a time):**
 
@@ -2216,9 +2222,12 @@ the run is `stopped`, and the merge stays closed.
    plan_version ≥ 1.7 plan the manifest the legacy rule synthesizes
    (Phase 2: `expected_paths` ← its Files, …): a rule already in this file, not
    a new design. Earlier steps are never touched.
-3. Check that the new steps can run, before anyone is asked:
+3. Check that the new steps can run, before anyone is asked. `--steps-from`
+   holds the appended steps to the step rules (`Test first:` with its `File:`,
+   one runnable `Verify:`) whatever the plan's version; below 1.8 nothing else
+   would:
    ```bash
-   node ${CLAUDE_PLUGIN_ROOT}/lib/validators/plan-validator.mjs --strict --json "{plan_path}"
+   node ${CLAUDE_PLUGIN_ROOT}/lib/validators/plan-validator.mjs --strict --json --steps-from {total + 1} "{plan_path}"
    ```
    Any exit but 0 (a `Verify:` that is not one test-runner call, a
    `Test first:` without its `File:`, …): restore the plan from the copy,

commands/trekplan.md

@@ -755,7 +755,9 @@ Write the plan following the template structure. The plan MUST include:
    `End-to-end: \`bash tests/e2e.sh\``. The same command is also listed under
    `## Verification`: Phase 7 of `/trekexecute` runs that section, and a passed
    criterion that runs the step's `End-to-end:` command is what verifies the
-   run end to end.
+   run end to end. `End-to-end:` rides on the last step that builds behaviour,
+   with `tests/e2e.sh` in that step's `Files:`: a step of its own that only adds
+   the script is a step of only tests, and it can never be proven red.
 10. **Execution Strategy** — For plans with > 5 steps: group steps into sessions
     (3–5 steps each), organize sessions into waves (parallel where independent),
     specify scope fences per session. Omit for plans with ≤ 5 steps.

commands/trekreview.md

@@ -423,7 +423,9 @@ same stable error codes (`FINDINGS_NO_JSON_BLOCK`, `FINDINGS_PARSE_ERROR`,
 `FINDING_PROSE_LINE_OUT_OF_RANGE` is the same check on a `path:line` written
 in prose. In a finding's own fields (`title`, `detail`, `recommended_action`,
 `brief_ref`) it is an **error**: re-ask that reviewer like any other schema
-failure. In the prose around the JSON block it is a **warning**: the re-ask
+failure, and quote the way a removed line is cited, `<rev>:<path>:<line>`
+(`v6.2.0:hooks/x.mjs:120`, not judged against today's file), so a finding
+about deleted code keeps its line instead of losing it. In the prose around the JSON block it is a **warning**: the re-ask
 asks for the block only and cannot correct that prose, so do not re-ask —
 report each such warning (reviewer, citation, the file's line count) in the
 Coverage section of `review.md`.