mustflow 2.30.0 → 2.31.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mustflow",
-  "version": "2.30.0",
+  "version": "2.31.0",
   "description": "Agent workflow documents and CLI for mustflow repository roots.",
   "type": "module",
   "license": "MIT-0",

package/templates/default/i18n.toml

@@ -62,7 +62,7 @@ translations = {}
 [documents."skills.index"]
 source = "locales/en/.mustflow/skills/INDEX.md"
 source_locale = "en"
-revision = 95
+revision = 99
 translations = {}
 
 [documents."skill.adapter-boundary"]
@@ -125,6 +125,18 @@ source_locale = "en"
 revision = 1
 translations = {}
 
+[documents."skill.sqlite-code-change"]
+source = "locales/en/.mustflow/skills/sqlite-code-change/SKILL.md"
+source_locale = "en"
+revision = 1
+translations = {}
+
+[documents."skill.postgresql-code-change"]
+source = "locales/en/.mustflow/skills/postgresql-code-change/SKILL.md"
+source_locale = "en"
+revision = 1
+translations = {}
+
 [documents."skill.dependency-injection"]
 source = "locales/en/.mustflow/skills/dependency-injection/SKILL.md"
 source_locale = "en"
@@ -457,7 +469,7 @@ translations = {}
 [documents."skill.performance-budget-check"]
 source = "locales/en/.mustflow/skills/performance-budget-check/SKILL.md"
 source_locale = "en"
-revision = 15
+revision = 19
 translations = {}
 
 [documents."skill.pattern-scout"]

package/templates/default/locales/en/.mustflow/skills/INDEX.md

@@ -2,7 +2,7 @@
 mustflow_doc: skills.index
 locale: en
 canonical: true
-revision: 95
+revision: 99
 authority: router
 lifecycle: mustflow-owned
 ---
@@ -139,7 +139,7 @@ routes. Event routes stay inactive until their event occurs.
 | Elysia routes, schemas, plugins, decorators, derives, guards, auth, error handling, OpenAPI output, Eden clients, or Bun server behavior are created or changed | `.mustflow/skills/elysia-code-change/SKILL.md` | Server entry, route modules, schemas, plugins, auth, error handling, OpenAPI or Eden surface, changed files, and command contract entries | Elysia routes, schemas, plugins, generated clients, tests, and docs examples | schema/type drift, context inference loss, auth gap, inconsistent error envelope, or stale OpenAPI/Eden output | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `mustflow_check` | Schema, validation, type inference, auth, error, and client contract checked, verification, and remaining Elysia risk |
 | Source anchors are added, revised, reviewed, or used to mark a module boundary | `.mustflow/skills/source-anchor-authoring/SKILL.md` | Target files, anchor reason, nearby anchors, source-anchor policy, and validation surface | Source anchors and directly related workflow docs or comments | comment bloat, authority drift, false verification claims, or hidden module pressure | `mustflow_check`, `docs_validate_fast` | Anchor placement decision, field choices, module-boundary handoff, and verification |
 | Changed files need risk classification and verification selection | `.mustflow/skills/diff-risk-review/SKILL.md` | Changed-file list, diff summary, and task goal | Changed surfaces and verification report | under- or over-verification | `changes_status`, `changes_diff_summary`, `test`, `test_related`, `test_audit`, `lint`, `build`, `docs_validate`, `mustflow_check` | Risk level, verification choice, rollback notes |
-| CLI execution duration, build time, bundle size, test scheduling logic, process spawning, or CLI performance claims are planned, edited, or reported | `.mustflow/skills/performance-budget-check/SKILL.md` | Performance surface, budget source, measurement method, and baseline metrics | Budget checks, CLI duration, bundle weight, scheduling optimization notes, measurements, and tests | invented budgets, stale measurements, child-process bottlenecks, or unverified speed claims | `changes_status`, `changes_diff_summary`, `build`, `test_related`, `docs_validate_fast`, `test_release`, `mustflow_check` | Performance surface, budget source, measurements, execution duration, bundle size, and remaining risks |
+| Runtime performance, hot paths, user-perceived latency, p95/p99 tail latency, throughput, infrastructure cost, memory, GC pressure, CPU cache locality, allocation churn, bundle size, payload size, media loading, build time, filesystem scanning, process spawning, IPC/RPC/DB/API fan-out, N+1 work, repeated filtering/sorting/parsing/serialization, caching, pagination, queues, virtualization, backpressure, or performance claims are planned, edited, reviewed, or reported | `.mustflow/skills/performance-budget-check/SKILL.md` | Performance surface, hot-path shape, input scale, measurement method, baseline and result when available, correctness boundaries, isolation surface, and command contract entries | Data access, lookup indexes, grouping, projection, batching, scheduling, rendering, cache boundaries, queues, concurrency limits, cancellation, measurements, docs, tests, and directly synchronized templates | invented budgets, stale measurements, hidden O(n²), misleading Big-O or data-structure claims, N+1 queries or RPC, unbounded materialization, repeated serialization, object churn, GC pressure, broad rerender, cache stampede, key explosion, queue backlog, pool exhaustion, stale async result, or speed-over-correctness tradeoff | `changes_status`, `changes_diff_summary`, `build`, `test_related`, `docs_validate_fast`, `test_release`, `mustflow_check` | Hot path, ROI priority, cost multiplier, measurement or complexity evidence, semantic preservation, optimization applied, verification, and remaining performance risk |
 | New feature, ambiguous or complex design request, pre-implementation design gate, module, folder layout, architecture, scaffold, refactor, routing, data model, frontend/backend/database/infrastructure choice, database engine choice, managed database extension choice, auth identity ownership, public URL contract, data residency policy, runtime patchability, runtime portability, global-ready locale/country/currency/timezone/money model, server-side authorization boundary, file upload or storage strategy, API response contract, content-heavy product, semantic content blocks, filter URL policy, admin operation model, cache strategy, content lifecycle, asset strategy, claim or fact registry, content graph, source collection flow, user-state layer, core/application/delivery/infra boundary, framework-magic boundary, core versus auxiliary path boundary, operational versus analytics boundary, HTTP-to-worker boundary, job or outbox model, backup/restore assumption, vendor or platform exit path, external-service truth ownership, search/queue/log/analytics portability, operational reproducibility, observability identifier flow, deployment-state portability, CI/CD dashboard dependency, ecosystem or maintainer-risk placement, multi-server state boundary, vertical-to-horizontal scaling boundary, AI usage cost boundary, AI gateway hard-limit boundary, pricing-growth boundary, failure-isolation boundary, or external service integration may require hidden structure decisions before coding | `.mustflow/skills/structure-discovery-gate/SKILL.md` | User request, intended capability, design gate classification, restated requirement, success criteria, non-goals, compatibility boundaries, hidden assumptions, named technologies or services, future content/API/rendering/data assumptions, database operating-shape assumptions, managed database feature assumptions, identity and provider-id assumptions, public URL assumptions, data location assumptions, runtime patch and portability assumptions, delivery/application/core/infra assumptions, global data assumptions, authorization assumptions, file-storage assumptions, source/provenance assumptions, lifecycle/asset/claim assumptions, user-state assumptions, admin/cache assumptions, core path and auxiliary path assumptions, async work assumptions, restore assumptions, vendor exit and replacement assumptions, external-service source-of-truth assumptions, search/queue/log/analytics reconstruction assumptions, operating-state reproduction assumptions, observability identifier assumptions, CI/CD reproducibility assumptions, dependency ecosystem and maintainer assumptions, pricing value/cost unit assumptions, failure-policy assumptions, AI gateway or cost assumptions, and relevant local patterns | Questions, assumptions, proposed file boundaries, and the smallest resulting implementation | brittle structure, vendor-name leakage, migration debt, lock-in debt, provider-id leakage, raw storage URL leakage, weak data location proof, unpatchable runtime, runtime-specific core logic, framework business-rule coupling, SaaS-only core state, weak search or queue reconstruction, weak global data model, weak server authorization, process-memory state leak, untracked AI cost, provider-budget-only AI protection, value/cost pricing mismatch, hidden dashboard deployment state, fragile single-maintainer core dependency, hidden operating state, broken traceability, file/storage drift, screen-shaped API coupling, core-path coupling, retry or worker coupling, unbounded failure radius, over-questioning, or speculative abstraction | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Design gate classification, restated requirement, success criteria, blocking questions, recommended defaults, assumptions, proposed files and responsibilities, upfront versus deferred structure decisions, borrowed service versus owned contract boundary, dependency direction, database, identity, public URL, data residency, runtime patchability and portability, global data, authorization, file-storage, API, vendor exit, external-service truth ownership, search/queue/log/analytics portability, operational reproducibility, CI/CD reproducibility, dependency risk, observability identity flow, pricing value/cost boundary, AI gateway boundary, core/application/delivery/infra boundaries, core and auxiliary boundaries, async work boundary, local pattern, verification, and remaining structure risk |
 
 ### Tests and Regression
