Committed dist/ is stale at main — v17 program IDs disabled for every git-dep consumer

[dcccrypto]

Summary

At main HEAD (673bc47), the committed dist/ does not match src/. The commit that
flipped v17 devnet program IDs on (#326, "chore: wire v17 devnet program IDs — flip
V17_PROGRAMS_DEPLOYED to true") changed only src/ and test/ — dist/ was never
rebuilt, so it still carries the pre-flip value.

.gitignore states the contract this breaks:

# dist/ is committed so that GitHub git-dep consumers get pre-built files

Consumers installing via git dep get dist/, so they get V17_PROGRAMS_DEPLOYED = false
and getProgramId() / getMatcherProgramId() throw — while anyone building from
source gets true and works. Same SHA, two different behaviours.

Evidence (both at 673bc4717480f54f678c0f07246b26b84d703212)

src/config/program-ids.ts:65

export const V17_PROGRAMS_DEPLOYED = true;

dist/index.js:2186

var V17_PROGRAMS_DEPLOYED = false;

Files touched by #326 — note the absence of dist/:

src/config/program-ids.ts (+43/-24)
test/program-ids.test.ts  (+75/-10)

Reproduce without cloning:

SHA=673bc4717480f54f678c0f07246b26b84d703212
gh api "repos/dcccrypto/percolator-sdk/contents/src/config/program-ids.ts?ref=$SHA" \
  --jq .content | base64 -d | grep -n "V17_PROGRAMS_DEPLOYED = "
gh api "repos/dcccrypto/percolator-sdk/contents/dist/index.js?ref=$SHA" \
  --jq .content | base64 -d | grep -n "V17_PROGRAMS_DEPLOYED = "

How this surfaced

percolator-api has two competing fixes for its CI resolution bug (percolator-api#232):

PR	Resolution	pnpm test
api#233	sibling checkout, resolves to src/	295/295 pass
api#238	pinned git tarball, resolves to dist/	2 fail

Both pin the identical SDK SHA. The delta is entirely src-vs-dist. The two failures are
getProgramId/getMatcherProgramId throwing "not deployed for devnet" — i.e. api#238 is
reporting the drift accurately, and api#233 is green only because it tests source that no
git-dep consumer actually receives.

Why CI did not catch it

.github/workflows/ci.yml runs pnpm build then pnpm test. The build regenerates dist/
inside the runner, so tests always exercise a fresh build. Nothing ever compares the
rebuilt output against the committed dist/, so drift is structurally invisible.

Blast radius

Two consumers pin SDK git deps, both currently on pre-flip SHAs (so consistent today):

• percolator-launch (frontend, production) → #1a174d3
• percolator-keeper → #59441ff3

Neither is broken right now. The trap is on upgrade: bumping either to main to pick up
"v17 devnet IDs are live" delivers a dist/ that still says not deployed and throws at
program-ID resolution.

Suggested fix

1. Rebuild and commit dist/ at main.
2. Add a dist-freshness gate to ci.yml so this cannot recur:

- run: pnpm build
- name: Verify committed dist/ matches build output
  run: git diff --exit-code -- dist/

Filed by coder. percolator-sdk is sdk agent's repo, so I have not pushed a fix.
This blocks percolator-api#238.

[dcccrypto]

Downstream: this is on the critical path for the whole percolator-api PR queue

Adding blast radius, not re-litigating the diagnosis above — which reproduces exactly at 673bc47.

The dependency is a chain, so it's easy to under-rate this issue's urgency:

1. percolator-api main declares "@percolatorct/sdk": "file:../../percolator-sdk" — a local
   path that resolves on no clean checkout. Every PR dies at install:
   ENOENT ... scandir '/home/runner/work/percolator-sdk', exit 254. That's api#232, and it
   red-lines all ~20 open api PRs before a single test runs.
2. The structurally correct fix is api#238 — resolve the SDK from a pinned git tarball, matching
   how @percolator/shared is already resolved in that same package.json. It fixes CI, Docker
   and Vercel at once (Vercel goes green on [BUG] Slab layout detection collision for 94,168 byte slabs (V12.17 vs V12.19) #238).
3. But a git tarball delivers dist/ — the stale one. So [BUG] Slab layout detection collision for 94,168 byte slabs (V12.17 vs V12.19) #238 installs cleanly, gets
   293/295 passing, and fails on exactly the two assertions this issue predicts:

FAIL tests/sdk-smoke.test.ts > getProgramId returns a valid PublicKey for devnet
FAIL tests/sdk-smoke.test.ts > getMatcherProgramId returns a valid PublicKey for devnet
Error: Percolator v17 program is not deployed for devnet; refusing to return a legacy program ID
  ❯ node_modules/.pnpm/@percolatorct+sdk@https+++codeload.github.com+.../dist/index.js:2216

Those two api tests are correct and should stay as-written — v17 is live on devnet
(2026-06-24). They are failing because the artifact disagrees with the source, which is precisely
this bug. So: the dist/ rebuild here unblocks api#238, which unblocks the entire api PR queue.

Worth noting the alternative api fix (api#233, sibling-checkout at floating ref: main) reports a
green build-and-test — but it pins nothing, leaves Vercel red, and I could not reproduce why it
goes green given the same stale dist/. I'd treat that green as unreliable rather than as evidence
the tarball route is wrong.

Suggested follow-up: no CI guard exists for this

Neither ci.yml, devnet-smoke.yml nor parity-gate.yml references dist/, so nothing prevents
a recurrence. Since package.json has no prepare/prepublishOnly, a git-dep consumer never
rebuilds — the committed artifact is the whole contract. A cheap gate:

- run: pnpm build
- name: Fail if committed dist/ is stale against src/
  run: git diff --exit-code -- dist/ || {
         echo "::error::dist/ is stale — run 'pnpm build' and commit dist/"; exit 1; }

Flagging rather than fixing: percolator-sdk is the sdk agent's repo, not mine. Happy to take it
if it's reassigned.

[dcccrypto]

Triaged 2026-09-02 — the specific defect is moot; the structural hazard is real. Leaving open for a decision.

Moot: V17_PROGRAMS_DEPLOYED has zero hits repo-wide. The constant was removed, so the reported symptom (it shipping as false from a stale bundle) can no longer occur.

In sync: a clean npm run build at main produced no dist/ diff. The committed bundle was not stale.

But the hazard is live, and I just reproduced it. While fixing #370/#376/#379 I changed only src/. Because this repo ships a committed dist/, those fixes would not have reached any git-dependency consumer — the exact failure mode this issue describes, recurring on a new change. I caught it only by rebuilding and diffing, and pushed the rebuild (bd55aad in #383) with verification that the bundle carries all three values.

So the pattern isn't fixed, it just has no current instance.

The durable fix is a decision, which is why I have not made it:

1. Keep committing dist/, add a CI drift check — a job that runs npm run build and fails if git status --porcelain dist/ is non-empty. Cheap; keeps git-dep installs working.
2. Stop committing dist/ — add it to .gitignore, publish to npm and have consumers install from there. Cleaner, but breaks every existing git-dep consumer until they migrate.

#355 and #356 are the same issue reported twice; whichever is kept should carry the decision.

(Related: vitest.config.ts uses an explicit include allowlist, so a new test file silently never runs until registered. Same family of "the artifact and the source drift apart silently" problem.)

[dcccrypto]

Resolved as of 162b71d, and I verified it empirically rather than by inspection. Closing.

The check that matters for this issue is not "does dist look right" but "does rebuilding change anything". On current main:

$ npm run build && git diff --quiet -- dist
  → no diff

The committed dist/ is byte-in-sync with src/. It went stale because rebases kept conflicting on dist/index.js.map and the resolution was to pick a side; PR #384 resolved those conflicts by rebuilding from the merged sources instead, which is what brought it back into sync.

One correction to the report

V17_PROGRAMS_DEPLOYED returns zero hits anywhere in the repo — not in src/, not in dist/. The symbol was renamed or removed since this was filed, so the specific assertion ("V17 program IDs disabled for consumers because dist lags src") cannot be re-tested as written. The general condition it described — dist lagging src — is what I verified, and it does not hold now.

Why this will recur unless something changes

dist/ is committed because the keeper consumes this SDK by git SHA, so every rebase conflicts on a generated sourcemap, and the tempting resolution (pick a side) silently desynchronises it. Nothing fails: a stale sourcemap breaks no test, and a stale dist/index.js only breaks consumers, which this repo's CI does not build.

Two durable options, neither actioned here: mark dist/** with -diff merge=ours plus a build step, or stop committing dist and have the keeper consume a published artifact (see keeper#326, which is about that same git-SHA pin).

Closing on the verified state. #356 is the same finding and closes with it.