docs: add documentation

.gitignore

@@ -12,9 +12,6 @@ deployments
 broadcast
 !/broadcast/*/1/
 
-# Docs
-docs/
-
 # Dotenv file
 .env
 

CODE_OF_CONDUCT.md

@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to make participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies within all project spaces, and it also applies when
+an individual is representing the project or its community in public spaces.
+Examples of representing a project or community include using an official
+project e-mail address, posting via an official social media account, or acting
+as an appointed representative at an online or offline event. Representation of
+a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at <[email protected]>. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at <https://www.contributor-covenant.org/version/1/4/code-of-conduct.html>
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+<https://www.contributor-covenant.org/faq>

CONTRIBUTING.md

@@ -0,0 +1,201 @@
+# Contributing
+
+## Code of Conduct
+Please make sure to read and observe our [Code of Conduct](/CODE_OF_CONDUCT.md).
+
+## Bug Reports
+
+* Ensure your issue [has not already been reported][1]. It may already be fixed!
+* Include the steps you carried out to produce the problem.
+* Include the behavior you observed along with the behavior you expected, and
+  why you expected it.
+* Include any relevant traces or debugging output.
+
+## Feature Requests
+
+We welcome feedback with or without pull requests. If you have an idea for how
+to improve the project, great! All we ask is that you take the time to write a
+clear and concise explanation of what need you are trying to solve. If you have
+thoughts on _how_ it can be solved, include those too!
+
+The best way to see a feature added, however, is to submit a pull request.
+
+## Pull requests
+
+Pull requests are squash-merged to keep the `main` branch history clean. The title of the pull request becomes the commit message, so it should be written in a consistent format:
+
+1) Begin with a capital letter.
+2) Do not end with a period.
+3) Write in the imperative: "Add feature X" and not "Adds feature X" or "Added feature X".
+
+We welcome conventional commits, with prefixes the title with "fix:" or "feat:".
+
+Work in progress pull requests should be submitted as Drafts and should **not** be prefixed with "WIP:".
+
+Branch names don't matter, and commit messages within a pull request mostly don't matter either, although they can help the review process.
+
+## Find something to work on
+
+We are always in need of help, be it fixing documentation, reporting bugs or writing some code.
+Look at places where you feel best coding practices aren't followed, code refactoring is needed or tests are missing.
+
+If you have questions about the development process,
+feel free to [file an issue](https://github.com/storyprotocol/protocol-periphery-v1/issues/new).
+
+## Engineering Guidelines
+
+### Testing
+
+Code must be thoroughly tested with quality unit tests.
+
+We defer to the [Foundry Best Practices](https://book.getfoundry.sh/tutorials/best-practices) and [Moloch Testing Guide](https://github.com/MolochVentures/moloch/tree/master/test#readme) for specific recommendations, though not all of it is relevant here. Note the introduction in Moloch Testing Guide:
+
+> Tests should be written, not only to verify correctness of the target code, but to be comprehensively reviewed by other programmers. Therefore, for mission critical Solidity code, the quality of the tests are just as important (if not more so) than the code itself, and should be written with the highest standards of clarity and elegance.
+
+Every addition or change to the code must come with relevant and comprehensive tests.
+
+Flaky tests are not acceptable.
+
+The test suite should run automatically for every change in the repository, and in pull requests tests must pass before merging.
+
+The test suite coverage must be kept as close to 100% as possible, enforced in pull requests.
+
+Test should use Foundry, unless for some reason js or hardhat are needed (for example, upgrades).
+
+The test function names will follow
+
+```
+- test_contextCamel_descriptionOfTheTestCamel
+- context = method name, contract or functionality.
+```
+
+In some cases unit tests may be insufficient and complementary techniques should be used:
+
+1. Property-based tests (aka. fuzzing) for math-heavy code.
+2. hardhat test using `hardhat-upgrades` OZ plugin to verify storage and upgradeability (until they support Foundry).
+3. Fork tests for upgreadeability to new implementations for upgradeable contracts, testing against the deployed contracts.
+4. E2E tests for critical (happy) paths.
+5. Formal verification for state machines.
+
+### Documentation
+
+For contributors, project guidelines and processes must be documented publicly.
+
+Every method and contract must have Natspec, using the `///` flavour always.
+
+For users, features must be abundantly documented. Documentation should include answers to common questions, solutions to common problems, and recommendations for critical decisions that the user may face.
+
+All changes to the core codebase (excluding tests, auxiliary scripts, etc.) must be documented in a changelog, except for purely cosmetic or documentation changes.
+
+### Peer review
+
+All changes must be submitted through pull requests and go through peer code review.
+
+The review must be approached by the reviewer in a similar way as if it was an audit of the code in question (but importantly it is not a substitute for and should not be considered an audit).
+
+Reviewers should enforce code and project guidelines.
+
+External contributions must be reviewed separately by multiple maintainers.
+
+### Automation
+
+Automation should be used as much as possible to reduce the possibility of human error and forgetfulness.
+
+Automations that make use of sensitive credentials must use secure secret management, and must be strengthened against attacks such as [those on GitHub Actions worklows](https://github.com/nikitastupin/pwnhub).
+
+Some other examples of automation are:
+
+- Looking for common security vulnerabilities or errors in our code (eg. reentrancy analysis).
+- Keeping dependencies up to date and monitoring for vulnerable dependencies.
+
+### Code style
+
+Solidity code should be written in a consistent format enforced by a linter, following the official [Solidity Style Guide](https://docs.soliditylang.org/en/latest/style-guide.html). See below for further [Solidity Conventions](#solidity-conventions).
+
+The code should be simple and straightforward, prioritizing readability and understandability. Consistency and predictability should be maintained across the codebase. In particular, this applies to naming, which should be systematic, clear, and concise.
+
+Sometimes these guidelines may be broken if doing so brings significant efficiency gains, but explanatory comments should be added.
+
+Modularity should be pursued, but not at the cost of the above priorities.
+
+### Solidity Conventions
+
+In addition to the official Solidity Style Guide we have a number of other conventions that must be followed.
+
+- Minimize exposing state variables, unless they help with external systems integration or readability.
+
+- Changes to state should be accompanied by events, and in some cases it is not correct to arbitrarily set state.
+
+- Internal or private state variables or functions should have an underscore prefix.
+
+  ```solidity
+  contract TestContract {
+      uint256 private _privateVar;
+      uint256 internal _internalVar;
+      function _testInternal() internal { ... }
+      function _testPrivate() private { ... }
+  }
+  ```
+
+* constant or immutable variables must be ALL_CAPS with underscores._ALL_CAPS if private or internal.
+
+- Events should be emitted immediately after the state change that they
+  represent, and should be named in the past tense.
+
+  ```solidity
+  function _burn(address who, uint256 value) internal {
+      super._burn(who, value);
+      emit TokensBurned(who, value);
+  }
+  ```
+
+  Some standards (e.g. ERC20) use present tense, and in those cases the
+  standard specification is used.
+
+- Interface names should have a capital I prefix.
+
+  ```solidity
+  interface IERC777 {
+  ```
+
+- Group contracts by functionality within folders if possible.
+
+- Interfaces should go inside the `interface` folder, mirroring the folder structure of the implementations
+
+- Folder names must be lowercase, hyphen separated.
+
+  ```
+  example-folder
+  ```
+
+- Contract names must be camel case, starting with uppercase letter
+
+  ```
+  ExampleContract.sol
+  ```
+
+- Acronyms should be
+  - Uppercase all if in contract name (`UUPSUpgradeable`, `IPAsset`)
+  - Camelcase in properties and function names (`ipAssetId`), except if they are defined otherwise in external contracts or interfaces (`tokenURI`)
+
+- Unchecked arithmetic blocks should contain comments explaining why overflow is guaranteed not to happen. If the reason is immediately apparent from the line above the unchecked block, the comment may be omitted.
+
+- Interfaces should contain methods an events. Structs showing in an interface should be grouped in a library
+
+- Function parameter names will have the **suffix** `_`
+
+- Naming conventions
+
+- Contract: CamelCase (adjectiveNoun)
+- Struct (noun)
+- Event (past-tense)
+- Function Name (verb noun)
+  - local variable (noun / compound noun)
+    - Booleans (use `isXXX`)
+    - `isValid`
+    - `valid`
+  - Modifier (prepositionNoun)
+    - `onlyOwner`
+
+
+[1]: https://github.com/storyprotocol/protocol-periphery-v1/issues