fix(docs): sync parity rows with the Smithy models (7,612 ops); gate rows, service pages and landing pages

Merged
VI
7d ago
+395-126

Summary

check-doc-counts.sh was green, but parity.md's Ops column (which every headline count is summed from) had fallen behind the code. Nothing compared it with the models.

Canonical values after this PR: 106 services, 7,612 operations (was 7,553), 257,288/257,288 variants, Bedrock family 222 (was 216), 31 Lambda runtimes.

Parity rows fixed (each op checked for a real dispatch arm + handler)

rowwasnowwhy
S3107112object annotations (5 ops, #261f2f2b2) shipped after a model refresh; row never moved
KMS5354GetKeyLastUsage
RDS163164DescribeServerlessV2PlatformVersions
Bedrock Runtime1011InvokeGuardrailChecks
AWS Backup109115backup access points (6 ops)
WAFv25559revenue statistics / settlement records (4 ops)
Lambda7388durable executions + capacity providers, in supported_actions() and conformance since April
CloudFront147167every modeled op dispatched and conformance-tested
Bedrock103108same
CloudWatch5455same

The new rule: a row equals the number of unique operations in its Smithy model(s). That is already true of the other 96 rows, and conformance probes every one of those ops.

Service pages that disagreed with their own row

57 of 57 DynamoDB (58), 802 of 802 EC2 (807), 44 of 44 Kinesis (45), 115 of 115 CloudWatch Logs (118), 126 of 126 Cognito User Pools (132), All 49 CloudWatch (55), 73 of 73 Lambda, 147 of 147 CloudFront, plus S3/KMS/RDS/Backup/WAFv2/Bedrock.

Landing pages and aggregate rows

Number-first landing-page claims: **53 KMS operations** (54), RDS 163 (164), DynamoDB 57 (58, body and description), S3 107 (112), SES 110 (116), Cognito User Pools 122 (132). Aggregate rows whose (all N ops) trailer contradicted the row's own count: Backup 109/115, EKS 65/70, OpenSearch 93/96, Account Management 15/18, Identity Store 19/22. CloudFront's intro paragraph said 147 operations..

Gate hardening (scripts/check-doc-counts.sh)

  1. parity row vs Smithy model. Rows are summed per docs slug and compared with the unique op count of the model(s) mapped to that slug in generate-operations-index.sh's SERVICES. A service page with a model but no parity row fails the gate.
  2. Service pages' own headline (N of N, **N operations**, All N operations, N-operation) is checked against that page's row(s).
  3. Bedrock phrasings that the old <N> Bedrock operations regex missed: N ops across 4 APIs, N of N Bedrock-family, (Bedrock N, Bedrock Runtime N, ...), ### Bedrock (N actions).
  4. Aggregator aliases: | WAF v2 | 55 | never matched WAFv2; SERVICE_ALIASES maps nine of these to their rows.
  5. Number-first claims (**53 KMS operations**, **53** KMS operations). This phrasing is folded into the existing per-service grep, so it costs no extra process spawns.
  6. (all N ops) trailers must match their row's count cell.
  7. Single-service landing pages (LANDING_PAGES): any bare N operations on the page must equal that service's row (or the Bedrock family).
  8. Rows and models are joined with a C-locale key sort. The gate fails loud if no model file resolves.

To check each new pass, I injected drift for that class alone and confirmed the gate FAILS with the expected message: row-vs-model, missing-row, service-page headline (including 57 of 58), service-page sentence, Bedrock "across", Bedrock list, alias, number-first, bold number, trailer and bare landing-page count. Negative checks: 1 of 3 shards on a service page and 7,612 operations across 106 services, including Bedrock both pass. Run time is about 21s.

Found, handled separately

AWS Batch (crates/fakecloud-batch, 45 ops, registered in the server since June) has no aws-models/service-map.json entry, so the conformance probe never measured it, and it has no parity row. Adding the map entry probes 0/1257: every request returns 404, because the harness has no wiring for Batch. A separate PR is wiring Batch into conformance and adding its row. Until that lands, PENDING_PARITY_ROW=(batch) holds the gate's missing-row check open; the gate fails once the row exists and the entry is still there.

Skipped deliberately

website/content/blog/** and marketing/** are point-in-time. Timestream's ops-index lists 34 (Write + Query share 4 names), and the row's 30 is the unique count.

Post-merge

Sync the GitHub repo description (currently "7,553 operations").

Test plan

  • bash scripts/check-doc-counts.sh passes
  • bash scripts/generate-operations-index.sh produces no diff
  • inverted sweep (number-then-noun with interposed words, comma totals, table cells) shows only whitelisted subsets (7 parity sandbox, 75 tfacc)
  • each new gate class observed failing on injected drift, then reverted
  • zola build (template index.html changed)
  • no .rs changes

Summary by cubic

parity.md's Ops column had drifted from the code: ten rows were below what fakecloud dispatches and conformance-tests, and every headline count (service pages, landing pages, aggregators) is summed from it. Fixed the rows and the pages that contradicted them, and extended check-doc-counts.sh to fail on this class of drift. Canonical totals move from 7,553 to 7,612 operations; the Bedrock family goes 216 → 222.

Parity fixes

  • Rows updated to their Smithy model counts: S3 107→112, KMS 53→54, RDS 163→164, Bedrock Runtime 10→11, Backup 109→115, WAFv2 55→59, Lambda 73→88, CloudFront 147→167, Bedrock 103→108, CloudWatch 54→55.
  • Service pages that disagreed with their own rows (DynamoDB, EC2, Kinesis, Logs, Cognito, CloudWatch, Lambda, CloudFront) and number-first landing claims (SES 110→116, Cognito 122→132, plus KMS/RDS/DynamoDB/S3) corrected.
  • Aggregate rows whose (all N ops) trailer contradicted the count cell fixed for Backup, EKS, OpenSearch, Account Management, and Identity Store.

Gate hardening

  • Each parity row is summed per docs slug and compared with the unique operation count of the model(s) mapped to that slug; a modeled service with no row fails the gate.
  • Service-page headlines, Bedrock phrasings (N ops across, N of N Bedrock-family, list form), aggregator aliases (WAF v2 → WAFv2), number-first claims, (all N ops) trailers, and bare N operations on single-service landing pages are all checked.
  • AWS Batch is exempt from the missing-row check until its conformance wiring lands.