Add security entry to Extension Intentions

Extension Intentions.md

@@ -14,5 +14,6 @@ These are some common intentions, each used in several projects. Each also lists
 | `C` | Content | Changes user-visible content, such as website copy. | Use `F`. |
 | `p` | Process | Changes some team process or working agreement. | Any of: <ul><li>Use a tacit, informal process.</li><li>Use `d`.</li><li>Keep your process definition outside of source control.</li></ul> |
 | `s` | Spec | Changes the spec or design. Used when team does formal specs or design reviews and keeps all such documents in the main product source, perhaps in the product code itself. | Any of: <ul><li>Use informal specs.</li><li>Use `d`.</li><li>Use your test suite as your only spec and use `t`.</li><li>Keep your spec / design outside of source control.</li></ul> |
+| `s` | Security | "expected same behavior with potential side effects" for example if you import a 3rd party library and mock the usages of that library, you do not really know if the security update was breaking or not. If there is a bug in the 3rd party dependency, then you might look at a safe package version update with suspicion. That is distinctly different from f where you updated some code and are expecting the outcome to be fully tested. To me the meaning of "low risk" is different when looking at "s" or "f". |
 | `n` | NOP | A commit with no changes (`--allow-empty`) | Use `r`. |
 | `@` | Unknown / multiple | Made a bunch of changes and are just getting it checked in. No real way to validate safety, and may not even compile. Usually used at the highest risk level (`@ @`). | Don't allow this. Require each commit to do exactly one intention and document itself accordingly. |