ai-ops-cli 0.2.6 → 1.0.2

package/data/skills/task-skills/spec-product-02-brief-to-technical-context/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "spec-product-02-brief-to-technical-context"
+  short_description: "Convert an approved brief into a constrained technical context."
+  default_prompt: "Use $spec-product-02-brief-to-technical-context to expand the approved brief into a Korean 05_technical-context.md with justified stack choices."
+policy:
+  allow_implicit_invocation: false

package/data/skills/task-skills/spec-product-02-brief-to-technical-context/references/template.md

@@ -0,0 +1,58 @@
+# 05_technical-context.md Template
+
+```md
+# 05 Technical Context
+
+## 제품 형태
+- web / app / backend / mixed
+
+## 기본 선택 스택
+- web:
+  - TypeScript
+  - Next.js
+  - shadcn/ui
+  - Tailwind CSS
+  - date-fns
+  - Supabase
+- app:
+  - Flutter
+- backend:
+  - NestJS
+  - Prisma
+  - Supabase
+  - GraphQL
+- simple serverless:
+  - Hono
+  - RESTful API
+
+## 선택 근거
+- 왜 이 조합이 현재 제품 범위에 맞는가
+
+## 운영 / 배포 가정
+- 인증
+- 데이터 저장
+- 배포 환경
+- 서버 필요 여부
+
+## 보안 고려사항
+- auth / secret / storage / upload / 외부 callback / tenant 경계 같은 제약
+- 없으면 `특이사항 없음`
+
+## 프로젝트 제약
+- 기존 코드베이스
+- 팀 숙련도
+- 일정 / 운영 부담
+
+## 현재 저장소 상태 / 스택 갭
+- web / app / backend surface별 현재 repo 상태: `present` / `partial` / `absent`
+- 이미 재사용할 수 있는 manifest, config, app/package 디렉터리
+- 부족한 scaffold, dependency install, env/config wiring
+- downstream work packet에서 선행 bootstrap 패킷이 필요한 영역
+
+## 추가 기술 제안 규칙
+- 기본 선호 스택으로 해결 가능한지 먼저 검토
+- 선호 밖 기술은 이유, 이점, 비용, 승인 필요 여부를 함께 기록
+
+## 미해결 기술 결정사항
+- 결정사항 1
+```

