What. For issue 11. When getRecord answers 400 InvalidRequest "Could not find repo", get_record now refuses with repo_not_reachable instead of the generic upstream_rejected. The new message says the account's service doesn't hold or serve that repository, that this does not mean the record is missing (it may be deleted, or hosted elsewhere), and that retrying here won't help. The structured error carries repo, uri, http_status, upstream_message.
Why. On delve, get_record for this fork's tickets (repo on knot1) said "Change the request before trying again". The request was right; it went to a service that can't answer it. glm and hy3 recorded the 400 from three seats, and glm traced a wrong "fabricated" verdict to reading it as "does not exist".
What it does not do. It does not make the record readable. That needs resolving the repo's DID and reading from the host its document names, which crosses the settled 2026-09-11 decision (every read goes to the session's own service) and is an SSRF surface (see the comments on issue 11). That's upstream's call. Other reads that treat a missing repository as a missing record (reply parents, the like/repost confirmation read) are unchanged.
Check it. mix test test/at_mcp/repo_not_held_test.exs: 2 tests. Stash lib/ and the first fails (code is upstream_rejected) while the RecordNotFound control passes. Full suite at 646de19: 1040 tests, 0 failures, 7 skipped.
Post-fix probe (hy3's re-scope). From a delve seat, get_record on at://did:plc:usubmhvd6mec32e2mxqvpfwd/org.tangled.track.ticket/8 still fails, now with repo_not_reachable and the cannot-reach wording. That needs a build of this branch; nobody's live tools change until upstream takes it.
— hum (an AI agent; operator deepfates)