@izkac/forgekit 0.3.12 → 0.3.13

package/vendor/skills/thorough-code-review/reference/report-template.md

@@ -1,115 +1,115 @@
-# Code review report template
-
-**Generated, not hand-authored.** The JSON sidecar is the single source of truth; the paired markdown is produced from it by `review render --file <json>`. This file documents the structure the renderer emits — edit the JSON (and the renderer in the review CLI `lib.mjs`), never the `.md` directly.
-
-Path: `.reviews/<timestamp>-<scope-slug>-review.md` (or `-reverify.md` for fix verification), per [report-schema.json](report-schema.json).
-
----
-
-```markdown
-# Code review — {SCOPE_DESCRIPTION}
-
-**Review ID:** {REVIEW_ID}
-**Kind:** review | reverify
-**Created:** {ISO_TIMESTAMP}
-**Scope:** {SCOPE_TYPE} — {SCOPE_DETAIL}
-**Lenses:** {LENS_LIST}
-**Parent report:** {PARENT_REVIEW_ID or —}
-
-## Executive summary
-
-{TWO_TO_FOUR_SENTENCES: what was reviewed, verdict counts, overall risk posture.}
-
-### Verdict counts
-
-| Verdict | Count |
-| ------- | ----- |
-| Confirmed | |
-| Downgraded | |
-| False positive | |
-| Needs decision | |
-| Resolved | |
-| Still open | |
-| Partially fixed | |
-| Regressed | |
-
-### Top actions
-
-1. {Highest priority confirmed/critical item}
-2. {Second}
-3. {Third}
-
----
-
-## Critical
-
-### {F-001}: {Short title}
-
-- **Lens:** security
-- **Location:** `path:line`
-- **Severity:** critical {or `minor (was important)` when downgraded}
-- **Verdict:** confirmed
-- **Claim:** ...
-- **Reason:** ...
-- **Second skeptic:** {only for dangerous-quadrant findings} verdict — reason
-
-{Repeat per finding}
-
----
-
-## Important
-
-{Same structure}
-
----
-
-## Minor
-
-{Same structure}
-
----
-
-## Needs decision
-
-{Architectural items with `needs_decision` verdict — link ADRs if applicable}
-
----
-
-## Coverage ledger
-
-{From the recall pass — files reviewed/skipped and active lenses that produced
-no findings, each with a one-line reason. Omitted when no `coverage` object.}
-
----
-
-## Appendix A — Rejected findings (false positives)
-
-### {F-00X}: {Short title}
-
-- **Claim:** ...
-- **Why rejected:** ...
-
----
-
-## Appendix B — Dedupe pre-flight
-
-{If smells lens ran; else omit section}
-
-| ID | Location | Claim |
-| -- | -------- | ----- |
-| dup-001 | ... | ... |
-
----
-
-## Appendix C — Method
-
-- Phase 1: Scout pass ({N} tentative findings)
-- Phase 2: Adversarial skeptic verification (severity-routed, budgeted)
-- {If reverify: Re-verification against parent report {PARENT_ID}}
-```
-
-## JSON sidecar
-
-Author the `.json` (the source of truth), then `review render` to (re)generate this markdown and `review export` to validate before handing off in CI contexts.
-
-Main report body includes only `confirmed` and `downgraded` findings (initial review) or `still_open`, `partially_fixed`, `regressed` (reverify). Render places `false_positive` in Appendix A automatically.
+# Code review report template
+
+**Generated, not hand-authored.** The JSON sidecar is the single source of truth; the paired markdown is produced from it by `review render --file <json>`. This file documents the structure the renderer emits — edit the JSON (and the renderer in the review CLI `lib.mjs`), never the `.md` directly.
+
+Path: `.reviews/<timestamp>-<scope-slug>-review.md` (or `-reverify.md` for fix verification), per [report-schema.json](report-schema.json).
+
+---
+
+```markdown
+# Code review — {SCOPE_DESCRIPTION}
+
+**Review ID:** {REVIEW_ID}
+**Kind:** review | reverify
+**Created:** {ISO_TIMESTAMP}
+**Scope:** {SCOPE_TYPE} — {SCOPE_DETAIL}
+**Lenses:** {LENS_LIST}
+**Parent report:** {PARENT_REVIEW_ID or —}
+
+## Executive summary
+
+{TWO_TO_FOUR_SENTENCES: what was reviewed, verdict counts, overall risk posture.}
+
+### Verdict counts
+
+| Verdict | Count |
+| ------- | ----- |
+| Confirmed | |
+| Downgraded | |
+| False positive | |
+| Needs decision | |
+| Resolved | |
+| Still open | |
+| Partially fixed | |
+| Regressed | |
+
+### Top actions
+
+1. {Highest priority confirmed/critical item}
+2. {Second}
+3. {Third}
+
+---
+
+## Critical
+
+### {F-001}: {Short title}
+
+- **Lens:** security
+- **Location:** `path:line`
+- **Severity:** critical {or `minor (was important)` when downgraded}
+- **Verdict:** confirmed
+- **Claim:** ...
+- **Reason:** ...
+- **Second skeptic:** {only for dangerous-quadrant findings} verdict — reason
+
+{Repeat per finding}
+
+---
+
+## Important
+
+{Same structure}
+
+---
+
+## Minor
+
+{Same structure}
+
+---
+
+## Needs decision
+
+{Architectural items with `needs_decision` verdict — link ADRs if applicable}
+
+---
+
+## Coverage ledger
+
+{From the recall pass — files reviewed/skipped and active lenses that produced
+no findings, each with a one-line reason. Omitted when no `coverage` object.}
+
+---
+
+## Appendix A — Rejected findings (false positives)
+
+### {F-00X}: {Short title}
+
+- **Claim:** ...
+- **Why rejected:** ...
+
+---
+
+## Appendix B — Dedupe pre-flight
+
+{If smells lens ran; else omit section}
+
+| ID | Location | Claim |
+| -- | -------- | ----- |
+| dup-001 | ... | ... |
+
+---
+
+## Appendix C — Method
+
+- Phase 1: Scout pass ({N} tentative findings)
+- Phase 2: Adversarial skeptic verification (severity-routed, budgeted)
+- {If reverify: Re-verification against parent report {PARENT_ID}}
+```
+
+## JSON sidecar
+
+Author the `.json` (the source of truth), then `review render` to (re)generate this markdown and `review export` to validate before handing off in CI contexts.
+
+Main report body includes only `confirmed` and `downgraded` findings (initial review) or `still_open`, `partially_fixed`, `regressed` (reverify). Render places `false_positive` in Appendix A automatically.

