@integrity-labs/agt-cli 0.28.670 → 0.28.672

package/dist/{chunk-HGVJVYKW.js → chunk-YOID6KOQ.js}

@@ -5526,6 +5526,27 @@ var FLAG_REGISTRY = [
     // consumed by the manager's own logic, not an in-container MCP, so no env materialization.
     defaultValue: false
   },
+  {
+    key: "spawn-inject-channel-secrets",
+    description: "ENG-9350 (host key-management hardening, epic ENG-9347): deliver a managed agent's channel bot tokens (SLACK_BOT_TOKEN, SLACK_APP_TOKEN, TELEGRAM_BOT_TOKEN, MSTEAMS_CLIENT_SECRET) into the Claude Code spawn env via `tmux new-session -e KEY=VALUE` (the same posture as ANTHROPIC_API_KEY / AGT_API_KEY) instead of writing them as plaintext to the on-disk `.env.integrations` file. ON = the manager injects the four channel secrets at spawn and evicts them from `.env.integrations`; the `.mcp.json` `${VAR}` templates are unchanged and now resolve from the spawn env, so the value never touches persistent EBS (and, under Docker isolation, is name-only forwarded into the container the same way AGT_API_KEY is). OFF (default) = today's behaviour, byte-for-byte: the tokens are written to `.env.integrations` (0600) and the wrapper sources them. Resolved host-side by the manager via hostFlagStore().getBooleanForAgent \u2014 the manager owns the spawn path, so no in-container MCP reads this; it materializes the VALUES, not the flag. A channel- token rotation already forces a session respawn (ENG-6062), so the injected value is bound at the same moment the file value used to be \u2014 the two paths are behaviourally equivalent, this one just keeps the plaintext off disk. Ships dark; flip per-agent/ host to soak before fleet convergence, flip OFF to fall back to the file path instantly without a code rollback. Integration credentials + the OAuth remote-MCP live-read proxy deliberately stay on the file (later slices / a permanent bounded carve-out, ADR-0062 Part 5).",
+    flagType: "boolean",
+    // Declared safe value is `false`: the current on-disk `.env.integrations` delivery,
+    // byte-for-byte. `false` is also the fail-safe direction — a flag-store read error must
+    // never silently move a fleet onto the spawn-env path (a bug there = a channel with no
+    // token = a silently dead channel). Net-new gate consumed by the manager's own spawn
+    // logic, not an in-container MCP, so registry-only with NO envVar materialization
+    // (mirrors scheduled-task-nudge-durable). Turning it ON removes plaintext at rest.
+    defaultValue: false,
+    // ENG-7997 flip-reach estimate: `since` is the first agt-cli build whose
+    // dist carries this host-side reader. That build is the one THIS PR's merge
+    // auto-publishes — unknown until then, and every already-published version
+    // (0.28.x) demonstrably lacks the reader (CodeRabbit npm-pack check). An
+    // UNREACHABLE placeholder is the fail-safe: the reach estimate counts zero
+    // hosts as honoring the flip (rather than over-claiming that 0.28.x hosts do,
+    // while they still write tokens to disk). MUST be updated to the actual
+    // published version once the release lands (tracked on ENG-9350).
+    since: "99.0.0"
+  },
   {
     key: "scheduled-task-confirmation-card",
     description: `Post the \u{1F44D}/\u{1F44E} "Task complete?" kanban confirmation card for completed scheduled_task runs (ENG-4576 / ENG-6048). OFF (default) kills these cards fleet-wide: ENG-8072 found they mis-thread onto the run's captured slack_delivery, which in the persistent-session model is frequently a conversational reply rather than the task's own output - so a routine cron's confirmation card lands in an unrelated human thread (e.g. a half-hourly reconciliation card posted into a "you're back online" DM), and a clean cron emits a human \u{1F44D}/\u{1F44E} prompt on every tick regardless. The card was net-negative, so it is disabled by default. Turn it ON per org to restore scheduled-task ratings for a customer who wants them (e.g. a daily digest delivered to a channel). Evaluated per-org in the API (POST /host/runs/finish + the manager rating-prompt route) via getEvaluatedFlags(); the decision is passed into postScheduledTaskKanbanConfirmation. API-only gate - no host env materialization. Ships dark (cards off).`,
@@ -5669,6 +5690,27 @@ var FLAG_REGISTRY = [
     // never auto-attach an integration nobody asked for, and both ENG-8332
     // prerequisites above are still open.
     defaultValue: false
+  },
+  {
+    key: "host-right-sizing",
+    description: 'ADR-0072. Gates the HostRightSizer cron, which evaluates every managed EC2 host against 7 days of memory and CPU and (at enforce) resizes it one rung inside the host\'s own maintenance window. off = the cron returns immediately: nothing is read, nothing is written. shadow = evaluate, persist a verdict row per host, and post the weekly summary \u2014 NO resize, and no actor code runs. enforce = as shadow, plus enqueue resizes. AS OF PHASE 1 (ENG-9324) THERE IS NO ACTOR, SO `enforce` BEHAVES EXACTLY LIKE `shadow`: selecting it records the mode on each verdict row and changes nothing else, and no host is resized. This note comes out when the Phase 3 actor lands; until then treat enforce as shadow-with-a-label, not as an armed fleet. Ships dark: this mechanism ends in a stop/start of a customer production host, so an unreachable flag store must resolve to NOT acting. TWO BOUNDS WORTH KNOWING BEFORE FLIPPING. (1) off is not a stop button for in-flight work \u2014 HostResizeDispatcher reads only ec2_pending_instance_type and knows nothing about this flag, so flipping to off stops new enqueues and lets every already-enqueued host complete its stop/modify/start; combined with the ~5-minute eval cache the true blast unit is one tick of open windows. A real kill switch has to live inside the dispatcher. (2) BYO hosts (ADR-0028) are EXCLUDED in Phase 1, not merely clamped to shadow: their instances live in the customer AWS account while the cron authenticates only with the platform provisioner role, so their metrics read as empty and every evaluation would land as unknown. ADR-0072 \xA79 intends them to be shadow-only ("we recommend; they resize") and making that real needs the per-host cross_account_role_arn resolved - its own slice. Pool hosts (ADR-0042) are excluded too, while host_kind is unset in prod. Both are eligibility predicates applied by the cron, documented here so the admin page showing enforce for such an org is not read as behaviour.',
+    flagType: "enum",
+    allowedValues: ["off", "shadow", "enforce"],
+    // Ships dark at `off`, NOT `shadow`. Diverging deliberately from
+    // slack-scheduled-channel-guard, whose shadow is a free local log line:
+    // THIS shadow spends a fleet-wide CloudWatch GetMetricData sweep per tick
+    // and writes a row per host, so defaulting to shadow would newly bill and
+    // newly write for every org that never opted in. shadow is the per-canary
+    // opt-in; enforce is the audited flip after the Phase 2 review.
+    defaultValue: "off",
+    // Evaluated centrally, in the API cron — there is no host-side reader, so
+    // no `since` and no dependence on fleet agt-cli convergence.
+    // NOTE: deliberately NO envVar. ADR-0072 §9 wants this gate scoped per
+    // org/host, and an envVar would be highest-precedence (ADR-0022) — a
+    // literal in sst.config.ts would pin every stage and make the admin page a
+    // control that does nothing, which is the ENG-8303 class exactly.
+    // enforce arms automated downtime on a customer's production host.
+    sensitive: true
   }
 ];
 var REGISTRY_BY_KEY = new Map(FLAG_REGISTRY.map((definition) => [definition.key, definition]));
@@ -12432,4 +12474,4 @@ export {
   minutesSinceLocalMidnight,
   peekCurrentSession
 };
-//# sourceMappingURL=chunk-HGVJVYKW.js.map
+//# sourceMappingURL=chunk-YOID6KOQ.js.map