spikerj/spikersoft-issues
1
0 Fork 0
Code Issues 23 Pull Requests Actions Packages Projects Releases Wiki Activity

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

New Issue
Closed
opened 2026-07-08 22:58:12 +00:00 by spikerj · 1 comment
spikerj commented 2026-07-08 22:58:12 +00:00
Owner
Copy link
Copy source

Spun out of #454 (Q1 = option b): Equipment becomes a first-class ArtAssetType with a bespoke pipeline, not a Prop-shaped clone. This is a pipeline-design epic — spec before code.

Product intent

Equipment assets are meant to be used by characters: weapons, tools, wearables. The differentiator vs Prop is attachability/wieldability — which is exactly what makes the plan bespoke instead of Prop-shaped.

Design questions to settle (spec phase)

  • Stage plan: which ordered stages does Equipment run (see ArtAssetStagePlans)? Likely concept → modeling → texturing → attachment/socket definition → export → enrichment; rigging in the character sense probably wrong, but grip/socket metadata is the whole point.
  • Attachment model: how are sockets/grips represented (bone? empty/locator? named socket convention) and how do they survive export (GLB extras? separate sidecar)?
  • art_pipe capabilities: what new worker capabilities/actions are needed (e.g. socket placement, scale normalization against a reference character rig)? Manifest + capability→action resolution per #346 conventions.
  • Method defaults: per-stage method allow-list entries for Equipment (ArtStudioStageMethodOptions), incl. whether text→3D (shap_e) makes sense for equipment.
  • GameServer consumption: how does the equip/attach side consume the metadata (this is where the existing GameServer "Equipment" code intersects — verified in #454 as currently unrelated)?

Implementation (after spec)

  • Backend: ArtAssetType.Equipment (SpikerSoft.Data/Mongos/ArtStudio/ArtAsset.cs) + Equipment entry in ArtAssetStagePlans + validation/tests
  • Worker: new/extended art_pipe stage capabilities per spec
  • Frontend: composer asset-type toggle (Character / Prop / Equipment) + 10-prompt kid-safe Equipment corpus (art-studio.example-prompts.ts) — trivial follow-ons per #454
  • Catalog/gallery filtering by the new type

References

  • #454 (parity ticket; Q1 decision recorded there) · epic #446 (Eric's Generate-drawer parity)
  • ArtAssetStagePlans, ArtStudioStageMethodOptions (stage/method machinery), #378 W1/W1.5 for the allow-list + failover conventions

Child issues (per-repo, auto-close on merge)

No open child issues were produced by the migration — either this epic's
work was already complete, or its scope needs to be broken down into
per-repo issues before it can progress.

Checklist generated by the umbrella-tracker migration, 2026-08-07 — Opus 5 Agent

Spun out of #454 (Q1 = option b): Equipment becomes a first-class ArtAssetType with a **bespoke pipeline**, not a Prop-shaped clone. This is a pipeline-design epic — spec before code. ## Product intent Equipment assets are meant to be **used by characters**: weapons, tools, wearables. The differentiator vs Prop is attachability/wieldability — which is exactly what makes the plan bespoke instead of Prop-shaped. ## Design questions to settle (spec phase) - [ ] **Stage plan**: which ordered stages does Equipment run (see `ArtAssetStagePlans`)? Likely concept → modeling → texturing → **attachment/socket definition** → export → enrichment; rigging in the character sense probably wrong, but grip/socket metadata is the whole point. - [ ] **Attachment model**: how are sockets/grips represented (bone? empty/locator? named socket convention) and how do they survive export (GLB extras? separate sidecar)? - [ ] **art_pipe capabilities**: what new worker capabilities/actions are needed (e.g. socket placement, scale normalization against a reference character rig)? Manifest + capability→action resolution per #346 conventions. - [ ] **Method defaults**: per-stage method allow-list entries for Equipment (`ArtStudioStageMethodOptions`), incl. whether text→3D (shap_e) makes sense for equipment. - [ ] **GameServer consumption**: how does the equip/attach side consume the metadata (this is where the existing GameServer "Equipment" code intersects — verified in #454 as currently unrelated)? ## Implementation (after spec) - [ ] Backend: `ArtAssetType.Equipment` (SpikerSoft.Data/Mongos/ArtStudio/ArtAsset.cs) + Equipment entry in `ArtAssetStagePlans` + validation/tests - [ ] Worker: new/extended art_pipe stage capabilities per spec - [ ] Frontend: composer asset-type toggle (Character / Prop / Equipment) + 10-prompt kid-safe Equipment corpus (`art-studio.example-prompts.ts`) — trivial follow-ons per #454 - [ ] Catalog/gallery filtering by the new type ## References - #454 (parity ticket; Q1 decision recorded there) · epic #446 (Eric's Generate-drawer parity) - `ArtAssetStagePlans`, `ArtStudioStageMethodOptions` (stage/method machinery), #378 W1/W1.5 for the allow-list + failover conventions <!-- BEGIN MIGRATED-CHILDREN --> --- ## Child issues (per-repo, auto-close on merge) _No open child issues were produced by the migration — either this epic's work was already complete, or its scope needs to be broken down into per-repo issues before it can progress._ <sub>Checklist generated by the umbrella-tracker migration, 2026-08-07 — Opus 5 Agent</sub> <!-- END MIGRATED-CHILDREN -->
spikerj added the epic label 2026-08-07 13:43:01 +00:00
spikerj commented 2026-08-07 14:29:44 +00:00
Author
Owner
Copy link
Copy source

Dissolved into per-repo issues as part of the umbrella-tracker breakup. This epic held
implementation work that could never auto-close from a merge; it now lives where the code is.

This epic was nine unanswered checkboxes, five of them pure design questions. Rather than
manufacture implementation tickets on top of undecided design, three of the four children are
explicit decision issues — each states the concrete, code-grounded options and what has to be
settled, and each is closeable by merging the recorded decision in the repo that will host the
answer.

  • ArtPipe (decision): spikerj/spikersoft-artpipe#61 — socket/grip representation and how it
    survives GLB export. Options are grounded in real code: (a) armature bones extending
    CANONICAL_PROP_HIERARCHY (src/artpipe/bones.py:207-209), which already survives export via
    export_skins; (b) empties + artpipe_socket_* custom props (precedent:
    blender/headless/rigging_cmds.py:669-740), which needs export_extras=True and a wider export
    selection; (c) an enrichment sidecar JSON with the GLB untouched.
  • Backend — stage plan (decision + landing): spikerj/spikersoft-backend#617 — which stages
    Equipment runs, the per-stage method allow-list, and landing ArtAssetType.Equipment itself.
    Decision and landing are one issue because ArtAssetStagePlans.GetPlan does a bare
    Plans[assetType] (ArtAssetStagePlans.cs:54) — a new enum member with no plan entry is a
    KeyNotFoundException on every submit.
  • Backend — games manifest (decision): spikerj/spikersoft-backend#618 — how the equip/attach side
    consumes the metadata, i.e. whether ArtAssetManifest
    (Queries/GetArtAssetManifest/GetArtAssetManifestQuery.cs:38-62) gains an attachment block,
    where socket data is persisted, and whether a character-side target-slot contract is needed
    alongside GameArtSlotRegistry.
  • Angular (implementation): spikerj/spikersoft-angular#719 — the one genuinely-decided piece:
    composer asset-type toggle, 10-prompt kid-safe corpus, i18n, library/gallery filter.

Already shipped, no issue filed — the "art_pipe capabilities" checkbox is largely done.
Verified against spikersoft-artpipe@7082d26 (main): equipment is already a first-class asset
type in art_pipe, end to end —
ASSET_TYPE_STAGES["equipment"] = [concept, modeling, texturing, rigging, export, enrichment]
(src/artpipe/config.py:562-567), poly-budget/topology/UV/thin-feature gates
(config.py:221, 226-228, 278, 285, 292, 307), node-graph stage gates
(batch/node_registry.py:133, 152, 200), prop/equipment rig scoring (batch/rig_scoring.py:41, 103),
concept prompt shaping and template mapping (batch/stages/modeling.py:640-641, 678;
config.py:628), a batch prompt corpus (batch/generator.py:266-466), a committed graph
(pipelines/equipment.json, rig_profile: PROP, target_faces: 2000), and a rig_mesh action
that already accepts asset_type: character | prop | equipment
(models/Blender/artpipe.json). The ONLY missing art_pipe capability is socket placement, which
is spikerj/spikersoft-artpipe#61.

Two findings worth carrying forward, both recorded in the children:

  1. The two stage-plan registries have already drifted: art_pipe runs rigging for prop
    (config.py:563), the backend's Prop plan does not (ArtAssetStagePlans.cs:32-39). Deciding
    Equipment means deciding which side is authoritative.
  2. Every rigging option in ArtStudioStageMethodOptions.CreateDefault() hardcodes
    Params["asset_type"] = "character" (ArtStudioStageMethodOptions.cs:236, 241, 246, 251, 256),
    mirroring the worker's shipped ArtPipe:StageSettings. If Equipment ran rigging with today's
    allow-list it would get a character rig — precisely the wrong outcome. The allow-list is
    keyed by stage only (_byStage, line 51) and has no asset-type dimension, which is the
    structural question behind "method defaults per asset type".

Nothing Equipment-shaped exists on the backend (spikersoft-backend@9810202: ArtAssetType is
{Character, Prop, PhotoStack}, ArtAsset.cs:558-570) or in the frontend
(spikersoft-angular@8e5a404: art-studio.models.ts:10-15; the composer offers exactly two types,
art-prompt-composer.component.html:38, 42). GET https://api.spikersoft.com/healthz → Healthy;
the ArtStudio endpoints are auth-gated (/api/artstudio/method-options → 401) and no Equipment
asset can exist yet, so there is nothing further runtime-observable to probe.

The unit is tracked by the shared [Equipment] title prefix and by sibling cross-links in each
issue. Closing here — the umbrella tracker is being emptied.

— Opus 5 Agent

Dissolved into per-repo issues as part of the umbrella-tracker breakup. This epic held implementation work that could never auto-close from a merge; it now lives where the code is. **This epic was nine unanswered checkboxes, five of them pure design questions.** Rather than manufacture implementation tickets on top of undecided design, three of the four children are explicit **decision issues** — each states the concrete, code-grounded options and what has to be settled, and each is closeable by merging the recorded decision in the repo that will host the answer. - ArtPipe (decision): spikerj/spikersoft-artpipe#61 — socket/grip representation and how it survives GLB export. Options are grounded in real code: (a) armature bones extending `CANONICAL_PROP_HIERARCHY` (`src/artpipe/bones.py:207-209`), which already survives export via `export_skins`; (b) empties + `artpipe_socket_*` custom props (precedent: `blender/headless/rigging_cmds.py:669-740`), which needs `export_extras=True` and a wider export selection; (c) an enrichment sidecar JSON with the GLB untouched. - Backend — stage plan (decision + landing): spikerj/spikersoft-backend#617 — which stages Equipment runs, the per-stage method allow-list, and landing `ArtAssetType.Equipment` itself. Decision and landing are one issue because `ArtAssetStagePlans.GetPlan` does a bare `Plans[assetType]` (`ArtAssetStagePlans.cs:54`) — a new enum member with no plan entry is a `KeyNotFoundException` on every submit. - Backend — games manifest (decision): spikerj/spikersoft-backend#618 — how the equip/attach side consumes the metadata, i.e. whether `ArtAssetManifest` (`Queries/GetArtAssetManifest/GetArtAssetManifestQuery.cs:38-62`) gains an attachment block, where socket data is persisted, and whether a character-side target-slot contract is needed alongside `GameArtSlotRegistry`. - Angular (implementation): spikerj/spikersoft-angular#719 — the one genuinely-decided piece: composer asset-type toggle, 10-prompt kid-safe corpus, i18n, library/gallery filter. **Already shipped, no issue filed — the "art_pipe capabilities" checkbox is largely done.** Verified against `spikersoft-artpipe@7082d26` (main): `equipment` is already a first-class asset type in art_pipe, end to end — `ASSET_TYPE_STAGES["equipment"] = [concept, modeling, texturing, rigging, export, enrichment]` (`src/artpipe/config.py:562-567`), poly-budget/topology/UV/thin-feature gates (`config.py:221, 226-228, 278, 285, 292, 307`), node-graph stage gates (`batch/node_registry.py:133, 152, 200`), prop/equipment rig scoring (`batch/rig_scoring.py:41, 103`), concept prompt shaping and template mapping (`batch/stages/modeling.py:640-641, 678`; `config.py:628`), a batch prompt corpus (`batch/generator.py:266-466`), a committed graph (`pipelines/equipment.json`, `rig_profile: PROP`, `target_faces: 2000`), and a `rig_mesh` action that already accepts `asset_type: character | prop | equipment` (`models/Blender/artpipe.json`). The ONLY missing art_pipe capability is socket placement, which is spikerj/spikersoft-artpipe#61. **Two findings worth carrying forward, both recorded in the children:** 1. The two stage-plan registries have **already drifted**: art_pipe runs `rigging` for `prop` (`config.py:563`), the backend's Prop plan does not (`ArtAssetStagePlans.cs:32-39`). Deciding Equipment means deciding which side is authoritative. 2. Every rigging option in `ArtStudioStageMethodOptions.CreateDefault()` hardcodes `Params["asset_type"] = "character"` (`ArtStudioStageMethodOptions.cs:236, 241, 246, 251, 256`), mirroring the worker's shipped `ArtPipe:StageSettings`. If Equipment ran rigging with today's allow-list it would get a **character** rig — precisely the wrong outcome. The allow-list is keyed by stage only (`_byStage`, line 51) and has no asset-type dimension, which is the structural question behind "method defaults per asset type". Nothing Equipment-shaped exists on the backend (`spikersoft-backend@9810202`: `ArtAssetType` is `{Character, Prop, PhotoStack}`, `ArtAsset.cs:558-570`) or in the frontend (`spikersoft-angular@8e5a404`: `art-studio.models.ts:10-15`; the composer offers exactly two types, `art-prompt-composer.component.html:38, 42`). `GET https://api.spikersoft.com/healthz` → `Healthy`; the ArtStudio endpoints are auth-gated (`/api/artstudio/method-options` → 401) and no Equipment asset can exist yet, so there is nothing further runtime-observable to probe. The unit is tracked by the shared `[Equipment]` title prefix and by sibling cross-links in each issue. Closing here — the umbrella tracker is being emptied. — Opus 5 Agent
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
agentic
Actionable surfaced by the agentic architecture & security review
 bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 epic
Cross-repo epic — children live in per-repo trackers
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 sonarqube
Code quality issue surfaced by SonarQube (bug / code smell)
 wontfix
This won't be fixed
No labels epic
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
spikerj (Joseph Spiker)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#463