@integrity-labs/agt-cli 0.28.716 → 0.28.718

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

@@ -34307,6 +34307,104 @@ var AGENT_DIRECTED_NOTICE_KINDS = [
   "waiting_on_agent"
 ];
 var AGENT_DIRECTED_KIND_SET = new Set(AGENT_DIRECTED_NOTICE_KINDS);
+var NOTICE_KIND_AUDIENCE = {
+  // ---- USER -------------------------------------------------------------
+  // An integration broke and only the customer can reconnect it. Carries the
+  // ENG-7652 deep link and renders as the ENG-9256 card — the one notice kind
+  // that already earned a bespoke renderer.
+  integration_failure: "user",
+  // The other half of that pair: the thing you were asked to reconnect is working
+  // again. Kept visible even though it needs no ACTION, because it closes a loop
+  // the customer was explicitly pulled into — hiding it would leave the reconnect
+  // card as the last word on a problem that is now fixed.
+  //
+  // ENG-9592 left a wart here and recorded it: two of the three recovery arms
+  // were written in the second person to the AGENT ("mention it to your owner",
+  // "your session will pick it up"), which reads as nonsense to the customer now
+  // seeing the same string. ENG-9609 rewrote all three to be true for both
+  // readers and pinned it in `eng-9609-recovery-copy-dual-audience.test.ts`.
+  // The note is deleted rather than updated: a deferral that outlives the thing
+  // it defers is just a false claim about the code.
+  integration_recovered: "user",
+  // The form itself. `direct-chat-form.ts` calls it "the agent→user render
+  // message"; hiding it would remove the control the user is meant to fill in.
+  form_request_render: "user",
+  // ENG-9592: the outcome chip for a button the user just pressed — "already
+  // resolved", "only the manager can approve", the re-prompt. Its producer says
+  // it exists so the click does not "look like it did nothing", which is exactly
+  // an answer owed to a person. See the note on the stamped payload below.
+  approval_outcome: "user",
+  // ---- AGENT ------------------------------------------------------------
+  // The ENG-9592 report's headline kind: parked-card pickup instructions, in the
+  // second person, ending in an order not to reply in direct-chat.
+  waiting_response: "agent",
+  // Already agent-directed before this change; each is summarised above and its
+  // reasoning lives beside its entry in AGENT_DIRECTED_NOTICE_KINDS.
+  scheduled_task_nudge: "agent",
+  kanban_check: "agent",
+  manager_feedback: "agent",
+  form_timeout: "agent",
+  integration_connected: "agent",
+  offer_result: "agent",
+  waiting_on_agent: "agent",
+  // "The user submitted your form … Use payload.values to continue the user's
+  // task" — a delivery mechanism, with a raw request uuid. The user submitted it;
+  // they do not need to be told they did.
+  form_result: "agent",
+  // Same shape for a tapped button: "The user tapped X on your button prompt
+  // (request `<uuid>`)". They tapped it.
+  button_click: "agent",
+  // ENG-9397: tells the agent a question was answered AFTER it stopped listening
+  // so it does not report the person as silent. The person's own answer goes
+  // back on the channel they tapped in, not here.
+  late_button_click: "agent",
+  // Broker grant resolutions. Second person to the agent, and each carries the
+  // grant uuid the tool contracts explicitly forbid showing a user ("NEVER paste
+  // the grant UUID into user-facing prose"). Two of these are in the report.
+  supabase_grant_resolved: "agent",
+  supabase_grant_denied: "agent",
+  aws_grant_resolved: "agent",
+  aws_grant_denied: "agent",
+  gcp_grant_resolved: "agent",
+  gcp_grant_denied: "agent",
+  // HITL tool-call approvals: "Do NOT call this tool again, do NOT claim the
+  // action happened, and do NOT poll".
+  integration_invoke_resolved: "agent",
+  integration_invoke_denied: "agent",
+  // Support/recruit approvals — same shape, agent resumes the provisioning.
+  recruit_resolved: "agent",
+  recruit_denied: "agent",
+  // "Your `<verb>` approval request (`<uuid>`) EXPIRED at …" — in the report,
+  // uuid and all.
+  approval_expired: "agent",
+  // A routine fired; the agent picks the work up.
+  routine_firing_result: "agent",
+  // Live-advisor wake: "Call `live_read` with escalation_id …" — a literal tool
+  // call addressed to the machine.
+  live_advisor_escalation: "agent",
+  live_advisor_session_open: "agent",
+  // The assigner reopened a card and the agent must work it again.
+  assigner_reopen: "agent",
+  // An inbound trigger event delivered onto the rail for the agent to handle.
+  // Named `trigger_event` by `triggerDeliveryPayload` — NOT `trigger_delivery`,
+  // which is what the producing module is called. Read from the builder.
+  trigger_event: "agent",
+  // Operational degradation routed into the agent's chat by the alert bridge.
+  degradation_alert: "agent",
+  // ENG-9592: probes and synthetic prompts, previously carrying NO payload at
+  // all and therefore unclassifiable. Stamped at their producers so the verdict
+  // is recorded rather than inherited from the default. `agent_probe` covers
+  // both probe kinds (liveness and the board nudge); the specific one is
+  // `payload.probe_kind`, so a new probe kind needs no entry here.
+  agent_probe: "agent",
+  agent_question_probe: "agent",
+  kanban_confirm_prompt: "agent"
+};
+var USER_FACING_KIND_SET = new Set(Object.entries(NOTICE_KIND_AUDIENCE).filter(([, audience]) => audience === "user").map(([kind]) => kind));
+var USER_FACING_NOTICE_KINDS = Object.freeze([
+  ...USER_FACING_KIND_SET
+]);
+var HIDDEN_NOTICE_KINDS = Object.freeze(Object.entries(NOTICE_KIND_AUDIENCE).filter(([, audience]) => audience === "agent").map(([kind]) => kind));
 
 // ../core/dist/direct-chat/cursor-advance.js
 var CURSOR_ADVANCE_NON_SHORTFALL_KEYS = ["advanced", "advanced_unreported", "failed"];
