weavatrix 1.17.3 → 1.17.4

package/README.md

@@ -58,7 +58,7 @@ weavatrix mcp .
 ```toml
 [mcp_servers.weavatrix]
 command = "npx"
-args = ["-y", "weavatrix@1.17.3", "mcp", "."]
+args = ["-y", "weavatrix@1.17.4", "mcp", "."]
 ```
 
 Pass an absolute repository path when the Codex process cwd is not the project
@@ -67,7 +67,7 @@ you intend to analyze.
 ### Claude Code
 
 ```sh
-claude mcp add weavatrix -- npx -y weavatrix@1.17.3 mcp .
+claude mcp add weavatrix -- npx -y weavatrix@1.17.4 mcp .
 ```
 
 ### Cursor
@@ -80,7 +80,7 @@ the plugin for the same server name:
   "mcpServers": {
     "weavatrix": {
       "command": "npx",
-      "args": ["-y", "weavatrix@1.17.3", "mcp", "${workspaceFolder}"]
+      "args": ["-y", "weavatrix@1.17.4", "mcp", "${workspaceFolder}"]
     }
   }
 }
@@ -89,14 +89,14 @@ the plugin for the same server name:
 Profiles expose bounded views of the same engine:
 
 ```sh
-npx -y weavatrix@1.17.3 mcp . --profile=all
-npx -y weavatrix@1.17.3 mcp . --profile=code
-npx -y weavatrix@1.17.3 mcp . --profile=seo
-npx -y weavatrix@1.17.3 mcp . --profile=n8n
-npx -y weavatrix@1.17.3 mcp . --profile=dify
-npx -y weavatrix@1.17.3 mcp . --profile=agent
-npx -y weavatrix@1.17.3 mcp . --profile=diagram
-npx -y weavatrix@1.17.3 mcp . --profile=web3
+npx -y weavatrix@1.17.4 mcp . --profile=all
+npx -y weavatrix@1.17.4 mcp . --profile=code
+npx -y weavatrix@1.17.4 mcp . --profile=seo
+npx -y weavatrix@1.17.4 mcp . --profile=n8n
+npx -y weavatrix@1.17.4 mcp . --profile=dify
+npx -y weavatrix@1.17.4 mcp . --profile=agent
+npx -y weavatrix@1.17.4 mcp . --profile=diagram
+npx -y weavatrix@1.17.4 mcp . --profile=web3
 ```
 
 The package contains native binaries for Windows x64/arm64, macOS x64/arm64,
@@ -121,6 +121,10 @@ same, and a call that names its own `output_format` still wins.
 
 `json` is the default and keeps the mirror, because a client that ignores
 `structuredContent` would otherwise see an empty result.
+For an architecture question, call `architecture_inventory` with no arguments
+and explain its modular, onion, layered, and ports-and-adapters hypotheses in
+prose. Report `CANDIDATE` and `INSUFFICIENT_EVIDENCE` honestly; the declared
+contract style is not evidence of the observed architecture.
 
 ### What the new domains actually answer
 
@@ -251,6 +255,11 @@ Pagination and explicit limits bound large neighborhoods, histories, searches,
 and contract inventories.
 
 `build_graph` and `architecture_inventory` share one typed build model. They
+also report independent, evidence-bounded hypotheses for modular source
+organization, onion, ports-and-adapters, layered dependencies, and deployment
+uncertainty; the declared target style is never observation. The summary
+includes each hypothesis's status, supporting signals, contradictions, and
+unknowns; use `detail:"full"` for paged graph evidence. They
 preserve nested Cargo, npm/TypeScript, Go, and Python components, many-to-many
 declared memberships, collision-free identities, configuration predicates,
 and immutable source evidence. Totals and SCC/cycle witnesses are computed
@@ -316,11 +325,11 @@ coding agent
     |
     | MCP over stdio
     v
-weavatrix 1.17.3
+weavatrix 1.17.4
     profile catalog · refresh · watcher · MCP framing
     |
     v
