The first drafts were too long

Three approved posts expose chronology, verification, and writing-style assumptions that the new blog workflow did not yet know to question.

The blog-writing machine survived its first three posts, but the prose it produced was too long, too granular, and too willing to reveal what happened next. None of those drafts needed line edits before publication. The correction arrived one level above them: individual posts were acceptable, while the system was consistently producing the wrong shape.

The first rule arrived during review#

The first draft immediately forced a chronology decision. A post written in July about work from April could carry the date it was drafted, or the date of the history it narrated. I chose the latter, so a reader sees the development in order and cannot tell which posts were backfilled. The registry keeps the real writing date for process history; the post keeps the final commit’s date for publication history.

Verification includes the workshop#

Publishing also exposed a gap in the devcontainer. The browser checks could not faithfully load the deployed blog or its typography, and the first firewall correction disappeared when a periodic refresh restored the older configuration. The fix mattered less than the working rule it produced: when a verification environment blocks a required host, name that constraint, update the maintained configuration, and restart from a recorded handoff instead of finding an invisible route around it.

A clean review can still reveal a pattern#

All three posts merged without author edits, then the shared problem became obvious. Each technical detail had earned its own paragraph, the prose arrived as an unbroken wall, and the closing paragraphs used knowledge that only a backfill author could have. I froze the cadence before a fourth draft could repeat the pattern and wrote the missing requirements down: four to six prose paragraphs, headers and structural elements where they earn their place, detail reserved for evidence, and no foresight beyond the post’s date.

A draft can need no line edits and still show that the system is producing the wrong shape.

Calibrate the rule against the work#

A style guide alone could describe a plausible result without proving it could produce one, so it was reviewed beside a full rewrite of the first post. That pairing corrected the guide in contact with real content: outcomes replaced inventories, code blocks stayed minimal, diagrams had to remain readable, and accessibility became a build-time gate rather than an editorial reminder. The skill now reads those structural rules before drafting and checks them again after security review. With the freeze lifted, the next backfill cluster can test whether the lesson transfers beyond the three posts that taught it.