chore: add defect-hardening issue template and security-remediation standard

[joctaTorres]

Cherry-picks two independent, additive commits off erh/phase-1-spawn-env-plumbing so they can land ahead of that branch's engine work, plus a dependency-pin bump to get CI green.

Commits

• security(standards): add standards/security-remediation.md — a security-remediation standard requiring that a severe/high exposure be remediated completely or not claimed remediated at all, so propose plans around partial fixes instead of letting them close the tracking issue.
• chore(github): add issue template — a Defect / hardening issue form with imperative-MUST wording rules (written in response to engine: RATCHET_BATCH_AGENT_CMD / RATCHET_EVAL_AGENT_CMD silently replace the agent in production — no gating, no notice, no journal marker, permissions bypassed #80 being worded weakly and half-fixed), plus blank_issues_enabled: false.
• security(deps): raise transitive pins past the new high advisories — see below.

The CI fix is not about this PR's content

The dependency-audit gate went red with 10 high advisories, all in transitive dev-dependencies (eslint, vitest/@vitest/coverage-v8, typescript-eslint). None are reachable from production dependencies, and none are caused by the two cherry-picked commits — the advisories were published after main's last green run, so main and every open PR fail this same gate today. Landing this unblocks them.

The existing major-keyed pins in pnpm-workspace.yaml were an earlier round of remediation for the same packages; the new advisories widened the vulnerable ranges past them:

package	was	now
brace-expansion	1.1.16 / 2.1.2 / 5.0.7	1.1.18 / 2.1.4 / 5.0.9
js-yaml	4.3.0	4.3.1
nanoid	(unpinned)	3.3.18
postcss	(unpinned)	8.5.23

postcss goes to 8.5.23 rather than the 8.5.18 the high advisory requires, which also clears the moderate incomplete-fix follow-up for the same sourceMappingURL traversal — the same patch-level bump either way.

esbuild's advisory is deliberately left open. It is low (arbitrary file read via the dev server on Windows), below the gate's high threshold, and unreachable here since build.js uses esbuild's build API and never its dev server. Clearing it would mean a minor bump of the actual build tool for no gate benefit.

Deliberately not done: switching the gate to pnpm audit --prod. That would turn the gate green by narrowing what it looks at, in the same PR that adds a standard against exactly that kind of partial remediation.

Verification

Run in a clean worktree at this commit:

• pnpm build — ok
• pnpm lint — clean
• pnpm test — 203 files / 2884 tests pass
• the gate's exact CI invocation → green: dependency-audit gate passed — no vulnerabilities at or above "high"

One earlier CI run also failed test/cli-e2e/basic.test.ts:127 on result.timedOut (a 20s CLI budget). That is a flake, not a regression: the parallel run passed all 2884 tests on identical code, and the suite passes locally.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	ratchet	89c019c	Commit Preview URL Branch Preview URL	Aug 26 2026, 09:42 PM