Addressed PR comments

rfd/0001-tooling-requirements.md

@@ -71,6 +71,8 @@ Existing files in this repo should not be moved until there is a compelling reas
 │   │   ├── docs/
 │   │   ├── workflows/
 │   │   │   ├── ci.yaml
+│   │   │   ├── go.mod
+│   │   │   ├── go.sum
 │   │   │   └── ...
 │   │   ├── .gitignore
 │   │   ├── CHANGELOG.md
@@ -86,6 +88,8 @@ Existing files in this repo should not be moved until there is a compelling reas
 │   │   ├── workflows/
 │   │   │   ├── cd.yaml
 │   │   │   ├── ci.yaml
+│   │   │   ├── go.mod
+│   │   │   ├── go.sum
 │   │   │   └── ...
 │   │   ├── .gitignore
 │   │   ├── CHANGELOG.md
@@ -124,11 +128,10 @@ The status check workflows should not trigger upon changes to specific paths, ra
 This workflow should run when a PR is merged, and optionally upon PR commits as a way to produce test builds. When ran, this workflow should upload artifacts as Github Packages where possible. These artifacts should not be uploaded to AWS unless absolutely necessary, and with Security's permission, as outlined in the [Security considerations section](#security-considerations). The name of these artifacts should include a dev tag generated by `git describe --tags` to ensure uniqueness.
 
 #### Release workflow
-The release workflow should be triggered when a new version is added to the CHANGELOG on `main` branch. When this occurs, the workflow should:
-1. Extract the new version from the CHANGELOG.
-2. Create a new Git tag targeting the commit that modified the CHANGELOG, with name `v<new version>-<project name>` with all separator characters (e.g. spaces and underscores) separated by dashes. This tag should be parsable by [this npm package](https://www.npmjs.com/package/semver) that Renovate uses for semver coercion.
-3. Build a new release of the tool, following the general logic of the CD workflow. Either the release version or Git tag may be used where appropriate.
-4. Create a new release, named after the Git tag, that includes the changes from the CHANGELOG. The release should also either include the built artifacts, or instructions on retrieving them (such as `docker pull ghcr.io/gravitational/shared-workflows/some-project:v1.2.3`).
+The release workflow should be triggered a new tag is cut. When this occurs, the workflow should:
+1. Verify that the tag matches the name `v<new version>-<project name>` with all separator characters (e.g. spaces and underscores) separated by dashes. It should also check to ensure that the version is listed in the CHANGELOG. This tag should be parsable by [this npm package](https://www.npmjs.com/package/semver) that Renovate uses for semver coercion.
+2. Build a new release of the tool, following the general logic of the CD workflow. Either the release version or Git tag may be used where appropriate.
+3. Create a new release, named after the Git tag, that includes the changes from the CHANGELOG. The release should also either include the built artifacts, or instructions on retrieving them (such as `docker pull ghcr.io/gravitational/shared-workflows/some-project:v1.2.3`).
 
 ### Project releases
 The process for releasing a new version of a project should be as follows: