Stage S5 — Deployment scripts, the port and the revert path
P Stage correspondence. S5 Release scripts. These are the same stage identities used by the product overview and case walkthrough. A checkpoint or nested task conversation stays inside its owning stage.
Placement after authoring
P S5 release scripts through S8 recovery are delivery follow-through after source authoring, tests and review. The same source.deployer responsibility retains target selection, packet revisions, confirmations and effect journal through these phases. Generate ordered API requests, parameterised SQL/migrations and build/deployment commands only where the accepted change needs them. H4 approves the exact packet; H5 and applicable effect gates precede deployment; independent target proof and any due recovery remain required before closing a delivery request. This is not Data S8 precipitation or asynchronous learning. Validation (S4) and deploy and verify (S7) do each raise a precipitation event: what the change had to become, and what the environment required, is filed as a proposal for the asynchronous workflow and never delays the delivery (Stage Precipitation).
Purpose
In the customer-specific development module (id source), a reviewed change is not a delivered change. This stage produces exactly three things, and a case missing any of them is not done (DG-5): the script set for the environments the brief names, the port prepared (a commit on a worktree, or the recorded "no counterpart"), and the revert path.
Inputs → Outputs
In: the reviewed merge-request head and its source-tree hash, the reviewer's verdict, the environments the brief named. Out: artifacts, database scripts and configuration items per lineage; the port prepared — a commit on a worktree or the recorded no master counterpart; revert commits or a teardown; gate H4 on the set.
What happens
| Stage | What happens | Who |
|---|---|---|
| S5 deployment scripts | the set for the environments the brief names (artifacts + DB scripts + config items, per lineage), the port prepared (a commit on a worktree from the port procedure across layouts, fix commits only, source commit named; appsettings never carried across F: [rules]) or the recorded outcome no master counterpart, and the revert path (revert commits / teardown) | deployer |
What runs this stage
| Agents | source.deployer |
| Isolated sub-agents | — |
| Memory domains it reads / proposes to | source/<repository> branch maps and the port procedure (Agents Memory) |
| Skills it runs | port between layouts · PL/SQL snapshot + signature (Agents Memory and Skills) |
| Its branch of the graph | Customer-Specific Development Module § 0 — the module's agent tree, its memory branch and its skills · the component list is Components — Development |
Every stage also uses source.root — the only profile that reaches the human — and, where it writes, the shared skill common.effect-applier (Gating).
Rules this stage carries, taken from real changes
P Case-series and mixed release contract: Case journeys §§ 5–6 requires the ordered commit series, exact source/target heads, each required database row/script, package and consumer image, external template and process version, with compatibility dependencies and target assertions. UI/backend order is case-specific. Ports can run in any declared direction; subject equality is not equivalence, and a protected-ref rewrite invalidates affected evidence. Missing scripts/rows are explicit blocking obligations, not an implied manual step. Revert/re-add iterations remain in the case history.
- The target set is the one the brief names (G3): S5 produces scripts for the environments in the brief — QA, STAGING, PROD, or a subset — never a fixed "bulstrad-prod set".
- Both terms are defined here (D105): cherry-pick (adapt if diverged) is the estate's own step between its branches; port is the module's procedure when the change crosses the two layouts —
merge-treefeasibility check, path rewrite between the two lineages —src/<Area>/<Svc>onbulstrad-staging/bulstrad-prodandsrc/PolicyAdministrationSystem/<Svc>(PAS services) orsrc/Serdica/<Svc>(platform services) onmaster/bulstrad-qa, from the path map in thesource/serdica-backendnode, layout files excluded, regenerated CI — and the port is a commit of its own naming the source commit. The port is prepared here and opened in S7 (D141, reconciling the two readings): S5 makes the port commit on a worktree and records itsmerge-treefeasibility, so the brief's port plan is proven before H4; the port merge request is opened only after PROD verification in S7 (within DG-9's one business day), or the brief records why it goes first (G18). The estate's own order stands underneath: MR →bulstrad-staging→ deploy and verify → cherry-pickbulstrad-prod→ deploy and verify →masterlast F: [branch-per-env rule]. - "No master counterpart" is an allowed S5 outcome (G29, G27): recorded with the reason (the feature does not exist on master, or master took another design — the Elsa decision), and DG-5 is satisfied by the customer-lineage deploy alone.
- An old-layout library fix is a NuGet release plus every consuming service image (G32): S5 enumerates the consumers on the target environment; that list is the blast radius (G35).