references/plan-output-contract.md

# Plan mode 답변 이해 출력 계약

AI 백서가 실제 적용된 요청에서 호스트 지시가 현재 응답 환경을 `Plan mode`로 명시하고 최종 Plan을 만들 때만 이 파일을 사용한다.

## 1. 적용 판정

다음 조건을 모두 확인한다.

- AI 백서가 이번 요청에 실제 적용되었다.
- 시스템·개발자 등 호스트 지시가 현재 응답 환경을 Plan mode로 명시했다.
- 질문 단계와 결과 방향을 바꾸는 충돌 해소 단계가 끝나 최종 Plan을 생성할 수 있다.

사용자 요청에 `계획`이 있거나 내부 `기획·계획` 렌즈를 적용했다는 이유로 Plan mode를 추정하지 않는다. 사용자가 Plan mode를 언급하거나 요청해도 호스트 지시가 없으면 이 계약을 적용하지 않는다.

사용자가 `텍스트로만`, `표나 다이어그램 없이`처럼 시각 표현을 직접 금지하면 문단과 목록으로 완결된 Plan을 제공한다. `답만`·`결과만`은 시각 표현 금지로 해석하지 않는다. 안전, B, 변화 추적과 큰 변화 A의 기존 계약은 유지한다.

## 2. Plan 조립

호스트가 요구한 Plan 형식과 래퍼를 유지하고 임의의 래퍼나 별도 산출물을 만들지 않는다. 한 Plan 본문을 다음 순서로 조립한다.

1. [answer-clarity-output-contract.md](answer-clarity-output-contract.md)의 `핵심 답변`
2. 일반 문장보다 관계가 더 잘 보일 때만 핵심 관계를 보여주는 주 표현 하나
3. 확인된 범위에서는 별도 결정을 요구하지 않고, 미확정 값은 표시한 실행 상세와 완료 기준
4. 필요한 `AI 백서 변화 추적`, 검증, 다음 단계와 큰 변화 A 링크

주 표현을 선택했다면 `핵심 답변` 바로 다음에 둔다. 선택적인 표현 제목 외에는 `핵심 답변`과 주 표현 사이에 설명 문단·가정·구현 게이트·범위 안내를 두지 않고 모두 표현 뒤 실행 상세로 옮긴다. 적합한 관계가 없거나 문장이 더 명확하면 주 표현을 생략하고 일반 텍스트로 이어 간다.

AI 백서 활성·호스트 Plan mode·질문 해소 후 최종 Plan이라는 시각 우선 계약의 활성 조건이 성립하고 사용자가 완료일과 완료 행동을 하나의 관계로 지정했다면, 텍스트 전용이 아닐 때는 그 날짜와 행동을 주 시각의 같은 단계·행·셀에서 직접 연결하고 요약이나 시각 뒤 상세에만 분리하지 않는다. 텍스트 전용일 때는 같은 실행 단계나 문장에서 날짜와 행동을 직접 연결한다.

Plan 전체의 구조화 시각 블록은 최대 2개다. Mermaid·와이어프레임뿐 아니라 주 시각 표, 실행 상세 표, 변화 추적 표를 포함한 모든 Markdown 표를 각각 한 개로 센다. 두 번째 블록은 주 시각과 독립적인 관계를 표현할 때만 허용하며, 같은 관계를 반복하거나 장식만 하는 시각물을 추가하지 않는다. 주 시각과 변화 추적 표를 사용했다면 실행 상세는 표가 아닌 문단·목록·정의목록으로 쓴다. API 계약과 QA처럼 상세 영역이 둘 다 필요해도 시각 블록 한도를 넘기지 않도록 적어도 하나는 목록·정의목록으로 구성한다. B 최종 답변을 Plan 밖에 다시 출력하지 않고 변화 추적과 조건부 모듈도 같은 Plan 본문의 뒤쪽 보조 섹션에 한 번만 둔다.

조립 전에 사용자 입력·자료에 명시된 결정 관계를 다음 단위로 내부 점검한다. 이 점검표 자체를 사용자에게 노출할 필요는 없다.

- 행위자·행동·대상
- 선행 조건·순서·의존성
- 분기·예외·복구
- 시스템·데이터 계약
- 검증·완료 기준

