fix: unbreak the v1.2.0 release notes and tighten the fragment ceiling to 200

.changie.yaml

@@ -18,9 +18,9 @@ kinds:
   - label: Documentation
 body:
   # A ceiling, not a target: one sentence is the rule (see RELEASE.md), and a
-  # body this long is a paragraph that belongs in the linked issue. Enforced by
-  # `changie new` only — a hand-written fragment is not checked.
-  maxLength: 400
+  # body this long is already two. Enforced by `changie new` only — a
+  # hand-written fragment is not checked.
+  maxLength: 200
 custom:
   - key: Issue
     label: Issue Number

RELEASE.md

@@ -30,7 +30,7 @@ You are prompted for a **kind** (`Added`, `Changed`, `Deprecated`, `Removed`,
 writes a small YAML file under `changes/unreleased/` — commit it alongside your
 code. Prefer `changie new` over hand-writing the YAML: it enforces the issue
 number — a fragment without one renders as a dead link — and refuses a body over
-400 characters.
+200 characters.
 
 ### One sentence. Two at most.
 
@@ -45,23 +45,25 @@ already points at.
 - **Never a third.** If it needs one, it is either two changes (write two
   fragments) or a story that belongs in the issue.
 
-`changie new` refuses a body over 400 characters (`body.maxLength` in
-[`.changie.yaml`](.changie.yaml)). That is a ceiling for the two-sentence case,
-not a target, and it does not see a fragment you hand-write.
+`changie new` refuses a body over 200 characters (`body.maxLength` in
+[`.changie.yaml`](.changie.yaml)). That is roughly one sentence: at 200 the
+second sentence is already crowding the first, so the ceiling and the rule push
+the same way. It does not see a fragment you hand-write.
 
 ```yaml
-# too long — the root cause, the mechanism and the evidence all belong in #142
+# too long — 417 characters; the root cause, the mechanism and the evidence all
+# belong in #142
 body: 'S3 Control requests were served by S3. `s3control` signs with S3''s own
   signing name, so every call fell through to the REST-XML default and the S3
   provider parsed it as a bucket and key — `CreateAccessPoint` returned 200 and
   left an object in a bucket named `v20180820`. S3 Control is now split off by its
   `/v20180820/` path prefix, and its unserved operations return a clean AWS error
   instead of a fabricated success'
 
-# right length
+# right length — 193 characters
 body: 'S3 Control requests were served by S3, which answered `CreateAccessPoint`
-  with a fabricated 200. It is now split off by its `/v20180820/` path prefix, and
-  its unserved operations return a clean AWS error'
+  with a fabricated 200. It is now split off by its `/v20180820/` path prefix and
+  its unserved operations decline cleanly'
 ```
 
 Config: [`.changie.yaml`](.changie.yaml).

changes/unreleased/Added-20260913-120000.yaml

@@ -2,4 +2,5 @@ kind: Added
 body: 'The 226 AWS services DevCloud does not register now have their Smithy models
   vendored, so codegen covers all 420 models. No service is registered yet and every
   published coverage figure is unchanged'
-Issue: "160"
+custom:
+    Issue: "160"

changes/unreleased/Added-20260913-140000.yaml

@@ -1,7 +1,5 @@
 kind: Added
-body: 'Eight AWS services whose operations the generic CRUD engine cannot classify
-  — payment-cryptography-data, geo-routes, cloudsearch-domain, ec2-instance-connect,
-  kinesis-video-webrtc-storage, marketplace-commerce-analytics, eks-auth and
-  inspector-scan — now have hand-written providers, bringing coverage to 213
-  registered and 209 serving'
-Issue: "161"
+body: 'Eight AWS services the generic CRUD engine cannot classify now have
+  hand-written providers, taking coverage to 213 registered and 209 serving'
+custom:
+    Issue: "161"

changes/unreleased/Added-20260913-160000.yaml

@@ -1,6 +1,6 @@
 kind: Added
-body: 'The 218 AWS services that had generated routers but no provider package are
-  now registered from the codegen scaffold template, so their SDK calls are answered
-  locally instead of reaching a real AWS account — coverage moves to 431 registered
-  and 426 serving at least one operation'
-Issue: "162"
+body: 'The 218 AWS services with generated routers but no provider package are now
+  registered from the codegen scaffold, taking coverage to 431 registered and 426
+  serving at least one operation'
+custom:
+    Issue: "162"

changes/unreleased/Added-20260913-170500.yaml

@@ -1,9 +1,6 @@
 kind: Added
-body: 'Two published figures are now gated against the binary that were not: the
-  routing and depth targets on the coverage page, and the size of the shipped
-  binary (45 MiB ceiling, checked in CI). A third gate is new but narrower than
-  intended — every one of the 431 registered services is now asserted to
-  initialize, which main.go only warned about, while its startup time is logged
-  rather than gated because a shared CI runner is 14x slower than the machine the
-  published figure comes from'
-Issue: "163"
+body: 'Three figures are now gated against the binary: the coverage page''s routing
+  and depth targets, the 45 MiB binary-size ceiling, and that all 431 registered
+  services initialize'
+custom:
+    Issue: "163"

changes/unreleased/Changed-20260913-145759.yaml

@@ -1,5 +1,5 @@
 kind: Changed
-body: The weekly Smithy sync re-derives the published coverage figures itself and commits them into its own pull request, so reviewing it is confirming which operations moved rather than transcribing the figures out of failing tests by hand
+body: The weekly Smithy sync now re-derives the published coverage figures and commits them into its own pull request, so reviewing it means confirming what moved rather than transcribing failing tests
 time: 2026-09-13T14:57:59.733064+09:00
 custom:
     Issue: "165"

changes/unreleased/Changed-20260913-184045.yaml

@@ -1,5 +1,5 @@
 kind: Changed
-body: The published fidelity tiers are stated against two denominators — the services DevCloud promises depth on, and every service it registers — so the long tail it routes to stop SDK calls escaping to a billable account no longer reads as a drop in hand-written coverage
+body: The published fidelity tiers are stated against two denominators — the services DevCloud promises depth on, and every service it registers — so the routed long tail no longer reads as a fidelity drop
 time: 2026-09-13T18:40:45.000000+09:00
 custom:
     Issue: "166"

changes/unreleased/Documentation-20260913-170000.yaml

@@ -1,6 +1,6 @@
 kind: Documentation
-body: 'The coverage page now states its two targets separately — routing, which is
-  431 of 431 and is a leak-zero safety property, and depth, which stays at the 205
-  services the 2026-09-05 demand study settled — so a service count can no longer
-  be read as a promise of fidelity'
-Issue: "163"
+body: 'The coverage page states routing and depth as two targets — 431 of 431
+  registered, depth still the 205 services the demand study settled — so a service
+  count no longer reads as a fidelity promise'
+custom:
+    Issue: "163"

changes/unreleased/Documentation-20260913-212251.yaml

@@ -1,5 +1,5 @@
 kind: Documentation
-body: 'The five per-service pages now list the operations DevCloud actually serves, derived from the fidelity manifest rather than from memory: S3 documented 8 of 37, DynamoDB 8 of 20, Lambda 6 of 25 and IAM 6 of 58, and each page''s limitations denied features that had since been implemented'
+body: The five per-service pages now list the operations DevCloud actually serves, derived from the fidelity manifest rather than from memory — S3 had documented 8 of 37, IAM 6 of 58
 time: 2026-09-13T21:22:51.981235+09:00
 custom:
     Issue: "167"

changes/unreleased/Fixed-20260913-161500.yaml

@@ -1,6 +1,6 @@
 kind: Fixed
 body: 'The CRUD engine no longer answers an operation it cannot classify with a
   broader sibling''s route — chime''s AssociatePhoneNumberWithUser was returning
-  UpdateUser''s 200 — because the registry now carries every REST-bound operation
-  and declines the unclassifiable ones instead of letting their paths fall through'
-Issue: "162"
+  UpdateUser''s 200 — and now declines it cleanly'
+custom:
+    Issue: "162"

docs/coverage.md

@@ -49,8 +49,9 @@ so does the reverse. See [Reproducing these numbers](#reproducing-these-numbers)
 ## Why a registered service can serve nothing
 
 The generic [CRUD engine](crud-engine.md) needs two things: to know which
-operation a request is for, and to recognise that operation as CRUD-shaped. Only
-the second still stops it.
+operation a request is for, and to recognise that operation as CRUD-shaped. The
+second is the usual blocker; the first still stops two services whose protocol
+the parser does not read.
 
 **The protocol always says which operation**, and the engine reads every form:
 
@@ -61,8 +62,8 @@ the second still stops it.
 | `json-1.0` | 48 | the `X-Amz-Target` header |
 | `query` | 15 | the `Action` form field |
 | `rest-xml` | 4 | HTTP method + path |
-| no in-tree model | 12 | n/a — hand-written providers |
-| unrecognised protocol | 1 | n/a — `partnercentralrevenuemeasurement` is `rpcv2Cbor` |
+| no in-tree model | 11 | n/a — hand-written providers |
+| unrecognised protocol | 2 | n/a — `ec2` is `ec2Query`, `partnercentralrevenuemeasurement` is `rpcv2Cbor` |
 
 **The operation is not CRUD-shaped.** `GetThing`, `ListThings` and `CreateThing`
 map onto a generic store. `ExecuteStatement`, `InvokeEndpoint` and
@@ -71,13 +72,19 @@ answer. This applies to four services: `forecastquery`, the two SageMaker Runtim
 variants `sagemaker-runtime` and `sagemakerruntimehttp2`, and `rds-data`. No
 protocol change reaches them.
 
-**The protocol is one the parser does not read.** This applies to exactly one
-service, and it is a different failure from the four above.
-`partnercentralrevenuemeasurement` speaks `smithy.protocols#rpcv2Cbor`, which
-`internal/codegen/parser.go` does not recognise, so *none* of its operations is
-classified — not because their names are unshaped, but because the model never
-reached the classifier. Teaching the parser a sixth protocol would reach it; no
-amount of CRUD-shaping would.
+**The protocol is one the parser does not read.** This applies to two services,
+and it is a different failure from the four above. `ec2` speaks
+`aws.protocols#ec2Query` and `partnercentralrevenuemeasurement` speaks
+`smithy.protocols#rpcv2Cbor`; `internal/codegen/parser.go` recognises neither, so
+*none* of their operations is classified — not because their names are unshaped,
+but because the model never reached the classifier. Teaching the parser those two
+protocols would reach them; no amount of CRUD-shaping would.
+
+EC2 is the one case where this costs depth rather than service: it is registered
+and served by a hand-written provider, so it is not in the registered-only five.
+What it loses is the engine — its model-declared long tail stays `unimplemented`
+instead of falling back to `auto-crud`, which is what `EngineWired: false` on its
+[fidelity manifest](fidelity-manifest.md) entry records.
 
 Registering a service the engine cannot serve is deliberate. The alternative is
 worse: an *unregistered* service is not routed, so the SDK call leaves the