PhoMaster / PenUmbra / Marshal Pen / Ordination 774

Marshal

Marshal is restored as both subject and discipline. The first panel carries the older Pueblo-resident subject matter reworked as How Marshal Works. The second panel preserves the newer delivery/custody treatise as Delivery Treatise. Both are collapsed so PenPals and Brancher can carry the fat doctrine without forcing the whole mountain open at first glance.

This ordination repairs the accidental overwrite by joining the recovered subject source with the 771 delivery doctrine. Marshal remains a front-line Pen at Marshal\index.html, not a mechanical sub-Pen hidden under Pueblo.

How Marshal Works

Pueblo / Marshal / Ordination 773

The Marshal Plan

Marshal is the Pueblo sub-Pen for the portable PSD/XMP vessel strategy: how Photoshop craft becomes a carried RunTree package, how Adobe operations remain rooted in Pueblo, and how FireDance, Desk, Xtools, A:gent, and S:end can treat a PSD not as an image only, but as a living operational container.

Pueblo sub-Pen Marshal PSD vessel XMP-contained RunTree Photoshop as actuator Ordinated delivery

Purpose

Marshal belongs under Pueblo because Pueblo is the Adobe craft district: the place where Photoshop, Desk, Xtools, JSX, Acrobat-facing projection, and image/container craft are explained as a coherent production world. Marshal is not a side document beside Pueblo. It is a sub-Pen inside Pueblo because Marshal is the portable vessel form that lets Pueblo craft travel.

Core framing: Pueblo is the workshop; Marshal is the packed vessel that leaves the workshop carrying intent, assets, state, and executable possibility.

The Marshal Plan establishes how a PSD can become a portable operational object. It may carry a RunTree in XMP, attach or reference supporting material, preserve enough context for restartability, and provide Desk/JSX/Photoshop with a current resident target. The image is not just art. It is also a vessel.

Ordination Position

This document is delivered as Marshal.html.773. The prior 771 attempt is not repaired. It is superseded. Ordination doctrine requires forward motion: when an issued ordinal is wrong, the answer is the next ordination, not a corrected pocket under the same witness.

Law: corrections move forward by next ordination. A repaired pocket using the same ordinal breaks audit truth because it creates a second untracked meaning for the same witness.

The live file remains Marshal.html. The audit file remains Marshal.html.773. The source delivery pocket remains pocket773/Pueblo/Marshal.html.773.

Relationship to Pueblo

Pueblo already states the essential craft laws: Photoshop is an actuator, Desk is the compiler, Pueblo is the craft, and persistence lives outside JSX. Marshal does not overturn those laws. It gives them a portable vessel.

Actor	Marshal relationship
FireDance / F:ire	Orchestrates, watches, provisions, and resumes movement. It remains the interpreter/execution world.
Desk	Compiles intent into one-shot Photoshop actions and can read/write Marshal state through defined interfaces.
Photoshop	Acts on the resident PSD. It is not the system of record, but the current Marshal may be the vessel being acted upon.
Xtools / P:xto	Provides field tools and callable Photoshop-side routines that can be wrapped by Desk or invoked through Pueblo craft law.
A:gent	Observes, explains, repairs, and guides Marshal-bearing workflows when a branch needs rescue or interpretation.

Marshal as Vessel

A Marshal PSD is the portable deployment vessel for a branch of work. It can contain the visible image, the layer structure, XMP metadata, embedded or attached references, and the RunTree fragment that tells the system where the object stands and what it can do next.

Marshal PSD
  visible composition
  Photoshop layers
  XMP-contained tree field
  Yml-safe encoded XML / RunTree fragment
  references to packages, Office/PDF/SQLite payloads
  current route and recovery state

The vessel idea matters because it converts a Photoshop document from a passive output into an operational carrier. A client can receive a Marshal and begin from a living plan rather than from a static art file.

