Docs

Give your coding agent the same contract a careful engineer would use.

This isn't "copy this prompt." It's a project-aware prompt generator that only uses the official SDK surface, real Runtime prerequisites, real job-status semantics, and a definition of done your agent — or you — can actually verify.

Current verified source

Framework recipes

Every framework option produces framework-shaped code using the same verified SDK calls. Only the frameworks below have a real, maintained example repository today — the generator is honest about the rest.

• JavaScript Maintained example →
• React On the roadmap
• Vue On the roadmap
• Next.js On the roadmap
• Angular On the roadmap
• Electron On the roadmap

Runtime prerequisites

• · A Windows computer with the Portix.One Runtime installed and running.
• · A compatible printer, powered on and available to the operating system.
• · A completed application pairing, approved by a human in the Portix.One tray.

Job-status semantics

Real statuses, exactly as the Runtime returns them: pending, printing, completed, failed, cancelled. An agent — or your own code — must not conflate these:

• Accepted — The Runtime queued the job and returned a jobId — this is not proof of physical output.
• Delivered — The Runtime sent the job to the printer, but the transport could not confirm physical output.
• Confirmed — The job reached the documented "completed" terminal state — the only status that can be called "printed."

Security rules

• · The generated prompt never includes real API keys, pairing tokens, pairing codes, or a visitor's detected Runtime data.
• · It never asks the agent to install or run installers automatically, disable security prompts, approve pairing without a human, open public ports, or expose the Runtime to the internet.
• · Every value in the prompt is either a placeholder you provided or drawn from this page's verified manifest.

Definition of done

• · The project builds and its existing tests pass.
• · Mock mode produces the expected receipt preview.
• · Runtime-unavailable and job-failure states are visible and actionable.
• · No secrets or temporary pairing values are committed.
• · The application never labels an accepted job as physically printed.
• · Physical-printer completion stays a manual verification step unless the Runtime returns a documented terminal confirmation.

See also: SDK reference, Runtime API, Security model.