The reviewer reads a change and writes the same report every time. Data & Business Solutions built it because a review that only reads the summary will miss the file, and a scan of the wrong tree will bless the wrong code. This is how the reviewer learned to open the files, scan the right branch, and stop grading one finding twice.
Principal Consultant
In the week of January 19 the consultant set the rules the reviewer still runs on. The review has to open the files. A summary is not the review. The report carries the date of the change, not the date the report was run. It goes into a database that can be searched, not a folder of pages. The security section says what was scanned and what it found.
Two decisions not to build also belong to this seat. In the week of April 27 a third review skill, with several agents exploring in parallel, was considered and not built, because the existing verify step never called the specialist agents already on hand. The gap was the call. Not a new product. The call was wired that same week, on April 29. And in the week of June 8 a newer, more expensive model became an optional second pass on that verify step, not the default, because the comparison against the default was not finished. No winner has been declared.
Business Analyst
In the week of April 6 the analyst wrote down what the automation is for. Every review has the same shape. The security scans run on the change, including when nobody is at the machine. The report is a file that can be handed to someone, and the same result is stored where it can be found later.
In the week of October 5 the analyst added one question the review now asks, once: whether a raw SQL statement is the standard for that area or just the shortest way through this one change. It asks on the first statement the change adds or edits, and it names the other lines. That question does not decide the review.
PMO
Two incidents set the PMO's rules for this project.
In the week of March 2 a review of the harness itself found 18 issues. All 18 fixes went in as one commit, and it broke skills that had been working. The commit was reverted the same day. The rule since then is simple. One fix. Then a real run. Then the next fix.
In the week of April 13 the skill was one file of about a thousand lines, and a lot of it was one project's paths and one team's habits. It was split so the steps stay in one place and the project notes sit beside them. The new skill ran next to the old one, and the report shape stayed the same so the comment step and the approve step did not have to change. A block that had already been turned off came out, so no dead instruction rode along.
Developer
In the week of April 20 the developer found that the branch lookup assumed one folder name. When the author's folder had a different name, the scan fell through to the reviewer's own branch, so the security tools were reading the reviewer's packages and not the author's. The lookup was changed to find the author's folder and to refresh it before the scan.
The refresh those steps named did not exist yet. Every run fell through to a tool that asked someone to sign in, which fails when nobody is sitting there. In the week of April 27 the developer wrote the refresh. It runs with a key and nobody at the keyboard, so the morning scan reads today's code and not whatever was last pulled. The first full pull of a branch took about 7 minutes. The next one, with nothing new, finished in under 2 seconds.
Code Reviewer
In the week of February 16 the review got a short command-line path, the same treatment as the other daily tools, so the morning session sees the summary and does not pull the raw report into the conversation.
In the week of October 5 the reviewer fixed a grading problem in its own rules. A SQL statement written above the data layer is a separate finding, set at Medium. The general rule for a layer violation grades higher. The first draft would have let the same statement be graded both ways, and a higher grade can send a change back. The reviewer did not want that coming out of a finding it had already set lower.
QA
The reviewer is checked by real runs, not by reading it. The March 2 revert is the reason: a change to the reviewer that is not followed by a live run is not trusted. The morning refresh has pulled a branch with nobody sitting there, which is the proof that the unattended path works.
What has not been verified is also on record. The specialist pass has been wired into the verify step since April 29, and not every review carries one. The comparison between the default model and the more expensive one was not finished.
Still open
The steps are split from the project notes, and the morning refresh exists. The specialist pass is wired, and not every review carries one. The second model is optional, and no winner has been picked.