@assembly-js/app-foundation 0.0.43 → 0.0.45

package/CHANGELOG.md

@@ -14,6 +14,12 @@ A foundation update reads the sections between an app's version and the target:
 from every bullet except `[guidance]`, agent work from the `fixes.json` entries those `[action]`
 bullets name. Write `[fix]`, `[behavior]` and `[action]` bullets for the app's owner.
 
+## 0.0.45
+- [guidance] The generated SDK method tables no longer list the session and token methods the foundation calls itself, and the module notes name each module's SDK groups.
+
+## 0.0.43
+- [guidance] The build agent's SDK method tables are now generated from the SDK instead of hand-written.
+
 ## 0.0.42
 - [action: package-proxy] Sign-in and cross-site request protection now come from the package instead of code the app owns, and are checked by sending real requests through the app.
 

package/CLAUDE.md

@@ -1,6 +1,6 @@
 # Assembly App Guide
 
-You are an expert frontend engineer building a custom app that runs **inside an Assembly portal as an iframe**. You create beautiful, performant, mobile-first applications that follow UI/UX and shadcn best practices and provide clear user feedback. **Design mobile-first: every component and layout must start from a single-column, narrow-viewport base (down to 320px) and scale up using `sm:`, `md:`, and `lg:` breakpoints.** This applies to grids, padding, typography, tabs, and any horizontal arrangement. If a task description gives you non-responsive CSS, adapt it to be mobile-first yourself. Read this whole file before writing any code — it contains the platform model, the data model, the SDK surface, and the iframe constraints. The information here is more current than your training data. **The SDK method tables below are generated from the SDK's type definitions; read `node_modules/@assembly-js/node-sdk/dist/codegen/api/services/<Resource>Service.d.ts` only for nested parameter shapes.**
+You are an expert frontend engineer building a custom app that runs **inside an Assembly portal as an iframe**. You create beautiful, performant, mobile-first applications that follow UI/UX and shadcn best practices and provide clear user feedback. **Design mobile-first: every component and layout must start from a single-column, narrow-viewport base (down to 320px) and scale up using `sm:`, `md:`, and `lg:` breakpoints.** This applies to grids, padding, typography, tabs, and any horizontal arrangement. If a task description gives you non-responsive CSS, adapt it to be mobile-first yourself. Read this whole file before writing any code — it contains the platform model, the data model, the SDK surface, and the iframe constraints. The information here is more current than your training data. **The SDK method tables below are generated from the SDK's type definitions.**
 
 ## Communication rules
 
@@ -164,14 +164,14 @@ Before adding a feature, check whether Assembly already covers it. If it does, *
 
 **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.
 
-- **Messages** — Direct messaging between staff and clients.
-- **Files** — Secure file/folder sharing. *For app-private uploads (attachments, exports) use the storage helpers from `@assembly-js/app-foundation/server` (see the `assembly-storage` skill) instead — Files is only for files the user wants in the portal Files tab.*
-- **Contracts** — eSignature contracts.
-- **Forms** — Intake forms / surveys (6 question types).
-- **Billing** — Invoices, subscriptions, payments.
-- **Knowledge Base** — Help articles / docs.
-- **Tasks** — Assign tasks to clients/team.
-- **Notes** — Per-client/company internal notes.
+- **Messages** — Direct messaging between staff and clients. SDK groups: Messages, MessageChannels.
+- **Files** — Secure file/folder sharing. *For app-private uploads (attachments, exports) use the storage helpers from `@assembly-js/app-foundation/server` (see the `assembly-storage` skill) instead — Files is only for files the user wants in the portal Files tab.* SDK groups: Files, FileChannels.
+- **Contracts** — eSignature contracts. SDK groups: Contracts, ContractTemplates.
+- **Forms** — Intake forms / surveys (6 question types). SDK groups: Forms, FormResponses.
+- **Billing** — Invoices, subscriptions, payments. SDK groups: Invoices, InvoiceTemplates, Subscriptions, SubscriptionTemplates, Products, Prices, Payments, Refunds.
+- **Knowledge Base** — Help articles / docs (no SDK methods; render-only).
+- **Tasks** — Assign tasks to clients/team. SDK groups: Tasks, TaskTemplates, Comments (task comments).
+- **Notes** — Per-client/company internal notes. SDK groups: Notes.
 
 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.
 
@@ -189,7 +189,7 @@ If the user's prompt says "build a CRM," the answer is mostly **wire up the exis
 **SDK methods** (every service, not only the resources above):
 
 <!-- generated: sdk-methods -->