package/data/skills/task-skills/spec-product-03-brief-to-product-spec/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: spec-product-03-brief-to-product-spec
+description: Expand an approved Korean 00_brief.md and 05_technical-context.md into a Korean 10_product-spec.md in the current project's docs/specs/baseline directory with concrete user flows, features, entities, business rules, edge cases, and success criteria while preserving approved scope and stack constraints.
+disable-model-invocation: true
+---
+
+# spec-product-03-brief-to-product-spec
+
+Use this skill after `./docs/specs/baseline/00_brief.md` and `./docs/specs/baseline/05_technical-context.md` are approved and the next artifact should be `./docs/specs/baseline/10_product-spec.md`.
+
+## Output Location
+
+- Write into the current workspace.
+- Default output path: `./docs/specs/baseline/10_product-spec.md`
+
+## Language Rules
+
+- Write the document in Korean.
+- Keep code-facing names, API field names, library/service names, protocol names, file paths, and widely used technical terms in their natural English form when that is clearer and more standard.
+- Do not force awkward phonetic transliterations such as `소스 오브 트루스`, `타겟 플랫폼`, or `워크 패킷`.
+- If an English technical term needs explanation, keep the English term and add a short Korean gloss on first mention, for example `source of truth(가장 신뢰하는 기준)`.
+
+## Required Inputs
+
+1. `./docs/specs/baseline/00_brief.md`
+2. `./docs/specs/baseline/05_technical-context.md`
+
+## Objective
+
+Convert direction into a tighter operational product spec without reopening already approved scope or ignoring the fixed technical context.
+
+## Workflow
+
+1. Turn goals into 1-3 core user flows.
+2. Derive the minimum feature set needed for those flows.
+3. Define only the entities needed for v1 decisions.
+4. Make business rules explicit, especially permissions and state transitions.
+5. Add edge cases that affect validation, UI states, or data integrity.
+6. Reflect technical constraints only where they meaningfully change the product shape.
+7. Rewrite success criteria so they can be checked later.
+
+## Security Lens
+
+Keep this pass lightweight and product-facing.
+
+- Check whether user flows or business rules introduce auth, permission, ownership, tenant, or destructive-action concerns.
+- Check whether features handle sensitive data, uploads, external callbacks, or rendered rich content.
+- Record the result under `보안 고려사항`.
+- If any of those triggers exist or the boundary is unclear, recommend `spec-security-01-triage` in `mode=spec`.
+
+Use [references/template.md](references/template.md) when drafting the file.
+
+## Glossary Rule
+
+- Check `./docs/specs/baseline/01_glossary.md` if it exists and the product spec introduces or chooses domain terms, entity names, state names, or user-facing labels.
+- After writing the target document, `spec-shared-glossary-sync` is recommended because product specs often add or refine canonical vocabulary.
+
+## Required Sections
+
+- `핵심 사용자 플로우`
+- `기능`
+- `엔티티`
+- `비즈니스 규칙`
+- `엣지 케이스`
+- `성공 기준`
+- `기술 제약 반영 메모`
+- `보안 고려사항`
+- `미해결 결정사항`
+
+## Mermaid Rule
+
+Add Mermaid when the product behavior is easier to understand visually.
+
+- Use flowchart for multi-step user flows.
+- Use stateDiagram for non-trivial state transitions.
+- Skip Mermaid if there is only one short flow and no meaningful state logic.
+
+## Quality Bar
+
+The product spec is not ready if:
+
+- features do not map cleanly to user flows
+- entities exist without behavioral rules
+- success criteria cannot be validated later
+- technical context is contradicted or ignored

package/data/skills/task-skills/spec-product-03-brief-to-product-spec/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "spec-product-03-brief-to-product-spec"
+  short_description: "Expand an approved brief into a concrete Korean product spec."
+  default_prompt: "Use $spec-product-03-brief-to-product-spec to turn the approved brief and technical context into a detailed Korean 10_product-spec.md."
+policy:
+  allow_implicit_invocation: false

package/data/skills/task-skills/spec-product-03-brief-to-product-spec/references/template.md

@@ -0,0 +1,41 @@
+# 10_product-spec.md Template
+
+```md
+# 10 Product Spec
+
+## 핵심 사용자 플로우
+1. 플로우 1
+2. 플로우 2
+
+## 기능
+- 기능 1
+- 기능 2
+
+## 엔티티
+- 엔티티명
+  - 목적
+  - 핵심 필드
+
+## 비즈니스 규칙
+- 규칙 1
+- 규칙 2
+
+## 엣지 케이스
+- empty state
+- loading state
+- error state
+
+## 성공 기준
+- 기준 1
+- 기준 2
+
+## 기술 제약 반영 메모
+- 어떤 제약이 제품 구조에 영향을 주는지
+
+## 보안 고려사항
+- auth / 권한 / 민감정보 / 업로드 / 외부 호출 / tenant 경계 관련 메모
+- 없으면 `특이사항 없음`
+
+## 미해결 결정사항
+- 결정사항 1
+```

