@defai.digital/automatosx 12.8.7 → 13.1.2

package/examples/abilities/performance.md

@@ -1,89 +0,0 @@
-# Frontend Performance Optimization
-
-Optimize React applications for speed and efficiency.
-
-## Core Web Vitals
-
-Target metrics:
-- **LCP** (Largest Contentful Paint): < 2.5s
-- **FID** (First Input Delay): < 100ms
-- **CLS** (Cumulative Layout Shift): < 0.1
-- **FCP** (First Contentful Paint): < 1.8s
-- **TTI** (Time to Interactive): < 3.8s
-
-## Optimization Strategies
-
-### 1. Code Splitting
-- Use React.lazy() for route-based splitting
-- Split heavy components (charts, editors, modals)
-- Use Suspense with meaningful fallbacks
-- Analyze bundle with webpack-bundle-analyzer
-
-### 2. Memoization
-- useMemo() for expensive calculations
-- useCallback() for callbacks passed to child components
-- React.memo() for components that re-render with same props
-- Don't over-memoize (profile first)
-
-### 3. Virtualization
-- Use react-window or react-virtualized for long lists (>100 items)
-- Implement infinite scroll for large datasets
-- Lazy load images in viewport
-
-### 4. Asset Optimization
-- Compress images (WebP format, use srcset)
-- Lazy load images (loading="lazy")
-- Use CDN for static assets
-- Enable gzip/brotli compression
-- Optimize fonts (font-display: swap, preload critical fonts)
-
-### 5. Render Optimization
-- Avoid inline function/object creation in render
-- Use key prop correctly for lists
-- Lift state up sparingly (keep state local when possible)
-- Debounce/throttle expensive operations (search, scroll handlers)
-- Use production build for deployment
-
-### 6. Network Optimization
-- Implement caching strategies (Cache-Control headers)
-- Use service workers for offline support
-- Prefetch critical resources
-- Minimize API calls (batch requests)
-- Use GraphQL field selection to fetch only needed data
-
-### 7. Bundle Optimization
-- Tree-shake unused code
-- Use dynamic imports for conditional features
-- Remove unused dependencies
-- Use lighter alternatives (date-fns instead of moment)
-- Configure webpack to split vendor bundles
-
-## Performance Profiling
-
-Tools and techniques:
-- Chrome DevTools Performance tab
-- React DevTools Profiler
-- Lighthouse CI
-- Web Vitals library
-- Bundle analyzer
-
-## Quick Checklist
-
-Before deploying:
-- [ ] Bundle size analyzed and optimized
-- [ ] Images compressed and lazy loaded
-- [ ] Long lists virtualized
-- [ ] Expensive computations memoized
-- [ ] Route-based code splitting implemented
-- [ ] Core Web Vitals measured and acceptable
-- [ ] Production build tested
-- [ ] Caching strategy configured
-
-## Application Hints
-
-When optimizing performance:
-- Measure before optimizing; profile to identify actual bottlenecks, not assumed ones
-- Target Core Web Vitals thresholds (LCP < 2.5s, FID < 100ms, CLS < 0.1)
-- Prefer code splitting and lazy loading over micro-optimizations
-- Don't over-memoize; useMemo/useCallback have overhead and should be profiled
-- Test performance with production builds; dev mode hides real performance issues

package/examples/abilities/problem-solving.md

@@ -1,50 +0,0 @@
-# Problem-Solving Ability
-
-Systematically approach and solve complex problems.
-
-## Problem-Solving Framework
-
-1. **Define** the problem
-   - State the problem clearly
-   - Identify root cause (5 Whys)
-   - Separate symptoms from causes
-   - Define constraints
-
-2. **Analyze** the situation
-   - Gather relevant information
-   - Identify patterns
-   - Consider multiple perspectives
-   - List assumptions
-
-3. **Generate** solutions
-   - Brainstorm alternatives
-   - Don't judge initially (divergent thinking)
-   - Consider unconventional approaches
-   - Document all ideas
-
-4. **Evaluate** options
-   - List pros and cons
-   - Consider trade-offs
-   - Assess feasibility
-   - Estimate impact
-
-5. **Implement** solution
-   - Create action plan
-   - Start with small experiments
-   - Monitor progress
-   - Adjust as needed
-
-6. **Review** and learn
-   - Did it solve the problem?
-   - What worked well?
-   - What could be improved?
-   - Document lessons learned
-
-## Techniques
-
-- **5 Whys**: Dig deeper by asking "why" repeatedly
-- **First Principles**: Break down to fundamental truths
-- **Rubber Duck Debugging**: Explain problem out loud
-- **Divide and Conquer**: Break into smaller sub-problems
-- **Work Backwards**: Start from desired outcome
-- **Analogies**: Apply solutions from similar domains

package/examples/abilities/propulsion-systems.md

@@ -1,50 +0,0 @@
-# Propulsion Systems
-
-## Overview
-
-Engineer and evaluate spacecraft propulsion systems, encompassing chemical and
-electric propulsion performance envelopes, reliability modeling, and
-integration with vehicle architecture and mission requirements.
-
-## Core Concepts & Best Practices
-
-- **Propulsion Taxonomy**: Compare bipropellant, monopropellant, solid,
-  hybrid, electric (Hall, ion, MPD), and advanced concepts (nuclear thermal,
-  solar sail).
-- **Performance Metrics**: Calculate specific impulse, thrust-to-weight, mass
-  flow, and efficiency; assess throttling capability and response time.
-- **System Integration**: Design feed systems (pressurization, valves,
-  regulators), thermal management, and structural interfaces with redundancy.
-- **Reliability Modeling**: Apply fault tree analysis, Weibull statistics, and
-  Bayesian updating to predict MTBF and mission success probabilities.
-- **Contamination & Plume Effects**: Model plume impingement, erosion, and
-  electromagnetic interference on spacecraft subsystems.
-
-## Tools & Methodologies
-
-- **Analysis Suites**: Use NASA CEA, RPA, or in-house CFD tools for combustion
-  and nozzle performance prediction.
-- **Electric Propulsion Modeling**: Employ Hall thruster simulators, ion optics
-  codes, and particle-in-cell (PIC) methods to analyze plasma behavior.
-- **System Sizing**: Develop Excel, Modelica, or Amesim models for propellant
-  budget, tank sizing, and pressurization cycles.
-- **Test Campaign Planning**: Define hot-fire, vibration, thermal vacuum, and
-  life tests; collect telemetry for model correlation.
-- **Verification & Validation**: Execute acceptance test procedures (ATP) and
-  qualification plans while enforcing strict configuration control.
-
-## Example Scenario
-
-A GEO comsat program selects a hybrid propulsion architecture: chemical
-thrusters for orbit raising and Hall-effect thrusters for station-keeping.
-Engineers use NASA CEA to size bipropellant engines, run PIC simulations to
-verify Hall thruster plume interactions, and apply reliability block diagrams
-to ensure mission lifetime exceeds 15 years with 0.98 probability.
-
-## Reference Resources
-
-- Sutton & Biblarz, *Rocket Propulsion Elements*, Wiley
-- Humble, Henry & Larson, *Space Propulsion Analysis and Design*, McGraw-Hill
-- Goebel & Katz, *Fundamentals of Electric Propulsion*, JPL/NASA
-- NASA Chemical Equilibrium with Applications (CEA): <https://cearun.grc.nasa.gov>
-- AIAA Propulsion and Energy Forum Proceedings

package/examples/abilities/quantum-algorithm-design.md

