Audit + mockup · the feature process, start to finish

From dev-call idea to live, in one lane

You asked whether the 6-step, deliverable-heavy process is too complicated. Three experts said yes - and that it enforces nothing. Here's the leaner version, traced full circle: the moment someone says “fix the settings page” on a call, through kickoff, all the way to shipped.

✎ Mockup only · nothing changed in the v1 or v2 prototypes
⚖️ The audit team agreed

Too much ceremony - and it enforces nothing. The advance logic never once checks a deliverable, so the 14 hand-attached artifacts are decorative: a coder taps “done” and sails through with 0 of 3 attached, forever. The board's own seed data proves the team already ignores it - 12 of 13 features have an empty deliverable ledger, and work jams at exactly the two steps GitHub can't auto-push. Their fix is unanimous: the real feature process is a few taps; everything else is the GitHub work the team already does.

The whole circle, one glance

Seven stops from idea to live. The team only touches four of them - the red ones. The two blue steps move themselves the second a PR opens and merges.

+ Add task
Kickoff
3 fields
→
1
Scope &
Prototype
Owner
→
2
Review
Seth
→
3
Build
⚡ auto
→
4
Test &
Merge
⚡ auto
→
5
Go Live
Confirm
→
✓ Live
Shipped
Done
Someone taps (4 touches total) Moves itself off GitHub Live for the client
Kickoff · how it starts

Real example from today's call: “someone needs to fix the settings and role pages in Company Settings.” You open Quick Add and fill three fields - a line, who owns it, and the category. That's the entire ask. Nothing else is required to get a task moving.

Add a task
✕
Fix the Settings & Role pages in Company Settings
MJMJ ▼
Platform ▼
+ Add detail
✨ Suggest details
Add task
Three fields and you're moving. Assign to can be “Unassigned” if you truly don't know yet, but the point is to name an owner on the spot. Due date, prototype link, and notes all come later in the Edit panel that already exists - not up front.
⤓ Tap “Add task” and it lands on the board:
PLATFORMSTEP 1 · SCOPE & PROTOTYPE
#311 · Fix the Settings & Role pages in Company Settings
MJowned by MJ 👤 MJ's turn
From here it's on rails: MJ builds a quick prototype and hands it to Seth. The five steps above carry it the rest of the way - no second setup form, no re-typing what the task is.
Managing the category list

The six categories are your existing board groupings - mostly they never change. But deliverables shift: a new workstream shows up, or one wraps and should stop cluttering the dropdown. Same control as PM Documents' folders: a ✎ Manage button flips the list into edit mode with an on/off switch, a rename pencil, and Add. Turn a category off and it leaves the Quick Add dropdown but stays on every task already tagged with it - nothing is lost, so you “close out” instead of delete.

Categories6 active · 1 off✓ Done
PlatformBuilt-in
Time & BillingBuilt-in
Multi-tenant + AgentsBuilt-in
RoadmapBuilt-in
InframarkBuilt-in
IntegrationsAdded by you
Turned offstill on their tasks, just hidden from new ones
React MigrationBuilt-in
v2→v3 wrapping · 3 tagged tasks keep it
New category name…
Add
Built-in categories can be turned off but not renamed or deleted - your tasks depend on them. Categories you add can be renamed, turned off, or removed. Off is reversible: flip the switch back on and it returns to the dropdown.
The five steps · whose turn · what makes it advance
#StepWhose courtDone whenHow it advances
0Kickoff (Quick Add)Whoever heard itA line + owner + category are in1 tap: Add task
1Scope & PrototypeOwnerPrototype link pasted in the issue, Seth tagged1 tap: hand to Seth
2ReviewSethSeth approves the prototype (or requests changes → bounces back)1 tap: approve
3BuildOwnerThe PR is opened⚡ auto · PR opened
4Test & MergeAlan → SethAlan tests in the PR, fixes land in it, Seth merges⚡ auto · PR merged
5Go LiveSeth → OwnerDeployed, and someone loaded the production URL1 confirm

Four human touches across the whole life of a feature: Add task → hand to Seth → Seth approves → confirm live. Steps 3 and 4 advance themselves on PR-open and PR-merge. Bug-test + QAQC were the same check done twice (and QAQC handed back to the owner to grade their own homework) - merged into one Test & Merge step owned by the tester. Go Live stays its own step because “merged” is not “live for the client” - that matters for Inframark.

Inside a step: what a coder sees now vs. simpler
NOW14 hand-attached deliverables≈ 0 filled in practice
Tenant isolation + agent console plans #305
owned by Jon · SCOPE & PROTOTYPE
Scope & Prototype
Jon · 0/3
Review
Seth
Build
⚡ auto
Bug-test
⚡ auto
QAQC
Jon
Go Live
⚡ auto
Deliverables 0 of 3 in
Scoped GitHub issue🔗 Attach link
Clickable prototype🔗 Attach link
Shareable link🔗 Attach link
⚠️ …and 11 more attach / upload / sign-off actions across the next 5 steps. Nothing blocks advancing, so they never get filled.
SIMPLER1 artifact, the rest from GitHubwhose-turn stays true on its own
Tenant isolation + agent console plans #305
owned by Jon · REVIEW
Scope & Prototype
✓ done
Review
Seth
Build
⚡ auto
Test & Merge
⚡ auto
Go Live
Seth
Whose turn · step 2 of 5
SE
Seth’s turn
What to do: open the prototype, then one tap.
✓ Approve & hand to Build↶ Request changes
Pulled from GitHub · nothing to attach
Issue#305 · the card is the issueauto
Prototyperc-crm-proto.pages.dev · from the issueauto
PR / mergeappears when Jon opens the PRauto
🔥 The coder's whole job = paste one prototype link, open a PR, confirm it's live. Seth's is one approval. Build and Test & Merge advance themselves - the work the team already does.
What survives · what goes

✓ Keep (3, the only real human artifacts)

  • •Clickable prototype link - the one thing that stops “built the wrong thing.” One paste.
  • •Prototype approved - Seth's one tap (a label / ✅, in the tool he's already in).
  • •Verified live - the “I loaded it in prod” confirm. Your Always-Works gate.

✗ Cut (11) - GitHub knows them, or they're duplicates

  • •Scoped GitHub issue the card is the issue · Shareable link dupe of the prototype
  • •Pull request · Merge commit · Production URL - auto from GitHub / the deploy
  • •Feedback addressed · Seth sign-off - that’s just Seth’s Approve tap
  • •Built on local6161 a localhost URL nobody can open · Prototype parity self-attested
  • •Bug-test notes · QAQC report - the two file-uploads nobody does; live in PR comments
The one thing that makes it stick
💡 The through-line all three landed on

Make the board event-driven, not deliverable-driven. Status should be a pure function of GitHub events - issue opened, PR opened, PR merged, deployed - not a manual dropdown a stray click can falsify. When “following the process” and “doing your normal GitHub work plus a couple of ✅s” become the same physical act, a disorganized team follows it every time - because there’s nothing extra left to skip.

RippleCore Dev · process audit + kickoff mockup · align here, then wire into v2