@devflow-core/dsh-devflow 0.1.0

package/assets/skills/devflow-prove/SKILL.md

@@ -0,0 +1,216 @@
+---
+name: devflow-prove
+description: "Use before saying done, fixed, complete, working, passed, resolved, ready, or candidate_pass; use after builds, bug fixes, rule/docs/skill changes, tests, validation, and any PASS/FAIL/BLOCKED evidence claim. Runs the narrowest sufficient check, performs adversarial review for development work, and reports Command/Result/Adversarial review/Judgment."
+---
+
+# DevFlow Prove
+
+No proof, no completion.
+
+**Violating the letter of the rules is violating the spirit of the rules.**
+
+## Methodology Assets
+
+When this skill activates, read these local references before choosing or running proof scenarios:
+
+- `skills/devflow-prove/references/flow-self-test.md` — end-to-end scenario tests and pressure scenarios for the framework itself.
+- `skills/devflow-prove/references/code-review-checklist.md` — language-specific code quality criteria for adversarial code review.
+
+## Process
+
+Load `skills/devflow-prove/references/proof-recovery-methods.md` before selecting proof. It owns the shared proof and recovery method details used by Prove and PUA.
+
+1. Identify the command, test, build, lint, diff check, validation script, or manual scenario that proves the claim.
+2. Confirm the exact changed files, approved File Structure/Plan boundary, latest Prewalk Execution Trace and Current Handoff Facts. Read the task's remaining-work completion evidence plus the nearest comparable code.
+3. Run the narrowest sufficient check now, then independently inspect the actual implementation diff before interpreting test results.
+4. Run adversarial review (对抗式审查) against the approved responsibility boundary, Prewalk facts, direct contracts, nearby convention, and likely regressions.
+5. For code changes: run the **Code Quality Review** (General Engineering Review + Language-Specific Checklist from `code-review-checklist.md`), then generate a **Code Review Report** (see format below). Classify each evidence-backed finding as Blocker, Warning, or Recommendation. An unresolved Blocker or Warning returns `FAIL` facts to Core; recommendations do not block an otherwise proven result.
+6. Read the real output and exit status.
+7. If it fails, report `FAIL` facts to `devflow-core`; Core selects Recovery or another owner. Use `devflow-pua` when the failure includes user challenge, repeated miss, or changed-wrong behavior.
+8. If it cannot run, report `BLOCKED` facts to `devflow-core` and name the missing condition.
+9. On `PASS`, load `devflow-learn` for its mandatory proactive completion review before final completion reporting. The review may yield a learning card, a project-knowledge candidate pending user confirmation, or no useful record.
+10. Only then report completion or `candidate_pass`.
+
+## Exception Return Boundary
+
+Prove is the terminal direct-success step. `PASS` completes only after the Learn review. `FAIL`, `BLOCKED`, an adversarial gap, an unresolved Code Review Blocker/Warning, or a missing recovery-proof field are non-unique facts and return to `devflow-core`; Prove does not select the repair, recovery, or re-clarification skill.
+
+## Proof Selection
+
+| Work type | Proof |
+|---|---|
+| Docs/rules/skills | File presence, frontmatter, required wording, command entries, path consistency, scenario checklist. |
+| Code | Targeted test, build, lint, typecheck, or runtime scenario. **Plus: inspect the actual implementation diff against the approved File Structure/Plan boundary, Prewalk evidence, and nearest comparable code before interpreting test results.** **Plus: comment verification — check requirements recorded by the Spec/Plan or local convention, and any non-obvious decision, business, security, or compatibility boundary.** **Plus: language-specific code quality review — detect language from file extensions, apply the matching checklist in `skills/devflow-prove/references/code-review-checklist.md`, and classify evidence-backed Blockers, Warnings, and Recommendations.** |
+| Bug fix | Original symptom reproduction or regression check. **Plus: verify any documented fix rationale and any non-obvious failure condition that needs preservation.** |
+| Framework design | Native capability coverage, anti-pattern gates, skill behavior, and output contracts. |
+| Productized skill pack | `npm test` or equivalent package validation. |
+
+## Adversarial Review
+
+After development work, adversarial review (对抗式审查) is mandatory before completion: check the strongest plausible reason the change is still wrong, incomplete, unreachable, over-broad, or under-verified. If the adversarial review finds a real gap, report `FAIL` facts to `devflow-core` before claiming completion.
+
+Adversarial review checklist for code changes:
+
+- **Correctness**: Does the code actually solve the stated goal? Are edge cases handled?
+- **Regression**: Could this change break sibling callers, shared state, or downstream consumers?
+- **Activation path**: Is the new code actually reachable? Can the user/trigger reach it?
+- **Scope creep**: Does the diff include unrequested behavior or drive-by refactors?
+- **Proof coverage**: Is the verification narrow enough to be meaningful, or is it a rubber-stamp?
+- **Code comments**: Are all Spec/Plan/local-convention requirements present? Are non-obvious decisions, business rules, security, or compatibility boundaries documented where needed? A missing triggered comment is an approved-contract gap; absence of untriggered narration is not.
+- **Code Quality**: Two-layer review. The adversarial review items above (Correctness, Regression, Activation path, Scope creep) already cover functional correctness. Then run the **General Engineering Review** from `skills/devflow-prove/references/code-review-checklist.md` for the remaining dimensions: requirements understanding, code quality (readability, maintainability, testability), performance, security, error handling. Finally, detect language(s) from file extensions and apply the matching **Language-Specific Checklist**. **Generate a diff-first Code Review Report (see format below) with actual changed-code evidence, Plan boundary, Prewalk evidence, Blockers, Warnings, Recommendations, and Boundary verdict; unresolved Blockers or Warnings block PASS.**
+
+After agent rule, command, prompt, entry, or `SKILL.md` changes, run a Skill Activation Chain Check before completion:
+
+```text
+Skill Activation Check: trigger <user words/command/upstream output>; surface <description/command/entry>; action <loads/calls target skill>; evidence <artifact/check/output>
+```
+
+Check:
+
+- Trigger: natural user wording, explicit command, or upstream stage output can reach the target skill.
+- Surface: the target `description`, command prompt, or entry file contains real trigger wording.
+- Runtime action: the rule says to load/call the skill, not only "reference" it.
+- Handoff evidence: the downstream skill artifact, check, or output contract is required before completion.
+- Breakpoint: if activation is broken, fix the trigger chain before editing skill internals again.
+
+## Required Output
+
+```text
+Command: <actual command run>
+Result: <key output summary>
+Adversarial review: <strongest challenge and disposition, or not applicable for non-development verification>
+Judgment: PASS / FAIL / BLOCKED
+```
+
+Add coverage when useful:
+
+```text
+Coverage: <what was verified>
+Not covered: <none or explicit gap>
+```
+
+## Code Review Report
+
+For code changes, after running the Code Quality Review (General Engineering Review + Language-Specific Checklist), generate this report before claiming PASS or FAIL. Review the actual diff before relying on test results. A Blocker or unresolved Warning returns `FAIL` facts to Core; Recommendations remain visible but do not independently prevent PASS.
+
+```text
+Code Review Report:
+- Diff reviewed: [actual changed files/ranges].
+- Plan boundary: [approved File Structure row(s) and verdict].
+- Prewalk evidence: [Execution Trace, Handoff Facts, remaining-work completion evidence].
+- Comparable code: [nearest inspected file/symbol and observed convention].
+- Blockers: [count].
+  1. [Blocker] [file:line] — [changed-code evidence and concrete risk] → [smallest correction].
+- Warnings: [count].
+  1. [Warning] [file:line] — [evidence-backed issue] → [required closure].
+- Recommendations: [count].
+  1. [Recommendation] [file:line] — [contextual improvement] → [optional choice].
+- Boundary verdict: [within approved responsibility/touch set or drift facts returned to Core].
+- Judgment: PASS (no unresolved Blockers or Warnings) / FAIL (Blocker or Warning remains).
+```
+
+Rules:
+- Every Blocker or Warning identifies an actual changed-code location, evidence, concrete risk, and smallest correction.
+- A pattern preference, function size, class name, dependency count, missing cache, or fixed architectural shape cannot block by itself.
+- Re-review the new diff after every quality repair and explicitly close or persist each prior Blocker/Warning.
+- **STOP gate**: when a Blocker or Warning remains, do not claim `PASS`; return the facts to Core for the next lifecycle decision. Recommendations remain visible but do not independently stop an otherwise proven result.
+
+## Learning Check
+
+Every `PASS` must load `devflow-learn` before the final completion report. The review actively extracts reusable implementation patterns, constrained decisions, effective proof, conventions, invariants, and business-fact candidates from verified work. A card is conditional on useful future-task value; the review itself is mandatory.
+
+If the user corrected the result, repeated the same rule, or a non-obvious pitfall appeared, preserve the existing `devflow-learn` recovery capture in addition to the `PASS` review.
+
+When a review identifies a code-backed business-semantic change, report the candidate and wait for user confirmation before loading `devflow-project-knowledge`. Do not update `docs/project-knowledge/` automatically.
+
+Report:
+
+```text
+Learning closure:
+- Learning signal: PASS review/correction/pitfall/none
+- Recall record: none/index/card
+- Review result: learning card/project-knowledge candidate/no useful record
+- New sediment: none/card/rule/skill
+- Next intercept: next time <X>, first do <Y>, do not do <Z>
+```
+
+Do not create noisy learning entries for one-off facts, raw implementation narration, already-covered lessons, or pure refactors without reusable insight.
+
+## Pressure Recovery Check
+
+If proof fails after repeated attempts, or the user says the result is wrong, changed wrong, not what they asked for, or hard to distinguish:
+
+```text
+Pressure check: user challenged result / repeated miss / failed proof
+Next step: devflow-core -> devflow-pua
+```
+
+Do not continue the same approach with only minor wording, parameter, or nearby-file tweaks. `devflow-pua` must stop, restate the goal, ask or infer the desired result, list 3 hypotheses, and choose a materially different approach before the next proof.
+
+## Recovery Proof Contract
+
+After a `devflow-pua` recovery, the first Prove pass must cite the PUA recovery output as evidence that recovery actually ran — triggering the skill alone is not proof. Quote these fields from the PUA output:
+
+```text
+Recovery evidence:
+- METHOD / SWITCH: <flavor/method and any switch line>
+- User-view miss: <classification>
+- New success contract: <expected result + verification>
+- Changed approach: <old path abandoned; new path>
+```
+
+If any field is missing or empty, recovery was not executed. Report `FAIL` facts to `devflow-core`, which may select `devflow-pua`; a bare `METHOD:` line without diagnosis, quarantine, and a changed approach is not recovery.
+
+## Evidence Rules
+
+- Do not write "should work" as a result.
+- Do not hide skipped checks.
+- If verification is partial, say exactly what remains unverified.
+- Never use old output, "looks good", or a delegated claim without independent verification.
+- Running the same successful command twice without changes adds no evidence.
+- On DeepSeek Harness (DSH), oversized tool results are pruned (default threshold 8192 chars, keeping the head 4096 and tail 1024). Preserve the key command, result excerpt, and judgment rationale in your own context — the completion report or `todo_write` — before a long output is truncated; do not rely on a pruned tool result still holding the evidence.
+
+## Failure Loop
+
+If proof fails:
+
+```text
+Judgment: FAIL
+Failure facts: ...
+Next step: devflow-core Recovery route; use devflow-pua for user challenge, changed-wrong result, repeated miss, or quality complaint
+```
+
+Recovery requires re-reading facts, listing 3 hypotheses, and trying a materially different approach.
+
+## Anti-Rationalization
+
+| Excuse | Reality |
+|---|---|
+| "This is only documentation." | Documentation can still be broken, stale, or uncallable. Validate it. |
+| "A partial check is enough." | Partial proof must be labeled partial. |
+| "The tool said success." | Tool claims are data. Verify the actual artifact/output. |
+| "I am confident." | Confidence is not evidence. |
+| "Comments are optional, the code works." | Comments required by the Spec, Plan, project convention, or a non-obvious boundary are implementation requirements; verify them. |
+| "The code is self-explanatory." | Clear code can avoid redundant narration, but it cannot waive an approved documentation requirement or an important non-obvious reason. |
+
+## Red Flags — STOP
+
+- About to say "done", "fixed", "complete", or "passed" without running verification
+- Using "should work", "probably", or "seems to"
+- Trusting a delegated claim without independent verification
+- Reusing old output as proof
+- Expressing satisfaction before verification runs
+- Skipping the Skill Activation Chain Check after rule/skill/command changes
+- Claiming PASS when an approved documentation requirement or an important non-obvious boundary is unaddressed
+
+**All of these mean: run the command, read the output, then claim.**
+
+## Verification
+
+Before leaving this skill, confirm:
+
+- [ ] Actual command or manual scenario was run.
+- [ ] Result summary cites real output.
+- [ ] Judgment is `PASS`, `FAIL`, or `BLOCKED`.
+- [ ] Coverage and gaps are clear when relevant.
+- [ ] After a `devflow-pua` recovery, the Prove pass cites the Recovery Proof Contract fields (METHOD/SWITCH, User-view miss, New success contract, Changed approach).

