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

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

@@ -16,12 +16,27 @@
   3. State the current behavior in plain language; include any non-obvious side effects or invariants you can see in the code.
 - **Output of this step**: a target table (`file | range | role`) and a "current behavior" paragraph; both are shown to user before continuing.
 
-### Step 3: Classify Refactoring Type
+### Step 3: Identify Project Scope and Load Project-Specific Knowledge
+
+This step applies only when the workspace has multiple projects (`projects.length > 1` in `project-context.yaml`). In single-project workspaces, all relevant knowledge was loaded at activation; skip this step entirely.
+
+- **Project identification**: match the file paths resolved in Step 2 against `projects[].path` and `projects[].source_paths`:
+  - A file whose path starts with a project's `path` prefix belongs to that project.
+  - A file under a project's `source_paths` entry also belongs to that project.
+  - Collect the set of unique project names from all matched files. This is the **active project scope** for this invocation.
+- **On-demand knowledge loading**: for each project P in the active project scope, read `.ai-agents/registry.yaml` and load:
+  1. Every entry under `knowledge.{P}` -- load each entry's referenced files (resolve relative to `.ai-agents/{source}`).
+  2. Every entry under `skills.mvt-refactor.knowledge.{P}` -- load each entry's referenced files.
+  3. Skip any key absent from the registry (no project-specific knowledge is valid; do not warn).
+- **Multi-project scenario**: if files span multiple projects, load each project's knowledge sequentially. The skill operates with the union of all loaded project-specific knowledge plus the `_all` knowledge already loaded at activation.
+- **Unmatched files**: if a file path does not match any project's `path` or `source_paths`, surface a note and treat it as belonging to the first project in `projects[]` (fallback). This may indicate a configuration gap in `project-context.yaml`.
+
+### Step 4: Classify Refactoring Type
 - **What**: pick the smallest type that covers the requested change. Use the Refactoring Types table above for risk levels.
 - **How**: assign one primary type per refactoring task. Multiple types in one run are allowed but each must be tracked separately in the artifact.
 - If the request requires `Change Interface/API` AND the symbol is exported beyond the project (public API, library entry point, IPC boundary): STOP -- this is no longer a refactoring task; recommend `/mvt-design`.
 
-### Step 4: Risk Assessment
+### Step 5: Risk Assessment
 - **What**: assign a final risk score and decide whether explicit confirmation is needed.
 - **How**: combine refactoring type and impact factors.
 
@@ -34,11 +49,11 @@
   | User has uncommitted changes overlapping the target | +1 |
 
 - Final risk = type's base level + factors:
-  - Low + 0..1 -> proceed silently in Step 7.
-  - Medium OR Low + 2 -> require explicit confirmation in Step 6.
-  - High OR (Medium + 2) -> require explicit confirmation AND a behavior-preservation strategy from Step 5.
+  - Low + 0..1 -> proceed silently in Step 8.
+  - Medium OR Low + 2 -> require explicit confirmation in Step 7.
+  - High OR (Medium + 2) -> require explicit confirmation AND a behavior-preservation strategy from Step 6.
 
-### Step 5: Choose Behavior-Preservation Strategy
+### Step 6: Choose Behavior-Preservation Strategy
 - **What**: pick a verification path BEFORE editing.
 - **How**: choose the row that matches your test reality.
 
@@ -50,34 +65,34 @@
 
 - Document the chosen strategy in the artifact regardless of risk level.
 
-### Step 6: Confirm with User (when required)
-- **Trigger**: per the Step 4 thresholds, or any High-risk type.
+### Step 7: Confirm with User (when required)
+- **Trigger**: per the Step 5 thresholds, or any High-risk type.
 - **Format**: present a single screen with:
   - Target summary (Step 2's table, condensed to file count + symbol).
   - Refactoring type and risk level.
   - Number of callers and a list of the top 5 affected files.
-  - Behavior-preservation strategy (Step 5).
+  - Behavior-preservation strategy (Step 6).
   - One yes/no prompt: `Proceed with this refactor? (y / n / show-plan)`.
 
-### Step 7: Plan and Execute Incrementally
+### Step 8: Plan and Execute Incrementally
 - **What**: apply the change in the smallest reversible steps.
 - **How**:
   1. Break the refactor into ordered sub-steps (e.g., Rename: 1) update declaration, 2) update callers, 3) update tests, 4) update docs).
   2. After each sub-step:
      - Compile / type-check the affected files.
