@integrity-labs/agt-cli 0.28.891 → 0.28.893

package/dist/mcp/augmented-admin.js

@@ -21478,14 +21478,30 @@ var resumeAgentSchema = strictObject({
 });
 var listAlertsSchema = strictObject({
   severity: external_exports.string().max(16).optional().describe("Filter by severity (critical | warning | info)."),
-  // ENG-8566: without this, an old alert of a specific kind is unreachable —
-  // the listing is newest-first and capped at 100, and the open board exceeds
-  // that. Twelve slack_manifest_drift warnings sat unfindable for 48 days.
+  // ENG-8566: without this, an alert of a specific kind could be unreachable —
+  // the listing is capped at 100 and the open board exceeds that. Twelve
+  // slack_manifest_drift warnings sat unfindable for 48 days.
+  //
+  // ENG-10379 corrected the ordering claim this comment used to carry ("the
+  // listing is newest-first"). It is severity-first, then OLDEST-first within a
+  // severity, so the rows a truncated page drops are the NEWEST of the lowest
+  // severity present. `cursor` below is now the general escape hatch; `kind`
+  // remains the narrow one for when you already know what you are hunting.
   kind: external_exports.string().max(64).optional().describe(
-    "Filter by alert kind, exact match (e.g. slack_manifest_drift, host_down, integration_down). Use this to reach older alerts of one kind: the list is newest-first and capped at 100, so without a kind filter an old alert below that cutoff cannot be retrieved at all."
+    "Filter by alert kind, exact match (e.g. slack_manifest_drift, host_down, integration_down). ENG-10379: ordering is severity first (critical, then warning, then info) and OLDEST-first within each severity, so the rows a truncated page drops are the NEWEST of the lowest severity present - not the oldest. Page with `cursor` to reach them; `kind` narrows the set when you already know what you are looking for."
   ),
   open: external_exports.boolean().optional().describe("When true, only currently-open (unclosed) alerts."),
-  limit: limitSchema
+  limit: limitSchema,
+  // ENG-10379: the API has accepted a keyset `cursor` since ENG-9295 and returns
+  // `next_cursor`, but this schema never exposed one - and these schemas are
+  // STRICT, so a caller passing `cursor` was REJECTED rather than ignored. The
+  // paging existed and could not be driven from here, which is what left rows
+  // past the 100-row cap unreachable: on a board over the cap those are the
+  // NEWEST alerts of the lowest severity present, and one of them was a 25-hour
+  // channel outage nobody could see.
+  cursor: external_exports.string().min(1).max(512).optional().describe(
+    "Keyset cursor from a previous response's `next_cursor`. Pass it to fetch the NEXT page, and repeat until `next_cursor` is null to walk the whole board. Opaque: it encodes (severity_rank, opened_at, id) as one string, and a malformed cursor is refused rather than silently serving page one again."
+  )
 });
 var requestAccessSchema = strictObject({
   target_org_id: external_exports.string().min(1).max(64).describe("UUID of the customer organization to open scoped read access to."),
@@ -21693,7 +21709,7 @@ server.registerTool(
 );
 server.registerTool(
   "debug_list_alerts",
-  { description: "List recent platform alerts across authorized orgs (host-down, agent-stale, probe-timeout, auth-failed), including NULL-team host alerts. Returns a projection per alert (kind, severity, message, source, open/closed state), plus { count, total, truncated } \u2014 `total` is the matches before the 100-row cap, so `truncated: true` means you are NOT seeing everything. Filter with { kind, severity, open, limit }. **ENG-10030 \u2014 two fields that change how you read `message`.** `dedupe_key` is the alert's identity (`<kind>:<subject id>`), so it tells you which ROW an alert is about, not just which agent. `updated_at` tells you whether `message` is CURRENT: `open_alert` overwrites `message` on every re-raise but never touches `opened_at`, so a message is a snapshot unless the monitor re-raised that `(kind, dedupe_key)` since the alert opened \u2014 and it reads like live output either way. ONE DIRECTION IS PROOF, THE OTHER IS A HINT: `updated_at === opened_at` is CONCLUSIVE (never written since insert, so never re-raised, so `message` is frozen at `opened_at` \u2014 check this before proposing a fix for what a message describes, because the code may have moved since); `updated_at > opened_at` is SUGGESTIVE ONLY, because the `alerts_set_updated_at` trigger fires on EVERY write \u2014 an acknowledge, a snooze, a close, or a backfill migration. Compare against `acknowledged_at` / `snoozed_until` / `closed_at`: if `updated_at` matches one of them, that write was the human action, not a re-raise. Matching NONE of them is evidence of a re-raise but not proof, because a migration that touches the row leaves no timestamp of its own. Reading it as a biconditional is expensive: on one measured board 63 of 98 open alerts were acknowledged, so ~64% would falsely report current text. Two reads an hour apart remain the only unambiguous positive test. **Use `kind` to find older alerts**: results are newest-first and hard-capped at 100, so on a busy board an alert below that cutoff is unreachable without it (ENG-8566: 12 slack_manifest_drift warnings sat unfindable for 48 days for exactly this reason).", inputSchema: listAlertsSchema },
+  { description: "List recent platform alerts across authorized orgs (host-down, agent-stale, probe-timeout, auth-failed), including NULL-team host alerts. Returns a projection per alert (kind, severity, message, source, open/closed state), plus { count, total, truncated } \u2014 `total` is the matches before the 100-row cap, so `truncated: true` means you are NOT seeing everything. Filter with { kind, severity, open, limit }. **ENG-10030 \u2014 two fields that change how you read `message`.** `dedupe_key` is the alert's identity (`<kind>:<subject id>`), so it tells you which ROW an alert is about, not just which agent. `updated_at` tells you whether `message` is CURRENT: `open_alert` overwrites `message` on every re-raise but never touches `opened_at`, so a message is a snapshot unless the monitor re-raised that `(kind, dedupe_key)` since the alert opened \u2014 and it reads like live output either way. ONE DIRECTION IS PROOF, THE OTHER IS A HINT: `updated_at === opened_at` is CONCLUSIVE (never written since insert, so never re-raised, so `message` is frozen at `opened_at` \u2014 check this before proposing a fix for what a message describes, because the code may have moved since); `updated_at > opened_at` is SUGGESTIVE ONLY, because the `alerts_set_updated_at` trigger fires on EVERY write \u2014 an acknowledge, a snooze, a close, or a backfill migration. Compare against `acknowledged_at` / `snoozed_until` / `closed_at`: if `updated_at` matches one of them, that write was the human action, not a re-raise. Matching NONE of them is evidence of a re-raise but not proof, because a migration that touches the row leaves no timestamp of its own. Reading it as a biconditional is expensive: on one measured board 63 of 98 open alerts were acknowledged, so ~64% would falsely report current text. Two reads an hour apart remain the only unambiguous positive test. **ORDERING AND PAGING - ENG-10379, and the previous text here was wrong.** Results are ordered by SEVERITY first (critical, then warning, then info) and OLDEST-FIRST within each severity. They are not ordered newest first. So on a board past the 100-row cap, the rows dropped are the NEWEST alerts of the lowest severity present - which is how a sweep that reads one page missed a live 25-hour channel outage. `truncated: true` still means exactly what it always did (more matches exist than this page carries); to REACH them, pass `cursor` set to this response's `next_cursor` and repeat until `next_cursor` comes back null, which walks the whole board in order. `kind` still narrows the set when you already know what you are looking for (ENG-8566: 12 slack_manifest_drift warnings sat unfindable for 48 days).", inputSchema: listAlertsSchema },
   async (args) => {
     try {
       const result = await client.listAlerts(args);

package/dist/mcp/direct-chat-channel.js

@@ -34867,6 +34867,12 @@ function clampDirectChatHistoryLimit(raw) {
   return floored;
 }
 
+// ../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",
@@ -37520,28 +37526,72 @@ var FLAG_REGISTRY = [
   },
   {
     key: "app-top-nav-shell",
-    description: "Global top-navigation shell redesign (ENG-8478 epic / ENG-8486). When ON, the dashboard chrome replaces the left sidebar with a top navigation bar (team switcher \xB7 destinations \xB7 command palette + account) so the left side is free for an agent-scoped rail; when OFF, the existing left sidebar is unchanged. Additive layout gate \u2014 no data-model change. Composes independently with agent-unified-screen (the two flags are reconciled in ENG-8488). Ships dark.",
+    description: "Global top-navigation shell redesign (ENG-8478 epic / ENG-8486). When ON, the dashboard chrome replaces the left sidebar with a top navigation bar (team switcher \xB7 destinations \xB7 command palette + account) so the left side is free for an agent-scoped rail; when OFF, the existing left sidebar is unchanged. Additive layout gate \u2014 no data-model change. Composes independently with agent-unified-screen (the two flags are reconciled in ENG-8488). NO LONGER DARK: ENG-9831 cutover step 1 flipped the default to true, so an org with no override now gets the top-nav shell. The key survives only until cutover step 2 deletes it.",
     flagType: "boolean",
-    // Declared safe value is `false` = the current left sidebar. Fail-closed to the
-    // shell that ships today if the flag DB is unreachable.
-    defaultValue: false,
-    // Read CLIENT-SIDE by the dashboard layout + sidebar ("use client") via
-    // usePublicBooleanFlag, so the key must be in the browser-exposed public map.
-    // Additive layout gate — not sensitive.
+    // ENG-9831 (cutover step 1): flipped `false` -> `true`. The comment this
+    // replaces called `false` the fail-closed direction — "the shell that ships
+    // today". That was true while the sidebar was the shell that shipped; the
+    // top nav is now the one being cut over to, so `false` points at the layout
+    // being retired. The old rationale is recorded rather than deleted because
+    // it was correct under a premise that has expired.
+    //
+    // NOTE the same split as ninjafy-brand below: this value is 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 — that is
+    // the argument passed at the call site. Four call sites carry `true` to
+    // match: (dashboard)/layout.tsx and the three legacy redirect hubs
+    // (settings, team, organization/settings). Flipping the registry alone
+    // leaves the cutover half-applied.
+    defaultValue: true,
+    // ENG-9831: NO LONGER read client-side. It was — via usePublicBooleanFlag in
+    // sidebar.tsx (twice) and top-nav.tsx — and that is precisely what this
+    // slice removed: a client hook starts at its default and corrects after an
+    // async GET /flags, so the console painted the sidebar and then replaced the
+    // WHOLE dashboard chrome after hydration. The ENG-8858/ENG-9227 flash at
+    // layout scale. It is now resolved once server-side in (dashboard)/
+    // layout.tsx and passed to both shells as a required prop.
+    //
+    // `public` MUST STAY ANYWAY — the same trap documented on ninjafy-brand.
+    // getPublicBooleanFlagServer resolves against the very same public-filtered
+    // `GET /flags` the browser uses (routes/flags.ts filters to
+    // listPublicFlagKeys()). Drop `public` and the key is simply absent from the
+    // map, the server helper falls through to its default forever, and every org
+    // silently gets whatever that default happens to be with no error anywhere.
+    // `public` means "readable through the public map", not "read by a browser".
     public: true
   },
   {
     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.
@@ -37563,24 +37613,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/mcp/index.js

@@ -27363,6 +27363,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",
@@ -29815,28 +29821,72 @@ var FLAG_REGISTRY = [
   },
   {
     key: "app-top-nav-shell",
-    description: "Global top-navigation shell redesign (ENG-8478 epic / ENG-8486). When ON, the dashboard chrome replaces the left sidebar with a top navigation bar (team switcher \xB7 destinations \xB7 command palette + account) so the left side is free for an agent-scoped rail; when OFF, the existing left sidebar is unchanged. Additive layout gate \u2014 no data-model change. Composes independently with agent-unified-screen (the two flags are reconciled in ENG-8488). Ships dark.",
+    description: "Global top-navigation shell redesign (ENG-8478 epic / ENG-8486). When ON, the dashboard chrome replaces the left sidebar with a top navigation bar (team switcher \xB7 destinations \xB7 command palette + account) so the left side is free for an agent-scoped rail; when OFF, the existing left sidebar is unchanged. Additive layout gate \u2014 no data-model change. Composes independently with agent-unified-screen (the two flags are reconciled in ENG-8488). NO LONGER DARK: ENG-9831 cutover step 1 flipped the default to true, so an org with no override now gets the top-nav shell. The key survives only until cutover step 2 deletes it.",
     flagType: "boolean",
-    // Declared safe value is `false` = the current left sidebar. Fail-closed to the
-    // shell that ships today if the flag DB is unreachable.
-    defaultValue: false,
-    // Read CLIENT-SIDE by the dashboard layout + sidebar ("use client") via
-    // usePublicBooleanFlag, so the key must be in the browser-exposed public map.
-    // Additive layout gate — not sensitive.
+    // ENG-9831 (cutover step 1): flipped `false` -> `true`. The comment this
+    // replaces called `false` the fail-closed direction — "the shell that ships
+    // today". That was true while the sidebar was the shell that shipped; the
+    // top nav is now the one being cut over to, so `false` points at the layout
+    // being retired. The old rationale is recorded rather than deleted because
+    // it was correct under a premise that has expired.
+    //
+    // NOTE the same split as ninjafy-brand below: this value is 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 — that is
+    // the argument passed at the call site. Four call sites carry `true` to
+    // match: (dashboard)/layout.tsx and the three legacy redirect hubs
+    // (settings, team, organization/settings). Flipping the registry alone
+    // leaves the cutover half-applied.
+    defaultValue: true,
+    // ENG-9831: NO LONGER read client-side. It was — via usePublicBooleanFlag in
+    // sidebar.tsx (twice) and top-nav.tsx — and that is precisely what this
+    // slice removed: a client hook starts at its default and corrects after an
+    // async GET /flags, so the console painted the sidebar and then replaced the
+    // WHOLE dashboard chrome after hydration. The ENG-8858/ENG-9227 flash at
+    // layout scale. It is now resolved once server-side in (dashboard)/
+    // layout.tsx and passed to both shells as a required prop.
+    //
+    // `public` MUST STAY ANYWAY — the same trap documented on ninjafy-brand.
+    // getPublicBooleanFlagServer resolves against the very same public-filtered
+    // `GET /flags` the browser uses (routes/flags.ts filters to
+    // listPublicFlagKeys()). Drop `public` and the key is simply absent from the
+    // map, the server helper falls through to its default forever, and every org
+    // silently gets whatever that default happens to be with no error anywhere.
+    // `public` means "readable through the public map", not "read by a browser".
     public: true
   },
   {
     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.
@@ -29858,24 +29908,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/mcp/origami.js

@@ -41494,6 +41494,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",
@@ -43743,28 +43749,72 @@ var FLAG_REGISTRY = [
   },
   {
     key: "app-top-nav-shell",
-    description: "Global top-navigation shell redesign (ENG-8478 epic / ENG-8486). When ON, the dashboard chrome replaces the left sidebar with a top navigation bar (team switcher \xB7 destinations \xB7 command palette + account) so the left side is free for an agent-scoped rail; when OFF, the existing left sidebar is unchanged. Additive layout gate \u2014 no data-model change. Composes independently with agent-unified-screen (the two flags are reconciled in ENG-8488). Ships dark.",
+    description: "Global top-navigation shell redesign (ENG-8478 epic / ENG-8486). When ON, the dashboard chrome replaces the left sidebar with a top navigation bar (team switcher \xB7 destinations \xB7 command palette + account) so the left side is free for an agent-scoped rail; when OFF, the existing left sidebar is unchanged. Additive layout gate \u2014 no data-model change. Composes independently with agent-unified-screen (the two flags are reconciled in ENG-8488). NO LONGER DARK: ENG-9831 cutover step 1 flipped the default to true, so an org with no override now gets the top-nav shell. The key survives only until cutover step 2 deletes it.",
     flagType: "boolean",
-    // Declared safe value is `false` = the current left sidebar. Fail-closed to the
-    // shell that ships today if the flag DB is unreachable.
-    defaultValue: false,
-    // Read CLIENT-SIDE by the dashboard layout + sidebar ("use client") via
-    // usePublicBooleanFlag, so the key must be in the browser-exposed public map.
-    // Additive layout gate — not sensitive.
+    // ENG-9831 (cutover step 1): flipped `false` -> `true`. The comment this
+    // replaces called `false` the fail-closed direction — "the shell that ships
+    // today". That was true while the sidebar was the shell that shipped; the
+    // top nav is now the one being cut over to, so `false` points at the layout
+    // being retired. The old rationale is recorded rather than deleted because
+    // it was correct under a premise that has expired.
+    //
+    // NOTE the same split as ninjafy-brand below: this value is 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 — that is
+    // the argument passed at the call site. Four call sites carry `true` to
+    // match: (dashboard)/layout.tsx and the three legacy redirect hubs
+    // (settings, team, organization/settings). Flipping the registry alone
+    // leaves the cutover half-applied.
+    defaultValue: true,
+    // ENG-9831: NO LONGER read client-side. It was — via usePublicBooleanFlag in
+    // sidebar.tsx (twice) and top-nav.tsx — and that is precisely what this
+    // slice removed: a client hook starts at its default and corrects after an
+    // async GET /flags, so the console painted the sidebar and then replaced the
+    // WHOLE dashboard chrome after hydration. The ENG-8858/ENG-9227 flash at
+    // layout scale. It is now resolved once server-side in (dashboard)/
+    // layout.tsx and passed to both shells as a required prop.
+    //
+    // `public` MUST STAY ANYWAY — the same trap documented on ninjafy-brand.
+    // getPublicBooleanFlagServer resolves against the very same public-filtered
+    // `GET /flags` the browser uses (routes/flags.ts filters to
+    // listPublicFlagKeys()). Drop `public` and the key is simply absent from the
+    // map, the server helper falls through to its default forever, and every org
+    // silently gets whatever that default happens to be with no error anywhere.
+    // `public` means "readable through the public map", not "read by a browser".
     public: true
   },
   {
     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.
@@ -43786,24 +43836,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
   },
   {