- fork 1: library-ness manifest-declared, kind = "library", default program
- fork 2: privacy = Go internal/ directory rule, named diagnostic at use
- fork 3: dep-boundary-only scope; Go subtree rule recorded as later tightening
- fork 4: lib+bin dual — library default action is check, explicit build works
- Go-inherited rule pinned: internal type in public signature allowed, no check
- impact analysis added: framework loses --emit workaround, plumbing under
internal/; compiler = two seams (driver kind + dep-use refusal WO-E1xx)
- VM zero impact by construction: no .wob change, libs compile whole-program
into consumer image, internal modules still emitted (privacy strips nothing)
- GC zero mechanism impact; pinned: inference stays whole-program, app usage
can promote dep classes, internal/ invisible to gcinfer — intended, not bug
- board + roadmap rows: needs-refinement -> forks settled, spec/plan next
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Brainstorm outcome, deliberately NOT implemented (developer decision: keep
as an iteration needing further refinement). Records:
- the two gaps iterations 15/16 exposed: library-ness is implicit (a
no-main project fails woc <dir> build mode — the framework is verified
via an --emit workaround) and the dep boundary leaks internals (pub has
no dep-private tier: parse_request is as importable as Handler).
- the conventions corpus: Go (package decides program-ness; cmd/;
internal/ = directory-shaped privacy, zero keywords) vs Rust ([lib]/
[[bin]] manifest targets; pub(crate)-family keyword visibility). Doctrine
fit points at Go's shape with an explicit manifest key (writeonce HAS a
manifest; explicit beats inference in errors).
- four open forks for the spec: kind declaration form; internal/ vs
pub(lib) vs export-allowlist; dep-boundary-only vs Go's subtree rule;
lib+bin duality. Draft acceptance criteria; web-app 14/0 as the
regression gate. Roadmap + board rows added.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
