What — let API error responses carry a safe, whitelisted subset of AppError.details (e.g. upgradeUrl, type) in production.
Why — billing/quota errors (402) attach an upgrade URL and a machine-readable type to AppError.details, but responses.error only serializes details in non-production. In production, clients (CLIs, agents) receive a bare message and cannot offer the upgrade path or branch on the error type.
Scope — lib/helpers/responses.js: introduce an explicit whitelist of production-safe detail keys (opt-in per key, e.g. upgradeUrl, type, retryAfter) serialized into the error envelope in all environments; everything else stays dev-only as today. Unit tests: whitelisted key passes in prod mode, non-whitelisted key stripped, dev behavior unchanged. A downstream consumer's MCP layer already forwards these details over JSON-RPC; this brings the REST envelope to parity.
Refs: none (downstream-neutral).
Created via /dev:issue
What — let API error responses carry a safe, whitelisted subset of
AppError.details(e.g.upgradeUrl,type) in production.Why — billing/quota errors (402) attach an upgrade URL and a machine-readable
typetoAppError.details, butresponses.erroronly serializesdetailsin non-production. In production, clients (CLIs, agents) receive a bare message and cannot offer the upgrade path or branch on the error type.Scope —
lib/helpers/responses.js: introduce an explicit whitelist of production-safe detail keys (opt-in per key, e.g.upgradeUrl,type,retryAfter) serialized into the error envelope in all environments; everything else stays dev-only as today. Unit tests: whitelisted key passes in prod mode, non-whitelisted key stripped, dev behavior unchanged. A downstream consumer's MCP layer already forwards these details over JSON-RPC; this brings the REST envelope to parity.Refs: none (downstream-neutral).
Created via /dev:issue