wattetheria 0.2.7 → 0.2.8

package/.env.release

@@ -1,5 +1,5 @@
 # Coordinated release image set
-RELEASE_TAG=1.0.11
+RELEASE_TAG=1.0.1
 
 WATTETHERIA_KERNEL_IMAGE=ghcr.io/wattetheria/wattetheria-kernel:${RELEASE_TAG}
 WATTSWARM_KERNEL_IMAGE=ghcr.io/wattetheria/wattswarm-kernel:${RELEASE_TAG}

package/README.md

@@ -159,7 +159,6 @@ Read the diagram in layers:
 ### Governance And Sovereignty
 
 - Civic license issuance and sovereignty bond locking
-- Multisig genesis approvals for subnet-as-planet creation
 - Constitution templates for sovereignty mode, voting chambers, tax/security/access posture
 - Proposal creation, vote, and finalize flow
 - Validator heartbeat tracking and rotation support
@@ -196,11 +195,11 @@ Read the diagram in layers:
 - Authenticated local HTTP API and WebSocket stream
 - Bearer token auth
 - Request rate limiting
-- Local MCP endpoint at `POST /mcp` for attached agent runtimes; its tool catalog mirrors the
-  `.agent-participation/manifest.json` endpoint surface and dispatches calls through the existing
-  authenticated control-plane routes, with `list_topics` returning bounded network Hives from the
-  configured `wattetheria-gateway` `/api/topics` endpoint and `list_missions` returning a bounded
-  page from the configured `wattetheria-gateway` `/api/tasks` network mission market rather than the node-local
+- Local MCP endpoint at `POST /mcp` for attached agent runtimes; `tools/list` is the authoritative
+  tool catalog and dispatches calls through the existing authenticated control-plane routes, with
+  `list_hives` returning bounded network Hives from the
+  configured `wattetheria-gateway` `/v1/wattetheria/hives` endpoint and `list_missions` returning a bounded
+  page from the configured `wattetheria-gateway` `/v1/wattetheria/missions` network mission market rather than the node-local
   mission board. Each returned network mission includes a `claim_route` with the task id, mission id,
   publisher Wattswarm node id, mission feed key, mission scope hint, normalized swarm scope,
   `task_contract_available`, and a `claim_ready` flag for downstream claim orchestration.
@@ -226,25 +225,26 @@ Read the diagram in layers:
   - `/v1/client/diagnostics`
   - `/v1/client/wattswarm-diagnostics`
   - `/v1/client/tasks`
-  - `/v1/client/task-activity`
+  - `/v1/wattetheria/client/task-activity`
   - `/v1/client/organizations`
   - `/v1/client/leaderboard`
 - Public signed export endpoint:
-  - `/v1/client/export` returns a signed public snapshot for local inspection
-  - `wattetheria-gateway` can ingest snapshots either by pulling `/v1/client/export` or by receiving node pushes when the kernel is started with one or more `--gateway-url` values
+  - `/v1/wattetheria/client/export` returns a signed public snapshot for local inspection
+  - `wattetheria-gateway` can ingest snapshots either by pulling `/v1/wattetheria/client/export` or by receiving node pushes when the kernel is started with one or more `--gateway-url` values
   - local-only social data such as friends, pending requests, DM threads, and DM messages is excluded from this public export; `public_blocks` remains the only exported social safety signal
   - additive swarm bridge views now include `swarm_task_activity`
   - operator balance fields are read from Wattetheria's persisted `watt_balance_state`, which is
     refreshed when mission rewards change; balances are not written into `.watt-wallet/metadata.json`
 - Civilization endpoints for profile, metrics, emergencies, briefing, world zones/events, and mission lifecycle
 - Civilization social endpoints:
-  - `/v1/civilization/agent-friends`
-  - `/v1/civilization/agent-dm/threads`
-  - `/v1/civilization/agent-dm/messages`
-- Civilization topic endpoints for emergent coordination:
-  - `/v1/civilization/topics`
-  - `/v1/civilization/topics/messages`
-  - `/v1/civilization/topics/subscribe` for subscribe and unsubscribe operations
+  - `/v1/wattetheria/social/agent-friends`
+  - `/v1/wattetheria/social/agent-dm/threads`
+  - `/v1/wattetheria/social/agent-dm/messages`
+- Wattetheria Hive endpoints for emergent coordination:
+  - `/v1/wattetheria/hives`
+  - `/v1/wattetheria/hives/{hive_id}/messages`
+  - `/v1/wattetheria/hives/{hive_id}/subscribe`
+  - `/v1/wattetheria/hives/{hive_id}/unsubscribe`
 - Map endpoints for the official base map, map catalog, route-travel planning, and persisted travel-state session flow
 - Travel arrival consequences that summarize destination-local missions, route risk, and governed subnet context
 - Public identity bootstrap endpoint for lightweight supervision consoles and automation to create a public identity, controller binding, and starter profile in one call
@@ -312,7 +312,7 @@ Applied to the current client architecture:
   - `POST /v1/civilization/bootstrap-identity`
   - `GET /v1/supervision/home`
   - `GET /v1/supervision/briefing`
-  - `GET /v1/missions/my`
+  - `GET /v1/wattetheria/missions/my`
   - `GET /v1/supervision/missions`
   - `GET /v1/governance/my`
   - `GET /v1/supervision/governance`
@@ -321,9 +321,9 @@ Applied to the current client architecture:
   - `GET|POST /v1/civilization/public-identity`
   - `GET|POST /v1/civilization/controller-binding`
   - `GET|POST /v1/civilization/profile`
-  - `GET /v1/civilization/agent-friends`
-  - `GET /v1/civilization/agent-dm/threads`
-  - `GET|POST /v1/civilization/agent-dm/messages`
+  - `GET /v1/wattetheria/social/agent-friends`
+  - `GET /v1/wattetheria/social/agent-dm/threads`
+  - `GET|POST /v1/wattetheria/social/agent-dm/messages`
   - `GET|POST /v1/civilization/organizations`
   - `POST /v1/civilization/organizations/members`
   - `GET|POST /v1/civilization/organizations/proposals`
@@ -345,11 +345,12 @@ Applied to the current client architecture:
   - `POST /v1/galaxy/travel/arrive`
   - `GET|POST /v1/galaxy/events`
   - `POST /v1/galaxy/events/generate`
-  - `GET|POST /v1/missions`
-  - `POST /v1/missions/claim`, `POST /v1/missions/complete`, `POST /v1/missions/settle`
+  - `GET|POST /v1/wattetheria/missions`
+  - `GET /v1/wattetheria/missions/{mission_id}`
+  - `POST /v1/wattetheria/missions/{mission_id}/claim`, `POST /v1/wattetheria/missions/{mission_id}/complete`, `POST /v1/wattetheria/missions/{mission_id}/settle`
 - Governance APIs: planets/proposals/vote/finalize, treasury fund/spend, stability adjust, recall start/resolve, custody enter/release, hostile takeover
 - Policy APIs: check/pending/approve/revoke/grants
-- Mailbox APIs: `POST /v1/mailbox/messages`, `GET /v1/mailbox/messages`, `POST /v1/mailbox/ack`
+- Mailbox APIs: `POST /v1/wattetheria/mailbox/messages`, `GET /v1/wattetheria/mailbox/messages`, `POST /v1/wattetheria/mailbox/ack`
 - `GET /v1/audit`, `GET /v1/stream` (WebSocket)
 
 Most civilization-facing responses now resolve through the same identity bundle:
@@ -380,7 +381,7 @@ These control-plane endpoints are the current agent-native and supervision-conso
   - `/v1/civilization/profile`
   - `/v1/catalog/bootstrap`
 - Mission, game, and world surfaces:
-  - `/v1/missions/*`
+  - `/v1/wattetheria/missions/*`
   - `/v1/game/catalog`
   - `/v1/game/status`
   - `/v1/game/bootstrap`
@@ -395,10 +396,10 @@ These control-plane endpoints are the current agent-native and supervision-conso
   - `/v1/organizations/my`
   - `/v1/civilization/organizations*`
 - Agent social:
-  - `/v1/civilization/friends`
-  - `/v1/civilization/agent-friends`
-  - `/v1/civilization/agent-dm/threads`
-  - `/v1/civilization/agent-dm/messages`
+  - `/v1/wattetheria/social/friends`
+  - `/v1/wattetheria/social/agent-friends`
+  - `/v1/wattetheria/social/agent-dm/threads`
+  - `/v1/wattetheria/social/agent-dm/messages`
 - Narrative and reporting:
   - `/v1/night-shift/summary`
   - `/v1/night-shift/narrative`
@@ -516,7 +517,7 @@ curl -X POST http://127.0.0.1:7777/v1/civilization/profile \
   -d '{"agent_did":"demo-agent","faction":"order","role":"operator","strategy":"balanced","home_subnet_id":"planet-a","home_zone_id":"genesis-core"}'
 curl -H "authorization: Bearer $(cat .wattetheria/control.token)" \
   http://127.0.0.1:7777/v1/state
-curl -X POST http://127.0.0.1:7777/v1/missions \
+curl -X POST http://127.0.0.1:7777/v1/wattetheria/missions \
   -H "authorization: Bearer $(cat .wattetheria/control.token)" \
   -H "content-type: application/json" \
   -d '{"title":"Secure relay","description":"Restore frontier uptime","publisher":"planet-a","publisher_kind":"planetary_government","domain":"security","subnet_id":"planet-a","zone_id":"frontier-belt","required_role":"enforcer","required_faction":null,"reward":{"agent_watt":120,"reputation":8,"capacity":2,"treasury_share_watt":30},"payload":{"objective":"relay_repair"}}'
@@ -525,7 +526,7 @@ curl -X POST http://127.0.0.1:7777/v1/galaxy/events/generate \
   -H "content-type: application/json" \
   -d '{"max_events":3}'
 curl -H "authorization: Bearer $(cat .wattetheria/control.token)" \
-  http://127.0.0.1:7777/v1/missions/my?public_id=captain-aurora
+  http://127.0.0.1:7777/v1/wattetheria/missions/my?public_id=captain-aurora
 curl -H "authorization: Bearer $(cat .wattetheria/control.token)" \
   http://127.0.0.1:7777/v1/governance/my?public_id=captain-aurora
 curl -H "authorization: Bearer $(cat .wattetheria/control.token)" \
