@mindfoldhq/trellis 0.5.16 → 0.5.18

package/README.md

@@ -7,8 +7,8 @@
 </p>
 
 <p align="center">
-<strong>The harness that makes coding agents production-ready</strong><br/>
-<sub>Start a feature in Gemini, continue in Claude Code, ship it with Codex — or hand it off to a teammate at any step. Context, specs, and standards are shared across every agent and every teammate, so anyone's best spec lifts the whole team.</sub>
+<strong>Make AI coding reliable at team scale.</strong><br/>
+<sub>A team AI coding harness for progressive specs, custom workflows, task context, and memory across Claude Code, Cursor, OpenCode, Codex, Kiro, Kilo, Gemini CLI, Antigravity, Windsurf, Qoder, CodeBuddy, GitHub Copilot, Droid, and Pi Agent.</sub>
 </p>
 
 <p align="center">

package/dist/migrations/manifests/0.5.17.json

@@ -0,0 +1,9 @@
+{
+  "version": "0.5.17",
+  "description": "Patch: bundle the Trellis spec bootstrap skill and update the marketplace/docs entry for project-specific spec generation.",
+  "breaking": false,
+  "recommendMigrate": false,
+  "changelog": "**Enhancements:**\n- feat(skills): `trellis-spec-bootstarp` is now a built-in bundled skill installed by `trellis init` and refreshed by `trellis update` for supported AI platforms.\n- feat(skills): the bundled skill helps AI bootstrap `.trellis/spec/` from the real repository with source-backed references for repository analysis, spec task planning, spec writing, and MCP setup.\n- docs(skills): replace the older marketplace-only `cc-codex-spec-bootstrap` docs entry with the built-in `trellis-spec-bootstarp` flow.",
+  "migrations": [],
+  "notes": "Run `trellis update` to install or refresh the bundled `trellis-spec-bootstarp` skill. No migration command is required."
+}

package/dist/migrations/manifests/0.5.18.json

@@ -0,0 +1,9 @@
+{
+  "version": "0.5.18",
+  "description": "Patch: archived task create collision guard, workflow-state tool routing clarification, and Codex 0.131 multi_agent_v2 timeout bounds.",
+  "breaking": false,
+  "recommendMigrate": false,
+  "changelog": "**Bug Fixes:**\n- fix(cli): `task.py create` now rejects slugs that already exist under `.trellis/tasks/archive/**` and prints the archived path (#291).\n- fix(workflow): `[workflow-state:in_progress]` now distinguishes sub-agent types from skills so agents do not call missing `trellis-implement` / `trellis-research` skills (#283).\n- fix(codex): `.codex/config.toml` emits `min_wait_timeout_ms`, `default_wait_timeout_ms`, and `max_wait_timeout_ms` together so Codex CLI 0.131+ accepts merged multi_agent_v2 timeout config (#294).",
+  "migrations": [],
+  "notes": "Patch on top of 0.5.17. Run `trellis update` to refresh task, workflow, and Codex templates. No migration command is required."
+}

package/dist/migrations/manifests/0.6.0-beta.18.json

@@ -0,0 +1,16 @@
+{
+  "version": "0.6.0-beta.18",
+  "description": "Beta patch: channel worker OOM guard, simplified channel message routing, bundled Trellis spec bootstrap skill docs, and safer task archive auto-commit failures.",
+  "breaking": false,
+  "recommendMigrate": false,
+  "changelog": "**Enhancements:**\n- feat(channel): default OOM guard for `trellis channel spawn`. Workers that stay continuously idle past `channel.worker_guard.idle_timeout` (default `5m`) are self-terminated with `killed{reason:\"idle-timeout\"}`. Mid-turn workers are not killed by idle cleanup.\n- feat(channel): spawn-time live-worker budget per project/scope. Default `channel.worker_guard.max_live_workers: 6`. Expired idle workers are cleaned first; if the budget is still exhausted, `spawn` rejects with live-worker details and kill / override hints.\n- feat(channel): simplified worker message routing by removing message tags from channel send/wait/run internals.\n- feat(config): `.trellis/config.yaml` gains a `channel.worker_guard` section via `trellis update`.\n- feat(skills): Trellis beta bundle includes the built-in `trellis-spec-bootstarp` skill for bootstrapping `.trellis/spec/` from the real codebase.\n**Bug Fixes:**\n- fix(cli): `task.py archive` now fails when its auto-commit fails instead of reporting a successful archive with uncommitted changes.",
+  "migrations": [],
+  "configSectionsAdded": [
+    {
+      "file": ".trellis/config.yaml",
+      "sentinel": "worker_guard:",
+      "sectionHeading": "Channel worker OOM guard"
+    }
+  ],
+  "notes": "Beta patch on top of 0.6.0-beta.17. `trellis update` appends `channel.worker_guard` defaults for existing projects. To opt out, set `channel.worker_guard.idle_timeout: 0` and / or `channel.worker_guard.max_live_workers: 0`, or pass `--idle-timeout 0` / `--max-live-workers 0` per spawn."
+}

package/dist/migrations/manifests/0.6.0-beta.19.json

@@ -0,0 +1,9 @@
+{
+  "version": "0.6.0-beta.19",
+  "description": "Beta patch: Pi trellis_subagent native progress cards, durable channel idempotency, task create/archive collision guard, workflow breadcrumb clarification, and Codex 0.131 timeout bounds.",
+  "breaking": false,
+  "recommendMigrate": false,
+  "changelog": "**Enhancements:**\n- feat(pi): Pi extension now exposes `trellis_subagent` with native progress cards, `single` / `parallel` / `chain` dispatch modes, throttled live updates, and Trellis-agent validation (#286, #290).\n**Bug Fixes:**\n- fix(core): channel `sendMessage` and `postThread` accept durable `idempotencyKey` values so retries return the original JSONL event and do not duplicate strict-delivery `undeliverable` events.\n- fix(cli): `task.py create` now rejects slugs that already exist under `.trellis/tasks/archive/**` and prints the archived path (#291).\n- fix(workflow): `[workflow-state:in_progress]` now distinguishes sub-agent types from skills so agents do not call missing `trellis-implement` / `trellis-research` skills (#283).\n- fix(codex): `.codex/config.toml` emits `min_wait_timeout_ms`, `default_wait_timeout_ms`, and `max_wait_timeout_ms` together so Codex CLI 0.131+ accepts merged multi_agent_v2 timeout config (#294).\n**Internal:**\n- chore(release): restore the shipped `0.5.17` migration manifest so manifest continuity and update-chain checks pass for the beta release.",
+  "migrations": [],
+  "notes": "Beta patch on top of 0.6.0-beta.18. Run `trellis update` to refresh Pi, Codex, workflow, and task templates. No migration command is required."
+}

package/dist/templates/codex/config.toml

@@ -26,10 +26,12 @@ project_doc_fallback_filenames = ["AGENTS.md"]
 # `enabled = true` is required inside the table — the table form does
 # NOT auto-enable the feature without it.
 # - max_concurrent_threads_per_session: bumps default 4 → 6.
-# - min_wait_timeout_ms: 480000 ms = 8 min. Codex default is 10 s, too
-#   short for Trellis subagents that routinely take 2-10 min. Hard
-#   ceiling is 3,600,000 (1 h).
+# - min/default/max_wait_timeout_ms: keep Codex's merged timeout config
+#   valid while raising the default wait to 8 min. Codex 0.131+ validates
+#   min <= default <= max.
 [features.multi_agent_v2]
 enabled = true
 max_concurrent_threads_per_session = 6
 min_wait_timeout_ms = 480000
+default_wait_timeout_ms = 480000
+max_wait_timeout_ms = 3600000

package/dist/templates/common/bundled-skills/trellis-spec-bootstarp/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: trellis-spec-bootstarp
+description: "Bootstrap project-specific Trellis coding specs with a platform-neutral single-agent workflow. Use when creating or refreshing .trellis/spec guidelines, analyzing a codebase with GitNexus, ABCoder, or source inspection, decomposing package/layer spec work, and writing real codebase-backed spec docs without placeholder text."
+---
+
+# Trellis Spec Bootstarp
+
+Use this skill to create or refresh `.trellis/spec/` guidelines from the real codebase. One capable agent owns the full loop: analyze the repository, choose the spec boundaries, write the docs, and verify the result. The workflow does not depend on a specific host, CLI, or agent brand.
+
+## Workflow
+
+1. Confirm Trellis is initialized and inspect the current `.trellis/spec/` tree.
+2. Analyze the repository architecture with the best available tools: GitNexus, ABCoder, language tooling, and direct source reads.
+3. Decompose the spec work by package and layer only when that reflects the actual codebase.
+4. Fill or reshape the spec files with concrete patterns, file paths, examples, and anti-patterns from the project.
+5. Verify that the final specs are internally consistent and contain no template placeholders.
+
+## Reference Routing
+
+| Need | Read |
+|------|------|
+| Repository architecture analysis | [references/repository-analysis.md](references/repository-analysis.md) |
+| Spec work decomposition and task planning | [references/spec-task-planning.md](references/spec-task-planning.md) |
+| Writing high-signal Trellis spec files | [references/spec-writing.md](references/spec-writing.md) |
+| GitNexus and ABCoder MCP setup | [references/mcp-setup.md](references/mcp-setup.md) |
+
+## Operating Rules
+
+- Treat templates as starting points, not contracts. Delete, rename, split, or add spec files when the repository calls for it.
+- Prefer source-backed rules over generic advice. Every important recommendation should point at a real file or repeated local pattern.
+- Keep execution single-owner by default. Optional helper agents are an implementation detail, not a requirement or user-visible dependency.
+- Do not write platform-specific instructions unless the target project already standardizes on that platform.
+- Do not leave placeholder text, empty headings, or copied boilerplate in `.trellis/spec/`.
+
+## Done Criteria
+
+- `.trellis/spec/` describes the project as it exists now.
+- Each relevant package or layer has practical coding guidance with real examples.
+- Non-applicable template sections are removed.
+- `index.md` files match the final spec file set.
+- Any required setup or analysis assumptions are documented in the relevant spec or task notes.

package/dist/templates/common/bundled-skills/trellis-spec-bootstarp/references/mcp-setup.md

@@ -0,0 +1,90 @@
+# MCP Setup
+
+GitNexus and ABCoder are recommended when bootstrapping Trellis specs because they expose architecture and AST context to the agent. They are tool choices, not platform requirements. Configure them through whatever MCP mechanism your agent host provides.
+
+## GitNexus
+
+GitNexus builds a code knowledge graph from the repository. Use it for module boundaries, execution flows, dependency relationships, blast radius, and graph queries.
+
+### Install and Index
+
+```bash
+# Run from the repository root.
+npx gitnexus analyze
+
+# Check index status.
+npx gitnexus status
+
+# Re-index after code changes when the analysis is stale.
+npx gitnexus analyze
+```
+
+The index is written to `.gitnexus/`. Keep embeddings only if the project already uses them; otherwise a normal index is enough for spec bootstrapping.
+
+### MCP Server Command
+
+Use this server command in the host's MCP configuration:
+
+```bash
+npx -y gitnexus mcp
+```
+
+### Useful Tools
+
+| Tool | Purpose |
+|------|---------|
+| `gitnexus_query` | Find execution flows and functional areas by concept |
+| `gitnexus_context` | Inspect callers, callees, references, and process participation for a symbol |
+| `gitnexus_impact` | Understand blast radius before changing a symbol |
+| `gitnexus_detect_changes` | Check changed symbols and affected flows before finishing |
+| `gitnexus_cypher` | Run direct graph queries |
+| `gitnexus_list_repos` | List indexed repositories |
+
+## ABCoder
+
+ABCoder parses code into UniAST and gives precise package, file, and node-level structure. Use it for signatures, type shapes, implementations, dependencies, and reverse references.
+
+### Install
+
+```bash
+go install github.com/cloudwego/abcoder@latest
+abcoder --help
+```
+
+### Parse Repositories
+
+```bash
+abcoder parse /absolute/path/to/package \
+  --lang typescript \
+  --name package-name \
+  --output ~/abcoder-asts
+```
+
+For monorepos, parse each package with a stable `--name` so task notes can reference the same repository names.
+
+### MCP Server Command
+
+Use this server command in the host's MCP configuration:
+
+```bash
+abcoder mcp ~/abcoder-asts
+```
+
+### Useful Tools
+
+| Tool | Layer | Purpose |
+|------|-------|---------|
+| `list_repos` | 1 | List parsed repositories |
+| `get_repo_structure` | 2 | Inspect packages and files |
+| `get_package_structure` | 3 | Inspect nodes within a package |
+| `get_file_structure` | 3 | Inspect functions, classes, types, and signatures in a file |
+| `get_ast_node` | 4 | Retrieve code, dependencies, references, and implementations |
+
+## Verification
+
+After configuration, verify from the agent host that both MCP servers are visible. Then run one simple query against each server before starting the spec writing pass.
+
+```bash
+ls .gitnexus/meta.json
+ls ~/abcoder-asts/*.json
+```

