0.1 Body-Carried Styling Law

Route now follows the same body-carried styling doctrine established for the current PenPals / Brancher absorption path. The essential style that makes this Pen readable is not stranded in the document head. It is carried inside the body, at the top of the donated body content, so that a Gather operation which extracts only the body still receives the Pen's visual grammar.

This matters because Route is not merely viewed as a standalone page. Route is also a source Pen that may be absorbed by PenPals, Brancher, or another doctrine carrier. In that setting, the outer document may supply its own head, title, and global shell. Route must therefore bring its local ink, panels, code blocks, spacing, and explanatory bands along with the body that is actually gathered.

Pen as standalone page:
    head style may work

Pen as gathered body:
    body style must travel with the body

Route 012:
    essential visual law is carried in the body

1. Definition and Scope

Route describes how intent enters the system and how that intent is carried through domains, panels, controllers, mantles, files, and sinks. In a conventional web application, routing maps a path to a page or action. In PhoMaster, routing is wider than that. A route may begin as a URL, but it may end as a warmed panel, a filesystem intention, a FireDance-observed artifact, or a controlled sink.

The Route Pen therefore covers Muq, door tokens, WarmWelcome, sub-panel dispatch, client intake, domain dispatch, and the migration path from the older Tell/Rell command switch into smaller, meaningful route authorities.

2. Muq as Routing Engine

Muq is the active interpreter of Route. It is not simply a page endpoint. It is the layer that receives intent and determines whether that intent should become a view, a deck state, a hosted route, a warmed panel, a sink, or a punt to some other surface.

The modern shape of Muq includes soft-routing parameters such as view, deck, origin, mode, step, intent, and portal. These allow one entry surface to resolve into different operational states without requiring the public address to know the internal panel or controller layout.

?view=prn
?view=wowdeck&deck=dtfhub
?command=door&door=PrintDocs

The important shift is that Muq is no longer just a dispatcher. It becomes a governor. It decides not only where a request goes, but whether the request is serviceable and how failure should be preserved.

3. Door Doctrine

A door is the public knock point of a route. It is not the panel itself, not the file itself, and not the slot itself. The door token is the stable identity presented to the caller.

?command=door&door=<DoorToken>

This lets public addressability remain stable while the internal target can be rewired. A door may resolve to a WowDeck slot, an MVC view, a hosted route, a documentation Pen, a remote host, a maintenance surface, or a sink.

The door model matters because it separates public vocabulary from private implementation. Public users knock on names. The system resolves those names through wiring.

4. WarmWelcome

WarmWelcome is the first lawful contact surface after a door knock. It is not a decoration or a landing splash. It is a threshold with intelligence.

WarmWelcome may inspect readiness, BasicData, Parentop state, service availability, prior position, and requested intent. From there it can pass the user onward, hold them, explain a warning, restore prior position, or route to sink.

door knock
  → Muq
  → wiring
  → WarmWelcome
  → sub-panel / review / resume / sink

5. Sub-Panel Dispatch and Wow Residency

A route is not complete just because a browser landed somewhere. In the Wow model, a route completes when it reaches meaningful focus. That focus may be a warmed panel, a hosted cshtml surface, an iframe-backed app, or a resident actuator panel.

WowDeck makes routing resident. Panels can remain warm, preserve their state, and receive navigation without destruction. This is why Muq and WowDeck belong together: Muq resolves intent, while WowDeck preserves the operational surface that intent reaches.

6. Parenting and Route Residue

Route does not move without memory. Parentop, Parental, and local BasicData carry route residue across frames and panels. This makes routing more than a URL handoff. It becomes a state inheritance pattern.

• Parentop is the top-level host state.
• Parental is the relative parent state.
• BasicData is the local carrying context.

This is why a panel can react to a help request, resume a prior position, or interpret who the visitor is without every detail being repeated in the URL.

7. Sink Doctrine

Sink is the lawful receiving basin for unresolved, unavailable, warming, denied, degraded, punted, or maintenance-bound route requests. It is not merely an error page. It is controlled termination.

A good sink preserves the original door, view, deck, origin, intent, and reroute information. It explains the condition and offers retry, return, or continuation.

unavailable
warming
rerouted
punted
denied
suspended
degraded
maintenance
unknown

The sink gives every route a lawful way home. That is the difference between a failed navigation and a preserved system state.

8. Rell and the Older Command Surface

Rell, formerly Tell, shows the older route grammar before it was separated into named controllers and route doctrine. It was a large command switch, but it was not meaningless. It encoded a consistent pattern: accept request, parse intent, write file state, redirect or return.

The Rell split revealed that many apparent controller actions were really route translations. Messaging, gating, commerce, upload, media, fence, print, and diagnostics all followed the same deeper rule: HTTP intent becomes filesystem intent.

Route therefore includes the migration of Rell. Rell is the evidence that routing, state, and actuation were already tied together; Muq and Door doctrine make that relationship explicit.

9. Filesystem as Route Memory

Many routes do not end in a page. They end in a file. In Rell and the broader PhoMaster system, files act as durable memory, queue entries, state witnesses, and actuator instructions.

A print route may emit a PRN intention file. A message route may emit an MMS or SMS payload. A fence route may emit tracked coordinates. A cull or deploy route may emit ordinated audit witnesses.

Files are not just storage. They are visible route state.

10. Domain Dispatch

Route also includes hostname dispatch. A domain can be a face, a door, a redirect, or a route selector. The old QireUp-style dispatch showed this in primitive form: a hostname was inspected and sent to the appropriate public face.

The modern version should preserve that power while moving intent resolution toward Muq and Door wiring. Domains remain important, but they should not hardcode all meaning forever. They should enter the route grammar.

11. Documentation Route vs Operation Route

The Route Pen also clarifies a separation already used by Print and Pho.Rip: documentation and operation are not the same route.

• Documentation lives as a Pen, usually an index.html under a named folder.
• Operation enters Muq, WowDeck, an actuator surface, or live domain behavior.

This keeps the document explaining the system separate from the live system carrying out the work. A Pen can embed an operational socket, but it should not be confused with the operational route itself.

12. Ordination and Route Delivery

Route delivery follows file-level ordination. The live file and the audit file exist side by side. Deploy pushes to the intended targets. Cull retrieves from the mutable authority.

For the Route Pen, the current delivery root is directly:

Route\index.html

not:

docs\Route\index.html

The current deployment destinations are:

E:\___Fire\Route
C:\___Fire\Route
G:\My Drive\PhoMaster\Route

The C route is the mutable authority. E and G are propagated mirrors. Cull pulls only from C so that edits made to the working authority can become the seed for the next ordination.

13. CEF Browser Space — Route as Runtime Normalizer

