[PROCESS] Open issues target `playground`, but `main` is 288 commits behind — work is being done against a stale branch

[dcccrypto]

Finding

origin/playground is 288 commits ahead of origin/main; main is 1 commit ahead of playground.

Branch	Last commit	Date
main	775a1263	2026-07-09
playground	2ae3f358	2026-07-16

Much of the open HIGH backlog is written against playground and names files that do not exist on main. I confirmed each file's presence per branch:

Issue	Named file / branch	On main?	On playground?
#2412	app/lib/liquidation-distance.ts	❌	✅
#2410	app/lib/playground-registered-markets.ts	❌	✅
#2371	states Branch: playground	—	—
#2364	states Branch: playground	—	—
#2362	app/components/trade/OrderTicket.tsx	❌	✅
#2400	app/app/api/mobile/create-market/route.ts	✅	✅

So of the recent HIGH issues, only #2400 is straightforwardly actionable against main — and it is devnet-gated.

Why this matters

Two fixes I raised against main turn out to already exist on playground:

• [HIGH] Unbounded Oracle API Caches Allow Persistent Memory-Exhaustion DoS #2416 (unbounded oracle caches) — playground already builds that cache with maxEntries. My PR fix(oracle-api): bound the publisher and resolver caches (GH#2416) #2437 is redundant.
• [High] Trade confirmation can submit a different worst-fill bound than the value reviewed by the user #2362 (worst-fill bound not forwarded) — playground's OrderTicket.tsx already has handleTrade(snapshotSize?, snapshotLimitPriceE6?) and forwards snapshot.worstFillPriceE6 through a bindConfirmedLimitPrice helper. My PR fix(trade): submit the worst-fill bound the user actually reviewed (GH#2362) #2439 is redundant.

One is not yet fixed on playground and remains live there:

• [HIGH] Portfolio shared cache accepts partial v17 owner-scan results, hiding active positions and understating account value #2414 (portfolio publishes a partial owner scan as complete) — usePortfolio.ts on playground has no isPartial equivalent. My PR fix(portfolio): stop publishing an incomplete scan as a complete one (GH#2414) #2438 fixes main; playground still needs this.

What I got wrong

I self-directed from the issue tracker without first checking which branch each issue targeted, or which branch was active. I noticed a symptom last cycle — #2362 naming a file absent from main — and flagged it, but did not follow through to a divergence check until now. Two PRs of duplicated effort is the cost.

Suggested resolution (needs a maintainer decision)

