Pre-publish scrub: a home-directory path ships in @cluesmith/t3-client, and neither new package carries its declared LICENSE

[pseudoseed]

The human has approved publishing @cluesmith/porch-driver and @cluesmith/t3-client as public npm
packages on one condition: zero secrets, identities or PII in what ships — code and comments
alike. npm publishes are effectively irreversible, so this has to be closed before the next
release, not after.

I audited both packages. Result: one blocking leak, two hygiene gaps, and no secrets.

Blocking — a home-directory path ships in the tarball

packages/t3-client/src/auth.ts:9

 * `codev/experiments/146-t3code-porch-proof/` and `/Users/chris/dev/t3code-spike/
 * spike.mjs`. t3code uses `POST /oauth/token`, form-encoded, ...

Both packages declare "files": ["src", "dist"], and neither tsconfig sets removeComments, so this
ships three times:

packages/t3-client/src/auth.ts:9
packages/t3-client/dist/auth.js:9
packages/t3-client/dist/auth.d.ts:9

It discloses the maintainer's username and local directory layout in a package published under their
own name.

Fix: keep the pointer that is useful and drop the one that is not. codev/experiments/146-t3code-porch-proof/
is a committed path a reader can actually follow; the second is a machine-local scratch directory
that exists on exactly one computer. Rewrite the sentence to reference only the committed experiment.

What is clean, so the scope is not larger than it looks

• No secrets of any kind. No tokens, keys, credentials, private key blocks, or assignment-shaped
  literals in either package's shipped source.
• No emails, no external hostnames, no IPs other than 127.0.0.1 in a loopback-security comment,
  which is correct and should stay.
• No process.env.* reads at all in either package's shipped source.
• packages/t3-client/live/integration.mjs carries /Users/chris/dev/t3code twice, but live/ is
  not in files, so it does not ship. Worth cleaning for tidiness; not a publish blocker.
• packages/codev/src/__tests__/spec-146-t3-contract.test.ts:43 has the same default, and
  packages/codev ships dist and not src, so it does not ship either.

For context on severity: /Users/chris already appears in 38 tracked files across this public
repository, so the username is not newly disclosed by publishing. The condition set was about these
packages, and auth.ts:9 is in them.

Hygiene gaps, same pass

1. Neither package has a LICENSE file. Both declare "license": "Apache-2.0". npm includes
   LICENSE automatically when present, and neither has one — so both would publish claiming a
   license whose text they do not carry. Add the Apache-2.0 text to both.
2. Neither has a repository field, so npm will not link back to the source. Add it.

The part that matters more than the fix

Add a guard, because remembering does not scale to the next published package:

A test that reads each publishable manifest's files list, resolves what would actually ship, and
fails when any shipped file matches a home-directory path (/Users/, /home/<name>/, C:\Users\).
Assert its own reach — it must fail when pointed at a set it cannot resolve, so a manifest change
cannot make it vacuously green.

This is the same shape as the manifest guard added in #209, which reads the dependency set rather
than restating it. Four packages publish today and two more are about to; the sixth will not be
checked by anyone remembering.

Related: #209 (the publish path, where these two became publishable), #199.

[pseudoseed]

On it! Working on a fix now.

[pseudoseed]

Closed by PR #215, merged as 4ebaf36b6 (a true merge, 2 parents — not a squash).

What was actually wrong

One line. packages/t3-client/src/auth.ts:9 carried an absolute home-directory path in a
comment explaining where the working OAuth flow had been proven:

 * `codev/experiments/146-t3code-porch-proof/` and `/Users/chris/dev/t3code-spike/
 * spike.mjs`. t3code uses `POST /oauth/token`, form-encoded, ...

It shipped three times, not once: src/auth.ts, dist/auth.js:9 and dist/auth.d.ts:9.
Two independent reasons stack to produce that:

• package.json sets files: ["src", "dist"], so source ships alongside the build.
• Neither tsconfig sets removeComments, so the comment survives into .js and .d.ts.

Either one alone would have leaked it. That is worth stating plainly, because the instinct
after finding a leak in a comment is to reach for removeComments — and here that would have
fixed two copies out of three and left the one in src/ shipping.

Why it mattered enough to block a publish

@cluesmith/porch-driver and @cluesmith/t3-client are the first two packages going public
from this repo. The human's approval was conditional and explicit: zero secrets, identities or
PII in what ships, code and comments included. A username in an absolute path is an identity.
npm publishes cannot be retracted — an unpublish window exists, but a mirror or a lockfile
that already resolved it does not care.

What now prevents the next one

packages/codev/src/__tests__/bugfix-214-publish-scrub.test.ts — 16 tests that ask npm pack --dry-run --json what would actually ship, then scan that set. Not a glob of what someone
believes ships. Three properties of it are the reason I expect it to still be true in a year:

1. It asserts its own reach. A test that scans an empty file set passes vacuously and reads
   green forever. This one has it('resolves a non-empty shipped set for every publishable package'), and a whole describe('the guard fails when it should') block that plants a home
   path in a shipped file and requires the red. A guard that cannot demonstrate it detects the
   thing is a decoration.
2. It reads sourcemap sources entries. Absolute build paths land there routinely and are
   invisible to anyone reading the .js.
3. It refuses a name allowlist. From the builder's own comment: a red that gets argued away
   is how allowlists start. Correct. The moment one username is allowed through by name, the
   check answers a different question than the one it claims to.

It also distinguishes "no packages at all" from "packages, none publishable" — two states that a
naive emptiness check collapses into the same silent pass.

Correction folded in

spec-146-phase-9-thread-backend.test.ts:169, a guard I approved under #209, matched only
working-directory: <path> and so counted packages/codev's copy-skeleton step as a build.
It now requires working-directory: <path> followed by run: … pnpm build. Same defect class
as the leak itself: a check reporting a state it was not positioned to observe.

Verified before approval

Every shipped source file in both packages is clean of /Users/ and /home/. No secrets, no
email addresses, no external hostnames or IPs (127.0.0.1 appears once, inside a security
comment), and no process.env.* reads in either package. Full suite at merge: 342 files
passed / 3 skipped, 6796 tests passed / 51 skipped, 0 failed.

Reviewer accounting, unrounded: claude APPROVE HIGH, opencode APPROVE HIGH, gemini SKIPPED
(the lane's own LANE_DID_NOT_REVIEW, agy quota), codex NO REVIEW (usage limit — exit 0 with
no output file, which is precisely the shape that gets miscounted as a pass).

Follow-up, for the record

The merge turned main red — not through the shipped fix, but through the CI step that makes the
guard meaningful. #215 added pnpm build to the unit job so the guard would scan real build
output instead of silently narrowing to committed files; that made the root npm pack in
extension-retirement.test.ts cross a 10s hook timeout it was already sitting near, by 544ms.

Fixed in #216 / PR #218 (18f9eb2bb), and the build step stayed. main is green, verified
per-job.

Worth stating plainly: the guard could not have been trusted without that build step, and the
build step could not land without breaking a test that packed 27.4 MB to read a list of
filenames. Both facts were true before this issue existed. The work surfaced them.