@pennixrv/trellis 0.7.0-beta.40 → 0.7.0-beta.41

package/dist/migrations/manifests/0.7.0-beta.41.json

@@ -0,0 +1,9 @@
+{
+  "version": "0.7.0-beta.41",
+  "description": "Read-only research completion and explicit subnode dispatch approval",
+  "breaking": false,
+  "recommendMigrate": false,
+  "changelog": "Allow complex and cross-owner analysis-only work to complete in planning without implementation approval. Require a frozen, explicitly approved evidence plan before requested subnode dispatch; preserve change-bearing Planning Seal and approval.",
+  "migrations": [],
+  "notes": "No migrations. Research remains bounded by the protected-target no-change contract."
+}

package/dist/templates/common/bundled-skills/trellis-channel/references/subnode-work.md

@@ -136,9 +136,13 @@ For `blocked`, `incomplete`, or `error`, include the same base fields plus a
 `blocker` string. Never use
 `accepted`, `rejected`, or `deferred` as a report status.
 
+## Dispatch Approval
+
+A request for research authorizes main-session evidence work; it does not by itself approve a subnode dispatch plan that has not yet been presented. Before any subnode `spawn` or `send`, persist and present the frozen plan in the active task. It must identify the research question, exact evidence-unit-to-scope mapping and grouping rationale, each brief's evidence range/sources, stop condition and report destination, concurrency/slot strategy, initial fill and FIFO refill/acceptance rules, and material dependencies. Record the user's explicit approval in that artifact. Approval is limited to the listed evidence work and grants no implementation authority. A material change to units, scope, method, owner, risk, or acceptance requires a newly frozen plan and approval before further affected dispatch. The main session may continue its own evidence work while awaiting dispatch approval.
+
 ## Dispatch And Wait
 
-Inspect the installed role first, then capture a durable event barrier before
+After the frozen plan is approved, inspect the installed role first, then capture a durable event barrier before
 the worker can emit a terminal event. The CLI waits once for a worker lifecycle
 transition after that barrier, including supervisor-authored terminal events:
 

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

@@ -50,13 +50,13 @@ Run only when the phase or routing rule is missing; otherwise reuse it.
 
 `get_context.py` shows the active task's `status` field. Route by `status` + artifact presence. This command replaces the user needing to remember the Trellis flow; it does not itself approve implementation.
 
-- `status=planning` + `task.json.meta.delivery_mode = "analysis_only"` → first confirm the task still satisfies the bounded evidence-only eligibility rule; then complete the PRD's evidence work, verify its acceptance criteria and no-change boundary, and archive directly. Do not run `task.py start`; a protected-target change requires a separate change-bearing task.
+- `status=planning` + `task.json.meta.delivery_mode = "analysis_only"` → verify the PRD's bounded evidence deliverable and protected-target no-change boundary, then complete the evidence and archive directly regardless of complexity or cross-owner scope. Do not run `task.py start`; a protected-target change requires a separate change-bearing task.
 - `status=planning` + no `prd.md` → **1.1** (load `trellis-brainstorm`)
-- `status=planning` + a recorded `decision-needed` or unsealed decision chain → return to the planning frontier and load `pennix-decision-grill` when independent material questions can be batched.
+- `status=planning` + a recorded `decision-needed` or unsealed decision chain → return to `pennix-decision-grill` only for a change-bearing decision or a user-owned choice that materially defines the requested research scope or method; research recommendations and open product choices alone do not trigger the gate.
 - `status=in_progress` + a material unresolved decision → record the reason and run `task.py replan <task> "<reason>"`; do not ask a native question during implementation.
 - `status=planning` + `prd.md` only → decide whether the task is lightweight or complex. Lightweight can move to **1.4** review; complex returns to **1.1** to add `design.md` + `implement.md`.
 - `status=planning` + complex artifacts complete + sub-agent jsonl not curated (empty, or only a legacy `_example` placeholder row) → **1.3**