package/data/skills/task-skills/spec-product-04-product-spec-to-ui-spec/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: spec-product-04-product-spec-to-ui-spec
+description: Generate initial Korean 20_ui-spec.md, optional English 21_stitch-prompt.md, and initial visual guidance from approved product specs, screenshots, or Stitch/reference drafts for first product implementation only.
+disable-model-invocation: true
+---
+
+# spec-product-04-product-spec-to-ui-spec
+
+Use this skill when `./docs/specs/baseline/10_product-spec.md` is approved and the product needs initial UI direction before first implementation.
+
+Default outputs:
+
+- `./docs/specs/baseline/20_ui-spec.md`
+- optional `./docs/specs/baseline/21_stitch-prompt.md`
+- optional `./docs/specs/baseline/22_stitch-assets/DESIGN.md`
+- optional `./docs/specs/baseline/24_design-tokens.md`
+
+Do not use this skill as the default path for MVP-afterward UI changes. Ongoing UI work belongs in `.codex/plans/*.md` with screenshots, reference apps, and detailed requested adjustments.
+
+## Language Rules
+
+- `20_ui-spec.md`, `DESIGN.md`, and `24_design-tokens.md` must be written in Korean.
+- `21_stitch-prompt.md`, when created, must be written in English.
+- Keep code-facing names, API field names, library/service names, protocol names, file paths, and standard technical terms in their natural English form when clearer.
+- Do not force awkward phonetic transliterations.
+
+## Required Inputs
+
+1. `./docs/specs/baseline/05_technical-context.md`
+2. `./docs/specs/baseline/10_product-spec.md`
+3. optional user-provided screenshots, reference apps, mood notes, or visual constraints
+4. optional Stitch output under `./docs/specs/baseline/22_stitch-assets/`
+
+## Objective
+
+Define initial UI structure and states clearly enough for first implementation, while treating visual references as concept/draft input rather than product truth.
+
+The skill should:
+
+- enumerate screens from approved user flows
+- define screen purpose, primary actions, states, and navigation boundaries
+- preserve target platform constraints
+- normalize initial visual direction against approved product scope
+- reject or defer visual ideas that imply unapproved product behavior
+- create a Stitch prompt only when external visual generation will reduce ambiguity
+
+## Workflow
+
+1. Read approved product and technical context.
+2. Identify UI surfaces that are required for the first build.
+3. Draft `20_ui-spec.md` around screens, states, interactions, and design constraints.
+4. If the user wants Stitch concepting, write `21_stitch-prompt.md` in English.
+5. If screenshots or Stitch output already establish reusable visual rules, write or update baseline `DESIGN.md` and optional tokens.
+6. Record security-relevant UI surfaces under `보안 고려사항`.
+
+## Visual Reference Rules
+
+- Stitch, screenshots, and reference apps are inspiration and structure references, not product truth.
+- Approved product spec and technical context outrank visual references.
+- If a reference introduces unsupported features, labels, business rules, biometric/medical claims, social mechanics, monetization, or platform assumptions, reject or mark them out of scope.
+- For Flutter or native apps, translate visual ideas into native primitives and theme/tokens. Do not treat HTML/CSS as the shipping stack.
+- Keep initial guidance practical enough for `spec-product-05` to create implementation packets.
+
+## Security Lens
+
+Keep this pass UI-focused and short.
+
+- Check whether the UI introduces auth-sensitive actions, destructive actions, file upload/download, rendered user content, or admin-only surfaces.
+- Record the result under `보안 고려사항`.
+- If any trigger appears or the trust boundary is unclear, recommend `spec-security-01-triage` in `mode=spec`.
+
+Use these references while drafting:
+
+- [references/ui-spec-template.md](references/ui-spec-template.md)
+- [references/stitch-prompt-template.md](references/stitch-prompt-template.md)
+
+## Required UI Spec Sections
+
+- `화면 목록`
+- `화면 목적`
+- `상태 정의`
+- `주요 인터랙션`
+- `디자인 제약`
+- `초기 시각 참고 / 구현 번역 규칙`
+- `보안 고려사항`
+
+## Mermaid Rule
+
+Include Mermaid only when navigation or state coverage is dense.
+
+- Use flowchart for screen-to-screen navigation.
+- Use stateDiagram for per-screen states when more than 4 states or transitions matter.
+- Skip Mermaid if prose is enough.

