feat: add coding practices, core values, cultural principles

docs/concepts/11-coding-practices.md

@@ -0,0 +1,53 @@
+---
+id: "coding-practices"
+sidebar_position: 11
+title: "Coding Practices"
+---
+
+# Coding Practices
+
+We adhere to the following best practices to the extent possible.
+
+## Solidity Smart Contracts
+
+### Development and Deployment
+
+- All contracts are built, tested, and deployed with [Foundry](https://github.com/foundry-rs/foundry).
+- We follow the best practices mentioned in the [Foundry Book](https://book.getfoundry.sh/tutorials/best-practices).
+
+### Naming Conventions
+
+The following naming conventions are used throughout the codebase:
+
+- **Contracts, Interfaces, and Libraries**: `PascalCase`
+- **Public functions and variables**: `camelCase`
+- **Constants**: `SCREAMING_SNAKE_CASE`
+- **Internal and Private Functions and Variables**: `_camelCase`
+- **Function Parameters**: Have a trailing `_` to avoid shadowing state variables
+- **Errors**: Follow the convention `<ContractName>_<ErrorName>`
+- **Test Functions**: Follow the convention `test(Fork)?(Fuzz)?_(RevertWhen_){1})?\w{1,}`
+  - A comprehensive list of valid and invalid examples can be found
+    [here](https://github.com/ScopeLift/scopelint/blob/1857e3940bfe92ac5a136827374f4b27ff083971/src/check/validators/test_names.rs#L106-L143)
+- **Directories**: `kebab-case`
+- **Test and Script Files**: `PascalCase`
+  - If test contracts represent function names, then they are in `camelCase`
+
+### Security Patterns
+
+- We use the [CEI](https://fravoll.github.io/solidity-patterns/checks_effects_interactions.html) and
+  [FREI-PI](https://www.nascent.xyz/idea/youre-writing-require-statements-wrong) patterns for smart contract security.
+
+### Testing
+
+- Concrete tests are written using [Bulloak](https://bulloak.dev), adhering to the
+  [Branching Tree Technique](https://x.com/PaulRBerg/status/1682346315806539776).
+- Tests are generated using the `bulloak scaffold` command.
+
+### Styling and Documentation
+
+- All contracts are linted with [Solhint](https://github.com/protofire/solhint).
+- Every contract, interface, library, function, and variable is documented with comprehensive
+  [NatSpec comments](https://docs.soliditylang.org/en/latest/natspec-format.html).
+- All codes are annotated with comments that explain what that bit of code does.
+  - Some annotations might come across as verbose, but explicitness is important in financial software like smart
+    contracts.

docs/concepts/12-values.md

@@ -0,0 +1,27 @@
+---
+id: "values"
+sidebar_position: 12
+title: "Our Values"
+---
+
+By sharing our core values and cultural principles publicly, we aim to help you understand the ethos that drives our
+work.
+
+## Core Values
+
+- Something related to security of system but it derives from the trust that team has in each other. If nNo trust, even
+  a permissionless can be compromised, for example, during deployment.
+- Listen to user. Derive features from users feedback.
+- On a mission to increase internet GDP. That means growing the pie as well.
+- A team works best when they behave like a family.
+- Focus on identifying and solving problems and not tasks.
+- Not afraid of taking responsibility individually if something goes wrong. We like to say "I will do it".
+
+## Cultural Principles
+
+- We don’t watch what we say. We are fully open about what we think, always.
+- We don’t believe in hierarchies.
+- We value creative solutions.
+- We view ourselves as infinitely fallible and acknowledge that anyone can make big mistakes regardless of experience.
+- We believe that progress is made through criticism and never hesitate to poke holes in each other’s ideas.
+- We open-source our work and share our knowledge on public Internet forums.

docs/concepts/11-glossary.md → docs/concepts/13-glossary.md

@@ -1,6 +1,6 @@
 ---
 id: "glossary"
-sidebar_position: 11
+sidebar_position: 13
 title: "Glossary"
 ---