-- `status=planning` + required artifacts complete + required jsonl curated or inline mode → run the Planning Seal closure pass, then **1.4**. Existing authorization must be a later explicit implementation approval for this task's current sealed material revision. Initial requests, design answers, and parent-task approval do not qualify. Use native plan seal/approve/start; ask only when that approval is missing. A replan invalidates it; minor progress edits do not.
+- `status=planning` + required artifacts complete + required jsonl curated or inline mode → for change-bearing work, run the Planning Seal closure pass, then **1.4**; require later explicit implementation approval for the current sealed revision and use native plan seal/approve/start. `analysis_only` work completes its evidence and archives without this path. A replan invalidates change-bearing approval; minor progress edits do not.
 - `status=in_progress` + implementation not started → **2.1**
 - `status=in_progress` + implementation done, not yet checked → **2.2**
 - `status=in_progress` + check passed → **3.3** (spec update) → **3.4** (commit)

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

@@ -6,13 +6,13 @@ A request to build, implement, fix, refactor, or "go ahead" is not approval to l
 
 For every non-trivial task, the user must respond at least once after the initial request before implementation begins. If no clarification is needed, that response must approve the final planning summary described below.
 
-While any user-owned product, scope, UX, compatibility, risk, or acceptance decision remains unresolved, keep the task in planning. First inventory evidence and decision dependencies. If at least two independent material decisions remain and `pennix-decision-grill` is available, delegate one bounded batch of up to three frontier questions; otherwise ask the single highest-value question. Do not edit product code, dispatch implementation, or run `task.py start` until the decision chain is sealed.
+Keep the task in planning while a user-owned choice needed to define the requested work remains unresolved. For `analysis_only`, findings, recommendations, and open product options do not block evidence work or require a sealed decision chain. For change-bearing work, inventory evidence and decision dependencies; batch independent material questions with `pennix-decision-grill` when useful, and do not implement or run `task.py start` until change decisions are sealed and approved.
 
 ## Analysis-Only Exception
 
 When `task.json.meta.delivery_mode = "analysis_only"` exactly and the PRD names a bounded evidence deliverable plus a no-change boundary for product source, runtime configuration, deployment, credentials, and external systems, task-creation consent authorizes that evidence work. Do not require a second planning approval or run `task.py start`: perform the declared research, audit, or design work while status remains `planning`, record the evidence, verify acceptance criteria and the boundary, commit task artifacts, and archive directly. If the evidence recommends a protected-target change, record it and create a separate change-bearing task before doing it.
 
-This exception is eligible only for a bounded evidence deliverable with no material user decision, design or implementation plan, cross-owner coordination, security or deployment change, release or credential action, or protected downstream task. Calling work "research", deferring source edits, or working in an audit/root repository does not make it analysis-only. If any of those conditions apply, use the normal complex planning and implementation-approval path.
+This route remains eligible for bounded evidence work regardless of complexity, cross-owner scope, multiple evidence units, or whether conclusions include recommendations or unresolved product choices. Record findings and recommendations in task artifacts; do not change protected targets, deploy, release, alter credentials, or mutate external systems. The initial request authorizes the requested main-session research, so do not require a second implementation approval, Planning Seal, or `task.py start` to complete it. If the user requests independent subnode evidence, freeze its dispatch plan in the task first and obtain explicit approval of that plan before any spawn/send; this approval authorizes only the listed evidence dispatch. If implementation is later requested, create or replan a change-bearing task and use its normal Planning Seal and implementation approval gates.
 
 All other tasks follow the planning and implementation approval gates below.
 
@@ -69,12 +69,11 @@ Use a concise title from the user's request. Both the title and `--description`
    - product intent still needed from the user
    - scope or risk decisions still needed from the user
    - likely out-of-scope items
