npm - @pennixrv/trellis - Versions diffs - 0.7.0-beta.5 → 0.7.0-beta.50 - Mend

@pennixrv/trellis 0.7.0-beta.5 → 0.7.0-beta.50

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (219) hide show

package/dist/templates/copilot/prompts/brainstorm.prompt.md CHANGED Viewed

@@ -10,7 +10,11 @@ A request to build, implement, fix, refactor, or "go ahead" is not approval to l
 For every non-trivial task, the user must respond at least once after the initial request before implementation begins. If no clarification is needed, that response must approve the final planning summary described below.
-While any user-owned product, scope, UX, compatibility, risk, or acceptance decision remains unresolved, end the turn with exactly one highest-value question. Do not edit product code, dispatch implementation, or run `task.py start`.
+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 change-bearing work, inventory evidence and decision dependencies; batch independent material questions with `pennix-decision-grill` when useful, and do not implement or run `task.py start` until change decisions are sealed and approved.
+## 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. Keep status `planning`, record and verify the evidence, commit task artifacts, and archive directly; do not run `task.py start` or wait for a second implementation approval. This route remains eligible regardless of complexity, cross-owner scope, multiple evidence units, or whether findings include recommendations or unresolved product choices. Record these in task artifacts without changing protected targets, deploying, releasing, altering credentials, or mutating external systems. The initial request authorizes the requested main-session research; do not require a second implementation approval, Planning Seal, or `task.py start`. If independent subnode evidence is requested, freeze its dispatch plan in the task and obtain explicit approval before any spawn/send; that approval authorizes only the listed evidence dispatch. A later implementation request needs a change-bearing task and its normal Planning Seal and implementation approval gates.
 ## Non-Negotiable Evidence Rule
@@ -22,6 +26,10 @@ Do not ask the user to confirm facts that the repository can answer. Ask only fo
 Repository evidence establishes current behavior and technical constraints. The user's intended behavior, feature scope boundaries, and UX preferences are never answerable by repository evidence alone, even when an existing pattern exists; existing patterns are options and recommendation evidence, not decisions.
+## Evidence Units For Read-Heavy Work
+When research, audit, review, or investigation is too large for one independently useful conclusion in the current session, split it into evidence units. Each unit has one question or scope, a minimal evidence range, a destination artifact, and a stop condition; persist facts, conclusion or blocker, unknowns, and a recovery point before starting another unit. Size each unit for one normal context window without promising an exact token or time limit.
 ---
 Use this skill during Phase 1 planning to turn the user's request into clear requirements and planning artifacts.
@@ -52,18 +60,17 @@ Use a concise title from the user's request. Both the title and `--description`
    - product intent still needed from the user
    - scope or risk decisions still needed from the user
    - likely out-of-scope items
-4. If a user-owned decision remains, ask the single highest-value question, include your recommendation and trade-off, then stop. Do not perform implementation work in the same turn.
-5. After each user answer, update `prd.md`, recompute the decision inventory, and repeat from step 2.
-6. When no user-owned decision remains, create or update `design.md` and `implement.md` for complex tasks.
-7. Run the requirement convergence gate, then the PRD convergence pass.
-8. Present the final planning summary and stop. Do not run `task.py start` or edit product code in the same turn.
-9. Only a subsequent user message that explicitly approves the latest planning summary authorizes `task.py start` and implementation. If the artifacts change materially after approval, repeat the final review.
+4. If the requested research scope or method depends on an unresolved user-owned choice, ask only that material question; otherwise proceed with the evidence work already requested. Use `pennix-decision-grill` to batch independent choices only when needed to define the requested work. A research recommendation or open product choice can be reported as a finding without being decided or sealed for implementation.
+5. If the user requests independent subnode evidence, first freeze the dispatch plan in the task: question, evidence-unit mapping and grouping rationale, brief scope/stop conditions/destinations, concurrency and FIFO refill/acceptance method. Obtain the user's explicit approval of that frozen plan before any spawn/send. This approval covers only the listed evidence dispatch; material changes to units, scope, method, owner, risk, or acceptance require reapproval. Main-session evidence work may continue while dispatch approval is pending.
+6. When a needed answer returns, persist it, recheck evidence, and continue the same task.
+7. For `analysis_only`, record and verify the declared evidence and no-change boundary in planning; do not require a Planning Seal, implementation approval, or `task.py start` merely because the research is complex.
+8. For change-bearing work, resolve material decisions, create/update complex-task artifacts, run the requirement convergence and PRD passes, then close and present the Planning Seal. Stop before implementation. Only later explicit approval of this task's current sealed revision authorizes native plan approval and `task.py start`; material changes require `task.py replan` and approval of its newly sealed revision.
 Do not invent a project-specific product/spec hierarchy. If the repository already has product, domain, or spec docs, use them. If it does not, proceed with the evidence that exists.
 ## Question Rules
