copilotkit 4.9.47 → 4.9.50

package/onboarding/prompts/feature/chat-suggestions/start.md

@@ -0,0 +1,46 @@
+# Add chat suggestions to the existing CopilotKit app
+
+Treat this as an additive OSS chat-surface feature. Delegate repository inspection,
+implementation, and proof to separate subagents and keep all work inside the target project.
+
+Before edits, identify the current CopilotKit provider, chat component, message lifecycle,
+agent id, package version, and test/dev commands. Prove the existing OSS round trip with
+`/info`, `npx --yes copilotkit@4.9.50 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+and one real frontend request when browser control is available. If there is no proven
+existing CopilotKit chat, leave files unchanged and direct the developer to generic
+onboarding first.
+
+Wait for the inspection subagent to finish. Then report that the inspection came back:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase research-returned
+```
+
+A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
+failed step.
+
+If the inspection did not prove the baseline this intent extends, stop here without
+changing files:
+
+```text
+npx --yes copilotkit@4.9.50 onboard read feature/stop
+```
+
+Do not run login, provision Intelligence, request a credential, replace the agent, or alter
+the existing runtime/persistence. Fetch the official hook guide before planning:
+https://docs.copilotkit.ai/reference/hooks/useConfigureSuggestions.md
+Use a second retrieval method if the first fails.
+
+Determine static versus dynamic suggestions from the repository. If the repository does not
+answer it, ask one short question only: recommend static suggestions for a predictable
+first-message experience, or offer dynamic suggestions when the developer needs
+context-dependent follow-ups. Show an approved-plan-sized diff, a focused test, and a proof
+that a visible suggestion submits the intended message.
+
+After approval, report the plan this run is about to implement:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase plan-written
+```
+
+Then run `npx --yes copilotkit@4.9.50 onboard read feature/chat-suggestions/implement`.

package/onboarding/prompts/feature/learning/implement.md

@@ -0,0 +1,44 @@
+# Implement Learning Container assignment without inventing a container
+
+Delegate implementation to one subagent with the approved plan and official guides. Reuse a
+valid existing Intelligence selection. If it is absent, use the documented streaming
+`login --json` session, let the developer select or create the Intelligence project, and
+require the secret-safe project/key provisioning summary before wiring the runtime.
+
+After the project is selected, ask the developer to create or select a stable Learning
+Container in the selected project's dashboard and provide its non-secret id. This is a real
+human gate: stop if they cannot provide it. Do not write a placeholder, a guessed id, or a
+new unsupported CLI command.
+
+Add only the documented managed runtime/thread prerequisites and the selected
+`getLearningContainerId` on the `CopilotKitIntelligence` instance. Return the same stable
+1-64 character id for the same thread every time: a thread cannot move after its first
+assignment, and a thread whose agent already ran cannot receive its first assignment
+later. Preserve the existing agent, identity, thread behavior,
+and persistence. 
+
+An Intelligence runtime requires `identifyUser`, and it usually reads a signed-in session
+that a CLI request does not carry. That makes the round trip UNKNOWN and the command exit
+non-zero on an app that is working. Pass what `identifyUser` reads with a repeatable
+`--header "Name: value"`, or record UNKNOWN as the expected result for an auth-gated app.
+It is not a defect to repair.
+
+Run focused tests and
+`npx --yes copilotkit@4.9.50 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+Repair changed-file failures and record secret-safe evidence.
+
+When implementation validation passes, report it:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase build-validated
+```
+
+If validation cannot pass, or this intent needs a prerequisite the app does not have, stop
+without further changes:
+
+```text
+npx --yes copilotkit@4.9.50 onboard read feature/stop
+```
+
+Otherwise run
+`npx --yes copilotkit@4.9.50 onboard read feature/learning/proof`.

package/onboarding/prompts/feature/learning/proof.md

@@ -0,0 +1,27 @@
+# Prove a real run is assigned to the selected Learning Container
+
+Delegate proof to a fresh subagent. In the real authenticated app, create or use a thread,
+send a normal agent request, and confirm the resulting run is assigned to the selected
+Learning Container through the documented Intelligence/Inspector evidence. Confirm the
+thread remains associated with the expected user and that the managed round-trip check still
+passes.
+
+Do not claim that Insights or Skills are already available: those depend on completed runs
+and later learning processing. Record only the assignment visible now, the request, app URL,
+process IDs, and safe stop commands. Repair changed-file defects and repeat.
+
+Report each attempt at the proof as it ends, counting from one:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase journey-attempted --attempt 1
+```
+
+Report each repair cycle the same way, counting from one:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase repair-attempted --attempt 1
+```
+
+Run
+`npx --yes copilotkit@4.9.50 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>`
+with the actual surface outcome.

package/onboarding/prompts/feature/learning/start.md

@@ -0,0 +1,52 @@
+# Add Learning to the existing CopilotKit app
+
+Treat Learning as a managed Intelligence feature that assigns real threads to a chosen
+Learning Container. Orchestrate with separate read-only, implementation, and proof
+subagents. Work only inside the target project and preserve its existing agent and chat.
+
+Before edits, inspect the runtime, agent id, provider/chat, server-side user identity,
+existing Intelligence configuration (presence only), existing thread routes, and the normal
+test/dev commands. Prove the current round trip and inspect `/info`. If the project does not
+already have a CopilotKit app, leave it unchanged and direct the developer to generic
+onboarding.
+
+Wait for the inspection subagent to finish. Then report that the inspection came back:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase research-returned
+```
+
+A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
+failed step.
+
+If the inspection did not prove the baseline this intent extends, stop here without
+changing files:
+
+```text
+npx --yes copilotkit@4.9.50 onboard read feature/stop
+```
+
+Fetch the current official guides before planning:
+https://docs.copilotkit.ai/backend/copilot-runtime.md
+https://docs.copilotkit.ai/intelligence/connect-your-runtime.md
+https://docs.copilotkit.ai/threads.md
+Use a second retrieval method if needed. The CLI has no supported command to create or list
+Learning Containers. Do not invent an id, scrape a dashboard, or treat an arbitrary string
+as one.
+
+Read the "Assign Threads to Learning Containers" section of that page. The container is
+chosen by `getLearningContainerId` on the `CopilotKitIntelligence` instance, which the
+same page documents; it receives the resolved application user and the run input, and it
+serves web and Channel runs through one API.
+
+Show a concise plan for managed runtime/thread prerequisites, a stable selected container,
+the documented `getLearningContainerId` selector, validation, and a visible assignment
+proof. Ask for approval separately.
+
+After approval, report the plan this run is about to implement:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase plan-written
+```
+
+Then run `npx --yes copilotkit@4.9.50 onboard read feature/learning/implement`.

package/onboarding/prompts/feature/open-generative-ui/implement.md

@@ -0,0 +1,28 @@
+# Implement Open Generative UI with the existing chat surface
+
+Delegate implementation to one subagent with the approved plan and the fetched official
+guide. Add only the documented Open Generative UI runtime middleware and any documented
+provider wiring the current package versions require. Preserve the existing agent, runtime
+route, persistence, chat surface, and model setup.
+
+Do not introduce Intelligence, a license key, a replacement agent, bespoke iframe HTML, or
+an "unknown tool" placeholder as the success path. Keep sandboxing and existing CSP rules
+intact unless the official guide and observed failure require a minimal documented change.
+
+Run the project's focused validation commands. Start the app and confirm `/info` reports
+`openGenerativeUIEnabled`, while treating that only as capability evidence. Record changed paths and
+validation results without secrets. When implementation validation passes, report it:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase build-validated
+```
+
+If validation cannot pass, or this intent needs a prerequisite the app does not have, stop
+without further changes:
+
+```text
+npx --yes copilotkit@4.9.50 onboard read feature/stop
+```
+
+Otherwise run
+`npx --yes copilotkit@4.9.50 onboard read feature/open-generative-ui/proof`.

