feat: enhance GitHub release handling and version update notifications

- Added updated_at field to GitHub release data in tests.
- Implemented edge release lookup prioritization and fallback mechanisms.
- Extended VersionUpdateView to include latestStablePublishedAt and latestEdgePublishedAt.
- Updated incoming webview message validation to handle new message types.
- Introduced tests for approval mode synchronization and incoming webview settings.
- Created versionUpdates.ts to manage version comparison and update notifications.
- Added logic to build version update views and notification keys based on release data.

Author: goodguy1963

.github/agents/ceo.agent.md

@@ -3,12 +3,16 @@ description: Strategic orchestrator that keeps session to-dos, Todo Cockpit, and
 name: CEO
 argument-hint: Ask me to coordinate work, review a direction, route to specialists, or evolve the repo's agent system.
 model: GPT-5.4 (copilot)
-tools: [vscode/memory, execute/runNotebookCell, execute/executionSubagent, execute/getTerminalOutput, execute/killTerminal, execute/sendToTerminal, execute/runTask, execute/createAndRunTask, read/readFile, agent/runSubagent, search/codebase, search/listDirectory, search/textSearch, scheduler/cockpit_get_board, tavily/tavily_crawl, tavily/tavily_extract, tavily/tavily_map, tavily/tavily_research, tavily/tavily_search, prefab/render_ui, todo]
+tools: [vscode/memory, read/readFile, agent/runSubagent, search/codebase, search/listDirectory, search/textSearch, scheduler/cockpit_get_board, tavily/tavily_crawl, tavily/tavily_extract, tavily/tavily_map, tavily/tavily_research, tavily/tavily_search, prefab/render_ui, todo]
 handoffs:
   - label: Plan Work
     agent: Planner
     prompt: "Create an implementation plan for this request and hand back the smallest safe execution path."
     send: false
+  - label: Deep Research
+    agent: Planner
+    prompt: "Conduct evidence-heavy external research (web, Perplexity, browser, Tavily) to establish facts before planning. Anchor findings in repo evidence first, then widen to external sources. Separate repo facts from external assumptions and return a compact evidence map before proposing a plan."
+    send: false
   - label: Handle Prefab UI
     agent: Prefab UI Specialist
     prompt: "Handle this Prefab UI, rendering, or wire-format request through the prefab-ui skill and the live Prefab surface. Prefer live rendering with prefab/render_ui when available, then report back with validation or blockers."
@@ -57,7 +61,7 @@ You are the top-level orchestrator for this repository.
 - **Never use the terminal, run tasks, or execute code directly.** If your own tools or scope are insufficient for a task — including terminal access, script execution, file edits, or running tests — delegate it to a suitable specialist instead of attempting it yourself. Treat any missing tool or execution surface as a routing signal, never a reason to stop.
 - Prefer repo-local specialists that already exist in `.github/agents`.
 - Use `Prefab UI Specialist` for live Prefab rendering, Prefab UI JSON, dashboards, forms, charts, settings panels, and API-backed Prefab view requests.
-- Use `Planner` when architecture, sequencing, or validation is unclear.
+- Use `Planner` for architecture, sequencing, or validation questions — and always route research-first or evidence-heavy requests (deep dives, competitive analysis, market research) through `Planner` or `Deep Research` so the stronger evidence standard is applied.
 - Use `Remediation Implementer` for approved bounded code changes that do not need broader architecture work.
 - Use `Remediation Implementer` for validation-only passes when a returned run must be checked before closeout.
 - Use `Documentation Specialist` for docs, guides, and knowledge-base alignment.
@@ -85,9 +89,9 @@ You are the top-level orchestrator for this repository.
   - delegate directly to an existing specialist when the path is clear
   - **never use the terminal, run tasks, or execute code directly — treat any missing tool or execution surface as a routing signal to a specialist, not a reason to attempt it yourself**
   - use `Prefab UI Specialist` when the request is mainly about live Prefab rendering, Prefab UI JSON, dashboards, forms, charts, settings panels, or API-backed Prefab views
