Building Alias Archive: Multi-Agent Collaboration, Astro Migration, and Static Delivery

Alias Archive began as a very thin personal-site skeleton. It contained no résumé, school, location, employment history, or contact address, and it was not meant to make “who I am” the protagonist of the home page. Its subject was the work itself: questions under study, playable experiments, sound production, and material that should not be forced into the first three groups.

That boundary was established early: this is an anonymous creative archive, not a personal profile. The home page, navigation, content model, and deployment strategy therefore organise how work is encountered rather than how the author is introduced.

The site now holds long-form posts, research series, development records, image groups, audio, video, explanatory SVGs, and a browser combat demo extracted from a Godot project. English, Chinese, and Japanese share slugs and relationships. The output is still a set of static files that can be published on another host by rebuilding and changing DNS.

This is an account of how a growing archive retained one identity through repeated content deliveries, interface revisions, and a framework migration.

Define what the site will not contain

Personal sites commonly begin with a portrait, a biography, education, location, and contact details. Alias Archive deliberately did not. The absence is not temporary missing content; anonymity is part of the product definition.

Four primary fields remain:

• Research—questions, reading, methods, and working notes;
• Games—project records, combat systems, asset pipelines, and playable studies;
• Music—finished pieces, production processes, arrangement, and sound work;
• Other—moving image, photography, websites, AI workflows, and material that does not belong elsewhere.

These are not four identity badges. They are four independently maintained entrances into an archive. The home page helps a visitor choose a path before it asks them to know anything about the author.

Why the initial stack became the wrong size

The early build used Next.js 16, vinext, and a Cloudflare Workers-oriented setup. It also reserved D1 and Tailwind even though neither was serving the actual product. The stack could run, but it solved a larger problem than the site had: content came from local files, while only filtering, disclosure controls, media launchers, and the game demo required client state. There was no login, commerce, database query, or server-rendering requirement.

The mismatch created friction:

• a static archive inherited compatibility and runtime concepts it did not need;
• unused database and styling configuration implied systems that did not exist;
• the intended deployment target and the adapter path were not aligned;
• content and visual integrity were critical, yet runtime details consumed disproportionate attention.

The migration goal was therefore not to adopt a fashionable framework. It was to make architecture match behaviour: Astro generates the static site, React remains only where state is useful, and Cloudflare Pages publishes dist directly.

Migration as preservation, not redesign

The migration took place on a separate astro-migration branch while the runnable main branch remained available for comparison. The source of truth was the actual working tree, not the latest clean commit. Uncommitted fonts and game and music content were part of the product and could not be erased in the name of a tidy migration.

Four constraints protected the work:

1. Move the visual system unchanged first—global CSS, paper texture, drafting grid, and semantic gold and teal;
2. Preserve trilingual content before editing it;
3. Keep routes stable—English at the root, Chinese and Japanese under /zh/ and /ja/;
4. Run old and new versions in parallel before deciding what to remove.

After parity was established, unused Tailwind and D1 configuration was removed. Source Han Serif, Source Han Sans, EB Garamond, and Courier Prime remained; X Typewriter was added as self-hosted WOFF2. The full English interface uses X Typewriter for its monospaced layer, while English fragments inside Chinese and Japanese layouts use the earlier stack to avoid making the game-like typeface dominate languages it was not chosen for.

The repository as an interface between agents

The content was never produced by a single continuous session. Research, game development, music, moving image, and web production had their own agents or Claude sessions. Codex handled integration, translation, frontend work, testing, Git, and deployment. The owner set disclosure boundaries, reviewed the actual result, and made final decisions.

Chat history is a weak long-term integration layer. The reusable solution was to make the repository itself the interface.

A useful delivery package contains:

• Markdown with complete frontmatter;
• assets with fixed names and target paths;
• a README stating insertion points, credits, public boundaries, and acceptance criteria;
• series order, related posts, and locale requirements;
• a distinction between editable material and content that must remain exact.

Integration means more than copying a post. Codex checks the schema, slug, asset URLs, translated siblings, relationships, sorting, and responsive behaviour. In this project, a README functions as a lightweight API: it converts hidden decisions from one session into inputs that another session can verify.

The content contract

Astro Content Collections gives every post a common schema. Beyond title and date, each entry carries:

• category—games, research, music, or other; its primary home;
• tags—free secondary labels;
• series and seriesOrder—a deliberate reading sequence;
• related—curated connections between posts;
• abstract—a fuller overview used by expanded or hovered list entries;
• draft—whether the item enters public lists;
• locale and a shared slug—the identity that binds the three language versions.

Category and tags coexist intentionally. Category answers “where does this primarily belong?” Tags answer “what else does it touch?” The former makes an all-posts index legible; the latter preserves the actual overlap between disciplines.

Research adds a second level: four series act as reading routes over eighteen posts. The page begins with all records; selecting a series narrows the list. Desktop uses large route cards and compact entries to establish hierarchy. Mobile avoids a previous conflict in which tapping a card both expanded its description and scrolled that newly expanded description out of view.

Localization is not two mechanical translations of Chinese. Titles, abstracts, body copy, diagram text, and interface labels are authored per language. Build tests check that each public slug has English, Chinese, and Japanese siblings. English entries generate the default routes, so a missing English sibling can prevent the route itself from existing—one reason local review cannot rely on an isolated Chinese file.

