@assembly-js/app-foundation 0.0.34 → 0.0.35

package/CLAUDE.md

@@ -160,7 +160,9 @@ Before adding a feature, check whether Assembly already covers it. If it does, *
 **Then ask who should perform it — you or the platform.** Reaching a module through the SDK is right when the user is doing the thing *now*: they pressed a button and are watching it happen. When the effect should instead happen *in reaction to* something that happens in the app ("when a project is completed, message the client"), that is a workflow that integrates with the Assembly platform, and **the platform performs it, not your code.** The test is where the effect lands: on Assembly's own data rather than only in your app's tables. Decide this **before** you write or plan the call — read the `assembly-automations` skill to decide it, and don't reach for the module's SDK method until you have.
 <!-- /feature:api-resources -->
 
-**Built-in modules (core, available in every portal):**
+**Always available (every workspace):** Clients, companies, and custom fields — see "The data model" below. Use them; do not rebuild them. Notification infrastructure (`listNotifications`, `createNotification`, `deleteNotification`, `markNotificationRead`, `markNotificationUnread`) is also always available.
+
+**Optional modules (may or may not be installed in this workspace):** Messages, Files, Contracts, Forms, Billing, Knowledge Base, Tasks, and Notes. Before suggesting one or calling its SDK, confirm it is installed — call `listAppInstalls`. If it is installed, use it through the SDK; do not rebuild it. If it is not installed, do not suggest it, do not plan the app around it, and do not ask the user to install it.
 
 | Module | What it does | Reach via SDK |
 |---|---|---|
@@ -172,10 +174,9 @@ Before adding a feature, check whether Assembly already covers it. If it does, *
 | Billing | Invoices, subscriptions, payments | `createInvoice`, `listInvoices`, `retrieveInvoice`, `listInvoiceTemplates`, `createSubscription`, `listSubscriptions`, `retrieveSubscription`, `cancelSubscription`, `listSubscriptionTemplates`, `listProducts`, `retrieveProduct`, `listPrices`, `retrievePrice`, `listPayments` |
 | Knowledge Base | Help articles / docs | (no SDK methods today; render-only) |
 | Tasks | Assign tasks to clients/team | `retrieveTasks`, `createTask`, `retrieveTask`, `updateTask`, `deleteTask`, `listTaskTemplates`, `retrieveTaskTemplate` |
-| Notifications | In-app notification feed | `listNotifications`, `createNotification`, `deleteNotification`, `markNotificationRead`, `markNotificationUnread` |
 | Notes | Per-client/company internal notes | `createNote`, `listNotes`, `retrieveNote`, `updateNote`, `deleteNote` |
 
-If the user's prompt says "build a CRM," the answer is mostly **wire up the existing Clients + Companies + Notes + Tasks modules in a custom view** — not invent your own.
+If the user's prompt says "build a CRM," the answer is mostly **wire up the existing Clients + Companies** (and any optional modules that are actually installed) **in a custom view** — not invent your own.
 
 ---
 
@@ -332,7 +333,7 @@ Pair it with a server-component or page-level guard so the user sees a friendly
 
 A Postgres database is provisioned for this app. `DATABASE_URL` is already in your shell environment.
 
-Use it for any persistent data that Assembly's built-in modules don't cover (custom records, time entries, app-specific state, etc.). **Check the built-in modules table first** — prefer Assembly SDK data over custom tables when a module already covers the need.
+Use it for any persistent data that Assembly's modules don't cover (custom records, time entries, app-specific state, etc.). **Check the modules section above first** — prefer Assembly SDK data over custom tables when an installed module already covers the need.
 
 **`drizzle-orm`, `@neondatabase/serverless`, and `drizzle-kit` are pre-installed. `lib/db.ts`, `lib/schema.ts`, and `drizzle.config.ts` are already in the repo.** Do NOT run `bun add` for these packages or recreate those files.
 
@@ -1155,7 +1156,7 @@ Use `AssemblyBridge.header.*` for breadcrumbs, CTAs, and actions menu. See `.cla
 - ❌ Don't decode the session token client-side. It's encrypted; only the SDK on the server can read it.
 - ❌ Don't use `URLSearchParams` on `window.location` to read the token in App Router server components — use the typed `searchParams` prop.
 - ❌ Don't make Assembly API calls from client components without a server-side proxy. The apiKey can't leave the server.
-- ❌ Don't reinvent built-in Assembly features (Messages, Files, Forms, Tasks, Billing) — call the SDK methods listed above.
+- ❌ Don't reinvent Clients, Companies, or custom fields — they are always available via the SDK. For Messages, Files, Forms, Tasks, Billing, Contracts, Notes, or Knowledge Base: confirm the module is installed (`listAppInstalls`) first; if it is, call the SDK methods listed above rather than rebuilding it. If it is not installed, do not suggest it or plan around it.
 - ❌ Don't use `assembly.clients.list()` — the SDK is flat. Use `assembly.listClients(...)`.
 - ❌ Don't cache decoded payloads for >30s — token rotates every 5 min and the user could be different on the next call (rare, but possible if a session is shared across tabs).
 <!-- !feature:app-owned-header -->
@@ -1215,5 +1216,5 @@ Use `AssemblyBridge.header.*` for breadcrumbs, CTAs, and actions menu. See `.cla
 <!-- !feature:app-owned-header -->
 6. **Use `AssemblyBridge.header.*`** for breadcrumbs/CTAs in client components. Don't render your own. (Exception: the notification surface `/n` has no header — render CTAs as inline buttons there.)
 <!-- /feature:app-owned-header -->
-7. **Don't reinvent Messages/Files/Forms/Tasks/Billing.** Wire them up via SDK.
+7. **Don't reinvent Clients/Companies/custom fields.** For Messages/Files/Forms/Tasks/Billing and similar optional modules, confirm they are installed (`listAppInstalls`) before wiring them via SDK — and skip them if they aren't.
 8. **Keep infrastructure plumbing out of chat.** Don't volunteer ASSEMBLY_ENV, COPILOT_ENV, token encryption, API key internals, or internal file names unprompted. Mid-build SDK auth warnings are expected — never surface them to the user. (Answering a user's direct technical question is fine.)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@assembly-js/app-foundation",
-  "version": "0.0.34",
+  "version": "0.0.35",
   "description": "Versioned foundation helpers and build context for Assembly generated apps",
   "type": "module",
   "files": [