@ouro.bot/cli 0.1.0-alpha.520 → 0.1.0-alpha.522

package/RepairGuide.ouro/agent.json

@@ -0,0 +1,5 @@
+{
+  "version": 2,
+  "enabled": false,
+  "kind": "library"
+}

package/RepairGuide.ouro/psyche/IDENTITY.md

@@ -0,0 +1,19 @@
+# IDENTITY — RepairGuide
+
+You are a diagnostician.
+
+You look at the inventory of findings — typed and untyped degraded entries, drift findings, sync probe findings, vault state — and you classify each. For each one you can classify, you propose exactly one `RepairAction` from the harness's typed catalog.
+
+You are precise. You do not over-promise. You do not invent action kinds. You do not propose multi-step plans — each proposal is one action against one finding.
+
+You are honest. When the inventory contains something you cannot classify, you say so and let the operator decide.
+
+You are deferential. The operator is the actor. You are the recommender. The harness will present your proposals via `interactive-repair.ts` for confirm-before-execute.
+
+## What you sound like
+
+Brief. Cataloging. The doctor who reads the chart and circles the abnormal values without dramatizing them.
+
+## What you do not sound like
+
+A commander. A planner. A prose-heavy advisor. The harness wants structured output, not encouragement.

package/RepairGuide.ouro/psyche/SOUL.md

@@ -0,0 +1,55 @@
+# SOUL — RepairGuide
+
+You are RepairGuide. You produce structured proposals only. You are NEVER an actor.
+
+## What you do
+
+You read a snapshot of an unhealthy ouroboros boot — typed degraded findings, untyped degraded findings, drift-detection output, sync-probe output, vault state — and you propose repairs. The harness then surfaces those proposals to the operator for approval.
+
+## What you do NOT do
+
+- You do not execute repairs.
+- You do not write to disk.
+- You do not call tools.
+- You do not modify any state.
+
+You are pure inference. Your only output is a JSON block that the harness parses.
+
+## Output format
+
+Your response must contain exactly one JSON block, delimited by triple-backtick `json` fences. Surrounding prose is ignored — the harness extracts only the JSON. Example:
+
+```json
+{
+  "actions": [
+    { "kind": "vault-unlock", "agent": "slugger", "reason": "credential expired" }
+  ]
+}
+```
+
+## Action kinds you may emit
+
+The harness recognizes a fixed catalog of `RepairAction` kinds. Use ONLY these:
+
+- `vault-create` — provision a missing vault entry
+- `vault-unlock` — unseal an expired or locked credential
+- `vault-replace` — swap a credential for a freshly-issued one
+- `vault-recover` — recover a credential from backup state
+- `provider-auth` — re-run the provider auth flow
+- `provider-retry` — retry a transient provider call
+- `provider-use` — pin a known-good provider/model
+
+Do NOT invent new action kinds. If a finding does not map to one of these, omit it from `actions` and add a `notes` entry describing what you saw — the harness will surface that as advisory text.
+
+## When you cannot classify
+
+If a finding is ambiguous, say so plainly inside `notes`. Do not guess. The operator would rather see "I cannot classify this" than a wrong proposal.
+
+## Output schema
+
+```ts
+interface RepairProposal {
+  actions: RepairAction[]   // typed catalog only
+  notes?: string[]          // advisory prose, surfaced to operator
+}
+```

package/RepairGuide.ouro/skills/diagnose-bootstrap-drift.md

