@pennixrv/trellis 0.7.2-beta.2 → 0.7.2-beta.4

package/dist/migrations/manifests/0.7.2-beta.3.json

@@ -0,0 +1,9 @@
+{
+  "version": "0.7.2-beta.3",
+  "description": "Taskless routing gate and explicit task-creation approval",
+  "breaking": false,
+  "recommendMigrate": false,
+  "changelog": "Clarify the taskless workflow contract for bounded, immediately verifiable work and require approval before inferred task creation when the user did not explicitly request a task.",
+  "migrations": [],
+  "notes": "The release updates bundled workflow templates and agent guidance only; no project file migration is required."
+}

package/dist/migrations/manifests/0.7.2-beta.4.json

@@ -0,0 +1,9 @@
+{
+  "version": "0.7.2-beta.4",
+  "description": "Bounded decision discovery and solution re-evaluation before convergence",
+  "breaking": false,
+  "recommendMigrate": false,
+  "changelog": "Challenge material defaults before decision handoff, reconsider affected choices after answers and evidence, and record completion evidence before requesting overall approval without adding fixed interview rounds.",
+  "migrations": [],
+  "notes": "Updates the two bundled phase workflow documents and diagrams. Use native trellis update to refresh project skills; no project file migration is required."
+}

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

@@ -4,10 +4,12 @@
 
 需要构造时，梳理决策项及其权限、候选、重要排除项与理由；按需补齐证据、适用约束、标准、阈值、依赖、影响和优先级。证据足够时给出推荐；证据不足则保留未知或待决项，不伪造结论。仅当选择之间存在条件依赖时使用决策树，并标明分支条件、来源、未知路径及其下游影响。互斥、共享依赖或汇合关系可用依赖图；独立候选用比较表或清单即可。
 
-候选尚未覆盖实质选择时，从不同机制、责任边界或运作方式拓宽，而非只列同一做法的参数变体；适用时纳入维持现状或不做。再以已确认约束、当前实现、外部先例及必要的有界探针筛选，区分不可行、代价较高与证据不足，保留排除理由及依赖后果。重要选择已可比较、未知已定位到受影响的决定时停止；不凑候选数量，不在没有新证据时追加轮次。目标变化回第一阶段，用户保留决定整理给第三阶段，不由辅助 Skill 提前锁定。
+候选尚未覆盖实质选择时，从不同机制、责任边界或运作方式拓宽，而非只列同一做法的参数变体；适用时纳入维持现状或不做。再以已确认约束、当前实现、外部先例及必要的有界探针筛选，区分不可行、代价较高与证据不足，保留排除理由及依赖后果。移交前还应完成下述重要默认与遗漏分支核对；不凑候选数量，不在没有新证据时追加轮次。目标变化回第一阶段，用户保留决定整理给第三阶段，不由辅助 Skill 提前锁定。
 
 新颖机制、重大重构、跨组件边界变化或关键取舍缺少可信本地先例时，进行有界的 `prior-art review`，记录适用性与采纳或排除理由。只读 Teamwork 可按需补充证据；主代理核验报告后归并。将 `DecisionSpace` 或有据跳过记录交由 Trellis CLI 接受，待用户决定交由解决方案设计与收敛阶段处理。
 