-Ask only one question per message.
+Ask one bounded batch per message: include up to three independent material frontier questions. Ask exactly one question only when it is the sole remaining material decision or later decisions depend on its answer.
 Each question must include:
@@ -76,9 +83,7 @@ Do not ask process questions such as whether to search, inspect files, or contin
 Recommendations are not default selections. Never choose a recommended product decision on the user's behalf merely because the user asked for implementation.
-Do not manufacture clarification questions when the request and repository evidence already resolve every decision. In that case, proceed directly to the final planning summary, which still requires a subsequent explicit approval.
-The final review is a required phase-transition gate, not a prohibited process question. Task-creation consent, the initial implementation request, and approval given before the latest final summary do not satisfy this gate.
+Do not manufacture clarification questions when the request and repository evidence already resolve the scope and method. For `analysis_only`, proceed with the requested evidence work; no final implementation review or approval is required. The final review and subsequent approval are phase-transition gates for change-bearing implementation only.
 ## Requirement Convergence Gate
@@ -91,10 +96,12 @@ Before final review, verify all of the following:
 - blocking open questions are empty
 - technical unknowns are researched or explicitly deferred without changing MVP behavior
-Lightweight tasks may omit `design.md` and `implement.md`; they may not skip evidence inspection, requirement convergence, final review, or fresh implementation approval.
+For `analysis_only`, the task PRD may stay bounded to evidence and the protected-target no-change boundary; no implementation review or approval is required. Change-bearing tasks retain their applicable evidence, convergence, final review, and fresh implementation approval gates.
 The final planning summary must show Goal, In Scope, Out of Scope, Acceptance Criteria, Key Decisions, relevant Risks or Deferred Items, and artifact status.
+For change-bearing work, the Planning Seal reconciles task artifacts, targets, branches, dependencies, release, validation, rollback, dynamic facts, and material decisions before implementation. It is not an eligibility or completion gate for `analysis_only` evidence work.
 ## Artifact Rules
 `prd.md` records requirements and acceptance:
@@ -142,15 +149,14 @@ After the pass, read `prd.md` top to bottom and verify that no fact is repeated
 ## Quality Bar
-Before declaring planning ready:
+Before declaring change-bearing planning ready:
+- `prd.md` contains testable acceptance criteria and has passed the PRD convergence pass.
+- Repository-answerable questions have been answered; blocking implementation questions are resolved.
+- Complex change-bearing tasks have `design.md` and `implement.md`; sub-agent-dispatch implementation tasks have curated manifests.
+- The Planning Seal and final summary cover the implementation target, validation, and rollback.
+- The user subsequently approved this task's current sealed plan.
-- `prd.md` contains testable acceptance criteria.
-- `prd.md` has passed the PRD convergence pass: no unresolved temporary brainstorm sections, no duplicate facts across sections, and no lost anchors, decisions, or acceptance mappings.
-- Repository-answerable questions have already been answered through inspection.
-- Blocking open questions are empty.
-- Complex tasks have `design.md` and `implement.md`.
-- Sub-agent-dispatch tasks have real curated entries in both `implement.jsonl` and `check.jsonl`; seed-only manifests are not ready.
-- The latest final planning summary has been presented to the user.
-- In a subsequent message, the user explicitly approved that summary for implementation.
+For `analysis_only`, verify the declared evidence deliverable and protected-target no-change boundary, then proceed to complete the research in planning without an implementation summary approval.
 Do not start implementation merely because the user originally asked for implementation.

