@1agh/maude 0.42.0 → 0.44.0

package/apps/studio/readiness.ts

@@ -14,6 +14,7 @@
 import { existsSync, readFileSync } from 'node:fs';
 import { homedir } from 'node:os';
 import { join } from 'node:path';
+import { getClaudeAuthStatus } from './acp/login-state.ts';
 import { isNativePluginContext } from './acp/plugin-bootstrap.ts';
 import { resolveAdapterEntry, resolveClaudePath } from './acp/probe.ts';
 import { resolveBrowser } from './bin/_ensure-browser.mjs';
@@ -32,6 +33,19 @@ export interface ReadinessItem {
   detail: string;
   /** Copy-paste-able fix, present only when the item is not satisfied. */
   remediation?: string;
+  /** Verbatim shell command for a dedicated code-block + Copy affordance (DDR-166 T0c) — kept separate from the prose `remediation`. */
+  installCommand?: string;
+  /** UI action hint (DDR-166): 'install' renders a "Set up AI editing" button that runs the official installer then auto-chains to sign-in; 'signin' renders a "Sign in to Claude" button alone. */
+  action?: 'install' | 'signin';
+  /**
+   * DDR-166 Decision 3 (binding — a security-review-mandated control, not
+   * cosmetic): the resolved absolute path of the binary a Sign-in click is
+   * about to spawn, shown BEFORE the button so a pre-existing PATH-hijacked
+   * `claude` isn't invisible to the one human capable of noticing it's wrong.
+   */
+  resolvedPath?: string;
+  /** True when `resolvedPath` is the binary Maude itself just installed (content-pinned — see probe.ts `setTrustedClaudeBin`), not something already on the user's PATH. */
+  resolvedViaMaude?: boolean;
 }
 
 export interface ReadinessReport {
@@ -164,37 +178,101 @@ export function scanPlugins(): PluginScan {
  * (DDR-128 hardening) so this can't be turned into a spawn-storm from a drive-by page.
  */
 export async function probeReadiness(): Promise<ReadinessReport> {
-  const [claude, maude, agentBrowser] = await Promise.all([
+  let [claude, maude, agentBrowser] = await Promise.all([
     (async () => resolveClaudePath() ?? (await resolveOnPath('claude')))(),
     resolveOnPath('maude'),
     resolveOnPath('agent-browser'),
   ]);
 
+  // Deterministic E2E stub for the two claude-readiness states that are
+  // otherwise near-impossible to reproduce on a real, already-set-up dev
+  // machine (mirrors MAUDE_E2E_FAKE_GITHUB_LOGIN in oauth.rs — same problem,
+  // same shape of fix: a real state that needs a pristine/logged-out machine
+  // to occur naturally gets a narrow, explicitly-named override instead of a
+  // hand-rolled sandbox that fights the OS's own PATH resolution). Never
+  // affects real users — unset in every normal launch.
+  const e2eForce = process.env.MAUDE_E2E_FORCE_CLAUDE_STATUS;
+  // A verified, explicitly-provisioned MAUDE_CLAUDE_BIN override (T0c's
+  // install flow, once its freshness+hash check passes) must never be
+  // clobbered back to "missing"/"signed-out" by this coarser stub — mirrors
+  // the same precedence fix in probe.ts's resolveClaudePath(). Without this,
+  // the acp-cold-start scenario could never observe its OWN install actually
+  // taking effect after starting from a forced-missing state.
+  const hasVerifiedOverride =
+    !!process.env.MAUDE_CLAUDE_BIN && claude === process.env.MAUDE_CLAUDE_BIN;
+  if (e2eForce === 'missing' && !hasVerifiedOverride) claude = null;
+  else if (e2eForce === 'signed-out' && !hasVerifiedOverride) claude = claude || '/usr/bin/claude'; // present, but auth probe below is also stubbed
+
   const items: ReadinessItem[] = [];
 
+  // DDR-166 T0d — honest 3-state instead of presence-only: not installed (an
+  // "install" action, T0c — runs the same verbatim official one-liner a user
+  // would type themselves, live-verified 2026-07-13 against
+  // code.claude.com/docs/en/quickstart.md; the copy-paste command below stays
+  // as the fallback/opt-out path) / installed-but-signed-out (a "Sign in"
+  // action, T0d) / signed-in-on-subscription.
+  const authStatus =
+    e2eForce === 'signed-out' ? { loggedIn: false } : claude ? await getClaudeAuthStatus() : null;
+  const signedIn = !!authStatus?.loggedIn;
+  const offSubscription =
+    signedIn && authStatus?.apiProvider && authStatus.apiProvider !== 'firstParty';
+  // DDR-166 Decision 5 — the settings-UI opt-out (prefs.rs `claude_auto_setup`,
+  // DEFAULT ON) reaches the dev-server as an env var set fresh at each sidecar
+  // spawn. Disabled → fall back to guide-only: no automated action offered,
+  // same posture as before T0c/T0d existed (still shows the copy-paste
+  // command below, just no button).
+  const autoSetupEnabled = process.env.MAUDE_CLAUDE_AUTOSETUP_ENABLED !== '0';
   items.push({
     id: 'claude',
     label: 'Claude Code (the `claude` CLI)',
     required: true,
-    status: claude ? 'present' : 'missing',
-    detail: claude
-      ? 'Installed — AI editing drives it on your own Pro/Max subscription.'
-      : 'Not found on PATH.',
-    remediation: claude
-      ? undefined
-      : 'Install Claude Code, then run `claude` and `/login` once. AI editing runs on your own Pro/Max subscription — never API billing.',
+    status: claude && signedIn ? 'present' : 'missing',
+    detail: !claude
+      ? 'Not found on PATH.'
+      : signedIn
+        ? offSubscription
+          ? `Signed in, but not on a Claude subscription (${authStatus?.apiProvider}) — AI editing may bill metered API usage.`
+          : `Signed in${authStatus?.subscriptionType ? ` · ${authStatus.subscriptionType}` : ''} — AI editing runs on your own Pro/Max subscription.`
+        : 'Installed, but not signed in.',
+    remediation: !claude
+      ? 'Install Claude Code, then sign in. AI editing runs on your own Pro/Max subscription — never API billing.'
+      : signedIn
+        ? undefined
+        : 'Sign in to connect it to your Pro/Max subscription.',
+    installCommand: !claude ? 'curl -fsSL https://claude.ai/install.sh | bash' : undefined,
+    action: !autoSetupEnabled ? undefined : !claude ? 'install' : !signedIn ? 'signin' : undefined,
+    resolvedPath: claude ?? undefined,
+    resolvedViaMaude: !!claude && claude === process.env.MAUDE_CLAUDE_BIN,
   });
 
-  items.push({
-    id: 'maude',
-    label: 'maude CLI',
-    required: true,
-    status: maude ? 'present' : 'missing',
-    detail: maude ? 'On PATH — `/design:edit` can reach its helpers.' : 'Not found on PATH.',
-    remediation: maude
-      ? undefined
-      : 'Install it: `npm i -g @1agh/maude`. `/design:edit` shells out to `maude design …`, so it must be on PATH.',
-  });
+  // DDR-166 T0b / DDR-168 — `maude` is bundled into the packaged app (compiled
+  // via apps/desktop/scripts/build-cli-binary.mjs, shipped as `externalBin`
+  // `binaries/maude`; sidecar.rs stages it into its own narrow, single-binary
+  // PATH directory, PREPENDS that directory ahead of the rest of PATH, and sets
+  // MAUDE_BUNDLED_CLI_PATH to that exact path). Prepending makes this
+  // deterministic, not a best-effort fallback: inside the sidecar's own spawned
+  // children the bundled copy always wins PATH resolution, so `maude === bundledCliPath`
+  // is the normal case on the desktop path, not merely one possible outcome. This
+  // row disappears entirely for the end user rather than surfacing an
+  // `npm i -g` instruction for something already shipped — it's an internal
+  // plumbing detail, not a recognizable capability like the agent-browser/
+  // adapter rows below. In dev contexts where the bundling step hasn't run
+  // (a bare `bun run server.ts`, `maude design serve`), MAUDE_BUNDLED_CLI_PATH
+  // is unset and this falls through to the pre-T0b behavior unchanged.
+  const bundledCliPath = process.env.MAUDE_BUNDLED_CLI_PATH || null;
+  const maudeIsBundled = !!bundledCliPath && maude === bundledCliPath;
+  if (!maudeIsBundled) {
+    items.push({
+      id: 'maude',
+      label: 'maude CLI',
+      required: true,
+      status: maude ? 'present' : 'missing',
+      detail: maude ? 'On PATH — `/design:edit` can reach its helpers.' : 'Not found on PATH.',
+      remediation: maude
+        ? undefined
+        : 'Install it: `npm i -g @1agh/maude`. `/design:edit` shells out to `maude design …`, so it must be on PATH.',
+    });
+  }
 
   const scan = scanPlugins();
   // DDR-143 — on the native/desktop path the ACP chat session AUTO-LOADS the
@@ -206,8 +284,18 @@ export async function probeReadiness(): Promise<ReadinessReport> {
   // `design` alone — demanding a plugin the chat doesn't use would be a false red.
   // The web `maude design serve` path ships no bundle (native=false, dir null) →
   // the manual marketplace remediation still shows there.
+  //
+  // DDR-168 — `designAutoloaded` no longer requires `!scan.design`: the bundled
+  // copy is injected unconditionally now (plugin-bootstrap.ts), regardless of
+  // whether a marketplace copy is ALSO installed at the user level (the
+  // double-registration risk that used to gate this is closed structurally in
+  // bridge.ts's `options.settings.enabledPlugins` override instead). So this row
+  // reads "auto-loaded" even on a machine that separately has design@maude
+  // installed — that's the whole point: the bundled, release-matched copy is
+  // what actually runs in the chat, so the UI should say so rather than imply
+  // "ready because you already had it."
   const native = isNativePluginContext();
-  const designAutoloaded = native && DESIGN_PLUGIN_DIR !== null && !scan.design;
+  const designAutoloaded = native && DESIGN_PLUGIN_DIR !== null;
   const designReady = scan.design || designAutoloaded;
   const pluginStatus: ReadinessStatus = designReady
     ? 'present'
@@ -221,7 +309,7 @@ export async function probeReadiness(): Promise<ReadinessReport> {
     status: pluginStatus,
     detail: designReady
       ? designAutoloaded
-        ? 'Auto-loaded in the Maude chat session — nothing to install.'
+        ? 'Bundled with this app — loads automatically in the chat session.'
         : 'design@maude is installed.'
       : scan.status === 'unknown'
         ? "Couldn't read Claude Code's plugin registry — check it manually."

package/apps/studio/runtime-bundle.ts

@@ -47,12 +47,26 @@ export const RUNTIME_PACKAGES = [
   'react-dom/client',
   'react/jsx-runtime',
   'react/jsx-dev-runtime',
-  // Phase 4 — Pixi.js v8 available as a per-iframe runtime bundle. Lazy-built
-  // on first request; canvases that don't `import 'pixi.js'` never pay the
-  // ~500 KB bundle cost. Reserved for future snapshot-to-texture rendering
-  // (DDR-024 deferred path) and any high-end designer-tool overlays a canvas
-  // wants to draw via WebGL.
+  // Pixi.js v8 — per-iframe runtime bundle for the non-destructive photo editor
+  // (feature-photo-editor). The canvas-lib `<PhotoLayer>` reaches the WebGL
+  // compositor (`photo/pipeline.ts`) through a LAZY runtime `import('pixi.js')`,
+  // so a canvas with no edited photo never pays the ~500 KB bundle cost (the
+  // lazy-bundle guarantee — regression-tested in test/photo-canvas-bundle.test.ts).
+  // Pre-built into dist/runtime/pixi-js.js + floored in .min-sizes.json.
+  // (Originally parked by DDR-024 for snapshot-to-texture rendering; the photo
+  // editor is the first real activation — see the photo-editor architecture DDR.)
   'pixi.js',
+  // @imgly/background-removal (feature-photo-editor) — client-side ML background
+  // removal (WASM/WebGPU via onnxruntime-web, ZERO native deps; the Node/native
+  // `-node` variant is NEVER imported — bun-compile-hostile, DDR-070 sharp-class
+  // exclusion). Externalised for the same lazy per-iframe bundling as pixi: the
+  // bg-remove harness (PhotoBgRemoveHarness) reaches it through a runtime
+  // `import('@imgly/background-removal')`, so a canvas that never removes a
+  // background pays zero cost. Model weights (~11–44 MB isnet) are fetched at
+  // first use (IMG.LY CDN by default; `publicPath` self-hosts for air-gapped —
+  // a documented follow-up, see the photo-editor DDR). Pre-built into
+  // dist/runtime + floored in .min-sizes.json.
+  '@imgly/background-removal',
   // Phase 3.7 / DDR-049 — Motion One (motion/react) is the canonical motion
   // library for the canvas-lib + handoff pipeline. Externalised here so the
   // canvas-lib motion helpers (<MotionDemo>, etc.) resolve through the same
@@ -220,7 +234,16 @@ export async function getRuntimeBundle(
   // The `as any` cast tolerates names like `__INTERNAL_DO_NOT_USE_OR_WARN`
   // that aren't declared in the package's .d.ts; the destructure still
   // succeeds at runtime, which is what matters.
-  const entryContent = `import * as __mod__ from ${JSON.stringify(pkg)};\n${
+  // pixi.js compiles shaders with `new Function()` — which the split-origin
+  // canvas iframe's strict CSP (DDR-054) forbids (no `unsafe-eval`), so the
+  // photo compositor threw "Current environment does not allow unsafe-eval" and
+  // the live preview silently failed in the DEFAULT mode (only same-origin, the
+  // opt-out, had no CSP to trip). pixi ships `pixi.js/unsafe-eval` — a
+  // side-effect module that swaps the eval-based shader/uniform sync for
+  // eval-free polyfills. Baking it into the runtime bundle here makes EVERY
+  // canvas's `import('pixi.js')` CSP-safe transparently (feature-photo-editor).
+  const sideEffects = pkg === 'pixi.js' ? `import "pixi.js/unsafe-eval";\n` : '';
+  const entryContent = `${sideEffects}import * as __mod__ from ${JSON.stringify(pkg)};\n${
     exportNames.length > 0
       ? `const {\n${namedLines}\n} = __mod__ as any;\n` + `export {\n${namedLines}\n};\n`
       : ''