wative-core 2.4.1 → 2.4.3

package/examples/17-locked-state.test.cjs

@@ -1,12 +1,4 @@
-// 17 — Locked-state contract. Locking is the library's core safety promise:
-// once locked, nothing that touches key material may succeed. The other
-// examples lock at the end of a test but never assert what locking actually
-// enforces, so a regression that left a decrypted key in memory would not fail
-// any of them.
-//
-// This file pins the contract from the outside: which operations refuse, which
-// error code they refuse with, that they hand back no secret material while
-// refusing, and that unlocking restores exactly the previous behaviour.
+// 17 — What locking enforces: which operations refuse, with which code, and unlock parity.
 
 const test = require("node:test");
 const assert = require("node:assert");
@@ -42,15 +34,7 @@ async function freshAccount(tag) {
   return { ws, account, wallet, address };
 }
 
-/**
- * Assert an operation refuses with the given code.
- *
- * The API deliberately mixes shapes: signing and key export are synchronous
- * (they only touch already-decrypted material), while anything that persists or
- * decrypts is async. Wrapping the call in an async function normalises a
- * synchronous throw and a rejected promise into one thing, so these assertions
- * describe the security contract rather than the call shape.
- */
+/** Assert an operation refuses with the given code, sync throw or rejection alike. */
 async function refuses(code, label, operation) {
   await assert.rejects(
     async () => operation(),
@@ -74,8 +58,6 @@ test("a locked account refuses every operation that needs key material", async (
   await refuses("ACCOUNT_LOCKED", "signTypedData", () => address.signTypedData(TYPED_DATA));
   await refuses("ACCOUNT_LOCKED", "deriveWallets", () => account.deriveWallets(1));
 
-  // Refusing with the correct password supplied is the point: possession of the
-  // password must not be enough to bypass the lock.
   await ws.unlock("wsp-pwd").catch(() => {});
 });
 
@@ -88,7 +70,6 @@ test("locking the workspace blocks workspace-level mutation too", async () => {
   await refuses("WORKSPACE_LOCKED", "accounts.create", () =>
     ws.accounts.create("Other", "wsp-pwd", MNEMONIC),
   );
-  // Accounts held from before the lock must not keep signing.
   await refuses("ACCOUNT_LOCKED", "signMessage on a stale handle", () =>
     address.signMessage("hello"),
   );
@@ -102,8 +83,6 @@ test("a locked account exposes no plaintext secret through its own surface", asy
 
   await account.lock();
 
-  // Walk everything reachable from the locked account — the object graph is
-  // cyclic (workspace ⇄ account ⇄ wallet), so track visited objects.
   const strings = [];
   const seen = new Set();
   const walk = (value) => {

package/examples/18-envelope-v3.test.cjs

@@ -1,15 +1,4 @@
-// 18 — HybridProviderV3 and the v3 envelope, through the published package.
-//
-// This file exists because the publish gate could not see the release's
-// headline feature at all. Every other example opens a workspace with
-// `Workspace.open({ path })`, which uses the default provider and writes v2, so
-// disabling v3 in all four built bundles — making `HybridProviderV3` silently
-// write v2 records — passed the entire 54-test suite. The same mutation fails
-// the source suite loudly, so the gap was exactly at the packaging boundary,
-// which is the one thing this gate exists to cover.
-//
-// The subpath `wative-core/node` also re-exports the class; that resolution is
-// covered by example 15.
+// 18 — HybridProviderV3 and the v3 envelope, exercised through the published package.
 
 const test = require("node:test");
 const assert = require("node:assert");
@@ -17,11 +6,7 @@ const { mkdtempSync, readFileSync, readdirSync, statSync } = require("node:fs");
 const { tmpdir } = require("node:os");
 const { join } = require("node:path");
 
-// Both from the SAME entry point, which is what the README documents and what
-// the cross-entry-point guard enforces: each entry is its own bundle with its
-// own class identities, so a Workspace from one cannot accept a provider from
-// the other. `wative-core/node` re-exports the provider classes but not
-// Workspace, so pairing them comes from here.
+// Both from the SAME entry point — each entry is its own bundle with its own classes.
 const { Workspace, HybridProviderV3 } = require("wative-core");
 
 const MNEMONIC =
@@ -60,10 +45,6 @@ test("HybridProviderV3 writes v3 records, and they all share one salt", async ()
     );
   }
 
-  // The container salt is the 16 bytes after the version byte. v3's whole point
-  // is that every record shares it, which is what collapses N derivations into
-  // one; v2 mints a fresh salt per record, so this is also what distinguishes
-  // the two formats beyond the version byte alone.
   const saltOf = (rel) => readFileSync(join(root, rel)).subarray(1, 17).toString("hex");
   const salts = new Set(names.map(saltOf));
   assert.strictEqual(salts.size, 1, `expected one container salt, got ${salts.size}`);

package/examples/19-simple-provider.test.cjs

@@ -1,14 +1,4 @@
-// 19 — The SHORT way to write a storage backend.
-//
-// Example 07 extends `Provider` and implements the record layer by hand, which
-// is what you want when the storage system already has its own encryption or
-// its own idea of a record. Most of the time you want this instead: extend
-// `ContainerProvider` and implement six methods that move bytes around. It
-// supplies the container session, the record API and all the encryption, so a
-// working backend is about twenty lines.
-//
-// The store here is a plain Map with no persistence and no cleverness — the
-// point is how little you have to write, not the store itself.
+// 19 — The short way to write a backend: extend ContainerProvider, move bytes, done.
 
 const test = require("node:test");
 const assert = require("node:assert");
@@ -21,8 +11,6 @@ class MapProvider extends ContainerProvider {
   #dirs = new Set([""]);
 
   _exist(path) {
-    // A directory "exists" if anything sits under it — the library asks about
-    // both files and directories through this one method.
     if (this.#store.has(path) || this.#dirs.has(path)) return true;
     const prefix = path.endsWith("/") ? path : path + "/";
     for (const k of this.#store.keys()) if (k.startsWith(prefix)) return true;
@@ -70,7 +58,6 @@ test("a twenty-line backend runs a whole workspace", async () => {
   let ws = await Workspace.open({ provider, password: "wsp-pwd" });
   assert.strictEqual(ws.locked, false);
 
-  // The built-in networks are there, exactly as with any other backend.
   assert.ok(ws.networks.map((n) => n.slug).includes("ethereum"));
 
   const acc = await ws.accounts.create(
@@ -81,7 +68,6 @@ test("a twenty-line backend runs a whole workspace", async () => {
   await acc.deriveWallets(2);
   assert.strictEqual(acc.wallets.length, 3);
 
-  // An address, and a signature from it — the full stack, on a Map.
   const evm = acc.wallets[0].evm;
   assert.match(evm.publicKey, /^0x[0-9a-fA-F]{40}$/);
   const sig = await evm.signMessage("hello from a Map");
@@ -89,7 +75,6 @@ test("a twenty-line backend runs a whole workspace", async () => {
 
   await ws.lock();
 
-  // Reopen from the same store: everything came back.
   ws = await Workspace.open({ provider, password: "wsp-pwd" });
   const again = ws.accounts.bySlug(acc.slug);
   assert.ok(again);
@@ -101,9 +86,6 @@ test("a twenty-line backend runs a whole workspace", async () => {
 });
 
 test("the encryption comes with the base class, not with your code", async () => {
-  // Nothing above encrypts anything, yet nothing readable reaches the store.
-  // That is the reason to extend `ContainerProvider`: a backend cannot weaken
-  // the encryption because a backend never performs it.
   const provider = new MapProvider("map://opaque");
   const ws = await Workspace.open({ provider, password: "wsp-pwd" });
   await ws.accounts.create(

package/examples/README.md

@@ -33,7 +33,7 @@ All tests work fully offline — no RPC calls, no real networks. Each test creat
 |---|---|
 | [01-quick-start.test.cjs](01-quick-start.test.cjs) | Open a workspace, create an HD account, derive 5 wallets, inspect EVM + Solana addresses, lock. |
 | [02-hd-account.test.cjs](02-hd-account.test.cjs) | HD-specific flows — deriving / slicing wallets, dumping the mnemonic, account-level passwords with `resetPassword`, round-trip across lock + reopen. |
-| [03-pk-account.test.cjs](03-pk-account.test.cjs) | PK accounts — creating from a private key, importing more keys (mix EVM + Solana under one account), duplicate-import rejection, dropping wallets. |
+| [03-pk-account.test.cjs](03-pk-account.test.cjs) | PK accounts — creating from a private key, importing more keys, and the three key formats accepted (EVM hex, Solana base58, `solana-keygen` JSON) with the chain inferred from the key. Also shows each import producing an address on both chains, duplicate-import rejection, and dropping wallets. |
 | [04-network-management.test.cjs](04-network-management.test.cjs) | The 10 pre-loaded networks, adding a brand-new network, overriding a pre-loaded RPC URL via `update()`, dropping user networks, the built-in protection guard. |
 | [05-asset-management.test.cjs](05-asset-management.test.cjs) | The 25 pre-loaded tokens, adding a custom user token, id collision rejection, contract-address collision rejection, dropping user tokens, `workspace.filter(q, "Asset")` search. |
 | [06-address-signing.test.cjs](06-address-signing.test.cjs) | Personal-message signing on EVM and Solana, building a transaction fully offline (no RPC). |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "wative-core",
-  "version": "2.4.1",
+  "version": "2.4.3",
   "description": "Hyperscale crypto wallet management library — multi-workspace, multi-chain, originally designed for on-chain market makers",
   "type": "module",
   "main": "./dist/index.node.cjs",