npm - @pennixrv/trellis - Versions diffs - 0.7.1 → 0.7.2-beta.2 - Mend

@pennixrv/trellis 0.7.1 → 0.7.2-beta.2

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 (321) hide show

package/dist/templates/copilot/prompts/break-loop.prompt.md DELETED Viewed

@@ -1,129 +0,0 @@
----
-description: "Trellis Copilot prompt: Break the Loop - Deep Bug Analysis"
----
-# Break the Loop - Deep Bug Analysis
-When debug is complete, use this command for deep analysis to break the "fix bug -> forget -> repeat" cycle.
----
-## Analysis Framework
-Analyze the bug you just fixed from these 5 dimensions:
-### 1. Root Cause Category
-Which category does this bug belong to?
-| Category | Characteristics | Example |
-|----------|-----------------|---------|
-| **A. Missing Spec** | No documentation on how to do it | New feature without checklist |
-| **B. Cross-Layer Contract** | Interface between layers unclear | API returns different format than expected |
-| **C. Change Propagation Failure** | Changed one place, missed others | Changed function signature, missed call sites |
-| **D. Test Coverage Gap** | Unit test passes, integration fails | Works alone, breaks when combined |
-| **E. Implicit Assumption** | Code relies on undocumented assumption | Timestamp seconds vs milliseconds |
-### 2. Why Fixes Failed (if applicable)
-If you tried multiple fixes before succeeding, analyze each failure:
-- **Surface Fix**: Fixed symptom, not root cause
-- **Incomplete Scope**: Found root cause, didn't cover all cases
-- **Tool Limitation**: grep missed it, type check wasn't strict
-- **Mental Model**: Kept looking in same layer, didn't think cross-layer
-### 3. Prevention Mechanisms
-What mechanisms would prevent this from happening again?
-| Type | Description | Example |
-|------|-------------|---------|
-| **Documentation** | Write it down so people know | Update thinking guide |
-| **Architecture** | Make the error impossible structurally | Type-safe wrappers |
-| **Compile-time** | TypeScript strict, no any | Signature change causes compile error |
-| **Runtime** | Monitoring, alerts, scans | Detect orphan entities |
-| **Test Coverage** | E2E tests, integration tests | Verify full flow |
-| **Code Review** | Checklist, PR template | "Did you check X?" |
-### 4. Systematic Expansion
-What broader problems does this bug reveal?
-- **Similar Issues**: Where else might this problem exist?
-- **Design Flaw**: Is there a fundamental architecture issue?
-- **Process Flaw**: Is there a development process improvement?
-- **Knowledge Gap**: Is the team missing some understanding?
-### 5. Knowledge Capture
-Solidify insights into the system:
-- [ ] Update `.trellis/spec/guides/` thinking guides
-- [ ] Update `.trellis/spec/backend/` or `frontend/` docs
-- [ ] Create issue record (if applicable)
-- [ ] Create feature ticket for root fix
-- [ ] Update check commands if needed
----
-## Output Format
-Please output analysis in this format:
-```markdown
-## Bug Analysis: [Short Description]
-### 1. Root Cause Category
-- **Category**: [A/B/C/D/E] - [Category Name]
-- **Specific Cause**: [Detailed description]
-### 2. Why Fixes Failed (if applicable)
-1. [First attempt]: [Why it failed]
-2. [Second attempt]: [Why it failed]
-...
-### 3. Prevention Mechanisms
-| Priority | Mechanism | Specific Action | Status |
-|----------|-----------|-----------------|--------|
-| P0 | ... | ... | TODO/DONE |
-### 4. Systematic Expansion
-- **Similar Issues**: [List places with similar problems]
-- **Design Improvement**: [Architecture-level suggestions]
-- **Process Improvement**: [Development process suggestions]
-### 5. Knowledge Capture
-- [ ] [Documents to update / tickets to create]
-```
----
-## Core Philosophy
-> **The value of debugging is not in fixing the bug, but in making this class of bugs never happen again.**
-Three levels of insight:
-1. **Tactical**: How to fix THIS bug
-2. **Strategic**: How to prevent THIS CLASS of bugs
-3. **Philosophical**: How to expand thinking patterns
-30 minutes of analysis saves 30 hours of future debugging.
----
-## After Analysis: Immediate Actions
-**IMPORTANT**: After completing the analysis above, you MUST immediately:
-1. **Update spec/guides** - Don't just list TODOs, actually update the relevant files:
-   - If it's a cross-platform issue �?update `cross-platform-thinking-guide.md`
-   - If it's a cross-layer issue �?update `cross-layer-thinking-guide.md`
-   - If it's a code reuse issue �?update `code-reuse-thinking-guide.md`
-   - If it's domain-specific �?update `backend/*.md` or `frontend/*.md`
-2. **Sync templates** - After updating `.trellis/spec/`, sync to `src/templates/markdown/spec/`
-3. **Commit the spec updates** - This is the primary output, not just the analysis text
-> **The analysis is worthless if it stays in chat. The value is in the updated specs.**

package/dist/templates/copilot/prompts/check-cross-layer.prompt.md DELETED Viewed

@@ -1,170 +0,0 @@
----
-description: "Trellis Copilot prompt: Cross-Layer Check"
----
-# Cross-Layer Check
-Check if your changes considered all dimensions. Most bugs come from "didn't think of it", not lack of technical skill.
-> **Note**: This is a **post-implementation** safety net. Ideally, read the [Pre-Implementation Checklist](.trellis/spec/guides/pre-implementation-checklist.md) **before** writing code.
----
-## Related Documents
-| Document | Purpose | Timing |
-|----------|---------|--------|
-| [Pre-Implementation Checklist](.trellis/spec/guides/pre-implementation-checklist.md) | Questions before coding | **Before** writing code |
-| [Code Reuse Thinking Guide](.trellis/spec/guides/code-reuse-thinking-guide.md) | Pattern recognition | During implementation |
-| **`/`** (this) | Verification check | **After** implementation |
----
-## Execution Steps
-### 1. Identify Change Scope
-```bash
-git status
-git diff --name-only
-```
-### 2. Select Applicable Check Dimensions
-Based on your change type, execute relevant checks below:
----
-## Dimension A: Cross-Layer Data Flow (Required when 3+ layers)
-**Trigger**: Changes involve 3 or more layers
-| Layer | Common Locations |
-|-------|------------------|
-| API/Routes | `routes/`, `api/`, `handlers/`, `controllers/` |
-| Service/Business Logic | `services/`, `lib/`, `core/`, `domain/` |
-| Database/Storage | `db/`, `models/`, `repositories/`, `schema/` |
-| UI/Presentation | `components/`, `views/`, `templates/`, `pages/` |
-| Utility | `utils/`, `helpers/`, `common/` |
-**Checklist**:
-- [ ] Read flow: Database -> Service -> API -> UI
-- [ ] Write flow: UI -> API -> Service -> Database
-- [ ] Types/schemas correctly passed between layers?
-- [ ] Errors properly propagated to caller?
-- [ ] Loading/pending states handled at each layer?
-**Detailed Guide**: `.trellis/spec/guides/cross-layer-thinking-guide.md`
----
-## Dimension B: Code Reuse (Required when modifying constants/config)
-**Trigger**:
-- Modifying UI constants (label, icon, color)
-- Modifying any hardcoded value
-- Seeing similar code in multiple places
-- Creating a new utility/helper function
-- Just finished batch modifications across files
-**Checklist**:
-- [ ] Search first: How many places define this value?
-  ```bash
-  # Search in source files (adjust extensions for your project)
-  grep -r "value-to-change" src/
-  ```
-- [ ] If the same value repeats -> does it represent one stable concept whose callers must change together? Extract only then. Two literals that merely happen to match today should stay separate
-- [ ] After modification, all usage sites updated?
-- [ ] If creating utility: Does similar utility already exist?
-**Detailed Guide**: `.trellis/spec/guides/code-reuse-thinking-guide.md`
----
-## Dimension B2: New Utility Functions
-**Trigger**: About to create a new utility/helper function
-**Checklist**:
-- [ ] Search for existing similar utilities first
-  ```bash
-  grep -r "functionNamePattern" src/
-  ```
-- [ ] If similar exists, can you extend it instead?
-- [ ] If creating new, is it in the right location (shared vs domain-specific)?
----
-## Dimension B3: After Batch Modifications
-**Trigger**: Just modified similar patterns in multiple files
-**Checklist**:
-- [ ] Did you check ALL files with similar patterns?
-  ```bash
-  grep -r "patternYouChanged" src/
-  ```
-- [ ] Any files missed that should also be updated?
-- [ ] Do the repeated sites represent one stable concept whose callers must change together? Abstract only then — not to pre-empt duplication that has not happened.
----
-## Dimension C: Import/Dependency Paths (Required when creating new files)
-**Trigger**: Creating new source files
-**Checklist**:
-- [ ] Using correct import paths (relative vs absolute)?
-- [ ] No circular dependencies?
-- [ ] Consistent with project's module organization?
----
-## Dimension D: Same-Layer Consistency
-**Trigger**:
-- Modifying display logic or formatting
-- Same domain concept used in multiple places
-**Checklist**:
-- [ ] Search for other places using same concept
-  ```bash
-  grep -r "ConceptName" src/
-  ```
-- [ ] Are these usages consistent?
-- [ ] Should they share configuration/constants?
----
-## Dimension E: Scope Discipline (Always applicable)
-**Trigger**: Every change, before reporting done
-**Checklist**:
-- [ ] 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?
-- [ ] Any workaround added at the caller instead of a fix where the behavior actually lives?
----
-## Common Issues Quick Reference
-| Issue | Root Cause | Prevention |
-|-------|------------|------------|
-| Changed one place, missed others | Didn't search impact scope | `grep` before changing |
-| Data lost at some layer | Didn't check data flow | Trace data source to destination |
-| Type/schema mismatch | Cross-layer types inconsistent | Use shared type definitions |
-| UI/output inconsistent | Same concept in multiple places | Extract shared constants |
-| Similar utility exists | Didn't search first | Search before creating |
-| Batch fix incomplete | Didn't verify all occurrences | grep after fixing |
----
-## Output
-Report:
-1. Which dimensions your changes involve
-2. Check results for each dimension
-3. Issues found and fix suggestions

package/dist/templates/copilot/prompts/check.prompt.md DELETED Viewed

@@ -1,110 +0,0 @@
----
-description: "Trellis Copilot prompt: check.prompt"
----
-# Code Quality Check
-Comprehensive quality verification for recently written code. Combines spec compliance, cross-layer safety, and pre-commit checks.
----
-## Step 1: Identify What Changed
-```bash
-git diff --name-only HEAD
-git status
-```
-## Step 2: Read Task Artifacts and Applicable Specs
-Read the current task artifacts in order:
-- `prd.md`
-- `design.md` if present
-- `implement.md` if present
-```bash
-python3 ./.trellis/scripts/get_context.py --mode packages
-```
-For each changed package/layer, read the spec index and follow its **Quality Check** section:
-```bash
-cat .trellis/spec/<package>/<layer>/index.md
-```
-Read the specific guideline files referenced — the index is a pointer, not the goal.
-## Step 3: Run Project Checks
-Run the project's lint, type-check, and test commands. Fix any failures before proceeding.
-## Step 4: Review Against Checklist
-### Code Quality
-- [ ] Linter passes?
-- [ ] Type checker passes (if applicable)?
-- [ ] Tests pass?
-- [ ] No debug logging left in?
-- [ ] No suppressed warnings or type-safety bypasses?
-### Test Coverage
-- [ ] New function → unit test added?
-- [ ] Bug fix → regression test added?
-- [ ] Changed behavior → existing tests updated?
-### Spec Sync
-- [ ] Does `.trellis/spec/` need updates? (new patterns, conventions, lessons learned)
-> "If I fixed a bug or discovered something non-obvious, should I document it so future me won't hit the same issue?" → If YES, update the relevant spec doc.
-### Scope Discipline
-- [ ] 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?
-- [ ] Any workaround added at the caller instead of a fix where the behavior actually lives?
-## Step 5: Cross-Layer Dimensions (if applicable)
-Skip this step if your change is confined to a single layer.
-### A. Data Flow (changes touch 3+ layers)
-- [ ] Read flow traces correctly: Storage → Service → API → UI
-- [ ] Write flow traces correctly: UI → API → Service → Storage
-- [ ] Types/schemas correctly passed between layers?
-- [ ] Errors properly propagated to caller?
-### B. Code Reuse (modifying constants, creating utilities)
-- [ ] Searched for existing similar code before creating new?
-  ```bash
-  grep -r "pattern" src/
-  ```
-- [ ] If the same value repeats, does it represent one stable concept whose callers must change together? Extract only then — two literals that merely happen to match today should stay separate.
-- [ ] After batch modification, all occurrences updated?
-### C. Import/Dependency (creating new files)
-- [ ] Correct import paths (relative vs absolute)?
-- [ ] No circular dependencies?
-### D. Same-Layer Consistency
-- [ ] Other places using the same concept are consistent?
----
-## Step 6: Report and Fix
-Report every violation you find. Then:
-- 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.
-If a fix would touch files outside the current task's scope, say so and stop instead of widening the change.

