I'm Spwashi. This page is the map around that sentence.

Experience

I have spent roughly fifteen years building software, with most of my strength in frontend systems, design systems, developer tooling, content surfaces, HTML/CSS architecture, and interface language. I work best where engineering, writing, interaction design, and learning overlap.

Why the dropout still matters

I did not leave school because I stopped caring about education. I left because I cared enough to feel the mismatch between institutional form and lived motivation. That mismatch still matters to me. It affects how I think about note systems, learning tools, interfaces, curricula, and product design.

School, language, and relief

I grew up respecting education as a process, and part of the long thread behind this site is that school often felt more breathable than home because new subjects and new language made it easier to describe experience with peers who could share the novelty. A lot of what became my career started as experiences I could not yet bring back home intact.

That thread now has a more explicit shelf on the mental health topic.

Language as synchronization

A lot of my motivation is simple: people often have real experiences without concrete language for them yet. I designed Spw, in part, to synchronize understanding about God, and in part to see the shape of ideas more clearly. I cared so much because my father and I had different spiritual upbringings. The same grammar has to work across cultures, collaborators, and tools. I do not think the value of that work is limited to one anticipated audience. The aim is to build better naming, clearer structure, and more surfaces where a thought can test whether it is becoming shareable.

That is part of why linguistics, interface language, and operator grammar keep showing up here. They are not side interests. They are part of the bridge, and sometimes that bridge produces a real moment of recognition when someone else cares enough to wonder about meaning with you.

Lately AI has become part of that loop too. I use systems like ChatGPT to help me process the language I am already building so I can update plans for the language itself instead of starting from a blank page every time.

How I like to work

I like small, serious teams, strong products, readable systems, and environments where maintenance is treated as care. I care about architecture because it changes what people can sustain, inherit, extend, and teach, and because site stability, naming, and structure are never merely cosmetic.

I care about the marketplace being more socially acceptable and less ratchet. I want pricing language that treats budgets as rhythmic allocations (13-step discipline, cauldron-visible numbers), better public proof, and better engineering surfaces around creative work so people do not have to choose between dignity and legibility.

Professional direction

I am aiming toward senior, staff, and principal-caliber work that integrates software engineering, developer experience, design systems, knowledge workflows, publishing surfaces, educational structure, and better HTML/CSS/SVG habits for engineers who want their work to stay legible.

What I build

I build parser-driven systems, interface architecture, documentation surfaces, design systems, public websites, developer tools, and environments where plain text can accumulate more structure without becoming opaque.

• language tooling and parser systems
• interface architecture and design systems
• developer experience and workflow design
• accessible web applications and publishing surfaces

spw-workbench

The strongest expression of this right now is spw-workbench. It is the kernel candidate: a workbench for readable systems, parser/runtime/tooling integration, semantic projection, portable seeds, and structured thinking that remains inspectable.

Why this matters now

A lot of institutions are not adjusting quickly enough to the current environment. Whatever people think of Roy Lee, I think he understands something real about where the school system is and where it is failing to adapt fast enough. That does not mean every response to that problem is wise. It does mean we need to build better structures instead of pretending the existing ones will correct themselves.

Readable systems over opaque automation

In an era of cheap generation, legibility matters more. I want systems that let people inspect what happened, recover intention, revise structure, and keep ownership over their files, reasoning, and tools. That includes authors, but it also includes engineers: I want more of us practicing plain HTML, durable CSS, and SVG as an editable medium for diagrams, characters, and reusable assets instead of treating the browser as an afterthought.

Home as semantic orientation

The home page should teach how to read the ecosystem: parts of speech, components, topics, images, SVG specimens, and operator routes.

Software as technical depth

The software surface should make parser systems, operators, syntax, rendering, projection, and tooling easier to understand and extend. The nearby math routes exist partly to make those structures feel less abstract before they become implementation detail.

Craft as editorial practice

The craft surface should strengthen my sense of hierarchy, panels, typography, sequencing, visual rhythm, publishing structure, and SVG as a vehicle for character development and asset exploration.

Services as practical conversion

The services page should convert attention into collaboration, clear scope, pricing logic, and useful contact surfaces.

Blog as interpretation practice

