작업 상태와 완료 보고 읽기

한국어 · English

작업이 멈춘 이유를 알고 싶거나, 완료 보고가 무엇을 근거로 하는지 자세히 확인하고 싶을 때 읽습니다. 시작 전 점검, 수정 전 실패가 뜻하는 것, 완료 보고의 근거, 사용자 확인이 필요한 상태(needs_user), 막힘과 예산, 보증 정책을 다룹니다. 처음 쓰는 사람을 위한 호출·재개·문제 해결은 사용 안내에 있습니다(English). 설치와 버전 확인은 설치 안내를 봅니다.

이 문서는 v0.1.8(ha 0.1.8·spar 0.1.8·spec 0.1.13·seal 0.1.23·spar 플러그인 0.1.4)의 실행 전 진단·지원 확인, nested/1, /3 결과와 횟수 총상한 변경을 설명합니다. 기존 목표는 저장된 규칙과 형식을 유지합니다. 배포판과 소스 빌드의 차이는 버전별 적용 범위에 있습니다.

목표 맡기기#

Spec은 요청을 docs/specs/<goal>/SPEC.md에 목표·범위·완료 조건으로 정리하고 보고한 뒤 멈춥니다. 결과를 바꾸는 질문에 답하거나 고칠 것을 말해 목표를 다듬습니다. Status: Ready는 문서가 준비됐다는 표시이며 구현을 시작하지는 않습니다.

준비되면 Codex 대화에서 $ 목록의 seal:seal을 골라 별도 메시지로 $seal:seal docs/specs/<goal>을 보냅니다. Claude Code에서는 /seal:seal docs/specs/<goal>을 씁니다. 이미 목표 문서가 있다면 바로 Seal에 맡겨도 됩니다. 에이전트가 계획·검사 방법을 검토하고 구현·검사·수정을 이어 갑니다. 매 작업마다 승인할 필요는 없습니다.

목표와 범위를 바꿀지는 사용자가 정합니다. Seal은 목표 문서를 고치지 않습니다. Spec으로 목표를 고쳤다면 별도로 docs/specs/<goal> 이어서 해줘라고 요청합니다. 자세한 문서 형식은 목표 문서 계약과 실행 묶음 계약에 있습니다.

도구 미리 점검하기#

검사가 브라우저나 외부 도구를 쓰면, 검사를 실제로 돌리기 전에 그 도구가 있는지 확인합니다. PLAN의 ## 실행 환경 절에 - <이름>: `<점검 명령>` 형식으로 도구를 적고 ha doctor <goal>을 실행합니다. 결과는 도구마다 사용 가능 또는 사용 불가이고, 사용 불가의 이유는 실행 파일 없음, 실행 권한 없음, 시간 초과, 0이 아닌 종료, 신호로 종료 중 하나입니다. 점검은 하나에 60초까지이며 기록과 예산에 들어가지 않습니다. ha doctor는 도구를 설치하지 않습니다. 사용 불가인 도구는 검사 전에 설치하거나 경로를 고칩니다.

실행 전에 확인할 것#

Seal은 기록을 남기기 전에 세 가지를 봅니다. 설치된 ha가 필요한 기능을 갖췄는지, 예산이 충분한지, 작업 트리에 커밋하지 않은 변경이 없는지입니다. 하나라도 어긋나면 멈추고 이유를 알립니다.

Core 지원#

Seal 0.1.20부터는 Core 지원을 손으로 대조하지 않습니다. skill 폴더의 core-requirements.json에 필요한 지원을 선언하고 ha start --check-skill로 시작하며, 빠진 지원이 있으면 ha가 기록 없이 거부합니다. Seal은 실행 파일과 메시지를 알리고 멈춥니다.

• Seal 0.1.21은 run-rules/5와 검토 gate 지원도 요구합니다.
• 설치된 ha가 run-rules/5나 Seal이 요구하는 다른 지원을 모르면 Seal은 기록 없이 멈추고 이전 규칙으로 물러나지 않습니다. 할 일은 그 지원을 갖춘 ha를 설치하는 것입니다.
• 이미 시작한 목표는 각 명령이 저장된 규칙을 계산하거나 66으로 거부합니다.

