@wix/himalaya-cli 0.1069.0 → 0.1071.0

package/guides/headless-loop.md

@@ -78,7 +78,7 @@ loop already makes the pictures — send them, and journal each one:
 
 ```sh
 himi render home --png shots/home.png --device iphone                    # the first picture, right after init
-himi studio                                                              # the build board: opens once, keeps itself current
+himi studio                                                              # the build board (init made it): opens it, keeps itself current
 himi run --watch &                                                       # live preview: repaints the open tab on every save
 himi progress "Starting from branded-lite" --step implement --image shots/home.png
 himi render home --png shots/home-dark.png --device iphone --scheme dark
@@ -87,9 +87,14 @@ himi progress                                                            # the j
 himi studio reel                                                         # at handover: the making-of, one self-contained file
 ```
 
-`himi studio` writes `.himi/studio/index.html` and opens it; from then on every render, test,
-validate, push and progress entry refreshes it, and the page picks that up by itself — no server,
-nothing to re-run (`--no-open` prints its path instead, for SSH). `himi run --watch` rebuilds on every
+`himi init` already writes the board (`.himi/studio/index.html`) without opening anything, and its
+`next[]` starts with this session's first steps — the live preview, the first picture, its postcard —
+so run those before anything else. `himi studio` writes the board and opens it; from then on every
+render, test, validate, push and progress entry refreshes it, and the page picks that up by itself — no
+server, nothing to re-run (`--no-open` prints its path instead, for SSH). The CLI journals three
+milestones by itself: the first PNG of the home screen, every completed `himi test` crawl, and every
+draft push. They 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
 on screen and prints `build_failed` with the reason. It stays up until you stop it, so start it in the
 background, and only after the template's startup requests are preflighted (step 4 of the entry skill).

package/guides/skill.md

@@ -46,8 +46,8 @@ A build takes most of an hour. An owner who sees nothing for that long assumes n
 - **A postcard at every milestone.** One or two lines plus the image that proves it: what you read from their site (its `evidence/pages/home-*.png`), their brand applied (the home screen in light **and** dark, next to the site), the launcher icon, each screen the first time it renders, and the test crawl's result (screens, actions exercised, gaps closed). When several renders are ready at once, send them together — a postcard, not a stream.
 - **Show, don't describe.** Use the richest channel your client has: an inline image or an attached file; failing that, open the PNG for them (`open` on macOS, `xdg-open` on Linux) and name its path. Never paste raw image data into the conversation.
 - **Never go quiet.** Do not work for more than about five minutes without one line that says which journey step you are on (`step 4 of 8`), what you are doing, and what comes next. Before a command that takes minutes — `himi site analyze`, `himi test --deep`, a QA build — say so, and roughly how long.
-- **Journal every postcard** with `himi progress "<what changed>" --step <n> --image <png>` when the installed CLI lists `progress` (`himi --help`). It keeps a copy of each image exactly as it was when you sent it, and a bare `himi progress` prints the journal with the current step — the quickest way back to your place.
-- **Give them a board to leave open.** When the installed CLI lists `studio`, run `himi studio` once, right after that first picture, and tell the owner it is there. It opens a local page in their browser that fills itself in — every screen as it renders, the journey step and your latest postcard, each check as it runs — so they can watch between your messages. It is a view of your local work, not the preview of step 7.
+- **Journal every postcard** with `himi progress "<what changed>" --step <n> --image <png>` when the installed CLI lists `progress` (`himi --help`). It keeps a copy of each image exactly as it was when you sent it, and a bare `himi progress` prints the journal with the current step — the quickest way back to your place. The CLI also journals the first picture of the home screen, every `himi test` crawl and every draft push by itself; your postcards are the ones that say why.
+- **Give them a board to leave open.** When the installed CLI lists `studio`, run `himi studio` once, right after that first picture, and tell the owner it is there (a current `himi init` has already made the board; this opens it). It opens a local page in their browser that fills itself in — every screen as it renders, the journey step and your latest postcard, each check as it runs — so they can watch between your messages. It is a view of your local work, not the preview of step 7.
 - **Let them click around while you work.** Once step 4's startup preflight says the app may boot locally, and when the installed CLI's `himi run` accepts `--watch`, keep `himi run --watch` running in the background: it serves the app on this machine, opens it in their browser (no `--browser` flag — that is a different mode, and `--watch` refuses it), and repaints that tab every time you save — and the board frames the same live app. Once the app is bound to their site, the watch preview shows that site's live data, fetched by their own browser as an anonymous visitor. It is a local preview of your working copy, never the owner-private preview, and a save that does not build leaves the last good version on screen while you fix it.
 - **Hand over the story too.** At the handover in step 7, when `himi --help` lists `himi studio reel` (an older CLI can have `studio` without it), run `himi studio reel` and offer the owner the file it writes: one self-contained page of their app taking shape, version by version, with your postcards. It shows how the app was built; it is never a substitute for the preview URL, and it carries the same sample-data captions the postcards did.
 