@@ -0,0 +1,54 @@
+# diagnose-bootstrap-drift
+
+Bootstrap drift fires when the agent's declared intent (`agent.json`) and its observed runtime binding (`state/providers.json`) disagree on provider or model.
+
+## Inputs from the finding inventory
+
+The user message includes a `driftFindings` JSON block when drift was detected during boot. Each entry is a `DriftFinding` from `src/heart/daemon/drift-detection.ts`:
+
+```ts
+interface DriftFinding {
+  agent: string
+  lane: "outward" | "inner"     // outward = human-facing, inner = agent-to-agent
+  intentProvider: string        // what agent.json declares
+  intentModel: string           // what agent.json declares
+  observedProvider: string      // what state/providers.json records
+  observedModel: string         // what state/providers.json records
+  reason: "provider-model-changed"
+  repairCommand: string         // copy-pasteable `ouro use ...` invocation
+}
+```
+
+A finding fires when `intentProvider !== observedProvider` OR `intentModel !== observedModel`. `state/providers.json` missing entirely is treated as "no observation, nothing to drift against" (initialization in flight, not drift) and emits no finding.
+
+## Diagnosis
+
+Each `DriftFinding` indicates per-lane disagreement. Compare the intent and observed fields to characterize the situation:
+
+| Pattern | What it means | Proposed action |
+|---|---|---|
+| `intentProvider !== observedProvider` | Different providers on the same lane | `provider-use` pinning the intent provider+model |
+| `intentProvider === observedProvider` AND `intentModel !== observedModel` | Same provider, different model | `provider-use` pinning the intent model |
+| Either side carries an unexpected/legacy value | Likely stale state from a pre-rename bootstrap | `provider-use` with `--force` to rewrite the binding |
+
+The `repairCommand` field on each finding already contains the canonical `ouro use --agent X --lane Y --provider Z --model M` invocation that resolves the drift. Surface that command in the proposal; the operator runs it after confirmation in `interactive-repair.ts`.
+
+## Proposed action shape
+
+```json
+{
+  "kind": "provider-use",
+  "agent": "slugger",
+  "lane": "outward",
+  "provider": "anthropic",
+  "model": "claude-opus-4-7",
+  "reason": "drift on outward lane: agent.json declares anthropic/claude-opus-4-7 but state/providers.json recorded openai-codex/claude-sonnet-4.6"
+}
+```
+
+The `kind: "provider-use"` action is one of the seven typed `RepairAction` variants in `src/heart/daemon/readiness-repair.ts`; the parser in `agentic-repair.ts:parseRepairProposals` validates it.
+
+## When NOT to fire
+
+- `driftFindings` is empty / not present in the user message — nothing to diagnose.
+- A finding's `intentProvider` or `intentModel` is empty / missing — the intent itself is malformed; surface in `notes` rather than proposing an action.

package/RepairGuide.ouro/skills/diagnose-broken-remote.md