@@ -181,6 +181,8 @@ routes. Event routes stay inactive until their event occurs.
 | --- | --- | --- | --- | --- | --- | --- |
 | Database schema, database engine choice, managed database extension or provider feature, SQLite or PostgreSQL suitability, query, transaction, ORM model, repository/store, index, cache-backed read model, read/write model, content metadata, content blocks, content graph, lifecycle states, versioned records, ledgers, job tables, outbox events, inbox events, idempotency records, processed webhook records, external API call records, provider intent records, manual recovery records, taxonomy, filter URL policies, SEO landing records, claim or fact registries, comparison methodologies, affiliate links, source provenance, verification state, behavior analytics events, core event stores, search document metadata, queue recovery metadata, semantic export/import data, provider id mappings, app-owned identity records, public URL records, data residency records, AI budget or policy records, external-service truth ownership, operational versus analytics data boundaries, cache-as-store decisions, API response projections, public identifiers, data ownership boundaries, admin audit logs, cache invalidation data, user activity state, aggregate cache, hybrid file/database storage, file metadata records, data retention, pagination, concurrency, idempotency, audit log, or persistence boundary is introduced, changed, reviewed, or reported | `.mustflow/skills/database-change-safety/SKILL.md` | Data role, database operating model, managed database dependency model, event role, affected tables or stores, storage split, identity and provider-id mapping model, public URL and file-object model, data location model, AI budget and feature-policy model, block/graph/lifecycle/version/ledger/job/outbox/inbox/webhook/provider-call/taxonomy/filter/claim/source/admin/cache/user-state model, export/import and provider-id mapping model, external-service truth model, search/queue/log/analytics data model, operational versus analytics boundary, API projection boundary, file metadata and object-storage boundary, public id rule, read/write path, transaction boundary, migration or rollback expectations, local DB or ORM patterns, changed files, and command contract entries | Schema, migrations, repositories, stores, queries, transactions, indexes, read models, ledgers, job records, outbox records, inbox records, processed webhook records, external call records, provider intent records, manual recovery records, content metadata, block records, claim records, source records, comparison records, affiliate records, behavior event records, core event records, search source records, projection records, export/import records, provider mapping records, app identity records, public URL records, data residency records, AI budget or feature-policy records, admin audit records, file metadata records, cache records, user-state records, fixtures, tests, docs, and directly synchronized templates | data loss, incomplete export, provider-id lock-in, provider-auth-function lock-in, raw storage URL lock-in, unprovable data location, SaaS-only core fact, stale cache, authorization leak, transaction bug, duplicate side effect, unknown provider outcome, retry drift, missing manual replay record, slow query, N+1 query growth, write-contention blind spot, operational DB reporting overload, file/database drift, provenance drift, search or queue reconstruction gap, aggregate drift, API/DB coupling, cache-invalidation drift, provider-budget-only AI enforcement, or unverified migration claim | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | Data role, database operating model, source-of-truth split, managed database dependency, app-owned identity, public URL, data residency, AI budget and policy records, schema/query/transaction review, delete lifecycle, versioning, ledger, job/outbox/inbox/webhook/provider-call/manual-recovery model, export/import and provider-id mapping model, external-service truth model, search/queue/log/analytics ownership, read/write model, behavior/audit event boundary, API projection boundary, file metadata boundary, block/graph/lifecycle/taxonomy/filter/claim/source/admin/cache/user-state checks, migration and rollback status, index/performance notes, security/retention checks, tests, verification, and remaining database risk |
 | Database migration files, schema migration history, ORM schema migrations, generated clients, schema dumps, SQL snapshots, backfills, rolling deploy compatibility, expand-and-contract changes, destructive database changes, migration rollback claims, or production database migration procedures are created, changed, reviewed, or reported | `.mustflow/skills/database-migration-change/SKILL.md` | Source schema, target schema, migration files, migration history, generated clients, schema dumps, SQL snapshots, affected queries, deployment shape, database engine, table size or lock assumptions, backfill plan, rollback type, validation query, and command contract entries | Migration files, ORM schemas, generated clients, schema dumps, SQL snapshots, backfill code, validation checks, seeds, fixtures, compatibility code, docs, tests, and directly synchronized examples | data loss, drop-plus-add rename, old/new app incompatibility, unsafe rolling deploy, unbounded backfill, production lock, generated-client drift, migration-history drift, false rollback claim, ORM autogenerate mistake, or destructive contract mixed with expand phase | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Migration phase, old/new schema compatibility, backfill and validation plan, rollback classification, ORM/generated/schema dump surfaces, dependent surfaces, verification, and remaining database-migration risk |
