@usesalama/ntx-apps-grocery

The shared grocery-subscription domain (see docs/TRD.md §5): Household, Address, Product, BasketTemplate, BasketTemplateLine, Subscription, SubscriptionLine, Cycle, CycleLineItem, Payment. Owned here rather than in admin or buyer because almost every entity is read/written by both apps (and by whatsapp) — this is the single source of truth regardless of which channel touches it.

Payment is grocery-owned, not a wrapper around ntx-apps-capital — capital's ProviderService implements a save-a-card-and-charge-later flow for its own recurring Plan billing, not the hosted-checkout-link flow a WhatsApp message needs. api/payment/providers/paystack calls Paystack's real Initialize/Verify Transaction endpoints directly (Flutterwave not built yet). PaymentController.checkout/.verify are the manual (M0/M1, pre-WhatsApp-automation) triggers; verify is the only code path that can move a Cycle confirmed → paid.

Basket sourcing: a household's actual basket always lives in SubscriptionLine, never read directly off BasketTemplateLine. Three ways to arrive at it: predefined (subscribe to a BasketTemplate, its lines get copied in on create), fully custom (no basketTemplateId, add lines directly), or a customized predefined basket (start from a template, then edit/add/remove lines same as custom). generateCycle only ever reads SubscriptionLine.

admin, buyer, and whatsapp depend on this lib for entities/repositories and expose their own API surface (permissions, routes) over the same data.

Structured to match origine/scaffold's existing apps (e.g. design): src/api/{resource}/{entities,dto,*.service,*.controller,*.module,index}.ts per resource, src/migrations/ with one file per table, src/app.config.ts for shared enums.

Route, Delivery, Referral, ConversationSession, MessageLog, and ComplaintLog/SwapLog are not built yet (M1/M2 scope, PRD's post-pilot phases).

Mounted at apps/grocery by cloud/server.