kernel entry
This site is a living magazine for culinary software: a literate cookbook, theory guide, art atlas, and RPG Wednesday notebook for staying sharp, practicing pivots on classics, and turning private wonder into shared meals, prompts, routes, lore, and reusable components.
Playable hook: once upon a time, a good surface gave the reader a place to stand, a reason to return, and one handle they could tune into frame.
Try this as a tunable reading surface: culinary reading, garden room, or runtime atlas.
the site needs one clear place where software engineering, art practice, culinary metaphor, and story seeds can stay readable together.
developers, parents, returning students, illustrators, performers, RPG players, cooks, researchers, and worldbuilders who need a practical first route.
recipe prompts, route maps, proof cards, session seeds, lore fragments, and reusable components that can travel to another site.
Current direction
A simple way to say it is: this site helps me wonder through recipes, components, spells, study plans, and session notes on my own, then share the ones that seem worth practicing in common. The current metaphor is a cookbook with engineering notes in the margins. The test is whether a pattern can be read, reused, revised, and served to someone else without losing its source.
I want the site to work for adults who are still learning in the middle of ordinary life: parents keeping their minds warm in case another degree becomes possible, engineers who want theory without losing craft, and people who need nutrition, romance, humor, and fantasy to stay connected to practice instead of becoming separate hobbies.
I think of the whole thing as a recursive editorial loop: make, inspect, reroute, repeat. The center of gravity is spw-workbench, with projections into Spw language design, software routes, author craft, math, tools, texture.website, RPG Wednesday, lore.land.
One reason the website matters so much is stability. It lets me centralize digital structures instead of leaving the practice scattered across apps, feeds, drafts, and moods. If the structure holds, the learning can compound instead of resetting every week. RPG Wednesday has been developing for more than a year now, so the public pages can treat it as a recurring release surface: sessions, library cards, cast notes, and logs that keep accumulating usable canon.
The story seed is practical: a reader can enter through soup, wings, a component, a character, a CSS state, a research question, or a trade ingredient and still find the same underlying move. Stock becomes context. Reduction becomes compression. Sauce becomes byproduct recovery. Mise en place becomes dependency clarity. A session becomes a test kitchen for lore.
Culinary techniques are useful because they ask for inventory. If a page says bloom, temper, deglaze, ferment, fold, or reduce, it can also suggest a shopping list, a memory character, and a scene. A cook learns what to buy; a software engineer learns what operation is happening; an RPG table gets a mnemonic creature or ritual that makes the concept easier to recall.
I want the interface to feel less like a pile of controls and more like a marked-up field guide. Links should still navigate plainly. Buttons should still announce themselves to assistive technology. But the visible language can call them handles, lenses, provisions, route clues, spell marks, and pantry notes when that helps the page feel like a place someone can mosey through instead of operate.
A lot of this gets worked out in video. I do not treat speaking as a polished trait I either have or do not have. I treat it as practice. I still keep showing up because communication gets better by being used, and then used again. That matters here because the boonhonk idea is less a label than a disposition: a way to test how tone, force, and interactivity change when structure is allowed to recombine.
The site should feel learnable before it feels elaborate. A good surface gives a stable ground, then lets depth appear through repeated handles, visible state, and small changes in spacing, color, or copy. That is the practical meaning of resonance here: not sound, but a visual relationship that teaches the reader what changed and why it matters.
Touch interactions should be mindful. Hover, focus, tap, and settings can reveal relationships without stealing the page from the reader. Semantic resonance is there to help someone discover the same concept in another card, route, recipe, prompt, or lore fragment when they are ready to follow it.
Start with the role that matches what you want to do now. The rest of the site stays available, but the first screen should not ask you to classify yourself alone. Pick one need, not your entire identity.
Use About, Software, and the Website Field Guide when you need route structure, reusable components, or something that can become a prompt later.
Use Play, Town Atlas, and Recipes when you need scene pressure, objects, surfaces, and material cues that can be drawn or staged.
Use RPG Wednesday, Sessions, Cast, and Library when you want readable memory, dialogue pressure, and a durable place for a table to become public.
A useful homepage should behave like mise en place for attention: the tools are visible, the work surface is clean enough to begin, and the next move does not require memorizing the whole pantry. The same page can also hold a story seed when the ingredients are named well enough for another person or model to expand.
Open Services, Cards, Now, or Contact when the goal is a commission, a referral, or a direct ask. This path helps when the page needs to become an offer, a proof card, or a concrete next move.
This route gives a collaborator a direct way to ask for help without first learning the rest of the atlas.
It produces a live offer path, a proof surface, or a small next action that can be completed quickly.
Use the current sprint, membership, and proof cards when the task is to help the work move forward. This route connects to the work-in-progress state, the recurring release cadence, and the small actions that keep the system alive.
This card helps when support is logistical rather than expressive.
It keeps coordination visible enough to share without turning it into a bigger task than it needs to be.
Use About, Software, and the Website Field Guide when the goal is method, architecture, or inspection. This card helps when a route should explain itself before it asks for trust.
This surface exists because a reusable medium should teach its own structure.
Developers and curious readers can use it to find the method before they commit to the whole site.
Use Care, Topics, and proof cards when the problem is not only knowledge but getting your footing back well enough to act. Return here after the immediate pressure has been named, because the next move should be small enough to finish.
This route exists for moments when the page should lower friction before it asks for a decision.
It can produce a steadier entry path, a topic neighbor, or a proof card that makes progress visible.
Topics, Town Atlas, Blog, Play, Research, and Tools are the broader lattice when you want to learn sideways. This surface produces neighboring routes, not just more labels.
* topics #> town atlas ~ play ? research
This is the exploratory route for when a visitor wants to move by relation instead of by category.
It helps the site remain a field guide rather than a single-path funnel.
Use the boonhonk register when the question is how a system behaves once disposition, signal, and recombination are part of the interface. This is the route for playful-social generosity with enough structure to stay useful.
* boonhonk register ~ rpg Wednesday
This card exists to show that tone is part of system design here, not an afterthought.
It gives the site a way to surface wonder, recombination, and public play without losing the practical route.
Learning science is more useful here as a reading habit than as a slogan: start with one question, leave with one artifact, then revisit from a neighboring route.
the site should help people learn something that survives the visit.
you need a visible loop from question to artifact to return path.
proof cards, route maps, prompts, and recurring habits that make the site easier to revisit.
Pick the route that matches your actual pressure now, not the most prestigious topic on the page.
Make a card, note, screenshot, route map, or quest so the learning can survive mood drift and time passing.
Use topics, play, care, or software to test whether the pattern transfers when the context changes.
Some visitors want the prose and canon. Others want the route model and runtime. Both get a first-class path, and both should leave with a smaller next move than they arrived with.
A component is a small machine for arranging attention.
For readers
Start with About, the Website Field Guide, the Town Atlas, and Recipes when you want the site’s story, method, and reusable craft to stay close together. This path connects to lore, practical routes, and the material practice behind the pages.
For builders
Start with Design, Settings, Software, and the inspect query when you want the browser-local controls, CSS, and layout behavior to stay legible. This surface helps the site feel like a system that can explain itself, not just render itself.
The center of gravity moves. Learning weeks, research weeks, playtest weeks, and publishing weeks should not all ask you to enter through the same door.
Changed center
Some visits are about support, some about proof, some about learning, and some about finding a route you ignored the first time because it was not ripe yet.
Use a different route than last time on purpose. The atlas is healthier when it supports drift.
Software should be close to math, craft, care, and play so the questions can mutate.
When a thought matters, turn it into a page, card, quest, prompt, or small spell someone else can point at and replay.
Fresh entry
That might be topics if you need a map, cards if you need a proof surface, or the blog if you need to watch fragments turn into public form.
Build your way into college-level thinking through a playable library, session notes, guide characters, studio quests, garden prompts, and portfolio-ready artifacts.
For the story substrate itself, move to the Town Atlas. That keeps the practical library and the world bible separate enough for humans and models to review without guessing which page is doing which job.
Make a route map, quest seed, or systems diagram in one sitting.
Use Grounding Rod, Cask, and Avalanche Evan as learning interfaces, not only character art.
Notice, name, build, document, connect, and extend before committing to a major label.
It can be a local record of an ask, offer, agreement, reference point, or chosen disposition.
See the active target, what it unlocks, and how someone can help in thirty seconds.
Make a screenshot-ready record for an ask, offer, pledge, reference, decision, or membership signal.
Choose an observer, reference, working, sponsor, or collaborator role without turning membership into a fan club.
Use creator packages, business web work, consulting, or a direct support path to fund useful output.
Privacy stays direct: drafts are not automatically public, screenshots should say why they exist, and shared records should expose only the context someone needs to act well.
This is the action layer. Start with the workbench, a topic route, a live playtest, a texture-facing surface, or the tools that help someone describe their work well.
A skill surface should give something back for the attention it asks of you: a clearer question, a usable pattern, a replayable spell, or a next move you can actually take.
Learning game
Gratitude
Wonder is useful here because it keeps software, art, care, and play from sealing themselves off too early.
Rewards
A route, card, or tool that makes the work feel startable.
A neighboring skill surface to borrow from before the thought stiffens.
A screenshot, prompt packet, card, or route sequence you can run again under different conditions.
Collection should mean “this helped me notice,” not “the page awarded a score.”
Take it sideways
These settings stay in this browser. Use them to set route bias, color atmosphere, and wonder memory without mixing tuning controls into the kernel statement.
Read one route as a component kit, one as a live playtest, and one as a texture or support surface.
One card keeps the work easy to start. One card gives the page a small reason to change tomorrow. Both stay readable without JavaScript.
Every character in <Spw> is a cognitive gesture. A frame #> orients. A probe ? opens inquiry. A reference ~ reaches without binding. An action @ commits. A surface > projects.
The same unit can be stressed differently depending on context. A word may be plain prose in one paragraph, a topic handle in another, an operator route somewhere else, or a label inside an SVG.
Each line is a gesture in a grammar that stays readable as plain text. Operators are vocabulary. Braces are containment.
#>home_frame < orients this unit of meaning
#:layer pragmatics < qualifies interpretive layer
^"reading_layers"{
?[word] < asks what a word is doing here
~image < relates text to nearby study
@accent < commits a local emphasis
*topic < connects repeated themes
>surface < projects visible hierarchy
}
&[context]{
=part_of_speech "noun|verb|adjective|operator|topic"
$meta "panel|caption|card|image|route"
!constraint "stay readable in plain text"
}The website itself is part of the practice. It is a field guide, a publishing surface, an observatory for settings and states, and a test for whether a site can stay readable while becoming more semantic, promptable, and cross-referenceable.
The practical thesis: readable syntax can give people and tools the same map. A typographic layer becomes more valuable when it is also a semantic layer.