What I built. How I learned to build it.

01 / Start here

I did not just make apps. I made ways to think.

A browser instrument, a game, a hero and a film might look like unrelated projects. For me, they share a question: can I use AI to make something I care about, understand why it works, and leave enough behind to keep improving it?

Chirp's Summary of Approach records the early nine-day AVIARY build, June 29–July 7. A single-deck player became a two-deck DJ instrument, then a family of musical tools. The motivations were wider than coding: practice planning, return to DJ culture and Carnatic percussion, explore synthesis, and reconnect with birds and nature photography.

The design principles were not invented after the screens. “Computers and the forest” paired systems rigor with living resonance. Stewardship meant preserving source material and making the next session easier. Those principles shaped the names, controls, themes and documentation.

This guide follows the work between the idea and the result

The interesting part is often the thing that is not the finished product: a signal graph, a data model, a design bay, a rough body, a reference sheet, a beat sheet, a simulation or a checking tool. Each lets me see something I could not see before.

How to read it: follow a case study, then use its “Try it” question on your own project. The exercises and example briefs are suggestions for the reader, not a claim that every project followed them.

A first-person editorial retelling, not a verbatim memoir. Project results are attributed to their records, not rerun here. “Models” means working representations and prototypes—not AI models I trained. Basis: C1, B1.

02 / What I made

A workshop of experiences, engines and working tools

A repo is a container, not a useful description of a creation. The collection contains at least three layers: things to experience, machinery that makes them possible, and tools that help me develop them.

These are not all finished products. A working instrument, a useful factory, a prototype game and an unfinished film can all be real accomplishments while being at different stages.

The distinction matters for reuse. A game's hero is its IP; the sprite factory may help another game. A landscape is an output; a seeded painter is an engine. A review page is not the product, but it can make the next product easier to judge.

Basis: C1–C4, H1–H3, S1–S5, B2–B3. The wider portfolio is context, not a new priority ranking.

03 / Design thinking · discover and define

Start with a moment, not a feature list

“Make a music app” leaves almost every important decision open. Who is using it? What are they trying to hear or do? What makes the current way awkward? A clear moment gives AI something more useful than a broad category.

Bestiary's ways of working already connect the build process to design thinking: start human-centred, explore different directions, build to think and test to learn. It also records a weakness: research can accumulate without becoming a clear problem statement. More material is not the same as a better definition.

Turn observation into a design question

Separate what I know, what I assume and what I need to learn. Spend time with the old way: watch a player without coaching, listen to a track through the current controls, or use your own tool for a week. A solo creator can be the first user, but that is not evidence of wider demand.

A worked example—not a claim of completed user research

Observation from the records: Rookery's meters could be mathematically active but unreadable, or use only the bottom of their scale on real music. Interpretation: drawing a signal is not enough; the display must fit the material and the viewing size. Design question: how might a listener see meaningful changes without learning the raw analysis machinery?

That question suggests a focused test: play the same material through the old and revised meter, compare usable range and label readability at a small size, and ask whether the listener can notice the change. It does not immediately justify a whole new dashboard.

Three lenses before investing

Wanted: whose need does this serve? Possible: what small test shows it can run? Sustainable: can I maintain it, afford its tools and use its assets legitimately? A blank answer is an uncertainty to investigate, not a box to quietly tick.

Basis: B1, C3. Discover/Define framing: Design Council; prototype/test framing: Stanford d.school. This is an iterative lens, not a certification or a claim of fleet-wide adoption.

04 / Design thinking · explore and choose

Make different answers before polishing one

AI can produce many variations very quickly. But five colourways of the same layout are not five ideas. SaffronRider's concept-to-production process calls for three or four genuinely different directions, judged before a direction is locked.

Give the exploration a boundary

A useful brief contains a person, an intended feeling, a mechanical job and a NOT-list. For a musical instrument, “playful” might mean controls that invite experimentation, while “not a tutorial wizard” protects discovery. For a masked hero, the silhouette and covered face are identity constraints, not optional styling.

Ask each direction to change a meaningful principle: the interaction, composition, rhythm, information density or production method. Then judge the options separately. An attractive image should not get credit for a control scheme it has not demonstrated.

Use a comparison the reader can actually decide on

