When a CLI is the whole product

This was not a single prompt producing a finished tool. It took three build passes and two independent review passes, with each pass assigned a narrower purpose:

• Pass one established the architecture. Ingestion, validation, maintenance rules, scoring, and reporting were separated so that a future validated model could be added without rewriting the rest of the application.
• Pass two turned the working prototype into an installable package. It added version reporting, release artifacts, a setup command, and prominent warnings that the default maintenance intervals are placeholders.
• The first independent review used a separate AI session that had not participated in the build. Its assignment was to distrust the implementation report and try to break the tool. It found two release-blocking defects: one could allow an output command to overwrite an input file, and another could allow a malformed CSV row to be silently misread instead of rejected.
• Pass three corrected those defects and six smaller issues identified during the same review. It also added regression coverage for each correction.
• The targeted re-check tested the corrections using alternate path spellings, filesystem aliases, multiple malformed records, and other boundary cases. The corrections held.

Review and testing do not turn a deterministic rules engine into a predictive model. They do something more modest and immediately useful: make its behavior more dependable, expose its limitations, and catch defects that a single build session may overlook.

The overwrite defect is a good example. The original implementation passed its own tests, but those tests did not try the kind of mistaken output command a tired person might actually enter. A separate reviewer approached the tool with a different objective: find a credible way for it to fail.

The result remains a prototype. Its documentation, terminal output, principal reports, and website identify it accordingly. Its default maintenance intervals are placeholders rather than manufacturer-approved schedules, and it has not been calibrated or validated using representative fleet data.

What it offers is narrower: a consistent and explainable first pass at the question, “What needs human attention first?” Before operational use, its rules would need to be replaced with an organization’s approved maintenance program and reviewed by qualified fleet personnel. Within those limits, it is complete enough to publish for examination, testing, and reuse.

The prototype runs locally with Python 3.12 or later and includes synthetic demonstration data. Windows PowerShell instructions are provided. Its bundled maintenance intervals are examples only and must be replaced and validated before operational use.