Propose and decide — the front half of the review loop
Everything we have built for reviewing work operates on changes that already exist as code. Nothing operates on a proposal before the code exists. This initiative adds that front half: propose a design, discuss it, decide — then hand off to the lane that already works.
What already exists (do not rebuild)
- Review & publish console per app hub — previews each pending change, publishes all-or-selected to production, blocks changes that cannot ship alone. Owner-gated, proven with real PRs (Terminal #15, LP Flow #120).
- Always-current dev app at
<app>-dev.rivent.devon the dev database. - Promotion model (2026-07-29) on all five operational apps:
developself-merges on green CI,mainis Shawn-only,sync-developprevents silent drift. - POST — commit + push here, live on design.rivent.dev in under a minute.
The gap
| Step | State |
|---|---|
| Propose a design | missing |
| Discuss and iterate on it | missing |
| Approve a direction | missing |
| Build it | develop lane |
| Preview the built change | Review & publish |
| Publish to production | Review & publish |
Open question — blocks the build
Where does the propose-and-decide surface live? The 2026-08-04 decision moved mockups and presentations off the portal into System Design, where POST already works and both owners already share state. But Review & publish lives on the portal's per-app hubs.
Working read: System Design for the design conversation, the portal hub for the change conversation. They are different objects — a proposal is not a pending change — and each already has a home. What is missing is a link between them: a decided proposal points at the PR that implements it, and the PR points back. That is a much smaller build than a new surface.
Needs Shawn's confirmation before anything is built.
Shape of the work, assuming that read
- Condense the top of the app hub — project info and CI detail currently crowd the page. Touches an approved mockup, so confirm first.
- A proposal carries a mockup or a plan, with comments and an approve-the-direction action distinct from approve-the-publish.
- Group activity by significance rather than a raw commit feed.
- Wire the decided-proposal ↔ PR link both ways.
- Pick up in your Claude — take a version into your own session, rework it, POST it back. This is the self-serve unlock; without it everything routes through one person.
Knobs on mockups, versions-as-whole-mockups and an abridged/full changelog are candidates once the loop is proven, not part of the first build.
Constraints that bind this
- No new infrastructure in the portal — hand-written HTML, Pages Functions, small JSON stores. No database, no framework, no build step.
- Sans-serif only, no monospace, fleet-wide.
/adminis owner-only; team features must not route through admin code.- Publishing to production stays Shawn-only. Approving a direction probably should not, or the rest of the team still cannot move — needs an explicit answer.
Out of scope
- Rebuilding previews, publish, gating or promotion. All shipped and proven.
- Any per-app copy of this surface before one real change has run end to end through it.