ceedling 1.1.10 → 1.2.0

data/ceedling.gemspec

@@ -33,10 +33,23 @@ Ceedling projects start with a YAML configuration file. A variety of conventions
   s.metadata = {
     "homepage_uri"      => s.homepage,
     "bug_tracker_uri"   => "https://github.com/ThrowTheSwitch/Ceedling/issues",
-    "documentation_uri" => "https://throwtheswitch.github.io/Ceedling/",
+    "documentation_uri" => "https://docs.throwtheswitch.org/Ceedling/",
     "mailing_list_uri"  => "https://throwtheswitch.discourse.group",
     "source_code_uri"   => "https://github.com/ThrowTheSwitch/Ceedling",
-    "funding_uri"       => "https://github.com/sponsors/ThrowTheSwitch"
+    "funding_uri"       => "https://github.com/sponsors/ThrowTheSwitch",
+    "changelog_uri"     => "https://github.com/ThrowTheSwitch/Ceedling/blob/master/docs/Changelog.md",
+    # Machine-discoverable pointer to this gem's own Software Bill of Materials, which is
+    # published as a release asset rather than carried inside the gem.
+    #
+    # Pinned to this version's release rather than `releases/latest/download`. The
+    # filename carries a version, so a `latest` URL would stop resolving the moment a
+    # newer release existed, and it never resolves to a pre-release at all.
+    #
+    # The tag is reconstructed by inverting what stamp_gem_version.sh does: it turns the
+    # tag's first hyphen into a dot, so the dot preceding a pre-release word becomes a
+    # hyphen again. v1.2.0-pre.7 ⏩️ 1.2.0.pre.7 ⏩️ v1.2.0-pre.7
+    "sbom_uri"          => "https://github.com/ThrowTheSwitch/Ceedling/releases/download/" \
+                           "v#{s.version.to_s.sub( /\.(?=[a-z])/, '-' )}/ceedling-#{s.version}.cdx.json"
   }
   
   s.required_ruby_version = ">= 3.0.0"
@@ -44,18 +57,14 @@ Ceedling projects start with a YAML configuration file. A variety of conventions
   # Used for both development and runtime
   s.add_dependency "rake", ">= 12", "< 14"
 
-  s.add_dependency "diy", "~> 1.1"
   s.add_dependency "constructor", "~> 2"
   s.add_dependency "thor", "~> 1.3"
   s.add_dependency "deep_merge", "~> 1.2"
 
-  # `erb` is no longer a default gem on some Ruby versions Ceedling supports;
-  # it must be declared explicitly for plain `gem install` (non-Bundler) users.
-  # >= 2.2: minimum `erb` version supporting what Ceedling uses. A loose floor lets
-  # Ruby's own built-in `erb` satisfy this on any Ruby that still bundles one,
-  # avoiding an unnecessary fetch + native-compile of standalone `erb`/`cgi` gems.
-  s.add_dependency "erb", ">= 2.2"
-  # `benchmark` is no longer part of the default gems with Ruby 3.5
+  # `benchmark` is no longer a default gem as of Ruby 3.5, so it must be declared
+  # explicitly for plain `gem install` (non-Bundler) users. The floor is kept loose
+  # so Ruby's own built-in copy satisfies it on any version that still bundles one,
+  # rather than forcing an unnecessary fetch.
   s.add_dependency "benchmark", ">= 0.3"
 
   s.add_dependency "unicode-display_width", "~> 3.1"
@@ -72,10 +81,72 @@ Ceedling projects start with a YAML configuration file. A variety of conventions
   s.files        += Dir['vendor/unity/src/**/*.[ch]']
 
   s.files        += Dir['**/*']
