Test 199

Review is done. Notes below. June 13 Mercury activation / onboarding review — Morgan notes Attendees: Morgan Chen, Priya, Marcus, Jake - Priya walked the activation and onboarding frames in Figma and kept anchoring on the file as the source of truth for flow decisions. - Marcus said the problem is that ready in Figma has been reading as safe to ship even when release-risk items are still open. - Concrete examples raised in room: - stuck credential / retry handling on first source connection - org-invite dead-end risk on the current auth branch - admin fallback / visibility concerns before the deeper admin path exists - Priya’s point: those issues can require follow-up work or even a design change, but they should not be litigated as open-ended design vetoes in comment threads after the core flow decision has already been made. - Marcus’s point: if implementation risk has nowhere explicit to live, it spills into Figma comments or Discord because that is where people are already looking. - Both acknowledged they have been half-routing around each other in Discord instead of resolving in one place. - Decision made in room: - design calls for Mercury activation / onboarding stay with Priya - canonical place for those decisions is Figma - release-readiness and dogfood gating stay with Marcus - canonical place for those concerns is the implementation checklist and release review, not Figma comment threads - if a checklist item requires a design change, link back to the exact Figma frame and reopen only that decision - stop adjudicating this in Discord side threads - Not magically fixed: - Priya still feels implementation concerns keep arriving as late redesign - Marcus still feels risk gets labeled implementation detail too early - tone improved once the split was explicit, but still tense - Cleanup from this meeting: - Priya keeps design decision notes in Figma - Marcus sends a cleaned implementation checklist with owners and blockers for the dogfood build - any Discord thread on this topic should point back to either the frame or the checklist instead of becoming a third system Save this as the explicit decision path and post a short note to the Mercury team: design calls stay with Priya in Figma; release-readiness concerns stay with Marcus and the implementation checklist. Don’t make it sound like the interpersonal friction is magically solved.

Review is done. Notes below. June 13 Mercury activation / onboarding review — Morgan notes Attendees: Morgan Chen, Priya, Marcus, Jake - Priya walked the activation and onboarding frames in Figma and kept anchoring on the file as the source of truth for flow decisions. - Marcus said the problem is that ready in Figma has been reading as safe to ship even when release-risk items are still open. - Concrete examples raised in room: - stuck credential / retry handling on first source connection - org-invite dead-end risk on the current auth branch - admin fallback / visibility concerns before the deeper admin path exists - Priya’s point: those issues can require follow-up work or even a design change, but they should not be litigated as open-ended design vetoes in comment threads after the core flow decision has already been made. - Marcus’s point: if implementation risk has nowhere explicit to live, it spills into Figma comments or Discord because that is where people are already looking. - Both acknowledged they have been half-routing around each other in Discord instead of resolving in one place. - Decision made in room: - design calls for Mercury activation / onboarding stay with Priya - canonical place for those decisions is Figma - release-readiness and dogfood gating stay with Marcus - canonical place for those concerns is the implementation checklist and release review, not Figma comment threads - if a checklist item requires a design change, link back to the exact Figma frame and reopen only that decision - stop adjudicating this in Discord side threads - Not magically fixed: - Priya still feels implementation concerns keep arriving as late redesign - Marcus still feels risk gets labeled implementation detail too early - tone improved once the split was explicit, but still tense - Cleanup from this meeting: - Priya keeps design decision notes in Figma - Marcus sends a cleaned implementation checklist with owners and blockers for the dogfood build - any Discord thread on this topic should point back to either the frame or the checklist instead of becoming a third system Save this as the explicit decision path and post a short note to the Mercury team: design calls stay with Priya in Figma; release-readiness concerns stay with Marcus and the implementation checklist. Don’t make it sound like the interpersonal friction is magically solved.

Review is done. Notes below. June 13 Mercury activation / onboarding review — Morgan notes Attendees: Morgan Chen, Priya, Marcus, Jake - Priya walked the activation and onboarding frames in Figma and kept anchoring on the file as the source of truth for flow decisions. - Marcus said the problem is that ready in Figma has been reading as safe to ship even when release-risk items are still open. - Concrete examples raised in room: - stuck credential / retry handling on first source connection - org-invite dead-end risk on the current auth branch - admin fallback / visibility concerns before the deeper admin path exists - Priya’s point: those issues can require follow-up work or even a design change, but they should not be litigated as open-ended design vetoes in comment threads after the core flow decision has already been made. - Marcus’s point: if implementation risk has nowhere explicit to live, it spills into Figma comments or Discord because that is where people are already looking. - Both acknowledged they have been half-routing around each other in Discord instead of resolving in one place. - Decision made in room: - design calls for Mercury activation / onboarding stay with Priya - canonical place for those decisions is Figma - release-readiness and dogfood gating stay with Marcus - canonical place for those concerns is the implementation checklist and release review, not Figma comment threads - if a checklist item requires a design change, link back to the exact Figma frame and reopen only that decision - stop adjudicating this in Discord side threads - Not magically fixed: - Priya still feels implementation concerns keep arriving as late redesign - Marcus still feels risk gets labeled implementation detail too early - tone improved once the split was explicit, but still tense - Cleanup from this meeting: - Priya keeps design decision notes in Figma - Marcus sends a cleaned implementation checklist with owners and blockers for the dogfood build - any Discord thread on this topic should point back to either the frame or the checklist instead of becoming a third system Save this as the explicit decision path and post a short note to the Mercury team: design calls stay with Priya in Figma; release-readiness concerns stay with Marcus and the implementation checklist. Don’t make it sound like the interpersonal friction is magically solved.