From a visual mood to a working system

The visual direction began with a black field, fine gold drafting lines, paper grain, and four abstract panels. It sat somewhere between an archive, a measuring instrument, an old technical manual, and stage documentation. The site inherited that language: a dark canvas, a faint grid, restrained gold, research teal, serif display type, and monospaced technical labels.

Style alone did not guarantee hierarchy. As the site grew, several problems appeared:

• display headings became too large while technical labels became too small;
• Chinese and Japanese felt compressed when they inherited English spacing;
• home cards, field hero cards, and list entries competed at similar scale;
• framed category tags sat off the text baseline;
• nested mobile scroll areas trapped the page at their top or bottom;
• a research filter changed the list below the fold, leaving users unsure whether the tap had worked.

The later use of the Impeccable skill did not replace the archive’s established taste. It made that taste operational. PRODUCT.md and DESIGN.md were used to state content hierarchy and visual grammar; real pages were then checked for responsive behaviour, accessibility, type scale, hover feedback, scroll mechanics, and state distinction. Impeccable acted as a design-system calibration, not as a skin generator.

The result retains the archive mood while reducing decorative noise. Cards do not all glow to signal importance; scale, spacing, numbering, rules, and expanded content establish hierarchy. Mobile interactions prioritise visible consequences. Chinese and Japanese use their own heading scale and rhythm. Long English prose remains in a reading face rather than extending X Typewriter across the entire article.

A static shell can still contain rich media

The archive now includes several kinds of media:

• SVG process diagrams, QC filmstrips, and colour comparisons in the MV article;
• audio and production material in music records;
• video in the AI presenter workflow, without autoplay;
• a Godot Web combat demo on the Games page, with no engine installation required;
• large images and captions in visual records.

The policy is to start expensive media on demand. Video exposes controls and a poster rather than taking sound and bandwidth on arrival. The Godot demo first shows a site-native launcher and progress state, and downloads the Web package only after the visitor chooses to run it. The surrounding document remains indexable, readable static HTML.

This is where Astro fits well: most pages are complete at build time, while filters, disclosures, launchers, and games receive local client state. Static delivery does not mean the site cannot do anything; it means unnecessary code does not run by default.

Failures became rules

Many of the project’s durable rules came from concrete failures:

Symptom	Cause	Rule that followed
localhost did not reflect a change	The preview had stopped or served an old build	Build, restart, then inspect the real route in a browser
A post appeared to disappear	Draft filtering excluded it from lists	Make review visibility explicit, then reconfirm before release
Chinese titles read like social-video headlines	Information was wrapped in promotional phrasing	Use formal, compact titles built from subject and action
Research and Other tags looked alike	Their semantic hues were too close	Separate category colour and preserve a shared baseline without frames
A mobile filter seemed unresponsive	The changed result was below the viewport	Scroll only when appropriate and avoid fighting expanded content
The page stopped scrolling at a list boundary	A nested scroll chain captured the gesture	Prefer the document’s natural flow for long lists
The Godot demo ran but felt unlike the game	Generic approximations replaced the game’s contracts	Calibrate animation, collision, poise, range, and timing against the source project

These issues appear unrelated, but they share one cause: approximating the real state too loosely. A page is not complete because it looks similar, and an interaction is not complete because an event fired.

Release as a repeatable loop

Every content delivery follows the same path to production:

1. Review the package and its disclosure boundaries;
2. Integrate assets, frontmatter, and all language siblings;
3. Update relationships, series, sorting, and list behaviour;
4. Run content tests and the production build;
5. Inspect the English root route and the Chinese and Japanese prefixed routes;
6. Check desktop and mobile dimensions;
7. Let the owner review the local site;
8. Commit, push, and allow Cloudflare Pages to publish.

Testing goes beyond TypeScript. The project checks trilingual coverage for public slugs, expected content statistics and data hashes, generated static routes, and required assets. Visual behaviour still requires a browser: snapshots cannot substitute for scrolling, hover, focus, and real font loading.

Cloudflare Pages and portability

The production boundary is Astro’s static output. A Node.js 22.13-or-newer environment runs pnpm build; the result goes to dist, and Cloudflare Pages publishes that directory. Astro 7’s Cloudflare adapter targets Workers, so the project does not add an adapter that does not match the chosen Pages deployment.

The custom apex domain is canonical. www and the pages.dev address redirect to it while preserving path and query. robots.txt, the sitemap, the 404 page, and trilingual routes are build outputs. There is no essential database that cannot be exported. Moving hosts would mean publishing the same dist elsewhere and changing DNS.

That restraint matches the privacy boundary. The site does not create contact collection or a comment backend before it has a purpose for them. The blog structure exists, but new runtime features are added only when the content requires them.

Conclusion: build an archive that can keep growing

The difficult part of Alias Archive was not making one attractive home page. It was ensuring that every new post, language, medium, and interaction still belonged to the same system. That requires several layers of constraint: a product boundary defines what not to build; a content contract defines how material enters; a design system defines how interface change remains coherent; tests and local review define when a release is ready.

Frameworks will change and more agents will participate. The durable method is simpler: write decisions into the repository, keep control with the owner, and make every increment testable, reversible, and portable.