GodopuandClaude Opus 5
8adbe2245c
Three scenarios join the contract set, so the fifteen vectors now cover an unproven side effect, an undecidable attribution, and an agent whose state goes unreadable in the window between finalization and notification. All fifteen match their expected decision. The side-effect case needed a decision about layering. Authoritative enforcement belongs in manifest verification, which has the job record and therefore knows what was declared; the policy honours an explicit negative from the collector so the case is expressible as a vector. Absence is not read as proof there, because the manifest check is the layer that fails closed on missing evidence. The operations note records why the agent declares and the reader re-derives, the three gates and why the backend allowlist can only be narrowed, the notification transaction, and the rollback. It also records a deviation from my own plan. §D2 asked for reviewer sign-off before promoting an attempt id into the record, since that changes a contract phase 1 froze. Measurement during implementation showed the change was not needed: the attempt guard already lives in the evidence layer, where attempt identity actually is, so auto-completion passes the engine a status precondition instead. The schema is untouched, the frozen contract holds, and a characterization test fails the moment a record starts carrying an attempt id, which is when to revisit it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UrDNJkHmm18uu7n7JwV5Qd
85 lines
6.1 KiB
Markdown
85 lines
6.1 KiB
Markdown
# 📑 Issue #5 Phase 2b — 자동완료 운영 노트 (Flag-Gated / Opt-In)
|
|
|
|
- **문서 버전**: Rev.1
|
|
- **상태**: 구현 완료, **기본 비활성(`MAM_AUTO_COMPLETE=0`)**
|
|
|
|
---
|
|
|
|
## 1. 한 문장 요약
|
|
|
|
**끝났다는 사실을 아는 쪽(에이전트)이 확정을 선언하고, 읽는 쪽은 그 선언을 믿지 않고 해시를 다시 계산한다.**
|
|
|
|
워처가 스스로 해시를 계산해 매니페스트를 만들면 그것은 "워처가 안정된 파일을 봤다"는 자기 증명일 뿐이다. 이 이슈의 앞선 라운드에서 리뷰어가 기각한 증거 형태이며, 같은 실수를 반복하지 않기 위한 설계 결정이다.
|
|
|
|
## 2. 그래서 미지원 에이전트는 자동으로 안전하다
|
|
|
|
확정을 선언하지 않은 에이전트는 매니페스트를 남기지 않는다. 매니페스트가 없으면 정책이 이미 `hold`한다(Phase 2a에서 구현·테스트 완료). **"미지원 경로 100% 보존"은 새 분기가 아니라 기존 동작의 귀결이다.**
|
|
|
|
## 3. 3중 게이트 (전부 참일 때만 커밋)
|
|
|
|
| 게이트 | 기본값 | 근거 |
|
|
|---|---|---|
|
|
| `MAM_AUTO_COMPLETE=1` | **`0` (OFF)** | 전역 킬 스위치 |
|
|
| 백엔드 허용목록 | `claude,grok,codex` | 정지 상태(`idle`/`done`) **관측 증거가 있는 백엔드만**. `agy`는 `working`만 관측, `hermes`·`opencode`는 관측 0건 |
|
|
| 잡별 opt-in | 레코드 `auto_complete: true` | 잡 단위 동의 |
|
|
|
|
`MAM_AUTO_COMPLETE_BACKENDS`로 목록을 **좁힐 수만** 있다. 관측된 적 없는 이름은 무시된다 — 넓히려면 설정이 아니라 증거가 필요하다.
|
|
|
|
## 4. 확정 계약 (P2B-01)
|
|
|
|
```
|
|
에이전트: publish_event.py --job <id> --event completed \
|
|
--finalize-report <path> [--side-effect <kind>=<ref>] ...
|
|
① <path>.tmp → <path> 원자적 rename (반쯤 쓰인 리포트를 최종본으로 볼 수 없게)
|
|
② SHA-256 계산
|
|
③ report-manifest.json 원자적 기록 (job_id, attempt_id, sha256, side_effects, declared_by)
|
|
```
|
|
|
|
- **리포트를 다시 쓰면 선언은 즉시 무효**가 된다. 해시를 다시 계산해 대조하기 때문이다. 새 본문에는 새 확정이 필요하다.
|
|
- **선언한 부수효과는 전부 증거가 있어야 한다.** 일부만 있는 것은 없는 것으로 취급한다 — 작업이 끝났다고 알 수 없기 때문이다.
|
|
- 확정은 발행 **앞에** 일어난다. 리포트를 아직 쓰는 중인 `completed` 이벤트는 계약이 금지하는 부분 리포트 채택을 부른다.
|
|
|
|
## 5. 지연 알림 (P2B-02)
|
|
|
|
```
|
|
락 안: 상태 커밋 + pending_notification 기록 ← 하나의 원자적 쓰기
|
|
락 밖: 발행 → 성공 시 notification_settled 전이로 정리
|
|
기동 시: pending_notification이 남은 레코드를 재발행 (멱등: 구독자가 seq로 중복 제거)
|
|
```
|
|
|
|
- **독립 Outbox 저장소를 만들지 않는다**(`state-transitions.md` §5 명시). 이미 쓰는 레코드에 필드 하나를 더 쓴다.
|
|
- **발행 실패는 의도적으로 intent를 남긴다.** 보내지 않은 알림이 보낸 것처럼 보이는 편이, 재시도되는 편보다 나쁘다.
|
|
- `notification_settled`는 **상태를 바꾸지 않는 bookkeeping 요청**이라 terminal 상태에서도 허용된다. 알림은 terminal에 *관한* 것이므로, terminal이 거부하는 요청으로는 영원히 정리할 수 없다.
|
|
|
|
## 6. 무판정 fail-closed
|
|
|
|
매니페스트를 읽지 못함, 정책이 예외를 던짐, 알 수 없는 결정 — 전부 `hold`다. **"판정하지 못함"은 결코 "완료"가 아니다.** 늦게 도착한 명시 terminal이 있으면 전이 경계가 추론 완료를 거부하며, 그것은 경계가 제 일을 한 것이지 게이트의 오류가 아니다.
|
|
|
|
## 7. 감사 표식
|
|
|
|
자동완료로 들어간 terminal에는 `completed_by: "auto_complete"`와 판정 사유가 남는다. 구독자와 래퍼는 자동/명시 완료를 구별하지 못하므로(`job_subscriber._check_disk_fallback`은 레지스트리 status만 본다), **사후에 구별할 수 있는 유일한 수단**이다.
|
|
|
|
## 8. 롤백
|
|
|
|
1. `MAM_AUTO_COMPLETE=0` — 신규 자동완료만 중단. **이미 확정된 terminal 레코드는 보존**한다.
|
|
2. `MAM_ENGINE_CAS=0` — Phase 2a 경로까지 되돌린다(자동완료는 그 위에 있으므로 함께 무력화).
|
|
3. `.mam/shadow/`는 레지스트리와 분리되어 있어 삭제해도 job 상태에 영향이 없다.
|
|
|
|
## 9. 계획 대비 이탈 1건 (레코드 스키마 미변경)
|
|
|
|
계획서 §D2는 `attempt_id`를 job 레코드의 1급 필드로 승격할 것을 권고하고, Phase 1이 동결한 "레코드 필드 불변" 계약의 변경이므로 **리뷰어 승인을 선행 조건**으로 걸었다.
|
|
|
|
구현 중 실측한 결과 **그 변경이 필요하지 않았다**:
|
|
- 엔진의 `expected_attempt`는 레코드의 `attempt_id`(없음)를 `iteration`(루프 회차)으로 대체 비교한다 — 두 개념이 달라 의미가 성립하지 않는다.
|
|
- 반면 **시도 식별은 이미 증거 계층에서 검증된다**: `policy`가 관측 식별자와 shadow 저장소의 dispatch 레코드를 대조하며, 시도가 어긋나면 `hold`한다(실측 확인).
|
|
|
|
따라서 자동완료는 엔진에 `expected_attempt`를 넘기지 않고 `expected_status="running"`(엔진의 고유 영역인 상태)만 전제조건으로 준다. **시도 보증은 시도 정체성이 실제로 사는 곳에 둔다.** 레코드 스키마는 바뀌지 않았고, Phase 1 계약도 유지된다.
|
|
|
|
`attempt_id` 승격은 열린 질문으로 남긴다. 승격하면 엔진에 2차 방어선이 생기지만 동결 계약을 바꿔야 하며, 현재는 필요하지 않다. `test_x03_the_record_carries_iteration_not_an_attempt_id`가 이 전제를 감시한다 — 레코드가 `attempt_id`를 갖게 되는 순간 실패하며, 그때가 재검토 시점이다.
|
|
|
|
## 10. Phase 3 인계
|
|
|
|
1. `preexec_fn`: 2b도 데몬을 스폰하지 않아 미노출 유지. 알림 flush는 기존 구독자 프로세스 안에서 수행한다.
|
|
2. 부수효과의 **원격** 확인(실제 push 도달 여부 등)은 비범위 — 증거의 존재·대응까지만 검증한다.
|
|
3. `agy`/`hermes`/`opencode` 자동완료는 정지 상태 실측 증거 확보 후 별도 판단.
|