@integrity-labs/agt-cli 0.28.805 → 0.28.807

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

@@ -36899,6 +36899,38 @@ var FLAG_REGISTRY = [
     // envVar — this is a net-new control with no pre-flags env gate to migrate.
     defaultValue: false
   },
+  {
+    key: "skill-dreaming-support-intake",
+    description: "Route skill dreaming's GLOBAL-scope proposals into Integrity Labs' own support-intake Linear workspace (ENG-9926). 42% of dreaming output targets a global skill no product surface can change, so those drafts can only ever become an agent-scoped fork that never reaches the thing it improves \u2014 the improvement is therefore ALSO filed as a support-intake issue, deduped per target skill with one Linear customer need per requesting org. Boolean gate; ships dark \u2014 when off nothing is filed and the fork behaviour is exactly today's.",
+    flagType: "boolean",
+    // Arming this starts exporting customer-derived text to a third-party tracker, so it
+    // takes the ADR-0022 §4 explicit-confirmation step rather than a single unguarded
+    // write — matching every comparable export gate in this file
+    // (`org-email-domain-derivation`, `kanban-push-status`,
+    // `augmented-support-auto-provision`, `email-guard-enforce-enabled`).
+    // (CodeRabbit, PR #5519: the first cut documented the risk in the comment below and
+    // then omitted the marker that acts on it.)
+    sensitive: true,
+    // THIS GATES A DATA CROSSING, NOT A COST. Read that before arming it.
+    //
+    // Everything skill dreaming does today stays inside the control plane: it reads
+    // `agent_memories` and writes a `skill_definitions` row in the same Postgres, same
+    // org, same RLS. This flag is what sends LLM-written rationale, confidence, and the
+    // verbatim NAMES of the memories that motivated a proposal OUT to Linear — and
+    // `feature-request-intake.ts` already calls Linear "the third-party tracker" where it
+    // refuses to export a requester's contact details there. Via
+    // linkFeatureRequestCustomerNeed it also sends the org's verified email domains.
+    //
+    // That is strictly more than ADR-0052 §6 gated for PostHog, and ENG-8247 is the
+    // precedent for why a credential must not BE the gate: holding a support-intake key
+    // is not the same as being cleared to send customer-derived text to a vendor's
+    // tracker. Hence a separate flag rather than leaning on isFeatureIntakeConfigured.
+    //
+    // Declared safe value is `false` (nothing filed). Fail-safe direction: a flag-DB read
+    // error must never start exporting on its own. No envVar — net-new control with no
+    // pre-flags env gate to migrate (ADR-0022).
+    defaultValue: false
+  },
   {
     key: "skill-draft-review-notify",
     description: "Pending skill-draft review nudge (ENG-6505): when a skill lands as a status=draft awaiting operator review, send a low-severity informational notification to the right reviewer(s) by scope \u2014 agent-scoped \u2192 the agent's manager (reports_to_person), falling back to team owners/admins; team-scoped \u2192 team owners/admins; org-scoped \u2192 org owners/admins \u2014 with a deep link to the Pending Skills card. Distinct from (and never doubles up on) the HIGH+ SkillSpector security alert. Covers both the agent-authored (ENG-4589) and skill-dreaming (ENG-6500) draft paths. Boolean gate; ships dark \u2014 when off no nudge is sent, so the steady state until an org is armed is silence.",
@@ -37247,6 +37279,26 @@ var FLAG_REGISTRY = [
     // env var is retired.
     envVar: "AUGMENTED_CONNECTIVITY_ESCALATION_ENABLED"
   },
+  {
+    key: "slack-manifest-remediate",
+    description: "Let the Slack manifest drift monitor PUSH, not just alert (ENG-9963). updateSlackManifest had exactly one caller \u2014 a console button \u2014 so nothing but a human click ever pushed a manifest; ENG-7762 changed the generator with no rollout mechanism and 26 agents went 53 days with no working per-agent slash commands. When on, the daily drift cron pushes the generated manifest for a drifted agent. When off it alerts exactly as before. NOTE what arming this authorises: a push REPLACES a customer-owned Slack app's entire manifest, so the cron only ever pushes drift whose diffs are purely additive (isSafelyRemediable) \u2014 an app with live-only entries a push would destroy is declined and left for a human. Boolean gate; ships dark.",
+    flagType: "boolean",
+    // Declared safe value is `false` (alert-only), matching the cron's compiled
+    // default. The fail-safe direction is the opposite of a paging gate's and
+    // matters more: a flag-DB read error must never authorise a WRITE to a
+    // customer's Slack app.
+    defaultValue: false,
+    // Operator override, same precedence and vocabulary as the connectivity
+    // escalation gate above, so an operator who knows one knows both.
+    envVar: "AUGMENTED_SLACK_MANIFEST_REMEDIATE_ENABLED",
+    // ADR-0022 §4. NOTE this is where it diverges from the connectivity gate it
+    // otherwise mirrors, and the divergence is the point: arming THAT one only
+    // causes alerts to open, while arming THIS one authorises a cron to REPLACE
+    // manifests on customer-owned Slack apps. That is precisely the class the
+    // sensitive marker exists for — a control whose relaxation should not be one
+    // unguarded write away.
+    sensitive: true
+  },
   {
     key: "integration-reauth-reminders",
     description: "Re-notify an integration that stays in needs_reauth (ENG-8370). Failure notification is at-most-once PER TRANSITION, so an integration nobody repairs is announced once and then silent forever - prod carried a row failing every 30-minute tick for ~21 days on a single day-one notification. When on, the IntegrationReauthReminder cron re-fires the existing reconnect notification on a backoff measured from failure ONSET (+1d, +3d, +7d, then weekly), skipping rows an operator has muted. When off the cron still scans and logs what it WOULD have sent, so the volume can be sized before anyone is messaged. Boolean gate; ships dark.",

package/dist/mcp/index.js

@@ -37099,7 +37099,7 @@ function renderKanbanList(items, nowMs = Date.now()) {
   return lines.join("\n");
 }
 var BLOCKED_ON_ME_SECTION_HEADING = "You are blocking these (another agent has stopped)";
-var BLOCKED_ON_ME_SECTION_NOTE = "_Another agent has PARKED its own work until you act. These are not your cards and not pullable work \u2014 you cannot move, note or complete them, and they do not count toward your in-progress load. Do the thing named, then tell the agent so it can resume; it un-parks its own card._";
+var BLOCKED_ON_ME_SECTION_NOTE = "_Another agent has PARKED its own work until you act. These are not your cards and not pullable work \u2014 you cannot move, note or complete them, and they do not count toward your in-progress load. Do the thing named, then answer with `kanban_respond` (card_id + your answer) \u2014 that delivers it ON the parked card and un-parks it. Do NOT open a second card to carry the answer._";
 var HUMAN_ASSIGNED_SECTION_HEADING = "Assigned to a person (not yours to action)";
 var HUMAN_ASSIGNED_SECTION_NOTE = "_These belong to a person, not to you. You cannot move, note or complete them \u2014 every kanban write is refused. If the work is finished (or was never really theirs), use `kanban_recall` to pull the card back onto your board, then close it as normal._";
 
@@ -37824,6 +37824,27 @@ function formatKanbanLogResult(label, data, match = {}) {
   };
 }
 
+// src/kanban-respond-outcome.ts
+function describeKanbanRespondOutcome(data) {
+  if (data.ok && data.delivered !== false) {
+    return "Answer delivered. Their card is un-parked and back on their board \u2014 they will pick it up from here, so it is off your plate.";
+  }
+  if (data.reason === "recorded_undelivered" || data.ok && data.delivered === false) {
+    return "Your answer was recorded and the card un-parked, but delivery to that agent could not be confirmed \u2014 tell them directly as well so it is not lost.";
+  }
+  const refusal = REFUSAL_MESSAGES[data.reason ?? ""];
+  if (refusal) return refusal(data);
+  return data.error ?? "Could not send your answer.";
+}
+var REFUSAL_MESSAGES = {
+  not_found: () => 'No card is parked on you with that id. Re-read kanban_list \u2014 only cards under "You are blocking these" can be answered here, and the id must be copied exactly.',
+  self_block: () => "That card is parked on YOU by you \u2014 a self-block, almost always a mistyped code_name when it was parked. Fix it on your own card rather than answering it.",
+  already_responded: () => "Someone already answered that card, so it has resumed. Nothing more to do.",
+  not_actionable: (d) => `That card is no longer parked (status: ${d.status ?? "unknown"}), so there is nothing to un-park. The agent has moved on.`,
+  recorded_not_unparked: () => "Your answer was recorded but the card could not be un-parked, so the agent is still blocked \u2014 tell them directly and check the card."
+};
+var HANDLED_REFUSAL_REASONS = Object.keys(REFUSAL_MESSAGES).sort();
+
 // src/kanban-update.ts
 function buildKanbanUpdateItem(id, fields) {
   const item = { id };
@@ -43983,6 +44004,38 @@ var FLAG_REGISTRY = [
     // envVar — this is a net-new control with no pre-flags env gate to migrate.
     defaultValue: false
   },
+  {
+    key: "skill-dreaming-support-intake",
+    description: "Route skill dreaming's GLOBAL-scope proposals into Integrity Labs' own support-intake Linear workspace (ENG-9926). 42% of dreaming output targets a global skill no product surface can change, so those drafts can only ever become an agent-scoped fork that never reaches the thing it improves \u2014 the improvement is therefore ALSO filed as a support-intake issue, deduped per target skill with one Linear customer need per requesting org. Boolean gate; ships dark \u2014 when off nothing is filed and the fork behaviour is exactly today's.",
+    flagType: "boolean",
+    // Arming this starts exporting customer-derived text to a third-party tracker, so it
+    // takes the ADR-0022 §4 explicit-confirmation step rather than a single unguarded
+    // write — matching every comparable export gate in this file
+    // (`org-email-domain-derivation`, `kanban-push-status`,
+    // `augmented-support-auto-provision`, `email-guard-enforce-enabled`).
+    // (CodeRabbit, PR #5519: the first cut documented the risk in the comment below and
+    // then omitted the marker that acts on it.)
+    sensitive: true,
+    // THIS GATES A DATA CROSSING, NOT A COST. Read that before arming it.
+    //
+    // Everything skill dreaming does today stays inside the control plane: it reads
+    // `agent_memories` and writes a `skill_definitions` row in the same Postgres, same
+    // org, same RLS. This flag is what sends LLM-written rationale, confidence, and the
+    // verbatim NAMES of the memories that motivated a proposal OUT to Linear — and
+    // `feature-request-intake.ts` already calls Linear "the third-party tracker" where it
+    // refuses to export a requester's contact details there. Via
+    // linkFeatureRequestCustomerNeed it also sends the org's verified email domains.
+    //
+    // That is strictly more than ADR-0052 §6 gated for PostHog, and ENG-8247 is the
+    // precedent for why a credential must not BE the gate: holding a support-intake key
+    // is not the same as being cleared to send customer-derived text to a vendor's
+    // tracker. Hence a separate flag rather than leaning on isFeatureIntakeConfigured.
+    //
+    // Declared safe value is `false` (nothing filed). Fail-safe direction: a flag-DB read
+    // error must never start exporting on its own. No envVar — net-new control with no
+    // pre-flags env gate to migrate (ADR-0022).
+    defaultValue: false
+  },
   {
     key: "skill-draft-review-notify",
     description: "Pending skill-draft review nudge (ENG-6505): when a skill lands as a status=draft awaiting operator review, send a low-severity informational notification to the right reviewer(s) by scope \u2014 agent-scoped \u2192 the agent's manager (reports_to_person), falling back to team owners/admins; team-scoped \u2192 team owners/admins; org-scoped \u2192 org owners/admins \u2014 with a deep link to the Pending Skills card. Distinct from (and never doubles up on) the HIGH+ SkillSpector security alert. Covers both the agent-authored (ENG-4589) and skill-dreaming (ENG-6500) draft paths. Boolean gate; ships dark \u2014 when off no nudge is sent, so the steady state until an org is armed is silence.",
@@ -44331,6 +44384,26 @@ var FLAG_REGISTRY = [
     // env var is retired.
     envVar: "AUGMENTED_CONNECTIVITY_ESCALATION_ENABLED"
   },
+  {
+    key: "slack-manifest-remediate",
+    description: "Let the Slack manifest drift monitor PUSH, not just alert (ENG-9963). updateSlackManifest had exactly one caller \u2014 a console button \u2014 so nothing but a human click ever pushed a manifest; ENG-7762 changed the generator with no rollout mechanism and 26 agents went 53 days with no working per-agent slash commands. When on, the daily drift cron pushes the generated manifest for a drifted agent. When off it alerts exactly as before. NOTE what arming this authorises: a push REPLACES a customer-owned Slack app's entire manifest, so the cron only ever pushes drift whose diffs are purely additive (isSafelyRemediable) \u2014 an app with live-only entries a push would destroy is declined and left for a human. Boolean gate; ships dark.",
+    flagType: "boolean",
+    // Declared safe value is `false` (alert-only), matching the cron's compiled
+    // default. The fail-safe direction is the opposite of a paging gate's and
+    // matters more: a flag-DB read error must never authorise a WRITE to a
+    // customer's Slack app.
+    defaultValue: false,
+    // Operator override, same precedence and vocabulary as the connectivity
+    // escalation gate above, so an operator who knows one knows both.
+    envVar: "AUGMENTED_SLACK_MANIFEST_REMEDIATE_ENABLED",
+    // ADR-0022 §4. NOTE this is where it diverges from the connectivity gate it
+    // otherwise mirrors, and the divergence is the point: arming THAT one only
+    // causes alerts to open, while arming THIS one authorises a cron to REPLACE
+    // manifests on customer-owned Slack apps. That is precisely the class the
+    // sensitive marker exists for — a control whose relaxation should not be one
+    // unguarded write away.
+    sensitive: true
+  },
   {
     key: "integration-reauth-reminders",
     description: "Re-notify an integration that stays in needs_reauth (ENG-8370). Failure notification is at-most-once PER TRANSITION, so an integration nobody repairs is announced once and then silent forever - prod carried a row failing every 30-minute tick for ~21 days on a single day-one notification. When on, the IntegrationReauthReminder cron re-fires the existing reconnect notification on a backoff measured from failure ONSET (+1d, +3d, +7d, then weekly), skipping rows an operator has muted. When off the cron still scans and logs what it WOULD have sent, so the volume can be sized before anyone is messaged. Boolean gate; ships dark.",
@@ -45936,6 +46009,37 @@ server.tool(
     }
   }
 );
+server.tool(
+  "kanban_respond",
+  'Answer a card ANOTHER agent parked on you, and un-park it so they can resume. Use this for any card in the "You are blocking these" section of kanban_list: that agent has STOPPED until you act, and this is the only way your answer reaches the card they are blocked on. Do the thing they asked, then send the answer here. Do NOT create a second card to carry it - they would end up with the parked card AND a separate one holding the thing that unblocks it, joined by nothing. You can only respond to a card that names YOU in its wait.',
+  {
+    card_id: external_exports.string().describe(
+      'The card id, exactly as kanban_list shows it under "You are blocking these".'
+    ),
+    text: external_exports.string().optional().describe(
+      "Your answer, self-contained. This is what the blocked agent resumes on, so give it the ANSWER rather than a pointer to one - it cannot see your board, your session or your files. Required unless you are picking a choice with `value`."
+    ),
+    value: external_exports.string().optional().describe("Machine value of a choice, when the card offered options. Otherwise omit."),
+    label: external_exports.string().optional().describe("Human label for that choice, when it differs from the value.")
+  },
+  async (params) => {
+    let data;
+    try {
+      data = await apiPost("/host/kanban/respond", {
+        agent_id: AGT_AGENT_ID,
+        card_id: params.card_id,
+        ...params.text ? { text: params.text } : {},
+        ...params.value ? { value: params.value } : {},
+        ...params.label ? { label: params.label } : {}
+      });
+    } catch (err) {
+      return {
+        content: [{ type: "text", text: `Could not send your answer: ${err.message}` }]
+      };
+    }
+    return { content: [{ type: "text", text: describeKanbanRespondOutcome(data) }] };
+  }
+);
 server.tool(
   "kanban_recall",
   'Pull a card you assigned to a HUMAN teammate back onto your own board. Use this when a card shows under "Assigned to a person" in kanban_list and you need to act on it - typically because the person finished the work (or it is no longer needed) and the card has to be closed. While a card is assigned to a person, every kanban write to it is refused; recall makes it yours again so kanban_move / kanban_done / kanban_log work. Recall does NOT complete the card - after recalling, close it yourself with kanban_done and a result. You can only recall a card you assigned.',
@@ -47816,6 +47920,11 @@ var LOCAL_TOOL_NAMES = /* @__PURE__ */ new Set([
   // ENG-8281: the inverse of assign_kanban_to_human — take a human-assigned
   // card back so the agent can finally close it.
   "kanban_recall",
+  // ENG-9838: the UNBLOCKING direction of waiting_on_agent. Parking already
+  // notified the target; the answer had no route back, so every agent-to-agent
+  // park needed a second, unlinked card carrying the answer beside the card it
+  // was meant to unblock.
+  "kanban_respond",
   // ENG-9050: the return path for delegated work.
   "kanban_reopen",
   // ENG-9375: the READ path over a teammate's board (counts only).

package/dist/mcp/origami.js

@@ -42623,6 +42623,38 @@ var FLAG_REGISTRY = [
     // envVar — this is a net-new control with no pre-flags env gate to migrate.
     defaultValue: false
   },
+  {
+    key: "skill-dreaming-support-intake",
+    description: "Route skill dreaming's GLOBAL-scope proposals into Integrity Labs' own support-intake Linear workspace (ENG-9926). 42% of dreaming output targets a global skill no product surface can change, so those drafts can only ever become an agent-scoped fork that never reaches the thing it improves \u2014 the improvement is therefore ALSO filed as a support-intake issue, deduped per target skill with one Linear customer need per requesting org. Boolean gate; ships dark \u2014 when off nothing is filed and the fork behaviour is exactly today's.",
+    flagType: "boolean",
+    // Arming this starts exporting customer-derived text to a third-party tracker, so it
+    // takes the ADR-0022 §4 explicit-confirmation step rather than a single unguarded
+    // write — matching every comparable export gate in this file
+    // (`org-email-domain-derivation`, `kanban-push-status`,
+    // `augmented-support-auto-provision`, `email-guard-enforce-enabled`).
+    // (CodeRabbit, PR #5519: the first cut documented the risk in the comment below and
+    // then omitted the marker that acts on it.)
+    sensitive: true,
+    // THIS GATES A DATA CROSSING, NOT A COST. Read that before arming it.
+    //
+    // Everything skill dreaming does today stays inside the control plane: it reads
+    // `agent_memories` and writes a `skill_definitions` row in the same Postgres, same
+    // org, same RLS. This flag is what sends LLM-written rationale, confidence, and the
+    // verbatim NAMES of the memories that motivated a proposal OUT to Linear — and
+    // `feature-request-intake.ts` already calls Linear "the third-party tracker" where it
+    // refuses to export a requester's contact details there. Via
+    // linkFeatureRequestCustomerNeed it also sends the org's verified email domains.
+    //
+    // That is strictly more than ADR-0052 §6 gated for PostHog, and ENG-8247 is the
+    // precedent for why a credential must not BE the gate: holding a support-intake key
+    // is not the same as being cleared to send customer-derived text to a vendor's
+    // tracker. Hence a separate flag rather than leaning on isFeatureIntakeConfigured.
+    //
+    // Declared safe value is `false` (nothing filed). Fail-safe direction: a flag-DB read
+    // error must never start exporting on its own. No envVar — net-new control with no
+    // pre-flags env gate to migrate (ADR-0022).
+    defaultValue: false
+  },
   {
     key: "skill-draft-review-notify",
     description: "Pending skill-draft review nudge (ENG-6505): when a skill lands as a status=draft awaiting operator review, send a low-severity informational notification to the right reviewer(s) by scope \u2014 agent-scoped \u2192 the agent's manager (reports_to_person), falling back to team owners/admins; team-scoped \u2192 team owners/admins; org-scoped \u2192 org owners/admins \u2014 with a deep link to the Pending Skills card. Distinct from (and never doubles up on) the HIGH+ SkillSpector security alert. Covers both the agent-authored (ENG-4589) and skill-dreaming (ENG-6500) draft paths. Boolean gate; ships dark \u2014 when off no nudge is sent, so the steady state until an org is armed is silence.",
@@ -42971,6 +43003,26 @@ var FLAG_REGISTRY = [
     // env var is retired.
     envVar: "AUGMENTED_CONNECTIVITY_ESCALATION_ENABLED"
   },
+  {
+    key: "slack-manifest-remediate",
+    description: "Let the Slack manifest drift monitor PUSH, not just alert (ENG-9963). updateSlackManifest had exactly one caller \u2014 a console button \u2014 so nothing but a human click ever pushed a manifest; ENG-7762 changed the generator with no rollout mechanism and 26 agents went 53 days with no working per-agent slash commands. When on, the daily drift cron pushes the generated manifest for a drifted agent. When off it alerts exactly as before. NOTE what arming this authorises: a push REPLACES a customer-owned Slack app's entire manifest, so the cron only ever pushes drift whose diffs are purely additive (isSafelyRemediable) \u2014 an app with live-only entries a push would destroy is declined and left for a human. Boolean gate; ships dark.",
+    flagType: "boolean",
+    // Declared safe value is `false` (alert-only), matching the cron's compiled
+    // default. The fail-safe direction is the opposite of a paging gate's and
+    // matters more: a flag-DB read error must never authorise a WRITE to a
+    // customer's Slack app.
+    defaultValue: false,
+    // Operator override, same precedence and vocabulary as the connectivity
+    // escalation gate above, so an operator who knows one knows both.
+    envVar: "AUGMENTED_SLACK_MANIFEST_REMEDIATE_ENABLED",
+    // ADR-0022 §4. NOTE this is where it diverges from the connectivity gate it
+    // otherwise mirrors, and the divergence is the point: arming THAT one only
+    // causes alerts to open, while arming THIS one authorises a cron to REPLACE
+    // manifests on customer-owned Slack apps. That is precisely the class the
+    // sensitive marker exists for — a control whose relaxation should not be one
+    // unguarded write away.
+    sensitive: true
+  },
   {
     key: "integration-reauth-reminders",
     description: "Re-notify an integration that stays in needs_reauth (ENG-8370). Failure notification is at-most-once PER TRANSITION, so an integration nobody repairs is announced once and then silent forever - prod carried a row failing every 30-minute tick for ~21 days on a single day-one notification. When on, the IntegrationReauthReminder cron re-fires the existing reconnect notification on a backoff measured from failure ONSET (+1d, +3d, +7d, then weekly), skipping rows an operator has muted. When off the cron still scans and logs what it WOULD have sent, so the volume can be sized before anyone is messaged. Boolean gate; ships dark.",

package/dist/mcp/slack-channel.js

@@ -37146,6 +37146,38 @@ var FLAG_REGISTRY = [
     // envVar — this is a net-new control with no pre-flags env gate to migrate.
     defaultValue: false
   },
+  {
+    key: "skill-dreaming-support-intake",
+    description: "Route skill dreaming's GLOBAL-scope proposals into Integrity Labs' own support-intake Linear workspace (ENG-9926). 42% of dreaming output targets a global skill no product surface can change, so those drafts can only ever become an agent-scoped fork that never reaches the thing it improves \u2014 the improvement is therefore ALSO filed as a support-intake issue, deduped per target skill with one Linear customer need per requesting org. Boolean gate; ships dark \u2014 when off nothing is filed and the fork behaviour is exactly today's.",
+    flagType: "boolean",
+    // Arming this starts exporting customer-derived text to a third-party tracker, so it
+    // takes the ADR-0022 §4 explicit-confirmation step rather than a single unguarded
+    // write — matching every comparable export gate in this file
+    // (`org-email-domain-derivation`, `kanban-push-status`,
+    // `augmented-support-auto-provision`, `email-guard-enforce-enabled`).
+    // (CodeRabbit, PR #5519: the first cut documented the risk in the comment below and
+    // then omitted the marker that acts on it.)
+    sensitive: true,
+    // THIS GATES A DATA CROSSING, NOT A COST. Read that before arming it.
+    //
+    // Everything skill dreaming does today stays inside the control plane: it reads
+    // `agent_memories` and writes a `skill_definitions` row in the same Postgres, same
+    // org, same RLS. This flag is what sends LLM-written rationale, confidence, and the
+    // verbatim NAMES of the memories that motivated a proposal OUT to Linear — and
+    // `feature-request-intake.ts` already calls Linear "the third-party tracker" where it
+    // refuses to export a requester's contact details there. Via
+    // linkFeatureRequestCustomerNeed it also sends the org's verified email domains.
+    //
+    // That is strictly more than ADR-0052 §6 gated for PostHog, and ENG-8247 is the
+    // precedent for why a credential must not BE the gate: holding a support-intake key
+    // is not the same as being cleared to send customer-derived text to a vendor's
+    // tracker. Hence a separate flag rather than leaning on isFeatureIntakeConfigured.
+    //
+    // Declared safe value is `false` (nothing filed). Fail-safe direction: a flag-DB read
+    // error must never start exporting on its own. No envVar — net-new control with no
+    // pre-flags env gate to migrate (ADR-0022).
+    defaultValue: false
+  },
   {
     key: "skill-draft-review-notify",
     description: "Pending skill-draft review nudge (ENG-6505): when a skill lands as a status=draft awaiting operator review, send a low-severity informational notification to the right reviewer(s) by scope \u2014 agent-scoped \u2192 the agent's manager (reports_to_person), falling back to team owners/admins; team-scoped \u2192 team owners/admins; org-scoped \u2192 org owners/admins \u2014 with a deep link to the Pending Skills card. Distinct from (and never doubles up on) the HIGH+ SkillSpector security alert. Covers both the agent-authored (ENG-4589) and skill-dreaming (ENG-6500) draft paths. Boolean gate; ships dark \u2014 when off no nudge is sent, so the steady state until an org is armed is silence.",
@@ -37494,6 +37526,26 @@ var FLAG_REGISTRY = [
     // env var is retired.
     envVar: "AUGMENTED_CONNECTIVITY_ESCALATION_ENABLED"
   },
+  {
+    key: "slack-manifest-remediate",
+    description: "Let the Slack manifest drift monitor PUSH, not just alert (ENG-9963). updateSlackManifest had exactly one caller \u2014 a console button \u2014 so nothing but a human click ever pushed a manifest; ENG-7762 changed the generator with no rollout mechanism and 26 agents went 53 days with no working per-agent slash commands. When on, the daily drift cron pushes the generated manifest for a drifted agent. When off it alerts exactly as before. NOTE what arming this authorises: a push REPLACES a customer-owned Slack app's entire manifest, so the cron only ever pushes drift whose diffs are purely additive (isSafelyRemediable) \u2014 an app with live-only entries a push would destroy is declined and left for a human. Boolean gate; ships dark.",
+    flagType: "boolean",
+    // Declared safe value is `false` (alert-only), matching the cron's compiled
+    // default. The fail-safe direction is the opposite of a paging gate's and
+    // matters more: a flag-DB read error must never authorise a WRITE to a
+    // customer's Slack app.
+    defaultValue: false,
+    // Operator override, same precedence and vocabulary as the connectivity
+    // escalation gate above, so an operator who knows one knows both.
+    envVar: "AUGMENTED_SLACK_MANIFEST_REMEDIATE_ENABLED",
+    // ADR-0022 §4. NOTE this is where it diverges from the connectivity gate it
+    // otherwise mirrors, and the divergence is the point: arming THAT one only
+    // causes alerts to open, while arming THIS one authorises a cron to REPLACE
+    // manifests on customer-owned Slack apps. That is precisely the class the
+    // sensitive marker exists for — a control whose relaxation should not be one
+    // unguarded write away.
+    sensitive: true
+  },
   {
     key: "integration-reauth-reminders",
     description: "Re-notify an integration that stays in needs_reauth (ENG-8370). Failure notification is at-most-once PER TRANSITION, so an integration nobody repairs is announced once and then silent forever - prod carried a row failing every 30-minute tick for ~21 days on a single day-one notification. When on, the IntegrationReauthReminder cron re-fires the existing reconnect notification on a backoff measured from failure ONSET (+1d, +3d, +7d, then weekly), skipping rows an operator has muted. When off the cron still scans and logs what it WOULD have sent, so the volume can be sized before anyone is messaged. Boolean gate; ships dark.",

package/dist/mcp/telegram-channel.js

@@ -37304,6 +37304,38 @@ var FLAG_REGISTRY = [
     // envVar — this is a net-new control with no pre-flags env gate to migrate.
     defaultValue: false
   },
+  {
+    key: "skill-dreaming-support-intake",
+    description: "Route skill dreaming's GLOBAL-scope proposals into Integrity Labs' own support-intake Linear workspace (ENG-9926). 42% of dreaming output targets a global skill no product surface can change, so those drafts can only ever become an agent-scoped fork that never reaches the thing it improves \u2014 the improvement is therefore ALSO filed as a support-intake issue, deduped per target skill with one Linear customer need per requesting org. Boolean gate; ships dark \u2014 when off nothing is filed and the fork behaviour is exactly today's.",
+    flagType: "boolean",
+    // Arming this starts exporting customer-derived text to a third-party tracker, so it
+    // takes the ADR-0022 §4 explicit-confirmation step rather than a single unguarded
+    // write — matching every comparable export gate in this file
+    // (`org-email-domain-derivation`, `kanban-push-status`,
+    // `augmented-support-auto-provision`, `email-guard-enforce-enabled`).
+    // (CodeRabbit, PR #5519: the first cut documented the risk in the comment below and
+    // then omitted the marker that acts on it.)
+    sensitive: true,
+    // THIS GATES A DATA CROSSING, NOT A COST. Read that before arming it.
+    //
+    // Everything skill dreaming does today stays inside the control plane: it reads
+    // `agent_memories` and writes a `skill_definitions` row in the same Postgres, same
+    // org, same RLS. This flag is what sends LLM-written rationale, confidence, and the
+    // verbatim NAMES of the memories that motivated a proposal OUT to Linear — and
+    // `feature-request-intake.ts` already calls Linear "the third-party tracker" where it
+    // refuses to export a requester's contact details there. Via
+    // linkFeatureRequestCustomerNeed it also sends the org's verified email domains.
+    //
+    // That is strictly more than ADR-0052 §6 gated for PostHog, and ENG-8247 is the
+    // precedent for why a credential must not BE the gate: holding a support-intake key
+    // is not the same as being cleared to send customer-derived text to a vendor's
+    // tracker. Hence a separate flag rather than leaning on isFeatureIntakeConfigured.
+    //
+    // Declared safe value is `false` (nothing filed). Fail-safe direction: a flag-DB read
+    // error must never start exporting on its own. No envVar — net-new control with no
+    // pre-flags env gate to migrate (ADR-0022).
+    defaultValue: false
+  },
   {
     key: "skill-draft-review-notify",
     description: "Pending skill-draft review nudge (ENG-6505): when a skill lands as a status=draft awaiting operator review, send a low-severity informational notification to the right reviewer(s) by scope \u2014 agent-scoped \u2192 the agent's manager (reports_to_person), falling back to team owners/admins; team-scoped \u2192 team owners/admins; org-scoped \u2192 org owners/admins \u2014 with a deep link to the Pending Skills card. Distinct from (and never doubles up on) the HIGH+ SkillSpector security alert. Covers both the agent-authored (ENG-4589) and skill-dreaming (ENG-6500) draft paths. Boolean gate; ships dark \u2014 when off no nudge is sent, so the steady state until an org is armed is silence.",
@@ -37652,6 +37684,26 @@ var FLAG_REGISTRY = [
     // env var is retired.
     envVar: "AUGMENTED_CONNECTIVITY_ESCALATION_ENABLED"
   },
+  {
+    key: "slack-manifest-remediate",
+    description: "Let the Slack manifest drift monitor PUSH, not just alert (ENG-9963). updateSlackManifest had exactly one caller \u2014 a console button \u2014 so nothing but a human click ever pushed a manifest; ENG-7762 changed the generator with no rollout mechanism and 26 agents went 53 days with no working per-agent slash commands. When on, the daily drift cron pushes the generated manifest for a drifted agent. When off it alerts exactly as before. NOTE what arming this authorises: a push REPLACES a customer-owned Slack app's entire manifest, so the cron only ever pushes drift whose diffs are purely additive (isSafelyRemediable) \u2014 an app with live-only entries a push would destroy is declined and left for a human. Boolean gate; ships dark.",
+    flagType: "boolean",
+    // Declared safe value is `false` (alert-only), matching the cron's compiled
+    // default. The fail-safe direction is the opposite of a paging gate's and
+    // matters more: a flag-DB read error must never authorise a WRITE to a
+    // customer's Slack app.
+    defaultValue: false,
+    // Operator override, same precedence and vocabulary as the connectivity
+    // escalation gate above, so an operator who knows one knows both.
+    envVar: "AUGMENTED_SLACK_MANIFEST_REMEDIATE_ENABLED",
+    // ADR-0022 §4. NOTE this is where it diverges from the connectivity gate it
+    // otherwise mirrors, and the divergence is the point: arming THAT one only
+    // causes alerts to open, while arming THIS one authorises a cron to REPLACE
+    // manifests on customer-owned Slack apps. That is precisely the class the
+    // sensitive marker exists for — a control whose relaxation should not be one
+    // unguarded write away.
+    sensitive: true
+  },
   {
     key: "integration-reauth-reminders",
     description: "Re-notify an integration that stays in needs_reauth (ENG-8370). Failure notification is at-most-once PER TRANSITION, so an integration nobody repairs is announced once and then silent forever - prod carried a row failing every 30-minute tick for ~21 days on a single day-one notification. When on, the IntegrationReauthReminder cron re-fires the existing reconnect notification on a backoff measured from failure ONSET (+1d, +3d, +7d, then weekly), skipping rows an operator has muted. When off the cron still scans and logs what it WOULD have sent, so the volume can be sized before anyone is messaged. Boolean gate; ships dark.",

package/dist/{persistent-session-PV4GPHG3.js → persistent-session-LEICQMWY.js}

@@ -49,8 +49,8 @@ import {
   writeDirectChatSessionState,
   writeEgressAllowlist,
   writePersistentClaudeWrapper
-} from "./chunk-DHOVIXR5.js";
-import "./chunk-2FL6V4E5.js";
+} from "./chunk-GIV6ORI3.js";
+import "./chunk-VK35F6O7.js";
 import "./chunk-XWVM4KPK.js";
 export {
   EGRESS_BASELINE_DOMAINS,
@@ -104,4 +104,4 @@ export {
   writeEgressAllowlist,
   writePersistentClaudeWrapper
 };
-//# sourceMappingURL=persistent-session-PV4GPHG3.js.map
+//# sourceMappingURL=persistent-session-LEICQMWY.js.map

package/dist/{responsiveness-probe-X3AW5TGA.js → responsiveness-probe-WEXP254C.js}

@@ -1,7 +1,7 @@
 import {
   paneLogPath
-} from "./chunk-DHOVIXR5.js";
-import "./chunk-2FL6V4E5.js";
+} from "./chunk-GIV6ORI3.js";
+import "./chunk-VK35F6O7.js";
 import "./chunk-XWVM4KPK.js";
 
 // src/lib/responsiveness-probe.ts
@@ -745,4 +745,4 @@ export {
   readAndResetSlackReplyBindingClassifications,
   readAndResetSlackReplyTargetClassifications
 };
-//# sourceMappingURL=responsiveness-probe-X3AW5TGA.js.map
+//# sourceMappingURL=responsiveness-probe-WEXP254C.js.map

package/dist/{session-auth-dead-W6K5VEU7.js → session-auth-dead-AROKHZET.js}

@@ -1,6 +1,6 @@
 import {
   sessionTranscriptDir
-} from "./chunk-2FL6V4E5.js";
+} from "./chunk-VK35F6O7.js";
 
 // src/lib/session-auth-dead.ts
 import { closeSync, openSync, readSync, readdirSync, statSync } from "fs";
@@ -203,4 +203,4 @@ export {
   decideSessionAuthState,
   probeSessionAuth
 };
-//# sourceMappingURL=session-auth-dead-W6K5VEU7.js.map
+//# sourceMappingURL=session-auth-dead-AROKHZET.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@integrity-labs/agt-cli",
-  "version": "0.28.805",
+  "version": "0.28.807",
   "description": "Augmented Team CLI — agent provisioning and management",
   "type": "module",
   "engines": {