사용자가 `모든 제품 결정이 확정`됐다고 밝히거나 `제공된 동작 집합을 그대로 구현`하라고 명시한 경우에만 그 입력을 닫힌 결정 집합으로 취급한다. 제공된 관계는 새 제품 의미를 만들지 않는 범위에서 구현·검증 단계로 분해할 수 있지만, 제공된 동작 계약을 표현하는 데 필요한 제안 명명 외에 새 사용자 동작·분기·복구·수명주기를 추가하지 않는다. 토큰·식별자·상태 코드는 제공된 동작을 표현하는 의미만 제안할 수 있으며, 앱 종료·재시작·상태 초기화, 약관 버전 변경·재동의, 네트워크·백그라운드 복구, 미제공 만료·재사용·저장·복구 의미, 동시성·원자성·멱등성 같은 새 결정을 모범 사례나 구현 기본값으로 확정하지 않고 생략하거나 `[확인 필요]`로 둔다. 사용자가 필드 존재만 제공했다면 그 필드에 새 변경·만료·재사용·저장 의미를 덧붙이지 않는다.

특정 횟수·범위·분기에 한정된 규칙을 모든 분기나 다른 실패 유형으로 확대하지 않는다. 예를 들어 1~4회 실패의 남은 횟수 비반환을 5회 실패·만료·rate limit 응답까지 넓히지 않는다. 1~4회 실패의 일반 불일치 안내만으로 현재 화면 유지 같은 UI 동작을 정하지 않으며, 일반 불일치 안내 외 UI 전이는 생략하거나 `[확인 필요]`로 둔다.


닫힌 결정 집합의 최종 답 직전에 문장·필드 단위 삭제 검사를 한다. 제목·구조, 제공 관계의 구현·검증 분해, 제공 동작을 표현하는 제안 명명을 제외하고 사용자 입력·자료에 직접 추적되지 않으면 삭제한다. 숫자 임계값이 중간 상태 표시를 뜻한다고 넓히지 않는다. 화면에서 수집한 필드가 어느 API에 전달·저장되는지 입력 없이 정하지 않고, 확정된 초기화 값과 다른 값을 만들지 않는다. 견고성·보안·완결성을 높인다는 이유만으로 미제공 의미를 남기지 않는다. 서버 필드·상태가 제공됐다는 사실만으로 입력에 없는 화면 표시·사용자 알림·QA 시나리오를 추가하지 않는다. 약관 메타데이터의 서버 관리만으로 화면 표시를 정하지 않는다. 필수 약관 동의 화면이라는 사실은 ID·version·본문 링크·필수 여부의 화면 표시를 정하는 근거가 아니다. 약관 동의 이력 저장만으로 가입 계정 저장을 확정하지 않는다. 가입 계정 저장·영속화는 생략하거나 `[확인 필요]`로 둔다. 기존 비밀번호 정책의 재사용만으로 API 오류 분기·오류 이름을 제안하지 않는다. 특히 `PASSWORD_POLICY_VIOLATION` 같은 새 오류 이름을 만들지 않는다. 다만 제공된 서버 타이밍·상태 전이를 직접 검증하는 구현·QA 분해는 허용한다. 따라서 `expiresAt`과 새 10분 코드가 제공됐다면 서버 타이밍 로직, 재발송 응답, `새 만료 시각 확인` QA로 분해할 수 있지만, 그 사실만으로 만료 시각 화면 표시나 새 코드 발송 사용자 안내를 추가하지 않는다. `기존 방식으로 세션 저장`처럼 결과 행동이 제공됐다는 사실은 그 행동의 구현·검증을 허용하지만 기존 인증 API 성공 응답 계약의 존재를 입증하지 않는다. 인접 API 계약을 `기존`이라고 쓰려면 사용자 입력·자료로 확인하거나 기존 계약 확인 게이트에 둔다.

사용자가 붙인 의미 필드 라벨은 대상 의미를 보존한다. 제안 별칭으로 `본문 link`를 `bodyLink` 또는 `contentUrl`로 바꿀 수 있지만, 필드 설명에서 `약관 본문 링크`임을 명시하지 않은 단독 `link`는 충분하지 않다.

