test("explicit chart-heavy page plans keep distinct page missions after normalization", () => {

const brief = `Create a 6-page English consulting-style data-story deck.

const summary = JSON.stringify({

rawBrief: brief,

subject: "Global AI infrastructure economics in 2026",

deliverable: "6-page PPT",

pageCount: 6,

audienceOrQualityBar: "consulting-style data-story",

coreTask: "Show consultant-grade data-storytelling.",

evidencePolicy: {

tier: "explicit assumption",

summary: "Use internally consistent sample data.",

lines: ["Do not present the scenario as a factual market report."],

},

pageMissions: [],

visualThinking: {

dominantVisualAnchor: "one dominant analytical object per page",

readingPath: "headline to chart to compact annotation",

regionStrategy: "one dominant chart field with minimal support",

densityPosture: "low-to-medium",

avoidPattern: "equal-weight card walls",

},

capabilityActivations: [],

assumptionPolicy: ["Use illustrative numbers only."],

});

const plan = parseStudioPreflightPlan({

text: summary,

brief,

requestedPageCount: 6,

});

assert.equal(plan.pageMissions.length, 6);

assert.equal(plan.pageMissions[1]?.missionScope, "page");

assert.equal(plan.pageMissions[4]?.missionScope, "page");

assert.match(plan.pageMissions[1]?.mission ?? "", /regional ai infrastructure capex|utilization growth/i);

assert.match(plan.pageMissions[4]?.mission ?? "", /margin pressure|gpu depreciation|networking cost/i);

assert.notEqual(plan.pageMissions[1]?.mission, plan.pageMissions[4]?.mission);

assert.notEqual(plan.pageMissions[1]?.headlineClaim, plan.pageMissions[4]?.headlineClaim);

? `Close the ${subject} story with a distinct final synthesis step.`

: `Develop proof step ${index - 1} for ${subject}.`,

? `${subject} should end with a distinct closing synthesis instead of repeating an earlier proof page.`

: `${subject} needs a distinct proof step on this page instead of reusing another page mission.`,

const scopedSegmentSummary = clampText(args.segment.text, 140);

? `Frame ${args.subject || "the subject"} through one BCG-style 2x2 matrix focused on ${scopedSegmentSummary}.`

? `Explain ${args.subject || "the subject"} through one chart-led evidence view focused on ${scopedSegmentSummary}.`

? `Explain ${args.subject || "the subject"} through one 3D-model-centered page focused on ${scopedSegmentSummary}.`

? `${args.subject || "The subject"} should be positioned through one quadrant matrix that specifically answers ${scopedSegmentSummary}.`

? `${args.subject || "The subject"} is best supported through one chart-led proof pattern that specifically answers ${scopedSegmentSummary}.`

? `${args.subject || "The subject"} is best explained through one dominant 3D product or system model focused on ${scopedSegmentSummary}.`

- **UI handoff path**: opening that exact returned `openUrl` in the user's default browser makes Studio consume the task, create a local project, and auto-start generation.

4. the agent opens the returned `openUrl` exactly in the default browser

5. Parse the returned `openUrl`.

6. In the **same default browser profile**, open that exact `openUrl`.

7. Do not replace it with the Studio homepage or a hand-written root URL.

8. Stop as soon as the browser has opened the launch URL.

Opening `http://127.0.0.1:5174/` by itself is not enough. The bridge only works when the browser visits the specific returned launch URL, for example:

open 'http://127.0.0.1:5174/?bridgeLaunch=<launch-id>'

If you created a launch task but only opened the Studio homepage, assume the prompt was **not** injected.

Shape prompts around these seven pieces:

- `Layout / structure cue`

- `Visual thesis`

- `Anti-patterns`

The current Studio engine needs both a **content contract** and a **visual contract**.

- The content contract keeps the page factual and logically structured.

- The visual contract decides whether the page feels designed or generic.

- The preflight-aware budget decides whether that ambition survives without collapsing into overflow or clutter.

Default rule: each page should have **one visual thesis**.

That usually means:

- one dominant visual or structural idea

- quiet secondary text

- restrained annotation

- strong hierarchy

- not many equal-weight cards competing for attention

Prefer:

- `single dominant visual`

- `figure-led`

- `chart-led`

- `matrix-first`

- `timeline-led`

- `hero + rail`

Avoid:

- equal-weight card walls

- generic dashboard clutter

- “beautiful” or “premium” with no structural cue

- asking one page to carry several unrelated visual ideas

Read `references/visual-briefing.md` when you need the visual prompting rules, `references/data-story-patterns.md` when you need to map source material to an archetype, `references/premium-visual-cues.md` for effective visual language, and `references/preflight-aware-visual-budget.md` when you need to keep ambition inside the engine's fit limits.

- one visual thesis per page

- explicit anti-patterns like `not equal-weight cards` or `not dashboard clutter`

- vague quality adjectives like `premium`, `top-tier`, `more advanced`

That means the best prompt is one that gives the model:

- a clean page split

- a realistic visual budget

- one dominant object per page where possible

- concise labels and short titles

Read `references/preflight-aware-visual-budget.md` when you need the current budget logic.

- default to one clear product claim, one workflow strip, and a few differentiated proof points

With the bridge path, opening the exact returned `openUrl` is enough for Studio to start generation. The human is expected to take over from the browser after the launch URL is opened.

Be precise here:

- `POST /api/studio/bridge/launch` only creates the task

- opening the exact returned `openUrl` is what consumes it

- opening the root Studio page does not consume the task

- Read `references/prompt-shaping.md` for the full 7-part prompt contract.

- Read `references/visual-briefing.md` for the visual contract.

- Read `references/data-story-patterns.md` for content-to-layout mapping.

- Read `references/premium-visual-cues.md` for effective visual phrasing.

- Read `references/preflight-aware-visual-budget.md` for fit-aware visual budgeting.

short_description: "Read the source first, shape a visually strong Studio prompt, bridge it into Studio, open the exact returned launch URL in the default browser, then stop"

default_prompt: "Use $ppt-workbench-studio to read source links first in the user's default browser, synthesize a concise Studio prompt with one visual thesis per page, prefer current Studio cues such as figure-led, chart-led, matrix-first, or hero + rail layouts where appropriate, avoid equal-weight card walls and dashboard clutter, call /api/studio/bridge/launch, parse the returned openUrl, open that exact launch URL in the same browser profile instead of the Studio homepage, and stop once the browser has opened that URL."