Drafting Hub：先按这个顺序读 Track D，不要上来就 polish prose

TL;DR

Track D 的正确顺序不是：

先开 Petition Letter -> 写一大段 -> 语言不顺再修

而应该是：

PE object -> RL planning -> PL architecture -> revision order -> cross-document QA

Use this if

• 你已经有基本 route 和 evidence 设计
• 你现在要把东西写成文档系统
• 你不想一上来就掉进 prose polishing

Not for you if

• 你还没做好 evidence design
• 你已经到 final filing / RFE 阶段

The Track D reading order

1. 先把 PE 写成可审对象

• 如何把 Future Plans 写成一个 defendable Proposed Endeavor
• PE 常见失败模式

先解决 object 和 failure mode，再谈语言。

2. 再规划 RL，不要先群发请求

• 如何 brief recommenders
• RL Portfolio Strategy：每个 recommender 只承担一个证明任务

这里的 proof brief、proof job 都是 internal planning shorthand，不是当前 /app/case/recommendations 的固定字段。

3. 再搭 PL 骨架

• Petition Letter Architecture

PL 的问题通常不是文采，而是 architecture。

4. 再决定 revision order

• Revision Order：先改 structure，再改 evidence，最后改语言

如果你不先控制 revision order，draft 越改越乱几乎是必然的。

5. 最后做 cross-document QA

• Cross-Document Consistency

A simple drafting flow

PE -> RL planning -> PL -> revision order -> consistency sweep

如果你现在已经在 PL 里写到很长，但 PE 还不稳，就该退回前一步。

If you only have one blocker

• PE 总像 job description：
• 先读 Turn Future Plans into a Defendable Proposed Endeavor
• 再读 PE Failure Modes
• 推荐信总是重复：
• 先读 How to Brief Recommenders
• 再读 RL Portfolio Strategy
• PL 越写越散：
• 先读 Petition Letter Architecture
• 再读 Revision Order

After reading do this

1. 回到 /app/case/proposed-endeavors，确认当前 PE object 是否已经稳定。
2. 回到 /app/case/recommendations，只输入当前产品真实支持的 referrer / materials / config 信息。
3. 回到 /app/case/petition，先搭 document plan，再动 prose。