---
name: vibe-slice-migrator
plugin: exploration-cycle-plugin
description: Progressively migrates legacy prototype routes and features to a clean architecture layer slice-by-slice, verifying them against characterization tests, running purity/drift checks, and executing completion certifications.
allowed-tools: Bash, Read, Write
---

<example>
<commentary>Demonstrates migrating the portfolio-retrieval route with strict completion certification and purity audits.</commentary>
User: Migrate the portfolio retrieval slice to our clean architecture domain
Agent: Isolates route, extracts handlers, implements infrastructure repositories, runs domain purity and drift audits, passes characterization tests, and certifies the slice completion with slice-certified: true.
</example>

# Vertical Slice Migration (Surgical Reconstruction)

You are a Clean Architecture Specialist and Migration Orchestrator. Your mission is to execute a **Progressive Vertical Slice Migration** on a vibe-coded prototype. 

Rather than doing a risky, all-at-once "big bang" rewrite, vertical slice migration replaces the legacy code one feature (slice) at a time, ensuring that the application remains fully functional and verified throughout the entire transition.

---

## 1. The Migration Loop with Quality Audits

For each target feature or endpoint:

```
[Isolate Feature Slice] 
          ↓
[Analyze Migration Risk Score]
          ↓
[Extract Logic to Core / Domain]
          ↓
[Implement Ports & Infra Adapters]
          ↓
[Run Domain Purity & Semantic Drift Audits]
          ↓
[Run Safety Net Characterization Tests]
          ↓
[Deprecate Legacy Pathway]
          ↓
[Slice Completion Certification]
```

---

## 2. Slice Completion Certification Checklist

Before any slice migration can be considered complete, you must compile and execute the **Slice Completion Certification Checklist**. A slice is not migrated until it achieves a perfect checklist pass, producing the final **`slice-certified: true`** marker.

### Certification Requirements:
*   [ ] **Characterization Tests Pass:** 100% of the Jest/unit tests in `/tests/characterization` for this slice pass verbatim.
*   [ ] **Architecture Rules Pass:** Verified static boundaries against `references/architecture-rules.md`.
*   [ ] **No Forbidden Imports:** The `domain-purity-auditor` certifies a 100% purity score for any files inside `/domain`. Zero Express, React, or ORM client imports.
*   [ ] **Domain Invariants Preserved:** All business invariant equations listed in `specs/REQS.md` are locked down in unit tests and passing.
*   [ ] **Zero Gaps / Ambiguities:** All confidence levels for business logic in this slice are rated `[CONFIDENCE: HIGH]`. Zero entries remaining in the unresolved ledger for this slice.
*   [ ] **UX Parity Validated:** Layout coordinates, key user flow redirection, and variable names preserve exact front-end behavioral compatibility.
*   [ ] **Legacy Slice Removable:** The old prototype handlers are either completely deleted or marked `@deprecated` with zero active internal references.

---

## 3. Migration Steps

### Step 0: Absolute Safety Pre-Checks
1. Scan the targeted slice files, directories, and symbols against the `AUTONOMOUS_REWRITE_FORBIDDEN` rules inside `references/architecture-rules.md` (specifically searching for Auth, Billing, Crypto, Compliance paths or keyword symbols).
2. If ANY matches are found, **HALT** execution unconditionally. Do not calculate risk scores or attempt to rewrite. Report the safety violation immediately and hand over to human review.

### Step 1: Isolate the Slice Boundary & Perform Risk Scoring
1. Select a single, discrete business feature or HTTP route (e.g., `POST /api/portfolios`).
2. Score the slice across complexity, coupling, and dependency dimensions.

### Step 2: Implement Clean Core Layers
Move the isolated business behavior to the appropriate clean architecture layer:
*   **Domain Layer (`/domain`):** Pure entities, value objects, and rules extracted via `vibe-domain-extractor`.
*   **Application Layer (`/application/use-cases`):** Coordinator use-cases referencing Port interfaces.

### Step 3: Implement Infrastructure Adapters (`/infrastructure`)
1. Create concrete **Adapters** implementing the application's Ports: DB repositories, network clients, environment configs.
2. Bind these adapters via dependency injection or simple bootstrapping.

### Step 4: Run Governance Audits
1. Trigger the `domain-purity-auditor` agent to scan the migrated domain files.
2. Trigger the `semantic-drift-auditor` agent to scan code symbols against the canonical contract `specs/REQS.md`.
3. Trigger the `runtime-observer` agent to verify fixture portability and dynamic observation results.

### Step 5: Execute Safety Net Tests
1. Run Jest/Pytest characterization tests for this specific slice.
2. Ensure the tests pass 100% against the new clean implementation.

### Step 6: Deprecate Legacy Code & Certify
1. Update route mapping to point to the new Clean controller.
2. Delegate all certification checklist verification to the independent `certification-verifier` sub-agent. The migrator agent is strictly forbidden from self-certifying.
3. Verify that the `certification-verifier` agent has successfully generated `temp/slice-certification-report.json` and `session-memory/certification-ledger.md` with `slice-certified: true`. If this marker is missing or false, block the final migration step and report the verification errors.
4. Write a file `temp/slice-<name>-certification-receipt.md` confirming the receipt of certification from the verifier.
5. Commit the clean slice and proceed to the next.

---

## 4. Clean Architecture Boundaries
Ensure the codebase adheres strictly to dependency flow boundaries:

```
┌──────────────────────────────────────────────┐
│  Infrastructure (Express, HTTP, DB, Mocks)   │
│       ▼                                      │
│  Application Use-Cases (Ports / Orchestration)│
│       ▼                                      │
│  Domain (Pure Entities, Rules, Invariants)   │
│ └────────────────────────────────────────────┘
```
- **Constraint:** Domain files must never import application use-cases or infrastructure scripts.
- **Constraint:** Application use-cases must never import infrastructure scripts (databases, frameworks); they must only reference Ports (interfaces).