package/dist/templates/common/bundled-skills/trellis-spec-bootstarp/references/repository-analysis.md

@@ -0,0 +1,59 @@
+# Repository Analysis
+
+The goal is to discover the project's real architecture before writing rules. Do not start from generic spec templates and fill blanks. Start from the code, then let the spec structure follow.
+
+## Analysis Order
+
+1. Read the existing `.trellis/spec/` tree and note which files are templates, outdated, or already project-specific.
+2. Inspect package manifests, build scripts, workspace config, and top-level documentation to identify packages and runtime layers.
+3. Use GitNexus for execution flows, module clusters, dependency hubs, and impact-sensitive areas.
+4. Use ABCoder or language-native tooling for exact signatures, types, class boundaries, and implementation examples.
+5. Read representative source and test files directly before turning any finding into a spec rule.
+
+## What To Capture
+
+| Area | Questions |
+|------|-----------|
+| Package boundaries | What does each package own? What imports cross boundaries? |
+| Runtime layers | Which code is CLI, backend, frontend, worker, shared library, test-only, or tooling? |
+| Core abstractions | Which types, services, stores, commands, routes, or adapters define the system shape? |
+| Data flow | Where does user input enter, how is it validated, and where does state persist? |
+| Error handling | How are failures represented, logged, surfaced, and tested? |
+| Configuration | Where do defaults, environment config, generated files, and templates live? |
+| Tests | Which test styles are trusted examples for new work? |
+
+## GitNexus Usage
+
+Start broad, then inspect specific symbols:
+
+```text
+gitnexus_query({query: "CLI command execution flow"})
+gitnexus_query({query: "template generation and migration"})
+gitnexus_context({name: "SymbolName"})
+gitnexus_cypher({query: "MATCH (n)-[r]->(m) RETURN n.name, type(r), m.name LIMIT 30"})
+```
+
+Use GitNexus results to find important files and flows. Do not quote graph output as the final authority until you have checked the relevant source files.
+
+## ABCoder Usage
+
+Use ABCoder when the spec needs exact code shapes:
+
+```text
+list_repos()
+get_repo_structure({repo_name: "package-name"})
+get_file_structure({repo_name: "package-name", file_path: "src/example.ts"})
+get_ast_node({repo_name: "package-name", node_ids: [{mod_path: "...", pkg_path: "...", name: "SymbolName"}]})
+```
+
+ABCoder is most valuable for documenting constructor patterns, function signatures, type contracts, and reference chains.
+
+## Analysis Notes
+
+Keep short notes while analyzing. The notes should include:
+
+- Package or layer name.
+- Files that define the local pattern.
+- Rules the spec should teach.
+- Anti-patterns found in old code, comments, tests, or migration paths.
+- Spec files that should be created, deleted, renamed, or merged.

