feat: add daily project management loop

.evozeus-wrapper/CHANGELOG.md

@@ -8,6 +8,35 @@ Wrapper harness migrations are recorded under `.evozeus-wrapper/docs/migrations/
 
 - No unreleased changes.
 
+## [v0.3.0] - 2026-07-22
+
+### Skill changes
+
+- Added a first-class daily project-management loop with `pre_standup`, `post_standup`, `approved_commit`, `approved_publish`, and `eod_close` modes.
+- Added deterministic phase routing, required source order, phase-specific outputs, mutation and publication authority, and missing-input recovery behavior.
+- Added consumer-workspace checkpoints for cross-run resume, source watermarks, mutation approvals, card fingerprints, publication receipts, and next decision points.
+- Added idempotency rules that prevent duplicate Base writes and duplicate card publication during scheduled retries.
+- Added a scheduled invocation adapter whose default policies are `proposal_only` and `private_draft`, with Monday weekly-establishment and Friday weekly-closure modifiers.
+- Added five synthetic evaluation scenarios and deterministic contract tests for the recurring daily loop.
+
+### Feedback / Issues
+
+- MetaInFLow/metainflow-dev-tasks#5: add a daily project-management operating loop.
+- Design: `.evozeus-wrapper/docs/designs/2026-07-22-daily-project-management-loop-v0.3.0.md`.
+
+### Verification
+
+- `python3 -m unittest discover -s tests -p 'test_*.py'`
+- JSON parsing for `evals/evals.json`.
+- `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, source-contract, and public-data boundary review.
+
+### Data boundary and rollback
+
+- Public artifacts use synthetic operating scenarios and contain no raw chats, customer records, internal links, production identifiers, Base tokens, or credentials.
+- Roll back by restoring the `v0.2.0` Skill release. Existing management contracts remain compatible; the daily orchestration layer and checkpoint contract are removed.
+
 ## [v0.2.0] - 2026-07-20
 
 ### Skill changes

.evozeus-wrapper/docs/designs/2026-07-22-daily-project-management-loop-v0.3.0.md

@@ -0,0 +1,96 @@
+# Daily Project Management Loop v0.3.0
+
+## Related Issue
+
+Related issue: MetaInFLow/metainflow-dev-tasks#5.
+
+## Optimization Goal
+
+Make recurring daily project management a first-class Skill feature. A run should enter a deterministic operating phase, reuse the prior checkpoint, gather only the evidence required for that phase, and produce the next decision-ready artifact without rediscovering the workflow.
+
+The Skill must own the operating behavior. A scheduler may trigger a phase, but it must not redefine evidence order, mutation authority, publication authority, or completion semantics.
+
+## Direction
+
+1. Add concise daily-loop routing and gates to `SKILL.md`.
+2. Add the detailed phase, checkpoint, idempotency, and automation adapter contracts to `references/daily-operations.md`.
+3. Reuse the existing management contracts for task identity, evidence, baseline, progress, capacity, and publication authorization.
+4. Keep scheduled runs proposal-only unless an explicit, still-valid approval is present in the current management cycle.
+5. Persist references and decisions in a local checkpoint; never persist raw private chat content, credentials, Base tokens, or customer records in the public Skill repository.
+
+## Operating Model
+
+### Phase 1: Pre-standup Scan
+
+- Establish the effective portfolio and workstreams.
+- Read the prior checkpoint, previous working-day chats, current week daily plan, Base tasks and logs, project plans, leave, and unresolved synchronization items.
+- Produce historical state-change candidates, milestone risks, orphan work, capacity gaps, and standup questions.
+- Do not mutate Base records or publish a group message.
+
+### Phase 2: Post-standup Reconciliation
+
+- Add the latest standup record and decisions to the evidence set.
+- Reconcile project plans, Base, daily plan, communication, and meeting decisions.
+- Produce a proposed mutation batch, the weekly-to-daily assignment map, and a private card draft.
+- Record conflicts, missing evidence, synchronization owners, and approval requirements.
+
+### Phase 3: Approved Commit And Publish
+
+- Apply only the approved mutation set, read every affected record back, and recalculate schedule health.
+- Publish only the approved final card to the approved destination.
+- A material content change invalidates publication approval.
+- Store mutation verification and publication receipt in the checkpoint.
+
+### Phase 4: End-of-day Closure
+
+- Recheck due milestones against code, document, demo, deployment, test, and acceptance evidence.
+- Separate submitted, demonstrated, deployed, tested, and accepted states.
+- Produce unfinished-item actions, tomorrow inputs, overdue or blocked changes, and Friday milestone closure when applicable.
+- Completion and acceptance remain evidence-gated.
+
+## Checkpoint Contract
+
+Use a consumer-workspace checkpoint keyed by local date and timezone. It records:
+
+- cycle date, timezone, completed phase, run ID, and source watermarks;
+- effective portfolio and workstream snapshot;
+- proposed mutations, approval state, applied mutation verification, and remaining conflicts;
+- orphan tasks and `pending_sync` ownership, SLA, and closure state;
+- card draft fingerprint, approved destination, approval state, publication receipt, and recall state;
+- next checkpoints and scheduled decision times.
+
+The checkpoint stores references and compact decisions, not raw private evidence. Re-running a phase with unchanged watermarks must reuse the existing result and avoid duplicate writes or messages.
+
+## Automation Adapter
+
+A scheduled invocation supplies the phase, cycle date, timezone, mutation policy, publication policy, and expected output channel. The default scheduled policies are `proposal_only` and `private_draft`.
+
+Recommended triggers:
+
+- Workday pre-standup scan; Monday adds weekly milestone establishment.
+- Workday post-standup reconciliation.
+- Workday end-of-day closure; Friday adds weekly milestone closure.
+
+Missing standup or plan inputs produce a named gap and a next retry condition. They never authorize fabricated facts, silent writes, or group publication.
+
+## Implementation Plan
+
+1. Add `references/daily-operations.md` with the phase matrix, input order, outputs, gates, checkpoint schema, idempotency key, recovery behavior, and scheduler prompt contract.
+2. Add a mandatory daily-loop section and intent routing to `SKILL.md`.
+3. Add synthetic regression scenarios for phase resume, scheduled proposal-only behavior, post-standup mutation proposals, end-of-day evidence recovery, and idempotent reruns.
+4. Extend deterministic tests to require the new reference, modes, checkpoint fields, automation policies, and version consistency.
+5. Update the changelog and release metadata to `v0.3.0`.
+
+## Verification Plan
+
+1. Add failing structural tests for the daily-loop entry modes, checkpoint, idempotency, scheduler adapter, proposal-only mutation policy, and private-draft publication policy.
+2. Run the existing test suite to demonstrate the missing feature.
+3. Implement the Skill, reference, eval, and release metadata changes.
+4. Run unit tests, JSON parsing, Skill format checks, wrapper structure, doctor, and version diagnostics.
+5. Keep public artifacts synthetic and confirm that no private source content or identifiers entered the change.
+
+## Release Plan
+
+Release as Skill `v0.3.0` because this adds a new recurring operating capability and invocation contract. Update `.evozeus-wrapper/CHANGELOG.md`, merge through a reviewed PR, publish a `v0.3.0` release referencing Issue #5, and confirm runtime installs still point to the canonical repository.
+
+Roll back by restoring `v0.2.0`. Existing management contracts remain compatible; only the daily orchestration layer is removed by rollback.

SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: metainflow-dev-tasks
-description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统」飞书多维表中的开发组任务，并结合对应项目任务安排、会前日计划、早会纪要和项目相关聊天核对范围、里程碑、承诺与实际进展；商机项目强制下钻项目安排。支持新增、查看、查询、分析和更新需求、子任务、bug、工时日志、项目、版本、业务线和成员负载。用户提到开发组任务、bug、需求、工时、日报、日计划、周计划、早会、今日安排、项目任务安排、商机项目、项目交付或版本规划时使用。
+description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统」飞书多维表中的开发组任务，并结合对应项目任务安排、会前日计划、早会纪要和项目相关聊天核对范围、里程碑、承诺与实际进展；商机项目强制下钻项目安排。支持会前扫描、会后校准、批准后写入/发布、日终收口和可幂等的定时调用，以及新增、查看、查询、分析和更新需求、子任务、bug、工时日志、项目、版本、业务线和成员负载。用户提到开发组任务、bug、需求、工时、日报、日计划、周计划、早会、今日安排、每日项目管理、定时检查、项目任务安排、商机项目、项目交付或版本规划时使用。
 ---
 
 ## EvoZeus-wrapper 状态检查
@@ -12,7 +12,7 @@ description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统
 若当前只是 runtime-only install，缺少维护资产时不要把安装副本当作事实源，回 canonical repo 处理 wrapper harness 或 Skill release。
 
 1. Skill release 状态
