review-changes: Own remediation and convergence

Keep independent reporting in inspect-changes so review-changes can
carry findings through fixes, tracking, and reinspection. Preserve the
original scope and work layers, and report incomplete runs explicitly.

Author: laurynas-biveinis

.github/linters/.jscpd.json

@@ -12,7 +12,7 @@
     "**/zsh/.p10k.zsh"
   ],
   "ignorePattern": [
-    "(?s)description: >-\\n  Internal step of review-changes:.*?Glob"
+    "(?s)description: >-\\n  Internal step of inspect-changes:.*?Glob"
   ],
   "absolute": true
 }

ai/.claude/CLAUDE.md

@@ -11,7 +11,7 @@ When presenting multiple options/alternatives to choose from, NEVER use Greek
 letters (α, β, γ, δ, ...). The user does not know the full Greek alphabet and
 it's awkward to type them in conversation.
 
-Never reference ephemeral IDs (review IDs from `review-changes` or similar
+Never reference ephemeral IDs (review IDs from `inspect-changes` or similar
 tools) in any artifact — duplicate the relevant finding text instead.
 
 ## Task Management

…e/skills/review-changes-analyze/SKILL.md …/skills/inspect-changes-analyze/SKILL.mdai/.claude/skills/review-changes-analyze/SKILL.md renamed to ai/.claude/skills/inspect-changes-analyze/SKILL.md ai/.claude/skills/review-changes-analyze/SKILL.md renamed to ai/.claude/skills/inspect-changes-analyze/SKILL.md

@@ -1,6 +1,7 @@
 ---
+name: inspect-changes-analyze
 description: >-
-  Internal step of review-changes: deeply analyze one kept finding and
+  Internal step of inspect-changes: deeply analyze one kept finding and
   return its analysis block (or a rejection).
 user-invocable: false
 allowed-tools: >-
@@ -44,7 +45,7 @@ Your invocation prompt supplies, for the single finding you must analyze:
   Procedure below and change one only through `## Correction`, never by
   restating it in the analysis body.
 - Any **caller requirements**, if present. Apply the
-  [shared caller-requirements guidance](../review-changes/references/caller-requirements.md).
+  [shared caller-requirements guidance](../inspect-changes/references/caller-requirements.md).
 - **Only when a placement decision applies** (the caller supplied a stack and
   a `REV`): the **stack** as a list of SHA + subject, each entry carrying
   neither, either, or both of `[behind a merge]` and `[merge commit]`, and the
@@ -61,7 +62,7 @@ Your invocation prompt supplies, for the single finding you must analyze:
   locate the defect in `REV` by content, and note that the index holds the
   reviewed change, so amending there is not a bare `git commit --amend`.
 - Existing **prior draft paths**. Follow the
-  [shared prior-draft guidance](../review-changes/references/prior-drafts.md)
+  [shared prior-draft guidance](../inspect-changes/references/prior-drafts.md)
   when filtering issues discovered during analysis.
 - Any **experiment results** for this finding (the matching `EXP` blocks), if
   present.
@@ -92,11 +93,11 @@ tools are read and Git only.
    positives, not disagreements of emphasis or severity. You can only reject;
    you cannot revive a finding verification dropped.
 1. Re-assess the verdict's **provenance** (per the
-   [shared provenance guidance](../review-changes/references/provenance.md)),
+   [shared provenance guidance](../inspect-changes/references/provenance.md)),
    **severity** (per the
-   [shared severity guidance](../review-changes/references/severity.md)), and
+   [shared severity guidance](../inspect-changes/references/severity.md)), and
    **confidence** (per the
-   [shared confidence guidance](../review-changes/references/confidence.md))
+   [shared confidence guidance](../inspect-changes/references/confidence.md))
    against what your deeper study found. When one of the three is
    wrong, append a `## Correction` section (schema below) carrying only the
    fields you are correcting, and state the reasoning in your analysis body as
