agentic-dev 0.1.0 → 0.2.0

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

@@ -0,0 +1,184 @@
+---
+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."
+---
+
+# SDD Development
+
+## Overview
+
+Use this skill for implementation work in repositories that treat `sdd/` as the canonical delivery record.
+
+This skill enforces one workflow:
+1. inspect and fix relevant `sdd/01_planning` artifacts first,
+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`,
+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.
+
+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`.
+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 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,
+- the task includes both implementation and documentation/verification updates,
+- the task may end in deployment or operational follow-up.
+
+Do not use this skill for:
+- casual questions with no repo changes,
+- one-off local debugging where no durable SDD record is needed,
+- repositories that do not use `sdd/` as their primary document system.
+
+## Workflow
+
+### 1. Inspect Planning First
+
+- Identify the impacted planning area before editing code.
+- Open only the relevant artifacts in `sdd/01_planning`:
+  - feature
+  - screen
+  - architecture
+  - data
+  - api
+  - iac
+  - integration
+  - nonfunctional
+  - security
+  - test
+- If the implementation has already drifted from planning, update the planning artifact first or at least record the drift before coding.
+
+### 2. Create Or Update The Plan
+
+- Create or reuse a durable plan file under `sdd/02_plan/<section>/`.
+- Prefer the repo's planning scaffold if available.
+- The plan must include:
+  - scope
+  - assumptions
+  - acceptance criteria
+  - execution checklist
+  - current notes
+  - validation
+- For any task that may end in deployment, acceptance criteria must explicitly include the DEV gate, the matching PROD gate, the retained full-layer test surface, and the rollback trigger/path.
+- For any task that touches persistence, models, repositories, migrations, SQL, ORM mappings, or runtime failures that may involve schema drift, acceptance criteria must explicitly include DEV/PROD schema verification.
+- Keep exactly one checklist item in progress.
+
+### 3. Implement Against The Plan
+
+- Make code changes only after the impacted planning artifact and plan are aligned enough to proceed.
+- Update the plan current notes after meaningful edits or decisions.
+- When document generators or capture pipelines are involved, keep those tools under `sdd/99_toolchain`.
+- For local screen exactness, treat Playwright as the canonical automation gate unless the repo documents a stronger exact gate for that surface.
+  - In repos created from this template, prefer `python3 sdd/99_toolchain/01_automation/run_playwright_exactness.py --suite <suite-id>` over ad-hoc `npx playwright test ...`.
+  - Keep the suite registry in `sdd/99_toolchain/01_automation/playwright_exactness_manifest.py`.
+  - Browser Use, manual screenshots, or semantic extraction can supplement diagnosis, but they do not replace the retained Playwright exactness gate when a suite exists.
+  - If the needed suite does not exist yet, add or extend it in the same task and register it before calling the work complete.
+- When the task depends on icons, logos, illustrations, or other static assets visible in a screen spec, use the repo's canonical Asset Spec Builder first.
+  - In repos created from this template, this is typically `sdd/99_toolchain/01_automation/spec_asset_builder.py` or a wrapper/manifest around it.
+  - 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`.
+  - 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.
+  - Use the generated guide as the working baseline before manual spacing or palette tweaks.
+  - If the repo does not provide a design guide builder yet, document the manual interpretation source in plan/build/verify.
+- Define the regression surface before calling implementation complete.
+  - Start from `sdd/02_plan/10_test/regression_verification.md`.
+  - Identify the direct target plus any upstream, downstream, and shared surfaces affected by the change.
+  - If the change touches shared routing, shell/auth, shared state, common components, contracts, generated assets, or builder output, widen the regression scope instead of validating only the edited module.
+  - Record the selected regression scope and any justified exclusions in plan/build/verify.
+- When rollout is in scope, define one retained full-layer validation surface and reuse it in DEV and PROD.
+  - Include the relevant app/runtime entrypoints, API/contracts, persistence/schema, jobs or workflow side effects, shared integrations, and health/monitoring checks affected by the change.
+  - Do not promote to PROD with a narrower verification surface than the DEV gate unless the user explicitly approves that exception and it is recorded.
+
+### 4. Record Build Summary
+
+- Record what you implemented in `sdd/03_build`.
+- Use:
+  - `03_build/01_feature` for feature implementation summaries
+  - `03_build/02_screen` for screen implementation summaries
+  - `03_build/03_architecture`, `06_iac`, `10_test` for current-state cross-cutting summaries
+- Keep entries factual and current-state only: implemented scope, modules, assets, contracts, and current user-visible behavior.
+
+### 5. Record Verification
+
+- Record retained verification status in `sdd/04_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
+- 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.
+  - After PROD deployment, rerun the same retained validation surface in PROD.
+  - If PROD validation fails, execute rollback or the approved recovery procedure immediately and record the failure and recovery outcome.
+- For persistence-affecting work, verification must include real schema evidence from both DEV and PROD when those environments exist.
+  - Check migration state and actual runtime schema separately.
+  - Validate the tables, columns, indexes, constraints, triggers, defaults, and any legacy compatibility objects touched by the change.
+  - Record the commands or queries used, the environments checked, and the drift or parity result.
+- Regression verification is mandatory.
+  - Verification must cover the direct surface and the retained upstream/downstream/shared surfaces selected from the regression baseline.
+  - If no automation exists for a needed regression slice yet, run the best available manual or command checks and record that gap as current residual risk.
+  - When a Playwright suite exists for the surface, record the canonical runner command, suite id, screenshot/json artifact paths, and any live-vs-local split explicitly.
+
+### 6. Record Operate Outcomes
+
+- If deployment or runtime follow-up happens, update `sdd/05_operate`.
+- Use:
+  - `05_operate/01_runbooks` for durable operating procedure changes
+  - `05_operate/02_delivery_status` for the current live state and monitoring baseline
+- Record:
+  - what was deployed
+  - which live baseline is current
+  - how it is monitored
+  - any current residual risk
+- For staged DEV -> PROD rollout, record the DEV gate, PROD gate, and any rollback outcome explicitly.
+- When the DEV deployment baseline is tied to `main`, do not treat a side-branch push as sufficient. Merge, cherry-pick, or otherwise replay the final change onto `main`, push `origin/main`, then record the deployment evidence against that `main` baseline.
+
+## Guardrails
+
+- 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/`.
+- 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.
+- When PROD rollout is in scope, do not leave a failed PROD deployment unreconciled; rollback or the approved recovery procedure must be executed and recorded.
+- Do not assume local tests, migration heads, or current model code prove deployed schema parity.
+- Do not skip DEV/PROD schema inspection for persistence-affecting work when schema drift could influence behavior.
+- Do not manually redraw screen-spec static assets when a canonical Asset Spec Builder exists for the repo; extract them first and use the generated asset.
+- Do not skip a relevant screen automation builder just because the requested UI change looks like a small manual tweak.
+- Do not stop verification at the edited file, route, or screen when the change can affect shared or adjacent behavior.
+- Do not omit regression scope selection from the retained SDD trail.
+- Do not update `05_operate` for tasks that never reached deployment; explicitly note that rollout did not happen instead.
+- Do not call a DEV rollout complete from a temporary branch when the repo or team baseline expects the deployed change to be on `origin/main`.
+
+## Output Standard
+
+By the end of an implementation task, the expected trail is:
+- planning artifact reviewed or corrected,
+- plan file updated,
+- build summary written,
+- verification summary written, including selected regression scope and residual risk,
+- operate status updated if rollout occurred.
+
+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,
+- the same retained full-layer validation surface was executed again in PROD,
+- DEV/PROD schema state was checked and recorded when schema could influence behavior,
+- any PROD validation failure produced rollback or recovery evidence in verify/operate.

package/.codex/skills/sdd/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "SDD Development"
+  short_description: "Use SDD-first flow with schema parity, regression scope, and staged rollout gates"
+  default_prompt: "Use $sdd to handle this development task through sdd planning, build, verify, and operate, including regression scope selection, schema parity checks for persistence-affecting work, and staged DEV-first validation when multiple environments exist."

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

@@ -0,0 +1,67 @@
+# SDD Section Map
+
+## Planning
+
+- `sdd/01_planning/01_feature`
+  - domain or service feature specifications
+- `sdd/01_planning/02_screen`
+  - service-level screen specifications and PDFs
+- `sdd/01_planning/03_architecture`
+  - bounded context, runtime, and structural design
+- `sdd/01_planning/04_data`
+  - data model and relationship definitions
+- `sdd/01_planning/05_api`
+  - transport contracts and API definitions
+- `sdd/01_planning/06_iac`
+  - infrastructure planning and deployment design
+- `sdd/01_planning/07_integration`
+  - integration contracts and external dependency planning
+- `sdd/01_planning/08_nonfunctional`
+  - performance, reliability, scalability, and operational constraints
+- `sdd/01_planning/09_security`
+  - security posture, threat model, and control planning
+- `sdd/01_planning/10_test`
+  - test strategy and planned cases
+
+## Plan
+
+- `sdd/02_plan/<section>`
+  - executable plan files and migration backlogs
+
+## Build
+
+- `sdd/03_build/01_feature`
+  - feature implementation summaries
+- `sdd/03_build/02_screen`
+  - screen implementation summaries
+- `sdd/03_build/03_architecture`
+  - structural and governance implementation summaries
+- `sdd/03_build/06_iac`
+  - current delivery/runtime implementation summaries
+- `sdd/03_build/10_test`
+  - current harness and validation implementation summaries
+
+## Verify
+
+- `sdd/04_verify/01_feature`
+  - feature verification summaries
+- `sdd/04_verify/02_screen`
+  - screen verification summaries
+- `sdd/04_verify/03_architecture`
+  - governance and structure verification summaries
+- `sdd/04_verify/06_iac`
+  - delivery/runtime verification summaries
+- `sdd/04_verify/10_test`
+  - current harness outputs and retained validation references
+
+## Operate
+
+- `sdd/05_operate/01_runbooks`
+  - durable operating procedures
+- `sdd/05_operate/02_delivery_status`
+  - current live state, monitoring baseline, and residual risk
+
+## Tooling
+
+- `sdd/99_toolchain`
+  - generators, capture tooling, manifests, and other SDD automation

package/.dockerignore

@@ -0,0 +1,8 @@
+.git
+node_modules
+**/node_modules
+**/dist
+**/.venv
+**/__pycache__
+**/.pytest_cache
+**/*.tsbuildinfo

package/.env.example

@@ -0,0 +1,50 @@
+SERVER_HTTP_PORT=8000
+CLIENT_LANDING_PORT=3000
+CLIENT_PLATFORM_PORT=3001
+CLIENT_MOBILE_PORT=3002
+CLIENT_ADMIN_PORT=4000
+
+POSTGRES_PORT=5432
+POSTGRES_DB=template
+POSTGRES_USER=template
+POSTGRES_PASSWORD=template
+
+MYSQL_PORT=3306
+MYSQL_DATABASE=template
+MYSQL_USER=template
+MYSQL_PASSWORD=template
+MYSQL_ROOT_PASSWORD=template-root
+
+MARIADB_PORT=3307
+MARIADB_DATABASE=template
+MARIADB_USER=template
+MARIADB_PASSWORD=template
+MARIADB_ROOT_PASSWORD=template-root
+
+MONGO_PORT=27017
+
+SERVER_APP_NAME=Template Server
+SERVER_ENVIRONMENT=development
+SERVER_API_PREFIX=/api/v1
+SERVER_DATABASE_BACKEND=postgres
+SERVER_POSTGRES_URL=postgresql+psycopg://template:template@postgres:5432/template
+SERVER_MYSQL_URL=mysql+pymysql://template:template@mysql:3306/template
+SERVER_MARIADB_URL=mysql+pymysql://template:template@mariadb:3306/template
+SERVER_MONGODB_URL=mongodb://mongo:27017
+SERVER_MONGODB_DATABASE=template
+SERVER_JWT_SECRET=template-local-dev-secret
+SERVER_JWT_ALGORITHM=HS256
+SERVER_ACCESS_TOKEN_TTL_MINUTES=120
+SERVER_BOOTSTRAP_ADMIN_EMAIL=admin@example.com
+SERVER_BOOTSTRAP_ADMIN_PASSWORD=change-me-admin
+SERVER_BOOTSTRAP_ADMIN_NAME=Template Admin
+SERVER_BOOTSTRAP_OPERATOR_EMAIL=operator@example.com
+SERVER_BOOTSTRAP_OPERATOR_PASSWORD=change-me-operator
+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_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/.gitignore

@@ -0,0 +1,16 @@
+node_modules/
+dist/
+.DS_Store
+*.tsbuildinfo
+.venv/
+__pycache__/
+.pytest_cache/
+.terraform/
+.agent/runs/**
+!.agent/runs/
+!.agent/runs/README.md
+!.agent/sdd-build-ast-audit.json
+!.claude/settings.local.json
+.codex/skills/dev-browser/node_modules/
+.codex/skills/dev-browser/profiles/browser-data/
+.tmp-agentic-smoke/

package/AGENTS.md

@@ -0,0 +1,78 @@
+# AGENTS.md
+
+## Toolchain Convention Policy
+
+- 저장소 공통 컨벤션, 워크플로우, 실행 규약의 정본은 항상 `sdd/99_toolchain/02_policies`에 저장한다.
+- `AGENTS.md`는 핵심 실행 규칙과 우선순위만 요약하며, 상세 배경/예외/절차는 toolchain 정책 문서를 따른다.
+
+## Regression Verification Policy
+
+- `sdd` 성격의 작업은 edited target만 확인하고 종료하지 않는다.
+- 회귀 검수 범위는 `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로 남긴다.
+
+## Branch And Deploy Policy
+
+- 코드베이스 기본 개발 브랜치는 `main`이다.
+- 구현 작업은 기본적으로 task 성격에 맞는 work branch에서 시작한다.
+- work branch는 `feat/...`, `fix/...`, `refactor/...`, `docs/...`, `test/...`처럼 작업 surface가 드러나는 이름을 사용한다.
+- work branch의 변경은 원격 branch까지 먼저 push해 working integration baseline을 남긴다.
+- `main`이 아닌 branch에서 agent turn이 끝날 때 durable 변경이 남아 있으면 기본적으로 그 branch에 coherent commit을 만들고 origin branch까지 push한다. 예외는 worktree가 이미 clean이거나 사용자가 그 turn에 commit/push를 금지한 경우뿐이다.
+- `DEV(개발계)` 반영이 필요한 작업은 그 branch를 `main`에 반영하고 `origin/main`까지 push한 뒤 배포한다.
+- 수동 배포 단계여도 `branch push -> main merge/push -> DEV 배포 -> DEV 검증` 순서를 생략하지 않는다.
+- 완료된 work branch는 관련 정합성 체크가 끝나고 변경이 `main`과 `origin/main`에 안전하게 반영된 뒤 local/remote branch를 모두 삭제한다. 사용자가 branch 유지를 명시한 경우만 예외다.
+- branch retire 전 최소 정합성 체크는 `관련 canonical 검증 명령 재실행`, `worktree clean 확인`, `최종 변경의 main 포함 여부 확인`이다.
+
+## Runtime Naming Policy
+
+- 문서/대화/로그에서 실행 환경은 항상 `DEV(개발계)`로 표기한다.
+- `local`, `localhost 환경` 같은 표현은 운영 용어로 사용하지 않는다.
+
+## SDD Placement Rule
+
+- 이 저장소는 top-level `docs/` 트리를 사용하지 않는다.
+- design, planning, execution, verification, operate 문서는 모두 `sdd/` 아래에 둔다.
+- 모든 `sdd/` section은 overwrite-only current-state artifact다.
+- 날짜별 history, archive, release-log, gate-log 성 문서는 `sdd/` 안에 유지하지 않는다.
+- durable plan artifact는 항상 `sdd/02_plan/<section>/` 아래에 둔다.
+
+## SDD Plan Governance
+
+- `sdd/02_plan`은 dated or archived planning history를 두지 않는다.
+- `sdd/02_plan`은 에이전트의 현재 개발 계획을 기록하는 루트다.
+- feature, screen, architecture, data, API, IAC, integration, nonfunctional, security, test planning은 durable target-specific 문서를 직접 갱신한다.
+- feature plan 기본 경로는 `sdd/02_plan/01_feature/<domain>_todos.md`다.
+- screen plan 기본 경로는 `sdd/02_plan/02_screen/<service>_todos.md`다.
+- 개발계 반영이 필요한 작업은 `구현(branch) -> branch push -> build -> main merge/push -> DEV(개발계) 배포 -> DEV 검수 -> 문서 갱신 -> branch 삭제` 순서를 기본 루틴으로 사용한다.
+- 횡단 작업도 날짜 파일을 추가하지 않고 같은 section의 governance/backlog/current-plan 문서를 덮어쓴다.
+
+## SDD Build Governance
+
+- `sdd/03_build`는 `sdd/02_plan`의 top-level split을 따라 durable implementation summary를 유지한다.
+- feature summary는 service 또는 domain-sized category로 묶고, screen summary는 service split을 따른다.
+- screen build summary는 `sdd/03_build/02_screen/<service>/` 아래 screen-specific 파일로 유지한다.
+- dated execution log는 두지 않고 같은 summary 파일을 갱신한다.
+
+## 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 파일로 유지한다.
+- dated gate result나 test evidence log는 남기지 않는다.
+
+## SDD Operate Governance
+
+- `sdd/05_operate`는 current delivery state, runbook, monitoring baseline만 유지한다.
+- raw runtime log나 release timeline은 SDD가 아니라 runtime logging system의 역할이다.
+
+## Harness Location Policy
+
+- Claude/Codex/Ralph 하네스와 에이전트 설정은 저장소 루트의 `.claude`, `.codex`, `.agent`와 `sdd/99_toolchain/01_automation` 설명 문서에 함께 유지한다.
+
+## Build AST Governance
+
+- `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`를 기준으로 관리한다.