The blog should help turn fragments, questions, wonder notes, and video summaries into more public and usable language, especially when those notes are moving from private authoring systems toward essays, ebooks, or lore surfaces.

Play as experimentation

The play surface should let me test interaction, symbolism, tone, live session rhythm, and narrative structures without pretending every experiment needs immediate productization. That includes RPG surfaces where scenes, textures, items, and characters can be staged, collected, and translated into later SVG or image work.

My documentation and code

• spw-workbench — parser, runtime, tooling, and workbench direction.
• spw.quest — paced guide into Spw (coming soon). Live specimens stay on the operator atlas.
• software surface — public route into the syntax, ideas, and experiments.
• math surface — intuition-first diagrams for the structural ideas behind the software routes.
• SVG storytelling — motif systems, illustrator handoff, and inspectable marks for recurring assets.
• SVG experiments — path grammar, addressable diagram hosts, and tuned handoff studies.
• trope.wiki — a longer-horizon home for trope physics, naming drift, and speech-bubble metaphysics.
• texture.website — a neighboring surface for material cues, language texture, and the tactile side of publishing systems.
• website field guide — runtime shell and interaction model of this site.
• lore.land surface — author-facing narrative, ebook, and mythic-publication direction.
• blog interpreter — public fragments, development notes, and reflective synthesis.

Knowledge environment references

• Obsidian Help — the core authoring substrate I keep returning to for private note systems. (Applied intentionally; the math on the engineering market and changed relevance of skills is real, yet it is possible to apply attention to other structures of necessary problem-solving.)
• Obsidian Developer Docs — useful when note workflows need to become more structured or tool-aware.
• What is Obsidian — the simplest entry point for authors who need a vault before they need an app platform.

Engineering interviews often test specific abstractions and tech relationships; experience design must respect the pace of software development, personality characterizations in teams, and how abstractions are discovered/taught with respect to a perspective's longitudinal existence and short-term motivations. Broader local-first + knowledge environment thinking (of which Obsidian is one clear, intentional example) serves many contexts and other structures of necessary problem-solving.

Local-first references

• Welcome to Automerge
• Automerge Core Concepts
• Local Storage and Sync

Language and tooling references

• Tree-sitter
• Language Server Protocol
• CodeMirror
• TypeScript Docs

Boon

Arrival, benefit, invitation, reward, flow toward.

Bane

Cost, limit, friction, refusal, necessary subtraction.

Bone

Structure, scaffold, chassis, carrier, persistence.

Bonk

Impact, event, interruption, comedic collision, change.

Honk

Signal, broadcast, resonance, wave, public relay.

Combinatoric genre

How a mix travels

Start with one transform, or a pair. Count if you want: 5 alone, 20 ordered pairs. A longer mix is a sequence of beats. Names on RPG Wednesday already do this: BoonWAP, Honk Bazongas.

boon + honk

Generous broadcast. An invitation that can be heard across the room.

bane + bone

Durable constraint. A limit that holds the room up instead of punishing it.

bone + bonk

A scaffold that can take a hit. Collision as research against something that will still be there after.

boon + bane

Arrival with a cost. The gift and the limit share the same beat.

honk + bonk

A signal that collides. Comedy that teaches a rule the table can reuse.

Food as modality extension

I do not think software is the only place where structure matters. Nutrition, menu design, hospitality, pacing, atmosphere, and the circulation of care are also design problems. We can describe the ways we hope nutrition flows and then make tasty foods that embody those hopes.

Restaurant + entertainment venue horizon

