Scope & Boundaries

spec은 행위에 집중하고, UI 명세는 범위 밖으로 둔다.

행위에 집중한다

spec은 "사용자가 무엇을 할 수 있는가"를 선언한다. 어떻게 보이는가(UI), 어떻게 구현하는가(기술)는 다루지 않는다.

범위 안

사용자 행위: "이슈를 생성할 수 있다", "상태를 변경할 수 있다"
시스템 동작: "마감일이 지나면 알림을 보낸다"
비즈니스 규칙: "재고가 0이면 구매할 수 없다"

범위 밖

UI 레이아웃: "버튼은 오른쪽 상단에 위치한다"
시각 디자인: "에러 메시지는 빨간색으로 표시한다"
기술 구현: "Redis 캐시를 사용한다"

모호할 때

경계가 모호한 경우, "다른 UI로 바꿔도 이 문장이 유효한가?"를 기준으로 판단한다.

문장	판단	이유
"드래그로 순서를 변경할 수 있다"	범위 안	UI를 바꿔도 "순서 변경" 행위는 유효
"드래그 시 반투명 고스트를 표시한다"	범위 밖	드래그 UI에 종속된 시각 명세
"목록을 칸반 보드로 볼 수 있다"	범위 안	"칸반 보드"는 보기 형식이라는 행위

검증 방식

Intent Map과 spec의 일관성은 도구가 아닌 에이전트 워크플로우 규칙으로 관리한다. 자동화된 파서나 CI 검증을 도입하지 않는다.

구현 전 확인 원칙

구현을 시작하기 전에 다음을 확인한다:

Intent Map에 spec이 등록되어 있는가 — 등록되지 않은 spec은 먼저 매니페스트에 추가한다.
spec 파일이 존재하는가 — Intent Map에 이름만 있고 파일이 없으면 먼저 작성한다.
spec이 행위에 집중하는가 — UI 명세나 기술 구현이 섞여 있으면 분리한다.

이 원칙은 에이전트의 워크플로우 규칙이나 코드 리뷰 체크리스트에 포함시켜 운용한다.

Intent Map 활용

Intent Map은 다음 상황에서 참조한다:

새 기능 계획 — 어떤 도메인에 배치할지 결정
영향 범위 파악 — 변경이 어떤 spec에 영향을 주는지 확인
도메인 분리 판단 — 한 도메인의 spec이 많아지면 접두사로 분리

다음 단계

Schema Reference — .intent.yml의 전체 필드를 확인한다