Headroom Realignment 目标架构解析：Rust-only 代理的请求生命周期、十大缓存安全不变量与 Auth-Mode 策略矩阵

本文围绕 REALIGNMENT/02-architecture.md 展开，完整继承该文档定义的目标架构骨架：Phase H 之后的 Rust-only 代理请求生命周期（11 步管线）、I1–I10 十条缓存安全不变量、压缩器模块布局、Auth-Mode 策略矩阵，以及 TOIN / CCR / Kompress 三个保留原语。在此基础上，结合当前仓库 crates/headroom-core 与 crates/headroom-proxy 的实际源码与测试，印证每个不变量的落地方式与 CI 测试门禁，帮助读者既读懂设计意图，又能沿源码与测试逐条验证其实现。

1. 总体定位：Phase H 之后的 Rust-only 代理

REALIGNMENT 系列的总入口是 REALIGNMENT/INDEX.md，其目标概括为：把整个代码库迁移到 Rust、保留 prefix cache、维持压缩价值、端到端集成 RTK，并以认证模式（PAYG / OAuth / Subscription）门控压缩策略。02-architecture.md 回答的是“迁移完成后的目标形态长什么样”：每个子系统的职责边界、不变量、文件布局，以及它明确不做的事情。配套的阶段文档（03-phase-A-lockdown.md 到 11-phase-I-test-infra.md）以 PR 粒度给出执行计划，本文聚焦架构文档本身。

2. 请求生命周期：Rust 侧的 11 步管线

文档 2.1 节给出的完整生命周期如下（原文继承）：

                                Client request
                                      │
                                      ▼
            ┌──────────────────────────────────────────────┐
            │ headroom-proxy (axum)                        │
            │                                              │
            │  1. classify_auth_mode(headers)              │  ← Phase F
            │     → "payg" | "oauth" | "subscription"      │
            │                                              │
            │  2. strip x-headroom-* from upstream-bound   │  ← Phase A (PR-A5)
            │                                              │
            │  3. byte-buffer body via RawValue            │  ← Phase A (PR-A4)
            │     (numeric precision preserved)            │
            │                                              │
            │  4. honor cache_control markers              │  ← Phase A (PR-A4)
            │     → frozen_message_count                   │
            │                                              │
            │  5. live_zone_compress(body, frozen_count,   │  ← Phase B
            │                       auth_mode)             │
            │     ├─ identify live-zone blocks             │
            │     ├─ per-block content-type detection      │
            │     ├─ dispatch to type-aware compressor     │
            │     ├─ token-validate; fallback to original  │
            │     ├─ CCR: hash-key, store, marker          │
            │     └─ replace block bytes in-place          │
            │                                              │
            │  6. tool_def_normalize(body)                 │  ← Phase E (PR-E1, E2)
            │     ├─ alpha-sort tools[]                    │
            │     └─ recursive-sort JSON Schema keys       │
            │                                              │
            │  7. cache_control_auto_place(body)           │  ← Phase E (PR-E3)
            │     (Anthropic; up to 4 ephemeral)           │
            │                                              │
            │  8. prompt_cache_key_inject(body)            │  ← Phase E (PR-E4)
            │     (OpenAI; only if not customer-set)       │
            │                                              │
            │  9. forward via reqwest with original bytes  │
            │     for unmodified envelope (RawValue diff)  │
            │                                              │
            │ 10. SSE response: byte-level state machine   │  ← Phase C (PR-C1)
            │     ├─ track blocks/items by id              │
            │     ├─ all delta types handled               │
            │     ├─ mid-stream error/ping/drop surfaced   │
            │     └─ pure passthrough to client            │
            │                                              │
            │ 11. usage telemetry (cache_read,             │  ← Phase G
            │     cache_creation, output_tokens, etc.)     │
            └──────────────────────────────────────────────┘
                                      │
                                      ▼
                                Upstream provider

这 11 步在当前仓库中可以找到清晰的落点：

• 步骤 1（auth-mode 分类）：由 auth_mode.rs 中的 classify 纯函数实现，见下文第 5 节。
• 步骤 4（frozen_message_count）：由 cache_control.rs 的 compute_frozen_count 计算——从 cache_control 标记推出“前 N 条消息已进 provider 前缀缓存”的下界。
• 步骤 5（live-zone 压缩）：入口在 live_zone.rs，其模块头注释完整描述了“live zone”的心智模型与边界规则。
• 步骤 6–8（Phase E 缓存稳定化）：对应 cache_stabilization/ 目录下的 tool_def_normalize.rs、anthropic_cache_control.rs、openai_cache_key.rs 等文件。
• 步骤 10（SSE 字节级状态机）：对应 sse/ 目录（anthropic.rs、openai_chat.rs、openai_responses.rs、framing.rs）。
• 步骤 11（usage 遥测）：对应 observability/ 目录（cache_hit_rate.rs、compression_ratio.rs、prometheus.rs）。