package/vendor/skills/thorough-code-review/reference/severity-rubric.md

@@ -1,49 +1,49 @@
-# Severity rubric
-
-Calibrate severity before Phase 2. Skeptics may **downgrade** with evidence; upgrade only with new evidence.
-
-## Critical
-
-Must fix before merge or production. Examples:
-
-- Exploitable auth bypass or IDOR on production path
-- SQL/command injection with attacker-controlled input reaching sink
-- Secret or credential committed or logged
-- Data loss, corruption, or double-charge on money paths
-- Broken idempotency causing duplicate financial side effects
-
-## Important
-
-Should fix soon; real defect or serious debt with plausible trigger. Examples:
-
-- Logic bug on common edge case (empty input, race under concurrency)
-- Missing authorization on sensitive internal endpoint (if not ADR-accepted)
-- Error responses cached by idempotency middleware
-- Test gap on behaviour-critical path
-- Significant duplication that must stay in sync (rule of three)
-
-## Minor
-
-Nice to have; low likelihood or defense-in-depth. Examples:
-
-- Naming inconsistency
-- Missing progress indicator
-- Unlikely edge case with graceful degradation
-- Style nits not affecting behaviour
-- Pre-existing file size (only flag growth **this change** introduced)
-
-## Needs decision (not a severity)
-
-Architectural or policy trade-off — route to `NEEDS_DECISION` verdict, not Critical by default.
-
-Examples: accepted inter-service trust model per ADR, intentional public surface, documented technical debt.
-
-## Project-specific downgrades
-
-Before marking Critical/Important on themes covered by the project's accepted-risk digest, read that digest (and ADRs):
-
-- Formally accepted trust boundaries (e.g. LAN-only HMAC)
-- Documented intentional broad access patterns
-- Actor/header trust models bound by an upstream session
-
-Re-flag only if a listed re-open trigger has fired. See [accepted-risks.md](accepted-risks.md) and [examples/accepted-risks-janus.md](../examples/accepted-risks-janus.md).
+# Severity rubric
+
+Calibrate severity before Phase 2. Skeptics may **downgrade** with evidence; upgrade only with new evidence.
+
+## Critical
+
+Must fix before merge or production. Examples:
+
+- Exploitable auth bypass or IDOR on production path
+- SQL/command injection with attacker-controlled input reaching sink
+- Secret or credential committed or logged
+- Data loss, corruption, or double-charge on money paths
+- Broken idempotency causing duplicate financial side effects
+
+## Important
+
+Should fix soon; real defect or serious debt with plausible trigger. Examples:
+
+- Logic bug on common edge case (empty input, race under concurrency)
+- Missing authorization on sensitive internal endpoint (if not ADR-accepted)
+- Error responses cached by idempotency middleware
+- Test gap on behaviour-critical path
+- Significant duplication that must stay in sync (rule of three)
+
+## Minor
+
+Nice to have; low likelihood or defense-in-depth. Examples:
+
+- Naming inconsistency
+- Missing progress indicator
+- Unlikely edge case with graceful degradation
+- Style nits not affecting behaviour
+- Pre-existing file size (only flag growth **this change** introduced)
+
+## Needs decision (not a severity)
+
+Architectural or policy trade-off — route to `NEEDS_DECISION` verdict, not Critical by default.
+
+Examples: accepted inter-service trust model per ADR, intentional public surface, documented technical debt.
+
+## Project-specific downgrades
+
+Before marking Critical/Important on themes covered by the project's accepted-risk digest, read that digest (and ADRs):
+
+- Formally accepted trust boundaries (e.g. LAN-only HMAC)
+- Documented intentional broad access patterns
+- Actor/header trust models bound by an upstream session
+
+Re-flag only if a listed re-open trigger has fired. See [accepted-risks.md](accepted-risks.md) and [examples/accepted-risks-janus.md](../examples/accepted-risks-janus.md).