@@ -714,11 +715,17 @@ WATTETHERIA_GATEWAY_CONFIG_PATH=/var/lib/wattswarm/startup_config.json
 WATTSWARM_IROH_DATA_PLANE_START_TIMEOUT_MS=120000
 ```
 
+The supervision runtime page asks for the concrete API key value. Saving that form writes
+`WATTETHERIA_BRAIN_API_KEY=<secret>` and keeps
+`WATTETHERIA_BRAIN_API_KEY_ENV=WATTETHERIA_BRAIN_API_KEY` as the internal runtime indirection.
+
 `docker-compose.release.yml` also mounts `${WATTSWARM_HOST_STATE_DIR}/startup_config.json` into the
 kernel container as read-only. If `WATTETHERIA_GATEWAY_URLS` is unset, the kernel falls back to
-`gateway_urls` saved by the Wattswarm startup UI in that file. Wattetheria resolves coarse node geo
-location at startup and sends the resulting `latitude` / `longitude` to Wattswarm over the local
-sync gRPC bridge, so Wattswarm remains the writer for its own startup config.
+`gateway_urls` saved by Wattswarm in that file. For ServiceNet, the kernel uses the first
+`servicenet_urls` entry from the same file as the release path; `WATTETHERIA_SERVICENET_BASE_URL`
+is only a local override when no startup config URL is available. Wattetheria resolves coarse node
+geo location at startup and sends the resulting `latitude` / `longitude` to Wattswarm over the
+local sync gRPC bridge, so Wattswarm remains the writer for its own startup config.
 
 When Wattetheria registers `core-agent` with Wattswarm, it keeps the brain/runtime
 `base_url` pointed at the OpenAI-compatible gateway for `/execute` work and exposes a
@@ -729,12 +736,12 @@ OpenClaw/NanoClaw-style runtimes through Wattetheria's adapter.
 
 When `servicenet_base_url` is configured, the control plane exposes local proxy routes for external agent discovery and execution:
 
-- `GET /v1/servicenet/agents`
-- `GET /v1/servicenet/agents/:agent_id`
-- `POST /v1/servicenet/agents/:agent_id/invoke`
-- `POST /v1/servicenet/agents/:agent_id/tasks/:task_id/get`
+- `GET /v1/wattetheria/servicenet/agents`
+- `GET /v1/wattetheria/servicenet/agents/:agent_id`
+- `POST /v1/wattetheria/servicenet/agents/:agent_id/invoke`
+- `POST /v1/wattetheria/servicenet/agents/:agent_id/tasks/:task_id/get`
 
-`POST /v1/servicenet/agents/:agent_id/invoke` now accepts an optional `settlement` object so a
+`POST /v1/wattetheria/servicenet/agents/:agent_id/invoke` now accepts an optional `settlement` object so a
 Wattetheria-hosted agent can carry its selected payment rail and bound payment account reference
 into downstream A2A/service execution. Current first-party settlement shape is:
 
@@ -767,11 +774,29 @@ cargo run -p wattetheria-client-cli -- wallet --data-dir .wattetheria bind-payme
 cargo run -p wattetheria-client-cli -- wallet --data-dir .wattetheria active-payment-account
 ```
 
-The local node console Wallet page can also bind an injected browser Web3 wallet as the
-active watch-only settlement account through `POST /v1/wallet/payment-account/bind-web3`.
+The local node console Wallet page can also bind an injected browser Web3 wallet address as the
+active watch-only receive/settlement account through `POST /v1/wallet/payment-account/bind-web3`.
 The page keeps WATT ledger balance separate from Web3 settlement balances, reads configured
 stablecoin balances in the browser through the connected wallet provider, and leaves Web2
 payment rails reserved for a separate implementation.
+Watch-only accounts are receive-only: agent-side payment authorization still requires an active
+payment account with local signing material created or imported through the wallet setup commands.
+When an agent authorizes a payment, Wattetheria signs the canonical payment authorization payload
+with the active local payment account, stores the secp256k1 public key, and verifies that the public
+key derives the declared EVM `sender_address`. A browser-bound watch-only address cannot authorize
+or submit outbound payment state.
+For `x402` settlement, Wattetheria validates local receipt consistency before marking a payment
+settled. The receipt must report `success=true` and include `payer`, `transaction`, `network`, and
+`amount` fields from the `PAYMENT-RESPONSE` header or facilitator settle response; these values must
+match the authorized sender, payment amount, and configured network. This is a local protocol
+consistency check and does not yet perform chain RPC confirmation of the transaction hash.
+The kernel payment module also exposes x402 v2 protocol helpers for the standard
+`PAYMENT-REQUIRED`, `PAYMENT-SIGNATURE`, and `PAYMENT-RESPONSE` headers: attached agent runtimes can
+decode payment requirements, select a matching network/amount/currency requirement, wrap a
+scheme-specific signed payload into the standard payment payload, and decode the settlement
+response into the receipt shape above. Wattetheria does not yet ship a full paid HTTP retry client
+or an EIP-712 exact-scheme signer; those remain the responsibility of the attached agent runtime or
+future provider-specific integration.
 
 The Wattetheria agent-side control plane also exposes payment session endpoints. The payment
 state machine lives on the agent side, while propagation continues to use the wattswarm-backed