1. State which branch is authoritative. If playground is where work lands, say so in the repo (README/CONTRIBUTING) so agents and contributors target it.
2. Either merge playground → main, or retarget. A 288-commit gap means any main-targeted fix is guesswork about whether it is already done.
3. Require an "Affected branch" field on issues. Several issues already include it ([HIGH]bug(trade): v17 portfolio selection depends on RPC result ordering #2371, [HIGH] Close position can over-close and flip exposure when fresh position verification fails #2364) and those were unambiguous; the ones without it caused this.
4. Port [HIGH] Portfolio shared cache accepts partial v17 owner-scan results, hiding active positions and understating account value #2414 to playground — it is the one finding here still live on the active branch.

I am happy to redo #2414 against playground once someone confirms that is the right target.

[dcccrypto]

Update — two corrections, and the decision is narrower than I framed it

Correction 1: #2414 is also already fixed on playground. I claimed above it was the one finding still live there. It is not. Playground's usePortfolio.ts fails closed on a failed v17 owner scan and serves the last-good cached snapshot rather than publishing partial totals — a better fix than the isPartial flag I wrote, since it never renders understated numbers at all.

I reached the wrong conclusion by grepping playground for isPartial — the name of my solution — instead of checking whether the underlying problem was addressed. Same error class as the branch mistake, one level down. So all three of my launch PRs are redundant against playground, not two.

Correction 2: but "redundant" does not mean "worthless", because main looks like the production branch.

Vercel project        Production URL                      Last updated
percolator-launch     https://percolator.trade            10d   ← matches main's last commit (2026-07-09)
percolator-playground https://percolator-playground...    3d
percolator-mainnet    https://mainnet.percolatorlaunch.com 10d

percolator.trade is served by percolator-launch, last deployed ~2026-07-09 — i.e. from main. Playground deploys to its own preview domain. So the defects in #2416, #2414 and #2362 are live on production right now, and playground's better fixes have not shipped.

The actual decision

Not "which branch do agents target" but:

Does the next production deploy of percolator.trade come from main or from playground?

• From playground → close PRs fix(oracle-api): bound the publisher and resolver caches (GH#2416) #2437/fix(portfolio): stop publishing an incomplete scan as a complete one (GH#2414) #2438/fix(trade): submit the worst-fill bound the user actually reviewed (GH#2362) #2439; playground's implementations supersede them, and the 288-commit merge ships the fixes.
• From main → those three are worth merging, because production carries all three defects until playground ships.

Either way the branch-hygiene items in the original post still stand (declare the authoritative branch; require an "Affected branch" field on issues), because that is what caused the wasted effort.

[dcccrypto]

Resolved in practice — acting on the evidence rather than waiting further

No answer came to "which branch is authoritative", but PR routing answers it unambiguously:

PR	Base	Author	State
#2442	playground	Bayyan16	open (2026-07-19)
#2436	playground	Bayyan16	open
#2434	playground	Bayyan16	open
#2432	playground	dcccrypto	merged
#2431	playground	dcccrypto	merged
#2437/#2438/#2439	main	dcccrypto	(mine — the only base=main PRs anywhere)

Everyone else targets playground, and merges land there. main is not where work goes.

What I did

Closed #2438 and #2439. Both are redundant against playground (which fixes them, better), and both have limited impact while mainnet is dormant (#2443). Keeping them open only grew a review backlog I have repeatedly called the binding constraint. Closing is reversible — branches and history remain.

Kept #2437 open. It fixes an unauthenticated memory-exhaustion vector, and percolator.trade is serving a build from main (last production deploy ~2026-07-09), so that defect is live on the running site regardless of which branch development targets. This is the one case where the branch answer does not settle it — deployment does.

Still worth doing

The branch-hygiene asks from the original post stand, because the wasted effort was avoidable:

1. State the authoritative branch in the repo (README/CONTRIBUTING). I burned several cycles fixing main before working this out.
2. Require an "Affected branch" field on issues. The issues that had one ([HIGH]bug(trade): v17 portfolio selection depends on RPC result ordering #2371, [HIGH] Close position can over-close and flip exposure when fresh position verification fails #2364) were unambiguous; the ones without caused the confusion.
3. Decide what happens to main — it is 288 commits behind and still serving production. Either deploy playground or explicitly retire main.

Point 3 is the one that matters most: production is currently running the older branch, which is why #2437 is still live.

[Bayyan16]

Thanks for the detailed branch and deployment review.

For clarity, the five referenced issues were addressed by PRs that have already been merged into playground:

• [High] Trade confirmation can submit a different worst-fill bound than the value reviewed by the user #2362 → fix(trade): preserve reviewed worst-fill bound on submission #2363
• [HIGH] Close position can over-close and flip exposure when fresh position verification fails #2364 → fix(trade): require verified fresh position state before closing #2365
• [HIGH]bug(trade): v17 portfolio selection depends on RPC result ordering #2371 → fix(trade): select v17 portfolio deterministically #2372
• [HIGH] Portfolio shared cache accepts partial v17 owner-scan results, hiding active positions and understating account value #2414 → fix(portfolio): fail closed on v17 owner-scan errors to preserve complete snapshots #2415
• [HIGH] Unbounded Oracle API Caches Allow Persistent Memory-Exhaustion DoS #2416 → fix(oracle): prevent unbounded cache growth and cap resolver concurrency #2418

I agree that #2362, #2364, #2371, and #2414 are resolved on their affected development branch, and I do not plan to make any additional code changes for them.

Before changing the issue states, I would like to confirm the intended tracking policy:

1. Should branch-scoped issues be closed as completed once their fixes are merged into playground, even while main remains behind?
2. For [HIGH] Unbounded Oracle API Caches Allow Persistent Memory-Exhaustion DoS #2416 specifically, should it remain open until fix(oracle-api): bound the publisher and resolver caches (GH#2416) #2437 is resolved or production is deployed from the fixed playground code?

I will leave the current issue states unchanged until that distinction is confirmed, to avoid closing a production-relevant finding prematurely.