@@ -34991,6 +35089,12 @@ var WAITING_KINDS = [
 ];
 var WAITING_KIND_SET = new Set(WAITING_KINDS);
 
+// ../core/dist/alerts/age.js
+var MINUTE_MS = 6e4;
+var HOUR_MS = 60 * MINUTE_MS;
+var DAY_MS = 24 * HOUR_MS;
+var ALERT_AGE_SEVERITY_FLOORS = [{ afterMs: 24 * HOUR_MS, floor: "critical" }];
+
 // ../core/dist/conversations/metrics.js
 var PERIOD_CONFIG = {
   "24h": { windowMs: 24 * 60 * 60 * 1e3, bucket: "hour" },
@@ -36418,6 +36522,25 @@ var FLAG_REGISTRY = [
     // deliberate, audited per-org flip (ADR-0022 §4).
     sensitive: true
   },
+  {
+    key: "email-require-approval-enforcement",
+    description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are armed by an org-scoped override written at org creation; existing orgs stay off until an operator flips them. Evaluated per-org. Ships dark.',
+    flagType: "boolean",
+    // Declared safe value is `false` (no hold). A flag-DB read error degrades here, so a flags
+    // outage can never silently start holding real customer email — the same fail-OPEN posture
+    // enforceEmailDomainGuard already takes, and the opposite of the enforcement resolver's
+    // fail-CLOSED, deliberately: a control that cannot verify itself must not block mail.
+    // No envVar: net-new control with no pre-flags env gate to migrate (ADR-0022).
+    defaultValue: false,
+    // Turning it on holds real customer email pending a human tap, so it is a deliberate,
+    // audited per-org flip (ADR-0022 §4).
+    sensitive: true,
+    // ENG-9629: NEW orgs are armed on. Declared here rather than hardcoded in the
+    // seeding code, so `listNewOrgFlagOverrides()` is the one answer to "which flags
+    // does a new org get". `defaultValue` stays false so the ~4 months of orgs already
+    // carrying an inert enforce-level email.require_approval row are NOT armed on deploy.
+    newOrgOverride: true
+  },
   {
     key: "email-guard-require-approval-enabled",
     description: "Platform enable-gate for the email-domain guardrail REQUIRE_APPROVAL stage (ENG-7939). When ON for an org, a scope at email_guard_stage=require_approval routes a send to a non-allowed domain into Human Approval (an Approve/Deny card) instead of a hard block: the rollout UI unlocks the option and the write routes accept require_approval. When OFF (default) the write routes reject require_approval and the UI shows it as not yet available, so no scope can select it. Structurally also depends on hitl-approval-routing being on (the approval broker fails closed to a hard block when routing is off). Evaluated per-org. Ships dark.",

package/dist/mcp/index.js

@@ -41723,6 +41723,104 @@ var AGENT_DIRECTED_NOTICE_KINDS = [
   "waiting_on_agent"
 ];
 var AGENT_DIRECTED_KIND_SET = new Set(AGENT_DIRECTED_NOTICE_KINDS);
+var NOTICE_KIND_AUDIENCE = {
+  // ---- USER -------------------------------------------------------------
+  // An integration broke and only the customer can reconnect it. Carries the
+  // ENG-7652 deep link and renders as the ENG-9256 card — the one notice kind
+  // that already earned a bespoke renderer.
+  integration_failure: "user",
+  // The other half of that pair: the thing you were asked to reconnect is working
+  // again. Kept visible even though it needs no ACTION, because it closes a loop
+  // the customer was explicitly pulled into — hiding it would leave the reconnect
+  // card as the last word on a problem that is now fixed.
+  //
+  // ENG-9592 left a wart here and recorded it: two of the three recovery arms
+  // were written in the second person to the AGENT ("mention it to your owner",
+  // "your session will pick it up"), which reads as nonsense to the customer now
+  // seeing the same string. ENG-9609 rewrote all three to be true for both
+  // readers and pinned it in `eng-9609-recovery-copy-dual-audience.test.ts`.
+  // The note is deleted rather than updated: a deferral that outlives the thing
+  // it defers is just a false claim about the code.
+  integration_recovered: "user",
+  // The form itself. `direct-chat-form.ts` calls it "the agent→user render
+  // message"; hiding it would remove the control the user is meant to fill in.
+  form_request_render: "user",
+  // ENG-9592: the outcome chip for a button the user just pressed — "already
+  // resolved", "only the manager can approve", the re-prompt. Its producer says
+  // it exists so the click does not "look like it did nothing", which is exactly
+  // an answer owed to a person. See the note on the stamped payload below.
+  approval_outcome: "user",
+  // ---- AGENT ------------------------------------------------------------
+  // The ENG-9592 report's headline kind: parked-card pickup instructions, in the
+  // second person, ending in an order not to reply in direct-chat.
+  waiting_response: "agent",
+  // Already agent-directed before this change; each is summarised above and its
+  // reasoning lives beside its entry in AGENT_DIRECTED_NOTICE_KINDS.
+  scheduled_task_nudge: "agent",
+  kanban_check: "agent",
+  manager_feedback: "agent",
+  form_timeout: "agent",
+  integration_connected: "agent",
+  offer_result: "agent",
+  waiting_on_agent: "agent",
+  // "The user submitted your form … Use payload.values to continue the user's
+  // task" — a delivery mechanism, with a raw request uuid. The user submitted it;
+  // they do not need to be told they did.
+  form_result: "agent",
+  // Same shape for a tapped button: "The user tapped X on your button prompt
+  // (request `<uuid>`)". They tapped it.
+  button_click: "agent",
+  // ENG-9397: tells the agent a question was answered AFTER it stopped listening
+  // so it does not report the person as silent. The person's own answer goes
+  // back on the channel they tapped in, not here.
+  late_button_click: "agent",
+  // Broker grant resolutions. Second person to the agent, and each carries the
+  // grant uuid the tool contracts explicitly forbid showing a user ("NEVER paste
+  // the grant UUID into user-facing prose"). Two of these are in the report.
+  supabase_grant_resolved: "agent",
+  supabase_grant_denied: "agent",
+  aws_grant_resolved: "agent",
+  aws_grant_denied: "agent",
+  gcp_grant_resolved: "agent",
+  gcp_grant_denied: "agent",
+  // HITL tool-call approvals: "Do NOT call this tool again, do NOT claim the
+  // action happened, and do NOT poll".
+  integration_invoke_resolved: "agent",
+  integration_invoke_denied: "agent",
+  // Support/recruit approvals — same shape, agent resumes the provisioning.
+  recruit_resolved: "agent",
+  recruit_denied: "agent",
+  // "Your `<verb>` approval request (`<uuid>`) EXPIRED at …" — in the report,
+  // uuid and all.
+  approval_expired: "agent",
+  // A routine fired; the agent picks the work up.
+  routine_firing_result: "agent",
+  // Live-advisor wake: "Call `live_read` with escalation_id …" — a literal tool
+  // call addressed to the machine.
+  live_advisor_escalation: "agent",
+  live_advisor_session_open: "agent",
+  // The assigner reopened a card and the agent must work it again.
+  assigner_reopen: "agent",
+  // An inbound trigger event delivered onto the rail for the agent to handle.
+  // Named `trigger_event` by `triggerDeliveryPayload` — NOT `trigger_delivery`,
+  // which is what the producing module is called. Read from the builder.
+  trigger_event: "agent",
+  // Operational degradation routed into the agent's chat by the alert bridge.
+  degradation_alert: "agent",
+  // ENG-9592: probes and synthetic prompts, previously carrying NO payload at
+  // all and therefore unclassifiable. Stamped at their producers so the verdict
+  // is recorded rather than inherited from the default. `agent_probe` covers
+  // both probe kinds (liveness and the board nudge); the specific one is
+  // `payload.probe_kind`, so a new probe kind needs no entry here.
+  agent_probe: "agent",
+  agent_question_probe: "agent",
+  kanban_confirm_prompt: "agent"
+};
+var USER_FACING_KIND_SET = new Set(Object.entries(NOTICE_KIND_AUDIENCE).filter(([, audience]) => audience === "user").map(([kind]) => kind));
+var USER_FACING_NOTICE_KINDS = Object.freeze([
+  ...USER_FACING_KIND_SET
+]);
+var HIDDEN_NOTICE_KINDS = Object.freeze(Object.entries(NOTICE_KIND_AUDIENCE).filter(([, audience]) => audience === "agent").map(([kind]) => kind));
 
 // ../core/dist/direct-chat/cursor-advance.js
 var CURSOR_ADVANCE_NON_SHORTFALL_KEYS = ["advanced", "advanced_unreported", "failed"];
@@ -41968,6 +42066,12 @@ function describeReportsToOutcome(resolved) {
   }
 }
 
+// ../core/dist/alerts/age.js
+var MINUTE_MS = 6e4;
+var HOUR_MS = 60 * MINUTE_MS;
+var DAY_MS = 24 * HOUR_MS;
+var ALERT_AGE_SEVERITY_FLOORS = [{ afterMs: 24 * HOUR_MS, floor: "critical" }];
+
 // ../core/dist/conversations/metrics.js
 var PERIOD_CONFIG = {
   "24h": { windowMs: 24 * 60 * 60 * 1e3, bucket: "hour" },
@@ -43395,6 +43499,25 @@ var FLAG_REGISTRY = [
     // deliberate, audited per-org flip (ADR-0022 §4).
     sensitive: true
   },
+  {
+    key: "email-require-approval-enforcement",
+    description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are armed by an org-scoped override written at org creation; existing orgs stay off until an operator flips them. Evaluated per-org. Ships dark.',
+    flagType: "boolean",
+    // Declared safe value is `false` (no hold). A flag-DB read error degrades here, so a flags
+    // outage can never silently start holding real customer email — the same fail-OPEN posture
+    // enforceEmailDomainGuard already takes, and the opposite of the enforcement resolver's
+    // fail-CLOSED, deliberately: a control that cannot verify itself must not block mail.
+    // No envVar: net-new control with no pre-flags env gate to migrate (ADR-0022).
+    defaultValue: false,
+    // Turning it on holds real customer email pending a human tap, so it is a deliberate,
+    // audited per-org flip (ADR-0022 §4).
+    sensitive: true,
+    // ENG-9629: NEW orgs are armed on. Declared here rather than hardcoded in the
+    // seeding code, so `listNewOrgFlagOverrides()` is the one answer to "which flags
+    // does a new org get". `defaultValue` stays false so the ~4 months of orgs already
+    // carrying an inert enforce-level email.require_approval row are NOT armed on deploy.
+    newOrgOverride: true
+  },
   {
     key: "email-guard-require-approval-enabled",
     description: "Platform enable-gate for the email-domain guardrail REQUIRE_APPROVAL stage (ENG-7939). When ON for an org, a scope at email_guard_stage=require_approval routes a send to a non-allowed domain into Human Approval (an Approve/Deny card) instead of a hard block: the rollout UI unlocks the option and the write routes accept require_approval. When OFF (default) the write routes reject require_approval and the UI shows it as not yet available, so no scope can select it. Structurally also depends on hitl-approval-routing being on (the approval broker fails closed to a hard block when routing is off). Evaluated per-org. Ships dark.",

package/dist/mcp/origami.js

@@ -40515,6 +40515,104 @@ var AGENT_DIRECTED_NOTICE_KINDS = [
   "waiting_on_agent"
 ];
 var AGENT_DIRECTED_KIND_SET = new Set(AGENT_DIRECTED_NOTICE_KINDS);
+var NOTICE_KIND_AUDIENCE = {
+  // ---- USER -------------------------------------------------------------
+  // An integration broke and only the customer can reconnect it. Carries the
+  // ENG-7652 deep link and renders as the ENG-9256 card — the one notice kind
+  // that already earned a bespoke renderer.
+  integration_failure: "user",
+  // The other half of that pair: the thing you were asked to reconnect is working
+  // again. Kept visible even though it needs no ACTION, because it closes a loop
+  // the customer was explicitly pulled into — hiding it would leave the reconnect
+  // card as the last word on a problem that is now fixed.
+  //
+  // ENG-9592 left a wart here and recorded it: two of the three recovery arms
+  // were written in the second person to the AGENT ("mention it to your owner",
+  // "your session will pick it up"), which reads as nonsense to the customer now
+  // seeing the same string. ENG-9609 rewrote all three to be true for both
+  // readers and pinned it in `eng-9609-recovery-copy-dual-audience.test.ts`.
+  // The note is deleted rather than updated: a deferral that outlives the thing
+  // it defers is just a false claim about the code.
+  integration_recovered: "user",
+  // The form itself. `direct-chat-form.ts` calls it "the agent→user render
+  // message"; hiding it would remove the control the user is meant to fill in.
+  form_request_render: "user",
+  // ENG-9592: the outcome chip for a button the user just pressed — "already
+  // resolved", "only the manager can approve", the re-prompt. Its producer says
+  // it exists so the click does not "look like it did nothing", which is exactly
+  // an answer owed to a person. See the note on the stamped payload below.
+  approval_outcome: "user",
+  // ---- AGENT ------------------------------------------------------------
+  // The ENG-9592 report's headline kind: parked-card pickup instructions, in the
+  // second person, ending in an order not to reply in direct-chat.
+  waiting_response: "agent",
+  // Already agent-directed before this change; each is summarised above and its
+  // reasoning lives beside its entry in AGENT_DIRECTED_NOTICE_KINDS.
+  scheduled_task_nudge: "agent",
+  kanban_check: "agent",
+  manager_feedback: "agent",
+  form_timeout: "agent",
+  integration_connected: "agent",
+  offer_result: "agent",
+  waiting_on_agent: "agent",
+  // "The user submitted your form … Use payload.values to continue the user's
+  // task" — a delivery mechanism, with a raw request uuid. The user submitted it;
+  // they do not need to be told they did.
+  form_result: "agent",
+  // Same shape for a tapped button: "The user tapped X on your button prompt
+  // (request `<uuid>`)". They tapped it.
+  button_click: "agent",
+  // ENG-9397: tells the agent a question was answered AFTER it stopped listening
+  // so it does not report the person as silent. The person's own answer goes
+  // back on the channel they tapped in, not here.
+  late_button_click: "agent",
+  // Broker grant resolutions. Second person to the agent, and each carries the
+  // grant uuid the tool contracts explicitly forbid showing a user ("NEVER paste
+  // the grant UUID into user-facing prose"). Two of these are in the report.
+  supabase_grant_resolved: "agent",
+  supabase_grant_denied: "agent",
+  aws_grant_resolved: "agent",
+  aws_grant_denied: "agent",
+  gcp_grant_resolved: "agent",
+  gcp_grant_denied: "agent",
+  // HITL tool-call approvals: "Do NOT call this tool again, do NOT claim the
+  // action happened, and do NOT poll".
+  integration_invoke_resolved: "agent",
+  integration_invoke_denied: "agent",
+  // Support/recruit approvals — same shape, agent resumes the provisioning.
+  recruit_resolved: "agent",
+  recruit_denied: "agent",
+  // "Your `<verb>` approval request (`<uuid>`) EXPIRED at …" — in the report,
+  // uuid and all.
+  approval_expired: "agent",
+  // A routine fired; the agent picks the work up.
+  routine_firing_result: "agent",
+  // Live-advisor wake: "Call `live_read` with escalation_id …" — a literal tool
+  // call addressed to the machine.
+  live_advisor_escalation: "agent",
+  live_advisor_session_open: "agent",
+  // The assigner reopened a card and the agent must work it again.
+  assigner_reopen: "agent",
+  // An inbound trigger event delivered onto the rail for the agent to handle.
+  // Named `trigger_event` by `triggerDeliveryPayload` — NOT `trigger_delivery`,
+  // which is what the producing module is called. Read from the builder.
+  trigger_event: "agent",
+  // Operational degradation routed into the agent's chat by the alert bridge.
+  degradation_alert: "agent",
+  // ENG-9592: probes and synthetic prompts, previously carrying NO payload at
+  // all and therefore unclassifiable. Stamped at their producers so the verdict
+  // is recorded rather than inherited from the default. `agent_probe` covers
+  // both probe kinds (liveness and the board nudge); the specific one is
+  // `payload.probe_kind`, so a new probe kind needs no entry here.
+  agent_probe: "agent",
+  agent_question_probe: "agent",
+  kanban_confirm_prompt: "agent"
+};
+var USER_FACING_KIND_SET = new Set(Object.entries(NOTICE_KIND_AUDIENCE).filter(([, audience]) => audience === "user").map(([kind]) => kind));
+var USER_FACING_NOTICE_KINDS = Object.freeze([
+  ...USER_FACING_KIND_SET
+]);
+var HIDDEN_NOTICE_KINDS = Object.freeze(Object.entries(NOTICE_KIND_AUDIENCE).filter(([, audience]) => audience === "agent").map(([kind]) => kind));
 
 // ../core/dist/direct-chat/cursor-advance.js
 var CURSOR_ADVANCE_NON_SHORTFALL_KEYS = ["advanced", "advanced_unreported", "failed"];
@@ -40739,6 +40837,12 @@ var WAITING_KINDS = [
 ];
 var WAITING_KIND_SET = new Set(WAITING_KINDS);
 
+// ../core/dist/alerts/age.js
+var MINUTE_MS = 6e4;
+var HOUR_MS = 60 * MINUTE_MS;
+var DAY_MS = 24 * HOUR_MS;
+var ALERT_AGE_SEVERITY_FLOORS = [{ afterMs: 24 * HOUR_MS, floor: "critical" }];
+
 // ../core/dist/conversations/metrics.js
 var PERIOD_CONFIG = {
   "24h": { windowMs: 24 * 60 * 60 * 1e3, bucket: "hour" },
@@ -42166,6 +42270,25 @@ var FLAG_REGISTRY = [
     // deliberate, audited per-org flip (ADR-0022 §4).
     sensitive: true
   },
+  {
+    key: "email-require-approval-enforcement",
+    description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are armed by an org-scoped override written at org creation; existing orgs stay off until an operator flips them. Evaluated per-org. Ships dark.',
+    flagType: "boolean",
+    // Declared safe value is `false` (no hold). A flag-DB read error degrades here, so a flags
+    // outage can never silently start holding real customer email — the same fail-OPEN posture
+    // enforceEmailDomainGuard already takes, and the opposite of the enforcement resolver's
+    // fail-CLOSED, deliberately: a control that cannot verify itself must not block mail.
+    // No envVar: net-new control with no pre-flags env gate to migrate (ADR-0022).
+    defaultValue: false,
+    // Turning it on holds real customer email pending a human tap, so it is a deliberate,
+    // audited per-org flip (ADR-0022 §4).
+    sensitive: true,
+    // ENG-9629: NEW orgs are armed on. Declared here rather than hardcoded in the
+    // seeding code, so `listNewOrgFlagOverrides()` is the one answer to "which flags
+    // does a new org get". `defaultValue` stays false so the ~4 months of orgs already
+    // carrying an inert enforce-level email.require_approval row are NOT armed on deploy.
+    newOrgOverride: true
+  },
   {
     key: "email-guard-require-approval-enabled",
     description: "Platform enable-gate for the email-domain guardrail REQUIRE_APPROVAL stage (ENG-7939). When ON for an org, a scope at email_guard_stage=require_approval routes a send to a non-allowed domain into Human Approval (an Approve/Deny card) instead of a hard block: the rollout UI unlocks the option and the write routes accept require_approval. When OFF (default) the write routes reject require_approval and the UI shows it as not yet available, so no scope can select it. Structurally also depends on hitl-approval-routing being on (the approval broker fails closed to a hard block when routing is off). Evaluated per-org. Ships dark.",

package/dist/mcp/slack-channel.js

@@ -34628,6 +34628,104 @@ var AGENT_DIRECTED_NOTICE_KINDS = [
   "waiting_on_agent"
 ];
 var AGENT_DIRECTED_KIND_SET = new Set(AGENT_DIRECTED_NOTICE_KINDS);
+var NOTICE_KIND_AUDIENCE = {
+  // ---- USER -------------------------------------------------------------
+  // An integration broke and only the customer can reconnect it. Carries the
+  // ENG-7652 deep link and renders as the ENG-9256 card — the one notice kind
+  // that already earned a bespoke renderer.
+  integration_failure: "user",
+  // The other half of that pair: the thing you were asked to reconnect is working
+  // again. Kept visible even though it needs no ACTION, because it closes a loop
+  // the customer was explicitly pulled into — hiding it would leave the reconnect
+  // card as the last word on a problem that is now fixed.
+  //
+  // ENG-9592 left a wart here and recorded it: two of the three recovery arms
+  // were written in the second person to the AGENT ("mention it to your owner",
+  // "your session will pick it up"), which reads as nonsense to the customer now
+  // seeing the same string. ENG-9609 rewrote all three to be true for both
+  // readers and pinned it in `eng-9609-recovery-copy-dual-audience.test.ts`.
+  // The note is deleted rather than updated: a deferral that outlives the thing
+  // it defers is just a false claim about the code.
+  integration_recovered: "user",
+  // The form itself. `direct-chat-form.ts` calls it "the agent→user render
+  // message"; hiding it would remove the control the user is meant to fill in.
+  form_request_render: "user",
+  // ENG-9592: the outcome chip for a button the user just pressed — "already
+  // resolved", "only the manager can approve", the re-prompt. Its producer says
+  // it exists so the click does not "look like it did nothing", which is exactly
+  // an answer owed to a person. See the note on the stamped payload below.
+  approval_outcome: "user",
+  // ---- AGENT ------------------------------------------------------------
+  // The ENG-9592 report's headline kind: parked-card pickup instructions, in the
+  // second person, ending in an order not to reply in direct-chat.
+  waiting_response: "agent",
+  // Already agent-directed before this change; each is summarised above and its
+  // reasoning lives beside its entry in AGENT_DIRECTED_NOTICE_KINDS.
+  scheduled_task_nudge: "agent",
+  kanban_check: "agent",
+  manager_feedback: "agent",
+  form_timeout: "agent",
+  integration_connected: "agent",
+  offer_result: "agent",
+  waiting_on_agent: "agent",
+  // "The user submitted your form … Use payload.values to continue the user's
+  // task" — a delivery mechanism, with a raw request uuid. The user submitted it;
+  // they do not need to be told they did.
+  form_result: "agent",
+  // Same shape for a tapped button: "The user tapped X on your button prompt
+  // (request `<uuid>`)". They tapped it.
+  button_click: "agent",
+  // ENG-9397: tells the agent a question was answered AFTER it stopped listening
+  // so it does not report the person as silent. The person's own answer goes
+  // back on the channel they tapped in, not here.
+  late_button_click: "agent",
+  // Broker grant resolutions. Second person to the agent, and each carries the
+  // grant uuid the tool contracts explicitly forbid showing a user ("NEVER paste
+  // the grant UUID into user-facing prose"). Two of these are in the report.
+  supabase_grant_resolved: "agent",
+  supabase_grant_denied: "agent",
+  aws_grant_resolved: "agent",
+  aws_grant_denied: "agent",
+  gcp_grant_resolved: "agent",
+  gcp_grant_denied: "agent",
+  // HITL tool-call approvals: "Do NOT call this tool again, do NOT claim the
+  // action happened, and do NOT poll".
+  integration_invoke_resolved: "agent",
+  integration_invoke_denied: "agent",
+  // Support/recruit approvals — same shape, agent resumes the provisioning.
+  recruit_resolved: "agent",
+  recruit_denied: "agent",
+  // "Your `<verb>` approval request (`<uuid>`) EXPIRED at …" — in the report,
+  // uuid and all.
+  approval_expired: "agent",
+  // A routine fired; the agent picks the work up.
+  routine_firing_result: "agent",
+  // Live-advisor wake: "Call `live_read` with escalation_id …" — a literal tool
+  // call addressed to the machine.
+  live_advisor_escalation: "agent",
+  live_advisor_session_open: "agent",
+  // The assigner reopened a card and the agent must work it again.
+  assigner_reopen: "agent",
+  // An inbound trigger event delivered onto the rail for the agent to handle.
+  // Named `trigger_event` by `triggerDeliveryPayload` — NOT `trigger_delivery`,
+  // which is what the producing module is called. Read from the builder.
+  trigger_event: "agent",
+  // Operational degradation routed into the agent's chat by the alert bridge.
+  degradation_alert: "agent",
+  // ENG-9592: probes and synthetic prompts, previously carrying NO payload at
+  // all and therefore unclassifiable. Stamped at their producers so the verdict
+  // is recorded rather than inherited from the default. `agent_probe` covers
+  // both probe kinds (liveness and the board nudge); the specific one is
+  // `payload.probe_kind`, so a new probe kind needs no entry here.
+  agent_probe: "agent",
+  agent_question_probe: "agent",
+  kanban_confirm_prompt: "agent"
+};
+var USER_FACING_KIND_SET = new Set(Object.entries(NOTICE_KIND_AUDIENCE).filter(([, audience]) => audience === "user").map(([kind]) => kind));
+var USER_FACING_NOTICE_KINDS = Object.freeze([
+  ...USER_FACING_KIND_SET
+]);
+var HIDDEN_NOTICE_KINDS = Object.freeze(Object.entries(NOTICE_KIND_AUDIENCE).filter(([, audience]) => audience === "agent").map(([kind]) => kind));
 
 // ../core/dist/direct-chat/cursor-advance.js
 var CURSOR_ADVANCE_NON_SHORTFALL_KEYS = ["advanced", "advanced_unreported", "failed"];
@@ -35259,6 +35357,12 @@ var WAITING_KIND_SET = new Set(WAITING_KINDS);
 // ../core/dist/alerts/index.js
 init_snooze();
 
+// ../core/dist/alerts/age.js
+var MINUTE_MS = 6e4;
+var HOUR_MS = 60 * MINUTE_MS;
+var DAY_MS = 24 * HOUR_MS;
+var ALERT_AGE_SEVERITY_FLOORS = [{ afterMs: 24 * HOUR_MS, floor: "critical" }];
+
 // ../core/dist/conversations/metrics.js
 var PERIOD_CONFIG = {
   "24h": { windowMs: 24 * 60 * 60 * 1e3, bucket: "hour" },
@@ -36686,6 +36790,25 @@ var FLAG_REGISTRY = [
     // deliberate, audited per-org flip (ADR-0022 §4).
     sensitive: true
   },
+  {
+    key: "email-require-approval-enforcement",
+    description: 'Enforcement gate for the `email.require_approval` guardrail (ENG-9611). That guardrail has been `default_for_new_orgs` since ~2026-05-03 and its display text promises "Require human approval before sending any email", but nothing ever read it: its only runtime path was toGuardrailForPrompt, i.e. a line in the agent CLAUDE.md. When ON for an org, a DISPATCHING email send (never a draft-create, ENG-7980) is held and routed to Human Approval regardless of recipient domain \u2014 which is what "any email" means, and is what distinguishes it from email-guard-require-approval-enabled, whose require_approval stage only intercepts a would-be DOMAIN block. Deliberately separate from the guardrail row: roughly four months of orgs already carry an inert `enforce`-level row, so reading the row alone would arm a blocking control across all of them on deploy. New orgs are armed by an org-scoped override written at org creation; existing orgs stay off until an operator flips them. Evaluated per-org. Ships dark.',
+    flagType: "boolean",
+    // Declared safe value is `false` (no hold). A flag-DB read error degrades here, so a flags
+    // outage can never silently start holding real customer email — the same fail-OPEN posture
+    // enforceEmailDomainGuard already takes, and the opposite of the enforcement resolver's
+    // fail-CLOSED, deliberately: a control that cannot verify itself must not block mail.
+    // No envVar: net-new control with no pre-flags env gate to migrate (ADR-0022).
+    defaultValue: false,
+    // Turning it on holds real customer email pending a human tap, so it is a deliberate,
+    // audited per-org flip (ADR-0022 §4).
+    sensitive: true,
+    // ENG-9629: NEW orgs are armed on. Declared here rather than hardcoded in the
+    // seeding code, so `listNewOrgFlagOverrides()` is the one answer to "which flags
+    // does a new org get". `defaultValue` stays false so the ~4 months of orgs already
+    // carrying an inert enforce-level email.require_approval row are NOT armed on deploy.
+    newOrgOverride: true
+  },
   {
     key: "email-guard-require-approval-enabled",
     description: "Platform enable-gate for the email-domain guardrail REQUIRE_APPROVAL stage (ENG-7939). When ON for an org, a scope at email_guard_stage=require_approval routes a send to a non-allowed domain into Human Approval (an Approve/Deny card) instead of a hard block: the rollout UI unlocks the option and the write routes accept require_approval. When OFF (default) the write routes reject require_approval and the UI shows it as not yet available, so no scope can select it. Structurally also depends on hitl-approval-routing being on (the approval broker fails closed to a hard block when routing is off). Evaluated per-org. Ships dark.",