@pennixrv/trellis 0.7.1 → 0.7.2-beta.2

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

@@ -1,31 +1,42 @@
-# Teammate configuration matrix
+# Teammate 配置矩阵
 
-The candidate source for teammate execution settings is the teammate
-configuration matrix. It is a selection input, not a new role system. A
-profile may provide a default provider and model plus provider-specific
-options. The frozen plan stores the selected execution values in the
-`Teammate Execution Configuration` snapshot so a running batch is unaffected
-by later matrix changes.
+配置由项目文件持有，运行时读取；下表解释默认选择，不替代实际文件。
 
-The tuple is:
+| 文件 | 职责 |
+| --- | --- |
+| `.trellis/agents/teammate-profiles.json`，schema 2 | `default_profile`；每个 profile 的 `role`、`default_configuration` 和 2–3 套命名 `configurations` |
+| `.trellis/agents/teammate.md` | 通用角色、只读职责和结果合同 |
+| `.trellis/agents/profiles/<profile>.md` | 精确专业角色卡；普通 Markdown，通过 Trellis 注入，不注册宿主原生角色 |
+| `.trellis/teamwork.json`，schema 2 | `default_mode`；各模式的 `default_members`、`max_concurrency`；`resources` 中的共享进程预算与非 batch 预留 |
+| `.trellis/config.yaml` 的 `teamwork.teammate_guard.idle_timeout` | 空闲清理；旧容量键仅在未迁移到 schema 2 时兼容读取 |
 
