@pennixrv/trellis 0.7.1-beta.0 → 0.7.1-beta.10

package/dist/templates/claude/hooks/statusline.py

@@ -136,14 +136,19 @@ def _get_current_task_for_input(trellis_dir: Path, cc_data: dict) -> dict | None
 
 
 def _count_active_tasks(trellis_dir: Path) -> int:
-    """Count non-archived task directories with valid task.json."""
+    """Count planning and in_progress tasks using the native bounded reader."""
     tasks_dir = trellis_dir / "tasks"
     if not tasks_dir.is_dir():
         return 0
     count = 0
-    for d in tasks_dir.iterdir():
-        if d.is_dir() and d.name != "archive" and (d / "task.json").is_file():
-            count += 1
+    scripts_dir = trellis_dir / "scripts"
+    if str(scripts_dir) not in sys.path:
+        sys.path.insert(0, str(scripts_dir))
+    from common.tasks import iter_active_tasks  # type: ignore[import-not-found]
+    try:
+        count = sum(1 for task in iter_active_tasks(tasks_dir) if task.status in {"planning", "in_progress"})
+    except (ValueError, OSError):
+        return 0
     return count
 
 

package/dist/templates/common/bundled-skills/trellis-decision-space-construction-and-merging/workflow.md

@@ -4,6 +4,8 @@
 
 需要构造时，梳理决策项及其权限、候选、重要排除项与理由；按需补齐证据、适用约束、标准、阈值、依赖、影响和优先级。证据足够时给出推荐；证据不足则保留未知或待决项，不伪造结论。仅当选择之间存在条件依赖时使用决策树，并标明分支条件、来源、未知路径及其下游影响。互斥、共享依赖或汇合关系可用依赖图；独立候选用比较表或清单即可。
 
+候选尚未覆盖实质选择时，从不同机制、责任边界或运作方式拓宽，而非只列同一做法的参数变体；适用时纳入维持现状或不做。再以已确认约束、当前实现、外部先例及必要的有界探针筛选，区分不可行、代价较高与证据不足，保留排除理由及依赖后果。重要选择已可比较、未知已定位到受影响的决定时停止；不凑候选数量，不在没有新证据时追加轮次。目标变化回第一阶段，用户保留决定整理给第三阶段，不由辅助 Skill 提前锁定。
+
 新颖机制、重大重构、跨组件边界变化或关键取舍缺少可信本地先例时，进行有界的 `prior-art review`，记录适用性与采纳或排除理由。只读 Teamwork 可按需补充证据；主代理核验报告后归并。将 `DecisionSpace` 或有据跳过记录交由 Trellis CLI 接受，待用户决定交由解决方案设计与收敛阶段处理。
 
 ```mermaid

package/dist/templates/common/bundled-skills/trellis-goal-exploration-and-requirements/workflow.md

@@ -4,6 +4,8 @@
 
 整理目标、范围、成功条件、关键约束和责任方。区分已知事实、假设、证据冲突和未知事项；缺少会改变目标或路线的用户事实时，通过 `pennix-decision-grill` 同步询问。记录会阻断推进的问题及恢复条件；不影响当前路线的事项可明确责任方和后续处理。
 
+当请求只描述症状、先给出解法或目标含糊时，先对照实际使用情境、当前行为与期望结果，必要时回述问题，检验是否过早限定了解法。区分硬约束与可挑战的惯例、未经证实的假设；只追查会改变本轮目标、范围或成功条件的信息。明确本轮要改变什么、怎样观察成功、哪些不做及哪些未知仍有实际影响后即可收敛，不强制访谈轮数或将开放问题缩成 MVP。已知目标直接复用，没有价值或不宜继续也可形成适用的分析路线。
+
 形成 `phase_output`，至少包含当前目标与需求基线、必要证据、不确定性、`phase_result` 和非约束性的 `route_advice`。`route_advice` 简要说明任务类型、复杂度画像和项目背景如何影响阶段选择，并记录复杂度判断的实际触发维度与理由；不机械计分或套用固定路由矩阵，也不要求固定字段或篇幅。路线发生变化时，使用 Trellis CLI 更新受影响的分类和阶段，并按影响范围重新核验。阶段可等待用户补充或因依赖阻塞；只有用户确认当前基线且阶段产物有效时，才以 `accepted` 离开本阶段。将阶段产物及引用提交 Trellis CLI 核验后，向用户展示简明基线并请求确认或修订。
 
 ```mermaid

package/dist/templates/common/bundled-skills/trellis-meta/SKILL.md

@@ -66,7 +66,7 @@ Do not assume the user has the Trellis source repository. Do not default to modi
 - `.trellis/workflow.md` is the local workflow source of truth. By default, `trellis init` writes the bundled `native` workflow; a custom workflow is available only when its source is explicitly supplied, and can be re-selected via `trellis workflow --template <id> --workflow-source <source>`. Missing `.trellis/agents/<name>.md` files referenced by the active template trigger a non-blocking stderr warning pointing at `trellis update`.
 - `.trellis/config.yaml` is the project-level Trellis configuration entry point. It hosts task lifecycle hooks (`hooks.after_create` / `after_start` / `after_finish`), journal shape (`session_commit_message` / `max_journal_lines` / `session_auto_commit`), Teamwork teammate guard (`teamwork.teammate_guard.idle_timeout` / `max_live_teammates`), Codex dispatch mode (`codex.dispatch_mode: inline | sub-agent`), and the spec registry block (`registry.spec.source` + `registry.spec.template`).
 - `.trellis/spec/` stores the user's project-specific coding conventions and design constraints. When `registry.spec` is set, files are refreshed by `trellis update`; local edits surface as `modified by user` conflicts in `.trellis/.template-hashes.json`.
-- `.trellis/tasks/` stores task records, planning artifacts, research, and JSONL context. Tasks remain in place after completion or cancellation. Tasks form parent/child trees through `task.py create --parent`, `add-subtask`, `remove-subtask`, and `list-context`.
+- `.trellis/tasks/` stores task records, planning artifacts, research, and JSONL context. Tasks follow their status directory: planning, in_progress, completed/YYYY-MM, or cancelled. Native relocation preserves identity and history and updates machine references transactionally. Tasks form parent/child trees through `task.py create --parent`, `add-subtask`, `remove-subtask`, and `list-context`.
 - `.trellis/workspace/` stores **deliberately written** developer journals. Raw cross-session dialogue is **not** stored here — it lives on disk under `~/.claude/projects/`, `~/.codex/sessions/`, and `~/.pi/agent/sessions/` and is recovered via `trellis mem search|extract|context`. The bundled `trellis-session-insight` skill teaches when to reach for `mem`.
 - `.trellis/agents/teammate.md` is the bundled, platform-agnostic instruction card loaded for a teammate by `trellis teamwork spawn --agent teammate`. Editable; `trellis update` backfills it if missing. Editing the per-platform `trellis-implement.md` / `trellis-check.md` does **not** change Teamwork teammate behavior.
 - `~/.trellis/teamwork/<project>/<session>/events.jsonl` is the Teamwork Session event log. User-owned, file-locked sequence numbering, durable `idempotencyKey` support; never under `.trellis/`.

package/dist/templates/common/bundled-skills/trellis-meta/references/customize-local/add-project-local-conventions.md

@@ -9,7 +9,7 @@ Often the user does not need to change Trellis mechanics; they need local AI to
 | Rules code must follow | `.trellis/spec/<layer>/` |
 | Cross-layer thinking methods | `.trellis/spec/guides/` |
 | AI capability for a project-specific flow | Platform-local skill |
-| One-off task material | `.trellis/tasks/<task>/` |
+| One-off task material | `.trellis/tasks/<task-dir>/` |
 | Session summary | `.trellis/workspace/<developer>/journal-N.md` |
 
 ## Create A Project-Local Skill

package/dist/templates/common/bundled-skills/trellis-meta/references/customize-local/change-context-loading.md

@@ -17,11 +17,11 @@ Context loading determines when AI reads workflow, task, spec, research, workspa
 | Source | Purpose |
 | --- | --- |
 | `.trellis/workflow.md` | Workflow and next-action hints. |
-| `.trellis/tasks/<task>/prd.md` | Current task requirements. |
-| `.trellis/tasks/<task>/design.md` | Complex task technical design. |
-| `.trellis/tasks/<task>/implement.md` | Complex task execution plan. |
-| `.trellis/tasks/<task>/implement.jsonl` | Spec/research to read before implementation. |
-| `.trellis/tasks/<task>/check.jsonl` | Spec/research to read during checking. |
+| `.trellis/tasks/<task-dir>/prd.md` | Current task requirements. |
+| `.trellis/tasks/<task-dir>/design.md` | Complex task technical design. |
+| `.trellis/tasks/<task-dir>/implement.md` | Complex task execution plan. |
+| `.trellis/tasks/<task-dir>/implement.jsonl` | Spec/research to read before implementation. |
+| `.trellis/tasks/<task-dir>/check.jsonl` | Spec/research to read during checking. |
 | `.trellis/spec/` | Project specs. |
 | `.trellis/workspace/` | Session records. |
 | git status | Current working tree changes. |

package/dist/templates/common/bundled-skills/trellis-meta/references/customize-local/change-task-lifecycle.md

@@ -1,6 +1,6 @@
 # Change Local Task Lifecycle
 
-Read the installed project's workflow and task record before changing task creation or lifecycle behavior. Task records remain in .trellis/tasks/ after completion or cancellation; Trellis does not archive task records.
+Read the installed project's workflow and task record before changing task creation or lifecycle behavior. 任务目录由 status 投影到 planning、in_progress、completed/YYYY-MM、cancelled；完成或取消必须通过原生事务同步移动、引用与会话清理，不能只改字段或手工移动目录。
 
 ## Read these files first
 
@@ -9,7 +9,8 @@ Read the installed project's workflow and task record before changing task creat
 3. .trellis/scripts/task.py
 4. .trellis/scripts/common/task_store.py
 5. .trellis/scripts/common/task_workflow.py
-6. The current task's task.json
+6. .trellis/scripts/common/task_layout.py and task_move.py
+7. The current task's task.json
 
 ## Common edit points
 

package/dist/templates/common/bundled-skills/trellis-meta/references/customize-local/overview.md

