TaskFlow 1.1.14

TaskFlow 1.1.14 — 2026-11-04

One addition, one changed rule, two fixes. The theme is the workflow's own bookkeeping: each change closes a gap between what the workflow says and what a running session can actually observe.

A prompt with no task in flight now states the entrance rule. It was silent for the state that preceded its own motivating failure. hooks/prompt-reminder now names task intake and git worktree add beside the prompt when summarize-state reports # TaskFlow (no active task) — that is, in a repository that records work but has none in flight. Measured 2026-11-03: the session held the task state twice, the user said "修D1", and the Agent skipped intake, promotion, PRD/Plan, approval and the worktree. Every other hook was silent for a structural reason — the capability gate judges by stage-document basename; task promote checks the tree only when called; SessionStart injects state, not a gate. A repository that has never used TaskFlow, one with a task at any phase, and any cwd outside a repository stay silent.

CONTRIBUTING.md releases the last push before a merge from waiting on CI, when every changed path is under TaskFlowDocs/ and the code commit's CI is already green and named in the pull request body. A push to main still runs the full matrix; what is removed is the wait on the pull request. The path set includes todo.md, which an earlier draft excluded on a false belief about what the suite reads — hooks/smoke-test reads todo.md at exactly two places, both inside the ## Item template section, which hooks/archive never edits.

The Todo merge driver resolves in one awk process. 154–227 seconds → 1 second on a real 125-entry file, with output byte-identical to the old implementation's on both the real merge inputs and a synthetic fixture. The matching rules are unchanged. The other half matters more: the result is built beside %A and copied in only after the whole decision, so a run that does not finish leaves Git's content alone and its nonzero exit reports the failure. Before this, an interrupted run left %A as Git handed it over and git merge reported success with one side's file and no driver result — which is exactly what PR #117 merged.

Verification

• bash hooks/release-check . — STATUS: pass, re-run on the pushed main
• bash hooks/repository-check . — STATUS: pass
• quick_validate.py skills/taskflow — Skill is valid!
• git diff --check — clean
• bash hooks/smoke-test — skipped for the release commit by policy: it differs from aaaf4cb (CI run 41816966078, 7/7 success) only in the four manifests, the two README samples and CHANGELOG.md, none of which the suite reads
• Each change ran the full matrix on its own pull request: #116 (run 41786276755), #117 (run 41788317606), #118 (run 41814555598) — smoke on ubuntu, macos and windows each time

Known limitations

• The entrance reminder does not refuse anything; a hard PreToolUse gate was offered and deliberately not chosen.
• The merge driver's failure assertion injects a refusal, not a kill — both leave the same evidence, and the assertion tests that shape.
• The CI-release rule is applied by a person, not by CI.
• Merged branches accumulate: task complete and archive remove the worktree and leave the branch on purpose, but nothing reports the leftovers. Recorded as TF-20261104-d535ae.

Release record

• Tag v1.1.14 names ca2d42e9aa4fdf4eedde3d73e3db7e5da271763c
• Pin commit 9893567, pushed with the tag in one atomic push
• Marketplace pins: both catalogs at v1.1.14 / ca2d42e9aa4fdf4eedde3d73e3db7e5da271763c