# Keep a changing character's current form clear

Use this optional authoring module when an original adult character can change appearance. It adapts a supplied three-page transformation prompt block into a current-form record and an image handoff. The source has no visible author, date, or recorded trials. Its instructions are reference material; they do not create a native OD simulation or connect memory to an image route.

## Separate form, stage, and accepted event

A **form** identifies the intended appearance. A **stage** says how far an established transition has progressed. Keep them separate: `granite form` identifies an appearance; `hands changed, face unchanged` describes a partial stage. A character can also be fully disguised without passing through every stage listed in a template.

Maintain one resolved appearance for the accepted moment. A partial transformation may deliberately combine traits from two forms. Describe that specific mixture rather than treating every mixed image as a failure. Clothing changes need their own established facts; a transformation does not automatically remove, replace, or resize clothing.

This original **local worksheet** organizes the record. It is not a native import or executable tracker configuration:

```text
Character: Mira, fictional adult archivist, age 30
Accepted event: F01 - only her hands have changed to gray granite
Active appearance: human form with granite hands
Stage: partial; hands only
Current visible appearance: warm brown face, brown eyes, black shoulder-length
braids, lean adult build, gray granite hands; navy jacket and cream shirt
Unchanged anchors: face, eyes, braids, body proportions, clothing
Superseded for this moment: ordinary skin surface on the hands
Scene: archive counter, waist-up, eye-level view, soft daylight
Next transition: none established
Accepted source image: [record actual selected image identifier, if using Edit]
```

The source block's emphasis on changing features is useful as a change list, but a change list alone may omit identity anchors the image needs. Resolve the **complete relevant visible result**: unchanged traits, accepted changes, coverage, and scene. Leave hidden or unassessable details out of the image verdict rather than guessing them.

## Give the record a destination

Keep the form definitions and accepted-event history in your maintained local notes. If using native memory, copy only the relevant continuing facts through the available memory workflow. If using a native text State Tracker, configure it through the actual controls and inspect its updates separately. The [progression guide](https://guide.ourdream.ai/characters/progression-and-systems) describes phases and trackers; it does not establish an automatic image connection.

Use one maintained ED or chat Custom Instructions location for any needed **behavior guidance**. This original block is a teaching adaptation, not a guaranteed lock:

```text
Keep Mira's form and transition stage aligned with the accepted scene record.
An ordinary action does not advance a transformation.
After an explicitly accepted change, retain the unaffected established traits.
For image descriptions, resolve the currently visible appearance, clothing,
and scene. Include a partial mixture only when that mixture is established.
If a required form fact is missing, ask for it rather than inventing a transition.
```

A temporary `/direct` can request an event for one reply where supported. Inspect the accepted result before updating the form record; writing a request is not proof that a transition occurred. For edits and regenerations, identify which branch you retained and reconcile dependent notes.

## Prepare the actual image input

First identify the route and its supplied inputs. The [appearance guide](https://guide.ourdream.ai/characters/creation-workflow) places stable visual traits in the appearance fields. The [editing guide](https://guide.ourdream.ai/characters/consistent-images) recommends a useful base and narrow edits. A current-form note does not automatically override a selected character's saved appearance or become an image reference.

For a route where you supply the needed appearance explicitly, this original resolved prompt describes the worksheet's visible result:

```text
One 30-year-old adult archivist with a warm brown face, brown eyes,
black shoulder-length braids, a lean adult build, and gray granite hands.
She wears a navy jacket over a cream shirt at an archive counter.
Both granite hands are visible resting beside a closed notebook.
Eye-level waist-up view, soft daylight, simple archive background.
```

This names the intended materials without requesting a second person or a completed full-body change. Adapt the wording to the actual selected model and route. If saved appearance contradicts it, record and resolve the specific conflict using available controls, or use an appropriate accepted image in Edit. Do not claim that an ED block suppresses appearance supplied elsewhere. Save the prior field revision before deliberately changing it.

## Edit a transformation without contradicting preservation

Select the real accepted in-app image. If its hands are still ordinary, `preserve everything exactly` conflicts with changing them. State the intended exception:

```text
Change only Mira's visible hands to gray granite, retaining their pose and
shape. Keep her face, eyes, braids, adult body proportions, navy jacket,
cream shirt, notebook, camera, crop, archive layout, and lighting unchanged.
```

Inspect the hands and every preservation criterion separately. A later completed stone form would require a different explicit change and an updated snapshot; do not retain the human-skin instruction for a surface you deliberately replaced. Keep the last accepted source and the neutral base so repeated fixes do not become the only available lineage.

## Keep persistent features separate from clothing visibility

The supplied community excerpt withdraws an earlier claim that storing persistent details in a skin-tone field makes clothing cover them appropriately. Its author reports that initial trials were confounded and clean-character tests contradicted the claim. The correction has no supplied date. Treat the universal workaround as **withdrawn**, not as an active placement rule or as a new negative-prompt recipe.

A stable mark can remain part of character identity while being covered in a particular picture. Field placement does not establish dependable visibility, garment preservation, or automatic occlusion. Inspect the clothing, visible marks, framing, and unwanted changes in actual results. See [CPD and Face Details](../tutorials/04_CPD_and_Face_Details.html) and [image editing](../tutorials/07_Edit_Images.html).

## Proposed checks - all not_run

| Case | Starting record and requested action | Inspect |
| --- | --- | --- |
| CF01 | Human form; ask Mira about the catalog | No unrequested form or stage change |
| CF02 | Accepted hands-only change | Granite hands with unchanged face, braids, clothing, and scene |
| CF03 | A deliberately defined partial form | Only the specified mixture; no added tail, horns, wings, or other changes |
| CF04 | Explicitly accepted complete granite form | Current surfaces replace superseded ones while intended identity anchors remain |
| CF05 | Saved appearance conflicts with the current snapshot | Conflict is identified and actual inputs recorded; no assumed hidden override |
| CF06 | Regenerate a transition and retain one reply | One accepted branch and event, without silently counting both alternatives |

Use the [test worksheet](../examples/Settings_and_Test_Log.txt). Record fields, presets, source-image lineage, exact inputs, each attempted edit and displayed charge, all outputs, and unassessable features. For media, distinguish native generation from later external cuts or audio edits. Proposed prompt wording is not a measured preservation result.

Review date: October 31, 2026. Linked Known State pages display July 27, 2026 as their modification date and were retrieved with Firecrawl on the review date. The supplied prompt and community reports do not establish a native state schema, transition timing, image-route injection, or model efficacy.