Type: uint — distinct type vs unsigned constraint (decision)

[rrrodzilla]

Workstream: Type system · Part of #89

Context

CEL treats uint (uint64) as a distinct type with separate overflow rules and no implicit int↔uint conversion. SchemaForge collapses everything to Integer(i64).

Scope — decision issue

• Decide: model unsigned as a distinct FieldType vs. an IntegerConstraints { min: 0 } constraint on the existing Integer.
• Tension: a constraint is simpler and probably enough for most fields; but CEL conformance treats the type distinction as load-bearing, so a constraint cannot fake it if we chase conformance.

Acceptance

• Documented decision tied to the substrate/conformance outcome (Epic: Built-in declarative rules engine (reduce reliance on gRPC hooks) #89 foundation).

---

Dependencies: Decision informed by #91 and the conformance results in #90. Soft.

[rrrodzilla]

Decided in ADR-0001 — landed in 8a74fb6 (docs/adr/0001-uint-type-vs-unsigned-constraint.md).

Decision: model unsigned integers as an IntegerConstraints { min: 0 } constraint on the existing FieldType::Integer — do NOT add a distinct DSL uint field type now (it stays addable later since FieldType is #[non_exhaustive]).

Why (all verified in code):

1. The Type: uint — distinct type vs unsigned constraint (decision) #98 premise that 'a constraint can't fake the conformance distinction' does not apply to the DSL surface — the Int/Uint distinction the cel-spec oracle grades on lives in the evaluator (CelValue::Uint/CelType::Uint with type-exact PartialEq), independent of how a stored field is spelled. The DSL choice does not move the conformance needle.
2. integer(min: 0) already exists (IntegerConstraints::with_min) and both backends already enforce it — Postgres CHECK (... >= 0), SurrealDB ASSERT $value >= 0 — with zero new code.
3. Neither backend has a native u64 (Postgres BIGINT/SurrealDB int are both i64); a distinct type would force NUMERIC/workarounds for no conformance payoff.
4. The bridge already can't round-trip > i64::MAX into storage (cel_to_dynamic uses i64::try_from → Overflow), so a distinct uint type wouldn't even unlock that range by itself.

Consequence: values above i64::MAX are out of scope until a concrete need appears; rule expressions over these fields see CEL int (authors can uint(x) inside an expression if they need uint semantics). Also establishes the docs/adr/ convention (#91's substrate ADR can be backfilled there).