Decompose problems into pipelines of data transformations. Refactors loops into map/filter/reduce chains, converts nested/OO logic into composable function sequences, designs multi-step data transformation pipelines. Trigger on: "transformational programming", "data pipeline", "function pipeline", "pipe operator", "|>", "stream processing", "chained transformations", "Unix pipes", "dataflow", "decompose into steps", "write this as a pipeline", "compose functions", "chain of transformations", or restructuring imperative/OO code into data transforms. NOT for ETL infrastructure or stream processing frameworks (Kafka, Flink) — focuses on code-level function composition and transformation design patterns.
94
97%
Does it follow best practices?
Impact
85%
1.19xAverage score across 3 eval scenarios
Passed
No known issues
A warehouse management system uses the module in inputs/inventory_reporter.js to produce low-stock reports. As the codebase grew, the class accumulated several fields that act as shared intermediate state — rawRecords, parsedItems, lowStockItems, categoryTotals, and skippedCount — all of which are mutated across multiple methods during a single run. This makes the logic hard to reason about: calling methods out of order corrupts the results, and adding new report variants means copying the entire class.
The engineering team wants the module rewritten as a proper data transformation pipeline in JavaScript. The new version should cover the same logical stages — loading, parsing, filtering, aggregating, and building the report — structured so that adding a new report variant does not require copying the whole module.
Produce a file named inventory_pipeline.js containing the refactored pipeline implementation. Also produce a file named pipeline_analysis.md that documents how you decomposed the problem into a pipeline and explains the data flow through each stage.
The refactored module should expose a top-level function (e.g. generateReport(records, threshold)) that composes the individual stages and returns the same report shape as the original run() method. Keep the existing report structure (fields: generatedAt, skippedRecords, totalLowStock, byCategory, items).