@@ -29,7 +29,7 @@ This directory is for local AI working in a user project where Trellis was insta
 | --- | --- |
 | Workflow | `.trellis/workflow.md` |
 | Project configuration | `.trellis/config.yaml` |
-| Task material | `.trellis/tasks/<task>/` |
+| Task material | `.trellis/tasks/<task-dir>/` |
 | Project specs | `.trellis/spec/` |
 | Runtime scripts | `.trellis/scripts/` |
 | Platform integration | `.claude/`, `.codex/`, `.cursor/`, `.opencode/`, `.zcode/`, and similar directories |

package/dist/templates/common/bundled-skills/trellis-meta/references/local-architecture/context-injection.md

@@ -9,7 +9,7 @@ Trellis context injection aims to make AI read the right files at the right time
 | session context | `.trellis/scripts/get_context.py` | Current developer, git status, active task, active tasks, journal, packages. |
 | workflow context | `.trellis/workflow.md` | Current Trellis flow and next action. |
 | spec context | `.trellis/spec/` + task JSONL | Specs that must be followed during implementation/checking. |
-| task context | `.trellis/tasks/<task>/prd.md`, `design.md`, `implement.md`, `research/` | Current task requirements, design, execution plan, and research. |
+| task context | `.trellis/tasks/<task-dir>/prd.md`, `design.md`, `implement.md`, `research/` | Current task requirements, design, execution plan, and research. |
 | platform context | Platform hooks/settings/agents | Lets different AI tools read the files above through their own mechanisms. |
 
 ## session-start

package/dist/templates/common/bundled-skills/trellis-meta/references/local-architecture/task-system.md

@@ -1,6 +1,6 @@
 # Local Task System
 
-Tasks live under .trellis/tasks/. A task record keeps its artifacts and history in place after completion or cancellation; Trellis does not move tasks into an archive.
+任务按状态存放于 `.trellis/tasks/planning/<task>`、`in_progress/<task>`、`completed/YYYY-MM/<task>`、`cancelled/<task>`。`task.json.status` 是唯一状态事实；目录只投影状态，不增加第五种状态。创建进入 planning，获准实施的 start 进入 in_progress，complete 进入当月 completed，cancel 进入 cancelled。任务身份和父子关系不因移动改变。
 
 ## Task records
 
@@ -27,7 +27,13 @@ The active task pointer is scoped to an AI session under .trellis/.runtime/sessi
 
 Use phase operations through task.py phase for artifact revisions, acceptance, evidence-backed skips, waits, blocks, resume, return, route, and authorization. Consult task.py help for current arguments. Completion and cancellation occur only after Delivery Review and On-Site Closeout Phase.
 
-The read-only trellis task progress command summarizes planning, in_progress, and completed lifecycle records. It does not change task state.
+The read-only trellis task progress command summarizes planning, in_progress, completed, and cancelled lifecycle records, with a partial flag for unreadable or inconsistent input. It does not change task state.
+
+## 布局迁移与恢复
+
+旧平铺目录和 `archive/YYYY-MM` 只能作为显式迁移输入。先运行 `task.py migrate-layout` 预览，再使用 `--apply`；已完成 archive 任务保留原月份，非终态任务按真实状态归位，不伪造完成。`--recover` 恢复未完成事务。重复名称、无效 JSON、符号链接、未知执行资源或交接所有权冲突会阻止迁移；不跳过记录。
+
+移动同步 JSON/JSONL 机器引用、会话指针及 runtime 哈希索引；终态操作在同一事务中清除本任务 runtime。历史正文和正式交接包保留。内容绑定的接受证据或 continuity digest 失效后，通过原生重新接受、capture、目标会话 reconcile 核对，不静默重授历史授权。文档中的 `<task-dir>` 指包含状态及必要月份的真实任务相对路径。
 
 ## Context manifests
 

package/dist/templates/common/bundled-skills/trellis-session-insight/references/cli-quick-reference.md

@@ -55,9 +55,10 @@ trellis mem projects
 
 ## Caveats
 
-- **OpenCode adapter is a stub on `0.6.0-beta.*`.** When `--platform` resolves to OpenCode (or `all` and OpenCode would be included), `mem` prints a one-line "reader unavailable" notice and continues with the other platforms. Don't promise OpenCode coverage in your reply until the adapter ships.
+- **OpenCode reads its local SQLite database.** `--include-children` merges supported child-session dialogue for search/context. Historical `--phase` slicing is unavailable for OpenCode: it warns and returns all dialogue. Report unreadable stores or unsupported slices from the actual command result.
 - **`--platform devin` is Cognition Devin CLI** (`~/.local/share/devin/cli/sessions.db`). It is not `trellis init --devin` (Devin Desktop / Cascade) and not Factory Droid.
 - **`--phase` slicing depends on `task.py create` / `task.py start` invocations appearing in the recorded bash calls of the session.** Sessions where the user ran `task.py` from a different terminal — outside the recorded AI loop — will not have phase boundaries. `--phase all` is the safe fallback.
