@uoyo/mvtt 2.0.0-beta.1 → 2.0.0-beta.3

package/sources/skills/mvt-template/manifest.yaml

@@ -1,63 +1,68 @@
-name: mvt-template
-output: .claude/skills/mvt-template/SKILL.md
-
-frontmatter:
-  name: mvt-template
-  description: "View, customize, and manage output templates for MVTT skills. This skill should be used when user wants to inspect available templates, create custom template versions, reset customizations, or export templates."
-
-sections:
-  - type: inline
-    content: |
-      # MVT Custom Template
-
-      ## Purpose
-
-      View, customize, and manage MVTT output templates. Inspect default templates, create custom versions that override defaults, reset customizations, and export templates.
-
-  - type: shared
-    source: sections/role-header.md
-    params:
-      role: Conductor
-      role_desc: "a Workflow Coordinator"
-      decision_rules:
-        - rule: "No arguments -> Show template list with status"
-        - rule: "User selects \"view\" -> Display full template content (custom version if exists)"
-        - rule: "User selects \"customize\" -> Guide through modification process"
-        - rule: "User selects \"reset\" -> Delete custom version, restore default"
-        - rule: "User selects \"export\" -> Output template to specified location"
-        - rule: "Custom template must preserve frontmatter format"
-      boundaries:
-        - scope: "modify default templates in `_templates/` root"
-          skill: "(Only create/modify in `custom/`)"
-        - scope: "modify skill logic"
-          skill: "(Only change output formatting)"
-
-  - type: shared
-    source: sections/activation-load-context.md
-    params:
-      extended_context:
-        - "Scan `.ai-agents/skills/_templates/custom/` for existing customizations"
-
-  - type: shared
-    source: sections/activation-load-config.md
-
-  - type: shared
-    source: sections/output-language-constraint.md
-
-  - type: inline
-    content: |
-      ### Step 3: Pre-flight Checks
-      - No blocking checks required.
-
-  - type: file
-    source: ./business.md
-
-  - type: shared
-    source: sections/session-update.md
-    params:
-      read_only: true
-
-  - type: shared
-    source: sections/footer-next-steps.md
-    params:
-      current_skill: mvt-template
+name: mvt-template
+output: .claude/skills/mvt-template/SKILL.md
+
+frontmatter:
+  name: mvt-template
+  description: "View, customize, and manage output templates for MVTT skills. This skill should be used when user wants to inspect available templates, create custom template versions, reset customizations, or export templates."
+
+sections:
+  - type: inline
+    content: |
+      # MVT Custom Template
+
+      ## Purpose
+
+      View, customize, and manage MVTT output templates. Inspect default templates, create custom versions that override defaults, reset customizations, and export templates.
+
+  - type: shared
+    source: sections/role-header.md
+    params:
+      role: Conductor
+      role_desc: "a Workflow Coordinator"
+      decision_rules:
+        - rule: "No arguments -> Show template list with status"
+        - rule: "User selects \"view\" -> Display full template content (custom version if exists)"
+        - rule: "User selects \"customize\" -> Guide through modification process"
+        - rule: "User selects \"reset\" -> Delete custom version, restore default"
+        - rule: "User selects \"export\" -> Output template to specified location"
+        - rule: "Custom template must preserve frontmatter format"
+      boundaries:
+        - scope: "modify default templates in `_templates/` root (only create/modify in `custom/`)"
+          skill: "(constraint)"
+        - scope: "modify skill logic (only change output formatting)"
+          skill: "(constraint)"
+
+  - type: shared
+    source: sections/activation-load-context.md
+    params:
+      extended_context:
+        - "Scan `.ai-agents/skills/_templates/custom/` for existing customizations"
+
+  - type: shared
+    source: sections/activation-load-config.md
+
+  - type: inline
+    content: |
+      ### Step 4: Pre-flight Checks
+      - No blocking checks required.
+
+  - type: file
+    source: ./business.md
+
+  - type: shared
+    source: sections/session-update.md
+    params:
+      read_only: true
+
+  - type: shared
+    source: sections/footer-next-steps.md
+    params:
+      current_skill: mvt-template
+      conditional_suggestions:
+        conditions:
+          - condition: "template customized"
+            primary: mvt-status
+            primary_desc: "Check project status"
+          - condition: "template reset to default"
+            primary: mvt-help
+            primary_desc: "Review available skills and templates"

package/sources/skills/mvt-test/business.md

@@ -76,8 +76,7 @@
 - Record each finding with: scenario id, expected vs observed, severity (Critical / Warning), and recommend `/mvt-fix`.
 
 ### Step 9: Write Artifact
-- **Path**: `.ai-agents/workspace/artifacts/{active_change.id}/tests/test-design.md`.
-- **Template**: `.ai-agents/skills/_templates/test-output.md` (custom override at `_templates/custom/...` takes precedence).
+- **Path and template**: as defined in the **Artifact Structure** section below.
 - **Required content** (mapped to template headings):
   - `Scope` -- target files, fallbacks applied.
   - `Test Framework & Layout` -- chosen framework, file layout convention.
@@ -89,7 +88,8 @@
   - `Suggested Run Commands` -- one or two commands the user can copy-paste.
 - The actual test files go to the project tree; the artifact is a record.
 
-### Step 10: (session update handled by shared section)
+### Step 10: State Update
+Apply the State Update rules defined in the **State Update** section below.
 
 ## Edge Cases & Errors
 

package/sources/skills/mvt-test/manifest.yaml

@@ -1,102 +1,115 @@
-name: mvt-test
-output: .claude/skills/mvt-test/SKILL.md
-
-frontmatter:
-  name: mvt-test
-  description: "Generate and design tests to validate implementations. This skill should be used when user wants to write tests, validate code, generate test cases, or analyze test coverage."
-
-sections:
-  - type: inline
-    content: |
-      # MVT Test
-
-      ## Purpose
-
-      Design and write tests to validate implementations against requirements and business rules. Ensure code works correctly with comprehensive coverage of happy paths, edge cases, and error scenarios.
-
-  - type: shared
-    source: sections/role-header.md
-    params:
-      role: Tester
-      role_desc: "a Quality Assurance Specialist"
-      decision_rules:
-        - rule: "Happy path works -> Add edge case and boundary tests"
-        - rule: "Bug found during testing -> Document with reproduction steps, suggest `/mvt-fix`"
-        - rule: "Coverage gap found -> Add tests focused on that area"
-        - rule: "Flaky test detected -> Flag for investigation"
-        - rule: "Test requires external service -> Use mocks/stubs, document the dependency"
-        - rule: "Security constraints in requirements -> Add security-focused test cases"
-        - rule: "Existing tests conflict with new implementation -> Flag the conflict"
-      boundaries:
-        - scope: "modify the code being tested"
-          skill: "/mvt-fix"
-        - scope: "make architecture decisions"
-          skill: "(Test against existing design)"
-        - scope: "skip edge cases or negative tests"
-          skill: "(Never)"
-
-  - type: inline
-    content: |
-      ## Variants
-
-      | Variant | Description |
-      |---------|-------------|
-      | `/mvt-test` | Generate tests for recent implementation |
-      | `/mvt-test {feature}` | Generate tests for specific feature |
-      | `/mvt-test --coverage` | Generate tests with coverage analysis |
-
-  - type: shared
-    source: sections/activation-load-context.md
-    params:
-      extended_context:
-        - "Implementation files to be tested"
-
-  - type: shared
-    source: sections/activation-load-config.md
-
-  - type: shared
-    source: sections/output-language-constraint.md
-
-  - type: shared
-    source: sections/activation-preflight.md
-    params:
-      checks:
-        - order: "1"
-          field: "session.initialized_at"
-          level: "WARN"
-          message: "Session not initialized. Run `/mvt-init` first."
-        - order: "2"
-          field: "no implementation files"
-          level: "WARN"
-          message: "No implementation found. Run `/mvt-implement` first."
-
-  - type: inline
-    content: |
-      ## Test Case Types
-
-      | Type | Description | Priority |
-      |------|-------------|----------|
-      | Happy Path | Normal successful flow | High |
-      | Edge Case | Boundary conditions | High |
-      | Negative | Invalid inputs, errors | High |
-      | Security | Authentication, injection | Medium |
-      | Performance | Load, stress | Low |
-
-  - type: file
-    source: ./business.md
-
-  - type: inline
-    content: |
-      ## Artifact Structure
-      Read the document structure template from: `.ai-agents/skills/_templates/test-output.md`
-      If a custom version exists at `.ai-agents/skills/_templates/custom/test-output.md`, use the custom version instead.
-      The template defines section headings only. Generate content for each section based on test design results.
-      Write the artifact to: `.ai-agents/workspace/artifacts/{change-id}/tests/test-design.md`
-
-  - type: shared
-    source: sections/session-update.md
-
-  - type: shared
-    source: sections/footer-next-steps.md
-    params:
-      current_skill: mvt-test
+name: mvt-test
+output: .claude/skills/mvt-test/SKILL.md
+
+frontmatter:
+  name: mvt-test
+  description: "Generate and design tests to validate implementations. This skill should be used when user wants to write tests, validate code, generate test cases, or analyze test coverage."
+
+sections:
+  - type: inline
+    content: |
+      # MVT Test
+
+      ## Purpose
+
+      Design and write tests to validate implementations against requirements and business rules. Ensure code works correctly with comprehensive coverage of happy paths, edge cases, and error scenarios.
+
+  - type: shared
+    source: sections/role-header.md
+    params:
+      role: Tester
+      role_desc: "a Quality Assurance Specialist"
+      decision_rules:
+        - rule: "Happy path works -> Add edge case and boundary tests"
+        - rule: "Bug found during testing -> Document with reproduction steps, suggest `/mvt-fix`"
+        - rule: "Coverage gap found -> Add tests focused on that area"
+        - rule: "Flaky test detected -> Flag for investigation"
+        - rule: "Test requires external service -> Use mocks/stubs, document the dependency"
+        - rule: "Security constraints in requirements -> Add security-focused test cases"
+        - rule: "Existing tests conflict with new implementation -> Flag the conflict"
+      boundaries:
+        - scope: "modify the code being tested"
+          skill: "/mvt-fix"
+        - scope: "make architecture decisions"
+          skill: "(Test against existing design)"
+        - scope: "skip edge cases or negative tests"
+          skill: "(Never)"
+
+  - type: inline
+    content: |
+      ## Variants
+
+      | Variant | Description |
+      |---------|-------------|
+      | `/mvt-test` | Generate tests for recent implementation |
+      | `/mvt-test {feature}` | Generate tests for specific feature |
+      | `/mvt-test --coverage` | Generate tests with coverage analysis |
+
+  - type: shared
+    source: sections/activation-load-context.md
+    params:
+      extended_context:
+        - "Implementation files to be tested"
+
+  - type: shared
+    source: sections/activation-load-config.md
+
+  - type: shared
+    source: sections/output-language-constraint.md
+
+  - type: shared
+    source: sections/activation-preflight.md
+    params:
+      checks:
+        - order: "1"
+          field: "session.initialized_at"
+          level: "WARN"
+          message: "Session not initialized. Run `/mvt-init` first."
+        - order: "2"
+          field: "implementation files (user args, implementation.md, or source tree)"
+          level: "WARN"
+          message: "No implementation found. Run `/mvt-implement` first."
+
+  - type: inline
+    content: |
+      ## Test Case Types
+
+      | Type | Description | Priority |
+      |------|-------------|----------|
+      | Happy Path | Normal successful flow | High |
+      | Edge Case | Boundary conditions | High |
+      | Negative | Invalid inputs, errors | High |
+      | Security | Authentication, injection | Medium |
+      | Performance | Load, stress | Low |
+
+  - type: file
+    source: ./business.md
+
+  - type: inline
+    content: |
+      ## Artifact Structure
+      Read the document structure template from: `.ai-agents/skills/_templates/test-output.md`
+      If a custom version exists at `.ai-agents/skills/_templates/custom/test-output.md`, use the custom version instead.
+      The template defines section headings only. Generate content for each section based on test design results.
+      Write the artifact to: `.ai-agents/workspace/artifacts/{change-id}/tests/test-design.md`
+
+  - type: shared
+    source: sections/session-update.md
+    params:
+      current_skill: mvt-test
+
+  - type: shared
+    source: sections/footer-next-steps.md
+    params:
+      current_skill: mvt-test
+      conditional_suggestions:
+        conditions:
+          - condition: "tests pass, implementation verified"
+            primary: mvt-review
+            primary_desc: "Final code review before merge"
+          - condition: "tests reveal bugs"
+            primary: mvt-fix
+            primary_desc: "Fix the issues found during testing"
+          - condition: "plan exists with remaining tasks"
+            primary: mvt-update-plan
+            primary_desc: "Mark current task done and advance to next"

