npm names and publication readiness

Operator runbook for issue #99: Evaluate the eventrunner / event-runner package names and the matching @eventrunner / @event-runner scopes.

Stop before reserving names#

Issue #99 originally proposed non-functional placeholder packages and empty organizations. npm's name policy prohibits registering names solely for future use. A package with no genuine function counts as squatting. An organization with no packages published within a reasonable time can also count as squatting. Empty placeholders do not meet this policy, even when the intended project exists elsewhere.

Do not execute the original placeholder plan. Before publication, the maintainer must approve a revised scope that identifies a useful package, its release contents, and any organizations needed for active use. This runbook does not select that package or authorize a release.

Who runs publication: A human operator using the intended CCM-controlled npm user account with 2FA and organization-controlled recovery information. An npm organization is separate from the user account that logs in. Unattended sessions can perform the public read-only checks below; publication and organization creation need the maintainer's explicit final go-ahead in the execution session.

1. Check the public registry#

Package names and organizations are different registry objects. Record the time, registry, exit code, and response for each check.

Human operators can use the npm CLI commands below. An installed npm client can attach saved registry credentials even for read-only requests. Unattended checks must use the credential-free HTTP commands later in this section.

npm view eventrunner --registry=https://registry.npmjs.org/
          npm view event-runner --registry=https://registry.npmjs.org/
          npm org ls eventrunner --registry=https://registry.npmjs.org/
          npm org ls event-runner --registry=https://registry.npmjs.org/
          

A bare scope, such as npm view @eventrunner, is not an organization lookup. For a public HTTP check, use these endpoints without credentials:

curl -i https://registry.npmjs.org/eventrunner
          curl -i https://registry.npmjs.org/event-runner
          curl -i https://registry.npmjs.org/-/org/eventrunner/user
          curl -i https://registry.npmjs.org/-/org/event-runner/user
          

A 404 is an observation, not a reservation or a guarantee that npm will accept the name. If a name exists, stop and confirm its ownership with the maintainer. Do not infer control from matching names or an empty member response.

2. Prepare an approved functional release#

• Agree with the maintainer which package has a genuine function and which names and organizations are needed. Revise issue #99's placeholder acceptance criteria before treating publication as ready. For each proposed organization, identify the active package to publish under its scope. Omit organizations without an approved active package.
• Review the release files, license, version, README, and package metadata. Preview the tarball file list with npm pack --dry-run --ignore-scripts from the approved package directory. This does not create or test the tarball.
• Review lifecycle scripts and generated build files before approving the final release contents. The preview above skips scripts; publishing from a directory can run them and produce different contents.
• After approving the build and lifecycle scripts, create one final tarball per approved package with npm pack. npm treats a tarball as one package. @eventrunner and @event-runner need separate tarballs when both organizations are approved. Inspect each tarball's actual file contents, including generated files, and check for private data. Record each path and SHA-256 checksum with the release approval. Publish each exact reviewed tarball. An approval for one package does not cover a second name. Rebuilding or changing a tarball requires another review.
• Confirm the package's behavior with the relevant checks for that release.
• Keep secrets and private files out of the tarball. Do not publish from the repository root or remove a workspace's private flag to reserve a name. The existing root and workspaces are private application packages.

3. Confirm the operator account#

Run npm whoami --registry=https://registry.npmjs.org/. Confirm the returned user is the approved operator. On the npm website, verify that user's 2FA and recovery details. If an approved organization already exists, also verify the required organization role. A new organization has no role to verify until step 5 creates it. A successful login does not prove those checks.

If login is needed, the human operator completes npm login and 2FA. Do not script around 2FA or store a token that bypasses it.

4. Recheck and obtain the final go-ahead#

Repeat all four registry checks immediately before any public change. Ask the maintainer to approve the exact names, every reviewed tarball and checksum, the public registry https://registry.npmjs.org/, and the organization actions in that execution session. Confirm each tarball checksum still matches. Earlier planning approval is insufficient. A role on an organization that does not exist yet is not a prerequisite. Stop if the observed ownership changed or any other prerequisite is unverified.

5. Create only the approved organizations and publish#

Follow npm's organization creation instructions on the website. Select the free public-package plan unless a paid plan is separately authorized. Add the approved maintainers and verify their roles. An organization's name is its scope. Create an organization only when the approved release includes its active scoped package. A member roster alone does not satisfy the active-use policy. After creation, and before publishing that scoped package, verify the operator's organization role.

The documented npm org command manages members with set, rm, and ls; it does not provide npm org create.

Publish each exact reviewed tarball to the public registry only. The command must pass --registry=https://registry.npmjs.org/. A saved .npmrc registry does not replace that flag. npm publish accepts a local tarball path. Do not publish from the source directory or repack after approval. The shape below is not approval to publish. Substitute one reviewed tarball path, and repeat it for every approved package. Add the approved --access value only when the maintainer named it.

npm publish <reviewed-tarball> --registry=https://registry.npmjs.org/
          

Complete 2FA interactively.

6. Verify ownership and record the result#

• Run npm view <approved-package-name> --registry=https://registry.npmjs.org/ for every approved package and check the exact version, description, and maintainers against that package's approved release.
• Check each approved organization with npm org ls <org-name> --registry=https://registry.npmjs.org/ while signed in as the operator, and verify owner and maintainer roles on the npm website.
• For every created organization, verify its approved scoped package exists in the registry and is associated with that organization. Record the package URL and the organization's access to it. An empty organization is incomplete.
• Record ownership, recovery details, publication date, and roles in the team's operator password/secrets manager, as used by docs/POSTMARK_PROVISIONING.md. Store recovery codes and any approved credentials only in operator storage. Enter one-time 2FA codes at the interactive prompt; never record them.
• Report the verified public result and the ownership-record location. Keep issue #99 open until its revised acceptance criteria are met. A missing public package, successful login, or new organization alone does not complete it.