@codeam/shared 2.61.26 → 2.61.28

package/dist/index.mjs

@@ -645,6 +645,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",
@@ -830,6 +855,22 @@ var INTEGRATION_BRANDING = {
     brandColor: "#E01E5A",
     logoSvg: '<svg width="54" height="54" viewBox="0 0 54 54" fill="none" xmlns="http://www.w3.org/2000/svg"><g clip-path="url(#clip0_4127_70105)"><path d="M11.379 33.9993C11.379 37.1358 8.84512 39.6507 5.7276 39.6507C2.61008 39.6507 0.0572205 37.1168 0.0572205 33.9993C0.0572205 30.8817 2.5911 28.3479 5.70862 28.3479H11.36V33.9993H11.379Z" fill="#E01E5A"/><path d="M14.1962 33.9997C14.1962 30.8632 16.7301 28.3483 19.8476 28.3483C22.9651 28.3483 25.499 30.8822 25.499 33.9997V48.1353C25.499 51.2718 22.9651 53.7867 19.8476 53.7867C16.7301 53.7867 14.1962 51.2718 14.1962 48.1353V33.9997Z" fill="#E01E5A"/><path d="M19.8662 11.2673C16.7296 11.2673 14.2148 8.73347 14.2148 5.61594C14.2148 2.49842 16.7486 -0.0354538 19.8662 -0.0354538C22.9837 -0.0354538 25.5175 2.49842 25.5175 5.61594V11.2673H19.8662Z" fill="#36C5F0"/><path d="M19.8682 14.1334C23.0047 14.1334 25.5196 16.6673 25.5196 19.7848C25.5196 22.9023 22.9857 25.4362 19.8682 25.4362H5.67566C2.53916 25.4362 0.0242615 22.9023 0.0242615 19.7848C0.0242615 16.6673 2.55814 14.1334 5.67566 14.1334H19.8682Z" fill="#36C5F0"/><path d="M42.5323 19.7853C42.5323 16.6488 45.0662 14.1339 48.1837 14.1339C51.3012 14.1339 53.8351 16.6678 53.8351 19.7853C53.8351 22.9028 51.3012 25.4367 48.1837 25.4367H42.5323V19.7853Z" fill="#2EB67D"/><path d="M39.7126 19.7934C39.7126 22.9299 37.1787 25.4448 34.0612 25.4448C30.9436 25.4448 28.4098 22.911 28.4098 19.7934V5.61986C28.4098 2.48336 30.9436 -0.0315399 34.0612 -0.0315399C37.1787 -0.0315399 39.7126 2.48336 39.7126 5.61986V19.7934Z" fill="#2EB67D"/><path d="M34.0376 42.482C37.1741 42.482 39.689 45.0158 39.689 48.1334C39.689 51.2509 37.1552 53.7848 34.0376 53.7848C30.9201 53.7848 28.3862 51.2509 28.3862 48.1334V42.482H34.0376Z" fill="#ECB22E"/><path d="M34.0381 39.6507C30.9016 39.6507 28.3867 37.1168 28.3867 33.9993C28.3867 30.8818 30.9206 28.3479 34.0381 28.3479H48.2306C51.3671 28.3479 53.882 30.8818 53.882 33.9993C53.882 37.1168 51.3482 39.6507 48.2306 39.6507H34.0381Z" fill="#ECB22E"/></g><defs><clipPath id="clip0_4127_70105"><rect width="54" height="54" fill="white"/></clipPath></defs></svg>'
   },
+  microsoft_teams: {
+    id: "microsoft_teams",
+    name: "Microsoft Teams",
+    vendor: "Microsoft",
+    tagline: "Team chat & collaboration",
+    brandColor: "#6264A7",
+    logoSvg: '<svg width="54" height="54" viewBox="0 0 54 54" fill="none" xmlns="http://www.w3.org/2000/svg"><path d="M36.6 22h12.3c1 0 1.8.8 1.8 1.8v10.4a7.2 7.2 0 0 1-7.2 7.2 7.2 7.2 0 0 1-7.2-7.2V22z" fill="#5059C9"/><circle cx="44" cy="14.4" r="4.6" fill="#5059C9"/><circle cx="27.2" cy="12" r="6.6" fill="#7B83EB"/><path d="M35.4 22H16.9c-1 .02-1.8.86-1.78 1.86v11.9A12 12 0 0 0 26.9 47.6a12 12 0 0 0 10.28-11.84V23.86c.02-1-.78-1.84-1.78-1.86z" fill="#7B83EB"/><path opacity=".12" d="M28 22v18.4a1.86 1.86 0 0 1-1.72 1.84H15.72A12.7 12.7 0 0 1 15.12 38V23.86c-.02-1 .78-1.84 1.78-1.86H28z" fill="#000"/><rect x="2.5" y="15" width="23.5" height="23.5" rx="2.2" fill="#4B53BC"/><path d="M19.8 21.4H8.7v3.05h4v11.1h3.1v-11.1h4V21.4z" fill="#fff"/></svg>'
+  },
+  google_chat: {
+    id: "google_chat",
+    name: "Google Chat",
+    vendor: "Google",
+    tagline: "Team messaging & spaces",
+    brandColor: "#00AC47",
+    logoSvg: '<svg width="54" height="54" viewBox="0 0 54 54" fill="none" xmlns="http://www.w3.org/2000/svg"><path d="M46 6H8a3.5 3.5 0 0 0-3.5 3.5v26A3.5 3.5 0 0 0 8 39h4.5v8.2a1.3 1.3 0 0 0 2.15 1L26 39h20a3.5 3.5 0 0 0 3.5-3.5v-26A3.5 3.5 0 0 0 46 6z" fill="#00AC47"/><circle cx="19.5" cy="22.5" r="3.1" fill="#fff"/><circle cx="34.5" cy="22.5" r="3.1" fill="#fff"/></svg>'
+  },
   linear: {
     id: "linear",
     name: "Linear",
@@ -1022,7 +1063,7 @@ function getIntegrationBranding(id) {
   return INTEGRATION_BRANDING[id] ?? null;
 }
 
-// src/skills/registry.ts
+// 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.
 
@@ -1055,6 +1096,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 }
+  }
+};
+
+// 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.
 
@@ -1078,28 +1131,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 }
+  }
+};
+
+// 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 }
   }
 };
+
+// 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);
 }
@@ -1247,7 +1406,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"
 };
 
 // src/preview-prompts.ts