package/README.md

@@ -1,66 +1,102 @@
-# agentic-dev
+# templates
 
-`agentic-dev`는 더 이상 앱 템플릿 정본이 아니다. 현재 이 repo의 canonical 역할은 새 GitHub repo 안에서 `agentic-core`와 `template-*` repo를 조합해 초기 프로젝트 baseline을 생성하는 installer CLI다.
+제품으로 바로 수렴 가능한 client/server 템플릿 모음이자 downstream 저장소가 그대로 복제하는 canonical template repo다.
 
-## Canonical Flow
+포함 템플릿:
 
-1. GitHub에 새 repository를 만든다.
-2. 그 repo를 clone한다.
-3. repo root에 `.git`만 있는 상태에서 아래를 실행한다.
+- [landing](./client/landing): 마케팅/브랜드 랜딩 패턴
+- [platform](./client/platform): 일반 제품형 플랫폼 앱 shell, dashboard/list/detail 패턴
+- [mobile](./client/mobile): 다국어/현장 업무형 모바일 IN workspace 패턴
+- [admin](./client/admin): 운영 콘솔형 shell, sidebar/topbar/drawer/table 패턴
+- [server](./server): HTTP 기반 hexagonal/DDD 서버 패턴
 
-```bash
-npx agentic-dev init
-```
+공통 원칙:
+
+- 프론트엔드는 `pnpm workspace + React + Vite + Tailwind` 기반
+- `shadcn/ui-style` primitive를 직접 포함
+- 제품 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`를 사용하는 기준 템플릿이다.
+- 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 설명을 기준으로 유지한다.
+
+SDD / delivery 원칙:
 
-4. CLI는 다음을 단계별로 묻는다.
-   - `agentic-core` repo/ref
-   - `do4ai` 조직의 `template-*` repo 선택
-   - template ref
-   - 앱 slug / display name / bootstrap email
-   - GitHub owner / repository / project
-5. CLI는 template materialize -> token render -> `agentic-core` sync -> repo-local contract/bootstrap -> exact commit lock 생성 순서로 세팅한다.
+- 설계, 계획, 구현, 검증, 운영 문서는 모두 `sdd/`가 canonical root다.
+- `sdd/`는 history 누적이 아니라 current-state durable 문서만 유지한다.
+- `02_plan`은 에이전트의 현재 개발 계획을 관리하고, feature는 `<domain>_todos.md`, screen은 `<service>_todos.md`로 유지한다.
+- 템플릿 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` 순서를 기본으로 사용한다.
 
