mustflow 2.112.3 → 2.112.7

package/templates/default/locales/en/.mustflow/skills/module-boundary-review/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.module-boundary-review
 locale: en
 canonical: true
-revision: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: module-boundary-review
-description: Apply this skill when code is created, changed, reviewed, or reported and module separation, cohesion, coupling, data ownership, rule ownership, failure ownership, import direction, circular dependency, DTO leakage, shared/common/utils growth, mock-heavy tests, repeated policy conditions, enum interpretation, repository business logic, anemic domain, domain-to-I/O leakage, transaction boundary mismatch, event naming, public API bloat, caller sequencing, premature reuse, co-change history, bug/fix distance, config ownership, log responsibility, exception translation, cache invalidation ownership, repeated authorization checks, frontend/backend policy leakage, time policy, batch or worker bypass, or temporary-code accumulation can make a change spread beyond its real owner.
+description: Apply this skill when code is created, changed, reviewed, or reported and module separation, cohesion, coupling, change axes, stability direction, data ownership, rule ownership, failure ownership, import direction, circular dependency, DTO leakage, shared/common/utils growth, mock-heavy tests, repeated policy conditions, enum interpretation, repository business logic, anemic domain, domain-to-I/O leakage, transaction boundary mismatch, event naming, public API bloat, caller sequencing, premature reuse, co-change history, bug/fix distance, config ownership, log responsibility, exception translation, cache invalidation ownership, repeated authorization checks, frontend/backend policy leakage, time policy, batch or worker bypass, shallow modules, or temporary-code accumulation can make a change spread beyond its real owner.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -46,6 +46,12 @@ who must change, who owns the data, who owns the failure, and who should not nee
   files repeatedly change together.
 - A review claims that layering, clean architecture, DDD, modular monolith, feature folders,
   repositories, services, shared utilities, events, DTOs, or frontend/backend separation is clean.
+- A design starts from feature folders, technical layers, or CRUD nouns and may be missing the real
+  split criterion: who changes the code, when, why, and independently of which other owners.
+- A module depends on a more volatile detail such as a provider SDK, UI route flow, database query
+  shape, external response, framework object, config dialect, or generated transport model.
+- A change creates many thin files whose public APIs are wider than the hidden implementation, or
+  whose abstractions only forward calls, wrap switches, or rename CRUD.
 - The suspected issue is not a large service split yet, but a local module boundary that leaks
   business rules, data shape, failure handling, sequencing, or ownership to neighbors.
 
@@ -70,12 +76,21 @@ who must change, who owns the data, who owns the failure, and who should not nee
 
 - Change reason: the policy, feature, bug, data shape, failure path, or operational behavior that
   caused the edit.
+- Change-axis ledger: likely independent changes over the next useful planning horizon, including
+  policy, external provider, data model, UI flow, permission, pricing, billing, deployment, and
+  operational changes, plus who or what would cause each change.
 - Changed-file spread: folders, modules, layers, packages, tests, generated files, templates, and
   docs touched by the same reason.
 - Co-change evidence when available: recent commits, PRs, repeated paired files, or local diff
   history showing files that usually move together.
 - Module graph evidence: imports, exports, public APIs, call sites, dependency direction, cycles,
   shared helpers, DTO flow, and configuration reads.
+- Stability evidence: which modules many callers rely on, which modules change because external
+  details move, and whether dependencies point toward the more stable policy owner rather than the
+  more volatile implementation detail.
+- Change-simulation evidence: expected files touched for at least three concrete next changes, such
+  as changing a payment provider, adding a pricing rule, changing admin UI flow, changing invoice
+  format, changing permissions, or adding a worker path.
 - Configured guardrail evidence when available: `code/module-boundary` results for
   `.mustflow/config/module-boundaries.toml` layer deny rules, public entrypoints, feature imports,
   shared budgets, and import cycles.
@@ -121,15 +136,30 @@ who must change, who owns the data, who owns the failure, and who should not nee
    - Count how many modules, folders, layers, tests, docs, and templates changed for that one reason.
    - If one policy edit forces controller, service, repository, mapper, utility, constants, worker,
      and UI edits together, treat the module boundary as suspect.
