deuk-agent-rule 2.5.13 → 3.3.2

package/bundle/AGENTS.md

@@ -1,146 +0,0 @@
-<!-- deuk-agent-rule:begin -->
-
-# Project Agent Rules
-
-## Identity
-
-- **[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 '하십시오체(-다/까)'.
-
-- **플랜 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. 
-<!-- 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

@@ -1,26 +0,0 @@
-# 💎 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/delivery-and-parallel-work.mdc

@@ -1,26 +0,0 @@
----
-description: Vertical slices, portfolio priority, parallel-branch ownership, scoped refactors
-alwaysApply: true
----
-
-# Delivery, portfolio, and parallel work
-
-## Default shape of work
-
-- Prefer **one PR (or one agent session outcome) = one vertically integrated slice**: buildable, runnable, and **demo-able** end-to-end for that slice. Do not treat “wide refactors with no user-visible behavior” as the default unit of delivery unless the user explicitly asks for that.
-- When the user states **portfolio, demo, or ship-this-week priority**, treat that as **scope authority**: narrow the task to what improves the visible outcome first; defer broad cleanups to a follow-up ticket unless they are blocking the slice.
-
-## Parallel branches and file ownership
-
-- Assume **other branches or developers may be editing the same repo**. Before touching widely shared files (large pages, shared `lib/`, config roots), **minimize blast radius**: prefer a small, well-bounded edit over sweeping moves in the same change set.
-- If the user names an **owner branch, feature lane, or file ownership** (e.g. “UI lane owns `components/`, gameplay owns `lib/game/`”), **stay inside that boundary** unless they explicitly expand it.
-- When parallel work is likely, **call out** touched paths that are high-merge-conflict risk so the user can coordinate; do not silently expand into those files without need.
-
-## Refactor discipline
-
-- **Shrink refactor scope by default**: extract or adjust only what the current task requires. If a larger refactor is tempting, split it: **(1)** minimal change that satisfies the task, **(2)** optional follow-up task in ticket format.
-- Do not use “while we’re here” to rename, reformat, or reorganize unrelated modules.
-
-## Interaction with tickets
-
-- If a ticket or user message defines **Files to modify** and **Constraints**, those win; this rule file **narrows** how you plan and execute within that envelope — it does not override explicit file lists.

package/bundle/rules/git-commit.mdc

@@ -1,24 +0,0 @@
----
-description: Git 커밋 메시지 — 짧고 의미 있게(저비용 출력)
-alwaysApply: false
----
-
-# Git commit messages (agent)
-
-커밋 메시지·스테이징 요약을 쓸 때만 적용. **출력은 최소 토큰**, 내용은 **검색·리뷰에 쓸 만한 정보**만.
-
-## 형식 (기본)
-
-- **첫 줄만**: 명령형, **72자 이내**, 마침표 없음.
-- **선택** `type(scope): summary` — `feat` `fix` `refactor` `docs` `chore` 등; `scope`는 디렉터리·모듈 한 단어.
-- **본문**: 사용자가 요청하거나 변경이 여러 주제일 때만. 그때도 **불릿 최대 3줄**, 각 80자 이내.
-
-## 쓸 것 / 쓰지 말 것
-
-- **쓸 것**: 무엇이 바뀌었는지 한 문장(동작·계약·호환). 위험한 변경이면 한 단어로 표시(`BREAKING` 또는 마이그레이션 한 줄).
-- **쓰지 말 것**: diff 재서술, 파일 목록 나열, “업데이트함/개선함” 같은 빈 말, 이모지, 장문 튜토리얼, 영어·한국어 이중 번역(팀 언어 하나만). 커밋 메시지 제목(Title)에 "sync" 단어 사용 금지 (대신 "release", "update", "apply" 등으로 구체적으로 표현).
-
-## 비용
-
-- 한 커밋 주제면 **제목 한 줄로 끝낸다.**
-- 스테이징이 크면 제목은 요약하고, 본문은 **사용자가 본문 달라고 할 때만** 추가한다.

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

@@ -1,104 +0,0 @@
----
-description: Ticket format rules for multi-AI workflow
-alwaysApply: true
----
-
-# Multi-AI Workflow
-
-## HIGHEST PRIORITY RULE (Tone, Documentation & Formatting)
-Never use dramatic, exaggerated, or absolute language. When authoring any document or ticket, you MUST NEVER use expressions that emphasize dramatic effects or imply absolute completeness/perfection. Maintain a strictly factual, calm, dry tone at all times.
-HARD RULE: Never use Markdown word emphasis (bold **, italic *, etc.) in any generated content, including tickets, reports, and chat responses. Keep the text uniformly plain.
-
-## Before starting work
-
-Before implementation, fixes, or other substantive changes to the repo:
-
-1. Check persisted tickets in the locations described in AGENTS.md (Ticket persistence) — at minimum inspect .deuk-agent-ticket/ and any project-specific internal paths for files related to the current task.
-2. If .deuk-agent-ticket/TICKET_LIST.md exists, read it before editing code, then open only relevant topic files, in addition to step 1.
-3. Read matching documents before editing code. If the user pasted a ticket in the chat, treat that as primary unless they say to follow on-disk files instead.
-4. Skip the scan only when no ticket locations exist, nothing matches the task, or the user tells you to ignore stored tickets.
-
-## Receiving Ticket from Other Tools
-
-When the user pastes a design or plan from another assistant or planning tool:
-
-1. Parse the ticket format (see AGENTS.md, heading Ticket format).
-2. Validate file paths exist before modifying.
-3. Execute changes as specified — do not redesign unless the user asks.
-4. Report back in the same ticket format for further iteration.
-
-## Producing Ticket for Other Tools
-
-When the user asks to prepare work for another tool:
-
-1. Output the ticket format with concrete file paths and change descriptions. When linking ticket files (Markdown [label](path) or path citations), use the full path from the repository root — never a bare filename.
-2. Include any constraints or dependencies.
-3. Do not include editor-specific instructions (token budgets, local rule file paths).
-4. When the ticket must persist (user asks to save or document it, or it is the canonical next-step spec), create or update a Markdown file under internal implementation documentation (see AGENTS.md, Ticket persistence). Prefer the unified .deuk-agent-ticket/ directory for both the index (TICKET_LIST.md) and the topic files; init gitignores .deuk-agent-ticket/ by default. Use the same ticket template; do not place this in public README/landing unless the project explicitly treats this as its internal log. In Markdown links and backtick citations, use the full path from the repository root — never a bare filename.
-5. After writing a persisted ticket, in chat include one dedicated line with the full repo-root-relative path so the next session can open it unambiguously, for example: `Path: .deuk-agent-ticket/sub/container-unified-20260329-120000.md` (same path you used in the file). Repeat the full path in links elsewhere in the same message if helpful.
-7. Write persisted ticket content in the user's conversation language (e.g., Korean) unless they specify another language. When using Korean, follow the concise polite style (-요) as described in AGENTS.md.
-
-## Context Preservation (New Issues)
-
-If a new bug, unexpected error, or structural scope change arises during your work, DO NOT attempt to fix it within an endless conversational loop. This degrades the context window.
-Instead, immediately pause and Prioritize Creating a Ticket.
-- Document your findings and create a new .deuk-agent-ticket/ Markdown file.
-- This preserves the context safely and allows transparent multi-agent handoffs or manual rollbacks.
-
-## Custom Slash Commands & Chat Selection UI
-
-If the user's prompt starts with /ticket or /티켓 (with an optional keyword like DeukPack), immediately pause and perform the following:
-1. Fetch & Present (Rich UI Selection): Do not just list text. Automatically read .deuk-agent-ticket/TICKET_LIST.md and present the available open tickets using a Carousel (preferred for compatible agents like Antigravity) or a Markdown Table (fallback).
-   - Carousel Slide Format:
-     ```markdown
-     ## [Ticket ID] Title
-     Group: [Group] | Project: [Project]
-     [Open Ticket](full/path/to/ticket.md)
-     ```
-   - Table Format: Use a clearly formatted table with a separate column for the [Open](path) link.
-2. Read & Contextualize: If the user selects a ticket (by number or clicking the link), immediately read the ticket content and summarize the latest constraints and objectives.
-3. Wait for command: Briefly summarize the active ticket state and wait for the user's next command.
-
-## Selection Box (Agent Chat Interaction)
-
-When the user asks to "choose" or "select" a ticket in the chat, the agent must provide a Selection Box-like experience:
-- Interactive Listing: Provide a numbered listing using the Carousel or Table format above.
-- Direct Linkage: Ensure every listed item has a clickable repository-root-relative path.
-- No CLI output only: Never just point to ticket list CLI output; always render the human-readable selection UI directly in the chat window.
-
-## Persisted ticket vs plan UI (optional)
-
-Some environments show plan-style documents in a separate panel from ordinary Markdown tabs. Behavior varies by product version; when the user wants that experience in Cursor, you may mirror the same ticket body (Ticket format) under the workspace .cursor/plans/ directory using a .plan.md suffix, for example .cursor/plans/deuk-ticket.plan.md or .cursor/plans/deuk-ticket-<topic>.plan.md.
-
-- Canonical copy remains the unified .deuk-agent-ticket/ directory, where both the topic files and the TICKET_LIST.md index pointer are located. The .cursor/plans/ file is an optional duplicate for UI only.
-- Single source of truth: If both exist, keep their content in sync; updating one should update the other in the same turn when possible.
-- Version control: Treat .cursor/plans/ like other local-only tickets unless the team commits plans on purpose — align with .gitignore team policy.
-- For temporary tickets within a single session, write them inline in chat; when repeatedly referenced, shared across multiple agents, or recording risks, convert to an internal .md file. The default storage path is the local .deuk-agent-ticket/ directory; commit to the repository only when requested by the user or following established team conventions.
-
-## Definitive Multi-AI Workflow Cycles
-
-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) 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, 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?
-   - Are there structural corruptions or unintended side effects in the generated output?
-   - This step must be executed proactively; do not wait for the user to prompt for post-test analysis.
-   - If any risk is identified, document it in the ticket before reporting — do not silently suppress it.
-6. Report & Close: Present the final artifact risk analysis to the user. If verified successful, clear the queue by running npx deuk-agent-rule ticket close --topic <topic>. If unexpected issues arise, revert to Phase 1 (Explore) to amend the ticket.
-
-
-## Agent Role Awareness
-
-If you are operating inside an IDE (Cursor, Windsurf), you are strictly in Phase 4 (Execution). Do not attempt to over-engineer or explore completely out of bounds. Follow the Markdown ticket constraints strictly. If large-scale exploration or breaking structural changes are needed during execution, pause and instruct the user to revert to Phase 1 (Explore & Plan).
-
-## Cost awareness (effective use of context)
-
-- Keep sessions focused — one clear objective per session when possible.
-- Prefer concise tickets and replies: concrete paths, decisions, and diffs over narrative padding.
-- For read-only analysis, prefer summaries and scoped excerpts over dumping whole files; use lightweight review modes when the product offers them.
-- When producing tickets for other tools, omit local-only tuning hints (see Producing Ticket above); still stay efficient in your own responses here.
-- Tone & Style: No hype, no exaggerations, no fake satisfaction. Keep responses entirely factual and calm. Crucially, when authoring any document or ticket, NEVER use expressions that emphasize dramatic effects or imply absolute completeness/perfection. When using Korean, follow the concise polite style (-요).

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