package/dist/templates/markdown/spec/backend/database-guidelines.md.txt CHANGED Viewed

@@ -1,51 +1,51 @@
-# Database Guidelines
+# 数据库指南（Database Guidelines）
-> Database patterns and conventions for this project.
+> 本项目的数据库模式与约定。
 ---
-## Overview
+## 概览（Overview）
 <!--
-Document your project's database conventions here.
+在此记录项目的数据库约定。
-Questions to answer:
-- What ORM/query library do you use?
-- How are migrations managed?
-- What are the naming conventions for tables/columns?
-- How do you handle transactions?
+需要回答的问题：
+- 使用什么 ORM/查询库？
+- 如何管理迁移？
+- 表名和列名遵循什么命名约定？
+- 如何处理事务？
 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Query Patterns
+## 查询模式（Query Patterns）
-<!-- How should queries be written? Batch operations? -->
+<!-- 查询应如何编写？如何执行批量操作？ -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Migrations
+## 迁移（Migrations）
-<!-- How to create and run migrations -->
+<!-- 如何创建和运行迁移 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Naming Conventions
+## 命名约定（Naming Conventions）
-<!-- Table names, column names, index names -->
+<!-- 表名、列名和索引名 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Common Mistakes
+## 常见错误（Common Mistakes）
-<!-- Database-related mistakes your team has made -->
+<!-- 团队曾经出现过的数据库相关错误 -->
-(To be filled by the team)
+（待团队填写）

package/dist/templates/markdown/spec/backend/directory-structure.md.txt CHANGED Viewed

@@ -1,26 +1,26 @@
-# Directory Structure
+# 目录结构（Directory Structure）
-> How backend code is organized in this project.
+> 本项目如何组织后端代码。
 ---
-## Overview
+## 概览（Overview）
 <!--
-Document your project's backend directory structure here.
+在此记录项目的后端目录结构。
-Questions to answer:
-- How are modules/packages organized?
-- Where does business logic live?
-- Where are API endpoints defined?
-- How are utilities and helpers organized?
+需要回答的问题：
+- 模块/包如何组织？
+- 业务逻辑位于何处？
+- API 端点在哪里定义？
+- 工具和辅助函数如何组织？
 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Directory Layout
