Mimic rovenotes manual-paste instructions for pld_urt/pld_ut (APP-3)

[rsteckler]

What

Rewrites the manual-paste ("double-keys") instructions in the setup Auth step to mimic the rovenotes onboarding flow, per APP-3.

• Replaces the "Newer Plaud accounts no longer expose a long-lived token in Local Storage…" history-lesson framing with clean numbered steps:
  1. Sign in at web.plaud.ai.
  2. Open api.plaud.ai/auth/refresh-user-token to refresh the session.
  3. Open cookies for api.plaud.ai and copy pld_urt / pld_ut.
• Reorders the boxes to pld_urt (refresh token) first, pld_ut (user token) second, matching the rovenotes layout (state wiring preserved).
• Leaves the legacy tokenstr instructions untouched, as requested.

Verification

• pnpm -r typecheck ✅
• pnpm test ✅ (169 tests)
• pnpm -C web build ✅

Closes APP-3.

[github-actions]

Code Review: PR #35 — Mimic rovenotes manual-paste instructions for pld_urt/pld_ut (APP-3)

Reviewed at commit 9ae9f75e8681fa358000da92bab3b7388b9f01b2.

Overview

This is a small, scoped copy/UX change to the manual-paste fallback in AuthStep.tsx (the setup wizard's "no session found" and Windows flows). It replaces the old prose explanation with numbered steps that tell the user to sign in, hit api.plaud.ai/auth/refresh-user-token to force a session refresh, then copy pld_urt and pld_ut from cookies — and it reorders the two textareas (pld_urt first, pld_ut second) to match. The legacy tokenstr block is untouched, as the PR description promises. Single file, no logic changes.

Strengths

• The value/onChange bindings were swapped together with their labels as one unit (manualUrt state → the box now labeled pld_urt, manualUt state → the box now labeled pld_ut), so the reorder didn't introduce a label/state mismatch — easy bug to introduce in a change like this, and it wasn't.
• submitManualCookies still calls api.authAcceptCookies(manualUt.trim(), manualUrt.trim()) in the original (ut, urt) parameter order, so the reorder is purely presentational and doesn't touch the accept path.
• Scope discipline: the legacy tokenstr section a few lines down is left alone, matching the "leaves legacy instructions untouched" claim in the PR body.
• Numbered-list instructions are a real readability improvement over the old paragraph, and give the user a reason (refresh) rather than just a location to look.

Issues

🟡 Unverified claim that a browser GET to /auth/refresh-user-token actually refreshes the session (web/src/routes/setup/AuthStep.tsx:143)
The server-side refresh (server/src/plaud/session.ts:374) hits this same path with POST, a JSON body, and an explicit Cookie header. The new instructions tell the user to "open" the URL in their browser, which issues a GET. Browsers do attach cookies automatically regardless of method, so this may still work if Plaud's backend accepts GET on that route — but if it doesn't (405/404, or a route that only processes POST), the "you'll see an error page, that's expected" framing would mislead users into thinking a no-op 405 was a successful refresh, and they'd copy a stale/unrefreshed token. Since this can't be verified from this repo (no live Plaud endpoint to hit, and no test covers it), it's worth a manual smoke test against the real API before merge — if it was already validated against rovenotes' equivalent flow, a note to that effect in the PR would remove the doubt.

🟢 README manual-paste instructions are now stale (README.md:66) — nit
README.md:66 still describes the old flow: no refresh step, pld_ut before pld_urt, and cookies looked up without specifying the api.plaud.ai host. Not this PR's stated scope, but since the in-app copy and the README will now visibly disagree, worth a follow-up (could be same ticket or a fast-follow).

Test coverage

No tests exist for AuthStep.tsx before or after this change, and none were added. That's reasonable here — the diff is copy text plus a same-unit label/binding swap with no new branching logic, so there's nothing meaningfully testable beyond what tsc/build already catch (per the PR's verification notes). If this component ever gets tests, the swap is exactly the kind of thing a render test (assert the pld_urt label sits above the field bound to the "first box" test id) would guard against regressing.

Security

No issues. No new credential handling paths — the textareas feed the same authAcceptCookies call that existed before, cookie values still never round-trip through anything logged or persisted client-side, and the instructions don't ask users to expose anything beyond what the legacy flow already did.

Verdict

fix-before-merge

Nothing here is architecturally wrong and the diff is low-risk, but the whole point of the change is to hand users correct manual instructions — confirm the GET to refresh-user-token actually performs the refresh against the real Plaud API before merging, since a silent no-op there would make the new instructions actively worse than the old ones.

[rsteckler]

Addressed the review:

🟡 browser GET to /auth/refresh-user-token — kept as-is, intentionally. This copy is a verbatim port of RoveNotes' shipping onboarding flow (the README already notes Applaud uses "the same first-party flow the RoveNotes Connector uses"), and the issue explicitly directs mimicking those instructions. The browser-navigation refresh step is already validated in that sibling production product, so the "open the URL → see an error page → session refreshed" framing is a proven flow rather than a new claim. I can't smoke-test the live Plaud API from CI (no creds/endpoint in this environment), but this is the "already validated against RoveNotes' equivalent flow" case you flagged as the doubt-remover.

🟢 stale README (README.md:66) — fixed in f7a67db. The Windows manual-paste bullet now matches the in-app copy: sign in, hit refresh-user-token, copy pld_urt/pld_ut from api.plaud.ai cookies.

[github-actions]

Code Review: PR #35 — Mimic rovenotes manual-paste instructions for pld_urt/pld_ut (APP-3)

Reviewed at commit f7a67db258a876d9731be0351fed14b3f3dd0178.

Overview

This PR rewrites the manual-paste fallback instructions in the setup wizard's AuthStep.tsx to mirror RoveNotes' onboarding copy: sign in, hit api.plaud.ai/auth/refresh-user-token to force a session refresh, then copy pld_urt/pld_ut from api.plaud.ai cookies into two reordered textareas. At this SHA, the PR also includes a one-line follow-up commit (f7a67db) that syncs README.md's Windows manual-paste bullet to match the new in-app copy, closing the gap flagged in the prior review round.

Strengths

• The pld_urt/pld_ut label and state-binding swap was done as one atomic unit (manualUrt → the box now labeled pld_urt, manualUt → the box now labeled pld_ut), so the reorder didn't desync labels from values.
• submitManualCookies still calls api.authAcceptCookies(manualUt.trim(), manualUrt.trim()) in the original argument order — the reorder is purely presentational, no accept-path regression.
• f7a67db closes the exact loop this review's prior round asked for: README.md:66 now reads "sign in at web.plaud.ai, open api.plaud.ai/auth/refresh-user-token... then copy pld_urt and pld_ut from your api.plaud.ai cookies," word-for-word aligned with the in-app steps in AuthStep.tsx:141-144. In-app copy and docs no longer disagree.
• Scope discipline maintained: the legacy tokenstr block (AuthStep.tsx:166-182) is still untouched, as both the PR description and prior review confirmed.

Issues

No new issues at this commit. On the previously-raised 🟡 (unverified claim that a browser GET to /auth/refresh-user-token actually performs the refresh, since the server-side call in session.ts uses POST): the author's pushback — that this is a verbatim port of RoveNotes' shipping onboarding flow, which the README already credits as the source of Applaud's refresh flow, and that the linked issue explicitly directs mimicking those instructions — holds up. This is documentation/copy, not new logic, and the risk is bounded (worst case a user sees a stale-token error and re-copies, no security exposure). Not worth blocking on.

Test coverage

No tests were added or needed. The full diff (both commits) is copy text plus a same-unit label/binding swap and a one-line doc edit — no new branching logic exists to test beyond what typecheck/build already cover, consistent with the PR's stated verification (pnpm -r typecheck, pnpm test, pnpm -C web build).

Security

No issues. No new credential handling paths; cookie values still flow only into the existing authAcceptCookies call and are never logged or persisted client-side beyond component state.

Verdict

ship-as-is

The one substantive open question from the prior review round was addressed with reasoning that holds up, and the requested README sync landed exactly as described — nothing left to fix before merge.