Human overview · for understanding

Delivery board: merged, audited, live

Both apps rejoined into one version, a real security hole closed, and the mystery of the missing client data solved · 2026-07-05

Both apps rejoined into one version, a real security hole closed, and the mystery of the missing client data solved

Master summary — the gist in 30 seconds

TL;DREverything from the delivery-board build is now merged, security-checked, pushed, and live — and a genuine security bug in Studio got closed before it could hurt anyone.

Input: two half-finished repos (pipeline + Studio) with a new feature sitting unmerged, plus a pile of stopped Modal apps from an earlier cleanup. Output: one branch, one push, one live deploy per app — and 5 real bugs (1 security, rest correctness) found and fixed along the way.

Why this mattersThis was the moment where 'it works in testing' either becomes 'it's safe in production' or quietly doesn't. Running a second, independent review after the build — instead of just shipping the QA'd feature — is what caught the one bug that actually mattered: a way to move a real deal forward without a real client action.
flowchart LR
 B["Delivery-board<br/>feature built"] --> M["Merge everything<br/>onto one branch"]
 M --> A["Independent audit<br/>(4 fresh reviewers)"]
 A --> F["Fix what's real"]
 F --> P["Push + deploy"]
 P --> L["Live, both apps"]

1 · Merging two sessions' work into one version

TL;DRA concurrent session's purge fixes and this session's delivery-board build got folded into a single `main`, with nothing left half-finished.

Input: the delivery-board build (already tested live) sitting on its own branch, plus a separate session's purge/cleanup fixes on another branch, plus scattered temp working folders. Output: one `main` branch, one working folder per repo, everything pushed to GitHub.

Why it mattersYou said it plainly: you don't want to think about which branch or which folder has the real version. Every temp folder from this build got cleaned up, and the two sessions' changes were combined without losing either one — that's what 'one synchronized version' actually looks like in practice, not just in principle.
flowchart TD
 S1["Session A:<br/>purge/deallock fixes"] --> Merge
 S2["Session B:<br/>delivery-board build"] --> Merge
 Merge["Combined onto main"] --> One["One branch,<br/>one folder,<br/>pushed to GitHub"]

2 · The security hole: a link that shouldn't approve anything, could

TL;DRAn internal preview link — meant only for you or your team to look at a project — could, if opened without being logged in, actually approve the design or submit client feedback on the client's behalf.

Input: Studio hands out different kinds of links — one for the real client, one for internal preview, one for a sales demo. Output before the fix: all three were treated the same way if nobody was logged in as staff, so the internal preview link had the same power as the real client link. Output after the fix: only the genuine client link can trigger those actions.

Why it mattersThis one matters because it's invisible until it's exploited: forward a preview link to a colleague, they open it without logging in, and the system reads that as 'the client approved the design' — moving a real deal forward on the pipeline board with nobody having actually approved anything. Closing it now means a future forwarded link can't quietly cost you a mis-tracked deal.
flowchart LR
 L1["Client link"] -->|should approve| OK["Approve /<br/>Submit feedback"]
 L2["Internal preview link<br/>(no login)"] -.->|used to also work| OK
 L2 -->|now blocked| X["Rejected"]
 L3["Sales-demo link"] -->|now blocked| X

3 · Four smaller correctness bugs, caught before they bit

TL;DRA forged webhook could have triggered a real payment email; a stale sync could have dragged a finished project backward; and two labels quietly disagreed with each other.

Input: the delivery-board code as built and tested. Output: a webhook now requires a real signature (like your other integrations already do), a finished/parked deal can no longer be yanked backward by a stale status check, two aliased stage names no longer block each other, and the board's column labels now match its filter dropdown everywhere.

Why it mattersNone of these had bitten yet — that's exactly why an independent second look is worth doing even after something is 'tested and working.' The webhook one in particular is the kind of gap that sits quiet for months and then triggers a real client email at the worst possible time.
flowchart TD
 W["Unsigned webhook"] -->|forgeable| Pay["Auto payment email"]
 W -->|fixed: signature required| Blocked1["Rejected"]
 Sync["Stale status sync"] -->|used to force backward| Regress["Finished deal moved back"]
 Sync -->|fixed: skip if already delivered| Blocked2["Left alone"]

4 · Solving the mystery of the missing client data

TL;DRThe Studio app everyone assumed was 'the real one' turned out to be nearly empty — the actual client projects were living somewhere else the whole time.

Input: five different Studio app copies, one long believed to be the true live one. Output: opened each one's actual database and counted real client projects — found 31 real projects (Matyi Mátyás, Labs Skyrocket, and others) sitting in the copy nobody thought was the real one, while the assumed-real copy had almost nothing in it. That copy is now the one true deploy target.

Why it mattersThis is exactly the kind of mix-up that causes real damage later: redeploy to the 'obviously correct' name, and you'd have quietly served an empty app to real clients while their actual project history sat untouched somewhere else. Checking the data itself — not the name — is what caught it in time.
pie showData
 title Real client projects, by app copy
 "studio-rebuild (the real one)" : 22
 "studio-prod (assumed real)" : 0
 "studio-v31 (assumed real)" : 0
 "studio-review" : 0

5 · Where things stand now

TL;DRBoth apps are live on the fixed code, both repos are pushed, nothing temporary is left lying around.

Input: the fixes above. Output: pipeline + booking redeployed and confirmed live; Studio redeployed to the copy that actually holds your client data; one open follow-up remains — repopulating the live board's existing deals into the new 6-column layout, which is a separate task nobody has done yet.

Why it mattersThe one thing still open (board repopulation) is a deliberate, separate step — not an oversight. Everything that was 'build it, check it, ship it' is now done and verifiable live.
flowchart LR
 Fixed["Fixes committed"] --> Push["Pushed to GitHub"] --> Deploy["Deployed live"] --> Open["1 follow-up open:<br/>board repopulation"]
Pipeline CHANGELOG entry →Studio CHANGELOG entry →Delivery-board handoff doc →