@@ -1,54 +0,0 @@
-# Quantum Algorithm Design
-
-## Overview
-
-Architect and tailor quantum algorithms such as QAOA, VQE, phase estimation,
-Grover, and Shor to solve optimization, simulation, and search problems while
-balancing gate depth, noise resilience, and classical-quantum workflow
-integration.
-
-## Core Concepts & Best Practices
-
-- **Problem Mapping**: Encode cost Hamiltonians or oracle functions that capture
-  the classical objective while minimizing qubit requirements.
-- **Ansatz Engineering**: Choose hardware-efficient or problem-inspired
-  ansätze; analyze expressibility versus trainability to avoid barren plateaus.
-- **Hybrid Loops**: Couple classical optimizers (e.g., SPSA, COBYLA, Adam) with
-  quantum evaluations; reuse measurement data with parameter-shift gradients
-  where available.
-- **Resource Estimation**: Quantify logical depth, T-count, and qubit footprint
-  prior to execution; evaluate circuit cut options for limited hardware.
-- **Error Mitigation**: Integrate zero-noise extrapolation, symmetry
-  verification, and probabilistic error cancellation early in algorithm design.
-
-## Tools & Methodologies
-
-- **Algorithm Templates**: Start from QAOA/VQE scaffolds and customize mixers,
-  cost layers, and measurement strategies.
-- **Classical Preprocessing**: Leverage problem reductions, graph
-  sparsification, or symmetry analysis to shrink the search space.
-- **Parameter Initialization**: Apply warm-start heuristics (e.g., classical
-  solutions, layer-wise training) to accelerate convergence.
-- **Performance Benchmarking**: Run simulators with realistic noise models and
-  track expected energy, fidelity, or success probability across layer depths.
-- **Result Verification**: Validate solutions against classical solvers (exact
-  or approximate) and quantify quantum advantage via scaling studies.
-
-## Example Scenario
-
-A logistics team models vehicle routing as a constrained optimization problem.
-By formulating the cost Hamiltonian for QAOA, selecting a tailored mixer that
-respects route feasibility, and combining SPSA with layer-wise parameter
-growth, they achieve improved approximation ratios on a noisy
-intermediate-scale quantum (NISQ) device relative to classical heuristics.
-
-## Reference Resources
-
-- Farhi et al., “A Quantum Approximate Optimization Algorithm,” arXiv:1411.4028
-- Peruzzo et al., “A Variational Eigenvalue Solver on a Photonic Quantum
-  Processor,” *Nature Communications* (2014)
-- Schuld & Killoran, “Quantum Machine Learning in Feature Hilbert Spaces,”
-  *PRL* (2019)
-- Nielsen & Chuang, *Quantum Computation and Quantum Information*, Cambridge
-  University Press
-- Qiskit Textbook: <https://qiskit.org/textbook>

package/examples/abilities/quantum-error-correction.md

@@ -1,56 +0,0 @@
-# Quantum Error Correction
-
-## Overview
-
-Design and analyze quantum error-correcting codes, including surface codes and
-fault-tolerant logical operations, while applying error mitigation techniques
-to bridge current hardware limitations.
-
-## Core Concepts & Best Practices
-
-- **Code Families**: Evaluate stabilizer, surface, color, and LDPC codes; match
-  code distance and threshold to hardware constraints.
-- **Fault Tolerance**: Implement transversal gates, lattice surgery, and magic
-  state distillation while tracking logical error budgets.
-- **Syndrome Extraction**: Optimize measurement circuits to minimize hook
-  errors and leakage; schedule parallelism carefully.
-- **Decoding Strategies**: Apply minimum-weight perfect matching, belief
-  propagation, or neural decoders; benchmark latency versus accuracy.
-- **Error Mitigation**: Combine post-selection, probabilistic error
-  cancellation, and Clifford data regression with error correction for
-  near-term devices.
-
-## Tools & Methodologies
-
-- **Simulation Frameworks**: Use Qiskit Ignis, QEC frameworks, Stim, or LDPC
-  simulation libraries to evaluate logical error rates.
-- **Decoder Implementations**: Integrate PyMatching, tensor network decoders,
-  or custom FPGA-based solutions for real-time performance.
-- **Threshold Analysis**: Perform Monte Carlo sampling over noise channels
-  (Pauli, amplitude damping, biased dephasing) to estimate thresholds.
-- **Logical Circuit Compilation**: Map high-level algorithms onto logical
-  qubits, schedule patch moves, and analyze lattice surgery costs.
-- **Cross-Layer Co-Design**: Coordinate hardware calibration teams with QEC
-  architects to ensure stabilizer measurements align with physical gate
-  capabilities.
-
-## Example Scenario
-
-A quantum computing platform targets a 10⁻³ logical error rate. Engineers
-select rotated surface codes with distance nine, implement syndrome extraction
-sequences with tailored CNOT ordering, and deploy PyMatching for decoding.
-Post-implementation Monte Carlo runs confirm the logical failure rate meets
-the reliability target under measured device noise.
-
-## Reference Resources
-
-- Fowler et al., “Surface Codes: Towards Practical Large-Scale Quantum
-  Computation,” *PR A* (2012)
-- Dennis et al., “Topological Quantum Memory,” *Journal of Mathematical
-  Physics* (2002)
-- Gottesman, “An Introduction to Quantum Error Correction and Fault-Tolerant
-  Quantum Computation,” arXiv:0904.2557
-- Stim: <https://github.com/quantumlib/Stim>
-- PyMatching: <https://github.com/Quantum-Computing-UK/pymatching>
-- Terhal, “Quantum Error Correction for Quantum Memories,” *Reviews of Modern
-  Physics* (2015)