@@ -169,7 +170,7 @@ tools are read and Git only.
    naming an owner prematurely.
    Pickaxe matches the exact removed string, so when the fix rephrases or
    re-indents it, prefer the bracketing `-L` form. The [attribution
-   procedure](../review-changes/references/provenance-attribution.md)
+   procedure](../inspect-changes/references/provenance-attribution.md)
    carries pickaxe search and merge-propagation caveats; apply those in the
    removal direction, with `<REV>` as the search endpoint. Exclude its
    containment and post-image blame tests: those classify surviving content.
@@ -217,7 +218,7 @@ tools are read and Git only.
    Provenance and placement can identify different owning commits. Determine
    provenance from whether the defect already exists in the scope's pre-image,
    including when introduced by the baseline commit itself, per the
-   [shared provenance guidance](../review-changes/references/provenance.md).
+   [shared provenance guidance](../inspect-changes/references/provenance.md).
    Placement follows the fix's target and cases (a)–(d) above, including the
    candidate-stack and never-published conditions for amendment. Compare blame
    results for consistency only when the revision, region, and attribution
@@ -296,7 +297,7 @@ carries an analysis block: never on a deferral, and never with a `## Rejection`
 
 If — and only if — analysis surfaced a genuinely new issue, append a
 `## Proposed new findings` section after the analysis block, following the
-[shared output-section contract](../review-changes/references/shared-output-sections.md).
+[shared output-section contract](../inspect-changes/references/shared-output-sections.md).
 
 `## Rejection`, `## Correction`, `## Proposed new findings`, and
 `## Experiment requests` are the only higher-level (`##`) headings allowed in a
@@ -309,7 +310,7 @@ rejecting analyst that also spotted a genuinely different issue still reports it
 ## Experiment requests
 
 Follow the [shared experiment-request format and safety
-constraints](../review-changes/references/shared-output-sections.md). Request
+constraints](../inspect-changes/references/shared-output-sections.md). Request
 runtime evidence when it would sharpen the analysis — **including whether a
 suggested action or one of your options is actually feasible given the tooling,
 environment, or APIs, not only whether the finding is valid**. Return the

…aude/skills/review-changes-step/SKILL.md …ude/skills/inspect-changes-step/SKILL.mdai/.claude/skills/review-changes-step/SKILL.md renamed to ai/.claude/skills/inspect-changes-step/SKILL.md ai/.claude/skills/review-changes-step/SKILL.md renamed to ai/.claude/skills/inspect-changes-step/SKILL.md

@@ -1,6 +1,7 @@
 ---
+name: inspect-changes-step
 description: >-
-  Internal step of review-changes: perform one code-review pass over a
+  Internal step of inspect-changes: perform one code-review pass over a
   given scope and return the draft findings.
 user-invocable: false
 allowed-tools: >-
@@ -40,7 +41,7 @@ Your invocation prompt supplies:
   `git diff A..B`). Run it to see the changes to review.
 - The **pre-image baseline** to tag provenance against, if supplied.
 - Any **caller requirements**, if present. Apply the
-  [shared caller-requirements guidance](../review-changes/references/caller-requirements.md).
+  [shared caller-requirements guidance](../inspect-changes/references/caller-requirements.md).
 
 You do a single fresh pass each invocation; you carry no state between runs.
 
@@ -150,11 +151,11 @@ Return the scope line first — including the round index, e.g.
 - IDs use the format `R<N>-<NNN>`, where `N` is the round index you were given
   and `NNN` runs in per-round discovery order (`001`, `002`, …).
 - Grade every finding's severity per the
-  [shared severity guidance](../review-changes/references/severity.md).
+  [shared severity guidance](../inspect-changes/references/severity.md).
 - Calibrate every finding's confidence per the
-  [shared confidence guidance](../review-changes/references/confidence.md).
+  [shared confidence guidance](../inspect-changes/references/confidence.md).
 - Classify every finding's provenance per the
-  [shared provenance guidance](../review-changes/references/provenance.md),
+  [shared provenance guidance](../inspect-changes/references/provenance.md),
   which says when the scope's diff settles it, when Git history is needed, and
   how cheap a first-pass tag may be. Tag it from the diff and a cheap baseline
   read; never run history attribution at this tier.

