Try the working example Edit in Studio
Practical workflow
Record a concrete revision
Give the revision a distinctive name, record its design requirements and explain why you changed them. Save a second revision with different requirements.
Compare actual saved values
Choose two revisions in Compare revisions. Each field shows earlier and later text, with an explicit changed or unchanged marker. Choosing the same revision twice asks you to select different records.
Retrieve and correct the history
The history table starts in creation order. Open a row to edit its requirements or rationale. Saving an edit changes that record; it does not create an immutable version. Add a new revision when you need to preserve the old one.
Keep the model inside the registered interface
The model selects only recipe_id=design_history. Trusted code owns the forms, comparison fields, storage collection and navigation. Use the supplied XML as a fixed template.
Verify persistence and deletion
Reload after adding or editing a revision. Check its exact values. Delete a revision and reload: it should stay absent. Export or back up important work separately; clearing browser data removes the ledger.
The bounded model response
{"recipe_id":"design_history"}Keep the template under code control
def select_template(response, trusted_template):
if response != {"recipe_id": "design_history"}:
raise ValueError("Choose a registered recipe; arbitrary XML is rejected")
return trusted_template
# trusted_template is the fixed XML below, stored by your application.
# Repeat the browser workflow whenever the trusted template changes.The fixed AppSPEC template
<?xml version="1.0" encoding="UTF-8"?>
<APP ID="design-change-ledger" NAME="Design Change Ledger" THEME="modern-minimal" WIDTH="1240px">
<DATA MODE="local" />
<STATE ID="history" NAV="Revision history" ICON="history">
<TEXT STYLE="h1" TEXT="Keep the reasoning behind each design change" />
<TEXT STYLE="muted" TEXT="Save design requirements and revision rationale locally. Choose two saved revisions to compare their actual text and see which fields changed." />
<FORM SAVE="design_revisions" SUBMIT-LABEL="Save revision">
<FIELD NAME="title" LABEL="Revision name" TYPE="text" REQUIRED="true" />
<FIELD NAME="requirements" LABEL="Design requirements" TYPE="textarea" REQUIRED="true" />
<FIELD NAME="rationale" LABEL="Why this changed" TYPE="textarea" REQUIRED="true" />
</FORM>
<TABLE SRC="design_revisions" SORT="created" OPEN="edit" EMPTY="No revisions yet. Save one above, then a second to compare them.">
<COL FIELD="created" LABEL="Saved" />
<COL FIELD="title" LABEL="Revision" />
<COL FIELD="rationale" LABEL="Rationale" />
</TABLE>
</STATE>
<STATE ID="compare" NAV="Compare revisions" ICON="columns-2">
<TEXT STYLE="h1" TEXT="Compare two saved revisions" />
<TEXT STYLE="muted" TEXT="Choose earlier and later records. A changed marker compares text and type, not whether a design is better." />
<RECORD-COMPARE SRC="design_revisions" TITLE="title" SORT="created">
<COL FIELD="title" LABEL="Revision name" />
<COL FIELD="requirements" LABEL="Design requirements" />
<COL FIELD="rationale" LABEL="Why this changed" />
</RECORD-COMPARE>
</STATE>
<STATE ID="edit" WIDTH="760px">
<TEXT STYLE="h1" TEXT="Edit revision" />
<TEXT STYLE="muted" TEXT="Editing replaces this record. Save a new revision to preserve an earlier version." />
<FORM UPDATE="design_revisions" TO="history" SUBMIT-LABEL="Save changes">
<FIELD NAME="title" LABEL="Revision name" TYPE="text" REQUIRED="true" />
<FIELD NAME="requirements" LABEL="Design requirements" TYPE="textarea" REQUIRED="true" />
<FIELD NAME="rationale" LABEL="Why this changed" TYPE="textarea" REQUIRED="true" />
</FORM>
<BUTTON LABEL="Delete revision" ACTION="remove" STYLE="danger" ICON="trash-2" />
</STATE>
<WIRE LABEL="remove" DELETE="design_revisions" TO="history" />
</APP>Source and scope
A public developer question prompted this walkthrough. It demonstrates a constrained template approach; it does not measure how often the reported problem occurs.
Manual text comparison and local browser storage only. No Figma import, synchronization, account sync, immutable version control, visual diff or automatic design-quality judgment.
This example passed real browser two-revision creation, chronological retrieval, field comparison, editing, reload, deletion, markup-as-text and mobile checks. These checks do not establish customer value.