fix(shell): compose the runtime manifest instead of replacing the app's own

Reproduced on a clean instance rather than reasoned about, and the finding is
worse than the 13 failing tests suggested: with tier 3, launchpad rendered
NOTHING on a fresh install. `#workspace-vue` held 7 bytes, an empty comment,
against 43,564 for the same instance on the commit before tier 3.

`GET /api/manifest` is not this app's manifest. ManifestController says so in
its own docblock: it assembles a document from the user's OpenRegister dashboard
objects, one page and one menu entry per dashboard, and "when the user has no
dashboards the manifest returns empty pages/menu".

App.vue read `runtimeManifest?.value ?? this.manifest`. An empty object is
truthy, so a user with no dashboards got a manifest with no pages and no menu,
and tier 3 builds both the router and the nav from the manifest. A user WITH
dashboards was no better off, only less obviously: the runtime document still
replaced the nine declared pages, the ADR-114 footer and the walkthrough, which
is what the chrome and routing specs have been failing on.

So the two are composed, which is what each is for. The bundled manifest owns
the declared surfaces; the runtime one contributes the dashboards only the
server knows about, and the live `runtime` block.

THE SETUP WIZARD CAME WITH CnAppRoot, and nothing accounted for it. CnAppRoot
opens CnSetupWizard while ANY step is outstanding, optional or not
(nextcloud-vue#806) — and `completed` is not `settled`: the status endpoint
answered `"completed": true` while still reporting `demo-data` and
`load-demo-data` as `done: false`. `cn-wizard-dialog` is an aria-modal that
intercepts pointer events, so every click landed on it. Measured locally: with
the wizard up, dashboard-sharing failed 4 of 4; with the choice recorded,
runtime-shell-canEdit and add-widget-modal ran 10 passed, 0 failed. globalSetup
now records the choice once, because the marker is per user and settling it per
spec makes the suite order-dependent.

Three manifest references could never resolve. The `dashboards` menu entry and
two walkthrough steps pointed at `dashboard-detail`, whose path is
`/dashboards/:id`, so vue-router threw `Missing required param "id"` on every
render. They were inert until tier 3 gave the manifest a real router. A third
step named the `Flows` PAGE where a menu-entry id belongs.

Six labels were raw i18n keys. `launchpad.menu.dashboards` and five others
render as the key itself in all 36 locales but Dutch, which is the only one
carrying them. They are plain English now, like every other entry in this menu
already was. Dutch loses a translation it only ever had for these six; that is
the same position `Flows`, `Store` and `Reports` are already in, and worth a
follow-up for all of them together rather than a special case for these.

682 unit tests pass. The development push run is the E2E proof, since that leg
does not run on a pull request.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: Conduction Release Bot

src/App.vue

@@ -129,7 +129,58 @@ export default {
 		 * @spec openspec/changes/launchpad-manifest-tier-3/specs/manifest-routing/spec.md#requirement-req-route-004-the-shared-chrome-renders-with-the-workspace-inside-it
 		 */
 		liveManifest() {
-			return this.runtimeManifest?.value ?? this.manifest
+			const runtime = this.runtimeManifest?.value
+			if (!runtime) {
+				return this.manifest
+			}
+
+			/*
+			 * MERGED, NOT REPLACED, and the difference is the whole app.
+			 *
+			 * `/api/manifest` is NOT this app's manifest. ManifestController
+			 * says so in its own docblock: it assembles a document from the
+			 * user's OpenRegister dashboard objects, one `type: "dashboard"`
+			 * page and one menu entry per dashboard, and "when the user has no
+			 * dashboards the manifest returns empty pages/menu".
+			 *
+			 * This used to be `runtime ?? this.manifest`. An empty object is
+			 * truthy, so a user with no dashboards got a manifest with NO pages
+			 * and NO menu — and since `launchpad-manifest-tier-3` builds the
+			 * router and the nav FROM the manifest, the app rendered nothing at
+			 * all. Measured on a clean install: `#workspace-vue` held 7 bytes,
+			 * an empty comment, against 43,564 for the same instance before the
+			 * tier-3 adoption.
+			 *
+			 * A user WITH dashboards was no better off, only less obviously:
+			 * the runtime document still replaced the nine declared pages, the
+			 * ADR-114 footer and the walkthrough, which is what the chrome and
+			 * routing specs were failing on.
+			 *
+			 * So the two are composed, which is what each is for. The bundled
+			 * manifest owns the app's declared surfaces; the runtime one
+			 * contributes the dashboards that only the server can know about,
+			 * and the live `runtime` block.
+			 */
+			const byId = (entries) => {
+				const seen = new Map()
+				for (const entry of entries) {
+					if (entry && entry.id !== undefined) {
+						seen.set(entry.id, entry)
+					}
+				}
+				return [...seen.values()]
+			}
+
+			return {
+				...this.manifest,
+				...(runtime.runtime ? { runtime: runtime.runtime } : {}),
+				pages: byId([
+					...(this.manifest.pages ?? []),
+					...(runtime.pages ?? []),
+				]),
+
+				menu: byId([...(this.manifest.menu ?? []), ...(runtime.menu ?? [])]),
+			}
 		},
 	},
 }

