agentic-dev 0.2.2 → 0.2.4

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/skills/sdd/SKILL.md

@@ -1,13 +1,184 @@
 ---
 name: sdd
-description: "Alias skill for repositories that use `sdd/` as the canonical delivery system."
-user_invocable: true
+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
+# SDD Development
 
-이 파일은 alias skill이다. canonical SDD workflow는 [`../sdd-dev/SKILL.md`](../sdd-dev/SKILL.md)를 따른다.
+## Overview
 
-Rules:
-- 실제 workflow와 section map은 `sdd-dev` 기준을 사용한다.
-- downstream repo가 `sdd` 이름으로 호출해도 동일한 current-state delivery 규칙으로 해석한다.
+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/.claude/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/.claude/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/.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/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 설명을 기준으로 유지한다.
@@ -42,12 +42,12 @@ SDD / delivery 원칙:
 설치형 scaffold:
 
 ```bash
-npx agentic-dev init my-app --template platform
+npx agentic-dev init my-app --template web
 cd my-app
 cp .env.example .env
 npm install -g pnpm
 pnpm install
-cd client/platform
+cd client/web
 npm run ui:parity:bootstrap
 ```
 
@@ -74,7 +74,7 @@ docker compose up --build
 기본 compose 포트:
 
 - `client/landing`: `3000`
-- `client/platform`: `3001`
+- `client/web`: `3001`
 - `client/mobile`: `3002`
 - `client/admin`: `4000`
 - `server/http`: `8000`

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 예시다.

package/client/{platform → web}/index.html

@@ -3,7 +3,7 @@
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <title>client-platform template</title>
+    <title>client-web template</title>
   </head>
   <body>
     <div id="root"></div>

package/client/{platform → web}/package.json

