gooseworks 0.3.10 → 0.3.12

package/README.md

@@ -93,6 +93,31 @@ npx gooseworks logout
 
 Deletes `~/.gooseworks/credentials.json`.
 
+### `whoami`
+
+Show which account you're currently signed in as. Handy when you have multiple
+GooseWorks accounts and need to confirm the active one before running a command.
+Reads local credentials only — no network call.
+
+```bash
+npx gooseworks whoami
+npx gooseworks whoami --json    # machine-readable output
+```
+
+Output:
+```
+Signed in as you@example.com
+Scope:      user
+Agent:      2e32bd49-…
+API base:   https://api.gooseworks.ai
+```
+
+To switch accounts, run `gooseworks logout` then `gooseworks login`.
+
+> The GooseWorks MCP server exposes the same identity check as the `whoami` tool
+> (email + the exact agent/org the token is pinned to), separate from
+> `list_accessible_scopes`, which lists *every* workspace you can reach.
+
 ### `search`
 
 Search the GooseWorks skill catalog.

package/dist/commands/whoami.d.ts

@@ -0,0 +1,11 @@
+import { Command } from 'commander';
+/**
+ * `gooseworks whoami` — show which account the CLI is currently signed in as.
+ *
+ * Reads `~/.gooseworks/credentials.json` only (no network call), so it works
+ * offline and reflects exactly what the CLI + its MCP registration will
+ * authenticate as. This is the answer to "I have multiple accounts — which one
+ * is active right now?"; use `gooseworks login` / `logout` to switch.
+ */
+export declare const whoamiCommand: Command;
+//# sourceMappingURL=whoami.d.ts.map

package/dist/commands/whoami.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"whoami.d.ts","sourceRoot":"","sources":["../../src/commands/whoami.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAIpC;;;;;;;GAOG;AACH,eAAO,MAAM,aAAa,SA0CtB,CAAC"}

package/dist/commands/whoami.js

@@ -0,0 +1,84 @@
+"use strict";
+var __createBinding = (this && this.__createBinding) || (Object.create ? (function(o, m, k, k2) {
+    if (k2 === undefined) k2 = k;
+    var desc = Object.getOwnPropertyDescriptor(m, k);
+    if (!desc || ("get" in desc ? !m.__esModule : desc.writable || desc.configurable)) {
+      desc = { enumerable: true, get: function() { return m[k]; } };
+    }
+    Object.defineProperty(o, k2, desc);
+}) : (function(o, m, k, k2) {
+    if (k2 === undefined) k2 = k;
+    o[k2] = m[k];
+}));
+var __setModuleDefault = (this && this.__setModuleDefault) || (Object.create ? (function(o, v) {
+    Object.defineProperty(o, "default", { enumerable: true, value: v });
+}) : function(o, v) {
+    o["default"] = v;
+});
+var __importStar = (this && this.__importStar) || (function () {
+    var ownKeys = function(o) {
+        ownKeys = Object.getOwnPropertyNames || function (o) {
+            var ar = [];
+            for (var k in o) if (Object.prototype.hasOwnProperty.call(o, k)) ar[ar.length] = k;
+            return ar;
+        };
+        return ownKeys(o);
+    };
+    return function (mod) {
+        if (mod && mod.__esModule) return mod;
+        var result = {};
+        if (mod != null) for (var k = ownKeys(mod), i = 0; i < k.length; i++) if (k[i] !== "default") __createBinding(result, mod, k[i]);
+        __setModuleDefault(result, mod);
+        return result;
+    };
+})();
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.whoamiCommand = void 0;
+const commander_1 = require("commander");
+const credentials_1 = require("../auth/credentials");
+const logger = __importStar(require("../utils/logger"));
+/**
+ * `gooseworks whoami` — show which account the CLI is currently signed in as.
+ *
+ * Reads `~/.gooseworks/credentials.json` only (no network call), so it works
+ * offline and reflects exactly what the CLI + its MCP registration will
+ * authenticate as. This is the answer to "I have multiple accounts — which one
+ * is active right now?"; use `gooseworks login` / `logout` to switch.
+ */
+exports.whoamiCommand = new commander_1.Command('whoami')
+    .description('Show which GooseWorks account you are signed in as')
+    .option('--json', 'Output raw JSON')
+    .action((opts) => {
+    const creds = (0, credentials_1.getCredentials)();
+    if (!creds) {
+        if (opts.json) {
+            console.log(JSON.stringify({ logged_in: false }, null, 2));
+        }
+        else {
+            logger.error('Not logged in. Run "gooseworks login" first.');
+        }
+        process.exit(1);
+    }
+    const scope = creds.scope_type ?? 'agent';
+    if (opts.json) {
+        console.log(JSON.stringify({
+            logged_in: true,
+            email: creds.email,
+            scope_type: scope,
+            agent_id: creds.agent_id,
+            default_agent_id: creds.default_agent_id ?? creds.agent_id,
+            api_base: creds.api_base,
+            mcp_server_url: creds.mcp_server_url ?? null,
+        }, null, 2));
+        return;
+    }
+    logger.success(`Signed in as ${creds.email}`);
+    logger.info(`Scope:      ${scope}`);
+    logger.info(`Agent:      ${creds.agent_id}`);
+    logger.info(`API base:   ${creds.api_base}`);
+    if (creds.mcp_server_url) {
+        logger.info(`MCP server: ${creds.mcp_server_url}`);
+    }
+    logger.info('Run "gooseworks logout" then "gooseworks login" to switch accounts.');
+});
+//# sourceMappingURL=whoami.js.map

