Bind fullscreen chrome to active tool name and description - PR 11.29

Author: DavidQ

docs/dev/codex_commands.md

@@ -1,34 +1,34 @@
 MODEL: GPT-5.3-codex
-REASONING: high
+REASONING: medium
 
 TASK:
-Apply PR 11.28.
-
-Starting from the current `4dc2b0f`-based recovery state, fix the remaining launch dependency issue:
-- Workspace Manager shows full sample 1902 workspace.
-- Vector Map can be clicked.
-- Vector Map opens but says palette is missing.
-- Most other palette-dependent tools are still grayed out.
-
-Do NOT restart the failed PR 11.23/11.25 approach.
-Do NOT collapse the workspace to palette-only.
-Do NOT add hardcoded or hidden fallback data.
-Do NOT require selectedAssetId, assetRegistry, or external file references when embedded payload exists.
-
-Required behavior:
-- Workspace Manager child launches must include or resolve shared workspace palette payload from the same sample-owned JSON already loaded for sample 1902.
-- `manifest.tools.palette` should satisfy the shared palette dependency for child tools.
-- `manifest.tools[toolId]` should satisfy the tool's own embedded payload dependency.
-- Palette-dependent tools should be enabled when both their own payload and the shared palette payload exist.
-- True utilities can remain N/A or disabled only with documented reason.
+Apply PR 11.29.
+
+Fix fullscreen chrome/title binding so entering fullscreen shows:
+
+<tool name> - <description>
+
+instead of:
+
+Configuration error (open title for details)
+
+Use the active tool's real manifest metadata. Do not hardcode individual tool names/descriptions.
+
+Do NOT:
+- change fullscreen enter/exit mechanics
+- change Workspace Manager payload fan-out
+- change button enablement
+- change sample 1902 data/schema
+- add hidden defaults or fallback sample data
+- touch start_of_day folders
 
 Implementation guidance:
-1. Find the child tool launch/context handoff code in tools/shared/platformShell.js or directly related Workspace Manager code.
-2. Find where Vector Map reports palette missing.
-3. Connect that missing dependency to the workspace manifest palette payload, not to a default or external asset.
-4. Adjust disabled-state logic so palette-dependent payload tools are not blocked when `manifest.tools.palette` exists.
-5. Keep palette fallback local to dependency satisfaction, not workspace tool-list selection.
-6. Add no broad refactor.
+1. Find the fullscreen title/header/chrome rendering path.
+2. Find where the configuration-error fallback is selected.
+3. Trace the active tool ID used when fullscreen is entered.
+4. Resolve tool display name and description from the same manifest/tool metadata source used by normal shell rendering.
+5. Only use configuration-error fallback when metadata is genuinely invalid/missing.
+6. Keep the change surgical.
 
 Validation:
 node --check tools/shared/platformShell.js
@@ -37,17 +37,17 @@ node ./tests/runtime/LaunchSmokeAllEntries.test.mjs --samples --sample-range=190
 Manual validation:
 Open sample 1902.
 Open Workspace Manager.
-Click Vector Map Editor.
-Confirm:
-- no missing palette message
-- vector map opens with palette context
-Return to Workspace Manager.
-Confirm palette-dependent tools with embedded payload are enabled/openable.
+Open a tool.
+Enter fullscreen.
+Confirm title area shows:
+<tool name> - <description>
+and not:
+Configuration error (open title for details)
 
 REPORT:
-Write docs/dev/reports/PR_11_28_validation.txt with:
+Write docs/dev/reports/PR_11_29_validation.txt with:
 - changed files
-- root cause of missing palette message
-- how shared palette handoff now works
-- which buttons remain disabled and why, if any
-- validation command results
+- root cause
+- metadata source used
+- validation commands/results
+- manual validation notes

docs/dev/commit_comment.txt

@@ -1 +1 @@
-Pass shared workspace palette to child tool launches - PR 11.28
+Bind fullscreen chrome to active tool name and description - PR 11.29

docs/dev/reports/PR_11_29_validation.txt

