@wix/himalaya-cli 0.1126.0 → 0.1128.0

package/guides/headless-loop.md

@@ -105,16 +105,24 @@ the template's, then once as "First look at your app" after your first change
 or draft postcard that would otherwise show the changed app first; Markdown edits do not
 count), a `himi test` crawl whose outcome changed (its
 counts or its home picture — an identical re-run writes none, and a repeat says what changed), and every draft push (with the home picture only
-when that shot is newer than the last source edit, or else the reason and the `himi render <home> --png` that makes one — and each draft push also rebuilds the making-of,
+when that shot is newer than the last source edit, or else the reason and the `himi render <home> --png` that makes one; a repeat names what changed since the last draft —
+"Since the last draft: the home screen changed." — and each draft push also rebuilds the making-of,
 `.himi/making-of.html`, named as `reel` in its output), and — after ten minutes with no postcard — a home render
 whose picture is new ("Still building: here's the home screen now."). A passing `himi validate` after a source change
 refreshes the home picture itself (the same offline render, bounded to 30 seconds, never for an unread `--remote`
 template; reported as `homePicture`), and an unchanged `himi test` crawl's home shot counts too, so a long stretch of edits,
-validates and crawls still reaches the owner. When the home picture a postcard carries landed on an error, loading or
+validates and crawls still reaches the owner. Those automatic renders are `himi render <home> --mocks --png`: the worker's
+load runs against the app's own recorded data — `dev/net-mocks.json` (`himi test --record` writes it), then the config's
+cms seed rows — as `himi test`'s shots do, never a request, so the picture shows content; record the site's data once
+and every automatic picture after it shows the app as it works. When the home picture a postcard carries landed on an error, loading or
 empty state (read from the worker state it was painted from), the postcard says so ("— but the home screen shows an
-error: …") instead of reading clean. A `himi progress` postcard given no `--image`
+error: …") instead of reading clean — and when the render itself caused it, painting without the site's data (the
+initial state's placeholders, or a request no recorded data held), it says "— but it is an offline preview, without the
+site's data, …" instead. A `himi progress` postcard given no `--image`
 carries the current home shot by itself (never a stale one; `--no-image` opts out; the `--step review` handover card
-carries it even as a repeat and names the making-of), and `himi render` and `himi test` carry a `reminder` (their
+carries it even as a repeat and names the making-of) — never a shot of placeholders, an empty or an error state as if it
+showed the app working: then it carries the newest home picture of the current code that shows content, or none, with
+the reason in `imageNote`, and `himi render` and `himi test` carry a `reminder` (their
 output's last key): with no `himi run --watch` running it names the command, with one running its url. The CLI's own postcards are marked as the CLI's, never move the journey step, and step aside when you journal
 the same step or the same picture within five minutes — so journal yours as usual. `himi run --watch` rebuilds on every
 save and sends the open tab only what changed; a save that does not build keeps the last good preview

package/guides/himi-test.md

@@ -197,6 +197,14 @@ every write refused at the transport) — then crawls hermetically on what it fr
 every run; record against a **QA site**, never production. See
 `docs/dev-network-gateway.md` for the record→freeze machinery.
 
+**The pictures use it too.** `himi render <id> --png --mocks` runs the worker's load against the
+same recorded data — `dev/net-mocks.json`, then the config's cms seed rows, never the canned
+fixture and never a request — so a data-driven screen paints its content instead of its offline
+placeholders. The automatic pictures (`himi init`'s first look, `himi validate`'s refresh) are
+that render. A picture painted without the site's data — the initial state, or a load in which a
+request found no recorded data (a shot's `offline` flag in `.himi/shot-states.json`) — is
+captioned as an offline preview, never as the app failing.
+
 ## The report an agent reads
 
 Every run prints a machine envelope with `--json`. Findings are source-mapped to the line

package/guides/skill.md

@@ -121,9 +121,9 @@ If a gate is not implied (no credentials, no draft instruction, no site URL for
 **Keep the owner watching, headless too.** Whoever watches the board while you work, or reads the run afterwards, sees only what reached the journal. Do these in the session that builds the app — not at the end, and not in a later session — each one when `himi --help` lists the command:
 
 1. **The board opens at init.** `himi init` creates the build board (`.himi/studio/index.html`) and its `next[]` starts with this session's first steps: run them now, in order: the first picture and its postcard, the consent preflight, then the live preview — for every template. The preflight costs nothing on an app that makes no startup request: if no worker or config can make a Wix or external request at boot, go straight on. When the installed `init` prints no `board`, run `himi studio --no-open` once in the app folder.
-2. **The first picture comes from init.** A current `himi init` renders the home screen itself — offline, it never calls Wix, so it needs no preflight — and journals it as the STARTING POINT — the template before any of your changes, never "your app" — so the board holds a picture from the start; your first home render after you change the source is journaled as "First look at your app". It does so only for a template bundled with the CLI: one fetched with `--remote` is its publisher's code, and a render runs it on this machine, so read its `dev/`, `config.ts` and `tier5-src/` first. On an older CLI, or when its `firstLook` says `skipped`, make it yourself right after init: `himi render <homeScreenId> --png --device iphone`. The CLI journals that first look itself.
+2. **The first picture comes from init.** A current `himi init` renders the home screen itself — offline, it never calls Wix, so it needs no preflight; when the app has recorded data (`dev/net-mocks.json`, which `himi test --record` writes, or cms seed rows) the automatic pictures load it, and otherwise they are captioned as an offline preview, not as an error — and journals it as the STARTING POINT — the template before any of your changes, never "your app" — so the board holds a picture from the start; your first home render after you change the source is journaled as "First look at your app". It does so only for a template bundled with the CLI: one fetched with `--remote` is its publisher's code, and a render runs it on this machine, so read its `dev/`, `config.ts` and `tier5-src/` first. On an older CLI, or when its `firstLook` says `skipped`, make it yourself right after init: `himi render <homeScreenId> --png --device iphone`. The CLI journals that first look itself.
 3. **Then the live preview: init started it; if it isn't running (`--remote`, CI), start it.** A current `himi init` starts `himi run --watch` itself (its `watch` field names the url, the board and `.himi/watch.log`; it stops after 30 minutes with no save) — do not start a second one. When its `watch` says `skipped`, only once the consent preflight (journey step 4) clears the app to boot locally, run `himi run --watch --content <dir> &` and leave it up until the handover: it repaints on every save and serves the board at `<url>/__himi/studio/`. Do not wait to be reminded: a `reminder` from `himi render` or `himi test` (the last key of their output) that says to start it means none is running — run it then; one that names a url means it is running.
-4. **A postcard with a picture at every journey step:** `himi progress "<what changed>" --step <n> --image .himi/shots/<screenId>.png`. Leave out `--image` and a current CLI attaches the current home shot for you. `himi test` and `himi push --draft` journal their own results too, and a home render after ten silent minutes journals "Still building" — your postcards still say what changed and why it matters.
+4. **A postcard with a picture at every journey step:** `himi progress "<what changed>" --step <n> --image .himi/shots/<screenId>.png`. Leave out `--image` and a current CLI attaches the current home shot for you — or, when that shot shows loading placeholders, an empty or an error state, the newest home picture of the current code that shows content; with none it attaches nothing, and `imageNote` says why. `himi test` and `himi push --draft` journal their own results too (a repeat draft says what changed since the last one), and a home render after ten silent minutes journals "Still building" — your postcards still say what changed and why it matters.
 5. **At the handover, the picture and the making-of:** journal `himi progress "<what the owner can review>" --step review` — it carries the current home picture even when the draft's card showed it, and rebuilds and names `.himi/making-of.html` (`makingOf`) — then hand the owner that file beside the preview link (every current `himi push --draft` also writes it, as `reel`; on an older CLI run `himi studio reel`). Name the file in your final report.
 
 ## Technical handoff

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1126.0",
+  "version": "0.1128.0",
   "type": "module",
   "description": "himi — the Himalaya authoring CLI. Build a Tier-5 content package on your own machine, push it to the production serve as a draft, preview it on web + Himi Player, and read worker logs back — the remote dev loop. Wraps @himalaya/serve-cli for transport.",
   "keywords": [
@@ -67,5 +67,5 @@
       "artifactId": "himalaya-cli"
     }
   },
-  "falconPackageHash": "07d194b64ad7a7ed43aab3c35b86ed6fc0fa64158defdf6674ca362a"
+  "falconPackageHash": "8340fceb4deeef12cc58c6969904b2b33ae4c90a5923c20cef72d267"
 }