The newest Route discovery is that Muq does not merely resolve navigation. It can instantiate a controlled browser environment and make that browser the true runtime behind the route. This is a major expansion of Route doctrine. A visitor may arrive through an old, limited, non-Chrome, locked-down, or otherwise unpredictable browser, but the operational surface does not have to depend on that visitor browser as the final application runtime.

Instead, Muq can route the request into a DownloadView or AgentView surface that commands a CEF browser instance. The visitor-facing browser becomes a viewing aperture, remote control, or intake shell. The CEF browser becomes the stable app-space where the real DOM, script execution, downloads, iframe probing, source capture, and state inspection occur.

visitor browser
  → Muq route
  → DownloadView / AgentView
  → CEF sub-browser
  → controlled Chrome-class app-space

This means Route can become a compatibility shield. Front-facing content can remain plain, conservative, and legacy-adaptive while the inner side uses the most advanced route, probe, panel, and Agent techniques. That is not a small convenience. It changes the burden of UI design. The public surface does not have to demand that every visitor bring the right browser, the right runtime, the right extension posture, or the right JavaScript environment. Route brings the runtime.

14. Foreign Browsers and the Plain-Vanilla Face

In ordinary web development, every serious application eventually collides with browser requirements. One browser supports a feature, another distorts it, a mobile browser delays it, an old browser lacks it, a locked-down corporate browser blocks it, and the developer is forced into warnings, polyfills, support tables, and compromise.

The CEF-routed model lets PhoMaster treat the outside browser differently. It does not need to be trusted as the application engine. It only needs to be good enough to reach Muq, receive a conservative surface, and participate in the visible exchange. The demanding work happens inside the routed browser space.

This creates a new rule:

Do not trust the caller’s browser to be the app runtime. Let Muq instantiate the app runtime.

That rule is especially powerful for public or customer-facing systems. A DTF shop customer, in-house visitor, remote customer, field operator, or older workstation may each arrive with a different browser reality. Route can still present a plain, non-breaking face while preserving a consistent inner system.

15. Persistent Inner Stage

The routed CEF browser is not just a compatibility trick. It also supports the deeper PhoMaster goal of persistence. The inner browser can remain warmed, inspected, and governed even if the visible caller drifts, refreshes, reconnects, or changes posture.

This solves a persistent problem in ordinary web applications: the visible session and the operational session are too tightly bound. If the browser tab reloads, the app often loses living state. If Angular is dangling, route state may be half-present and half-gone. If a security transition interrupts the user, the application may have to reconstruct itself from fragments.

Route can now separate those concerns:

• the visitor connection is the outer aperture,
• the Muq route is the addressable command path,
• the CEF browser is the persistent inner stage,
• the Agent layer inspects and acts within that stage,
• and Sink preserves fault or disconnect meaning when the route cannot complete.

This gives session reconnection a better foundation. The system is no longer trying to save every fragile thread in the visitor’s browser. It can reconnect the visitor to a resident route-space that already exists behind the curtain.

16. DownloadView as Sub-Browser Workbench

The existing DownloadView is the right workbench for this model because it is already aligned with browser event monitoring, download observation, and staged navigation. It can become the visible control surface for a hidden or embedded CEF browser.

The older StdFrame vocabulary already points toward the required command set: create browser, navigate URL, get current location, get main source, get frame source, execute JavaScript, move back and forward, refresh, stop, and inspect download state. Route does not need to invent a new philosophy for this. It needs to wrap that proven vocabulary in Muq-accessible form.

AgentBrowserService
  CreateSession()
  Navigate(url)
  GetLocation()
  GetSource()
  GetFrameSource(frameName)
  ExecuteScript(js)
  GetDownloadStatus()
  Stop()
  Refresh()
  Back()
  Forward()

That service boundary lets Muq treat the CEF instance as a routable browser socket. It can load a target, wait for readiness, inspect source, probe frames, execute JavaScript, and return results without requiring the front-facing browser to carry that operational load.

17. Stage States: Static, Loaded, Ready, Stable, Probe

A routed browser is valuable because it can inspect a page at more than one activation depth. A raw HTTP fetch only sees source before runtime behavior. A normal visible browser shows the result but does not necessarily expose stable intermediate state. The CEF sub-browser can be commanded through stages.

static
  server-side source, before browser activation

loaded
  CEF has navigated and the main frame exists

ready
  document.readyState is complete

stable
  ready plus a quiet period after DOM mutation

source
  captured main-frame HTML from the active browser

frame
  captured named iframe or child-frame source

probe
  controlled JavaScript inspection or action

This matters for WowDeck, Muq, Print, Portal, Upload, and any future resident system. Agent can see not only what the file said at rest, but what the route became after startup. It can determine whether a panel is actually present, whether an iframe has filled, whether a button exists, whether a download began, whether a title-barb fired, or whether the route washed to Sink.

18. Title Barbs and JS Intake

The CEF layer does not discard the older FireDance title-barb approach. It strengthens it by placing it beside modern JavaScript intake. In the older model, page content could actuate FireDance by changing the document title with a prefix. The title was not visible in the bareback browser, so it became a hidden command bus.

=_=status payload
=/=final payload
#_=focus payload
@_=sendkeys payload
*=*client payload

That channel remains useful because it is simple, deterministic, and easy to observe. It allows page-to-host signaling even when more elaborate bridges are unavailable or undesirable.

CEF also provides the reverse direction: direct JavaScript execution into the page. Route can now use both channels:

• title barbs as a low-friction control and event plane,
• JavaScript execution/evaluation as a rich data and probing plane.

The best hybrid rule is to use the title as a signal or trigger, and JavaScript evaluation for larger structured data. A title may announce that data is ready; Agent can then execute JavaScript to retrieve JSON from the page.

19. Agent Pipeline Through Muq

With a routable CEF browser, Agent no longer has to reason only from static documents or visible screenshots. Agent can ask Muq to instantiate a browser stage, navigate, wait, probe, and report. This is the beginning of an actual Agent pipeline.

Agent request
  → Muq route
  → DownloadView / AgentView
  → CEF browser session
  → staged navigation
  → DOM/source/frame/probe capture
  → Agent interpretation
  → Sink or continuation

The route may be direct, such as /Muq?view=download&mode=agent, or it may pass through a door token, such as an AgentProbe door. The exact public shape can evolve, but the responsibility is clear: Muq governs access, CEF hosts the active page, Agent observes and acts, and Sink preserves failures lawfully.

20. Browser Virtualization Through Route

This doctrine can be stated simply: Route can virtualize the browser. The caller’s browser does not disappear, but it is demoted from final authority. It becomes the outer human aperture. The inner Chrome-class browser becomes the consistent runtime.

That creates a powerful practical outcome. PhoMaster can keep front-facing complexity low while retaining advanced inner capability. Public pages can be plain. Operational panels can be resident. Agent can probe. Downloads can be monitored. Frame sources can be captured. Scripts can be injected. Title barbs can be interpreted. A customer’s browser can wander while the inner stage remains available for reconnection.

This is why the Route Pen must now include CEF doctrine. Route is no longer only movement from page to page. Route can now create a controlled application environment behind the route and keep that environment warm.

21. Operational Payoff

The payoff is large enough to justify the approach broadly:

• legacy browsers receive a conservative face instead of a rejection,
• complex browser requirements move inward to a controlled CEF runtime,
• sessions reconnect to a resident stage instead of a fragile tab,
• Agent receives a stable object of inspection,
• downloads and iframes become observable route events,
• and failure can be washed into Sink instead of becoming raw browser confusion.

This is not anti-web. It is a route-governed way of using the web more reliably. The public browser remains useful, but the system no longer depends on it as the one place where all truth must live.

22. Revised Route Doctrine

The Route Pen now has a wider statement:

Route is the movement language of PhoMaster, and Muq is its interpreter. Doors name entry, WarmWelcome mediates readiness, Parenting carries residue, WowDeck hosts residency, Sink preserves failed traversal, and CEF-backed Agent browsing supplies a persistent inner app-space independent of the visitor browser’s limitations.

That is the new plateau. Route no longer only sends a user somewhere. It can stage the place, warm it, inspect it, preserve it, and reconnect the user to it later.

23. Muq Operational Upgrade — Resident CEF Socket

The Route doctrine has now crossed from architecture into operational Muq implementation. The important move was not to bolt a browser onto one special page. The move was to treat the CEF browser as a shared resident route capability. A route that instantiates a Muq form can now be prepared to carry a CEF socket, and that socket can be enabled, sized, navigated, inspected, and used by Agent without forcing every future route to reinvent the browser harness.

The practical delivery added the first version of that shared capability into Muq. The changed-files package introduced a shared CEF route socket partial, a CEF command controller, shared layout enablement, Agent and Download resident route enablement, HomeController URL parameter carry-through, and project-file awareness for the new components. One deployment placement issue was discovered: the Web project was delivered one level too high, beside src, when it properly belongs at src\Web. After moving that folder into the correct position, the rebuild was clean.

This placement correction matters for the ordination record. The Muq source tree should be understood as rooted with Web under source:

Muq
  src
    Web

Future Deploy and Cull references for Muq must preserve that location. The route Pen itself is not changing the Muq code in this ordination; it is recording the operational lesson so the next Muq design iteration starts from the correct filesystem understanding.

24. Shared cshtml as Browser Capability Carrier

The shared cshtml layer is the correct place for the CEF route socket because it is the common resident surface. If CEF is only placed in a single Download view or a single Agent view, it becomes a feature. If it is carried by the shared resident route shell, it becomes infrastructure.

This follows the same Route principle already used elsewhere: do not make the visible surface own the whole operation when a shared route layer can carry the recurring capability. A Download view can still be the immediate workbench. Agent can still be the probing intelligence. But the socket grammar belongs low enough that later surfaces can opt into it without duplicating the whole browser control system.

Muq shared cshtml
  → resident route surface
  → optional CEF socket
  → staged browser activation
  → Agent / Download / future route consumers

This turns the browser into a routable resource. The original route can use ordinary URL parameters to enable the socket, set the initial size, choose a target URL, request a stage, and decide whether the session should expose source, frame, status, or probe results.

25. URL-Driven Browser Enablement

The browser socket should be operable through clear, conservative route parameters. The route itself remains the authority; the front-facing browser only requests a staged resident capability.

/Muq?view=download&mode=agent&cef=1
/Muq?view=agent&cef=1&stage=stable
/Muq?view=prn&cef=1&target=<encoded-url>
/Muq?view=wowdeck&deck=dtfhub&cef=1

These parameters should not be understood as final syntax yet. They describe the grammar: enable, size, navigate, stage, inspect, and report. That grammar is enough to make CEF a standard part of Muq route behavior while leaving the exact controller contract free to evolve.

26. Agent and Download as First Consumers

Agent and Download remain the first natural consumers of this shared capability. Download has the right historical shape because it already concerns browser navigation, download observation, source access, and event monitoring. Agent has the right future shape because it needs a stable active DOM to inspect, not merely a raw source string or a screenshot.

The paired model is therefore:

Download
  visible workbench and browser event monitor

Agent
  interpretation, probing, staged inspection, route diagnosis

Shared CEF socket
  resident Chrome-class app-space hosted by Muq

Once this relationship exists, many future route surfaces can borrow the same power. Review surfaces can inspect what would happen before activation. Wow-hosted panels can be staged and measured. Documentation sockets can open a live operational route while keeping the Pen itself plain and stable.

27. Corrected Muq Ordination Note

The Muq delivery was functionally successful but revealed a packaging rule: changed files for the Web project must be delivered under src\Web, not as a sibling of src. The manual correction did not change the delivered code; it only placed the Web folder where the solution expects it. The rebuild confirmed the code was sound.

For the next Muq delivery, the package should preserve this shape:

pocketNNN
  Muq
    src
      Web
        Controllers
        Views
        Shared
        ...

The Route Pen records the lesson but does not issue a new Muq code package in this ordination. Muq code changes can wait for the next design iteration. The only delivery here is the updated Route Pen document, advanced by ordination.

29. Snapshot Capability — Visual Witness of Route State

The newest Muq advancement adds a third artifact class to the CEF route socket. Earlier Route doctrine already established that the resident browser can capture source and probe data. The snapshot addition means the system can now also preserve the rendered visual result of a staged navigation.

This is an important threshold because it lets Muq and Agent record not only what the page says internally, but what the browser actually became after layout, script execution, iframe activation, panel warmup, and visual settling. The snapshot is therefore a rendered witness of route state.

Muq route
  → CEF staged browser
  → target page navigates
  → DOM reaches selected stage
  → source captured
  → probe JSON captured
  → bitmap snapshot captured
  → artifact set written

The bitmap is not a decorative screenshot. It is operational evidence. It can show whether WarmWelcome appeared, whether a WowDeck panel truly slid into focus, whether an iframe filled correctly, whether a failure washed to Sink, or whether a customer-facing page reached the expected visible state.

30. Three Artifact Classes from One Navigation

A CEF navigation can now produce a more complete artifact bundle. The three classes should be understood together:

• Source artifact — current main-frame or child-frame HTML.
• Probe artifact — JavaScript-evaluated state, JSON facts, readiness data, and DOM measurements.
• Bitmap artifact — the rendered pixels of the living browser at the chosen stage.

