Update to Walla

Changed files

.codex-plugin/plugin.json →

skills/walla/SKILL.md →

skills/walla/references/custom-fields.md →

skills/walla/references/forms.md →

skills/walla/references/responses-and-automations.md →

skills/walla/references/custom-fields.md

--- before
+++ after
@@ -1,6 +1,6 @@
 # Custom field workflows
 
-Custom fields are an Enterprise capability. Use the MCP's `custom-fields` reference as the authoritative model for data references, output schemas, and host interaction.
+Every Walla plan can use custom fields. Plans differ only in how many custom field types a team can own. Use the MCP's `custom-fields` reference as the authoritative model for data references, output schemas, and host interaction.
 
 ## Reuse an existing type
 
@@ -12,11 +12,12 @@
 
 Follow the state machine exactly:
 
-1. Call `start_custom_field_build` with the team, a clear name, and a concrete description of the field's behavior and saved value.
-2. Poll `get_custom_field_build` until the state is `awaiting_your_code`.
-3. Call `get_custom_field_scaffold`. Treat the returned scaffold and allowed file paths as authoritative; do not invent SDK APIs, imports, or unsupported files.
-4. Implement the smallest complete field, then call `submit_custom_field` with the required files.
-5. Poll `get_custom_field_build`. On `try_again`, retry the same poll. On `build_failed`, use the returned errors to revise and resubmit.
+1. Call `start_custom_field_build` with the team, a clear name, and a concrete description of the field's behavior and saved value. To change an existing type, pass its `customFieldTypeId` as `targetTypeId`; approval then adds a new version to that type.
+   - If the team already owns its plan's maximum number of types, starting or approving a build for a new type returns `payment_required`. Tell the user that an upgrade is necessary, and offer to revise an existing type. A revision does not count against the limit.
+2. Call `get_custom_field_scaffold` immediately. Do not wait for `get_custom_field_build` to show `awaiting_your_code`: only a ready scaffold response moves the build to that state. While the scaffold returns `{ notReady: true, retryAfterMs }`, wait that long and call it again.
+3. Treat the returned contract notes, SDK types, example, and file tree as authoritative. Do not invent SDK APIs, imports, or unsupported files.
+4. Implement the smallest complete field, then call `submit_custom_field`. The submission is a merge patch over the scaffold and must include `outputSchema.json`. A field that reads other fields' answers must also include `observeFields.json` with `{"mode":"configured"}`; without it, the field receives no form context.
+5. Poll `get_custom_field_build`. If `submit_custom_field` returns `try_again`, the build is busy; wait and repeat the same submit. On `build_failed`, use the returned errors to revise and resubmit.
 6. At `ready_to_review`, give the user the returned `previewUrl` and ask them to review the rendered field.
 7. Call `approve_custom_field_build` only after the user has approved the preview. Approval registers a reusable type and immutable version.
 8. Attach the returned `customFieldTypeId` to a form with `form_apply_edits`, then verify with `get_form`.
@@ -30,6 +31,6 @@
 
 ## Build lifecycle
 
-- A team has a limited number of builds in flight. If an abandoned build occupies a slot, offer `cancel_custom_field_build` only after the user confirms they no longer want it.
+- A team can have only a few builds in flight, and an unapproved build expires. If an abandoned build occupies a slot, offer `cancel_custom_field_build` only after the user confirms they no longer want it.
 - Cancellation is irreversible for the build and tears down its preview. It cannot cancel an approved version.
 - Do not start a replacement build merely to work around a transient state. Poll or resubmit within the existing build as the returned state directs.