Repository navigation
0.1.6 — the upgrade remedy stops wiping your cache
Four things a consumer acts on: the upgrade remedy, the install transport, a
duplicate-entry failure that is easy to mistake for the other two, and a new
field in the error envelope. Everything else is method and report work that
changes no behaviour, listed at the end.
THE UPGRADE REMEDY NO LONGER WIPES YOUR WHOLE BUN CACHE. acc version --check
on exit 10 — "a newer release exists" — used to hand every caller three
commands: bun remove, then bun pm cache rm, then a pinned bun add over
git+ssh://. The middle one clears bun's ENTIRE global cache and takes no
package argument — which on a shared CI runner means cold-caching every
dependency of every job sharing it. It is gone from the sequence. What exit
10 prints now, and what it puts in the machine-readable next array, are
generated from one source so they cannot drift:
bun remove agent-cli-conformance
bun add -d git+https://github.com/ichabodcole/agent-cli-conformance.git#<tag>
acc version --check
WHY IT WENT. Measured on bun 1.4.0 against this repository while it is public
— both conditions load-bearing, and a bun release, a private fork or a
non-GitHub host could change either. Under them, bun normalises
git+https://github.com/… to github:owner/repo: the two spellings produce
one @GH@<owner>-<repo>-<sha> cache entry and no bare clone. git+ssh://
produces a bare clone (<hash>.git, carrying a HEAD) plus a @G@<sha>
entry. Both were read off the cache directory after installing each way. The
stale-bare-clone refusal — no commit matching "…" — that the wipe existed to
clear needs that clone. The wipe was correct when it was written, because
the sequence then printed git+ssh://, which does create one. What
invalidated it is the transport change in this same release: the sequence now
prints git+https://, and on that line there is no clone to clear. Two
consequence checks on the new line agree with the cache reading: a pinned
v0.1.4 → v0.1.5 upgrade in one warm cache exits 0 with no refusal, and
an unpinned install into a package.json holding no entry, against a cache
holding only 0.1.4, delivered 0.1.5.
The command is not deleted. Exit 10 now prints it in a paragraph addressed
to callers whose install line is git+ssh://, with its cost attached, and
docs/wiki/guides/how-to-fix-a-broken-install.md keeps it as that transport's
remedy. ⚠ That paragraph is prose only: the next array carries the three
commands above and nothing conditional, so a PROGRAM reading next on an ssh
install does not receive the cache step. Until that is closed, a program that
may run on either transport should read its own dependency URL from
package.json and, when it is git+ssh://, FAIL LOUDLY rather than proceed —
do not silently insert the cache step, which is the one command this release
exists to keep out of CI. next is advisory, and this is the one case where
it is incomplete rather than wrong.
The tests that asserted the wipe was present did not just go. They now assert
the invariant behind both versions of this mistake — every command in the
sequence either remedies a failure that reproduces on the transport the
sequence prints or verifies the result, ordered so it works — plus one test
that does nothing today and requires any reinstated whole-cache step to carry
its own cost in its own description.
IF YOU ALREADY HAVE acc INSTALLED, YOUR OWN KIT STILL PRINTS THE OLD
SEQUENCE. (Installing for the first time? Skip to the install documents below;
none of this paragraph applies to you.) The fix ships in the binary, so it
arrives only once you have upgraded — and the message that prompts an upgrade
is the one carrying the old advice. This note is the way around that. If
your install line is the git+https:// one above, run the three commands
here instead of the ones your installed acc version --check prints, and get
<tag> from:
git ls-remote --tags --refs --sort=-v:refname \
https://github.com/ichabodcole/agent-cli-conformance.git 'v*' \
| grep -oE 'v[0-9]+\.[0-9]+\.[0-9]+$' | head -1
If you are on git+ssh:// deliberately — a contributor with a key, a
private fork, or a network whose proxy rewrites github.com — do NOT paste the
https line: it points at a repository that is not yours or a transport your
network will not serve. Keep your own URL and put bun remove first, for the
reason below. On that transport bun pm cache rm before the add is doing real
work — and it carries the same cost there as anywhere: it clears bun's WHOLE
cache, takes no package argument, and does not belong in CI or a build step.
Derive your <tag> by pointing the ls-remote line at YOUR OWN remote, not
the one above.
THE INSTALL IS ANONYMOUS. This repository is public. Every live surface that
named the install still said otherwise, and the claim was load-bearing: it is
why every documented command used git+ssh://. Measured with the global git
config disabled and terminal prompts off, on a machine whose other credential
paths were not exercised: an anonymous git ls-remote https://… answers with
the tags, and bun add -d 'git+https://…#<tag>' installs at exit 0 and
delivers that tag. So https leads now everywhere the old claim reached: the
README, the acc skill's step 1, the install guide, the L0 guide, the wiki's
routing row, the exit-10 output, and the remote list acc version --check
tries. Against THIS repository, on a network that reaches github.com directly,
that means a CI runner or a sandboxed agent needs no key, no token and no
credential helper — which is the case the old ssh-only line could not serve at
all.
git+ssh:// is not dropped: still the second remote tried, still what a
contributor with a key uses, still what survives a rewriting proxy, still what
a private fork needs. GIT_TERMINAL_PROMPT=0 stays — the guard is about what
happens when a read does NOT succeed, which is when nobody is watching.
THE INSTALL DOCUMENTS NOW SEPARATE A FIRST INSTALL FROM AN UPGRADE. The
skill's step 1 derives the current tag with the ls-remote line above and
asks you to substitute it into the pin. The placeholder is deliberately not a
shell variable: an interpolated empty ref leaves a bare #, which resolves
exactly as no ref does — measured both ways against one seeded cache, same
result — while looking pinned in the package.json you commit. Against a
cache already holding an older resolution that is what you get: exit 0, an
older kit, and a committed URL that reads as pinned. Pasted unsubstituted the
add refuses at exit 1 and changes nothing, also measured, on a fresh
project and on one already holding the dependency.
⚠ ADDING OVER AN EXISTING ENTRY IS A THIRD THING TO ACT ON, and it is not
the same as the stale-cache failures above. bun add pointed at a new ref
does not replace the dependency: it appends a SECOND entry under the same key
and resolves the first — measured on bun 1.4.0, with no warn: Duplicate key
printed at all, and with the success line naming the sha you asked for while
the other one installs. That is why the two measurements in this note differ
rather than disagree: an unpinned install into a package.json with NO entry
resolved fresh and delivered the newest release, while an add over an existing
entry delivered the old one. Whether your package.json already names this
dependency is what decides which you are in. bun remove first is the fix, on
every transport, which is why it leads the sequence.
The guide documents three ways an install hands you the wrong bytes — the
duplicate key, the stale bare clone, and a stale extracted package — and each
is now scoped, in the guide and in the README and the wiki row that route to
it, to the transport that can produce it. On git+https:// only the duplicate
key is reachable, so a reader there is no longer sent hunting a stale bare
clone they have no way to create. (These three are failures, not the four
changes this note opens with; they are different lists.)
EXIT-2 REFUSALS NOW SAY WHICH REFUSAL THEY ARE. acc report and acc compare
refuse a bad input file with exit 2, and until now nothing machine-readable
separated the cases — which matter differently: a corrupt file needs fixing,
and a well-formed file that is not a report needs a different command run over
it. Each refusal now carries a stable details.reason in the error envelope:
not-json the file is not JSON at all — it is corrupt or truncated.
`acc report` and `acc compare`.
not-a-report valid JSON, but not an `acc check` report — it lacks the
target and observations. Most likely a recorded batch or a
different tool's output; run `acc check` to produce a report.
`acc report` and `acc compare`.
no-verdict an `acc check` report carrying observations but no verdict,
so there is nothing to render. `acc report` only — `acc
compare` never needed a verdict and never conflated this.
not-json and not-a-report come from the loader both commands share, so
they appear identically in each; that is read from the shared code path, and I
ran all three against acc report rather than all five combinations. No exit
code was added or changed, and the field is additive, so nothing branching on
exit codes today behaves differently.
NOT CHANGED: no command, flag or exit code added or removed. The test suite is
green — 1740 tests across 55 files, bun 1.4.0.
INTERNAL, and a consumer acts on none of it, with one exception. The
cold-repair method page gains a pre-edit dependency-list stage, two named seam
checks and a second defect class kept deliberately out of its counts; a
per-class baseline for the two earlier runs was recovered from evidence
already in the tree, so the next run has something to compare against. The
exception, for anyone working on the probe-plan proposal: it recorded that the
warrant behind its BREAKING recorded.ts format change has expired, and that
the conclusion has NOT been re-made against the new facts. Do that before
acting on that section.