+   - Before accepting a new split, list the independent change axes first. Do not start with
+     `controllers`, `services`, `repositories`, `utils`, or CRUD nouns unless the repository already
+     proves those are the real change units.
 2. Group by reason to change.
    - Files with different names but the same change reason are one module candidate.
    - `UserService`, `UserValidator`, `UserMapper`, `UserPolicy`, and `UserHelper` changing together is
      evidence of sliced roles, not necessarily separated modules.
+   - Write each candidate module as "this module changes when ...". If that sentence names more than
+     one independent owner, split the candidate or report the boundary risk.
+   - Prefer volatility names and business capabilities, such as pricing policy, payment provider,
+     subscription lifecycle, invoice rendering, fraud check, fulfillment handoff, or entitlement
+     decision, over role-sliced layer names when those better predict future edits.
 3. Check import direction.
    - Infrastructure or low-level modules should not know high-level business use case names unless
      the repository intentionally uses that inversion.
    - Treat lower layers importing policy names such as plan, checkout, approval, permission, or
      subscription as evidence that the policy leaked downward.
+   - Check stability direction. Code that many callers depend on should not import volatile details
+     such as Stripe, Toss, Prisma, SQLAlchemy, React Router, FastAPI request objects, provider DTOs,
+     raw SQL builders, generated clients, or `process.env` unless the repository explicitly makes
+     that layer an edge adapter.
+   - Prefer interfaces or ports owned by the using side when the abstraction protects stable policy
+     code from an unstable provider, database, queue, cache, filesystem, network, framework, or UI
+     detail.
 4. Treat cycles as boundary failure until proven harmless.
    - If A imports B and B imports A, identify the missing concept, ownership decision, event, port, or
      data-flow direction.
@@ -188,6 +218,11 @@ who must change, who owns the data, who owns the failure, and who should not nee
     - Too many exported functions can mean internals are on display.
     - If callers must call `create`, then `apply`, then `reserve`, then `mark`, the module has handed
       out an assembly manual instead of owning the sequence.
+    - A good module should have a small door and a deeper inside. If most files only expose one-line
+      forwarding methods, wrapper services, or renamed CRUD calls, treat the split as shallow module
+      theater until a real hidden decision or variation point is named.
+    - A public API wider than the behavior it hides is usually not a boundary; it is implementation
+      leakage with extra navigation.
 16. Check reuse claims.
     - "Used in many places" is not enough reason to extract a common helper.
     - Reuse is safe only when the callers change for the same reason. Similar code from different
@@ -197,20 +232,27 @@ who must change, who owns the data, who owns the failure, and who should not nee
       names.
     - If a file repeatedly receives temporary exceptions in the same direction, name the missing
       concept instead of adding another branch.
-18. Compare bug location with fix location.
+18. Run change simulations.
+    - Pick at least three plausible next changes from the change-axis ledger.
+    - For each scenario, list which modules should change and which modules must stay ignorant.
+    - If changing a provider, UI flow, invoice format, permission rule, or pricing rule repeatedly
+      crosses the same unrelated modules, treat that as hidden coupling.
+    - If a module would break because a different module's test changed, identify whether the
+      boundary couples futures that should be independent.
+19. Compare bug location with fix location.
     - If the symptom appears in one module but the fix belongs in an unrelated utility, policy, or
       mapper, the responsibility line may be bent.
-19. Check config, time, and logging responsibility.
+20. Check config, time, and logging responsibility.
     - Raw `process.env`, feature flag, remote config, clock, timezone, locale, and date parsing should
       usually be read at the edge and injected as explicit values.
     - Logs that mention another module's job, such as payment code logging welcome-email failure, are
       strong ownership evidence.
-20. Translate exceptions at boundaries.
+21. Translate exceptions at boundaries.
     - Database, provider, filesystem, framework, and payment errors should not leak through every
       layer unchanged.
     - Convert external failure dialect into the receiving module's language while preserving safe
       diagnostic causes.
