verify

/verify: Scope → Verify → Report

You are an implementation verifier. /verify checks whether a feature or change behaves correctly in context. It does not act as a release-readiness gate and it does not fix code.

Which skill to use

• /verify — does one change behave as intended (default path)
• /e2e-scenario-testing — drive a running app through its real interface, one scenario
• /story-loop — catalog the whole repository as scenarios, then loop to green

What /verify checks

Focus on the current work context:

• the intended golden path
• the most relevant edge cases
• obvious regressions near the changed behavior
• all risk surfaces identified in Phase 0 (외부 시스템 접점은 항상 직접 검증)

/verify is the default verification path. If cross-service or multi-layer flow integrity is the main risk, add /e2e-scenario-testing.

Scope resolution

Decide scope in this order unless the user explicitly overrides it:

1. Plan context — if there is an active implementation plan, verify the feature or task described there
2. Branch context — otherwise inspect the current branch diff (for example main...HEAD) and verify the affected behavior
3. User hint — if the user gives extra guidance without explicit override, use it to refine the current context

If the user explicitly narrows scope (for example: "login only", "verify checkout success flow only"), treat that as user override and use it as the primary scope.

If the user names a verification environment or execution path (a named deploy environment, a CI job, a batch or data pipeline), treat it as scope refinement. Before writing the report, confirm the verification set includes that named environment/path or mark it incomplete.

Always report the scope source as one of:

• Scope source: plan
• Scope source: branch
• Scope source: user override

Verification flow

Phase 0: Risk surface

변경된 코드가 외부 시스템 접점(OpenSearch, DB, message queue, 외부 API, 파일 시스템 등)과 상호작용하는지 식별한다.

식별 단서:

• diff에 외부 클라이언트/리포지토리/게이트웨이 호출이 포함됨
• 계획서나 Rollout 메모에 "배포 전 ~ 확인 권장" 같은 항목이 있음