- MODULE.bazel names the module progmasoft_catch3, the name it has in
  the registry, with bazel_compatibility >=8.0.0; //tools:version finds
  the version under the new name.
- .bcr/ holds the templates publish-to-bcr fills: metadata, source (the
  GitHub archive of the catch3-* tag) and the presubmit, which runs the
  test module on Debian, Ubuntu, macOS (x86-64 and arm64) and Windows
  with Bazel 8.x and 9.x.
- tests/Progmasoft/BazelModule is a module that depends on Catch3 as a
  user's does, through //:catch3_main and through //:catch3 with its
  own main. The root ignores it; Bazel Builds tests it with Bazel 8.x
  and 9.x on Ubuntu and Windows.
- Publish to BCR runs when a catch3-* release is published, or by hand
  for a tag, and opens the registry pull request from the fork of the
  maintainer, without attestations.
- The integration guide says how a module depends on progmasoft_catch3.

Claude-Session: https://claude.ai/code/session_01Ji7xZMYjc4zankoc7hGBE1

Every place that states the version says 0.4.0, written by
bazelisk run //tools:version -- 0.4.0, and the single-file distribution
carries it. The release notes describe the release: per-test coverage
with --coverage, secret-looking variables withheld from workers unless
--pass-env names them, the repository tools in C++17 under Bazel, and
versions with three numbers again.

Claude-Session: https://claude.ai/code/session_01Ji7xZMYjc4zankoc7hGBE1

The scripts in use become programs run with `bazelisk run //tools:<tool>`,
and arguments follow `--`:

  amalgamate     the single-file distribution; --check only compares it
  check          licenses, convenience headers, header guards, file names,
                 versions and whether the distribution is up to date
  third-party    compares third_party/ with its archives, or writes it
  version        prints the version, or moves every place that states it
  release-notes  prints a section of the release notes
  repo-info      reports the checkout and the tools on PATH; --json writes
                 it through yyjson, with the fields of Tala's repo-info

amalgamate writes what the Python script wrote, byte for byte, except for
the time of generation. That line is gone so that the output is
deterministic and --check can compare it.

MODULE.bazel now pins the archives of third_party/ by version and sha256,
so Bazel fetches and checks them instead of a tool of ours, and Renovate
reads the versions there.

Scripts nobody used are gone: fixWhitespace, updateDocumentSnippets,
buildAndTest, and updateDocumentToC, which rewrote unrelated documents.
CheckConvenienceHeaders leaves CTest, since //tools:check runs it in CI.
The Python of tests/TestScripts stays: those are tests, not tools.

Versions have four numbers from this release on.

The release notes get their date and name the tag prefix Catch3 uses from
now on. Every other version location already says 0.3.0; MODULE.bazel was
the one left.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

rules_swift reaches the module graph through protobuf and rules_apple,
resolved to 3.1.2. Its Windows autoconfiguration runs whenever
swiftc.exe is on PATH and, up to 3.4.1, writes a toolchain that
indexes APPLE_PLATFORMS_CONSTRAINTS with the undefined name arch, so
every Bazel build on such a host failed in analysis with "name 'arch'
is not defined". The hosted runners have no Swift, which is why CI
never saw it.

A single_version_override selects 3.4.2, the first fixed release with
the same compatibility level. It needs protobuf 29 and apple_support
1.24.2, both already satisfied by the graph (protobuf stays at 33.4);
nlohmann_json, only used by rules_swift's own tools, moves to
3.12.0.bcr.1 in the lockfile.

Verified on Windows with Swift 6.4.1 on PATH: bazel test
//tests/Progmasoft:property_tests passes, where it failed before.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>