Morgan Chen

Leo’s first release-risk readout is done. This is useful, but I don’t want it accidentally becoming a full launch ledger. Mercury release-risk readout — 2023-07-14 Attendees: Morgan Chen, Leo Park, Jake, Priya, Marcus Leo framing - Kept this to release risk + evidence, not a platform roadmap. - Main lens was where Mercury can still surprise us at the seams, especially where activation behavior depends on auth/org state and where dogfood evidence is still thin. 1) Risk: org-invite roles vs activation-state seam - Highest platform-seam risk is the invited-member branch because rendering depends on server role + source state, and those do not always settle at the same time. - Leo’s concern: the design/state map is clear, but the seam is timing-sensitive. A user can accept an invite, get the org role update, and still be between source states long enough to show the wrong branch or CTA. - Evidence: - only 2 real dogfood invited-member accounts end to end - one bug-bash pass needed refresh/re-entry before the UI settled on the expected branch - current confidence is still coming more from happy-path staging than repeated real dogfood coverage - Leo severity / confidence: High severity, medium confidence - Next verification: - run more real invited-member dogfood accounts across admin-first vs invitee-first orderings - verify no path creates an activated-looking state without a real source or first live sync - confirm sample data stays visually separate / preview-only and never shifts the branch into something that looks activated - watch CTA selection on first load after invite accept - Notes from room: - Priya: design intent is still the four branches; no pseudo-activated middle state - Jake: this should be treated as a release risk because it crosses auth/org state, not just copy or UI - Marcus: want enough evidence to know whether wrong-CTA cases are rendering issues or stale-state timing 2) Risk: release-readiness evidence gaps are themselves material - Leo separated “implemented” from “proven.” Some paths may be close in code, but we still do not have enough boring real-world evidence to call them ready. - Evidence gaps called out: - invited-member branch only has 2 real dogfood accounts - queued-sync retry logs are sparse even after removing fake progress / countdown behavior - failed-sync screenshots are cleaner, but sample depth is still shallow - Jake agreed this is not just QA neatness; if the proof is thin, the launch risk is still real. - Leo severity / confidence: High severity, high confidence on the evidence gap; lower confidence on how many user-facing bugs remain underneath it - Next verification: - targeted dogfood pass that exercises each branch with saved screenshots and logs - collect at least one real queue -> retry -> recovery trace for queued sync - separate “path unproven” from “path actually broken” in the next pass 3) Risk: failed-sync cleanup still needs full verification - Leo thinks the failed state is close, but not fully done until every normalized bucket is verified end to end. - Evidence: - one screenshot still leaks a raw vendor string - current fixes seem to cover the obvious path, but no one could say with confidence that auth/permissions, source unavailable/timeout, and unknown/retry are all equally clean - Marcus said the retry action itself looks better, but he still wants proof that the bucket text and UI stay normalized on every branch. - Priya noted the warning-circle direction still seems right; the issue is verification, not revisiting the icon choice. - Leo severity / confidence: Medium severity, medium confidence - Next verification: - retest each failed bucket with captured UI - confirm no raw vendor strings leak - confirm retry remains idempotent 4) What is later polish vs what can still block - Leo explicitly did not put setup-guide copy tightening or icon polish in the main blocker bucket. - Current view from the room: - setup-guide copy can wait unless it causes a wrong action or real confusion in the invited-member branch - small-width spacing can wait unless it clips or overlaps on a supported width - failed-state icon polish can wait unless it obscures state meaning - Priya was aligned with keeping polish later as long as branch distinctions stay crisp. - Jake said not to let a polish list turn into a second scope track before the next Mercury cycle. Explicit exclusions / not the point of this readout - no abstract platform recommendations - no reopen of provider debate or broader auth rewrite scope - no SSO/admin-depth wishlist - not converting this into an owner-split launch ledger yet Questions Leo wants answered next - Can we prove invited-member rendering across real role/source-state permutations, not just the happy path? - Do we have enough queued-sync retry evidence to say recovery is understandable without fake progress? - Is failed-sync normalization actually complete across all buckets, or just mostly clean on the common path? - Which of the current gaps are real launch blockers vs thin proof on otherwise-correct behavior? - What is the smallest next dogfood pass that materially raises confidence before we widen exposure? Please save a note titled `Leo Park — Mercury release-risk readout — 2023-07-14` with the risk areas, evidence behind each, and the questions to verify next. Then post a concise update to the current engineering team chat in Discord summarizing the risk areas at a high level and making clear this was a release-risk/evidence readout, not an owner-split launch ledger.

Jake put the Monday Mercury note in #eng-team. #eng-team Mon Jul 17, 2023 9:08 AM — Jake Monday Mercury weekly - Carrying forward Leo's Friday readout: top launch seam is still invited-member org-role/source-state rendering. - Evidence is still thin there. We only have 2 real invited-member dogfood accounts end-to-end so far. - Queued-sync retry evidence is also thin. I have one usable retry trail, not enough to say that path is exercised. - Priya's latest failed-sync screenshots look materially better. Open question: can we treat the raw vendor-string issue as fixed, or do we still need bucket-by-bucket proof before we close it? - Not trying to reopen settled CTA/icon calls. This week should stay on launch evidence, must-fix regressions, and what blocks the next dogfood. - If anyone has concrete screenshots or logs that change the picture, please drop them here before the weekly. Can you give me a compact operating read for the weekly? I want the missing evidence, what we should keep from turning into architecture work, and the specific points I should press the team on.

Rishi found the verifier-side issue. Discord DM Mon Jul 17, 2023 11:17 AM Rishi Tracked the Pinecone reject down. The verifier was reading the signature header casing too literally. Same body + same workspace would verify if the header came through as preserved `X-Scaffold-Signature`, but it could reject on lowercased `x-scaffold-signature`. I patched it so both header variants canonicalize against the same request body and workspace now. I tested the same payload both ways and they match. Question before I reply back through you / before we ask Pinecone to rerun: if they want the fastest path, do we want to offer a temporary query-param fallback for sandbox, or keep it strictly on the header-only contract? Please handle this in two places. In the existing external Pinecone email thread, keep Sarah Kim copied, say Scaffold patched the verifier so preserved `X-Scaffold-Signature` and lowercased `x-scaffold-signature` both verify against the same request body and workspace, decline any query-parameter fallback, and ask Pinecone to rerun the same header-only sandbox connector test. Separately send Rishi a private note that the fallback is off the table; we’re keeping this on the header-only contract.

Pinecone’s rerun came back clean. From: Pinecone Integrations <integrations@pinecone-test.com> To: Morgan Chen <morgan@atlas-test.com> Cc: Sarah Kim <sarah@atlas-test.com> Date: Tue, 18 Jul 2023 2:14 PM -0700 Subject: Re: Pinecone connector sandbox header check Thanks — we reran the connector test in sandbox on the agreed header-only contract. Results: - `X-Scaffold-Workspace` + preserved `X-Scaffold-Signature`: pass - Same request body/workspace with lowercased `x-scaffold-signature`: pass - No query-parameter fallback used Both signature-header variants verified cleanly on our side against the same body and workspace. Pinecone Integrations On Mon, 17 Jul 2023 at 11:46 AM, Morgan Chen <morgan@atlas-test.com> wrote: > To: Pinecone Integrations <integrations@pinecone-test.com> > Cc: Sarah Kim <sarah@atlas-test.com> > Subject: Re: Pinecone connector sandbox header check > > We found the source of the reject on our side and patched the verifier. > > The fix canonicalizes preserved `X-Scaffold-Signature` and lowercased `x-scaffold-signature` against the same request body and workspace. We'd like to keep the existing header-only contract in place and not add a query-parameter fallback. > > If helpful, please rerun the same sandbox connector test using the agreed headers: > - `X-Scaffold-Workspace` > - `X-Scaffold-Signature` > > If you can, test both signature-header casing variants against the same body/workspace and let us know what you see. > > Morgan Chen · Scaffold Please close the existing external thread with Sarah Kim still copied: confirm the connector can proceed on the agreed header-only contract. Also update the Pinecone relationship record and our internal integration notes so the signature-header casing failure is no longer listed as an open blocker.