+移交前，从当前目标的实际使用、失败或交付场景挑战重要默认假设，检查候选之外是否仍有会改变行为、责任或验收的分支。可查事实由代理补证，真实用户取舍交第三阶段处理；尚未满足前置或暂不能精确表述的未知，说明影响哪个决定及后续处理，不能因当前无就绪问题就当作已解决。在现有产物简短保留关键发现、排除依据和未决项的移交方式；重要选择可比较且未知已有处置路径时停止，不穷举理论分支，也不把每个默认都变成用户问题。
+
 ```mermaid
 flowchart TD
   input["核对已确认且仍有效的需求基线"] --> material{"差异或条件分支会改变交付、验收、风险或下游选择？"}
@@ -26,8 +28,9 @@ flowchart TD
   merge --> representation{"候选关系需要条件分支吗？"}
   representation -->|"是"| tree["建立可追溯决策树并标明相关未知路径"]
   representation -->|"否"| simple["使用清单、比较表或适用的依赖图"]
-  tree --> assess["核对证据、覆盖范围、关系与当前 revision"]
-  simple --> assess
+  tree --> challenge["用当前任务场景挑战重要默认，检查遗漏分支与未知处置"]
+  simple --> challenge
+  challenge --> assess["核对证据、覆盖范围、关系与当前 revision"]
   assess -->|"目标或范围变化"| goal_exploration_and_requirements["回到目标探索与需求核对阶段，更新基线"]
   assess -->|"证据或候选仍有缺口"| items
   assess -->|"可供方案收敛"| output["Trellis CLI 接受 DecisionSpace"]
@@ -40,3 +43,4 @@ flowchart TD
 - 有实质决策空间时，候选、关键证据、关系、未知项和推荐均能支持下一阶段比较；不要求固定字段数量或同时使用多种图表。
 - 无实质差异时，跳过记录须能说明当前基线、判断依据和重新进入条件。
 - 保留用户决定不在本阶段锁定；外部参考不替代项目事实或用户选择。
+- 已检查影响当前目标的重要默认和遗漏分支，关键未知有受影响决定及移交路径；没有就绪问题不单独构成退出依据。

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

@@ -4,6 +4,8 @@
 
 比较适用方案，说明选择依据、重要后果、行为边界、责任、必要依赖、验证方式、停止与恢复条件及实质风险。对新颖核心机制、重大重构、跨组件边界变化或关键不确定性缺少可信本地先例的方案，在结果接受前完成有界 `prior-art review`，记录适用性、采纳或排除理由，或说明没有适用先例。外部材料改变候选、标准或依赖时回到决策空间构造与归并阶段。
 
+用户答复、新证据、方案修订或复核发现后，重新筛选受影响的重要选择：是否出现新分支、前置是否满足、原决定是否仍有效。先保存真实答案及其影响，只重开受影响项；可查事实继续补证，用户取舍按依赖提问，不把问完原有列表或当前无就绪问题等同于方案完整。关键未知须有补证、用户决定、明确接受的剩余风险、延期或不继续等处置，不能静默排除。
+
 判断当前结果：分析交付形成 `analysis_conclusion`；不继续形成 `no_go`；延期形成带责任方、触发条件和恢复位置的 `deferred`，留在解决方案设计与收敛阶段；实施路线形成 `implementation_contract`，明确目标、范围和接受条件，并按路线需要补足实施与核验信息。只有交付物具有独立实施或集成边界时才拆分工作包，并说明推进和协作所需的依赖、顺序、责任或集成信息；单一交付不人为拆分工作包。解决方案设计与收敛阶段的结果接受与实施授权分开记录；只有合同及明确批准均有效时，Trellis CLI 才允许进入任务实施与测试验证阶段。
 
 合同结果已接受、实施尚未授权时，发现需要返修，应通过 `task.py phase return` 回到本阶段或更早受影响阶段，记录理由和证据。受影响的接受与授权随之失效；修订后重新接受当前产物，再核验实施授权。
@@ -14,22 +16,29 @@
 
 研究、原型和协作证据写回现有阶段产物、research 或 execution 自然落点，注明来源与版本、事实和假设、适用性、限制及决定影响。证据足够即停止扩搜；工具、报告或模板不能替代用户决定和 Trellis 原生接受事实。
 
+请求整体批准前，落实已有独立复核，在现有产物简短说明关键反例、发现及处置。以当前任务的具体行为或交付物检验端到端可执行性与验收依据；涉及发布安装时，核对本地验证、发布产物和实际运行身份的关系，不能只凭版本字符串认定同一产物。发现未决重要选择就回到筛选，不为没有新发现的情况追加轮次；充分的整体接受和实施授权不重复索取。
+
 ```mermaid
 flowchart TD
-  input["核对需求基线与已接受的 DecisionSpace"] --> decisions{"存在尚待用户决定的实质取舍？"}
+  input["核对需求基线与已接受的 DecisionSpace"] --> rescreen["复用已定事项，重新筛选重要分支、前置与未知处置"]
+  rescreen --> decisions{"存在尚待用户决定的实质取舍？"}
   decisions -->|"是"| grill["pennix-decision-grill 同步询问；留在解决方案设计与收敛阶段"]
   grill --> impact{"答复影响哪个范围？"}
   impact -->|"目标或范围"| goal_exploration_and_requirements["回到目标探索与需求核对阶段"]
   impact -->|"候选、标准或依赖"| decision_space_construction_and_merging["回到决策空间构造与归并阶段"]
-  impact -->|"当前候选中的选择"| compare["比较方案和重要后果"]
-  decisions -->|"否"| compare
+  impact -->|"当前候选中的选择；保存答复后重算"| rescreen
+  decisions -->|"否；必要证据和未知已有处置"| compare["比较方案和重要后果"]
+  decisions -->|"前置或证据尚缺"| repair["补证或修订受影响方案"]
+  repair --> rescreen
   compare --> prior{"触发 prior-art review？"}
   prior -->|"是"| review["核验相关开源实现或公开提案并记录适用性"]
   review --> changed{"外部证据改变候选、标准或依赖？"}
   changed -->|"是"| decision_space_construction_and_merging
