test(storybook): shrink the smoke matrix to its declared checks

[UncertaintyDeterminesYou4ndMe]

Part of #2390 (Storybook half; the Electron E2E changes follow in a separate PR per the issue).

Problem

The product smoke manifest expanded 22 surfaces into 92 serial page loads, but the assertions do not justify the matrix:

• Every job runs the same baseline: mount succeeds, no console/page errors, root has content, and (dark jobs) the .dark class + computed color-scheme. Only a surface's declared checks[] add anything beyond that.
• Nine surfaces declare no checks (onboarding, settings, usage, providers, skills, mcp, mcpMarketplace, mcpEditor, dailyReview) — their compact and floor viewports re-ran exactly the baseline that wide already proves. Same for askUserQuestion.
• Three checked surfaces ran compact and floor through the same check branch: module-page-inspector branches at 1024px (both compact 820 and floor 480 take the dialog branch), plan-reminder-row's right-alignment check gates on ≥1100px (both skip it), and session-context-layer is one width-agnostic predicate whose distinct narrow behavior (overflow-menu fallback) floor already exercises at the stricter width.

Change

One file: apps/desktop/stories/product-smoke-manifest.json. Every removal goes through the runner's own declared mechanism — the validator fails unless each of the three product viewports is either covered or given a written opt-out reason — so nothing is silently skipped:

• 9 no-checks surfaces + askUserQuestion → wide only (both color schemes kept: the dark-scheme assertion is a real per-job check)
• planReminders / planRemindersInspector / sessionContext → wide + floor, compact opted out as the same check branch at a looser width

Untouched: REQUIRED_PRODUCT_SURFACES (all 22 surfaces still present), all checks[], the runner itself, and the full catalog mount sweep — every story in the built index still renders once (100 renders before and after), so 'renders without throwing' coverage is not reduced for any story.

Timing

Local, smoke:storybook after build-storybook, same machine:

	manifest jobs (serial)	catalog renders	wall
before	92	100	43.0s
after	48	100	28.6s (−33%)

The manifest half runs at concurrency 1 (its geometry checks need a quiet page), so it dominates smoke wall time — and is exactly the half this shrinks.

Judgment call for review

The three checked-surface compact opt-outs (planReminders, planRemindersInspector, sessionContext) are the interpretive part: the check code takes the same branch as floor, but the DOM under it differs at 820px. If you weigh 820px as an independent geometry worth mounting, say so and I'll restore those three (matrix 48 → 54; the nine no-checks surfaces are the unambiguous bulk of the win).

cc @Astro-Han

[Astro-Han]

Thanks — this is a good reduction. The manifest should pay for additional viewport jobs only when those jobs prove a distinct contract.

I do not think the removed floor jobs need to be restored. The affected entries had no geometry checks, so another narrow mount would still pass if overflow, column layout, or containment regressed. Their story states continue to receive the catalog mount sweep. If a narrow layout becomes an important contract, the useful follow-up is a focused geometry assertion rather than restoring a mount-only viewport duplicate.

Two small P3 documentation cleanups:

• The ask-user-question story comment still says the manifest renders compact and floor variants, but this PR changes it to wide only.
• The PR description reports 92 → 48 manifest jobs; against this branch's parent manifest, the actual count is 90 → 46.

Neither needs to block the test reduction. The implementation and CI look good to merge. Thanks!

[UncertaintyDeterminesYou4ndMe]

Part of #2390 (Storybook half; the Electron E2E changes follow in a separate PR per the issue).

Problem

The product smoke manifest expanded 22 surfaces into 92 serial page loads, but the assertions do not justify the matrix:

• Every job runs the same baseline: mount succeeds, no console/page errors, root has content, and (dark jobs) the .dark class + computed color-scheme. Only a surface's declared checks[] add anything beyond that.
• Nine surfaces declare no checks (onboarding, settings, usage, providers, skills, mcp, mcpMarketplace, mcpEditor, dailyReview) — their compact and floor viewports re-ran exactly the baseline that wide already proves. Same for askUserQuestion.
• Three checked surfaces ran compact and floor through the same check branch: module-page-inspector branches at 1024px (both compact 820 and floor 480 take the dialog branch), plan-reminder-row's right-alignment check gates on ≥1100px (both skip it), and session-context-layer is one width-agnostic predicate whose distinct narrow behavior (overflow-menu fallback) floor already exercises at the stricter width.