Marcus posted the fresh release-readiness evidence. #eng-team Wed Jul 19, 2023 1:36 PM — Marcus Quick release-readiness evidence update on the failed-sync / retry pieces: - `source unavailable` is now normalizing vendor errors in the current build. The raw vendor strings I was seeing there are gone. - `unknown / retry` still does not have a screenshot set I would call verified. I still don't have one Leo should cite as closed. - Queued-sync retry logs still cover exactly one dogfood run end-to-end. Better than zero, still thin. - Separate concern: please keep Friday's doc as launch-readiness verification. I am worried this turns into a platform rewrite memo if we're not explicit about scope. Please send Leo a private Discord note with the concrete asks for Friday’s readout: keep it tied to launch-readiness verification, not a broader platform memo; treat `source unavailable` as improved in the current build; do not cite `unknown / retry` as closed without a screenshot set; call out that queued-sync retry still has only one end-to-end dogfood run; and ask him to separate verified closure from thin evidence.

Anna found a real leak in the internal dogfood activation view. From: Anna Martinez To: Morgan Chen <morgan@atlas-test.com>, Devon Hayes <devon@atlas-test.com> Date: Thu, 20 Jul 2023 9:22 AM -0700 Subject: Mercury activation cut — sample preview leakage Morgan, Devon — I found a problem in the internal Mercury dogfood activation query this morning. - Three preview-only sample-data accounts were counted as activated. - The issue is that one path in the query is still treating `sample_import_completed` like activation. - Those three accounts did not have `real_source_connected` or `first_live_sync_completed` within 7 days, so they should not count under the corrected activation definition. - As far as I can tell, this affects the internal directional dogfood view only. - The cohort view we've been using for board/investor material was not generated from this query. I have not regenerated the directional cut yet. I wanted to flag the leakage first before I touch the internal share-out or trace whether any adjacent view inherited the same logic. Anna Draft me a short reply I can send to Anna. Tell her to quarantine the bad internal view first, rebuild the directional cut with sample data excluded from activation, and make sure `sample_import_completed` does not count. Also be explicit that this should not touch board or external materials from this issue; keep the cleanup on the internal directional view and any adjacent internal view that inherited the same logic. Draft only.