@@ -0,0 +1,32 @@
+PR 11.29 Validation Report
+
+Changed files:
+- tools/shared/platformShell.js
+- docs/dev/reports/PR_11_29_validation.txt
+
+Root cause:
+- Fullscreen summary text was built from `tool.name + tool.shortDescription` only.
+- Several valid registry entries expose reliable display metadata as `displayName + description` while `shortDescription` may be absent.
+- That strict `shortDescription` requirement triggered the fallback string `Configuration error (open title for details)` even when valid manifest metadata existed.
+
+Metadata source used:
+- Active tool metadata from the existing tool registry resolution path already used by the shell (`currentTool` from `getToolById(document.body.dataset.toolId)`).
+- Header binding now resolves title fields from:
+  - `displayName` (fallback `name`)
+  - `description` (fallback `shortDescription`)
+- No hardcoded per-tool name/description values were added.
+
+Validation commands/results:
+- node --check tools/shared/platformShell.js -> PASS
+- node ./tests/runtime/LaunchSmokeAllEntries.test.mjs --samples --sample-range=1902-1902 --tools -> PASS
+  - Summary: PASS=19 FAIL=0 TOTAL=19
+
+Manual validation notes:
+- Manual browser interaction cannot be fully executed in this CLI-only run.
+- Expected manual check path:
+  1) Open sample 1902
+  2) Open Workspace Manager
+  3) Open any tool
+  4) Enter fullscreen
+  5) Confirm summary/title shows `<tool name> - <description>` and not `Configuration error (open title for details)`
+- Code path updated specifically for fullscreen summary/title binding and leaves fullscreen mechanics/payload fan-out/button enablement unchanged.

docs/dev/reports/PR_11_29_validation_template.txt

@@ -0,0 +1,23 @@
+# PR 11.29 Validation
+
+Changed files:
+-
+
+Root cause:
+-
+
+Metadata source:
+-
+
+Before:
+- Fullscreen description showed Configuration error (open title for details).
+
+After:
+- Fullscreen shows <tool name> - <description>.
+
+Validation:
+- node --check tools/shared/platformShell.js
+- node ./tests/runtime/LaunchSmokeAllEntries.test.mjs --samples --sample-range=1902-1902 --tools
+
+Manual:
+- sample 1902 -> Workspace Manager -> open tool -> fullscreen

docs/pr/PR_11_29_FULLSCREEN_TOOL_TITLE_DESCRIPTION_BINDING.md

@@ -0,0 +1,49 @@
+# PR 11.29 — Fullscreen Tool Title / Description Binding
+
+## Purpose
+Fix fullscreen chrome display so it shows the active tool name and description instead of the configuration-error fallback.
+
+## Problem
+When entering fullscreen, the header/title area should display:
+
+<tool name> - <description>
+
+Instead, description currently shows:
+
+Configuration error (open title for details)
+
+## Required Change
+Bind fullscreen title/description to the active tool manifest metadata already available to Workspace Manager/platform shell.
+
+## Scope
+- Fix fullscreen display/chrome binding only.
+- Do not change fullscreen enter/exit behavior.
+- Do not change Workspace Manager payload fan-out.
+- Do not change tool enablement.
+- Do not change sample 1902 payload/schema.
+- Do not add hardcoded descriptions.
+- Do not add fallback sample/tool data.
+- Do not touch start_of_day folders.
+
+## Expected Behavior
+For any opened tool, fullscreen display should show:
+
+<tool display name> - <tool description>
+
+Example:
+Vector Map Editor - <Vector Map Editor manifest description>
+
+If description is truly missing from manifest metadata, show a safe empty description or documented neutral fallback, but do not show the configuration-error text when valid manifest metadata exists.
+
+## Investigation Targets
+- fullscreen header/chrome title rendering
+- active tool metadata lookup
+- tool manifest description resolver
+- configuration error fallback path
+
+## Acceptance
+- Entering fullscreen shows active tool name.
+- Entering fullscreen shows active tool description from manifest metadata.
+- The text "Configuration error (open title for details)" does not appear for tools with valid manifest description.
+- Fullscreen exit behavior remains unchanged.
+- Runtime smoke test passes.

tools/shared/platformShell.js

@@ -275,23 +275,24 @@ function buildToolHeaderIntroData(currentTool) {
     return null;
   }
 