-  changed -->|"否"| assess["核对完整性、风险、验证和恢复条件"]
+  changed -->|"否"| newDecisions{"新证据出现未决重要分支？"}
+  newDecisions -->|"是"| rescreen
+  newDecisions -->|"否"| assess["独立复核完整性、风险、验证、恢复与关键发现处置"]
   prior -->|"否"| assess
-  assess -->|"有实质缺口"| compare
+  assess -->|"有实质缺口；补证或修订后重算"| repair
   assess -->|"analysis_conclusion 或 no_go"| reviewResult["Trellis CLI 接受解决方案设计与收敛阶段结果"]
   assess -->|"deferred"| defer["记录恢复条件并留在解决方案设计与收敛阶段"]
   assess -->|"implementation_contract"| contract["冻结必要实施合同"]

package/dist/templates/common/skills/request-intake.md

@@ -2,16 +2,16 @@
 
 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.
+Reuse verified evidence and existing authorization. Follow the taskless route in workflow.md only when all of these are true: the goal is clear; the scope and owner are bounded; risk is controlled; the user has authorized the actual action; success can be verified in the current session; and the work needs no persistent route, coordination, design, review, release, installation, migration, external delivery, or dedicated rollback plan. A bounded irreversible action additionally needs exact target verification, an acceptable recovery or loss boundary, and a stop condition. User authorization alone is not sufficient. Read-only inspection, bounded diagnosis, low-impact native-owner maintenance or cleanup, small single-surface edits, and rerunning existing checks are examples, not an allowlist. 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 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:
+2. When the work needs a persistent route, coordination, design, review, release, installation, migration, external delivery, or a durable record, treat it as task-based. If the user did not explicitly ask to create a task, stop before the create command and ask for creation approval. State which taskless condition is not met, the proposed owner/scope/route, and the risk of proceeding without a task. An explicit user request to create or resume a task is already authorization for that lifecycle action only; it does not authorize implementation or delivery:
 
        {{PYTHON_CMD}} ./.trellis/scripts/task.py create "<title>" --description "<summary>"
 
-3. Initialize an ordered phase route that includes Goal Exploration and Requirements Confirmation Phase, then only the later phases the task needs:
+3. After creation approval, initialize an ordered phase route that includes Goal Exploration and Requirements Confirmation Phase, then only the later phases the task needs:
 
        {{PYTHON_CMD}} ./.trellis/scripts/task.py phase init <task> --task-kind <analysis|implementation|combined> --complexity <simple|standard|complex> --project-context <new|existing> --phase-ids <ordered-phase-ids>
 

package/dist/templates/kiro/agents/trellis.json

