Skip to content

Audit runtime-core for npm publish readiness #13

Description

@GsCommand

Audit commandlayer/runtime-core and determine whether it is safe to publish to npm.

Do not publish.
Do not merge.
Do not make changes in this task unless explicitly asked later.

Goal:
Produce a publish-readiness report for runtime-core as the shared crypto/canonicalization/receipt primitive layer used by runtime, agent-sdk, and VerifyAgent.

Audit areas:

  1. Package metadata
  • package.json name, version, description, license, type/module format
  • main/types/exports correctness
  • files whitelist correctness
  • npm publish access expectations
  • repository/homepage/bugs fields
  • sideEffects setting if relevant
  • engines field
  1. Build output hygiene
  • Confirm dist/ is not tracked in git unless intentionally required.
  • Confirm .gitignore excludes build artifacts.
  • Confirm package files includes only intended publish artifacts.
  • Confirm no src/shims.d.ts or temporary files are being published accidentally.
  1. TypeScript/build/test health
    Run:
  • npm install
  • npm run build
  • npm test
  • npm run typecheck if present
  • npm pack --dry-run

If a command fails because of environment/registry access, report that clearly and separate environment failure from code failure.

  1. Public API audit
    Inspect exported modules and types.
    Confirm public API is minimal and stable for:
  • canonicalizeSortedKeysV1 / canonicalization helpers
  • hash helpers
  • Ed25519 signing/verification helpers
  • receipt creation/verification helpers if present
  • ENS signer/TXT helpers if present

Check for accidental exports of internal helpers.

  1. Receipt/canonicalization consistency
    Check whether all receipt canonicalization paths use the same canonicalization function.
    Specifically audit for inline key-sort logic vs shared canonicalizeSortedKeysV1.
    Report any divergence.

  2. Status naming consistency
    Audit ReceiptStatus or equivalent types.
    Confirm emitted statuses and types agree.
    If types say ok | error but runtime emits success, report it.
    Do not change yet.

  3. ENS/signature helper correctness
    Audit any ENS verification or TXT record helper files.
    Check default TXT keys against current CommandLayer convention:

  • cl.sig.pub
  • cl.sig.kid
  • cl.sig.canonical
  • cl.receipt.signer
    Report wrong or legacy defaults.
  1. Security and secrets
    Search for:
  • private keys
  • test keys that look production-like
  • hardcoded secrets
  • npm tokens
  • API keys
  • accidentally committed .env files
    Report findings.
  1. Dependency hygiene
  • audit dependency list
  • check for unnecessary runtime dependencies
  • check package-lock status
  • confirm lockfile is committed if package uses npm
  • run npm audit if feasible, but do not block solely on low/noise findings unless material
  1. README/publish docs
    Check README for:
  • install command
  • usage examples
  • API examples
  • npm package name matching package.json
  • publish/release instructions if present
  • warnings about experimental APIs if needed
  1. Cross-repo compatibility
    Report whether runtime-core appears compatible with:
  • commandlayer/runtime
  • commandlayer/agent-sdk
  • commandlayer/verifyagent
    Do not edit other repos.

Output report:
Use this format:

Publish readiness: SAFE / NOT SAFE / SAFE AFTER FIXES

Score: X/10

Blocking issues:

  • ...

Non-blocking issues:

  • ...

Commands run:

  • ...

npm pack --dry-run contents summary:

  • ...

Recommended fixes before publish:

  1. ...
  2. ...
  3. ...

Recommended publish command only if safe:

  • npm publish --access public

Important:
Do not publish.
Do not tag a release.
Do not change package version.
Do not commit changes.
Only audit and report.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions