범위는 실행 전에 도착해
brief 는 작업하면서 뜻을 발견하는 일기장이 아니야. 요청자가 허가한 목표, 바꿔도 되는 대상, 건드리면 안 되는 대상, 결과물 목적지, 완료 증거를 물질화한 작업 지시서야. 다른 session 이 원래 대화를 못 봐도 권한을 복구할 수 있어야 해.
범위를 입력이라고 부르면 plan gate 역할도 선명해져. gate 는 그 경계 안에서 방법을 제안하고 위험과 proof 를 보여줘. “정규식 대신 parser 를 쓴다”는 방법 변화지만 “셋째 파일도 같이 고친다”는 전제 변화야. 둘을 한 문장에 섞으면 승인 범위가 미끄러져.
실행 중 새 사실이 나오는 건 정상이고, 그래서 visible amendment 가 필요해. 허용 대상 밖에 같은 결함을 발견했다면 영향과 선택지를 기록하고 요청자에게 전제를 돌려줘. 승인되면 새 delegation 이나 보이는 수정으로 이어가고, 아니면 원래 경계에서 멈춰.
attachment 와 예시가 많아도 입력일 수 있어. 핵심은 작음이 아니라 닫힘이야. package 만 읽고 어떤 authority 가 이동했는지 알 수 있으면 되고, 다시 product discovery 를 열어야 한다면 아직 scope 가 아니야.
전제와 방법을 갈라
현재 plan 의 모든 문장을 두 칸으로 분류해봐. target·exclusion·destination·proof 는 전제 쪽, tool·sequence·implementation choice 는 방법 쪽이야. 분류 못 하는 문장은 대개 scope 확장을 method 안에 숨기고 있어.
수정이 필요한 순간
작업 중 새 사실이 나왔다고 해보자. 허용 대상 둘만 고치려 했는데 셋째 파일에도 같은 결함이 보여. 그 파일까지 고치는 게 기술적으로는 맞아 보여도 범위 입력은 자동으로 늘지 않아. 실행자는 발견과 영향, 두 선택지를 기록하고 요청자에게 전제를 다시 돌려줘야 해. 승인되면 보이는 수정으로 브리프를 갈거나 새 위임을 만들고, 승인되지 않으면 원래 경계에서 멈춰. 이 절차가 느려 보이는 순간이 바로 소유권이 실제로 작동하는 순간이야.