@@ -1,5 +1,5 @@
 {
-  "name": "@do4ai/client-platform-template",
+  "name": "@do4ai/client-web-template",
   "private": true,
   "version": "0.1.0",
   "type": "module",
@@ -8,12 +8,12 @@
     "dev": "vite --host 0.0.0.0 --port 3001",
     "build": "tsc -b && vite build",
     "preview": "vite preview --host 0.0.0.0 --port 4301",
-    "ui:parity:init": "bash ../../sdd/99_toolchain/01_automation/agentic-dev/init_frontend_parity.sh ../.. platform",
-    "ui:parity:bootstrap": "bash ../../sdd/99_toolchain/01_automation/agentic-dev/bootstrap_frontend_parity.sh ../.. platform",
-    "ui:parity:scaffold": "bash ../../sdd/99_toolchain/01_automation/agentic-dev/run_frontend_target.sh scaffold ../.. platform",
-    "ui:parity:materialize-references": "bash ../../sdd/99_toolchain/01_automation/agentic-dev/run_frontend_target.sh materialize_references ../.. platform",
-    "ui:parity:route-gap": "bash ../../sdd/99_toolchain/01_automation/agentic-dev/run_frontend_target.sh route_gap ../.. platform",
-    "ui:parity:proof": "bash ../../sdd/99_toolchain/01_automation/agentic-dev/run_frontend_target.sh proof ../.. platform",
+    "ui:parity:init": "bash ../../sdd/99_toolchain/01_automation/agentic-dev/init_frontend_parity.sh ../.. web",
+    "ui:parity:bootstrap": "bash ../../sdd/99_toolchain/01_automation/agentic-dev/bootstrap_frontend_parity.sh ../.. web",
+    "ui:parity:scaffold": "bash ../../sdd/99_toolchain/01_automation/agentic-dev/run_frontend_target.sh scaffold ../.. web",
+    "ui:parity:materialize-references": "bash ../../sdd/99_toolchain/01_automation/agentic-dev/run_frontend_target.sh materialize_references ../.. web",
+    "ui:parity:route-gap": "bash ../../sdd/99_toolchain/01_automation/agentic-dev/run_frontend_target.sh route_gap ../.. web",
+    "ui:parity:proof": "bash ../../sdd/99_toolchain/01_automation/agentic-dev/run_frontend_target.sh proof ../.. web",
     "ui:parity": "npm run ui:parity:proof"
   },
   "dependencies": {

package/client/{platform/scripts/ui-parity-platform-adapter.mjs → web/scripts/ui-parity-web-adapter.mjs}

@@ -13,7 +13,7 @@ const routes = JSON.parse(
 const routeMap = new Map(routes.map((entry) => [entry.id, entry.route]));
 
 export default {
-  service: "templates-platform",
+  service: "templates-web",
   targetBaseUrl: "http://127.0.0.1:4301",
   viewport: {
     width: 1440,
@@ -26,7 +26,7 @@ export default {
     referenceImage: `sdd/04_verify/10_test/ui_parity/reference/${screen.id}.png`,
     readySelector: "body",
     readyTimeoutMs: 10000,
-    tags: ["template", "platform"],
+    tags: ["template", "web"],
   })),
   async preparePage(page, { route }) {
     await page.route("**/auth/me", async (routeRequest) => {
@@ -34,8 +34,8 @@ export default {
         status: 200,
         contentType: "application/json",
         body: JSON.stringify({
-          id: "tmpl-platform",
-          name: "Template Platform User",
+          id: "tmpl-web",
+          name: "Template Web User",
           email: "operator@example.com",
           role: "member",
         }),
@@ -43,17 +43,17 @@ export default {
     });
     await page.addInitScript(() => {
       window.localStorage.setItem(
-        "platform.auth.token",
+        "web.auth.token",
         JSON.stringify({
           access_token: "template-access-token",
           token_type: "bearer",
-          user_id: "tmpl-platform",
+          user_id: "tmpl-web",
         }),
       );
     });
     if (route === "/login") {
       await page.addInitScript(() => {
-        window.localStorage.removeItem("platform.auth.token");
+        window.localStorage.removeItem("web.auth.token");
       });
     }
   },

package/client/{platform → web}/src/auth/AuthProvider.tsx

@@ -3,7 +3,7 @@ import { createContext, useContext, useEffect, useMemo, useState, type ReactNode
 import { getMe, login as loginRequest } from "@/auth/auth-client";
 import type { AuthToken, AuthUser, LoginCommand } from "@/auth/types";
 
-const STORAGE_KEY = "platform.auth.token";
+const STORAGE_KEY = "web.auth.token";
 
 interface AuthContextValue {
   user: AuthUser | null;

package/compose.yml

@@ -138,19 +138,19 @@ services:
     networks:
       - template-dev
 
-  client-platform:
+  client-web:
     build:
       context: .
-      dockerfile: client/platform/Dockerfile.dev
+      dockerfile: client/web/Dockerfile.dev
       network: host
     environment:
-      PORT: ${CLIENT_PLATFORM_PORT:-3001}
-      VITE_API_BASE_URL: ${CLIENT_PLATFORM_VITE_API_BASE_URL:-http://127.0.0.1:8000/api/v1}
+      PORT: ${CLIENT_WEB_PORT:-3001}
+      VITE_API_BASE_URL: ${CLIENT_WEB_VITE_API_BASE_URL:-http://127.0.0.1:8000/api/v1}
       CHOKIDAR_USEPOLLING: ${CLIENT_WATCH_USE_POLLING:-false}
     ports:
-      - "${CLIENT_PLATFORM_PORT:-3001}:${CLIENT_PLATFORM_PORT:-3001}"
+      - "${CLIENT_WEB_PORT:-3001}:${CLIENT_WEB_PORT:-3001}"
     volumes:
-      - ./client/platform:/app/client/platform
+      - ./client/web:/app/client/web
     depends_on:
       server:
         condition: service_started

package/infra/compose/.env.dev.example

@@ -15,14 +15,14 @@ DEV_SERVER_MONGODB_URL=mongodb://mongo:27017
 DEV_SERVER_MONGODB_DATABASE=template
 DEV_SERVER_JWT_SECRET=change-me
 DEV_SERVER_ACCESS_TOKEN_TTL_MINUTES=120
-DEV_SERVER_CORS_ORIGINS=https://dev-landing.example.com,https://dev-platform.example.com,https://dev-mobile.example.com,https://dev-admin.example.com
+DEV_SERVER_CORS_ORIGINS=https://dev-landing.example.com,https://dev-web.example.com,https://dev-mobile.example.com,https://dev-admin.example.com
 
 DEV_CLIENT_LANDING_PORT=13000
-DEV_CLIENT_PLATFORM_PORT=13001
+DEV_CLIENT_WEB_PORT=13001
 DEV_CLIENT_MOBILE_PORT=13002
 DEV_CLIENT_ADMIN_PORT=14000
 
 DEV_CLIENT_LANDING_VITE_API_BASE_URL=https://dev-api.example.com/api/v1
-DEV_CLIENT_PLATFORM_VITE_API_BASE_URL=https://dev-api.example.com/api/v1
+DEV_CLIENT_WEB_VITE_API_BASE_URL=https://dev-api.example.com/api/v1
 DEV_CLIENT_MOBILE_VITE_API_BASE_URL=https://dev-api.example.com/api/v1
 DEV_CLIENT_ADMIN_VITE_API_BASE_URL=https://dev-api.example.com/api/v1

package/infra/compose/.env.prod.example

@@ -16,14 +16,14 @@ PROD_SERVER_MONGODB_URL=mongodb://mongo:27017
 PROD_SERVER_MONGODB_DATABASE=template
 PROD_SERVER_JWT_SECRET=change-me
 PROD_SERVER_ACCESS_TOKEN_TTL_MINUTES=120
-PROD_SERVER_CORS_ORIGINS=https://landing.example.com,https://platform.example.com,https://mobile.example.com,https://admin.example.com
+PROD_SERVER_CORS_ORIGINS=https://landing.example.com,https://web.example.com,https://mobile.example.com,https://admin.example.com
 
 PROD_CLIENT_LANDING_PORT=23000
-PROD_CLIENT_PLATFORM_PORT=23001
+PROD_CLIENT_WEB_PORT=23001
 PROD_CLIENT_MOBILE_PORT=23002
 PROD_CLIENT_ADMIN_PORT=24000
 
 PROD_CLIENT_LANDING_VITE_API_BASE_URL=https://api.example.com/api/v1
-PROD_CLIENT_PLATFORM_VITE_API_BASE_URL=https://api.example.com/api/v1
+PROD_CLIENT_WEB_VITE_API_BASE_URL=https://api.example.com/api/v1
 PROD_CLIENT_MOBILE_VITE_API_BASE_URL=https://api.example.com/api/v1
 PROD_CLIENT_ADMIN_VITE_API_BASE_URL=https://api.example.com/api/v1

package/infra/compose/README.md

@@ -30,6 +30,6 @@ docker compose --env-file infra/compose/.env.prod -f infra/compose/prod.yml up -
 - `infra/compose/dev.yml`, `infra/compose/prod.yml`은 dedicated host/runtime split이 필요할 때 쓰는 overlay이며, root compose baseline을 대체하는 문서 기준선은 아니다.
 - provider-first canonical delivery split은 `AWS edge/domain -> OpenStack backend compute -> AWS data plane`이고, 세부 구조는 `infra/terraform/README.md`를 기준으로 설명한다.
 - `VITE_API_BASE_URL`은 컨테이너 내부 DNS가 아니라 브라우저가 도달 가능한 API URL이어야 한다.
-- 포트 역할은 root compose baseline과 같은 순서를 따른다: landing, platform, mobile, admin, server/http.
+- 포트 역할은 root compose baseline과 같은 순서를 따른다: landing, web, mobile, admin, server/http.
 - PROD 웹 앱은 `pnpm build + pnpm preview`로 기동한다.
 - OpenStack에서 자동 배포까지 묶고 싶으면 `infra/terraform/openstack/server` 또는 lower-level `openstack/dev`, `openstack/prod` root를 사용한다.

package/infra/compose/dev.yml

@@ -65,20 +65,20 @@ services:
     networks:
       - templates-dev
 
-  client-platform:
+  client-web:
     build:
       context: ../..
-      dockerfile: client/platform/Dockerfile
-    container_name: templates-client-platform-dev
+      dockerfile: client/web/Dockerfile
+    container_name: templates-client-web-dev
     restart: unless-stopped
     depends_on:
       server:
         condition: service_started
     environment:
-      VITE_API_BASE_URL: ${DEV_CLIENT_PLATFORM_VITE_API_BASE_URL}
+      VITE_API_BASE_URL: ${DEV_CLIENT_WEB_VITE_API_BASE_URL}
       PORT: 3001
     ports:
-      - "${DEV_CLIENT_PLATFORM_PORT:-13001}:3001"
+      - "${DEV_CLIENT_WEB_PORT:-13001}:3001"
     networks:
       - templates-dev
 

package/infra/compose/prod.yml

@@ -43,7 +43,7 @@ services:
       MONGODB_DATABASE: ${PROD_SERVER_MONGODB_DATABASE:-template}
       JWT_SECRET: ${PROD_SERVER_JWT_SECRET:-change-me}
       ACCESS_TOKEN_TTL_MINUTES: ${PROD_SERVER_ACCESS_TOKEN_TTL_MINUTES:-120}
-      CORS_ORIGINS: ${PROD_SERVER_CORS_ORIGINS:-https://landing.example.com,https://platform.example.com,https://mobile.example.com,https://admin.example.com}
+      CORS_ORIGINS: ${PROD_SERVER_CORS_ORIGINS:-https://landing.example.com,https://web.example.com,https://mobile.example.com,https://admin.example.com}
     ports:
       - "${PROD_SERVER_HTTP_PORT:-28000}:8000"
     networks:
@@ -66,20 +66,20 @@ services:
     networks:
       - templates-prod
 
-  client-platform:
+  client-web:
     build:
       context: ../..
-      dockerfile: client/platform/Dockerfile
-    container_name: templates-client-platform-prod
+      dockerfile: client/web/Dockerfile
+    container_name: templates-client-web-prod
     restart: unless-stopped
     depends_on:
       server:
         condition: service_started
     command: ["sh", "-lc", "pnpm build && pnpm preview --host 0.0.0.0 --port 4301"]
     environment:
-      VITE_API_BASE_URL: ${PROD_CLIENT_PLATFORM_VITE_API_BASE_URL}
+      VITE_API_BASE_URL: ${PROD_CLIENT_WEB_VITE_API_BASE_URL}
     ports:
-      - "${PROD_CLIENT_PLATFORM_PORT:-23001}:4301"
+      - "${PROD_CLIENT_WEB_PORT:-23001}:4301"
     networks:
       - templates-prod