-4. If user-owned decisions remain, calculate the independent frontier. Use `pennix-decision-grill` for a bounded batch when two or more independent material decisions are ready; otherwise ask the single highest-value question. Include recommendation and trade-off. Yield only while the answer is unavailable.
-5. When the host returns the current continuation's answer, immediately persist it in `prd.md` or the decision artifact, recheck evidence and conflicts, recalculate the frontier, and continue the same planning loop. Do not create a second Trellis lifecycle for the same decision chain. Stop only for a new unresolved frontier, a real capability or authority block, or a final sealed summary awaiting implementation approval.
-6. When no user-owned decision remains, create or update `design.md` and `implement.md` for complex tasks.
-7. Run the requirement convergence gate, then the PRD convergence pass. Finish with one Planning Seal closure pass.
-8. Present the final planning summary and stop. Do not run `task.py start` or edit product code in the same turn.
-9. For planned/change-bearing tasks, classify `execution_class=planned` and `delivery_mode=change_bearing` in native task meta, then run `task.py plan seal <task>` after closure. Only a subsequent user message explicitly approving this task's current material plan authorizes `task.py plan approve <task> --revision <n> --basis "<short non-sensitive actual approval basis>"`, followed by `task.py start` and implementation. Initial delivery requests, parent-task approval, and design answers are insufficient. If scope, owner, risk, public behavior, or acceptance materially changes, run `task.py replan <task> "<reason>"`; it invalidates seal/approval. Return through planning, seal the new revision, present it, and obtain later approval. Minor wording, formatting, and progress records do not require resealing. The native record enforces structure, not authenticity of chat approval.
+4. If the requested research scope or method depends on an unresolved user-owned choice, ask only that material question; otherwise proceed with the evidence work already requested. Use `pennix-decision-grill` to batch independent choices only when needed to define the requested work. A research recommendation or open product choice can be reported as a finding without being decided or sealed for implementation.
+5. If the user requests independent subnode evidence, first freeze the dispatch plan in the task: question, evidence-unit mapping and grouping rationale, brief scope/stop conditions/destinations, concurrency and FIFO refill/acceptance method. Obtain the user's explicit approval of that frozen plan before any spawn/send. This approval covers only the listed evidence dispatch; material changes to units, scope, method, owner, risk, or acceptance require reapproval. Main-session evidence work may continue while dispatch approval is pending.
+6. When a needed answer returns, persist it, recheck evidence, and continue the same task. Do not create a second lifecycle for the same decision chain.
+7. For `analysis_only`, record and verify the declared evidence and no-change boundary in planning; do not require `design.md`, `implement.md`, a Planning Seal, implementation approval, or `task.py start` merely because the research is complex.
+8. For change-bearing work, resolve material decisions, create/update complex-task artifacts, run the requirement convergence and PRD passes, then close and present the Planning Seal. Stop before implementation. Only a later explicit approval for this task's current sealed revision authorizes native plan approval and `task.py start`. Initial requests, parent-task approvals, and design answers do not qualify. Material changes require `task.py replan` and approval of its newly sealed revision; progress and wording edits do not.
 
 When changing the active task only for planning, use native `task.py select`,
 not start. `create --no-start` intentionally preserves the old pointer. Follow
@@ -97,9 +96,7 @@ Do not ask process questions such as whether to search, inspect files, or contin
 
 Recommendations are not default selections. Never choose a recommended product decision on the user's behalf merely because the user asked for implementation.
 
-Do not manufacture clarification questions when the request and repository evidence already resolve every decision. In that case, proceed directly to the final planning summary, which still requires a subsequent explicit approval.
-
-The final review is a required phase-transition gate, not a prohibited process question. Task-creation consent, the initial implementation request, and approval given before the latest final summary do not satisfy this gate.
+Do not manufacture clarification questions when the request and repository evidence already resolve the scope and method. For `analysis_only`, proceed with the requested evidence work; no final implementation review or approval is required. The final review and subsequent approval are phase-transition gates for change-bearing implementation only.
 
 ## Thinking Framework: First Principles Analysis
 
@@ -155,11 +152,11 @@ Before final review, verify all of the following:
 - blocking open questions are empty
 - technical unknowns are researched or explicitly deferred without changing MVP behavior
 
-Lightweight tasks may omit `design.md` and `implement.md`; they may not skip evidence inspection, requirement convergence, final review, or fresh implementation approval.
+For `analysis_only`, keep the task PRD bounded to evidence and the protected-target no-change boundary; it may omit `design.md` and `implement.md` and does not need an implementation review or approval. Change-bearing tasks retain their applicable evidence, convergence, final review, and fresh implementation approval gates.
 
 The final planning summary must show Goal, In Scope, Out of Scope, Acceptance Criteria, Key Decisions, relevant Risks or Deferred Items, and artifact status.
 
