W24 미리보기 · 웹소설 본편 STARRY PASS 20 — 동결된 악보와 하나의 깃발 모든 조각이 한 commit에 맞을 때 마지막 선택은 하나가 되었다
범위 개요 + D1–D6 · 월–토 p785–p813 상단 — W24 개요 + D1–D6
정본 상태 SOURCE AUDIT PASS PDF·package·display byte 폐쇄
실행 상태 W24 D1–D6 RUNTIME NOT_RUN runtimeRunsByPreview=0
공통 코어 · 트랙 선택 시 증권 기본 이 preview는 Gradle·Docker·HTTP·PostgreSQL·external review·사람 서명을 실행하지 않았습니다. D1은 learner runtime NOT_RUN, D2·D3·D5·D6는 HUMAN_SEMANTIC_REVIEW_REQUIRED, D4는 source-only·runtime DEFERRED_TO_D7입니다. p785–p813 상단 — W24 개요 + D1–D6만 포함하며 p813 하단 D7과 p818–819 주간 통합·해설·Green Gate는 제외합니다.
strict D1–D6 초회 예상시간은 8시간 20분–15시간 50분입니다. 공통 코어 · 트랙 선택 시 증권 기본이며 증권 기본은 원문 선택 결과가 아닌 UI 설정입니다. 전체 코드 inventory는 canonical 9개·illustrative 8개, aggregate 17/696/640/0/640/640/68/0/0, source-local tests=0·testsExecuted=0입니다. Q39·Q40은 prompt-only 원문을 바탕으로 한 비정본·미실행 예시입니다.
월요일, STARRY의 악보 보관함에 마지막 자물쇠가 걸렸다. 니지카는 대충 전체 test를 돌리는 대신 43개의 정확한 selector와 37개의 class 이름을 줄마다 맞췄다. 결과 XML도 37개, test는 66개여야 했고 failure·error·skip 세 칸은 모두 0이어야 했다. 료는 말했다. “합계가 같아도 다른 악기가 끼어들면 같은 연주가 아니야.”
공식 장면컷은 분위기용이며, STARRY의 사건·대사·기술 수치는 원문 감사에 따른 비공식 학습 구성입니다. 그림 한눈에: wildcard 없이 43 selector와 actual XML 37·tests 66을 exact Gate로 닫습니다. expected 목록은 악보였고 actual XML은 실제로 연주했다는 영수증이었다. 이 preview에는 그 영수증이 없었으므로 SOURCE AUDIT PASS 아래 runtimeRunsByPreview=0을 함께 적었다.
화요일, 키타는 벽에 세 개의 흐름을 그렸다. 정상 이체는 9000과 6000, ledger pair 합 0으로 끝났다. 업무 처리 뒤 강제로 넘어지는 흐름은 DB effect 0으로 되돌아와야 했다. 같은 열쇠를 스무 번 동시에 넣는 흐름은 business effect 하나만 남기고 나머지를 replay로 돌려보냈다.
그림 한눈에: 정상·중간 실패·동시 중복의 transaction·atomic claim 경계를 나란히 봅니다. 공식 장면컷은 분위기용이며, STARRY의 사건·대사·기술 수치는 원문 감사에 따른 비공식 학습 구성입니다. 그러나 architecture-pack.pdf의 크기와 hash만으로 세 그림의 의미를 확인할 수는 없었다. ERD·lock order·rollback·replay는 사람이 읽고 서명하기 전까지 MANUAL_REVIEW_REQUIRED였다.
수요일, 히토리는 README 첫 화면에서 기술 이름을 지웠다. 대신 세 문장으로 문제를 쓰고 정확한 scope와 5분 실행을 붙였다. 원자성·잠금·멱등·대사·query·보안·운영 일곱 위험마다 선택, test, 결과, 한계, raw evidence를 같은 줄로 이었다.
그림 한눈에: README를 기능 목록이 아니라 일곱 위험과 실제 증거의 지도처럼 구성합니다. Q39 메모에는 지난달 customer 집합에서 이번 달 집합을 빼는 EXCEPT와 NULL-safe NOT EXISTS가 놓였다. 원문은 문제만 주었기에 fixture도 결과도 만들었다고 하지 않았다. 비정본 예시는 output grain과 nullable 반례를 설명하는 데만 썼다.
그림 한눈에: 같은 customer grain의 두 기간 집합을 안전하게 차집합으로 만듭니다. 목요일, 네 개의 demo 악보가 테이블 위에 펼쳐졌다. 숫자 accountId를 state에 저장하고 첫 요청은 201, 같은 payload replay는 200, 다른 payload는 409, 대사는 mismatch 0으로 끝나는 계약이었다. 하지만 오늘의 도장은 그 연주를 실행하는 도장이 아니었다.
그림 한눈에: numeric accountId에서 201·200 replay·409 conflict까지 목표 계약을 봅니다. p804의 선명한 문장이 소유권을 정했다. D4는 네 script의 존재·bytes·hash와 literal secret 패턴을 감사할 뿐 active DB와 app lifecycle은 D7의 run-w24-release가 소유했다. 따라서 marker 끝은 runtime_claim=false였다.
그림 한눈에: files4·hashes4·literal_secrets0과 runtime_claim=false를 한 source-only 도장으로 분리합니다. 공식 장면컷은 분위기용이며, STARRY의 사건·대사·기술 수치는 원문 감사에 따른 비공식 학습 구성입니다. 금요일, 외부 review 표의 첫 열에는 사람 이름과 시각, 대상 commit이 들어갔다. 다섯 개 이상의 actionable 질문마다 accept·reject·defer, 기술 근거, commit 또는 issue를 연결했다. 행 수와 hash는 표가 있다는 사실만 증명했고 review의 사실성과 판단은 사람이 원본을 대조해야 닫혔다.
그림 한눈에: reviewer identity와 다섯 질문의 결정·근거·후속 연결을 한 계약으로 묶습니다. Q40에서는 status마다 amount 순위를 다시 매겼다. PERCENT_RANK 0.10 이하를 상위 후보로 읽었지만 작은 표본과 cutoff 동률 때문에 정확히 10% 행을 보장하지 않는다고 적었다. 이것도 prompt-only 비정본·미실행 예시였다.
그림 한눈에: status별 percentile과 작은 표본·동률의 결과 cardinality 한계를 함께 봅니다. 토요일, 두 길 앞에 선택표가 놓였다. 공고 적합 40, 관심 20, 자료 15, 팀 기회 15, 완주 위험 10. 증권과 카드의 모든 점수에는 실제 URL과 확인일이 필요했고 사람이 합계를 다시 계산해 서명해야 했다. 화면의 기본 깃발은 증권이었지만, 그것은 사용자가 정한 UI 시작점이지 원문에서 이미 끝난 선택이 아니었다.
그림 한눈에: 가중치 100·근거 URL·사람 검산을 거쳐 정확히 한 track만 고릅니다. 마지막 칠판에는 p813 상단에서 굵은 선이 그어졌다. F01–F15까지만 이번 미리보기에 들어왔다. 아래의 F16 release와 F17 lifecycle, p818–819의 통합과 Green Gate는 실제 실행 소유권을 가진 다음 문이었다.
그림 한눈에: strict D1–D6 F01–F15와 D7 release·lifecycle F16–F17을 분리합니다. 히토리는 하나의 깃발 옆에 적었다. “W24 D1–D6 RUNTIME NOT_RUN. 고른 것처럼 보이는 화면보다 누가 실제로 실행하고 서명했는지가 먼저다.”
W24 미리보기 · 히토리 질문 노트 히토리의 질문 노트 — STARRY PASS 20 본편의 exact test inventory·architecture sequence·README·demo source audit·external review·track 선택 비유를 W24의 정확한 owner와 증거 경계로 다시 연결합니다. 모든 답은 p785–p813 상단 — W24 개요 + D1–D6에 한정합니다. 현재 W24 D1–D6 RUNTIME NOT_RUN·runtimeRunsByPreview=0이며 D4 runtime은 DEFERRED_TO_D7, 사람 검토 상태는 HUMAN_SEMANTIC_REVIEW_REQUIRED입니다.
1. 이번 미리보기의 strict PDF 범위는 어디인가요? 답: p785 W24 개요부터 p813 상단 D6 최종 Mastery Gate까지입니다.
근거: 정확한 표기는 p785–p813 상단 — W24 개요 + D1–D6입니다. overview p785, D1 p786–p791 상단, D2 p791 하단–p794 상단, D3 p794 하단–p797, D4 p798–p806 상단, D5 p806 하단–p809, D6 p810–p813 상단입니다.
오답 함정: W24 전체가 p785–819라는 이유로 p813 하단 D7이나 p818–819 주간 통합·해설·Green Gate를 섞으면 안 됩니다.
범위 한계: p813은 D6와 D7이 함께 있는 혼합 페이지라 문단 경계까지 확인해야 합니다.
실제 기술 이름 mixed-page semantic boundary for W24 overview and D1-D6
2. D1–D6 예상시간 합계와 기본 트랙 표지는 무엇인가요? 답: 합계는 8시간 20분–15시간 50분, 즉 500–950분이며 공통 코어 · 트랙 선택 시 증권 기본입니다.
근거: D1 70–135분, D2 65–125분, D3 100–190분, D4 80–160분, D5 90–170분, D6 95–170분을 더합니다. Q39·Q40 시간은 D3·D5에 이미 포함됩니다.
오답 함정: W24 전체 9시간 20분–17시간 50분은 D7 60–120분을 포함하므로 strict 합계가 아닙니다.
범위 한계: 원문에는 증권 기본값이 없습니다. 증권은 사용자 요청에 따른 UI 기본일 뿐 실제 선택 결과가 아닙니다.
실제 기술 이름 bounded D1-D6 time total with source-neutral securities UI default
3. SOURCE AUDIT PASS는 W24 runtime·외부 review·track 선택 Green인가요? 답: 아닙니다. 현재 상태는 W24 D1–D6 RUNTIME NOT_RUN이고 runtimeRunsByPreview=0입니다.
근거: PASS는 PDF·package·display byte와 정본·비정본 경계를 확인했다는 뜻입니다. Gradle·Docker·HTTP·PostgreSQL·external reviewer·사람 서명을 이 preview가 실행하지 않았습니다.
오답 함정: 코드에 GREEN marker가 보이거나 canonical source가 있다는 이유로 실제 실행 결과로 읽으면 안 됩니다.
범위 한계: D4 runtime은 D7 소유이며 D2·D3·D5·D6의 의미 완료는 사람 검토가 필요합니다.
실제 기술 이름 static source closure versus local runtime and human semantic evidence
4. D1 exact core contract의 고정 숫자는 무엇인가요? 답: selectors=43, classes=37, tests=66이며 failures·errors·skipped는 모두 0입니다.
근거: core-v1-expected.json, exact Gradle selector, verifier와 actual JUnit XML 37개가 같은 class별 test 수를 가리켜야 합니다.
오답 함정: wildcard selector, 0 tests, expected 목록만 존재하는 상태를 Green으로 세면 안 됩니다.
범위 한계: 목록과 source는 계약이며 learner root의 actual XML과 native exit가 없으면 runtime evidence가 아닙니다.
실제 기술 이름 exact Gradle selector and JUnit XML inventory contract
그림 한눈에: D1 · 43 selectors·37 classes·66 tests exact Gate. 5. 왜 expected와 actual class 집합을 양방향으로 비교하나요? 답: 누락된 class와 예상 밖 class를 모두 fail-closed로 잡기 위해서입니다.
근거: actual XML count=37뿐 아니라 sorted expected·actual name set과 각 class의 exact tests를 비교합니다.
오답 함정: 총 test 수 66만 맞으면 class 배치가 달라도 된다고 생각하면 안 됩니다.
범위 한계: selector 43은 실행 대상 계약이고 actual suite의 직접 증거는 XML 37개입니다.
실제 기술 이름 bidirectional expected-actual suite set equality and per-suite counts
6. D1 primary evidence marker와 현재 실행 경계는 무엇인가요? 답: marker는 W24D1_PRIMARY_EVIDENCE_GREEN classes=37 tests=66 failures=0 errors=0 skipped=0 actual_xml=37 sha256=<64-hex>입니다.
근거: actual XML에서 만든 test-inventory.md를 임시 파일에서 원자 이동하고 canonical expectation·gate hash와 연결합니다.
오답 함정: 표시된 marker 문자열을 이 preview가 생성했다고 말하면 안 됩니다.
범위 한계: D1 learner 실행은 NOT_RUN이며 source-local tests=0·testsExecuted=0입니다.
실제 기술 이름 atomic learner test inventory closure with exact XML and hashes
7. D2 architecture pack의 세 sequence는 무엇인가요? 답: 정상 이체, business 처리 뒤 중간 실패, 같은 key·payload의 동시 중복입니다.
근거: 세 흐름 모두 RequestId→Authorization→AtomicClaim→sorted locks→ledger pair→COMPLETE→commit/rollback 경계를 명시합니다.
오답 함정: 성공 흐름만 그리고 실패·중복에서 transaction boundary를 생략하면 안 됩니다.
범위 한계: architecture-pack.pdf의 파일·hash 검사는 다이어그램 의미 Green을 만들지 않습니다.
실제 기술 이름 normal failure and concurrent duplicate transaction sequence architecture
그림 한눈에: D2 · 정상·중간 실패·동시 중복 sequence. 8. D2 정상 sequence의 목표 oracle은 무엇인가요? 답: 출금 9000, 입금 6000, ledger pair 합계 0입니다.
근거: 입력 1000 이체 뒤 두 balance와 debit/credit ledger 합이 transaction 하나에 닫혀야 합니다.
오답 함정: 다이어그램에 숫자가 있다는 사실을 실제 DB 실행 결과로 바꾸면 안 됩니다.
범위 한계: 이는 재검증 목표 관찰값이며 preview runtime은 NOT_RUN입니다.
실제 기술 이름 balanced double-entry transfer success-sequence oracle
9. D2 실패·동시 중복 sequence의 목표 oracle은 무엇인가요? 답: after-business failure는 DB effect 0, 같은 key·payload 20회는 business effect 1과 나머지 replay/existing입니다.
근거: rollback과 atomic claim이 중간 실패와 동시 중복에서 추가 업무 효과를 막아야 합니다.
오답 함정: HTTP 응답 수를 business effect 수와 같다고 세면 안 됩니다.
범위 한계: 실제 동시 실행·DB row evidence는 이 preview에 없습니다.
실제 기술 이름 rollback-zero-effect and atomic-idempotency concurrent replay oracle
10. D2 validator가 자동으로 증명하는 것과 못 하는 것은 무엇인가요? 답: 파일 존재·128 byte 이상·SHA는 확인하지만 ERD·세 sequence의 의미는 증명하지 못합니다.
근거: exact marker는 MANUAL_REVIEW_REQUIRED W24D2 bytes=<actual> sha256=<64-hex>입니다.
오답 함정: 64-hex hash나 exit 0을 사람 review 완료로 해석하면 안 됩니다.
범위 한계: ERD diff, lock order, replay·rollback 설명은 사람이 원문과 대조해야 합니다.
실제 기술 이름 architecture artifact shape-hash validation versus manual semantic review
11. D3 README는 어떤 구조로 다시 쓰나요? 답: 첫 화면의 3문장 문제·정확한 scope·5분 실행 뒤 일곱 risk를 선택·test·결과·한계와 연결합니다.
근거: 원자성·잠금·멱등·대사·query·보안·운영마다 환경·commit·raw evidence 링크를 둡니다.
오답 함정: 기능 목록과 기술 스택만 나열하거나 수치의 환경·근거를 숨기면 안 됩니다.
범위 한계: validator는 40 byte·3 nonblank·placeholder 부재·hash만 보며 의미는 HUMAN_SEMANTIC_REVIEW_REQUIRED입니다.
실제 기술 이름 risk-choice-test-result-limit README evidence topology
그림 한눈에: D3 · 3문장·7 risk·result·limit. 12. Q39는 전월에만 있던 고객을 어떻게 찾나요? 답: 전월 customer 집합에서 당월 customer 집합을 EXCEPT하거나 correlated NOT EXISTS로 제외합니다.
근거: 두 기간 모두 같은 customer grain과 상태 조건으로 DISTINCT한 뒤 차집합을 구합니다.
오답 함정: NOT IN에 nullable 값을 그대로 넣거나 transaction row를 그대로 반환해 고객을 중복시키면 안 됩니다.
범위 한계: 원문 Q39는 prompt-only이며 fixture·정답·실행 결과가 없습니다.
실제 기술 이름 customer-set difference with EXCEPT or NULL-safe NOT EXISTS
그림 한눈에: Q39 · prompt-only EXCEPT·NOT EXISTS·NULL-safe. 13. Q39 답안에서 반드시 공개할 반례와 상태는 무엇인가요? 답: nullable 비교가 UNKNOWN이 되는 반례와 시작 table·output grain·cardinality를 공개하고 비정본·미실행으로 표시합니다.
근거: EXCEPT와 correlated NOT EXISTS는 customer grain을 지키지만 schema 제약과 기간 경계는 답안이 명시해야 합니다.
오답 함정: 코드 뒤풀이 예시를 workbook 제공 정답이나 PostgreSQL 관찰 결과로 부르면 안 됩니다.
범위 한계: 실제 evidence에는 query byte·fixture·row count·result hash가 추가로 필요합니다.
실제 기술 이름 prompt-only SQL difference reasoning with nullable counterexample disclosure
14. D4 demo 계약은 numeric accountId를 왜 state에 저장하나요? 답: 실제 AccountResponse의 long ID를 이후 TransferRequest에 전달하고 metadata 파일을 SQL로 오인하지 않기 위해서입니다.
근거: reset-demo가 응답의 numeric accountId와 baseUrl·runId를 state JSON에 고정합니다.
오답 함정: 표시용 계좌번호나 W8 metadata 파일을 현재 V001 table의 key로 쓰면 안 됩니다.
범위 한계: source 계약을 읽는 것과 실제 app·DB를 띄워 response를 얻는 것은 다릅니다.
실제 기술 이름 numeric account identifier handoff through deterministic demo state
그림 한눈에: D4 계약 · 실제 runtime은 D7로 이관. 15. 201→200→409의 의미는 각각 무엇인가요? 답: 첫 요청은 201·replayed=false, 같은 payload 재요청은 200·replayed=true, 다른 payload는 409 IDEMPOTENCY_CONFLICT입니다.
근거: 세 응답을 같은 runId·idempotency key contract와 연결하고 changed payload의 additional effect는 0이어야 합니다.
오답 함정: replay를 새 이체 성공으로 세거나 409 뒤 원장 행이 더 생겨도 된다고 생각하면 안 됩니다.
범위 한계: 이는 D4가 보여 주는 목표 계약이고 실제 runtime Green은 D7 owner에게 이관됩니다.
실제 기술 이름 idempotent create replay and payload-conflict HTTP contract
16. 대사 mismatch 0은 무엇을 비교하나요? 답: V001 account balance와 ledger_entry의 계좌별 합계를 직접 비교합니다.
근거: reconcile-demo의 목표 marker는 DEMO_RECONCILIATION_GREEN mismatches=0입니다.
오답 함정: metadata 문서나 이전 주 seed를 현재 DB 대사 source로 쓰면 안 됩니다.
범위 한계: D1–D6 preview에는 actual DB row·container·transcript가 없으므로 목표값일 뿐입니다.
실제 기술 이름 account-ledger reconciliation against current V001 tables
17. D4 당일 source audit의 exact marker는 무엇인가요? 답: W24_DEMO_SOURCE_AUDIT files=4 literal_secrets=0 hashes=4 runtime_claim=false입니다.
근거: reset-demo, run-transfer, reconcile-demo, run-w24-demo 네 packaged source의 존재·bytes·SHA와 단순 literal secret 패턴만 봅니다.
오답 함정: files=4·hashes=4를 201·200·409·mismatch0 실행 Green으로 바꾸면 안 됩니다.
범위 한계: source audit 예시 자체도 preview에서 미실행이며 실제 runtime은 DEFERRED_TO_D7입니다.
실제 기술 이름 four-script source identity and literal-secret audit without runtime claim
그림 한눈에: D4 · source-only files4·hashes4·runtime_claim=false. 18. D4 체크리스트와 p804 ownership이 충돌할 때 무엇을 우선하나요? 답: p804의 명시적 ownership을 우선해 D4는 source audit, 실제 demo runtime은 D7로 판정합니다.
근거: 원문은 이 날 active DB/app lifecycle을 소유하지 않으며 W24_DEMO_GREEN은 run-w24-release가 소유한다고 적습니다.
오답 함정: 체크박스의 목표 관찰값을 당일 완료된 실제 결과로 읽으면 안 됩니다.
범위 한계: strict preview는 D7 F16·F17을 제외하므로 release·lifecycle Green을 주장하지 않습니다.
실제 기술 이름 source-conflict resolution by explicit runtime ownership authority
19. demo evidence에서 secret과 identity는 어떻게 다뤄야 하나요? 답: password·Authorization 원문은 남기지 않고 runId·state·세 response·대사 output을 같은 실행으로 연결합니다.
근거: source audit는 literal secret 패턴만 좁게 찾고 transcript redaction은 runtime owner가 별도로 확인해야 합니다.
오답 함정: literal_secrets=0을 모든 secret leakage가 없다는 완전한 보안 증명으로 넓히면 안 됩니다.
범위 한계: 환경 변수·로그 framework·downstream trace의 비밀 노출은 별도 검사 대상입니다.
실제 기술 이름 demo evidence correlation with credential redaction boundary
20. D5 external review가 닫히려면 무엇이 필요한가요? 답: 실제 reviewer·시각·대상 commit과 최소 다섯 actionable 질문, 각 decision·reason·commit/issue, 사람 서명이 필요합니다.
근거: accept·reject·defer를 모두 허용하되 근거와 재검토 조건을 원본 변경에 연결합니다.
오답 함정: self-review를 external review로 적거나 질문 수만 채우고 의미 없는 행을 늘리면 안 됩니다.
범위 한계: 이 preview에는 reviewer identity·서명이 없어 HUMAN_SEMANTIC_REVIEW_REQUIRED입니다.
실제 기술 이름 human-signed external review decision and follow-up evidence contract
그림 한눈에: D5 · reviewer·decision·reason·commit/issue. 21. D5 generic validator가 Green이 아닌 이유는 무엇인가요? 답: 40 byte·3 nonblank·placeholder 부재·SHA는 파일 모양만 보고 reviewer·판단·근거의 사실성을 판정하지 못하기 때문입니다.
근거: LOCAL_ARTIFACT_VALIDATED W24D5는 사람 검토 전 상태이며 external review 완료 marker가 아닙니다.
오답 함정: process exit 0이나 hash를 reviewer 승인으로 바꾸면 안 됩니다.
범위 한계: 최소 다섯 행의 identity·question·decision·reason·link를 사람이 원본과 대조해야 합니다.
실제 기술 이름 structural review-log validation versus human semantic attestation
22. Q40은 상태별 상위 10% 후보를 어떻게 구하나요? 답: status로 partition하고 amount 내림차순의 PERCENT_RANK를 계산해 0.10 이하 후보를 고릅니다.
근거: NTILE을 쓸 수도 있지만 선택한 함수의 정의와 output grain을 설명해야 합니다.
오답 함정: 전체 상태를 한 ranking으로 섞거나 rank 함수를 계산한 같은 SELECT의 WHERE에서 바로 참조하면 안 됩니다.
범위 한계: 원문 Q40은 prompt-only이며 코드 예시는 비정본·미실행입니다.
실제 기술 이름 status-partitioned percentile ranking for high-value candidates
그림 한눈에: Q40 · prompt-only PERCENT_RANK·small sample·ties. 23. Q40에서 정확히 10% 행을 보장할 수 없는 이유는 무엇인가요? 답: 작은 partition과 cutoff 동률 때문에 PERCENT_RANK 0.10 이하의 행 수가 정확히 10%가 아닐 수 있습니다.
근거: 한 행 partition의 PERCENT_RANK는 0이고 동액은 같은 rank를 공유할 수 있습니다.
오답 함정: top 10%라는 말만 보고 결과 행 수를 floor(n×0.1)로 단정하면 안 됩니다.
범위 한계: 정확한 고정 행 수가 요구되면 tie policy와 ROW_NUMBER·NTILE 선택을 별도 계약으로 정해야 합니다.
실제 기술 이름 small-partition and cutoff-tie semantics in percentile ranking
24. D6 track selection의 다섯 가중치는 무엇인가요? 답: 공고 적합 40, 관심 20, 자료 15, 팀 기회 15, 완주 위험 10으로 합계 100입니다.
근거: 증권·카드 각 점수에 실제 공고 또는 학습·협업 근거 URL과 확인일을 붙이고 사람이 가중 합계를 다시 계산합니다.
오답 함정: 가중치 합계나 URL 없이 느낌 점수만 적으면 안 됩니다.
범위 한계: 원문은 선택 방법을 주며 실제 점수·근거·서명은 비어 있습니다.
실제 기술 이름 weighted evidence-backed securities-versus-card track selection rubric
그림 한눈에: D6 · 40·20·15·15·10=100과 사람 검산. 25. 증권 기본값과 실제 track 선택을 어떻게 구분하나요? 답: UI는 증권을 기본 표시하지만 실제 완료는 사람 서명 뒤 증권 또는 카드 정확히 하나를 선택한 상태입니다.
근거: 사용자 기본 설정은 navigation metadata이고 원문 evidence/w24/track-selection.csv의 결과가 아닙니다.
오답 함정: 증권 UI 기본을 D6 점수 계산·근거 검토·사람 서명 완료로 표현하면 안 됩니다.
범위 한계: 실제 선택 결과가 생기면 근거 URL·확인일·합계와 함께 갱신해야 합니다.
실제 기술 이름 UI default metadata separated from human-attested single-track outcome
26. D6 validator의 marker와 의미 경계는 무엇인가요? 답: LOCAL_ARTIFACT_VALIDATED W24D6 bytes=<actual> sha256=<64-hex>이며 의미는 HUMAN_SEMANTIC_REVIEW_REQUIRED입니다.
근거: generic 검사는 존재·40 byte·3 nonblank·placeholder·hash만 보고 weights·score·URL·합계·single selection을 계산하지 않습니다.
오답 함정: CSV 파일이 있다는 이유로 두 track 중 하나가 실제 선택됐다고 말하면 안 됩니다.
범위 한계: criterion·weight·score·evidence와 합계를 사람이 재검산하고 서명해야 완료됩니다.
실제 기술 이름 generic track-artifact validation versus signed semantic selection
27. strict D1–D6과 코드 뒤풀이 전체 범위는 어떻게 다르나요? 답: 미리보기는 p785–p813 상단과 F01–F15이며, F16 release와 F17 lifecycle은 D7 전용이라 제외합니다.
근거: D7은 p813 하단부터 actual core Gate·demo·cleanup·tag 후보를 묶고 p818–819는 주간 통합·해설·Green Gate입니다.
오답 함정: 전체 코드 문서에 W24_RELEASE_GREEN·W24_LIFECYCLE_GREEN이 보인다는 이유로 D1–D6 실행 결과에 넣으면 안 됩니다.
범위 한계: 코드 링크는 full week를 보여 주지만 미리보기의 runtime·서사 경계는 넓어지지 않습니다.
실제 기술 이름 strict preview ownership boundary versus full-week release inventory
그림 한눈에: D1–D6 F01–F15 · D7 F16–F17 제외. 28. modern 코드 inventory 표찰은 어떻게 읽나요? 답: 전체 W24 코드는 17 units, canonical 9개, illustrative 8개이며 strict F01–F15는 canonical 7개·illustrative 8개입니다.
근거: aggregate 17/696/640/0/640/640/68/0/0는 units / physical / nonblank / setup / mapping / translation / chunks / source-local tests / tests executed입니다.
오답 함정: displayed source와 GREEN marker를 실행된 test로 세거나 D7 F16·F17을 strict 범위에 포함하면 안 됩니다.
범위 한계: 현재 source-local tests=0·testsExecuted=0이며 모든 runtimeRunsByPreview도 0입니다.
실제 기술 이름 canonical-illustrative full-week inventory with strict D1-D6 subset accounting
마지막 한 줄 W24의 핵심은 exact 37/66 Gate, 세 architecture 흐름, source-only demo audit, reviewer와 단일 track의 사람 검토를 한 commit에 연결하되 D7이 소유한 runtime Green과 UI 기본값을 실제 완료로 넓혀 말하지 않는 것입니다.
