@mondaydotcomorg/z2h-cli 0.3.1 → 0.4.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mondaydotcomorg/z2h-cli",
-  "version": "0.3.1",
+  "version": "0.4.0",
   "bin": "./bin/z2h-cli.js",
   "main": "./dist/index.js",
   "types": "./dist/index.d.ts",

package/src/templates/app/CLAUDE.md

@@ -25,15 +25,9 @@ The orchestrator routes to `z2h:feature-development`, which handles the typechec
 
 ---
 
-## 🌟 Prefer Frontend Over Backend
+## 🌟 Data-Fetching Hierarchy
 
-If a request *could* be solved in this app using existing backend endpoints — do that. Backend changes go through a slow PR + Harmony pipeline; frontend changes ship in seconds via `z2h-cli deploy`.
-
-When uncertain, ask:
-
-> "Can we do this in the app with existing endpoints, or does it need a backend change?"
-
-Only escalate to `z2h:backend-feature-development` for genuinely new persisted entities, schemas, write paths, or server-side rules.
+When a request needs data, follow `z2h:coding-standards-mf` §0: write a `runQuery` helper for Snowflake data (TS module using `getBigBrainAPI()` for React apps; vanilla `<script>` using `window.location.origin` for html-embed apps), write a client-side fetch for other browser-accessible sources, or tell the user to reach out at `#zero-to-hero` if the data needs an API key or server-side access. Backend changes to `bigbrain-zth` are not in scope.
 
 ---
 

package/src/templates/workspace/package.json.tmpl

@@ -12,7 +12,7 @@
     "react-error-boundary": "^3.1.3"
   },
   "devDependencies": {
-    "@mondaydotcomorg/bigbrain-types": "^0.3.3",
+    "@mondaydotcomorg/bigbrain-types": "^0.3.4",
     "@mondaydotcomorg/mf-api-types": "^0.1.1",
     "@mondaydotcomorg/trident-toolkit": "^2.9.25",
     "@mondaydotcomorg/z2h-cli": "__Z2H_CLI_VERSION__",