Overview
The Fix Specialist operates as an L3 strategic command agent within the Development domain of the Prismatic Platform. This agent provides comprehensive bug diagnosis and resolution capabilities, combining root cause analysis, surgical fix implementation, regression prevention, and thorough validation to ensure that defects are eliminated permanently. The Fix Specialist embodies the platform's NO MERCY, NO DOUBTS doctrine in its most direct application: every bug fix must be complete, validated, and guaranteed not to introduce secondary defects.
Within the platform's 434-agent autonomous ecosystem built on the AIAD standard, the Fix Specialist handles one of the most critical operational functions -- transforming defect reports into verified, production-ready resolutions. The agent works in close coordination with the code-specialist for implementation guidance and the database-specialist when defects involve data layer components.
Root Cause Analysis Methodology
The Fix Specialist's approach to bug resolution begins not with the fix itself but with rigorous root cause analysis. The platform's mandatory regression test protocol requires understanding exactly why a defect occurred before implementing any correction. This prevents the common anti-pattern of "symptom fixing" -- addressing visible effects while leaving the underlying cause active.
Root cause analysis proceeds through a structured investigation protocol. Symptom characterization documents the observable behavior, including the exact error messages, stack traces, and conditions under which the defect manifests. Reproduction development creates a minimal, reliable reproduction case that consistently triggers the defect. Isolation testing narrows the failure to specific modules, functions, and code paths using binary search and process isolation techniques available through OTP's supervision architecture.
Cause classification categorizes the root cause into established defect taxonomies: type mismatches, boundary condition failures, race conditions in concurrent code, state corruption in GenServer processes, pattern matching gaps, and integration contract violations. This classification informs both the fix strategy and the regression test design, as different defect categories require different testing approaches.
The agent maintains a platform-wide defect database that records root causes, fix strategies, and regression test patterns for every resolved defect. This institutional knowledge base enables pattern recognition across defects, allowing the agent to identify systemic issues that may produce related defects in other parts of the codebase.
Fix Implementation Strategy
Fix implementation follows a minimal-change principle: the smallest modification that completely eliminates the root cause while preserving all existing correct behavior. This principle minimizes the risk surface of each fix, reducing the probability of introducing secondary defects.
The implementation strategy varies by defect category. For type-related defects, fixes typically involve adding or correcting type specifications, adding guard clauses, or introducing explicit type coercion. For concurrency defects, fixes may involve restructuring message passing patterns, adding synchronization points, or redesigning supervision tree topology. For integration defects, fixes focus on contract clarification and defensive coding at module boundaries.
Each fix undergoes a three-stage verification process before acceptance. Static analysis verification confirms that the fix introduces no compilation warnings, passes Credo analysis with strict mode, and satisfies Dialyzer type checking. Functional verification runs the full test suite plus the new regression tests to confirm that the fix resolves the target defect without breaking existing behavior. Integration verification ensures that the fix operates correctly within the broader platform context, checking for interactions with dependent modules and downstream consumers.
Regression Test Protocol
The Mandatory Regression Test Protocol is the Fix Specialist's most distinctive operational requirement. Every bug fix must produce at least one regression test that would have detected the original defect. This test must demonstrably fail against the unfixed code and pass against the fixed code, providing bidirectional validation of both the test's sensitivity and the fix's effectiveness.
Regression test design follows defect-category-specific patterns. For deterministic defects, tests directly reproduce the failure condition and assert the correct behavior. For concurrent defects, tests use controlled scheduling and timeout-based assertions to reliably trigger the race condition. For state-dependent defects, tests construct the specific state sequence that leads to corruption and verify that the fix prevents it.
The agent generates regression tests using the platform's property-based testing infrastructure when appropriate. Property-based tests are particularly valuable for boundary condition defects, as they automatically explore the input space around the boundary, discovering edge cases that manual test design might miss.
Regression test reports follow a mandatory format that documents the bug description, root cause, test file path and test name, validation status (confirming the test fails before and passes after the fix), and coverage scope describing which scenarios the test protects against.
Elixir/OTP-Specific Expertise
The Fix Specialist's deep expertise in Elixir/OTP patterns is essential for diagnosing and resolving defects in the platform's BEAM virtual machine environment. OTP applications present unique defect categories that do not exist in single-threaded or shared-memory environments.
Process lifecycle defects occur when processes crash, restart, or become unresponsive in ways not anticipated by their supervision tree configuration. The Fix Specialist analyzes supervisor strategies (one-for-one, one-for-all, rest-for-one), restart intensities, and child specifications to ensure that process failures are handled correctly.
Message ordering defects arise when processes make implicit assumptions about the order in which messages arrive. In the BEAM's concurrent message passing model, ordering guarantees are limited to messages between specific process pairs. The Fix Specialist identifies and corrects assumptions about cross-process message ordering.
ETS table concurrency defects occur when multiple processes access shared ETS tables without appropriate coordination. While ETS provides atomic single-key operations, multi-key operations require explicit serialization. The Fix Specialist identifies patterns where ETS tables are used in ways that violate atomicity requirements.
Hot code reload compatibility defects emerge when code upgrades do not correctly handle state migration between module versions. The Fix Specialist verifies that fixes maintain compatibility with the platform's hot upgrade capabilities.
Quality Gates Integration
Every fix produced by the Fix Specialist must pass the platform's comprehensive quality gates before acceptance. These gates enforce a zero-tolerance standard for code quality.
| Quality Gate | Requirement | Enforcement |
|---|---|---|
| Compilation | Zero warnings with --warnings-as-errors | Blocking |
| Credo strict | All code quality checks pass | Blocking |
| Dialyzer | No type specification violations | Blocking |
| Test suite | All tests pass including new regression tests | Blocking |
| Coverage | Test coverage maintained or improved | Blocking |
| Documentation | Public functions documented with @doc and @spec | Blocking |
Fix Validation Workflow
The complete fix validation workflow ensures end-to-end correctness.
The pre-fix phase captures the baseline state: existing test results, compilation status, and quality metrics. This baseline enables precise measurement of the fix's impact. The fix phase implements the minimal code change and adds regression tests. The verification phase runs the full validation suite and compares results against the baseline. The acceptance phase confirms that all quality gates pass and no regressions are introduced.
The agent maintains a rollback capability at every phase, enabling instant reversion to the pre-fix state if any validation step reveals problems. This safety net supports the doctrine's requirement for decisive action backed by evidence-based confidence.
Integration Architecture
| Component | Relationship | Purpose |
|---|---|---|
| Phoenix Framework | Web layer | LiveView and controller defect resolution |
| Elixir/OTP | Runtime platform | Process, supervision, and concurrency defects |
| Quality Gates | Validation pipeline | Multi-stage fix validation |
| Ecto | Data layer | Schema, changeset, and query defects |
| Telemetry | Monitoring | Fix impact measurement and regression detection |
Related Agents
- code-specialist (L3) - Intelligent code generation with multi-phase requirement refinement providing implementation patterns for complex fixes
- database-specialist (L3) - PostgreSQL expertise for data layer defect diagnosis and resolution
- doc-specialist (L3) - Documentation updates coordinated with fix implementations to keep documentation accurate
Connect & Contribute
Created by Tomáš Korcak (korczis) | Open Source under GHL