A hyphen in a use target is a path separator; and a primitive is not a module #9895

Re-filed from #7506. An attempt claimed that issue on 2026-10-07 and left an empty branch, and a dispatch row that has spent its retry ceiling keeps its issue for good - so no bee could take it again, however much the brief improved. The work below is carried over unchanged.

Re-filed from #5267. An attempt claimed that issue on 2026-10-01 and left an empty branch, and a dispatch row that has spent its retry ceiling keeps its issue for good - so no bee could take it again, however much the brief improved. The work below is carried over unchanged.

Re-filed from #2697. An attempt claimed that issue on 2026-09-24 and left an empty branch, and a dispatch row that has spent its retry ceiling keeps its issue for good - so no bee could take it again, however much the brief improved. The work below is carried over unchanged.

Two more ways a use target failed to resolve, both found by ranking what
blocks the most otherwise-clean specs.

1. A hyphen in a use target is a path separator.

use provider-schema::Message;   ->  specs/provider/schema.t27
use lsp-schema::DiagnosticSeverity;  ->  specs/lsp/schema.t27

Checked against the tree rather than assumed: provider, lsp, bus, sync,
config and runtime all resolve this way -- six of the seven hyphenated
targets in the corpus. Applied only as a FALLBACK, because a spec file may
legitimately carry a hyphen and specs/physics/gamma-conflict.t27 would
otherwise be split into a directory that does not exist.

The seventh, tritype-base (14 occurrences), resolves to nothing: there is no
specs/tritype/base.t27. The symbols it imports -- Trit, trit_negate,
trit_multiply -- are declared in specs/base/types.t27, so it looks like a
stale name rather than a missing file, but renaming it is a corpus decision and
is left alone.

2. use tritype-base::usize; imports a primitive. There is no module to
load, and const @"usize" = @import(...) shadows the builtin, so it is
meaningless twice over. 6 specs were blocked on usize.zig: FileNotFound.
Skipped now, for every Zig primitive type name.

A regression the VALID count could not show. The hyphen change first bound
the module under its last segment, so use runtime-process::{ProcessID, ...}
became const process = ... while the body says runtime_process.generate_pid().
14 undeclared identifiers in one spec, 12 in another -- and zero specs crossed
from VALID to invalid, because they were already invalid. Only the per-spec
error delta showed it. Fixed by binding under the name the spec uses.

Measured:

The +5 is two specs that got past their import wall and had their own defects
become countable -- unused function parameter in sync/index. Errors going
up here is the instrument working.

Original file list

• specs/base/types.t27
• specs/lsp/schema.t27
• specs/physics/gamma-conflict.t27
• specs/provider/schema.t27
• specs/tritype/base.t27

The instruments

Every one of these reads and prints; none of them writes. Run them from the repository root, with <spec> replaced by the file in ## Boundary:

.t27 is not Rust and not Zig, and a bee fluent in either writes one by
accident. Measured 2026-09-20: a bee filled eight bodies in
specs/file/watcher.t27 with return Ok(());, Err(FileError::WatcherNotFound)
and for i in 0..watchers.length. The parse ratchet refused the whole file --
Unexpected token in expression: RParen, line 123 -- and a spec that does not
parse generates nothing, so every test it already carried stopped running.

At the top level the parser accepts exactly these eight forms, with an optional
pub, and no others:

const   var   fn   enum   struct   test   invariant   bench

There is no trait, no impl, no type X = ..., no generics, no macro. What
a bee reaches for from another language, and what happens:

