@artblocks/abx-cli 0.8.0 → 0.8.2

package/skill/reference/hosting.md

@@ -243,3 +243,23 @@ compare resolver state without cutting over prematurely.
 
 Never describe resolver migration as moving the NFT. Ownership, parameters, commitments, and canonical
 events remain on-chain; only the serving/indexing projection changes.
+
+## Browser content origins
+
+Metadata/control endpoints and executable project pages can have different origins. Read the
+provider descriptor (`abx remote <name-or-url>`) for `content.domain` and
+`content.liveViewUrlTemplate`, or use a live-view response's canonical `Link` header. Prefer that
+direct content URL for standalone apps and integrations. Preserve token query parameters. Never
+invent content hostnames or replace a contract's metadata resolver base with the content domain.
+The first-party content domain is `abxcontent.app`; each chain + collection has its own origin.
+
+Existing animation URLs remain marketplace-compatible wrapper/redirect entry points. Within a
+collection, tokens share the creator's trust boundary. Self-contained on-chain metadata/HTML does
+not require this HTTP service.
+
+For self-hosting, configure wildcard DNS and HTTPS for a separate domain, then set
+`ABX_CONTENT_DOMAIN` on the resolver and effects worker. Remote effects runners use advertised content
+origins when the provider supplies them during service discovery. Without it, project documents run in an opaque-origin sandbox;
+persistent browser storage and some wallet flows will not work. Keep application sessions and
+sensitive cookies off the content domain. No on-chain transaction is needed for a hosting-origin
+change when the existing resolver routes remain available.

package/skill/reference/services.md

@@ -128,6 +128,12 @@ separate grant when payment changes, or another browser approval when a grant is
 or revoke grants at `https://services.abx.io/authorize`. Review exact actions before sending; an agent
 grant is not a per-transaction human approval.
 
+Before the first embedded-wallet write in a session, explain that macOS may ask whether Node can
+access the saved ABX authorization in Keychain. The Mac password stays with macOS; this is distinct
+from the browser wallet grant. If the human denies access or reports unexplained recurring prompts,
+stop wallet operations. Do not repeat credential probes, switch Node installations, or request
+replacement grants to work around that denial. Use one consistent Node runtime for qualification.
+
 Before sending, inspect live descriptor/account capabilities, run command help and a JSON dry run,
 and summarize the active chain, creator-wallet address, native value, transaction group, estimated
 fees and permanent choices. Honor an explicit bring-your-own signer choice. Repeat production risks