The Proof Desk sits at the bottom of every app's Status tab. It's where a change is proposed, seen running, discussed, and shipped to the app's dev version — in plain English, with no code and no GitHub. This page is the quickstart and the FAQ from the demo.
Everything on the Proof Desk touches the dev world only. The live apps cannot be reached from here.
Everyone on the team
<app>-dev.rivent.devBreak things here freely. That's what it's for.
Shawn only
Nothing you do on the Proof Desk can reach this side.
Reviewing needs a browser and nothing else. Proposing needs your SLW workspace.
Browser only · works today for everyone
A few minutes after Ship, the change is live on the app's dev version — with your name on the card.
Your SLW workspace · Claude Code
No magic words, no commands. Design questions get a mockup with sliders; mechanical changes go straight to a reviewable pull request on the card.
Right now the ask is: try to break it. Propose something that actually bugs you — whatever you propose really ships to dev, so the test produces real improvements. Anything confusing, type it straight into a card's comment box.
“Do I even have access?” Three separate doors, all granted by Shawn. Reviewers need only the first.
Missing a door? Ask Shawn — access is his call, and it takes him a couple of minutes.
Being in the app's folder is the reliable way — in Claude Code, pick the app's folder when you connect. But naming the app clearly in your request (“on LP Flow…”) usually gets you there from anywhere in the workspace. When in doubt: open the app's folder.
It posts a comment on the card — like a margin note in a shared doc. Everyone sees it; nothing happens automatically. Comments become instructions the next time someone asks Claude to iterate on that card (“pick up the density card and address the comments”).
Knobs appear when the question is “how much / which way” — spacing, density, layout. You explore settings in the mockup, the group approves numbers, and the real change gets built to match.
Mechanical changes (“put the deal name in the tab title”) have nothing to tune, so the card goes straight to the pull request view: changelog, checks, “See this change running”, Ship.
Previews live outside our sign-in wall, and the databases refuse to hand data to anyone unauthenticated — that's the security model working, not a bug. Use previews to judge look and behaviour; the full effect on real records shows on the app's dev version minutes after you ship.
No. Ship only ever targets the dev version, the server refuses anything aimed elsewhere, and GitHub itself blocks everyone but Shawn from production. Worst case you break the dev app — which is recoverable in minutes and genuinely fine.
The card records the person who proposed it (even though Claude does the posting) and the person who shipped it. GitHub's internal bookkeeping shows service identities — the Proof Desk card is the human record.
The Proof Desk works today for the apps on the App Board. Incubating and sandbox apps join when they're promoted onto the board — until then their builders iterate directly, which is the right speed for that stage.
Probably not. A pull request is just “here's a file change for review” — and not every file change touches an app. Publishing a mockup, for example, is a pull request that only adds an HTML sketch to the portal's mockups folder; zero app behaviour changes. Before reacting, read the PR panel on the card: it states exactly what changes and where it ships. When in doubt, ask Claude “what does this PR actually change?”
Shared — one dev version per app, for the whole team. When anyone ships, everyone sees it a few minutes later (writing, checks and deploy take ~5–10 minutes, so it's not literally live-typing). That's the point: everyone proposes on cards in parallel, the dev app accumulates the shipped results, and Shawn publishes batches to live.
One card = one coherent change (“redesign the research pane”, “fix the header wrapping”). Don't pile 50 unrelated edits into one — if something breaks, nobody can tell which of the 50 did it. Iterating within a card is fine and encouraged: keep telling Claude to adjust, versions stack up on the same card, and the PR updates until you ship.
Worked on something big across a long chat? Ask Claude: “distill this conversation into working requirements and put them on the Proof Desk” — it'll split things sensibly.
Michael, or just type it into the card's comment box. If it's an access problem (“you don't have access to this project”), that's Shawn.
The card “How dense should deal rows be?” on LP Flow's Proof Desk is live now — sliders and all. Drag things. Leave a comment. That's the whole system in one card.