agentic-dev 0.2.3 → 0.2.6

package/.agent/prd.json

@@ -13,7 +13,7 @@
         ".agent/prompt.md",
         "sdd/02_plan",
         "sdd/03_build",
-        "sdd/04_verify"
+        "sdd/03_verify"
       ],
       "validation": [
         "jq . .agent/prd.json"

package/.agent/prompt.md

@@ -6,7 +6,7 @@ Rules:
 3. Lock one reproduction or validation command before editing.
 4. Make one focused change set toward the requested story.
 5. Re-run the requested validation commands immediately.
-6. Update the matching `sdd/02_plan`, `sdd/03_build`, and `sdd/04_verify` current-state artifacts when scope changes.
+6. Update the matching `sdd/02_plan`, `sdd/03_build`, and `sdd/03_verify` current-state artifacts when scope changes.
 7. Update `.agent/prd.json` story status and append one short line to `.agent/progress.txt`.
 8. Stop after this iteration and report:
    - story id

package/.claude/CLAUDE.md

@@ -19,7 +19,7 @@ templates/
 │   └── skills/      # Claude Code repo-local skills (.claude/skills/<name>/SKILL.md)
 ├── .codex/          # Codex 설정, 에이전트, 스킬
 ├── client/
-│   ├── platform/    # 일반 앱 템플릿
+│   ├── web/    # 일반 앱 템플릿
 │   ├── admin/       # 어드민 템플릿
 │   ├── mobile/      # 현장형 모바일 템플릿
 │   └── landing/     # 랜딩 템플릿

package/.claude/agents/db-dev.md

@@ -23,4 +23,4 @@ Focus:
 Rules:
 - Keep template defaults generic.
 - Separate persistence concerns from domain logic.
-- Document backend data surface changes in `sdd/04_data`, `06_iac`, `04_verify`.
+- Document backend data surface changes in `sdd/04_data`, `06_iac`, `03_verify`.

package/.claude/agents/frontend-dev.md

@@ -22,4 +22,4 @@ Focus:
 Rules:
 - Preserve runtime tree readability from `main.tsx` down to route leaves.
 - Prefer product-grade patterns over placeholder scaffolds.
-- Record UI structure changes in `sdd/03_build` and `04_verify`.
+- Record UI structure changes in `sdd/03_build` and `03_verify`.

package/.claude/agents/test-dev.md

@@ -22,5 +22,5 @@ Focus:
 
 Rules:
 - Verify direct, upstream, downstream, and shared surfaces when applicable.
-- Keep validation evidence in `sdd/04_verify`.
+- Keep validation evidence in `sdd/03_verify`.
 - Treat missing automation as a documented gap, not a silent skip.

package/.claude/skills/sdd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sdd
-description: "Use for any software development request in a repository that treats `sdd/` as the canonical delivery system. Trigger on requests like develop, implement, build, code, work on, modify, fix, patch, refactor, test, verify, deploy, monitor, or screen/UI-driven prompts such as 화면명세서, 화면설계서, 화면 설계, 화면, 화면 스펙, UI, 디자인, 디자인 가이드, screen spec, screen design, or design guide. The workflow is always SDD-first: inspect and update `sdd/01_planning`, create or update the task plan under `sdd/02_plan`, implement the change, record execution in `sdd/03_build`, capture validation in `sdd/04_verify`, and record deployment or monitoring in `sdd/05_operate` when rollout happens."
+description: "Use for any software development request in a repository that treats `sdd/` as the canonical delivery system. Trigger on requests like develop, implement, build, code, work on, modify, fix, patch, refactor, test, verify, deploy, monitor, or screen/UI-driven prompts such as 화면명세서, 화면설계서, 화면 설계, 화면, 화면 스펙, UI, 디자인, 디자인 가이드, screen spec, screen design, or design guide. The workflow is always SDD-first: inspect and update `sdd/01_planning`, create or update the task plan under `sdd/02_plan`, implement the change, record execution in `sdd/03_build`, capture validation in `sdd/03_verify`, and record deployment or monitoring in `sdd/05_operate` when rollout happens."
 ---
 
 # SDD Development
@@ -14,7 +14,7 @@ This skill enforces one workflow:
 2. create or update the task plan under `sdd/02_plan/<section>/`,
 3. perform the code work,
 4. record the current implementation summary in `sdd/03_build`,
-5. record the current retained verification summary in `sdd/04_verify`,
+5. record the current retained verification summary in `sdd/03_verify`,
 6. record deployment and monitoring outcomes in `sdd/05_operate` when rollout happens.
 
 When rollout is explicitly in scope, and the repository has separate DEV and PROD environments, this skill enforces a staged release rule: deploy to DEV first, complete the retained full-layer validation surface there, promote to PROD only after DEV passes, then rerun the same retained validation surface in PROD. If PROD validation fails, rollback is required unless the user explicitly redirects and that risk is recorded.
@@ -24,14 +24,14 @@ Read [references/section-map.md](references/section-map.md) when you need the ex
 For screen-spec-driven UI work, reusable static assets from the spec must be extracted through the repo's canonical asset builder before being used in code.
 For screen-spec-driven layout work, inspect the repo's canonical design guide builder first when one exists.
 For local screen exactness, treat the repo's Playwright exactness runner and suite registry as the canonical automation gate when they exist.
-For verification work, treat regression scope selection as a required retained artifact and carry it through `sdd/02_plan`, `sdd/03_build`, and `sdd/04_verify`.
+For verification work, treat regression scope selection as a required retained artifact and carry it through `sdd/02_plan`, `sdd/03_build`, and `sdd/03_verify`.
 Do not infer rollout scope from the existence of `sdd/05_operate` alone; require rollout only when the user asks for deployment or the repo's current policy/plan makes rollout part of completion.
 When a repo or team treats DEV deployment from `main` as the completion bar, temporary branches or worktrees are only working space. Before calling the task deployed, land the final retained change on `main` and push `origin/main`.
 
 ## When To Use
 
 Use this skill when:
-- the repository has `sdd/01_planning`, `02_plan`, `03_build`, `04_verify`, `05_operate`,
+- the repository has `sdd/01_planning`, `02_plan`, `03_build`, `03_verify`, `05_operate`,
 - the user gives a development instruction such as `개발해`, `작업해`, `구현해`, `수정해`, `고쳐`, `리팩토링해`, `테스트해`, `배포해`,
 - the user asks for screen/UI work with prompts such as `화면명세서`, `화면설계서`, `화면 설계`, `화면`, `화면 스펙`, `UI`, `디자인`, `디자인 가이드`, `screen spec`, `screen design`, or `design guide`,
 - the user wants work to be traceable through those folders,
@@ -91,7 +91,7 @@ Do not use this skill for:
   - Reusable asset planning records belong under `sdd/01_planning/02_screen/assets/`.
   - Build the runtime asset from the approved PDF/image source instead of hand-tracing or screenshot-cropping it.
   - Use exact verification such as `--verify-exact` when the asset is expected to match the source crop exactly.
-  - Record the source, manifest, generated asset path, and any exception in `sdd/03_build` and `sdd/04_verify`.
+  - Record the source, manifest, generated asset path, and any exception in `sdd/03_build` and `sdd/03_verify`.
   - Only fall back to manual recreation when the builder cannot express the asset, and explicitly document that exception in the plan/build/verify trail.
 - When the task depends on spacing, layout density, typography, color rhythm, or component hierarchy derived from a screen spec, inspect the repo's canonical design guide builder first.
   - In repos created from this template, inspect `sdd/99_toolchain/01_automation/README.md` and use the actual builder, wrapper, or manifest that exists in the repo.
@@ -117,11 +117,11 @@ Do not use this skill for:
 
 ### 5. Record Verification
 
-- Record retained verification status in `sdd/04_verify`.
+- Record retained verification status in `sdd/03_verify`.
 - Use:
-  - `04_verify/01_feature` for feature verification summaries
-  - `04_verify/02_screen` for screen verification summaries
-  - `04_verify/03_architecture`, `06_iac`, `10_test` for current retained checks and residual risk
+  - `03_verify/01_feature` for feature verification summaries
+  - `03_verify/02_screen` for screen verification summaries
+  - `03_verify/03_architecture`, `06_iac`, `10_test` for current retained checks and residual risk
 - Never claim completion without command-level validation evidence.
 - For staged DEV -> PROD rollout, verification must use the same retained full-layer validation surface in both environments.
   - Run the full-layer validation in DEV after deployment and treat it as a hard gate before PROD promotion.

package/.claude/skills/sdd/references/section-map.md

@@ -43,15 +43,15 @@
 
 ## Verify
 
-- `sdd/04_verify/01_feature`
+- `sdd/03_verify/01_feature`
   - feature verification summaries
-- `sdd/04_verify/02_screen`
+- `sdd/03_verify/02_screen`
   - screen verification summaries
-- `sdd/04_verify/03_architecture`
+- `sdd/03_verify/03_architecture`
   - governance and structure verification summaries
-- `sdd/04_verify/06_iac`
+- `sdd/03_verify/06_iac`
   - delivery/runtime verification summaries
-- `sdd/04_verify/10_test`
+- `sdd/03_verify/10_test`
   - current harness outputs and retained validation references
 
 ## Operate

package/.codex/skills/sdd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sdd
-description: "Use for any software development request in a repository that treats `sdd/` as the canonical delivery system. Trigger on requests like develop, implement, build, code, work on, modify, fix, patch, refactor, test, verify, deploy, monitor, or screen/UI-driven prompts such as 화면명세서, 화면설계서, 화면 설계, 화면, 화면 스펙, UI, 디자인, 디자인 가이드, screen spec, screen design, or design guide. The workflow is always SDD-first: inspect and update `sdd/01_planning`, create or update the task plan under `sdd/02_plan`, implement the change, record execution in `sdd/03_build`, capture validation in `sdd/04_verify`, and record deployment or monitoring in `sdd/05_operate` when rollout happens."
+description: "Use for any software development request in a repository that treats `sdd/` as the canonical delivery system. Trigger on requests like develop, implement, build, code, work on, modify, fix, patch, refactor, test, verify, deploy, monitor, or screen/UI-driven prompts such as 화면명세서, 화면설계서, 화면 설계, 화면, 화면 스펙, UI, 디자인, 디자인 가이드, screen spec, screen design, or design guide. The workflow is always SDD-first: inspect and update `sdd/01_planning`, create or update the task plan under `sdd/02_plan`, implement the change, record execution in `sdd/03_build`, capture validation in `sdd/03_verify`, and record deployment or monitoring in `sdd/05_operate` when rollout happens."
 ---
 
 # SDD Development
@@ -14,7 +14,7 @@ This skill enforces one workflow:
 2. create or update the task plan under `sdd/02_plan/<section>/`,
 3. perform the code work,
 4. record the current implementation summary in `sdd/03_build`,
-5. record the current retained verification summary in `sdd/04_verify`,
+5. record the current retained verification summary in `sdd/03_verify`,
 6. record deployment and monitoring outcomes in `sdd/05_operate` when rollout happens.
 
 When rollout is explicitly in scope, and the repository has separate DEV and PROD environments, this skill enforces a staged release rule: deploy to DEV first, complete the retained full-layer validation surface there, promote to PROD only after DEV passes, then rerun the same retained validation surface in PROD. If PROD validation fails, rollback is required unless the user explicitly redirects and that risk is recorded.
@@ -24,14 +24,14 @@ Read [references/section-map.md](references/section-map.md) when you need the ex
 For screen-spec-driven UI work, reusable static assets from the spec must be extracted through the repo's canonical asset builder before being used in code.
 For screen-spec-driven layout work, inspect the repo's canonical design guide builder first when one exists.
 For local screen exactness, treat the repo's Playwright exactness runner and suite registry as the canonical automation gate when they exist.
-For verification work, treat regression scope selection as a required retained artifact and carry it through `sdd/02_plan`, `sdd/03_build`, and `sdd/04_verify`.
+For verification work, treat regression scope selection as a required retained artifact and carry it through `sdd/02_plan`, `sdd/03_build`, and `sdd/03_verify`.
 Do not infer rollout scope from the existence of `sdd/05_operate` alone; require rollout only when the user asks for deployment or the repo's current policy/plan makes rollout part of completion.
 When a repo or team treats DEV deployment from `main` as the completion bar, temporary branches or worktrees are only working space. Before calling the task deployed, land the final retained change on `main` and push `origin/main`.
 
 ## When To Use
 
 Use this skill when:
-- the repository has `sdd/01_planning`, `02_plan`, `03_build`, `04_verify`, `05_operate`,
+- the repository has `sdd/01_planning`, `02_plan`, `03_build`, `03_verify`, `05_operate`,
 - the user gives a development instruction such as `개발해`, `작업해`, `구현해`, `수정해`, `고쳐`, `리팩토링해`, `테스트해`, `배포해`,
 - the user asks for screen/UI work with prompts such as `화면명세서`, `화면설계서`, `화면 설계`, `화면`, `화면 스펙`, `UI`, `디자인`, `디자인 가이드`, `screen spec`, `screen design`, or `design guide`,
 - the user wants work to be traceable through those folders,
@@ -91,7 +91,7 @@ Do not use this skill for:
   - Reusable asset planning records belong under `sdd/01_planning/02_screen/assets/`.
   - Build the runtime asset from the approved PDF/image source instead of hand-tracing or screenshot-cropping it.
   - Use exact verification such as `--verify-exact` when the asset is expected to match the source crop exactly.
-  - Record the source, manifest, generated asset path, and any exception in `sdd/03_build` and `sdd/04_verify`.
+  - Record the source, manifest, generated asset path, and any exception in `sdd/03_build` and `sdd/03_verify`.
   - Only fall back to manual recreation when the builder cannot express the asset, and explicitly document that exception in the plan/build/verify trail.
 - When the task depends on spacing, layout density, typography, color rhythm, or component hierarchy derived from a screen spec, inspect the repo's canonical design guide builder first.
   - In repos created from this template, inspect `sdd/99_toolchain/01_automation/README.md` and use the actual builder, wrapper, or manifest that exists in the repo.
@@ -117,11 +117,11 @@ Do not use this skill for:
 
 ### 5. Record Verification
 
-- Record retained verification status in `sdd/04_verify`.
+- Record retained verification status in `sdd/03_verify`.
 - Use:
-  - `04_verify/01_feature` for feature verification summaries
-  - `04_verify/02_screen` for screen verification summaries
-  - `04_verify/03_architecture`, `06_iac`, `10_test` for current retained checks and residual risk
+  - `03_verify/01_feature` for feature verification summaries
+  - `03_verify/02_screen` for screen verification summaries
+  - `03_verify/03_architecture`, `06_iac`, `10_test` for current retained checks and residual risk
 - Never claim completion without command-level validation evidence.
 - For staged DEV -> PROD rollout, verification must use the same retained full-layer validation surface in both environments.
   - Run the full-layer validation in DEV after deployment and treat it as a hard gate before PROD promotion.

package/.codex/skills/sdd/references/section-map.md

@@ -43,15 +43,15 @@
 
 ## Verify
 
-- `sdd/04_verify/01_feature`
+- `sdd/03_verify/01_feature`
   - feature verification summaries
-- `sdd/04_verify/02_screen`
+- `sdd/03_verify/02_screen`
   - screen verification summaries
-- `sdd/04_verify/03_architecture`
+- `sdd/03_verify/03_architecture`
   - governance and structure verification summaries
-- `sdd/04_verify/06_iac`
+- `sdd/03_verify/06_iac`
   - delivery/runtime verification summaries
-- `sdd/04_verify/10_test`
+- `sdd/03_verify/10_test`
   - current harness outputs and retained validation references
 
 ## Operate

package/.env.example

@@ -1,6 +1,6 @@
 SERVER_HTTP_PORT=8000
 CLIENT_LANDING_PORT=3000
-CLIENT_PLATFORM_PORT=3001
+CLIENT_WEB_PORT=3001
 CLIENT_MOBILE_PORT=3002
 CLIENT_ADMIN_PORT=4000
 
@@ -44,7 +44,7 @@ SERVER_BOOTSTRAP_OPERATOR_NAME=Template Operator
 SERVER_CORS_ORIGINS=["http://localhost:3000","http://127.0.0.1:3000","http://localhost:3001","http://127.0.0.1:3001","http://localhost:3002","http://127.0.0.1:3002","http://localhost:4000","http://127.0.0.1:4000"]
 
 CLIENT_LANDING_VITE_API_BASE_URL=http://127.0.0.1:8000/api/v1
-CLIENT_PLATFORM_VITE_API_BASE_URL=http://127.0.0.1:8000/api/v1
+CLIENT_WEB_VITE_API_BASE_URL=http://127.0.0.1:8000/api/v1
 CLIENT_MOBILE_VITE_API_BASE_URL=http://127.0.0.1:8000/api/v1
 CLIENT_ADMIN_VITE_API_BASE_URL=http://127.0.0.1:8000/api/v1
 CLIENT_WATCH_USE_POLLING=false

package/AGENTS.md

@@ -11,7 +11,7 @@
 - 회귀 검수 범위는 `sdd/02_plan/10_test/regression_verification.md` 기준으로 direct, upstream, downstream, shared surface까지 선택한다.
 - Playwright exactness suite가 있는 UI surface는 `sdd/99_toolchain/01_automation/run_playwright_exactness.py`를 canonical local gate로 사용한다.
 - shared route, shell, auth/session, component, data contract, generated asset, builder output 변경은 adjacent consumer까지 검수 범위를 넓힌다.
-- 선택한 회귀 범위, 생략 사유, residual risk는 `sdd/02_plan`, `sdd/03_build`, `sdd/04_verify`에 current-state로 남긴다.
+- 선택한 회귀 범위, 생략 사유, residual risk는 `sdd/02_plan`, `sdd/03_build`, `sdd/03_verify`에 current-state로 남긴다.
 
 ## Branch And Deploy Policy
 
@@ -57,8 +57,8 @@
 
 ## SDD Verify Governance
 
-- `sdd/04_verify`는 feature/screen/architecture/IAC/test별 current verification summary만 유지한다.
-- screen verification summary는 `sdd/04_verify/02_screen/<service>/` 아래 screen-specific 파일로 유지한다.
+- `sdd/03_verify`는 feature/screen/architecture/IAC/test별 current verification summary만 유지한다.
+- screen verification summary는 `sdd/03_verify/02_screen/<service>/` 아래 screen-specific 파일로 유지한다.
 - dated gate result나 test evidence log는 남기지 않는다.
 
 ## SDD Operate Governance
@@ -75,4 +75,4 @@
 - `sdd/03_build`는 실행 이력 요약이 아니라 runtime assembly current-state 문서다.
 - service/screen build summary는 `entry -> provider/router -> auth/session gate -> shell -> route leaf -> backend contract leaf` 순서를 우선 유지한다.
 - `sdd/03_build`에는 dated history, Ralph iteration narrative, run id memo를 남기지 않는다.
-- AST 기반 current-state 적합성은 `scripts/dev/audit_sdd_build_ast.py`와 `sdd/04_verify/03_architecture/build_ast_runtime_tree_governance.md`를 기준으로 관리한다.
+- AST 기반 current-state 적합성은 `scripts/dev/audit_sdd_build_ast.py`와 `sdd/03_verify/03_architecture/build_ast_runtime_tree_governance.md`를 기준으로 관리한다.

package/README.md

@@ -5,7 +5,7 @@
 포함 템플릿:
 
 - [landing](./client/landing): 마케팅/브랜드 랜딩 패턴
-- [platform](./client/platform): 일반 제품형 플랫폼 앱 shell, dashboard/list/detail 패턴
+- [web](./client/web): 일반 제품형 웹 앱 shell, dashboard/list/detail 패턴
 - [mobile](./client/mobile): 다국어/현장 업무형 모바일 IN workspace 패턴
 - [admin](./client/admin): 운영 콘솔형 shell, sidebar/topbar/drawer/table 패턴
 - [server](./server): HTTP 기반 hexagonal/DDD 서버 패턴
@@ -17,7 +17,7 @@
 - 제품 DOM은 유지하고, 스타일 조정값은 `theme.ts` + CSS custom properties로 노출
 - proof/spec 전용 DOM 복제 대신 fixture data + parameter surface로 정렬
 - `server`는 hexagonal architecture 기준으로 `contracts + application + domain + infrastructure`를 사용
-- `landing`, `platform`, `mobile`, `admin`은 실제 `/api/v1/auth/login`과 `/api/v1/auth/me`를 사용하는 기준 템플릿이다.
+- `landing`, `web`, `mobile`, `admin`은 실제 `/api/v1/auth/login`과 `/api/v1/auth/me`를 사용하는 기준 템플릿이다.
 - runtime baseline은 루트 `compose.yml`을 기준으로 유지하고, 여기서 4개 frontend surface, `server`, 기본 `postgres`, optional DB profile을 함께 올린다.
 - agentic baseline은 `.claude`, `.codex`, `.agent`를 함께 유지하고 downstream repo가 role agent, skill alias, Ralph harness를 그대로 가져가도록 설계한다.
 - `sdd/03_build`는 단순 구현 목록이 아니라 실제 runtime assembly를 따라 읽는 AST-style current-state 설명을 기준으로 유지한다.
@@ -27,6 +27,7 @@ SDD / delivery 원칙:
 - 설계, 계획, 구현, 검증, 운영 문서는 모두 `sdd/`가 canonical root다.
 - `sdd/`는 history 누적이 아니라 current-state durable 문서만 유지한다.
 - `02_plan`은 에이전트의 현재 개발 계획을 관리하고, feature는 `<domain>_todos.md`, screen은 `<service>_todos.md`로 유지한다.
+- retained verification summary는 `sdd/03_verify`를 canonical root로 사용한다.
 - 템플릿 runtime baseline은 root `compose.yml` dev-focused stack이고, dedicated host용 DEV(개발계)/PROD compose overlay는 `infra/compose/`에 둔다.
 - current canonical delivery split은 `AWS edge/domain -> OpenStack backend compute -> AWS data plane`이다.
 - DEV(개발계) 반영이 필요한 작업은 `build -> main push -> DEV deploy -> DEV verify` 순서를 기본으로 사용한다.
@@ -42,20 +43,52 @@ SDD / delivery 원칙:
 설치형 scaffold:
 
 ```bash
-npx agentic-dev init my-app --template platform
-cd my-app
-cp .env.example .env
-npm install -g pnpm
-pnpm install
-cd client/platform
-npm run ui:parity:bootstrap
+npx agentic-dev
+```
+
+또는 비대화형으로:
+
+```bash
+npx agentic-dev init my-app --template template-web
+npx agentic-dev init my-app --template template-web --skip-bootstrap
 ```
 
+설치 프로세스:
+
+1. `npx agentic-dev` 또는 `npx agentic-dev init <dir>`
+   - 프로젝트 디렉터리를 입력받는다.
+2. 공개 `say828/template-*` 레포 목록에서 템플릿을 선택한다.
+   - repo name 또는 숫자 선택을 모두 지원한다.
+3. 선택한 template repo를 새 폴더로 clone/copy 한다.
+   - `template-*` 패턴이 아닌 값은 거부한다.
+4. `.env.example`이 있으면 `.env`를 자동 생성한다.
+5. `pnpm install`과 `pnpm exec playwright install chromium`을 자동 실행한다.
+6. `npm run ui:parity:bootstrap`을 자동 실행한다.
+   - `--skip-bootstrap`을 주면 이 단계만 건너뛴다.
+
 CLI가 하는 일:
 
-- 선택한 frontend template 하나를 `client/<template>`로 설치
-- `server`, `.claude`, `.codex`, `.agent`, `sdd`, `infra`, `scripts`를 함께 설치
-- 선택한 template에 맞게 `compose.yml`, `pnpm-workspace.yaml`, `repo-contract.json`을 정렬
+- 공개 `say828/template-*` 레포를 GitHub API로 조회한다.
+- 사용자 입력을 받아 template repo를 선택한다.
+- 선택된 repo를 target directory에 설치하고 `.env`, dependencies, Chromium, bootstrap까지 자동 처리한다.
+- invalid repo name이나 `template-*`가 아닌 값은 즉시 거부한다.
+- `--skip-bootstrap`을 주면 설치까지만 하고 bootstrap은 멈춘다.
+
+Parity 명령:
+
+- `npm run ui:parity:init`
+  - repo contract alias, parity contract, route-gap 산출물을 초기화한다.
+- `npm run ui:parity:bootstrap`
+  - `init -> build -> preview -> materialize reference -> plan_audit gate -> proof gate`를 한 번에 실행한다.
+- `npm run ui:parity:proof`
+  - 기존 parity contract를 기준으로 proof만 다시 실행한다.
+
+주요 parity 산출물:
+
+- contract: `sdd/02_plan/10_test/templates/ui_parity_web_contract.yaml`
+- route-gap report: `sdd/02_plan/99_generated/from_planning/ui_parity/`
+- verification summary: `sdd/03_verify/10_test/ui_parity/`
+- preview log: `sdd/03_verify/10_test/ui_parity/web-preview.log`
 
 GitHub token 운영:
 
@@ -74,7 +107,7 @@ docker compose up --build
 기본 compose 포트:
 
 - `client/landing`: `3000`
-- `client/platform`: `3001`
+- `client/web`: `3001`
 - `client/mobile`: `3002`
 - `client/admin`: `4000`
 - `server/http`: `8000`
@@ -96,7 +129,7 @@ DB adapter 전환:
 Agentic baseline:
 
 - `.claude/agents/`: Claude role agent prompt surface
-- `.claude/skills/sdd`, `.claude/skills/sdd-development`: SDD skill surface
-- `.codex/skills/SKILL.md`: OTRO root alias
+- `.claude/skills/sdd`: Claude SDD canonical skill
+- `.codex/skills/SKILL.md`: Codex root skill index
 - `.codex/skills/sdd/`: Codex SDD canonical skill
 - `.agent/ralph.sh`, `.agent/ralph-supervisor.sh`: bounded Ralph loop runner

package/SDD_SKILL.md

@@ -21,7 +21,7 @@
 - 요구사항과 설계는 `sdd/01_planning`에서 확인한다.
 - 지금 당장 수행 중인 작업 계획은 `sdd/02_plan`에 적는다.
 - 실제 구현 결과는 `sdd/03_build`에 남긴다.
-- 검증 근거와 residual risk는 `sdd/04_verify`에 남긴다.
+- 검증 근거와 residual risk는 `sdd/03_verify`에 남긴다.
 - 실제 배포와 운영 결과가 있었을 때만 `sdd/05_operate`를 갱신한다.
 
 즉, 이 스킬의 핵심은 "코드 변경" 자체가 아니라 "코드 변경을 설명하고 검증 가능한 current-state trail"을 같이 만드는 것이다.
@@ -30,7 +30,7 @@
 
 다음 조건이면 기본적으로 `sdd` 스킬 대상이다.
 
-- 저장소가 `sdd/01_planning`, `02_plan`, `03_build`, `04_verify`, `05_operate` 구조를 사용한다.
+- 저장소가 `sdd/01_planning`, `02_plan`, `03_build`, `03_verify`, `05_operate` 구조를 사용한다.
 - 사용자가 구현, 수정, 리팩토링, 테스트, 배포, 화면 작업처럼 실제 개발 지시를 한다.
 - 결과물이 코드 변경만으로 끝나면 안 되고, durable plan/build/verify 기록이 남아야 한다.
 
@@ -150,7 +150,7 @@
 
 ### 5. Verify 기록
 
-`sdd/04_verify`는 단순히 "테스트 통과"를 적는 곳이 아니다. 어떤 검증을 했는지, 어떤 범위를 확인했는지, 무엇이 아직 residual risk인지 명확하게 남겨야 한다.
+`sdd/03_verify`는 단순히 "테스트 통과"를 적는 곳이 아니다. 어떤 검증을 했는지, 어떤 범위를 확인했는지, 무엇이 아직 residual risk인지 명확하게 남겨야 한다.
 
 중요한 검증 규칙은 다음과 같다.
 
@@ -259,7 +259,7 @@
 
 이 폴더의 역할은 "지금 구현이 어떤 상태인가"를 설명하는 것이다.
 
-### `sdd/04_verify`
+### `sdd/03_verify`
 
 검증 근거와 residual risk를 current-state로 남긴다.
 
@@ -297,7 +297,7 @@ section map은 단순 참고표가 아니라 "이번 작업이 어디에 기록
 예를 들면 다음과 같다.
 
 - 기능 요구사항이 바뀌면 `01_planning/01_feature`와 `02_plan/01_feature`를 본다.
-- 화면 정렬이 핵심이면 `01_planning/02_screen`, `02_plan/02_screen`, `03_build/02_screen`, `04_verify/02_screen` 축으로 간다.
+- 화면 정렬이 핵심이면 `01_planning/02_screen`, `02_plan/02_screen`, `03_build/02_screen`, `03_verify/02_screen` 축으로 간다.
 - shared governance나 skill rule 정리는 `03_architecture` 축으로 간다.
 - schema/API/integration 변화가 크면 data/api/integration planning과 verify를 함께 본다.
 - rollout이 실제 범위면 `05_operate`까지 completion trail에 들어온다.
@@ -479,7 +479,7 @@ rollout이 범위일 때 보통 필요한 것은 다음이다.
 - 관련 planning을 확인했음
 - `sdd/02_plan`이 현재 작업 기준으로 갱신됨
 - `sdd/03_build`가 구현 결과를 설명함
-- `sdd/04_verify`가 검증 근거와 residual risk를 설명함
+- `sdd/03_verify`가 검증 근거와 residual risk를 설명함
 - rollout이 실제로 있었다면 `sdd/05_operate`도 갱신됨
 
 추가로 아래 조건이 붙을 수 있다.
@@ -508,7 +508,7 @@ rollout이 범위일 때 보통 필요한 것은 다음이다.
 - asset recipe wrapper: `sdd/99_toolchain/01_automation/build_asset_recipes.py`
 - screen spec generator: `sdd/99_toolchain/01_automation/build_screen_spec_pdf.py`
 - capture tooling: `sdd/99_toolchain/01_automation/capture_screen_assets.mjs`
-- verification harness baseline: `sdd/04_verify/10_test/verification_harness.md`
+- verification harness baseline: `sdd/03_verify/10_test/verification_harness.md`
 - verification strategy baseline: `sdd/02_plan/10_test/verification_strategy.md`
 - regression scope baseline: `sdd/02_plan/10_test/regression_verification.md`
 

package/bin/agentic-dev.mjs

@@ -4,17 +4,19 @@ import process from "node:process";
 import { createInterface } from "node:readline/promises";
 import {
   ensureTargetDir,
-  listTemplates,
+  fetchTemplateRepos,
+  installTemplateRepo,
   parseArgs,
-  scaffoldTemplate,
+  resolveTemplateRepo,
+  selectTemplateRepo,
   usage,
-  validateTemplate,
 } from "../lib/scaffold.mjs";
 
-async function promptForMissing(options) {
+async function promptForMissing(options, repos) {
   if (options.yes && (!options.targetDir || !options.template)) {
-    throw new Error("`--yes` requires both target directory and template.");
+    throw new Error("`--yes` requires both target directory and template repo.");
   }
+
   if (options.targetDir && options.template) {
     return options;
   }
@@ -25,12 +27,31 @@ async function promptForMissing(options) {
   });
 
   try {
-    if (!options.targetDir) {
-      options.targetDir = (await rl.question("Target directory: ")).trim();
+    while (!options.targetDir) {
+      const answer = await rl.question("Project directory: ");
+      options.targetDir = answer.trim();
+      if (!options.targetDir) {
+        console.log("Project directory cannot be empty.");
+      }
     }
+
     if (!options.template) {
-      const templates = listTemplates().join(", ");
-      options.template = (await rl.question(`Template (${templates}): `)).trim();
+      console.log("");
+      console.log(`Public template repos from ${options.owner}:`);
+      repos.forEach((repo, index) => {
+        const summary = repo.description ? ` - ${repo.description}` : "";
+        console.log(`  ${index + 1}. ${repo.name}${summary}`);
+      });
+      console.log("");
+      while (!options.template) {
+        const answer = await rl.question("Select template repo (number or repo name): ");
+        try {
+          options.template = selectTemplateRepo(answer, repos).name;
+        } catch (error) {
+          console.log(error.message);
+          options.template = "";
+        }
+      }
     }
   } finally {
     rl.close();
@@ -40,12 +61,20 @@ async function promptForMissing(options) {
 }
 
 function printSuccess(result) {
-  console.log(`Scaffolded agentic-dev template: ${result.template}`);
-  console.log(`Destination: ${result.destinationRoot}`);
   console.log("");
-  console.log("Next steps:");
-  for (const step of result.nextSteps) {
-    console.log(`  ${step}`);
+  console.log(`Initialized template repo: ${result.templateRepo}`);
+  console.log(`Destination: ${result.destinationRoot}`);
+  if (result.executedSteps.length > 0) {
+    console.log("Completed:");
+    for (const step of result.executedSteps) {
+      console.log(`  ${step}`);
+    }
+  }
+  if (result.nextSteps.length > 0) {
+    console.log("Next steps:");
+    for (const step of result.nextSteps) {
+      console.log(`  ${step}`);
+    }
   }
 }
 
@@ -80,12 +109,18 @@ async function main() {
   }
 
   try {
-    options = await promptForMissing(options);
-    validateTemplate(options.template);
+    const repos = await fetchTemplateRepos({ owner: options.owner });
+    if (repos.length === 0) {
+      throw new Error(`No public template-* repos found for ${options.owner}.`);
+    }
+
+    options = await promptForMissing(options, repos);
+    const selectedRepo = resolveTemplateRepo(options.template, repos);
     const destinationRoot = ensureTargetDir(options.targetDir, { force: options.force });
-    const result = scaffoldTemplate({
+    const result = installTemplateRepo({
       destinationRoot: path.resolve(destinationRoot),
-      template: options.template,
+      templateRepo: selectedRepo,
+      skipBootstrap: options.skipBootstrap,
     });
     printSuccess(result);
   } catch (error) {

package/client/admin/scripts/ui-parity-admin-adapter.mjs

@@ -23,7 +23,7 @@ export default {
     id: screen.id,
     title: screen.title,
     route: routeMap.get(screen.id) ?? "/",
-    referenceImage: `sdd/04_verify/10_test/ui_parity/reference/${screen.id}.png`,
+    referenceImage: `sdd/03_verify/10_test/ui_parity/reference/${screen.id}.png`,
     readySelector: "body",
     readyTimeoutMs: 10000,
     tags: ["template", "admin"],

package/client/landing/scripts/ui-parity-landing-adapter.mjs

@@ -23,7 +23,7 @@ export default {
     id: screen.id,
     title: screen.title,
     route: routeMap.get(screen.id) ?? "/",
-    referenceImage: `sdd/04_verify/10_test/ui_parity/reference/${screen.id}.png`,
+    referenceImage: `sdd/03_verify/10_test/ui_parity/reference/${screen.id}.png`,
     readySelector: "body",
     readyTimeoutMs: 10000,
     tags: ["template", "landing"],

package/client/mobile/scripts/ui-parity-mobile-adapter.mjs

@@ -23,7 +23,7 @@ export default {
     id: screen.id,
     title: screen.title,
     route: routeMap.get(screen.id) ?? "/",
-    referenceImage: `sdd/04_verify/10_test/ui_parity/reference/${screen.id}.png`,
+    referenceImage: `sdd/03_verify/10_test/ui_parity/reference/${screen.id}.png`,
     readySelector: "body",
     readyTimeoutMs: 10000,
     tags: ["template", "mobile"],

package/client/{platform → web}/Dockerfile

@@ -3,13 +3,13 @@ FROM node:20-slim
 WORKDIR /app
 
 COPY pnpm-lock.yaml pnpm-workspace.yaml ./
-COPY client/platform/package.json ./client/platform/package.json
+COPY client/web/package.json ./client/web/package.json
 
-RUN npm install -g pnpm@10.32.0 && pnpm install --filter @do4ai/client-platform-template...
+RUN npm install -g pnpm@10.32.0 && pnpm install --filter @do4ai/client-web-template...
 
 COPY . .
 
-WORKDIR /app/client/platform
+WORKDIR /app/client/web
 
 EXPOSE 3001
 

package/client/web/Dockerfile.dev

@@ -0,0 +1,18 @@
+FROM node:20-slim
+
+WORKDIR /app
+
+RUN npm install -g pnpm@10.32.0
+
+COPY pnpm-lock.yaml pnpm-workspace.yaml ./
+COPY client/web/package.json ./client/web/package.json
+
+RUN pnpm install --frozen-lockfile --filter @do4ai/client-web-template...
+
+COPY client/web ./client/web
+
+WORKDIR /app/client/web
+
+EXPOSE 3001
+
+CMD ["sh", "-lc", "pnpm exec vite --host 0.0.0.0 --port ${PORT:-3001}"]

package/client/{platform → web}/README.md

@@ -1,4 +1,4 @@
-# platform
+# web
 
 일반 사용자용 제품 앱 보일러플레이트다.
 
@@ -25,7 +25,7 @@ npm run dev
 npm run ui:parity:init
 ```
 
-이 단계는 repo-level contract, `ui_parity_platform_contract.yaml`, route-gap manifest를 생성한다.
+이 단계는 repo-level contract, `ui_parity_web_contract.yaml`, route-gap manifest를 생성한다.
 
 첫 proof 부트스트랩:
 
@@ -44,4 +44,4 @@ npm run ui:parity:route-gap
 npm run ui:parity:proof
 ```
 
-이 템플릿은 repo root의 `sdd/99_toolchain/01_automation` 도구를 사용하고, `client/platform/scripts/ui-parity-platform-adapter.mjs`는 앱별 adapter 예시다.
+이 템플릿은 repo root의 `sdd/99_toolchain/01_automation` 도구를 사용하고, `client/web/scripts/ui-parity-web-adapter.mjs`는 앱별 adapter 예시다.