v0.18.0 아키텍처 리팩터링 총괄 — 목표 구조·63개 이슈·6개 분야·5개 Phase

이 문서는 v0.18.0 전체 로드맵과 실행 현황을 확인하는 단일 총괄 문서다. 앞부분에서 목표·분야별 작업 순서·통과 기준을 보고, 뒤의 63개 작업 지시서에서 목적·소유 경계·산출물·완료 조건을 확인한다. 구현 중 중요한 변경은 docs/updates/에 개별 문서로 기록하고 여기에서 연결한다.

항목	현재 상태
문서 최초 등록 / 기준일	2026-09-07 (KST)
계획 개정	개정 11 (2026-09-10): Phase 5 기존 6개 실행 이슈를 4/1/1 스텝으로 게시하고 실제 번호 연결. 전체 63개·191개 직접 의존은 그대로 유지
실행 상태	Phase 1·2 원 구현 29개 병합. Phase 3은 #1402–#1421의 20개 원 구현이 release에 합류한 게시 시점이며 D11 #1422 통합 작업은 진행 중. Phase 4는 7개 게시·구현 미착수. 과거 9월 8일의 종료 보완·배포 기록과 현재 상태를 구분하며 개별 최신 증거는 이슈/PR에서 확인
구현·통합·릴리즈 검증	게시 시점 원 구현 PR 병합 49/63(공수가 아닌 작업 수), Phase 4 구현 0/7. release 병합·staging·Production 검증은 별도다. D12의 추가 대표 운영 측정 생략 결정을 보존하고 생략을 성능 효과 입증으로 집계하지 않음
실행 GitHub 이슈 / 담당 배정	Phase 1 11개·Phase 2 18개·Phase 3 21개·Phase 4 7개·Phase 5 6개, 63/63 게시·미게시 0개. Phase 5는 6개 게시·미착수이며 게시·담당 배정·착수·검증·승격·배포 완료를 구분
이번 문서 변경	사용자 요청으로 기존 Phase 5 U06/R02/R03/R04/R05/R06을 게시하고 아래 §5·§12·§13·§14에 연결. 앞선 Phase 4 결정의 D14/D11·R04/R05 보강과 원 범위/선행/완료조건을 유지. 새 작업 ID·직접 의존 추가 없음
진행 관리	HQ가 이 문서의 상태·범위·의존성과 실제 이슈/PR/SHA/증거 링크를 관리
현재 통합 대상	캠페인 앱 코드 PR base = `release/v0.18.0`. R05/R06 승격은 release→staging→main 절차로 구분한다. 문서 PR은 Barbelic-docs main. 앱 precheck → Merge Check → release 병합, 최종 승격 full·배포는 현재 릴리스 규칙과 공통 지침을 따름

목표 구조는 2절, 분야별 5개 Phase는 5절, 진행 상태와 기록 방식은 7절에 있다. 12절의 실행 목록에서 ID를 누르면 13절의 해당 작업 지시서로 이동한다.

최초 감사의 기준 소스는 main aed0d39c7d54ac792f19910cd377b6dc6adfa50a, production 478ddf1238834fbed7bbeedee031223da94003eb이며, 2026-09-07 재조회에서 tree 3458142cc7d7d4e74f1b58a0eeec751f25e1eccd가 같았다. 착수 때 최신 SHA·열린 이슈/PR·실제 배포 버전을 다시 고정한다. 소스 일치는 운영 DB·설정·트래픽 검증을 대신하지 않는다.

2026-09-06 코드 감사의 31개 추적 항목과 후속 커버리지 점검의 8개 범위를 이 문서의 대응표에 보존했다. 기존 정규 운동 계층, 사실/읽기 모델 분리, receipt, 원본 보호 장치는 유지할 기반이다. 주요 개선 대상은 거대 repository/controller, 느슨한 타입과 중복 상태, 저장 교체의 원자성, 통계의 중복 작성·불필요한 전체 계산이다. Outbox 교체 실패는 메모리 저장소의 quota fault로 재현했으며 운영 유실을 관찰한 것은 아니다. DB 경합·실제 복구·운영 부하는 실행 시 증명해야 한다.

이 문서는 사용자 요청으로 구현 전에 등록하는 진행형 총괄 기록이다. 일반 작업 기록 형식의 완료 시점 보고서와 구분하며, 아래 완료 조건은 달성할 목표다. 문서 등록만으로 G01이나 다른 실행 이슈를 완료 처리하지 않는다. 현재 프로덕션 계약은 해당 변경 PR에서 정식 갱신하기 전까지 유효하다. 첫 문서 보강 때의 main은 b347a4d219d5f31a5746c7e4fd18e8caf7ea44dd였고, Phase 1 종료 보완은 #1318·#1321이 포함된 c2bf7f60518dcee06321065884ac75ba681d59fb에서 시작했다. 최신 구현 상태는 위 현황과 아래 PR 장부를 따른다.

1. CTO 관점의 목표와 기본 전략

0.18.0의 결과는 사용자 데이터의 소유권·저장 확정·통계 발행·화면 상태에 명시적 계약이 있고, 기능 변경이 해당 기능 모듈 안에서 끝나는 앱이다. 여러 작업자가 공용 컨트롤러·범용 객체·순서 의존 보정 코드를 함께 고치는 구조를 끝낸다.

React·Vite·Postgres·Supabase와 현재 정규화된 운동 계층을 유지하는 모듈형 단일 앱으로 간다. session → session_exercise → session_exercise_part, exercise_set → exercise_set_part는 현재 제품 의미를 표현하는 구조다. 테이블 통합·새 프레임워크·마이크로서비스·범용 동기화 플랫폼을 도입하는 작업으로 확대하지 않는다.

한 번의 제품 릴리즈 안에서 여러 번의 작고 검증 가능한 이식·통합을 수행한다. 거대한 마지막 PR에서 모든 코드를 한꺼번에 교체하지 않는다. 선행 계약을 고정하고, 저장 경로 하나를 끝까지 연결한 뒤 같은 패턴으로 기능을 넓힌다. 각 통합 상태는 스테이징에서 실행 가능해야 한다.

모든 구현·검증·정리 항목을 0.18.0에 포함한다. 우선순위는 착수·검토 순서를 뜻하며 낮은 우선순위 항목의 생략을 허용하지 않는다. 보고서의 “TanStack Query 또는 기존 coordinator 정리”, “안전한 merge 또는 사본 기반 보존”처럼 선택 관계인 제안은 선택 이유를 기록하고 한 방식으로 문제를 해결한다. 서로 양립하지 않는 대안을 모두 구현하지 않는다.

2. 최종 책임 경계

계층	소유하는 것	다른 계층에 전달하는 계약
App shell	owner/auth/connectivity 수명주기, route, overlay host, feature 조립	owner epoch, route, 좁은 feature binding
Feature	운동·계획·달력·PR·프로필·소셜·그룹·인입의 사용 사례	typed view model, 사용자 intent, command/query port
Headless editor / pure policy	입력 중 상태, validation, ID·단위 의미, 도메인 상태 전이	prepared command, validation 결과, view model
Repository / codec / transport	도메인 RPC, 외부 unknown 검증, 서버 row 변환, 인증·timeout·오류 수송	canonical camelCase DTO
Outbox / dispatcher	미전송 요청의 영속 보관, 원자 교체, attempt·retry·claim, receipt 확인	committed/deferred/held/blocked 결과
Resource cache	owner·ID·기간·version 별 서버 응답, dedup/cancel/invalidation	immutable snapshot와 selector
Server command	권한·revision·멱등 검증, 정규 사실·receipt·dirty의 원자 commit	확정 identity/revision/generation
Stats worker / projector	durable claim, 관측·증분 계산, 완전한 세대 발행	서버가 확정한 read model
복구 도구	보존 출처·지원 범위·검증된 계획과 명시 복구	dry-run, precondition, 새 restore receipt

text

app shell
  ├─ owner / auth / connectivity lifecycle
  ├─ route / overlay host
  └─ feature bindings
       ├─ workout / plan / calendar / pr / profile / social / group / import
       ├─ headless editor + typed view model + pure policies
       └─ feature commands / resource queries

durable commands → atomic outbox → dispatcher → RPC
                                            └→ canonical + receipt + dirty event
resource queries → owner-scoped cache → read-model RPC
dirty event → leased worker → observations → projections → generation publication

클라이언트는 입력 중인 상태와 미전송 쓰기를 소유한다. 서버는 정규 데이터와 확정 통계를 소유한다. “기기에 보관됨”, “서버 저장 확정”, “통계 갱신 완료”는 다른 상태다. 로컬 pending overlay는 표시용이며 서버 상세의 쓰기 원천을 대신하지 않는다.

위 durable commands는 현재 완료 기록 생성·수정·삭제와 계획 수정·삭제 범위에서 시작한다. 신규 계획 생성은 서버 ID가 필요한 기존 온라인 정책을 유지하고, 인증·파일 업로드 등도 명시적 capability로 구분한다. 모든 명령은 typed 경계를 갖되 모든 기능에 새 오프라인 제품 동작을 추가하지 않는다.

폴더 구성의 목표는 다음과 같다. Phase 1 G03/D03에서 확정한 계층 계약과 SQL 원천을 따른다. 후속 issue 카드의 신규 경로는 계획 경계이며 현재 파일 존재를 주장하는 목록이 아니다.

text

src/react/
  app/                    # shell와 lifecycle 조립
  contracts/              # 계층 사이의 작은 계약
  features/<feature>/
    domain/               # pure 정책, 타입
    editor/               # 필요한 기능에만 headless 모델
    commands/
    queries/
    bindings/
  resources/              # owner-scoped cache primitive
  persistence/            # outbox, dispatch, mirror, 버전별 codec
  services/               # domain repositories와 RPC transport
  ui/
    shared/               # tokens, primitives; domain 업무 판단 제외
    mobile/               # mobile 표현
    desktop/              # desktop 표현
supabase/
  definitions/<domain>/   # 현재 SQL 정의의 원천
  migrations/             # 적용 순서가 고정된 불변 이력
  schema.sql              # migration replay 결과 snapshot

현재 store와 coordinator를 작고 typed한 형태로 완성하는 것을 기본안으로 잡는다. 새 query/state 라이브러리는 필요성이 입증될 때 G03에서 한 번 결정한다. 플랫폼 UI는 별도 layout을 유지하고 입력 의미·검증·편집 상태를 공유한다.

3. 보존할 정책과 이번에 바꿀 기술 계약

구분	0.18.0 결정
기존 숫자·통계 정책	e1RM·PR·최대반복수·세트 score·볼륨·출석·반올림·시간 순서·단위 의미 유지
기록 identity	canonical parent/child ID, source/source_ref, 기존 mutation ID/hash, receipt 이력 유지
완료 저장 UX	기존 wait/immediate 표와 무음 자동 동기화, pending 통계 구분 유지
충돌 기본 정책	나중 서버 도착 요청 우선 유지. durable 재조립·확인 가능한 사본·명시 복구 추가
안전한 field merge 제안	G01에서 선택지 판단을 기록. 현재 기본값은 사본+복구이며 검증되지 않은 자동 merge는 도입하지 않음
복구 UX	삭제 직후 취소 toast 금지 유지. 별도 사본·복구 화면에서 명시 undo 제공
초안 보존	active/archive 7일, archive 최대 5개, checkpoint 3일·owner 하나 유지
사본 정책	일 1회·90일·PITR 미사용 유지. completeness·checksum·경보·실제 복구 도구 보강
계정 삭제·권한	owner/RLS/grants·개인정보 삭제·인입 source 정책 유지
변경할 기술 규칙	outbox per-mutation 원자 상태 전이·CAS/expiry/fence·durable successor, typed resource, 단일 projector 작성자
호환 코드	구형 저장 decoder·유효 공개 RPC adapter만 명시 경계에 보존; 활성 앱의 임의 shape fallback 제거

감사 당시 쓰기 계약은 CAS/탭 간 lease를 금지했으나 G01에서 v0.18.0 ADR의 좁은 기술 계약으로 갱신했다. 후속 구현은 이 계약을 따르며 기본 제품 정책을 변경하는 근거로 해석하지 않는다. 현재 쓰기 계약

복구 사본이 없거나 만료됐다면 그 범위를 표시한다. “모든 입력을 어떤 상황에서도 영구 보존”하는 약속은 이 구조나 현재 보존 정책으로 할 수 없다. 미전송 요청의 유일한 근거는 일반 초안 TTL과 구분해 보존한다.

4. 주요 분야별 그룹과 우선순위

관리용 프로그램 issue 1개와 아래 6개 분야별 epic을 제안한다. G/S/D/A/U/B/N/I/R 접두어는 기존 세부 track 식별자로 유지하며 실제 배정은 아래 주요 분야를 사용한다. 2026-09-10 사용자 결정으로 기존 62개를 유지하고 D14 하나를 추가해 실행 issue는 63개다.

주요 분야	이슈	개수	책임
HQ·공통 계약·검증·릴리즈	G01, G02, G03, G04, G05, R01, R02, R03, R04, R05, R06	11	공통 계약, 전체 커버리지, 테스트/성능 기준, 구 구현 정리, 통합 검증·출시
DB·통계·마이그레이션	D01, D02, D03, D04, D05, D06, D07, D08, D09, D10, D11, D12, D13, D14	14	전체 DB 모델·쿼리, migration, 동시 저장, dirty scope, 증분 통계, worker·인입 job
저장·동기화·복구	S01, S02, S03, S04, S05, S06, S07, S08, S09, S10, S11	11	outbox 원자성·claim, command·dispatcher·receipt, 충돌·초안·백업·복원
앱 구조·도메인·편집기	A01, A02, A03, A04, A05, A06, A07, A08, A09, A10, A11, A12, A13, A14, A15, A16	16	repository·codec, owner lifecycle, resource cache, 공통 editor, feature binding·shell·타입
UI·CSS·화면 성능	U01, U02, U03, U04, U05, U06, U07	7	tokens·primitive, mobile/desktop, responsive, CSS 정리, 가상화·bundle·UX
서버 API·플랫폼·인입·실행 환경	B01, B02, N01, I01	4	인증·계정·관리 API, 빌드·의존성, iOS/Android·SW, Wodup/Motra/InBody 파일 경로

P0: 저장 안전성, 공통 선행 계약, 최종 출시를 막는 검증. ready 상태에서 우선 처리한다.
P1: 목표 구조를 성립시키는 핵심 이식·통계·복구 구현.
P2: 구조 마무리·성능·UI 일관성·퇴역 코드 제거. 이것도 이번 릴리즈 필수다.
이 우선순위는 감사 보고서의 결함 심각도와 별개인 실행 우선순위다. P0 작업도 선행 계약을 건너뛰지 않는다.

한 issue는 하나의 검토 가능한 결과를 갖는다. 코드 추출과 의미 변경을 분리할 필요가 있으면 한 issue에 2–3개 작은 PR을 연결한다. 서로 의존하는 초소형 변경만 기존 작업 규칙에 따라 통합 PR로 묶는다. 큰 issue 여러 개를 “PR 4–8개 묶음”처럼 기계적으로 합치지 않는다. 너무 커지면 child issue로 나누고 coverage/DAG도 함께 갱신한다.

5. 전체 5개 Phase와 통과 기준

Phase	목표	개수	해당 이슈
1. 공통 기반과 계약 확정	여러 작업자가 공유할 타입·정책·검증 도구와 독립 구현 경계를 확보한다.	11	G01, G02, G03, G04, G05, S01, D01, D03, D13, A01, U01
2. 안전한 저장 경로와 첫 수직 통합	운동 입력부터 durable 저장·서버 확정·화면 재조회까지 새 구조의 표준 경로를 만든다.	18	S02, S03, S04, S05, S06, S07, S08, D02, D12, A02, A03, A07, A08, A09, A12, A13, B01, B02
3. 전체 기능·통계·플랫폼 이식	검증한 경계를 모든 기능에 확대하고 서버 통계·복구·native·인입을 연결한다.	21	S09, S10, S11, D04, D05, D06, D07, D08, D09, D10, D11, A04, A05, A06, A10, A11, A14, U02, U03, N01, I01
4. 최종 구조·CSS·성능·원본 쓰기 정리	활성 구조를 완성하고 원본의 불필요한 물리 쓰기·표현·초기 로딩 비용을 줄인다.	7	A15, A16, U07, U04, U05, D14, R01
5. 통합 검증·배포 리허설·v0.18.0 릴리즈	검증된 최종 코드와 DB를 실제 출시하고 데이터·성능·사용자 경험의 결과를 확인한다.	6	U06, R02, R03, R04, R05, R06

분야별 Phase 배정과 현재 진행률

분야는 소유권을, Phase는 통합 순서를 보여 준다. 각 칸의 ID는 같은 분야 안에서 그 단계에 수행할 작업이다.

분야	Phase 1	Phase 2	Phase 3	Phase 4	Phase 5	합계
HQ — HQ·공통 계약·검증·릴리즈	G01, G02, G03, G04, G05	—	—	R01	R02, R03, R04, R05, R06	11
DATA — DB·통계·마이그레이션	D01, D03, D13	D02, D12	D04, D05, D06, D07, D08, D09, D10, D11	D14	—	14
DURABLE — 저장·동기화·복구	S01	S02, S03, S04, S05, S06, S07, S08	S09, S10, S11	—	—	11
APP — 앱 구조·도메인·편집기	A01	A02, A03, A07, A08, A09, A12, A13	A04, A05, A06, A10, A11, A14	A15, A16	—	16
UI — UI·CSS·화면 성능	U01	—	U02, U03	U04, U05, U07	U06	7
PLATFORM — 서버 API·플랫폼·인입·실행 환경	—	B01, B02	N01, I01	—	—	4

Phase	실행 이슈	구현 완료	Staging 검증	Release 검증	단계 상태
1. 공통 기반과 계약 확정	11	11	9 (G01/G05 해당 없음)	0	Phase 1 기반·종료 보완 검증 완료 — Phase 2 착수 입력 확보; 상세 증거는 아래 장부
2. 안전한 저장 경로와 첫 수직 통합	18	18 원 PR	18 최종 통합 포함	운영/실기기 인계 있음	원 구현 병합·최종 staging 확인. 종료 보완은 `main`/v0.17.3 통합 지정·실제 병합 전; 최신 main 합류 검증 별도
3. 전체 기능·통계·플랫폼 이식	21 게시	20 원 PR release 병합	개별 기록	최종 후보 검증 별도	2026-09-10 게시 시점: #1402–#1421 합류·D11 진행 중. 아래 과거 미착수 표기는 각 카드 게시 당시 상태
4. 최종 구조·CSS·성능·원본 쓰기 정리	7 게시	0	0	0	Planned · 게시·미착수, 3/2/1/1 스텝
5. 통합 검증·배포 리허설·v0.18.0 릴리즈	6 게시	0	0	0	Planned · 게시·미착수, 4/1/1 스텝

구현 병합·배포 포함·Release 검증은 별도 상태다. Phase 1의 Release 0과 아래 과거 장부의 Production 미검증은 당시 기록이며, 현재 Production 코드 미포함을 뜻하지 않는다. 현재 Phase 2 배포 대조표는 종료 기록에 있다. Phase 완료는 작업 개수뿐 아니라 해당 통과 기준 충족을 요구한다.

Phase 1 게시 이슈와 실행 말머리

2026-09-07에 Phase 1의 11개를 실제 GitHub 이슈로 게시했다. 제목의 [리팩터링 n-m]에서 n은 Phase, m은 같은 Phase 안에서 병렬 진행 가능한 선행 순위다. 각 이슈에는 담당 작업에 필요한 전체 목표·책임 경계·선행 입력·후속 인계의 요약, 실제 직접 선행 링크, 상세 작업 순서·소유 경계·산출물·검증·기록 조건을 넣었다. 작업자는 이슈의 요약과 필요한 계약을 읽으며 총괄 전체 통독을 요구하지 않는다. Phase 번호는 기존 1–5를 유지한다.

말머리	실행 이슈
[리팩터링 1-1]	G01 / #1279
[리팩터링 1-2]	G02 / #1280, G05 / #1281
[리팩터링 1-3]	G03 / #1282, D03 / #1283
[리팩터링 1-4]	G04 / #1284, S01 / #1285, D01 / #1286, D13 / #1287, A01 / #1288, U01 / #1289

Phase 1은 1-1 → 1-2 → 1-3 → 1-4 순서로 진행한다. 같은 스텝 안에서만 병렬 진행하고, 앞 스텝 전체의 완료·검증·병합을 확인한 뒤 다음 스텝에 착수한다. 각 이슈의 직접 선행 계약·파일 소유권도 준비돼 있어야 한다. Step 4의 여섯 이슈도 자동으로 여섯 세션에 배정하는 뜻은 아니며 공용 파일/DB 환경에 따라 HQ가 동시 작업 수를 조정한다. 게시한 사실을 구현 완료나 Ready 판정으로 집계하지 않는다.

Phase 1 — 공통 기반과 계약 확정

목적: 여러 작업자가 공유할 타입·정책·검증 도구와 독립 구현 경계를 확보한다.

이슈 11개: G01, G02, G03, G04, G05, S01, D01, D03, D13, A01, U01.

설계 문서만 만드는 단계가 아니다. codec/transport 분리 경계와 테스트·migration 도구를 구현한다.

작업열	내부 순서
HQ·계약	G01 → G02/G05 → G03 → G04
저장·앱·UI 계약	G02/G03 이후 S01, A01; G03 이후 U01
SQL·검증 기반	G02 이후 D03; G02/G03 이후 D01; G05·D03 이후 D13

다음 단계로 넘어갈 조건

실제 기능×계층 목록, 계약 소유자·허용 경계와 변경 절차가 정해져 있다.
기존 정책·ID·수치 의미, mutation/receipt/resource/editor/CSS 계약을 고정했다.
deterministic fixture·SQL 원천·migration 검증 도구·성능 기준이 준비돼 있으며 구형 저장 writer 공존의 초기 실험 결과가 있다.

Phase 2 — 안전한 저장 경로와 첫 수직 통합

목적: 운동 입력부터 durable 저장·서버 확정·화면 재조회까지 새 구조로 작동하는 표준 경로를 만든다.

이슈 18개: S02, S03, S04, S05, S06, S07, S08, D02, D12, A02, A03, A07, A08, A09, A12, A13, B01, B02.

Phase 2 게시·실행 인계 (2026-09-07): 18개 모두 v0.18.0 마일스톤에 생성했다. 말머리는 [리팩터링 2-m]이며 제목 뒤 태그와 별도 라벨은 붙이지 않았다. 각 이슈의 자기 맥락·선택 필독·상세 작업·수락 조건·직접 선행 링크로 시작한다. 전체 총괄의 반복 통독은 필요 없다. 이슈 생성 기준 main은 07c04f371이며 작업자는 실제 착수 때 최신 main·열린 PR·계약을 확인한다.

실행 스텝	게시한 실행 이슈	개수
`[리팩터링 2-1]`	S02 #1325, S08 #1326, D02 #1327, D12 #1328, A02 #1329, A03 #1330, B01 #1331, B02 #1332	8
`[리팩터링 2-2]`	S03 #1333, S04 #1334, A07 #1335	3
`[리팩터링 2-3]`	S05 #1336, S07 #1337, A08 #1338, A12 #1339, A13 #1340	5
`[리팩터링 2-4]`	S06 #1341	1
`[리팩터링 2-5]`	A09 #1342	1

스텝은 위 순서로 계획한다. 2-1의 8개는 선행이 확보된 병렬 후보이며 한꺼번에 8개 공용 파일을 수정하라는 뜻은 아니다. 초기에는 S02·D02·A02·B01 등 독립 경계 4개 안팎을 배정하고 담당/파일 여건에 따라 나머지를 합류시킨다. 이후 착수는 12절의 직접 선행 전체·merged SHA·필요 검증·소유권으로 판단한다. S05/S07의 outbox, A02/A03의 facade, A12/A13의 공통 policy 및 D02/D12의 겹치는 SQL object는 같은 스텝이라도 연결 패치를 직렬 통합한다. 승인된 범위의 일상 착수에 HQ 상주나 라벨 재승인은 필요 없다.

Phase 1의 종료 인계도 해당 이슈에 반영했다. S03는 S01의 prepared/needs_preparation/invalid 결과와 구형 identity를 보존하고, D02는 실제 2연결 generation 경합을 회귀로 고친다. DB 변경은 D13의 v2 판정·실제 이미지 pin·5,000ms 잠금 예산을 사용하며 기존 전체 upgrade의 5,017ms 실패를 합격으로 재사용하지 않는다. A09 직접 선행은 유지하되 Phase 2 종료에는 A12/A13 editor까지 실제 저장 경로에 합류한 증거가 필요하다. 전체 플랫폼 화면 이식은 Phase 3이다.

기존 화면 표현을 이용해 실제 저장 경로부터 증명한다. 모바일·데스크톱 화면 전반의 이전은 Phase 3에서 한다.

작업열	내부 순서
Queue·동기화	S02 → S04 → S07; A02+S01 → S03; S03/S04/D02 → S05 → S06
DB·서버	D02와 D12 독립; B01/B02는 각 경계에서 병렬
앱·편집기	A02/A03; B01 → A07 → A08; A02/A03/S03 → A12/A13
첫 수직 통합	A02/A03/A08/S06/D02 → A09; S08은 독립 초안 정리

다음 단계로 넘어갈 조건

quota/abort·전송 중 편집·응답 유실·재시작·owner 전환에서 원문과 mutation identity가 보존된다.
동시 저장·서버 receipt 계약과 DB 모델/쿼리의 필요한 개선을 실제 검증했다.
공통 editor·prepare→outbox→dispatcher→RPC→receipt→resource 재조회가 기존 화면의 얇은 adapter를 통해 작동한다.
인증/API·owner lifecycle·빌드 환경의 책임이 나뉘고 첫 feature 이식 패턴을 확정했다.

2026-09-08 종료 보완: 원 구현 18개 병합 후 확인된 (1) 고아 후속 요청·미확인 미러의 receipt 제품 조회 연결 (2) receipt 뒤 owner resource 재조회·계획 카드 수렴은 별도 기록에서 구현·로컬 검증했다. 사용자는 이 보완을 main에 병합하여 v0.17.3에 포함하도록 지정했다. 현재 실제 병합 전이며, 최신 main의 PR #1401·365f16d45 합류 뒤 검증은 새 결과가 나온 후 기록한다. 기존 로컬 통과를 그 최신 통합본의 통과·병합·staging 성공으로 앞당겨 표기하지 않는다. 2026-09-08 사용자 결정으로 D12의 추가 대표 운영 seq_scan·저장 지연 측정은 생략하고 #1328을 종료했다. 이는 측정 성공·운영 효과 입증이 아니다. R04/R05의 전체 성능·릴리스 검증과 B01 실제 provider, B02/N01 서명·iOS·WebView 실기기 검증은 그대로 유지한다. 이 보완과 의존성이 없는 Phase 3 작업은 병행할 수 있다.

A09 릴리스 상태 (2026-09-08): #1342는 Open · [v0.17.3 스테이징] · milestone v0.17.3으로 관리한다. 원 구현 PR #1394·ba3b77bf는 release/v0.17.3의 60c8a5746109c6e827e87b10547c1bc9fccd9302에 포함되어 있고 원 구현 대비 누락 커밋은 0개다. 기존 staging 실행은 성공했다. 이 증거는 원 구현의 staging 상태이며 현재 main 미반영·검증 중인 HQ의 별도 receipt/resource 종료 보완이나 v0.17.3 Production 배포 성공을 뜻하지 않는다.