package/dist/commands/whoami.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"whoami.js","sourceRoot":"","sources":["../../src/commands/whoami.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAAA,yCAAoC;AACpC,qDAAqD;AACrD,wDAA0C;AAE1C;;;;;;;GAOG;AACU,QAAA,aAAa,GAAG,IAAI,mBAAO,CAAC,QAAQ,CAAC;KAC/C,WAAW,CAAC,oDAAoD,CAAC;KACjE,MAAM,CAAC,QAAQ,EAAE,iBAAiB,CAAC;KACnC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE;IACf,MAAM,KAAK,GAAG,IAAA,4BAAc,GAAE,CAAC;IAC/B,IAAI,CAAC,KAAK,EAAE,CAAC;QACX,IAAI,IAAI,CAAC,IAAI,EAAE,CAAC;YACd,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,EAAE,SAAS,EAAE,KAAK,EAAE,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,CAAC;QAC7D,CAAC;aAAM,CAAC;YACN,MAAM,CAAC,KAAK,CAAC,8CAA8C,CAAC,CAAC;QAC/D,CAAC;QACD,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IAClB,CAAC;IAED,MAAM,KAAK,GAAG,KAAK,CAAC,UAAU,IAAI,OAAO,CAAC;IAC1C,IAAI,IAAI,CAAC,IAAI,EAAE,CAAC;QACd,OAAO,CAAC,GAAG,CACT,IAAI,CAAC,SAAS,CACZ;YACE,SAAS,EAAE,IAAI;YACf,KAAK,EAAE,KAAK,CAAC,KAAK;YAClB,UAAU,EAAE,KAAK;YACjB,QAAQ,EAAE,KAAK,CAAC,QAAQ;YACxB,gBAAgB,EAAE,KAAK,CAAC,gBAAgB,IAAI,KAAK,CAAC,QAAQ;YAC1D,QAAQ,EAAE,KAAK,CAAC,QAAQ;YACxB,cAAc,EAAE,KAAK,CAAC,cAAc,IAAI,IAAI;SAC7C,EACD,IAAI,EACJ,CAAC,CACF,CACF,CAAC;QACF,OAAO;IACT,CAAC;IAED,MAAM,CAAC,OAAO,CAAC,gBAAgB,KAAK,CAAC,KAAK,EAAE,CAAC,CAAC;IAC9C,MAAM,CAAC,IAAI,CAAC,eAAe,KAAK,EAAE,CAAC,CAAC;IACpC,MAAM,CAAC,IAAI,CAAC,eAAe,KAAK,CAAC,QAAQ,EAAE,CAAC,CAAC;IAC7C,MAAM,CAAC,IAAI,CAAC,eAAe,KAAK,CAAC,QAAQ,EAAE,CAAC,CAAC;IAC7C,IAAI,KAAK,CAAC,cAAc,EAAE,CAAC;QACzB,MAAM,CAAC,IAAI,CAAC,eAAe,KAAK,CAAC,cAAc,EAAE,CAAC,CAAC;IACrD,CAAC;IACD,MAAM,CAAC,IAAI,CAAC,qEAAqE,CAAC,CAAC;AACrF,CAAC,CAAC,CAAC"}

package/dist/index.js

@@ -5,6 +5,7 @@ const commander_1 = require("commander");
 const install_1 = require("./commands/install");
 const login_1 = require("./commands/login");
 const logout_1 = require("./commands/logout");
+const whoami_1 = require("./commands/whoami");
 const update_1 = require("./commands/update");
 const credits_1 = require("./commands/credits");
 const search_1 = require("./commands/search");
@@ -24,6 +25,7 @@ program
 program.addCommand(install_1.installCommand);
 program.addCommand(login_1.loginCommand);
 program.addCommand(logout_1.logoutCommand);
+program.addCommand(whoami_1.whoamiCommand);
 program.addCommand(update_1.updateCommand);
 program.addCommand(credits_1.creditsCommand);
 program.addCommand(search_1.searchCommand);

package/dist/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";;;AACA,yCAAoC;AACpC,gDAAoD;AACpD,4CAAgD;AAChD,8CAAkD;AAClD,8CAAkD;AAClD,gDAAoD;AACpD,8CAAkD;AAClD,4CAAgD;AAChD,wCAA4C;AAC5C,0CAA8C;AAC9C,sDAA0D;AAC1D,8CAAkD;AAClD,gDAAoD;AACpD,8CAAkD;AAClD,uCAAuC;AAEvC,MAAM,OAAO,GAAG,IAAI,mBAAO,EAAE,CAAC;AAC9B,OAAO;KACJ,IAAI,CAAC,YAAY,CAAC;KAClB,WAAW,CAAC,yDAAyD,CAAC;KACtE,OAAO,CAAC,IAAA,oBAAU,GAAE,CAAC,CAAC;AAEzB,OAAO,CAAC,UAAU,CAAC,wBAAc,CAAC,CAAC;AACnC,OAAO,CAAC,UAAU,CAAC,oBAAY,CAAC,CAAC;AACjC,OAAO,CAAC,UAAU,CAAC,sBAAa,CAAC,CAAC;AAClC,OAAO,CAAC,UAAU,CAAC,sBAAa,CAAC,CAAC;AAClC,OAAO,CAAC,UAAU,CAAC,wBAAc,CAAC,CAAC;AACnC,OAAO,CAAC,UAAU,CAAC,sBAAa,CAAC,CAAC;AAClC,OAAO,CAAC,UAAU,CAAC,oBAAY,CAAC,CAAC;AACjC,OAAO,CAAC,UAAU,CAAC,gBAAU,CAAC,CAAC;AAC/B,OAAO,CAAC,UAAU,CAAC,kBAAW,CAAC,CAAC;AAChC,OAAO,CAAC,UAAU,CAAC,8BAAiB,CAAC,CAAC;AACtC,OAAO,CAAC,UAAU,CAAC,sBAAa,CAAC,CAAC;AAClC,OAAO,CAAC,UAAU,CAAC,wBAAc,CAAC,CAAC;AACnC,OAAO,CAAC,UAAU,CAAC,sBAAa,CAAC,CAAC;AAElC,OAAO,CAAC,KAAK,EAAE,CAAC"}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";;;AACA,yCAAoC;AACpC,gDAAoD;AACpD,4CAAgD;AAChD,8CAAkD;AAClD,8CAAkD;AAClD,8CAAkD;AAClD,gDAAoD;AACpD,8CAAkD;AAClD,4CAAgD;AAChD,wCAA4C;AAC5C,0CAA8C;AAC9C,sDAA0D;AAC1D,8CAAkD;AAClD,gDAAoD;AACpD,8CAAkD;AAClD,uCAAuC;AAEvC,MAAM,OAAO,GAAG,IAAI,mBAAO,EAAE,CAAC;AAC9B,OAAO;KACJ,IAAI,CAAC,YAAY,CAAC;KAClB,WAAW,CAAC,yDAAyD,CAAC;KACtE,OAAO,CAAC,IAAA,oBAAU,GAAE,CAAC,CAAC;AAEzB,OAAO,CAAC,UAAU,CAAC,wBAAc,CAAC,CAAC;AACnC,OAAO,CAAC,UAAU,CAAC,oBAAY,CAAC,CAAC;AACjC,OAAO,CAAC,UAAU,CAAC,sBAAa,CAAC,CAAC;AAClC,OAAO,CAAC,UAAU,CAAC,sBAAa,CAAC,CAAC;AAClC,OAAO,CAAC,UAAU,CAAC,sBAAa,CAAC,CAAC;AAClC,OAAO,CAAC,UAAU,CAAC,wBAAc,CAAC,CAAC;AACnC,OAAO,CAAC,UAAU,CAAC,sBAAa,CAAC,CAAC;AAClC,OAAO,CAAC,UAAU,CAAC,oBAAY,CAAC,CAAC;AACjC,OAAO,CAAC,UAAU,CAAC,gBAAU,CAAC,CAAC;AAC/B,OAAO,CAAC,UAAU,CAAC,kBAAW,CAAC,CAAC;AAChC,OAAO,CAAC,UAAU,CAAC,8BAAiB,CAAC,CAAC;AACtC,OAAO,CAAC,UAAU,CAAC,sBAAa,CAAC,CAAC;AAClC,OAAO,CAAC,UAAU,CAAC,wBAAc,CAAC,CAAC;AACnC,OAAO,CAAC,UAAU,CAAC,sBAAa,CAAC,CAAC;AAElC,OAAO,CAAC,KAAK,EAAE,CAAC"}

