@uoyo/mvtt 2.0.0 → 2.2.0

package/sources/templates/test-output/body.md

@@ -1,7 +1,79 @@
 # Test Design: {Feature Name}
 
+<!--
+  This template defines the structure of test-design.md.
+  Each section below includes a guidance comment explaining what to write.
+  Replace {Feature Name} with the actual feature/change name.
+  Remove these HTML comments in the final artifact.
+-->
+
+## Scope
+<!--
+  The target files under test and any fallbacks applied (e.g., resolved
+  from implementation.md Files Touched, or git diff, or user argument).
+  Establishes what this test design covers.
+-->
+
+## Test Framework & Layout
+<!--
+  The chosen test framework (inferred from project manifests or confirmed
+  with user) and the file layout convention used (mirror under tests/,
+  sibling *.test.ts, etc.). One short paragraph or a small table.
+-->
+
+## Test Scenarios
+<!--
+  The Scenario Table from the scenario-identification step. Columns:
+  | ID | Scenario | Type (happy/edge/negative/security/performance) | Rule-traced-to |.
+  Covers happy paths, boundaries, invalid inputs, business rules from
+  project-context.md, and error paths declared in design.md data flow.
+-->
+
 ## Test Cases
+<!--
+  The row-level test case table from the design step. Columns:
+  | ID | Scenario | Granularity | Preconditions | Inputs | Actions | Expected | Rule-traced-to |.
+  Each row maps to one concrete, runnable test. One scenario maps to one
+  granularity (unit / integration / E2E).
+-->
 
 ## Test Code
+<!--
+  The generated test files: file paths and a brief description of what
+  each file covers. The actual test source goes into the project tree;
+  this section is a record of what was written and where. Include any
+  setup/fixture notes that explain non-obvious test infrastructure.
+-->
+
+## Granularity Decisions
+<!--
+  Summary of how scenarios were assigned to unit / integration / E2E,
+  including any "needs setup" gaps (e.g., integration scenarios flagged
+  because the project lacks an integration test setup). One short
+  paragraph or a small table.
+-->
 
 ## Coverage Analysis
+<!--
+  Only when the --coverage flag is set; otherwise omit this heading
+  entirely. Map test cases back to target files/functions and business
+  rules from project-context.md; list gaps (untested functions, untested
+  rules, untested error paths) and recommend additional test cases for
+  each gap. Do not auto-generate gap tests unless the user confirms.
+-->
+
+## Implementation Issues Found
+<!--
+  Bugs discovered during scenario design or test writing (failing test
+  reveals a real bug, not a test bug). Each finding: scenario id, expected
+  vs observed, severity (Critical / Warning), and a recommendation to run
+  /mvt-fix. Do NOT modify production code from this skill. If none found,
+  write "None".
+-->
+
+## Suggested Run Commands
+<!--
+  One or two commands the user can copy-paste to execute the generated
+  tests (e.g., `npx vitest run path/to/test.test.ts`). Keep it minimal
+  and project-appropriate.
+-->

package/sources/sections/activation-load-config.md

@@ -1,11 +0,0 @@
-### Step 4: Load Config & Apply Preferences (Config Foundation)
-Read `.ai-agents/config.yaml` and enforce the following throughout this entire session:
-
-**Language**:
-- `preferences.interaction_language` → Language for everything spoken to the user (chat, prompts, tables); NOT for files written to disk. See the **Language Constraint** section below for the full, non-negotiable rules.
-- `preferences.document_output_language` → Language for files written to disk. See the **Language Constraint** section below for the full rules.
-
-**Other preferences**:
-- `preferences.output.no_emojis` → If true, never use emojis
-- `preferences.output.data_format` → Use this format for data sections in artifacts
-- `preferences.context_routing.relevance_threshold` → Used by `/mvt-manage-context add` for AI routing (default 70 if missing)

package/sources/sections/activation-load-context.md