Change

One file: apps/desktop/stories/product-smoke-manifest.json. Every removal goes through the runner's own declared mechanism — the validator fails unless each of the three product viewports is either covered or given a written opt-out reason — so nothing is silently skipped:

• 9 no-checks surfaces + askUserQuestion → wide only (both color schemes kept: the dark-scheme assertion is a real per-job check)
• planReminders / planRemindersInspector / sessionContext → wide + floor, compact opted out as the same check branch at a looser width

Untouched: REQUIRED_PRODUCT_SURFACES (all 22 surfaces still present), all checks[], the runner itself, and the full catalog mount sweep — every story in the built index still renders once (100 renders before and after), so 'renders without throwing' coverage is not reduced for any story.

Timing

Local, smoke:storybook after build-storybook, same machine:

	manifest jobs (serial)	catalog renders	wall
before	92	100	43.0s
after	48	100	28.6s (−33%)

The manifest half runs at concurrency 1 (its geometry checks need a quiet page), so it dominates smoke wall time — and is exactly the half this shrinks.

Judgment call for review

The three checked-surface compact opt-outs (planReminders, planRemindersInspector, sessionContext) are the interpretive part: the check code takes the same branch as floor, but the DOM under it differs at 820px. If you weigh 820px as an independent geometry worth mounting, say so and I'll restore those three (matrix 48 → 54; the nine no-checks surfaces are the unambiguous bulk of the win).

cc @Astro-Han

[Astro-Han]

Thanks — this is a good reduction. The manifest should pay for additional viewport jobs only when those jobs prove a distinct contract.

I do not think the removed floor jobs need to be restored. The affected entries had no geometry checks, so another narrow mount would still pass if overflow, column layout, or containment regressed. Their story states continue to receive the catalog mount sweep. If a narrow layout becomes an important contract, the useful follow-up is a focused geometry assertion rather than restoring a mount-only viewport duplicate.

Two small P3 documentation cleanups:

• The ask-user-question story comment still says the manifest renders compact and floor variants, but this PR changes it to wide only.
• The PR description reports 92 → 48 manifest jobs; against this branch's parent manifest, the actual count is 90 → 46.

Neither needs to block the test reduction. The implementation and CI look good to merge. Thanks!

[UncertaintyDeterminesYou4ndMe]

Part of #2390 (Storybook half; the Electron E2E changes follow in a separate PR per the issue).

Problem

The product smoke manifest expanded 22 surfaces into 92 serial page loads, but the assertions do not justify the matrix:

• Every job runs the same baseline: mount succeeds, no console/page errors, root has content, and (dark jobs) the .dark class + computed color-scheme. Only a surface's declared checks[] add anything beyond that.
• Nine surfaces declare no checks (onboarding, settings, usage, providers, skills, mcp, mcpMarketplace, mcpEditor, dailyReview) — their compact and floor viewports re-ran exactly the baseline that wide already proves. Same for askUserQuestion.
• Three checked surfaces ran compact and floor through the same check branch: module-page-inspector branches at 1024px (both compact 820 and floor 480 take the dialog branch), plan-reminder-row's right-alignment check gates on ≥1100px (both skip it), and session-context-layer is one width-agnostic predicate whose distinct narrow behavior (overflow-menu fallback) floor already exercises at the stricter width.

Change

One file: apps/desktop/stories/product-smoke-manifest.json. Every removal goes through the runner's own declared mechanism — the validator fails unless each of the three product viewports is either covered or given a written opt-out reason — so nothing is silently skipped:

• 9 no-checks surfaces + askUserQuestion → wide only (both color schemes kept: the dark-scheme assertion is a real per-job check)
• planReminders / planRemindersInspector / sessionContext → wide + floor, compact opted out as the same check branch at a looser width

Untouched: REQUIRED_PRODUCT_SURFACES (all 22 surfaces still present), all checks[], the runner itself, and the full catalog mount sweep — every story in the built index still renders once (100 renders before and after), so 'renders without throwing' coverage is not reduced for any story.

Timing

Local, smoke:storybook after build-storybook, same machine:

	manifest jobs (serial)	catalog renders	wall
before	92	100	43.0s
after	48	100	28.6s (−33%)

The manifest half runs at concurrency 1 (its geometry checks need a quiet page), so it dominates smoke wall time — and is exactly the half this shrinks.

Judgment call for review

