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

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/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.3",
   "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.3"
   },
   "devDependencies": {
     "@eslint/js": "^9.18.0",