Repository navigation
0.1.8 — A6 measures bun-launched targets, and the record names the wire argv
This release makes A6 — the -- terminator
rule — return a real verdict for targets acc launches through bun. It previously returned
unverified for every such target, permanently, which for an adopter whose every CLI is a bun
script meant the rule could never be measured on the population acc handles best.
Are you affected?
targetArgv0 in your report is an array — look at its first element. It tells you whether
acc launched your tool through bun directly. It cannot tell you whether something it names runs
bun underneath, so if the first element is not bun, you need to know that about your own script.
- It is
bun. This release changes what A6 tells you; read on. You land here when your
file's shebang names bun at any path (#!/usr/bin/env bunand#!/opt/homebrew/bin/bunboth
count — only the final path segment is read), or when it is a.tsfile carrying no shebang. - It is a wrapper script of yours that runs bun underneath. Nothing in this release changes
your verdicts, but read the first bullet under "What is not fixed" anyway — A6 has been,
and still is, judging your tool on an argv it never received. This is the case most worth your
attention, and it is the one this release does not fix. - It is anything else. A6 behaved correctly for you before and still does. Nothing to do.
What changed
A6 no longer refuses bun-launched targets. Bun strips one bare -- immediately after the
script path — one per bun layer between the launcher and the script — before the script sees
process.argv, and A6's probe leads with that terminator, so the probe was never delivered. The
runner now prepends one extra -- at the spawn when it can see that bun is the launcher. Bun
eats the extra one; the target receives what a native target receives.
Measured: on this repository's own CLI, launched through bun, A6 now reports pass where it
reported unverified; on kit/fixtures/broken/ignores-double-dash.ts, also launched through
bun, it reports fail.
What a consumer has to act on
Verdicts move. If your targetArgv0 starts with bun, A6 changes from unverified to
pass or fail. Automation that treated A6's unverified as a fixed property of bun targets
should stop assuming it. A6 stays diagnostic, so a new fail does not move your exit code or
your conformant claim. For a target launched through bun it is a real measurement that your
tool did not honour --, so read the rule page rather than filtering it out. Behind a wrapper it
is not — see "What is not fixed".
New optional field in the report JSON: launchAdjustment, on an observation. It is present
only when the argv acc itself put on the wire differed from that observation's recorded args.
It reports what acc did at the spawn, and cannot see a launcher below that — a wrapper that
eats the terminator internally produces no launchAdjustment, because acc spawned exactly what
it recorded.
Today the only source is this bun compensation. Its value is a single line of prose — do not
parse it programmatically, branch on the key's presence instead. Do read it when replaying a
probe by hand: the wire argv is spelled out inside it. Example (wrapped here for width; the real
value contains no newline):
one `--` was prepended for the bun launcher and consumed before delivery; the wire argv was
["bun","/abs/path/cli.ts","--","--","--acc-probe-xyzzy-value"]
The recorded args are not the wire argv, so a hand replay of args alone against a bun target
will not reproduce the kit's run. They stay uncompensated so that A6's evidence id and
acc compare's alignment do not fork between bun and non-bun targets. See
how to read the check report JSON.
What is not fixed
- A wrapper script that hides a bun layer is still uncompensated. The deleted
unverified
short-circuit keyed on the target'sargv0namingbun, and a wrapper arrives as its own
path — so it never matched that guard, and was already collecting a verdict measured against
an argv it never received. What is new is that this is now a named A6 coverage gap instead of
a silent one. Measured: a conforming.tsfixture reports A6passpassed directly and
failbehind a one-lineexec bunwrapper. Pass a direct path wherever you have one. - The compensation is by exactly one
--, and that is a property ofacc, not of bun.
Measured on bun 1.4.0: stripping is one per bun layer —bun <script>strips one, but
bun run <script>interposes a second layer and strips two. One is the right amount only
becauseaccnever constructs a launcher deeper than a single bun layer, which a test asserts. - A
bun build --compilebinary needs no compensation and gets none: measured, it strips
nothing. - A7 still carries its caveat. The
eight owner-CLI run measured both A6 and A7 as
unverifiedacross all eight targets. A6's cause is addressed here; A7's prose extractor
still finds no closed value set to falsify on that population, and that run has not been
repeated against this change.
Provenance
All bun behaviour above was measured on bun 1.4.0, macOS (darwin 25.6.0), and is written up in
docs/research/2026-08-29-bun-terminator-stripping.md.
README.md, STANDARD.md, the A6 rule page, the probing concept, the JSON report guide, the
first-CLI tutorial and the checker-authoring guide were repaired to match the new behaviour. The
repository's full gate — typecheck, lint, markdown format, both doc linters and the test suite —
is green at 1771 tests.
0.1.8 (2026-08-29)
Bug Fixes
- kit: A6 measures bun-launched targets instead of refusing them (dbfee51)
- kit: A6 measures bun-launched targets instead of refusing them (a12ddea)
- kit: A6 reaches the bun population (7949ae9)
- kit: the A6 terminator survives a bun launcher (4d17a4f)
- kit: the A6 terminator survives a bun launcher (8e0f233)
- kit: the record says which argv it means (37eabae)
- kit: the record says which argv it means (06f81f0)