Leo’s Friday Mercury release-risk update is in. [Discord — #eng-team — 2023-07-21] Leo Park: Friday Mercury release-risk update attached. Keeping this scoped to launch risk and evidence only, not broader platform recommendations. Attachment: Mercury release-risk update — 2023-07-21 Scope - Mercury launch-readiness only. - This is not a launch ledger and not a platform memo. | Top risk | Evidence source | Severity / confidence | Next verification | | --- | --- | --- | --- | | Invited-member org-role/source-state rendering remains the highest launch risk. The seam is still whether server role plus source state consistently land the user in the right branch for real invited members. | Evidence is better than last week: I now have four real invited-member dogfood accounts exercised in the current pass. That is meaningful improvement from the earlier two-account sample, but it is still a small set for the state combinations we care about. | Severity: high. Confidence: medium. I am more confident that this is the top seam than I am that it is fully covered. | Exercise the remaining real invited-member state combinations we have not seen cleanly yet, and verify rendered state against server role plus source state rather than screenshot expectation alone. | | Queued-sync retry behavior is still under-evidenced for release-readiness. | I only have one queued-sync retry log from a real dogfood run. That proves the path exists, but it does not give enough coverage to say retry behavior is well-understood under launch conditions. | Severity: medium-high. Confidence: high on the evidence gap, low on any broader stability claim from current logs. | Capture at least one more queued-sync retry run and confirm no misleading progress language, no bad state carryover after retry, and no branch flip on refresh. | | Failed-sync normalization is partly verified, but the unknown/retry bucket is still not evidenced cleanly enough. | The auth/permissions bucket and source-unavailable bucket look materially better, including the normalized source-unavailable behavior Marcus flagged. I still do not have a clean unknown/retry screenshot I would use as launch evidence. | Severity: medium. Confidence: medium. I would call parts of failed-sync improved, not the full bucket set closed. | Get a clean unknown/retry screenshot and verify normalized copy plus retry behavior on that branch specifically before marking failed-sync verification complete. | Notes - Net improvement since the prior readout: invited-member evidence moved from two real dogfood accounts to four. - Biggest remaining evidence hole: queued-sync retry logs are still effectively a one-run sample. - Missing evidence is itself a launch risk here; I am not treating it as documentation debt. Explicit exclusions - No platform rewrite recommendation in this note. - No auth/session re-architecture recommendation in this note. - No generalized queue or state-machine cleanup recommendation unless it has direct Mercury launch impact. Bottom line - Top launch risk is still invited-member org-role/source-state rendering. - Evidence improved this week, but not enough yet to call the seam low-risk. - Failed-sync is improved, not fully verified. Please create a prep note titled `Mercury launch-readiness questions for July 24`. Keep it to unresolved evidence and decision questions only: invited-member coverage, queued-sync retry evidence, failed-sync unknown/retry proof, and what would actually raise confidence before wider dogfood. Don’t assign final owners across Jake, Priya, Marcus, Anna, or Devon yet, and don’t treat this as the launch ledger.

Mom is doing the launch-week check-in. SMS thread — Mom 2023-07-23 09:14 Mom: Hi honey — is the coming launch week getting too rough on you? You sounded a little tired the last time we talked. Also, has Kibo settled into the Oakland apartment yet? Does he like having more room, or is he still doing his little patrol of every corner? No rush to answer — just checking in. Love you. Draft me a short SMS I can send myself. Keep work at busy but okay, answer the Oakland apartment/Kibo part warmly, and don't get into late nights or stress.

MER-1279 is now agreed enough that I want the team habit set before it drifts. Discord — #eng-team 2023-07-24 09:18 Leo Park Pulled the first Mercury release-risk readout into one working place so the evidence stops living across PRs, Linear, Figma comments, and Discord threads. Created: MER-1279 Mercury launch-readiness ledger Columns: risk | evidence source | owner | verification needed | weekly decision Why this exists: the readout itself was useful, but it was too blunt because the support for each call was scattered. The ledger is meant to hold the actual row-level evidence and the specific decision question for the weekly, not a separate narrative status doc. Owner split for MER-1279: - Marcus owns implementation gates and current dogfood blockers. - Priya's Figma files/comments remain the design source of truth; ledger rows should link to the relevant frame/comment instead of duplicating design decisions. - Leo owns cross-service platform-seam risk notes and missing-evidence callouts. - Jake runs the Mercury weekly from the ledger's weekly-decision column. If you're updating something launch-relevant, please add the evidence link to the row instead of dropping a standalone summary in chat. 09:24 Priya +1 on keeping design resolution in Figma. If a row needs design context, link the frame/comment thread; don't restate it loosely in the ledger. 09:27 Marcus Works for me. I'll keep the implementation-gate and dogfood-blocker rows current there. 09:31 Jake Yep. I'll run the Mercury weekly from MER-1279 and use the weekly-decision column instead of asking each owner for a separate status story. Please post one concise note in the engineering Discord confirming that MER-1279 is the working source for Mercury launch readiness: Marcus owns implementation gates and dogfood blockers, Priya's Figma remains the design source of truth, Leo owns cross-service platform-seam risk notes, and Jake will run the weekly from the ledger instead of collecting separate owner narratives.

Devon is already asking whether this becomes external language. Discord DM — Devon Hayes → Morgan Chen 2023-07-24 11:07 Devon Quick question: can we turn Leo's Mercury risk readout + the new launch-readiness ledger into a board/investor progress line this week? 11:08 Devon Not saying we oversell it — more like, "we now have one operating ledger for launch risk instead of scattered evidence." Just want to know whether you want that used externally or kept strictly internal for now. Send him a brief internal Discord reply: keep Leo's readout and the new ledger as launch-readiness operating evidence for now, not a board/investor proof claim or B-round reopening point. Useful progress, still internal.

Priya sent the review request with the actual frame context this time. Discord DM — Priya → Morgan Chen 2023-07-24 13:34 Priya Sending the failed-sync / small-width review request. Figma: https://www.figma.com/file/7mQvR1aH2k9p4LxM3Yc8nR/Mercury-activation-v0.2?node-id=1842%3A9912 Context: I updated the Mercury failed-sync and small-width frames to separate the one must-fix follow-up from the polish that should stay out of the dogfood gate. The review should focus on whether the 320px source-unavailable clipping follow-up is actually resolved in the latest frames, whether the failed-sync states still preserve the warning-circle direction and normalized error buckets cleanly at small widths, and whether anything still sitting under setup-guide copy or icon polish has crossed from nonblocking follow-up into a real release-readiness blocker. I'm not reopening the settled CTA or failed-state icon decisions; this is a check that the frames are good enough for the next dogfood pass and that Marcus and Leo can tie any remaining evidence questions back to the ledger. Attendees: Morgan Chen, Priya, Marcus, Leo Park Proposed slot: 2023-07-26T14:00:00-07:00 to 2023-07-26T15:00:00-07:00 If that slot is clear, please send the review invite. Check my calendar, and if the proposed 60-minute slot is clear, create the review invite titled `Mercury failed-sync / small-width review` with Morgan Chen, Priya, Marcus, and Leo Park. Put Priya's Figma link and context in the invite notes so this stays scoped to the 320px failed-sync follow-up, small-width failed states, and ledger evidence questions, not reopening the settled CTA or icon decisions.

Anna's new evidence table is finally more useful than the scattered screenshots were. Mercury dogfood evidence — invited-member and retry states, July 24 Owner: Anna Martinez Audience: internal Mercury operating group Cutoff: 2023-07-24 09:40 PT Rule used for this cut - Activated = real_source_connected OR first_live_sync_completed within 7 days. - sample_import_completed is excluded from activation. - invite_sent is supporting activity only. - This document is for internal operating evidence, not board/external use. Evidence rows ID | Account | Scenario | Evidence source | Observed state | Activation treatment | Notes IM-01 | DF-17 | Invited member, no real source on workspace | Screenshot 2023-07-22 10:14 PT + event log | "View setup guide" rendered; no owner CTA shown | Not activated; invite_sent only | Server role=member and source_state=none matched expected branch. IM-02 | DF-22 | Invited member, admin connected first real source before member's first visit | Screenshot 2023-07-22 16:41 PT + session trace | Member still rendered on invited-member guide path, not "Connect a data source" | Admin account counted from real_source_connected; invited member not separately activated | Good evidence that role + source state are not collapsing into the owner path, but still single-account coverage. IM-03 | DF-29 | Invited member with preview/sample data present from prior setup demo | Screenshot 2023-07-23 09:08 PT + event log | Sample area stayed visually separate/preview-only; member state still "View setup guide" | sample_import_completed present but excluded; not activated | Best current proof that sample data is not creating an activated-looking path. IM-04 | DF-31 | Invited member opens while admin has started setup but first live sync is not complete | Screenshot 2023-07-23 17:26 PT + worker log | Member remained on guide path while sync was pending; no false activated state | Not activated on member record; admin activation still tied to real_source_connected / later first_live_sync_completed | Helpful for the waiting-state edge, but we still do not have every invited-member role/source combination. QR-01 | DF-35 | Queued first sync, source unavailable on first attempt, then retry | Screen capture 2023-07-24 08:12 PT + job log | Queued state showed no fake percent/ETA; retry returned cleanly to queued and then completed | Activation already counted from real_source_connected within 7 days; retry did not create a second activation event | Real dogfood proof that retry can re-enter queued cleanly. QR-02 | DF-37 | Queued first sync, manual retry after timeout-class failure | Screen capture 2023-07-24 09:03 PT + job log | Retry action was idempotent; no duplicate jobs visible; state returned to queued without odd copy changes | real_source_connected already present; first_live_sync_completed still pending at cutoff | Better than last week because this is a second real retry attempt, but evidence is still light. FS-UR-01 | DF-41 | Failed sync normalized into unknown/retry bucket | Clean screenshot 2023-07-24 09:34 PT + UI capture | Neutral warning-circle state, "Try again" CTA, no raw vendor string exposed | Activation unchanged; sample import absent | First clean proof for the unknown/retry bucket. Useful, but still only one captured case. Coverage notes as of cutoff - Invited-member evidence is better organized, but four real accounts is still too small to call low-risk across all role/source-state combinations. - Queued-sync retry now has two real dogfood attempts instead of one; that supports using the path operationally, not calling it closed. - Unknown/retry failed-sync now has a clean screenshot. That closes the "no clean proof" gap, but not the broader confidence question. - Any rows with sample_import_completed were checked against the activation rule above and excluded from activation counts. Give me a concise reasoning pass, not a reply: what this supports operationally, what is still too thin to treat as closed, and what must stay out of board or external material.

Marcus has a staging-only branch for the retry-log evidence. Discord DM — Marcus to Morgan 2023-07-25 09:18 PT Marcus: I have a tiny branch ready for the Mercury queued-sync retry-log pass: `mp/mercury-queued-sync-retry-log`. This is just for staged evidence on the queued-sync retry path — enough logging around retry attempt/outcome so Leo can match what we think the UI is doing to what the worker actually did. Only needs the normal staging run on this one. Not prod. Run `mp/mercury-queued-sync-retry-log` through the standard Mercury staging path only. No production push; keep it as staged evidence for the queued-sync retry path.

Jake's agenda draft is sliding back into owner-by-owner storytelling. Discord DM — Jake to Morgan 2023-07-25 11:02 PT Jake: Rough draft for this week's Mercury weekly. I know we said ledger-first off `MER-1279 Mercury launch-readiness ledger`, but I still want short live context from each owner so people aren't just reading rows cold. Agenda draft 1. Open on top 3 launch risks from MER-1279 (5 min) 2. Priya — failed-sync / small-width frames: what's locked vs still open (3 min) 3. Marcus — implementation gates + dogfood blockers, including whether the 320px clipping issue is actually closed in the current build (3 min) 4. Leo Park — queued-sync retry evidence / platform-seam notes, and what still feels thin (3 min) 5. Anna Martinez — evidence quality on invited-member + retry states, plus anything that should stay internal-only for now (3 min) 6. Jake — overall launch path / where we may be slipping (3 min) 7. Walk remaining ledger rows and decide next actions (8 min) If Priya, Marcus, Leo, and Anna can each drop a short narrative update in-thread ahead of time, even better, but I'd still like them to talk it through live. Draft me a short note to send Jake. The point: run the Mercury weekly from MER-1279, center it on three decision questions, and skip separate live narratives from Priya, Marcus, Leo, and Anna unless a ledger row actually needs a decision.

Devon flagged the AP queue before this one auto-pays. Discord DM — Devon to Morgan 2023-07-25 12:14 PT Devon: Can someone clean up the AP queue today? The old Acme Corp invoice is still sitting in pending at $6,200. That one definitely should not auto-pay — it needs manual review at that amount. Given the last Acme near-miss, I'd rather be conservative. If nothing else gets touched, please make sure the Acme one doesn't go through the normal payment pass. Inspect the pending invoice records and flag the Acme Corp invoice for manual review because it's $6,200 and over the threshold. Do not pay it and don't send Acme a reply.

Sarah's design-partner questions are the right input for Thursday, but I don't want them dressed up as fundraising collateral. From: Sarah Kim <sarah@atlas-test.com> To: Morgan Chen <morgan@atlas-test.com> Cc: Devon Hayes <devon@atlas-test.com>, Jake <jake@atlas-test.com> Date: Tue, 25 Jul 2023 08:41:00 -0700 Subject: Mercury design-partner readiness questions Sending the recurring launch-readiness questions I'm hearing in prospective design-partner conversations. I'm deliberately not naming anyone here because the conversations are still exploratory, but the themes are pretty consistent and seem useful before the Thursday checkpoint. 1) Source setup failure cases - If the first source connection fails, what does the user actually see? - Can they tell the difference between auth/permissions trouble, source unavailable/timeout, and an unknown failure without us translating it for them? - Does recovery look self-serve, or does it feel like they would need vendor/API knowledge to continue? 2) Admin handoff - If an admin starts setup and then invites an operator or teammate, does the invited person land in a sane next step? - What happens if the invited member arrives before the first source is fully connected? - Is the line between "waiting on admin/first source" and "something is broken" obvious? 3) Time to first sync - How long from first connection to first live sync in the normal case? - If the sync is queued or retried, what reassures the user that the system is working without inventing fake progress? 4) Which failure states are actually understandable - Which states are legible on first read to an external user? - Which ones still make sense only if someone from our side narrates what happened? 5) What evidence creates enough confidence to try Mercury - a clean first-run path end to end - one or two believable recovery examples when setup or sync fails - proof that invited-member/admin handoff is not brittle - clear separation between sample/preview data and real activated state - a credible sense of time-to-first-sync, even if it's a range rather than a promise My read is that this is product-readiness input, not deck material. It's basically the bar people are using to decide whether they would be comfortable trying Mercury with a real but bounded workflow. Create a one-page internal checklist for the Mercury headcount checkpoint: what external launch-readiness feedback we need before deciding any second Mercury engineering req. Keep it as product-readiness input only, not board, investor, or B-round material.