HALLIATUS's decision-page learnings came from a practical failure: the planning document existed, but the owner could not conveniently open and review it. The response was a readable page with the finding, before/after diagrams, recommendations, choices and an explicit way to return the answers.

That page is itself an intermediate artifact. It turns a vague discussion into a decision without pretending the choice has already been made. A recommendation should say why it wins and what would be lost or costly to reverse.

Choose the first test before choosing the expensive tool

The recorded 2D-animation trial proposed the same tasks in Moho, Character Animator and Blender: build the silhouette, turn the head, perform a namaste-to-point gesture and make an idle loop. The rule favoured speed only if the visor and mustache still read. The document is a trial plan; it does not establish a winner.

This is a useful habit: choose the common question and the pass condition before the tool. Otherwise, every tool will demonstrate its favourite trick and the comparison will tell you very little.

Basis: S1, S6, H4. The exercise is guidance; the tool trial remains proposed in its source record.

05 / The work between idea and product

Choose a model for the question it can answer

An intermediate model is a useful simplification. It leaves some things out so I can understand something else. A rough body is not a bad final character; a fixture is not fake evidence if it is honestly labelled and used for the right question.

Basis: C2–C4, H2–H3, S1–S5, B1–B3. Images: original SaffronRider proxy-front and K6-flat artifacts, resized for reading.

06 / Case study · Chirp's instruments

Give the tool ears before giving it a face

Chirp's AVIARY family includes decks, synths, sequencers and audiovisual experiments. Many instruments are self-contained browser pages. The family resemblance comes from shared principles; their different jobs come from different interaction and sound designs.

The first model is the sound path

The audio learnings start with a graph: source, processing, gain, analyser, output. Drawing that path makes the intended behaviour inspectable before the control panel exists. If the tool is silent, establish that a signal reaches the master before debugging the decorative end of the chain.

The visual side receives named features—bass, treble or energy—rather than every raw frequency bin. This small intermediate representation gives several displays a common language. A control can change the sound while a meter helps the listener understand the consequence.

A real platform changed the architecture

Rookery's records describe a background-playback constraint on iOS: decoded-buffer Web Audio is suspended when the page backgrounds. The recorded response was a lifetime media element with a gesture-gated analysis graph, rather than treating lock-screen playback as a simple toggle.

Events such as play, pause and waiting drive the displayed state. A page should report what the player is doing, not what a button last asked it to do. This is a design lesson as much as a coding lesson: a user's expectation can reveal that the underlying model is wrong.

A green test can still hide an unreadable instrument

One Rookery pass drew every pane and measured the signals correctly, yet several scales lacked numerals and a reel looked empty. The lesson was to look at the screenshot, then add the check that would have caught the actual problem. Pixel activity proves drawing; it does not prove interpretation.

Basis: C1, C3–C4. These are recorded instrument learnings, not a fresh device test.

07 / Case study · Chirp's data and reusable parts

Sometimes the bug is a missing idea

Two screens disagree. The tempting AI task is “make them match.” But that can erase something true. Chirp's de-spaghetti notes record MOLT and Rookery disagreeing about map pins: one was showing where a scene was set; the other was showing where the music came from.

Before: one location trying to answer two questions

A scene could be painted in the Sonoran desert while its musical reference belonged elsewhere. Reading the source showed that most of the apparent pin errors were not wrong coordinates. The data model needed scene location and musical origin, not one winner.

A second anomaly exposed another model: several scenes can share a place. Treating scene and place as interchangeable had hidden entries. The fix was broader than patching the single missing record. This is design thinking in code: the exception teaches you what concept is absent.

Share the law, not every surface

The same records deliberately keep the two globe renderers different. MOLT's painted scene-picker and Rookery's listening scope do different jobs. Shared facts should agree; presentation may intentionally diverge.

Chirp's av-core follows that distinction for sound. Timing, pitch, seeded randomness and musical-theory helpers have one hand-edited source, known-answer vectors and generated inline copies. Pages keep their own menu choices and adapters. Deliberate forks carry reasons instead of being silently overwritten.

The intermediate artifacts are not just a library: they are the vocabulary, the test vectors, the adapter and the generated-copy markers. They make reuse inspectable while preserving the self-contained browser-page format.

