…
name: d2-guardian
description: The guardians' skill on d2: report-only checks of other agents' work, one watch per guardian. Read after d2-maker and d2-agents.
-tags: inherited
---
# d2-guardian
…
- **You only report. You never change anything anywhere:** no topics, no drafts, no pipeline items, no status changes on others' work, no code.
- **Post your status first, before you read or write anything:** d2 knows you are a guardian only from your newest board status in the `guardian` role; until then your token is an ordinary AI token and your report write is refused. Post your own status as any agent: `working` with your watch as text while you run, `idle` when done (board name `guardian-<watch>`, the watcher `watcher`).
-- **Write each run's findings into your report, a `Report:` topic** (the only thing you may write; d2 refuses anything else): `Report:<your name>-<yyyy-mm-dd>`, frontmatter `by`, `watch`, `run`, `trigger`, `summary`, `tags: report, guardian`; `# Report: <name>, <date>`, the summary line, a `##` per check, and per finding a `### F<n> <one line> {#f<n>}` with what you saw, where (links with anchors), what it differs from (quote both), then
+- **Write each run's findings into your report, a `Report:` topic** (the only thing you may write; d2 refuses anything else): `Report:<watch>-guardian-<yyyy-mm-dd>` (`Report:spec-guardian-2026-10-05`, `Report:watcher-guardian-2026-10-05`; a second run the same day adds `-2`), frontmatter `type: guardian-report`, `watch` (spec, tests, security or watcher: the one property that says which guardian wrote it), `by` (your agent name), `run` (when the run started), `since` (where the spec watch's *done since* started), `through` (the `doneAt` of the last done item checked), `state` (`in-progress` until the run ends, then `done`), `trigger`, `summary`, `tags: report, guardian`; the title `# Report from the <watch> guardian, <date>`, the summary line, a `##` per check, and per finding a `### F<n> <one line> {#f<n>}` with what you saw, where (links with anchors), what it differs from (quote both), then
- a context fence: ```` ```context <Topic>#<anchor> ```` with a few lines above and below as they are now, the problem line starting with `→ ` (for drift, two fences: the spec line and the test);
- a **`Recommend:` line** saying concretely what to change — which line, to what — so the item made from the finding is actionable as it stands: `**Recommend:** …`, one line, before the suggestions. A finding that only says what is wrong leaves whoever picks the item up to work the fix out again, from a report they did not write.
- its suggested work items, as `- [ ] <title> {for: <role agent>, size: small|medium|large}` lines under the finding.
Then post one board notice to your person: your summary line and a link to the report. d2 raises the `N_GUARD` notice for a run with findings (none for a clean run).
+- **One report per run, kept in progress:** a run starts by finding its own watch's newest report (`Report:<watch>-guardian-…` with your `watch` in its frontmatter; never another guardian's). If that report is still `state: in-progress`, the last run didn't finish: continue it, from its *Run notes* and `through`, in the same topic. Otherwise start a new one, `state: in-progress`, and write it at once. Keep a `## Run notes` section at its end (where you are, what's left, anything you couldn't check and why) and save the report as you go, at least after each check or every 5 items; set `state: done` only when the run ends. So a crash or a run that can't finish loses little, and the next run picks it up instead of starting over. **Why:** a long run that crashed half way would otherwise start again from the top and crash again (Razie, designer-38 chat, 2026-10-05).
- **In your chat, answer with an abstract:** your summary line, the two or three findings that matter most, and the report's link; never paste the whole report.
- **Discuss, then act only when told.** Your person may go through the report with you in your chat. Make work items for other roles **only when your person says so**, with `askedBy` naming them and a link to the report; never on your own.
…
Areas: `d2-spec`, `d2-design`, Routes, MarketingBlurbs. When: daily and after each checkpoint. Spec, UiSpec and Design agree (a Design section per feature under the same `{#id}`, ending with *Routes and codes*); codes, anchors and routes resolve (built or Planned in Routes); each design follows the Standing principles at the top of Spec; blurbs cite real spec lines.
+**First: done since your last run.** Before the checks below, check the pipeline items closed since your last checked point, so work that shipped without its documents is caught.
+ - **Where to start:** the `through` of your newest spec report, finished or not. A date your person gives in the start prompt (*review done items since ‹date›*) wins; with neither, the last 30 done items.
+ - **Oldest first, at most 20 per run:** list them with `GET /api/v2/pipeline?status=done&format=json`, leave out releases, handovers and reports, and work them in `doneAt` order from the start point. Items left past the 20 are named in the summary (*n left, next run continues*).
+ - **Save as you go:** write your report as the run starts (`state: in-progress`, `since` and `through` = the start point) and, after every 5 items, save it again with the findings so far and `through` = the `doneAt` of the last item checked; at the end set `state: done`. A run that crashes or can't finish loses at most five items' work, and the next one picks up from `through`, never from the top. A run that finds its watch's newest report still `in-progress` continues that report (see *One report per run* above) instead of starting a new one.
+ - **An item you can't check** (its read fails, it's too big to read, or it is the one right after an in-progress report's `through`, so it likely stopped that run) goes under *Couldn't check* in the not-carried section with why, and `through` moves past it, so one bad item never stops every run after it.
+ Check each one against the published topics:
+ - **Tests:** every test the item names (its *Done when* and the *Tests* line of its As built) is a Testing line with its code, *Tested* and the test file; the code is new, not one another test already has (a second `PIPE-115` is a finding).
+ - **Spec and SpecUi:** a change someone using d2 would notice (behaviour, a page, an error an agent gets) has its line, with a code.
+ - **Design:** every rule, route, field, setting and error code (`E_…`) the item built is in its Design section and that section's *Routes and codes*; planned routes in Routes.
+ - **As built:** Proto1Impl carries the item's As built line, unless its ticket says *no doc changes*.
+ - **Design calls folded:** every *Decided* and *Suggested update* the coder sent, on the item or on the open *Design calls* item for the designer, is in the published text, or the item carries the designer's ruling declining it.
+ **Superseded first, then judged against the newest:** before reporting an item, look *forward* at every item done after it, not only this run's 20. A later item supersedes it when its `supersedes` lists a code the older item added or changed (its `## Changes`, or its `codes`), or failing those they share a behaviour or test code or a spec, design or test anchor; sharing only `touches` on the same feature makes it a *maybe*. A superseded item's gaps are judged against the newest item's As built only: list it under *Superseded* (*P-400: superseded by P-600, shares ^pipe-57*), with no fix of its own; a *maybe* goes into the newer item's finding, both ids named, the recommendation written from the newer one. **Why:** an old item's suggested lines, folded after a later item changed the same behaviour, would put obsolete text into the spec and cost the designer work for nothing.
+ **`supersedes` on every ticket:** every coder item filed since your `since`, open or done, has `supersedes` (codes, or `none`) and a `## Changes` section. For each code under Changes, look it up in the published Spec and SpecUi: a new code needs nothing; an existing code missing from `supersedes` is a finding (*P-n changes ^pipe-57 but doesn't say it supersedes it*), as is a missing field or section, or a `supersedes` code that doesn't exist. These go in the same batch, so the designer fixes them before a coder builds on a stale picture. Items marked `verified` get the same check: a wrong verified list is a finding too.
+ Every item missing any of these goes into the report's first section after the summary, **`## Done items not carried {#not-carried}`**, with its lists *Not carried*, *Superseded* and *Missing or wrong `supersedes`*: one `### P-n ‹title› {#p-n}` per item (the item as a link), then what's missing, each with the line the coder suggested quoted, where it belongs (topic and section as links) and a **Recommend:** line. Close the section with **one** suggested item for all of them together, `- [ ] Complete the docs of done items P-a, P-b, … (report #not-carried) {for: designer agent, size: medium|large}` (medium up to five items), so your person can send the whole batch to the designer at once; a gap only a coder can fill (a missing As built, a reused test code) goes in the same batch, marked *coder*, for the designer to pass on. Count them in the summary line. **Why:** ten coder items in a row ([P-866](/pipeline/P-866) to [P-891](/pipeline/P-891)) shipped with tests and suggested doc lines, but none of those lines reached Spec, SpecUi, Design or Testing; the suggestions piled up unread on the designer's design-calls item (Razie, designer-38 chat, 2026-10-05). Oldest first with saves every 5 items, so a long backlog spans runs and a crash never restarts it from the top (Razie, same chat).
+
1. **Aligned:** every feature id `{#id}` in Spec and UiSpec has a Design section with the same id, and every Design feature section has its Spec or UiSpec line; orphans either way.
2. **Routes and codes:** every Design feature section ends with its *Routes and codes* bullet; every route, page and code named there is in Routes (built or under Planned), and every Routes line names a feature that exists.
…
10. **Tested:** every Spec or UiSpec line added or changed since your last run carries a code and has at least one Testing line; the tests guardian checks the tests themselves.
-Summary line: *spec: N findings (unaligned a, unresolved b, duplicate codes c, how in Spec d)*. Suggested owner: `designer agent`.
+Summary line: *spec: not carried n of m done; N findings (unaligned a, unresolved b, duplicate codes c, how in Spec d)*. Suggested owner: `designer agent`.
## security
…
- Until `show=` is built (P-626) the Toolbox check fails by design: report it once as *known, waits on P-626*, not as a new alert each run.
+
+10. **Pipeline scope — tickets never leak across projects** (Razie, 2026-10-05; read-only GETs, on every project you can reach):
+ - A pipeline item belongs to the **one project it was created in**; its visibility follows that project's membership, and there is **no per-ticket visibility field** and no "shared" flag. Confirm a ticket from one project (e.g. a d2spec `P-###`) is **not returned** by another project's pipeline list or `GET /api/v2/pipeline/<id>` — anonymously and with your token — and that its id resolves only within its own project. `forRole`/`forName` route who an item is *assigned* to, never who may *see* it.
+ - The only cross-project surface is the explicit **All projects** roll-up, and it must show only items from projects the caller is a member of — never another person's projects. Probe that a caller sees no ticket, title, summary or doc from a project they don't belong to.
+ - A finding here (a ticket readable outside its project, or the roll-up exposing a non-member's project) is an **alert**.
+
Summary line: *security: N findings (a alert); routes probed b of c*. A finding in 1 to 3 is an alert. Suggested owners: the project's admins; code fixes → `coder agent`.
…