codeam-cli 2.61.26 → 2.61.28

package/CHANGELOG.md

@@ -4,6 +4,22 @@ All notable changes to `codeam-cli` are documented here.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [2.61.27] — 2026-07-24
+
+### Added
+
+- **shared:** Add spec-driven-development skill + split skills into per-file modules
+
+### Fixed
+
+- **shared:** Add PR_REVIEW_LAUNCH to USER_EVENTS (sync A↔B drift)
+
+## [2.61.26] — 2026-07-23
+
+### Fixed
+
+- **cli:** Classify 'OAuth session expired … could not be refreshed' as an auth failure
+
 ## [2.61.25] — 2026-07-23
 
 ### Fixed

package/dist/index.js

@@ -672,6 +672,31 @@ var INTEGRATION_REGISTRY = {
       }
     }
   },
+  microsoft_teams: {
+    id: "microsoft_teams",
+    name: "Microsoft Teams",
+    icon: "microsoft_teams",
+    category: "comms",
+    // COMING SOON — placeholder catalog entry (no OAuth provider / MCP yet). The
+    // agent will post review pings + read threads AS THE USER over Microsoft Graph
+    // once the provider lands. `enabled:false` renders it as a dimmed "coming
+    // soon" tile inside the (live) comms category.
+    enabled: false,
+    auth: { kind: "oauth_redirect" },
+    delivery: {}
+  },
+  google_chat: {
+    id: "google_chat",
+    name: "Google Chat",
+    icon: "google_chat",
+    category: "comms",
+    // COMING SOON — placeholder catalog entry (no OAuth provider / MCP yet). The
+    // agent will post review pings + read spaces AS THE USER over the Google Chat
+    // API once the provider lands. `enabled:false` → dimmed "coming soon" tile.
+    enabled: false,
+    auth: { kind: "oauth_redirect" },
+    delivery: {}
+  },
   notion: {
     id: "notion",
     name: "Notion",
@@ -806,7 +831,7 @@ function isKnownIntegrationId(id) {
   return id in INTEGRATION_REGISTRY;
 }
 
-// ../../packages/shared/src/skills/registry.ts
+// ../../packages/shared/src/skills/code-review.ts
 var CODE_REVIEW_BODY = `Use this skill when reviewing a pull request. It defines what a high-signal
 review looks like so your inline comments are worth the author's time.
 
@@ -839,6 +864,18 @@ line, each led by a severity tag (blocker/should-fix/nit) and a concrete reason
 (the failure scenario or risk), not a restatement of the diff. If the change is
 correct and well-tested, approve and say so \u2014 finding nothing is a valid outcome.
 Review only the diff and its direct blast radius; do not demand unrelated refactors.`;
+var codeReviewSkill = {
+  id: "code-review",
+  name: "Code Review",
+  description: `High-signal PR review: prioritize correctness \u2192 security \u2192 tests \u2192 clarity, one anchored finding per comment.`,
+  source: "curated",
+  delivery: {
+    skillFile: { body: CODE_REVIEW_BODY },
+    instruction: { body: CODE_REVIEW_INSTRUCTION }
+  }
+};
+
+// ../../packages/shared/src/skills/resolve-conflicts.ts
 var RESOLVE_CONFLICTS_BODY = `Use this skill when resolving merge conflicts on a pull request. The goal is a
 merge that preserves BOTH sides' intent, not one that just makes the file compile.
 
@@ -862,28 +899,134 @@ and prefer a union of intents; drop a side only when the two are mutually exclus
 keeping the side that matches the PR's purpose. Leave no conflict markers behind
 (grep for them). Regenerate lockfiles rather than hand-merging them. The result must
 build and pass tests \u2014 run them \u2014 before you commit and push.`;
-var SKILL_REGISTRY = {
-  "code-review": {
-    id: "code-review",
-    name: "Code Review",
-    description: `High-signal PR review: prioritize correctness \u2192 security \u2192 tests \u2192 clarity, one anchored finding per comment.`,
-    source: "curated",
-    delivery: {
-      skillFile: { body: CODE_REVIEW_BODY },
-      instruction: { body: CODE_REVIEW_INSTRUCTION }
-    }
-  },
-  "resolve-conflicts": {
-    id: "resolve-conflicts",
-    name: "Resolve Conflicts",
-    description: `Merge-conflict resolution that preserves both sides' intent, leaves no markers, and keeps the build green.`,
-    source: "curated",
-    delivery: {
-      skillFile: { body: RESOLVE_CONFLICTS_BODY },
-      instruction: { body: RESOLVE_CONFLICTS_INSTRUCTION }
-    }
+var resolveConflictsSkill = {
+  id: "resolve-conflicts",
+  name: "Resolve Conflicts",
+  description: `Merge-conflict resolution that preserves both sides' intent, leaves no markers, and keeps the build green.`,
+  source: "curated",
+  delivery: {
+    skillFile: { body: RESOLVE_CONFLICTS_BODY },
+    instruction: { body: RESOLVE_CONFLICTS_INSTRUCTION }
+  }
+};
+
+// ../../packages/shared/src/skills/spec-driven-development.ts
+var SPEC_DRIVEN_BODY = `Use this skill for any coding task that isn't a trivial one-liner. Build the right
+thing, provably, with the least ceremony the task warrants \u2014 specification before
+code, but its depth scales to the work. Skipping it yields code that looks right yet
+solves the wrong problem or breaks something you never checked.
+
+## Step 0 \u2014 Right-size the work (always first)
+- **Quick** \u2014 a typo, copy tweak, one-line fix, a single file with no unknowns.
+  No ceremony: make the change, run the relevant test/build, confirm it. Do NOT
+  write a spec for a typo.
+- **Standard** \u2014 a feature or fix across a few files, some unknowns, a testable
+  outcome. A light inline pass (a 2-3 sentence spec + a short plan), then build
+  test-first, then verify. No scaffolding files.
+- **Deep** \u2014 large, ambiguous, risky, or touching many files / shared contracts /
+  data / auth. The full flow below, tracking the work in beads (\`bd\`), not scratch
+  files.
+When unsure, start one level lighter and escalate the moment real ambiguity or risk
+appears. State which level you picked in one line.
+
+## Step 1 \u2014 Ground in the real codebase (before specifying anything non-trivial)
+You are almost never in a greenfield. Before you spec or plan, survey the real code:
+the existing patterns for this kind of change, the files you'll touch, the test
+setup, prior art, and the constraints (auth, data, shared types, CLAUDE.md
+conventions). A spec written in a vacuum produces a plan that fights the codebase.
+Read first; never assume.
+
+## Step 2 \u2014 Specify: the WHAT and WHY (not the HOW)
+State the user-visible outcome and why it matters, then the acceptance criteria \u2014
+each concrete and testable ("tapping X shows Y", "the endpoint returns 409 when Z"),
+never vague ("works well"). List what is out of scope. Put NO implementation detail
+here (no file names, no libraries). If a requirement is ambiguous, mark it rather
+than guess.
+
+## Step 3 \u2014 Clarify: resolve ambiguity, but don't stall
+Gather the ambiguities that would actually change what you build. Ask the
+highest-leverage ones \u2014 batched, at most ~3, phrased as concrete choices. For
+low-stakes unknowns, pick a sensible default and SAY so ("assuming X unless you tell
+me otherwise") instead of asking. On a conversational/mobile client every round-trip
+is expensive \u2014 don't pester; decide what you safely can.
+
+## Step 4 \u2014 Plan: the HOW, grounded and simple
+Design against the real code. Apply the simplicity gates before committing:
+- **Fewest moving parts** that satisfy the criteria. If you add a layer or
+  abstraction, justify it or drop it.
+- **Use the framework/library directly** \u2014 don't wrap it for flexibility you don't
+  need yet.
+- **Minimal blast radius** \u2014 touch what the change needs, nothing more.
+State the test strategy (what proves each criterion) and name the real risks. Keep
+the plan short.
+
+## Step 5 \u2014 Tasks: small, verifiable, ordered
+Split the plan into tasks that each end in something you can run and check. Mark
+independent ones as parallelizable. Each task is the smallest unit worth its own
+check. Sequence by dependency.
+
+## Step 6 \u2014 Implement: test-first by default
+For each task: write the test that would fail without the change, watch it fail, make
+it pass, keep it green. Follow the patterns you found in Step 1. Commit in logical
+units. Escape hatch: for a genuine spike or exploratory UI where test-first is
+impractical, say so explicitly and add the test right after \u2014 never skip it silently.
+
+## Step 7 \u2014 Verify + self-review (what separates "done" from "looks done")
+Return to the acceptance criteria and prove EACH one is met \u2014 run the tests, diff the
+behavior, look at the real output. Then review your own work adversarially:
+- What did I NOT test?
+- What did I change that I didn't need to?
+- What could this have broken (the blast radius)?
+- Does anything contradict the spec?
+Fix what you find before declaring done. "The tests I wrote pass" is not "it works".
+
+## Step 8 \u2014 Done + handoff
+Done means acceptance criteria met, tests green, no known regressions. Summarize what
+changed in plain terms. File any deferred work or follow-ups to beads (\`bd\`) so
+nothing is lost. Never claim done on unverified work.
+
+## Principles (the constitution)
+- Clarify before you build; verify before you call it done.
+- Testable beats descriptive \u2014 a criterion you can't check isn't one.
+- Grounded beats greenfield \u2014 fit the codebase that exists.
+- Simple beats clever \u2014 the least structure that works.
+- Scale the process to the task \u2014 ceremony on a typo is a bug.
+- Real work goes to beads, not throwaway files in someone's repo.`;
+var SPEC_DRIVEN_INSTRUCTION = `Follow spec-driven development, scaled to the task:
+1. Right-size first. A trivial change (typo, one file, no unknowns) \u2192 just make it
+   well and verify, no ceremony. A feature/ambiguous/risky change \u2192 spec \u2192 plan \u2192
+   build \u2192 verify.
+2. Ground in the real codebase before planning \u2014 read the existing patterns, tests,
+   and constraints. Never assume; read first.
+3. Specify the WHAT and WHY as testable acceptance criteria, not the HOW. Mark
+   ambiguities instead of guessing.
+4. Clarify only the highest-leverage unknowns (batch <=3, concrete choices); default
+   the low-stakes ones and say so. Don't stall on round-trips.
+5. Plan the simplest approach that fits the code: fewest moving parts, use libraries
+   directly, minimal blast radius. State how each criterion will be tested.
+6. Implement test-first by default; follow existing patterns; commit in logical units.
+7. Verify EACH acceptance criterion (run tests, diff behavior), then self-review
+   adversarially: what's untested? what did I change needlessly? what could I have
+   broken? what contradicts the spec? Fix before declaring done.
+8. Track deferred work in beads (bd), not scratch files. Simple beats clever; verify
+   before done.`;
+var specDrivenDevelopmentSkill = {
+  id: "spec-driven-development",
+  name: "Spec-Driven Development",
+  description: `Spec-driven development scaled to the task: right-size, ground in the code, write testable acceptance criteria, plan simply, build test-first, and verify every criterion before done.`,
+  source: "curated",
+  delivery: {
+    skillFile: { body: SPEC_DRIVEN_BODY },
+    instruction: { body: SPEC_DRIVEN_INSTRUCTION }
   }
 };
+
+// ../../packages/shared/src/skills/registry.ts
+var SKILL_REGISTRY = {
+  "code-review": codeReviewSkill,
+  "resolve-conflicts": resolveConflictsSkill,
+  "spec-driven-development": specDrivenDevelopmentSkill
+};
 function isSkillId(id) {
   return Object.prototype.hasOwnProperty.call(SKILL_REGISTRY, id);
 }
@@ -1024,7 +1167,12 @@ var USER_EVENTS = {
   // VCS / PR Command Center — the backend publishes this after an agent finishes
   // reviewing a PR (verdict + comment count + findings), driving the mobile
   // completion screen + push. Mirrored in repo A's app-shared events.ts.
-  VCS_AGENT_REVIEW_COMPLETE: "vcs_agent_review_complete"
+  VCS_AGENT_REVIEW_COMPLETE: "vcs_agent_review_complete",
+  /** PR-review launch progress toast — the "Review with an agent" flow shows a
+   *  toast when the review runs server-side (Inngest). Mobile-only surface,
+   *  produced by api-v2 (the CLI neither produces nor consumes it). Mirrored in
+   *  repo A. */
+  PR_REVIEW_LAUNCH: "pr_review_launch"
 };
 
 // ../../packages/shared/src/preview-prompts.ts
@@ -6117,7 +6265,7 @@ function readAnonId() {
 }
 function superProperties() {
   return {
-    cliVersion: true ? "2.61.26" : "0.0.0-dev",
+    cliVersion: true ? "2.61.28" : "0.0.0-dev",
     nodeVersion: process.version,
     platform: process.platform,
     arch: process.arch,
@@ -6298,7 +6446,7 @@ var os4 = __toESM(require("os"));
 // package.json
 var package_default = {
   name: "codeam-cli",
-  version: "2.61.26",
+  version: "2.61.28",
   description: "Workflow-continuity bridge for AI coding agents. Wrap Claude Code or Codex in a PTY and supervise, approve, and redirect the session from any device \u2014 async. The terminal companion for CodeAgent Mobile.",
   type: "commonjs",
   main: "dist/index.js",
@@ -7469,7 +7617,7 @@ var CommandRelayService = class _CommandRelayService {
       // fresh + clear the "CLI update available" banner after a self-update
       // (a codespace that reinstalls @latest reconnects via heartbeat, not
       // pair/reconnect). Older backends ignore the extra field.
-      ..."2.61.26" ? { ideVersion: "2.61.26" } : {}
+      ..."2.61.28" ? { ideVersion: "2.61.28" } : {}
     }).then(() => log.trace("relay", `heartbeat ok online=${online}`)).catch((err) => log.trace("relay", `heartbeat failed online=${online}`, err));
   }
   /**
@@ -18331,7 +18479,7 @@ async function autoUpgradeBeforeCriticalCommand() {
   if (process.env.NODE_ENV === "test") return;
   if (process.env.CODEAM_DISABLE_UPDATE_CHECK === "1") return;
   if (process.env.CI) return;
-  const current = true ? "2.61.26" : null;
+  const current = true ? "2.61.28" : null;
   if (!current) return;
   const cache = readCache();
   const fresh = cache && Date.now() - cache.fetchedAt < TTL_MS;
@@ -18348,7 +18496,7 @@ function checkForUpdates() {
   if (process.env.CODEAM_DISABLE_UPDATE_CHECK === "1") return;
   if (process.env.CI) return;
   if (!process.stdout.isTTY) return;
-  const current = true ? "2.61.26" : null;
+  const current = true ? "2.61.28" : null;
   if (!current) return;
   const cache = readCache();
   const fresh = cache && Date.now() - cache.fetchedAt < TTL_MS;
@@ -18368,7 +18516,7 @@ var SELF_UPDATE_INTERVAL_MS = 60 * 60 * 1e3;
 var SELF_UPDATE_VIEW_TIMEOUT_MS = 3e4;
 var SELF_UPDATE_INSTALL_TIMEOUT_MS = 18e4;
 function currentCliVersion() {
-  return true ? "2.61.26" : null;
+  return true ? "2.61.28" : null;
 }
 function runCmd(cmd, args2, timeoutMs) {
   return new Promise((resolve8) => {
@@ -38361,7 +38509,7 @@ function checkChokidar() {
 }
 async function doctor(args2 = []) {
   const json = args2.includes("--json");
-  const cliVersion = true ? "2.61.26" : "0.0.0-dev";
+  const cliVersion = true ? "2.61.28" : "0.0.0-dev";
   const apiBase2 = resolveApiBaseUrl();
   const diagnosticId = (0, import_node_crypto13.randomUUID)();
   log.info("doctor", `run id=${diagnosticId} cli=${cliVersion}`);
@@ -38872,7 +39020,7 @@ async function mcpRun(args2) {
 // src/commands/version.ts
 var import_picocolors15 = __toESM(require("picocolors"));
 function version2() {
-  const v = true ? "2.61.26" : "unknown";
+  const v = true ? "2.61.28" : "unknown";
   console.log(`${import_picocolors15.default.bold("codeam-cli")} ${import_picocolors15.default.cyan(v)}`);
 }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codeam-cli",
-  "version": "2.61.26",
+  "version": "2.61.28",
   "description": "Workflow-continuity bridge for AI coding agents. Wrap Claude Code or Codex in a PTY and supervise, approve, and redirect the session from any device — async. The terminal companion for CodeAgent Mobile.",
   "type": "commonjs",
   "main": "dist/index.js",