落地任务复用治理规则与 worktree 对齐检查 [09-09-trellis-workflow-alignment]

2026-09-09 本地已验证完成、待交审的治理修复，一直未提交：

- 6 个 skill（trellis-before-dev/brainstorm/check/continue/finish-work/start）
  统一改为"先检查当前和直接相关既有任务，复用优先于新建"，取代原来"复杂任务
  先请求新建 task"的默认动作；新增 worktree/active-task 一致性校验步骤。
- project-governance.md 新增两节：Task Reuse（任务复用判据）、Active Task And
  Worktree Alignment（激活任务与实际执行 worktree 一致性检查，防止跨 worktree
  会话把上一个任务的 workflow-state 当成当前任务）。
- workflow.md 的 Request Triage / Parent-Child 章节、no_task 面包屑同步改写。

本地已过 task validate、check-trellis-governance.mjs、check-process-contract.mjs、
audit-docs.mjs、git diff --check；无业务代码改动。

Co-Authored-By: Claude Sonnet 5 <[email protected]>

.trellis/workflow.md

@@ -180,8 +180,8 @@ Phase 3: Finish  → verify, update spec, commit, and wrap up
 
 ### Request Triage
 
-- Pure consultation and small, isolated edits need no task unless requested. Non-trivial work needs a task and an approved plan; ask for task creation only when not already authorized.
-- Complex task: ask whether you may create a Trellis task and enter planning. If the user says no, do not do broad inline implementation; explain, clarify scope, or suggest a smaller split.
+- Pure consultation and small, isolated edits need no new task unless requested. Non-trivial work needs a task contract and approved plan, not necessarily a new directory.
+- Check the current task and directly related existing tasks first. Put acceptance-related fixes in the current task; put another domain's fixes in its existing task with a scoped follow-up stage. Create a task only for independently managed work without a suitable existing owner, with creation consent when not already authorized. Do not expand an existing task silently or reopen archived tasks automatically.
 - User approval to create a task is not approval to start implementation. Planning still happens first.
 
 ### Planning Artifacts
@@ -194,7 +194,7 @@ Phase 3: Finish  → verify, update spec, commit, and wrap up
 
 ### Parent / Child Task Trees
 
-Use a parent task when one user request contains several independently verifiable deliverables. The parent task owns the source requirement set, the task map, cross-child acceptance criteria, and final integration review; it normally should not be the implementation target unless it also has direct work.
+Use a parent task when genuinely new, independently managed deliverables need one; reuse suitable existing task contracts first. A small fix, separate worktree or separate commit alone does not require a child task. The parent owns cross-deliverable requirements and acceptance, not every incidental fix.
 
 Use child tasks for deliverables that can be planned, implemented, checked, and archived independently. Parent/child structure is not a dependency system: if one child must wait for another, write that ordering in the child `prd.md` / `implement.md` and keep each child's acceptance criteria testable.
 
@@ -203,9 +203,9 @@ Create new children with `task.py create "<title>" --slug <name> --parent <paren
 <!-- Per-turn breadcrumb: shown when there is no active task (before Phase 1) -->
 
 [workflow-state:no_task]
-No active task. First classify the current turn and ask for task-creation consent before creating any Trellis task.
+No active task. First classify the turn; no active pointer does not mean no suitable task exists.
 Pure consultation or a small isolated edit: respond or execute within scope without asking to create a task.
-Complex task: ask the user if you can create a Trellis task and enter the planning phase. If the user says no, explain, clarify scope, or suggest a smaller split.
+For tracked work, check directly related existing tasks and reuse a suitable contract. Activate already approved work with the official task command; new scope still needs review. Only request new-task creation when no suitable owner exists and creation is not already authorized. Do not create tasks merely for separate commits or worktrees.
 [/workflow-state:no_task]
 
 <!-- Per-turn breadcrumb: shown when the active task record cannot be read. -->