@@ -106,11 +106,19 @@ When there is no human in the loop (QA runner, cron, dispatched agent), do not i
 - Credentials already in the environment (`WIX_CLIENT_ID` / `WIX_SITE_URL`, a dpx session, `HIMI_CONTROL_TOKEN`) **are** consent to use that identity against the named target. Do not prompt for them again; do not mint a different site or account.
 - An explicit `--draft` / publish-draft instruction in the brief **is** owner-private preview approval. Do **not** promote live unless the brief says to.
 - QA binary / store submission still needs the brief to name that step; absence means skip it.
-- **Progress still goes somewhere.** With nobody reading the chat, keep the same milestones in the journal (`himi progress`), so whoever reads the run afterwards can see what was built and when.
+- **Progress still goes somewhere.** With nobody reading the chat, the pictures and postcards go to the journal (`himi progress`) and the build board instead — the steps below, in this session, while you build.
 - **Site creation is never implied.** `himi site create` spends money on the customer's account, so it needs the brief to name it explicitly, exactly like a QA binary. Absent that, a missing site is the gap you record — not something you fix by provisioning one.
 
 If a gate is not implied (no credentials, no draft instruction, no site URL for a Wix-backed app), stop and record the gap — do not guess a customer, site, or promotion.
 
+**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. When the installed `init` prints no `board`, run `himi studio --no-open` once in the app folder.
+2. **Keep the live preview running.** Once journey step 4's startup preflight clears the app to boot locally, start `himi run --watch &` in the app folder and leave it up until the handover: it repaints on every save and serves the board at `<url>/__himi/studio/`.
+3. **Make the first picture right after init:** `himi render <homeScreenId> --png --device iphone`. The CLI journals that first look itself.
+4. **A postcard with a picture at every journey step:** `himi progress "<what changed>" --step <n> --image .himi/shots/<screenId>.png`. `himi test` and `himi push --draft` journal their own results too; your postcards say what changed and why it matters.
+5. **At the handover, the making-of:** run `himi studio reel` and name the file it writes in your final report.
+
 ## Technical handoff
 
 Read https://apps.wix.com/_api/himi-serve/himi-skill.md only when you enter implementation. It contains the exact CLI, HTTP, MCP, template, worker, validation, release, and QA-build instructions. The transport-specific references are https://apps.wix.com/_api/himi-serve/skill-http.md and https://apps.wix.com/_api/himi-serve/skill-mcp.md; use them when the customer's environment needs those transports, while preserving this journey and its approval gates.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1069.0",
+  "version": "0.1071.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": [
@@ -65,5 +65,5 @@
       "artifactId": "himalaya-cli"
     }
   },
-  "falconPackageHash": "d66a8a95769c3eb84b52d4da2233db6689f1f833a2b254304aff2bc0"
+  "falconPackageHash": "6640fad907fef656cbb5c2fa0b681448939515cf50af74a45c59083c"
 }