Seal 0.1.26은 새 목표에 run-rules/6을 요구하고 ha start --rules run-rules/6 … --check-skill로 시작합니다. 형식·기능 요구는 0.1.21과 같고 규칙만 바뀝니다. ha 0.1.8은 /6을 지원하지 않으므로 이 시작을 거부합니다. /6이나 다른 필수 지원이 없으면 Seal은 기록 없이 멈추고 이전 규칙으로 물러나지 않습니다. 해당 지원을 갖춘 ha가 필요하며, 이미 시작한 /1~/5 목표는 저장된 규칙을 유지합니다.

Seal이 --skill로 가리킨 skill 폴더에 core-requirements.json이 있으면 start가 그 skill에 필요한 Core 지원을 실제 실행 파일과 대조하고, 빠진 지원이 있으면 기록 없이 거부합니다. --check-skill을 함께 주면 그 선언이 필수이고, 이 기능 전의 ha는 그 시작을 받지 않습니다(Core 지원 정보 계약 §8).

그 전 Seal(0.1.17~0.1.19)의 지원 확인

아래는 그 전 Seal(0.1.17~0.1.19)의 확인입니다.

Seal은 실제 사용할 Core의 절대 경로를 정하고 그 실행 파일의 capabilities --format json을 읽습니다. 새 시작은 이해하는 기본 규칙과 필요한 지원이 모두 있어야 하며, 기존 목표는 저장된 규칙과 요청한 동작을 기준으로 확인합니다.

조회 미지원·실패·잘못된 정보·부족한 기능이면 기록 전에 멈추고 대상과 이유를 설명합니다. 다른 실행 파일의 조회 결과를 재사용하거나 /1·/2로 바꿔 시작하지 않습니다. 경로나 실행 파일 내용이 바뀌면 다시 확인합니다. 정확한 필드는 Core 지원 정보 계약에 있습니다.

이 지원 확인은 자동 설치·권한 확대·과거 기록 변경으로 우회하지 않습니다. 업데이트 뒤에도 실제 선택된 실행 파일의 지원 정보를 다시 읽습니다.

Python 호환 도우미는 선택 사항이며, Python이 없어도 실제 지원 정보와 같은 계약을 직접 확인할 수 있습니다. Spec의 문서 작성에는 Core나 이 조회가 필요 없습니다. 설치된 Codex·Claude 모델이 지침을 실제로 따르는지는 별도 호스트 평가 대상이며, 지원 정보 출력만으로 보증하지 않습니다.

예산과 도구#

• 예산이 없으면 검증 실행: 자동으로 시작하고 승인이 필요할 때만 한 번 묻습니다.
• 검사에 필요한 도구는 baseline 전에 ha doctor로 점검하고 사용 불가인 도구를 한 질문으로 묻습니다.

에이전트는 ha estimate docs/specs/<goal>로 PLAN의 최소 검증량과 상한을 비교할 수 있습니다. 예를 들어 run-rules/6까지는 필수 change가 34개면 수정 전·후 각 한 번씩 최소 68회가 필요합니다. manual은 검사 실행 수에 포함되지 않습니다.

기본 비교 검증에 포함되는 선택 조건과 명시적으로 선택한 AC·EX·task 명령의 추가량도 따로 표시합니다. --baseline은 비교 검증 선택량을, --format json은 기계가 읽는 출력을 제공합니다.

PLAN에 - 검증 실행: 자동을 쓰면 start가 max(50, ⌈필수 최소량 × 1.5⌉)로 상한을 정합니다.

• 그 값이 사용자 설정 폴더(~/.config/jaekit/, XDG_CONFIG_HOME이 있으면 $XDG_CONFIG_HOME/jaekit/)의 ha.json에 적은 preapproved_runs 이하이면 묻지 않고 시작합니다. 파일이 없으면 그 상한은 50입니다.
• 넘으면 start가 exceeds the pre-approved limit로 기록 없이 멈추고 사용자의 승인을 기다립니다.
• 파일을 쓸 수 없으면 pre-approved run limit 오류로 멈추며 50으로 대신하지 않습니다.

형식과 예시는 사용 안내에 있습니다.

