Pueblo

Pueblo is the workshop where PhoSend's visual production methods are made explicit. It does not own company routing, cloud substrate, message delivery, or the Marshal vessel doctrine. It owns the practical Adobe-facing craft: how intent becomes Photoshop work, how Desk compiles that work, how Xtools and JSX support the operation, and how repeatable production patterns are recorded for future builders.

The name is intentionally human. A pueblo is a place where craft accumulates. In PhoMaster terms, Pueblo is the craft district: the place where tools, patterns, and practical methods become something an apprentice can walk into and learn.

FireDance -> GML / intent -> Desk -> JSX -> Photoshop

• Photoshop is an actuator, not the system of record.
• Desk compiles intent into executable JSX transactions.
• JSX execution should remain disposable and repeatable.
• Persistence, recovery, queueing, and restartability live outside Photoshop.
• Pueblo documents craft patterns; it does not become the runtime itself.

Pueblo is the natural home for doctrine around Adobe craft. It is not a list of every script and every callable routine. It is the toolchest map: the apprentice can open the drawer that matches the kind of work being done, then descend later into the specific blades, clamps, gauges, or jigs inside that drawer. Pueblo therefore describes the practical groups of capability that make Photoshop automation repeatable.

• Photoshop automation patterns.
• Desk compiler rules and output expectations.
• Xtools callable and library classification.
• JSX transaction hygiene.
• Template, bitmap, mask, and raster production procedures.
• Lettering and font-bed interactions when they touch Photoshop craft.
• DTF, product rendering, and other Adobe-dependent production slices.

This does not prevent specialized Pens from existing. It simply means that when the question is "how does the Adobe craft work?" Pueblo is the district where the answer belongs.

Desk is best understood as the compiler bench between intent and Photoshop. FireDance can own time, state, files, queues, recovery, and orchestration; Desk should not try to become that larger organism. Desk receives a bounded visual intent, pattern, or GML-like instruction surface, and emits a Photoshop transaction that can be run once, observed, and discarded. This is why Desk belongs in Pueblo doctrine: it is not the vessel, not the company office, not the cloud, and not the message carrier. It is the craft translator that turns a known visual purpose into executable Adobe work.

A useful way to view Desk is as a set of compiler drawers rather than a single magic script. One drawer holds parsing and normalization: the source language, naming conventions, and resolved operands must be made boring before Photoshop is asked to move. Another drawer holds layout and measurement: rectangles, anchors, font beds, raster extents, baselines, mask boundaries, and product positions have to be computed outside the fragile moment of execution. A third drawer holds transaction assembly: once the work is known, Desk should package JSX so the Photoshop side does not have to remember previous context or infer missing state. A fourth drawer is verification and reporting: the emitted action should leave enough evidence for FireDance, Pueblo, or A:gent to understand what happened.

This is intentionally a general Desk description. The fuller Desk inventory will need its own supplied source material. Pueblo only needs enough here to establish the bench: Desk compiles; Photoshop actuates; FireDance remembers; Pueblo teaches the craft pattern.

Xtools is not one tool. It is an old but rich Photoshop automation toolchest. The current xtools tree shows several major drawers: apps, xapps, xlib, docs, etc, prefs, flex, and flex-crypto. The file list shows roughly three hundred files overall, with xlib as the large library drawer, apps and xapps as executable/demo/application drawers, and docs as the reference shelf.

The most Pueblo-relevant drawers are xlib, apps, and docs. The xlib drawer supplies reusable mechanisms; apps shows how those mechanisms become runnable tools; docs provides enough explanatory surface to keep the library from becoming folklore.

Stdlib is the clearest example of the Xtools drawer philosophy. The reference guide states that Stdlib is not really a class, but a namespace: instead of adding more than two hundred functions to the global namespace, related functions are collected under Stdlib. That keeps names such as getColorAt from colliding with functions written elsewhere, a small convenience in tiny scripts and a major survival rule in large scripts.

For Pueblo, Stdlib should be seen as the general-purpose utility chest under Photoshop automation. It extends built-in classes such as Date, Folder, and String, keeps a few global helpers for Action Manager IDs, and then groups the main functions by similarity. Those groups are the drawers an operator reaches for when building reliable JSX transactions.

Stdlib matters because it makes Photoshop scripting less lonely. It supplies the missing handles, adapters, and utility movements that a real production script reaches for over and over. Pueblo should therefore treat Stdlib as the first drawer to check before inventing a new helper.

The flex and flex-crypto folders look like a bridge from the ExtendScript/Xtools world into the ActionScript/Flex world. The presence of .actionScriptProperties, .flexLibProperties, project metadata, src trees, xkit, and crypto/RSA material suggests a client-library or UI experimentation layer rather than the core Photoshop execution library. In Pueblo terms, this drawer is not the main hammer for Photoshop, but it is evidence that xtools was already thinking beyond simple scripts: UI, external clients, library packaging, and cryptographic support were all within reach.

That guess should remain labeled as a guess until the Flex source itself is reviewed. Still, the directory shape is useful. It tells Pueblo to keep an eye on Xtools not only as JSX utilities, but as a broader tool-making culture: Photoshop scripts, reusable libraries, UI shells, action translators, and external-facing helper layers.

Marshal is now outside Pueblo. That is the correct boundary. Marshal is the vessel doctrine: PSD/XMP, RunTree-bearing payloads, packaging, custody, and transportable authority. Pueblo is the craft doctrine: what the Adobe tools do and how they should be driven.

So Pueblo may refer to Marshal when a vessel is consumed or projected, but it no longer contains Marshal as a subordinate page.

Pueblo carries its essential style inside the body because PenPals and Brancher gather Pen body sections. A standalone <head> is useful when the page is viewed alone, but it is not reliable when the Pen is absorbed as body content into the union surface. Therefore this delivery keeps the visual rules in a body-carried <style> implant scoped under .pueblo-pen-root.

The scoping matters. Pueblo styling should not leak outward and restyle PenPals or other Pens. It should make Pueblo readable when gathered, while remaining polite inside the larger PenUmbra surface.

This delivery advances as 777. It uses the corrected naming style: Deploy_Pueblo_777.ps1, Cull_Pueblo_778.ps1, and pocket777\Pueblo\index.html.777. It does not emit Pueblo_Marshal files and does not deploy a Pueblo\Marshal.html target.

The audit principle remains unchanged: spent ordinals are not repaired. The next delivery is based on the living culled source, and any boundary correction moves forward into the next issue.