diff --git a/CHANGELOG.md b/CHANGELOG.md
index 885f7c4..bead310 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,46 +1,46 @@
 ## [v1.1.0](https://github.com/skyoo2003/devcloud/releases/tag/v1.1.0) - 2026-09-06
 ### Added
-* Provider-namespaced configuration: service blocks can be written as `providers.aws.services.*`, forward-compatible with `providers.azure.*`. The top-level `services` block is the same block under its historical name and keeps working; a block for an unserved provider loads with a warning instead of failing ([#135](https://github.com/skyoo2003/devcloud/issues/135))
-* Per-provider auth adapters (`internal/auth`): SigV4 credentials are parsed once and the caller's claimed identity — access key, region, signing name, session token — is available to every plugin via `auth.FromContext`, and reported as a new `region` field on `GET /devcloud/api/logs`. Nothing is verified; DevCloud still accepts any credentials ([#135](https://github.com/skyoo2003/devcloud/issues/135))
-* Amazon Comprehend, served by the generic CRUD engine (49 operations auto-crud, 36 unimplemented). Unimplemented operations return a clean AWS error, never a fabricated success ([#136](https://github.com/skyoo2003/devcloud/issues/136))
-* All 48 upstream AI/Machine Learning service models are registered, taking DevCloud from 105 to 148 services. 17 are served by the generic CRUD engine or a hand-written provider; the remaining 31 are routed and decline with a clean AWS error rather than letting the call fall through to real AWS. See docs/coverage.md for the registered / served split ([#137](https://github.com/skyoo2003/devcloud/issues/137))
-* docs/coverage.md, which publishes the registered, serving and registered-only service counts together. The service count is never stated on its own ([#137](https://github.com/skyoo2003/devcloud/issues/137))
-* Admin API endpoint `GET /devcloud/api/unrouted` reports which AWS services this DevCloud was asked for and does not register, with per-service counts and first/last seen. Requires `admin.enabled: true`. Two documented ceilings: a request DevCloud cannot classify is routed to S3 rather than counted, so the figure is a floor; and a non-zero `droppedServiceIds` means the collector hit its key cap. Paste the output into a service request to turn a missing service into a measurement ([#138](https://github.com/skyoo2003/devcloud/issues/138))
-* "Service Not Supported" issue form for asking for an AWS service DevCloud does not register yet. It asks which operations you actually call and accepts the `/devcloud/api/unrouted` output, because a service name alone does not say how much of it you need ([#138](https://github.com/skyoo2003/devcloud/issues/138))
-* The generic CRUD engine now serves `rest-json` services. That protocol carries no `X-Amz-Target` header, so the operation is recovered from the request method and path using the route table the model already declares — the same matcher the generated per-service routers use, now shared in `internal/shared/httproute`. 28 already-registered services stopped being registered-only without any change to their providers: services serving at least one operation went 117 to 145, and `auto-crud` operations 1,415 to 2,200. A path the route table does not know still declines with a clean AWS error rather than a fabricated success ([#139](https://github.com/skyoo2003/devcloud/issues/139))
-* The 57 AWS services with demonstrated demand are registered, taking DevCloud to 205 services — the target set in `docs/coverage.md` after the 100% claim was tested and dropped. 54 of the 57 serve at least one operation; the three that do not are named with their reasons: `elastic-load-balancing` (query) and `s3-control` (rest-xml) use protocols the CRUD engine cannot read, and `rds-data` has no CRUD-shaped operation in its entire API. Fleet totals: 199 of 205 services serve at least one operation, and 4,858 operations are engine-served ([#139](https://github.com/skyoo2003/devcloud/issues/139))
-* The generic CRUD engine now serves every protocol DevCloud registers. `rest-xml` and `query` were the last two: `rest-xml` recovers its operation from the request method and path against the model's URI templates, like `rest-json`, and `query` reads it from the `Action` field of the form body. 112 operations move from `unimplemented` to `auto-crud` — 94 in `s3-control` and 18 in `elastic-load-balancing` — and protocol is no longer a reason any registered service serves nothing ([#143](https://github.com/skyoo2003/devcloud/issues/143))
-* CI gates the published coverage figure. `docs/coverage.md`, `README.md` and `docs/README.md` are read by `go test ./cmd/devcloud/` and compared to the live registry and fidelity manifest in both directions: removing a service without editing the published number fails, and editing the number without the code moving fails identically. The demand set in `docs/demand.md` is checked to still be registered, so the count cannot be held steady by swapping one service for another ([#144](https://github.com/skyoo2003/devcloud/issues/144))
-* `scripts/model_churn.py` summarises what a Smithy model sync actually changed — which services gained or lost operations, which models moved only documentation, and how many upstream models are not vendored here. The weekly sync PR is built from it, so a reviewer reads a change rather than a whole-tree regeneration of 194 models. Run it by hand with `python3 scripts/model_churn.py --upstream` ([#147](https://github.com/skyoo2003/devcloud/issues/147))
+* Provider-namespaced configuration: service blocks can be written as `providers.aws.services.*`, forward-compatible with `providers.azure.*`. The top-level `services` block is the same block under its historical name and keeps working ([#135](https://github.com/skyoo2003/devcloud/issues/135))
+* Per-provider auth adapters (`internal/auth`) parse SigV4 credentials once and expose the caller's claimed identity to every plugin via `auth.FromContext`, adding a `region` field to `GET /devcloud/api/logs`. Nothing is verified — DevCloud still accepts any credentials ([#135](https://github.com/skyoo2003/devcloud/issues/135))
+* Amazon Comprehend, served by the generic CRUD engine (49 operations auto-crud, 36 unimplemented), where an unimplemented operation returns a clean AWS error rather than a fabricated success ([#136](https://github.com/skyoo2003/devcloud/issues/136))
+* All 48 upstream AI/Machine Learning service models are registered, taking DevCloud from 105 to 148 services. 17 are served and the remaining 31 decline with a clean AWS error instead of falling through to real AWS ([#137](https://github.com/skyoo2003/devcloud/issues/137))
+* docs/coverage.md, which publishes the registered, serving and registered-only service counts together so the service count is never stated on its own ([#137](https://github.com/skyoo2003/devcloud/issues/137))
+* Admin API endpoint `GET /devcloud/api/unrouted` reports which AWS services this DevCloud was asked for and does not register, with per-service counts and first/last seen; it requires `admin.enabled: true`. The figure is a floor — an unclassifiable request is routed to S3 rather than counted, and a non-zero `droppedServiceIds` means the collector hit its key cap ([#138](https://github.com/skyoo2003/devcloud/issues/138))
+* "Service Not Supported" issue form for requesting an AWS service DevCloud does not register yet, which asks which operations you actually call and accepts `/devcloud/api/unrouted` output ([#138](https://github.com/skyoo2003/devcloud/issues/138))
+* The generic CRUD engine now serves `rest-json` services, recovering the operation from the request method and path against the route table the model already declares (shared in `internal/shared/httproute`). 28 registered-only services started serving: services with at least one operation went 117 to 145, and `auto-crud` operations 1,415 to 2,200 ([#139](https://github.com/skyoo2003/devcloud/issues/139))
+* The 57 AWS services with demonstrated demand are registered, taking DevCloud to 205 services — 199 of which serve at least one operation, for 4,858 engine-served operations. The three that serve nothing are named with their reasons in docs/coverage.md ([#139](https://github.com/skyoo2003/devcloud/issues/139))
+* The generic CRUD engine now serves every protocol DevCloud registers: `rest-xml` recovers its operation from method and path, and `query` reads it from the form body's `Action` field. 112 operations move from `unimplemented` to `auto-crud`, so protocol is no longer a reason any registered service serves nothing ([#143](https://github.com/skyoo2003/devcloud/issues/143))
+* CI gates the published coverage figure: `go test ./cmd/devcloud/` compares `docs/coverage.md`, `README.md` and `docs/README.md` against the live registry in both directions, so neither the code nor the number can move without the other. The demand set in `docs/demand.md` is checked to still be registered, so the count cannot be held steady by swapping one service for another ([#144](https://github.com/skyoo2003/devcloud/issues/144))
+* `scripts/model_churn.py` summarises what a Smithy model sync actually changed, so the weekly sync PR reads as a change rather than a whole-tree regeneration of 194 models ([#147](https://github.com/skyoo2003/devcloud/issues/147))
 ### Changed
-* Codegen now runs through a provider-neutral intermediate representation (`internal/codegen/ir`) behind a `ModelSource` interface, so a second API description format is an added file rather than a rewrite. Smithy is the first source; generated output is byte-identical ([#135](https://github.com/skyoo2003/devcloud/issues/135))
-* Service routing aliases are derived from the Smithy models instead of a hand-maintained switch in the gateway. Onboarding a service no longer needs a hand-written routing entry: all 93 previously-routed aliases resolve unchanged, and an alias claimed by more than one service is reported rather than guessed ([#137](https://github.com/skyoo2003/devcloud/issues/137))
+* Codegen now runs through a provider-neutral intermediate representation (`internal/codegen/ir`) behind a `ModelSource` interface, so a second API description format is an added file rather than a rewrite. Smithy is the first source and generated output is byte-identical ([#135](https://github.com/skyoo2003/devcloud/issues/135))
+* Service routing aliases are derived from the Smithy models instead of a hand-maintained switch in the gateway, so onboarding a service no longer needs a hand-written routing entry. All 93 previously-routed aliases resolve unchanged, and an alias claimed by more than one service is reported rather than guessed ([#137](https://github.com/skyoo2003/devcloud/issues/137))
 * The fidelity manifest records each service's wire protocol, so a registered service that the CRUD engine cannot reach is distinguishable from one whose wiring is broken ([#137](https://github.com/skyoo2003/devcloud/issues/137))
-* The AWS coverage target is 205 services, not 431. Of the 283 services DevCloud does not register, only 57 have been built by at least two of moto, LocalStack, and terraform-provider-aws, and 115 by none of them; DevCloud has received zero service requests to date. Rather than build a long tail nobody has asked for, the target is now every registered service plus every service with demonstrated demand. The remaining 226 are not refused — any of them can be onboarded on request — but they are no longer promised. Evidence and method in docs/demand.md; the decision rule was fixed in advance and is published in docs/coverage.md ([#138](https://github.com/skyoo2003/devcloud/issues/138))
-* `rest-xml` request bodies are still not buffered by the gateway, now by an explicit rule rather than as a side effect of the protocol being unservable. The engine serves `rest-xml` from the path and query alone, so S3's large binary uploads keep streaming; `crud.NeedsBody` is the predicate and a test fails if the body is read ([#143](https://github.com/skyoo2003/devcloud/issues/143))
-* The boto3 compatibility suite exercises every registered service. It parametrises over a generated service list (`internal/generated/compat/services.json`) instead of two hand-written name lists, so registering a service and testing it are no longer separate steps. 31 of 205 registered services had no boto3 test at all, 29 of them counted in the published coverage figure; the suite grew from 854 to 993 tests ([#144](https://github.com/skyoo2003/devcloud/issues/144))
+* The AWS coverage target is 205 services, not 431: of the 283 services DevCloud does not register, only 57 have been built by two or more of moto, LocalStack and terraform-provider-aws, and DevCloud has received zero service requests to date. The remaining 226 can still be onboarded on request but are no longer promised — evidence in docs/demand.md, decision rule in docs/coverage.md ([#138](https://github.com/skyoo2003/devcloud/issues/138))
+* `rest-xml` request bodies are still not buffered by the gateway, now by an explicit rule rather than as a side effect of the protocol being unservable: the engine serves `rest-xml` from the path and query alone, so S3's large binary uploads keep streaming. `crud.NeedsBody` is the predicate, and a test fails if the body is read ([#143](https://github.com/skyoo2003/devcloud/issues/143))
+* The boto3 compatibility suite exercises every registered service, parametrising over a generated service list (`internal/generated/compat/services.json`) instead of two hand-written name lists. It found 31 of 205 registered services with no boto3 test at all, and grew from 854 to 993 tests ([#144](https://github.com/skyoo2003/devcloud/issues/144))
 ### Fixed
 * Service registration is no longer silently dropped: `scripts/generate-imports.sh` gated on a `register.go` file that no service has, so every run wrote an empty import block and the built binary registered nothing. It now gates on the package actually calling `Register`, and refuses to write a gutted file instead of reporting success ([#136](https://github.com/skyoo2003/devcloud/issues/136))
-* A newly scaffolded service now serves its CRUD-shaped operations instead of failing every call: the generated provider declined with an error the gateway never routes to the CRUD engine, so the service was registered and routed but answered HTTP 500 for everything ([#136](https://github.com/skyoo2003/devcloud/issues/136))
-* The fidelity manifest no longer reports `auto-crud` for operations the binary refuses. A tier was assigned from CRUD-registry membership alone, which says an operation is classifiable rather than reachable; it now requires the owning provider to actually hand unimplemented operations to the engine ([#136](https://github.com/skyoo2003/devcloud/issues/136))
-* Smithy's non-boxed primitives (PrimitiveLong, PrimitiveBoolean and the other five) are mapped to Go types. Models using them previously generated code that did not compile ([#137](https://github.com/skyoo2003/devcloud/issues/137))
-* 'make codegen' is now byte-identical across runs. A model bundling two namespaces with colliding shape names produced different output on every run, because shapes are keyed by short name and the generator iterated a Go map ([#137](https://github.com/skyoo2003/devcloud/issues/137))
-* Amazon Rekognition can be onboarded. Its X-Amz-Target prefix is RekognitionService, which no routing entry covered, so every call returned UnknownService ([#137](https://github.com/skyoo2003/devcloud/issues/137))
-* Stale service counts across the docs. README.md advertised 104 services and docs/faq.md 101, when 148 are registered; docs/fidelity-manifest.md also carried outdated per-tier operation totals. Every count now appears with its depth split (148 registered / 117 serving at least one operation), so the number is never read as a capability claim on its own ([#138](https://github.com/skyoo2003/devcloud/issues/138))
-* 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 ([#142](https://github.com/skyoo2003/devcloud/issues/142))
-* Eight query-protocol providers no longer fabricate a success. `rds`, `neptune`, `docdb`, `redshift`, `elasticache`, `autoscaling`, `cloudformation` and `elasticloadbalancingv2` answered any operation they do not implement with HTTP 200 and an empty `<ActionResponse/>`, so a caller was told an operation succeeded when nothing ran. The body also had no `<ActionResult>` wrapper, so botocore raised `KeyError` rather than returning a value — `neptune.describe_db_cluster_endpoints()` crashed the SDK. They now hand the operation to the generic CRUD engine, which serves the 223 CRUD-shaped ones from the real store and refuses the rest with a clean `InvalidAction` ([#145](https://github.com/skyoo2003/devcloud/issues/145))
-* The four Amazon Lex services are reachable from boto3. `lex-models`, `lex-runtime`, `lexv2-models` and `lexv2-runtime` all sign as `lex`, and no service is called `lex`, so the alias stayed contested and every Lex call died as `UnknownService` — the services were registered, counted as serving operations, and reachable by nobody. The shared-signing-name split that already separates `mediastore-data`, `sagemaker-runtime` and Timestream now recognises a signing name that is a group key rather than a member service ID, so each request is answered by the sibling whose route table models its method and path. `DeleteBot` is claimed by two of them at `DELETE /bots/{id}` and is still refused rather than guessed at. Compatibility-tested services: 199 to 203 ([#146](https://github.com/skyoo2003/devcloud/issues/146))
-* Three operations the fidelity manifest calls `hand-verified` are now reachable. `appsync.ListApis`, `eks.ListAccessPolicies` and `opensearch.ListApplications` were each implemented by a `case` clause in their provider, but the provider's hand-written path resolver did not know the route boto3 sends — `GET /v2/apis`, `GET /access-policies` and `GET /2021-01-01/opensearch/list-applications` — so the operation arrived empty and the call answered `NotImplemented`. Each provider now falls back to its own model's route table when its resolver recognises nothing, which recovers the operation instead of losing it. No published figure moves: these operations were already labelled served, and the label is now true ([#146](https://github.com/skyoo2003/devcloud/issues/146))
-* The fidelity manifest no longer drops operations with short names. The scan that decides which operations are hand-verified required a name of four characters or more, so `resourcegroups.Untag` was recorded and `Tag` — implemented beside it in the same dispatch switch — was reported as unimplemented. A probe then asked for `Tag`, got the answer the provider has always given, and reported a fabricated success that was never fabricated: the code was real and the manifest was wrong about it. Short dispatch literals are now collected separately and promoted only where the service's own model declares them, so `Tag` counts and the `GET`/`PUT` literals every path resolver switches on still cannot become operations. Hand-verified operations: 4,496 to 4,497 ([#146](https://github.com/skyoo2003/devcloud/issues/146))
-* S3 no longer answers an unimplemented bucket sub-resource with a bucket listing. `GET /{Bucket}?analytics` matched no sub-resource branch and fell through to `ListObjects`, so botocore read the resulting 200 `<ListBucketResult>` as a successful `ListBucketAnalyticsConfigurations`. `?inventory`, `?metrics`, `?replication`, `?lifecycle`, `?encryption`, `?versions` and `?object-lock` all took the same path. A bucket-level GET carrying a query parameter that is neither a sub-resource this provider serves nor a parameter a listing carries now returns a clean `NotImplemented`. The check is an allow-list of listing parameters rather than a deny-list of sub-resource names, so a sub-resource AWS adds later declines instead of being served as a listing ([#146](https://github.com/skyoo2003/devcloud/issues/146))
-* The weekly Smithy model sync discarded the changes worth reviewing. Its test step ended the job before the pull request was opened, and an upstream model that gains an operation is designed to fail that step — it moves the fidelity manifest and trips the published-figure gate. So a cosmetic sync produced a PR and a semantic one produced a red cron job with nothing attached. The test result is now recorded rather than gating, the PR is always opened when models moved, and the failure is re-raised afterwards so the cron does not silently go green ([#147](https://github.com/skyoo2003/devcloud/issues/147))
-* A release dry run keeps its artifacts. The `Upload assets` step ran when `dry_run` was not set, so it uploaded on a real release — where GoReleaser has already attached the same files to the GitHub Release — and skipped the one path that publishes nothing and therefore has no other output. RELEASE.md documents the dry run as building artifacts and uploading them to the run, so a maintainer validating a build before tagging got a green run with nothing to inspect ([#150](https://github.com/skyoo2003/devcloud/issues/150))
+* A newly scaffolded service now serves its CRUD-shaped operations instead of answering HTTP 500 for everything, because the generated provider declined with an error the gateway never routes to the CRUD engine ([#136](https://github.com/skyoo2003/devcloud/issues/136))
+* The fidelity manifest no longer reports `auto-crud` for operations the binary refuses; a tier assigned from CRUD-registry membership alone says an operation is classifiable rather than reachable, and now requires the owning provider to actually hand unimplemented operations to the engine ([#136](https://github.com/skyoo2003/devcloud/issues/136))
+* Smithy's non-boxed primitives (PrimitiveLong, PrimitiveBoolean and the other five) are mapped to Go types; models using them previously generated code that did not compile ([#137](https://github.com/skyoo2003/devcloud/issues/137))
+* `make codegen` is now byte-identical across runs, where a model bundling two namespaces with colliding shape names produced different output every time because shapes are keyed by short name and the generator iterated a Go map ([#137](https://github.com/skyoo2003/devcloud/issues/137))
+* Amazon Rekognition can be onboarded; its `X-Amz-Target` prefix `RekognitionService` was covered by no routing entry, so every call returned `UnknownService` ([#137](https://github.com/skyoo2003/devcloud/issues/137))
+* Stale service counts across the docs: README.md advertised 104 services and docs/faq.md 101 when 148 are registered, and docs/fidelity-manifest.md carried outdated per-tier operation totals. Every count now appears with its depth split (148 registered / 117 serving at least one operation), so the number is never read as a capability claim on its own ([#138](https://github.com/skyoo2003/devcloud/issues/138))
+* S3 Control requests were served by S3, which signs with the same name and parsed them 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 ([#142](https://github.com/skyoo2003/devcloud/issues/142))
+* Eight query-protocol providers (`rds`, `neptune`, `docdb`, `redshift`, `elasticache`, `autoscaling`, `cloudformation`, `elasticloadbalancingv2`) answered any unimplemented operation with HTTP 200 and an empty `<ActionResponse/>`, so a caller was told an operation succeeded when nothing ran — and botocore raised `KeyError` on the missing `<ActionResult>` wrapper. They now hand the operation to the generic CRUD engine, which serves the 223 CRUD-shaped ones from the real store and refuses the rest with a clean `InvalidAction` ([#145](https://github.com/skyoo2003/devcloud/issues/145))
+* The four Amazon Lex services are reachable from boto3, where all four sign as `lex` and no service is called `lex`, so the alias stayed contested and every Lex call died as `UnknownService`. The shared-signing-name split now recognises a signing name that is a group key rather than a member service ID, and answers each request from the sibling whose route table models its method and path ([#146](https://github.com/skyoo2003/devcloud/issues/146))
+* `appsync.ListApis`, `eks.ListAccessPolicies` and `opensearch.ListApplications` are reachable: each was implemented, but the provider's hand-written path resolver did not know the route boto3 sends, so the operation arrived empty and the call answered `NotImplemented`. Each provider now falls back to its own model's route table when its resolver recognises nothing ([#146](https://github.com/skyoo2003/devcloud/issues/146))
+* The fidelity manifest no longer drops operations with short names, where the hand-verified scan required four characters or more and reported `resourcegroups.Tag` as unimplemented while the code beside it was real. Short dispatch literals are now collected separately and promoted only where the service's own model declares them ([#146](https://github.com/skyoo2003/devcloud/issues/146))
+* S3 no longer answers an unimplemented bucket sub-resource with a bucket listing, where `GET /{Bucket}?analytics` and seven siblings fell through to `ListObjects` and botocore read the resulting 200 as a successful call. A bucket-level GET whose query parameter is neither a served sub-resource nor a listing parameter now returns a clean `NotImplemented` ([#146](https://github.com/skyoo2003/devcloud/issues/146))
+* The weekly Smithy model sync discarded the changes worth reviewing: its test step ended the job before the pull request was opened, and an upstream model that gains an operation is designed to fail that step. The test result is now recorded rather than gating, the PR is always opened when models moved, and the failure is re-raised afterwards so the cron does not silently go green ([#147](https://github.com/skyoo2003/devcloud/issues/147))
+* A release dry run keeps its artifacts; the `Upload assets` step ran when `dry_run` was not set, so it uploaded on a real release — where GoReleaser has already attached the same files — and skipped the one path that publishes nothing else ([#150](https://github.com/skyoo2003/devcloud/issues/150))
 ### Documentation
-* Coverage docs state what the compatibility figure excludes and why. Two registered services have no boto3 client at all (`sagemakerruntimehttp2`, `transcribestreaming`), and the four Lex services are registered but reachable by no boto3 caller — all four clients sign as the contested alias `lex`, which routes nowhere by design. `README.md` and `docs/README.md` had quoted 148 registered / 117 serving since three milestones earlier ([#144](https://github.com/skyoo2003/devcloud/issues/144))
-* docs/coverage.md now publishes what keeping up with upstream costs, measured rather than estimated: refreshing all 194 vendored models changed 93 of them, 32 moved an operation, and none was documentation-only. The reading states its own ceiling — the 93 had been vendored 141 days earlier, and the 101 vendored the day before did not move at all, so it is an accumulated backlog and not a weekly rate. docs/contributing.md adds what a reviewer of the weekly sync PR is actually being asked to check ([#147](https://github.com/skyoo2003/devcloud/issues/147))
-* The release procedure moved from `docs/release.md` to `RELEASE.md` at the repo root, and three things it never stated are now in it: GoReleaser publishes a Homebrew formula to a separate tap repository through a GitHub App token scoped to that repo alone, a tagged build pushes four `*-alpine` image tags rather than the one the doc implied, and `make changelog VERSION=` is the batch and merge pair. The archive files list carries `RELEASE.md`, so the docs index link to it resolves inside a release tarball and not only on GitHub ([#148](https://github.com/skyoo2003/devcloud/issues/148))
-* The contributor guide no longer asks for a build toolchain and a server the project does not need. docs/contributing.md listed SQLite3 development headers as a prerequisite and said `make test` runs with CGO enabled — the driver has been pure Go since v1.0.0, and the Makefile, every workflow and every pre-commit hook set `CGO_ENABLED=0`. It also said the compatibility suite needs a running DevCloud instance; the `devcloud_server` fixture starts one itself on a free port against a temporary data dir it removes afterwards, and the three env vars that override that (`DEVCLOUD_EXTERNAL`, `DEVCLOUD_BIN`, `DEVCLOUD_PORT`) are now documented. docs/getting-started.md advertised a Next.js frontend on port 3000 under Docker Compose, where the compose file has one service and that frontend lives in a separate repository. Documented for the first time alongside: the `clean`, `changelog` and `stats` Make targets, the pre-commit and golangci-lint setup, and the `/devcloud/api/fidelity` and `/devcloud/api/unrouted` admin routes ([#149](https://github.com/skyoo2003/devcloud/issues/149))
-* The compatibility policy states current figures. It had gone stale in five places — 775 boto3 tests, 948 `auto-crud` operations, 4,496 hand-verified, 148 registered services of which 31 served nothing, and a 93/11 split of model-backed to hand-written services — and nothing caught it, because nothing reads the file: `cmd/devcloud/coverage_test.go` gates docs/coverage.md, README.md and docs/README.md against the live registry, and docs/compatibility-policy.md is not in that set. It now reads 1,144 tests, 5,193 `auto-crud`, 4,497 hand-verified, 205 registered with 4 serving nothing, and 193/12 — each taken from the gated page or measured, not restated. The document ships inside the release archive, so a stale figure there describes the binary beside it ([#150](https://github.com/skyoo2003/devcloud/issues/150))
+* Coverage docs state what the compatibility figure excludes and why: two registered services have no boto3 client at all (`sagemakerruntimehttp2`, `transcribestreaming`), and the four Lex services are registered but reachable by no boto3 caller because every Lex client signs as the contested alias `lex` ([#144](https://github.com/skyoo2003/devcloud/issues/144))
+* docs/coverage.md now publishes the measured cost of keeping up with upstream — refreshing all 194 vendored models changed 93 of them, and 32 moved an operation. The reading states its own ceiling: those 93 had been vendored 141 days earlier, so it is an accumulated backlog and not a weekly rate ([#147](https://github.com/skyoo2003/devcloud/issues/147))
+* The release procedure moved from `docs/release.md` to `RELEASE.md` at the repo root, and now states three things it never did: the Homebrew formula is published to a separate tap repository through a GitHub App token scoped to that repo alone, a tagged build pushes four `*-alpine` image tags, and `make changelog VERSION=` is the batch-and-merge pair ([#148](https://github.com/skyoo2003/devcloud/issues/148))
+* The contributor guide no longer asks for SQLite3 development headers, CGO, or a separately running DevCloud instance — the driver has been pure Go since v1.0.0, and the compatibility suite starts its own server. docs/getting-started.md also no longer advertises a Next.js frontend on port 3000 that lives in a separate repository ([#149](https://github.com/skyoo2003/devcloud/issues/149))
+* The compatibility policy states current figures, having gone stale in five places because nothing gates it: `cmd/devcloud/coverage_test.go` covers docs/coverage.md, README.md and docs/README.md, and docs/compatibility-policy.md is not in that set. It now reads 1,144 tests, 5,193 `auto-crud`, 4,497 hand-verified, 205 registered with 4 serving nothing, and 193/12 model-backed to hand-written ([#150](https://github.com/skyoo2003/devcloud/issues/150))
 ## [v1.0.0](https://github.com/skyoo2003/devcloud/releases/tag/v1.0.0) - 2026-08-11
 ### Added
 * Add the four SQS dead-letter redrive operations (ListDeadLetterSourceQueues, Start/List/CancelMessageMoveTask), completing SQS at 23 operations ([#94](https://github.com/skyoo2003/devcloud/issues/94))
@@ -74,13 +74,13 @@
 * Restored CloudWatch's 17 CRUD-engine operations. The gateway picks the protocol from the request, not from the provider, so CloudWatch reaches the engine whenever a client speaks JSON — filtering the registry by the provider's declared protocol had removed that coverage outright ([#126](https://github.com/skyoo2003/devcloud/issues/126))
 * EventBridge rule ARNs now name their event bus, as AWS does. A rule name is unique per bus, so same-named rules on two custom buses previously shared one ARN — and with it, one tag set, where tagging one rule changed the other's and deleting one wiped the survivor's ([#126](https://github.com/skyoo2003/devcloud/issues/126))
 * CloudWatch now drops an alarm's tags when the alarm is deleted, so recreating an alarm under the same name no longer inherits the old one's tags ([#126](https://github.com/skyoo2003/devcloud/issues/126))
-* Downloadable binaries now start. Releases were built with CGO_ENABLED=0 while the SQLite driver required cgo, so every tar.gz/zip binary, the Homebrew formula and the versioned `*-alpine` images exited at startup with "go-sqlite3 requires cgo to work. This is a stub" — only the rolling `latest` image, built separately with cgo, worked. The driver is now pure Go, so no build needs a C toolchain or SQLite headers ([#128](https://github.com/skyoo2003/devcloud/issues/128))
-* Service selection now matches what the docs promise. An empty `services` block is still a block, so it starts nothing rather than every registered service; and `DEVCLOUD_SERVICES` names the running set outright rather than intersecting with the `services` block, so it starts a service the block omits and overrides a block entry the file disabled. Previously `DEVCLOUD_SERVICES=sqs` alongside a block listing only `s3` started nothing at all ([#129](https://github.com/skyoo2003/devcloud/issues/129))
-* CloudFront no longer fabricates a success for operations it does not implement. Its dispatch fallback answered HTTP 200 with an empty XML document, which boto3 parses as a successful empty result, on all 122 CloudFront operations the fidelity manifest classifies as `unimplemented` — including `GetPublicKey`. It now returns `NotImplemented` (HTTP 501), matching the other 32 providers that decline from their own dispatch default. It was the only provider in the tree that answered an unimplemented call with a success ([#129](https://github.com/skyoo2003/devcloud/issues/129))
-* Generated routers now honour route patterns that constrain the query string, so operations distinguished only by a query parameter are reachable. `matchURI` split the whole pattern into path segments, which made `/2020-05-31/tagging?Operation=Tag` unable to match the path segment `tagging` — CloudFront `TagResource` and `UntagResource` were implemented but unroutable, and answered as unimplemented. A pattern's constraint must now be satisfied by the request query, and query-constrained routes are tried ahead of unconstrained ones so a bare path cannot shadow a more specific route ([#129](https://github.com/skyoo2003/devcloud/issues/129))
-* Released binaries now register their services. GoReleaser built `cmd/devcloud/main.go` rather than the package, which drops `imports.go` — the only place the 104 services blank-import themselves into the registry. `main.go` references nothing from it, so the build succeeded and the binary exited at startup with `unknown service: s3`. Every archive, the Homebrew formula and the container images were affected; the boto3 suite missed it because the release gate compiled the package instead of what GoReleaser ships, and that gate now builds with GoReleaser ([#131](https://github.com/skyoo2003/devcloud/issues/131))
+* Downloadable binaries now start, where releases built with `CGO_ENABLED=0` against a SQLite driver that required cgo exited at startup — every tar.gz/zip binary, the Homebrew formula and the versioned `*-alpine` images. The driver is now pure Go, so no build needs a C toolchain or SQLite headers ([#128](https://github.com/skyoo2003/devcloud/issues/128))
+* Service selection now matches what the docs promise: an empty `services` block starts nothing rather than every registered service, and `DEVCLOUD_SERVICES` names the running set outright instead of intersecting with the block. Previously `DEVCLOUD_SERVICES=sqs` alongside a block listing only `s3` started nothing at all ([#129](https://github.com/skyoo2003/devcloud/issues/129))
+* CloudFront no longer fabricates a success for the 122 operations the fidelity manifest classifies as `unimplemented`, where its dispatch fallback answered HTTP 200 with an empty XML document that boto3 parses as a successful empty result. It now returns `NotImplemented` (HTTP 501), matching the other 32 providers that decline from their own dispatch default ([#129](https://github.com/skyoo2003/devcloud/issues/129))
+* Generated routers now honour route patterns that constrain the query string, so operations distinguished only by a query parameter are reachable — `matchURI` split the whole pattern into path segments, leaving CloudFront `TagResource` and `UntagResource` implemented but unroutable. Query-constrained routes are tried ahead of unconstrained ones, so a bare path cannot shadow a more specific route ([#129](https://github.com/skyoo2003/devcloud/issues/129))
+* Released binaries now register their services, where GoReleaser built `cmd/devcloud/main.go` rather than the package and dropped the `imports.go` that blank-imports all 104 services — every archive, the Homebrew formula and the container images exited at startup with `unknown service: s3`. The release gate now builds with GoReleaser instead of compiling the package, which is why the boto3 suite missed it ([#131](https://github.com/skyoo2003/devcloud/issues/131))
 ### Documentation
-* Corrected what the fidelity manifest says an `unimplemented` operation returns. It claimed JSON and Query services answer `InvalidAction` (HTTP 400), but only the 46 providers that fall through to the CRUD engine do; 32 answer `NotImplemented` (HTTP 501) from their own dispatch default, several use their own vocabulary, and `sqs` differs by protocol. Only the failure itself is stable — the specific code and status are documented, not guaranteed ([#129](https://github.com/skyoo2003/devcloud/issues/129))
+* Corrected what the fidelity manifest says an `unimplemented` operation returns: it claimed JSON and Query services answer `InvalidAction` (HTTP 400), where only the 46 providers falling through to the CRUD engine do and 32 answer `NotImplemented` (HTTP 501) from their own dispatch default. Only the failure itself is stable — the specific code and status are documented, not guaranteed ([#129](https://github.com/skyoo2003/devcloud/issues/129))
 * The roadmap, architecture and governance docs no longer describe DevCloud as pre-1.0. All three ship inside the release archive, so a v1.0 download would have carried a roadmap listing its own release as pending, an architecture overview naming Phase 1 as current, and a governance doc calling the API unstable — contradicting the compatibility policy packaged beside them ([#130](https://github.com/skyoo2003/devcloud/issues/130))
 ## [v0.2.0](https://github.com/skyoo2003/devcloud/releases/tag/v0.2.0) - 2026-04-21
 ### Added
diff --git a/RELEASE.md b/RELEASE.md
index 4955178..f9b74f1 100644
--- a/RELEASE.md
+++ b/RELEASE.md
@@ -26,10 +26,38 @@ changie new
 ```
 
 You are prompted for a **kind** (`Added`, `Changed`, `Deprecated`, `Removed`,
-`Fixed`, `Security`, `Documentation`), a one-line **body**, and the **issue
-number**. It 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, and a fragment without one renders as a dead link.
+`Fixed`, `Security`, `Documentation`), a **body**, and the **issue number**. It
+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, and a fragment without one renders as a dead link.
+
+### One sentence. Two at most.
+
+The changelog is a scan surface, not a design document — the reader is deciding
+whether this release affects them. Root cause, mechanism, measurements and
+rejected alternatives belong in the linked issue and PR, which every entry
+already points at.
+
+- **One sentence** — what changed, and what it means for someone using DevCloud.
+- **A second only if a reader must not miss it** — a limit, a behaviour change
+  they have to act on, or the one figure that makes the entry meaningful.
+- **Never a third.** If it needs one, it is either two changes (write two
+  fragments) or a story that belongs in the issue.
+
+```yaml
+# too long — 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
+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'
+```
 
 Config: [`.changie.yaml`](.changie.yaml).
 
@@ -52,6 +80,9 @@ rather than from a failed tag. The rest are only caught here.
       `grep -L 'Issue: "[0-9]' changes/unreleased/*.yaml` prints nothing.
 - [ ] **`changes/unreleased/` is not empty.** No fragments means either nothing
       shipped or someone forgot one.
+- [ ] **Every fragment body is one sentence, two at most.** A third sentence is
+      either a second change that needs its own fragment or detail that belongs in
+      the issue.
 - [ ] **Deprecation review.** If this release *removes* anything previously
       deprecated — a config key, an env var, an admin route — confirm it shipped
       for at least one release with a warning first. Removing without that overlap
diff --git a/changes/unreleased/Documentation-20260906-185423.yaml b/changes/unreleased/Documentation-20260906-185423.yaml
new file mode 100644
index 0000000..ddec072
--- /dev/null
+++ b/changes/unreleased/Documentation-20260906-185423.yaml
@@ -0,0 +1,5 @@
+kind: Documentation
+body: Changelog fragments are capped at one sentence, two at most, with the rule and a worked example in RELEASE.md and a line for it in the pre-flight checklist. Every entry already in the changelog is rewritten to that limit, and the v1.1.0 and v1.0.0 release notes are republished from their fragment files
+time: 2026-09-06T18:54:23.073014+09:00
+custom:
+    Issue: "152"
diff --git a/changes/unreleased/Documentation-20260906-234500.yaml b/changes/unreleased/Documentation-20260906-234500.yaml
index d1fe140..f5e2065 100644
--- a/changes/unreleased/Documentation-20260906-234500.yaml
+++ b/changes/unreleased/Documentation-20260906-234500.yaml
@@ -1,5 +1,5 @@
 kind: Documentation
-body: 'The documentation no longer publishes the same figure at five different values. Six numbers were restated across pages and no two agreed: 205/148/101 registered services, 12,407/9,030/7,475 known operations, 992/1,144/775 compatibility tests, 11/12 services without a Smithy model, and 46 engine-wired services against a measured 155. Only docs/coverage.md, README.md and docs/README.md are gated against the binary by cmd/devcloud/coverage_test.go, so those were right and every restatement had rotted; coverage.md now owns the numbers and the other pages link to it. Three statements did not match the code and are corrected: docs/troubleshooting.md pointed at a GET /devcloud/api/health route that internal/admin/api.go does not register, and blamed a failed Lambda invoke on Docker when lambda/runtime.go is a stub that always returns a placeholder; docs/contributing.md listed interface.go, serializer.go and deserializer.go as codegen output when no template emits them. docs/crud-engine.md contradicted itself, serving five protocols in one table and claiming JSON-only across 46 services two screens later. docs/compatibility-policy.md said 193 model-backed services and 12 without, where manifest_gen.go holds 194 and 11. Eighteen files are shorter overall — 3,564 lines to 2,501 — with the 285-row demand.md evidence table and the per-service pages left intact'
+body: 'The documentation no longer publishes the same figure at five different values: six numbers were restated across pages with no two agreeing, so docs/coverage.md now owns them and every other page links to it. Three statements that did not match the code are corrected — a GET /devcloud/api/health route that is not registered, a failed Lambda invoke blamed on Docker when the runtime is a stub, and codegen output files no template emits — and eighteen files are 1,063 lines shorter'
 time: 2026-09-06T23:45:00.000000+09:00
 custom:
     Issue: "151"
diff --git a/changes/v1.0.0.md b/changes/v1.0.0.md
index a361b08..56c2c3f 100644
--- a/changes/v1.0.0.md
+++ b/changes/v1.0.0.md
@@ -31,11 +31,11 @@
 * Restored CloudWatch's 17 CRUD-engine operations. The gateway picks the protocol from the request, not from the provider, so CloudWatch reaches the engine whenever a client speaks JSON — filtering the registry by the provider's declared protocol had removed that coverage outright ([#126](https://github.com/skyoo2003/devcloud/issues/126))
 * EventBridge rule ARNs now name their event bus, as AWS does. A rule name is unique per bus, so same-named rules on two custom buses previously shared one ARN — and with it, one tag set, where tagging one rule changed the other's and deleting one wiped the survivor's ([#126](https://github.com/skyoo2003/devcloud/issues/126))
 * CloudWatch now drops an alarm's tags when the alarm is deleted, so recreating an alarm under the same name no longer inherits the old one's tags ([#126](https://github.com/skyoo2003/devcloud/issues/126))
-* Downloadable binaries now start. Releases were built with CGO_ENABLED=0 while the SQLite driver required cgo, so every tar.gz/zip binary, the Homebrew formula and the versioned `*-alpine` images exited at startup with "go-sqlite3 requires cgo to work. This is a stub" — only the rolling `latest` image, built separately with cgo, worked. The driver is now pure Go, so no build needs a C toolchain or SQLite headers ([#128](https://github.com/skyoo2003/devcloud/issues/128))
-* Service selection now matches what the docs promise. An empty `services` block is still a block, so it starts nothing rather than every registered service; and `DEVCLOUD_SERVICES` names the running set outright rather than intersecting with the `services` block, so it starts a service the block omits and overrides a block entry the file disabled. Previously `DEVCLOUD_SERVICES=sqs` alongside a block listing only `s3` started nothing at all ([#129](https://github.com/skyoo2003/devcloud/issues/129))
-* CloudFront no longer fabricates a success for operations it does not implement. Its dispatch fallback answered HTTP 200 with an empty XML document, which boto3 parses as a successful empty result, on all 122 CloudFront operations the fidelity manifest classifies as `unimplemented` — including `GetPublicKey`. It now returns `NotImplemented` (HTTP 501), matching the other 32 providers that decline from their own dispatch default. It was the only provider in the tree that answered an unimplemented call with a success ([#129](https://github.com/skyoo2003/devcloud/issues/129))
-* Generated routers now honour route patterns that constrain the query string, so operations distinguished only by a query parameter are reachable. `matchURI` split the whole pattern into path segments, which made `/2020-05-31/tagging?Operation=Tag` unable to match the path segment `tagging` — CloudFront `TagResource` and `UntagResource` were implemented but unroutable, and answered as unimplemented. A pattern's constraint must now be satisfied by the request query, and query-constrained routes are tried ahead of unconstrained ones so a bare path cannot shadow a more specific route ([#129](https://github.com/skyoo2003/devcloud/issues/129))
-* Released binaries now register their services. GoReleaser built `cmd/devcloud/main.go` rather than the package, which drops `imports.go` — the only place the 104 services blank-import themselves into the registry. `main.go` references nothing from it, so the build succeeded and the binary exited at startup with `unknown service: s3`. Every archive, the Homebrew formula and the container images were affected; the boto3 suite missed it because the release gate compiled the package instead of what GoReleaser ships, and that gate now builds with GoReleaser ([#131](https://github.com/skyoo2003/devcloud/issues/131))
+* Downloadable binaries now start, where releases built with `CGO_ENABLED=0` against a SQLite driver that required cgo exited at startup — every tar.gz/zip binary, the Homebrew formula and the versioned `*-alpine` images. The driver is now pure Go, so no build needs a C toolchain or SQLite headers ([#128](https://github.com/skyoo2003/devcloud/issues/128))
+* Service selection now matches what the docs promise: an empty `services` block starts nothing rather than every registered service, and `DEVCLOUD_SERVICES` names the running set outright instead of intersecting with the block. Previously `DEVCLOUD_SERVICES=sqs` alongside a block listing only `s3` started nothing at all ([#129](https://github.com/skyoo2003/devcloud/issues/129))
+* CloudFront no longer fabricates a success for the 122 operations the fidelity manifest classifies as `unimplemented`, where its dispatch fallback answered HTTP 200 with an empty XML document that boto3 parses as a successful empty result. It now returns `NotImplemented` (HTTP 501), matching the other 32 providers that decline from their own dispatch default ([#129](https://github.com/skyoo2003/devcloud/issues/129))
+* Generated routers now honour route patterns that constrain the query string, so operations distinguished only by a query parameter are reachable — `matchURI` split the whole pattern into path segments, leaving CloudFront `TagResource` and `UntagResource` implemented but unroutable. Query-constrained routes are tried ahead of unconstrained ones, so a bare path cannot shadow a more specific route ([#129](https://github.com/skyoo2003/devcloud/issues/129))
+* Released binaries now register their services, where GoReleaser built `cmd/devcloud/main.go` rather than the package and dropped the `imports.go` that blank-imports all 104 services — every archive, the Homebrew formula and the container images exited at startup with `unknown service: s3`. The release gate now builds with GoReleaser instead of compiling the package, which is why the boto3 suite missed it ([#131](https://github.com/skyoo2003/devcloud/issues/131))
 ### Documentation
-* Corrected what the fidelity manifest says an `unimplemented` operation returns. It claimed JSON and Query services answer `InvalidAction` (HTTP 400), but only the 46 providers that fall through to the CRUD engine do; 32 answer `NotImplemented` (HTTP 501) from their own dispatch default, several use their own vocabulary, and `sqs` differs by protocol. Only the failure itself is stable — the specific code and status are documented, not guaranteed ([#129](https://github.com/skyoo2003/devcloud/issues/129))
+* Corrected what the fidelity manifest says an `unimplemented` operation returns: it claimed JSON and Query services answer `InvalidAction` (HTTP 400), where only the 46 providers falling through to the CRUD engine do and 32 answer `NotImplemented` (HTTP 501) from their own dispatch default. Only the failure itself is stable — the specific code and status are documented, not guaranteed ([#129](https://github.com/skyoo2003/devcloud/issues/129))
 * The roadmap, architecture and governance docs no longer describe DevCloud as pre-1.0. All three ship inside the release archive, so a v1.0 download would have carried a roadmap listing its own release as pending, an architecture overview naming Phase 1 as current, and a governance doc calling the API unstable — contradicting the compatibility policy packaged beside them ([#130](https://github.com/skyoo2003/devcloud/issues/130))
diff --git a/changes/v1.1.0.md b/changes/v1.1.0.md
index abaaf46..c62ad5d 100644
--- a/changes/v1.1.0.md
+++ b/changes/v1.1.0.md
@@ -1,43 +1,43 @@
 ## [v1.1.0](https://github.com/skyoo2003/devcloud/releases/tag/v1.1.0) - 2026-09-06
 ### Added
-* Provider-namespaced configuration: service blocks can be written as `providers.aws.services.*`, forward-compatible with `providers.azure.*`. The top-level `services` block is the same block under its historical name and keeps working; a block for an unserved provider loads with a warning instead of failing ([#135](https://github.com/skyoo2003/devcloud/issues/135))
-* Per-provider auth adapters (`internal/auth`): SigV4 credentials are parsed once and the caller's claimed identity — access key, region, signing name, session token — is available to every plugin via `auth.FromContext`, and reported as a new `region` field on `GET /devcloud/api/logs`. Nothing is verified; DevCloud still accepts any credentials ([#135](https://github.com/skyoo2003/devcloud/issues/135))
-* Amazon Comprehend, served by the generic CRUD engine (49 operations auto-crud, 36 unimplemented). Unimplemented operations return a clean AWS error, never a fabricated success ([#136](https://github.com/skyoo2003/devcloud/issues/136))
-* All 48 upstream AI/Machine Learning service models are registered, taking DevCloud from 105 to 148 services. 17 are served by the generic CRUD engine or a hand-written provider; the remaining 31 are routed and decline with a clean AWS error rather than letting the call fall through to real AWS. See docs/coverage.md for the registered / served split ([#137](https://github.com/skyoo2003/devcloud/issues/137))
-* docs/coverage.md, which publishes the registered, serving and registered-only service counts together. The service count is never stated on its own ([#137](https://github.com/skyoo2003/devcloud/issues/137))
-* Admin API endpoint `GET /devcloud/api/unrouted` reports which AWS services this DevCloud was asked for and does not register, with per-service counts and first/last seen. Requires `admin.enabled: true`. Two documented ceilings: a request DevCloud cannot classify is routed to S3 rather than counted, so the figure is a floor; and a non-zero `droppedServiceIds` means the collector hit its key cap. Paste the output into a service request to turn a missing service into a measurement ([#138](https://github.com/skyoo2003/devcloud/issues/138))
-* "Service Not Supported" issue form for asking for an AWS service DevCloud does not register yet. It asks which operations you actually call and accepts the `/devcloud/api/unrouted` output, because a service name alone does not say how much of it you need ([#138](https://github.com/skyoo2003/devcloud/issues/138))
-* The generic CRUD engine now serves `rest-json` services. That protocol carries no `X-Amz-Target` header, so the operation is recovered from the request method and path using the route table the model already declares — the same matcher the generated per-service routers use, now shared in `internal/shared/httproute`. 28 already-registered services stopped being registered-only without any change to their providers: services serving at least one operation went 117 to 145, and `auto-crud` operations 1,415 to 2,200. A path the route table does not know still declines with a clean AWS error rather than a fabricated success ([#139](https://github.com/skyoo2003/devcloud/issues/139))
-* The 57 AWS services with demonstrated demand are registered, taking DevCloud to 205 services — the target set in `docs/coverage.md` after the 100% claim was tested and dropped. 54 of the 57 serve at least one operation; the three that do not are named with their reasons: `elastic-load-balancing` (query) and `s3-control` (rest-xml) use protocols the CRUD engine cannot read, and `rds-data` has no CRUD-shaped operation in its entire API. Fleet totals: 199 of 205 services serve at least one operation, and 4,858 operations are engine-served ([#139](https://github.com/skyoo2003/devcloud/issues/139))
-* The generic CRUD engine now serves every protocol DevCloud registers. `rest-xml` and `query` were the last two: `rest-xml` recovers its operation from the request method and path against the model's URI templates, like `rest-json`, and `query` reads it from the `Action` field of the form body. 112 operations move from `unimplemented` to `auto-crud` — 94 in `s3-control` and 18 in `elastic-load-balancing` — and protocol is no longer a reason any registered service serves nothing ([#143](https://github.com/skyoo2003/devcloud/issues/143))
-* CI gates the published coverage figure. `docs/coverage.md`, `README.md` and `docs/README.md` are read by `go test ./cmd/devcloud/` and compared to the live registry and fidelity manifest in both directions: removing a service without editing the published number fails, and editing the number without the code moving fails identically. The demand set in `docs/demand.md` is checked to still be registered, so the count cannot be held steady by swapping one service for another ([#144](https://github.com/skyoo2003/devcloud/issues/144))
-* `scripts/model_churn.py` summarises what a Smithy model sync actually changed — which services gained or lost operations, which models moved only documentation, and how many upstream models are not vendored here. The weekly sync PR is built from it, so a reviewer reads a change rather than a whole-tree regeneration of 194 models. Run it by hand with `python3 scripts/model_churn.py --upstream` ([#147](https://github.com/skyoo2003/devcloud/issues/147))
+* Provider-namespaced configuration: service blocks can be written as `providers.aws.services.*`, forward-compatible with `providers.azure.*`. The top-level `services` block is the same block under its historical name and keeps working ([#135](https://github.com/skyoo2003/devcloud/issues/135))
+* Per-provider auth adapters (`internal/auth`) parse SigV4 credentials once and expose the caller's claimed identity to every plugin via `auth.FromContext`, adding a `region` field to `GET /devcloud/api/logs`. Nothing is verified — DevCloud still accepts any credentials ([#135](https://github.com/skyoo2003/devcloud/issues/135))
+* Amazon Comprehend, served by the generic CRUD engine (49 operations auto-crud, 36 unimplemented), where an unimplemented operation returns a clean AWS error rather than a fabricated success ([#136](https://github.com/skyoo2003/devcloud/issues/136))
+* All 48 upstream AI/Machine Learning service models are registered, taking DevCloud from 105 to 148 services. 17 are served and the remaining 31 decline with a clean AWS error instead of falling through to real AWS ([#137](https://github.com/skyoo2003/devcloud/issues/137))
+* docs/coverage.md, which publishes the registered, serving and registered-only service counts together so the service count is never stated on its own ([#137](https://github.com/skyoo2003/devcloud/issues/137))
+* Admin API endpoint `GET /devcloud/api/unrouted` reports which AWS services this DevCloud was asked for and does not register, with per-service counts and first/last seen; it requires `admin.enabled: true`. The figure is a floor — an unclassifiable request is routed to S3 rather than counted, and a non-zero `droppedServiceIds` means the collector hit its key cap ([#138](https://github.com/skyoo2003/devcloud/issues/138))
+* "Service Not Supported" issue form for requesting an AWS service DevCloud does not register yet, which asks which operations you actually call and accepts `/devcloud/api/unrouted` output ([#138](https://github.com/skyoo2003/devcloud/issues/138))
+* The generic CRUD engine now serves `rest-json` services, recovering the operation from the request method and path against the route table the model already declares (shared in `internal/shared/httproute`). 28 registered-only services started serving: services with at least one operation went 117 to 145, and `auto-crud` operations 1,415 to 2,200 ([#139](https://github.com/skyoo2003/devcloud/issues/139))
+* The 57 AWS services with demonstrated demand are registered, taking DevCloud to 205 services — 199 of which serve at least one operation, for 4,858 engine-served operations. The three that serve nothing are named with their reasons in docs/coverage.md ([#139](https://github.com/skyoo2003/devcloud/issues/139))
+* The generic CRUD engine now serves every protocol DevCloud registers: `rest-xml` recovers its operation from method and path, and `query` reads it from the form body's `Action` field. 112 operations move from `unimplemented` to `auto-crud`, so protocol is no longer a reason any registered service serves nothing ([#143](https://github.com/skyoo2003/devcloud/issues/143))
+* CI gates the published coverage figure: `go test ./cmd/devcloud/` compares `docs/coverage.md`, `README.md` and `docs/README.md` against the live registry in both directions, so neither the code nor the number can move without the other. The demand set in `docs/demand.md` is checked to still be registered, so the count cannot be held steady by swapping one service for another ([#144](https://github.com/skyoo2003/devcloud/issues/144))
+* `scripts/model_churn.py` summarises what a Smithy model sync actually changed, so the weekly sync PR reads as a change rather than a whole-tree regeneration of 194 models ([#147](https://github.com/skyoo2003/devcloud/issues/147))
 ### Changed
-* Codegen now runs through a provider-neutral intermediate representation (`internal/codegen/ir`) behind a `ModelSource` interface, so a second API description format is an added file rather than a rewrite. Smithy is the first source; generated output is byte-identical ([#135](https://github.com/skyoo2003/devcloud/issues/135))
-* Service routing aliases are derived from the Smithy models instead of a hand-maintained switch in the gateway. Onboarding a service no longer needs a hand-written routing entry: all 93 previously-routed aliases resolve unchanged, and an alias claimed by more than one service is reported rather than guessed ([#137](https://github.com/skyoo2003/devcloud/issues/137))
+* Codegen now runs through a provider-neutral intermediate representation (`internal/codegen/ir`) behind a `ModelSource` interface, so a second API description format is an added file rather than a rewrite. Smithy is the first source and generated output is byte-identical ([#135](https://github.com/skyoo2003/devcloud/issues/135))
+* Service routing aliases are derived from the Smithy models instead of a hand-maintained switch in the gateway, so onboarding a service no longer needs a hand-written routing entry. All 93 previously-routed aliases resolve unchanged, and an alias claimed by more than one service is reported rather than guessed ([#137](https://github.com/skyoo2003/devcloud/issues/137))
 * The fidelity manifest records each service's wire protocol, so a registered service that the CRUD engine cannot reach is distinguishable from one whose wiring is broken ([#137](https://github.com/skyoo2003/devcloud/issues/137))
-* The AWS coverage target is 205 services, not 431. Of the 283 services DevCloud does not register, only 57 have been built by at least two of moto, LocalStack, and terraform-provider-aws, and 115 by none of them; DevCloud has received zero service requests to date. Rather than build a long tail nobody has asked for, the target is now every registered service plus every service with demonstrated demand. The remaining 226 are not refused — any of them can be onboarded on request — but they are no longer promised. Evidence and method in docs/demand.md; the decision rule was fixed in advance and is published in docs/coverage.md ([#138](https://github.com/skyoo2003/devcloud/issues/138))
-* `rest-xml` request bodies are still not buffered by the gateway, now by an explicit rule rather than as a side effect of the protocol being unservable. The engine serves `rest-xml` from the path and query alone, so S3's large binary uploads keep streaming; `crud.NeedsBody` is the predicate and a test fails if the body is read ([#143](https://github.com/skyoo2003/devcloud/issues/143))
-* The boto3 compatibility suite exercises every registered service. It parametrises over a generated service list (`internal/generated/compat/services.json`) instead of two hand-written name lists, so registering a service and testing it are no longer separate steps. 31 of 205 registered services had no boto3 test at all, 29 of them counted in the published coverage figure; the suite grew from 854 to 993 tests ([#144](https://github.com/skyoo2003/devcloud/issues/144))
+* The AWS coverage target is 205 services, not 431: of the 283 services DevCloud does not register, only 57 have been built by two or more of moto, LocalStack and terraform-provider-aws, and DevCloud has received zero service requests to date. The remaining 226 can still be onboarded on request but are no longer promised — evidence in docs/demand.md, decision rule in docs/coverage.md ([#138](https://github.com/skyoo2003/devcloud/issues/138))
+* `rest-xml` request bodies are still not buffered by the gateway, now by an explicit rule rather than as a side effect of the protocol being unservable: the engine serves `rest-xml` from the path and query alone, so S3's large binary uploads keep streaming. `crud.NeedsBody` is the predicate, and a test fails if the body is read ([#143](https://github.com/skyoo2003/devcloud/issues/143))
+* The boto3 compatibility suite exercises every registered service, parametrising over a generated service list (`internal/generated/compat/services.json`) instead of two hand-written name lists. It found 31 of 205 registered services with no boto3 test at all, and grew from 854 to 993 tests ([#144](https://github.com/skyoo2003/devcloud/issues/144))
 ### Fixed
 * Service registration is no longer silently dropped: `scripts/generate-imports.sh` gated on a `register.go` file that no service has, so every run wrote an empty import block and the built binary registered nothing. It now gates on the package actually calling `Register`, and refuses to write a gutted file instead of reporting success ([#136](https://github.com/skyoo2003/devcloud/issues/136))
-* A newly scaffolded service now serves its CRUD-shaped operations instead of failing every call: the generated provider declined with an error the gateway never routes to the CRUD engine, so the service was registered and routed but answered HTTP 500 for everything ([#136](https://github.com/skyoo2003/devcloud/issues/136))
-* The fidelity manifest no longer reports `auto-crud` for operations the binary refuses. A tier was assigned from CRUD-registry membership alone, which says an operation is classifiable rather than reachable; it now requires the owning provider to actually hand unimplemented operations to the engine ([#136](https://github.com/skyoo2003/devcloud/issues/136))
-* Smithy's non-boxed primitives (PrimitiveLong, PrimitiveBoolean and the other five) are mapped to Go types. Models using them previously generated code that did not compile ([#137](https://github.com/skyoo2003/devcloud/issues/137))
-* 'make codegen' is now byte-identical across runs. A model bundling two namespaces with colliding shape names produced different output on every run, because shapes are keyed by short name and the generator iterated a Go map ([#137](https://github.com/skyoo2003/devcloud/issues/137))
-* Amazon Rekognition can be onboarded. Its X-Amz-Target prefix is RekognitionService, which no routing entry covered, so every call returned UnknownService ([#137](https://github.com/skyoo2003/devcloud/issues/137))
-* Stale service counts across the docs. README.md advertised 104 services and docs/faq.md 101, when 148 are registered; docs/fidelity-manifest.md also carried outdated per-tier operation totals. Every count now appears with its depth split (148 registered / 117 serving at least one operation), so the number is never read as a capability claim on its own ([#138](https://github.com/skyoo2003/devcloud/issues/138))
-* 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 ([#142](https://github.com/skyoo2003/devcloud/issues/142))
-* Eight query-protocol providers no longer fabricate a success. `rds`, `neptune`, `docdb`, `redshift`, `elasticache`, `autoscaling`, `cloudformation` and `elasticloadbalancingv2` answered any operation they do not implement with HTTP 200 and an empty `<ActionResponse/>`, so a caller was told an operation succeeded when nothing ran. The body also had no `<ActionResult>` wrapper, so botocore raised `KeyError` rather than returning a value — `neptune.describe_db_cluster_endpoints()` crashed the SDK. They now hand the operation to the generic CRUD engine, which serves the 223 CRUD-shaped ones from the real store and refuses the rest with a clean `InvalidAction` ([#145](https://github.com/skyoo2003/devcloud/issues/145))
-* The four Amazon Lex services are reachable from boto3. `lex-models`, `lex-runtime`, `lexv2-models` and `lexv2-runtime` all sign as `lex`, and no service is called `lex`, so the alias stayed contested and every Lex call died as `UnknownService` — the services were registered, counted as serving operations, and reachable by nobody. The shared-signing-name split that already separates `mediastore-data`, `sagemaker-runtime` and Timestream now recognises a signing name that is a group key rather than a member service ID, so each request is answered by the sibling whose route table models its method and path. `DeleteBot` is claimed by two of them at `DELETE /bots/{id}` and is still refused rather than guessed at. Compatibility-tested services: 199 to 203 ([#146](https://github.com/skyoo2003/devcloud/issues/146))
-* Three operations the fidelity manifest calls `hand-verified` are now reachable. `appsync.ListApis`, `eks.ListAccessPolicies` and `opensearch.ListApplications` were each implemented by a `case` clause in their provider, but the provider's hand-written path resolver did not know the route boto3 sends — `GET /v2/apis`, `GET /access-policies` and `GET /2021-01-01/opensearch/list-applications` — so the operation arrived empty and the call answered `NotImplemented`. Each provider now falls back to its own model's route table when its resolver recognises nothing, which recovers the operation instead of losing it. No published figure moves: these operations were already labelled served, and the label is now true ([#146](https://github.com/skyoo2003/devcloud/issues/146))
-* The fidelity manifest no longer drops operations with short names. The scan that decides which operations are hand-verified required a name of four characters or more, so `resourcegroups.Untag` was recorded and `Tag` — implemented beside it in the same dispatch switch — was reported as unimplemented. A probe then asked for `Tag`, got the answer the provider has always given, and reported a fabricated success that was never fabricated: the code was real and the manifest was wrong about it. Short dispatch literals are now collected separately and promoted only where the service's own model declares them, so `Tag` counts and the `GET`/`PUT` literals every path resolver switches on still cannot become operations. Hand-verified operations: 4,496 to 4,497 ([#146](https://github.com/skyoo2003/devcloud/issues/146))
-* S3 no longer answers an unimplemented bucket sub-resource with a bucket listing. `GET /{Bucket}?analytics` matched no sub-resource branch and fell through to `ListObjects`, so botocore read the resulting 200 `<ListBucketResult>` as a successful `ListBucketAnalyticsConfigurations`. `?inventory`, `?metrics`, `?replication`, `?lifecycle`, `?encryption`, `?versions` and `?object-lock` all took the same path. A bucket-level GET carrying a query parameter that is neither a sub-resource this provider serves nor a parameter a listing carries now returns a clean `NotImplemented`. The check is an allow-list of listing parameters rather than a deny-list of sub-resource names, so a sub-resource AWS adds later declines instead of being served as a listing ([#146](https://github.com/skyoo2003/devcloud/issues/146))
-* The weekly Smithy model sync discarded the changes worth reviewing. Its test step ended the job before the pull request was opened, and an upstream model that gains an operation is designed to fail that step — it moves the fidelity manifest and trips the published-figure gate. So a cosmetic sync produced a PR and a semantic one produced a red cron job with nothing attached. The test result is now recorded rather than gating, the PR is always opened when models moved, and the failure is re-raised afterwards so the cron does not silently go green ([#147](https://github.com/skyoo2003/devcloud/issues/147))
-* A release dry run keeps its artifacts. The `Upload assets` step ran when `dry_run` was not set, so it uploaded on a real release — where GoReleaser has already attached the same files to the GitHub Release — and skipped the one path that publishes nothing and therefore has no other output. RELEASE.md documents the dry run as building artifacts and uploading them to the run, so a maintainer validating a build before tagging got a green run with nothing to inspect ([#150](https://github.com/skyoo2003/devcloud/issues/150))
+* A newly scaffolded service now serves its CRUD-shaped operations instead of answering HTTP 500 for everything, because the generated provider declined with an error the gateway never routes to the CRUD engine ([#136](https://github.com/skyoo2003/devcloud/issues/136))
+* The fidelity manifest no longer reports `auto-crud` for operations the binary refuses; a tier assigned from CRUD-registry membership alone says an operation is classifiable rather than reachable, and now requires the owning provider to actually hand unimplemented operations to the engine ([#136](https://github.com/skyoo2003/devcloud/issues/136))
+* Smithy's non-boxed primitives (PrimitiveLong, PrimitiveBoolean and the other five) are mapped to Go types; models using them previously generated code that did not compile ([#137](https://github.com/skyoo2003/devcloud/issues/137))
+* `make codegen` is now byte-identical across runs, where a model bundling two namespaces with colliding shape names produced different output every time because shapes are keyed by short name and the generator iterated a Go map ([#137](https://github.com/skyoo2003/devcloud/issues/137))
+* Amazon Rekognition can be onboarded; its `X-Amz-Target` prefix `RekognitionService` was covered by no routing entry, so every call returned `UnknownService` ([#137](https://github.com/skyoo2003/devcloud/issues/137))
+* Stale service counts across the docs: README.md advertised 104 services and docs/faq.md 101 when 148 are registered, and docs/fidelity-manifest.md carried outdated per-tier operation totals. Every count now appears with its depth split (148 registered / 117 serving at least one operation), so the number is never read as a capability claim on its own ([#138](https://github.com/skyoo2003/devcloud/issues/138))
+* S3 Control requests were served by S3, which signs with the same name and parsed them 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 ([#142](https://github.com/skyoo2003/devcloud/issues/142))
+* Eight query-protocol providers (`rds`, `neptune`, `docdb`, `redshift`, `elasticache`, `autoscaling`, `cloudformation`, `elasticloadbalancingv2`) answered any unimplemented operation with HTTP 200 and an empty `<ActionResponse/>`, so a caller was told an operation succeeded when nothing ran — and botocore raised `KeyError` on the missing `<ActionResult>` wrapper. They now hand the operation to the generic CRUD engine, which serves the 223 CRUD-shaped ones from the real store and refuses the rest with a clean `InvalidAction` ([#145](https://github.com/skyoo2003/devcloud/issues/145))
+* The four Amazon Lex services are reachable from boto3, where all four sign as `lex` and no service is called `lex`, so the alias stayed contested and every Lex call died as `UnknownService`. The shared-signing-name split now recognises a signing name that is a group key rather than a member service ID, and answers each request from the sibling whose route table models its method and path ([#146](https://github.com/skyoo2003/devcloud/issues/146))
+* `appsync.ListApis`, `eks.ListAccessPolicies` and `opensearch.ListApplications` are reachable: each was implemented, but the provider's hand-written path resolver did not know the route boto3 sends, so the operation arrived empty and the call answered `NotImplemented`. Each provider now falls back to its own model's route table when its resolver recognises nothing ([#146](https://github.com/skyoo2003/devcloud/issues/146))
+* The fidelity manifest no longer drops operations with short names, where the hand-verified scan required four characters or more and reported `resourcegroups.Tag` as unimplemented while the code beside it was real. Short dispatch literals are now collected separately and promoted only where the service's own model declares them ([#146](https://github.com/skyoo2003/devcloud/issues/146))
+* S3 no longer answers an unimplemented bucket sub-resource with a bucket listing, where `GET /{Bucket}?analytics` and seven siblings fell through to `ListObjects` and botocore read the resulting 200 as a successful call. A bucket-level GET whose query parameter is neither a served sub-resource nor a listing parameter now returns a clean `NotImplemented` ([#146](https://github.com/skyoo2003/devcloud/issues/146))
+* The weekly Smithy model sync discarded the changes worth reviewing: its test step ended the job before the pull request was opened, and an upstream model that gains an operation is designed to fail that step. The test result is now recorded rather than gating, the PR is always opened when models moved, and the failure is re-raised afterwards so the cron does not silently go green ([#147](https://github.com/skyoo2003/devcloud/issues/147))
+* A release dry run keeps its artifacts; the `Upload assets` step ran when `dry_run` was not set, so it uploaded on a real release — where GoReleaser has already attached the same files — and skipped the one path that publishes nothing else ([#150](https://github.com/skyoo2003/devcloud/issues/150))
 ### Documentation
-* Coverage docs state what the compatibility figure excludes and why. Two registered services have no boto3 client at all (`sagemakerruntimehttp2`, `transcribestreaming`), and the four Lex services are registered but reachable by no boto3 caller — all four clients sign as the contested alias `lex`, which routes nowhere by design. `README.md` and `docs/README.md` had quoted 148 registered / 117 serving since three milestones earlier ([#144](https://github.com/skyoo2003/devcloud/issues/144))
-* docs/coverage.md now publishes what keeping up with upstream costs, measured rather than estimated: refreshing all 194 vendored models changed 93 of them, 32 moved an operation, and none was documentation-only. The reading states its own ceiling — the 93 had been vendored 141 days earlier, and the 101 vendored the day before did not move at all, so it is an accumulated backlog and not a weekly rate. docs/contributing.md adds what a reviewer of the weekly sync PR is actually being asked to check ([#147](https://github.com/skyoo2003/devcloud/issues/147))
-* The release procedure moved from `docs/release.md` to `RELEASE.md` at the repo root, and three things it never stated are now in it: GoReleaser publishes a Homebrew formula to a separate tap repository through a GitHub App token scoped to that repo alone, a tagged build pushes four `*-alpine` image tags rather than the one the doc implied, and `make changelog VERSION=` is the batch and merge pair. The archive files list carries `RELEASE.md`, so the docs index link to it resolves inside a release tarball and not only on GitHub ([#148](https://github.com/skyoo2003/devcloud/issues/148))
-* The contributor guide no longer asks for a build toolchain and a server the project does not need. docs/contributing.md listed SQLite3 development headers as a prerequisite and said `make test` runs with CGO enabled — the driver has been pure Go since v1.0.0, and the Makefile, every workflow and every pre-commit hook set `CGO_ENABLED=0`. It also said the compatibility suite needs a running DevCloud instance; the `devcloud_server` fixture starts one itself on a free port against a temporary data dir it removes afterwards, and the three env vars that override that (`DEVCLOUD_EXTERNAL`, `DEVCLOUD_BIN`, `DEVCLOUD_PORT`) are now documented. docs/getting-started.md advertised a Next.js frontend on port 3000 under Docker Compose, where the compose file has one service and that frontend lives in a separate repository. Documented for the first time alongside: the `clean`, `changelog` and `stats` Make targets, the pre-commit and golangci-lint setup, and the `/devcloud/api/fidelity` and `/devcloud/api/unrouted` admin routes ([#149](https://github.com/skyoo2003/devcloud/issues/149))
-* The compatibility policy states current figures. It had gone stale in five places — 775 boto3 tests, 948 `auto-crud` operations, 4,496 hand-verified, 148 registered services of which 31 served nothing, and a 93/11 split of model-backed to hand-written services — and nothing caught it, because nothing reads the file: `cmd/devcloud/coverage_test.go` gates docs/coverage.md, README.md and docs/README.md against the live registry, and docs/compatibility-policy.md is not in that set. It now reads 1,144 tests, 5,193 `auto-crud`, 4,497 hand-verified, 205 registered with 4 serving nothing, and 193/12 — each taken from the gated page or measured, not restated. The document ships inside the release archive, so a stale figure there describes the binary beside it ([#150](https://github.com/skyoo2003/devcloud/issues/150))
+* Coverage docs state what the compatibility figure excludes and why: two registered services have no boto3 client at all (`sagemakerruntimehttp2`, `transcribestreaming`), and the four Lex services are registered but reachable by no boto3 caller because every Lex client signs as the contested alias `lex` ([#144](https://github.com/skyoo2003/devcloud/issues/144))
+* docs/coverage.md now publishes the measured cost of keeping up with upstream — refreshing all 194 vendored models changed 93 of them, and 32 moved an operation. The reading states its own ceiling: those 93 had been vendored 141 days earlier, so it is an accumulated backlog and not a weekly rate ([#147](https://github.com/skyoo2003/devcloud/issues/147))
+* The release procedure moved from `docs/release.md` to `RELEASE.md` at the repo root, and now states three things it never did: the Homebrew formula is published to a separate tap repository through a GitHub App token scoped to that repo alone, a tagged build pushes four `*-alpine` image tags, and `make changelog VERSION=` is the batch-and-merge pair ([#148](https://github.com/skyoo2003/devcloud/issues/148))
+* The contributor guide no longer asks for SQLite3 development headers, CGO, or a separately running DevCloud instance — the driver has been pure Go since v1.0.0, and the compatibility suite starts its own server. docs/getting-started.md also no longer advertises a Next.js frontend on port 3000 that lives in a separate repository ([#149](https://github.com/skyoo2003/devcloud/issues/149))
+* The compatibility policy states current figures, having gone stale in five places because nothing gates it: `cmd/devcloud/coverage_test.go` covers docs/coverage.md, README.md and docs/README.md, and docs/compatibility-policy.md is not in that set. It now reads 1,144 tests, 5,193 `auto-crud`, 4,497 hand-verified, 205 registered with 4 serving nothing, and 193/12 model-backed to hand-written ([#150](https://github.com/skyoo2003/devcloud/issues/150))