+- **Historical slice names are not native workflow state.** `brainstorm` and `implement` remain valid retrieval flags; they do not identify any of the current five phases, prove acceptance or implementation authorization, or grant task ownership. There is no `--task` filter. Unknown, inapplicable, duplicate, or incomplete flags fail with exit code 2.
 - **`mem` indexes platform JSONL files directly.** If the user has cleared their Claude / Codex / Pi session storage, `mem` cannot recover what is no longer on disk.
 - **`mem` is read-only.** No remote sync, no edits to platform JSONL. Any write you do based on `mem` findings is your own follow-up call into the editing tools available to you.
 

package/dist/templates/common/bundled-skills/trellis-session-insight/references/triggering-patterns.md

@@ -41,7 +41,7 @@ The user resumed work after a gap and the context is implicit.
 - "我们上次做到哪了"
 - "接着昨天那个任务"
 
-Reach: `trellis mem list --task <current-task-dir>` to find the most recent sessions tied to the active task, then `extract` the last one.
+Reach: first read the current task's native phase, ownership, and recorded progress. Use `trellis mem list --cwd <project-root>` and `search "<task-id or distinctive topic>" --cwd <project-root>` to find candidate sessions, then inspect them with `context` or `extract`. The CLI has no `--task` filter; project membership and recency do not prove that a session owns the task. History supplements current task state and does not transfer ownership.
 
 ## Familiar-bug debugging
 
@@ -80,7 +80,7 @@ The user explicitly wants to look back at this task — not as a forced step, on
 - "记一下这次踩的坑"
 - "复盘下这个任务"
 
-Reach: identify the current task's session id (from `.trellis/.runtime/sessions/*.json` or `mem list --task <task-dir>`), then `extract <id> --phase brainstorm` and `--phase implement`. Present a summary — surface concrete file:line citations where possible. Whether to also write the summary somewhere (PRD, spec, notes file) is the user's call; offer, don't auto-write.
+Reach: use the task's recorded host session identifier as a candidate, or search its distinctive topic within `--cwd <project-root>`, then verify the session content. `extract <id> --phase brainstorm` and `--phase implement` are historical dialogue slices based on recorded create/start calls, not the current five workflow phases; use `--phase all` when those boundaries do not apply. Present concrete citations where possible. Write findings only to an authorized natural task or knowledge location.
 
 ## Anti-patterns: do NOT reach for `mem` here
 

package/dist/templates/common/bundled-skills/trellis-solution-design-and-convergence/workflow.md

@@ -6,6 +6,10 @@
 
 判断当前结果：分析交付形成 `analysis_conclusion`；不继续形成 `no_go`；延期形成带责任方、触发条件和恢复位置的 `deferred`，留在解决方案设计与收敛阶段；实施路线形成 `implementation_contract`，明确目标、范围和接受条件，并按路线需要补足实施与核验信息。只有交付物具有独立实施或集成边界时才拆分工作包，并说明推进和协作所需的依赖、顺序、责任或集成信息；单一交付不人为拆分工作包。解决方案设计与收敛阶段的结果接受与实施授权分开记录；只有合同及明确批准均有效时，Trellis CLI 才允许进入任务实施与测试验证阶段。
 
+逐项决定回答后，将已决目标、候选依据、接口与数据流、owner、依赖顺序、实施和验证，以及适用的迁移、发布、资源和失败恢复安排组织为一个完整方案。核对需求覆盖、跨产物一致性、可实施性和可验收性；有净收益时使用有界反例或压力测试，先修复可查缺口。向用户展示可识别的整体方案和实质剩余取舍后，再记录当前 revision 的接受及实施授权。逐项答复不自动等于整体批准；用户已充分明确批准整体方案时不重复索取。目标或候选问题回最早受影响阶段，局部方案问题在本阶段解决，不增设外部封口状态。
+
+研究、原型和协作证据写回现有阶段产物、research 或 execution 自然落点，注明来源与版本、事实和假设、适用性、限制及决定影响。证据足够即停止扩搜；工具、报告或模板不能替代用户决定和 Trellis 原生接受事实。
+
 ```mermaid
 flowchart TD
   input["核对需求基线与已接受的 DecisionSpace"] --> decisions{"存在尚待用户决定的实质取舍？"}

package/dist/templates/common/bundled-skills/trellis-spec-bootstrap/references/mcp-setup.md

@@ -2,6 +2,8 @@
 
 GitNexus and ABCoder are recommended when bootstrapping Trellis specs because they expose architecture and AST context to the agent. They are tool choices, not platform requirements. Configure them through whatever MCP mechanism your agent host provides.
 
+First discover the project's approved, available tools and existing indexes. Use source and tests directly when no suitable index is available; record that limit. Spec bootstrapping does not authorize installing tools, configuring MCP servers, downloading executables, or creating or refreshing indexes. The setup examples below apply only after those operations have separate authorization and the target repository is explicit. Prefer an already installed, pinned owner entry point over an unpinned download.
+
 ## GitNexus
 
 GitNexus builds a code knowledge graph from the repository. Use it for module boundaries, execution flows, dependency relationships, blast radius, and graph queries.
@@ -15,7 +17,7 @@ npx gitnexus analyze
 # Check index status.
 npx gitnexus status
 
-# Re-index after code changes when the analysis is stale.
+# Re-index only when explicitly authorized for this repository.
 npx gitnexus analyze
 ```
 
