docs(devlog): archive the 48 units whose work landed on dev

.github/CODEOWNERS

@@ -38,7 +38,7 @@
 # subsystem. Optional subsystems (Compatibility Lab and anything added later) register
 # into core-owned slots at activation instead of being imported here; the invariant is
 # enforced by tests/core-lab-boundary.test.ts and designed in
-# devlog/_plan/260814_lab_core_decoupling/.
+# devlog/_fin/260814_lab_core_decoupling/.
 # Last-match-wins: this block must stay below /src/server/ to take effect.
 /src/router.ts @lidge-jun
 /src/server/index.ts @lidge-jun

AGENTS.md

@@ -62,7 +62,7 @@ subagent-fallback chain has nowhere to await, so an `await` added before the
 activation block would silently reroute subagents to a different model than the
 operator configured.
 
-Design and audit history: `devlog/_plan/260814_lab_core_decoupling/`.
+Design and audit history: `devlog/_fin/260814_lab_core_decoupling/`.
 
 ## The `devlog` directory
 

devlog/_plan/260730_gui_hydration_loading_unify/010_loading_contract.md → devlog/_fin/260730_gui_hydration_loading_unify/010_loading_contract.md

@@ -559,8 +559,8 @@ export function useDataSurface<T>(
 WP6가 카드 패딩·스위치 중심선·구조를 함께 결정해야 한다. WP2가 loading 목적의 얕은 카드
 래퍼를 만들면 그 결정을 선점하고 WP6의 검증 범위를 흐린다. 따라서 WP6는 이 결정으로 **WP1
 뒤 병렬 착수 가능**이며, WP3만 WP2의 어댑터·프리미티브에 순차 의존한다
-([000_plan.md:35](/Users/jun/Developer/new/700_projects/opencodex/devlog/_plan/260730_gui_hydration_loading_unify/000_plan.md:35),
-[000_plan.md:38](/Users/jun/Developer/new/700_projects/opencodex/devlog/_plan/260730_gui_hydration_loading_unify/000_plan.md:38)).
+([000_plan.md:35](/Users/jun/Developer/new/700_projects/opencodex/devlog/_fin/260730_gui_hydration_loading_unify/000_plan.md:35),
+[000_plan.md:38](/Users/jun/Developer/new/700_projects/opencodex/devlog/_fin/260730_gui_hydration_loading_unify/000_plan.md:38)).
 
 ```tsx
 import type { CSSProperties, ReactNode } from "react";
@@ -1029,7 +1029,7 @@ test("shared loading primitives announce one polite busy status", () => {
 
 WP3가 계획의 15개 표면 중 하나를 옮길 때 아래를 순서대로 적용한다. 한 페이지에 여러 독립 DTO가
 있으면 DTO마다 이 체크리스트를 적용하되, 페이지의 준비 여부를 한 DTO의 성공으로 대신 판단하지
-않는다([000_plan.md:54](/Users/jun/Developer/new/700_projects/opencodex/devlog/_plan/260730_gui_hydration_loading_unify/000_plan.md:54)).
+않는다([000_plan.md:54](/Users/jun/Developer/new/700_projects/opencodex/devlog/_fin/260730_gui_hydration_loading_unify/000_plan.md:54)).
 
 - 기존 fetch entry point와 현재 cache key를 찾고, `useDataSurface(key, deps, load, { isEmpty, pollMs, enabled })`로 교체한다. 새 `useState` cache, 새 `useEffect` fetch, 새 module map을 만들지 않는다.
 - `load(signal)`은 기존 endpoint와 `AbortSignal`을 그대로 전달하고, 실패 응답은 throw한다. 성공값으로 `undefined`를 반환하지 않는다.
@@ -1496,5 +1496,5 @@ bun run privacy:scan
 **OUT**: WP2는 15개 페이지를 이관하지 않는다. 각 페이지의 실제 endpoint·empty copy·retry UI·layout
 변경은 WP3다. WP2는 poll 간격, request count, cache TTL, inflight 공유, quota fan-out도 바꾸지
 않는다. 그 수량 정책은 WP4이며, 계획도 WP3의 단일 진입점 뒤에 WP4를 둔다
-([000_plan.md:36](/Users/jun/Developer/new/700_projects/opencodex/devlog/_plan/260730_gui_hydration_loading_unify/000_plan.md:36)).
+([000_plan.md:36](/Users/jun/Developer/new/700_projects/opencodex/devlog/_fin/260730_gui_hydration_loading_unify/000_plan.md:36)).
 WP2는 설정 card/row primitive를 export하지 않으므로 WP6의 정렬 통일도 여기서 하지 않는다.

devlog/_plan/260730_gui_hydration_loading_unify/030_revalidation_policy.md → devlog/_fin/260730_gui_hydration_loading_unify/030_revalidation_policy.md

@@ -1,6 +1,6 @@
 # 030 — WP4 재검증·폴링·요청 중복 제거
 
-작성 2026-07-30. 이 문서는 구현 diff다. 기준은 [000_plan.md:115-165](/Users/jun/Developer/new/700_projects/opencodex/devlog/_plan/260730_gui_hydration_loading_unify/000_plan.md:115), [000_research.md:381-394](/Users/jun/Developer/new/700_projects/opencodex/devlog/_plan/260730_gui_hydration_loading_unify/000_research.md:381), [001_live_evidence.md:47-75](/Users/jun/Developer/new/700_projects/opencodex/devlog/_plan/260730_gui_hydration_loading_unify/001_live_evidence.md:47)다. E3는 npm 전역 v2.7.43 서빙본의 4초 관측이고, 아래 호출 지점은 `dev` HEAD에서 다시 확인했다.
+작성 2026-07-30. 이 문서는 구현 diff다. 기준은 [000_plan.md:115-165](/Users/jun/Developer/new/700_projects/opencodex/devlog/_fin/260730_gui_hydration_loading_unify/000_plan.md:115), [000_research.md:381-394](/Users/jun/Developer/new/700_projects/opencodex/devlog/_fin/260730_gui_hydration_loading_unify/000_research.md:381), [001_live_evidence.md:47-75](/Users/jun/Developer/new/700_projects/opencodex/devlog/_fin/260730_gui_hydration_loading_unify/001_live_evidence.md:47)다. E3는 npm 전역 v2.7.43 서빙본의 4초 관측이고, 아래 호출 지점은 `dev` HEAD에서 다시 확인했다.
 
 ## 현재 요청 지도
 

devlog/_plan/260730_gui_hydration_loading_unify/050_settings_card_unify.md → devlog/_fin/260730_gui_hydration_loading_unify/050_settings_card_unify.md

@@ -9,11 +9,11 @@ WP6은 WP2의 D 결과를 읽고 아래 둘 중 하나만 고른다.
 | `.setting-row`를 감싼 card primitive를 export함 | 그 primitive를 import하고, 이 문서의 markup을 그 primitive의 children으로 넣는다. | WP6가 두 번째 card primitive를 만들지 않는다. |
 | WP2가 로더만 다루며 card primitive를 export하지 않음 | 아래의 `<div className="card">` + `.setting-row` markup을 WP6의 정본으로 둔다. | WP2에 card API를 뒤늦게 추가하지 않는다. |
 
-이 결정은 WP6 P에서 한 번만 기록한다. WP2의 카드 export는 선택적 소비 관계일 뿐이며, WP6의 시작·검증·완료를 막지 않는다. 이 분기는 계획에 이미 명시돼 있다: `/Users/jun/Developer/new/700_projects/opencodex/devlog/_plan/260730_gui_hydration_loading_unify/000_plan.md:34`.
+이 결정은 WP6 P에서 한 번만 기록한다. WP2의 카드 export는 선택적 소비 관계일 뿐이며, WP6의 시작·검증·완료를 막지 않는다. 이 분기는 계획에 이미 명시돼 있다: `/Users/jun/Developer/new/700_projects/opencodex/devlog/_fin/260730_gui_hydration_loading_unify/000_plan.md:34`.
 
 ## 현재 상태 진단
 
-사용자가 보고 있는 화면은 이 checkout이 아니라 npm 전역 `v2.7.43`이다. 그 서빙 CSS에는 `.account-pool-strategy-card` 규칙이 없어서 카드 안쪽 inset 자체가 없었다. 반대로 현재 `dev`에는 이미 `padding: 14px 16px`가 있다. 즉, **테두리에 바짝 붙어 보인 패딩 문제는 릴리스 지연으로 남아 있고, dev에서 같은 패딩 버그가 그대로 재현되는 것은 아니다.** 근거는 `/Users/jun/Developer/new/700_projects/opencodex/devlog/_plan/260730_gui_hydration_loading_unify/000_research.md:307-318`, 현재 CSS는 `/Users/jun/Developer/new/700_projects/opencodex/gui/src/styles.css:1284-1289`이다.
+사용자가 보고 있는 화면은 이 checkout이 아니라 npm 전역 `v2.7.43`이다. 그 서빙 CSS에는 `.account-pool-strategy-card` 규칙이 없어서 카드 안쪽 inset 자체가 없었다. 반대로 현재 `dev`에는 이미 `padding: 14px 16px`가 있다. 즉, **테두리에 바짝 붙어 보인 패딩 문제는 릴리스 지연으로 남아 있고, dev에서 같은 패딩 버그가 그대로 재현되는 것은 아니다.** 근거는 `/Users/jun/Developer/new/700_projects/opencodex/devlog/_fin/260730_gui_hydration_loading_unify/000_research.md:307-318`, 현재 CSS는 `/Users/jun/Developer/new/700_projects/opencodex/gui/src/styles.css:1284-1289`이다.
 
 그러나 dev도 설정 구조는 통일돼 있지 않다. `CodexPoolStrategySetting`은 제목·설명을 card의 맨 위에 두고 전폭 select를 별도 grid로 내보낸다(`/Users/jun/Developer/new/700_projects/opencodex/gui/src/components/CodexPoolStrategySetting.tsx:190-237`). 그 select의 label은 `strategyLabelHidden` 때문에 `sr-only`가 된다(`/Users/jun/Developer/new/700_projects/opencodex/gui/src/components/AccountPoolStrategyControls.tsx:54-70`). 따라서 화면에는 "제목 + 설명 아래의 이름 없는 전폭 선택기"가 남는다. 이는 title/desc를 좌측에, 조작부를 우측에 둔 지배적 패턴과 다르다. 기준 구현은 `/Users/jun/Developer/new/700_projects/opencodex/gui/src/pages/claude-code-sections.tsx:41-69`, CSS는 `/Users/jun/Developer/new/700_projects/opencodex/gui/src/styles.css:1830-1842`다.
 
@@ -174,7 +174,7 @@ diff --git a/gui/src/styles.css b/gui/src/styles.css
 +.account-pool-strategy-card__error { margin: 0 var(--space-4) var(--space-3); color: var(--red); }
 ```
 
-release 쪽 패딩은 이 diff로 "고친다"고 말하지 않는다. 이 diff는 dev 구조를 정본으로 맞춘다. 사용자의 실제 `v2.7.43` 화면에는 이 CSS가 없으므로, 로컬 build를 실제 serving binary로 교체하고 이후 릴리스해야 `padding`과 새 row 모두 도달한다. 서빙본/checkout 불일치 근거는 `/Users/jun/Developer/new/700_projects/opencodex/devlog/_plan/260730_gui_hydration_loading_unify/000_research.md:7-29`다.
+release 쪽 패딩은 이 diff로 "고친다"고 말하지 않는다. 이 diff는 dev 구조를 정본으로 맞춘다. 사용자의 실제 `v2.7.43` 화면에는 이 CSS가 없으므로, 로컬 build를 실제 serving binary로 교체하고 이후 릴리스해야 `padding`과 새 row 모두 도달한다. 서빙본/checkout 불일치 근거는 `/Users/jun/Developer/new/700_projects/opencodex/devlog/_fin/260730_gui_hydration_loading_unify/000_research.md:7-29`다.
 
 ## 스위치 정렬 diff
 

devlog/_plan/260730_gui_hydration_loading_unify/060_multimodel_demotion.md → devlog/_fin/260730_gui_hydration_loading_unify/060_multimodel_demotion.md

@@ -2,7 +2,7 @@
 
 ## 판정과 전제
 
-이 WP는 WP6 CSS에 의존하지 않는다. 제거 허용 여부는 control마다 CLI/API 수용 매니페스트가 실제 소스에 있는지와 사용자의 제거 승인만으로 판단한다. 이 의존성은 `/Users/jun/Developer/new/700_projects/opencodex/devlog/_plan/260730_gui_hydration_loading_unify/000_plan.md:34-45`, 사전 gate는 같은 문서 167-172행에 있다.
+이 WP는 WP6 CSS에 의존하지 않는다. 제거 허용 여부는 control마다 CLI/API 수용 매니페스트가 실제 소스에 있는지와 사용자의 제거 승인만으로 판단한다. 이 의존성은 `/Users/jun/Developer/new/700_projects/opencodex/devlog/_fin/260730_gui_hydration_loading_unify/000_plan.md:34-45`, 사전 gate는 같은 문서 167-172행에 있다.
 
 여기서 "개별"은 모델 하나, provider 하나의 model catalog, custom model 한 건을 바꾸는 조작이다. 전역 context-cap 값, 모든 provider에 일괄 적용하는 switch, 전역 shadow-call model, provider의 기본 model은 GUI에 남긴다. provider별 context-cap은 **GUI에 남긴다.** 모델 하나가 아니라 provider 단위이며, 전역 cap value와 `setAll`의 바로 아래에서 같은 설정 축을 이룬다. 다만 현재 provider model card header에 박혀 있으므로 WP6 정본 row로 옮긴다. 근거가 되는 현재 control은 `/Users/jun/Developer/new/700_projects/opencodex/gui/src/pages/Models.tsx:659,735`, API/CLI는 `/Users/jun/Developer/new/700_projects/opencodex/src/server/management/provider-routes.ts:441-485`, `/Users/jun/Developer/new/700_projects/opencodex/src/cli/models-runtime.ts:144-173`에 있다.
 

devlog/_fin/260731_pr_issue_triage_round/050_windows_ci_flake_rca.md

@@ -164,7 +164,7 @@ macOS의 claude 핑 테스트도 같은 계열이다. 90ms 침묵에 25ms 핑 
 ## 병행 단위 — `260731_windows_bun_stability`
 
 같은 문제를 다른 사람(`bitkyc08-arch`)이 독립적으로 조사해
-`devlog/_plan/260731_windows_bun_stability/000_research.md`에 남겼다. 결론이
+`devlog/_fin/260731_windows_bun_stability/000_research.md`에 남겼다. 결론이
 수렴한다 — 하나의 플레이크가 아니라 원인이 다른 여러 모드라는 것.
 
 그쪽이 **더 정확한 부분이 둘** 있어서 여기 반영한다.

devlog/_fin/260801_deepseek_responses_wire/040_outcome.md

@@ -100,4 +100,4 @@ regression from this unit:
   `panic(thread 8988): Internal assertion failure` / `oh no: Bun has crashed`.
 
 That belongs to the open Windows Bun stability work
-(`devlog/_plan/260731_windows_bun_stability/`), not here.
+(`devlog/_fin/260731_windows_bun_stability/`), not here.

devlog/_plan/260803_pr_issue_sweep/000_plan.md → devlog/_fin/260803_pr_issue_sweep/000_plan.md

@@ -68,7 +68,7 @@ the routing subsystem in this unit, confined to the native compact branch in
 `src/server/responses/compact.ts`.
 
 **What used to be Phase 3 is gone.** It carried #914 and #919. Both left for
-`devlog/_plan/260803_transport_attribution/` after the audit gate showed each
+`devlog/_fin/260803_transport_attribution/` after the audit gate showed each
 is a policy decision about account-health attribution rather than a local fix.
 The earlier tables in this document showed a 3→4 hard dependency and then
 dropped it; with the transport work gone entirely, no such edge exists.
@@ -101,7 +101,7 @@ provider-local default-off repair is its own unit,
 
 #914 and #919 (transport failure attribution, before and after HTTP 200) left
 this unit after four audit rounds. Their analysis and the full rejection
-history live in `devlog/_plan/260803_transport_attribution/`. Both issues stay
+history live in `devlog/_fin/260803_transport_attribution/`. Both issues stay
 **open**; nothing in this unit fixes either.
 
 The #915 and #893 deferrals were checked by the plan reviewer against the
@@ -185,7 +185,7 @@ authenticating server before failing, and after HTTP 200 the question stops
 being about credentials at all and becomes about reliability. The likely
 correct direction for both is separating host health from account health. That
 work, and the full rejection history including the `5xx → retry rejection`
-attempt-history hole, is in `devlog/_plan/260803_transport_attribution/`.
+attempt-history hole, is in `devlog/_fin/260803_transport_attribution/`.
 
 Four rejected designs cost one session and shipped nothing broken. The
 alternative was a guard that passed CI and silently changed routing behavior

devlog/_plan/260803_pr_issue_sweep/030_phase3_compact_alternate.md → devlog/_fin/260803_pr_issue_sweep/030_phase3_compact_alternate.md

@@ -109,7 +109,7 @@ Flow:
 behavior.** Earlier drafts of this doc tried to define a neutrality rule here,
 first attributing every B exception to B, then deferring to a transport-phase
 classifier. Both are now moot: #914 and #919 left this unit entirely
-(`devlog/_plan/260803_transport_attribution/`) after four rejected designs
+(`devlog/_fin/260803_transport_attribution/`) after four rejected designs
 established that no local rule correctly decides attribution.
 
 So this phase does **not** change attribution semantics at all. A transport

devlog/_plan/260803_pr_issue_sweep/040_phase4_backlog_disposition.md → devlog/_fin/260803_pr_issue_sweep/040_phase4_backlog_disposition.md

@@ -102,7 +102,7 @@ prove correct (`tests/server-live.test.ts:642-675`).
 
    **#914 and #919 both stay open.** Four designs across the two were rejected
    at the audit gate, and both moved to
-   `devlog/_plan/260803_transport_attribution/`. Their comments record what was
+   `devlog/_fin/260803_transport_attribution/`. Their comments record what was
    tried and why each failed, so the next attempt does not rediscover that Bun
    collapses DNS failure and connection refusal into one label, that redirects
    put credential-visible failures on the same path, that a 5xx observed during

devlog/_plan/260803_pr_issue_sweep/060_outcome.md → devlog/_fin/260803_pr_issue_sweep/060_outcome.md

@@ -31,7 +31,7 @@ The fourth round also found the decision record:
 behavior deliberately, with `transient 실패 기록, affinity 해제` as the stated
 expected outcome. It is a policy, not a defect.
 
-Both moved to `devlog/_plan/260803_transport_attribution/` with the full
+Both moved to `devlog/_fin/260803_transport_attribution/` with the full
 history. @luvs01 then opened #922 with a fourth approach that includes Bun's
 `ConnectionRefused` — the thing design 1 missed. Reviewed with the probe
 evidence and the two post-header counterexamples attached.