package/dist/templates/common/bundled-skills/trellis-spec-bootstarp/references/spec-task-planning.md

@@ -0,0 +1,61 @@
+# Spec Task Planning
+
+Use a single agent as the default execution model. The agent may create Trellis tasks for traceability, but the skill should not require a specific platform, CLI, or parallel worker model.
+
+## Decomposition
+
+Create spec work units around real ownership boundaries:
+
+- One package when a package has its own conventions.
+- One layer when the same package has distinct frontend, backend, CLI, worker, or shared-library rules.
+- One cross-cutting guide when a pattern spans packages and is not owned by one layer.
+
+Avoid artificial decomposition. A small library usually needs one focused spec pass, not several tasks.
+
+## Task Shape
+
+When a Trellis task is useful, write a concise PRD with these sections:
+
+```markdown
+# Fill <package-or-layer> Trellis Specs
+
+## Goal
+Write project-specific `.trellis/spec/` guidance for <scope>.
+
+## Scope
+- Spec directory:
+- Source directories to inspect:
+- Tests to inspect:
+- Out of scope:
+
+## Architecture Context
+Summarize the concrete findings from repository analysis.
+
+## Files To Create Or Update
+- `.trellis/spec/.../index.md`
+- `.trellis/spec/.../<topic>.md`
+
+## Rules
+- Adapt the spec file set to the real codebase.
+- Use real source examples with file paths.
+- Remove template-only sections that do not apply.
+- Do not modify product source code unless the task explicitly asks for it.
+
+## Acceptance Criteria
+- [ ] Specs contain concrete examples and anti-patterns from the repository.
+- [ ] No placeholder text remains.
+- [ ] Index files match the final spec files.
+- [ ] Claims are backed by source files, tests, or project docs.
+```
+
+## Optional Helper Agents
+
+If the host supports subagents, helpers can inspect independent packages or run verification. They are optional. The main agent still owns integration and final quality.
+
+Helper tasks must have clear ownership:
+
+- Read-only research tasks may inspect any source needed for the assigned scope.
+- Write tasks should own disjoint spec directories.
+- Verification tasks should check placeholder removal, broken links, and consistency.
+
+Do not encode helper-agent names, vendor-specific commands, or platform-specific routing in the skill. Put only the required work and acceptance criteria in the task.

package/dist/templates/common/bundled-skills/trellis-spec-bootstarp/references/spec-writing.md

@@ -0,0 +1,70 @@
+# Spec Writing
+
+Trellis specs are coding guidance for future agents. They should explain how to work in this repository, not how a generic project might be organized.
+
+## Write From Evidence
+
+Each important rule should be backed by one of these:
+
+- A source file that demonstrates the preferred pattern.
+- A test file that shows expected behavior.
+- A project document that defines the convention.
+- A repeated pattern across multiple files.
+
+Use short snippets only when they make the rule clearer. Prefer linking to the file path and naming the symbol or behavior.
+
+## File Structure
+
+Keep the spec tree aligned with the project:
+
+- Keep `index.md` as the navigation file for the spec directory.
+- Split topics when developers would look for them independently.
+- Merge topics when separate files would repeat the same rule.
+- Delete template files that do not apply.
+- Add new files for important local patterns the template missed.
+
+## Content Standards
+
+Good spec sections include:
+
+- When the rule applies.
+- The local pattern to follow.
+- The source or test files that prove the pattern.
+- Common mistakes or anti-patterns.
+- Verification commands or checks when they are specific and reliable.
+
+Avoid:
+
+- Placeholder prose.
+- Generic framework advice.
+- Tool instructions that only work in one agent host.
+- Long copied code blocks.
+- Rules based on a single accidental implementation detail.
+
+## Example Shape
+
+```markdown
+## Command Handlers
+
+Command handlers should keep argument parsing, validation, and side effects separate. The local pattern is:
+
+- Parse CLI flags at the command boundary.
+- Convert raw inputs into typed task options before invoking core logic.
+- Keep filesystem writes in the command or service layer, not in template helpers.
+
+Reference files:
+- `packages/cli/src/commands/example.ts`
+- `packages/cli/test/commands/example.test.ts`
+
+Avoid passing raw `process.argv` or unvalidated config objects into shared helpers.
+```
+
+## Final Pass
+
+Before finishing:
+
+```bash
+grep -R "To be filled\\|TODO: fill\\|placeholder" .trellis/spec
+```
+
+Also check links, index files, and whether any spec still describes a template rather than this repository.

