docs: plan cloudpack series (6 posts) with visuals and key numbers

Cloudpack series maps native linker innovations to JS bundling at
Microsoft Teams scale (50k+ modules). Source: ~/workspace/wundler/
(kenotron-ms/cloudpack on GitHub).

Series plan:
1. The Bundle Is Not a File (ThinLTO/mold/BOLT analogy)
2. The 2KB Module Summary (25x compression, content-addressed)
3. Dead Code That Actually Stays Dead (two-layer tree-shaking)
4. The Service Worker as ld.so (ABS delta delivery)
5. Your Users Are Teaching the Bundler (PGO from browser sessions)
6. Signing Manifests, Not Code (ed25519, threat model)

Key receipts: 604ms warm rebuild at 10k modules, ~100MB for 50k
module summaries (fits L3), ~50% CDN bandwidth saved per deploy.

🤖 Generated with Amplifier

Co-Authored-By: Amplifier <240397093+microsoft-amplifier@users.noreply.github.com>
This commit is contained in:
Ken
2026-05-27 06:36:49 +00:00
parent cde305e44a
commit 6241656f55
+23
View File
@@ -205,3 +205,26 @@ Source: kenotron-ms/rage repo + ~/workspace/family/Work/Reference/BuildXL spec
Each post stands alone but gains context from the series. The series landing page Each post stands alone but gains context from the series. The series landing page
shows progress (like makingsoftware.com's progress bar) and creates anticipation shows progress (like makingsoftware.com's progress bar) and creates anticipation
for upcoming posts. for upcoming posts.
## Current Content Plan: Cloudpack Series
Source: ~/workspace/wundler/ (kenotron-ms/cloudpack on GitHub) + architect brief + exec summary
The core idea: the bundle is not a file, it's a query against a continuously-maintained
module graph. The architecture maps native linker innovations (ThinLTO, mold, BOLT/Propeller)
to JavaScript bundling at Microsoft Teams scale (50k+ modules).
| # | Title | Angle | Visuals Needed |
|---|-------|-------|----------------|
| 1 | The Bundle Is Not a File | Linker-world analogy. ThinLTO/mold/BOLT mapped to JS bundling. "Database, not compiler." | Architecture: the 3-phase pipeline. Side-by-side: linker innovation → bundler equivalent. |
| 2 | The 2KB Module Summary That Replaced a Full Parse | ModuleSummary as the core data structure. 25x compression. Content-addressed cache. | Diagram: source file (50KB) → ModuleSummary (2KB). The rayon parallel loop. |
| 3 | Dead Code That Actually Stays Dead | Two-layer tree-shaking: module-level (conservative) + function-level (aggressive via call-edge graph). SideEffectMarker AST analysis. | Flow: BFS reachability + Tarjan SCC + call-edge DCE walk. Before/after module counts. |
| 4 | The Service Worker as ld.so | Adaptive Bundle Service. Delta manifests. Browser tells server what it has, server returns only what's missing. | Architecture: CDN chunks as shared libraries, SW as dynamic linker. Delta computation flow. |
| 5 | Your Users Are Teaching the Bundler | Profile-Guided Optimization from real browser sessions. C³ co-request clustering. SQLite co-request matrix. Prefetch without rebuild. | The feedback loop: browser sessions → JSONL → SQLite → C³ clustering → manifest hints. |
| 6 | Signing Manifests, Not Code | Ed25519 signing of chunk hashes. Threat model: ABS compromise ≠ code injection. PGO fields excluded from signature. | Security model diagram: what's signed, what's not, what an attacker can/can't do. |
Key numbers for receipts:
- 10k modules warm rebuild: 604ms analysis-only
- 50k modules in memory as summaries: ~100MB (fits L3 cache)
- ABS delivery: ~50% CDN bandwidth saved per deploy
- 50k modules, 10k DAU, 1% weekly churn: saves ~47 GB/week