@autohq/cli 0.1.84 → 0.1.86

package/dist/agent-bridge.js

@@ -21784,9 +21784,15 @@ var SESSION_RUN_DISPATCH_COMMAND_KINDS = [
   "stop"
 ];
 var SESSION_RUN_PERSISTED_COMMAND_KINDS = [
-  ...SESSION_RUN_COMMAND_KINDS,
+  "message",
+  "pause",
+  "resume",
+  "interrupt",
+  "cancel",
+  "stop",
   "start",
-  "startWithMessage"
+  "startWithMessage",
+  "answer"
 ];
 var SESSION_RUN_LIFECYCLE_COMMAND_KINDS = [
   "pause",

package/dist/index.js

@@ -17660,9 +17660,15 @@ var init_session_run_commands = __esm({
       "stop"
     ];
     SESSION_RUN_PERSISTED_COMMAND_KINDS = [
-      ...SESSION_RUN_COMMAND_KINDS,
+      "message",
+      "pause",
+      "resume",
+      "interrupt",
+      "cancel",
+      "stop",
       "start",
-      "startWithMessage"
+      "startWithMessage",
+      "answer"
     ];
     SESSION_RUN_LIFECYCLE_COMMAND_KINDS = [
       "pause",
@@ -21127,7 +21133,7 @@ var init_package = __esm({
   "package.json"() {
     package_default = {
       name: "@autohq/cli",
-      version: "0.1.84",
+      version: "0.1.86",
       license: "SEE LICENSE IN README.md",
       publishConfig: {
         access: "public"
@@ -29147,7 +29153,7 @@ var onboardingSkillMarkdown = `# Onboard your user to auto
 
 You are a coding agent running inside the user's repository. Your job is to
 take them from zero to a working auto deployment in one conversation, with
-the least possible friction. Follow the five beats in order, and run every
+the least possible friction. Follow the six beats in order, and run every
 waiting step in parallel with your own work.
 
 ## Ground rules
@@ -29199,7 +29205,8 @@ get me into your Slack." Then, without waiting:
 Build a repo dossier while the clicks happen. Explore the codebase and git
 history for:
 
-- Stack and layout: languages, frameworks, build and test setup, CI config.
+- Stack and layout: languages, frameworks, build and test setup, CI and
+  deploy workflows (Beat 6 wires into these).
 - How the team works: PR conventions, review patterns, branch and release
   habits, merge frequency.
 - Tools referenced: issue tracker keys in commits and branches, chat or
@@ -29280,6 +29287,102 @@ one workflow. Then:
 5. Apply with \`auto apply\` and confirm the trigger is active. Route the
    workflow's reports to the Slack channel from Beat 2.
 
+## Beat 6: Wire CI to apply on merge
+
+Every apply so far ran from this terminal under the user's own login. Its
+durable home is CI: a dry-run plan as a check on every PR, and the real
+apply when changes merge \u2014 \`.auto/\` ships the same way the code does. Do
+this once the GitHub App is connected and the first apply has succeeded.
+
+1. CI authenticates as a service account, never as the user. Create two \u2014
+   the \`applier\` token lives only on the merge path, while the \`read-only\`
+   token is exposed to PR-triggered runs: it can produce the dry-run plan
+   but cannot perform a real apply, and it stays revocable on its own. Pipe
+   each token straight into a GitHub secret so it never touches your
+   transcript or disk \u2014 with \`pipefail\` and \`jq -re\` so a failed create
+   cannot silently store an empty secret:
+
+   \`\`\`sh
+   set -o pipefail
+   auto service-account create github-actions-auto-apply \\
+     --preset applier --json \\
+     | jq -re .token | gh secret set AUTO_APPLY_SERVICE_ACCOUNT_TOKEN
+   auto service-account create github-actions-auto-apply-dry-run \\
+     --preset read-only --json \\
+     | jq -re .token | gh secret set AUTO_APPLY_DRY_RUN_SERVICE_ACCOUNT_TOKEN
+   \`\`\`
+
+   Confirm both pipelines exited 0 and \`gh secret list\` shows both names
+   before moving on. If deploys go through a GitHub environment, scope the
+   apply secret to it (\`gh secret set --env\`).
+2. Fit into the deploy process you mapped in Beat 3. If a workflow already
+   ships merges, splice two steps in after its deploy succeeds \u2014 plan
+   (\`auto apply --dry-run\`), then \`auto apply\` \u2014 reusing its checkout and
+   Node setup. If nothing deploys from CI yet, add the standalone workflow
+   below. Either way, keep the PR dry-run check: it shows reviewers the
+   exact create/update/archive plan their merge will execute.
+3. Workflow files live outside \`.auto/\`, so show the user the file and get
+   a yes; commit it on the same branch as the \`.auto/\` resources.
+
+\`\`\`yaml
+name: Auto Apply
+
+# Both triggers assume the default branch is main; swap in the repo's
+# actual default branch before committing.
+on:
+  pull_request:
+    branches: [main]
+  push:
+    branches: [main]
+
+permissions:
+  contents: read
+
+concurrency:
+  group: auto-apply-\${{ github.event.pull_request.number || github.ref }}
+  cancel-in-progress: \${{ github.event_name == 'pull_request' }}
+
+jobs:
+  plan:
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: lts/*
+      - run: npx -y --package=@autohq/cli auto apply --dry-run
+        env:
+          AUTO_API_TOKEN: \${{ secrets.AUTO_APPLY_DRY_RUN_SERVICE_ACCOUNT_TOKEN }}
+
+  apply:
+    if: \${{ github.event_name == 'push' }}
+    needs: plan
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: lts/*
+      - run: npx -y --package=@autohq/cli auto apply
+        env:
+          AUTO_API_TOKEN: \${{ secrets.AUTO_APPLY_SERVICE_ACCOUNT_TOKEN }}
+\`\`\`
+
+Adapt it to the repo: the default branch name, the team's Node setup or
+pinned tool versions, and set \`AUTO_API_BASE_URL\` only if the project runs
+against a non-default Auto host. \`pull_request\` runs from forks do not
+receive secrets; if fork PRs are routine here, run the dry-run from a
+\`pull_request_target\` workflow that checks out workflow code from the base
+branch and only \`.auto/\` from the PR head.
+
+After the PR merges, watch the first run and confirm its plan reports the
+resources you already applied as unchanged. From then on, \`.auto/\` on the
+default branch is the source of truth \u2014 directory apply prunes resources
+that are no longer declared, so the team changes agents by PR, not by
+terminal.
+
 ## Workflow playbook
 
 Candidates, strongest signals, and what confirms fit:
@@ -29305,15 +29408,20 @@ out loud when proposing.
   the install is approved, and have the concierge retry.
 - Sign-in stalls: the user may not have an invite yet; point them at the
   auto site and pause gracefully rather than failing.
+- \`gh secret set\` fails (no repo admin rights, gh not authenticated):
+  leave the CI workflow in the PR anyway and hand the user the two
+  create-and-pipe commands from Beat 6 to run themselves. Tokens are shown
+  once and must never be pasted into the conversation.
 - A command disagrees with this document: the command is right. Re-read
   \`auto --help\` and adapt.
 
 ## What you leave behind
 
 - \`.auto/\` committed on a branch with a PR the user can merge: the
-  concierge and workflow session YAML plus \`context.md\` (the distilled
-  dossier). Write the PR description for teammates \u2014 it doubles as the
-  announcement that this repo now has an auto agent.
+  concierge and workflow session YAML, the CI apply workflow from Beat 6,
+  plus \`context.md\` (the distilled dossier). Write the PR description for
+  teammates \u2014 it doubles as the announcement that this repo now has an
+  auto agent.
 - With the user's opt-in, an AGENTS.md section that tells every future
   coding agent in this repo that auto exists, what is deployed, and how to
   add workflows.

package/package.json

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