@@ -82,7 +84,7 @@ abcoder mcp ~/abcoder-asts
 
 ## Verification
 
-After configuration, verify from the agent host that both MCP servers are visible. Then run one simple query against each server before starting the spec writing pass.
+After an authorized configuration change, verify the selected MCP server from the agent host and run a simple query. Neither server is mandatory; unavailable tooling does not block a source-backed spec pass.
 
 ```bash
 ls .gitnexus/meta.json

package/dist/templates/common/bundled-skills/trellis-spec-bootstrap/references/spec-task-planning.md

@@ -14,7 +14,7 @@ Avoid artificial decomposition. A small library usually needs one focused spec p
 
 ## Task Shape
 
-When a Trellis task is useful, write a concise PRD with these sections:
+Reuse the current task when the spec work belongs to its authorized scope. Otherwise route the request through request-intake and the project's native phases. The following is an example of useful coverage; preserve the project's actual artifact structure rather than requiring a new PRD or these exact headings:
 
 ```markdown
 # Fill <package-or-layer> Trellis Specs
@@ -55,7 +55,7 @@ If the host supports subagents, helpers can inspect independent packages or run
 Helper tasks must have clear ownership:
 
 - Read-only research tasks may inspect any source needed for the assigned scope.
-- Write tasks should own disjoint spec directories.
+- Native helper write tasks require explicit project authorization and disjoint spec directories. Trellis Teamwork teammates remain in their research, review, or verification role and return findings in the assigned format; the coordinator applies accepted spec edits.
 - Verification tasks should check placeholder removal, broken links, and consistency.
 
 Do not encode helper-agent names, vendor-specific commands, or platform-specific routing in the skill. Put only the required work and acceptance criteria in the task.

package/dist/templates/common/bundled-skills/trellis-teamwork/SKILL.md

@@ -37,8 +37,11 @@ trellis teamwork context list <session> --scope global --thread <thread>
 
 | User intent | Read |
 |---|---|
+| `general`: bounded research, review, or verification assignments | `references/teamwork-plan-construction.md`, then `references/coordination-modes.md` |
+| Advisor: one bounded consultation | `references/coordination-modes.md` |
+| `committee`: parallel assessment by two or three distinct lenses | `references/coordination-modes.md` |
 | “和 codex/claude 讨论一下”, “brainstorm with another agent” | `references/teamwork-plan-construction.md`, then `references/coordination-modes.md` |
-| “派一个 implement/check agent”, “让 agent review”, “spawn a worker” | `references/teamwork-plan-construction.md`, then `references/teammate-processes.md` |
+| “派 teammate 做研究或验证”, “让 agent review”, “spawn a worker” | `references/teamwork-plan-construction.md`, then `references/teammate-processes.md` |
 | “开 issue 区 / topic 群 / changelog / board”, “make a forum” | `references/teamwork-plan-construction.md` |
 | “看看这个 thread”, “inspect a thread” | `references/teamwork-plan-construction.md` |
 | “Teamwork 卡住了 / 没输出 / progress 被截断”, “teammate stalled” | `references/teammate-processes.md` |
@@ -46,13 +49,15 @@ trellis teamwork context list <session> --scope global --thread <thread>
 
 ## Core Rules
 
+- Teammates provide research, review, verification, evidence, and advice under a role contract; they do not implement product code. Coding tools or provider permission modes do not grant that role authority. Return results in the assigned format and let the coordinator review them.
+- `general`, `advisor`, and `committee` are coordination modes, independent from `run`, batch execution, and forum sessions. The current `batch` CLI is reserved and refuses dispatch; see the plan reference for the current boundary.
 - New forum Teamwork Sessions use `--type forum`. A `thread` is one item inside a forum Teamwork Session.
 - Use `--context-file` / `--context-raw` and `trellis teamwork context add/delete/list`.
 - Use `--stdin` or `--text-file` for long messages. Do not put long mixed Chinese/English text in the positional shell argument.
 - Pretty `messages` output is an operator dashboard and may truncate progress. Use `--raw` for audit.
 - `--as` is the speaker or worker handle, depending on the command. Use explicit, stable names when multiple agents or sessions are involved.
 - `--scope project` (default) operates on the current cwd's project bucket; `--scope global` operates on the shared `__global__` bucket. Pick scope deliberately — a global board is invisible from project listings unless `--scope global` is passed.
-- For brainstorm, do multiple pressure-test rounds. One answer plus one confirmation is review, not brainstorm.
+- For exploratory discussion, choose distinct questions and pressure-test unresolved assumptions. Continue only while another exchange can change the decision or its evidence; do not require a fixed number of rounds or relabel a confirmation as new evidence.
 - **Dispatcher wait pattern**: use `--kind done` / `--kind turn_finished` (Trellis-emitted system events), not a user `--tag` as the completion signal. Tags are labels, not runtime completion events.
 - Teamwork Sessions are event-sourced. Do not parse `events.jsonl` first; use `forum`, `thread`, `messages --thread`, and `context list`.
 - `@pennixrv/trellis-core` owns reusable Teamwork Session/thread state, event append, sequence allocation, context/title projection, reducers, and task helpers. The CLI owns flags, terminal rendering, prompts, teammate lifecycle, and process exits.