+## 目录布局（Directory Layout）
 ```
 <!-- Replace with your actual structure -->
@@ -31,24 +31,24 @@ src/
 ---
-## Module Organization
+## 模块组织（Module Organization）
-<!-- How should new features/modules be organized? -->
+<!-- 新功能/模块应如何组织？ -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Naming Conventions
+## 命名约定（Naming Conventions）
-<!-- File and folder naming rules -->
+<!-- 文件和目录的命名规则 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Examples
+## 示例（Examples）
-<!-- Link to well-organized modules as examples -->
+<!-- 链接到组织良好的模块作为示例 -->
-(To be filled by the team)
+（待团队填写）

package/dist/templates/markdown/spec/backend/error-handling.md.txt CHANGED Viewed

@@ -1,51 +1,51 @@
-# Error Handling
+# 错误处理（Error Handling）
-> How errors are handled in this project.
+> 本项目如何处理错误。
 ---
-## Overview
+## 概览（Overview）
 <!--
-Document your project's error handling conventions here.
+在此记录项目的错误处理约定。
-Questions to answer:
-- What error types do you define?
-- How are errors propagated?
-- How are errors logged?
-- How are errors returned to clients?
+需要回答的问题：
+- 定义了哪些错误类型？
+- 错误如何传播？
+- 错误如何记录日志？
+- 如何向客户端返回错误？
 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Error Types
+## 错误类型（Error Types）
-<!-- Custom error classes/types -->
+<!-- 自定义错误类/类型 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Error Handling Patterns
+## 错误处理模式（Error Handling Patterns）
-<!-- Try-catch patterns, error propagation -->
+<!-- try-catch 模式、错误传播方式 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## API Error Responses
+## API 错误响应（API Error Responses）
-<!-- Standard error response format -->
+<!-- 标准错误响应格式 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Common Mistakes
+## 常见错误（Common Mistakes）
-<!-- Error handling mistakes your team has made -->
+<!-- 团队曾经出现过的错误处理问题 -->
-(To be filled by the team)
+（待团队填写）

package/dist/templates/markdown/spec/backend/index.md.txt CHANGED Viewed

@@ -1,38 +1,38 @@
-# Backend Development Guidelines
+# 后端开发指南（Backend Development Guidelines）
-> Best practices for backend development in this project.
+> 本项目的后端开发最佳实践。
 ---
-## Overview
+## 概览（Overview）
-This directory contains guidelines for backend development. Fill in each file with your project's specific conventions.
+本目录包含后端开发指南。请在各文件中填写项目的具体约定。
 ---
-## Guidelines Index
+## 指南索引（Guidelines Index）
-| Guide | Description | Status |
+| 指南（Guide） | 说明（Description） | 状态（Status） |
 |-------|-------------|--------|
-| [Directory Structure](./directory-structure.md) | Module organization and file layout | To fill |
-| [Database Guidelines](./database-guidelines.md) | ORM patterns, queries, migrations | To fill |
-| [Error Handling](./error-handling.md) | Error types, handling strategies | To fill |
-| [Quality Guidelines](./quality-guidelines.md) | Code standards, forbidden patterns | To fill |
-| [Logging Guidelines](./logging-guidelines.md) | Structured logging, log levels | To fill |
+| [目录结构（Directory Structure）](./directory-structure.md) | 模块组织和文件布局 | 待填写 |
+| [数据库指南（Database Guidelines）](./database-guidelines.md) | ORM 模式、查询和迁移 | 待填写 |
+| [错误处理（Error Handling）](./error-handling.md) | 错误类型和处理策略 | 待填写 |
+| [质量指南（Quality Guidelines）](./quality-guidelines.md) | 代码标准和禁止模式 | 待填写 |
+| [日志指南（Logging Guidelines）](./logging-guidelines.md) | 结构化日志和日志级别 | 待填写 |
 ---
-## How to Fill These Guidelines
+## 如何填写这些指南（How to Fill These Guidelines）
-For each guideline file:
+对于每个指南文件：
-1. Document your project's **actual conventions** (not ideals)
-2. Include **code examples** from your codebase
-3. List **forbidden patterns** and why
-4. Add **common mistakes** your team has made
+1. 记录项目的**实际约定**，而不是理想状态
+2. 包含代码库中的**代码示例**
+3. 列出**禁止模式**及其原因
+4. 补充团队曾经出现过的**常见错误**
-The goal is to help AI assistants and new team members understand how YOUR project works.
+目标是帮助 AI 助手和新团队成员理解项目的实际工作方式。
 ---
-**Language**: All documentation should be written in **English**.
+**语言（Language）**：所有文档默认使用**简体中文**。

package/dist/templates/markdown/spec/backend/logging-guidelines.md.txt CHANGED Viewed

@@ -1,51 +1,51 @@
-# Logging Guidelines
+# 日志指南（Logging Guidelines）
-> How logging is done in this project.
+> 本项目如何记录日志。
 ---
-## Overview
+## 概览（Overview）
 <!--
-Document your project's logging conventions here.
+在此记录项目的日志约定。
-Questions to answer:
-- What logging library do you use?
-- What are the log levels and when to use each?
-- What should be logged?
-- What should NOT be logged (PII, secrets)?
+需要回答的问题：
+- 使用什么日志库？
+- 有哪些日志级别，分别何时使用？
+- 应记录哪些内容？
+- 哪些内容不应记录（个人身份信息、密钥）？
 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Log Levels
+## 日志级别（Log Levels）
-<!-- When to use each level: debug, info, warn, error -->
+<!-- 各级别的使用场景：debug、info、warn、error -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Structured Logging
+## 结构化日志（Structured Logging）
-<!-- Log format, required fields -->
+<!-- 日志格式和必填字段 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## What to Log
+## 应记录的内容（What to Log）
-<!-- Important events to log -->
+<!-- 应记录的重要事件 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## What NOT to Log
+## 不应记录的内容（What NOT to Log）
-<!-- Sensitive data, PII, secrets -->
+<!-- 敏感数据、个人身份信息和密钥 -->
-(To be filled by the team)
+（待团队填写）

package/dist/templates/markdown/spec/backend/quality-guidelines.md.txt CHANGED Viewed

@@ -1,51 +1,51 @@
-# Quality Guidelines
+# 质量指南（Quality Guidelines）
-> Code quality standards for backend development.
+> 后端开发的代码质量标准。
 ---
-## Overview
+## 概览（Overview）
 <!--
-Document your project's quality standards here.
+在此记录项目的质量标准。
-Questions to answer:
-- What patterns are forbidden?
-- What linting rules do you enforce?
-- What are your testing requirements?
-- What code review standards apply?
+需要回答的问题：
+- 禁止哪些模式？
+- 执行哪些 lint 规则？
+- 有哪些测试要求？
+- 适用哪些代码审查标准？
 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Forbidden Patterns
+## 禁止模式（Forbidden Patterns）
-<!-- Patterns that should never be used and why -->
+<!-- 永远不应使用的模式及其原因 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Required Patterns
+## 必须遵守的模式（Required Patterns）
-<!-- Patterns that must always be used -->
+<!-- 必须始终使用的模式 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Testing Requirements
+## 测试要求（Testing Requirements）
-<!-- What level of testing is expected -->
+<!-- 期望达到的测试层级 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Code Review Checklist
+## 代码审查清单（Code Review Checklist）
-<!-- What reviewers should check -->
+<!-- 审查者应检查的内容 -->
-(To be filled by the team)
+（待团队填写）

package/dist/templates/markdown/spec/frontend/component-guidelines.md.txt CHANGED Viewed

@@ -1,59 +1,59 @@
-# Component Guidelines
+# 组件指南（Component Guidelines）
-> How components are built in this project.
+> 本项目如何构建组件。
 ---
-## Overview
+## 概览（Overview）
 <!--
-Document your project's component conventions here.
+在此记录项目的组件约定。
-Questions to answer:
-- What component patterns do you use?
-- How are props defined?
-- How do you handle composition?
-- What accessibility standards apply?
+需要回答的问题：
+- 使用哪些组件模式？
+- 如何定义 props？
+- 如何处理组合？
+- 适用哪些无障碍标准？
 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Component Structure
+## 组件结构（Component Structure）
-<!-- Standard structure of a component file -->
+<!-- 组件文件的标准结构 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Props Conventions
+## Props 约定（Props Conventions）
-<!-- How props should be defined and typed -->
+<!-- props 应如何定义和声明类型 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Styling Patterns
+## 样式模式（Styling Patterns）
-<!-- How styles are applied (CSS modules, styled-components, Tailwind, etc.) -->
+<!-- 如何应用样式（CSS modules、styled-components、Tailwind 等） -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Accessibility
+## 无障碍（Accessibility）
-<!-- A11y requirements and patterns -->
+<!-- A11y 要求和模式 -->
-(To be filled by the team)
+（待团队填写）
 ---
-## Common Mistakes
+## 常见错误（Common Mistakes）
-<!-- Component-related mistakes your team has made -->
+<!-- 团队曾经出现过的组件相关错误 -->
-(To be filled by the team)
+（待团队填写）