@@ -142,6 +142,7 @@ and push. Ask me before anything that removes or rewrites history.
 | [loader/](loader/README.md), `loader-cli/`, `loader-compat-check/` | The loader library that installs a package into a Rock database (for .NET 10 and for Rock's .NET Framework, as the `SparkDevNetwork.Rock.SampleData.Loader` NuGet package), its command line for developers and test harnesses, and the check that both builds compute the same keys. |
 | [validation/](validation/README.md) | Tolerances and the script that grades generated data, plus the invariants, contract, and standards check the verify tool uses. |
 | [verify/](verify/README.md) | The tool that proves each package works on one exact Rock and writes its receipt. Publishing needs a passing receipt. |
+| [release/](release/README.md) | The Rock releases each release builds for, and the script that merges a release into the hosted package index. `.github/workflows/release.yml` publishes the packages and the loader on a version tag. |
 | [datasets/](datasets/README.md) | One manifest per dataset, with its settings. |
 | [content/](content/README.md) | Fonts for check images, and later the text pools. |
 
 
@@ -26,6 +26,10 @@ This log wins over the [design spec](design-spec.md) wherever the two disagree.
 | 124 | 2026-10-21 | Each dataset manifest (`datasets/*.json`) holds its card for Rock's installer: a summary, what it is best for, two to four highlights, and its people, households, campuses, and typical install time, measured from real loads. The loader embeds the manifests, and `SampleDataDatasets` reads them. The builder refuses a manifest without a card, and the verify tool fails a default-seed load whose people or households differ from the card by more than 2%. | Rock's block shows every dataset before it downloads one, from the loader it already has. The card sits beside the settings that make the dataset, and verify keeps its numbers from going stale. |
 | 125 | 2026-10-21 | Steps are their own part, `Steps`, loaded after notes. Choosing steps loads small groups, serving teams, and giving too. The part holds both step programs, the Discipleship Path and the Student Path (decisions 115 to 119). The Student Path's student check-ins come from the attendance plan, not the attendance rows, so steps do not need the attendance part. Steps plan only when they load, and Cast step stories, the students' among them, are checked only when steps loaded. | Steps are a feature a person can want or not, like prayer or notes. Each Small Group, Serve, and Lead step copies a membership that small groups or serving wrote, open requests to serve come from serving, and each Give step must agree with the journey stage giving writes. So a step needs those rows to be true, which widens the rule in decision 121 from rows that point at another part's rows to rows that must agree with them. The attendance plan holds exactly the check-ins the attendance step writes, so the student steps are the same as in a full load whether or not attendance loads, and choosing steps does not also force attendance. Without attendance, Rock shows student steps without the check-ins behind them, the way adult steps already count family Sundays from the plan. Nothing after steps reads them, so leaving them out changes no other part. |
 | 126 | 2026-10-22 | The building campaign (decision 109) is church setup, not a part. Its fund, campus accounts, campaign dates, Create Pledge page, and statement template settings load with configuration in every load. The fund's goal, written into its description from the planned pledges, is written in every load too. The pledges and campaign gifts, the Cast's (decisions 110 to 112) and the Crowd's and businesses' (decisions 113 and 114), belong to the Giving part. They are written in the Giving step, not a step or part of their own, and the Cast's campaign stories are checked only when giving loaded. All pledges are planned in every load, before giving is planned. | A fund, its accounts, and page settings are setup a church has before anyone gives, like the funds and campus accounts that already load with configuration. A person who leaves out giving still gets a Create Pledge page that works. Pledges and campaign gifts are giving records. Most campaign gifts are a line on a usual gift, so they cannot load without giving, and a pledge without its gifts would show every pledger as not started. Planning the pledges in every load keeps the giving plan the same, so prayer, which reads that plan, does not change when giving is left out. It also keeps the fund the same in every load, since its goal comes from the pledged total. The generated pledgers are drawn from the giving patterns people carry, which always load, so the draw needs no other part. No other part reads pledge rows. |
+| 127 | 2026-10-21 | Releases are built by the release workflow (`.github/workflows/release.yml`), never on a developer's machine. For each Rock release in `release/rock-releases.json`, it checks out that Rock from SparkDevNetwork/Rock (a release tag, or a pinned commit before Rock tags it), builds it with Visual Studio's MSBuild, starts SQL Server, writes every dataset's package, runs the verify tool, and runs the publishing gate. A version tag (`v1.0.0`) publishes. A manual run is a dry run unless it is on `main` and asks to publish. | Each package is for one exact Rock (decision 52), so one release covers every supported Rock. A clean machine for every run means a package never depends on what a developer had built or installed. |
+| 128 | 2026-10-21 | Published files never change. A release uploads each package and its receipt to `sampledata/packages/v{version}/rock-{Rock version}/`, cached for a year. A re-run skips a file already there with the same bytes and stops at one with other bytes. The index, `sampledata/packages/index.json`, is merged and uploaded last, cached for 5 minutes. It lists each dataset once per Rock version: a release replaces the entry for the same dataset and Rock, and entries for other Rocks stay. | Every package URL can be cached forever, a failed run can simply be run again, and no one sees a package in the index before its file exists. Older packages keep working at their own paths after the index moves on. |
+| 129 | 2026-10-21 | A prerelease tag (`v1.1.0-beta.1`) publishes the loader as a NuGet prerelease and uploads its packages, but changes only `packages/index-prerelease.json`: the stable index plus the prerelease. A stable release writes both indexes. | Rock's installer block reads `index.json`, so a church never gets a prerelease. Testers point the block at the prerelease index instead. |
+| 130 | 2026-10-21 | Publishing stores no secrets. The publish job runs in the `release` GitHub environment, which needs a person's approval and allows only `main` and `v*` tags. It signs in to nuget.org with trusted publishing, and to Azure with OpenID Connect as an identity that trusts only that environment and whose only role is Storage Blob Data Contributor on the `sampledata` container. | There is no key to leak, rotate, or expire. The identity can write only sample data, and a person approves every publish. |
 
 ## Time
 
 
@@ -34,6 +34,7 @@ The words this project uses, in alphabetical order.
 | **Mass send** | An email, text, or push sent to 25 or more people at once. Calibration part 7 measures them. |
 | **Opportunity** | One way to serve that people can ask about, such as Greeter. Each opportunity places people on its serving team. |
 | **Package** | A zip the builder writes for one dataset and one exact Rock: data files only, never SQL, with a checksum for every file in `package.json`. |
+| **Package index** | `index.json`, the hosted list of packages that Rock's installer block reads, at `storage.rockrms.com/sampledata/packages/`. The release workflow merges each release into it and uploads it last (decision 128). |
 | **Pending** | A team member who has connected but is not serving yet. The team leader makes them Active after onboarding. The scheduler only schedules Active members. |
 | **Persona** | A behavior pattern, such as a weekly giver or a holiday-only attender. |
 | **Pledge** | A promise to give a total to a fund over set dates, with an optional frequency. Rock's Pledge Analytics compares it with what the giving unit gave. |
@@ -42,6 +43,7 @@ The words this project uses, in alphabetical order.
 | **Position** | A room a serving team serves in, with a minimum, desired, and maximum number of people at each service. |
 | **Profile** | The blended target numbers the builder uses, in `calibration/profiles/`. |
 | **Relative date** | A date stored as `yearsAgo` plus a month and day, or as `daysAgo`, instead of a fixed date. |
+| **Release workflow** | `.github/workflows/release.yml`. On a version tag it builds, verifies, and publishes every package for every supported Rock, and pushes the loader to nuget.org (decision 127). |
 | **Rhythm step** | A step that is a habit, such as being in a small group or giving. It starts and can stop. A milestone step happens once, such as baptism. See [Steps](steps.md). |
 | **Rotation** | How often a volunteer serves: one of Rock's four schedule templates (every week, every other week, 1st and 3rd, or 2nd and 4th). |
 | **Seed** | The text every random choice starts from. The same seed and anchor give the same data. |