[RELEASE] Promote develop → master: tangle-cloud revamp + Surplus iframe

[drewstone]

Production release: promote develop → master (deploys to cloud.tangle.tools). 6 commits, all reviewed/merged on develop:

• #3259 restore Tangle dapp design system
• #3265 add blueprint apps + local staking gates
• #3266 register Surplus as an iframe blueprint + cross-origin allow-same-origin wallet support
• #3267 "Visit site" link for every blueprint from website metadata
• #3268 hotfix: read website from BlueprintWithMetadata
• lint: keep react-compiler diagnostics advisory

develop is green post-hotfix. The curated iframe path needs no env flag, so Surplus embeds in prod without config changes.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for tangle-dapp canceled.

Name	Link
🔨 Latest commit	c7e7490
🔍 Latest deploy log	https://app.netlify.com/projects/tangle-dapp/deploys/6a2fdf2acef90d0008760ac4

[netlify]

✅ Deploy Preview for tangle-leaderboard canceled.

Name	Link
🔨 Latest commit	c7e7490
🔍 Latest deploy log	https://app.netlify.com/projects/tangle-leaderboard/deploys/6a2fdf2a574308000893bf50

[tangletools]

✅ Auto-approved PR — 1159b7c4

Blanket team auto-approval is enabled for this reviewer service.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: blanket_auto_approve · 2026-06-15T10:54:26Z}

[netlify]

✅ Deploy Preview for tangle-cloud canceled.

Name	Link
🔨 Latest commit	c7e7490
🔍 Latest deploy log	https://app.netlify.com/projects/tangle-cloud/deploys/6a2fdf2a7bff130008b9c5a4

[tangletools]

🟡 Value Audit — sound-with-nits

Verdict	sound-with-nits
Concerns	5 (5 weak-concern)
Heuristic	0.0s
Duplication	0.0s
Interrogation	365.8s (2 bridge agents)
Total	365.8s

💰 Value — sound-with-nits

Promotes the tangle-cloud revamp and local staking gates to master: it adds a curated, identity-matched blueprint registry, a hardened iframe bridge/postMessage protocol for embedded first-party apps (including Surplus with allow-same-origin), restores the Tangle dapp design system inside tangle-clo

