stzDelivery

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

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

the structured log of the delivery's phases (Deploy). Queryable + renderable: oDelivery.Log().AsJson(), oDelivery.Log().EntriesOfLevel(:error).no extension

attach the solution's application model -- named datasets + per-part roles. The emulator renders each part FROM it (its real menu / computed dashboard), instead of a shared placeholder.QCSXTZZZIBWU

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

(no comment in the source: the name reads as a sentence) has app topologyno extension

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

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

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

(no comment in the source: the name reads as a sentence) add super appno extension

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

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

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

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

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

declare the Softanza capabilities a part's code uses (:PivotTable, :Unicode, ...). Stored as lowercased keys (the canonical form).no extension

ONE CAVEAT, and it is Haro's, not this method's: an attribute store COPIES (probed -- bind a service on your own handle afterwards and this delivery will not see it). So either finish configuring the registry BEFORE attaching it, or make later changes THROUGH the accessor, which reaches the stored object: oDelivery.ServicesQ().BindLiveQ(:payments, oImpl, "stripe_key").QCSXTZZZIBWU

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

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

Which external services a part's code actually calls. The parallel of NeedsIn (Softanza capabilities); this is the OUTSIDE world.QCSXTZZZIBWU

(no comment in the source: the name reads as a sentence) service needs inno extension

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

The rehearsed surface, one record per service: [ :service, :posture, :secret, :bound, :parts ] This is the answer to "what does shipping this actually require of me?", available before a single byte is built.no extension

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

The credentials a production deploy will require -- names only, never values.no extension

REHEARSE THE GATE. The registry only reports sandbox-in-production once its phase IS production, so a pre-flight check asks the question in that frame and then puts the phase back -- you learn what shipping would say without declaring that you are shipping. (The plane's own habit: rehearse, then commit.)no extension

(no comment in the source: the name reads as a sentence) services are production readyno extension

(no comment in the source: the name reads as a sentence) why services not readyno extension

Project parts AND services into one graph, so a rule can ask the question neither side can answer alone: does a part that is BOUND TO A SITE (i.e. destined for production) depend on a service that is still a fake? See stzServiceRuleSet.no extension

a first inference: scan the app source for capability markers -> keys. Upgradeable to the stzCodeGraph call-edge analysis (lexical starting point).no extension

WHERE each part deploys in production: bind a target site to the part it hosts. Site-first, part-second -- demystified: "deploy to <site>, the <part>". (Deploy(:Emulated) needs no sites -- it runs in the browser; production does.)no extension

the executing actor -- governs whether Deploy(:Production) COMMITS or only rehearses (only an effectful actor may cross the governed bridge to reality).no 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) deployment actorno extension

what a part NEEDS from its host: memory / compute / storage (a stzResourceSpec). Parallels NeedsIn (capabilities); here it is the physical footprint the target must provide -- the CI/IaC "resources.requests" idea.no extension

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

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

ship an emulator's bundle DIRECTORY as a part's production artifact. The bundle you built and debugged with Deploy(:Emulated) becomes what Deploy(:Production) ships -- the same tree, one directive. pBundle is a stzEmulator or a dir path.no extension

ship only pcPart's SLICE of the bundle -- its app (index.html) + engine subset (stz_<part>.wasm) + the bridge (stz.js), not the whole mission-control. A frontend deploys only what it needs to run.no extension

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

REHEARSE the placement & scope plan -- no bytes built. This is Build()'s thinking made visible (VSF rehearse->plan->commit).no extension

Deploy() covers BOTH phases (Scope-Oriented: the deploy scope is the frame). :Emulated -> the programming phase: generate the web-based mission-control emulator (via stzEmulator) where the whole solution runs and is debugged visually, part by part. :Production -> the same parts cross the governed bridge to real target SITES. Deploy(:Production) DRIVES a stzDeployment: it binds each part to its site (from DeployTo) and, IF the actor may commit (effectful), STORES + LAUNCHES it -- otherwise it returns the deployment as a rehearsal. Emulation rehearses in the browser; production commits.no extension