-```text
-role + provider + optional profile + model + reasoning effort + options
+默认成员数为 general 1、advisor 3、committee 3；默认并发上限分别为 8、3、3，共享存活进程预算为 8，非 batch 预留为 0。成员数用于构造计划，不要求同时运行；有效并发还受显式请求、共享预算和宿主能力约束。schema 2 不再叠加旧 YAML 容量上限，兼容读取和环境覆盖均在 `capacityPolicy.diagnostics` 中说明。`capacityPolicy` 是解析结果，不是另一套配置。
+
+每套执行配置包含 `provider`、`model`，可选 `reasoning_effort` 和适配器支持的 `options`。上下文长度沿用 provider 默认，不配置 token 或预算机制。`teammate` 是内部执行者类型，公开计划不填写 `role_id`；`lens` 只表示成员的“本次关注点”。
+
+| Profile | 工作职责 | 默认配置 | 第二候选 | 第三候选 |
+| --- | --- | --- | --- | --- |
+| `architecture` | 架构、接口、依赖与取舍 | codex / gpt-6.1-sol / xhigh | copilot / gpt-6.1-sol / xhigh | copilot / claude-opus-5.5 / xhigh |
+| `review` | 基于当前差异的正确性审查 | codex / gpt-6.1-sol / high | copilot / gpt-6.1-sol / high | copilot / claude-opus-5.5 / high |
+| `research` | 外部资料、先例与时效核验 | codex / gpt-6.1-sol / high | copilot / gpt-6.1-sol / high | copilot / claude-sonnet-5.5 / high |
+| `verification` | 独立验收、验证和证据核对 | codex / gpt-6.1-sol / high | copilot / gpt-6.1-sol / high | copilot / claude-sonnet-5.5 / high |
+| `exploration` | 围绕主题探索本地源码、调用和边界 | codex / gpt-6.1-sol / high | copilot / gpt-6.1-sol / high | copilot / claude-sonnet-5.5 / high |
+| `diagnosis` | 针对已知故障验证根因假设 | codex / gpt-6.1-sol / high | copilot / gpt-6.1-sol / high | copilot / claude-opus-5.5 / high |
+
+候选名为 `codex-sol`、`copilot-sol`，以及 `copilot-opus` 或 `copilot-sonnet`。默认 profile 为 `exploration`。先查实际设置：
+
+```bash
+trellis teamwork config --profile architecture --configuration copilot-opus --mode committee
 ```
 
-The role remains `teammate`. Coordination mode is separate from role and
-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 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
-Teamwork teammate is not the native host-created `subagent`; the two have
-different creation paths and contracts.
+成员显式覆盖执行值只作用于该成员，不改项目默认。多成员应考虑同 provider 不同模型、跨 provider 同模型或不同专业的收益，填写 `selection_reason`；不强制异构、不自动轮换、不静默 fallback。`architecture + committee` 可以让 2–3 位架构成员分别使用不同配置。
+
+构造器冻结有效执行值、通用加专业角色指令、模式结果合同、上下文、模式配置摘要和能力摘要。能力的 `evidence: adapter-contract` 说明它来自静态适配器合同，不是已安装后端的成功探测。后续改配置只影响新计划，已有计划执行时不重新解析角色文件；新计划的参考文件在派发前后核对冻结摘要。模型不可用、推理强度未被后端声明或选项不支持时明确失败，并保留实际配置协商阶段及后端声明信息。
+
+四种 transport 为 Codex app-server、Claude Code stream-json、Copilot ACP 和 DSH ACP。Copilot 原生 CLI 支持非交互调用；这里选择 ACP 是为了统一会话、配置与取消回执。DSH 使用 `dsh --profile acp`，恢复使用其声明的 `session/resume`；Copilot 使用 `session/load`。安装、账号和真实调用结果须单独核验，fixture 通过不证明某个后端已可用。
+
+Codex 使用 `developerInstructions`，Claude 使用独立的 append-system-prompt；ACP v1 只有用户内容块，Trellis 将角色与任务放在两个明确区分的纯文本块，但不宣称具有独立 system 优先级。完整角色在同一会话成功完成一轮后不重复发送，恢复或首次失败后重新建立。参考资料通过任务数据通道发送。不会动态改写 `AGENTS.md` 或注册 provider 原生 persona。
+
+源码、Git、递归委派和隐式历史使用限制是角色义务。宿主能力检查只声明实际运行能力：前台等待、受控产物、transport 和容量；不声称完成文件系统只读或记忆隔离。可用工具与宽权限模式不授予 teammate 编写产品代码的职责。
+
+工具权限自动允许，不设置默认沙箱或工具/路径准入限制。Codex 默认 `danger-full-access`、`approvalPolicy: never`；ACP 自动选择后端提供的允许选项。宿主仍可能附加 AGENTS、Skills 和环境记忆，角色摘要不代表整个有效上下文摘要。

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

@@ -7,21 +7,37 @@ evidence, path, secret, and symlink rules. The teammate writes only its
 current attempt artifacts. It does not modify product source, Git state, task
 status, or another teammate's artifacts.
 
-After a timeout, the same attempt may receive a continuation. A confirmed
-execution or acceptance failure may consume that assignment's explicit retry
-budget and create a new attempt identity. An uncertain command, changed host
-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 managed batch runtime wait yields before the frozen deadline, the CLI
+may continue waiting on the same provider process and attempt identity. This
+continuation does not send another provider prompt, extend the deadline, or
+consume the full-attempt retry budget. The CLI keeps other active slots moving
+while that wait is pending. At the deadline it closes FIFO admission and
+cancels active attempts. A confirmed execution or acceptance failure may
+consume the assignment's explicit retry budget and create a new attempt
+identity. A `blocked` report with evidence ends only that assignment and does
+not stop later FIFO work. An uncertain command, changed host identity,
+incomplete report write, 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.
+
+For an interactive Teamwork Session `wait` invoked as a host tool, resume only
+that host 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. This host-tool rule does not control a managed `teamwork batch`:
+that foreground CLI call owns the batch lifecycle and returns one receipt.
 
 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 run [name] --profile exploration --configuration codex-sol --stdin --json
+trellis teamwork spawn <name> --profile review --configuration copilot-opus \
+  --as reviewer --file .trellis/tasks/in_progress/<task-dir>/prd.md \
+  --jsonl .trellis/tasks/in_progress/<task-dir>/research.jsonl
 trellis teamwork send <name> --as <agent> --stdin
-trellis teamwork wait <name> --as <agent> --kind done,turn_finished
+trellis teamwork wait <name> --as <agent> --from reviewer --json
 trellis teamwork interrupt <name> --as <agent> --to <teammate> --stdin
 trellis teamwork kill <name> --as <teammate>
 ```
