Gold: 64-state evidence shiproom에서 release를 방어한다

1. 01

   찾아보기 · 기초

   cp64 recognize · Gold: 64-state evidence shiproom에서 release를 방어한다: 64-state shiproom·evidence-first release 표식 중 “malformed input·rate-limited dependency·ambiguous commit crash·artifact drift의 네 scenario를 demo-only·guarded-run·tested-recovery·evidence-first-release 정책과 네 phase로 교차해 동일 release identity와 사람 판정으로 닫는다.”을 충족하는 상태를 고른다.

   상황

   기능 목록·사용자 요구·인수 기준·성공 screenshot·test log가 섞인 project board에서 릴리스 증거가 될 수 있는 항목을 구분합니다.

   문제

   각 artifact가 무엇을 주장하고 무엇을 증명하지 못하는지 분류한 뒤 requirement-to-evidence 표를 작성하세요.

   제공 자료

   • Input fixture: REQ-01, AC-01, 구현 메모, screenshot, pytest summary, README command, run fingerprint
   • 요구는 사용자 가치와 실패 경계를 설명하고, 인수 기준은 관찰 가능한 통과 조건으로 바뀌어야 합니다.
   • screenshot은 화면 상태를 보여도 입력 계약·복구·새 환경 재현을 증명하지 않습니다.
   • 증거는 requirement id·run id·artifact fingerprint와 연결되어야 합니다.
   • 판정 경계: 화면의 성공 여부가 아니라 요구·인수 기준·CLI·파일·API·pandas 실행·fault recovery·source·tests·README·run log·failure review·AI disclosure의 연결 증거를 채점합니다.
   • Privacy: 실제 사용자·운영 저장소·credential·환경변수·live endpoint를 읽지 않고 synthetic input과 고정된 local fixture만 사용합니다.
   • 공개/비공개 경계: 공개 DTO에는 client-safe 자기검토 설명만 둡니다. executable oracle·hidden expected protocol·private deterministic seed·secret sentinel은 production import graph 밖에 둡니다.
   • 검증 조건: exact Python·pytest·패키징 도구 결과를 추정하지 않습니다. 환경 플래그와 이미 준비된 로컬 QA image가 모두 있을 때만 exact-runtime 증거를 주장하며 image pull이나 다른 runtime 대체는 허용하지 않습니다.
   • 과장 금지: 한 번의 성공 demo, 녹색 test, 생성된 README, AI 추천은 복구 안전성·artifact 재현성·보안·자격 합격을 보증하지 않습니다.

   비교표 · 관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.

   정답 대신 4단계 힌트 보기

   1. 관찰

      Gold: 64-state evidence shiproom에서 release를 방어한다의 output만 보지 말고 input identity, exit, side effect, rollback, log/metric과 artifact hash를 분리하세요.

   2. 개념

      malformed input·rate-limited dependency·ambiguous commit crash·artifact drift의 네 scenario를 demo-only·guarded-run·tested-recovery·evidence-first-release 정책과 네 phase로 교차해 동일 release identity와 사람 판정으로 닫는다.

   3. 다음 도움

      내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.

   내 답과 맞춰 볼 기준 보기정답과 비교
