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

* 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>

* fix(nav): the admin entry is not called Settings, because the foldout already is

gate-63 caught the label I chose. ADR-079 reserves `settings`, `appsettings` and
`app settings` for a settings-foldout entry, because NcAppNavigation's foldout is
ITSELF labelled "Settings" — an entry by that name renders as Settings >
Settings, which is the duplication ADR-079 D1 removed a whole menu to stop.

Replacing the raw `launchpad.menu.adminSettings` key with "Settings" walked
straight into it. "Admin settings" says where the entry goes — it redirects to
/settings/admin/launchpad — and is not reserved.

⚠️ FOLLOW-UP, NOT SILENTLY FIXED HERE: this entry now carries the same label as
the one nc-vue's shared chrome already renders, and both lead to the same admin
page. ADR-079 D1's precedent says an in-app duplicate of the Nextcloud admin
settings page should go, not be renamed. Removing a menu surface is a product
decision rather than a gate fix, so it is named here instead of taken.

Verified locally: gate-63 reports `checked 2 manifest(s): 0 failure(s)`, 682
unit tests pass, webpack build clean.

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

* fix(l10n): the new admin label has a Dutch key, so it does not render English

gate-102 caught what my last commit deferred, and it was right to: a manifest
string with no `l10n/nl.json` key renders its English source to a Dutch user, and
nothing else reports it. `check:l10n-js` compares nl.json to nl.js, and a string
absent from BOTH is in sync.

⚠️ CORRECTION TO THAT COMMIT MESSAGE. It said Dutch loses a translation it only
ever had for these six labels. That was wrong, and the gate is what measured it:
five of the six English strings I introduced — Dashboards, Templates, Settings,
Dashboard — were ALREADY keys in nl.json, so replacing the dotted i18n keys cost
Dutch nothing there. Only "Admin settings" was new, because only that label had
no prior English form to have been catalogued under.

So there is no follow-up owed for the other five, and the one that was genuinely
missing is added rather than noted: "Beheerinstellingen", matching the file's own
"Instellingen > Beheer" and "beheerder".

Verified locally: gate-102 `checked 51 manifest string(s)` with no findings,
gate-63 `0 failure(s)`, prettier clean, 682 unit tests pass.

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

---------

Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: 3 people

l10n/en.json

@@ -1065,6 +1065,7 @@
         "AI insight unavailable — the local LLM source is not configured": "AI insight unavailable — the local LLM source is not configured",
         "Generate insight": "Generate insight",
         "Total spend: {amount}": "Total spend: {amount}",
-        "Features & roadmap": "Features & roadmap"
+        "Features & roadmap": "Features & roadmap",
+        "Admin settings": "Admin settings"
     }
 }

l10n/nl.json

@@ -1135,6 +1135,7 @@
         "Version": "Versie",
         "How many dashboards there are, and who they belong to.": "Hoeveel dashboards er zijn, en van wie ze zijn.",
         "Store": "Store",
-        "Install dashboard configurations that other organisations have published: a set of tiles, a layout, or the flows behind them.": "Installeer registers, schema's en flows die andere organisaties hebben gepubliceerd."
+        "Install dashboard configurations that other organisations have published: a set of tiles, a layout, or the flows behind them.": "Installeer registers, schema's en flows die andere organisaties hebben gepubliceerd.",
+        "Admin settings": "Beheerinstellingen"
     }
 }

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": "Admin 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": "Admin 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 () => {