What it touches
Order items, note, customer contact, fulfillment type, and order status.
Owner / operator side / Operator-side prototype
Kitchen order queue
Staff can see incoming orders and move them through kitchen states.
For a pizzeria
Lets the restaurant turn direct orders into an actual working queue behind the counter.
Where it fits
What the shop uses behind the counter
These are the restaurant-side tools for menu control, kitchen flow, stock, printing, and fallback alerts.
This page is the readable P4P explanation for one module. It is meant to be understandable before you open the raw manifest.
What it does not own
It is not public discovery and it does not own payment.
Current state
Operator-side prototype
available in the pilot-node operator dashboard when enabled
Current declared data-access summary: Order items, note, customer contact, fulfillment type, and local order status. Operator-only; not exposed in public discovery.
Read next
Do not stop at one module page.
See what the customer opens first
The kitchen queue is easier to read once you start from the direct customer menu surface.
Then see the customer follow-up
The customer-side mirror of kitchen state changes is the order-status page.
Keep the payment edge small
Even when the kitchen flow exists, the first live payment shape is still pay at pickup.
Technical identity
p4p.kitchen.screen
If you need the developer-facing version, open the GitHub module reference or the raw manifest. The public P4P page stays focused on what the module means operationally.
Open provider page / Open GitHub module reference / Open GitHub provider reference / Open raw manifest
Contact
This module page is still part of the same narrow proof story.
Questions about this module, the provider layer, or the live-pilot boundary: hedegreen.research@gmail.com.
Public proof front door: https://pizza4people.com/.
Broader protocol-family direction: https://protocols4people.com/.