chore: use @tangle-network/brand from npm

[AtelyPham]

Summary

• Replace "file:../brand" with "^0.2.0" in package.json (also upgrades from stale 0.1.0 → 0.2.0)
• Remove the git clone brand sibling step from all 4 CI workflows (deploy, check-links, check-copy, check-models)

Test plan

• CI workflows pass without the brand clone step
• pnpm install --frozen-lockfile resolves @tangle-network/brand from registry

[tangletools]

❌ Needs Work — 88a35ac0

Readiness 72/100 · Confidence 92/100 · 7 findings (2 high, 1 medium, 4 low)

	kimi	glm	aggregate
Readiness	72	88	72
Confidence	92	95	92
Correctness	76	92	76
Security	95	98	95
Testing	55	75	55
Architecture	87	90	87

Core change — moving @tangle-network/brand from file:../brand to npm ^0.2.0 — is clean and correct; all CI workflows properly drop the git-clone-sibling step. Three real issues prevent merge: operators.astro now claims 'LIVE PAYOUTS' with fabricated dollar figures (code comment admits they're illustrative, but nothing in the rendered UI says so); deploy.yml swapped the pnpm/action-setup and setup-node order in a way that breaks cache per official docs; and four blog posts were deleted with no redirect config, burning any inbound SEO/backlinks. | Read all 26 changed files. The core change is mi

Blocking

🔴 HIGH deploy.yml: pnpm/action-setup runs after actions/setup-node cache:pnpm — cache is a no-op — .github/workflows/deploy.yml

Lines 16-21: the new order is setup-node (with cache: pnpm) first, then pnpm/action-setup. Per the official pnpm/action-setup v4 docs and the actions/setup-node docs: 'When using the cache option in setup-node, pnpm/action-setup must be run before setup-node.' With pnpm not installed at cache-resolution time, setup-node cannot locate the pnpm store path and the cache step silently becomes a no-op. Builds succeed but every run does a full cold install (~60–90s penalty). Fix: move pnpm/action-setup back before setup-node, matching the pre-PR order.

🔴 HIGH operators.astro presents fabricated numbers as live on-chain data — src/pages/operators.astro

Lines ~73-125: the section label was changed from 'OPERATOR LEDGER · PREVIEW' (with an explicit disclaimer: 'Numbers below are illustrative') to 'LIVE PAYOUTS' with a pulsing dot. The stats block now reads '$2,847 last hour', '412 payouts/min', '$68,328 last 24h', '147 operators serving'. The code comment at line ~73 acknowledges 'Numbers below are illustrative — the ledger surface that wires this to live x402 settlements is on the protocol roadmap'. There is no visible disclaimer to visitors. Presenting fabricated throughput and payout figures under a 'LIVE' label is deceptive and creates legal/regulatory exposure. Fix: either revert to 'PREVIEW' labeling with explicit illustrative text, or add a visible disclaimer alongside the numbers.

Other

🟠 MEDIUM deploy.yml: --branch=production removed — CF Pages may route to preview environment — .github/workflows/deploy.yml

Line 35: the wrangler-action command changed from 'pages deploy dist/client --project-name=tangle-website --branch=production' to 'pages deploy dist/client --project-name=tangle-website'. Without --branch=production, Cloudflare Pages uses the git branch name ('main') to determine production vs. preview. This is safe only if the CF Pages project is already configured with 'main' as the production branch. If it was previously relying on the explicit 'production' alias (a common CF Pages pattern), deployments will land in the preview environment and production will not be updated. Verify CF Pages project settings before merging.

🟡 LOW Cloudflare deploy lost explicit --branch=production flag — .github/workflows/deploy.yml

Line 35: pages deploy dist/client --project-name=tangle-website removed the --branch=production flag that was present in the old deploy at line 38. With the trigger now push: branches: [main], wrangler uses the current git branch (main) as the deployment branch. This works if Cloudflare Pages is configured to serve main as production, but the old explicit --branch=production was a safety net against misconfiguration. Verify the Cloudflare Pages project's production branch setting matches before merging.

🟡 LOW check-links.mjs drops blueprint-agent skip — local pnpm check:links will fail on private-repo URL — scripts/check-links.mjs

Lines 37-47 removed: the skip for '^https?://github.com/tangle-network/blueprint-agent' was deleted. The code comment that was there said 'Private repo — anonymous fetch returns 404 by design.' The blog post src/content/blog/subscription-vs-pay-per-request-api-pricing.mdx line 146 links to that repo. Running 'pnpm check:links' locally will now report a broken link. Note: lychee.toml (the authoritative CI check) still has the exclusion, so CI is unaffected. Fix: either restore the skip in SKIP_PATTERNS, or accept that local check:links w

🟡 LOW lib.badge rendered without existence guard — src/pages/index.astro

Line 325: {lib.badge} is rendered unconditionally but badge is an optional-looking field (unlike stars/repo/name/blurb which are structurally essential). All 6 current ossLibs entries have it (verified at lines 23, 31, 39, 47, 55, 63), so it won't fail now, but a future entry missing badge would render undefined as text. Add {lib.badge ?? ''} or require the field in the data shape.

🟡 LOW OpenCode harness chip shows SST logo instead of OpenCode brand — src/pages/services/sandbox.astro

Line 28: logo: 'sst' resolves to the SST infrastructure-as-code tool icon from simple-icons, not the OpenCode brand mark. The previous code used a custom /logos/opencode.svg (deleted in this PR). The vendor: 'sst' is accurate — SST owns OpenCode — but the SST simple-icons logo is a different visual identity. Consider whether the SST logo renders correctly in the chip or whether a letter-fallback (logo: null) would be more honest until an OpenCode simple-icons entry exists.

---

_{tangletools · 2026-05-05T06:36:20Z · trace}

[tangletools]

❌ 2 Blocking Findings

Core change — moving @tangle-network/brand from file:../brand to npm ^0.2.0 — is clean and correct; all CI workflows properly drop the git-clone-sibling step. Three real issues prevent merge: operators.astro now claims 'LIVE PAYOUTS' with fabricated dollar figures (code comment admits they're illustrative, but nothing in the rendered UI says so); deploy.yml swapped the pnpm/action-setup and setup-node order in a way that breaks cache per official docs; and four blog posts were deleted with no redirect config, burning any inbound SEO/backlinks. | Read all 26 changed files. The core change is mi

🔴 HIGH deploy.yml: pnpm/action-setup runs after actions/setup-node cache:pnpm — cache is a no-op — .github/workflows/deploy.yml

Lines 16-21: the new order is setup-node (with cache: pnpm) first, then pnpm/action-setup. Per the official pnpm/action-setup v4 docs and the actions/setup-node docs: 'When using the cache option in setup-node, pnpm/action-setup must be run before setup-node.' With pnpm not installed at cache-resolution time, setup-node cannot locate the pnpm store path and the cache step silently becomes a no-op. Builds succeed but every run does a full cold install (~60–90s penalty). Fix: move pnpm/action-setup back before setup-node, matching the pre-PR order.

🔴 HIGH operators.astro presents fabricated numbers as live on-chain data — src/pages/operators.astro

Lines ~73-125: the section label was changed from 'OPERATOR LEDGER · PREVIEW' (with an explicit disclaimer: 'Numbers below are illustrative') to 'LIVE PAYOUTS' with a pulsing dot. The stats block now reads '$2,847 last hour', '412 payouts/min', '$68,328 last 24h', '147 operators serving'. The code comment at line ~73 acknowledges 'Numbers below are illustrative — the ledger surface that wires this to live x402 settlements is on the protocol roadmap'. There is no visible disclaimer to visitors. Presenting fabricated throughput and payout figures under a 'LIVE' label is deceptive and creates legal/regulatory exposure. Fix: either revert to 'PREVIEW' labeling with explicit illustrative text, or add a visible disclaimer alongside the numbers.

5 Non-Blocking

🟠 MEDIUM deploy.yml: --branch=production removed — CF Pages may route to preview environment — .github/workflows/deploy.yml

Line 35: the wrangler-action command changed from 'pages deploy dist/client --project-name=tangle-website --branch=production' to 'pages deploy dist/client --project-name=tangle-website'. Without --branch=production, Cloudflare Pages uses the git branch name ('main') to determine production vs. preview. This is safe only if the CF Pages project is already configured with 'main' as the production branch. If it was previously relying on the explicit 'production' alias (a common CF Pages pattern), deployments will land in the preview environment and production will not be updated. Verify CF Pages project settings before merging.

🟡 LOW Cloudflare deploy lost explicit --branch=production flag — .github/workflows/deploy.yml

Line 35: pages deploy dist/client --project-name=tangle-website removed the --branch=production flag that was present in the old deploy at line 38. With the trigger now push: branches: [main], wrangler uses the current git branch (main) as the deployment branch. This works if Cloudflare Pages is configured to serve main as production, but the old explicit --branch=production was a safety net against misconfiguration. Verify the Cloudflare Pages project's production branch setting matches before merging.

🟡 LOW check-links.mjs drops blueprint-agent skip — local pnpm check:links will fail on private-repo URL — scripts/check-links.mjs

Lines 37-47 removed: the skip for '^https?://github.com/tangle-network/blueprint-agent' was deleted. The code comment that was there said 'Private repo — anonymous fetch returns 404 by design.' The blog post src/content/blog/subscription-vs-pay-per-request-api-pricing.mdx line 146 links to that repo. Running 'pnpm check:links' locally will now report a broken link. Note: lychee.toml (the authoritative CI check) still has the exclusion, so CI is unaffected. Fix: either restore the skip in SKIP_PATTERNS, or accept that local check:links w

🟡 LOW lib.badge rendered without existence guard — src/pages/index.astro

Line 325: {lib.badge} is rendered unconditionally but badge is an optional-looking field (unlike stars/repo/name/blurb which are structurally essential). All 6 current ossLibs entries have it (verified at lines 23, 31, 39, 47, 55, 63), so it won't fail now, but a future entry missing badge would render undefined as text. Add {lib.badge ?? ''} or require the field in the data shape.

🟡 LOW OpenCode harness chip shows SST logo instead of OpenCode brand — src/pages/services/sandbox.astro

Line 28: logo: 'sst' resolves to the SST infrastructure-as-code tool icon from simple-icons, not the OpenCode brand mark. The previous code used a custom /logos/opencode.svg (deleted in this PR). The vendor: 'sst' is accurate — SST owns OpenCode — but the SST simple-icons logo is a different visual identity. Consider whether the SST logo renders correctly in the chip or whether a letter-fallback (logo: null) would be more honest until an OpenCode simple-icons entry exists.

---

_{tangletools · 2026-05-05T06:36:20Z · trace}