Record the findings that have no Linear issue, in one place

[HackTuah]

The Linear workspace is at its free issue limit:

You've exceeded the free issue limit for this workspace.

Five findings from the 002 review rounds could not be filed. They were recorded as comments on the nearest open issue, which keeps them but does not make them findable — the two round-4 items already spent a round parked in a thread before anyone re-read them.

Owner decision, 2026-09-07: every unfileable finding goes on a comment and into a single running list, so nothing lives only in a thread.

What is in it

Three live defects, shipped in 0.3.0, being fixed in slice 003 — recorded as tracked-only-here so that if that slice does not ship them they revert to unfiled rather than disappearing: the non-primitive x-mcp-header annotation making a tool permanently uncallable, a host data fault losing the request id, and pre-read refusals answering without connection: close.

Two cleanup items waiting for board capacity: fault_response/4's re-raise branch is unpinned, and ToolCatalog.fetch/2's @spec is not honest now that it is public API.

Two structural gaps: nothing derives the modern era's required result fields from the specification, so the next missing one is found the way ttlMs/cacheScope were; and readme_claims_test.exs does not deliver what CONVENTIONS.md asks of it.

Each entry names the round and the lane that found it, gives the derivation, and says whether it is a live defect or cleanup. The file states how an entry leaves: deleted by the commit that discharges it, not marked done in place.

Scope

One new file, slices/UNFILED.md. It is in neither concurrent slice's file set — slice 003 owns mix.exs, README.md, CHANGELOG.md, lib/, test/; slice 004 owns tools/, .githooks/, .github/.

Gate green, every step line reading pass.

Noted while running the gate here

reuse reads pass (24 commentable files) with this .md file added and carrying an SPDX header. The count is unchanged because the REUSE population is a hand-written extension glob ('*.ex' '*.exs' '*.sh' '*.yml') under a comment claiming it is derived from the tracked set — so .md is invisible to it. That is SCR-262 observed in the ordinary course of adding a file, and it is slice 004's item 7.

[HackTuah]

Correcting one entry in this ledger, from a reproduction rather than from reading.

slices/UNFILED.md:100-109, "BeamMCP.ToolCatalog.fetch/2's @spec is not honest", says
three host-authored catalog shapes raise. Reproduced on today's main + slice 008
(slices/008-catalog-generalization/logs/probe-fetch-spec.txt, written by the probe that produced
it) — four raise, and there is a fifth case the entry does not mention that is worse than any of
them:

host spec.name is a binary, not an atom       {:RAISED, ArgumentError}
all/0 returns a non-list map                  {:RAISED, BadMapError}
all/0 returns nil                             {:RAISED, Protocol.UndefinedError}
all/0 returns a bare map, not a %ToolSpec{}   {:returned, {:ok, %{name: :echo}}}
module is not loaded / does not exist         {:RAISED, UndefinedFunctionError}
CONTROL: a well-formed catalog                {:returned, {:ok, %BeamMCP.ToolSpec{...}}}

The missing raise is UndefinedFunctionError — a module that is not loaded or does not exist.

The fourth line is the one that matters. It does not raise: it returns
{:ok, %{name: :echo}} successfully, which violates the @spec silently and hands a
struct-shaped thing that is not a struct on to dispatch. The entry frames the problem as "says
:error and raises", so the case it misses is the one a reader of the entry would never think to
guard: a wrong answer that looks like a right one. A raise is loud; this is quiet.

Both directions are closed in slice 008 (SCR-294, PR #21), and not by widening the @spec or
adding a rescue — Catalog.validate/1 refuses all five shapes at Server.new/1, so the raise
conditions are unreachable for a server that started, and they are documented in the moduledoc
rather than caught. Catching would make a host bug indistinguishable from "no such tool", which is
the advertise-versus-call disagreement the behaviour exists to prevent.

The rest of this ledger's live entries are unverified against the current tree in the same way.
That is not a criticism of the entries; it is the same thing this correction demonstrates. Each
one was measured when it was written, on a tree several slices back — fault_response/4's
unpinned re-raise branch cites 137 tests, 0 failures, and the suite is at 187 tests, 0
failures today. Nothing here says which of them still reproduce. Before any of them is acted on,
it should be re-run the way this one was, and the count in it should be treated as a claim about
that older tree rather than a fact about this one.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DiEKvejosdQbcRvQ47x9UQ