Morgan Chen

Jake posted the Mercury weekly. [Discord — #eng-team] Jake Mercury weekly — Jun 5 Owners / moving pieces for this week - Feature-flag cleanup: Marcus. Goal is to collapse stale rollout flags and remove dead toggles before Jun 8 so QA is not testing three different paths. - Activation dashboard drift: Anna Martinez. She owns reconciling the dashboard against the corrected activation mapping and will post an internal-only diff once the numbers stop moving. - Onboarding-copy QA: Priya. She is running the Mercury activation/onboarding pass; this week’s scope is empty states, source-connect prompts, and first-live-sync copy. Launch blockers that need decisions this week 1. Historical activation backfill vs hard annotation line on the chart. - Backfill keeps the internal trend cleaner but costs Anna time and moves the numbers again. - Annotated break is faster and honest, but the dashboard will show a visible discontinuity from the May 24 correction. 2. Rollout shape for the onboarding changes. - Single launch flag is the fastest path. - Tenant-by-tenant allowlist is safer, but it keeps the QA matrix ugly and slows launch. Please keep the activation dashboard work in the internal operating lane for now. Status updates in thread by end of day Jun 6. Create an internal operating note for this week with the decisions, owners, and unresolved blockers. Keep it as working material for the team, not investor-facing language.

Please send Priya a short private Discord note confirming the activation/onboarding QA path from the weekly — empty states, source-connect prompts, and first-live-sync copy. Keep it normal-work tone, not a promotion announcement.

Anna sent the weekly activation pull. Discord DM — Anna Martinez → Morgan Chen Mon, Jun 5, 2023, 9:14 AM Here’s the raw Mercury activation pull from Looker after the definition correction. Internal directional pass only. Definition on this cut: - activated_7d = real_source_connected OR first_live_sync_completed within 7 days of signup - sample_import_completed is excluded from activation - invite_sent is supporting activity only - week of 2023-05-29 omitted because the 7-day window is still open ```csv signup_week,signups,invite_sent_7d,sample_import_completed_7d,real_source_connected_7d,first_live_sync_completed_7d,activated_7d,invite_sent_no_activation_7d 2023-04-24,18,15,10,8,7,9,5 2023-05-01,20,17,11,9,8,10,5 2023-05-08,21,19,12,10,8,11,6 2023-05-15,19,17,11,8,7,9,6 2023-05-22,23,20,13,10,9,12,6 ``` A few of the misses / edge cases, since the pattern is mostly “invite happened, but real source didn’t land inside 7d” rather than “nobody touched setup”: ```csv account_id,signup_date,connector,invite_sent_at,sample_import_completed_at,real_source_connected_at,first_live_sync_completed_at,activated_7d,notes mrc_4581,2023-05-01,salesforce,2023-05-01 11:42,,2023-05-10 09:15,,false,invite sent; source connected on day 9 mrc_4610,2023-05-03,hubspot,2023-05-03 14:08,2023-05-03 14:19,,,false,invite + sample import only mrc_4722,2023-05-11,salesforce,2023-05-11 16:02,2023-05-11 16:11,,2023-05-19 10:48,false,live sync landed on day 8 so still misses corrected window mrc_4797,2023-05-17,hubspot,2023-05-17 12:22,,,,false,invite only; no downstream event by day 7 mrc_4829,2023-05-20,bigquery,2023-05-20 10:11,,,2023-05-25 09:42,true,counted activated; live sync in-window, source event missing on old connector path mrc_4850,2023-05-22,netsuite,2023-05-22 15:06,2023-05-22 15:14,2023-05-31 10:03,,false,source connected on day 9 mrc_4874,2023-05-24,salesforce,2023-05-24 13:17,,,,false,invite sent; stalled before connection mrc_4891,2023-05-25,postgres,2023-05-25 09:51,,,2023-05-30 08:44,true,counted activated via first live sync; source event missing ``` Biggest thing that jumps out to me: invite rate is fine, and sample-import activity is not terrible, but the handoff into a real source inside 7 days is still where we bleed. There are also 1–2 rows/week where live sync exists but the source-connected event is absent, so Devon and I still need to decide whether that is old-path instrumentation residue or a separate mapping bug. Pull out three operating questions for Anna and Devon. Keep it internal — no board wording, no external framing, no slide language.

Rishi has the Pinecone blocker narrowed down. Discord DM — Rishi → Morgan Chen Mon, Jun 5, 2023, 11:02 AM Pinecone blocker: integration tests are ready on our side except they still haven’t answered the auth-header question in the thread with integrations@pinecone-test.com. Concrete thing I need from them: - whether their test env expects only `Authorization: Bearer <token>` - or whether they want `Api-Key: <token>` on that same endpoint I’m fine coding to either one, I just don’t want to burn another day on local stubs against the wrong behavior. That answer is the unblock. Please send a short follow-up in the existing Pinecone integration thread to integrations@pinecone-test.com, keeping Sarah in the normal cc path. Ask only for the concrete auth-header answer that unblocks Rishi.

Mom checked in. SMS — Mom → Morgan Chen Mon, Jun 5, 2023, 7:06 PM Hi sweetheart — has work calmed down at all or is it still so busy? Is the new Oakland apartment starting to feel settled? And is Kibo behaving himself over there? Love you. Draft me a short SMS I can send myself. Reassure her, keep it to apartment/Kibo-level updates, and don’t get into late nights or stress.

This activation review invite is too thin. From: Priya <priya@atlas-test.com> To: Morgan Chen <morgan@atlas-test.com> Date: Tue, Jun 6, 2023 at 8:42 AM Subject: Fwd: Mercury activation review Forwarding the hold. ---------- Forwarded message ---------- From: Calendar <calendar-notify@atlas-test.com> Date: Tue, Jun 6, 2023 at 8:39 AM Subject: Invitation: Mercury activation review To: Morgan Chen <morgan@atlas-test.com> Mercury activation review When: Wednesday, Jun 7, 2023 · 2:00 PM – 2:30 PM Pacific Time Guests: Morgan Chen, Priya, Jake, Marcus, Anna Martinez Organizer: Priya Description: Walk through latest activation flow. Attachments / links: None Before I accept it, send Priya a private note asking for the missing review materials: the Figma link and a short context note on what we’re deciding / who is walking through what.

Marcus asked the release-notes routing question. Discord DM — Marcus → Morgan Chen Tue, Jun 6, 2023, 10:58 AM Quick release-notes routing question: the feature-flag rollout still isn’t green, but I have the draft notes ready. Can I put them somewhere broader now so support sees them early, or should they stay in #eng-releases until the deploy is green? Send him a concise private team-chat reply: until the deploy is green, the draft notes stay in #eng-releases. Not #eng-all pre-green.

Devon wants one last health skim before the Mercury readiness conversation. Discord DM — Devon Hayes to Morgan Chen 2023-06-06 09:18 PT Devon Hayes: Before the Mercury readiness convo, can you do one last 30-day health skim across the usual eight services? Please use the batched pull this time — I do not want to trip the old rate limit again. I only need the top line: anything red, anything noisy enough to matter, and anything that actually changed versus normal background churn. No per-service wall of text. Please run the usual eight-service sweep as a batched pull and give me the compact status only: anything red, anything noisy enough to matter, and anything that actually changed versus normal churn. No per-service dump.

Greg pushed again on NDA examples. Email thread Subject: Re: NDA scope From: Greg Shipman <greg@acme-test.com> To: Morgan Chen <morgan@atlas-test.com> Cc: Sarah Kim <sarah@atlas-test.com> Date: Tue, Jun 6, 2023 at 8:42 AM PDT Morgan — I understand that is Scaffold's position, but it is still too abstract for us to evaluate on our side. Please identify the exact materials Scaffold believes are outside the NDA so we can deal with the actual set in question rather than the general principle. If there are only a handful, I do not see why we need to take this live again. We should be able to resolve it over email if you can list them specifically. Greg --- From: Morgan Chen <morgan@atlas-test.com> To: Greg Shipman <greg@acme-test.com> Cc: Sarah Kim <sarah@atlas-test.com> Date: Mon, Jun 5, 2023 at 4:18 PM PDT Subject: Re: NDA scope Greg — Scaffold disagrees that the materials Acme is pointing to fall within the NDA's confidentiality scope as drafted. All other rights are preserved. Morgan Chen · Scaffold Reply in the existing thread to Greg, keeping Sarah on cc. Keep it narrow: Scaffold’s position from Monday stands, we’re not going to itemize examples in writing, and all rights are preserved.

Rishi posted the first auth v0.2 readout. Discord — #eng-team 2023-06-07 08:14 PT Rishi Patel Mercury auth v0.2 readout prep Spent time in the sandbox on the two hosted paths we keep circling for Mercury auth. Not trying to re-open custom auth; this is just the practical readout on where Clerk is clean, where Auth0 is cleaner, and what still feels unresolved before we talk live. - Sessions - Clerk: fastest path to a working session flow. I had middleware + server check working quickly, and the happy path feels boring in a good way. - Auth0: also works, but it took more setup to get to the same place. More knobs if we end up needing unusual policy or tenant-specific behavior. - Still unproven: session refresh after invite accept or org change. - Magic links - Clerk: easiest end-to-end flow so far. New user + return user behavior was straightforward in the sandbox. - Auth0 passwordless: workable, but redirect/state handling was fussier and I hit more did-we-just-lose-the-return-path moments. - Need one more pass on link reuse and expiry behavior so support is not guessing on day one. - Organization invites - Clerk's org model maps pretty well to the basic team-invite flow we want. - Main edge case: invited person already has a personal workspace, then accepts into a team workspace. That handoff is not fully burned down. - Auth0 can do it, but we would own more of the invite and membership stitching ourselves. - SSO / admin gaps - This is still the squishiest area. - If Mercury launch only needs normal session auth + invites, Clerk remains the simpler path. - If we need deeper admin controls, domain or IdP management, or more enterprise-ish SSO behavior earlier than planned, Auth0 still looks stronger there. - Pricing caveats - Clerk is better on speed right now. - I still do not have a satisfying pricing view if usage ramps fast and we end up with a large MAU footprint on top of org features. - Auth0 is less pleasant on implementation time, but the enterprise/contract shape may be less surprising later. - Staging / deploy note - If anyone wants to validate either path on staging, please use the standard pipeline. - No one-off shortcut for staging auth testing. I do not want to learn the wrong lesson from a path we would not actually ship. Happy to turn this into a short walkthrough once people have skimmed. Create an internal pre-read doc for Thursday with the questions and non-decisions. I want scope risks and deploy-discipline checks called out, not a final provider recommendation.

Priya sent the actual Figma comment export for the review. Figma comment export File: Mercury / Activation flow v17 Exported by: Priya Export time: 2023-06-07 09:06 PT 1. Comment C-214 Frame: 01 — Empty state / first visit Status: Resolved Author: Priya Time: 2023-06-06 15:48 PT Comment: The hierarchy is still doing too much at once. Connect a source should be the clear primary action. Invite teammate can stay visible, but not as a second primary on first visit. Replies: - Marcus — 2023-06-06 16:02 PT: Fine by me as long as the secondary action does not imply it is launch-critical. - Priya — 2023-06-06 16:09 PT: Yep, this is about focus, not hiding it forever. 2. Comment C-219 Frame: 03 — Source connect / provider chooser Status: Open Author: Marcus Time: 2023-06-06 16:14 PT Comment: We still do not have ready error states for provider timeout, expired magic link, or permission denied after the OAuth bounce. I do not think this frame is implementation-ready until those exist, even if the happy path is stable. Replies: - Priya — 2023-06-06 16:28 PT: Agreed the states need to exist. I had them as a separate pass because the main review here was path + hierarchy. - Marcus — 2023-06-06 16:34 PT: Works for sequencing, but engineering will need the actual states before build handoff. 3. Comment C-223 Frame: 01 — Empty state / first visit Status: Open Author: Priya Time: 2023-06-06 16:41 PT Comment: @Morgan Chen Do we want the promise in the headline to be Connect your first source or Get your first live sync? The first is simpler and more literal for step one. The second matches activation better, but it is a bigger promise if sync completion slips. 4. Comment C-227 Frame: 04 — Connecting / loading state Status: Resolved Author: Marcus Time: 2023-06-06 16:55 PT Comment: Need a defined button lock + spinner state here so users cannot double-submit while the connector handoff is in flight. Replies: - Priya — 2023-06-06 17:03 PT: Added a loading variant and disabled CTA treatment in the component set. - Marcus — 2023-06-06 17:10 PT: Saw it. Resolved. 5. Comment C-231 Frame: 03 — Source connect / provider chooser Status: Open Author: Marcus Time: 2023-06-06 17:18 PT Comment: @Morgan Chen Should Skip for now exist on this step for Mercury launch? It helps if support needs a manual recovery path, but it also creates a half-activated state we do not currently surface well in ops or reporting. 6. Comment C-236 Frame: 02 — Empty state / supporting copy Status: Resolved Author: Priya Time: 2023-06-06 17:31 PT Comment: Secondary copy is competing with the checklist. I am trimming it down so the page does not read like setup docs before the user has even started. Replies: - Marcus — 2023-06-06 17:40 PT: Shorter is better here. 7. Comment C-241 Frame: 06 — Invite teammate Status: Open Author: Priya Time: 2023-06-06 18:02 PT Comment: @Morgan Chen Is teammate invite in scope for launch-day activation, or is it explicitly post-activation? I can keep the affordance visible but secondary, or move it fully after first live sync. I do not want the UI implying that invite completion is part of the initial success definition if we are not going to measure it that way. Replies: - Marcus — 2023-06-06 18:11 PT: If it stays on the page, engineering needs the empty, no-admin, and invite-failed states at handoff. 8. Comment C-244 Frame: 05 — Permission denied / recovery Status: Open Author: Marcus Time: 2023-06-06 18:19 PT Comment: For the recovery path, do we want retry-in-place, back-to-provider-list, or a support CTA? This is less about visuals and more about whether the design is claiming a recovery path we can actually support in the first cut. Replies: - Priya — 2023-06-06 18:33 PT: I can mock all three, but I would rather not imply self-serve recovery if we know ops will still need to intervene on some connectors. Give me a neutral read on which comments are product decisions I need to make versus implementation-readiness concerns. Don’t adjudicate the Priya/Marcus tension — just separate the work.

The auth readout needs a short Thursday morning slot with Jake and Rishi. Please route the scheduling request through Priya / the usual calendar path, not a direct ping to Jake from me. Ask for 30 minutes if there’s an opening.

Devon is asking whether the auth readout changes the narrative. Discord DM — Devon Hayes to Morgan Chen 2023-06-07 11:07 PT Devon Hayes: If the auth readout is clean, do we use it in the board/investor story, or is that premature? Not saying we need to deck it up immediately — just asking whether it becomes part of the narrative once the room feels good about it, or whether it stays operating detail for now. Draft a short answer I can send back: even if the room feels good about it, this stays an operating input for Mercury for now, not board or investor deck material.

Priya found the slot. [Discord reply — Priya] Thursday 10:30–11:00am PT is clear for Jake. I checked with Rishi too and he can make that slot. Create the calendar event for Thursday, June 8, 2023 from 10:30-11:00am PT titled `Mercury auth v0.2 readout`. Invite me, Jake, and Rishi.

Auth readout notes are here. Mercury auth readout — Thu Jun 8 Attendees: Morgan, Jake, Rishi Notes - Rishi demoed the Clerk sandbox session path end to end. Happy path worked in the sandbox. - He also walked the magic-link path. That path is working at demo level too. - Org-invite behavior still has edge cases. The existing-user vs new-user accept flow is not clean yet, and the landing/org-context behavior after accept still needs work. - SSO/admin depth is still unresolved. We do not have a clean answer yet on how much admin surface we would still need to build around the provider. - No provider call out of this readout. Clerk has the faster sandbox path right now, but the invite + SSO/admin questions are still real. - Marcus raised a release-process concern: auth is exactly the kind of area where someone will be tempted to shortcut staging, and that is a bad idea here. - Standard staging pipeline only. No shortcut path for this. - Before any prod conversation, need a clean staging pass on session path, magic link, and org invites. Update the pre-read into an internal open-questions note for Friday’s decision window. Leave the provider baseline and deploy/prod call unsettled; this should capture what needs to be answered, including the staging discipline checks.

Please post a process comment on PR-1192. Remind the team to use the standard pipeline, keep release notes in #eng-releases until the deploy is green, and not move anything to #eng-all pre-green. Also say any late-Friday production push needs my explicit exception.

Dumping rough notes for tomorrow’s wrap before I lose the thread. rough notes for June 9 wrap - team: Mercury weekly owners are clearer now. less drift on who owns what. - team: activation cut is still directional/internal only. - team/product: Priya’s activation QA is moving quietly and in the right direction. - external: Pinecone nudge sent; still waiting on a test slot. - legal/ops: Acme NDA is still live, but no decision point yet. - auth: today’s readout surfaced open questions. don’t frame it like we made the provider or deploy call. Turn this into a recording outline that says what actually moved this week. Don’t turn the auth prep into a decision, and don’t use internal activation cuts as external proof.

Rishi has a Pinecone update. [Discord DM — Rishi] Just got off with Pinecone. They can do a test window Tuesday morning. They also asked whether we want to send the headers in advance. Can the reply just reserve the slot and say we’ll follow with the technical handoff separately? I’d rather not put header detail in Morgan’s note. Reply in the existing Pinecone integration thread accepting the Tuesday morning test window. Say Scaffold will follow with the technical handoff separately, and don’t include header details in my note.

Rishi just posted this in the engineering thread: #eng-team — Friday, June 9, 2023 Thread: Mercury auth v0.2 baseline [10:14 AM] Rishi: @Morgan Chen @Jake got the Clerk-backed Mercury auth pass to a place I'd call green on internal staging for the next dogfood build. What is green right now: - session create + refresh through normal app navigation - magic-link login end to end, including resend and expired-link handling - org-invite accept + revoke from the current inviter flow What is explicitly not in v0.2: - SSO - deeper admin/org settings and role-management work - enterprise shortcuts around the current invite path Smoke test table from the staging pass: | Flow | Result | Notes for next dogfood build | | --- | --- | --- | | Email magic-link request | Green | Link delivered and redeemed from a fresh browser session | | Expired magic link | Green | Re-request path works instead of dead-ending | | Session persistence | Green | Refresh and close/reopen kept the session valid on internal staging | | Logout and re-login | Green | No stale session artifacts after logout | | Org invite accept | Green | New user lands in the invited org correctly | | Org invite revoke | Green | Revoked invite no longer resolves; rejection copy is still rough | | Org context after first accept | Green | Session stayed attached to the correct org after invite acceptance | | SSO entry | Out of scope | Not wired for v0.2 | | Admin org settings / deeper controls | Out of scope | Separate follow-up branch; not part of this baseline call | If nobody sees an in-scope blocker here, I'd treat this as baseline-ready for the next internal dogfood build. Please save a short internal baseline note and post the decision back to #eng-team: Clerk is the Mercury v0.2 baseline for sessions, magic links, and org invites. SSO and deeper admin controls stay out of this scope.

Updated raw notes for today’s wrap are below. - Team — Mercury auth v0.2 baseline is Clerk for sessions, magic links, and org invites; dogfood next. Keep SSO/admin-later out of this update. - Customers — only product movement + blockers: dogfood criteria tightening, no new promise, no date pull-in. - Investors — do not reopen auth-provider debate; Mercury proof first. - Legal/ops — no decision today, so probably skip. - Release discipline — late Friday rule stays intact. Turn this into a tight recording outline. Treat the Mercury auth baseline as the team update, keep customer language to product movement and blockers, and skip legal/ops unless there is an actual decision.

The Friday squeeze question landed exactly when I expected it would. #eng-team — Friday, June 9, 2023 Thread reply added to Mercury auth v0.2 baseline [3:37 PM] Rishi: Follow-up on the side admin work: branch `rishi/mercury-admin-org-invite-settings` just cleared CI. This is the org-invite/admin-settings cleanup we kept out of the baseline call. Question before I tee anything up further: do we want to squeeze this into prod this afternoon, or leave it on the normal Monday path? [3:39 PM] Jake: Only me and Rishi are online right now. Full on-call roster is not present. Reply in that same engineering thread: no Friday-after-3 exception without the full on-call roster. Keep the admin branch on the standard Monday pipeline.

Recording is up. - June 9 Friday update Loom: https://www.loom.com/share/8d0e9604c2d84e4da1f6a4f0c6c9c5bf - Used the earlier outline. - No extra written recap needed. Please post a one-line note with the Loom link in the current team Discord. Don’t add a duplicate written recap.

I’m leaving later than planned. Can you place my usual Friday Lemongrass dinner order and send me the ETA once it’s confirmed?

Can you check today’s calendar? If 10am-noon PT is open, create a protected hold titled `Protected time — Mercury operating work`. If it’s not open, don’t move anything.

Now that it’s Monday, please run `rishi/mercury-admin-org-invite-settings` through the standard staging pipeline. No shortcut path — I just want a green build for Rishi and Jake to dogfood from.

Jake’s weekly has the loose ends in one place. #eng-team — Monday, June 12, 2023 Jake (tagging Mercury leads): Mercury weekly note for leads: - Auth / dogfood: this week's build is moving onto the Clerk baseline from Friday. Sessions and magic links are where they need to be for internal use. Org-invite flow works, but the copy still needs a cleanup pass before we widen dogfood. - Release readiness: the checklist is still split between design-side issues and implementation-side issues. Right now it is half copy / UX / empty states and half gating / logging / fallback behavior. - Open owner questions: 1. Who owns the final org-invite copy pass before the next dogfood cut? 2. Who owns the release-readiness checklist as one thing instead of it living half in Figma and half in review comments? 3. Do admin / org-settings changes stay fully out until after the next dogfood cut, or do we want a narrower subset? - Morgan, can you give the top three blockers you want carried into this week's Mercury note? My rough list is invite copy cleanup, release-readiness ownership, and keeping the admin/settings scope from pulling SSO back into the conversation. - Separate point: SSO and deeper admin controls still feel like later-scope noise, not something I want mixed into this week's Mercury story. Create a short internal Mercury operating note from this: top blockers, owner questions, and what should stay out of investor framing. Keep it working-team material.

Anna’s weekly activation cut is here. Google Sheets export Workbook: Mercury activation cut — 2023-06-12 Owner: Anna Martinez Generated: 2023-06-12 08:14 PT [Tab: README] Reporting window: accounts created 2023-06-05 00:00 PT through 2023-06-11 23:59 PT Metric definition (corrected 2023-05-24) - Activated = first qualifying event within 7 days of account_created_at - Qualifying events = real_source_connected OR first_live_sync_completed - Not qualifying = sample_import_completed, invite_sent by itself Audience / use - Internal directional operating cut only - Do not use for board, investor, or external charts Caveats - Small sample this week: 18 provisionally new accounts in window - Every cohort in this window is still open or only just at the edge of the 7-day window as of this export - Two rows look like reactivation / dedupe edge cases and need warehouse review before this becomes anything sturdier [Tab: weekly_cut] signup_date | provisional_new_accounts | observed_activated_so_far | observed_rate_so_far | via_real_source_connected | via_first_live_sync_completed | sample_import_only | invite_sent_only_no_activation | no_meaningful_post_signup_event | 7d_window_status | notes 2023-06-05 | 3 | 2 | 66.7% | 1 | 1 | 1 | 0 | 0 | closes late 2023-06-12 | one cohort member only has sample import so far 2023-06-06 | 2 | 1 | 50.0% | 1 | 0 | 1 | 0 | 0 | open | small n 2023-06-07 | 4 | 2 | 50.0% | 0 | 2 | 1 | 1 | 0 | open | includes one reactivation candidate 2023-06-08 | 3 | 1 | 33.3% | 1 | 0 | 1 | 1 | 0 | open | includes one reactivation candidate 2023-06-09 | 2 | 0 | 0.0% | 0 | 0 | 1 | 1 | 0 | open | two signups; both stalled before qualifying event 2023-06-10 | 2 | 1 | 50.0% | 0 | 1 | 0 | 1 | 0 | open | weekend cohort 2023-06-11 | 2 | 0 | 0.0% | 0 | 0 | 1 | 0 | 1 | D0/D1 only | too fresh to read much TOTAL | 18 | 7 | 38.9% observed so far | 3 | 4 | 6 | 4 | 1 | all provisional | keep internal + directional only [Tab: path_summary] activation_path | accounts real_source_connected | 3 first_live_sync_completed | 4 sample_import_completed only | 6 invite_sent only / no qualifying event yet | 4 no meaningful post-signup event | 1 [Tab: edge_cases_for_review] provisional_account_id | created_at_pt | current_classification | qualifying_event_seen | why_flagged mrcy_06_07_b2 | 2023-06-07 10:14 | counted in weekly cut for now | first_live_sync_completed at +19h | org/domain matches April workspace; new org was created after prior workspace had gone dormant; likely reactivation vs truly new logo mrcy_06_08_f1 | 2023-06-08 16:52 | counted in weekly cut for now | real_source_connected at +2h | same billing customer fingerprint as March trial; owner email changed; need dedupe rule check before using externally [Sheet note from Anna] I left the two flagged rows in the provisional count so the team can see the operating shape, but I would not quote the topline outside the room. Biggest current question to me is whether the drop-off is mostly sample import but no real source, or whether invite/admin friction is the bigger blocker once a source is live. Pull out the operating questions and draft a short reply to Anna. Keep the cut clearly internal and directional — no board wording, no external framing, and don’t quote the topline as proof.

Mom did the quiet-weekend check-in. SMS thread 2023-06-12 09:18 AM — Mom: Hi honey, you were pretty quiet over the weekend, so now I am doing the annoying mother check-in. Are you exhausted, or just busy? 2023-06-12 09:19 AM — Mom: Also, how are the apartment and Kibo? I have not heard a home update in a bit. Draft me a short SMS I can send myself. Reassure her, mention normal apartment/Kibo stuff, and keep work to “busy but okay” level only.

I want to walk into the Mercury review with the lines clear, not with a lecture. Figma review packet File: Mercury activation / onboarding review Prepared by: Priya Last updated: 2023-06-13 08:37 PT Scope: dogfood activation flow from first workspace creation through first live sync and teammate invite Frames in review - Frame 12: Landing after workspace creation - Frame 15: Connect first data source - Frame 18: First sync success / handoff - Frame 21: Invite teammate - Frame 24: Error and retry states Design notes pinned in file Frame 15 - Decision: keep one primary CTA on the first-run path: Connect your first source - Sample import remains a secondary utility and does not count as activation Frame 18 - Decision: after first live sync, push directly to value confirmation and next action - Do not insert an admin detour before the user sees first live value Frame 21 - Decision: invite teammates after first live sync, not before - Keep the first-run path tight; avoid adding extra branching for org setup on the main path Frame 24 - Structure is locked for dogfood review - Need exact copy for credential failure versus permission failure Embedded comment export Frame 15 — Connect first data source 2023-06-12 17:42 — Priya Marking this as the intended primary path for dogfood. If a user only runs a sample import, they stay in the not activated state and get the secondary reminder, but we do not treat that as success. 2023-06-12 18:01 — Marcus I am not comfortable calling this ready unless we surface the stuck-credential case. The backend can fail in three different ways here and support will not know which bucket they are in from this screen. 2023-06-12 18:09 — Priya The flow decision is still one CTA and one fallback. Error taxonomy can sit under the same layout; I do not want the whole frame reopened because service responses are messy. 2023-06-12 18:18 — Marcus This is not just taxonomy. If we ship without a visible retry state, I will mark the dogfood checklist blocked. Frame 18 — First sync success / handoff 2023-06-12 18:26 — Priya Decision: after first live sync we go straight to value confirmation, then invite. No admin detour before first value. 2023-06-12 18:33 — Marcus Implementation note: org invite permissions are not actually clean in this branch. If we keep this order, someone needs to own the risk call that admins may see a dead-end on team invite. 2023-06-12 18:41 — Priya That sounds like checklist or release gating, not a design-decision comment on the frame. 2023-06-12 18:49 — Marcus Putting it here because the frame says ready for dogfood and that is what I am pushing back on. Frame 21 — Invite teammate 2023-06-13 07:58 — Priya Resolved earlier side suggestion to add admin settings link here. Keeping the path tight for first-run. 2023-06-13 08:03 — Marcus Please do not resolve this yet. Without an admin fallback, support gets a weird partial-success state for orgs with SSO coming later. 2023-06-13 08:11 — Priya SSO is later scope and not part of this review packet. If we need a fallback for dogfood, link the blocker instead of reopening the flow. Frame 24 — Error and retry states 2023-06-13 08:17 — Marcus Need explicit owner on implementation checklist for retry instrumentation before this can be considered shippable. 2023-06-13 08:20 — Priya Happy to link the checklist once it is cleaned up. I just do not want Figma comments turning into the release board. Priya open review items - Confirm copy tone for source-connection failure versus permission failure - Confirm whether invite reminder waits until first live sync or can appear on next return session - Implementation blockers should be linked, but not turned into open-ended flow redecisions unless the frame behavior changes Screenshot included in packet — text extraction from Discord, #eng-team, 2023-06-12 evening 19:14 — Marcus Figma keeps marking frames ready while release risks are still unresolved. I am not looking for a design debate, but I need somewhere to block dogfood. 19:17 — Priya Figma is the design review. If every risk objection lands in comments after a decision, there is not actually a source of truth. 19:20 — Jake Let us not split this across Figma and Discord tonight. Bring the blocked items to the review tomorrow. 19:24 — Marcus Fine, but then someone needs to say whether checklist blockers can override a resolved frame. 19:27 — Priya They can block ship, not rewrite the flow in chat. Identify where decision rights are blurring and give me a short in-room framing so this does not become another Priya/Marcus side-channel fight.

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.

Priya and Marcus both pinged me separately after the review, which is exactly the pattern I want to stop. Please send two concise private Discord notes. To Priya: reinforce that the activation/onboarding design calls are hers and Figma is the clean path for those decisions. To Marcus: reinforce that release-readiness and dogfood gating are his checklist lane, and those concerns can block ship without being litigated in Figma comments. Keep both calm and direct.

Pinecone confirmed the sandbox test passed. Subject: Re: Pinecone sandbox auth-header test From: Pinecone Integrations <integrations@pinecone-test.com> To: Morgan Chen <morgan@atlas-test.com> Date: Tue, 13 Jun 2023 14:26:44 -0700 Tuesday’s auth-header test passed cleanly against our sandbox. We saw the expected workspace header + signature on each request and did not need a fallback. If Scaffold wants to keep the same header contract, we can use it again for next week’s connector test. If you are planning to change anything before then, send the updated header shape and we will mirror it in the sandbox. Thanks, Pinecone Integrations --- From: Morgan Chen <morgan@atlas-test.com> To: Pinecone Integrations <integrations@pinecone-test.com> Date: Mon, 12 Jun 2023 09:11:07 -0700 Subject: Re: Pinecone sandbox auth-header test Thanks. For the sandbox pass we would like to keep the auth surface narrow: - X-Scaffold-Workspace - X-Scaffold-Signature No query-param fallback on this round. If that looks fine on your side, we are good to run the Tuesday test. Morgan Chen · Scaffold --- From: Pinecone Integrations <integrations@pinecone-test.com> To: Morgan Chen <morgan@atlas-test.com> Date: Mon, 12 Jun 2023 08:54:19 -0700 Subject: Pinecone sandbox auth-header test Can you confirm the header names you want us to expect for Tuesday’s sandbox auth test? If next week’s connector test is going to use the same contract, we can avoid reconfiguring twice on our side. Reply in the existing Pinecone thread, cc Sarah, that Scaffold will keep the same header contract for next week’s connector test. Keep it quick and don’t add new technical detail beyond that.

First internal dogfood notes from the Clerk-backed build: Discord thread — Mercury auth baseline 2023-06-14 10:18 AM — Rishi Ran the first internal dogfood pass on the Monday standard-staging build. Digest from my pass + 5 internal testers: Stable / green - Sessions look solid. Login -> app -> refresh -> close/reopen browser all held; no surprise logouts. - Invite accept + revoke both worked end to end on the current build. Acceptable for this round - Magic links are acceptable for internal dogfood. Delivery felt a little slow rather than broken, but nobody got stuck. - Expired-link handling is understandable enough for now. Confusing in the current build - Two testers got tripped up by the org-invite copy. - One read the invite email and thought they were being asked to create a brand-new workspace. - Another got to the accept screen and said it still reads more like signup than join-existing-org. - Suggest we tighten the invite email subject/body plus the accept-screen header before the next dogfood pass. Requested, but later scope - One tester asked for an SSO shortcut instead of the current password / magic-link path. - Marking that later scope, not something to wedge into v0.2. Net: functionally good enough to keep dogfooding once the org-invite copy gets cleaned up. Split this into must-fix-before-next-dogfood versus later-scope items for the Mercury operating note. I care especially about separating org-invite copy cleanup from SSO requests.

Devon is tempted to borrow the weekly activation uptick for the board pre-read. Discord DM — Devon Hayes -> Morgan Chen 2023-06-14 8:42 AM This week's Mercury activation cut finally has a real uptick after the mapping cleanup. I know it's still the weekly directional view, not the sturdier board cut, but the signal is fresh enough that I'm tempted to use it as a small footnote in the board pre-read rather than ignore it. Do you want me to patch the pre-read, or keep the weekly activation move fully internal for now? Give me a short reasoning response I can send him: keep the weekly activation move fully internal for now, don’t patch board material from this directional cut, and wait for the sturdier cohort view.

Jamie sent a draft October schedule hint. SMS thread — Jamie and Morgan 2023-06-14 6:27 PM — Jamie Sending the draft October schedule screenshot. [Attached image: hospital scheduling app month view for October 2023, marked draft. Oct 13-17 is mostly clear/lightly assigned; Oct 18-22 shows multiple tentative evening shifts and a weekend block.] Still preliminary, but the early stretch still looks easier to protect than the later part of the bigger window. 13-17 feels more realistic than the back half right now. I wouldn't lock anything yet though — they can still move stuff around. Think through whether this changes the Tokyo hold. My bias is still keep Oct 12–22 penciled in and mentally treat Oct 13–17 as the cleaner stretch, but don’t book anything and don’t narrow the calendar dates yet.

Greg reopened the Acme NDA/design-partner thread. Email thread From: Greg Shipman <greg@acme-test.com> To: Morgan Chen <morgan@atlas-test.com> Date: Thu, 15 Jun 2023 08:11:24 -0700 Subject: Re: Mercury design-partner wave / NDA coverage Morgan, Wanted to reopen two points in one place. First, if Scaffold is putting together the first Mercury design-partner wave, Acme should be considered for that group. We have already spent real time on the evaluation path, and I do not think it makes sense for us to be treated like a brand-new account. Second, Acme's view is that the NDA should cover the underlying evaluation materials here, not only polished screenshots or anything customer-facing. If Scaffold disagrees, please send written examples of what you believe falls outside the confidentiality scope so we can understand the boundary concretely. If the answer is that Acme is not in the first wave, please just say that directly. If the answer is maybe later, it would still help to know what has to be true first. Thanks, Greg Shipman Acme Prepare an internal note and a narrow unsent holding reply. Do not send anything, and don’t settle Acme’s design-partner status today. Keep our NDA boundary consistent without itemizing examples in a way that creates a new mess.

Marcus sent the cleaned release-readiness checklist. Linear export — Mercury dogfood build release-readiness checklist Exported by Marcus on 2023-06-15 11:06 AM View: implementation-only Note: design-decision comment threads were removed after the June 13 review. For Priya-owned flow/copy calls, use the linked Figma frames instead of debating them here. | Issue | Owner | Status | Blocker | Notes | Linked source | | --- | --- | --- | --- | --- | --- | | MERC-214 Session persistence on refresh + browser reopen | Rishi | In QA | none | Verify Clerk session survives hard refresh, reopen, and deep-link return on the standard-staging build. | n/a | | MERC-219 Magic-link resend + expired-state telemetry | Marcus | In progress | waiting on final event names from Rishi | Add send/open/success/expired/resend instrumentation so the next dogfood pass is measurable. | n/a | | MERC-223 Org-invite email copy implementation | Marcus | Ready | none | Apply the approved invite email subject/body from Figma; no wording discussion in this checklist. | Figma: Mercury activation/onboarding v18, frame INV-03 | | MERC-224 Org-invite accept-screen copy implementation | Marcus | Ready | none | Swap in the approved join-existing-org language from Figma; current flow works, this is clarity cleanup. | Figma: Mercury activation/onboarding v18, frame INV-07 | | MERC-228 Invite accept/revoke audit event | Rishi | In progress | webhook naming pass not final | Needed so support can trace who invited and who revoked during dogfood. | n/a | | MERC-231 Default dogfood org seed + pending invites | Jake | Ready | none | Seed 3 internal orgs and 2 pending invites so reviewers are not hand-building setup each time. | n/a | | MERC-233 Internal support note for known auth limits | Marcus | Drafted | none | Note that SSO shortcut requests are later scope for v0.2; route testers to password or magic-link for now. | n/a | | MERC-236 Rollback checklist for org-invite settings branch | Marcus | Ready | none | Standard pipeline only; keep rollback steps attached to the deploy checklist. | n/a | Out of scope for this checklist - SSO shortcut / IdP login option - Deeper admin controls around invite policy Removed from this view on export - Design-decision threads - Copy debates already resolved in Figma Save this as `Mercury dogfood release-readiness checklist — June 15` and keep it implementation-only. Design calls should link back to Priya’s Figma frames rather than getting reargued in the checklist.

Before Friday turns into six side threads, please post a concise Mercury operating update in the team Discord. No meeting. Include: - Auth dogfood: Clerk-backed build is functionally holding up; sessions are solid, invite accept/revoke worked, magic links are acceptable but a little slow, and org-invite copy is the must-fix before the next pass. - Release-readiness owners: Rishi on session persistence and invite/audit plumbing, Marcus on magic-link telemetry, invite-copy implementation, support note, and rollback checklist, Jake on dogfood org seed/pending invites, Priya remains the Figma owner for flow/copy decisions. - Monday open questions: are the telemetry/audit event names final enough to measure the next dogfood pass, and are we keeping SSO/deeper admin controls out of v0.2 while the invite/settings branch stays on the standard pipeline.

Greg's latest is below. Jake is trying to close the first Mercury design-partner wave this morning, so I don't want this thread to become the blocker list and the materials path at the same time. From: Greg Shipman <greg@acme-test.com> To: Morgan Chen <morgan@atlas-test.com> Cc: Sarah Kim <sarah@atlas-test.com> Date: Fri, Jun 16, 2023 at 8:14 AM PDT Subject: Re: NDA scope and Mercury examples Morgan, I understand the position, but “outside the confidentiality scope as drafted” is still too high-level for us to action on our side. Please send written examples of the materials Scaffold is saying were outside scope among the items Acme has raised. A short list is fine. If that means screenshots, workflow notes, rollout materials, or anything else, please identify those in writing so we can sort it cleanly. If you still want to discuss live after that, fine, but I need something more specific than the current sentence before I take this back internally. Greg On Thu, Jun 15, 2023 at 4:18 PM Morgan Chen <morgan@atlas-test.com> wrote: Greg — Scaffold disagrees that the materials Acme pointed to fall within the confidentiality scope as drafted. Those items were outside that scope, and Scaffold preserves all other rights. If it would be useful, we can discuss live. Morgan Chen · Scaffold Please send a narrow reply on the existing external thread to Greg with Sarah Kim copied: no written examples by email, Scaffold's view is still that the disputed materials are outside the confidentiality scope as drafted, all other rights are preserved, and if Acme wants to discuss examples we should do that live. Also send Jake a short internal chat note: Acme can keep informing customer/blocker context, but while the NDA scope is muddy they should not get fresh Mercury materials and should not be in the first design-partner wave.

Pinecone came back on the connector test. Details are here: From: Pinecone Integrations <integrations@pinecone-test.com> To: Morgan Chen <morgan@atlas-test.com> Cc: Sarah Kim <sarah@atlas-test.com> Date: Fri, Jun 16, 2023 at 9:27 AM PDT Subject: Re: Pinecone connector test — signature mismatch Hi Morgan, We reran the sandbox connector test this morning using the agreed header contract and no query-parameter fallback. Log excerpt: [2023-06-16T16:22:34Z] POST /v1/connectors/pinecone/test Headers: X-Scaffold-Workspace: ws_sandbox_2c17 X-Scaffold-Signature: t=1686932494,v1=0f92e8c0a7d3b4f1... Content-Type: application/json Body: {"workspace_id":"ws_sandbox_2c17","connector":"pinecone","mode":"test"} Response: 401 {"error":"signature_mismatch","detail":"timestamp outside accepted skew"} Timing we captured: signed_at: 2023-06-16T16:21:34Z request_sent: 2023-06-16T16:21:36Z request_received: 2023-06-16T16:22:34Z The header names matched your note, so the remaining mismatch looks like timestamp skew rather than a missing field. Do you want us to keep the contract exactly as-is and retry with tighter clock sync, or should we add a temporary query-parameter fallback for timestamp/signature while you debug? Best, Pinecone Integrations On Tue, Jun 13, 2023 at 2:41 PM Morgan Chen <morgan@atlas-test.com> wrote: Confirmed for this connector test: - X-Scaffold-Workspace - X-Scaffold-Signature Please keep it header-only for this pass; no query-parameter fallback. Morgan Chen · Scaffold Please reply in the existing Pinecone integration thread with Sarah copied: the header contract is unchanged, no query-parameter fallback, and they should retry with the narrower timestamp/skew window. Separately send Rishi a quick internal note: the one code-side thing to inspect is the signing/timestamp path around signed_at versus send/receive time, since the headers matched and the failure is timestamp skew.