닫힌 결정 집합에서 재발송 이벤트가 제공됐다는 사실만으로 입력에 없는 UI 입력 잠금 해제·재활성화·새 코드 입력 상태를 추가하지 않고 생략하거나 `[확인 필요]`로 둔다. 서버의 새 코드 발급, `expiresAt`, 재발송 응답과 제공된 rate-limit 처리를 API·서버 검증에 두는 것은 허용하지만, 이를 새 UI 동작으로 확장하지 않는다.

각 관계를 주 시각 블록이나 실행 상세의 적절한 위치에 한 번 이상 대응시킨다. 간결함을 위해 명시된 결정 관계를 삭제하거나 일반적인 모범 사례로 치환하지 않는다. 주 시각물은 핵심 흐름과 실행 판단을 바꾸는 대표 분기를 압축하되, 사용자가 핵심으로 지정한 모든 예외 분기는 선택한 흐름의 주 시각에서 직접 확인되게 한다. 예를 들어 `필수 약관 미동의 → 가입 완료 차단`을 실행 상세나 QA에만 두지 않는다. 이는 주 시각에 사소한 모든 분기까지 넣으라는 뜻이 아니라 사용자 지정 핵심 예외를 빠뜨리지 말라는 규칙이다. 나머지 명시된 화면 전환과 제어 상태는 실행 상세에 보존한다. 필드 구조처럼 흐름을 바꾸지 않는 시스템·데이터 계약도 실행 상세에 둘 수 있다.

사용자 입력에 명시된 결과 행동은 각각 Plan에서 직접 확인할 수 있게 쓴다. 예를 들어 `세션 저장`, `자동 로그인`, `홈 이동`을 서로 다른 결과로 요구했다면 하나를 다른 인접 상태로 암시하거나 생략하지 않는다.

역할의 해상도도 출처 그대로 유지한다. 입력에 지정된 팀이 맡은 동작은 그 팀 단위로 보존한다. 한 팀이 산출물의 전체 행위자로 지정됐다면 그 팀의 명칭을 그대로 Plan에 쓰고, 요약·범위와 실행·검증의 적절한 위치에서 전체 범위 책임을 직접 확인할 수 있게 한다. 이를 앱·시스템·무주체·담당 미정 표현으로 대체하거나 기술·화면·검증의 세부 단계에서 사라지게 하지 않는다. 리드·책임자·담당자·검토자 같은 하위 역할로 임의 분해하지 않는다. 입력에 없는 콘텐츠 제공자, 게시·확인 권한, 내부 절차는 실행에 꼭 필요하지 않으면 생략하거나 `[확인 필요]`로 둔다. 그 값이 결과 방향이나 안전을 바꾸는 경우에만 질문한다. `[가정]` 표시는 사람·역할·권한·사실을 새로 만들거나 확정하는 허가가 아니다.

역할에 읽기·쓰기 허용이 있다는 사실은 실행 책임 지정과 다르다. 입력에 별도 근거가 없으면 허용된 역할을 기록 저장·확인 담당으로 승격하지 않는다.

정의되지 않은 라벨을 `기존·현재 조직 기준`이라고 풀어 쓰지 않는다. 지정된 역할·계정·시스템이 이미 등록·프로비저닝·설정·보호됐다고 주장하지 않는다. 기존 승인 시스템·보존 기간처럼 입력에 명시된 승인 시스템·보존 기간은 그대로 사용할 수 있지만, 접근 주체의 등록이나 보안 영역 배치 같은 인접 상태 사실까지 확인된 것으로 확장하지 않는다.

사용자가 신규 API·데이터 계약 설계를 Plan 범위로 요청했다면 요청·응답·오류 계약의 경로·필드·코드를 `제안 인터페이스`로 정할 수 있다. 구현 전 기존 명명·충돌 확인을 실행 게이트로 두며, 제안값을 기존 시스템의 사실처럼 쓰지 않는다. 영속화 스키마, 비밀번호 해시, 인증코드 해시, 임시 저장, 트랜잭션·아웃박스, 멱등성·보존·로그 정책과 소유 역할 같은 내부 구현은 사용자 입력·자료·외부 확인에 근거가 없으면 확정하지 않고 생략하거나 `[확인 필요]`로 둔다. 제안이라는 이유만으로 확인되지 않은 저장 방식·소유 역할을 확정하지 않는다.

