@genex-ai/cli-demo 0.48.0-dev.79 → 0.48.0-dev.80

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.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@genex-ai/cli-demo",
3
- "version": "0.48.0-dev.79",
3
+ "version": "0.48.0-dev.80",
4
4
  "description": "Set up your ~/.claude workspace, authorize, create a game project, generate AI assets, and publish (genex CLI).",
5
5
  "type": "module",
6
6
  "bin": {
@@ -28,15 +28,19 @@ ring) that no hand-written CSS can fake.
28
28
  the CSS placeholder, finished to `$genex-threejs-game-ui`'s Tier-1 floor,
29
29
  ships as the HUD.
30
30
 
31
- ## Three layers — glass is CSS, chrome is sprites, data is DOM
32
-
33
- - **Glass (DOM).** The translucent plate behind every widget is CSS —
34
- `background: rgba(<brief's darkest hue>, 0.35–0.6)` plus
35
- `backdrop-filter: blur(6–12px)` (and its `-webkit-` twin). Semi-transparency
36
- physically cannot survive sprite extraction: a composited panel's pixels are
37
- a blend of panel and background, and no cutout can un-blend them so glass
38
- is NEVER baked into a sprite. This is how AAA smoked-glass HUDs are built:
39
- live glass panels, crisp art on top.
31
+ ## Three layers — plates are DOM, chrome is sprites, data is DOM
32
+
33
+ - **Plate (DOM).** The backing surface behind a widget is built in CSS — in
34
+ whatever register the brief and concept frame call for: smoked glass
35
+ (`background: rgba(<darkest hue>, 0.35–0.6)` + `backdrop-filter: blur(6–12px)`
36
+ and its `-webkit-` twin) when the style wants translucency, a solid painted
37
+ plate, a subtle gradient or no plate at all for an outline-led look.
38
+ **Glass is a technique, not a default** do not reach for translucency
39
+ because this skill mentions it; reach for it when THIS game's brief does.
40
+ What is fixed is WHERE plates are built — the DOM — because
41
+ semi-transparency physically cannot survive sprite extraction: a composited
42
+ panel's pixels are a blend of panel and background, and no cutout can
43
+ un-blend them. Plates are NEVER baked into sprites.
40
44
  - **Chrome (sprites — what THIS pipeline generates).** Opaque frames, corner
41
45
  brackets, ornaments, emblems, icons, medallions — hard-alpha art laid over
42
46
  the glass. The Stage-2 sheet contains ONLY chrome; never a panel with its
@@ -60,10 +64,11 @@ The HUD overlays a **live 3D scene**. The pixels between widgets show the game.
60
64
  fabric, wood board) as part of the HUD. Material aesthetics belong on the
61
65
  widget FRAMES — the HP bar frame is parchment, the minimap ring is leather —
62
66
  never on a screen-filling sprite.
63
- - **No glass in sprites.** Translucent panel plates in the mockup are welcome
64
- as the LOOK, but the Stage-2 asset list requests only their opaque chrome
65
- (frame, brackets, ornament); the plate itself is rebuilt at runtime as CSS
66
- glass matching the mockup's tint (see the three layers above).
67
+ - **No plates in sprites.** Panel plates in the mockup translucent or
68
+ solid — are welcome as the LOOK, but the Stage-2 asset list requests only
69
+ their opaque chrome (frame, brackets, ornament); the plate itself is
70
+ rebuilt at runtime in CSS matching the mockup's tint (see the three layers
71
+ above).
67
72
  - **4–7 widgets.** Fewer doesn't read as a HUD; more clutters the screen and
68
73
  burns generations.
69
74
  - **Every widget needs internal contrast** — a panel fill, outline stroke, or
@@ -15,10 +15,10 @@ Fill `[ASSET_LIST]`, then pass the whole text as the prompt to
15
15
  identity labels);
16
16
  - **states what to REMOVE** (`runtime_static` labels and `runtime_dynamic`
17
17
  values, fills, items);
18
- - **requests chrome only** — never a panel's translucent plate or glass
19
- surface: plates are rebuilt at runtime as CSS glass (rgba +
20
- backdrop-filter), so ask for the panel's frame/brackets/ornament, not the
21
- panel surface itself;
18
+ - **requests chrome only** — never a panel's plate/backing surface,
19
+ translucent or solid: plates are rebuilt at runtime in CSS (rgba,
20
+ backdrop-filter, or a solid fill — whatever matches the mockup), so ask
21
+ for the panel's frame/brackets/ornament, not the panel surface itself;
22
22
  - **requests the annotated duplicate** for every bar/meter frame (the
23
23
  template's progress block below covers the mechanics — your item just says
24
24
  "output the clean frame + annotated duplicate pair").
@@ -110,6 +110,33 @@ Three.js release or branch, and do not blindly copy demo architecture.
110
110
  13. Validate in a real browser with fixed seeds, captures, interaction checks,
111
111
  and performance evidence.
112
112
 
113
+ ## Parallelize with subagents (when the environment has them)
114
+
115
+ Generations already render server-side in parallel — the wall-clock savings
116
+ live in the ATTENDED chains. When the coding agent supports background
117
+ subagents (e.g. Claude Code's Agent tool), split these off; in environments
118
+ without them (Cursor), the same order simply runs sequentially and the
119
+ `--no-wait` pattern still hides most generation latency.
120
+
121
+ - **HUD chain worker.** The moment the Stage-1 mockup lands, hand the whole
122
+ `$genex-ai-hud` chain to one subagent: pick the better candidate → Stage-2
123
+ sheet → clean → extract → masks → write the sprite wiring. Its prompt must
124
+ be self-contained — the style brief, concept-frame and mockup URLs, the
125
+ output dir, and exactly which files it owns.
126
+ - **Asset shepherd.** One subagent runs `npx genex wait` on every queued ID
127
+ and wires each asset in as it lands (skybox, models, menu video, dressing),
128
+ swapping placeholders out and reporting each swap.
129
+ - **Verification runner.** Browser evidence — screenshots, control presses,
130
+ the menu loop-seam watch, in-situ checks of placed art — can run in a
131
+ subagent while the main agent keeps building.
132
+
133
+ Hard rules: **one writer per file** — each subagent owns a disjoint file set
134
+ (the HUD worker owns the hud modules and `public/assets/hud/`, the shepherd
135
+ owns asset-wiring modules), and the main agent stays the only writer of
136
+ gameplay/netcode. Merge points are explicit: a subagent reports what it
137
+ changed, the main agent reconciles. Never put two writers on the same
138
+ module — a corrupted entry point costs more than the minutes saved.
139
+
113
140
  ## Acceptance gate
114
141
 
115
142
  **Game fast path:** for a game task that loaded no procedural/visual-system skill,