Phase 3 — 전체 기능·통계·플랫폼 이식

목적: 검증한 경계를 모든 기능에 확대하고 서버 통계·복구·native·인입을 연결한다.

이슈 21개: S09, S10, S11, D04, D05, D06, D07, D08, D09, D10, D11, A04, A05, A06, A10, A11, A14, U02, U03, N01, I01.

Phase 3 게시·실행 인계 (2026-09-08): 21개 모두 v0.18.0 마일스톤에 게시했다. 현재 게시 21개·미착수·구현 0개이며 말머리는 [리팩터링 3-m]이다. 각 이슈에 전체 목표 중 자기 역할의 요약·선택 필독·상세 순서·행동 검증·직접 선행 실제 링크·후속 인계를 넣었다. 총괄 전체 통독은 요구하지 않는다.

실행 스텝	게시한 실행 이슈	개수
`[리팩터링 3-1]`	S10 #1402, D04 #1403, D09 #1404, A04 #1405, A05 #1406, A06 #1407, N01 #1408	7
`[리팩터링 3-2]`	S09 #1409, S11 #1410, D05 #1411, D08 #1412, A10 #1413, A14 #1414, I01 #1415	7
`[리팩터링 3-3]`	D06 #1416, D07 #1417, D10 #1418, A11 #1419, U02 #1420, U03 #1421	6
`[리팩터링 3-4]`	D11 #1422	1

21개로 가장 큰 구현 묶음이다. 내부 선행을 지키면서 계산·복구·feature·플랫폼을 병렬 진행한다. 3-1 → 3-2 → 3-3 → 3-4는 직접 선행에 따른 7/7/6/1 병렬 후보 묶음이며, 실제 착수는 각 이슈의 직접 선행 전체·합류 SHA·검증·파일 소유권으로 판단한다. 같은 스텝이라는 이유로 공용 controller·SQL object·CSS 파일을 동시에 덮어쓰지 않는다.

통합 대상 확정: Phase 3의 개별 작업 브랜치는 release/v0.18.0에서 분기하고 **PR base도 release/v0.18.0**으로 지정한다. Phase 3 커밋은 이 브랜치로 통합하며 main용 npm run landing:request를 release 대상으로 사용하지 않는다. Phase 2 종료 보완만 main/v0.17.3 대상으로 별도 지정됐다. 이슈 게시를 Phase 3의 main 자동 병합이나 Production 배포 승인으로 사용하지 않는다. 기존 검증·소유권·DB 이력 보존은 유지하고 HQ 상주·새 라벨 승인 절차를 추가하지 않는다.

게시 전 코드는 ed3d6db7와 #1395 navigation 계약, 당시 열린 #1398 디자인/기능·#1401 세트 점수 변경을 대조했다. 현재 #1401은 365f16d45로 main에 병합됐으므로 해당 이슈 착수 때 release 브랜치의 실제 합류 상태와 최신 계약을 확인한다. Phase 2 보완의 receipt/resource 계약은 영향받는 작업의 입력이며 62개 밖의 새 ID나 전체 Phase 3 착수 장벽으로 추가하지 않는다.

작업열	내부 순서
통계 계산	D04 → D05 → D06/D07; D04 → D08 → D10; D09·A06와 합쳐 D11
복구	S10 → S11; S06/S10 → S09
기능 resource	A04/A05/A06; A06+A09 → A10/A14; I01 등 선행 이후 A11
인입·native	D09+A05 → I01; N01은 Phase 2에서 확보한 계약 위에서 독립 진행
모바일·데스크톱	S09·editor/resource 계약 이후 U02/U03 병렬

다음 단계로 넘어갈 조건

Home/Calendar/PR/Volume/Profile/Social/Group/Import와 이력 조회가 typed feature resource를 사용한다.
동일 canonical fixture에서 통계 전체/증분 결과가 같고 단일 작성자·사용자별 worker·generation 발행이 작동한다.
복구 command/engine/manifest, Wodup/Motra/InBody 경로, native/SW 계약이 구현·연결됐다.
모바일·데스크톱 입력 의미가 같고 responsive 표현이 공통 view model을 소비한다.

Phase 4 — 최종 구조·CSS·성능·원본 쓰기 정리

목적: 활성 경로에 구 구현과 새 구현이 얽혀 남지 않도록 구조를 완성하고 비용을 줄인다.

이슈 7개: A15, A16, U07, U04, U05, D14, R01.

실행 스텝	실행 이슈	핵심 결과
`[리팩터링 4-1]`	A15 #1531	기능별 binding·얇은 app shell
`[리팩터링 4-1]`	U07 #1532	CSS cascade·scope·중복 정리
`[리팩터링 4-1]`	D14 #1533	변하지 않은 자식 행과 순서의 물리 쓰기 제거
`[리팩터링 4-2]`	A16 #1534	활성 any·dual shape·거대 mapper 정리
`[리팩터링 4-2]`	U04 #1535	긴 목록의 실제 viewport 가상화
`[리팩터링 4-3]`	U05 #1536	feature import graph·초기 bundle 비용 축소
`[리팩터링 4-4]`	R01 #1537	D14/D11을 포함한 활성 경로·퇴역·호환 경계 마감

상세 실행계획에 D14의 목표·범위·5개 내부 Phase·예상효과·완료조건과 D11/R01/R04/R05 인계를 기록했다.

모든 정리를 이때까지 미루지 않는다. 각 feature 이식 PR에서 대체 코드를 제거하고, 이 phase에서 잔여 경로를 마감한다.

작업열	내부 순서
원본 쓰기	D02/D04/S10/D11 → D14; R01에 직접 인계
앱 구조	A15 → A16
CSS·목록	U07 → U04
Bundle·구 구현 퇴역	A15/U04 → U05; A16/U05/D14 및 전체 직접 선행 합류 후 R01

다음 단계로 넘어갈 조건

shell은 lifecycle/route/overlay/feature 조립만 담당하고 광범위 AnyRecord/dual shape·중복 상태를 제거했다.
D14에서 메모-only·동일 내용의 새 저장은 자식 쓰기 0, 실제 변경의 영향 밖 자식 쓰기 0, 순서 불변의 위치 쓰기 0을 확인한다. ID·원본·revision·receipt·generation 계약은 유지한다.
D11의 변경 공개 행 발행 증거와 D14의 원본 쓰기 증거를 R01/R04/R05에 연결한다. full payload 검증 비용과 정당한 suffix 재계산은 별도다.
CSS cascade·override·중복을 정리하고 목록 DOM·초기 bundle 비용이 설정된 예산을 충족한다.
대체 구현·미사용 코드·불필요 wrapper를 제거하고 유효 호환 adapter는 목적·담당·제거 조건을 남겼다.
G05 장부에서 각 필수 영역의 구현·관련 검증 증거를 확인했다. 최종 통합·운영 검증은 Phase 5에 남겨 상태를 구분한다.

Phase 5 — 통합 검증·배포 리허설·v0.18.0 릴리즈

목적: 검증된 최종 코드와 DB를 실제 출시하고 데이터·성능·사용자 경험의 결과를 확인한다.

이슈 6개: U06, R02, R03, R04, R05, R06.

2026-09-10 게시: 기존 6개를 v0.18.0 milestone에 게시했다. 이슈별 목표·범위·직접 선행·선택 필독·내부 Phase·예상효과·수용 기준·후속 인계를 포함한다. 5-1 → 5-2 → 5-3 순서이며 같은 스텝의 독립 검증만 병렬 진행한다. 전체 코드/검사 작업의 목적 release는 release/v0.18.0, R05/R06 승격은 현행 release→staging→main 절차다. 지금 게시를 구현 착수나 운영 승격 승인으로 해석하지 않는다.

실행 스텝	실행 이슈	핵심 결과
`[리팩터링 5-1]`	U06 #1540	UX·접근성·플랫폼 실제 연결 검증
`[리팩터링 5-1]`	R02 #1541	구/신 앱·서버·IDB와 저장 장애 호환
`[리팩터링 5-1]`	R03 #1542	실제 사본의 격리 선택 복원·RPO/RTO
`[리팩터링 5-1]`	R04 #1543	긴 이력·혼합 부하·원본→계산→발행 전체 비용
`[리팩터링 5-2]`	R05 #1544	실제 populated 이관·staging 리허설·후보 확정
`[리팩터링 5-3]`	R06 #1545	검증 후보의 Production 배포·관찰·정본 마감

U06의 실제 staging API 검증은 5-1 안의 검증 환경 준비부터 릴리스 담당의 기존 full·배포 절차로 조율한다. R05의 완료/착수를 U06 선행으로 요구하지 않는다. R05는 네 검증 결과 이후 전체 이관·호환 리허설과 최종 후보를 확정하며, 이미 같은 후보의 유효한 staging 증거가 있으면 재사용하고 바뀐 후보만 다시 승격·검증한다. 이 환경 준비는 별도 신규 이슈나 직접 의존을 추가하지 않는다.

자동 검증은 #1478 제외를 유지하고 오너 실기기 확인을 게이트로 삼지 않는다. R03의 실제 사본 apply는 격리 환경으로 제한한다. R06의 완료는 release 병합을 넘어서 실제 Production 배포·정해진 관찰·유효 사본 확인까지다. 문서/이슈 게시와 이 결과의 달성을 구분한다.

R04는 D14/D11의 저장→계산→최종 발행 DML·WAL·직렬화·잠금·p95를 같은 1/4/10년 workload에서 검증한다. R05는 실제 이전 버전 populated DB의 원본·ID·receipt 보존과 중단/재개·구/신 앱·복원·full rebuild를 기존 선행 증거에 묶는다. 보강 범위.

테스트 작성과 개별 검증은 앞 phase부터 수행한다. 이 phase는 완성된 앱 전체를 최종 증명하는 단계다.

작업열	내부 순서
독립 최종 검증	U06: UX/접근성; R02: 구버전/저장 장애; R03: 복원; R04: 혼합 부하
릴리즈 리허설	네 검증 합격 → R05: 실제 migration/Edge/frontend/native 조합 검증
생산 배포	R05 후보·승인·복구 준비 → R06: 배포·smoke·관찰·장부 마감

다음 단계로 넘어갈 조건

구 앱/서버/IDB/native/SW 조합과 실제 사본 복구를 검증했다.
UX·mixed load·queue/freshness·전체 DB upgrade 기준을 최종 후보 SHA에서 충족했다.
필수 검증의 skipped/미확인 상태가 없고 동일한 후보의 배포·rollback/forward-fix 준비가 검토 가능하다.
production 배포 후 관찰 기간과 유효 사본을 확인하고 원 보고서 31개 항목+추가 8개 범위의 장부를 마감했다.

Phase 내부의 선행 순서

아래 순위는 이전 Phase의 선행이 준비됐다고 가정한 가장 이른 착수 묶음이다. 같은 행도 파일·DB object 소유권이 겹치면 직렬화한다. 실제 착수 판정은 63개 목록의 직접 선행 전체를 사용한다.

Phase	내부 순위	같은 순위에서 독립 진행 가능한 이슈
1	1	G01
1	2	G02, G05
1	3	G03, D03
1	4	G04, S01, D01, D13, A01, U01
2	1	S02, S08, D02, D12, A02, A03, B01, B02
2	2	S03, S04, A07
2	3	S05, S07, A08, A12, A13
2	4	S06
2	5	A09
3	1	S10 #1402, D04 #1403, D09 #1404, A04 #1405, A05 #1406, A06 #1407, N01 #1408
3	2	S09 #1409, S11 #1410, D05 #1411, D08 #1412, A10 #1413, A14 #1414, I01 #1415
3	3	D06 #1416, D07 #1417, D10 #1418, A11 #1419, U02 #1420, U03 #1421
3	4	D11 #1422
4	1	A15, U07, D14
4	2	A16, U04
4	3	U05
4	4	R01
5	1	U06 #1540, R02 #1541, R03 #1542, R04 #1543
5	2	R05 #1544
5	3	R06 #1545

Phase 운영 규칙

분야는 담당 전문성을, phase는 통합 결과의 진행 순서를 뜻한다. 하나의 분야는 여러 phase에 걸쳐 계속 작업한다. 같은 phase에 있다는 이유로 모든 issue를 동시에 시작하지 않는다. 단계별 이슈 수는 공수나 기간 비율이 아니다. Phase 3은 큰 병렬 구현 묶음이며 실제 일정은 처리량과 검증 소요로 정한다.

선행 merge + 계약 고정 + 파일 소유권 확보가 착수 조건이다.
초기 4개 안팎, 경계가 열리면 4–6개 작업을 동시에 진행하되 리뷰 대기와 파일 충돌에 따라 줄인다. 6개 분야가 6대 기기와 반드시 1:1로 대응하지는 않는다.
후속 phase의 독립 작업은 앞당길 수 있다. 예를 들어 Phase 1 후 A04/A05/A06·D09를, Phase 2의 D02/D12가 완료되면 D04→D05/D08을 HQ가 배정할 수 있다. 이 규칙은 Phase 1 내부의 1-1 → 1-2 → 1-3 → 1-4 순차 진행을 해제하지 않는다. A09 전에는 그 계약을 사용하는 전체 feature 이전을 완료했다고 간주하지 않는다.
Phase 2의 첫 저장 경로를 표준으로 검증하고, Phase 3에서 feature별 화면/resource로 확대한다. prototype이나 mock만으로 A09를 완료하지 않는다.
U01의 CSS 규약은 Phase 1에 시작한다. 실제 화면 이식 U02/U03은 Phase 3, 잔여 CSS 품질 U07과 가상화 U04는 Phase 4다. CSS 품질을 마지막 시각 검사만으로 대신하지 않는다.
DB migration 절차는 Phase 1, 실제 모델·저장 변경은 Phase 2, 통계 구조는 Phase 3에 진행하고 각각 해당 PR에서 검증한다. Phase 5는 이번 릴리즈 전체의 populated DB upgrade를 재현한다.
Phase 4 완료 후 U06/R02/R03/R04를 병렬로 실행한다. 공유 staging/DB fixture를 사용하는 파괴적 시험끼리는 별도 환경 또는 실행 슬롯으로 격리한다.
각 phase는 코드를 구현·통합·검증하는 단위이며 목표 구조 전체의 릴리즈는 v0.18.0이다. Phase 1·2의 실제 이전 릴리즈 포함은 위 배포 장부대로 기록하고, Phase 2 종료 보완의 v0.17.3 지정과 Phase 3의 release/v0.18.0 통합을 구분한다. 필수 검증 실패 시 해당 소유 이슈로 돌아가 수정한다.

충돌이 나기 쉬운 경계

경계	소유권
Repository/controller 최초 추출·최종 배선	A01/A07/A15 담당; feature 작업자는 분리된 모듈 소유
pending store·IDB	S02→S04→S07의 queue 담당; S05/S06 배선은 순서대로 합류
SQL registry·migration 번호·schema	domain별 object·번호·snapshot은 해당 PR 담당이 검증, landing은 Actions 자동 큐
CSS/token·mobile/desktop	U01 계약; U02/U03의 표현; U07 정리; U04 변경은 U06까지 검증
API/auth·native·인입	B01: provider/API, N01: bridge/SW, D09: job runtime, I01: parser/normalizer
Vite/package/lock/workflow/native 환경	B02 계약·배정된 소유자 검증 → Actions 자동 통합 슬롯; U05는 feature import graph 중심

6. 여러 Fable 5.1을 운영하는 방식

HQ는 목표·계약·의존성·공용 변경의 충돌·예외·릴리즈 상태를 조율한다. 특정 HQ 세션의 상주를 일상적인 착수·머지 조건으로 삼지 않는다. Fable은 지정 issue의 구현·관련 행동 시험·PR 증거와 검증된 랜딩 요청을 소유한다. 서로의 범위를 추측해 보완하거나 다른 기능을 예방적으로 리팩터링하지 않는다.

초기에는 독립 작업 4개 정도, 경계가 열리면 4–6개 정도를 동시 진행하는 것을 제안한다. 이는 기기 수 제한이 아니라 첫 운영 WIP 기준이다. 같은 파일 충돌과 리뷰 대기 시간이 늘면 동시 작업을 줄인다. 작업자가 남아도 계약이 미정인 코드를 추측해 만들게 하지 않는다.

작업열	순서 또는 독립 범위	겹치면 HQ가 직렬화할 부분
Durable queue	S01→S02→S04→S07	pendingWorkoutSaves/IDB adapter
Command·충돌·초안	S03→S05→S06→S09; S08 독립	pending store 최종 wiring, identity 계약
DB·통계	D02→D04→D05→D06/D07; D08·D09·D10 분리	enqueue, 최상위 projector, migration 생성
복구	S10→S11, 이후 R03	recovery SQL와 backup workflow
앱·도메인	A01 후 domain repository 병렬, A07→A08→A09 후 feature 확장	거대 Repository/controller에서의 최초 추출·최종 삭제
Editor·UI	A12/A13, U01, U02/U03 후 U07→U04	props·tokens·CSS 파일과 shell 최종 wiring
API·환경	B01, B02	provider/API는 B01, runtime 조립 A07, 공용 설정은 배정된 소유자 검증과 자동 큐 통합
Native	N01	native/bridge/SW, B01 callback 계약·B02 환경 계약만 공유
전체 인입	I01	parser/normalizer는 I01, Wodup worker runtime은 D09

작업열은 담당 영역이지 track 수만큼 팀을 동시에 생성하라는 지시가 아니다. 한 Fable이 끝난 뒤 같은 영역의 다음 ready issue를 맡는 편이 문맥 비용과 충돌을 줄인다. 플랫폼 디자인 담당과 기능 연결 담당은 역할로 구분하며 기존 문서의 모델 이름을 새 실행 도구의 권한으로 오해하지 않도록 G01에서 정리한다.

공용 파일 운영

아래 Actions 랜딩·staging 자동 통합 설명은 main 대상 PR에 적용한다. Phase 3은 사용자 지정에 따라 **작업 PR → release/v0.18.0**으로 통합하고, main용 landing:request를 적용하지 않는다. release 브랜치 병합 자체를 main staging 검증이나 Production 공개로 집계하지 않는다. 각 작업 담당자는 실제 PR base·선행 SHA·관련 검증과 공용 변경 순서를 확인하며 HQ의 상주나 새 승인 라벨을 기다리는 절차는 만들지 않는다.

appController, remoteDataController, barbelicRepository, pending store는 먼저 담당자 한 명이 분리 경계를 만든다. 다른 작업자는 새 목적지 모듈을 구현하고 최종 export/wiring은 해당 소유자가 합친다.
package.json/lock, Vite 설정, app entry, workflow, 공통 DTO는 배정된 소유자가 계약·영향을 확인하고 자동 통합 슬롯에 요청한다. 기존 이슈에서 승인된 변경이면 HQ 재승인을 받지 않는다.
schema.sql·migration 번호·배포 manifest는 각 PR 담당자가 도메인 원천·DDL/backfill과 함께 생성·검증한다. 동일 object나 공용 파일의 변경이 겹칠 때만 HQ가 책임·순서를 조율한다.
migration 번호는 실제 통합 대상의 최신 migration 목록과 대조해 합류 직전에 확정한다. Phase 3은 release/v0.18.0와 이후 합류할 main의 번호 충돌을 함께 확인하며, 이미 적용한 migration은 수정하지 않는다.
여러 PC의 로컬 파일 잠금은 서로를 잠그지 못한다. 담당자가 npm run landing:request -- --pr <N>을 실행하면 저장소 공통 Actions concurrency 큐가 최신 head/main·검증·관리자 호환을 확인하고 squash merge → 명시적 staging 배포·확인까지 직렬 실행한다. landing:active·landing:queued는 승인·잠금이 아니다.
대기 중 head/main이 바뀌면 담당자가 최신화·관련 검증 후 재요청한다. 자동 작업은 다른 PR의 코드를 임의 수정하지 않는다. workflow 종료 시 슬롯은 반납되며 이미 머지된 PR은 같은 요청으로 staging 확인·재개가 가능하다. 이전 staging 실패를 무시하고 무관한 변경을 쌓지 않는다.
각 통합 PR은 staging 적용·ledger 확인까지 닫는다. Production 승인 대기는 랜딩 슬롯을 점유하지 않으며 최종 R06은 기존 별도 오너 승인 릴리스 경로를 따른다. 상세 절차는 HQ 운영 정본 §4를 따른다.

Fable 한 작업에 주는 지시서

text

Release / issue: v0.18.0 / S02
목적: 새 미전송 저장 실패 시 이전 요청 보존
기준: base SHA, 선행 issue의 merged SHA, 적용 계약 버전
허용 경로: 명시 목록
입력 계약 / 출력 계약: 링크와 타입
완료 조건: 관찰 가능한 불변식
검증: 필수 명령·fault 시나리오·fixture
금지/범위 밖: 제품 정책 변경, 다른 issue 파일, DB 이력 수정
제출: PR, 변경 이유, 실제 실행 결과, 호환/전환 영향
미해결: 실패·미실행을 그대로 보고

각 작업자는 별도 branch/worktree에서 시작한다. Phase 3의 시작 기준과 PR base는 release/v0.18.0이며 Phase 2 종료 보완의 대상은 main이다. 공용 worktree를 공유하지 않는다. HQ는 PR 제목이나 모델의 “완료” 문장 대신 diff·계약·시험 결과를 검토한다. 검토 후 SHA가 바뀌면 관련 검토와 검증을 새 SHA에 맞춘다.

7. 작업 상태와 누락 방지

text

Planned → Contract-ready → Ready → In progress → Review
        → Merged → Staging verified → Release verified

선행 구현이 merge되고 필요한 계약·파일 소유권이 확정되면 Ready가 된다. 개발 브랜치의 단위 테스트 성공과 staging/production 검증은 따로 기록한다. GitHub의 open/closed 두 상태만으로 이 차이를 대신하지 않는다.

추적 장부는 다음을 연결한다.

text

보고서 항목 → 실행 issue → 구현 PR/SHA → 행동·성능 증거
            → staging 검증 → production release/SHA

HQ는 진행률과 함께 다음을 본다: 현재 병목 선행 issue, 파일 충돌, 계약 변경, 검증 대기, 해결되지 않은 저장/정합 위험, 실제 끝난 보고서 항목. 작성 코드량·commit 수·line 수 감소로 진척을 평가하지 않는다.

새로 발견된 결함은 해당 issue의 완료 조건에 직접 관련되면 포함한다. 별개의 제품 요구나 이론적 개선은 범위를 무작정 늘리지 않고 기록한다. 출시를 막는 실제 데이터 결함은 0.18.0 선행으로 추가하고 DAG·범위 합계를 갱신한다. 원 보고서 항목은 조용히 범위 밖으로 이동하지 않는다.

총괄 문서와 개별 작업 기록의 역할

이 파일 하나에서 전체 내역을 확인한다. 범위·목표·분야/Phase·선행·실행 상태·릴리즈 증거의 요약은 여기에서 갱신한다. 같은 로드맵을 별도 Phase 문서나 별도 총괄 문서로 복제하지 않는다. 실제 GitHub 이슈가 생기면 계획 ID를 유지하고 12절의 상태/링크 칸에 연결한다. 작업별 기술 논의와 상세 로그는 그 이슈와 PR에 둔다.

작업 세션의 읽기 범위와 맥락 인계

총괄은 HQ가 전체 범위·계약·의존성을 조율하는 정본이며, 각 작업자가 매번 1–12절이나 63개 카드를 통독할 필요는 없다. 작업 세션의 시작점은 자기 GitHub 이슈의 맥락 요약·상세 작업·완료 조건, 저장소 AGENTS.md, 직접 선행에서 확정한 계약·PR·검증·미해결 인계다. 최신 진행과 합의는 이슈 댓글 및 연결 PR에서 확인한다.

HQ는 이미 게시한 Phase 1의 #1279–#1289에 이 방식을 소급 적용하고, 후속 이슈를 게시할 때도 아래 내용을 본문 앞에 넣는다.

전체 이식 목표와 현재 Phase의 목적, 서버/클라이언트·공통 의미/플랫폼 표현의 책임 경계.
이 작업이 해결하는 문제와 목표 구조에서 맡는 위치.
각 직접 선행에서 받을 결과와 그 계약을 기다리는 이유.
후속 작업에 넘길 산출물·담당 경계 및 이 이슈에서 완료하지 않는 후속 구현.
실제로 읽을 계약·코드의 링크와 읽기 초점, 요약 기준일. 큰 파일은 관련 함수·RPC·타입·호출자를 검색해 필요한 정의를 확보한다.

요약은 탐색 비용을 줄이는 안내이며 정본 계약의 복제본이 아니다. 세션은 읽은 코드·계약 SHA를 남기고, 범위·정책·책임·의존성이 모호할 때 총괄의 해당 카드/절만 추가 확인한다. 계약이 바뀌면 HQ가 영향을 받는 이슈의 요약·링크·인계를 함께 갱신한다. 기존 작업 내용·수용 조건·직접 선행은 요약으로 축소하거나 대체하지 않는다.

중요한 구조 변경, 저장·복구 계약 전환, DB 이관, 통계 발행 전환, UI/CSS 체계 변경, 릴리즈 리허설·출시 결과는 docs/updates/YYYY-MM-DD-slug.md에 각각 독립 문서로 남긴다. 중요 변경 한 건이 여러 이슈/PR에 걸칠 수 있으므로 63개 이슈마다 기계적으로 새 문서를 만들지는 않는다.

기록 대상	개별 문서에 남길 내용	이 총괄 문서에 갱신할 내용
구조·계약 결정	문제, 선택 이유와 대안, 책임·데이터 흐름 전후, 정본 계약 링크	결정 요약, 영향 이슈·의존성, 상세 기록 링크
저장·DB·통계·복구 전환	원본/ID 보존, migration·backfill, 호환 범위·전환·실패 복구, 실제 시험 결과	Phase 통과 증거, PR/SHA·migration, 남은 위험
UI·CSS·플랫폼 이전	공통 의미와 표현 경계, 주요 흐름, 실제 화면·접근성·성능 전후	관련 이슈 상태, 확인한 플랫폼, 상세 기록 링크
검증·릴리즈	후보 SHA, 검증 명령·환경·실측·미실행, 배포와 관찰 결과	실행/검증 완료 수, 릴리즈 상태, 잔여 항목

개별 문서는 updates 기록 형식을 따른다. 랜딩 날짜(KST), 관련 이슈/PR, 배경→해결 구조→적용 내용→검증 결과→남은 일을 적고 이 총괄 문서로 돌아오는 링크와 계획 ID를 포함한다. 원본 계약은 docs/contracts/·docs/data/·docs/process/의 해당 문서를 갱신하고 작업 기록에는 연결한다. 회고 문장을 새로운 기술 계약처럼 중복 유지하지 않는다.

상세 기록을 추가한 PR에서 이 문서의 아래 장부, 12절 해당 이슈, Phase 집계를 함께 갱신한다. 기존 규칙대로 docs/README.md 작업 기록 표와 docs/.vitepress/config.mts 작업 기록 목록 끝에도 개별 문서를 등록한다. 미래 문서의 빈 파일이나 아직 없는 링크는 미리 만들지 않는다.

중요 업데이트 기록 장부

Phase 1의 계약·codec·transport·UI 기반·SQL 및 검증 도구가 아래 PR로 구현됐다. 각 행은 최초 랜딩 증거이고 이후 S01/D01/D13 보완은 종료 기록으로 연결한다. 전체 feature·worker·CSS 이식과 Production 적합성은 다음 Phase의 범위다.