@@ -30,8 +46,106 @@ 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 project profile supplies the common and professional role cards plus
+execution defaults. `--profile` and `--configuration` select them;
+`--reasoning-effort`, `--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", "delivery" }`.
+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 reference data.
+`delivery` defaults to `inline`; `required` supplies a path, digest and an
+instruction to read the complete file before work; `on-demand` supplies a
+path, digest and retrieval condition. Required/on-demand missing files fail
+explicitly. New frozen batches recheck reference bytes before dispatch and
+after completion; changed references require a new plan. This check binds
+source versions, but does not prove the model actually read every byte.
+Legacy generic `--agent <card>` remains available for deliberately custom
+agent cards, but it cannot be combined with professional profile selection.
+Interactive roles return a schema-2 JSON content report; they do not invent batch
+claims, report paths or attempt identities.
+
+Common/professional role rules and the mode-specific result contract are
+initialization instructions. Codex uses `developerInstructions`; Claude uses
+append-system-prompt. Reference material travels with the first task as data.
+ACP has user blocks only: the role is sent once after a confirmed turn, retained
+for follow-ups, and injected again after recovery or an unsuccessful first
+turn. No JSON transport envelope is serialized into the role/task prose.
+The host may add AGENTS, Skills and memory; `TRELLIS_HOOKS=0` disables Trellis
+hooks, not all host context. No environment or memory isolation is claimed.
+
+All providers automatically allow tool permissions. Codex defaults to
+`danger-full-access` with `approvalPolicy: never`; an explicit user sandbox
+override is still supported. ACP selects the offered allow option and reports
+an error if none exists. Role boundaries remain prompt obligations.
+
+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 live budget and mode capacity come from schema-2 `.trellis/teamwork.json`;
+explicit CLI flags and environment overrides may tighten the frozen policy.
+Legacy `.trellis/config.yaml` teammate keys are ignored with diagnostics;
+the separate idle timeout remains a process-lifecycle setting.
+`--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.
+
+Codex interrupts use `turn/interrupt` and await the old terminal turn before
+submitting the replacement. ACP sends `session/cancel` and awaits the terminal
+prompt response; sending a notification alone is not cancellation proof.
+Batch cancellation additionally confirms provider process exit. Unconfirmed
+termination preserves reconciliation and its capacity reservation. Session
+removal and prune preserve sessions with unresolved batch reservations.
+
+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 only after a valid complete content report.
+`run --json` returns the common machine envelope and keeps failure diagnostics;
+early supervisor errors/kills terminate the wait without hiding the cause.
+`wait --json --from <one-worker>` binds the final report to `inputSeq` and
+`turnId`; it does not stop the persistent worker. Default event waits retain
+their existing behavior. 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 reports and worklogs, including rejected attempts, remain until explicit
+native cleanup; the result includes every attempt index. The
+Teamwork Session event log follows its own lifecycle.
+
+`teamwork cleanup-artifacts <plan> --task <task-dir>` previews the exact retained
+report/worklog/stderr files of a durably settled batch. Only an explicit repeat
+with `--confirm <preview-digest>` deletes those files; a changed preview or an
+unresolved reservation is rejected. Read and accept needed evidence before
+cleanup. Session removal alone does not delete task-owned attempt evidence.
+
+Use `teamwork reconcile <original-plan> --task <task-dir>` to preview recovery
+after coordinator loss. `--execute --reason <disposition>` only settles when
+native process-exit facts or process birth identity prove termination. A missing
+PID, absent report, or dead coordinator alone is insufficient. This command
+preserves accepted assignments and releases only the original batch's leases.
+It does not restart providers or accept task results.
+
+After a durable failed settlement and explicit bounded retry approval, construct
+`teamwork retry <original-plan> --task <task-dir> --output <new-plan> --batch <new-id>
+--assignments <failed-id,...> --deadline <ISO-time> --approval-ref <approval>`.
+Only failed assignments enter the new plan; frozen inputs and parent lineage
+are retained. Repeating the same output is idempotent. Execute the new plan
+normally; the original terminal result remains unchanged. A recovered subset
+does not retroactively accept the original committee evaluation.
+
+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

@@ -14,10 +14,14 @@ coordination_mode
 ```
 
 The plan also freezes the Teamwork Session, batch, deadline, protected targets,