package/sources/skills/mvt-update-plan/business.md

@@ -1,72 +1,83 @@
-## Execution Flow
-
-### Step 1: Resolve Target
-
-Required inputs:
-
-- **task_id** -- which task to update
-- **new_status** -- one of: `pending`, `in_progress`, `done`, `blocked`, `skipped`
-- **artifacts** (optional, comma-separated paths) -- files produced or touched
-- **notes** (optional) -- free-form note string
-
-Resolution rules:
-
-- If `task_id` is omitted AND exactly one task currently has status `in_progress` -> default to that task.
-- If `task_id` is omitted AND zero or multiple tasks are in_progress -> ask the user to specify.
-- If the user reply is the natural-language form `done` / `blocked: <reason>` (from a workflow skill's soft-prompt) -> map to:
-  - `done` -> task = plan.current_task, new_status = done
-  - `blocked: <reason>` -> task = plan.current_task, new_status = blocked, notes = `<reason>`
-
-### Step 2: Load and Validate Existing Plan
-
-1. Read `active_change.plan_path` (the file location is fixed by `/mvt-plan-dev`).
-2. Parse YAML; if parse fails or schema is invalid -> stop and report. Do not attempt to repair silently.
-3. Verify the target `task_id` exists in `tasks[]`. If not, list valid ids and stop.
-
-### Step 3: Apply the Update
-
-Mutate the in-memory plan:
-
-1. Find the target task; capture `old_status` for the report.
-2. Set `tasks[i].status = new_status`.
-3. If `artifacts` provided -> append to `tasks[i].artifacts` (de-duplicate).
-4. If `notes` provided -> overwrite `tasks[i].notes`.
-5. Update `plan.updated_at` to current ISO 8601 timestamp.
-
-### Step 4: Recompute current_task
-
-Selection logic, in order:
-
-1. If any task has status `in_progress` AND it is **not** the task we just changed to a terminal status (done/blocked/skipped) -> `current_task` = that task's id.
-2. Otherwise pick the first task (by array order) where:
-   - `status == pending`
-   - All ids in `depends_on` reference tasks with status `done`
-3. If no such task exists AND every task is `done` -> set `plan.status = done`, `current_task = null`.
-4. If no such task exists but some tasks are still `pending` (because their dependencies are not done -- e.g., everything reachable is blocked) -> set `current_task = null`, leave `plan.status = in_progress`. Surface a warning in the output ("All remaining tasks are blocked by dependencies; resolve a blocker before continuing").
-
-If the selected next task is currently `pending` -> promote it to `in_progress` (so the plan accurately reflects the active focus). Skip this promotion if `plan.status` just transitioned to `done`.
-
-### Step 5: Validate and Write
-
-1. Run the plan validator on the mutated structure.
-2. If validation fails -> abort the write, report the validation errors, leave the original file untouched.
-3. Otherwise, write back to `active_change.plan_path`.
-
-### Step 6: Update Session State
-
-Apply the standard State Update rules (see shared section above) AND the update-plan-specific updates:
-
-- Refresh the matching entry in `recent_changes[]`: `last_updated` -> current ISO 8601 timestamp.
-- Do NOT touch `active_change.has_plan` / `active_change.plan_path`.
-
-### Step 7: Output
-
-Emit the Plan Update summary block defined in the Output Format section. Include:
-
-- The task that changed (id, title, old -> new status).
-- A compact table of all tasks with their current status.
-- The new `current_task` (or "(plan complete)" if `plan.status == done`).
-- A one-line "Next" hint:
-  - If a new `current_task` is set -> recommend the skill matching its `skill_hint`.
-  - If plan complete -> recommend `/mvt-cleanup` or starting a new change via `/mvt-analyze`.
-  - If all remaining tasks are blocked -> recommend resolving the blocker (point at the `notes` of the blocked task).
+## Execution Flow
+
+### Step 1: Resolve Target
+
+Required inputs:
+
+- **task_id** -- which task to update
+- **new_status** -- one of: `pending`, `in_progress`, `done`, `blocked`, `skipped`
+- **artifacts** (optional, comma-separated paths) -- files produced or touched
+- **notes** (optional) -- free-form note string
+
+Resolution rules:
+
+- If `task_id` is omitted AND exactly one task currently has status `in_progress` -> default to that task.
+- If `task_id` is omitted AND zero or multiple tasks are in_progress -> ask the user to specify.
+- If the user reply is the natural-language form `done` / `blocked: <reason>` (from a workflow skill's soft-prompt) -> map to:
+  - `done` -> task = plan.current_task, new_status = done
+  - `blocked: <reason>` -> task = plan.current_task, new_status = blocked, notes = `<reason>`
+
+### Step 2: Load and Validate Existing Plan
+
+1. Read `active_change.plan_path` (the file location is fixed by `/mvt-plan-dev`).
+2. Parse YAML; if parse fails or schema is invalid -> stop and report. Do not attempt to repair silently.
+3. Verify the target `task_id` exists in `tasks[]`. If not, list valid ids and stop.
+
+### Step 3: Apply the Update
+
+Mutate the in-memory plan:
+
+1. Find the target task; capture `old_status` for the report.
+2. Set `tasks[i].status = new_status`.
+3. If `artifacts` provided -> append to `tasks[i].artifacts` (de-duplicate).
+4. If `notes` provided -> overwrite `tasks[i].notes`.
+5. Update `plan.updated_at` to current ISO 8601 timestamp.
+
+### Step 4: Recompute current_task
+
+Selection logic, in order:
+
+1. If any task has status `in_progress` AND it is **not** the task we just changed to a terminal status (done/blocked/skipped) -> `current_task` = that task's id.
+2. Otherwise pick the first task (by array order) where:
+   - `status == pending`
+   - All ids in `depends_on` reference tasks with status `done`
+3. If no such task exists AND every task is `done` -> set `plan.status = done`, `current_task = null`.
+4. If no such task exists but some tasks are still `pending` (because their dependencies are not done -- e.g., everything reachable is blocked) -> set `current_task = null`, leave `plan.status = in_progress`. Surface a warning in the output ("All remaining tasks are blocked by dependencies; resolve a blocker before continuing").
+
+If the selected next task is currently `pending` -> promote it to `in_progress` (so the plan accurately reflects the active focus). Skip this promotion if `plan.status` just transitioned to `done`.
+
+### Step 5: Validate and Write
+
+1. Run the plan validator on the mutated structure.
+2. If validation fails -> abort the write, report the validation errors, leave the original file untouched.
+3. Otherwise, write back to `active_change.plan_path`.
+
+### Step 6: Update Session State
+
+Apply the State Update rules defined in the **State Update** section below, AND the update-plan-specific updates:
+
+- Refresh the matching entry in `changes[]`: `updated_at` -> current ISO 8601 timestamp.
+- Do NOT touch `active_change.plan_path`.
+
+### Step 7: Output
+
+Emit the Plan Update summary block defined in the Output Format section. Include:
+
+- The task that changed (id, title, old -> new status).
+- A compact table of all tasks with their current status.
+- The new `current_task` (or "(plan complete)" if `plan.status == done`).
+- A one-line "Next" hint:
+  - If a new `current_task` is set -> recommend the skill matching its `skill_hint`.
+  - If plan complete -> recommend `/mvt-cleanup` or starting a new change via `/mvt-analyze`.
+  - If all remaining tasks are blocked -> recommend resolving the blocker (point at the `notes` of the blocked task).
+
+## Edge Cases & Errors
+
+| Case | Handling |
+|------|----------|
+| `plan.yaml` not found at `active_change.plan_path` | Abort with error: "No plan found. Run `/mvt-plan-dev` to create one." |
+| Task id provided does not exist in `plan.yaml` | Abort with error listing valid task ids |
+| Transition to `done` but `depends_on` tasks are not all `done` | Warn but allow: "Task marked done despite unfinished dependencies — verify correctness" |
+| All tasks are `done` but user marks another as `in_progress` | Reject: plan is already complete; suggest creating a new change |
+| Circular dependency detected in `depends_on` | Report the cycle and refuse to auto-advance `current_task`; suggest manual fix |
+| `plan.yaml` write fails (permission denied, invalid YAML state) | Abort; do not update session; report the write error |