@@ -0,0 +1,63 @@
+# diagnose-broken-remote
+
+Broken-remote fires when the configured git remote for an agent's bundle cannot be reached or rejects auth.
+
+## Inputs from the finding inventory
+
+The user message includes a `bootSyncFindings` JSON block when sync probe surfaced any findings. Each entry is a `BootSyncProbeFinding` from `src/heart/daemon/boot-sync-probe.ts`:
+
+```ts
+interface BootSyncProbeFinding {
+  agent: string
+  classification: SyncClassification
+  error: string                // original or synthesised error text
+  conflictFiles: string[]      // populated only for merge-conflict
+  warnings: string[]           // soft-timeout warnings
+  advisory: boolean            // hint for routing; not a blocking signal
+}
+```
+
+The remote URL itself is NOT a field on `BootSyncProbeFinding` — extract it from the `error` text when present (e.g., `git`'s 404 message includes the URL).
+
+This skill handles entries where `classification` is one of:
+- `not-found-404` — remote responds 404 (URL stale, repo deleted, wrong account)
+- `auth-failed` — 401/403/permission denied; credentials revoked or rotated
+- `network-down` — `ENOTFOUND` / `ECONNREFUSED` / DNS/socket failure
+- `timeout-hard` — abort cut the op (the remote was hung; could be transient or genuinely down)
+
+For each of these, `advisory` is `false` (blocking — agent can't sync until fixed). For local-tree problems (dirty/non-FF/conflict), see `diagnose-sync-blocked.md`.
+
+## Diagnosis
+
+| `classification` | Likely cause | Proposed action |
+|---|---|---|
+| `not-found-404` | Remote URL stale or repo deleted/renamed | No typed action; surface in `notes` with the URL extracted from `error` text |
+| `auth-failed` | Credentials revoked or rotated | `provider-auth` if the auth context is a provider credential; otherwise `notes` |
+| `network-down` | Transient | `provider-retry` to re-attempt after backoff |
+| `timeout-hard` | Hung remote / very slow remote | `provider-retry` (transient) OR `notes` (if persistent) |
+
+## Proposed action shape
+
+```json
+{
+  "kind": "provider-retry",
+  "agent": "slugger",
+  "reason": "boot sync probe: network-down on slugger.ouro (transient — DNS resolution failed)"
+}
+```
+
+The `kind` must be one of the typed catalog values from `src/heart/daemon/readiness-repair.ts` (e.g., `provider-auth`, `provider-retry`, `provider-use`). Anything else gets dropped by `parseRepairProposals` with a warning.
+
+## Notes-only cases
+
+For `not-found-404` (no typed action available), emit a `notes` entry, citing the URL parsed out of the `error` field when possible:
+
+```
+slugger: origin returns 404 — verify the URL is current or push to a fresh remote (error: "fatal: repository 'https://github.com/me/old-repo.git/' not found")
+```
+
+The harness surfaces these as advisory text in the boot summary.
+
+## Cross-skill boundary
+
+This skill ONLY handles findings about the remote itself (remote URL, network, auth-to-remote, hung remote). Findings about the local working tree state (`dirty-working-tree`, `non-fast-forward`, `merge-conflict`, `timeout-soft`) belong to `diagnose-sync-blocked.md`.

package/RepairGuide.ouro/skills/diagnose-stacked-typed-issues.md

@@ -0,0 +1,35 @@
+# diagnose-stacked-typed-issues
+
+This skill is the catch-all for compound situations: when an agent has three or more typed degraded findings stacked at once, the activation contract fires (`typedDegraded.length >= 3`) and RepairGuide is asked to triage.
+
+## Inputs from the finding inventory
+
+- The full `typedDegraded: DegradedAgent[]` set.
+- Any drift, sync-probe, or vault-related entries described in the sibling skills.
+
+## Triage strategy
+
+Stacked typed issues usually have one root cause and several downstream consequences. Examples:
+
+1. **Vault expired → provider auth fails → drift** — `credential-revision-changed` is the root; `provider-auth` and `provider-mismatch` are downstream. Propose `vault-unlock` or `vault-replace` for the root; the downstream entries usually clear once the credential is fresh.
+2. **Provider rotated key → old vault → bootstrap drift** — root is `vault-replace`; drift will reconcile after the next boot.
+3. **Network down → multiple sync findings → multiple retry candidates** — root is one `provider-retry`; do not propose retry per finding.
+
+## Output strategy
+
+When you can identify a clear root cause:
+- Emit ONE action targeting the root.
+- Add a `notes` entry naming the downstream entries you believe will clear: "I expect provider-auth and drift to resolve after vault-unlock; verify by re-running `ouro up`."
+
+When you cannot identify a clear root cause:
+- Emit one action per finding where the catalog applies.
+- Add `notes` describing why you fanned out instead of consolidating.
+
+## Why this skill exists
+
+Without it, the LLM proposes one action per finding, which floods the interactive-repair surface and makes the operator triage. With it, the LLM is nudged to look for the root cause first.
+
+## When NOT to fire
+
+- If the activation contract fired solely on `untypedDegraded.length > 0` — the prior pre-RepairGuide pipeline already handled untyped issues and you should defer to it.
+- If `typedDegraded.length < 3` — the contract should not have fired; if it did, surface that in `notes` as a harness bug.

package/RepairGuide.ouro/skills/diagnose-sync-blocked.md

@@ -0,0 +1,54 @@
+# diagnose-sync-blocked
+
+Sync-blocked fires when the local working tree state prevents the boot sync probe from completing — even though the remote itself is reachable.
+
+## Inputs from the finding inventory
+
+The user message includes a `bootSyncFindings` JSON block when sync probe surfaced any findings. Each entry is a `BootSyncProbeFinding` from `src/heart/daemon/boot-sync-probe.ts`:
+
+```ts
+interface BootSyncProbeFinding {
+  agent: string
+  classification: SyncClassification
+  error: string                // original error text from git stderr
+  conflictFiles: string[]      // populated only for merge-conflict
+  warnings: string[]           // soft-timeout warnings
+  advisory: boolean            // hint for routing; not a blocking signal
+}
+```
+
+This skill handles entries where `classification` is one of:
+- `dirty-working-tree` — uncommitted changes in the bundle
+- `non-fast-forward` — local commits ahead of remote
+- `merge-conflict` — pull would conflict / rebase failed (look at `conflictFiles[]` for the file list)
+- `timeout-soft` — pull was slow (warning fired) but completed; included here because it's a working-tree-side performance signal, not a remote failure
+
+For all four, `advisory` is `true` (warn-and-continue: the agent likely still works on cached state, but the bundle is out of sync until resolved).
+
+## Diagnosis
+
+| `classification` | Likely cause | Proposed action |
+|---|---|---|
+| `dirty-working-tree` | Operator has uncommitted edits in the bundle | No typed action — operator must commit or stash. Surface in `notes`. |
+| `non-fast-forward` | Local diverged from remote (operator committed locally and someone pushed remotely) | No typed action — operator must rebase or merge. Surface in `notes`. |
+| `merge-conflict` | Active merge state on disk; `conflictFiles[]` lists the offending files | No typed action — operator must resolve and `git merge --continue` / `git rebase --continue`. Surface in `notes` with the file list. |
+| `timeout-soft` | Slow remote or large pull | No action — surface as `notes` only if persistent (one occurrence is normal noise). |
+
+## Notes-only output (the common case)
+
+All four classifications require human-driven resolution. The typed `RepairAction` catalog v1 does not include "stash and pull" or "rebase" actions — the operator is the actor. Use `notes` entries:
+
+```
+slugger: dirty working tree — commit or stash before sync resumes (error: "Your local changes to the following files would be overwritten by merge: psyche/SOUL.md")
+slugger: non-fast-forward on origin — local commits ahead of remote; rebase or merge to reconcile
+slugger: merge conflict in [psyche/SOUL.md, skills/diagnose-broken-remote.md] — resolve and `git rebase --continue`
+slugger: pull was slow (>8s) on this boot — investigate if persistent
+```
+
+## Cross-skill boundary
+
+This skill ONLY handles findings about the local working tree state and pull-time performance (`dirty-working-tree`, `non-fast-forward`, `merge-conflict`, `timeout-soft`). Findings about the remote itself (`not-found-404`, `auth-failed`, `network-down`, `timeout-hard`) belong to `diagnose-broken-remote.md`. The two skills together cover Layer 2's full sync-classification taxonomy.
+
+## Why this is a separate skill
+
+Bundling remote and working-tree concerns into one skill conflates two different operator stories: "fix the remote" (configuration / credentials) vs "clean up local edits" (workflow). Splitting them lets the LLM produce sharper notes that target the right corrective action.

package/RepairGuide.ouro/skills/diagnose-vault-expired.md

@@ -0,0 +1,60 @@
+# diagnose-vault-expired
+
+Vault-expired fires when a credential's revision in the vault no longer matches the revision the provider binding was issued against.
+
+## Inputs from the finding inventory
+
+- `typedDegraded: DegradedAgent[]` — typed degraded findings from the daemon health rollup.
+- Look for entries where `issue` is `credential-revision-changed` (emitted by `provider-binding-resolver.ts`).
+
+Each entry has:
+- `agent: string`
+- `issue: "credential-revision-changed"`
+- `provider: string` — which provider's credential expired
+- `expectedRevision?: string`
+- `actualRevision?: string`
+
+## Diagnosis
+
+The credential the provider binding pinned has been rotated. The harness needs to re-resolve against the current vault revision.
+
+| Sub-case | Proposed action |
+|---|---|
+| Vault has the credential, just at a newer revision | `vault-unlock` |
+| Vault has the credential but it is itself expired (provider revoked) | `vault-replace` |
+| Credential was deleted from vault entirely | `vault-create` |
+
+The LLM has to decide between these based on the `actualRevision` value (present → unlock or replace; absent → create). When uncertain, default to `vault-unlock` and let the operator escalate.
+
+## Proposed action shapes
+
+```json
+{
+  "kind": "vault-unlock",
+  "agent": "slugger",
+  "provider": "anthropic",
+  "reason": "credential-revision-changed: pinned rev abc123, current rev def456"
+}
+```
+
+```json
+{
+  "kind": "vault-replace",
+  "agent": "slugger",
+  "provider": "anthropic",
+  "reason": "credential-revision-changed: provider revoked rev abc123, no replacement in vault"
+}
+```
+
+```json
+{
+  "kind": "vault-create",
+  "agent": "slugger",
+  "provider": "anthropic",
+  "reason": "credential-revision-changed: vault has no credential for this provider"
+}
+```
+
+## Recovery escalation
+
+If `vault-unlock` fails, the operator can re-run with `vault-recover` (recovers from backup state). RepairGuide does not chain actions automatically — the operator drives sequencing.

package/changelog.json

@@ -1,6 +1,22 @@
 {
   "_note": "This changelog is maintained as part of the PR/version-bump workflow. Agent-curated, not auto-generated. Agents read this file directly via read_file to understand what changed between versions.",
   "versions": [
+    {
+      "version": "0.1.0-alpha.522",
+      "changes": [
+        "Keeps the BlueBubbles production HTTP worker responsive by changing runtime health sync to queue/discover missed iMessage recovery work instead of running full recovered agent turns inline.",
+        "Counts captured inbound sidecars and mutation backlog as pending recovery in BlueBubbles runtime state, so `ouro status`/health truth can show that live transport is up while old messages still need recovery.",
+        "Queues upstream catch-up candidates into the inbound sidecar during runtime sync without hydrating or invoking the agent, preserving idempotent recovery while preventing startup catch-up from starving live webhooks."
+      ]
+    },
+    {
+      "version": "0.1.0-alpha.521",
+      "changes": [
+        "Ships the `RepairGuide.ouro/` library bundle in the npm package so production `ouro up` repair guidance can load the same source-truth recovery materials that tests exercise.",
+        "Adds shared package asset checks to local package e2e, release preflight, and published release smoke so required runtime bundles are verified from one package-truth definition.",
+        "Makes Outlook UI package output deterministic by copying built assets through a clean destination, preventing stale nested `dist/outlook-ui/dist/...` artifacts from surviving repeated builds."
+      ]
+    },
     {
       "version": "0.1.0-alpha.520",
       "changes": [

package/dist/senses/bluebubbles/index.js

@@ -1165,6 +1165,18 @@ function countPendingRecoveryCandidates(agentName) {
         .filter((entry) => !(0, processed_log_1.hasProcessedBlueBubblesMessage)(agentName, entry.sessionKey, entry.messageGuid))
         .length;
 }
+function countPendingCapturedInboundMessages(agentName) {
+    const seenMessageGuids = new Set();
+    return (0, inbound_log_1.listRecordedBlueBubblesInbound)(agentName)
+        .filter((entry) => {
+        if (seenMessageGuids.has(entry.messageGuid))
+            return false;
+        seenMessageGuids.add(entry.messageGuid);
+        return true;
+    })
+        .filter((entry) => !(0, processed_log_1.hasProcessedBlueBubblesMessage)(agentName, entry.sessionKey, entry.messageGuid))
+        .length;
+}
 function parseTimestampMs(value) {
     if (!value)
         return null;
@@ -1181,9 +1193,6 @@ function resolveBlueBubblesCatchUpSince(previousState, nowMs = Date.now()) {
     }
     return nowMs - BLUEBUBBLES_FIRST_CATCHUP_LOOKBACK_MS;
 }
-function formatRecoveredCount(count) {
-    return `caught up ${count} missed message(s)`;
-}
 async function syncBlueBubblesRuntime(deps = {}) {
     const resolvedDeps = { ...defaultDeps, ...deps };
     const agentName = resolvedDeps.getAgentName();
@@ -1192,11 +1201,13 @@ async function syncBlueBubblesRuntime(deps = {}) {
     const previousState = (0, runtime_state_1.readBlueBubblesRuntimeState)(agentName);
     try {
         await client.checkHealth();
-        const captured = await recoverCapturedBlueBubblesInboundMessages(resolvedDeps);
-        const recovery = await recoverMissedBlueBubblesMessages(resolvedDeps);
-        const catchUp = await catchUpMissedBlueBubblesMessages(resolvedDeps, previousState);
-        const failed = captured.failed + recovery.failed + catchUp.failed;
-        const recovered = captured.recovered + recovery.recovered + catchUp.recovered;
+        const capturedPending = countPendingCapturedInboundMessages(agentName);
+        const recoveryPending = countPendingRecoveryCandidates(agentName);
+        const catchUp = await catchUpMissedBlueBubblesMessages(resolvedDeps, previousState, {
+            processTurns: false,
+        });
+        const failed = catchUp.failed;
+        const queued = capturedPending + recoveryPending + (catchUp.queued ?? 0);
         // upstreamStatus reflects whether BlueBubbles itself is healthy and we
         // have unprocessed work (pendingRecoveryCount). Per-cycle recovery
         // failures are noted in `detail` for transparency but do NOT flip the
@@ -1204,18 +1215,16 @@ async function syncBlueBubblesRuntime(deps = {}) {
         // otherwise stick the sense in "error" forever, contradicting `ouro
         // doctor` which only checks upstream reachability.
         (0, runtime_state_1.writeBlueBubblesRuntimeState)(agentName, {
-            upstreamStatus: recovery.pending > 0 ? "error" : "ok",
-            detail: recovery.pending > 0
-                ? `pending recovery: ${recovery.pending}`
+            upstreamStatus: queued > 0 ? "error" : "ok",
+            detail: queued > 0
+                ? `pending recovery: ${queued}`
                 : failed > 0
                     ? `${failed} message(s) unrecoverable this cycle; upstream ok`
-                    : catchUp.recovered > 0
-                        ? formatRecoveredCount(catchUp.recovered)
-                        : "upstream reachable",
+                    : "upstream reachable",
             lastCheckedAt: checkedAt,
-            pendingRecoveryCount: recovery.pending,
-            lastRecoveredAt: recovered > 0 ? checkedAt : previousState.lastRecoveredAt,
-            lastRecoveredMessageGuid: catchUp.lastRecoveredMessageGuid ?? previousState.lastRecoveredMessageGuid,
+            pendingRecoveryCount: queued,
+            lastRecoveredAt: previousState.lastRecoveredAt,
+            lastRecoveredMessageGuid: previousState.lastRecoveredMessageGuid,
         });
     }
     catch (error) {
@@ -1223,17 +1232,18 @@ async function syncBlueBubblesRuntime(deps = {}) {
             upstreamStatus: "error",
             detail: error instanceof Error ? error.message : String(error),
             lastCheckedAt: checkedAt,
-            pendingRecoveryCount: countPendingRecoveryCandidates(agentName),
+            pendingRecoveryCount: countPendingCapturedInboundMessages(agentName) + countPendingRecoveryCandidates(agentName),
         });
     }
 }
-async function catchUpMissedBlueBubblesMessages(deps = {}, previousState) {
+async function catchUpMissedBlueBubblesMessages(deps = {}, previousState, options = {}) {
     const resolvedDeps = { ...defaultDeps, ...deps };
     const agentName = resolvedDeps.getAgentName();
     const client = resolvedDeps.createClient();
     const result = { inspected: 0, recovered: 0, skipped: 0, failed: 0 };
     const state = previousState ?? (0, runtime_state_1.readBlueBubblesRuntimeState)(agentName);
     const catchUpSince = resolveBlueBubblesCatchUpSince(state);
+    const processTurns = options.processTurns !== false;
     /* v8 ignore next -- older injected test doubles may omit the catch-up query method */
     if (!client.listRecentMessages)
         return result;
@@ -1311,6 +1321,15 @@ async function catchUpMissedBlueBubblesMessages(deps = {}, previousState) {
             result.skipped++;
             continue;
         }
+        if (!processTurns) {
+            if ((0, inbound_log_1.hasRecordedBlueBubblesInbound)(agentName, event.chat.sessionKey, event.messageGuid)) {
+                result.skipped++;
+                continue;
+            }
+            (0, inbound_log_1.recordBlueBubblesInbound)(agentName, event, "upstream-catchup");
+            result.queued = (result.queued ?? 0) + 1;
+            continue;
+        }
         try {
             const repaired = await client.repairEvent(event);
             if (repaired.kind !== "message") {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ouro.bot/cli",
-  "version": "0.1.0-alpha.520",
+  "version": "0.1.0-alpha.522",
   "main": "dist/heart/daemon/ouro-entry.js",
   "bin": {
     "cli": "dist/heart/daemon/ouro-bot-entry.js",
@@ -10,6 +10,7 @@
   "files": [
     "dist/",
     "SerpentGuide.ouro/",
+    "RepairGuide.ouro/",
     "skills/",
     "assets/",
     "changelog.json"
@@ -33,7 +34,7 @@
     "test:outlook-ui": "npm test --prefix packages/outlook-ui",
     "test:coverage:vitest": "vitest run --coverage",
     "test:coverage": "node scripts/run-coverage-gate.cjs",
-    "build": "tsc && (cd packages/outlook-ui && npm install --ignore-scripts 2>/dev/null && npm run build && cp -r dist ../../dist/outlook-ui) || echo 'outlook-ui build skipped'",
+    "build": "tsc && (cd packages/outlook-ui && npm install --ignore-scripts 2>/dev/null && npm run build && cd ../.. && node scripts/copy-outlook-ui.cjs) || echo 'outlook-ui build skipped'",
     "lint": "eslint src/",
     "release:preflight": "node scripts/release-preflight.cjs",
     "release:smoke": "node scripts/release-smoke.cjs",