package/onboarding/prompts/feature/open-generative-ui/proof.md

@@ -0,0 +1,27 @@
+# Prove a generated UI renders safely in the real chat
+
+Delegate proof to a fresh subagent. Use the existing frontend and agent to request a small,
+benign interactive UI such as a greeting card. Require the resulting sandboxed generated UI
+or iframe to render in the conversation and respond to its intended interaction. A capability
+flag, tool-call stream, or "Unknown Tool" fallback is not proof.
+
+Record the request, visible result, app URL, process IDs, and safe stop commands. Keep
+project-owned services running. Repair a failure caused by changed files and prove again;
+do not replace the output with a hard-coded component. If browser control is absent, report
+the missing visual proof honestly.
+
+Report each attempt at the proof as it ends, counting from one:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase journey-attempted --attempt 1
+```
+
+Report each repair cycle the same way, counting from one:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase repair-attempted --attempt 1
+```
+
+Then run
+`npx --yes copilotkit@4.9.50 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>`
+with the outcome actually observed.

package/onboarding/prompts/feature/open-generative-ui/start.md

@@ -0,0 +1,47 @@
+# Add Open Generative UI to the existing CopilotKit app
+
+Treat this as a focused OSS enhancement. Orchestrate the work with separate read-only,
+implementation, and proof subagents, all restricted to the target project directory.
+
+Before edits, have a research subagent identify the current CopilotKit runtime route,
+provider/chat component, agent id, package versions, existing middleware, sandbox/CSP
+constraints, and normal test/dev commands. Prove the existing app first with `/info`,
+`npx --yes copilotkit@4.9.50 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+and a real frontend request when browser control is available. If the app is not an existing
+OSS CopilotKit app with a proven round trip, change nothing and direct the developer to the
+generic onboarding path first.
+
+Wait for the inspection subagent to finish. Then report that the inspection came back:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase research-returned
+```
+
+A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
+failed step.
+
+If the inspection did not prove the baseline this intent extends, stop here without
+changing files:
+
+```text
+npx --yes copilotkit@4.9.50 onboard read feature/stop
+```
+
+Do not sign in, select an Intelligence project, create credentials, change the existing
+agent, or swap out the chat surface. Open Generative UI is an OSS runtime feature.
+
+Fetch the current official guide before planning:
+https://docs.copilotkit.ai/generative-ui/open-generative-ui.md
+Retry through a second retrieval method if needed. Setup is the documented
+`openGenerativeUI` option on the runtime, which makes `/info` report
+`openGenerativeUIEnabled`; the middleware is what parses tool-call arguments afterwards.
+Show a small plan covering that runtime option, the existing provider's renderer path,
+likely CSP/sandbox implications, tests, and a user-visible generated UI proof. Ask for approval separately.
+
+After approval, report the plan this run is about to implement:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase plan-written
+```
+
+Then run `npx --yes copilotkit@4.9.50 onboard read feature/open-generative-ui/implement`.

package/onboarding/prompts/feature/realtime-sync/implement.md

@@ -0,0 +1,38 @@
+# Implement managed realtime thread sync with documented endpoints
+
+Delegate implementation to one subagent with the approved plan and fetched guides. If no
+valid Intelligence selection exists, follow the single streaming `login --json` session,
+let the developer select or create a project, and require the secret-safe selection summary
+before wiring it. Reuse a valid selected project instead of creating another one.
+
+Add only the documented Intelligence runtime, stable server-side `identifyUser`, catch-all
+thread routes, and client realtime wiring. Preserve the existing agent, persistence, and
+chat UI. For self-hosted setup, require explicit `apiUrl` and `wsUrl` together; do not infer
+or rewrite either endpoint. For hosted setup, do not add a speculative URL.
+
+An Intelligence runtime requires `identifyUser`, and it usually reads a signed-in session
+that a CLI request does not carry. That makes the round trip UNKNOWN and the command exit
+non-zero on an app that is working. Pass what `identifyUser` reads with a repeatable
+`--header "Name: value"`, or record UNKNOWN as the expected result for an auth-gated app.
+It is not a defect to repair.
+
+Run focused tests and
+`npx --yes copilotkit@4.9.50 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+Repair changed-file failures and record changed paths and secret-safe validation
+evidence.
+
+When implementation validation passes, report it:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase build-validated
+```
+
+If validation cannot pass, or this intent needs a prerequisite the app does not have, stop
+without further changes:
+
+```text
+npx --yes copilotkit@4.9.50 onboard read feature/stop
+```
+
+Otherwise run
+`npx --yes copilotkit@4.9.50 onboard read feature/realtime-sync/proof`.

package/onboarding/prompts/feature/realtime-sync/proof.md

@@ -0,0 +1,28 @@
+# Prove realtime thread changes reach a second active client
+
+Delegate proof to a fresh subagent. Open the same authenticated project/thread in two isolated
+browser contexts. From context A, create or mutate a thread and send a message. Require
+context B to receive the thread/message change without a manual reload. Then exercise a
+second mutation in the reverse direction where the product supports it. Keep the managed
+round-trip verification green.
+
+Record both visible states, actions, timing, app URL, process IDs, and safe stop commands.
+A successful WebSocket connection, a server event, or a refreshed second tab is not proof.
+Repair changed-file defects and repeat. If the environment cannot drive two contexts, report
+the missing proof rather than claiming realtime works.
+
+Report each attempt at the proof as it ends, counting from one:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase journey-attempted --attempt 1
+```
+
+Report each repair cycle the same way, counting from one:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase repair-attempted --attempt 1
+```
+
+Run
+`npx --yes copilotkit@4.9.50 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>`
+with the actual outcome.

package/onboarding/prompts/feature/realtime-sync/start.md

@@ -0,0 +1,50 @@
+# Add realtime thread sync to the existing CopilotKit app
+
+Treat realtime sync as the Intelligence thread-realtime plane, not as a generic WebSocket
+exercise. Act as the orchestrator and delegate read-only inspection, implementation, and
+two-context proof to subagents within the target project.
+
+Before edits, inspect the current runtime, provider/chat, agent id, authenticated stable user
+identity, thread routes, existing Intelligence configuration (presence only), current websocket
+configuration, and normal test/dev commands. Prove the current frontend-to-runtime-to-agent
+round trip and inspect `/info`. If this is not an existing CopilotKit app, leave files
+unchanged and direct the developer to generic onboarding first.
+
+Wait for the inspection subagent to finish. Then report that the inspection came back:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase research-returned
+```
+
+A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
+failed step.
+
+If the inspection did not prove the baseline this intent extends, stop here without
+changing files:
+
+```text
+npx --yes copilotkit@4.9.50 onboard read feature/stop
+```
+
+Fetch the current official guides before planning:
+https://docs.copilotkit.ai/intelligence/connect-your-runtime.md
+https://docs.copilotkit.ai/auth.md
+https://docs.copilotkit.ai/intelligence/threads-explained.md
+https://docs.copilotkit.ai/reference/hooks/useThreads.md
+Retry unavailable pages a second way. Reuse a proven Intelligence project where present; do
+not sign in or select/create one until the developer approves the plan.
+
+The plan must name the documented managed runtime/thread wiring, identity and catch-all
+thread routes, the existing or documented client realtime connection, tests, and a proof in
+two browser contexts. For self-hosted Intelligence, configure `apiUrl` and `wsUrl` together
+from explicit developer-owned values; never derive one from the other. The client prepends
+`/api` itself, so an `apiUrl` that already ends in `/api` produces `/api/api/...`. Hosted setup may not
+need a `wsUrl`. Ask for approval separately.
+
+After approval, report the plan this run is about to implement:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase plan-written
+```
+
+Then run `npx --yes copilotkit@4.9.50 onboard read feature/realtime-sync/implement`.

package/onboarding/prompts/feature/rich-threads/implement.md

@@ -0,0 +1,41 @@
+# Implement Rich Threads with a stable identity and managed runtime
+
+Delegate implementation to one subagent with the approved plan and fetched official guides.
+If repository evidence does not prove an existing valid Intelligence selection, run
+`npx --yes copilotkit@4.9.50 login --json` and follow its single streaming session. Then
+list projects, show the developer the current/recent choices, and select or create one only
+after they choose. Require the secret-safe selection summary to confirm the project file,
+environment file, and key provisioning; never display a key. If existing configuration is
+valid, reuse it rather than minting another project or key.
+
+Add only documented Intelligence runtime wiring, server-side `identifyUser`, and catch-all
+thread routes. Use the existing authenticated user source; if no stable source exists, stop
+and explain that it is a prerequisite. Preserve the agent, existing persistence, and chat
+surface. Add the documented drawer only if the approved plan selected it.
+
+An Intelligence runtime requires `identifyUser`, and it usually reads a signed-in session
+that a CLI request does not carry. That makes the round trip UNKNOWN and the command exit
+non-zero on an app that is working. Pass what `identifyUser` reads with a repeatable
+`--header "Name: value"`, or record UNKNOWN as the expected result for an auth-gated app.
+It is not a defect to repair.
+
+Run focused type/test commands, then start the app and run
+`npx --yes copilotkit@4.9.50 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+Repair changed-file failures before continuing. Record changed paths and secret-safe
+validation evidence.
+
+When implementation validation passes, report it:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase build-validated
+```
+
+If validation cannot pass, or this intent needs a prerequisite the app does not have, stop
+without further changes:
+
+```text
+npx --yes copilotkit@4.9.50 onboard read feature/stop
+```
+
+Otherwise run
+`npx --yes copilotkit@4.9.50 onboard read feature/rich-threads/proof`.

package/onboarding/prompts/feature/rich-threads/proof.md

@@ -0,0 +1,27 @@
+# Prove Rich Threads persist and reopen for the same user
+
+Delegate proof to a fresh subagent. In the real authenticated frontend, create a conversation,
+send a distinct message, confirm the response, reload or reopen the same thread, and require
+the prior history to remain visible for that same stable user. Confirm the runtime exposes
+the required thread routes and the Intelligence verification remains successful.
+
+Record the interaction, visible persisted history, app URL, process IDs, and safe stop
+commands. Do not count a thread id in a log, a successful API call, or an in-memory history
+as proof. Repair defects caused by changed files and repeat. Keep project-owned servers
+running.
+
+Report each attempt at the proof as it ends, counting from one:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase journey-attempted --attempt 1
+```
+
+Report each repair cycle the same way, counting from one:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase repair-attempted --attempt 1
+```
+
+Then run
+`npx --yes copilotkit@4.9.50 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>`
+with the actual browser outcome.

package/onboarding/prompts/feature/rich-threads/start.md

@@ -0,0 +1,52 @@
+# Add Rich Threads to the existing CopilotKit app
+
+Treat Rich Threads as a managed Intelligence feature layered onto the existing app, not as a
+reason to replace its agent or chat. Act as the orchestrator and delegate inspection,
+implementation, and proof to separate subagents within the target project.
+
+Before edits, have a read-only subagent locate the runtime route, CopilotKit provider/chat,
+agent id, current thread UI or headless API, authentication boundary, stable server-side user
+identity source, current project configuration (presence only), and test/dev commands. Prove
+the current frontend-to-runtime-to-agent round trip and inspect `/info`. If the project lacks
+an existing CopilotKit app, leave it unchanged and direct the developer to generic onboarding.
+
+Wait for the inspection subagent to finish. Then report that the inspection came back:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase research-returned
+```
+
+A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
+failed step.
+
+If the inspection did not prove the baseline this intent extends, stop here without
+changing files:
+
+```text
+npx --yes copilotkit@4.9.50 onboard read feature/stop
+```
+
+Fetch the current official guides before planning:
+https://docs.copilotkit.ai/threads.md
+https://docs.copilotkit.ai/threads-lifecycle.md
+https://docs.copilotkit.ai/intelligence/connect-your-runtime.md
+https://docs.copilotkit.ai/auth.md
+https://docs.copilotkit.ai/prebuilt-components/copilot-threads-drawer.md
+Retry unavailable pages a second way. Do not infer an identity from a browser display name or
+use a client-supplied identifier as the server-side user identity. `identifyUser` names an
+already-authenticated caller; it is not the authentication gate, and the auth page lists the
+thread routes that do not resolve the caller through it and must be guarded separately.
+
+Re-use a valid existing Intelligence project and credential when repository evidence proves
+one. If Intelligence is missing, do not create a project or sign in yet: show a plan first.
+The plan must name the documented Intelligence runtime wiring, server-side `identifyUser`,
+catch-all thread routes, the selected UI (drawer or existing headless UI), preserved behavior,
+tests, and a reload/reopen proof. Ask for approval separately.
+
+After approval, report the plan this run is about to implement:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase plan-written
+```
+
+Then run `npx --yes copilotkit@4.9.50 onboard read feature/rich-threads/implement`.

package/onboarding/prompts/feature/stop.md

@@ -0,0 +1,41 @@
+# Stop this feature without changing the app
+
+Keep the developer's current agent, frontend, runtime, persistence, chat surface, and
+package choices exactly as they were.
+
+Name the step that stopped this run and what it needed: a CopilotKit baseline this intent
+extends, a documentation page that would not load, a prerequisite the app does not have, a
+validation that would not pass, or a proof that could not be driven. Do not say the feature
+works when this run could not prove it.
+
+If the app has no proven CopilotKit baseline, say so plainly and point the developer at
+generic onboarding, which builds the app this intent needs. Give it a run id of its own:
+a `start` with no `--run` reprints the id this stopped run already holds, and one id
+covering both reads as one run that did two different things.
+
+```text
+npx --yes copilotkit@4.9.50 onboard start --run <new-12-character-id>
+```
+
+Do not read a generic onboarding node from this run. A feature run and a generic run are
+separate routes, and continuing one inside the other reports a stop that never happened.
+
+Do not run `onboard complete`. This run did not complete.
+
+If this run changed files before it stopped, list every path it changed and say whether it
+reverted them. A report that says only that the run stopped cannot be acted on.
+
+Send one short report. Run the feedback command without another developer question. The
+CLI telemetry gate decides whether the report is sent.
+
+```text
+npx --yes copilotkit@4.9.50 onboard feedback
+```
+
+Write the feedback message to the command's standard input, in at most four lines. Send no
+secrets, source code, logs, or command output. The command refuses a report that carries
+any of those, prints the reason, and exits zero. A refused report is not a failed step.
+Reword it and send it again, or stop without a report. The command prints what it sent.
+This is the channel for a stop. Report friction only from a run that finished, never from
+here. If the CLI says that telemetry is disabled or unavailable, state that the report was
+not sent and stop without another question.

package/onboarding/prompts/feature/voice/implement.md

@@ -0,0 +1,28 @@
+# Implement documented voice transcription wiring
+
+Delegate implementation to one subagent with the approved plan and fetched voice guide.
+Wire the documented `TranscriptionService` into the existing v2 catch-all runtime and retain
+the current provider/chat surface. Use the already configured credential variable by name
+only; never read, print, synthesize, or add a secret. If no supported credential is present,
+stop with that specific setup requirement.
+
+Do not add Intelligence, replace the agent, or make a fake microphone button. Run the focused
+type/test command and start the app. Confirm `/info` reports
+`audioFileTranscriptionEnabled`, but treat it as capability evidence rather than completed
+voice proof. Record changed paths and validation results.
+
+When implementation validation passes, report it:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase build-validated
+```
+
+If validation cannot pass, or this intent needs a prerequisite the app does not have, stop
+without further changes:
+
+```text
+npx --yes copilotkit@4.9.50 onboard read feature/stop
+```
+
+Otherwise run
+`npx --yes copilotkit@4.9.50 onboard read feature/voice/proof`.

package/onboarding/prompts/feature/voice/proof.md

@@ -0,0 +1,27 @@
+# Prove voice input reaches the existing chat without fabricating microphone access
+
+Delegate proof to a fresh subagent. Confirm the real composer renders the microphone control
+and that the runtime advertises transcription. Where browser microphone permission is
+available and the developer authorizes it, record a short benign utterance and require its
+transcript to appear in the composer and submit through the existing agent path.
+
+When microphone permission is unavailable, use the official guide's documented canned
+`onTranscribed`/transcript route for automated proof instead; do not grant permissions on the
+developer's behalf or claim a live recording was made. Record the visible control, transcript
+path, agent response, app URL, and process IDs. Fix changed-file defects and repeat.
+
+Report each attempt at the proof as it ends, counting from one:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase journey-attempted --attempt 1
+```
+
+Report each repair cycle the same way, counting from one:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase repair-attempted --attempt 1
+```
+
+Then run
+`npx --yes copilotkit@4.9.50 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>`
+with the actual surface outcome.