-     - If a test command was identified in Step 5, run it (or surface it for user to run if running tests is not allowed in this environment).
+     - If a test command was identified in Step 6, run it (or surface it for user to run if running tests is not allowed in this environment).
      - On failure: revert the sub-step, surface the cause, do NOT continue.
   3. Do not interleave behavior changes (bug fixes, feature toggles) with the refactor. If you spot one, note it for follow-up; do not silently include it.
   4. Do not modify code outside the planned target unless required for compilation/type correctness; record any such "incidental" edits.
 
-### Step 8: Verify Behavior Preservation
+### Step 9: Verify Behavior Preservation
 - **What**: prove (within the chosen strategy) that observable behavior is unchanged.
 - **How**:
   - With tests: all pre-existing tests pass; new characterization tests pass; assert pass count is unchanged or increased.
   - Without tests: list the call sites you visually verified, plus the manual behavior checks you recommend the user run.
-- If anything regresses: revert the most recent sub-step, surface the regression, return to Step 7. Do not declare success.
+- If anything regresses: revert the most recent sub-step, surface the regression, return to Step 8. Do not declare success.
 
-### Step 9: Write Refactor Notes
+### Step 10: Write Refactor Notes
 - **Path**: `.ai-agents/workspace/artifacts/{change-id}/refactor-notes.md` if `active_change` exists; otherwise inline summary in conversation only (shortcut mode).
 - **Required content**:
   - `Target` -- file/symbol list, current-behavior paragraph.
@@ -88,7 +103,7 @@
   - `Verification Result` -- tests run, pass/fail counts; or manual checks recommended.
   - `Follow-ups` -- deferred behavior changes spotted during refactoring.
 
-### Step 10: State Update
+### Step 11: State Update
 Apply the State Update rules defined in the **State Update** section below.
 
 ## Edge Cases & Errors
@@ -98,8 +113,8 @@ Apply the State Update rules defined in the **State Update** section below.
 | Target spans multiple repos / submodules | STOP -- out of scope; recommend a coordinated change rather than a single refactor |
 | Refactor uncovers a real bug | Pause refactor, document the bug, recommend `/mvt-fix` -- do NOT fix during the refactor |
 | Refactor target is dead code | Confirm with user before deleting; offer alternative of marking deprecated first |
-| Symbol is referenced via reflection / dynamic dispatch / string lookup | Increase risk by +2; require strategy 5(a) (characterization test) before proceeding |
+| Symbol is referenced via reflection / dynamic dispatch / string lookup | Increase risk by +2; require strategy 6(a) (characterization test) before proceeding |
 | User has uncommitted changes overlapping the target | Show diff, recommend committing/stashing first, ask for explicit confirmation if user wants to proceed anyway |
 | Type/test failures persist after revert | Surface a clear summary; suggest user re-run the original test baseline to detect a pre-existing failure unrelated to the refactor |
-| User aborts at Step 6 | Do not modify any file; report "no changes" |
+| User aborts at Step 7 | Do not modify any file; report "no changes" |
 | Active change is mid-implementation (not yet `done`) | Warn that refactoring during implementation can confuse review/test phases; require explicit confirmation |

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

@@ -65,10 +65,8 @@ sections:
   - type: shared
     source: sections/output-language-constraint.md
 
-  - type: inline
-    content: |
-      ### Step 4: Pre-flight Checks
-      - No blocking checks required (shortcut operation).
+  - type: shared
+    source: sections/output-format-constraint.md
 
   - type: inline
     content: |

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

@@ -2,12 +2,23 @@
 
 ### Step 1: Read Session State
 
-Extract from the already-loaded session context:
-- `active_change` -- the current change-id (if any), plan_path
+Read `.ai-agents/workspace/session.yaml`. If the file is missing or empty, jump to Step 8 with the "no session" branch.
+
+Extract:
+- `active_change` -- the current change-id (if any), plan_path, epic_id
+- `active_epic` -- the current epic (if any): id, title, epic_path
 - `changes` -- list of changes with active plans
 - `history` -- last 20 entries (skill name, timestamp, change_id)
 