Basis: C2, C5. These are specific recorded fixes; they do not imply that all duplication across the fleet is resolved.

08 / Case study · HALLIATUS's design labs

Build the workshop around the game

HALLIATUS holds TALON, the mecha tactics game, and a studio for shaping its parts. The bays are not decorative extras. They create a place to inspect a character, sprite, portrait, icon or cockpit control without needing the whole campaign to be running.

From a design study to a production contract

Hero and villain bays establish silhouettes and visual rules. The Interface Foundry explores mecha panels, vintage meters, cyberdeck readouts, a synth and runway timing. The Icon Foundry is a separate source for glyphs; the shared design system supplies named components and tokens.

Different outputs have different dispositions. A self-contained study can ship as a working lab page. Something embedded in the game must lose external design-runtime dependencies and match the game's own vocabulary. Recording which route an export took prevents “the mock-up worked” from being mistaken for integration.

The sprite grid became a bridge

The recorded mech factory ports bay painters from a 256-unit design grid to a 128-pixel sprite-cell contract. The relationship is explicit, not guessed. Checks cover foot contact, player-core visibility and colour restrictions. The Sprite Lab mirrors real game assets, so inspection does not drift onto a separate mock set.

The portrait factory likewise derives a vector registry and palette rules from the approved lab. That makes the intermediate design source useful at several resolutions without baking labels and colours into every output.

The PMO surface closes the loop

The gated Tool Shed is a project desk: Status reads the project record, Docs exposes the working knowledge, and Bays opens the tools. The design index tells me where a study went. This connects making to managing: not just “what did we generate?” but “where does it belong, and is it used?”

Basis: H1–H2. Lab studies and production features are distinct; factory availability does not approve every generated asset.

09 / Case study · the animation staging lab

Rehearse the shot with the pixels that will ship

BAY-09, the Scene Factory, is a cutscene composition bench. I can choose a backdrop, place battle sprites, props and symbols, drag and resize them, change an actor's animation and order the cast. It uses the game's stage painter and its 768×432 frame—not a convincing but unrelated mock-up.

The composition is the intermediate model

The export is a StageBeat snippet: a plate stack and actor entries in the game's own scene language. That lets a visual choice cross into production without being redescribed as “roughly here, about this big.” An author still integrates it; it is not a rendered movie or automatically published scene.

A still shot cannot prove pacing

The recorded next-slice plan is explicit about the limit. The current bay proves composition, not a durable multi-beat draft, transition timing, audio/text rhythm or whole-scene playback. Its proposed progression is shot compositor → multi-beat editor → preview through the production runner.

That expansion is parked, not completed. The architectural lesson is still useful: one painter, one vocabulary, one runner. A future editor should author data for the existing player, not grow a second cutscene engine that behaves differently.

Basis: H3 and the sceneBay implementation. The screenshot proves the route is reachable, not a full interactive validation of staging/export.

10 / Case study · SaffronRider's character model

An image became a sequence of better questions

The rider needed to remain recognisable across views, gestures and media. The answer was not one perfect generation. It was a chain of representations, each reducing a different uncertainty.

The failure changed the input, not just the wording

The October 4 reference-sheet notes record Firefly reading “mustache + armour” as a bare-faced medieval samurai. More wording did not protect the masked identity. A suited-hero frame anchored the front; that chosen front then guided the side and back.

A strict angle instruction helped create a true profile. Using the proxy-side image as the sole reference fixed the view but copied its blocky style. Different references constrain different things: geometry, identity and finish are not interchangeable jobs.

Inspect before promoting

The recorded front/side/back route produced a recognisable Tripo mesh. The next questions were different: did the mustache tips survive, was the scarf consistent, and could the mesh be rigged? The run card's rule was mesh first, rig after. Rigging a flawed mesh only makes the flaw more expensive.

Basis: S1–S3. Original early reference artifacts, resized. Vendor settings in the historical notes are not current instructions or pricing claims.

11 / Case study · rigs, poses and physical outputs

A generated model is material, not a finished asset

A mesh describes a shape. A rig supplies movement. A production asset also needs scale, conventions, tests and a receiving tool. Treating all of that as one “AI model” hides where a failure actually lives.

Test the simplest useful movement first