날짜(KST)	Phase / 계획 ID	중요한 변경·결정	개별 updates 문서	이슈 / PR / SHA·migration	검증 결과·미확인
2026-09-07	Phase 1 / G01	보존 정책 P1~P10 / 변경 계약 5종을 ADR 로, 기준선·62개 소유 역할·공용 자원 통합 담당·라벨 병합 큐·스테이징 슬롯·릴리스 게이트·관리자 게이트를 HQ 운영 정본으로 고정. 배포·역할·랜딩·AGENTS 문서의 옛 문장(main=운영 배포, 모델 이름 역할, 한 PC 잠금) 정정. `landing-queue` 워크플로 검사 + 라벨 4개	G01 작업 기록	#1279 / PR #1296 / migration 없음	앵커 테스트 33·check:deployment·VitePress build 통과. 미확인: `landing-queue` 검사의 실제 차단력은 main 보호 규칙(HQ 운영 정본 §6 O1) 뒤
2026-09-07	Phase 1 / G05	추적 파일 1,934개·테이블 77·cron 7·Edge 3·API 4를 영역 25×계층 20 에 붙이는 분류 규칙 파일과 검사 도구(미분류·미등록 진입점·장부 행 누락·미배정/미확인·문서 동기화). 공용 파일·DB object·CSS scope·native bridge 소유권 표와 계약 변경 통지 절차. 운영 정본 §3 파일명 정정(`appController.jsx`→`.tsx`)	G05 작업 기록 · 장부	#1281 / PR #1307 / migration 없음	미분류 0·미등록 0·`--strict` 통과·행동 테스트 7·`npm run check` 통과(2,593). 미확인: 다른 세션이 새 경로 PR 에서 규칙을 추가하는 운영은 첫 사례 전
2026-09-07	Phase 1 / G02	clock·ID·장애 주입·두 DB 연결·oracle fixture	G02 기록	#1280 / PR #1310 / `b0e5076a` / 새 migration 없음	최초 PR의 CI·검증 및 개별 기록 참조; Production 미검증
2026-09-07	Phase 1 / G03	공유 도메인·명령·조회·표시 계약	G03 기록	#1282 / PR #1311 / `e94f0d34` / 새 migration 없음	최초 PR의 CI·검증 및 개별 기록 참조; Production 미검증
2026-09-07	Phase 1 / D03	SQL 원천 462개·registry·후보 생성·drift 검사	D03 기록	#1283 / PR #1312 / `16b8e996` / 새 migration 없음	최초 PR의 CI·검증 및 개별 기록 참조; Production 미검증
2026-09-07	Phase 1 / G04	6개 workload·실측·성능/관측 예산	G04 기록	#1284 / PR #1315 / `beff760b` / 새 migration 없음	최초 PR의 CI·검증 및 개별 기록 참조; Production 미검증
2026-09-07	Phase 1 / S01	버전별 codec·원문 보존·구번들 공존	S01 기록	#1285 / PR #1320 / `50580d7b` / 새 migration 없음	종료 보완·직접 검증; Production 미검증
2026-09-07	Phase 1 / D01	통계 DAG·writer 장부·oracle·동치 기준	D01 기록	#1286 / PR #1319 / `c58c6522` / 새 migration 없음	종료 보완·직접 검증; Production 미검증
2026-09-07	Phase 1 / D13	populated upgrade·위험 판정·중단 재개·backfill 도구	D13 기록	#1287 / PR #1318 / `e970dd7d` / 새 migration 없음	종료 보완·직접 검증; Production 미검증
2026-09-07	Phase 1 / A01	RPC transport·도메인 factory 9개·port 배선	A01 기록	#1288 / PR #1316 / `947413d1` / 새 migration 없음	최초 PR의 CI·검증 및 개별 기록 참조; Production 미검증
2026-09-07	Phase 1 / U01	공통 UI props·입력/저장/포커스·CSS 기반	U01 기록	#1289 / PR #1317 / `45e58c33` / 새 migration 없음	최초 PR의 CI·검증 및 개별 기록 참조; Production 미검증
2026-09-09	Phase 3 / A05	인입(Wodup·Motra)·관리자(신고·정지·유저 검색·운영 점검표) 서버 호출을 `importRepository`·`adminRepository` + `domains/codecs/{wodupImport,motraImport,adminModeration}Codec` 으로 이전(옛 저장소 −429줄·본문 0), Wodup 잡 DTO(단계 변환표 1곳·시작 결과 3종·Motra 동기 완료)로 `ImportPort` 결과 unknown 5→0, 관리자 함수를 일반 파사드에서 제거(앱 청크 관리자 RPC 이름 0; 관리자 화면은 v0.17.7 부터 Barbelic-docs/admin), 본인 내보내기 port 분리, 2026-09-10 main(v0.17.7) 반영 `169a9e2a`	A05 기록	#1406 / PR #1443 / release/v0.18.0 `4f6d193b` / migration 없음	`npm run check` 3,445(통과 3,418·DB 조건 27 skip)·행동 검사 24·`adminBundleBoundary` 모듈 그래프 검사·빌드 grep. release/v0.18.0 통합 완료(2026-09-10, 큐 8차 Merge Check 통과, #1491 정책으로 full CI 는 staging 승격 후보에서)·staging·Production 은 미반영(기록 §5)
2026-09-10	Phase 3 / I01	인입 세 경로(Wodup·InBody·Motra)의 실패를 공통 계약(`features/import/importContract.ts` — 단계·코드·줄/행·원문 가용성·경로 등록표·A11 화면 상태)으로, 브라우저 SHA-256 으로 완료된 파일은 `already_imported`·진행 중은 붙기·실패는 새 배치, InBody 건너뜀·중복·이미 넣은 파일 정직 보고, Motra typed 오류 5종·`statsPending`, 서버 `WodupNormalizeError`(코드·줄)·조용한 추정 경고 3종(값 불변), 죽은 Motra 파서 사본 −791줄, `npm run perf:import` 실측·replay fixture 3종	I01 기록	#1415 / PR #1498 / release/v0.18.0 `55e9fae8` / migration 없음	`npm run check` 3,570(통과 3,532·DB 조건 38 skip)·새 테스트 17·`ci:precheck-local` pgTAP 136파일/2,625 assert. release/v0.18.0 통합 완료(2026-09-10 11:44 KST, 큐 Merge Check 통과)·staging·Production 은 미반영(기록 §5)
2026-09-10	Phase 3 / U03	Desktop A12/A13 연결·S08 최신 입력·S09 복구·intrinsic host/shell·실제 200% zoom	U03 기록	#1421, PR #1520 · `c1af78e8`, migration 없음	browser 29/29·actual adapter 7/7. Production/native 미실행
2026-09-10	Phase 4 계획	D14 추가·기존 여섯 작업 포함 7개 게시·D11/R01/R04/R05 수용 기준 보강	계획·실행 이슈	앱 구현·migration 없음	63개 ID·191개 의존·문서 검사, 제품 성능 미실측
2026-09-10	Phase 5 게시	기존 6개를 4/1/1 실행 스텝·상세 절차·최종 검증 범위로 게시	이 문서 §5·§12·§13	U06 #1540, R02 #1541, R03 #1542, R04 #1543, R05 #1544, R06 #1545	63개 ID·191개 직접 의존 보존, 원격 본문/선행 대조. 제품 구현·검증·배포 없음

Phase 1 통합 증거와 후속 경계

종료 보완 PR #1322도 bf9064973으로 병합됐으며 전체 CI·자동 랜딩·staging DB/함수/프론트엔드/스모크가 성공했다. Phase 1 도구·대표 경로 검증은 완료이며 Production 승인은 포함하지 않는다.
원 PR 11개가 main에 병합됐다. D13 #1318(e970dd7d)·D01 후속 #1321(c2bf7f60)의 실제 Supabase 검증과 스테이징도 확인했다. D13 staging, 후속 main staging.
S01 원문 보존/준비 상태, D01 기준일·재적재 결정성, D13 실패 증거 거부·owner probe와 CASE-039의 실제 RPC 완료 대기는 종료 보완 기록이 최신 인계다. 과거 개별 기록의 미실행·미분류 수치를 현재 미완료로 다시 세지 않는다.
기존 v0.17.1 백필은 수정한 D13 도구의 4년 실측(고정 Postgres 17.6.1.127)에서 잠금 5,017ms > 5,000ms로 거부됐다. 다른 이미지에서의 예비 5,171ms는 릴리스 판정에 사용하지 않는다. 사실 보존·원천 일치·빈 DB replay 성공과 예산 합격을 분리한다. 기존 적용 migration을 수정하거나 예산을 넓혀 합격으로 바꾸지 않는다. 이 제약은 실제 릴리스 PR #1303 및 R05의 rollout 입력이며 Phase 1 도구 제공 완료가 Production 업그레이드 승인은 아니다.
새 writer 활성화, atomic outbox/claim, 전체 UI·CSS 이식, worker 단일 작성자·generation 전환은 계획대로 후속 Phase에서 수행한다.

PR #1278의 CI 기준선 보수

최초 실패 run의 Linux 검사는 2,586개 중 2,583개 통과·3개 실패였다. workoutDraftArchive.test.mjs의 2026-08-29 저장 fixture와 실제 Date.now()가 섞여 7일 TTL 이후 실패했다. production의 보존 동작은 바꾸지 않고 해당 테스트 context의 Date만 격리하며 종료 시 복원하도록 수정했다. 활성/보관 봉투의 7일 직전·정확 경계, 원문 보존, 동일 봉투가 실제로 살아 있는 선점 음성 사례도 검증한다.

수정 전 해당 파일 9/12 → 수정 후 12/12, archive/cache/store 관련 28/28, manifest gate 통과를 확인했다. 이 파일은 감사 manifest 미등재여서 기존 감사 대상의 변경 신고가 필요하지 않으며 manifest 자체는 수정하지 않았다. 로컬 전체 check는 2,585/2,586으로 날짜 실패 3건이 해소됐고 Windows checkout의 schemaSnapshotContract.test.mjs CRLF 단언 1건은 남았다. LF/CRLF 기준선 정리는 G02의 기존 범위에 남긴다. 원격 최종 CI 결과는 PR #1278의 해당 커밋 검사로 확인한다.

이 최소 보수는 G02의 일부 입력이며 공통 fault/barrier/oracle·플랫폼 기준선 전체를 완료한 것이 아니다. G02 담당은 최신 main/PR diff를 먼저 확인해 이미 반영된 수정은 재구현하지 않는다.

결정과 계획 변경 이력

