mustflow 1.18.16 → 1.30.0

package/templates/default/locales/ko/.mustflow/skills/adapter-boundary/SKILL.md

@@ -1,193 +0,0 @@
----
-mustflow_doc: skill.adapter-boundary
-locale: ko
-canonical: false
-revision: 3
-lifecycle: mustflow-owned
-authority: procedure
-name: adapter-boundary
-description: Apply this skill when external systems, protocols, SDKs, databases, webhooks, queues, files, caches, framework requests or responses, AI models, browser storage, or provider data cross into or out of core logic and need ports, adapters, translation, error mapping, timeout, retry, idempotency, security, or observability boundaries.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.adapter-boundary
-  command_intents:
-    - changes_status
-    - changes_diff_summary
-    - test_related
-    - test
-    - lint
-    - build
-    - docs_validate_fast
-    - test_release
-    - mustflow_check
----
-
-# Adapter Boundary
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Keep external-world language, protocols, failures, and operational concerns out of core logic. Core logic speaks in internal use-case and domain terms; adapters translate external requests, responses, rows, messages, errors, identities, and provider behavior at the boundary.
-
-This skill is not just a wrapper pattern. A good adapter boundary absorbs provider details, validates or maps untrusted input, classifies failures, applies timeouts and retry policy, preserves idempotency where needed, and records safe observability evidence without leaking secrets or personal data.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- Code receives input from HTTP, CLI, webhooks, message queues, scheduled jobs, browser events, uploaded files, external databases, or external APIs.
-- Code calls external APIs, payment providers, email or SMS providers, file storage, object storage, databases, caches, search engines, analytics, AI models, queues, or browser storage.
-- Provider SDK types, framework request or response objects, database rows, external event objects, raw model responses, or provider error types are visible in domain, application, service, or use-case code.
-- A new or changed port, repository, gateway, provider module, controller, worker, webhook handler, mapper, or integration test is needed.
-- The boundary needs timeout, retry, rate-limit, idempotency, signature verification, duplicate handling, logging, metrics, redaction, or provider-version decisions.
-- An optional external integration may be disabled and needs either a safe neutral adapter or an explicit disabled result without leaking provider absence inward.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The change is a pure calculation, value object, internal formatter, or data-only refactor with no external boundary.
-- The only problem is hidden construction or global lookup of a dependency; use `dependency-injection` first, then return here only if external data, errors, or protocol behavior also need a boundary.
-- The operation coordinates several already-translated ports, repositories, queues, caches, or providers behind one caller-facing workflow; use `facade-pattern` for that high-level entry point while keeping this skill for each external boundary.
-- The task is a disposable one-off script that is not imported, repeated, tested, used in production, or connected to external systems.
-- The repository already has a more specific local integration skill that fully covers the boundary.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- The external system or protocol and whether it is inbound, outbound, or both.
-- The internal use case, domain action, or read model that should receive translated data.
-- Existing local patterns for ports, adapters, repositories, controllers, workers, mappers, result types, retries, idempotency, logging, and tests.
-- Provider-specific risk: write effects, duplicate delivery, unknown statuses, money, time, identifiers, secrets, personal data, files, untrusted URLs, rate limits, or provider version changes.
-- Relevant command-intent contract entries for tests, builds, docs, template checks, release checks, and mustflow validation.
-
-<!-- mustflow-section: preconditions -->
-## Preconditions
-
-- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
-- The boundary direction and owner are clear enough to avoid putting provider names or external protocol terms into core logic.
-- If the local layout is unfamiliar, use `pattern-scout` or `codebase-orientation` before introducing new folders or naming conventions.
-- If the change also introduces hidden collaborators or concrete construction, use `dependency-injection` for that part of the work.
-- If the integration is optional and disabled by explicit configuration, use `null-object-pattern` only when the neutral behavior is safe and honest; required providers must fail closed.
-
-<!-- mustflow-section: allowed-edits -->
-## Allowed Edits
-
-- Define narrow internal ports in the consuming application or domain language.
-- Add inbound adapters that parse, verify, validate, translate, and map protocol results.
-- Add outbound adapters that call providers and translate requests, responses, errors, identifiers, and operational metadata.
-- Add mapper, error-mapper, fixture, fake-port, contract-test, and adapter-test files directly needed by the boundary.
-- Add or update assembly-root wiring when a new adapter implementation is introduced.
-- Do not copy provider APIs into ports, return provider SDK objects, expose database rows as domain objects, or add a broad catch-all `ExternalAdapter`.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. Classify the boundary.
-   - Inbound: HTTP route, controller, webhook, CLI command, queue consumer, scheduler, browser event, uploaded file, or external data import.
-   - Outbound: provider SDK, HTTP API, database, cache, file storage, search engine, message publisher, email/SMS/push provider, payment provider, AI model, or browser storage.
-2. Name the internal capability in business language. Use names such as `PaymentGateway`, `EmailSender`, `ObjectStorage`, `UserStore`, `OrderReader`, `SummaryGenerator`, or `EventPublisher`. Keep provider names such as Stripe, Prisma, SendGrid, S3, OpenAI, or Redis inside adapter implementation names.
-3. Design the port from the consumer's need, not from the provider's API.
-   - Keep ports small and split unrelated reasons to change.
-   - Use internal input and output types only.
-   - Do not include SDK types, ORM model types, HTTP request objects, provider response objects, or provider error classes.
-4. Build inbound adapters as translators, not business-rule containers.
-   - Parse and validate external input.
-   - Verify signatures, authentication evidence, request size, file constraints, and allowed URL or host rules where relevant.
-   - Extract only the values needed by the use case.
-   - Map use-case results back to the protocol response.
-   - Keep pricing, permission decisions, state transitions, inventory policy, subscription policy, and other business rules in the application or domain layer.
-5. Build outbound adapters as provider translators, not pass-through wrappers.
-   - Create provider requests from internal input.
-   - Set timeouts and retry policy where appropriate.
-   - Pass idempotency keys for writes when the provider supports them.
-   - Distinguish timeout, network error, rate limit, authentication failure, authorization failure, invalid request, business rejection, provider outage, and unknown provider error.
-   - Return internal `Result` values or local error types instead of throwing provider errors for expected failures.
-   - For optional disabled integrations, return an honest skipped or disabled outcome, or wire a safe null object at the assembly boundary. Do not return fake provider success.
-6. Convert external data immediately at the boundary.
-   - Map provider responses, database rows, queue messages, file metadata, model outputs, and browser storage values into internal types.
-   - Keep external identifiers distinct from internal identifiers.
-   - Represent money in integer minor units and explicit currency.
-   - Convert dates and times explicitly according to the repository's time policy.
-   - Copy only fields that internal code actually uses.
-7. Separate mappers when translation grows.
-   - Split request mapping, response mapping, error mapping, and fixture builders once they become non-trivial or repeated.
-   - Keep provider-version differences inside adapter or mapper files.
-8. Treat databases, caches, and queues as external systems.
-   - Core logic should use stores, readers, writers, or publishers rather than raw clients.
-   - Database rows are persistence shapes, not domain objects.
-   - Queue messages and integration events are external envelopes until parsed and translated.
-   - Cache keys, time-to-live values, invalidation rules, and stale-data policy must be explicit.
-9. Keep database transactions and external side effects separate by default.
-   - Do not call external APIs inside database transactions unless a local rule explicitly justifies the risk.
-   - Use explicit states, an outbox, an action ledger, or a reconciliation path when database changes and external effects must be coordinated.
-10. Harden webhooks and duplicate delivery.
-    - Verify signatures before trusting payloads.
-    - Preserve the raw body or safe raw reference when needed for verification and replay.
-    - Use provider event identifiers or action keys to prevent duplicate effects.
-    - Translate external event types into internal commands or events before calling the use case.
-11. Keep AI model boundaries explicit.
-    - Keep provider request format, model name, temperature, token limits, safety settings, and raw response parsing inside adapter or configuration code.
-    - Validate structured output before returning it.
-    - Return internal purpose-level outputs such as summaries, classifications, recommendations, or extracted fields.
-12. Make observability safe and useful.
-    - Log adapter name, provider, operation, correlation id, safe idempotency-key hash, provider request id, duration, retry count, outcome, and local error kind when available.
-    - Do not log API keys, tokens, card data, passwords, identity numbers, raw personal data, full email bodies, full payment requests, full provider responses, or unredacted payloads.
-    - Add metrics for latency, failures, retries, rate limits, duplicate handling, and ambiguous or unknown provider outcomes when the boundary is operationally important.
-13. Test at the right layer.
-    - Use fake ports in use-case tests; they should not call real external systems.
-    - Test adapters with provider fixtures, mock clients, or local test doubles for request mapping, response mapping, error mapping, timeout, retry, idempotency, redaction, and duplicate handling.
-    - Add contract or sandbox tests for critical providers when local fixtures cannot catch provider drift.
-14. Verify with the narrowest configured command intents that cover changed source, tests, templates, docs, release metadata, and mustflow checks.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- Core logic has no provider SDK imports, framework request or response objects, ORM clients, database rows, provider response objects, or provider error classes.
-- Ports are named in internal business language and expose only internal input, output, and error types.
-- Inbound adapters validate and translate before calling use cases.
-- Outbound adapters translate internal requests, provider responses, and provider failures before returning.
-- Timeouts, retry policy, idempotency, duplicate handling, security checks, and redacted observability are explicit where the risk requires them.
-- Tests cover core behavior through fakes and adapter behavior through mapping, error, and boundary tests.
-
-<!-- mustflow-section: verification -->
-## Verification
-
-Use configured oneshot command intents when available:
-
-- `changes_status`
-- `changes_diff_summary`
-- `test_related`
-- `test`
-- `lint`
-- `build`
-- `docs_validate_fast`
-- `test_release`
-- `mustflow_check`
-
-Prefer the narrowest configured test or build intent that proves the affected boundary. Use documentation and release checks when skill routes, templates, public docs, package metadata, or installed-file surfaces change.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If a port starts mirroring a provider API, narrow it to the consuming use case and move provider details back into the adapter.
-- If an adapter becomes a pass-through wrapper, add explicit mapping and error translation or remove the false boundary.
-- If an adapter begins making business decisions, move the policy into the application or domain layer.
-- If timeout, retry, or idempotency behavior cannot be made safe, fail closed and report the remaining manual or reconciliation requirement.
-- If sensitive data appears in logs, fixtures, metrics, receipts, or test output, stop and route the sensitive surface through the repository's security and privacy review path.
-- If the provider behavior is unknown or drift-prone, keep claims local to verified fixtures or contract evidence and report what still needs live verification.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Boundary classified
-- Internal port or use-case input selected
-- Provider or protocol details contained
-- Inbound validation and translation handled
-- Outbound request, response, and error mapping handled
-- Timeout, retry, idempotency, and duplicate behavior handled or explicitly deferred
-- Security and redaction surfaces checked
-- Tests, fixtures, fakes, or contract checks added or reused
-- Command intents run
-- Skipped checks and reasons
-- Remaining boundary leakage or provider risk