상한이 필수 최소량보다 작으면 start는 기록을 남기기 전에 거부합니다. 기존 허용 범위에서 목표를 나누거나 시작 전에 충분한 예산을 결정합니다. 추정치에는 재시도와 준비 시간이 들어 있지 않습니다. 진행 중 목표에서 조회하면 현재 PLAN을 설명할 뿐이며 이미 기록된 상한이나 잔여량을 늘리지 않습니다.

커밋하지 않은 변경#

검증 전에 uncommitted changes로 거부되면 출력된 경로를 확인합니다.

• tracked는 Git이 이미 관리하는 파일의 변경이므로 작업 의도에 따라 commit하거나 되돌립니다.
• untracked dependency symlink는 링크 자체의 경로를 보고 보관·제외 여부를 판단합니다. 예를 들어 apps/web/node_modules가 표시되면 그 경로의 ignore 규칙을 검토합니다.

안내만으로 모든 node_modules를 제외하거나 파일을 자동 정리하지는 않습니다.

거부된 검사는 실행 횟수에 들어가지 않습니다. 여러 검사를 실행하다 멈췄다면 앞서 실행한 결과와 사용량은 남으며 출력에서 몇 개가 실행됐는지 알 수 있습니다. ha status의 worktree_dirty에도 경로와 유형이 나옵니다. Git 조회 실패는 깨끗한 상태로 취급하지 않습니다. 문제를 고친 뒤 검증을 다시 실행합니다.

목표 문서의 조건 형식#

새 Spec 예시는 Criteria-Format: nested/1을 명시해 AC 아래의 설명 목록을 같은 조건의 본문으로 읽습니다. 표시가 없는 기존 목표는 기존 해석을 유지합니다.

기존 목표에서 표시를 추가하면 목표 문서가 변경되므로 이전 검증과 수동 확인을 새 해석에 재사용하지 않습니다. 들여쓰기 예시는 목표 문서 계약을 참고합니다.

수정 전 실패가 뜻하는 것#

run-rules/6까지는 모든 change 조건의 검사가, run-rules/7에서는 표시한 change 조건의 검사가 바꾸기 전에 의도한 위반을 보여야 합니다. 명령이 실패했다는 사실만으로 수정 전 근거가 되지는 않습니다.

change 검사는 선언한 대상과 요구 위반을 구조화 결과로 연결해야 합니다.

• 누락된 의존성, import·수집·브라우저 기동 오류, 미실행·skip, 의미를 알 수 없는 스크립트 실패는 기대 실패로 인정하지 않습니다.
• 실제 실행한 검사가 기능 부재를 직접 관측한 결과는 구분할 수 있습니다.

baseline을 기록할 때는 선언한 모든 대상이 실행돼야 하며 의도한 위반이 있고 오류나 다른 assertion 실패가 없어야 합니다. baseline 요구 여부와 관계없이 현재 검사는 선언한 대상 전체의 통과가 필요합니다.

결과 계약과 참조 검사에 연결 방법이 있습니다. 참조 검사는 파일을 실제로 읽는 작은 예시이며 특정 테스트 러너를 자동 설치하거나 모든 러너를 지원하지 않습니다.

이미 있는 시험에 연결하기#

이미 있는 시험을 그대로 쓰고 싶다면, ha capabilities에 check-adapter/v1이 있는 Core에서 러너 어댑터로 change 조건을 그 시험 하나에 연결할 수 있습니다. 생산자 프로그램 없이 go test -json …의 출력이나, 러너가 {HA_JUNIT_XML} 위치에 쓴 JUnit XML을 ha가 직접 읽습니다.

성질이 깨졌을 때의 assertion 실패 메시지 첫 줄에 jaekit:violation=<위반 식별자> 표식을 넣습니다. 예를 들어 가상의 인사 CLI 시험이라면 t.Fatalf("jaekit:violation=greeting-missing the CLI says %q", got)처럼 씁니다.

표식이 없거나 로그·표준 출력에만 있는 실패는 의도한 위반으로 인정하지 않습니다. 어댑터는 선택이며 지원이 없으면 참조 검사나 전용 생산자를 씁니다.

오류와 재시도#

error와 판정 불가는 제한된 오류 재시도에 함께 포함됩니다. 실제 시도한 실패·오류·stale와 사용량은 남습니다. 뒤의 통과만으로 같은 입력에서 나온 불리한 결과를 지우지 않습니다.