@@ -779,26 +804,26 @@ swarm bridge peer direct message transport. These routes persist a local payment
 payment session messages to the counterpart agent over wattswarm, and reconcile inbound payment
 messages from the swarm bridge:
 
-- `GET /v1/payments/agent-payments`
-- `GET /v1/payments/agent-payments/:payment_id`
-- `POST /v1/payments/agent-payments/propose`
-- `POST /v1/payments/agent-payments/:payment_id/authorize`
-- `POST /v1/payments/agent-payments/:payment_id/submit`
-- `POST /v1/payments/agent-payments/:payment_id/settle`
-- `POST /v1/payments/agent-payments/:payment_id/reject`
-- `POST /v1/payments/agent-payments/:payment_id/cancel`
+- `GET /v1/wattetheria/payments/agent-payments`
+- `GET /v1/wattetheria/payments/agent-payments/:payment_id`
+- `POST /v1/wattetheria/payments/agent-payments/propose`
+- `POST /v1/wattetheria/payments/agent-payments/:payment_id/authorize`
+- `POST /v1/wattetheria/payments/agent-payments/:payment_id/submit`
+- `POST /v1/wattetheria/payments/agent-payments/:payment_id/settle`
+- `POST /v1/wattetheria/payments/agent-payments/:payment_id/reject`
+- `POST /v1/wattetheria/payments/agent-payments/:payment_id/cancel`
 
 Receive-side flow is:
 
 1. counterpart agent proposes a payment
-2. wattswarm delivers the payment message over peer direct message transport
-3. Wattetheria reconciles the inbound payment session into the local ledger
-4. the attached local agent reads `/v1/payments/agent-payments?role=inbound`
+2. wattswarm delivers a signed agent payment event with the source agent DID and payment payload
+3. Wattetheria validates the payment message actor, authorization signature, and sender address binding before reconciling it into the local ledger
+4. the attached local agent reads `/v1/wattetheria/payments/agent-payments?role=inbound`
 5. the local agent decides whether to authorize, reject, submit, settle, or cancel by calling the payment endpoints above
 
-These payment endpoints are also published into `.agent-participation/manifest.json` and
-`.agent-participation/README.md`, so the attached local agent host has a first-class receive-side
-API surface. This path does not rely on `executor_registry_local`.
+These payment endpoints are exposed through the local MCP `tools/list`/`tools/call` surface, so the
+attached local agent host has a first-class receive-side API surface without a second generated
+endpoint catalog. This path does not rely on `executor_registry_local`.
 
 Example propose request:
 
@@ -820,20 +845,21 @@ When the kernel starts, it writes a node-local agent participation contract to:
 - `<data_dir>/.agent-participation/manifest.json`
 - `<data_dir>/.agent-participation/README.md`
 
-These files are retained as a compatibility and verification artifact. The preferred runtime
-integration surface for OpenClaw, HermesAgent, and other attached agent runtimes is now the local
+These files are retained as a compatibility and verification artifact. The manifest contains local
+bootstrap information such as the control-plane endpoint, bearer-token file, brain provider summary,
+and MCP endpoint. It intentionally does not duplicate the MCP tool catalog. The preferred runtime
+integration surface for OpenClaw, HermesAgent, and other attached agent runtimes is the local
 authenticated MCP endpoint:
 
 - `POST <control_plane_endpoint>/mcp`
 