src/manifest.json

@@ -96,22 +96,22 @@
   "menu": [
     {
       "id": "dashboards",
-      "label": "launchpad.menu.dashboards",
+      "label": "Dashboards",
       "icon": "ViewDashboardOutline",
-      "route": "dashboard-detail",
+      "route": "Workspace",
       "section": "main"
     },
     {
       "id": "admin-templates",
-      "label": "launchpad.menu.adminTemplates",
+      "label": "Templates",
       "icon": "FileReplaceOutline",
       "route": "/admin/templates",
       "section": "settings",
       "permission": "admin"
     },
     {
       "id": "admin-settings",
-      "label": "launchpad.menu.adminSettings",
+      "label": "Settings",
       "icon": "CogOutline",
       "route": "/admin/settings",
       "section": "settings",
@@ -183,7 +183,7 @@
       "id": "dashboard-detail",
       "route": "/dashboards/:id",
       "type": "custom",
-      "title": "launchpad.pages.dashboard",
+      "title": "Dashboard",
       "_note": "type:custom for the same reason as Workspace: this is the grid addressed by dashboard id, not a declarative dashboard page. The :id selects the active dashboard (dashboard-deeplinking).",
       "widgets": [],
       "config": {
@@ -195,7 +195,7 @@
       "id": "admin-templates-index",
       "route": "/admin/templates",
       "type": "custom",
-      "title": "launchpad.pages.adminTemplates",
+      "title": "Templates",
       "component": "AdminSettingsRedirect",
       "_note": "REDIRECTS to /settings/admin/launchpad. TemplatesPage is a TAB inside the Nextcloud admin section, not a page of its own; routing it in-app would render half an admin surface next to the real one.",
       "config": {
@@ -206,7 +206,7 @@
       "id": "admin-settings",
       "route": "/admin/settings",
       "type": "custom",
-      "title": "launchpad.pages.adminSettings",
+      "title": "Settings",
       "component": "AdminSettingsRedirect",
       "_note": "REDIRECTS to /settings/admin/launchpad. The admin surface is a Nextcloud settings section (lib/Settings/LaunchPadAdmin.php, mounted by src/admin.js), not an in-app page — the component this once named, AdminSettingsPage, has never existed. The route resolves so the menu entry is not a dead link, and lands where the functionality is."
     },
@@ -491,7 +491,7 @@
             "body": "A short tour of the main screens. It takes under a minute, and you can close it at any point and pick it up again from the help menu.",
             "target": {
               "kind": "page",
-              "ref": "dashboard-detail"
+              "ref": "Workspace"
             },
             "advanceOn": {
               "type": "manual"
@@ -504,11 +504,11 @@
             "task": "Click Dashboards in the menu",
             "target": {
               "kind": "nav-item",
-              "ref": "dashboard-detail"
+              "ref": "dashboards"
             },
             "advanceOn": {
               "type": "route-match",
-              "route": "dashboard-detail"
+              "route": "Workspace"
             }
           },
           {
@@ -518,7 +518,7 @@
             "task": "Open Flows from the menu",
             "target": {
               "kind": "nav-item",
-              "ref": "Flows"
+              "ref": "FlowsMenu"
             },
             "advanceOn": {
               "type": "route-match",

tests/e2e/global-setup.ts

@@ -120,6 +120,7 @@ export default async function globalSetup(config: FullConfig): Promise<void> {
 
 	await dismissFirstRunWizard(page)
 	await markSupportNoteSeen(page)
+	await settleSetupWizard(page)
 
 	// Persist the storage state so individual specs reuse the session.
 	/*
@@ -218,6 +219,66 @@ export default async function globalSetup(config: FullConfig): Promise<void> {
  * @param {import('@playwright/test').Page} page an authenticated page.
  * @return {Promise<void>}
  */
+/**
+ * Record the setup wizard's outstanding choice, so it does not open over the app.
+ *
+ * ⚠️ COMPLETED IS NOT THE SAME AS SETTLED, and that distinction is the whole
+ * bug. `GET /api/setup/status` answered `"completed": true` while still
+ * reporting `steps: { "demo-data": { done: false }, "load-demo-data":
+ * { done: false } }`, and `CnAppRoot` opens the wizard while ANY step is
+ * outstanding, optional or not (nextcloud-vue#806). So the wizard opened on a
+ * setup that called itself complete.
+ *
+ * It is not a cosmetic overlay. `cn-wizard-dialog` is an `aria-modal` that
+ * INTERCEPTS POINTER EVENTS, so every click in the app lands on the dialog and
+ * the failure names a button that the same log calls visible, enabled and
+ * stable. Measured locally against a clean instance: with the wizard up,
+ * dashboard-sharing failed 4 of 4; with it settled, runtime-shell-canEdit and
+ * add-widget-modal went to 10 passed, 0 failed.
+ *
+ * This app had no wizard at all until `launchpad-manifest-tier-3` rooted it on
+ * `CnAppRoot`, which is why nothing here had to account for one before.
+ *
+ * Recording the CHOICE is what settles it, not writing the completion key: the
+ * choice is what marks both `demo-data` and its dependent `load-demo-data`
+ * done. `none` is the honest answer for a test run, and it imports nothing.
+ *
+ * @param page A page already authenticated against the instance.
+ */
+async function settleSetupWizard(page: Page): Promise<void> {
+	try {
+		const status = await page.evaluate(async () => {
+			const token =
+				document
+					.querySelector('head[data-requesttoken]')
+					?.getAttribute('data-requesttoken')
+				?? document.getElementById('requesttoken')?.getAttribute('value')
+				?? ''
+			const res = await fetch('/index.php/apps/launchpad/api/setup/config', {
+				method: 'POST',
+				headers: {
+					'Content-Type': 'application/json',
+					requesttoken: token,
+					'OCS-APIRequest': 'true',
+				},
+				body: JSON.stringify({ demo_dataset: 'none' }),
+			})
+			return res.status
+		})
+		if (status >= 400) {
+			console.warn(
+				`[playwright globalSetup] setup-wizard settle returned ${status}; `
+					+ 'specs will hit a wizard mask over every click.',
+			)
+		}
+	} catch (error) {
+		console.warn(
+			'[playwright globalSetup] could not settle the setup wizard:',
+			error,
+		)
+	}
+}
+
 async function markSupportNoteSeen(page: Page): Promise<void> {
 	try {
 		const status = await page.evaluate(async () => {