@wowok/agent-mcp 3.0.4 → 3.0.6

package/dist/schemas/onchain_table_data.output.json

@@ -5997,6 +5997,36 @@
                       "additionalProperties": false,
                       "description": "Role evidence derived from the address's on-chain facts (K3 22 §13 P1-7)."
                     },
+                    "follow_ups": {
+                      "description": "Guided follow-ups (INTERACTION FLOOR: always at least 2). Data-driven probes first (permission organizations / order footprint when memberships exist), generic relation probes (public personal profile / reverse map / recent activity) fill up to the floor. Present at least two, numbered, so the user can answer with one short reply.",
+                      "type": "array",
+                      "items": {
+                        "type": "object",
+                        "properties": {
+                          "label": {
+                            "type": "string",
+                            "description": "Short label of the guided follow-up probe."
+                          },
+                          "detail": {
+                            "description": "One line on what the probe answers.",
+                            "type": "string"
+                          },
+                          "call": {
+                            "type": "object",
+                            "propertyNames": {
+                              "type": "string"
+                            },
+                            "additionalProperties": {},
+                            "description": "READY-TO-RUN query_toolkit arguments for this probe — present it to the user so a single short reply runs it."
+                          }
+                        },
+                        "required": [
+                          "label",
+                          "call"
+                        ],
+                        "additionalProperties": false
+                      }
+                    },
                     "service_analysis": {
                       "description": "Service-type analysis merged into the address profile (present for Service addresses).",
                       "anyOf": [
@@ -7668,7 +7698,7 @@
                                   "description": "Forward weight — the contribution this forward makes toward its Pair's threshold. ⚠️ SINGLE-OPERATOR LOCK: a forward contributes its weight AT MOST ONCE. It is locked by the first operator that accomplishes it (progress.move session_accomplish_imp); a second operator re-executing the same accomplished forward aborts E_NOT_THE_HOLDER. Therefore multi-operator cooperation (threshold > 1) needs one DISTINCT forward per contributing operator (e.g. threshold 2 → begin_a + begin_b, each weight 1) — never reuse one forward."
                                 },
                                 "guard": {
-                                  "description": "Guard reference for this forward. Accepts TWO formats:\n• STRING (preferred): \"my_guard_name\" — the Guard's name or address as a plain string.\n• OBJECT (only when retained_submission is needed): {guard: \"my_guard_name\", retained_submission: [1,2,3]}.\nFOLLOW THE SCHEMA FIELD STRUCTURE: A Guard reference is fundamentally a STRING (the Guard object's name or address). Provide a string when you only need to reference a Guard — do NOT wrap a bare string in an object structure. The OBJECT form {guard: \"...\", retained_submission: [...]} exists ONLY to carry additional `retained_submission` data alongside the string reference; inside the object, the `guard` field is STILL a string. In short: string-in for a string reference, object-in only when you need to pass extra data.\nCOGNITIVE PRINCIPLE: Guard validation ALWAYS occurs BEFORE the forward operation. A Guard that queries state of the SAME Progress object this forward operates on (e.g. progress.current) will see the PRE-transition value (source node), NOT the target node. If the Guard checks progress.current == target_node, it will ALWAYS FAIL. Querying a DIFFERENT Progress object (cross-machine) is safe and reasonable — that progress is not modified by this forward. For target-node verification after transition, bind the Guard to the Allocator instead (allocation.alloc runs AFTER the state transition completes).\n⚠️ T1 LOSSY POINT (B-3): WoWok has NO on-chain cron. A business phrase like 'after N days, auto-X' is NOT an automatic trigger — it decomposes into (1) a time_guard that checks elapsed time, and (2) an OFF-CHAIN keeper that must submit the forward when the guard passes. Configuring a time_guard WITHOUT a keeper means nothing ever fires.",
+                                  "description": "Guard reference for this forward. Accepts TWO formats:\n• STRING (preferred): \"my_guard_name\" — the Guard's name or address as a plain string.\n• OBJECT (only when retained_submission is needed): {guard: \"my_guard_name\", retained_submission: [1,2,3]}.\nFOLLOW THE SCHEMA FIELD STRUCTURE: A Guard reference is fundamentally a STRING (the Guard object's name or address). Provide a string when you only need to reference a Guard — do NOT wrap a bare string in an object structure. The OBJECT form {guard: \"...\", retained_submission: [...]} exists ONLY to carry additional `retained_submission` data alongside the string reference; inside the object, the `guard` field is STILL a string. In short: string-in for a string reference, object-in only when you need to pass extra data.\nCOGNITIVE PRINCIPLE: Guard validation ALWAYS occurs BEFORE the forward operation. A Guard that queries state of the SAME Progress object this forward operates on (e.g. progress.current) will see the PRE-transition value (source node), NOT the target node. If the Guard checks progress.current == target_node, it will ALWAYS FAIL. Querying a DIFFERENT Progress object (cross-machine) is safe and reasonable — that progress is not modified by this forward. For target-node verification after transition, bind the Guard to the Allocator instead (allocation.alloc runs AFTER the state transition completes).\n⚠️ T1 LOSSY POINT (B-3): WoWok has NO on-chain cron. A business phrase like 'after N days, auto-X' is NOT an automatic trigger — it decomposes into (1) a time_guard that checks elapsed time, and (2) an OFF-CHAIN keeper that must submit the forward when the guard passes. Configuring a time_guard WITHOUT a keeper means nothing ever fires.\nRETAINED_SUBMISSION: a non-empty retained_submission does NOT relax Guard verification — the forward's Guard is always validated first. The list only selects which of the caller's already-verified submissions are persisted into the Progress history (see the guard field above).",
                                   "anyOf": [
                                     {
                                       "anyOf": [
@@ -7680,7 +7710,7 @@
                                               "description": "Guard object name or address (string). Example: 'my_attendance_guard' or '0x1234...'"
                                             },
                                             "retained_submission": {
-                                              "description": "Data submitted by user during Guard object verification",
+                                              "description": "Guard table identifiers whose verified values are persisted into the Progress history when the forward is accomplished. The Guard is ALWAYS fully verified first (regardless of this list): the forward cannot complete unless the Passport carries a passing result for it. After verification, exactly the caller's submissions for the listed identifiers are copied into history (passport::submissions_get) as Guard-verified facts; empty array (default) records nothing. Use it for audit and downstream queries, never as a way to relax Guard conditions.",
                                               "anyOf": [
                                                 {
                                                   "type": "array",
@@ -8468,7 +8498,7 @@
                                     "additionalProperties": false,
                                     "description": "Guard submission"
                                   },
-                                  "description": "Used to define submitted data after Guard verification"
+                                  "description": "Values persisted into the Progress history when this forward was accomplished. PROVENANCE: when the Machine forward lists retained_submission identifiers, the Guard is STILL fully verified first — the forward cannot complete without a passing Guard result. After verification, exactly the caller's submissions for the listed identifiers are copied here as Guard-verified facts (see MachineForwardGuardSchema)."
                                 },
                                 "msg": {
                                   "type": "string",
@@ -9083,7 +9113,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9110,7 +9140,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9137,7 +9167,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9164,7 +9194,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9198,7 +9228,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             },
             "context_depth": {
               "description": "BFS recursion depth for dependency expansion in assemble_context (default 0 = no expansion). When >0, the assembly recursively queries objects referenced by the center objects (permission, guard, machine, service, repositories, etc.) up to the given depth, using the same address-field extraction rules as extractAddressFields. Each level issues one batched query_objects call (≤50 IDs per batch). Cycles are detected and skipped via a visited set. Discovered dependencies are returned in `dependencies` (edge metadata) and `dependency_objects` (full object states). Recommended: 1–2 for most use cases; 3+ may pull large subgraphs (use context_include to constrain).",
@@ -9241,7 +9271,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             },
             "reverse_order_amount": {
               "description": "Escrowed order amount (smallest-unit string) for reverse_map — included in the report summary as the concrete escrow mention.",
@@ -9338,7 +9368,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9383,7 +9413,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             }
           },
           "required": [
@@ -9428,7 +9458,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             },
             "account": {
               "description": "Scope the aggregation to ONE account address (the client's current account). Omit to aggregate across ALL local accounts.",
@@ -9463,7 +9493,7 @@
                 "mainnet",
                 "localnet"
               ],
-              "description": "Network for the query. Defaults to 'testnet' if omitted. 'localnet' is for internal test use against a local fullnode."
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
             },
             "account": {
               "description": "Scope to ONE account address (the client's current account). Omit to merge across ALL local accounts.",
@@ -9520,6 +9550,160 @@
           ],
           "additionalProperties": false,
           "description": "Cross-network build detection + mainnet customization preflight (first-touch migration): detect whether the account has already built Services/Machines/etc. on the source network (default testnet), report the same on the target network (default mainnet), and return a business-facing checklist of the key settings to confirm/change when migrating — payment token, location, arbitration, WIP, gas. Read-only."
+        },
+        {
+          "type": "object",
+          "properties": {
+            "query_type": {
+              "type": "string",
+              "const": "onchain_topology"
+            },
+            "focus": {
+              "description": "Seed of the topology — an on-chain address (EOA 0x00… or any object 0x10..0x24/0xf1) or a LocalMark name (resolved automatically). Required when query_type='onchain_topology'. The read-side topology kernel expands OUTWARD from this seed over the machine-readable EdgeSchema: holder fields, global reverse indexes (orders/permissions/bindings/votes), Machine node tables (the workflow graph) and derived money-flow edges.",
+              "type": "string"
+            },
+            "context_network": {
+              "type": "string",
+              "enum": [
+                "testnet",
+                "mainnet",
+                "localnet"
+              ],
+              "description": "Network for the query. Defaults to the user's CURRENT network (client UI selection / authority config) when omitted. 'localnet' is for internal test use against a local fullnode."
+            },
+            "intent": {
+              "description": "SEMANTIC exploration strategy (G3) — what this topology call is trying to establish. Deterministically shapes the edge whitelist, per-family depth caps and budget: full_map=complete structural map; order_health=order lifecycle+completion+disputes; fund_flow=payments+allocation waterfall+guard-gated splits; workflow=Machine node graphs+transitions+progress; counterparty=who is on the other side (buyer/seller/agents/operators); reputation=votes+arbitration record+contacts; permission=permission groups+bindings+entity tables; supply_chain=multi-leg allocation/sub-order settlement; arbitration=dispute cases+voters; demand_match=demand presenters+guards+rewards. When omitted, defaults come from the persona system (role default intents < account persona preference), then industry templates; every applied layer is reported in result.strategy.trace.",
+              "type": "string",
+              "enum": [
+                "full_map",
+                "order_health",
+                "fund_flow",
+                "workflow",
+                "counterparty",
+                "reputation",
+                "permission",
+                "supply_chain",
+                "arbitration",
+                "demand_match"
+              ]
+            },
+            "role": {
+              "description": "Identity lens for the default strategy: the persona role whose default intents and RoleProfile.topology preference drive the exploration when 'intent' is omitted (e.g. prospect → counterparty+reputation+fund_flow due diligence).",
+              "type": "string",
+              "enum": [
+                "merchant",
+                "customer",
+                "demander",
+                "prospect",
+                "supplier",
+                "collaborator",
+                "arbitrator"
+              ]
+            },
+            "industry": {
+              "description": "Industry template lens (freelance/rental/education/travel/subscription/retail or a registered pack industry): shapes per-family depth caps — e.g. rental deepens money edges (deposit round-trip), travel deepens workflow (multi-leg trips).",
+              "type": "string"
+            },
+            "context_account": {
+              "description": "Optional EOA address whose persona record supplies the identity-specific exploration preference (RoleProfile.topology). Omit to use the system persona. Also serves as the OBSERVER of the G2 role-interest view when interest_role is set.",
+              "type": "string"
+            },
+            "interest_role": {
+              "description": "G2 role interest view — project THIS CommercialRole's complete interest view (利益评估 stakes + 可行操作路径 node-game actions + 博弈对手分析 + 风险提醒) for context_account (or the seed when it is an EOA) over the same expanded graph. The view is returned as result.role_interest and as one IR:<role> finding carrying the same structured payload. Scoring comes exclusively from the evaluation game modules; when omitted, defaults to the persona 'role' lens if provided.",
+              "type": "string",
+              "enum": [
+                "merchant",
+                "customer",
+                "demander",
+                "prospect",
+                "supplier",
+                "collaborator",
+                "arbitrator",
+                "neutral",
+                "system"
+              ]
+            },
+            "no_cache": {
+              "description": "Set true to bypass the SDK chain-read cache. In-call batching/dedup still applies.",
+              "type": "boolean"
+            },
+            "analyze": {
+              "description": "Run the registered graph Analyzer suite (R/A/O/G — risk / structural-arbitrage / opportunity / game) over the NEUTRAL viewport and return objective findings. Default true; set false for raw topology only. Findings are facts + structural suggestions, never scores — scoring stays in the game-theory modules.",
+              "type": "boolean"
+            },
+            "analyzer_kinds": {
+              "description": "Filter analyzer kinds when analyze=true (default: all four): risk=R rules, arbitrage=A structural-arbitrage, opportunity=O, game=G objective situations.",
+              "type": "array",
+              "items": {
+                "type": "string",
+                "enum": [
+                  "risk",
+                  "arbitrage",
+                  "opportunity",
+                  "game"
+                ]
+              }
+            },
+            "only_analyzers": {
+              "description": "Run ONLY these analyzer ids (whitelist, e.g. ['R1','G2']). The full registered id list is returned in `analyzers` of every response.",
+              "type": "array",
+              "items": {
+                "type": "string"
+              }
+            },
+            "include_raw": {
+              "description": "Attach each node's full raw on-chain object as nodes[].raw. Default false — nodes then carry only kind/object_type/coin_type/state/depth, keeping the payload compact.",
+              "type": "boolean"
+            },
+            "table_edges": {
+              "description": "Dynamic-table edges to expand (channel B). Default ['machine.node'] — expands every reached Machine's workflow node table and DERIVES the wf.transition graph. Add 'permission.entity' for permission-group members (EOA/Guard + perm indices) and 'demand.presenter' for demand proposals.",
+              "type": "array",
+              "items": {
+                "type": "string",
+                "enum": [
+                  "machine.node",
+                  "permission.entity",
+                  "demand.presenter"
+                ]
+              }
+            },
+            "budget": {
+              "description": "Optional expansion-budget overrides. Every fetch stays batched (<=50 ids/request) regardless of these caps; exhaustion is reported honestly in budget_exhausted.",
+              "type": "object",
+              "properties": {
+                "max_depth": {
+                  "description": "BFS wave depth (default 4).",
+                  "type": "integer",
+                  "minimum": 0,
+                  "maximum": 8
+                },
+                "max_nodes": {
+                  "description": "Hard node cap (default 500).",
+                  "type": "integer",
+                  "minimum": 1,
+                  "maximum": 3000
+                },
+                "max_rpcs": {
+                  "description": "Hard logical RPC-batch cap; each batch carries at most 50 ids (default 120).",
+                  "type": "integer",
+                  "minimum": 1,
+                  "maximum": 400
+                },
+                "max_fanout": {
+                  "description": "Per-node fanout cap per edge schema (default 60).",
+                  "type": "integer",
+                  "minimum": 1,
+                  "maximum": 5200
+                }
+              },
+              "additionalProperties": false
+            }
+          },
+          "required": [
+            "query_type"
+          ],
+          "additionalProperties": false,
+          "description": "Read-only on-chain TOPOLOGY network around ONE seed address: batched multi-hop BFS over the machine-readable EdgeSchema (never per-id RPC; objects / EOA keyed fields / tables / events use four separate batched channels). Returns nodes + typed edges (family F=field / R=reverse-index / W=workflow / M=money-flow / S=social) with per-edge retention semantics (complete / bounded_exact / membership / bounded_window / derived), the STRUCTURAL workflow subgraph of each reached Machine (incl. its structural terminal set), structural completion of every Order reached, R/A/O/G analyzer findings, and truncation / data-gap / budget honesty markers. Read-only."
         }
       ]
     },