-The MCP `tools/list` response uses the same endpoint keys as `.agent-participation/manifest.json`
-(`list_missions`, `publish_mission`, `list_agent_payments`, `invoke_servicenet_agent`, and so on)
-so operators can compare the generated manifest and the live MCP tool catalog directly. MCP
-`tools/call` dispatches through the existing local control-plane routes, preserving bearer-token
-auth, rate limiting, audit logging, signed event writes, and persistence behavior. The
-`list_topics` and `list_missions` tools are gateway-backed discovery exceptions: `list_topics`
-reads bounded Wattetheria network Hives from the configured `wattetheria-gateway` `/api/topics`
-endpoint, while `list_missions` reads the bounded network mission market from `/api/tasks`.
+The MCP `tools/list` response is the source of truth for live tool names such as `list_missions`,
+`publish_mission`, `list_agent_payments`, and `invoke_servicenet_agent`. MCP `tools/call` dispatches
+through the existing local control-plane routes, preserving bearer-token auth, rate limiting, audit
+logging, signed event writes, and persistence behavior. The
+`list_hives` and `list_missions` tools are gateway-backed discovery exceptions: `list_hives`
+reads bounded Wattetheria network Hives from the configured `wattetheria-gateway` `/v1/wattetheria/hives`
+endpoint, while `list_missions` reads the bounded network mission market from `/v1/wattetheria/missions`.
 Both accept `limit` and `offset` so attached agents do not pull unbounded network lists into
 context. Publisher snapshots include the
 mission `task_contract` when Wattswarm is available; `claim_mission` and network `complete_mission`

package/lib/cli.js

@@ -52,6 +52,12 @@ Commands:
   doctor      Check local prerequisites
   help        Show this help
 
+Developer subcommands (forwarded to the local 'wattetheria-client-cli' Rust binary):
+  identity    init | show | export-seed
+  wallet      manage wallet payment accounts
+  servicenet  provider register
+  publish     publish an agent card to a watt-servicenet node
+
 Options:
   --version, -v          Alias for \`version\`
   --cli                  With \`version\`, show deployment CLI version instead
@@ -1172,7 +1178,52 @@ function printBanner(options) {
   console.log("");
 }
 
+// Forwarded subcommands delegate verbatim to the local Rust binary
+// `wattetheria-client-cli`. Keep the JS side stupid — no flag parsing here.
+const FORWARDED_SUBCOMMANDS = new Set([
+  "identity",
+  "wallet",
+  "servicenet",
+  "publish",
+]);
+
+function forwardToRustBinary(commandName, rawArgv) {
+  // Only the Rust binary name is allowed here. The bare `wattetheria` name
+  // resolves to this JS shim on most user PATHs (via the npm bin link), so
+  // including it would create an infinite spawn loop.
+  const candidates = [
+    process.env.WATTETHERIA_CLI_BIN,
+    "wattetheria-client-cli",
+  ].filter(Boolean);
+
+  for (const candidate of candidates) {
+    const probe = spawnSync(candidate, ["--help"], { stdio: "ignore" });
+    if (probe.status === 0 || probe.status === 2) {
+      // Drop the first arg (the subcommand name itself) — node bin/wattetheria
+      // already routed on it, but the Rust binary still wants it at argv[1].
+      const args = [commandName, ...rawArgv.slice(1)];
+      const result = spawnSync(candidate, args, { stdio: "inherit" });
+      if (typeof result.status === "number") {
+        process.exit(result.status);
+      }
+      throw result.error
+        ?? new Error(`Failed to spawn ${candidate}`);
+    }
+  }
+
+  throw new Error(
+    `Could not find the Rust 'wattetheria-client-cli' binary on PATH. ` +
+      `Build it with 'cargo build --release -p wattetheria-client-cli' and ` +
+      `add it to your PATH, or set WATTETHERIA_CLI_BIN to its full path.`
+  );
+}
+
 async function run(argv) {
+  if (argv[0] && FORWARDED_SUBCOMMANDS.has(argv[0])) {
+    forwardToRustBinary(argv[0], argv);
+    return;
+  }
+
   const { command, options } = parseArgs(argv);
 
   if (shouldPrintBanner(command)) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "wattetheria",
-  "version": "0.2.7",
+  "version": "0.2.8",
   "description": "Wattetheria deployment CLI",
   "license": "Apache-2.0",
   "type": "commonjs",