package/data/skills/task-skills/spec-product-04-product-spec-to-ui-spec/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "spec-product-04-product-spec-to-ui-spec"
+  short_description: "Create initial UI spec, optional Stitch prompt, and first-build visual guidance."
+  default_prompt: "Use $spec-product-04-product-spec-to-ui-spec to create an initial Korean 20_ui-spec.md, optional English 21_stitch-prompt.md, and practical first-build visual guidance from approved product specs and reference inputs."
+policy:
+  allow_implicit_invocation: false

package/data/skills/task-skills/spec-product-04-product-spec-to-ui-spec/references/stitch-prompt-template.md

@@ -0,0 +1,41 @@
+# 21_stitch-prompt.md Template
+
+```md
+# Stitch Prompt
+
+## Product Context
+- Summarize the product in 3-5 lines.
+
+## Technical Context
+- Mention the intended platform and implementation constraints relevant to UI generation.
+- Say the generated result is an initial visual reference, not product truth or the shipped technology stack.
+
+## Core User Flows
+1. Flow 1
+2. Flow 2
+
+## Screens To Generate
+- Screen 1
+- Screen 2
+
+## Required States
+- empty
+- loading
+- error
+- success
+
+## Key Interactions
+- Interaction 1
+- Interaction 2
+
+## Design Direction
+- Visual tone
+- Layout constraints
+- Platform assumptions
+- Current design-system constraints, if any
+
+## Scope Guardrails
+- Do not invent unapproved features, pricing, social mechanics, medical claims, or backend behavior.
+- Do not imply that HTML/CSS is the implementation stack.
+- Treat output as concept art/reference for first implementation.
+```

package/data/skills/task-skills/spec-product-04-product-spec-to-ui-spec/references/ui-spec-template.md

@@ -0,0 +1,39 @@
+# 20_ui-spec.md Template
+
+```md
+# 20 UI Spec
+
+## 화면 목록
+- 화면명
+
+## 화면 목적
+- 화면별 목적과 주요 사용자 행동
+
+## 상태 정의
+- empty
+- loading
+- error
+- success
+
+## 주요 인터랙션
+- 인터랙션 1
+- 인터랙션 2
+
+## 디자인 제약
+- 접근성
+- 반응형
+- 시각 톤
+- 플랫폼 제약
+
+## 초기 시각 참고 / 구현 번역 규칙
+- 참고 screenshot, reference app, Stitch 결과는 initial concept reference다.
+- 승인된 product spec과 technical context가 더 우선한다.
+- 구현 대상은 승인된 target platform이며, Flutter 프로젝트라면 Flutter widget tree와 theme/token으로 번역한다.
+- HTML/CSS를 그대로 이식하지 않는다.
+- 레이아웃 계층, CTA 우선순위, 정보 그룹, 상태 표현, 주요 인터랙션 중 제품에 승인된 부분만 유지한다.
+- 범위 밖 아이디어는 `범위 제외` 또는 후속 plan 후보로 분리한다.
+
+## 보안 고려사항
+- auth-sensitive action, destructive action, upload/download, rendered content 관련 메모
+- 없으면 `특이사항 없음`
+```

