@assembly-js/app-foundation 0.0.7 → 0.0.8

package/CLAUDE.md

@@ -10,6 +10,10 @@ In user-facing chat, never mention ASSEMBLY_ENV, COPILOT_ENV, or any other inter
 
 **If an SDK auth warning appears mid-build** — for example, a "You must set ASSEMBLY_ENV=local" message from the SDK initializer — treat it as expected transient state. The sandbox resolves it automatically as the build progresses. Do not surface this message in chat and do not ask the user to set any environment variables.
 
+When you describe a feature or a change, describe what the user and their clients will **experience** — who can open the app, what each audience sees or can do. The mechanics that produce it are plumbing too: keep manifest keys (`surfaces`, `app.json`), file names, SDK method names, and identity fields like `clientId`/`internalUserId` out of chat unless the user asks how it works. "Clients will see only their own record" is something they can act on; "add a client surface to the manifest and branch on `identity.clientId`" is not.
+
+When a request implies a scope or permission change, apply it and report the product effect — don't stop to ask the user to approve the mechanics. "When a client views this, show them their own info" already means "make this client-facing," so make the change and say what happened ("clients now see just their own record; your team still sees everyone"). Ask first only on a genuine product choice the user can weigh — who should see the app, what each audience sees — phrased in those terms, never as a manifest or surface decision.
+
 ---
 
 ## Skills

package/dist/client.d.ts

@@ -1,5 +1,6 @@
 export * from './session-exchange.js';
 export * from './network-capture.js';
+export * from './parent-origin.js';
 export * from './client-companies.js';
 export * from './pagination.js';
 export * from './theme.js';

package/dist/client.js

@@ -7,6 +7,9 @@
 // also runs in the Edge middleware runtime that proxy.ts uses.
 export * from './session-exchange.js';
 export * from './network-capture.js';
+// Self-running on client module load (see the module comment): registers the
+// framing origin with the app-bridge allowlist so custom-domain portals work.
+export * from './parent-origin.js';
 export * from './client-companies.js';
 export * from './pagination.js';
 export * from './theme.js';

package/dist/parent-origin.d.ts

@@ -0,0 +1,17 @@
+/**
+ * Resolve the origin of the window framing this app.
+ *
+ * Prefers `location.ancestorOrigins` (browser-attested, immune to referrer
+ * policy; Chromium/WebKit) and falls back to `document.referrer` (Firefox).
+ * Returns null outside an iframe or when neither source is available —
+ * e.g. a restrictive Referrer-Policy on the parent in Firefox.
+ */
+export declare function resolveParentOrigin(): string | null;
+/**
+ * Add the framing origin to the bridge's postMessage allowlist.
+ *
+ * Idempotent (the bridge holds origins in a Set) and restricted to https
+ * parents — local development origins are already on the default allowlist,
+ * so an http parent never needs registering.
+ */
+export declare function registerParentOriginWithBridge(): void;

package/dist/parent-origin.js

@@ -0,0 +1,57 @@
+// Registers the app's real framing origin with the app-bridge postMessage
+// allowlist, so the bridge works on workspaces with custom portal domains.
+//
+// The bridge SDK ships a hardcoded origin allowlist (localhost + assembly
+// domains) and silently drops every outgoing and incoming message when the
+// parent origin isn't on it. On a custom-domain portal that kills header CTAs,
+// session-token refresh, and theme sync. Trusting the framing origin here is
+// sound because the proxy already gates who may frame the app at all: its CSP
+// frame-ancestors directive allows only the static assembly domains plus this
+// workspace's own portal URL, and the browser enforces that before any of this
+// bundle runs. Inside the frame, the browser-reported parent origin is
+// therefore always one the platform trusts.
+import { AssemblyBridge } from '@assembly-js/app-bridge';
+/**
+ * Resolve the origin of the window framing this app.
+ *
+ * Prefers `location.ancestorOrigins` (browser-attested, immune to referrer
+ * policy; Chromium/WebKit) and falls back to `document.referrer` (Firefox).
+ * Returns null outside an iframe or when neither source is available —
+ * e.g. a restrictive Referrer-Policy on the parent in Firefox.
+ */
+export function resolveParentOrigin() {
+    if (typeof window === 'undefined')
+        return null;
+    if (window.parent === window)
+        return null;
+    const ancestor = window.location.ancestorOrigins?.[0];
+    if (ancestor)
+        return ancestor;
+    try {
+        const referrer = document.referrer;
+        if (referrer)
+            return new URL(referrer).origin;
+    }
+    catch {
+        // Unparseable referrer — fall through to null.
+    }
+    return null;
+}
+/**
+ * Add the framing origin to the bridge's postMessage allowlist.
+ *
+ * Idempotent (the bridge holds origins in a Set) and restricted to https
+ * parents — local development origins are already on the default allowlist,
+ * so an http parent never needs registering.
+ */
+export function registerParentOriginWithBridge() {
+    const origin = resolveParentOrigin();
+    if (!origin || !origin.startsWith('https://'))
+        return;
+    AssemblyBridge.configure({ additionalOrigins: [origin] });
+}
+// Run on module load: every app's client bundle imports this package (authFetch,
+// network capture), and module evaluation precedes hydration — so the origin is
+// registered before any component's first header/session-token call. Baked app
+// files never call this module directly, which is exactly why it self-runs.
+registerParentOriginWithBridge();

package/package.json

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