2.1 字节区间手术：为什么不用“反序列化 → 修改 → 再序列化”

这是整个架构中最关键的工程决策。live_zone.rs 的文档注释给出了明确解释：重写块通过 serde_json::value::RawValue 借用切片上的指针算术定位，然后把替换内容拼接进输出：

out = body[..block_start] || replacement || body[block_end..]

被重写范围之外的字节是从输入直接拷贝的，绝不重新序列化。之所以不能走“反序列化成 Value → 修改 → 序列化”的路径，是因为重新序列化无法保留原始空白、键序细节与数字格式——而这些恰恰是 provider 已经针对它计算过缓存的字节。文档 I1 不变量要求的“SHA-256 字节相等”只能靠这种字节级直拷保证。

该决策在工作区 Cargo.toml 中固化：serde_json 同时启用了 preserve_order、arbitrary_precision、raw_value 三个特性——arbitrary_precision 保留源文件中的数字字面量 token，raw_value 暴露未解析的 JSON 字节视图。

对应的 CI 测试门禁在 live_zone_dispatch.rs 的 byte_fidelity_outside_compressed_block 用例：断言被压缩块之外的前缀/后缀字节与输入完全一致。

3. 十条缓存安全不变量（I1–I10）

文档 2.2 节声明“每个 PR 都必须遵守”这十条不变量，与 INDEX.md 的 Cross-cutting invariants 一一对应。逐条继承原文档内容并附仓库证据：

I1 — 未修改字节的字节级忠实透传

对每个请求，发往上游的字节（SHA-256）必须与从客户端收到的字节除 transform 显式修改的字节区间外完全相等。不允许经过 Value 类型重新序列化，不允许 JSON 美化器插入空白，不允许对 UTF-8 用户内容做 \uXXXX ASCII 转义。

• 实现：messages[*] 条目使用 serde_json::value::RawValue；被修改的消息走全新序列化，保留的消息作为精确字节拷贝转发。
• 测试门禁：proxy_byte_faithful_anthropic_sha256 —— 录制一个真实 Anthropic /v1/messages 载荷，关闭压缩走一遍代理，在上游 mock 处断言 SHA-256 字节相等。仓库中 fixtures/anthropic_messages_request_real.json 与 integration_body.rs 即承载此类真实字节级回归。

I2 — 缓存热区永不被修改

以下内容 Headroom 永不触碰：system（字符串或块列表）、tools[*]（Phase E 的字母排序与 JSON Schema 键排序除外，两者都是确定性的）、索引小于 frozen_message_count 的任何消息、带 encrypted_content 的 reasoning 项、带 signature 的 thinking 块、redacted_thinking.data、compaction 项。

• 实现：live_zone_compress 从尾部遍历 messages，识别 live-zone 块（最新 user 消息、最新 tool_result、最新 function_call_output、最新 local_shell_call_output、最新 apply_patch_call_output），只修改这些块内部的字节。live_zone.rs 的注释进一步明确了上下界：下界是 frozen_message_count（下界以下必须逐字节一致），上界是“最新 user 消息”——最新 assistant 消息也属于热区，因为它正是下一轮响应继续的位置，永远不碰。
• 测试门禁：cache_hot_zone_unchanged_under_compression —— 含 system + tools + 5 轮历史 + 新 tool_result 的 fixture，断言上游处 system、tools 与前 5 轮字节相等。

I3 — Append-only

一旦某条消息出现在任何一次历史请求中，它的字节即被冻结。压缩只作用于 live zone（最新一轮）。

• 实现：frozen_message_count 是硬性下限；任何试图触碰 index < frozen_message_count 的压缩器会在编译期（Rust trait 约束）或运行期（Python assertion）被拒绝。
• 测试门禁：append_only_invariant_under_recompression —— 相同输入字节两次过压缩器产生字节相等输出，保留消息在两次运行间字节相等。

I4 — 确定性

对相同的 (input bytes, frozen_count, auth_mode)，压缩器产生字节相等的输出。无时间戳、无随机种子、无时间相关决策。

