\r \r

Role\r

\r This skill designs the data side of unit-level regression protection. It focuses on fixtures, edge-case input matrices, and deterministic reproduction data that makes logic regressions visible and maintainable.\r \r

When To Use\r

\r

• Use for fixture design, data providers, edge-case matrices, and regression input preparation.\r
• Use for keywords such as fixture, test data, regression case, boundary case, dataset, and reproducible input.\r
• Use when the main risk is not missing the assertion structure, but missing the right test inputs.\r \r

Source Material\r

\r

• AI-ENTRY.md\r
• CLAUDE.md\r
• dev/ai/skills/testing/SKILL.md\r
• dev/ai/skills/community-module/SKILLS-CONSOLIDATED.md\r
• dev/ai/skills/php84-performance/SKILL.md\r \r

Responsibilities\r

\r

• Build stable and realistic test inputs for changed logic.\r
• Cover null safety, boundary values, invalid shapes, and historical regression patterns.\r
• Keep test data readable and close to the business rule being protected.\r
• Reduce flakiness by removing unnecessary dependence on ambient state.\r \r

Workflow\r

\r

1. Read the defect or feature behavior and identify the minimum input combinations that matter.\r
2. Convert known bugs and edge conditions into explicit datasets or fixtures.\r
3. Add null, empty, duplicate, and invalid-shape cases where the code path warrants them.\r
4. Keep test data local, named, and understandable.\r
5. Run the focused unit suite and confirm the regression inputs behave as expected.\r
6. Remove redundant datasets that do not increase defect detection value.\r
7. Document the key regression scenario in the test naming or comments if needed.\r \r

Weline Rules\r

\r

• Prefer small, isolated, testable changes.\r
• Provide unit test evidence where relevant.\r
• Follow PHP null-safety expectations when building regression cases.\r
• Keep module boundaries intact when preparing fixtures or collaborators.\r \r

Inputs Required\r

\r

• The changed logic and known failure modes.\r
• Historical bug symptoms, edge cases, or stack-trace triggers.\r
• Existing fixture style in the target module.\r
• Focused unit-test command for verification.\r \r

Expected Output\r

\r

• Focused datasets or fixtures that reproduce meaningful edge cases.\r
• Updated regression coverage with clear input intent.\r
• Evidence that the new datasets pass after the fix and protect the failure mode.\r \r

Validation\r

\r

• Run focused unit tests that consume the new datasets or fixtures.\r
• Confirm the added cases cover meaningful branches or prior bugs.\r
• Confirm no dataset depends on unrelated mutable global state.\r
• Confirm fixture complexity stays justified by risk.\r \r

Constraints\r

\r

• Do not add bulky generic fixtures that hide the real regression case.\r
• Do not depend on random values or time-sensitive data without control.\r
• Do not create test data that crosses module boundaries without a strong reason.\r
• Do not duplicate many near-identical datasets when one explicit case is enough.\r \r