@enfyra/mcp-server 0.0.34 → 0.0.35

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@enfyra/mcp-server",
-  "version": "0.0.34",
+  "version": "0.0.35",
   "description": "MCP server for Enfyra - manage your Enfyra instance via Claude Code",
   "type": "module",
   "license": "MIT",

package/src/lib/mcp-examples.js

@@ -579,7 +579,7 @@ create_menu({
 // Child page extensions should be focused:
 // /dashboard            compact summary/routing hub: KPIs, current signal, attention queue, navigation cards
 // /cloud/projects      project status and drill-downs
-// /cloud/provisioning  provisioning timeline/failures/slow steps
+// /cloud/provisioning  project/run grouped provisioning status, current step, meaning, next action
 // /cloud/billing       orders/subscriptions/refunds
 // /cloud/infrastructure hosts/capacity/plans/system credential readiness
 // /cloud/readiness     legal/Paddle/landing launch checklist
@@ -589,6 +589,7 @@ create_menu({
           'Design the menu/page split before generating dashboard code.',
           'Keep /dashboard as a summary and distribution page, not a detailed operations table.',
           'Use focused pages for operational domains.',
+          'Provisioning pages should not show raw history rows as the primary UI; group by project/run and translate step keys into operator-facing labels.',
           'UTabs is available in eApp extension runtime for page-level sections.',
           'Admin links for editing or inspecting records should point to /data/<table> routes.',
         ],

package/src/lib/mcp-instructions.js

@@ -272,6 +272,7 @@ export function buildMcpServerInstructions(apiBaseUrl) {
     '- **Code format:** Vue SFC only. Structure: `<template>...</template>` + `<script setup>...</script>`. Server auto-compiles; if compile fails, fix and retry.',
     '- **NO import statements.** All APIs are injected globally (see full list below).',
     '- **Design first for dashboards:** before creating/updating a dashboard extension, define the menu/page split, time range controls, tabs, and drill-down links. Keep `/dashboard` as a compact summary and routing hub only: KPIs, current signal, attention queue, and navigation cards. Put detailed lists/tables/timelines into focused pages such as projects, provisioning, billing, infrastructure, and readiness.',
+    '- **Operational page modeling:** model admin operational pages around the operator mental entity, not raw database/event rows. For provisioning, group history by project/run, translate internal step keys into readable labels, show current step, operator meaning, and next action, and keep raw history as a secondary `/data` shortcut.',
     '- **Page layout default:** page extensions should render full-bleed inside the app shell by default. The extension root is already inside the eApp page `<main>`, so do not add root-level page padding such as `p-4 sm:p-6 xl:p-8`; use spacing between internal sections only. Do not wrap the entire page in a centered card/container unless explicitly requested. Use responsive grids/stacks from the first version so the page works on desktop, tablet, and mobile.',
     '- **Admin record links:** when an admin extension links to backend records for management or inspection, point to eApp data routes such as `/data/landing_terms`, `/data/cloud_projects`, or `/data/cloud_payment_orders`. Do not use public landing-page paths from record fields such as `/cloud-terms` unless the explicit intent is previewing the public website.',
     '- **Do not downgrade extension code to ES5 to appease tooling.** eApp extension runtime should support normal browser/runtime APIs such as `Array.includes`, `Set`, `Promise.all`, `String.replace`, `Intl.DateTimeFormat`, and `Intl.NumberFormat`. If diagnostics reject these, fix eApp extension checker/runtime contract instead of rewriting generated extension code around the limitation.',