The three checked-surface compact opt-outs (planReminders, planRemindersInspector, sessionContext) are the interpretive part: the check code takes the same branch as floor, but the DOM under it differs at 820px. If you weigh 820px as an independent geometry worth mounting, say so and I'll restore those three (matrix 48 → 54; the nine no-checks surfaces are the unambiguous bulk of the win).

cc @Astro-Han

[Astro-Han]

Thanks — this is a good reduction. The manifest should pay for additional viewport jobs only when those jobs prove a distinct contract.

I do not think the removed floor jobs need to be restored. The affected entries had no geometry checks, so another narrow mount would still pass if overflow, column layout, or containment regressed. Their story states continue to receive the catalog mount sweep. If a narrow layout becomes an important contract, the useful follow-up is a focused geometry assertion rather than restoring a mount-only viewport duplicate.

Two small P3 documentation cleanups:

• The ask-user-question story comment still says the manifest renders compact and floor variants, but this PR changes it to wide only.
• The PR description reports 92 → 48 manifest jobs; against this branch's parent manifest, the actual count is 90 → 46.

Neither needs to block the test reduction. The implementation and CI look good to merge. Thanks!

[UncertaintyDeterminesYou4ndMe]

Part of #2390 (Storybook half; the Electron E2E changes follow in a separate PR per the issue).

Problem

The product smoke manifest expanded 22 surfaces into 92 serial page loads, but the assertions do not justify the matrix:

• Every job runs the same baseline: mount succeeds, no console/page errors, root has content, and (dark jobs) the .dark class + computed color-scheme. Only a surface's declared checks[] add anything beyond that.
• Nine surfaces declare no checks (onboarding, settings, usage, providers, skills, mcp, mcpMarketplace, mcpEditor, dailyReview) — their compact and floor viewports re-ran exactly the baseline that wide already proves. Same for askUserQuestion.
• Three checked surfaces ran compact and floor through the same check branch: module-page-inspector branches at 1024px (both compact 820 and floor 480 take the dialog branch), plan-reminder-row's right-alignment check gates on ≥1100px (both skip it), and session-context-layer is one width-agnostic predicate whose distinct narrow behavior (overflow-menu fallback) floor already exercises at the stricter width.

Change

One file: apps/desktop/stories/product-smoke-manifest.json. Every removal goes through the runner's own declared mechanism — the validator fails unless each of the three product viewports is either covered or given a written opt-out reason — so nothing is silently skipped:

• 9 no-checks surfaces + askUserQuestion → wide only (both color schemes kept: the dark-scheme assertion is a real per-job check)
• planReminders / planRemindersInspector / sessionContext → wide + floor, compact opted out as the same check branch at a looser width

Untouched: REQUIRED_PRODUCT_SURFACES (all 22 surfaces still present), all checks[], the runner itself, and the full catalog mount sweep — every story in the built index still renders once (100 renders before and after), so 'renders without throwing' coverage is not reduced for any story.

Timing

Local, smoke:storybook after build-storybook, same machine:

	manifest jobs (serial)	catalog renders	wall
before	92	100	43.0s
after	48	100	28.6s (−33%)

The manifest half runs at concurrency 1 (its geometry checks need a quiet page), so it dominates smoke wall time — and is exactly the half this shrinks.

Judgment call for review

The three checked-surface compact opt-outs (planReminders, planRemindersInspector, sessionContext) are the interpretive part: the check code takes the same branch as floor, but the DOM under it differs at 820px. If you weigh 820px as an independent geometry worth mounting, say so and I'll restore those three (matrix 48 → 54; the nine no-checks surfaces are the unambiguous bulk of the win).

cc @Astro-Han

[Astro-Han]

Thanks — this is a good reduction. The manifest should pay for additional viewport jobs only when those jobs prove a distinct contract.

I do not think the removed floor jobs need to be restored. The affected entries had no geometry checks, so another narrow mount would still pass if overflow, column layout, or containment regressed. Their story states continue to receive the catalog mount sweep. If a narrow layout becomes an important contract, the useful follow-up is a focused geometry assertion rather than restoring a mount-only viewport duplicate.

Two small P3 documentation cleanups:

• The ask-user-question story comment still says the manifest renders compact and floor variants, but this PR changes it to wide only.
• The PR description reports 92 → 48 manifest jobs; against this branch's parent manifest, the actual count is 90 → 46.

Neither needs to block the test reduction. The implementation and CI look good to merge. Thanks!