• Rust's result sugar (Ok(()), Err(E::V), ?) is not a construct here.
• Rust macros (println!, format!, vec!) are not constructs here.
• A range loop (for i in 0..n) is Rust and Zig, not this language.
• Zig builtins (catch unreachable, @intCast, @constCast) are not constructs here.
• Cross-module reuse (use other::fn;) parses and then generates a comment and an unqualified call, so the Zig fails with use of undeclared identifier (use a::b; generates no import, so no spec can reuse a function from another spec #4298). It does not work yet.

t27c parse <spec> answers in one line whether what you wrote is the language.
Run it before you report, every time.

• t27c spec-status <spec> - the compiler's one-word verdict: IMPLEMENTED, PARTIAL, UNWRITTEN, NOPARSE, NOFN. Exit code is 0 whatever it says, so read the word.
• t27c symbols <spec> - every name the file declares, with its kind. Answers "does this already exist here?" before you add it.
• t27c outline <spec> - per function: its locals, what it calls, what it returns. The contract you are implementing against.
• t27c coverage <spec> - which functions have a test and which do not. The issue asks for tests; this is how you check you wrote them.
• t27c lint <spec> - style and shape warnings. It OVER-REPORTS has no test or invariant: measured 2026-09-20 over 60 specs it printed 677 of those where coverage found 190 untested functions, disagreeing on 59 of the 60 - it warns about bit_to_trit_pair in specs/base/ternary_encoding.t27, which test bit_to_trit_pair_zero calls on line 249. Read it as a hint; coverage is the answer.
• t27c typecheck <spec> - types, before generation. Prints Typecheck OK (0 errors, 0 warnings) or the errors.
• t27c test-report <spec> - builds this spec and runs its own tests, which is what the oracle does. BLOCKED means the generated Zig does not compile, with the error beside it.
• python3 tools/dupe_scan.py --name <function> - where that function already lives, if it does. 576 of 4021 bodies here are byte-identical copies.

The rest of the toolbelt is in docs/BEE_TOOLBELT.md.

Queen-runnable restatement (2026-10-05)

The compiler half of this issue is on master: hyphenated use paths landed in #2733 (dacffeb) and #2882 (069ca03), and t27c gen now prints // use usize: no references in this module instead of importing a primitive. What the issue explicitly left alone is still open: tritype-base resolves to no file (there is no specs/tritype/base.t27; the name is only the module tritype-base; line of specs/base/types.t27), yet 14 use tritype-base::... lines in 12 specs still name it, 9 of them importing the primitive usize. The symbols it imports (Trit, trit_negate, trit_multiply) are declared in specs/base/types.t27, which 389 other use lines already reach as base::types. This restatement asks for that corpus rename.

Boundary

• specs/ternary/bigint.t27
• specs/vsa/vsa_core.t27
• specs/jit/jit.t27
• specs/provider/transform.t27
• specs/provider/schema.t27
• specs/provider/stream.t27
• specs/provider/adapters.t27
• specs/bus/schema.t27
• specs/bus/pubsub.t27
• specs/lsp/protocol.t27
• specs/lsp/schema.t27
• specs/lsp/language.t27

User Scenarios & Testing

• Given 12 specs on master import from tritype-base, a module that does not exist, when each use tritype-base::usize; line is deleted and each other use tritype-base::X; is rewritten to use base::types::X;, then no spec names tritype-base, the three specs that import Trit name base::types, and every touched spec still parses.

Requirements

• FR-001: The change MUST remove every use tritype-base::usize; line (a primitive is not a module) and MUST rewrite every remaining use tritype-base::X; to use base::types::X;, the module that declares Trit, trit_negate and trit_multiply.
• FR-002: Every touched spec MUST still parse, and its existing tests MUST stay (no test or function deleted to make a count).
• FR-003: The change MUST NOT edit specs/base/types.t27; its module tritype-base; line stays.
• FR-004: The change MUST NOT add or modify non-t27 hand-written code (specs/policy/own_language.t27).

Success Criteria

• grep -rn 'use tritype-base' specs | wc -l prints 0
• grep -c 'use base::types::Trit' specs/ternary/bigint.t27 prints 1
• grep -c 'use base::types::Trit' specs/jit/jit.t27 prints 1
• grep -c 'use base::types::Trit' specs/vsa/vsa_core.t27 prints 1
• t27c spec-status specs/vsa/vsa_core.t27 prints IMPLEMENTED
• t27c spec-status specs/ternary/bigint.t27 does not print NOPARSE
• t27c spec-status specs/lsp/language.t27 does not print NOPARSE

The instruments

Every one of these reads and prints; none of them writes. Run them from the repository root, with <spec> replaced by the file in ## Boundary:

.t27 is not Rust and not Zig, and a bee fluent in either writes one by
accident. Measured 2026-09-20: a bee filled eight bodies in
specs/file/watcher.t27 with return Ok(());, Err(FileError::WatcherNotFound)
and for i in 0..watchers.length. The parse ratchet refused the whole file --
Unexpected token in expression: RParen, line 123 -- and a spec that does not
parse generates nothing, so every test it already carried stopped running.

At the top level the parser accepts exactly these eight forms, with an optional
pub, and no others:

const   var   fn   enum   struct   test   invariant   bench

There is no trait, no impl, no type X = ..., no generics, no macro. What
a bee reaches for from another language, and what happens:

• Rust's result sugar (Ok(()), Err(E::V), ?) is not a construct here.
• Rust macros (println!, format!, vec!) are not constructs here.
• A range loop (for i in 0..n) is Rust and Zig, not this language.
• Zig builtins (catch unreachable, @intCast, @constCast) are not constructs here.
• Cross-module reuse (use other::fn;) parses and then generates a comment and an unqualified call, so the Zig fails with use of undeclared identifier (use a::b; generates no import, so no spec can reuse a function from another spec #4298). It does not work yet.

t27c parse <spec> answers in one line whether what you wrote is the language.
Run it before you report, every time.

• t27c spec-status <spec> - the compiler's one-word verdict: IMPLEMENTED, PARTIAL, UNWRITTEN, NOPARSE, NOFN. Exit code is 0 whatever it says, so read the word.
• t27c symbols <spec> - every name the file declares, with its kind. Answers "does this already exist here?" before you add it.
• t27c outline <spec> - per function: its locals, what it calls, what it returns. The contract you are implementing against.
• t27c coverage <spec> - which functions have a test and which do not. The issue asks for tests; this is how you check you wrote them.
• t27c lint <spec> - style and shape warnings. It OVER-REPORTS has no test or invariant: measured 2026-09-20 over 60 specs it printed 677 of those where coverage found 190 untested functions, disagreeing on 59 of the 60 - it warns about bit_to_trit_pair in specs/base/ternary_encoding.t27, which test bit_to_trit_pair_zero calls on line 249. Read it as a hint; coverage is the answer.
• t27c typecheck <spec> - types, before generation. Prints Typecheck OK (0 errors, 0 warnings) or the errors.
• t27c test-report <spec> - builds this spec and runs its own tests, which is what the oracle does. BLOCKED means the generated Zig does not compile, with the error beside it.
• python3 tools/dupe_scan.py --name <function> - where that function already lives, if it does. 576 of 4021 bodies here are byte-identical copies.

The rest of the toolbelt is in docs/BEE_TOOLBELT.md.

The instruments

Every one of these reads and prints; none of them writes. Run them from the repository root, with <spec> replaced by the file in ## Boundary:

.t27 is not Rust and not Zig, and a bee fluent in either writes one by
accident. Measured 2026-09-20: a bee filled eight bodies in
specs/file/watcher.t27 with return Ok(());, Err(FileError::WatcherNotFound)
and for i in 0..watchers.length. The parse ratchet refused the whole file --
Unexpected token in expression: RParen, line 123 -- and a spec that does not
parse generates nothing, so every test it already carried stopped running.

At the top level the parser accepts exactly these eight forms, with an optional
pub, and no others:

const   var   fn   enum   struct   test   invariant   bench

There is no trait, no impl, no type X = ..., no generics, no macro. What
a bee reaches for from another language, and what happens:

• Rust's result sugar (Ok(()), Err(E::V), ?) is not a construct here.
• Rust macros (println!, format!, vec!) are not constructs here.
• A range loop (for i in 0..n) is Rust and Zig, not this language.
• Zig builtins (catch unreachable, @intCast, @constCast) are not constructs here.
• Cross-module reuse (use other::fn;) parses and then generates a comment and an unqualified call, so the Zig fails with use of undeclared identifier (use a::b; generates no import, so no spec can reuse a function from another spec #4298). It does not work yet.

t27c parse <spec> answers in one line whether what you wrote is the language.
Run it before you report, every time.

• t27c spec-status <spec> - the compiler's one-word verdict: IMPLEMENTED, PARTIAL, UNWRITTEN, NOPARSE, NOFN. Exit code is 0 whatever it says, so read the word.
• t27c symbols <spec> - every name the file declares, with its kind. Answers "does this already exist here?" before you add it.
• t27c outline <spec> - per function: its locals, what it calls, what it returns. The contract you are implementing against.
• t27c coverage <spec> - which functions have a test and which do not. The issue asks for tests; this is how you check you wrote them.
• t27c lint <spec> - style and shape warnings. It OVER-REPORTS has no test or invariant: measured 2026-09-20 over 60 specs it printed 677 of those where coverage found 190 untested functions, disagreeing on 59 of the 60 - it warns about bit_to_trit_pair in specs/base/ternary_encoding.t27, which test bit_to_trit_pair_zero calls on line 249. Read it as a hint; coverage is the answer.
• t27c typecheck <spec> - types, before generation. Prints Typecheck OK (0 errors, 0 warnings) or the errors.
• t27c test-report <spec> - builds this spec and runs its own tests, which is what the oracle does. BLOCKED means the generated Zig does not compile, with the error beside it.
• python3 tools/dupe_scan.py --name <function> - where that function already lives, if it does. 576 of 4021 bodies here are byte-identical copies.

The rest of the toolbelt is in docs/BEE_TOOLBELT.md.