처음이어도 괜찮아요 · 그림부터 시작해요
Gold: 64-state evidence shiproom에서 release를 방어한다
malformed input·rate-limited dependency·ambiguous commit crash·artifact drift의 네 scenario를 demo-only·guarded-run·tested-recovery·evidence-first-release 정책과 네 phase로 교차해 동일 release identity와 사람 판정으로 닫는다. 이를 생략하면 demo·test·CI green 중 하나만 근거로 source·wheel·SBOM·attestation·incident·AI disclosure가 서로 다른 subject인 release를 승인한다. 상황에서도 데모는 보일 수 있지만 제품·검증·운영 책임을 방어할 수 없습니다.
아직 답을 몰라도 괜찮아요. 아래 작은 예시를 보고 먼저 예상해 보세요.01 · 가볍게 시작하기
정답을 보기 전에 먼저 골라볼까요?
cp64 frozen synthetic fixture · fixed clock/UTC · outbound deny · secret-like sentinel · one independent mutant- 1먼저 골라보기
틀려도 괜찮아요. 지금 생각한 답 하나를 정해요.
- 2그림으로 확인하기
움직이는 순서와 달라지는 곳만 천천히 찾아요.
- 3내 말로 다시 말하기
한 문장으로 말해 보면 내가 이해한 곳을 확인할 수 있어요.
02 · 그림으로 보기
그림이 움직이는 순서를 직접 확인해요
GOLD LAB · EVIDENCE-FIRST RELEASE SHIPROOM
Gold: 64-state evidence shiproom에서 release를 방어한다: “동작한다”를 “출시해도 된다”로 바꾸세요
Gold: 64-state evidence shiproom에서 release를 방어한다의 contract·implementation·failure·evidence·human verdict를 한 화면에서 대조한다.
orders_malformed_demo.json · synthetic local fixturerequirement-to-fault suite · idempotent replay검증되지 않은 행이 집계와 최종 산출물의 의미를 바꿉니다.
SPECIFY → RUN → RECOVER → SHIP
3. 네 검증 단계를 직접 진행하세요
현재 조합깨진 입력 · 증거 우선 릴리스 · 요구를 실행 가능한 인수 기준으로 봉인
검증 질문사용자 흐름·데이터 계약·실패 경계와 완료 조건을 테스트 가능한 문장으로 연결했나요?
현재 작업사용자 흐름부터 증거까지 추적 · 입력 schema와 사용자 오류 메시지를 인수 기준에 연결
관찰REQ-IN-01은 유효 2행·격리 1행·종료 코드 2를 요구합니다.
REQUIREMENT → EVIDENCE
요구와 증거 추적표
| 요구 | 인수 기준 | 증거 | 상태 |
|---|---|---|---|
| REQ-01 | 필수 order_id가 없거나 amount가 숫자가 아니면 행을 격리하고 원인을 반환 | requirement-to-evidence trace | linked |
| REQ-02 | CLI·파일·API·pandas 통합 경로가 결정적으로 종료 | CLI + file + API + pandas end-to-end | sealed |
| REQ-03 | 유효 2행만 처리하고 격리 1행과 원인을 같은 run에 연결 | incident-led idempotent replay | sealed |
| REQ-04 | source·tests·README·replay·AI disclosure를 새 환경에서 검증 | source + tests + README + replay bundle | sealed |
제품 경계
- input contractACTIVE
필수 order_id가 없거나 amount가 숫자가 아니면 행을 격리하고 원인을 반환
- CLI → VALIDATE → DATASEALED
CLI + file + API + pandas end-to-end
- fault + recoverySEALED
incident-led idempotent replay
- release evidenceSEALED
source + tests + README + replay bundle
릴리스 증거 묶음
- requirements + acceptance testsCAPTURED
requirement-to-evidence trace
필수 order_id가 없거나 amount가 숫자가 아니면 행을 격리하고 원인을 반환 - CLI + file + API + pandas runSEALED
CLI + file + API + pandas end-to-end
synthetic local fixture · deterministic run id - failure review + recovery replaySEALED
incident-led idempotent replay
유효 2행만 처리하고 격리 1행과 원인을 같은 run에 연결 - source + tests + README + run logSEALED
source + tests + README + replay bundle
fresh local sandbox replay · artifact fingerprint - AI use + human verificationSEALED
prompt scope + human verification
generated scope · reviewer checks · accepted changes
SYNTHETIC INCIDENT REVIEW
synthetic fault review
- 신호
- 두 번째 synthetic 행에서 order_id 누락과 amount='oops' 주입
- 영향
- 검증 없이 진행하면 합계와 행 계보가 잘못됩니다.
- 대응
- incident-led idempotent replay
- 복구 확인
- 유효 2행만 처리하고 격리 1행과 원인을 같은 run에 연결
M1–M11에서 가져온 11개 증거를 확인하세요11 evidence links
- PRG-01-M01실행과 타입
입력·출력·종료 상태를 명시적인 타입과 값으로 설명
runtime fingerprint · exit code · typed value - PRG-01-M02제어 흐름
분기·반복·종료 조건을 제한해 무한 재시도를 방지
decision table · bounded attempts - PRG-01-M03컬렉션
레코드·키·집합으로 중복과 누락을 판별
record schema · dedupe key - PRG-01-M04함수
작은 계약 단위로 검증·변환·저장 책임을 분리
function contract · pure boundary - PRG-01-M05모듈과 환경
패키지 경계와 실행 환경을 새 환경에서도 재구성
module graph · environment manifest - PRG-01-M06파일과 데이터
schema·encoding·원자적 쓰기로 파일 산출물을 보호
file contract · atomic artifact - PRG-01-M07예외와 자원
좁은 예외 분류와 정리 규칙으로 실패 경계를 설명
exception map · cleanup proof - PRG-01-M08객체와 상태
도메인 불변식과 상태 전이를 한 모델에 고정
state model · invariant check - PRG-01-M09테스트와 디버깅
fixture·결함 주입·구조화 로그로 사고를 재현
test suite · incident timeline - PRG-01-M10API 자동화
timeout·retry·idempotency·checkpoint로 의존성을 제어
retry budget · idempotency key · checkpoint - PRG-01-M11데이터 파이프라인
schema·lineage·reconciliation으로 데이터 의미를 보존
data contract · lineage · replay report
아직 출시 판정을 열지 않았습니다. 요구를 명세하고, 제품 전체를 실행하고, 결함을 복구한 뒤 마지막 단계에서만 승인 여부를 판단합니다.
처음 보는 말도 책 읽듯 풀어봐요
이 수업은 쉬운 뜻과 생활 예를 아직 함께 준비하지 못했어요. 설명 없는 정확한 이름은 먼저 보여 주지 않을게요.
그림에서 찾을 쉬운 규칙
- 01malformed input·rate-limited dependency·ambiguous commit crash·artifact drift의 네 scenario를 demo-only·guarded-run·tested-recovery·evidence-first-release 정책과 네 phase로 교차해 동일 release identity와 사람 판정으로 닫는다.
- 024×4×4 state receipt·acceptance trace·private fault recovery·source/test/wheel/SBOM/CI/attestation identity·AI disclosure·signed SHIP/REWORK/BLOCK verdict는 demo·test·CI green 중 하나만 근거로 source·wheel·SBOM·attestation·incident·AI disclosure가 서로 다른 subject인 release를 승인한다.를 포함한 정상·경계·실패 실행에서 독립적으로 다시 계산할 수 있어야 한다.
- 03Gold: 64-state evidence shiproom에서 release를 방어한다은 AI-off 기준선을 먼저 봉인하고 AI 제안 diff를 검토한 뒤, AI가 보지 못한 mutant로 재검증하고 사람이 승인·수정·거절한다.
- 04실제 조직 release review를 축소한 capstone 공개 구두 방어와 operator handoff로 전이할 때 구현보다 contract·effect boundary·evidence owner·residual risk를 먼저 보존한다.
03 · 같이 풀어보기
한 단계씩 따라가면 어렵지 않아요
실제 조직 release review를 축소한 capstone 공개 구두 방어와 operator handoff의 축소된 product slice에서 Gold: 64-state evidence shiproom에서 release를 방어한다 release 판단을 수행한다.
cp64 frozen synthetic fixture · fixed clock/UTC · outbound deny · secret-like sentinel · one independent mutant04 · 이제 내가 해볼 차례
여기까지 오면 이런 일을 할 수 있어요
64개 state를 순회하며 앞의 세 phase를 SEALED로 보존하고 RELEASE_REPRODUCE에서만 evidence-complete human verdict를 내리는 shiproom gate를 구현한다.을 수행하고 4×4×4 state receipt·acceptance trace·private fault recovery·source/test/wheel/SBOM/CI/attestation identity·AI disclosure·signed SHIP/REWORK/BLOCK verdict로 malformed input·rate-limited dependency·ambiguous commit crash·artifact drift의 네 scenario를 demo-only·guarded-run·tested-recovery·evidence-first-release 정책과 네 phase로 교차해 동일 release identity와 사람 판정으로 닫는다.을 독립 검증한다.
- Gold: 64-state evidence shiproom에서 release를 방어한다의 contract·owner·normal/boundary/failure outcome을 AI 없이 먼저 고정한다.
- demo·test·CI green 중 하나만 근거로 source·wheel·SBOM·attestation·incident·AI disclosure가 서로 다른 subject인 release를 승인한다.를 frozen synthetic fixture로 재현하고 최초 divergence와 expected verdict를 설명한다.
- AI 제안은 baseline과 diff로만 검토하고 독립 mutant에서 64개 state를 순회하며 앞의 세 phase를 SEALED로 보존하고 RELEASE_REPRODUCE에서만 evidence-complete human verdict를 내리는 shiproom gate를 구현한다.을 다시 실행한다.
- 4×4×4 state receipt·acceptance trace·private fault recovery·source/test/wheel/SBOM/CI/attestation identity·AI disclosure·signed SHIP/REWORK/BLOCK verdict와 사람의 accept·refactor·reject 판정 및 residual risk를 함께 제출한다.
05 · 자주 헷갈리는 지점
틀린 답도 이유를 알면 다음에는 맞힐 수 있어요
01demo가 성공하고 CI가 green이면 artifact identity와 recovery 증거는 보조 자료다.
한 번 더 생각해 볼 질문cp64 Gold: 64-state evidence shiproom에서 release를 방어한다에서 이 주장을 깨는 최소 반례와 관찰 가능한 판정값을 쓰세요.
이렇게 고쳐 생각해요malformed input·rate-limited dependency·ambiguous commit crash·artifact drift의 네 scenario를 demo-only·guarded-run·tested-recovery·evidence-first-release 정책과 네 phase로 교차해 동일 release identity와 사람 판정으로 닫는다.
02한 scenario의 SHIP 판정은 다른 policy와 phase 조합에도 그대로 적용된다.
한 번 더 생각해 볼 질문cp64 Gold: 64-state evidence shiproom에서 release를 방어한다에서 이 주장을 깨는 최소 반례와 관찰 가능한 판정값을 쓰세요.
이렇게 고쳐 생각해요demo·test·CI green 중 하나만 근거로 source·wheel·SBOM·attestation·incident·AI disclosure가 서로 다른 subject인 release를 승인한다.는 성공 출력과 별도로 재현하고 최초 위반 지점에서 차단해야 한다.
03AI가 release summary를 만들면 사람은 residual risk 없이 SHIP할 수 있다.
한 번 더 생각해 볼 질문cp64 Gold: 64-state evidence shiproom에서 release를 방어한다에서 이 주장을 깨는 최소 반례와 관찰 가능한 판정값을 쓰세요.
이렇게 고쳐 생각해요4×4×4 state receipt·acceptance trace·private fault recovery·source/test/wheel/SBOM/CI/attestation identity·AI disclosure·signed SHIP/REWORK/BLOCK verdict와 독립 mutant·human verdict가 함께 있어야 승인 범위를 설명할 수 있다.
06 · 더 궁금할 때만 보기
선생님과 검토자를 위한 믿을 만한 원문
원문과 어디까지 참고했는지 펼쳐 보기처음 배우는 동안에는 열지 않아도 괜찮아요.
valid·reliable·privacy-enhanced·fairness with harmful bias managed의 위험 관리 속성. 현재 revision 절차와 1.0 최종 문서를 구분한다.
M12 언어 runtime 기준과 source artifact의 Sigstore·SPDX SBOM. free-threaded build는 선택이고 JIT는 실험 기능이므로 기본 GIL·JIT-off gate 결과와 혼용하지 않는다.
Python 3.14를 포함한 M12 current test lane. 설치·실행 receipt 전에는 저장소 검증 완료를 주장하지 않는다.
artifact·SBOM attestation 생성과 gh attestation verify. 검증하지 않은 attestation은 보안 이득이나 artifact 안전성 증명이 아니다.
component·service·dependency·lifecycle inventory를 가진 M12 core SBOM. SBOM은 vulnerability-free 증명이나 license 판정 자체가 아니다.
build provenance와 level requirement를 현재 표준으로 학습한다. GitHub의 v1.0 Build L2/L3 설명을 v1.2 달성으로 바꾸지 않는다.
log·metric·trace, telemetry와 observability의 차이, SLI·SLO를 user-visible outcome과 연결하는 기반