The recorded move order was namaste-to-point, idle, then the airborne kick. The first gesture exercised the fingers without root travel. The kick came last because hips, rigid plates and motion through space added more unknowns. A held kick pose could expose weight problems before a whole clip was rendered.

The fingers worked in the auto-rig test; the scarf needed dedicated bone chains. An early GLB re-export was faulty, while the FBX in the original bundle was clean. The moves script used that source. “It exported” was not enough—the receiving tool had to reveal whether the skeleton and orientation survived.

Reusable archetypes emerged from actual characters

The later rig process distinguishes humanoids, a beast with jaw and tail, an armoured arthropod with claws, an odd two-faced humanoid, vehicles and props. They share some posing machinery, but not the same repair recipe.

THEL's claw hinges needed measured axes and both halves moving; a one-sided motion looked like a lever. MAYASURA's unusual limb orientation could be intentional, so it had to be tested before being “fixed.” The bike did not need the humanoid skeleton an auto-rigger put inside it.

A print asks different questions from an animation

The early print mesh had open edges, and its mustache became too thin at miniature scale. The recorded repair thickened surfaces and remeshed the output into a millimetre-aware 3MF. That solved physical preparation questions but softened edges. A print derivative can need different compromises from the screen master.

The reusable result is therefore a master plus recipes, not one universal file. Keep fixes in scripts, measure scale against the character rules, and derive the output for the destination. A watertight report still does not prove a physical print succeeded.

Basis: S3–S4. Reported mesh/rig/print-prep results are historical evidence, not a fresh export or printer test.

12 / Case study · building and refining a film scene

The beat sheet makes the scene discussable

SaffronRider's film process grew from actual scene work: write what happens, prepare assets, specify poses/camera/shading, block the scene, take notes, refine, then finish. A note can send the work back to any earlier step—not just trigger another full render.

The intermediate models are a plan, a clock and a blocking pass

A scene plan identifies shots and lengths. A beat sheet says which camera sees which action, with the rider's moves and the opponent's moves named on the same grid. At the recorded 148 BPM and 24 fps, a beat is about 9.73 frames; the audio grid is the timing reference, not a convenient whole-frame guess.

Proofs caught things the script could not explain away

The process notes record early hits landing metres short. Anchor measurements exposed the gap. A camera-visibility check reduced how often another body covered the rider's head. Probe frames and enlarged contact sheets checked whether the shot actually read, not just whether it rendered without errors.

Later polish records make the same distinction: measured planted-foot corrections and sample-identical audio refactoring are mechanical evidence. A short rendered kick proof still needed visual revision because the first trail looked like a laser, not flame. Neither kind of proof replaces the other.

Fix the layer that owns the problem

A sound or callout note can go to the mix or 2D pass; a set note can reuse character layers; a pose or camera note returns to the scene; a mouth or claw problem goes back to the rig. New version names and frame caches preserve comparison. The intermediate layers make this possible without regenerating the whole idea.

Basis: S5, S7. The latest inspected polish record still leaves full-speed watch/listening approval and final-master work open; this guide does not call the film finished.

13 / Wider workshop · engines and experiments

The useful thing may be underneath the product

Reuse became more concrete when there was a second real customer for a component—not just a hope that a generic framework might be useful someday. Two other projects in Bestiary's knowledge collection show this from different sides.

Pixelscapes: a scene as a recipe, not a saved picture

The recorded landscape engine describes a scene through an archetype, variant and seed, painted through a limited palette. Hand-built landscapes and data-driven recipes share a renderer. The intermediate model is the recipe: enough instructions to reconstruct the scene, not an opaque generated image.

A frozen prototype supplies a reference for comparison. The records distinguish a scene's identity from its presentation, so adding a new palette need not silently change an old shared scene. Changes that tests cannot represent, such as intentional re-tints, go into a decision record.

Heron later consumed a thin landscape core rather than the whole donor app. Provenance, parity checks and a repeatable update path made the transfer inspectable. The engine was reusable; the calendar and the landscape explorer remained different products.

Phrasebloom: simulation as a model of play

The music-match puzzle uses simulations to explore board rules and player behaviour. Skilled, casual and idle bots are different test models, not a substitute for all players. An idle bot is especially useful: it asks whether the system rewards doing nothing.