Source tells what the browser contains. Probe tells what the browser knows. Snapshot tells what the browser shows. None of these alone is enough for the full Agent doctrine. Together they make the route inspectable from code, structure, and visible outcome.

source.html
state.json
screen.png

This makes the route state portable. A later reader, an Agent pass, a developer, or a support operator can inspect the same navigation state without having to recreate the live session immediately.

31. Snapshot as Ordnance, Not Ornament

The snapshot capability belongs naturally with ordination. A rendered state can become part of an audit set. It can be carried beside the live route result, compared across iterations, and used to verify that a route changed in the intended visual way.

That is especially valuable for Muq, WowDeck, and Print because much of their truth is resident and staged. A panel may be present in source before it is meaningfully visible. An iframe may exist before it has loaded the operational surface. A route may be technically complete while visually wrong. Snapshot closes that gap.

Source proves structure. Probe proves state. Snapshot proves visible arrival.

32. Stage-Aware Snapshot Timing

A snapshot should not be treated as a blind capture. It should be requested at a declared stage, just like source or probe capture. The minimum useful stages remain:

loaded
ready
stable
probe-complete
sink
fault

The most valuable capture for Agent work is usually stable: the page has loaded, scripts have had time to create the working structure, and the route has stopped visibly thrashing. For fault handling, a sink or fault-stage snapshot is equally important because it preserves the failure surface, not just the success surface.

This timing rule keeps snapshot artifacts meaningful. A premature bitmap may only prove that a blank shell existed. A stable bitmap proves that the route reached an interpretable visual condition.

33. Changed-Files Muq Snapshot Delivery

The Muq snapshot upgrade was delivered as a changed-files-only ordination. It carried the CEF controller and route socket changes required to expose snapshot behavior through the resident Muq browser surface, while preserving the corrected Muq source placement under Muq\src\Web.

The changed delivery advanced Muq with the snapshot-aware CEF pieces:

CefRouteController.cs
_CefRouteSocket.cshtml
AgentView.cshtml
DownloadView.cshtml

The doctrine lesson is the larger point: CEF is now not merely an active browser hidden behind a route. It is an artifact generator. It can turn a routed navigation into a durable set of source, state, and rendered image evidence.

34. Agent Use of Snapshots

Agent can now work with a staged browser in a more human-comparable way. It can ask Muq to navigate, wait, inspect, and then capture a visual witness. This lets Agent reason across the same layers a developer would examine manually: source, computed state, and visible result.

Agent request
  → Muq route
  → CEF browser session
  → navigate target
  → wait stable
  → capture source
  → capture probe JSON
  → capture snapshot
  → return artifact set

This is especially useful for the resident-route doctrine because the user’s outside browser is no longer the only place visual truth exists. The inner CEF stage can retain and document the visible condition independently of the visitor browser drifting away, refreshing, disconnecting, or failing to support advanced features.

35. Revised Artifact Doctrine

With snapshot support, Route artifacts should be described as a bundle rather than a single file. A route session may produce:

• the requested URL and route parameters,
• the resolved URL after redirects,
• the main-frame source,
• selected child-frame sources,
• the JavaScript probe result,
• the title-barb or console events observed,
• download status if relevant,
• and the rendered bitmap snapshot.

This makes a Muq route session into a reviewable object. It is no longer only a transient browser event. It becomes a carried witness of what Route did, what the page became, and what the system could see at the time.

36. Closing Doctrine

Route is the movement language of PhoMaster. Muq interprets it. Doors name it. WarmWelcome mediates it. Parenting remembers it. WowDeck hosts it. Sink preserves it when it cannot proceed. Rell proves that the old command world already held this grammar in disguised form.

The Route Pen exists so that routing no longer looks like scattered navigation. It becomes a doctrine of movement, meaning, and lawful termination.

0. Prelude — The Man Who Did Not Stop

There is a familiar image: a man moving quickly through a building, opening doors, passing through, never stopping long enough to leave a written message. Someone behind him asks why he did not leave a note. The answer is that he did not need to. He was the note.

Everything about him—what he carried, where he stepped, what he touched, which door he passed through—was already a message. The system did not need a note after the fact. It needed to observe the traversal.

1. Door Is Not Merely an Entry

In ordinary systems, a door is treated as an entrance: a URL endpoint, a page, a controller action, or a file. In PhoMaster, that is not enough. A Door is an addressable threshold that records traversal.

Door
  = addressable threshold
  = route node
  = traversal witness
  = pocket-drop event

A Door is therefore not merely something the request goes through. It is something that remembers the request went through. Once a Door remembers, the system no longer depends on central reconstruction, fragile session inference, or remote database lookup as the only source of truth.

2. From Logging to Shedding

Conventional logging is retrospective. Something happens, and a system writes about it. Door changes that model. Door uses shedding: as the traveler moves, complete local truth falls out at every node touched.

The note is not written later. The traversal sheds its own evidence as it proceeds. This is why the pocket-drop metaphor matters. Each node receives a complete pocket, and each pocket can stand alone.

3. The Pocket Doctrine

The pocket is the atomic unit of Door. Each node touched by traversal receives one. Not optionally. Not only at the final endpoint. Every meaningful node in the interpreted route receives enough local truth for audit, action, and accounting.

Every door touched receives the traveler's pocket.

That pocket contains the full request, the interpreted mantle, the node position, the route decision, and the outcome. It does not require upstream queries or cross-node stitching. The local pocket provisions the polling consumer with everything needed to react.

4. Inflow, Error, and Result Grammar

Door uses three output classes for route evidence:

This keeps the route grammar visible by file type. Inflow arrives as ordinary JSON. Error has its own error-son form. Result has its own zson form so a poller can distinguish raw arrival from finished consequence without opening every file first.

5. Rename Instantiation Law

If a poller sees a half-written file, the Door contract is broken. Therefore Door output must always be instantiated by rename.

write:  Ingress_abc123.json.tmp
close
rename: Ingress_abc123.json

write:  Error_abc123.eson.tmp
close
rename: Error_abc123.eson

write:  Result_abc123.zson.tmp
close
rename: Result_abc123.zson

This is the observer safety law. Pollers can use directory seek and extension detection without locks, without partial parse risk, and without becoming consumers of an unfinished artifact.

6. Door as Media Node

Door expands beyond token dispatch. A door token such as ?command=door&door=PrintDocs remains a valid public knock pattern, but Door also describes every media node that a routed traversal touches.

A URL such as:

child2.child1.f-ire.pho.rip/level1/level2?x=1

may resolve into:

F:ire\
F:ire\child1\
F:ire\child1\child2\
F:ire\child1\child2\level1\
F:ire\child1\child2\level1\level2\