package/dist/skills/master-skill.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"master-skill.d.ts","sourceRoot":"","sources":["../../src/skills/master-skill.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,MAAM,WAAW,UAAU;IACzB,qEAAqE;IACrE,IAAI,EAAE,MAAM,CAAC;IACb,OAAO,EAAE,MAAM,CAAC;CACjB;AAED,oDAAoD;AACpD,wBAAgB,cAAc,IAAI,UAAU,EAAE,CAM7C;AAED;;;;;;;;GAQG;AACH,wBAAgB,qBAAqB,IAAI,MAAM,CA0L9C;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,uBAAuB,IAAI,MAAM,CAsUhD;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,yBAAyB,IAAI,MAAM,CAsSlD"}
+{"version":3,"file":"master-skill.d.ts","sourceRoot":"","sources":["../../src/skills/master-skill.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,MAAM,WAAW,UAAU;IACzB,qEAAqE;IACrE,IAAI,EAAE,MAAM,CAAC;IACb,OAAO,EAAE,MAAM,CAAC;CACjB;AAED,oDAAoD;AACpD,wBAAgB,cAAc,IAAI,UAAU,EAAE,CAM7C;AAED;;;;;;;;GAQG;AACH,wBAAgB,qBAAqB,IAAI,MAAM,CA0L9C;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,uBAAuB,IAAI,MAAM,CAsUhD;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,yBAAyB,IAAI,MAAM,CA8WlD"}

package/dist/skills/master-skill.js

@@ -583,8 +583,17 @@ tags: [gooseworks, ads, video, remix, imessage, local-render, byoa]
 
 You produce **video** ad creative on the user's OWN machine and sync the result back to the
 GooseWorks app over MCP. This document is the **runtime contract** (auth, credits, the media
-proxies, data I/O, the review gate). A separate **recipe skill** — fetched per format — tells
-you *what to make*; read both, and this doc wins on any conflict about the environment.
+proxies, data I/O, the review gate). A separate **recipe skill** — fetched per format — tells you
+*what to make* (the pieces, prompts, models, order of assembly).
+
+**Division of authority — read both, but when they disagree THIS doc wins on the environment AND the
+review/approval flow.** The recipe governs WHAT to make; this doc governs WHEN you pause, generate,
+and spend. In particular: a recipe may spell out a **multi-phase, multi-gate** flow — "generate the
+still [GATE] → approve → author the prompt [GATE] → approve → render [GATE] → approve", several
+separate pauses. **Do NOT run it that way.** Collapse every one of those gates into the single
+**review-once** flow below: one review set, one approval (Step 3). Take the recipe's pieces, prompts
+and models; ignore its intermediate pauses. This is the exact contradiction that confused past runs
+(GOOSE-2542) — there is no ambiguity: review-once wins.
 
 You run inside the user's own Claude Code session (they pasted an instruction with a project
 id). The app NEVER runs you — it is the viewer + review surface; you are the renderer.
