Three doors lead from Livecode into the Hitchhiker architecture: stacks as services, stacks as wiki widgets, and a literate language that commands stacks. Each door gets an honest verdict here. Together they balance the short term — twenty years of Livecode fluency, usable now — against the long term: owning the WikiScript language and a lean wasm, Rust, Spin and Tauri architecture we can build against for years.
1. **Door one**: stacks as services 1. **Door two**: Wasm Widgets 1. **Door three**: Open Language
# The balance Short term leverage comes through door two, with door one opened only on concrete need. Long term ownership is already underway: the grammar is an owned file, the Agreement Corpus with its permission tables is an implementation independent conformance suite.
When the grammar settles the core ports to a small Rust crate compiled three ways — a wasm32-wasi Spin component on port 4246, a browser module for the plugin, a native lib in the Tauri Guide. One core, three targets, joined by the `process` interface of the Guide component model. That shape — tiny deterministic kernel, corpus locked tests, typed seams — is also what makes the codebase good to build against with agents: see Agentic Sustainability.
# Sequence - [ ] wiki-plugin-livecode — door two, pure leverage, no language risk - [ ] The WikiScript evaluator in JS — kernel semantics settle, MUST violation decided - [ ] The stage dialect — WikiScript commands driving embedded stacks - [ ] The Rust core and Spin component — ownership, three targets - [ ] Livecode Server bridge — only if a server side stack need arrives first
# See - WikiScript Architecture and Livecode Wasm - Double Parse and SimpleTalk - Agentic Sustainability and WikiScript Plan