현재 워크스페이스나 기존 소스·저장소의 존재·부재·확인 가능 여부를 사용자 입력·자료·외부 확인 없이 단정하지 않는다. 예를 들어 `현재 워크스페이스에는 소스가 없다`고 쓰지 말고, 필요한 경우 `구현 전 기존 명명·계약 확인` 게이트로만 둔다.

제안 인터페이스로 정할 수 있는 것은 요청·응답·오류 계약의 경로·필드·오류 이름(오류 코드 이름 포함)뿐이다. 이름 제안은 사용자 입력·자료에 없는 데이터 타입·wire type·값 형식·직렬화 형식·enum·nullability까지 정할 권한이 아니다. 예를 들어 필드 이름만 제공되거나 제안한 `email`·`signupId`·`expiresAt`·`id`·`version`·`bodyLink`·`required`·`agreed`에 출처 없이 `: string`·`: boolean` 같은 타입을 붙이지 않는다. 필요한 속성에 출처가 없으면 생략하거나 `[확인 필요]`로 두며, 사용자 입력·자료가 타입·wire type·형식·enum·nullability를 직접 제공한 경우에는 그 제공값을 그대로 보존할 수 있다.


사용자 입력·자료·외부 확인에 없는 저장·보안·배포·관측 결정을 새 기본값이나 기존 정책으로 만들지 않는다. 메모리 보관·프로세스 재시작, 자격 증명·인증 증표의 보관, 배포 순서·운영 지표처럼 인터페이스 밖의 구현·운영 세부사항은 요청에서 확정한 관계가 아니면 생략하거나 `[확인 필요]`로 둔다. `기존 정책을 따른다`는 문구만으로 미제공 결정을 확정하지 않는다.

## 3. 관계 표현 선택

텍스트 전용이 아니더라도 모든 Plan에 표현을 강제하지 않는다. 다음 관계가 확인되고 일반 문장보다 이해가 쉬워질 때만 하나를 주 표현으로 선택한다. 표도 구조화 표현 블록으로 센다.

| 계획의 핵심 관계 | 기본 표현 |
|---|---|
| 같은 단위의 검증된 비음수 수치 비교 | 고정폭 가로 텍스트 막대 |
| 공통 기준이 있는 복수 선택지 | Markdown 비교표 |
| 명시적인 순서·의존성이 있고 분기가 없음 | 단계 흐름 |
| 조건에 따라 행동이 달라짐 | 결정 분기 |
| 날짜·기간·이정표 관계가 핵심 | 타임라인 |
| 화면·레이아웃·화면 전환 | 저충실도 텍스트 와이어프레임 또는 화면 흐름도 |
| 역할·승인·인계 | 시퀀스 다이어그램 또는 역할 표 |
| 위 관계가 없거나 문장이 더 분명함 | 일반 텍스트 |

가장 작은 표현으로 핵심 관계를 충분히 보여준다. 화면 관계가 핵심이 아닌데 와이어프레임을 강제하거나, 짧은 선형 계획에 장식용 흐름도를 만들지 않는다.

기본 주 표현은 하나다. 서로 독립적인 두 관계가 모두 결정에 필수일 때만 두 번째 표현을 허용한다. 질문·충돌 해소 중, 자료 부족, 관계 불명, 텍스트 전용 요청에는 표현을 만들지 않는다. 전체 구조화 표현 블록 최대 2개와 주 표현 바로 배치 규칙은 유지한다.

Mermaid 등 특정 문법의 렌더링을 호스트에서 안정적으로 사용할 수 있을 때만 그 문법을 사용한다. 호스트 지시가 현재 응답에서 Mermaid 렌더링 지원을 명시적으로 보장하지 않으면 지원 여부가 불확실한 것으로 보고 Mermaid를 사용하지 않는다. 이때 Markdown 표·텍스트 와이어프레임·들여쓰기 흐름 중 하나로 같은 정보를 보존한다. 일반적인 제품 지식이나 과거 렌더링 경험을 지원 확인으로 간주하지 않으며, 렌더링 성공, 생성하지 않은 첨부 파일이나 존재하지 않는 외부 링크를 주장하지 않는다.

