Changes to docs maintaing headers for all words.

CHANGELOG.md

@@ -280,7 +280,7 @@ snforge_std = { git = "https://github.com/foundry-rs/starknet-foundry", tag = "v
 
 ## [0.1.1] - 2023-07-26
 
-### Forge & cast
+### Forge & Cast
 
 #### Fixed
 
@@ -289,7 +289,7 @@ snforge_std = { git = "https://github.com/foundry-rs/starknet-foundry", tag = "v
 
 ## [0.1.0] - 2023-07-19
 
-### Forge & cast
+### Forge & Cast
 
 #### Added
 

CONTRIBUTING.md

@@ -1,4 +1,4 @@
-# Contribution guideline
+# Contribution Guideline
 
 Starknet Foundry is under active development and is open for contributions!
 Want to get started?
@@ -8,12 +8,12 @@ Need some guidance?
 Reach out to other developers on [Telegram](https://t.me/+d8ULaPxeRqlhMDNk) or open
 a [GitHub discussion](https://github.com/foundry-rs/starknet-foundry/discussions)!
 
-### Environment setup
+### Environment Setup
 
 See [development guide](https://foundry-rs.github.io/starknet-foundry/development/environment-setup.html) in Starknet
 Foundry book for environment setup.
 
-### Running tests and checks
+### Running Tests and Checks
 
 To run tests scripts, you have to install:
 
@@ -67,17 +67,17 @@ to add hasn't been already discussed.
 We also appreciate creating a feature request before making a contribution, so it can be discussed before you get to
 work.
 
-### Writing tests
+### Writing Tests
 
 Please make sure the feature you are implementing is thoroughly tested with automatic tests.
 You can check existing tests in the repository to see the recommended approach to testing.
 
-### Breaking changes
+### Breaking Changes
 
 If the change you are introducing is changing or breaking the behavior of any already existing features, make sure to
 include that information in the pull request description.
 
-### Pull request size
+### Pull Request Size
 
 Try to make your pull request self-contained, only introducing the necessary changes.
 If your feature is complicated,

README.md

@@ -77,7 +77,7 @@ Forge achieves performance comparable to the Cairo Test Runner with improved use
 
 To learn more about our benchmark methodology check [here](./benchmarks/).
 
-## Getting help
+## Getting Help
 
 You haven't found your answer to your question in
 the [Starknet Foundry Book](https://foundry-rs.github.io/starknet-foundry/)?

RELEASING.md

@@ -1,11 +1,11 @@
-# Instruction for creating new Starknet Forge releases
+# Instruction for Creating New Starknet Forge Releases
 
 1. Create a new branch.
 2. Run `./scripts/release.sh MAJOR.MINOR.PATCH`.
 3. Merge introduced changes to master branch.
 4. Wait for release workflows to pass. A new release will be created on GitHub.
 
-## Manually creating a release
+## Manually Creating a Release
 
 In case a manual creation of release is necessary, for example when
 cherry-picking changes, a release can also be triggered by creating a tag

design_documents/accessing_emitted_events.md

@@ -1,4 +1,4 @@
-# Accessing emitted events
+# Accessing Emitted Events
 
 <!-- TOC -->
 * [Accessing emitted events](#accessing-emitted-events)
@@ -20,7 +20,7 @@ Some contract functions can emit events. It is important to test if they were em
 
 Propose a solution that will allow checking if events were emitted.
 
-## Considered solutions
+## Considered Solutions
 
 1. `expect_events` cheatcode 
 2. `spy_events` cheatcode
@@ -61,7 +61,7 @@ It will panic if:
 - not all defined events were emitted
 - some other events where emitted
 
-### Usage example
+### Usage Example
 
 ```cario
 #[starknet::interface]
@@ -157,7 +157,7 @@ It is designed to enable more simplified flow:
 - `fetch_events` will be called internally, so there will always be the newest events,
 - checked events will be removed from the `events` property.
 
-### Propositions to consider
+### Propositions to Consider
 
 - `TargetedSpy` - regular spy with the target parameter for creation, which would be an enumeration of:
   ```cairo
@@ -171,7 +171,7 @@ It is designed to enable more simplified flow:
   It would clarify the confusion when `name` field is hashed when it comes from `EventSpy`.
 
 
-### Usage example
+### Usage Example
 
 ```cario
 // Contract is the same as in the previous example

design_documents/cairo_deployment_scripts.md

@@ -1,6 +1,6 @@
-# Cairo deployment scripts
+# Cairo Deployment Scripts
 
-## Table of contents
+## Table of Contents
 
 * [Context](#context)
 * [Goal](#goal)
@@ -26,29 +26,29 @@ contracts.
 
 Propose a solution with an example syntax, that would allow to write deployment scripts in cairo.
 
-## Considered solution
+## Considered Solution
 
 This section is split into smaller subsections describing things we will need to tackle while implementing the solution.
 
-### sncast commands
+### sncast Commands
 Specific sncast commands (declare, deploy, account) could be imported as regular functions to the scipts, and called as such.
 Our functions return specific types (structs defined in `cast/src/helpers/response_structs.rs`), that make retrieving
 essential information easier, so we should be good on that front.
 
 The commands would have to be implemented in the same manner as forge's cheatcodes.
 
-### sncast config
+### sncast Config
 We should allow for all flags passed to sncast to be propagated to the script. CastConfig should also be importable
 and usable from script if someone wishes so, but we should not require it. That means, we might have to review our subcommands
 and if some of them requires it directly (`account create` is one), we should try to get rid of this dependency. 
 
-### Interacting with contract
+### Interacting with Contract
 We will use contracts dispatchers to be able to call/invoke its functions directly 
 (e.g. if contract named `mycontract` has a function `myfunction`, we should be able to just do `mycontractDispatcher.myfunction();`).
 We should also support our subcommands (`invoke`, `call`) to call/invoke so dispatchers are able to use them, and for calling/invoking 
 contracts without dispatchers.
 
-### Running the script
+### Running the Script
 The script would essentially run an entrypoint function - `main`. Inside our script subcommand, we will have to compile 
 the cairo script file using a custom builder/extension, and then run it using some form of a custom runner - all similarly
 to how it is done in snforge.
@@ -79,7 +79,7 @@ that sets up the devnet to be used for dry running for users.
 The behaviour would be changed with `--broadcast` flag, that would actually execute needed transactions. We should also
 include a warning message about potential incurring cost.
 
-### Error handling
+### Error Handling
 If the transaction fails, we should put all the relevant info about it to the state file, output log information and stop
 script execution.
 If the script fails (for any reason that is not connected to transactions - eg rpc node down), we should output relevant
@@ -220,7 +220,7 @@ Picking those would ensure us that:
 
 
 
-### Example script
+### Example Script
 An example deployment script could look like this:
 
 ```cairo
@@ -259,7 +259,7 @@ fn main() {
 }
 ```
 
-### Example state file
+### Example State File
 The state file by default should be written to the current working directory, with a name `<script file name>.state.json`.
 Its schema could look like this:
 
@@ -325,7 +325,7 @@ the transaction receipt and checking its status etc)
 
 If it makes sense, some of the flags could be included in Scarb.toml config file.
 
-## Proposed steps/tasks
+## Proposed Steps/Tasks
 
 MVP:
   - allow for writing scripts using dispatchers and imported cast subcommand functions:

design_documents/contract_verification.md

@@ -1,4 +1,4 @@
-# Cairo contract verification via block explorers
+# Cairo Contract Verification Via Block Explorers
 
 ## Context
 
@@ -8,7 +8,7 @@ Cairo smart contracts deployed to Starknet are only visible as a Cairo Bytecode
 
 This proposal includes an extension to `sncast` utility enabling a contract owner to perform contract verification against a selected Blockchain Explorer API. We propose to create a first, reference implementation for the Voyager APIs.
 
-## Proposed solution
+## Proposed Solution
 
 We propose to design a dedicated `verify` command for the `sncast` tool, and add a mechanism whereby this command can be implemented for various Blockchain Explorers. We define a "generic" contract verification interface and propose to implement the interface by "adapters" specific to respective explorers. 
 
@@ -54,7 +54,7 @@ Options are:
  - mainnet - for verification at mainnet
  - goerli -  for verification on testnet
 
-### Contract verification interface
+### Contract Verification Interface
 
 To implement contract verification for a specific explorer, it is required to implement a generic interface (request/response), as described below. The data structures proposed can be eventually extended to cater for detailed requirements of subsequent explorer adapters.
 
@@ -73,7 +73,7 @@ To implement contract verification for a specific explorer, it is required to im
   - `ErrorMessage` - `String`
   - `ErrorDetail` - `String`
 
-### Voyager API adapter plugin
+### Voyager API Adapter Plugin
 
 A sample request in the Voyager API adapter implementation will look as follows: 
 ```rust

design_documents/loading_data_from_files.md

@@ -24,14 +24,14 @@ let file_data = read_array_from_file('file.txt').unwrap();
 assert(*array[0] == *file_data[0] && *array[1] == *file_data[1], 'arrays are not equal');
 ```
 
-## Proposed solution
+## Proposed Solution
 
 Create traits that are responsible for reading data from a file and loading it into Cairo memory
 as an array of felts, returning a Result if something goes wrong (file does not exist, short string is too long, etc.).
 Then the user can deserialize it themselves to the desired structure 
 as described in [Cairo Book](https://book.cairo-lang.org/appendix-03-derivable-traits.html#serializing-with-serde).
 
-### Supported type of files
+### Supported Type of Files
 
 For now, two types of files would be supported (in the future we can support also CSV, TOML, etc.):
 - plain text files with space-separated felts like this
@@ -52,7 +52,7 @@ For now, two types of files would be supported (in the future we can support als
 ```
 Note that short strings have to be in double quotes here due to JSON grammar definition.
 
-### User interface
+### User Interface
 ```
 // struct to store path of the file
 struct File {

design_documents/prepare_cheatcode.md

@@ -33,7 +33,7 @@ the address in advance with the current cheatcodes.
 
 Propose a solution that will allow knowing the address of a contract before the deployment.
 
-## Considered solutions
+## Considered Solutions
 
 ### Require Calling the `prepare` Cheatcode Before Every Deployment
 
@@ -73,15 +73,15 @@ That will use the same method of calculating the contract address as `deploy` us
 This way the user will have an ability to know the address of the contract that will be deployed, and the current
 deployment flow will remain unchanged.
 
-#### Known problems with this solution
+#### Known Problems with this Solution
 
 For the address returned by `precalculate_address` to match the address from `deploy`, the user will have to
 call `precalculate_address` immediately before the deployment or at least before any other calls to `deploy` as the
 internal counter will then be incremented.
 
 This could be remedied by having separate counters for all `class_hashe`es, but it will still remain a limiting factor.
 
-#### Example usage
+#### Example Usage
 
 ```cairo
 mod HelloStarknet {
@@ -132,7 +132,7 @@ fn call_and_invoke() {
 }
 ```
 
-## Proposed solution
+## Proposed Solution
 
 Change the current deployment flow, so it can better facilitate precalculating of contract addresses.
 
@@ -167,11 +167,11 @@ Both `precalculate_address` and `deploy` should use the same way of calculating
 Introduce the same salt counter as [discussed here](#salt-counter).
 This will allow deterministic address calculation and deploying of multiple instances of the same contract.
 
-### Known problems with this solution
+### Known Problems with this Solution
 
 Same problems as [indicated here](#known-problems-with-this-solution) apply to Proposed Solution 2 as well.
 
-### Example usage
+### Example Usage
 
 ```cairo
 mod HelloStarknet {

design_documents/stark_curve_signatures.md

@@ -1,16 +1,16 @@
-# `StarkCurve` signatures
+# `StarkCurve` Signatures
 
 ## Context
 
 Some users would like to have a way of generating and signing with the `stark curve`. It would be useful for testing
 custom account implementations. 
 
-## Existing solutions
+## Existing Solutions
 
 Currently, it is possible only with the snForge I/O utilities which does not seem flexible. Also, to import such a signature
 users have to generate it outside the Cairo and save it somewhere. Cheatcodes should simplify that process.
 
-## Proposed solution
+## Proposed Solution
 
 My proposal would be to introduce a `StarkCurveKeyPair` struct which would implement `sign` and `verify` methods.
 
@@ -27,7 +27,7 @@ trait StarkCurveKeyPairTrait {
 }
 ```
 
-## Example usage
+## Example Usage
 
 ```cairo
 use snforge_std::{StarkCurveKeyPair, StarkCurveKeyPairTrait};

design_documents/state_forking/multi-forking.md

@@ -10,7 +10,7 @@ Foundry provides a way of interacting with multiple networks inside a single tes
 
 Above features will require us to change currently implemented `CheatnetState`.
 
-## New CheatnetState interface
+## New CheatnetState Interface
 
 ![New CheatnetState interface](./new_CheatnetState_interface.png)
 
@@ -29,7 +29,7 @@ It appears that since our tests are contracts we can abandon `CachedState` and `
 We would have to verify this idea, but if it is double we could create some class that implements `State` trait from blockifier
 and keep it as a `blockifier_state`.
 
-## Interacting with multiple forks (Cheatnet side)
+## Interacting with Multiple Forks (Cheatnet Side)
 
 Let's split common fork interaction into parts:
 
@@ -53,7 +53,7 @@ by simply implementing `StateReader` for the `StateCache`. It would search for a
 - check if contract is available in the forked network (perform call to node) - if so return it
 - throw an error
 
-## Required actions
+## Required Actions
 
 - verify if it is possible to get rid of methods using `CachedState`
 - create `StarknetState` (name can be changed) struct which will implement `State` trait