상태에 나온 이유와 해당 ha log를 보고 검사·제품·환경 중 무엇이 달라져야 하는지 판단합니다.

규칙 버전(run-rules)별 차이

Seal 0.1.16부터 새 목표를 run-rules/4로 시작합니다. 0.1.21부터는 run-rules/5로 시작하며, /5는 /4를 모두 지키고 standard·strict 목표에 검토 gate를 더합니다. /4는 /3의 결과 규칙을 그대로 지키고, 오류 회복을 포함한 자율 처리를 더합니다.

Seal 0.1.26은 run-rules/6으로 시작합니다. /6은 /5의 네 판정만 바꿉니다.

• standard·strict 목표의 마지막 candidate 라운드(dry run 제외)가 시작 base_commit부터 검토하지 않았으면 review_base_mismatch로 완료를 막습니다. 시작 base부터의 candidate 뒤 fixes 사슬은 Spar의 gate가 확인합니다.
• 완료 뒤 review note는 현재 등급이 standard·strict일 때만 완료 기록을 무효로 합니다. light이거나 등급 줄이 없으면 다른 조건이 유효한 완료 기록을 유지합니다.
• record_head가 앞선 줄의 hash이고 그 줄과 done 줄 사이에 발견 줄(run-finding/v1)만 있거나 아무 줄도 없으면, 그 done 줄은 판정한 줄입니다. record_head가 가리키는 줄 자체는 발견 줄이어도 됩니다. 모든 done 줄은 전체 기록에서 먼저 판정하므로, record_head가 판정하지 않은 줄을 가리켜도 판정한 줄이 될 수 있습니다. 그런 다음 판정하지 않은 done 줄은 완료 여부와 관계없이 상태 계산에서 없는 것으로 취급합니다. 완료 기록과 그 설명, 최신 done 줄, 예산 창, 경과 시간, 완료 뒤 구간, 예산 변경 거부가 모두 이에 따르며 상태·보고·비용·예산 변경은 같은 뷰를 씁니다. 앞의 기록도 다른 유효성 조건을 만족해야 하며, 판정했지만 다른 이유로 무효인 줄에서는 이전처럼 멈춥니다.
• 완료 뒤 다음 실행이나 완료가 아닌 done까지의 구간을 경과에서 빼고 post_completion_seconds로 따로 보입니다. 아래 예산 설명과 계약 §4.9에 경계가 있습니다.

/1~/5로 시작한 기존 목표는 종전 판정을 유지하며 자동 이전되지 않습니다.

baseline 선택과 검사 동결 (run-rules/7)#

현재 Seal은 새 목표를 run-rules/7로 시작합니다. 지원하지 않는 Core에서는 기록 없이 멈추며 이전 규칙으로 물러나지 않습니다. 직접 실행하는 ha start의 기본 규칙은 run-rules/3 그대로이고, 이미 /1~/6으로 시작한 목표의 판정·출력·기록은 바뀌지 않습니다.

PLAN 조건표의 선택 baseline 열에 요구를 적은 change 조건만 baseline을 요구합니다. 빈 칸·—나 열이 없으면 요구하지 않습니다. 버그 수정·회귀·"X가 일어나지 않는다"·base에서 일부가 이미 충족된 조건처럼 거짓 통과 위험이 있는 조건을 고르고, 이유를 plan 라운드 전에 REVIEW에 적습니다. 표시하지 않은 change 조건도 검사 경로와 구조화 결과 계약은 필요하지만, base에도 있는 진입점에 묶을 필요 없이 새 함수의 시험에 연결할 수 있습니다.

필수 최소량은 표시한 필수 change × 2 + 표시하지 않은 필수 change + 필수 maintain입니다. manual은 0회입니다. 표시한 change 1개, 표시하지 않은 change 4개, maintain 3개가 모두 필수라면 최소 9회이고, 자동 상한은 max(50, ⌈9 × 1.5⌉) = 50입니다. 시작 전에는 ha estimate <goal> --rules run-rules/7로 이 값을 봅니다. 시작한 목표는 저장된 규칙을 쓰며 다른 --rules를 주면 거절합니다.

대상 없는 ha check <goal> --baseline은 표시한 change 조건만 고릅니다(표시한 선택 조건도 포함). 표시가 하나도 없으면 기록 없이 거절합니다. 표시하지 않은 조건을 직접 지정해 baseline을 실행할 수도 있고, 실제 실행은 예산에 셉니다. 그 baseline의 신선한 불리한 결과도 판정에 남습니다. 표시한 조건의 baseline은 검사 파일이 정해진 뒤 한 번 기록하도록 계획합니다. 검사 수정마다 기록하는 습관을 줄이자는 안내이며, 이미 낡은 근거를 신선하게 만드는 예외가 아닙니다.

/7에서 "baseline 전" 질문 모으기·ha doctor·strict의 plan 라운드는 baseline이 없는 목표에서도 현재 검사나 baseline 어느 쪽이든 첫 ha check 기록 전에 마칩니다. 시작 전에 알 수 있는 질문을 모으되, 물을 것이 없으면 바로 일합니다.

• 입력 실패인 대상 파일 없음, 손상된 입력, 시작하지 못하는 도구, 신호 종료는 통과가 아니다.
• baseline을 요구하지 않는 검사(maintain, EX-n, task 명령, 표시하지 않은 change 조건)는 입력 실패를 위반, 오류, 판정 불가 중 하나로 세어도 그것만으로 검사의 결함이 아니다. 위반으로 기록된 실패는 입력이 달라질 때까지 남는다.
• baseline을 요구하는 change 조건의 전용 생산자는 입력 실패를 위반으로 보고하지 않는다. 결과 계약이 허용하는 경우(예: missing: violation)는 예외이며 그 선택은 plan 라운드 전에, plan이 없으면 어떤 검토 라운드보다도 전에 REVIEW.md에 적는다.

baseline을 요구하는지는 규칙에 따라 읽습니다. run-rules/6까지는 모든 change 조건이 요구하고 /7은 표시한 조건만 요구합니다. 러너 어댑터는 입력 실패를 스스로 분류하며, 결과 계약의 분류와 입력 실패 표는 바뀌지 않습니다.

검사 동결 시점은 기록된 마지막 gate의 dry run이 아닌 라운드 중 strict의 첫 plan 라운드 또는 standard의 첫 candidate 라운드입니다. 조건표에서 검사 경로를 적은 모든 행의 경로에 있는 선언·생산자·시험·도우미·설정이 대상입니다. Seal은 동결 라운드 바로 뒤 ha note <goal> review --gate <file>로 gate와 그때 조건표의 검사 경로를 기록합니다. 동결 라운드에서 끝난 gate note가 없으면 뺀 검사 경로를 관측할 수 없고, 상태와 보고에 동결 때의 조건표가 기록되지 않음이 나옵니다.

동결 뒤 검사 파일을 고치면 commit하고 ha note <goal> check-change checks:<path> --reason "<지적 ID, 또는 조건과 이유>"로 까닭을 남깁니다. 검토 지적을 고친 변경이면 그 지적 ID를 씁니다. 까닭은 지금 blob에 묶이므로 파일을 다시 바꾸면 그 변경의 까닭도 다시 남깁니다. 다음 코드 검토 라운드에 바뀐 검사와 까닭을 함께 줍니다. 동결 전 변경에는 이 까닭이 필요 없고, 동결 뒤에도 검사 결함을 고칠 수 있습니다. 동결 표시는 자체로 완료를 막거나 plan-delta를 요구하지 않습니다.

ha status는 change 조건마다 baseline_required와 사람용 baseline required 줄을 보입니다. ha report의 확인한 것은 모든 change 조건 중 baseline을 요구한 수와 그중 신선한 baseline 수를 나눠 보입니다. 직접 볼 것에서 시작 뒤 뺀 baseline 표시, 동결 뒤 바뀐 검사 파일과 까닭, 까닭 없는 변경을 읽습니다. 뺀 경로에는 비교에 쓴 review note seq가 붙습니다. light나 기록된 gate가 없는 목표에는 동결 표시가 없고, 검수 요약의 ### 보지 않은 것에는 baseline 없이 충족한 change 조건을 적습니다. 실행 기록 계약 §4.10에 정확한 필드와 표시가 있습니다.

완료 보고 읽기#

완료 보고는 목표 폴더의 PROGRESS.md와 대화에 함께 나옵니다. 다음을 확인합니다.

1. 무엇이 바뀌었는가. 실제 파일·화면·동작이 요청과 맞는지 봅니다.
2. 필수 조건이 어떻게 충족됐는가. 자동 검사 결과와 직접 확인한 항목을 구분합니다. 선택 조건은 완료를 막지 않으며 따로 표시합니다.
3. 검사가 무엇을 다뤘는가. 새 동작을 확인한 검사, 유지해야 할 동작, 확인하지 못한 범위를 봅니다. 검증 명령이나 조건 종류를 바꿨다면 이유를 확인합니다.
4. 가정과 한계가 무엇인가. 에이전트가 정한 가정이 의도와 맞는지, 남은 한계가 결과에 영향을 주는지 봅니다.

완료의 근거는 ha done이 남긴 완료 기록입니다. 터미널에서 ha status <goal>로 현재 목표와 기록에 따른 상태를 확인할 수 있습니다. <goal>은 docs/specs/login-link처럼 실제 목표 폴더 경로로 바꿉니다.

Seal 0.1.20 이상으로 시작한 목표의 완료 보고는 ha report의 출력을 그대로 붙이므로, 맨 위 다섯 줄을 먼저 읽고 아래에서 완료 기록과 Seal의 판단 문장을 봅니다. 0.1.24 이상으로 시작해 완료한 목표에서는 판단 문장이 ## 검수 요약에 있습니다. ha report <goal> --lang ko는 같은 기록을 바뀐 것, 확인한 것, 직접 볼 것, 남은 한계, 다음 행동 다섯 줄로 요약합니다. ha status와 같은 계산이고 기록을 바꾸지 않습니다. 요약 아래의 도장은 PROGRESS.md의 ## 현재가 어느 기록 head를 기준으로 쓰였는지 맞춰 볼 때 씁니다.

검수 요약. 0.1.24 이상으로 시작한 목표에서는 완료 기록 뒤 ## 현재 바로 다음의 ## 검수 요약이 검수를 시작하는 곳입니다. 맨 위 줄에 완료 기록, 보증 등급, 충족한 필수 조건 수, 검토 gate 결과, 이 변경이 하는 일, 먼저 볼 것이 있고, 그 아래에 바뀐 동작과 파일, 범위 밖이나 기존 것을 바꾼 곳, 근거, 누가 정했나, 직접 볼 것, 보지 않은 것, 자세히가 이 순서로 옵니다. 해당하는 것이 없는 항목에는 없음을 쓰고, 목표를 다시 열어 완료를 다시 기록하면 새 완료 기록 기준으로 다시 씁니다. 사용자의 언어로 쓰고, 기록은 무엇인지를 먼저 쓰며, 항목마다 짧게 쓰고 seq는 보조로만 붙입니다. 검증 출력과 지적 원문은 옮기지 않고 지적은 ID, 한 줄 요약, 끝만 적습니다. Seal의 판단은 이 절에만 있고, ## 완료 보고에는 ha report 출력과 이 절을 가리키는 한 줄이 있습니다. 완료한 목표는 ## 검수 요약부터 읽습니다. 멈춘 목표와 그 전 Seal로 시작한 목표는 지금처럼 ## 완료 보고를 읽습니다.

보증 수준 local은 해당 컴퓨터에서 얻은 근거라는 뜻입니다. 검사는 실행한 에이전트가 작성하며 같은 사용자 권한으로 파일과 기록을 바꿀 수 있습니다. 결과 전체의 무결함이나 독립된 제3자의 보증을 뜻하지 않습니다.

빠진 것이 있으면 무엇을 고칠지 말합니다. Seal이 사용자 요청을 인용한 reopen을 기록하고 재작업합니다. 이전 완료 기록은 현재 완료 근거로 쓰이지 않으며 새 예산 창이 열립니다. 목표 문서부터 바꿔야 한다면 Spec으로 고친 뒤 별도로 계속하라고 요청합니다.

검사 출력 원문이 필요하면 터미널에서 ha log <goal> <seq>로 봅니다. <seq>는 보고에 나온 기록 번호입니다. 실행 뒤 출력 저장이 실패한 process_output 기록은 실제 시도와 사용량이 남아도 원문 경로가 비어 있을 수 있습니다. 기록 저장 오류로 적용 여부가 불확실하다면 성공으로 단정하지 않고 저장 상태를 확인합니다. 보존된 원문은 해당 작업 트리의 Git 디렉토리 아래 ha/에 있고 Git이 추적하지 않습니다(저장되는 파일).

needs_user 처리#

에이전트가 정할 수 없는 항목이 남으면 이유와 함께 묻습니다. 필요한 판단을 하고 답하면 그 답이 기록됩니다.

막힘과 예산#

• blocked: 인증 만료, 권한 거부, 사용량 한도 등으로 멈춘 상태입니다. 에이전트가 남긴 해소 조건을 읽고 원인을 해결한 뒤 계속하라고 합니다.
• budget_exhausted: 검사 횟수나 경과 시간의 예산을 넘은 상태입니다. 남은 일과 어떤 한도를 넘었는지 보고 더 쓸지 정합니다.

/4 이상은 아래 /3의 예산 규칙을 따르면서 사전 승인한 상한, 신고한 대기, 재개한 창의 상한을 따로 정합니다. 그 차이는 자율 처리와 실행 기록 계약을 봅니다. run-rules/6은 완료 뒤 시간도 아래처럼 뺍니다.

/3에서 횟수만 더 쓰려면 현재 창의 총상한을 변경합니다. 사용량 48회·상한 50회에서 상한을 100회로 바꾸면 사용량 48회·잔여 52회입니다. 40회로 줄이면 잔여 0회·초과 8회이며 쓴 기록은 사라지지 않습니다. 증액에는 그 한도를 허용한 사용자 원문과 요청 문맥, 감액에는 이유가 남습니다. 짧은 “좋아”도 무엇에 동의했는지 문맥이 있으면 형식만으로 거부하지 않습니다. 인용 출처를 확인하지 못했다면 에이전트가 기록한 주장입니다.

상태의 창 번호·예산 개정·현재 상한에 연결해 변경하므로 다른 변경이나 재개와 충돌하면 자동으로 덮어쓰거나 합산하지 않습니다. 현재 상태를 다시 확인해 결정합니다. 저장 오류가 적용 불확실성을 알리면 다시 적용하기 전에 기록을 확인합니다. 정확한 명령과 필드는 제품 계약에 있습니다.

이 변경은 새 창을 열지 않고 시간 상한·경과 시간·실패·오류 한도·막힘을 초기화하지 않습니다. 시간 상한 변경은 지원하지 않습니다. PLAN을 고치는 것만으로 진행 중 상한은 바뀌지 않습니다. 완료된 창은 명시적 재작업·재개가 필요하며 /3의 새 창은 최신 횟수 상한과 기존 시간 상한을 이어받습니다. /1·/2는 기존처럼 사용자 발화를 인용한 reopen으로 최초 상한의 새 창을 엽니다.

예산 창은 마지막 시작이나 reopen부터 마지막 실행 예산 대상 기록 시각까지입니다. 발견 줄은 예산 입력에서 빠집니다. 상태 조회만으로 시간이 늘지는 않지만 예산 변경을 포함한 새 기록이 붙으면 창이 늘어납니다. /4·/5는 창 길이에서 신고한 대기를 빼고, run-rules/6은 완료 뒤 구간도 뺍니다. 재개를 걸쳐 실행한 검사는 기록된 창에 계산됩니다. 검사·baseline의 실제 시도, 오류·판정 불가, 유효·stale는 서로 다른 집계 축입니다. baseline도 사용량에 포함됩니다.

