백엔드 변경이 architecture boundary, dependency direction, policy, TDD 결정에 맞는지 독립 검토해야 할 때 사용하는 리뷰 규칙.
백엔드 코드를 요구사항과 설계 결정에 맞게 수정하고 compile/test/typecheck 같은 구현 검증 evidence를 남겨야 할 때 사용하는 구현 규칙.
백엔드 구현 전에 아키텍처 판단, 계층 책임, 트랜잭션, 정합성, 실패 처리, 동시성, 검증 계획을 기술설계문서로 정리해야 할 때 사용하는 작성 규칙.
프론트엔드 변경이 architecture, conventions, performance, UI/UX 기준에 맞는지 독립 검토해야 할 때 사용하는 리뷰 규칙.
UI, route/page, component, client state, API client, query/cache 코드를 요구사항과 설계 결정에 맞게 수정하고 구현 검증 evidence를 남겨야 할 때 사용하는 구현 규칙.
프론트엔드 구현 전에 사용자 흐름, route, component, state, API, cache, error, browser 검증 계획을 기술설계문서로 정리해야 할 때 사용하는 작성 규칙.
feature delivery 요청에서 product planning, API contract, backend/frontend delivery engineer subagent를 오케스트레이션하고 결과를 통합할 때 사용한다. subagent가 다른 subagent를 호출할 수 없는 runtime에서 fullstack 기능 전달 오케스트레이션이 필요한 경우 사용한다.
Analyze an existing backend codebase and update `docs/backend` so architecture, policies, strategies, getting-started notes, and design documentation reflect actual code instead of generic playbook assumptions.