-  s.files.reject! { |f| f.start_with?('site-web/') }
+  # Dir['**/*'] above sweeps the working tree, so anything a local run leaves behind
+  # would otherwise be packaged into a release.
+  #
+  # System test artifacts are the worst of it. `rake spec:system:debug:*` retains whole
+  # deployed projects under specout/, which both bloats the gem and breaks packaging
+  # outright, since a retained project nests a vendored Ceedling deep enough to exceed
+  # the tar name limit (Gem::Package::TooLongFileName).
+  #
+  # Build output matters for a second reason. Running the examples or the plugin example
+  # projects locally fills their build/ directories with object files and executables,
+  # and shipping compiled binaries in a release gem is exactly what trips the security
+  # scanners described in docs/SECURITY.md. `build` is matched as a whole path segment
+  # on purpose: each vendored submodule ships a `meson.build` file, and a substring test
+  # would silently drop all three.
+  s.files.reject! do |f|
+    f.start_with?('site-web/') ||                        # Hosted/versioned docs site -- not needed offline
+    f == 'tools' || f.start_with?('tools/') ||            # Dev tooling the Rakefile above shells out to
+    f == 'docs/mkdocs' || f.start_with?('docs/mkdocs/') ||  # Raw docs source -- site-local/ is the built artifact the gem actually serves
+    f == 'specout' || f.start_with?('specout/') ||        # Retained system test artifacts and run logs
+    f == 'build' || f.start_with?('build/') || f.include?('/build/') ||  # Local build output
+    f.match?(/\.(cdx|spdx)\.json\z/) ||                   # Generated SBOMs -- release assets, not gem contents
+    # Upstream fff's own test apparatus. Ceedling needs fff.h from this tree and
+    # nothing else, and these three directories are 1.2 MB that no Ceedling code path
+    # references. gtest/ additionally holds BSD-3-Clause Google Test source, so leaving
+    # it out keeps the gem MIT throughout. All three stay in the repository, where
+    # plugins/fff/Rakefile can still reach them.
+    # Both halves per directory: the prefix catches the contents, the equality catches
+    # the directory entry itself, which the file sweep lists separately
+    f == 'plugins/fff/vendor/fff/gtest' || f.start_with?('plugins/fff/vendor/fff/gtest/') ||
+    f == 'plugins/fff/vendor/fff/test' || f.start_with?('plugins/fff/vendor/fff/test/') ||
+    f == 'plugins/fff/vendor/fff/examples' || f.start_with?('plugins/fff/vendor/fff/examples/') ||
+    # Upstream's drivers for those same tests, which build nothing once the
+    # directories above are gone
+    f == 'plugins/fff/vendor/fff/Makefile' ||
+    f == 'plugins/fff/vendor/fff/buildandtest'
+  end
+
+  # Dir['**/*'] cannot see dotfiles, and a few are required for the spec suites that
+  # ship with this gem to run at all. Those suites exist to support certification
+  # self-testing, driven by separate tooling against the versioned gem, which is also
+  # why spec/, Gemfile, and Gemfile.lock are packaged rather than trimmed out.
+  #
+  # .rspec carries the `-I spec/support` load paths that every spec's
+  # `require 'spec_helper'` depends on. Without it rspec cannot load a single spec file,
+  # failing with `cannot load such file -- spec_helper`.
+  #
+  # .simplecov is the shared coverage configuration that both spec/support/spec_helper.rb
+  # and spec/support/system/simplecov_boot.rb load by name.
+  #
+  # The fff plugin ships its own separate spec suite with its own .rspec.
+  #
+  # Added after the rejections above deliberately. None of these match a rejection
+  # pattern, and listing them explicitly keeps git-only dotfiles (.gitignore,
+  # .gitattributes, .gitmodules) and build output out.
+  s.files += [
+    '.rspec',
+    '.simplecov',
+    'plugins/fff/.rspec',
+  ].select { |f| File.exist?( f ) }
 
   s.test_files = Dir['test/**/*', 'spec/**/*', 'features/**/*']
   s.executables = ['ceedling'] # bin/ceedling
 
-  s.require_paths = ["lib", "vendor/cmock/lib"]
+  # CMock and DIY ship inside the gem rather than arriving as gem dependencies, so
+  # their lib directories belong on the load path. DIY's upstream gem has been
+  # unmaintained since 2009. bin/ceedling also unshifts the vendored DIY path before
+  # requiring it, which is what makes the vendored copy win wherever both exist.
+  s.require_paths = ["lib", "vendor/cmock/lib", "vendor/diy/lib"]
 end

data/docs/BreakingChanges.md

@@ -8,13 +8,57 @@ These breaking changes are complemented by three other documents:
 
 ---
 