Each folder in that walk can receive its own _route pocket:

_route\
  Ingress_*.json
  Error_*.eson
  Result_*.zson

7. Muq as Root Walker

Muq is the one who walks. Door is what records the walk.

Muq receives the incoming host, scheme, path, query, headers, user context, and route intent. It then decodes the host and path, resolves the mantle pinnacle, materializes the route nodes, writes ingress pockets, dispatches or sinks the request, and finally writes error or result pockets during retreat.

incoming URL
  → Muq root controller
  → decode host/path/query/hash
  → resolve Mantle pinnacle
  → materialize every node as folder
  → write verbose ingress at every node
  → execute / route / sink
  → write retreat result at every node

8. Mantle Pinnacle Table — The Current Situational Object

A DNS-resolvable pinnacle such as f-ire.pho.rip represents the public form of a Mantle pinnacle such as F:ire. But f-ire does not necessarily mean the literal hard drive F:\. It means the current F:ire mantle cwd locus.

That locus is determined by a current situational object: the Mantle pinnacle table. This table cross-references mantle pinnacles to their active drive or cwd settings.

This table is not a static publication chart. It is a live situational object. It tells the route walker where the mantle currently resolves in media.

9. BasicData, Parentop, and Parental Lookup

The Mantle pinnacle table belongs in window.BasicData at the level that knows the current mantle settings. A child frame or resident panel may not have the full table locally. Therefore the route intelligence must be able to climb through Parental and ultimately Parentop to find the BasicData that actually contains the pinnacle-to-locus mapping.

window.BasicData
  local context

Parental.BasicData
  immediate parent context

Parentop.BasicData
  topmost host / apex context

This is important because Door must not assume that the current iframe or panel is the authority. The authority is the nearest available BasicData context that carries the Mantle pinnacle table and session identity needed for the walk.

10. Routing Certainty and Window Identity

Door can be sure it is being routed when three identities line up:

• the incoming host resolves to a known Mantle pinnacle token,
• the BasicData hierarchy yields the current pinnacle table for that token,
• the active window identity confirms which frame, panel, or resident route surface is making or receiving the traversal.

This means window identity is not cosmetic. It tells the system whether the request is arriving at the apex, a child iframe, a resident Wow panel, a hosted route surface, or a Muq-controlled browser socket. The route can then decide whether to act locally, ask Parentop for authority, or sink the request as unserviceable.

11. Session Identity

Session ID is not the same thing as mantle identity. Mantle identity answers:

Where does this route live in media?

Session identity answers:

Which traversal instance is this?

Door needs both. The mantle table resolves the path. The session or request ID binds ingress, error, and result pockets together across all nodes touched by the walk. Without session identity, every node may still know the route, but the distributed pockets cannot be reliably grouped as one traversal.

A useful Door packet therefore carries both:

{
  "requestId": "door-20260430-...",
  "sessionId": "...",
  "windowId": "...",
  "mantleToken": "f-ire",
  "mantleName": "F:ire",
  "cwdRoot": "...",
  "nodePath": "...",
  "nodeDepth": 2
}

The request ID is the traversal stitch. The session ID is the continuity stitch. The window ID is the surface stitch. The mantle table is the media stitch.

12. Door and Parenting Residue

Traditional systems propagate state through parameters, headers, and sessions. Door does not reject those, but it does not depend on them alone. Every node pocket contains the full route context, and that context can include the relevant BasicData snapshot or reference.

This means downstream consumers do not have to ask where the request came from. The pocket carries enough residue to provision local action, audit, and accounting.

13. Door and Sink

When routing fails, Door does not permit a broken path. A failed route still becomes lawful arrival at Sink. Sink writes the error or result pocket back through the same node trail.

status:
  served
  sunk
  rerouted
  denied
  faulted
  maintenance
  warming

The failed traversal is therefore still inspectable. It still has a session ID, request ID, window identity, mantle token, node path, and result packet.

14. Door and Actuation

Door aligns with the older Rell/Tell grammar: web-shaped intent becomes filesystem-shaped state. Print writes intention artifacts such as /Work/Mms/Prt_*. Upload assembles temporary files before rename. Commerce writes order and purchase artifacts. Messaging writes SMS/MMS artifacts.

Door generalizes that pattern. It does not only dispatch a request; it leaves artifacts for asynchronous consumers to observe and act upon.

27. Left-Hand and Right-Hand Descendency

Door now recognizes two major forms of URL descendency. The first is the left-hand host descendency, expressed by dot-separated subdomain segments before the Mantle pinnacle. The second is the right-hand path descendency, expressed by slash-separated path segments after the host.

In a route such as:

child2.child1.f-ire.pho.rip/step1/step2/step3?some=this

the left-hand descendency resolves first:

child2.child1.f-ire.pho.rip
  -> F:ire\child1\child2

Then the right-hand descendency extends the route from that resolved locus:

/step1/step2/step3
  -> F:ire\child1\child2\step1\step2\step3

The important point is that the right-hand path is not lesser than the subdomain path. Once the Mantle apex and left-hand descent have produced the target route folder, the right-hand pathing becomes the relative branch below that final target. Every node in that branch is treated with the same Door rules: pocket-drop, Glue copy, filter evaluation, result retreat, and poller visibility.

28. Up and Down Filter Arrays

To prevent left-hand and right-hand path methods from being confused, Door segregates filter groups into Up and Down arrays. These are not arrays in the database sense; they are folder-instantiated method collections whose subfolders may be exact names or wildcard patterns.

Door\
  Up\
    Ch###e\
      In\
      Out\

  Down\
    step$\
      In\
      Out\

Up belongs to the host-side, dot-separated, reverse descendency. It applies while interpreting names such as child2.child1.f-ire. Down belongs to the slash-separated branch after the host and applies while interpreting names such as step1/step2/step3.

This separation gives Door a clean grammar:

Up:
  child2.child1.f-ire.pho.rip
  filters: Door\Up\...

Down:
  /step1/step2/step3
  filters: Door\Down\...

Both sides still use the same wildcard substitution law: $ means *, and # means ?. The difference is the side of the URL being interpreted.

29. Up Filtering — Host-Side Descent

Up filters operate on the left-hand DNS/subdomain descent. They are the filters for the part of the address that walks from the public Mantle pinnacle into its host-side children.

Door\Up\Ch###e\

A filter such as Ch###e may match a host-side node named Change. If the exact folder Door\Up\Change\ also exists, wildcard matches execute first in alphabetical order, and the exact folder executes last.

30. Down Filtering — Path-Side Branching

