A broad review needs an outline, but a complete outline does not mean every item was executed and verified. Revisiting Northstar's eighteen-layer review, I treat the connection between questions and evidence as a production method in its own right.
Map the layers that actually exist
Northstar is a desktop app connecting renderer, Electron main and workers, local storage, MCP, Python and external sites. The outline covers requirements, UI, IPC, project runtime, observation/input, accounts, executors, scheduling, storage/files, performance and distribution. It does not assume a cloud application server that does not exist.
Each layer records its role, relevant code, existing execution evidence and unverified scope. A source file's existence is not proof that its feature succeeded. Connecting implementation and observation distinguishes a useful outline from a wide list of names. Planned capabilities must remain separate from current ones so the next reviewer has an honest starting point.
Retain evidence versions and what was newly done
The 0.1.166 review reused earlier regression, project-execution and UI records with their versions. It did not rerun the entire suite merely to obtain the outline judgment. A test can appear under several layers, so layer counts are explicitly not added as independent totals.
Historical UI use does not newly verify latest-build accessibility, high magnification or every Korean IME flow. Python environment separation does not become an OS security sandbox. Notes prevent success in one column from filling a gap in another. Later correction documents also need reading when discussing the current product, so historical judgment keeps its proper time boundary.
Use generated judgment to choose the next question
The model classified five layers as evidence-supported and thirteen as partially supported, with an overall need for more evidence. It found no major outline omission while explicitly denying universal complete verification. Those categories are not a pass rate, accuracy or probability.
The proposed priority concerned interruption/restart after submission but before verification, with non-replay and retained source/peer work. That is a suggested experiment, not proof it was already performed. Generated judgment cannot replace reading actual inputs, responses, code and reproduction evidence. A sentence saying the model approved is insufficient to conclude a release decision.
Check units inside the judgment against original evidence
A stored model reason can be read as fifteen actual projects. The project-isolation result instead contains fifteen checks, and its test code targets specified project contexts. Publishing a check count as a project count would transfer a unit error from generated summary into the article.
I use the result file and assertions to restore the unit in public prose. Merely reading a report does not replace that comparison. Follow a table's number back to its subjects and conditions. Even a specific-sounding model explanation can change a factual unit. I correct the content claim without rewriting the original development record, preserving the evidence of how the discrepancy arose.
A whole-system account includes its remaining boundaries
Later records add local scheduling, shutdown and Gemini fixes with separate reviews. One outline cannot verify every later version. Changed layers, neighboring callers and actual failure transitions must be connected again. Completeness means making gaps visible rather than erasing them.
For this article I read the existing outline, response, results and tests without a new model call or full original-suite execution. The shared failure lab checks only its small synthetic boundary. Useful maker knowledge explains which evidence supported which judgment and what needs checking next. That connection enables another person to continue verification more effectively than a universal promise of perfection.