feat(content): expand Blueprint and TEE explainers

[drewstone]

What changed

• Expanded tee-attestation-ai-services into a zero-context article with a private summarization story, execution-vs-quality boundary, public provider sources, a runnable toy TypeScript policy check, and failure handling.
• Expanded 30-blueprints into a builder's decision guide with a complete request-to-result path, public SDK starter command, illustrative contract model, caller/operator tradeoffs, and an unhappy-path review.
• Refreshed docs/editorial/blog-zero-context-triage.md from the stale pre-rewrite baseline.

Proof

• pnpm check:blog — 85 posts, 13 series, 0 errors, 0 warnings
• pnpm check:blog:reader --report docs/editorial/blog-zero-context-triage.md — 0 P0, 36 P1, 49 P2, 0 hard rejects
• pnpm build — pass (existing Vite chunk-size warning only)
• docs slop scan — 0 findings on both changed posts
• Public source links — HTTP 200
• git diff --check — pass

[tangletools]

✅ Auto-approved drewstone PR — be23c361

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-08-04T02:07:20Z}

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Concerns	1 (1 low)
Heuristic	0.0s
Duplication	0.0s
Interrogation	219.0s (2 bridge agents)
Total	219.0s

💰 Value — sound

Rewrites two P0 (hard-fail) blog posts into P1 decision-grade explainers, clearing all hard failures and fitting the established series/content grain — no duplication, no better approach.

