David """
That is 'Worker' & Fullfulment App to some degree done. Later I will probably move the stub of this to the hosted server so that it can be used as a permenant demo. Like '###/dfd-fulfilment' However, the next app I need is '###/buydfd'. This is the Customer facing app to buy the 20L of fuel, have it delivered to their car. I'm thinking that we need an 'Order/Buy' page. I don't want to redesign the app. Maybe we could somehow in the configuration have this as a 'loadable' page. The buttons down the bottom could use the same mechanism as 'messages' in that they are preloadable. Maybe this is a variation of messages that has some basic html. An image, some choices, like 'How many litres?', 'Location of vehicle?' (GPS), delivery-timeslot?
"""

Elior-Ai """
Yes. I think buydfd should be another skin/configuration of CharacterIF, not another application architecture.

What you are describing is very close to the responder page we just built, except instead of displaying an incoming request and asking the human to choose Accept/Decline, it displays a small structured order form and produces an order transaction.

I would generalise the existing idea only one notch:

[pages]
order = order.json
messages = messages
settings = settings

Then perhaps:

dfd-5/
buy/
pages/
order.json

order.json could initially be deliberately unsophisticated:

{
"title": "Buy DFD Fuel",
"image": "/static/dfd-fuel-20l.jpg",
"text": "Fuel delivered directly to your vehicle.",
"fields": [
{
"id": "quantity",
"type": "choice",
"label": "How many litres?",
"choices": ["20", "40", "60"]
},
{
"id": "vehicle_location",
"type": "location",
"label": "Location of vehicle"
},
{
"id": "delivery_time",
"type": "choice",
"label": "Delivery time",
"choices": ["Morning", "Afternoon", "Evening"]
}
],
"buttons": [
{
"id": "order",
"caption": "Order Fuel"
}
]
}

The important bit is that I wouldn't make this arbitrary loadable HTML. That starts turning CharacterIF into a browser/application framework.

Instead, make the page definition declarative, just as Messages already accepts declarative response buttons.

So buydfd might normally look like:

┌─────────────────────────────┐
│ Buy DFD │
│ │
│ [ fuel image ] │
│ │
│ How many litres? │
│ [ 20 L ▼ ] │
│ │
│ Vehicle location │
│ [ Use current location ] │
│ │
│ Delivery time │
│ [ Afternoon ▼ ] │
│ │
├─────────────────────────────┤
│ Home Order Account │
└─────────────────────────────┘

And after filling it in, Order produces something wonderfully familiar to what we just finished:

{
"type": "order",
"request_id": "req-0005",
"product": "dfd-fuel",
"quantity": 20,
"unit": "litres",
"vehicle_location": {
"latitude": "...",
"longitude": "..."
},
"delivery_time": "afternoon"
}

That can enter the same mini transaction system.

So the two applications begin fitting together naturally:

BUYDFD CUSTOMER
│
│ Order 20 L
▼
0005-transaction.json
│
▼
DFD fulfilment
│
│ job/request
▼
WORKER CharacterIF
│
├── Accept
└── Decline
"""