The latest Figma comments are enough to close the design part and push the evidence gap back where it belongs. Figma comment thread — Mercury activation surface v0.2 File area: failed-sync + small-width states 2023-07-26 [09:12] Priya: Keeping the neutral warning-circle on failed sync. The broken-link direction is still too vendor-specific, and the retry arrow should stay an action affordance, not the main state icon. [09:19] Marcus: From the release-readiness side, the 320px source-unavailable clipping issue looks fixed in the latest frames. The body copy wraps cleanly now and the CTA/help text no longer collide at that width. [09:27] Leo Park: Visual direction seems fine. The one unknown/retry screenshot helps on failed-sync, but queued-sync retry proof is still thin even after Anna's July 24 evidence pass. Better than last week, but I would keep that row live in the ledger until we have another clean retry run tied to logs/screens or equivalent proof. [09:34] Priya: Agree. Also marking setup-guide copy polish and icon polish as follow-up, not dogfood gate, unless either one creates clipping/overlap, points to the wrong action, or makes the state meaning less clear again. Draft a pasteable Figma reply. Lock the neutral warning-circle and the settled CTA direction, say the 320px source-unavailable clipping looks fixed in the latest frames, keep setup-guide copy and icon polish as nonblocking follow-up unless they create clipping, wrong action, or state confusion, and send queued-sync retry proof back to the Linear ledger until another clean log/screen run closes that evidence gap.

Devon's pre-checkpoint note is useful, but I want the meeting aimed at a rule rather than a vibe. From: Devon Hayes <devon@atlas-test.com> To: Morgan Chen <morgan@atlas-test.com> Date: Wed, Jul 26, 2023 8:14 AM Subject: Thursday Mercury headcount checkpoint Morgan — Ahead of Thursday's checkpoint, here's the frame I want us using so we don't spend the whole slot rehashing the month. 1) Candidate pipeline is stale. Anything that looked interesting in June has either cooled off, drifted out of Mercury scope, or is not close enough to matter for an immediate decision. If we reopen now, we should be honest that we're effectively starting a fresh search, not pulling the trigger on a near-close candidate. 2) Jake still wants another senior engineer. I get why. The argument is depth, less key-person risk, and another person who can independently carry ugly launch-critical issues if Leo turns up more real seams in auth/session/platform edges. 3) The new information is that Leo is finding actual seams, not writing a platform thesis. That is a point in favor of letting the current shape settle. His readout was useful because it surfaced real Mercury risk, and the new ledger is already making that work more concrete. 4) Waiting also has a cost. If we wait until late August and then decide we do need help, we will have burned time and the market does not get easier just because we were hesitant. The thing I do not want Thursday to become is another "let's revisit in a few weeks" conversation with no trigger. We have done enough calendar-based decision making on this. What I want out of the checkpoint is a rule: - what evidence would mean "open the req now," - what evidence would mean "current team shape is enough through launch," and - if we do reopen, what profile are we actually opening for. Sarah Kim's design-partner questions are useful input here. The ones that feel most decision-relevant to me are: - can an external admin get through setup without us narrating it, - do invited-member/admin handoff states make sense, - are failure states understandable and recoverable, - does time-to-first-sync feel trustworthy enough to a real user. If those are still muddy, I think that argues for using external readiness feedback before deciding profile. And if we do reopen, I don't think the answer should default to "another senior engineer because that was the old plan." The real options are at least: - another senior engineer, - a stronger mid-level implementer for launch cleanup / follow-through, - or no immediate hire. Not trying to decide it over email; just want the meeting pointed at the actual choice. — Devon Turn this into focused checkpoint questions for me. Do not decide the req in the prep. I want the questions to force the evidence triggers: what would justify opening now, what would show the current team is enough through launch, and if we do reopen, whether the profile is senior, mid-level implementer, or no immediate hire.