## 4. 텍스트 완결성과 경계

시각 블록은 요약으로 사용하고 본문만 읽어도 목표, 범위, 선택한 접근, 의존성, 예외·실패 처리, 검증과 완료 기준을 실행할 수 있게 쓴다. 필요한 항목만 포함하되 시각물에만 결정 정보를 남기지 않는다.

확정되지 않은 사람·대상·날짜·기간·숫자·예산·권한·경로·정책·사실은 추측하지 않고 필요한 위치에 `[확인 필요]`를 남긴다. 게시일만 확인됐다면 임의의 초안·검토 마감일을 역산하지 않고 상대 순서로 쓴다. 기존 저장소·보존정책·승인권자·운영창이 제공되지 않았다면 `기존`이라고 단정하지 않는다.

현재 입력에서 이미 식별된 서로 독립적인 고영향 빈칸은 첫 질문 묶음에 모두 포함한다. 질문이 끝난 뒤에는 초기 입력과 후속 답의 명시 관계를 최종 B에 각각 직접 보존한다. 초기 입력이나 후속 답의 준비 완료 상태는 완료된 진입 조건으로 유지하고 새 준비 작업으로 바꾸거나 누락하지 않는다. `이미 확정해 제공`처럼 완료된 상태를 새 실행 단계의 `제공한다`로 바꾸지 않는다. 이런 상태는 진입 조건으로 두고 그 상태를 사용하는 후속 행동부터 실행 단계로 쓴다. 책임 변화는 변화 추적의 출처·B 변화·판단 및 행동 영향에서 같은 책임 주체와 책임 행동을 유지한다. 입력에 없는 롤백 후 재배포 절차·일정은 확정하지 않는다.

N2의 `2026-09-15 한국·일본 동시 출시` 조건과 `현행 보안 규정상 9월에는 한국만 출시 가능` 조건이 충돌하면, 질문 payload 전체에 두 조건의 이름과 내용을 각각 최소 한 번 직접 쓴다. 안전한 question 예시는 `2026-09-15 한국·일본 동시 출시 조건과 현행 보안 규정상 9월에는 한국만 출시 가능한 조건이 충돌합니다. 어느 조건을 변경하거나 예외 승인할 수 있나요?`이다. 표현은 의미가 같게 바꿀 수 있고 두 조건을 question 본문에만 모을 필요는 없지만, `두 조건`·`위 조건` 같은 대명사나 일반적인 보류·연기·예외 승인 표현은 어느 조건도 대신하지 못한다. 선택지가 question에서 빠진 조건을 보완하려면 그 선택지 자체가 빠진 조건의 이름과 내용을 구체적으로 밝혀야 한다. 조건 이름을 모든 선택지에 반복할 필요는 없다.

N2에서 `동시 출시 조건과 보안 규정을 변경할 수 없다`는 사실만으로 `예외 승인도 불가`라고 추론하지 않는다. 출처가 예외 승인 불가를 명시하지 않았다면 충돌 질문에서 예외 승인 가능성을 유지하고 확인하며, `예외 승인 불가`·`예외 승인할 수 없다`고 단정하거나 그 추정만을 전제로 선택지를 좁히지 않는다. 출처가 예외 승인 불가를 직접 명시했다면 그 제한을 그대로 보존한다. No-Go·출시 연기와 예외 승인 확인을 함께 선택지로 두는 것은 허용한다.

첫 질문은 현재 입력에서 식별된 미해결 고영향 빈칸 자체를 직접 묻는다. 이미 확정된 인접 조건이나 일반 책임 배치로 대체하지 않는다. 예를 들어 승인 필요·승인 시점·미승인 처리가 이미 정해졌다면 이를 구체 승인 절차·승인 확인·증적 확보 책임, 배포 시작 시각·30분 정상 판정 기준·경보 발생 조치의 질문 대신 사용하지 않는다. 이는 이미 식별한 슬롯을 보존하는 규칙이며 새 후보 발굴이나 고정 체크리스트 요구가 아니다. 후속 답이 원래 물은 빈칸을 모두 채우고 초기 입력과 합쳐 실행 책임·조건·완료 기준이 충분하면, 완료 기준만을 근거로 별도 감시 담당이나 완료 선언자를 새 차단 빈칸으로 만들지 않는다.

