`ludic help` ended with a section titled "contributing to the toolchain itself", listing bootstrap, reseed, docs-gen and release tasks. None of that is available to someone who installed the language — those tasks need the repository — so the shipped tool was advertising work its user cannot do, in a namespace they have to read past to find `new` and `run`. The tasks move to a second program, dev.ludic -> bin/ludic-dev, built from a checkout and excluded from every release artifact. `ludic` keeps the project and package commands and nothing else; `ludic dev …` now explains where the tasks went instead of failing as an unknown command. What this shook out: the two programs share prelude/build/project/pkg, so the helpers each had accreted in whichever file first needed them — cc(), ensure_ludicc, the string functions, title_case, cmd_version — moved to where both can see them. The argument-shift indirection added for the `dev` namespace is gone with the namespace, so commands read argv directly again. `ludic-dev test` asserts the split rather than trusting it: the staged install must build a project, and `ludic dev build` there must fail while naming ludic-dev. install.sh keeps building older tags, whose bootstrap goes through main.ludic. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
982 B
982 B
What & why
Closes #
Checklist
bin/ludic-dev testpasses.- For compiler/runtime changes:
bin/ludic-dev reseed && bin/ludic-dev bootstrap-cfreestill reaches the self-hosting fixpoint with no C compiler in the loop. ludic-fmtleaves the touched files unchanged (2-space, LF, UTF-8).- New/changed stdlib symbols are documented under
docs/language/**and registered intools/docgen/inventory.json(bin/ludic-dev docs-gen && bin/ludic-dev docs-check build/pagespasses). - Commits follow Conventional Commits.
- No new C / Python / JS in tooling (Ludic only), and no generated
artifacts committed outside
build//bin/.