@integrity-labs/agt-cli 0.28.891 → 0.28.892

package/dist/mcp/telegram-channel.js

@@ -35774,6 +35774,12 @@ var CURSOR_SHORTFALL_REASONS = [
 var NON_SHORTFALL_KEYS = new Set(CURSOR_ADVANCE_NON_SHORTFALL_KEYS);
 var KNOWN_REASONS = new Set(CURSOR_SHORTFALL_REASONS.filter((k) => !NON_SHORTFALL_KEYS.has(k)));
 
+// ../core/dist/direct-chat/agent-history-notices.js
+var AGENT_HISTORY_TURNS_ONLY_OR_FILTER = [
+  "payload->>kind.is.null",
+  `payload->>kind.in.("",${[...USER_FACING_NOTICE_KINDS].sort().join(",")})`
+].join(",");
+
 // ../core/dist/onboarding/state-machine.js
 var AREA_ORDER = [
   "framing",
@@ -38442,16 +38448,36 @@ var FLAG_REGISTRY = [
   },
   {
     key: "ninjafy-brand",
-    description: 'Present the product under the Ninjafy brand instead of Augmented Team (ENG-8250). This is the UMBRELLA brand gate, not a one-off nav toggle: every subsequent rebrand surface (page titles, email templates, marketing-facing copy) reads THIS key rather than adding its own flag, so the whole rebrand keeps a single kill switch. First surface is the left-hand nav wordmark \u2014 ON replaces the human+robot mark and the "augmented.team" text with italic lowercase "ninjafy"; OFF renders exactly what shipped before. Scope is the USER-FACING BRAND PRESENTATION \u2014 text AND VISUAL THEME. ENG-8858 widened this from text alone: the Ninjafy palette is gated here too, because a colour theme is not text. It stays ONE key rather than gaining a `ninjafy-theme` sibling, so a half-branded state \u2014 ninjafy wordmark over Augmented green \u2014 is unreachable and the rebrand keeps a single kill switch. It must never gate a code identifier, package name, env var or CLI name. EXISTING identifiers stay `Augmented`/`agt` per the CLAUDE.md naming contract, which protects them from premature renaming \u2014 the deep rename is workstream C of docs/runbooks/rebrand-ninjafy-migration.md and is out of scope here. That contract does NOT require NEW code to carry the old brand: artefacts created specifically for the rebrand take Ninjafy naming (ENG-8078 decision 9; see the CLAUDE.md rebrand carve-out). Either way it is a naming rule, not a flag concern \u2014 this key gates presentation, never an identifier. Set the stage-wide default to flip a whole environment, or add a feature_flag_overrides row to pilot a subset while everyone else still sees Augmented. Overrides resolve at FOUR grains, most specific first \u2014 agent, team, host, then org-wide (evaluate.ts:79-81); organization_id is always required, so there is no global override. Org and team are the useful pilot grains for THIS flag: there is now exactly ONE consumer \u2014 (dashboard)/layout.tsx via getPublicBooleanFlagServer \u2014 evaluating in the active-org cookie scope, so a host- or agent-scoped row is accepted by the table but never reached by the console. It resolves the key ONCE per request and passes the boolean down to sidebar.tsx and top-nav.tsx as a required prop. Resolution is SERVER-side deliberately: the client hook starts at its default and updates after an async GET /flags, so anything gated on it paints Augmented and then repaints. ENG-8858 moved the PALETTE for that reason (a full-page colour flash); ENG-9227 moved the WORDMARK, which had been the last surface still swapping after hydration. A consequence worth knowing: /login and the marketing routes stay on the Augmented palette whatever an org sets, because getPublicBooleanFlagServer returns the default without a verified session and a pre-auth page has neither a session nor an active org \u2014 a PER-ORG flag structurally cannot brand one. Those surfaces follow only when the stage-wide default flips. Ships dark.',
+    description: 'Present the product under the Ninjafy brand instead of Augmented Team (ENG-8250). This is the UMBRELLA brand gate, not a one-off nav toggle: every subsequent rebrand surface (page titles, email templates, marketing-facing copy) reads THIS key rather than adding its own flag, so the whole rebrand keeps a single kill switch. First surface is the left-hand nav wordmark \u2014 ON replaces the human+robot mark and the "augmented.team" text with italic lowercase "ninjafy"; OFF renders exactly what shipped before. Scope is the USER-FACING BRAND PRESENTATION \u2014 text AND VISUAL THEME. ENG-8858 widened this from text alone: the Ninjafy palette is gated here too, because a colour theme is not text. It stays ONE key rather than gaining a `ninjafy-theme` sibling, so a half-branded state \u2014 ninjafy wordmark over Augmented green \u2014 is unreachable and the rebrand keeps a single kill switch. It must never gate a code identifier, package name, env var or CLI name. EXISTING identifiers stay `Augmented`/`agt` per the CLAUDE.md naming contract, which protects them from premature renaming \u2014 the deep rename is workstream C of docs/runbooks/rebrand-ninjafy-migration.md and is out of scope here. That contract does NOT require NEW code to carry the old brand: artefacts created specifically for the rebrand take Ninjafy naming (ENG-8078 decision 9; see the CLAUDE.md rebrand carve-out). Either way it is a naming rule, not a flag concern \u2014 this key gates presentation, never an identifier. Set the stage-wide default to flip a whole environment, or add a feature_flag_overrides row to pilot a subset while everyone else still sees Augmented. Overrides resolve at FOUR grains, most specific first \u2014 agent, team, host, then org-wide (evaluate.ts:79-81); organization_id is always required, so there is no global override. Org and team are the useful pilot grains for THIS flag: there is now exactly ONE consumer \u2014 (dashboard)/layout.tsx via getPublicBooleanFlagServer \u2014 evaluating in the active-org cookie scope, so a host- or agent-scoped row is accepted by the table but never reached by the console. It resolves the key ONCE per request and passes the boolean down to sidebar.tsx and top-nav.tsx as a required prop. Resolution is SERVER-side deliberately: the client hook starts at its default and updates after an async GET /flags, so anything gated on it paints Augmented and then repaints. ENG-8858 moved the PALETTE for that reason (a full-page colour flash); ENG-9227 moved the WORDMARK, which had been the last surface still swapping after hydration. A consequence worth knowing: /login and the marketing routes stay on the Augmented palette whatever an org sets, because fetchPublicFlags returns null without a verified session and a pre-auth page has neither a session nor an active org \u2014 a PER-ORG flag structurally cannot brand one. ENG-9830 CORRECTS what used to be written here ("those surfaces follow only when the stage-wide default flips"): they do not follow it at all. Two reasons. The value returned on a null fetch is the CALL SITE\u2019s passed argument, not this registry default; and six such pages (/login, /reset-password, /auth/confirm, the pre-redeem member-signin gate and the two public Slack-install terminal pages) do not mount <BrandStamp/> AT ALL \u2014 deliberately, enumerated with per-page reasons in eng-9266-brand-stamp-coverage.test.ts. They become branded when the flag is REMOVED at cutover step 2 and the palette moves into bare :root, with no read left to gate it. NO LONGER DARK: ENG-9830 cutover step 1 flipped the default to true, so an org with no override now sees Ninjafy. The key survives only until cutover step 2 deletes it.',
     flagType: "boolean",
-    // Declared safe value is `false`: the pre-rebrand brand. `false` is also the
-    // fail-closed direction — if the flag DB is unreachable we must show the brand
-    // that is currently live and contractually correct, never leak an unannounced
-    // rebrand to every customer at once.
-    defaultValue: false,
+    // ENG-9830 (cutover step 1): flipped `false` -> `true`. The comment this
+    // replaces argued `false` was the fail-closed direction — "never leak an
+    // UNANNOUNCED rebrand to every customer at once". That was correct for as
+    // long as the rebrand was unannounced. It is not any more: Ninjafy is the
+    // live, announced brand (ENG-9613 reconciled the console onto the master
+    // assets while the flag was already ON in production), so `false` now points
+    // at the brand we no longer ship. A flags outage that reverted a customer to
+    // Augmented would be the incident, not the safe harbour.
+    //
+    // The old rationale is recorded rather than deleted because it is a correct
+    // argument whose PREMISE expired — reading the change without it looks like
+    // someone overriding a deliberate fail-closed default.
+    //
+    // NOTE this value is only consulted by the API evaluator when building the
+    // `GET /flags` map for an org with no override. It is NOT the fallback the
+    // webapp uses on an outage: `getPublicBooleanFlagServer(key, defaultValue)`
+    // returns its own PASSED argument when the fetch fails, so the call sites in
+    // (dashboard)/layout.tsx and components/brand-stamp.tsx carry `true` too.
+    // Flipping only one of the two leaves the cutover half-applied.
+    defaultValue: true,
     // ENG-9227: there are NO client readers of this key left. (dashboard)/
     // layout.tsx resolves it ONCE server-side via getPublicBooleanFlagServer and
     // passes the boolean down to sidebar.tsx and top-nav.tsx as a required prop.
+    // "ONCE" is about the chrome, not the key: components/brand-stamp.tsx is a
+    // SECOND, independent server read of `ninjafy-brand` (CodeRabbit, #5385).
+    // Both are listed in the note above because both carry an outage fallback
+    // that has to move together — reading this paragraph alone would leave you
+    // updating one of the two.
     // ENG-8858 did that for the THEME; ENG-9227 finished the job for the
     // WORDMARK, which had kept usePublicBooleanFlag and so kept swapping
     // "augmented.team" to "ninjafy" after hydration.
@@ -38473,24 +38499,38 @@ var FLAG_REGISTRY = [
   },
   {
     key: "ninjafy-logo",
-    description: "Which Ninjafy logo TREATMENT the console chrome renders (ENG-9365). This is a SUB-SELECTION under ninjafy-brand, not a second brand gate: it is consulted only once ninjafy-brand has already resolved ON, so with the brand off the value is inert and the half-branded state that flag's description calls unreachable stays unreachable. ninjafy-brand remains the single kill switch for the rebrand. It exists so candidate logo treatments can be put in front of a human and compared in the running console, rather than judged from a static export. lockup = mark and wordmark together, both in the brand blue \u2014 exactly what ENG-9298 shipped, so an unset flag is a no-op. two-tone = the mark in brand blue with the wordmark in the neutral text colour (the treatment of the blue-icon/black-wordmark artwork). wordmark = the word alone, no mark. Every treatment is composed from the ENG-9298 geometry \u2014 ENG-9312 pins that the lockup's blue path IS the mark subpath followed by the wordmark subpaths, byte for byte \u2014 so a new treatment is a composition, never a fresh trace, and the three drawings cannot drift apart. Surfaces are the dashboard sidebar and the top nav. The top nav shows the WORDMARK portion at every width whatever the treatment, because ENG-9342 decided that deliberately (a full lockup at the header's icon height crowds the team switcher on a phone) \u2014 so a treatment changes the word's colour there, never whether a mark appears. The admin sidebar (ENG-9323) is NOT wired to this key and always renders the mark; widening it is a separate decision. Resolved SERVER-SIDE in (dashboard)/layout.tsx via getPublicEnumFlagServer, beside ninjafy-brand and in the same single GET /flags round trip, then passed down as a required prop. That is not a style preference: the client hook starts at its default and updates after an async fetch, so a client read would paint one logo and swap it after hydration \u2014 the exact flash ENG-9227 removed from the wordmark and ENG-8858 removed from the palette. Org and team are the useful pilot grains, as for ninjafy-brand: the single consumer evaluates in the active-org cookie scope, so a host- or agent-scoped override row is accepted by the table but never reached by the console.",
+    description: "Which Ninjafy logo TREATMENT the console chrome renders (ENG-9365). This is a SUB-SELECTION under ninjafy-brand, not a second brand gate: it is consulted only once ninjafy-brand has already resolved ON, so with the brand off the value is inert and the half-branded state that flag's description calls unreachable stays unreachable. ninjafy-brand remains the single kill switch for the rebrand. It existed so candidate logo treatments could be put in front of a human and compared in the running console, rather than judged from a static export. That comparison has happened: ENG-9830 cutover step 1 chose TWO-TONE, so that is now the default and an unset flag renders it. NOTE this reverses the property this description used to claim \u2014 an unset flag was a no-op while the default was lockup (what ENG-9298 shipped), and that is deliberately given up at cutover: the default MOVING is the change. The key survives only until cutover step 2 hardcodes the chosen treatment and deletes it. lockup = mark and wordmark together, both in the brand blue \u2014 what ENG-9298 shipped. two-tone = the mark in brand blue with the wordmark in the neutral text colour (the treatment of the blue-icon/black-wordmark artwork); the chosen one. wordmark = the word alone, no mark. Every treatment is composed from the ENG-9298 geometry \u2014 ENG-9312 pins that the lockup's blue path IS the mark subpath followed by the wordmark subpaths, byte for byte \u2014 so a new treatment is a composition, never a fresh trace, and the three drawings cannot drift apart. Surfaces are the dashboard sidebar and the top nav. The top nav shows the WORDMARK portion at every width whatever the treatment, because ENG-9342 decided that deliberately (a full lockup at the header's icon height crowds the team switcher on a phone) \u2014 so a treatment changes the word's colour there, never whether a mark appears. The admin sidebar (ENG-9323) is NOT wired to this key and always renders the mark; widening it is a separate decision. Resolved SERVER-SIDE in (dashboard)/layout.tsx via getPublicEnumFlagServer, beside ninjafy-brand and in the same single GET /flags round trip, then passed down as a required prop. That is not a style preference: the client hook starts at its default and updates after an async fetch, so a client read would paint one logo and swap it after hydration \u2014 the exact flash ENG-9227 removed from the wordmark and ENG-8858 removed from the palette. Org and team are the useful pilot grains, as for ninjafy-brand: the single consumer evaluates in the active-org cookie scope, so a host- or agent-scoped override row is accepted by the table but never reached by the console.",
     flagType: "enum",
     allowedValues: ["lockup", "two-tone", "wordmark"],
-    // Declared safe value is `lockup` — what ENG-9298 shipped. This flag has no
-    // "off" direction: it selects among presentations that are all live-safe, so
-    // fail-safe here means "the treatment currently in production", not the
+    // ENG-9830 (cutover step 1): `lockup` -> `two-tone`. The treatments existed
+    // so they could be compared in the running console rather than judged from a
+    // static export (ENG-9365); that comparison has now happened and `two-tone`
+    // — the mark in brand blue with the wordmark in the neutral text colour — is
+    // the chosen treatment. It becomes the hardcoded one when this key is
+    // removed at cutover step 2.
+    //
+    // The rule this value obeys is unchanged: this flag has no "off" direction,
+    // so fail-safe means "the treatment currently in production", not the
     // narrowest one. A flag-DB read error, an archived row, or a stored value
     // outside allowedValues all resolve here (evaluate.ts normalizeFlagValue),
-    // which is what makes an experimental value impossible to strand.
-    defaultValue: "lockup",
+    // which is what makes an experimental value impossible to strand. Only which
+    // treatment holds that position has moved.
+    //
+    // Same split as ninjafy-brand above: this governs the API evaluation path
+    // only. The webapp's outage fallback is the argument passed at the
+    // (dashboard)/layout.tsx call site, which carries 'two-tone' to match.
+    defaultValue: "two-tone",
     // Same trap as ninjafy-brand, and it bites harder here because there are no
     // client readers of this key AT ALL — it is server-resolved by construction.
     // `public` does NOT mean "read by a browser"; it means "readable through the
     // public map". getPublicEnumFlagServer resolves against the same GET /flags
     // endpoint the browser uses, and that route filters to listPublicFlagKeys()
     // (routes/flags.ts). Drop `public` and the key is simply absent from the map,
-    // so the helper falls through to its default and returns `lockup` FOREVER —
-    // the dropdown appearing to do nothing, with no error raised anywhere.
+    // so the helper falls through to the fallback passed at that call site and
+    // returns it FOREVER — the dropdown appearing to do nothing, with no error
+    // raised anywhere. Named as the call site rather than as a literal on
+    // purpose: this comment said `lockup` for exactly as long as `lockup` was
+    // the answer, and ENG-9830 flipping the winner is what made it a lie.
     public: true
   },
   {

package/dist/{persistent-session-ZDZSEODJ.js → persistent-session-ARKZDYMX.js}

@@ -62,8 +62,8 @@ import {
   writeDirectChatSessionState,
   writeEgressAllowlist,
   writePersistentClaudeWrapper
-} from "./chunk-SXYTFXPO.js";
-import "./chunk-BH5RFBUM.js";
+} from "./chunk-WMJBXN6N.js";
+import "./chunk-FZ6KIIYX.js";
 import "./chunk-XWVM4KPK.js";
 export {
   CLAUDE_HOST_WIDE,
@@ -130,4 +130,4 @@ export {
   writeEgressAllowlist,
   writePersistentClaudeWrapper
 };
-//# sourceMappingURL=persistent-session-ZDZSEODJ.js.map
+//# sourceMappingURL=persistent-session-ARKZDYMX.js.map

package/dist/{responsiveness-probe-7CY5VZMG.js → responsiveness-probe-X2WXPIUI.js}

@@ -1,7 +1,7 @@
 import {
   paneLogPath
-} from "./chunk-SXYTFXPO.js";
-import "./chunk-BH5RFBUM.js";
+} from "./chunk-WMJBXN6N.js";
+import "./chunk-FZ6KIIYX.js";
 import "./chunk-XWVM4KPK.js";
 
 // src/lib/responsiveness-probe.ts
@@ -764,4 +764,4 @@ export {
   readAndResetSlackReplyBindingClassifications,
   readAndResetSlackReplyTargetClassifications
 };
-//# sourceMappingURL=responsiveness-probe-7CY5VZMG.js.map
+//# sourceMappingURL=responsiveness-probe-X2WXPIUI.js.map

package/dist/{session-auth-dead-65TG2DLW.js → session-auth-dead-BLEV4AUJ.js}

@@ -1,6 +1,6 @@
 import {
   sessionTranscriptDir
-} from "./chunk-BH5RFBUM.js";
+} from "./chunk-FZ6KIIYX.js";
 
 // src/lib/session-auth-dead.ts
 import { closeSync, openSync, readSync, readdirSync, statSync } from "fs";
@@ -203,4 +203,4 @@ export {
   decideSessionAuthState,
   probeSessionAuth
 };
-//# sourceMappingURL=session-auth-dead-65TG2DLW.js.map
+//# sourceMappingURL=session-auth-dead-BLEV4AUJ.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@integrity-labs/agt-cli",
-  "version": "0.28.891",
+  "version": "0.28.892",
   "description": "Augmented Team CLI — agent provisioning and management",
   "type": "module",
   "engines": {
@@ -24,7 +24,7 @@
   "scripts": {
     "build": "tsup && npm run build:mcp-assets && npm run build:cli-assets",
     "build:mcp-assets": "mkdir -p dist/mcp && cp ../../packages/mcp/dist/index.js dist/mcp/index.js && cp ../../packages/mcp/dist/slack-channel.js dist/mcp/slack-channel.js && cp ../../packages/mcp/dist/direct-chat-channel.js dist/mcp/direct-chat-channel.js && cp ../../packages/mcp/dist/telegram-channel.js dist/mcp/telegram-channel.js && cp ../../packages/mcp/dist/teams-channel.js dist/mcp/teams-channel.js && cp ../../packages/mcp/dist/whatsapp-channel.js dist/mcp/whatsapp-channel.js && cp ../../packages/mcp/dist/whatsapp-link.js dist/mcp/whatsapp-link.js && cp ../../packages/mcp/dist/remote-oauth-proxy.js dist/mcp/remote-oauth-proxy.js && cp ../../packages/mcp/dist/computer-use-proxy.js dist/mcp/computer-use-proxy.js && cp ../../packages/augmented-admin-mcp/dist/index.js dist/mcp/augmented-admin.js && cp ../../packages/augmented-support-mcp/dist/index.js dist/mcp/augmented-support.js && cp ../../packages/augmented-help-kb-mcp/dist/index.js dist/mcp/augmented-help-kb.js && cp ../../packages/origami-mcp-server/dist/index.js dist/mcp/origami.js && cp ../../packages/xero-mcp-server/dist/index.js dist/mcp/xero.js",
-    "build:cli-assets": "mkdir -p dist/assets && cp assets/impersonate-statusline.sh dist/assets/impersonate-statusline.sh && chmod +x dist/assets/impersonate-statusline.sh && mkdir -p dist/assets/review && cp assets/review/post-review-findings.mjs dist/assets/review/post-review-findings.mjs && cp assets/review/obiwan-auth.mjs dist/assets/review/obiwan-auth.mjs && cp assets/review/SKILL.md dist/assets/review/SKILL.md && cp assets/review/SWEEP.md dist/assets/review/SWEEP.md && chmod +x dist/assets/review/post-review-findings.mjs",
+    "build:cli-assets": "mkdir -p dist/assets && cp assets/impersonate-statusline.sh dist/assets/impersonate-statusline.sh && chmod +x dist/assets/impersonate-statusline.sh && mkdir -p dist/assets/review && cp assets/review/post-review-findings.mjs dist/assets/review/post-review-findings.mjs && cp assets/review/obiwan-auth.mjs dist/assets/review/obiwan-auth.mjs && chmod +x dist/assets/review/post-review-findings.mjs",
     "dev": "tsx watch src/bin/agt.ts",
     "test": "vitest run",
     "typecheck": "bash ../../scripts/typecheck-guard.sh tsc --noEmit",

package/dist/assets/review/SKILL.md

@@ -1,223 +0,0 @@
----
-name: pr-review
-description: Review a GitHub pull request's diff and write the findings to a JSON artefact. Use when asked to review a PR, or when a card asks you to review a repo's pull request. Produces the artefact only — it never posts to GitHub.
----
-
-# Reviewing a pull request
-
-You are a Ninjafy agent (Ninjafy and Augmented Team are one platform, so you
-answer to the old name too). This skill is how you review a pull request.
-
-**You write a file. You post nothing.** Posting is a separate, gated step that
-reads the file this skill produces. Producing the artefact and publishing it are
-deliberately different actions, so a review can be made and read before anybody
-decides it should appear on the PR.
-
-You do **not** need a checkout. Everything below comes from the GitHub API via
-`gh`, which is already on your PATH and already authenticated.
-
----
-
-## 1. Resolve the PR
-
-You need the repository as `owner/name` and the PR number. If you were given
-only a URL, read them off it.
-
-```bash
-gh api repos/OWNER/NAME/pulls/NUMBER
-```
-
-From the response take `number`, `title`, `state`, `head.sha` and `base.sha`.
-
-- **`state` is not `open`** — say so and stop. Reviewing a closed chapter helps
-  nobody.
-- **The call fails** — say so and stop. Do not review from memory of the repo.
-
-`head.sha` is the commit you are reviewing. Every later step is pinned to it,
-and it is part of the artefact's filename, because a review of one commit says
-nothing about another.
-
-## 2. Get the diff — from the API, not from a working tree
-
-```bash
-gh api repos/OWNER/NAME/pulls/NUMBER/files --paginate --slurp
-```
-
-Each entry has `filename`, `status`, `patch` (a unified diff hunk) and the
-change counts. Read the patches; that is the change.
-
-**Use this endpoint and no other.** The step that posts findings anchors each
-one to a line it computes from *these same patches* — the right-hand side of
-each hunk, which is the only place GitHub accepts an inline comment. A line
-number taken from anywhere else (a local `git diff`, a whole-file read, a
-`compare` against a different base) can be perfectly correct about the code and
-still unanchorable, and an unanchorable finding is quietly demoted out of the
-place a reader would look for it.
-
-Some entries have **no `patch`** — a binary file, or one too large for GitHub to
-render. Do not guess at their contents. Either fetch the file if you need it, or
-leave it unreviewed and say which files you skipped.
-
-### Then check the PR has not moved under you
-
-This endpoint returns the diff **as it is now**, not the diff at the `head.sha`
-you read in step 1. If someone pushed while you were reading, you now hold one
-commit's diff about to be filed under another commit's name.
-
-So read the head again and compare:
-
-```bash
-gh api repos/OWNER/NAME/pulls/NUMBER --jq .head.sha
-```
-
-- **Same as step 1** — carry on.
-- **Different** — start again from step 1 against the new head. If it moves a
-  second time, stop and write an `incomplete` artefact saying the PR is moving
-  faster than you can read it.
-
-Do not simply relabel what you already read with the newer sha. That is the
-failure this check exists to prevent, not a way around it: the artefact would be
-a review of code nobody can see any more, indistinguishable from a review of the
-code that is there.
-
-## 3. Load the repo's own rules
-
-```bash
-gh api repos/OWNER/NAME/contents/CLAUDE.md?ref=HEAD_SHA --jq .content
-```
-
-```bash
-gh api repos/OWNER/NAME/contents/docs/reference/review-rules.md?ref=HEAD_SHA --jq .content
-```
-
-Both are base64; decode them. **Issue both requests before you begin step 4 —
-this is not optional.** Either may 404, which is fine and normal: most repos
-have neither.
-
-Record which happened, because "absent" and "never asked" are different facts
-and the artefact cannot tell them apart on its own. `rulesFile` is the path when
-the fetch returned content (at either ref), and `null` **only after you have
-actually observed a 404 at both**. If you did not issue the request, the review is `incomplete` with that as
-the reason — a review conducted without rules it never looked for must not be
-filed as though the rules were absent.
-
-Where `review-rules.md` exists it **outranks your priors**: a rule saying "this
-is deliberate here, do not flag it" exists because a reviewer already raised
-that exact thing and a human said no. Where it does not exist, review anyway and
-say so in your summary — a repo without one gets a generic review, which is
-worth having and worth labelling as such.
-
-Pin both reads to `HEAD_SHA` first. Reading the default branch's rules against a
-branch's code compares the change to something it was never written against.
-
-**If `review-rules.md` 404s at `HEAD_SHA`, retry it at the default branch, and
-record which ref supplied it.** A branch cut before the rules file landed — or
-simply never merged forward — has no copy of it at its own head, and that is the
-common case, not the rare one: measured 2026-09-08, **8 of the 12 newest open
-PRs** 404 on it. Pinning alone therefore withholds the corpus from most reviews
-precisely while it is newest. Rules describe the repo's current standards rather
-than the branch's snapshot, so the fallback is sound; what would not be sound is
-applying them without saying so. Set `rulesRef` to `"head"` or `"default"`
-alongside `rulesFile`.
-
-Do NOT pipe or redirect these commands. Use `--jq` on the `gh` call itself and
-read the output directly. A reviewer runs unattended under a tool allowlist
-narrow enough that it cannot post to GitHub, and `gh … | jq` or `gh … > file`
-is a compound command that such an allowlist rejects — so composing a shell
-pipeline costs you turns and buys nothing.
-
-## 4. Review
-
-Prioritise, in this order:
-
-1. **Correctness.** Does it do what it claims? What input makes it wrong?
-
-2. **Claims that outrun the code.** A comment, commit message or PR body
-   asserting a guard, a threshold or a behaviour the code does not implement.
-   These are worse than a missing guard, because they stop the next person
-   looking. Read what the change *says about itself*, and check it.
-
-3. **Silent failure.** A path where something goes wrong and nothing reports it:
-   a swallowed error, a fallback that renders a failed measurement as a
-   plausible normal value, an empty result indistinguishable from "nothing to
-   report". Ask of every failure branch: *if this fired right now, how would
-   anyone know?*
-
-4. **Tests that cannot fail.** A test that looks correct and is structurally
-   incapable of failing reports coverage it does not provide, and CI will never
-   reveal it, because CI only ever runs it green.
-
-5. **Security visible in the diff** — a new unauthenticated path, a secret on a
-   command line or in an environment variable, an unparameterised query, a taint
-   flow from request input to a sink.
-
-**Do not spend the review on formatting, naming, or suggesting more cases for
-behaviour already covered.** A review that is 80% nits gets skimmed, and then
-the one real finding in it gets skimmed too.
-
-## 5. Say which of the three outcomes you reached
-
-They are different states and reporting them identically is the failure this
-skill exists to find in other people's code:
-
-- You reviewed the diff and **found nothing**. A legitimate, useful result.
-- You reviewed the diff and **found things**.
-- You **could not finish** — the diff was too large to hold, a file had no
-  patch and you needed it, an API call failed. Say that. Never present a partial
-  read as a clean one.
-
-## 6. Write the artefact
-
-One file per PR head, under `.smithers/review/` relative to your working
-directory (create it if absent):
-
-```text
-.smithers/review/<pr>-<first 12 chars of head sha>.code.json
-```
-
-```json
-{
-  "pr": 1234,
-  "head": "abc123def456",
-  "reviewedAt": "2026-09-07T00:00:00Z",
-  "rulesFile": "docs/reference/review-rules.md",
-  "rulesRef": "head",
-  "status": "reviewed",
-  "findings": [
-    {
-      "file": "packages/api/src/routes/thing.ts",
-      "line": 42,
-      "severity": "major",
-      "category": "correctness",
-      "summary": "one sentence stating the defect",
-      "why": "the failing case, concretely: these inputs produce this wrong output"
-    }
-  ]
-}
-```
-
-**`severity` is `major` or `minor`. Nothing else.** Not `high`, not `critical`,
-not `P1`. The step that posts these filters by severity, and it compares within
-a known vocabulary: a token it does not recognise is kept rather than dropped,
-so an invented level does not vanish — but it does defeat the filter, silently,
-while the filter carries on printing as though it were working. `P1`/`P2`/`P3`
-belong to the separate security review and are not yours to emit here.
-
-`category` is one of `correctness`, `claim`, `silent-failure`, `test`,
-`security`.
-
-**`status` is `reviewed` or `incomplete`.** `incomplete` takes a `reason`. An
-empty `findings` array on an `incomplete` review must never be read as clean,
-and the posting step refuses to post from one at all — which is the whole point
-of the field. Use it rather than shrinking the review to fit.
-
-`line` is a right-hand line number from the patches you read in step 2. Omit it
-if the finding is about the change as a whole rather than one line.
-
-## 7. Report, and stop
-
-Print counts by severity and category, the artefact path, and whether a rules
-file was found. Then **stop**.
-
-Do not post the findings. Do not open a review. Do not comment on the PR. If you
-were asked to review, you have done what was asked.

package/dist/assets/review/SWEEP.md

@@ -1,169 +0,0 @@
----
-name: pr-review-sweep
-description: Find the pull requests in scope that have no review for their current head, and review them. Use when a recurring card asks you to sweep a repository's open PRs. Reviews via the pr-review skill; posts nothing.
----
-
-# Sweeping a repository's open pull requests
-
-You are a Ninjafy agent (Ninjafy and Augmented Team are one platform, so you
-answer to the old name too). This skill is the loop that decides **which** pull
-requests get reviewed. The `pr-review` skill is what reviews one. Keep them
-separate: this one chooses, that one reads.
-
-**You post nothing, and neither does the review.** Every artefact this skill
-touches is a file under your own working directory.
-
----
-
-## 1. Read your scope — and refuse without one
-
-The card that woke you must name a scope. One of:
-
-- `label:<name>` — open PRs carrying that label
-- `author:<login>` — open PRs opened by that account
-- `prs:<n>,<n>,<n>` — an explicit list
-
-**If the card names no scope, review nothing.** Write the sweep summary
-(section 5) with `"status": "refused"` and `"reason": "no_scope"`, say so, and
-stop.
-
-This is not caution, it is the point. An unscoped sweep is "review every open
-PR", which at this repository's volume is the most expensive thing you could be
-asked to do, and nobody would have asked for it — they would have forgotten to
-say. A missing scope is a missing instruction, so the safe reading is *nothing*,
-never *everything*.
-
-You also need the repository as `owner/name`. If the card does not name one,
-that is `"reason": "no_repo"` and the same refusal.
-
-## 2. List the candidates
-
-```bash
-gh pr list --repo OWNER/NAME --state open --limit 100 \
-  --json number,headRefOid,title,isDraft,author
-```
-
-Add `--label <name>` or `--author <login>` per the scope.
-
-For a `prs:` scope, read each one with `gh api repos/OWNER/NAME/pulls/NUMBER`
-instead. **That payload names the same things differently** — `head.sha`, not
-`headRefOid`; `draft`, not `isDraft` — and it does not filter by state, so check
-`state` is `open` yourself and skip anything else. A closed PR reached this way
-would otherwise enter the sweep, which the `--state open` above rules out for
-every other scope.
-
-**Skip drafts.** A draft moves under you by design, so a review of one is
-usually filed against a head nobody will ever see again.
-
-The head sha is `headRefOid` from the list, or `head.sha` from the API.
-Everything below keys on its first 12 characters.
-
-## 3. Decide what to review — read the artefact, not just its name
-
-For each candidate, the artefact is:
-
-```text
-.smithers/review/<pr>-<first 12 chars of head sha>.code.json
-```
-
-**A file existing is not a review having happened.** Read it and branch on
-`status`:
-
-- **No file** → review it.
-- **`"status": "reviewed"`** → skip. This head has been reviewed, whether it
-  found anything or not. Count it as `alreadyReviewed`.
-- **`"status": "incomplete"`** → this is a review that could not finish — an API
-  call failed, the diff was unreadable, the PR moved twice. Retry it, **up to 3
-  attempts total**. Read its `attempts` field and **remember the number** — you
-  will need it in section 4, and it is about to be overwritten. An absent field
-  means 1. At 3 or more, skip it and count it as `abandoned`.
-
-Treating `incomplete` as done is the failure this branch exists to prevent: one
-transient API error would park that head forever, and the sweep would report a
-clean pass over a PR nobody ever read. Treating it as never-attempted is the
-opposite failure — an unreadable diff retried every five minutes for a week.
-
-A force-push changes the head, so it changes the filename, so it gets a fresh
-review with a fresh attempt count. You do not need to do anything about that.
-
-## 4. Review, up to the cap
-
-Review the candidates in ascending PR number, invoking the **`pr-review`** skill
-for each. **Stop after 3 reviews in one sweep** unless the card names a
-different `cap:<n>`. Count the rest as `skippedByCap`; the next tick takes them.
-
-The cap is a cost guard, not a queue-management nicety. Each review is a full
-read of a diff and costs real money against a shared subscription, and a sweep
-that finds thirty unreviewed PRs is exactly when you least want to run thirty
-reviews back to back.
-
-**After a retry, record the attempt — from the number you remembered, not from
-the file.** If the artefact `pr-review` just wrote is `incomplete`, set its
-`attempts` to **one more than the value you read in section 3** (which was 1 if
-the field was absent), then move on.
-
-`pr-review` overwrites the artefact: same filename, fresh body, no `attempts`
-field. So "increment what is in the file" reads 1 every time, the count never
-reaches 3, and an unreadable diff is retried every tick forever — the cap looking
-like it works while being unreachable. The remembered number is the only one
-that carries.
-
-### Do not read what the other reviewers said
-
-Never read `/reviews`, `/comments`, `/issues/NUMBER/comments`, or any other
-reviewer's findings, on any PR, at any point in this sweep.
-
-Your review has to be worth comparing against another reviewer's on the same
-commit, and a review that has read the other one is not evidence of anything.
-This is easy to do by accident — the endpoints are one call away and they look
-like context.
-
-## 5. Write the sweep summary — this is how anyone knows you ran
-
-Every sweep writes a summary, including a sweep that reviewed nothing and a
-sweep that refused.
-
-Append one line to `.smithers/review/sweep-log.jsonl`, and overwrite
-`.smithers/review/sweep-latest.json` with the same object:
-
-```json
-{
-  "at": "2026-09-09T04:00:00Z",
-  "status": "swept",
-  "repo": "owner/name",
-  "scope": "label:obi-wan-review",
-  "cap": 3,
-  "open": 12,
-  "candidates": 4,
-  "alreadyReviewed": 2,
-  "reviewed": [{ "pr": 1234, "head": "abc123def456", "status": "reviewed", "findings": 2 }],
-  "abandoned": [],
-  "skippedByCap": 1,
-  "posted": 0
-}
-```
-
-`status` is `swept` or `refused`; a `refused` summary carries `reason` and omits
-the sweep counts — **but still carries `"posted": 0`**, which is not one of them.
-It is the field the whole phase is checked on, and a summary that may drop it is
-a guarantee with a hole exactly where a refusal happened.
-
-**Write it even when the answer is boring, and especially then.** A reviewer
-that has quietly stopped working — a credential gone, the skill missing, an
-account at its limit — posts nothing and files nothing, which is precisely what
-a working reviewer looks like on a quiet day. The difference between the two is
-that one of them wrote this file. `"reviewed": []` with `"candidates": 0` is a
-healthy sweep. **No summary at all is the alarm.**
-
-`posted` is always `0`. It is in the summary because a number that is always
-zero is checkable, and a promise in prose is not.
-
-## 6. Report, and stop
-
-Say which repo and scope you swept, how many PRs were in scope, how many you
-reviewed, how many were already done, and anything you abandoned or capped.
-Name the summary file.
-
-Then stop. Do not post the findings. Do not open a review. Do not comment on any
-PR. Reviews are published by a separate, gated step that reads these artefacts —
-not by you, and not in this phase.