@githolon/dsl 0.80.0 → 0.80.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@githolon/dsl",
-  "version": "0.80.0",
+  "version": "0.80.1",
   "type": "module",
   "description": "Nomos 2 domain-authoring DSL: aggregates + directives in TS, executed and encoded to the Rust kernel's wire shapes.",
   "license": "SEE LICENSE IN LICENSE.md",

package/src/build_package.ts

@@ -197,12 +197,23 @@ export function composeDomainModule(spec: DomainModuleSpec): DomainModule {
   const byId = new Map<string, AggregateHandle>();
   for (const a of [...aggregatesOf(merged), ...(spec.extraAggregates ?? [])]) byId.set(a.id, a);
   const directives = directivesOf(merged);
-  // RELATIONS AUTO-ENSURE: a directive that `.ensures(RelationTuple)` (the relate-family shape — its plan
-  // `writeTuple`s) needs the framework RelationTuple aggregate IN the schema, or the deploy gate never
-  // learns the type and the tuple write silently fails admission. Inject it so the dev needn't re-export
-  // the framework handle — the same "discoverable without re-exports" courtesy a `capability()` bundle
-  // gets. Era-safe: only a domain that authors tuples gains the aggregate, so no existing manifest hash drifts.
-  if (!byId.has(RelationTuple.id) && directives.some((d) => d.aggregateId === RelationTuple.id)) {
+  // RELATIONS AUTO-ENSURE + AUTO-COMPOSE (co2 recovery DX): a domain that USES relation law — declares a
+  // relation schema, a `.requires(...)`-gated directive, or relate-family/signer directives ensuring
+  // RelationTuple — needs the framework RelationTuple aggregate IN the schema on TWO counts: (1) the deploy
+  // gate must learn the type or a `writeTuple` silently fails admission, and (2) the auto-composed
+  // `relationTuplesByObject` query (appended below) `.returns(RelationTuple)`, so the read projection
+  // (`readProjectionForModule`/`readKeyFieldKind`) cannot resolve its return schema unless RelationTuple is
+  // one of the module's aggregates. Injecting it HERE (before the aggregate snapshot) makes auto-compose
+  // BYTE-EQUIVALENT to a tenant that explicitly `export { relationTuplesByObject, RelationTuple }` — the
+  // same aggregate + query enter the manifest, and the USD prim emission sorts aggregates by id, so
+  // insertion order does not perturb the hash. Era-safe: only a relation-using domain gains the aggregate,
+  // so no existing (relation-free) manifest hash drifts, and a tenant that already had the explicit export
+  // sees NO further move (identical bytes).
+  const usesRelations =
+    (spec.relationTypes ?? []).length > 0 ||
+    directives.some((d) => (d as { requiresRelationGate?: unknown }).requiresRelationGate !== undefined) ||
+    directives.some((d) => d.aggregateId === RelationTuple.id);
+  if (usesRelations && !byId.has(RelationTuple.id)) {
     byId.set(RelationTuple.id, RelationTuple);
   }
   // BIRTH-METER AUTO-ENSURE (metered birth, slice A — the same "discoverable without re-exports"
@@ -285,10 +296,9 @@ export function composeDomainModule(spec: DomainModuleSpec): DomainModule {
   // workspace running the law — no tenant re-export to forget. ERA/OMIT RULE: a relation-free domain
   // appends nothing (byte-identical module/package); a relation-using one gains the query on its NEXT
   // recompile (a named, additive hash move the #58 evolve gate admits silently).
-  const usesRelations =
-    relationTypes.length > 0 ||
-    directives.some((d) => (d as { requiresRelationGate?: unknown }).requiresRelationGate !== undefined) ||
-    directives.some((d) => d.aggregateId === RelationTuple.id);
+  // `usesRelations` was computed above the aggregate snapshot (so RelationTuple could be injected into the
+  // schema); reuse it here to append the audit query. The two MUST agree — the aggregate and the query it
+  // returns have to enter the manifest together, or the read projection can't resolve the return schema.
   if (usesRelations && !queries.some((q) => q.id === relationTuplesByObject.id)) {
     queries.push(relationTuplesByObject);
   }