-The Planning Seal closure pass must reconcile `task.json`, `prd.md`, `design.md`, `implement.md`, research, decision records, and manifests; verify the actual modification targets and branches, ordered dependencies and release steps, validation and rollback, dynamic-fact dispositions and replan triggers, and that every material decision has an owner and a fixed outcome. Remove static ambiguity before implementation: no `TBD`, `TODO`, `decision-needed`, unowned option, unspecified branch, open implementation path, validation gap, or conditional acceptance may remain. A material discovery invalidates the seal and returns to planning; implementation may consume only a sealed plan.
+For change-bearing work, the Planning Seal closure pass reconciles task artifacts, targets, branches, dependencies, release, validation, rollback, dynamic facts, and material decisions before implementation; unresolved implementation ambiguity invalidates the seal. This closure pass is not an eligibility or completion gate for `analysis_only` evidence work.
 
 ## Artifact Rules
 
@@ -208,15 +205,12 @@ After the pass, read `prd.md` top to bottom and verify that no fact is repeated
 
 ## Quality Bar
 
-Before declaring planning ready:
+Before declaring change-bearing planning ready:
 
-- `prd.md` contains testable acceptance criteria.
-- `prd.md` has passed the PRD convergence pass: no unresolved temporary brainstorm sections, no duplicate facts across sections, and no lost anchors, decisions, or acceptance mappings.
-- Repository-answerable questions have already been answered through inspection.
-- Blocking open questions are empty.
-- Complex tasks have `design.md` and `implement.md`.
-- Sub-agent-dispatch tasks have real curated entries in both `implement.jsonl` and `check.jsonl`; seed-only manifests are not ready.
-- The latest final planning summary has been presented to the user.
-- In a subsequent message, the user explicitly approved that summary for implementation.
+- `prd.md` contains testable acceptance criteria and has passed the PRD convergence pass.
+- Repository-answerable questions have been answered; blocking implementation questions are resolved.
+- Complex change-bearing tasks have `design.md` and `implement.md`; sub-agent-dispatch implementation tasks have curated manifests.
+- The Planning Seal and final summary cover the implementation target, validation, and rollback.
+- The user subsequently approved this task's current sealed plan.
 
-Do not start implementation merely because the user originally asked for implementation.
+For `analysis_only`, verify the declared evidence deliverable and protected-target no-change boundary, then proceed to complete the research in planning without an implementation summary approval. Do not start change-bearing implementation merely because the user originally requested it.

package/dist/templates/copilot/prompts/brainstorm.prompt.md

@@ -10,11 +10,11 @@ A request to build, implement, fix, refactor, or "go ahead" is not approval to l
 
 For every non-trivial task, the user must respond at least once after the initial request before implementation begins. If no clarification is needed, that response must approve the final planning summary described below.
 
-While any user-owned product, scope, UX, compatibility, risk, or acceptance decision remains unresolved, keep the task in planning. First inventory evidence and decision dependencies. If at least two independent material decisions remain and `pennix-decision-grill` is available, delegate one bounded batch of up to three frontier questions; otherwise ask the single highest-value question. Do not edit product code, dispatch implementation, or run `task.py start` until the decision chain is sealed.
+Keep the task in planning while a user-owned choice needed to define the requested work remains unresolved. For `analysis_only`, findings, recommendations, and open product options do not block evidence work or require a sealed decision chain. For change-bearing work, inventory evidence and decision dependencies; batch independent material questions with `pennix-decision-grill` when useful, and do not implement or run `task.py start` until change decisions are sealed and approved.
 
 ## Analysis-Only Exception
 