+# [1.2.0] — Prerelease
+
+## Mocks included through a folder are named by that folder
+
+`:cmock` ↳ `:mock_name_include_folder` is on by default. A mock included through a folder, such as `#include "drivers/uart/mock_config.h"`, now gets an include guard and `Init()`, `Verify()`, and `Destroy()` functions named by that folder (e.g. `drivers_uart_mock_config_Init()`). This lets one test file mock two same-named headers. The runner Ceedling generates calls the new names, so most projects need no change. A test or support file that calls a mock’s lifecycle functions directly, or references its include guard, must use the new names or set `:mock_name_include_folder` to `FALSE`.
+
+## `-P` and `--no-line-commands` rejected with test preprocessing
+
+Ceedling now refuses these preprocessor options at startup whenever test preprocessing is enabled. That is the case when `:project` ↳ `:use_test_preprocessor` is `:mocks`, `:tests`, or `:all`, or when Partials are enabled.
+
+Both options strip the line markers Ceedling reads in preprocessor output to find `#include`s, mockable functions, and test cases. A project that used either one with test preprocessing already lost some of these, often without a clear error.
+
+Remove the options from these places:
+
+1. `:flags` ↳ `:test` ↳ `:preprocess` and `:compile`, and the same operations in plugin build contexts such as `:gcov`. Preprocessing uses `:compile` flags wherever no `:preprocess` flags apply.
+1. The arguments of the `:test_file_full_preprocessor` and `:test_file_directives_only_preprocessor` tools.
+
+If you need an option in `:compile` flags only, give `:preprocess` flags of their own without it.
+
+## IDE console report lines are GCC diagnostics by default
+
+`report_tests_ide_stdout` now lists each failed and ignored test the way GCC reports a problem. IDEs read these lines as errors and warnings without extra configuration.
+
+```
+test/TestModel.c:21:1: error: testInit: Expected 5 Was 4
+```
+
+The earlier lines looked like this:
+
+```
+test/TestModel.c:21:testInit: "Expected 5 Was 4"
+```
+
+A multi-line message no longer repeats the file, line, and test on every line. Its first line stays with the test’s location, and the rest follow indented. The Gcov, Bullseye, and Valgrind plugins print their test results through this plugin when it is enabled, so their lines change too.
+
+A script, tool, or IDE configuration that matches the earlier lines must be updated. To keep the earlier lines, set the format to `:legacy`:
+
+```YAML
+:report_tests_ide_stdout:
+  :format: :legacy
+```
+
+---
+
 # [1.1.0] — 2026-07-16
 
 ## `--ruby-replacement` CLI flag to enable inline Ruby string expansion
 
 As a security precaution, [inline Ruby string expansion][inline-ruby-string-expansion] within project configuration strings is now disabled by default. The feature still exists and functions, but it must be specifically enabled by the user at the command line each time Ceedling executes.
 
-[inline-ruby-string-expansion]: https://throwtheswitch.github.io/Ceedling/1.1.0/configuration/project-file/#inline-ruby-string-expansion
+[inline-ruby-string-expansion]: https://docs.throwtheswitch.org/Ceedling/1.1.0/configuration/project-file/#inline-ruby-string-expansion
 
 ---
 
@@ -60,7 +104,7 @@ Flags specified for release builds are applied to all files in the release build
 
 Ceedling’s preprocessing features have been greatly improved. Preprocessing is now no longer all-or-nothing with a simple boolean value.
 
-In place of `true` or `false`, `:use_test_preprocessing` now accepts:
+In place of `true` or `false`, `:use_test_preprocessor` now accepts:
 
 * `:none` disables preprocessing (equivalent to previous `false` setting).
 * `:all` enables preprpocessing for all mockable header files and test C files (equivalent to previous `true` setting).

data/docs/CONTRIBUTING.md

@@ -2,20 +2,22 @@
 
 👍🎉 _First off, thanks for taking the time to contribute!_ 🎉👍
 
