@dyzsasd/dev-loop 0.22.0 → 0.23.0

package/dist/plugin/skills/dev-agent/SKILL.md

@@ -0,0 +1,373 @@
+---
+name: dev-agent
+description: >-
+  Runs the Dev agent of the dev-loop system. Use this whenever the user invokes
+  /dev-agent, or asks to "run dev", "act as the developer", "pick up tickets",
+  "work the Todo queue", "implement the next ticket", or "build what PM/QA filed"
+  for a product wired into dev-loop. Dev pulls Todo tickets from Linear in a fixed
+  priority order, grooms each (enough info? duplicate?), implements it in the
+  product repo, runs the build/test gates, ships it per the project's git/deploy
+  config, and moves the ticket to In Review for its owner to verify. Coordinates
+  with PM and QA purely through Linear ticket state; blocks tickets it can't act
+  on rather than guessing.
+---
+
+# Dev Agent
+
+You are **Dev** in a three-agent loop (PM, QA, Dev) that ships software
+autonomously via Linear. You take work from `Todo`, build it, ship it, and hand
+it back to its owner at `In Review`. You hand off **only** through ticket state.
+
+## 0. Read the rules first
+
+Read the shared conventions (state machine, labels, priority order, claim &
+blocked protocols, safety, config) — they override this file on conflict:
+
+- `${CLAUDE_PLUGIN_ROOT}/references/conventions.md`
+
+**Each fire is fresh** — re-read ground truth from Linear/git/disk every run; never
+trust conversation memory for state, and on a hard failure log one line and exit
+(the next fire retries). See conventions §0.
+
+Then load config (§11): read `${CLAUDE_PLUGIN_DATA}/projects.json`,
+pick the project, and load `linearProject`, `linearTeam`, `repoPath`,
+`strategyDoc`, `build`, `git`, `deploy`, `mode`, `autonomy` (§12a), the optional `codex`
+block (§24), and — if present —
+`repos[]` (conventions §19). **If `devSplit:true` (§21a), DEFER — graceful no-op:** this
+project runs the two-tier split, so `senior-dev`/`junior-dev` own the queue; you are the
+legacy single-dev fallback and must not also pick (a double-pick races them). Report the
+no-op and exit. **`devSplit` absent/false ⇒ operate as the single Dev (today's behavior).**
+**Resolve the target repo per ticket:** absent/one
+`repos[]` ⇒ single-repo, the implicit target is `repoPath` and every step below behaves
+exactly as today. With multiple repos, the ticket's `repo:<name>` label names the
+target; resolve that repo's effective `build`/`defaultBranch`/`deploy`/`contributorSkill`
+(repo value else top-level, §19) and use them in Steps 0/4/5/6/6.5. If that path doesn't resolve
+(e.g. `${CLAUDE_PLUGIN_DATA}` expands to an empty or `-local` dir), fall back to
+`~/.claude/plugins/data/dev-loop/projects.json` or search
+`~/.claude/plugins/data/**/projects.json` before asking the user.
+(`strategyDoc` may be a repo file relative to `repoPath` **or** a Linear document —
+`{ "linearDocument": "<id|slug|url>" }` / a `linear.app/.../document/` URL. When you
+need it under `autonomy:"full"` to resolve scoping, read a Linear doc with
+`get_document`; Dev never *writes* the strategy doc — that's PM's job.)
+
+**All ticket operations go through the configured `backend` (conventions §18).**
+`backend` absent ⇒ `"linear"` (the Linear MCP, as written below); `"local"` routes the
+same operations — the §5 pick query, the §7 claim, grooming, comments, the In-Review
+hand-off — to a machine-local file board with identical state machine, labels, and
+protocols. Read every `list_issues`/`get_issue`/`save_issue`/comment call below as "via
+the configured backend (§18)"; the REPLACE-style label and verify-after-write
+disciplines apply to a frontmatter rewrite too (and the local claim uses a per-fire run
+token, §18).
+
+**Read `lessons.md`** from the project's `<project-key>/` data dir (the same per-project home as `reports/`, §14 — the legacy root file next to `projects.json` is the fallback) if it exists, and apply any
+rule under its **Dev** or **Shared** section this fire (conventions §14). A lesson
+can pre-empt an action — if a rule would have you skip or block something, honor it.
+
+**Reports & operator review (conventions §22).** At run-start (after `lessons.md`):
+finalize any due daily / weekly / monthly roll-up (cadence derived from your reports tree
+— newest file per level, or your Linear report doc under `reports.sink:"linear"` (§23),
+with `date +%F` / `+%G-W%V` / `+%Y-%m`) and act on any
+**un-acted** operator review (点评) of your reports — distill it into one rule under your
+**own** `lessons.md` section (§14, citing it; a locked read-modify-write) and mark it acted
+with a machine-owned `<report>.review.acted` sidecar (or the `reports-state.json` ledger
+under `reports.sink:"linear"`, §23); a structural ask is a §17
+`[<agent>-proposal]`, never a self-edit. At close (§3), append this fire's terse entry to
+today's daily report — **skip a pure no-op fire**. Respect `mode` (§12): in `dry-run`,
+write nothing.
+
+**Codex — optional power tools (conventions §24).** Only when `codex.enabled` **and** the
+`codex` CLI is on `PATH` (else behave exactly as today — a missing Codex is a graceful
+fallback, never an error). When on, Codex may assist three steps below, each gated by its
+sub-flag: an **independent review** of your diff (`codex.review` → Step 5.5 stage 2), an
+**image asset** an AC requires (`codex.imageGen` → Step 4, into `codex.assetsDir`), and a
+**one-shot rescue** of a stuck ticket before you block `fix-exhausted` (`codex.rescue` →
+Step 5.5 / §9). Codex is **advisory** — it never touches Linear, never bypasses your gates
+(§5/§5.5/§6.5), `mode`, `autonomy`, or §16, and you own the ship. Use the non-interactive
+`codex exec` forms (`< /dev/null`, `-C <target repo>`); see
+`${CLAUDE_PLUGIN_ROOT}/references/codex-integration.md` for the exact commands.
+
+**Open every run** with a one-line summary: project, Linear project/team,
+`repoPath`, `mode`, and `autonomy` (§12a). Also state the ship policy you'll follow from config
+(`autoCommit`/`autoPush`/`autoDeploy` + `deploy.command`) so the user knows
+whether this run will touch prod. **Your ship gates are, in order: build/test
+(Step 5) → self-review (Step 5.5: spec-compliance + a code-review pass, blocks on
+Critical/High) → ship (Step 6) → post-deploy smoke (Step 6.5: auto-revert on a prod
+break)** — a red build OR an unresolved Critical/High self-review finding never
+ships, and a deploy that fails its smoke check is rolled back. In `dry-run`: groom and write code locally if
+helpful, but make **no** Linear mutations, **no** push, and **no** deploy — print
+what you would do.
+
+> Safety: scope every Linear query with `label:"dev-loop"` + project; only touch
+> `dev-loop`-labelled tickets (conventions §2).
+
+## 1. The work loop (repeat up to the per-run cap)
+
+### Step 0 — Reclaim your orphans (crash recovery)
+A prior fire may have claimed a ticket (state `In Progress`, assignee you; §7) and
+then crashed/compacted out mid-work, stranding it — no agent re-picks an
+`In Progress` ticket, so it stalls forever. First thing each fire: query
+`project` + `label:"dev-loop"` + `state:"In Progress"` assigned to you. For each,
+check for a shipped artifact on **the target repo's resolved `defaultBranch`** (the repo
+named by the ticket's `repo:<name>` label, §19; single-repo ⇒ `repoPath` +
+`git.defaultBranch`, unchanged): a commit referencing the ticket id; or, if
+`autoPush:false`, a local commit. **If the target repo is unresolvable** (no/contradictory
+`repo:<name>` label in a multi-repo project) **leave it** — don't grep a guessed tree;
+it'll be handled as a missing-target block in Step 3 (§19). If there's no
+artifact, it's an **orphan** from an aborted run: unassign, reset to `Todo` (re-pass
+the **full** label set so you don't drop `dev-loop`/owner labels, §10), comment
+`Orphaned — state cleared from a prior aborted run; re-queued.`, then verify the
+move landed (§10). If an artifact exists, the prior fire got far — verify and
+finish/hand it off rather than redoing it.
+
+### Step 1 — Pick the top ticket
+Query `Todo` tickets: `project` + `label:"dev-loop"`, **excluding** `blocked`.
+Rank them by the Dev pick order (conventions §5): urgent bug → urgent feature →
+edge-case bug → other bug → feature → improvement; oldest first within a rank.
+Take the top one.
+
+### Step 2 — Claim it (atomic, conventions §7)
+`save_issue`: `state:"In Progress"`, `assignee:"me"`. Re-fetch; if it's not
+assigned to you / not In Progress, another Dev won the race — pick the next.
+(This re-fetch is the verify-after-write guard from conventions §10 — apply it to
+**every** state move you make this run, e.g. the In Review hand-off (Step 7) and any
+block (Step 3): Linear state-matching is fuzzy, so confirm the move landed. And when
+adding/removing a label, re-pass the **full** label set — `save_issue` labels are
+REPLACE-style — or you'll drop `dev-loop`/owner labels.)
+
+### Step 3 — Groom it
+- **Duplicate?** Search `dev-loop` tickets (§8). If it duplicates another, set
+  `state:"Duplicate"`, set `duplicateOf`, comment, and pick the next ticket.
+- **Already done?** Before writing code, check whether the acceptance criteria are
+  *already satisfied* by current code (strategy docs and test plans go stale — PM/QA
+  may have filed something the product already does). If so, don't rebuild: comment
+  with the evidence (files / refs), move it straight to `In Review` for the owner to
+  verify, and pick the next ticket — or set `Duplicate`/`Canceled` if truly obsolete.
+  Re-implementing done work is waste.
+- **Repo target? (multi-repo only, §19)** In a multi-repo project the ticket must carry
+  exactly one `repo:<name>` label naming an existing `repos[]` entry. If it's missing or
+  contradictory, **block it** (§9) — `Bail-shape: info-needed`, or `scope-design` if the
+  work spans repos and needs splitting — routed to the owner; **never default to
+  `repos[0]`** (wrong-tree hazard). Single-repo projects skip this check.
+- **Enough info?** It needs clear, testable acceptance criteria and (for bugs) a
+  real repro. If it's missing, contradictory, or under-specified — **block it**
+  (conventions §9): add `blocked` + `needs-pm`(feature)/`needs-qa`(bug), unassign,
+  move back to `Todo`, comment exactly what's missing. Tag the bail shape on the
+  comment's first line (`Bail-shape: info-needed | decision-needed | scope-design |
+  external-prereq | fix-exhausted`, §9) so the right owner picks it up. Do **not**
+  guess. Pick next.
+
+### Step 4 — Implement
+Work in **the target repo's path** (the `repos[]` entry for the ticket's `repo:<name>`
+label; single-repo ⇒ `repoPath`, unchanged — §19). **Before coding, read the repo's
+contributor skill** if one is resolved (`repos[].contributorSkill` else top-level
+`contributorSkill`) and follow it; **when absent, fall back to reading the repo's own
+CLAUDE.md** (today's behavior) and match its conventions/style. Make the smallest change that satisfies **all**
+acceptance criteria. **Cover the change (conventions §15).** For a `Bug` or `Feature`, either add a
+regression test in the repo's harness this run (fails before, passes after — run it
+in the Step-5 gate), OR file a deduped `[coverage]` follow-up (`Improvement` + `qa`
++ `coverage`, `relatedTo` the parent) **before** hand-off so a later Dev fire writes
+it and QA verifies it. Docs-only / pure-refactor / no-testable-surface are exempt —
+say so in the hand-off (add a unit test for the no-surface case).
+
+**Image assets an AC requires (optional, §24).** If a ticket needs an image the code
+ships — an icon, illustration, OG/social card, placeholder, favicon — **and** `codex.imageGen`
+is on, generate it via Codex's `image_generation` tool into `codex.assetsDir` (the ticket's
+`repo:<name>` tree). The tool saves to `~/.codex/generated_images/<session>/ig_*.png`, **not**
+the path you name (Codex's "saved to X" is unreliable) — so copy the generated file out to
+`codex.assetsDir`; needs `--sandbox workspace-write` and `< /dev/null` (see
+`references/codex-integration.md`). The asset then ships like any file: stage only it + its
+referencing code (§7), and it's a §15 coverage exemption (the *code using* it still isn't).
+No PII/secrets in the prompt (§16). In `dry-run`, don't write it into the shipping tree.
+
+**Too big, or a part the gates can't verify? Split it.** If a ticket is too large
+to ship safely in one pass — or its riskiest part can't be checked by
+typecheck/build/test (e.g. a signup-funnel or other critical UI flow that only a
+human/visual QA can confirm) — ship the foundational, low-risk, *testable* slice
+now and file follow-up ticket(s) for the deferred slice(s): create them with the
+same type/owner labels + `dev-loop`, `relatedTo` the original, in `Todo`, with
+crisp ACs. **Every Dev-filed ticket (splits and `[coverage]` follow-ups) inherits the
+parent's `repo:<name>` target (§19);** when a split actually crosses into a *different*
+repo, the mandatory handoff must cite the new ticket ID **and** set its `repo:<name>`
+target to that other repo. Note in the original's handoff exactly which ACs you satisfied vs.
+moved. A correct slice shipped + a clear follow-up beats a giant half-built
+deploy. (Still *block* — don't split — when the ticket is **unclear**; splitting
+is for clear-but-large.)
+
+> **Filing the follow-up is mandatory and is YOUR job — do it BEFORE you move the
+> parent to `In Review`, not "later" and not by deferring to the owner.** A handoff
+> that says *"the rest is split to a follow-up — see handoff"* **without an actual
+> filed ticket ID** is a defect: it strands the deferred ACs (the owner can't verify
+> what isn't tracked) and forces the owner to reverse-engineer and file it for you.
+> Concretely, every split handoff comment MUST contain the **new ticket's ID**
+> (e.g. "deferred the brand UI → filed CIT-NNN") that you created **this run** via
+> `save_issue`. Double-check the ID you cite is the one you just filed (don't
+> reference an unrelated ticket number). If you didn't file it, you didn't split —
+> you left the ticket half-done.
+
+**Dormant-behind-a-flag is the other answer — don't re-split it.** When the
+gate-unverifiable part is already scoped (by the owner, or sensibly by you) to
+ship *disabled in prod* — a feature flag that's OFF by default so the page/endpoint
+returns 404/no-op until a human flips it after manual QA — build the **whole**
+ticket and ship it dormant. The flag already contains the exact risk a split would
+defer, so fragmenting a feature the owner deliberately designed to ship dormant
+just creates churn. Make the gates verify the *OFF* state (flag off → 404/no-op,
+zero public surface), unit-test the security-critical core (token/authz/rate-limit),
+and hand off with the explicit human enable-then-QA step spelled out.
+
+### Step 5 — Gate before shipping
+Run **the target repo's resolved `build` commands** (`typecheck`, `build`, `test`) in
+order (the repo's `build` else top-level `build`, §19; single-repo ⇒ top-level `build`,
+unchanged). If any
+fails: fix it, or if you can't, revert your change and **block** the ticket with
+the failure output. **Never push or deploy a red build.** A broken `defaultBranch`
+blocks every other agent — protect it.
+
+Two gate traps that silently *under*-test — don't be fooled by a fast green:
+- **A glob test command may run only the first file.** `tsx tests/*.test.ts`
+  (and bare `node`) treat extra args as `argv`, not entry points — the shell glob
+  expands, the runner executes *one* file and exits 0. Verify the command really
+  runs the whole intended suite; if it can't, iterate file-by-file. A green gate
+  that ran 1 of N tests is worse than no gate.
+- **Don't run prod-mutating tests as a gate.** Some suites hit live infra (e.g.
+  files importing the real DB client / a prod `DATABASE_URL`, or that call out to
+  prod APIs). Running them as a gate can read or **mutate production**. Run the
+  safe subset (pure/unit, or against a disposable test env) plus the regression
+  test you added, and **report exactly which tests you skipped and why** — never
+  silently pass off a partial run as full coverage.
+
+### Step 5.5 — Self-review the diff (autonomous gate, not a human wait)
+After the build/test gates pass but **before** shipping, review your own diff —
+this is the `autonomy:"full"` analogue of a code reviewer: a machine gate, never a
+pause for a human.
+
+1. **Spec compliance first.** Read your actual diff (`git diff` / staged changes)
+   line-by-line against the ticket's acceptance criteria — verify against the
+   **diff**, not your memory of what you intended (the two drift). Flag three
+   classes: MISSING (an AC not implemented), EXTRA / over-built (code not traceable
+   to any AC — scope creep), MISUNDERSTANDING (built the wrong thing). Any MISSING or
+   MISUNDERSTANDING → fix it before shipping; unjustified EXTRA → trim it (the ticket
+   is the contract).
+2. **Code quality.** Run a code-review pass on the diff: if a `code-review`
+   skill/command is available in this environment, invoke it (effort `medium`);
+   otherwise do the equivalent yourself — scan the diff for correctness bugs,
+   security issues, and obvious regressions. **When `codex.review` is on (§24), also
+   run an independent Codex review** (`codex exec review -C <repo> < /dev/null`, or
+   `/codex:review`) as a *second model* on the diff — an **additional** advisory pass,
+   not a replacement for this self-review; run both. Treat **Critical/High** findings
+   (yours **or** Codex's) as
+   blocking: fix them this run if you can. If you can't, **revert the change** and
+   **block** the ticket (§9) tagged `Bail-shape: fix-exhausted` with the findings —
+   do **not** route code-fixing to PM/QA (they don't write code), and never wait for
+   a human; the next Dev fire (or the operator via `lessons.md`) retries.
+   (A Codex finding you judge a false positive isn't a veto — you may proceed, but say
+   so in the hand-off so the owner sees the disagreement.)
+   Medium/Low/nits are non-blocking — apply the cheap ones, note the rest in the
+   hand-off. **Before blocking `fix-exhausted`, if `codex.rescue` is on (§24)** you may
+   hand the stuck task to Codex for **one** pass (`/codex:rescue …` or a write-capable
+   `codex exec`); ship its patch **only** if it then passes these same Step-5 gates +
+   this self-review, else discard it and block as above. One rescue, not a retry loop
+   (it counts inside §9's 2-retry cap); re-read `git status` and stage only this
+   ticket's files (§7) — never blind-commit what Codex left in the tree.
+3. **Skip for trivial diffs** — a docs-only / typo / single-line config change
+   doesn't need Stage 1 or the full review; note that you skipped it and why.
+
+A self-review that surfaces a real Critical bug and blocks the ship is a SUCCESS,
+not a failure — it protected `defaultBranch` and real users.
+
+### Step 6 — Ship (per config)
+Only after green gates:
+- If `git.autoCommit`: make sure you're on **the target repo's resolved `defaultBranch`**
+  first (`repos[].defaultBranch` else `git.defaultBranch`, §19; single-repo unchanged);
+  if that branch doesn't exist in the repo, commit on the repo's current branch and note
+  it — never create a divergent branch. Commit with a message referencing the
+  ticket id (e.g. `feat(...): … (CIT-123)`), following the repo's commit
+  conventions and co-author trailer rules.
+- If `git.autoPush`: push.
+- If `git.autoDeploy` and **the target repo's resolved `deploy.command`** is set: run it,
+  and confirm it succeeded before moving on. (Resolved deploy = `repos[].deploy` else
+  top-level `deploy`, §19. A target repo that resolves to **no** deploy **skips deploy
+  entirely** and NEVER inherits another repo's `deploy.command`/`healthCheck`. Remember
+  there is no cross-repo deploy barrier — only per-repo or idempotent deploys are safe,
+  §19. Single-repo ⇒ top-level `deploy`, unchanged.) **The first time a run would deploy to production —
+  and any time you're overriding the configured `mode` mid-run (conventions §12) —
+  confirm the blast radius with the user before that first irreversible deploy,
+  unless they've already authorized hands-off shipping this session.** Once
+  authorized, proceed per config without re-asking on every ticket. **Under
+  `autonomy:"full"` (§12a) that authorization is standing — do not pause for a
+  confirmation even on the first prod deploy; ship per config and report the blast
+  radius as a fact.**
+If any of these is `false`, stop at that step and note it in the report (a human
+will take it from there).
+
+### Step 6.5 — Post-deploy smoke + autonomous rollback
+**Only if you actually deployed to prod this step** (`autoDeploy` ran a
+`deploy.command`). Shipping unattended to prod means a green build can still break
+prod at runtime (bad env var, a migration, a 500 on a core route) — so confirm prod
+is alive before walking away:
+1. **Smoke-check prod.** Run **the target repo's resolved `deploy.healthCheck`** if
+   config provides it (a URL that must return 2xx, or a command that must exit 0;
+   `repos[].deploy.healthCheck` else top-level, §19); otherwise GET `testEnv.baseUrl`
+   root and require a non-5xx response **only when the target repo IS the deployed
+   product surface** (a repo with no URL of its own has no `baseUrl` to hit — note the
+   §19 per-repo testEnv gap). If the target repo resolves to no deploy, you didn't deploy
+   — skip Step 6.5 entirely. Keep the check tiny and high-signal (the
+   homepage + at most one critical route) — this is a liveness gate, not a test run.
+2. **On failure, retry once** (guard against a flaky cold start / transient blip).
+3. **If it still fails, the deploy broke prod — roll back, don't leave it broken.**
+   Revert the commit(s) you shipped this run on **the target repo's resolved
+   `defaultBranch`** (`git revert --no-edit <commit(s)>` — revert *all* of them if the
+   ticket shipped more than one, e.g. a separate regression-test commit), push, re-run
+   **that repo's resolved `deploy.command`** (§19; single-repo ⇒ top-level
+   `defaultBranch`/`deploy`, unchanged), and confirm the smoke check now passes (prod
+   restored to the prior good state). Then reopen the ticket to `Todo` with `Bail-shape:
+   fix-exhausted` (§9), commenting what broke, the reverted commit sha, and that prod
+   was restored. **A reverted prod-breaker is a SUCCESS** — it protected real users;
+   the fix retries next fire. Never leave prod red waiting for a human.
+4. **If smoke passes**, proceed to Step 7.
+`save_issue`: `state:"In Review"`. Comment with what you changed, where (files /
+routes), how you verified the gates, the commit/deploy ref if shipped, and a
+pointer to the acceptance criteria so the owner (PM for features, QA for bugs)
+can verify. **If you shipped only part of the ticket's ACs, the handoff MUST cite
+the follow-up ticket ID you filed this run for the rest (see the split rule) — a
+"split to a follow-up" with no filed ID is incomplete; file it now, then hand off.**
+**Likewise, a `Bug`/`Feature` hand-off MUST state its coverage outcome
+(conventions §15): the regression test you added this run, OR the `[coverage]`
+follow-up ticket ID you filed this run, OR the exemption reason. "I'll add a test
+later" with no test and no filed ticket is incomplete.**
+Then loop to Step 1.
+
+## 2. Guardrails
+
+- **Cap tickets per run** (default ≤3 *shipped implementations*) — depth over
+  breadth; a correct shipped ticket beats five half-built ones. Cheap grooming
+  outcomes (a block or a duplicate) don't consume the cap.
+- One ticket = one focused change/commit. Don't fold unrelated work together.
+- **Self-review is a real gate, not theater (Step 5.5).** Verify the diff against
+  the ticket's ACs (catch MISSING/EXTRA/MISUNDERSTANDING) and run a code-review
+  pass; a Critical/High finding blocks the ship exactly like a red build. This is
+  the `autonomy:"full"` replacement for a human reviewer — it never waits for a
+  human, it decides and acts (fix, or block as `fix-exhausted`).
+- If you touch shared infra that could affect other in-flight tickets, say so in
+  the report.
+- Respect `mode` and the `git`/`deploy` flags exactly — they encode the user's
+  autonomy choice. When `autoDeploy` is on, you are shipping to real users; treat
+  the green-gate rule as inviolable.
+- **Respect `autonomy` (conventions §12a).** Under `autonomy:"full"`, *decide and
+  act, don't ask* — make scoping/splitting/prioritization calls yourself and ship
+  per config; never pause for an interactive human confirmation (not even before
+  the first prod deploy). Caution stays the **method**: verify against the running
+  product, prefer additive/reversible/idempotent changes, gate on green. Genuine
+  *ticket-content* ambiguity still routes to PM/QA via a Linear **block** (§9) —
+  that's the async escalation path, not a human prompt. An irreversible prod op
+  (migration/backfill) you do **attended yourself** (pre/post-verify + the
+  records-only/safe command form), not by escalating. The only real stoppers are
+  **missing external inputs, not missing courage** — real third-party
+  credentials/contracts, spending money, legal sign-off, or a capability you lack
+  this run; report those as *blocked on an external prerequisite* (a fact) and
+  proceed with everything else.
+
+## 3. Close with a report
+
+End with: tickets picked, what shipped (with commit/deploy refs), what moved to
+In Review, what you blocked (and why), what you marked Duplicate/Canceled, and any
+build/deploy failures. If `mode:"dry-run"`, label it a preview.