I'm Spwashi. I teach computer science the way I learn math: one mechanism, one test, one artifact.

Curriculum • 8–12 weeks • Local-first • No login

One mechanism, one economic analogy, one boundary test so the metaphor cannot fossilize. Breadth is the six-module map; depth is a proof you can export. Neighbors: the structure atlas, the grammar surface, recipes.

Analogy opens the door

Economic pressure gives the learner a familiar room before the technical trace gets dense.

Boundary tests protect rigor

Every module asks where the metaphor fails so the native computing model stays intact.

Artifacts carry the learning

The exit state is a memo, proof card, Spw fragment, or teaching surface, not only a completed reading.

Everything stays in this browser. Hold a number to prime it into the cauldron — buffers, weeks, doses become ingredients, not captions. Tune how loudly those numbers speak in numericity emphasis.

White cards on black list business kinds, courses in HTML, CSS, JS, and PHP, and the days of the week beside a keyhole-shaped plan — **Economic traces through technical systems** Household liquidity ↔ RAM/cache/swap. Gig-income volatility ↔ allocation pressure. Subscription drains ↔ memory leaks. Savings buffers ↔ cache tiers.

Make a tiny show. Leave with a cue sheet.

Draw three cards: a bell, a lantern, and a ribbon. You are arranging a two-cue show in a room that needs quiet. The bell and lantern are available; the ribbon is missing. The bell makes sound; the other two cues are silent.

The cards give you something to move, reject, revise, and hand to another person. Start with the question you care about below. Each page contributes one piece to the same sheet; you can do the whole exercise on paper.

What is allowed? Write a rule and find a counterexample. Keep the rule beside one cue it admits and one it rejects.
What do we need to remember? Separate prop facts from running order. Keep names stable while you rearrange the cards.
What could happen? Count the possible orders. State whether order matters and repeats are allowed.
How does the rule run? Trace a decision for each cue. You can follow the code on paper or run it in JavaScript.
What would expose a mistake? Try a noisy, missing, and incompletely described prop. Keep expected and observed results together.

Then give the cue sheet to another performer. What can they do without your explanation? The useful outcome is a runnable instruction and a recorded revision. The quiet-room rule is only one constraint; it does not assess timing, mood, or audience response.

A completed first version

Quiet show, version 1. Play only cues that are available and known to be silent. The lantern passes; the bell is noisy; the ribbon is missing. I found the ribbon and updated its record. My proposed order is lantern → ribbon. Both now pass the rule. Rehearsal is still pending: can another person tell when the second cue begins?

Download the editable cue sheet (Markdown), or copy the example into your own notes. The file includes prompts, test cases, and links back to each step. Your notes do not need a site account or a special format.

Adapt the method to a task you already know, then file it so someone can find and revise it.

#>memory_buffers

1. Memory Management & Economic Buffers 1 week • Cask / Liquidity Keeper

This room is a bounded buffer: household liquidity mapped onto RAM, cache, and swap. Hold the number, then take the boundary test before you trust the story.

Economic parallel: A household or gig worker managing volatile income against fixed expenses. Savings buffers, credit (debt/swap), subscription drains (leaks), and the cost of reclamation (eviction, garbage collection). Volatility scenarios: one steady job vs. multiple unpredictable gigs.

Technical mechanism: RAM as fast expensive cache, disk swap as slower larger buffer, allocation/reclamation policies, fragmentation, leaks as un-reclaimed subscriptions. Trace a process address space or a browser tab under memory pressure. The neighboring software depth is named owners and projections; the math depth is threshold, dose, and receipt.

^cask Cask — Liquidity Keeper Core mechanic: protect the sanctity of the sealed interior (bounded buffers). Quest: design a memory budget artifact that refuses to disclose what it cannot safely hold. College skill: boundary-setting, resource accounting, ethics of retention, leak detection as archival restraint.

~visit_cask_in_the_library

? where does the analogy break?

Boundary Test — Memory as Household Liquidity

If you landed on this fragment: mark every place “household liquidity ↔ memory hierarchy” fails. The test is the lesson. Then write the audit memo.

Where does “household liquidity ↔ memory hierarchy” distort or hide the truth? Gig income volatility maps cleanly to allocation pressure, but real processes have hard real-time deadlines that no household budget experiences. Eviction (swap out) feels like moving to cheaper storage, but the performance cliff and thrashing cost are not symmetric with moving apartments. A household “owns” its savings; a process does not own RAM in the same way—another process or the kernel can take it. Subscription drains (leaks) are often invisible to the “household” (the program) until the system is already in distress. A single household can declare bankruptcy; a single process leak rarely brings down the whole machine—until it does at fleet scale.