• What it does: The promotion bundles six reviewed commits. Concretely: (1) Tangle Cloud gets a curated blueprint registry (apps/tangle-cloud/src/blueprintApps/registry.ts) that matches first-party apps by publisher namespace + requested slug, with entries for Trading, Sandbox, Training, Surplus and LLM Inference. (2) It adds a hardened iframe runtime: a versioned postMessage protocol (iframe/protocol.ts), st
• Goals it achieves: The change makes Tangle Cloud capable of hosting first-party blueprint apps as secure, policy-governed iframes instead of maintaining bespoke per-blueprint React modules, which lets new partner/product surfaces (Surplus, LLM Inference, etc.) ship without dapp releases. It improves UX consistency by restoring the Tangle design system inside tangle-cloud and gives operators clear identity, trust lab
• Assessment: The change is good on its merits. The architecture is coherent: it reuses the upstream @tangle-network/blueprint-ui primitives and resolvers (resolver.ts re-exports and extends them), layers a security-first iframe protocol on top of standard postMessage/wagmi/viem, and keeps curated first-party entries separate from the metadata-driven parser while both feed the same landing-page/layout sur
• Better / existing approach: No material architecture change is needed. The main improvement available is to stop duplicating the native-token metadata fallback: the same zeroAddress native-token handling already lives in libs/tangle-shared-ui/src/hooks/useEvmAssetMetadatas.ts (lines 87–95) and libs/tangle-shared-ui/src/data/staking/useOnChainStakingAssets.ts (line 16), yet the local staking pages redefine `NATIVE_TOKEN

🎯 Usefulness — sound-with-nits

Surplus is a coherent, reachable extension of the curated iframe path; the allow-same-origin escape hatch and registry wiring fit the codebase, with only minor ops-documentation and curated-route gaps.

• Integration: Surplus is wired as a curated-module entry in apps/tangle-cloud/src/blueprintApps/registry.ts:242-321, matched by publisherNamespace 'tangle' + requestedSlug 'surplus'. It is reachable from the canonical slug route apps/tangle-cloud/src/pages/blueprints/[publisher]/[slug]/page.tsx:18 via getBlueprintAppByCanonicalSlug, and rendered through BlueprintAppLandingPage apps/tangle-cloud/src/blueprintApp
• Fit with existing patterns: The change extends the existing curated registry + iframe bridge model rather than competing with it. The allowSameOrigin flag is typed as curated-only in apps/tangle-cloud/src/blueprintApps/iframe/types.ts:35-41 and is not parsed from untrusted on-chain metadata (apps/tangle-cloud/src/blueprintApps/iframe/manifest.ts:89-135 never reads it). This keeps the stricter opaque-origin default for metada
• Real-world viability: The iframe bridge is hardened for realistic use: strict origin equality (apps/tangle-cloud/src/blueprintApps/iframe/origin.ts:33) and source equality (origin.ts:37) prevent confused-deputy attacks; payloads are bounded (correlationId length in protocol.ts:202-206, calldata in protocol.ts:212, typed-data in protocol.ts:325-331). Surplus itself is configured defensively with allowReadAccount:false,

🎯 Usefulness Audit

🟡 Iframe kill switch documented as universal but only covers metadata-driven manifests [robustness] ``

apps/tangle-cloud/src/blueprintApps/iframe/README.md:44 and README.md:164 describe VITE_BLUEPRINT_IFRAME_ENABLED as a kill switch that disables 'every iframe-mode manifest,' but the flag is only consulted in apps/tangle-cloud/src/blueprintApps/manifest.ts:220-226 for metadata-driven parsing. Curated registry entries such as Surplus (registry.ts:242-321) render regardless of the flag. This is intentional per the PR body ('curated iframe path needs no env flag'), but the README wording sets an ops

🟡 'Visit site' link is unreachable on curated canonical-slug routes [integration] ``

IframeBlueprintLayout.tsx:174-188 renders the 'Visit site' link only when websiteUrl is provided. BlueprintAppLandingPage.tsx:126 passes canonicalBlueprint?.website, but canonicalBlueprint comes from useBlueprint which is enabled only when view.blueprintId !== undefined (BlueprintAppLandingPage.tsx:59-62). Curated registry entries reached via /blueprints/:publisher/:slug do not fetch the indexed blueprint, so view.blueprintId is absent and the link never appears on those pages even when the on-c

💰 Value Audit

🟡 Native token metadata fallback is repeated across local staking pages [duplication] ``

The local staking changes hardcode NATIVE_TOKEN_ADDRESS = zeroAddress and NATIVE_ASSET_METADATA = { name: 'Ether', symbol: 'ETH', decimals: 18 } in at least four places: apps/tangle-dapp/src/pages/staking/delegate/index.tsx:83-88, apps/tangle-dapp/src/pages/staking/withdraw/index.tsx:67-72, apps/tangle-dapp/src/data/rewards/usePendingRewards.ts and apps/tangle-dapp/src/data/rewards/useDelegatorPositions.ts. The same native-token fallback logic already exists in `libs/tangle-shared-ui

🟡 formatMoney overlaps with the existing formatBn utility [duplication] ``