2. 02

   먼저 생각하기 · 기초

   cp64 predict · Gold: 64-state evidence shiproom에서 release를 방어한다: AI 없이 “demo·test·CI green 중 하나만 근거로 source·wheel·SBOM·attestation·incident·AI disclosure가 서로 다른 subject인 release를 승인한다.”를 실행했을 때 exit·state·artifact·evidence가 어떻게 달라질지 먼저 예측한다.

   상황

   깨진 입력·429 의존성·모호한 commit crash·artifact drift를 demo-only부터 evidence-first-release까지 네 정책으로 처리합니다.

   문제

   각 scenario-policy 조합의 final verdict와 release gate 결과를 예측하고, final phase 전에는 왜 판정을 봉인해야 하는지 설명하세요.

   제공 자료

   • Input fixture: 4 scenarios × 4 policies, phase 1–3 evidence partial, phase 4 release replay
   • guarded-run은 위험한 실행을 멈출 수 있지만 모든 scenario의 복구·재현 증거를 만들지는 않습니다.
   • tested-recovery는 실행 복구를 증명해도 artifact drift에서는 README와 manifest gap이 남을 수 있습니다.
   • evidence-first-release는 요구·실행·복구·release bundle을 모두 같은 run으로 재현합니다.
   • 판정 경계: 화면의 성공 여부가 아니라 요구·인수 기준·CLI·파일·API·pandas 실행·fault recovery·source·tests·README·run log·failure review·AI disclosure의 연결 증거를 채점합니다.
   • Privacy: 실제 사용자·운영 저장소·credential·환경변수·live endpoint를 읽지 않고 synthetic input과 고정된 local fixture만 사용합니다.
   • 공개/비공개 경계: 공개 DTO에는 client-safe 자기검토 설명만 둡니다. executable oracle·hidden expected protocol·private deterministic seed·secret sentinel은 production import graph 밖에 둡니다.
   • 검증 조건: exact Python·pytest·패키징 도구 결과를 추정하지 않습니다. 환경 플래그와 이미 준비된 로컬 QA image가 모두 있을 때만 exact-runtime 증거를 주장하며 image pull이나 다른 runtime 대체는 허용하지 않습니다.
   • 과장 금지: 한 번의 성공 demo, 녹색 test, 생성된 README, AI 추천은 복구 안전성·artifact 재현성·보안·자격 합격을 보증하지 않습니다.

   비교표 · 관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.

   정답 대신 4단계 힌트 보기

   1. 관찰

      Gold: 64-state evidence shiproom에서 release를 방어한다의 output만 보지 말고 input identity, exit, side effect, rollback, log/metric과 artifact hash를 분리하세요.

   2. 개념

      malformed input·rate-limited dependency·ambiguous commit crash·artifact drift의 네 scenario를 demo-only·guarded-run·tested-recovery·evidence-first-release 정책과 네 phase로 교차해 동일 release identity와 사람 판정으로 닫는다.

   3. 다음 도움

      내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.

   내 답과 맞춰 볼 기준 보기움직임과 비교
3. 03

   순서 따라가기 · 익힌 것을 써보기

   cp64 trace · Gold: 64-state evidence shiproom에서 release를 방어한다: 64-state shiproom → evidence-first release → SEALED → release verdict를 따라 요청에서 4×4×4 state receipt·acceptance trace·private fault recovery·source/test/wheel/SBOM/CI/attestation identity·AI disclosure·signed SHIP/REWORK/BLOCK verdict까지 최초 contract divergence를 추적한다.

   상황

   하나의 synthetic 주문 작업이 CLI 입력에서 validator·local fake API·pandas transform·atomic artifact·checkpoint·evidence bundle을 통과합니다.

   문제

   정상 실행과 429·validation failure·commit crash 경로에서 component state와 artifact ownership을 단계별 diagram으로 추적하세요.

   제공 자료

   • Input fixture: CLI → input contract → API → pandas → atomic commit → checkpoint → release evidence
   • validation은 pandas 집계 전에 끝나며 잘못된 행은 원본 id와 원인을 유지한 채 격리합니다.
   • API retry는 deadline·Retry-After·attempt budget과 동일 idempotency key를 공유합니다.
   • artifact commit과 checkpoint는 별도 상태이므로 reconciliation 단계가 필요합니다.
   • 판정 경계: 화면의 성공 여부가 아니라 요구·인수 기준·CLI·파일·API·pandas 실행·fault recovery·source·tests·README·run log·failure review·AI disclosure의 연결 증거를 채점합니다.
   • Privacy: 실제 사용자·운영 저장소·credential·환경변수·live endpoint를 읽지 않고 synthetic input과 고정된 local fixture만 사용합니다.
   • 공개/비공개 경계: 공개 DTO에는 client-safe 자기검토 설명만 둡니다. executable oracle·hidden expected protocol·private deterministic seed·secret sentinel은 production import graph 밖에 둡니다.
   • 검증 조건: exact Python·pytest·패키징 도구 결과를 추정하지 않습니다. 환경 플래그와 이미 준비된 로컬 QA image가 모두 있을 때만 exact-runtime 증거를 주장하며 image pull이나 다른 runtime 대체는 허용하지 않습니다.
   • 과장 금지: 한 번의 성공 demo, 녹색 test, 생성된 README, AI 추천은 복구 안전성·artifact 재현성·보안·자격 합격을 보증하지 않습니다.

   서로 이어지는 모습을 그리기 · 관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.

   정답 대신 4단계 힌트 보기

   1. 관찰

      Gold: 64-state evidence shiproom에서 release를 방어한다의 output만 보지 말고 input identity, exit, side effect, rollback, log/metric과 artifact hash를 분리하세요.

   2. 개념

      malformed input·rate-limited dependency·ambiguous commit crash·artifact drift의 네 scenario를 demo-only·guarded-run·tested-recovery·evidence-first-release 정책과 네 phase로 교차해 동일 release identity와 사람 판정으로 닫는다.

   3. 다음 도움

      내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.

   내 답과 맞춰 볼 기준 보기움직임과 비교
