This is also a bet about the moment. A lot of developers have been laid off, a lot of institutions feel brittle, and too much software hides process until it fails. I think we can engineer better structures: ones that help people learn, publish, collaborate, and keep ownership over their files and thought. A personal webpage does not need to be fancy to start doing that. It needs to show how you relate to process, and that is part of why process art matters here. It is also why I keep returning to math and lore: the first helps make structure feel less arbitrary, and the second helps make computation feel less abstract to authors.
Tailor the atlas
Let the homepage reflect your route
These choices stay in this browser, and they carry into the image accents, cards, and route surfaces you open next. The full register lives on settings.
theme: autopalette: routememory: nearby
Resonance dimension
Choose the guiding perspective
Keep the atlas context-led, or bias nearby images and cards toward craft, software, or mathematics.
Theme
Hold the light level
Leave it adaptive or pin the reading atmosphere before you wander into deeper topics.
Color paths
Stumble into a palette, then follow where it feels coherent.
Current dimension: route. Wonder memory is nearby, and color mode is auto.
The practical aim is simple: a visitor should be able to discover a good path by color, not only by taxonomy. For the full browser-local register, open runtime preferences.
Happy paths on this site can start with a temperature instead of a category: follow warmer material routes into craft or recipes, cooler structural routes into software, or more social energy into play. Wonder memory decides whether that feeling stays local or starts echoing.
wonder memory: nearby
?~@&*^
Surface view
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. This lets the page teach that typography is not only styling. It is a model of emphasis, access, and relationship that can point onward into software, math, craft, or recipes without needing a different interface for each mode.
The site is built from reusable frames, cards, chips, figures, operator routes, image studies, and publishing surfaces. Those are not separate concerns. They are parts of one semantic lattice where plain text, component structure, visual atmosphere, and media cues can reinforce one another, then later feed into sister routes like publishing registers, runtime settings, and eventually cloned domains such as spwashi.art and spwashi.dev.
Syntax view
Each line is a gesture in a grammar that stays readable as plain text. Operators are vocabulary. Braces are containment. Topic handles and image studies can both be indexed as semantic surfaces.
#>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. I want the pages to behave less like isolated essays and more like a configurable surface where settings, interaction rules, and publishing cues can move from one route to the next.
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. A surface becomes more valuable when it can imply nearby contexts without becoming noisy. That same grammar should be sturdy enough to seed later siblings such as spwashi.art and spwashi.dev.
Atlas weather — the first color field should already hint that the atlas, craft, and site design share a paper-and-tide vocabulary.
Parser weather — this route study points forward to software, the parser map, and complexity budgets before the page turns fully technical.
On this page, a term can behave as noun, verb, adjective, topic, route, operator, label, caption, or material cue.
Noun
frame as a thing: a container, a card, a room, a visible boundary.
Verb
frame as an action: to orient, to prepare, to set expectation and containment.
Adjective
frame-like as a quality: bounded, editorial, deliberate, clarifying.
Operator
#> as an operator: a formal stance that changes how the next thing is read.
The same principle applies to surface, signal, craft, and play. This is useful because the site is not just cataloguing topics. It is also showing how a vocabulary becomes more expressive when the page itself demonstrates multiple grammatical uses.
Words, topics, and images should reinforce one another
An image can act as evidence, mood, nearby material, contrast, or an invitation to reinterpret a topic physically.
Pretext Physics — the image behaves like a nearby material proof for the topic pretext.
Abstract Wash Study — the image behaves like a nearby material cue for atmosphere, accent, and material.
Start with the page in front of you, then follow handles when you want more. The left wall can bias density; the right wall can bias operator color. Each layer you unlock can stay unlocked, forming incremental topical depth through repeated traversal.
A working subset of the operator family. Top row: the reading spine for orienting, elevating, inquiring, relating, committing, and projecting. Bottom row: support grammar for qualification, settling, binding, reflection, integration, and normalization.
The brace is also a polarity axis. The left wall { leans structural and shared; the right wall } leans situated and felt.
Each route is a different kind of room in the same workshop
A page does not only need sections. It can have rooms with different gravity: reflective nooks, charged portals, registers, specimens, workshops, theatres, kitchens, and archives. The names are there to make process legible, not to sound clever, and each one should point somewhere useful like about, software, craft, play, or the blog.
~nookNookReflective, editorial, intimate surfaces that hold careful prose and slower invitation.>portalPortalCharged entry points that suggest another context is relevant and worth entering.=registerRegisterLedger-like surfaces that collect signals, routes, statuses, and later revisitation traces.@specimenSpecimenPromptable artifacts that imply screenshot-worthiness, material study, or trope development.#>workshopWorkshopSystem-building surfaces for parser thinking, runtime ideas, architecture, and readable tooling.$archiveArchiveCollected routes, older surfaces, domain clusters, and memory-bearing materials.
The aim is not to replace HTML with images. The aim is to let a component feel like a meaningful specimen that could become a render study, poster, or prompt seed later.
Papergami Architecture — a structural prompt seed for layout, readable planes, and spatial grammar.
Alchemy Token Display — a motif study for symbolic emphasis, semantic ornament, and collectible token language.
Constellation Studio — a route-and-motif study for archives, signals, and connected surfaces.
I am thinking in seasons as much as posts. The practical aim is a stronger production rhythm between October and January, where writing, software notes, render studies, and website changes accumulate into a visible body of process.
Production Season
Between October and January I want a steadier public rhythm: channel summaries, workbench notes, linked topic updates, and enough visible process that the season reads like a body of work instead of stray posts.
Configurable Flows
The longer-term goal is configurable data flow between pages, so a route can carry state, related artifacts, or semantic cues from settings into topic hubs, field guides, and future domain forks without flattening everything into one app.
If I practice paying attention to this site, it should become more useful, more legible, more beautiful, more technically sound, and more able to support collaboration, study, publication, and later forks into sibling surfaces.
Home as spoken summary
The home page should summarize the spwashi channel in plain language, then route people into software, math, craft, recipes, play, and lore.land without making the entry point feel abstract.
Website as process surface
The website field guide should show that many engineers would benefit from making a webpage of their own. It does not need to begin as a polished brand surface. It needs to demonstrate how they relate to process, and it should stay compatible with authoring tools like Obsidian when those notes need to become public writing later.
Settings and cross-page state
Settings should clarify which parts of the system are global, local, atmospheric, behavioral, or inspectable, then eventually support richer data flow between pages so nearby routes can inherit useful context instead of starting blank.
Future route forks
Craft and site design are already helping define the visual language that could later seed spwashi.art, while software and website systems are the obvious base for spwashi.dev. lore.land is the companion route where author onboarding, ebooks, and narrative structure can become their own serious surface.
A simple constellation study: routes do not only sit in a menu. They can also feel nearby because a local interaction suggests another context is relevant.
