Plan slice 005 — provenance-bound tool identity, against SEP-2640 read in full

[HackTuah]

PLAN only. No shipping code, no behaviour change.

SEP-2640 was read before the design, not after

Archived at slices/005-provenance-bound-tool-identity/logs/spec-sep-2640-skills.md by the command that fetched it — 644 lines — and re-measured at time of writing:

state=open  merged=False  mergeable_state=clean
Status: Accepted  Sponsor: @pja-ant

Its mergeable_state moved from blocked to clean while the survey that found it was still running. This slice treats it as landing.

2640 already states compound identity normatively — "the pair of the host's identity for the originating server and the skill's uri", "MUST NOT key any of these on the uri alone". The PLAN says outright that this slice does not get to claim the idea.

The three differences it does claim

1. Tools, not skills. 2640 never touches Tool, tools/list or tools/call.
2. On the wire, not a host-assigned label. 2640's origin half is the host's identity for the server — explicitly not serverInfo.name — and it never appears in any MCP message.
3. The project's own security charter still lists "Tool identity across servers" as Open, no champion.

What happens to the claim if 2640 is extended to tools

Decided in the PLAN, before the code:

• origin half stays a host-assigned label → the claim narrows to difference 2 and survives;
• origin goes on the wire for tools → the claim is dead, the right response is to adopt the standard's shape, and it is recorded as retired rather than quietly restated;
• either way the defect is unaffected — a newcomer named after an incumbent is indistinguishable today whatever any SEP says.

With a trigger rather than an intention: re-fetch 2640 and re-run the open-SEP sweep before this slice's PR.

Two dependencies, stated before the work

• This brief supersedes the earlier "do not spawn further subagents" (PR A brief names what it supersedes; a lane that cannot spawn says so #14), so the lanes may spawn.
• SCR-289 blocks this slice if its record rests on a survivor's status — the harness can add a failure under load, the direction that turns a survivor into a false kill.

Verification

Files were git added before the gate ran, since an unadded file is invisible to git ls-files and the step would have printed pass over it:

reuse pass (235 tracked; 59 in scope, 57 headered + 2 sidecar; excluded 174 archive + 2 licence text)
Gate OK.  GATE_EXIT=0

[HackTuah]

Do not re-run the red check on this PR

The failing push run is deliberate standing evidence. A green re-run would destroy it. Owner ruling, 2026-09-08.

This branch changes a PLAN file and an archived specification page. No code, no test, no dependency. The pull_request run passed and the push run failed on the same commit:

run 34174978505  event=pull_request  success
run 34174975336  event=push          failure

test FAIL (exit 2) — Running ExUnit with seed: 70815, max_cases: 8
  1) HTTPBanditTest "a refusal over the adapter's drain cap now announces the close it always did"
     code: assert String.contains?(bytes, "HTTP/1.1 403")
  160 tests, 1 failure

Two runs of one commit, two answers. That is the finding, and it is filed as SCR-289.

Why re-running would be the wrong kind of tidy

A re-run would almost certainly go green, and the PR would look fine. That is how a flake becomes invisible — and this particular flake has a direction: it adds a failure, which is what turns a survivor into a false kill in a mutation table. It has already done that once in this repository, to Mc2 in slice 003 round 3, from this same component.

So the red is worth more than the green. It is the only artefact in the repository that demonstrates, on a commit containing no code, that "gate green" is currently a sample rather than a measurement.

What unblocks this PR

Not a re-run. SCR-289 lands first, as its own slice, ahead of this one:

• remove the wall-clock window from the Bandit-backed test — no longer one candidate among several, it is the requirement;
• demonstrate the rate before fixing, not a single transcript;
• prove a known survivor still reports as a survivor under the conditions that produced the false kill;
• demonstrate the fix at CI's max_cases: 8, where it was caught, not only at the development machine's 64;
• commit the mutation harness, which currently lives in a session scratchpad — the 003 record cites $S/mut.sh <name>, a path no future reader can resolve, and a command that cannot be re-run is not a record.

This PR waits on that. Leave the check red.