@assembly-js/app-foundation 0.0.50 → 0.0.52

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 check scripts those `[action]`
 bullets ship. Write `[fix]`, `[behavior]` and `[action]` bullets for the app's owner.
 
+## 0.0.52
+- [guidance] The build agent is told that the CRM tab loads the app's client route as staff, with the client or company of that page in the token, so it renders a staff view scoped to that record instead of the client view or an error. It is also told to send notifications for submissions, status changes, approvals and required alerts even when the request does not mention notifications.
+
+## 0.0.51
+- [guidance] The build agent is told that its preview is `localhost:3000` and that the public sandbox host is unreachable from inside the sandbox.
+
 ## 0.0.50
 - [guidance] The build agent is no longer told to reinstall packages that come pre-installed, offered a toast library the platform bans, or shown a secret type the manifest rejects, and its header guidance no longer contradicts itself when the app owns its header. It is also told why the dashboard and client surfaces take separate routes and to detect the viewer with `getSessionIdentity()`.
 

package/CLAUDE.md

@@ -31,10 +31,10 @@ Assembly-specific gotchas live in `.claude/skills/<name>/SKILL.md`. Invoke them
 - `assembly-native-resources` — native message channels, forms, portal files/file channels: never hardcode their IDs, discover them at runtime
 - `assembly-mutations` — minimal `requestBody` rule for `update*` calls
 <!-- !feature:notification-settings -->
-- `assembly-notifications` — in-product + email notifications via createNotification; `ctaParams` for notification CTA URLs (the `/n` surface renders from those, not the best-effort `notificationId` claim)
+- `assembly-notifications` — in-product + email notifications via createNotification; `ctaParams` for notification CTA URLs (the `/n` surface renders from those, not the best-effort `notificationId` claim) Send them unprompted when the app has submissions, status changes, approvals, or alerts someone must act on, even if the request never says "notify".
 <!-- /feature:notification-settings -->
 <!-- feature:notification-settings -->
-- `assembly-notifications` — in-product + email notifications via createNotification; `ctaParams` for notification CTA URLs (the `/n` surface renders from those, not the best-effort `notificationId` claim); per-user toggleable categories via manifest `notificationSettings` + `notificationSettingId`
+- `assembly-notifications` — in-product + email notifications via createNotification; `ctaParams` for notification CTA URLs (the `/n` surface renders from those, not the best-effort `notificationId` claim); per-user toggleable categories via manifest `notificationSettings` + `notificationSettingId` Send them unprompted when the app has submissions, status changes, approvals, or alerts someone must act on, even if the request never says "notify".
 <!-- /feature:notification-settings -->
 - `clearing-client-notifications` — REQUIRED when the app sends client notifications: clear the portal sidebar badge with markNotificationRead (clear-on-view vs clear-on-action)
 <!-- feature:api-resources -->
@@ -64,6 +64,7 @@ Assembly-specific gotchas live in `.claude/skills/<name>/SKILL.md`. Invoke them
 - `assembly-route-errors` — REQUIRED in every route handler: use `handleRouteError` from `@assembly-js/app-foundation/server` in catch blocks — never return `err.message`. Validate values before they hit typed DB columns (e.g. `parseUuid` before a uuid-column lookup).
 - `assembly-action-results` — REQUIRED when a server action refuses work the UI should explain (validation, permission, not ready to send): return `{ ok: false, message }` instead of throwing. A thrown message is redacted in production.
 - `assembly-dev-server-logs` — the dev server's stdout/stderr (server-side errors, stack traces, console output) is readable at `/tmp/dev-server.log`; check it before guessing at a 500 or broken preview.
+- Your own preview is `localhost:3000`; never fetch the public `sb-*.vercel.run` host from inside the sandbox (egress to it is blocked).
 
 ---
 
@@ -137,6 +138,8 @@ The token tells you which type the current viewer is:
 
 The app should **detect the viewer type from the token** and render audience-appropriate UI. Don't show "Create new" buttons to clients if creation is staff-only.
 
+**The CRM tab runs your client route as staff.** It loads the same `clientUrl` as the Client Portal, but its token carries the staff member's `internalUserId` plus the record the tab sits on: `clientId` (with its `companyId`) on a client's page, `companyId` alone on a company's page. So every page under the client surface has three viewers: a client, staff on a client's tab, and staff on a company's tab. Check `internalUserId` first. When it is set, render the staff view of that client or company, with the actions staff take there (review, upload, manage), never the client-only view and never a "portal users only" error. On a company's tab, show that company's records only, not the whole workspace.
+
 **The CRM tab is never the only path to per-client data.** The CRM tab is a shortcut: it renders with a specific `clientId`/`companyId` already in the token. But any client/company-specific data or action it exposes must *also* be reachable from the Dashboard main view — even if it takes a few clicks. Build the main view so an internal user can browse to a specific client/company (a list, or a `UserCompanySelector` that drills into a per-entity detail screen) and reach the same data and actions there. The main-view detail screen doesn't have to match the CRM-tab layout — it can reuse the same components or present them differently — but the main view must never be empty or aggregate-only when the CRM tab has per-client functionality. Don't leave `internalUrl` as a dead end.
 
 <!-- !feature:app-owned-header -->

package/package.json

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

package/skills/assembly-notifications/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: assembly-notifications
 # <!-- !feature:notification-settings -->
-description: Use when the app must notify internal users or clients about something that happened — in-product, email, or both. Covers createNotification, the Notification Center /n surface, and clearing the client badge (see clearing-client-notifications).
+description: Use when the app must notify internal users or clients about something that happened — in-product, email, or both — including unprompted, whenever it has submissions, status changes, approvals, or required alerts. Covers createNotification, the Notification Center /n surface, and clearing the client badge (see clearing-client-notifications).
 # <!-- /feature:notification-settings -->
 # <!-- feature:notification-settings -->
-description: Use when the app must notify internal users or clients, or needs per-user notification preferences (Product/Email toggles). Covers createNotification, the /n surface, notificationSettings + notificationSettingId, and clearing the client badge (see clearing-client-notifications).
+description: Use when the app must notify internal users or clients (including unprompted, whenever it has submissions, status changes, approvals, or required alerts), or needs per-user notification preferences (Product/Email toggles). Covers createNotification, the /n surface, notificationSettings + notificationSettingId, and clearing the client badge (see clearing-client-notifications).
 # <!-- /feature:notification-settings -->
 ---