The recorded work committed decision rules before examining the tables. A harder board floor failed a casual-player condition, so scope changed instead of quietly adding help to make the number green. Simulation offered a reason to choose, not proof that humans would enjoy the result.

The harvested record still leaves human playtests and blind listening open. That boundary is the learning: an experimental model can disprove a mechanism without proving a market, an experience or a finished product.

Basis: B2–B4, harvested October 3–4, 2026. These examples use dated Bestiary evidence, not a fresh full audit of those products.

14 / AI-assisted making · a practical session

Vibe coding needs a memory and a boundary

Chirp's approach calls this AI-assisted “vibe coding” held to a steward's discipline. The useful part of the vibe is fast exploration: describing a feeling, trying a control, generating a first draft and seeing what happens. The discipline is what lets that speed accumulate into something coherent.

Give AI the right working context

Start with the project's current purpose, locked design rules, the relevant files, the exact host or engine, and the one question this slice should answer. Read the existing work before making more. A whole knowledge library is usually less useful than the few authoritative records that govern today's decision.

Then separate exploration from execution. First ask for alternatives, assumptions and the cheapest tests. Choose the direction yourself. Only then ask for implementation inside a named scope. AI should not turn every attractive side idea into another system.

A starter prompt you can adapt

Goal: [one person, moment and desired result]. Read first: [current project record and relevant design/contract docs]. Preserve: [identity, behaviour, format and production path]. This slice: [one observable outcome]. Not this slice: [explicit exclusions]. Before editing: show two plausible approaches, risks and your recommendation. After I choose: make the smallest useful change. Use existing components. Prove it in [real engine/tool] with [pass condition]. Report what you checked, what you did not, and the next uncertainty. Do not publish or change access settings.

Close the session, not just the chat

Review the actual diff or asset, run the relevant checks, open the result where it will be used, and make the decision visible. Update the project record and write why the choice was made. A chat answer saying “done” is not a durable handoff.

Chirp's “The system thinks, you decide” captures the division: AI can propose, generate, compare and explain; I own direction and approval. I also need to resolve rights, licensing and publication boundaries. A generated asset does not automatically settle any of those questions.

Basis: C1–C2, H4, B1. The prompt is an editorial template, not a transcript or a promise that every repo enforces this workflow.

15 / AI-assisted making · proving the result

Ask for evidence at the right level

“The tests pass” can mean the code parses, one state changed, a canvas painted, a file exported or a real user completed a task. Those are not equivalent claims. The workshop's strongest checks make the boundary visible.

Four different kinds of evidence

1. Mechanical: known inputs produce expected outputs. Test the actual module or renderer, not a copy of its logic in the test.
2. Integrated: the host consumes the artifact correctly. Open the exported rig, use the game painter, or check the deployed route.
3. Perceptual: a person can read, hear and use the result. Look at the screen, listen on the intended device, watch the shot at speed.
4. Decision: the owner explicitly accepts the result for its purpose. Technical evidence supports that choice; it does not make it automatically.

Prove that the checker can say no

Bestiary calls this earning a check by mutation: deliberately introduce the failure the check claims to detect and confirm that it fails. A test that only looks for a word can pass commented-out code. A test for “file exists” can accept a silent stem or a broken export.

Chirp's de-spaghetti work found another version of the problem: an inventory tool reported duplicated capability because it was counting generated library code as hand-owned duplication. The checking tool itself needed correction. Evidence should be checked against reality, not believed because it has a reassuring label.

Keep the promotion path honest

Basis: B1, C2–C6, H2, S7. Technical checks and human creative approval remain deliberately separate.

16 / AI-assisted making · preserve the learning

The repository is the memory between sessions

The collaboration becomes fragile if everything important lives in chat: the reason for a decision, which file is the master, what failed, or whether someone approved the result. Architecture notes, codices, changelogs, project records and handoffs give the next person—or AI session—a way to continue.

Turn an incident into a reusable rule

“The mesh broke” is an anecdote. “The re-exported GLB lost the usable skeleton; the original FBX was clean; open the receiving-tool export before adding moves” is a learning. It names the failure, the evidence, the changed practice and the boundary of the claim.

Chirp's records say documentation written in the past tense must describe current behaviour, not the goal. SaffronRider records each round of feedback with what changed and a new version. HALLIATUS indexes design exports and their destinations. These are different formats doing the same job: preventing the next session from having to rediscover the truth.