Result: Marshal makes Photoshop collaboration, provisioning, restartability, and artifact delivery travel together.

XMP and RunTree

The XMP field is treated like a drive embodiment. It is not a casual comment dump. It is a contained tree surface. Because Yml mapping can preserve XML-valid names and attributes, the RunTree can carry meaningful mantle names, route hints, proc/status state, and queue or recovery markers without forcing the PSD itself to understand every external system.

This is why Marshal belongs in the same strategic family as WebDAV, B:ase, Zipool, and S:end. Each is a way for the Tree to appear in a different embodiment. Marshal is the PSD/XMP embodiment.

Rule: the current resident Marshal is the implicit source/destination vessel for Desk and JSX operations until the workflow explicitly moves to another Marshal.

Resident Marshal

Only one Marshal from a particular tree directory should be treated as resident at a time. The resident Marshal gives Photoshop-side operations a stable target. JSX does not have to discover the universe every time; it can operate through a known current vessel.

tree directory
  current resident Marshal.psd
    Desk compiles
    JSX acts
    Photoshop changes layers
    FireDance observes results
    Marshal XMP carries state forward

This is what prevents the old “robot script has to do it all right now” problem. Work can be deposited, polled, resumed, copied, or redirected because the vessel has state and address.

Restartability and Remediation

Marshal is a restartability device. The PSD can be moved, copied, handed off, sent to a client, returned, or routed through a different machine while retaining enough structured state to know what it is and what should happen next.

Failed action can leave status rather than losing meaning.
Recovery can occur from the vessel rather than from memory of a conversation.
A:gent can inspect the branch, report what is wrong, and recommend the next safe action.
FireDance can resume from visible file/state surfaces instead of hidden process state.

Law: Marshal must never depend on Photoshop session memory alone. If a workflow matters, enough truth must be written into the vessel, sidecar, or associated tree to make recovery possible.

Payload Universe

The Marshal Plan allows the PSD to carry or coordinate more than pixels. It can organize the practical payload universe surrounding a job.

Payload type	Marshal role
JSX / Desk instructions	Stored or referenced as the next executable plan.
Office / Excel	Attached or referenced for tabular, pricing, order, or production data.
SQLite	Self-contained data packet for portable job state or local application structure.
PDF	Projected outward through X:pdf as a delivery/container artifact.
Images and rasters	Native Photoshop layer assets or external support files.

The direction is important: the PSD/Marshal world remains the authority, while PDF and other external documents are often projections from that authority rather than the source of it.

Transport and Broadcast

A Marshal can travel. That is the point of the plan. A Marshal can be transferred to another node, copied into another hierarchy, delivered to a client, or used as a broadcast vessel for a set of related operations.

The location of the Marshal gives operations both source and destination. Different Marshals at different hierarchy nodes can be copied between, compared, or used to route instructions and results.

Pueblo craft
  → Marshal vessel
  → client Photoshop / local FireDance / cloud-facing branch
  → returned or synchronized state
  → A:gent inspection and next instruction

Strategic result: Marshal turns a PSD into a movable branch of the company RunTree.

Security and Capability

The Marshal Plan can support capability-style security without pretending that secrecy must hide everything. Much of a payload can be visible while the next valid capability, key, route, or token remains protected and rotating.

At the doctrine level, the key point is not to describe covert mechanics. The key point is that authorization should be treated as current capability, not as a permanent static secret.

Principle: visible structure may be harmless; current capability controls whether the next action is permitted.

Mantle Routing

Marshal is deeply tied to the mantle grammar now used across PhoMaster. The relevant neighbors are:

P:ho for vessel/package identity.
P:kgs for package surfaces and carried payload groups.
P:xto for xtools and Photoshop field tools.
X:tre for tree projection and tree impact.
X:pdf for PDF projection from the Marshal authority.
F:run for runtime execution in FireDance/Robot/Bin territory.
A:way / A:see / A:do for agent steering, observation, and action.