@@ -1,48 +0,0 @@
----
-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`로 검색할 수 있습니다.

package/bundle/rules.d/deukrag-mcp.md

@@ -1,37 +0,0 @@
----
-id: deukrag-mcp
-condition:
-  mcp: deukrag
-inject_target: ["AGENTS.md", "gemini.md"]
----
-## 🧠 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를 반복 호출하십시오.**
-
-## 📡 RAG Connectivity & Fallback Protocol (RAG 상태별 행동 지침)
-
-에이전트는 현재 환경의 RAG(MCP) 연결 상태에 따라 아래와 같이 행동 유형을 즉시 전환해야 합니다.
-
-### State A: RAG-Normal (Strict RAG-First)
-- **상태**: MCP 도구(`mcp_deukrag_search_*`)가 정상 작동함.
-- **행동**: 모든 분석과 코드 작성 전 반드시 RAG를 호출하십시오. 로컬 파일 검색(`grep`, `ls`)보다 RAG 결과를 우선 신뢰하십시오.
-
-### State B: RAG-Missing (Graceful Fallback)
-- **상태**: 환경에 MCP 도구가 설치되어 있지 않거나 설정되지 않음.
-- **행동**: 즉시 로컬 파일 기반 검색(`grep_search`, `list_dir`, `view_file`)으로 전환하십시오. RAG 부재를 사용자에게 불평하지 말고, 가용한 로컬 컨텍스트 내에서 최선을 다해 작업을 완수하십시오.
-
-### State C: RAG-Error (Loop Prevention)
-- **상태**: MCP 호출 시 타임아웃, 연결 오류, 또는 동일 에러가 2회 이상 반복됨.
-- **행동**: **즉시 RAG 호출을 중단**하고 State B(로컬 검색)로 강제 전환하십시오. 에러 루프에 빠져 작업 시간을 낭비하지 마십시오. 문제 상황을 `## 📜 Execution Report`에 기록하여 추후 복구 티켓을 발행할 수 있게 하십시오.
-
-### State D: RAG-Miss (Zero Results)
-- **상태**: MCP 도구를 정상 호출했으나 관련 결과가 반환되지 않음 (DeukRag Miss).
-- **행동**: 검색 결과가 없다고 해서 임의로 추측하거나 단념하지 마십시오. 즉시 로컬 파일 기반 검색(`grep_search`, `list_dir`, `view_file`)으로 전환하여 대체 로컬 근거(Local Evidence)를 수집하십시오.
-  - **[보완 하드룰]**: 로컬 검색으로 찾은 대체 근거는 즉시 `add_knowledge` 도구를 호출하여 RAG 시스템에 보완(주입)하십시오. 이를 통해 다음 질의부터 해당 지식을 즉시 검색할 수 있게 됩니다.
-  - **이후 티켓이나 보고서 작성 시 반드시 "RAG Miss 발생: 로컬 검색 근거 파일 목록[...]"을 명시적으로 기록하십시오.**