-When `task.json.meta.delivery_mode = "analysis_only"` exactly and the PRD names a bounded evidence deliverable plus a no-change boundary for product source, runtime configuration, deployment, credentials, and external systems, task-creation consent authorizes that evidence work. Keep status `planning`, record and verify the evidence, commit task artifacts, and archive directly; do not run `task.py start` or wait for a second implementation approval. This exception is eligible only when there is no material user decision, design or implementation plan, cross-owner coordination, security or deployment change, release or credential action, or protected downstream task. Otherwise use normal complex planning.
+When `task.json.meta.delivery_mode = "analysis_only"` exactly and the PRD names a bounded evidence deliverable plus a no-change boundary for product source, runtime configuration, deployment, credentials, and external systems, task-creation consent authorizes that evidence work. Keep status `planning`, record and verify the evidence, commit task artifacts, and archive directly; do not run `task.py start` or wait for a second implementation approval. This route remains eligible regardless of complexity, cross-owner scope, multiple evidence units, or whether findings include recommendations or unresolved product choices. Record these in task artifacts without changing protected targets, deploying, releasing, altering credentials, or mutating external systems. The initial request authorizes the requested main-session research; do not require a second implementation approval, Planning Seal, or `task.py start`. If independent subnode evidence is requested, freeze its dispatch plan in the task and obtain explicit approval before any spawn/send; that approval authorizes only the listed evidence dispatch. A later implementation request needs a change-bearing task and its normal Planning Seal and implementation approval gates.
 
 ## Non-Negotiable Evidence Rule
 
@@ -60,12 +60,11 @@ Use a concise title from the user's request. Both the title and `--description`
    - product intent still needed from the user
    - scope or risk decisions still needed from the user
    - likely out-of-scope items
-4. If user-owned decisions remain, calculate the independent frontier. Use `pennix-decision-grill` for a bounded batch when two or more independent material decisions are ready; otherwise ask the single highest-value question. Include recommendation and trade-off. Yield only while the answer is unavailable.
-5. When the host returns the current continuation's answer, persist it in `prd.md` or the decision artifact, recheck evidence and conflicts, recalculate the frontier, and continue the same planning loop. Stop only for a new unresolved frontier, a real capability or authority block, or a final sealed summary awaiting implementation approval.
-6. When no user-owned decision remains, create or update `design.md` and `implement.md` for complex tasks.
-7. Run the requirement convergence gate, then the PRD convergence pass. Finish with one Planning Seal closure pass.
-8. Present the final planning summary and stop. Do not run `task.py start` or edit product code in the same turn.
-9. Only a subsequent user message that explicitly approves the latest planning summary authorizes `task.py start` and implementation. If implementation reveals a material unresolved decision, record `decision-needed`, run `task.py replan <task> "<reason>"`, and return through this planning flow; do not open a popup during implementation.
+4. If the requested research scope or method depends on an unresolved user-owned choice, ask only that material question; otherwise proceed with the evidence work already requested. Use `pennix-decision-grill` to batch independent choices only when needed to define the requested work. A research recommendation or open product choice can be reported as a finding without being decided or sealed for implementation.
+5. If the user requests independent subnode evidence, first freeze the dispatch plan in the task: question, evidence-unit mapping and grouping rationale, brief scope/stop conditions/destinations, concurrency and FIFO refill/acceptance method. Obtain the user's explicit approval of that frozen plan before any spawn/send. This approval covers only the listed evidence dispatch; material changes to units, scope, method, owner, risk, or acceptance require reapproval. Main-session evidence work may continue while dispatch approval is pending.
+6. When a needed answer returns, persist it, recheck evidence, and continue the same task.
+7. For `analysis_only`, record and verify the declared evidence and no-change boundary in planning; do not require a Planning Seal, implementation approval, or `task.py start` merely because the research is complex.
+8. For change-bearing work, resolve material decisions, create/update complex-task artifacts, run the requirement convergence and PRD passes, then close and present the Planning Seal. Stop before implementation. Only later explicit approval of this task's current sealed revision authorizes native plan approval and `task.py start`; material changes require `task.py replan` and approval of its newly sealed revision.
 
 Do not invent a project-specific product/spec hierarchy. If the repository already has product, domain, or spec docs, use them. If it does not, proceed with the evidence that exists.
 
@@ -84,9 +83,7 @@ Do not ask process questions such as whether to search, inspect files, or contin
 
 Recommendations are not default selections. Never choose a recommended product decision on the user's behalf merely because the user asked for implementation.
 