package/examples/abilities/quantum-frameworks-transpilation.md

@@ -1,53 +0,0 @@
-# Quantum Frameworks & Transpilation
-
-## Overview
-
-Leverage Qiskit, Cirq, and related toolchains to build quantum circuits,
-perform transpilation and optimization passes, and tailor executions to
-specific backend topologies and calibration data for maximal performance.
-
-## Core Concepts & Best Practices
-
-- **Circuit Abstraction**: Separate algorithm logic from backend configuration
-  using parameterized circuits and modular subroutines.
-- **Compilation Stages**: Understand high-level synthesis, basis translation,
-  layout selection, and scheduling; tune each stage for depth and fidelity.
-- **Hardware Awareness**: Align qubit allocation with device coupling maps and
-  apply gate direction corrections plus SWAP insertion strategies judiciously.
-- **Optimization Heuristics**: Employ gate cancellation, commutation analysis,
-  and resynthesis passes; iterate on pass managers to hit depth or width
-  targets.
-- **Calibration Integration**: Consume backend calibration data (gate errors,
-  T1/T2, readout errors) to inform transpiler cost models and pulse-level
-  adjustments.
-
-## Tools & Methodologies
-
-- **Qiskit Workflow**: Use `QuantumCircuit`, `transpile`, and `PassManager`
-  with custom passes; export to QASM or pulse schedules when required.
-- **Cirq Workflow**: Build `Circuit` objects with PhasedFSim gates, optimize
-  via `cirq.optimize_for_target_gateset`, and serialize using `cirq.to_json`.
-- **Cross-Framework Interop**: Convert circuits via `qasm3` or `tket` bridges
-  for comparative benchmarking.
-- **Pulse-Level Control**: Employ Qiskit Pulse or Cirq’s `pulses` module for
-  custom calibrations and dynamical decoupling sequences.
-- **Automation Pipelines**: Script transpilation sweeps across optimization
-  levels, collect performance metrics, and store build artifacts for
-  reproducibility.
-
-## Example Scenario
-
-An R&D team migrates a chemistry VQE circuit to new superconducting hardware.
-They create a custom Qiskit `PassManager` that performs layout selection via
-SABRE, enables commutation-aware gate cancellations, and inserts echoed
-cross-resonance calibrations, cutting circuit depth by 27% while preserving
-expected energy accuracy.
-
-## Reference Resources
-
-- Qiskit Documentation: <https://qiskit.org/documentation>
-- Cirq Documentation: <https://quantumai.google/cirq>
-- Murali et al., “Noise-Adaptive Compiler Mappings for Noisy
-  Intermediate-Scale Quantum Computers,” *ASPLOS* (2019)
-- Cowtan et al., “On the Qubit Routing Problem,” *ACM TECS* (2020)
-- TKET Compiler: <https://cqcl.github.io/tket/pytket/api>

package/examples/abilities/quantum-noise-modeling.md