package/dist/templates/common/bundled-skills/trellis-teamwork/references/coordination-modes.md

@@ -22,7 +22,9 @@ change the task or phase by itself.
 Use committee coordination when one question benefits from parallel distinct
 lenses. The plan contains two or three assignments in one evaluation group.
 All members share the assignment contract and use distinct lenses. They return
-independent evidence; the coordinator compares the reports after they finish.
+independently authored reports; the coordinator compares them after they finish.
+Members may cite the same authoritative sources. Distinct lenses do not
+guarantee independent evidence or require different providers, models, or profiles.
 
 Committee members do not debate with one another, run a consensus loop, or use
 a directional counter relationship. If a question does not need independent

package/dist/templates/common/bundled-skills/trellis-teamwork/references/teammate-configuration-matrix.md

@@ -18,12 +18,17 @@ profile. Supported provider adapters are Codex app-server, DSH ACP, Copilot
 ACP, and Claude Code CLI when their host contracts are available. A provider
 name alone does not prove that its host is installed or verified.
 
-The host capability proof covers only the boundaries required by the selected
-plan: foreground waiting, protected artifact writes, read-only protected
-targets and Git state, disabled native or recursive delegation, isolated
-context, supported transport, and a positive capacity. The CLI refuses a
-dispatch when the selected host cannot prove those properties. It does not
-invent an execution profile or silently change the frozen values.
+The coordinator's host capability proof covers foreground waiting, protected
+artifact writes, attempt artifact output, disabled native delegation, isolated
+context, supported transport, and a positive capacity. Source and Git write
+boundaries are role obligations recorded in `writePolicy`; they do not require
+filesystem or Git permission isolation. Available tools do not authorize a
+teammate to implement product code. The coordinator rejects an incomplete
+runtime proof without silently changing the frozen execution values.
+
+The public `trellis teamwork batch` entry currently refuses dispatch before
+coordination state is written. It does not discover or connect a host adapter;
+interactive `spawn` and `run` do not establish a verified batch adapter.
 
 The bundled role card is `.trellis/agents/teammate.md`. It is provider-neutral
 and limits a teammate to the frozen context and current attempt artifacts. A

package/dist/templates/common/bundled-skills/trellis-teamwork/references/teammate-processes.md

@@ -14,12 +14,20 @@ identity, or unconfirmed cancellation enters reconciliation and is not
 automatically duplicated. Reconciliation is a runtime outcome; the task
 coordinator decides whether a later task phase needs a return.
 
+When a live Teamwork wait returns a host continuation, resume only that
+continuation until it resolves, times out, or errors. Do not run another
+host action meanwhile, including another wait, shell command, or status/message
+query. An empty transport slice does not mean the wait has completed. Run
+diagnostics only after the continuation returns and diagnosis is needed.
+
 Use the ordinary Teamwork Session commands for a deliberate one-shot or
 interactive discussion:
 
 ```bash
 trellis teamwork run [name]
-trellis teamwork spawn <name> --agent <agent> --provider <provider>
+trellis teamwork spawn <name> --agent teammate --provider <provider> \
+  --as reviewer --file .trellis/tasks/<task-dir>/prd.md \
+  --jsonl .trellis/tasks/<task-dir>/research.jsonl
 trellis teamwork send <name> --as <agent> --stdin
 trellis teamwork wait <name> --as <agent> --kind done,turn_finished
 trellis teamwork interrupt <name> --as <agent> --to <teammate> --stdin
@@ -30,8 +38,44 @@ These commands operate a Teamwork Session and do not replace a frozen plan or
 create a second scheduler. Do not use them to bypass a rejected batch or to
 steer an active managed assignment manually.
 
-For a stalled process, inspect `teamwork list`, `teamwork messages --raw`, the
-provider log, and the host process state in that order. Use `kill` only when
-the process owner and current state are known. The runtime event log is the
-source of truth for coordination state; sidecar process files are diagnostic
-evidence.
+`spawn` registers an idle teammate; the first targeted `send` starts its turn.
+The agent card can set provider defaults, while `--provider`, `--model`,
+`--cwd`, `--resume`, `--sandbox`, `--timeout`, and `--warn-before` refine one
+launch. `--file` accepts repeatable paths or globs. `--jsonl` accepts a
+repeatable Trellis JSONL manifest whose entries have `{ "file", "reason" }`.
+Both forms are resolved relative to the spawn cwd, reject paths outside the
+cwd or configured trusted roots, skip missing entries with a warning, and
+enforce per-file and total-context limits before building the system prompt.
+
+Use `--inbox-policy explicitOnly|broadcastAndExplicit` to control which
+messages are delivered to a teammate. `send --to` selects recipients and
+`--delivery-mode appendOnly|requireKnownWorker|requireRunningWorker` controls
+target validation. The runtime records the injected files, manifest paths,
+provider identity, and terminal event in the session log.
+
+The guard resolves CLI flags, then environment variables, then
+`teamwork.teammate_guard` in `.trellis/config.yaml`, then built-in defaults.
+`--idle-timeout` cleans a continuously idle teammate; `--max-live-teammates`
+limits live processes. A value of `0` disables the corresponding guard. An
+idle teammate is not cleaned while it is in a turn. `interrupt` requests a
+replacement instruction, `kill` attempts graceful shutdown, and `kill --force`
+uses the hard termination path. `--resume` supplies the provider session or
+thread identifier for a later attempt.
+
+For short independent work, `teamwork run` creates an ephemeral session,
+injects the selected context, sends one prompt, waits for `done`, prints the
+answer, and removes the session. For a managed plan, the coordinator owns
+claim, dispatch, retry budget, terminal receipt, and reconciliation. An
+uncertain provider action is reconciled instead of being duplicated. Settled
+attempt artifacts may be cleaned according to the plan retention rule; the
+Teamwork Session event log follows its own lifecycle.
+
+For a stalled process, inspect `teamwork list`,
+`teamwork messages <session> --raw --no-progress`, the provider log, and the
+host process state in that order. Use `messages --follow` for live output and
+the `--since`, `--kind`, `--from`, `--to`, `--thread`, and `--action` filters
+to isolate a turn. Use `kill` only when the process owner and current state
+are known. The runtime event log is the source of truth for coordination
+state; sidecar process files are diagnostic evidence. The hidden
+`teamwork __supervisor` and `__parse-trace` commands are runtime internals,
+not user-facing dispatch entry points.

package/dist/templates/common/bundled-skills/trellis-teamwork/references/teamwork-plan-construction.md

@@ -39,22 +39,27 @@ specs, and the generic teammate role card. Freeze the input revision and route
 revision after the coordinator has selected the scope. If those values change,
 construct a new plan rather than mixing results from different task inputs.
 
-The public dispatch entry point is:
+The reserved managed-batch entry point is:
 
 ```bash
 trellis teamwork batch <plan-path>
 ```
 
-The command validates the plan, then the coordinator owns dispatch, waiting,
-report acceptance, and the terminal receipt. The coordinating agent does not
-manually refill slots or create a second retry loop.
+The current CLI unconditionally refuses this command before writing
+coordination state: a verified runtime adapter has not been connected to the
+coordinator. It does not discover an adapter or start the batch. The shared
+coordinator and its plan/report contracts exist and are tested separately.
+Do not present `run` or `spawn` as a substitute for managed batch execution.
+When connected, the coordinator owns dispatch, waiting, report acceptance,
+and the terminal receipt; the coordinating agent must not add a second retry loop.
 
 ## Teamwork Session and forum commands
 
 Create and inspect the durable runtime object with the native CLI:
 
 ```bash