-If session.yaml is missing or empty, jump to Step 8 with the "no session" branch.
+### Step 1a: Check Epic State
+
+After extracting session data in Step 1, check for epic state:
+
+| Condition | Action |
+|-----------|--------|
+| `active_change.id` non-empty AND `active_change.epic_id` non-empty | Set `within_epic = true`. Continue to Step 2 (normal plan-based resume). In Step 7, include an Epic Context section. |
+| `active_change.id` empty AND `active_epic.id` non-empty (epic-pending) | Read `epic.yaml` via `active_epic.epic_path`. If unreadable, warn and jump to Step 8 with the "epic-pending but epic.yaml missing" edge case. Otherwise, identify the child referenced by `epic.yaml.current_change` as the resume target. Skip Steps 2-6 and go directly to Step 7 with a simplified report containing: (1) **Epic State** -- epic title, id, status, progress (done/total); (2) **Current Sub-change** -- title, scope, depends_on status of each dependency; (3) **Resume Point** -- "Resuming epic: {title}. Next sub-change: {current_change_title}. Run `/mvt-analyze` to start."; (4) **Recommended Next Step** -- `/mvt-analyze` -- Start the next sub-change in the epic. |
+| Neither | Continue to Step 2 (normal flow). |
 
 ### Step 2: Discover Pending Plans
 
