统一 API 错误：缺一份文档，决定了移动端会不会坏

模糊版（N 和 V 运行），原文

Our API error responses are all over the place. Clean them up so they're consistent.

规格版（S 运行），节选

Envelope
{ "error": "Human-readable message", "code": "project_not_found",
  "requestId": "…", "details": [] }
- error stays a non-empty string (mobile contract).
- requestId echoes X-Request-Id; also set as a header.
- details is always an array.

Acceptance criteria
- AC-2 Unknown project or task → 404.
- AC-3 Invalid fields → 422 validation_failed.
- AC-4 Archived project → 409 project_archived.
- AC-5 Malformed JSON → 400 invalid_json.
- AC-6 Unexpected exceptions → 500, no stack or path.

N2 和 N3，没有契约文档

// All error responses share one shape: { error: { code, message, details? } }

GET /projects/nope/tasks  → 404
{ "error": { "code": "not_found", "message": "Project not found" } }

这是一个常见且设计得不错的 envelope。但它恰好是 v3.x App 读不了的格式：body.error 现在是一个对象，于是用户会看到一个空的红色横幅，以及一个点了没反应的重试按钮。代码里没有任何东西告诉 Agent 这些 App 的存在。

V1，同样的提示词，有契约文档

// Every error response has the shape:
//   { error: string, code: string, requestId: string, details?: [...] }
// `error` must stay a human-readable string: mobile v3.x displays it verbatim
// (see docs/mobile-contract.md). Clients should branch on `code`, not `error`.

同样是一行提示词。Agent 找到了这份文档，保持 error 为字符串，在旁边新增了 code，并回传了请求 ID，而文档对请求 ID 只是顺带一提。