Reuse is a controlled translation

Borrow the intent, then rederive the details for the destination. A useful donor may have different timing units, build commands, rendering assumptions or rights. Preserve provenance, test the adapter and leave the receiving project's design choices intact.

Rescued work needs the same discipline. Old branches can contain useful discoveries, but an old patch is a proposal against today's code—not an automatic restoration. Inspect it, separate the still-valid idea, and verify the new result.

Bestiary and Watchtower have different jobs

Bestiary holds reusable standards, skills, hooks, research and fleet guidance; Flyway records intentions and handoffs. Watchtower reads and presents the work. The operating plan promotes a repeated learning into shared practice after it appears in more than one repo. That is a rule and scaffold, not proof that every fleet repo has adopted it.

Basis: C1–C2, H1–H4, S4–S5, B1 and the Hive Plan. This describes practices and intentions, not a completed fleet-wide rollout.

17 / Your first design-thinking + AI build

Make one useful thing, and leave it understandable

Use this as a worksheet, not as seventeen new obligations. A small sound tool, a single scene, a character pose or one screen is enough. The point is to move one idea through a complete learning loop.

1 · Before you ask AI to build

• Moment: who is doing what, and what is difficult?
• Known / assumed / unknown: one line each.
• Must stay true: identity, behaviour, rights and format.
• NOT-list: what this slice will deliberately not do.

2 · Choose the cheapest honest model

• Options: two or three genuinely different routes.
• First question: the uncertainty that blocks progress.
• Model: graph, clickable study, proxy, reference view, beat sheet or fixture—and what it cannot prove.
• Pass line: a visible, audible or measurable condition chosen before the trial.

3 · Build, inspect and decide

• AI boundary: relevant source, approved direction, allowed change and excluded scope.
• Reality check: actual engine, receiving tool or device, plus one bad/null case.
• Human judgment: what you saw, heard or tried, and whether it is good enough for this purpose.
• If it fails: change the owning layer; do not regenerate the whole project by default.

4 · Close the loop

• Deliver: a result someone can open or use, checked at its destination.
• Record: one decision, one learning and the next uncertainty.
• Keep: the source/master, reproduction path and useful evidence.
• Reuse later: extract the proven mechanism when a second actual need appears.

The measure of progress: not how much AI produced, but how much uncertainty you removed—and whether the next person can continue without guessing.

Editorial worksheet synthesized from the project cases and B1. Adapt its scale to the task; it is not a new fleet policy.

18 / Open the workshop

Start with a tool, then look at how it was made

The reader links below lead to live Cloudflare Pages surfaces, not private repositories. Some are working prototypes or development tools. Access checks dated October 12, 2026; a reachable page is not a complete product test.

• Chirp / AVIARYPublic · start with a browser instrument.
• Chirp · Summary of ApproachPublic · the early build story and design philosophy.
• HALLIATUS / TALONPublic · the game and its interactive world.
• HALLIATUS · Tool Shed and design labsPassword-protected · Status, Docs, Bays and foundries.
• HALLIATUS · BAY-09 Scene FactoryPublic route · stage a shot using the game painter.
• SaffronRiderPublic · the world and playable rhythm-fighting prototype.
• SaffronRider · StudioPublic · production and inspection tools.
• WatchtowerPassword-protected · a reading surface for the fleet.

Where this guide's examples come from

C1–C6 · Chirp: Approach, design principles, de-spaghetti, audio/visualizer and single-file learnings, av-core and verification notes. H1–H4 · HALLIATUS: overview/PMO, factories, Scene Factory plan and implementation, decision-page learnings. S1–S7 · SaffronRider: pipeline, proxy, first reference-sheet run, rigs, film process, 2D trial and polish review. B1–B4 · Bestiary: ways of working; dated Pixelscapes, Phrasebloom and Heron harvests.

Design-thinking framing also draws on the Design Council Double Diamond and Stanford d.school Bootleg. These clarify the method; they are not claimed as the origin of my projects.

Prepared October 12, 2026. Revision-pinned source paths, caveats and regeneration instructions are maintained beside this guide in Bestiary. Read without a network; outbound links need access. No protected credentials are included.