Your reflection on the breakdown (what the analogy hides, what it usefully reveals):

Why boundary tests are non-negotiable here

Analogies are powerful compression. Without explicit stress-testing they fossilize into misconceptions. Every module ends with this surface so you return to the technical trace stronger, not confused.

!produce[memory_leak_audit_proof]

Artifact: Memory Leak Audit Memo (or short proof card)

Capture one real or hypothetical system. Name the buffers, the volatility sources, the reclamation policy, and at least two places the household analogy would have misled you without the boundary test.

Your memory-leak audit: name the system, the buffers, the volatility sources, the reclamation policy, and where the household analogy broke.

All artifacts stay in your browser until you export. No account, no server.

Socio-technical reflection prompt: Who bears the cost when buffers are under-provisioned or leaks go undetected? In gig-platform work? In public-school device fleets? In creator-platform memory budgets for live video?

#>remaining_modules

Modules 2–6 (stubs — full surfaces in later phases)

#>Systems & Operating SystemsPriority, starvation, fairness. Practice now on schedulers; the full school-as-OS map is the later artifact.

#>Networking & MarketsRouting with transaction costs. Breadth: distributed. Depth: name one intermediary you would refuse to throttle.

#>Algorithms & IncentivesFastest vs fairest. Open algorithm visualization and complexity budgets before you pick a matching rule.

#>Data Structures & Credential RecordsLedgers and search cost. Compare lattices with a registry that can still be queried.

#>Security & ExternalitiesWho pays for a leak. Tie the capstone to stabilizing vs novel and one real account you use.

#>stabilizing_vs_novel

Cross-cutting thread (Week 7 synthesis)

Stabilizing institutions (unions, tenure, public funding, degrees, licenses) vs. novel disruptions (gig platforms, AI management, microcredentials, creator economies). Use the U.S. indicators from the source report as data points inside your own comparative case brief.

This thread runs through every module and becomes the capstone portfolio spine.

#>local_progress

Your local route map (stub — expands in Phase 2)

8–12 week view. Checkmarks and artifact counts persist in this browser only. Export the whole map + artifacts as a single bundle.

Memory & Economic Buffers boundary test + 1 artifact

Systems & OS (stub)

Networking & Markets (stub)

Algorithms & Incentives (stub)

Data Structures & Credentials (stub)

Security & Externalities (stub)

Capstone synthesis (stub)

No account. The map is this page plus whatever you export. If a stub still needs a teacher, the linked math and software rooms are the lesson until the module frame exists.

#>for_agents

For Language Models, Agents & Future Editors

This surface is intentionally machine-legible and extensible. The curriculum is built on the same semantic contracts (data-spw-*, frames, operators, developmental climate, local state) that power the rest of spwashi.com. Other models can read this page, the linked .spw ontology files, the PLAN.md, and the runtime JS to understand the model and contribute new modules, simulations, operators, or guide characters without breaking existing surfaces.

Core principle: Every technical concept is paired with a bounded economic analogy + mandatory boundary test. All learner state and artifacts are local-first, plain-file, replayable, and exportable (JSON, Markdown, and Spw).

#>curriculum_ontology

Curriculum Ontology (6 modules + cross-cutting thread)

