Bug fix with a regression-test cycle

Case study in full

Reference run — measured values from a released, versioned run.

Stack profile: php-laravel-13 · Data origin: Reference run of Aug 31, 2026 — figures from the run’s frozen usage snapshot, released by the operator. The run’s trace is laid out step by step below. · Measurement period: Aug 31, 2026 (one run, ~24 minutes)

A Laravel audio-processing application normalised loudness in two passes: measure first, then apply. The second FFmpeg pass, however, ran without linear mode — the measurement had no effect and the material sounded “pumped”. The bug was reported as a ticket in the internal tracker; a test capturing it was missing.

Out of scope — not automated: Not automated: classifying the bug as reproducible and relevant remains a human decision, as does approving the fix and its counter-check before the merge.

Prerequisites

• A reproducible bug report described in the tracker.
• A stack profile with the project's existing test commands.
• Guardrails that record a test obligation for bug fixes.
• Approval that the fix including a regression test may be carried out.

Workflow

1. The bug report from the tracker is turned into a plan; stack detection recognises the existing PHP codebase — no foreign scaffold is created, work happens in the existing files.
2. The fix switches the second normalisation pass to linear mode and extracts the filter construction into an independently testable method.
3. A reconciliation step updates the dependent callers in the codebase (six files, including job, controller and Livewire layers).
4. A Pest regression test permanently captures the generated filter graph of the second pass.
5. The result goes out as a pull request to the repository; the ticket surface worked on is deterministically checked against the slice paths.

The trail of the run

1. Ticket

   The reported loudness bug sits in the internal tracker as a reproducible report; a test capturing it is missing.

2. Plan

   The report becomes a plan of three slices; stack detection recognises the existing PHP codebase — work happens in the existing files, no foreign scaffold.

3. Slice 1 — Fix

   The second normalisation pass is switched to linear mode and the filter construction is extracted into an independently testable method. One commit.

4. Slice 2 — Reconciliation

   Dependent callers in the codebase are updated — six files across job, controller and Livewire layers. One commit.

5. Slice 3 — Regression test

   A Pest test permanently captures the generated filter graph of the second pass. One commit.

   tests/Unit/AudioProcessingLoudnormTest.php

6. Pull request

   Three commits go to the repository as a draft; the deterministic surface check reports no missed paths. After ~24 minutes the story stands at “to verify” — acceptance stays with a human.

Result artifacts

• Three commits, all within the PHP codebase: fix, reconciliation, Pest regression test (tests/Unit/AudioProcessingLoudnormTest.php).
• Traceable as a trail: plan, three slices and checks are laid out step by step below; authorised members find the run in the cockpit.
• The ticket surface was hit — the deterministic surface check reported no missed paths.
• After ~24 minutes the story stood at “to verify” — functional acceptance stays with a human.

Key figures

Log in to see your own run and cost details in the cockpit

Synthetic examples on this page are marked as such; reference runs carry measured values from a single, released run. Neither is a promise about the duration, quality or cost of a future run of your own — your own figures appear in the cockpit after logging in, within your own tenant context.