cfsa-antigravity 3.0.2 → 3.1.0

package/template/.codex/skills/migration-management/references/relational.md

@@ -0,0 +1,214 @@
+# Relational Database Migration Patterns
+
+Paradigm-specific patterns for the `migration-management` skill. Read `SKILL.md` first for universal methodology.
+
+Covers: **PostgreSQL**, **MySQL**
+
+---
+
+## Migration Tracking Tables
+
+### PostgreSQL
+
+```sql
+CREATE TABLE schema_migrations (
+  version BIGINT PRIMARY KEY,
+  name VARCHAR(255) NOT NULL,
+  executed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+  duration_ms INTEGER,
+  checksum VARCHAR(64)
+);
+
+CREATE TABLE migration_logs (
+  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  version BIGINT NOT NULL,
+  status VARCHAR(20) NOT NULL,
+  error_message TEXT,
+  rolled_back_at TIMESTAMP,
+  executed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
+);
+
+CREATE OR REPLACE FUNCTION record_migration(
+  p_version BIGINT, p_name VARCHAR, p_duration_ms INTEGER
+) RETURNS void AS $$
+BEGIN
+  INSERT INTO schema_migrations (version, name, duration_ms)
+  VALUES (p_version, p_name, p_duration_ms)
+  ON CONFLICT (version) DO UPDATE SET executed_at = CURRENT_TIMESTAMP;
+END;
+$$ LANGUAGE plpgsql;
+```
+
+### MySQL
+
+```sql
+CREATE TABLE schema_migrations (
+  version BIGINT PRIMARY KEY,
+  name VARCHAR(255) NOT NULL,
+  executed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+  duration_ms INT,
+  checksum VARCHAR(64)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
+
+CREATE TABLE migration_status (
+  id INT AUTO_INCREMENT PRIMARY KEY,
+  version BIGINT NOT NULL,
+  status ENUM('pending', 'completed', 'failed', 'rolled_back'),
+  error_message TEXT,
+  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
+```
+
+---
+
+## Adding Columns
+
+### PostgreSQL
+
+```sql
+-- Non-blocking column addition
+ALTER TABLE users ADD COLUMN phone VARCHAR(20) DEFAULT '';
+ALTER TABLE users ADD CONSTRAINT phone_format
+  CHECK (phone = '' OR phone ~ '^\+?[0-9\-\(\)]{10,}$');
+CREATE INDEX CONCURRENTLY idx_users_phone ON users(phone);
+
+-- Rollback:
+-- DROP INDEX CONCURRENTLY idx_users_phone;
+-- ALTER TABLE users DROP COLUMN phone;
+```
+
+### MySQL
+
+```sql
+ALTER TABLE users
+ADD COLUMN phone VARCHAR(20) DEFAULT '',
+ADD INDEX idx_phone (phone);
+
+-- Rollback:
+-- ALTER TABLE users DROP COLUMN phone;
+```
+
+---
+
+## Renaming Columns
+
+```sql
+-- PostgreSQL
+ALTER TABLE users RENAME COLUMN user_name TO full_name;
+REINDEX TABLE users;
+
+-- Rollback:
+-- ALTER TABLE users RENAME COLUMN full_name TO user_name;
+```
+
+---
+
+## Creating Indexes Non-Blocking
+
+### PostgreSQL (CONCURRENTLY)
+
+```sql
+CREATE INDEX CONCURRENTLY idx_orders_user_created
+ON orders(user_id, created_at DESC);
+
+CREATE INDEX CONCURRENTLY idx_products_category_active
+ON products(category_id) WHERE active = true;
+
+-- Verify
+SELECT schemaname, tablename, indexname, idx_scan
+FROM pg_stat_user_indexes WHERE indexname LIKE 'idx_%';
+```
+
+### MySQL (INPLACE)
+
+```sql
+ALTER TABLE orders
+ADD INDEX idx_user_created (user_id, created_at),
+ALGORITHM=INPLACE, LOCK=NONE;
+```
+
+---
+
+## Data Transformations
+
+### PostgreSQL
+
+```sql
+-- Normalize emails
+UPDATE users SET email = LOWER(TRIM(email))
+WHERE email != LOWER(TRIM(email));
+
+-- Deduplicate (keep latest)
+DELETE FROM users WHERE id NOT IN (
+  SELECT DISTINCT ON (LOWER(email)) id
+  FROM users ORDER BY LOWER(email), created_at DESC
+);
+```
+
+### MySQL
+
+```sql
+UPDATE products p
+JOIN category_mapping cm ON p.old_category = cm.old_name
+SET p.category_id = cm.new_category_id
+WHERE p.old_category IS NOT NULL;
+```
+
+---
+
+## Testing in Transaction
+
+```sql
+BEGIN;
+ALTER TABLE users ADD COLUMN test_column VARCHAR(255);
+SELECT COUNT(*) FROM users;
+-- ROLLBACK if issues, COMMIT if good
+ROLLBACK;
+```
+
+---
+
+## Bidirectional Migration Example
+
+```sql
+-- ===== UP =====
+CREATE TYPE user_status AS ENUM ('active', 'suspended', 'deleted');
+ALTER TABLE users ADD COLUMN status user_status DEFAULT 'active';
+
+-- ===== DOWN =====
+-- ALTER TABLE users DROP COLUMN status;
+-- DROP TYPE user_status;
+```
+
+---
+
+## Production Safety
+
+```sql
+-- PostgreSQL: Prevent hanging migrations
+SET statement_timeout = '30min';
+SET lock_timeout = '5min';
+```
+
+---
+
+## Combined Migration Example
+
+```sql
+BEGIN;
+ALTER TABLE users ADD COLUMN full_name VARCHAR(255);
+UPDATE users SET full_name = first_name || ' ' || last_name;
+CREATE INDEX idx_users_full_name ON users(full_name);
+ALTER TABLE users ADD CONSTRAINT email_unique UNIQUE(email);
+COMMIT;
+```
+
+---
+
+## Tools
+
+- [PostgreSQL ALTER TABLE](https://www.postgresql.org/docs/current/sql-altertable.html)
+- [MySQL ALTER TABLE](https://dev.mysql.com/doc/refman/8.0/en/alter-table.html)
+- [Flyway](https://flywaydb.org/) — Java
+- [Alembic](https://alembic.sqlalchemy.org/) — Python
+- [Knex.js](https://knexjs.org/) — Node.js

package/template/.codex/skills/minimalist-surgical-development/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: minimalist-surgical-development
+description: "Use when editing an existing codebase and the goal is minimal, standard, and non-invasive changes — prioritizes simplest solution, standard libraries first, and surgical modification without unsolicited refactors"
+version: 2.0.0
+source: self
+date_added: "2026-02-27"
+date_rewritten: "2026-03-14"
+---
+
+# Minimalist & Surgical Development
+
+**Code like Kent Beck.** Solve the stated problem with the least code and the least disruption to the existing structure.
+
+## When to Use
+
+- Task emphasizes "minimal changes", "surgical fix", "preserve structure", "don't refactor"
+- Modifying existing code rather than building from scratch
+- Temptation exists to introduce new abstractions, frameworks, or large rewrites
+- Bug fixes where scope creep is the real risk
+
+## When NOT to Use
+
+- Greenfield development (building from scratch)
+- Explicit refactoring requests ("restructure this module")
+- Performance work that requires architectural change
+
+---
+
+## Minimalist Code Generation
+
+### Simplicity First
+
+Always provide the most straightforward solution possible. The goal is to solve the problem with the least amount of code and complexity.
+
+```typescript
+// ❌ Over-engineered
+class ConfigurableRetryStrategy {
+  constructor(private config: RetryConfig) {}
+  async execute<T>(fn: () => Promise<T>): Promise<T> {
+    // 40 lines of retry logic with exponential backoff...
+  }
+}
+
+// ✅ Minimalist (if you only retry once)
+try {
+  result = await fetchData();
+} catch {
+  result = await fetchData(); // One retry
+}
+```
+
+### Standard Library First
+
+Heavily favor standard library functions and widely accepted common patterns. Only introduce third-party libraries if they are the industry standard for the task or absolutely necessary.
+
+```typescript
+// ❌ Adding lodash for one function
+import { groupBy } from "lodash";
+const grouped = groupBy(items, "category");
+
+// ✅ Standard library
+const grouped = Object.groupBy(items, (item) => item.category);
+// Or if targeting older runtimes:
+const grouped = items.reduce((acc, item) => {
+  (acc[item.category] ??= []).push(item);
+  return acc;
+}, {} as Record<string, typeof items>);
+```
+
+### Focus on the Core Request
+
+Generate code that directly addresses the user's request. Do not add extra features or handle edge cases that were not mentioned.
+
+## Surgical Code Modification
+
+### Preserve Existing Code
+
+The current codebase is the source of truth. Respect its structure, style, and logic.
+
+### Minimal Necessary Changes
+
+When adding a feature or fixing a bug, alter the absolute minimum amount of existing code required.
+
+```diff
+ // The user asked: "add a createdAt timestamp to new users"
+ function createUser(data: UserInput): User {
+   return db.users.insert({
+     ...data,
++    createdAt: new Date(),
+     status: "active",
+   });
+ }
+ // That's it. Don't refactor the function, rename variables,
+ // add types, or "improve" unrelated code.
+```
+
+### Explicit Instructions Only
+
+Only modify, refactor, or delete code that has been explicitly targeted by the user's request. Do not perform unsolicited refactoring, cleanup, or style changes on untouched code.
+
+### Integrate, Don't Replace
+
+Whenever feasible, integrate new logic into the existing structure rather than replacing entire functions or blocks.
+
+## Navigation Before Modification
+
+Before making any change, understand what you're modifying:
+
+1. **Read the target** — view the specific function/class being changed
+2. **Check call sites** — grep for usages to understand impact
+3. **Respect patterns** — if the codebase does X one way, continue that way
+4. **Verify after** — run the relevant tests, not the whole suite unless needed
+
+## Quick Checklist
+
+Before submitting a change:
+
+- [ ] Is this the smallest diff that satisfies the requirement?
+- [ ] Did I avoid modifying unrelated code?
+- [ ] Did I use existing utilities/abstractions instead of adding new ones?
+- [ ] Did I avoid adding new dependencies?
+- [ ] Does the change follow existing code style and patterns?
+- [ ] If I added an abstraction — was it explicitly requested?
+
+## Anti-Patterns
+
+| Don't | Do |
+|-------|-----|
+| "While I'm here, let me also..." | Only change what was requested |
+| Introduce new abstractions unprompted | Use existing patterns |
+| Add a library for one utility function | Use standard library |
+| Replace an entire function for a one-line fix | Surgical single-line edit |
+| "Improve" naming in unrelated code | Respect existing conventions |
+| Handle edge cases not mentioned | Solve the stated problem |
+| Add types/docs to untouched functions | Leave existing code alone |

package/template/.codex/skills/parallel-agents/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: parallel-agents
+description: Orchestrate concurrent analysis or implementation across independent domains. Use when a task can be decomposed into independent workstreams (e.g., via simultaneous tool calls or background processes) — spec writing, code review, security audit, feature implementation.
+---
+
+# Parallel Agents & Concurrent Tool Execution
+
+## Overview
+
+Some tasks are naturally parallelizable — they have independent domains that don't share state. As a highly-capable agent, you can drastically cut wall-clock time by leveraging **concurrent tool execution** (e.g., running multiple `view_file` calls, `grep_search` calls, or background terminal commands simultaneously) instead of investigating sequentially.
+
+**Core principle:** Parallelism is a scheduling optimization, not a quality shortcut. Every concurrent workstream follows the same quality standards as a sequential task.
+
+## When to Use
+
+- **Multi-surface implementation** — A slice has independent surfaces (DB, API, UI, admin) that don't share implementation logic
+- **Multi-domain analysis** — Security audit + performance review + accessibility audit on the same codebase
+- **Spec writing** — Multiple IA shards need specs written from the same architecture doc
+- **Code review** — Large PR touches independent subsystems
+- **Debugging** — Multiple independent failures (see `parallel-debugging` skill for the full protocol)
+
+## When NOT to Use
+
+- Tasks share mutable state or edit the same files
+- Later tasks depend on output of earlier tasks (use sequential pipeline instead)
+- You don't fully understand the task decomposition yet (investigate first)
+- Simple task that one agent handles in < 5 minutes
+
+## The Protocol
+
+### 1. Decompose
+
+Break the task into independent domains. Each domain must satisfy ALL of:
+
+| Requirement | Why |
+|-------------|-----|
+| **Independent files** — workstreams do not mutate the same file | Prevents race conditions and tool call hash mismatches |
+| **Independent state** — no shared mutable resources (DB tables, caches) | Prevents race conditions |
+| **Self-contained context** — stream can run without waiting on another's output | Prevents blocking |
+| **Clear deliverable** — you can verify the stream's work in isolation | Prevents integration surprises |
+
+If any requirement fails → that domain can't be parallelized. Run it sequentially.
+
+### 2. Define Workstream Profiles
+
+Instead of giving yourself a single massive objective, explicitly define the scope for each concurrent stream conceptually:
+
+```markdown
+## Workstream: [Domain Name]
+### Scope
+[Exactly what this stream owns — files, features, concerns]
+
+### Context
+[Everything needed — paste relevant code, specs, error messages]
+
+### Constraints
+- Do NOT mutate files outside the defined scope
+- Follow rule: boundary-not-placeholder for cross-stream dependencies
+```
+
+**Scope quality rules:**
+- ✅ **Focused** — one clear problem domain
+- ✅ **Constrained** — explicit file/scope boundaries
+- ❌ **Shared Mutable State** — running `replace_file_content` on the same file concurrently will fail or corrupt data.
+
+### 3. Concurrent Execution
+
+Launch the workstreams simultaneously using your concurrent tool execution capabilities.
+For example, if testing and formatting code, you might run `npm run test` in one background terminal and `npx prettier --write` in another, checking the statuses of both instead of waiting for one to finish before starting the other.
+When making file edits, batch disjoint `replace_file_content` tool calls in the same turn.
+
+### 4. Synthesize
+
+After ALL concurrent streams yield results, synthesize them into a single coherent picture before proceeding:
+
+```markdown
+## Concurrent Synthesis
+
+### Task Summary
+[What was accomplished across all workstreams]
+
+### Findings by Domain
+| Domain | Finding/Result |
+|--------|----------------|
+| Stream 1 | [what was found] |
+| Stream 2 | [what was found] |
+
+### Consolidated Actions
+1. **Critical**: [From Stream X]
+2. **Important**: [From Stream Y]
+
+### Integration Verification
+- [ ] No file conflicts during concurrent editing
+- [ ] Full test suite passes
+- [ ] Changes reviewed for consistency
+```
+
+### 5. Verify Integration
+
+**Non-negotiable:** After merging all agent outputs:
+1. Run the full validation suite (not just individual agent tests)
+2. Check for contradictions between agent recommendations
+3. Verify no files were modified by multiple agents
+4. Spot-check agent work — agents can make systematic errors
+
+## Task Decomposition Archetypes
+
+These are suggested ways to slice concurrent workstreams:
+
+| Archetype | Domain Focus | Typical Sub-Skills |
+|-----------|--------------|-------------------|
+| **Security Review** | Vulnerabilities, RBAC, input validation | security-scanning, code-review |
+| **Test Quality** | Test coverage, edge cases | tdd-workflow |
+| **Backend Implementation** | API design, data layer | rest-api-design, surrealdb-expert |
+| **Frontend Implementation** | UI components, accessibility | frontend-design, accessibility |
+| **Performance Audit** | Bottlenecks, bundle size | web-performance-optimization |
+| **Documentation** | API docs, architecture docs | — |
+| **ACH Debugging** | Root cause investigation | systematic-debugging, parallel-debugging |
+
+## Integration with Kit
+
+- **With `parallel-feature-development`:** When making concurrent file edits, use the strict file ownership protocol to prevent tool call conflicts (e.g. failing `replace_file_content` because the file hash changed).
+- **With `session-continuity` Protocol 9:** When you claim both a `BE` and `FE` task concurrently, the `files:` blocks are your guarantee that you can execute edits simultaneously safely.
+- **With `boundary-not-placeholder`:** If a concurrent stream hits a missing dependency, use `// BOUNDARY:` stubs. Don't block the stream indefinitely.
+
+## Common Mistakes
+
+| Mistake | Consequence | Fix |
+|---------|-------------|-----|
+| Concurrent edits to same file | Overwrites, hash mismatches | One stream per file strictly |
+| No synthesis step | Contradictory logic | Always synthesize before committing changes |
+| Shared dependencies not frozen | Build breaks unexpectedly | Use interface contracts first |
+
+## TDD-Order Dispatch (Slice Implementation)
+
+### Triggering Condition
+
+Enter parallel mode when the slice's tasks contain surface tags (`BE`, `FE`, `QA`). Proceed sequentially when no tags are found.
+
+### Core Principle
+
+> **Tests are the rock. Code is malleable.** Tests encode the acceptance criteria and must be comprehensive. Code adapts to pass tests, never the reverse.
+
+### 5-Phase Dispatch Table
+
+| Phase | Agent | Responsibility | Depends On |
+|-------|-------|----------------|------------|
+| 0 | Orchestrator | Contracts/schemas (untagged tasks) | — |
+| 1 | QA (RED) | Write comprehensive failing tests | Phase 0 |
+| 2 | BE + FE (parallel) | Write code to make tests pass | Phase 1 |
+| 3 | QA (GREEN) | Verify all tests pass, anti-cheat audit | Phase 2 |
+| 4 | Orchestrator | Iterative correction loop if needed | Phase 3 |
+
+### Dispatch Instructions
+
+1. **Untagged tasks first** — Contract/schema work runs sequentially by orchestrator (Phase 0) before any tagged dispatch.
+2. **QA-RED** — QA agent writes comprehensive failing tests for ALL acceptance criteria. Tests MUST fail. Read `.codex/skills/session-continuity/protocols/09-parallel-claim.md`. Every contract field and error type covered.
+3. **BE + FE parallel** — Code against tests and contracts simultaneously. Annotate spec-gap decisions with `// DECISION: [what and why]`.
+4. **QA-GREEN** — Re-verify all tests pass, anti-cheat check, add integration tests.
+5. **Iterative loop rule** — If QA-GREEN fails → re-dispatch BE/FE → QA-GREEN again → repeat until all pass.
+6. **File independence check** — Verify no two tagged tasks touch the same files before dispatching (prevents tool call hash mismatches).
+
+### Progress Logging
+
+Log each dispatch phase to `.memory/pipeline/progress/slices/phase-NN-slice-NN.md` under `## Dispatch Log`.

package/template/.codex/skills/parallel-debugging/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: parallel-debugging
+description: Leverage concurrent terminal background processes to debug multiple independent failures simultaneously using ACH methodology. Use when you have 2+ failures across different subsystems.
+---
+
+# Parallel Debugging via Concurrent Streams
+
+## Overview
+
+When a test suite or system has multiple independent failures, investigating them sequentially in a single terminal is slow. This skill teaches you to spawn multiple concurrent workstreams (e.g. background bash processes) per failure domain, investigating them simultaneously.
+
+**Core principle:** This is a concurrency layer on top of `systematic-debugging`, not a replacement. You must still follow the full four-phase debugging process for each stream.
+
+## When to Use
+
+- 2+ test failures across **different files or subsystems**
+- Multiple error types in logs from **independent components**
+- Post-refactor breakage across **unrelated modules**
+- Production incidents affecting **separate services**
+
+## When NOT to Use
+
+- **Related failures** — fixing one might fix others (investigate together first)
+- **Shared state** — concurrent terminal commands might interfere (e.g. mutating the same database table)
+- **Unknown scope** — you don't know what's broken yet (explore first, then go concurrent)
+- **Single root cause suspected** — one investigation is faster
+
+**Decision test:** If fixing Bug A could possibly affect Bug B, they are NOT independent. Investigate sequentially to avoid tool tool conflict.
+
+## The Protocol
+
+### Phase 1: Hypothesis Generation (ACH)
+
+Before dispatching agents, generate competing hypotheses:
+
+1. **List all failures** with their error messages, stack traces, and last-known-good state
+2. **Group by domain** — which failures share files, state, or call paths?
+3. **Independence test** — for each group, ask: "Could fixing group A change group B's behavior?"
+   - **Yes** → merge into one investigation
+   - **No** → independent, can parallelize
+
+```markdown
+## Failure Analysis
+
+| # | Failure | Domain | Files | Independent? |
+|---|---------|--------|-------|-------------|
+| 1 | `auth.test.ts` — token expired | Auth | `src/auth/*` | ✅ |
+| 2 | `api.test.ts` — 500 on /users | API handler | `src/api/users.ts` | ✅ |
+| 3 | `api.test.ts` — 500 on /users/me | API handler | `src/api/users.ts` | ❌ shares files with #2 |
+| 4 | `db.test.ts` — connection refused | Database | `src/db/*` | ✅ |
+
+→ Dispatch: 3 agents (merge #2 + #3)
+```
+
+### Phase 2: Concurrent Investigation
+
+For each independent failure domain, start a concurrent investigation stream:
+
+1. **Background Terminals**: Use your `WaitMsBeforeAsync` flag to run `npm run test -- path/to/failing.test.ts` in the background. Do this simultaneously for each independent domain.
+2. **Concurrent Analysis**: Check the status of all background commands concurrently. Read the logs side-by-side.
+
+**Constraint per stream:**
+- Mentally partition your execution space: Workstream 1 only looks at Files A and B. Workstream 2 only looks at Files C and D.
+- Do NOT try to `replace_file_content` without strict certainty that the files don't overlap.
+- Every stream still requires the full `systematic-debugging` methodology: gather evidence, find patterns, form hypothesis, test minimally.
+
+### Phase 3: Result Synthesis
+
+After all agents complete:
+
+```markdown
+## Debug Synthesis
+
+### Results
+| Agent | Domain | Root Cause | Fix | Confidence | Cross-Domain? |
+|-------|--------|-----------|-----|------------|---------------|
+| 1 | Auth | Expired token TTL config | Updated config | HIGH | No |
+| 2+3 | API | Missing null check on user.email | Added guard | HIGH | No |
+| 4 | Database | Connection pool exhausted | Increased pool size | MEDIUM | Possible |
+
+### Cross-Domain Discoveries
+[Agent 4 noted: connection pool exhaustion could cause API timeouts under load.
+This may be related to #2+3 under different conditions. Monitor after fix.]
+
+### Integration Verification
+- [ ] All agent fixes applied
+- [ ] No file conflicts between agents
+- [ ] Full test suite passes (not just fixed tests)
+- [ ] Cross-domain discoveries documented as issues
+```
+
+**Synthesis rules:**
+1. **HIGH confidence + no cross-stream overlap** → apply fixes concurrently using batched `replace_file_content` calls.
+2. **MEDIUM confidence** → apply sequentially and test between each.
+3. **Cross-stream discovery** → stop concurrent execution, investigate sequentially.
+
+### Phase 4: Integration Verification
+
+**Non-negotiable after merging all fixes:**
+
+1. Run full test suite (not just the tests each agent fixed)
+2. Check for new failures introduced by fixes
+3. Verify no files were modified by multiple agents
+4. Document cross-domain discoveries as issues for future investigation
+
+## Example: Real Session
+
+**Scenario:** 6 failures across 3 files after refactoring
+
+| File | Failures | Domain |
+|------|----------|--------|
+| `agent-tool-abort.test.ts` | 3 (timing issues) | Abort logic |
+| `batch-completion.test.ts` | 2 (tools not executing) | Batch processing |
+| `race-conditions.test.ts` | 1 (execution count = 0) | Race condition handling |
+
+**Independence test:** Abort logic, batch processing, and race conditions are separate subsystems. ✅
+
+**Dispatch:** Start 3 concurrent `run_command` tests in the background using `WaitMsBeforeAsync`, each tracing their subsystem. Check `command_status` concurrently for all 3.
+
+**Results:**
+- Stream 1: Replaced arbitrary timeouts with event-based waiting
+- Stream 2: Fixed event structure bug (`threadId` in wrong place)
+- Stream 3: Added wait for async tool execution to complete
+
+**Integration:** All fixes independent, applied via batched `multi_replace_file_content` calls, full suite tested and green.
+
+## Common Mistakes
+
+| Mistake | Consequence | Fix |
+|---------|-------------|-----|
+| Parallelizing related failures | One fix breaks another stream's assumptions | Independence test FIRST |
+| Mismatched file edits | `replace_file_content` fails with hash mismatched | Ensure file scopes are 100% independent |
+| Skipping systematic-debugging phases | Guessing instead of investigating | Run the actual tests concurrently |
+| Running tests on shared DB | State leaks between background tests | Mock DB or run sequentially |
+| Skipping integration verification | Silent regressions from fix interactions | Full suite after merge |