Down filters operate on the slash-separated path after the host. Once the route has resolved to a locus such as F:ire\child1\child2, the URL path /step1/step2/step3 becomes the branch F:ire\child1\child2\step1\step2\step3.

Door\Down\step$\

A filter such as Door\Down\step$\ may match step1, step2, and step3. Each node is still evaluated independently, pocketed independently, and recorded into Glue independently.

31. Pathing Order — Up Then Down, Retreat Back Through Both

Door traversal now has a clearer walk:

1. resolve Mantle pinnacle
2. walk Up host-side descendency
3. arrive at the target route locus
4. walk Down right-hand path branch
5. consume by final controller or sink
6. retreat through Down nodes
7. retreat through Up nodes
8. return to apex

Glue records both halves. The route can distinguish a host-derived node from a path-derived node even if the visible folder name is the same.

32. Bookshelf — URL Parameters as Route Shelf

The second vast area of active routing is the query string: everything after the question mark. These parameters are not necessarily pathing, but they are often essential to the meaning of a route. Rell has long used URL parameters as operational carriers, and Muq also receives route meaning through view, deck, mode, step, intent, portal, target, and similar values.

Door names this parameter layer Bookshelf.

?some=this&view=prn&session=abc

A parameter may be a single page, or it may point to an entire book. It may carry a direct scalar value, a hex-encoded payload, a reference to a file, a route intent, a stage instruction, or a global OS file that supports the route. Bookshelf is therefore not merely query parameters. It is the route shelf of named carried references.

33. Bookshelf Availability at Every Transit

Bookshelf is available to Muq during every node transit, both In and Out. It is also available to polling consumers because every node pocket and Glue copy can carry the relevant query parameter map.

Bookshelf:
  some = this
  view = prn
  deck = dtfhub
  stage = stable
  target = ...

This means a filter does not have to rediscover URL parameters. The parameter shelf travels with the route. A node-level filter may decide that a parameter applies locally, that it points to an outside artifact, that it should be copied into Glue, or that it should reshape the route.

34. Bookshelf as Page or Book

A Bookshelf entry may be tiny or vast. A parameter such as some=this may be a single page of information. A parameter such as manifest=..., body=..., or target=... may refer to an entire book of route meaning. Door allows both.

The important law is that Bookshelf entries are not treated as second-class route data. They are carried into Glue and node pockets so that filters, controllers, and pollers can judge the totality of the route, not merely its folder descent.

35. Parenting Filters — Same Grammar, Different Medium

Folder/file filters are not the only filter form. The same grammar exists in Parenting. At the window level, BasicData may carry filter structures that parallel the filesystem prototype bin.

BasicData.Filter.In.Ch$
BasicData.Filter.Out.ste#2

A BasicData filter can carry the same conceptual payload as filter.txt and filter.js in the folder world:

{
  "js": "jjjjjj",
  "txt": "ttttt"
}

36. Parental Filter Climb

Parenting filters obey the same inheritance instinct as BasicData itself. If the local window does not resolve a needed filter, the search climbs to the Parental context, then upward again, until a matching filter is found or the hierarchy is exhausted.

window.BasicData.Filter
  -> if not resolved
Parental.BasicData.Filter
  -> if not resolved
Parentop.BasicData.Filter

This means a child iframe or resident panel can inherit route behavior without duplicating every method locally. The apex may define broad route filters. A child may define local overrides. Exact matches still have final force at the level where they are found.

37. Filer-ing and Parent-ing Parity

The intent is identical across Filer-ing and Parent-ing. A filesystem filter and a BasicData filter both represent a method that may examine route context, execute or describe a behavior, and record its effect into Glue.

Filer-ing:
  Door\Up\Ch###e\In\filter.js
  Door\Down\step$\Out\filter.txt

Parent-ing:
  BasicData.Filter.In.Ch$
  BasicData.Filter.Out.ste#2

The difference is medium, not doctrine. The folder version is durable, inspectable, and poller-friendly. The Parenting version is resident, window-aware, and immediately available to a live frame hierarchy.

38. Combined Route Judgment

A filter judges the totality of the route. That totality now includes Up host-side descendency, Down path-side branch descendency, Bookshelf query parameters, Glue route memory, node pockets, BasicData, Parental and Parentop context, session ID, request ID, and window identity.

This is not a simple filename match. It is a route intelligence point. It can decide what a node means in the context of everything being carried through and around that node.

39. Updated Door Formula

Door =
  Up host descent
  + Down path branch
  + Bookshelf parameters
  + Glue route whiteboard
  + Filer-ing filters
  + Parent-ing filters
  + node pockets
  + retreat result

The traveler is still the note, but the note is now richer. It has a path, a shelf, a window identity, a session continuity, filter methods, and a Glue record of every push, reshape, withdrawal, redo, sink, or result.

40. Angle — The Third Kingdom of URL Navigation

Door now recognizes the fragment after # as the third active kingdom of URL navigation. Up handles dotted host descendency. Down handles slash pathing. Bookshelf handles the query string. Angle handles the Angular, panel, client, or resident route after the hash.

f-ire.pho.rip/step1/step2?command=stop&reason=fail#angle1/angle2
f-ire.pho.rip/step1/step2?command=stop&reason=fail#/abs1/abs2

A hash without a leading slash is relative. A hash with a leading slash is absolute. Door treats that distinction as intent.

41. Relative Angle and Absolute Angle

A relative Angle begins without a slash, such as #angle1/angle2. It means navigation from the current Glued angle. If Glue has no Angle value, the default base is /, so the first relative angle is effectively absolute by default. If Glue has collected an Angle prefix, the relative hash extends that prefix.

An absolute Angle begins with #/, such as #/abs1/abs2. It is routed after inbound Glue has been created, but it overrides the normal relative continuation and starts from the Mantle root.

42. Glue Angle

Glue now carries an Angle property. This is the accumulated client or Angular prefix gathered during ingress and optionally implanted by filters.

{
  "kind": "Glue",
  "Angle": "/glueang1/glueang2",
  "AngleMode": "relative",
  "AngleResolved": "/glueang1/glueang2/angle1/angle2"
}

Filters may append to the Glue Angle. Bookshelf parameters, BasicData, Parentop signals, or node-local prototype methods may also implant Angle segments. Angle therefore becomes recorded route state, not hidden client ornament.

43. Angle Resolution Examples

Suppose Up and Down pathing have resolved the final target as:

F:ire\child1\child2\step1\step2\

Then a relative Angle:

#angle1/angle2

resolves as:

F:ire\child1\child2\step1\step2\angle1\angle2\

If Glue has already collected /glueang1/glueang2, then the same relative Angle resolves as:

F:ire\child1\child2\step1\step2\glueang1\glueang2\angle1\angle2\

By contrast, an absolute Angle:

#/abs1/abs2

starts from the Mantle root:

F:ire\abs1\abs2\

44. Angle Nodes Are Real Media Nodes

The resolved Angular route is mirrored in Mantle storage. Every node of the final Angle route is instantiated with the same Door obligations as every Up or Down node. It receives the pocket, the Glue copy, and the audit/accounting/ action evidence.

_route\
  Ingress_*.json
  Error_*.eson
  Result_*.zson
  Glue_*.zson

Angular no longer has to infer everything from the live app alone. Its stage directives, local assets, current Glue, and node-specific instructions may already live in the real-media folder it has entered.

45. Angle Under the Same Geas

Angle is under the same geas as the rest of Door. A hash route is not free from evidence just because browsers often treat it as client-side. If Door resolves it, Door sheds into it.

Every Angle node may receive the original URL, resolved URL, Up chain, Down chain, Bookshelf map, Glue Angle before and after resolution, filter actions, and final result or sink condition.

46. Angular as Enhanced Resident Navigation

Angular is strengthened by this doctrine because it does not need to carry all stage directives and assets inside the client route. It can arrive at a resolved media node that already contains route evidence, stage directives, assets, and Glue.

Nothing important has to remain invisible outside the node. The route itself provisions the place, and the Angular surface can rely on Glued information.

47. Relative Angle from the Final Target Node

Up:
  child2.child1.f-ire.pho.rip
  → F:ire\child1\child2

Down:
  /step1/step2
  → F:ire\child1\child2\step1\step2

Relative Angle:
  #angle1/angle2
  → F:ire\child1\child2\step1\step2\angle1\angle2

Relative Angle behaves like a child branch of the already resolved route, not as detached client decoration.

48. Absolute Angle as Override

Absolute Angle begins with #/ and starts from the Mantle root after inbound Glue is established. Because it overrides the current target branch, it must be recorded clearly in Glue.

{
  "action": "AngleOverride",
  "from": "F:ire\\child1\\child2\\step1\\step2",
  "to": "F:ire\\abs1\\abs2",
  "reason": "absolute hash route"
}

49. Garbage Cleaning

Complete transit evidence creates many files. Door therefore expects garbage cleaning as a maintenance layer. Old Glue copies, expired ingress pockets, redundant snapshots, and superseded result files can be pruned or archived by policy after evidence has safely arrived.

Cleaning never interferes with rename instantiation and never exposes pollers to half-written files.

50. Updated Door Navigation Formula

Door =
  Up host descent
  + Down path branch
  + Bookshelf parameters
  + Angle hash route
  + Glue route whiteboard
  + Filer-ing filters
  + Parent-ing filters
  + node pockets
  + retreat result

This is the full Door walk: DNS-side ascent into Mantle, path-side descent into branch, parameter-side Bookshelf intent, and hash-side Angle residency. The traveler is still the note, but now even the Angular shadow of the route drops a pocket.

52. Body-Carried Styling for Brancher Absorption

Door now follows the same body-carried styling law used by Route and the stabilized PenPals/Brancher absorption path. A gathered Pen donates its body. Therefore, essential readability cannot depend on a style block that lives only in the document head.

The Door Pen carries its baseline ink, spacing, panel, card, table, and code styling inside the body itself. When Brancher extracts the Door body, the visual doctrine travels with the doctrinal text. Door remains readable as a standalone page and remains readable as a gathered Pen body.

Door\index.html
  head  = document identity
  body  = donated doctrine + donated style
  style = carried with the body for PenPals / Brancher survival

This does not change Door ownership or Cull scope. It only prevents the extracted Door body from becoming visually orphaned when absorbed by another Pen.

53. Closing Doctrine

Door is the doctrine of traversal made visible. It transforms a route from a hidden controller decision into a walk across media. Every node touched receives a pocket. Every pocket is written safely by rename. Every pocket knows the mantle, session, window, route, and result.

The system does not merely remember what happened. The system is composed of where it happened.

16. Glue — The Route Whiteboard

Door now adds Glue: the route-global zson that begins at the initial Mantle decision and carries forward through the entire traversal. When Muq resolves the pinnacle token, the drive or cwd locus, and the first media node, it also provisions Glue as a whiteboard for the route. Glue records the original URL, current URL, session, request, window identity, mantle, touched nodes, filter activity, route reshaping, restaging, sink decisions, artifacts, and final result.

incoming URL
  -> Mantle pinnacle decision
  -> drive / cwd locus resolved
  -> node path provisioned
  -> Glue.zson created
  -> traversal begins

Glue is not merely a log. A log observes after the fact. Glue participates during traversal. It is available to the final controller, to any filter that must judge the route, and to the retreat path as the final result is carried back through every touched node.

17. Glue as zson Result Carrier

Door already separates inflow, error, and result artifacts as json, eson, and zson. Glue belongs to the zson family because it records route consequence even while the route is still in motion.

{
  "kind": "Glue",
  "requestId": "...",
  "sessionId": "...",
  "windowId": "...",
  "mantleToken": "f-ire",
  "mantleName": "F:ire",
  "cwdRoot": "...",
  "originalUrl": "...",
  "currentUrl": "...",
  "nodes": [],
  "filters": [],
  "actions": [],
  "result": null
}

As traversal proceeds, Glue gains node touches, filter matches, URL reshaping events, redirection proposals, restaging notes, sink decisions, artifact references, timing, and final status.

18. Glue Propagates Down and Back

Glue moves in both directions. On descent, Muq carries Glue through the route as each node is provisioned and touched. On retreat, Glue carries the final result back through the same touched path.

descent:
  apex -> child1 -> child2 -> level1 -> level2

retreat:
  level2 -> level1 -> child2 -> child1 -> apex

Every node traversed downward or upward receives a copy of the current Glue. That way a node does not merely know that a request passed through. It can also know what the request became after later decisions.

19. Path Filters — Methods Attached to Route Names

Door now gains a method layer: Path Filters. A Path Filter is a named or wildcarded method surface that can attach behavior to any similar node in a route path. As Muq transits a node, it examines available filter prototypes and determines whether any filter applies to that node name and route condition.

Door\Change\
Door\Cha$\
Door\Ch###e\

In this grammar, $ stands for *, and # stands for ?. Thus Cha$ and Ch###e can both match Change, while Change remains the exact folder.

20. Filter Direction — In and Out

A route has direction. Filters therefore have direction. In filters execute during descent into a node; Out filters execute during retreat out of a node.

Door\Change\In\
Door\Change\Out\

An In filter may provision, gate, annotate, reshape, push, or restage the route before the final controller consumes it. An Out filter may interpret the final result and leave accounting, rollback, redo, sink, or completion residue behind.

