Apply PR #40845: feat(app): redesign non-modal settings

.opencode/plugins/tui/discovery-smoke.ts

@@ -0,0 +1,13 @@
+import type { Context } from "../../../packages/plugin/src/tui/context"
+
+export default {
+  id: "test.tui-discovery-smoke",
+  setup(_context: Context) {
+    // context.ui.toast.show({
+    //   title: "TUI plugin discovery works",
+    //   message: "Loaded .opencode/plugins/tui/discovery-smoke.ts",
+    //   variant: "success",
+    //   duration: 30_000,
+    // })
+  },
+}

.opencode/skills/ideal-pseudocode/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: ideal-pseudocode
+description: Function-by-function refactoring loop driven by ideal pseudocode. Use when the user says "ideal pseudocode", asks to make a function read like its pseudocode, or wants a dense module cleaned up one function at a time.
+---
+
+# Ideal Pseudocode
+
+Clean up one function at a time by writing the pseudocode it _should_ read as, naming every delta between that and the real code, and closing only the gaps the user approves.
+
+## Loop
+
+One function per round. Never touch code before the user picks a direction.
+
+1. **Pick the target** with the user — usually the next function up or down the call chain from the last round.
+2. **Read the current code** fresh from disk. It may have unsaved or parallel edits; ask before overwriting anything unexpected.
+3. **Distill.** Write the function's ideal pseudocode in a `ts`-fenced code block — TypeScript-flavored for syntax highlighting, but pseudocode: comments over mechanics, one line per idea, every arm of a loop visible as an arm. For a dense or unfamiliar function, first show the _current_ structure as pseudocode, then the ideal.
+4. **Name the deltas.** A numbered list; each delta is one concrete gap: control flow smuggled through combinators, a flag-typed parameter, colliding names, side-effect plumbing drowning a loop body, twin functions differing only by a filter. For each, give an honest cost/benefit and a decisive recommendation — including "leave it" when the density has reasons (state the reasons).
+5. **Verify before proposing.** Any API the proposal builds on (a combinator, schedule, matcher) gets checked against the installed version's source, not memory.
+6. **Get buy-in, then apply.** Minimal edits. Quarantine irreducible ugliness inside a small helper whose name is the pseudocode line it implements. Collapse shallow sibling functions into one deep function only when the distinguishing argument is a domain noun, not a behavior switch.
+7. **Validate.** Typecheck and the focused test suites from the package directory; rerun timing-sensitive tests repeatedly. Flag any semantic change the restructure introduced, even when tests pass.
+8. **Offer the next target** and stop.
+
+## Style
+
+- Keep each round tight: pseudocode block, deltas, recommendation, one question.
+- State mutation belongs in one visible place (usually the loop tail), never spread across error channels or callback closures.
+- Prefer early return and `if` chains for control flow; matchers are for producing values.
+- Compare names against the question each caller is actually asking; rename toward the domain noun.
+
+## Example round
+
+Every round should read like this (abridged from a real one, on an Effect step-runner):
+
+> `runStep` it is. The ideal pseudocode:
+>
+> ```ts
+> // One logical step: one settled model call, however many attempts it takes.
+> // An attempt can end without settling in two ways:
+> //   transient provider failure -> retry the same call, same assistant message
+> //   compaction rewrote history -> rebuild the request and call again
+> function runStep(session, promotable, step) {
+>   while (true) {
+>     const result = callModel(session, promotable, step)
+>
+>     if (result.completed) return result
+>
+>     if (result.retryable) {
+>       wait(retrySchedule) // exhausted -> publish Step.Failed, fail drain
+>       promotable = none // never re-promote on a second attempt
+>       continue
+>     }
+>
+>     // compaction restarted the step: fresh request from rewritten history
+>     promotable = none
+>     step = result.step
+>   }
+> }
+> ```
+>
+> Comparing against the real thing, three deltas:
+>
+> 1. **The retry arm doesn't live in the loop.** In the pseudocode, retry is just another loop arm. In the real code it's smuggled through the error channel: `Effect.tapError` mutating loop variables via `Effect.sync` closures, then `Effect.retryOrElse` re-running a suspended call. Four mutable variables mutated from three different places — the state flow is invisible unless you already know the trick.
+> 2. **`recoverOverflow: typeof compaction.compact | undefined`** — a function-typed parameter used as a one-shot armed/disarmed flag. The callee already closes over `compaction`; a boolean says what it is.
+> 3. **`assistantMessageID`** exists solely to resume the same durable message across retries — fine, but only legible once the retry arm is visible in the loop.
+>
+> The unifying move for (1): a schedule driver, so a retryable failure becomes a caught value handled in the loop body exactly like the compaction arm. One honest trade: it's more manual than the blessed combinator — but the manual version is the loop the combinator was hiding, and the loop already exists for restarts. Two restart mechanisms, one control structure.
+>
+> Want me to apply it — unified loop, simplified schedule input, boolean `recoverOverflow`?

