The PERIOD Code page passed checks I needed, and I still wasn’t willing to accept the presentation. The useful part came after the corrections, when the page I accepted became a standard the next book could be measured against.
The First Version Still Looked Like an Article
On October 11, 2026, I converted the existing PERIOD Code page into a public overview and sample page for the published book. The complete work was available in paperback and Kindle. The website needed to introduce it clearly, keep useful framework material accessible, offer an original excerpt, and give readers an obvious way to reach the book.
That page already had a history. Other articles linked to it. Its section addresses could exist in somebody’s bookmarks or an outside link. Changing its purpose did not give the implementation permission to discard those connections. The existing page identity, address, title, historical anchors, and intended links needed to survive, along with the approved excerpt.
The initial publication preserved all eleven historical anchors and matched the original excerpt’s sixty-seven paragraphs against the approved source. The purchase links pointed to the intended destination. The page loaded, and a mobile browser check found no horizontal overflow. Those were useful results.
The presentation still looked too much like a long article with a small book cover. Having the right information somewhere on the page had not created the book overview I wanted. The opening needed to establish what the book was and how someone could get it, while giving the free framework explanation its own readable place.
A dedicated visual pass added a more deliberate opening layout, section navigation, an excerpt treatment, and a closing purchase panel. Its report recorded twenty out of twenty targeted checks passing and described the visual pass as complete. My review still produced more work.
On mobile, I wanted the purchase information and first button before the cover. I also wanted the cream background confined to the short excerpt introduction, with the manuscript itself on the normal white reading background. Both changes were made without rewriting the approved prose.
Even that correction was not one smooth operation. An attempted split edit failed WordPress block validation. The partial layout change was rolled back before the correction continued safely. The record contains successful checks, further review, a rejected implementation attempt, and more corrections. Calling one of those earlier passes complete had not made the presentation accepted.
The Markup Said Centered
The cover provided a particularly clear example. WordPress already had an alignment instruction, aligncenter, saying the image should be centered. Under the Proof theme running on my site, the cover still sat toward the left of its column.
The instruction existed. The intended result did not.
A check that searched the markup for the alignment setting could have found exactly what it expected. That would establish that the setting was present. It would not establish where the browser actually placed the image.
The correction kept the native WordPress alignment and added explicit automatic margins on the left and right of the image’s container. Then browser measurements compared the center of the displayed cover with the center of its containing column. The final results recorded zero centering error on desktop and at both tested mobile widths.
The measurements confirmed the correction. Those results would become one part of the evidence for the accepted presentation, alongside its reading order, excerpt treatment, and purchase layout.
I have covered the wider process in How I Actually Build Software With AI. This job gave it a concrete reference: a finished page with several decisions worth carrying into the next book.
The Screenshot Needed Questioning Too
The same job also exposed the reverse problem. A headless browser, running automatically to inspect and capture the page, produced a view in which the site navigation appeared open over the content. The early report treated that as a possible separate navigation issue.
I checked the actual site. The menu behaved normally.
That observation mattered because changing the theme to satisfy the screenshot would have expanded a book-page job into sitewide navigation work without establishing a real navigation defect. A screenshot was evidence worth investigating. It was not enough by itself to justify the change.
The later evidence capture accounted for the discrepancy. The menu was hidden only inside the temporary headless capture session, and that adjustment was documented. The live theme and navigation were left alone. Those pictures could help us inspect the book presentation, but they were not evidence that the menu itself had been tested by those captures.
This belonged in the standard too. The cover problem showed why the browser’s output had to be checked against the markup’s claim. The menu problem showed why an automated view still needed interpretation. I needed to understand what each piece of evidence could establish before deciding what should change.
Acceptance Became Three Separate Answers
Once the remaining details were corrected and I accepted the page, I wanted the next book’s completion record to be clearer than the reports we had just worked through. The reusable acceptance template now separates three decisions.
Technical integrity covers the implementation and its protected content. Is the page structurally valid? Did the correct text survive? Are its identity, links, and historical anchors intact? Does the cover load, and are the purchase destinations correct?
Visual/browser acceptance covers the rendered presentation. Is the cover centered where it belongs? Does the mobile order follow the accepted layout? Is the excerpt readable in its intended treatment? Does the closing button have the required space below it?
Human acceptance records my decision about the result as a whole. Am I willing to put my name on this presentation? Does it accomplish what I wanted this particular page to do? That answer can still be revisions requested, even when earlier checks pass.
These are different questions, and some of the browser questions can be answered automatically. The distinction is not simply a machine doing one stage and a person doing another. It is keeping the claims separate so a successful result in one field does not silently fill in the others.
My approval cannot excuse a damaged excerpt or a broken historical link either. Looking right would not make those failures acceptable. The final process needs the technical evidence, the browser evidence, and my decision. The acceptance form gives each one a place instead of compressing everything into a single word.
I Wanted More Than a Page I Liked
The accepted PERIOD Code page became the golden reference for a new Core Framework Book Publishing Standard. I wanted the design we had settled to survive the conversation, so the next book page could start from something I had actually approved.
A link to the live page was not enough because that page could change. We kept the accepted WordPress source, a checksum identifying its exact contents, screenshots, browser measurements, and the design rules under version 1.0. The next execution would have a fixed reference instead of a moving target.
The screenshots came from the actual public page. They covered the desktop opening and full page, mobile views, the cover, the excerpt, section navigation, and the final purchase area. The capture record identified the browser dimensions and disclosed the temporary navigation adjustment. That made the conditions behind the pictures part of the evidence.
The measurements made several decisions much less vague. The final note below the purchase button had a twenty-four-pixel gap. The cover had a recorded centering error of zero. The page had no horizontal overflow at a desktop width of 1,365 pixels and mobile widths of 390 and 360 pixels.
Those measurements do not guarantee a good page. They tell the next execution what centered and properly spaced mean for this particular layout, with a small allowed tolerance.
The preserved capture script went beyond taking pictures. It included automatic checks for overflow, a loaded cover, cover centering, the gap below the final button, and the historical anchor inventory. The same visual details that had required correction were now conditions the verification could examine directly.
Other decisions became explicit layout rules. On mobile, the opening copy and purchase button come before the cover. The cream treatment belongs around the short excerpt introduction. The manuscript sample stays on the normal reading background. The final purchase area has its own space and purpose.
Before those rules were recorded, another execution could have produced a valid page that still needed the same corrections. Now it has the approved layout and measurable checks to use from the start.
I have written about project records carrying useful knowledge into later AI work. This added a specific kind of reference: a finished page whose accepted qualities were recorded for a family of pages that had not yet gone through the same process.
The page and the standard now had different jobs. The page introduced one book to readers. The standard told future work which presentation decisions had been settled, how to check them, and which decisions still belonged to me.
The Next Book Still Needs Its Own Evidence
A reusable design does not relieve the next execution of understanding the next book. That was another decision the standard needed to make explicit.
The PERIOD Code has its own cover, purchase destination, excerpt, section structure, and historical links. Its eleven original anchors are an inventory to preserve on that page. They are not a requirement to invent eleven anchors for every other book. The same applies to its excerpt length and paragraph count.
For another framework, the work begins by reading that page and its newest approved source. Its existing links have to be understood. Its sample has to match its own manuscript. Its purchase buttons need the right destination. The shared presentation gives that material a tested arrangement, but the material still needs its own verification.
The acceptance template reflects that distinction. It provides places to record the book, sources, preserved page identity, links, excerpt checks, screenshots, measurements, and final decisions. It is a form for doing the next job properly, not a completed certificate that can be copied from PERIOD.
The reference also has a version. The accepted evidence is preserved under v1.0. If I later change the shared design, that change needs its own accepted version and explanation. Quietly replacing the old reference would make it harder to understand what earlier work had actually followed.
A particular book can also need a justified exception. That should be recorded for that book rather than silently becoming the new rule for everything. Standardizing the presentation should reduce repeated guesswork while leaving room for an actual difference in the work.
Generating the Page Was One Part of the Job
This is why “vibe coding” feels incomplete as a description of how I work. AI did substantial implementation work here. It helped produce and change the WordPress structure, run checks, measure the browser output, preserve evidence, and write the standard.
But the implementation was only part of what happened. I defined the page’s purpose and what needed to survive. I reviewed the result, required corrections, distinguished a real alignment problem from an apparent navigation problem, and decided which finished presentation to accept. Then I wanted that acceptance to guide the next book.
An implementation can be generated again. A settled product decision should not have to be guessed again because nobody bothered to preserve what was accepted and why.
The Next PASS Has a Clearer Meaning
For the next book, the accepted layout is no longer just something I can point at. It has measurements and checks that show whether the new page follows it.
If a future page differs, I can ask whether it failed a requirement, needs a justified exception, or calls for a new accepted version. I do not have to reconstruct every decision from an old conversation.
I still make the final call. But the next page should arrive with its content verified, its layout measured, and any exception explained. I do not want to spend another review rediscovering a standard I already approved.
New Here?
Read Next:
- I Used AI to Turn My Website Into a Published Book Without Rewriting It
- Why I Make AI Review Before It Rewrites
- How I Move Google Docs Into WordPress With ChatGPT