agentic-dev 0.2.4 → 0.2.7

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/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,24 +14,25 @@ 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.
 For persistence-affecting work, this skill also enforces schema-parity verification. Always compare migration or model intent against the real DEV and PROD schema state for the affected database objects instead of assuming deployed reality matches the code.
+Unless the user explicitly forbids it, durable work is not complete at code-edit state. Finish with a coherent git commit, push the retained result to the configured remote, and if the repository ships an installable package or CLI, publish the new version and verify the registry reflects it.
 
 Read [references/section-map.md](references/section-map.md) when you need the exact destination inside `sdd/`.
 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 +92,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 +118,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.
@@ -155,6 +156,8 @@ Do not use this skill for:
 - Do not create or repopulate a parallel `docs/` tree when `sdd/` exists.
 - Do not skip planning review just because the code change looks small.
 - Do not leave build, verify, or operate evidence only in chat text when it should live in `sdd/`.
+- Do not stop after local edits when durable changes remain; commit and push are the default completion bar unless the user explicitly forbids them.
+- Do not leave a publishable package or CLI unpublished after changing shipped behavior or instructions unless the user explicitly forbids publish.
 - When PROD rollout is in scope, do not promote to PROD before the retained full-layer DEV validation surface has passed.
 - When PROD rollout is in scope, do not use a weaker PROD validation surface than the one that gated DEV unless the user explicitly approves and that risk is recorded.
 - When PROD rollout is in scope, do not stop at "PROD deployment succeeded"; post-deploy PROD validation is mandatory.
@@ -175,7 +178,9 @@ By the end of an implementation task, the expected trail is:
 - plan file updated,
 - build summary written,
 - verification summary written, including selected regression scope and residual risk,
-- operate status updated if rollout occurred.
+- operate status updated if rollout occurred,
+- coherent git commit created and pushed,
+- publishable package/CLI인 경우 registry publish and latest verification completed unless the user explicitly forbade it.
 
 When PROD rollout is in scope, the retained completion state also requires:
 - DEV deployment happened first and the retained full-layer DEV validation surface passed,

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,24 +14,25 @@ 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.
 For persistence-affecting work, this skill also enforces schema-parity verification. Always compare migration or model intent against the real DEV and PROD schema state for the affected database objects instead of assuming deployed reality matches the code.
+Unless the user explicitly forbids it, durable work is not complete at code-edit state. Finish with a coherent git commit, push the retained result to the configured remote, and if the repository ships an installable package or CLI, publish the new version and verify the registry reflects it.
 
 Read [references/section-map.md](references/section-map.md) when you need the exact destination inside `sdd/`.
 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 +92,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 +118,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.
@@ -155,6 +156,8 @@ Do not use this skill for:
 - Do not create or repopulate a parallel `docs/` tree when `sdd/` exists.
 - Do not skip planning review just because the code change looks small.
 - Do not leave build, verify, or operate evidence only in chat text when it should live in `sdd/`.
+- Do not stop after local edits when durable changes remain; commit and push are the default completion bar unless the user explicitly forbids them.
+- Do not leave a publishable package or CLI unpublished after changing shipped behavior or instructions unless the user explicitly forbids publish.
 - When PROD rollout is in scope, do not promote to PROD before the retained full-layer DEV validation surface has passed.
 - When PROD rollout is in scope, do not use a weaker PROD validation surface than the one that gated DEV unless the user explicitly approves and that risk is recorded.
 - When PROD rollout is in scope, do not stop at "PROD deployment succeeded"; post-deploy PROD validation is mandatory.
@@ -175,7 +178,9 @@ By the end of an implementation task, the expected trail is:
 - plan file updated,
 - build summary written,
 - verification summary written, including selected regression scope and residual risk,
-- operate status updated if rollout occurred.
+- operate status updated if rollout occurred,
+- coherent git commit created and pushed,
+- publishable package/CLI인 경우 registry publish and latest verification completed unless the user explicitly forbade it.
 
 When PROD rollout is in scope, the retained completion state also requires:
 - DEV deployment happened first and the retained full-layer DEV validation surface passed,

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/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
 
@@ -25,6 +25,14 @@
 - 완료된 work branch는 관련 정합성 체크가 끝나고 변경이 `main`과 `origin/main`에 안전하게 반영된 뒤 local/remote branch를 모두 삭제한다. 사용자가 branch 유지를 명시한 경우만 예외다.
 - branch retire 전 최소 정합성 체크는 `관련 canonical 검증 명령 재실행`, `worktree clean 확인`, `최종 변경의 main 포함 여부 확인`이다.
 
+## Completion And Release Policy
+
+- 사용자가 명시적으로 금지하지 않는 한, durable 변경이 남은 agent 작업은 `commit -> push -> publish 가능한 패키지/CLI는 publish`까지 끝나야 완료로 간주한다.
+- "설명만 하고 종료", "로컬 수정만 남기고 종료", "커밋 없이 종료", "원격 미반영 상태로 종료"는 기본 완료 상태가 아니다.
+- npm package, 설치형 CLI, 배포 artifact처럼 사용자가 즉시 받는 deliverable을 가진 저장소는 변경 후 새 버전을 발행하고 registry 배포까지 확인한다.
+- publish 가능한 저장소에서 publish를 생략할 수 있는 예외는 사용자가 그 turn에서 명시적으로 금지한 경우뿐이다.
+- 완료 보고 전 최소 확인 항목은 `coherent commit 존재`, `원격 push 완료`, `publish 대상이면 registry 최신 반영 확인`이다.
+
 ## Runtime Naming Policy
 
 - 문서/대화/로그에서 실행 환경은 항상 `DEV(개발계)`로 표기한다.
@@ -57,8 +65,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 +83,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

@@ -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 web
-cd my-app
-cp .env.example .env
-npm install -g pnpm
-pnpm install
-cd client/web
-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 운영:
 
@@ -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/web/scripts/ui-parity-web-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", "web"],