-trellis teamwork create <name> --type chat|forum
+trellis teamwork create <name> --type chat|forum \
+  --task .trellis/tasks/<task-dir> --description "bounded discussion"
 trellis teamwork list [--scope project|global] [--all]
 trellis teamwork messages <name> [--raw]
 trellis teamwork wait <name> --as <agent> --kind done,turn_finished
@@ -63,10 +68,45 @@ trellis teamwork thread <name> <thread-key>
 trellis teamwork context list <name> [--thread <thread-key>]
 ```
 
-Use `--context-file` and `--context-raw` for durable context. Use `--stdin` or
-`--text-file` for long message bodies. `--kind` selects runtime event kinds;
-it is not a user-defined tag. Read forum summaries and thread projections
-through the CLI before inspecting raw event storage.
+Use `--scope global` only for a deliberately shared board; the default project
+scope is isolated by the current project bucket. `create` also accepts
+`--labels`, `--cwd`, `--by`, `--force`, `--context-file`, `--context-raw`, and
+`--ephemeral`. Ephemeral sessions are hidden from `list` unless `--all` is
+passed and are intended for short-lived coordination.
+
+For a forum, append structured thread events with `opened`, `comment`,
+`status`, or `summary` and inspect the reduced board or event timeline:
+
+```bash
+trellis teamwork post <session> opened --as main --thread design \
+  --title "Design question" --description "What needs evidence?"
+trellis teamwork post <session> comment --as reviewer --thread design \
+  --stdin
+trellis teamwork post <session> status --as main --thread design --status open
+trellis teamwork post <session> summary --as main --thread design \
+  --summary "Evidence collected"
+trellis teamwork forum <session> --status open
+trellis teamwork thread <session> design
+trellis teamwork thread rename <session> design architecture --as main
+```
+
+`post` can also replace labels or assignees and attach thread context with
+`--context-file` / `--context-raw`. Session-level context uses
+`teamwork context add|delete|list`; context deletion appends a durable
+projection event rather than rewriting the event log. Use `title set` and
+`title clear` for the display title.
+
+Use `--stdin` or `--text-file` for long message and thread bodies. `messages`
+supports `--raw`, `--follow`, `--last`, `--since`, `--kind`, `--from`, `--to`,
+`--thread`, `--action`, and `--no-progress`. `--kind` selects runtime event
+kinds; it is not a user-defined tag. Read forum summaries and thread
+projections through the CLI before inspecting raw event storage.
+
+Remove settled runtime state deliberately. `rm <name>` stops live teammates
+before deleting one session. `prune` is a dry-run by default and supports one
+of `--ephemeral`, `--empty`, `--idle <duration>`, or `--all`, plus `--keep`;
+pass `--yes` to perform the deletion. Never use session cleanup as a task
+archive operation.
 
 ## Result handling
 

package/dist/templates/common/commands/start.md

@@ -1,6 +1,6 @@
 # Start Session
 
-Load the current Trellis context and continue from the task record's current phase.
+Load the session's Trellis context. Route a new request through `trellis-request-intake`; resume existing work through `trellis-continue` and the task record's current phase. Do not repeat initialization when context and ownership have already been established.
 
 ## Load context
 
@@ -12,7 +12,7 @@ Read the applicable spec indexes before editing code. The active phase breadcrum
 
 ## Route the current request
 
-- No active Trellis task: use the taskless route when the request is clear, low-risk, reversible, authorized, and immediately verifiable. Otherwise create the task with the user's consent and load `trellis-goal-exploration-and-requirements`.
+- New request: use `trellis-request-intake` to determine whether it changes the current goal, is independent work, or qualifies for the taskless route. Reuse existing authorization and evidence.
 - Task with no initialized route: inspect its current requirements, choose the applicable ordered phases with evidence for omissions, then initialize the route through task.py phase init.
 - Goal Exploration and Requirements Confirmation Phase: load `trellis-goal-exploration-and-requirements`. Do not leave until the user confirms the current requirements artifact revision.
 - Decision Space Construction and Consolidation Phase: load `trellis-decision-space-construction-and-merging`.

package/dist/templates/common/skills/before-dev.md

@@ -2,10 +2,7 @@ Read the relevant development guidelines before starting your task.
 
 Execute these steps:
 
-1. **Read current task artifacts**:
-   - `prd.md` for requirements and acceptance criteria
-   - `design.md` if present for technical design
-   - `implement.md` if present for execution order and validation plan
+1. **Read the current native phase and its accepted implementation contract**, including referenced requirements, design, execution and validation artifacts. Use the actual references; `prd.md`, `design.md` and `implement.md` are common filenames, not proof of acceptance, freshness or implementation authorization. For the authorized taskless route, use its bounded request and applicable specs.
 
 2. **Discover packages and their spec layers**:
    ```bash

