One release and its readiness, feature by feature, worked out from the board by the rules of D113 (never by AI).

Feature = an epic in the release; issues with no epic are grouped as other. Each feature lists the checks it passes and, when it is not Ready, the reasons. For people who do not manage releases (manage: false) the gate items, baseline and scope history are left out — frontmatter.gate is [], baseline null, scope_log [] and gate / scope are null — only gate_summary is given, and added_after_baseline is false (D113 (4)). Use the numbers as they are; do not guess.

Read this before answering anything about a release ("are we ready?", "what is blocked?", "summarise for the steering meeting"). Use status, features[] (status, checks, reasons), other, counts, gate_summary and scope exactly as returned — never guess, round or invent numbers, and name the issue keys from reasons. manage: false is the member view (no gate items, no scope history) — say so rather than guessing them. You cannot create or edit a release, tick its gate, lock its baseline or mark it shipped: that is for people in the web app — an AI agent never approves a release.

You act with exactly the rights of the user who owns this token; a project you cannot see returns not_found.