@@ -1,58 +0,0 @@
-# Quantum Noise Modeling
-
-## Overview
-
-Model and mitigate noise in quantum systems by characterizing decoherence
-channels, gate error rates, and calibration drift to improve reliability of
-algorithm execution on NISQ and emerging fault-tolerant hardware.
-
-## Core Concepts & Best Practices
-
-- **Noise Channels**: Represent errors via Kraus operators (depolarizing,
-  amplitude damping, phase damping) or Lindblad master equations for
-  continuous-time modeling.
-- **Decoherence Metrics**: Track T1/T2 times, Ramsey fringes, and spin-echo
-  results; monitor temperature and flux bias stability.
-- **Gate Characterization**: Use randomized benchmarking, interleaved RB, gate
-  set tomography, and cycle benchmarking to quantify fidelity.
-- **Readout Analysis**: Build confusion matrices, apply measurement error
-  mitigation, and detect drift through auto-calibration routines.
-- **Calibration Strategies**: Schedule frequent recalibrations, employ
-  closed-loop optimization, and maintain calibration history with anomaly
-  alerts.
-
-## Tools & Methodologies
-
-- **Simulation Platforms**: Employ Qiskit Aer noise models, Cirq’s
-  `NoiseModel`, or QuTiP for density-matrix simulations.
-- **Characterization Pipelines**: Automate RB experiments, fit exponential
-  decay to extract error per Clifford, and store metadata in configuration
-  databases.
-- **Drift Detection**: Apply statistical process control (SPC) on calibration
-  metrics; trigger recalibration when control charts exceed thresholds.
-- **Noise-Aware Scheduling**: Route circuits through lower-error qubits, adjust
-  scheduling to avoid crosstalk hotspots, and insert dynamical decoupling
-  pulses.
-- **Mitigation Techniques**: Combine zero-noise extrapolation, probabilistic
-  error cancellation, and measurement mitigation with robust statistical
-  post-processing.
-
-## Example Scenario
-
-An operations team observes declining algorithm fidelity on a trapped-ion
-device. They run interleaved RB to isolate a two-qubit gate with rising error,
-update the Qiskit Aer noise model with new Kraus parameters, and deploy
-adaptive recalibration routines that restore average gate fidelity above
-99.5%, improving VQE energy convergence.
-
-## Reference Resources
-
-- Wallman & Emerson, “Noise Tailoring for Scalable Quantum Computation via
-  Randomized Compiling,” *PRL* (2016)
-- Kjaergaard et al., “Superconducting Qubits: Current State of Play,” *Annual
-  Review of Condensed Matter Physics* (2020)
-- Magesan et al., “Scalable and Robust Randomized Benchmarking of Quantum
-  Processes,” *PRL* (2011)
-- QuTiP Documentation: <https://qutip.org>
-- Kandala et al., “Error Mitigation Extends the Computational Reach of a Noisy
-  Quantum Processor,” *Nature* (2019)

package/examples/abilities/refactoring.md