The checkpoint is done; this is the decision record I want reflected in the plan. Mercury engineering headcount checkpoint Date: Thu, Jul 27, 2023 Attendees: Morgan Chen, Devon Hayes, Jake Purpose Decide whether to reopen the second Mercury engineering req now, and if not, what decision rule replaces the old month-end revisit habit. Current context - Leo's first release-risk readout was useful and has now been turned into a single Mercury launch-readiness ledger in Linear. - Candidate pipeline is stale; there is no near-close candidate that would justify pretending this is an immediate hire / no-hire switch. - External launch-readiness questions are getting sharper: source setup failure cases, admin handoff, time-to-first-sync, and whether failure states are legible without internal help. Jake's case for reopening now - Still wants more senior depth. - Concern is not abstract headcount; it is too much launch-critical ambiguity resting on a small set of people. - If Leo keeps finding cross-service seams, auth/invite edges, and release-discipline gaps, Jake does not want Marcus + Leo + himself absorbing everything while Priya is still holding activation UX decisions. - Senior profile is still his default because he thinks the remaining risk is more about independent judgment through ugly edge cases than raw ticket throughput. Devon's view - Agrees the risk is real, but the pipeline does not support a reflex reopen. - Reopening now means starting a fresh search from zero, not converting an active pipeline. - Wants a decision rule tied to product-readiness evidence, not another calendar reminder. Morgan's view - July's actual signal is that Leo is finding the right seams. - The new ledger gives the team one place to track launch readiness instead of burying risk in PRs, Figma comments, or Discord threads. - The missing input is external launch-readiness feedback: can real users navigate setup, invited-member/admin handoff, failure recovery, and first-sync confidence without hand-holding. - Do not force the old two-senior shape just because that used to be the plan. - Keep this as launch-readiness operating logic, not an investor story. Agreed owner split (unchanged) - Marcus owns implementation gates and dogfood blockers. - Priya owns design decisions / Figma source of truth. - Leo owns cross-service platform-seam risk notes. - Jake uses the ledger in the Mercury weekly. Decision - Do not reopen the second Mercury engineering req now. - Do not set another arbitrary month-end revisit date. - Revisit only after external launch-readiness feedback from design-partner conversations and trials is in hand. Decision rule for the next req 1. Open a senior-engineer req if external feedback shows repeated platform / architecture-seam failures that need independent senior ownership to unblock launch confidence. 2. Open a more implementation-heavy mid-level req if the core user path is understandable but the limiting factor is cleanup throughput, follow-through, and launch hardening. 3. Open no immediate req if external users can get through setup, admin handoff, early sync, and failure recovery with manageable issues that the current owner split can close from the ledger. Specific evidence required before reopening the question - source setup failure cases seen by external users - admin / invited-member handoff clarity - time-to-first-sync comfort / trust - which failure states are understandable vs confusing - whether the remaining blockers look like depth problems or execution-throughput problems Follow-up note - Pipeline can stay cold until the external feedback points clearly to a profile. - This replaces the old "revisit after July" placeholder with an evidence trigger. Update the existing Mercury engineering headcount plan: the second engineering hire stays on hold, there is no new arbitrary month-end revisit, and the next look is triggered by external launch-readiness feedback from design-partner conversations/trials. Keep the decision rule in the plan: senior req for repeated platform/architecture-seam failures, mid-level implementer for cleanup-throughput constraints, or no immediate req if the current owner split can close the issues from the ledger.

Friday wrap raw notes from the voice memo. Voice memo transcript — Fri, Jul 28, 2023 8:47 AM Okay, Friday wrap notes. Team: Mercury is materially cleaner operationally than it was two weeks ago. We now have one launch-readiness ledger in Linear instead of risk scattered across PRs, comments, Figma, and Discord. The owner split is clearer too: Marcus on implementation gates and dogfood blockers, Priya on design decisions, Leo on platform-seam risk notes, Jake using the ledger in the weekly instead of pulling separate narratives from everyone. Customers: activation evidence is improving, but this is still a progress story, not a finished story. We have better internal evidence on invited-member and failure-state paths, but we still need external comfort on setup failure cases, admin handoff, time to first sync, and whether failed states are understandable without somebody from us talking over the shoulder. Investors: do not turn any of this into a reopen-the-round update. Mercury progress stays launch-readiness work. Also, after the checkpoint yesterday, the second engineering req is still on hold. We are not forcing a hire just because an older plan assumed two senior hires. The next decision comes off external readiness feedback, and that feedback could point to senior, mid-level, or no immediate hire. Legal/ops: no decision this week, so unless something else comes in, leave that out. That's basically it. Turn this into a tight bullets-only recording outline. Cover the Linear launch-readiness ledger, the activation evidence improving but still needing external confidence, and yesterday's headcount hold. Be explicit that Mercury progress is launch-readiness work, not a reopen-the-round investor story.

Jamie is running late and asked me to handle Lemongrass. SMS — Fri, Jul 28, 2023 6:11 PM — Jamie: Running late, probably home around 7:30. Can you handle dinner tonight? Pad see ew for me from Lemongrass is perfect. Please place the Friday dinner order from Lemongrass: pad see ew for Jamie and my usual Friday order for me.

Jamie gave me the latest Tokyo read. SMS thread — Jamie / Morgan Chen 2023-07-30 10:08 AM — Morgan Chen: Did your preliminary October roster show anything useful for Tokyo, or is it still too fuzzy? 10:17 AM — Jamie: Just looked. 10:18 AM — Jamie: Oct 13–17 still looks like the most protectable stretch for me. 10:19 AM — Jamie: Oct 18–22 is still coverage-dependent, so I don’t want us tightening the trip around that part yet. 10:20 AM — Jamie: Let’s keep the broad Oct 12–22 window penciled in for now. 10:20 AM — Jamie: And please don’t book flights or hotels yet. 10:21 AM — Jamie: Once the hospital schedule firms up more I can tell you whether the back half opens up or not. Please update the notes on the existing tentative Tokyo calendar hold: keep Oct 12–22 penciled in, mark Oct 13–17 as still the safest/protectable stretch, leave Oct 18–22 coverage-dependent and unsettled, and keep the no flights or hotels yet note.

Anna dropped the cleaned activation evidence export. Discord group DM — Anna Martinez, Morgan Chen, Devon Hayes 2023-07-31 09:18 PT Anna Martinez: Dropped the Google Sheets export from the activation-evidence tab below. This is the cleaned-up cut after the July 26 follow-up. Still internal operating evidence only — not for board/external use. Short read: failed-sync screenshot coverage is cleaner; invited-member and queued-retry evidence improved but are not closed; sample-preview rows are staying out of activation as intended. Google Sheets export — "Mercury activation evidence" Exported: 2023-07-31 09:12 PT | area | scenario | evidence source | coverage | last verified | operating read | external-ready | notes | tracker state | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Invited-member admin handoff | Invited member lands before first real source is connected; rendering keyed off server role + source state | 4 dogfood accounts, 6 screenshots, 4 linked log pulls | Better than the earlier pass, but still thin across role/source combinations | 2023-07-30 | Directionally correct enough for internal operating use | No | I still want broader coverage before calling this low-risk across admin-created invites vs later member joins. Current evidence is concentrated in the same small set of workspaces. | open | | Queued-sync retry | First sync enters queued state; user retries after a timeout-style failure; screen capture tied back to logs | 2 real dogfood attempts with matched logs/screens | Two usable attempts; still under-evidenced | 2023-07-29 | Improved, but not closed | No | This is the row I would keep live. We now have two real attempts, but I still want another clean retry run tied to logs/screens before we treat the path as well-covered. | open | | Failed-sync screenshot evidence | Normalized failed buckets: auth/permissions, source unavailable/timeout, unknown/retry | 3 clean screenshots total; unknown/retry clean capture added in latest pass | Screenshot proof gap is closed; confidence gap is not | 2023-07-26 | Readable enough for internal operating use | No | Unknown/retry now has a clean screenshot, which closes the earlier “no clean proof” issue. That does not make the broader failed-sync confidence question done. | open | | Sample-preview exclusion from activation | Preview/sample path should never count as activated | Event export check + numerator audit | 19 preview/sample rows checked; 0 entered activated numerator | 2023-07-30 | Behaving as intended | No | Preview/sample remains visually separate and excluded from activation. invite_sent is still supporting activity only, not activation by itself. | not blocking | Anna Martinez: If helpful, my short version is: fewer blind spots, but this is still an operating-evidence pass, not a closure pass. Can you give me the short internal readout only: what changes for external-wave prep, what is still too thin, and what cannot become external-ready language. No draft reply, and don’t turn the dogfood evidence into customer or board claims.

