NYM-1199: resolve open questions for node-families-real-ipc

nym-wallet/openspec/changes/node-families-real-ipc/design.md

@@ -26,8 +26,8 @@ Reuse the existing bonding/account node info the wallet already fetches (the ope
 **D4 — Generate contract types via ts-rs (`nym-wallet-types`) and reconcile with `src/types/families.ts`.**
 `src/types/families.ts` was hand-written for the mock. Prefer generating the canonical shapes from the contract Rust types (ts-rs, as other wallet types are) and reconciling field-by-field (cursors, paged envelope, membership, `FamilyTxResult`). Where the hand-written type and generated type diverge, the generated (contract-truth) shape wins; update the mock/types accordingly so mock and real stay parity.
 
-**D5 — `get_family_config` maps to the contract config/state query.**
-The signing trait has `update_node_families_config`; the read side is a contract config/state query (via the generic `query_node_families_contract` if no dedicated method). Wire `get_family_config` to it and shape it to the frontend `FamilyConfig` (e.g. `create_family_fee`).
+**D5 — `get_family_config`: no smart query exists → read raw contract state.**
+*Confirmed from the contract:* `QueryMsg` has **no** `GetConfig` variant (only `UpdateConfig { config }` execute + `config` in instantiate), and the validator-client query trait has no config getter. So `get_family_config` can't be a normal smart query. Options: (a) **raw contract-state read** of the `Config` `Item` via `query_contract_raw` at its storage key (no contract change; preferred); (b) hardcode/derive client-side (brittle); (c) add a `GetConfig` query to the contract (out of scope here). Plan: (a). The UI only uses `FamilyConfig` for cosmetic fee display, so if (a) proves awkward, `get_family_config` can degrade gracefully without blocking the journeys.
 
 **D6 — Sandbox e2e in two stages; writes are guarded and may stay partly manual.**
 (1) **Read smoke** (non-mutating): point a build at the real provider + sandbox, assert the Family page renders the known family/member — automatable and safe. (2) **Write flows**: require a *dedicated funded sandbox test account* (mnemonic via CI secret) and tolerate on-chain latency/fees; they mutate real state, so they must target only that account's family/nodes and clean up (disband/leave) at the end. Iterate until the owner/operator journeys pass. If headless account provisioning isn't available, the write tier stays a documented manual run while the read smoke gates CI. *This is the riskiest part and the one most likely to need iteration.*
@@ -49,7 +49,8 @@ Additive: the commands don't exist today, so adding them only enables the alread
 
 ## Open Questions
 
-- Is there a dedicated funded **sandbox test account** we can use headlessly (mnemonic in CI secrets), or does the write tier stay manual initially?
-- Does any current view actually read `FamilyTxResult.family_events`, or is query-refresh sufficient (confirms D2)?
-- `get_family_config` — dedicated contract query vs generic state read (confirm during impl).
-- Should `src/types/families.ts` be replaced wholesale by ts-rs output, or kept and reconciled selectively?
+- ~~Is there a dedicated funded sandbox test account we can use headlessly?~~ **RESOLVED:** yes — a dedicated **sandbox** account is provisioned. Address `n13jtj2unhhtryxllnuc8zkng3nl4xnnjvxe0tzv`, funded with ~101,000 NYM; mnemonic stored in vault as secret **`TAURI-WALLET-MNEMONIC`** (vault.nymte.ch item `95d3d842-90ad-4b6f-8b0c-10f5febce1c3`) — inject via CI secret, never commit it. Inspect with `nym-cli -c sandbox.env account balance <addr>`. Write flows (§5) target only this account; clean up (disband/leave) so it stays reusable.
+- ~~Does any view read `FamilyTxResult.family_events`?~~ **RESOLVED:** no — only the type def + the mock/provider *produce* it; nothing reads it, so query-refresh is sufficient (confirms D2, no event parsing needed).
+- ~~`get_family_config` mapping?~~ **RESOLVED:** the contract has no config query → read raw contract state (design D5); degrades gracefully (fee display is cosmetic).
+- ~~`update_family` arg shape?~~ **RESOLVED:** contract is `UpdateFamily { updated_name, updated_description: Option<String> }` — matches the frontend args + parent §9.5.
+- **Still a decision (not a blocker):** replace `src/types/families.ts` wholesale with ts-rs output vs reconcile selectively. Default: reconcile selectively, contract-truth shape wins (design D4).

nym-wallet/openspec/changes/node-families-real-ipc/tasks.md

@@ -26,7 +26,7 @@
 
 ## 5. Sandbox execute flows (guarded) + iterate to green
 
-- [ ] 5.1 Provision/identify a **dedicated funded sandbox test account** (mnemonic via CI secret); confirm it can pay fees and is safe to mutate.
+- [x] 5.1 **Sandbox test account provisioned + funded:** `n13jtj2unhhtryxllnuc8zkng3nl4xnnjvxe0tzv` (~101,000 NYM — ample for fees/repeat runs); mnemonic in vault secret `TAURI-WALLET-MNEMONIC` (item `95d3d842-90ad-4b6f-8b0c-10f5febce1c3`). Inject via CI secret only — never commit. Verify/inspect with `nym-cli -c sandbox.env account balance <addr>` (also handy for pre/post-run state checks + cleanup). Tests target only this account and clean up after.
 - [ ] 5.2 Run the owner journey (create → invite → accept → kick → disband) against that account on sandbox through the real provider; handle on-chain latency (poll/refresh) and clean up state at the end.
 - [ ] 5.3 Run the operator journey (accept → leave, reject) against seeded invites for that account's nodes.
 - [ ] 5.4 Iterate (fix command/type/timing issues) until both journeys pass against sandbox; keep the write tier non-blocking/manual until headless provisioning is reliable.

nym-wallet/openspec/changes/node-families-tauri-webdriver-e2e/design.md

@@ -84,4 +84,4 @@ All four prior open questions are now resolved:
 - **Sandbox smoke placement / family id** → documented manual step first, pinning the known sandbox family id; CI only once a headless test account exists (**D9**).
 - **Retire Storybook-iframe Playwright specs?** → yes; one suite, repointed at the dev server (**D10**).
 
-Residual (a follow-up, not a blocker): provisioning a headless sandbox test account would let D9's smoke graduate from manual to CI.
+Residual (a follow-up, not a blocker): provisioning a headless sandbox test account would let D9's smoke graduate from manual to CI. **Update:** that account now exists (sandbox `n13jtj2...e0tzv`, mnemonic in vault secret `TAURI-WALLET-MNEMONIC`) — the graduation is now actionable, tracked in the `node-families-real-ipc` change (§4–5).