copilot-tap-extension 2.0.5 → 2.0.6

package/README.md

@@ -30,6 +30,7 @@ Background commands and agent prompts produce output line by line. An EventFilte
 - You poll an API or dashboard and want the agent to react when something changes.
 - You re-ask the same prompt periodically and want it on a timer or running whenever idle.
 - You build external tools in any language and want them available inside Copilot without touching the SDK.
+- You want a live visual flight recorder for tap streams, emitters, provider state, logs, and session events.
 
 ## Get started
 
@@ -115,6 +116,8 @@ Once inside the session, describe what you want in natural language. You can als
 
 > _"Tail the API logs, inject errors, drop health checks"_
 
+> _"Open the tap diagnostics canvas"_
+
 The agent translates these into emitter and filter configurations behind the scenes.
 
 ## How it works
@@ -239,6 +242,12 @@ The recommended approach is a **keep-all bootstrap**: start with no EventFilter
 
 Rules can be added or changed while the emitter is running. You never need to restart it to adjust filtering.
 
+**Inspect tap with a live diagnostics canvas**
+
+Use the `tap_open_diagnostics_canvas` tool to open a local canvas that shows tap's retained EventStreams, emitter state, provider gateway state, injection queue, runtime logs, and recent session events in one place.
+
+The canvas is bounded and redacted: it keeps recent diagnostic evidence without exposing provider auth tokens or unbounded transcript payloads.
+
 ## Repo layout
 
 ```text
@@ -276,6 +285,7 @@ PLAN.md                         # ubiquitous language and design decisions
 | [Reference](./docs/reference.md) | Look up tool parameters, config fields, or the event pipeline |
 | [Provider guide](./docs/providers.md) | Add external tools to Copilot via the WebSocket provider interface |
 | [Use cases and patterns](./docs/use-cases.md) | Recipes for deploy watchers, PR monitors, log tailers, and more |
+| [Copilot SDK canvas surfaces](./docs/recipes/copilot-sdk-canvas.md) | Local SDK findings for extension-owned canvas UI surfaces |
 | [Evals](./docs/evals.md) | Run or extend the automated test suite |
 | [Copilot instructions](./src/copilot-instructions.md) | Understand or customize how the agent uses this extension |
 | [Implementation plan](./PLAN.md) | Ubiquitous language and naming conventions for contributors |

package/dist/copilot-instructions.md

@@ -170,6 +170,10 @@ When working on the extension itself, not just using its emitter tools, prefer t
 - use `session.send()` for asynchronous follow-up prompts and `session.sendAndWait()` only when the extension must wait for an answer
 - use `onPermissionRequest` and `onUserInputRequest` for guarded flows instead of custom ad hoc prompting
 - use `fs.watch` or `watchFile` when the extension should react to manual file edits or workspace artifacts such as `plan.md`
+- use `createCanvas` with `joinSession({ canvases: [...] })` for extension-owned UI panels when text-only EventStreams are not enough; `open()` returns `title`, `status`, and a renderer `url`, actions power `invoke_canvas_action`, and per-instance state should be keyed by `instanceId`
+- treat canvas support as experimental: action names must not start with `canvas.`, guard optional host canvas capabilities, prefer loopback HTTP renderers on ephemeral ports, and clean them up in `onClose`
+- remember that external tap providers cannot declare Copilot SDK canvases over the current WebSocket protocol; implement canvases in the extension layer or explicitly extend the gateway protocol first
+- open the built-in `tap-diagnostics` canvas with `tap_open_diagnostics_canvas` when users ask to inspect tap internals, diagnostics, logs, stream history, provider state, or "everything tap is doing"
 
 Good non-emitter examples to adapt into this repo:
 
@@ -177,6 +181,7 @@ Good non-emitter examples to adapt into this repo:
 - watch a config file and refresh the corresponding emitter when the user edits it
 - add a helper tool that fetches one-shot data from an API while emitters continue to watch background streams
 - log EventFilter updates and emitter lifecycle events to the timeline for observability
+- add a canvas dashboard for stream/emitter inspection when a workflow benefits from a persistent visual surface
 
 ## What not to do