Building Zwikipedia

I wanted a place where an article about something I had made could be as long as it needed to be. Some projects need a paragraph. Others have a story involving a website, a physical object, an experiment with AI, and several occasions when the original plan stopped being useful.1

I also wanted articles about the fictional ideas connected to those projects: an encyclopedia from an alternate universe, where a band could have a discography and a university could have a history. And I wanted room for anything else I felt like writing about because it sounded interesting.1

That combination became Zwikipedia.

A portfolio you can explore

A résumé can say, “Sisters Erie: Created a fictional band with a website and music using AI, including ChatGPT and Suno.” That gives someone a description of the project. It leaves most of the work outside the sentence.8

Here, I can give the process several pages: the problems I ran into, the choices I made, why I made them, and the technology used to put the result together. Someone can examine the band, website, images, stories, and music while following the account of how they developed.8

The writing is part of that portfolio too. I want it to be interesting enough that a person reads about the work because the story holds their attention. They can see the result in detail and understand more of the thought and skill that went into it.1 8

Several kinds of article under one roof

The collection brings together very different subjects. Atypical Alchemist is a real collection and a website. Arcana University is fictional. Sisters Erie are fictional musicians, but the work of developing their stories, images, and music is real.2

That last distinction becomes especially useful when a project grows. The Sisters' Beat the Sunrise belongs in their fictional 2016 discography. The music I am developing belongs to the actual work happening in 2026. Each history can be interesting on its own, and linking them gives the reader more to explore.3

The site therefore needs room for an encyclopedia article and a making-of story. The first can describe a band performing at Katie's Pub. The second can explain that I began by designing a tour tee-shirt, then needed dates for its back, then kept going until the band had outgrown the back of the shirt.3

From a homepage to articles

The application began with a Laravel homepage and grew into database-backed articles. Laravel provides the server-side framework; shared Blade templates give the pages a consistent structure. The article records hold their text, revisions, sources, and published selections instead of requiring a separate hand-built page for every subject.4

That structure matters once the writing becomes substantial. Changing the wording of an article should be an editorial task. Adding a source or correcting a detail should not require redesigning the site around it.

The first article set established the basic routes and the distinction between fictional subjects and real-world accounts. Its brief introductions were enough to demonstrate that the pages worked. They were much less successful at explaining why someone would want to read them.4 5

That has become part of building Zwikipedia too: replacing the scaffolding with articles worth spending time with.

Making room for the writing

The visual direction uses navy, antique gold, parchment, serif type, and a stack of books. The intention in the recorded design work is a reference publication with the warmth of an old library. The page needs to support a long read while still letting someone find a particular section.4

The article layouts developed through desktop, tablet, and mobile review. Shared elements include the title, contents navigation, body text, figures where useful, related reading, and sources. A musician's profile and a technical case study can use the same visual language without needing the same internal structure.4

The contents control has a practical job. A reader arriving at a long song article may want its history, its full lyric, or the context around a particular claim. Someone visiting a software article may want the origin story or the explanation of one feature. The page should make those routes easier to find.

The editorial system

The writing can be developed with AI without making every generated paragraph public immediately. The implemented workflow keeps incoming proposals separate from the canonical article collection. A selected proposal is checked and imported into the private editor; review and publication are later steps.6

Revisions preserve what came before. The public article uses a specifically published revision, while the editor retains drafts and the review history. The final publishing step requires my authenticator code.6

That gives me room to work on the text. A draft can be rewritten after I add context, and an accepted article can receive another revision when I find a photograph, remember an important detail, or get useful editorial notes. The published page does not have to be the end of the process.1

Working with AI, and giving it something worth rewriting

The first versions of the real-world project articles were too basic. The older public portfolio could establish that a project existed, but it did not contain everything that had happened since or explain why the project had mattered to me.1

Adding context made a substantial difference. Pet Savers became the story of making a website for my mother's rescue organization, adapting it so other people could maintain it, struggling with a later rebuild, and eventually using AI to build again. Carbs of the Huge Manatee gained the physical decks, the near-ten-thousand-dollar order, the cease-and-desist timing, the early failed online attempts, and the later breakthrough.2

Those details gave the articles their subjects. The technology could then be explained through what it enabled and where it had been difficult.

The useful pattern is becoming clear: make a draft, add my context, rewrite, and edit. I want the result to be interesting and fun, to show the work and skill that are actually there, and to avoid inventing a more impressive history than the one that happened.1

Keeping the work coherent

Zwikipedia is also built within the ZDP Development Protocol, the method that developed across my AI-assisted projects. The repository holds code and technical decisions; ZPI holds tickets and project workflow. The method is intended to keep decisions recoverable and progress understandable when the work moves between sessions and tools.7

For the public site, that work appears in ordinary things a reader can use: article links, source references, a responsive page, and a route from a fictional subject to its creation account. The underlying records matter when something needs to be checked, corrected, or improved.

Building the collection itself

The application and the articles are developing together. A long manuscript reveals things a short starter page cannot: whether headings are useful, whether the source notes are overwhelming, whether a photograph has enough context, or whether two parts of the publishing system are displaying the same section twice.5

The collection made that last problem visible: source disclosures supplied by both the manuscript and the template appeared twice. Consolidating them gave readers one place to find the references, and the next editing pass exposed a related problem: useful citations were mixed with internal editorial notes.5

That is a small example of the wider process. Zwikipedia becomes a better place for the work as more of the actual work is put into it. There are articles to improve, stories to recover, and projects that deserve more space than their old portfolio captions gave them.