-weavatrix-rust 2.17.2
+weavatrix-rust 2.17.3
     typed graph · analysis · 67 product operations including local CI, n8n, Dify, agent packages, Mermaid, and Web3
 ```
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "weavatrix",
-  "version": "1.17.3",
-  "weavatrixEngineVersion": "2.17.2",
+  "version": "1.17.4",
+  "weavatrixEngineVersion": "2.17.3",
   "description": "Native repository intelligence for coding agents: 67 read-only MCP operations backed by typed evidence graphs, impact, architecture, local CI restrictions, APIs, Git, search, semantics, memory, n8n workflows, Dify apps, agent packages, Mermaid diagrams, and Web3 ABIs.",
   "author": "Sergii Ziborov <sergii.ziborov@gmail.com>",
   "license": "MIT",

package/server.json

@@ -7,14 +7,14 @@
     "url": "https://github.com/Weavatrix/weavatrix",
     "source": "github"
   },
-  "version": "1.17.3",
+  "version": "1.17.4",
   "websiteUrl": "https://weavatrix.com",
   "packages": [
     {
       "registryType": "npm",
       "registryBaseUrl": "https://registry.npmjs.org",
       "identifier": "weavatrix",
-      "version": "1.17.3",
+      "version": "1.17.4",
       "runtimeHint": "npx",
       "transport": {
         "type": "stdio"

package/skill/SKILL.md

@@ -23,10 +23,17 @@ contracts. Do not call it merely because the server is available.
 1. Call `graph_stats` and confirm `repository_context.root` matches the workspace
    you intend. The MCP process is pinned to its launch root; it will not silently
    answer for another repository.
-2. For "what is this repository's architecture?", call
-   `architecture_inventory` with no `detail` argument (bounded summary).
-   Explain its packages, component areas, dominant coupling, and limits in
-   your own concise prose; do not paste the tool's JSON as the answer. Use
+2. For "what is this repository's architecture?", including "is it onion,
+   modular, layered, or ports-and-adapters?", call `architecture_inventory`
+   with no `detail` argument (bounded summary). Read
+   `architecture_hypotheses.hypotheses`: report each relevant `SUPPORTED`,
+   `CANDIDATE`, `CONTRADICTED`, or `INSUFFICIENT_EVIDENCE` status with one
+   decisive dependency witness or missing signal. Explain the result,
+   component areas, and limits in concise prose; do not paste the JSON. Do
+   not turn a candidate into a confirmed style, or use a declared contract
+   `style` as proof of the observed architecture. See
+   [references/tools/architecture_inventory.md](references/tools/architecture_inventory.md)
+   for the interpretation rules. Use
    `module_map` for a directory-focused question, or `search_code` for a
    known literal. Request `architecture_inventory` with `detail:"full"`
    only when a specific component, edge, or cycle needs source evidence.

package/skill/references/tool-routing.md

@@ -41,7 +41,7 @@ cannot silently switch to another repository. Pass an explicit
 
 ## Quality and architecture
 
-- [`architecture_inventory`](tools/architecture_inventory.md) — Bounded architecture overview by default, with complete edge/cycle-candidate totals; `detail:"full"` gives paged evidence. Explain the overview in prose, not as a JSON dump.
+- [`architecture_inventory`](tools/architecture_inventory.md) — Bounded architecture overview and evidence-bounded style hypotheses by default, with complete edge/cycle-candidate totals; `detail:"full"` gives paged evidence. Explain statuses and witnesses in prose, not as a JSON dump.
 - [`ci_restrictions`](tools/ci_restrictions.md) — Local GitHub Actions checks and conditional applicability.
 - [`explain_restriction`](tools/explain_restriction.md) — One restriction and its evidence limits.
 - [`find_duplicates`](tools/find_duplicates.md) — Deterministic Type-1/2/3 clone families.

package/skill/references/tools/architecture_inventory.md

@@ -1,8 +1,9 @@
 # `architecture_inventory`
 
-Observed package, nested component, declared-membership, and typed edge
-evidence. The default is a bounded architecture overview, not a raw graph
-dump. No style label or target architecture is inferred.
+Observed package, nested component, declared-membership, typed edge, and
+architecture-style evidence. The default is a bounded overview, not a raw
+graph dump. Style findings are independent hypotheses, never the target
+contract's declared style.
 
 ## When to use
 
@@ -31,8 +32,22 @@ the component quotient is reported as architecture, not as symbol recursion.
 {"name":"architecture_inventory","arguments":{}}
 ```
 
-Turn the returned packages, component paths, dominant coupling, and complete
-edge/cycle-candidate totals into a concise answer in your own words. Never
+Read `architecture_hypotheses.hypotheses` first. `modular_source` concerns
+source organization; `onion` and `layered` concern dependency direction;
+`ports_and_adapters` concerns core interfaces and adapters; `microservices`
+concerns deployment and remains unconfirmed without independent deployment
+evidence. These dimensions may coexist. `SUPPORTED` means the rule's static
+signals were observed, not that architectural intent or runtime behavior was
+proven. `CANDIDATE` requires qualified language, `CONTRADICTED` needs its
+counterexample, and `INSUFFICIENT_EVIDENCE` must not be turned into absence.
+Path names are weak role candidates; inspect `observed_signals`,
+`contradictions`, and `unknowns`. Never use a contract `style`, green
+`verify_architecture` result, or package count as proof of an observed style.
+
+Answer in your own concise prose, for example: "Modular source organization:
+supported (module markers and cross-directory imports). Onion: insufficient
+evidence (no application-to-domain and outer-to-core chain)." Include one
+decisive file-level witness when available, not the entire JSON. Never
 present a quotient/union cycle candidate as a proven executable cycle. Ask
 for `{"detail":"full"}` only to inspect a specific edge, component, or
 cycle witness. The full response can be large and paginates edges.