Use Case
Project authoring validates and documents product configuration before generating strict Relay and Notary inputs. Review of #364 found that the CEL worker memory range is repeated in Notary core validation, registryctl validation, the project-authoring JSON Schema, and tests. The values currently agree, but a later product tuning could leave registryctl accepting or rejecting a different range.
Proposed Behavior
- Export the product-owned CEL worker minimum and maximum from registry-notary-core.
- Make registryctl runtime validation and generated-schema verification consume those constants.
- Keep the committed JSON Schema as an implementer/editor artifact, but generate or verify its numeric bounds from the same source.
- Inventory other exact product limits duplicated by project authoring and include only cases with a clear owning constant and two active consumers.
Acceptance
- One product-owned constant pair controls CEL worker validation across Notary and registryctl.
- CI fails if the committed project-authoring schema drifts from the constants.
- Existing generated projects and error messages remain stable unless an explicit pre-1.0 decision changes the bounds.
Boundaries
Use Case
Project authoring validates and documents product configuration before generating strict Relay and Notary inputs. Review of #364 found that the CEL worker memory range is repeated in Notary core validation, registryctl validation, the project-authoring JSON Schema, and tests. The values currently agree, but a later product tuning could leave registryctl accepting or rejecting a different range.
Proposed Behavior
Acceptance
Boundaries