package/assets/skills/devflow-prove/references/code-review-checklist.md

@@ -0,0 +1,202 @@
+# Code Review Checklist
+
+Two-layer review: general engineering dimensions (all languages) + language-specific best practices.
+
+## How to Use
+
+1. Read the approved File Structure/Plan boundary, latest Prewalk Execution Trace, Current Handoff Facts, remaining-work completion evidence, actual changed diff, and nearest comparable code.
+2. Run the **General Engineering Review** first — applies to all code changes regardless of language.
+3. Detect the language(s) from changed file extensions.
+4. Apply the matching **Language-Specific Checklist** below.
+5. For full-stack changes, apply all relevant language checklists.
+6. Classify findings only from actual changed-code evidence and concrete risk: unmet approved requirement, active security/data/authorization risk, correctness regression, or demonstrated operational failure is a `Blocker`; an evidence-backed boundary, contract, local-convention, side-effect, or verification issue requiring closure is a `Warning`; other contextual guidance is a `Recommendation`. Unresolved Blockers and Warnings prevent `PASS`.
+
+> **Note**: Functional correctness, regression, activation path, scope creep, and proof coverage are already covered by the adversarial review checklist in `SKILL.md`. The General Engineering Review below covers the remaining dimensions that the adversarial review does not.
+
+> **Applicability**: Treat the following design, framework, and language items as context checks, not universal prescriptions. Apply one when the approved scope, existing project convention, measured workload, public contract, or concrete failure mode makes it relevant. Security, authorization, data protection, injection prevention, resource safety, and an explicit project rule remain hard checks.
+
+> **Non-blocking by itself**: a pattern preference, function or class size, dependency count, absent cache, or fixed architecture shape is not a Blocker or Warning without changed-code evidence and concrete risk.
+
+## General Engineering Review
+
+Applies to all code changes. Review the items proportionately to the changed behavior and classify them with the rules above; do not fail a small change merely because it omits a speculative abstraction or style preference.
+
+### 1. Requirements Understanding
+
+- [ ] Business goal is clear: what does this code achieve?
+- [ ] Inputs, outputs, and boundary conditions are identified.
+- [ ] Non-functional requirements are addressed (performance, security, availability).
+
+### 2. Code Quality
+
+#### 2.1 Readability
+
+- [ ] A maintainer can identify business intent, key rules, failure paths, and side effects from local names and structure.
+- [ ] Types and functions have one dominant, coherent responsibility; boundaries are changed only when dependencies, lifecycle, or change reasons justify it.
+- [ ] Important conditions use domain language; code avoids unexplained flags, magic values, and opaque control flow where a clearer local expression is warranted.
+- [ ] Comments explain WHY, not WHAT; names and structure carry ordinary explanation.
+
+#### 2.2 Maintainability
+
+- [ ] The nearest applicable project convention for naming, layering, errors, logging, caching, and tests is followed, or a deliberate deviation has reason, impact, and proof.
+- [ ] Dependencies, configuration, and extension points are introduced only when current scope or evidence makes them useful.
+- [ ] Meaningful duplication is consolidated only when shared code improves local understanding, correctness, or a demonstrated reuse need.
+- [ ] New abstraction preserves a current boundary, replacement need, test need, or multiple real implementations; it is not added only to satisfy a design principle.
+
+#### 2.3 Testability
+
+- [ ] State and side effects have an appropriate test seam for the changed behavior; use interfaces, dependency injection, pure functions, or existing project mechanisms only when they improve that seam.
+- [ ] Side effects are controlled and isolated where the current risk or project convention requires it.
+- [ ] Tests cover changed main paths, edge cases, and boundary conditions proportionately to risk.
+
+### 3. Performance
+
+- [ ] Time and space complexity fit the expected data volume or measured workload.
+- [ ] No N+1 query problems or repeated expensive work on an identified hot path.
+- [ ] Caching, optimization, and concurrency are assessed when workload or a concrete failure mode makes them relevant; any chosen cache has measurable benefit, ownership, invalidation, and consistency behavior.
+- [ ] Performance techniques are not added speculatively where the simpler path is sufficient.
+
+### 4. Security
+
+- [ ] Input validation prevents injection (SQL, XSS, command, path traversal).
+- [ ] Output encoding prevents XSS.
+- [ ] Sensitive data is encrypted (at rest and in transit).
+- [ ] Authorization and permission checks are in place.
+- [ ] Logs do not leak sensitive data (passwords, tokens, PII).
+
+### 5. Error Handling
+
+- [ ] Exceptions are classified appropriately (business vs system vs validation).
+- [ ] Error messages are user-friendly and actionable.
+- [ ] Resources are properly released (connections, files, streams).
+- [ ] Fail-fast principle applied where appropriate.
+
+## Language-Specific Checklists
+
+## C# / .NET
+
+- Use enums for fixed value sets; no magic strings/numbers.
+- Use `const` or `static readonly` for true constants; not `static` instance fields.
+- Prefer LINQ over manual loops when it improves readability without hurting performance.
+- Use `var` when the type is obvious from the right side; use explicit type when it aids readability.
+- Use `StringBuilder` for string concatenation in loops; not `+=`.
+- Use `string.IsNullOrEmpty()` / `string.IsNullOrWhiteSpace()`; not `== ""` or `== null`.
+- Prefer `async/await` over `.Result` / `.Wait()`; avoid sync-over-async.
+- Use `ConfigureAwait(false)` in library code.
+- Use collection initializers: `new List<T> { a, b, c }`.
+- Use null-conditional operators (`?.`) and null-coalescing (`??`) appropriately.
+- Use `record` for immutable data; `class` for mutable.
+- Use pattern matching (`is`, `switch` expressions) over type checks + casts.
+- Use `nameof()` for parameter/property references in exceptions and notifications.
+- Prefer dependency injection over static service locators.
+- Use `using` statements/declarations for IDisposable.
+- Check for: `==` vs `.Equals()`, mutable structs, enum underlying type mismatches, missing `ConfigureAwait(false)` in library code.
+
+## Java
+
+- Use enums for fixed value sets; no magic strings/numbers.
+- Use `Optional<T>` for nullable return values; not `null` returns with `@Nullable`.
+- Prefer `Stream` API over manual loops when it improves readability.
+- Use `StringBuilder` for string concatenation in loops.
+- Use `Objects.requireNonNull()` for null checks.
+- Prefer `List.of()` / `Map.of()` (Java 9+) for immutable collections.
+- Use `try-with-resources` for AutoCloseable.
+- Prefer interfaces as types: `List<String>` not `ArrayList<String>`.
+- Use `@Override` when implementing interface methods or overriding superclass methods.
+- Use `final` for variables that should not be reassigned.
+- Prefer records (Java 16+) for immutable data carriers.
+- Use `instanceof` pattern matching (Java 16+) over type checks + casts.
+- Use `switch` expressions with `->` and `yield`.
+- Check for: `==` for string comparison, `Integer` cache range, unchecked exceptions, raw types.
+
+## TypeScript / JavaScript
+
+- Use `enum` or union types for fixed value sets; no magic strings/numbers.
+- Use `const` by default; `let` only when reassignment is needed; never `var`.
+- Prefer `interface` for object shapes; `type` for unions and intersections.
+- Use optional chaining (`?.`) and nullish coalescing (`??`).
+- Use `readonly` for immutable properties and `Readonly<T>` / `ReadonlyArray<T>` for immutable collections.
+- Prefer `unknown` over `any`; use type guards to narrow.
+- Use discriminated unions for state machines; not boolean flags.
+- Use `as const` for literal type inference.
+- Prefer `import type` for type-only imports.
+- Use `Promise` with `async/await`; not `.then()` chains when possible.
+- Use `Map`/`Set` for key-value/unique collections; not plain objects when keys are non-string.
+- Check for: `==` vs `===`, `null` vs `undefined`, mutable default parameters, `any` overuse.
+
+## Vue
+
+- Use `<script setup>` with Composition API; not Options API for new code.
+- Use `ref()` / `reactive()` for state; `computed()` for derived values.
+- Use `defineProps()` / `defineEmits()` with TypeScript types.
+- Use `watch()` / `watchEffect()` for side effects; clean up in `onUnmounted()`.
+- Prefer `v-model` with `defineModel()` over manual prop/emit sync.
+- Use `provide()` / `inject()` for dependency injection across deep component trees.
+- Use `<Suspense>` for async component loading.
+- Keep components small and composable; extract reusable logic to composables (`use*` functions).
+- Use `v-if` for conditional rendering, `v-show` for frequent toggling.
+- Use `:key` with `v-for` for stable identity; not array index.
+- Check for: reactive property addition without `reactive()`, missing `key` in `v-for`, `v-if` + `v-for` on same element, missing `onUnmounted` cleanup.
+
+## React
+
+- Use function components with hooks; not class components for new code.
+- Use `useState` for local state; `useReducer` for complex state logic.
+- Use `useMemo` / `useCallback` only when profiling shows a need; not by default.
+- Use custom hooks (`use*`) to extract reusable logic.
+- Use `useEffect` with proper cleanup; not for derived state (use `useMemo` instead).
+- Use `React.memo()` only when profiling shows re-render issues.
+- Use `key` prop with stable identity in lists; not array index.
+- Use `children` prop for composition; not prop drilling when possible.
+- Use Context for cross-cutting concerns; not for every piece of state.
+- Use `forwardRef` when the component needs to expose a ref.
+- Use `useId()` for stable unique IDs.
+- Use Suspense + lazy for code splitting.
+- Check for: stale closures in `useEffect`, missing dependency arrays, `useEffect` for derived state, unnecessary `useMemo`/`useCallback`.
+
+## Python
+
+- Use `Enum` / `IntEnum` for fixed value sets; no magic strings/numbers.
+- Use type hints (`typing` module) for function signatures.
+- Use `dataclass` for data containers; `NamedTuple` for immutable records.
+- Use `pathlib.Path` for file paths; not `os.path` string concatenation.
+- Use `f-strings` for string formatting; not `%` or `.format()`.
+- Use `with` statements for resource management.
+- Use `collections` module: `defaultdict`, `Counter`, `deque` where appropriate.
+- Use list/dict comprehensions over manual loops when readable.
+- Use `if __name__ == "__main__":` guard for script entry.
+- Use `@dataclass(frozen=True)` for immutable data.
+- Use `match` statement (Python 3.10+) for structural pattern matching.
+- Use `@property` for computed attributes; not getter methods.
+- Use `abc.ABC` / `@abstractmethod` for interfaces.
+- Check for: mutable default arguments, `is` vs `==`, bare `except`, `global` overuse.
+
+## Go
+
+- Use `iota` constants or named types for fixed value sets; no magic strings/numbers.
+- Use `errors.Is()` / `errors.As()` for error checking; not `==`.
+- Use `defer` for cleanup; LIFO order.
+- Use `context.Context` for cancellation and timeouts in all I/O functions.
+- Use `struct` with methods; not inheritance.
+- Use interfaces with small method sets (1-3 methods); define at point of use.
+- Use `goroutine` + `channel` for concurrency; not shared state with mutex when possible.
+- Use `sync.WaitGroup` for goroutine coordination.
+- Use table-driven tests as the default test pattern.
+- Use `go fmt` style; tabs not spaces.
+- Use `:=` for new variables; `=` for reassignment.
+- Use `if err != nil` error handling; not panic/recover for control flow.
+- Check for: goroutine leaks, unclosed channels, nil interface values, slice aliasing, unhandled errors.
+
+## SQL
+
+- Use parameterized queries; never string concatenation for SQL.
+- Use `COALESCE` / `NULLIF` for null handling; not `ISNULL` or `IFNULL` when portable.
+- Use `EXISTS` over `IN` for subqueries on large datasets.
+- Use `JOIN` with explicit `ON`; not implicit comma joins.
+- Use `WITH` (CTE) for complex queries; not nested subqueries.
+- Use `UPSERT` (`ON CONFLICT` / `MERGE`) for insert-or-update; not SELECT-then-INSERT.
+- Use `CASE WHEN` for conditional logic; not `IIF` or `DECODE` when portable.
+- Use `EXPLAIN` to verify query plans for non-trivial queries.
+- Use indexes on columns in `WHERE`, `JOIN`, and `ORDER BY` clauses.
+- Use `TRANSACTION` / `BEGIN...COMMIT` for multi-statement atomicity.
+- Check for: `SELECT *`, missing `WHERE` in `UPDATE`/`DELETE`, N+1 queries, implicit type conversion, missing index on hot path.