-  - use `Planner` first when tradeoffs, architecture, or sequencing are unclear
-  - use `Remediation Implementer` for approved bounded implementation work
-  - use `Validate Run` through `Remediation Implementer` when returned work needs an explicit validation pass before closeout
+  - use `Planner` first when tradeoffs, architecture, sequencing, or validation is unclear — or when the request is research-first or evidence-heavy (deep dive, competitive analysis, market research)
+  - use `Planner` for approved bounded implementation work
+  - use `Validate Run` through `Remediation Implementer` when returned work needs an explicit closeout check against acceptance criteria — not when Planner or the implementing specialist already ran validation
   - use `Documentation Specialist` when documentation or knowledge alignment is the main task
   - use `Cockpit Todo Expert` first when Todo Cockpit cards, approvals, task drafts, or Task List entries need durable attention
   - use `Custom Agent Foundry` first when capability is missing

.github/agents/system/README.md

@@ -39,7 +39,7 @@ Source-of-truth rules:
 Recommended pattern:
 
 1. Let `CEO` coordinate the request.
-2. Use `Planner` for architecture and sequencing.
+2. Use `Planner` for architecture, sequencing, and evidence-heavy external research (deep dives, competitive analysis, market research).
 3. Use `Remediation Implementer` for approved bounded code changes.
 4. Use `Documentation Specialist` when docs or knowledge need alignment.
 5. Use `Cockpit Todo Expert` for persistent board updates, Task List todo coordination, and approval routing.

.github/agents/system/TEAM-RULES.md

@@ -21,8 +21,9 @@ These starter agents follow the same operating rules across repositories.
 
 ## Orchestration Boundary
 
-- `CEO` is the orchestrator and decision layer.
+- `CEO` is the orchestrator and decision layer. It delegates execution rather than performing it directly.
 - Orchestrators must treat personal tool or scope limits as a routing signal and delegate when a suitable specialist exists.
+- `Planner` owns evidence-heavy external research and is the correct route for research-first requests (deep dives, competitive analysis, market research) so that its stronger evidence standard is applied.
 - `Documentation Specialist` owns doc accuracy and shared knowledge hygiene.
 - `Cockpit Todo Expert` owns Todo Cockpit persistence, approval-state mutations, and linked Task List todo coordination.
 - Implementation specialists other than `Cockpit Todo Expert` should not mutate Cockpit board state directly unless that is their explicit role.

README.md

@@ -38,7 +38,9 @@ That structure keeps the LLM as the native execution chat surface while Copilot
 
 ## 🎬 Demo
 
