Templates catalogue
App Studio is coming soon: it is in development and testing and is not part of release 3.0. This page describes App Studio as it is being built, so names and steps may change before release.
Templates are real app sources embedded in the server (apps/backend/modules/appstudio/templates/catalog/<id>/): a template.json card, a manifest.json and the src/ files. Creating an app from a template writes those files into a fresh draft. Every template is compiled through the real bundle builder in the module's tests, so a template that would not publish is a bug.
Two ways to use them:
- New app → Start from on the Apps page copies the template's files into your draft.
- Try one of these… in the builder header seeds the chat with the template's prompt — the same app, built by the agent against your data instead of copied. Paste the prompt below into the chat if you prefer.
Topic paths in the prompts use mHv1.0/{org}/…; {org} resolves to your organization's slug.
Showcase
The three showcase apps are published into every organization on first open (needs app:publish), after which anyone with app:run can run them and app:clone holders can clone them. They are the answer to "why build an app instead of a dashboard?" — each one proves things only an App Studio app can do: live values and history in one client, the app's own configuration and the human layer kept in app storage, a governed write that renders disabled-with-reason for a viewer who lacks the scope, and a kiosk-ready layout. Line Pulse and Shift Book discover what your organization actually has and say so honestly when it has nothing yet; Line Runner needs nothing from the plant at all.
Line Pulse (line-pulse)
The plant on the wall. On first open the board finds up to six topics under mHv1.0/{org}/ that carry a numeric value and shows each as a big live tile (useTopic) with a sparkline and a target band; a Trend tab draws one aggregated chart per tile over a time range (/uns/data/aggregated); an availability card comes from the state-duration of a running-state topic (/uns/data/state-duration). Settings — tiles, targets, the running-state topic — live in a shared compare-and-set document, so the people who run the line shape the board and a colleague's concurrent save is shown, not overwritten. An organization with no live topics sees "Connect a line to see this" and the path to Connect.
Build a line board called Line Pulse: on first open discover up to six topics under mHv1.0/{org}/ that have a numeric value, show each as a big live tile with a sparkline and a target band, add a Trend tab with a time range and one aggregated chart per tile, an availability card from the state-duration of a running-state topic, and a Settings tab (kept in app storage) where the tiles, targets and the running-state topic can be changed.
Shift Book (shift-book)
The human layer next to the machine data. The plant already has shifts; the platform does not define them yet — so the app keeps the shift calendar as its own configuration (a shared document whose shape a platform shift entity can adopt later) and computes against it: which shift is on, one shared handover note per shift with a per-viewer "I read this" (user-scoped storage) and the last ten handovers, this shift's produced count and availability from a counter topic and a running-state topic over the shift window, and a downtime log (reason, minutes, note) kept in app storage. Each downtime entry has Publish to UNS — a data.publish on the confirm rung to mHv1.0/{org}/shift-book/downtime, which a viewer without uns:publish sees disabled with the platform's own reason. Settings are kept by the people who may write to the plant. Saving a handover posts a notice to the app's people over the person feed (notifications.notify) — the incoming shift hears it from the bell, not from luck.
Build a shift book: define shifts (name, start, end, weekdays) in app storage with defaults Morning 06–14, Afternoon 14–22, Night 22–06 and show which shift is on now; one shared handover note per shift with a per-viewer 'I read this' acknowledgement and the last ten handovers; this shift's produced count and availability from a counter topic and a running-state topic; and a downtime log (reason, minutes, note) kept in app storage with a 'Publish to UNS' button that asks for confirmation and is disabled with the reason for viewers who cannot publish.
Line Runner (line-runner)
The demo you hand someone at a booth. An endless runner drawn on a canvas: an AGV rides a factory conveyor, jumps pallets, crates, parts bins and carts, lowers its mast under robot arms and crane hooks, and collects gold nuts for bonus units; the line speeds up through Morning, Afternoon, Night and Overtime. Space / ↑ jumps and ↓ ducks; on a touch screen the upper half of the canvas jumps and holding the lower half ducks.
The game is the hook; the plant board is the point. The top 10 is one shared compare-and-set document (leaderboard): every finished run merges itself onto whatever is stored now, and when two players finish together the SDK's put re-reads the winner and re-runs the merge — both scores land. Rows are keyed by the player's user id and labelled with the signed-in name, so the board lists the people who actually played. Each player's best and run count are a user-scoped document (personal) nobody else can read. Clear board is shown to the app's editors and rendered disabled, with the reason, for everyone else. The board collection is writable by every viewer (every viewer posts scores), so it is a showcase, not an anti-cheat system: someone calling the storage API by hand could post a score they did not play.
Build a game called Line Runner: an endless runner on a canvas where an AGV on a factory conveyor jumps pallets, crates and carts and lowers its mast under robot arms and crane hooks, speeding up through Morning, Afternoon, Night and Overtime shifts, with gold nuts worth bonus units; keep a plant-wide top 10 as one shared compare-and-set document in app storage keyed by the player's user id, each player's best and run count in user-scoped storage, and a Clear board button only the app's editors can use.
Operations
MaestroHub Health Console (maestrohub-health-console)
The platform through its own SDK: pipeline count, recent executions by name and UNS topic count on one screen — a small read-only console to start from.
Build a MaestroHub health console: number of pipelines and how many failed recently, number of UNS topics, and the most recent executions, refreshing every 30 seconds.
Pipeline Activity Console (pipeline-activity-console)
The organization's execution history with per-status counts, plus a live watch: pick a pipeline and its manual runs land in the console as they happen (useExecutionStream) — no polling between refreshes.
Build a pipeline activity console: the latest executions with counts per status and a filter, plus a "watch live" panel where I pick a pipeline and see its runs land in real time.
Line Operator Console (line-operator-console)
Station status lights from UNS topics, a running-notes card the shift keeps, and one confirmed action bound to a connector function. The Andon pattern.
Build a line operator console for line 3: station status lights from the topics under mHv1.0/{org}/line3/stations/*, a notes card the shift can edit, and one 'Release interlock' button bound to the interlock connector function that asks for confirmation before it runs.
Approval Inbox (approval-inbox)
The pipeline approvals waiting for a human, decided from the floor: each card shows what is being asked and the held payload, with Approve and Reject on the confirm rung (approvals.decide) — disabled with the reason for viewers who cannot decide.
Build an approval inbox: list the pending pipeline approvals (approvals.list), show each one's title, pipeline, requester, deadline and held payload, and add Approve and Reject buttons with a note field that ask for confirmation and are disabled with the reason for viewers who cannot decide.
Pipeline Health Overview (pipeline-health-overview)
Every pipeline with its last execution outcome, refreshed every 30 seconds — the ops wall for the automation layer.
Build a pipeline health overview: list all pipelines with a badge for the outcome of their latest execution and how long ago it ran, refreshing every 30 seconds.
Shift Handover Notes (shift-handover-notes)
The outgoing shift writes, the incoming shift acknowledges: one shared handover document with a per-viewer "read" mark.
Build a shift handover app: one shared handover note the outgoing shift edits, a history of the last 10 handovers, and a per-user 'I read this' acknowledgement.
Connector Health Wall (connector-health-wall)
Every connector's up/down state and message rate from the platform's metrics, on one wall — refreshed every 20 seconds.
Build a connector health wall from the monitoring metrics: one row per connector with an up/down badge and its message rate, refreshed every 20 seconds.
Performance
Production Count + OEE Dashboard (production-oee-dashboard)
Live good/scrap counts and an OEE gauge per line from UNS topics, with the last hour's trend from the history API.
Build a production dashboard for line 3: live good count, scrap count and OEE from the topics under mHv1.0/{org}/line3/, an OEE gauge with an 85% target, and the last hour of OEE values as a list.
Production
Recipe Switch Console (recipe-switch-console)
Pick the next recipe from a catalogue curated by the app's editors (writers: "editors" — operators read, keepers write), submit the changeover through the approval gate (the rung-3 approval write) — and watch the released run land step by step over the live execution stream.
Build a recipe switch console for line 3: show the current recipe from mHv1.0/{org}/line3/recipe/current, let a supervisor choose the next recipe and submit the changeover to the 'recipe-changeover' pipeline's manual trigger, which requires approval.
Quality
Quality Check Console (quality-check-console)
Record a quality check against the live sample value and publish the verdict to a UNS topic — a confirmed write.
Build a quality check console: show the live sample value from mHv1.0/{org}/line3/quality/sample, let the inspector mark pass/fail with a comment, and publish the verdict to mHv1.0/{org}/line3/quality/verdict after confirmation.
Maintenance
Alarms & Maintenance Notes (alarms-maintenance-notes)
The organization's alarms from the platform's own alert feed — active first, live as they fire and clear (useAlerts) — each with a maintenance note the crew keeps next to it, and an Acknowledge button that runs through the confirm rung with the viewer's authority (alerts.ack; disabled with the reason for a viewer without alerts:ack).
Build an alarm board: list the alarms from the platform's alert feed (alerts.recent, active first), keep it live with useAlerts, let the crew keep a maintenance note per alarm in app storage, and add an Acknowledge button that asks for confirmation and is disabled with the reason for viewers who cannot acknowledge.
Equipment Maintenance Log (equipment-maintenance-log)
Pick a machine from the plant the knowledge module keeps, see what is declared on it, where it sits and the live values of its bound topics, and keep a dated maintenance log next to it — keyed to the thing's stable id (plant.whatCanIAsk / plant.walk / plant.describe), so it survives topic renames.
Build a maintenance log: let the technician pick a site (plant.whatCanIAsk) and a machine under it (plant.walk down the physical tree), show its name, what is declared on it, where it sits and the live values of its bound topics (plant.describe with values — series.ref is the topic), and keep dated log entries in app storage keyed by the thing's id, with a filter by technician.
Sustainability
Energy Consumption Monitor (energy-consumption-monitor)
Live power draw per area with a daily kWh total and a budget gauge, from UNS energy topics.
Build an energy monitor: live kW for the areas under mHv1.0/{org}/energy/*/power, today's kWh total from mHv1.0/{org}/energy/site/kwh_today, and a gauge against a 12,000 kWh daily budget.
Data
UNS Topic Explorer (mini) (uns-topic-explorer)
Browse the topics you can read, pick one, and watch its live value with the last few records — the smallest useful UNS viewer.
Build a mini UNS explorer: list the topics I can read (from the accessible-topics API), let me pick one, and show its live value plus the last 10 records.
Reporting
Custom Reports (parameterized) (custom-reports)
Pick a topic and a time range, pull the aggregated series, and show the numbers — the report the plant asks for every Monday, parameterized.
Build a parameterized report: a topic path input, a date range, and a button that loads the aggregated values for that range and shows min/avg/max plus the row count.
The scopes each template's manifest requests are shown on the New app dialog when you pick it. They are read from the template's manifest.json, not listed here, so the dialog is always the current answer.