[TiantianFlow]

Closes #83. Closes #84.

#83: check-ins stop, and the interval follows the work

• The operator stops scheduling check-ins when board/status.md shows state: done after the goal was sent and the result is reported; when updated and foil seat list have not changed over several check-ins and its one nudge changed neither (it reports that once); or when state: blocked has questions it has relayed.
• The report that stops says monitoring stopped and which condition stopped it. Check-ins start again when the human answers, sends a new goal, or asks for status. A timer that drives the operator pauses on the same conditions.
• The interval is no longer "at most 10 minutes". Following the owner's comment, it is chosen from the work, usually 5 to 20 minutes and changing as it goes. It can be a minute for a step expected to be that fast (and goes back to 5 to 20 when that step isn't done), or up to 30 minutes early in a long goal (and goes back to 5 to 20 as the end nears).

#84: the operator clears a validated folder-trust prompt

• The human no longer pre-trusts paths. Onboarding still asks the human to clear update, first-run and opt-in dialogs once per harness.
• A new Dialogs section in the operator skill says the operator clears a folder-trust prompt only when all of these hold: the seat is in foil seat list; the window id and worktree come from run/registry.json and the launch cwd from run/plans/<seat>.json; the prompt is live and names one path; that path, made canonical, equals the recorded cwd, and the cwd is the seat's own checkout; and the choice is unambiguous. Then the operator sends only that key to the recorded window and peeks again to confirm the prompt is gone. A parent or any other directory is never trusted.
• Everything else is the human's, including login prompts and command or tool approvals, which the previous rule let the operator answer. The skill states the residual risk: this is cooperative protection for a same-user operator, not OS isolation.
• The lead now mentions a folder-trust prompt in its blocked question. When the answer says the prompt was cleared, it carries on with that seat instead of killing it. When the operator sees such a question, it runs the same checks and tells the lead.

The requirements (onboarding, F12, the section 8 operator and lead rows), the READMEs (EN and zh-CN), the demos (EN and zh-CN), the CHANGELOG and tests/test_skills.py all follow.

Verification

• uv run --frozen --extra dev pytest -m "not e2e_live": 573 passed. ruff check .: clean.
• Two rounds of independent review, a privacy check and a publish-safety check. Round 1 found the lead skill would still kill a seat whose prompt was cleared, plus some wording. Round 2 found two low items, both fixed.
• Not verified against live harness CLIs. The rule is skill text for the operator, and it adds no code.

---

Generated by Claude Code