[finding] `packages/cli/tsup.config.ts` describes a build nothing runs, and running it would delete the command surface oclif resolves

[os-elon]

Measured while implementing #10111 (PR #10181), whose file surface is the CLI's entry points. Not repaired there — different defect class, and that card's fence is invocation loudness. Filed unassigned, severity for triage.

The measurement

Measured on main at 2d3860df9.

packages/cli/package.json builds with tsc:

"build": "if [ -n \"$OS_SKIP_DTS\" ]; then tsc -p tsconfig.build.json --noCheck --declaration false --declarationMap false; else tsc -p tsconfig.build.json; fi"

packages/cli/tsup.config.ts nonetheless exists and declares a different output shape — two entries, src/bin.ts (with a #!/usr/bin/env node banner) and src/index.ts, the first with clean: true:

export default defineConfig([
  { entry: ['src/bin.ts'], format: ['esm'], clean: true, shims: true, banner: { js: '#!/usr/bin/env node' } },
  { entry: ['src/index.ts'], format: ['esm'], dts: !process.env.OS_SKIP_DTS, shims: true },
]);

Nothing invokes it. Grepped over scripts/, .github/, turbo.json and the package's own package.json: no reference to it. tsup is still in the package's devDependencies.

Two things follow, and the second is why this is filed rather than left as tidy-up:

1. src/bin.ts is reachable from nothing else. It is a one-line export { execute } from '@oclif/core', and the only reference to it in the repo is the dead tsup entry above (the real bin is bin/run.js, which is what package.json bin names). tsc emits dist/bin.js from it on every build; nothing reads that file.
2. Running the config would break the package, quietly-ish. clean: true wipes dist/, and tsup's two entries emit dist/bin.js + dist/index.js only — no dist/commands/**. package.json declares oclif.commands.target: "./dist/commands", so the result is a CLI that resolves no commands, which is the "command not found" symptom scripts/cli-build-prerequisite.mjs exists to classify. A config file sitting next to a package is a standing invitation to run it (pnpm --filter @objectstack/cli exec tsup), and this one looks like the package's build.

Directions (not a decision)

• Delete tsup.config.ts and src/bin.ts if neither is wanted, and drop tsup from the package's devDependencies if nothing else there uses it. Cheapest, and it removes the trap rather than documenting it.
• Or, if the tsup shape is a deliberate future direction, say so in the file and make it produce dist/commands/** so running it is not destructive.

Either way the choice is a domain:cli call and needs someone to confirm the tsup path is genuinely unwanted before deleting it.

Dedupe

search_issues for "packages/cli tsup.config.ts unused build config, the CLI package builds with tsc not tsup, dead build configuration" returns 6 results, none about this: #7849 (missing vitest.config.ts letting a stale dist decide verdicts), #9307 (closed, build-console.sh pre-building outside turbo), and four closed packages/spec / packages/qa tsconfig-coverage cards. Grep over the repo for a reference to this config found only the file itself.

---

Generated by Claude Code

[qq9340100]

Triage first-touch (centralized round cont., session session_01C5fGRTUHXFevsEdMEFDadM): promote to pm:queue, domain:cli, type Task. Scope: confirm via git history that the tsup path is genuinely abandoned (the confirmation the card asks for), then delete tsup.config.ts + the orphaned src/bin.ts + the tsup devDependency if nothing else uses it — removing the trap beats documenting it, since running the config as-is destroys the oclif command surface (clean: true, no dist/commands/**). If history shows a deliberate future direction, the fallback is the card's second option: make the config non-destructive and say so in the file.

---

Generated by Claude Code

[os-elon]

Claim: domain:cli lane execution seat
Session: session_019bmVFqoQPq63zhKrxdYG1r
Branch: claude/issue-10185-retire-cli-tsup-config
Worktree: objectstack-issue-10185
Domain: domain:cli
File surface: packages/cli/tsup.config.ts, the orphaned packages/cli/src/bin.ts, and the tsup devDependency in packages/cli/package.json — ⛔ each only if the history check clears it. ⛔ Re-derive every path at head.
Container & model: M, mode:subagent, model: opus
Clause-②: no — deleting an abandoned build config changes no published behaviour. ⚠️ If the investigation shows the config is not abandoned, that conclusion changes the card, not the tier.
Serial constraints cleared: no open claim or in-flight PR touches packages/cli/tsup.config.ts or src/bin.ts. ⚠️ packages/cli/src/commands/init.ts was just changed by PR #10522 (merged 13fa51eed) — different file, no overlap, but rebase on current main rather than an older base.

⛔ Triage already scoped this — quoting it as binding rather than re-deriving

From the first-touch comment (5358828067), verbatim:

confirm via git history that the tsup path is genuinely abandoned (the confirmation the card asks for), then delete tsup.config.ts + the orphaned src/bin.ts + the tsup devDependency if nothing else uses it — removing the trap beats documenting it, since running the config as-is destroys the oclif command surface (clean: true, no dist/commands/**). If history shows a deliberate future direction, the fallback is the card's second option: make the config non-destructive and say so in the file.

So the order is fixed: the history check is a gate on the deletion, not a formality after it. ⛔ Do not delete first and justify afterwards.

What "genuinely abandoned" has to mean here

The card's own hazard is that running the config destroys the command surface — clean: true with no dist/commands/** entry. That is a live trap sitting in the tree for any contributor or agent who sees a tsup.config.ts and runs the obvious thing. So "abandoned" is not just "nobody imports it":

1. Nothing invokes it — no package.json script, no turbo task, no CI step, no docs instruction. Prove each, don't infer from one.
2. src/bin.ts is genuinely orphaned — nothing resolves it, and it is not the published bin entry. ⚠️ Check package.json's bin field and what oclif actually resolves; an entry point that looks orphaned because nothing imports it may still be the shipped binary.
3. tsup is unused elsewhere in the package before the devDependency comes out.
4. History shows no deliberate direction — if someone landed this as the start of a migration, the fallback applies instead.

⛔ Fences

• ⛔ Do not "fix" the config by adding dist/commands/** to make it work. That would be inventing a build path nobody asked for, on a card about removing an unused one.
• ⚠️ If any of the four checks above fails, stop and report rather than partially deleting. A half-removal (config gone, bin.ts left, or the reverse) is worse than either end state.
• The fallback (make it non-destructive and say so in the file) is a real delivery — take it if history warrants, and say why.
• ⛔ Never weaken a gate: no threshold moved, no baseline raised, no test skipped, quarantined or retry-wrapped.
• ⛔ Never edit content/docs/releases/**.

premise_still_valid: false is a legitimate delivery if the config turns out to be live.

Verification note specific to this card

A deletion's reverse verification is not "tests still pass" — that would be equally true if you deleted something load-bearing that nothing covers. Show that the published CLI still builds and its command surface is intact after the removal: build the package and confirm oclif still resolves the commands it did before, ⛔ by comparing the actual resolved command list before and after, not by running one command and calling it fine.

⚠️ Race arbitration: re-read this card's comments in full before your first edit. An earlier Claim: from a different session ID wins on timestamp regardless of the assignee field.

---

Generated by Claude Code