Skip to content

Commit 35b8450

Browse files
committed
chore(changeset): the rate-limit budget arm reads narrowing, which is the direction it moves
The declaration was filed `yes (widening)` under "when unsure, declare yes", before the shape was chosen. The measurement went the other way: no key is added to a published payload here, and the accept set shrinks — a refusal replaces a silent accept. The arm is the one line a consumer reads for direction of change, so it says so. Nothing else in this changeset moves. The BREAKING banner and the ADR-0087 `not-required (no-migration-prescription)` disposition both stay: the breaking-ness is carried by those, not by the arm, and the gate reads the same verdict off either signal. Co-authored-by: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JbZnqu8bt6YqfJsr9vaFb3
1 parent 36adeca commit 35b8450

1 file changed

Lines changed: 1 addition & 1 deletion

File tree

‎.changeset/rate-limit-budget-unknown-keys-refused.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ feat(spec): refuse unknown keys inside a rate-limit budget — `RateLimitConfigS
77
**BREAKING** accept-set narrowing on a published spec schema, landing after the
88
v17.0.0 cut (the lockstep launch-window convention ships it as `minor`).
99

10-
Clause-②: yes (widening)
10+
Clause-②: no (narrowing)
1111

1212
<!-- adr-0087: not-required (no-migration-prescription) this change retires NO key. The budget vocabulary is byte-identical and only the unknown-key POSTURE moves, from strip to reject, on one of its two mounts. Nothing exists for `objectstack migrate meta` to rewrite, because an undeclared key was never honoured: it was dropped at parse, so neither the inbound token bucket (`@objectstack/runtime` `security/inbound-rate-limit.ts`), nor the endpoint policy chain, nor the publish gate ever read one — measured with the gate's own instrument, which reports this def as accepting the key and returning a document without it. There is no single FROM/TO rule a ledger entry could state either, since what is now refused is an open set of author typos rather than a renamed key. The upgrade channel is the schema rejection itself, which is strictly more specific than any ledger line: it names the offending key at the author's own path and carries either the canonical spelling or the wrong-layer pointer. This is the same disposition, on the same stored metadata type, that #5384 took one level up when it closed `ApiEndpointSchema` itself; the `declarative-apis-endpoints-live` entry that governs this surface is already registered for protocol 17 and needs no change here. -->
1313

0 commit comments

Comments
 (0)