自由职业项目启动对齐包
自由职业项目最容易翻车的地方不在执行，而在启动：范围没对齐、验收标准没写、审批人是谁不知道、客户素材什么时候给不清楚、沟通节奏靠感觉、变更来了没有流程。iHire 2026 对 2,250 名美国劳动者的调查把「期望/项目范围不清」与「沟通缺失或质量差」列为自由职业者最主要的两大挑战。问题不是不知道这些事重要，而是没有一个地方把它们按交付物逐条摆出来、并且如实标出哪些还没确认。
本技能做这件事：读一份 JSON，输出双方可逐条核对的启动对齐卡——项目与每个交付物的五类状态、范围内/范围外、验收标准、审批人、客户输入、沟通节奏、升级路径、变更流程、依赖图与根阻塞项、等待客户清单、缺失事实、时间线冲突、责任缺口、澄清问题、人工启动检查表、草稿（一律未发送）与 Markdown 对齐卡。脚本只读一个本地 JSON，不联网、不写文件、不签合同、不接受变更、不承诺价格与工期、不联系客户、不写 PM/CRM、不上传文件、不推断法律条款。
输入与澄清
字段表、判定顺序与安全边界见 @references/guide.md（同目录 references/sample.json 是常规样例，五个交付物分别落在五种状态；references/sample-blocked.json 是重复编号、非对象记录、拒绝引用、注入与循环依赖的样例，两者输出分布固定）。
最少确认：as_of（必须带时区偏移）、project.project_id、project.start_at、project.timezone。
必须问清的关键点：
as_of与项目时区不能省。没有它们无法判断当前时点与逾期，工具会停在INPUT_INCOMPLETE，而不是猜一个当前时间。- 有交付物 ≠ 已验收。每个交付物必须有非空的
acceptance_criteria，否则记MISSING_ACCEPTANCE_CRITERIA并停在证据不足。范围外声明同样是必需字段：没有out_of_scope记MISSING_OUT_OF_SCOPE。 - 有审批人 ≠ 已批准。
approver_party_id只是指定了审批人；真正的结论来自approvals[]里的状态。只有approved才算通过；pending/not_requested/rejected都推进ACTION_NEEDED；有审批人却没有任何审批记录记MISSING_APPROVAL_RECORD。 - 审批状态是封闭词表。只接受
approved/pending/not_requested/rejected；表外值记UNKNOWN_APPROVAL_STATUS，不猜。 - 客户输入状态是封闭词表。只接受
received/not_received/partial/waived；只有received与waived算完成，缺省或表外一律按「未收到」进入等待客户，并记UNKNOWN_INPUT_STATUS。 - 状态取最严重者。交付物与项目都用同一顺序聚合：
BLOCKED>INSUFFICIENT_EVIDENCE>WAITING_ON_CLIENT>ACTION_NEEDED>READY。 - 硬阻塞必须先人工修正：重复编号、审批人或依赖指向不存在的编号、依赖成环、到期时间无法解析或早于项目启动、非对象记录。这些判
BLOCKED，工具不会替你自动挑选一条。 - 时间线冲突单独列出。到期晚于项目目标交付记
DUE_AFTER_TARGET（推进ACTION_NEEDED）；目标交付早于启动记TARGET_BEFORE_START（项目级硬阻塞）。 - 沟通与变更全部来自你的事实。工具不内置任何行业默认（不说「一般每周同步一次」）。缺渠道/节奏/响应目标/升级路径分别记缺口；
change_process缺整段或缺任一步骤都记缺口。 - 不生成任何可发送内容。所有草稿的状态恒为
DRAFT_NOT_SENT；没有contact_consent: true就没有草稿，明确拒绝（false）会被记录，未表态（缺失）按未知处理并列入检查表。 - 只给文件名，不要给路径或链接。
evidence_ref与evidence_refs只接受单一文件名；含路径、链接或盘符的引用会被拒绝，输出里只保留安全化文件名，原引用不会回显。 - 不要填登录凭据。输入里出现密码、令牌一类字段或真实凭据形态的字符串会被整体拒绝，且不回显该内容。
执行
- 按 @references/guide.md 的字段表整理输入 JSON。第一次使用建议先用 @references/sample.json 跑一遍，确认输出结构后再换成自己的项目。
- 用 Python 3.9+ 执行本包脚本（无第三方依赖、不联网）：
python3 "<skill-directory>/scripts/run.py" "<input.json>"，Windows 可用py -3。 - 先看顶层
status：REJECTED表示输入疑似含凭据（已拒绝且未回显）；INPUT_INCOMPLETE表示缺as_of/ 项目编号 / 启动时间 / 时区；BLOCKED表示存在硬矛盾；GAPS_FOUND表示存在待补齐、证据不足或等待项；READY表示项目与全部交付物就绪。 - 再看
project_state与status_counts：READY/ACTION_NEEDED/WAITING_ON_CLIENT/INSUFFICIENT_EVIDENCE/BLOCKED。 - 按
deliverables[].state与deliverables[].findings逐条处理；按root_blockers先解根阻塞，按dependency_cycles打破循环。 - 按
waiting_on_client追客户输入与审批；按missing_facts与clarification_questions逐条追问；不要自行填数，也不要把缺失当成 0。 - 按
timeline_conflicts/responsibility_gaps/unknown_parties修正时间线、责任人与编号。 - 按
drafts（全部DRAFT_NOT_SENT）准备人工沟通；contact_consent未同意者没有草稿，须先人工确认同意。 - 用
human_checklist完成启动前核对，用human_confirm_items明确哪些决定必须由人工做。
运行约束
- 只读：只读取用户提供的那一个 JSON；不打开链接、不调用外部服务、不写文件、不访问任何项目管理或客户系统。
- 不自动执行：不签合同、不接受范围/价格/工期变更、不承诺价格与交期、不自动联系客户、不写 PM/CRM、不上传文件、不推断法律条款。
- 只推导不发明：结论只由输入中的明示事实推导；不虚构验收标准、审批结论、客户输入、沟通节奏或变更流程。
- 未知保持未知：缺失验收不按通过、缺失审批记录不按批准、缺失客户输入不按已收到、缺失格式/数量不按 0。
- 状态门禁：五类状态固定聚合顺序；硬阻塞（重复编号、悬空依赖、依赖成环、非法/倒置时间、非对象记录）必须先人工修正。
- 同意门禁：
drafts恒为DRAFT_NOT_SENT；contact_consent不为true时不生成任何草稿。 - 确定性：交付物按输入顺序、编号映射按首次出现、列表按固定顺序，同一输入输出逐字节一致。
- 文件名门禁：
evidence_ref/evidence_refs只接受单一文件名；含路径、链接或盘符的引用被拒绝，且只输出安全化文件名，原引用在任何字段都不出现。 - 提示注入逐字段检测、位置精确、低误报：覆盖备注、项目名、沟通/变更文本、交付物描述、验收/范围外、审批主题、客户输入描述；命中时只加标记并在
injection_flagged中给出精确路径（如notes、deliverables[1]/description）；检测要求「动作词 + 目标词」同句共现。 - 不可信文本先转义再入简报，命中即隐藏：
markdown_summary中所有自由文本走同一转义处理（去控制字符、折叠空白、对 Markdown 元字符加反斜杠）；命中注入的值改用固定占位「已隐藏疑似提示注入文本」。 - 隐私门禁：字段名命中
password、token、api_key一类凭据名，或字符串值具备真实凭据形态，直接拒绝处理且不回显该内容。 - 免责：输出是项目启动对齐的人工准备材料，不是合同、报价、工期承诺、法律或税务结论；范围、验收、审批与合规必须由双方人工确认。