package/templates/default/locales/ko/.mustflow/skills/artifact-integrity-check/SKILL.md

@@ -1,114 +0,0 @@
----
-mustflow_doc: skill.artifact-integrity-check
-locale: ko
-canonical: false
-revision: 1
-lifecycle: mustflow-owned
-authority: procedure
-name: artifact-integrity-check
-description: 생성 산출물이나 바이너리 자산을 만들거나 교체하거나 패키징하거나 참조하거나 보고할 때 적용합니다.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.artifact-integrity-check
-  command_intents:
-    - changes_status
-    - changes_diff_summary
-    - test_release
-    - build
-    - mustflow_check
----
-
-# 산출물 무결성 확인
-
-<!-- mustflow-section: purpose -->
-## 목적
-
-생성 산출물, 패키지 포함 파일, 미디어 자산, 보고서, 내려받을 수 있는 출력물이 실제로 존재하고 의도한 출처와 맞으며, 근거 없이 검증 완료로 보고되지 않게 합니다.
-
-<!-- mustflow-section: use-when -->
-## 사용할 때
-
-- 산출물이나 바이너리 자산을 생성, 교체, 이동, 삭제, 패키징, 참조합니다.
-- 최종 보고에서 파일이 생성, 최적화, 내보내기, 패키지 포함, 사용 가능 상태라고 주장합니다.
-- 빌드나 패키징 단계가 오래되었거나 누락되었거나 너무 크거나 배포에서 빠질 수 있는 파일을 씁니다.
-- 문서, README, 매니페스트, 테스트가 생성 파일이나 자산 경로를 가리킵니다.
-
-<!-- mustflow-section: do-not-use-when -->
-## 사용하지 않을 때
-
-- 변경이 소스에만 있고 생성, 패키징, 내보내기, 바이너리 파일을 언급하지 않습니다.
-- 더 좁은 스킬이 정확한 산출물 경로, 패키지 표면, 출력 주장을 이미 검증합니다.
-- 사용자가 파일 생성이나 검증 없이 개념 계획만 요청했습니다.
-
-<!-- mustflow-section: required-inputs -->
-## 필요한 입력
-
-- 산출물 경로 또는 기대 출력 위치.
-- 산출물을 만들어야 하는 소스 파일, 생성 단계, 패키지 규칙.
-- 크기, 형식, 해시, 매니페스트, 패키지, 문서 기대값.
-- 빌드, 패키징, 검증, 자산 최적화에 관한 명령 의도 계약 항목.
-
-<!-- mustflow-section: preconditions -->
-## 전제 조건
-
-- 작업이 사용할 때 조건에 맞고 사용하지 않을 때 조건에는 해당하지 않습니다.
-- 필요한 입력이 있거나, 부족한 입력을 추측하지 않고 보고할 수 있습니다.
-- 현재 범위의 상위 지시와 `.mustflow/config/commands.toml`을 확인했습니다.
-
-<!-- mustflow-section: allowed-edits -->
-## 허용되는 수정
-
-- 산출물 주장을 사실로 유지하는 데 필요한 산출물, 소스 참조, 매니페스트, 패키지 메타데이터, 테스트, 문서만 갱신합니다.
-- 저장소가 해당 산출물을 버전 관리한다고 명시하지 않았다면 생성 캐시, 일시적 빌드 출력, 로컬 상태를 커밋하지 않습니다.
-- 해시, 크기, 파일 용량, 내보내기 결과, 패키지 포함 근거를 지어내지 않습니다.
-
-<!-- mustflow-section: procedure -->
-## 절차
-
-1. 작업이 영향을 주는 각 산출물이나 바이너리 자산과 그에 대한 주장을 나열합니다.
-2. 산출물이 소스 관리 대상인지, 생성물인지, 패키지 포함물인지, 무시되는 로컬 상태인지, 외부 출력인지 확인합니다.
-3. 소스 참조, 매니페스트, 패키지 포함 규칙, 문서 링크, 테스트가 같은 경로와 형식을 가리키는지 확인합니다.
-4. 사용할 수 있는 가장 좁은 구성된 명령 의도로 존재 여부, 형식, 기대 포함 여부를 검증합니다.
-5. 생성 산출물이 오래되었거나 누락되었다면 구성된 명령 의도로만 다시 만들거나, 빠진 명령을 보고합니다.
-6. 산출물이 버전 관리 대상이 아니라면 최종 보고에서 커밋되었거나 배포된 것처럼 말하지 않습니다.
-7. 확인한 경로, 실행한 명령 의도, 남은 미검증 속성을 정확히 보고합니다.
-
-<!-- mustflow-section: postconditions -->
-## 완료 조건
-
-- 코드, 문서, 매니페스트, 테스트, 최종 보고의 모든 산출물 주장은 관찰한 근거가 있거나 확인하지 못했다고 명시되어 있습니다.
-- 생성물과 무시되는 출력은 저장소가 버전 관리 대상으로 선언하지 않는 한 프로젝트 진실로 취급하지 않습니다.
-- 패키지나 배포 주장은 가능한 경우 관련 구성된 의도로 검증했습니다.
-
-<!-- mustflow-section: verification -->
-## 검증
-
-사용 가능한 구성된 일회성 명령 의도를 사용합니다.
-
-- `changes_status`
-- `changes_diff_summary`
-- `test_release`
-- `build`
-- `mustflow_check`
-
-산출물을 더 잘 덮는 좁은 자산 또는 문서 검증 의도가 있으면 그 의도를 사용합니다.
-
-<!-- mustflow-section: failure-handling -->
-## 실패 처리
-
-- 산출물을 생성하거나 확인할 수 없다면 빠진 도구, 명령 의도, 소스 파일을 보고합니다.
-- 패키지 포함과 소스 참조가 다르면 산출물을 배포된 것으로 보고하기 전에 매니페스트나 문서를 고칩니다.
-- 산출물이 너무 크거나 오래되었거나 형식이 틀렸다면 문제를 보고하고 프로덕션 준비 완료라고 말하지 않습니다.
-- 검증에 외부 서비스나 사용할 수 없는 도구가 필요하면 그 경계에서 멈추고 확인하지 못한 산출물 속성을 밝힙니다.
-
-<!-- mustflow-section: output-format -->
-## 출력 형식
-
-- 확인한 산출물 경로
-- 산출물 출처 또는 생성 경로
-- 포함, 형식, 용량 근거
-- 실행한 명령 의도
-- 건너뛴 산출물 확인과 이유
-- 남은 산출물 무결성 위험

