@assembly-js/app-foundation 0.4.0 → 0.4.2

package/CHANGELOG.md

@@ -19,6 +19,12 @@ A patch release never changes what an app's build requires; a minor release may
 not by hand; see `changes/README.md`. CI fails a PR that changes a check script without a
 `bump: minor` change file.
 
+## 0.4.2
+- [guidance] The build agent's main guide now says a client contact's cross-app calls use `viewerClient`, while team members and background work keep `installerClient`.
+
+## 0.4.1
+- [guidance] Build agents append to `requiredSecrets` instead of rewriting it, and remove an entry only when the user asks to disconnect that integration.
+
 ## 0.4.0
 - [fix] The renewal response is never cached.
 - [fix] Analytics identify the viewer again in migrated apps.

package/CLAUDE.md

@@ -52,7 +52,7 @@ Assembly-specific gotchas live in `.claude/skills/<name>/SKILL.md`. Invoke them
 - `assembly-app-inner-location` — mount `<LocationReporter />` so the host mirrors the app's inner page in its address bar; deep-link a notification or link to a specific record with `linkTo({ to: 'app', installId, path })`, never to the app root. Never hand-write location reporting.
 <!-- /feature:deep-link-app-inner-location -->
 <!-- feature:cross-app-apis -->
-- `assembly-app-clients` — calling another workspace app through its generated client in `generated/apps/<appId>/` (`installerClient`, by verb and path), and rendering an empty state that names the app when the call is refused instead of a 500.
+- `assembly-app-clients` — calling another workspace app through its generated client in `generated/apps/<appId>/` (`viewerClient` for a client contact, `installerClient` for team members and background work, by verb and path), and rendering an empty state that names the app when the call is refused instead of a 500.
 <!-- /feature:cross-app-apis -->
 - `assembly-ai` — AI features, including speech-to-text, via Assembly's OpenAI proxy (no API keys needed)
 - `assembly-storage` — app-private file uploads/downloads (NOT the portal Files module). The storage helpers come from `@assembly-js/app-foundation/server` — import them, don't rewrite them. POST only `{ fileName }` (a bare name) and store the key the platform returns; never build the S3 key yourself.
@@ -462,7 +462,7 @@ Relationships:
 If the user names another app, read its file in `.assembly/docs/apps/` and follow the call recipe at the top of that file. If that folder is absent, the app is not callable (it may still need the Security update). Cross-app calls from pages, server actions and routes use `getInstallerAssembly()`; cron and webhooks use `getOfflineAssembly()`. Never return another app's response to a client unfiltered — scope any client data you forward. While a person is using the app, those calls use the installer client, because the platform does not yet prove which person the call is for. Once it can, use the viewer client for that person's data and keep the installer client for staff-wide reads.
 <!-- /feature:api-resources -->
 <!-- feature:cross-app-apis -->
-When `generated/apps/<appId>/` exists for that app, call it through the generated client instead (see the `assembly-app-clients` skill); the docs recipe is the fallback for an app with no folder there.
+When `generated/apps/<appId>/` exists for that app, call it through the generated client instead (see the `assembly-app-clients` skill); the docs recipe is the fallback for an app with no folder there. The generated client supersedes the installer-client note above: a client contact's own calls use `viewerClient`, which the platform scopes to that contact; team members and background work use `installerClient`.
 <!-- /feature:cross-app-apis -->
 
 ---
@@ -533,7 +533,7 @@ Two paths, decided by whether an `assembly-integrations` skill is present and, i
 ### Two rules
 
 1. **Read the credential only from `process.env.<KEY>`, server-side only.** Route handlers, server components, and server actions can read it. Client components, `'use client'` modules, and anything that ends up in the browser bundle cannot. Never hardcode a value, never persist one to the database, never read from the URL, never write `.env*` files.
-2. **Declare every secret you read in `.assembly/app.json`.** Add an entry under a top-level `requiredSecrets` array in the same change that introduces the call. The Assembly platform reads this manifest after the build, prompts the user for each value, and injects them as Vercel env vars at deploy.
+2. **Declare every secret you read in `.assembly/app.json`.** Add an entry under the existing top-level `requiredSecrets` array in the same change that introduces the call. Append to the array; never replace it with a shorter list. The setup form keeps saved values and asks only for keys that have none, so removing an entry to simplify it gains nothing and drops a credential the deployed app is using. Remove an entry only when the user asked to disconnect that integration, and say which key you removed. The Assembly platform reads this manifest after the build, prompts the user for each value not saved yet, and injects declared secrets as Vercel env vars at deploy.
 
 ### Adding a secret to an app that already calls the provider
 

package/package.json

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