Cod3xDocs
guide

Good Designs

Design studies about reducing difficult systems to small, durable contracts.

Cod3x has a shelf for failures. It should also have a shelf for designs that worked unusually well.

These are Design Studies, not a catalog of patterns to cargo-cult. Each study starts with a problem that looks larger than the code that eventually solves it, then follows the reduction that made the solution composable. Some are Design Genealogies: they follow a small trick across projects until repeated requirements, failures, and reuse earn it a more general form.

The teaching order is deliberate:

  1. explain the problem in plain English;
  2. show the tempting complicated design;
  3. show the smaller question the next layer actually needs to answer;
  4. name the formal design principle only after the reader can see it;
  5. return to the real implementation and its tradeoffs.

Concrete first. Formal second.

Start here

  1. 01 Reduce the Problem Ask the smallest useful question.
  2. 02 Playlist Eligibility Put policy behind the smallest expressive contract.
  3. 03 Move Stable Work Cold Compute stable facts when they become stable.
  4. 04 NullFunction to StateMachine Let representation grow only when state earns it.
  5. 05 Delete Fake Objects Remove machinery with no real identity, ownership, or lifetime.

Choose a branch

The five-step path teaches the core instinct: make the question smaller, put work where it belongs, and do not add machinery until it earns its existence. The branches let readers choose depth without turning the section into assigned reading.

All studies

StudyThe reduction
Reduce the ProblemAsk what the next layer actually needs instead of modeling everything the current layer knows.
S3maphore Playlist EligibilityPlaylist conflict resolution becomes an eligibility callback plus generic priority ordering.
CamHelperT4rg3t5 camera logic becomes a reusable interface after real consumers prove the boundary.
ImageAtlasRepeated frame arithmetic becomes a domain object with a small vocabulary.
Local HandlersSame-context synchronous observation stays local instead of becoming another engine event.
Move Stable Work to the Cold PathStable playlist order is established at load time instead of repeatedly during resolution.
I.s3.lfCache expensive engine-backed values once, bind the attached object once, and expose convenient table-shaped access.

Genealogies

GenealogyThe shape of the evolution
NullFunction to StateMachineEmpty callback → swappable handler → named states and explicit transition timing.
Event-Driven S3maphore ResolutionPoll everything → identify invalidation events → pay for the cases event-driven state makes possible.
PlaylistRulesSemantic rule questions → shared cache helper → explicit invalidation → private machinery.
ProtectedTableCompose storage-backed settings, transient state, and methods → remove synchronization plumbing → harden the reusable boundary.
Actor SchedulerUnbounded actor scanning → bounded batches with an explicit freshness target.
StaticCollectionEngine objects → data shaped for rules → incremental work with explicit stale-result authority.
Delete Fake ObjectsDecorative constructors and nested shapes → ownership, lifetime, and state made explicit.
Earned Shared InfrastructureSpecific solution → repeated use → extracted H3 contract.

More material

The same instinct appears elsewhere in the manual. Generation counters give deferred work one identity instead of trying to cancel every stale operation. Static Switching System's pipeline boundary keeps two different kinds of replacement from becoming one ambiguous rule language. H3UI is another promising study in keeping a reusable UI vocabulary above raw openmw.ui layout construction.

The point is not that every problem wants a predicate, a facade, a state machine, or a generation number. The point is to look for the smallest contract that preserves the decision the system actually has to make, then let reality—not taste—earn the next layer of machinery.