The route may be native, proxy, or venting. If a mantle can wisely pass a request toward a better final destination, it may do so. If observation says no, it should return eson rather than pretending to continue.

Why Pueblo Owns This

Marshal is not merely P:ho doctrine because the working body is Adobe-centered. It is a Photoshop PSD plan. It involves layer organization, XMP, JSX, Desk, Xtools, Acrobat/PDF projection, and Adobe operation. Pueblo is therefore the right Pen home.

That does not mean Pueblo owns every future Marshal. It means Pueblo owns the craft doctrine for how the Adobe-world Marshal is built, edited, acted upon, and projected.

Sub-Pen rule: Pueblo\Marshal.html is the doctrinal place for Marshal strategy while Pueblo\index.html remains the broader Adobe craft district.

Implementation Horizon

The Marshal Plan should now grow toward implementation in stages:

Define the XMP/Yml field layout used to carry the RunTree fragment.
Define the current-resident Marshal rule for Photoshop sessions.
Define Desk interfaces for reading and writing Marshal state.
Define Xtools wrappers that are safe in Photoshop 27.2+ and Pueblo-class execution.
Define X:pdf projection from Marshal PSD into outward PDF artifacts.
Define A:gent inspection and remediation prompts for Marshal-bearing jobs.
Define S:end and Zipool carriage where Marshal-related payloads need delivery or publication.

Horizon statement: Marshal is the portable Adobe vessel that lets Pueblo craft become deployable, inspectable, recoverable, and returnable.

Delivery Treatise

PhoMaster / PenUmbra / Marshal Pen / Ordination 771

Marshal

Marshal is the Pen for ordered carrying: the doctrine of collecting, escorting, stabilizing, and delivering living materials without confusing custody with ownership. It is where payload, pocket, escort, and destination become one disciplined delivery grammar.

Marshal begins as a front-line Pen. It may remember Pueblo lineage and may carry Pueblo-adjacent craft, but it is not mechanically subordinated to Pueblo. Its address is Marshal\index.html, and its ordination range begins here.

1. Purpose of the Marshal Pen

Marshal exists to clarify the difference between possession, custody, authority, and delivery. A system that moves files, Pens, pockets, results, staged content, source mirrors, and conversation seed material needs more than copying. It needs lawful carrying. Marshal names that law.

A marshal does not become the owner of every artifact it escorts. It preserves the artifact's identity, keeps the route intelligible, prevents contamination, and arrives with enough structure that the receiving system knows what has been carried, what is live, what is audit, and what remains outside the marshal's authority.

2. Marshal as Escort, Not Author

Marshal is especially important because many PhoMaster artifacts travel inside other carriers. PenPals may absorb Pen bodies. Brancher may union whole bodies for conversation hatching. Deploy scripts may mirror a Pen into C, E, and G. Cull scripts may return living truth from the mutable production side.

In all of those cases, a carrier can easily be mistaken for an owner. Marshal rejects that confusion. The escorting vessel may carry content, but ownership still belongs to the subject Pen. Presence is not authority. Reach is not authorship. Provisioning is not possession.

3. Custody Grammar

Payload

The thing being carried: a file, body section, support asset, state packet, route artifact, or pocket.

Escort

The controlled movement of the payload through a known route without mutating its identity.

Custody

The temporary responsibility to preserve integrity while the payload is in transit.

Authority

The right to edit, ordain, cull, or retire the payload. Authority stays with the owning Pen or system.

4. Relationship to Ordination

Ordination says that only clean emitted artifacts are real and that correction moves forward by new ordinal. Marshal obeys this by carrying ordinated material without reinterpreting the ordinal. It must never reissue another Pen's ordinal, silently rename responsibility, or pretend that transit created a new truth.

Marshal therefore reinforces the rule already learned across the Pen system: the artifact that is delivered is the artifact that exists. Conversation, intention, or staging alone does not ordain. Marshal can escort a future artifact, but it cannot make that artifact real until delivery occurs.