-21. Check cache invalidation, authorization, frontend policy, and alternate entrypoints.
+22. Check cache invalidation, authorization, frontend policy, and alternate entrypoints.
     - Cache invalidation belongs near the data owner, not scattered across random callers.
     - Authorization checks repeated in controllers should move to one use-case entry, policy, or
       capability boundary.
@@ -218,7 +260,14 @@ who must change, who owns the data, who owns the failure, and who should not nee
       backend policy from internal statuses.
     - Batch, cron, worker, and admin tools should use the same use case or policy owner as online
       requests instead of bypassing validations, events, logs, and permissions.
-22. Decide the smallest response.
+23. Attack the design before accepting it.
+    - Name the three modules or abstractions most likely to rot first.
+    - For each, name the change request that would break it, the owner that would cause the change,
+      and whether the blast stays inside one module.
+    - Remove or redesign shallow wrappers, central managers, enum-switch strategies, provider-shaped
+      "neutral" ports, configuration-driven logic hiding, event-bus call hiding, and CRUD stamp
+      modules when they fail the attack.
+24. Decide the smallest response.
     - If evidence is strong and the edit is in scope, make the smallest boundary fix.
     - If the fix would be broad, report the module boundary risk and the first safe split point.
     - If evidence is weak, leave the structure alone and report the missing co-change or ownership
@@ -229,9 +278,15 @@ who must change, who owns the data, who owns the failure, and who should not nee
 
 - The changed reason, changed-file spread, co-change evidence, data owner, policy owner, failure
   owner, and public module surface are explicit or reported as missing.
+- The relevant change axes and stability direction are explicit, or reported as missing evidence.
+- At least three change simulations were checked when designing or accepting a new module boundary,
+  unless the task is only auditing an existing small local diff.
 - Import direction, cycles, DTO spread, shared helper ownership, repository policy leakage, domain
   I/O leakage, transaction mismatch, event naming, caller sequencing, duplicated policy, and alternate
   entrypoints are fixed or reported where relevant.
+- Shallow module signals such as role-sliced CRUD layers, one-line wrappers, provider-shaped ports,
+  ownerless managers, event-bus call hiding, config-hidden logic, and public API bloat are removed,
+  justified, or reported.
 - Any new abstraction hides a named responsibility and reduces caller knowledge, change spread, or
   test mock cost.
 - Behavior, public contracts, permissions, data ownership, and failure semantics remain intact or
@@ -276,11 +331,13 @@ design is clean.
 ## Output Format
 
 - Module boundary reviewed
-- Change reason and changed-file spread
+- Change reason, change axes, stability direction, and changed-file spread
 - Co-change, import direction, cycle, DTO, shared helper, public API, caller sequencing, and test mock
   evidence
 - Data owner, policy owner, failure owner, cache invalidation owner, config/time owner, and
   authorization owner where relevant
+- Change simulations and most-likely-to-rot modules
+- Shallow module signals found, fixed, justified, or deferred
 - Boundary fixes made or recommended
 - Evidence level: current diff, local source evidence, history evidence, configured-test evidence,
   missing, or not applicable

package/templates/default/locales/en/.mustflow/skills/routes.toml

@@ -198,6 +198,12 @@ route_type = "adjunct"
 priority = 76
 applies_to_reasons = ["unknown_change", "code_change", "behavior_change", "test_change", "public_api_change", "performance_change"]
 
+[routes."abstraction-boundary-review"]
+category = "general_code"
+route_type = "adjunct"
+priority = 77
+applies_to_reasons = ["unknown_change", "code_change", "behavior_change", "test_change", "public_api_change", "performance_change", "data_change"]
+
 [routes."module-boundary-review"]
 category = "general_code"
 route_type = "adjunct"

package/templates/default/locales/en/AGENTS.md

@@ -2,7 +2,7 @@
 mustflow_doc: agents.root
 locale: en
 canonical: true
-revision: 18
+revision: 20
 lifecycle: user-editable
 authority: binding
 ---
@@ -92,8 +92,17 @@ mustflow-managed details are under `.mustflow/`.
 
 - When searching unfamiliar code, look for nearby `mf:anchor` comments and use them as
   navigation metadata for durable responsibility boundaries.
