v0.1.7

Two ways Forgelore was quietly failing to recognise an error it already
knew, both found by watching a real agent rather than by a test.

Fixed

A chained command is attributed to the tool that produced the error.
An agent writes cd web && npm run build far more often than it runs a
build on its own. Command normalisation took the first word, so a compiler
diagnostic was fingerprinted under cd — or, in the session that found
this, under ls:

ls -a && go build ./... 2>&1 | head -40

That fingerprint matched nothing, and nothing is what the agent got. The
same session then ran the plain command and the hint appeared, which is
what made the cause certain. A chain is now reduced to its last link before
anything else applies.

It is a guess, and it is wrong for go build ./... && echo ok, where the
error comes from the first link. It is the better guess: a chain is written
to reach its last command.

A package manager is the tool, not its subcommand. npm, yarn and
pnpm were treated like npx, so npm run build normalised to run and
npm test to test. A script name is not a tool, and whatever the script
invokes is nowhere on the command line — so one error was fingerprinted
separately under every script that could provoke it. They now normalise to
the package manager, exactly as go build and go test both normalise to
go.

npx and bunx still hand over to the binary they name, and so do the
subcommands that genuinely name one: npm exec, pnpm exec, yarn dlx,
bun x.

One case gets worse: yarn tsc now gives yarn rather than tsc. Yarn 1
allows running a binary directly, but a script and a binary cannot be told
apart from the command line, and the script form is far more common.

Does this change existing records?

Only for commands that were never matching. A record whose fingerprint came
from a plain command — go build ./..., npx tsc — is unaffected. If you
recorded a fix under npm run build or a chained command before this
release, re-record it or run forgelore dedupe to find the pair.

Also verified in this release

Claude Code 2.1.290, with both corpora kept and replayed. scratchpad_dir
is gone from every event where 2.1.289 carried it on all four; nothing
breaks, because session state falls back to the store's own cache.

Gemini CLI is supported and verified against 0.62.0 — hooks, tier B.
Its AfterTool reports a failing command's exit code inside llmContent
rather than in the documented error field, and the wrapper it puts around
the output does not reach the fingerprint: the same error reported by
Gemini and by Claude Code hashes identically.

Upgrading

npm install -g forgelore        # or
curl -fsSL https://raw.githubusercontent.com/forgeprint/forgelore/main/scripts/install.sh | bash

Nothing to migrate. The record schema is 1 and the mapping format is 2.

gh attestation verify forgelore_linux_amd64 -R forgeprint/forgelore
npm audit signatures

Which agents this release supports

Agent	Checked against a running agent
Claude Code 2.1.290	hooks, both MCP protocol eras, usage reader	A
Copilot CLI 1.0.91	hooks only — its MCP client has never been connected	B
Gemini CLI 0.62.0	hooks only — its MCP client has never been connected	B
Codex CLI	nothing; the mapping is a reading of the documentation	unverified
Cursor	researched, not started	—