21. Filter Ordering — Wildcards Before Exact

Filter order matters. Door uses a folder-based cascade. All wildcard filter folders that match the node are considered in alphabetical order. If an exact folder exists for the node name, the exact folder executes last.

For node: Change

1. Cha$
2. Ch###e
3. Change

The exact folder comes last because it can uniquify the final behavior for the concrete node. Broad prototype rules apply first; the named node gets the last word, similar to element-level style after broader CSS rules.

22. Filter Effects — Push, Reshape, Residue, Restage

A filter judges the totality of the route shed into the node. It may inspect the inflow pocket, Glue, BasicData, Parentop-derived Mantle table, window identity, session ID, request ID, and local node state.

Every effect must be written into Glue. Filters may change the route, but they must not hide the fact that the route changed.

23. Prototype Bin — Generic Methods for Named Nodes

The prototype bin is where generic route methods live before being attached to a particular media node. Door is the natural Pen to hold the doctrinal prototype examples because Door defines traversal, pocket-drop, Glue, and filter order.

Door\
  Change\
    In\
      filter.txt
      filter.js
    Out\
      filter.txt
      filter.js

  Cha$\
    In\
      filter.txt
      filter.js

  Ch###e\
    In\
      filter.txt
      filter.js

The text representation explains the filter. The JavaScript representation supplies the executable or inspectable route method.

24. Glue and Filter Relationship

Glue and filters are complementary. Glue is the route whiteboard. Filters are the local hands that may write on that whiteboard.

Glue:
  remembers the route

Filter:
  reads the route
  may change the route
  records that change into Glue

A filter without Glue would be dangerous because it could alter navigation invisibly. Glue without filters would be passive because it could record the walk but not reshape it. Together they create a route that is observable, accountable, and still capable of intelligent local transformation.

25. Poller Consequence — Local Knowledge Without Cross-Reference

Every node receives Glue for the same reason every node receives a pocket: asynchronous consumers must be able to react locally. A poller waking at a node should not have to search the apex to learn whether the route was redirected, sunk, restaged, or completed.

_route\
  Ingress_*.json
  Error_*.eson
  Result_*.zson
  Glue_*.zson

That gives the polling consumer enough information for audit, action, and accounting.

26. Door After Glue and Filters

Door is the threshold system where traversal becomes evidence, Glue becomes the carried route whiteboard, and Path Filters become local methods capable of reshaping, annotating, withdrawing, restaging, or completing the route while preserving the full history of what happened.

1. Purpose of This Ordination

The new Rell split is a candidate map. It is not yet a new application layout, not a controller generator, and not a commitment to final ownership. The useful thing at this stage is to name each case pool according to the system slice it most likely belongs to. That lets the next human pass choose candidates with the right mental model.

The old Tell controller was a toolbox that grew by necessity. It accepted command values, interpreted them, touched files, shaped redirects, staged messages, assembled uploads, handled commerce, pushed print intent, and consulted gates. Rell is the recovery of that toolbox into named utility surfaces.

2. Selection Rule

The selection rule is simple:

Assign by identity grammar, not by adjacency.

A case that writes to /Work/Mms may be print, messaging, or both, depending on whether the payload is Prt_ print intent or an SMS/MMS message. A case that mentions xact may look like commerce, but it may really belong to the old photography/event-commerce knot. A case that returns a page may not be UI at all; it may be a route translator.

3. Application Slice Vocabulary

4. Rell Case Pool Atlas

The following table is the working candidate-selection map. It is intentionally opinionated, but not final. “Application slice” means the best current home for reasoning and future segregation; it does not require that the code be moved there immediately.

5. High-Risk Knots

Photography / Xact / Commerce

The most dangerous knot remains the xact/tack/photog/hotel/session area. These cases look like commerce because they display products, save orders, compute totals, and prepare purchase routes. But they also carry the older photography event system. That means they should not be split only by nouns such as “product” or “order.” Until the new assembly proves otherwise, keep the photography-session gravity visible.

Messaging / Gating

Message text can become gate control. The allow, refuse, and team-setting patterns may arrive as SMS body content and then call gate behavior. This does not mean the MessagingController should own all gating. It means Messaging is one source of gating commands. The proper future shape is likely a Messaging intake that delegates to a Gating service.

Upload / Diagnostics Checker

checker appears diagnostic, but in practice it also polls for next server directive in an upload/intake style. For candidate selection, duplicate ownership is acceptable: let UploadSession keep the operational checker while Diagnostics keeps the concept of server-condition verification.

Static Types

Extension cases should be treated as retirement candidates. IIS should own plain static delivery unless the file response is guarded, transformed, logged, generated, or otherwise meaningful as application behavior.

6. Brancher Clue

Brancher matters here because it demonstrates how Wrench should behave: it should not flatten the system into a generic summary. It should preserve full bodies, named slices, and portable doctrine. The same principle applies to Rell case selection. The goal is not to make the split look neat. The goal is to preserve enough meaning that the next conversation or next operator can pick up the work without losing the original grain.

7. Candidate-Selection Workflow

1. Review one candidate pool.
2. Confirm or adjust its application slice.
3. Mark cross-slice dependencies.
4. Avoid moving code until the owning slice is stable.
5. Keep LocateController_Remnant as a temporary delegating shell.
6. Retire Misc only after every held case has a named reason and owner.

8. Wrench Doctrine After Rell Split

Rell confirms that Wrench is not just a place for helper functions. Wrench is the working bench where unclassified tools become named instruments. Some tools will graduate into their own Pens or application slices. Others will remain in Wrench because their purpose is to help every slice: filesystem truth, WorkZone resolution, ordination, diagnostics, template expansion, and compatibility routing.

The LocateController split is therefore not a cleanup story. It is a recognition story. The system already contained Route, Send, Merch, Print, Fence, Upload, Transfer, Media, Conduit, and Wrench. The split merely makes those identities visible enough to choose.

9. Immediate Next Human Pass

The best next review is not to edit code. It is to walk the table and mark each pool as one of:

• accepted owner
• split required
• duplicate candidate
• hold in remnant
• retire to static/IIS

That will make the eventual migration mechanical instead of interpretive.

10. Body-Carried Styling for PenPals Absorption

This ordination shifts Wrench into the same body-carried styling contract used by Route and the corrected Door delivery. The essential style for this Pen is no longer dependent on the document head. It travels inside the body with the donated content so PenPals Gather, Brancher extraction, or any later full-body union keeps Wrench readable without special casing.

The rule is practical: if a Pen expects to survive as a gathered body, its essential ink, spacing, cards, tables, tags, and code styling must be present inside that body. External or head-level styling may still exist in live pages, but gathered survival cannot depend on it.