C.W.K.
Stream
Lesson 04 of 04 · published

Fixed Surfaces Beat a Plugin OS

~11 min · fixed-surfaces, reuse, window-model

Level 0Lost in Finder
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"Six features that reuse four layers is a product. Six features with six private engines is a swamp."

The Shape on Screen

Before the abstractions, picture the window. A customizable toolbar on top. A collapsible left rail: a Selection Basket drop stack above a source list of devices, shared volumes, favorites, and recent items. Then the browser split — Pane A and Pane B, each with its own tab strip, breadcrumb, list-or-icon browser, and a resizable Preview/Info inspector dock. Exactly one pane is active; exactly one tab is active in each pane. That geometry is fixed. It doesn't rearrange itself, and users can't bolt panels onto it.

Six Families, Four Layers

The 1.x roadmap adds six fixed feature families: source-list ergonomics, named workspace presets, Batch Rename, the Selection Basket, the Size Browser, and Finder tag/color-label editing. Here's the discipline that keeps them from metastasizing: each one is a new client of the same four canonical layers — workspace, location reference, enumeration, and the operation engine — and never a new engine of its own.

What That Buys

Batch Rename doesn't invent a rename path; it submits normal immutable operation plans. The Selection Basket doesn't stage bytes; it stores ordered location references. The Size Browser doesn't build a second directory catalog; it derives a cancellable scan. Presets don't cache directory contents; they snapshot references. Because everything routes through the same audited layers, a bug fixed in the operation engine is fixed for all six features at once — and none of them can lose a file in a way the core can't.

Fixed surfaces inherit canonical boundaries. A new feature earns its place by reusing the workspace, location, enumeration, and operation layers — not by forking them. The test for every future addition: does it introduce a second browser truth, a second mutation path, or a module lifecycle? If yes, it's rejected, no matter how useful it sounds.
Track cleared. You now hold the thesis (trustworthy mutation over parity), the family placement (file workbench, no own brain), the bounded scope (the useful thirty percent), and the reuse discipline (fixed surfaces, four layers). Everything after this is the machinery that makes 'never lose a file' true.

Code

The fixed window geometry·text
  +----------------------------------------------------------+
  |  toolbar: navigation / view / dual + inspector / actions |
  +--------+-------------------------+-----------------------+
  | basket |  Pane A                 |  Pane B (collapsible) |
  | -------|  tab strip + breadcrumb |  tab strip + bcrumb   |
  | source |  list or icon browser   |  list or icon browser |
  | list   |  Preview / Info dock    |  Preview / Info dock   |
  +--------+-------------------------+-----------------------+

  One pane active. One tab active per pane. Geometry is fixed.
Each 1.x family reuses, never forks·text
  FAMILY                 REUSES (never a new engine)
  ------                 ---------------------------
  workspace presets      workspace + location refs
  Batch Rename           operation engine (normal plans)
  Selection Basket       ordered location references
  Size Browser           enumeration (cancellable scan)
  tags / color labels    operation engine (metadata plans)
  source-list ergonomics workspace + mount observation

  Zero new mutation paths. Zero module lifecycles.

External links

Exercise

Design a seventh feature you think Waygate should have. Now apply the test: can it be built by reusing the workspace, location, enumeration, and operation layers, or does it need a new engine? If it needs a new engine, redesign it until it doesn't — or conclude it doesn't belong.
Hint
Most genuinely-good file-manager features (a 'recent moves' view, a duplicate finder, a quick-filter) turn out to be new clients of enumeration + the journal, not new engines. The ones that fail the test — a plugin loader, an embedded terminal — are exactly the ones that would break the safety story.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.