How to Use Dashboard / Case / Proposed Endeavors / Recommendations / Petition

Canonical question: What does each core product module do, what should the user input, and what should happen next?

Expected output: A module-by-module operating plan for the current product.

TL;DR

小白最容易犯的错，是只记住页面名，不知道每个页面到底干什么。

当前产品里最核心的 5 个页面可以这样记：

• Dashboard: 看总体 readiness、route comparison、claim coverage
• Case: 补 profile facts、history、future plan、evidence
• Proposed Endeavors: 定义和迭代 PE
• Recommendations: 管 referrers，配置 RL workflow
• Petition Letter: 做 PL review 和结构化推进

Why you should read this now

如果你会说：

• “我是不是该先去写 PE？”
• “Case 和 Dashboard 有什么区别？”
• “Recommendations 里先填什么，后生成什么？”

那你现在缺的是 module operating plan。

Use this if

• 你是第一次正式进入产品主流程
• 你想知道当前页面该填什么、别填什么
• 你想减少来回跳页面的无效动作

Not for you if

• 你已经长期在产品里推进，页面语义很熟
• 你当前只需要某个单独文档的深度写作建议

Module I/O map

页面 | 你主要输入什么 | 你主要得到什么 | 下一步通常去哪里

Dashboard | 不是手填主数据；主要是读当前 case 的 scorecard / route / claim coverage | route comparison、claim coverage、readiness snapshot | /app/case 或 /app/case/proposed-endeavors

Case | personal info、education、projects、professional history、future plan、evidence | case facts、intake records、evidence inventory | /app/dashboard、/app/case/proposed-endeavors、/app/case/recommendations

Proposed Endeavors | route-grounded PE drafting / candidate selection | PE candidates、selected versions、route-grounded object | /app/case/recommendations 或 /app/case/petition

Recommendations | referrer info、endorsed endeavors、endorsed items、config / generate | RL config、generated RL draft、outdated warnings | /app/case/petition 或回 /app/case 补材料

Petition Letter | PL draft/review actions、section-level review | PL structure、review comments、scorecard-aware revision target | packet QA / filing checklist

How a beginner should actually use them

1. Start in Case

先把 case facts 补完整。不要在 facts 还空的时候就去做高级 narrative。

2. Then check Dashboard

看 route comparison、claim coverage、argument diagnosis。这里更像判断板，不是原始数据录入页。

3. Then use Proposed Endeavors

当你已经知道大概哪条 route 更稳，再去 PE。这里应该服务一个更清楚的 endeavor object。

4. Then use Recommendations

先把 referrer 基础信息和 endorsed materials 配好，再 generate draft。不要把这里当“随手让人夸我一下”的地方。

5. Then use Petition Letter

当 PE / RL / evidence 已经有一定稳定度时，再把 PL 当成总逻辑 spine，而不是第一步。

Common mistakes

• 把 Dashboard 当成写作页
• 把 Case 当成可跳过的 intake 表单
• 在 Proposed Endeavors 里反复改，但 profile facts 还是空
• 在 Recommendations 里先 generate draft，再回头补 referrer 基础信息
• 把 Petition Letter 当成最后统一兜底的地方

After reading do this

1. 给自己写一个 module operating plan：我当前应该主用哪个页面，为什么。
2. 如果你还是零基础，先回 /app/case 把 facts 补齐，再去 /app/dashboard 看判断层。
3. 只有当事实和 route 已经有一定稳定度，才进入 /app/case/proposed-endeavors、/app/case/recommendations、/app/case/petition。

Related reads

• End-to-End NIW Process and Timeline
• DIY Materials Checklist
• Petition Letter Architecture

Sources / basis

• README.md
• frontend-new/src/App.tsx
• frontend-new/src/pages/Dashboard.tsx
• frontend-new/src/pages/recommendations/components/LetterWorkspace.tsx
• frontend-new/src/layouts/MainLayout.tsx

Related reads

• End-to-End NIW Process and Timeline：从不了解到 filing 的完整路径 - 把 NIW 拆成 orientation、gate、endeavor、evidence、drafting、packet、filing、RFE recovery 八步，避免一上来就乱跳。
• DIY Materials Checklist：小白要自己准备什么，为什么准备，先后顺序是什么 - 把官方 filing items、证据材料、产品内输入、app 外 worksheet 分开，才不会一上来就乱收材料。
• Petition Letter Architecture - 好的 Petition Letter 不是把所有事实堆成一封长信，而是让每个 section 只承担一个 adjudication job。

Source basis

1. [1] README core routes and feature descriptions - Repository README
2. [2] frontend-new/src/App.tsx - Frontend routes
3. [3] Dashboard / Recommendations / AppShell - Frontend page implementations