-  const toolName = normalizeSingleLineText(currentTool?.name);
+  const toolName = normalizeSingleLineText(currentTool?.displayName) || normalizeSingleLineText(currentTool?.name);
   const toolShortDescription = normalizeSingleLineText(currentTool?.shortDescription);
   const toolDescription = normalizeSingleLineText(currentTool?.description);
-  const headerText = toolName && toolShortDescription
-    ? `${toolName} \u2014 ${toolShortDescription}`
-    : `Configuration error: ${toolId} header requires tool.name and tool.shortDescription in tools/toolRegistry.js.`;
+  const headerDescriptor = toolDescription || toolShortDescription;
+  const headerText = toolName && headerDescriptor
+    ? `${toolName} - ${headerDescriptor}`
+    : `Configuration error: ${toolId} header requires tool.displayName/tool.name and tool.description/tool.shortDescription in tools/toolRegistry.js.`;
   const introText = toolName && toolDescription
     ? `${toolName}: ${toolDescription}`
-    : `Configuration error: ${toolId} intro requires tool.name and tool.description in tools/toolRegistry.js.`;
-  const hasHeaderError = !(toolName && toolShortDescription);
+    : `Configuration error: ${toolId} intro requires tool.displayName/tool.name and tool.description in tools/toolRegistry.js.`;
+  const hasHeaderError = !(toolName && headerDescriptor);
   const hasIntroError = !(toolName && toolDescription);
   const diagnosticParts = [];
   if (hasHeaderError) {
-    diagnosticParts.push(`Configuration error: ${toolId} header requires tool.name and tool.shortDescription in tools/toolRegistry.js.`);
+    diagnosticParts.push(`Configuration error: ${toolId} header requires tool.displayName/tool.name and tool.description/tool.shortDescription in tools/toolRegistry.js.`);
   }
   if (hasIntroError) {
-    diagnosticParts.push(`Configuration error: ${toolId} intro requires tool.name and tool.description in tools/toolRegistry.js.`);
+    diagnosticParts.push(`Configuration error: ${toolId} intro requires tool.displayName/tool.name and tool.description in tools/toolRegistry.js.`);
   }
   const headerDisplayText = hasHeaderError
     ? `${toolName || toolId} \u2014 Configuration error (open title for details)`
@@ -1818,14 +1819,15 @@ function renderHeaderMarkup(currentTool, isHeaderExpanded) {
   const useStandardizedToolHeader = !isLanding
     && Boolean(currentTool?.id)
     && STANDARDIZED_TOOL_HEADER_IDS.has(currentTool.id);
-  const standardizedToolName = normalizeTextValue(currentTool?.name);
+  const standardizedToolName = normalizeTextValue(currentTool?.displayName) || normalizeTextValue(currentTool?.name);
   const standardizedToolShortDescription = normalizeTextValue(currentTool?.shortDescription);
   const standardizedToolHelpText = normalizeTextValue(currentTool?.description);
-  const hasStandardizedHeaderConfig = Boolean(standardizedToolName && standardizedToolShortDescription);
+  const standardizedHeaderDescriptor = standardizedToolHelpText || standardizedToolShortDescription;
+  const hasStandardizedHeaderConfig = Boolean(standardizedToolName && standardizedHeaderDescriptor);
   const hasStandardizedIntroConfig = Boolean(standardizedToolName && standardizedToolHelpText);
   const standardizedHeaderText = hasStandardizedHeaderConfig
-    ? `${standardizedToolName} \u2014 ${standardizedToolShortDescription}`
-    : `Configuration error: ${currentTool?.id || "tool"} header requires tool.name and tool.shortDescription in tools/toolRegistry.js.`;
+    ? `${standardizedToolName} - ${standardizedHeaderDescriptor}`
+    : `Configuration error: ${currentTool?.id || "tool"} header requires tool.displayName/tool.name and tool.description/tool.shortDescription in tools/toolRegistry.js.`;
   const standardizedIntroText = hasStandardizedIntroConfig
     ? `${standardizedToolName}: ${standardizedToolHelpText}`
     : `Configuration error: ${currentTool?.id || "tool"} intro requires tool.name and tool.description in tools/toolRegistry.js.`;