[yyyyaaa]

Summary

A create form now opens on a field's database default instead of an empty control.

• ResourceField.createDefault takes { value } alongside 'now'. A create form starts that field on the value: a priority select defaulting to Medium shows Medium, not None.
• An explicit form default (defaultValues, such as a related list's parent) still wins, and edit forms still read the stored value.
• The docs entry for ResourceField.createDefault describes both forms.

priority: {
  name: 'priority',
  label: 'Priority',
  input: 'select',
  options: [{ value: 'Low', label: 'Low' }, { value: 'Medium', label: 'Medium' }],
  createDefault: { value: 'Medium' },
},

Context

Found while dogfooding desktop v0.1.0-beta.4: a generated "New wishlist idea" form showed None for a required priority, and saving it empty stored Medium, so the data was right but the form hid the default. Once this lands in registry-dist, the app template's generator will emit createDefault: { value } from the AppSpec field's default (_meta only says a column has a default, not which), and the desktop will move its registry pin.

🤖 Generated with Claude Code

https://claude.ai/code/session_017WbsG7JQsKEMKNgVsc4psk

[tenki-reviewer]

Review complete. No issues found — approved ✅.

---

This PR extends the resource-kit create-default mechanism so fields can declare a default as an object ({ value: <string|number|boolean> }) in addition to the existing static and now sentinel forms. The form-values coercion branch now unwraps .value from object defaults before normal conversion, types.ts widens the createDefault union accordingly, the app-kit docs describe the new shape, and the resource-kit test suite covers numeric object defaults plus the edit-mode rule that stored record values override create defaults.

_{Reviewed commit: 3ce30b3}