-Do not manufacture clarification questions when the request and repository evidence already resolve every decision. In that case, proceed directly to the final planning summary, which still requires a subsequent explicit approval.
-
-The final review is a required phase-transition gate, not a prohibited process question. Task-creation consent, the initial implementation request, and approval given before the latest final summary do not satisfy this gate.
+Do not manufacture clarification questions when the request and repository evidence already resolve the scope and method. For `analysis_only`, proceed with the requested evidence work; no final implementation review or approval is required. The final review and subsequent approval are phase-transition gates for change-bearing implementation only.
 
 ## Requirement Convergence Gate
 
@@ -99,11 +96,11 @@ Before final review, verify all of the following:
 - blocking open questions are empty
 - technical unknowns are researched or explicitly deferred without changing MVP behavior
 
-Lightweight tasks may omit `design.md` and `implement.md`; they may not skip evidence inspection, requirement convergence, final review, or fresh implementation approval.
+For `analysis_only`, the task PRD may stay bounded to evidence and the protected-target no-change boundary; no implementation review or approval is required. Change-bearing tasks retain their applicable evidence, convergence, final review, and fresh implementation approval gates.
 
 The final planning summary must show Goal, In Scope, Out of Scope, Acceptance Criteria, Key Decisions, relevant Risks or Deferred Items, and artifact status.
 
-The Planning Seal closure pass reconciles `task.json`, `prd.md`, `design.md`, `implement.md`, research, decision records, and manifests; verifies targets, branches, dependencies, release, validation, rollback, dynamic-fact dispositions, and replan triggers; and fixes every material decision to an owner and outcome. No `TBD`, `TODO`, `decision-needed`, unowned option, unspecified branch, open implementation path, validation gap, or conditional acceptance may remain. Any material discovery invalidates the seal and returns to planning.
+For change-bearing work, the Planning Seal reconciles task artifacts, targets, branches, dependencies, release, validation, rollback, dynamic facts, and material decisions before implementation. It is not an eligibility or completion gate for `analysis_only` evidence work.
 
 ## Artifact Rules
 
@@ -152,15 +149,14 @@ After the pass, read `prd.md` top to bottom and verify that no fact is repeated
 
 ## Quality Bar
 
-Before declaring planning ready:
+Before declaring change-bearing planning ready:
+
+- `prd.md` contains testable acceptance criteria and has passed the PRD convergence pass.
+- Repository-answerable questions have been answered; blocking implementation questions are resolved.
+- Complex change-bearing tasks have `design.md` and `implement.md`; sub-agent-dispatch implementation tasks have curated manifests.
+- The Planning Seal and final summary cover the implementation target, validation, and rollback.
+- The user subsequently approved this task's current sealed plan.
 
-- `prd.md` contains testable acceptance criteria.
-- `prd.md` has passed the PRD convergence pass: no unresolved temporary brainstorm sections, no duplicate facts across sections, and no lost anchors, decisions, or acceptance mappings.
-- Repository-answerable questions have already been answered through inspection.
-- Blocking open questions are empty.
-- Complex tasks have `design.md` and `implement.md`.
-- Sub-agent-dispatch tasks have real curated entries in both `implement.jsonl` and `check.jsonl`; seed-only manifests are not ready.
-- The latest final planning summary has been presented to the user.
-- In a subsequent message, the user explicitly approved that summary for implementation.
+For `analysis_only`, verify the declared evidence deliverable and protected-target no-change boundary, then proceed to complete the research in planning without an implementation summary approval.
 
 Do not start implementation merely because the user originally asked for implementation.

package/dist/templates/trellis/workflow.md

@@ -208,11 +208,9 @@ Phase 3: Finish  → verify, update spec, commit, and wrap up
 
 ### Analysis-only tasks
 
-An analysis-only task is eligible only when `task.json.meta.delivery_mode = "analysis_only"` exactly and its `prd.md` names the evidence deliverable plus a no-change boundary for product source, runtime configuration, deployment, credentials, and external systems. Task creation consent authorizes that bounded evidence work, not protected-target changes.
+An analysis-only task is eligible when `task.json.meta.delivery_mode = "analysis_only"` exactly and its `prd.md` names the evidence deliverable plus a no-change boundary for product source, runtime configuration, deployment, credentials, and external systems. Complexity, cross-owner scope, multiple evidence units, recommendations, or unresolved product choices do not make it ineligible. The user's research request authorizes the requested main-session evidence work.
 