+| SQLite-specific schema, query, transaction, migration, indexing, extension, WAL, local-file persistence, embedded database, mobile database, browser OPFS/WASM SQLite, cache index, or SQLite runtime behavior is created, changed, reviewed, or reported | `.mustflow/skills/sqlite-code-change/SKILL.md` | SQLite role, runtime and binding, file ownership, storage medium, concurrency shape, schema/type rules, query/index evidence, migration and recovery needs, changed files, and command contract entries | SQLite schema, queries, connection setup, transactions, pragmas, indexes, migrations, fixtures, tests, docs, and directly synchronized templates | wrong runtime assumption, file-lock surprise, WAL overclaim, network filesystem risk, disabled foreign keys, weak type constraints, unsafe raw SQL, query-plan overclaim, sidecar-file data loss, failed migration rebuild, or unverified backup/restore | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | SQLite runtime, storage, WAL/concurrency, schema/type/constraint, query/index, migration, backup/restore, verification, and remaining SQLite risk |
+| PostgreSQL-specific schema, query, transaction, migration, indexing, extension, role, row-level security, connection pooling, replication, backup, restore, managed Postgres, or Postgres runtime behavior is created, changed, reviewed, or reported | `.mustflow/skills/postgresql-code-change/SKILL.md` | PostgreSQL role, version, provider, extension inventory, topology, pooler, schema/type rules, query-plan evidence, transaction/retry rules, migration and recovery needs, changed files, and command contract entries | PostgreSQL schema, queries, migrations, generated SQL, connection setup, pool settings, roles, RLS policies, extensions, tests, docs, and directly synchronized templates | version drift, provider constraint miss, connection storm, lock or rewrite surprise, unsafe online DDL claim, bad pooler assumption, RLS bypass, search-path risk, extension drift, stale replica read, query-plan overclaim, or unverified restore | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | PostgreSQL version/topology, pooling, lock/transaction, schema/type/RLS/role, query/index/statistics, backup/restore, verification, and remaining PostgreSQL risk |
 | Dependency versions, lockfiles, package-manager metadata, workspace constraints, runtime engines, peer dependencies, optional dependencies, security advisory fixes, generated dependency output, framework plugins, CI actions, Docker base images, package manager behavior, or toolchain versions are upgraded, downgraded, pinned, widened, regenerated, reviewed, or reported | `.mustflow/skills/dependency-upgrade-review/SKILL.md` | Dependency name, old and new versions or ranges, direct or transitive path, ecosystem and package manager, declaration files, lockfiles, runtime or toolchain files, advisory or release-note evidence, generated outputs, callers, docs, package output, Docker or CI surfaces, and command contract entries | Package declarations, lockfiles, generated outputs, compatibility code, tests, docs, package metadata, Docker or CI files, and directly synchronized examples | lockfile churn, hidden transitive replacement, peer or engine break, module-format drift, native or optional package break, framework or generator output drift, unsafe broad security update, weakened tests, Docker or CI runtime drift, or unreviewed supply-chain change | `changes_status`, `changes_diff_summary`, `lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Upgrade reason, ecosystem surface, direct and transitive graph changes, compatibility classification, runtime/peer/engine/module/feature/platform/generated-output risks, synchronized surfaces, verification, and remaining dependency-upgrade risk |
 | Dependency, package, runtime, framework, tool, command, plugin, service, platform capability, supported-version policy, security patch path, ecosystem maturity claim, maintainer-risk assumption, runtime portability claim, edge or serverless compatibility claim, critical-path library choice, package script, lifecycle hook, binary download, lockfile, audit result, or supply-chain-sensitive dependency surface is assumed, added, removed, imported, invoked, installed, audited, or documented | `.mustflow/skills/dependency-reality-check/SKILL.md` | Assumed dependency or capability, declaration files, version or feature expectation, role criticality, supported-version or end-of-life evidence, patchability expectation, runtime compatibility boundary, maintainer and ecosystem evidence when available, lockfile entry, package script or lifecycle hook, audit or provenance evidence, and relevant command intents | Package metadata, lockfiles, imports, scripts, command contracts, docs, tests, runtime policy notes, portability notes, and reports | unavailable dependency, hallucinated or lookalike package, fragile single-maintainer core dependency, experimental technology in a survival path, unsupported runtime, unclear security patch path, runtime-specific API leakage into core logic, stale version claim, lifecycle script risk, audit suppression, lockfile drift, or install guidance mismatch | `changes_status`, `changes_diff_summary`, `build`, `test_release`, `mustflow_check` | Dependency checked, ecosystem and maintainer-risk boundary reviewed, supported-version, patchability, and runtime-portability boundary reviewed, supply-chain surface reviewed, declarations synchronized, verification, and remaining dependency risk |
 | Generated or edited code, configuration, CI workflows, package metadata, install instructions, examples, Docker images, framework setup, runtime declarations, toolchain declarations, or migration-sensitive snippets introduce explicit external version references, action refs, package ranges, runtime versions, framework majors, Docker image tags, or scaffold commands that may be stale | `.mustflow/skills/version-freshness-check/SKILL.md` | Versioned reference, owning files, repository version policy, approved freshness source, compatibility context, migration risk, and command contract entries | Package metadata, lockfiles, CI workflows, Dockerfiles, runtime files, framework config, docs, examples, templates, tests, and version-decision reports | stale default version, false latest claim, accidental major migration, repository policy mismatch, unsupported generated example, floating-tag drift, or unverified security/support claim | `changes_status`, `changes_diff_summary`, `build`, `test_related`, `docs_validate_fast`, `test_release`, `mustflow_check` | Versioned surfaces checked, repository policy and freshness source, selected version track, compatibility classification, approval need, synchronized surfaces, verification, and remaining version-freshness risk |

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

@@ -2,11 +2,11 @@
 mustflow_doc: skill.performance-budget-check
 locale: en
 canonical: true
-revision: 15
+revision: 19
 lifecycle: mustflow-owned
 authority: procedure
 name: performance-budget-check
-description: Apply this skill when CLI execution duration, build time, bundle size, test execution scheduler bottlenecks, filesystem scanning latency, process spawning overhead, or dependency size budgets are planned, edited, or reported.
+description: Apply this skill when runtime performance, hot paths, user-perceived latency, p95/p99 tail latency, throughput, infrastructure cost, memory, GC pressure, CPU cache locality, allocation churn, bundle size, payload size, media loading, build time, filesystem scanning, process spawning, IPC/RPC/DB/API fan-out, N+1 work, repeated filtering/sorting/parsing/serialization, caching, pagination, queues, virtualization, backpressure, or performance claims are planned, edited, reviewed, or reported.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -22,99 +22,165 @@ metadata:
     - mustflow_check
 ---
 
-# Performance Budget Check (CLI Core Condensed)
+# Performance Budget Check
 
 <!-- mustflow-section: purpose -->
 ## Purpose
 
-Keep CLI performance claims and execution speed tied to reproducible, measured thresholds instead of qualitative statements.
+Keep performance work focused on the places where cost multiplies: item count, request count, service fan-out, retry count, bytes transferred, bytes copied, objects allocated, rendered nodes, database round trips, filesystem walks, IPC calls, cache misses, branch misses, lock waits, queue backlog, and connection-pool waits.
+
+Prefer removing unnecessary work over making unnecessary work slightly faster. A performance change should preserve semantics, name the hot path, and report whether it is measured, inferred from complexity, or still unverified. Do not treat Big-O labels, "hash map", "indexed query", "cache", "queue", or "autoscaling" as proof that a path is fast enough; constant factors, memory layout, runtime dispatch, allocation, locks, external round trips, and shared resource bottlenecks often dominate.
 
 <!-- mustflow-section: use-when -->
 ## Use When
 
-- The task changes or reports CLI build time, bundle size, test scheduling logic, database cache initialization, or command execution duration.
-- A change adds heavy dependencies, recursive file-system scanning, command fan-out, or repeated child process spawning (e.g., test harness overhead).
-- A test optimization changes process isolation, in-process CLI execution, shared build outputs, or scheduler grouping.
-- A report claims that a CLI path is "faster", "optimized", "efficient", or "lightweight".
+- A task changes or reports latency, p95 or p99 tail latency, throughput, infrastructure cost, memory use, GC pressure, CPU cache locality, allocation churn, build time, bundle size, payload size, media loading, CLI duration, test scheduling, cache initialization, filesystem scanning, process spawning, or command execution duration.
+- Code introduces or reviews repeated external access such as DB queries, repository calls, HTTP/RPC calls, Redis calls, S3/object storage calls, IPC commands, filesystem `stat` or scan calls, or child processes.
+- Code filters, sorts, groups, joins, parses, serializes, clones, formats, normalizes, validates, allocates objects, builds DTOs, opens clients or sessions, renders UI lists, or computes projections inside loops or render paths.
+- A change adds caching, memoization, precomputation, derived stores, selectors, virtualized lists, batching, queues, concurrency limits, cancellation, backpressure, debounce, throttle, workers, background jobs, CDN or HTTP caching assumptions, payload reduction, or media optimization for performance reasons.
+- Code uses async work, goroutines, futures, workers, task queues, streams, regexes, date parsing, string construction, exception handling, or logging in a path whose input or traffic can grow.
+- A report claims a path is faster, optimized, efficient, lightweight, responsive, scalable, low-memory, low-overhead, or safe for large input.
 
 <!-- mustflow-section: do-not-use-when -->
 ## Do Not Use When
 
-- The task only changes wording, translations, or docs with no runtime execution impact.
-- The numbers represent local mocks or test-only fixtures with no operational baseline meaning.
+- The task only changes wording, translations, or docs with no runtime, package, measurement, or performance claim.
+- The number is only a local fixture value with no performance or public meaning.
+- The change is purely database-engine-specific performance work; use the matching engine skill first, then this skill only for cross-cutting measurement, hot-path, UI, cache, or I/O boundaries.
+- The proposed optimization changes product semantics, authorization, durability, consistency, or user-visible ordering; use the relevant behavior, data, migration, or security skill first.
 
 <!-- mustflow-section: required-inputs -->
 ## Required Inputs
 
-- **Performance Surface**: Target command path, build step, or test scheduling token model.
-- **Measurement Method**: The exact execution tool (e.g., in-process execution vs. process spawning).
-- **Baseline**: Current execution duration or bundle size before changes.
-- **Measured Result**: Post-change metrics under identical sandbox constraints.
-- **Isolation Surface**: Shared state touched by the optimization, such as `process.cwd()`, `process.env`, module cache, build output directories, database files, or child processes.
+- Performance surface: request path, command path, render path, build step, batch job, queue, cache, database path, filesystem path, IPC/RPC boundary, or test scheduler.
+- Hot-path shape: expected call frequency, input size, growth direction, nested loops, external round trips, payload size, rendered node count, allocation rate, data layout, branch predictability, lock or pool contention, queue depth, and whether the path runs during user input or startup.
+- Time breakdown evidence: user-visible moment, wall-time split across browser, network, application CPU, DB, cache, external API, queue, filesystem, IPC, serialization, compression, logging, and render work, plus CPU time versus wait time when available.
+- Measurement method or evidence: configured command intent, profiler output, query count, runtime log, trace span, resource metric, benchmark, complexity analysis, or reason the metric is unavailable.
+- Baseline and post-change result when measurable under comparable constraints, including whether the evidence reflects average, p95, p99, cold start, warm cache, realistic data size, or local-only behavior.
+- Saturation evidence: utilization, backlog or queue depth, pool wait, lock wait, retry or error rate, tenant or data skew, and good-period versus bad-period comparison when available.
+- Optimization goal: user-perceived speed, server cost reduction, tail-latency stability, failure isolation, memory headroom, or developer-loop speed.
+- Correctness boundaries: ordering, duplicates, idempotency, partial failure, cancellation, consistency, cache invalidation, stale data, and rollback behavior.
+- Isolation surface: shared state touched by the optimization, such as `process.cwd()`, `process.env`, module cache, build output directories, database files, caches, stores, workers, timers, or child processes.
+- Relevant command-intent contract entries for build, tests, docs, release checks, and mustflow validation.
 
 <!-- mustflow-section: preconditions -->
 ## Preconditions
 
-- The task matches the Use When criteria and does not match the exclusions.
-- Standard test suite intent (`test_related` or `test_fast`) is configured and functional.
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+- Required inputs are available, or missing inputs can be reported without guessing.
+- If personal data, authorization, tenant isolation, secrets, logs, retention, or audit data is involved, also use `security-privacy-review`.
+- If database schema, query, index, migration, or transaction behavior changes, also use `database-change-safety`, `database-migration-change`, or the matching database engine skill.
+- If UI rendering, layout, accessibility, or user-facing interaction changes, also use `ui-quality-gate`.
 
 <!-- mustflow-section: allowed-edits -->
 ## Allowed Edits
 
-- Tighten budget limits, add performance test fixtures, optimize scheduling tokens, or use in-process helpers instead of spawning heavy child processes.
-- Replace fuzzy adjectives ("fast", "responsive") with exact duration (ms/sec) or file weight (KB/MB).
+- Optimize data access, indexing, grouping, projection, batching, scheduling, rendering, cache boundaries, concurrency limits, cancellation, and measurement code tied to the task.
+- Add or tighten performance-oriented tests, fixtures, budgets, metrics, docs, and reports when repository evidence supports them.
+- Replace fuzzy adjectives with measured values or explicitly label the claim as complexity-only or unverified.
+- Do not add speculative caches, memoization, workers, batching, virtualized UI, or concurrency fan-out when the hot path and invalidation boundary are unknown.
+- Do not trade correctness, durability, authorization, privacy, ordering, partial-failure behavior, or user trust for speed without explicit product acceptance.
 
 <!-- mustflow-section: procedure -->
 ## Procedure
 
-1. Identify if the performance change affects:
-   - **Build Time**: bundle duration, generated file size, and rebuild behavior.
-   - **Test Scheduling**: scheduler token capacity, wave grouping, in-process execution, and subprocess fan-out.
-   - **CLI Boot Time**: Node process startup, module import cost, and command dispatch latency.
-2. Run the narrowest matching oneshot intent (e.g., `build` or `test_related`) to establish a deterministic local baseline.
-3. Before converting process-spawned tests to in-process execution, inventory global process state:
-   - current working directory reads or writes;
-   - environment variable mutation;
-   - `process.argv`, `process.exitCode`, signal handlers, module cache, timers, and singleton caches;
-   - shared filesystem outputs such as `dist/`, local indexes, or temporary database paths.
-4. Do not use `process.chdir()` as an in-process test isolation strategy when multiple tests can run in the same Node test runner. Use a context-aware current-directory adapter, serialize the affected tests, or keep those tests in separate processes.
-5. Treat build output directories that are deleted and recreated during build as exclusive resources. Lock the build/test runner before rebuilding or reading that output so an overlapping run cannot remove files from a live test process.
-6. Before measuring, check for an already-running build, profile, or test process for the same repository. Stop, wait, or report the overlap before recording timings.
-7. Eliminate process spawning loops. Where possible, invoke core logic directly in-process instead of using heavy CLI shell executions, but only after the isolation surface is controlled.
-8. Measure and document the metrics exactly:
-   - Command duration (ms or seconds).
-   - Bundle size (KB or MB) if `dist/` is affected.
-9. Identify any potential platform-specific latency differences (Windows PowerShell vs. Unix sh).
-10. Verify changes using `mustflow_check` and the narrowest test suite intent.
+1. Name the hot path and cost multiplier. Ask how many times the line runs after multiplying by requests, items, services, retries, renders, files, rows, shards, or queued jobs.
+   - Turn "slow" into a numeric budget before choosing a fix. Name the user-visible moment, such as first content, click response, save completion, scroll/input responsiveness, background delivery, batch completion, or developer command duration. State the current and target p50, p95, p99, throughput, memory, payload, or cost when evidence exists.
+   - Decompose elapsed time before touching code. Split request, render, command, or job wall time across browser, network, server routing, authorization, application CPU, DB, cache, external APIs, queue wait, filesystem, IPC, serialization, compression, logging, response download, and render. Distinguish CPU time from wait time; high wall time with low CPU means the path is waiting.
+   - Find queueing and saturation, not just high utilization. Check utilization, backlog, queue depth, pool waits, lock waits, retry or error rate, and p95/p99 latency together. Compare good periods to bad periods, affected tenants or data sizes, specific workers or replicas, and cold versus warm cache before declaring the bottleneck.
+2. Rank the likely return on effort before choosing a technique. In typical web or service paths, first check DB/API round-trip count, slow query plans, repeated reads that could be safely cached, work that does not need to block the response, static or media delivery, response payload shape, and then CPU or allocation micro-optimizations. Escalate algorithmic or runtime work early only when the measured hot path is CPU-heavy, data-processing-heavy, render-loop-heavy, or clearly quadratic.
+3. Do not stop at asymptotic complexity. For `O(N)`, check sequential versus pointer-chasing access, working-set size, branch predictability, per-item allocation, string or Unicode work, runtime dispatch, logging, locks, and external round trips. For `O(log N)`, check node locality, comparator cost, key size, pointer jumps, and branch behavior. For `O(1)` maps or caches, check hash cost, key equality, load factor, resize or rehash spikes, collision behavior, key mutability, cache miss path, and hot-key contention.
+4. Classify the performance surface:
+   - CPU and algorithm: nested loops, repeated lookup, sorting, parsing, formatting, validation, scoring, diffing, search, regex, JSON work, compression, crypto, image processing, context switching, event-loop blocking, runtime dispatch, or CPU throttling.
+   - I/O and external boundaries: DB, filesystem, HTTP/RPC, Redis/cache, object storage, IPC, child processes, provider SDKs, DNS, TLS, retransmits, cross-region calls, or load-balancer hot spots.
+   - Memory and allocation: object churn, deep clone, DTO conversion, large object graphs, byte/string copies, serialization, boxing, pointer chasing, cache locality, and GC pressure.
+   - UI and delivery: unstable references, broad store invalidation, large lists, layout thrashing, image or icon load, font loading, hydration cost, bundle parse or execute time, payload size, input delay, and main-thread work.
+   - Concurrency and resilience: pool exhaustion, long transactions, locks, retry storms, queue growth, backpressure, cancellation, partial failure, and shared-resource bottlenecks that autoscaling cannot remove.
+5. Look for repeated external access first. Loops around repository calls, ORM lazy fields, DB queries, network calls, Redis gets, object storage calls, filesystem stats, IPC commands, or child processes are usually higher risk than local arithmetic.
+6. Remove N+1 and fan-out before micro-optimizing. Prefer batch loading, bulk APIs, bounded concurrency, preloading, projection, and one request that returns the data shape the caller actually needs.
+7. Check DB and ORM reality before adding caches. Confirm query count, selected columns, lazy loading, index fit, sort or pagination shape, row estimates, rows examined versus returned, temp sorts or tables, lock waits, transaction duration, replication lag, WAL or checkpoint pressure, and connection-pool waits. Do not use a cache to hide a query shape that should be fixed first. Treat pool size as a safety valve, not a cure for slow queries, long transactions, hot rows, or N+1 access.
+8. Look for hidden quadratic work. Repeated membership checks, `find`, `filter`, `some`, `contains`, `indexOf`, grouping, or join-like scans inside another loop usually need a lookup table, `Set`, `Map`, sorted merge, or database-side join.
+9. Choose data structures by actual cost, not labels. Small collections may be faster as arrays or sorted arrays than maps. Large lookup tables should use compact immutable keys, pre-sized capacity when supported, stable hashing and equality, and a memory layout that does not turn every item into a pointer chase.
+10. Preserve semantics while changing data structures. State whether order, duplicate handling, first versus last winner, tie-breakers, missing records, and stable IDs still match the old behavior.
+11. Bound reads and materialization. Avoid unbounded `SELECT *`, `findAll`, full filesystem scans, full JSON loads, full array materialization, whole response bodies, and API responses without pagination, projection, chunking, or streaming when data can grow.
+12. Reduce payload and media work before tuning rendering internals. Send only needed fields, avoid overfetching, split late or optional data, use HTTP caching or CDN only for cacheable assets or responses, and check image dimensions, formats, lazy loading, and fixed layout dimensions before adding component memoization.
+13. Check sorting and top-k work. Do not sort entire collections when only a top subset is needed. Precompute sort keys when comparison logic parses dates, normalizes strings, computes scores, or reads paths.
+14. Check pagination semantics. Offset pagination can become linearly slower and can duplicate or skip items on changing data. Prefer stable keyset or cursor semantics when the product does not require arbitrary page jumps.
+15. Move repeated pure computation out of loops and renders. Normalize queries once, precompute search blobs or numeric timestamps, reuse regexes and formatters, and avoid repeated schema validation after data crosses a trusted boundary.
+16. Reuse expensive clients and sessions. Do not create HTTP clients, DB clients, ORM clients, SDK clients, regexes, date formatters, connection pools, or thread pools per request, per item, or per render unless the local API explicitly requires that lifecycle.
+17. Control allocation. Avoid deep clone, JSON round-trip cloning, broad object spread, byte/string round trips, large intermediate arrays, repeated DTO layers, per-item closure or promise creation, exception construction in normal flow, and formatter creation in hot paths.
+18. Stream or chunk large data. Files, JSONL, CSV, response bodies, object-storage blobs, and generated artifacts should not be read or decoded all at once when size can grow. Prefer bounded buffers, streaming parsers, and projection before serialization; state parser token or line-size limits when they matter.
+19. Balance async and parallelism. Avoid both accidental sequential waits over independent I/O and unbounded `Promise.all`, goroutine, future, task, or worker fan-out. Use bounded concurrency, connection limits, timeouts, cancellation, and partial-result semantics.
+20. Keep cache and memoization honest. Add caches only when the input key, invalidation rule, maximum size, TTL or version, stale behavior, and memory budget are explicit. Check stampede, key cardinality, negative caching, remote-cache hit cost, hot-key contention, authorization variance, cold-start behavior, shard or resize warmup, and cache outage behavior.
+21. Treat queues as latency shifting, not work removal. Queue only work that does not need to block the user or transaction, and define consumer capacity, backlog limits, retry with jitter, idempotency, ordering, poison-message handling, and what happens when the queue is full.
+   - During incidents, separate mitigation from root fix. Rate limits, temporary TTL extension, disabling nonessential work, lowering worker concurrency, replica routing, batch delay, or graceful degradation can protect the system, but still record the query, lock, retry, payload, hot-key, shard, or queue-design root cause.
+22. Keep derived state disposable. Separate source data, lookup indexes, and UI projections. Projection caches should be rebuildable and should not become a second source of truth.
+23. Keep references stable when rendering. Avoid recreating arrays, objects, context values, store payloads, or item props for unchanged data. Use stable IDs for list keys and virtualize large lists when rendering cost is the bottleneck.
+24. Keep expensive work off the UI thread or async executor when it blocks progress. Move large parsing, search indexing, thumbnail generation, diffing, compression, crypto, or file processing to a worker, blocking pool, backend, or job queue only when the boundary cost is lower than keeping it local.
+25. Batch boundary crossings. IPC, RPC, database, filesystem, and provider calls should cross boundaries in meaningful bulk operations, with per-item results, partial-failure behavior, timeout, cancellation, and bounded concurrency.
+   - If sharding, partitioning, or row/cache key design appears in the fix, choose keys by load and query pattern rather than business neatness. Check hot tenants, hot counters, sequential row keys, fan-out scatter, resharding cost, cache hit-rate loss after movement, and whether coordinators stay off the hot data path.
+26. Add backpressure to producer-consumer paths. Queues, watcher events, progress events, sync events, and refresh jobs need capacity, coalescing, latest-only behavior, rejection, degradation, or bounded consumers when production can outrun consumption.
+27. Handle cancellation and stale async results. Search, refresh, sync, scans, and UI-driven loads need generation tokens or abort signals so old work cannot overwrite newer state.
+28. Review filesystem and watcher paths. Prefer incremental metadata, debounce, event coalescing, and reconciliation over repeated whole-tree scans. Treat watcher events as hints, not truth.
+29. Review pool and lock pressure. Shorten DB transactions, release connections before external work, avoid holding locks around slow I/O, avoid one global lock around a growing map or cache, and measure pool acquisition latency when concurrency grows.
+30. Check retry, timeout, and external dependency behavior. Retries need maximum attempts, exponential backoff, jitter, idempotency, and circuit-breaking or graceful degradation when an external service is slow or unavailable.
+31. Check logging and telemetry overhead. Avoid serializing large payloads or building expensive log strings on successful hot paths. Metrics and logs also need bounded cardinality and sampling on high-frequency paths. Do not remove useful observability to make numbers look better; good traces, query counts, cache hit rates, queue backlog, pool waits, tenant or shard labels, and retry/error signals are part of the performance surface.
+32. Run a language and runtime smell pass when applicable:
+   - TypeScript and JavaScript: repeated `includes` or `find`, unbounded `Promise.all`, `forEach(async ...)`, ORM N+1, object spread clones, JSON deep clone, repeated `new Date`, `console.log(JSON.stringify(...))`, per-request clients, large sync JSON or file work, and CPU work on the event loop.
+   - Go: goroutine per item, missing `context` or timeout, per-call `http.Client`, `io.ReadAll` on growing input, slice growth without capacity, one mutex around a large map, and synchronous logging or formatting in hot loops.
+   - Rust: `.clone()` to silence ownership design, unnecessary `collect`, repeated `Regex::new`, `Arc<Mutex<_>>` as a default, `join_all` over unbounded futures, CPU-bound work on async executors, and missing `with_capacity` for large collections.
+   - Python: list membership in loops, sequential `requests` calls without session reuse, unbounded `asyncio.gather`, full `read()` or `json.load()` on growing files, `deepcopy`, repeated `datetime.strptime`, f-string logging at disabled levels, row-wise pandas loops, and CPU work on the event loop.
+33. Measure when possible. Use the narrowest configured command intent that exercises the path. If measurement is unavailable, report the result as complexity evidence rather than a speed claim. Do not compare local microbenchmarks to production user experience unless data size, cache state, network, concurrency, and tail-latency conditions are comparable.
+34. Treat deploys, restarts, migrations, rebalances, and cache warmups as performance events. A path that is fast only after warm caches, settled JIT, stable replicas, or completed compaction should report cold-start and recovery risk separately from steady-state speed.
+35. Keep large performance architecture changes separate. Watcher refresh, bulk IPC commands, projection caches, virtualized lists, worker offload, queue introduction, cache layers, CDN behavior, sharding, and storage redesigns should be independent changes unless the repository evidence proves they must land together.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
-- All speed or weight claims are backed by measured data or explicitly marked as "unverified local estimate".
-- No hidden process-spawning bottlenecks or N+1 file scan loops are introduced.
-- In-process performance work documents how global process state and shared build outputs are isolated.
+- The hot path, cost multiplier, and affected input scale are explicit.
+- The optimization goal is explicit: user-perceived speed, server cost, p95 or p99 stability, failure isolation, memory headroom, or developer-loop speed.
+- The wall-time breakdown, CPU-versus-wait classification, saturation signal, and resource bottleneck class are explicit when evidence exists.
+- Speed, memory, bundle, payload, query-count, render, CPU locality, allocation, lock, pool, queue, or I/O claims are backed by measurement or labeled as complexity-only.
+- N+1 work, hidden quadratic scans, unbounded materialization, repeated serialization, repeated allocation, client/session churn, broad rendering, and unbounded or accidentally sequential async work are removed or reported.
+- Caches, queues, batching, concurrency, workers, streams, CDN or HTTP caching, media optimization, and projections have invalidation, ordering, duplicate, partial-failure, cancellation, backpressure, capacity, stale-data, and memory behavior defined where relevant.
+- Correctness, security, durability, privacy, and user-visible semantics remain intact or are explicitly reported as tradeoffs.
 
 <!-- mustflow-section: verification -->
 ## Verification
 
-Use configured oneshot command intents:
-- `build` (to check bundle weight/correctness)
-- `test_related` or `test_fast` (to verify execution speed)
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `build`
+- `test_related`
+- `docs_validate_fast`
+- `test_release`
 - `mustflow_check`
 
+Use the narrowest configured test, build, docs, release, or mustflow intent that proves the changed performance surface. Do not infer raw benchmark, profiler, browser, database, package-manager, server, or watcher commands.
+
 <!-- mustflow-section: failure-handling -->
 ## Failure Handling
 
-- If local execution hardware makes metrics non-deterministic, state the sandbox CPU/environment variables explicitly.
-- If timings are distorted by an orphaned or overlapping process, stop and classify the measurement as invalid before taking a new baseline.
-- If correctness conflicts with performance, prioritize correctness, revert the optimization, and report the trade-off.
+- If metrics vary by local hardware or concurrent process load, state the measurement boundary and avoid broad claims.
+- If timings are distorted by an orphaned, overlapping, or stale build/test process, classify the measurement as invalid before taking a new baseline.
+- If the hot path, input scale, or invalidation rule is unknown, prefer a small semantics-preserving cleanup or report the missing evidence instead of adding cache or concurrency complexity.
+- If correctness conflicts with performance, prioritize correctness and report the tradeoff.
+- If configured verification is missing, report the missing command intent instead of inventing a raw command.
 
 <!-- mustflow-section: output-format -->
 ## Output Format
 
-- Performance Surface: [e.g., CLI test-harness in-process runner]
-- Measurement Method: [e.g., bun run test:related]
-- Baseline Metrics: [e.g., 18.2s execution with process spawning]
-- Post-change Metrics: [e.g., 3.8s execution via in-process helper]
-- Sync Details: synchronized CLI helpers and test configuration
-- Remaining Risks: platform-specific process execution drift under heavy IO
+- Performance surface and hot path
+- Cost multiplier and input scale
+- Time breakdown and resource bottleneck class
+- Optimization goal and ROI priority
+- Performance evidence: measured, complexity-only, or unverified
+- Semantics preserved: order, duplicates, IDs, consistency, partial failure, cancellation, and stale result handling
+- Optimization applied or recommended
+- Cache, queue, batching, concurrency, projection, UI, payload, media, memory, runtime, lock, pool, stream, retry, timeout, deployment, sharding, and I/O notes where relevant
+- Command intents run
+- Skipped measurements and reasons
+- Remaining performance risk

package/templates/default/locales/en/.mustflow/skills/postgresql-code-change/SKILL.md

@@ -0,0 +1,157 @@
+---
+mustflow_doc: skill.postgresql-code-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: postgresql-code-change
+description: Apply this skill when PostgreSQL-specific schema, query, transaction, migration, indexing, extension, role, row-level security, connection pooling, replication, backup, restore, managed Postgres, or Postgres runtime behavior is created, changed, reviewed, or reported.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.postgresql-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - test_related
+    - test
+    - lint
+    - build
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# PostgreSQL Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep PostgreSQL changes explicit about server version, operational topology, connection pressure, lock behavior, planner evidence, transaction semantics, role boundaries, extension ownership, and restore reality.
+
+PostgreSQL is not just "SQL with more features." Most production damage comes from unbounded locks, accidental table rewrites, connection storms, search-path surprises, extension drift, false rollback claims, or treating managed-service defaults as application design.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- PostgreSQL schema, queries, indexes, constraints, migrations, generated SQL, transactions, roles, RLS policies, extensions, functions, triggers, views, materialized views, partitions, replication, backups, or restore behavior are introduced, changed, reviewed, or reported.
+- Code uses PostgreSQL through an ORM, query builder, migration tool, driver, connection pool, serverless adapter, PgBouncer, managed Postgres provider, read replica, or extension-backed feature.
+- A task mentions locking, isolation, advisory locks, row locks, deadlocks, serialization retries, `search_path`, RLS, `timestamptz`, JSONB, GIN, GiST, BRIN, full-text search, generated columns, partial indexes, expression indexes, concurrent indexes, partitions, logical replication, PITR, or extension versions.
+- Documentation or final reports claim a PostgreSQL change is online, safe, fast, indexed, scalable, version-compatible, migration-safe, role-safe, or recoverable.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is database-backed but not PostgreSQL-specific; use `database-change-safety`.
+- The task only changes database migrations without PostgreSQL-specific lock, validation, rewrite, generated-output, online-index, or rollout behavior; use `database-migration-change` first.
+- The task only selects or upgrades a Postgres client, ORM, or extension package; use `dependency-reality-check`, `dependency-upgrade-review`, or `version-freshness-check`.
+- The task only changes non-Postgres SQL examples with no project behavior claim.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- PostgreSQL role: primary source of truth, reporting replica, read model, queue store, analytics store, temporary scratch database, or managed-service dependency.
+- Server identity: major and minor version, managed provider constraints, extension inventory and versions, schemas in use, driver, ORM, pooler, and deployment environment.
+- Topology: app instances, worker count, connection pool size, PgBouncer or provider pool mode, read replicas, failover model, backup/PITR expectation, and whether migrations run during rolling deploys.
+- Schema and data rules: constraints, foreign keys, indexes, identity generation, UUID policy, enum or lookup-table choice, JSONB boundaries, timestamp semantics, money or decimal policy, tenant isolation, RLS, and privilege model.
+- Query evidence: affected query paths, representative parameters, row counts or cardinality assumptions when known, plan evidence when available, index usage, sort or join pressure, statistics needs, and read/write frequency.
+- Transaction and retry rules: isolation level, lock expectations, timeout policy, idempotency, external side effects, retryable database failures, and deadlock or serialization handling.
+- Migration and recovery needs: lock or rewrite risk, validation phase, backfill strategy, deploy compatibility, rollback classification, invalid-index cleanup, backup and restore evidence, and dependent services.
+- Relevant command-intent contract entries for tests, builds, docs, release checks, and mustflow validation.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+- If PostgreSQL stores product or customer data, also use `database-change-safety`.
+- If schema or data changes must move from an old shape to a new shape, also use `database-migration-change`.
+- If roles, RLS, tenant isolation, personal data, credentials, audit logs, or retention are involved, also use `security-privacy-review`.
+- If version-specific PostgreSQL features, extensions, managed-provider behavior, or dependency support are asserted, also use `version-freshness-check` or `dependency-reality-check`.
+- If performance, query-time, index, partitioning, or scaling claims are made, also use `performance-budget-check`.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Update PostgreSQL schema, queries, migrations, generated SQL, connection setup, pool settings, roles, RLS policies, extension declarations, tests, docs, and directly synchronized template surfaces tied to the task.
+- Add explicit version, provider, lock, pool, transaction, role, extension, restore, and verification notes when behavior depends on deployment shape.
+- Do not treat this skill as permission to run raw PostgreSQL tools, migration commands, package scripts, admin SQL, live database operations, or provider console actions outside configured command intents.
+- Do not weaken tenant isolation, role separation, durability, backup, or migration safety to make a local test pass.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the PostgreSQL role and topology. Name whether the database is primary truth, reporting replica, job store, analytics store, managed provider surface, or temporary store.
+2. Identify the actual version and provider constraints. Check server major/minor version, official PostgreSQL release notes for version-dependent behavior, extension versions, managed-service limitations, driver behavior, ORM behavior, and pooler mode before relying on new features.
+3. Check connection pressure. Count app instances, workers, background jobs, migrations, admin tasks, and pooler behavior. Prevent connection storms by bounding pool sizes and avoiding one pool per hot request path or serverless invocation when the platform cannot sustain it.
+4. Check transaction boundaries. Keep transactions short, avoid user interaction or external I/O while holding locks, and define isolation, timeout, retry, and idempotency behavior for conflicts, deadlocks, and serialization failures.
+5. Check lock behavior before changing schema. Decide whether an operation blocks reads, writes, both, or only metadata. For live tables, separate expand, backfill, validate, switch, and contract phases when needed.
+6. Check online index and constraint patterns. Use staged validation or concurrent index patterns when the database and migration tool support them, and respect transaction-boundary restrictions. Plan cleanup for invalid indexes or failed validations.
+7. Check table rewrites and scans. Type changes, defaults, generated columns, constraints, backfills, and index builds can rewrite or scan large tables. Do not claim production safety without table-size, lock, timeout, and rollout evidence.
+8. Check schema ownership. Prefer constraints, foreign keys, unique indexes, exclusion constraints, and check constraints for facts the database must enforce. Add child-side foreign-key indexes when query and lock behavior need them.
+9. Check identity and identifiers. Distinguish identity columns, sequences, UUIDs, natural keys, public ids, provider ids, and idempotency keys. Version-gated UUID generation, sequence ownership, and public-id exposure need explicit decisions.
+10. Check type semantics. Use `timestamptz` for instants, separate local schedule values from instants, use numeric types intentionally for money and measurements, avoid `money` unless the product accepts its locale and formatting behavior, and avoid JSONB as a dumping ground for query-critical facts.
+11. Check enum and domain modeling. Database enums are easy to add to but awkward to remove or rename. Use lookup tables or check constraints when lifecycle, localization, tenant customization, or compatibility needs are likely.
+12. Check JSONB, arrays, full-text, vector, geospatial, and extension-backed features. Confirm extension availability, schema ownership, index type, operator class, query shape, backup/restore inclusion, and exit path before relying on provider-specific convenience.
+13. Check query plans with real shape. Prefer representative parameters and data distribution. Separate estimates from actual work, inspect filter versus index conditions when plan evidence exists, and add extended statistics when correlated columns mislead the planner.
+14. Match indexes to workload. Review equality, range, sort, join, partial predicate, expression, multicolumn ordering, GIN/GiST/BRIN tradeoffs, uniqueness, and write amplification. Do not add indexes just because a column is frequently mentioned.
+15. Check partitioning only with a lifecycle reason. Partitioning helps when pruning, retention, load, or maintenance boundaries match the partition key. It can make queries, uniqueness, foreign keys, and operations worse when added as generic scale theater.
+16. Check autovacuum and bloat surfaces. Hot updates, dead tuples, long transactions, queue tables, and repeated deletes can hurt plans and storage. If the change increases churn, name vacuum, retention, and batching assumptions.
+17. Check roles and privileges. Runtime roles should not be owners or superusers. Separate owner, migrator, runtime, read-only, and maintenance roles when the project supports it. Avoid application SQL that depends on a privileged console role.
+18. Check `search_path` and schema qualification. Do not let untrusted or mutable search paths choose functions, tables, extensions, or security-sensitive objects. Schema-qualify sensitive database objects where local practice requires it.
+19. Check RLS and tenant isolation. If RLS protects tenant or user data, verify policy coverage for read, write, update, delete, service roles, migrations, maintenance jobs, and bypass paths. Do not treat application filters as equivalent to RLS.
+20. Check generated SQL and ORM behavior. Review actual generated queries, default transaction wrapping, migration DDL, null handling, relation loading, batching, prepared statement behavior, and pool use. Do not assume the ORM generated the online-safe PostgreSQL pattern.
+21. Check backup and restore. A useful restore includes roles, owners, privileges, extensions, schemas, sequences, RLS policies, data, jobs, and application smoke behavior. Do not treat app-level exports or ad hoc selects as a PostgreSQL backup.
+22. Check replication and read replicas. Reads from replicas may be stale. Failover can break session state, advisory locks, prepared statements, and connection pools. Name freshness and failover assumptions when reads or jobs use replicas.
+23. Select verification from the command contract. Use configured test, build, docs, release, and mustflow intents only; report missing PostgreSQL-specific verification instead of inventing raw database commands.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- PostgreSQL version, provider, extension, pooler, topology, and role boundaries are explicit.
+- Schema constraints, identity, type, timestamp, JSONB, enum, extension, RLS, and privilege decisions match product rules.
+- Lock, rewrite, validation, online-index, backfill, transaction, retry, and timeout behavior is proven or reported as risk.
+- Query plan, index, statistics, partitioning, autovacuum, bloat, and replica-freshness claims are tied to evidence or marked unverified.
+- Backup, restore, roles, privileges, extension, sequence, and failover assumptions are explicit.
+- Verification uses configured command intents only.
+
+<!-- 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 exercises the changed PostgreSQL path. Do not infer raw PostgreSQL shell, package-manager, migration, benchmark, backup, or provider-console commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If server version, provider constraints, extension versions, or pooler mode cannot be identified, do not claim feature support or production equivalence.
+- If lock behavior, table size, backfill volume, timeout, or online DDL behavior is unknown, mark the migration or schema change as production-risky.
+- If roles, RLS, `search_path`, or tenant isolation cannot be proven, fail closed or report the security boundary gap.
+- If query-plan evidence is unavailable, avoid claiming an index or rewrite is faster.
+- If backup and restore evidence is missing, do not claim recovery readiness.
+- If configured verification is missing, report the missing command intent instead of running raw database or provider commands.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- PostgreSQL role, version, provider, extension, and topology inspected
+- Pooling, transaction, lock, retry, timeout, and migration classification
+- Schema, identity, type, timestamp, JSONB, enum, constraint, RLS, role, and privilege decisions
+- Query plan, index, statistics, partitioning, autovacuum, bloat, and replica notes
+- Backup, restore, failover, and managed-provider status
+- Command intents run
+- Skipped PostgreSQL checks and reasons
+- Remaining PostgreSQL risk

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

@@ -288,6 +288,18 @@ route_type = "primary"
 priority = 82
 applies_to_reasons = ["code_change", "data_change", "migration_change", "public_api_change", "test_change", "docs_change", "security_change"]
 
+[routes."sqlite-code-change"]
+category = "data_external"
+route_type = "primary"
+priority = 86
+applies_to_reasons = ["code_change", "data_change", "migration_change", "behavior_change", "test_change", "docs_change", "security_change", "performance_change"]
+
+[routes."postgresql-code-change"]
+category = "data_external"
+route_type = "primary"
+priority = 86
+applies_to_reasons = ["code_change", "data_change", "migration_change", "behavior_change", "public_api_change", "test_change", "docs_change", "security_change", "performance_change"]
+
 [routes."dependency-upgrade-review"]
 category = "data_external"
 route_type = "primary"
@@ -352,7 +364,7 @@ applies_to_reasons = ["formatting_change"]
 category = "general_code"
 route_type = "adjunct"
 priority = 70
-applies_to_reasons = ["performance_change"]
+applies_to_reasons = ["performance_change", "code_change", "data_change", "ui_change", "behavior_change"]
 
 [routes."vertical-slice-tdd"]
 category = "tests"

package/templates/default/locales/en/.mustflow/skills/sqlite-code-change/SKILL.md

@@ -0,0 +1,155 @@
+---
+mustflow_doc: skill.sqlite-code-change
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: sqlite-code-change
+description: Apply this skill when SQLite-specific schema, query, transaction, migration, indexing, extension, WAL, local-file persistence, embedded database, mobile database, browser OPFS/WASM SQLite, cache index, or SQLite runtime behavior is created, changed, reviewed, or reported.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.sqlite-code-change
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - test_related
+    - test
+    - lint
+    - build
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# SQLite Code Change
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep SQLite changes honest about the real runtime, file ownership, concurrency shape, type semantics, query plan, durability, and recovery path.
+
+SQLite is not "small PostgreSQL." It is an embedded library plus a database file. Most mistakes come from pretending it has a server, a remote connection pool, unlimited concurrent writers, or identical feature support in every binding.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- SQLite schema, migrations, queries, indexes, transactions, connection setup, pragmas, journal mode, backup, restore, cache index, or local database files are introduced, changed, reviewed, or reported.
+- A project uses SQLite through an ORM, native binding, bundled library, system library, mobile SDK, Electron or desktop app, WebAssembly build, OPFS-backed browser storage, or Cloudflare/D1-like SQLite surface.
+- A task mentions WAL, foreign keys, `STRICT`, JSON, JSONB, FTS, RTree, generated columns, expression indexes, partial indexes, upsert, busy handling, checkpoints, vacuuming, attached databases, or live database backups.
+- Code treats SQLite as source of truth, rebuildable cache, offline-first store, local search index, test database, edge database, or synchronization replica.
+- Documentation or final reports claim a SQLite change is durable, concurrent, portable, fast, indexed, version-compatible, migration-safe, or recoverable.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is database-backed but not SQLite-specific; use `database-change-safety`.
+- The task only changes database migrations without engine-specific SQLite behavior; use `database-migration-change` first and this skill only for SQLite-specific lock, rewrite, file, pragma, or runtime details.
+- SQLite appears only as an implementation detail of mustflow's own local index and the change is about command authority or generated search metadata rather than SQLite behavior.
+- The task is only dependency version research for a SQLite binding; use `dependency-reality-check` or `version-freshness-check`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- SQLite role: source of truth, local-only cache, read model, sync replica, test fixture, analytics scratch store, or packaged seed database.
+- Runtime identity: SQLite library version, binding or driver, bundled versus system library, compile options when observable, and whether the runtime is native, mobile, WASM, OPFS, edge-hosted, or managed.
+- File ownership: database path, storage medium, backup surface, whether the file is local disk, ephemeral storage, synced folder, network filesystem, container volume, mobile sandbox, or browser origin storage.
+- Concurrency shape: process count, thread model, expected write bursts, single-writer acceptance, busy timeout or retry policy, transaction length, checkpoint owner, and whether readers must keep working during writes.
+- Schema and data rules: foreign key enforcement, affinity expectations, `STRICT` use, `CHECK` constraints, uniqueness, rowid policy, timestamp policy, generated columns, JSON validity, collation, and null semantics.
+- Query and index evidence: affected query paths, expected filters, joins, sorts, counts, pagination, full-text search needs, `EXPLAIN QUERY PLAN` observations when available, and write-cost tradeoffs.
+- Migration and recovery needs: `user_version` or migration ledger, rebuild versus in-place migration, live-data backup method, integrity checks, rollback expectation, and sidecar file handling.
+- Relevant command-intent contract entries for tests, builds, docs, release checks, and mustflow validation.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
+- If SQLite stores product or customer data, also use `database-change-safety`.
+- If SQLite schema or data must move from an old shape to a new shape, also use `database-migration-change`.
+- If runtime versions, bundled binaries, packages, or extension availability are asserted, also use `version-freshness-check` or `dependency-reality-check`.
+- If personal data, secrets, audit logs, retention, tenant isolation, or local-device privacy are involved, also use `security-privacy-review`.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Update SQLite schema, query, connection setup, transaction handling, pragmas, indexes, migrations, fixtures, tests, docs, and directly synchronized template surfaces tied to the task.
+- Add explicit runtime, file, concurrency, migration, backup, and verification notes when SQLite behavior depends on deployment shape.
+- Do not treat a SQLite skill as permission to run raw SQLite tools, migration commands, package scripts, or live database operations outside configured command intents.
+- Do not delete, rewrite, copy, or vacuum live database files unless the user explicitly asked and the repository has a configured, safe command intent or documented manual boundary.
+- Do not use SQLite-specific behavior to silently weaken authorization, tenant scope, durability, privacy, or migration expectations.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the SQLite role. Decide whether the database is authoritative, disposable, a local replica, or a generated index. If clearing the file loses product meaning, treat it as durable data.
+2. Identify the actual runtime before relying on features. Check the binding, bundled or system SQLite library, compile options when observable, and official SQLite release history for any version-dependent feature. Do not assume the newest SQLite documentation matches the deployed runtime.
+3. Check deployment file reality. A local SQLite file behaves differently on laptop disk, mobile sandbox, container volume, synced folder, network filesystem, browser OPFS, and ephemeral serverless storage. Report unsupported or unproven storage shapes.
+4. Decide concurrency honestly. SQLite permits many readers and one writer. WAL improves reader/writer coexistence; it does not turn SQLite into a multi-writer server. Keep write transactions short, avoid external I/O inside transactions, and define busy handling or retry behavior.
+5. Check connection lifecycle. Prefer a small, explicit connection strategy that matches the binding. Avoid accidental many-writer pools, global hidden connections, or per-request open/close churn when the local pattern already owns connection reuse.
+6. Check durability pragmas. Treat journal mode, synchronous behavior, temp store, locking mode, cache size, mmap, checkpointing, and vacuum settings as deployment choices. Do not disable journaling or durability for source-of-truth data unless the loss model is explicit and accepted.
+7. Check foreign keys and constraints. SQLite foreign key enforcement can depend on connection setup. Verify it is enabled where needed, and encode important invariants with constraints instead of relying only on application checks.
+8. Check type semantics. SQLite affinity is permissive unless the schema uses stricter constructs. Use `STRICT`, `CHECK`, generated columns, and canonical serialization where the product needs predictable booleans, timestamps, decimal values, JSON validity, enums, or identifiers.
+9. Check row identity. Decide rowid, integer primary key, autoincrement, UUID, natural key, or composite identity intentionally. Do not assume autoincrement semantics match other databases.
+10. Check SQL construction. Bind values through the local driver or ORM. Build identifiers only from allowlisted names. Do not concatenate user input into raw SQL, FTS queries, pragma names, attached database names, or file paths.
+11. Check upsert and conflict behavior. Make uniqueness constraints match the intended conflict target, and define whether a conflict should insert, update, ignore, or fail. Check triggers and change counters when application behavior depends on affected-row counts.
+12. Check JSON and extension features. JSON, JSONB, FTS, RTree, generated columns, expression indexes, partial indexes, session/change-set features, and vector or custom extensions require runtime support and real query need. Gate them by deployed runtime, binding exposure, and migration fallback.
+13. Check full-text search separately from ordinary indexes. FTS tables need their own content ownership, tokenizer behavior, rebuild path, delete/update handling, and query escaping. Do not treat FTS output as product truth unless the architecture says so.
+14. Match indexes to the actual workload. Review filters, joins, sorts, pagination, uniqueness, and write cost. Use query-plan evidence when available, but do not snapshot `EXPLAIN QUERY PLAN` text as a public API.
+15. Bound reads and writes. Avoid unbounded scans, unbounded result sets, N+1 loops, high-cardinality counts on hot paths, and row-by-row writes when batching is safer.
+16. Check migrations with SQLite limits in mind. Some schema changes require table rebuilds. Preserve data, indexes, triggers, foreign keys, generated columns, collations, and constraints during rebuilds. Keep the migration ledger or `user_version` synchronized.
+17. Check live backup and restore. Use an official backup-style approach or a proven application backup path. Do not copy only the main database file while WAL or shared-memory sidecar files may contain live state. Do not delete sidecar files as "cleanup."
+18. Check integrity and recovery. For durable data, define integrity checks, crash recovery assumptions, restore rehearsal status, and what happens after partial writes, disk-full errors, lock timeouts, interrupted migrations, and failed checkpoints.
+19. Check portability. SQLite SQL, pragmas, collations, extensions, and date/time behavior do not automatically port to PostgreSQL or other engines. If portability is a goal, name the accepted SQLite-specific decisions.
+20. Select verification from the command contract. Use configured test, build, docs, release, and mustflow intents only; report missing SQLite-specific verification instead of inventing raw database commands.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- SQLite runtime, binding, file owner, deployment storage, and feature gates are explicit.
+- Source-of-truth, cache, replica, or generated-index role is named.
+- Transaction length, busy handling, write concurrency, WAL/checkpoint ownership, and durability settings are intentional.
+- Schema constraints, affinity, foreign keys, identity, JSON, FTS, indexes, and migration behavior match product rules.
+- Backup, restore, sidecar-file, integrity, and portability risks are proven or reported as unverified.
+- Verification uses configured command intents only.
+
+<!-- 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 exercises the changed SQLite path. Do not infer raw SQLite shell, package-manager, migration, benchmark, or backup commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If the actual SQLite runtime or binding cannot be identified, do not claim version-specific feature support.
+- If storage is ephemeral, networked, synced, or shared across machines, do not claim ordinary SQLite durability or locking safety without project-specific proof.
+- If concurrent writes, long transactions, WAL checkpointing, or busy handling are unknown, report the concurrency risk instead of assuming defaults are fine.
+- If foreign keys, constraints, or `STRICT` behavior cannot be confirmed, avoid claiming data integrity.
+- If backup, restore, migration idempotency, or sidecar-file handling cannot be proven, mark recovery as unverified.
+- If configured verification is missing, report the missing command intent instead of running raw database commands.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- SQLite role and runtime inspected
+- File ownership, storage, WAL, and concurrency classification
+- Schema, type, constraint, identity, JSON, FTS, and index decisions
+- Transaction, busy handling, durability, checkpoint, and migration notes
+- Backup, restore, integrity, portability, and sidecar-file status
+- Command intents run
+- Skipped SQLite checks and reasons
+- Remaining SQLite risk

package/templates/default/manifest.toml

@@ -1,6 +1,6 @@
 id = "default"
 name = "default"
-version = "2.30.0"
+version = "2.31.0"
 description = "Minimal workflow for LLM agents to read, edit, and verify their work in a repository."
 common_root = "common"
 locales_root = "locales"
@@ -55,6 +55,8 @@ creates = [
   ".mustflow/skills/date-number-audit/SKILL.md",
   ".mustflow/skills/database-change-safety/SKILL.md",
   ".mustflow/skills/database-migration-change/SKILL.md",
+  ".mustflow/skills/sqlite-code-change/SKILL.md",
+  ".mustflow/skills/postgresql-code-change/SKILL.md",
   ".mustflow/skills/dependency-injection/SKILL.md",
   ".mustflow/skills/dependency-reality-check/SKILL.md",
   ".mustflow/skills/dependency-upgrade-review/SKILL.md",
@@ -173,6 +175,8 @@ minimal = [
   "date-number-audit",
   "database-change-safety",
   "database-migration-change",
+  "sqlite-code-change",
+  "postgresql-code-change",
   "dependency-reality-check",
   "dependency-upgrade-review",
   "version-freshness-check",
@@ -239,6 +243,8 @@ patterns = [
   "date-number-audit",
   "database-change-safety",
   "database-migration-change",
+  "sqlite-code-change",
+  "postgresql-code-change",
   "dependency-injection",
   "dependency-reality-check",
   "dependency-upgrade-review",
@@ -316,6 +322,8 @@ oss = [
   "date-number-audit",
   "database-change-safety",
   "database-migration-change",
+  "sqlite-code-change",
+  "postgresql-code-change",
   "dependency-injection",
   "dependency-reality-check",
   "dependency-upgrade-review",
@@ -405,6 +413,8 @@ team = [
   "date-number-audit",
   "database-change-safety",
   "database-migration-change",
+  "sqlite-code-change",
+  "postgresql-code-change",
   "dependency-injection",
   "dependency-reality-check",
   "dependency-upgrade-review",
@@ -480,6 +490,8 @@ product = [
   "date-number-audit",
   "database-change-safety",
   "database-migration-change",
+  "sqlite-code-change",
+  "postgresql-code-change",
   "dependency-injection",
   "dependency-reality-check",
   "dependency-upgrade-review",
@@ -563,6 +575,8 @@ library = [
   "date-number-audit",
   "database-change-safety",
   "database-migration-change",
+  "sqlite-code-change",
+  "postgresql-code-change",
   "dependency-injection",
   "dependency-reality-check",
   "dependency-upgrade-review",