# Release Record And Rollback

**Produce one release record per deployment, stored in the repository.** A
chat message is not a record. Each record states:

- the full commit hash, never a branch or tag name alone;
- the resolved version of every dependency, copied from the lock file;
- every configuration key the build or the running process reads, with values
  redacted and the origin of each value named;
- the target environment, the timestamp, and who or what deployed.

**Produce the rollback as numbered steps.** Write them for a person who did
not build the release. Each step names the command, the output that confirms
it worked, and what to do if that output does not appear. State how long the
whole rollback takes. If the release contains a data migration, state whether
the rollback needs a reverse migration, and write that migration too.

**Prove the release is reproducible before you call it shipped.** Build the
recorded commit a second time and compare the artifact. If the two builds
differ, name the cause — an embedded timestamp, an absolute path, an unpinned
dependency — and either remove it or record it as a known difference.

**Rehearse the rollback against a live deployment.** Do it at least once every
90 days `[ASSUMPTION A-8]` and write the date and the measured duration into
the record. A rollback nobody has executed is a plan, not a rollback.

**Record a configuration change like a release.** A change to a value alone
gets its own record with the same fields `[ASSUMPTION]`. Without it, rolling
back code silently reverts settings that were never part of the release.

**A reviewer checks:**

- rebuilding the recorded commit produces the same artifact;
- the rollback was last executed against a live deployment less than 90 days
  ago, with the date and duration written down;
- the record contains no readable secret, and omits no configuration key the
  running process reads;
- every rollback step names a command and the output that confirms it, so
  someone who did not build the release can follow it;
- a data migration in the release has a written reverse path.

**Boundary.** Branching, tests, pull request and review belong to the
contribution skill. This skill starts when a change is about to reach a
running environment, and it ends when the rollback is proven.