[Planeshifter]

Description

What is the purpose of this pull request?

This pull request:

• removes a @throws {TypeError} callback argument must be a function JSDoc tag from three lib/sync.js files in _tools/pkgs. The synchronous APIs never accept or validate a callback; the tag was copied from the sibling lib/async.js.

Namespace summary. _tools/pkgs has 25 members, none autogenerated. The analysis covered the file tree, package.json key sets and values, README section lists and order, test//examples/ naming, public signatures, return kinds, validation prologues, error construction, JSDoc shape, and require() dependencies. Features with a clear majority (≥75%) were the file tree core, all package.json keys (100%), the README section list, error construction via format (100%), @example presence (100%), validation via isPlainObject in lib/validate.js (100%), and the lib/sync.js @throws set. Features without a clear majority were left out: bin naming, ## Notes placement (64%), public signature shape, return kind (value vs. callback), and the @throws sets in lib/async.js/lib/main.js.

_tools/pkgs/browser-deps

pkgDeps.sync( pkgs[, options] ) documented a callback TypeError that it never throws. Removed the tag from lib/sync.js. 16 of 20 sibling lib/sync.js files (80%) carry no callback @throws tag.

_tools/pkgs/browser-entry-points

entryPoints.sync( pkgs[, options] ) documented a callback TypeError that it never throws. Removed the tag from lib/sync.js (80% conformance among sibling lib/sync.js files).

_tools/pkgs/deps

pkgDeps.sync( pkgs[, options] ) documented a callback TypeError that it never throws. Removed the tag from lib/sync.js (80% conformance among sibling lib/sync.js files).

Related Issues

Does this pull request have any related issues?

None.

Reference Packages

Did the content of this pull request follow one or more existing packages? Answering is optional.

This pull request followed these packages:

• _tools/pkgs/names, _tools/pkgs/namespaces, _tools/pkgs/standalones (and the other lib/sync.js siblings in _tools/pkgs).

What carried over from the reference(s)?

• The @throws tag set on the synchronous entry point, which documents only the argument and option errors.

What differed, or what did you have to work out yourself?

• Nothing. The change only removes lines.

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. Features were extracted structurally (filesystem and strings) and semantically (one extraction agent per package). Each candidate then went through three-agent drift validation: semantic review, cross-reference of tests, examples, and docs, and structural review. No test, example, README, or docs/usage.txt refers to a sync-API callback error. The @throws tag stays in each lib/async.js, where it is correct.

_tools/pkgs/entry-points. It has the same stray tag. The change was reverted from this PR because touching lib/sync.js makes CI lint the file, and that surfaces a pre-existing stdlib/jsdoc-doctest failure in its @example, which #11672 addresses. The tag can be removed once #11672 lands.

Deliberately excluded.

• Missing lib/sync.js in dep-list, namespace-deps, name2bucket, name2standalone: these are sync-only or pure APIs.
• Missing lib/validate.js in name2bucket/name2standalone: they take no options object.
• Missing test/ in installed: it needs new tests written for that package.
• Empty CLI ### Notes in dep-list/namespace-deps: it needs content specific to each package.
• Keyword gaps: these follow genuine semantic differences between packages.

Observations not addressed here (need human review).

• deps/lib/sync.js declares @returns {ObjectArray} but can return an Error.
• name2bucket/lib/main.js checks isPositiveInteger( buckets ) twice.

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. It was produced by an automated drift-detection routine that compares packages within a namespace.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_017wWD77JrT2EefRqpDUb1Cx