stzDeploymentSite

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

the access config (Q-fluent: chainable via the ...Q suffix)QCSXTZZZIBWU

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

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

auth is EITHER a plain reference string (e.g. "env/DEPLOY_KEY", back-compat) OR a stzSecret. When it is a secret, the site stores the OBJECT and displays only its redacted descriptor -- the key never lands in Config/ConfigJson.QCSXTZZZIBWU

reference the auth secret BY NAME from a central stzSecretStore. The site holds NO key and NO store object -- only the name (Haro copies objects on assignment, so a held store would be a private copy whose audit no one sees). The reveal is done through the SHARED store, passed by reference at reveal time (ResolveAuthVia), so the store's gate applies AND the store audits it. This is how a project keeps ONE complete audit trail across every reveal.QCSXTZZZIBWU

(no comment in the source: the name reads as a sentence) set store atQCSXTZZZIBWU

(no comment in the source: the name reads as a sentence) set launch withQCSXTZZZIBWU

(no comment in the source: the name reads as a sentence) set status withQCSXTZZZIBWU

what the host PROVIDES (its capacity). For a real host it is discovered via the provider API; for a fixed host it is declared here.QCSXTZZZIBWU

name a provisioning provider -> this host can be CREATED/resized to meet a requirement (IaC-style), not just deployed to.QCSXTZZZIBWU

readsno extension

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

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

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

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

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

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

(no comment in the source: the name reads as a sentence) is store backedno extension

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

the site holds a secret (directly, or by name in a store) rather than a ref.no extension

the LIVE auth value -- GOVERNED. For a directly-held stzSecret it reveals with the actor gate; for a plain ref string it returns it as-is. A STORE-BACKED secret cannot be revealed here -- the store must be passed by reference so its audit is real; use ResolveAuthVia(store, actor).no extension

the store-aware reveal: the shared store is passed HERE (by reference), so its gate applies AND it AUDITS the access -- the project's one audit trail stays complete. For a non-store-backed site the store is ignored and this behaves like ResolveAuth(actor).no extension

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

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

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

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

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

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

the access config as inspectable DATA -- the LINK between the programming environment and this site (connection + storage + control). CAPACITY AND PROVIDER BELONG HERE. They are exactly what _SiteFeasibility() reads to decide whether a part fits a site or has to be provisioned -- and they appeared in NONE of the three renderings below. A site could be declared, printed and saved without the two facts that decide whether the deployment is possible, and a reloaded site would report "capacity not declared -- assumed ok", turning a SHORTFALL into a pass.no extension

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

the config, serialized -- so a target site can be SAVED, versioned, shared: the persistent link the dev/emulation environment reads to reach a site.no extension

(no comment in the source: the name reads as a sentence) save config tono extension

A live backend turns the site config into a REAL command run through the managed child (SpawnProcess) -- the same path stzBuilder uses to run zig. The commands are rehearsable (Commands() shows them before anything runs). :LocalRepo uses direct file ops; :GitRepo runs real git (proven end to end against a local bare repo); :Server runs scp/ssh; a scriptable host provisions via its provider CLI. The commands are correct wherever the tool + target exist -- in this sandbox git and the local repo complete; scp/ssh/docker/aws are generated and run through the same child, but need a real host/registry/account to finish.no extension

(no comment in the source: the name reads as a sentence) storeno 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

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

provision a scriptable host to meet a requirement (the IaC move -- bring the host into existence, don't just deploy to it). Runs the provider CLI via the child.no extension

the real commands, rehearsable (see them before they run)no extension

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

(no comment in the source: the name reads as a sentence) launch command lineno extension

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

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