[UncertaintyDeterminesYou4ndMe]

Part of #2390 (Storybook half; the Electron E2E changes follow in a separate PR per the issue).

Problem

The product smoke manifest expanded 22 surfaces into 92 serial page loads, but the assertions do not justify the matrix:

• Every job runs the same baseline: mount succeeds, no console/page errors, root has content, and (dark jobs) the .dark class + computed color-scheme. Only a surface's declared checks[] add anything beyond that.
• Nine surfaces declare no checks (onboarding, settings, usage, providers, skills, mcp, mcpMarketplace, mcpEditor, dailyReview) — their compact and floor viewports re-ran exactly the baseline that wide already proves. Same for askUserQuestion.
• Three checked surfaces ran compact and floor through the same check branch: module-page-inspector branches at 1024px (both compact 820 and floor 480 take the dialog branch), plan-reminder-row's right-alignment check gates on ≥1100px (both skip it), and session-context-layer is one width-agnostic predicate whose distinct narrow behavior (overflow-menu fallback) floor already exercises at the stricter width.

Change

One file: apps/desktop/stories/product-smoke-manifest.json. Every removal goes through the runner's own declared mechanism — the validator fails unless each of the three product viewports is either covered or given a written opt-out reason — so nothing is silently skipped:

• 9 no-checks surfaces + askUserQuestion → wide only (both color schemes kept: the dark-scheme assertion is a real per-job check)
• planReminders / planRemindersInspector / sessionContext → wide + floor, compact opted out as the same check branch at a looser width

Untouched: REQUIRED_PRODUCT_SURFACES (all 22 surfaces still present), all checks[], the runner itself, and the full catalog mount sweep — every story in the built index still renders once (100 renders before and after), so 'renders without throwing' coverage is not reduced for any story.

Timing

Local, smoke:storybook after build-storybook, same machine:

	manifest jobs (serial)	catalog renders	wall
before	92	100	43.0s
after	48	100	28.6s (−33%)

The manifest half runs at concurrency 1 (its geometry checks need a quiet page), so it dominates smoke wall time — and is exactly the half this shrinks.

Judgment call for review

The three checked-surface compact opt-outs (planReminders, planRemindersInspector, sessionContext) are the interpretive part: the check code takes the same branch as floor, but the DOM under it differs at 820px. If you weigh 820px as an independent geometry worth mounting, say so and I'll restore those three (matrix 48 → 54; the nine no-checks surfaces are the unambiguous bulk of the win).

cc @Astro-Han

[Astro-Han]

Thanks — this is a good reduction. The manifest should pay for additional viewport jobs only when those jobs prove a distinct contract.

I do not think the removed floor jobs need to be restored. The affected entries had no geometry checks, so another narrow mount would still pass if overflow, column layout, or containment regressed. Their story states continue to receive the catalog mount sweep. If a narrow layout becomes an important contract, the useful follow-up is a focused geometry assertion rather than restoring a mount-only viewport duplicate.

Two small P3 documentation cleanups:

• The ask-user-question story comment still says the manifest renders compact and floor variants, but this PR changes it to wide only.
• The PR description reports 92 → 48 manifest jobs; against this branch's parent manifest, the actual count is 90 → 46.

Neither needs to block the test reduction. The implementation and CI look good to merge. Thanks!

[UncertaintyDeterminesYou4ndMe]

Part of #2390 (Storybook half; the Electron E2E changes follow in a separate PR per the issue).

Problem

The product smoke manifest expanded 22 surfaces into 92 serial page loads, but the assertions do not justify the matrix:

• Every job runs the same baseline: mount succeeds, no console/page errors, root has content, and (dark jobs) the .dark class + computed color-scheme. Only a surface's declared checks[] add anything beyond that.
• Nine surfaces declare no checks (onboarding, settings, usage, providers, skills, mcp, mcpMarketplace, mcpEditor, dailyReview) — their compact and floor viewports re-ran exactly the baseline that wide already proves. Same for askUserQuestion.
• Three checked surfaces ran compact and floor through the same check branch: module-page-inspector branches at 1024px (both compact 820 and floor 480 take the dialog branch), plan-reminder-row's right-alignment check gates on ≥1100px (both skip it), and session-context-layer is one width-agnostic predicate whose distinct narrow behavior (overflow-menu fallback) floor already exercises at the stricter width.

Change