+- Source anchors are indexed into the local SQLite cache only when source indexing is enabled,
+  typically through a configured local-index intent such as `mf run local_index` or through
+  `mf index --source` when the command contract permits that command.
+- Use `mf search --scope source <query>` to find source-anchor coordinates, or
+  `mf search --scope all <query>` when workflow documents and source anchors should be searched
+  together. Search results point to files, line numbers, anchor IDs, and risk tags that still need
+  to be read in the current source tree.
 - Treat source anchors as navigation-only hints. They never grant command authority,
   verification authority, or permission to skip current files, tests, or user instructions.
+- If `mf search` reports a missing or stale index, refresh through the configured local-index
+  intent when available instead of treating old search rows as current evidence.
 - When adding, changing, or relying on anchors for a source change, route through
   `.mustflow/skills/source-anchor-authoring/SKILL.md` if installed.
 
@@ -106,6 +115,10 @@ mustflow-managed details are under `.mustflow/`.
   Follow the stricter rule.
 - When navigating to a nested repository, reread that repository's `AGENTS.md` and
   `.mustflow/config/*.toml` before editing.
+- In repository farms, prefer each child repository's own command contract for repository-owned
+  commands. If the parent root intentionally orchestrates children, split parent-owned commands
+  into repo-named fragments under `.mustflow/config/commands/`; use
+  `mf workspace command-fragments` for read-only guidance.
 - Do not edit outside the selected child repository unless explicitly requested.
 
 ## Host-Specific Instruction Compatibility

package/templates/default/locales/ko/AGENTS.md

@@ -2,7 +2,7 @@
 mustflow_doc: agents.root
 locale: ko
 canonical: false
-revision: 25
+revision: 27
 lifecycle: user-editable
 authority: binding
 ---
@@ -60,7 +60,10 @@ mustflow가 관리하는 세부 문서와 설정은 `.mustflow/` 폴더 아래
 ## 소스 앵커
 
 - 익숙하지 않은 코드를 탐색할 때는 주변 `mf:anchor` 주석을 찾아보고, 오래 유지되는 책임 경계를 찾기 위한 탐색 메타데이터로 사용합니다.
+- 소스 앵커는 소스 색인이 켜져 있을 때만 로컬 SQLite 캐시에 들어갑니다. 보통 `mf run local_index` 같은 설정된 로컬 색인 인텐트를 통하거나, 명령 계약이 해당 명령을 허용하는 경우 `mf index --source`로 색인합니다.
+- `mf search --scope source <query>`로 소스 앵커 좌표를 찾고, 워크플로우 문서와 소스 앵커를 함께 찾아야 할 때는 `mf search --scope all <query>`를 사용합니다. 검색 결과는 파일, 줄 번호, 앵커 ID, risk tag를 가리키는 탐색 좌표일 뿐이며, 현재 소스 파일을 다시 읽어야 합니다.
 - 소스 앵커는 탐색용 힌트일 뿐입니다. 명령 실행 권한, 검증 권한, 현재 파일/테스트/사용자 지시를 건너뛸 권한을 부여하지 않습니다.
+- `mf search`가 색인 누락이나 오래된 색인을 보고하면, 오래된 검색 행을 현재 근거로 삼지 말고 가능한 경우 설정된 로컬 색인 인텐트로 새로 고칩니다.
 - 소스 변경에서 앵커를 추가하거나 수정하거나 앵커에 의존해야 한다면, 설치되어 있는 경우 `.mustflow/skills/source-anchor-authoring/SKILL.md` 절차를 따릅니다.
 
 ## 상위/하위 규칙 우선순위
@@ -69,6 +72,7 @@ mustflow가 관리하는 세부 문서와 설정은 `.mustflow/` 폴더 아래
 - 작업 방식, 코드 스타일, 테스트 방식, 명령 실행 규칙이 충돌할 경우 하위 저장소의 `AGENTS.md`와 `.mustflow/config/commands.toml`을 우선합니다.  
 - 보안, 비밀 정보, 개인정보, 파괴적 명령, 수정 가능 경로 등 안전 규칙은 누적 적용하며 더 엄격한 규칙을 따릅니다.  
 - 상위 작업 공간에서 하위 저장소로 진입한 경우, 하위 저장소의 `AGENTS.md`와 `.mustflow/config/*.toml`을 다시 읽은 뒤 작업합니다.  