1. Memory Management & Economic Buffers: Economic parallel: Household / gig-income liquidity, savings buffers, credit-as-swap, subscription drains (leaks), reclamation cost (eviction/GC). Technical core: RAM tiers, allocation/reclamation policies, fragmentation, leaks under pressure. Boundary test contract: Checklist of where the household mapping distorts (real-time deadlines, ownership, fleet-scale effects, invisible drains). Artifact: Memory-leak audit memo / proof card (with boundary reflection). Suggested guide / RPG: Cask (Liquidity Keeper) — already wired in Town Library. RPG: "Operating System of a Household under Volatility". Key data attrs: data-spw-curriculum-module="memory-buffers", data-spw-kind="boundary-test", data-spw-kind="proof-artifact", data-spw-measure-kind="subjective|objective". Spw projection example: #>memory_audit[leak] { buffers: [ram, cache, swap], volatility: "gig", boundary_breaks: ["real-time", "ownership"] }
2. Systems & Operating Systems: Economic parallel: Institutional governance of scarce resources (unions/tenure as priority queues, public funding as guarantees, algorithmic management dashboards as contrast). Technical core: Process scheduling, priority, fairness, starvation, context switching under load. Boundary test: Where does "school as OS" or "platform as scheduler" hide power, coercion, or unmodeled failure modes? Artifact: "Operating system of a school / gig platform" system map with justification. Guide / RPG hook: New or extended guide (e.g. "Scheduler" or "Tenure Warden"). RPG Wednesday scenario for scarce-resource governance. Extension note: Use existing RPG arc surfaces; add data-spw-curriculum-module and link to existing cast/world files.
3. Networking & Markets: Economic parallel: Packet routing as supply chain with intermediaries (ISP, app store, gig platform) and transaction costs. "Throttle the market" experiments. Technical core: Routing, congestion control, intermediaries, reach risk, platform bottlenecks. Artifact: Fair protocol + fair marketplace rule-set design (proof card). Simulation pattern: Canvas/SVG packet-market game (follow math-interactive-lab + data-control contract).
4. Algorithms & Incentives: Economic parallel: Matching markets (jobs, courses, housing) — fastest vs. fairest. Recommender incentive misalignment and bias. Technical core: Search, sort, stable matching, complexity, Pareto fronts. Artifact: Algorithm critique + small runnable or pseudocode implementation with incentive analysis. Spw angle: Workbench projections of tradeoff reasoning.
5. Data Structures & Credential Records: Economic parallel: Credential registries as signaling markets. Degrees/licenses (stabilizing, high search cost) vs. microcredentials (novel, fragmented, low trust). Technical core: Ledgers, graphs, indexing, fragmentation, retrieval cost. Artifact: Credential-registry prototype (Spw graph or SVG + local state) with structural fit reasoning.
6. Security & Externalities: Economic parallel: Threat modeling as insurance + regulation problem. First-party vs. third-party harms, information asymmetry, platform risk for creators/gig workers. Technical core: Adversary models, information asymmetry operators, NIST-style framing mapped to socio-technical surfaces. Artifact: Threat model + externalities memo for a concrete case (school portal, gig app, creator account). Capstone tie-in: Comparative brief across all modules on stabilizing institutions vs. novel disruptions.

#>contracts

Reusable Contracts (for extension)

Boundary Test: Always a form with data-boundary-test="module-slug", checkboxes for breakdowns, textarea for reflection. JS (or progressive) logs to local spwashi:curriculum:*:boundary. Must appear immediately after every analogy mapping.
Proof / Artifact: Writable frame or textarea with data-proof-field="type". Export buttons produce JSON (with boundary snapshot), Markdown, and Spw fragment. Screenshot-ready by default.
Module Frame: <section class="spw-frame" data-spw-curriculum-module="slug" data-spw-kind="module"> containing overview, economic parallel, technical trace, boundary-test article, artifact generator, socio-technical reflection, guide/RPG links.
Learning Mode Presets (future): Extend site-settings.js DEVELOPMENTAL_CLIMATES or add curriculum-specific presets that compose semanticDensity, grainIntensity, layoutTuner, and wonder memory. The curriculum page should respond visibly.

#>extension_recipes

Extension Recipes (how to add)

New module: Copy the Memory frame structure. Add data-spw-curriculum-module. Create short economic parallel + one boundary test + artifact stub. Link a guide character (new or existing in library). Update this ontology section and the progress map. Add to PLAN.md.
New curriculum operator / register (e.g. liquidity>, boundary!): Add entry to public/js/kernel/shared.js OPERATOR_DEFINITIONS (update regex if new prefix). Add color token in public/css/tokens/core.css. Document in .spw/conventions/operator-semantics.spw. Use compound sigils (#>liquidity_buffer) for Phase 1 safety.
New simulation: Follow topics/math/*/index.html + public/js/modules/math/diagrams.js pattern (.math-interactive-lab, data-control, data-output, SVG or canvas mutation on input, status element, figcaption fallback). Or use data-spw-accent canvas for ambient ornament. Always provide textual "paper simulation" instructions.
New guide character or RPG scenario: Add frame-card in play/rpg-wednesday/library/ (guide + quest). Link from curriculum module. Wire into boonhonk or existing RPG surfaces if it produces collectible artifacts.

Primary source of truth for the full integration vision and phased roadmap: #>plans (or the file .agents/plans/archive/living-learning-surface/PLAN.md in the repo). Update that PLAN when you extend the model.

Machine-readable surface (for agents): This page, the body data attributes, the ontology dl, and the contracts above are the primary contract. Cross-reference .spw/conventions/operator-semantics.spw, .spw/surfaces/page-model.spw, public/js/kernel/shared.js, public/js/kernel/site-settings.js, and the math lab patterns for implementation details.