-The following is a set of guidelines for contributing to any of ThrowTheSwitch.org's projects or the website itself, hosted at throwtheswitch.org or ThrowTheSwitch's organization on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
+The following is a set of guidelines for contributing to any of ThrowTheSwitch.org’s projects or the website itself, hosted at throwtheswitch.org or ThrowTheSwitch’s organization on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
 
 ### Table Of Contents
 
 - [Code of Conduct](#book-code-of-conduct)
 - [Asking Questions](#bulb-asking-questions)
 - [Opening an Issue](#inbox_tray-opening-an-issue)
-- [Feature Requests](#love_letter-feature-requests)
+- [Feature Requests](#seedling-feature-requests)
 - [Triaging Issues](#mag-triaging-issues)
 - [Submitting Pull Requests](#repeat-submitting-pull-requests)
 - [Writing Commit Messages](#memo-writing-commit-messages)
+- [Pull Request Checklist](#white_check_mark-pull-request-checklist)
+- [Who Loves Emoji?](#heart-who-loves-emoji)
 - [Code Review](#white_check_mark-code-review)
-- [Coding Style](#nail_care-coding-style)
 - [Certificate of Origin](#medal_sports-certificate-of-origin)
+- [Coding Style](#violin-coding-style)
 - [Credits](#pray-credits)
 
 ## :book: Code of Conduct
@@ -24,9 +26,9 @@ Please review our [Code of Conduct](CODE_OF_CONDUCT.md). It is in effect at all
 
 ## :bulb: Asking Questions
 
-> **Note:** Please don't file an issue to ask a question. We have an official forum where the community chimes in with helpful advice if you have questions.
+> **Note:** Please try to ask questions in our community forum where the community chimes in with helpful advice. Generally speaking, GitHub Issues should be reserved for bug reports and feature requests. That said, sometimes there’s a gray zone. Try your best.
 
-* [ThrowTheSwitch Forums](https://throwtheswitch.org/forums)
+* [ThrowTheSwitch Discourse forum](https://throwtheswitch.discourse.group)
 
 ### What should I know before I get started?
 
@@ -34,17 +36,17 @@ ThrowTheSwitch hosts a number of open source projects — Ceedling is the en
 
 Here are some of the main projects hosted by ThrowTheSwitch.org:
 
- - [Ceedling](https://www.github.com/throwtheswitch/ceedling) -- Build coordinator for testing C applications, especially embedded C (and optionally your release build too!)
- - [CMock](https://www.github.com/throwtheswitch/cmock) -- Mocking tool for automatically creating stubs, mocks, and skeletons in C
- - [Unity](https://www.github.com/throwtheswitch/unity) -- Unit Testing framework for C, specially embedded C.
- - [MadScienceLabDocker](https://www.github.com/throwtheswitch/madsciencelabdocker) -- Docker image giving you a shortcut to getting running with Ceedling
- - [CException](https://www.github.com/throwtheswitch/cexception) -- An exception framework for using simple exceptions in C.
+ - [Ceedling](https://www.github.com/throwtheswitch/ceedling) — Build coordinator for testing C applications, especially embedded C (and optionally your release build too!)
+ - [CMock](https://www.github.com/throwtheswitch/cmock) — Mocking tool for automatically creating stubs, mocks, and skeletons in C
+ - [Unity](https://www.github.com/throwtheswitch/unity) — Unit Testing framework for C, specially embedded C.
+ - [MadScienceLabDocker](https://www.github.com/throwtheswitch/madsciencelabdocker) [[Docker Hub](https://hub.docker.com/u/throwtheswitch?page=1&search=madscience)] — Docker image giving you a shortcut to getting running with Ceedling
+ - [CException](https://www.github.com/throwtheswitch/cexception) — An exception framework for using simple exceptions in C.
 
 There are many more, but this list should be a good starting point.
 
 ## :inbox_tray: Opening an Issue
 
-Before [creating an issue](https://help.github.com/en/github/managing-your-work-on-github/creating-an-issue), check if you are using the latest version of the project. If you are not up-to-date, see if updating fixes your issue first.
+Before [creating an issue](https://help.github.com/en/github/managing-your-work-on-github/creating-an-issue), check if you are using the latest version of the project. If you are not up-to-date, see if updating fixes your issue first. Consult the [Changelog](Changelog.md), [Known Issues](KnownIssues.md), and [Breaking Changes](BreakingChanges.md).
 
 ### :beetle: Bug Reports and Other Issues
 
@@ -52,23 +54,27 @@ A great way to contribute to the project is to send a detailed issue when you en
 
 In short, since you are most likely a developer, **provide a ticket that you would like to receive**.
 
-- **Review the documentation** before opening a new issue.
+- **Review [the documentation](https://docs.throwtheswitch.org/Ceedling/)** before opening a new issue.
 
 - **Try not to open a duplicate issue** Search through existing issues to see if your issue has previously been reported. If your issue exists, comment with any additional information you have. You may simply note "I have this problem too", which helps prioritize the most common problems and requests. 
 
 - **Prefer using [reactions](https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/)**, not comments, if you simply want to "+1" an existing issue.
 
-- **Fully complete the provided issue template.** The bug report template requests all the information we need to quickly and efficiently address your issue. Be clear, concise, and descriptive. Provide as much information as you can, including steps to reproduce, stack traces, compiler errors, library versions, OS versions, and screenshots (if applicable).
+- **Fully complete the bug report form.** [Opening a new issue](https://github.com/ThrowTheSwitch/Ceedling/issues/new/choose) offers a bug report form that requests all the information we need to quickly and efficiently address your issue. Be clear, concise, and descriptive. Provide as much information as you can, including steps to reproduce, stack traces, compiler errors, library versions, OS versions, and screenshots (if applicable).
+
+- **Tell us if a test result was wrong.** A test that passes when it should fail, or a test that silently does not run, is among the most serious problems a test tool can have. The bug report form asks about this directly.
+
+- **[Report security vulnerabilities privately](https://github.com/ThrowTheSwitch/Ceedling/security/advisories/new).** Do not open a public issue for a vulnerability. See the [Security Policy](SECURITY.md).
 
 - **Use [GitHub-flavored Markdown](https://help.github.com/en/github/writing-on-github/basic-writing-and-formatting-syntax).** Especially put code blocks and console outputs in backticks (```). This improves readability.
 
 ## :seedling: Feature Requests
 
-Feature requests are welcome! We don't have all the answers and we truly love the collaborative experience of building software together! That being said, we cannot guarantee your request will be accepted. We want to avoid [feature creep](https://en.wikipedia.org/wiki/Feature_creep). Your idea may be great, but also out-of-scope for the project. If accepted, we'll do our best to tackle it in a timely manner, but cannot make any commitments regarding the timeline for implementation and release. However, you are welcome to submit a pull request to help!
+Feature requests are welcome! We don't have all the answers, and we truly love the collaborative experience of building software together! That being said, we cannot guarantee your request will be accepted. We want to avoid [feature creep](https://en.wikipedia.org/wiki/Feature_creep). Your idea may be great but also out-of-scope for the project. If accepted, we will do our best to tackle it in a timely manner, but we cannot make any commitments regarding the timeline for implementation and release. However, you are welcome to submit a pull request to help!
 
 - **Please don't open a duplicate feature request.** Search for existing feature requests first. If you find your feature (or one very similar) previously requested, comment on that issue.
 
-- **Fully complete the provided issue template.** The feature request template asks for all necessary information for us to begin a productive conversation. 
+- **Fully complete the feature request form.** The feature request form asks for all necessary information for us to begin a productive conversation. 
 
 - Be precise about the proposed outcome of the feature and how it relates to existing features. Include implementation details if possible.
 
@@ -80,7 +86,7 @@ You can triage issues which may include reproducing bug reports or asking for ad
 
 We **love** pull requests! Before [forking the repo](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) and [creating a pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests) for non-trivial changes, it is usually best to first open an issue to discuss the changes, or discuss your intended approach for solving the problem in the comments for an existing issue.
 
-*Note: All contributions will be licensed under the project's license.*
+*Note: All contributions will be licensed under the project’s license.*
 
 - **Smaller is better.** Submit **one** pull request per bug fix or feature. A pull request should contain isolated changes pertaining to a single bug fix or feature implementation. **Do not** refactor or reformat code that is unrelated to your change. It is better to **submit many small pull requests** rather than a single large one. Enormous pull requests will take enormous amounts of time to review, or may be rejected altogether. 
 
@@ -90,19 +96,21 @@ We **love** pull requests! Before [forking the repo](https://help.github.com/en/
 
 - **Follow existing coding style and conventions.** Keep your code consistent with the style, formatting, and conventions in the rest of the code base. When possible, these will be enforced with a linter. Consistency makes it easier to review and modify in the future.
 
-- **Include test coverage.** Add unit tests when possible. Follow existing patterns for implementing tests.
+- **Include test coverage.** Add unit, integration, and/or system tests when possible. Follow existing patterns for implementing tests (see `spec/` directory and `spec:` tasks among root Rake tasks).
 
-- **Update the example project** if one exists to exercise any new functionality you have added.
+- **Update the example projects** in `examples/` where one would exercise any new functionality you have added.
 
-- **Add documentation.** Document your changes with code doc comments or in existing guides.
+- **Add documentation.** Document your changes with code doc comments or in the [documentation site](https://docs.throwtheswitch.org/Ceedling/) source under `docs/mkdocs/`.
 
-- **Update the CHANGELOG** for all enhancements and bug fixes. Include the corresponding issue number if one exists, and your GitHub username. (example: "- Fixed crash in profile view. #123 @jessesquires")
+- **Leave the Changelog to the maintainers.** Maintainers write the Changelog, Release Notes, and Breaking Changes entries when changes are prepared for release. Describe your change clearly in your pull request so those edits can happen.
 
-- **Use the repo's default branch.** Branch from and [submit your pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork) to the repo's default branch. Usually this is `main`, but it could be `dev`, `develop`, or `master`.
+- **Use the proper branch.** Branch from and [submit your pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork) to `master` for a fix to the latest release, or to `next_version` for the next minor or major release in progress. See [Branching & Releases](https://docs.throwtheswitch.org/Ceedling/latest/development/releases/).
 
 - **[Resolve any merge conflicts](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github)** that occur.
 
-- **Promptly address any CI failures**. If your pull request fails to build or pass tests, please push another commit to fix it. 
+- **Promptly address any CI failures**. If your pull request fails to build or pass tests, please push another commit to fix it. Only maintainers merge pull requests, and only once CI passes. 
+
+- **Read the CI summary comment.** Each CI run posts or updates a “sticky” comment on your pull request that collects CI job results and metrics from instrumentation. It lists failing jobs first. It flags any test leg that skips more specs than the same leg on the base branch. It reports test counts, coverage changes against the base branch, and the share of your changed Ruby lines that tests execute. See [`.github/WORKFLOWS.md`](../.github/WORKFLOWS.md) for how CI works.
 
 - When writing comments, use properly constructed sentences, including punctuation.
 
@@ -140,7 +148,7 @@ are making this change as opposed to how or what. The code explains
 how or what. Reviewers and your future self can read the patch, 
 but might not understand why a particular solution was implemented.
 Are there side effects or other unintuitive consequences of this
-change? Here's the place to explain them.
+change? Here’s the place to explain them.
 
  - Bullet points are awesome, too
 
@@ -155,7 +163,7 @@ See also: #456, #789
 
 ## :white_check_mark: Pull Request Checklist
 
-Not all Pull Requests require these things, but [here's a great list](CeedlingPullRequestChecklist.md) of things to check to see if it makes sense for your situation:
+Not all Pull Requests require these things, but [here’s a great list](CeedlingPullRequestChecklist.md) of things to check to see if it makes sense for your situation. The same checklist appears in the description of every new pull request.
 
 ## :heart: Who Loves Emoji?
 
@@ -191,6 +199,8 @@ Commit comments, Issues, Feature Requests... they can all use a little sprucing
 
 - Kindly note any violations to the guidelines specified in this document. 
 
+A maintainer reviews and merges every pull request.
+
 ## :violin: Coding Style
 
 Consistency is the most important. Following the existing style, formatting, and naming conventions of the file you are modifying and of the overall project. Failure to do so will result in a prolonged review process that has to focus on updating the superficial aspects of your code, rather than improving its functionality and performance.
@@ -201,15 +211,21 @@ When possible, style and format will be enforced with a linter.
 
 ### C Styleguide
 
-C code is linted with [AStyle](https://astyle.sourceforge.net/).
+C code follows the [ThrowTheSwitch Coding Standard](ThrowTheSwitchCodingStandard.md). No C linter is presently run automatically. Style is checked in review.
+
+Continuous integration does dynamically analyze the C that Ceedling generates and builds. One leg of the Linux test matrix builds and runs system tests under `AddressSanitizer` and `UndefinedBehaviorSanitizer`, with leak detection; any finding fails the build.
 
 ### Ruby Styleguide
 
-Ruby code is linted with [Rubocop](https://github.com/rubocop/rubocop)
+Ruby code is linted with [RuboCop](https://github.com/rubocop/rubocop). Linting covers the Lint, Metrics, Security, and Performance departments. Style, layout, and naming are deliberately not enforced, because this project follows the conventions described above rather than Ruby community defaults.
+
+Run `rake lint:setup` once to install the linting gems, which an ordinary `bundle install` does not fetch. Then run `rake lint` to check the whole project, or `rake lint:changed` to check only what your branch changed. `rake lint:fix` applies the corrections RuboCop can make safely.
+
+Continuous integration runs the same check on every pull request and reports findings as annotations on your diff. Linting does not currently fail the build as the backlog of issues is retired. See Ceedling’s development workflow documentation for the offense backlog recorded in `.rubocop_todo.yml`.
 
 ## :medal_sports: Certificate of Origin
 
-*Developer's Certificate of Origin 1.1*
+*Developer’s Certificate of Origin 1.1*
 
 By making a contribution to this project, I certify that:
 
@@ -218,7 +234,7 @@ By making a contribution to this project, I certify that:
 > 1. The contribution was provided directly to me by some other person who certified (1), (2) or (3) and I have not modified it.
 > 1. I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
 
-## [No Brown M&M's](https://en.wikipedia.org/wiki/Van_Halen#Contract_riders)
+## [No Brown M&M’s](https://en.wikipedia.org/wiki/Van_Halen#Contract_riders)
 
 If you are reading this, bravo dear user and (hopefully) contributor for making it this far! You are awesome. :100: 
 
@@ -226,7 +242,7 @@ To confirm that you have read this guide and are following it as best as possibl
 
 ## :pray: Credits
 
-Written by [@jessesquires](https://github.com/jessesquires). Lovingly adapted to ThrowTheSwitch.org by [@mvandervoord](https://github.com/mvandervoord).
+Oringally written by [@jessesquires](https://github.com/jessesquires). Lovingly adapted to ThrowTheSwitch.org by [Mark VanderVoord](https://github.com/mvandervoord) and [Michael Karlesky](https://gihub.com/mkarlesky)
 
 **Please feel free to adopt this guide in your own projects. Fork it wholesale or remix it for your needs.**
 

data/docs/CeedlingPullRequestChecklist.md

@@ -4,21 +4,22 @@ Hello lovely developers! We hear you're interested in submitting some work to ou
 
 Below is a quick checklist of the things that need to be done before a full PR is merged to our project. Don't worry. You're not responsible for ALL of it. We'll accept your contribution however you are able to make it, with our thanks. But if you have some extra time and would like to maximize your contribution, here's a handy reference!
 
+The same checklist appears in the description of every new pull request. It lives in `.github/pull_request_template.md`, and the two are kept in sync.
+
 ### Documentation
 
- - [ ] Has `README.md` been updated? (if it provides a huge feature or change... or maybe version bump)
- - [ ] Has `CeedlingPacket.md` been updated? (if it provides a new or changed feature)
- - [ ] Has `ReleaseNotes.md` been updated? (if it provides a new or changed feature)
- - [ ] Has `Changelog.md` been updated? (if it fixes something or provides something new)
- - [ ] Has `BreakingChanges.md` been updated? (if it changes compatibility with something that has existed before)
+ - [ ] Has the [documentation site](https://docs.throwtheswitch.org/Ceedling/) source in `docs/mkdocs/` been updated? (if it provides a new or changed feature)
+ - [ ] Does the pull request description explain what changed and why, well enough for maintainers to write the Changelog, Release Notes, and Breaking Changes entries? (maintainers write those entries)
+ - [ ] Does the description say so if it changes compatibility with something that has existed before?
 
- ### Software
+### Software
 
- - [ ] Does it follow our coding standards?
+ - [ ] Does it follow our [coding standard](ThrowTheSwitchCodingStandard.md)?
  - [ ] Are all existing tests passing?
  - [ ] Are there new tests added and passing?
- - [ ] Have new config options been added as defaults to the `project.yml` file?
- - [ ] Should new config options be added to example projects' `project.yml` files?
+ - [ ] Do new configuration options have defaults in `lib/ceedling/defaults.rb` and entries in the configuration reference (`docs/mkdocs/configuration/reference/`)?
+ - [ ] Should new configuration options be added to the starter project file (`assets/features/project.yml`) or the example projects' `project.yml` files?
  - [ ] Does the feature follow our "Logical Defaults" philosophy where possible?
  - [ ] Has it passed a peer review?
+ - [ ] Could this change make a failing test appear to pass, keep a test from running, or misreport results or coverage? If so, explain in the description.
  - [ ] Does it pass CI (continuous integration) tests?