-and ordered `assignments`. Each assignment has an `assignment_id`, brief path,
-role, provider, optional profile and model, scope, lens, source digest,
-acceptance criteria, and an explicit retry budget. The CLI validates the plan
-and the immutable brief before dispatch.
+and ordered `assignments`. Each assignment has an `assignment_id`, selected
+profile/configuration, selection reason, task input, scope, optional lens,
+source digest, acceptance criteria, and an explicit retry budget. The native
+constructor resolves the effective provider/model/effort/options and common
+plus professional instructions, then publishes schema-2 plan and briefs.
+Claims also use schema 2; new launches freeze `reportVersion: 2`. Historical
+frozen launches without it continue to read schema-1 reports. Do not hand-author frozen
+execution objects, role or capability digests, claims, or plan hashes.
 
 Use the native task lifecycle for task status and acceptance. Teamwork records
 coordination facts and teammate reports; it does not write `current_phase_id`,
@@ -39,40 +43,168 @@ 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:
+Construct and run through the native entry points:
 
 ```bash
-trellis teamwork batch <plan-path>
+trellis teamwork config --profile review --mode advisor
+trellis teamwork plan <draft.json> --task <task-dir> --output <task-dir>/plan.json --dry-run
+trellis teamwork plan <draft.json> --task <task-dir> --output <task-dir>/plan.json
+trellis teamwork batch <task-dir>/plan.json --task <task-dir> --preflight
+trellis teamwork batch <task-dir>/plan.json --task <task-dir> --json
 ```
 
-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 draft is a JSON object with `schema_version: 2`, the binding fields above,
+safe `batch_id` and `session_id`, `deadline`, optional `requested_capacity`
+and `protected_targets`, and explicit `assignments`. A minimal member is:
+
+```json
+{
+  "assignment_id": "review-a",
+  "profile": "review",
+  "configuration": "codex-sol",
+  "selection_reason": "Use the configured source reviewer",
+  "summary": "Review the selected change",
+  "scope": "src/example.ts",
+  "input": "Inspect the assigned source and return evidence in the requested report.",
+  "source_digest": "<SHA-256 of the selected source evidence>",
+  "acceptance": ["Cite precise source locations and explain observable impact"],
+  "max_retries": 0
+}
+```
+
+Optional member overrides are `provider`, `model`, `reasoning_effort`, and
+adapter-supported `options`; context comes from `context_files` and
+`context_manifests`. Committee members additionally need distinct `lens`
+values and otherwise share the same task/evidence/acceptance contract. The
+constructor creates their evaluation group. Read the configuration matrix
+before choosing candidates. Output must be inside the selected task under
+this project's `.trellis/tasks/`; existing immutable artifacts are preserved.
+
+`--dry-run` validates all prepared briefs and paths without writing artifacts.
+`--preflight` validates frozen inputs, current native task revisions and
+capacity without launching a provider; `processProbe: not_run` means accounts,
+models and transport have not been tested by that command. Actual dispatch
+negotiates provider model and effort and fails explicitly if unsupported.
+
+Invoke one foreground `trellis teamwork batch` command and wait for its
+receipt. The CLI owns FIFO admission, capacity, provider waits, retries,
+cancellation, report acceptance, and settlement. The main agent does not
+schedule per-assignment waits or retries. A timeout continuation waits on the
+same provider process under the frozen batch deadline; it does not send another
+provider prompt or consume a full-attempt retry. At the batch deadline, the CLI
+closes admission, marks undispatched FIFO work `FINAL_FAILED`, then cancels and
+drains active attempts. Confirmed outcomes settle as `SETTLED_WITH_FAILURE`;
+unconfirmed process exit requires reconciliation.
+
+A valid `blocked` report with evidence ends only that assignment as
+`FINAL_FAILED`; the CLI continues with the remaining FIFO work and preserves
+the blocker report. Missing reports may use the assignment's declared retry
+budget. A truncated report or report storage error is uncertain and requires
+reconciliation. Other incomplete or rejected reports may retry only within the
+declared attempt budget.
+
+`run` and `spawn` operate interactive sessions and do not bypass batch
+reconciliation. A restart returns a durable terminal receipt or
+`RECONCILIATION_REQUIRED`; it never silently replays an uncertain attempt.
+Before returning a recovered terminal receipt, the CLI checks the frozen plan,
+all assignment dispositions, terminal attempt and teammate facts, capacity
+leases, projection issues, and the exact receipt event. It may reconstruct a
+missing receipt only from consistent terminal facts. Capacity reservations
+survive a coordinator crash because a dead coordinator does not prove its
+provider processes exited. Do not delete an unresolved reservation to make
+another batch fit; inspect ownership and terminal evidence. An unreadable or
+conflicting recovery state retains the reservation and original evidence; it
+does not authorize a replacement dispatch.
 
 ## 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/in_progress/<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