package/templates/default/locales/ko/.mustflow/skills/behavior-preserving-refactor/SKILL.md

@@ -1,182 +0,0 @@
----
-mustflow_doc: skill.behavior-preserving-refactor
-locale: ko
-canonical: false
-revision: 11
-lifecycle: mustflow-owned
-authority: procedure
-name: behavior-preserving-refactor
-description: Apply this skill when refactoring should reduce change cost while preserving existing behavior and keeping behavior changes separate.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.behavior-preserving-refactor
-  command_intents:
-    - changes_status
-    - changes_diff_summary
-    - test_related
-    - test
-    - docs_validate_fast
-    - test_release
-    - mustflow_check
----
-
-# Behavior-Preserving Refactor
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Guide refactoring that lowers future change cost without silently changing runtime behavior.
-
-Refactoring is not cleanup for aesthetics. It is a controlled way to make code easier to understand, test, and change while keeping bug fixes, feature work, and behavior changes separate.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- The user asks to refactor, clean up, reorganize, simplify, split, extract, rename, remove duplication, or improve structure.
-- A planned change risks mixing renames, moves, extractions, deduplication, bug fixes, and feature behavior in one diff.
-- Existing code is hard to change because responsibilities, names, branches, dependencies, or tests are unclear.
-- Existing inheritance, base classes, abstract classes, template methods, protected state, or subclass variants make behavior harder to test or change.
-- Existing handlers, repositories, adapters, jobs, or services mix business decisions with database access, network calls, logging, current time, generated identifiers, randomness, environment reads, or framework objects.
-- Existing controllers, handlers, jobs, or services mix one state-changing intent with authorization, transactions, idempotency, audit logs, outbox events, retries, concurrency checks, and external side effects.
-- Existing controllers, handlers, workers, command handlers, or services repeat the same multi-step subsystem sequence and should move behind a stable facade without changing behavior.
-- Existing lifecycle state changes are scattered across direct assignments, handlers, repositories, jobs, UI checks, SQL conditions, or provider callbacks.
-- Existing code repeats presence checks for optional collaborators such as loggers, analytics clients, caches, optional notifications, or no-op processors.
-- The task touches legacy or weakly tested code and needs a safer refactoring order.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The requested task is primarily a bug fix or failure diagnosis; use `repro-first-debug` first.
-- The change introduces new folders, modules, routing, data models, or external service boundaries before refactoring scope is clear; use `structure-discovery-gate`.
-- The task is only to review an already completed diff; use `diff-risk-review` or `code-review`.
-- The target code is about to be deleted, the requirement is still unclear, or the next step requires a product decision rather than a refactor.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- The refactoring goal, target files or area, and the concrete pain being reduced.
-- Current behavior evidence, such as tests, examples, fixtures, command output, or observed input and output cases.
-- Existing local patterns for naming, file boundaries, dependencies, and tests.
-- Current changed-file list when the worktree is already dirty.
-- Relevant command-intent contract entries for verification.
-
-<!-- mustflow-section: preconditions -->
-## Preconditions
-
-- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
-- The expected behavior to preserve is known, or the unknown behavior has been reported before edits begin.
-- If the area is unfamiliar, `codebase-orientation` or `pattern-scout` has been used to avoid inventing a parallel structure.
-- If tests are absent or weak, the first safe step is to add characterization coverage, capture input and output cases, or explicitly report the verification gap.
-
-<!-- mustflow-section: allowed-edits -->
-## Allowed Edits
-
-- Rename unclear identifiers when the rename improves call-site meaning without changing behavior.
-- Extract small functions, policies, or helpers when they have a clear concept, inputs, outputs, and test value.
-- Flatten conditional flow when it preserves the same guard conditions and error behavior.
-- Separate responsibilities, dependencies, or side effects in the smallest useful step.
-- Move domain decisions toward pure functions or narrow policy objects, and keep I/O, clocks, network calls, process spawning, persistence, and logging in the imperative edge.
-- Add or update tests that preserve current behavior or make the refactoring safe.
-- Do not mix behavior changes, bug fixes, new features, broad formatting churn, or unrelated cleanup into the refactor.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-Before broad hotspot scans, compress candidates before reading files.
-
-- Exclude generated files, bundled files, lock files, dependency directories, large fixtures, snapshots, build outputs, minified files, and source maps before ranking candidates.
-- Use `[refactoring.hotspots]` preferences as scan limits: `large_file_candidate_kb` for the first size signal, `history_days` for recent change and bug-fix history, and the candidate limits for how many files to inspect at each depth.
-- Prefer overlapping low-cost signals over a single metric: size, recent change frequency, bug-fix history, import/export count, TODO/FIXME/HACK count, type or lint bypasses, missing nearby tests, and architecture-boundary imports.
-- Treat strong combinations as higher priority, such as large files with frequent changes and no tests, small security/payment/permission files with repeated bug fixes, large React client components with many effects, and API/controller files that mix validation, authorization, business logic, database access, and response formatting.
-- Do not read every candidate. Keep the first pass to the configured primary limit, narrow to the configured structure-review limit, and read full file contents only for the configured full-file limit.
-- When opening a candidate, inspect imports, exports, declarations, TODO or type-bypass neighborhoods, and the largest or most branch-heavy function before reading the full file.
-
-1. Diagnose whether refactoring is needed.
-   - Name the real problem: change cost, unclear responsibility, repeated bug risk, test difficulty, dependency coupling, or confusing flow.
-   - Do not refactor only because code looks long, old, or stylistically uneven.
-2. Identify behavior that must stay fixed.
-   - Prefer existing tests or examples.
-   - If coverage is missing, record representative input and output cases or add focused characterization tests before structural edits.
-   - Treat suspected bugs as separate follow-up fixes unless the user explicitly asks to change behavior.
-3. Choose the safest refactoring ladder.
-   - Start with names and local clarity.
-   - Then extract small concepts with clear inputs and outputs.
-   - Then flatten conditions or isolate policies.
-   - Then remove duplication only when the duplicated code changes for the same reason.
-   - Move files, introduce abstractions, or split modules only after local behavior is easier to see.
-4. Check duplication before merging code.
-   - Keep duplication when code only looks similar or will change for different reasons.
-   - Prefer common code only when it represents the same rule, simplifies call sites, and does not add parameter or branch complexity.
-   - Prefer explicit duplication over a misleading abstraction.
-5. Check extracted functions and names.
-   - Extract only concepts that can be named precisely.
-   - Avoid vague names such as `process`, `handle`, `do`, or `helper` unless they match established local style.
-   - Boolean functions should read naturally at call sites and reveal the condition being tested.
-6. Prefer the low-ceremony structural pattern that matches the pain:
-   - Dependency injection when direct construction, global lookup, or hidden imports of tools, clients, clocks, file systems, processes, loggers, configuration, random generators, identifiers, queues, or external SDKs makes behavior hard to test. Use `dependency-injection` before editing that boundary.
-   - Adapter or translator boundaries when external formats leak into core logic. Use `adapter-boundary` when provider data, protocols, errors, timeouts, retries, idempotency, security, or observability are part of the boundary.
-   - Composition over inheritance when behavior can be assembled from small explicit collaborators. Use `composition-over-inheritance` before editing `extends`, base classes, abstract classes, template methods, protected state, mixins, or subclass combinations.
-   - Command pattern when a state-changing user or system intent needs a traceable execution unit with explicit payload, context, authorization, transaction boundary, idempotency, outbox, audit, retry, or concurrency behavior. Use `command-pattern` before editing that execution unit.
-   - Pure core with an imperative shell when business decisions, validation, authorization, pricing, eligibility, state transitions, or domain events are mixed with I/O, time, generated identifiers, randomness, environment reads, or framework objects. Use `pure-core-imperative-shell` before editing that split.
-   - State machine pattern when status, state, phase, step, or stage controls allowed behavior and transitions are scattered or assigned directly. Use `state-machine-pattern` before editing lifecycle transitions.
-   - Strategy pattern when repeated branches choose among interchangeable algorithms, policies, pricing rules, scoring methods, provider choices, or feature variants that share one purpose. Use `strategy-pattern` before editing that strategy family.
-   - Result and Option values when expected failures, meaningful absence, null returns, thrown business failures, or ambiguous success flags make behavior hard to follow. Use `result-option` before editing that return-shape contract.
-   - Null Object pattern when repeated nullable checks around an optional collaborator can be replaced by a same-interface neutral implementation without hiding required failures. Use `null-object-pattern` before editing that optional dependency boundary.
-   - Injected time context when current time affects preserved behavior.
-7. Handle conditional complexity by finding the policy.
-   - Use early exits for simple guard conditions when they preserve behavior.
-   - Separate state, type, permission, and exceptional-rule branches when they are mixed.
-   - Avoid replacing clear branches with a strategy object, table, or abstraction before the policy boundary is proven.
-8. Keep commits and reports reviewable.
-   - Separate renames, moves, extractions, deduplication, tests, and behavior changes when possible.
-   - If behavior changes are discovered, stop and report them as a separate fix path.
-9. Verify with the narrowest configured command intents that cover the changed code and contract surfaces.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- Existing behavior is preserved or any behavior change is clearly separated and reported.
-- The refactor has a named purpose tied to lower change cost, lower defect risk, or better testability.
-- The diff is small enough for a reviewer to distinguish mechanical changes from semantic changes.
-- Tests or verification evidence cover the behavior most likely to regress.
-
-<!-- mustflow-section: verification -->
-## Verification
-
-Use configured oneshot command intents when available:
-
-- `changes_status`
-- `changes_diff_summary`
-- `test_related`
-- `test`
-- `docs_validate_fast`
-- `test_release`
-- `mustflow_check`
-
-Choose the narrowest configured test or build intent that proves the refactored behavior. Use documentation and release checks only when the refactor changes public docs, templates, schemas, package metadata, or release-sensitive surfaces.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If current behavior cannot be observed, stop before broad restructuring and report the missing safety evidence.
-- If a refactor uncovers a bug, keep the refactor behavior-preserving and propose the fix as a separate change.
-- If deduplication creates more options, branches, or vague names, undo or postpone that abstraction.
-- If tests fail after a supposedly behavior-preserving edit, diagnose the behavior difference before continuing.
-- If the next useful step is a large module move or public boundary change, use `structure-discovery-gate` and `contract-sync-check` before proceeding.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Refactoring goal
-- Behavior preservation evidence
-- Structural risk signals found
-- Facade extraction used or intentionally avoided
-- Refactoring ladder chosen
-- Structural pattern used or intentionally avoided
-- Changes made or analysis-only recommendation
-- Behavior changes intentionally excluded
-- Verification intents run
-- Skipped checks and reasons
-- Remaining risks or follow-up fix path

