Files

T

DongHyeonka d6dfda64ab docs(branch): 기존 7개 노트를 개정 결정·신규 위임에 정합

- REGISTRY-001 Summary 문자열 4곳 (additive, revision 은 1 유지).
  registry-governance 는 본문 서술 12곳의 '8개'도 함께 9개로 갱신
- OFFLINE-CACHE-001 pin @1->@2 와 Summary·적용점 (behavior-change)
- DELEG-FE-007~011 delegate 5곳 접수 완료 — 미접수 위임 0건
- runtime-schema-validation 이 FLOW-FE-EVENT-003/004 소유를 명시
- env-runtime-config 가 FE-REG-CAPABILITY registry 와 FE-GATE-033 gate
  owner 를 취득하고 claim 2건 추가
- 신규 6개 노트의 delegation pin 을 기존 @1 형식으로 정규화

2026-07-28 14:40:38 +09:00

26 KiB

Raw Blame History

title, source_type, status, branch, parent_branch, related_projects, governing_docs, tags, created, target_merge, status_label, id, kind, project, work_item, inherits, accepts_delegations, refines, overrides, depends_on, contract_packet, contract_packet_sha256, imports

title

source_type

status

branch

parent_branch

related_projects

governing_docs

branch: feature-runtime-schema-validation-contract

Layer: raw/branch-notes/ — 단일 브랜치의 TODO·결정·진행 기록. 머지/종료 후 verified 결과는 /ingest로 wiki/projects/에 추출한다.

부모 (필수)

raw/project-notes/ca-skeleton-frontend-operational-contract

브랜치 계약 패킷

생성 시 프로젝트 개정: 1
패킷 스키마: contract_packet: 1
완료 조건: content-type·JSON·envelope·payload invalid fixture가 기대 failure kind로 정규화된다

상속한 프로젝트 결정

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

브랜치 지역 결정

기존 branch-local 결정은 아래 ## Decision Evidence Map / 결정-근거 매핑의 D-row가 소유하며 이 packet에서 복제하지 않는다.

Decision ID	Decision	Relation	Supporting Claims	Status

선언한 예외

Override ID	Overrides	Reason	Approval	Status

목표

이 브랜치는 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:

범위

포함 범위

응답 경계 검증의 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 한다.
인바운드 이벤트 경계 검증 — hub §2.1.4 FLOW-FE-EVENT-003@1(event envelope 공유 스키마 검증; non-throwing) · FLOW-FE-EVENT-004@1(eventSchema per-event 검증; 미검증 프레임은 EVENT_SCHEMA_MISMATCH 로 드롭하고 application 에 도달시키지 않는다)의 owner 는 본 branch 다. 요청/응답과 달리 스트림에는 요청이 없고 재개 커서가 있으므로 FLOW-FE-RESP-* 와 순서를 합치지 않는다. 프레임 수신·transport decode(stage 1~2)는 raw/branch-notes/feature-frontend-realtime-subscription-lifecycle-contract 소유이고, codec 디코드 이후 payload 검증은 raw/branch-notes/feature-frontend-multi-protocol-api-transport-contract 가 DELEG-FE-010@1 로 본 branch 에 위임했다.
각 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에서 파생된 자료)

가져온 흐름 단계

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

수신한 위임

Delegation Ref	From	Concern	Status
`DELEG-FE-010@1`	raw/branch-notes/feature-frontend-multi-protocol-api-transport-contract	`fe.deleg.decoded-payload-validation`	accepted

가져온 프로젝트 계약

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 참조로 적용

Sub-branches (세부 작업)

없음 — scaffolding 단계

오류 기록 (이 branch 작업 중 발생)

없음 — scaffolding 단계

면접 준비 (이 작업에서 나올 수 있는 면접 질문)

없음 — scaffolding 단계

강의 (이 작업을 위해 학습한 강의)

없음 — scaffolding 단계

job-posting tie-ins (이 작업에서 파생된 글감)

없음 — scaffolding 단계

완료 후 정리

PR 링크:
리뷰 메모:
머지 결과 / 배포 환경:
wiki 추출 대상 (verified만, wiki/projects/로만 추출):
- actually-implemented 항목:
- locally-verified 항목:
- prod-verified 항목:
추출하지 않을 항목 (planned / documented-only / abandoned):

26 KiB Raw Blame History

branch: feature-runtime-schema-validation-contract

부모 (필수)

브랜치 계약 패킷

상속한 프로젝트 결정

브랜치 지역 결정

선언한 예외

목표

범위

포함 범위

제외 범위

근거 (필수, 최소 1개+)

TODO

진행 중 메모

결정 사항

결정-근거 매핑

구현 가이드

1. 4-stage boundary validation pipeline (adapters/http)

2. 스키마 작성·배치 규약

3. 검증 실패 → safe 신호 매핑 (redaction)

4. outbound requestSchema 검증

5. compatibility posture (additive tolerance)

엣지·실패·의존

검증해야 할 주장

관심사 커버리지 (coverage-auditor 자동 생성 — 있을 때)

마주친 문제

묶음 (이 branch에서 파생된 자료)

가져온 흐름 단계

수신한 위임

가져온 프로젝트 계약

Sub-branches (세부 작업)

오류 기록 (이 branch 작업 중 발생)

면접 준비 (이 작업에서 나올 수 있는 면접 질문)

강의 (이 작업을 위해 학습한 강의)

job-posting tie-ins (이 작업에서 파생된 글감)

관련 일일 노트

완료 후 정리

26 KiB

Raw Blame History