# Character Studio and Outfit Generator — v1+ roadmap

Maintained 2026-10-05 · Operator: Jim / JMC · Interface release: v1.0.
The versions below group proposed work; they are not dates or promises to bundle
every item into one PR. Begin each implementation with a scoped activity plan.

## The working pipeline

The Oracle generates underlying Physicality. The wardrobe and Hair engines
generate a coherent presentation programmatically. The Studio preserves source
Appearance, applies one selected outfit, and assembles an editable visual brief.
Future LLM calls can refine an explicit draft; image providers can render its
chosen prompt. Neither connection is needed for the current workflow.

## v1.0 — released capability

| Component | Supported scope |
| --- | --- |
| Outfit Generator | Temperate humanoid Everyday/Formal/Active ensembles; independent wardrobe seeds, batches, holds, editable garments, palettes, removal/Undo |
| Hair | Nine coherent arrangements; length/texture confirmation; presentation/occasion/attitude/construction filters; independent seeds, regional edits, holds, baseline restoration, physical requirements |
| Character Studio | Oracle v0.1 single/batch JSON, manual visual identity, source-preserving projection, one selected outfit, covered marking/body-detail handling, signature IDs, editable reference-sheet prompt |
| Portability | Complete Studio JSON and selected outfit JSON; Clothes/Hair variable-notation Blocks; readable text; legacy document support |
| Workspace protection | Unexported-work indicator and browser unload warning; complete Studio export establishes a saved baseline |

The original plan's P5 adapters/direct handoff are still future work. Existing
JSON handoff is the supported v1.0 route. Example garments/styles remain authored
draft content after promotion; the tool's release does not make them Setting canon.

## Proposed sequence

| Phase | Deliverable | Completion evidence |
| --- | --- | --- |
| v1.1 — workflow | Direct selected-Oracle/batch-member handoff; optional local recovery; clearer workspace replacement and save controls | The same original record, edits, selection, and prompt survive transfer/recovery; no hidden regeneration or automatic overwrite |
| v1.1 — catalogue authoring | Repeatable content-pack guide and validation command for local-model-authored garments, ensembles, palettes, and Hair | A new pack loads with unique IDs, valid references/regions/requirements, source attribution, and a new reviewed catalogue version; prior saved records still restore |
| v1.2 — Ballad adapters | Explicitly supported Appearance and Attire/Clothing fragments, mapping reports, selected Appearance/Clothes/Hair export; later full Card support | Documented example dialects round-trip; unsupported fields remain visible; partial/malformed input is reported without replacing the workspace |
| v1.2 — presentation depth | More outfit occasions, climate/purpose preferences, prompt presets, and reconciled styling supports | An Intimate or work/combat purpose remains distinct; held conflicts are explained; each preset uses one coherent Character/outfit |
| Species extension — parallel track | Averall Human, Faefolken, Jotun, Dwarf, and other reviewed Physicality packs; shared generator or separate interfaces | Each pack has its own reviewed sources and anatomy assumptions; adapter mapping preserves the record and explicitly describes garment-fit limits |
| v1.x — optional providers | Explicit LLM refinement and image generation from the current programmatic draft | Requests use the chosen snapshot/prompt; source and manual edits survive; returned text/images retain request provenance and provider/settings |

Species packs can proceed independently of Studio changes. The existing Oracle
specifically represents Elves of Averall; shared formatting is an extension seam,
not evidence that another species is already modelled or fitted by the wardrobe.

## First follow-up: easier handoff and recovery

- Add **Open selected Character in Studio** to the Oracle only after defining
  the same-origin transfer format and explicit replace/open behaviour.
- Add optional browser recovery with a visible last-saved state and deliberate
  restore/reset. Explain whether storage is local to a device/origin and can be
  cleared. Downloaded JSON remains the portable authoritative handoff.
- Keep workspace data separate from transient seed/browse controls. If those
  controls become persistent, version and document their restoration separately.
- Continue testing clean startup, failed import/download, full-file restoration,
  and leaving with changed Character, wardrobe, holds, or manual prompt.

## Catalogue expansion and local-model trials

Runtime sources are small family files rather than one growing database:

- `Web/outfitgen/data/`: palettes, garment slots, occasion ensembles; catalogue manifest.
- `Web/outfitgen/data/hair/`: three construction families and its own manifest.
- `Web/elfgen/data/`: the Oracle's setting-specific structured sources, including
  Celine-derived `physicality.json`. Maintain attribution and descriptive depth.

A local-model task should supply one record contract, a few approved examples,
allowed vocabulary, and a bounded family/count. Review output for coherent
physical construction as well as JSON validity. Hair regions must describe one
style, requirement notes must say how it is supported, and occasion tags must
agree with the description. Keep new records separate until accepted.

Validate IDs, paths, vocabulary, references, coverage, complete regions, and
compatibility before admitting a pack. Changing content/order changes random
selection: advance its logical catalogue version, preserve old snapshots, and
establish new independent output evidence. Do not rewrite the old test digests
just to make changed generation pass. Reviewed packs can grow without changing
the UI architecture; extra anatomy or selection rules need their own design pass.

## Ballad and styling support

Source mapping authority is [SOURCES.md](../../Draft/character-studio/SOURCES.md):
Ballad `xmSpec` actorRolesheet Attire and `llmSpec` CharacterCard outfit conventions,
plus JMC's original `WhatIsAttire.md` intake. Refresh the referenced templates
before implementing an adapter. The current Blocks use XML containers with
variable notation; full-template strict XML parsing is not assumed.

Required Hair ties/pins are currently review notes. A later support resolver must
link an existing signature/headwear/outfit item or explicitly supply a new one,
assign stable IDs once, and preserve existing item colours. New supports may use
the outfit Accessory palette role. Headwear geometry requires real metadata before
it can become an automatic compatibility rule. Do not silently cut, dye, extend,
or transform hair to satisfy a style.

## Model integrations

Keep the bulk of semi-random generation programmatic and reproducible. An LLM
extension can revise the selected draft, propose a validated pack, or help map
unsupported prose. Preserve its original input and returned candidate separately
until applied; a refinement must not silently reroll identity or overwrite held edits.

Image generation should use the currently visible prompt and selected snapshot,
with explicit request controls and a stored result association. Multi-view sheets
still need image review. Provider setup, request limits, errors/cancellation,
credentials, cost visibility, and provenance belong to that later activity.

## Release and maintenance rules

- Product release numbers are separate from JSON schema, engine, and catalogue
  versions. v1.0 promotion leaves all existing replay/data contracts intact.
- Keep the runtime README and `_activity.md` current. Historical plans stay in
  `Draft/character-studio/`; the next task must distinguish implemented and proposed.
- Separate engine/DOM checks, deployed-browser evidence, and Jim's human review.
- All current files stay local to the browser; there is no server workspace or
  autosave. The unload warning cannot guarantee protection on every browser exit.
- Every PR should state its source revision, bounded change, checks, unresolved
  limitations, and continuation point. Existing working examples are useful fixtures.

Next recommended activity after v1.0 review: a bounded catalogue-authoring guide
and local-model trial, or direct Oracle handoff. Choose the one matching the next
real use; provider integration has no dependency on promoting this release.