@@ -1,7 +1,7 @@
 {
   "name": "trellis",
   "description": "Trellis workflow main agent. Follows the current task route and matching Skills, or uses the taskless route when eligible.",
-  "prompt": "# Trellis Workflow Agent\n\nYou are the main session agent for a project that uses the Trellis workflow.\n\n## On Every Turn\n\nA `userPromptSubmit` hook injects a `<workflow-state>` breadcrumb each turn with the active task and its current phase. An `agentSpawn` hook injects a `<session-context>` overview when this agent starts. Use these to orient yourself; resolve missing or stale state through Trellis CLI.\n\n## How to Work\n\n1. Follow `.trellis/workflow.md` and the matching phase Skill. The workflow and its task route define the business phase; task lifecycle status and artifact presence do not.\n2. If the breadcrumb is missing or stale, inspect the active task with `python3 ./.trellis/scripts/task.py current --json` and `python3 ./.trellis/scripts/task.py phase show <task>`.\n3. With no active task, use the taskless route only when `.trellis/workflow.md` permits it; otherwise create the task and establish its baseline through Goal Exploration and Requirements Confirmation Phase.\n4. The Goal Exploration and Requirements Confirmation Phase requires the user's confirmation of the current requirements revision. Before Task Implementation and Test Verification Phase, both an accepted `implementation_contract` from Solution Design and Convergence Phase and separate implementation authorization are required. Delivery Review and On-Site Closeout Phase governs delivery acceptance, task completion, and cancellation.\n5. Use task artifacts and context manifests as required by the current route and any dispatched agent; do not require a fixed set of planning documents based only on task complexity.\n6. Verify with project checks appropriate to the changes before reporting completion.\n\n## Constraints\n\n- Do NOT run `git commit` / `git push` / `git merge` unless the user explicitly asks.\n- Keep changes scoped to the request.\n- Discover guidelines on demand: `python3 ./.trellis/scripts/get_context.py --mode packages`.\n",
+  "prompt": "# Trellis Workflow Agent\n\nYou are the main session agent for a project that uses the Trellis workflow.\n\n## On Every Turn\n\nA `userPromptSubmit` hook injects a `<workflow-state>` breadcrumb each turn with the active task and its current phase. An `agentSpawn` hook injects a `<session-context>` overview when this agent starts. Use these to orient yourself; resolve missing or stale state through Trellis CLI.\n\n## How to Work\n\n1. Follow `.trellis/workflow.md` and the matching phase Skill. The workflow and its task route define the business phase; task lifecycle status and artifact presence do not.\n2. If the breadcrumb is missing or stale, inspect the active task with `python3 ./.trellis/scripts/task.py current --json` and `python3 ./.trellis/scripts/task.py phase show <task>`.\n3. With no active task, classify the request against the taskless contract first. If taskless is eligible, process and verify it directly. If you infer that a task is needed and the user did not explicitly request one, explain the gap, proposed owner/scope/route, and risk, then ask before running task.py create. An explicit request to create or resume a task authorizes that lifecycle action only; establish its baseline through Goal Exploration and Requirements Confirmation Phase.\n4. The Goal Exploration and Requirements Confirmation Phase requires the user's confirmation of the current requirements revision. Before Task Implementation and Test Verification Phase, both an accepted `implementation_contract` from Solution Design and Convergence Phase and separate implementation authorization are required. Delivery Review and On-Site Closeout Phase governs delivery acceptance, task completion, and cancellation.\n5. Use task artifacts and context manifests as required by the current route and any dispatched agent; do not require a fixed set of planning documents based only on task complexity.\n6. Verify with project checks appropriate to the changes before reporting completion.\n\n## Constraints\n\n- Do NOT run `git commit` / `git push` / `git merge` unless the user explicitly asks.\n- Keep changes scoped to the request.\n- Discover guidelines on demand: `python3 ./.trellis/scripts/get_context.py --mode packages`.\n",
   "tools": [
     "read",
     "write",

package/dist/templates/trellis/workflow.md

@@ -4,7 +4,7 @@
 
 1. 保持下表列出的业务阶段各自独立。每个阶段都有自己的活动、产物、接受条件和回流路径。
 2. 任务与阶段事实由 Trellis CLI 管理。Skills、Hooks、Teamwork、Paseo 和其他组件按各自职责提供指引、证据或执行能力。
-3. 采用满足任务风险和验收需要的最小流程。可以基于证据跳过阶段；边界清楚、风险低、可逆、已获授权且能立即验证的请求可以不创建 Trellis task。
+3. 采用满足任务风险和验收需要的最小流程。可以基于证据跳过阶段；目标清楚、责任方单一、范围封闭、风险受控、已获授权、能在当前会话立即验证且不需要持久路线、协调、设计、审查、发布、安装、迁移或外部交付的请求可以不创建 Trellis task。不可逆动作还必须有精确对象核验、可接受的恢复或损失边界和停止条件；用户授权不是唯一充分条件。
 4. 在任务资产中记录决定和当前证据。不得从阶段状态、Teamwork 结果或会话交接状态推断任务状态。
 
 ## Trellis 项目上下文
@@ -74,7 +74,7 @@ python3 ./.trellis/scripts/add_session.py --title "<title>" --summary "<summary>
 ```mermaid
 flowchart LR
   request["用户请求"] --> triage{"是否需要 Trellis task？"}
-  triage -->|"否；边界清楚、低风险、可逆、已授权且可验证"| direct["直接处理并验证"]
+  triage -->|"否；目标/范围清楚、风险受控、已授权、可立即验证且无需持久治理"| direct["直接处理并验证"]
   triage -->|"是"| goal_exploration_and_requirements["目标探索与需求核对阶段"]
   goal_exploration_and_requirements -->|"当前基线已获用户确认"| decision_space_construction_and_merging["决策空间构造与归并阶段"]
   decision_space_construction_and_merging -->|"已接受或有证据的跳过记录"| solution_design_and_convergence["解决方案设计与收敛阶段"]
@@ -88,7 +88,7 @@ flowchart LR
 <!-- 宿主 Hook 从以下区块读取每轮工作流提示。 -->
 
 [workflow-state:no_task]
-先判断请求性质。只有范围清楚、责任方单一、风险低、可逆、已获授权且能立即验证时，才直接处理而不创建任务；否则创建或恢复 Trellis task。创建任务不代表获准实施。
+先按 taskless 合同判断目标、责任方、范围、风险、授权、立即验证和持久治理需要。全部满足时直接处理并验证，不创建 task；不可逆动作还要核验精确对象、恢复或损失边界和停止条件。若模型判断需要任务而用户没有明确要求创建，先说明不满足的门槛、任务 owner/范围/路线和不建任务的风险，向用户申请后再调用 create。用户明确要求创建或恢复任务时复用该创建授权。创建任务不代表获准实施。
 [/workflow-state:no_task]
 
 [workflow-state:task_error]

package/package.json

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