-[![Watch the Copilot Cockpit intro video](https://raw.githubusercontent.com/goodguy1963/Copilot-Cockpit/main/images/DEMO%20v2.gif)](https://www.youtube.com/watch?v=yiJCmwmxEFc)
+[![Watch the Copilot Cockpit intro video](https://raw.githubusercontent.com/goodguy1963/Copilot-Cockpit/main/images/DEMO%20v2.gif)](https://youtu.be/yiJCmwmxEFc?si=TFf5vLOhTtcSASg3&t=197)
+
+Direct video link: [Watch the intro video](https://youtu.be/yiJCmwmxEFc?si=TFf5vLOhTtcSASg3&t=197).
 
 Use the feature tour below for the slower tab-by-tab explanation.
 
@@ -215,12 +217,12 @@ If you want the optional integration layers, the practical order is:
 1. Get the core `Todo` -> `Research` -> `Task` or `Job` loop working first.
 2. Use `Set Up MCP` to create or repair `.vscode/mcp.json` and activate the repo-local scheduler MCP server for this workspace.
 3. Add any separate third-party MCP servers you want, such as Tavily, Perplexity, or [Prefab by Max Health Inc.](https://github.com/Max-Health-Inc/prefab), to that same workspace MCP config. Those servers are separate from Copilot Cockpit's scheduler server and may need their own API keys or provider-specific setup.
-4. Use `Sync Bundled Skills` to write the bundled Copilot skills into `.github/skills` once you want stronger repo-local guidance for how Copilot should approach work. If the Prefab by Max Health Inc. MCP server is configured, that bundled path also adds the `prefab-ui` skill so installed users can route Prefab by Max Health Inc. UI and wire-format work through the shipped contract instead of keeping it as a repo-only extra.
-5. Add the optional agent layer only if you want a specialist or orchestrator setup on top of the core workflow.
+4. Optionally, but recommended if you want the full repo-local Copilot guidance layer, use `Sync Bundled Skills` to write the bundled Copilot skills into `.github/skills`. If the Prefab by Max Health Inc. MCP server is configured, that bundled path also adds the `prefab-ui` skill so installed users can route Prefab by Max Health Inc. UI and wire-format work through the shipped contract instead of keeping it as a repo-only extra.
+5. Add the optional bundled-agent layer only if you want a specialist or orchestrator setup on top of the core workflow: use `Stage Bundled Agents` for a compare-first mirror under `.vscode/copilot-cockpit-support/bundled-agents`, or `Sync Bundled Agents` for the live install path into `.github/agents`.
 
-`Sync Bundled Skills` is optional, but it is a good next step once the core loop is working because those repo-local skills shape how Copilot approaches planning, routing, and execution in this repo without changing the underlying task model. If you also use Codex, the separate `Add MCP To Codex` and `Add Skills To Codex` actions configure the Codex-side files, but the main setup path in this repo is still Copilot-first.
+`Sync Bundled Skills` remains optional, but it is the recommended next step once the core loop is working if you want the full shipped guidance layer, because those repo-local skills shape how Copilot approaches planning, routing, and execution in this repo without changing the underlying task model. If you also use Codex, the separate `Add MCP To Codex` and `Add Skills To Codex` actions configure the Codex-side files, but the main setup path in this repo is still Copilot-first.
 
-For agents, start by deciding whether you want a compare-first preview or a live install. `Stage Bundled Agents` creates a staged mirror under `.vscode/copilot-cockpit-support/bundled-agents` and leaves the live repo-local system untouched, which makes it the safer starting point. `Sync Bundled Agents` installs the bundled starter pack into live `.github/agents` files when you want the optional specialist layer active in the repo. When the Prefab by Max Health Inc. MCP server is part of your workspace setup, that shipped agent path also includes `Prefab UI Specialist` as the focused router for Prefab by Max Health Inc. UI, renderer, and API-backed view work. Treat any existing repo-local agent setup as user-owned first. Use stage-first when the repo already has a richer local system, and only approve sync when you want the live install path. Back up `.github` first when it already exists, and keep in mind that customized workspace copies are skipped so your repo-specific agent edits are not overwritten.
+For agents, start by deciding whether you want a compare-first preview or a live install. `Stage Bundled Agents` creates a staged mirror under `.vscode/copilot-cockpit-support/bundled-agents` and leaves the live repo-local system untouched, which makes it the safer starting point. `Sync Bundled Agents` installs the bundled starter pack into live `.github/agents` files when you want the optional specialist layer active in the repo. When the Prefab by Max Health Inc. MCP server is part of your workspace setup, that shipped agent path also includes `Prefab UI Specialist` as the focused router for Prefab by Max Health Inc. UI, renderer, and API-backed view work. Treat any existing repo-local agent setup as user-owned first. Use stage-first when the repo already has a richer local system, and only approve sync when you want the live install path. Back up `.github` first when it already exists, and keep in mind that customized workspace copies are skipped so your repo-specific agent edits are not overwritten rather than being force-synced.
 
 If you want the live bundled-agent workflow, enable custom subagents in GitHub Copilot settings with `chat.customAgentInSubagent.enabled` before relying on that layer.
 
@@ -289,7 +291,13 @@ npm run install:vsix:insiders
 npm run install:vsix:both
 ```
 
-After installation, the extension creates or repairs repo-local support files for the current workspace.
+After you install and open the extension in a workspace, start with the core workflow in the cockpit UI. If you want the full repo-local MCP, skills, and bundled-agent system, the recommended setup order is:
+
+1. Run `Set Up MCP` to create or repair `.vscode/mcp.json` for the workspace scheduler server.
+2. Optionally, but recommended when you want the full repo-local guidance layer, run `Sync Bundled Skills` to write the bundled Copilot skills into `.github/skills`.
+3. Choose the bundled-agent path that fits your repo: `Stage Bundled Agents` writes a compare-first mirror under `.vscode/copilot-cockpit-support/bundled-agents`, while `Sync Bundled Agents` installs the live starter-pack files into `.github/agents`.
+
+Those setup steps are manual by design. Copilot Cockpit does not auto-sync or blindly overwrite an existing repo-local skills or agent system.
 
 ## 🗂️ Key Files
 

docs/feature-tour.md

@@ -24,7 +24,9 @@ This page mixes one live demo reference with illustrative SVG mockups for the ta
 
 Current overview reference for `S1`:
 
-[![Watch the Copilot Cockpit intro video](../images/DEMO%20v2.gif)](https://www.youtube.com/watch?v=yiJCmwmxEFc)
+[![Watch the Copilot Cockpit intro video](../images/DEMO%20v2.gif)](https://youtu.be/yiJCmwmxEFc?si=TFf5vLOhTtcSASg3&t=197)
+
+Direct video link: [Watch the intro video](https://youtu.be/yiJCmwmxEFc?si=TFf5vLOhTtcSASg3&t=197).
 
 This intro video remains the current broad product overview for the docs. The tab-specific visuals below are illustrative SVG mockups for documentation, not live screenshots.
 

docs/getting-started.md

@@ -80,7 +80,9 @@ npm run install:vsix:both
 
 ## Demo
 
-[![Watch the Copilot Cockpit intro video](../images/DEMO%20v2.gif)](https://www.youtube.com/watch?v=yiJCmwmxEFc)
+[![Watch the Copilot Cockpit intro video](../images/DEMO%20v2.gif)](https://youtu.be/yiJCmwmxEFc?si=TFf5vLOhTtcSASg3&t=197)
+
+Direct video link: [Watch the intro video](https://youtu.be/yiJCmwmxEFc?si=TFf5vLOhTtcSASg3&t=197).
 
 Use [Feature Tour](./feature-tour.md) for the slower tab-by-tab explanation.
 

docs/github-integration.md

@@ -121,6 +121,14 @@ When a GitHub-sourced Todo enters `needs-bot-review`, the launched review prompt
 - The saved GitHub automation prompt as an explicit GitHub-specific instruction block.
 - Pull-request branch and security preflight when the source item is a pull request.
 
+The Settings tab `Search provider` and `Research provider` fields apply here. They do not change the extension's general runtime or switch a global fetch backend by themselves. Instead, they change the default generated guidance inside the `needs-bot-review` planning prompt:
+
+- `Search provider` tells the prompt which lightweight external search option to mention for quick lookups.
+- `Research provider` tells the prompt which deeper follow-up research option to mention only after built-in and local URL checks have already run first.
+- `None` for `Research provider` keeps that deeper-research guidance on built-in and local tooling only.
+
+In other words, the workflow still starts with built-in/local URL inspection, and these settings only change what the default review prompt recommends if more external search or grounding is needed after that.
+
 ### Pull Request Security-First Preflight
 
 For pull-request sourced handoffs, Copilot Cockpit adds a dedicated preflight block before implementation work:

docs/workflows.md

@@ -13,6 +13,7 @@ The default path is: start with a `Todo`, use `Research` when context is missing
 - GitHub-sourced cards persist source metadata so repeat imports reuse and refresh the same Todo instead of creating duplicates.
 - Built-in workflow flags include `new`, `needs-bot-review`, `needs-user-review`, `ready`, `ON-SCHEDULE-LIST`, and `FINAL-USER-CHECK`.
 - Saving a todo into `ready` can create or reopen its linked task draft so execution prep stays adjacent to the approval step.
+- The Settings tab `Search provider` and `Research provider` options only change the default guidance generated for the `needs-bot-review` prompt; built-in/local URL checks still happen first. See [GitHub Integration](./github-integration.md).
 
 ## GitHub Triage Loop