test: cover connected account claim entitlement

[sage-ddd]

Adds focused regression coverage for the connected-wallet claim path.

What changed:

• verifies ClaimSDK.checkEntitlement() resolves getWhitelistedRoot(connectedAccount) first
• verifies the SDK calls checkEntitlement(address) with the resolved root account, while keeping the connected wallet as the active account
• covers the same behavior through getWalletClaimStatus()

Why:

• issue Refactor: support connected accounts for claiming flow #24 is specifically about connected wallets claiming through their whitelisted root identity
• current main already has the core root-address entitlement path, so this locks that behavior down without changing runtime code unnecessarily

Validation:

• HOME=$PWD/.yarn-home YARN_GLOBAL_FOLDER=$PWD/.yarn-home/global YARN_CACHE_FOLDER=$PWD/.yarn/cache node .yarn/releases/yarn-4.6.0.cjs workspace @goodsdks/citizen-sdk vitest run test/claim-connected-account.test.ts
• HOME=$PWD/.yarn-home YARN_GLOBAL_FOLDER=$PWD/.yarn-home/global YARN_CACHE_FOLDER=$PWD/.yarn/cache node .yarn/releases/yarn-4.6.0.cjs workspace @goodsdks/citizen-sdk build

Closes #24

Summary by Sourcery

Add regression tests to verify connected wallets check claim entitlement against their whitelisted root account.

Tests:

• Add coverage ensuring ClaimSDK.checkEntitlement() resolves entitlement using the whitelisted root account while retaining the connected wallet as the active account.
• Add tests confirming getWalletClaimStatus() uses the same root-address entitlement path for connected accounts.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• The two tests duplicate a lot of setup for publicClient, walletClient, identitySDK, and ClaimSDK construction; consider extracting a small factory/helper to create a configured SDK + mocks so future tests for connected-account behavior stay DRY and easier to adjust.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The two tests duplicate a lot of setup for `publicClient`, `walletClient`, `identitySDK`, and `ClaimSDK` construction; consider extracting a small factory/helper to create a configured SDK + mocks so future tests for connected-account behavior stay DRY and easier to adjust.

## Individual Comments

### Comment 1
<location path="packages/citizen-sdk/test/claim-connected-account.test.ts" line_range="51-42" />
<code_context>
+  it("uses the same root-address entitlement path when resolving wallet claim status", async () => {
</code_context>
<issue_to_address>
**suggestion (testing):** Assert that `getWhitelistedRoot` is invoked in the `getWalletClaimStatus` path as well

This test covers the `checkEntitlement` call, but it doesn’t assert that the identity layer is used in this path. To fully capture the intended behavior, please also assert:

```ts
expect(identitySDK.getWhitelistedRoot).toHaveBeenCalledWith(CONNECTED_ACCOUNT)
```

This mirrors the first test and proves that wallet claim status uses the same root-resolution logic, not just the same `readContract` shape.

Suggested implementation:

```typescript
    const status = await sdk.getWalletClaimStatus()

    expect(identitySDK.getWhitelistedRoot).toHaveBeenCalledWith(CONNECTED_ACCOUNT)

```

If the function under test is not named `getWalletClaimStatus` or the variable holding the identity SDK mock is not `identitySDK`, adjust the SEARCH pattern and expectation accordingly. For example:

- If the call is `await citizenSdk.getWalletClaimStatus()`, change the SEARCH line to match that exact call.
- If your identity layer mock is named `mockIdentitySdk` or comes from a factory (e.g. `const identity = createIdentitySDK()`), update the expectation to use that identifier instead of `identitySDK`.

The expectation should stay in this test case (`"uses the same root-address entitlement path when resolving wallet claim status"`) and be placed after the call that triggers the wallet-claim-status resolution so that the mock invocation has already occurred.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

suggestion (testing): Assert that getWhitelistedRoot is invoked in the getWalletClaimStatus path as well

This test covers the checkEntitlement call, but it doesn’t assert that the identity layer is used in this path. To fully capture the intended behavior, please also assert:

expect(identitySDK.getWhitelistedRoot).toHaveBeenCalledWith(CONNECTED_ACCOUNT)

This mirrors the first test and proves that wallet claim status uses the same root-resolution logic, not just the same readContract shape.

Suggested implementation:

    const status = await sdk.getWalletClaimStatus()

    expect(identitySDK.getWhitelistedRoot).toHaveBeenCalledWith(CONNECTED_ACCOUNT)

If the function under test is not named getWalletClaimStatus or the variable holding the identity SDK mock is not identitySDK, adjust the SEARCH pattern and expectation accordingly. For example:

• If the call is await citizenSdk.getWalletClaimStatus(), change the SEARCH line to match that exact call.
• If your identity layer mock is named mockIdentitySdk or comes from a factory (e.g. const identity = createIdentitySDK()), update the expectation to use that identifier instead of identitySDK.

The expectation should stay in this test case ("uses the same root-address entitlement path when resolving wallet claim status") and be placed after the call that triggers the wallet-claim-status resolution so that the mock invocation has already occurred.

[sage-ddd]

Got it, thanks for clarifying. I missed that this had already been resolved through your contributor flow, so I’ll close this PR.