결정	내용	적용 상태
D1	목표 구조 이식과 보고서 개선사항 전체를 v0.18.0에 포함한다. 대안 관계인 제안은 선택 이유를 남기고 하나의 방식으로 해결한다.	계획 합의; 구현 전
D2	보강된 62개 작업을 6개 분야·5개 Phase로 운영하며 직접 선행과 소유권으로 착수 순서를 정한다.	계획 배정 완료
D3	전체 로드맵·현황은 이 파일 하나, 중요한 실제 업데이트는 updates 안 개별 문서로 관리한다.	이번 문서에 반영
D4	2026-09-07: Phase 1 11개를 말머리 [리팩터링 1-1]~[리팩터링 1-4]와 상세 실행 지시로 게시하고 실제 번호를 연결한다.	#1279–#1289 게시; 전체 62개 범위·186개 직접 의존 유지
D5	2026-09-07 G01: 보존 정책·변경 계약은 ADR, 운영(소유권·병합 큐·릴리스 게이트)은 HQ 운영 정본이 정본. 양자택일 = 사본+명시 복구(F07)·기존 store typed 완성(F09)·도메인 원천+생성기(F24)·충돌 문장은 그 자리에서 정정(F30). 여러 PC 직렬화 = GitHub 라벨 큐 + HQ 단일 머저(merge queue 는 private 저장소라 미제공). 새 writer 는 S01 공존 실험 통과 전 비활성	PR #1296 반영. main 보호 규칙·Production 승인자는 오너 손(운영 정본 §6)
D6	2026-09-07: 담당 세션은 이슈별 맥락 요약과 필요한 계약·선행 인계부터 읽고 총괄은 해당 부분만 참조한다. HQ는 전체 정본과 영향 이슈의 요약을 함께 관리한다.	게시된 #1279–#1289 소급 적용; 후속 게시에도 적용. 작업 범위·완료 조건·의존성 유지
D7	2026-09-07: Phase 1의 스텝을 합쳐 진행하는 제안은 채택하지 않고 1-1 → 1-2 → 1-3 → 1-4 순서를 유지한다. 같은 스텝 안에서만 병렬 진행하며 앞 스텝의 완료·검증·병합 후 다음 스텝에 착수한다.	실행 순서 확정; 기술적 직접 의존과 62개 작업 범위는 유지
D8	2026-09-07 오너 요청(#1313): D5의 HQ 상주·라벨 승인·단일 머저 절차를 담당자 요청 → 저장소 공통 Actions 자동 직렬 랜딩으로 대체한다. HQ는 구조·범위·의존성·공용 파일 충돌·예외만 조율한다. 최신 head/main·기존 검증·관리자 호환·staging 완료는 계속 확인하며 Production 오너 승인은 유지한다.	운영 정본·랜딩·branch-workflow·AGENTS 및 이 문서의 현행 지침에 반영. 과거 G01 기록은 보존. 62개 범위·직접 의존·D7 스텝 순서·기존 완료 상태 유지
D9	2026-09-08: Phase 3 21개를 `[리팩터링 3-1]`~`[리팩터링 3-4]`의 7/7/6/1 스텝으로 게시하고 각 이슈에 자기 맥락·선택 필독·직접 선행·상세 작업·검증·후속 인계를 포함한다.	#1402–#1422 게시. 전체 게시 50/62·원 구현 PR 병합 29/62·Phase 3 구현 0개·미게시 12개; 62개 범위·186개 직접 의존 유지
D10	2026-09-08 사용자 지정: Phase 2 종료 보완만 `main`에 병합해 v0.17.3에 포함하고, Phase 3 커밋은 `release/v0.18.0`으로 통합한다. 개별 작업 PR base도 release 브랜치로 고정하며 `main`용 `landing:request`를 release에 사용하지 않는다.	통합 대상 확정·이 문서에 반영. Phase 2 종료 보완은 실제 main 병합 전이며 #1401 합류 뒤 검증은 별도 기록. Phase 3의 main 자동 병합·Production 배포 승인이나 HQ 상주/추가 라벨 절차를 뜻하지 않음
D11	2026-09-08 사용자 요청: #1328은 추가 성능 측정을 진행하지 않고 종료하며, #1342는 v0.17.3 스테이징으로 관리한다.	#1328 Closed · `[v0.17.2 반영완료]`, 대표 운영 seq_scan·저장 지연 추가 측정 생략(측정 성공 아님). #1342 Open · `[v0.17.3 스테이징]`, milestone v0.17.3·원 구현 release/v0.17.3 포함·기존 staging 성공. HQ 별도 보완은 main 미반영·검증 중. R04/R05 전체 검증·다른 작업 수락 조건·62개 ID/의존 유지
D12	2026-09-10 사용자 요청: 데이터 쓰기 효율 실행계획을 Phase 4에 반영하고 Phase 4 작업을 이슈로 게시한다.	D14 신규·총 63개·Phase 4 7개 게시, D14의 선행 D02/D04/S10/D11 및 R01의 D14 선행 의존 추가. 기존 D11/R01/R04/R05 완료조건 보강. 기록
D13	2026-09-10 사용자 요청: “phase 5도 일단 이슈 만들어줄래?”	기존 U06/R02/R03/R04/R05/R06 6개를 4/1/1 스텝으로 게시. 63/63 게시·191개 직접 의존 유지, 구현/검증/배포 미착수. 새 범위·의존·배포 승인 추가 없음

범위·정책·의존성이 바뀌면 날짜, 이유, 영향 ID, 승인/합의 근거를 이 표에 추가하고 관련 카드와 합계를 함께 고친다. 과거 적용 결과는 개별 기록에 보존한다.

8. 데이터 이관·호환·전환 전략

① 확장: 구형 앱이 계속 사용하는 공개 v5 writer/조회 계약을 유지한 채 새 내부 함수·index·메타데이터·복구 capability를 추가한다. canonical 사용자 사실은 구조 리팩터링을 위해 다시 작성하지 않는다.

② 읽기 호환: 구형 IDB/draft/receipt를 버전별 decoder로 읽는다. 기존 mutation ID/hash/sourceRef를 다시 만들지 않는다. 알 수 없는 row를 빈 데이터로 처리하지 않는다.

③ writer 안전성: 구형 탭은 새 lease/successor를 모를 수 있다. 실제 구 번들과 다중 탭으로 검증한다. 안전한 공존을 증명할 수 없다면 기존 입력을 보존하고 upgrade가 가능한 시점까지 활성화를 기다린다. 새 버전의 체크만으로 옛 탭을 막았다고 가정하지 않는다. 이 설계는 S01에서 먼저 검증하고 R02에서 최종 확인한다.

④ 서버 그림자 검증: 동일 canonical snapshot으로 full/incremental을 비교한다. shadow는 별도 결과 공간에서 비용을 제한해 실행하고 사용자에게 공개하지 않는다. policy golden corpus도 함께 검증해 두 구현이 공유하는 버그를 놓치지 않는다.

⑤ 단일 경로 전환: 사용자별 worker를 먼저 검증된 full projector로 확인한 뒤 incremental을 활성화한다. 정상 상태에서 동일 최종 테이블에 구/신 작성자가 동시에 쓰지 않는다. 모든 projection이 준비된 generation만 발행한다. live cohort 전환의 실제 설정·승인 범위는 릴리즈 직전 확정한다.

⑥ 정리: 활성 앱의 기존 거대 구현·임의 fallback·중복 writer를 이번 릴리즈에서 제거한다. applied migration·필요한 구형 decoder·현재 지원하는 v5 adapter는 명시적 호환 경계다. 불필요한 내부 wrapper 제거와 사용 중인 공개 API의 DROP은 다른 일이다. 사용 증거 없이 공개 계약을 삭제하는 일을 “모든 개선사항 구현”의 조건으로 삼지 않는다.

⑦ rollback: DB downgrade·IDB clear·receipt 삭제로 되돌리지 않는다. 호환되는 frontend와 검증된 full projection 경로, feature 전환 취소, forward fix를 사용한다. 새 queue를 이해하지 못하는 과거 bundle은 rollback 후보가 될 수 없다. 정확한 허용 버전은 R02/R05 결과에 남긴다.

9. 검증과 릴리즈 절차

테스트는 각 issue의 위험에 맞게 추가한다. 문서 이동·단순 이름 변경마다 구현을 복사하는 테스트를 만들지 않는다. 저장 원자성·DB 경합·통계 동치·복원처럼 결과를 확인해야 하는 곳에 실제 행동 검증을 둔다. 기존 보안/import 경계 검사는 유지한다.

검증 층	이번에 반드시 남길 증거
로컬·정적	lint/types/boundaries/unused/check/build, deterministic clock/line ending, 감사 manifest 신고
저장	실제 IDB quota/abort/다중 탭·network response loss·owner 전환·구형 queue
DB	두 연결 barrier·멱등·OCC·RLS/grants·migration replay/pgTAP·원본 불변
통계	과거 수정/삭제/순서 fixture·full vs incremental·단일 작성자·세대 발행·stale lease
UI	실제 연결한 모바일/desktop·IME·확대·focus·back/overlay·상태 표현
성능	같은 사양/fixture 전후 p95·lock·queue·WAL/rows·초기 bundle/DOM, 혼합 지속 부하
복구	현재/구형 사본·전체 가족/인입 복원·checksum·실측 RPO/RTO
릴리즈	기존 앱/서버 호환·staging dress rehearsal·exact SHA·production 관찰

초기 감사에서 DB 경합/운영 부하/실제 복원은 미실행이었다. 이번 로드맵은 그 검증을 구현 완료 조건으로 포함한다. 현재 통과했다고 주장하지 않는다. 외부 환경·secret이 없어 필요한 lane이 skipped된 CI는 릴리즈 합격이 아니다.

2026-09-10 실행 기준: 앱 작업 → release/v0.18.0 → staging → main(Production). 작업 PR 전 precheck, 작업→release의 일반 Merge Check, 최종 release→staging의 full CI를 구분한다. staging→main은 동일 tree의 유효한 full 기록과 현재 staging 배포·smoke를 확인한다. 실제 배포는 DB→Edge→앱→smoke 순서와 현재 릴리스 절차를 따른다. 문서·관리자는 별도 저장소/검사/배포 경계를 따른다.

자동 검증은 2026-09-10 #1478 제외 범위를 적용한다. 와드업·관리자 관련 제외 검사를 이 계획을 근거로 재활성화하지 않으며, 제외와 필요한 검사 미실행을 구분한다. 오너의 실기기 확인을 통과 게이트로 삼지 않는다. 자동 증거와 사람의 감각으로 판단할 미검증 품질을 분리한다.

최종 후보 SHA·migration·staging 결과·허용 rollback/forward-fix·복구 증거를 준비한다. 총괄 문서와 63개 실행 이슈 게시를 제품 구현·승격·Production 배포 완료로 해석하지 않는다.

10. 0.18.0 완료의 정의

보고서 31개 추적 항목이 구현 결과 또는 명시적 대안 선택 근거에 연결돼 있다.
완료 기록 쓰기는 예외 없이 durable 요청에서 출발하고, 교체·응답 유실·충돌·업데이트에도 request identity와 원문을 보존한다.
canonical/receipt/dirty는 원자적이고, 사용자 간 작업은 긴 전역 batch 잠금으로 묶이지 않는다. D14의 실제 값이 변하지 않은 자식·순서에는 물리 쓰기를 하지 않으며 새 저장의 revision/receipt/generation은 유지한다.
통계는 단일 작성자·정확한 scope·checkpoint/suffix·완전한 generation 발행으로 동작하고 full 기준과 일치한다. D11은 행 계산 출처와 owner 공개 세대를 구분하고 변경된 공개 키만 원자 발행한다.
feature가 좁은 repository/resource/editor/binding을 사용한다. 거대 context와 mutable 중복 상태, 활성 내부의 AnyRecord/MobileProps/dual shape를 제거한다.
모바일/desktop은 같은 입력·도메인 의미를 사용하며 responsive·접근성·긴 목록·초기 로딩 예산을 실제로 통과한다.
미사용·대체 구현과 소스 모양 의존 테스트를 정리하고, 보존한 호환 경로는 목적과 제거 조건이 명시된다.
구형 사용자 데이터와 실제 사본을 이용한 호환·복원·혼합 부하·배포 리허설을 통과한다.
검증된 소스가 production에 배포됐고 관찰 구간·유효 사본까지 확인돼 있다.

기존 62개는 개정 3의 실행 분해이며, 2026-09-10 D14 추가 후 현재는 6개 분야·5개 Phase의 63개다. 필요한 하위 분할이 생기면 장부를 갱신하되 위 결과를 낮추지 않는다. 일정은 첫 수직 경로까지의 실제 개발·리뷰·staging 소요를 측정한 뒤 산정한다. Fable 대수를 곧바로 속도 배수로 계산하지 않는다.

유지되는 전체 커버리지 종료 조건

원 보고서 31개 항목과 별도로 C01–C08의 전체 개발 범위를 추적한다. G05가 실제 기능·계층 목록과 담당/증거 장부를 만들고, R01/R05/R06은 필수 영역의 미배정·미확인이 없음을 확인한다. 목록에 issue가 연결됐다는 사실과 코드 품질·운영 검증 완료는 구분한다.

D12가 전체 DB 관계·제약·index·비통계 쿼리 검토와 필요한 개선을 소유한다.
D13이 실제 데이터의 migration 잠금·backfill·중단 재개 절차를 만들고, 각 변경 PR과 R05가 실제 증거를 제출한다.
U01이 초기 CSS 규약을 정하고, U02/U03 이후 U07이 누적 cascade/override/중복을 정리한다. U04 및 최종 U06 검증으로 이어진다.
B01의 API/provider 계약을 A07이 소비한다. N01은 native/bridge/SW, I01은 전체 parser/파일, B02는 환경/빌드를 소유하며 R01부터 모두 합류한다.
잘된 구조는 유지 근거와 필요한 시험으로 완료한다. 확인되지 않은 결함을 전제로 전면 재작성하지 않는다.

11. 보고서와 추가 커버리지 대응표

F07b는 원 보고서 7번 안의 재전송 ID 문제, C01–C08은 추가 검토·개선 범위다.

보고서	개선사항	연결 issue
F01	Outbox 교체 원자성	S01, S02, S04, N01, R02, R05
F02	동시 저장 generation 경합	D01, D02, R02, R05
F03	Dirty scope·증분 통계	D01, D04, D05, D06, D07, D11, R04, R05
F04	Projection 다중 작성자	D01, D05, D06, D07, D11
F05	전역 worker의 사용자 간 잠금	D01, D08, D11, R04, R05
F06	Wodup 자동 복구·완료 정합	D01, D09, D11, I01, R05
F07	충돌 사본·명시 복구와 merge 정책	G01, S06, S09, S10, R02
F07b	충돌 재전송 ID의 비영속성	S01, S06, R02
F08	실제 domain repository 분리	G03, A01, A02, A03, A04, A05, A06, A16, B01, I01, R01
F09	Resource cache·lifecycle 분리	G03, A07, A08, A09, A10, A11, A16, B01, N01, R01
F10	197-field renderCtx·shell	G03, A07, A09, A10, A11, A15, R01
F11	gymData/ref/dataTick 중복 상태	G03, S08, A07, A08, A09, A10, A11, A15, A16
F12	any·범용 타입·DTO 경계	G03, S01, S03, A01, A02, A03, A04, A05, A06, A12, A13, A16, B01, I01, R01
F13	camel/snake·legacy 내부 관용	G03, S01, S03, A01, A02, A03, A04, A05, A06, A12, A13, A16, I01, R01
F14	공통 headless editor·입력 상태	G03, S08, A12, A13, U02, U03, U06
F15	예외 기반 prepare	S03, A12, A13
F16	Outbox/UI/retry 책임 혼합	G03, S04, S05, A09, R02
F17	전체 큐 조회·mirror·index	S01, S04, S07, N01, R02, R04
F18	이름 추정 이력	A14
F19	Feed 의존 이력·반복 find	A14, U04, R04
F20	실제 viewport 가상화	U04, R04
F21	고정 canvas/zoom 대응 구조	U03, U06, U07, N01
F22	Token·primitive·플랫폼 일관성	U01, U02, U03, U06, U07
F23	실제 bundle/초기 실행 비용	G04, U05, B02, R04
F24	SQL 원천·migration·wrapper 구조	G01, D03, D11, D12, D13, R01
F25	소스 모양 대신 행동 검사	G02, D03, R01
F26	Clock·UUID·scheduler·줄바꿈 재현성	G02, S08, R02
F27	Repair/rollover 전역 탐색	D01, D10, D11, D12, R04
F28	사본 검증·실제 복구	S10, S11, D13, I01, R03, R05, R06
F29	관측·혼합 부하·운영 증거	G04, S11, D08, B02, R04, R05, R06
F30	미사용 코드·잘못된 이름·오래된 문서	G01, U07, B02, R01, R06

추가 범위	내용	책임 issue	구현·검증 연결
C01	전체 기능·공유 계층 커버리지	G05	G05, G01, G03, R01, R05, R06
C02	전체 DB 모델·제약·index·대표 쿼리	D12	D12, D03, D04, R04, R05
C03	populated DB migration·잠금·backfill·재개	D13	D13, D02, D03, D09, R05
C04	CSS cascade·scope·override·중복 품질	U07	U01, U02, U03, U07, U04, U06, R01
C05	서버 API·인증·계정·관리자 권한	B01	B01, A07, A03, A05, R02, U06
C06	네이티브·SW·업데이트 생애주기	N01	N01, S01, S07, S08, U03, U06, R02, R05
C07	전체 인입·파일 처리	I01	I01, A05, A11, D09, S10, R03, R04, U06
C08	환경·빌드·의존성·자원 경계	B02	B02, G04, U05, R04, R05, R06

12. 63개 Issue 실행 목록

2026-09-11 R01 대조: 선행56개 주 구현 PR의 현재 release ancestry와 시험 기록을 연결했다. 본 표가 현재 통합 상태이며 아래 카드의 당시 착수 문구는 이식 과정 기록과 구분한다. R01도 PR1569·merge849191b5로 release 반영되어 총57개 구현이 합류했으며, Phase5 여섯 최종 검증은 예정/미검증이다. S10/S11 문서 PR16/28은 아직 main 미게시다. 정확한 SHA·검증·보존 조건을 따른다.

모두 v0.18.0 필수 범위다. 우선순위는 착수·검토 순서이며 생략 허용이나 결함 심각도를 뜻하지 않는다. ID를 누르면 같은 문서의 작업 지시서로 이동한다. 상태/증거는 실제 GitHub 이슈 게시·배정·PR 병합·검증에 맞춰 갱신한다.

ID	작업	분야	우선	Phase	직접 선행	상태 / 실제 이슈·PR·증거
G01	0.18.0 범위·정책·작업 및 배포 계약 확정	HQ	P0	1	—	release 포함 · PR1296 · `e6150af0` · 시험·제한 대조 · #1279
G02	재현 가능한 테스트 기준선과 행동 검증 기반	HQ	P0	1	G01	release 포함 · PR1310 · `b0e5076a` · 시험·제한 대조 · #1280
G03	도메인 타입·명령·조회·통계 계약 설계	HQ	P0	1	G01, G05	release 포함 · PR1311 · `e94f0d34` · 시험·제한 대조 · #1282
G04	성능·보존 관측 기준선과 릴리즈 예산 확정	HQ	P1	1	G02, G03	release 포함 · PR1315 · `beff760b` · 시험·제한 대조 · #1284
G05	전체 기능·공유 계층의 커버리지와 소유권 장부	HQ	P0	1	G01	release 포함 · PR1307 · `80572704` · 시험·제한 대조 · #1281
S01	버전별 저장 codec와 mutation protocol 구현	DURABLE	P0	1	G02, G03	release 포함 · PR1320 · `50580d7b` · 시험·제한 대조 · #1285
S02	Outbox 교체·합치기의 IDB 트랜잭션 원자화	DURABLE	P0	2	S01	release 포함 · PR1349 · `2801239a` · 시험·제한 대조 · #1325
S03	순수 command builder와 요청 identity 통일	DURABLE	P1	2	S01, A02	release 포함 · PR1363 · `1bba53eb` · 시험·제한 대조 · #1333
S04	전송 중 요청 보호·탭별 claim과 후속 명령 보존	DURABLE	P0	2	S02	release 포함 · PR1369 · `f8334135` · 시험·제한 대조 · #1334
S05	Outbox·Dispatcher·ReceiptReconciler 책임 분리	DURABLE	P1	2	S03, S04, D02	release 포함 · PR1374 · `73d6f84b` · 시험·제한 대조 · #1336
S06	충돌 재전송 요청과 복구 근거의 원자적 영속화	DURABLE	P0	2	S05	release 포함 · PR1385 · `1ebfda64` · 시험·제한 대조 · #1341
S07	Owner index·bounded mirror·IDB timeout 구현	DURABLE	P1	2	S04	release 포함 · PR1377 · `37066827` · 시험·제한 대조 · #1337
S08	Draft lifecycle·Clock·checkpoint 순서 정리	DURABLE	P1	2	S01, G02	release 포함 · PR1350 · `06db380c` · 시험·제한 대조 · #1326
S09	Conflict 사본 조회와 명시적 복구 command	DURABLE	P1	3	S06, S10	release 포함 · PR1502 · `2518e156` · 시험·제한 대조 · #1409
S10	Update·삭제·자식 전체·인입의 범위 지정 복구 엔진	DURABLE	P1	3	S01, D02, D03	release 포함 · PR1442 · `99669e3e` · 시험·제한 대조 · #1402
S11	데이터 사본 completeness·checksum·복구 manifest	DURABLE	P1	3	S10, G04	release 포함 · PR1499 · `2ab89770` · 시험·제한 대조 · #1410
D01	통계 계산 DAG·단일 작성자·동치 검증 계약	DATA	P0	1	G02, G03	release 포함 · PR1319 · `c58c6522` · 시험·제한 대조 · #1286
D02	동시 저장 generation 경합 재현과 영수증 세대 원자화	DATA	P0	2	D01, D03, D13	release 포함 · PR1352 · `7db92fb5` · 시험·제한 대조 · #1327
D03	SQL 도메인 원천·migration 생성·drift gate	DATA	P1	1	G01, G02	release 포함 · PR1312 · `16b8e996` · 시험·제한 대조 · #1283
D04	Dirty event의 정확한 영향 범위·세대별 병합	DATA	P1	3	D02, D12	release 포함 · PR1454 · `b074cbb1` · 시험·제한 대조 · #1403
D05	변경 세션 observation·기본 rollup 증분화	DATA	P1	3	D04	release 포함 · PR1506 · `8b796c1f` · 시험·제한 대조 · #1411
D06	기간·달력 projection의 단일 작성자와 bucket 갱신	DATA	P1	3	D05	release 포함 · PR1518 · `5b16a162` · 시험·제한 대조 · #1416
D07	PR·e1RM·최대반복수 checkpoint와 suffix 재생	DATA	P1	3	D05	release 포함 · PR1522 · `e2833dee` · 시험·제한 대조 · #1417
D08	사용자별 stats worker·lease·실패 복구	DATA	P1	3	D04	release 포함 · PR1510 · `a1d462a8` · 시험·제한 대조 · #1412
D09	Wodup durable 소비자·lease 회수·완료 정합	DATA	P1	3	D01, D03, D13	release 포함 · PR1445 · `b4bae47a` · 시험·제한 대조 · #1404
D10	Repair·rollover 탐색의 index·cursor·watermark화	DATA	P2	3	D04, D08	release 포함 · PR1521 · `b62a358c` · 시험·제한 대조 · #1418
D11	통계 계산 통합·동치 검증·generation publication 전환	DATA	P1	3	D06, D07, D08, D09, D10, A06, G04	release 포함 · PR1547 · `d058cbb7` · 시험·제한 대조 · #1422
D12	전체 DB 모델·제약·index·대표 쿼리 품질 개선	DATA	P1	2	G05, G03, D03, D13	release 포함 · PR1358 · `d1e77113` · 시험·제한 대조 · #1328
D13	데이터가 있는 DB의 migration·잠금·backfill 안전성	DATA	P0	1	G05, G02, D03	release 포함 · PR1318 · `e970dd7d` · 시험·제한 대조 · #1287
D14	세션 원본의 변경 행만 저장	DATA	P1	4	D02, D04, S10, D11	release 포함 · PR1551 · `576dae9b` · 시험·제한 대조 · #1533
A01	공용 RPC transport와 거대 Repository 분리 경계 생성	APP	P1	1	G02, G03	release 포함 · PR1316 · `947413d1` · 시험·제한 대조 · #1288
A02	Workout·Plan repository와 canonical codec 분리	APP	P1	2	A01	release 포함 · PR1354 · `af2a828b` · 시험·제한 대조 · #1329
A03	Catalog·Profile repository와 codec 분리	APP	P1	2	A01	release 포함 · PR1351 · `530bb4cf` · 시험·제한 대조 · #1330
A04	Social·Group repository와 codec 분리	APP	P1	3	A01	release 포함 · PR1448 · `8c4ddc69` · 시험·제한 대조 · #1405
A05	Import·Admin repository와 codec 분리	APP	P1	3	A01	release 포함 · PR1443 · `4f6d193b` · 시험·제한 대조 · #1406
A06	Stats·화면 RPC query와 codec 분리	APP	P1	3	A01, D01	release 포함 · PR1453 · `f5477802` · 시험·제한 대조 · #1407
A07	Owner·Auth·Connectivity lifecycle 분리	APP	P1	2	A01, B01	release 포함 · PR1365 · `0775e6b2` · 시험·제한 대조 · #1335
A08	Owner-scoped resource cache·typed snapshot primitive	APP	P1	2	A07	release 포함 · PR1372 · `4fb2d26f` · 시험·제한 대조 · #1338
A09	Workout·Plan·Catalog resource 이전과 첫 수직 통합	APP	P1	2	A02, A03, A08, S06, D02	release 포함 · PR1394 · `ba3b77bf` · 시험·제한 대조 · #1342
A10	Home·Calendar·PR·Volume resource와 generation UX 이전	APP	P1	3	A06, A09	release 포함 · PR1501 · `3c91514c` · 시험·제한 대조 · #1413
A11	Profile·Social·Group·Import resource 이전	APP	P1	3	A03, A04, A05, A09, I01	release 포함 · PR1516 · `daca15d9` · 시험·제한 대조 · #1419
A12	플랫폼 공통 Workout headless editor	APP	P1	2	A02, A03, S03	release 포함 · PR1378 · `1514fc52` · 시험·제한 대조 · #1339
A13	플랫폼 공통 Plan headless editor	APP	P1	2	A02, A03, S03	release 포함 · PR1375 · `d5e12e9d` · 시험·제한 대조 · #1340
A14	Canonical ID 기반 종목 이력 조회와 indexed merge	APP	P1	3	A02, A03, A06, A09	release 포함 · PR1503 · `209bbffd` · 시험·제한 대조 · #1414
A15	Feature binding 통합과 얇은 app shell 완성	APP	P2	4	A10, A11, A12, A13, A14, U02, U03	release 포함 · PR1550 · `290eadb9` · 시험·제한 대조 · #1531
A16	잔여 any·dual shape·거대 mapper 제거 완료	APP	P2	4	A15, S09, S11	release 포함 · PR1561 · `517c538e` · 시험·제한 대조 · #1534
U01	공통 시각 token·primitive·접근성 계약	UI	P1	1	G03	release 포함 · PR1317 · `45e58c33` · 시험·제한 대조 · #1289
U02	Mobile 화면을 공통 editor·typed view model에 연결	UI	P1	3	U01, A09, A12, A13, S08, S09	release 포함 · PR1523 · `b0fa93ec` · 시험·제한 대조 · #1420
U03	Desktop 공통 editor 연결과 intrinsic responsive 전환	UI	P1	3	U01, A09, A12, A13, S08, S09	release 포함 · PR1520 · `c1af78e8` · 시험·제한 대조 · #1421
U04	긴 목록의 실제 viewport 가상화와 identity 계약	UI	P2	4	U02, U03, A10, A11, A14, U07	release 포함 · PR1553 · `af5ae625` · 시험·제한 대조 · #1535
U05	Feature import graph와 초기 bundle 비용 최적화	UI	P2	4	A15, U04, G04	release 포함 · PR1565 · `2cfeac53` · 시험·제한 대조 · #1536
U06	전체 feature UX·접근성·플랫폼 일관성 검증	UI	P2	5	A16, U04, U05, S09, R01, N01, I01, B01	Planned · 게시·미착수 · U06 #1540 · `5-1`
U07	CSS cascade·scope·override·중복 코드 정리	UI	P2	4	U01, U02, U03	release 포함 · PR1549 · `4a642ad3` · 시험·제한 대조 · #1532
B01	서버 API·인증·계정 연결·삭제·관리자 경계 개선	PLATFORM	P1	2	G05, G03, A01	release 포함 · PR1346 · `ba0f4035` · 시험·제한 대조 · #1331
B02	웹·Edge·관리자·Native의 환경·빌드·의존성 경계	PLATFORM	P1	2	G05, G03, G04	release 포함 · PR1356 · `7b44295e` · 시험·제한 대조 · #1332
N01	iOS·Android bridge·생애주기·SW 업데이트 개선	PLATFORM	P1	3	B01, B02, S01, S07, S08, A07	release 포함 · PR1441 · `0102ec07` · 시험·제한 대조 · #1408
I01	전체 인입·파일 parser·identity·부분 실패 경로 개선	PLATFORM	P1	3	G05, A05, D09, G04	release 포함 · PR1498 · `55e9fae8` · 시험·제한 대조 · #1415
R01	구현 이식 종료·퇴역 코드·테스트·문서 정리	HQ	P2	4	A16, D11, S11, U05, G05, D12, U07, B01, B02, N01, I01, D14	release 반영완료 · PR1569 · `849191b5` · 검증·인계 · R01 #1537 · `4-4`
R02	구·신 앱/서버/IDB 호환과 저장 장애 통합 검증	HQ	P0	5	R01, S08, S09, N01, B01	Planned · 게시·미착수 · R02 #1541 · `5-1`
R03	실제 사본 기반 선택 복구·인입 복원 리허설	HQ	P1	5	R01, S10, S11, D11, I01	Planned · 게시·미착수 · R03 #1542 · `5-1`
R04	혼합 부하·장기 이력·UI/저장 성능 검증	HQ	P1	5	R01, G04, S07, D11, U05, B02, I01, D12	Planned · 게시·미착수 · R04 #1543 · `5-1`
R05	0.18.0 스테이징 전체 릴리즈 리허설과 후보 확정	HQ	P0	5	R02, R03, R04, U06, D13, B02	Planned · 게시·미착수 · R05 #1544 · `5-2`
R06	v0.18.0 production 릴리즈와 검증 종료	HQ	P0	5	R05	Planned · 게시·미착수 · R06 #1545 · `5-3`

13. Issue별 작업 지시서 초안

63개 카드의 목표·계획 ID를 유지한다. Phase 1 11개·Phase 2 18개·Phase 3 21개·Phase 4 7개·Phase 5 6개로 63개 모두 게시했다. Phase 5는 게시·미착수다. 게시 시점 Phase 3은 20개 원 PR이 release에 합류하고 D11이 진행 중이며, Phase 4는 게시·구현 0개다. Phase 3·4는 v0.18.0 milestone·release/v0.18.0 PR base를 사용한다. 게시·담당 배정·구현·release 병합·운영 검증을 구분한다. 아래 과거 Phase 3의 미착수·미완료 체크는 카드 게시 당시 기록이므로 실행 이슈와 최신 인계를 확인한다. 새 D14 외 기존 카드의 범위와 완료조건은 삭제하지 않았다. 신규 경로는 G03/D03 계약을 따른다.

G01

0.18.0 범위·정책·작업 및 배포 계약 확정

실행 이슈: Merged(배포 해당 없음) · #1279 · PR #1296 · e6150af0 · 기록. 종료 보완과 검증의 범위는 Phase 1 종료 기록에 정리한다.

분야 / Phase: HQ / 1
우선순위: P0
직접 선행: 없음
책임 역할: HQ
보고서 연결: F07, F24, F30
추가 범위: C01
소유 경계: AGENTS.md, docs/contracts/**, docs/process/**, .github/workflows/**

의미: 작업자들이 서로 다른 목표나 과거 규칙을 따르지 않도록 이번 릴리즈의 정본을 만든다.

산출물

보고서 개선사항-issue 대응표, 열린 issue/PR 중복·진행 작업 정리, 브랜치별 기준 SHA와 변경 소유권 표
현재 정책 유지/이번에 바꾸는 기술 계약을 구분한 ADR: 쓰기 capability, outbox 원자성·CAS, 충돌 사본, 통계 작성자, 타입·캐시 경계
여러 PC에 통하는 자동 병합 큐·스테이징 통합 슬롯과 별도 오너 승인 Production 릴리스, 관리자 별도 즉시 배포 경로의 0.18.0 게이트(D8 운영 개정)

완료 증거

[x] 현재 문서의 main/production 배포 설명과 오래된 모델 역할·CAS 금지 규칙의 충돌이 해소되고 링크된 정본이 하나다. (배포 파이프라인 첫 문단·8단계 정정, 브랜치 문서 "v0.18.0 실행 모델" 절, 쓰기 계약 §3·§11 개정 → 운영 정본 §4-6 표가 정본)
[x] 모든 보고서 항목에 구현 issue 또는 상호 배타적 제안의 선택 근거가 있으며, 각 issue의 수정 허용 경로·오너가 정해져 있다. (§11 대응표 유지 + 운영 정본 §2-1 양자택일 4건 근거, §2-2 62개 소유 역할·지시서 소유 경계)
[x] 공용 파일·DB migration 번호·schema 생성·workflow 변경은 단일 통합 순서를 갖고, 다른 PC의 로컬 잠금을 분산 잠금으로 취급하지 않는다. (G01 당시 HQ 단일 머저로 구현·완료. D8에서 담당자 요청과 Actions 자동 직렬 큐로 집행을 변경했으며 소유권·검증은 유지. 운영 정본 §3·§4)
[x] 계획의 전체 범위는 기존 보고서와 G05의 실제 feature×layer 목록을 함께 사용한다. G/B/N/I를 포함한 모든 track의 최종 소유자를 지정한다. (초기 소유권 = 운영 정본 §2-2 역할 표 62개 전부; G05 가 feature×layer 로 정밀화하되 §3 통합 담당은 유지 — §5-2)

범위·호환 주의: 이슈 생성은 승인돼 진행했다. G01 실행에서는 제품 정책을 임의 재설계하거나 운영 DB·production을 변경하지 않는다.

G02

재현 가능한 테스트 기준선과 행동 검증 기반

실행 이슈: Staging verified · #1280 · PR #1310 · b0e5076a · 기록. 종료 보완과 검증의 범위는 Phase 1 종료 기록에 정리한다.

분야 / Phase: HQ / 1
우선순위: P0
직접 선행: G01
책임 역할: 검증 담당
보고서 연결: F25, F26
추가 범위: —
소유 경계: tests/**, tests/audit/pending-changes.json, .gitattributes, scripts/**

의미: 기존 동작을 보존하면서 구조를 바꿀 수 있도록 시간·환경 때문에 흔들리지 않는 검증 기반을 확보한다.

산출물

Clock/UUID/scheduler 주입과 archive TTL fixture 수정, LF/CRLF 정책 정리
저장 fault injection, 두 DB 연결 barrier, 통계 oracle, owner 전환 및 브라우저 계약 fixture의 공통 도구
소스 모양 검사 중 행동 검사로 전환할 목록과 유지할 보안·import 경계 검사 목록

완료 증거

[x] 감사에서 확인한 날짜 의존 3개 및 줄바꿈 의존 1개 실패의 원인이 해소되고 현재 날짜와 고정 날짜에서 뜻이 같은 결과를 낸다.
[x] 기존 테스트 수정은 pending-changes에 신고하고 기능 PR에서 감사 manifest를 직접 수정하지 않는다.
[x] 실행하지 않은 DB/browser/viewport 검사는 성공으로 합산하지 않으며 기준 SHA·명령·결과를 남긴다.
[x] 기존 native/API/provider/CSS 검사를 inventory에 연결해 재사용하고 변경 위험에 맞는 행동 시험만 추가한다.

범위·호환 주의: 실패를 없애기 위해 assertion을 약화하거나 새 구현을 그대로 복사한 oracle을 만들지 않는다.

G03

도메인 타입·명령·조회·통계 계약 설계

실행 이슈: Staging verified · #1282 · PR #1311 · e94f0d34 · 기록. 종료 보완과 검증의 범위는 Phase 1 종료 기록에 정리한다.

분야 / Phase: HQ / 1
우선순위: P0
직접 선행: G01, G05
책임 역할: HQ + 타입 경계 담당
보고서 연결: F08, F09, F10, F11, F12, F13, F14, F16
추가 범위: C01
소유 경계: src/react/contracts/**, src/react/types/**, docs/architecture/**, docs/contracts/**

의미: 병렬 작업자들이 같은 ID·단위·입력 상태·영수증·조회 상태를 공유하게 한다.

산출물

canonical ID·날짜·단위·입력 union, generated DB row와 내부 DTO·view model의 분리
Command/Receipt/Conflict/Resource/Generation 최소 계약과 feature별 좁은 port, 명령별 온라인·durable 정책표
형식 버전이 있는 오프라인 decoder와 단일 camelCase 내부 모델, 계층 의존성 허용표

완료 증거

[x] UI 계약이 DB row·Supabase client·범용 BarbelicApi 전체를 요구하지 않는다.
[x] 기기 보관·서버 확정·통계 갱신 완료가 타입과 상태로 구분된다.
[x] 완료 기록 create/update/delete와 계획 update/delete의 기존 outbox 범위를 보존하며, 신규 계획 생성 등 온라인 의존 명령을 추측으로 오프라인화하지 않는다.
[x] G05의 실제 기능·계층 목록을 입력으로 삼고 시간대·정밀도·null/0·외부 provider/native bridge의 계약 소유자를 명시한다.

범위·호환 주의: 검증 없는 as 캐스팅으로 unknown을 DTO로 바꾸거나 기능마다 새 범용 프레임워크를 만들지 않는다.

G04

성능·보존 관측 기준선과 릴리즈 예산 확정

실행 이슈: Staging verified · #1284 · PR #1315 · beff760b · 기록. 종료 보완과 검증의 범위는 Phase 1 종료 기록에 정리한다.

분야 / Phase: HQ / 1
우선순위: P1
직접 선행: G02, G03
책임 역할: 성능·운영 담당
보고서 연결: F23, F29
추가 범위: C08
소유 경계: src/react/services/appPerformanceBudgets.ts, src/react/services/**report*, supabase/functions/**, scripts/**, docs/gates/**

의미: 최적화 여부를 추측하지 않고 동일한 조건의 전후 자료로 판단한다.

산출물

mutation ID·job ID·release SHA·generation 연결 규격과 queue age/lock wait/read-write p95/freshness 계측
1·4·10년 synthetic 데이터, 여러 owner·같은 owner 여러 기기, 읽기·저장·인입 혼합 부하 프로필
실제 초기 네트워크·parse·route 비용, 저장 지연·통계 지연·복구 RPO/RTO의 기준 측정과 릴리즈 상한

완료 증거

[x] 워크로드에는 동시 사용자 수뿐 아니라 요청률·기록량·동시 인입·대상 DB 사양이 기록된다.
[x] 합격 수치와 증가 추세 허용 기준은 최종 부하 시험 전에 고정한다. 아직 측정하지 않은 처리량을 보장하지 않는다.
[x] telemetry에 기록 본문·메모·인입 원문·인증 토큰을 넣지 않는다.

범위·호환 주의: 기존 RPC budget을 계측 없는 성능 보장으로 인용하지 않는다.

G05

전체 기능·공유 계층의 커버리지와 소유권 장부

실행 이슈: Merged(배포 해당 없음) · #1281 · PR #1307 · 80572704 · 기록. 종료 보완과 검증의 범위는 Phase 1 종료 기록에 정리한다.

분야 / Phase: HQ / 1
우선순위: P0
직접 선행: G01
책임 역할: HQ + 범위 통합 담당
보고서 연결: 전체 커버리지 보강
추가 범위: C01
소유 경계: docs/architecture/**, docs/contracts/**, scripts/architecture/**

의미: 보고서에 나온 문제 외에도 실제 앱의 기능과 실행 계층이 담당 없이 빠지는 것을 막는다.

산출물

route/feature/controller/repository/API/RPC/table/CSS/native/job/build의 목록과 연결 관계, 기존 검사·계약의 재사용 목록
각 영역의 유지 근거/개선·검증 완료/해당 없음/미확인 상태, 담당 issue·PR·SHA·검증 증거를 연결하는 장부
공용 파일·DB object·CSS scope·native bridge의 소유권과 계약 변경 통지 절차

완료 증거

[x] 운동·계획·달력·PR·볼륨·카탈로그·프로필/신체 데이터·소셜·그룹·온보딩·인증·계정 삭제·인입·관리자와 공유 runtime을 실제 코드 목록에 대조한다.
[x] tracked 실행 코드와 설정·스타일·asset·테스트·문서가 영역 또는 근거 있는 제외에 연결된다. 파일 연결 자체를 품질 검증 완료로 표시하지 않는다.
[x] 필수 영역의 미확인/미배정과 새로운 미분류 진입점을 R01/R05 종료 검사에서 탐지하며, G05는 목록·검사 도구까지만 완료 처리한다.

범위·호환 주의: 전 영역 코드를 다시 쓰거나 출시 전에 무제한 감사를 반복하는 작업으로 확대하지 않는다. 실제 품질 판정은 각 구현 담당이 수행한다.

S01

버전별 저장 codec와 mutation protocol 구현

실행 이슈: Staging verified · #1285 · PR #1320 · 50580d7b · 기록. 종료 보완과 검증의 범위는 Phase 1 종료 기록에 정리한다.

분야 / Phase: DURABLE / 1
우선순위: P0
직접 선행: G02, G03
책임 역할: 저장 프로토콜 담당
보고서 연결: F01, F07b, F12, F13, F17
추가 범위: C06
소유 경계: src/react/services/pendingWorkoutSaves.ts, src/react/contracts/**, src/react/persistence/codecs/**

의미: 구형 미전송 기록을 그대로 살리면서 새 저장 구현이 사용할 정확한 상태 계약을 만든다.

산출물

create/update/delete/plan-edit/plan-delete union과 immutable request/attempt metadata 구분
구형 kind/state 누락 row decoder, lease/successor/evidence 최소 메타데이터
실제 구형 탭을 이용한 writer 공존 실험과 활성화·호환 rollback 계약

완료 증거

[x] 기존 mutation ID·hash·sourceRef·payload가 변환 전후 보존되고 unknown/malformed row도 원문을 지우지 않는다.
[x] 다른 owner의 동일 target이 섞이지 않는다.
[x] 구형 writer가 새 metadata를 무시하는 경우를 확인하고, 안전한 공존 또는 초안 보존 후 업그레이드 대기 방식이 증명되기 전 새 writer를 활성화하지 않는다.

범위·호환 주의: 새 client의 capability 체크만으로 이미 열린 구형 writer를 통제할 수 있다고 가정하지 않는다.

S02

Outbox 교체·합치기의 IDB 트랜잭션 원자화

실행 이슈: Merged · PR #1349 · 2801239a · Production 포함·운영/실기기 인계 별도 · #1325 · [리팩터링 2-1]. 이슈 본문에 선택 필독·상세 작업·검증·직접 선행과 후속 인계를 포함한다.

분야 / Phase: DURABLE / 2
우선순위: P0
직접 선행: S01
책임 역할: durable queue 담당
보고서 연결: F01
추가 범위: —
소유 경계: src/react/services/pendingWorkoutSaves.ts, src/react/persistence/outbox/**

의미: 새 미전송 수정 저장이 실패해도 이전 미전송 데이터가 사라지지 않게 한다.

산출물

predecessor 조회·검증·새 행 기록·대체 행 삭제를 한 readwrite transaction으로 실행
commit 후만 local UI 반영하는 enqueueOrReplace 경계

완료 증거

[ ] quota/abort/탭 종료의 각 중단 지점에서 이전 또는 새 유효 요청이 보존된다.
[ ] transaction 밖에서 hash를 준비하고 안에서 target/state/version을 다시 확인한다.
[ ] create→delete 취소는 미전송 queued에만 적용하며 sending·결과 미상의 요청을 지우지 않는다.

범위·호환 주의: remove→put 순서를 put→remove 두 트랜잭션으로 바꾸는 것만으로 원자성을 주장하지 않는다.

S03

순수 command builder와 요청 identity 통일

실행 이슈: 구현 완료 · PR 제출 · #1333 · [리팩터링 2-2] · 기록 · 계약 save-preparation.md. 이슈 본문에 선택 필독·상세 작업·검증·직접 선행과 후속 인계를 포함한다. main 병합·staging 확인은 이슈 종결 댓글에 기록한다.

분야 / Phase: DURABLE / 2
우선순위: P1
직접 선행: S01, A02
책임 역할: command 담당
보고서 연결: F12, F13, F15
추가 범위: —
소유 경계: src/react/features/completed-workout/completedWorkoutCommands.ts, src/react/features/workout/commands/**, src/react/features/plan/commands/**

의미: 저장 준비가 네트워크 실패 예외를 이용하지 않고 도메인 값만으로 완성되게 한다.

산출물

prepareCreate/Update/Delete/Plan과 typed PreparedMutation
버전이 명시된 hash/identity primitive와 쓰기 원천 validator

완료 증거

[x] 정상 prepare에서 network/storage/telemetry 호출이나 의도적 throw가 없다. — 조립기는 identity·시계만 주입받는다; completedSessionPrepare ①·planPrepare ① 이 fetch·IndexedDB·navigator.onLine 을 부르면 던지는 전역 아래에서 정상 조립을 확인. 예외 기반 prepareSave/prepareDelete 제거
[x] 기존 fixture의 ID/hash/child identity가 같고 display projection을 update 원천으로 받지 않는다. — v0.16/v0.17 fixture 행 12개 + 새로 적은 행의 재계산 없는 재생(⑤), 옛 계획 행은 행 id 유지(planPrepare ③), writeSource: display 는 컴파일 fixture + validator 거부
[x] 입력 오류는 구별 가능한 결과로 반환하고 durable 적재 실패와 구분한다. — SavePreparationError 5종 vs OutboxEnqueueError(컴파일 fixture ②, 용량 초과 대조 ③)

범위·호환 주의: 기존 persisted 요청의 hash를 새 helper로 재발급하지 않는다. — 지켰다(§3 규칙, 재생 테스트).

S04

전송 중 요청 보호·탭별 claim과 후속 명령 보존

실행 이슈: Merged · PR #1369 · f8334135 · Production 포함·운영/실기기 인계 별도 · #1334 · [리팩터링 2-2]. 이슈 본문에 선택 필독·상세 작업·검증·직접 선행과 후속 인계를 포함한다.

분야 / Phase: DURABLE / 2
우선순위: P0
직접 선행: S02
책임 역할: durable queue 담당
보고서 연결: F01, F16, F17
추가 범위: —
소유 경계: src/react/persistence/outbox/**, src/react/services/pendingWorkoutSaves.ts

의미: 전송 중 편집과 늦은 ACK가 최신 사용자 의도를 삭제하지 못하게 한다.

산출물

per-mutation CAS claim·expiry·fencing token, immutable sending payload
sending create/update/delete/plan의 durable successor와 predecessor receipt 재확인

완료 증거

[ ] 새 버전 두 탭의 동시 claim·탭 종료·lease 만료·늦은 ACK에서 새 요청이 삭제되거나 옛 요청이 부활하지 않는다.
[ ] 응답 미상의 선행 요청은 같은 ID로 확정한 뒤 후속을 전송한다.
[ ] owner가 바뀐 후 이전 ACK가 현재 owner 상태에 적용되지 않는다.

범위·호환 주의: 전역 리더 선출은 도입하지 않는다. 구형 탭은 lease를 준수한다는 보장 대상이 아니며 S01 호환 경계를 따른다.

S05

Outbox·Dispatcher·ReceiptReconciler 책임 분리

실행 이슈: Merged · PR #1374 · 73d6f84b · Production 포함·운영/실기기 인계 별도 · #1336 · [리팩터링 2-3]. 이슈 본문에 선택 필독·상세 작업·검증·직접 선행과 후속 인계를 포함한다.

분야 / Phase: DURABLE / 2
우선순위: P1
직접 선행: S03, S04, D02
책임 역할: 저장 흐름 통합 담당
보고서 연결: F16
추가 범위: —
소유 경계: src/react/controllers/pendingWorkoutSavesStore.ts, src/react/services/pendingWorkoutMutationFlush.ts, src/react/persistence/dispatch/**

의미: 저장 모듈이 여러 화면의 cache·toast·editor callback을 직접 조율하지 않게 한다.

산출물

durable row만 전송하는 dispatcher, receipt identity/version validator
committed/deferred/held/blocked typed 결과와 feature invalidation port

완료 증거

[ ] 온라인·오프라인·재시도는 같은 sender를 통과하며 retry 정책의 소유자가 명확하다.
[ ] persistence가 calendar/profile/toast 구현을 import하지 않는다.
[ ] 같은 receipt가 중복 cache 반영·추가 알림을 만들지 않고 ownDataReplica는 서버 조회 응답으로만 채운다.

범위·호환 주의: 17개 callback을 이름만 바꾼 전역 event bus로 옮기지 않는다.

S06

충돌 재전송 요청과 복구 근거의 원자적 영속화

실행 이슈: Merged · PR #1385 · 1ebfda64 · Production 포함·운영/실기기 인계 별도 · #1341 · [리팩터링 2-4]. 이슈 본문에 선택 필독·상세 작업·검증·직접 선행과 후속 인계를 포함한다.

분야 / Phase: DURABLE / 2
우선순위: P0
직접 선행: S05
책임 역할: 충돌 동기화 담당
보고서 연결: F07, F07b
추가 범위: —
소유 경계: src/react/persistence/conflict/**, src/react/services/pendingWorkoutMutationFlush.ts, supabase/definitions/recovery/**

의미: 충돌 후 서버가 저장했는데 답장이 유실돼도 같은 작업을 새 ID로 다시 수행하지 않게 한다.

산출물

원래 요청→충돌→새 revision/ID 요청을 durable successor로 먼저 저장
local/base/remote snapshot 또는 immutable history reference와 실제 가용성 기록

완료 증거

[ ] conflict→durable commit→server commit→응답 유실→재시작에서 동일한 새 ID/hash로 receipt를 재생한다.
[ ] rebase 저장 실패 때 원래 요청이 남고 미저장 요청은 전송되지 않는다.
[ ] 기본 나중 도착 요청 우선·무음 동작은 유지하며 actual_revision만 받은 경우 remote 내용을 발명하지 않는다.

범위·호환 주의: 자동 필드 merge로 제품 정책을 바꾸지 않는다. 사본을 얻을 수 없는 경우 그 한계를 명시하고 완전 복구로 표시하지 않는다.

S07

Owner index·bounded mirror·IDB timeout 구현

실행 이슈: Merged · PR #1377 · 37066827 · Production 포함·운영/실기기 인계 별도 · #1337 · [리팩터링 2-3]. 이슈 본문에 선택 필독·상세 작업·검증·직접 선행과 후속 인계를 포함한다.

분야 / Phase: DURABLE / 2
우선순위: P1
직접 선행: S04
책임 역할: durable queue 담당
보고서 연결: F17
추가 범위: C06
소유 경계: src/react/services/workoutLocalCacheDb.ts, src/react/persistence/outbox/**, src/react/persistence/mirror/**

의미: 실패로 큐가 쌓여도 전체 사용자 payload 반복 조회·직렬화 비용이 폭증하지 않게 한다.

산출물

owner/target/state/time index와 cursor batch, payload/attempt metadata 분리
generation·ACK/delete tombstone이 있는 mirror 복구와 timeout/abort 공통 adapter

완료 증거

[ ] 1/100/1000개 payload drain에서 전체 rewrite가 O(N²)로 늘지 않는 계측을 낸다.
[ ] old/new mirror·primary 일부 실패·ACK 조합에서 이미 처리된 요청을 잘못 재활성화하지 않는다.
[ ] unknown/ambiguous recovery는 원문 보존·receipt 확인으로 처리하고 mirror만으로 없어진 최신 ACK 여부를 알 수 있다고 가정하지 않는다.

범위·호환 주의: IndexedDB 전체 삭제나 기존 queue 재생성으로 upgrade 문제를 해결하지 않는다. mirror는 장치 전체 삭제에 대한 백업 보장이 아니다.

S08

Draft lifecycle·Clock·checkpoint 순서 정리

실행 이슈: Merged · PR #1350 · 06db380c · Production 포함·운영/실기기 인계 별도 · #1326 · [리팩터링 2-1]. 이슈 본문에 선택 필독·상세 작업·검증·직접 선행과 후속 인계를 포함한다.

분야 / Phase: DURABLE / 2
우선순위: P1
직접 선행: S01, G02
책임 역할: 초안 담당
보고서 연결: F11, F14, F26
추가 범위: C06
소유 경계: src/react/controllers/workoutDraftStore.ts, src/react/services/workoutDraftCache.ts, src/react/services/workoutDraftCheckpoint.ts

의미: 초안 보존과 복원이 owner·operation·앱 종료 순서에 따라 엇갈리지 않게 한다.

산출물

typed owner/operation/phase lifecycle과 autosave/archive/clear coordinator
이전 operation의 늦은 checkpoint upload를 막는 ordering/fence와 Clock

완료 증거

[ ] owner 전환·restore 중 새 운동·pagehide·clear 뒤 늦은 upload·TTL 경계를 검증한다.
[ ] active/archive 7일·archive 최대 5개·checkpoint 3일/owner 하나의 정책을 유지한다.
[ ] 미전송 mutation의 유일한 근거를 draft TTL 때문에 삭제하지 않는다.

범위·호환 주의: 다중 활성 초안·공동 편집·새 local-first DB로 제품 범위를 확장하지 않는다.

S09

Conflict 사본 조회와 명시적 복구 command

실행 이슈: Planned · 게시·미착수 · #1409 · [리팩터링 3-2] · v0.18.0 · PR base release/v0.18.0. 이슈의 자기 맥락·선택 필독·상세 작업·행동 검증·직접 선행 링크·후속 인계로 시작한다. 게시를 Ready·구현·검증·배포 완료로 집계하지 않는다.

분야 / Phase: DURABLE / 3
우선순위: P1
직접 선행: S06, S10
책임 역할: 복구 기능 담당
보고서 연결: F07
추가 범위: —
소유 경계: src/react/features/recovery/**, src/react/contracts/**, src/react/persistence/conflict/**

의미: 자동 충돌 처리를 유지하면서 덮인 값을 확인하고 명시적으로 되돌릴 수 있게 한다.

산출물

복구 출처·가용 범위·현재 revision이 있는 RecoveryDescriptor
update undo와 full-family delete restore를 새 durable mutation으로 수행하는 command/props

완료 증거

[ ] 명시 undo 중 다른 수정이 발생하면 자동 LWW로 다시 덮지 않고 precondition을 재확인한다.
[ ] 같은 복구의 재시작·응답 유실은 동일 ID로 수렴한다.
[ ] 사본 없음·만료·권한 없음은 가능한 복구 범위를 정확히 표시하며 기존 삭제 직후 취소 toast는 추가하지 않는다.

범위·호환 주의: 삭제 receipt/tombstone을 지우거나 새 sourceRef create로 restore 검사를 우회하지 않는다.

S10

Update·삭제·자식 전체·인입의 범위 지정 복구 엔진

실행 이슈: Planned · 게시·미착수 · #1402 · [리팩터링 3-1] · v0.18.0 · PR base release/v0.18.0. 이슈의 자기 맥락·선택 필독·상세 작업·행동 검증·직접 선행 링크·후속 인계로 시작한다. 게시를 Ready·구현·검증·배포 완료로 집계하지 않는다.

분야 / Phase: DURABLE / 3
우선순위: P1
직접 선행: S01, D02, D03
책임 역할: 복구 DB 담당
보고서 연결: F07, F28
추가 범위: C07
소유 경계: supabase/definitions/recovery/**, supabase/contracts/user-fact-columns.json, scripts/data-copy/**

의미: 행 이력과 보존 원문을 실제로 복구 가능한 도구로 연결한다.

산출물

owner/entity/field 범위 dry-run plan·hash/revision 검증·원자 apply와 immutable restore receipt
session→exercise→part 및 set→part 전체 가족·부분 child·복합키 복구; 인입 source replay 경계

완료 증거

[ ] scalar/array/JSON/null·전체 삭제·일부 child·같은 요청 2회·중간 실패 rollback·동시 수정·타 owner 거부를 실제 DB에서 검증한다.
[ ] 기존 ID/source identity를 보존하고 관련 dirty 범위만 enqueue하며 정상적인 다른 최신 데이터를 덮지 않는다.
[ ] 인입은 가용 원본과 source_ref로 재생하고 직접 입력 source·삭제된 계정을 부활시키지 않는다.

범위·호환 주의: 일반 사용자 undo와 관리자 ticket 권한을 구분한다. 이 issue는 도구 구현이며 운영 데이터 복구 실행을 포함하지 않는다.

S11

데이터 사본 completeness·checksum·복구 manifest

실행 이슈: Planned · 게시·미착수 · #1410 · [리팩터링 3-2] · v0.18.0 · PR base release/v0.18.0. 이슈의 자기 맥락·선택 필독·상세 작업·행동 검증·직접 선행 링크·후속 인계로 시작한다. 게시를 Ready·구현·검증·배포 완료로 집계하지 않는다.

분야 / Phase: DURABLE / 3
우선순위: P1
직접 선행: S10, G04
책임 역할: 복구 운영 도구 담당
보고서 연결: F28, F29
추가 범위: —
소유 경계: .github/workflows/user-data-copy.yml, scripts/data-copy/**, docs/process/rollback.md

의미: 백업 job 성공과 실제 복구 가능한 사본 존재를 구분한다.

산출물

schema/migration head·table/key/column coverage·counts/hash·family dependency·raw/receipt/tombstone 가용성 manifest
구형 schema 사본을 격리 복원 후 현재 schema 대상 scoped recovery plan으로 변환하는 도구
유효 사본 신선도·실패·누락 경보와 복구 범위 보고

완료 증거

[ ] 누락 테이블/원문·checksum 변조·schema mismatch를 apply 전에 탐지한다.
[ ] 일 1회·90일·PITR 미사용 정책을 유지하며 사본에 없는 내용을 백업됐다고 표시하지 않는다.
[ ] 원문이 없으면 가용 범위와 복구 불가 구간을 명시하고 RPO는 마지막 유효 사본, RTO는 실제 훈련으로 계산한다.

범위·호환 주의: 비용 증가·보존기간 연장·개인정보 파기 정책 변경을 암묵적으로 포함하지 않는다.

D01

통계 계산 DAG·단일 작성자·동치 검증 계약

실행 이슈: Staging verified · #1286 · PR #1319 · c58c6522 · 기록. 종료 보완과 검증의 범위는 Phase 1 종료 기록에 정리한다.

분야 / Phase: DATA / 1
우선순위: P0
직접 선행: G02, G03
책임 역할: 통계 계약 담당
보고서 연결: F02, F03, F04, F05, F06, F27
추가 범위: —
소유 경계: docs/contracts/stats-projection*, tests/db/**, supabase/contracts/**

의미: 계산 담당자들이 중간 결과를 서로 보정하지 않고 합의된 입력·출력으로 협업하게 한다.

산출물

observation→session→순차 파생→기간/달력→snapshot→publication DAG와 테이블/컬럼별 작성자
정책 버전·반올림·null/0·순서/tie-break 및 generation/snapshot 계약
1/4/10년·과거 수정/삭제·날짜 이동·종목 교체·복합세트·체중·manual PR fixture와 기존 전체 결과 기준. history-1y/4y/10y 기준 파일은 종료 보완에서 고정 입력의 별도 새 owner 재적재까지 검증했다.

완료 증거

[x] 전체 계산 결과가 논리 키 기준 결정적이며 비교 제외 운영 필드가 명시된다.
[x] 같은 projection의 최종 작성자는 한 주체로 계약에 배정했다. 현행 중복 작성자 이식은 D04–D11의 후속 구현이다.
[x] 독립 고정 corpus·정책 불변식·full/incremental 비교 절차를 확정하고 현행 full 결과를 검증했다. 새 incremental 구현과의 실제 비교는 해당 후속 PR에서 실행한다.

범위·호환 주의: 리팩터링 과정에서 e1RM·PR·볼륨·출석·세트 score 정책 숫자를 바꾸지 않는다.

D02

동시 저장 generation 경합 재현과 영수증 세대 원자화

실행 이슈: Merged · PR #1352 · 7db92fb5 · Production 포함·운영/실기기 인계 별도 · #1327 · [리팩터링 2-1]. 이슈 본문에 선택 필독·상세 작업·검증·직접 선행과 후속 인계를 포함한다.

분야 / Phase: DATA / 2
우선순위: P0
직접 선행: D01, D03, D13
책임 역할: 서버 command 담당
보고서 연결: F02
추가 범위: C03
소유 경계: supabase/definitions/workout/**, tests/db/**

의미: 사용자 전체 버전의 잠금 없는 전후 차이 때문에 독립된 저장 요청이 실패하는 구조를 제거한다.

Phase 1에서 확정한 재현(2026-09-07): 4년 workload 적재 중 정각 cron enqueue와 저장이 겹쳐 1건이 +1 단언으로 거절됐다. fixture trigger를 쓰지 않은 2연결 재현에서도 동일 실패와 해당 저장의 rollback을 확인했다. 종료 보완 기록의 prior=N → 별도 enqueue N+1 → 자기 enqueue N+2 순서를 첫 회귀 검사로 사용한다. D01의 cron 격리는 테스트 입력 제어이며 이 제품 결함의 해결이 아니다.

산출물

실제 두 DB 연결 barrier로 다른 세션·동일 세션·planned/completed 경합 재현
enqueue가 자기 mutation에 배정한 generation을 반환하고 receipt에 기록하는 계약

완료 증거

[ ] 다른 세션 두 저장은 각각 원본/자식/receipt 하나로 성공하고 같은 세션 동일 revision 충돌은 유지된다.
[ ] planned 쓰기는 기존대로 통계 dirty를 만들지 않고 동일 ID 다른 payload 거부와 멱등 재생을 유지한다.
[ ] canonical+receipt+dirty 부분 commit이 없다. 예상 경합이 재현되지 않으면 실제 직렬화 근거로 해결 여부를 판정하고 불필요한 변경을 만들지 않는다.

범위·호환 주의: 통계 worker의 무거운 사용자 잠금을 저장 경로 전체에 추가하는 것을 최종 해법으로 삼지 않는다.

D03

SQL 도메인 원천·migration 생성·drift gate

실행 이슈: Staging verified · #1283 · PR #1312 · 16b8e996 · 기록. 종료 보완과 검증의 범위는 Phase 1 종료 기록에 정리한다.

분야 / Phase: DATA / 1
우선순위: P1
직접 선행: G01, G02
책임 역할: SQL 기반 담당 + HQ 통합
보고서 연결: F24, F25
추가 범위: C02, C03
소유 경계: supabase/definitions/**, scripts/**, supabase/migrations/**, supabase/schema.sql

의미: 현재 SQL 정의를 도메인별로 읽고 수정하되 적용 이력을 훼손하지 않는 작업 체계를 만든다.

산출물

qualified signature 기준 원천 registry와 dependency manifest
새 함수 정의 변경의 결정적 migration candidate 생성·replay snapshot·drift 검사
door→engine→policy/projection 호출 방향과 security/search_path/grant 검증

완료 증거

[x] 최초 원천 추출은 동작·권한·RLS·함수 설정이 현재와 동일하다.
[x] 원천→새 migration→빈 DB replay→snapshot을 두 번 실행해 같은 결과를 얻는다.
[x] 이미 적용한 migration은 불변이고 DDL/backfill은 generator가 추측하지 않는 명시 단계이며, 담당자가 최신 main 기준으로 landing 요청 전 번호를 정리하고 자동 큐가 머지 직전 기준을 재확인한다(D8).
[x] D13은 migration 실행 도구·검증 절차를, 각 domain 담당은 SQL object를 소유한다. D12 모델 개선도 같은 registry와 생성/landing 경로를 사용한다.

범위·호환 주의: schema.sql 수동 병합·migration squash·운영 migration repair를 포함하지 않는다.

D04

Dirty event의 정확한 영향 범위·세대별 병합

실행 이슈: Planned · 게시·미착수 · #1403 · [리팩터링 3-1] · v0.18.0 · PR base release/v0.18.0. 이슈의 자기 맥락·선택 필독·상세 작업·행동 검증·직접 선행 링크·후속 인계로 시작한다. 게시를 Ready·구현·검증·배포 완료로 집계하지 않는다.

분야 / Phase: DATA / 3
우선순위: P1
직접 선행: D02, D12
책임 역할: 통계 queue 담당
보고서 연결: F03
추가 범위: C02
소유 경계: supabase/definitions/stats/queue/**, supabase/definitions/workout/**

의미: 미반영 작업이 남았다는 이유로 한 번의 수정을 전 종목 재계산으로 확대하지 않게 한다.

산출물

old/new session/date/exercise·metric family·full 원인이 있는 dirty scope
pending 합집합·processing 불변 scope·후속 세대·실패 범위 보존

완료 증거

[ ] 날짜 이동·종목 교체는 old/new 양쪽을 포함하고 삭제 잔재가 없다.
[ ] worker 처리 중 새 쓰기가 와도 이벤트가 유실되지 않고 failed 범위가 성공으로 숨겨지지 않는다.
[ ] 구형 scope는 추측으로 축소하지 않고 보수적 full/suffix로 변환한다.

범위·호환 주의: 알려진 scope가 없는 경우의 명시적 full refresh와 일반 저장을 구분한다.

D05

변경 세션 observation·기본 rollup 증분화

실행 이슈: Planned · 게시·미착수 · #1411 · [리팩터링 3-2] · v0.18.0 · PR base release/v0.18.0. 이슈의 자기 맥락·선택 필독·상세 작업·행동 검증·직접 선행 링크·후속 인계로 시작한다. 게시를 Ready·구현·검증·배포 완료로 집계하지 않는다.

분야 / Phase: DATA / 3
우선순위: P1
직접 선행: D04
책임 역할: 관측·세션 계산 담당
보고서 연결: F03, F04
추가 범위: —
소유 경계: supabase/definitions/stats/observations/**, supabase/definitions/stats/session/**

의미: 통계 모듈들이 같은 원시 세트를 반복 해석하지 않게 하고 새 세션 처리 비용을 변경 범위로 제한한다.

산출물

정규화된 set observation과 세션별 기본 rollup
변경 세션 upsert/delete 및 순수 정책 입력 DTO

완료 증거

[ ] 복합 종목/shared set/source identity와 fixture 결과가 기존 전체 계산과 같다.
[ ] 오늘 append에서 무관한 과거 관측·세션을 재작성하지 않는 읽기/쓰기 계측을 낸다.
[ ] canonical 사실은 수정하지 않고 shadow 계산 실패는 재시도 dirty로 남긴다.

범위·호환 주의: 최종 기간 테이블·PR 상태를 이 단계에서 직접 보강하지 않는다.

D06

기간·달력 projection의 단일 작성자와 bucket 갱신

실행 이슈: release 반영 완료 · 앱 #1518 / 5b16a162 · 운영 배포 전 · #1416 · [리팩터링 3-3] · 필드/영향 계약 · 검증 기록. 기준 a1d462a8, D05 #1506 포함. staging/Production 반영은 별도다.

분야 / Phase: DATA / 3
우선순위: P1
직접 선행: D05
책임 역할: 기간·달력 계산 담당
보고서 연결: F03, F04
추가 범위: —
소유 경계: supabase/definitions/stats/periods/**, supabase/definitions/stats/calendar/**

의미: base/main-reps/strength가 동일 행을 번갈아 재작성하는 순서 의존성을 없앤다.

산출물

최종 기간 row assembler/upsert와 additive/max/average별 dirty bucket 전략
순차 파생 결과가 바뀐 suffix의 날짜·bucket 영향 입력

완료 증거

[x] day/week/month/quarter/year·달력 DTO가 전체 기준과 일치한다.
[x] 같은 최종 row의 모든 값을 한 작성자가 완성하며 뒤 단계 보정 UPDATE가 없다.
[x] 기간 이동·최대값 삭제·동일일 다세션·복합세트에서 정확하고 반올림 평균의 재평균을 하지 않는다.

검증: 기존 full 대비 종목 39·훈련 20·달력 7행 차이 0, D06 DB 10/10, 각 표 계산 writer 1개, 실제 worker 미완료 입력 실패→재시도 수렴, 작은 append 계산 쓰기 123→11(운영 개선율 아님).

범위·호환 주의: D07과 입력 계약을 먼저 고정해 병렬 구현하되 파생값이 빠진 결과를 운영 발행하지 않는다.

D07

PR·e1RM·최대반복수 checkpoint와 suffix 재생

실행 이슈: release 반영 완료 · 앱 #1522 / e2833dee · 운영 배포 전 · #1417 · [리팩터링 3-3] · v0.18.0 · PR base release/v0.18.0. 검증 기록, 문서 PR #45. D05·D06 이후 U03·D10을 포함한 b62a358c와 통합하고 Precheck·Merge Check를 통과했다.

분야 / Phase: DATA / 3
우선순위: P1
직접 선행: D05
책임 역할: 순차 통계 담당
보고서 연결: F03, F04
추가 범위: —
소유 경계: supabase/definitions/stats/pr/**, supabase/definitions/stats/strength/**

의미: 과거 수정의 실제 이후 영향을 반영하면서 매번 무관한 과거 앞부분을 다시 읽지 않게 한다.

산출물

policy/source boundary/generation 버전 checkpoint와 earliest affected 이후 replay
PR provenance·추정 state·set score 파생 observation과 기간 영향 출력

완료 증거 — 체크포인트 계약 · 동치·비용·발행 검증 기록

[x] 동일일 순서·과거 삭제·manual baseline·날짜 이동·실패 세트에서 정책 결과가 같다.
[x] 최신 append는 전체 raw prefix scan에 의존하지 않고 checkpoint 부재/불일치 때 검증된 full 계산을 수행한다.
[x] 조기 중단은 결과 동일성을 입증한 경우만 적용하고 applied generation을 부분 갱신하지 않는다.

범위·호환 주의: 이 단계가 기간 테이블의 두 번째 작성자가 되지 않는다. 정책 변경으로 parity 차이를 정당화하지 않는다.

D08

사용자별 stats worker·lease·실패 복구

실행 이슈: release/v0.18.0 통합 a1d462a8(2026-09-10) — 기록, staging·Production 미반영 · #1412 · [리팩터링 3-2] · v0.18.0 · PR base release/v0.18.0. 이슈의 자기 맥락·선택 필독·상세 작업·행동 검증·직접 선행 링크·후속 인계로 시작한다. 게시를 Ready·구현·검증·배포 완료로 집계하지 않는다.

분야 / Phase: DATA / 3
우선순위: P1
직접 선행: D04
책임 역할: 통계 worker 담당
보고서 연결: F05, F29
추가 범위: —
소유 경계: supabase/definitions/stats/workers/**, supabase/functions/**stats*

의미: 서로 다른 사용자의 작업과 잠금이 하나의 긴 batch transaction에 묶이지 않게 한다.

산출물

짧은 claim transaction→한 사용자 process transaction→ack/retry, 제한된 worker 동시성
lease token·heartbeat/expiry·fencing, process RPC의 transaction-local context 재설정

완료 증거

[ ] 느린 B 작업 때문에 완료된 A의 새 저장이 B batch 종료까지 기다리지 않는다.
[ ] claim 직후 종료·timeout·만료·옛 worker 재등장·ACK 유실에서 유실/중복 발행이 없다.
[ ] 같은 사용자의 원본/통계 일관성은 유지하고 현 scoped RPC의 상태·권한 호환도 유지한다.

범위·호환 주의: 전역 lock만 삭제하지 않는다. 긴 SQL 중 별도 heartbeat 불가 문제는 실제 RPC 실행/lease fence/timeout 설계로 검증한다.

D09

Wodup durable 소비자·lease 회수·완료 정합

실행 이슈: Planned · 게시·미착수 · #1404 · [리팩터링 3-1] · v0.18.0 · PR base release/v0.18.0. 이슈의 자기 맥락·선택 필독·상세 작업·행동 검증·직접 선행 링크·후속 인계로 시작한다. 게시를 Ready·구현·검증·배포 완료로 집계하지 않는다.

분야 / Phase: DATA / 3
우선순위: P1
직접 선행: D01, D03, D13
책임 역할: 인입 worker 담당
보고서 연결: F06
추가 범위: C03, C07
소유 경계: supabase/functions/wodup-start-import/**, supabase/functions/wodup-process-import-jobs/**, supabase/definitions/import/**

의미: 브라우저 요청이나 일회성 worker가 종료돼도 인입 작업이 자동으로 재개되게 한다.

산출물

due job scheduler·claim/lease/backoff·단계 cursor와 명시 실패 상태
canonical commit과 완료 상태의 원자 확정 또는 receipt reconcile
기존 normalizing/importing job의 안전 분류·재개 도구

완료 증거

[ ] dispatch 실패·staging 중 종료·canonical commit 직후 응답 유실·옛 worker 재등장에서 중복 없는 완료/명시 실패로 수렴한다.
[ ] 동일 batch 재개는 원본 삭제·새 인입 없이 가능하고 source_ref·원문 hash/owner가 유지된다.
[ ] 기존 lease 없는 job을 무조건 탈취하지 않으며 애매한 상태는 원본 보존·검토 대상으로 남긴다.

범위·호환 주의: 중단된 같은 job 복구와 새로운 사용자 재인입 허용 정책을 혼합하지 않는다.

D10

Repair·rollover 탐색의 index·cursor·watermark화

실행 이슈: v0.18.0 release 반영 완료 · #1418 · [리팩터링 3-3] · v0.18.0 · PR base release/v0.18.0. PR #1521 · b62a358c · D10 기록에 실제 검증·PR·환경별 반영 상태를 구분한다.

분야 / Phase: DATA / 3
우선순위: P2
직접 선행: D04, D08
책임 역할: 정기 유지 작업 담당
보고서 연결: F27
추가 범위: —
소유 경계: supabase/definitions/stats/maintenance/**, supabase/definitions/stats/scheduling/**

의미: 작은 LIMIT이 있어도 매번 전 사용자 이력을 집계하는 탐색 비용을 제한한다.

산출물

nextRefreshAt/due queue와 stable cursor/watermark 기반 repair sweep
catalog 변경·새 owner bootstrap·날짜 경계 rollover의 복구 가능한 탐색 상태

완료 증거

[x] EXPLAIN과 실제 실행에서 후보 discovery 자체가 page budget으로 제한된다.
[x] 중간 종료·재실행·다중 worker에서 누락·첫 페이지 반복·starvation이 없다.
[x] 손상 fixture를 순회 내 발견하고 inactive owner를 영구 제외하지 않는다.

범위·호환 주의: old/new 정기 scan을 동시에 무제한 실행하지 않는다.

D11

통계 계산 통합·동치 검증·generation publication 전환

실행 이슈: release/v0.18.0 반영 완료 · Production 미배포 · #1422 · 앱 PR #1547 · d058cbb7 · 검증·전환 기록. 이슈는 Production 성공 전까지 열어 둔다.

분야 / Phase: DATA / 3
우선순위: P1
직접 선행: D06, D07, D08, D09, D10, A06, G04
책임 역할: HQ + 데이터 통합 담당
보고서 연결: F03, F04, F05, F06, F24, F27
추가 범위: —
소유 경계: supabase/definitions/stats/orchestration/**, supabase/definitions/stats/publication/**, docs/process/**

의미: 분리된 모듈이 하나의 완전하고 정확한 통계 세대를 발행하는 최종 경로로 동작하게 한다.

산출물

observation→순차 파생→기간/달력→snapshot→publication의 단일 orchestration
같은 canonical snapshot의 full/incremental shadow 비교와 pending/failed job 이관
단일 사용자 worker+full 계산 검증 후 incremental로 전환하는 runbook과 호환 adapter

완료 증거

[x] fixture corpus의 수치·정책·PR 근거·외부 DTO 차이가 0이며 stale source를 최신 generation으로 publish할 수 없다.
[ ] 활성 production 계산은 projection별 단일 작성자를 사용하고 전체 rebuild도 같은 작성자를 full 범위로 구동한다. release 후보 구현·격리 DB 검증은 완료했으며 Production 적용은 R05/R06에서 확인한다.
[x] 구형 baseline 체인은 테스트 oracle로 격리하고 서버 공개 v5/조회 계약은 명시적 adapter로 유지한다. 알고리즘·DB 통합 시험을 통과한다.

범위·호환 주의: 새 원본 이중 쓰기나 사용자에게 보이는 shadow 결과를 만들지 않는다. 운영 cohort 전환은 R05/R06 배포 절차에서 검증한다.

2026-09-10 완료조건 구체화: D08의 기존 인계인 delta publish를 별도 신규 이슈로 나누지 않는다. 행의 계산 출처와 owner 공개 세대를 구분하고, 논리 키·의미 있는 필드(source_updated_at 포함)로 비교한 변경 공개 키만 I/U/D한다. 새 generation 값을 모든 행에 덮은 뒤 UPSERT하는 방식으로 전체 갱신을 되풀이하지 않는다. 출력 행과 applied generation은 원자적으로 공개하고 stale lease·새 dirty·삭제 경합·재시도와 full oracle 동치를 증명한다. D08 publish 예산 6초를 유지하고 D06의 내부 계산 DML 123→11을 최종 publisher 개선 수치로 재사용하지 않는다. 상세 절차·수용 기준. 기존 담당자 Phase·PR·직접 선행은 변경하지 않는다.

D12

전체 DB 모델·제약·index·대표 쿼리 품질 개선

실행 이슈: Closed · [v0.17.2 반영완료] · #1328 · PR #1358 · d1e77113 · [리팩터링 2-1]. 2026-09-08 사용자 결정으로 추가 대표 운영 seq_scan·저장 지연 측정을 생략하고 종료했다. D12 기록의 기존 샌드박스 실측과 운영 미측정 사실을 보존하며, 생략을 측정 성공·운영 효과 입증으로 표시하지 않는다. R04/R05 전체 성능·릴리스 검증과 다른 작업의 수락 조건은 유지한다.

분야 / Phase: DATA / 2
우선순위: P1
직접 선행: G05, G03, D03, D13
책임 역할: DB 모델·쿼리 담당
보고서 연결: F24, F27
추가 범위: C02
소유 경계: supabase/definitions/**, supabase/contracts/**, supabase/tests/**, docs/data/**

의미: 운동 통계 이외 도메인까지 논리·물리 데이터 구조와 조회 비용을 검증한다.

산출물

도메인별 ERD/object registry와 fact/projection/system 작성자·보존·삭제 정책표
PK/FK/unique/check/nullability/owner 연결·시간대/정밀도/단위 검토와 필요한 forward 변경
profile/social/group/catalog/identity/import/admin 포함 대표 조회의 index·정렬·페이지·중복 조회 실행계획과 필요한 개선

완료 증거

[ ] 실제 테이블·뷰·공개 RPC가 유지 근거 또는 수정·시험 증거에 연결되고 도메인 제약과 RLS/권한 시험이 통과한다.
[ ] 대표 데이터에서 쿼리의 읽기 범위·반복 호출을 확인하고 중복 index/JSON 이중 권위/불필요 trigger·wrapper는 실제 소비자에 근거해 정리한다.
[ ] 기존 ID·source·수치 정책을 유지한다. SQL object 수정 범위는 D03 registry로 배정하며 D02/D04 등 다른 소유 함수는 그 담당 이슈로 변경을 넘긴다.

범위·호환 주의: partition/sharding·전면 비정규화·테이블 재설계를 측정 근거 없이 도입하지 않는다. 전체 DB 경로가 허용 범위라는 이유로 타 담당 SQL을 병렬 수정하지 않는다.

D13

데이터가 있는 DB의 migration·잠금·backfill 안전성

실행 이슈: Staging verified · #1287 · PR #1318 · e970dd7d · 기록. 종료 보완과 검증의 범위는 Phase 1 종료 기록에 정리한다.

분야 / Phase: DATA / 1
우선순위: P0
직접 선행: G05, G02, D03
책임 역할: DB 이관 도구 담당 + HQ
보고서 연결: F24, F28
추가 범위: C03
소유 경계: scripts/migrations/**, docs/data/supabase-migration-strategy.md, supabase/tests/**

의미: 빈 DB replay와 실제 이전 버전 데이터의 업그레이드를 모두 검증하는 이관 절차를 만든다.

산출물

DDL/함수/index/constraint/backfill별 잠금·테이블 재작성·시간·WAL/디스크·재실행 위험 분류와 migration 증거 템플릿
지원 이전 릴리즈 데이터 fixture의 upgrade harness, 긴 backfill의 범위·cursor·checkpoint·재개 primitive
구/신 앱·worker 공존, 이관 중단·재실행·forward repair와 사실 불변 검증 절차

완료 증거

[x] 변경 유형별 대표 시나리오에서 빈 DB replay와 populated DB upgrade를 실행하고 중간 실패/재개 후 사실·ID·관계가 유지된다.
[x] 각 실제 migration PR이 위험 분류와 적용 시간/잠금·자원 예산을 제출하도록 기존 preflight/landing gate를 보강한다. 낮은 위험의 변경에 불필요한 backfill 프레임워크를 강제하지 않는다.
[x] D13 종료는 도구·대표 fixture 검증이다. 0.18.0 실제 migration 전체의 최신 데이터 upgrade 결과는 R05가 다시 요구한다.

범위·호환 주의: 운영 DB 직접 실험·이력 수정·무조건 무중단 보장을 포함하지 않는다. DDL/backfill 내용은 각 SQL object 담당이 소유한다.

D14

세션 원본의 변경 행만 저장

실행 이슈: D14 #1533 · [리팩터링 4-1] · v0.18.0 · PR base release/v0.18.0 · release 반영 완료 · 앱 PR #1551 · 576dae9b · 작업 기록. Production 미배포.

분야 / Phase: DATA / 4
우선순위: P1
직접 선행: D02, D04, S10, D11
책임 역할: 원본 저장 담당
보고서 연결: F02, F03, F29 / 2026-09-10 데이터 쓰기 효율 추가 결정
추가 범위: C02, C03
소유 경계: 앱 supabase/definitions/workout/functions/write_session_children_v5.sql 및 save_session_v5_engine.sql 최소 배선, 관련 저장·원본 보호·복원·경합 검사와 생성 migration/schema/registry. 문서 계약·장부는 Barbelic-docs 소유.

의미: 세션 메모만 바꿔도 종목·세트 자식이 반복 UPDATE되는 경로에서, 실제 값·순서가 달라진 행만 쓴다. 요청 전체 검증과 원본 관계 모델은 유지한다.

산출물

같은 트랜잭션에서 정규화된 typed 값·ID/소속을 확인하고 삽입·실제 변경·삭제·유지 집합을 계산하는 저장 경로
실제 순서 변경에만 위치 충돌 회피를 적용하고 정당한 정규화·파생 트리거 효과를 보존하는 배선
테이블별 DML·WAL·trigger·lock·save p95 전후 및 원본/receipt/generation·복원·경합 증거

작업절차: Phase 1 기준선·변경 판정 → Phase 2 변경 집합 저장 → Phase 3 순서·정규화·이력 → Phase 4 실패·경합·호환 → Phase 5 전후·populated upgrade·필수 precheck·Merge Check·release 병합. 상세 목표·범위·예상효과.

완료 증거

[x] 메모-only 및 같은 내용 새 논리 저장에서 자식 네 테이블 I/U/D가 모두 0이다. 새 revision·receipt·완료 저장 generation 규칙은 유지하며 같은 mutation 재전송은 기존 영수증을 재사용한다.
[x] 무게 한 칸·추가·삭제·재정렬의 정당한 영향 밖 자식 쓰기 0, 순서 불변의 위치 변경 쓰기 0을 실제 DB로 확인한다.
[x] owner·기대 revision·ID/소속 검사를 먼저 수행하며 입력의 null/누락·정밀도·출처·필수 이력·원본 보호·복원·파생 결과를 보존한다.
[x] 중간 실패는 자식·revision·receipt·dirty 전체를 롤백하고 실제 경합·복합·복원 직후 편집 회귀를 통과한다.
[x] 과거 사용자 원본을 migration으로 일괄 UPDATE/DELETE하지 않으며 같은 fixture의 비용과 정합 증거를 R01/R04/R05로 넘긴다.

범위·호환 주의: 모델 전면 개편·patch API·통계 enqueue 생략·트리거 비활성화·raw/history 삭제·새 범용 diff 프레임워크는 하지 않는다. 고정 fixture의 메모/동일 저장 UPDATE 21→0·무게 한 칸 21→1과 로컬 WAL/p95를 측정했고 Production 효과는 미측정이다. full payload 검증의 O(전체 입력) 비용을 변경행 수 비용으로 보고하지 않는다.

A01

공용 RPC transport와 거대 Repository 분리 경계 생성

실행 이슈: Staging verified · #1288 · PR #1316 · 947413d1 · 기록. 종료 보완과 검증의 범위는 Phase 1 종료 기록에 정리한다.

분야 / Phase: APP / 1
우선순위: P1
직접 선행: G02, G03
책임 역할: 데이터 접근 경계 담당
보고서 연결: F08, F12, F13
추가 범위: —
소유 경계: src/react/services/barbelicRepository.ts, src/react/services/barbelicApi.ts, src/react/services/rpcTransport*, src/react/services/domains/**

의미: 각 도메인 작업자가 같은 5천 줄 파일을 동시에 편집하지 않고 독립적으로 구현할 수 있게 한다.

산출물

timeout·인증·오류 정규화·진단만 갖는 작은 transport와 도메인별 목적지 파일
기존 공개 API와 새 port의 명시적 연결, 추출 순서와 공용 파일 소유권 목록
다중 retry를 구분한 transport/dispatcher 책임표

완료 증거

[x] transport가 운동·프로필·화면 캐시 정책을 알지 않는다.
[x] 이후 도메인 작업자는 자기 파일에 구현하고 마지막 공용 export 배선만 담당자가 병합한다.
[x] RPC 이름·요청·오류 의미가 기존 계약과 같으며 v5 실패를 구형 RPC로 돌리지 않는다.

범위·호환 주의: 큰 파일의 함수를 다른 파일에서 그대로 재수출하는 것만으로 완료하지 않는다.

A02

Workout·Plan repository와 canonical codec 분리

실행 이슈: Merged · Production 포함 · #1329 · PR #1354 · [리팩터링 2-1] · 기록 · 추출 지도 §3-1. 이슈 본문에 선택 필독·상세 작업·검증·직접 선행과 후속 인계를 포함한다. 실제 병합·배포 대조는 Phase 2 종료 기록을 따른다.

분야 / Phase: APP / 2
우선순위: P1
직접 선행: A01
책임 역할: 운동 데이터 접근 담당
보고서 연결: F08, F12, F13
추가 범위: —
소유 경계: src/react/services/domains/workout*, src/react/services/domains/plan*, src/react/features/workout/**, src/react/features/plan/**

의미: 핵심 기록 쓰기와 상세 읽기의 변환·검증을 해당 도메인에 모은다.

산출물

workoutRepository/planRepository, save/detail/receipt codec와 narrow port
기존 repository·mapper의 해당 구현 이동 및 내부 이중 필드 표현 제거

완료 증거

[x] row/detail/receipt/display의 쓰기 원천 자격을 타입과 validator로 구분한다. — sessionDetailCodec 이 WritableCopy(detail) 를 만들고 isWritableCompletedSessionCopy 가드 + 컴파일 fixture(sessionDetail·workoutPorts)
[x] 동일 ID·같은 단위·기존 v5 payload/receipt 동작이 유지된다. — workoutRepositoryDestination(10)·planRepositoryDestination(8)·sessionDetailCodec(4) 행동 테스트, 기존 v5/receipt/plan round-trip 테스트 유지
[x] 화면이 snake_case나 서버 자식행 형태를 해석하지 않는다. — 상세 codec 만 서버 키를 읽고(이중 읽기 41→0, dual-key 기준선 253→227) 화면·컨트롤러에 DB 행 해석 신설 0

범위·호환 주의: 진행 중 운동을 canonical 서버 세션으로 미리 생성하지 않는다.

A03

Catalog·Profile repository와 codec 분리

실행 이슈: Merged · PR #1351 · 530bb4cf · Production 포함·운영/실기기 인계 별도 · #1330 · [리팩터링 2-1]. 이슈 본문에 선택 필독·상세 작업·검증·직접 선행과 후속 인계를 포함한다.

분야 / Phase: APP / 2
우선순위: P1
직접 선행: A01
책임 역할: 카탈로그·프로필 담당
보고서 연결: F08, F12, F13
추가 범위: C05
소유 경계: src/react/services/domains/catalog*, src/react/services/domains/profile*, src/react/features/catalog/**, src/react/features/profile/**

의미: 종목 identity와 프로필 데이터 변환을 다른 기능의 휴리스틱에서 분리한다.

산출물

catalogRepository/profileRepository, canonical ID와 별도 alias 해석 경계
프로필 입력·응답 typed DTO와 owner 규칙

완료 증거

[ ] 별칭 확정은 카탈로그/인입 경계에 있고 일반 화면은 ID로 접근한다.
[ ] nullable·누락·유효한 0이 codec에서 혼동되지 않는다.
[ ] 해당 구현이 거대 Repository/mapper에 중복 남지 않는다.
[ ] 온보딩·신체 데이터·프로필의 날짜/단위/validation 계약과 실제 API 경로를 G05 목록에 대응하며 계정 생애주기 구현은 B01과 중복하지 않는다.

범위·호환 주의: 기존 종목 ID를 이름 기반으로 재발급하지 않는다.

A04

Social·Group repository와 codec 분리

실행 이슈: Planned · 게시·미착수 · #1405 · [리팩터링 3-1] · v0.18.0 · PR base release/v0.18.0. 이슈의 자기 맥락·선택 필독·상세 작업·행동 검증·직접 선행 링크·후속 인계로 시작한다. 게시를 Ready·구현·검증·배포 완료로 집계하지 않는다.

분야 / Phase: APP / 3
우선순위: P1
직접 선행: A01
책임 역할: 소셜·그룹 담당
보고서 연결: F08, F12, F13
추가 범위: —
소유 경계: src/react/services/domains/social*, src/react/services/domains/group*, src/react/features/social/**, src/react/features/group/**

의미: 피드·관계·그룹 작업의 권한과 데이터 계약을 핵심 운동 구현과 분리한다.

산출물

socialRepository/groupRepository 및 페이지·오류·mutation 계약
owner별 읽기/쓰기 port와 DTO

완료 증거

[ ] 다른 owner의 캐시나 인증이 도메인 호출에 섞이지 않는다.
[ ] 페이지 커서·중복 방지·기존 그룹 계획/댓글/좋아요 의미를 유지한다.
[ ] 공통 transport 외에 workoutRepository 내부를 import하지 않는다.

범위·호환 주의: 댓글·좋아요 등 온라인 명령의 자동 재시도 정책을 임의로 확장하지 않는다.

A05

Import·Admin repository와 codec 분리

실행 이슈: Planned · 게시·미착수 · #1406 · [리팩터링 3-1] · v0.18.0 · PR base release/v0.18.0. 이슈의 자기 맥락·선택 필독·상세 작업·행동 검증·직접 선행 링크·후속 인계로 시작한다. 게시를 Ready·구현·검증·배포 완료로 집계하지 않는다.

분야 / Phase: APP / 3
우선순위: P1
직접 선행: A01
책임 역할: 인입·관리 도구 담당
보고서 연결: F08, F12, F13
추가 범위: C05, C07
소유 경계: src/react/services/domains/import*, src/react/services/domains/admin*, src/react/features/import/**, src/react/features/admin/**

의미: 무거운 인입·관리 접근이 일반 앱의 의존성과 초기 bundle을 끌고 다니지 않게 한다.

산출물

importRepository/adminRepository와 typed job status/error DTO
일반 화면용 최소 job 조회 port와 관리자 전용 경계

완료 증거

[ ] 사용자 화면이 raw table/admin client를 받지 않는다.
[ ] 인입 진행 상태가 서버 job 상태와 대응하고 추측으로 완료 표시하지 않는다.
[ ] 별도 관리자 배포 경로가 G01의 게이트를 따른다.
[ ] Wodup 외 Motra/InBody와 관리자/API 진입점을 G05 목록에 대응하고, parser·worker·서버 권한은 I01/D09/B01의 좁은 port로 소비한다.

범위·호환 주의: 일반 앱 번들에 service-role 권한이나 관리자 전용 구현을 포함하지 않는다.

A06

Stats·화면 RPC query와 codec 분리

실행 이슈: Planned · 게시·미착수 · #1407 · [리팩터링 3-1] · v0.18.0 · PR base release/v0.18.0. 이슈의 자기 맥락·선택 필독·상세 작업·행동 검증·직접 선행 링크·후속 인계로 시작한다. 게시를 Ready·구현·검증·배포 완료로 집계하지 않는다.

분야 / Phase: APP / 3
우선순위: P1
직접 선행: A01, D01
책임 역할: 통계 조회 담당
보고서 연결: F08, F12, F13
추가 범위: —
소유 경계: src/react/services/domains/stats*, src/react/services/screenRpcAdapters.ts, src/react/services/*ViewMappers*, src/react/features/calendar/**, src/react/features/pr/**

의미: 서버 통계 의미를 유지하며 화면별 읽기 계약과 presentation 변환의 책임을 분리한다.

산출물

Home/Calendar/PR/Volume/Session read query 모듈과 validated DTO
도메인 projection과 플랫폼 view mapper의 분리

완료 증거

[ ] 서버 generation·정책 버전·갱신 상태가 화면 DTO까지 전달된다.
[ ] 통계 부재를 클라이언트 추정 점수로 채우지 않는다.
[ ] raw 수년치 세트를 받아 화면에서 재계산하는 경로가 생기지 않는다.

범위·호환 주의: SQL projector의 업무 의미를 JS에 재구현하지 않는다.

A07

Owner·Auth·Connectivity lifecycle 분리

실행 이슈: Merged · PR #1365 · 0775e6b2 · Production 포함·운영/실기기 인계 별도 · #1335 · [리팩터링 2-2]. 이슈 본문에 선택 필독·상세 작업·검증·직접 선행과 후속 인계를 포함한다.

분야 / Phase: APP / 2
우선순위: P1
직접 선행: A01, B01
책임 역할: 앱 runtime 담당
보고서 연결: F09, F10, F11
추가 범위: C05
소유 경계: src/react/controllers/remoteDataController.ts, src/react/controllers/ownerStores.ts, src/react/app/**

의미: 계정·연결 수명주기가 각 feature의 cache reset 목록을 직접 관리하지 않게 한다.

산출물

AuthSessionRuntime/ConnectivityRuntime/OwnerRuntime과 owner 전환 계약
현재 owner를 떠날 때 draft flush·구독 정리·요청 취소·새 store 생성의 명시적 순서

완료 증거

[ ] A계정 요청의 늦은 응답이 B계정 화면·cache를 덮지 않는다.
[ ] 인증 만료·명시 로그아웃·계정 삭제의 서로 다른 보존 정책을 유지한다.
[ ] 데이터 조회 오류가 인증 실패처럼 표시되지 않는다.

범위·호환 주의: 기존 owner store 패턴을 전역 mutable singleton으로 되돌리지 않는다.

A08

Owner-scoped resource cache·typed snapshot primitive

실행 이슈: Merged · PR #1372 · 4fb2d26f · Production 포함·운영/실기기 인계 별도 · #1338 · [리팩터링 2-3]. 이슈 본문에 선택 필독·상세 작업·검증·직접 선행과 후속 인계를 포함한다.

분야 / Phase: APP / 2
우선순위: P1
직접 선행: A07
책임 역할: resource 기반 담당
보고서 연결: F09, F11
추가 범위: —
소유 경계: src/react/resources/**, src/react/controllers/remoteDataController.ts, src/react/runtimeGymData.ts

의미: 각 기능이 중복 구현하던 loaded flag·promise·abort·revision 관리를 하나의 작은 계약으로 통일한다.

산출물

owner/resource/id/range/version key, dedup·cancel·invalidate·stale generation 규칙
immutable ResourceSnapshot과 selector, 읽기 cache와 local write overlay의 분리

완료 증거

[ ] 공유 중인 요청은 한 소비자의 취소 때문에 다른 소비자가 깨지지 않고, owner epoch가 바뀐 응답은 채택하지 않는다.
[ ] mutable ref+dataTick 없이 snapshot reference 변경으로 구독자가 갱신된다.
[ ] 기존 coordinator 확장을 기본으로 하며 다른 query 도구 선택 시 G03 계약 충족 근거와 단일 구현만 남긴다.

범위·호환 주의: 서버 cache를 authoritative local DB 또는 outbox로 겸용하지 않는다.

A09

Workout·Plan·Catalog resource 이전과 첫 수직 통합

실행 이슈: Open · [v0.17.3 스테이징] · milestone v0.17.3 · #1342 · PR #1394 · ba3b77bf · [리팩터링 2-5]. 원 구현은 release/v0.17.3의 60c8a5746109c6e827e87b10547c1bc9fccd9302에 포함(원 구현 대비 behind 0)됐고 기존 staging은 성공했다. HQ의 별도 receipt/resource 종료 보완은 main 미반영·검증 중이며 이 원 구현의 staging 증거와 분리한다. Production 반영 완료로 표시하지 않는다.

분야 / Phase: APP / 2
우선순위: P1
직접 선행: A02, A03, A08, S06, D02
책임 역할: 운동 feature 통합 담당
보고서 연결: F09, F10, F11, F16
추가 범위: —
소유 경계: src/react/features/workout/**, src/react/features/plan/**, src/react/features/catalog/**, src/react/resources/**

의미: 저장→기기 보관→서버 receipt→무효화→재조회가 새 경계만으로 동작하는 첫 완성 경로를 만든다.

산출물

상세·계획·카탈로그 resource와 feature-local selectors/commands
온라인·오프라인 workout update 수직 시나리오와 receipt에 따른 최소 invalidation

완료 증거

[ ] 저장 정책을 UI·resource·dispatcher가 각각 판단하지 않는다.
[ ] 서버 상세의 권위와 pending overlay를 분리하고 receipt가 늦어도 편집을 잃지 않는다.
[ ] 이 경로가 통과한 뒤 나머지 화면의 resource 이전 패턴을 확정한다.

범위·호환 주의: renderCtx 전체 객체를 새 feature prop으로 포장하지 않는다.

A10

Home·Calendar·PR·Volume resource와 generation UX 이전

실행 이슈: Planned · 게시·미착수 · #1413 · [리팩터링 3-2] · v0.18.0 · PR base release/v0.18.0. 이슈의 자기 맥락·선택 필독·상세 작업·행동 검증·직접 선행 링크·후속 인계로 시작한다. 게시를 Ready·구현·검증·배포 완료로 집계하지 않는다.

분야 / Phase: APP / 3
우선순위: P1
직접 선행: A06, A09
책임 역할: 통계 feature 담당
보고서 연결: F09, F10, F11
추가 범위: —
소유 경계: src/react/features/home/**, src/react/features/calendar/**, src/react/features/pr/**, src/react/features/volume/**

의미: 통계 화면의 반복 cache orchestration을 제거하고 서버 발행 시점에 맞춰 일관되게 갱신한다.

산출물

기능별 resource keys·selector·refresh policy와 typed view model
loading/empty/stale/refreshing/error 상태 및 generation 대기 계약

완료 증거

[ ] 부분 통계 세대를 최신 완료 결과처럼 섞어 보여주지 않는다.
[ ] 한 기록 저장으로 관련 없는 모든 화면 cache를 초기화하지 않는다.
[ ] 기간 변경·뒤로가기·늦은 응답에서 이전 범위가 새 범위를 덮지 않는다.

범위·호환 주의: 통계를 즉시 보이게 하려고 로컬 추정치를 확정치로 섞지 않는다.

A11

Profile·Social·Group·Import resource 이전

실행 이슈: release/v0.18.0 반영완료 · Production 전 · PR #1516 · merge daca15d9 · #1419 · [리팩터링 3-3]. A11 기록에 6 Phase, precheck4분4초(3,509 pass/0 fail/60 조건부 skip), Merge Check 성공, 제거/잔존·G05/A16/R04 인계를 연결했다. 실제 Production·긴 이력 성능은 별도다.

분야 / Phase: APP / 3
우선순위: P1
직접 선행: A03, A04, A05, A09, I01
책임 역할: 주변 feature 담당
보고서 연결: F09, F10, F11
추가 범위: C07
소유 경계: src/react/features/profile/**, src/react/features/social/**, src/react/features/group/**, src/react/features/import/**

의미: remoteDataController가 나머지 기능 상태까지 계속 소유하는 것을 끝낸다.

산출물

feature별 resource·selector·command binding과 import 상태 구독
feed pagination 및 프로필·그룹 invalidation 계약

완료 증거

[x] 같은 키 공유 조회·화면 이탈·계정 전환·반복 조립/dispose의 단위 행동 증거를 확인했다(실제 Production 재접속은 미검증).
[x] 업로드 원문과 화면 상태의 저장·보존 책임이 구분된다.
[x] 거대 controller의 해당 ref/map/flag 구현을 제거하고 호환 props 투영의 잔존 담당을 적었다.

범위·호환 주의: 최종 wiring 외에 다른 작업자의 feature 내부를 함께 수정하지 않는다.

A12

플랫폼 공통 Workout headless editor

실행 이슈: Merged · PR #1378 · 1514fc52 · Production 포함·운영/실기기 인계 별도 · #1339 · [리팩터링 2-3]. 이슈 본문에 선택 필독·상세 작업·검증·직접 선행과 후속 인계를 포함한다.

분야 / Phase: APP / 2
우선순위: P1
직접 선행: A02, A03, S03
책임 역할: 운동 편집 모델 담당
보고서 연결: F12, F13, F14, F15
추가 범위: —
소유 경계: src/react/features/workout/editor/**, src/react/ui/shared/workout*, src/react/contracts/**

의미: 모바일과 데스크톱에서 입력 검증·완료 판정·복합 운동 해석이 달라지는 원인을 없앤다.

산출물

pure reducer/상태 union, numeric input 모델, validation·row command·save preparation port
view model 및 플랫폼 무관 editor 계약 시험

완료 증거

[ ] 빈 문자열·0·unknown·invalid, IME 조합 중 입력, 단위 전환의 의미가 유지된다.
[ ] 복합 운동·공통 세트·미수행 세트 삭제·진행 중 초안 정책이 양 플랫폼에서 같은 결과를 낸다.
[ ] editor가 React DOM·네트워크·IDB·화면 CSS를 직접 참조하지 않는다.

범위·호환 주의: UI 이벤트 핸들러를 이름만 바꾸어 거대한 headless 파일 하나로 옮기지 않는다.

A13

플랫폼 공통 Plan headless editor

실행 이슈: Merged · Production 포함 · #1340 · [리팩터링 2-3] · 기록 · 계약 plan-editor-model.md. 이슈 본문에 선택 필독·상세 작업·검증·직접 선행과 후속 인계를 포함한다. 실제 병합·배포 대조는 Phase 2 종료 기록을 따른다.

분야 / Phase: APP / 2
우선순위: P1
직접 선행: A02, A03, S03
책임 역할: 계획 편집 모델 담당
보고서 연결: F12, F13, F14, F15
추가 범위: —
소유 경계: src/react/features/plan/editor/**, src/react/ui/desktop/screens/DesktopPlanEditorModel.ts, src/react/contracts/**

의미: 계획 편집의 카탈로그 판단·입력 검증·저장 준비를 표현 계층에서 독립시킨다.

산출물

PlanEditorModel·pure validation·typed view model
워크아웃과 의미가 같은 작은 policy만 공유하는 명시적 공통 모듈

완료 증거

[ ] 플랫폼별 같은 입력 sequence가 같은 prepared plan과 validation 결과를 만든다.
[ ] 계획과 완료 기록의 서로 다른 ID·저장 정책을 억지로 같은 상태 머신에 넣지 않는다.
[ ] 기존 DesktopPlanEditorModel의 업무 판단이 view adapter에 중복 남지 않는다.

범위·호환 주의: 도메인 차이를 수십 개 boolean 옵션으로 감춘 범용 editor 엔진을 만들지 않는다.

A14

Canonical ID 기반 종목 이력 조회와 indexed merge

실행 이슈: release/v0.18.0 통합 완료(209bbffd, 2026-09-10) · staging 승격 대기 · #1414 · [리팩터링 3-2] · v0.18.0 · PR base release/v0.18.0 · 앱 PR #1503(Phase 1 099f3e0f · Phase 2 6edd7bc8 · Phase 3 19458bd8) · 기록. release 통합·staging·Production 상태는 기록 §5 상태 표.

분야 / Phase: APP / 3
우선순위: P1
직접 선행: A02, A03, A06, A09
책임 역할: 운동 이력 담당
보고서 연결: F18, F19
추가 범위: —
소유 경계: src/react/features/workout/history/**, src/react/contracts/ports/exerciseHistoryDto.ts, src/react/services/domains/codecs/exerciseHistoryCodec.ts, src/react/services/mobileFeedViewMappers.ts(피드 카드 전용으로 축소), src/react/ui/shared/workoutCalculations.ts(표시 도우미만), supabase/definitions/pr/functions/get_exercise_pr_history_v3_core.sql(세트 원자·기록 칸, 추가 전용) — supabase/definitions/queries/** 는 새 SQL 이 필요 없어 만들지 않았다

의미: 이력의 정확도와 비용이 운동 이름이나 사용자가 방문한 피드 범위에 의존하지 않게 한다.

산출물

exercise ID·owner·cursor 기반 history resource/RPC 계약 — 기존 get_exercise_pr_history 재사용(세트 원자 4종·recording_fields 추가 전용, v4 유지), typed 계약 contracts/ports/exerciseHistoryDto.ts, resource features/workout/history/exerciseHistoryResource.ts
session/exercise ID Map 기반 merge(exerciseHistoryMerge.ts)와 범위·페이지 완전성 메타데이터(hasMore·exhausted·setsTruncatedRows·연도 창 exerciseHistoryWindow.ts), 화면 port(read/open/loadMore/close)

완료 증거

[x] 유사 이름·이름 변경·복합 운동·중복 페이지에서도 다른 종목 이력이 섞이지 않는다 — tests/react/exerciseHistoryFeature.test.mjs(다른 종목 페이지는 오류, 식별자 없는 행은 unresolved)·exerciseHistoryDrawer.test.mjs.
[x] 피드를 열기 전후 이력의 동일 범위 결과가 같다 — 캐시 키 (owner·종목·연도·커서·크기·기준일), exerciseHistoryBinding.test.mjs 재열기 서버 호출 0. 피드 창·세션 검색 재활용 경로(buildMobileExerciseHistory·ensureSessionSearch 배선)는 삭제.
[x] merge가 행마다 전체 배열 find를 반복하지 않고 서버 쿼리는 실제 계획으로 index/limit 적용을 확인한다 — Map 색인(1/4/10년 fixture 행당 0.58→0.49µs, exerciseHistoryMergeThroughput.test.mjs), EXPLAIN core Index Scan user_exercise_session_rollups_detail_cursor_idx limit+1(10년 실데이터 18~75ms, 기록 §4·§5). 문(v4) 근력 지표 부착 3.6초는 세트 스코어·DB 담당 인계(기록 §4 "작업 중 드러난 것").

범위·호환 주의: 모든 이력을 초기 로딩하거나 이름 fallback을 내부에 남기지 않는다. SQL 변경은 DB 통합자가 반영한다. (실측: 세트 원자 보강은 함수 재발행 1건이라 이 트랙이 마이그레이션까지 반영했다.)

A15

Feature binding 통합과 얇은 app shell 완성

실행 이슈: A15 #1531 · [리팩터링 4-1] · v0.18.0 · PR base release/v0.18.0 · release/v0.18.0 반영완료 · 앱 PR #1550 · merge 290eadb9 · precheck 3,579 pass/0 fail/88 조건부 skip·Merge Check 성공·Production 전. 상세 목표·작업절차·예상효과·검증·선행 인계는 이슈 본문과 Phase 4 계획을 따른다.

분야 / Phase: APP / 4
우선순위: P2
직접 선행: A10, A11, A12, A13, A14, U02, U03
책임 역할: 앱 통합 담당
보고서 연결: F10, F11
추가 범위: —
소유 경계: src/react/appController.tsx, src/react/mobileApp.tsx, src/react/desktopApp.tsx, src/react/app/**, src/react/features/**/binding*

의미: 기능 추가가 appController와 모든 플랫폼 root의 동시 수정을 요구하는 구조를 끝낸다.

산출물

owner/auth/connectivity·route/overlay host·feature 조립만 담당하는 shell
각 feature의 좁은 binding과 typed props; 기존 197-field context 경로 제거

완료 증거

[x] shell이 운동 검증·통계 계산·기능 cache reset을 수행하지 않는다.
[x] 197개 필드를 다른 mega-context로 옮기거나 여러 중첩 객체 아래 그대로 유지하지 않는다.
[x] 한 feature의 일반 데이터/화면 변경을 shell 변경 없이 할 수 있는 실제 예시를 검증한다.

범위·호환 주의: 전역 event bus 또는 service locator로 의존성을 감추지 않는다.

실제 책임·검증·후속 인계는 A15 기록과 feature 계약 §10에 연결한다.

A16

잔여 any·dual shape·거대 mapper 제거 완료

실행 이슈: A16 #1534 · [리팩터링 4-2] · v0.18.0 · PR base release/v0.18.0 · release 반영 완료 · PR1561 · 517c538e · A16 기록 (문서 PR66·Production 상태는 기록에서 별도 구분). 상세 목표·작업절차·예상효과·검증·선행 인계는 이슈 본문과 Phase 4 계획을 따른다.

분야 / Phase: APP / 4
우선순위: P2
직접 선행: A15, S09, S11
책임 역할: 타입 경계 통합 담당
보고서 연결: F08, F09, F11, F12, F13
추가 범위: —
소유 경계: src/react/types/**, src/react/services/barbelicMappers.ts, src/react/services/barbelicViewMappers.ts, src/react/controllers/remoteDataController.ts, dual-key-baseline.json

의미: 새 모듈 옆에 구형 범용 구조를 계속 남기는 부분 이식을 방지한다.

산출물

활성 앱 도메인별 any·이중 필드 baseline 소진과 legacy decoder 격리
거대 Repository/remote controller/mapper의 잔여 책임 이전 및 빈 compatibility facade 제거

완료 증거

[x] 활성 앱의 광범위 AnyRecord/MobileProps와 내부 camel/snake 이중 해석이 제거된다.
[x] 외부 JSON용 unknown·정당한 generic·버전별 구형 decoder는 명시된 경계에만 존재하며 unchecked cast나 suppression으로 수치만 줄이지 않는다.
[x] 모든 기존 소비자가 새 경계를 사용하고 이전 구현에 남은 import가 없다.

범위·호환 주의: 적용된 migration·구형 사용자 데이터 decoder·명시적 서버 호환 계약까지 일괄 삭제하지 않는다.

최종 precheck는 8분33초 전체 통과(단위3,616/0/92, pgTAP143파일/2,825assert) 후 정상 Merge Check로 release에 반영했다. 소유 경계·보존14항목을 R01/G05에 인계한다. Production 배포·이슈 종결은 별도다.

U01

공통 시각 token·primitive·접근성 계약

실행 이슈: Staging verified · #1289 · PR #1317 · 45e58c33 · 기록. 종료 보완과 검증의 범위는 Phase 1 종료 기록에 정리한다.

분야 / Phase: UI / 1
우선순위: P1
직접 선행: G03
책임 역할: 디자인 담당
보고서 연결: F22
추가 범위: C04
소유 경계: src/react/ui/shared/**, src/react/contracts/*props*, docs/contracts/**

의미: 표현을 플랫폼별로 유지하면서 색·간격·입력·dialog 동작의 일관성을 확보한다.

산출물

token과 button/input/dialog/empty/error/loading primitive 계약
focus 복귀·keyboard·screen reader·validation 표시·pending 표현 규격

완료 증거

[x] 같은 상태가 화면마다 상반된 성공/오류 의미나 문구로 보이지 않는다.
[x] 공유 primitive가 network·controller·도메인 계산을 import하지 않는다.
[x] 디자인 props 계약을 기능 담당과 확정하고 기존의 확정 통계/동기화 대기 구분을 보존한다.
[x] CSS layer/scope·semantic token·플랫폼 독립 token·z-index/override 예외의 초기 규약과 파일 소유권을 정한다. 실제 잔여 CSS 정리는 U07이 수행한다.

범위·호환 주의: 모바일·데스크톱 layout 전체를 하나의 컴포넌트로 강제 통합하지 않는다.

U02

Mobile 화면을 공통 editor·typed view model에 연결

실행 이슈: release/v0.18.0 반영 완료 · Production 미반영 · #1420 · [리팩터링 3-3] · v0.18.0 · PR base release/v0.18.0. 이슈의 자기 맥락·선택 필독·상세 작업·행동 검증·직접 선행 링크·후속 인계로 시작한다. 게시를 Ready·구현·검증·배포 완료로 집계하지 않는다.

분야 / Phase: UI / 3
우선순위: P1
직접 선행: U01, A09, A12, A13, S08, S09
책임 역할: 모바일 디자인 + 기능 연결 담당
보고서 연결: F14, F22
추가 범위: C04
소유 경계: src/react/ui/mobile/**, src/react/features/**/mobile*, docs/contracts/**

의미: 모바일의 기존 제품 흐름을 유지하면서 화면 아래 중복 업무 판단을 제거한다.

산출물

Workout/Plan 입력·완료·수정·삭제·복구 화면의 typed adapter
IME/뒤로가기/overlay·오프라인 안내 및 conflict 복구 진입점

완료 증거

[ ] 화면이 숫자 의미·ID 추정·직접 저장·임의 통계 보완을 수행하지 않는다.
[ ] 초안 보관·전송 대기·서버 확정·격리 상태를 실제 데이터와 맞춰 표시한다.
[ ] 취소·재진입·동기화 지연·계정 전환에서 편집 state가 엉키지 않는다.
[ ] 모바일 신규 style이 U01 layer/scope 계약을 따르고 U07이 정리할 때 기능 상태 선택자·동적 클래스 목록을 제공한다.

범위·호환 주의: 삭제 직후 취소 toast를 새로 추가하지 않는다. 복구는 명시적인 보관·복구 화면에서 제공한다.

2026-09-10 U02: 운동/계획의 실제 모바일 typed editor, S08/A09 저장 수명, S09 보관·복구 화면 구현. 계약·증거·인계. 실제 브라우저 22개·동일 입력 7개·check 3,572개 통과. 최신 release b62a358c 통합·Precheck 통과, 앱 PR #1523 Merge Check 성공·b0fa93ec release 병합. 작업 기록. Production 배포 완료로 집계하지 않는다.

U03

Desktop 공통 editor 연결과 intrinsic responsive 전환

실행 이슈: release/v0.18.0 통합 완료 · PR #1520 · c1af78e8 · #1421 · [리팩터링 3-3] · v0.18.0 · PR base release/v0.18.0. U03 작업 기록. Production 미반영. 실제 Chromium 29/29·두 플랫폼 adapter 7/7, canvas/resize zoom 제거, U07 selector·native 미실행 범위 기록.

분야 / Phase: UI / 3
우선순위: P1
직접 선행: U01, A09, A12, A13, S08, S09
책임 역할: 데스크톱 디자인 + 기능 연결 담당
보고서 연결: F14, F21, F22
추가 범위: C04, C06
소유 경계: src/react/ui/desktop/**, src/react/vite/desktopRoot.tsx, src/react/ui/shared/styles/app-host.css, docs/contracts/**

의미: 고정 canvas 확대축소와 예외 보정 대신 창 크기·글자 크기에 대응하는 표현 구조로 바꾼다.

산출물

공통 editor/view model용 Desktop adapter
1913×1063/zoom 중심 shell을 Grid/Flex·container 대응 layout으로 이전; feature별 시각 계약

완료 증거

[x] 대표 좁은·넓은 창, 브라우저 200% 확대, 긴 한글/영문 텍스트에서 주요 작업이 가려지지 않는다.
[x] 같은 입력 시나리오의 저장 payload·validation·통계 의미가 모바일과 같다.
[x] 전역 canvas zoom/overflow 땜질을 제거하고 필요한 예외는 실제 컴포넌트 요구로 문서화한다.
[x] host/desktop CSS 소유권을 U07과 직렬화하고 N01이 제공하는 WebView·키보드/safe area 경계를 소비한다. native 구현 완료 여부는 U06에서 최종 확인한다.

범위·호환 주의: 현재 화면 불량을 이미 확인했다고 주장하지 않으며, 성능·접근성 검증으로 새 표현을 평가한다.

U04

긴 목록의 실제 viewport 가상화와 identity 계약

실행 이슈: U04 #1535 · [리팩터링 4-2] · v0.18.0 · PR base release/v0.18.0 · release 반영 (af5ae625), Production 미배포. 상세 목표·작업절차·예상효과·검증·선행 인계는 이슈 본문과 Phase 4 계획을 따른다.

분야 / Phase: UI / 4
우선순위: P2
직접 선행: U02, U03, A10, A11, A14, U07
책임 역할: 리스트 성능 담당
보고서 연결: F19, F20
추가 범위: C04
소유 경계: src/react/ui/shared/ViewportList.tsx (기존 useListWindow 삭제), src/react/ui/**/list*, src/react/features/**/selectors*

의미: 기록이 쌓여도 스크롤한 전체 행의 DOM과 반복 계산이 무한히 증가하지 않게 한다.

산출물

측정상 긴 피드·이력·검색 목록에 실제 가상화 적용
stable key·memoized item identity·가변 높이·focus/scroll 복원 규약

완료 증거

[x] 긴 목록을 끝까지 이동해도 live DOM 행 수가 viewport+overscan 수준에서 제한된다.
[x] 추가 페이지·행 수정·뒤로가기 후 scroll/focus가 예측 가능하다.
[x] 짧은 목록은 복잡한 가상화 없이 유지하며 기존 설치 도구 재사용 여부를 확인한다.

범위·호환 주의: 무한 스크롤의 데이터 페이지 로딩과 viewport 가상화를 같은 기능으로 취급하지 않는다.

U04 인계: 작업 기록 · viewport·identity 계약. 실제 960/300행 전체 탐색 후 live행 최대19~43, browser21/21·check3,581 pass, 필수 precheck·자기 Merge Check·release 포함 확인. U05 bundle 증가/초기 import, U06 native·접근성 미실행 범위, R04 비용 원본, R01 hook 퇴역을 구분한다.

U05

Feature import graph와 초기 bundle 비용 최적화

실행 이슈: U05 #1536 · [리팩터링 4-3] · v0.18.0 · PR base release/v0.18.0 · release/v0.18.0 반영완료 2cfeac53 · 앱 PR #1565 · Production 전. 상세 목표·작업절차·예상효과·검증·선행 인계는 이슈 본문과 Phase 4 계획을 따른다.

분야 / Phase: UI / 4
우선순위: P2
직접 선행: A15, U04, G04
책임 역할: 번들 성능 담당
보고서 연결: F23
추가 범위: C08
소유 경계: src/react/app/**, src/react/features/**/index*, vite.config.mjs, package.json, package-lock.json

의미: 분리한 코드가 실제 초기 로딩과 parse 비용 감소로 이어지게 한다.

산출물

feature route별 lazy boundary와 공용 chunk 의존성 정리
cold/warm boot 네트워크·parse·전환 비용 전후 자료

완료 증거

[ ] 초기 경로에서 import/미방문 feature 코드가 불필요하게 내려오지 않으며 현재 관리자 별도 bundle 경계도 유지된다.
[ ] 총 chunk 크기 합계 대신 실제 초기 요청과 사용자 동작별 비용을 G04 예산으로 평가한다.
[ ] lazy loading 실패·배포 후 구형 chunk·복귀 상황에 복구 경로가 있다.
[ ] package/Vite/lock 수정은 B02/HQ 소유권과 조율하고 플랫폼별 실제 초기 asset·font 비용 및 관리 앱 bundle 경계를 함께 확인한다.

범위·호환 주의: package/lock/vite sentinel 변경은 배정된 소유자와 조율하고 자동 통합 슬롯을 사용한다. 라이브러리 수를 늘리는 것을 목표로 하지 않는다.

U05 인계: 작업 기록 · 로딩·복구 계약. 초기 모바일 요청55→38·cold 전송669,839→566,048bytes, DOM317은 G04상한294 초과. 필수 precheck와 자기 Merge Check 통과 후 release 병합 2cfeac53를 확인했다. R01/R04/U06에 증거와 미측정 범위를 인계한다.

U06

전체 feature UX·접근성·플랫폼 일관성 검증

실행 이슈: U06 #1540 · [리팩터링 5-1] · v0.18.0 · 게시·미착수. 상세 목표·절차·검증·선행 인계는 이슈 본문을 따른다. 코드 변경의 release 통합과 R05/R06 승격·배포 완료는 별도로 확인한다.

분야 / Phase: UI / 5
우선순위: P2
직접 선행: A16, U04, U05, S09, R01, N01, I01, B01
책임 역할: UX 검증 담당
보고서 연결: F14, F21, F22
추가 범위: C04, C05, C06, C07
소유 경계: tests/browser/**, tests/viewport/**, docs/gates/**

의미: 아키텍처 이식 후 사용자가 경험하는 흐름과 데이터 표시가 일관적인지 확인한다.

산출물

로그인·운동·계획·달력·PR·프로필·소셜·그룹·인입·복구의 실제 연결 시나리오
모바일/desktop viewport·IME·keyboard·focus·확대·back/overlay 검증 증거

완료 증거

[ ] loading/empty/stale/error/pending/confirmed 상태를 각각 확인한다.
[ ] mock만 연결된 preview가 아니라 staging API와 연결된 화면에서도 핵심 흐름을 통과한다.
[ ] 시각 검토와 기능 검토의 담당자가 각각 결과를 남긴다.
[ ] 온보딩/신체 데이터·계정 연결/삭제·관리자·각 인입 경로를 G05 목록에 대조하고 stylesheet 진입 순서·native keyboard/safe area·font loading을 확인한다.

범위·호환 주의: 스크린샷이 같다는 이유만으로 입력·저장·접근성 회귀를 통과시키지 않는다.

U07

CSS cascade·scope·override·중복 코드 정리

실행 이슈: U07 #1532 · [리팩터링 4-1] · v0.18.0 · PR base release/v0.18.0 · Phase 1~4 완료·앱 PR #1549 / 4a642ad3 release 반영. U07 결과·수치·예외. 상세 목표·작업절차·예상효과·검증·선행 인계는 이슈 본문과 Phase 4 계획을 따른다.

분야 / Phase: UI / 4
우선순위: P2
직접 선행: U01, U02, U03
책임 역할: CSS 구조 담당
보고서 연결: F21, F22, F30
추가 범위: C04
소유 경계: src/react/ui/**/styles/**, src/react/vite/vite-scaffold.css, scripts/check-dead-css.mjs, dead-css-baseline.json

의미: 반응형 이전 후에도 스타일 덮어쓰기와 전역 충돌이 누적되는 것을 막는다.

산출물

host/reset·token·primitive·feature·플랫폼 예외의 layer/scope/소유권 정리
실제 사용처와 computed style에 근거한 반복 선택자·중복 선언·append-only override·불필요 important·dead CSS 제거
로드 순서·동적 클래스·z-index/stacking·scroll/overflow·font loading의 회귀 자료와 정당한 예외 목록

완료 증거

[x] 같은 화면이 feature 진입/lazy stylesheet 로드 순서에 따라 달라지지 않고 다른 feature·플랫폼의 스타일이 새지 않는다.
[x] 공유해야 할 의미 token과 플랫폼 독립 token을 구분하며 유효 fallback·동적 클래스는 보존한다. baseline 재생성만으로 개선 처리하지 않는다.
[ ] U02/U03 스타일 변경이 합류한 뒤 정리하고 이후 U04 변경까지 U06에서 확대·긴 텍스트·overlay·키보드/safe area의 실제 표현을 검증한다.

U07 인계: U02/U03 최종 CSS 통합 후 U07 Chromium 10/10·U03 29/29·U02 22/22·U01 16/16, 12개 화면/폭 32속성 차이 0. U04 이후 U06의 native·safe-area 최종 완료 항목은 계속 미완료로 유지한다. 소유·인계 계약.

범위·호환 주의: CSS Modules/Tailwind 전환이나 모든 important 제거를 목표로 삼지 않는다. U01은 초기 규약, U07은 실제 잔여 정리와 코드 품질을 소유한다.

B01

서버 API·인증·계정 연결·삭제·관리자 경계 개선

실행 이슈: Merged · PR #1346 · ba0f4035 · Production 포함·운영/실기기 인계 별도 · #1331 · [리팩터링 2-1]. 이슈 본문에 선택 필독·상세 작업·검증·직접 선행과 후속 인계를 포함한다.

분야 / Phase: PLATFORM / 2
우선순위: P1
직접 선행: G05, G03, A01
책임 역할: 서버 API·인증 담당
보고서 연결: F08, F09, F12
추가 범위: C05
소유 경계: api/auth/**, api/admin/**, api/account/**, src/react/services/auth/**, src/react/services/supabaseAuth.ts, src/react/services/accountDeletionClient.ts

의미: React 데이터 흐름 밖의 인증·관리·계정 생애주기에도 명시적 입력·권한·실패 계약을 둔다.

산출물

실제 API/provider별 입력 schema·actor/owner/admin 권한·오류·timeout/retry 계약과 필요한 모듈화
Kakao/Google/Apple 로그인·계정 연결·콜백·token 갱신·로그아웃·삭제의 상태 전이와 외부 실패 처리
계정 삭제의 외부 provider 해제·로컬 purge·서버 삭제·중단 재개 경계 및 필요한 검증

완료 증거

[ ] 잘못된 actor/target·연결 충돌·중복/늦은 callback·인증 만료·provider 실패에서 잘못된 계정 연결이나 타 owner 결과 적용이 없다.
[ ] 관리자/시험용 API의 환경·권한 차단을 확인하고 일반 client에 비밀·관리 권한을 전달하지 않는다. 실제 결함을 확인한 경우에만 수정한다.
[ ] 계정 삭제/로그아웃/세션 만료의 서로 다른 보존 정책을 유지하고 삭제된 계정 데이터를 retry/복구로 부활시키지 않는다.

범위·호환 주의: A07은 앱 owner runtime, B01은 서버/API·JS provider 구현, N01은 native callback/secure storage를 소유한다. 외부 실제 계정 변경은 검증 범위와 승인에 맞춰 별도로 수행한다.

B02

웹·Edge·관리자·Native의 환경·빌드·의존성 경계

실행 이슈: Merged · PR #1356 · 7b44295e · Production 포함·운영/실기기 인계 별도 · #1332 · [리팩터링 2-1]. 이슈 본문에 선택 필독·상세 작업·검증·직접 선행과 후속 인계를 포함한다.

분야 / Phase: PLATFORM / 2
우선순위: P1
직접 선행: G05, G03, G04
책임 역할: 빌드·환경 담당 + HQ
보고서 연결: F23, F29, F30
추가 범위: C08
소유 경계: .github/**, package.json, package-lock.json, vite*.mjs, vercel.json, docs/vercel.json, capacitor.config.json, ios/*.xcconfig, android/*.gradle, supabase/config.toml

의미: 같은 소스가 서로 다른 배포 대상에서 실행될 때 설정과 권한을 추측하지 않게 한다.

산출물

web/admin/Edge/iOS/Android별 build·환경·버전·지원 runtime·secret/public config 계약
기존 CI 권한·dependency/lock·toolchain·source map/로그 노출 경계 검토와 필요한 수정
DB 연결 수·API/Edge timeout·worker concurrency·메모리/인입 크기 예산과 배포 target 검증

완료 증거

[ ] 환경 누락/잘못된 target에서 가짜 성공 또는 다른 환경 fallback을 하지 않고 client 번들/로그에 서버 비밀이 포함되지 않는다.
[ ] 의존성·lock·빌드 도구가 일관되고 관리자 별도 배포, 웹 배포와 native 빌드/설치 버전의 조합을 명시한다.
[ ] G04와 같은 자원 예산을 사용하며 native release build 검증은 적합한 macOS/Android 환경에서 수행한 증거를 R05에 넘긴다. 실행 불가를 통과로 처리하지 않는다.

범위·호환 주의: 업데이트 자체가 목적이 아니며 의존성을 무조건 최신화하지 않는다. native 기능 코드는 N01, 앱 feature lazy import는 U05가 소유한다. 공용 sentinel은 배정된 소유자가 검증하고 자동 큐에서 통합한다.

N01

iOS·Android bridge·생애주기·SW 업데이트 개선

실행 이슈: Planned · 게시·미착수 · #1408 · [리팩터링 3-1] · v0.18.0 · PR base release/v0.18.0. 이슈의 자기 맥락·선택 필독·상세 작업·행동 검증·직접 선행 링크·후속 인계로 시작한다. 게시를 Ready·구현·검증·배포 완료로 집계하지 않는다.

분야 / Phase: PLATFORM / 3
우선순위: P1
직접 선행: B01, B02, S01, S07, S08, A07
책임 역할: 네이티브 runtime 담당
보고서 연결: F01, F09, F17, F21
추가 범위: C06
소유 경계: ios/App/App/**, android/app/src/main/**, src/react/contracts/nativeBridge.ts, src/react/services/nativeAuthSessionPolicy.ts, src/react/vite/nativeSplash.ts, public/sw.js, public/manifest.webmanifest

의미: 웹 코드의 이식이 네이티브 인증·저장·앱 재시작·오프라인 시작을 깨뜨리지 않게 한다.

산출물

Swift/Kotlin bridge·secure store·deep link/callback·resume/background/process-death의 타입·소유권·상태 계약과 필요한 정리
웹 shell/SW/assets cache와 IDB 사용자 데이터의 분리, 구/신 native shell·웹 코드·서비스 워커 호환 matrix
키보드/safe area·뒤로가기·splash·오프라인 시작·앱 업데이트의 실제 기기/적합 환경 검증

완료 증거

[ ] 늦거나 중복된 native callback·bridge 재연결·프로세스 종료에서 인증과 owner/draft/pending이 일관되게 수렴한다.
[ ] API/auth를 shell cache에 섞지 않고 오래된 HTML/chunk·cache 정리·업데이트 중단에도 지원 버전이 안전하게 시작한다.
[ ] v0.18 bridge/저장 형식을 모르는 기존 설치 앱과 열린 탭의 허용 조합·보존 후 업데이트 경로를 실제로 입증하고 R02에서 통합 확인한다.

범위·호환 주의: 캐시 삭제·강제 reload로 미저장 입력을 지우지 않는다. 외부 인증 서비스 계약은 B01, 빌드/환경은 B02, 화면 CSS는 U 담당과 좁은 계약으로 연결한다.

I01

전체 인입·파일 parser·identity·부분 실패 경로 개선

실행 이슈: #1415 · [리팩터링 3-2] · v0.18.0 · PR base release/v0.18.0. 2026-09-10 release/v0.18.0 통합 55e9fae8(PR #1498, Phase 1~6, 큐 Merge Check) — 작업 기록. staging·Production 미반영. 증거: 인입 계약 1벌(features/import/importContract.ts)·경로 등록표·worker/정규화 코드 표 일치 테스트·replay fixture 3종·큰 파일 계측(npm run perf:import). 소유 경계의 motraNormalizedUpload.ts·motraImportController.ts 는 #1463 이관·제거로 앱에 없다.

분야 / Phase: PLATFORM / 3
우선순위: P1
직접 선행: G05, A05, D09, G04
책임 역할: 인입·파일 담당
보고서 연결: F06, F08, F12, F13, F28
추가 범위: C07
소유 경계: src/react/services/motraNormalizedUpload.ts, src/react/services/inbodyImport.ts, src/react/services/wodupJsonlUpload.ts, src/react/controllers/motraImportController.ts, supabase/functions/_shared/wodup-normalizer.ts, src/react/features/import/**

의미: Wodup worker 외의 실제 파일·인입 경로에도 검증·보존·재시도와 자원 사용 계약을 적용한다.

산출물

Wodup/Motra/InBody 및 실제 존재하는 파일 경로의 원문→parse→validate→identity→canonical→통계 단계별 책임과 필요한 코드 정리
날짜/단위/null·잘못된 파일·중복/부분 성공·취소·업로드 중단·원문 가용성을 표현하는 typed 결과
대표 큰 파일의 parse/upload 메모리·시간·취소·UI 응답성 자료와 복구 replay fixture

완료 증거

[ ] 같은 파일/작업의 재시도와 신규 재인입 정책을 구분하고 source identity·수치 의미·원문을 보존한다.
[ ] 잘못된 행을 조용히 정상값으로 추정하지 않으며 부분 실패/성공을 정확히 표시하고 G04 자원 예산을 충족한다.
[ ] 각 실제 인입 경로가 A11 화면 상태, S10/R03 복구, R04 부하 시험에 연결된다. I01은 normalizer/parser, D09는 durable worker runtime을 소유한다.

범위·호환 주의: 없는 export/파일 기능을 새로 만들거나 provider의 재인입·원문 보존 정책을 임의로 변경하지 않는다.

R01

구현 이식 종료·퇴역 코드·테스트·문서 정리

실행 이슈: R01 #1537 · [리팩터링 4-4] · v0.18.0 · PR base release/v0.18.0 · release/v0.18.0 반영완료 · 앱 PR #1569 · merge849191b5 · precheck/Merge Check 통과 · Production 전. 상세 목표·작업절차·예상효과·검증·선행 인계는 이슈 본문과 Phase 4 계획을 따른다.

분야 / Phase: HQ / 4
우선순위: P2
직접 선행: A16, D11, S11, U05, G05, D12, U07, B01, B02, N01, I01, D14
책임 역할: HQ + 통합 정리 담당
보고서 연결: F08, F09, F10, F12, F13, F24, F25, F30
추가 범위: C01, C04
소유 경계: src/react/**, tests/**, docs/**, package.json, package-lock.json

의미: 새 구조와 옛 구조를 함께 유지하는 장기 스파게티 상태로 릴리즈가 끝나지 않게 한다.

산출물

활성 호출 경로 기준의 구 controller/repository/mapper·중복 projector·미사용 Vite scaffold 제거
서버 projection만 읽는 clientStrengthFallback 등 실제 의미에 맞춘 이름과 dead dependency 정리
행동 테스트 전환·정본 문서 갱신·호환 adapter eligibility manifest

완료 증거

[ ] 이전 구현에 대한 활성 import/호출이 없고 대체된 테스트의 행동 커버리지가 유지된다.
[ ] 보존한 구형 decoder·공개 RPC adapter·full rebuild는 목적/담당/소비자/제거 조건이 명시된 경계에만 있다.
[ ] 보고서 모든 행에 실제 구현·PR·시험 증거가 연결되고 baseline 파일을 지운 것만으로 any/dual-shape 해결 처리하지 않는다.
[ ] G05 장부의 모든 필수 기능·공유 계층에 유지 근거 또는 구현·검증 증거가 있고 미배정/미확인을 완료로 바꾸지 않는다. 원 보고서 31개 항목과 추가 범위 C01–C08을 모두 대조한다.

범위·호환 주의: 적용 migration 기록·사용 중인 구형 RPC·복구 가능한 기존 데이터·정당한 전체 rebuild를 dead code로 취급하지 않는다.

2026-09-10 D14 인계 보강: D14의 원본 변경행 저장·D11의 변경행 발행이 실제 활성 경로인지 호출자·trigger·worker를 확인한다. 대체된 전체 자식 UPDATE·전체 출력 교체 wrapper만 퇴역하고 유효 legacy decoder·공개 RPC·같은 writer를 쓰는 full rebuild는 보존한다. 63개/191개 의존과 G05의 이식 증거를 대조하되 Phase 5 여섯 작업은 예정/미검증으로 유지하고, 원본→계산→발행 경로 및 비용·미검증을 R04/R05에 넘긴다. 상세 절차.

2026-09-11 현재 작업: 퇴역/호환 eligibility manifest와 실제 사본·구버전 인계. 실제 release 반영은 최종 병합 후 기록한다.

R02

구·신 앱/서버/IDB 호환과 저장 장애 통합 검증

실행 이슈: R02 #1541 · [리팩터링 5-1] · v0.18.0 · 게시·미착수. 상세 목표·절차·검증·선행 인계는 이슈 본문을 따른다. 코드 변경의 release 통합과 R05/R06 승격·배포 완료는 별도로 확인한다.

분야 / Phase: HQ / 5
우선순위: P0
직접 선행: R01, S08, S09, N01, B01
책임 역할: 저장 통합 검증 담당
보고서 연결: F01, F02, F07, F07b, F16, F17, F26
추가 범위: C05, C06
소유 경계: tests/browser/**, tests/db/**, docs/gates/**

의미: 개별 모듈 시험을 넘어 실제 업데이트·재시작·다중 탭에서 사용자 입력이 보존되는지 확인한다.

산출물

old/old·old/new·new/old 기본 쓰기·new/new capability matrix
구형 IDB/mirror·blocked upgrade·dirty draft·pending update·owner change·호환 rollback 시나리오
서버 commit 후 응답 유실·동시 저장·conflict·late ACK·undo 경쟁의 실제 연결 시험

완료 증거

[ ] 어느 조합이 허용/업그레이드 대기/신규 기능 불가인지 실제 bundle과 두 브라우저 context로 증명한다.
[ ] 강제 새로고침·IDB clear 없이 초안/미전송 원문을 보존하고 불명확한 결과는 receipt 재확인으로 수렴한다.
[ ] 같은 논리 요청의 중복 canonical 반영·타 owner 노출·오래된 ACK에 의한 최신 의도 소실이 없다.
[ ] native 설치 버전/웹 번들/SW/IDB와 provider 로그인·연결·로그아웃·삭제를 포함해 허용된 호환 조합의 증거를 확인한다.

범위·호환 주의: v0.17 서버에 신규 undo capability가 없는 것을 가짜 성공이나 폐기 API fallback으로 처리하지 않는다.

R03

실제 사본 기반 선택 복구·인입 복원 리허설

실행 이슈: R03 #1542 · [리팩터링 5-1] · v0.18.0 · 게시·미착수. 상세 목표·절차·검증·선행 인계는 이슈 본문을 따른다. 코드 변경의 release 통합과 R05/R06 승격·배포 완료는 별도로 확인한다.

분야 / Phase: HQ / 5
우선순위: P1
직접 선행: R01, S10, S11, D11, I01
책임 역할: 복구 검증 담당
보고서 연결: F28
추가 범위: C07
소유 경계: scripts/data-copy/**, tests/recovery/**, docs/process/rollback.md

의미: 원본 보존 장치를 실제 복원 가능한 수준까지 확인한다.

산출물

현재/지원 구형 schema 사본→격리 DB→scoped dry-run→apply→통계 재생 훈련
update·full-family delete·partial child·복합키·인입 raw replay 및 실패 사본 시나리오
행 수/hash/ID/FK/source identity·실측 RPO/RTO와 복구 불가 범위 report

완료 증거

[ ] 목표 owner/family 외 정상 최신 데이터가 바뀌지 않는다.
[ ] 원문 누락·변조·schema 차이·삭제된 owner를 apply 전에 판별하고 허용 범위만 복구한다.
[ ] 복원된 facts와 read-model이 기대값과 일치하고 복구 도구를 문서만 읽은 담당자가 반복 실행할 수 있다.
[ ] Wodup 외 실제 Motra/InBody 등 I01의 인입 목록에 대해 지원 복구 범위와 원문 불가 상태를 확인한다.

범위·호환 주의: 리허설은 격리 환경에서 수행한다. 원문/사본이 없는 구간에 무손실 복구를 약속하지 않는다.

R04

혼합 부하·장기 이력·UI/저장 성능 검증

실행 이슈: R04 #1543 · [리팩터링 5-1] · v0.18.0 · 게시·미착수. 상세 목표·절차·검증·선행 인계는 이슈 본문을 따른다. 코드 변경의 release 통합과 R05/R06 승격·배포 완료는 별도로 확인한다.

분야 / Phase: HQ / 5
우선순위: P1
직접 선행: R01, G04, S07, D11, U05, B02, I01, D12
책임 역할: 성능 검증 담당
보고서 연결: F03, F05, F17, F19, F20, F23, F27, F29
추가 범위: C02, C07, C08
소유 경계: scripts/performance/**, tests/performance/**, docs/gates/**

의미: 구조 개선이 사용자 수와 누적 기록 증가에 실제로 견디는지 확인한다.

산출물

같은 인프라의 전후 1/4/10년·혼합 읽기/쓰기/인입·여러 owner/동일 owner 부하 결과
read/write p95·오류율·queue age·lock wait·generation delay·읽기/쓰기 행·WAL·bundle/DOM 계측
release SHA가 연결된 dashboard/경보와 지속 시험 결과

완료 증거

[ ] G04에서 고정한 부하·예산에서 저장 정합 오류가 없고 성능/freshness 기준을 충족한다.
[ ] 오늘 append의 비용이 불필요하게 전체 과거 기록을 재작성하는 형태가 아니다. 합당한 영향 suffix 비용은 분리해서 보고한다.
[ ] 과부하 후 backlog가 줄고 failed job/보관 데이터가 추적 가능하며 read 부하와 인입이 일반 저장을 고갈시키지 않는다.
[ ] 비통계 도메인 대표 쿼리, API/Edge 연결·자원 예산, 큰 파일 parse/upload, font·CSS/layout 비용도 같은 workload에서 확인한다.

범위·호환 주의: 원하는 동시 사용자 수를 정해 놓고 작은 fixture 결과만으로 달성했다고 주장하지 않는다.

2026-09-10 전체 쓰기 비용 보강: 기존 G04 도구와 같은 1/4/10년 workload에서 원본 DML→계산→최종 public DML·직렬화·WAL·trigger·lock wait·save p95·queue freshness를 분리 계측한다. 메모-only, 같은 mutation/동일 내용 새 저장, 현재 한 세트, 과거 수정·날짜 이동·최댓값 삭제·복합·동시 저장을 포함한다. D14/D11의 무관한 행 쓰기 0과 full oracle 동치 및 기존 예산 충족을 확인하고 정당한 suffix 비용을 구분한다. 부분 DML 감소를 전체 개선율로 외삽하지 않는다. 작업절차·수락 조건.

R05

0.18.0 스테이징 전체 릴리즈 리허설과 후보 확정

실행 이슈: R05 #1544 · [리팩터링 5-2] · v0.18.0 · 게시·미착수. 상세 목표·절차·검증·선행 인계는 이슈 본문을 따른다. 코드 변경의 release 통합과 R05/R06 승격·배포 완료는 별도로 확인한다.

분야 / Phase: HQ / 5
우선순위: P0
직접 선행: R02, R03, R04, U06, D13, B02
책임 역할: HQ 릴리즈 담당
보고서 연결: F01, F02, F03, F05, F06, F28, F29
추가 범위: C01, C02, C03, C06, C08
소유 경계: .github/workflows/deploy.yml, docs/process/deployment-pipeline.md, docs/releases/**

의미: 여러 PR의 녹색 표시를 실제 배포 가능한 하나의 릴리즈 증거로 묶는다.

산출물

기존 상태→DB 확장/이관→Edge→새 frontend→worker/서빙 전환의 staging dress rehearsal
DB replay/pgTAP·browser/viewport·schema·migration ledger·loss audit·smoke 필수 결과
구 job/구 client coexistence·호환 frontend rollback/forward-fix·projection full 복구 시험과 릴리즈 후보 SHA

완료 증거

[ ] 환경/secret 부재로 필요한 job이 skipped되면 실패 처리하고 해당 검증을 실행한 증거가 있어야 한다.
[ ] canonical 사용자 값·ID·자식 관계가 이관 전후 같고 backfill은 projection/metadata 범위에서 bounded하게 진행된다.
[ ] 관리자 별도 배포 경로를 포함해 공개 시점이 통제되며 rollback 가능한 정확한 버전과 중단 조건이 명시된다.
[ ] D13의 도구 통과만으로 끝내지 않고 이번 릴리즈 실제 migration 전체를 populated 이전 버전 DB에서 이관·중단/재개·구/신 앱 공존 시험한다. 웹/admin/Edge와 필요한 iOS/Android 빌드 증거를 같은 후보에 연결한다.

범위·호환 주의: 리허설용 임의 운영 사용자 쓰기나 운영 DB 전체 downgrade를 요구하지 않는다.

2026-09-10 전환 안전성 보강: D14/D11을 포함한 실제 전체 forward migration을 이전 버전 populated 격리 DB에 적용하고 원본 값·ID·source·자식 관계·receipt·필수 이력을 대조한다. 실제 변경 지점의 중단/재개·pending/processing/computed/failed 상태·구/신 클라이언트 저장·복원 후 재저장·full rebuild를 R02/R03/U06 증거와 같은 후보 SHA에 묶는다. 비의도 원본 변경·부분 세대 노출·dirty 유실 0과 허용 rollback/forward-fix를 확인한다. #1478 자동 제외를 합격으로 집계하거나 다시 활성화하지 않는다. 작업절차·수락 조건.

R06

v0.18.0 production 릴리즈와 검증 종료

실행 이슈: R06 #1545 · [리팩터링 5-3] · v0.18.0 · 게시·미착수. 상세 목표·절차·검증·선행 인계는 이슈 본문을 따른다. 코드 변경의 release 통합과 R05/R06 승격·배포 완료는 별도로 확인한다.

분야 / Phase: HQ / 5
우선순위: P0
직접 선행: R05
책임 역할: HQ
보고서 연결: F28, F29, F30
추가 범위: C01, C08
소유 경계: docs/releases/**, .github/workflows/deploy.yml

의미: 모든 개선사항이 실제 배포된 결과와 연결되어야 릴리즈를 완료한다.

산출물

검증된 main→production release PR와 v0.18.0 merge commit, 배포 파이프라인 실행
DB staging-applied gate→migration dry-run/push→Edge probe→Vercel→smoke→tag 결과
합의된 관찰 구간의 저장/오류/queue/freshness 지표·복구 사본·coverage ledger 마감

완료 증거

[ ] 필수 개선사항 31개 행과 63개 실행 issue가 구현·통합·배포 증거로 닫히고 미검증 항목을 완료로 표시하지 않는다.
[ ] 생산 배포는 후보 SHA/실제 배포 환경에 대해 필요한 승인을 마지막 단계에서 받고 기존 자동화 경로로 진행한다.
[ ] 배포 직후 smoke뿐 아니라 설정한 관찰 기간의 오류/지연·유효 사본 상태를 확인한 후 milestone을 닫는다.
[ ] 추가 범위 C01–C08도 G05 장부의 증거로 마감한다. 문서에 이슈를 추가한 사실은 코드 품질·운영 검증 완료를 뜻하지 않는다.

범위·호환 주의: 이 카드는 향후 production 릴리즈의 조건이다. 총괄 문서 등록과 실행 이슈 게시·제품 배포는 별도 작업이다.

14. 의존성 검증과 실행 전 준비

2026-09-10 기존 62개 ID·수용 기준·186개 직접 의존을 보존하고 D14를 추가했다. D14←D02/D04/S10/D11의 4개와 R01←D14 1개를 더해 63개·191개 직접 의존이다. 6개 분야와 5개 Phase에 각 작업이 한 번 배정되고 Phase별 합계는 11/18/21/7/6이다. Phase 역전·누락·순환 없이 모든 작업은 R06으로 연결된다. 내부 실행 스텝은 §5의 순서를 따른다.

현재 63/63 게시·미게시 0개다. 앞선 Phase 4는 7개, 이번 Phase 5는 6개 게시했으며 이번 게시를 구현 완료로 세지 않는다. Phase 4 계획과 실행 이슈에서 실제 GitHub 번호·목표·범위·선행·허용 경로·작업절차·예상효과·완료조건을 확인한다. 착수 때 최신 release SHA·열린 이슈/PR·계약·배포 버전을 대조한다. 게시를 Ready·검증·병합·배포 완료로 바꾸지 않는다. 63개는 실행 작업 수이며 관리용 이슈는 분모에 더하지 않는다.

15. 기존 구조·계약과 연결

이번 목표는 다음의 기존 기반 위에서 이식한다. 링크한 기록은 이번 v0.18.0 작업의 완료 증거가 아니다.

영역	현재 계약·기반 기록
정규 운동 계층	세션 데이터 모델, 운동 기록 계층 리모델링
완료 기록 저장	쓰기 파이프라인 계약, 쓰기 원천 계약, 기존 파이프라인 작업 기록
사실 보존	유저 사실 불변 계약, 원본 보호 작업 기록
서버 조회·통계	화면 RPC 계약
DB 이관·schema	Migration 랜딩 절차, schema snapshot 작업 기록
UI 경계	디자인 전달·기능 배선 계약, 하단 크롬 여백 개선 기록
배포·작업 기록	브랜치 운영, 배포 파이프라인, updates 기록 형식

v0.18.0 아키텍처 리팩터링 총괄 — 목표 구조·63개 이슈·6개 분야·5개 Phase ​

1. CTO 관점의 목표와 기본 전략 ​

2. 최종 책임 경계 ​

3. 보존할 정책과 이번에 바꿀 기술 계약 ​

4. 주요 분야별 그룹과 우선순위 ​

5. 전체 5개 Phase와 통과 기준 ​

분야별 Phase 배정과 현재 진행률 ​

Phase 1 게시 이슈와 실행 말머리 ​

Phase 1 — 공통 기반과 계약 확정 ​

Phase 2 — 안전한 저장 경로와 첫 수직 통합 ​

Phase 3 — 전체 기능·통계·플랫폼 이식 ​

Phase 4 — 최종 구조·CSS·성능·원본 쓰기 정리 ​

Phase 5 — 통합 검증·배포 리허설·v0.18.0 릴리즈 ​

Phase 내부의 선행 순서 ​

Phase 운영 규칙 ​

6. 여러 Fable 5.1을 운영하는 방식 ​

7. 작업 상태와 누락 방지 ​

총괄 문서와 개별 작업 기록의 역할 ​

작업 세션의 읽기 범위와 맥락 인계 ​

중요 업데이트 기록 장부 ​

Phase 1 통합 증거와 후속 경계 ​

PR #1278의 CI 기준선 보수 ​

결정과 계획 변경 이력 ​

8. 데이터 이관·호환·전환 전략 ​

9. 검증과 릴리즈 절차 ​

10. 0.18.0 완료의 정의 ​

유지되는 전체 커버리지 종료 조건 ​

11. 보고서와 추가 커버리지 대응표 ​

12. 63개 Issue 실행 목록 ​

13. Issue별 작업 지시서 초안 ​

G01 ​

G02 ​

G03 ​

G04 ​

G05 ​

S01 ​

S02 ​

S03 ​

S04 ​

S05 ​

S06 ​

S07 ​

S08 ​

S09 ​

S10 ​

S11 ​

D01 ​

D02 ​

D03 ​

D04 ​

D05 ​

D06 ​

D07 ​

D08 ​

D09 ​

D10 ​

D11 ​

D12 ​

D13 ​

D14 ​

A01 ​

A02 ​

A03 ​

A04 ​

A05 ​

A06 ​

A07 ​

A08 ​

A09 ​

A10 ​

A11 ​

A12 ​

A13 ​

A14 ​

A15 ​

A16 ​

U01 ​

U02 ​

U03 ​

U04 ​

v0.18.0 아키텍처 리팩터링 총괄 — 목표 구조·63개 이슈·6개 분야·5개 Phase

1. CTO 관점의 목표와 기본 전략

2. 최종 책임 경계

3. 보존할 정책과 이번에 바꿀 기술 계약

4. 주요 분야별 그룹과 우선순위

5. 전체 5개 Phase와 통과 기준

분야별 Phase 배정과 현재 진행률

Phase 1 게시 이슈와 실행 말머리

Phase 1 — 공통 기반과 계약 확정

Phase 2 — 안전한 저장 경로와 첫 수직 통합

Phase 3 — 전체 기능·통계·플랫폼 이식

Phase 4 — 최종 구조·CSS·성능·원본 쓰기 정리

Phase 5 — 통합 검증·배포 리허설·v0.18.0 릴리즈

Phase 내부의 선행 순서

Phase 운영 규칙

6. 여러 Fable 5.1을 운영하는 방식

7. 작업 상태와 누락 방지

총괄 문서와 개별 작업 기록의 역할

작업 세션의 읽기 범위와 맥락 인계

중요 업데이트 기록 장부

Phase 1 통합 증거와 후속 경계

PR #1278의 CI 기준선 보수

결정과 계획 변경 이력

8. 데이터 이관·호환·전환 전략

9. 검증과 릴리즈 절차

10. 0.18.0 완료의 정의

유지되는 전체 커버리지 종료 조건

11. 보고서와 추가 커버리지 대응표

12. 63개 Issue 실행 목록

13. Issue별 작업 지시서 초안

G01

G02

G03

G04

G05

S01

S02

S03

S04

S05

S06

S07

S08

S09

S10

S11

D01

D02

D03

D04

D05

D06

D07

D08

D09

D10

D11

D12

D13

D14

A01

A02

A03

A04

A05

A06

A07

A08

A09

A10

A11

A12

A13

A14

A15

A16

U01

U02

U03

U04