-The exception is invalid when the work still needs a material user decision, design or implementation plan, cross-owner coordination, security or deployment change, release or credential action, or a protected downstream task. "Research" and a deferred source edit do not override this classification; use normal complex planning when any condition applies.
-
-Keep an eligible analysis-only task in `planning`: write its research, audit, or design evidence; verify its acceptance criteria and boundary; commit task artifacts; then archive directly. Do not run `task.py start`, configure implementation context, or wait for a second implementation approval. If the evidence recommends a protected-target change, record the recommendation and create a separate change-bearing task before doing it.
+Keep the task in `planning`: write and verify its research, audit, or design evidence, commit task artifacts, and archive directly. Do not run `task.py start`, configure implementation context, require a Planning Seal, or wait for a second implementation approval. If independent subnode evidence is requested, freeze the dispatch plan in the task and obtain explicit approval before any spawn/send; that approval authorizes only the listed evidence dispatch. If the evidence recommends a protected-target change, record the recommendation and create a separate change-bearing task before doing it.
 
 ### Planning Artifacts
 
@@ -276,8 +274,8 @@ Preserve existing task fields and artifacts. If the correct status cannot be det
 
 [workflow-state:planning]
 Load `trellis-brainstorm`; stay in planning.
-If `task.json.meta.delivery_mode = "analysis_only"` exactly, complete the declared evidence work now. Do not wait for a start review or run `task.py start`; when the PRD boundary and acceptance evidence pass, commit task artifacts and archive directly. A protected-target recommendation requires a separate change-bearing task.
-Lightweight: `prd.md` can be enough. Complex: finish `prd.md`, `design.md`, and `implement.md`; run the Planning Seal closure pass before asking for review. If `decision-needed` items or an unsealed decision graph remain, load `pennix-decision-grill`, batch only independent frontier questions, and stay in planning. Answers returned by the current continuation must be persisted and fed back into the same planning loop.
+If `task.json.meta.delivery_mode = "analysis_only"` exactly, complete bounded evidence work regardless of complexity or cross-owner scope; the PRD names the evidence deliverable and protected-target no-change boundary. Do not run a Planning Seal or wait for implementation approval. A protected-target recommendation requires a separate change-bearing task.
+For `analysis_only`, complete the bounded evidence work regardless of complexity or cross-owner scope; its PRD names the evidence deliverable and protected-target no-change boundary. Do not run a Planning Seal or wait for implementation approval. For change-bearing work, lightweight tasks may use `prd.md`; complex tasks need `design.md` and `implement.md` plus the Planning Seal before implementation review. Research recommendations and open product choices may be recorded without sealing them as implementation decisions. Persist answers needed to define the requested work and continue the same planning loop.
 Multi-deliverable scope: consider a parent task plus independently verifiable child tasks; dependencies must be written in child artifacts, not implied by tree position.
 Sub-agent mode: curate `implement.jsonl` and `check.jsonl` as spec/research manifests before start.
 Planned/change-bearing start requires native plan seal and matching later approval of this task's current material revision. Selecting context does not approve it.
@@ -291,8 +289,8 @@ Planned/change-bearing start requires native plan seal and matching later approv
 
 [workflow-state:planning-inline]
 Load `trellis-brainstorm`; stay in planning.
