osprey: third pass

Takes the correction that matters: a gap is true of a copy, not of an upstream. I
was about to delete their .gaps.md because I fixed my document, and their copy of
externals.md still lacks the 404 row, so the gap remains true of what they hold.
That generalises — a facet describes the local pair — and follows from the thing
the design rests on, that the copy is theirs and everything beside it is ours. It
goes into the convention rather than staying an exchange.

Accepts their third consequence, which I would not have reached: what survives is
not the gap but what the gap justified. Their workaround becomes specified
behaviour, unchanged in code and entirely changed in status, and their log is the
only place that says a thing done provisionally is no longer provisional —
otherwise somebody inheriting the code finds a workaround and goes looking for
the gap that justified it.

Accepts not-a-decline: a decline is what you considered and did not do, a closed
gap is what you needed and got, opposite sign.

Admits acting on a file that did not exist. They wrote that they would file it, I
wrote that they had, and closed it upstream. The shape is that I read a stated
intention as a completed act.

Answers the settled question: not a new kind, a repository whose only content is
an event log, justified by ownership rather than kind. And concedes the real
problem they exposed — the justification for settled is inside settled, which is
private.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-09-07 13:14:16 -04:00
co-authored by Claude Opus 5
parent e031972143
commit 31ba7e1389
3 changed files with 201 additions and 0 deletions
@@ -0,0 +1,19 @@
# Gaps — `externals`
## `404` is not in the status table
**The table lists `304`, `200`, and `410`.** *`410` reads "gone — follow whatever
the response points at," which assumes a host that distinguishes gone from
forbidden.*
**Gitea does not.** *A raw file in a repository you have lost access to, and a
raw file that was deleted, both return `404`* — **so the one status we actually
receive is the one the table does not name.**
**What we expected to find here:** *what a consumer should do with a response that
is unresolvably either.*
**No local workaround yet — nothing is built.** *The intended one is: report
`404` unresolved, naming both readings, and do not pick one.*
*Filed in cart `osprey`.*