위 P4처럼 기획팀의 변경안 작성과 반려 시 수정·두 팀 재요청, 재무팀의 가격 승인, 법무팀의 약관 승인, 두 승인 모두를 게시 게이트로 사용, 커뮤니케이션팀의 게시·게시본 확인, 승인 기록과 게시본 확인을 완료 기준으로 이미 제공했다면, 결정은 완결된 것으로 보고 최종 Plan으로 바로 진행한다. 이때 `재무팀·법무팀의 승인 기록 작성과 게시 전 증적 확인은 누가 맡나요?` 같은 질문은 선택적인 미제공 구현 세부를 새 고영향 빈칸으로 만든 것이므로 차단 질문으로 만들지 않는다. 승인 기록은 완료 증거로 참조하되 새 기록 작성·취합·게시 전 증적 확인 책임자를 배정하지 않는다. 저장 위치·기록 방식·게시 전 증적 확인 절차는 생략하거나 비차단 `[확인 필요]`로 둘 수 있으며, 출처가 정한 팀 역할은 그대로 보존한다.


최종 Plan을 출력하기 직전에 다음 출처 스캔을 수행한다.

1. 실제로 물었던 고영향 질문마다 후속 사용자 답이나 확인 자료가 있는지 항목별로 대조한다.
2. 하나의 답을 질문 묶음 전체의 답으로 복제하지 않는다. 일부만 답했다면 나머지는 계속 미응답이다.
3. Plan의 사람·대상·날짜·기간·숫자·예산·권한·경로·정책을 사용자 입력·자료·외부 확인과 대조한다.
4. 출처가 없는 값은 생략하거나 `[확인 필요]`로 표시하고, 그 값이 결과 방향을 바꾸면 최종 Plan 대신 질문한다.
5. 명시된 결정 관계마다 시각 블록 또는 실행 상세의 대응 위치가 있는지 확인하고, 빠진 관계가 있으면 새 사실을 만들지 않는 범위에서 Plan을 보완한다.
6. 초기 요청 이후 새 사용자 답·새 자료·외부 확인이 하나도 없으면 자동 변화 추적과 자동 A 비교를 모두 생략한다. 안전 거절·비식별화만으로 변화 추적이나 A를 만들지 않고, 변화가 없다는 제목·표·설명도 만들지 않는다. 다만 사용자가 A 전문을 명시적으로 요청하면 result-contract의 안전·산출물 경계에 따라 제공한다.
7. N3처럼 사용자 입력이 처음 요청뿐이고 그 뒤 새 사용자 답·새 자료·외부 확인이 전혀 없으면, `AI 백서 변화 추적`·`조치·변화 추적`·A·delta 전용 제목·표·설명을 만들지 않는다. 입력에 이미 주어진 운영 승인·감사 기록 요건은 실행·검증에 그대로 둘 수 있지만 변화 추적으로 다시 이름 붙이지 않는다. 이때 입력이 제공한 기존 승인 시스템·읽기·쓰기 역할·3년 보존은 보존하되, 입력에 없는 실제 기록 수행자·서식·내부 저장 절차는 생략하거나 비차단 `[확인 필요]`로 둔다. `실제 수행자는 조직 절차에 따라 정함`, `기존 내부 서식과 저장 절차는 변경하지 않음`처럼 그 존재나 불변 상태를 단정하지 않는다. 민감정보 제외 규칙은 그대로 유지한다.
   N3에서 입력이 제공한 쓰기·읽기 역할은 승인 기록에 대한 접근 권한일 뿐 실제 저장 수행자·책임 주체 지정이 아니다. 역할별 접근통제와 승인 기록 저장 완료는 적용·검증할 수 있지만, `쓰기가 허용된 지정 역할`이나 `쓰기 권한이 있는 두 역할만`을 실제 저장 수행자·책임자로 이름 붙이거나 그 수행 범위를 해당 역할로 한정하지 않는다. 입력에 없는 수행자는 생략하거나 비차단 `[확인 필요]`로 둔다. `[확인 필요]`인 실제 저장 수행자를 실행 전에 반드시 지정해야 한다고 확정하지 않는다. 쓰기 허용 역할을 실제 저장 수행자의 후보 범위로 제한하지 않는다. `읽기·쓰기 권한만으로 새로 지정하지 않는다` 같은 면책 문장은 표·본문의 명시적 배정을 해소하지 못한다. 출처가 지정한 팀·역할은 그대로 보존하고 하위 역할을 만들지 않는다. 초기 입력뿐인 경우에는 `별도 변화 추적 산출물은 생성하지 않는다`처럼 생략 사실을 설명하는 메타 문장도 만들지 않고 조용히 생략한다. `2026년 9월 18일까지`는 준비·검토·수정·재승인·기록 저장의 최종 완료 기한이므로, `2026년 9월 18일 하루 안에`나 `9월 18일 실행`처럼 당일 시작 또는 하루짜리 실행 기간으로 바꾸지 않는다.
   N3의 날짜만 있는 최종 완료 기한 `2026년 9월 18일까지`는 그 날짜를 포함한다. `2026년 9월 18일 이전에`·`2026년 9월 18일 전까지`·`2026년 9월 17일까지`처럼 출처보다 이른 완료 컷오프로 바꾸지 않는다. 대상 날짜를 완료 기한·완료 관계에 반복할 수 있다. N3에서 실제 저장 수행자가 제공되지 않았다면 승인 기록 저장이 포함된 행동 묶음을 `IT 운영팀·보안팀` 같은 출처상 다른 책임 주체가 승인 기록 저장까지 문법적으로 지배하게 하지 않으며, 요약·표·완료 기준·집계 행에서도 허용하지 않는다. 행동을 분리하거나 저장 수행자를 비차단 `[확인 필요]`로 둔다. 접근 권한, 승인·반려 수정·재승인·검토 책임, 완료 검증은 출처가 지정한 주체에 그대로 둘 수 있다. 별도의 저장 수행자 `[확인 필요]` 행이나 면책 문장은 다른 행의 적극적 책임 배정을 해소하지 못한다. 기존 승인 시스템·읽기·쓰기 역할·3년 보존, 네 가지 고위험 권한, 여섯 기록 필드, 반려 당일 재승인 흐름은 그대로 보존한다.
   N3에서 사용자가 `비식별 목록 준비`만 제공했다면, 이를 원계정 연결·가역 매핑, 재식별 키·테이블, 토큰·가명 식별자 매핑 저장, 추적·재식별 내부 통제·정책이 존재하거나 유지된다는 단정으로 확대하지 않는다. 입력이 제공한 기존 승인 시스템·읽기·쓰기 권한·3년 보존·목록 버전·기록 필드는 그대로 보존한다. 구체 연결·재식별 방식이 필요하지만 출처가 없으면 생략하거나 비차단 `[확인 필요]`로 두며, 원계정 매핑·재식별 방식을 확정하지 않는다고 직접 밝힐 수 있다. 주변 면책 문장은 같은 답의 적극적 연결·통제 단정을 해소하지 못한다. 이 제한은 비식별 목록 자체, 비식별 식별자 또는 목록 버전 추적을 금지하지 않는다.
