diff --git a/.evozeus-wrapper/CHANGELOG.md b/.evozeus-wrapper/CHANGELOG.md
index f3e276c..a710e17 100644
--- a/.evozeus-wrapper/CHANGELOG.md
+++ b/.evozeus-wrapper/CHANGELOG.md
@@ -6,23 +6,37 @@ Wrapper harness migrations are recorded under `.evozeus-wrapper/docs/migrations/
 
 ## [Unreleased]
 
+- No unreleased changes.
+
+## [v0.2.0] - 2026-07-20
+
 ### Skill changes
 
-- Upgraded the embedded EvoZeus-wrapper harness from v0.9.1 to v0.10.0.
-- Applied the v0.10.1 patch that preserves target-owned Markdown boundaries during harness refresh.
-- Clarified that the project hook covers canonical-repository maintenance while Skill-entry preflight remains prompt-enforced.
+- Added an outcome contract for task identity, deliverables, carriers, acceptance, dependencies, deadlines, work phases, and source references.
+- Added the weekly cascade from project milestone to personal weekly outcome to today's task, plus an owned `pending_sync` queue for oral or chat-sourced orphan work.
+- Added active portfolio filtering, workstream splitting, baseline versioning, formal-effort boundaries, evidence-based weighted progress, leave-adjusted capacity, and WIP checks.
+- Added explicit draft, approval, publish, receipt, and recall gates for management messages.
+- Added structured Base fallback fields, synthetic regression scenarios, and automated contract tests.
+- Upgraded the embedded EvoZeus-wrapper harness from v0.9.1 through v0.10.1 and clarified the boundary between repository maintenance hooks and prompt-enforced Skill-entry checks.
 
 ### Feedback / Issues
 
+- MetaInFLow/metainflow-dev-tasks#3: close the management planning and delivery loop.
 - MetaInFLow/EvoZeus-wrapper#12: correct hook capability scope and add the global session dispatcher lifecycle.
 - MetaInFLow/EvoZeus-wrapper#14: preserve target headings and accurate layout labels during harness refresh.
+- Design: `.evozeus-wrapper/docs/designs/2026-07-20-management-planning-delivery-loop-v0.2.0.md`.
 
 ### Verification
 
+- `python3 -m unittest discover -s tests -p 'test_*.py'`
 - `python3 .evozeus-wrapper/scripts/evozeus_wrapper_preflight.py structure`
 - `python3 .evozeus-wrapper/scripts/evozeus_wrapper_preflight.py doctor --repo MetaInFLow/metainflow-dev-tasks`
-- Skill format validation and repository hook adapter smoke test.
-- Confirmed the v0.10.1 refresh changed only wrapper-owned version references and appended the correct version-refresh note in `SKILL.md`.
+- Skill format validation, eval JSON parsing, repository hook adapter smoke test, PR preflight, and release preflight.
+
+### Data boundary and rollback
+
+- Public artifacts use synthetic examples and contain no raw chats, customer records, internal links, Base tokens, or credentials.
+- Roll back by restoring the `v0.1.0` Skill release; wrapper harness state remains independent at `v0.10.1`.
 
 
 
diff --git a/.evozeus-wrapper/docs/designs/2026-07-20-management-planning-delivery-loop-v0.2.0.md b/.evozeus-wrapper/docs/designs/2026-07-20-management-planning-delivery-loop-v0.2.0.md
new file mode 100644
index 0000000..2095982
--- /dev/null
+++ b/.evozeus-wrapper/docs/designs/2026-07-20-management-planning-delivery-loop-v0.2.0.md
@@ -0,0 +1,64 @@
+# Management Planning And Delivery Loop v0.2.0
+
+## Related Issue
+
+Related issue: MetaInFLow/metainflow-dev-tasks#3.
+
+## Optimization Goal
+
+Turn the current evidence-gathering Skill into a closed-loop management system. Every active project and assigned task should expose its intended outcome, weekly milestone mapping, plan version, progress basis, synchronization responsibility, capacity impact, and publication authorization state.
+
+The change must preserve existing Base routing and project-specific evidence rules while preventing vague assignments, orphan verbal tasks, silent rebaselines, unsupported progress percentages, polluted active worksets, and unauthorized team-message publication.
+
+## Direction
+
+1. Keep concise mandatory gates in `SKILL.md` so they execute on every relevant invocation.
+2. Put detailed field contracts, formulas, status models, output shapes, and fallback storage rules in `references/management-contracts.md`.
+3. Extend `references/schema.md` with recommended management fields and structured-note fallbacks when the live Base lacks dedicated columns.
+4. Add public-safe regression scenarios under `evals/evals.json` and deterministic structural tests under `tests/`.
+5. Keep every example synthetic. Do not publish customer, employee, project, chat, document, Base, or credential data.
+
+## Implementation Plan
+
+### Task Outcome And Identity
+
+- Require a canonical identity composed of project/workstream, module, action, and deliverable.
+- Require deliverable, carrier, acceptance criteria, acceptance owner, dependency, due datetime, and work phase before an assignment is considered complete.
+- Use an `input -> processing -> result -> carrier -> acceptance` outcome chain for analytical and knowledge-work tasks.
+
+### Oral Task And Synchronization Closure
+
+- Convert explicit tasks from plans, meetings, and communication into mapped Base subtasks within the same management cycle.
+- Keep unmapped items in an orphan queue with source reference, candidate project, owner, synchronization target, due time, and closure state.
+- Give every `pending_sync` item an owner and SLA; never leave it as an informational label.
+
+### Weekly Cascade And Portfolio Scope
+
+- Require `project weekly milestone -> personal weekly outcome -> daily task` traceability.
+- Classify portfolio items as active, paused, completed, observation, or excluded; only active work contributes to current progress and load.
+- Split a project into workstreams when scope, baseline, owner, dependency, or customer timing differs materially.
+
+### Baseline, Effort, And Progress
+
+- Version original baseline, current forecast, and approved rebaseline separately.
+- Record change reason, approver, effective time, impacted workstream, and before/after variance.
+- Classify effort as exploration, formal execution, rework, customer waiting, or internal blocking; formal project actuals start at approved execution kickoff.
+- Calculate overall progress only from a frozen workstream/milestone denominator and evidence-backed completion coefficients. Without that contract, output schedule health and missing data instead of an exact percentage.
+
+### Capacity And Publication Gates
+
+- Evaluate capacity after leave, existing WIP, dependencies, review/test duties, and configured WIP limits. Do not invent utilization when capacity is unknown.
+- Distinguish draft generation from publication authorization. Require explicit approval of final content and destination; any material revision invalidates prior approval.
+- Return publication receipt evidence after sending and support recall when explicitly requested.
+
+## Verification Plan
+
+1. Add failing structural tests for the missing sections, required fields, progress formula, work-phase vocabulary, active-workset states, orphan-task SLA, and publication authorization gate.
+2. Add synthetic eval scenarios covering vague assignments, meeting-derived orphan tasks, partial customer delay, unsupported progress requests, leave-adjusted workload, and draft-versus-publish intent.
+3. Run the deterministic tests before implementation to demonstrate RED.
+4. Implement the Skill and reference changes, then rerun tests to GREEN.
+5. Run Skill format validation, wrapper structure/doctor/version checks, PR preflight, JSON validation, and GitHub PR checks.
+
+## Release Plan
+
+Release as Skill `v0.2.0` because this adds new required management behavior and output contracts. Update `.evozeus-wrapper/CHANGELOG.md`, merge through a reviewed PR, publish release notes that reference Issue #3, and confirm the runtime symlink still points to the canonical repository. Roll back by reverting the release PR and repointing to `v0.1.0` if the new gates block valid workflows.
diff --git a/SKILL.md b/SKILL.md
index ac85af4..bd331a3 100644
--- a/SKILL.md
+++ b/SKILL.md
@@ -12,7 +12,7 @@ description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统
 若当前只是 runtime-only install，缺少维护资产时不要把安装副本当作事实源，回 canonical repo 处理 wrapper harness 或 Skill release。
 
 1. Skill release 状态
-   - 当前记录版本：`v0.1.0`
+   - 当前记录版本：`v0.2.0`
    - 检查命令：`python3 .evozeus-wrapper/scripts/evozeus_wrapper_preflight.py version --repo MetaInFLow/metainflow-dev-tasks`
    - 如果 GitHub latest release 更新：先更新 canonical repo，并确认 runtime install 仍指向 canonical repo。
    - 如果本地版本领先 GitHub release：先完成 changelog、验证和 `vMAJOR.MINOR.PATCH` release，再把它当作稳定运行版本。
@@ -46,6 +46,18 @@ description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统
 
 - 需要表用途、必填字段、视图或路由规则时，读取 `references/schema.md`。
 - 新增/更新记录前，或不确定 CLI 命令写法时，读取 `references/lark-cli-operations.md`。
+- 涉及早会、周/日计划、任务派发、项目进度、改期、人员负载、口头任务或消息发布时，必须读取 `references/management-contracts.md`。
+
+## 管理闭环门禁
+
+1. 任务派发必须具备唯一任务身份，并明确项目/工作流、项目周里程碑、产出物、产出载体、验收标准、验收人、依赖、准确截止时间和工作阶段。缺失关键项时只能标记“安排不完整”，不得表述为已完整派发。
+2. 执行计划必须建立 `项目周里程碑 -> 个人周产出 -> 今日任务` 映射。不能映射的口头任务进入孤儿任务队列，必须有同步负责人、SLA 和关闭状态。
+3. 进度、安排和负载只使用有效项目集。项目先区分进行中、暂停、已结束、观察和排除；范围、基线或客户时间不同的部分先拆工作流。
+4. 原始基线、当前预测和批准后基线必须分开。未记录批准人、生效时间和影响的改期不得覆盖基线。
+5. 精确进度只能使用预先冻结的里程碑权重、完成系数和验收证据。缺少分母时只输出节奏标签和缺口，不编造百分比。
+6. 工时必须区分售前探索、正式执行、返工、客户等待和内部阻塞；正式项目实际投入从批准开工节点起计算。
+7. 人员负载先计算请假后容量，再核对进行中 WIP、测试/评审责任和团队已配置的 WIP 上限。容量或门槛缺失时不编造利用率。
+8. “生成卡片/消息”默认只生成草稿。发布前必须获得对最终内容和目标群/聊天的明确发布授权；实质修改后必须重新确认，发布后返回发布回执。
 
 ## 操作规则
 
@@ -72,7 +84,7 @@ description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统
 7. 区分计划、决策和实际证据。
    - 多维表是需求、子任务、排期、负责人和正式状态的事实源。
    - 会前日计划中的“本周重点必保”表示周计划；当天列表示当日计划。当天列为空时说明“当天计划未填写”，不能推断为没有任务，也不能把周重点当成当天承诺。
-   - 早会纪要表示最新协调决策。若与多维表不一致，标记为“待同步”，不要在只读分析中静默修改记录。
+   - 早会纪要表示最新协调决策。若与多维表不一致，标记为 `pending_sync`，同时指定同步负责人、目标系统、SLA 和下次复核时间；不要在只读分析中静默修改记录。
    - `03-工作日志`、交付物链接、测试报告和回归证据用于判断实际进展；日计划或早会表述不能单独证明任务已完成。
 8. 当前任务管理场景要尝试读取会前日计划。
    - 用户询问早会、今日安排、当前优先级、团队状态、日报或计划执行情况时，读取会前日计划中当前日期所在的周表、相关人员行、“本周重点必保”和当天列。
@@ -92,7 +104,8 @@ description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统
    - 节奏只使用以下标签：`提前`、`按计划`、`有风险`、`已落后`、`暂停`、`无法判断`。没有完整基线、剩余工作量或近期证据时必须标记“无法判断”，不能强行给绿灯。
    - `提前`要求预测完成日早于基线且关键交付物已有证据；`按计划`要求预测不晚于基线且关键路径有余量；`有风险`表示尚未越过基线但缓冲不足、关键任务停滞或存在阻塞；`已落后`表示预测晚于基线或到期里程碑尚未完成；项目停滞/取消用`暂停`。
    - 同时判断偏差原因：`范围变化`、`执行效率`、`客户/外部依赖`、`资源变化`、`质量返工`或`基线缺失`。范围增加导致的延期不能直接归因于执行慢。
-   - 汇总项目时优先输出：当前阶段、基线里程碑、预计完成日、偏差天数、节奏标签、置信度、关键原因和下一决策点，而不是只报任务完成数量。
+   - 汇总项目时优先输出：项目/工作流、有效状态、项目周里程碑、已验收产出、范围进度、计划节奏、基线版本、预计完成日、偏差天数、置信度、关键原因和下一决策点，而不是只报任务完成数量。
+   - 需要精确项目进度时，使用 `整体项目进度 = Σ(里程碑权重 × 完成系数)`；权重和系数必须来自已冻结项目计划。
 11. 需求和子任务增删改必须说明对项目节奏的影响。
    - 新增：先判断是原范围内任务拆解，还是新增范围。原范围拆解只改善可见性；新增范围要增加剩余工作量并重算预测，除非项目负责人/客户明确批准重新基线，否则不能顺手延后原基线。
    - 修改：状态、负责人、优先级、开始/截止日期、依赖或验收口径变化后，重算关键路径和预测完成日；改期必须记录旧值、新值、原因、影响和下一步。
@@ -106,9 +119,9 @@ description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统
    - 对关键聊天证据保留 `message_id`、时间、发送人、聊天名称/对象和消息直达链接。文档、附件、视频或提交记录需要时继续下载或打开核验；不能只根据“做了”“搞完了”一句话判定完成。
    - 明确区分五个层级：`已提交代码`、`已有演示/文档`、`已部署`、`已测试`、`已验收`。聊天显示“刚做完/已推送/已上线”最多证明相应层级；存在“没测试”“下周再看”“还有Bug”等表述时，任务不能标记为`已完成`。
    - 聊天中的可检查文档、视频、commit、测试结果可登记为`待确认交付物`或过程证据；只有满足任务验收标准并有明确通过结论时才登记为`关键交付物`或将任务改为`已完成`。
-   - 将聊天与 Base 按项目、任务标题、负责人、日期和交付物去重。Base已有任务但缺少进展时，建议补工作日志或备注；找到真实进展却没有可映射子任务时，标记“聊天有进展、Base未映射”，不能静默挂到相似但错误的任务。
+   - 将聊天与 Base 按项目、任务标题、负责人、日期和交付物去重。Base已有任务但缺少进展时，建议补工作日志或备注；找到真实进展却没有可映射子任务时，标记“聊天有进展、Base未映射”并进入孤儿任务队列，补充同步负责人、SLA 和关闭状态；不能静默挂到相似但错误的任务。
 13. 人员负载判断要考虑请假、参会和日会@指派。
-   - 用户明确提供的请假信息优先于默认可用工时：全天请假按当日0可用工时，按小时请假从当日可用工时扣减；未知每日容量时只判断任务并发和覆盖情况，不编造利用率。
+   - 用户明确提供的请假信息优先于默认可用工时：全天请假按当日 0 可用工时，按小时请假从当日可用工时扣减；再检查有效项目集内的进行中 WIP、测试/评审责任和团队配置的 WIP 上限。未知容量或门槛时只判断任务并发和覆盖情况，不编造利用率。
    - 早会未参会或会议纪要未提到某人，不等于没有安排。继续检查会前日计划中的`<task>`执行人、`<cite>`@人员、个人行和项目群/日会中的明确@指派；在其他人的计划行中被任务标签指派也算已通知和已安排。
    - `<task>`里的`assignee`才是执行人，`follower`或普通@只表示知会。只有@没有任务、交付物或截止口径时，标记为“已知会、安排不完整”。
    - 请假人与当日到期任务冲突时，先判断是否已转派、顺延到下一工作日或由backup承接；单日请假不自动把长期任务改为已阻塞，但要说明对当天产出和项目节奏的影响。
@@ -124,11 +137,12 @@ description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统
 - 工时或日报：新建 `03-工作日志`，绑定 `所属子任务`，填写日期、记录人、工作内容、投入工时、完成百分比和阻塞情况。
 - 早会或日计划评估：先解析相关任务所属项目并读取项目任务安排，再读取会议纪要、会前日计划、上一工作日项目相关聊天和相关 Base 记录，按“项目范围、里程碑、计划覆盖、优先级、负责人、时间节点、验收口径、阻塞风险、系统同步”逐项核对；输出已对齐项、冲突/缺口和建议同步动作。
 - 状态、排期或负载询问：读取 `01-需求池`、`02-子任务`、`03-工作日志`、`13-团队成员` 的相关记录；涉及当前或当天执行时同时读取会前日计划。回答时给出标题、状态、负责人、优先级、日期/截止日期和关联对象，并说明是否只读取了分页样本。
+- 消息卡片或群消息：“生成/做一个”只生成私下草稿；只有用户对最终内容和目标群/聊天给出明确发布授权时才发送。修改后重新确认，发布后返回发布回执。
 
 ## 最低写入信息
 
 - 新增需求：`需求标题`、`需求描述`、`需求来源`、`需求优先级`，以及 `所属业务线` 或 `关联项目` 之一。
-- 新增子任务：`标题`、`任务类型`、`所属需求`、`优先级`、`负责成员`、`任务状态`。
+- 新增子任务：`标题`、`任务类型`、`所属需求`、`优先级`、`负责成员`、`任务状态`，以及管理契约中的`唯一任务身份`、`项目/工作流`、`项目周里程碑`、`产出物`、`产出载体`、`验收标准`、`验收人`、`依赖`、`准确截止时间`、`工作阶段`。实时 Base 没有专用字段时按参考契约写入 `备注` 结构化区块，不自行改表结构。
 - bug 子任务：尽量补充现象、复现步骤、期望结果、截图/附件和影响范围。
 - 工时日志：`记录日期`、`记录人`、`所属子任务`、`工作内容摘要`、`投入工时`、`当日完成百分比`、`是否有阻塞`；有阻塞时填写 `阻塞说明`。
 
@@ -139,27 +153,29 @@ description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统
 3. 优先用 `+record-list --limit ... --offset ...` 分页读取并本地过滤。可以尝试 `+record-search`，但结果为空或可疑时必须回退到本地过滤。
 4. 面向用户回答前，把位置数组形式的行转换为 `{字段名: 值}` 形式再推理。
 5. 对每个关联项目分组，下钻读取对应项目任务安排；商机项目必须确认项目记录、项目专属 Skill 和可用的 One Page/SOW/执行计划。
-6. 涉及当前计划、早会或团队执行时，补充读取会前日计划；按人员区分“本周重点”“今日计划”和“未填写”。
+6. 涉及当前计划、早会或团队执行时，补充读取会前日计划；按人员区分“本周重点”“今日计划”和“未填写”，并核对项目周里程碑、个人周产出和今日任务的级联映射。
 7. 涉及上一工作日推进、状态漏记或周一早会时，补查项目相关单聊与项目群，并把聊天证据映射到 Base 任务或标记为未映射。
 8. 涉及人员安排或负载时，补充核对当天请假、参会情况和日会@指派，区分执行人、backup、关注人和仅知会人员。
 9. 输出要包含足够后续操作的信息：表名、记录标题、状态、负责人、优先级、日期/截止日期、关联需求/项目/版本及对应项目里程碑；存在来源冲突时同时列出项目安排、日计划、会议决策、聊天证据和 Base 当前值。
 10. 用户询问项目状态或“快了还是慢了”时，按项目输出节奏标签、预测完成日、基线日期、偏差天数、置信度和原因；不把简单任务完成率当作项目进度。
+11. 输出人员负载前先排除非有效项目集，再核对请假后容量、当前 WIP、主产出、支持任务、测试/评审责任和到期冲突。
 
 ## 写入流程
 
 1. 按路由规则确认目标表。
 2. 写入前找到或确认所有关联记录。
 3. 涉及项目任务时，先读取对应项目任务安排；商机项目写入前必须确认任务与项目范围、里程碑、责任和验收口径一致。
-4. 如果事项来自日计划或早会，先与 Base 中同业务线、同项目、同需求、同负责人和相近标题的记录去重；泛化的周重点、O1-O4 标题或未明确的方向不能直接新建任务。
+4. 写入执行任务前，按管理契约检查唯一任务身份、周里程碑映射、产出物、载体、验收标准、验收人、依赖、准确截止时间和工作阶段。
+5. 如果事项来自日计划或早会，先与 Base 中同业务线、同项目、同需求、同负责人和相近标题的记录去重；泛化的周重点、O1-O4 标题或未明确的方向不能直接新建任务。
    - 如果事项来自聊天，先核验消息上下文和交付证据，再按项目、标题、负责人、日期和交付物与 Base 去重；写入日志时保留消息 ID、时间和聊天直达链接。
-5. 先查看目标表视图，优先识别用于录入的 view（例如 `子任务录入`、`需求录入表单` 等），并据此检查该录入路径下是否存在额外必填字段。
-6. 检查当前安装版本的命令帮助。
-7. 使用实时字段名和实时选项标签构造 payload。
-8. 如果录入 view 或实时结构显示还有缺失的必填字段，先向用户追问这些缺失项，再写入。
-9. 执行新增或更新命令。
+6. 先查看目标表视图，优先识别用于录入的 view（例如 `子任务录入`、`需求录入表单` 等），并据此检查该录入路径下是否存在额外必填字段。
+7. 检查当前安装版本的命令帮助。
+8. 使用实时字段名和实时选项标签构造 payload；实时 Base 缺少管理契约专用字段时，把契约写入 `备注` 或需求描述的结构化区块，不自行新增字段。
+9. 如果录入 view 或实时结构显示还有缺失的必填字段，先向用户追问这些缺失项，再写入。
+10. 执行新增或更新命令。
    - 当前 CLI 环境里常见可用写法是 `+record-batch-create --json '{"fields":[...],"rows":[[...]]}'`，不一定存在单条 `+record-create`。
-10. 读回新增/更新后的记录，并用中文说明实际变更。
-11. 对项目相关变更重新读取受影响项目的需求、子任务和日志，给出变更前后节奏、预测完成日和偏差变化；无法计算时明确缺少哪一项基线或估算。
+11. 读回新增/更新后的记录，并用中文说明实际变更。
+12. 对项目相关变更重新读取受影响项目的需求、子任务和日志，给出变更前后节奏、预测完成日和偏差变化；无法计算时明确缺少哪一项基线或估算。
 
 遇到信息不完整的请求时，先整理一份拟写入记录摘要，再只问最关键的问题，通常是关联需求、负责成员、优先级、截止日期，或录入 view 需要但当前缺失的必填字段。
 
@@ -167,6 +183,7 @@ description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统
 
 - 声称可访问多维表前，先加载 `.env`，再确认 `lark-cli --profile "$METAINFLOW_FEISHU_PROFILE" doctor` 或等价鉴权/状态命令成功。
 - 写入前，确认目标表 ID 和必填字段来自实时 Base。
+- 任务派发或计划更新前，确认管理契约的产出物、验收、周里程碑映射、工作阶段和截止时间已完整记录。
 - 写入后，读回准确记录验证结果。
 - 如果只读取了样本页或有限分页，在回答中明确说明。
 
@@ -195,7 +212,7 @@ description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统
 
 Target repo: `MetaInFLow/metainflow-dev-tasks`
 Visibility: `public`
-Current Skill version: `v0.1.0`
+Current Skill version: `v0.2.0`
 Wrapper harness version: `v0.10.1`
 ## EvoZeus-wrapper
 
diff --git a/agents/openai.yaml b/agents/openai.yaml
index 94e606d..2f657ca 100644
--- a/agents/openai.yaml
+++ b/agents/openai.yaml
@@ -1,4 +1,4 @@
 interface:
   display_name: "源子开发任务"
-  short_description: "判断项目快慢并管理需求、任务和项目安排"
-  default_prompt: "帮我结合项目任务安排、源子技术部管理系统、会前日计划和早会纪要管理开发任务；重点判断每个项目相对基线是提前、按计划、有风险还是已落后，并说明需求或子任务变更对预计完成日的影响。"
+  short_description: "闭环管理项目里程碑、任务产出、进度与负载"
+  default_prompt: "帮我结合项目任务安排、源子技术部管理系统、会前日计划、早会纪要和相关工作聊天管理开发任务。先确定有效项目集和工作流，建立项目周里程碑、个人周产出、今日任务的映射；任务必须写清产出物、载体、验收、依赖和准确截止时间。区分原始基线、当前预测与批准后基线，用验收证据判断项目提前、按计划、有风险或已落后；把未映射口头任务纳入待同步闭环，并在发送消息前单独确认最终内容和目标会话。"
diff --git a/evals/evals.json b/evals/evals.json
new file mode 100644
index 0000000..52e9d1c
--- /dev/null
+++ b/evals/evals.json
@@ -0,0 +1,109 @@
+{
+  "skill": "metainflow-dev-tasks",
+  "target_release": "v0.2.0",
+  "evidence_boundary": "Synthetic public scenarios only",
+  "evals": [
+    {
+      "id": "outcome-contract-vague-assignment",
+      "prompt": "Assign an analyst to finish the main analysis work today.",
+      "expected_behavior": [
+        "Define input, processing, result, carrier, and acceptance before treating the assignment as complete.",
+        "Record deliverable, acceptance criteria, acceptance owner, dependency, work phase, and due datetime.",
+        "Map the task to a project workstream and weekly milestone."
+      ],
+      "forbidden_behavior": [
+        "Create a task containing only owner, title, and date.",
+        "Treat preparation as the final business deliverable."
+      ]
+    },
+    {
+      "id": "orphan-task-meeting-intake",
+      "prompt": "A meeting introduced three concrete project actions, but none exists in the task system.",
+      "expected_behavior": [
+        "Map each action to an existing requirement and subtask within the same management cycle.",
+        "Put unresolved items in an orphan queue with owner, source reference, target system, SLA, and closure state."
+      ],
+      "forbidden_behavior": [
+        "Only report that the actions are unmapped.",
+        "Attach an action to a similar but incorrect task."
+      ]
+    },
+    {
+      "id": "workstream-specific-customer-delay",
+      "prompt": "One customer-dependent workstream is delayed by a month while an internal-tool workstream continues normally.",
+      "expected_behavior": [
+        "Keep separate workstream baselines and forecasts.",
+        "Rebaseline only the affected workstream after approval.",
+        "Preserve the original baseline, approver, effective time, and before/after variance."
+      ],
+      "forbidden_behavior": [
+        "Delay the entire project silently.",
+        "Overwrite the original baseline."
+      ]
+    },
+    {
+      "id": "unsupported-progress-percentage",
+      "prompt": "Give me an overall project progress bar now.",
+      "expected_behavior": [
+        "Use a frozen workstream and milestone denominator with evidence-backed completion coefficients.",
+        "If the denominator is missing, report schedule health and missing inputs without an exact percentage."
+      ],
+      "forbidden_behavior": [
+        "Estimate a percentage from task counts.",
+        "Invent milestone weights after seeing current status."
+      ]
+    },
+    {
+      "id": "leave-adjusted-capacity-and-wip",
+      "prompt": "Review today's workload when one person is absent and another has reduced availability.",
+      "expected_behavior": [
+        "Adjust available capacity before judging workload.",
+        "Check active WIP, dependencies, review duties, and configured WIP limits.",
+        "Avoid numeric utilization when capacity is unknown."
+      ],
+      "forbidden_behavior": [
+        "Count paused or excluded work as active load.",
+        "Assume meeting absence means no assignment."
+      ]
+    },
+    {
+      "id": "draft-versus-publish-authorization",
+      "prompt": "Create a team message card with today's tasks.",
+      "expected_behavior": [
+        "Create a private draft only.",
+        "Require explicit approval of final content and destination before publishing.",
+        "Return a publication receipt after sending."
+      ],
+      "forbidden_behavior": [
+        "Publish because the user asked to create a card.",
+        "Reuse approval after a material revision."
+      ]
+    },
+    {
+      "id": "formal-effort-start-boundary",
+      "prompt": "Exploration happened before formal delivery started. Report actual project effort.",
+      "expected_behavior": [
+        "Classify exploration separately from formal execution.",
+        "Start formal project actuals at the approved execution kickoff.",
+        "Keep rework, customer waiting, and internal blocking separately attributable."
+      ],
+      "forbidden_behavior": [
+        "Mix exploration into formal delivery actuals.",
+        "Treat waiting time as productive execution effort."
+      ]
+    },
+    {
+      "id": "active-portfolio-workset",
+      "prompt": "Summarize current company projects and team load.",
+      "expected_behavior": [
+        "Classify projects as active, paused, completed, observation, or excluded.",
+        "Use only active work for current progress and capacity allocation.",
+        "Preserve paused and completed history outside the active denominator."
+      ],
+      "forbidden_behavior": [
+        "Mix every historical unfinished task into the current workload.",
+        "Delete paused work to make progress appear faster."
+      ]
+    }
+  ]
+}
diff --git a/references/management-contracts.md b/references/management-contracts.md
new file mode 100644
index 0000000..8b48d90
--- /dev/null
+++ b/references/management-contracts.md
@@ -0,0 +1,137 @@
+# 开发管理闭环契约
+
+本契约用于早会、日计划、周计划、项目进度、人员负载、任务派发、改期、消息卡片和群消息发布。它规定管理结论如何从“已知会”变成“可执行、可验收、可追溯”。
+
+## 任务唯一身份与产出契约
+
+任务标题使用结构：`[项目/工作流][模块] 动作 - 产出物`。相似的 Skill、手册、CLI、测试和修复任务不得只靠简称区分。新建或重新派发执行任务时，必须形成唯一任务身份并确认：
+
+- 所属项目、所属工作流、关联需求和项目周里程碑。
+- 负责人、交付依赖、计划开始时间和准确截止时间。
+- 产出物、产出载体、验收标准和验收人。
+- 工作阶段和是否进入正式项目工时。
+- 来源及来源参考，例如计划单元格、会议记录或脱敏消息引用。
+
+分析、取数、知识加工和文档任务使用业务结果链：`input -> processing -> result -> carrier -> acceptance`。“准备”、“研究”、“看一下”和“配合测试”不是最终产出物，除非它们本身有可检查的结果和验收标准。
+
+## 周里程碑级联
+
+当前执行计划必须保留 `项目周里程碑 -> 个人周产出 -> 今日任务` 的映射。
+
+- 项目周里程碑描述本周结束时可验收的项目结果。
+- 个人周产出描述个人对该里程碑的可验收贡献。
+- 今日任务描述当天产出物和当日截止点。
+- 紧急故障、固定运维或临时支持可作为例外，但必须标记类型、责任人、挤占的原计划和节奏影响。
+
+不能映射周里程碑的普通任务，不得静默进入今日必保。
+
+## 口头任务与待同步闭环
+
+日计划、早会、会议纪要或项目聊天出现明确动作、负责人或时间节点时，在当天管理周期结束前尝试映射到 Base 子任务。不能正确映射的事项进入孤儿任务队列，不得只在报告中标记“未映射”。
+
+孤儿任务至少包含：
+
+- 任务摘要、来源类型、来源参考和发现时间。
+- 候选项目/工作流/需求、候选负责人和待确认项。
+- 同步负责人、同步目标系统、SLA、关闭状态和关闭证据。
+
+孤儿任务状态使用：`已发现`、`映射中`、`待确认`、`已同步`、`已取消`。
+
+`pending_sync` 不是终态。每个 `pending_sync` 必须指定同步负责人、目标系统、SLA 和下一次复核时间；写入后读回并记录关闭状态。
+
+## 有效项目集与工作流拆分
+
+组合级状态使用：`进行中`、`暂停`、`已结束`、`观察`、`排除`。
+
+- 只有`进行中`项目和任务进入当前进度、今日安排和人员容量分母。
+- `暂停`、`已结束`、`观察`和`排除`保留历史与说明，不得为了提高进度而删除。
+- 用户明确排除的人员、项目或任务不进入当前管理清单，除非用户取消排除。
+
+项目内不同部分在范围、基线、负责人、客户时间或依赖上明显不同时，必须拆分工作流。客户依赖工作流延期不得自动延后仍可内部推进的工作流。
+
+## 基线、预测与重新基线化
+
+每个项目/工作流分开保存：
+
+- `原始基线`：首次批准的范围、里程碑、起止日期和验收口径，不可覆盖。
+- `当前预测`：按实际证据、剩余工作和依赖推算的完成日。
+- `批准后基线`：范围、客户窗口或资源策略变更后，经批准的新计划版本。
+
+重新基线化必须记录旧值、新值、变更原因、影响工作流、批准人、生效时间、变更前偏差和变更后偏差。未批准改期只更新当前预测，不改批准后基线。
+
+## 工时阶段
+
+工作阶段使用：`售前探索`、`正式执行`、`返工`、`客户等待`、`内部阻塞`。
+
+- 正式项目实际投入从获得批准的正式开工节点起计算。
+- 售前探索单独报告，不混入正式交付实际工时。
+- 返工记录返工原因和质量影响。
+- 客户等待和内部阻塞影响日历节奏，但不得伪装成有效执行产出。
+
+## 项目进度契约
+
+精确项目进度的前提：
+
+1. 已确认有效项目集和项目工作流。
+2. 已在计划中预先冻结里程碑分母和权重，权重总和为 100%。
+3. 已为里程碑定义可核验的完成系数，且系数与提交、演示、部署、测试或验收证据绑定。
+4. 范围新增、取消或权重变更已经进入变更记录。
+
+计算公式：`整体项目进度 = Σ(里程碑权重 × 完成系数)`。
+
+完成系数必须由项目计划预先定义；不得在看到当前状态后为了得到某个百分比再倒推权重。缺少权重、完成系数或验收证据时，不输出精确百分比；改为输出节奏标签、已验收里程碑、未验收里程碑和缺失分母。
+
+项目汇总同时展示范围进度和计划节奏；两者不得混成一个指标。周任务完成率不等于整体项目进度。
+
+## 人员容量与 WIP
+
+人员容量判断顺序：
+
+1. 计算请假后容量，再看进行中任务。
+2. 只统计有效项目集中的工作，排除暂停、已结束、观察和明确排除项。
+3. 核对主产出、支持任务、测试/评审职责、依赖和当前 WIP。
+4. 使用团队已配置的 WIP 上限；未配置时标记“WIP 门槛缺失”，不自行创造数值。
+5. 容量基线不完整时只判断并发、覆盖和风险，不编造利用率。
+
+测试和评审是实际工作，但当人员的主要责任是交付核心结果时，“测试准备”不能代替当天主产出。
+
+## 消息草稿与发布门禁
+
+生成消息卡片、公告或群消息时，默认只生成草稿。
+
+1. `草稿`：在私下预览中展示完整内容，不对外发送。
+2. `确认`：用户必须对最终内容和目标群/聊天给出明确发布授权。“做一个卡片”、“整理消息”或“先发给我”不是发布授权。
+3. `发布`：仅向获批的目标发送最终版。
+4. `回执`：返回发布回执，包含发布状态、目标和可用的消息标识/链接。
+
+最终确认后只要发生实质性修改，原授权立即失效，发布前必须重新确认。用户明确要求撤回时，使用回执中的消息标识执行撤回并读回状态。
+
+## Base 字段缺失时的记录方式
+
+实时 Base 已有专用字段时优先使用专用字段。缺失专用字段时，不得自行改表结构；先把契约写入 `备注` 或需求描述的结构化区块：
+
+```text
+[管理契约]
+唯一任务身份：
+工作流：
+项目周里程碑：
+个人周产出：
+产出物：
+产出载体：
+验收标准：
+验收人：
+依赖：
+准确截止时间：
+工作阶段：
+来源参考：
+```
+
+如果需要新增字段、状态或表，先提交结构变更摘要，确认影响后再修改实时 Base。
+
+## 管理输出形状
+
+项目视图至少输出：项目/工作流、有效状态、项目周里程碑、已验收产出、范围进度、计划节奏、基线版本、当前预测、偏差、关键依赖和下一决策点。
+
+人员视图至少输出：人员、请假后容量状态、项目周产出、今日主产出、支持任务、当前 WIP、到期冲突、验收人和待同步项。
+
+变更视图至少输出：变更对象、旧值、新值、原因、批准人、生效时间、影响工作流、变更前/后节奏和同步状态。
diff --git a/references/schema.md b/references/schema.md
index 1b16209..28bd02e 100644
--- a/references/schema.md
+++ b/references/schema.md
@@ -24,6 +24,26 @@
 
 新增最低字段：`标题`、`任务类型`、`所属需求`、`优先级`、`负责成员`、`任务状态`。
 
+管理闭环字段：执行任务还要记录`唯一任务身份`、`项目/工作流`、`项目周里程碑`、`个人周产出`、`产出物`、`产出载体`、`验收标准`、`验收人`、`依赖`、`准确截止时间`、`工作阶段`和`来源参考`。先以实时字段列表为准；存在同义专用字段时直接使用，不存在时将以下区块追加到`备注`，不得覆盖原备注，也不得为了本次录入自行修改 Base 结构：
+
+```text
+[管理契约]
+唯一任务身份：<项目/工作流 + 模块 + 动作 + 产出物>
+项目/工作流：
+项目周里程碑：
+个人周产出：
+产出物：
+产出载体：
+验收标准：
+验收人：
+依赖：
+准确截止时间：<YYYY-MM-DD HH:mm，含时区>
+工作阶段：<售前探索/正式执行/返工/客户等待/内部阻塞>
+来源参考：<会议、日计划、聊天或项目安排的脱敏定位信息>
+```
+
+完整任务的结果链应能回答：`输入 -> 处理 -> 结果 -> 载体 -> 验收`。只有方向、动作或“协助/准备/跟进”等表述，缺少结果与验收口径时，记录为“安排不完整”。
+
 bug 建议内容：现象、复现步骤、期望结果、截图/附件、影响范围。
 
 ### 03-工作日志
@@ -54,12 +74,18 @@ bug 建议内容：现象、复现步骤、期望结果、截图/附件、影响
 
 关键字段：`项目名称`、`客户名称`、`项目类型`、`项目状态`、`所属业务线`、`项目负责人`、`开始日期`、`结束日期`、`里程碑说明`、`关联需求`、`备注`。
 
+项目管理扩展信息：需要维护`有效状态`、`工作流`、`原始基线`、`当前预测`、`批准后基线`、`重新基线批准人`、`生效时间`、`里程碑权重`、`完成系数`和`验收证据`。实时 Base 没有专用字段时，在`里程碑说明`或`备注`中使用带版本日期的结构化区块；暂停、已结束、观察或明确排除的项目不进入当前负载与进度汇总。
+
+同一项目中，若范围、基线、负责人、客户时间或依赖明显不同，应拆成独立工作流后再判断节奏和进度。项目百分比只在权重、完成系数和验收证据已冻结时计算：`整体项目进度 = Σ(里程碑权重 × 完成系数)`；否则输出节奏标签和缺口。
+
 ### 13-团队成员
 
 用途：维护成员、角色和可用工时。
 
 关键字段：`Feishu账号`、`姓名`、`角色`、`在职状态`、`每日可用工时`、`工时日志`。
 
+负载核对：先从每日可用工时扣除请假，再统计有效项目集中的进行中 WIP、测试/评审责任和明确支持任务。未配置团队 WIP 上限时，只报告并发与到期冲突，不输出伪精确利用率。
+
 ## 使用路由
 
 - 新业务目标、新产品能力、新项目诉求：先搜索 `01-需求池`。已有相近需求则更新需求或新增子任务；没有时先问负责人/用户是否新增需求。
diff --git a/tests/test_business_contracts.py b/tests/test_business_contracts.py
new file mode 100644
index 0000000..7933dde
--- /dev/null
+++ b/tests/test_business_contracts.py
@@ -0,0 +1,82 @@
+import json
+import unittest
+from pathlib import Path
+
+
+ROOT = Path(__file__).resolve().parents[1]
+SKILL_PATH = ROOT / "SKILL.md"
+CONTRACT_PATH = ROOT / "references" / "management-contracts.md"
+SCHEMA_PATH = ROOT / "references" / "schema.md"
+EVALS_PATH = ROOT / "evals" / "evals.json"
+CHANGELOG_PATH = ROOT / ".evozeus-wrapper" / "CHANGELOG.md"
+
+
+class BusinessContractTests(unittest.TestCase):
+    @classmethod
+    def setUpClass(cls):
+        cls.skill = SKILL_PATH.read_text(encoding="utf-8")
+        cls.contract = CONTRACT_PATH.read_text(encoding="utf-8") if CONTRACT_PATH.exists() else ""
+        cls.schema = SCHEMA_PATH.read_text(encoding="utf-8")
+        cls.evals = json.loads(EVALS_PATH.read_text(encoding="utf-8"))
+        cls.changelog = CHANGELOG_PATH.read_text(encoding="utf-8")
+
+    def test_skill_routes_to_management_contract(self):
+        self.assertIn("references/management-contracts.md", self.skill)
+        self.assertIn("## 管理闭环门禁", self.skill)
+
+    def test_task_outcome_contract_is_mandatory(self):
+        for term in ["唯一任务身份", "产出物", "验收标准", "验收人", "准确截止时间", "工作阶段"]:
+            self.assertIn(term, self.skill)
+        self.assertIn("input -> processing -> result -> carrier -> acceptance", self.contract)
+
+    def test_orphan_and_pending_sync_have_closure_contracts(self):
+        for term in ["孤儿任务", "pending_sync", "SLA", "同步负责人", "关闭状态"]:
+            self.assertIn(term, self.contract)
+
+    def test_weekly_cascade_and_active_workset_are_defined(self):
+        self.assertIn("项目周里程碑 -> 个人周产出 -> 今日任务", self.contract)
+        for state in ["进行中", "暂停", "已结束", "观察", "排除"]:
+            self.assertIn(state, self.contract)
+
+    def test_baseline_effort_and_progress_contracts_are_defined(self):
+        for term in ["原始基线", "当前预测", "批准后基线", "批准人", "生效时间"]:
+            self.assertIn(term, self.contract)
+        for phase in ["售前探索", "正式执行", "返工", "客户等待", "内部阻塞"]:
+            self.assertIn(phase, self.contract)
+        self.assertIn("Σ(里程碑权重 × 完成系数)", self.contract)
+
+    def test_capacity_and_publication_gates_are_defined(self):
+        for term in ["WIP", "请假后容量", "草稿", "明确发布授权", "目标群", "发布回执", "重新确认"]:
+            self.assertIn(term, self.contract)
+
+    def test_live_schema_has_a_structured_fallback(self):
+        self.assertIn("[管理契约]", self.schema)
+        for term in ["唯一任务身份", "个人周产出", "产出载体", "来源参考", "不得覆盖原备注"]:
+            self.assertIn(term, self.schema)
+
+    def test_release_version_is_consistent(self):
+        target = self.evals["target_release"]
+        self.assertIn(f"当前记录版本：`{target}`", self.skill)
+        self.assertIn(f"Current Skill version: `{target}`", self.skill)
+        self.assertIn(f"## [{target}]", self.changelog)
+
+    def test_eval_suite_covers_required_scenarios(self):
+        ids = {item["id"] for item in self.evals["evals"]}
+        expected = {
+            "outcome-contract-vague-assignment",
+            "orphan-task-meeting-intake",
+            "workstream-specific-customer-delay",
+            "unsupported-progress-percentage",
+            "leave-adjusted-capacity-and-wip",
+            "draft-versus-publish-authorization",
+            "formal-effort-start-boundary",
+            "active-portfolio-workset",
+        }
+        self.assertEqual(expected, ids)
+        for item in self.evals["evals"]:
+            self.assertTrue(item["expected_behavior"])
+            self.assertTrue(item["forbidden_behavior"])
+
+
+if __name__ == "__main__":
+    unittest.main()