run-rules/6의 완료 뒤 구간은 판정한 complete done의 at부터, 그 at과 같은 초나 그 뒤에 시작한 검사·baseline의 가장 이른 started_at이나 완료가 아닌 done의 at 가운데 이른 시점까지입니다. 완료 전에 시작해 그 뒤 기록된 실행은 구간을 끝내지 않습니다. 둘 다 없으면 창의 마지막 예산 기록에서 끝납니다. 다른 완료 done은 구간을 이어 가고, note와 발견 줄은 끝내지 않습니다. 실행 구간은 경과에 남고 신고 대기와 겹친 시간은 한 번만 빠집니다. 추가로 뺀 초가 budget.post_completion_seconds이며 elapsed_seconds = span_seconds - reported_wait_seconds - post_completion_seconds입니다. 사람용 상태의 Budget 절과 ha cost JSON의 예산 창에도 이 초를 따로 보이고, ha report의 남은 한계와 ha cost는 같은 경과를 씁니다. 완료 뒤 첫 실행 전의 작업 시간도 빠지므로, 코드 재작업은 사용자 요청을 인용한 reopen으로 새 창에서 진행합니다. 실행 횟수·상한과 완료 창의 예산 변경 거부는 그대로입니다.

도달은 사용량과 상한이 같은 경우이고 초과는 실제로 넘은 경우입니다. 완료 기록이 있는 목표는 시간이 지나도 예산 초과 상태가 되지 않습니다. /2~/7은 필수 조건이 모두 충족되고 예산 초과만 남았으면 완료를 기록할 수 있습니다. 이는 추가 실행 권한이 아니며 예산은 검사 실행을 자동 차단하거나 진행 중 검사를 종료하는 장치도 아닙니다.

새 대화에서 이어 가기#

같은 프로젝트 폴더에서 새 대화를 열고 docs/specs/<goal> 이어서 해줘라고 보냅니다. Seal이 목표·계획·진행 기록과 현재 상태를 읽고 남은 일을 이어 갑니다. 사용자 판단이 필요한 항목이 남아 있으면 먼저 답합니다.

검증 근거 보고#

Seal 0.1.10부터 도입된 보고 형식은 기대 결과의 근거, 실제 관측 경계, 시험 방법과 대체 환경을 구분합니다. 같은 근거는 조건 그룹으로 참조할 수 있습니다. 검토에는 예정, 완료·중단 보고에는 실제 결과와 미관측·남은 위험을 남깁니다. 실제 실행은 정답 근거 자체가 아니며 fake 결과가 실제 모델 관측으로 바뀌지 않습니다. 시각 출처와 판단을 바꾼 새 사실도 구별합니다.

기존 목표는 시작 형식을 유지하고 누락된 새 항목은 미기록입니다. 과거 완료를 덮어쓰거나 관측을 채우지 않습니다. 이 보고 형식은 Seal 0.1.12부터 포함되며 현재 배포판 v0.1.8에도 들어 있습니다. 가상 보고 예시를 참고하세요.

보증 정책#

필요한 독립 검토·실제 경계 근거가 없으면 완료 보류하며, 무관한 작업은 계속할 수 있습니다.

Seal 0.1.20부터는 SPEC의 Assurance: 등급이 독립 검토 단계를 정합니다.

• standard는 최종 후보·수정·누적 라운드, strict는 baseline 전 plan 라운드를 더하고, light는 이유를 남기고 생략할 수 있습니다.
• 프로젝트 지침이 더 많은 검토를 요구하면 그쪽을 따릅니다.

독립 검토가 필요한 목표는 마지막 head 전체를 본 누적 라운드가 열린 지적 없이 끝난 뒤에만 ha done을 실행합니다(사용 안내).

보증 정책의 범위와 가상 사례

Seal 0.1.11부터 도입된 보증 정책은 목표나 프로젝트가 명시한 보증 정책의 필수 범위를 조건에 연결합니다. 선택 비교는 미관측과 한계를 남깁니다. 모델·실행 순서는 실행자가 정하고 Core는 검토 동의를 충분성으로 판정하지 않습니다.

가상 보증 사례는 계약의 연결 예시이며 실제 모델 관측이 아닙니다.

완료 뒤 발견 문서#

Seal 0.1.12의 새 보고 형식은 당시 완료 보고를 보존하고 이후 발견의 대상 버전·조건·재현 범위·판단 이력·재작업 요청을 연결합니다. 미해결 발견과 역사적 완료는 동시에 표시할 수 있습니다. 문서 상태가 Core의 구조화 조회나 동시 변경 처리를 대신하지 않으며 발견 기록만으로 실행을 재개하거나 예산이 바뀌지 않습니다. 가상 발견 이력은 실제 실행 기록이 아닙니다.