-   - 当前记录版本：`v0.2.0`
+   - 当前记录版本：`v0.3.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，再把它当作稳定运行版本。
@@ -47,6 +47,7 @@ description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统
 - 需要表用途、必填字段、视图或路由规则时，读取 `references/schema.md`。
 - 新增/更新记录前，或不确定 CLI 命令写法时，读取 `references/lark-cli-operations.md`。
 - 涉及早会、周/日计划、任务派发、项目进度、改期、人员负载、口头任务或消息发布时，必须读取 `references/management-contracts.md`。
+- 涉及“开始今天的项目管理”、连续工作日复核、会前/会后/日终操作、跨运行恢复或定时调用时，必须读取 `references/daily-operations.md`。
 
 ## 管理闭环门禁
 
@@ -59,6 +60,18 @@ description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统
 7. 人员负载先计算请假后容量，再核对进行中 WIP、测试/评审责任和团队已配置的 WIP 上限。容量或门槛缺失时不编造利用率。
 8. “生成卡片/消息”默认只生成草稿。发布前必须获得对最终内容和目标群/聊天的明确发布授权；实质修改后必须重新确认，发布后返回发布回执。
 
+## 每日项目管理闭环
+
+1. 连续项目管理不重新发明流程。先读当日检查点，再在 `pre_standup`、`post_standup`、`approved_commit`、`approved_publish` 和 `eod_close` 中选择唯一模式。
+2. `pre_standup` 执行会前扫描：复用上一检查点，读前一工作日聊天、当周日计划、Base、项目任务安排、工作日志和请假；输出状态候选、孤儿任务、项目风险、人员缺口和早会必问项。
+3. `post_standup` 执行会后校准：加入早会纪要/妙记、会后 @ 指派和新聊天；输出冲突、拟变更批次、项目周里程碑到今日任务的映射和私下卡片草稿。
+4. `approved_commit` 只处理用户已批准的变更 ID。写入前重读旧值，写入后逐条读回，再计算受影响项目的预测和偏差。
+5. `approved_publish` 只发布用户已批准指纹的最终卡片，且目标会话必须已明确。发布后把消息标识、目标和时间写入回执。
+6. `eod_close` 执行日终收口：把当日到期产出区分为已提交代码、已有演示/文档、已部署、已测试和已验收，输出未闭环动作、负责人、下次复核和明日输入。
+7. 每次运行都要更新消费者工作区的当日检查点，保存来源水位、有效项目集、拟变更、批准状态、卡片指纹、发布回执和下一检查点；不把原始私聊正文或凭证写入公开仓库。
+8. scheduled 定时调用必须传入显式 `mode`、`cycle_date` 和 `timezone`，并使用 `proposal_only` 和 `private_draft`。定时运行不自动翻状态、改基线、标记验收或群发布。
+9. 每次写入或发送都使用检查点生成的幂等键。相同来源水位和相同批准内容已成功时，直接返回旧结果，禁止重复写入或重复发送。
+
 ## 操作规则
 
 1. 先发现实时表结构，再写入或下结论。
@@ -128,6 +141,7 @@ description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统
 
 ## 意图路由
 
+- “开始今天的项目管理”、“按今天流程跑”或定时检查：读取 `references/daily-operations.md` 和当日检查点，选择会前扫描、会后校准、批准后写入、批准后发布或日终收口模式；跨运行复用检查点，定时调用保持只读分析与私下草稿。
 - 新业务目标、新产品能力、新项目诉求或长期事项：先识别业务线，再搜索该业务线下的 `01-需求池`；已有相近需求则补充信息或新增子任务；只有确认后才新建需求。
 - bug、截图反馈、线上异常：先识别业务线，再按该业务线内的模块、项目、版本或长期事项搜索 `01-需求池`；在 `02-子任务` 新建一条 `任务类型=bug` 的记录并绑定 `所属需求`。
 - 小优化、运维、排查、临时支持：绑定到该业务线下的已有长期需求，例如运维类、项目支持类或业务线优化类需求；然后新建 `02-子任务`。
@@ -185,6 +199,7 @@ description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统
 - 写入前，确认目标表 ID 和必填字段来自实时 Base。
 - 任务派发或计划更新前，确认管理契约的产出物、验收、周里程碑映射、工作阶段和截止时间已完整记录。
 - 写入后，读回准确记录验证结果。
+- 每日项目管理运行后，验证检查点的 `cycle_date`、`completed_phase`、`source_watermarks`、幂等键、拟变更状态和卡片/发布状态与实际一致。
 - 如果只读取了样本页或有限分页，在回答中明确说明。
 
 ## 自进化方法
@@ -212,7 +227,7 @@ description: 通过 lark-cli/LarkSuite CLI 处理「源子技术部管理系统
 
 Target repo: `MetaInFLow/metainflow-dev-tasks`
 Visibility: `public`
-Current Skill version: `v0.2.0`
+Current Skill version: `v0.3.0`
 Wrapper harness version: `v0.10.1`
 ## EvoZeus-wrapper
 

agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "源子开发任务"
   short_description: "闭环管理项目里程碑、任务产出、进度与负载"
-  default_prompt: "帮我结合项目任务安排、源子技术部管理系统、会前日计划、早会纪要和相关工作聊天管理开发任务。先确定有效项目集和工作流，建立项目周里程碑、个人周产出、今日任务的映射；任务必须写清产出物、载体、验收、依赖和准确截止时间。区分原始基线、当前预测与批准后基线，用验收证据判断项目提前、按计划、有风险或已落后；把未映射口头任务纳入待同步闭环，并在发送消息前单独确认最终内容和目标会话。"
+  default_prompt: "帮我结合项目任务安排、源子技术部管理系统、会前日计划、早会纪要和相关工作聊天管理开发任务。连续工作日使用每日项目管理闭环，从检查点恢复并进入会前扫描、会后校准、批准后写入/发布或日终收口阶段；定时调用只生成拟变更和私下草稿。先确定有效项目集和工作流，建立项目周里程碑、个人周产出、今日任务的映射；任务必须写清产出物、载体、验收、依赖和准确截止时间。区分原始基线、当前预测与批准后基线，用验收证据判断项目提前、按计划、有风险或已落后；把未映射口头任务纳入待同步闭环，并在发送消息前单独确认最终内容和目标会话。"