feat: publish the fidelity tiers against both denominators they are read against - #166
Merged
Merged
Conversation
…ead against
Registering the 226 services the demand study found nobody building enlarged a
denominator and nothing else. The page reported it as depth: hand-verified read
23.6% where it had read 36.2%, without one operation becoming less faithful, and
the only way to "offset" that number is roughly 2,450 hand-written operations
nobody asked for.
The per-operation table now publishes two columns. The serving target is the
depth promise — every registered service except those 226 — and all registered
adds the long tail back, with the 6,794 operations that exist so an SDK call
cannot leave for a billable account. Both shares are stated, both are gated, and
the denominator is named wherever the share is read.
The serving-target set is derived from docs/demand.md rather than pinned: the
registry minus exactly the rows with support < 2. A fourth place for 205 to live
is the defect this page exists to prevent. The share is carried as integer tenths
of a percent so the gate and the updater compare the digits the page shows, not
two floats that agree to a precision no reader can see.
Review follow-ups, each with a failing test first:
- The tier table's serving-target column was counted over a set whose size
nothing compared to the 205 the target table publishes. AWS shipping a
service the study never sampled grows that set to 206 — deliberately — while
the page goes on promising depth on 205 and every gate stays green.
- The paragraph under that table restates the same arithmetic in words, and
prose is where a number goes to stop being maintained. Both figures are now
gated and rewritten by the weekly sync; the second statement of 6,794 was
reworded so exactly one span owns it.
- docs/fidelity-manifest.md restates the share and nothing read it back, which
is the shape of the drift that left "148 registered / 117 serving" on both
front pages for three milestones. It is the sync's fourth page now.
- Both readers of docs/demand.md folded an unparseable support cell into their
`continue`, which read as though a malformed row were routine. demandRow
requires digits, so that branch was unreachable and the real hazard is a row
that goes missing entirely — which the denominator gate above now catches.
One parse, used twice, so the two cannot split the table differently.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Registering the 226 services the demand study found nobody building enlarged a denominator and nothing else, but the coverage page reported it as depth —
hand-verifiedread 23.6% where it had read 36.2% without one operation becoming less faithful. The per-operation table now publishes both denominators, and every page that restates the share is gated against the binary.Related Issue
Refs #166
Changes
Published figures
docs/coverage.mdsplits the per-operation table into Serving target (the depth promise: every registered service except the 226) and All registered (the long tail added back, with the 6,794 operations that exist so an SDK call cannot leave for a billable account).hand-verifiedshares are published — 36.2% and 23.6% — with the denominator named where each is read.docs/fidelity-manifest.mdgains the same note.Derivation
docs/demand.md(registry minus exactly the rows with support < 2) rather than pinned, so 205 does not gain a fourth home.Gates (five → nine)
TestPublishedOperationTiersMatchTheManifestTestPublishedFidelityShareMatchesTheManifesthand-verifiedshare of eachTestPublishedLongTailProseMatchesTheManifestTestFidelityManifestQuotesTheSameShareTestPublishedTargetTableMatchesTheBinaryWeekly sync
figureEditcarries arenderfunction instead of aseparatedbool — the page shows three renderings now (plain, thousands-separated, one decimal place) and the cell decides which.docs/fidelity-manifest.mdas a fourth target, and is idempotent on the committed pages.Files Changed
cmd/devcloud/coverage_test.goshareTenths,demandSupportcmd/devcloud/figures_update_test.gorenderfunctions,formatTenths, six new edits, three new round-trip casesdocs/coverage.mddocs/fidelity-manifest.mdchanges/unreleased/Changed-20260913-184045.yamlTest Plan
Every new gate was proved to bite before it was trusted — the figure was mangled in the tracked page, the gate was run, and the page restored:
206:promises depth on 206 … counted over 2056,795:states 6795 … columns differ by 6794fidelity-manifest.mdagrees withcoverage.md36.3%:states 36.3% … publishes 36.2%figureEdits existedshareTenthsrounds half up, not truncatesTestShareRendersTheFigureThePageShows— 1/8 →12.5, 0/0 →0.0Checklist
golangci-lint run)