[Planeshifter]

Description

What is the purpose of this pull request?

This pull request:

• Aligns the README-side identifier in two outlier packages of @stdlib/constants/float64 with the identifier actually exported from lib/index.js, matching a namespace-wide convention already present in 91% of siblings and mirrored by the constants/float32 counterpart.

Namespace summary

• Target namespace: @stdlib/constants/float64.
• Member count: 67 non-autogenerated members.
• Features analyzed: file tree; package.json shape, scripts, stdlib keys, directories, keywords; manifest.json shape; README heading sequence; README H1 title vs lib/index.js exported identifier; lib/index.js JSDoc tag set, section markers (// MAIN //, // EXPORTS //), @see URLs, and require() graph; docs/repl.txt, docs/types/index.d.ts, test/test.js, and examples/index.js shape.
• Features with clear majority (≥75%): file tree (100%), package.json top-level key set (100%), directories and manifest.json key sets (100%), examples/, test/, docs/, include/, lib/ file-name sets (100%), @type/@constant/@default/@module/@example JSDoc tag presence (100%), README H1 title matches exported identifier (91%, 61/67).
• Features without clear majority (excluded): none in this pass reached ≥75% conformance without also having a coherent cross-namespace mirror that ruled the deviation out as intentional.

Per outlier package

@stdlib/constants/float64/gamma-lanczos-g

Rename README references from the short form GAMMA_LANCZOS_G to FLOAT64_GAMMA_LANCZOS_G to match the exported identifier in lib/index.js: six occurrences rewritten (H1, #### GAMMA_LANCZOS_G subsection header, four inline code samples), word-boundary regex leaves the STDLIB_CONSTANT_FLOAT64_GAMMA_LANCZOS_G C-macro reference intact. Aligns with 61/67 (91%) of @stdlib/constants/float64 sibling READMEs and matches the pattern already used by constants/float32/gamma-lanczos-g (FLOAT32_GAMMA_LANCZOS_G). No source, test, example, docs/repl.txt, or .d.ts file changed.

@stdlib/constants/float64/fourth-root-eps

Rewrote six occurrences of the short-form FOURTH_ROOT_EPS in the README (H1, the #### subsection header, and four inline code samples) to FLOAT64_FOURTH_ROOT_EPS, matching the identifier exported from lib/index.js and aligning with the constants/float32/fourth-root-eps sibling and 61/67 (91%) of @stdlib/constants/float64 READMEs. README-only; no source, test, example, docs/repl.txt, or .d.ts changes. Word-boundary regex, so the STDLIB_CONSTANT_FLOAT64_FOURTH_ROOT_EPS C-macro reference is untouched.

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 feature extraction across all 67 members: file tree, package.json shape and field values, manifest.json shape, README heading sequence and identifier usage, lib/index.js JSDoc tag set and section markers, require() graph, docs/repl.txt and docs/types/index.d.ts shape, test/test.js and examples/index.js filenames.
• Semantic feature extraction across all 67 members. Constants have no function signature, validation prologue, or error-construction surface, so the productive semantic signal came from JSDoc tag presence and dependency graph.
• Three-agent drift validation on each candidate finding (Opus semantic-review, Opus cross-reference, Sonnet structural-review). Five candidates were initially proposed; the cross-reference agent flagged three (cbrt-eps, eps, sqrt-eps) as needs-human because the code identifier ends in _EPSILON while the F32 sibling's README ends in _EPS, making the intended rename target ambiguous. Those three were dropped per the routine's advance criteria.

Deliberately excluded:

• @see JSDoc tag absence in 11 packages (e.g. half-ln-two, ln-half, ln-ten, sqrt-half, sqrt-two) — the omission is mirrored in every constants/float32 sibling and reflects packages without a canonical Wikipedia/OEIS reference. Same treatment applied in PR docs: tidy doc and C macro drift in @stdlib/constants/float32 #12432 for the F32 side.
• Package.json keyword absences (float64, dbl, double, math, mathematics) in 28 flagged outliers — every case mirrors the matching constants/float32 sibling's keyword set. The dbl/double absences also correspond to a coherent "64bit"-style keyword family (high-word-*, num-high-word-significand-bits, gamma-lanczos-g), not drift. Same treatment applied in PR chore: correct float64 keyword leftovers in @stdlib/constants/float32 packages #11964 and PR docs: tidy doc and C macro drift in @stdlib/constants/float32 #12432.
• ## See Also README section variation — auto-populated by the package generator and explicitly out of scope per the routine's pre-validation gate.
• README H1 rename for constants/float64/glaisher-kinkelin — the exported identifier is A (mathematical notation for the Glaisher–Kinkelin constant), not FLOAT64_GLAISHER; the F32 sibling was refactored to FLOAT32_GLAISHER, but changing the F64 export from A is a JS-side rename and needs maintainer sign-off, not a drift correction.
• constants/float64/cbrt-eps, constants/float64/eps, constants/float64/sqrt-eps — the F32 siblings use FLOAT32_*_EPS in the README while exporting FLOAT32_*_EPSILON; on the F64 side the export is also FLOAT64_*_EPSILON. Whether the F64 README should mirror the F32 short-form (FLOAT64_*_EPS) or align with the actual _EPSILON export is a maintainer judgment call, not mechanical drift.
• Any change to public API, test expectations, or example behavior.

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

This PR was authored end-to-end by Claude Code as part of the cross-package drift-detection routine. The namespace (@stdlib/constants/float64) was selected at random, structural and semantic features were extracted across all 67 members, majority patterns were computed at the 75% threshold, and three independent validation agents (two Opus semantic / cross-reference, one Sonnet structural-review) reviewed each candidate before it was applied. Two surgical, mechanical README-only corrections remain after that gate — both are unprefixed short-form identifiers rewritten to the FLOAT64_* form that already matches the export and the sibling constants/float32 README. A human should verify the changes before merging.

---

@stdlib-js/reviewers

---

Generated by Claude Code

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
constants/float64/fourth-root-eps	$\\color{green}53/53$ $\\color{green}+100.00\\%$	$\\color{green}1/1$ $\\color{green}+100.00\\%$	$\\color{green}0/0$ $\\color{green}+100.00\\%$	$\\color{green}53/53$ $\\color{green}+100.00\\%$
constants/float64/gamma-lanczos-g	$\\color{green}48/48$ $\\color{green}+100.00\\%$	$\\color{green}1/1$ $\\color{green}+100.00\\%$	$\\color{green}0/0$ $\\color{green}+100.00\\%$	$\\color{green}48/48$ $\\color{green}+100.00\\%$

The above coverage report was generated for the changes in this PR.