One file: apps/desktop/stories/product-smoke-manifest.json. Every removal goes through the runner's own declared mechanism — the validator fails unless each of the three product viewports is either covered or given a written opt-out reason — so nothing is silently skipped:

• 9 no-checks surfaces + askUserQuestion → wide only (both color schemes kept: the dark-scheme assertion is a real per-job check)
• planReminders / planRemindersInspector / sessionContext → wide + floor, compact opted out as the same check branch at a looser width

Untouched: REQUIRED_PRODUCT_SURFACES (all 22 surfaces still present), all checks[], the runner itself, and the full catalog mount sweep — every story in the built index still renders once (100 renders before and after), so 'renders without throwing' coverage is not reduced for any story.

Timing

Local, smoke:storybook after build-storybook, same machine:

	manifest jobs (serial)	catalog renders	wall
before	92	100	43.0s
after	48	100	28.6s (−33%)

The manifest half runs at concurrency 1 (its geometry checks need a quiet page), so it dominates smoke wall time — and is exactly the half this shrinks.

Judgment call for review

The three checked-surface compact opt-outs (planReminders, planRemindersInspector, sessionContext) are the interpretive part: the check code takes the same branch as floor, but the DOM under it differs at 820px. If you weigh 820px as an independent geometry worth mounting, say so and I'll restore those three (matrix 48 → 54; the nine no-checks surfaces are the unambiguous bulk of the win).

cc @Astro-Han

[Astro-Han]

Thanks — this is a good reduction. The manifest should pay for additional viewport jobs only when those jobs prove a distinct contract.

I do not think the removed floor jobs need to be restored. The affected entries had no geometry checks, so another narrow mount would still pass if overflow, column layout, or containment regressed. Their story states continue to receive the catalog mount sweep. If a narrow layout becomes an important contract, the useful follow-up is a focused geometry assertion rather than restoring a mount-only viewport duplicate.

Two small P3 documentation cleanups:

• The ask-user-question story comment still says the manifest renders compact and floor variants, but this PR changes it to wide only.
• The PR description reports 92 → 48 manifest jobs; against this branch's parent manifest, the actual count is 90 → 46.

Neither needs to block the test reduction. The implementation and CI look good to merge. Thanks!

[UncertaintyDeterminesYou4ndMe]

Part of #2390 (Storybook half; the Electron E2E changes follow in a separate PR per the issue).

Problem

The product smoke manifest expanded 22 surfaces into 92 serial page loads, but the assertions do not justify the matrix:

• Every job runs the same baseline: mount succeeds, no console/page errors, root has content, and (dark jobs) the .dark class + computed color-scheme. Only a surface's declared checks[] add anything beyond that.
• Nine surfaces declare no checks (onboarding, settings, usage, providers, skills, mcp, mcpMarketplace, mcpEditor, dailyReview) — their compact and floor viewports re-ran exactly the baseline that wide already proves. Same for askUserQuestion.
• Three checked surfaces ran compact and floor through the same check branch: module-page-inspector branches at 1024px (both compact 820 and floor 480 take the dialog branch), plan-reminder-row's right-alignment check gates on ≥1100px (both skip it), and session-context-layer is one width-agnostic predicate whose distinct narrow behavior (overflow-menu fallback) floor already exercises at the stricter width.

Change

One file: apps/desktop/stories/product-smoke-manifest.json. Every removal goes through the runner's own declared mechanism — the validator fails unless each of the three product viewports is either covered or given a written opt-out reason — so nothing is silently skipped:

• 9 no-checks surfaces + askUserQuestion → wide only (both color schemes kept: the dark-scheme assertion is a real per-job check)
• planReminders / planRemindersInspector / sessionContext → wide + floor, compact opted out as the same check branch at a looser width

Untouched: REQUIRED_PRODUCT_SURFACES (all 22 surfaces still present), all checks[], the runner itself, and the full catalog mount sweep — every story in the built index still renders once (100 renders before and after), so 'renders without throwing' coverage is not reduced for any story.

Timing

Local, smoke:storybook after build-storybook, same machine:

	manifest jobs (serial)	catalog renders	wall
before	92	100	43.0s
after	48	100	28.6s (−33%)

The manifest half runs at concurrency 1 (its geometry checks need a quiet page), so it dominates smoke wall time — and is exactly the half this shrinks.

Judgment call for review