@@ -653,14 +662,18 @@ says to shell out, use the MCP equivalent:
   stays the project-relative \`...render-file?path=working/final.mp4\` — the route re-prepends the
   prefix itself. Always verify with \`get_download_url\` on the FULL \`agent-config/...\` path (must
   be non-empty; curl it for HTTP 200) BEFORE marking the render complete.
-- Media generation (FAL / ElevenLabs) is billed to the agent through the GooseWorks proxies.
-  \`submit_render { kind: "full" }\` debits **1 ad credit at row creation** — so sequence it LAST
-  (render + verify a good MP4 first), and never re-submit on a guess (that double-bills). Call
-  \`get_ad_credits\` first; the user can check \`gooseworks credits\`.
+- Media generation (FAL / ElevenLabs) through the GooseWorks proxies is the **REAL spend** — billed
+  to the agent per call as you generate (Step 4). \`submit_render { kind: "full" }\` additionally
+  debits **1 nominal ad credit when the render ROW is opened** (a bookkeeping fee, NOT the render's
+  true cost) — so open it only once you actually have a rendered master (Step 4.1/4.2), and never
+  re-submit on a guess (that double-bills). The final-video QC gate (Step 4.3) then sits between
+  that master and PINNING it. Call \`get_ad_credits\` first; the user can check \`gooseworks credits\`.
 
 ## Step 1 — resolve the project, source, brand
 
-1. \`get_ad_project { project_id }\` → keep \`brand_id\`, \`source_sample_id\`, \`name\`, \`status\`.
+1. \`get_ad_project { project_id }\` → keep \`brand_id\`, \`source_sample_id\`, \`name\`, \`status\`, and
+   the **top-level** \`app_url\` + \`brand_url\` (returned alongside \`project\`, NOT inside it) — these
+   are the links you hand the user for the in-app review (Step 3) and the final delivery (Step 5).
 2. \`get_ad_template { template_id: source_sample_id }\` → the source video: \`media_url\`,
    \`recipe\`, \`format\` (e.g. "imessage"), \`extracted_script\`, \`how_to\`, \`remix_spec\`.
 3. Brand gate: \`get_brand_kit { brand_id }\`. If \`researchStatus\` is \`complete\`, REUSE it —
@@ -696,22 +709,55 @@ Playwright resolve, and point the recorder's \`NODE_PATH\` at it.
 > recipe does not yet carry \`atoms\` / \`instructions\` still hold the legacy \`recipe.thread\` payload;
 > migrate them to this shape (capabilities + instructions in the DB) — do not reintroduce a CLI map.
 
-## Step 3 — prepare ALL the ingredients, then review ONCE (always, before any paid render)
-
-This is a **review-once** flow: prepare every ingredient the video needs, show the whole set to
-the user in the app, get ONE approval, then render. Never render before approval, and don't drip
-ingredients out one at a time.
-
-1. **Generate every ingredient the format needs — not just the script.** For an iMessage video
-   that's typically: the **script** (the bubble thread), the **image(s)** shown in the conversation
-   (one or more), and the **end card**. Richer templates add more (hook frame, background, product
-   shots, music bed…). Read the recipe for the exact ingredient list. Generate the visuals NOW
-   (media proxies / recipe), and \`get_upload_url\` each preview asset to the project folder
-   \`agent-config/brands/<brand_slug>/projects/<project_id>/working/review/<name>\` (the same
-   path-prefix rule as final publish — a bare \`working/review/<name>\` won't render in the panel).
-   In \`script_drafts\`, set each ingredient's \`path\` to the project-relative \`working/review/<name>\`.
-   You may ask the user a couple of clarifying questions about the generation first if the recipe
-   calls for it (angle, which product, offer/code) — batch them, then prepare everything.
+## Step 3 — assemble the review set, then get ONE approval in the app (before the expensive render)
+
+This is a **review-once** flow: put the whole review set in the app, get ONE approval, then run the
+expensive render + any remaining paid work end-to-end. Never spend on the expensive render before
+approval, and don't drip pieces out one at a time and re-pause.
+
+**What goes in the review — show the REAL cheap pieces, PROMPT only the expensive render.** Split
+every piece three ways by cost, NOT just "free vs paid":
+- **FREE** (an iMessage / Apple-Notes HTML mockup, a text/CTA line — rendered locally, no proxy
+  call) → generate NOW and mirror the real asset.
+- **CHEAP paid** — a single still/image, the creator/avatar frame, the end card, a short voiceover
+  or music bed (each costs cents → roughly **≤ 100 credits**) → **generate these NOW too** and
+  mirror the real asset. The few credits buy a real review: the user SEES the actual creator face
+  and end card and HEARS the VO, instead of judging a prompt. **This OVERRIDES any recipe rule that
+  says to gate ALL paid calls** — only the expensive render below is gated.
+- **EXPENSIVE paid** — the video take / final AI render (hundreds of credits) → do NOT generate.
+  Put its **exact prompt/spec** (+ ref image URLs) in the tile. This is the ONE thing approved as a
+  prompt (you can't preview a hundreds-of-credits video for free); it's generated only in Step 4.
+
+**The expensive render's exact prompt must be in the panel BEFORE you ask for approval** — so a
+single "go" runs it (plus any remaining paid work) without re-pausing mid-run.
+
+**Show every cost in CREDITS, never dollars.** 1 credit = $0.01 and media generations bill at
+provider-cost × 1.2, so **credits ≈ round-up(provider-$ × 120)** per generation, plus a flat
+**200-credit base per video**. Convert any $ figures to credits and show ONLY credits to the user —
+never print a "$…" amount.
+
+**Never assemble/stitch the finished video for review.** The review is of the individual pieces (or
+their prompts) — never a "full cascade" / "approved cut" clip. Building the whole video before
+approval defeats the gate (the user opens the review to an already-finished video) and wastes the
+render (GOOSE-2542). The full video is assembled ONLY in Step 4, after approval. A \`video\`
+ingredient here is only a genuinely separate SOURCE clip the format needs (e.g. supplied b-roll).
+
+1. **Assemble every piece the format needs — not just the script.** Read the recipe for the exact
+   list. For an iMessage video that's the **script** (bubble thread), the **conversation image(s)**,
+   and the **end card**; richer templates add a hook frame, background, product shots, music bed, a
+   creator/avatar, a voiceover… For each piece, decide FREE / CHEAP-paid / EXPENSIVE-paid (above):
+   - **FREE or CHEAP paid** (≤ ~100 credits — HTML mockups, a still, the creator frame, the end
+     card, a short VO/music bed) → generate it now and \`get_upload_url\` the asset to the project
+     folder \`agent-config/brands/<brand_slug>/projects/<project_id>/working/review/<name>\` (same
+     path-prefix rule as final publish — a bare \`working/review/<name>\` won't render in the panel);
+     set that piece's \`path\` in \`script_drafts\` to the project-relative \`working/review/<name>\`.
+   - **EXPENSIVE paid** (the video take / final render, hundreds of credits) → do NOT generate. Put
+     the **exact prompt/spec** (and any ref image URLs) in the tile's \`text\` / \`subtitle\` so the
+     user reviews what will be spent on. No \`path\` yet — it's generated in Step 4.
+   Include the **estimated cost in CREDITS** (never dollars) of the cheap pieces already generated +
+   the pending render, so the user approves knowing the total spend. You may batch a couple of
+   clarifying questions first if the recipe calls for it (angle, which product, offer/code), then
+   assemble everything.
 2. **Mirror the whole ingredient set for review** — \`update_ad_project_script { project_id,
    script_drafts, script }\`. \`script_drafts\` is a structured payload of **container-tagged
    ingredients** so the app renders each piece the right way:
@@ -726,21 +772,34 @@ ingredients out one at a time.
      for the podcast shape, or pass the readable \`script\` string).
    \`path\` = \`working/review/<name>\` (upload the preview asset first via \`get_upload_url\`); \`url\`
    works too. **Label every ingredient** ("Hook image", "End card", "Voiceover", "Background
-   music", "HER"). This writes NO render and costs NO credits — it populates the review panel.
-3. **STOP and ask the user to approve the ingredients in THIS Claude Code session.** Do not render
-   until they say go. If they want changes, regenerate the affected ingredient, call
-   \`update_ad_project_script\` again, and re-ask. Only AFTER approval do Step 4.
+   music", "HER"). The \`update_ad_project_script\` call itself writes no render and costs no credits
+   (the cheap pieces you already generated above have their own small cost) — it just populates the
+   review panel.
+3. **STOP — the review happens in the APP's review panel, NOT in this chat.** You've mirrored the
+   ingredients (3.2); now hand the user the project's \`app_url\` (from \`get_ad_project\`) and tell
+   them to review the pieces there and hit **"Approve & render"**. That button gives them a short
+   message to paste back into this session — THAT is your go-ahead. Do NOT paste the
+   script/ingredients into the chat for a thumbs-up, and do NOT render until that approval comes
+   back from the app. If they want changes (via the app's comments or here), regenerate the
+   affected ingredient, call \`update_ad_project_script\` again, tell them it's refreshed in the
+   app, and wait for a fresh approval. Only AFTER the app approval do Step 4. A single approval
+   authorises the WHOLE remaining chain — generate every paid piece, render, self-QC, publish —
+   with NO further pauses (that is exactly why every paid prompt must already be in the panel).
 
 ## Step 4 — render locally, report stages, publish
 
-1. Render per the recipe (Playwright record → ffmpeg stitch → \`mix-master\` audio). Generate any
-   hook / background / end-card assets through the media proxies (below).
+1. Now generate every PAID piece you showed as a prompt in Step 3 — the AI stills/video, voice,
+   music, the end-card render — through the media proxies (below), each from its approved prompt.
+   Then assemble per the recipe (Playwright record where needed → ffmpeg stitch → \`mix-master\`
+   audio).
 2. Open the row LAST: \`submit_render { project_id, kind: "full" }\` → keep \`render_id\`, then
    \`update_render_status { render_id, status: "running" }\`. The render row tracks status only
    (queued / running / complete / failed) — narrate fine-grained progress with
    \`append_project_message\` instead.
-3. **MANDATORY final-video review gate — review EVERY finished master before \`set_final_render\`,
-   whatever the format (UGC or not).** The render credit is already spent (\`submit_render\` in 4.2);
+3. **MANDATORY final-video QC gate — YOU review EVERY finished master before \`set_final_render\`,
+   whatever the format (UGC or not).** This is your own automated quality check, separate from the
+   user's Step-3 approval — it does not go back to the user. The render row is already open (its
+   nominal credit spent, \`submit_render\` in 4.2);
    this gate stands between a rendered master and PINNING/publishing it, so a bad render never gets
    set as final. A master that looks fine on a still can still have a mis-voiced word, a caption
    drifting off its line, a beat out of order, or a deformation — review the actual VIDEO, not
@@ -844,10 +903,23 @@ path. (\`fal-storage-proxy\` may 404 depending on the install; don't block on it
 
 - **MCP + ffmpeg + Playwright required** — run \`gooseworks doctor\` in Phase 0; stop with the
   exact fix it prints if anything is ✗.
-- **Prepare ALL ingredients first** (script + every visual: image(s) + end card + whatever else
-  the template needs), mirror the whole set with \`update_ad_project_script\`, and get the user's
-  approval in-session BEFORE rendering — always (review-once).
-- **submit_render LAST**; \`output_url\` = the durable render-file URL, never a CDN URL.
+- **Assemble the whole review set first**, mirror it with \`update_ad_project_script\`, and get the
+  user's approval **in the app's review panel** (the "Approve & render" button) BEFORE the expensive
+  render — never ask for a thumbs-up in this chat (review-once, in-app).
+- **Show the REAL cheap pieces; PROMPT only the expensive render.** Generate the FREE + CHEAP-paid
+  pieces (≤ ~100 credits — stills, creator frame, end card, short VO/music) and mirror the real
+  assets; put ONLY the expensive video take/render in the panel as its exact prompt. That prompt
+  must be in the panel before you ask to approve, so a single "go" runs the render + any remaining
+  paid work (→ QC → publish) with no re-pausing.
+- **Costs in CREDITS, never dollars.** credits ≈ round-up(provider-$ × 120) per generation + a flat
+  200-credit base per video; never show a "$…" figure to the user.
+- **Never assemble the full video before approval.** The review shows the
+  individual PIECES, never the finished cut (or their prompts) — not a
+  stitched/composited cut; do not add a "full cascade" / finished-video clip
+  as a review ingredient (GOOSE-2542). The assembled video is produced only in
+  Step 4.
+- **submit_render only after the master is rendered** (Step 4.2), never on a guess; \`output_url\` =
+  the durable render-file URL, never a CDN URL.
 - **Always pass \`project_id\` on media-proxy calls** (fal / ElevenLabs) so the credits attribute
   to this ad project — that's what lets the user see per-project spend in the app.
 - **Verify a real, non-empty MP4** (watch it) before marking the render complete.

package/dist/skills/master-skill.js.map

@@ -1 +1 @@
-{"version":3,"file":"master-skill.js","sourceRoot":"","sources":["../../src/skills/master-skill.ts"],"names":[],"mappings":";;AA4BA,wCAMC;AAWD,sDA0LC;AAiBD,0DAsUC;AAcD,8DAsSC;AAv1BD,oDAAoD;AACpD,SAAgB,cAAc;IAC5B,OAAO;QACL,EAAE,IAAI,EAAE,YAAY,EAAE,OAAO,EAAE,qBAAqB,EAAE,EAAE;QACxD,EAAE,IAAI,EAAE,WAAW,EAAE,OAAO,EAAE,uBAAuB,EAAE,EAAE;QACzD,EAAE,IAAI,EAAE,aAAa,EAAE,OAAO,EAAE,yBAAyB,EAAE,EAAE;KAC9D,CAAC;AACJ,CAAC;AAED;;;;;;;;GAQG;AACH,SAAgB,qBAAqB;IACnC,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAwLR,CAAC;AACF,CAAC;AAED;;;;;;;;;;;;;;GAcG;AACH,SAAgB,uBAAuB;IACrC,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAoUR,CAAC;AACF,CAAC;AAED;;;;;;;;;;;GAWG;AACH,SAAgB,yBAAyB;IACvC,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAoSR,CAAC;AACF,CAAC"}
+{"version":3,"file":"master-skill.js","sourceRoot":"","sources":["../../src/skills/master-skill.ts"],"names":[],"mappings":";;AA4BA,wCAMC;AAWD,sDA0LC;AAiBD,0DAsUC;AAcD,8DA8WC;AA/5BD,oDAAoD;AACpD,SAAgB,cAAc;IAC5B,OAAO;QACL,EAAE,IAAI,EAAE,YAAY,EAAE,OAAO,EAAE,qBAAqB,EAAE,EAAE;QACxD,EAAE,IAAI,EAAE,WAAW,EAAE,OAAO,EAAE,uBAAuB,EAAE,EAAE;QACzD,EAAE,IAAI,EAAE,aAAa,EAAE,OAAO,EAAE,yBAAyB,EAAE,EAAE;KAC9D,CAAC;AACJ,CAAC;AAED;;;;;;;;GAQG;AACH,SAAgB,qBAAqB;IACnC,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAwLR,CAAC;AACF,CAAC;AAED;;;;;;;;;;;;;;GAcG;AACH,SAAgB,uBAAuB;IACrC,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAoUR,CAAC;AACF,CAAC;AAED;;;;;;;;;;;GAWG;AACH,SAAgB,yBAAyB;IACvC,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA4WR,CAAC;AACF,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gooseworks",
-  "version": "0.3.10",
+  "version": "0.3.12",
   "description": "GooseWorks CLI — give your coding agent real data tools",
   "bin": {
     "gooseworks": "./dist/index.js"

package/skills/goose-video/SKILL.md

@@ -18,8 +18,17 @@ tags: [gooseworks, ads, video, remix, imessage, local-render, byoa]
 
 You produce **video** ad creative on the user's OWN machine and sync the result back to the
 GooseWorks app over MCP. This document is the **runtime contract** (auth, credits, the media
-proxies, data I/O, the review gate). A separate **recipe skill** — fetched per format — tells
-you *what to make*; read both, and this doc wins on any conflict about the environment.
+proxies, data I/O, the review gate). A separate **recipe skill** — fetched per format — tells you
+*what to make* (the pieces, prompts, models, order of assembly).
+
+**Division of authority — read both, but when they disagree THIS doc wins on the environment AND the
+review/approval flow.** The recipe governs WHAT to make; this doc governs WHEN you pause, generate,
+and spend. In particular: a recipe may spell out a **multi-phase, multi-gate** flow — "generate the
+still [GATE] → approve → author the prompt [GATE] → approve → render [GATE] → approve", several
+separate pauses. **Do NOT run it that way.** Collapse every one of those gates into the single
+**review-once** flow below: one review set, one approval (Step 3). Take the recipe's pieces, prompts
+and models; ignore its intermediate pauses. This is the exact contradiction that confused past runs
+(GOOSE-2542) — there is no ambiguity: review-once wins.
 
 You run inside the user's own Claude Code session (they pasted an instruction with a project
 id). The app NEVER runs you — it is the viewer + review surface; you are the renderer.
@@ -88,14 +97,18 @@ says to shell out, use the MCP equivalent:
   stays the project-relative `...render-file?path=working/final.mp4` — the route re-prepends the
   prefix itself. Always verify with `get_download_url` on the FULL `agent-config/...` path (must
   be non-empty; curl it for HTTP 200) BEFORE marking the render complete.
-- Media generation (FAL / ElevenLabs) is billed to the agent through the GooseWorks proxies.
-  `submit_render { kind: "full" }` debits **1 ad credit at row creation** — so sequence it LAST
-  (render + verify a good MP4 first), and never re-submit on a guess (that double-bills). Call
-  `get_ad_credits` first; the user can check `gooseworks credits`.
+- Media generation (FAL / ElevenLabs) through the GooseWorks proxies is the **REAL spend** — billed
+  to the agent per call as you generate (Step 4). `submit_render { kind: "full" }` additionally
+  debits **1 nominal ad credit when the render ROW is opened** (a bookkeeping fee, NOT the render's
+  true cost) — so open it only once you actually have a rendered master (Step 4.1/4.2), and never
+  re-submit on a guess (that double-bills). The final-video QC gate (Step 4.3) then sits between
+  that master and PINNING it. Call `get_ad_credits` first; the user can check `gooseworks credits`.
 
 ## Step 1 — resolve the project, source, brand
 
-1. `get_ad_project { project_id }` → keep `brand_id`, `source_sample_id`, `name`, `status`.
+1. `get_ad_project { project_id }` → keep `brand_id`, `source_sample_id`, `name`, `status`, and
+   the **top-level** `app_url` + `brand_url` (returned alongside `project`, NOT inside it) — these
+   are the links you hand the user for the in-app review (Step 3) and the final delivery (Step 5).
 2. `get_ad_template { template_id: source_sample_id }` → the source video: `media_url`,
    `recipe`, `format` (e.g. "imessage"), `extracted_script`, `how_to`, `remix_spec`.
 3. Brand gate: `get_brand_kit { brand_id }`. If `researchStatus` is `complete`, REUSE it —
@@ -131,22 +144,55 @@ Playwright resolve, and point the recorder's `NODE_PATH` at it.
 > recipe does not yet carry `atoms` / `instructions` still hold the legacy `recipe.thread` payload;
 > migrate them to this shape (capabilities + instructions in the DB) — do not reintroduce a CLI map.
 
-## Step 3 — prepare ALL the ingredients, then review ONCE (always, before any paid render)
-
-This is a **review-once** flow: prepare every ingredient the video needs, show the whole set to
-the user in the app, get ONE approval, then render. Never render before approval, and don't drip
-ingredients out one at a time.
-
-1. **Generate every ingredient the format needs — not just the script.** For an iMessage video
-   that's typically: the **script** (the bubble thread), the **image(s)** shown in the conversation
-   (one or more), and the **end card**. Richer templates add more (hook frame, background, product
-   shots, music bed…). Read the recipe for the exact ingredient list. Generate the visuals NOW
-   (media proxies / recipe), and `get_upload_url` each preview asset to the project folder
-   `agent-config/brands/<brand_slug>/projects/<project_id>/working/review/<name>` (the same
-   path-prefix rule as final publish — a bare `working/review/<name>` won't render in the panel).
-   In `script_drafts`, set each ingredient's `path` to the project-relative `working/review/<name>`.
-   You may ask the user a couple of clarifying questions about the generation first if the recipe
-   calls for it (angle, which product, offer/code) — batch them, then prepare everything.
+## Step 3 — assemble the review set, then get ONE approval in the app (before the expensive render)
+
+This is a **review-once** flow: put the whole review set in the app, get ONE approval, then run the
+expensive render + any remaining paid work end-to-end. Never spend on the expensive render before
+approval, and don't drip pieces out one at a time and re-pause.
+
+**What goes in the review — show the REAL cheap pieces, PROMPT only the expensive render.** Split
+every piece three ways by cost, NOT just "free vs paid":
+- **FREE** (an iMessage / Apple-Notes HTML mockup, a text/CTA line — rendered locally, no proxy
+  call) → generate NOW and mirror the real asset.
+- **CHEAP paid** — a single still/image, the creator/avatar frame, the end card, a short voiceover
+  or music bed (each costs cents → roughly **≤ 100 credits**) → **generate these NOW too** and
+  mirror the real asset. The few credits buy a real review: the user SEES the actual creator face
+  and end card and HEARS the VO, instead of judging a prompt. **This OVERRIDES any recipe rule that
+  says to gate ALL paid calls** — only the expensive render below is gated.
+- **EXPENSIVE paid** — the video take / final AI render (hundreds of credits) → do NOT generate.
+  Put its **exact prompt/spec** (+ ref image URLs) in the tile. This is the ONE thing approved as a
+  prompt (you can't preview a hundreds-of-credits video for free); it's generated only in Step 4.
+
+**The expensive render's exact prompt must be in the panel BEFORE you ask for approval** — so a
+single "go" runs it (plus any remaining paid work) without re-pausing mid-run.
+
+**Show every cost in CREDITS, never dollars.** 1 credit = $0.01 and media generations bill at
+provider-cost × 1.2, so **credits ≈ round-up(provider-$ × 120)** per generation, plus a flat
+**200-credit base per video**. Convert any $ figures to credits and show ONLY credits to the user —
+never print a "$…" amount.
+
+**Never assemble/stitch the finished video for review.** The review is of the individual pieces (or
+their prompts) — never a "full cascade" / "approved cut" clip. Building the whole video before
+approval defeats the gate (the user opens the review to an already-finished video) and wastes the
+render (GOOSE-2542). The full video is assembled ONLY in Step 4, after approval. A `video`
+ingredient here is only a genuinely separate SOURCE clip the format needs (e.g. supplied b-roll).
+
+1. **Assemble every piece the format needs — not just the script.** Read the recipe for the exact
+   list. For an iMessage video that's the **script** (bubble thread), the **conversation image(s)**,
+   and the **end card**; richer templates add a hook frame, background, product shots, music bed, a
+   creator/avatar, a voiceover… For each piece, decide FREE / CHEAP-paid / EXPENSIVE-paid (above):
+   - **FREE or CHEAP paid** (≤ ~100 credits — HTML mockups, a still, the creator frame, the end
+     card, a short VO/music bed) → generate it now and `get_upload_url` the asset to the project
+     folder `agent-config/brands/<brand_slug>/projects/<project_id>/working/review/<name>` (same
+     path-prefix rule as final publish — a bare `working/review/<name>` won't render in the panel);
+     set that piece's `path` in `script_drafts` to the project-relative `working/review/<name>`.
+   - **EXPENSIVE paid** (the video take / final render, hundreds of credits) → do NOT generate. Put
+     the **exact prompt/spec** (and any ref image URLs) in the tile's `text` / `subtitle` so the
+     user reviews what will be spent on. No `path` yet — it's generated in Step 4.
+   Include the **estimated cost in CREDITS** (never dollars) of the cheap pieces already generated +
+   the pending render, so the user approves knowing the total spend. You may batch a couple of
+   clarifying questions first if the recipe calls for it (angle, which product, offer/code), then
+   assemble everything.
 2. **Mirror the whole ingredient set for review** — `update_ad_project_script { project_id,
    script_drafts, script }`. `script_drafts` is a structured payload of **container-tagged
    ingredients** so the app renders each piece the right way:
@@ -161,21 +207,34 @@ ingredients out one at a time.
      for the podcast shape, or pass the readable `script` string).
    `path` = `working/review/<name>` (upload the preview asset first via `get_upload_url`); `url`
    works too. **Label every ingredient** ("Hook image", "End card", "Voiceover", "Background
-   music", "HER"). This writes NO render and costs NO credits — it populates the review panel.
-3. **STOP and ask the user to approve the ingredients in THIS Claude Code session.** Do not render
-   until they say go. If they want changes, regenerate the affected ingredient, call
-   `update_ad_project_script` again, and re-ask. Only AFTER approval do Step 4.
+   music", "HER"). The `update_ad_project_script` call itself writes no render and costs no credits
+   (the cheap pieces you already generated above have their own small cost) — it just populates the
+   review panel.
+3. **STOP — the review happens in the APP's review panel, NOT in this chat.** You've mirrored the
+   ingredients (3.2); now hand the user the project's `app_url` (from `get_ad_project`) and tell
+   them to review the pieces there and hit **"Approve & render"**. That button gives them a short
+   message to paste back into this session — THAT is your go-ahead. Do NOT paste the
+   script/ingredients into the chat for a thumbs-up, and do NOT render until that approval comes
+   back from the app. If they want changes (via the app's comments or here), regenerate the
+   affected ingredient, call `update_ad_project_script` again, tell them it's refreshed in the
+   app, and wait for a fresh approval. Only AFTER the app approval do Step 4. A single approval
+   authorises the WHOLE remaining chain — generate every paid piece, render, self-QC, publish —
+   with NO further pauses (that is exactly why every paid prompt must already be in the panel).
 
 ## Step 4 — render locally, report stages, publish
 
-1. Render per the recipe (Playwright record → ffmpeg stitch → `mix-master` audio). Generate any
-   hook / background / end-card assets through the media proxies (below).
+1. Now generate every PAID piece you showed as a prompt in Step 3 — the AI stills/video, voice,
+   music, the end-card render — through the media proxies (below), each from its approved prompt.
+   Then assemble per the recipe (Playwright record where needed → ffmpeg stitch → `mix-master`
+   audio).
 2. Open the row LAST: `submit_render { project_id, kind: "full" }` → keep `render_id`, then
    `update_render_status { render_id, status: "running" }`. The render row tracks status only
    (queued / running / complete / failed) — narrate fine-grained progress with
    `append_project_message` instead.
-3. **MANDATORY final-video review gate — review EVERY finished master before `set_final_render`,
-   whatever the format (UGC or not).** The render credit is already spent (`submit_render` in 4.2);
+3. **MANDATORY final-video QC gate — YOU review EVERY finished master before `set_final_render`,
+   whatever the format (UGC or not).** This is your own automated quality check, separate from the
+   user's Step-3 approval — it does not go back to the user. The render row is already open (its
+   nominal credit spent, `submit_render` in 4.2);
    this gate stands between a rendered master and PINNING/publishing it, so a bad render never gets
    set as final. A master that looks fine on a still can still have a mis-voiced word, a caption
    drifting off its line, a beat out of order, or a deformation — review the actual VIDEO, not
@@ -279,10 +338,23 @@ path. (`fal-storage-proxy` may 404 depending on the install; don't block on it
 
 - **MCP + ffmpeg + Playwright required** — run `gooseworks doctor` in Phase 0; stop with the
   exact fix it prints if anything is ✗.
-- **Prepare ALL ingredients first** (script + every visual: image(s) + end card + whatever else
-  the template needs), mirror the whole set with `update_ad_project_script`, and get the user's
-  approval in-session BEFORE rendering — always (review-once).
-- **submit_render LAST**; `output_url` = the durable render-file URL, never a CDN URL.
+- **Assemble the whole review set first**, mirror it with `update_ad_project_script`, and get the
+  user's approval **in the app's review panel** (the "Approve & render" button) BEFORE the expensive
+  render — never ask for a thumbs-up in this chat (review-once, in-app).
+- **Show the REAL cheap pieces; PROMPT only the expensive render.** Generate the FREE + CHEAP-paid
+  pieces (≤ ~100 credits — stills, creator frame, end card, short VO/music) and mirror the real
+  assets; put ONLY the expensive video take/render in the panel as its exact prompt. That prompt
+  must be in the panel before you ask to approve, so a single "go" runs the render + any remaining
+  paid work (→ QC → publish) with no re-pausing.
+- **Costs in CREDITS, never dollars.** credits ≈ round-up(provider-$ × 120) per generation + a flat
+  200-credit base per video; never show a "$…" figure to the user.
+- **Never assemble the full video before approval.** The review shows the
+  individual PIECES, never the finished cut (or their prompts) — not a
+  stitched/composited cut; do not add a "full cascade" / finished-video clip
+  as a review ingredient (GOOSE-2542). The assembled video is produced only in
+  Step 4.
+- **submit_render only after the master is rendered** (Step 4.2), never on a guess; `output_url` =
+  the durable render-file URL, never a CDN URL.
 - **Always pass `project_id` on media-proxy calls** (fal / ElevenLabs) so the credits attribute
   to this ad project — that's what lets the user see per-project spend in the app.
 - **Verify a real, non-empty MP4** (watch it) before marking the render complete.