chore: clean-up

[Planeshifter]

Description

What is the purpose of this pull request?

This pull request:

• encloses the ## C APIs block of stats/base/dists/bradford/mean and stats/base/dists/bradford/skewness in a <section class="c"> element and normalizes the HTML comment that precedes it, making the two READMEs structurally identical to their siblings. No rendered prose changes.

Namespace summary

Namespace	stats/base/dists/bradford
Members	10 (cdf, entropy, mean, median, mode, pdf, quantile, skewness, stdev, variance); none autogenerated
Features analyzed	11 — file tree, package.json key set, scripts key set, keywords, manifest.json key set, README heading sequence, README section structure, test/benchmark/examples file naming, public signature, validation prologue, JSDoc shape
Clear majority (≥ 75%)	9
No clear majority	2 — the * * * rule preceding the C block (4/10, subsequently added to mean on review; see below) and the univariate keyword (4/10, excluded)

stats/base/dists/bradford/mean

Adds the <section class="c"> wrapper around ## C APIs in mean/README.md, enclosing the nested intro, usage, notes, and examples blocks and bringing bradford/mean in line with 8 of its 10 sibling packages (80%) and 1612 of 1614 packages repo-wide that pair a C implementation with a ## C APIs heading. Reparenting these blocks clears four latent duplicate-section warnings caused by their class names colliding with the JavaScript counterparts at root level, and satisfies the remark-lint-expected-html-sections c branch's requirement for nested usage and examples blocks, both already present. Also normalizes the preceding comment from <!-- C API documentation. --> to <!-- C interface documentation. -->, matching tools/snippets/c.md and 1929 of 1930 occurrences repo-wide.

Two further corrections were applied on review: the * * * rule ahead of the c section, and removal of a stray blank line before the closing fence of the JavaScript examples block. The blank line predates this PR and made mean the only member of the namespace whose examples block ends on an empty line.

stats/base/dists/bradford/skewness

The ## C APIs section in skewness/README.md lacked the <section class="c"> wrapper and its <!-- C interface documentation. --> marker, leaving the intro, usage, notes, and examples blocks at root level where they collided with their JavaScript counterparts' class names. This left bradford/skewness, alongside bradford/mean, as the only two exceptions among the 1614 packages repo-wide that pair a C implementation with a ## C APIs heading. Wrapping the blocks in <section class="c"> / <!-- /.c -->, placed before the untouched <section class="references">, brings the package in line with its 8 bradford siblings (80%) and clears four latent duplicate-section warnings.

Related Issues

Does this pull request have any related issues?

No.

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

Validation

Checked:

• Structural extraction over all 10 members: file tree, package.json/scripts/stdlib/manifest.json key sets, README heading sequence and <section> structure, and test/benchmark/examples file naming.
• Semantic extraction per package: public signature, return kind, validation prologue, error construction, JSDoc shape, and require() dependency set.
• Lint posture of the proposed markup against remark-lint-expected-html-sections and remark-lint-html-section-structure as configured by etc/remark/plugins/pkg_readmes.js. The c class is optional at root but requires nested usage and examples when present; both READMEs already carry them, so the newly activated branch passes. Section balance and </section> → <!-- /.class --> pairing were verified to match median/README.md and variance/README.md exactly.
• Placement of the closing </section> relative to <section class="references">, against the 777 packages repo-wide that carry both.
• Repo-wide conformance after the change: 1614/1614.

Deliberately excluded:

• Intentional deviations. stdev has an empty validation prologue because it is sqrt( variance( c ) ) in both JS and C and variance already guards isnan( c ) || c <= 0.0; adding a guard would be dead code. mode has no test/fixtures/python/runner.py because mode( c ) is the constant 0.0 and there are no reference values to generate.
• Generator-owned artifacts. skewness lacks a docs/img/ equation SVG, which is produced by the remark-svg-equations-to-file tooling and referenced only from a commented-out, SHA-pinned fallback <img>; the package already renders its equation through the current fenced math block. repl.txt, docs/types/*.d.ts, and the auto-populated ## See Also blocks were out of scope throughout.
• Features without a clear majority. The * * * rule before the C block appears in only 4/10 members, below the 75% threshold, so it was initially left as found. It was added to mean on review: repo-wide the rule is present in 1926/1948 packages carrying a c section and is part of tools/snippets/c.md, so the namespace sample was the misleading signal. skewness already carried it. The univariate keyword (4/10) remains excluded.
• Low-materiality metadata. The skewed keyword is present in 8/10 members and absent from quantile and skewness. It was dropped: quantile is already touched by open PR refactor: correct Unary probability parameter in base/dists/bradford/quantile #12496, and every skewness package across the other distribution namespaces uses skewness/shape/asymmetry in its place.

No test or example reads either README, and neither package's docs/types/test.ts is affected.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

AI Assistance

When authoring the changes proposed in this PR, did you use any kind of AI assistance?

• Yes
• No

If you answered "yes" above, how did you use AI assistance?

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

Disclosure

If you answered "yes" to using AI assistance, please provide a short disclosure indicating how you used AI assistance. This helps reviewers determine how much scrutiny to apply when reviewing your contribution. Example disclosures: "This PR was written primarily by Claude Code." or "I consulted ChatGPT to understand the codebase, but the proposed changes were fully authored manually by myself.".

This PR was written primarily by Claude Code, as part of an automated cross-package drift audit. The outliers were found by extracting structural and semantic features from all 10 members of the namespace and taking a per-feature majority vote at a 75% threshold; each candidate correction was then reviewed by separate agents for semantic justification, test/tooling dependencies, and structural applicability before being applied. The resulting diff is documentation markup only.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01Kb86RxT3YPqc4KzHz4vDfi

[stdlib-bot]

Coverage Report

No coverage information available.