The three checked-surface compact opt-outs (planReminders, planRemindersInspector, sessionContext) are the interpretive part: the check code takes the same branch as floor, but the DOM under it differs at 820px. If you weigh 820px as an independent geometry worth mounting, say so and I'll restore those three (matrix 48 → 54; the nine no-checks surfaces are the unambiguous bulk of the win).

cc @Astro-Han

[Astro-Han]

Thanks — this is a good reduction. The manifest should pay for additional viewport jobs only when those jobs prove a distinct contract.

I do not think the removed floor jobs need to be restored. The affected entries had no geometry checks, so another narrow mount would still pass if overflow, column layout, or containment regressed. Their story states continue to receive the catalog mount sweep. If a narrow layout becomes an important contract, the useful follow-up is a focused geometry assertion rather than restoring a mount-only viewport duplicate.

Two small P3 documentation cleanups:

• The ask-user-question story comment still says the manifest renders compact and floor variants, but this PR changes it to wide only.
• The PR description reports 92 → 48 manifest jobs; against this branch's parent manifest, the actual count is 90 → 46.

Neither needs to block the test reduction. The implementation and CI look good to merge. Thanks!

[UncertaintyDeterminesYou4ndMe]

Part of #2390 (Storybook half; the Electron E2E changes follow in a separate PR per the issue).

Problem

The product smoke manifest expanded 22 surfaces into 92 serial page loads, but the assertions do not justify the matrix:

• Every job runs the same baseline: mount succeeds, no console/page errors, root has content, and (dark jobs) the .dark class + computed color-scheme. Only a surface's declared checks[] add anything beyond that.
• Nine surfaces declare no checks (onboarding, settings, usage, providers, skills, mcp, mcpMarketplace, mcpEditor, dailyReview) — their compact and floor viewports re-ran exactly the baseline that wide already proves. Same for askUserQuestion.
• Three checked surfaces ran compact and floor through the same check branch: module-page-inspector branches at 1024px (both compact 820 and floor 480 take the dialog branch), plan-reminder-row's right-alignment check gates on ≥1100px (both skip it), and session-context-layer is one width-agnostic predicate whose distinct narrow behavior (overflow-menu fallback) floor already exercises at the stricter width.

Change

One file: apps/desktop/stories/product-smoke-manifest.json. Every removal goes through the runner's own declared mechanism — the validator fails unless each of the three product viewports is either covered or given a written opt-out reason — so nothing is silently skipped:

• 9 no-checks surfaces + askUserQuestion → wide only (both color schemes kept: the dark-scheme assertion is a real per-job check)
• planReminders / planRemindersInspector / sessionContext → wide + floor, compact opted out as the same check branch at a looser width

Untouched: REQUIRED_PRODUCT_SURFACES (all 22 surfaces still present), all checks[], the runner itself, and the full catalog mount sweep — every story in the built index still renders once (100 renders before and after), so 'renders without throwing' coverage is not reduced for any story.

Timing

Local, smoke:storybook after build-storybook, same machine:

	manifest jobs (serial)	catalog renders	wall
before	92	100	43.0s
after	48	100	28.6s (−33%)

The manifest half runs at concurrency 1 (its geometry checks need a quiet page), so it dominates smoke wall time — and is exactly the half this shrinks.

Judgment call for review

The three checked-surface compact opt-outs (planReminders, planRemindersInspector, sessionContext) are the interpretive part: the check code takes the same branch as floor, but the DOM under it differs at 820px. If you weigh 820px as an independent geometry worth mounting, say so and I'll restore those three (matrix 48 → 54; the nine no-checks surfaces are the unambiguous bulk of the win).

cc @Astro-Han

[Astro-Han]

Thanks — this is a good reduction. The manifest should pay for additional viewport jobs only when those jobs prove a distinct contract.

I do not think the removed floor jobs need to be restored. The affected entries had no geometry checks, so another narrow mount would still pass if overflow, column layout, or containment regressed. Their story states continue to receive the catalog mount sweep. If a narrow layout becomes an important contract, the useful follow-up is a focused geometry assertion rather than restoring a mount-only viewport duplicate.

Two small P3 documentation cleanups:

• The ask-user-question story comment still says the manifest renders compact and floor variants, but this PR changes it to wide only.
• The PR description reports 92 → 48 manifest jobs; against this branch's parent manifest, the actual count is 90 → 46.

Neither needs to block the test reduction. The implementation and CI look good to merge. Thanks!