.opencode/skills/opencode-drive/SKILL.md

@@ -0,0 +1,254 @@
+---
+name: opencode-drive
+description: Use when an agent needs drive OpenCode via a script or interact with an isolated instance
+---
+
+# OpenCode Drive
+
+Use `opencode-drive` to launch an isolated OpenCode instance and control it via commands or a script.
+
+There are two modes. Always default to using a script unless specifically directed to be interactive (connect
+to an existing running instance, or start a new one, and make a few changes to the UI and read it, and iterate
+on changes).
+
+Scripts allow you to run a full walkthrough in one run. When the script is done opencode-drive exits,
+stops all processes, and cleans up all artifacts.
+
+# Prepare The Environment
+
+Use `init` when files must be added to the isolated home or project before OpenCode starts. It prints the artifact directory without launching OpenCode. A later `start` with the same name reuses it.
+
+```bash
+artifacts=$(opencode-drive init --name demo)
+cp -R ./fixtures/home/. "$artifacts/"
+cp -R ./fixtures/project/. "$artifacts/files/"
+opencode-drive start --name demo --dev ~/projects/opencode
+```
+
+The simulated project is under `$artifacts/files`. Running `start` without a prior `init` initializes the artifacts automatically.
+
+# Scripted usage
+
+You can write scripts that walk through entire flows, and gives you full access to controlling
+the backend too. See examples of the script API at the bottom of this file.
+
+After creating or editing a script, always typecheck it before running. Never skip this step:
+
+```bash
+opencode-drive check ./reproduce-stale-exploring-empty.ts
+```
+
+Run it by passing `--script` to start:
+
+```bash
+opencode-drive start --name auto-stop-reproduction --script ./reproduce-stale-exploring-empty.ts
+```
+
+It will output information about the run, including paths to log files which you can read
+to inspect what happened. If you need to dig into failures that aren't clear, read those log
+files. If the script is unsuccessful, automatically fix the script and run it again.
+
+Scripts use one typed definition object. `setup` runs before OpenCode starts,
+and `fs.writeFile` always writes inside the simulated project.
+
+You can read the full typed API here: https://raw.githubusercontent.com/jlongster/opencode-drive/refs/heads/main/src/script/types.ts
+
+```ts
+import { defineScript } from "opencode-drive"
+
+export default defineScript({
+  async setup({ fs, config }) {
+    config.autoupdate = false
+    await fs.writeFile("src/example.ts", "export const value = 1\n")
+  },
+
+  async run({ ui, llm }) {
+    await ui.submit("Open src/example.ts")
+    await llm.send(llm.text("The file exports `value`."))
+    await ui.waitFor("The file exports `value`.")
+  },
+})
+```
+
+`setup` receives the current OpenCode config object, which starts from the
+default drive config unless the prepared instance already has one. When a script
+needs custom config, mutate this `config` parameter instead of generating and
+writing a new config object from scratch, so the script keeps the default
+provider/model settings unless it intentionally changes them.
+
+Note that the simulated model is a GPT model type, and opencode uses the `patch` tool for working with files Do not use a `edit` or `write` tool to edit files.
+
+Use `launch: "manual"` when the script needs to launch the server and every TUI
+itself (this is extremely rare, do not use this unless explicitly asked). In this
+mode `ui` is typed as `null`; call `server.launch()` exactly
+once before launching clients. Each `clients.launch(name)` result provides the
+same UI methods as the automatic client. You can see an example of this API
+here: https://raw.githubusercontent.com/jlongster/opencode-drive/refs/heads/main/examples/multiple-clients.ts
+
+Use the exported `wait(milliseconds)` utility for an unconditional delay.
+
+`await llm.send(...)` waits for the next request and resolves after OpenCode
+acknowledges its complete response. `llm.queue(...)` declares responses in
+advance. Chunks may be built with `text`, `reasoning`, `toolCall`, `raw`,
+`finish`, and `disconnect`. A normal response receives `finish("stop")`
+automatically unless it yields or queues an explicit terminal event.
+
+`llm.text(text, { delay, chunkSize })` defaults to a 2 ms delay and a
+15-character target varied by plus or minus 5 per chunk.
+
+`llm.reasoning` accepts the same options, and `llm.pause(milliseconds)` adds a
+delay between any two outputs.
+
+Use `llm.serve` for an ongoing typed response generator:
+
+```ts
+llm.serve(async function* (request, index) {
+  yield llm.reasoning(`Handling request ${index + 1}`)
+  yield llm.text(`Received ${request.id}`)
+  yield llm.finish("stop")
+})
+```
+
+The backend connection, response cleanup, cancellation, and recording
+completion are automatic.
+
+You can see some example scripts here:
+
+- https://raw.githubusercontent.com/jlongster/opencode-drive/refs/heads/main/examples/simple.ts
+- https://raw.githubusercontent.com/jlongster/opencode-drive/refs/heads/main/examples/serve.ts
+
+## Prune
+
+- `prune` removes artifact directories. These are always cleaned up after running a script
+  successfully, but leftover on failed runs. Always call this if a script fails.
+
+```bash
+opencode-drive prune --name demo
+
+// --force cleans up all artifcat directories
+opencode-dirve prune --force
+```
+
+# Live interaction usage
+
+- Always give headless instances a unique `--name`. Visible instances may omit it.
+- A normal headless `start` detaches automatically and returns after the instance is ready.
+- Do not add `&`; the long-running owner already runs in the background.
+- Configure simulated model responses after startup when needed.
+- Send ordered UI commands with `send`.
+- Always stop the instance when finished.
+
+```bash
+opencode-drive start --name demo
+
+opencode-drive send --name demo \
+  --command.ui.type '{"text":"Explain this project"}' \
+  --command.ui.enter
+
+opencode-drive stop --name demo
+```
+
+## Send UI Commands
+
+- Every `send` opens a connection to the named instance, runs its commands in order, and exits.
+- Combine typing and Enter in one command when submitting a prompt.
+- JSON-valued commands require one JSON argument.
+- Multiple command flags execute from left to right.
+
+Commands:
+
+- `--command.ui.type <json>` types into the focused editor. Arguments: `text` string.
+- `--command.ui.press <json>` presses a key. Arguments: `key` string; optional `modifiers` object with boolean `ctrl`, `shift`, `meta`, `super`, or `hyper`.
+- `--command.ui.enter` presses Enter. Arguments: none.
+- `--command.ui.arrow <json>` presses an arrow key. Arguments: `direction` is `up`, `down`, `left`, or `right`.
+- `--command.ui.focus <json>` focuses an element. Arguments: `target` is the numeric element `num` returned by `ui.state`.
+- `--command.ui.click <json>` clicks an element. Arguments: numeric `target`, `x`, and `y`; use the element `num` returned by `ui.state` as `target`.
+- `--command.ui.state` prints focus and interactive element metadata as JSON. Arguments: none.
+- `--command.ui.matches <json>` prints whether literal, case-sensitive text appears on screen. Arguments: `text` string.
+
+```bash
+opencode-drive send --name demo \
+  --command.ui.type '{"text":"Find the relevant code and explain it"}' \
+  --command.ui.enter
+
+opencode-drive send --name demo \
+  --command.ui.press '{"key":"p","modifiers":{"ctrl":true}}'
+
+opencode-drive send --name demo \
+  --command.ui.arrow '{"direction":"down"}'
+
+opencode-drive send --name demo \
+  --command.ui.focus '{"target":12}'
+
+opencode-drive send --name demo \
+  --command.ui.click '{"target":12,"x":4,"y":1}'
+
+opencode-drive send --name demo \
+  --command.ui.matches '{"text":"OpenCode"}'
+```
+
+To read the UI state and see information about interactable elements, use the `ui.state` command:
+
+```bash
+opencode-drive send --name demo --command.ui.state
+```
+
+## Configure LLM Responses
+
+- `responses` controls what the LLM responds with
+- Only use this if you are wanting to reproduce an exact type of response
+- Defaults are `text,reasoning,diff,tool` with `write,apply_patch`.
+- Supported types are `text`, `reasoning`, `diff`, and `tool`.
+- `--tools` limits generated tool calls to names offered by OpenCode.
+
+```bash
+opencode-drive responses --name demo \
+  --types text,reasoning,diff,tool \
+  --tools write,apply_patch
+
+opencode-drive responses --name demo \
+  --types tool \
+  --tools read,glob,grep
+```
+
+## Inspect The UI
+
+- `ui.state` prints focus and interactive element metadata as JSON.
+- `ui.matches` checks for literal, case-sensitive screen text.
+- `screenshot` prints the generated image path.
+
+```bash
+opencode-drive screenshot --name demo
+```
+
+## Lifecycle
+
+- `stop` waits for recording export and owner cleanup before returning.
+
+```bash
+opencode-drive stop --name demo
+```
+
+# Record The UI
+
+- Start with `--record` to capture a headless instance from its first rendered frame.
+- `stop` finishes the recording, exports an MP4, and prints its path.
+
+```bash
+opencode-drive start --name demo --record
+
+opencode-drive send --name demo \
+  --command.ui.type '{"text":"Show me the current architecture"}' \
+  --command.ui.enter
+
+opencode-drive stop --name demo
+```
+
+# Artifacts dir
+
+- `dir` prints the artifact directory for the instance.
+
+```bash
+opencode-drive dir --name demo
+```
+

.opencode/skills/sample-skill/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: sample-skill
+description: Use when the user says sample skill, skill demo, or asks how an opencode SKILL.md should be structured; demonstrates a tiny project-local skill with practical assistant workflow guidance.
+---
+
+# Sample Skill
+
+This is a minimal project-local opencode skill. It exists as a reference for how a skill is structured and as a tiny reusable workflow the assistant can load when the user asks for a skill example.
+
+## When To Use
+
+- Use when the user asks for a sample skill or skill template.
+- Use when demonstrating the required `SKILL.md` frontmatter and body format.
+- Do not use for unrelated coding tasks just because a skill exists.
+
+## Workflow
+
+- Confirm the specific outcome the user wants if the request is ambiguous.
+- Inspect the relevant files before changing anything.
+- Make the smallest correct change.
+- Verify the result with a focused read, typecheck, test, or other lightweight check when available.
+- Summarize the changed files and any required restart or reload step.
+
+## Example Response Style
+
+When this skill is relevant, keep responses direct and actionable:
+
+```text
+I created a project-local skill at .opencode/skills/sample-skill/SKILL.md.
+Restart opencode for the new skill to be discovered by future sessions.
+```