-Generated from the SDK's service classes. Methods are called flat (`assembly.listClients(...)`); every method takes a single object of the named parameters (`?` = optional), and a service with no methods listed is not callable. Read the `.d.ts` only for nested parameter shapes. Named return types that could not be resolved to a `{ data, nextToken }` list envelope are shown by name and need a `.d.ts` lookup.
+Generated from the SDK's service classes. Methods are called flat (`assembly.listClients(...)`); every method takes a single object of the named parameters (`?` = optional). Read the `.d.ts` only for nested parameter shapes. Named return types that could not be resolved to a `{ data, nextToken }` list envelope are shown by name and need a `.d.ts` lookup.
 
 **Clients**
 
@@ -395,12 +395,6 @@ Generated from the SDK's service classes. Methods are called flat (`assembly.lis
 | `listRefunds` | `invoiceId`, `limit?`, `nextToken?` | `{ data?: Array<refund_Refund>, nextToken }` |
 | `createRefund` | `requestBody` | `refund_Refund` |
 
-**Session**
-
-| Method | Parameters | Returns |
-|---|---|---|
-| `sessionExchange` | `requestBody` | `session_ExchangeResponse` |
-
 **SubscriptionTemplates**
 
 | Method | Parameters | Returns |
@@ -433,12 +427,6 @@ Generated from the SDK's service classes. Methods are called flat (`assembly.lis
 | `retrieveTask` | `id` | `marketplace_application_Task` |
 | `updateTask` | `id`, `requestBody` | `marketplace_application_Task` |
 
-**Token**
-
-| Method | Parameters | Returns |
-|---|---|---|
-| `offlineTokenIssue` | — | `offline_IssueResponse` |
-
 **Workspaces**
 
 | Method | Parameters | Returns |
@@ -1214,8 +1202,8 @@ Method naming convention from the OpenAPI codegen:
 
 Every method, its parameter names, and its return shape are in the generated tables under "The data model"; they come from the codegen types in `node_modules/@assembly-js/node-sdk/dist/codegen/api/`, so don't guess a method that isn't listed. Read the `.d.ts` only for nested parameter shapes. Two files, two jobs:
 
-- **`index.d.ts` — the map.** Re-exports all 31 services and every model type, and gives the exact service filename. The names are not always the obvious singular/plural: the names are not always the obvious singular/plural (`FormResponsesService`, `TaskTemplatesService`, `SubscriptionTemplatesService`, `MeService`).
-- **`services/<Resource>Service.d.ts` — the nested shapes.** Parameter object fields and model types live here; the tables above already give names and return shape.
+- **`index.d.ts` — the map.** Re-exports all 31 services and every model type, and gives the exact service filename. The names are not always the obvious singular/plural (`FormResponsesService`, `TaskTemplatesService`, `SubscriptionTemplatesService`, `MeService`).
+- **`services/<Resource>Service.d.ts` — the parameter fields.** Parameter object fields and model types live here; the tables above already give names and return shape.
 
 The client flattens every service onto one object, so a method declared in `TasksService.d.ts` is still called as `assembly.retrieveTasks(...)`.
 
@@ -1487,10 +1475,10 @@ Use `AssemblyBridge.header.*` for breadcrumbs, CTAs, and actions menu. See `.cla
 
 ## TL;DR
 
-1. **Read this whole file before writing any code.** Especially the data model, "What's already built in," and the SDK method index.
+1. **Read this whole file before writing any code.** Especially the data model, "What's already built in," and the generated method tables.
 2. **The middleware exchanges `?token=` (first load) for a user-scoped bearer in an HttpOnly cookie; that bearer authenticates every call.** You never handle the token.
 3. **Call `getAssembly()` — no token argument, ever.** `getAssembly()` (RSC/server actions) and `getAssemblyForRequest(req)` (route handlers) read the bearer cookie. Identity via `getSessionIdentity()` / `useAssembly()`. Never read `searchParams.token`, thread a token, or set `x-assembly-token`.
-4. **The SDK is flat: `assembly.listClients(...)`, not `assembly.clients.list()`.** The generated method tables list every method; `services/<Resource>Service.d.ts` has the nested parameter shapes.
+4. **The SDK is flat: `assembly.listClients(...)`, not `assembly.clients.list()`.** The generated method tables list every method;
 5. **The bearer expires in 60 min; `useServerAction`/`authFetch` re-exchange it silently and retry.** You don't refresh anything or touch `AssemblyBridge.sessionToken`.
 <!-- !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.)

package/package.json

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