This website began with an unusual but effective development loop: describe a change in a Telegram chat, let an OpenClaw-based assistant update the code, push the result to GitHub, and allow GitHub Pages to deploy it. The workflow worked. Our goal was not to replace a successful website or redesign its hosting architecture. It was to move the collaboration layer into Codex while preserving everything that was already reliable.
A Workflow Migration, Not a Rebuild
The first decision was the most important: separate the product from the process used to maintain it. The product is a dependency-free static website built with HTML, CSS, and JavaScript. Its production path is intentionally simple: the public repository's main branch is published through GitHub Pages and connected to our custom domain.
None of that needed to change. Replacing the technology stack merely because the development interface changed would have added risk without creating value. Instead, we kept the hosting, repository, domain, and site structure intact and focused only on making the new working relationship explicit.
Turning Assumptions Into Repository Knowledge
The old process carried useful context, but some of it lived outside the repository. The README referred to deployment notes and an automated social-posting pipeline that were not actually present in the project. That is a warning sign in any handoff: when the documented workflow depends on missing files or external memory, the next operator has to guess.
We closed that gap by documenting the operating model alongside the code:
- Project instructions define the architecture, implementation conventions, validation expectations, and safety boundaries.
- Deployment documentation records the GitHub Pages configuration, local preview process, release steps, and rollback plan.
- A blog publishing checklist captures the repeatable details that are easy to miss, including archive placement and previous/next article navigation.
The result is not just better documentation. It is portable context. A fresh workspace can now understand how the project should be handled without relying on a particular chat history.
Human Control at the Release Boundary
AI-assisted development is most useful when autonomy and authority are clearly separated. In the new workflow, the assistant may inspect files, make requested edits, and test locally. Creating a commit and pushing it to the public repository are separate actions, and each requires an explicit instruction.
That boundary matters because a push to main is also a production release. Treating “edit,” “commit,” and “push” as distinct approvals creates natural review points without slowing down the exploratory work that AI handles well.
Designing for a Public Repository
The migration documentation was reviewed with the same assumption as the website itself: anything committed may become public. We checked for credentials, tokens, private network details, customer information, and unnecessary account data before publishing. The project instructions are public by design, making the rules auditable while keeping sensitive information out of the repository entirely.
We also documented a backout plan before the first migration commit. An unpushed commit cannot affect production. If a pushed change causes a problem, the preferred response is a new git revert commit, local verification, and an explicitly approved push. This preserves history and provides a clear path back to a known-good state.
Proving the New Loop
With the documentation reviewed, we committed it locally, checked the exact staged snapshot, and then pushed only after a separate approval. GitHub Pages completed the deployment successfully, the custom domain continued to respond normally, and the deployed files confirmed that the intended commit reached production.
That small release exercised the complete migrated workflow without changing the customer-facing design. It gave us a low-risk way to prove that local collaboration, version control, deployment, verification, and rollback planning all fit together.
The Practical Lesson
Good workflow migrations preserve what is already dependable and make hidden assumptions visible. The most valuable change was not switching from one AI interface to another. It was converting an informal process into a documented, testable, and reversible operating model.
Our development conversation now happens in a new place, but the principles remain the same: use AI to move quickly, keep people in control of production boundaries, and leave the project easier for the next collaborator to understand.