@vitrinka/cli 5.16.1 → 5.17.1

package/CHANGELOG.md

@@ -3,6 +3,110 @@
 `vitrinka update` prints the sections newer than your previous version
 after updating — keep entries short and user-facing.
 
+## 5.17.1
+
+**A code-mode review shows the sheet as an image, never as text.** When
+a Codex code-mode script reads `get_card_image`, the `review` skill and
+the annotation docs now tell it to hand the image block to the host's
+image call (`image(block)`) and print only the text block. A script that
+logged the whole result would otherwise feed the image's base64 to the
+model as text, which is how one review's transcript grew to 41 GB.
+
+## 5.17.0
+
+**A ui-loop review keeps what did not move.** Each review batch carries a
+digest per screen and a reviewer records the digests of the screens it
+actually read, so retaking a few blank shots reopens only those screens,
+never every finished batch. A screen whose shots did not change since
+the previous pass is carried: it keeps its findings and verdicts, leaves
+the review batches and counts as reviewed, and the scoreboard callout
+names how many were carried.
+
+**Several review runs share one ui-loop pass.** Each `review-loop` run
+claims its own review batches, so a big pass can be reviewed by several
+identical runs at once: the review stage's return says how many
+(`parallel`), each of those runs continues as one, and a run that finds
+every batch left already claimed ends. A run whose reviewer failed hands
+its claimed batches to its own next run, which reviews them first.
+Only the run that takes the pass's synthesis lease writes the backlog,
+scores the pass and posts the callouts; any other ends saying another run
+is synthesizing. While a capture runs, every stage waits instead of
+starting beside it, and `areas` no longer narrows a review.
+
+**A stalled reviewer no longer stalls the pass.** A review batch whose
+reviewer stalls twice (the watchdog stops it) is split in halves, and the
+same run reviews them with the agents it has left. A half that stalls
+twice is blocked instead of retried: its screens stay unreviewed and are
+named in the run's problems, the pass still gets its backlog, and the
+loop then ends naming them, to judge by hand or reshoot, instead of
+reviewing the pass again.
+
+**A ui-loop polish loop can be paused.** `vybava ui-loop pause --reason
+"…"` drains the whole loop: no `review-loop` stage starts (it returns
+stage `paused`, a null `next` and the `resume` args to launch later),
+and a running stage ends at its next boundary, after its reviewer round,
+before the synthesis, between fix lanes or before Settle, keeping what
+it did. `vybava ui-loop resume` lifts the pause and frees the stopped
+runs' batch claims; launch the `resume` args and the loop goes on where
+it stopped.
+
+**A screen nobody could shoot is one line, not a broken finding.** A
+ui-loop screen marked `retired` (dead code, a plugin not installed, a
+feature off) is never shot, reviewed or counted, and `map` marks such
+screens instead of calling them unreachable. A screen without a single
+usable shot (unreachable, a failed recipe, an error) no longer counts
+against review coverage or gets filed as a broken finding: each area
+board's "Not captured this pass" card lists it once with its reason,
+instead of once per viewport and theme. The fix round's rig lane
+(below) repairs its recipe, and the screens a pass still has no shot of
+when it reaches its final check are named in one problems line and keep
+it from completing.
+
+**A cross-lane fix is reworked, not blocked.** A ui-loop fix lane whose
+fix needs a file another lane owns now defers the item with the change
+it needs there, and the fix stage gives it a rework lane after the area
+lanes that owns both, so it is fixed in the same round. A block now
+means the fix waits on something outside the repo (seed data, a
+backend, another repo, a decision), and the run that ends the fix round
+returns every such item of the round in one list, `ownerQuestions`, to
+ask their owner in a single batch. A skipped, blocked or deferred item
+stays checkpointed while its own files are unchanged, whatever other
+lanes commit; one that no longer counts is listed in the stage's
+`stale`, and the next fix round takes it.
+
+**A ui-loop fix round repairs its capture recipes.** The round ends with
+one rig lane that fixes the recipes a renamed label or a dead step broke:
+the literal names `vybava ui-loop check --labels` finds in no label
+source, the screens the pass never shot (unless the manifest marks them
+unreachable with the seed data) and those whose recipe failed; a screen
+whose code is dead or whose feature is off it marks `retired`. It
+reaches a control by its role and accessible name (the harness's
+`action` step) instead of a CSS or `nth=` selector, checks each repair
+with `vybava ui-loop run --probe` before it checkpoints it, re-renders
+the app map with them, and the verify pass reshoots those screens. A
+screen it cannot repair joins the round's `ownerQuestions` when its
+environment blocks it, or `reworkStuck` when the repair needs the app
+or the rig's project file. A pass whose review converged gets the same
+repair: the loop runs the rig lane on it and then captures the screens
+it repaired, instead of ending with them unshot. A label miss no longer
+stops a capture, and `map` writes new recipes the same way.
+
+**A ui-loop pass triages its failures.** After each capture, and before
+the review writes the backlog, `vybava ui-loop triage` groups the shots
+that failed by cause. Screens that failed on infrastructure (a network
+blip, a page that stayed blank) come back as one `vybava ui-loop run
+--retake …` command in the stage's problems, and one application
+failure behind many screens is filed as ONE broken item that names them
+all, instead of a finding per screen. A recipe whose literal left the app
+goes to the fix round's rig lane.
+Every ui-loop stage needs Výbava v0.45.0 or later (ui-loop state
+contract 10) and refuses an older one; run
+`brew upgrade --cask vybava`. Update vitrinka with it: an older vitrinka
+neither waits for a running capture, shares a review between runs nor
+splits a stalled batch, it cannot finish a review in which a newer one
+blocked a batch, it would complete a pass whose never-shot screens it
+never names, and it stops a fix round in which a lane deferred an item.
+
 ## 5.16.1
 
 **Every survey uses the contact sheet.** The `publish` and `resolve` skills

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vitrinka/cli",
-  "version": "5.16.1",
+  "version": "5.17.1",
   "description": "vitrinka CLI — capture and publish artifact sets, drive the annotation-board work queue. Thin npm launcher for the single-binary Go CLI.",
   "bin": {
     "vitrinka": "bin/vitrinka.js"
@@ -15,12 +15,12 @@
     "node": ">=18"
   },
   "optionalDependencies": {
-    "@vitrinka/cli-darwin-arm64": "5.16.1",
-    "@vitrinka/cli-darwin-x64": "5.16.1",
-    "@vitrinka/cli-linux-arm64": "5.16.1",
-    "@vitrinka/cli-linux-x64": "5.16.1",
-    "@vitrinka/cli-win32-arm64": "5.16.1",
-    "@vitrinka/cli-win32-x64": "5.16.1"
+    "@vitrinka/cli-darwin-arm64": "5.17.1",
+    "@vitrinka/cli-darwin-x64": "5.17.1",
+    "@vitrinka/cli-linux-arm64": "5.17.1",
+    "@vitrinka/cli-linux-x64": "5.17.1",
+    "@vitrinka/cli-win32-arm64": "5.17.1",
+    "@vitrinka/cli-win32-x64": "5.17.1"
   },
   "keywords": [
     "vitrinka",