package/data/skills/task-skills/spec-product-05-spec-to-work-packets/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: spec-product-05-spec-to-work-packets
+description: Convert approved baseline product specs into initial-build Korean work packets under docs/specs/initial-build, with explicit scope, tests, dependencies, and repo-reality bootstrap/foundation packets when needed.
+disable-model-invocation: true
+---
+
+# spec-product-05-spec-to-work-packets
+
+Use this skill only when the next artifact is the first implementation packet set for a product baseline.
+
+## Output Location
+
+- Write into the current workspace.
+- Create or continue one initial-build batch such as `./docs/specs/initial-build/2026-03-21_initial-build/`.
+- If no active initial-build batch exists yet, create `./docs/specs/initial-build/YYYY-MM-DD_initial-build/`.
+- Default output path: `./docs/specs/initial-build/<initial-build-topic>/30_work-packets/*.md`
+- Optional summary artifact: `./docs/specs/initial-build/<initial-build-topic>/30_work-packets/00_packet-map.md`
+
+Do not use this skill as the default path for MVP 이후 changes. Ongoing changes belong in `.codex/plans/*.md`.
+
+## Required Inputs
+
+Read all relevant available inputs before writing packets:
+
+1. `./docs/specs/baseline/05_technical-context.md`
+2. `./docs/specs/baseline/10_product-spec.md`
+3. `./docs/specs/baseline/20_ui-spec.md` when the product includes approved UI surfaces
+4. optional initial visual references under `./docs/specs/baseline/22_stitch-assets/`
+5. optional `./docs/specs/baseline/22_stitch-assets/DESIGN.md`
+6. optional `./docs/specs/baseline/24_design-tokens.md`
+7. current repository manifests, config files, and top-level app/package directories relevant to the approved stack
+
+Use what exists. Explicitly note missing but relevant inputs.
+
+If the product has no user-facing UI by design, proceed from `05_technical-context.md` and `10_product-spec.md` without inventing UI docs or visual inputs.
+
+If the product has UI but no visual references exist, proceed from `20_ui-spec.md`; visual references are helpful but never a blocker.
+
+## Language Rules
+
+- Write every work packet in Korean.
+- Keep code identifiers, API field names, library/service names, protocol names, file paths, and standard technical terms in their natural English form when clearer.
+- Do not force awkward phonetic transliterations.
+
+## Objective
+
+Produce initial-build packets that are independently understandable, independently implementable, and small enough for human review and safe AI execution.
+
+For initial-build work, packet generation must stay grounded in the current repository reality, not an imagined clean scaffold.
+
+The packet set should be `parallel-ready`:
+
+- packets are small enough to hand to one worker at a time
+- dependencies are explicit enough that plan mode can order or parallelize them
+- hidden coupling is minimized before execution begins
+
+## Required Sections
+
+Every packet must include:
+
+- `목표`
+- `범위`
+- `입력물`
+- `산출물`
+- `대상 파일 / 모듈`
+- `승인 기준`
+- `보안 검토`
+- `테스트`
+- `의존성`
+- `범위 제외`
+
+For UI-touching packets:
+
+- `입력물` should include `20_ui-spec.md` and any relevant visual guidance that exists
+- `승인 기준` must state which UI structure, hierarchy, states, and interactions must survive in the approved target platform
+- any intentional deviation from initial visual references must be named explicitly
+
+## Security Overlay
+
+Every packet must include `보안 검토`.
+
+- `보안 검토` must state `판정: 필요 | 불필요 | 확인 필요`.
+- It must briefly list trigger surfaces and say whether implementation-stage security review is required.
+- If the packet touches auth, permission, sensitive data, tenant boundaries, external fetch, uploads, raw queries, rendered content, or destructive actions, do not mark it `불필요` unless the packet is clearly documentation-only.
+- If risk is unclear, use `확인 필요` and recommend `spec-security-01-triage` in `mode=spec`.
+
+## Dependency Rules
+
+Every packet must make dependency state explicit.
+
+- If there is no dependency, write `없음`.
+- If another packet must finish first, name the packet ID explicitly.
+- If the packet is blocked by a contract, schema, design decision, or external approval, name that dependency explicitly.
+- If the packet is likely parallel-safe with other packets, note that inside `의존성`.
+- Never leave dependencies implied or blank.
+
+Use a compact structure such as:
+
+- `선행 패킷: 없음`
+- `선행 패킷: 001_api-shell`
+- `외부 결정 / 선행 계약: Supabase auth schema 확정`
+- `병렬 가능 후보: 003_home-shell, 004_session-card`
+
+## Repository Reality Check
+
+Before drafting packets, inspect the current repository for concrete evidence of the approved stack.
+
+- Check stack signals such as `package.json`, lockfiles, workspace manifests, `next.config.*`, `components.json`, `tailwind.config.*`, `pubspec.yaml`, `lib/`, `android/`, `ios/`, `nest-cli.json`, `src/main.ts`, `prisma/schema.prisma`, GraphQL schema/config files, and existing app/package directories.
+- Use product surfaces declared in `05_technical-context.md` to decide which signals matter.
+- Classify each approved surface as `present`, `partial`, or `absent`.
+- If any approved surface is `partial` or `absent`, create explicit bootstrap/foundation packets before feature packets for that surface.
+
+## Bootstrap / Foundation Rules
+
+Bootstrap work is first-class packet work.
+
+- Prefer clear packet names such as `000_repo-bootstrap`, `001_web-foundation`, `002_backend-foundation`, or `003_db-foundation`.
+- Cover the minimum setup required to make later feature packets realistic:
+  - package manager / workspace initialization when missing
+  - framework scaffold or base module wiring
+  - required approved dependencies installation
+  - baseline config files and directory structure
+  - environment/example config wiring needed for local execution
+  - smoke-level verification such as install success, boot success, or schema generation success
+- Downstream feature packets must list relevant foundation packet IDs in `선행 패킷`.
+- Do not scatter the same installation or scaffold work across multiple feature packets.
+
+Use these references while drafting:
+
+- [references/work-packet-template.md](references/work-packet-template.md)
+- [references/stitch-html-review.md](references/stitch-html-review.md) only when initial Stitch HTML exists and materially helps UI packet boundaries
+
+## Glossary Rule
+
+- Check `./docs/specs/baseline/01_glossary.md` only if packet wording could drift from established entity, state, or UI terminology.
+- Do not run `spec-shared-glossary-sync` by default after packet generation. Run it only if packeting surfaced meaningful new terms or clear terminology collisions.
+
+## Mermaid Rule
+
+Include Mermaid only when dependency structure is hard to scan in prose.
+
+- If packet count is 4 or more, or dependency order across backend/mobile/domain seams is hard to scan, prefer adding `00_packet-map.md`.
+- Use graph TD for packet dependency DAGs.
+- Skip Mermaid if packets are already linear and obvious.
+
+If `00_packet-map.md` is created, packet files' `## 의존성` sections remain the canonical dependency source.
+
+## Quality Bar
+
+The packet set is not ready if:
+
+- it assumes a framework scaffold that is absent from the repo
+- dependencies are implied rather than explicit
+- bootstrap work is hidden inside feature packets
+- security trigger surfaces are not marked
+- UI packets ignore approved UI spec or current visual guidance
+- packets are too broad for one worker to implement safely

