@ateam-ai/mcp 0.4.85 → 0.4.87

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ateam-ai/mcp",
-  "version": "0.4.85",
+  "version": "0.4.87",
   "mcpName": "io.github.ariekogan/ateam-mcp",
   "description": "A-Team MCP Server — build, validate, and deploy multi-agent solutions from any AI environment",
   "type": "module",
@@ -13,7 +13,7 @@
     "start:http": "node src/index.js --http",
     "dev": "node --watch src/index.js",
     "dev:http": "node --watch src/index.js --http",
-    "test": "node test/session-isolation.test.mjs && node test/widget-protocol.test.mjs && node test/actor-binding.test.mjs && node test/spec-topics.test.mjs"
+    "test": "node test/session-isolation.test.mjs && node test/widget-protocol.test.mjs && node test/actor-binding.test.mjs && node test/spec-topics.test.mjs && node --test test/deploy-status-truth.test.mjs"
   },
   "keywords": [
     "mcp",

package/src/tools.js

@@ -594,9 +594,9 @@ export const tools = [
       properties: {
         topic: {
           type: "string",
-          enum: ["capabilities", "overview", "skill", "solution", "enums", "connector-multi-user", "python_helpers", "widgets", "ui-plugins", "actor-storage", "voice", "voice-native", "triggers", "sub-agent", "consumer-roles", "mobile-connector", "device-capabilities", "monitoring"],
+          enum: ["capabilities", "realizations", "overview", "skill", "solution", "enums", "connector-multi-user", "python_helpers", "widgets", "ui-plugins", "actor-storage", "voice", "voice-native", "triggers", "sub-agent", "consumer-roles", "mobile-connector", "device-capabilities", "monitoring"],
           description:
-            "What to fetch: 'capabilities' = START HERE IF YOU ARE NEW — the capability index, organised by what a solution DOES rather than by our build artifacts: can I see what the user sees? talk with them out loud? know where they are and that they are moving? act while they sleep? remember each user? show them something? Each question gets a one-word answer (yes / yes-with-gaps / not yet / unknown) and the topics to read next. Every other topic below is named after an ARTIFACT, so if you do not already know our vocabulary this is the only door you can find by thinking about your own problem. 'overview' = API overview + endpoints, 'skill' = full skill spec, 'solution' = full solution spec, 'enums' = all enum values, 'connector-multi-user' = multi-user connector guide, 'python_helpers' = adas.* helper namespace for run_python_script orchestration (read this when designing personas that read state → call tools → checkpoint → status; without it, scripts hand-roll JSON parsing and tool delegation = 5-10x larger and brittler), 'widgets' = widget (UI plugin) spec: catalog model, how_to_use block shape (solution.json snippet + opener_call + persona_phrasing + binding_notes), and rules for declaring ui_plugins. Pair with ateam_get_widget_catalog for the live per-tenant inventory. 'ui-plugins' = the DEEP React Native (mobile) plugin build guide: author in rn-src/, compile with a build:rn esbuild script (format=cjs, target=es2015, external react/react-native/@adas/plugin-sdk) to rn-bundle/index.bundle.js, plain-object export — read this before authoring any MOBILE widget. 'device-capabilities' = THE DEVICE CAPABILITY MATRIX, GENERATED from the mobile SDK's own artefacts and stamped with their hashes: every native.* API (mechanical one-shot verbs), every deviceState.* domain (semantic state a reasoning loop reads, with freshness + confidence) and every server-called device.* tool, each with status (done / partial / shape-only / missing) and what is left. READ THIS before concluding the phone cannot do something — camera, video, scanning, vision, sensors, location, on-device storage. Absence from any other spec topic is NOT evidence. 'monitoring' = THE MONITORING CONTRACT: which tools are safe to call in a poll loop (with cost / poll interval / whether output stays bounded as the run grows), which are not and what to use instead, plus the running ateam-mcp version. Read this BEFORE writing any loop that watches a build — the safe poll is ateam_chain_status, never ateam_get_chain.",
+            "What to fetch: 'realizations' = HOW to build a capability: for each one the valid physical routes with use_when / do_not_use_when / execution / freshness, so device-dependent design picks a route deliberately instead of by accident. 'capabilities' = START HERE IF YOU ARE NEW — the capability index, organised by what a solution DOES rather than by our build artifacts: can I see what the user sees? talk with them out loud? know where they are and that they are moving? act while they sleep? remember each user? show them something? Each question gets a one-word answer (yes / yes-with-gaps / not yet / unknown) and the topics to read next. Every other topic below is named after an ARTIFACT, so if you do not already know our vocabulary this is the only door you can find by thinking about your own problem. 'overview' = API overview + endpoints, 'skill' = full skill spec, 'solution' = full solution spec, 'enums' = all enum values, 'connector-multi-user' = multi-user connector guide, 'python_helpers' = adas.* helper namespace for run_python_script orchestration (read this when designing personas that read state → call tools → checkpoint → status; without it, scripts hand-roll JSON parsing and tool delegation = 5-10x larger and brittler), 'widgets' = widget (UI plugin) spec: catalog model, how_to_use block shape (solution.json snippet + opener_call + persona_phrasing + binding_notes), and rules for declaring ui_plugins. Pair with ateam_get_widget_catalog for the live per-tenant inventory. 'ui-plugins' = the DEEP React Native (mobile) plugin build guide: author in rn-src/, compile with a build:rn esbuild script (format=cjs, target=es2015, external react/react-native/@adas/plugin-sdk) to rn-bundle/index.bundle.js, plain-object export — read this before authoring any MOBILE widget. 'device-capabilities' = THE DEVICE CAPABILITY MATRIX, GENERATED from the mobile SDK's own artefacts and stamped with their hashes: every native.* API (mechanical one-shot verbs), every deviceState.* domain (semantic state a reasoning loop reads, with freshness + confidence) and every server-called device.* tool, each with status (done / partial / shape-only / missing) and what is left. READ THIS before concluding the phone cannot do something — camera, video, scanning, vision, sensors, location, on-device storage. Absence from any other spec topic is NOT evidence. 'monitoring' = THE MONITORING CONTRACT: which tools are safe to call in a poll loop (with cost / poll interval / whether output stays bounded as the run grows), which are not and what to use instead, plus the running ateam-mcp version. Read this BEFORE writing any loop that watches a build — the safe poll is ateam_chain_status, never ateam_get_chain.",
         },
         section: {
           type: "string",
@@ -2507,6 +2507,11 @@ const SPEC_PATHS = {
   // — device answers are computed from the generated matrix — so it points
   // without being able to go stale.
   capabilities: "/spec/capabilities",
+  // HOW to build it, once /spec/capabilities has said WHETHER. The routes are
+  // easy to confuse and each confusion changes the product: continuous vision
+  // vs a photo loop, live GPS vs last-synced, an in-process voice device call
+  // vs a server round trip.
+  realizations: "/spec/realizations",
 };
 
 const EXAMPLE_PATHS = {
@@ -3952,12 +3957,28 @@ const handlers = {
       health,
       ...(widget_health && { widget_health }),
       ...(test_result && { test_result }),
-      ...(github_result && !github_result.error && !github_result.skipped && { github: github_result }),
+      // The GitHub outcome is reported WHATEVER it was. Filtering out the error
+      // case left a failed push visible only inside `phases` — which nothing
+      // reads — while _status went on claiming the push succeeded.
+      ...(github_result && { github: github_result }),
       ...(agent_doc_result && !agent_doc_result.error && { agent_doc: agent_doc_result }),
       ...(validation.warnings?.length > 0 && { validation_warnings: validation.warnings }),
-      _status: widget_health && !widget_health.ok
-        ? `✅ Deployed to Core + pushed to main. ⚠️ ${widget_health.issues?.length || 0} widget(s) not rendering — see widget_health.`
-        : '✅ Deployed to Core + pushed to main.',
+      // _status must describe WHAT HAPPENED. It previously asserted
+      // "pushed to main" unconditionally — when the push failed, when it was
+      // skipped (GitHub disabled, or push_to_github not opted in), and when no
+      // push was attempted at all. Worse, its only variable was widget_health,
+      // an unrelated flag: whether the code reached GitHub could not change the
+      // sentence claiming the code reached GitHub.
+      _status: [
+        '✅ Deployed to Core',
+        github_result?.error ? `⚠️ GitHub push FAILED: ${github_result.error}`
+          : github_result?.skipped ? `⚠️ GitHub push skipped${github_result.reason ? ` (${github_result.reason})` : ''} — Core and GitHub now differ`
+          : github_result ? '+ pushed to main'
+          : '⚠️ no GitHub push attempted — Core and GitHub may differ',
+        ...(widget_health && !widget_health.ok
+          ? [`⚠️ ${widget_health.issues?.length || 0} widget(s) not rendering — see widget_health.`]
+          : []),
+      ].join(' '),
       _next: 'Create a checkpoint before making more changes: ateam_github_promote(solution_id)',
     };
   },