@@ -56,18 +67,23 @@ For each artifact, capture: file path, mtime, size (in tokens estimate = chars /
 
 ### Step 5: Determine Resume Point
 
-Read the plan's `current_task`. The resume point = that task. Next-step recommendation = the task's `skill_hint` (or infer from task title if skill_hint is absent).
+Read the plan's `current_tasks` map. The resume point = the task(s) referenced by `current_tasks`. Next-step recommendation = the relevant task's `skill_hint` (or infer from task title if skill_hint is absent).
+
+For multi-project workspaces, if `current_tasks` has entries for multiple projects, display each project's current task separately.
 
 Also filter `history` to entries matching `change_id == selected_change_id` (entries with empty change_id are excluded from this filtered view).
 
+If the plan-update script output from a previous session included a `project_switch` notification, surface it: "Last session crossed from {from} to {to} project."
+
 ### Step 6: Load Plan Progress
 
 Generate the **Plan Progress** section:
 
 - Read all tasks from plan.yaml.
-- Build a compact status table: `| # | id | title | status | skill_hint |`
-- Highlight `current_task` row (prefix with `>>` or bold).
+- Build a compact status table: `| # | id | title | status | project | skill_hint |`
+- Highlight `current_tasks` rows (prefix with `>>` or bold).
 - Count summary: `Done: {d}, In Progress: {ip}, Pending: {p}, Blocked: {b}, Skipped: {s}`
+- If any task has `deliverables.freshness == "stale"`, append a warning: "Stale deliverables: {task_ids} -- downstream tasks may be out of date. Run `/mvt-implement` to refresh."
 
 And the **Current Task Detail** section:
 
@@ -82,11 +98,12 @@ And the **Current Task Detail** section:
 Render via the `resume-output.md` template. Sections to fill:
 
 1. **Active Task** -- name, change-id, started_at (from selected plan)
-2. **Plan Progress** -- task table + counts + current task detail
-3. **Recent Skill History** -- last 5 entries from history (filtered to selected change if applicable)
-4. **Recent Artifacts** -- the top 5 artifacts collected in Step 4 (path, mtime, size)
-5. **Resume Point** -- a one-paragraph natural-language summary of "where we are"
-6. **Recommended Next Step** -- the mapped next skill from Step 5, with justification
+2. **Epic Context** (if `within_epic` is true) -- epic title, id, progress (done/total children), current position within the epic. Resolve the parent epic path: compare `active_change.epic_id` to `active_epic.id`. If they match, use `active_epic.epic_path`. If they do not match, search `session.epics[]` for an entry with `id == active_change.epic_id` and use its `epic_path`. If neither path exists, render the plan resume and add a bounded warning: "Epic context could not be loaded (epic_id: {active_change.epic_id})." Read `epic.yaml` via the resolved path and render: "This change is part of epic: **{epic_title}** ({done}/{total} sub-changes done). Current: {active_child_title}."
+3. **Plan Progress** -- task table + counts + current task detail
+4. **Recent Skill History** -- last 5 entries from history (filtered to selected change if applicable)
+5. **Recent Artifacts** -- the top 5 artifacts collected in Step 4 (path, mtime, size)
+6. **Resume Point** -- a one-paragraph natural-language summary of "where we are"
+7. **Recommended Next Step** -- the mapped next skill from Step 5, with justification
 
 ### Step 8: Edge Cases
 
@@ -94,4 +111,7 @@ Render via the `resume-output.md` template. Sections to fill:
 - **No active plans**: report "No active plans found. Start a new change with `/mvt-analyze` or run `/mvt-status` to check project state."
 - **Selected change but referenced artifacts missing**: warn "Artifact directory `{path}` not found -- task state may be stale. Verify with `/mvt-status` or run `/mvt-cleanup`."
 - **Plan exists but plan.yaml is invalid** (parse error or schema violation): warn "plan.yaml is corrupted or invalid. Run `/mvt-plan-dev` to regenerate, or `/mvt-status` to inspect."
-- **Stale task warning**: If plan's `current_task` has status `in_progress` but the plan's `updated_at` is more than 5 days old, append a notice: "Current task has been in_progress for {N} days without updates. Consider running `/mvt-update-plan` to refresh status."
+- **Stale task warning**: If plan's `current_tasks` entries reference tasks with status `in_progress` but the plan's `updated_at` is more than 5 days old, append a notice: "Current task has been in_progress for {N} days without updates. Consider running `/mvt-update-plan` to refresh status."
+- **Stale deliverables warning**: If any task has `deliverables.freshness == "stale"`, warn: "Task(s) {ids} have stale deliverables. Downstream tasks may reference outdated contracts. Run `/mvt-implement` to refresh."
+- **Epic-pending but epic.yaml missing**: warn "Epic state references `epic_path` but file not found at `{path}`. Run `/mvt-status` to inspect or `/mvt-cleanup` to archive stale entries."
+- **Epic-pending but current_change empty or invalid**: warn "Epic `current_change` is empty or points to a non-existent child. Run `/mvt-status` to inspect the epic state."

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

@@ -30,8 +30,8 @@ sections:
         - rule: "Exactly one in_progress plan found -> Auto-select it and proceed"
         - rule: "No plans found -> Report no active plans, suggest `/mvt-analyze` or `/mvt-plan-dev`"
         - rule: "active_change is empty AND history is empty AND no plans -> Recommend `/mvt-init` or `/mvt-status`"
-        - rule: "Plan exists and has current_task -> Use current_task's skill_hint as next-step recommendation"
-        - rule: "Plan's current_task has been in_progress for >5 days -> Surface stale warning"
+        - rule: "Plan exists and has current_tasks -> Use current_tasks entry's skill_hint as next-step recommendation"
+        - rule: "Plan's current_tasks entry has been in_progress for >5 days -> Surface stale warning"
         - rule: "Last skill was interrupted -> Surface the context, suggest retry"
       boundaries:
         - scope: "read git state (branch, diff, commits)"
@@ -70,7 +70,7 @@ sections:
       current_skill: mvt-resume
       conditional_suggestions:
         conditions:
-          - condition: "plan has current_task with skill_hint"
+          - condition: "plan has current_tasks entry with skill_hint"
             primary: mvt-implement
             primary_desc: "Continue with the next planned task (use skill_hint)"
           - condition: "no active plans found"

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

@@ -4,7 +4,7 @@
 - **Required**:
   - The set of files to review (see Step 2 for resolution).
 - **Fallback**:
-  - If `design.md`/`implementation.md` are missing, downgrade to "code-only review": skip the design-compliance checks (Step 4 row group A) and note the limitation in the artifact.
+  - If `design.md`/`implementation.md` are missing, downgrade to "code-only review": skip the design-compliance checks (Step 5 row group A) and note the limitation in the artifact.
   - If `project-context.md` is missing, skip layer-compliance checks and note the limitation.
 
 ### Step 2: Resolve Review Target
@@ -22,12 +22,27 @@
 - If the resolved list is empty, STOP and ask the user to specify the target.
 - If the list exceeds ~30 files, ask the user to scope down OR confirm a high-level (per-module) review depth.
 
-### Step 3: Determine Review Depth
-- **Default**: full review across all axes (Step 4).
+### Step 3: Identify Project Scope and Load Project-Specific Knowledge
+
+This step applies only when the workspace has multiple projects (`projects.length > 1` in `project-context.yaml`). In single-project workspaces, all relevant knowledge was loaded at activation; skip this step entirely.
+
+- **Project identification**: match the file paths resolved in Step 2 against `projects[].path` and `projects[].source_paths`:
+  - A file whose path starts with a project's `path` prefix belongs to that project.
+  - A file under a project's `source_paths` entry also belongs to that project.
+  - Collect the set of unique project names from all matched files. This is the **active project scope** for this invocation.
+- **On-demand knowledge loading**: for each project P in the active project scope, read `.ai-agents/registry.yaml` and load:
+  1. Every entry under `knowledge.{P}` -- load each entry's referenced files (resolve relative to `.ai-agents/{source}`).
+  2. Every entry under `skills.mvt-review.knowledge.{P}` -- load each entry's referenced files.
+  3. Skip any key absent from the registry (no project-specific knowledge is valid; do not warn).
+- **Multi-project scenario**: if files span multiple projects, load each project's knowledge sequentially. The skill operates with the union of all loaded project-specific knowledge plus the `_all` knowledge already loaded at activation.
+- **Unmatched files**: if a file path does not match any project's `path` or `source_paths`, surface a note and treat it as belonging to the first project in `projects[]` (fallback). This may indicate a configuration gap in `project-context.yaml`.
+
+### Step 4: Determine Review Depth
+- **Default**: full review across all axes (Step 5).
 - `--aspect <name>`: narrow to a single axis. Supported aspects: `architecture`, `quality`, `errors`, `edge-cases`, `security`, `naming`, `tests`. Other aspects -> ask user to clarify.
 - For files >300 lines, do a structural pass first (interfaces, exports, key paths) before line-level review; do not attempt line-by-line on huge files.
 
-### Step 4: Run Review Checks
+### Step 5: Run Review Checks
 - **What**: produce findings, each tagged with severity, location, and a concrete remedy.
 - **How**: walk the checklist below. Skip any group whose inputs were missing per Step 1 fallback notes.
 
@@ -39,7 +54,7 @@
 
   **Group B -- Code Quality**
   - Functions are small and focused; flag functions > ~50 lines or with > ~3 nested control levels.
-  - Naming is clear, consistent with `naming-conventions.md`, and matches surrounding code.
+  - Naming is clear, consistent with the naming conventions loaded by activation (if any), and matches surrounding code.
   - No duplication: same logic appearing >= 3 times warrants extraction.
   - No premature abstraction: a single-use helper / interface / wrapper is a finding.
   - No dead code, unused imports, commented-out blocks left behind.
@@ -68,7 +83,7 @@
   - Auth/authz checks present on every protected endpoint or operation.
   - SQL/NoSQL/HTML rendered through parameterized / escaped APIs.
 
-### Step 5: Categorize and De-duplicate Findings
+### Step 6: Categorize and De-duplicate Findings
 - **Severity**: assign each finding using the table below.
 
   | Level | Definition | Examples |
@@ -80,7 +95,7 @@
 - Merge duplicate findings (same root cause appearing in multiple files) into one entry with a list of locations.
 - Each finding must include: file, line range, severity, observation, recommendation.
 
-### Step 6: Write Artifact
+### Step 7: Write Artifact
 - **Path and template**: as defined in the **Artifact Structure** section below. If no `active_change` exists, use `.ai-agents/workspace/artifacts/_ad-hoc-review-{YYYY-MM-DD-HHMM}/review.md`.
 - **Required content** (mapped to template headings):
   - `Review Scope` -- file list, depth, aspect filter, fallbacks applied (e.g., "design.md missing -> Group A skipped").
@@ -91,13 +106,13 @@
   - `Skipped Checks` -- groups skipped because inputs were missing, with reason.
   - `Recommended Next Skill` -- e.g., `/mvt-fix` for Critical, `/mvt-test` if Group E gaps, `/mvt-refactor` if Group B is dominant.
 
-### Step 7: Verdict Rule
+### Step 8: Verdict Rule
 - Critical > 0 -> verdict is `Request changes`. Suggest `/mvt-fix`.
 - Critical = 0, Warnings > 5 -> verdict is `Approve with comments`.
 - Critical = 0, Warnings <= 5, Suggestions only -> verdict is `Approve`.
 - Code-only review (design.md missing) -> verdict cannot be higher than `Approve with comments` (call it out explicitly).
 
-### Step 8: State Update
+### Step 9: State Update
 Apply the State Update rules defined in the **State Update** section below.
 
 ## Edge Cases & Errors

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

@@ -62,6 +62,9 @@ sections:
   - type: shared
     source: sections/output-language-constraint.md
 
+  - type: shared
+    source: sections/output-format-constraint.md
+
   - type: shared
     source: sections/activation-preflight.md
     params:

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

@@ -11,16 +11,16 @@
 ### Step 2: Build Activity Timeline
 - **What**: produce the most-recent-first list of history entries with derived metadata.
 - **How**:
-  1. Read `history` from `session.yaml`.
+  1. Read `.ai-agents/workspace/session.yaml`, extract `history`.
   2. For each entry, attach: relative time (e.g., "2h ago"), `change_id` (if present), and the originating skill name.
   3. Limit to the last 10 entries for the rendered table; keep full count separately for the summary line.
 
 ### Step 3: Discover All Plans (Multi-Change Dashboard)
 - **What**: produce the canonical plan list across the workspace.
 - **How**:
-  1. Iterate `changes[]` from `session.yaml`. For each entry with a `plan_path`, attempt to read the plan file.
+  1. From the session data loaded above, iterate `changes[]`. For each entry with a `plan_path`, attempt to read the plan file.
   2. Glob `.ai-agents/workspace/artifacts/*/plan.yaml` to find any plans not registered in `changes` (mark them `unindexed`). **Exclude paths under `artifacts/_archived/`** — those are completed changes archived by `/mvt-cleanup`.
-  3. For each plan, extract: `change_id`, `title`, `status`, `current_task`, task progress (`done/total`), `updated_at`, `skill_hint` (from current task if present).
+  3. For each plan, extract: `change_id`, `title`, `status`, `current_tasks`, task progress (`done/total`), `updated_at`, `skill_hint` (from current task if present).
   4. If a plan file is present but malformed, include a row with `(corrupt)` in the status column and mark the file path; do not abort.
 - **Branches**:
 
@@ -38,19 +38,44 @@
   2. **Projects** -- table: name | type | tech stack (truncated). Cap at 10 rows; collapse the rest into `+N more`.
   3. **Semantic Context** -- one line: `project-context.md present` / `missing -- run /mvt-analyze-code`.
   4. **Active Change** -- if `active_change` exists: id, title, start time. Else: `none`.
+  4a. **Epic Progress** -- if `active_epic.id` is non-empty:
+     - Read `epic.yaml` via `active_epic.epic_path`. If the file is missing or unreadable, render `(epic.yaml not found at {path})` and skip this section.
+     - Compute progress: count children with `status` in `["done", "abandoned"]` as completed; total = `children.length`.
+     - Render:
+
+       ```markdown
+       ## Epic: {epic_title} ({epic_id})
+       Progress: {done}/{total} done -- Status: {status}
+
+       | Sub-change | Status | depends_on | Internal Progress |
+       |------------|--------|------------|-------------------|
+       | {title} | {status} | {deps or --} | {plan progress or --} |
+       ```
+
+     - For each child in `epic.yaml.children[]`:
+       - `depends_on`: comma-separated list of change_ids, or `--` if empty.
+       - `Internal Progress`: for a child with `status: active`, attempt to read its plan.yaml from `.ai-agents/workspace/artifacts/{change_id}/plan.yaml`. If found, show `{done_count}/{total_count} tasks`. If not found, show `--`. For non-active children, show `--`.
+     - Below the table, render a context line:
+       - If `active_change.id` is non-empty (within-epic active change): "Current: **{active_child_title}**. Run `/mvt-resume` to continue."
+       - If `active_change.id` is empty (epic-pending state): "Next sub-change: **{current_change_title}**. Run `/mvt-analyze` to start."
   5. **Changes Overview** -- table from Step 3 (skip if no plans). Render with these columns:
 
-     | change-id | title | status | progress | current_task | updated_at |
-     |-----------|-------|--------|----------|--------------|------------|
+     | change-id | title | status | progress | current_tasks | project | updated_at |
+     |-----------|-------|--------|----------|---------------|---------|------------|
+
+     For `current_tasks`, display as a compact representation: if single-project, show the task id only; if multi-project, show `web: t2, api: t1` format. The `project` column lists the distinct projects across all tasks in the plan.
+
+     If any task has `deliverables.freshness == "stale"`, append a warning row: "Stale deliverables: {task_ids} -- run `/mvt-implement` to refresh"
   6. **Skill History** -- last 5 rows of the timeline from Step 2.
 
 - Hard cap: total rendered output should not exceed ~120 lines. If it would, truncate Skill History first; never truncate the active change or Changes Overview header rows.
 
 ### Step 5: Suggest Next Step
 - Resolution order (first match wins):
-  1. `active_change` has a plan in `in_progress`, `current_task` is set -> suggest the task's `skill_hint` (or, if missing, recommend `/mvt-update-plan` to set `current_task`).
-  2. `project-context.md` is missing -> suggest `/mvt-analyze-code`.
-  3. No `active_change` or no active plan -> suggest `/mvt-analyze` to start a new feature OR `/mvt-help` to browse the catalog.
+  1. `active_change` has a plan in `in_progress`, `current_tasks` has entries -> suggest the relevant task's `skill_hint` (or, if missing, recommend `/mvt-update-plan` to set `current_tasks`).
+  2. `active_epic.id` non-empty AND `active_change.id` empty (epic-pending state) -> suggest `/mvt-analyze` -- Start the next sub-change in the epic.
+  3. `project-context.md` is missing -> suggest `/mvt-analyze-code`.
+  4. No `active_change` or no active plan -> suggest `/mvt-analyze` to start a new feature OR `/mvt-help` to browse the catalog.
 - The suggestion must be a single line: skill command + one-clause reason.
 
 ## Edge Cases & Errors
@@ -60,8 +85,11 @@
 | `session.yaml` missing entirely | Render a minimal report (Projects section if available) and recommend `/mvt-init` |
 | `session.yaml` corrupt (parse error) | Surface error with file path, render Projects only, recommend `/mvt-init` to reinitialize |
 | `changes[]` references a `plan_path` that no longer exists | Include in Changes Overview with `(missing)` marker; do not delete the index entry from this skill |
-| Plan file's `current_task` references a task id not in `tasks[]` | Render `current_task` as `(invalid: <id>)`; do not attempt to fix |
+| Plan file's `current_tasks` references a task id not in `tasks[]` | Render `current_tasks` entry as `(invalid: <id>)`; do not attempt to fix |
 | Plan file's `status` is not one of the known values | Render the raw value verbatim; flag in skip-checks of the report |
 | Both `changes[]` and the artifact glob find the same plan | Deduplicate by `change_id`; prefer the indexed entry's metadata |
 | Multiple `in_progress` plans | All rendered in Changes Overview; Step 5's suggestion picks the most recently updated; mention the count in the suggestion line |
 | Workspace contains zero projects | Render header only with a single suggestion: `/mvt-init` |
+| `active_epic.epic_path` points to missing `epic.yaml` | Render `(epic.yaml not found at {path})` in Epic Progress section; skip the section |
+| `epic.yaml` parse error | Surface one-line error with file path, skip Epic Progress section; do not attempt repair |
+| `epic.yaml.current_change` points to non-existent child | Show `(invalid: {id})` in the child table context line |

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

@@ -25,7 +25,7 @@ sections:
         - rule: "If workflow in progress -> Highlight recent skill history and next recommended step"
         - rule: "If project-context.md missing -> Suggest `/mvt-analyze-code` to generate semantic context"
         - rule: "If one or more plans exist -> Show Changes Overview table with progress for all plans"
-        - rule: "If an in_progress plan has a current_task -> Suggest the matching skill_hint as next step"
+        - rule: "If an in_progress plan has current_tasks -> Suggest the matching skill_hint as next step"
       boundaries:
         - scope: "analyze requirements"
           skill: "/mvt-analyze"
@@ -63,7 +63,7 @@ sections:
       current_skill: mvt-status
       conditional_suggestions:
         conditions:
-          - condition: "active change with current_task"
+          - condition: "active change with current_tasks"
             primary: mvt-resume
             primary_desc: "Resume work on the current task"
           - condition: "project-context.md missing"