bug(package): scripts/github-coordination.js is missing from the npm tarball - the 7 published /epic-* commands cannot run

Summary

scripts/github-coordination.js is missing from the published npm package, but seven commands that are published call it. Anyone who installs from npm — including npm i -g ecc-universal, the documented path — gets seven /epic-* commands that cannot run.

It works from a git clone, which is what masks this in local development.

Root cause

package.json files[] enumerates each top-level scripts/*.js by hand. scripts/github-coordination.js is not in that list, so npm excludes it from the tarball. scripts/lib/ ships wholesale ("scripts/lib/"), which is why scripts/lib/github-coordination.js survives and only the CLI entry disappears.

Verified against main (currently 2.2.2) — still not listed, so this will ship again:

"scripts/catalog.js",
"scripts/consult.js",
...
"scripts/work-items.js",
"scripts/uninstall.js"

There is no bin entry either — the map has ecc, ecc-install, ecc-memory-mcp, ecc-plan-canvas, ecc-control-pane, but no ecc-github-coordination.

Other than this file, there is no dispatcher for these actions anywhere in the package: a package-wide grep for applyClaim|applySync|applyUnblock|applyValidate|applyPublish|applyDecompose|applyReview matches only scripts/lib/github-coordination/actions.js (definitions) and scripts/lib/github-coordination.js (re-export). scripts/work-items.js has its own claim, but it is an unrelated local-SQLite subsystem.

Reproduction

npm i -g [email protected]

node "$(npm root -g)/ecc-universal/scripts/github-coordination.js" --help
# Error: Cannot find module '.../ecc-universal/scripts/github-coordination.js'

Confirm the omission from the tarball:

npm pack [email protected]
tar -tzf ecc-universal-2.2.1.tgz | grep -c '^package/scripts/[^/]*\.js$'
# 41  — running the same count over a checkout lists 42; the difference is this file

Impact

All seven of these ship in commands/ (which is in files[]) and each instructs the agent to run:

node scripts/github-coordination.js <command> <issue> --repo <owner/repo>

• epic-claim.md
• epic-decompose.md
• epic-publish.md
• epic-review.md
• epic-sync.md
• epic-unblock.md
• epic-validate.md

So the whole epic coordination workflow is broken for npm installs while appearing to work in the repo. (Related in spirit but a different bug: #3084.)

Fix

Add one line to files[]:

"scripts/github-coordination.js",

If the CLI is intentionally not meant to ship, the alternative is to remove or repair the seven command files above, since they reference a file that no release contains.

Adjacent bugs found while restoring the file

Restoring it locally to unblock the workflow exercised the CLI enough to find four real bugs in it. Happy to split these into separate issues, or send a PR, whichever is easier:

1. --limit is parsed as an issue number. It uses normalizeIssueNumber, so --limit 0 — the natural "no limit" — throws Invalid issue number: 0, and any non-numeric value reports a misleading issue-number error. applySync/applyUnblock also do limit: options.limit || 100, so 0 cannot mean "no limit" downstream either.
2. A flag placed before the command silently misroutes. node scripts/github-coordination.js --issue 5 claim --repo o/r leaves command null (only argv[0] is read as the command), so it falls through to the sync default and runs a full-repo sync instead of a claim on #5.
3. --dry-run still writes state. It opens and migrates the local store at ~/.claude/ecc/state.db, although --help promises "Preview changes without modifying GitHub or state". Passing dbPath: ':memory:' works — resolveStateStorePath already special-cases it.
4. The store is never closed on the error path. In main(), catch calls process.exit(1), so finally { if (store) store.close(); } does not run when an action throws. process.exitCode = 1 keeps the exit code and lets the cleanup run.

Environment

• [email protected] (latest published; main is 2.2.2)
• Node v26.7.0, Windows 11, gh 2.98.0