fix(security-tracker): harden the local and Jira backends after review

docs/designs/2026-10-15-security-tracker-backends-plan.md

@@ -31,7 +31,7 @@ Per the [designs convention](README.md), this plan is folded into the design and
 | 10 | Setup: Step 3a — choose backend, detect format, confirm access, write descriptor | `plugins/magpie-setup/skills/setup/config.md` | Done |
 | 11 | Taxonomy: `contract:security-tracker` in the validator, capability docs, labeler | `tools/skill-and-tool-validator`, `docs/labels-and-capabilities.md`, `.github/labeler.yml` | Done |
 | 12 | Token restamp for the edited skills; `prek run --all-files` | `measured_tokens:` frontmatter | Done |
-| 12a | vetted-ops: `[tracker]` policy, translation of every tracker operation, six new operations, refusal of the rest, tests incl. an end-to-end run against the local tracker | `tools/vetted-ops/` | Done |
+| 12a | vetted-ops: `[tracker]` policy, translation of every tracker operation, nine new operations, refusal of the rest, tests incl. an end-to-end run against the local tracker | `tools/vetted-ops/` | Done |
 | 12b | Contract: skill-command → vetted-operation → backend table; shared block points skills at vetted operations | `tools/security-tracker/contract.md`, `tools/dev/blocks/tracker-backend.md` | Done |
 | 13 | Security-skill eval suites (self-eval) — 308/313; the 5 failures come from prompt files this change does not touch | `tools/skill-evals/evals/security-*` | Done (cross-model pass to do) |
 | 14 | Create the `contract:security-tracker` label on `apache/magpie` | GitHub labels | To do (maintainer) |

docs/designs/2026-10-15-security-tracker-backends.md

