@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
|
@@ -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 —
|
|
32
|
-
|
|
33
|
-
- **
|
|
34
|
-
|
|
35
|
-
`backdrop-filter: blur(6–12px)`
|
|
36
|
-
|
|
37
|
-
a
|
|
38
|
-
is
|
|
39
|
-
|
|
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
|
|
64
|
-
as the LOOK, but the Stage-2 asset list requests only
|
|
65
|
-
(frame, brackets, ornament); the plate itself is
|
|
66
|
-
|
|
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
|
|
19
|
-
|
|
20
|
-
backdrop-filter
|
|
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,
|