docs(register): C-86 and C-87 — the residuals ADR-016 and ADR-017 leave behind - #236
Merged
Merged
Conversation
… leave behind Both were described in the ADRs and tracked nowhere. A decision record states a position; the register is what carries a live risk, and these are live. C-86 — the release path now depends on two other repositories with no way past a red build. ADR-016 accepted that coupling partly on a justification that measurement killed: protect_main lists ZERO bypass actors, so administrator status confers no exemption, and there is no classic branch protection either. The interesting part is that it is LATENT: no status check is required today, so a red build blocks nothing. The moment C-81's enforcement half is fixed — correctly, and it should be — this becomes live and unbypassable in the same change. Two open items that each look sensible alone combine into something neither of them says, so C-81 now says it. Rate is not hypothetical: views-appwrite reports five registry editions in four days, four of them observation-only, each of which would have blocked a release. views-appwrite#76 filed to make the obligation-carrying distinction machine-readable, which is the preferred resolution and which that seat volunteered. C-87 — the delivery label will be verified against a declaration, and nothing will verify the declaration against the consumer's code. ADR-017 §8 states it; the residual belongs here because the second half is work in repositories this project does not control (views-faoapi#379 has an owner, views-crafdapi#39 is blocked on a data contract), and because for a third-party-operated API it may never exist at all. Register 85/12/73 -> 87/14/73. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Answering a direct question: "are all risks registered?" — they were not. Two.
Both were described in the ADRs and tracked nowhere. A decision record states a position; the register is what carries a live risk.
C-86 — the release path depends on two other repositories, with no way past a red build
ADR-016 accepted that coupling partly on a justification measurement killed:
protect_mainlists zero bypass actors, so administrator status confers no exemption, and there is no classic branch protection either. That is withdrawn in the ADR; this entry is the risk it was papering over.The interesting part is that it is latent. No status check is required on
maintoday, so a red build blocks nothing and the coupling costs nothing.The moment C-81's enforcement half is fixed — correctly, and it should be — this becomes live and unbypassable in the same change. Two open items that each look sensible on their own combine into something neither of them says. C-81 now says it.
The rate is not hypothetical: views-appwrite reports five registry editions in four days, four observation-only, each of which would have blocked a release. views-appwrite#76 filed to make the obligation-carrying distinction machine-readable — the preferred resolution, and one that seat volunteered.
C-87 — the label will be checked against a declaration; nothing will check the declaration against the consumer
ADR-017 §8 states it plainly. It belongs in the register because the second half is work in repositories this project does not control — views-faoapi#379 has a willing owner, views-crafdapi#39 is blocked on that partner's data contract — and because for a third-party-operated private API it may never exist at all.
Also records the ordering constraint that a reviewer's catch produced: the source-reading check must survive until the consumer-side check lands, or there is a green window proving only that two values this platform authored agree with each other.
Also filed while checking
views-appwrite#76 — the pin-by-contract-version option. It was recorded in ADR-016 §7a as "not adopted here, needs the upstream side first" and tracked nowhere, which is how an idea dies in a paragraph. views-appwrite#45 is adjacent but different: that one is about readers ignoring
[meta] version; this is about which changes should oblige a consumer to act.Register 85/12/73 → 87/14/73.
🤖 Generated with Claude Code