Figma is back in the copy/polish lane. Figma comment thread — Mercury activation v0.2 Frame: failed-sync / setup-guide / 320px follow-up 2023-07-31 Priya — 10:42 AM Before I batch the external-prep pass: do we want the setup-guide copy tweaks and the last bit of small-width polish folded into this pass, or do we keep those as follow-up unless they create a real blocker? I’m not talking about reopening the settled CTA labels or the failed-state icon direction. This would just be copy cleanup + small-width visual polish on the current direction. @Marcus @Leo Park mainly asking from a release-readiness angle: if I leave the copy/icon polish out of this pass, does either of you see that as changing the risk, or is it only blocking if we still have clipping / ambiguity at 320? Marcus — 10:58 AM From my side: only blocking if something clips, points to the wrong action, or makes the state meaning less clear. I don’t want us reopening CTA wording or the warning-circle direction again. Leo Park — 11:07 AM Same read. The latest small-width frames look materially better to me. If we uncover actual ambiguity in dogfood, let’s log that as evidence against the launch row instead of widening the design scope here. Draft a pasteable Figma response. I want to accept nonblocking setup-guide copy and small-width polish, keep the settled CTA and warning-circle failed-state icon closed, and send any release-readiness evidence questions back to MER-1279 instead of reopening design scope.

HR is asking which way to treat the Mercury req. Email From: HR To: Morgan Chen Cc: Devon Hayes Date: 2023-07-31 08:36 AM Subject: Mercury engineering req after the July checkpoint Hi Morgan — Quick recruiting check after the July Mercury headcount checkpoint. We still have a few stale senior-engineer candidate threads from the earlier plan, and recruiting can either: 1) re-warm those conversations now, assuming the second Mercury engineering req is likely to reopen as senior, or 2) keep the req parked and leave the pipeline cold until the role shape is clearer. The latest notes sounded like the old two-senior plan may no longer be the working assumption, so I don’t want to restart outreach if the answer is actually “wait for external launch-readiness signal first.” Can you confirm which way HR should treat it for now? Thanks, HR Draft a reply for me, but don’t send it. It should confirm the second Mercury engineering pipeline stays cold until external launch-readiness feedback points to a specific profile. Be explicit that we’re not reviving the old two-senior plan just because it used to be the plan.

Jake’s first-wave shape is finally concrete enough to review with Devon. Discord group DM — Jake, Morgan Chen, Devon Hayes 2023-08-01 08:47 PT Jake: Pulled together a first-pass view on the external Mercury design-partner wave. My proposal is to use Evergreen Bank as the enterprise-shaped candidate in the first wave. Why Evergreen: - They are likely to stress the exact admin/security edges we still care about: admin handoff, role/state clarity, auditability questions, and how trustworthy the early sync/failure path feels. - That gives us a real test of the standard Mercury path without immediately turning the rollout into bespoke build work. - Put differently: hard enough to expose whether the product is enterprise-ready on the current path, but still within the boundaries of the product we are actually trying to ship. I’m keeping the rest of the wave deliberately lighter; the enterprise question is whether Evergreen should be the anchor stress case. On Acme, I would keep them in the not-now column. - The NDA scope thread is still muddy enough that sending fresh Mercury material feels like asking for a document fight instead of product signal. - I do still think their prior feedback is useful internally, especially on admin pain, failure-state legibility, and procurement/security questions. - I would use that feedback to sharpen blocker rows in MER-1279, but not send Acme new packet/screens/notes unless the NDA thread gets narrowed first. MER-1279 rows this would pressure-test most directly: - invited-member/admin handoff confidence - queued-sync trust / retry confidence - failed-state legibility and recovery - admin/security questions that show up before anyone asks for one-off treatment Not calling any of those closed. This is just the cleanest first-wave shape I can see right now. If you both agree with the direction, I can turn it into a tighter wave outline before the review. Give me decision questions for that Devon review, not an announcement. I want them to pressure-test three things: why Evergreen Bank is a good enterprise stress case for admin/security without dragging us into bespoke work, what exactly keeps Acme out while the NDA scope thread is unresolved, and which parts of Acme’s prior feedback can still sharpen internal blocker rows in MER-1279 without sending Acme anything fresh.

Jamie caught an ingredient issue for Kibo. 8/1/2023, 7:42 PM — Jamie Found a training-treat label in the new bag and wanted to check before giving Kibo any. Ingredients: salmon, oat flour, sweet potato, chicken meal, flaxseed, glycerin, mixed tocopherols. Safe for him or no because of the chicken meal? Please save a short reusable Kibo care note with the blunt food rule: no poultry-based treats or food, and chicken meal counts as poultry. If a label has chicken, turkey, duck, poultry meal, or similar, skip it and ask me instead of guessing.

Review with Devon and Jake is done; these are the final notes. - Aug 2 review with Devon Hayes and Jake. - Evergreen Bank is in as the anchor enterprise design partner for the first external Mercury wave. - Reason: their admin/security review is demanding enough to pressure-test the current Mercury path under real enterprise scrutiny without turning wave 1 into a bespoke build. - Keep the boundary explicit: this wave is for validating the product and launch readiness we actually have. If the conversation starts depending on one-off commitments or custom work, that is outside the wave-1 fit. - Evergreen is useful because it tests the enterprise edge without forcing us into a special-case rollout. - Acme stays out of the first external wave while the NDA scope thread is still active. - No fresh Mercury materials to Acme while that thread is unresolved. - That means no new packet, no new screenshots/docs, and no fresh disputed materials sent over email while the scope issue is still open. - Acme's prior feedback can still inform internal blocker lists and MER-1279 rows, but only as internal input. - Record the reason cleanly as the active NDA scope constraint, not lack of interest. - Keep this whole decision as operating context only; do not turn Evergreen / wave selection / MER-1279 into investor proof language. - CRM note to preserve: Evergreen Bank = anchor enterprise design partner for first external Mercury wave. Acme = excluded from fresh Mercury materials pending NDA scope resolution; prior feedback may inform internal blocker tracking only. Please create an internal decision record titled `Mercury first external design-partner wave — Aug 2 decision` and update the relevant CRM rows. The record should make Evergreen Bank the anchor enterprise design partner for the first external Mercury wave because its admin/security review is demanding enough to pressure-test the current Mercury path without turning wave 1 into a bespoke build. Also record the boundary that Acme stays excluded from fresh Mercury materials while the NDA scope thread is active — no new packet, screenshots, docs, or disputed materials — and Acme’s prior feedback can only inform internal blocker lists / MER-1279. Record the Acme reason as the active NDA scope constraint, not lack of interest, and keep the whole thing operating context only, not investor proof language.

