mustflow 2.22.5 → 2.22.12

package/dist/core/command-contract-validation.js

@@ -6,11 +6,11 @@ import { COMMAND_EFFECT_CONCURRENCY, COMMAND_EFFECT_MODES, COMMAND_EFFECT_TYPES,
 import { commandIntentBlockedCommandPattern, commandIntentHasCommandSource, commandIntentNameIsSafe, } from './command-contract-rules.js';
 import { MAX_COMMAND_OUTPUT_BYTES, commandMaxOutputBytesLimitMessage } from './command-output-limits.js';
 import { SUCCESS_EXIT_CODES_CONTRACT_DESCRIPTION, successExitCodesAreValid } from './success-exit-codes.js';
-function commandContractIssue(message) {
-    return { message };
+function commandContractIssue(message, id) {
+    return id ? { id, message } : { message };
 }
-function commandContractWarning(message) {
-    return { message, severity: 'warning' };
+function commandContractWarning(message, id) {
+    return id ? { id, message, severity: 'warning' } : { message, severity: 'warning' };
 }
 function hasOwn(table, key) {
     return Object.prototype.hasOwnProperty.call(table, key);
@@ -56,7 +56,7 @@ function validatePositiveIntegerField(table, key, label, issues) {
 function validateMaxOutputBytesField(table, key, label, issues) {
     validatePositiveIntegerField(table, key, label, issues);
     if (isPositiveInteger(table[key]) && Number(table[key]) > MAX_COMMAND_OUTPUT_BYTES) {
-        issues.push(commandContractIssue(commandMaxOutputBytesLimitMessage(label)));
+        issues.push(commandContractIssue(commandMaxOutputBytesLimitMessage(label), 'mustflow.command_contract.max_output_bytes_exceeds_limit'));
     }
 }
 function validateAllowedStringField(table, key, label, allowedValues, issues) {
@@ -115,7 +115,7 @@ function validateCommandIntentEffects(intentName, intent, issues) {
         return;
     }
     if (!Array.isArray(intent.effects) || intent.effects.some((entry) => !isRecord(entry))) {
-        issues.push(commandContractIssue(`[commands.intents.${intentName}].effects must be an array of tables`));
+        issues.push(commandContractIssue(`[commands.intents.${intentName}].effects must be an array of tables`, 'mustflow.command_contract.effects_invalid'));
         return;
     }
     for (const effect of intent.effects) {
@@ -171,39 +171,39 @@ function validateCommandIntent(intentName, intent, issues) {
     const lifecycle = typeof intent.lifecycle === 'string' ? intent.lifecycle : undefined;
     const runPolicy = typeof intent.run_policy === 'string' ? intent.run_policy : undefined;
     if (!lifecycle) {
-        issues.push(commandContractIssue(`Configured intent ${intentName} must define lifecycle`));
+        issues.push(commandContractIssue(`Configured intent ${intentName} must define lifecycle`, 'mustflow.command_contract.configured_missing_lifecycle'));
     }
     if (!runPolicy) {
-        issues.push(commandContractIssue(`Configured intent ${intentName} must define run_policy`));
+        issues.push(commandContractIssue(`Configured intent ${intentName} must define run_policy`, 'mustflow.command_contract.configured_missing_run_policy'));
     }
     if (lifecycle === 'oneshot') {
         validatePositiveIntegerField(intent, 'timeout_seconds', `[commands.intents.${intentName}].timeout_seconds`, issues);
         if (!hasOwn(intent, 'timeout_seconds')) {
-            issues.push(commandContractIssue(`Oneshot intent ${intentName} must define timeout_seconds`));
+            issues.push(commandContractIssue(`Oneshot intent ${intentName} must define timeout_seconds`, 'mustflow.command_contract.oneshot_missing_timeout'));
         }
         if (intent.stdin !== 'closed') {
-            issues.push(commandContractIssue(`Oneshot intent ${intentName} must set stdin = "closed"`));
+            issues.push(commandContractIssue(`Oneshot intent ${intentName} must set stdin = "closed"`, 'mustflow.command_contract.oneshot_stdin_not_closed'));
         }
     }
     if (lifecycle && LONG_RUNNING_LIFECYCLES.has(lifecycle) && runPolicy === 'agent_allowed') {
-        issues.push(commandContractIssue(`Long-running intent ${intentName} must not use run_policy = "agent_allowed"`));
+        issues.push(commandContractIssue(`Long-running intent ${intentName} must not use run_policy = "agent_allowed"`, 'mustflow.command_contract.long_running_agent_allowed'));
     }
     if (intent.mode === 'shell' && runPolicy === 'agent_allowed' && intent.allow_shell !== true) {
-        issues.push(commandContractIssue(`Agent-runnable shell intent ${intentName} must set allow_shell = true`));
+        issues.push(commandContractIssue(`Agent-runnable shell intent ${intentName} must set allow_shell = true`, 'mustflow.command_contract.agent_shell_requires_allow'));
     }
     if (!commandIntentHasCommandSource(intent)) {
-        issues.push(commandContractIssue(`Configured intent ${intentName} must define argv or mode = "shell" with cmd`));
+        issues.push(commandContractIssue(`Configured intent ${intentName} must define argv or mode = "shell" with cmd`, 'mustflow.command_contract.executable_source_missing'));
     }
     const blockedCommandPattern = commandIntentBlockedCommandPattern(intent);
     if (blockedCommandPattern?.code === 'shell_background_pattern') {
-        issues.push(commandContractIssue(`Shell intent ${intentName} contains a blocked long-running or background pattern`));
+        issues.push(commandContractIssue(`Shell intent ${intentName} contains a blocked long-running or background pattern`, 'mustflow.command_contract.shell_background_pattern'));
     }
     if (blockedCommandPattern?.code === 'long_running_command_pattern') {
-        issues.push(commandContractIssue(`Intent ${intentName} contains a blocked long-running or background command pattern`));
+        issues.push(commandContractIssue(`Intent ${intentName} contains a blocked long-running or background command pattern`, 'mustflow.command_contract.long_running_command_pattern'));
     }
     if (hasOwn(intent, 'success_exit_codes')) {
         if (!successExitCodesAreValid(intent.success_exit_codes)) {
-            issues.push(commandContractIssue(`[commands.intents.${intentName}].success_exit_codes must be ${SUCCESS_EXIT_CODES_CONTRACT_DESCRIPTION}`));
+            issues.push(commandContractIssue(`[commands.intents.${intentName}].success_exit_codes must be ${SUCCESS_EXIT_CODES_CONTRACT_DESCRIPTION}`, 'mustflow.command_contract.success_exit_codes_invalid'));
         }
     }
     validateCommandIntentEffects(intentName, intent, issues);
@@ -281,7 +281,9 @@ function validateCommandEnvInheritanceWarnings(commandsToml) {
     const issues = [];
     for (const warning of findCommandEnvInheritanceWarnings(commandsToml)) {
         const message = formatCommandEnvInheritanceWarning(warning);
-        issues.push(warning.severity === 'warning' ? commandContractWarning(message) : commandContractIssue(message));
+        issues.push(warning.severity === 'warning'
+            ? commandContractWarning(message, 'mustflow.command_contract.broad_env_inheritance')
+            : commandContractIssue(message, 'mustflow.command_contract.broad_env_inheritance'));
     }
     return issues;
 }
@@ -316,7 +318,7 @@ function validateProjectLocalBinWarnings(projectRoot, commandsToml) {
         if (!projectLocalBinExecutableExists(projectRoot, executable)) {
             continue;
         }
-        issues.push(commandContractWarning(`configured agent-runnable intent ${intentName} uses bare executable "${executable}" that matches project-local node_modules/.bin; use a package-manager mediated command such as npm exec, pnpm exec, bun x, or yarn exec`));
+        issues.push(commandContractWarning(`configured agent-runnable intent ${intentName} uses bare executable "${executable}" that matches project-local node_modules/.bin; use a package-manager mediated command such as npm exec, pnpm exec, bun x, or yarn exec`, 'mustflow.command_contract.project_local_bin_bare_executable'));
     }
     return issues;
 }
@@ -336,12 +338,12 @@ export function validateCommandContractConfig(commandsToml) {
     validateCommandDefaults(commandsToml, issues);
     validateCommandResources(commandsToml, issues);
     if (!isRecord(commandsToml.intents)) {
-        issues.push(commandContractIssue('Missing [intents] table in .mustflow/config/commands.toml'));
+        issues.push(commandContractIssue('Missing [intents] table in .mustflow/config/commands.toml', 'mustflow.command_contract.intent_table_missing'));
         return issues;
     }
     for (const [intentName, intent] of Object.entries(commandsToml.intents)) {
         if (!isRecord(intent)) {
-            issues.push(commandContractIssue(`Intent ${intentName} must be a TOML table`));
+            issues.push(commandContractIssue(`Intent ${intentName} must be a TOML table`, 'mustflow.command_contract.intent_not_table'));
             continue;
         }
         validateCommandIntent(intentName, intent, issues);

package/dist/core/contract-lint.js

@@ -14,6 +14,7 @@ const CONTRACT_LINT_SOURCE_FILES = [
     '.mustflow/docs/agent-workflow.md',
     'AGENTS.md',
     'src/core/change-classification.ts',
+    'src/core/change-classification-policy.ts',
 ];
 export const DOCUMENTED_VERIFICATION_REASONS = [
     'before_publish',
@@ -49,7 +50,10 @@ const RELEASE_SENSITIVE_REASONS = new Set([
 ]);
 const COMMANDS_CONFIG_PATH = '.mustflow/config/commands.toml';
 const SKILL_INDEX_PATH = '.mustflow/skills/INDEX.md';
-const CHANGE_CLASSIFICATION_SOURCE_PATH = 'src/core/change-classification.ts';
+const CHANGE_CLASSIFICATION_SOURCE_PATHS = [
+    'src/core/change-classification.ts',
+    'src/core/change-classification-policy.ts',
+];
 const AGENT_WORKFLOW_PATH = '.mustflow/docs/agent-workflow.md';
 const PACKAGE_SCRIPT_RUNNERS = new Set(['bun', 'npm', 'pnpm', 'yarn']);
 const MAKEFILE_CANDIDATES = ['Makefile', 'makefile'];
@@ -413,7 +417,7 @@ function classifyReasonSource(reason, knownClassificationReasons, documentedVeri
 function buildRelatedDocs(source, relatedSkills) {
     const docs = [COMMANDS_CONFIG_PATH];
     if (source === 'classification') {
-        docs.push(CHANGE_CLASSIFICATION_SOURCE_PATH);
+        docs.push(...CHANGE_CLASSIFICATION_SOURCE_PATHS);
     }
     if (source === 'documented') {
         docs.push(AGENT_WORKFLOW_PATH);

package/dist/core/correlation-id.js

@@ -0,0 +1,16 @@
+import { randomBytes } from 'node:crypto';
+export const CORRELATION_ID_PATTERN = '^mf-[a-z][a-z0-9_-]*-[0-9a-f]{16}$';
+const CORRELATION_ID_REGEX = new RegExp(CORRELATION_ID_PATTERN);
+function normalizeCorrelationScope(scope) {
+    const normalized = scope
+        .toLowerCase()
+        .replace(/[^a-z0-9_-]+/g, '_')
+        .replace(/^_+|_+$/g, '');
+    return /^[a-z][a-z0-9_-]*$/.test(normalized) ? normalized : 'event';
+}
+export function createCorrelationId(scope) {
+    return `mf-${normalizeCorrelationScope(scope)}-${randomBytes(8).toString('hex')}`;
+}
+export function isCorrelationId(value) {
+    return typeof value === 'string' && CORRELATION_ID_REGEX.test(value);
+}

package/dist/core/run-receipt.js

@@ -225,6 +225,7 @@ export function createRunReceipt(input) {
     return {
         schema_version: RUN_RECEIPT_SCHEMA_VERSION,
         command: 'run',
+        correlation_id: input.correlationId,
         intent: input.intent,
         status: input.status,
         timed_out: input.timedOut,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mustflow",
-  "version": "2.22.5",
+  "version": "2.22.12",
   "description": "Agent workflow documents and CLI for mustflow repository roots.",
   "type": "module",
   "license": "MIT-0",
@@ -36,10 +36,13 @@
     "test:coverage": "bun run build && node scripts/run-cli-tests.mjs coverage",
     "test:audit": "node scripts/audit-tests.mjs --json",
     "test:release": "bun run build && node scripts/run-cli-tests.mjs release",
+    "test:fast:node": "npm run build && node scripts/run-cli-tests.mjs fast",
+    "test:release:node": "npm run build && node scripts/run-cli-tests.mjs release",
     "test:full": "bun run build && node scripts/run-cli-tests.mjs full-auto",
     "test:full:auto": "bun run build && node scripts/run-cli-tests.mjs full-auto",
     "test:full:serial": "bun run build && node scripts/run-cli-tests.mjs full",
     "check": "bun run check:package && bun run test:full",
+    "check:core:node": "node scripts/run-node-core-check.mjs",
     "check:package": "node -e \"const fs=require('fs'); JSON.parse(fs.readFileSync('package.json','utf8')); console.log('package.json ok')\"",
     "check:typecheck": "tsc -p tsconfig.json --noEmit",
     "prepack": "npm run build",

package/schemas/README.md

@@ -48,6 +48,10 @@ Current schemas:
 These schemas define stable, automation-facing fields. Human-readable command  
 output is intentionally excluded.
 
+Current `classify`, `verify`, `run`, dashboard export, and verify state outputs may include
+`correlation_id` so local artifacts from one work incident can be connected without storing raw
+transcripts, environment values, or hidden reasoning.
+
 The published schema surface is tracked in `src/core/public-json-contracts.ts`.  
 Release tests verify consistency between this manifest, `schemas/*.schema.json`,  
 `npm pack --dry-run --json`, and the installed package’s JSON command output.

package/schemas/change-verification-report.schema.json

@@ -29,6 +29,10 @@
     "classification_summary": {
       "$ref": "#/$defs/classificationSummary"
     },
+    "correlation_id": {
+      "type": "string",
+      "pattern": "^mf-[a-z][a-z0-9_-]*-[0-9a-f]{16}$"
+    },
     "verification_plan_id": {
       "type": "string",
       "pattern": "^sha256:[0-9a-f]{64}$"

package/schemas/classify-report.schema.json

@@ -16,6 +16,10 @@
   "properties": {
     "schema_version": { "const": "1" },
     "command": { "const": "classify" },
+    "correlation_id": {
+      "type": "string",
+      "pattern": "^mf-[a-z][a-z0-9_-]*-[0-9a-f]{16}$"
+    },
     "mustflow_root": { "type": "string" },
     "source": { "enum": ["changed", "paths"] },
     "files": {

package/schemas/dashboard-export.schema.json

@@ -20,6 +20,10 @@
   "properties": {
     "schema_version": { "const": "1" },
     "command": { "const": "dashboard export" },
+    "correlation_id": {
+      "type": "string",
+      "pattern": "^mf-[a-z][a-z0-9_-]*-[0-9a-f]{16}$"
+    },
     "format": { "enum": ["html", "json"] },
     "generated_at": { "type": "string" },
     "mustflow_root": { "type": "string" },

package/schemas/latest-run-pointer.schema.json

@@ -23,6 +23,10 @@
     "schema_version": { "const": "1" },
     "command": { "const": "verify" },
     "kind": { "const": "verify_run_summary" },
+    "correlation_id": {
+      "type": "string",
+      "pattern": "^mf-[a-z][a-z0-9_-]*-[0-9a-f]{16}$"
+    },
     "reason": { "type": "string" },
     "reasons": {
       "type": "array",

package/schemas/run-receipt.schema.json

@@ -34,6 +34,10 @@
   "properties": {
     "schema_version": { "const": "1" },
     "command": { "const": "run" },
+    "correlation_id": {
+      "type": "string",
+      "pattern": "^mf-[a-z][a-z0-9_-]*-[0-9a-f]{16}$"
+    },
     "intent": { "type": "string" },
     "status": { "enum": ["passed", "failed", "timed_out", "start_failed", "output_limit_exceeded"] },
     "timed_out": { "type": "boolean" },

package/schemas/verify-report.schema.json

@@ -23,6 +23,10 @@
   "properties": {
     "schema_version": { "const": "1" },
     "command": { "const": "verify" },
+    "correlation_id": {
+      "type": "string",
+      "pattern": "^mf-[a-z][a-z0-9_-]*-[0-9a-f]{16}$"
+    },
     "mustflow_root": { "type": "string" },
     "reason": { "type": "string" },
     "reasons": {

package/schemas/verify-run-manifest.schema.json

@@ -20,6 +20,10 @@
   "properties": {
     "schema_version": { "const": "1" },
     "command": { "const": "verify" },
+    "correlation_id": {
+      "type": "string",
+      "pattern": "^mf-[a-z][a-z0-9_-]*-[0-9a-f]{16}$"
+    },
     "reason": { "type": "string" },
     "reasons": {
       "type": "array",

package/templates/default/i18n.toml

@@ -74,7 +74,7 @@ translations = {}
 [documents."skill.architecture-deepening-review"]
 source = "locales/en/.mustflow/skills/architecture-deepening-review/SKILL.md"
 source_locale = "en"
-revision = 1
+revision = 2
 translations = {}
 
 [documents."skill.behavior-preserving-refactor"]
@@ -325,7 +325,7 @@ translations = {}
 [documents."skill.security-privacy-review"]
 source = "locales/en/.mustflow/skills/security-privacy-review/SKILL.md"
 source_locale = "en"
-revision = 16
+revision = 17
 translations = {}
 
 [documents."skill.security-regression-tests"]
@@ -349,7 +349,7 @@ translations = {}
 [documents."skill.test-design-guard"]
 source = "locales/en/.mustflow/skills/test-design-guard/SKILL.md"
 source_locale = "en"
-revision = 1
+revision = 2
 translations = {}
 
 [documents."skill.test-maintenance"]

package/templates/default/locales/en/.mustflow/skills/architecture-deepening-review/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.architecture-deepening-review
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: architecture-deepening-review
@@ -37,6 +37,7 @@ This is a review-first skill. It helps decide whether code needs a deeper module
 ## Use When
 
 - The user asks for architecture review, module boundaries, structural improvement, codebase deepening, maintainability review, or testability improvement.
+- The user asks where a design will break first as it grows, which responsibility boundary is most likely to blur, or whether a module, service, database owner, permission model, deployment unit, or failure boundary is still clear enough.
 - A file, module, service, handler, command, controller, or test suite looks broad enough that the next edit may add another responsibility.
 - Code exposes internal steps to many callers, repeats orchestration, or makes tests hard because policy, I/O, formatting, and dispatch are mixed.
 - A shallow wrapper adds naming without hiding complexity, or a helper has become a pass-through layer around many unrelated concerns.
@@ -57,6 +58,7 @@ This is a review-first skill. It helps decide whether code needs a deeper module
 - Target area, current pain, and the user-facing or maintainer-facing reason to inspect architecture.
 - Relevant source files, call sites, exports, tests, fixtures, schemas, templates, or documentation that show current behavior and ownership.
 - Local patterns for modules, boundaries, naming, errors, dependency direction, and tests.
+- The data owner, write path, failure mode, and expected 3x, 10x, or 100x growth pressure when the review is about a design rather than only a file split.
 - Current changed-file list when the worktree is already dirty.
 - Relevant command-intent contract entries for verification.
 
@@ -88,7 +90,22 @@ This is a review-first skill. It helps decide whether code needs a deeper module
 3. Identify one to three candidate boundaries.
    - Each candidate must name the responsibility it would hide or clarify.
    - Reject candidates that only rename, wrap, or move code without lowering caller complexity or test cost.
-4. Score each candidate from 1 to 9.
+4. Force the design through the ownership and failure questions before scoring.
+   - Name the first likely mixed-responsibility boundary. Common early failures are business rules leaking into controllers, repositories, external adapters, UI components, or framework-specific handlers.
+   - Name the final owner for important data. The owner is the module that protects the invariant, not necessarily the module that reads the value most often.
+   - Separate original state from cache, search index, analytics, summary, AI output, provider response, or other derived state.
+   - Identify every direct write path for high-impact fields such as status, role, permission, balance, quota, plan, entitlement, deleted state, payment state, or ownership.
+   - Ask whether a failure creates a visible failure state or silently creates false success. High-impact paths such as authorization, payment, entitlement, deletion, and destructive administration should fail closed.
+   - Ask whether duplicate requests, retries, webhook redelivery, queue replay, or worker restart can repeat a harmful effect. If yes, require an idempotency, ledger, outbox, or reconciliation boundary before calling the design safe.
+5. Check growth pressure in concrete stages.
+   - At 3x scale, look first for implementation-quality failures: missing indexes, N+1 reads, large responses, synchronous file or image work, repeated external calls, and insufficient connection pools.
+   - At 10x scale, look first for ownership and state failures: write hot spots, queue delay, cache invalidation, server-local files, scattered permission rules, external API rate limits, and deployment units that change for unrelated reasons.
+   - At 100x scale, look first for partitioning and operational failures: data split boundaries, tenant or region hot spots, retry storms, external dependency isolation, long deploy recovery, missing observability, and manual-only recovery paths.
+6. Check scaling direction without forcing premature distribution.
+   - A small team may start with one larger server or a simple server set, but request handlers should not depend on process memory, local uploads, duplicate cron execution, in-transaction external calls, or server-specific job state.
+   - Application servers should be able to become stateless. Databases may start with vertical scaling, but the design should not block read replicas, read models, queue-backed work, or future data partitioning.
+   - Horizontal scaling is only real if any server can handle the same request, workers can safely duplicate or retry work, and database writes do not all converge on an uncontrolled hot spot.
+7. Score each candidate from 1 to 9.
    - User value: whether the structure protects a user-visible or public contract.
    - Maintenance value: whether future changes become smaller or less error-prone.
    - Blast radius: how many callers, files, schemas, templates, or docs would change.
@@ -111,6 +128,8 @@ This is a review-first skill. It helps decide whether code needs a deeper module
 
 - The output contains a ranked architecture candidate list or one scoped structural change.
 - Any chosen change has a named reason tied to lower change cost, lower defect risk, or better testability.
+- Important data has a named owner, write path, original-or-derived classification, and failure behavior when the reviewed design touches durable state.
+- Growth pressure is either checked at 3x, 10x, and 100x or explicitly marked not relevant to the current architecture decision.
 - Behavior changes are excluded or explicitly moved to a separate follow-up.
 - Verification evidence or verification gaps are reported without claiming unrun checks passed.
 
@@ -145,6 +164,10 @@ Use documentation and release checks only when the review or chosen change touch
 
 - Review target and current pain
 - Evidence inspected
+- Data owner, write path, and original-versus-derived state when relevant
+- Failure mode, idempotency, and recovery boundary when relevant
+- 3x, 10x, and 100x growth pressure when relevant
+- Vertical versus horizontal scaling direction when relevant
 - Candidate boundaries and scores
 - Selected next action
 - Narrower skill used or intentionally avoided

package/templates/default/locales/en/.mustflow/skills/security-privacy-review/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.security-privacy-review
 locale: en
 canonical: true
-revision: 16
+revision: 17
 lifecycle: mustflow-owned
 authority: procedure
 name: security-privacy-review
@@ -31,6 +31,7 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
 ## Use When
 
 - A change touches authentication, authorization, sessions, admin behavior, tenant boundaries, personal data, secrets, tokens, credentials, API keys, or private files.
+- A feature adds role, permission, administrator, internal-tool, feature-flag, emergency-access, support, or back-office exceptions that could make the authorization model less explicit over time.
 - A change comes from AI-generated code, vibe-coded output, copied examples, or a broad assistant patch that may have optimized for the happy path without proving abuse boundaries.
 - A change adds or modifies logging, telemetry, diagnostics, receipts, reports, caches, generated state, retention, redaction, export, or external transmission.
 - A change adds or modifies behavior analytics events, event schemas, page views, clicks, searches, impressions, scroll data, experiments, attribution, request traces, or observability data that may include personal data or sensitive context.
@@ -76,6 +77,7 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
 - Changed files, diff summary, and the user goal.
 - Sensitive data, actor, trust boundary, storage, logging, retention, export, or external disclosure surfaces involved.
 - Actor, resource owner, tenant boundary, server-side authorization rule, state-changing route, external network target, dependency source, and agent/tool permission surface involved.
+- Permission model shape when authorization is involved: actor, resource, action, scope, condition, default decision, exception path, emergency-access path, and audit expectation.
 - Read, list, search, update, delete, upload, attach, download, invite, billing, and admin actions affected, including whether the server scopes each action by actor, owner, workspace, organization, team, role, or capability.
 - Cookie, JWT, OAuth, file upload, file download, business-value, database mutation, ORM bulk operation, CI/CD permission, deployment setting, or secret-source surface involved.
 - Cryptographic primitive, password hashing, random-token, secure transport, certificate validation, scanner gate, or security invariant involved.
@@ -126,6 +128,9 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
    - Treat client-provided actor ids, role names, workspace ids, plan names, prices, discounts, entitlement flags, and status values as untrusted input. Derive trusted actor and tenant context from server-side authentication and membership checks.
    - Check list, search, detail, attachment, export, and download paths as carefully as mutation paths. Read access is still data access.
    - Reject mass assignment. Server code should allowlist mutable fields instead of passing raw request bodies into database updates where privileged fields could be set by the client.
+   - Review permission rules as actor, resource, action, scope, and condition rather than role name alone. "Admin can do it" is not enough; the rule should say which administrator can perform which action on which resource and under which tenant or system scope.
+   - Treat growing exceptions such as `isAdmin`, hardcoded user ids, company-email suffixes, internal-tool bypasses, feature-flag bypasses, or support-only shortcuts as authorization-model decay. Replace them with explicit capabilities, scoped roles, or time-limited emergency access.
+   - Emergency access should have a reason, time limit, notification or approval path, and audit log. It should not become a permanent silent superuser branch.
 7. For high-impact admin operations, require a server-side capability or role check, actor attribution, target identity, reason or change note where useful, before/after evidence, and a rollback, preview, or recovery path proportionate to the impact.
    High-impact examples include publish/unpublish, slug change, redirect change, canonical change, robots or sitemap change, filter definition change, advertisement slot or policy change, cache purge, search reindex, ranking refresh, bulk edit, and role or permission change.
 8. For high-risk content claims, require source attribution, jurisdiction or market, effective date, verification date, risk tier, review owner, affected-content lookup, and human approval before publication when the domain is legal, privacy, finance, health, safety, eligibility, pricing, ranking, comparison, or compliance.
@@ -194,6 +199,8 @@ Catch security, privacy, and disclosure risks introduced by ordinary code, docum
 - Public and packaged surfaces do not include unnecessary secrets, personal data, or misleading privacy guarantees.
 - Admin operations, shared-cache behavior, generated-state rebuilds, and audit logs are treated as security-sensitive when they affect private data, permissions, public indexing, traffic, or monetization.
 - Client-side permission displays, file upload or download flows, private asset URLs, and API response fields are treated as disclosure and access-control surfaces.
+- Permission models define actor, resource, action, scope, condition, and default-deny behavior when authorization is involved, or the missing model is reported as a risk.
+- Administrator, support, internal-tool, feature-flag, and emergency-access exceptions are audited, time-bounded, or reported as authorization-model drift.
 - Behavior analytics, observability, and audit logs are separated by durability, retention, attribution, personal-data, and loss-tolerance expectations.
 - Core security, privacy, billing, entitlement, file, search, job, webhook, and administrator events are internally owned or explicitly reported as SaaS-only with the resulting export, retention, and incident-reconstruction risk.
 - Trace context, baggage, request ids, user ids, tenant ids, job ids, and webhook ids are reviewed for sensitive data, external propagation, retention, and backend portability when those surfaces exist.
@@ -240,6 +247,7 @@ Use a narrower configured test, build, or documentation intent when it better pr
 - Data residency, data classification, AI processing location, runtime patch, and hard-limit policy checked when relevant
 - Claim, comparison, affiliate, user-generated content, data-ownership, deletion, anonymization, export, and retention boundaries checked when relevant
 - Authorization, session, token, input, file, network, business-logic, dependency, cryptography, transport, deployment, scanner, and agent-tool boundaries checked
+- Permission exception and emergency-access boundaries checked when relevant
 - Redaction, omission, or wording changes made
 - Related security-regression test need
 - Command intents run

package/templates/default/locales/en/.mustflow/skills/test-design-guard/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.test-design-guard
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: test-design-guard
@@ -31,6 +31,8 @@ Guard the design quality of new tests and new test cases. This skill prevents in
 
 This skill does not force TDD order. It requires evidence that each new or changed test proves an observable behavior contract.
 
+Good tests prove that important assumptions fail loudly. They should protect the risky behavior, boundary, state, permission, cost, or integration condition that would matter in production rather than only proving that the happy path can be demonstrated once.
+
 <!-- mustflow-section: use-when -->
 ## Use When
 
@@ -54,6 +56,7 @@ This skill does not force TDD order. It requires evidence that each new or chang
 - Behavior contract source: user request, issue, bug report, schema, command contract, public docs, fixture, template, or current behavior.
 - Existing tests, fixtures, and helpers near the behavior.
 - Intended test objective and changed files.
+- Risk list for the changed behavior, including money, permissions, deletion, external calls, AI cost, queues, files, data ownership, retries, timeouts, partial failure, or concurrency when those risks exist.
 - Baseline status when using a failing test as evidence.
 - Relevant command-intent contract entries.
 
@@ -78,6 +81,7 @@ This skill does not force TDD order. It requires evidence that each new or chang
 
 1. Confirm the contract and coverage.
    - Name the observable behavior being protected.
+   - Name the production risk the test is supposed to catch. If no risk can be named, prefer reusing existing coverage or reporting the idea as speculative.
    - Reuse or strengthen existing tests when they already cover the behavior.
    - Treat uncovered ideas without a contract source as suggestions, not tests.
 2. Select the smallest useful test shape.
@@ -98,6 +102,8 @@ This skill does not force TDD order. It requires evidence that each new or chang
 5. Check assertion quality.
    - Assert at least one observable result: return value, exit code, stdout or stderr, state change, file output, emitted effect, schema result, error shape, or user-visible contract.
    - Mock interaction assertions may support a test, but they must not be the only evidence of behavior unless the mock interaction itself is the public contract.
+   - For high-risk boundaries, prefer assertions over final state, stored records, rejected access, idempotency outcome, usage record, emitted event, or durable failure status rather than only asserting that a mocked collaborator was called.
+   - Treat tests that mock every database, transaction, authorization, serialization, queue, provider, or filesystem boundary as unit evidence only. Require a nearby integration, contract, fixture, or schema check when the real boundary is the risk.
 6. Choose verification by objective.
    - Use a semantic objective such as `new_behavior`, `bug_regression`, `security_negative`, `stale_test_cleanup`, `contract_sync`, `release_surface`, or `docs_or_template_contract`.
    - Start with the narrowest configured intent that proves the objective.
@@ -110,6 +116,7 @@ This skill does not force TDD order. It requires evidence that each new or chang
 ## Postconditions
 
 - Each new or changed test has a contract source, selected test shape, and observable assertion.
+- Each new or changed test has a named risk, or the final report explains why the change is low-risk or already covered.
 - RED evidence is classified as `behavior_red`, `api_scaffold_red`, `invalid_red`, or `not_applicable`.
 - Speculative edge cases and duplicate coverage are reported instead of silently added.
 - Verification uses configured command intents and reports any missing or skipped coverage.
@@ -142,6 +149,7 @@ Prefer the narrowest configured intent that proves the selected objective. `test
 ## Output Format
 
 - Contract source
+- Production risk being protected
 - Verification objective
 - Selected test shape: `example`, `boundary`, `property`, `mixed`, or `not_applicable`
 - Cases reused

package/templates/default/locales/ko/.mustflow/context/INDEX.md

@@ -3,7 +3,7 @@ mustflow_doc: context.index
 kind: mustflow-context
 locale: ko
 canonical: false
-revision: 1
+revision: 2
 name: context-index
 authority: router
 lifecycle: mustflow-owned
@@ -11,14 +11,14 @@ stability: medium
 review_status: needs_human_review
 ---
 
-# 문맥 색인
+# 컨텍스트 색인
 
-이 파일은 현재 작업에 필요한 프로젝트 문맥 파일을 결정하고 참조하는 안내서입니다.  
-불필요한 정보 유입을 방지하기 위해 기본적으로 모든 문맥 파일을 읽지 않습니다.
+이 파일은 현재 작업에 필요한 프로젝트 컨텍스트 파일을 결정하고 참조하는 안내서입니다.  
+불필요한 정보 유입을 방지하기 위해 기본적으로 모든 컨텍스트 파일을 읽지 않습니다.
 
-## 사용 가능한 문맥
+## 사용 가능한 컨텍스트
 
-| 문맥 | 적용 시나리오 | 경로 |
+| 컨텍스트 | 적용 시나리오 | 경로 |
 | --- | --- | --- |
 | project | 작업이 프로젝트 방향, 범위, 공개 동작, 비목표, 저장소 전반의 규칙에 잠재적으로 영향을 미치는 경우 | `.mustflow/context/PROJECT.md` |
 
@@ -26,14 +26,14 @@ review_status: needs_human_review
 
 | 앵커 | 적용 시나리오 | 경로 |
 | --- | --- | --- |
-| 사용자용 개요 | 공개 프로젝트 개요나 설치 안내가 필요한 경우입니다. 강제 정책이 아닌 일반 문맥으로 참조하십시오. | `README.md` |
-| 로드맵 | 프로젝트 계획, 우선순위, 마일스톤 또는 비목표 문맥이 필요한 경우입니다. 설치된 mustflow 정책이 아닌 계획 문맥으로 참조하십시오. | `ROADMAP.md` |
+| 사용자용 개요 | 공개 프로젝트 개요나 설치 안내가 필요한 경우입니다. 강제 정책이 아닌 일반 컨텍스트로 참조하십시오. | `README.md` |
+| 로드맵 | 프로젝트 계획, 우선순위, 마일스톤 또는 비목표 컨텍스트가 필요한 경우입니다. 설치된 mustflow 정책이 아닌 계획 컨텍스트로 참조하십시오. | `ROADMAP.md` |
 | 시각 디자인 | UI, 시각적 정체성, 디자인 토큰, 레이아웃 또는 접근성을 변경하는 경우 | `DESIGN.md` |
 
 ## 읽기 규칙
 
-- 현재 작업에 해당하는 문맥 파일만 참조하십시오.  
-- 문맥 파일은 더 높은 권한의 출처에 기반한다고 명시되지 않은 경우 참고용 지침으로 간주합니다.  
-- 문맥이 코드, 테스트, 명령 계약, 명시적 사용자 지시와 충돌하는 경우 이를 보고하고 더 높은 권한의 출처를 우선 적용하십시오.  
+- 현재 작업에 해당하는 컨텍스트 파일만 참조하십시오.  
+- 컨텍스트 파일은 더 높은 권한의 출처에 기반한다고 명시되지 않은 경우 참고용 지침으로 간주합니다.  
+- 컨텍스트가 코드, 테스트, 명령 계약, 명시적 사용자 지시와 충돌하는 경우 이를 보고하고 더 높은 권한의 출처를 우선 적용하십시오.  
 - 누락된 프로젝트 목표, 비목표, 디자인 토큰, API 계약, 데이터 규칙을 임의로 추측하거나 생성하지 마십시오.  
-- `DESIGN.md`의 디자인 토큰을 `.mustflow/context/` 내에 중복 기록하지 마십시오.
+- `DESIGN.md`의 디자인 토큰을 `.mustflow/context/` 내에 중복 기록하지 마십시오.

package/templates/default/locales/ko/.mustflow/context/PROJECT.md

@@ -3,7 +3,7 @@ mustflow_doc: context.project
 kind: mustflow-context
 locale: ko
 canonical: false
-revision: 1
+revision: 2
 name: project
 authority: contextual
 lifecycle: user-editable
@@ -15,14 +15,14 @@ source_refs:
   - .mustflow/config/commands.toml
 ---
 
-# 프로젝트 문맥
+# 프로젝트 컨텍스트
 
-이 파일은 코딩 에이전트를 위한 프로젝트별 문맥을 정의합니다.  
+이 파일은 코딩 에이전트를 위한 프로젝트별 컨텍스트를 정의합니다.  
 알 수 없는 항목은 비워 두시고, 내용을 임의로 추측하여 작성하지 마십시오.
 
 ## 권한 경계
 
-- 이 파일에는 근거가 있는 문맥, 알 수 없는 사항, 충돌 내용을 기록할 수 있습니다.  
+- 이 파일에는 근거가 있는 컨텍스트, 알 수 없는 사항, 충돌 내용을 기록할 수 있습니다.  
 - 이 파일은 명령 실행 권한을 부여하거나, 파일 수정 금지 규칙을 정의하거나,  
   `AGENTS.md` 또는 `.mustflow/config/*.toml`을 재정의하거나, 현재 근거가 없는  
   기능을 약속해서는 안 됩니다.  
@@ -62,5 +62,5 @@ source_refs:
 
 ## 오래된 내용 확인
 
-- 이 파일이 현재 코드, 테스트, 명령 계약, 명시적 사용자 지시와 충돌하는 경우, 이를 오래된 문맥으로 간주하고 충돌 내용을 보고해 주십시오.  
-- 프로젝트 방향, 비목표, 저장소 전반의 규칙이 실제로 변경된 경우에만 이 파일을 수정해 주십시오.
+- 이 파일이 현재 코드, 테스트, 명령 계약, 명시적 사용자 지시와 충돌하는 경우, 이를 오래된 컨텍스트로 간주하고 충돌 내용을 보고해 주십시오.  
+- 프로젝트 방향, 비목표, 저장소 전반의 규칙이 실제로 변경된 경우에만 이 파일을 수정해 주십시오.