I want to manage or own an entertainment venue with a restaurant (or series) one day as a modality extension of boonhonk. Ingredient sourcing is part of that practice: who grew it, which season, how far, and how a grower is named, if they are. Compelling recipes, fantastic service, pacing, atmosphere, liminality of arrival/departure, and the circulation of care (as charge/discharge of attention and component states) are design problems. Materials as paint: table surfaces, flavor timing, and speech-bubble orders (operator-like requests in scenes) can be tuned like site metamaterial, physics-reason, or cauldron ingredients. This lets the work move from symbolic and digital surfaces into recurring physical experience: meals, rooms, rituals, timing, staff systems, repeat visitors, public culture. See recipes (public kitchen for culinary culture, composition, garden, sensory research, fermentation as material science, cauldron hook + visibility for discovery across structures) and RPG Wednesday (iterative character design, worldbuild with restaurant scenes as prototype for venue lore + service as readable system; l'n'd'r speech bubble expertise as reason to explore subvocalization, attentional resonance with spells/cauldron, and component ecology for hospitality). Different page regions, nooks, badge modes, and toasts prepare the vocabulary for physical service flow.

Liminality and materials science meet attentional flow here: thresholds of hospitality (entry, seating, service, exit), materials (food as paintable matter, table as surface, light/sound as tokens) shape how attention moves and wonder accumulates. A venue is another place where speech-bubble metaphysics (clear orders, shared stories) and real physics (heat, timing, flow) can be practiced inclusively.

Why this belongs here

A restaurant is also a readable system. It has flows, thresholds, interfaces, menus, sequencing, maintenance, signals, and memory. It is another place where attention can be converted into structure people can actually inhabit.

What attention should produce

Attention is not just admiration or sensitivity. It should produce assets. After enough attention, I want stronger naming, better system boundaries, cleaner files, more useful workflows, sharper editorial judgment, clearer interfaces, and more grounded decisions about what deserves to exist.

Rhythm at scale

Ten thousand videos across a few years, counted in 200-day chunks and released on the 13-step cycle. The operators have continued to develop inside that cadence, but the January 2023 rhythm still sets the measure. The sequence functions like a multi-pass process over a persistent execution trace: each 200-day epoch applies further transformations, and the releases serve as commit points in a long-running repository of attention. What compounds is not the raw count. It is the lattice of distinctions, defaults, priorities, and forms that can be carried forward without the original moment having to be reconstructed each time. See schedulers for the geometry of the release cycle and the Spw operator atlas for how the 13-step sequence and its primitives have evolved inside it.

Compounding through practice

Practice matters because attention compounds unevenly. Paying attention to one parser bug helps with another. Paying attention to one page layout helps with a whole family of surfaces. Paying attention to one recipe helps with timing, sequencing, hospitality, menu design, and the way vegetables change when they are cut, stacked, roasted, or placed beside a neighbor. The point is not to hoard observations. The point is to convert them into reusable structure.

From attention to action

My preferred conversion chain is: notice → name → compare → compress → build → publish → teach → host. That is one reason this site includes software pages, craft pages, services, recipes, play, and public notes. They are different outputs from the same discipline.

Kernel

The kernel holds the durable pieces: Spw operators, route conventions, semantic component patterns, accessible HTML/CSS rules, portable seed shape, and the small set of names that should not drift every time the surface gets more imaginative.

• Spw operator grammar and pronunciation: swoop.
• Stable component primitives: frames, cards, chips, figures, registers, prompts.
• Route contracts that make pages readable to humans and tools.
• Seed package conventions that can travel through .spw folders.

Lattice

The lattice is where projects cross-pollinate: spw-workbench, spw.quest, texture.website, lore.land, trope.wiki, factshift.com, RPG Wednesday, image studies, math routes, recipes, and component experiments. Each should remain local, but not isolated.

The lattice lets a visual motif become a component, a component become a lesson, a lesson become a route, a route become a printed packet, and a packet become a collectible seed.

Projection

A projection is a local view of the same deeper grammar. A homepage can project orientation. An about page can project identity and method. A lore page can project scene. A texture page can project material. A workbench can project parser state.

Public contract

The public site should help a new reader understand what the work is, help a collaborator find useful entry points, help a model preserve context, and help future publishing surfaces inherit meaning without flattening the system into a portfolio blurb.

.spw package

A portable seed package should carry the smallest useful bundle: name, intent, operators, route anchors, visual cues, prompt cues, dependencies, and enough notes for another surface to reconstruct the local meaning.

Print bridge

The same seed should be able to become a card, booklet, zine page, sticker, table prop, or Boon Square. Print is not a nostalgia layer here. It is a way to make digital semantics easier to hold, gift, annotate, and revisit.

Texture surface

texture.website is the neighboring surface for material cues, tactile language, style contagion, and interface texture. It should help the kernel avoid becoming sterile while keeping the aesthetic inspectable.

Lore surface

lore.land is the narrative and publishing projection: where scenes, characters, speech bubbles, enchantment, print artifacts, and RPG Wednesday materials can become public culture instead of isolated notes.