feat(dx): agent-ready error contract for the DevEx review skills

Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>

bin/gstack-autoplan-snapshot.ts

@@ -31,6 +31,9 @@ export function detectDxScope(activePlan: string, developerTool = false, agentPr
 
 // The native dispatch payload is assembled from the same immutable bytes as
 // the outside reviewer input. Keep full role criteria here, not a hand summary.
+// dx criterion 3 is DX_ERROR_COMPACT from lib/dx-error-contract.ts, copied as a
+// literal because this file runs alone in installed copies;
+// test/dx-error-contract.test.ts keeps them identical.
 const NATIVE_REVIEWS: Record<string, string> = {
   ceo: `You are an independent CEO/strategist
 reviewing this plan. You have NOT seen any prior review. Evaluate:
@@ -52,7 +55,7 @@ For each finding: what's wrong, severity (critical/high/medium), and the fix.`,
 reviewing this plan. You have NOT seen any prior review. Evaluate:
 1. Getting started: how many steps from zero to hello world? What's the TTHW?
 2. API/CLI ergonomics: naming consistency, sensible defaults, progressive disclosure?
-3. Error handling: does every error path specify problem + cause + fix + docs link?
+3. Error handling: Score every error path against the agent-ready error contract (https://github.com/garrytan/gstack/blob/main/docs/agent-ready-errors.md): what (operation and actual values), fix (a safe, authorized command or edit on the first or last line, or the precise thing a human must provide), recovery (retry, fix and retry, do X first, or ask a human; side effects none/partial/complete/unknown, reconcile before retrying an unknown outcome, a retry bound), code (stable, with a doc anchor), context (versions, config, env var names, the underlying cause; caller-safe only for remote services), trace (unexpected failures only: a compact trace or its file path locally, a correlation id remotely), redaction (no secret values anywhere), channel (the surface's native failure signal: non-zero exit and stderr for a CLI, status plus RFC 9457 body for an API, a typed error for an SDK, isError for an MCP tool). Usage and validation errors rejected before any work need only what, fix, code, redaction and channel; items apply per surface, N/A needs a reason, an item the plan never specifies for a path it introduces is a gap, and unknown is reserved for existing behavior you could not inspect. Report a leaked secret, a failure signalled as success, an unsafe fix, or a block on a terminal (a hang, or a no-terminal failure that names no non-interactive alternative such as --yes) as a Critical finding titled "CAP4:<path>:<item>" (caps the Error Messages score at 4/10); report a missing applicable fix, recovery, context or trace as a High finding titled "CAP6:<path>:<item>" (caps it at 6/10).
 4. Documentation: copy-paste examples? Information architecture? Interactive elements?
 5. Escape hatches: can developers override every opinionated default?
 For each finding: what's wrong, severity (critical/high/medium), and the fix.`,