Route

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.