fix(tangle-cloud): Read website from BlueprintWithMetadata (repair develop typecheck)

[drewstone]

Hotfix for develop. #3267 merged at its pre-fix head (e98752c15) — GitHub never synced the follow-up fix commit I pushed — so develop now has a TypeScript error:

BlueprintAppLandingPage.tsx(126,41): error TS2551: Property 'websiteUrl' does not exist on type 'BlueprintWithMetadata'. Did you mean 'website'?

useBlueprint returns BlueprintWithMetadata (field website), not the app-level Blueprint (field websiteUrl). One-line fix: canonicalBlueprint?.websiteUrl → canonicalBlueprint?.website. Restores the tangle-cloud typecheck/build on develop.

🤖 Generated with Claude Code

[tangletools]

✅ Auto-approved PR — a3dd1e52

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-15T02:01:31Z}

[tangletools]

🟡 Value Audit — sound-with-nits

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

💰 Value — sound-with-nits

One-line type repair that reads website (the field on BlueprintWithMetadata returned by useBlueprint) instead of the non-existent websiteUrl, restoring the tangle-cloud build while keeping the new "Visit site" link working.

• What it does: In apps/tangle-cloud/src/blueprintApps/components/BlueprintAppLandingPage.tsx:126 it changes the websiteUrl prop passed to IframeBlueprintLayout from canonicalBlueprint?.websiteUrl to canonicalBlueprint?.website. useBlueprint at libs/tangle-shared-ui/src/data/graphql/useBlueprints.ts:544-602 returns { ...blueprint, ...metadata } as BlueprintWithMetadata, and BlueprintWithMetadata
• Goals it achieves: 1) Unblock develop by fixing the tangle-cloud TypeScript typecheck/build. 2) Correctly wire the blueprint metadata's website value into the iframe layout's "Visit site" link (IframeBlueprintLayout.tsx:174-188).
• Assessment: Good change. It is the minimal, correct fix: the data source has website, the layout prop is websiteUrl, and this maps one to the other exactly where the data is consumed. It follows the existing local convention of using the raw BlueprintWithMetadata object for canonicalBlueprint (also used for blueprintUi and useBlueprintModes in the same component).
• Better / existing approach: none — this is the right approach for a hotfix. I checked the existing mapping in useBlueprints.ts:108-131 (toAppBlueprint) which converts website to websiteUrl when producing AppBlueprint, and useBlueprintMap already exposes AppBlueprint instances. Reusing that here would require either converting canonicalBlueprint to AppBlueprint or switching to useBlueprintMap, both heavier

🎯 Usefulness — sound

Corrects a field-name mismatch so the iframe blueprint landing page reads the publisher website from the GraphQL hook's actual return shape.

• Integration: BlueprintAppLandingPage is rendered by three routes: apps/tangle-cloud/src/pages/blueprints/[id]/page.tsx:90, [publisher]/[slug]/page.tsx:28, and [slug]/[serviceId]/page.tsx:37. The fixed line passes websiteUrl={canonicalBlueprint?.website} to IframeBlueprintLayout (BlueprintAppLandingPage.tsx:126), which conditionally renders a 'Visit site' link at IframeBlueprintLayout.tsx:174. The behavior is l
• Fit with existing patterns: Fits the codebase's data model exactly. useBlueprint returns BlueprintWithMetadata, defined in libs/tangle-shared-ui/src/data/graphql/useBlueprints.ts:95-106 with field website: string | null (line 102). The app-level Blueprint type uses websiteUrl, and toAppBlueprint maps bp.website → websiteUrl (line 124). Using websiteUrl on BlueprintWithMetadata was the mismatch; website is the established fie
• Real-world viability: Holds up. website is string | null and IframeBlueprintLayout only renders the link when truthy (line 174). useBlueprint handles undefined blueprintId, fetch failures, and chain-read fallbacks (useBlueprints.ts:563-606), returning null in failure cases so the prop safely passes through.

💰 Value Audit

🟡 Field-name mismatch between BlueprintWithMetadata.website and Blueprint.websiteUrl invites repeat typos [maintenance] ``

BlueprintWithMetadata exposes website (libs/tangle-shared-ui/src/data/graphql/useBlueprints.ts:102) while the app-level Blueprint type exposes websiteUrl (libs/tangle-shared-ui/src/types/blueprint.ts:91). The previous feature commit (611f0e5) already tripped over this. The immediate fix is correct, but consider a small follow-up to alias or unify the names (or funnel these reads through toAppBlueprint) so the next "Visit site" addition doesn't reintroduce the same TS error.

---

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 · 20260615T020505Z}