Toolcraft 0.0.115 regresses npm audit signatures with private bundled identities

[kamilio]

Summary

toolcraft@0.0.115 regresses the clean-consumer npm audit signatures behavior accepted by #499. A clean standalone install records private bundled workspace package identities under node_modules/toolcraft/node_modules/*, and npm attempts to resolve those identities from the public registry.

The first failure is currently:

npm error code E404
npm error 404 Not Found - GET https://registry.npmjs.org/@poe-code%2ffrontmatter

@poe-code/frontmatter@0.0.1 is not published. Other bundled private identities are present in the lock as well.

Reproduction

Environment:

• Node.js 24.14.0
• npm 10.9.7
• macOS

tmp=$(mktemp -d)
cd "$tmp"
printf '{"private":true,"devDependencies":{"toolcraft":"0.0.115"}}\n' > package.json
npm install --ignore-scripts --no-audit --no-fund
npm audit signatures

Observed: npm exits with E404 for @poe-code/frontmatter@0.0.1.

The generated lock contains entries including:

• node_modules/toolcraft/node_modules/@poe-code/frontmatter
• node_modules/toolcraft/node_modules/@poe-code/agent-defs
• node_modules/toolcraft/node_modules/@poe-code/process-runner
• other private bundled identities

This differs from the #499 resolution comment for toolcraft@0.0.93, which states that packed manifests omit name and version, leaving zero nested Toolcraft package identities in the clean lock and allowing signature audit to pass.

Expected

A clean install of the current Toolcraft release should pass npm audit signatures without publishing private implementation packages or requiring downstream registry/signature exceptions.

Acceptance criteria

• Pack and install the release candidate into a clean consumer with npm 10 and npm 11.
• Verify its lock contains no independently auditable private bundled identities.
• Run npm audit signatures successfully.
• Add a regression test that compares the packed tarball/install shape, not only the monorepo workspace shape.

[kamilio]

Fixed by 24d9978 (anonymize private bundled package identities, scoped to private packages only) and 58f7340 (release-time audit tolerance for in-flight lockstep versions), released as toolcraft@0.0.119.

Verified against the published package using the exact repro from this issue:

• clean consumer with "devDependencies": {"toolcraft": "0.0.119"}, npm install --ignore-scripts completes with a valid tree,
• the generated lock contains zero auditable private bundled identities (private manifests in the tarball omit name/version; public bundled packages like toolcraft-schema keep theirs),
• npm audit signatures passes: 13 packages with verified registry signatures, 5 with verified attestations,
• toolcraft/testing and toolcraft/mcp both import.

Exact bundled versions remain recorded in composition.json, which is generated before identities are stripped. Regression coverage: the standalone smoke (scripts/verify-toolcraft-standalone.mjs, run by the toolcraft release workflow) now asserts the packed tarball shape (private = anonymized, public = identified), asserts the clean-consumer lock omits auditable private identities, and runs npm audit signatures against the installed consumer.