+trellis teamwork wait <name> --as <agent> --from <worker> --json
 trellis teamwork forum <name>
 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
 
+Agent callers always request the machine view: `run --json`, `batch --json`,
+or interactive `wait --json --from <one-worker>`. The common envelope has
+`schemaVersion: 1`, `kind: trellis_result`, `mode`, `association`, `execution`,
+`reports`, `semanticValidation: not_run`, and `disposition`. Execution facts
+are distinct from report validation, model content status, and task acceptance.
+`execution.stopped` describes confirmed process cleanup; a persistent wait
+leaves its worker running. Parse stdout as one JSON object; diagnostics use
+stderr. CLI argument-parser errors may precede this result contract.
+
+Each new content report has `schema_version: 2`, `status` (complete, blocked,
+incomplete, error), nonempty `answer`, nonempty `evidence` entries with
+`id`, `locator`, `summary`, and arrays `limitations`, `unresolved`, `deviations`.
+Interactive replies return this JSON directly, with no report file or invented
+batch identity. Batch reports additionally copy the assigned task, batch,
+assignment, attempt, teammate, plan, phase, route, input and source identities
+into the exact report path. `done` is emitted by the adapter, not by the model.
+
+Batch machine results expose validated report content, association, report path
+and SHA-256. Missing or invalid accepted artifacts fail validation; historical
+schema-1 content is explicitly `legacy`, never synthesized as a valid new
+answer. Retention may remove failed-attempt artifacts. Main-agent semantic
+review checks the answer and evidence against the acceptance criteria; shape
+validation does not perform that review or change native task acceptance.
+
 The coordinator returns `ALL_ACCEPTED`, `SETTLED_WITH_FAILURE`, or
-`RECONCILIATION_REQUIRED`. A terminal receipt is a runtime fact. The main task
-then reviews reports against the phase contract, records durable evidence in
-the task-owned artifact, and uses the task's native acceptance gate before
-advancing. A formal session handoff is an independent, lower-priority
-continuity artifact and does not represent a phase transition.
+`RECONCILIATION_REQUIRED`. For `ALL_ACCEPTED`, review every accepted report
+against the phase contract, record the evidence in the task-owned artifact, and
+use the native task acceptance gate before advancing. For
+`SETTLED_WITH_FAILURE`, review the failure reports and blockers, do not accept
+or advance the phase, and decide the next task-level action through the native
+workflow. For `RECONCILIATION_REQUIRED`, stop dispatch, retry, and cleanup;
+preserve the reported runtime evidence and reservation for explicit
+reconciliation. A receipt is a runtime fact, not phase acceptance. A formal
+session handoff is an independent, lower-priority continuity artifact and does
+not represent a phase transition.

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.

package/dist/templates/common/skills/check.md

@@ -13,11 +13,7 @@ git status
 
 ## Step 2: Read Task Artifacts and Applicable Specs
 