• What it does: Expands src/content/blog/30-blueprints.mdx from a catalog-list post ('30 Tangle Blueprints: LLM Inference to Autonomous Trading') into a caller/builder decision guide with a caller-vs-operator-vs-payment split table, a request-to-result path, an illustrative TypeScript ServiceContract toy model, the real cargo tangle blueprint create SDK command, a 5-step repo-inspection workflow, and a hosted
• Goals it achieves: Move both posts out of the P0 rewrite tier by clearing their hard failures (repository-debris, native-jargon-before-definition, number-without-conditions for 30-blueprints; repository-debris, native-jargon-before-definition for tee-attestation). Give each a concrete reader problem, a decision, and machine-checkable evidence (code blocks, FAQ, primary sources). Retire the catalog-count ti
• Assessment: Good change, in the grain of the codebase. The agent-intent-series skill (.codex/skills/tangle-agent-intent-series/SKILL.md) and blog-editor skill (.codex/skills/tangle-blog-editor/SKILL.md) define the exact template these posts now follow: answer capsule in the opening, an executable code block, FAQ with ### questions, >=2 internal links, >=3 primary external sources, decision-led closer. T
• Better / existing approach: none — this is the right approach. Checked for an existing chooser/buyer-side Blueprint guide via grep on 'how to choose|chooser|caller decision|buyer.s guide' across src/content/blog/*.mdx: only operator-staking-ai-blueprints.mdx (staking, not choosing) matched, so the caller-decision angle on 30-blueprints is genuinely new. The closest neighbors are blueprint-protocol-operator-services.mdx (
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error

🎯 Usefulness — sound

Two existing blog posts are expanded into differentiated zero-context explainers that remain fully wired into the Astro content collection and cross-link live sibling posts; nothing is dead or competing.

• Integration: Both files are schema-valid members of the blog collection (src/content.config.ts:4-21) and are auto-routed by src/pages/blog/[...slug].astro:5-11 via getCollection('blog', ({data}) => !data.draft). They render at /blog/30-blueprints and /blog/tee-attestation-ai-services. Frontmatter (title/slug/summary/date/author/tags) satisfies the required schema on both; draft is unset so they are inclu
• Fit with existing patterns: The expansion follows the repo's own documented editorial direction (docs/editorial/blog-zero-context-triage.md, docs/editorial/blog-quality-checklist.md) rather than inventing a new pattern. The retitled 30-blueprints now occupies a distinct reader niche — a consumer/builder decision guide ('How to Choose an Operator-Run Service') — differentiated from sibling explainers: how-blueprints-work (arc
• Real-world viability: Static MDX with only markdown tables and fenced code blocks (2 fenced blocks per file, balanced); no JSX components, imports, or interactive runtime to break under edge inputs. The TypeScript toy policy check is syntactically valid and explicitly labeled illustrative ('not a copy-paste SDK type'), so it cannot be mistaken for a runnable SDK contract. The cargo CLI command matches the public SDK RE
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

🔎 Heuristic Signals

🟡 Cruft: console debug added src/content/blog/30-blueprints.mdx

+console.log(

---

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 · 20260804T021843Z}

[tangletools]

✅ Auto-approved drewstone PR — 5053a5b7

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-08-04T02:18:47Z}

[tangletools]

✅ Auto-approved drewstone PR — 96a8c7f5

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-08-04T02:21:59Z}

[tangletools]

🟡 Value Audit — sound-with-nits

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

💰 Value — sound-with-nits

Expands two terse catalog-style posts into zero-context builder/caller decision guides with worked stories, runnable TypeScript policy toys, and failure paths; aligns them with the repo's enforced editorial standard (docs/editorial/blog-quality-checklist.md) and augments in place rather than forking

• What it does: Rewrites 30-blueprints.mdx (188→498 lines) from a '30 examples catalog list' into a caller-facing decision guide that follows one private-PDF summarization job from request to result, with a toy ServiceContract TypeScript model, a 6-step inspection checklist for public Blueprint repos, an unhappy-path timeline, and caller-vs-operator-vs-hosted-API decisions. Rewrites tee-attestation-ai-services.md
• Goals it achieves: Bring two older posts up to the zero-context editorial standard enforced since 41a9292 (docs/blog: enforce zero-context editorial standard). The previous versions assumed reader context, lacked runnable examples, and in 30-blueprints' case carried a stale catalog count ('30') in the title that the post itself admitted was only a snapshot. The new versions give each post one named reader problem, a
• Assessment: Good change, in the grain of the codebase. (1) Augments in place — same slugs, same files, same dates; does not fork new posts. (2) Differentiated from sibling posts by reader path: 30-blueprints is caller-side 'how to choose', while how-blueprints-work.mdx is protocol architecture/lifecycle, blueprint-protocol-operator-services.mdx is author-side 'how to define one', building-ai-services-on-tangl
• Better / existing approach: none — this is the right approach. Searched src/content/blog for 'blueprint' (100+ matches across ~15 posts) and inspected the four closest siblings (how-blueprints-work, blueprint-protocol-operator-services, building-ai-services-on-tangle, trusted-execution-on-tangle). Each occupies a distinct reader path; none is a wholesale substitute for the two posts being expanded. Augmenting in place was co
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error

🎯 Usefulness — sound

Two expanded MDX blog posts integrate cleanly into the existing content collection and series — frontmatter validates, all internal links and cover images resolve, the series ordering is conflict-free, and the dedicated blog audit passes with 0 errors.

• Integration: Standard MDX in the blog collection (src/content.config.ts:4-21); frontmatter matches the zod schema. All 5 internal /blog/ links resolve to existing files, both cover images exist under public/images/covers/editorial/, and the 'Agent Intent Infrastructure' series has orders 1-12 with no conflicts (TEE post = order 12). The 30-blueprints slug is preserved across the title change so no inbound link
• Fit with existing patterns: Follows the established Agent Intent Infrastructure series pattern and the zero-context editorial standard enforced by scripts/audit-blog.mjs. Cross-links to sibling posts (trusted-execution-on-tangle, blueprint-sdk-deployment-guide, building-ai-services-on-tangle, ai-agent-sandbox, blueprint-sdk-x402-payments-runnable-jobs) are exactly the connections the series relies on. The title change for 30
• Real-world viability: Static MDX content; the toy TypeScript/JSON/bash/text code blocks are fenced for reading and explicitly labeled illustrative ('not a copy-paste SDK type', 'does not contact Tangle'), so they carry no build or runtime risk. The realistic-use questions for a blog post — does it render, do links resolve, is frontmatter valid, does it survive the audit — are all yes. (Full astro build could not be run
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

🔎 Heuristic Signals

🟡 Cruft: console debug added src/content/blog/30-blueprints.mdx

+console.log(

💰 Value Audit

🟡 Slug 30-blueprints no longer matches the retitled post [maintenance] ``

30-blueprints.mdx:2-3 retitles to 'Tangle Blueprints: How to Choose an Operator-Run Service' but keeps slug 30-blueprints. The new body even explains 'The old version of this article used a catalog count in its title' (30-blueprints.mdx:323-325), so the count is now explicitly meaningless, yet it lives on in the URL. Preserving the slug to avoid breaking inbound links is a defensible tradeoff and should not gate the merge; if a redirect map exists (worth checking in the Astro config / vercel.j

---

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 · 20260804T022413Z}