• 实现：TOIN 是纯观察（Phase B PR-B5），永不改变请求期决策；所有哈希使用 BLAKE3 / SHA-256 且输入顺序稳定；排序顺序显式化（输出用 BTreeMap，绝不 HashMap）；任何压缩代码路径中不出现 Instant::now()。
• 测试门禁：property test —— 对任意合法输入验证幂等性 compress(input) == compress(compress(input).original) 与运行间确定性 compress(input) == compress(input)。

I5 — Token 感知，而非字节感知

每次压缩后都要用 tokenizer 验证：若 compressed.tokens >= original.tokens，则转发原文。

• 实现：Phase B PR-B4。按内容类型设字节阈值：code > 2KB、JSON > 1KB、logs > 500B、纯文本 > 5KB；低于阈值直接不尝试压缩（开销超过收益）。
• 测试门禁：文档给出的 proptest 门禁 proptest_compression_token_count_non_increasing，在仓库中对应的实际实现是 live_zone_token_validation.rs 的 live_zone_compression_token_count_non_increasing 属性测试——对 strategy 生成的任意合法输入，断言 tokens(output) ≤ tokens(input)。

I6 — 位置保持

压缩从不重排 content 数组内的块，从不把一个块拆成多个，从不在既有块上添加内联元数据字段。

• 实现：压缩器签名为 fn(block: &mut Block) -> Result<()>——原地操作。块类型、tool_use_id / call_id、is_error、所有兄弟字段全部保留。
• 旁路元数据：CCR 检索指令放在一个独立的 marker 块（text 类型、兄弟节点）中，绝不作为原块上的额外字段。

I7 — 工具定义只归一化，不压缩

工具按 name 字母序排序；JSON Schema 键递归排序；description 空白归一化；除此之外每个工具 input_schema.properties[*].description 的字节原样保留。

• 实现：Phase E PR-E1、PR-E2。仓库中可见对应测试 integration_tool_sort.rs 与 integration_schema_sort.rs。

I8 — signature、encrypted_content、redacted_thinking.data 神圣不可侵犯

这些字段只透传：永不检查、永不解码、永不变换。

• 实现：压缩器的块类型分派对这些类型有显式的 no-op 分支。Bedrock/Vertex 原生路径（Phase D）保留它们——这一点与旧的 LiteLLM 转换器不同。对应仓库 bedrock/ 与 vertex/ 目录。

I9 — TOIN 只观察，绝不修改请求字节

TOIN 的模式统计跨请求增长；推荐在部署间隙发布到磁盘；压缩器只在启动时读取推荐，不在请求期读取。

• 实现：Phase B PR-B5。TOIN 的内存态写入是 append-only；读取永不阻塞压缩。

I10 — Auth 模式门控压缩策略

• PAYG：激进（完整 live-zone 压缩、CCR、工具注入、Phase 3 稳定化）；

• OAuth：透传优先（仅 live-zone 无损，不自动加 cache_control、不自动加 prompt_cache_key、不加 X-Forwarded-*）;

• Subscription：隐身优先（OAuth 全部行为，外加保留 accept-encoding、永不上游注入 X-Headroom-*、永不改写 User-Agent）。

• 实现：Phase F PR-F1、PR-F2。

4. 压缩器模块布局（Phase B 之后）

文档 2.3 节给出的目标布局如下（原文继承）：

crates/headroom-core/src/
├── lib.rs                     # public surface
├── tokenizer/                 # KEEP (HF + tiktoken impls)
│   ├── mod.rs
│   ├── hf_impl.rs
│   ├── tiktoken_impl.rs
│   ├── estimator.rs
│   └── registry.rs
├── ccr.rs                     # KEEP, hardened (persistent backend)
├── signals/                   # KEEP — drives live-zone consumers
│   ├── mod.rs
│   ├── line_importance.rs
│   ├── keyword_detector.rs
│   └── tiered.rs
├── transforms/                # the compressors
│   ├── mod.rs
│   ├── safety.rs              # MOVED from context/safety.rs (Phase B)
│   ├── live_zone.rs           # NEW — live-zone block dispatcher (Phase B)
│   ├── content_detector.rs    # KEEP
│   ├── detection.rs           # KEEP
│   ├── magika_detector.rs     # KEEP
│   ├── unidiff_detector.rs    # KEEP
│   ├── adaptive_sizer.rs      # KEEP
│   ├── anchor_selector.rs     # KEEP
│   ├── tag_protector.rs       # KEEP
│   ├── log_compressor.rs      # KEEP
│   ├── search_compressor.rs   # KEEP
│   ├── diff_compressor.rs     # KEEP
│   ├── kompress_compressor.rs # NEW — Phase H Rust port via `ort` crate
│   ├── smart_crusher/         # KEEP (25 files, correctly scoped)
│   └── pipeline/              # SHRUNK — only the live-zone orchestrator
│       ├── mod.rs
│       ├── orchestrator.rs    # rewrite to live-zone-only
│       ├── traits.rs          # LosslessTransform / LossyTransform
│       └── offloads/          # KEEP — JSON, log, search, diff offloads
└── auth_mode.rs               # NEW — Phase F (classify_auth_mode helper)