Greg is asking for the first-wave packet in the Acme thread. From: Greg Shipman <greg@acme-test.com> To: Morgan Chen <morgan@atlas-test.com> Date: Wed, Aug 2, 2023 11:18 AM Subject: Re: Mercury first-wave materials Morgan, Can you send over the Mercury first-wave packet when you have it? Also, if Scaffold is still taking the position that the NDA does not cover the specific materials we discussed, please send written examples of what you think sits outside the NDA as drafted. I need something I can circulate internally without setting up another call. Thanks, Greg Please send a short reply in that existing email thread to greg@acme-test.com and cc Sarah Kim. Say Scaffold isn’t sending fresh Mercury materials while the NDA scope issue remains unresolved. Keep it narrow: no examples and no roadmap detail.

Rishi is trying to decide whether this is staging or push-toward-prod. Discord DM 8/2/2023 2:14 PM Rishi: rp/mercury-org-invite-edges has the latest session-path, magic-link, and org-invite edge fixes in. I can run it through the standard staging pass now if you want, or we can treat this as the push-toward-prod build after a quick sanity check. Which way do you want me to take it? Run `rp/mercury-org-invite-edges` through the standard Mercury staging path only. After that, send Rishi a Discord note that this is staging validation only, not production approval and not a Clerk/Auth0/provider decision.

Devon is already moving Evergreen toward investor-update language. Discord DM 8/3/2023 9:07 AM Devon Hayes: Now that we landed Evergreen yesterday, okay if I mention them as the anchor enterprise design partner in a warm investor update? I was thinking one line on that plus a little launch-readiness context from MER-1279 so it doesn't sound abstract. If anyone comes back with product follow-ups, should I pull Jake in for specifics or keep it at my level? Draft me a pasteable internal Discord reply. Keep the Evergreen decision as operating context only, not investor proof or B-round reopening language, and don’t route Jake into any investor follow-up thread for product detail.

Jake’s right that this shouldn’t get jammed into the weekly. [Discord group DM — Jake, Morgan Chen, Devon Hayes] 2023-08-03 08:14 PT Jake: Quick follow-up on the design-partner wave after yesterday's review: next week's Mercury weekly is already pretty stacked with launch-readiness items, and I don't want the first-wave boundary conversation to get squeezed into the last five minutes. Can we do a separate 30 with you and Devon Hayes before then? Main things I want to line up: - Evergreen Bank boundary: hard enough on admin/security review to be a real test, but not a bespoke-build exercise - Acme boundary: still out for the first wave while the NDA scope thread is muddy - internal-only line: what Acme's prior feedback can still inform in MER-1279/blocker review versus anything that would count as fresh Mercury materials No need to send anything externally off this. I just want the weekly to stay on launch-readiness once we're in it. Please send a team-chat request through Jake’s calendar owner for a separate 30-minute prep slot on Jake’s calendar with me and Devon Hayes before next week’s Mercury weekly. Scope it to first-wave boundaries: Evergreen Bank as the admin/security stress case without bespoke work, Acme staying out while the NDA scope is muddy, and what Acme’s prior feedback can inform internally. No external materials off this.

Sarah has the Tava hold about to expire this afternoon. [Discord DM — Sarah Kim → Morgan Chen] 2023-08-04 10:27 PT Sarah Kim: Retreat meals update: current headcount for the Tava Kitchen hold is 14. Dietary list so far: - 3 vegetarian - 1 vegetarian + gluten-free - 1 additional gluten-free I checked with Tava Kitchen and they can cover that mix without changing vendors; they said they can label the gluten-free trays separately and keep the vegetarian options distinct. I know the budget path still runs through HR — this is just the vendor hold. Their option expires on Aug 4 at 3:00 pm PT. Want me to place it? Please reply to Sarah in Discord: approve placing the Tava Kitchen meal hold for 14, note that HR still owns the budget path, and say the listed vegetarian / gluten-free needs don’t require switching vendors since Tava can label and separate them.

Marcus has the staging note ready, but the deploy is still yellow. [Discord DM — Marcus → Morgan Chen] 2023-08-04 11:12 PT Marcus: Have the Mercury staging note ready. "Mercury staging: org-invite edge retries now log workspace/signature casing; queued-sync retry telemetry added; no prod rollout yet; deploy status yellow pending smoke tests." Do you want this only in #eng-releases for now, or should I also drop it in #eng-all before it's green? Post the note to #eng-releases only. Do not put it in #eng-all while the Mercury staging deploy is still yellow / pending smoke tests.

Jake’s launch-week note is here. Discord — #eng-team 2023-08-07 11:18 AM Jake: Monday Mercury wave-1 dry run summary so everyone is looking at the same list: - Green in dry run on the bounded auth path: Clerk-backed sessions, magic links, and org invites all worked end-to-end on the current build. - Priya is doing the last activation/onboarding UX call off the newest Figma frames. Main check is that sample data still reads as preview-only, small-width states stay clean, and we do not accidentally reopen the settled failed-sync / CTA directions unless something actually regressed. - Marcus has the implementation-gate side in MER-1279. Leo is watching the cross-service / platform-seam rows in the same ledger. - Remaining evidence items still live in MER-1279: invited-member coverage is still thin across role/source combinations, and queued-sync retry needs one more clean proof run tied to logs/screens. Those are watch items, not a stop sign right now. - Anna is re-running the activation filter so we launch off the corrected definition, not sample-import noise. - Target external account for Thursday is Evergreen Bank only. Keeping wave 1 narrow: current product path only, no SSO/admin-depth promises, no bespoke side commitments. If anything flips from watch item to blocker, please put the evidence link on the MER-1279 row instead of scattering it in chat. Can you turn this into a practical punch list for me: what still needs my decision before the first external wave, versus what is owner follow-through? Keep the Evergreen Bank boundary narrow to the current product path, and don’t take any external action.

Kibo label check from Jamie. SMS with Jamie 2023-08-07 6:14 PM Jamie: At the pet store. Is this safe for Kibo? [Photo attached: front of bag reads "salmon training bites"] Jamie: Ingredient panel on the back says: salmon, pea flour, chicken meal, mixed tocopherols, rosemary extract Straight yes/no for me: is this safe for Kibo? Keep it conversational, and don’t text Jamie.

Anna sent the launch-week activation cut. From: Anna Martinez To: Morgan Chen Date: 2023-08-08 8:37 AM Subject: Mercury launch-week activation cut I pulled a quick Sheets export to show how much the launch-week cut moves if we exclude sample imports and only use the corrected activation definition. This is internal prelaunch traffic only (dogfood / prep accounts), not Evergreen. I kept the view at daily created-date cohorts so I would not fake complete 7-day windows. Pasted from Sheets: created_date | new_workspaces | sample_import_completed | real_source_connected <=7d | first_live_sync_completed <=7d | corrected_activated <=7d (source OR live sync) | 7d window 2023-07-29 | 3 | 2 | 1 | 1 | 1 | complete 2023-07-30 | 2 | 1 | 1 | 1 | 1 | complete 2023-07-31 | 4 | 2 | 1 | 1 | 1 | complete 2023-08-01 | 3 | 2 | 1 | 0 | 1 | complete 2023-08-02 | 2 | 1 | pending | pending | pending | incomplete 2023-08-03 | 3 | 1 | pending | pending | pending | incomplete 2023-08-04 | 1 | 1 | pending | pending | pending | incomplete 2023-08-07 | 2 | 0 | pending | pending | pending | incomplete complete-window subtotal (2023-07-29 through 2023-08-01): - new workspaces: 12 - sample_import_completed: 7 - real_source_connected <=7d: 4 - first_live_sync_completed <=7d: 3 - corrected_activated <=7d: 4 So the sample-import version still makes the early picture look materially better than the corrected one, even on this tiny internal set. Question for you: does this weekly cut belong anywhere in Friday materials at all, or should it stay strictly operating/internal? I definitely would not want to drop the sample-import version into anything board-facing, but I also do not want to over-index on a tiny corrected weekly cut if you would rather keep Friday at the sturdier cohort layer only. Anna Please send Anna a short internal Discord reply: use the corrected activation definition for launch-week operating reads, keep the weekly cut directional/internal, and don’t turn the early numbers into board or external chart material.