-## What Gets Generated
+문서:
 
-- `agentic-core` canonical harness
-  - `.claude/`
-  - `.codex/`
-  - `sdd/` shared inventory
-  - `scripts/agentic-core/`
-- template runtime/app code
-- repo-local GitHub Project agentic surface
-  - `.claude/agentic-dev.json`
-  - `.codex/agentic-dev.json`
-  - `sdd/99_toolchain/01_automation/github-project-kit/project-contract.json`
-  - `sdd/99_toolchain/01_automation/github-project-kit/artifact-contract.json`
-- provenance lock
-  - `.agentic-dev-lock.json`
+- [UI Contract Projection](./sdd/99_toolchain/01_automation/ui-contract-projection.md): 스킬/CLI 공통 projection 계약
+- [Infra Compose](./infra/compose/README.md): root compose baseline과 dedicated DEV(개발계)/PROD compose overlay
+- [Terraform Layout](./infra/terraform/README.md): provider-first canonical infra layout
+- [OpenStack Terraform](./infra/terraform/openstack/README.md): OpenStack compute baseline
+- [AST Build Governance](./sdd/02_plan/03_architecture/build_ast_runtime_tree_governance.md): `sdd/03_build` runtime-tree governance
 
-## Preconditions
+설치형 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
+```
 
-- current directory must already be a Git repo root
-- the repo should be empty except for `.git`
-- `gh`, `git`, `python3`, `node` must be installed
-- GitHub auth must have repo/project permissions
-- target GitHub repository must already exist
+CLI가 하는 일:
 
-## Template Contract
+- 선택한 frontend template 하나를 `client/<template>`로 설치
+- `server`, `.claude`, `.codex`, `.agent`, `sdd`, `infra`, `scripts`를 함께 설치
+- 선택한 template에 맞게 `compose.yml`, `pnpm-workspace.yaml`, `repo-contract.json`을 정렬
 
-template repo는 optional `.agentic-dev/template.json`을 통해 installer에 override를 줄 수 있다.
+GitHub token 운영:
 
-- `artifact_contract` 또는 `artifactContract`
-- `render_excludes`
+- 실제 token 값은 repo 파일에 저장하지 않는다.
+- GitHub CLI나 자동화는 `GH_TOKEN` 또는 별도 wrapper가 있다면 `AGENTIC_GITHUB_TOKEN` 같은 환경변수에서 읽도록 운영한다.
+- 이미 대화나 로그에 노출된 token은 재사용하지 않고 즉시 폐기 후 새로 발급하는 것이 맞다.
 
-없으면 installer는 generic artifact contract baseline을 사용한다.
 
-## Development
+개발용 compose baseline:
 
 ```bash