4. 04

   내 말로 설명하기 · 익힌 것을 써보기

   cp64 explain · 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와 사람 판정으로 닫는다.이 필요한 이유와 4×4×4 state receipt·acceptance trace·private fault recovery·source/test/wheel/SBOM/CI/attestation identity·AI disclosure·signed SHIP/REWORK/BLOCK verdict가 입증하지 못하는 범위를 함께 설명한다.

   상황

   artifact는 저장됐지만 checkpoint 전에 process가 종료되어 재시작 시 commit 여부가 모호합니다.

   문제

   왜 단순 retry가 중복 부작용을 만들며 stable operation id·content fingerprint·lookup·atomic checkpoint가 어떻게 exactly-once 관찰을 만드는지 설명하세요.

   제공 자료

   • Input fixture: operation=order-summary-17, artifact fingerprint=f17, checkpoint absent, restart
   • exactly-once는 transport가 아니라 같은 logical operation의 관찰 결과가 한 건이라는 application contract입니다.
   • idempotency key는 payload 의미가 같을 때만 재사용하며 다른 fingerprint와 충돌하면 차단합니다.
   • lookup 결과와 local checkpoint는 같은 artifact fingerprint를 가리켜야 합니다.
   • 판정 경계: 화면의 성공 여부가 아니라 요구·인수 기준·CLI·파일·API·pandas 실행·fault recovery·source·tests·README·run log·failure review·AI disclosure의 연결 증거를 채점합니다.
   • Privacy: 실제 사용자·운영 저장소·credential·환경변수·live endpoint를 읽지 않고 synthetic input과 고정된 local fixture만 사용합니다.
   • 공개/비공개 경계: 공개 DTO에는 client-safe 자기검토 설명만 둡니다. executable oracle·hidden expected protocol·private deterministic seed·secret sentinel은 production import graph 밖에 둡니다.
   • 검증 조건: exact Python·pytest·패키징 도구 결과를 추정하지 않습니다. 환경 플래그와 이미 준비된 로컬 QA image가 모두 있을 때만 exact-runtime 증거를 주장하며 image pull이나 다른 runtime 대체는 허용하지 않습니다.
   • 과장 금지: 한 번의 성공 demo, 녹색 test, 생성된 README, AI 추천은 복구 안전성·artifact 재현성·보안·자격 합격을 보증하지 않습니다.

   까닭을 함께 쓰는 설명 · 관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.

   정답 대신 4단계 힌트 보기

   1. 관찰

      Gold: 64-state evidence shiproom에서 release를 방어한다의 output만 보지 말고 input identity, exit, side effect, rollback, log/metric과 artifact hash를 분리하세요.

   2. 개념

      malformed input·rate-limited dependency·ambiguous commit crash·artifact drift의 네 scenario를 demo-only·guarded-run·tested-recovery·evidence-first-release 정책과 네 phase로 교차해 동일 release identity와 사람 판정으로 닫는다.

   3. 다음 도움

      내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.

   내 답과 맞춰 볼 기준 보기설명 기준과 비교
5. 05

   빈칸 채우기 · 익힌 것을 써보기

   cp64 complete · Gold: 64-state evidence shiproom에서 release를 방어한다: 누락된 guard·effect boundary·failure verdict를 채워 “64개 state를 순회하며 앞의 세 phase를 SEALED로 보존하고 RELEASE_REPRODUCE에서만 evidence-complete human verdict를 내리는 shiproom gate를 구현한다.”을 fail-closed로 완성한다.

   상황

   기능은 완성됐지만 requirement·architecture·tests·README·run log·failure review·AI disclosure가 서로 연결되지 않은 release dossier가 있습니다.

   문제

   빈 traceability manifest를 완성하고 각 evidence item의 owner·source revision·run id·fingerprint·approval rule을 채우세요.

   제공 자료

   • Input fixture: manifest skeleton: requirements, architecture, tests, README, replay, incident, AI-use fields empty
   • release evidence는 source와 함께 versioned되며 generated artifact의 생성 command를 포함합니다.
   • failure review는 실패를 숨기지 않고 trigger·impact·root cause·recovery·regression test를 연결합니다.
   • AI disclosure는 도구 사용 범위·사람의 검증·채택한 변경과 독립 proof를 구분합니다.
   • 판정 경계: 화면의 성공 여부가 아니라 요구·인수 기준·CLI·파일·API·pandas 실행·fault recovery·source·tests·README·run log·failure review·AI disclosure의 연결 증거를 채점합니다.
   • Privacy: 실제 사용자·운영 저장소·credential·환경변수·live endpoint를 읽지 않고 synthetic input과 고정된 local fixture만 사용합니다.
   • 공개/비공개 경계: 공개 DTO에는 client-safe 자기검토 설명만 둡니다. executable oracle·hidden expected protocol·private deterministic seed·secret sentinel은 production import graph 밖에 둡니다.
   • 검증 조건: exact Python·pytest·패키징 도구 결과를 추정하지 않습니다. 환경 플래그와 이미 준비된 로컬 QA image가 모두 있을 때만 exact-runtime 증거를 주장하며 image pull이나 다른 runtime 대체는 허용하지 않습니다.
   • 과장 금지: 한 번의 성공 demo, 녹색 test, 생성된 README, AI 추천은 복구 안전성·artifact 재현성·보안·자격 합격을 보증하지 않습니다.

   비교표 · 관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.

   정답 대신 4단계 힌트 보기

   1. 관찰

      Gold: 64-state evidence shiproom에서 release를 방어한다의 output만 보지 말고 input identity, exit, side effect, rollback, log/metric과 artifact hash를 분리하세요.

   2. 개념

      malformed input·rate-limited dependency·ambiguous commit crash·artifact drift의 네 scenario를 demo-only·guarded-run·tested-recovery·evidence-first-release 정책과 네 phase로 교차해 동일 release identity와 사람 판정으로 닫는다.

   3. 다음 도움

      내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.

   내 답과 맞춰 볼 기준 보기답과 설명 함께 비교
6. 06

   틀린 곳 고치기 · 익힌 것을 써보기

   cp64 debug · Gold: 64-state evidence shiproom에서 release를 방어한다: 독립 mutant로 “demo·test·CI green 중 하나만 근거로 source·wheel·SBOM·attestation·incident·AI disclosure가 서로 다른 subject인 release를 승인한다.”를 재현하고 최초 위반 지점만 수정한다.

   상황

   source와 pytest는 통과하지만 README command는 삭제된 option을 사용하고 runtime manifest와 run log는 이전 dependency fingerprint를 가리킵니다.

   문제

   release pipeline을 단계별로 디버그해 최초 drift를 찾고, 최소 수정·regression gate·fresh-environment replay를 설계하세요.

   제공 자료

   • Input fixture: source r22, tests green, README --legacy, manifest fp21, run log fp21, expected fp22
   • 테스트 성공은 test가 실행한 interface만 증명하며 README command의 실행 가능성을 자동 보장하지 않습니다.
   • artifact drift는 파일 수정 시간보다 canonical content와 semantic command test로 판정합니다.
   • 고친 bundle은 깨끗한 local sandbox에서 install·run·compare 순서로 재현합니다.
   • 판정 경계: 화면의 성공 여부가 아니라 요구·인수 기준·CLI·파일·API·pandas 실행·fault recovery·source·tests·README·run log·failure review·AI disclosure의 연결 증거를 채점합니다.
   • Privacy: 실제 사용자·운영 저장소·credential·환경변수·live endpoint를 읽지 않고 synthetic input과 고정된 local fixture만 사용합니다.
   • 공개/비공개 경계: 공개 DTO에는 client-safe 자기검토 설명만 둡니다. executable oracle·hidden expected protocol·private deterministic seed·secret sentinel은 production import graph 밖에 둡니다.
   • 검증 조건: exact Python·pytest·패키징 도구 결과를 추정하지 않습니다. 환경 플래그와 이미 준비된 로컬 QA image가 모두 있을 때만 exact-runtime 증거를 주장하며 image pull이나 다른 runtime 대체는 허용하지 않습니다.
   • 과장 금지: 한 번의 성공 demo, 녹색 test, 생성된 README, AI 추천은 복구 안전성·artifact 재현성·보안·자격 합격을 보증하지 않습니다.

   순서대로 적기 · 관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.

   정답 대신 4단계 힌트 보기

   1. 관찰

      Gold: 64-state evidence shiproom에서 release를 방어한다의 output만 보지 말고 input identity, exit, side effect, rollback, log/metric과 artifact hash를 분리하세요.

   2. 개념

      malformed input·rate-limited dependency·ambiguous commit crash·artifact drift의 네 scenario를 demo-only·guarded-run·tested-recovery·evidence-first-release 정책과 네 phase로 교차해 동일 release identity와 사람 판정으로 닫는다.

   3. 다음 도움

      내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.

   내 답과 맞춰 볼 기준 보기답과 설명 함께 비교
7. 07

   직접 만들기 · 새 문제

   cp64 implement · Gold: 64-state evidence shiproom에서 release를 방어한다: 64개 state를 순회하며 앞의 세 phase를 SEALED로 보존하고 RELEASE_REPRODUCE에서만 evidence-complete human verdict를 내리는 shiproom gate를 구현한다.을 frozen synthetic fixture와 bounded effect로 구현해 4×4×4 state receipt·acceptance trace·private fault recovery·source/test/wheel/SBOM/CI/attestation identity·AI disclosure·signed SHIP/REWORK/BLOCK verdict를 생성한다.

   상황

   네 scenario·네 policy·네 phase를 순회하며 phase 1–3의 outcome은 봉인하고 마지막 phase에서만 exact verdict를 반환하는 상태 기계가 필요합니다.

   문제

   입력 배열을 변경하지 않는 64-state generator와 exact verdict matrix·고유 id·invalid phase guard를 구현하세요.

   제공 자료

   • Input fixture: phases[4], scenarios[4], policies[4], verdict matrix[4][4]
   • state id는 scenario:policy:phase이며 Cartesian product의 64개 값이 모두 고유해야 합니다.
   • phase index는 0–3 정수만 허용하고 그 외 값은 오류로 fail-closed합니다.
   • outcome과 verdict key는 RELEASE_REPRODUCE에서만 존재하며 앞 phase에는 verdict 문자열을 포함하지 않습니다.
   • 판정 경계: 화면의 성공 여부가 아니라 요구·인수 기준·CLI·파일·API·pandas 실행·fault recovery·source·tests·README·run log·failure review·AI disclosure의 연결 증거를 채점합니다.
   • Privacy: 실제 사용자·운영 저장소·credential·환경변수·live endpoint를 읽지 않고 synthetic input과 고정된 local fixture만 사용합니다.
   • 공개/비공개 경계: 공개 DTO에는 client-safe 자기검토 설명만 둡니다. executable oracle·hidden expected protocol·private deterministic seed·secret sentinel은 production import graph 밖에 둡니다.
   • 검증 조건: exact Python·pytest·패키징 도구 결과를 추정하지 않습니다. 환경 플래그와 이미 준비된 로컬 QA image가 모두 있을 때만 exact-runtime 증거를 주장하며 image pull이나 다른 runtime 대체는 허용하지 않습니다.
   • 과장 금지: 한 번의 성공 demo, 녹색 test, 생성된 README, AI 추천은 복구 안전성·artifact 재현성·보안·자격 합격을 보증하지 않습니다.

   컴퓨터 안내와 나온 결과 · 관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.

   정답 대신 4단계 힌트 보기

   1. 관찰

      Gold: 64-state evidence shiproom에서 release를 방어한다의 output만 보지 말고 input identity, exit, side effect, rollback, log/metric과 artifact hash를 분리하세요.

   2. 개념

      malformed input·rate-limited dependency·ambiguous commit crash·artifact drift의 네 scenario를 demo-only·guarded-run·tested-recovery·evidence-first-release 정책과 네 phase로 교차해 동일 release identity와 사람 판정으로 닫는다.

   3. 다음 도움

      내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.

   내 답과 맞춰 볼 기준 보기정답과 비교
