fix: 하네스 제거 및 keycloak 문서 보강

This commit is contained in:
DongHyeonka
2026-07-25 12:53:13 +09:00
parent 6c53ded9cb
commit d71669eb59
2329 changed files with 138239 additions and 172816 deletions
@@ -1 +0,0 @@
../../vault/10-projects/ca-skeleton-frontend-operational-contract/branch-notes/feature-runtime-schema-validation-contract.md
@@ -0,0 +1,293 @@
---
title: branch / feature-runtime-schema-validation-contract
source_type: branch-note
status: raw
branch: feature-runtime-schema-validation-contract
parent_branch:
related_projects: [ca-skeleton-frontend, ca-skeleton]
governing_docs: [raw/project-notes/ca-skeleton-frontend-operational-contract.md]
tags: [branch, ca-skeleton, frontend, validation, integration, javascript, json]
created: 2026-07-18
target_merge:
status_label: in-progress
id: BR-CA-SKELETON-FRONTEND-OPERATIONAL-CONTRACT-006
kind: project-work-item
project: ca-skeleton-frontend-operational-contract
work_item: WI-CA-SKELETON-FRONTEND-OPERATIONAL-CONTRACT-006
inherits: [DEC-CA-SKELETON-FRONTEND-OPERATIONAL-CONTRACT-VALIDATION-001@1]
refines: []
overrides: []
depends_on: [WI-CA-SKELETON-FRONTEND-OPERATIONAL-CONTRACT-005]
contract_packet: 1
contract_packet_sha256: 489734960b06bb60f76ac96b8ad7f49731c8bb8d11e7b9de7e53af63d746b6a2
imports: [FE-OC-006@1, FE-OC-008@1, FE-OC-023@1, FE-OC-024@1, FLOW-FE-RESP-001@1, FLOW-FE-RESP-002@1, FLOW-FE-RESP-003@1, FLOW-FE-RESP-007@1, FLOW-FE-RESP-008@1]
---
# branch: feature-runtime-schema-validation-contract
> Layer: `raw/branch-notes/` — 단일 브랜치의 TODO·결정·진행 기록. 머지/종료 후 verified 결과는 `/ingest`로 `wiki/projects/`에 추출한다.
<!-- section-id: branch-parent -->
## 부모 (필수)
- [[raw/project-notes/ca-skeleton-frontend-operational-contract]]
<!-- GENERATED: branch-contract:start -->
<!-- section-id: branch-contract-packet -->
## 브랜치 계약 패킷
- **생성 시 프로젝트 개정**: `1`
- **패킷 스키마**: `contract_packet: 1`
- **완료 조건**: content-type·JSON·envelope·payload invalid fixture가 기대 failure kind로 정규화된다
<!-- section-id: inherited-project-decisions -->
### 상속한 프로젝트 결정
| Decision Ref | Project Summary | Branch Application | Source |
|---|---|---|---|
| `DEC-CA-SKELETON-FRONTEND-OPERATIONAL-CONTRACT-VALIDATION-001@1` | boundary runtime validation은 Zod schema로 수행한다 | Work Item 완료 조건에 적용 | [[raw/project-notes/ca-skeleton-frontend-operational-contract]] |
<!-- section-id: branch-local-decisions -->
### 브랜치 지역 결정
> 기존 branch-local 결정은 아래 `## Decision Evidence Map / 결정-근거 매핑`의 D-row가 소유하며 이 packet에서 복제하지 않는다.
| Decision ID | Decision | Relation | Supporting Claims | Status |
|---|---|---|---|---|
<!-- section-id: declared-overrides -->
### 선언한 예외
| Override ID | Overrides | Reason | Approval | Status |
|---|---|---|---|---|
<!-- GENERATED: branch-contract:end -->
<!-- section-id: branch-goal -->
## 목표
이 브랜치는 project-wide 계약 `FE-OC-007`(JSON envelope와 payload는 boundary에서 runtime schema를 MUST 통과)을 구현 착수 가능한 상세 명세로 내린다. 스켈레톤은 컴파일 타임 타입 보장이 없는 plain JavaScript ESM 이므로([[raw/project-notes/ca-skeleton-frontend-operational-contract]] FE-D002), 컴파일러가 API 응답 같은 경계 데이터의 형태를 보장할 수 없다. 그 빈자리를 HTTP 경계의 런타임 스키마 검증 계층으로 채우며, 검증 라이브러리는 Zod 로 고정한다([[raw/project-notes/ca-skeleton-frontend-operational-contract]] FE-D007). 이 검증 계층이 방출하는 실패 신호는 `FE-OC-008`(failure normalization)과 `FE-OC-023`(schema compatibility) 계약이 소비하는 입력이 된다. 프런트엔드 코드는 아직 존재하지 않으므로 본 노트의 모든 구현 주장 등급은 `planned` 이다.
- 이슈:
- PR:
<!-- section-id: branch-scope -->
## 범위
### 포함 범위
- 응답 경계 검증의 4-stage gate 정의 — `FE-OC-007`, hub §7.3 processing order stage 2~6: (2) content-type 검사, (3) JSON parse, (4) envelope schema, (5) success/failure 분기, (6) payload schema.
- 이 중 **stage 4~6 의 owner 는 본 branch** 다 — hub §2.1.4 Flow Stage Registry `FLOW-FE-RESP-004@1`(envelope 공유 스키마 검증; 경계 검증은 `.safeParse()` non-throwing 이며 throw 를 상위로 누출하지 않는다) · `FLOW-FE-RESP-005@1`(success/failure 분기 검증; 200 이어도 envelope 이 invalid 하면 success 로 반환하지 않는다) · `FLOW-FE-RESP-006@1`(payload per-operation 스키마 검증; payload invalid 는 `SCHEMA_MISMATCH` 이고 mapper 는 검증 통과분만 받는다). 이 세 단계의 Invariants 를 바꾸려면 본 branch 가 revision 을 올려야 한다. stage 2~3 은 [[raw/branch-notes/feature-api-client-response-envelope-contract]] 소유라 `imports` 로만 pin 한다.
- 각 stage 실패를 4종의 구분된 raw failure 신호로 방출 — CONTENT_TYPE_MISMATCH / MALFORMED_JSON / ENVELOPE_MISMATCH / SCHEMA_MISMATCH (hub §8.2, `FE-OC-008` 기여).
- Zod 스키마 작성 규약 — envelope 공유 스키마 1개 + operation별 payload 스키마, `FE-REG-API` responseSchema 참조 (hub §5.3).
- 경계에서 `.safeParse()`(non-throwing) 사용 — 검증 실패가 throw 로 presentation 까지 누출되지 않고 normalized 실패로 매핑되도록.
- Outbound requestSchema 검증 — params/search/body 를 전송 전 operation requestSchema 로 검증 (hub §5.3).
- 4종 invalid fixture(content-type/JSON/envelope/payload) → 기대 kind 매핑 (§20 Measurable completion).
- payload additive-tolerance posture — `FE-OC-023` 기여 (정책 자체는 위임, 아래 Out of scope).
### 제외 범위
- normalized failure 의 최종 shape·userMessageKey·severity·action·UX·telemetry 매핑 → `FE-OC-008` owner [[raw/branch-notes/feature-frontend-error-classification-boundary-contract]] 소유(`FE-REG-ERROR`). 본 branch 는 stage 신호와 safe issue subset 까지만.
- shared HTTP client 자체(transport, timeout, abort, retry, request context) → `FE-OC-006` owner [[raw/branch-notes/feature-api-client-response-envelope-contract]].
- runtime config 검증(hub §6.4)은 별개 경계 → `FE-OC-004` owner [[raw/branch-notes/feature-frontend-env-runtime-config-contract]].
- DTO → application model mapper(processing order stage 7, `FLOW-FE-RESP-007@1`) → [[raw/branch-notes/feature-boundary-mapper-viewmodel-contract]] (`FE-OC-024`, `FE-OC-007` 기여). 본 branch 는 검증된 DTO 를 mapper 에 넘기는 데까지만.
- schema breaking/additive 분류·migration·version bump 정책 → `FE-OC-023` owner [[raw/branch-notes/feature-frontend-contract-compatibility-governance]].
- form input 런타임 검증 — 현재 hub 에 대응 `FE-OC` 계약 없음. 필요 시 신규 제안(planned)으로만 다룬다(임의 확대 금지).
## 근거 (필수, 최소 1개+)
| Source | 정당화하는 결정 |
|---|---|
| [[raw/official-docs/zod-runtime-schema-validation-official]] | D1 Zod 채택(`ZOD-VALID-C2` plain JS 동작), D2·D5 `.parse()` 검증 관문(`ZOD-VALID-C3`), D3 `.safeParse()` non-throwing 경계(`ZOD-VALID-C4`·`ZOD-VALID-C5`) |
| [[raw/project-notes/ca-skeleton-frontend-operational-contract]] | 계약 `FE-OC-007` + 결정 FE-D007(Zod) + processing order §7.3 + failure matrix §8.2 + error enum §5.6 — D2·D4·D5·D6 의 project-decision 근거 |
## TODO
- [ ] envelope 공유 스키마(success/failure discriminated union) + operation payload 스키마 작성 규약 확정 — 등급: `planned`
- [ ] adapters/http 4-stage boundary validation pipeline 명세 — 등급: `planned`
- [ ] 4종 invalid fixture(content-type/JSON/envelope/payload) → 기대 kind 매핑 테스트 — 등급: `planned`
- [ ] ZodError → safe issue path/count 매핑(redaction) — 등급: `planned`
- [ ] outbound requestSchema 검증 wiring — 등급: `planned`
- [ ] payload additive-tolerance 정책 확인(`FE-OC-023` 위임 경계 확정) — 등급: `planned`
## 진행 중 메모
`/branch-spec` fill 완료(2026-07-19). 프런트엔드 repo 부재 — 전 항목 `planned`. hub + zod official-doc 만을 SSOT 로 사용, 근거 없는 사실 미기재.
## 결정 사항
- 2026-07-18: boundary runtime validation 을 Zod 로 수행 / 이유: plain JS 는 컴파일 타임 타입 보장이 없어 경계의 외부 데이터 형태를 런타임에 강제해야 함 / 검토한 대안: Yup·ajv·io-ts·generated schema / 언제 대안: bundle budget 초과 또는 generated schema pipeline 필요 시 / 근거: [[raw/project-notes/ca-skeleton-frontend-operational-contract]] FE-D007 + zod 공식 문서 `ZOD-VALID-C2`.
- 2026-07-18: 검증 지점은 shared HTTP adapter 경계 하나(adapters/http) — call-site 개별 검증 금지 / 근거: hub §7.3 processing order + §4.2 component responsibility.
- 2026-07-18: 경계에서 `.safeParse()`(non-throwing) default, `.parse()`(throw)는 이미 정규화 catch 안에서만 / 근거: hub §8 total-function 규칙 + `ZOD-VALID-C4`·`ZOD-VALID-C5`.
- 2026-07-18: 4 stage 를 4종 구분 kind 로 매핑(content-type/JSON/envelope/payload) / 근거: hub §8.2 failure matrix + §5.6 error enum(enum 소유는 `FE-REG-ERROR`).
- 2026-07-18: envelope 스키마 1개 공유(먼저) → payload 스키마 per-operation(다음) / 근거: hub §7.3 + §5.3 responseSchema.
- 2026-07-18: payload 는 additive 미지 필드 tolerate, envelope 필수 필드 strict / 정책 owner 는 `FE-OC-023` / 근거: hub §6.4 strict 선례 + `FE-OC-023`.
## 결정-근거 매핑
> 각 결정과 raw source Claim ID 의 연결. `Decision ID` 는 이 branch-note 안에서 안정적으로 유지한다.
| Decision ID | Decision | 선택 조건 (언제 이 결정 / 언제 대안) | Supporting Claims | Evidence Strength | Open Risk |
|---|---|---|---|---|---|
| D1 | 경계 런타임 검증 라이브러리 = Zod (본 branch 가 소유하는 결정 FE-D007) | bundle budget 이 허용하고 generated schema pipeline 이 불필요한 동안 Zod default; bundle budget 초과 또는 generated schema pipeline 필요 시 lighter/generated validator 로 재검토 | `zod-runtime-schema-validation-official.md#ZOD-VALID-C2`, `#ZOD-VALID-C3`, `#ZOD-VALID-C4`; [[raw/project-notes/ca-skeleton-frontend-operational-contract]] FE-D007 | official-doc + project-decision (accepted-documented-only) | accepted-documented-only — bundle 크기·코드 evidence 없음 |
| D2 | 검증은 shared HTTP adapter 경계(adapters/http)에서만 실행, §7.3 processing order stage 2~6 으로 | 고정 invariant — shared client 경계(`FE-OC-006`)에서만; per-call-site 검증은 registry violation 이라 대안 분기 없음 | [[raw/project-notes/ca-skeleton-frontend-operational-contract]] §7.3 · §4.2 · §4.4; `zod-runtime-schema-validation-official.md#ZOD-VALID-C3` | project-decision + official-doc | shared client(`FE-OC-006`) wiring 존재에 의존; client 파이프라인 변경 시 삽입 지점 이동 |
| D3 | 경계에서 `.safeParse()`(non-throwing) default, `.parse()`(throw)는 정규화 catch 내부 한정 | 실패를 normalized kind 로 변환해야 하는 경계 지점 = safeParse; 이미 정규화 catch 가 감싸는 내부 지점에 한해 parse+catch 허용 | `zod-runtime-schema-validation-official.md#ZOD-VALID-C4`, `#ZOD-VALID-C5`; [[raw/project-notes/ca-skeleton-frontend-operational-contract]] §8.2 total-function | official-doc + project-decision | ZodError → safe issue path 매핑이 raw value 를 누출하면 안 됨(`FE-OC-008` 과 공동 소유) |
| D4 | 4 stage 를 4종 구분 kind 로 방출: content-type→CONTENT_TYPE_MISMATCH, JSON→MALFORMED_JSON, envelope→ENVELOPE_MISMATCH, payload→SCHEMA_MISMATCH | §8.2·§7.3 로 고정; 단일 generic parse kind 로 병합은 fixture 별 기대 kind 매핑(Measurable completion) 위반이라 거부 | [[raw/project-notes/ca-skeleton-frontend-operational-contract]] §8.2 · §7.3 · §5.6 | project-decision | kind enum 은 `FE-REG-ERROR`(`FE-OC-008` owner) 소유; 이름 변경 시 fixture 갱신 필요 |
| D5 | envelope 스키마 1개(공유 discriminated union) 먼저(stage 4/5) → payload 스키마 per-operation(stage 6), `FE-REG-API` responseSchema 참조 | 200 이어도 envelope·payload invalid 면 success 반환 금지(SCHEMA_MISMATCH); backend envelope 형태 변경은 `FE-OC-023` compatibility 사건으로 재검토 | [[raw/project-notes/ca-skeleton-frontend-operational-contract]] §7.3 envelope shapes · §5.3 responseSchema; `zod-runtime-schema-validation-official.md#ZOD-VALID-C5` | project-decision + official-doc | 공유 envelope surface — backend 계약 변경이 전 operation 에 파급 |
| D6 | payload 는 additive 미지 필드 tolerate(forward-compatible), envelope 필수 필드는 strict | additive 필드가 검증을 깨지 않게 하되 additive vs breaking 분류가 바뀌면 `FE-OC-023` 정책을 따름 | [[raw/project-notes/ca-skeleton-frontend-operational-contract]] `FE-OC-023` · §6.4 strict 선례 | project-decision (정책 위임); 메커니즘은 UNSUPPORTED_IMPL | Zod object 의 strip/passthrough/strict default 는 archived claim 에 없음 → 로컬 검증 필요 |
## 구현 가이드
> 결정에서 도출된 `planned` blueprint. 프런트엔드 코드 부재이므로 경로·이름은 hub §4.6 planned blueprint / §5.1 registry owner map 에서 grounded 하되 전체는 `planned`.
### 1. 4-stage boundary validation pipeline (adapters/http)
> **Trace**: D2 + D4 + D5 · `FE-OC-007` (hub §7.3 processing order stage 2~6, §8.2 failure matrix)
>
> - **UNSUPPORTED_IMPL_DECISION**: content-type 매칭 규칙(`application/json` prefix match vs exact)과 JSON parse 메커니즘(`response.text()` + `JSON.parse` vs `response.json()`)은 archived claim 없음. prefix match + try/catch 를 제안 — trade-off: 단계 분리를 명시화해 fixture 별 kind 매핑이 쉬워지나 표준 근거가 아닌 임의 선택.
| Stage | Check | 메커니즘 (planned) | 실패 kind | Negative fixture |
|---|---|---|---|---|
| 1 transport | HTTP 완료 — 본 branch 범위 밖 | (owned by `FE-OC-006`) | network kinds (위임) | — |
| 2 content-type | operation 기대 media type 과 응답 Content-Type 비교 | `application/json` prefix match (UNSUPPORTED_IMPL) | CONTENT_TYPE_MISMATCH | JSON operation + `text/html` 응답 (§8.5) |
| 3 JSON parse | body 를 JSON 으로 파싱 | try/catch around JSON.parse (UNSUPPORTED_IMPL) | MALFORMED_JSON | not-valid-JSON body |
| 4 envelope | envelope discriminated union `.safeParse()` | Zod object {success, data\/error, meta} | ENVELOPE_MISMATCH | top-level envelope 필드 누락 |
| 5 success/failure 분기 | `success` 판별자 분기; false 면 error envelope shape 검증 | discriminated union on `success` | ENVELOPE_MISMATCH (분기 형태 불일치); 정상 failure 는 status 기반 kind (§8.2, 위임) | success:false + malformed error envelope |
| 6 payload | operation responseSchema `.safeParse()` | Zod payload schema (`FE-REG-API` responseSchema) | SCHEMA_MISMATCH | 200 + payload 필드 타입 불일치 |
| 7 mapper | DTO → application model — 본 branch 범위 밖 | (delegated) | UNKNOWN_FAILURE catch-all | [[raw/branch-notes/feature-boundary-mapper-viewmodel-contract]] `FE-OC-024` |
stage 1·7 은 다른 branch 소유이므로 detail 을 여기서 명세하지 않고 owner 를 가리킨다(R3).
### 2. 스키마 작성·배치 규약
> **Trace**: D1 + D5 · `FE-OC-007` + `FE-REG-API` responseSchema/requestSchema (hub §5.3)
>
> - **UNSUPPORTED_IMPL_DECISION**: 스키마 파일 위치 — hub §4.6 blueprint 에 schemas 디렉터리가 없음. envelope 공유 스키마 `src/adapters/http/response-envelope-schema.js`, operation payload/request 스키마 `src/adapters/http/schemas/<operation>.js` 를 제안 — trade-off: envelope/schema mapping 을 소유한 adapters/http(§4.2)에 배치해 layering 은 유지되나 정확한 경로는 repo 생성 시 확정.
- **envelope 스키마**(공유, 1개) — success branch {success: literal true, data, meta{requestId, traceId, correlationId?}}, failure branch {success: literal false, error{code, category, message, retryable, details?}, meta{requestId, traceId}} (hub §7.3 shapes).
- **payload/request 스키마**(operation별) — 이름은 §5.3 initial planned rows 에서 grounded: responseSchema `SampleResourceListPayload`·`SampleResourcePayload`, requestSchema `SampleResourceListQuery`·`CreateSampleResourceCommand`. body 없으면 requestSchema explicit `none`.
- operation → 스키마 참조의 registry(`FE-REG-API`)는 `FE-OC-006` owner 가 소유 — 본 branch 는 참조 대상 스키마의 shape/규약만 소유(R3).
### 3. 검증 실패 → safe 신호 매핑 (redaction)
> **Trace**: D3 + D4 · `FE-OC-007` → `FE-OC-008` 기여 (hub §8.1 normalized shape, §8.2 telemetry rule)
>
> - **UNSUPPORTED_IMPL_DECISION**: `.safeParse()` result.error(ZodError)에서 추출할 정확한 필드 shape — archived claim 은 "granular information"(`ZOD-VALID-C4`)까지만. {schemaId, issuePathCount, safeIssuePaths[]} 만 추출하고 raw value 제외를 제안 — trade-off: §8.2 SCHEMA_MISMATCH telemetry rule("schema ID + safe issue path count")과 일치하나 issue path 직렬화 세부는 로컬 검증 필요.
- ENVELOPE_MISMATCH telemetry: schema version, no body (§8.2).
- SCHEMA_MISMATCH telemetry: schema ID + safe issue path count (§8.2).
- normalized failure 에 raw body/value/token/authorization header/full URL/stack 포함 금지 (§8.1).
- 최종 normalized failure shape·userMessageKey·action·severity·UX 는 [[raw/branch-notes/feature-frontend-error-classification-boundary-contract]] `FE-OC-008` owner 소유로 위임(R3) — 본 branch 는 stage 신호 + safe issue subset 까지만.
### 4. outbound requestSchema 검증
> **Trace**: D5 (requestSchema 필드) · `FE-OC-007` + `FE-REG-API` (hub §5.3 "params/search도 검증")
>
> - **UNSUPPORTED_IMPL_DECISION**: outbound requestSchema 실패의 normalized kind — hub §8.2 에 "로컬 outbound schema 실패" row 없음. 개발자 계약 위반이므로 요청 전송 없이 즉시 실패시키고 kind 는 `FE-OC-008` owner 와 협의(잠정 UNKNOWN_CLIENT_FAILURE 또는 전용 kind)를 제안 — trade-off: 사용자 노출 실패가 아니라 개발 단계 검출용이므로 별도 kind 없이 throw + test 로 처리 가능.
- params/search/body 를 send 전 operation requestSchema 로 검증. body 없으면 explicit `none`(§5.3).
### 5. compatibility posture (additive tolerance)
> **Trace**: D6 · `FE-OC-007` → `FE-OC-023` 기여 (hub §6.4 strict 선례)
>
> - **UNSUPPORTED_IMPL_DECISION**: Zod object 의 unknown-key 처리(strip/passthrough/strict) default — archived claim 없음(zod 문서는 parse/safeParse/ZodError 만 발췌). payload 는 unknown 필드 tolerate(additive-safe), envelope 는 strict 를 제안 — trade-off: additive backend 필드가 검증을 깨지 않으나 정확한 Zod 구성은 로컬 검증 필요.
> - **R3(OUT_OF_BRANCH_SCOPE)**: additive vs breaking 분류·migration·version bump 규칙은 [[raw/branch-notes/feature-frontend-contract-compatibility-governance]] `FE-OC-023` owner 소유 — 여기서 정하지 않음.
## 엣지·실패·의존
- **실패·엣지 경로**:
- 200 status 인데 JSON/envelope/payload invalid → success 로 반환하지 않고 각 stage kind 로 실패 (§7.3).
- 4xx/5xx body 가 invalid → status 기반 safe fallback error 생성, raw body 폐기 (§7.3). status → kind 매핑 자체는 §8.2(`FE-OC-008` 소유).
- 정상 실패 envelope(success:false) → SCHEMA_MISMATCH 아님; error envelope shape 검증 후 status 기반 kind 로 매핑.
- 빈 body / body 없는 operation(requestSchema `none`) → payload 검증 skip, envelope 검증만.
- validator/mapper 자체 throw → 최종 catch-all UNKNOWN_FAILURE (§8.2 total function); throw 를 presentation 으로 통과시키는 경로 금지.
- deep clone(대량 payload) 비용 — `ZOD-VALID-C3` 은 deep clone 을 명시하나 성능은 증명 안 함 → Claims To Verify 로 이월.
- **다른 계약 의존**:
- [[raw/branch-notes/feature-api-client-response-envelope-contract]] 의 shared client 경계 `FE-OC-006` 을 consume — 검증은 이 client 응답 파이프라인 stage 2~6 에 삽입. `FE-REG-API` responseSchema/requestSchema 필드 변경 시 본 branch wiring 영향.
- [[raw/branch-notes/feature-frontend-error-classification-boundary-contract]] 에 `FE-OC-008` 기여 — 4종 kind + normalized shape + UX/telemetry 소유.
- [[raw/branch-notes/feature-frontend-contract-compatibility-governance]] 에 `FE-OC-023` 기여 — schema additive/breaking 정책 소유.
- [[raw/branch-notes/feature-boundary-mapper-viewmodel-contract]] 가 검증된 payload(stage 7)를 consume — raw DTO 직접 사용 금지(`FE-OC-007` 기여).
- [[raw/branch-notes/feature-sample-feature-slice-contract-fixture]] 가 sample operation 스키마로 이 gate 를 관통(`FE-OC-024`).
## 검증해야 할 주장
| Claim | Why uncertain | How to verify | Status |
|---|---|---|---|
| 4종 invalid fixture(content-type/JSON/envelope/payload)가 각각 기대 kind 로 매핑됨 | 코드 없음; 매핑은 planned 명세뿐 | §20 measurable: content-type/JSON/envelope/payload invalid fixture 테스트(`FE-GATE-004` schema report) | `needs-confirmation` |
| `.safeParse()` 경로가 어떤 invalid 응답에서도 throw 를 presentation 으로 누출하지 않음(total function) | zod 는 ZodError 를 throw 가능(`ZOD-VALID-C4`); safeParse 사용이 코드로 강제되는지 미검증 | catch-all UNKNOWN_FAILURE fixture + throw 누출 negative test (§8.2) | `needs-confirmation` |
| payload additive 미지 필드가 SCHEMA_MISMATCH 를 유발하지 않음(forward-compatible) | Zod unknown-key default 가 archived claim 에 없음 | additive-field fixture 통과 확인 + `FE-OC-023` compatibility fixture | `needs-confirmation` |
| envelope → payload 순서로 200 + invalid payload 가 success 로 반환되지 않음 | 처리 순서는 §7.3 명세뿐, 코드 없음 | 200 + invalid payload fixture → SCHEMA_MISMATCH 기대 | `needs-confirmation` |
| ZodError → safe issue subset 매핑이 raw value/PII 를 누출하지 않음 | granular info 추출 시 원본 값 포함 위험(`ZOD-VALID-C4`) | redaction negative test(raw body/stack 누출 검사, §8.2 · `FE-OC-008`) | `needs-confirmation` |
| deep clone 검증 성능이 boundary budget 내 | `ZOD-VALID-C3` deep clone 비용 미증명 | 대량 payload 벤치(`FE-GATE-004` timing fixture 는 config 소유 — 협업) | `needs-confirmation` |
## 관심사 커버리지 (coverage-auditor 자동 생성 — 있을 때)
> `/coverage`가 채우는 생성물이며 손으로 유지하지 않는다.
| 관심사 | 상태 | owner | 심각도 | 근거 |
|---|---|---|---|---|
| TODO — `/coverage` 실행 전 | missing | (없음) | 미평가 | TODO |
## 마주친 문제
없음 — scaffolding 단계
## 묶음 (이 branch에서 파생된 자료)
<!-- GENERATED: flow:start -->
### 가져온 흐름 단계
| Stage Ref | Order | Owner | Input | Action | Output |
|---|---:|---|---|---|---|
| `FLOW-FE-RESP-001@1` | 1 | [[raw/branch-notes/feature-api-client-response-envelope-contract]] | HTTP 요청 | transport 완료 대기 | raw Response |
| `FLOW-FE-RESP-002@1` | 2 | [[raw/branch-notes/feature-api-client-response-envelope-contract]] | raw Response | content-type 기대값 검사 | 본문 판독 가능 Response |
| `FLOW-FE-RESP-003@1` | 3 | [[raw/branch-notes/feature-api-client-response-envelope-contract]] | 본문 판독 가능 Response | JSON parse | unvalidated JSON |
| `FLOW-FE-RESP-007@1` | 7 | [[raw/branch-notes/feature-boundary-mapper-viewmodel-contract]] | 검증된 payload | DTO → application model 매핑 | application model |
| `FLOW-FE-RESP-008@1` | 8 | [[raw/branch-notes/feature-frontend-error-classification-boundary-contract]] | application model 또는 실패 신호 | 정규화된 결과 반환 | application result 또는 normalized failure |
<!-- GENERATED: flow:end -->
<!-- GENERATED: project-contract-imports:start -->
## 가져온 프로젝트 계약
| Ref | Owner | 요약 | Branch 적용 |
|---|---|---|---|
| `FE-OC-006@1` | [[raw/branch-notes/feature-api-client-response-envelope-contract]] | 모든 HTTP는 shared client를 MUST 통과하고 timeout·abort·response parsing을 page에서 구현하면 안 됨 | import 참조로 적용 |
| `FE-OC-008@1` | [[raw/branch-notes/feature-frontend-error-classification-boundary-contract]] | 모든 failure는 stable frontend error kind로 MUST 정규화하고 raw body·stack을 UI에 노출하면 안 됨 | import 참조로 적용 |
| `FE-OC-023@1` | [[raw/branch-notes/feature-frontend-contract-compatibility-governance]] | API/config/storage/release schema의 breaking change는 migration 또는 version bump 없이 배포하면 안 됨 | import 참조로 적용 |
| `FE-OC-024@1` | [[raw/branch-notes/feature-sample-feature-slice-contract-fixture]] | sample은 contract fixture이며 production feature가 의존하면 안 됨 | import 참조로 적용 |
<!-- GENERATED: project-contract-imports:end -->
### Sub-branches (세부 작업)
없음 — scaffolding 단계
### 오류 기록 (이 branch 작업 중 발생)
없음 — scaffolding 단계
### 면접 준비 (이 작업에서 나올 수 있는 면접 질문)
없음 — scaffolding 단계
### 강의 (이 작업을 위해 학습한 강의)
없음 — scaffolding 단계
### job-posting tie-ins (이 작업에서 파생된 글감)
없음 — scaffolding 단계
## 관련 일일 노트
없음 — scaffolding 단계
## 완료 후 정리
- PR 링크:
- 리뷰 메모:
- 머지 결과 / 배포 환경:
- **wiki 추출 대상** (verified만, `wiki/projects/`로만 추출):
- `actually-implemented` 항목:
- `locally-verified` 항목:
- `prod-verified` 항목:
- **추출하지 않을 항목** (planned / documented-only / abandoned):