Add mention of FREIPI into SST (nascentxyz#13)

* cei -> freipi

* freipi in dev process

audit-readiness-checklist.md

@@ -14,14 +14,14 @@
 - [ ] Avoid using assembly as much as possible. Use of assembly increases audit times because it throws away Solidity's guardrails and must be checked much more carefully.
 - [ ] Document use of `unchecked`. Concretely describe *why* it is safe to not perform arithmetic checks on each code block. Preferably for each operation.
 - [ ] Any `public` function that can be made `external` should be made `external`. This is not just a gas consideration, but it also reduces the cognitive overhead for auditors because it reduces the number of possible contexts in which the function can be called.
-- [ ] Use the [Checks-Effects-Interactions pattern](https://docs.soliditylang.org/en/v0.8.13/security-considerations.html#use-the-checks-effects-interactions-pattern) everywhere possible. Otherwise use reentrancy guards. Treat all token and ETH transfers as 'interactions'.
+- [ ] Use the [Function Requirements-Effects-Interactions-Protocol Invariants (FREI-PI) pattern](https://www.nascent.xyz/idea/youre-writing-require-statements-wrong) everywhere possible. Treat all token and ETH transfers as 'interactions'. Verify your system-level protocol invariants still hold at the end of each interaction.
 - [ ] Have at least one trusted Solidity dev or security person outside your organization sanity check your contracts. If your code is a tire fire and in need of major changes, you want to hear about that early and from a trusted friend (for free) rather than after an expensive audit.
 
 
 ### Nice to haves
 
 - [ ] Use formal verification tools to verify the invariants, but be aware that -- in practice -- current formal verification tools aren't a silver bullet and have some edge cases that aren't handled. [Certora](https://www.certora.com/) and [Runtime Verification](https://runtimeverification.com/) are examples of commonly used (paid) tools in this category.
-- [ ] Write down your security assumptions. This doesn't have to be super formal. E.g., "We assume that the `owner` is not malicious, that the Chainlink oracles won't lie about the token price, that the Chainlink oracles will always report the price at least once every 24 hours, that all tokens that the `owner` approves are ERC20-compliant tokens with no transfer hooks, and that there will never be a chain reorg of more than 30 blocks." This helps you understand how things could possibly go wrong *even if your contracts are bug-free*. Good auditors will be able to help you understand you whether your assumptions are realistic. They may also be able point out assumptions you're making that you didn't realize you were making.
+- [ ] Write down your extraneous security assumptions. This doesn't have to be super formal. E.g., "We assume that the `owner` is not malicious, that the Chainlink oracles won't lie about the token price, that the Chainlink oracles will always report the price at least once every 24 hours, that all tokens that the `owner` approves are ERC20-compliant tokens with no transfer hooks, and that there will never be a chain reorg of more than 30 blocks." This helps you understand how things could possibly go wrong *even if your contracts are bug-free*. Good auditors will be able to help you understand you whether your assumptions are realistic. They may also be able point out assumptions you're making that you didn't realize you were making.
 - [ ] If you're unsure about something in your own code, or there are areas where you'd like auditors to spend more time, make a list of these to share with the auditors.
 - [ ] Add scoping details for auditors. The form used in preparation for [Code4rena](https://code4rena.com/) is provided as an example in the collapsible section below.
 <details> <summary>Audit Scoping Details</summary>

development-process.md

@@ -35,6 +35,7 @@ You may have millions of dollars at risk already, or will after launch. As such,
  - Include the feature request + specification
 2. Write an initial implementation
  - Get an initial implementation in place
+ - Follow the [Function Requirements-Effects-Interactions-Protocol Invariants (FREI-PI) pattern](https://www.nascent.xyz/idea/youre-writing-require-statements-wrong) for any functions that are entrypoints for users.
  - Document all functions' intended behavior ([NatSpec](https://docs.soliditylang.org/en/develop/natspec-format.html) for public/external functions) and add inline documentation/comments
  - Any use of `unchecked` should include `safety` documentation like:
  ```solidity