Skip to content

docs(register): C-86 and C-87 — the residuals ADR-016 and ADR-017 leave behind - #236

Merged
Polichinel merged 1 commit into
developmentfrom
docs/register-adr016-017-residuals
Aug 10, 2026
Merged

docs(register): C-86 and C-87 — the residuals ADR-016 and ADR-017 leave behind#236
Polichinel merged 1 commit into
developmentfrom
docs/register-adr016-017-residuals

Conversation

@Polichinel

Copy link
Copy Markdown
Collaborator

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_main lists 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 main today, 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.

ruff check .        # clean
pytest -q           # 399 passed, 40 xfailed

🤖 Generated with Claude Code

… 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>
@Polichinel
Polichinel merged commit ee9453b into development Aug 10, 2026
4 checks passed
@Polichinel
Polichinel deleted the docs/register-adr016-017-residuals branch August 10, 2026 06:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant