Print

What Print provides

PhoRip Print is the first public/private service where the PhoSend system becomes concrete for a customer. It does not merely describe printing, and it is not only a storefront for printer supplies. It accepts a customer’s production intent, turns that intent into a printer-specific binary artifact, and surrounds the artifact with enough evidence to make the work repeatable, auditable, supportable, and recoverable.

The customer-facing product is the ability to keep producing. A shop may own a printer, sell garments, receive art, and understand its customers, yet still be stopped by the difficult parts of DTF and DTG operation: white ink behavior, channel assignment, density decisions, media limits, printer profile drift, real-estate packaging, and the gap between a pretty RGB image and a binary file that a converted printer can consume. PhoRip Print exists to absorb that complexity.

The immediate output is a .prn file matched to a real production condition: printer, ink set, dot strategy, media, and job constraints. The larger service is continuity. If the customer’s local printer is unavailable, the same job identity can route into fulfillment fallback so the customer’s promise to their own buyer does not collapse.

The service flow is conditional, not mechanical

PrintStart does not force every customer through a single rigid image-before-package path. The service begins by determining what the customer already has and what still needs to be created. A customer may select an existing private or global PRN, supply subject artwork for templating, upload a finished composite that only needs real-estate packaging, or upload a gang sheet that already expresses the layout. Each starting point changes what the system must do next.

Intake
  - customer identity and job name
New or Existing
  - use a private/global PRN or begin a new one
Compositing Method
  - subject + template, or uploaded composite
Job / Printer Selection
  - printer, DTF/DTG intent, product, media, ink set
Gang Sheet Source
  - uploaded/selected RGB print source where applicable
Printer Profile Confirmation
  - model, resolution, ink mapping, constraints, green summary
Production Plan
  - expected output, generated PRN, sidecar evidence
Delivery
  - customer PRN delivery or fulfillment fallback
Status / Audit / Support
  - queued, processing, ready, shipped, fulfilled, incident

This conditional flow matters because it prevents the system from destroying authored intent. A gang sheet is already a final RGB print source. A composite already contains templating decisions. A subject image still needs a template. A package is not the same thing as a picture; it is the distribution of one or more composites across fixed-width media so that length, yield, and cost are controlled.

Subject, Composite, Package, Gang Sheet, PRN

A Subject is the customer’s raw image or artwork. A Composite is a templated result, often guided by a specially constructed PSD template: a frame, a collage, a book page, or another production shape. A Package is the real-estate plan that arranges one or more composites for efficient production. A Gang Sheet is the RGB source image the RIP translates into dots. The PRN is the final binary printer-consumable artifact.

For fixed-width printers, width is the given wall and length is the economic consequence. Packaging therefore becomes a craft of arranging what must be printed so the least length of paper or film is consumed without changing the truth of the output. A ninety-degree rotation is not decorative; it may be the difference between waste and viable production.

The panels are workstations, not doctrine fragments

The operational deck may expose panels such as Printers, Inks, Paper, Image, Package, and PRN. Those panels are resident workstations. They keep the user oriented, preserve state, and eventually feed filesystem truth. Their order is a usable walk through the operational surface, not a claim that every job always begins the same way.

Printers -> Inks -> Paper -> Image -> Package -> PRN

Printers establishes the physical family and limits. Inks resolves channel assignments, white behavior, density assumptions, and circulation-sensitive facts. Paper or film establishes width, coating, margins, and adhesion constraints. Image determines whether the source is a subject, composite, gang sheet, or existing asset. Package resolves real estate when packaging is required. PRN seals the decision set into a deterministic artifact.

White ink makes the service necessary

White is the operational differentiator in DTF/DTG. It settles, clogs, drifts, requires circulation, and changes the meaning of density, underbase, and registration. A PRN that ignores white behavior can be generated and still be wrong. PhoRip must therefore carry white ink facts into the job contract, the transform contract, and the recipe/audit layer.

Conduit carries the service

Conduit is the transport and audit spine for the PhoRip service. Whether the customer runs a local PhoRip executable, uses the server-only path, or participates in a hybrid installation, Conduit carries identity, upload, configuration, status, artifact delivery, and fallback handoff. The customer sees a service; the system sees a chain of state-bearing commitments.

The customer is not only buying a file. The customer is buying the ability to keep promising output.

Every PRN needs surrounding evidence

The PRN is the final binary instruction set, but it should never be the only thing preserved. The job needs uploaded assets, generated or uploaded composites, gang sheets, printer profile snapshots, preview images, audit logs, fulfillment shipping artifacts, incident markers, and a recipe sidecar. That surrounding evidence is what lets a future conversation, operator, customer, or automated agent understand what happened without guessing.

jobid_utcms.json
  job id + correlation id
  printer profile id + resolved mapping
  explicit ink assignment map
  algorithm / version hash
  fulfillment fallback flags
  PRN / preview / audit references

Why this belongs in a Pen

Print is not merely another subject in Brancher. It is the customer-readable explanation of PhoRip’s first service. It should teach a startup conversation what the business offers, why the panels exist, which words matter, and how the operational route differs from the documentation surface. Brancher can later absorb this Pen and carry it forward, but Brancher should not be edited here. Print owns Print\index.html, and this ordination keeps that boundary clean.

The route is the live surface; the Pen is the teaching surface.

There are two implemented paths around Print/DTF operation. In Route/Muq, PrintView.cshtml currently instantiates a bare-bones operational skeleton. In the Pen system, Print\index.html culminates the knowledge. These must not be confused. The route is where the live operation is hosted. The Pen is where the meaning, vocabulary, service promise, and contract grammar are concentrated.

The iframe below is therefore a deployment socket. It may show the actual Muq PRN route when the host is live, but the documentation remains complete even if the route is unavailable.

The Pen may show the operation without becoming the operation.

The documentation Pen can carry an iframe socket to the operational route. That socket should point through Muq rather than pretending the documentation file is the application. It is a witness and gateway, not a replacement for the runtime.

If the host route is unavailable, this frame simply shows the current deployment condition. The Pen remains readable and complete without it.

Detailed objects belong here, but they stay collapsed.

Contracts and JSON examples are needed for implementation, audit, and future agent work, but they should not dominate the reader’s first pass. Detailed objects are therefore carried in collapsed blocks. A reader can expand them when needed; Brancher can carry them without losing readability.

Contract objects belong in the Print Pen, but JSON stays collapsed.

The wiring material below is included here because Print is the Pen that must teach PhoRip’s public/private print-service contracts. Each JSON object is collapsed so the reader can expand detail only when needed.

PhoSend Architecture Extract

The first application slice 'Dtf/Dtg', by focusing on dtf, it shows us how to treat application slices now with our WowDeck engine.

Pho.Rip

Pho.Rip represents the manufacturing gateway into the direct-to-film (DTF/DTG) production ecosystem. It is a dedicated entry domain for print production and product manufacturing workflows.

While Intake registers users into PhoSend, Pho.Rip becomes the operational harbor where automated creative manufacturing occurs. It demonstrates the full pipeline from image ingestion to product fulfillment.

DTF Production

Direct-to-Film production serves as the first pipeline for PhoSend's automated commerce architecture.

The typical pipeline includes: Image ingestion → template application → product rendering → storefront generation → messaging → fulfillment

This pipeline demonstrates the core PhoSend principle:

"One image enters the system. A business emerges from it."

DTF/PhoRip focus

Job Contract (input)

• what the customer supplies (artwork, sizing, garment/printer profile, ink set)
• how it’s represented (file payload + metadata JSON)

Transform Contract (processing)

• ink assignment rules, white underbase logic, halftoning/dither strategy,

color management assumptions

• .prn generation specifics per printer family (e.g., Epson 7890 class)
• plus secondary artifacts: preview PNG, audit log, “recipe” JSON for reproducibility

Delivery / Continuity Contract

• fulfillment fallback when customer printer is down

1) PhoRipJob (input contract)

This is the single source of truth for a print job. It can be submitted via Conduit endpoint, and it can also be serialized to a file as a “job packet” when needed.

{
  "schema": "phorip.job.v1",
  "jobId": "PRJ_20260201_173045_1234567890123_A1B2C3D4",
  "utcMs": "1730451234567",
  "customer": {
    "accountId": "acct_...",
    "contact": { "name": "…", "email": "…", "phone": "…" }
  },
  "request": {
    "mode": "dtf",
    "priority": "normal",
    "quantity": 1,
    "dueUtcMs": "1730550000000",
    "notes": "customer notes / operator notes"
  },
  "sourceArt": {
    "assetId": "asset_...",
    "filename": "design.psd",
    "kind": "psd",
    "bytesSha256": "…",
    "widthPx": 4500,
    "heightPx": 5400,
    "dpi": 300,
    "colorSpace": "RGB",
    "layersPolicy": "preserve",
    "upload": {
      "method": "npart",
      "url": "/Npart/…",
      "token": "…"
    }
  },
  "printTarget": {
    "printerFamily": "epson",
    "model": "7890",
    "connection": "customer_printer",
    "deviceProfileId": "prof_7890_wetcap_…",
    "media": {
      "type": "dtf_film",
      "widthMm": 600,
      "vendor": "…",
      "lot": "…"
    },
    "inkSet": {
      "layout": "CMYKWW",
      "channels": ["C","M","Y","K","W1","W2"],
      "whiteInk": { "enabled": true, "density": 1.0 }
    },
    "resolution": { "dpiX": 1440, "dpiY": 1440 }
  },
  "renderPolicy": {
    "sizing": {
      "scaleMode": "none",
      "fitBoxMm": { "w": 300, "h": 400 },
      "anchor": "center"
    },
    "whiteUnderbase": {
      "enabled": true,
      "strategy": "auto",
      "chokePx": 1,
      "spreadPx": 0,
      "minAlpha": 0.02
    },
    "halftone": {
      "method": "dither",
      "strength": 0.85,
      "seed": 12345
    },
    "colorManagement": {
      "intent": "perceptual",
      "inputProfile": "sRGB",
      "outputProfileId": "prof_7890_…"
    }
  },
  "fulfillment": {
    "fallbackAllowed": true,
    "fallbackMode": "phoprints_fulfill",
    "shipTo": { "name": "…", "address1": "…", "city": "…", "region": "…", "postal": "…", "country": "…" }
  },
  "security": {
    "requestSignature": "…",
    "submittedBy": "portal_user|api_key|operator",
    "ip": "x.x.x.x"
  }
}

Notes that match your ecosystem

• jobId is deliberately file-name friendly (prefix + utc + GUID fragment).
• utcMs is a fixed-length string.
• sourceArt.upload.method.

2) PhoRipJobAck (immediate response)

When Conduit receives a job, you want a stable “receipt” (works whether you return it via JSON, embed as <script>var utasker=…</script>, or file-based).

{
  "schema": "phorip.jobAck.v1",
  "jobId": "PRJ_…",
  "utcMs": "…",
  "accepted": true,
  "queue": {
    "name": "dtf_normal",
    "positionHint": 12
  },
  "links": {
    "status": "/Conduit/PhoRip/status?jobId=PRJ_…",
    "artifacts": "/Conduit/PhoRip/artifacts?jobId=PRJ_…"
  },
  "error": null
}

If validation fails:

{
  "schema": "phorip.jobAck.v1",
  "jobId": "PRJ_…",
  "utcMs": "…",
  "accepted": false,
  "error": {
    "code": "missing_required",
    "message": "printTarget.model is required",
    "field": "printTarget.model"
  }
}

3) PhoRipStatus (state machine)

audit trail can replay production

{
  "schema": "phorip.status.v1",
  "jobId": "PRJ_…",
  "utcMs": "…",
  "state": "rendering",
  "progress": { "pct": 62, "phase": "underbase" },
  "worker": {
    "kind": "local_worker|server_worker",
    "host": "SERVER01",
    "pid": 1234,
    "leaseUtcMs": "…"
  },
  "events": [
    { "utcMs": "…", "type": "queued", "msg": "Enqueued dtf_normal" },
    { "utcMs": "…", "type": "started", "msg": "Worker claimed job" },
    { "utcMs": "…", "type": "profile", "msg": "Output profile prof_7890_…" }
  ],
  "error": null
}

On failure:

{
  "schema": "phorip.status.v1",
  "jobId": "PRJ_…",
  "utcMs": "…",
  "state": "failed",
  "progress": { "pct": 0, "phase": "init" },
  "error": {
    "name": "RenderError",
    "message": "White channel overflow",
    "stack": "…",
    "origin": "worker",
    "evidence": {
      "logRef": "work/PRJ_…/logs/render.log",
      "artifactRef": "work/PRJ_…/debug/preview_fail.png"
    }
  }
}

4) PhoRipArtifacts (output contract)

This is what a client, operator, or fallback fulfillment needs.

{
  "schema": "phorip.artifacts.v1",
  "jobId": "PRJ_…",
  "utcMs": "…",
  "outputs": [
    {
      "kind": "printer_prn",
      "filename": "PhoRip_PRJ_…_epson7890_dtf.prn",
      "bytesSha256": "…",
      "sizeBytes": 12345678,
      "download": {
        "method": "fuq",
        "url": "/Fuq/get?f=…",
        "expiresUtcMs": "…"
      },
      "printerHints": {
        "model": "7890",
        "dpiX": 1440,
        "dpiY": 1440,
        "inkLayout": "CMYKWW"
      }
    },
    {
      "kind": "preview_png",
      "filename": "PhoRip_PRJ_…_preview.png",
      "download": { "method": "fuq", "url": "/Fuq/get?f=…", "expiresUtcMs": "…" }
    },
    {
      "kind": "recipe_json",
      "filename": "PhoRip_PRJ_…_recipe.json",
      "download": { "method": "fuq", "url": "/Fuq/get?f=…", "expiresUtcMs": "…" }
    },
    {
      "kind": "audit_log",
      "filename": "PhoRip_PRJ_…_audit.jsonl",
      "download": { "method": "fuq", "url": "/Fuq/get?f=…", "expiresUtcMs": "…" }
    }
  ]
}

Why “recipe_json” matters

That’s your time machine: it lets you reproduce a .prn from the same source art and policy even if the code evolves.

5) PhoRipRecipe (the reproducibility capsule)

This is the frozen “how we made it.”

{
  "schema": "phorip.recipe.v1",
  "jobId": "PRJ_…",
  "inputs": {
    "sourceArtSha256": "…",
    "printerProfileId": "prof_7890_…",
    "renderPolicy": { "...": "..." }
  },
  "engine": {
    "serverBuild": "Conduit_3.042",
    "workerBuild": "PhoRipWorker_…",
    "timestampUtcMs": "…"
  },
  "decisions": [
    { "k": "underbase.strategy", "v": "auto" },
    { "k": "underbase.chokePx", "v": 1 },
    { "k": "halftone.method", "v": "dither" }
  ],
  "outputs": {
    "prnSha256": "…",
    "previewSha256": "…"
  }
}

skinny.pull.v1 (write as .json)

{
  "schema": "skinny.pull.v1",
  "reqId": "PULL_PhoRip_FireWwwroot_Surface_v1",
  "utcMs": "___UTCMS___",

  "target": {
    "umbrella": "FireWwwroot",
    "root": "c:\\___Fire\\wwwroot"
  },

  "filters": {
    "includeGlobs": [
      "**/*.html","**/*.htm","**/*.js","**/*.ts","**/*.css",
      "**/*.json","**/*.md","**/*.txt","**/*.xml","**/*.config",
      "**/*.aspx","**/*.ascx","**/*.master","**/*.cs","**/*.vb"
    ],
    "excludeGlobs": [
      "**/node_modules/**","**/dist/**","**/build/**","**/.git/**"
    ],
    "maxBytesPerFile": 600000
  },

  "asks": [
    {
      "id": "token_hits_phorip",
      "kind": "tokenHits",
      "details": {
        "tokens": ["phorip","dtf","dtg",".prn","epson","7890","printer","ink","underbase","halftone","cutter","fitbody","___datavar___","___infovar___","conduit","phosend","phoagent"]
      }
    },
    {
      "id": "extract_matching_files",
      "kind": "extractFiles",
      "details": {
        "onlyFilesThatHitTokens": true,
        "maxFiles": 250,
        "bundle": "zip"
      }
    },
    {
      "id": "cutter_template_candidates",
      "kind": "extractByPathHints",
      "details": {
        "pathHints": ["**/*Cutter*","**/*FitBody*","**/*Template*","**/*PhoRip*","**/*DTF*","**/*DTG*"],
        "bundle": "zip",
        "maxFiles": 400
      }
    }
  ],

  "return": {
    "artifactDelivery": {
      "mode": "fileDrop",
      "folder": "c:\\inetpub\\wwwroot\\work\\skinny",
      "zipWhenLarge": true
    }
  }
}

Expected result: .zson with:

• a token-hit manifest (JSON)
• a zip of the matching source files
• a zip of template candidates

This is the fastest way to ground the PhoRip contract surfaces.

Request 3 — “Deployed surface” mirror pull (from inetpub\wwwroot, excluding runtime churn)

Goal: capture what’s actually deployed for the same PhoRip/token surfaces, without pulling work/results noise.

{
  "schema": "skinny.pull.v1",
  "reqId": "PULL_PhoRip_InetpubWwwroot_Surface_v1",
  "utcMs": "___UTCMS___",

  "target": {
    "umbrella": "InetpubWwwroot",
    "root": "c:\\inetpub\\wwwroot"
  },

  "filters": {
    "includeGlobs": [
      "**/*.html","**/*.htm","**/*.js","**/*.ts","**/*.css",
      "**/*.json","**/*.md","**/*.txt","**/*.xml","**/*.config",
      "**/*.aspx","**/*.ascx","**/*.master","**/*.cs","**/*.vb"
    ],
    "excludeGlobs": [
      "**/work/**","**/results/**","**/app_data/**","**/temp/**","**/tmp/**",
      "**/node_modules/**","**/dist/**","**/build/**","**/.git/**"
    ],
    "maxBytesPerFile": 600000
  },

  "asks": [
    {
      "id": "token_hits_phorip",
      "kind": "tokenHits",
      "details": {
        "tokens": ["phorip","dtf","dtg",".prn","epson","7890","printer","ink","underbase","halftone","cutter","fitbody","___datavar___","___infovar___","conduit","phosend","phoagent"]
      }
    },
    {
      "id": "extract_matching_files",
      "kind": "extractFiles",
      "details": {
        "onlyFilesThatHitTokens": true,
        "maxFiles": 250,
        "bundle": "zip"
      }
    }
  ],

  "return": {
    "artifactDelivery": {
      "mode": "fileDrop",
      "folder": "c:\\inetpub\\wwwroot\\work\\skinny",
      "zipWhenLarge": true
    }
  }
}

This gives us the deploy-side mirror, which plus your manifest diff = full verification.

How you can “aggregate” these

You said you’ll aggregate individual requests. Great: your aggregate can just embed these as an array under a parent envelope like:

{
  "schema": "skinny.batch.v1",
  "utcMs": "___UTCMS___",
  "requests": [ /* the three objects above */ ]
}

Your pipeline can then produce one .zson per request, or one combined batch .zson with per-request nodes — either is fine.

Part 2 — The JSON trace contract (the backbone)

You already nailed the meta-rule: JSON is the treaty language. So the interpreter should emit:

phorip.trace.v1

{
  "schema": "phorip.trace.v1",
  "runId": "RIP_1730451234567_AB12CD34",
  "utcMsStart": "1730451234567",
  "source": {
    "textSha256": "…",
    "length": 1240
  },
  "machine": {
    "version": "PhoRipInterpreter_…",
    "mode": "dtf",
    "target": { "printer": "epson7890", "dpi": "1440x1440" }
  },
  "steps": [
    {
      "i": 0,
      "phase": "lex",
      "span": { "a": 0, "b": 5, "line": 1, "col": 1 },
      "token": { "kind": "WORD", "lexeme": "PRINT" },
      "action": { "kind": "emit_token" },
      "envDiff": []
    },
    {
      "i": 42,
      "phase": "eval",
      "span": { "a": 212, "b": 219, "line": 8, "col": 3 },
      "node": { "kind": "OpAssignInk", "args": ["W1","density",1.0] },
      "action": { "kind": "set_env", "path": "ink.W1.density", "value": 1.0 },
      "envDiff": [
        { "op": "set", "path": "ink.W1.density", "from": 0.9, "to": 1.0 }
      ],
      "effects": [
        { "kind": "file_write_virtual", "path": "work/.../recipe.json", "bytes": 1822 }
      ]
    }
  ],
  "error": null
}

Why this matters

• Your UI can be a pure renderer of this JSON.
• You can record/compare traces across builds.
• You can “fast-forward” by skipping non-interesting phases.
• You can build color rules off token.kind, node.kind, action.kind, envDiff.op, effects.kind.

This is the foundation for the “visual syntax debugger” you want.