[arberx]

Three fixes, all found by consumers of the published package. Two are breaking, so this is 5.0.0.

1. selectRepresentativeSample is quadratic, and it blocks the event loop

interleaveBySubValue walked every sub-value bucket on every round, including buckets long since exhausted. The shape that triggers it is ordinary, not adversarial: one dominant sub-value plus a long tail of one-off ones, which is what a sitemap of /p/<city>/<slug> URLs looks like. Both the round count and the bucket count become ~n/2, so emitting n values cost ~n²/4.

ordered is already sorted by descending bucket size, so the buckets still holding a value at round r are exactly a prefix of it. Shrinking that prefix as rounds advance is linear and picks the identical pages.

n=40,000    6,851ms -> 8ms
n=110,398  52,695ms -> 22ms

The severity is not the wall clock. The work is synchronous and runs before the first page fetch, so it blocks the event loop and thereby suspends the very timeouts, AbortSignals and fetch budgets meant to bound a sitemap audit. In a hosted deployment, one 5 MB sitemap — a single fetch of the budget — froze the whole process for 13 seconds, taking the health endpoint and every other tenant's in-flight audit with it.

The pre-fix implementation is committed as the reference, and a seeded property test compares 500 random shapes against it, so the equivalence claim is enforced rather than asserted in a commit message. Note the sampler returns picks in document order, so the interleave decides which pages, not their order; the test compares accordingly. A linear-but-wrong-order rewrite fails it.

2. BREAKING: a factor that does not apply no longer counts against the page

An analyzer reporting applicable: false still returns score 0, and that 0 was weighted into overallScore. A product page lost real points for not being an FAQ page. The flag existed to say exactly that, and the sitemap rollup already honored it through applicableAvgScore — the page score did not.

Non-applicable factors are now excluded from both the numerator and the denominator. Dropping only the numerator would be worse than the bug, silently capping every such page below 100. factorApplies moves into scoring.ts as the one predicate both paths share.

The resolved applicability is now always emitted, not just what an analyzer volunteered. A page-specific factor judged by the presence fallback used to come back score: 0, sharePct: 0, applicable: undefined — indistinguishable from one that applied and scored zero unless the consumer reimplemented PAGE_SPECIFIC_FACTOR_IDS and the threshold.

example.com goes 31 → 35.

3. BREAKING: weight is not a percentage, and we printed it as one

The core weights sum to 111, not 100, and the score correctly divides by the actual total. Both formatters printed ${factor.weight}%, overstating all sixteen and producing a column that never adds to 100. A downstream dashboard reproduced the same mistake independently, which is the signal that the payload was missing the number rather than that consumers were careless.

Factors now carry sharePct, computed from the same denominator the score uses and allocated by largest remainder so the shares sum to exactly 100. Rounding each weight independently does not: the core set comes to 99.9, which would reproduce the same never-adds-up column one decimal down. The test asserts exactly 100 across many subsets, since one lucky denominator proves nothing.

sharePct is optional so compare still reads reports produced before it existed, and the exported factorSharePct helper uses the same allocation in that case — never weight alone. A non-applicable factor reports 0.

The markdown column header is now "% of score", and docs/scoring.md / CLAUDE.md no longer claim the weights sum to 100.

Verification

• 600 tests pass. Both new test files fail against the pre-fix implementations.
• End to end on the built dist: example.com scores 35, sharePct sums to exactly 100, every factor carries a resolved applicable, and the two non-applicable factors report 0.