@pennixrv/trellis 0.7.1 → 0.7.2-beta.0

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>"

package/dist/templates/common/skills/update-spec.md

@@ -23,9 +23,9 @@ Apply code-spec depth when the change includes any of:
 - Database schema/migration change
 - Infra integration (storage, queue, cache, secrets, env wiring)
 
-### Mandatory Output (7 Sections)
+### Applicable Contract Coverage
 
-For triggered tasks, include all sections below:
+For triggered tasks, cover the applicable contracts below in the existing document structure. Reuse current coverage and link it where sufficient; do not require seven headings, artificial examples or empty sections for every small API change:
 1. Scope / Trigger
 2. Signatures (command/API/DB)
 3. Contracts (request/response/env)
@@ -138,7 +138,7 @@ If you added a new section or the code-spec status changed, update the category'
 
 ## Update Templates
 
-### Mandatory Template for Infra/Cross-Layer Work
+### Example Structure for Infra/Cross-Layer Work
 
 ```markdown
 ## Scenario: <name>
@@ -313,12 +313,10 @@ If you're unsure what to update, answer these prompts:
 Before finishing your code-spec update:
 
 - [ ] Is the content specific and actionable?
-- [ ] Did you include a code example?
+- [ ] Are examples included where they clarify a real contract or failure?
 - [ ] Did you explain WHY, not just WHAT?
 - [ ] Did you include executable signatures/contracts?
-- [ ] Did you include validation and error matrix?
-- [ ] Did you include Good/Base/Bad cases?
-- [ ] Did you include required tests with assertion points?
+- [ ] Are applicable validation, failure cases and verification assertions covered or linked?
 - [ ] Is it in the right code-spec file?
 - [ ] Does it duplicate existing content?
 - [ ] Would a new team member understand it?

package/dist/templates/copilot/hooks/session-start.py

@@ -231,8 +231,7 @@ def _get_task_status(trellis_dir: Path, hook_input: dict) -> str:
     if not active.task_path:
         return (
             "Status: NO ACTIVE TASK\n"
-            "Next: Classify the current turn and ask for task-creation consent "
-            "before creating any Trellis task."
+            "Next: Route through trellis-request-intake using the existing authorization and taskless contract."
         )
 
     task_ref = active.task_path
@@ -244,12 +243,10 @@ def _get_task_status(trellis_dir: Path, hook_input: dict) -> str:
         )
 
     task_json_path = task_dir / "task.json"
-    task_data: dict = {}
-    if task_json_path.is_file():
-        try:
-            task_data = json.loads(task_json_path.read_text(encoding="utf-8"))
-        except (json.JSONDecodeError, PermissionError):
-            pass  # Optional task metadata; fall back to generic status.
+    from common.io import read_json_checked  # type: ignore[import-not-found]
+    task_data, _reason = read_json_checked(task_json_path)
+    if task_data is None or task_data.get("status") not in ("planning", "in_progress", "completed", "cancelled"):
+        return f"Status: TASK_ERROR\nTask: {task_ref}\nNext: Repair the existing task record through its owner before continuing; do not create a replacement task."
 
     task_title = task_data.get("title", task_ref)
     task_status = task_data.get("status", "unknown")
@@ -379,13 +376,15 @@ def _build_compact_current_state(
     active = _resolve_active_task(trellis_dir, hook_input)
     if active.task_path:
         task_dir = _resolve_task_dir(trellis_dir, active.task_path)
-        status = "unknown"
+        status = "task_error"
         task_json = task_dir / "task.json"
         if task_json.is_file():
             try:
                 data = json.loads(task_json.read_text(encoding="utf-8"))
                 if isinstance(data, dict):
-                    status = str(data.get("status") or "unknown")
+                    value = data.get("status")
+                    if value in ("planning", "in_progress", "completed", "cancelled"):
+                        status = value
             except (json.JSONDecodeError, OSError):
                 pass  # Optional task metadata; fall back to generic status.
         lines.append(f"Current task: {_repo_relative(repo_root, task_dir)}; status={status}.")
@@ -503,11 +502,15 @@ def main() -> None:
         hook_input = json.loads(sys.stdin.read())
         if not isinstance(hook_input, dict):
             hook_input = {}
-        project_dir = Path(_normalize_windows_shell_path(hook_input.get("cwd", "."))).resolve()
+        raw_cwd = hook_input.get("cwd")
+        project_dir = Path(_normalize_windows_shell_path(raw_cwd if isinstance(raw_cwd, str) and raw_cwd else ".")).resolve()
     except (json.JSONDecodeError, KeyError):
         hook_input = {}
         project_dir = Path(".").resolve()
 
+    project_dir = next((candidate for candidate in (project_dir, *project_dir.parents) if (candidate / ".trellis").is_dir()), None)
+    if project_dir is None or not (project_dir / ".trellis" / "scripts" / "common" / "active_task.py").is_file():
+        return
     configure_project_encoding(project_dir)
 
     trellis_dir = project_dir / ".trellis"