@autohq/cli 0.1.378 → 0.1.380

package/dist/agent-bridge.js

@@ -23492,7 +23492,7 @@ Object.assign(lookup, {
 // package.json
 var package_default = {
   name: "@autohq/cli",
-  version: "0.1.378",
+  version: "0.1.380",
   license: "SEE LICENSE IN README.md",
   publishConfig: {
     access: "public"
@@ -28123,6 +28123,10 @@ var CreditEventTypeSchema = external_exports.enum(CREDIT_EVENT_TYPES);
 var UsdAmountSchema = external_exports.number().finite();
 var NonNegativeUsdSchema = external_exports.number().finite().nonnegative();
 var PositiveUsdSchema = external_exports.number().finite().positive();
+var MIN_CREDIT_PURCHASE_USD = 5;
+var MAX_CREDIT_PURCHASE_USD = 1e4;
+var wholeCents = (value2) => Math.abs(value2 * 100 - Math.round(value2 * 100)) < 1e-6;
+var ChargeableUsdSchema = PositiveUsdSchema.min(MIN_CREDIT_PURCHASE_USD).max(MAX_CREDIT_PURCHASE_USD).refine(wholeCents, "amount must be a whole number of cents");
 var CreditEventSchema = external_exports.object({
   organizationId: OrganizationIdSchema,
   type: CreditEventTypeSchema,
@@ -28130,7 +28134,11 @@ var CreditEventSchema = external_exports.object({
   description: external_exports.string().trim().min(1).nullable().default(null),
   // The acting user for manual purchases/adjustments; null for system-issued
   // rows (signup grants, auto-top-ups).
-  createdByUserId: external_exports.string().trim().min(1).nullable().default(null)
+  createdByUserId: external_exports.string().trim().min(1).nullable().default(null),
+  // External payment reference (e.g. a Stripe payment intent id). Unique in
+  // the ledger, so payment-driven mints are idempotent: a webhook retry or a
+  // sync-plus-webhook race inserts once and no-ops after.
+  externalRef: external_exports.string().trim().min(1).nullable().default(null)
 }).refine(
   (event) => event.type === "adjustment" || event.amountUsd > 0,
   "Only adjustment credit events may carry a non-positive amount"
@@ -28142,6 +28150,7 @@ var CreditEventRecordSchema = external_exports.object({
   amountUsd: UsdAmountSchema,
   description: external_exports.string().trim().min(1).nullable(),
   createdByUserId: external_exports.string().trim().min(1).nullable(),
+  externalRef: external_exports.string().trim().min(1).nullable(),
   createdAt: external_exports.string().datetime()
 });
 var SPENDING_LIMIT_WINDOWS = ["day", "month"];
@@ -28159,14 +28168,24 @@ var OrganizationBillingSettingsSchema = external_exports.object({
   // Balance at or below the threshold triggers a top-up of the configured
   // amount. Both must be set for auto-top-up to arm.
   autoTopUpThresholdUsd: NonNegativeUsdSchema.nullable(),
-  autoTopUpAmountUsd: PositiveUsdSchema.nullable()
+  autoTopUpAmountUsd: PositiveUsdSchema.nullable(),
+  // Stripe linkage, set by the payment flow (never by the settings PATCH):
+  // the org's Stripe customer, and the saved card auto-top-up charges
+  // off-session. A non-null payment method is what "card on file" means.
+  stripeCustomerId: external_exports.string().trim().min(1).nullable(),
+  stripeDefaultPaymentMethodId: external_exports.string().trim().min(1).nullable()
 });
 var UpdateOrganizationBillingSettingsRequestSchema = external_exports.object({
   spendLimitDayUsd: PositiveUsdSchema.nullable().optional(),
   spendLimitMonthUsd: PositiveUsdSchema.nullable().optional(),
   autoTopUpEnabled: external_exports.boolean().optional(),
   autoTopUpThresholdUsd: NonNegativeUsdSchema.nullable().optional(),
-  autoTopUpAmountUsd: PositiveUsdSchema.nullable().optional()
+  // The top-up amount is charged to a real card, so it carries the same
+  // bounds as a purchase: whole cents (Stripe charges integer cents; a
+  // fractional-cent amount would make the charge and the mint disagree
+  // forever) and the purchase floor/cap (Stripe rejects sub-$0.50 charges,
+  // which would otherwise disarm auto-top-up on first trigger).
+  autoTopUpAmountUsd: ChargeableUsdSchema.nullable().optional()
 }).strict();
 var OrganizationCreditsResponseSchema = external_exports.object({
   organizationId: OrganizationIdSchema,
@@ -28179,6 +28198,14 @@ var AddOrganizationCreditsRequestSchema = external_exports.object({
   amountUsd: PositiveUsdSchema.max(1e4),
   description: external_exports.string().trim().min(1).max(500).optional()
 }).strict();
+var ReturnPathSchema = external_exports.string().trim().min(1).max(2e3).regex(/^\/(?!\/)/, "returnPath must be an absolute in-app path");
+var CreateCreditPurchaseRequestSchema = external_exports.object({
+  amountUsd: ChargeableUsdSchema,
+  returnPath: ReturnPathSchema
+}).strict();
+var CreateBillingPortalSessionRequestSchema = external_exports.object({
+  returnPath: ReturnPathSchema
+}).strict();
 
 // ../../packages/schemas/src/pricing.ts
 var RATE_CARD_2026_06_23 = {
@@ -31868,6 +31895,268 @@ triggers:
           content: "harness: claude-code\nenvironment:\n  name: agent-runtime\n  image:\n    kind: preset\n    name: node24\n  resources:\n    memoryMB: 8192\n"
         }
       ]
+    },
+    {
+      version: "1.3.0",
+      files: [
+        {
+          path: "agents/incident-response-slack.yaml",
+          content: `imports:
+  - ./incident-response.yaml
+systemPrompt: |
+  You are the incident response agent for {{ $repoFullName }}. When an alert
+  arrives, your job is fast, evidence-based triage \u2014 not heroics.
+
+  Investigation protocol:
+  - Read the alert payload carefully; identify the affected service and
+    the symptom.
+  - Correlate with recent change: inspect the last day of commits on main
+    in the mounted checkout (git log) and look for changes touching the
+    affected area.
+  - When an observability tool is available, pull the relevant logs,
+    monitors, or metrics for the alert window before speculating.
+  - Form a hypothesis with explicit confidence: likely cause, supporting
+    evidence, and what would confirm or refute it.
+
+  Reporting protocol (Slack {{ $slackChannel }}):
+  - Slack renders mrkdwn links: <https://url|text>.
+  - Post one top-level message: severity, service, one-line symptom, and
+    the alert link.
+  - Thread the full triage under it: timeline, suspected cause with
+    evidence, suggested next steps, and what you ruled out.
+  - After your first reply, call auto.chat.subscribe for the thread so
+    responder questions route back to you. Answer follow-ups in the same
+    thread with the same evidence discipline.
+
+  Fix protocol (serve the fix on a platter):
+  - When the evidence points at a specific code change with a clear,
+    contained fix \u2014 a bad commit to revert, a config value to correct, a
+    small patch \u2014 prepare it: create a focused branch from main in the
+    mounted checkout, implement the minimal fix, push the branch, and open
+    a draft pull request with create_pull_request.
+  - The PR body states the hypothesis the fix encodes with its evidence
+    and says how to verify it. Post the PR link in the incident thread.
+  - Keep the fix minimal and reversible; run the repo's relevant checks
+    when the environment allows and report what you ran. Never force a fix:
+    when the cause is uncertain or the change would sprawl, the triage with
+    suggested next steps is a complete deliverable on its own.
+
+  Hard limits: your only writes are the incident thread and the draft fix
+  PR. Do not merge the PR, push to main, restart services, mutate
+  infrastructure, or declare an incident resolved \u2014 humans review the fix
+  and decide that. If the evidence is thin, say so plainly rather than
+  manufacturing a conclusion.
+initialPrompt: |
+  A production alert arrived.
+
+  Alert:
+  - Title: {{title}}
+  - Severity: {{severity}}
+  - Service: {{service}}
+  - Description: {{description}}
+  - Link: {{link}}
+
+  Investigate following your responder instructions, then post the triage
+  to Slack {{ $slackChannel }} and subscribe to the thread for follow-ups.
+  If the evidence points at a clear, contained code fix, also open a draft
+  fix PR and post the link in the thread.
+# The Slack variant triages in the channel, not on a GitHub issue: narrow the
+# base's GitHub tooling to the pull-request surface and drop the issue grant.
+tools:
+  chat:
+    kind: local
+    implementation: chat
+    auth:
+      kind: connection
+      provider: slack
+      connection: "{{ $slackConnection }}"
+  github:
+    kind: github
+    tools:
+      - pull_request_read
+      - create_pull_request
+      - update_pull_request
+mounts:
+  - kind: git
+    repository: "{{ $repoFullName }}"
+    mountPath: /workspace/repo
+    ref: main
+    depth: 100
+    auth:
+      kind: githubApp
+      capabilities:
+        contents: write
+        pullRequests: write
+        issues: none
+        checks: read
+        actions: read
+triggers:
+  - name: mention
+    event: chat.message.mentioned
+    connection: "{{ $slackConnection }}"
+    where:
+      $.chat.provider: slack
+      $.auto.authored: false
+      $.auto.attributions:
+        exists: false
+    message: |
+      {{message.author.userName}} mentioned you on Slack:
+
+      {{message.text}}
+
+      Channel: {{chat.channelId}}
+      Thread: {{chat.threadId}}
+
+      Reply in that thread with chat.send. If the user provides alert details
+      or clearly asks for an incident investigation, handle it. If required
+      context is missing, ask for the alert details. Otherwise, briefly explain
+      that you investigate production alerts, post triage to {{ $slackChannel }},
+      open a draft fix PR when the cause is clear, and answer follow-up
+      questions in the incident thread.
+    routing:
+      kind: spawn
+  - name: thread-reply
+    events:
+      - chat.message.mentioned
+      - chat.message.subscribed
+    connection: "{{ $slackConnection }}"
+    where:
+      $.chat.provider: slack
+      $.auto.authored: false
+      $.auto.attributions:
+        exists: true
+    message: |
+      {{message.author.userName}} replied in your incident thread:
+
+      {{message.text}}
+
+      Channel: {{chat.channelId}}
+      Thread: {{chat.threadId}}
+
+      Answer in that thread with chat.send, keeping the evidence discipline
+      from your instructions.
+    routing:
+      kind: deliver
+      routeBy:
+        kind: attributedSessions
+      onUnmatched: drop
+`
+        },
+        {
+          path: "agents/incident-response.yaml",
+          content: `name: incident-response
+model:
+  provider: anthropic
+  id: claude-opus-4-8
+identity:
+  displayName: Incident Response
+  username: incident-response
+  avatar:
+    asset: .auto/assets/sentinel.png
+    sha256: 8b8c15db5c65b19fcd81a856cc6b4c56cb64a2b6b473eedcf7159ee0e07f55ec
+  description: First responder for production alerts - posts an evidence-based triage issue and drafts a fix PR when the cause is clear.
+imports:
+  - ../fragments/environments/agent-runtime.yaml
+systemPrompt: |
+  You are the incident response agent for {{ $repoFullName }}. When an alert
+  arrives, your job is fast, evidence-based triage \u2014 not heroics.
+
+  Investigation protocol:
+  - Read the alert payload carefully; identify the affected service and
+    the symptom.
+  - Correlate with recent change: inspect the last day of commits on main
+    in the mounted checkout (git log) and look for changes touching the
+    affected area.
+  - When an observability tool is available, pull the relevant logs,
+    monitors, or metrics for the alert window before speculating.
+  - Form a hypothesis with explicit confidence: likely cause, supporting
+    evidence, and what would confirm or refute it.
+
+  Reporting protocol (GitHub issues):
+  - Create one GitHub issue for the incident with the issue_write tool:
+    the title is "[severity] service: one-line symptom", and the body
+    opens with the alert link, then the full triage \u2014 timeline, suspected
+    cause with evidence, suggested next steps, and what you ruled out.
+  - If material findings arrive after the issue exists, add them with
+    add_issue_comment rather than rewriting the body, so the record stays
+    chronological.
+
+  Fix protocol (serve the fix on a platter):
+  - When the evidence points at a specific code change with a clear,
+    contained fix \u2014 a bad commit to revert, a config value to correct, a
+    small patch \u2014 prepare it: create a focused branch from main in the
+    mounted checkout, implement the minimal fix, push the branch, and open
+    a draft pull request with create_pull_request.
+  - The PR body links the incident issue, states the hypothesis the fix
+    encodes with its evidence, and says how to verify it. Link the PR from
+    the incident issue with add_issue_comment.
+  - Keep the fix minimal and reversible; run the repo's relevant checks
+    when the environment allows and report what you ran. Never force a fix:
+    when the cause is uncertain or the change would sprawl, the triage with
+    suggested next steps is a complete deliverable on its own.
+
+  Hard limits: your only writes are the incident issue and the draft fix
+  PR. Do not merge the PR, push to main, restart services, mutate
+  infrastructure, or declare an incident resolved \u2014 humans review the fix
+  and decide that. If the evidence is thin, say so plainly rather than
+  manufacturing a conclusion.
+initialPrompt: |
+  A production alert arrived.
+
+  Alert:
+  - Title: {{title}}
+  - Severity: {{severity}}
+  - Service: {{service}}
+  - Description: {{description}}
+  - Link: {{link}}
+
+  Investigate following your responder instructions, then create the GitHub
+  incident issue with your triage. If the evidence points at a clear,
+  contained code fix, also open a draft fix PR and link it from the issue.
+mounts:
+  - kind: git
+    repository: "{{ $repoFullName }}"
+    mountPath: /workspace/repo
+    ref: main
+    depth: 100
+    auth:
+      kind: githubApp
+      capabilities:
+        contents: write
+        pullRequests: write
+        issues: write
+        checks: read
+        actions: read
+workingDirectory: /workspace/repo
+tools:
+  auto:
+    kind: local
+    implementation: auto
+  github:
+    kind: github
+    tools:
+      - issue_read
+      - issue_write
+      - add_issue_comment
+      - pull_request_read
+      - create_pull_request
+      - update_pull_request
+triggers:
+  - name: incident-webhook
+    event: webhook.incident.opened
+    endpoint: incident-webhook
+    auth:
+      kind: bearer_token
+      secretRef: incident-webhook-secret
+    routing:
+      kind: spawn
+`
+        },
+        {
+          path: "fragments/environments/agent-runtime.yaml",
+          content: "harness: claude-code\nenvironment:\n  name: agent-runtime\n  image:\n    kind: preset\n    name: node24\n  resources:\n    memoryMB: 8192\n"
+        }
+      ]
     }
   ],
   "@auto/issue-triage": [
@@ -37433,7 +37722,7 @@ var TEMPLATE_DESCRIPTIONS = {
   "@auto/code-review": "A pull-request reviewer that posts one severity-ranked review comment and reports a check; a -slack entrypoint adds Slack verdicts.",
   "@auto/daily-digest": "A scheduled read-only analyst that posts a daily shipped-code digest to a tracking issue; a -slack entrypoint posts to Slack instead.",
   "@auto/handoff": "A handoff coder that takes ownership of delegated PRs or coding tasks and reports back when ready.",
-  "@auto/incident-response": "A first responder for production alerts: investigates, posts a triage issue, and answers follow-ups; -slack entrypoint for channel triage.",
+  "@auto/incident-response": "A first responder for production alerts: investigates, posts a triage issue, and opens a draft fix PR when the cause is clear; -slack entrypoint for channel triage.",
   "@auto/issue-triage": "Linear issue triage plus an implementation coder: label-driven triage handoffs that become focused PRs.",
   "@auto/lead-engine": "An inbound-lead researcher that scores fit and drafts outreach for human approval; -slack entrypoint for a sales-channel flow.",
   "@auto/onboarding": "Auto's house onboarding guidance, importable as a managed template.",

package/dist/index.js

@@ -19729,7 +19729,7 @@ var init_organization_settings = __esm({
 });
 
 // ../../packages/schemas/src/billing.ts
-var FEE_CARD_2026_07_06, BILLING_FEE_CARDS, CURRENT_BILLING_FEE_VERSION, CREDIT_EVENT_TYPES, CreditEventTypeSchema, UsdAmountSchema, NonNegativeUsdSchema, PositiveUsdSchema, CreditEventSchema, CreditEventRecordSchema, SPENDING_LIMIT_WINDOWS, SpendingLimitWindowSchema, BilledSpendWindowsSchema, OrganizationBillingSettingsSchema, UpdateOrganizationBillingSettingsRequestSchema, OrganizationCreditsResponseSchema, AddOrganizationCreditsRequestSchema;
+var FEE_CARD_2026_07_06, BILLING_FEE_CARDS, CURRENT_BILLING_FEE_VERSION, CREDIT_EVENT_TYPES, CreditEventTypeSchema, UsdAmountSchema, NonNegativeUsdSchema, PositiveUsdSchema, MIN_CREDIT_PURCHASE_USD, MAX_CREDIT_PURCHASE_USD, wholeCents, ChargeableUsdSchema, CreditEventSchema, CreditEventRecordSchema, SPENDING_LIMIT_WINDOWS, SpendingLimitWindowSchema, BilledSpendWindowsSchema, OrganizationBillingSettingsSchema, UpdateOrganizationBillingSettingsRequestSchema, OrganizationCreditsResponseSchema, AddOrganizationCreditsRequestSchema, ReturnPathSchema, CreateCreditPurchaseRequestSchema, CreateBillingPortalSessionRequestSchema;
 var init_billing = __esm({
   "../../packages/schemas/src/billing.ts"() {
     "use strict";
@@ -19754,6 +19754,10 @@ var init_billing = __esm({
     UsdAmountSchema = external_exports.number().finite();
     NonNegativeUsdSchema = external_exports.number().finite().nonnegative();
     PositiveUsdSchema = external_exports.number().finite().positive();
+    MIN_CREDIT_PURCHASE_USD = 5;
+    MAX_CREDIT_PURCHASE_USD = 1e4;
+    wholeCents = (value) => Math.abs(value * 100 - Math.round(value * 100)) < 1e-6;
+    ChargeableUsdSchema = PositiveUsdSchema.min(MIN_CREDIT_PURCHASE_USD).max(MAX_CREDIT_PURCHASE_USD).refine(wholeCents, "amount must be a whole number of cents");
     CreditEventSchema = external_exports.object({
       organizationId: OrganizationIdSchema,
       type: CreditEventTypeSchema,
@@ -19761,7 +19765,11 @@ var init_billing = __esm({
       description: external_exports.string().trim().min(1).nullable().default(null),
       // The acting user for manual purchases/adjustments; null for system-issued
       // rows (signup grants, auto-top-ups).
-      createdByUserId: external_exports.string().trim().min(1).nullable().default(null)
+      createdByUserId: external_exports.string().trim().min(1).nullable().default(null),
+      // External payment reference (e.g. a Stripe payment intent id). Unique in
+      // the ledger, so payment-driven mints are idempotent: a webhook retry or a
+      // sync-plus-webhook race inserts once and no-ops after.
+      externalRef: external_exports.string().trim().min(1).nullable().default(null)
     }).refine(
       (event) => event.type === "adjustment" || event.amountUsd > 0,
       "Only adjustment credit events may carry a non-positive amount"
@@ -19773,6 +19781,7 @@ var init_billing = __esm({
       amountUsd: UsdAmountSchema,
       description: external_exports.string().trim().min(1).nullable(),
       createdByUserId: external_exports.string().trim().min(1).nullable(),
+      externalRef: external_exports.string().trim().min(1).nullable(),
       createdAt: external_exports.string().datetime()
     });
     SPENDING_LIMIT_WINDOWS = ["day", "month"];
@@ -19790,14 +19799,24 @@ var init_billing = __esm({
       // Balance at or below the threshold triggers a top-up of the configured
       // amount. Both must be set for auto-top-up to arm.
       autoTopUpThresholdUsd: NonNegativeUsdSchema.nullable(),
-      autoTopUpAmountUsd: PositiveUsdSchema.nullable()
+      autoTopUpAmountUsd: PositiveUsdSchema.nullable(),
+      // Stripe linkage, set by the payment flow (never by the settings PATCH):
+      // the org's Stripe customer, and the saved card auto-top-up charges
+      // off-session. A non-null payment method is what "card on file" means.
+      stripeCustomerId: external_exports.string().trim().min(1).nullable(),
+      stripeDefaultPaymentMethodId: external_exports.string().trim().min(1).nullable()
     });
     UpdateOrganizationBillingSettingsRequestSchema = external_exports.object({
       spendLimitDayUsd: PositiveUsdSchema.nullable().optional(),
       spendLimitMonthUsd: PositiveUsdSchema.nullable().optional(),
       autoTopUpEnabled: external_exports.boolean().optional(),
       autoTopUpThresholdUsd: NonNegativeUsdSchema.nullable().optional(),
-      autoTopUpAmountUsd: PositiveUsdSchema.nullable().optional()
+      // The top-up amount is charged to a real card, so it carries the same
+      // bounds as a purchase: whole cents (Stripe charges integer cents; a
+      // fractional-cent amount would make the charge and the mint disagree
+      // forever) and the purchase floor/cap (Stripe rejects sub-$0.50 charges,
+      // which would otherwise disarm auto-top-up on first trigger).
+      autoTopUpAmountUsd: ChargeableUsdSchema.nullable().optional()
     }).strict();
     OrganizationCreditsResponseSchema = external_exports.object({
       organizationId: OrganizationIdSchema,
@@ -19810,6 +19829,14 @@ var init_billing = __esm({
       amountUsd: PositiveUsdSchema.max(1e4),
       description: external_exports.string().trim().min(1).max(500).optional()
     }).strict();
+    ReturnPathSchema = external_exports.string().trim().min(1).max(2e3).regex(/^\/(?!\/)/, "returnPath must be an absolute in-app path");
+    CreateCreditPurchaseRequestSchema = external_exports.object({
+      amountUsd: ChargeableUsdSchema,
+      returnPath: ReturnPathSchema
+    }).strict();
+    CreateBillingPortalSessionRequestSchema = external_exports.object({
+      returnPath: ReturnPathSchema
+    }).strict();
   }
 });
 
@@ -23680,6 +23707,268 @@ triggers:
               content: "harness: claude-code\nenvironment:\n  name: agent-runtime\n  image:\n    kind: preset\n    name: node24\n  resources:\n    memoryMB: 8192\n"
             }
           ]
+        },
+        {
+          version: "1.3.0",
+          files: [
+            {
+              path: "agents/incident-response-slack.yaml",
+              content: `imports:
+  - ./incident-response.yaml
+systemPrompt: |
+  You are the incident response agent for {{ $repoFullName }}. When an alert
+  arrives, your job is fast, evidence-based triage \u2014 not heroics.
+
+  Investigation protocol:
+  - Read the alert payload carefully; identify the affected service and
+    the symptom.
+  - Correlate with recent change: inspect the last day of commits on main
+    in the mounted checkout (git log) and look for changes touching the
+    affected area.
+  - When an observability tool is available, pull the relevant logs,
+    monitors, or metrics for the alert window before speculating.
+  - Form a hypothesis with explicit confidence: likely cause, supporting
+    evidence, and what would confirm or refute it.
+
+  Reporting protocol (Slack {{ $slackChannel }}):
+  - Slack renders mrkdwn links: <https://url|text>.
+  - Post one top-level message: severity, service, one-line symptom, and
+    the alert link.
+  - Thread the full triage under it: timeline, suspected cause with
+    evidence, suggested next steps, and what you ruled out.
+  - After your first reply, call auto.chat.subscribe for the thread so
+    responder questions route back to you. Answer follow-ups in the same
+    thread with the same evidence discipline.
+
+  Fix protocol (serve the fix on a platter):
+  - When the evidence points at a specific code change with a clear,
+    contained fix \u2014 a bad commit to revert, a config value to correct, a
+    small patch \u2014 prepare it: create a focused branch from main in the
+    mounted checkout, implement the minimal fix, push the branch, and open
+    a draft pull request with create_pull_request.
+  - The PR body states the hypothesis the fix encodes with its evidence
+    and says how to verify it. Post the PR link in the incident thread.
+  - Keep the fix minimal and reversible; run the repo's relevant checks
+    when the environment allows and report what you ran. Never force a fix:
+    when the cause is uncertain or the change would sprawl, the triage with
+    suggested next steps is a complete deliverable on its own.
+
+  Hard limits: your only writes are the incident thread and the draft fix
+  PR. Do not merge the PR, push to main, restart services, mutate
+  infrastructure, or declare an incident resolved \u2014 humans review the fix
+  and decide that. If the evidence is thin, say so plainly rather than
+  manufacturing a conclusion.
+initialPrompt: |
+  A production alert arrived.
+
+  Alert:
+  - Title: {{title}}
+  - Severity: {{severity}}
+  - Service: {{service}}
+  - Description: {{description}}
+  - Link: {{link}}
+
+  Investigate following your responder instructions, then post the triage
+  to Slack {{ $slackChannel }} and subscribe to the thread for follow-ups.
+  If the evidence points at a clear, contained code fix, also open a draft
+  fix PR and post the link in the thread.
+# The Slack variant triages in the channel, not on a GitHub issue: narrow the
+# base's GitHub tooling to the pull-request surface and drop the issue grant.
+tools:
+  chat:
+    kind: local
+    implementation: chat
+    auth:
+      kind: connection
+      provider: slack
+      connection: "{{ $slackConnection }}"
+  github:
+    kind: github
+    tools:
+      - pull_request_read
+      - create_pull_request
+      - update_pull_request
+mounts:
+  - kind: git
+    repository: "{{ $repoFullName }}"
+    mountPath: /workspace/repo
+    ref: main
+    depth: 100
+    auth:
+      kind: githubApp
+      capabilities:
+        contents: write
+        pullRequests: write
+        issues: none
+        checks: read
+        actions: read
+triggers:
+  - name: mention
+    event: chat.message.mentioned
+    connection: "{{ $slackConnection }}"
+    where:
+      $.chat.provider: slack
+      $.auto.authored: false
+      $.auto.attributions:
+        exists: false
+    message: |
+      {{message.author.userName}} mentioned you on Slack:
+
+      {{message.text}}
+
+      Channel: {{chat.channelId}}
+      Thread: {{chat.threadId}}
+
+      Reply in that thread with chat.send. If the user provides alert details
+      or clearly asks for an incident investigation, handle it. If required
+      context is missing, ask for the alert details. Otherwise, briefly explain
+      that you investigate production alerts, post triage to {{ $slackChannel }},
+      open a draft fix PR when the cause is clear, and answer follow-up
+      questions in the incident thread.
+    routing:
+      kind: spawn
+  - name: thread-reply
+    events:
+      - chat.message.mentioned
+      - chat.message.subscribed
+    connection: "{{ $slackConnection }}"
+    where:
+      $.chat.provider: slack
+      $.auto.authored: false
+      $.auto.attributions:
+        exists: true
+    message: |
+      {{message.author.userName}} replied in your incident thread:
+
+      {{message.text}}
+
+      Channel: {{chat.channelId}}
+      Thread: {{chat.threadId}}
+
+      Answer in that thread with chat.send, keeping the evidence discipline
+      from your instructions.
+    routing:
+      kind: deliver
+      routeBy:
+        kind: attributedSessions
+      onUnmatched: drop
+`
+            },
+            {
+              path: "agents/incident-response.yaml",
+              content: `name: incident-response
+model:
+  provider: anthropic
+  id: claude-opus-4-8
+identity:
+  displayName: Incident Response
+  username: incident-response
+  avatar:
+    asset: .auto/assets/sentinel.png
+    sha256: 8b8c15db5c65b19fcd81a856cc6b4c56cb64a2b6b473eedcf7159ee0e07f55ec
+  description: First responder for production alerts - posts an evidence-based triage issue and drafts a fix PR when the cause is clear.
+imports:
+  - ../fragments/environments/agent-runtime.yaml
+systemPrompt: |
+  You are the incident response agent for {{ $repoFullName }}. When an alert
+  arrives, your job is fast, evidence-based triage \u2014 not heroics.
+
+  Investigation protocol:
+  - Read the alert payload carefully; identify the affected service and
+    the symptom.
+  - Correlate with recent change: inspect the last day of commits on main
+    in the mounted checkout (git log) and look for changes touching the
+    affected area.
+  - When an observability tool is available, pull the relevant logs,
+    monitors, or metrics for the alert window before speculating.
+  - Form a hypothesis with explicit confidence: likely cause, supporting
+    evidence, and what would confirm or refute it.
+
+  Reporting protocol (GitHub issues):
+  - Create one GitHub issue for the incident with the issue_write tool:
+    the title is "[severity] service: one-line symptom", and the body
+    opens with the alert link, then the full triage \u2014 timeline, suspected
+    cause with evidence, suggested next steps, and what you ruled out.
+  - If material findings arrive after the issue exists, add them with
+    add_issue_comment rather than rewriting the body, so the record stays
+    chronological.
+
+  Fix protocol (serve the fix on a platter):
+  - When the evidence points at a specific code change with a clear,
+    contained fix \u2014 a bad commit to revert, a config value to correct, a
+    small patch \u2014 prepare it: create a focused branch from main in the
+    mounted checkout, implement the minimal fix, push the branch, and open
+    a draft pull request with create_pull_request.
+  - The PR body links the incident issue, states the hypothesis the fix
+    encodes with its evidence, and says how to verify it. Link the PR from
+    the incident issue with add_issue_comment.
+  - Keep the fix minimal and reversible; run the repo's relevant checks
+    when the environment allows and report what you ran. Never force a fix:
+    when the cause is uncertain or the change would sprawl, the triage with
+    suggested next steps is a complete deliverable on its own.
+
+  Hard limits: your only writes are the incident issue and the draft fix
+  PR. Do not merge the PR, push to main, restart services, mutate
+  infrastructure, or declare an incident resolved \u2014 humans review the fix
+  and decide that. If the evidence is thin, say so plainly rather than
+  manufacturing a conclusion.
+initialPrompt: |
+  A production alert arrived.
+
+  Alert:
+  - Title: {{title}}
+  - Severity: {{severity}}
+  - Service: {{service}}
+  - Description: {{description}}
+  - Link: {{link}}
+
+  Investigate following your responder instructions, then create the GitHub
+  incident issue with your triage. If the evidence points at a clear,
+  contained code fix, also open a draft fix PR and link it from the issue.
+mounts:
+  - kind: git
+    repository: "{{ $repoFullName }}"
+    mountPath: /workspace/repo
+    ref: main
+    depth: 100
+    auth:
+      kind: githubApp
+      capabilities:
+        contents: write
+        pullRequests: write
+        issues: write
+        checks: read
+        actions: read
+workingDirectory: /workspace/repo
+tools:
+  auto:
+    kind: local
+    implementation: auto
+  github:
+    kind: github
+    tools:
+      - issue_read
+      - issue_write
+      - add_issue_comment
+      - pull_request_read
+      - create_pull_request
+      - update_pull_request
+triggers:
+  - name: incident-webhook
+    event: webhook.incident.opened
+    endpoint: incident-webhook
+    auth:
+      kind: bearer_token
+      secretRef: incident-webhook-secret
+    routing:
+      kind: spawn
+`
+            },
+            {
+              path: "fragments/environments/agent-runtime.yaml",
+              content: "harness: claude-code\nenvironment:\n  name: agent-runtime\n  image:\n    kind: preset\n    name: node24\n  resources:\n    memoryMB: 8192\n"
+            }
+          ]
         }
       ],
       "@auto/issue-triage": [
@@ -29276,7 +29565,7 @@ var init_hardcoded = __esm({
       "@auto/code-review": "A pull-request reviewer that posts one severity-ranked review comment and reports a check; a -slack entrypoint adds Slack verdicts.",
       "@auto/daily-digest": "A scheduled read-only analyst that posts a daily shipped-code digest to a tracking issue; a -slack entrypoint posts to Slack instead.",
       "@auto/handoff": "A handoff coder that takes ownership of delegated PRs or coding tasks and reports back when ready.",
-      "@auto/incident-response": "A first responder for production alerts: investigates, posts a triage issue, and answers follow-ups; -slack entrypoint for channel triage.",
+      "@auto/incident-response": "A first responder for production alerts: investigates, posts a triage issue, and opens a draft fix PR when the cause is clear; -slack entrypoint for channel triage.",
       "@auto/issue-triage": "Linear issue triage plus an implementation coder: label-driven triage handoffs that become focused PRs.",
       "@auto/lead-engine": "An inbound-lead researcher that scores fit and drafts outreach for human approval; -slack entrypoint for a sales-channel flow.",
       "@auto/onboarding": "Auto's house onboarding guidance, importable as a managed template.",
@@ -32356,7 +32645,7 @@ var init_package = __esm({
   "package.json"() {
     package_default = {
       name: "@autohq/cli",
-      version: "0.1.378",
+      version: "0.1.380",
       license: "SEE LICENSE IN README.md",
       publishConfig: {
         access: "public"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@autohq/cli",
-  "version": "0.1.378",
+  "version": "0.1.380",
   "license": "SEE LICENSE IN README.md",
   "publishConfig": {
     "access": "public"