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

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

@@ -0,0 +1,9 @@
+{
+  "version": "0.7.0-beta.44",
+  "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/templates/common/bundled-skills/trellis-channel/references/multi-target-dispatch.md

@@ -2,8 +2,12 @@
 
 Use after the user has authorized independent evidence and the task owns a
 reviewed unit mapping. Read `subnode-work.md` for artifact and acceptance rules.
-Codex inline mode governs native implement/check agents; it does not disable
-explicit Channel evidence. Missing independent reports cannot be replaced by
+Codex inline workflows skip native implement/check dispatch and keep ordinary
+implementation/checking in the main session; inline mode does not disable
+explicit Channel evidence. Channel implement/check workers belong to a
+separately selected Channel-driven workflow, not `codex-subnode-channel`.
+Codex Channel workers disable their own native multi-agent features to prevent
+recursive dispatch. Missing independent reports cannot be replaced by
 main-session pass claims.
 
 ## Prepare And Dispatch In One Host Call

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

@@ -3,6 +3,13 @@
 Use these patterns by intent. Prefer durable channels for multi-round work and
 `channel run` for one-shot questions.
 
+The selected project workflow owns the dispatch and evidence contract. Under
+`codex-subnode-channel`, the main session implements/checks inline and explicitly
+approved independent evidence uses the subnode brief/report/acceptance path in
+`subnode-work.md`. The generic agent examples below do not override that path.
+Codex Channel workers disable their own native multi-agent features to prevent
+recursion; main-session inline mode does not disable explicit Channel evidence.
+
 ## Pattern A: Multi-round Brainstorm
 
 Use when the user says "和 codex/claude 讨论一下", "brainstorm", or "拉一个 agent
@@ -49,7 +56,10 @@ needed.
 
 ## Pattern B: Implement / Check Agent
 
-Use when the user asks to dispatch implementation or review work.
+Use only when the selected workflow permits Channel implement/check dispatch
+and the task authorizes it, such as a Channel-driven workflow. Under
+`codex-subnode-channel`, use an approved independent-evidence subnode instead;
+ordinary implementation/checking stays in the main session.
 
 ```bash
 TASK=.trellis/tasks/05-12-foo
@@ -74,7 +84,9 @@ already run.
 
 ## Pattern C: Parallel Reviewers
 
-Use one channel and distinct worker names.
+Use one channel and distinct worker names only under the same permitted
+dispatch contract as Pattern B. These generic check workers are not the default
+review path for `codex-subnode-channel`.
 
 ```bash
 trellis channel create cr-feature --ephemeral

package/dist/templates/common/bundled-skills/trellis-meta/references/customize-local/change-skills-or-commands.md

@@ -4,10 +4,11 @@ When the user wants to change AI entry points, auto-trigger rules, or explicit c
 
 Before editing, classify the skill you are about to touch:
 
-- **Bundled upstream skill** — `trellis-meta`, `trellis-spec-bootstrap`, `trellis-session-insight`, `trellis-channel`. Source of truth lives in the Trellis CLI repo under `packages/cli/src/templates/common/bundled-skills/<name>/`; auto-dispatched to every platform's skill root by `getBundledSkillTemplates()` on `trellis init` / `trellis update`. Local edits here are tracked by `.trellis/.template-hashes.json` and will be flagged on the next update.
-- **Project-local skill** — anything else under `.{platform}/skills/`. Owned by the user; not refreshed by `trellis update`.
+- **Bundled multi-file skill** — `trellis-meta`, `trellis-spec-bootstrap`, `trellis-session-insight`, `trellis-channel`, `trellis-research-record`. Source lives under `packages/cli/src/templates/common/bundled-skills/<name>/`; `getBundledSkillTemplates()` distributes it to each platform skill root on init/update.
+- **Other Trellis-managed entry** — single-file skills such as `trellis-check` and `trellis-before-dev`, command-backed skills such as `trellis-finish-work`, and platform-specific entries. Their sources live under `common/skills/`, `common/commands/` or the relevant platform template directory. Configurators generate them and update tracks their template hashes too.
+- **Project-local entry** — content created by the project outside the managed template set, owned by the user and not refreshed by `trellis update`. Its directory or absence from a short bundled-name list does not establish ownership.
 
-The remainder of this file uses "skill" for the local file; the override and conflict rules differ between the two cases.
+The remainder uses "skill" for the local file. Confirm its actual source and generated-file ownership before choosing the edit path.
 
 ## Read These Files First
 
@@ -15,7 +16,7 @@ The remainder of this file uses "skill" for the local file; the override and con
 2. Target platform skill/command/prompt/workflow directory
 3. Related agent or hook files
 4. Whether project rules already exist in `.trellis/spec/`
-5. `.trellis/.template-hashes.json` — confirms whether the skill you are about to edit is upstream-owned (entry present) or project-local (entry absent)
+5. `.trellis/.template-hashes.json` and the relevant template/configurator — a hash entry confirms management; a missing entry alone does not prove project ownership.
 
 ## Which Entry Type To Choose
 
@@ -25,7 +26,7 @@ The remainder of this file uses "skill" for the local file; the override and con
 | User wants to trigger manually with a command | Add or modify a command/prompt/workflow. |
 | Team project conventions | Prefer `.trellis/spec/` or a project-local skill — never a bundled skill directory. |
 | Tweak a bundled skill (`trellis-meta` et al.) for the user's own project | Create a project-local sibling skill (different name) that overrides intent, or edit `.trellis/spec/`. Edits inside the bundled skill directory survive only until the next `trellis update` and will need a "keep" choice each time. |
-| Contribute the change back upstream | Edit `packages/cli/src/templates/common/bundled-skills/<name>/` in the Trellis CLI repo, not the deployed copy. |
+| Contribute the change back upstream | Edit its actual bundled, common skill/command or platform template source in the Trellis CLI repo, not the deployed copy. |
 | Change Trellis flow semantics | Synchronize `.trellis/workflow.md`. |
 
 ## Modify A Skill
@@ -50,12 +51,12 @@ Do not write vague descriptions such as "helpful project skill"; they can trigge
 
 ### Bundled vs. Project-Local
 
-The same directory shape is used by two very different ownership models:
+The same directory shape can contain different ownership models:
 
-| Aspect | Bundled (`trellis-meta`, `trellis-spec-bootstrap`, `trellis-session-insight`, `trellis-channel`) | Project-local |
+| Aspect | Trellis-managed entry | Project-local |
 | --- | --- | --- |
-| Source of truth | `packages/cli/src/templates/common/bundled-skills/<name>/` in Trellis CLI repo | Inside the user project itself |
-| Dispatch | Auto-dispatched to every platform skill root by `getBundledSkillTemplates()` (`packages/cli/src/templates/common/index.ts`) on `trellis init` / `trellis update` | Created by the user (or another skill) and never moved |
+| Source of truth | Actual bundled, common skill/command or platform template in the Trellis CLI repo | Inside the user project itself |
+| Generation | Bundled files use `getBundledSkillTemplates()`; other entries use the platform configurator on init/update | Created by the user (or another skill) |
 | Hash tracking | Every file recorded in `.trellis/.template-hashes.json`; conflict prompt on update | Not tracked |
 | Editing locally | Allowed but will be marked "modified by user" on next update | Free editing |
 | The right way to customize | Add a *new* project-local skill with a *different* name that supplements (or supersedes) the bundled one | Edit the file directly |
@@ -92,7 +93,7 @@ If a command only repeats workflow rules, prefer making it reference/read `.trel
 | ZCode | `.zcode/skills/`, `.zcode/commands/` |
 | Kilo / Antigravity / Devin | workflows + skills |
 
-Every directory above is a deploy target for the four bundled skills. Each platform receives a full copy on `trellis init` and refresh on `trellis update`; nothing has to be wired by hand.
+The bundled multi-file skills are distributed to each supported platform skill root on init/update; other managed entries follow that platform's configurator. Read the actual template set rather than inferring it from a fixed count.
 
 ## Add A Project-Local Skill
 
@@ -111,8 +112,9 @@ Pick a name that does **not** collide with the bundled set:
 - `trellis-spec-bootstrap`
 - `trellis-session-insight`
 - `trellis-channel`
+- `trellis-research-record`
 
-A reused name causes `getBundledSkillTemplates()` to overwrite the project-local copy on the next update. A common convention is to prefix the project name: `acme-trellis-deploy`, `acme-trellis-onboarding`.
+Also avoid names of generated single-file or platform entries. A collision becomes managed template content or an update conflict; it is not a durable override. A common convention is to prefix the project name: `acme-trellis-deploy`, `acme-trellis-onboarding`.
 
 ## Notes
 

package/dist/templates/common/bundled-skills/trellis-meta/references/local-architecture/workflow.md

@@ -22,10 +22,12 @@ Each phase contains numbered steps, such as `1.3 Configure context`. These numbe
 
 ## Skill Routing
 
-`workflow.md` separates routing by platform capability:
+Read the selected `workflow.md` and current task phase to determine routing;
+platform capability alone does not select the implementation/check path:
 
-- Platforms with sub-agent support: dispatch `trellis-implement` by default for implementation and `trellis-check` for checking.
-- Platforms without sub-agent support: the main session reads skills such as `trellis-before-dev`, then executes directly.
+- A workflow that selects native sub-agent dispatch uses its platform-supported `trellis-implement` / `trellis-check` path.
+- An inline workflow has the main session read `trellis-before-dev`, implement and check directly. Explicit Channel independent evidence remains subject to that workflow's authorization and acceptance contract.
+- A Channel-driven workflow is a separate selected variant; generic Channel examples do not override an inline workflow.
 
 When changing local AI behavior, update the routing descriptions in `workflow.md` first, then check whether the corresponding platform skill, command, or agent files need to stay in sync.
 
@@ -59,7 +61,7 @@ Common changes:
 | Add a phase | Update the Phase Index, phase body, routing, and state blocks. |
 | Change task creation policy | Update the `no_task` state block and Phase 1 description. |
 | Change the default implementation/check path | Update Phase 2 and skill routing. |
-| Change the wrap-up flow | Update Phase 3 and `finish-work` related descriptions. Note the current split: Phase 3.4 = AI-driven code commits (batched, user-confirmed), Phase 3.5 = `/finish-work` (archive + record session). `/finish-work` refuses to run if the working tree is dirty. |
+| Change the wrap-up flow | Update Phase 3 and `finish-work` descriptions together. Follow the selected workflow's commit/push authorization; finish-work checks acceptance and classifies task-related versus unrelated dirty paths before archive and journal recording. |
 | Change platform differences | Update routing descriptions grouped by platform. |
 
 After editing, make the AI reread `.trellis/workflow.md`; do not assume the flow from the old conversation is still valid.

package/dist/templates/common/bundled-skills/trellis-session-insight/SKILL.md

@@ -63,6 +63,29 @@ intent, including any minimal source-note status/version/target-link update.
 Existing authorized task/spec duties do not acquire an extra confirmation gate.
 Verify each target independently; do not introduce automatic synchronization.
 
+## Bulk history and resource boundaries
+
+For bulk or remote history research, first define the project path, platform,
+date range, question and required session types. Start with metadata and a small
+sample to verify the stored structure; filter before extracting bodies. Confirm
+main-session versus child-session scope from actual metadata, not file counts.
+
+Choose the processing location and authorized destination before reading a
+large corpus. Process one bounded unit at a time, retain only needed results,
+and transfer only the requested material. Test the intended bulk path on small
+or synthetic data and observe memory/output before scaling. On resource
+pressure, stop the affected work, preserve its checkpoint and reduce the unit;
+do not continue a remote scan or increase concurrency blindly.
+
+`--limit` limits displayed rows, not scan work or a process memory budget.
+Codex small-output `search`/`context` avoid accumulating all dialogue bodies,
+but per-record parsing, fingerprints/index metadata and output still cost
+memory. Full `extract`/phase results and the other platform adapters may retain
+complete dialogue arrays. Do not promise constant memory or infer an earlier
+OOM's cause from these limits alone. Preserve the source logs; raw dialogue,
+credentials and runtime data do not belong in Git. Historical findings still
+require current-source verification and do not authorize automatic write-back.
+
 ## How to call it
 
 Full CLI reference is in `references/cli-quick-reference.md`. The 80% case is one of:

package/dist/templates/common/commands/finish-work.md

@@ -16,7 +16,7 @@ This prints:
 - **Git status** — quick visual on what's dirty.
 - **Recent commits** — you'll need their hashes in Step 4 for `--commit`.
 
-If `--mode record` surfaces other completed tasks not tied to the current session, surface them to the user with a one-shot confirmation: "These N tasks look done — archive them too in this round? [y/N]". Default is no; the current active task is always archived in Step 3 regardless.
+If `--mode record` surfaces other completed tasks not tied to the current session, surface them to the user with a one-shot confirmation: "These N tasks look done — archive them too in this round? [y/N]". Default is no; archive the current task only after the acceptance check below.
 
 ## Step 2: Sanity check — classify dirty paths
 
@@ -44,13 +44,28 @@ Then route:
   > "FYI, dirty files outside this task's scope — leaving them for the other window: `<list>`."
 - **Genuinely unsure** — ask the user once: "Are `<list>` this task's work I forgot to commit, or another window's? (commit / ignore)" — then route per their answer.
 
+### Acceptance check before archive
+
+Compare the task's PRD-defined endpoint and required acceptance criteria with
+actual evidence in its records and verification results. Reuse valid results;
+state which checks ran, did not run, were blocked, or had limited coverage.
+Installation, publishing, project updates or live execution require their own
+evidence when they are part of the authorized endpoint; static readiness or
+isolated tests cannot stand in for them. Clean bootstrap/cleanup is conditional
+on the task goal and authorization, not an automatic finishing step.
+
+If a required criterion is unmet or lacks sufficient evidence, return to the
+corresponding work and leave the task unarchived. Reporting a limitation does
+not satisfy a required criterion. Keep this conclusion in the existing task
+record; do not add a separate acceptance receipt.
+
 ## Step 3: Archive task(s)
 
 ```bash
 {{PYTHON_CMD}} ./.trellis/scripts/task.py archive <task-name>
 ```
 
-At minimum: the current active task (if any). Plus any extra tasks the user confirmed in Step 1. Each archive produces a `chore(task): archive ...` commit via the script's auto-commit.
+Archive the current active task and any extra tasks confirmed in Step 1 only when their required acceptance has been verified. Each archive produces a `chore(task): archive ...` commit via the script's auto-commit.
 
 If there is no active task and the user did not confirm any cleanup archives, skip this step.
 

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

@@ -1,6 +1,6 @@
 # Code Quality Check
 
-Comprehensive quality verification for recently written code. Combines spec compliance, cross-layer safety, and pre-commit checks.
+Verify the task's affected behavior against the current implementation, applicable specs, and acceptance criteria.
 
 ---
 
@@ -11,6 +11,11 @@ git diff --name-only HEAD
 git status
 ```
 
+Use the diff as the entry point. Follow the affected behavior through existing
+implementation, necessary callers, configuration, tests, documentation and
+generated consumers. Expand when evidence of an existing problem could affect
+the task result; do not default to a whole-module or whole-repository audit.
+
 ## Step 2: Read Task Artifacts and Applicable Specs
 
 Read the current task artifacts in order:
@@ -35,6 +40,12 @@ Read the specific guideline files referenced — the index is a pointer, not the
 
 Run the project's lint, type-check, and test commands. Fix any failures before proceeding.
 
+Choose checks by changed behavior and risk. When the task includes installation,
+release or a live workflow, verify its normal entry and required endpoint;
+isolated tests do not prove those endpoints. A clean bootstrap or destructive
+cleanup applies only when required by the task and authorized. Reuse valid
+results and distinguish checks run, not run, blocked, or limited.
+
 ## Step 4: Review Against Checklist
 
 ### Code Quality
@@ -47,9 +58,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 behavior and material risks covered by meaningful checks?
+- [ ] Bug fix has a regression that reaches the failing path?
+- [ ] Existing tests updated when their behavior changed, without duplicating trivial implementation?
 
 ### Spec Sync
 
@@ -62,7 +73,7 @@ Run the project's lint, type-check, and test commands. Fix any failures before p
 - [ ] Any tidying of code the task did not require?
 - [ ] Any abstraction, config or extension point added for a case that does not exist yet?
 - [ ] Any speculative fallback for a state that cannot occur?
-- [ ] Any file changed that the acceptance criteria do not mention?
+- [ ] Each changed file serves the task or a necessary consumer, even if the AC do not name it individually?
 - [ ] Any workaround added at the caller instead of a fix where the behavior actually lives?
 
 ## Step 5: Cross-Layer Dimensions (if applicable)
@@ -100,6 +111,12 @@ Skip this step if your change is confined to a single layer.
 
 Report every violation you find. Then:
 
+Verify important findings against current requirements, actual sources, callers
+and relevant counterevidence before prioritizing. Separate observed facts from
+inferences; a rule's presence, a zero call count or an intentional behavior is
+not by itself proof of a defect. Record task-relevant findings and their effect
+on acceptance; new consequential scope choices follow the task's decision gate.
+
 - 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.
 

package/dist/templates/markdown/spec/guides/index.md.txt

@@ -63,7 +63,7 @@ These guides help you **ask the right questions before coding**.
 2. **Ignoring design comments**: Flagging intentional behavior documented in code comments as bugs
 3. **Variable misreading**: Not tracing a variable to its actual definition (e.g., Map keyed by path vs name)
 
-**Verification rule**: Every CRITICAL/WARNING finding must be verified against the actual code before prioritizing. Budget ~35% false-positive rate for AI reviews.
+**Verification rule**: Every CRITICAL/WARNING finding must be verified against the actual code before prioritizing.
 
 ---
 

package/package.json

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