apps/tangle-cloud/src/styles/chrome.ts:307-393 introduces formatMoney, which performs lossless integer division and compact formatting for EVM bigints. libs/ui-components/src/utils/formatBn.ts:172-252 already does lossless decimal formatting for Substrate BN values in the same repo. The two operate on different numeric types, but the rounding, trailing-zero and display concerns are nearly identical. Consider extracting a shared integer-formatting primitive (e.g. `formatBigIntWithDecimals

🟡 CopyableId reinvents a copy affordance already in ui-components [duplication] ``

apps/tangle-cloud/src/components/chrome/CopyableId.tsx implements click-to-copy for identifiers with middle-truncation. libs/ui-components/src/components/CopyWithTooltip/CopyWithTooltip.tsx and libs/ui-components/src/hooks/useCopyable.ts already provide a similar copy affordance. CopyableId is intentionally more compact and ID-specific, so this is a minor nit, but a shared "copy with truncation" primitive in ui-components could avoid the duplication as the chrome system matures.

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260615T110217Z}

[tangletools]

✅ Auto-approved PR — c7e7490a

Blanket team auto-approval is enabled for this reviewer service.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: blanket_auto_approve · 2026-06-15T11:17:02Z}

[tangletools]

🔴 Value Audit — redundant-or-flawed

Verdict	redundant-or-flawed
Concerns	3 (2 strong-concern, 1 weak-concern)
Heuristic	0.0s
Duplication	0.0s
Interrogation	337.7s (2 bridge agents)
Total	337.7s

💰 Value — redundant-or-flawed

Realigns tangle-cloud with the Tangle dApp design system and replaces the custom blueprint catalog with the shared BlueprintGallery, but the new Header drops the top-nav slot that IframeBlueprintLayout depends on, breaking the chrome for iframe blueprints including Surplus.

• What it does: Header.tsx (apps/tangle-cloud/src/components/Header.tsx:34-59) removes the fixed topbar, breadcrumb trail, theme toggle, and the TopNavSlot left-slot rendering, becoming a right-aligned action bar. Layout.tsx (apps/tangle-cloud/src/components/Layout.tsx:40, 116) removes theme-change plumbing and renders without props. BlueprintListing.tsx (apps/tangle-cloud/src/pages/blueprints/Blueprin
• Goals it achieves: Adopt the Tangle dApp's simpler, non-topbar chrome (matching apps/tangle-dapp/src/containers/Layout.tsx:36-52 and TopNavigationPanel.tsx). Consolidate blueprint listing UI by reusing the shared BlueprintGallery already used by tangle-dapp (apps/tangle-dapp/src/pages/blueprints/BlueprintListing.tsx:1-40). Reduce custom local code and maintenance surface in tangle-cloud.
• Assessment: The design-system alignment and BlueprintGallery reuse are coherent and worthwhile. However, the Header change creates a functional regression: IframeBlueprintLayout still publishes its blueprint identity + Create-instance/Details/Visit-site strip via useTopNavSlot (apps/tangle-cloud/src/blueprintApps/components/IframeBlueprintLayout.tsx:217), and Layout.tsx still wraps the app in TopNavSlotProvid
• Better / existing approach: Either (A) restore a left content slot in the new Header/Layout header row that renders the TopNavSlot content so IframeBlueprintLayout keeps working, or (B) update IframeBlueprintLayout to render its strip in-page (below the Layout header row) instead of publishing to a now-removed global topbar. Option B better matches the new tangle-dapp-style Layout where pages own their own chrome. I checked

🎯 Usefulness — redundant-or-flawed

The Surplus iframe registration and website-link wiring are coherent, but the Header simplification removes the top-nav slot that IframeBlueprintLayout depends on, leaving iframe blueprint pages without their primary chrome actions.

• Integration: The change is mostly wired in: Layout renders the simplified Header (Layout.tsx:116); BlueprintListing consumes the shared BlueprintGallery from tangle-shared-ui (BlueprintListing.tsx:220); the Surplus curated entry is registered with mode: 'iframe' and allowSameOrigin: true (registry.ts:242-321); and websiteUrl flows from BlueprintWithMetadata.website through BlueprintAppLandingPage int
• Fit with existing patterns: Replacing the local catalog with BlueprintGallery fits the established pattern: tangle-dapp already uses the same shared component (apps/tangle-dapp/src/pages/blueprints/BlueprintListing.tsx). The Surplus iframe entry mirrors the existing trading/sandbox/llm-inference entries and reuses the same BlueprintAppFrameHost/BlueprintAppFrame pipeline. The problem is that the Header change conflicts
• Real-world viability: Under realistic use, a user navigating to /blueprints/surplus will see the Surplus iframe but will have no visible way to create a service instance, switch deployment modes, expand the iframe, visit the blueprint's own site, or open the Details panel. The only escape hatch is focus mode, triggered by a button that is itself inside the orphaned nav slot. The security gating for Surplus is sound —

💰 Value Audit

🔴 Header redesign breaks IframeBlueprintLayout's top-nav slot [against-grain] ``

Header.tsx removed the useTopNavSlotContent hook and the left slot that rendered it (old Header.tsx:45-58), while Layout.tsx:87 still wraps the app in TopNavSlotProvider and IframeBlueprintLayout.tsx:217 still publishes its blueprint identity + Create-instance/Details/Visit-site strip via useTopNavSlot(navContent). The published content now has no renderer, so iframe blueprint pages lose their primary chrome. This directly affects the Surplus iframe blueprint (registry.ts:242-313) that the PR ti

🎯 Usefulness Audit

🔴 Header simplification orphans IframeBlueprintLayout's top-nav chrome [integration] ``

Header.tsx (c7e7490) removed useTopNavSlotContent() and the left slot that rendered blueprint identity, mode picker, Create-instance CTA, expand, Visit site, and Details button. IframeBlueprintLayout.tsx:217 still calls useTopNavSlot(navContent) and its comment at line 113 still refers to the 'Header left slot'. TopNavSlot.tsx:17-18 documents that 'pages call useTopNavSlot(node) to publish, the Header renders useTopNavSlotContent()' — but no caller of useTopNavSlotContent remains. The fix

🟡 TopNavSlotContent consumer is dead code [ergonomics] ``

useTopNavSlotContent is exported but has no callers after the Header change (Grep shows only its definition in TopNavSlot.tsx:41). If the slot pattern is intentionally retired, the provider, context, and useTopNavSlotContent export should be removed so future developers do not assume the slot still works.

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260615T112422Z}