package/data/skills/task-skills/spec-product-05-spec-to-work-packets/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "spec-product-05-spec-to-work-packets"
+  short_description: "Split baseline specs into initial-build packets with repo-reality foundation work."
+  default_prompt: "Use $spec-product-05-spec-to-work-packets to convert the approved baseline spec set into initial-build Korean work packets under docs/specs/initial-build, checking the current repository against the approved stack and creating explicit foundation packets when required surfaces are missing."
+policy:
+  allow_implicit_invocation: false

package/data/skills/task-skills/spec-product-05-spec-to-work-packets/references/stitch-html-review.md

@@ -0,0 +1,25 @@
+# Stitch HTML Review Checklist
+
+Use this checklist before writing initial-build UI packets from Stitch output.
+
+## Extract
+
+- top-level screens represented by each HTML file
+- repeated layout regions such as header, shell, side panel, footer
+- major interactive blocks such as forms, tables, tabs, charts, filters
+- visible state variants such as disabled, active, empty, loading-like placeholders, error copy
+
+## Do Not Assume
+
+- generated class names are production-ready structure
+- every visual grouping should become a component
+- missing states mean those states do not exist
+- HTML output means the shipped product should be implemented as web markup
+
+## Use For Packeting
+
+- identify natural UI seams
+- identify likely component boundaries
+- identify stateful regions needing separate implementation work
+- cross-check whether the generated visuals introduce behavior not present in the approved spec
+- identify which approved layout hierarchy, CTA priority, copy grouping, and state presentation should survive target-platform translation