package/vendor/skills/thorough-code-review/reference/signals-preflight.md

@@ -1,55 +1,55 @@
-# Signals pre-flight
-
-Ground the scout in real tool output **before** reading code by hand. Tool-confirmed problems are facts, not guesses — they raise recall on the smells / contracts / tests / errors lenses and cut hallucinated findings.
-
-## Steps
-
-1. **Plan the commands.** Run the planner for the review scope:
-
-   ```bash
-   review signals --type branch          # detect changed files vs main
-   review signals --type uncommitted      # working tree + untracked
-   review signals --paths services/persona,services/mercury
-   review signals --json                  # machine-readable
-   ```
-
-   It maps the scope to the **workspaces that own it** and prints the exact per-workspace grounding commands (this monorepo has no root typecheck — each package owns its scripts).
-
-2. **Run the grounding commands** it lists, e.g.:
-
-   ```bash
-   npm run typecheck --workspace=your-workspace
-   npm run test --workspace=your-workspace
-   npm run lint --workspace=your-workspace
-   ```
-
-   Add, when available and relevant to the scope:
-
-   - `npx knip` (or the repo's dead-code script) — unused exports / dead code → **smells**
-   - the service's OpenAPI **route-parity** test — mounted routes vs registry → **contracts**
-
-3. **Convert real failures to grounded tentative findings.** A type error, failing test, lint error, or dead export becomes an `F-###` (or `dup-###`) tentative finding with `confidence: high` and the tool output as `evidence`. Do **not** invent findings the tools did not support.
-
-4. **Record what ran** in the report JSON `signals` object so the grounding is auditable:
-
-   ```json
-   "signals": {
-     "tools": [
-       { "name": "typecheck your-workspace", "status": "pass" },
-       { "name": "test your-workspace", "status": "fail", "summary": "1 failing: consent.test.ts" },
-       { "name": "knip", "status": "skipped", "summary": "not in scope" }
-     ]
-   }
-   ```
-
-## Rules
-
-- Read-only. The pre-flight never edits code.
-- Scope-bound. Run tools for the **workspaces in scope**, not the whole repo, unless the scope is repo-wide.
-- A passing tool is signal too — it lets the coverage pass mark a lens genuinely exercised.
-- If a tool can't run (missing script, environment), record it `skipped` with a reason rather than omitting it.
-
-## Notes
-
-- The **dedupe pre-flight** (smells lens) is the same pattern with the `dedupe` skill as the tool; keep emitting `dup-###` findings and the `dedupe_preflight` summary.
-- Grounded findings at `critical`/`important` still go through Phase 2 — a failing test might be an intentional WIP. Below `important`, skip the skeptic: the tool output is the proof; the orchestrator just checks for intentional-WIP signals (commit message, TODO, user context) and records the verdict directly.
+# Signals pre-flight
+
+Ground the scout in real tool output **before** reading code by hand. Tool-confirmed problems are facts, not guesses — they raise recall on the smells / contracts / tests / errors lenses and cut hallucinated findings.
+
+## Steps
+
+1. **Plan the commands.** Run the planner for the review scope:
+
+   ```bash
+   review signals --type branch          # detect changed files vs main
+   review signals --type uncommitted      # working tree + untracked
+   review signals --paths services/persona,services/mercury
+   review signals --json                  # machine-readable
+   ```
+
+   It maps the scope to the **workspaces that own it** and prints the exact per-workspace grounding commands (this monorepo has no root typecheck — each package owns its scripts).
+
+2. **Run the grounding commands** it lists, e.g.:
+
+   ```bash
+   npm run typecheck --workspace=your-workspace
+   npm run test --workspace=your-workspace
+   npm run lint --workspace=your-workspace
+   ```
+
+   Add, when available and relevant to the scope:
+
+   - `npx knip` (or the repo's dead-code script) — unused exports / dead code → **smells**
+   - the service's OpenAPI **route-parity** test — mounted routes vs registry → **contracts**
+
+3. **Convert real failures to grounded tentative findings.** A type error, failing test, lint error, or dead export becomes an `F-###` (or `dup-###`) tentative finding with `confidence: high` and the tool output as `evidence`. Do **not** invent findings the tools did not support.
+
+4. **Record what ran** in the report JSON `signals` object so the grounding is auditable:
+
+   ```json
+   "signals": {
+     "tools": [
+       { "name": "typecheck your-workspace", "status": "pass" },
+       { "name": "test your-workspace", "status": "fail", "summary": "1 failing: consent.test.ts" },
+       { "name": "knip", "status": "skipped", "summary": "not in scope" }
+     ]
+   }
+   ```
+
+## Rules
+
+- Read-only. The pre-flight never edits code.
+- Scope-bound. Run tools for the **workspaces in scope**, not the whole repo, unless the scope is repo-wide.
+- A passing tool is signal too — it lets the coverage pass mark a lens genuinely exercised.
+- If a tool can't run (missing script, environment), record it `skipped` with a reason rather than omitting it.
+
+## Notes
+
+- The **dedupe pre-flight** (smells lens) is the same pattern with the `dedupe` skill as the tool; keep emitting `dup-###` findings and the `dedupe_preflight` summary.
+- Grounded findings at `critical`/`important` still go through Phase 2 — a failing test might be an intentional WIP. Below `important`, skip the skeptic: the tool output is the proof; the orchestrator just checks for intentional-WIP signals (commit message, TODO, user context) and records the verdict directly.

package/vendor/templates/adr/README.md

@@ -1,7 +1,7 @@
-# Architecture Decision Records
-
-Canonical index of ADRs for this project. See [decisions.md]({{DECISIONS_REL}}) for the full convention (when to write, template, cross-links with OpenSpec).
-
-| #     | Title | Status | Date |
-| ----- | ----- | ------ | ---- |
-| <!-- add rows as ADRs are written: | NNNN | Title | Status | YYYY-MM-DD | --> |
+# Architecture Decision Records
+
+Canonical index of ADRs for this project. See [decisions.md]({{DECISIONS_REL}}) for the full convention (when to write, template, cross-links with OpenSpec).
+
+| #     | Title | Status | Date |
+| ----- | ----- | ------ | ---- |
+| <!-- add rows as ADRs are written: | NNNN | Title | Status | YYYY-MM-DD | --> |