Migration Notes

Hashbrown v0.5 changes how Skillet schemas are printed for models and how parsed values are resolved internally. Most apps do not need to migrate anything manually.

You only need these notes if your app persisted JSON that was generated from Hashbrown v0.4 schemas and you now want to read that stored JSON with Hashbrown v0.5 code.

---

Who Is Affected

You are likely unaffected if:

• Your app stores chat messages as text and asks the model to generate fresh structured data.
• Your app uses Hashbrown resources without persisting structured output JSON.
• Your app stores application data after converting it into your own domain model.

You may need a one-time data migration if:

• You persisted raw structured output JSON generated by Hashbrown v0.4.
• You persisted raw generative UI JSON generated by Hashbrown v0.4.
• You replay old v0.4 model output directly into v0.5 Skillet validation or rendering paths.

Hashbrown does not currently ship a public migration helper for this. If this becomes a common need, we may add a supported helper later. For now, keep migration code in your app's data layer and run it only against stored v0.4 data.

---

anyOf Output

Hashbrown v0.4 sometimes wrapped complex anyOf branches so models could select a branch explicitly.

Index-wrapped v0.4 output:

{
  "0": {
    "title": "Q3 forecast"
  }
}

The v0.5 shape is the branch value itself:

{
  "title": "Q3 forecast"
}

When every branch was an object with one string literal discriminator, v0.4 could use the literal value as the wrapper key.

Literal-wrapped v0.4 output:

{
  "success": {
    "data": "Saved"
  }
}

The v0.5 shape should include the discriminator field in the object:

{
  "status": "success",
  "data": "Saved"
}

---

Generative UI Output

Hashbrown v0.4 represented component nodes with $tag, $props, and $children.

v0.4 UI output:

{
  "$tag": "app-markdown",
  "$props": {
    "children": "Hello"
  },
  "$children": []
}

Hashbrown v0.5 represents component nodes as an object keyed by the exposed component name. Component props resolve through s.node(...), so finalized stored props should be wrapped with parser-node metadata if you are migrating old raw UI JSON.

v0.5 UI output:

{
  "app-markdown": {
    "props": {
      "complete": true,
      "partialValue": {
        "children": "Hello"
      },
      "value": {
        "children": "Hello"
      }
    },
    "children": []
  }
}

If your app can regenerate old generative UI output from the original prompt and model, prefer regeneration over hand-migrating stored UI trees.

---

Root Primitive Output

Hashbrown v0.4 wrapped root primitive and array schemas under __wrappedPrimitive when printing JSON Schema for models.

v0.4 root primitive output:

{
  "__wrappedPrimitive": "hello"
}

The v0.5 value is the primitive or array itself:

"hello"

---

Recommended Migration Strategy

Treat this as a storage migration, not as normal Skillet runtime behavior.

1. Identify stored records created by Hashbrown v0.4.
2. Migrate those records once at your persistence boundary.
3. Validate the migrated JSON against the v0.5 Skillet schema.
4. Store the migrated v0.5 shape, or store your own domain model instead of raw model output.

Avoid applying migration logic globally in Angular templates, computed values, or every schema validation call. Automatic migration can hide real schema mismatches, especially for ambiguous anyOf values.

---

Next Steps

Skillet Schema

Review the v0.5 schema language.

JSON Parser

Use the streaming JSON parser directly.