-If `task.json.meta.delivery_mode = "analysis_only"` exactly, complete the declared evidence work now. Do not wait for a start review or run `task.py start`; when the PRD boundary and acceptance evidence pass, commit task artifacts and archive directly. A protected-target recommendation requires a separate change-bearing task.
-Lightweight: `prd.md` can be enough. Complex: finish `prd.md`, `design.md`, and `implement.md`; run the Planning Seal closure pass before asking for review. If `decision-needed` items or an unsealed decision graph remain, load `pennix-decision-grill`, batch only independent frontier questions, and stay in planning. Answers returned by the current continuation must be persisted and fed back into the same planning loop.
+If `task.json.meta.delivery_mode = "analysis_only"` exactly, complete bounded evidence work regardless of complexity or cross-owner scope; the PRD names the evidence deliverable and protected-target no-change boundary. Do not run a Planning Seal or wait for implementation approval. A protected-target recommendation requires a separate change-bearing task.
+For `analysis_only`, complete the bounded evidence work regardless of complexity or cross-owner scope; its PRD names the evidence deliverable and protected-target no-change boundary. Do not run a Planning Seal or wait for implementation approval. For change-bearing work, lightweight tasks may use `prd.md`; complex tasks need `design.md` and `implement.md` plus the Planning Seal before implementation review. Research recommendations and open product choices may be recorded without sealing them as implementation decisions. Persist answers needed to define the requested work and continue the same planning loop.
 Multi-deliverable scope: consider a parent task plus independently verifiable child tasks; dependencies must be written in child artifacts, not implied by tree position.
 Inline mode: skip jsonl curation; Phase 2 reads artifacts/specs via `trellis-before-dev`.
 Planned/change-bearing start requires native plan seal and matching later approval of this task's current material revision. Selecting context does not approve it.
@@ -385,7 +383,7 @@ When a user request matches one of these intents inside an active task, route fi
 
 ### Guardrails
 
-- Only an eligible `task.json.meta.delivery_mode = "analysis_only"` task may complete while `planning`; it may write evidence artifacts, but any protected-target change requires a separate change-bearing task.
+- `analysis_only` tasks may complete in `planning` when their PRD names bounded evidence and a protected-target no-change boundary; complexity, cross-owner scope, multiple evidence units, and recommendations do not make them ineligible. Any protected-target change requires a separate change-bearing task.
 - Task creation approval is not implementation approval; change-bearing implementation waits for `task.py start` after artifact review.
 - PRD-only is valid for lightweight tasks; complex tasks need `design.md` + `implement.md`.
 - Planning must be persisted to task artifacts; checks must run before reporting completion.
@@ -440,7 +438,7 @@ The brainstorm skill will guide you to:
 - Keep `prd.md` focused on requirements and acceptance criteria
 - For complex tasks, produce `design.md` and `implement.md` before implementation starts
 - For read-heavy work, split long investigation into evidence units and persist each unit's conclusion or recovery point before continuing
-- Before review or `task.py start`, run the Planning Seal closure pass across all task artifacts and lock targets, branches, dependencies, release, validation, rollback, dynamic-fact handling, and every material decision
+- Before change-bearing implementation review or `task.py start`, run the Planning Seal closure pass across task artifacts and lock targets, branches, dependencies, release, validation, rollback, dynamic-fact handling, and implementation decisions; `analysis_only` does not use this gate
 
 When considering a parent/child split:
 - Use a parent task when one request contains several independently verifiable deliverables.
@@ -566,7 +564,7 @@ If `task.py start` errors with a session-identity message (no context key from h
 | `research/` has artifacts (complex tasks) | recommended |
 | `design.md` exists (complex tasks) | ✅ |
 | `implement.md` exists (complex tasks) | ✅ |
-| Planning Seal closure pass recorded; static decisions and implementation paths are locked | ✅ |
+| Change-bearing task: Planning Seal closure pass recorded; static implementation decisions and paths are locked | ✅ |
 
 [Claude Code, Cursor, OpenCode, codex-sub-agent, Kiro, Gemini, Qoder, CodeBuddy, Copilot, Droid, Pi, Oh My Pi, ZCode, Snow, Reasonix, Trae, Grok, Kimi Code, DeepSeek Harness]
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pennixrv/trellis",
-  "version": "0.7.0-beta.40",
+  "version": "0.7.0-beta.41",
   "description": "AI capabilities grow like ivy — Trellis provides the structure to guide them along a disciplined path",
   "type": "module",
   "main": "./dist/index.js",
@@ -34,7 +34,7 @@
     "inquirer": "^9.3.7",
     "undici": "^6.21.0",
     "zod": "^4.4.2",
-    "@pennixrv/trellis-core": "0.7.0-beta.40"
+    "@pennixrv/trellis-core": "0.7.0-beta.41"
   },
   "devDependencies": {
     "@eslint/js": "^9.18.0",