@integrity-labs/agt-cli 0.28.891 → 0.28.892

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",
@@ -37532,16 +37538,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.
@@ -37563,24 +37589,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",
@@ -29827,16 +29833,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.
@@ -29858,24 +29884,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",
@@ -43755,16 +43761,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.
@@ -43786,24 +43812,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/slack-channel.js

@@ -35724,6 +35724,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",
@@ -38392,16 +38398,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.
@@ -38423,24 +38449,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
   },
   {