659 schema tdl generalize first class definitional constraints across schema 20

[evomimic]

Summary

Implements Issue #659’s Core Schema 2.0 TDL groundwork for first-class definitional constraints.

Constraint kinds are now direct ConstraintType descendants that own their parameter contracts and applicability declarations. Core also includes reusable named cardinality constraint instances and a concrete Length16k.LengthConstraint attached to MapStringValueType.StringValueType.

Changes

• Added generic Constraints / HasConstraints descriptor relationships.
• Added ApplicableToDescriptorTypes / HasApplicableConstraintTypes applicability relationships.
• Defined direct Core constraint types:
  • CardinalityConstraint.ConstraintType
  • LengthConstraint.ConstraintType
  • NumericRangeConstraint.ConstraintType
  • ItemCountConstraint.ConstraintType
  • UniqueItemsConstraint.ConstraintType
• Declared compatibility through descriptor-family applicability:
  • length constraints apply to string value types;
  • numeric range constraints apply to integer value types;
  • item count and uniqueness constraints apply to value-array value types;
  • cardinality constraints apply to relationship descriptors.
• Replaced relationship-level cardinality lowering with shared, named Core instances:
  • ExactlyOne.CardinalityConstraint
  • ZeroOrOne.CardinalityConstraint
  • OneOrMore.CardinalityConstraint
  • ZeroOrMore.CardinalityConstraint
• Added Length16k.LengthConstraint and attached it to MapStringValueType.StringValueType.
• Regenerated Core schema import artifacts.
• Updated Core loader metrics for the additional constraint-instance holon.

Scope

This PR establishes the TDL model and generated-schema fidelity required for the validation workplan. It intentionally does not implement:

• constraint-instance key-rule runtime resolution;
• runtime constraint evaluation or enforcement;
• compiler-synthesized constraint instances or attachments;
• extension-schema attachment/rejection fixtures.

Testing

• Passed npm run map-schema:compile:coreschema
• Passed npm run map-schema:check:coreschema
• Passed cargo test --manifest-path tools/map-schema/Cargo.toml --lib (24 tests)

A subsequent Sweettest run confirmed Core, generated Core, validation, and query schema loads pass. The remaining Book/Person fixture failures are a stale expected link metric: four new authored Constraints attachments raise its expected count from 42 to 46.

[evomimic]

Follow-up implementation updates in response to map-dev-docs PR #24 findings:

• Added the abstract Rule.HolonType semantic family without creating an Instance TypeKind anchor.
• Generalized RuleOf / Rules provenance to all ordinary configured rules; Constraint, ValidationRule, and configured key-rule instances now share the Rule lineage.
• Added rule_of <SchemaKey> source syntax, lowering to RuleOf, plus decompilation support and focused parser/lowering tests.
• Renamed the generic LengthConstraint to StringLengthConstraint and added distinct BytesLengthConstraint semantics.
• Migrated the Core string limit to Length16k.StringLengthConstraint.
• Regenerated Core JSON imports and updated Core loader metrics for the two added descriptor holons.

The scoped source/tooling checks pass, as do npm test and a full Core-corpus load through npm start.

Runtime work remains intentionally deferred and is recorded on #659: ConstraintInstanceRule resolution, effective-constraint collection, fail-closed unsupported-constraint handling, cardinality execution, and strict Core-bootstrap proof.

[owleyeview]

Review Findings

Thanks for carrying the first-class constraint model into the TDL corpus. I found issues that should be addressed before merge:

1. The TDL compiler performs descriptor-semantic inference

cardinality_constraint_types() in tools/map-schema/src/tdl_compiler.rs:292 walks authored Extends declarations from a hard-coded CardinalityConstraint.ConstraintType root, then uses that derived classification to admit the cardinality shorthand.

This conflicts with the TDL boundary in tdl-spec.md §19: parsing and lowering do not resolve references or perform descriptor-driven validation.

Please restrict cardinality syntactically to generic instance declarations, lower its bounds onto that authored instance, and leave constraint-type compatibility to descriptor-aware validation. Alternatively, changing the compiler boundary should be an explicit design decision rather than an incidental part of this migration.

2. A configured key-rule instance is missing RuleOf

KeyRuleType.HolonType now extends Rule.HolonType, so configured key-rule instances require provenance through RuleOf. ImplementationName.FormatRule in schema-src/dance/schema.tdl:15 does not provide it. It should likely include:

rule_of "MAP Dance Schema-v0.1.0"

There is also an authoring-style inconsistency: the five constraint instances use the rule_of clause, while all 50 ValidationRule instances author RuleOf through their relationship maps. Both lower successfully, but the decompiler normalizes the relationship form to the clause, so a decompile/recompile cycle would rewrite validation.tdl.

Please choose one canonical corpus form—preferably rule_of—or clarify that the semantic RuleOf fact, rather than the shorthand clause, is the requirement.

3. ApplicableToDescriptorTypes has an incompatible source endpoint

In schema-src/core/root.tdl:535, the relationship source is ConstraintType.HolonType. Its occurrences, however, are authored on constraint-type descriptor holons such as CardinalityConstraint.ConstraintType, whose direct DescribedBy type is MetaConstraintType.MetaHolonType.

Under DS-OCC-002, descriptor endpoints are checked through their direct describing meta-type—not through the descriptor holon’s own Extends lineage. These occurrences are therefore endpoint-incompatible.

Please change the declared source and inverse target to MetaConstraintType.MetaHolonType, while preserving the intended meaning that constraint-type descriptors declare applicability.