sygnal 6.1.1 → 6.2.0

package/CHANGELOG.md

@@ -2,6 +2,45 @@
 
 All notable changes to Sygnal are listed here. Versions follow [semantic versioning](https://semver.org). Releases before 5.4.0 are described in the [GitHub releases](https://github.com/tpresley/sygnal/releases) and tags.
 
+## 6.2.0 — 2026-10-10
+
+Two things since 6.1.1. Agents get read-only tools that take an input (`agent.queries`) and actions that answer once their result is in state (`until`). And the editor tooling (PLAN-7 Phase 4) grows from findings to navigation: the language server in `sygnal-check` 0.5.0 adds completions, go to definition / references, code lenses and rename for the names Sygnal wires by string, in VS Code (extension 0.2.0), Neovim, Helix, JetBrains IDEs and any other LSP editor.
+
+Everything is additive. The core doesn't change (the size gate measures 42,690 B, as in 6.1.1), and the new `sygnal/ai` options are tree-shaken from apps that don't use them.
+
+**Measured impact.**
+- On a generated 20,000-line project (Apple M3 Max): a completion answers in about 1 ms (about 0.7 ms while a check runs); go to definition from the last check's index takes under 1 ms, about 70 ms after an unsaved change or a save; an edit shows its findings about 270 ms later (150 ms of it the typing pause); a cold check takes about 250 ms.
+- Completions find the cursor's context in 1,270 of 1,270 mid-edit cases measured on three example apps (unterminated strings, half-typed keys, truncated files).
+- Rename was applied 167 times across 11 example apps and the fixtures with the findings unchanged every time; it refused 114 renames it couldn't prove complete.
+- An eval of the Claude Code plugin with coding agents (PLAN-7 E-1, Haiku and Sonnet) found no measurable benefit: Claude Code delivers few language-server findings to the model (only for Edit/Write edits, and it drops findings for files the agent is editing), and agents already run `sygnal-check --strict`. The plugin stays a tool for people; the agent docs don't change.
+- Size: the kanban gate is unchanged, (a) 42,690 B with `nativeGlobalThis: false` (budget 42,700 B) and (b) 38,679 B by default.
+
+**Companion packages.**
+- **`sygnal-check` 0.5.0:** completions, go to definition / references, code lens and rename in `sygnal-check lsp`; a positions index for actions, EVENTS types, class/id tokens, controls, state keys, context and child components; rules for `agent.queries` and `until`.
+- **`create-sygnal-app` 2.3.0:** every template depends on `sygnal` ^6.2.0 and `sygnal-check` ^0.5.0.
+- **VS Code extension 0.2.0:** the new features, code lens peek view, setting `sygnal.codeLens`, and a notice when a project's own `sygnal-check` predates them.
+- **Claude Code plugin 0.1.1:** the updated `sygnal-dev` skill. Claude Code uses no completions or navigation, so nothing else changes.
+
+### Added
+
+- **`sygnal-check lsp`: completions.** Inside the strings TypeScript can't see: model keys (unhandled actions first, as a snippet when the editor supports one), `DOM.select` / `DOM.click('…')` selectors (the component's own classes after `.`, ids after `#`), `EVENTS.select('…')` and `event('…')` (types used elsewhere in the project), `next('…')` and reply names, `<Collection from="…">` state keys. Answered on the main thread from the last check, also while you type and the file doesn't parse; nothing outside these places, so TypeScript's own completions aren't crowded.
+- **`sygnal-check lsp`: go to definition and references.** Intent key ↔ model entry ↔ `next()` / reply names / `agent.actions`; EVENTS selects ↔ emitters across files; a selector token → the element rendering it (or the child that does, SYG104-style); `from="x"` → the state key; a context read → the nearest providing ancestor; `CHILD.select(Child)` → the child and its PARENT entries; user behavior names → their definition; names built from module constants. A name it can't read gives nothing, never a guess.
+- **`sygnal-check lsp`: code lenses.** On intent keys (`handled by model.SAVE · STATE, HTTP → LOADED/FAILED`, or `no model entry`), model keys (`triggered by intent, next from RESET`, or `not triggered`) and EVENTS selects / emits (emitter / listener counts). The verdicts come from the same SYG101/SYG102 run as the findings, so a lens never disagrees with one. Setting `sygnal.codeLens`.
+- **`sygnal-check lsp`: rename** of actions (intent, model, `next`, reply names, statics; `agent.actions` keys as a confirm-needed group), EVENTS types, class / id names, state keys and context entries. It refuses, with the reason, whenever it can't find every use: built-ins, spreads and computed keys, names built at run time or from constants, first-party behaviors, class names a stylesheet or markup file might use, any project file with a syntax error, or a mention of the name it can't account for. Matches in test files come as a separate group that needs confirmation.
+- **`agent.queries`: read-only tools that take an input** (`sygnal/ai`). `queries: { find: { description, input, when?, run: (state, input) => result } }` on an `agent` declaration offers the tool `<name>_find`, marked read-only, to every agent surface (the `chat` behavior, WebMCP, MCP Apps, the dev MCP endpoint, `t.callTool()`; the command bar skips read-only tools). A call validates the input and checks `when` as for an action, then returns `{ ok: true, result }`: nothing is dispatched and nothing renders. Use it for data too large to send in `read` on every request, or an answer computed from the state. On a Collection item component a query gets the item key parameter, like the item's actions. `run` must be pure and synchronous: a missing or `async` `run` is the new **SYG246** (runtime and `sygnal-check`), and a query whose tool name is an action's is the new **SYG247** (only the action is offered). SYG240, SYG241 and SYG243 cover queries too. Types: `AgentQuery`, `AgentQueryResult`; `AgentDeclaration.actions` is optional (a declaration may have queries only); `AgentResult` gains `result`. `sygnal-check --graph` lists a declaration's `queries`. WebMCP's result budget cuts a long `result` as it cuts `state` (SYG242).
+- **Agent action `until`: a call answers once the action's result is in state** (`sygnal/ai`). An action that only starts something (a search whose results a `resources` entry fetches, a driver request with a reply action) answered right after its render, so the model saw `status: 'loading'`. `until: 'search'` makes the call wait until that resource is neither loading nor refreshing (so `keepPrevious` and refetches are waited for too); `until: (state) => boolean` covers a result a reply action writes. The request still goes through `resources` or a driver, so tests answer it with `t.respond('HTTP', …)`. After `timeout` (default 10 s) the call answers `{ ok: true, pending: true, note, state }`. `agentTools()` gains `cancel()`; the `chat` behavior cancels a waiting call on Stop, on a failure and on a new message, so a slow request never blocks the next turn. New **SYG248** (runtime and `sygnal-check`, with a "did you mean" fix): `until` names no resource of the component, so the call answers at once. SYG241 covers a throwing `until`. Types: `AgentAction.until` / `timeout`, `AgentResult.pending` / `note`, `AgentToolSet.cancel()`.
+
+### Changed
+
+- **`sygnal-check lsp` is faster on large projects:** the navigation index is sent as soon as the model is built when a request waits for it, and the code-lens and position data cost a few ms per check (a 20,000-line project: navigation right after a save about 70 ms).
+- **A plain chat is the `chat` behavior with `agent: false`** (docs and agent context). The AI chat guide gains "The same chat with the `chat` behavior", a live demo of `chat({ agent: false, form, prompt, stop, regenerate })`: Stop keeps the partial reply, Retry doesn't repeat the question, every message has an `id`, and the host can send with `next('chat.SEND', text)` and react in `'chat.DONE'`. The raw driver request stays the form for one-off requests (a summary, structured `output`). `llms.txt` and the `sygnal-dev` skill now send a conversation to the behavior instead of teaching the hand-written chat model, and the demos write user messages as `{ role: 'user', content }`, a short form every transport accepts. No library change.
+- **Docs: every code block that is a file shows its file name.** A first-line comment with text after the file name (`// TaskPage.jsx: the page reads the same request`), or a Vike route path with `@` in it, rendered as a plain comment with no tab; those blocks now carry the bare name or `title="…"`. A variant label goes into the tab (`main.js (development)`, `vite.config.js (Vite 8)`), the Sygnal side of each From React / From Vue comparison is titled "Sygnal", and live demo code that follows a "Demo server" block or a named file shows its component file (`Chat.jsx`, `Ticket.jsx`, ...). The guides shipped in the package (`dist/guide`) carry the same titles.
+- **The docs build checks file-name tabs.** `npm --prefix docs run build` runs `docs/scripts/check-code-titles.mjs` after the link check: it fails when a built code block starts with a file-name comment that Expressive Code didn't turn into a tab.
+
+### Fixed
+
+- **The `chat` behavior: a late tool result no longer keeps the "not run" error text.** When Stop closed a running tool call as `output-error` ("not run: stopped by the user") and the call then finished and changed the app (G-626), its part became `output-available` with the stale `errorText` still on it. The result now replaces it, and an `output-error` result drops a stale `output`.
+
 ## 6.1.1 — 2026-10-10
 
 Editor tooling (PLAN-7). A language server, `sygnal-check lsp`, shows the checker's findings in the editor while you type: an intent selector that matches nothing, an action with no model entry, an EVENTS type nobody listens to, and the other wiring bugs that fail silently at runtime and that TypeScript can't see. It runs in VS Code (a new extension), Claude Code (a new plugin), Neovim, Helix, JetBrains IDEs (LSP4IJ) and any other LSP editor, all from the one server in `sygnal-check`, so the editor, the CLI, the Vite overlay and CI report the same findings from the same config file.