Found by driving the compiled log-watcher's third path — the MCP server. It now
answers real JSON-RPC over HTTP: initialize returns protocolVersion/serverInfo,
tools/list returns the full tool list (1049 bytes of generated JSON), and an
unauthorized request gets 401 {"error":"unauthorized"}. corpus 71/0, woc 565/0,
wovm gates green.
- lexer: `\r` and `\0` escapes. Without `\r` a program cannot write CRLF at
all — the server's `index_of(buf, "\r\n\r\n")` was searching for a literal
backslash-r, so it never found a header terminator and hung on every request
- parser: an interpolated sub-expression now mints node ids from the OUTER id
space. A fresh sub-parser started at 1, so `${...}` nodes collided with the
file's own nodes — and every side table (drops, moves, rc, masks, f_decl) is
keyed by node id. Surfaced as WO-E404 "ownership table names `headers`,
which has no register"; silent misattribution otherwise
- types.ml: `net.Conn` is a reserved SCALAR type (a file descriptor). It was
falling through as "some user class", i.e. WO_K_OWNED, so the frame would
DROP an integer at scope end
- types.ml: confident_typ knows `..` yields Text. Interpolation desugars to a
Concat chain, so without it every interpolated value looked underivable —
which is why the `+`-on-Text check missed two live sites in the workload
- `m[k]` on a map is now the OPTIONAL read (nil for a missing key), while
`get(m, k)` stays the asserting one that traps KEY. That is what makes
`let v = m[k]; if v != nil` — the workload's header lookup — work.
trap/missing-map-key now pins `get(...)`, and the surface doc records the
split
- json.encode of a `json.Value` emits it verbatim (kind 255): an echoed id was
coming back as "1" instead of 1
- disasm: TRY/ENDTRY render instead of ?OP32/?OP33
- status board: the push-of-a-borrowed-Text gap is now recorded with the
concrete failure it produces (tools/call tail_log), plus the leaked
temporary-record shell found in the same disassembly
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .dev | ||
| .vscode | ||
| compiler | ||
| crates | ||
| docs | ||
| infra | ||
| prototypes/wo-db | ||
| runtime | ||
| scripts | ||
| static | ||
| templates | ||
| tests/corpus | ||
| .gitignore | ||
| .gitmodules | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CLAUDE.md | ||
| justfile | ||
| prompt.md | ||
| README.md | ||
writeonce
A declarative full-stack programming language. You write .wo files; the runtime compiles them into a binary that owns the database, serves REST, and pushes live subscriptions — no external database, no external web server, no frontend framework.
Think Go + Postgres + net/http + Phoenix LiveView, folded into one language and one binary.
persistant database
- reads and writes database to RAM, persist data to postgres SQL.
- The entire database lives in RAM; every committed write is mirrored to PostgreSQL as a backup — asynchronously, behind the runtime's own WAL, never in the read or ack path. Set
WO_PG=postgres://user@host:5432/dband every type's rows appear as a Postgres table (named by its@table(name: ...)annotation) that you can query with plainpsql. Plan and phases:docs/plan/16-postgres-mirror.md; try it:just pricing-pg-demo.
Quickstart
git clone https://github.com/shoneyJ/writeonce
cd writeonce
cargo run --bin wo -- run docs/examples/blog # serve the sample blog on :8080
curl http://127.0.0.1:8080/api/articles # it's a real REST API now
See .dev/reference/rest/blog.rest for a preconfigured HTTP-request file that drives the whole sample — open it in VS Code (with the REST Client extension) or JetBrains and click "Send Request" on each block.
What this repository contains
| Path | What it is |
|---|---|
crates/rt/ |
The new .wo language runtime — lexer, type-DSL parser, in-memory engine, axum REST server. Produces the wo binary. |
crates/{ql,value,engine,txn,db,wal,sub,http,gen,policy,logic,service,ui,app}/ |
14 empty placeholder crates scaffolded for Phases 2–6. Real code extracts from rt/ as each phase activates. |
docs/runtime/wo-language.md |
Start here. The language overview: toolchain, hello-world, stdlib, client model. |
docs/runtime/database.md |
The 7-phase engineering series that drives the runtime's design. |
docs/examples/blog/ |
Sample .wo project: blog with articles, authors, tags, comments. ~200 lines. |
docs/examples/ecommerce/ |
Sample .wo project: storefront + live order-ops table + cross-paradigm checkout. ~300 lines. |
prototypes/wo-db/ |
C++ prototype of the query-layer engine (SQL + Cypher + document paths, RETURNING aliases, LIVE stub). ~2k lines, smoke tests pass. Reference implementation the Rust port follows. |
.dev/reference/rest/ |
.rest files (VS Code REST Client / JetBrains HTTP format) for manually testing the running prototype. |
.dev/reference/crates/ |
The v1 writeonce blog — 13 Rust crates implementing the original .seg + sidecar-index storage engine and .htmlx templating. Preserved as a nested workspace; see .dev/reference/README.md. |
Current stage
The runtime is under active development. Each stage lands as an independently shippable cut:
| Stage | What works | Status |
|---|---|---|
| 1 | wo run <dir> discovers every .wo file under a directory |
✅ shipped |
| 2 | Type-DSL parser, in-memory engine, REST CRUD (list / get / create / update / delete) generated from service rest blocks, JSON bodies with auto-id, default-value seeding, partial-update PATCH |
✅ shipped — cargo run -- run docs/examples/blog |
| 3 | LIVE subscriptions over WebSocket, delta frames on commit, me / session layer |
pending |
| 4+ | Transactional fns (fn checkout in txn snapshot), row-level policies, type-attached triggers, ##ui SSR, WAL durability, codegen |
see docs/runtime/database.md |
cargo test --lib at the root runs 14 unit tests covering the lexer, parser, compiler, and engine. Stage-3 endpoints respond 501 Not Implemented until they land.
Build & test
cargo build # builds all 15 crates (only `rt` has real code)
cargo test --lib # 14 unit tests
cargo run --bin wo -- run docs/examples/blog # serve the blog sample
cargo run --bin wo -- run docs/examples/ecommerce # serve the ecommerce sample
# Override the listen address
WO_LISTEN=127.0.0.1:9000 cargo run --bin wo -- run docs/examples/blog
The v1 codebase (reference)
The original writeonce blog engine — 13 crates, flat-file .seg storage, sidecar indexes, .htmlx templates, hand-rolled epoll event loop — moved to .dev/reference/crates/ when the new runtime was scaffolded. It's a nested Cargo workspace:
cd .dev/reference/crates
cargo build # all 13 v1 crates still compile
cargo test # 12 unit tests, 1 ignored integration test
V1 crates keep the wo- prefix (wo-seg, wo-store, …). The new runtime crates dropped it (ql, value, engine, …). docs/runtime/database/07-wo-seg-migration.md is the phased coexistence plan for replacing v1 with the new runtime — abstract behind a trait, dual-write, cut over, decommission.
License & status
Work in progress. Nothing here is stable. Read the language overview in docs/runtime/wo-language.md if you want to know the shape; read the phase docs if you want to see the engineering plan; look in docs/examples/ if you want to see what the end product feels like.