# DELETED in Phase B:
# context/                     ← except safety.rs which moved
# scoring/
# relevance/

crates/headroom-proxy/src/
├── lib.rs
├── main.rs
├── config.rs
├── error.rs
├── proxy.rs                   # Phase A: pure passthrough on /v1/messages
                               # Phase C: + /v1/chat/completions, /v1/responses
├── headers.rs                 # Phase F: conditional X-Forwarded-*
├── websocket.rs               # Phase C: WS Codex flow
├── sse/                       # NEW — Phase C
│   ├── mod.rs
│   ├── parser.rs              # byte-level state machine
│   ├── anthropic.rs           # 4-event dance + delta types
│   ├── openai_chat.rs         # tool_call accumulation
│   └── openai_responses.rs    # output items + reasoning summary
├── compression/
│   ├── mod.rs                 # routing by path × auth_mode
│   ├── live_zone_anthropic.rs # NEW (Phase B)
│   ├── live_zone_openai.rs    # NEW (Phase C)
│   ├── tool_def_normalize.rs  # NEW (Phase E)
│   ├── cache_control.rs       # NEW (Phase E)
│   └── model_limits.rs        # KEEP
├── bedrock/                   # NEW — Phase D
│   ├── mod.rs
│   ├── sigv4.rs
│   ├── invoke.rs
│   └── eventstream.rs
├── vertex/                    # NEW — Phase D
│   ├── mod.rs
│   ├── adc.rs
│   └── stream_raw_predict.rs
└── observability/             # NEW — Phase G
    ├── mod.rs
    ├── prometheus.rs
    ├── cache_hit_rate.rs
    └── compression_ratio.rs

# DELETED:
# compression/icm.rs           ← Phase A PR-A1
# compression/anthropic.rs     ← Phase A PR-A1 (replaced with live_zone_anthropic.rs in Phase B)

对照当前仓库可以确认这份布局已基本落地，且与文档标注一致：

• crates/headroom-core/src/ 下确实存在 tokenizer/、signals/、ccr/、transforms/live_zone.rs、transforms/safety.rs、transforms/smart_crusher/（约 25 个文件）、transforms/pipeline/offloads/（JSON、log、search、diff offloads），以及 auth_mode.rs；Kompress 的 Rust 端口落在 transforms/kompress.rs（文档树中标记为 kompress_compressor.rs，同 crate 另有 onnx_cpu.rs 支撑 ONNX 会话）。
• crates/headroom-proxy/src/ 下存在 proxy.rs、headers.rs、websocket.rs、sse/、compression/live_zone_anthropic.rs、compression/live_zone_openai.rs、bedrock/、vertex/、observability/；Phase E 的 tool_def_normalize 与 cache_control 归一化逻辑实际收敛在 cache_stabilization/ 目录中，与 compression/ 各司其职。

布局文档的价值在于它同时是删除清单：context/（safety.rs 除外）、scoring/、relevance/、旧 compression/icm.rs 全部退役——这与 INDEX.md 中“Retired (~25K LOC)”一节相互印证：ICM、RollingWindow、ProgressiveSummarizer、scoring.py、tool_crusher.py 以及 MessageScorer 的 Rust 移植（PR #338、#343，被判为无用功）都被删除。

5. Auth-Mode 策略矩阵（Phase F）

文档 2.4 节的完整策略矩阵如下（原文继承）：