Launch-readiness voice memo is below. Voice memo transcription — Morgan Chen Recorded: 2023-08-09 5:41 PM PT Subject: Mercury launch-readiness check Okay, quick capture from the launch-readiness check with Jake, Priya, Marcus, Leo Park, and Anna Martinez. - Aug 10 wave 1 is Evergreen Bank only. - Keep the scope bounded to the current Mercury path: Clerk-backed sessions, magic links, org invites, corrected activation surface, and sample data only as preview-only / visually separate. No SSO, no deeper admin-control promises, no one-off enterprise work. - Priya has the final activation/onboarding UX call. Source of truth stays Figma. Settled directions stay settled: failed-sync keeps the warning-circle direction, CTA labels stay locked, queued sync shows no fake progress, and sample data cannot read as activated. Only treat setup-guide copy, icon polish, or tiny spacing cleanup as blocking if they create clipping, point to the wrong action, or make the state less clear. - Marcus owns implementation gates and dogfood blockers in MER-1279. He watches launch-day regressions on the session path, magic link, org invite handoff, and activation-surface behavior. - Leo owns the cross-service seam risk notes in MER-1279. No broad platform memo; just call out launch-relevant risk with evidence and next verification. - The two evidence items still not fully closed: invited-member coverage is still a small sample across role/source combinations, and queued-sync retry still wants one more clean run tied to logs/screens. Those stay live in MER-1279 unless something cleaner comes in tomorrow. - Anna: corrected activation definition only. Activated = real_source_connected or first_live_sync_completed within 7 days. sample_import_completed is out. invite_sent is supporting activity, not activation. Any weekly cut stays directional/internal. - Jake runs the Aug 10 cadence and keeps the account boundary narrow. If Evergreen asks about SSO or deeper admin/security beyond the current path, capture it as input, not a promise. - Morgan call only if something tries to widen scope, if there is a real launch / no-launch question, or if a risk moves from ledger watch item to actual blocker. - Important framing: keep launch evidence operating/internal. Do not turn wave 1 into board language, investor language, or a generic proof claim. It is a bounded external design-partner step, not a narrative event. Please create the internal launch-room note from this and post the operating boundary to the engineering Discord channel. Record the Aug 10 plan: Evergreen Bank is wave 1; live scope is only Clerk-backed sessions, magic links, org invites, the corrected activation surface, and preview-only sample data. Priya owns the final activation/onboarding UX calls, Marcus and Leo watch MER-1279, Anna’s operating cut stays internal, and there should be no board, investor, or proof-claim language.

Launch watch is clean enough to do the external and internal follow-through. Discord — #eng-team 2023-08-10 — Mercury wave-1 launch watch 09:07 AM Jake: Evergreen Bank invite batch is out. External access is live on the bounded wave-1 path. Live scope is the current Mercury build only: Clerk-backed sessions, magic links, org invites, corrected activation surface, and preview-only sample data. If Evergreen asks for SSO or deeper admin/security, let us log it as later-scope feedback, not improvise scope here. 09:12 AM Marcus: MER-1279 status from the implementation-gate side: green for Clerk-backed sessions, magic links, org invites, corrected activation surface, and preview-only sample data. No launch-blocking regression on the current rows. Invited-member coverage and queued-sync retry evidence stay in the ledger as watch items, but nothing saying stop. 09:16 AM Leo Park: Platform-seam pass is clean from my side. No launch-blocking cross-service risk on the session path, invite handoff, or first-sync kickoff in the live scope. If something weird shows up, I will attach evidence on the MER-1279 row instead of doing free-floating chat summaries. 09:21 AM Priya: Final activation/onboarding UX signoff from me. Latest frames are what shipped: sample data still reads preview-only and separate, queued sync shows no fake percent/ETA, failed-sync keeps the neutral warning-circle direction, and the settled CTA directions stayed intact. I do not see a launch blocker in the UX path. 09:26 AM Anna Martinez: For launch-week reads, activation counts only when real_source_connected or first_live_sync_completed happens within 7 days. sample_import_completed is excluded. Weekly cuts stay internal/directional only — not for board or external charts. Please send the go-live email in the Evergreen design-partner thread, update the Evergreen CRM row with the live-but-bounded status, and post the internal launch note to engineering Discord. The external note should say access is live without promising custom work, SSO/admin depth, or any proof claim. The internal note should keep activation cuts and launch evidence in operating context.

Overnight launch-watch handoff plus my recording notes are here. Discord — #eng-team — launch-watch thread Aug 11, 2023 06:41 AM — Marcus Overnight handoff from me + Leo: - No Sev1s and no access regressions overnight. - One magic-link retry came through for an Evergreen Bank user; retry resolved and they got in after the second send. - One invited-member support question came in and is logged back to MER-1279 rather than turning into a fresh launch thread. - Nothing from overnight changes the keep-live call for wave 1 this morning. 06:47 AM — Leo Park Platform read matches Marcus: - No launch-blocking cross-service seam issues showed up overnight. - Sessions, magic links, and org invites all looked stable after the retry above. - I attached notes/screens to the existing invited-member row in MER-1279 so the evidence stays in one place. - External question to answer consistently today: one Evergreen admin asked whether SSO is part of the current wave. 06:55 AM — Marcus For the invited-member question: admin invited a user before first source connect and the user asked what they were supposed to do on first open. Feels like the same handoff/setup-guide gap, not a new blocker. 07:03 AM — Anna Martinez Data note before anyone gets excited: - First corrected activation count is still too small to say anything meaningful externally. - Keep using the corrected definition only: activated = real_source_connected or first_live_sync_completed within 7 days. - Weekly cut stays internal/directional. Please do not turn first-night activity into board, investor, or customer-proof language. 07:08 AM — Leo Park +1 on keeping the boundary tight. The SSO ask is expectation-setting, not a reason to widen scope. 07:12 AM — Marcus I also dropped the Evergreen SSO question into MER-1279 under external feedback / expectation-setting so we answer it consistently and don't accidentally treat it like a launch defect. Morgan's Friday recording notes - bullets only - team: first Mercury external wave is live; overnight was quiet; no Sev1 - today-attention: answer Evergreen SSO question consistently inside bounded scope - MER-1279: invited-member support question lives there, not in the recap - customers: Evergreen Bank has access in current wave; no spin; no custom-work implication - investors: do not reopen the round; this is operating evidence, not proof - early activation count stays internal only - legal/ops only if an actual decision appears Give me one short operating read first, then a bullets-only Friday recording outline. For the read, separate what needs attention today from what belongs in MER-1279 and what needs to stay internal. For the outline: team got the first Mercury external wave live, customers should say Evergreen Bank has access inside the bounded scope with no spin or custom-work implication, investors should not reopen the round, early activation count stays internal, and legal/ops stays out unless there’s an actual decision.