@akanjs/cli 0.9.47 → 0.9.49

package/cjs/src/guidelines/modelConstant/modelConstant.instruction.md

@@ -48,21 +48,21 @@ export const StatusEnum = enumOf(["active", "inactive"] as const);
 export type StatusEnum = enumOf<typeof StatusEnum>;
 
 // 3. Input Model
-@Model.Input("DroneInput")
+
 export class DroneInput {
   @Field.Prop(() => String)
   name: string;
 }
 
 // 4. Object Model
-@Model.Object("DroneObject")
+
 export class DroneObject extends BaseModel(DroneInput) {
   @Field.Prop(() => String, { enum: StatusEnum, default: "offline" })
   status: StatusEnum;
 }
 
 // 5. Light Model
-@Model.Light("LightDrone")
+
 export class LightDrone extends Light(DroneObject, ["id", "name", "status"] as const) {
   isConnected() {
     return this.status !== "offline";
@@ -70,7 +70,7 @@ export class LightDrone extends Light(DroneObject, ["id", "name", "status"] as c
 }
 
 // 6. Full Model
-@Model.Full("Drone")
+
 export class Drone extends Full(DroneObject, LightDrone) {
   isAvailable() {
     return this.isConnected() && this.wsUri.startsWith("ws://");
@@ -78,7 +78,7 @@ export class Drone extends Full(DroneObject, LightDrone) {
 }
 
 // 7. Insight Model
-@Model.Insight("DroneInsight")
+
 export class DroneInsight {
   @Field.Prop(() => Int, { default: 0, accumulate: { $sum: 1 } })
   count: number;
@@ -113,7 +113,6 @@ import { LightCategory } from "../category/category.constant";
 The Input model defines fields required for data creation:
 
 ```typescript
-@Model.Input("DroneInput")
 export class DroneInput {
   @Field.Prop(() => String)
   name: string;
@@ -144,7 +143,6 @@ The Object model adds system-managed fields:
 export const droneStatuses = ["active", "offline", "inactive"] as const;
 export type DroneStatus = (typeof droneStatuses)[number];
 
-@Model.Object("DroneObject")
 export class DroneObject extends BaseModel(DroneInput) {
   @Field.Prop(() => String, { enum: droneStatuses, default: "offline" })
   status: DroneStatus;
@@ -172,7 +170,6 @@ const drone = st.use.drone(); // drone.status
 Light model defines lightweight schema for list queries:
 
 ```typescript
-@Model.Light("LightDrone")
 export class LightDrone extends Light(DroneObject, ["name", "status"] as const) {
   isConnected() {
     return this.status !== "offline";
@@ -196,7 +193,6 @@ const droneMap = st.use.droneMap(); // Map<string, LightDrone>
 Full model adds convenience functions:
 
 ```typescript
-@Model.Full("Drone")
 export class Drone extends Full(DroneObject, LightDrone) {
   static isDronesAllConnected(droneList: LightDrone[]) {
     return droneList.every((drone) => drone.isConnected());
@@ -226,7 +222,6 @@ const isAllConnected = cnst.Drone.isDroneAllConnected(droneList);
 Insight model defines statistical fields:
 
 ```typescript
-@Model.Insight("DroneInsight")
 export class DroneInsight {
   @Field.Prop(() => Int, { default: 0, accumulate: { $sum: 1 } })
   count: number;
@@ -371,13 +366,11 @@ graph LR
 ### 1. Scalar Embedded Style
 
 ```typescript
-@Model.Scalar("DronePhysicalState")
 export class DronePhysicalState {
   @Field.Prop(() => [Float], { default: [0, 0, 0] })
   rpy: [number, number, number];
 }
 
-@Model.Object("DroneObject")
 export class DroneObject {
   @Field.Prop(() => DronePhysicalState)
   physicalState: DronePhysicalState;
@@ -387,7 +380,6 @@ export class DroneObject {
 ### 2. Reference ID Style
 
 ```typescript
-@Model.Input("MissionInput")
 export class MissionInput {
   @Field.Prop(() => ID, { ref: "drone" })
   drone: string;
@@ -397,7 +389,6 @@ export class MissionInput {
 ### 3. Resolved Reference Style
 
 ```typescript
-@Model.Object("DroneObject")
 export class DroneObject {
   @Field.Prop(() => LightMission, { nullable: true })
   mission: LightMission | null;
@@ -417,6 +408,7 @@ import { LightMission } from "../cnst_";
 ## Best Practices for Maintainable Models
 
 1. **Consistent Naming**:
+
    - Input: `DroneInput`
    - Object: `DroneObject`
    - Light: `LightDrone`
@@ -424,16 +416,19 @@ import { LightMission } from "../cnst_";
    - Sort: `droneSort`
 
 2. **Reference Handling**:
+
    - Use Light models for references
    - Avoid circular dependencies
    - Prefer direct imports over barrel files
 
 3. **Field Design**:
+
    - Use proper field types (Prop, Hidden, Secret, Resolve)
    - Set appropriate defaults (especially for arrays)
    - Add validation where needed
 
 4. **Performance Optimization**:
+
    - Use Light models for list queries
    - Keep Insight/Summary models lean
    - Use appropriate indexes for queries
@@ -450,21 +445,21 @@ import { ID, Int, String } from "@akanjs/base";
 import { Field, Model } from "@akanjs/constant";
 
 // Input Model
-@Model.Input("DroneInput")
+
 export class DroneInput {
   @Field.Prop(() => String)
   name: string;
 }
 
 // Object Model
-@Model.Object("DroneObject")
+
 export class DroneObject extends BaseModel(DroneInput) {
   @Field.Prop(() => String, { enum: ["active", "offline"], default: "offline" })
   status: string;
 }
 
 // Light Model
-@Model.Light("LightDrone")
+
 export class LightDrone extends Light(DroneObject, ["id", "name", "status"] as const) {
   isConnected() {
     return this.status === "active";
@@ -472,7 +467,7 @@ export class LightDrone extends Light(DroneObject, ["id", "name", "status"] as c
 }
 
 // Full Model
-@Model.Full("Drone")
+
 export class Drone extends Full(DroneObject, LightDrone) {
   isAvailable() {
     return this.isConnected() && this.battery > 20;
@@ -480,7 +475,7 @@ export class Drone extends Full(DroneObject, LightDrone) {
 }
 
 // Insight Model
-@Model.Insight("DroneInsight")
+
 export class DroneInsight {
   @Field.Prop(() => Int, { accumulate: { $sum: 1 } })
   count: number;

package/cjs/src/guidelines/modelDocument/modelDocument.instruction.md

@@ -16,21 +16,11 @@
 
 A `model.document.ts` file is structured into four distinct classes, each with a specific responsibility:
 
-### 1. Input Class
-
-Defines the data structure for create/update operations:
-
-```typescript
-@Database.Input(() => cnst.ExampleInput)
-export class ExampleInput extends by(cnst.ExampleInput) {}
-```
-
 ### 2. Document Class
 
 Represents a MongoDB document with instance methods:
 
 ```typescript
-@Database.Document(() => cnst.Example)
 export class Example extends by(cnst.Example) {
   // Document methods here
 }
@@ -41,7 +31,6 @@ export class Example extends by(cnst.Example) {
 Represents the MongoDB collection with static methods:
 
 ```typescript
-@Database.Model(() => cnst.Example)
 export class ExampleModel extends into(Example, cnst.exampleCnst) {
   // Model statics here
 }
@@ -52,7 +41,6 @@ export class ExampleModel extends into(Example, cnst.exampleCnst) {
 Defines schema hooks and indexes:
 
 ```typescript
-@Database.Middleware(() => cnst.Example)
 export class ExampleMiddleware extends beyond(ExampleModel, Example) {
   onSchema(schema) {
     // Middleware and indexes here
@@ -74,7 +62,6 @@ Document methods operate on individual document instances and typically follow t
 ### Example of Document Methods:
 
 ```typescript
-@Database.Document(() => cnst.User)
 export class User extends by(cnst.User) {
   // Simple transformation method (synchronous)
   addRole(role: string) {
@@ -113,7 +100,6 @@ Model statics operate on the entire collection and are typically asynchronous. T
 ### Example of Model Statics:
 
 ```typescript
-@Database.Model(() => cnst.Order)
 export class OrderModel extends into(Order, cnst.orderCnst) {
   // Query by specific criteria
   async findPendingOrders(userId: string) {
@@ -206,7 +192,6 @@ Middleware allows you to intercept and modify document operations at various lif
 ### Example Middleware Implementation:
 
 ```typescript
-@Database.Middleware(() => cnst.User)
 export class UserMiddleware extends beyond(UserModel, User) {
   onSchema(schema: SchemaOf<UserModel, User>) {
     // Pre-save hook for password hashing
@@ -258,7 +243,6 @@ Indexes are crucial for query performance. Define them in the Middleware's `onSc
 ### Example Index Implementation:
 
 ```typescript
-@Database.Middleware(() => cnst.Product)
 export class ProductMiddleware extends beyond(ProductModel, Product) {
   onSchema(schema: SchemaOf<ProductModel, Product>) {
     // Single field index (1=ascending, -1=descending)
@@ -346,7 +330,6 @@ DataLoader batches and caches database requests to optimize performance, especia
 ### Example DataLoader Implementation:
 
 ```typescript
-@Database.Model(() => cnst.Order)
 export class OrderModel extends into(Order, cnst.orderCnst) {
   // Load orders by user ID
   @Loader.ByField("userId")
@@ -461,7 +444,6 @@ const resultCount = await productModel.searchCountProduct("wireless headphones")
 Use transactions for operations that need to be atomic:
 
 ```typescript
-@Database.Model(() => cnst.Order)
 export class OrderModel extends into(Order, cnst.orderCnst) {
   @Transaction()
   async createOrderWithItems(orderData, items) {
@@ -497,10 +479,6 @@ import { dayjs } from "@akanjs/base";
 import { beyond, by, Database, into, Loader, SchemaOf } from "@akanjs/document";
 import * as cnst from "../cnst";
 
-@Database.Input(() => cnst.ProductInput)
-export class ProductInput extends by(cnst.ProductInput) {}
-
-@Database.Document(() => cnst.Product)
 export class Product extends by(cnst.Product) {
   applyDiscount(percentage: number) {
     if (percentage < 0 || percentage > 100) {
@@ -529,7 +507,6 @@ export class Product extends by(cnst.Product) {
   }
 }
 
-@Database.Model(() => cnst.Product)
 export class ProductModel extends into(Product, cnst.productCnst) {
   @Loader.ByField("category")
   categoryProductsLoader: Loader<string, Product[]>;
@@ -579,7 +556,6 @@ export class ProductModel extends into(Product, cnst.productCnst) {
   }
 }
 
-@Database.Middleware(() => cnst.Product)
 export class ProductMiddleware extends beyond(ProductModel, Product) {
   onSchema(schema: SchemaOf<ProductModel, Product>) {
     // Update stock status on save

package/cjs/src/guidelines/modelService/modelService.generate.json

@@ -24,13 +24,6 @@
       "path": "libs/shared/lib/user/user.service.ts",
       "sample": 1
     },
-    {
-      "type": "example",
-      "description": "@Service decorator examples",
-      "path": "{apps,libs}/*/lib/*/*.service.ts",
-      "filterText": "@Service",
-      "sample": 2
-    },
     {
       "type": "example",
       "description": "@Use decorator examples",
@@ -89,9 +82,9 @@
     },
     {
       "type": "example",
-      "description": "LogService examples",
+      "description": "serve examples",
       "path": "{apps,libs}/*/lib/*/*.service.ts",
-      "filterText": "LogService",
+      "filterText": "serve",
       "sample": 1
     },
     {
@@ -113,8 +106,8 @@
     "filePath": "./modelService.instruction.md",
     "contents": [
       "Purpose and role of model.service.ts files",
-      "Service structure and inheritance (DbService, LogService, MixSrvs)",
-      "Core decorators (@Service, @Srv, @Use, @Db, @Sig)",
+      "Service structure and inheritance (DbService, serve, MixSrvs)",
+      "Core decorators (@Srv, @Use, @Db, @Sig)",
       "Database operations (CRUD, queries, search)",
       "Customizing database operations (_preCreate, _postCreate, _preUpdate, _postUpdate, _preRemove, _postRemove)",
       "Working with other services (dependency injection patterns)",

package/cjs/src/guidelines/modelService/modelService.instruction.md

@@ -23,7 +23,6 @@ Akan.js services typically extend base service classes provided by the framework
 Most services extend `DbService` to work with MongoDB models:
 
 ```typescript
-@Service("ProductService")
 export class ProductService extends DbService(db.productDb) {
   // Service methods here
 }
@@ -31,13 +30,12 @@ export class ProductService extends DbService(db.productDb) {
 
 The `DbService` function automatically injects the database model and provides numerous convenience methods for CRUD operations.
 
-### LogService
+### serve
 
 For utility services that don't directly work with a database model:
 
 ```typescript
-@Service("SecurityService")
-export class SecurityService extends LogService("SecurityService") {
+export class SecurityService extends serve("security" as const) {
   // Utility methods here
 }
 ```
@@ -51,7 +49,7 @@ For specific domain services with shared functionality:
 export const LibService = MixSrvs(SharedService, PlatformService, SocialService);
 
 // In another service
-@Service("CustomService")
+
 export class CustomService extends LibService {
   // Custom methods here
 }
@@ -59,20 +57,6 @@ export class CustomService extends LibService {
 
 ## Core Decorators
 
-### @Service Decorator
-
-Declares a class as an injectable NestJS service with additional configuration options:
-
-```typescript
-@Service("UserService", {
-  enabled: true, // Enable/disable service dynamically
-  serverMode: "federation", // "federation", "batch", or not specified
-})
-export class UserService extends DbService(db.userDb) {
-  // Service implementation
-}
-```
-
 Options:
 
 - `enabled`: Boolean flag to conditionally disable a service (default: true)
@@ -263,7 +247,6 @@ async _postRemove(doc: Product): Promise<Product> {
 Services often work together to implement complex operations:
 
 ```typescript
-@Service("OrderService")
 export class OrderService extends DbService(db.orderDb) {
   @Srv() productService: ProductService;
   @Srv() userService: UserService;
@@ -322,7 +305,6 @@ export class OrderService extends DbService(db.orderDb) {
 For real-time features:
 
 ```typescript
-@Service("ChatService")
 export class ChatService extends DbService(db.chatDb) {
   @Websocket()
   websocket: Websocket<ChatSignal>;
@@ -354,8 +336,7 @@ export class ChatService extends DbService(db.chatDb) {
 For background processing:
 
 ```typescript
-@Service("EmailService")
-export class EmailService extends LogService("EmailService") {
+export class EmailService extends serve("email" as const) {
   @Queue()
   emailQueue: Queue<EmailSignal>;
   @Use()
@@ -441,7 +422,7 @@ Services should not maintain internal state between requests:
 
 ```typescript
 // BAD - maintains state in the service
-@Service("CounterService")
+
 class CounterService {
   private count = 0; // This state is lost on server restart
 
@@ -454,7 +435,7 @@ class CounterService {
 }
 
 // GOOD - uses database for state
-@Service("CounterService")
+
 class CounterService extends DbService(db.counterDb) {
   async increment(counterId: string) {
     const counter = await this.getCounter(counterId);
@@ -474,7 +455,7 @@ Each service should focus on a specific domain:
 
 ```typescript
 // BAD - mixing concerns
-@Service("UserService")
+
 class UserService extends DbService(db.userDb) {
   async createUser(data) {
     // User creation logic
@@ -490,7 +471,7 @@ class UserService extends DbService(db.userDb) {
 }
 
 // GOOD - separate services
-@Service("UserService")
+
 class UserService extends DbService(db.userDb) {
   @Srv() emailService: EmailService;
   @Srv() paymentService: PaymentService;
@@ -500,14 +481,12 @@ class UserService extends DbService(db.userDb) {
   }
 }
 
-@Service("EmailService")
-class EmailService extends LogService("EmailService") {
+class EmailService extends serve("email" as const) {
   async sendEmail(userId, subject, content) {
     // Email sending logic
   }
 }
 
-@Service("PaymentService")
 class PaymentService extends DbService(db.paymentDb) {
   async processPayment(userId, amount) {
     // Payment processing logic
@@ -546,13 +525,12 @@ Inject other services using decorators, not direct imports:
 // BAD - direct import
 import { UserService } from "../user/user.service";
 
-@Service("OrderService")
 class OrderService extends DbService(db.orderDb) {
   private userService = new UserService(); // Hard-coded dependency
 }
 
 // GOOD - dependency injection
-@Service("OrderService")
+
 class OrderService extends DbService(db.orderDb) {
   @Srv() userService: UserService; // Injected dependency
 }
@@ -563,7 +541,6 @@ class OrderService extends DbService(db.orderDb) {
 Use the built-in logger for consistent logging:
 
 ```typescript
-@Service("PaymentService")
 class PaymentService extends DbService(db.paymentDb) {
   async processPayment(orderId: string, amount: number) {
     this.logger.log(`Processing payment of ${amount} for order ${orderId}`);
@@ -581,20 +558,6 @@ class PaymentService extends DbService(db.paymentDb) {
 }
 ```
 
-## Integration with NestJS
-
-Akan.js services are built on top of NestJS's dependency injection system. The `@Service` decorator builds on top of NestJS's `@Injectable()`:
-
-```typescript
-// Behind the scenes, @Service does this:
-@Injectable()
-export class UserService {
-  // ...
-}
-```
-
-This allows Akan.js services to be used within NestJS modules, controllers, and resolvers.
-
 ## Complete Example
 
 Here's a complete example of a service implementation:
@@ -602,7 +565,7 @@ Here's a complete example of a service implementation:
 ```typescript
 import { Dayjs } from "@akanjs/base";
 import { Cron } from "@akanjs/nest";
-import { DbService, Service, Srv, Use } from "@akanjs/service";
+import { DbService, Srv, Use } from "@akanjs/service";
 import type { EmailApi } from "@util/nest";
 
 import * as cnst from "../cnst";
@@ -610,7 +573,6 @@ import * as db from "../db";
 import { Revert } from "../dict";
 import type * as srv from "../srv";
 
-@Service("OrderService")
 export class OrderService extends DbService(db.orderDb) {
   @Srv() userService: srv.UserService;
   @Srv() productService: srv.ProductService;
@@ -704,31 +666,6 @@ export class OrderService extends DbService(db.orderDb) {
 
 ## Troubleshooting
 
-### Service Not Being Injected
-
-If a service isn't being injected correctly:
-
-1. Ensure the service name matches:
-
-   ```typescript
-   @Service("UserService")  // This name must match
-   export class UserService extends DbService(db.userDb) {}
-
-   @Srv("UserService")  // Or this must match if using explicit name
-   userService: UserService;
-   ```
-
-2. Check if the service is enabled in the current environment:
-
-   ```typescript
-   @Service("UserService", { enabled: process.env.ENABLE_USER_SERVICE === 'true' })
-   ```
-
-3. Verify server mode restrictions:
-   ```typescript
-   @Service("CleanupService", { serverMode: "batch" })  // Only runs in batch mode
-   ```
-
 ### Database Operations Failing
 
 1. Check model definition and schema:
@@ -763,7 +700,7 @@ Model services in Akan.js are powerful components that encapsulate business logi
 Key takeaways:
 
 - Services should be stateless, with persistent state managed in the database
-- Use the appropriate decorator (@Service, @Srv, @Use, etc.) for dependency injection
+- Use the appropriate decorator (@Srv, @Use, etc.) for dependency injection
 - Implement lifecycle hooks for proper resource management
 - Use scheduled tasks for recurring operations
 - Follow single responsibility principle

package/cjs/src/guidelines/modelSignal/modelSignal.generate.json

@@ -176,7 +176,6 @@
     "contents": [
       "Purpose and role of model.signal.ts files",
       "Signal class structure and core components",
-      "@Signal decorator and Signal class definition",
       "DbSignal and other higher-order functions",
       "Endpoint decorators (@Query, @Mutation, @Message, @Process, @Pubsub)",
       "Parameter decorators (@Arg.Query, @Arg.Param, @Arg.Body, @Self, etc.)",

package/cjs/src/guidelines/modelSignal/modelSignal.instruction.md

@@ -26,7 +26,6 @@ import { Arg, DbSignal, Mutation, Query, resolve, Self, Signal } from "@akanjs/s
 import * as cnst from "../cnst";
 import type * as db from "../db";
 
-@Signal(() => cnst.ModelName)
 export class ModelNameSignal extends DbSignal(cnst.modelNameCnst, cnst.Srvs, {
   guards: { get: Query.Public, cru: Mutation.User },
 }) {
@@ -36,36 +35,7 @@ export class ModelNameSignal extends DbSignal(cnst.modelNameCnst, cnst.Srvs, {
 
 Key components:
 
-- `@Signal()` decorator defines this class as a signal provider
-- `DbSignal()` higher-order function provides standard CRUD operations
-- `guards` option configures default access control for CRUD operations
-- Service references are injected from `Srvs` imported from cnst.ts
-
-## Decorator Reference
-
-### 1. @Query Decorator
-
-Used for read-only operations with access control levels:
-
-```typescript
-@Query.Public(() => [cnst.Product])  // Public access, returns array of Products
-async productListInFeatured(
-  @Arg.Query("skip", () => Int, { nullable: true }) skip: number | null,
-  @Arg.Query("limit", () => Int, { nullable: true }) limit: number | null,
-  @Arg.Query("sort", () => String, { nullable: true }) sort: SortOf<cnst.ProductFilter> | null
-) {
-  const products = await this.productService.listFeatured({ skip, limit, sort });
-  return resolve<cnst.Product[]>(products);  // Type-safe resolution
-}
-```
-
-Access control levels:
-
-- `Query.Public` - Available to unauthenticated users
-- `Query.User` - Requires user authentication
-- `Query.Admin` - Requires admin access
-- `Query.SuperAdmin` - Requires super admin access
-- `Query.Every` - Available to all authenticated users (any role)
+- `
 
 ### 2. @Mutation Decorator
 
@@ -169,7 +139,7 @@ The slice pattern standardizes data access with consistent naming and pagination
 async chatRoomListInSelf(  // listIn<SliceName> pattern
   @Arg.Query("skip", () => Int, { nullable: true }) skip: number | null,
   @Arg.Query("limit", () => Int, { nullable: true }) limit: number | null,
-  @Arg.Query("sort", () => String, { nullable: true }) sort: SortOf<cnst.ChatRoomFilter> | null,
+  @Arg.Query("sort", () => String, { nullable: true }) sort: SortOf<db.ChatRoomFilter> | null,
   @Self() self: Self
 ) {
   const chatRooms = await this.chatRoomService.listInUser(self.id, { skip, limit, sort });
@@ -288,7 +258,6 @@ function ChatRoom({ roomId }) {
 DbSignal creates standard operations that you don't need to implement:
 
 ```typescript
-@Signal(() => cnst.Board)
 export class BoardSignal extends DbSignal(cnst.boardCnst, cnst.Srvs, {
   guards: { get: Query.Public, cru: Mutation.Admin },
 }) {
@@ -408,7 +377,6 @@ async getProjectDetails(
 ### Basic CRUD Signal with DbSignal
 
 ```typescript
-@Signal(() => cnst.Product)
 export class ProductSignal extends DbSignal(cnst.productCnst, cnst.Srvs, {
   guards: { get: Query.Public, cru: Mutation.Admin },
 }) {
@@ -436,7 +404,6 @@ export class ProductSignal extends DbSignal(cnst.productCnst, cnst.Srvs, {
 ### Real-Time Chat Signal
 
 ```typescript
-@Signal(() => cnst.Chat)
 export class ChatSignal {
   @Mutation.User(() => cnst.Chat)
   async sendChat(
@@ -464,7 +431,6 @@ export class ChatSignal {
 ### Background Processing Signal
 
 ```typescript
-@Signal(() => cnst.Report)
 export class ReportSignal {
   @Mutation.Admin(() => cnst.Report)
   async generateReport(
@@ -543,7 +509,6 @@ export function SelfSlice<T>(returnType: () => T) {
 ### Signal Integration with External APIs
 
 ```typescript
-@Signal(() => cnst.ExternalData)
 export class ExternalApiSignal {
   @Query.Public(() => cnst.WeatherData)
   async getWeatherData(@Arg.Query("location", () => String) location: string) {
@@ -564,7 +529,6 @@ export class ExternalApiSignal {
 Signals can implement caching for performance:
 
 ```typescript
-@Signal(() => cnst.Product)
 export class ProductSignal extends DbSignal(cnst.productCnst, Srvs) {
   @Query.Public(() => cnst.Product)
   async getProduct(@Arg.Param("productId", () => ID) productId: string) {

package/cjs/src/guidelines/modelStore/modelStore.instruction.md

@@ -37,7 +37,6 @@ import { stateOf, Store } from "@akanjs/store";
 import * as cnst from "../cnst";
 import { fetch } from "../sig";
 
-@Store(() => cnst.Product)
 export class ProductStore extends stateOf(fetch.productGql, {
   // Custom state properties
   featuredProducts: [] as cnst.LightProduct[],
@@ -359,7 +358,7 @@ For complex applications, compose multiple stores:
 // In store.ts
 export class RootStore extends MixStore(ProductStore, CategoryStore, VendorStore, CartStore) {}
 
-export const store = rootStoreOf(RootStore);
+export const storeRoot = rootStoreOf(RootStore);
 ```
 
 ### Cross-Store Operations
@@ -489,7 +488,6 @@ import * as cnst from "../cnst";
 import { fetch } from "../sig";
 import { msg } from "../msg";
 
-@Store(() => cnst.Product)
 export class ProductStore extends stateOf(fetch.productGql, {
   // UI State
   productViewMode: "grid" as "grid" | "list",