package/dist/templates/common/skills/break-loop.md

@@ -115,13 +115,7 @@ When multiple root causes are plausible and evidence is incomplete, update your
 
 Before investigating, state what you believe and why:
 
-| Hypothesis | Prior | Reasoning |
-|------------|-------|-----------|
-| H1: [cause A] | 40% | Most common for this pattern |
-| H2: [cause B] | 30% | Plausible given environment |
-| H3: [other] | 30% | Catch-all |
-
-Priors must sum to 100%. If you can't assign probabilities, investigate first.
+List plausible hypotheses with current supporting and contradicting evidence, uncertainty and a discriminating check. Qualitative confidence is sufficient; do not invent numeric probabilities or require them to sum to 100%.
 
 ### Step 2: Observe Evidence
 
@@ -148,12 +142,7 @@ Don't gather more of the same. Find evidence that **differs strongly** between t
 
 ### Step 5: State Confidence
 
-| Confidence | Action |
-|------------|--------|
-| 90%+ | Proceed with fix, monitor |
-| 70-90% | Proceed, add fallback check |
-| 50-70% | Test hypothesis before committing |
-| <50% | Need more evidence, don't guess |
+State which hypothesis the evidence supports, what it rules out, and which limits remain. Choose the next check or authorized fix based on consequences and uncertainty, not a numeric threshold. Do not add speculative fallbacks to compensate for an unverified cause.
 
 Never express binary certainty when evidence is incomplete. Use "most likely", "plausible but unlikely", "worth investigating".
 
@@ -169,16 +158,16 @@ Never express binary certainty when evidence is incomplete. Use "most likely", "
 
 ## After Analysis: Immediate Actions
 
-**IMPORTANT**: After completing the analysis above, you MUST immediately:
+After analysis, preserve the reusable finding at its natural owner:
 
-1. **Update spec/guides** - Don't just list TODOs, actually update the relevant files:
+1. **Update applicable spec/guides** when the finding establishes a reusable executable contract or thinking trigger within the task's authority:
    - If it's a cross-platform issue → update `cross-platform-thinking-guide.md`
    - If it's a cross-layer issue → update `cross-layer-thinking-guide.md`
    - If it's a code reuse issue → update `code-reuse-thinking-guide.md`
    - If it's domain-specific → update `backend/*.md` or `frontend/*.md`
 
-2. **Sync templates** - After updating `.trellis/spec/`, sync to `src/templates/markdown/spec/`
+2. **Respect the source owner** — project specs do not automatically belong in Trellis's bundled templates. Update a component template only when that component owns the rule and the task authorizes that source change; use its native generation path for installed assets.
 
-3. **Commit the spec updates** - This is the primary output, not just the analysis text
+3. **Record evidence and verification** in the current task or journal when no reusable spec change is justified. Commit only under the project's existing authorization; analysis does not grant commit, publication or installation authority.
 
-> **The analysis is worthless if it stays in chat. The value is in the updated specs.**
+Keep the finding discoverable without manufacturing a spec change or a second task ledger.