package/templates/default/locales/ko/.mustflow/skills/code-review/SKILL.md

@@ -1,118 +0,0 @@
----
-mustflow_doc: skill.code-review
-locale: ko
-canonical: false
-revision: 4
-authority: procedure
-lifecycle: mustflow-owned
-name: code-review
-description: 코드 변경 사항을 검토하거나, 변경 범위 및 검증 누락 여부를 확인해야 할 때 적용합니다.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.code-review
-  command_intents:
-    - test
-    - test_related
-    - test_audit
-    - lint
----
-
-# 코드 검토 (Code Review)
-
-<!-- mustflow-section: purpose -->
-## 목적
-
-변경 사항이 요청 범위에 부합하는지 확인하고, 동작상의 위험이나 검증 누락이 없는지 검토합니다.
-
-<!-- mustflow-section: use-when -->
-## 적용 시나리오
-
-- 코드 변경, diff 검토, 풀 리퀘스트(PR) 검토 또는 잠재적 회귀 위험 확인이 필요한 경우 적용합니다.
-- 새로운 동작 구현보다 변경에 따른 위험 평가 및 누락 확인이 주된 목적인 경우 적용합니다.
-
-<!-- mustflow-section: do-not-use-when -->
-## 적용하지 않는 경우
-
-- 단순한 문구 수정, 번역 또는 서식 변경 작업만 포함된 경우 적용하지 않습니다.
-- 검토할 변경 파일이나 diff가 없는 경우 적용하지 않습니다.
-
-<!-- mustflow-section: required-inputs -->
-## 필요한 입력
-
-- 수정된 파일 목록 또는 diff
-- 사용자가 지정한 검토 기준
-- `AGENTS.md`의 작업 규칙
-- `.mustflow/docs/agent-workflow.md`의 공통 작업 정책
-- `.mustflow/config/commands.toml`의 명령 의도 계약
-
-<!-- mustflow-section: preconditions -->
-## 사전 조건
-
-- 작업이 사용 조건에 맞고 사용하지 않는 경우에는 해당하지 않습니다.
-- 필요한 입력을 확보했거나, 빠진 입력을 추측하지 않고 보고할 수 있습니다.
-- 현재 범위에 대해 더 높은 우선순위의 지침과 `.mustflow/config/commands.toml`을 확인했습니다.
-
-<!-- mustflow-section: allowed-edits -->
-## 허용 수정 범위
-
-- 이 스킬, 사용자 요청, `.mustflow/skills/INDEX.md`의 맞는 경로가 설명하는 범위 안에서만 수정합니다.
-- 명령 권한을 넓히거나, 프로젝트 사실을 지어내거나, 관련 없는 워크플로 파일을 변경하지 않습니다.
-
-<!-- mustflow-section: procedure -->
-## 절차
-
-1. 수정된 파일 목록을 검토합니다.
-2. 요청 사항과 무관한 불필요한 변경 사항이 포함되었는지 확인합니다.
-3. 공개 동작, 설정, 명령 및 문서에 미치는 영향을 분석합니다.
-4. 테스트의 적절성을 검토합니다.
-   - 새로운 기능에 대한 테스트가 누락되었는지 확인합니다.
-   - 제거된 기능에 대한 불필요한 테스트가 남아있는지 확인합니다.
-   - 새로운 위험을 검증하지 못하는 중복 테스트가 있는지 확인합니다.
-   - 단언(assertion)이 근거 없이 약화되었는지 확인합니다.
-   - 스냅샷 갱신에 타당한 근거가 있는지 확인합니다.
-   - 기존 테스트로 인해 삭제된 동작이 의도치 않게 재도입될 위험이 있는지 확인합니다.
-5. 필요한 테스트 또는 규칙 검사 의도가 `.mustflow/config/commands.toml`에 정의되어 있는지 확인하십시오.
-6. 발견된 사항을 심각도순으로 기록하십시오.
-
-<!-- mustflow-section: postconditions -->
-## 사후 조건
-
-- 명확한 근거, 실행한 명령 의도, 건너뛴 확인, 남은 위험을 포함해 예상 출력을 작성할 수 있습니다.
-- 빠진 명령 의도, 알 수 없는 입력, 권한 충돌은 숨기지 않고 보고합니다.
-
-<!-- mustflow-section: verification -->
-## 검증
-
-공유 명령 정책은 `.mustflow/docs/agent-workflow.md#명령-실행-정책`을 따릅니다.
-
-관련 명령 의도:
-
-- `test`
-- `test_related`
-- `test_audit`
-- `lint`
-
-각 의도는 `.mustflow/config/commands.toml`에서 확인하십시오.
-`status = "configured"`가 아니면 실행하지 않고, 상태와 건너뛴 이유를 보고하십시오.
-`lifecycle = "oneshot"`과 `run_policy = "agent_allowed"`가 아니면 검증 명령으로 실행하지 않습니다.
-스킬 문서 내에 실제 셸 명령을 직접 작성하지 마십시오.
-
-<!-- mustflow-section: failure-handling -->
-## 실패 대응
-
-- 필요한 명령 의도가 `unknown`, `manual_only`, `disabled`이거나 없는 경우, 대체 명령을 임의로 추측하지 마십시오.
-- 검증을 수행하지 못한 이유와 잔존 위험을 보고하십시오.
-- 민감한 정보나 파괴적인 명령 위험이 식별되면 즉시 중단하고 확인된 내용을 보고하십시오.
-
-<!-- mustflow-section: output-format -->
-## 출력 형식
-
-- 작업 요약
-- 심각도별 발견 사항
-- 검토한 파일 목록
-- 실행한 명령 의도
-- 건너뛴 명령 의도 및 사유
-- 테스트 적절성 검토 결과
-- 잔존 위험