mustflow 1.15.97

package/templates/default/locales/ko/.mustflow/skills/pattern-scout/SKILL.md

@@ -0,0 +1,110 @@
+---
+mustflow_doc: skill.pattern-scout
+locale: ko
+canonical: false
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: pattern-scout
+description: 익숙하지 않은 영역을 구현하기 전, 이미 저장소 안에 같은 모양을 해결한 패턴이 있는지 확인할 때 적용합니다.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.pattern-scout
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - mustflow_check
+---
+
+# 패턴 먼저 찾기
+
+<!-- mustflow-section: purpose -->
+## 목적
+
+새 구조, 이름, 데이터 흐름, 테스트 방식, 문서 형태를 만들기 전에 가장 가까운 저장소 내부 구현 패턴을 찾습니다.
+
+<!-- mustflow-section: use-when -->
+## 사용할 때
+
+- 익숙하지 않은 모듈, 명령, 화면, 스키마, 템플릿, 스킬, 문서 묶음을 수정합니다.
+- 비슷한 기능이 저장소 다른 곳에 이미 있을 가능성이 있습니다.
+- 충분한 근거 없이 새 추상화, 도우미, 파일 배치, 테스트 스타일을 만들 위험이 있습니다.
+- 기존 이름 규칙, 다국어 처리, 검증, 패키징 관례에 맞춰야 합니다.
+
+<!-- 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`
+- `mustflow_check`
+
+선택한 패턴이 요구하는 더 좁은 테스트, 빌드, 문서 검증 의도가 있으면 함께 실행합니다.
+
+<!-- mustflow-section: failure-handling -->
+## 실패 처리
+
+- 내부 패턴이 없으면 새 패턴임을 보고하고 첫 버전은 작게 유지합니다.
+- 패턴이 충돌하면 수정 파일에 가장 가까운 쪽을 우선하고 절충점을 보고합니다.
+- 검증에서 빠진 색인이나 메타데이터 정합성이 드러나면 관련 없는 로직을 더하기 전에 정합성을 먼저 고칩니다.
+- 가장 가까운 패턴이 오래되었거나 깨져 있다면 그대로 복사하지 말고, 그 사실을 보고한 뒤 더 안전한 내부 선례를 고릅니다.
+
+<!-- mustflow-section: output-format -->
+## 출력 형식
+
+- 변경 형태
+- 확인한 내부 패턴
+- 적용한 패턴 또는 벗어난 이유
+- 맞춰 둔 색인, 매니페스트, 문서
+- 실행한 명령 의도
+- 건너뛴 검증과 이유

package/templates/default/locales/ko/.mustflow/skills/performance-budget-check/SKILL.md

@@ -0,0 +1,121 @@
+---
+mustflow_doc: skill.performance-budget-check
+locale: ko
+canonical: false
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: performance-budget-check
+description: 성능 예산, 번들 크기, 페이지 무게, 시작 시간, 명령 실행 시간, 메모리 사용량, 자산 크기, 처리량, 지연 시간, 벤치마크 출력, 성능 주장을 계획, 수정, 검토, 보고할 때 적용합니다.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.performance-budget-check
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - build
+    - test_related
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# 성능 예산 확인
+
+<!-- mustflow-section: purpose -->
+## 목적
+
+성능 주장과 예산을 로컬 체감으로 추측하지 않고, 선언된 기준값, 재현 가능한 측정, 명시적인 절충점에 묶어 둡니다.
+
+<!-- mustflow-section: use-when -->
+## 사용할 때
+
+- 작업이 성능 예산, 번들 크기, 페이지 무게, 시작 시간, 명령 실행 시간, 메모리 사용량, 자산 크기, 처리량, 지연 시간, 검색 인덱스 크기, 빌드 시간, 벤치마크 출력을 바꾸거나 보고합니다.
+- 변경이 더 무거운 의존성, 생성된 자산, 정적 페이지, 검색 인덱스, 시작 시 작업, 파일 스캔, 여러 명령 실행, 반복적인 프로세스 생성을 추가합니다.
+- 보고가 어떤 경로가 더 빠름, 느림, 가벼움, 최적화됨, 캐시됨, 병렬화됨, 저렴함, 비쌈, 예산 안에 있음, 예산을 넘었음을 주장합니다.
+- 실패나 느려짐이 측정 범위, 명령 선택, 동시 실행, 캐시, 생성 결과 크기 검토가 필요함을 시사합니다.
+
+<!-- mustflow-section: do-not-use-when -->
+## 사용하지 않을 때
+
+- 작업이 문구만 바꾸며 성능이나 크기 주장을 만들지 않습니다.
+- 숫자가 예산이나 공개 보고 의미가 없는 로컬 fixture 또는 예시에 불과합니다.
+- 변경이 이미지 자산 변환만 다룹니다. 해당 자산 파이프라인에는 `web-asset-optimization`을 사용하고, 이 스킬은 예산 보고가 필요할 때만 함께 사용합니다.
+
+<!-- mustflow-section: required-inputs -->
+## 필요한 입력
+
+- 명령, 페이지, 자산, 번들, 시작 경로, 쿼리, 빌드, 생성 결과 같은 성능 표면.
+- 존재한다면 예산 출처: 저장소 설정, 문서화된 기준값, 사용자가 준 한도, 벤치마크 기준선, 패키지 메타데이터, 현재 명령 결과.
+- 측정 방식, 환경 경계, 예열 여부, 결과가 결정적인지, 표본인지, 로컬 전용인지, 근삿값인지.
+- 상태, diff, 빌드, 테스트, 문서, 릴리스, mustflow 검증에 관한 명령 의도 계약 항목.
+
+<!-- mustflow-section: preconditions -->
+## 전제 조건
+
+- 작업이 사용할 때 조건에 맞고 사용하지 않을 때 조건에는 해당하지 않습니다.
+- 필요한 입력이 있거나, 부족한 입력을 추측하지 않고 보고할 수 있습니다.
+- 현재 범위의 상위 지시와 `.mustflow/config/commands.toml`을 확인했습니다.
+
+<!-- mustflow-section: allowed-edits -->
+## 허용되는 수정
+
+- 변경된 성능 표면에 연결된 예산 검사, 측정 메모, 기준값, 캐시 경계, 의존성 절충 메모, 테스트, 문서, 보고를 추가하거나 강화합니다.
+- "빠르다" 또는 "가볍다" 같은 모호한 주장을 측정된 표현, 범위가 있는 표현, 또는 명시적인 미검증 표현으로 바꿉니다.
+- 새 도구를 추가하기 전에 기존의 구성된 명령 의도와 저장소 안의 측정 경로를 우선합니다.
+- 진실 출처 없이 기준값, 벤치마크 숫자, 하드웨어 가정, 네트워크 조건, 릴리스 차단 예산을 지어내지 않습니다.
+
+<!-- mustflow-section: procedure -->
+## 절차
+
+1. 성능 표면을 식별하고 작업이 런타임, 빌드 시간, 테스트 시간, 문서 생성, 자산 무게, 패키지 크기, 사용자에게 보이는 로딩 동작 중 무엇에 영향을 주는지 분류합니다.
+2. 기준값이나 주장을 바꾸기 전에 예산 출처를 찾습니다. 예산이 없으면 이 작업을 예산 발견 또는 측정 전용 작업으로 보고합니다.
+3. 주변 코드, 문서, 템플릿, 테스트, 명령 메타데이터에서 중복된 성능 문장이나 오래된 기준값을 확인합니다.
+4. 측정값을 결정적, 표본, 로컬 전용, 외부 의존, 미측정으로 분류합니다.
+5. 변경이 의존성, 생성 결과, 반복 작업을 추가한다면 예상 비용 경로와 기존 대안이 있는지 확인합니다.
+6. 주장은 보수적으로 둡니다. 명령, 입력 범위, 캐시, 예열, 병렬 실행, 생성 파일이 결과에 영향을 줬는지 함께 밝힙니다.
+7. 예산을 넘었다면 영향을 받은 표면, 예산 출처, 측정값 또는 측정 불가 상태, 추정 원인, 가장 작은 후속 작업을 보고합니다.
+8. 변경한 성능, 패키지, 문서, mustflow 표면을 증명하는 가장 좁은 구성된 검증을 실행합니다.
+
+<!-- mustflow-section: postconditions -->
+## 완료 조건
+
+- 성능 주장에는 예산 출처, 측정 방식, 또는 명시적인 미검증 상태가 있습니다.
+- 기준값과 벤치마크 관련 문서, 테스트, 패키지 메타데이터, 생성 결과 메모, 명령 계약이 겹치는 곳에서 동기화되어 있습니다.
+- 최종 보고는 측정 증거, 추정, 로컬 관찰, 제안된 후속 작업을 구분합니다.
+
+<!-- mustflow-section: verification -->
+## 검증
+
+사용 가능한 구성된 일회성 명령 의도를 사용합니다.
+
+- `changes_status`
+- `changes_diff_summary`
+- `build`
+- `test_related`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+변경한 성능 표면을 더 잘 증명하는 좁은 벤치마크, 자산, 빌드, 문서, 테스트 의도가 있으면 그 의도를 사용합니다.
+
+<!-- mustflow-section: failure-handling -->
+## 실패 처리
+
+- 예산 출처가 없으면 새로 지어내지 않습니다. 출처가 없음을 보고하고 주장을 정성적 표현이나 측정 전용 표현으로 둡니다.
+- 측정이 로컬 하드웨어, 캐시 상태, 네트워크, 레지스트리 상태, 이전 실행의 생성 결과에 의존한다면 그 경계를 밝힙니다.
+- 검증이 너무 느리거나 구성된 명령이 없다면 추론한 명령을 실행하지 말고 빠진 명령 의도 또는 건너뛴 의도를 보고합니다.
+- 성능 수정이 정확성, 보안, 접근성, 데이터 안전과 충돌하면 더 엄격한 정확성 경계를 보존하고 절충점을 보고합니다.
+
+<!-- mustflow-section: output-format -->
+## 출력 형식
+
+- 검토한 성능 표면
+- 예산 출처 또는 예산 없음
+- 측정 방식과 경계
+- 동기화한 기준값, 주장, 메타데이터
+- 실행한 명령 의도
+- 건너뛴 측정과 이유
+- 남은 성능 위험

package/templates/default/locales/ko/.mustflow/skills/project-context-authoring/SKILL.md

@@ -0,0 +1,107 @@
+---
+mustflow_doc: skill.project-context-authoring
+locale: ko
+canonical: false
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: project-context-authoring
+description: 저장소 근거를 바탕으로 `.mustflow/context/PROJECT.md`를 작성하거나 유지보수할 때 적용합니다.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.project-context-authoring
+  command_intents:
+    - mustflow_check
+---
+
+# 프로젝트 맥락 작성
+
+<!-- mustflow-section: purpose -->
+## 목적
+
+`.mustflow/context/PROJECT.md`를 간결한 에이전트용 브리핑으로 유지하되, 근거 없는 제품 방향, 아키텍처, 로드맵, 구현 약속이 들어가지 않도록 막습니다.
+
+<!-- mustflow-section: use-when -->
+## 사용 조건
+
+- `.mustflow/context/PROJECT.md`를 새로 채우거나, 고치거나, 정리할 때.
+- 프로젝트 목표, 비목표, 도메인 용어, 불변 조건, 검증 메모, 운영 제약, 기준 자료와 충돌 메모, 열린 질문을 에이전트용으로 기록해야 할 때.
+- 공개 문서, 매니페스트, 테스트, 소스 파일, 명령 계약이 서로 맞지 않아 맥락 파일에 충돌을 기록해야 할 때.
+
+<!-- mustflow-section: do-not-use-when -->
+## 사용하지 않는 경우
+
+- 루트 `README.md`, `PROJECT.md`, `ROADMAP.md`, API 문서, 사용자용 문서만 수정하는 작업일 때.
+- 사용자가 저장소 근거가 없는 추측성 계획, 제품 비전, 아키텍처 설계를 요청할 때.
+- 더 가까운 프로젝트 전용 맥락 작성 절차가 있을 때.
+- 변경 내용이 낮은 권한의 프로젝트 맥락이 아니라 `AGENTS.md`, `.mustflow/config/commands.toml`, `.mustflow/docs/agent-workflow.md`에 들어가야 할 때.
+
+<!-- mustflow-section: required-inputs -->
+## 필요한 입력
+
+- 기존 `.mustflow/context/PROJECT.md`.
+- `AGENTS.md`와 `.mustflow/config/*.toml`.
+- 존재하고 관련 있는 경우 루트 `PROJECT.md`, `README.md`, `ROADMAP.md`, `DESIGN.md`.
+- `REPO_MAP.md`, 패키지 매니페스트, 기존 문서, 테스트, CI 파일, 소스 파일. 단, 이들은 근거일 뿐 권한 출처가 아닙니다.
+- 현재 사용자 요청과 명시된 출처 제약.
+
+<!-- mustflow-section: preconditions -->
+## 사전 조건
+
+- 작업이 사용 조건에 맞고 사용하지 않는 경우에는 해당하지 않습니다.
+- 필요한 입력을 확보했거나, 빠진 입력을 추측하지 않고 보고할 수 있습니다.
+- 현재 범위에 대해 더 높은 우선순위의 지침과 `.mustflow/config/commands.toml`을 확인했습니다.
+
+<!-- mustflow-section: allowed-edits -->
+## 허용 수정 범위
+
+- 이 스킬, 사용자 요청, `.mustflow/skills/INDEX.md`의 맞는 경로가 설명하는 범위 안에서만 수정합니다.
+- 명령 권한을 넓히거나, 프로젝트 사실을 지어내거나, 관련 없는 워크플로 파일을 변경하지 않습니다.
+
+<!-- mustflow-section: procedure -->
+## 절차
+
+1. 현재 저장소 근거가 명확히 반박하지 않는 한 기존 사람이 작성한 맥락을 보존합니다.
+2. 기존 맥락 파일에서 시작한 뒤, 요청된 맥락 항목에 필요한 근거만 모읍니다.
+3. 확인된 사실, 가정, 미확인 항목, 충돌을 분리합니다. 문서, 매니페스트, 테스트, 소스 파일, 명령 계약 사이의 불일치를 조용히 덮지 않습니다.
+4. 맥락은 간결하게 유지합니다. 긴 설명보다 짧은 목록이나 짧은 문단을 선호합니다.
+5. 프로젝트 요약, 목표, 비목표, 도메인 용어, 위험 영역, 불변 조건, 검증, 운영 제약, 기준 자료와 충돌 메모, 열린 질문처럼 근거가 있는 항목만 다룹니다.
+6. 아키텍처, 사용자 유형, 릴리스, 코딩 규칙 메모는 저장소가 직접 근거를 제공할 때만 추가합니다.
+7. 검증을 설명할 때는 `.mustflow/config/commands.toml`의 명령 의도 이름을 참조합니다. 패키지 스크립트, CI 작업, 매니페스트 힌트를 에이전트 실행 권한으로 바꾸지 않습니다.
+8. 제품 목표, 로드맵 약속, 도메인 규칙, 구현 세부사항을 추측하지 말고, 알 수 없는 항목은 비워 두거나 명시적으로 미확인으로 표시합니다.
+
+<!-- mustflow-section: postconditions -->
+## 사후 조건
+
+- 명확한 근거, 실행한 명령 의도, 건너뛴 확인, 남은 위험을 포함해 예상 출력을 작성할 수 있습니다.
+- 빠진 명령 의도, 알 수 없는 입력, 권한 충돌은 숨기지 않고 보고합니다.
+
+<!-- mustflow-section: verification -->
+## 검증
+
+가능한 경우 설정된 일회성 명령 의도를 사용합니다.
+
+- `mustflow_check`
+
+맥락 갱신이 공개 문서나 명령 계약도 바꾸는 경우에는 해당 스킬을 추가로 적용하고 그 스킬의 설정된 검증 의도를 사용합니다.
+
+<!-- mustflow-section: failure-handling -->
+## 실패 대응
+
+- 근거가 충돌하면 한쪽을 조용히 고르지 말고 충돌이나 열린 질문으로 기록합니다.
+- 필요한 출처가 없으면 모델 기억으로 빈칸을 채우지 말고 미확인으로 표시합니다.
+- 맥락 문구가 명령 정책이나 파일 편집 금지 규칙처럼 보여 검증이 실패하면, 해당 규칙을 올바른 권한 파일로 옮기거나 근거 없는 주장을 제거합니다.
+- 맥락이 너무 길어지면 오래 유지될 사실과 기준 자료 메모 중심으로 줄입니다.
+
+<!-- mustflow-section: output-format -->
+## 출력 형식
+
+- 갱신한 맥락 항목
+- 사용한 근거 출처
+- 추가한 확인된 사실
+- 기록한 가정, 미확인 항목, 충돌
+- 실행한 명령 의도
+- 건너뛴 명령 의도와 이유
+- 남은 맥락 위험

package/templates/default/locales/ko/.mustflow/skills/pure-core-imperative-shell/SKILL.md

@@ -0,0 +1,212 @@
+---
+mustflow_doc: skill.pure-core-imperative-shell
+locale: ko
+canonical: false
+revision: 6
+lifecycle: mustflow-owned
+authority: procedure
+name: pure-core-imperative-shell
+description: Apply this skill when business decisions, validation, authorization, pricing, eligibility, state transitions, domain events, effect descriptions, or calculations are mixed with I/O such as databases, HTTP handlers, repositories, SDK calls, files, queues, logs, metrics, clocks, randomness, environment reads, payments, emails, or framework request/response objects.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.pure-core-imperative-shell
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - test_related
+    - test
+    - lint
+    - build
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Pure Core, Imperative Shell
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Separate code that decides from code that does.
+
+The pure core owns business rules, calculations, validation, authorization decisions, pricing, eligibility, state transitions, domain events, effect descriptions, and deterministic reducers. The imperative shell owns databases, HTTP, files, network calls, logging, metrics, payments, emails, queues, caches, clocks, generated identifiers, randomness, environment variables, transactions, retries, idempotency, and framework-specific objects.
+
+Core decides. Shell does.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- Business rules are mixed with database access, HTTP handlers, repositories, external SDK calls, framework objects, logs, metrics, clocks, randomness, generated identifiers, environment reads, payments, emails, files, queues, or caches.
+- Code contains meaningful `if`, `switch`, pricing, permission, eligibility, expiration, quota, scoring, matching, validation, or state-transition logic and also performs side effects.
+- Several pricing, discount, permission, scoring, matching, recommendation, or provider-choice policies need to remain pure while being selected at runtime.
+- Core tests require database mocks, HTTP mocks, SDK mocks, clock mocks, logger mocks, or framework request objects.
+- A handler, repository, adapter, worker, or event consumer hides business policy.
+- A state change must produce domain events or effect descriptions without executing those effects immediately.
+- Retrying, idempotency, stale writes, or outbox behavior depends on distinguishing the decision from its execution.
+- A state-changing shell action needs command semantics for payload, context, authorization, transaction boundaries, idempotency, audit logs, retries, concurrency, outbox records, queue reuse, or worker execution.
+- A domain lifecycle uses status, state, phase, step, or stage values and state transitions need to be pure, explicit, and table-driven.
+- A shell repeatedly coordinates several ports, adapters, repositories, queues, caches, or effect executors and needs a stable caller-facing entry point without absorbing the pure decision.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The change is trivial pass-through CRUD with no meaningful decision beyond raw input shape checks.
+- The only issue is direct construction or hidden dependency lookup; use `dependency-injection` first.
+- The only issue is external format, protocol, provider error, timeout, retry, security, or observability translation; use `adapter-boundary` first.
+- The task is pure refactoring with behavior preservation risks but no decision/execution split; use `behavior-preserving-refactor`.
+- The decision boundary is already clear and the requested edit only updates a single pure calculation.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- The business action, command, workflow, or state change being implemented or refactored.
+- The decision the domain must make and the facts needed to make it.
+- The current side effects, including persistence, external calls, messages, logs, metrics, generated identifiers, time, randomness, and environment reads.
+- Local patterns for result types, domain errors, events, effects, outbox messages, repositories, adapters, mappers, and tests.
+- Existing behavior evidence when refactoring code that already runs.
+- 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.
+- If changing existing behavior is not the goal, `behavior-preserving-refactor` has been used to protect the current behavior first.
+- If external systems cross the boundary, `adapter-boundary` has been used for provider containment.
+- If the code constructs, resolves, or imports external tools inside core logic, `dependency-injection` has been used for construction and collaborator flow.
+- If normal failures, meaningful absence, null returns, thrown business failures, or error response shapes are part of the decision boundary, `result-option` has been used for the return-shape contract.
+- If the shell action is a state-changing user or system intent with transaction, idempotency, audit, retry, outbox, queue, worker, or external side-effect concerns, `command-pattern` has been used to shape the execution unit.
+- If the core decision changes lifecycle state and allowed events depend on current state, `state-machine-pattern` has been used to define the transition table, guards, effects, and invalid-transition errors.
+- If the pure decision has several interchangeable algorithms or policies for the same purpose, `strategy-pattern` has been used to separate selection from execution.
+- If the shell needs one stable high-level entry point over a repeated multi-step subsystem workflow, `facade-pattern` has been used so callers stay simple while business decisions remain in the core.
+- The target business decision can be described without naming a database table, HTTP route, framework object, or provider SDK.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Extract deterministic decision functions, policy functions, state-transition functions, or reducers.
+- Define explicit input facts, decision output, domain events, effect descriptions, and typed business errors.
+- Move database access, network access, logging, metrics, clocks, generated identifiers, randomness, environment reads, transactions, retries, and idempotency handling into the shell.
+- Add boundary mappers between external data and core input, and between core output and persistence, messages, or responses.
+- Add fast core tests without mocks and narrower shell tests for mapping, persistence, effects, idempotency, and error translation.
+- Do not add broad service classes, global containers, event buses, or abstractions just to make the tree look layered.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Locate the mixed responsibility.
+   - Decision signals: `if`, `switch`, status checks, role checks, amount calculations, eligibility checks, validation rules, state transitions, deadline rules, quota rules, and domain error choices.
+   - Execution signals: `await`, database access, external SDK calls, HTTP clients, file access, logging, metrics, email sending, message publishing, cache access, `new Date()`, `Date.now()`, generated identifiers, randomness, and environment reads.
+2. Name the pure decision.
+   - Prefer verbs such as `decide`, `calculate`, `derive`, `validate`, `transition`, `classify`, `price`, `score`, `select`, `can`, `is`, or `has`.
+   - Avoid naming the core after a route, ORM model, SDK method, provider, or transport operation.
+3. Define explicit core input.
+   - Include every fact the decision needs: actor, domain state, loaded external facts, policy mode, current timestamp, business date, time zone, generated identifiers, random value, feature-flag result, and idempotency-relevant facts.
+   - Do not let the core reach outward to obtain missing facts.
+4. Define typed output.
+   - Use local `Result` or equivalent for expected business outcomes.
+   - Use local `Option` or equivalent when absence is meaningful and not an error.
+   - Return typed business errors for normal failures such as not found, denied access, invalid state, expired input, insufficient balance, quota exceeded, duplicate command, and stale business rule conditions.
+   - Throw only for programmer errors or impossible internal invariant violations.
+5. Keep the core deterministic.
+   - The core must not perform I/O, log, read time, generate identifiers, use direct randomness, read environment variables, mutate external state, or depend on request, response, ORM, SDK, database-row, or framework objects.
+   - Time should enter as epoch milliseconds, business date, ISO string, or explicit time context.
+   - Money should use integer minor units, explicit currency, and explicit rounding or tax policy.
+6. Return state changes, events, and effects as data.
+   - Domain events describe what happened.
+   - Effect descriptions describe what the shell should do.
+   - The core may create those values, but it must not persist, publish, send, charge, upload, delete, log, or schedule them.
+7. Shape the imperative shell.
+   - Parse raw input.
+   - Authenticate the actor.
+   - Load required facts.
+   - Resolve time, identifiers, config, feature flags, randomness, and idempotency records.
+   - Map external data to core input.
+   - Call the pure core at the decision point.
+   - Map core errors to transport or caller errors.
+   - Persist state changes and outbox records.
+   - Execute or enqueue effect descriptions.
+   - Record logs, metrics, retries, and idempotency outcomes.
+8. Split validation and authorization.
+   - Structural validation belongs in the shell: JSON shape, route parameter shape, required fields, upload size, unsupported content type, and transport limits.
+   - Business validation belongs in the core: eligibility, status, deadline, quota, refundability, inventory, coupon applicability, and domain invariants.
+   - Authentication belongs in the shell. Business authorization belongs in the core.
+9. Keep persistence honest.
+   - Map database rows to domain input before calling core.
+   - Map decisions to persistence commands after core returns.
+   - Database constraints can protect integrity, but they must not be the only place where business policy exists.
+   - Use optimistic locking, version checks, unique constraints, and transactions in the shell when stale decisions or duplicates are possible.
+10. Keep external side effects outside local transactions.
+    - Do not hold a database transaction open while calling slow network services.
+    - When local state and external messages must both be reliable, save state and outbox messages in one transaction, then publish after commit.
+    - For payments, refunds, account closure, file deletion, and other harmful repeated effects, combine deterministic core decisions with shell-side idempotency or an action ledger.
+11. Use state machines for lifecycle transitions when needed.
+    - If status, state, phase, step, or stage controls allowed actions, use `state-machine-pattern` to define the transition table, event names, guards, terminal states, effect descriptions, invalid transitions, and tests.
+    - Keep the transition function pure and let the shell persist state, transition history, idempotency records, and outbox rows.
+12. Use strategies for interchangeable pure policies when needed.
+    - If pricing, discount, scoring, ranking, matching, permission, recommendation, or provider-choice logic has several methods with one shared purpose, use `strategy-pattern`.
+    - Keep strategy selection in a selector, resolver, or shell boundary and keep strategy execution behind a shared pure contract when possible.
+13. Use command structure for state-changing shell units when needed.
+    - If one user or system intent needs explicit payload, context, authorization, transaction, idempotency, outbox, audit, retry, concurrency, or queue and worker reuse, use `command-pattern` to shape the shell execution unit.
+    - Keep the pure core as the decision maker and the command handler as the orchestrator.
+14. Use facades for repeated subsystem workflows when needed.
+    - If callers need one stable high-level operation over several shell collaborators, use `facade-pattern`.
+    - Keep the facade as an orchestration boundary; it may call the pure core, adapters, repositories, outbox, and idempotency stores, but it must not become the place where domain policy lives.
+15. Test at the right layer.
+    - Core tests should be fast, deterministic, table-driven when useful, and free of mocks, databases, networks, queues, caches, servers, and framework runtime.
+    - Shell tests should verify input mapping, error mapping, persistence, transactions, effect execution or enqueueing, retries, idempotency, observability, and provider boundary behavior.
+    - Use property-based tests for pricing, discounts, rounding, ranking, state transitions, allocation, quota, and scoring when combinations are large.
+15. Avoid ceremony when there is no real decision.
+    - Do not invent a pure core for simple create, list, update, delete flows that only pass validated fields through.
+    - Extract a core as soon as the flow gains meaningful business branching.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Given the same input, the core returns the same output.
+- The core can run without a database, network, file system, queue, cache, server, framework, logger, clock, environment variables, random generator, or generated identifier service.
+- Business rules are visible in core functions, not hidden inside handlers, repositories, adapters, or database queries.
+- The shell owns all I/O, boundary mapping, persistence, transactions, retries, idempotency, logs, metrics, and side-effect execution.
+- Business rule tests do not require mocks.
+
+<!-- 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 focused core tests for decision behavior and focused shell tests for boundary behavior. Use release or documentation checks when the change affects templates, package metadata, public docs, schemas, CLI behavior, or skill routing.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If required facts cannot be loaded or represented explicitly, stop and report the missing boundary.
+- If expected behavior is unknown, add characterization coverage or report the verification gap before extracting broad structure.
+- If extraction changes behavior, separate the behavior fix from the pure-core refactor.
+- If the shell still contains business branches after extraction, continue until only orchestration and transport checks remain or report the remaining policy explicitly.
+- If the core still imports infrastructure, reapply `dependency-injection` and `adapter-boundary`.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Decision being isolated
+- Side effects moved or kept in shell
+- Core input facts and typed outputs introduced
+- Events or effect descriptions introduced
+- State-machine transition table introduced or reused
+- Strategy family introduced or reused
+- Facade boundary introduced or intentionally avoided
+- Shell responsibilities and boundary mappers
+- Business failures represented as values
+- Tests or verification evidence
+- Skipped checks and remaining mixed-logic risk