8. 08

   새 문제에 써보기 · 새 문제

   cp64 transfer · Gold: 64-state evidence shiproom에서 release를 방어한다: 실제 조직 release review를 축소한 capstone 공개 구두 방어와 operator handoff로 계약을 옮겨 AI 보조의 변경점과 사람이 최종 승인할 근거를 방어한다.

   상황

   AI 보조로 만든 Python CLI를 학습 demo에서 제3자가 설치·실행·실패 복구·검토할 수 있는 release candidate로 전환합니다.

   문제

   M1–M11 역량을 evidence chain에 배치하고 보안·SBOM·관측성·incident·AI disclosure를 포함한 evidence-first shiproom 계획을 작성하세요.

   제공 자료

   • Input fixture: AI-generated CLI, synthetic fixtures, partial tests, draft README, no release dossier
   • M1–M11의 타입·제어·컬렉션·함수·환경·파일·예외·객체·test·API·data evidence를 현재 artifact에 연결합니다.
   • secret scan·dependency inventory·least privilege·structured logging은 기능 test와 별도 gate입니다.
   • AI 산출물은 prompt 공개 자체가 아니라 생성 범위·사람의 검증·독립 실행 proof로 평가합니다.
   • 판정 경계: 화면의 성공 여부가 아니라 요구·인수 기준·CLI·파일·API·pandas 실행·fault recovery·source·tests·README·run log·failure review·AI disclosure의 연결 증거를 채점합니다.
   • Privacy: 실제 사용자·운영 저장소·credential·환경변수·live endpoint를 읽지 않고 synthetic input과 고정된 local fixture만 사용합니다.
   • 공개/비공개 경계: 공개 DTO에는 client-safe 자기검토 설명만 둡니다. executable oracle·hidden expected protocol·private deterministic seed·secret sentinel은 production import graph 밖에 둡니다.
   • 검증 조건: exact Python·pytest·패키징 도구 결과를 추정하지 않습니다. 환경 플래그와 이미 준비된 로컬 QA image가 모두 있을 때만 exact-runtime 증거를 주장하며 image pull이나 다른 runtime 대체는 허용하지 않습니다.
   • 과장 금지: 한 번의 성공 demo, 녹색 test, 생성된 README, AI 추천은 복구 안전성·artifact 재현성·보안·자격 합격을 보증하지 않습니다.

   순서대로 적기 · 관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.

   정답 대신 4단계 힌트 보기

   1. 관찰

      Gold: 64-state evidence shiproom에서 release를 방어한다의 output만 보지 말고 input identity, exit, side effect, rollback, log/metric과 artifact hash를 분리하세요.

   2. 개념

      malformed input·rate-limited dependency·ambiguous commit crash·artifact drift의 네 scenario를 demo-only·guarded-run·tested-recovery·evidence-first-release 정책과 네 phase로 교차해 동일 release identity와 사람 판정으로 닫는다.

   3. 다음 도움

      내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.

   내 답과 맞춰 볼 기준 보기설명 기준과 비교

8개 답이 남았습니다.