Risk Summary

Risk Summary

Signal	Status
Posting legitimacy	✅ High Confidence
Employment classification	⚠️ contractor-style language: "{quoted phrase}"
Culture screen	⚠️ caution — {evidence}
Interview red flags	— no interview sessions yet
AI claims vs. infrastructure	— not evaluated

## 评估后流程：报告落盘与追踪器登记

fursah.md 规定 A–G 完成后必须执行两步，无一例外。

### 1. 保存 Markdown 报告

文件路径为 `reports/{###}-{company-slug}-{YYYY-MM-DD}.md`，命名规则：

- `{###}` = 三位零填充的序列号（如 `042`）；
- `{company-slug}` = 公司名小写英文、无空格、连字符分词；
- `{YYYY-MM-DD}` = 当前日期。

关于序列号的原子分配：其英文源文档 `modes/oferta.md` 明确要求通过 `node reserve-report-num.mjs` 领取号码（stdout 返回 `{###}`），写完报告后再用 `node reserve-report-num.mjs --release {###}` 释放哨兵，以防止并发评估撞号。查看 [reserve-report-num.mjs](https://gitcode.com/GitHub_Trending/ca/career-ops/blob/398edb11421475c463c1e2f254031400eec0139b/reserve-report-num.mjs?utm_source=gitcode_repo_files) 源码可以看到其实现机制：追踪器扫描与哨兵创建都在与追踪器写入者相同的锁下执行，而 `O_CREAT|O_EXCL` 保证哨兵文件跨进程创建的原子性，`formatReportNumber` 则强制三位零填充格式（见该文件 L13–L17 的用法注释与 L41–L47 的格式化函数）。

**报告结构模板**（fursah.md 原文完整继承）：

```markdown
# Evaluation: {Company} — {Role}

**Date:** {YYYY-MM-DD}
**URL:**
**Archetype:** {detected}
**Score:** {X/5}
**Legitimacy:** {High Confidence | Proceed with Caution | Suspicious}
**PDF:** {path or pending}

---

## A) Role Summary
（块 A 完整内容）

## B) Match with CV
（块 B 完整内容）

## C) Level and Strategy
（块 C 完整内容）

## D) Comp and Demand
（块 D 完整内容）

## E) Customization Plan
（块 E 完整内容）

## F) Interview Plan
（块 F 完整内容）

## G) Posting Legitimacy
（块 G 完整内容）

## Risk Summary
（每个风险信号一行，固定顺序 — 见上方 Risk Summary 章节）

## H) Draft Application Answers
（仅当综合匹配评分 ≥ 4.5 时写入 — 面向申请表的现成答案草稿）

---

## Keywords extracted
（从 JD 提取的 15–20 个 ATS 优化关键词）

注意块 H 的条件门：只有综合匹配分达到 4.5 及以上才生成申请表答案草稿。这与 modes/_shared.md 的评分解读表（4.5+ 立即推荐投递、4.0–4.4 值得投递、3.5–3.9 视情况、3.5 以下不推荐）共同构成了投递决策线。

2. 登记到追踪系统

fursah.md 要求始终把该申请登记进主表 data/applications.md，但禁止直接编辑主表——而是把临时行写入 batch/tracker-additions/ 目录下的 TSV 文件，以避免重复并便于正确合并，然后运行：

node merge-tracker.mjs