package/bundle/templates/MODULE_RULE_TEMPLATE.md

@@ -1,24 +0,0 @@
-# Submodule Agent Rules: [Module Name]
-
-> **[CAUTION FOR AI AGENTS]**
-> When the Ticket Document `Target Submodule` matches this module, you MUST strictly adhere to the following architectural conventions and rules. Do not cross-pollinate rules from other submodules.
-
-## 📁 Repository Boundary
-- **Path Root:** `[e.g., DeukUI/ or DeukPackKits/]`
-- **Allowed Tech Stack:** `[e.g., React, TypeScript, CSS Modules | C#, Unity 2022]`
-
-## 🏗️ Core Architecture & Conventions
-1. **Naming Conventions:**
-   - [e.g., Use PascalCase for C# files, kebab-case for TS files.]
-2. **State Management:**
-   - [e.g., Do NOT use global Redux state; pass props or use React Context localized.]
-3. **Prohibited Patterns:**
-   - [e.g., Absolutely forbidden to use LINQ inside `Update()` functions.]
-   - [e.g., Absolutely forbidden to overwrite `index.js` generated files.]
-
-## 🛠️ Build & Test Protocol
-- **To build this module:** `[e.g., npm run build:plugin --prefix DeukUI]`
-- **To test this module:** `[e.g., npm run test:ui]`
-
-## 🔗 Ticket Instructions
-Always enforce that generated `Tickets` intended for this module include this rule file in their `[Context Files]` section.

package/bundle/templates/TICKET_TEMPLATE.md

@@ -1,58 +0,0 @@
-# [Execution] Task: <%= meta.title %> | ID: <%= meta.id %>
-
-> **[CAUTION FOR AI AGENTS]**
-> You are operating within a locked multi-module monorepo.
-> 1. Restrict absolutely all analysis, file creation, and modifications to the declared **[Target Submodule]** below.
-> 2. Read the files listed in **[Context Files]** before doing ANY code generation.
-> 3. DO NOT leak configuration, logic, or dependencies from other submodules.
-
-## 🎯 Scope Bounds
-- **Target Submodule:** `<%- meta.submodule || '[e.g., DeukUI | DeukPack | DeukNavigation]' %>`
-- **Context Files:** 
-  - `[e.g., DeukAgentRules/templates/MODULE_RULE_TEMPLATE.md]`
-  - `[e.g., path/to/your/specific/rules.md]`
-
-## 📁 Files to Modify
-- `path/from/root/to/target1`: [Specific instructions. Don't write 'refactor', describe WHAT to refactor.]
-
-## 🏗️ Design Decisions (Refer to Plan)
-- **Plan Reference**: <%- meta.planLink %>
-- [Briefly restate critical decisions if necessary]
-
-## 🛑 Strict Constraints (Rules to never break)
-- [e.g., No hotpath LINQ, Async Safety, No Raw Pointers]
-
-## 🔄 Phased Execution Steps
-> Agent: Do NOT attempt to do Phase 3 before Phase 1 is fully tested. 
-
-0. [Phase 0> RAG Research (MCP)]
-   - [ ] `mcp_deukrag_search_rules` 기반 규약 검토 완료
-   - [ ] `mcp_deukrag_search_tickets` 과거 유사 티켓 이력 열람 완료
-   - [ ] (필수 작성) 검색된 핵심 컨텍스트 요약: 
-   - [ ] (RAG Miss 시 필수 작성) 로컬 검색 결과 `add_knowledge` 도구로 즉시 주입 완료 여부 및 주입된 파일 목록: 
-
-0.5 [Phase 0.5> Deep Analysis (Optional)]
-   - [ ] 복잡한 아키텍처 변경 시 별도 분석 아티팩트 작성 및 승인 완료
-
-1. [Phase 1> Setup / Parsing]
-
-2. [Phase 2> Core Logic Change]
-   - [ ] (CONTINUOUS RAG) 새로운 함수/클래스 수정 전 `mcp_deukrag_search_code` 및 `search_rules`로 관련 패턴 수시 검색
-
-3. [Phase 3> Cleanup / Verification]
-   - [ ] (VERIFY RAG) 디버깅 및 에러 발생 시 로그 덤프 전 `mcp_deukrag_search_tickets` 로 과거 해결책 우선 탐색
-   - [ ] **Potential Issue Table**:
-     | 이슈 | 심각도 | 설명 | 조치 계획 |
-     |---|---|---|---|
-     | | | | |
-
-4. [Phase 4> Follow-up Chaining (MANDATORY if issues exist)]
-   - [ ] 위 표에서 즉시 해결 불가능한 항목에 대해 별도 티켓 발행 완료
-     > CLI Command Example: `deuk-agent-rule ticket create --topic 048-F1-fix-issue --title "Fix the issue" --group <group>`
-   - [ ] (필수 작성) 발행된 후속 티켓 번호 리스트:
-
-## ✅ Verification / QA
-- [ ] **Deep Analysis Verification**: Phase 0.5에서 도출된 핵심 설계 및 구조적 결정사항이 코드에 모두 올바르게 반영되었는지 확인.
-- [ ] **Potential Issues Check**: [Identify side effects, edge cases, or performance impacts]
-- [ ] **Strict Constraints Audit**: [No hotpath LINQ, Async Safety, No Raw Pointers, etc.]
-- [ ] `npm run test` 또는 관련 검증 명령 실행 결과 확인