策略维度	PAYG	OAuth	Subscription
Live-zone 压缩	aggressive	lossless-only	lossless-only
CCR 启用	是	是	是（长会话）
工具定义字母排序	是	是	是
JSON Schema 键排序	是	是	是
自动放置 cache_control	是	否（会使 scope 失效）	否
自动注入 prompt_cache_key	是（OpenAI）	否	否
修改 anthropic-beta	否	否	否
上游发送 X-Headroom-*	否	否	否
上游发送 X-Forwarded-*	是	是	否
改写 User-Agent	否	否	否
剥离 accept-encoding	可	可	否（保留）
有损压缩器（LLMLingua）	可	否	否
Memory 注入	live-zone 尾部	live-zone 尾部（门控）	live-zone 尾部（门控）
TOIN 聚合键	(mode, model)	(mode, model)	(mode, model)
Authorization 日志脱敏	前 12 字符	前 12 字符	前 12 字符

从源码结构看，该矩阵的执行点在 auth_mode.rs 的分类函数上。AuthMode 枚举定义为三个变体（auth_mode.rs）：Payg（激进压缩可开启）、OAuth（透传优先：不自动 cache_control、不自动 prompt_cache_key、不启用有损压缩器）、Subscription（隐身：OAuth 全部行为 + 保留 accept-encoding、绝不注入 X-Headroom-*、绝不改写 User-Agent）。

分类的判定顺序（最具体信号优先）值得注意：

1. Subscription UA 前缀 → Subscription。模块级常量 SUBSCRIPTION_UA_PREFIXES（auth_mode.rs）列出 claude-cli/、claude-code/、codex-cli/、cursor/、github-copilot/ 等，用 lowercased str::contains 匹配——CLI 的 auth-mode 优先于它恰好携带的 bearer token 形态：Claude Code 会话用的是 sk-ant-oat* token，但它是订阅客户端而非 OAuth。
2. Authorization: Bearer sk-ant-oat* → OAuth（Claude Pro/Max OAuth），必须先于更宽的 sk- PAYG 规则检查，因为 sk-ant-oat 同样以 sk- 开头。
3. Bearer sk-* / API key 类 → Payg。

分类器是纯函数（无 I/O、无 panic 路径）：非 UTF-8 头值落回安全默认 Payg 并记一条 tracing::warn!，让运维在日志流中发现问题客户端而不拖垮代理。

该矩阵背后的业务逻辑在 auth_mode.rs 的文档注释中写得很直白：PAYG 用户按 token 付费，激进压缩直接省钱；OAuth 用户的每次成本不透明且 OAuth scope 绑定 (account, model, session)，beta-header 漂移会使 scope 失效，因此缓存安全压倒一切；Subscription 用户的 provider 按请求数限速，程序化指纹检测意味着必须“看起来就是上游 agent 本人”。

6. 保留原语细节：TOIN、CCR、Kompress

文档 2.5 节定义了三个必须保留的底层原语（用户指令保留），逐条继承：

6.1 TOIN（Phase B PR-B5 之后）

// Strict observation-only.
pub trait Telemetry {
    fn record_compression(
        &self,
        auth_mode: AuthMode,
        model: ModelFamily,
        structure_hash: StructureHash,
        outcome: CompressionOutcome,
    );
    // No request-time hint API. Period.
}

// Recommendations published between deploys via:
//   $ cargo run -p headroom-toin-publish -- --auth-mode payg --model claude-3-7-sonnet
// Output: recommendations.toml committed to repo, loaded by compressor at startup.

要点：接口上不存在任何请求期 hint API。TOIN 的统计跨请求增长，但推荐只在部署间隙经 headroom-toin-publish 工具离线生成 recommendations.toml，由压缩器启动时加载——这就是 I4（确定性）与 I9（只观察）的共同落点。仓库中 transforms/recommendations.rs 与 recommendations_loader.rs 测试承载启动期加载逻辑。

6.2 CCR（Phase B PR-B7 之后）

pub trait CcrStore: Send + Sync {
    fn put(&self, hash: ContentHash, original: Bytes, ttl: Duration) -> Result<()>;
    fn get(&self, hash: ContentHash) -> Result<Option<Bytes>>;
    fn purge_expired(&self) -> usize;
}

pub struct SqliteCcrStore { ... }   // primary backend
pub struct RedisCcrStore { ... }    // optional, for multi-worker

// `ccr_retrieve` tool registered on every request for sessions that ever did CCR.
// Marker injection format: `<<ccr:HASH>>` appended to compressed block content.
// Markers are deterministic (hash is content-addressed); replay-safe.

CCR（Compress-Cache-Retrieve）的语义是“线上有损、端到端无损”：变换丢掉行或替换不透明字符串时，原文按进入 prompt 的哈希键存入 store，运行期通过检索工具调用按哈希取回原文。当前仓库 ccr/mod.rs 中 CcrStore trait 已落地为 put/get/len 契约，三个后端齐备：