@@ -1,59 +0,0 @@
-## Activation Protocol
-
-### Step 1: Load Context
-Load these files as foundational context:
-- `.ai-agents/workspace/project-context.yaml` -- Project index (structural info)
-- `.ai-agents/registry.yaml` -- Available skills registry and knowledge declarations
-{{?extended_context}}
-
-Extended context for this skill:
-{{/extended_context}}
-{{#extended_context}}
-- {{.}}
-{{/extended_context}}
-
-### Step 2: Resolve Project Scope (PS)
-
-Read `project-context.yaml > projects[]`.
-
-**Single project** (`projects.length == 1`): Set PS = [sole project name]. Skip remaining PS steps.
-
-**Multi-project** (`projects.length > 1`):
-**Mode A -- Plan-driven** (active plan exists and skill operates on plan tasks):
-1. **Plan signal**: PS = current task's `project` array from plan's `current_tasks`. Drop stale project names (not in `projects[]`), fall through.
-2. **Path match**: Match current working paths against `projects[].path` and `source_paths`.
-3. **Prompt**: If still unresolved, list candidates and ask user. Never silently load all projects.
-
-**Mode B -- Non-plan** (no active plan or ad-hoc changes):
-Defer PS to execution: identify change target, match against `projects[].path` and `source_paths`, load project-specific knowledge on demand (Step 3).
-
-### Step 3: Load Knowledge
-
-Registry uses project-keyed maps; `_all` is a reserved key (all projects). Applies to both top-level `knowledge` and `skills.<name>.knowledge`.
-
-**Knowledge Loading Protocol**:
-For each knowledge entry in the registry, follow these steps:
-1. **Read the `source` field** from the registry entry (e.g., `knowledge/project/_generated/`).
-2. **Construct the base directory**: join `.ai-agents/` with the `source` value → `.ai-agents/{source_value}/`.
-3. **Load files**:
-   - `files: [a.md, b.md]` → load `.ai-agents/{source_value}/a.md`, `.ai-agents/{source_value}/b.md`.
-   - `files_from_manifest: true` → read `.ai-agents/{source_value}/manifest.yaml`, load entries with `auto_load: true`.
-4. **Skip non-existent paths** silently (do not error or warn).
-
-**Worked example**:
-Given this registry entry:
-```yaml
-- id: project-context
-  source: knowledge/project/_generated/
-  files:
-    - project-context.md
-```
-Resolution: `.ai-agents/` + `knowledge/project/_generated/` + `project-context.md` = `.ai-agents/knowledge/project/_generated/project-context.md`
-
-**Anti-pattern -- DO NOT**:
-- Guess or hardcode base directories (e.g., `.ai-agents/workspace/`).
-- Assume a default path structure. The `source` field value is the authoritative path component.
-
-**At activation** (both modes): load `knowledge._all` + `skills.<current-skill>.knowledge._all`.
-**Mode A** (additionally): for each P in PS, load `knowledge[P]` + `skills.<current-skill>.knowledge[P]`.
-**Mode B** (during execution): on demand, load `knowledge[P]` + `skills.<current-skill>.knowledge[P]` for identified project(s).

package/sources/sections/activation-preflight.md

@@ -1,14 +0,0 @@
-### Step 5: Pre-flight Checks
-
-For each check below, if the condition holds, perform the action implied by its **Level**:
-
-- **WARN** -- emit the message, then ask "Continue anyway? (y/n)". Default to **y** if the user does not respond.
-- **BLOCK** -- emit the message and stop. Do not proceed until the prerequisite is satisfied.
-- **REQUIRED** -- same as BLOCK; the prerequisite is mandatory.
-- **INFO** -- emit the message and proceed; no confirmation needed.
-
-| # | Condition | Level | Message |
-|---|-----------|-------|---------|
-{{#checks}}
-| {{order}} | `{{field}}` is empty | {{level}} | {{message}} |
-{{/checks}}