package/dist/templates/trellis/scripts/common/task_store.py

@@ -83,6 +83,30 @@ def ensure_tasks_dir(repo_root: Path) -> Path:
     return tasks_dir
 
 
+def _find_archived_task_by_dir_name(tasks_dir: Path, dir_name: str) -> Path | None:
+    """Find an archived task directory with the exact active-task dir name."""
+    archive_dir = tasks_dir / DIR_ARCHIVE
+    if not archive_dir.is_dir():
+        return None
+
+    for month_dir in sorted(archive_dir.iterdir()):
+        if not month_dir.is_dir():
+            continue
+        candidate = month_dir / dir_name
+        if candidate.is_dir():
+            return candidate
+
+    return None
+
+
+def _repo_relative_path(path: Path, repo_root: Path) -> str:
+    """Format a path relative to the repo root when possible."""
+    try:
+        return path.relative_to(repo_root).as_posix()
+    except ValueError:
+        return str(path)
+
+
 # =============================================================================
 # Sub-agent platform detection + JSONL seeding
 # =============================================================================
@@ -193,6 +217,13 @@ def cmd_create(args: argparse.Namespace) -> int:
     task_dir = tasks_dir / dir_name
     task_json_path = task_dir / FILE_TASK_JSON
 
+    archived_task_dir = _find_archived_task_by_dir_name(tasks_dir, dir_name)
+    if archived_task_dir:
+        print(colored(f"Error: Task already archived: {dir_name}", Colors.RED), file=sys.stderr)
+        print(f"Archived at: {_repo_relative_path(archived_task_dir, repo_root)}", file=sys.stderr)
+        print("Use a new slug if you intend to create a new task.", file=sys.stderr)
+        return 1
+
     if task_dir.exists():
         print(colored(f"Warning: Task directory already exists: {dir_name}", Colors.YELLOW), file=sys.stderr)
     else:

package/dist/templates/trellis/workflow.md

@@ -195,6 +195,7 @@ Then run `task.py start <task-dir>` to flip status to in_progress.
      commit, including Phase 3.3 spec update and Phase 3.4 commit. -->
 
 [workflow-state:in_progress]
+**Tools**: `trellis-implement` / `trellis-research` are sub-agent types only (Task/Agent tool, NOT Skill — there is no skill by these names). `trellis-update-spec` is a skill. `trellis-check` exists as both; prefer the Agent form when verifying after code changes.
 **Flow**: trellis-implement → trellis-check → trellis-update-spec → commit (Phase 3.4) → `/trellis:finish-work`.
 **Main-session default (no override)**: dispatch the `trellis-implement` / `trellis-check` sub-agents — the main agent does NOT edit code by default. Phase 3.4 commit (required, once): after trellis-update-spec, or whenever implementation is verifiably complete, the main agent **drives the commit** — state the commit plan in user-facing text, then run `git commit` — BEFORE suggesting `/trellis:finish-work`. `/finish-work` refuses to run on a dirty working tree (paths outside `.trellis/workspace/` and `.trellis/tasks/`).
 **Sub-agent self-exemption**: if you are already running as `trellis-implement`, implement directly from the loaded task context and do NOT spawn another `trellis-implement`; if you are already running as `trellis-check`, review/fix directly and do NOT spawn another `trellis-check`. The default dispatch rule applies to the main session only.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mindfoldhq/trellis",
-  "version": "0.5.16",
+  "version": "0.5.18",
   "description": "AI capabilities grow like ivy — Trellis provides the structure to guide them along a disciplined path",
   "type": "module",
   "main": "./dist/index.js",