assess

MDT Code Fitness Assessment Workflow (v2)

Assess affected code before architecture design. Surfaces the decision: integrate as-is, refactor inline, or split CRs.

Core Principle: Know the state of what you're touching before deciding how to touch it.

User Input

$ARGUMENTS

Session Context

Use {TICKETS_PATH} in all file path templates below (if it's not defined read ticketsPath key from .mdt-config.toml).

Output

File {filename} has {None/Partial} test coverage. Refactoring without tests risks breaking undocumented behavior.

Behaviors identified for testing:

Behavior	Type	Risk if Untested
{function} returns {shape}	Return contract	Silent shape change
{function} throws {ErrorType}	Error contract	Wrong error type
{function} emits {event}	Side effect	Missing events

Recommendation: Add behavioral preservation tests before proceeding.

Options: [A] Add tests inline (expand CR scope) [B] Create test CR first (CR-TEST blocks this CR) [C] Proceed without tests (accept risk)

### Step 5: Determine Recommendation

Based on findings:

**Option 1 (Just Integrate)** when:
- All files ✅ Healthy
- Or: ⚠️ files not in direct change path
- Or: Deadline pressure justifies deferring

**Option 2 (Refactor Inline)** when:
- ⚠️ files in direct change path
- Total refactor effort ≤ 4 hours
- Refactoring improves the feature work

**Option 3 (Split CRs)** when:
- 🔴 Critical files in change path
- Total refactor effort > 4 hours
- Refactoring benefits multiple future CRs
- High-risk files (volatile + low tests)
- **🔴 No test coverage on files being refactored** (test CR first)

### Step 6: Present Assessment

```markdown
## Code Fitness Assessment: {CR-KEY}

### Summary

| Verdict | Count | Action |
|---------|-------|--------|
| ✅ Healthy | {N} | Proceed |
| ⚠️ Concerning | {N} | Consider refactoring |
| 🔴 Critical | {N} | Refactor required |

### Affected Files