@pennixrv/trellis 0.7.0-beta.44 → 0.7.0-beta.46

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

@@ -0,0 +1,9 @@
+{
+  "version": "0.7.0-beta.45",
+  "description": "Bounded Codex memory queries and workflow asset boundaries",
+  "breaking": false,
+  "recommendMigrate": false,
+  "changelog": "Read Codex JSONL memory queries in bounded passes, preserve compaction and repeated-turn semantics, enforce context character budgets, and clarify managed asset, dispatch, archive acceptance, and bulk research boundaries.",
+  "migrations": [],
+  "notes": "No migrations. Existing session data, task state, and user-owned workflow files are preserved."
+}

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

@@ -0,0 +1,9 @@
+{
+  "version": "0.7.0-beta.46",
+  "description": "Idea-to-plan routing and closed-loop review guidance",
+  "breaking": false,
+  "recommendMigrate": false,
+  "changelog": "Add workflow guidance for separating facts from decisions, recording evidence at the natural task artifact, grilling consequential choices, closing review loops, and assigning boundaries to neighboring defects.",
+  "migrations": [],
+  "notes": "No migrations. Existing session data, task state, and user-owned workflow files are preserved."
+}

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

@@ -8,6 +8,18 @@ For every non-trivial task, the user must respond at least once after the initia
 
 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 other work, screen consequential user-owned choices with `pennix-decision-grill`, including a single choice; it owns progressive decision method, not task lifecycle. Do not implement or run `task.py start` until change decisions are sealed and approved.
 
+## Idea-to-Plan Route
+
+When the input is an idea, suspected gap, review finding, or loosely stated improvement, route it through the smallest complete chain:
+
+1. State the user outcome and the concrete problem or gap in one sentence.
+2. Separate repository-answerable facts from user-owned choices; inspect the repository, task history, and applicable specs before asking about facts.
+3. Record the current evidence and its recovery point in the natural task artifact: research matrix for research, PRD/design for planning, and the diff or Git history for code.
+4. Screen only the choices that change scope, owner, risk, public behavior, release, or acceptance through `$pennix-decision-grill`.
+5. Define observable acceptance, boundaries, rollback, and the next dependency-ready action; then use the normal seal and approval gate.
+
+An issue discovered while doing this work is not automatically part of the task. Compare its owner, target, risk, and acceptance with the sealed scope. Record every consequential finding and ask whether it should be included; a same-owner, reversible, low-risk correction may use the existing in-progress addition rule. Otherwise use `task.py replan` and reseal before dependent implementation.
+
 ## 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.

package/dist/templates/common/skills/break-loop.md

@@ -8,6 +8,8 @@ When debug is complete, use this for deep analysis to break the "fix bug -> forg
 
 Analyze the bug you just fixed from these 5 dimensions:
 
+Start with a short causal loop before filling the five dimensions: expected behavior → observed failure → discriminating evidence → root cause → prevention check. If the failure is not reproduced, label the uncertainty and do not promote a plausible explanation to a confirmed cause.
+
 ### 1. Root Cause Category
 
 Which category does this bug belong to?
@@ -174,3 +176,5 @@ Record verified findings in the active task. Update a spec only when the finding
 Consumer projects do not sync specs into Trellis templates. When working on the Trellis source itself, update a corresponding template under `packages/cli/src/templates/markdown/` only if it exists and the change is intended for generated consumers. Keep root coordination contracts in their owner; do not copy them into component specs.
 
 Follow the task's existing commit and release process. This skill does not independently authorize source changes, commits, publication, or new tickets.
+
+When the analysis reveals a neighboring defect, compare its owner, target, risk, and acceptance with the current task. Record the finding and ask for inclusion when it changes material scope; only a same-owner, reversible, low-risk correction may continue under the existing in-progress addition rule. This keeps root-cause learning broad while keeping implementation scope explicit.

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

@@ -121,3 +121,15 @@ on acceptance; new consequential scope choices follow the task's decision gate.
 - 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.
 
 If a fix would touch files outside the current task's scope, say so and stop instead of widening the change.
+
+## Step 7: Close the Review Loop
+
+For each material finding, preserve the chain from evidence to action:
+
+1. State the observed behavior, source or test evidence, and confidence.
+2. Identify the affected acceptance criterion, owner, target, and risk.
+3. Classify the finding as an in-scope correction, a separately owned issue, or a consequential scope change.
+4. Fix only in-scope mechanical corrections. Record separately owned or consequential findings and use the task's decision/replan gate before dependent work.
+5. Re-run the smallest check that exercises the finding, then re-read the affected acceptance criteria and final diff.
+
+Do not silently absorb newly discovered work because it is nearby. A user-requested addition can remain in the current task only when the existing same-owner, reversible, low-risk rule applies; otherwise ask through the normal decision route and update the sealed plan before implementation.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pennixrv/trellis",
-  "version": "0.7.0-beta.44",
+  "version": "0.7.0-beta.46",
   "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.44"
+    "@pennixrv/trellis-core": "0.7.0-beta.46"
   },
   "devDependencies": {
     "@eslint/js": "^9.18.0",