package/dist/templates/copilot/prompts/create-command.prompt.md DELETED Viewed

@@ -1,116 +0,0 @@
----
-description: "Trellis Copilot prompt: Create New Copilot Prompt"
----
-# Create New Copilot Prompt
-Create a new Copilot slash-command prompt file in `.github/prompts/`.
-## Usage
-```
-/create-command <command-name> <description>
-```
-Example:
-```
-/create-command review-pr Check PR code changes against project guidelines
-```
-## Execution Steps
-### 1. Parse Input
-Extract from user input:
-- Command name: must be kebab-case (example: `review-pr`)
-- Description: one-sentence purpose
-### 2. Analyze Requirements
-Classify the command intent:
-- Initialization
-- Pre-development check
-- Quality check
-- Session recording
-- Generation / automation
-### 3. Generate Prompt Content
-Create concise, executable Markdown content.
-Simple prompt shape:
-```markdown
-Single clear instruction with expected output.
-```
-Complex prompt shape:
-```markdown
-# Prompt Title
-Short purpose.
-## Steps
-### 1. Step One
-Concrete action.
-### 2. Step Two
-Concrete action.
-## Output
-Expected output format.
-```
-### 4. Create Prompt File
-Write file:
-- `.github/prompts/<command-name>.prompt.md`
-If the file already exists, compare content and update only when user asks to overwrite.
-### 5. Confirm Result
-Output:
-```
-[OK] Created Copilot Prompt: /<command-name>
-File path:
-- .github/prompts/<command-name>.prompt.md
-Usage:
-/<command-name>
-Description:
-<description>
-```
-## Content Quality Guidelines
-Good prompt traits:
-1. Clear and concise
-2. Actionable without extra interpretation
-3. Properly scoped
-4. Defines expected output when needed
-Avoid:
-1. Vague intent (example: "optimize code")
-2. Overly long instructions with mixed goals
-3. Duplicating existing prompt behavior without reason
-## Naming Conventions
-| Prompt Type | Prefix | Example |
-|------------|--------|---------|
-| Session Start | `start` | `start` |
-| Pre-development | `before-` | `before-dev` |
-| Check | `check-` | `check` |
-| Record | `record-` | `record-session` |
-| Generate | `generate-` | `generate-api-doc` |
-| Update | `update-` | `update-changelog` |
-| Other | verb-first | `review-code`, `sync-data` |

package/dist/templates/copilot/prompts/finish-work.prompt.md DELETED Viewed

@@ -1,22 +0,0 @@
----
-description: "Record progress in the Trellis developer session journal."
----
-# Finish Work
-Record progress in the developer session journal when ending this session. This prompt does not change task status, phase state, or implementation authorization. Task completion and cancellation are handled during Delivery Review and On-Site Closeout Phase through Trellis CLI.
-## Review the current session
-    python3 ./.trellis/scripts/get_context.py --mode record
-Review the current task, repository changes, and recent commits. Make the journal summary clear about completed work, remaining work, and blockers. A clean working tree or committed changes do not by themselves mean the task is complete.
-## Record the journal
-    python3 ./.trellis/scripts/add_session.py \
-      --title "Session title" \
-      --commit "hash1,hash2" \
-      --summary "Progress, remaining work, and blockers"
-Pass only commit hashes that belong to this session. Omit --commit when no relevant commit exists. Leave task state to Trellis CLI and formal session handoff to its separate, explicitly requested workflow.