…de/skills/review-changes-verify/SKILL.md …e/skills/inspect-changes-verify/SKILL.mdai/.claude/skills/review-changes-verify/SKILL.md renamed to ai/.claude/skills/inspect-changes-verify/SKILL.md ai/.claude/skills/review-changes-verify/SKILL.md renamed to ai/.claude/skills/inspect-changes-verify/SKILL.md

@@ -1,6 +1,7 @@
 ---
+name: inspect-changes-verify
 description: >-
-  Internal step of review-changes: verify one draft finding against the
+  Internal step of inspect-changes: verify one draft finding against the
   code and return its verdict block.
 user-invocable: false
 allowed-tools: >-
@@ -38,12 +39,12 @@ Your invocation prompt supplies, for the single finding you must verify:
   `git diff A..B`). Run it to see the reviewed change.
 - The **pre-image baseline** to re-derive provenance against, if supplied.
 - Paths of **existing prior drafts**. Use the
-  [shared prior-draft guidance](../review-changes/references/prior-drafts.md)
+  [shared prior-draft guidance](../inspect-changes/references/prior-drafts.md)
   to screen issues discovered during verification.
 - Any **experiment results** for this finding (the matching `EXP` blocks), if
   present.
 - Any **caller requirements**, if present. Apply the
-  [shared caller-requirements guidance](../review-changes/references/caller-requirements.md).
+  [shared caller-requirements guidance](../inspect-changes/references/caller-requirements.md).
 
 ## Procedure
 
@@ -53,7 +54,7 @@ files** — your tools are read and Git only.
 1. Independently confirm the finding by reading the code, following references,
    or consulting Git history. Do not hypothesize. Before deciding, run rule 3's
    in-image check from the [shared provenance
-   guidance](../review-changes/references/provenance.md): a site in neither the
+   guidance](../inspect-changes/references/provenance.md): a site in neither the
    pre-image nor the post-image is outside the reviewed content, and the rule's
    re-location half can move `Final location:` onto in-image content that
    depends on it, which is why the check belongs here rather than after the
@@ -70,7 +71,7 @@ files** — your tools are read and Git only.
    (give that as the reason) rather than keeping it as a zero-action
    SUGGESTION.
 1. Re-derive the finding's confidence from the evidence per the
-   [shared confidence guidance](../review-changes/references/confidence.md),
+   [shared confidence guidance](../inspect-changes/references/confidence.md),
    rather than adjusting the draft's number. On either outcome the number
    grades the evidence for the finding's claim, not the verdict you reach
    about it. Give the evidence that settled it in `Verification trace:`, and
@@ -79,14 +80,14 @@ files** — your tools are read and Git only.
    should usually become a `drop` — a gate on the number, not a fourth way of
    failing verification.
 1. On `keep`, re-derive the finding's severity per the
-   [shared severity guidance](../review-changes/references/severity.md), rather
+   [shared severity guidance](../inspect-changes/references/severity.md), rather
    than inheriting the draft's grade. When your severity differs from the
    draft's, say so in `Verification trace:` and give the consequence that
    settled it.
 1. On `keep`, re-derive the finding's provenance per the
-   [shared provenance guidance](../review-changes/references/provenance.md).
+   [shared provenance guidance](../inspect-changes/references/provenance.md).
    Where that guidance sends you to attribution, read the [attribution
-   procedure](../review-changes/references/provenance-attribution.md) before
+   procedure](../inspect-changes/references/provenance-attribution.md) before
    running any of its commands — several fail by printing a plausible wrong
    answer rather than an error. Yours is the only tier that runs them.
    Establish it yourself rather than inheriting the draft's tag; the draft's
@@ -119,12 +120,12 @@ Return one verdict block:
 
 Optionally append a `## Proposed new findings` section after the verdict,
 listing additional issues spotted while verifying. Follow the
-[shared output-section contract](../review-changes/references/shared-output-sections.md).
+[shared output-section contract](../inspect-changes/references/shared-output-sections.md).
 
 ## Experiment requests
 
 Follow the [shared experiment-request format and safety
-constraints](../review-changes/references/shared-output-sections.md). Request
+constraints](../inspect-changes/references/shared-output-sections.md). Request
 runtime evidence in two cases:
 
 - If the experiment is needed to **decide**, return the requests with **no**