package/data/skills/task-skills/spec-product-05-spec-to-work-packets/references/work-packet-template.md

@@ -0,0 +1,67 @@
+# Work Packet Template
+
+```md
+# 001 패킷 제목
+
+## 목표
+
+- 이번 패킷이 끝나면 무엇이 가능해져야 하는가
+- foundation 패킷이면 이후 기능 패킷이 실제 repo 위에서 시작 가능해야 한다.
+
+## 범위
+
+- 포함되는 변경 범위
+- 설치, scaffold, config, env wiring만 다루는 foundation 패킷인지 여부를 명확히 적는다.
+
+## 입력물
+
+- `./docs/specs/baseline/05_technical-context.md`
+- `./docs/specs/baseline/10_product-spec.md`
+- 필요 시 `./docs/specs/baseline/20_ui-spec.md`
+- 필요 시 `./docs/specs/baseline/22_stitch-assets/...`
+- 필요 시 `./docs/specs/baseline/22_stitch-assets/DESIGN.md`
+- 필요 시 `./docs/specs/baseline/24_design-tokens.md`
+- 현재 repo의 관련 manifest / config / app 디렉터리 상태 (`package.json`, `pubspec.yaml`, `next.config.*`, `nest-cli.json`, `prisma/schema.prisma` 등)
+
+## 산출물
+
+- 기대 결과물
+- foundation 패킷이면 생성되거나 정리될 scaffold, config, dependency install 결과를 적는다.
+
+## 대상 파일 / 모듈
+
+- 수정 또는 생성 대상
+- 필요 시 `package.json`, lockfile, `pubspec.yaml`, `next.config.*`, `tailwind.config.*`, `components.json`, `nest-cli.json`, `src/main.ts`, `prisma/schema.prisma`, `apps/*`, `packages/*`, `lib/*` 같은 기반 파일을 명시한다.
+
+## 승인 기준
+
+- 기준 1
+- 기준 2
+- foundation 패킷이면 이후 패킷이 가정하는 framework scaffold와 dependency wiring이 repo에 실제로 존재해야 한다.
+- foundation 패킷이면 최소 한 가지 smoke 검증 기준을 넣는다. 예: install 성공, dev boot 성공, schema generation 성공.
+- UI 패킷이면 `20_ui-spec.md`와 initial visual guidance에서 승인된 화면 구조, CTA 우선순위, 상태 표현, 주요 인터랙션을 target platform에 맞게 보존해야 한다.
+- 헤드리스 / 백엔드 패킷이면 화면 문서를 새로 만들지 않고 계약, 데이터 흐름, 운영 동작 기준으로 검증 가능해야 한다.
+
+## 보안 검토
+
+- 판정: 필요 / 불필요 / 확인 필요
+- 트리거: auth / 권한 / 민감정보 / 업로드 / 외부 호출 / raw query / 렌더링 / tenant 경계 / 삭제 동작 중 해당 사항
+- 구현 후 리뷰 조건: 필요 없으면 `없음`
+
+## 테스트
+
+- 테스트 1
+- 테스트 2
+- foundation 패킷이면 smoke test, install verification, scaffold verification, generated file presence 중 최소 하나를 넣는다.
+
+## 의존성
+
+- 선행 패킷: 없음 / `000_repo-bootstrap` / `001_xxx`
+- 외부 결정 / 선행 계약: 없으면 `없음`
+- 병렬 가능 후보: 없으면 `없음`
+
+## 범위 제외
+
+- 이번 패킷에서 다루지 않을 것
+- foundation 패킷이면 실제 기능 구현, 세부 UI 완성, 비즈니스 로직은 범위 제외로 분리한다.
+```