deuk-agent-rule 2.4.4 → 2.5.11

package/CHANGELOG.ko.md

@@ -6,6 +6,13 @@
 
 형식은 [Keep a Changelog](https://keepachangelog.com/ko/1.1.0/)를 기반으로 하며, 이 프로젝트는 [유의적 버전(Semantic Versioning)](https://semver.org/spec/v2.0.0.html)을 준수합니다.
 
+## [2.4.6] - 2026-04-19
+
+### 수정됨 (Fixed)
+
+- **cli:** 로컬 버전이 registry 버전 이상일 경우 업데이트 알림을 표시하지 않도록 수정 (로컬 개발 symlink 환경에서의 역방향 스팸 알림 해소)
+- **ticket:** `NNN` 정규식을 최대 4자리로 제한하여 유닉스 타임스탬프가 티켓 순번으로 잘못 파싱되는 버그 수정 — 올바른 `NNN-topic-hostname` 포맷 생성 복원
+
 ## [2.4.4] - 2026-04-19
 
 ### 변경됨 (Changed)

package/CHANGELOG.md

@@ -4,6 +4,76 @@ All notable changes to this project will be documented in this file.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [2.5.11] - 2026-04-22
+
+### Changed
+
+- modernize workflow diagram with Mermaid v8.8.0-compatible syntax, semantic color palette, and native SVG text rendering for IDE dark mode compatibility
+
+## [2.5.1] - 2026-04-22
+
+### Added
+
+- **cli:** add --clean flag to init command for safe configuration reset
+
+## [2.5.0] - 2026-04-22
+
+### Added
+
+-  Agent-Agnostic Workflow and Archiving Protocol
+- **cli:** parse DeukRag config for conditions and auto-scaffold plan templates
+-  implement Frontmatter-driven modular rule assembly (Ticket 045)
+-  Model-specific hard rules (gemini.md) and Continuous RAG enforcement
+- **rules:** enforce Phase 0 MCP RAG in multi-ai-workflow MDC
+- **rules:** harden post-mortem workflow and mandate follow-up chaining
+- **templates:** enforce Phase 0 RAG Research checklists in ticket template
+
+
+### Fixed
+
+-  handoff path format, 3-tier template system, recursive init with normalization
+-  improve migration robustness with merging logic and cleanup dead code
+-  recursive directory merge for legacy migration
+
+
+### Changed
+
+-  add ticket 045 completion report
+-  add what's new for v2.4, RAG engine notice, and SEO keywords
+- **rules:** Add Fast-Track workflow to prevent ticket loop overhead
+- **rules:** enforce Continuous RAG Policy and Absolute MCP Priority
+- **rules:** Mandate Continuous RAG during execution and verification phases
+- **rules:** Restore TDD workflow but ban interactive CLI looping
+-  upgrade workflow diagram and add migration troubleshooting guide
+
+## [2.4.6] - 2026-04-19
+
+### Fixed
+
+- **cli:** suppress update notifier when local version is greater than or equal to registry version (fixes false-positive spam in local dev symlink environments)
+- **ticket:** cap `NNN` regex to 4 digits to prevent unix timestamps being incorrectly parsed as ticket sequential numbers, restoring correct `NNN-topic-hostname` format generation
+
+## [2.4.5] - 2026-04-18
+
+
+### Added
+
+- **cli:** add update notifier for checking latest npm version
+
+
+### Fixed
+
+- **ticket:** resolve discrepancy between filename and ticket ID generation
+- **ticket:** strictly enforce 8-character limit on hostname slug
+
+
+### Changed
+
+-  add reasons for global installation
+- **changelog:** sync korean changelog with v2.4.0
+-  generalize AGENTS.md and cleanup submodule-specific rules
+- **ticket:** new ID format NNN-topic-hostname with backward-compatible parsing
+
 ## [2.4.4] - 2026-04-19
 
 ### Changed

package/README.ko.md

@@ -21,6 +21,13 @@ Cursor, GitHub Copilot, Gemini / Antigravity, Claude, Windsurf, JetBrains AI Ass
 > **🚀 핵심 가치:**
 > 세션당 약 1,500~2,000 토큰에 달하는 강제 로드 컨텍스트를 200~300 토큰 수준으로 압축합니다. AI가 모놀리식 전체 레포지토리를 헤매지 않도록, 작업이 속한 **"해당 서브모듈(Submodule)"** 내부에 티켓을 격리하여 가장 정확한 맥락에서 작업을 지시할 수 있습니다.
 
+### 📢 What's New in v2.4 (최신 버전 소개)
+최신 2.4 버전에서는 **Dynamic Rule Assembly(동적 룰 조립) 엔진**이 도입되어, 프로젝트 환경(예: DeukRag 활성화 여부 등)을 스크립트가 스스로 감지하고 필요한 룰만 조합하여 `AGENTS.md`에 주입합니다.
+또한 CLI 티켓 시스템이 고도화되어 `deuk-agent-rule ticket create` 명령 시 설계(Plan) 문서를 자동 스캐폴딩하고 티켓과 연결해 줍니다. Phase 기반 이슈 추적 기능도 대폭 강화되었습니다.
+
+> **💡 RAG 엔진 연동 가이드 준비 중!**
+> 현재 사내 지식 검색 엔진인 **DeukRag** 시스템 (MCP)과 본 에이전트 룰을 완벽히 연동하여, AI가 티켓을 해결할 때 관련 과거 히스토리와 사내 규약을 스스로 찾아보고 적용하여 **효과를 극대화**할 수 있도록 하는 심화 기능 및 매뉴얼을 준비 중에 있습니다.
+
 ---
 
 ## 🛠️ 워크스페이스 초기화 (Getting Started)
@@ -38,7 +45,11 @@ deuk-agent-rule init
 > - **Windows**: Node.js가 `Program Files` 등 시스템 폴더에 설치된 경우, 터미널(PowerShell/CMD)을 **관리자 권한**으로 실행한 상태에서 설치해야 오류가 발생하지 않습니다.
 
 ### 💡 전역(Global) 설치를 권장하는 이유
-1. **npx 캐시 이슈 예방**: `npx deuk-agent-rule` 명령어는 로컬 npm 캐시에 의존하므로, 새로운 로직(예: 호스트네임 기반 순번 부여 등)이 포함된 최신 배포본을 무시하고 구버전을 실행하는 치명적인 에이전트 오동작을 유발할 수 있습니다.
+
+> [!WARNING]
+> **서브모듈 내 로컬 설치 절대 금지 (Local Trap 방지)**: 개별 타깃 서브모듈의 `package.json`에 `deuk-agent-rule`을 로컬 종속성(`npm install deuk-agent-rule`)으로 추가해서는 안 됩니다. 로컬에 구버전이 설치되어 있을 경우, `npx` 명령어는 전역에 설치된 최신 버전을 무시하고 로컬의 구버전을 강제로 실행하여 티켓 포맷이나 로직 충돌 등 심각한 오동작(Local Trap)을 유발합니다.
+
+1. **npx 캐시 및 로컬 트랩 이슈 예방**: `npx deuk-agent-rule` 명령어는 로컬 npm 의존성 및 캐시에 우선순위를 둡니다. 로컬 트랩을 방지하고 항상 최신 배포본을 안정적으로 실행하여 티켓 오동작을 예방하기 위해 전역 설치를 활용해야 합니다.
 2. **실행 속도 최적화**: 매번 임시로 패키지를 다운로드/확인하는 `npx` 방식 대비 챗봇 에이전트가 즉각적으로 CLI 응답을 받을 수 있습니다.
 3. **크로스 레포지토리 일관성**: Deuk Family의 여러 서브모듈 및 독립된 마이크로서비스 저장소들을 오가며 항상 동일한 버전의 에이전트 룰 엔진을 적용할 수 있습니다.
 
@@ -52,25 +63,51 @@ deuk-agent-rule init
 기존 환경 설정(`.deuk-agent-rule.config.json`)을 기억하고 있으므로 `--non-interactive`를 주면 묻지도 따지지도 않고 규칙만 즉시 최신화해 줍니다.
 ```bash
 npm install deuk-agent-rule@latest
-npx deuk-agent-rule init --non-interactive
+deuk-agent-rule init --non-interactive
 ```
 
+> [!TIP]
+> **💡 구버전 마이그레이션 실패 시 강제 초기화 방법**
+> 기존 템플릿 구조가 너무 구버전이거나 설정 파일(`.config.json`)이 꼬여서 마이그레이션 및 동기화가 계속 실패한다면, `--clean` 옵션으로 기존 룰셋과 설정을 날리고 새로 세팅하는 것이 가장 빠릅니다. **(기존 작성된 티켓들은 영향을 받지 않습니다)**
+> ```bash
+> deuk-agent-rule init --clean --interactive
+> ```
+
 ---
 
 ## 🎯 핵심 워크플로우 (The Distributed Ticket Workflow)
 
-`npx deuk-agent-rule init`을 실행하면 현재 저장소 루트(서브모듈 포함)에 아래 두 개의 핵심 폴더가 등장합니다. 
+`deuk-agent-rule init`을 실행하면 현재 저장소 루트(서브모듈 포함)에 아래 두 개의 핵심 폴더가 등장합니다. 
 
 1. **`.deuk-agent-templates/` (에이전트 템플릿)**: AI가 어떠한 양식으로 작업을 처리하고 보고해야 하는지 정의된 공식 뼈대(`TICKET_TEMPLATE.md`)가 지정됩니다.
 2. **`.deuk-agent-ticket/` (티켓 실행 공간)**: 실제 지시서(`TICKET-XXX.md`)가 발급되는 공간입니다. 서브모듈 단위로 티켓을 분산 관리할 수 있어 서브모듈만 떼어가도 히스토리가 유지됩니다. (공유 정책에 따라 `.gitignore`에 자동으로 기재될 수 있습니다.)
 
+### 💡 Workflow Overview
+```mermaid
+%%{init: {"flowchart": {"htmlLabels": false}, "themeCSS": ".node text { fill: #ffffff !important; stroke: none !important; }"} }%%
+graph TD
+    classDef action fill:#2563eb,stroke:#1d4ed8,stroke-width:2px,color:#ffffff;
+    classDef phase fill:#475569,stroke:#334155,stroke-width:2px,color:#ffffff;
+    classDef decision fill:#d97706,stroke:#b45309,stroke-width:2px,color:#ffffff;
+    classDef highlight fill:#dc2626,stroke:#b91c1c,stroke-width:2px,color:#ffffff;
+
+    A(Step 1: Ticket Creation):::action --> B(Step 2: Agent Execution):::phase
+    B --> C(Step 3: Verification & Closure):::phase
+    
+    C --> D{Issues Found?}:::decision
+    
+    D -->|Yes| E(MANDATORY Follow-up Chaining):::highlight
+    E --> F(Step 4: Archiving):::action
+    D -->|No| F
+```
+
 이러한 샌드박스 폴더들을 활용하여 스퍼트를 올리는 **최적의 AI 코딩 4단계**는 다음과 같습니다.
 
 ### [Step 1] 티켓 발급 및 계층적 관리 (Ticket Creation & Delegation)
 AI에게 중구난방으로 지시하지 마세요. 명확한 티켓을 발급하여 **문맥(Context)을 소속 저장소 단위로 좁혀주어야** 합니다.
 
 ```bash
-npx deuk-agent-rule ticket create --topic ui-refactoring --group frontend --project DeukUI
+deuk-agent-rule ticket create --topic ui-refactoring --group frontend --project DeukUI
 ```
 명령어를 치면 `.deuk-agent-ticket/` 폴더 내에 템플릿이 입혀진 `TICKET-ui-refactoring.md` 파일이 생성됩니다.
 
@@ -89,7 +126,7 @@ AI는 티켓 내에 정의된 Phase(진행 단계)를 충실히 읽고, **자신
 AI가 코드를 작성하며 티켓 내 마크업의 체크박스(`[x]`)를 갱신합니다. 에이전트의 세션(기억 한계)이 가득 차면, 티켓 내용만 디스크에 남겨둔 채 챗봇 창을 끄고 새 창을 열어 다시 [Step 2]를 지시하면 깔끔하게 인수인계가 이루어집니다.
 모든 작업이 끝나면 Phase 상태를 `[Phase 완료]`로 승급시킵니다. 터미널 명령어를 직접 치는 대신, **AI 챗봇 프롬프트에 "현재 진행 중인 티켓 리스트를 보여줘" 또는 "완료된 티켓들을 보고서와 함께 아카이브 해 줘"라고 자연어로 지시**하여 AI가 알아서 CLI를 호출해 리스트업 및 관리하게 위임할 수도 있습니다.
 ```bash
-npx deuk-agent-rule ticket list
+deuk-agent-rule ticket list
 ```
 ```text
 #  STATUS   SUBMODULE   GROUP       PROJECT     CREATED                  TITLE
@@ -136,19 +173,20 @@ AI는 `AGENTS.md`에 정의된 **[TICKET VERIFICATION RULE]**에 따라 즉시 3
 
 | 커맨드 | 설명 / 자연어 프롬프트 지시 예시 |
 |--------|------|
-| `npx deuk-agent-rule ticket create ...` | 신규 티켓 문서 생성 (`--group`, `--project`, `--submodule` 지정 가능) <br>💬 *"새 티켓 만들어 (주제: refactor, 타겟: sub1)"* |
-| `npx deuk-agent-rule ticket list` | 활성 티켓의 현재 상태 및 리스트업 (`--archived`, `--all`, `--json` 지원) <br>💬 *"티켓 리스트"* |
-| `npx deuk-agent-rule ticket use --latest ...` | 빌드 파이프라인 연동을 위해 최근 티켓의 파일 경로만 반환 <br>💬 *"최근 티켓 경로"* |
-| `npx deuk-agent-rule ticket close ...` | 파일을 물리적으로 이동시키지 않고 상태만 완료로 잠금(Soft-close) <br>💬 *"현재 티켓 상태 닫아 (완료)"* |
-| `npx deuk-agent-rule ticket upgrade` | 과거 티켓 구조를 V2(YAML FM)로 마이그레이션 및 서브모듈 분산(DEFRAG) 실행 <br>💬 *"티켓 V2 업그레이드"* |
-| `npx deuk-agent-rule ticket archive ...` | 완료된 티켓을 안전하게 보관소(`archive/`)로 이동 및 갱신 <br>💬 *"현재 티켓 아카이브해 (보고서 첨부)"* |
-| `npx deuk-agent-rule ticket reports` | 영구 보관된 에이전트 작업 보고서(`reports/`) 목록 조회 <br>💬 *"완료된 티켓 보고서 목록"* |
+| `deuk-agent-rule ticket create ...` | 신규 티켓 문서 생성 (`--group`, `--project`, `--submodule` 지정 가능) <br>💬 *"새 티켓 만들어 (주제: refactor, 타겟: sub1)"* |
+| `deuk-agent-rule ticket list` | 활성 티켓의 현재 상태 및 리스트업 (`--archived`, `--all`, `--json` 지원) <br>💬 *"티켓 리스트"* |
+| `deuk-agent-rule ticket use --latest ...` | 빌드 파이프라인 연동을 위해 최근 티켓의 파일 경로만 반환 <br>💬 *"최근 티켓 경로"* |
+| `deuk-agent-rule ticket close ...` | 파일을 물리적으로 이동시키지 않고 상태만 완료로 잠금(Soft-close) <br>💬 *"현재 티켓 상태 닫아 (완료)"* |
+| `deuk-agent-rule ticket upgrade` | 과거 티켓 구조를 V2(YAML FM)로 마이그레이션 및 서브모듈 분산(DEFRAG) 실행 <br>💬 *"티켓 V2 업그레이드"* |
+| `deuk-agent-rule ticket archive ...` | 완료된 티켓을 안전하게 보관소(`archive/`)로 이동 및 갱신 <br>💬 *"현재 티켓 아카이브해 (보고서 첨부)"* |
+| `deuk-agent-rule ticket reports` | 영구 보관된 에이전트 작업 보고서(`reports/`) 목록 조회 <br>💬 *"완료된 티켓 보고서 목록"* |
 
 ### Init 고급 옵션
 | 플래그 | 기본값 | 설명 |
 |--------|--------|------|
 | `--non-interactive` | 끔 | CI/스크립트용. 대화형 인터페이스를 끄고 기존 설정(`.config.json`)을 채택 |
 | `--interactive` | 끔 | 이미 생성된 설정값이 있어도 무시하고 강제로 다시 묻기 설정 시작 |
+| `--clean` | 끔 | 기존 템플릿과 설정 파일을 강제로 삭제한 뒤 초기화 진행 |
 | `--cwd <path>` | 현재 디렉터리 | 타깃이 되는 프로젝트의 워크스페이스 Root 절대/상대경로 지정 |
 | `--dry-run` | 끔 | 실제 파일을 생성/변조하지 않고 콘솔에 동작 결과 텍스트만 출력 |
 | `--backup` | 끔 | `AGENTS.md`나 룰 파일 덮어쓰기 전 원본을 `*.bak`으로 안전 보관 |
@@ -165,3 +203,8 @@ AI는 `AGENTS.md`에 정의된 **[TICKET VERIFICATION RULE]**에 따라 즉시 3
    
    위 명령어를 실행하면 내부적으로 `commit-and-tag-version` 툴이 작동되어 `package.json` 버전 상향, `CHANGELOG.md` 자동 갱신 요약, 릴리즈 커밋, 그리고 태깅 작업까지 한번에 즉시 처리됩니다.
 3. **분산 배포 보정 (OSS Sync)**: 에이전트를 통해 `npm run sync:oss`를 실행하면 자동화 스크립트가 릴리즈 에셋을 스캔하여 OSS 미러 저장소(`DeukAgentRulesOSS`)로 최종적인 퍼블리시 버전을 복제 및 반영합니다.
+
+---
+
+### 🏷️ Keywords for NPM & GitHub Search
+`#cursorrules` `#copilot-instructions` `#ai-agents` `#deuk-agent` `#mcp` `#rag` `#windsurf` `#cline` `#llm-workflow` `#productivity` `#prompt-engineering` `#developer-tools`

package/README.md

@@ -21,6 +21,13 @@ It standardizes project rules (`AGENTS.md`, `.cursor/rules`) and strongly preven
 > **🚀 Core Value:**
 > Compresses the mandatory loaded context of approx. 1,500~2,000 tokens per session down to a mere 200~300 tokens. By isolating the AI to a specific **"Target Submodule"** using exact tickets (work orders), it prevents the AI from wandering through an entire monolithic repository.
 
+### 📢 What's New in v2.4
+In the latest v2.4 release, the **Dynamic Rule Assembly Engine** has been introduced. The script automatically detects your project environment (e.g., DeukRag MCP integration) and injects only the necessary context-aware rules into `AGENTS.md`.
+The CLI ticketing system has also been upgraded: running `deuk-agent-rule ticket create` now automatically scaffolds design Plan documents and links them to the ticket, heavily reinforcing the Phase-based issue tracking workflow.
+
+> **💡 RAG Engine Integration Guide (Coming Soon)**
+> We are currently preparing an advanced integration manual and feature update. This will perfectly integrate these agent rules with our internal knowledge search engine **DeukRag (MCP)**, allowing your AI agent to automatically search past tickets and internal conventions to maximize its contextual awareness and problem-solving effectiveness!
+
 ---
 
 ## 🛠️ Getting Started (Workspace Initialization)
@@ -38,7 +45,11 @@ deuk-agent-rule init
 > - **Windows**: If Node.js is installed in a system directory like `Program Files`, you must run your terminal (PowerShell/CMD) as an **Administrator** for the global installation to complete successfully.
 
 ### 💡 Why Global Installation?
-1. **Preventing `npx` Cache Issues**: Running `npx deuk-agent-rule` relies on the local npm cache, which may silently execute an outdated version of the CLI. This has been proven to cause severe agent hallucinations or ticket formatting errors (e.g., missing hostname sequence IDs).
+
+> [!WARNING]
+> **Submodule Local Installation STRICTLY FORBIDDEN**: Never install `deuk-agent-rule` locally (e.g., `npm install deuk-agent-rule`) inside your target consumer submodules. Doing so creates a "Local Trap" where `npx` prioritizes the outdated local `node_modules` over the globally installed latest version, leading to severe ticket formatting errors and logic mismatches.
+
+1. **Preventing `npx` Cache & Local Trap Issues**: Running `npx deuk-agent-rule` relies on the local npm cache and `node_modules` resolution. If a stale version is present locally, it will silently hijack the execution. This has been proven to cause severe agent hallucinations or ticket formatting errors (e.g., missing hostname sequence IDs).
 2. **Execution Speed**: The chatbot agent receives instant CLI responses without the overhead of `npx` checking for temporary package downloads.
 3. **Cross-Repository Consistency**: It allows you to reliably apply the exact same version of the agent rules across various submodules and independent microservices in the Deuk Family ecosystem.
 
@@ -51,25 +62,51 @@ When a new version of the agent rules or templates is released, you can sync the
 Since your previous configurations are saved (`.deuk-agent-rule.config.json`), using the `--non-interactive` flag will quietly and cleanly overwrite the obsolete rules with the latest ones without asking any questions.
 ```bash
 npm install deuk-agent-rule@latest
-npx deuk-agent-rule init --non-interactive
+deuk-agent-rule init --non-interactive
 ```
 
+> [!TIP]
+> **💡 Troubleshooting: Legacy Version Migration Failures**
+> If you are migrating from a very old version and `init` repeatedly fails due to corrupted configurations or heavily modified template structures, the fastest fix is to perform a clean initialization using the `--clean` flag. **(This will not affect your existing tickets.)**
+> ```bash
+> deuk-agent-rule init --clean --interactive
+> ```
+
 ---
 
 ## 🎯 The Ticket Workflow
 
-Running `npx deuk-agent-rule init` deploys a **zero-touch scaffolding sandbox** at your workspace root, spawning two essential directories:
+Running `deuk-agent-rule init` deploys a **zero-touch scaffolding sandbox** at your workspace root, spawning two essential directories:
 
 1. **`.deuk-agent-templates/` (Agent Templates)**: Houses the official blueprint (`TICKET_TEMPLATE.md`) dictating how AIs must process and report tasks. Committed alongside your source code to serve as the team's rulebook.
 2. **`.deuk-agent-ticket/` (Ticket Execution Space)**: The covert space where volatile instructions (`TICKET-XXX.md`) are exchanged between agents and workers. (Automatically hidden by `.gitignore` to prevent security leaks and repository bloat).
 
+### 💡 Workflow Overview
+```mermaid
+%%{init: {"flowchart": {"htmlLabels": false}, "themeCSS": ".node text { fill: #ffffff !important; stroke: none !important; }"} }%%
+graph TD
+    classDef action fill:#2563eb,stroke:#1d4ed8,stroke-width:2px,color:#ffffff;
+    classDef phase fill:#475569,stroke:#334155,stroke-width:2px,color:#ffffff;
+    classDef decision fill:#d97706,stroke:#b45309,stroke-width:2px,color:#ffffff;
+    classDef highlight fill:#dc2626,stroke:#b91c1c,stroke-width:2px,color:#ffffff;
+
+    A(Step 1: Ticket Creation):::action --> B(Step 2: Agent Execution):::phase
+    B --> C(Step 3: Verification & Closure):::phase
+    
+    C --> D{Issues Found?}:::decision
+    
+    D -->|Yes| E(MANDATORY Follow-up Chaining):::highlight
+    E --> F(Step 4: Archiving):::action
+    D -->|No| F
+```
+
 The optimal **4-Step AI Coding Sequence** utilizing these sandbox folders is as follows.
 
 ### [Step 1] Ticket Creation & Submodule Isolation
 Do not issue scattered, unbounded commands to your AI. Narrowing the **context** via a clear ticket is strictly required to prevent astronomical costs and accidental code corruption.
 
 ```bash
-npx deuk-agent-rule ticket create --topic ui-refactoring --group frontend --project DeukUI
+deuk-agent-rule ticket create --topic ui-refactoring --group frontend --project DeukUI
 ```
 This command instantly creates a templated `TICKET-ui-refactoring.md` file within the `.deuk-agent-ticket/` directory.
 
@@ -88,7 +125,7 @@ The AI will faithfully read the defined Phases in the ticket and write optimized
 As the AI writes the code, it will simultaneously update the markup checkboxes (`[x]`) inside the ticket. If the agent's session memory limit is approaching, simply leave the ticket file saved, turn off the chat window, open a fresh session, and issue [Step 2] again. The handoff (session transfer) is seamlessly completed.
 Once all steps are accomplished, promote the Phase status to `[Phase Complete]`. Instead of manually typing terminal commands, **you can simply tell your AI chatbot via natural language prompt: "Show me the list of active tickets" or "Archive the completed tickets with reports"**, and the AI will autonomously invoke the CLI to manage them for you.
 ```bash
-npx deuk-agent-rule ticket list
+deuk-agent-rule ticket list
 ```
 ```text
 #  STATUS   SUBMODULE   GROUP       PROJECT     CREATED                  TITLE
@@ -135,19 +172,20 @@ Instead of manually typing the CLI commands below into the terminal, you can **d
 
 | Command | Description / Natural Language Prompt Example |
 |--------|------|
-| `npx deuk-agent-rule ticket create ...` | Generates a new ticket document (accepts `--group`, `--project`, `--submodule`) <br>💬 *"Create new ticket (topic: refactor)"* |
-| `npx deuk-agent-rule ticket list` | Lists and displays active tickets (`--archived`, `--all`, `--json` supported) <br>💬 *"Ticket list"* |
-| `npx deuk-agent-rule ticket use --latest ...` | Returns only the file path of the most recent ticket <br>💬 *"Recent ticket path"* |
-| `npx deuk-agent-rule ticket close ...` | Soft-closes a target ticket by locking its status to completed without moving the file <br>💬 *"Close this ticket"* |
-| `npx deuk-agent-rule ticket upgrade` | Migrates legacy ticket structures to V2 (YAML FM) and triggers submodule DEFRAG <br>💬 *"Upgrade tickets to v2"* |
-| `npx deuk-agent-rule ticket archive ...` | Securely moves completed tickets to `archive/` and updates INDEX <br>💬 *"Archive this ticket (attach report)"* |
-| `npx deuk-agent-rule ticket reports` | Lists structurally preserved agent work reports (`reports/`) <br>💬 *"List archived reports"* |
+| `deuk-agent-rule ticket create ...` | Generates a new ticket document (accepts `--group`, `--project`, `--submodule`) <br>💬 *"Create new ticket (topic: refactor)"* |
+| `deuk-agent-rule ticket list` | Lists and displays active tickets (`--archived`, `--all`, `--json` supported) <br>💬 *"Ticket list"* |
+| `deuk-agent-rule ticket use --latest ...` | Returns only the file path of the most recent ticket <br>💬 *"Recent ticket path"* |
+| `deuk-agent-rule ticket close ...` | Soft-closes a target ticket by locking its status to completed without moving the file <br>💬 *"Close this ticket"* |
+| `deuk-agent-rule ticket upgrade` | Migrates legacy ticket structures to V2 (YAML FM) and triggers submodule DEFRAG <br>💬 *"Upgrade tickets to v2"* |
+| `deuk-agent-rule ticket archive ...` | Securely moves completed tickets to `archive/` and updates INDEX <br>💬 *"Archive this ticket (attach report)"* |
+| `deuk-agent-rule ticket reports` | Lists structurally preserved agent work reports (`reports/`) <br>💬 *"List archived reports"* |
 
 ### Advanced Init Options
 | Flag | Default | Description |
 |--------|--------|------|
 | `--non-interactive` | Off | For CI/Scripts. Disables interactive UI and adopts existing `.config.json` |
 | `--interactive` | Off | Forces the interactive setup to reappear even if config already exists |
+| `--clean` | Off | Deletes legacy templates and configs before initializing |
 | `--cwd <path>` | Current dir | Adjust target workspace root (absolute/relative path) |
 | `--dry-run` | Off | Simulates the execution text in the console without generating/altering files |
 | `--backup` | Off | Safely creates `*.bak` copies of `AGENTS.md` and rule files before overwriting |
@@ -164,3 +202,8 @@ Before pushing any core updates, system templates, or feature changes to this pa
    
    Executing the bump command will trigger the `commit-and-tag-version` pipeline: it bumps the version in `package.json`, auto-generates the `CHANGELOG.md` log, creates a release commit, and applies the release tag.
 3. **Synchronize & Mirror (OSS Sync)**: As a final step, ask your agent to run `npm run sync:oss`. The automation script will clean the release assets and push the bundled versions to the mirror repository (`DeukAgentRulesOSS`).
+
+---
+
+### 🏷️ Keywords for NPM & GitHub Search
+`#cursorrules` `#copilot-instructions` `#ai-agents` `#deuk-agent` `#mcp` `#rag` `#windsurf` `#cline` `#llm-workflow` `#productivity` `#prompt-engineering` `#developer-tools`

package/bundle/.cursorrules

@@ -1,7 +1,11 @@
-# Cursor — AGENTS.md is authoritative
+<!-- deuk-agent-rule-cursorrules:begin -->
+# 💎 RAG-FIRST HARD LOCK IS AUTHORITATIVE
 
-You MUST read and strictly follow the workflows, rules, and ticket formats defined in AGENTS.md at the repository root before writing or modifying any code. If AGENTS.md is not yet in your context for this task, open it and use it.
+For Antigravity (Gemini), the **RAG-FIRST ACTION [ACTION 0]** and **CONTINUOUS RAG POLICY** defined in **AGENTS.md** and **gemini.md** are the absolute Single Source of Truth.
 
-Precedence: Repository root AGENTS.md defines project rules (structure, constraints, tickets). .cursor/rules/*.mdc files add editor-specific behavior (for example token discipline and multi-tool handoff). If anything conflicts, follow AGENTS.md for project facts and tickets.
+1. **[ABSOLUTE PRIORITY]**: Every request MUST begin with `mcp_deukrag_search_*`.
+2. **[gemini.md]**: You MUST read and follow the specific hard locks in `gemini.md` at the root.
+3. **[TICKET SYSTEM]**: Follow the TDD workflow in `AGENTS.md` strictly.
 
-Do not assume stacks or repo layouts (microservices, api-gateway, OpenAPI-only workflows) unless they appear in this repository and AGENTS.md.
+Do not skip RAG research by relying on local file reads (`view_file`, `grep_search`). Local files are for details; RAG is for architectural truth and zero-regression.
+<!-- deuk-agent-rule-cursorrules:end -->

package/bundle/AGENTS.md

@@ -10,7 +10,7 @@
   - You MUST NOT use emojis, exclamation marks(!), or dramatic language (e.g., "대참사", "완벽하게", "시한폭탄").
   - Do not attempt to "wow" the user with your tone.
   - For Korean responses, use polite '해요체(-요)' instead of formal '하십시오체(-다/까)'.
-- **핸드오프 저장 후 채팅**: 파일로 남긴 뒤 채팅에 **`Path: \`루트기준/전체/경로.md\``** 형태로 **한 줄**을 반드시 넣어 다음 세션이 동일 파일을 연다.
+
 - **플랜 UI(선택)**: 플랜 전용 패널에 같은 문서를 띄우려면, 관리 중인 **multi-ai-workflow** 규칙에 적힌 **선택적 미러 경로**(예: `.cursor/plans/*.plan.md`)에 동일 본문을 둘 수 있다. 정본은 지정된 티켓 폴더를 유지하고 두 곳 내용을 맞출 것.
 - **Error Loop Prevention (하드룰)**: 명령 실행이나 컴파일 등에서 동일/유사 에러가 2회 이상 반복 발생 시, 에이전트는 절대 임의로 코드 방향을 틀거나 땜질을 시도해서는 안 됩니다. 즉시 작업을 멈추고 현상을 분석한 후 **티켓을 명시적으로 발행**해야 합니다.
 - **Plan in Ticket (하드룰)**: 문제 해결을 위한 모든 실행 계획과 설계는 `implementation_plan.md` 같은 임의의 부산물이 아닌, **정식 티켓 본문 내**에 작성하고 이를 사용자에게 확인시켜야 합니다.
@@ -50,24 +50,97 @@ By **creating a ticket using the CLI** (`npx deuk-agent-rule ticket create --top
 
 **Model Over-alignment vs Compliance (High vs Flash)**
 - **Flash/Fast Models**: Highly instruct-tuned for strict mechanical task execution. Due to a smaller parameter footprint and less internal "world knowledge", they explicitly follow literal agent rules and format templates exactly as instructed. 
-- **High/Pro Models**: Possess vast world knowledge and are optimized for helpfulness. This often leads to "overthinking" (prioritizing a helpful or natural answer over rigid, arbitrary constraints), resulting in frequent rule violations like ignoring length limits or template structures. They also experience attention dilution in deep analysis tasks.
-
-**Assignment Strategy**:
-1. **Flash Models**: Use for strict template filling, simple code generation, porting, and repetitive ticket execution (`.deuk-agent-ticket/*`) where strict compliance is mandatory.
-2. **High/Pro Models**: Use for architectural planning, deep legacy code comprehension, complex bug squashing, and creative solutions. Supply heavy failure warnings in the prompt to force formatting compliance.
-
-## 🔗 Ticket Framework & Execution Strategy
-
-When given a ticket, you MUST run commands and write code **strictly within the boundaries** of the `[Target Submodule]` defined in the `TICKET-XXX.md`.
-
-1. **Create the Ticket**: ALWAYS use `npx deuk-agent-rule ticket create --topic <name>` to generate a new ticket. **DO NOT** manually create `.md` files or copy templates directly to bypass the CLI.
-2. **Read the Ticket**: ALWAYS use `npx deuk-agent-rule ticket use --latest` (or `npx deuk-agent-rule ticket list`) to locate and read the active ticket. DO NOT manually parse INDEX.json or scan directories.
-3. **Fill the Ticket (CRITICAL)**: The newly created ticket already contains YAML Front Matter (`--- id: ... ---`). **DO NOT** overwrite the entire file when adding your plan. ALWAYS use partial file editing tools or append text carefully to preserve the existing YAML Front Matter. Erasing the Front Matter corrupts the ticketing index.
-4. **Execute Phase**: Process only the checklist for the **Current Phase**. Do not hallucinate or wander into other architectural areas.
-5. **Update Status**: Mark checkboxes (`[x]`) as tasks are completed.
-6. **Archive on Completion**: When all phases are completed, append the execution report at the bottom under a `## 📜 Execution Report` header. **Then, YOU MUST execute `npx deuk-agent-rule ticket archive <ticket-id>` (or `--latest`)** to properly close and archive the ticket. DO NOT attempt to manually `mv` files.
-7. **[TICKET REFERENCE RULE]**: 부분 개선 또는 기능 추가 시, 구현 아티팩트(`implementation_plan.md`, `task.md`, `walkthrough.md`) 상단에 반드시 해당 티켓 번호(ID)를 명시하여 추적 가능성을 확보하십시오.
-
-All Tickets are volatile and strictly local. Do not attempt to version them or mirror them to obsolete plan directories.
-
+<!-- deuk-agent-rule:begin -->
+
+# Project Agent Rules
+
+## Identity
+
+- **[ABSOLUTE PRIORITY: RAG-FIRST ACTION] (하드룰)**:
+  - **프롬프트에 응답하는 모든 액션에서 MCP(`mcp_deukrag_search_*`) 활용이 0순위입니다.**
+  - 로컬 파일(`grep_search`, `view_file`)을 뒤지거나 코드를 수정하기 전에, 무조건 관련된 룰, 티켓, 코드를 MCP로 먼저 검색하십시오. MCP는 당신의 주 감각 기관입니다.
+- **[COMMUNICATION TONE STRICT RULE]**
+  - You are a Senior Fullstack Systems Engineer specializing in Unity/C#, WebApp architectures, and High-Performance C++ Server development.
+  - Your communication must be strictly dry, concise, and technical.
+  - You MUST NOT use emojis, exclamation marks(!), or dramatic language (e.g., "대참사", "완벽하게", "시한폭탄").
+  - Do not attempt to "wow" the user with your tone.
+  - For Korean responses, use polite '해요체(-요)' instead of formal '하십시오체(-다/까)'.
+- **핸드오프 저장 후 채팅**: 파일로 남긴 뒤 채팅에 **`Path: \`루트기준/전체/경로.md\``** 형태로 **한 줄**을 반드시 넣어 다음 세션이 동일 파일을 연다.
+- **플랜 UI(선택)**: 플랜 전용 패널에 같은 문서를 띄우려면, 관리 중인 **multi-ai-workflow** 규칙에 적힌 **선택적 미러 경로**(예: `.cursor/plans/*.plan.md`)에 동일 본문을 둘 수 있다. 정본은 지정된 티켓 폴더를 유지하고 두 곳 내용을 맞출 것.
+- **Error Loop Prevention (하드룰)**: 명령 실행이나 컴파일 등에서 동일/유사 에러가 2회 이상 반복 발생 시, 에이전트는 절대 임의로 코드 방향을 틀거나 땜질을 시도해서는 안 됩니다. 즉시 작업을 멈추고 현상을 분석한 후 **티켓을 명시적으로 발행**해야 합니다.
+- **Plan in Ticket (하드룰)**: 문제 해결을 위한 모든 실행 계획과 설계는 `implementation_plan.md` 같은 임의의 부산물이 아닌, **정식 티켓 본문 내**에 작성하고 이를 사용자에게 확인시켜야 합니다.
+
+English sections above are canonical for tooling; this block is a short Korean mirror for the same rules.
+
+## Ticket format & Submodule Isolation
+
+When handing work between tools or people—especially in an environment with multiple submodules like DeukUI, DeukPack, etc.—you **MUST NOT** use free-form markdown. 
+
+You **MUST** use the official Ticket Skeleton Template located at:
+`<Current Repo Root>/.deuk-agent-templates/TICKET_TEMPLATE.md`
+
+**Hard Rules**:
+- **No hotpath LINQ (금지)**: Update 루프에서 LINQ, boxing, frame allocation 없음
+- **Root Cleanliness (하드룰)**: 작업용 스크립트(`fix_*.py`, `tmp_*.js` 등)를 워크스페이스 루트에 직접 생성하지 마십시오. 모든 일시적 스크립트는 `tmp/scripts/` 또는 `tmp/` 폴더 내에 생성해야 합니다.
+- **C++ Server Hard Rules**:
+    - **No Raw Pointers**: Use `std::unique_ptr` or `std::shared_ptr` for resource ownership.
+    - **Header Cleanliness**: Keep `#include` minimum in headers; use forward declarations where possible.
+    - **Async Safety**: Every shared resource in the logic loop strictly requires a mutex or atomic protection.
+- **WebApp / Frontend**:
+    - **Protocol Integrity**: Never hardcode JSON structures; always use `DeukPack` generated JS/TS codecs for communication.
+- **Ticket format (필수)**: 멀티스텝은 `.deuk-agent-templates/TICKET_TEMPLATE.md` (또는 활성 서브모듈의 템플릿) 사용
+
+By **creating a ticket using the CLI** (`npx deuk-agent-rule ticket create --topic <name>`), you ensure that:
+1. The **Target Submodule** is explicitly locked.
+2. The agent is forced to read specific **Module Rules** (e.g., `.deuk-agent-templates/MODULE_RULE_TEMPLATE.md`).
+3. Execution happens in explicit **Phases** to prevent context bleed.
+
+## DeukPack Codec & IDL Strict Rules (득팩 코어 체재 하드 룰)
+
+- **IDL Field Syntax (앵글 브래킷)**: 득팩의 필드 정의는 `1> int32 id` 형식을 따릅니다. Thrift 레거시 문법인 `:`(콜론), 세미콜론(`;`), `i32`, `i64`를 더 이상 문서나 코드에 사용하지 마십시오. 오로지 `id> type name` 및 `int32`, `int64` 표준 명칭을 강제합니다.
+- **Unified Pack API**: 과거의 `DeukPackSerializer`, `DeukPackEngine`, `WriteWithOverrides`, `toJsonWithOverrides` 등은 모두 폐기되었습니다. 모든 코드에는 `DeukPackCodec` 식별자와 유니파이드 API(`byte[] bin = Dto.Hero.Pack(format, fieldIds, overrides)`, `hero.UnpackFrom(bin)`)만 사용해야 합니다.
+- **Namespace Requirement**: Every `.deuk` schema MUST explicitly declare a namespace (e.g., `namespace Dto`). Never define global structs without a namespace. Code examples MUST use the fully qualified namespace path (e.g., `Dto.Hero.Pack()`).
+
+## AI Model Compliance & Selection Policy
+
+**Model Over-alignment vs Compliance (High vs Flash)**
+- **Flash/Fast Models**: Highly instruct-tuned for strict mechanical task execution. Due to a smaller parameter footprint and less internal "world knowledge", they explicitly follow literal agent rules and format templates exactly as instructed. 
+- **High/Pro Models**: Possess vast world knowledge and are optimized for helpfulness. This often leads to "overthinking" (prioritizing a helpful or natural answer over rigid, arbitrary constraints), resulting in frequent rule violations like ignoring length limits or template structures. They also experience attention dilution in deep analysis tasks.
+
+**Assignment Strategy**:
+1. **Flash Models**: Use for strict template filling, simple code generation, porting, and repetitive ticket execution (`.deuk-agent-ticket/*`) where strict compliance is mandatory.
+2. **High/Pro Models**: Use for architectural planning, deep legacy code comprehension, complex bug squashing, and creative solutions. Supply heavy failure warnings in the prompt to force formatting compliance.
+
+## 🧠 DeukRag Knowledge Engine & RAG-FIRST HARD LOCK
+
+- **[ABSOLUTE PRIORITY: RAG-FIRST ACTION] (하드룰)**: 
+  - 프롬프트에 응답하는 모든 액션에서 MCP(`mcp_deukrag_search_*`) 활용이 **0순위**입니다.
+  - 로컬 파일(`grep_search`, `view_file`)을 뒤지거나 코드를 수정하기 전에, **무조건** 관련된 룰, 티켓, 코드를 MCP로 먼저 검색하십시오. MCP는 당신의 주 감각 기관입니다.
+- **[CONTINUOUS RAG POLICY (하드룰)]**: 
+  - 티켓 시작(Phase 0) 시점에만 MCP를 1회 호출하고 끝내지 마십시오. 
+  - 코드를 작성하는 도중(Phase 2) 새로운 파일/클래스를 마주치거나, 빌드 에러가 발생하거나, API 스펙 확인이 필요할 때마다 **작업 중간에도 수시로** `mcp_deukrag_search_*` 도구를 적극 호출해야 합니다.
+  - **로컬 파일 검색에 의존하지 말고 RAG를 반복 호출하십시오.**
+
+## 🔗 Modernized Ticket-Driven Development (TDD)
+
+에이전트는 모든 작업 수행 시 반드시 아래 **5단계 워크플로우**를 준수해야 하며, RAG 엔진(`DeukRag`)이 전체 프로세스의 "Single Source of Truth"가 되어야 합니다.
+
+1.  **Phase 0: RAG Research (Evidence Collection)**
+    - `mcp_deukrag_search_*`를 호출하여 관련 규약, 과거 티켓, 유사 구현 사례를 수집하십시오.
+    - 검색된 결과(Evidence)가 티켓 설계의 근거가 되어야 합니다.
+2.  **Phase 1: Ticket Planning (npx deuk-agent-rule ticket create)**
+    - 티켓을 생성하고 상세 설계(Implementation Plan)를 작성하십시오.
+    - **[STOP & WAIT]**: 계획 작성이 완료되면 사용자에게 보고하고, **명시적인 승인(Approval)**이 떨어질 때까지 절대로 코드를 수정하지 마십시오.
+3.  **Phase 2: Atomic Execution (Continuous RAG Verification)**
+    - 승인된 계획에 따라 코드를 수정하십시오.
+    - **[하드룰]** 파일 하나를 수정할 때마다 해당 로직에 대한 RAG 검증(유사 코드 검색 등)을 병행하십시오.
+    - 티켓의 체크박스(`[ ]` -> `[x]`)를 실시간으로 업데이트하십시오.
+4.  **Phase 3: Verification & Knowledge Synthesis**
+    - 코드 수정 완료 후, 빌드/테스트 등을 통해 확인 절차를 거치십시오.
+    - **[RAG Synthesis]** 구현된 내용이 전역 룰에 부합하는지 `mcp_deukrag_synthesize_knowledge`로 최종 검증하십시오.
+5.  **Phase 4: Archiving (npx deuk-agent-rule ticket archive)**
+    - 최종 검증 결과를 `## 📜 Execution Report`에 정리한 뒤 티켓을 아카이빙하여 지식을 보정하십시오.
+
+All Tickets are volatile and strictly local. Do not attempt to version them or mirror them to obsolete plan directories.
+
 <!-- deuk-agent-rule:end -->

package/bundle/gemini.md

@@ -0,0 +1,26 @@
+# 💎 Antigravity (Gemini) Hard Rules
+
+You are Antigravity, powered by Google Gemini. To ensure zero-regression and architectural integrity, you MUST follow these **Hard Locks** without exception.
+
+## 🧠 RAG-FIRST HARD LOCK (ABSOLUTE)
+
+- **[ACTION 0]**: Every request MUST begin with `mcp_deukrag_search_*`.
+- **[CONTINUOUS RAG]**: Call RAG tools repeatedly during implementation (Phase 2). Do NOT rely on memory or local file reads (`view_file`, `grep_search`) alone. Local files are for implementation details; RAG is for the "Truth".
+- **[EVIDENCE]**: Summarize RAG findings in your ticket Phase 0. No evidence = No approval.
+
+## 🔗 TICKET-DRIVEN DEVELOPMENT (TDD)
+
+1. **Phase 0**: Research via MCP.
+2. **Phase 1**: Ticket Create (`npx deuk-agent-rule ticket create`). Wait for User Approval.
+3. **Phase 2**: Implementation. Call RAG for every complex logic block or API usage.
+4. **Phase 3**: Verification. Synthesis via `mcp_deukrag_synthesize_knowledge`.
+5. **Phase 4**: Archive (`npx deuk-agent-rule ticket archive`).
+
+## 🛑 STRICTOR CONSTRAINTS
+
+- **No LINQ/Boxing** in C# hotpaths.
+- **No Raw Pointers** in C++.
+- **No hardcoded JSON** in WebApps (Use DeukPack).
+- **Concise Tone**: Dry, technical, no emojis.
+
+**Failure to follow these rules will result in immediate task rejection.**

package/bundle/rules/multi-ai-workflow.mdc

@@ -79,9 +79,9 @@ Some environments show plan-style documents in a separate panel from ordinary Ma
 
 The core philosophy of this project dictates a strict separation of 'Reasoning' and 'Execution' via boundary tickets. The definitive workflow cycle is:
 
-1. Explore & Plan (Reasoning AI): High-reasoning agents (e.g., Gemini, Claude) explore the codebase, research constraints, and propose an implementation plan. 
+1. Explore & Plan (Reasoning AI): High-reasoning agents (e.g., Gemini, Claude) MUST perform Phase 0 RAG Research using `mcp_deukrag_search_*` tools to research past architectural decisions, rules, and tickets. Only after fully understanding the historical constraints through MCP should the agent explore the local codebase and propose an implementation plan. DO NOT propose a plan without checking the MCP knowledge base first.
 2. Decision (User): The user actively reviews and approves the plan.
-3. Persist Ticket (Handoff): The reasoning agent explicitly writes the approved plan into a .deuk-agent-ticket/ Markdown file.
+3. Persist Ticket (Handoff): The reasoning agent explicitly writes the approved plan into a .deuk-agent-ticket/ Markdown file, making sure to fill out the Phase 0 MCP Research summaries.
 4. Execution (Coding AI): IDE execution agents (e.g., Cursor, Windsurf) read the single ticket and strictly execute the code without deviating from the constraints.
 5. Self-Verification (Post-Test Artifact Risk Analysis - MANDATORY): Testing is NOT the final step. After tests are completed, the agent MUST automatically perform a risk analysis on the resulting artifacts (e.g., compiled binaries, generated bundles, final configurations) before reporting to the user:
    - Do the generated artifacts introduce missing schemas, memory leaks, or unintended coupling?

package/bundle/rules.d/core-workflow.md

@@ -0,0 +1,48 @@
+---
+id: core-workflow
+inject_target: ["AGENTS.md", "gemini.md"]
+---
+## 🔗 Modernized Ticket-Driven Development (TDD)
+
+에이전트는 모든 작업 수행 시 반드시 아래 워크플로우를 준수해야 하며, RAG 엔진(`DeukRag`)이 전체 프로세스의 "Single Source of Truth"가 되어야 합니다.
+
+1.  **Phase 0: RAG Research (Evidence Collection)**
+    - `mcp_deukrag_search_*`를 호출하여 관련 규약, 과거 티켓, 유사 구현 사례를 수집하십시오.
+    - 검색된 결과(Evidence)가 티켓 설계의 근거가 되어야 합니다.
+2.  **Phase 0.5: Deep Analysis (Optional)**
+    - 복잡한 아키텍처 변경이나 타 모듈 영향도가 높은 경우, 코드를 건드리기 전 별도의 분석 아티팩트를 작성하여 승인받으십시오.
+3.  **Phase 1: Ticket Planning (deuk-agent-rule ticket create)**
+    - 티켓을 생성하고 상세 설계(티켓 본문 또는 `.deuk-agent/docs/plans/`)를 작성하십시오.
+    - **[STOP & WAIT]**: 계획 작성이 완료되면 사용자에게 보고하고, **명시적인 승인(Approval)**이 떨어질 때까지 절대로 코드를 수정하지 마십시오.
+4.  **Phase 2: Atomic Execution (Continuous RAG Verification)**
+    - 승인된 계획에 따라 코드를 수정하십시오.
+    - **[하드룰]** 파일 하나를 수정할 때마다 해당 로직에 대한 RAG 검증(유사 코드 검색 등)을 병행하십시오.
+    - 티켓의 체크박스(`[ ]` -> `[x]`)를 실시간으로 업데이트하십시오.
+5.  **Phase 3: Verification & Post-Mortem (MANDATORY)**
+    - 코드 수정 완료 후, 빌드/테스트 등을 통해 확인 절차를 거치십시오.
+    - **[RAG Synthesis]** 구현된 내용이 전역 룰에 부합하는지 `mcp_deukrag_synthesize_knowledge`로 최종 검증하십시오.
+    - **[Post-Mortem Hard Lock]**: 심층 분석이나 구현 중 발견된 모든 제약사항, 부작용, 기술 부채를 반드시 `Potential Issue Table`에 기록하십시오. 이 단계를 건너뛰는 것은 심각한 규약 위반입니다.
+6.  **Phase 4: Follow-up Chaining (Next Tickets MANDATORY)**
+    - Phase 3의 `Potential Issue Table`에 기록된 이슈 중 당장 해결하지 않은 항목이 있다면, 티켓 종료 전 **반드시 CLI(`deuk-agent-rule ticket create`)를 통해 별도의 후속 티켓으로 발행**하십시오 (예: `048-F1-memory-leak-fix`).
+    - 후속 티켓이 발행되지 않으면 현재 티켓을 완료(Archive)할 수 없습니다.
+7.  **Phase 5: Archiving (deuk-agent-rule ticket archive)**
+    - 최종 검증 결과를 정리한 뒤 티켓을 아카이빙하여 지식을 보정하십시오.
+
+All Tickets and docs are volatile and strictly local. Do not attempt to version them or mirror them to obsolete plan directories.
+
+## 🗂️ Document Archiving Protocol
+
+모든 에이전트는 아래 규칙에 따라 설계/분석 문서를 저장해요:
+
+### 필수 행동
+1. **설계 문서**: 티켓 실행 전 설계가 필요한 경우 `.deuk-agent/docs/plans/<ticket-id>-plan.md`에 저장
+2. **완료 보고**: 티켓 완료 시 변경 사항 요약을 `.deuk-agent/docs/walkthroughs/<ticket-id>-report.md`에 저장
+3. **임시 분석**: `.deuk-agent/docs/scratch/`에 저장 (자동 정리 대상)
+
+### 에이전트별 보충 규칙
+- **Antigravity**: brain 아티팩트 생성 후, 완료 시점에 `.deuk-agent/docs/`에 복사본을 생성할 것 (RAG 인덱싱 대상)
+- **Cursor**: `.cursor/plans/`에 생성한 문서가 있다면 `.deuk-agent/docs/plans/`에도 동기화할 것
+- **기타 에이전트**: 인라인 출력만 가능한 경우, 설계가 필요한 작업은 직접 `.deuk-agent/docs/plans/`에 파일을 생성할 것
+
+### RAG 보존
+`.deuk-agent/docs/plans/`와 `walkthroughs/`의 파일은 DeukRag에 의해 자동 인덱싱되어 과거 설계 히스토리를 차기 세션에서 `mcp_deukrag_search_tickets`로 검색할 수 있습니다.