Removing repeated wording and correcting a display on the current page can be undone when a later build reproduces the earlier form. The historical request also asked to apply the detail-page change to the template. The task therefore concerned both existing output and the process used to create future pages.
The archive has separate connections for template postprocessing and runtime assets, plus a function that replays completed repairs for an existing site. Editing a generated file and changing its generator can produce the same screen today but behave differently at the next build.
The later template-review records and generator and preview code narrow the inspection sequence: common engine, site copy, build output, then the server’s served path. Comparing those locations identifies the source of the page currently open.
Separate a current-page repair from the next generation
Editing final HTML can make a visible correction quickly. If the inputs and processing remain unchanged, another generation can overwrite it. I first distinguish an input-data issue, a common presentation rule and a site-specific exception. The important question is which process produces the affected output, not merely which line was edited.
The historical guide says new instances receive the common postprocessing and runtime while existing engines and originals are not automatically changed. A future template and a retained project have separate maintenance paths. Correcting the master does not itself prove that every existing website receives the same change.
A new site receives a copy of the engine at creation
The inspected generator copies the required common-engine files into the new project’s .engine folder. The new project’s build command uses code inside that folder. Engine location is resolved from the running module’s file, so a later change to the common source does not automatically change an existing site’s engine.
The guide separates maintaining the common master through synchronization, sealing and checks from applying a change to an existing site. A site-generation test compares transferred common files with their hash record and checks that the maintenance synchronizer is absent from the site engine. I read that test definition without executing it.
If a new build of an existing site still looks old after a common-source correction, compare the engine that site actually uses with the corrected master. Review the required change while preserving site inputs and exceptions. Regenerating the site folder or overwriting its entire engine is not the first remedy.
Connect static cleanup with behavior needed at runtime
An archived build change connects common presentation processing to rendered pages and copies its CSS and JavaScript into the output. Cleanup of repeated text belongs at generation time, while viewport and selection behavior still need runtime code. The structure separates what can be completed before a page opens from what must respond afterward.
The retained patch shows where the build connection was added. Whether the assets reached the output and whether the page loaded them need separate check results. The complete build was not rerun for this article, so the implementation change and its delivered result remain distinct evidence.
Replay only the repairs completed for that existing site
The existing-site replay function reads that site’s technical-checked issues from the ledger and reapplies those rules. It does not import every completed issue from another website. Additional repair branches also use the target site’s recorded state. The previously selected repair scope becomes a condition for the next application.
That function relies on the ledger, so an incorrect completion state can cause incorrect replay. Its presence also does not establish connection to every future build path. The actual generation hook and post-output inspection remain separate requirements. A replay rule and the process that invokes it need their own evidence.
Keep sealing and code checks within their actual scope
The original guide calls for renewing the seal after a master change and running code checks. Sealing identifies the expected files and makes unexpected differences inspectable. Equality with a sealed file is not evidence that the screen is appropriate or the wording factual. The reason for the selected reference needs to remain with it.
Actual historical output records forty passing template checks involving common presentation and material selection. I did not use that number to erase failure in a combined command containing another check; independently successful runs were examined as well. These establish source/build conditions, not pixels on every original customer site. No archived program was executed for this article.
A new build does not retarget an already running preview
The inspected build creates a fresh output directory by default and records its path as output in last-build.json. Unless an output root is specified directly, the preview command reads that record at startup and passes the path to the server. The server finds requested files beneath that root. It does not reread last-build.json on every request to switch to the newest output.
A new build can therefore exist while a running server continues serving the previous directory. The guide explicitly says to stop and restart the preview after rebuilding to view the latest build. Refreshing the browser requests the same address again; it does not establish that the server’s target directory changed.
The synthetic path example below illustrates this relationship. It is not a real site’s execution log or the result of starting a new server. The retained value is the server’s root path, not an in-memory freeze of every file’s contents. Changing a file inside that root can change the file the server reads.
Explore the implementation
Synthetic path relationship; no server executed
project/.engine -> builds/preview-A -> running server
new build -> builds/preview-B
last-build.json -> builds/preview-B
running server -> builds/preview-ALeave the repair location for the next maker
Record whether a change belongs in input data, a shared master, a site exception, postprocessing, runtime or generated output. Retain the pages to inspect after rebuilding and the working features that must remain. The customer can distinguish a present-screen correction from a change carried into future work, and the maker has a precise restart location.
An urgent repair may require editing generated output directly. Record whether the next generation will overwrite it and whether the generator also needs a change. That lets the next person distinguish a one-off screen correction from a repair intended to survive rebuilding.
This code read adds a concrete inspection sequence: the site’s engine, the output path in its latest build record, and the project, port and served path of the actual preview. Compare the expected change in those files before reviewing the screen. This authoring task restarted or changed no existing preview or production server and does not claim to have resolved a customer site’s delivery issue.