mandu-mcp-verify

Mandu MCP Verify

편집 직후 / 생성 직후 / pre-commit 에서 도는 표준 검증 루프. 핵심은 "하나의 ate 파이프라인 + guard + 구조 진단" 을 병렬 fast path 로 먼저 돌리고, 실패했을 때만 세분 도구로 drill-down 하는 것.

Trigger

• 파일 편집 직후 (특히 app/, spec/, src/shared/contracts/)
• mandu_generate 완료 직후 (create-flow 가 자동 전이)
• "check 해줘", "제대로 된 거야?", "괜찮아?"
• stop-hook / pre-commit 자동 실행
• 사용자가 명시적으로 "verify", "validate", "검증"

Fast Path (병렬, 기본값)

네 도구는 서로 독립. 병렬 호출.

┌─────────────────────────────┐
│ mandu.ate.auto_pipeline     │  ← Tier-0: extract/generate/run/heal 전부
├─────────────────────────────┤
│ mandu_guard_check           │  ← Tier-1: 아키텍처 규칙 위반 스캔
├─────────────────────────────┤
│ mandu.lint                  │  ← 가드레일-lint: 코드 품질 스캔 (oxlint)
├─────────────────────────────┤
│ mandu_doctor                │  ← Tier-0: 구조/import/location 진단
└─────────────────────────────┘
       네 개를 parallel 호출

인자 예:

mandu.ate.auto_pipeline({
  repoRoot: ".",
  oracleLevel: "standard",
  useImpactAnalysis: true,    // 변경된 라우트만 대상
  autoHeal: false              // heal 은 별도 단계
})

mandu_guard_check({ repoRoot: "." })

mandu.lint({ typeAware: false })   // oxlint 미설치 시 조용히 skip

mandu_doctor({ repoRoot: "." })

네 응답을 수집하고 pass/fail 매트릭스를 만든다:

도구	pass	fail 의 의미
ate.auto_pipeline	테스트 통과 + 계약 일치	테스트 실패 또는 impact 드리프트
guard_check	레이어/금지 import 위반 없음	아키텍처 규칙 위반
lint	oxlint error 0	error 1+ (warning 은 informational)
doctor	파일 위치 / import 정상	구조 결함

네 개 모두 green → verify 종료. 사용자에게 압축 요약 제시.

Drill-Down (실패 시에만)

fast path 가 빨간 항목을 돌려주면 그 카테고리별로만 drill-down. 세 종류가 다 실패했다고 모든 drill-down 을 돌리지 말고, 응답에 들어온 카테고리만.

Guard 실패

mandu_guard_explain({ violationId })    ← 먼저: 왜 위반인지 설명
  → (자동 수정 가능하면) mandu_guard_heal({ autofix: true, violationIds: [...] })
  → (수동 수정이면) 사용자에게 수정 지시 후 fast path 재실행

ATE 실패 (테스트 실패 / 힐 후보 있음)

mandu.ate.feedback({ runId })           ← 힐 후보의 카테고리/우선순위
  → mandu.ate.apply_heal({ runId, healIndex, createBackup: true })
  → fast path 의 ate.auto_pipeline 재실행