+- repository farm에서는 각 하위 저장소가 소유한 명령은 해당 저장소의 command contract를 우선합니다. 상위 루트가 하위 저장소를 의도적으로 orchestration해야 한다면 상위 소유 명령을 `.mustflow/config/commands/` 아래 repo 이름별 fragment로 나누고, `mf workspace command-fragments`로 읽기 전용 안내를 확인합니다.  
 - 명시적 요청 없이 선택한 하위 저장소 밖의 파일은 수정하지 않습니다.
 
 ## 호스트별 지침 호환성

package/templates/default/manifest.toml

@@ -1,6 +1,6 @@
 id = "default"
 name = "default"
-version = "2.112.3"
+version = "2.112.7"
 description = "Minimal workflow for LLM agents to read, edit, and verify their work in a repository."
 common_root = "common"
 locales_root = "locales"
@@ -27,6 +27,7 @@ creates = [
   ".mustflow/skills/code-review/SKILL.md",
   ".mustflow/skills/ai-generated-code-hardening/SKILL.md",
   ".mustflow/skills/quality-gaming-guard/SKILL.md",
+  ".mustflow/skills/abstraction-boundary-review/SKILL.md",
   ".mustflow/skills/module-boundary-review/SKILL.md",
   ".mustflow/skills/change-blast-radius-review/SKILL.md",
   ".mustflow/skills/business-rule-leakage-review/SKILL.md",
@@ -234,6 +235,7 @@ after_install = [
   "Read AGENTS.md for repository-specific working rules.",
   "Run mf doctor to inspect the current state before editing.",
   "Generate REPO_MAP.md with mf map when a repository map is needed.",
+  "For repo farms under projects/, run mf workspace command-fragments --projects-dir projects --json before putting many child-repository commands in one parent command file.",
   "Review the default Bun-backed test intents in .mustflow/config/commands.toml and replace them with narrower project commands when useful.",
   "Add your lint and build commands to .mustflow/config/commands.toml.",
   "Review repository-specific language and style defaults in .mustflow/config/preferences.toml.",
@@ -261,6 +263,7 @@ minimal = [
   "code-review",
   "ai-generated-code-hardening",
   "quality-gaming-guard",
+  "abstraction-boundary-review",
   "module-boundary-review",
   "change-blast-radius-review",
   "business-rule-leakage-review",
@@ -430,6 +433,7 @@ patterns = [
   "code-review",
   "ai-generated-code-hardening",
   "quality-gaming-guard",
+  "abstraction-boundary-review",
   "module-boundary-review",
   "change-blast-radius-review",
   "business-rule-leakage-review",
@@ -610,6 +614,7 @@ oss = [
   "code-review",
   "ai-generated-code-hardening",
   "quality-gaming-guard",
+  "abstraction-boundary-review",
   "module-boundary-review",
   "change-blast-radius-review",
   "business-rule-leakage-review",
@@ -808,6 +813,7 @@ team = [
   "code-review",
   "ai-generated-code-hardening",
   "quality-gaming-guard",
+  "abstraction-boundary-review",
   "module-boundary-review",
   "change-blast-radius-review",
   "business-rule-leakage-review",
@@ -991,6 +997,7 @@ product = [
   "code-review",
   "ai-generated-code-hardening",
   "quality-gaming-guard",
+  "abstraction-boundary-review",
   "module-boundary-review",
   "change-blast-radius-review",
   "business-rule-leakage-review",
@@ -1180,6 +1187,7 @@ library = [
   "code-review",
   "ai-generated-code-hardening",
   "quality-gaming-guard",
+  "abstraction-boundary-review",
   "module-boundary-review",
   "change-blast-radius-review",
   "business-rule-leakage-review",