Asset Work Network — runbook

Several specialised work applications speak one governed contract (work_v1) to a shared supply side, and a shutdown coordinator follows the work. The network shows the basics of the information flows; finer behaviour is a conversation with a client (see docs/implementation/asset_work_network_enhancements.md). Design: docs/implementation/asset_work_network.md. The generated map of who publishes, consumes and implements what is NETWORK_MAP.md.

Role	Application	Local port
work (mobile plant)	`work_management`	5087
work (fixed plant)	`mwem`	5082
work (haul roads)	`haul_road`	5124
shutdown campaigns	`scrm`	5085
inventory (`inventory_v1`)	`msam`	5083
purchasing (`purchasing_v1`)	`psam`	5084
finance (`finance_v1`)	`fins`	5081
orchestrator instance	`orchestrator_aw`	5125

The work applications are interchangeable to the supply side: events and commands carry a work_system, and the orchestrator routes the answers (dispatch: in the manifest) to the work application that asked.

Deployments (in `system.manifest.yaml`)

Deployment	Ports	Databases	Use
`local`	as above	the applications' own	the standalone demos — nothing flows between them
`demo`	+2000	`demo/db/` (persistent)	the control panel's network; scenario buttons; reset to the seeds
`acceptance`	+3000	`acceptance/db/` (rebuilt)	the opt-in test

python networks/run_network.py --network asset_work --deployment demo            # start (seeds any missing database)
python networks/run_network.py --network asset_work --deployment demo --status
python networks/run_network.py --network asset_work --deployment demo --stop
python networks/asset_work/network.py reset --deployment demo                    # back to the seeds

Scenarios

python networks/asset_work/trigger.py <code> --deployment demo (or the buttons in the control panel). Run them on freshly seeded databases and in this order — they share one set of databases, and a3 leaves a shortage behind that a later delivery covers.

Code	Flow	Story
`a1`	A1	A bearing is short for crusher work (mwem): purchasing orders it, it slips, arrives, is reserved, issued, and its cost posted.
`a2`	A2	Haul road material in stock: reserved, issued, posted; the work is completed and closed on a quantity check.
`a3`	A3	A late delivery, then the order is cancelled: the work application is told the date moved, then cleared.
`m1`	—	The same path for the mobile plant work application.
`s1`	S1	A shutdown follows its work: readiness moves as a part is short, then arrives; scope freeze; the permit gates the start; close-out.
`s2`	S2	A work order added after the freeze is a scope change that must be decided before it is assigned.
`h1`	H1	A serious road defect becomes a work order at once; the segment is closed for wet weather and reopened.

Tests

python -m pytest server/tests/test_supply_roles.py server/tests/test_integration_apps.py -q       # contracts, roles, every app's handlers
AW_NETWORK_ACCEPTANCE=1 python -m pytest server/tests/test_asset_work_network_acceptance.py -q    # starts the acceptance deployment (~1 min), stops it

Changing the network

Membership, flows, dispatch and deployments are written in network.spec.yaml (deployments name a shared profile from networks/_profiles.yaml); python -m codegen.cli network-manifest asset_work regenerates system.manifest.yaml (--check verifies it is current), then python -m codegen.cli network-docs asset_work for NETWORK_MAP.md. See docs/implementation/network_spec.md.
A member's published and consumed events come from its own <app>.integration.dsl; the manifest is built from them.
Per-network sample data should be a seed world (python -m codegen.cli seed <app> --file …), not a change to an application's own seed, unless every network that uses it can live with the change.

Not yet done

Deployment to the droplet (the five already-deployed apps hold live databases that need replacing; haul_road has no deploy block yet), mining-specific seed worlds, readiness/campaign fields on work_management, permits and labour in mwem readiness.