-npm test
-node src/cli.js --help
+cp .env.example .env
+docker compose up --build
 ```
 
-## Notes
+기본 compose 포트:
+
+- `client/landing`: `3000`
+- `client/platform`: `3001`
+- `client/mobile`: `3002`
+- `client/admin`: `4000`
+- `server/http`: `8000`
+
+기본 로그인 계정:
+
+- `admin@example.com` / `<CHANGE_ME>`
+- `operator@example.com` / `<CHANGE_ME>`
+
+DB adapter 전환:
+
+- 기본: `SERVER_DATABASE_BACKEND=postgres`
+- 선택 가능: `postgres`, `mysql`, `mariadb`, `mongodb`, `memory`
+- optional DB 컨테이너는 compose profile로 포함돼 있다:
+  - `docker compose --profile mysql up --build`
+  - `docker compose --profile mariadb up --build`
+  - `docker compose --profile mongo up --build`
+
+Agentic baseline:
 
-- 이 worktree에는 legacy template/runtime 코드가 남아 있을 수 있다. 현재 turn에서는 dirty worktree를 건드리지 않기 위해 비파괴적으로 installer surface를 우선 canonical화했다.
-- template 정본은 별도 `template-*` repo가 소유해야 하며, 첫 기준 템플릿은 `palcar`를 일반화한 `template-fullstack-mono`를 전제로 한다.
+- `.claude/agents/`: Claude role agent prompt surface
+- `.claude/skills/sdd`, `.claude/skills/sdd-development`: SDD skill surface
+- `.codex/skills/SKILL.md`: OTRO root alias
+- `.codex/skills/sdd/`: Codex SDD canonical skill
+- `.agent/ralph.sh`, `.agent/ralph-supervisor.sh`: bounded Ralph loop runner