Language intelligence joins the path.

The same compiler mind, available while you type

The new himesan lsp --stdio command reuses the parser and contextual analysis that already judge a real build. It can diagnose unsaved templates, explain tags and output contexts, list component symbols, complete known component constructors, and follow a component reference to its declaring .sando signature.

It does not generate files, run Go, fetch a dependency, start the development supervisor, or take over an editor. The protocol is the ordinary Language Server Protocol, so the intelligence belongs to Hime-san rather than one proprietary editor integration.

Three tools, three deliberately different jobs

• Hime-san Beta 2 contains the reusable language intelligence and remains AGPL-3.0-only.
• The Sandwich Hime Agent Skill v0.1.0 teaches compatible coding agents the safe, pinned project workflow under 0BSD.
• The VS Code preview 0.1.0-preview.1 supplies highlighting, snippets, explicit project commands, and an LSP client under AGPL-3.0-only.

The editor preview never downloads or upgrades Hime-san. It respects workspace trust and asks the workspace environment—local, WSL, SSH, or container—to supply the exact compiler its project expects.

Compiler forward, runtime steady

Beta 2 changes only the development compiler. Applications still use sando v1.0.0-beta.1; no new runtime tag was created because its code and ABI did not change.

go get gamertan.com/sandwich-hime/sando@v1.0.0-beta.1
go install gamertan.com/sandwich-hime/cmd/himesan@v1.0.0-beta.2

The Beta 2 source tag is signed. Clean direct and public-proxy installation, checksum-database resolution, full race-enabled Linux verification, and native Windows verification on the supported Go lines passed. Native macOS evidence remains explicitly provisional.

Why build this now?

Because a language should meet a learner before the build fails. A good editor hint can explain the boundary without hiding the HTML. A good agent instruction can preserve the pinned dependency instead of “helpfully” changing it. A good protocol lets the next editor reuse the work instead of rebuilding the compiler from the outside.

This is preview tooling. We want classroom and community feedback on installation, diagnostics, completion, definitions, workspace trust, and process cleanup before publishing to editor registries.