[Art Studio] ArtPipe Generate-drawer composer parity — remaining deltas vs Eric's original (#446) #454

New Issue

2026-07-07T21:48:36Z

spikerj commented

2026-07-07 21:48:36 +00:00

Follow-up under epic #446. After the Generate-drawer flow was restored (#446 P2b, d1743e4) and the git-rail stage editor landed (#385), our art-prompt-composer is at/above parity with Eric's Generate Assets drawer (http://127.0.0.1:5050/) on the two big items:

✅ Hidden-until-clicked — + Generate → drawer (@if(drawerOpen())), matches Eric's openDrawer()/drawerOverlay.
✅ Collapsible pipeline stages — our rail renders concept → modeling → texturing → rigging → animation → export (+ our extra enrichment), each collapsible with a per-stage method select and auto/manual/skip badge — the equivalent of Eric's .dw-stages .dw-node list.

(Context: the always-visible/subpar view reported on 2026-07-07 was a stale deploy predating #385/#446 — the frontend image publish had been blocked by the #363 e2e flake until b1024b1. Current master is correct.)

Remaining parity deltas (minor)

Equipment asset type. Eric offers Character / Prop / Equipment; we expose only Character / Prop (ArtAssetType in art-studio.models.ts). ⚠️ Backend-coupled — the generation pipeline must accept equipment, so this is not a frontend-only change. Needs backend confirmation of support before wiring the toggle.
Theme selector (Random / fantasy / scifi / nature / urban / food / furniture). We deliberately use presets / preset-batch instead. Decision needed: adopt Eric's theme axis, keep presets, or offer both. Not obviously a regression.
Random prompt button. Eric has a randomPrompt() control next to the prompt field; we don't. Low-risk, frontend-only, but needs a small prompt corpus (per asset type) to seed from.

Suggested handling

(2) is a product/design decision (theme axis vs presets) — needs Joey's call before any code.
(1) needs a backend capability check first.
(3) is the only safe standalone frontend PR, and even it wants a curated prompt list.

Filing for triage rather than speculatively coding a backend-coupled type or overriding the presets design. Reference: libraries/features/art-studio/src/lib/art-prompt-composer/ and art-studio.models.ts.

Follow-up under epic #446. After the Generate-drawer flow was restored (#446 P2b, `d1743e4`) and the git-rail stage editor landed (#385), our `art-prompt-composer` is at/above parity with Eric's `Generate Assets` drawer (`http://127.0.0.1:5050/`) on the two big items: - ✅ **Hidden-until-clicked** — `+ Generate` → drawer (`@if(drawerOpen())`), matches Eric's `openDrawer()`/`drawerOverlay`. - ✅ **Collapsible pipeline stages** — our rail renders `concept → modeling → texturing → rigging → animation → export` (+ our extra `enrichment`), each collapsible with a per-stage method select and auto/manual/skip badge — the equivalent of Eric's `.dw-stages` `.dw-node` list. _(Context: the always-visible/subpar view reported on 2026-07-07 was a **stale deploy** predating #385/#446 — the frontend image publish had been blocked by the #363 e2e flake until `b1024b1`. Current master is correct.)_ ## Remaining parity deltas (minor) 1. **`Equipment` asset type.** Eric offers Character / Prop / **Equipment**; we expose only Character / Prop (`ArtAssetType` in `art-studio.models.ts`). ⚠️ **Backend-coupled** — the generation pipeline must accept `equipment`, so this is not a frontend-only change. Needs backend confirmation of support before wiring the toggle. 2. **`Theme` selector** (Random / fantasy / scifi / nature / urban / food / furniture). We deliberately use **presets / preset-batch** instead. Decision needed: adopt Eric's theme axis, keep presets, or offer both. Not obviously a regression. 3. **`Random prompt` button.** Eric has a `randomPrompt()` control next to the prompt field; we don't. Low-risk, frontend-only, but needs a small prompt corpus (per asset type) to seed from. ## Suggested handling - (2) is a **product/design decision** (theme axis vs presets) — needs Joey's call before any code. - (1) needs a **backend capability check** first. - (3) is the only safe standalone frontend PR, and even it wants a curated prompt list. Filing for triage rather than speculatively coding a backend-coupled type or overriding the presets design. Reference: `libraries/features/art-studio/src/lib/art-prompt-composer/` and `art-studio.models.ts`.

spikerj commented

2026-07-08 01:35:21 +00:00

Delta (3) — Random prompt — shipped. spikersoft-angular PR #153 (merged to master 58c4028): a "Surprise me" button under the prompt fills it with a curated kid-safe example for the current asset type (Character / Prop), corpus in art-studio.example-prompts.ts. Shown only in prompt mode.

Remaining two deltas are still blocked on decisions (not code):

Equipment asset type — confirmed backend ArtAssetType is Character / Prop only (SpikerSoft.Data/Mongos/ArtStudio/ArtAsset.cs); the Equipment hits elsewhere are unrelated GameServer code. Needs a backend enum + stage-plan support + a product decision on Equipment's pipeline before the frontend toggle is safe.
Theme selector vs presets — product/design call (we intentionally use presets/preset-batch instead of Eric's theme axis).

Keeping this open for (1)+(2). Whenever you make the theme call and/or greenlight backend Equipment support, I'll take the frontend side.

**Delta (3) — Random prompt — shipped.** spikersoft-angular PR #153 (merged to `master` `58c4028`): a "Surprise me" button under the prompt fills it with a curated kid-safe example for the current asset type (Character / Prop), corpus in `art-studio.example-prompts.ts`. Shown only in prompt mode. **Remaining two deltas are still blocked on decisions (not code):** 1. **Equipment asset type** — confirmed backend `ArtAssetType` is `Character` / `Prop` only (`SpikerSoft.Data/Mongos/ArtStudio/ArtAsset.cs`); the `Equipment` hits elsewhere are unrelated GameServer code. Needs a backend enum + stage-plan support + a product decision on Equipment's pipeline before the frontend toggle is safe. 2. **Theme selector vs presets** — product/design call (we intentionally use presets/preset-batch instead of Eric's theme axis). Keeping this open for (1)+(2). Whenever you make the theme call and/or greenlight backend Equipment support, I'll take the frontend side.

spikerj commented

2026-07-08 02:06:04 +00:00

Status pass on the three deltas — this ticket is now decision-only; no bounded frontend work remains.

Item 3 (Random prompt / "Surprise me") — ✅ DONE, shipped in Angular PR #153. The randomPrompt() button is wired in art-prompt-composer.component.html (with the composer.randomPrompt i18n key), the method is in the component (seeding from ART_EXAMPLE_PROMPTS[assetType()]), and it has spec coverage (incl. hidden-in-image-mode). The "needs a small prompt corpus" blocker is resolved — art-studio.example-prompts.ts ships 10 kid-safe prompts each for Character and Prop. Nothing left here.
Item 1 (Equipment asset type) — confirmed genuinely backend-coupled + design-gated. Verified: ArtAssetType in SpikerSoft.Data/Mongos/ArtStudio/ArtAsset.cs is { Character, Prop } only, and its doc comment states the type "determines the ordered stage plan (see ArtAssetStagePlans)." So Equipment isn't a frontend toggle or even just an enum add — it needs an Equipment stage-plan defined (which stages an equipment asset runs, and any Equipment-specific method defaults). That's a pipeline-design call. If/when you want it, that's the backend piece to spec first; the frontend toggle + an Equipment prompt corpus are then trivial follow-ons.
Item 2 (Theme selector vs presets) — still your product call (adopt Eric's theme axis / keep presets / offer both). No verification changes this one.

Net: item 3 closed out; items 1 and 2 both need your decision before any code. Leaving the ticket open as the tracker for those two.

Status pass on the three deltas — this ticket is now **decision-only**; no bounded frontend work remains. - **Item 3 (Random prompt / "Surprise me") — ✅ DONE, shipped in Angular PR #153.** The `randomPrompt()` button is wired in `art-prompt-composer.component.html` (with the `composer.randomPrompt` i18n key), the method is in the component (seeding from `ART_EXAMPLE_PROMPTS[assetType()]`), and it has spec coverage (incl. hidden-in-image-mode). The "needs a small prompt corpus" blocker is resolved — `art-studio.example-prompts.ts` ships 10 kid-safe prompts each for Character and Prop. Nothing left here. - **Item 1 (Equipment asset type) — confirmed genuinely backend-coupled + design-gated.** Verified: `ArtAssetType` in `SpikerSoft.Data/Mongos/ArtStudio/ArtAsset.cs` is `{ Character, Prop }` only, and its doc comment states the type *"determines the ordered stage plan (see ArtAssetStagePlans)."* So Equipment isn't a frontend toggle or even just an enum add — it needs an **Equipment stage-plan defined** (which stages an equipment asset runs, and any Equipment-specific method defaults). That's a pipeline-design call. If/when you want it, that's the backend piece to spec first; the frontend toggle + an Equipment prompt corpus are then trivial follow-ons. - **Item 2 (Theme selector vs presets) — still your product call** (adopt Eric's theme axis / keep presets / offer both). No verification changes this one. Net: item 3 closed out; items 1 and 2 both need your decision before any code. Leaving the ticket open as the tracker for those two.

spikerj commented

2026-07-08 22:49:18 +00:00

@spikerj Decision request — this ticket is blocked on two product calls; everything codeable has shipped. Answering the two questions below (even one-liners) unblocks it; both have a recommended default if you just want to say "do the recommended".

Q1 — Equipment asset type: define its stage plan?

Adding Equipment is a pipeline-design decision, not a toggle: ArtAssetType drives the ordered stage plan (ArtAssetStagePlans). Options:

(a) Recommended — Prop-shaped plan: Equipment = concept → modeling → texturing → export → enrichment (no rigging/animation, same as Prop), existing method defaults. Cheap to ship: enum value + stage plan + composer toggle + a 10-prompt Equipment corpus. Differentiation is semantic (prompt bias, catalog filtering) until we want equipment-specific stages.
(b) Bespoke plan: e.g. rigged/attachable equipment (weapon grips, attachment sockets) — needs real pipeline design and probably new art_pipe capabilities; a separate epic-sized ticket.
(c) Skip: drop Equipment from parity scope and close this half.

Q2 — Theme axis vs presets?

(a) Recommended — keep presets, no theme selector: our presets/preset-batch intentionally replaced Eric's Random/fantasy/scifi/… theme axis and are strictly more expressive; a second categorical axis next to them muddies the composer for kids.
(b) Offer both: add a theme dropdown that just prefixes/biases the prompt (frontend-only, small) — defensible if you want one-click flavor without picking a preset.
(c) Adopt themes, retire presets: closest to Eric's original, but a regression in flexibility.

If the answers are 1(a) + 2(a): I'll spec the small backend PR (enum + stage plan + validation/tests), then the frontend toggle + prompt corpus, and Q2 closes with no code. If 1(c) + 2(a), this whole ticket closes with no code.

@spikerj **Decision request** — this ticket is blocked on two product calls; everything codeable has shipped. Answering the two questions below (even one-liners) unblocks it; both have a recommended default if you just want to say "do the recommended". ### Q1 — Equipment asset type: define its stage plan? Adding Equipment is a pipeline-design decision, not a toggle: `ArtAssetType` drives the ordered stage plan (`ArtAssetStagePlans`). Options: - **(a) Recommended — Prop-shaped plan:** Equipment = `concept → modeling → texturing → export → enrichment` (no rigging/animation, same as Prop), existing method defaults. Cheap to ship: enum value + stage plan + composer toggle + a 10-prompt Equipment corpus. Differentiation is semantic (prompt bias, catalog filtering) until we want equipment-specific stages. - **(b) Bespoke plan:** e.g. rigged/attachable equipment (weapon grips, attachment sockets) — needs real pipeline design and probably new art_pipe capabilities; a separate epic-sized ticket. - **(c) Skip:** drop Equipment from parity scope and close this half. ### Q2 — Theme axis vs presets? - **(a) Recommended — keep presets, no theme selector:** our presets/preset-batch intentionally replaced Eric's Random/fantasy/scifi/… theme axis and are strictly more expressive; a second categorical axis next to them muddies the composer for kids. - **(b) Offer both:** add a theme dropdown that just prefixes/biases the prompt (frontend-only, small) — defensible if you want one-click flavor without picking a preset. - **(c) Adopt themes, retire presets:** closest to Eric's original, but a regression in flexibility. If the answers are 1(a) + 2(a): I'll spec the small backend PR (enum + stage plan + validation/tests), then the frontend toggle + prompt corpus, and Q2 closes with no code. If 1(c) + 2(a), this whole ticket closes with no code.

spikerj referenced this issue

2026-07-08 22:58:12 +00:00

[ArtStudio][Epic] Equipment asset type — bespoke attachable-equipment pipeline (stage plan, sockets/grips, art_pipe capabilities) #463

spikerj commented

2026-07-08 22:58:28 +00:00

Decisions from Joey (2026-07-08): Q1 = (b), Q2 = (a). That resolves everything this ticket was tracking — closing.

Q1 — Equipment asset type → (b) bespoke plan. Equipment gets a real attachable-equipment pipeline (sockets/grips, art_pipe capability work), not a Prop-shaped clone. Per this ticket's own scoping that's epic-sized design work, now tracked in #463 (spec-first: stage plan, attachment model, capabilities, method defaults; then enum/stage-plan/frontend-toggle/prompt-corpus implementation).
Q2 — Theme axis → (a) keep presets, no theme selector. Presets/preset-batch remain our intentional replacement for Eric's theme axis. No code; the composer stays as-is.
Item 3 (Random prompt / "Surprise me") already shipped in spikersoft-angular PR #153.

Parity scorecard vs Eric's drawer at close: hidden-until-clicked ✅, collapsible stages ✅, random prompt ✅, theme axis intentionally not adopted (Q2a), Equipment deferred to its own pipeline epic #463 (Q1b).

Decisions from Joey (2026-07-08): **Q1 = (b)**, **Q2 = (a)**. That resolves everything this ticket was tracking — closing. - **Q1 — Equipment asset type → (b) bespoke plan.** Equipment gets a real attachable-equipment pipeline (sockets/grips, art_pipe capability work), not a Prop-shaped clone. Per this ticket's own scoping that's epic-sized design work, now tracked in **#463** (spec-first: stage plan, attachment model, capabilities, method defaults; then enum/stage-plan/frontend-toggle/prompt-corpus implementation). - **Q2 — Theme axis → (a) keep presets, no theme selector.** Presets/preset-batch remain our intentional replacement for Eric's theme axis. No code; the composer stays as-is. - Item 3 (Random prompt / "Surprise me") already shipped in spikersoft-angular PR #153. Parity scorecard vs Eric's drawer at close: hidden-until-clicked ✅, collapsible stages ✅, random prompt ✅, theme axis intentionally not adopted (Q2a), Equipment deferred to its own pipeline epic #463 (Q1b).

spikerj closed this issue

2026-07-08 22:58:29 +00:00

spikerj referenced this issue

2026-07-20 15:26:28 +00:00

Child book read-context never built on real tokens: bare FindFirst("sub") nulled by JWT inbound claim mapping (breaks #729 household grants; #618 child gate fail-opens) #734

spikerj referenced this issue

2026-07-22 02:43:23 +00:00

Reading journey: let parents share their uploaded books with their children #729

spikerj referenced this issue

2026-07-22 03:16:33 +00:00

Epic: build the full parent-approval book model (upload approval chain, ApprovedBy audit, parent family/staff-uploads view, auto-Public-on-approval) #621

spikerj referenced this issue