[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@cloudhal/core-contracts@0.8.0

Minor Changes

• b6cf70f: The contract gains two field types for collections, reference and repeater (RFC-0045 §1, rollout step 1, Collections stage 4: reference fields and repeaters (needs RFC) #114). Every write path still refuses them, so existing sites behave exactly as before.

  • Contract. FieldDefinition gains ReferenceField and RepeaterField. A new SubFieldDefinition union holds a repeater's sub-fields: scalar values only, so a repeater cannot contain a repeater. FieldMigration.fromType gains both types, and FieldMigration gains an optional sub. There is no schemaVersion bump, and existing documents stay valid.

  • The gate. Until rollout step 7 enables them, a reference or repeater definition, or a migration marker that names one, is refused with fields_unsupported: API status 409, with an MCP hint. The refusal covers:

    • site creates and updates, so Studio, MCP and the API;
    • field operations;
    • every bundle importSite takes: import, pull, push, cloudhal import --replace and --revert, snapshot restores and edition copies.

    checkBundle gained assertFieldTypes. It checks the working site row, and prepareImport checks every snapshot site body the import writes once it has been verified (bodies the target already holds are its own), and refuses the types when no capability is given. A push answers 409 fields_unsupported with its issues, not 400 bad_request.

  • Pure core (@cloudhal/core-ts/fields), with no effect on stored data yet:

    • the definition rules: reference_target_unknown, where, itemLabel, and caps on sub-fields and leaves;
    • value checks for both types, the per-item requiredToPublish, and too_many_references;
    • resolveFields skips types it does not know;
    • fieldsJsonSchema(…, { strict: true }) and strictSchemaCost;
    • pickMember, referenceIssues, and FIELD_QUERY_OPS and structured-data entries that make neither type listable or mappable.

    FIELD_TYPES keeps the nine enabled types (EnabledFieldType). ALL_FIELD_TYPES lists all eleven.

  • MCP. update_collection's input now builds its $defs with defsClosure and offers only the enabled types. A test checks that every $ref in every tool's input and output schema resolves. Before this change, pnpm gen alone would have left the input pointing at $defs it did not carry.

  • Fix, existing sites: block props and typed-field objects no longer accept keys named after Object.prototype members (constructor, toString, __proto__, …) as known props. The props interpreter (validateProps) now checks and reads own keys only. Such keys are refused as unknown, and a prop the value leaves out is absent, not the prototype's function. toLocaleString, isPrototypeOf and propertyIsEnumerable join the reserved field keys, beside toString, valueOf and hasOwnProperty.

@cloudhal/agent-runtime@0.8.0

Patch Changes

• Updated dependencies [b6cf70f]
  • @cloudhal/core-contracts@0.8.0
  • @cloudhal/storage@0.8.0

@cloudhal/analytics@0.8.0

Patch Changes

• Updated dependencies [b6cf70f]
  • @cloudhal/core-contracts@0.8.0
  • @cloudhal/storage@0.8.0

@cloudhal/api@0.8.0

Patch Changes

• b6cf70f: The contract gains two field types for collections, reference and repeater (RFC-0045 §1, rollout step 1, Collections stage 4: reference fields and repeaters (needs RFC) #114). Every write path still refuses them, so existing sites behave exactly as before.

  • Contract. FieldDefinition gains ReferenceField and RepeaterField. A new SubFieldDefinition union holds a repeater's sub-fields: scalar values only, so a repeater cannot contain a repeater. FieldMigration.fromType gains both types, and FieldMigration gains an optional sub. There is no schemaVersion bump, and existing documents stay valid.

  • The gate. Until rollout step 7 enables them, a reference or repeater definition, or a migration marker that names one, is refused with fields_unsupported: API status 409, with an MCP hint. The refusal covers:

    • site creates and updates, so Studio, MCP and the API;
    • field operations;
    • every bundle importSite takes: import, pull, push, cloudhal import --replace and --revert, snapshot restores and edition copies.

    checkBundle gained assertFieldTypes. It checks the working site row, and prepareImport checks every snapshot site body the import writes once it has been verified (bodies the target already holds are its own), and refuses the types when no capability is given. A push answers 409 fields_unsupported with its issues, not 400 bad_request.

  • Pure core (@cloudhal/core-ts/fields), with no effect on stored data yet:

    • the definition rules: reference_target_unknown, where, itemLabel, and caps on sub-fields and leaves;
    • value checks for both types, the per-item requiredToPublish, and too_many_references;
    • resolveFields skips types it does not know;
    • fieldsJsonSchema(…, { strict: true }) and strictSchemaCost;
    • pickMember, referenceIssues, and FIELD_QUERY_OPS and structured-data entries that make neither type listable or mappable.

    FIELD_TYPES keeps the nine enabled types (EnabledFieldType). ALL_FIELD_TYPES lists all eleven.

  • MCP. update_collection's input now builds its $defs with defsClosure and offers only the enabled types. A test checks that every $ref in every tool's input and output schema resolves. Before this change, pnpm gen alone would have left the input pointing at $defs it did not carry.

  • Fix, existing sites: block props and typed-field objects no longer accept keys named after Object.prototype members (constructor, toString, __proto__, …) as known props. The props interpreter (validateProps) now checks and reads own keys only. Such keys are refused as unknown, and a prop the value leaves out is absent, not the prototype's function. toLocaleString, isPrototypeOf and propertyIsEnumerable join the reserved field keys, beside toString, valueOf and hasOwnProperty.

• Updated dependencies [b6cf70f]

  • @cloudhal/core-contracts@0.8.0
  • @cloudhal/core-ts@0.8.0
  • @cloudhal/mcp-server@0.8.0
  • @cloudhal/agent-runtime@0.8.0
  • @cloudhal/analytics@0.8.0
  • @cloudhal/astro-renderer@0.8.0
  • @cloudhal/comments@0.8.0
  • @cloudhal/schedules@0.8.0
  • @cloudhal/storage@0.8.0

@cloudhal/astro-renderer@0.8.0

Patch Changes

• Updated dependencies [b6cf70f]
  • @cloudhal/core-contracts@0.8.0
  • @cloudhal/core-ts@0.8.0
  • @cloudhal/analytics@0.8.0
  • @cloudhal/comments@0.8.0
  • @cloudhal/storage@0.8.0

@cloudhal/cli@0.8.0

Patch Changes

• Updated dependencies [b6cf70f]
  • @cloudhal/core-contracts@0.8.0
  • @cloudhal/core-ts@0.8.0
  • @cloudhal/mcp-server@0.8.0
  • @cloudhal/api@0.8.0
  • @cloudhal/agent-runtime@0.8.0
  • @cloudhal/analytics@0.8.0
  • @cloudhal/astro-renderer@0.8.0
  • @cloudhal/comments@0.8.0
  • @cloudhal/schedules@0.8.0
  • @cloudhal/storage@0.8.0
  • @cloudhal/cloudflare@0.8.0

@cloudhal/cloudflare@0.8.0

Patch Changes

• Updated dependencies [b6cf70f]
  • @cloudhal/core-ts@0.8.0
  • @cloudhal/mcp-server@0.8.0
  • @cloudhal/api@0.8.0
  • @cloudhal/agent-runtime@0.8.0
  • @cloudhal/analytics@0.8.0
  • @cloudhal/comments@0.8.0
  • @cloudhal/schedules@0.8.0
  • @cloudhal/storage@0.8.0

@cloudhal/comments@0.8.0

Patch Changes

• Updated dependencies [b6cf70f]
  • @cloudhal/core-contracts@0.8.0
  • @cloudhal/core-ts@0.8.0
  • @cloudhal/storage@0.8.0

@cloudhal/core-ts@0.8.0

Patch Changes

• b6cf70f: The contract gains two field types for collections, reference and repeater (RFC-0045 §1, rollout step 1, Collections stage 4: reference fields and repeaters (needs RFC) #114). Every write path still refuses them, so existing sites behave exactly as before.

  • Contract. FieldDefinition gains ReferenceField and RepeaterField. A new SubFieldDefinition union holds a repeater's sub-fields: scalar values only, so a repeater cannot contain a repeater. FieldMigration.fromType gains both types, and FieldMigration gains an optional sub. There is no schemaVersion bump, and existing documents stay valid.

  • The gate. Until rollout step 7 enables them, a reference or repeater definition, or a migration marker that names one, is refused with fields_unsupported: API status 409, with an MCP hint. The refusal covers:

    • site creates and updates, so Studio, MCP and the API;
    • field operations;
    • every bundle importSite takes: import, pull, push, cloudhal import --replace and --revert, snapshot restores and edition copies.

    checkBundle gained assertFieldTypes. It checks the working site row, and prepareImport checks every snapshot site body the import writes once it has been verified (bodies the target already holds are its own), and refuses the types when no capability is given. A push answers 409 fields_unsupported with its issues, not 400 bad_request.

  • Pure core (@cloudhal/core-ts/fields), with no effect on stored data yet:

    • the definition rules: reference_target_unknown, where, itemLabel, and caps on sub-fields and leaves;
    • value checks for both types, the per-item requiredToPublish, and too_many_references;
    • resolveFields skips types it does not know;
    • fieldsJsonSchema(…, { strict: true }) and strictSchemaCost;
    • pickMember, referenceIssues, and FIELD_QUERY_OPS and structured-data entries that make neither type listable or mappable.

    FIELD_TYPES keeps the nine enabled types (EnabledFieldType). ALL_FIELD_TYPES lists all eleven.

  • MCP. update_collection's input now builds its $defs with defsClosure and offers only the enabled types. A test checks that every $ref in every tool's input and output schema resolves. Before this change, pnpm gen alone would have left the input pointing at $defs it did not carry.

  • Fix, existing sites: block props and typed-field objects no longer accept keys named after Object.prototype members (constructor, toString, __proto__, …) as known props. The props interpreter (validateProps) now checks and reads own keys only. Such keys are refused as unknown, and a prop the value leaves out is absent, not the prototype's function. toLocaleString, isPrototypeOf and propertyIsEnumerable join the reserved field keys, beside toString, valueOf and hasOwnProperty.

• Updated dependencies [b6cf70f]

  • @cloudhal/core-contracts@0.8.0
  • @cloudhal/schedules@0.8.0
  • @cloudhal/storage@0.8.0

create-cloudhal@0.8.0

Patch Changes

• @cloudhal/cli@0.8.0

@cloudhal/mcp-server@0.8.0

Patch Changes

• b6cf70f: The contract gains two field types for collections, reference and repeater (RFC-0045 §1, rollout step 1, Collections stage 4: reference fields and repeaters (needs RFC) #114). Every write path still refuses them, so existing sites behave exactly as before.

  • Contract. FieldDefinition gains ReferenceField and RepeaterField. A new SubFieldDefinition union holds a repeater's sub-fields: scalar values only, so a repeater cannot contain a repeater. FieldMigration.fromType gains both types, and FieldMigration gains an optional sub. There is no schemaVersion bump, and existing documents stay valid.

  • The gate. Until rollout step 7 enables them, a reference or repeater definition, or a migration marker that names one, is refused with fields_unsupported: API status 409, with an MCP hint. The refusal covers:

    • site creates and updates, so Studio, MCP and the API;
    • field operations;
    • every bundle importSite takes: import, pull, push, cloudhal import --replace and --revert, snapshot restores and edition copies.

    checkBundle gained assertFieldTypes. It checks the working site row, and prepareImport checks every snapshot site body the import writes once it has been verified (bodies the target already holds are its own), and refuses the types when no capability is given. A push answers 409 fields_unsupported with its issues, not 400 bad_request.

  • Pure core (@cloudhal/core-ts/fields), with no effect on stored data yet:

    • the definition rules: reference_target_unknown, where, itemLabel, and caps on sub-fields and leaves;
    • value checks for both types, the per-item requiredToPublish, and too_many_references;
    • resolveFields skips types it does not know;
    • fieldsJsonSchema(…, { strict: true }) and strictSchemaCost;
    • pickMember, referenceIssues, and FIELD_QUERY_OPS and structured-data entries that make neither type listable or mappable.

    FIELD_TYPES keeps the nine enabled types (EnabledFieldType). ALL_FIELD_TYPES lists all eleven.

  • MCP. update_collection's input now builds its $defs with defsClosure and offers only the enabled types. A test checks that every $ref in every tool's input and output schema resolves. Before this change, pnpm gen alone would have left the input pointing at $defs it did not carry.

  • Fix, existing sites: block props and typed-field objects no longer accept keys named after Object.prototype members (constructor, toString, __proto__, …) as known props. The props interpreter (validateProps) now checks and reads own keys only. Such keys are refused as unknown, and a prop the value leaves out is absent, not the prototype's function. toLocaleString, isPrototypeOf and propertyIsEnumerable join the reserved field keys, beside toString, valueOf and hasOwnProperty.

• Updated dependencies [b6cf70f]

  • @cloudhal/core-contracts@0.8.0
  • @cloudhal/core-ts@0.8.0
  • @cloudhal/agent-runtime@0.8.0
  • @cloudhal/analytics@0.8.0
  • @cloudhal/astro-renderer@0.8.0
  • @cloudhal/comments@0.8.0
  • @cloudhal/schedules@0.8.0
  • @cloudhal/storage@0.8.0

@cloudhal/schedules@0.8.0

Patch Changes

• Updated dependencies [b6cf70f]
  • @cloudhal/core-contracts@0.8.0
  • @cloudhal/storage@0.8.0

@cloudhal/storage@0.8.0

Patch Changes

• Updated dependencies [b6cf70f]
  • @cloudhal/core-contracts@0.8.0