Repository navigation
feat(launcher-standard): add the (js-runtime) bun/bunx launch route, v0.5.0 (D224) - #1100
Merged
Merged
Conversation
…v0.5.0
The launcher standard had no compliant way to say "launch this JavaScript
tool via bun" (owner ruling D224). This adds a (js-runtime) clause to
launcher-standard_praxis.deed and the matching section in
docs/UX-standards/launcher-standard.adoc.
Two routes, tried in ascending :priority order:
- 10 repo-script: the repo commits bun.lock or bun.lockb, so run
`bun install --frozen-lockfile`, then `bun run --bun {script}`.
- 20 pinned-package: `bunx --bun {package}@{exact-version}`, where the
version must be a full x.y.z.
Forbidden: npx, npm exec, pnpm dlx, deno, and latest, ranges or no
version at all.
`--bun` is required. Measured with bun 1.3.14: without it, bun honours a
node shebang, so `bunx <cli>` reports typeof Bun = "undefined". With it,
the same command reports "object".
The adoc example builds the command as an argv array and runs it under
nohup. Tested live: the PID file holds the tool's pid, and the log
shows it ran under Bun. There is also a new checklist item and a
Security bullet against unquoted `$COMMAND`.
:standard-version goes from 0.4.0 to 0.5.0, because the new clause is a
consumer-visible obligation. CURRENT_VERSION and the prose in
check-launcher-standard-currency.sh move with it. Consumers citing
v0.4.0 now get the gate's non-blocking stale-version warning
(standards#991).
Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YSq3UodR3CjsuAK5yoTzHF
Contributor
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 55 minutes. View limit detailsLimit details: You’ve used the included review currently available. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
5 tasks
…d-js-runtime-bun-d224 Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.com>
hyperpolymath
added a commit
that referenced
this pull request
Oct 1, 2026
main took 0.4.0 -> 0.5.0 for the (js-runtime) clause (D224, #1100) while this branch took the same number for the archetype profile and the provisioning mode family. 0.5.0 is published with D224's meaning, so the provisioning obligations are 0.6.0 (2026-10-01): deed :standard-version, the currency gate's CURRENT_VERSION (its test asserts they agree), the .adoc section, the launcher template's compliance claim and provision-modes.sh. A consumer still citing 0.5.0 gets the gate's non-blocking stale-version warning (standards#991), not a failure. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UkSmyapDUmuGyyZSJmvbKy
This was referenced Oct 1, 2026
hyperpolymath
added a commit
that referenced
this pull request
Oct 1, 2026
…isioning modes (#1112) **Supersedes #1096.** The content is identical, rebuilt on current `main` as one signed commit. ## Why a replacement - **Unsigned commits.** Two docstring commits pushed by `coderabbitai[bot]` (`71cad01f`, `18dcefa2`) were unsigned. `required_signatures` refuses a PR that has any unsigned commit on its head, even under squash (`docs/SIGNING-POLICY.adoc` § *Squash signs the result, not the PR branch*). Their content (docstrings, now 74/74 covered) is kept. - **Rebuild.** `git merge --squash origin/feat/provisioning-canon` onto `origin/main`, then `git commit -S`. `git diff 18dcefa HEAD` shows only main's later #1087/#1098 files plus the delta below. The original commit list is in the commit message. ## Delta vs #1096: Hypatia `eval_in_shell` false positives #1096's `Hypatia` code-scanning check and `governance / Validate Hypatia Baseline` were red on 4 `content_patterns/eval_in_shell` findings (`provision-check.sh:23`, `provision-lib.sh:867,868,944`). The rule is a bare `\beval\b`, and every hit is the **word**: the `eval` verb name, or the `.eval/` directory. None is the shell builtin. The fix is an inline `# hypatia:ignore eval_in_shell -- <reason>` pragma on each line, not baseline entries: - `HYPATIA-BASELINE-FORMAT.adoc` lists "single new findings on freshly-introduced code" as a bad baseline entry, and the baseline is a ratcheted exemption ledger. - These files are templates minted into other repos. The pragma travels with them; a standards-only baseline entry would not. - 3 comment lines that newer hypatia (`4065424`) also flags are pragma'd too, so a scanner bump does not turn this red again. **Control:** local `hypatia@4065424 scan` over the two files reports **7** `eval_in_shell` findings on #1096's version and **0** on this branch. `bash -n` is clean for both scripts. Upstream rule precision is tracked upstream in hyperpolymath/hypatia#892 (`eval_in_shell` matches the word, not the builtin in command position). CodeRabbit's last `CHANGES_REQUESTED` (the `launcher.sh.tmpl` header saying modes delegate to the Justfile) is already addressed in this content: l.25–29 say provisioning modes call `build/just/provision-lib.sh` directly. --- ## Original description (#1096) ## What Phase 1 of the estate provisioning campaign. This PR is the canon every repository will be minted from, so that nobody who clones a repo has to search for how to install, configure, run, test, bench, diagnose or repair it. **New: `3-practice/provisioning/`** - `PROVISIONING-STANDARD.adoc` (v1.0.0) and `provisioning-standard_praxis.deed` (lints OK) - **Engine**, identical estate-wide: - `provision.just`: the `provision::` module with every verb - `provision-lib.sh`: bash only, shellcheck clean - `provision-modes.sh`: the launcher dispatch - `provision-check.sh`: the offline conformance checker, covering §8 items 1–5 - **Minted templates:** - `launcher.sh.tmpl` - `mise.toml` (latest plus `mise.lock`) - Guix: a `cargo-build-system` package for Rust, a `copy-build-system` source package for everything else, plus `manifest.scm` and a pinned `channels.scm` - `docs/SETUP.adoc`, the manual route, with a doctor-code troubleshooting table - `docs/AI_INSTALLATION_GUIDE.adoc` - `llm-warmup-{user,dev,maintainer}.adoc` - the README `[[ai-install]]` "Just say it" fragment (the neurophone pattern) - the per-repo `provisioning_praxis.deed` **Launcher standard 0.6.0** (`launcher-standard.adoc` and `launcher-standard_praxis.deed`) - Every repository carries a `launcher.sh`, profiled by archetype. Only `app` has runtime modes; the others print N/A and exit 0. - `--setup`, `--doctor`, `--heal` and `--ai-setup` call the engine directly (`build/just/provision-lib.sh`), so a repo's own root `doctor`/`setup`/`heal` recipe cannot shadow the canon. - Repo-specific checks live in the `doctor-local`, `setup-local` and `heal-local` recipes. A failing `doctor-local` is FAIL PV-E50. **`guix.scm`:** the licence field was a malformed ad-hoc licence object pointing at palimpsest-license. It is now `mpl2.0` from `(guix licenses)`, which is the licence the file's own SPDX header already declares. No licence changes. ## Verified - `deed_lint.py`: - OK on `launcher-standard_praxis.deed` and `provisioning-standard_praxis.deed` - OK on a filled instance of the per-repo deed template - Shellcheck is clean on the engine scripts. - `provision-check.sh` fixture: - The positive control gives rc=0. - 9 mutants each fail on exactly their own check: launcher not executable, root verb missing, module verb missing, banned `python`, banned `aqua:denoland/deno`, no `mise.lock`, guix stub, mechanical slot residue, README SPEC residue. - `--dev` downgrades SPEC residue to a WARN. - doctor-local, in a scratch repo: - A failing `doctor-local` gives PV-E50 and rc=1 via both `./launcher.sh --doctor` and `just doctor`. - A root `doctor` that prints fake green is not executed by `--doctor`. - just floor 1.42.0, measured: a root recipe depending on a module recipe fails on 1.31, 1.36, 1.40 and 1.41. - Guix, via `podman` with `metacall/guix` at ae77aeb: the Rust source package derivation builds (`guix build -d`, rc=0). The non-Rust derivation and the real build were still running when this PR was opened. ## Known, not introduced here - The standards-map gate (Gate D) is already red on `main`, with 5 unmapped top-level entries: `arena-session-787`, `patches`, `ULTRAPLAN-2026-09-24.adoc`, `ULTRAPLAN-2026-09-29.adoc` and `ziz-drop`. This PR adds no top-level entry, because `3-practice` is already mapped. - Dogfooding `mod provision` in this repo's own Justfile is deferred to the pilot phase. ## Update: review round (head b234caf) **Commits since opening** - **206eb6c4 — one placement resolver.** - Each Guix template resolves the repository root from its own location, so a repo can keep the files at the root or under `build/`. This resolves the CodeRabbit placement thread. - Zig is detected up to 3 directories down. - **39b790f5 — no faked zig/bun tests.** - A language with no test command prints an honest N/A. - There is now one AI-install sentence, read from the README by `ai-setup`. - **eaf3a894 — new `fmt-check` verb, the check-only twin of `fmt`.** - Per language: `cargo fmt --check`, `zig fmt --check`, `mix format --check-formatted`, `gleam format --check`, `dune build @fmt`, and bun's `fmt-check` script. - `quality` now depends on this verb. Before, it silently ran `lint`. - **b234caf5 — the remaining review findings.** - `doctor-local.sh` now runs sourced in a subshell. An `exit` or a tripped `set -e` is FAIL **PV-E51**, and the checks it completed still count. - `hp_provision_or_return` replaces `&& exit $?`, which reported success for a failing mode. - The `ai-warmup` argument is now quoted. - trivy is pinned in mise only where a recipe calls it. - The launcher currency constant is now 0.5.0 (0.6.0 after 094fd79, below). - **7e6f3db6 — `toolchain-refresh` regenerates `build/guix/crates.scm`.** - `guix.scm.cargo.tmpl` already promised this, but nothing implemented it. The new lib verb `crates-scm` runs `guix import crate --lockfile`. `GUIX` may name a container wrapper. - The file is written whole or not at all. Output is accepted only when it defines one origin per registry crate in `Cargo.lock`, because a containerised guix loses its exit status. Otherwise the run fails with the new code **PV-E41** and the old file stays. PV-E41 is in the deed, the lib and the SETUP table: all three hold the same 28 codes. - Measured on launch-scaffolder's `Cargo.lock`: - 151/151 origins; - `guix repl` gives `(length %crate-inputs)` = 151 and `origin?` = `#t`; - regeneration is byte-identical. - Mutants killed: - truncated importer output (10/151): rc 1, PV-E41, file sha256 unchanged; - a failing importer (0/151): rc 1, PV-E41, file sha256 unchanged. - **094fd798 — merge `main`; the provisioning modes are launcher standard 0.6.0.** - `main` took 0.5.0 for the `(js-runtime)` clause (D224, #1100). That number is published with that meaning, so the archetype and provisioning obligations move to **0.6.0** (2026-10-01). Updated together: the deed, the `.adoc`, the currency gate's `CURRENT_VERSION`, the launcher template and `provision-modes.sh`. - A consumer still citing 0.5.0 gets the non-blocking stale-version warning (standards#991), not a failure. - Checks: - currency test 19/19; - the gate on this tree: clean at v0.6.0; - `--self-test`: 4 mutants seeded, all detected. **Measured on rsr-template-repo (the first consumer; that PR follows)** - doctor-hook cases: | hook | PASS / WARN / FAIL | |---|---| | normal | 19 / 1 / 0 | | `exit 3` | 19 / 0 / 1 + PV-E51 | | `set -e; false` | 19 / 0 / 1 + PV-E51 | | `fail` | 18 / 0 / 1 | - `./launcher.sh --doctor`: rc 0 when clean, rc 1 with a failing hook. - `just doctor` 18/0/0, `just validate` pass, `provision-check --dev` 0 FAIL / 0 WARN, shellcheck clean. - `fmt-check`: rc 0 on clean code; a mis-formatted mutant gives rc 1. - Guix, via `metacall/guix` at ae77aeb: - `guix build -f guix.scm`: rc 0. - `guix shell -m manifest.scm --dry-run`: rc 0. - `channels.scm` evaluates to the same pinned commit. - `just registry-check` OK. `check-launcher-standard-currency` OK. **Red checks: none is a required check. Classified:** - **Canon/spine lockstep and Map integrity** are already red on `main`: the constitution hash, dogfood-gate, and the ULTRAPLAN / arena-session-787 / patches / ziz-drop entries. #1088 fixes them. - **Repo self-tests:** - This PR's `CURRENT_VERSION` drift is fixed in b234caf. - The docstring shallow-clone failure is also red on `main`. - **Hypatia:** 6 `eval_in_shell` findings are false positives on the `eval` *verb name*: a comment, the `.eval/` report directory, a `case` label, and the verb list. Nothing here calls the builtin. - **Deferred red checks, by context:** `governance / Validate Hypatia Baseline`, `scan / Hypatia Neurosymbolic Analysis` and `Hypatia` → hyperpolymath/hypatia#892. On 094fd79 the baseline gate kept exactly six findings: `eval_in_shell` at `provision-check.sh:23` and `provision-lib.sh:17,732,733,742,804`, all the *word* `eval`. The same three checks are green on `main` 8cfad82. Renaming the user-facing `eval` verb to satisfy the scanner would be the wrong arm. - Fixed at source in hyperpolymath/hypatia#892, with acceptance criteria and positive and negative controls. - Per the owner ruling, this is tracked as an issue, not a blocker. - The 3 `uuid-v7.yml` baseline findings are fixed by #1088. - #1088 also touches `REGISTRY.a2ml`. If it merges first, regenerate the registry here. **Placement labels (elegance arm)** - The engine is **vendored byte-identical** into each repo, and `provision-set --check` will prove it is equal to canon. **This is the elegant long-term arm.** - Departure considered and rejected: fetching the engine at run time. That would break offline and Guix-hermetic use and add a supply-chain hop. - **`channels.scm` is minted, not engine** (departure, labelled). `toolchain-refresh` re-pins it per repo by design, so a byte-compare would go red after every weekly refresh. Instead it is checked for a 40-hex commit pin. ## Update: one banned list, backends and bare names (heads b01a245, bf7c97a) Found by the 8-repo pilot (launch-scaffolder#67). - **b01a245:** - The deed's `:banned-tools` and the engine's `BANNED_TOOLS` had diverged. They are now one 20-item list, plus a new `:banned-backends ("npm" "pipx" "pip" "go")`. launch-scaffolder tests that the deed and the engine agree. - PV-W23 now reads `mise.toml`, `.mise.toml` and `.tool-versions`. - A tool behind a banned backend is flagged whatever its name (`npm:prettier`). - Controls: `.tool-versions` python + `.mise.toml` `"npm:prettier"` → `[python npm:prettier] rc=1`; clean → `[] rc=0`. - **bf7c97a:** a bare name whose only registry backends are banned is flagged too. `prettier` resolves only to `npm:prettier`. - The lookup uses `mise registry`, which works offline. - Shells with no mise and names mise doesn't know are never flagged on a guess. - Controls: `prettier` → `[prettier] rc=1`; `shfmt`/`zig`/an unknown `jest` → `[] rc=0`. - shellcheck is clean, and docstring coverage is 100%. - Pilot gaps that are canon work but not fixed here are filed as #1107. ## Next - the rsr-template-repo canon fix - the `provision-set` generator and the `provisioning-check.yml` gate - a pilot of about 8 repos, then fan-out in SET batches 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01DAKujx2PXHcVSA7vncTNH1 Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Owner ruling D224: the launcher standard had no compliant way to launch a JavaScript tool via bun. This PR adds a
(js-runtime)clause tolauncher/launcher-standard_praxis.deedand the matching section todocs/UX-standards/launcher-standard.adoc, so both halves move together as launcher-standard-lockstep requires. It also bumps:standard-versionfrom 0.4.0 to 0.5.0.The clause
repo-script, whenbun.lockorbun.lockbis committedbun install --frozen-lockfile, thenbun run --bun {script}pinned-packagebunx --bun {package}@{exact-version}, with a full x.y.z versionForbidden:
npx,npm exec,pnpm dlxanddeno.latest, a semver range, or no version at all.Why
--bunis mandatory. Measured with bun 1.3.14, using a paired control:#!/usr/bin/env nodeshebang. Withbunx <cli>, the tool reportstypeof Bunas"undefined".bunx --bun <cli>, it reports"object".bun runbehaves the same way.Why argv arrays. The existing
nohup $COMMANDpattern word-splits and globs its arguments. For a script or package name, that is a command-injection surface. The new example buildscmd=(…)and runsnohup "${cmd[@]}".This PR also adds:
$COMMAND.Verification
scripts/check-launcher-standard-currency.sh --self-test: OK.scripts/tests/check-launcher-standard-currency-test.sh: 19 passed, 0 failed.CURRENT_VERSIONback to 0.4.0 makes the suite's DRIFT check fail (18/1). The file was restored withcp -a.7bcc971):BAKED_STANDARD, launch-scaffolder'sStandard::parsereadsspec_version = "0.5.0".origin/maindeed, exactly two more tests fail (cargo:82 passed; 20 failed, against 18 failed at baseline). Both hard-code"0.4.0":spec_version_is_standard_version_not_schema_versionfalls_back_to_the_baked_copy_when_no_rung_existskill -0succeeds while it runs and fails after it exits), and the log showstypeof Bun = object.deed-conformancerunsdeed_lint.pyon every committed.deedand is path-triggered by this PR.Consumer impact
BAKED_STANDARDand update the two"0.4.0"assertions. That is a follow-up there, not part of this PR.⚠ Separate finding, not caused by this PR. Swapping standards' own unmodified
origin/maindeed into launch-scaffolder fails 18 tests (cargo:84 passed; 18 failed): 15 onstandard is missing the (platforms) clause, 2 on(metadata-block) is missing its (encoding) clause, and 1 content pin. launch-scaffolder's baked copy has drifted ahead of the canonical deed by two clauses. Filed as hyperpolymath/launch-scaffolder#65. (Corrected from an earlier "17"; the first count dropped a test name containing digits.)Refs D224.
🤖 Generated with Claude Code
https://claude.ai/code/session_01YSq3UodR3CjsuAK5yoTzHF