7. 정의되지 않은 라벨, 역할·계정·시스템의 등록·프로비저닝·설정·보호 상태와 다른 인접 상태 사실에 사용자 입력·자료·외부 확인 근거가 있는지 대조한다.
8. Plan 전체의 Mermaid·와이어프레임·Markdown 표 수를 세어 2개 이하인지, 두 번째 블록이 주 시각과 독립적인 관계인지 확인한다.
9. 입력에서 전체 행위자로 지정된 팀의 명칭과 전체 범위 책임이 요약·범위와 실행·검증에서 직접 확인되는지, 이를 앱·시스템·무주체·담당 미정으로 대체하지 않았는지, 읽기·쓰기 허용을 저장·확인 담당으로 확대하지 않았는지 확인한다.
10. 요약 바로 다음에 선택적인 시각 제목 외 설명 문단 없이 주 시각 블록이 오는지 확인한다.
11. 호스트 지시가 현재 응답의 Mermaid 지원을 명시적으로 보장했는지 확인하고, 보장이 없으면 Markdown 표·텍스트 와이어프레임·들여쓰기 흐름으로 대체한다.
12. 신규 API·데이터 경로와 필드를 설계했다면 `제안 인터페이스`임을 밝히고 기존 명명·충돌 확인 게이트를 두었는지, 근거 없는 영속화·해시·임시 저장·트랜잭션·멱등성·보존·로그 정책을 확정하지 않았는지 확인한다.
13. 사용자 근거가 없는 저장·보안·배포·관측 결정을 새 기본값이나 기존 정책으로 만들지 않았는지 확인한다.
14. 사용자가 모든 제품 결정의 확정 또는 제공된 동작 집합의 그대로 구현을 명시했다면, 입력에 없던 사용자 동작·분기·복구·수명주기나 토큰·식별자·상태 코드의 만료·재사용·저장·복구 의미, 동시성·원자성·멱등성 결정을 추가하지 않았는지 확인한다.
15. 닫힌 결정 집합이면 문장·필드 단위 삭제 검사를 수행해 허용된 구조·분해·제안 명명 외 내용이 사용자 입력·자료에 직접 추적되는지 확인하고, 추적되지 않는 내용은 삭제한다.
16. 닫힌 결정 집합이면 서버 필드·상태를 새 화면 표시·사용자 알림으로 확대하거나, 제공된 결과 행동을 근거로 인접 API 계약을 `기존`이라고 단정하지 않았는지 확인한다. 제공된 서버 타이밍·상태 전이를 직접 검증하는 구현·QA 분해와 기존 명명·충돌 확인을 둔 제안 인터페이스는 삭제하지 않는다.
17. 사용자 입력의 의미 필드 라벨이 대상 의미를 유지하는지 확인한다. 제안 별칭이 단독 `link`라면 필드 설명에 약관 본문 링크라는 뜻을 직접 남긴다.
18. 사용자가 핵심으로 지정한 모든 예외 분기가 주 시각에 있고 상세·QA에만 남지 않았는지 확인하되, 사소한 분기까지 주 시각에 추가하지 않는다.
19. 닫힌 결정 집합의 재발송에서 입력에 없는 UI 잠금 해제·재활성화·새 코드 입력 상태를 추가하지 않았는지 확인한다. 제공된 서버 발급·만료·응답·rate-limit의 직접 구현과 검증은 보존한다.
20. 현재 입력에서 이미 식별된 서로 독립적인 고영향 빈칸을 첫 질문 묶음에서 빠뜨리지 않았는지 확인한다.
21. 초기 입력과 후속 답의 명시 관계가 최종 B에 각각 직접 보존되고, 준비 완료 상태가 새 작업이나 미완료 상태로 바뀌지 않았는지 확인한다.
22. 책임 변화의 세 인과 필드에서 같은 책임 주체와 책임 행동이 이어지며 승인자와 증적 확보·제출자를 근거 없이 합치지 않았는지 확인한다.
23. 입력에 없는 롤백 후 재배포 절차·일정을 새 기본값으로 확정하지 않았는지 확인한다.
24. 특정 횟수·범위·분기의 규칙을 `모든`·`어떤` 같은 전칭 표현으로 넓혀 다른 분기나 실패 유형에 적용하지 않았는지 확인한다.
25. 사용자가 완료일과 완료 행동을 한 관계로 지정했다면 텍스트 전용이 아닐 때는 주 시각의 같은 단계·행·셀에서, 텍스트 전용일 때는 같은 실행 단계나 문장에서 날짜와 행동이 직접 연결되는지 확인한다.

`텍스트로만` 요청이나 사용자의 `추가 질문 없이` 요구도 이 스캔을 끄지 않는다.

다음을 수행하거나 수행했다고 주장하지 않는다.

- 호스트의 Plan mode 전환, 플랜 탭·패널의 생성·배치·크기 조정
- Figma, 생성 이미지, 외부 Visualize 기능이나 별도 파일을 사용한 시각화
- AI 백서 자체의 새 공개 API, 명령, 설정, 데이터 타입, MCP 또는 UI capability를 추가하거나 이미 제공한다고 주장

배포·인증의 조건·역할·시간·필드 보존은 [공통 관계 계약](result-contract.md#조건역할시간필드-관계-보존)을 따른다. 사례의 세부 수치와 고정 문구를 일반 업무로 확대하지 않는다.