stzDeployment

(no comment in the source: the name reads as a sentence) initno extension

the structured log of the deployment run -- queryable and renderable (oDep.Log().EntriesOfLevel(:error), oDep.Log().AsJson()). Populated by Run().no extension

bind a part to its target site. For many at once, use SetTargets.no extension

(no comment in the source: the name reads as a sentence) set targetsno extension

order the plan: pcPart runs AFTER pcDependsOn is verified (a plan-DAG edge). Simple deployments declare none; complex ones (a frontend after its backend) do.no extension

attach a REAL build output to ship for a part (the per-part stz_<part>.wasm, the app bundle, the native binary...). pcRelName is its name at the destination; pcPath is the built file on disk. Shipped byte-for-byte alongside the manifest.no extension

(no comment in the source: the name reads as a sentence) artifacts attachedno extension

wire an emulator's built bundle DIRECTORY straight in as a part's production artifact -- the SAME tree you emulated becomes what ships. Accepts a stzEmulator (built on demand) or a bundle directory path; the bundle lands under the solution name.no extension

ship a part's OWN slice from an emulator bundle -- its app (as index.html), its engine subset (stz_<part>.wasm), and the bridge (stz.js) -- NOT the whole mission-control. A frontend part deploys only what it needs to run.no extension

(no comment in the source: the name reads as a sentence) set actorno extension

(no comment in the source: the name reads as a sentence) bindingsno extension

(no comment in the source: the name reads as a sentence) number of bindingsno extension

(no comment in the source: the name reads as a sentence) site forno extension

the governance gate: may this deployment cross to reality?no extension

the deployment plan (rehearsal) -------------------- each part -> [ part, kind, target, siteName, siteKind, protocol ]no extension

(no comment in the source: the name reads as a sentence) explainno extension

(no comment in the source: the name reads as a sentence) showno extension

perform (governed) --------------------------------- store each part's deploy artifact on its bound site. returns [ committed(0/1), [ [part, site, outcome], ... ] ]no extension

(no comment in the source: the name reads as a sentence) launchno extension

(no comment in the source: the name reads as a sentence) statusno extension

the plan of steps (order, gates, rollback) --------- the deployment PLAN as ordered steps. A simple deployment is the default chain per part -- provision? -> store -> launch -> verify; After() edges add cross-part ordering (a frontend after its backend). Returns [ [name, op, part, siteName, [needs]], ... ], topologically ordered so every dependency precedes its dependants.no extension

EXECUTE the ordered plan (governed). Each step runs its op; the verify step is a GATE (the site must be launched). On any failure, the completed store/launch steps are ROLLED BACK in reverse -- the deployment is transactional. Returns [ committed(0/1), [ [stepName, outcome], ... ] ]. No effectful actor -> rehearse. Did Run() execute at all? A deployment REFUSED upstream -- by the service gate in stzDelivery, say -- comes back untouched, and "nothing happened" is then assertable without reading the log.no extension

Did it commit, or only rehearse? Rehearsed steps touch nothing.no extension

(no comment in the source: the name reads as a sentence) runno extension

feasibility (host resources) ----------------------- Per-site admission check: sum the requirements of the parts bound to each site and test the site's capacity (or its ability to PROVISION one). Returns [ [siteName, requiredText, capacityText, fits(0/1), note], ... ]. This is the same "does the host have room?" question a K8s scheduler / CI runner answers.no extension

TRUE only if every site can host its parts (fits or can provision).no extension