@@ -56,12 +56,13 @@ named body fields, the single status rollup, attachments for the CVE record, and
    Skills never call a backend CLI.
    Every tracker `gh` command in a skill maps to a [vetted operation](../../tools/security-tracker/contract.md#from-skill-commands-to-vetted-operations),
    and vetted-ops translates that operation for the backend its policy names (`[tracker] platform`).
-   The translation is reviewed code: the policy supplies the backend's tool directory and pinned target, never a command,
+   The translation is reviewed code: the policy supplies only the pinned target, and the backend's code runs from the tool installed beside vetted-ops, never from a path a policy names,
    so the closed-shape guarantees — fixed program, unaddressable target, parameters as argv elements, bodies on stdin,
    reads unreachable from the write entry point — hold on all three backends.
-   Six operations were added so every tracker shape the skills use has a vetted form:
+   Nine operations were added so every tracker shape the skills use has a vetted form:
    `issue-create`, `issue-reopen`, `issue-list-label`, `issue-search` (plain words, no `:` qualifiers),
-   `tracker-pending` and `tracker-publish`.
+   `issue-body` and `issue-attach` (so CVE JSON generation works without GitHub),
+   `tracker-doctor` (the pre-flight on another backend), `tracker-pending` and `tracker-publish`.
    Tracker operations with no counterpart (boards, milestone administration, the roster, `rollup-fold`) refuse by name,
    and a test derives the tracker operations from the catalogue so a new one cannot go unmapped.
 5. **Skills switch through one shared block**, `tools/dev/blocks/tracker-backend.md`,
@@ -131,7 +132,7 @@ the Groovy bridge stays the general `contract:tracker` write path for the `issue
 one question in the existing batch picks the backend.
 For local files it finds the folder, runs `detect`, shows the decisions and notes, asks who can read the repository, and writes the descriptor only after that answer.
 The descriptor is the one file this step writes outside the personal layer. It is left uncommitted, and the first publish proposal includes it.
-For both non-GitHub backends the step also shows the vetted-ops `[tracker]` table and the six new caller grants, and writes them only on confirmation.
+For both non-GitHub backends the step also shows the vetted-ops `[tracker]` table and the nine new caller grants, and writes them only on confirmation.
 
 ## Alternatives considered
 

plugins/magpie-security/skills/cve-allocate/SKILL.md

@@ -21,7 +21,7 @@ argument-hint: "[issue-number] [CVE-YYYY-NNNNN]"
 capability: capability:resolve
 surface_hash: sha256:25c2286c4e159c66
 license: Apache-2.0
-measured_tokens: 7366
+measured_tokens: 7638
 ---
 
 <!-- Placeholder convention (see AGENTS.md#placeholder-convention-used-in-skill-files):
@@ -160,17 +160,26 @@ Local modifications go in the override file; framework changes go via PR to `apa
 
 <!-- BEGIN MAGPIE BLOCK: tracker-backend — generated from tools/dev/blocks/tracker-backend.md -->
 
-Read `tracker.platform` from `<project-config>/project.md` (default `github`) before the first tracker operation.
+Read `tracker.platform` from `<project-config>/project.md` before the first tracker operation; unset or `TODO` means `github`.
 With `github`, every recipe below runs as written.
 With `local-files` or `jira`, never run a `gh` command against `<tracker>`:
 look the command up in the [skill-command → vetted-operation table](../../../../tools/security-tracker/contract.md#from-skill-commands-to-vetted-operations)
 and run that vetted operation instead — `vetted-op-read` for reads, `vetted-op-tracker` for the rollup, body-field and publish operations, `vetted-op` for the other writes.
-Vetted-ops translates it for the configured backend; `<tracker>` issue numbers become the backend's IDs, and the returned `url` is the link.
+Vetted-ops translates it for the configured backend; issue numbers become the backend's IDs (`SEC-0012`, `FOOSEC-12`), and the returned `url` is the link.
 Operations on `<upstream>` (PRs, code search) do not change.
 A refusal — the backend's confidentiality guard, or an operation the backend does not have — stops the step: report it, never route around it.
 
+**Pre-flight on another backend.** The GitHub checks in Step 0 — `gh api repos/<tracker>` access, the collaborator roster, project-board ids — do not apply.
+Run the `tracker-doctor` vetted operation instead and stop on any failing check; take the security-team roster from `<project-config>/release-trains.md`, and treat the project board as disabled.
+
+**CVE JSON on another backend.** `generate-cve-json <N> --attach` reads and attaches through GitHub, so do not run it.
+Instead: save the body with the `issue-body` vetted operation (`vetted-op-read … --save cve-body issue-body <id>`),
+run `generate-cve-json --stdin --title "<issue title>" --output <workspace>/<CVE-ID>.json` on that saved file —
+adding `--review` when the issue's labels (from `issue-view`) include the release-vote label or a forward-state label the generator's config names, since `--stdin` cannot see labels and would otherwise produce DRAFT —
+and attach the result with the `issue-attach` vetted operation (`<id> <workspace>/<CVE-ID>.json <CVE-ID>.json`).
+
 **Publish local tracker changes before ending.** With `local-files`, nothing reaches the team until it is committed.
-If this run wrote to the tracker, run the `tracker-pending` vetted operation as the last step, show the changed files,
+If this run wrote to the tracker, run the `tracker-pending` vetted operation as the last step, show the changed files and any unpushed commits,
 draft a commit message naming the trackers and the action, ending with the project's commit-attribution trailer, and ask.
 Only on the user's confirmation run `tracker-publish` with that message file
 (Git: commit the tracker folder and push; SVN: commit, which publishes).

plugins/magpie-security/skills/issue-deduplicate/SKILL.md

@@ -25,7 +25,7 @@ argument-hint: "[kept-issue] [duplicate-issue]"
 capability: capability:resolve
 surface_hash: sha256:3c9f502b802d2037
 license: Apache-2.0
-measured_tokens: 5989
+measured_tokens: 6261
 ---
 
 <!-- Placeholder convention (see AGENTS.md#placeholder-convention-used-in-skill-files):
@@ -154,17 +154,26 @@ Local modifications go in the override file; framework changes go via PR to `apa
 
 <!-- BEGIN MAGPIE BLOCK: tracker-backend — generated from tools/dev/blocks/tracker-backend.md -->
 
-Read `tracker.platform` from `<project-config>/project.md` (default `github`) before the first tracker operation.
+Read `tracker.platform` from `<project-config>/project.md` before the first tracker operation; unset or `TODO` means `github`.
 With `github`, every recipe below runs as written.
 With `local-files` or `jira`, never run a `gh` command against `<tracker>`:
 look the command up in the [skill-command → vetted-operation table](../../../../tools/security-tracker/contract.md#from-skill-commands-to-vetted-operations)
 and run that vetted operation instead — `vetted-op-read` for reads, `vetted-op-tracker` for the rollup, body-field and publish operations, `vetted-op` for the other writes.
-Vetted-ops translates it for the configured backend; `<tracker>` issue numbers become the backend's IDs, and the returned `url` is the link.
+Vetted-ops translates it for the configured backend; issue numbers become the backend's IDs (`SEC-0012`, `FOOSEC-12`), and the returned `url` is the link.
 Operations on `<upstream>` (PRs, code search) do not change.
 A refusal — the backend's confidentiality guard, or an operation the backend does not have — stops the step: report it, never route around it.
 
+**Pre-flight on another backend.** The GitHub checks in Step 0 — `gh api repos/<tracker>` access, the collaborator roster, project-board ids — do not apply.
+Run the `tracker-doctor` vetted operation instead and stop on any failing check; take the security-team roster from `<project-config>/release-trains.md`, and treat the project board as disabled.
+
+**CVE JSON on another backend.** `generate-cve-json <N> --attach` reads and attaches through GitHub, so do not run it.
+Instead: save the body with the `issue-body` vetted operation (`vetted-op-read … --save cve-body issue-body <id>`),
+run `generate-cve-json --stdin --title "<issue title>" --output <workspace>/<CVE-ID>.json` on that saved file —
+adding `--review` when the issue's labels (from `issue-view`) include the release-vote label or a forward-state label the generator's config names, since `--stdin` cannot see labels and would otherwise produce DRAFT —
+and attach the result with the `issue-attach` vetted operation (`<id> <workspace>/<CVE-ID>.json <CVE-ID>.json`).
+
 **Publish local tracker changes before ending.** With `local-files`, nothing reaches the team until it is committed.
-If this run wrote to the tracker, run the `tracker-pending` vetted operation as the last step, show the changed files,
+If this run wrote to the tracker, run the `tracker-pending` vetted operation as the last step, show the changed files and any unpushed commits,
 draft a commit message naming the trackers and the action, ending with the project's commit-attribution trailer, and ask.
 Only on the user's confirmation run `tracker-publish` with that message file
 (Git: commit the tracker folder and push; SVN: commit, which publishes).

plugins/magpie-security/skills/issue-fix/SKILL.md

@@ -23,7 +23,7 @@ capability:
   - capability:resolve
 surface_hash: sha256:550eabe3b9bb3689
 license: Apache-2.0
-measured_tokens: 7163
+measured_tokens: 7435
 ---
 
 <!-- Placeholder convention (see AGENTS.md#placeholder-convention-used-in-skill-files):
@@ -131,17 +131,26 @@ Local modifications go in the override file; framework changes go via PR to `apa
 
 <!-- BEGIN MAGPIE BLOCK: tracker-backend — generated from tools/dev/blocks/tracker-backend.md -->
 
-Read `tracker.platform` from `<project-config>/project.md` (default `github`) before the first tracker operation.
+Read `tracker.platform` from `<project-config>/project.md` before the first tracker operation; unset or `TODO` means `github`.
 With `github`, every recipe below runs as written.
 With `local-files` or `jira`, never run a `gh` command against `<tracker>`:
 look the command up in the [skill-command → vetted-operation table](../../../../tools/security-tracker/contract.md#from-skill-commands-to-vetted-operations)
 and run that vetted operation instead — `vetted-op-read` for reads, `vetted-op-tracker` for the rollup, body-field and publish operations, `vetted-op` for the other writes.
-Vetted-ops translates it for the configured backend; `<tracker>` issue numbers become the backend's IDs, and the returned `url` is the link.
+Vetted-ops translates it for the configured backend; issue numbers become the backend's IDs (`SEC-0012`, `FOOSEC-12`), and the returned `url` is the link.
 Operations on `<upstream>` (PRs, code search) do not change.
 A refusal — the backend's confidentiality guard, or an operation the backend does not have — stops the step: report it, never route around it.
 
+**Pre-flight on another backend.** The GitHub checks in Step 0 — `gh api repos/<tracker>` access, the collaborator roster, project-board ids — do not apply.
+Run the `tracker-doctor` vetted operation instead and stop on any failing check; take the security-team roster from `<project-config>/release-trains.md`, and treat the project board as disabled.
+
+**CVE JSON on another backend.** `generate-cve-json <N> --attach` reads and attaches through GitHub, so do not run it.
+Instead: save the body with the `issue-body` vetted operation (`vetted-op-read … --save cve-body issue-body <id>`),
+run `generate-cve-json --stdin --title "<issue title>" --output <workspace>/<CVE-ID>.json` on that saved file —
+adding `--review` when the issue's labels (from `issue-view`) include the release-vote label or a forward-state label the generator's config names, since `--stdin` cannot see labels and would otherwise produce DRAFT —
+and attach the result with the `issue-attach` vetted operation (`<id> <workspace>/<CVE-ID>.json <CVE-ID>.json`).
+
 **Publish local tracker changes before ending.** With `local-files`, nothing reaches the team until it is committed.
-If this run wrote to the tracker, run the `tracker-pending` vetted operation as the last step, show the changed files,
+If this run wrote to the tracker, run the `tracker-pending` vetted operation as the last step, show the changed files and any unpushed commits,
 draft a commit message naming the trackers and the action, ending with the project's commit-attribution trailer, and ask.
 Only on the user's confirmation run `tracker-publish` with that message file
 (Git: commit the tracker folder and push; SVN: commit, which publishes).

plugins/magpie-security/skills/issue-import-from-md/SKILL.md

@@ -27,7 +27,7 @@ argument-hint: "[path-to-markdown-file]"
 capability: capability:intake
 surface_hash: sha256:e2437e84cdf98aa5
 license: Apache-2.0
-measured_tokens: 7095
+measured_tokens: 7367
 ---
 
 <!-- Placeholder convention (see AGENTS.md#placeholder-convention-used-in-skill-files):
@@ -156,17 +156,26 @@ Local modifications go in the override file; framework changes go via PR to `apa
 
 <!-- BEGIN MAGPIE BLOCK: tracker-backend — generated from tools/dev/blocks/tracker-backend.md -->
 
-Read `tracker.platform` from `<project-config>/project.md` (default `github`) before the first tracker operation.
+Read `tracker.platform` from `<project-config>/project.md` before the first tracker operation; unset or `TODO` means `github`.
 With `github`, every recipe below runs as written.
 With `local-files` or `jira`, never run a `gh` command against `<tracker>`:
 look the command up in the [skill-command → vetted-operation table](../../../../tools/security-tracker/contract.md#from-skill-commands-to-vetted-operations)
 and run that vetted operation instead — `vetted-op-read` for reads, `vetted-op-tracker` for the rollup, body-field and publish operations, `vetted-op` for the other writes.
-Vetted-ops translates it for the configured backend; `<tracker>` issue numbers become the backend's IDs, and the returned `url` is the link.
+Vetted-ops translates it for the configured backend; issue numbers become the backend's IDs (`SEC-0012`, `FOOSEC-12`), and the returned `url` is the link.
 Operations on `<upstream>` (PRs, code search) do not change.
 A refusal — the backend's confidentiality guard, or an operation the backend does not have — stops the step: report it, never route around it.
 
+**Pre-flight on another backend.** The GitHub checks in Step 0 — `gh api repos/<tracker>` access, the collaborator roster, project-board ids — do not apply.
+Run the `tracker-doctor` vetted operation instead and stop on any failing check; take the security-team roster from `<project-config>/release-trains.md`, and treat the project board as disabled.
+
+**CVE JSON on another backend.** `generate-cve-json <N> --attach` reads and attaches through GitHub, so do not run it.
+Instead: save the body with the `issue-body` vetted operation (`vetted-op-read … --save cve-body issue-body <id>`),
+run `generate-cve-json --stdin --title "<issue title>" --output <workspace>/<CVE-ID>.json` on that saved file —
+adding `--review` when the issue's labels (from `issue-view`) include the release-vote label or a forward-state label the generator's config names, since `--stdin` cannot see labels and would otherwise produce DRAFT —
+and attach the result with the `issue-attach` vetted operation (`<id> <workspace>/<CVE-ID>.json <CVE-ID>.json`).
+
 **Publish local tracker changes before ending.** With `local-files`, nothing reaches the team until it is committed.
-If this run wrote to the tracker, run the `tracker-pending` vetted operation as the last step, show the changed files,
+If this run wrote to the tracker, run the `tracker-pending` vetted operation as the last step, show the changed files and any unpushed commits,
 draft a commit message naming the trackers and the action, ending with the project's commit-attribution trailer, and ask.
 Only on the user's confirmation run `tracker-publish` with that message file
 (Git: commit the tracker folder and push; SVN: commit, which publishes).