feat: design system + registration/onboarding, integrated

[innolope-dev]

Design system + registration/onboarding, integrated

Lands both in-flight frontend efforts on dev together, in the order that pays the migration cost once:

1. feat: design system release #2813 feat/design-system — the DS release (680 files: tokens + tailwind-4, component consolidation, page rebuilds).
2. feat: reimagined registration and onboarding (residence step, Unlock payments, home checklist, region-restricted screens) #2834 feat/app-registration-onboarding — residence step, Unlock payments, home checklist, region-restricted screens.
3. A migration pass putting feat: reimagined registration and onboarding (residence step, Unlock payments, home checklist, region-restricted screens) #2834's new screens on the semantic tokens, because they were written against the legacy palette that is banned on the DS line.

Merging them separately does not work in either order: whichever lands second has to be re-migrated, and ds-lint blocks #2834 outright once the DS ratchet is on dev. Both source PRs stay open and close when this merges.

Conflict resolution

52 conflict hunks over 40 files. Doctrine throughout, the same one #2813 used for its own dev merges: DS structure wins, behavior is re-applied, never dropped.

The ones worth a reviewer's time:

File	Resolution
TransactionDetailsReceipt.tsx	DS decomposes it 1077 → 247 LoC while dev kept extending the old file. Took the decomposition, re-applied dev's TASK-19830 public-receipt work onto it: official header/footer, issuedAt, and the PDF link moved into ReceiptActions where actions now live.
useReceiptViewModel.ts	Kept dev's meetsShareConditions / shouldShowDownloadPdf. Deleted dev's per-row border machinery: the DS details card owns dividers via divide-y divide-dashed, so shouldHideBorder / shouldHideGroupBorder had no consumer left.
TransactionCard.tsx	DS ListItem rebuild, plus dev's getActionIcon(type, status) signature and inbound-arrow request row.
home/page.tsx	DS shell (<HomePage /> in features/home/). #2834's home work lives in ActivationCTAs, which HomePage already renders — nothing lost.
Profile/index.tsx	#2834's information architecture expressed in DS ListGroups. Payment limits leave the menu (folded inline into Unlock payments), name visibility moves to /profile/edit. The unlock row keeps the DS badge chip over #2834's pulsing dot — one attention language per screen.
UnlockPayments.view.tsx	LimitsProgressBar is deleted on the DS line (one 0_Bruddle/ProgressBar primitive); ported to it with getLimitColorClass, as MantecaLimitsView already does.
CryptoDeposit.view.tsx	DS removal of the offramp deposit path (#2841) stands; dev's newer bridging-variance copy kept for the remaining lane.
capabilities.ts	reason / canRetry were declared twice after the auto-merge — kept the richer CapabilityReason form.
api.openapi.json / api.generated.ts	#2834's, which carries the endpoints from the (now merged) peanut-api-ts#1429. Verified a strict superset of dev's — nothing dropped, exactly /config/residence-restrictions, /manteca/initiate-onboarding and /user/crisp-token added — and pnpm gen:api regenerates byte-identical, so check:api passes.

Two bugs the merge surfaced, fixed rather than papered over

• Truncation regression. The DS ListItem rebuild of TransactionCard broke the min-w-0 shrink chain, so a long counterparty name could push the amount off the row — the exact regression TASK-20700 fixed on dev. Caught by dev's own test once it was re-pointed at the new structure.
• A contradictory test. history.utils.test.ts ended up holding both branches' expectations for the amount sign (DS's "incoming sign-less" and dev's "inflow sign") — a state no single branch ever had. Now consistent with the ruling below.

Two product rulings (Slava, 2026-08-28)

• Incoming amounts carry a +. The states board (17966:12128) draws them unsigned; a signed inflow reads faster in a mixed feed, so dev's TASK-21887 behavior wins. Plain text, not green. Outgoing keeps -; cancelled / failed / refunded stay struck through and sign-less. The board now disagrees with the code and needs updating.
• The generated self-avatar moves onto the avatar board's seven triples (17802:61529), the same set AvatarWithBadge draws initials on — 875 combinations, up from 625, and no raw hex left in the component. Accepted trade-off: the self-avatar no longer reads as visually distinct from the counterparty initials circles beside it.

DS debt: every metric at or below the #2813 baseline

#2834's screens arrived on the legacy palette. Migrated rather than baselined:

metric	after merge	after migration	baseline
legacyColorClasses	84	0	0
consumedUndefinedTokens (dead styles)	3	0	0
stockTextSize	415	362	362
nonDsClassesInViews	144	138	138
rawHex	72	65	65

Two HEX_ALLOW entries rather than baseline bumps: the @react-pdf/renderer receipt (its StyleSheet takes no tailwind tokens) and layout.tsx's Next viewport themeColor, which must be a literal. classNameSitesInPages moves 313 → 314, recorded through --allow-increase with a reason: the receipt page keeps dev's print:hidden nav wrapper for the PDF receipt.

Also on the way through: useResidenceRestrictionSets was calling fetchWithSentry(PEANUT_API_URL…) directly, tripping the DS boundary gate that did not exist when #2834 was written — routed through apiFetch with includeAuth: false. The two transport probes that also trip it (native-canary, network-triage) are exempted with reasons: a bare fetch is the instrument in both, and network-triage needs cors/no-cors modes apiFetch cannot express.

Gates, run locally at the tip

typecheck clean · prettier clean · eslint clean on touched files · ds-lint --check green · next build exit 0 · 4,054 tests across 331 suites (3 skipped), covering src/utils, src/hooks, src/components, src/features, src/context, src/app and src/i18n.

What still needs a human

• Vlad: the states board needs the + on incoming; and the avatar-vs-initials distinction called out above is a design call that can still be reversed here.
• Deploy order: peanut-api-ts#1429 is already merged, so the backend is in place.

[chip-peanut-bot]

Chip review — changes requested

Two previously reported correctness defects remain: bank-request payments still display as incoming, and the residence reorder fixes only the device-local mirror while leaving the durable server pair duplicated.

Findings

• MAJOR · src/utils/history.utils.ts:342 · Bank-request payments are still signed as incoming
  This is unchanged from the prior review. For a Bridge P2P_REQUEST_FULFILL where the viewer is SENDER, the transformer emits bank_request_fulfillment and the receipt calls it "Sent to …", but this mapping renders +$25 even though the payer's balance decreased. Map bank_request_fulfillment to "-" and add a sign regression case for the sender-side Bridge fulfillment.

• MAJOR · src/components/Profile/views/ResidenceChangeModal.tsx:92 · Residence reorder still drops a country on the server
  With primary ES and second FR, selecting FR still calls /update-user with only residenceCountry=FR. The new localStorage swap makes this device show FR/ES, but the endpoint supports secondResidenceCountry and the durable second slot remains FR, so the server pair becomes FR/FR and ES is lost. Compute the swap before the request, submit both fields together, then update both mirrors; assert the request includes secondResidenceCountry=ES.

• MINOR · .github/workflows/tests.yml:445 · [moonshotai/kimi-k3] ds-shots runs PR-controlled Node code with write-scoped GH_TOKEN in env
  In the ds-shots job's 'Publish the changed screenshots' step, GH_TOKEN: ${{ github.token }} (scoped contents: write + pull-requests: write for this job) is exported into the environment of a step that then executes node scripts/visual-comment.mjs from the PR checkout. Any branch pushed to this repo (forks are blocked by ds-shots-filter's head-repo check) that touches scripts/visual-comment.mjs — which the filter regex explicitly counts as pixel-moving — gets that script executed while the token is readable from process.env, so the script can exfiltrate it and push/act on PRs over the API. Additionally, the token is embedded in the git remote URL (https://x-access-token:$GH_TOKEN@github.com/...), which a failed git push can echo into build logs. Fix: run the node listing step without GH_TOKEN in env and authenticate the push without token-in-URL (e.g. git config http.https://github.com/.extraheader "AUTHORIZATION: basic <b64>", or gh CLI), keeping the token materialized only for the push itself.

Inline anchors unavailable for 1 finding(s); the findings remain in this summary.

Checked clean

• Pinned worktree HEAD, trusted author, base ref/SHA, and merge base all match the supplied values.
• Earlier findings: bank-request sign is STILL PRESENT; dual-residence reorder is STILL PRESENT in durable server state despite the local-mirror swap; required ESLint failure is FIXED.
• The two new fix commits and all six files changed since the previous reviewed head were inspected; the DS twMerge import corrections and unused-import removal are sound.
• Bank fulfillment was traced from sender-side Bridge P2P_REQUEST_FULFILL through the transformer, activity sign, receipt title, and tests.
• Dual-residence persistence was traced from signup through /update-user's residenceCountry and secondResidenceCountry fields, local mirrors, refetch, and restriction consumers.
• No additional actionable security, privilege, injection, secret-exposure, or maintainability defect was found in the fix-up delta.
• Exact-head unit, eslint, typecheck, format, ds-lint, human-authors, analyze, report, and aggregate ci-success checks passed; ds-shots remained in progress.
• Targeted local Jest execution was unavailable because this detached worktree has no Jest binary; exact-head unit CI is green.

Second opinion by moonshotai/kimi-k3: 1 finding(s), marked with the model name. It reads the diff only, so treat its findings as advice.

Exact head: 6e4031ff3cb8 · Context: repo, ci

[chip-peanut-bot]

Chip review — changes requested

Request changes: the repeated write-token, bank-fulfillment sign, and cross-device residence findings remain, and exact-head unit CI now aborts before running tests.

Findings

• BLOCKING · .github/workflows/tests.yml:451 · PR-authored code can still reach the write token
  The listing step runs PR-controlled code in the same job that later exports a contents-write GH_TOKEN. A same-repository PR can append a malicious tool directory to $GITHUB_PATH; the publish step then resolves commands such as mkdir or git from that directory while the token is present, allowing it to be exfiltrated or used. Put publication in a base-owned privileged workflow that never checks out or executes the PR head, and accept only strictly validated inert artifacts and filenames.

• MAJOR · src/utils/history.utils.ts:342 · Bank-request payments are still signed as incoming
  For P2P_REQUEST_FULFILL with fulfillmentType: 'bridge' and viewer role SENDER, the transformer maps to bank_request_fulfillment and the receipt says Sent to. This entry still returns +, so a completed $10 bank payment renders +$10 in both the activity row and receipt even though the viewer paid it. Map this direction to - and add a sender-side bridge-fulfillment sign assertion.

• MAJOR · src/components/Profile/views/ResidenceChangeModal.tsx:98 · Residence swaps still depend on device-local state
  readSecondResidence reads only the localStorage mirror, while the durable second slot is not returned by /users/me. A dual resident with server pair ES/FR who opens a new device or clears storage and promotes FR gets previousSecond = null, so isReorder is false and the request sends only residenceCountry: 'FR'; the server pair becomes FR/FR and ES is still lost. Return the durable second residence to this flow or make the backend swap atomically, and cover the missing-mirror case.

• MAJOR · .github/workflows/tests.yml:180 · Unit CI aborts before running the suite
  At this exact head, Fetch BE render-snapshot baseline receives an empty GH_TOKEN; the newly added set -euo pipefail makes gh api exit 4, so Run unit tests never executes and no JUnit or coverage files exist. Provision a credential available to same-repository PR runs or move this baseline fetch behind a trusted artifact-producing workflow, then verify the unit job reaches the test command.

Inline anchors unavailable for 1 finding(s); the findings remain in this summary.

Checked clean

• Earlier workflow-token finding: STILL PRESENT; moving PR-authored listing code to an earlier step does not create a runner trust boundary.
• Earlier bank-request sign finding: STILL PRESENT; sender-side bridge fulfillment still maps to bank_request_fulfillment and receives '+'.
• Earlier residence server-pair fix: FIXED for the device retaining the second-residence mirror, but the broader cross-device dependence remains.
• The latest base-ref shell interpolation in tests, code-analysis, and supply-chain workflows is fixed by passing the ref through environment variables.
• Exact-head format, eslint, typecheck, ds-lint, analyze, human-authors, report, and deploy-preview checks succeeded; unit and aggregate ci-success failed, and advisory ds-shots was still running at review time.
• Exact-head unit logs show the baseline-fetch token is empty and the job exits before any tests run.
• No local Jest run was attempted because the detached worktree has no node_modules; the previous exact-head unit run covered the unchanged application code, and current CI logs were inspected for the workflow-only delta.

Second opinion skipped: daily-budget-reached.

Exact head: 3d3d220ec0e1 · Context: repo, ci

[chip-peanut-bot]

Chip review — changes requested

Request changes: three repeated defects remain. The unit-CI abort is fixed, but the visual job still combines PR code with write access, bank-request fulfillments still display as incoming, and residence swaps still rely on device-local second-residence state.

Findings

• BLOCKING · .github/workflows/tests.yml:308 · PR-controlled visual job retains repository write access
  This job grants contents and pull-request write permissions, then checks out the PR and runs PR-controlled install, build, and test code before placing github.token in a later step. A malicious install script can persist a PATH or GITHUB_ENV hook; when the publish step runs, that hook can read GH_TOKEN and push repository content. A later step in the same job is not an isolation boundary. Run capture in a read-only pull_request workflow and publish validated data from a separate base-controlled workflow_run job that never executes artifact code.

• MAJOR · src/utils/history.utils.ts:342 · Bank-request payer still receives an inflow sign
  bank_request_fulfillment is constructed for the P2P_REQUEST_FULFILL sender/payer, and the receipt describes it as "Sent to". Mapping it to '+' makes a completed $25 bank fulfillment appear as +$25 even though the viewer paid it. Map this direction to '-' and update the sign regression test.

• MAJOR · src/components/Profile/views/ResidenceChangeModal.tsx:98 · Residence swaps still depend on device-local state
  The swap is detected with readSecondResidence(userId), but that mirror is absent on a fresh device. With durable state declared=ES and second=FR, selecting FR on a new device leaves previousSecond null, so only residenceCountry=FR is sent and the server pair becomes FR/FR, losing ES. Return the second residence from users/me or expose an atomic server reorder operation, pass durable state into the modal, and cover the no-localStorage case.

Inline anchors unavailable for 1 finding(s); the findings remain in this summary.

Checked clean

• Earlier unit-CI abort: FIXED; exact-head unit and aggregate ci-success checks passed.
• Earlier write-token exposure: STILL PRESENT in the ds-shots job.
• Earlier bank-request sign defect: STILL PRESENT in DIRECTION_TO_SIGN.
• Earlier cross-device residence swap defect: STILL PRESENT because reorder detection still reads localStorage.
• The only change since the previous reviewed head 3d3d220 is the baseline-fetch handling in tests.yml; it introduced no new application-code behavior.

Second opinion skipped: daily-budget-reached.

Exact head: f17a276a2721 · Context: repo, github-actions-docs

[chip-peanut-bot]

Chip review — changes requested

Request changes: PR-controlled execution still shares jobs with repository-write and cross-repo read tokens, exact-head unit CI still aborts before the suite, and the repeated bank-sign and cross-device residence defects remain.

Findings

• BLOCKING · .github/workflows/tests.yml:309 · PR code still shares a job with a write token
  This remains unchanged after both earlier reviews. The job executes the PR's install/build/visual scripts before later steps receive a contents:write token and a pull-requests:write token. A PR-controlled postinstall can append a tool shim to GITHUB_PATH, then intercept the later token-bearing git invocation; the same trust-boundary problem applies to the comment publisher. Split capture into a read-only job and pass only artifacts to a publisher job that never checks out or executes PR code.

• BLOCKING · .github/workflows/tests.yml:179 · The cross-repo read secret is exposed after PR code runs
  Switching this step to the existing MONO_READ_TOKEN makes a repository secret reachable in a job that has already run PR-controlled checkout, postinstall, and typegen code. For example, a malicious postinstall can prepend a wrapper through GITHUB_PATH; when this fetch later invokes gh, the wrapper receives GH_TOKEN and can exfiltrate every private repository the token can read. Fetch the backend fixture in an isolated no-checkout job and transfer it as an artifact to the unprivileged unit job.

• MAJOR · .github/workflows/tests.yml:193 · Unit CI still aborts before running the suite
  The exact-head unit job fails in this fetch with gh: Not Found (HTTP 404) and base64: invalid input; the Run unit tests step is never reached. MONO_READ_TOKEN is present but is not scoped to peanut-api-ts, so the previous early-abort finding is still present under a new failure mode. Use a credential that can read the backend fixture, or remove/vendor this cross-repo fetch, while keeping the fail-loud behavior.

• MAJOR · src/utils/history.utils.ts:342 · Bank-request payers are still shown an inflow sign
  The bridge P2P-request strategy emits bank_request_fulfillment only for EHistoryUserRole.SENDER, i.e. the viewer paying the request through bank rails. A completed $25 payment therefore renders as +$25 even though the viewer's balance decreased. This repeated finding remains unchanged; map this direction to - and cover the payer case in the sign tests.

• MAJOR · src/components/Profile/views/ResidenceChangeModal.tsx:98 · Residence reorders still depend on device-local state
  Reorder detection still reads the second residence only from localStorage. On a fresh device or with blocked storage, a server pair such as primary ES / second FR has no local second value; selecting FR sets isReorder false and sends only residenceCountry: FR, so the durable pair is not atomically swapped and the outgoing ES country is lost from the pair. Return/pass the server's second residence or make the backend perform the reorder atomically, then test the missing-local-mirror case.

Inline anchors unavailable for 1 finding(s); the findings remain in this summary.

Checked clean

• Verified HEAD and merge base exactly match the supplied head and base SHAs.
• Reassessed all earlier findings: the visual write-token, bank-sign, residence, and unit-suite findings are still present.
• Exact-head unit CI failed before tests because MONO_READ_TOKEN received HTTP 404 from the peanut-api-ts contents endpoint; other exact-head jobs were still running.
• Compared the new drift-check logic against the canonical 49-entry backend fixture: no missing, extra, or reshaped cases were reported.
• Reviewed the three-commit delta since 3d3d220; outside the workflow and render-snapshot test, the repeated behavior defects were unchanged.

Second opinion skipped: daily-budget-reached.

Exact head: b79e429cb938 · Context: repo, ci, product, backend

[chip-peanut-bot]

Chip review — changes requested

Request changes: the isolated backend-baseline job fixes the cross-repo secret exposure and unit-suite abort, but the repeated visual write-token exposure, bank-payment sign, and cross-device residence defects remain.

Findings

• BLOCKING · .github/workflows/tests.yml:333 · PR code still shares a job with a write token
  Still present after two earlier reviews. This job grants contents and pull-request write access, runs PR-controlled install/build/visual code, and later starts a shell with GH_TOKEN. A malicious postinstall can persist BASH_ENV or a GITHUB_PATH shim, then execute when the publish step receives the token and use it with repository-write authority. Split capture into a read-only job and pass validated artifacts to a publisher job that never checks out or executes PR code.

• MAJOR · src/utils/history.utils.ts:342 · Bank-request payers are still shown an inflow sign
  Still present from prior reviews. The bridge P2P-request strategy emits bank_request_fulfillment only when the viewer role is SENDER, meaning the viewer paid the request through bank rails. This mapping still returns '+', so a completed $25 payment renders as +$25 even though the viewer's balance decreased. Map bank_request_fulfillment to '-' and cover the sender-plus-bridge sign case.

• MAJOR · src/components/Profile/views/ResidenceChangeModal.tsx:98 · Residence reorders still depend on device-local state
  Still present from prior reviews. Reorder detection reads the second residence only from localStorage. On a fresh device, a durable server pair ES/FR has no local second value; selecting FR makes isReorder false and sends only residenceCountry=FR, so the pair can become FR/FR and lose ES. Return and pass the server's second residence or make the reorder atomic server-side, then cover the missing-local-mirror case.

Inline anchors unavailable for 1 finding(s); the findings remain in this summary.

Checked clean

• Verified detached worktree HEAD, merge base, trusted author, base ref, and base SHA match the supplied values.
• Earlier cross-repo read-secret finding: FIXED; the fetch now runs in a permissions-empty job with no checkout, install, or PR-authored execution and transfers only an artifact.
• Earlier unit-CI abort finding: FIXED; a missing baseline artifact now skips only the drift import, and the exact-head unit and aggregate CI checks succeeded.
• Earlier visual write-token, bank-sign, and residence-reorder findings: STILL PRESENT and re-reported above.
• The exact-head format, ds-lint, eslint, typecheck, unit, report, human-authors, analyze, and aggregate checks succeeded; advisory ds-shots and the deploy preview were still running when reviewed.
• Focused local Jest execution was unavailable because the detached worktree has no installed dependencies; the relevant current tests and exact-head unit result were inspected instead.

Second opinion skipped: daily-budget-reached.

Exact head: 0797cee325f2 · Context: repo, ci

[chip-peanut-bot]

Chip review — changes requested

Request changes: the visual-job write-token exposure is fixed, but bank-request payments still carry the wrong sign and two local-storage fallbacks still override or ignore the durable second residence.

Findings

• MAJOR · src/utils/history.utils.ts:342 · Bank-request payers are still shown an inflow sign
  This repeated direction bug remains. The bridge request strategy emits bank_request_fulfillment only for userRole: SENDER, and the receipt labels it as sent, but this table returns +. A payer completing a $25 bank request therefore sees +$25 even though they paid it. Map this direction to - and add a direct sign regression case for bank_request_fulfillment.

• MAJOR · src/components/Profile/views/UnlockPayments.view.tsx:488 · An explicit no-second-residence response revives stale device data
  /users/me serializes declaredSecond as either a country or null, but this ?? treats authoritative null like an absent pre-deploy field. If the server has ES/null while this device still stores FR, selecting France passes the stale FR into the modal; the save is classified as a reorder and persists ES as a second residence that the server said did not exist. Fall back only when the property is undefined, clear/sync the mirror when the server field is present, and cover the null-server plus stale-mirror case.

• MAJOR · src/hooks/useResidenceRestrictions.ts:70 · Fresh devices ignore the server's second residence for availability
  The hook still reads the second country only from localStorage even though /users/me now returns residence.declaredSecond. For an unverified dual-resident account with primary RU, second BR, and empty device storage, the server primary restriction is {banking:true, card:true}; this early return skips the intended intersection with unrestricted BR, so both offers remain hidden on a fresh device. Prefer the server field and use the mirror only when that field is undefined, with a server-second/no-mirror regression test.

Inline anchors unavailable for 1 finding(s); the findings remain in this summary.

Checked clean

• Verified the detached worktree HEAD, merge base, trusted author, base ref, and base SHA against the supplied values.
• Earlier visual write-token finding: FIXED — the PR-controlled ds-shots job now has contents:read only and emits artifacts plus a job summary instead of pushing a branch or commenting.
• Earlier bank-request sign finding: STILL PRESENT and re-reported above; the sender-only strategy and outbound receipt wording refute the plus sign.
• Earlier fresh-device residence reorder case: FIXED for a non-null server pair, with request-body coverage; the distinct authoritative-null and availability consumers above remain device-dependent.
• Checked the merged backend contract: residence.declaredSecond is serialized as string-or-null, while residenceRestrictions is derived without the second country.
• Exact-head GitHub checks exposed the completed trusted review and Vercel checks plus skipped manual/ping jobs; required unit, lint, typecheck, and aggregate checks had not registered, so they were not relied on.
• Targeted Jest execution was unavailable because dependencies are absent from the detached worktree; no install was performed in the read-only review tree.
• Diff whitespace validation passed.

Second opinion skipped: daily-budget-reached.

Exact head: 54aab88b4ee8 · Context: repo, ci, peanut-api-ts

[chip-peanut-bot]

Chip review — changes requested

Request changes: payer-side bank-request fulfillments still render as inflows, and the newest residence-authority fix is not propagated to the Unlock screen's region grouping.

Findings

• MAJOR · src/utils/history.utils.ts:328 · Bank-request payers are still shown an inflow
  This earlier finding is still present. For a P2P_REQUEST_FULFILL with fulfillmentType bridge and userRole SENDER, the strategy emits bank_request_fulfillment, but this map returns +. A payer whose balance decreases therefore sees +$10 in history and the receipt. Map this direction to - and add a payer-side sign regression test.

• MINOR · src/components/Profile/views/UnlockPayments.view.tsx:227 · Unlock groups still use the device-only second residence
  The new declaredSecondIso2 correctly resolves server-versus-mirror authority, but the group model still receives secondResidenceIso2. On a fresh device with server declaredSecond: 'BR', South America is not tagged or sorted as Your region; with explicit null plus a stale mirror, the disowned region remains tagged until remount. Pass declaredSecondIso2 here and into the Europe check, and update the memo dependencies.

Checked clean

• Earlier workflow finding FIXED: the PR-executing ds-shots job now has contents: read only, with PR publication isolated from PR-authored code.
• Earlier UnlockPayments mutation finding FIXED: explicit null no longer falls through to the stale mirror for the residence-change modal, and the mirror is cleared from the server answer.
• Earlier useResidenceRestrictions fresh-device finding FIXED: the hook now consumes the server's declaredSecond field and covers both fresh-device and explicit-null cases.
• Exact-head required CI is green, including unit, eslint, typecheck, format, ds-lint, report, and ci-success; advisory ds-shots and deploy preview were still running at review time.
• The exact head and merge base matched the supplied SHAs, the detached worktree was clean, and git diff --check passed.
• Traced the payer-side P2P_REQUEST_FULFILL strategy and adversarially verified the remaining sign failure; reviewed the tip residence commit for authority, stale-state, and memoization paths.

Second opinion skipped: daily-budget-reached.

Exact head: 06550b08beaa · Context: repo, ci

[chip-peanut-bot]

Chip review — no blocking findings — this is not an approval

All supplied earlier findings are fixed at this head, and no new actionable defect remains in the follow-up changes.

Checked clean

• FIXED — bank_request_fulfillment now maps the payer-side transaction to an outflow sign, with pending and completed regression assertions.
• FIXED — Unlock payments groups and the Europe residence check now consume the server-resolved second residence instead of the device-only mirror.
• FIXED — an explicit server null for declaredSecond remains authoritative and no longer revives stale device data.
• FIXED — useResidenceRestrictions now intersects availability with the server's declaredSecond on fresh devices, with coverage for both a server value and explicit null.
• Correctness and adversarial pass traced the bank-request direction from the transaction transformer through history and receipt sign rendering; the payer receives a minus sign in reachable pending and completed states.
• Security pass confirmed the PR-executing visual job remains read-only and the current follow-up commit introduces no workflow or privilege change.
• Exact-head required CI passed: ci-success, unit, typecheck, format, ESLint, ds-lint, human-authors, and analysis are green.
• The advisory ds-shots job failed before build or browser tests because the hosted runner received 403 responses from packages.microsoft.com while installing Playwright system dependencies; this is external to the PR behavior and does not gate ci-success.
• Local targeted tests could not start because the supplied detached worktree has no node_modules; exact-head unit CI completed successfully instead.
• Slop pass on the follow-up commit found the authority-resolution logic centralized and its memo dependencies updated; no dead or duplicate behavior was introduced.

Second opinion skipped: daily-budget-reached.

Exact head: 68fb6b1abc0f · Context: repo