-Read the current task artifacts in order:
-
-- `prd.md`
-- `design.md` if present
-- `implement.md` if present
+Read the current native phase, accepted contract and its actual artifact references for requirements, design, execution and validation. Common filenames such as `prd.md`, `design.md` and `implement.md` do not prove current acceptance or authorization. For taskless work, check the authorized bounded request.
 
 ```bash
 python3 ./.trellis/scripts/get_context.py --mode packages
@@ -33,7 +29,7 @@ Read the specific guideline files referenced — the index is a pointer, not the
 
 ## Step 3: Run Project Checks
 
-Run the project's lint, type-check, and test commands. Fix any failures before proceeding.
+Run the applicable required project checks and verification appropriate to the changed behavior and risk. Investigate failures and fix those caused by the change within its authorization; record unrelated baseline failures and unavailable checks accurately. Do not silently expand the task to repair unrelated failures or claim checks passed when evidence is incomplete.
 
 ## Step 4: Review Against Checklist
 
@@ -47,9 +43,9 @@ Run the project's lint, type-check, and test commands. Fix any failures before p
 
 ### Test Coverage
 
-- [ ] New function → unit test added?
-- [ ] Bug fix → regression test added?
-- [ ] Changed behavior → existing tests updated?
+- [ ] Non-trivial new behavior and risk covered by meaningful existing or new tests?
+- [ ] Bug fix reproduced by a regression check at the actual entry path?
+- [ ] Changed behavior reflected in tests without mirroring implementation details?
 
 ### Spec Sync
 
@@ -80,7 +76,7 @@ Skip this step if your change is confined to a single layer.
 
 - [ ] Searched for existing similar code before creating new?
   ```bash
-  grep -r "pattern" src/
+  rg "pattern" src/
   ```
 - [ ] If the same value repeats, does it represent one stable concept whose callers must change together? Extract only then — two literals that merely happen to match today should stay separate.
 - [ ] After batch modification, all occurrences updated?
@@ -101,6 +97,6 @@ Skip this step if your change is confined to a single layer.
 Report every violation you find. Then:
 
 - Mechanical and local (lint nit, missing type, wrong import, dead branch, failing assertion) → fix in place, then re-run project checks.
-- Design or judgment (naming a shared concept, moving a module boundary, changing a public interface, reassigning where behavior lives) → record the evidence and your recommendation, and stop. Do not rewrite it silently.
+- Local engineering judgment within the accepted contract → resolve it with evidence and continue. A material unresolved change to scope, public behavior, ownership, risk or acceptance → record the recommendation and pause dependent work for the project's decision process.
 
 If a fix would touch files outside the current task's scope, say so and stop instead of widening the change.

package/dist/templates/common/skills/{brainstorm.md → request-intake.md}

@@ -1,10 +1,12 @@
-# Trellis Brainstorm
+# Trellis Request Intake
 
-Use this entry skill for a new request that needs a Trellis task. For a clear, low-risk, reversible, authorized, immediately verifiable request, follow the taskless route in workflow.md.
+Use this entry skill to route a new request. First check its relationship to the active task: a change to the same goal returns to the earliest affected phase; independent work needs its own intake. Do not put unrelated work into the active task or bypass its ownership and acceptance gates. To resume existing work, use trellis-continue and the current native task facts.
+
+Reuse verified evidence and existing authorization. For a clear, low-risk, reversible, authorized, immediately verifiable request, follow the taskless route in workflow.md. Intake ends when the request reaches its appropriate phase; do not repeat session initialization or conduct a second requirements or planning workflow here.
 
 ## Start the task
 
-1. Inspect only repository evidence that can change the goal, scope, acceptance criteria, constraints, or route. Ask the user when intent or a material choice remains unclear.
+1. Inspect only evidence that can change the goal, scope, acceptance criteria, constraints, or route. Ask the user only for missing intent or a material user choice; use the project's decision method when needed.
 2. Create a Trellis task when the work needs a persistent route, coordination, or review:
 
        {{PYTHON_CMD}} ./.trellis/scripts/task.py create "<title>" --description "<summary>"