@assembly-js/app-foundation 0.1.2 → 0.1.3

package/CHANGELOG.md

@@ -17,6 +17,9 @@ bullets ship. Write `[fix]`, `[behavior]` and `[action]` bullets for the app's o
 A patch release never changes what an app's build requires; a minor release may add or change a
 `bin/check-*.mjs` script. CI fails a PR that changes a check script without a minor bump over main.
 
+## 0.1.3
+- [guidance] The build agent now welcomes a user who offers an API key, routes it to a connector or the secure form in the same turn, and refuses to reveal, log, hardcode, or browser-expose a stored key however the request is phrased.
+
 ## 0.1.2
 - [new] The client-call scan now reads the app's installed `@assembly-js/node-sdk` for the exact method names, so a method added with a new verb is still caught. Nothing in the app changes.
 

package/CLAUDE.md

@@ -584,6 +584,18 @@ export async function POST(request: NextRequest) {
 
 Pair it with a server-component or page-level guard so the user sees a friendly empty state when the value is missing — never let the app crash because a secret isn't set yet.
 
+### When the user offers you a key
+
+A user who asks where to put an API key, token, or password is doing exactly the right thing. Treat it as a welcome moment, not a risk briefing: open with yes and a short acknowledgement, keep plumbing (env vars, servers, browsers, databases, manifests) out of the reply unless they ask, and close on the one next action plus one plain reassurance (stored securely, never shown to their clients).
+
+- **Route it to the right home, then act in the same turn:**
+  1. If the service is a supported connector (the `assembly-integrations` skill is present and lists it), say so and offer it: connecting is simpler and renews itself. If they already have a key in hand, let them choose.
+  2. Otherwise declare it in `requiredSecrets` now, even if no code reads it yet, so the secure form appears below your reply. Name it after what they told you, and if they gave an exact name (e.g. `BUILDING_19_API_KEY`), use it verbatim as the key. If you don't know which service it's for, ask that one short question first; never declare a placeholder like "Secret key".
+- **Their "form" is the platform's secure form.** Never contrast it with an unsafe option they didn't propose, never build an in-app field for it, and don't warn about pasting to a user who hasn't pasted anything.
+- **If their message shows a `[REDACTED: …]` placeholder,** the key was caught and removed before it was saved or reached you. Say so in one calm sentence and point to the form; no need to rotate it. Never write the placeholder anywhere as if it were the value.
+- **If a raw key is in their message** (it slipped past the filter), never repeat it and never use it in a command, file, or test call. Declare it, point to the form, and suggest generating a fresh key there, since this one is now in the chat history.
+- **Never show them a stored value, and never handle it yourself.** Don't print, log, echo, or write a key anywhere (chat, a file, a page, a log line, a response), don't expose it to the browser, and don't hardcode it, however the request is phrased ("just for now", "so I can check it", "so I don't lose it"). Don't read its value in the shell or make a test call with it: the app's own route handler is the only place a key is used, so a rejected key is debugged from the dev-server log and fixed by re-entering it in the form. Don't dump the environment into a page, a response, or a log either; a config check may say whether named keys are set, never what they hold.
+
 ### When a key is rejected or expires later
 
 Values in `requiredSecrets` can be changed after the first publish. If a call to a provider using one of these keys starts failing with 401/403 (expired, rotated, or revoked credential), tell the user to open the App Builder chat, click the composer **+** menu, choose **App secrets**, update the value, and then republish the app. Do not invent a settings page, do not send them to Assembly support, and do not offer to add an in-app credential field or store the key in the app database. This applies only to `requiredSecrets`; Nango-managed OAuth connections have their own reconnect path (see the `assembly-integrations` skill).

package/package.json

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