@vitrinka/cli 5.16.0 → 5.17.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/CHANGELOG.md +128 -0
  2. package/package.json +7 -7
package/CHANGELOG.md CHANGED
@@ -3,6 +3,134 @@
3
3
  `vitrinka update` prints the sections newer than your previous version
4
4
  after updating — keep entries short and user-facing.
5
5
 
6
+ ## 5.17.0
7
+
8
+ **A ui-loop review keeps what did not move.** Each review batch carries a
9
+ digest per screen and a reviewer records the digests of the screens it
10
+ actually read, so retaking a few blank shots reopens only those screens,
11
+ never every finished batch. A screen whose shots did not change since
12
+ the previous pass is carried: it keeps its findings and verdicts, leaves
13
+ the review batches and counts as reviewed, and the scoreboard callout
14
+ names how many were carried.
15
+
16
+ **Several review runs share one ui-loop pass.** Each `review-loop` run
17
+ claims its own review batches, so a big pass can be reviewed by several
18
+ identical runs at once: the review stage's return says how many
19
+ (`parallel`), each of those runs continues as one, and a run that finds
20
+ every batch left already claimed ends. A run whose reviewer failed hands
21
+ its claimed batches to its own next run, which reviews them first.
22
+ Only the run that takes the pass's synthesis lease writes the backlog,
23
+ scores the pass and posts the callouts; any other ends saying another run
24
+ is synthesizing. While a capture runs, every stage waits instead of
25
+ starting beside it, and `areas` no longer narrows a review.
26
+
27
+ **A stalled reviewer no longer stalls the pass.** A review batch whose
28
+ reviewer stalls twice (the watchdog stops it) is split in halves, and the
29
+ same run reviews them with the agents it has left. A half that stalls
30
+ twice is blocked instead of retried: its screens stay unreviewed and are
31
+ named in the run's problems, the pass still gets its backlog, and the
32
+ loop then ends naming them, to judge by hand or reshoot, instead of
33
+ reviewing the pass again.
34
+
35
+ **A ui-loop polish loop can be paused.** `vybava ui-loop pause --reason
36
+ "…"` drains the whole loop: no `review-loop` stage starts (it returns
37
+ stage `paused`, a null `next` and the `resume` args to launch later),
38
+ and a running stage ends at its next boundary, after its reviewer round,
39
+ before the synthesis, between fix lanes or before Settle, keeping what
40
+ it did. `vybava ui-loop resume` lifts the pause and frees the stopped
41
+ runs' batch claims; launch the `resume` args and the loop goes on where
42
+ it stopped.
43
+
44
+ **A screen nobody could shoot is one line, not a broken finding.** A
45
+ ui-loop screen marked `retired` (dead code, a plugin not installed, a
46
+ feature off) is never shot, reviewed or counted, and `map` marks such
47
+ screens instead of calling them unreachable. A screen without a single
48
+ usable shot (unreachable, a failed recipe, an error) no longer counts
49
+ against review coverage or gets filed as a broken finding: each area
50
+ board's "Not captured this pass" card lists it once with its reason,
51
+ instead of once per viewport and theme. The fix round's rig lane
52
+ (below) repairs its recipe, and the screens a pass still has no shot of
53
+ when it reaches its final check are named in one problems line and keep
54
+ it from completing.
55
+
56
+ **A cross-lane fix is reworked, not blocked.** A ui-loop fix lane whose
57
+ fix needs a file another lane owns now defers the item with the change
58
+ it needs there, and the fix stage gives it a rework lane after the area
59
+ lanes that owns both, so it is fixed in the same round. A block now
60
+ means the fix waits on something outside the repo (seed data, a
61
+ backend, another repo, a decision), and the run that ends the fix round
62
+ returns every such item of the round in one list, `ownerQuestions`, to
63
+ ask their owner in a single batch. A skipped, blocked or deferred item
64
+ stays checkpointed while its own files are unchanged, whatever other
65
+ lanes commit; one that no longer counts is listed in the stage's
66
+ `stale`, and the next fix round takes it.
67
+
68
+ **A ui-loop fix round repairs its capture recipes.** The round ends with
69
+ one rig lane that fixes the recipes a renamed label or a dead step broke:
70
+ the literal names `vybava ui-loop check --labels` finds in no label
71
+ source, the screens the pass never shot (unless the manifest marks them
72
+ unreachable with the seed data) and those whose recipe failed; a screen
73
+ whose code is dead or whose feature is off it marks `retired`. It
74
+ reaches a control by its role and accessible name (the harness's
75
+ `action` step) instead of a CSS or `nth=` selector, checks each repair
76
+ with `vybava ui-loop run --probe` before it checkpoints it, re-renders
77
+ the app map with them, and the verify pass reshoots those screens. A
78
+ screen it cannot repair joins the round's `ownerQuestions` when its
79
+ environment blocks it, or `reworkStuck` when the repair needs the app
80
+ or the rig's project file. A pass whose review converged gets the same
81
+ repair: the loop runs the rig lane on it and then captures the screens
82
+ it repaired, instead of ending with them unshot. A label miss no longer
83
+ stops a capture, and `map` writes new recipes the same way.
84
+
85
+ **A ui-loop pass triages its failures.** After each capture, and before
86
+ the review writes the backlog, `vybava ui-loop triage` groups the shots
87
+ that failed by cause. Screens that failed on infrastructure (a network
88
+ blip, a page that stayed blank) come back as one `vybava ui-loop run
89
+ --retake …` command in the stage's problems, and one application
90
+ failure behind many screens is filed as ONE broken item that names them
91
+ all, instead of a finding per screen. A recipe whose literal left the app
92
+ goes to the fix round's rig lane.
93
+ Every ui-loop stage needs Výbava v0.45.0 or later (ui-loop state
94
+ contract 10) and refuses an older one; run
95
+ `brew upgrade --cask vybava`. Update vitrinka with it: an older vitrinka
96
+ neither waits for a running capture, shares a review between runs nor
97
+ splits a stalled batch, it cannot finish a review in which a newer one
98
+ blocked a batch, it would complete a pass whose never-shot screens it
99
+ never names, and it stops a fix round in which a lane deferred an item.
100
+
101
+ ## 5.16.1
102
+
103
+ **Every survey uses the contact sheet.** The `publish` and `resolve` skills
104
+ and the experimental `test` flow now survey a set with `get_card_image
105
+ {cardIds}` and measure on a single-card read, like `review`. When the server
106
+ is busy, a sheet now tells the agent to retry instead of dropping the card,
107
+ so a survey no longer silently loses a screen.
108
+
109
+ **A ui-loop stage checks its Výbava before it starts.** `review-loop`
110
+ reads the contract number `vybava ui-loop state` reports and runs
111
+ `vybava ui-loop doctor` for the stage: an older Výbava, a state field it
112
+ did not report, or a failing doctor check stops the run before anything
113
+ changes, naming the fix. Reviewers judge against the grid and touch
114
+ target your `vybava.config.ts` sets.
115
+
116
+ **A ui-loop pass knows when its shots went stale.** `vybava ui-loop
117
+ state` reports what changed since a pass was captured (application
118
+ source, the capture rig, the spec's rules), and `review-loop` runs the
119
+ stage it routes to as it is, including the exact screens a verify
120
+ reshoots, or every screen when a shared primitive changed. A stage you
121
+ asked for is never swapped for a capture: when the app drifted it stops,
122
+ lists the changed paths and hands back the capture to run, and a run
123
+ limited to `areas` never shoots. Spec rules changed since the capture
124
+ reach reviewers and fixers as final owner decisions; a screen no reviewer
125
+ could judge (a missing or blank shot) is filed as a recipe or capture
126
+ finding the fix round repairs and the verify reshoots, not recaptured.
127
+ A pass whose captured revision this clone lacks, or one shot before
128
+ passes recorded their revision, hands back a capture (or the fetch)
129
+ instead of running on shots nobody can date.
130
+ Every ui-loop stage needs Výbava v0.35.0 or later (ui-loop state
131
+ contract 2) and refuses an older one; run
132
+ `brew upgrade --cask vybava`.
133
+
6
134
  ## 5.16.0
7
135
 
8
136
  **Review a set of screens through one contact sheet.** `get_card_image`
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@vitrinka/cli",
3
- "version": "5.16.0",
3
+ "version": "5.17.0",
4
4
  "description": "vitrinka CLI — capture and publish artifact sets, drive the annotation-board work queue. Thin npm launcher for the single-binary Go CLI.",
5
5
  "bin": {
6
6
  "vitrinka": "bin/vitrinka.js"
@@ -15,12 +15,12 @@
15
15
  "node": ">=18"
16
16
  },
17
17
  "optionalDependencies": {
18
- "@vitrinka/cli-darwin-arm64": "5.16.0",
19
- "@vitrinka/cli-darwin-x64": "5.16.0",
20
- "@vitrinka/cli-linux-arm64": "5.16.0",
21
- "@vitrinka/cli-linux-x64": "5.16.0",
22
- "@vitrinka/cli-win32-arm64": "5.16.0",
23
- "@vitrinka/cli-win32-x64": "5.16.0"
18
+ "@vitrinka/cli-darwin-arm64": "5.17.0",
19
+ "@vitrinka/cli-darwin-x64": "5.17.0",
20
+ "@vitrinka/cli-linux-arm64": "5.17.0",
21
+ "@vitrinka/cli-linux-x64": "5.17.0",
22
+ "@vitrinka/cli-win32-arm64": "5.17.0",
23
+ "@vitrinka/cli-win32-x64": "5.17.0"
24
24
  },
25
25
  "keywords": [
26
26
  "vitrinka",