5. Relationship to Cull

Cull is return. Marshal helps explain why Cull must be narrow. A cull does not gather everything visible in a folder. It returns the living truth owned by the subject being culled. Support files may be present. Other Pens may be provisioned. Brancher or PenPals may carry union content. None of that changes Cull scope.

Ownership defines Cull scope.
Presence does not define Cull scope.
Provisioning does not define Cull scope.

Marshal treats that boundary as a custody law. The return path must not drag unrelated passengers into a subject's truth file. If there is a real structural movement to make, it belongs in an explicit Moving instruction or in the owning Pen's own ordination cycle.

6. Relationship to PenPals Gather

PenPals absorbs Pen bodies for reading, inspection, and Brancher hatching. That means Marshal's body must carry enough styling to survive extraction without relying on its head. The body-carried style implant at the top of this body is therefore intentional, not decorative.

Marshal must be readable when gathered into PenPals, when unioned into Brancher, and when opened directly as Marshal\index.html. The body itself carries the foundational variables, ink, background, panels, code formatting, and layout floor needed to avoid inherited style failure.

7. Body-Carried Styling Law for Marshal

Any Pen that expects to be gathered by body extraction must place essential readability styling inside the body. Head styles may exist for direct page operation, but the gathered body cannot depend on them. Marshal therefore carries its own root class, palette, font choices, code-block styling, card surfaces, and responsive padding inside the body.

The root class is .marshal-pen-root. Gathered hosts should not be required to know Marshal's internal rules. They only need to insert the body. Marshal then arrives with its own visual floor and does not vanish into another Pen's inherited ink, background, or button rules.

8. Marshal and Pocket Discipline

A pocket is not a place to keep editing forever. It is a delivered carrier. After deploy, the living source is the un-ordinated file at the active target, usually the C-side production root for the Pen. The pocket becomes evidence of what was delivered, not the next editing location.

Marshal makes this visible because pocket work is a custody problem. The pocket escorts the ordinated artifact into deployment. After that, the next Cull returns from the active production location, not from the retired pocket and not from a mirror that happens to contain a copy.

9. C, E, and G Deployment Meaning

Marshal follows the current Pen deployment model. The C location is the active production truth that may be edited and later culled. The E location is a supporting or formative mirror. The G location under PhoMaster is the public and source-facing mirror. Deploy writes to all three, but Cull returns only from the active authority.

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

This distribution is not three competing truths. It is one active mutable source with mirrors. Marshal's job is to keep that distinction clear during movement.

10. Route, Door, and Marshal

Door doctrine says the traveler is the note. Route doctrine says traversal is media-realized visitation. Marshal adds the escorting view: as a request or artifact passes through nodes, it may drop pockets, logs, results, or state evidence. The system must be able to follow the escorted meaning without confusing the trail with the owner.

A door can receive the knock. Route can materialize the path. Marshal describes how the payload is lawfully carried along that path and how consumers can trust that carried state without over-consuming it.

11. Failure Mode: Custody Becomes Ownership

The most dangerous Marshal failure is subtle: a carrier begins to edit, shrink, summarize, or re-own what it was only supposed to carry. This is the same family of failure that can make Brancher less useful by thinning fat doctrine, or make PenPals wrong by culling provisioned Pens that it merely displayed.

Marshal is the antidote. It states that a good carrier preserves the fullness needed by the destination. It does not replace the source. It does not reduce meaning for its own convenience. It does not alter another Pen's ordination.

12. First Ordination Standing

This first Marshal ordination establishes the Pen, the path, and the standard delivery/cull scenario. Future Marshal work can now proceed from the active Marshal\index.html returned by Cull, not from this pocket. If later content moves in from Pueblo, Door, Route, Wrench, or PenPals, that movement should be explicit and subject to ownership discipline.