The manifest pinned `[build] runtime = "../../../runtime/wovm"`, a repo-only
relative path that overrides woc's runtime resolution — so `woc <copied-dir>`
failed off-repo (e.g. an installed toolchain on a test server) with "runtime
binary not found".
- Drop the [build] section: the project no longer hardcodes a machine path, so
an installed `woc` self-locates `wovm` beside its own binary.
- The module justfile's `build` recipe now sets WO_RUNTIME=<repo>/runtime/wovm
so the in-repo build still uses the freshly built VM.
- Acceptance is unaffected (it compiles via `woc --emit` + an explicit $WOVM,
never the manifest [build] key).
Verified: just log-watcher::build OK; just log-watcher 7/0; and building a
copied tree with the installed-layout woc from an unrelated cwd self-locates
the sibling wovm and produces a runnable binary.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- a directory carrying wo.toml is a PROJECT: `woc .` inside it (or
`woc path/to/project` from anywhere) reads the manifest and produces
<target>/<name>, exactly what `woc build <dir> -o ...` produces
- schema is the one the sample already carried -- top-level name/
version/description, [runtime] wo (accepted, not yet enforced) --
plus a new [build] section: runtime (wovm to prepend) and target
(output dir, default "target"), both relative to the manifest's own
directory so the build is invocation-point independent
- unknown keys and sections are hard errors: a typo'd key silently
ignored would build the wrong thing
- directories WITHOUT wo.toml keep check-only semantics -- the corpus
is full of those; oop-e2e 71/0, woc-test 565/0, log-watcher 7/0
- sample's wo.toml gains the [build] section; target/ gitignored
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
