create-relkit 0.7.8 → 0.7.9

package/dist/create-capabilities.js

@@ -13,16 +13,16 @@ const entries = Object.freeze([
         deploy: "none",
         examples: true,
         identity: Object.freeze({
-            release: "0.7.8",
+            release: "0.7.9",
             bun: "1.3.10",
             typescript: "5.9.3",
             packageCatalogDigest: "ac7c2f56e61fca5ab890775cf4c483722cb590e488ee7fc4741224cbb4f50ccd",
             template: "default/v1/minimal",
             snapshotProtocol: 1,
         }),
-        templateDigest: "579d32ffc180edbf06bb6656099882285cc0d4795601557efdee86d1b470212a",
-        freshEvidence: "docs/evidence/create-capabilities/0.7.8/fresh.json",
-        restartEvidence: "docs/evidence/create-capabilities/0.7.8/restart.json",
+        templateDigest: "e21547aecfb921ffe180f89707686e7bd68cafa8eec21881607b10d64141da02",
+        freshEvidence: "docs/evidence/create-capabilities/0.7.9/fresh.json",
+        restartEvidence: "docs/evidence/create-capabilities/0.7.9/restart.json",
     }),
 ]);
 export const CREATE_CAPABILITY_TABLE = Object.freeze({

package/dist/templates/default/README.md

@@ -8,6 +8,6 @@ scaffolder:
 - `agent` — the minimal example plus a read-only tool and agent descriptor.
 
 Each variant is self-contained and can be copied as a project root. It uses
-the current checked-in RelKit package version (`0.7.8`), Bun `1.3.10`, and
+the current checked-in RelKit package version (`0.7.9`), Bun `1.3.10`, and
 TypeScript `5.9.3`. The generator owns project-name substitution and later
 installation/Git behavior.

package/dist/templates/default/v1/agent/.agents/skills/relkit/SKILL.md

@@ -21,6 +21,16 @@ Recommend optional modules only when they solve a concrete part of this task: fo
 
 Default to backend work. Do not introduce frontend pages, app.js, assets.css or demo interfaces unless requested. Preserve existing frontend files, explicitly selected fullstack functionality and the framework Inspector. For users and orders, define separate resource endpoints with explicit input/output contracts, validation and applicable authorization; avoid a public table dispatcher controlled by an entity parameter. Internal tables and infrastructure services need no public endpoint. Preserve intentional protocol handlers such as the Better Auth mount and shared internal helpers.
 
+## Design domain ownership
+
+Before scaffolding business behavior, identify its owning domain. For a request spanning multiple business capabilities, include a compact ownership map in the implementation plan: service name, owned rules/state, public operations/events, dependencies, and any transaction spanning capabilities. Then proceed with authorized implementation; the map is not another approval gate.
+
+A domain service owns one cohesive business responsibility and its invariants. Separate capabilities with distinct rules, lifecycles, or public contracts. Keep closely related entities together when they share those rules; do not create a service per table, endpoint, or noun. Shared authentication, database, tenant ID, or deployment does not make the entire application one domain. Avoid a product-named catch-all service containing unrelated capabilities.
+
+For existing apps, reuse the service that owns the behavior. Do not reorganize unrelated domains or move existing code without task scope. A small single-domain feature needs only its existing owner, not a new architecture exercise.
+
+Read [domain design and public contracts](references/domain-apis.md) when choosing boundaries or coordinating services. Name the owner of each invariant that spans domains and explain how atomic updates remain atomic. Do not assume a nested service invocation shares the caller's database transaction. Keep the shared database/auth singletons and one migration history; business boundaries do not require separate databases or deployments.
+
 ## Source placement
 
 New projects place every generic, database, and auth boundary at `src/services/<name>/service.ts`. Keep its functions, events, tasks, jobs, tools, agents, channels, schemas, resources, helpers, and assets under that service. Routes live at `src/routes`; configuration support and environment contracts live at `src/platform`. Application descriptors use plain TypeScript and supported public APIs; Effect imports are not required.
@@ -59,6 +69,8 @@ Read only the reference relevant to the requested change. These examples describ
 
 ## Verify the result
 
+Compare the final services and route targets with the ownership map. Confirm each capability has real operations under its owner, cross-service imports use public contracts, and no catch-all implementation hides behind empty services. Explain deliberate boundary changes and verify cross-domain consistency/failure behavior. A passing graph check validates structure, not domain cohesion.
+
 Review the CLI's created and updated files, warnings, next steps and final diff. Run focused checks after logical changes. Before completion, run applicable check, typecheck, build, unit/integration tests and existing relevant end-to-end coverage. Inspect package.json for actual script names. For HTTP work, test the route's status/body, valid and invalid input, and denied and allowed access where relevant; a direct function test does not cover request mapping or the complete flow. Replay the original bug through the boundary that failed. Backend/API tests do not require an unsolicited frontend.
 
 Database/auth changes also need explicit environment setup and migration steps from [the data reference](references/data-apis.md), followed by persistence/session/authorization verification. Stop all test-owned servers and clients. Report what changed, exact verification performed, and every failed, skipped or blocked check with its effect on confidence. Written code or passing unit tests alone is not fully verified delivery when affected runtime behavior remains untested.

package/dist/templates/default/v1/agent/.agents/skills/relkit/references/domain-apis.md

@@ -2,6 +2,60 @@
 
 Generated projects map `@app/*` to `src/*`; keep the `.js` suffix on source imports. Use the installed package types when an exact signature matters, and run `bun run check` to validate the discovered graph.
 
+## Choose a domain before choosing a folder
+
+For work spanning business capabilities, map responsibility to services before adding artifacts. Record the rules/state each service owns, the operations/events it exposes, its dependencies, and who coordinates invariants that cross boundaries. Service names should describe those responsibilities, not merely repeat the application name.
+
+For example, a commerce backend could use:
+
+| Service         | Owns                                      | Public contract                      |
+| --------------- | ----------------------------------------- | ------------------------------------ |
+| `orders`        | Order lifecycle and accepted order totals | Place/cancel order, `orders.created` |
+| `pricing`       | Price calculation and discount rules      | Calculate a quote                    |
+| `notifications` | Notification delivery and deduplication   | React to an order event              |
+
+This is an example, not a required taxonomy. Related entities such as cars and car models may belong to one fleet service. Split by distinct rules and lifecycles, not by table count. One coherent capability can remain one service. A shared database, auth service, or tenant identifier is infrastructure reuse, not a reason to collect all business operations under one service.
+
+### Public collaboration
+
+Each service selects its own operations; another service must not act as a barrel for its neighbor's internals:
+
+```ts
+// src/services/pricing/service.ts
+import { defineService } from "@relkit/app/services";
+import calculateQuote from "./functions/calculate-quote.function.js";
+
+export default defineService({ functions: { calculateQuote } });
+```
+
+An orders function can call the public pricing contract. For a pure calculation that needs no provider state:
+
+```ts
+import pricing from "@app/services/pricing/service.js";
+
+// Inside an orders function handler:
+const quote = await pricing.calculateQuote.invoke({ sku, quantity });
+// Apply the order's acceptance rules to the validated quote.
+```
+
+Use the installed declarations for the calculation's actual input/output. Do not import `pricing/functions/*`, call a foreign handler, or expose the same function as a member of two services. A route for orders targets the orders service; separate URLs alone do not establish domain boundaries.
+
+For an asynchronous reaction, orders owns and exposes `orders.created`; a consumer under `src/services/notifications/functions/` uses `defineEventFunction({ id: "notifications.order-created", event: "orders.created", ... })`. Event-only consumers are discovered in their owning domain and are not added to its callable functions map. The event examples below show publication and subscription.
+
+### Invariants and transactions
+
+Name one owner for a command's consistency rules. For example, accepting an order and reserving stock may require one atomic decision. A service call followed by a second write is not proof of an atomic transaction, and `.invoke()` must not be assumed to inherit the caller's transaction or resources.
+
+Inspect installed transaction/invocation behavior before composing provider-backed commands. Choose a supported transaction coordinator or keep tightly coupled invariants within one cohesive owner. Define narrow public operations for other domains; do not duplicate another domain's rules or silently write its owned state from arbitrary helpers. Use events for reactions that can occur after commit, with an outbox when publication must survive a crash. Events alone do not preserve synchronous atomicity.
+
+Keep one shared database service and its ordered migration history when the app uses one database. Do not create a database, auth service, or migration history per business domain.
+
+Changing an existing operation's domain ownership is a redesign, not just a grouped/flat layout move. Review IDs, durable versions, policies, callers, and stored history explicitly; do not promise that a folder move between domains preserves identity.
+
+### Review the resulting boundaries
+
+Compare the actual service graph and routes with the ownership map. Check that each planned capability has real operations under its owner, imports use public service boundaries, business rules live with their owner, and no catch-all service still contains the implementation behind empty facades. Review any merged or split responsibility and verify cross-domain failure/rollback behavior. A passing graph check proves structural validity, not semantic cohesion.
+
 ## `defineFunction` and `defineService`
 
 Put domain behavior in `src/services/<domain>/functions/*.function.ts`. A function validates input before its handler and validates the returned output:
@@ -62,13 +116,13 @@ export default orderCreated;
 
 Expose it through `defineService({ events: { orderCreated } })` when other domains need it. A publisher declares the exact ID in `publishes: ["orders.created"]` and calls `await context.events["orders.created"].publish({ orderId })`.
 
-An event-only consumer reacts without returning a result to its publisher:
+An event-only consumer in `src/services/notifications/functions/` reacts without returning a result to its publisher:
 
 ```ts
 import { defineEventFunction } from "@relkit/app/events";
 
 export default defineEventFunction({
-  id: "orders.confirmation",
+  id: "notifications.order-created",
   event: "orders.created",
   handler: async ({ orderId }, context) => {
     context.log.info("Order created", { orderId });

package/dist/templates/default/v1/agent/package.json

@@ -16,15 +16,15 @@
   },
   "dependencies": {
     "@langchain/langgraph": "1.4.14",
-    "@relkit/app": "0.7.8",
-    "@relkit/local": "0.7.8",
+    "@relkit/app": "0.7.9",
+    "@relkit/local": "0.7.9",
     "effect": "4.0.1",
     "langchain": "1.5.10"
   },
   "devDependencies": {
     "@types/bun": "1.3.10",
-    "@relkit/cli": "0.7.8",
-    "@relkit/testing": "0.7.8",
+    "@relkit/cli": "0.7.9",
+    "@relkit/testing": "0.7.9",
     "typescript": "5.9.3"
   }
 }

package/dist/templates/default/v1/api/.agents/skills/relkit/SKILL.md

@@ -21,6 +21,16 @@ Recommend optional modules only when they solve a concrete part of this task: fo
 
 Default to backend work. Do not introduce frontend pages, app.js, assets.css or demo interfaces unless requested. Preserve existing frontend files, explicitly selected fullstack functionality and the framework Inspector. For users and orders, define separate resource endpoints with explicit input/output contracts, validation and applicable authorization; avoid a public table dispatcher controlled by an entity parameter. Internal tables and infrastructure services need no public endpoint. Preserve intentional protocol handlers such as the Better Auth mount and shared internal helpers.
 
+## Design domain ownership
+
+Before scaffolding business behavior, identify its owning domain. For a request spanning multiple business capabilities, include a compact ownership map in the implementation plan: service name, owned rules/state, public operations/events, dependencies, and any transaction spanning capabilities. Then proceed with authorized implementation; the map is not another approval gate.
+
+A domain service owns one cohesive business responsibility and its invariants. Separate capabilities with distinct rules, lifecycles, or public contracts. Keep closely related entities together when they share those rules; do not create a service per table, endpoint, or noun. Shared authentication, database, tenant ID, or deployment does not make the entire application one domain. Avoid a product-named catch-all service containing unrelated capabilities.
+
+For existing apps, reuse the service that owns the behavior. Do not reorganize unrelated domains or move existing code without task scope. A small single-domain feature needs only its existing owner, not a new architecture exercise.
+
+Read [domain design and public contracts](references/domain-apis.md) when choosing boundaries or coordinating services. Name the owner of each invariant that spans domains and explain how atomic updates remain atomic. Do not assume a nested service invocation shares the caller's database transaction. Keep the shared database/auth singletons and one migration history; business boundaries do not require separate databases or deployments.
+
 ## Source placement
 
 New projects place every generic, database, and auth boundary at `src/services/<name>/service.ts`. Keep its functions, events, tasks, jobs, tools, agents, channels, schemas, resources, helpers, and assets under that service. Routes live at `src/routes`; configuration support and environment contracts live at `src/platform`. Application descriptors use plain TypeScript and supported public APIs; Effect imports are not required.
@@ -59,6 +69,8 @@ Read only the reference relevant to the requested change. These examples describ
 
 ## Verify the result
 
+Compare the final services and route targets with the ownership map. Confirm each capability has real operations under its owner, cross-service imports use public contracts, and no catch-all implementation hides behind empty services. Explain deliberate boundary changes and verify cross-domain consistency/failure behavior. A passing graph check validates structure, not domain cohesion.
+
 Review the CLI's created and updated files, warnings, next steps and final diff. Run focused checks after logical changes. Before completion, run applicable check, typecheck, build, unit/integration tests and existing relevant end-to-end coverage. Inspect package.json for actual script names. For HTTP work, test the route's status/body, valid and invalid input, and denied and allowed access where relevant; a direct function test does not cover request mapping or the complete flow. Replay the original bug through the boundary that failed. Backend/API tests do not require an unsolicited frontend.
 
 Database/auth changes also need explicit environment setup and migration steps from [the data reference](references/data-apis.md), followed by persistence/session/authorization verification. Stop all test-owned servers and clients. Report what changed, exact verification performed, and every failed, skipped or blocked check with its effect on confidence. Written code or passing unit tests alone is not fully verified delivery when affected runtime behavior remains untested.

package/dist/templates/default/v1/api/.agents/skills/relkit/references/domain-apis.md

@@ -2,6 +2,60 @@
 
 Generated projects map `@app/*` to `src/*`; keep the `.js` suffix on source imports. Use the installed package types when an exact signature matters, and run `bun run check` to validate the discovered graph.
 
+## Choose a domain before choosing a folder
+
+For work spanning business capabilities, map responsibility to services before adding artifacts. Record the rules/state each service owns, the operations/events it exposes, its dependencies, and who coordinates invariants that cross boundaries. Service names should describe those responsibilities, not merely repeat the application name.
+
+For example, a commerce backend could use:
+
+| Service         | Owns                                      | Public contract                      |
+| --------------- | ----------------------------------------- | ------------------------------------ |
+| `orders`        | Order lifecycle and accepted order totals | Place/cancel order, `orders.created` |
+| `pricing`       | Price calculation and discount rules      | Calculate a quote                    |
+| `notifications` | Notification delivery and deduplication   | React to an order event              |
+
+This is an example, not a required taxonomy. Related entities such as cars and car models may belong to one fleet service. Split by distinct rules and lifecycles, not by table count. One coherent capability can remain one service. A shared database, auth service, or tenant identifier is infrastructure reuse, not a reason to collect all business operations under one service.
+
+### Public collaboration
+
+Each service selects its own operations; another service must not act as a barrel for its neighbor's internals:
+
+```ts
+// src/services/pricing/service.ts
+import { defineService } from "@relkit/app/services";
+import calculateQuote from "./functions/calculate-quote.function.js";
+
+export default defineService({ functions: { calculateQuote } });
+```
+
+An orders function can call the public pricing contract. For a pure calculation that needs no provider state:
+
+```ts
+import pricing from "@app/services/pricing/service.js";
+
+// Inside an orders function handler:
+const quote = await pricing.calculateQuote.invoke({ sku, quantity });
+// Apply the order's acceptance rules to the validated quote.
+```
+
+Use the installed declarations for the calculation's actual input/output. Do not import `pricing/functions/*`, call a foreign handler, or expose the same function as a member of two services. A route for orders targets the orders service; separate URLs alone do not establish domain boundaries.
+
+For an asynchronous reaction, orders owns and exposes `orders.created`; a consumer under `src/services/notifications/functions/` uses `defineEventFunction({ id: "notifications.order-created", event: "orders.created", ... })`. Event-only consumers are discovered in their owning domain and are not added to its callable functions map. The event examples below show publication and subscription.
+
+### Invariants and transactions
+
+Name one owner for a command's consistency rules. For example, accepting an order and reserving stock may require one atomic decision. A service call followed by a second write is not proof of an atomic transaction, and `.invoke()` must not be assumed to inherit the caller's transaction or resources.
+
+Inspect installed transaction/invocation behavior before composing provider-backed commands. Choose a supported transaction coordinator or keep tightly coupled invariants within one cohesive owner. Define narrow public operations for other domains; do not duplicate another domain's rules or silently write its owned state from arbitrary helpers. Use events for reactions that can occur after commit, with an outbox when publication must survive a crash. Events alone do not preserve synchronous atomicity.
+
+Keep one shared database service and its ordered migration history when the app uses one database. Do not create a database, auth service, or migration history per business domain.
+
+Changing an existing operation's domain ownership is a redesign, not just a grouped/flat layout move. Review IDs, durable versions, policies, callers, and stored history explicitly; do not promise that a folder move between domains preserves identity.
+
+### Review the resulting boundaries
+
+Compare the actual service graph and routes with the ownership map. Check that each planned capability has real operations under its owner, imports use public service boundaries, business rules live with their owner, and no catch-all service still contains the implementation behind empty facades. Review any merged or split responsibility and verify cross-domain failure/rollback behavior. A passing graph check proves structural validity, not semantic cohesion.
+
 ## `defineFunction` and `defineService`
 
 Put domain behavior in `src/services/<domain>/functions/*.function.ts`. A function validates input before its handler and validates the returned output:
@@ -62,13 +116,13 @@ export default orderCreated;
 
 Expose it through `defineService({ events: { orderCreated } })` when other domains need it. A publisher declares the exact ID in `publishes: ["orders.created"]` and calls `await context.events["orders.created"].publish({ orderId })`.
 
-An event-only consumer reacts without returning a result to its publisher:
+An event-only consumer in `src/services/notifications/functions/` reacts without returning a result to its publisher:
 
 ```ts
 import { defineEventFunction } from "@relkit/app/events";
 
 export default defineEventFunction({
-  id: "orders.confirmation",
+  id: "notifications.order-created",
   event: "orders.created",
   handler: async ({ orderId }, context) => {
     context.log.info("Order created", { orderId });

package/dist/templates/default/v1/api/package.json

@@ -15,13 +15,13 @@
     "graph": "relkit graph print"
   },
   "dependencies": {
-    "@relkit/app": "0.7.8",
+    "@relkit/app": "0.7.9",
     "effect": "4.0.1"
   },
   "devDependencies": {
     "@types/bun": "1.3.10",
-    "@relkit/cli": "0.7.8",
-    "@relkit/testing": "0.7.8",
+    "@relkit/cli": "0.7.9",
+    "@relkit/testing": "0.7.9",
     "typescript": "5.9.3"
   }
 }

package/dist/templates/default/v1/fullstack/.agents/skills/relkit/SKILL.md

@@ -21,6 +21,16 @@ Recommend optional modules only when they solve a concrete part of this task: fo
 
 Default to backend work. Do not introduce frontend pages, app.js, assets.css or demo interfaces unless requested. Preserve existing frontend files, explicitly selected fullstack functionality and the framework Inspector. For users and orders, define separate resource endpoints with explicit input/output contracts, validation and applicable authorization; avoid a public table dispatcher controlled by an entity parameter. Internal tables and infrastructure services need no public endpoint. Preserve intentional protocol handlers such as the Better Auth mount and shared internal helpers.
 
+## Design domain ownership
+
+Before scaffolding business behavior, identify its owning domain. For a request spanning multiple business capabilities, include a compact ownership map in the implementation plan: service name, owned rules/state, public operations/events, dependencies, and any transaction spanning capabilities. Then proceed with authorized implementation; the map is not another approval gate.
+
+A domain service owns one cohesive business responsibility and its invariants. Separate capabilities with distinct rules, lifecycles, or public contracts. Keep closely related entities together when they share those rules; do not create a service per table, endpoint, or noun. Shared authentication, database, tenant ID, or deployment does not make the entire application one domain. Avoid a product-named catch-all service containing unrelated capabilities.
+
+For existing apps, reuse the service that owns the behavior. Do not reorganize unrelated domains or move existing code without task scope. A small single-domain feature needs only its existing owner, not a new architecture exercise.
+
+Read [domain design and public contracts](references/domain-apis.md) when choosing boundaries or coordinating services. Name the owner of each invariant that spans domains and explain how atomic updates remain atomic. Do not assume a nested service invocation shares the caller's database transaction. Keep the shared database/auth singletons and one migration history; business boundaries do not require separate databases or deployments.
+
 ## Source placement
 
 New projects place every generic, database, and auth boundary at `src/services/<name>/service.ts`. Keep its functions, events, tasks, jobs, tools, agents, channels, schemas, resources, helpers, and assets under that service. Routes live at `src/routes`; configuration support and environment contracts live at `src/platform`. Application descriptors use plain TypeScript and supported public APIs; Effect imports are not required.
@@ -59,6 +69,8 @@ Read only the reference relevant to the requested change. These examples describ
 
 ## Verify the result
 
+Compare the final services and route targets with the ownership map. Confirm each capability has real operations under its owner, cross-service imports use public contracts, and no catch-all implementation hides behind empty services. Explain deliberate boundary changes and verify cross-domain consistency/failure behavior. A passing graph check validates structure, not domain cohesion.
+
 Review the CLI's created and updated files, warnings, next steps and final diff. Run focused checks after logical changes. Before completion, run applicable check, typecheck, build, unit/integration tests and existing relevant end-to-end coverage. Inspect package.json for actual script names. For HTTP work, test the route's status/body, valid and invalid input, and denied and allowed access where relevant; a direct function test does not cover request mapping or the complete flow. Replay the original bug through the boundary that failed. Backend/API tests do not require an unsolicited frontend.
 
 Database/auth changes also need explicit environment setup and migration steps from [the data reference](references/data-apis.md), followed by persistence/session/authorization verification. Stop all test-owned servers and clients. Report what changed, exact verification performed, and every failed, skipped or blocked check with its effect on confidence. Written code or passing unit tests alone is not fully verified delivery when affected runtime behavior remains untested.

package/dist/templates/default/v1/fullstack/.agents/skills/relkit/references/domain-apis.md

@@ -2,6 +2,60 @@
 
 Generated projects map `@app/*` to `src/*`; keep the `.js` suffix on source imports. Use the installed package types when an exact signature matters, and run `bun run check` to validate the discovered graph.
 
+## Choose a domain before choosing a folder
+
+For work spanning business capabilities, map responsibility to services before adding artifacts. Record the rules/state each service owns, the operations/events it exposes, its dependencies, and who coordinates invariants that cross boundaries. Service names should describe those responsibilities, not merely repeat the application name.
+
+For example, a commerce backend could use:
+
+| Service         | Owns                                      | Public contract                      |
+| --------------- | ----------------------------------------- | ------------------------------------ |
+| `orders`        | Order lifecycle and accepted order totals | Place/cancel order, `orders.created` |
+| `pricing`       | Price calculation and discount rules      | Calculate a quote                    |
+| `notifications` | Notification delivery and deduplication   | React to an order event              |
+
+This is an example, not a required taxonomy. Related entities such as cars and car models may belong to one fleet service. Split by distinct rules and lifecycles, not by table count. One coherent capability can remain one service. A shared database, auth service, or tenant identifier is infrastructure reuse, not a reason to collect all business operations under one service.
+
+### Public collaboration
+
+Each service selects its own operations; another service must not act as a barrel for its neighbor's internals:
+
+```ts
+// src/services/pricing/service.ts
+import { defineService } from "@relkit/app/services";
+import calculateQuote from "./functions/calculate-quote.function.js";
+
+export default defineService({ functions: { calculateQuote } });
+```
+
+An orders function can call the public pricing contract. For a pure calculation that needs no provider state:
+
+```ts
+import pricing from "@app/services/pricing/service.js";
+
+// Inside an orders function handler:
+const quote = await pricing.calculateQuote.invoke({ sku, quantity });
+// Apply the order's acceptance rules to the validated quote.
+```
+
+Use the installed declarations for the calculation's actual input/output. Do not import `pricing/functions/*`, call a foreign handler, or expose the same function as a member of two services. A route for orders targets the orders service; separate URLs alone do not establish domain boundaries.
+
+For an asynchronous reaction, orders owns and exposes `orders.created`; a consumer under `src/services/notifications/functions/` uses `defineEventFunction({ id: "notifications.order-created", event: "orders.created", ... })`. Event-only consumers are discovered in their owning domain and are not added to its callable functions map. The event examples below show publication and subscription.
+
+### Invariants and transactions
+
+Name one owner for a command's consistency rules. For example, accepting an order and reserving stock may require one atomic decision. A service call followed by a second write is not proof of an atomic transaction, and `.invoke()` must not be assumed to inherit the caller's transaction or resources.
+
+Inspect installed transaction/invocation behavior before composing provider-backed commands. Choose a supported transaction coordinator or keep tightly coupled invariants within one cohesive owner. Define narrow public operations for other domains; do not duplicate another domain's rules or silently write its owned state from arbitrary helpers. Use events for reactions that can occur after commit, with an outbox when publication must survive a crash. Events alone do not preserve synchronous atomicity.
+
+Keep one shared database service and its ordered migration history when the app uses one database. Do not create a database, auth service, or migration history per business domain.
+
+Changing an existing operation's domain ownership is a redesign, not just a grouped/flat layout move. Review IDs, durable versions, policies, callers, and stored history explicitly; do not promise that a folder move between domains preserves identity.
+
+### Review the resulting boundaries
+
+Compare the actual service graph and routes with the ownership map. Check that each planned capability has real operations under its owner, imports use public service boundaries, business rules live with their owner, and no catch-all service still contains the implementation behind empty facades. Review any merged or split responsibility and verify cross-domain failure/rollback behavior. A passing graph check proves structural validity, not semantic cohesion.
+
 ## `defineFunction` and `defineService`
 
 Put domain behavior in `src/services/<domain>/functions/*.function.ts`. A function validates input before its handler and validates the returned output:
@@ -62,13 +116,13 @@ export default orderCreated;
 
 Expose it through `defineService({ events: { orderCreated } })` when other domains need it. A publisher declares the exact ID in `publishes: ["orders.created"]` and calls `await context.events["orders.created"].publish({ orderId })`.
 
-An event-only consumer reacts without returning a result to its publisher:
+An event-only consumer in `src/services/notifications/functions/` reacts without returning a result to its publisher:
 
 ```ts
 import { defineEventFunction } from "@relkit/app/events";
 
 export default defineEventFunction({
-  id: "orders.confirmation",
+  id: "notifications.order-created",
   event: "orders.created",
   handler: async ({ orderId }, context) => {
     context.log.info("Order created", { orderId });

package/dist/templates/default/v1/fullstack/package.json

@@ -15,9 +15,9 @@
   },
   "dependencies": {
     "@langchain/langgraph": "1.4.14",
-    "@relkit/app": "0.7.8",
-    "@relkit/client": "0.7.8",
-    "@relkit/local": "0.7.8",
+    "@relkit/app": "0.7.9",
+    "@relkit/client": "0.7.9",
+    "@relkit/local": "0.7.9",
     "@tanstack/react-query": "5.102.3",
     "effect": "4.0.1",
     "langchain": "1.5.10",
@@ -26,8 +26,8 @@
     "react-dom": "19.2.8"
   },
   "devDependencies": {
-    "@relkit/cli": "0.7.8",
-    "@relkit/testing": "0.7.8",
+    "@relkit/cli": "0.7.9",
+    "@relkit/testing": "0.7.9",
     "@types/bun": "1.3.10",
     "@types/react": "19.2.18",
     "@types/react-dom": "19.2.7",

package/dist/templates/default/v1/minimal/.agents/skills/relkit/SKILL.md

@@ -21,6 +21,16 @@ Recommend optional modules only when they solve a concrete part of this task: fo
 
 Default to backend work. Do not introduce frontend pages, app.js, assets.css or demo interfaces unless requested. Preserve existing frontend files, explicitly selected fullstack functionality and the framework Inspector. For users and orders, define separate resource endpoints with explicit input/output contracts, validation and applicable authorization; avoid a public table dispatcher controlled by an entity parameter. Internal tables and infrastructure services need no public endpoint. Preserve intentional protocol handlers such as the Better Auth mount and shared internal helpers.
 
+## Design domain ownership
+
+Before scaffolding business behavior, identify its owning domain. For a request spanning multiple business capabilities, include a compact ownership map in the implementation plan: service name, owned rules/state, public operations/events, dependencies, and any transaction spanning capabilities. Then proceed with authorized implementation; the map is not another approval gate.
+
+A domain service owns one cohesive business responsibility and its invariants. Separate capabilities with distinct rules, lifecycles, or public contracts. Keep closely related entities together when they share those rules; do not create a service per table, endpoint, or noun. Shared authentication, database, tenant ID, or deployment does not make the entire application one domain. Avoid a product-named catch-all service containing unrelated capabilities.
+
+For existing apps, reuse the service that owns the behavior. Do not reorganize unrelated domains or move existing code without task scope. A small single-domain feature needs only its existing owner, not a new architecture exercise.
+
+Read [domain design and public contracts](references/domain-apis.md) when choosing boundaries or coordinating services. Name the owner of each invariant that spans domains and explain how atomic updates remain atomic. Do not assume a nested service invocation shares the caller's database transaction. Keep the shared database/auth singletons and one migration history; business boundaries do not require separate databases or deployments.
+
 ## Source placement
 
 New projects place every generic, database, and auth boundary at `src/services/<name>/service.ts`. Keep its functions, events, tasks, jobs, tools, agents, channels, schemas, resources, helpers, and assets under that service. Routes live at `src/routes`; configuration support and environment contracts live at `src/platform`. Application descriptors use plain TypeScript and supported public APIs; Effect imports are not required.
@@ -59,6 +69,8 @@ Read only the reference relevant to the requested change. These examples describ
 
 ## Verify the result
 
+Compare the final services and route targets with the ownership map. Confirm each capability has real operations under its owner, cross-service imports use public contracts, and no catch-all implementation hides behind empty services. Explain deliberate boundary changes and verify cross-domain consistency/failure behavior. A passing graph check validates structure, not domain cohesion.
+
 Review the CLI's created and updated files, warnings, next steps and final diff. Run focused checks after logical changes. Before completion, run applicable check, typecheck, build, unit/integration tests and existing relevant end-to-end coverage. Inspect package.json for actual script names. For HTTP work, test the route's status/body, valid and invalid input, and denied and allowed access where relevant; a direct function test does not cover request mapping or the complete flow. Replay the original bug through the boundary that failed. Backend/API tests do not require an unsolicited frontend.
 
 Database/auth changes also need explicit environment setup and migration steps from [the data reference](references/data-apis.md), followed by persistence/session/authorization verification. Stop all test-owned servers and clients. Report what changed, exact verification performed, and every failed, skipped or blocked check with its effect on confidence. Written code or passing unit tests alone is not fully verified delivery when affected runtime behavior remains untested.

package/dist/templates/default/v1/minimal/.agents/skills/relkit/references/domain-apis.md

@@ -2,6 +2,60 @@
 
 Generated projects map `@app/*` to `src/*`; keep the `.js` suffix on source imports. Use the installed package types when an exact signature matters, and run `bun run check` to validate the discovered graph.
 
+## Choose a domain before choosing a folder
+
+For work spanning business capabilities, map responsibility to services before adding artifacts. Record the rules/state each service owns, the operations/events it exposes, its dependencies, and who coordinates invariants that cross boundaries. Service names should describe those responsibilities, not merely repeat the application name.
+
+For example, a commerce backend could use:
+
+| Service         | Owns                                      | Public contract                      |
+| --------------- | ----------------------------------------- | ------------------------------------ |
+| `orders`        | Order lifecycle and accepted order totals | Place/cancel order, `orders.created` |
+| `pricing`       | Price calculation and discount rules      | Calculate a quote                    |
+| `notifications` | Notification delivery and deduplication   | React to an order event              |
+
+This is an example, not a required taxonomy. Related entities such as cars and car models may belong to one fleet service. Split by distinct rules and lifecycles, not by table count. One coherent capability can remain one service. A shared database, auth service, or tenant identifier is infrastructure reuse, not a reason to collect all business operations under one service.
+
+### Public collaboration
+
+Each service selects its own operations; another service must not act as a barrel for its neighbor's internals:
+
+```ts
+// src/services/pricing/service.ts
+import { defineService } from "@relkit/app/services";
+import calculateQuote from "./functions/calculate-quote.function.js";
+
+export default defineService({ functions: { calculateQuote } });
+```
+
+An orders function can call the public pricing contract. For a pure calculation that needs no provider state:
+
+```ts
+import pricing from "@app/services/pricing/service.js";
+
+// Inside an orders function handler:
+const quote = await pricing.calculateQuote.invoke({ sku, quantity });
+// Apply the order's acceptance rules to the validated quote.
+```
+
+Use the installed declarations for the calculation's actual input/output. Do not import `pricing/functions/*`, call a foreign handler, or expose the same function as a member of two services. A route for orders targets the orders service; separate URLs alone do not establish domain boundaries.
+
+For an asynchronous reaction, orders owns and exposes `orders.created`; a consumer under `src/services/notifications/functions/` uses `defineEventFunction({ id: "notifications.order-created", event: "orders.created", ... })`. Event-only consumers are discovered in their owning domain and are not added to its callable functions map. The event examples below show publication and subscription.
+
+### Invariants and transactions
+
+Name one owner for a command's consistency rules. For example, accepting an order and reserving stock may require one atomic decision. A service call followed by a second write is not proof of an atomic transaction, and `.invoke()` must not be assumed to inherit the caller's transaction or resources.
+
+Inspect installed transaction/invocation behavior before composing provider-backed commands. Choose a supported transaction coordinator or keep tightly coupled invariants within one cohesive owner. Define narrow public operations for other domains; do not duplicate another domain's rules or silently write its owned state from arbitrary helpers. Use events for reactions that can occur after commit, with an outbox when publication must survive a crash. Events alone do not preserve synchronous atomicity.
+
+Keep one shared database service and its ordered migration history when the app uses one database. Do not create a database, auth service, or migration history per business domain.
+
+Changing an existing operation's domain ownership is a redesign, not just a grouped/flat layout move. Review IDs, durable versions, policies, callers, and stored history explicitly; do not promise that a folder move between domains preserves identity.
+
+### Review the resulting boundaries
+
+Compare the actual service graph and routes with the ownership map. Check that each planned capability has real operations under its owner, imports use public service boundaries, business rules live with their owner, and no catch-all service still contains the implementation behind empty facades. Review any merged or split responsibility and verify cross-domain failure/rollback behavior. A passing graph check proves structural validity, not semantic cohesion.
+
 ## `defineFunction` and `defineService`
 
 Put domain behavior in `src/services/<domain>/functions/*.function.ts`. A function validates input before its handler and validates the returned output:
@@ -62,13 +116,13 @@ export default orderCreated;
 
 Expose it through `defineService({ events: { orderCreated } })` when other domains need it. A publisher declares the exact ID in `publishes: ["orders.created"]` and calls `await context.events["orders.created"].publish({ orderId })`.
 
-An event-only consumer reacts without returning a result to its publisher:
+An event-only consumer in `src/services/notifications/functions/` reacts without returning a result to its publisher:
 
 ```ts
 import { defineEventFunction } from "@relkit/app/events";
 
 export default defineEventFunction({
-  id: "orders.confirmation",
+  id: "notifications.order-created",
   event: "orders.created",
   handler: async ({ orderId }, context) => {
     context.log.info("Order created", { orderId });

package/dist/templates/default/v1/minimal/package.json

@@ -15,13 +15,13 @@
     "graph": "relkit graph print"
   },
   "dependencies": {
-    "@relkit/app": "0.7.8",
+    "@relkit/app": "0.7.9",
     "effect": "4.0.1"
   },
   "devDependencies": {
     "@types/bun": "1.3.10",
-    "@relkit/cli": "0.7.8",
-    "@relkit/testing": "0.7.8",
+    "@relkit/cli": "0.7.9",
+    "@relkit/testing": "0.7.9",
     "typescript": "5.9.3"
   }
 }

package/dist/templates/default/v1/tasks/.agents/skills/relkit/SKILL.md

@@ -21,6 +21,16 @@ Recommend optional modules only when they solve a concrete part of this task: fo
 
 Default to backend work. Do not introduce frontend pages, app.js, assets.css or demo interfaces unless requested. Preserve existing frontend files, explicitly selected fullstack functionality and the framework Inspector. For users and orders, define separate resource endpoints with explicit input/output contracts, validation and applicable authorization; avoid a public table dispatcher controlled by an entity parameter. Internal tables and infrastructure services need no public endpoint. Preserve intentional protocol handlers such as the Better Auth mount and shared internal helpers.
 
+## Design domain ownership
+
+Before scaffolding business behavior, identify its owning domain. For a request spanning multiple business capabilities, include a compact ownership map in the implementation plan: service name, owned rules/state, public operations/events, dependencies, and any transaction spanning capabilities. Then proceed with authorized implementation; the map is not another approval gate.
+
+A domain service owns one cohesive business responsibility and its invariants. Separate capabilities with distinct rules, lifecycles, or public contracts. Keep closely related entities together when they share those rules; do not create a service per table, endpoint, or noun. Shared authentication, database, tenant ID, or deployment does not make the entire application one domain. Avoid a product-named catch-all service containing unrelated capabilities.
+
+For existing apps, reuse the service that owns the behavior. Do not reorganize unrelated domains or move existing code without task scope. A small single-domain feature needs only its existing owner, not a new architecture exercise.
+
+Read [domain design and public contracts](references/domain-apis.md) when choosing boundaries or coordinating services. Name the owner of each invariant that spans domains and explain how atomic updates remain atomic. Do not assume a nested service invocation shares the caller's database transaction. Keep the shared database/auth singletons and one migration history; business boundaries do not require separate databases or deployments.
+
 ## Source placement
 
 New projects place every generic, database, and auth boundary at `src/services/<name>/service.ts`. Keep its functions, events, tasks, jobs, tools, agents, channels, schemas, resources, helpers, and assets under that service. Routes live at `src/routes`; configuration support and environment contracts live at `src/platform`. Application descriptors use plain TypeScript and supported public APIs; Effect imports are not required.
@@ -59,6 +69,8 @@ Read only the reference relevant to the requested change. These examples describ
 
 ## Verify the result
 
+Compare the final services and route targets with the ownership map. Confirm each capability has real operations under its owner, cross-service imports use public contracts, and no catch-all implementation hides behind empty services. Explain deliberate boundary changes and verify cross-domain consistency/failure behavior. A passing graph check validates structure, not domain cohesion.
+
 Review the CLI's created and updated files, warnings, next steps and final diff. Run focused checks after logical changes. Before completion, run applicable check, typecheck, build, unit/integration tests and existing relevant end-to-end coverage. Inspect package.json for actual script names. For HTTP work, test the route's status/body, valid and invalid input, and denied and allowed access where relevant; a direct function test does not cover request mapping or the complete flow. Replay the original bug through the boundary that failed. Backend/API tests do not require an unsolicited frontend.
 
 Database/auth changes also need explicit environment setup and migration steps from [the data reference](references/data-apis.md), followed by persistence/session/authorization verification. Stop all test-owned servers and clients. Report what changed, exact verification performed, and every failed, skipped or blocked check with its effect on confidence. Written code or passing unit tests alone is not fully verified delivery when affected runtime behavior remains untested.

package/dist/templates/default/v1/tasks/.agents/skills/relkit/references/domain-apis.md

@@ -2,6 +2,60 @@
 
 Generated projects map `@app/*` to `src/*`; keep the `.js` suffix on source imports. Use the installed package types when an exact signature matters, and run `bun run check` to validate the discovered graph.
 
+## Choose a domain before choosing a folder
+
+For work spanning business capabilities, map responsibility to services before adding artifacts. Record the rules/state each service owns, the operations/events it exposes, its dependencies, and who coordinates invariants that cross boundaries. Service names should describe those responsibilities, not merely repeat the application name.
+
+For example, a commerce backend could use:
+
+| Service         | Owns                                      | Public contract                      |
+| --------------- | ----------------------------------------- | ------------------------------------ |
+| `orders`        | Order lifecycle and accepted order totals | Place/cancel order, `orders.created` |
+| `pricing`       | Price calculation and discount rules      | Calculate a quote                    |
+| `notifications` | Notification delivery and deduplication   | React to an order event              |
+
+This is an example, not a required taxonomy. Related entities such as cars and car models may belong to one fleet service. Split by distinct rules and lifecycles, not by table count. One coherent capability can remain one service. A shared database, auth service, or tenant identifier is infrastructure reuse, not a reason to collect all business operations under one service.
+
+### Public collaboration
+
+Each service selects its own operations; another service must not act as a barrel for its neighbor's internals:
+
+```ts
+// src/services/pricing/service.ts
+import { defineService } from "@relkit/app/services";
+import calculateQuote from "./functions/calculate-quote.function.js";
+
+export default defineService({ functions: { calculateQuote } });
+```
+
+An orders function can call the public pricing contract. For a pure calculation that needs no provider state:
+
+```ts
+import pricing from "@app/services/pricing/service.js";
+
+// Inside an orders function handler:
+const quote = await pricing.calculateQuote.invoke({ sku, quantity });
+// Apply the order's acceptance rules to the validated quote.
+```
+
+Use the installed declarations for the calculation's actual input/output. Do not import `pricing/functions/*`, call a foreign handler, or expose the same function as a member of two services. A route for orders targets the orders service; separate URLs alone do not establish domain boundaries.
+
+For an asynchronous reaction, orders owns and exposes `orders.created`; a consumer under `src/services/notifications/functions/` uses `defineEventFunction({ id: "notifications.order-created", event: "orders.created", ... })`. Event-only consumers are discovered in their owning domain and are not added to its callable functions map. The event examples below show publication and subscription.
+
+### Invariants and transactions
+
+Name one owner for a command's consistency rules. For example, accepting an order and reserving stock may require one atomic decision. A service call followed by a second write is not proof of an atomic transaction, and `.invoke()` must not be assumed to inherit the caller's transaction or resources.
+
+Inspect installed transaction/invocation behavior before composing provider-backed commands. Choose a supported transaction coordinator or keep tightly coupled invariants within one cohesive owner. Define narrow public operations for other domains; do not duplicate another domain's rules or silently write its owned state from arbitrary helpers. Use events for reactions that can occur after commit, with an outbox when publication must survive a crash. Events alone do not preserve synchronous atomicity.
+
+Keep one shared database service and its ordered migration history when the app uses one database. Do not create a database, auth service, or migration history per business domain.
+
+Changing an existing operation's domain ownership is a redesign, not just a grouped/flat layout move. Review IDs, durable versions, policies, callers, and stored history explicitly; do not promise that a folder move between domains preserves identity.
+
+### Review the resulting boundaries
+
+Compare the actual service graph and routes with the ownership map. Check that each planned capability has real operations under its owner, imports use public service boundaries, business rules live with their owner, and no catch-all service still contains the implementation behind empty facades. Review any merged or split responsibility and verify cross-domain failure/rollback behavior. A passing graph check proves structural validity, not semantic cohesion.
+
 ## `defineFunction` and `defineService`
 
 Put domain behavior in `src/services/<domain>/functions/*.function.ts`. A function validates input before its handler and validates the returned output:
@@ -62,13 +116,13 @@ export default orderCreated;
 
 Expose it through `defineService({ events: { orderCreated } })` when other domains need it. A publisher declares the exact ID in `publishes: ["orders.created"]` and calls `await context.events["orders.created"].publish({ orderId })`.
 
-An event-only consumer reacts without returning a result to its publisher:
+An event-only consumer in `src/services/notifications/functions/` reacts without returning a result to its publisher:
 
 ```ts
 import { defineEventFunction } from "@relkit/app/events";
 
 export default defineEventFunction({
-  id: "orders.confirmation",
+  id: "notifications.order-created",
   event: "orders.created",
   handler: async ({ orderId }, context) => {
     context.log.info("Order created", { orderId });

package/dist/templates/default/v1/tasks/package.json

@@ -13,13 +13,13 @@
     "jobs:trigger": "relkit jobs trigger --job exportOrders --input-file examples/export-orders.json --operation-id example-trigger"
   },
   "dependencies": {
-    "@relkit/app": "0.7.8",
+    "@relkit/app": "0.7.9",
     "effect": "4.0.1"
   },
   "devDependencies": {
     "@types/bun": "1.3.10",
-    "@relkit/cli": "0.7.8",
-    "@relkit/testing": "0.7.8",
+    "@relkit/cli": "0.7.9",
+    "@relkit/testing": "0.7.9",
     "typescript": "5.9.3"
   }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-relkit",
-  "version": "0.7.8",
+  "version": "0.7.9",
   "description": "Create a RELKIT application from a supported project template.",
   "license": "MIT",
   "repository": {
@@ -44,10 +44,10 @@
   },
   "dependencies": {
     "@clack/prompts": "1.7.0",
-    "@relkit/compiler": "0.7.8",
+    "@relkit/compiler": "0.7.9",
     "typescript": "5.9.3",
     "effect": "4.0.1",
-    "@relkit/contracts": "0.7.8"
+    "@relkit/contracts": "0.7.9"
   },
   "devDependencies": {
     "@effect/vitest": "4.0.1",