@@ -1,223 +0,0 @@
-# Refactoring Ability
-
-Expert knowledge of code smells, refactoring techniques, and strategies for improving code quality without changing behavior.
-
-## Overview
-
-Refactoring is the process of restructuring existing code without changing its external behavior. The goal is to improve code quality, readability, and maintainability.
-
-## Code Smells
-
-Code smells are indicators that something might be wrong with your code structure.
-
-### Bloaters
-
-**Long Method**
-- **Smell**: Method with too many lines
-- **Impact**: Hard to understand, test, and maintain
-- **Refactoring**: Extract Method, Replace Temp with Query, Decompose Conditional
-
-```typescript
-// ❌ BAD: Long method
-function processOrder(order: Order) {
-  // Validate order
-  if (!order.id) throw new Error('Invalid order');
-  if (order.items.length === 0) throw new Error('Empty order');
-  for (const item of order.items) {
-    if (item.quantity <= 0) throw new Error('Invalid quantity');
-    if (!item.price) throw new Error('Missing price');
-  }
-
-  // Calculate total
-  let subtotal = 0;
-  for (const item of order.items) {
-    subtotal += item.price * item.quantity;
-  }
-  const tax = subtotal * 0.1;
-  const shipping = subtotal > 100 ? 0 : 10;
-  const total = subtotal + tax + shipping;
-
-  // Apply discounts
-  let discount = 0;
-  if (order.customer.isPremium) {
-    discount = total * 0.15;
-  } else if (total > 200) {
-    discount = total * 0.1;
-  } else if (total > 100) {
-    discount = total * 0.05;
-  }
-
-  // Save order
-  // ... 50 more lines
-}
-
-// ✅ GOOD: Extracted methods
-function processOrder(order: Order) {
-  validateOrder(order);
-  const total = calculateTotal(order);
-  const discounted = applyDiscounts(total, order.customer);
-  return saveOrder(order, discounted);
-}
-
-function validateOrder(order: Order) {
-  if (!order.id) throw new Error('Invalid order');
-  if (order.items.length === 0) throw new Error('Empty order');
-  order.items.forEach(validateOrderItem);
-}
-
-function calculateTotal(order: Order): number {
-  const subtotal = calculateSubtotal(order.items);
-  const tax = calculateTax(subtotal);
-  const shipping = calculateShipping(subtotal);
-  return subtotal + tax + shipping;
-}
-
-function applyDiscounts(total: number, customer: Customer): number {
-  const discountRate = getDiscountRate(total, customer);
-  return total * (1 - discountRate);
-}
-```
-
-**Large Class**
-- **Smell**: Class with too many fields, methods, or responsibilities
-- **Impact**: Violates Single Responsibility Principle
-- **Refactoring**: Extract Class, Extract Subclass
-
-**Long Parameter List**
-- **Smell**: Function with many parameters
-- **Impact**: Hard to use, understand, and change
-- **Refactoring**: Introduce Parameter Object, Preserve Whole Object
-
-**Primitive Obsession**
-- **Smell**: Using primitives instead of small objects
-- **Impact**: Loss of type safety and domain meaning
-- **Refactoring**: Replace Data Value with Object, Introduce Value Object
-
-### Object-Orientation Abusers
-
-**Switch Statements**
-- **Smell**: Type-based conditionals instead of polymorphism
-- **Impact**: Violates Open/Closed Principle, hard to extend
-- **Refactoring**: Replace Conditional with Polymorphism
-
-**Refused Bequest**
-- **Smell**: Subclass doesn't use inherited methods
-- **Impact**: Violates Liskov Substitution Principle
-- **Refactoring**: Replace Inheritance with Delegation, Push Down Method
-
-### Change Preventers
-
-**Divergent Change**
-- **Smell**: One class changed for many different reasons
-- **Impact**: Violates Single Responsibility Principle
-- **Refactoring**: Extract Class
-
-**Shotgun Surgery**
-- **Smell**: Every change requires many small changes in many classes
-- **Impact**: Hard to make changes, easy to miss updates
-- **Refactoring**: Move Method, Move Field, Inline Class
-
-### Dispensables
-
-**Duplicate Code**
-- **Smell**: Same code structure in multiple places
-- **Impact**: Maintenance nightmare, bugs replicate
-- **Refactoring**: Extract Method, Extract Class, Pull Up Method
-
-**Dead Code**
-- **Smell**: Unused variables, parameters, methods, classes
-- **Impact**: Confusion, maintenance burden
-- **Refactoring**: Delete it
-
-**Speculative Generality**
-- **Smell**: "We might need this someday" code
-- **Impact**: Unnecessary complexity
-- **Refactoring**: Collapse Hierarchy, Inline Class, Remove Parameter
-
-## Refactoring Techniques
-
-### Extract Method
-
-**When**: Code fragment can be grouped together
-**Benefit**: Improves clarity, reusability
-
-### Inline Method
-
-**When**: Method body is as clear as the name
-**Benefit**: Reduces unnecessary indirection
-
-### Extract Variable
-
-**When**: Complex expression that's hard to understand
-**Benefit**: Makes expression clearer
-
-### Rename Variable/Method/Class
-
-**When**: Name doesn't reveal intent
-**Benefit**: Improves readability
-
-### Move Method/Field
-
-**When**: Method/field used more by another class
-**Benefit**: Reduces coupling, improves cohesion
-
-### Extract Class
-
-**When**: Class has responsibilities for multiple concerns
-**Benefit**: Follows Single Responsibility Principle
-
-### Replace Conditional with Polymorphism
-
-**When**: Type-based conditionals
-**Benefit**: Follows Open/Closed Principle
-
-## Refactoring Strategies
-
-### 1. The Refactoring Workflow
-
-**Red-Green-Refactor (TDD)**:
-1. **Red**: Write failing test
-2. **Green**: Make test pass (quick and dirty)
-3. **Refactor**: Improve code while keeping tests green
-
-**Safe Refactoring**:
-1. Ensure tests exist and pass
-2. Make small, incremental changes
-3. Run tests after each change
-4. Commit frequently
-5. Use automated refactoring tools when possible
-
-### 2. When to Refactor
-
-**Rule of Three**:
-- First time: Just do it
-- Second time: Wince but do it anyway
-- Third time: Refactor
-
-**Opportunistic Refactoring**:
-- While adding features
-- While fixing bugs
-- During code review
-- When understanding code
-
-### 3. When NOT to Refactor
-
-- Code is about to be deleted
-- Rewriting is easier than refactoring
-- Close to a deadline (defer to later)
-- Code works and doesn't need changes
-
-## Best Practices
-
-1. **Test Coverage First**: Ensure tests exist before refactoring
-2. **Small Steps**: Make one change at a time
-3. **Commit Often**: Save working states frequently
-4. **Use Tools**: Leverage IDE and automated refactoring
-5. **Review Changes**: Have someone review your refactoring
-6. **Document Why**: Explain major refactorings in commit messages
-
-## Further Reading
-
-- "Refactoring" by Martin Fowler
-- "Working Effectively with Legacy Code" by Michael Feathers
-- "Your Code as a Crime Scene" by Adam Tornhill