• InMemoryCcrStore（in_memory.rs）：进程内分片 DashMap，测试默认；
• SqliteCcrStore（sqlite.rs）：生产默认，WAL 模式、预编译语句、读时惰性 TTL 清理，跨 worker 重启持久化；
• RedisCcrStore（redis.rs）：多 worker 可选，feature = "redis" 门控。

源码中还有两个与文档“标记确定、可重放”直接对应的参数：默认 TTL 为 30 分钟（ccr/mod.rs），且它是空闲窗口而非墙钟——每次成功 get 重置计时，使长会话中持续被引用的条目能存活；同时以 8 倍 TTL 的绝对上限防止常量访问把条目永久钉住（DEFAULT_MAX_LIFETIME_MULTIPLIER = 8）。端到端验证见 ccr_roundtrip.rs 与 live_zone_ccr.rs。

6.3 Kompress-base（Phase H PR-H4 Rust 端口之后）

// Plain-text §8.6 compressor. Used only as a last resort, only on live-zone
// user-message text exceeding 5KB.
pub struct KompressCompressor {
    // ONNX runtime via `ort` crate. Model deterministic for fixed weights.
    session: ort::Session,
    threshold_bytes: usize,
}

impl LossyTransform for KompressCompressor { ... }

定位非常克制：纯文本压缩器，只作为最后手段、只用于超过 5KB 的 live-zone 用户消息文本，权重固定时输出确定。当前仓库对应 transforms/kompress.rs，并有 kompress_parity.rs 做 Python/Rust 双端一致性验证。

7. 架构“明确不做”的清单

文档 2.6 节的负面清单是这套架构区别于“什么都压一点”型中间件的关键，逐条继承：

• 不丢弃历史消息。永远。 ICM 已消失。
• 不修改 system、tools 或任何旧轮次。
• 不把 Headroom 自己的工具注入客户 prompt——除非本会话已经触发过 CCR（且一旦注入就恒常存在，绝不抖动）。
• 不在请求期查询 TOIN。推荐只在启动时加载。
• 代理不 shell out 到 RTK。RTK 位于 wrap-CLI 一侧（2026-05-01 项目决议）。
• 不做 Anthropic ↔ OpenAI 形状互转。每个 provider 有自己的原生 handler；Bedrock 与 Vertex 走原生信封（Phase D）。
• 不在 /v1/responses/compact 或 /v1/conversations 上压缩（形状不同，仅透传）。
• 不改写请求头，除了：剥离上游方向的 x-headroom-*、以及按模式条件添加 X-Forwarded-*（仅 PAYG/OAuth）。
• 不添加 User-Agent。客户的 UA 原样透传。
• 不压缩图片、base64 块或音频（本次 realignment 范围外）。
• 不改 tool_use.input 的 JSON 键序、tool_calls.function.arguments 字符串内容、phase 字段、V4A patch、local_shell_call.action.command 的 argv 数组，以及任何加密/脱敏/compaction 内容。

这份清单与第 3 节的 I1–I10 互为表里：不变量回答“必须保证什么”，负面清单回答“哪些诱惑明确拒绝”。

8. 小结：如何用这套架构阅读当前代码库

如果你要在本仓库中验证 REALIGNMENT 架构文档的每一项主张，最短路径是：

1. 字节忠实：读 live_zone.rs 的字节区间手术说明，跑 live_zone_dispatch.rs 的 byte_fidelity_outside_compressed_block；
2. frozen 边界：读 cache_control.rs 的 compute_frozen_count；
3. auth-mode 门控：读 auth_mode.rs 的分类顺序与 AuthMode 枚举；
4. CCR 无损端到端：读 ccr/mod.rs 的 TTL 语义与 ccr_roundtrip.rs；
5. token 不减门禁：读 live_zone_token_validation.rs 的属性测试。

整体而言，02-architecture.md 的价值在于把“压缩工具输出”这件看似可以随意发挥的事，收敛为一组可测试的不变量：压缩只发生在 live zone，热区字节逐位冻结，输出确定性可复现，节省以 token 而非字节度量，且一切策略最终由 auth mode 一维门控。这是当前 Rust 代码库（headroom-core + headroom-proxy）实际组织方式的设计依据，也是后续阅读 03-phase-A-lockdown.md 等阶段文档的前提。