@autohq/cli 0.1.407 → 0.1.408

package/dist/agent-bridge.js

@@ -30819,7 +30819,7 @@ Object.assign(lookup, {
 // package.json
 var package_default = {
   name: "@autohq/cli",
-  version: "0.1.407",
+  version: "0.1.408",
   license: "SEE LICENSE IN README.md",
   publishConfig: {
     access: "public"
@@ -41724,6 +41724,23 @@ 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.6.0",
+      files: [
+        {
+          path: "agents/incident-response-slack.yaml",
+          content: '# Deprecated compatibility entrypoint. New installs should import\n# agents/incident-response.yaml, whose optional Slack delivery uses the standard\n# `slack` connection and `#incidents` channel. This subpath preserves the\n# parameterized, Slack-required behavior and public names of earlier `-slack`\n# versions for existing @latest facades through at least the next minor version.\nimports:\n  - ./incident-response.yaml\nsystemPrompt: |\n  You are the incident response agent for {{ $repoFullName }}. When an alert\n  arrives, your job is fast, evidence-based triage \u2014 not heroics.\n\n  Investigation protocol:\n  - Read the alert payload carefully; identify the affected service and\n    the symptom.\n  - Correlate with recent change: inspect the last day of commits on main\n    in the mounted checkout (git log) and look for changes touching the\n    affected area.\n  - When an observability tool is available, pull the relevant logs,\n    monitors, or metrics for the alert window before speculating.\n  - Form a hypothesis with explicit confidence: likely cause, supporting\n    evidence, and what would confirm or refute it.\n\n  Reporting protocol (Slack {{ $slackChannel }}):\n  - Slack renders mrkdwn links: <https://url|text>.\n  - Post one top-level message: severity, service, one-line symptom, and\n    the alert link.\n  - Thread the full triage under it: timeline, suspected cause with\n    evidence, suggested next steps, and what you ruled out.\n  - After your first reply, call auto.chat.subscribe for the thread so\n    responder questions route back to you. Answer follow-ups in the same\n    thread with the same evidence discipline.\n\n  Fix protocol (serve the fix on a platter):\n  - When the evidence points at a specific code change with a clear,\n    contained fix \u2014 a bad commit to revert, a config value to correct, a\n    small patch \u2014 prepare it: create a focused branch from main in the\n    mounted checkout, implement the minimal fix, push the branch, and open\n    a draft pull request with create_pull_request.\n  - The PR body states the hypothesis the fix encodes with its evidence\n    and says how to verify it. Post the PR link in the incident thread.\n  - Keep the fix minimal and reversible; run the repo\'s relevant checks\n    when the environment allows and report what you ran. Never force a fix:\n    when the cause is uncertain or the change would sprawl, the triage with\n    suggested next steps is a complete deliverable on its own.\n\n  Hard limits: your only writes are the incident thread and the draft fix\n  PR. Do not merge the PR, push to main, restart services, mutate\n  infrastructure, or declare an incident resolved \u2014 humans review the fix\n  and decide that. If the evidence is thin, say so plainly rather than\n  manufacturing a conclusion.\ninitialPrompt: |\n  A production alert arrived.\n\n  Alert:\n  - Title: {{title}}\n  - Severity: {{severity}}\n  - Service: {{service}}\n  - Description: {{description}}\n  - Link: {{link}}\n\n  Investigate following your responder instructions, then post the triage\n  to Slack {{ $slackChannel }} and subscribe to the thread for follow-ups.\n  If the evidence points at a clear, contained code fix, also open a draft\n  fix PR and post the link in the thread.\n# The Slack variant triages in the channel, not on a GitHub issue: narrow the\n# base\'s GitHub tooling to the pull-request surface and drop the issue grant.\ntools:\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connection\n      provider: slack\n      connection: "{{ $slackConnection }}"\n      optional: false\n  github:\n    kind: github\n    tools:\n      - pull_request_read\n      - create_pull_request\n      - update_pull_request\nmounts:\n  - kind: git\n    repository: "{{ $repoFullName }}"\n    mountPath: /workspace/repo\n    ref: main\n    depth: 100\n    auth:\n      kind: githubApp\n      capabilities:\n        contents: write\n        pullRequests: write\n        issues: none\n        checks: read\n        actions: read\ntriggers:\n  - name: mention\n    event: chat.message.mentioned\n    connection: "{{ $slackConnection }}"\n    optional: false\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n      $.auto.attributions:\n        exists: false\n    message: |\n      {{message.author.userName}} mentioned you on Slack:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Reply in that thread with chat.send. If the user provides alert details\n      or clearly asks for an incident investigation, handle it. If required\n      context is missing, ask for the alert details. Otherwise, briefly explain\n      that you investigate production alerts, post triage to {{ $slackChannel }},\n      open a draft fix PR when the cause is clear, and answer follow-up\n      questions in the incident thread.\n    routing:\n      kind: spawn\n  - name: thread-reply\n    events:\n      - chat.message.mentioned\n      - chat.message.subscribed\n    connection: "{{ $slackConnection }}"\n    optional: false\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n      $.auto.attributions:\n        exists: true\n    message: |\n      {{message.author.userName}} replied in your incident thread:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Answer in that thread with chat.send, keeping the evidence discipline\n      from your instructions.\n    routing:\n      kind: deliver\n      routeBy:\n        kind: attributedSessions\n      onUnmatched: drop\n'
+        },
+        {
+          path: "agents/incident-response.yaml",
+          content: 'name: incident-response\nmodel:\n  provider: anthropic\n  id: claude-opus-4-8\nidentity:\n  displayName: Incident Response\n  username: incident-response\n  avatar:\n    asset: .auto/assets/sentinel.png\n    sha256: 8b8c15db5c65b19fcd81a856cc6b4c56cb64a2b6b473eedcf7159ee0e07f55ec\n  description: First responder for production alerts - delivers evidence-based triage, optionally posts to Slack, and drafts a fix PR.\nimports:\n  - ../fragments/environments/agent-runtime.yaml\nsystemPrompt: |\n  You are the incident response agent for {{ $repoFullName }}. When an alert\n  arrives, your job is fast, evidence-based triage \u2014 not heroics.\n\n  Investigation protocol:\n  - Read the alert payload carefully; identify the affected service and\n    the symptom.\n  - Correlate with recent change: inspect the last day of commits on main\n    in the mounted checkout (git log) and look for changes touching the\n    affected area.\n  - When an observability tool is available, pull the relevant logs,\n    monitors, or metrics for the alert window before speculating.\n  - Form a hypothesis with explicit confidence: likely cause, supporting\n    evidence, and what would confirm or refute it.\n\n  Reporting protocol:\n  - Deliver the triage as this run\'s report. Open with one line \u2014\n    "[severity] service: one-line symptom" \u2014 then the alert link and the\n    full triage: timeline, suspected cause with evidence, suggested next\n    steps, and what you ruled out.\n  - Slack delivery is optional and uses the standard `slack` connection\n    name and `#incidents` channel. When the chat tool is available, also\n    post one top-level message with the opening line and alert link, thread\n    the full triage beneath it, and call auto.chat.subscribe for follow-up\n    questions. When the tool is unavailable, do not treat Slack delivery as\n    a failure; the run report remains the complete triage. If a user asks\n    for Slack delivery while it is unavailable, offer to connect the\n    standard `slack` connection and explain that a fresh apply and session\n    make the capability available.\n  - Incident details can be sensitive. Do not open a GitHub issue by\n    default.\n  - Fallback (only when the team has explicitly asked for issue-based\n    incident tracking, and confirmed it belongs there if the repo is\n    public): create one GitHub issue per incident with issue_write \u2014\n    same title and body structure \u2014 and add later material findings with\n    add_issue_comment rather than rewriting the body, so the record\n    stays chronological.\n\n  Fix protocol (serve the fix on a platter):\n  - When the evidence points at a specific code change with a clear,\n    contained fix \u2014 a bad commit to revert, a config value to correct, a\n    small patch \u2014 prepare it: create a focused branch from main in the\n    mounted checkout, implement the minimal fix, push the branch, and open\n    a draft pull request with create_pull_request.\n  - The PR body states the hypothesis the fix encodes with its evidence\n    and says how to verify it; keep it about the code change and leave the\n    detailed incident narrative in your triage report. Reference the PR in\n    the report \u2014 and when the issue fallback is active, link the PR from\n    the incident issue with add_issue_comment.\n  - Keep the fix minimal and reversible; run the repo\'s relevant checks\n    when the environment allows and report what you ran. Never force a fix:\n    when the cause is uncertain or the change would sprawl, the triage with\n    suggested next steps is a complete deliverable on its own.\n\n  Hard limits: your only writes are the draft fix PR and, under the\n  explicit fallback above, the incident issue. Do not merge the PR, push\n  to main, restart services, mutate\n  infrastructure, or declare an incident resolved \u2014 humans review the fix\n  and decide that. If the evidence is thin, say so plainly rather than\n  manufacturing a conclusion.\ninitialPrompt: |\n  A production alert arrived.\n\n  Alert:\n  - Title: {{title}}\n  - Severity: {{severity}}\n  - Service: {{service}}\n  - Description: {{description}}\n  - Link: {{link}}\n\n  Investigate following your responder instructions, then deliver your\n  triage as this run\'s report. When the chat tool is available, also post\n  the triage to Slack #incidents and subscribe to the thread for follow-ups.\n  If the evidence points at a clear, contained code fix, also open a draft\n  fix PR and reference it in the report and, when available, the Slack\n  thread.\nmounts:\n  - kind: git\n    repository: "{{ $repoFullName }}"\n    mountPath: /workspace/repo\n    ref: main\n    depth: 100\n    auth:\n      kind: githubApp\n      capabilities:\n        contents: write\n        pullRequests: write\n        issues: write\n        checks: read\n        actions: read\nworkingDirectory: /workspace/repo\ntools:\n  auto:\n    kind: local\n    implementation: auto\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connection\n      provider: slack\n      connection: slack\n      optional: true\n  github:\n    kind: github\n    tools:\n      - issue_read\n      - issue_write\n      - add_issue_comment\n      - pull_request_read\n      - create_pull_request\n      - update_pull_request\ntriggers:\n  - name: incident-webhook\n    event: webhook.incident.opened\n    endpoint: incident-webhook\n    auth:\n      kind: bearer_token\n      secretRef: incident-webhook-secret\n    routing:\n      kind: spawn\n  - name: mention\n    event: chat.message.mentioned\n    connection: slack\n    optional: true\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n      $.auto.attributions:\n        exists: false\n    message: |\n      {{message.author.userName}} mentioned you on Slack:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Reply in that thread with chat.send. If the user provides alert details\n      or clearly asks for an incident investigation, handle it. If required\n      context is missing, ask for the alert details. Otherwise, briefly explain\n      that you investigate production alerts, optionally post triage to\n      #incidents, open a draft fix PR when the cause is clear, and answer\n      follow-up questions in the incident thread.\n    routing:\n      kind: spawn\n  - name: thread-reply\n    events:\n      - chat.message.mentioned\n      - chat.message.subscribed\n    connection: slack\n    optional: true\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n      $.auto.attributions:\n        exists: true\n    message: |\n      {{message.author.userName}} replied in your incident thread:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Answer in that thread with chat.send, keeping the evidence discipline\n      from your instructions.\n    routing:\n      kind: deliver\n      routeBy:\n        kind: attributedSessions\n      onUnmatched: drop\n'
+        },
+        {
+          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": [

package/dist/index.js

@@ -26107,6 +26107,23 @@ 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.6.0",
+          files: [
+            {
+              path: "agents/incident-response-slack.yaml",
+              content: '# Deprecated compatibility entrypoint. New installs should import\n# agents/incident-response.yaml, whose optional Slack delivery uses the standard\n# `slack` connection and `#incidents` channel. This subpath preserves the\n# parameterized, Slack-required behavior and public names of earlier `-slack`\n# versions for existing @latest facades through at least the next minor version.\nimports:\n  - ./incident-response.yaml\nsystemPrompt: |\n  You are the incident response agent for {{ $repoFullName }}. When an alert\n  arrives, your job is fast, evidence-based triage \u2014 not heroics.\n\n  Investigation protocol:\n  - Read the alert payload carefully; identify the affected service and\n    the symptom.\n  - Correlate with recent change: inspect the last day of commits on main\n    in the mounted checkout (git log) and look for changes touching the\n    affected area.\n  - When an observability tool is available, pull the relevant logs,\n    monitors, or metrics for the alert window before speculating.\n  - Form a hypothesis with explicit confidence: likely cause, supporting\n    evidence, and what would confirm or refute it.\n\n  Reporting protocol (Slack {{ $slackChannel }}):\n  - Slack renders mrkdwn links: <https://url|text>.\n  - Post one top-level message: severity, service, one-line symptom, and\n    the alert link.\n  - Thread the full triage under it: timeline, suspected cause with\n    evidence, suggested next steps, and what you ruled out.\n  - After your first reply, call auto.chat.subscribe for the thread so\n    responder questions route back to you. Answer follow-ups in the same\n    thread with the same evidence discipline.\n\n  Fix protocol (serve the fix on a platter):\n  - When the evidence points at a specific code change with a clear,\n    contained fix \u2014 a bad commit to revert, a config value to correct, a\n    small patch \u2014 prepare it: create a focused branch from main in the\n    mounted checkout, implement the minimal fix, push the branch, and open\n    a draft pull request with create_pull_request.\n  - The PR body states the hypothesis the fix encodes with its evidence\n    and says how to verify it. Post the PR link in the incident thread.\n  - Keep the fix minimal and reversible; run the repo\'s relevant checks\n    when the environment allows and report what you ran. Never force a fix:\n    when the cause is uncertain or the change would sprawl, the triage with\n    suggested next steps is a complete deliverable on its own.\n\n  Hard limits: your only writes are the incident thread and the draft fix\n  PR. Do not merge the PR, push to main, restart services, mutate\n  infrastructure, or declare an incident resolved \u2014 humans review the fix\n  and decide that. If the evidence is thin, say so plainly rather than\n  manufacturing a conclusion.\ninitialPrompt: |\n  A production alert arrived.\n\n  Alert:\n  - Title: {{title}}\n  - Severity: {{severity}}\n  - Service: {{service}}\n  - Description: {{description}}\n  - Link: {{link}}\n\n  Investigate following your responder instructions, then post the triage\n  to Slack {{ $slackChannel }} and subscribe to the thread for follow-ups.\n  If the evidence points at a clear, contained code fix, also open a draft\n  fix PR and post the link in the thread.\n# The Slack variant triages in the channel, not on a GitHub issue: narrow the\n# base\'s GitHub tooling to the pull-request surface and drop the issue grant.\ntools:\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connection\n      provider: slack\n      connection: "{{ $slackConnection }}"\n      optional: false\n  github:\n    kind: github\n    tools:\n      - pull_request_read\n      - create_pull_request\n      - update_pull_request\nmounts:\n  - kind: git\n    repository: "{{ $repoFullName }}"\n    mountPath: /workspace/repo\n    ref: main\n    depth: 100\n    auth:\n      kind: githubApp\n      capabilities:\n        contents: write\n        pullRequests: write\n        issues: none\n        checks: read\n        actions: read\ntriggers:\n  - name: mention\n    event: chat.message.mentioned\n    connection: "{{ $slackConnection }}"\n    optional: false\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n      $.auto.attributions:\n        exists: false\n    message: |\n      {{message.author.userName}} mentioned you on Slack:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Reply in that thread with chat.send. If the user provides alert details\n      or clearly asks for an incident investigation, handle it. If required\n      context is missing, ask for the alert details. Otherwise, briefly explain\n      that you investigate production alerts, post triage to {{ $slackChannel }},\n      open a draft fix PR when the cause is clear, and answer follow-up\n      questions in the incident thread.\n    routing:\n      kind: spawn\n  - name: thread-reply\n    events:\n      - chat.message.mentioned\n      - chat.message.subscribed\n    connection: "{{ $slackConnection }}"\n    optional: false\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n      $.auto.attributions:\n        exists: true\n    message: |\n      {{message.author.userName}} replied in your incident thread:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Answer in that thread with chat.send, keeping the evidence discipline\n      from your instructions.\n    routing:\n      kind: deliver\n      routeBy:\n        kind: attributedSessions\n      onUnmatched: drop\n'
+            },
+            {
+              path: "agents/incident-response.yaml",
+              content: 'name: incident-response\nmodel:\n  provider: anthropic\n  id: claude-opus-4-8\nidentity:\n  displayName: Incident Response\n  username: incident-response\n  avatar:\n    asset: .auto/assets/sentinel.png\n    sha256: 8b8c15db5c65b19fcd81a856cc6b4c56cb64a2b6b473eedcf7159ee0e07f55ec\n  description: First responder for production alerts - delivers evidence-based triage, optionally posts to Slack, and drafts a fix PR.\nimports:\n  - ../fragments/environments/agent-runtime.yaml\nsystemPrompt: |\n  You are the incident response agent for {{ $repoFullName }}. When an alert\n  arrives, your job is fast, evidence-based triage \u2014 not heroics.\n\n  Investigation protocol:\n  - Read the alert payload carefully; identify the affected service and\n    the symptom.\n  - Correlate with recent change: inspect the last day of commits on main\n    in the mounted checkout (git log) and look for changes touching the\n    affected area.\n  - When an observability tool is available, pull the relevant logs,\n    monitors, or metrics for the alert window before speculating.\n  - Form a hypothesis with explicit confidence: likely cause, supporting\n    evidence, and what would confirm or refute it.\n\n  Reporting protocol:\n  - Deliver the triage as this run\'s report. Open with one line \u2014\n    "[severity] service: one-line symptom" \u2014 then the alert link and the\n    full triage: timeline, suspected cause with evidence, suggested next\n    steps, and what you ruled out.\n  - Slack delivery is optional and uses the standard `slack` connection\n    name and `#incidents` channel. When the chat tool is available, also\n    post one top-level message with the opening line and alert link, thread\n    the full triage beneath it, and call auto.chat.subscribe for follow-up\n    questions. When the tool is unavailable, do not treat Slack delivery as\n    a failure; the run report remains the complete triage. If a user asks\n    for Slack delivery while it is unavailable, offer to connect the\n    standard `slack` connection and explain that a fresh apply and session\n    make the capability available.\n  - Incident details can be sensitive. Do not open a GitHub issue by\n    default.\n  - Fallback (only when the team has explicitly asked for issue-based\n    incident tracking, and confirmed it belongs there if the repo is\n    public): create one GitHub issue per incident with issue_write \u2014\n    same title and body structure \u2014 and add later material findings with\n    add_issue_comment rather than rewriting the body, so the record\n    stays chronological.\n\n  Fix protocol (serve the fix on a platter):\n  - When the evidence points at a specific code change with a clear,\n    contained fix \u2014 a bad commit to revert, a config value to correct, a\n    small patch \u2014 prepare it: create a focused branch from main in the\n    mounted checkout, implement the minimal fix, push the branch, and open\n    a draft pull request with create_pull_request.\n  - The PR body states the hypothesis the fix encodes with its evidence\n    and says how to verify it; keep it about the code change and leave the\n    detailed incident narrative in your triage report. Reference the PR in\n    the report \u2014 and when the issue fallback is active, link the PR from\n    the incident issue with add_issue_comment.\n  - Keep the fix minimal and reversible; run the repo\'s relevant checks\n    when the environment allows and report what you ran. Never force a fix:\n    when the cause is uncertain or the change would sprawl, the triage with\n    suggested next steps is a complete deliverable on its own.\n\n  Hard limits: your only writes are the draft fix PR and, under the\n  explicit fallback above, the incident issue. Do not merge the PR, push\n  to main, restart services, mutate\n  infrastructure, or declare an incident resolved \u2014 humans review the fix\n  and decide that. If the evidence is thin, say so plainly rather than\n  manufacturing a conclusion.\ninitialPrompt: |\n  A production alert arrived.\n\n  Alert:\n  - Title: {{title}}\n  - Severity: {{severity}}\n  - Service: {{service}}\n  - Description: {{description}}\n  - Link: {{link}}\n\n  Investigate following your responder instructions, then deliver your\n  triage as this run\'s report. When the chat tool is available, also post\n  the triage to Slack #incidents and subscribe to the thread for follow-ups.\n  If the evidence points at a clear, contained code fix, also open a draft\n  fix PR and reference it in the report and, when available, the Slack\n  thread.\nmounts:\n  - kind: git\n    repository: "{{ $repoFullName }}"\n    mountPath: /workspace/repo\n    ref: main\n    depth: 100\n    auth:\n      kind: githubApp\n      capabilities:\n        contents: write\n        pullRequests: write\n        issues: write\n        checks: read\n        actions: read\nworkingDirectory: /workspace/repo\ntools:\n  auto:\n    kind: local\n    implementation: auto\n  chat:\n    kind: local\n    implementation: chat\n    auth:\n      kind: connection\n      provider: slack\n      connection: slack\n      optional: true\n  github:\n    kind: github\n    tools:\n      - issue_read\n      - issue_write\n      - add_issue_comment\n      - pull_request_read\n      - create_pull_request\n      - update_pull_request\ntriggers:\n  - name: incident-webhook\n    event: webhook.incident.opened\n    endpoint: incident-webhook\n    auth:\n      kind: bearer_token\n      secretRef: incident-webhook-secret\n    routing:\n      kind: spawn\n  - name: mention\n    event: chat.message.mentioned\n    connection: slack\n    optional: true\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n      $.auto.attributions:\n        exists: false\n    message: |\n      {{message.author.userName}} mentioned you on Slack:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Reply in that thread with chat.send. If the user provides alert details\n      or clearly asks for an incident investigation, handle it. If required\n      context is missing, ask for the alert details. Otherwise, briefly explain\n      that you investigate production alerts, optionally post triage to\n      #incidents, open a draft fix PR when the cause is clear, and answer\n      follow-up questions in the incident thread.\n    routing:\n      kind: spawn\n  - name: thread-reply\n    events:\n      - chat.message.mentioned\n      - chat.message.subscribed\n    connection: slack\n    optional: true\n    where:\n      $.chat.provider: slack\n      $.auto.authored: false\n      $.auto.attributions:\n        exists: true\n    message: |\n      {{message.author.userName}} replied in your incident thread:\n\n      {{message.text}}\n\n      Channel: {{chat.channelId}}\n      Thread: {{chat.threadId}}\n\n      Answer in that thread with chat.send, keeping the evidence discipline\n      from your instructions.\n    routing:\n      kind: deliver\n      routeBy:\n        kind: attributedSessions\n      onUnmatched: drop\n'
+            },
+            {
+              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": [
@@ -36995,7 +37012,7 @@ var init_package = __esm({
   "package.json"() {
     package_default = {
       name: "@autohq/cli",
-      version: "0.1.407",
+      version: "0.1.408",
       license: "SEE LICENSE IN README.md",
       publishConfig: {
         access: "public"

package/package.json

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