feat: add guidelines and .github

.github/pull_request_template.md

@@ -0,0 +1,28 @@
+## Description
+<!-- Please include a summary of the change and which issue is fixed. Also, list any dependencies that are required for this change. -->
+
+<!-- Fixes # (issue) -->
+
+## Type of change
+
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+- [ ] This change requires a documentation update
+
+## How Has This Been Tested?
+<!-- Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration -->
+
+- [ ] Test A
+- [ ] Test B
+
+## Checklist:
+
+- [ ] My code follows the style guidelines of this project
+- [ ] I have performed a self-review of my own code
+- [ ] I have commented my code, particularly in hard-to-understand areas
+- [ ] I have made corresponding changes to the documentation
+- [ ] My changes generate no new warnings
+- [ ] I have added tests that prove my fix is effective or that my feature works
+- [ ] New and existing unit tests pass locally with my changes
+- [ ] Any dependent changes have been merged and published in downstream modules

.github/workflows/build.yml

@@ -0,0 +1,18 @@
+name: Build Project
+
+on: [push, pull_request]
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - name: Set up Node.js
+        uses: actions/setup-node@v2
+        with:
+          node-version: "22"
+          cache: "yarn"
+      - name: Install dependencies
+        run: yarn install
+      - name: Build
+        run: yarn build

.github/workflows/formatting.yml

@@ -0,0 +1,18 @@
+name: Code Formatting Check
+
+on: [push, pull_request]
+
+jobs:
+  formatting:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - name: Set up Node.js
+        uses: actions/setup-node@v2
+        with:
+          node-version: "22"
+          cache: "yarn"
+      - name: Install Prettier
+        run: yarn add --dev prettier
+      - name: Check code formatting
+        run: yarn prettier --check .

.github/workflows/linting.yml

@@ -0,0 +1,18 @@
+name: Lint Code Base
+
+on: [push, pull_request]
+
+jobs:
+  eslint:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - name: Set up Node.js
+        uses: actions/setup-node@v2
+        with:
+          node-version: "22"
+          cache: "yarn"
+      - name: Install dependencies
+        run: yarn install --frozen-lockfile
+      - name: Run ESLint
+        run: yarn eslint .

CODING_GUIDELINES.md

@@ -0,0 +1,106 @@
+# Coding Guidelines for Email Recovery Demo
+
+This document outlines the coding guidelines for contributing to the **Email Recovery Demo**. Following these guidelines will help maintain a consistent and high-quality codebase.
+
+## 1. Code Formatting
+
+- **Tool**: Use **Prettier** to automatically format your code. Ensure that all code is formatted before committing.
+  - Run `npx prettier --write .` to format the entire codebase.
+- **Indentation**: Use 2 spaces per indentation level. Do not use tabs.
+- **Line Length**: Aim to keep lines under 100 characters. Longer lines should be broken up for readability.
+- **Function Length**: Aim to keep functions short and focused. If a function is too long, consider breaking it up into smaller functions.
+- **Imports**: Organize imports into the following sections:
+  1. External dependencies (e.g., libraries from `node_modules`).
+  2. Absolute imports (e.g., `import { func } from 'src/utils';`).
+  3. Relative imports (e.g., `import { func } from '../utils';`).
+
+  Example:
+  ```ts
+  import fs from 'fs';
+  import { validateEmail } from 'src/utils';
+  import { parseInput } from '../parsers';
+  ```
+- **Braces**: Use braces for all control structures, even single-line blocks.
+
+  Example:
+  ```ts
+  if (condition) {
+    doSomething();
+  }
+  ```
+
+- **Semicolons**: Always use semicolons to terminate statements.
+- **Whitespace**: Use a single space after commas and colons, but no space before them.
+
+  Example:
+  ```ts
+  const arr = [1, 2, 3];
+  const obj = { name: 'Alice', age: 30 };
+  ```
+
+## 2. Code Linting
+
+- **Tool**: Use **ESLint** to enforce code quality. Run `npx eslint .` before committing your code.
+- **Handling Lints**: Address all warnings and errors reported by ESLint. Avoid ignoring lint rules unless necessary, and if you do, provide a comment explaining why.
+
+## 3. Naming Conventions
+
+- **Variables and Functions**: Use `camelCase` for variable and function names.
+
+  Example: 
+  ```ts
+  const userName = 'Alice';
+  ```
+- **Classes and Interfaces**: Use `PascalCase`.
+
+  Example: 
+  ```ts
+  class UserAccount { ... }
+  ```
+
+- **Constants**: Use `UPPER_CASE` for constant values.
+
+  Example: 
+  ```ts
+  const MAX_USERS = 100;
+  ```
+
+## 4. Documentation
+
+- **JSDoc**: Document all public functions, methods, and classes using JSDoc comments.
+
+  Example:
+  ```ts
+  /**
+   * Creates a new user account.
+   * @param {string} name - The name of the user.
+   * @returns {UserAccount} A new UserAccount object.
+   */
+  function createUserAccount(name: string): UserAccount {
+    // function body
+  }
+  ```
+
+- **Inline Comments**: Add comments in code where the intent or logic is not immediately clear.
+
+## 5. Error Handling
+
+- **Use of `try`/`catch`**: Use `try`/`catch` blocks for error-prone code. Always handle errors gracefully.
+
+  Example:
+  ```ts
+  try {
+    const data = await fetchData();
+  } catch (error) {
+    console.error('Error fetching data', error);
+  }
+  ```
+
+- **Custom Errors**: When appropriate, define custom error types by extending the `Error` class.
+
+## 6. Testing
+
+- **Tool**: Use **Jest** for writing unit and integration tests. Ensure that all new functionality has corresponding tests.
+  - Run `npm test` to execute the test suite.
+- **Test Structure**: Organize tests in a `__tests__` directory or in files with the `.test.ts` or `.spec.ts` suffix.
+- **Coverage**: Aim for at least 80% code coverage. Run `npm test -- --coverage` to check coverage metrics.

CONTRIBUTING.md

@@ -0,0 +1,116 @@
+# Contributing to Email Recovery Demo
+
+Thank you for considering contributing to our project! We welcome contributions of all kinds, including code, documentation, bug reports, feature requests, and more. This document outlines the process for contributing to this project.
+
+## Table of Contents
+- [Contributing to Email Recovery Demo](#contributing-to-email-recovery-demo)
+  - [Table of Contents](#table-of-contents)
+  - [1. Code of Conduct](#1-code-of-conduct)
+  - [2. Getting Started](#2-getting-started)
+  - [3. Coding Guidelines](#3-coding-guidelines)
+  - [4. Testing](#4-testing)
+  - [5. Commit Messages](#5-commit-messages)
+  - [6. Pull Request Process](#6-pull-request-process)
+  - [7. Contact](#7-contact)
+
+## 1. Code of Conduct
+We are committed to providing a welcoming and inspiring community for all and expect our Code of Conduct to be honored. Anyone who violates this code of conduct may be banned from the community.
+
+Our community strives to:
+
+- **Be friendly and patient.**
+- **Be welcoming**: We strive to be a community that welcomes and supports people of all backgrounds and identities.
+- **Be considerate**: Your work will be used by other people, and you in turn will depend on the work of others.
+- **Be respectful**: Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners.
+- **Be careful in the words that you choose**: We are a community of professionals, and we conduct ourselves professionally.
+- **Be kind to others**: Do not insult or put down other participants. Harassment and other exclusionary behavior aren't acceptable.
+
+This includes, but is not limited to:
+
+- Violent threats or language directed against another person.
+- Discriminatory jokes and language.
+- Posting sexually explicit or violent material.
+- Posting (or threatening to post) other people's personally identifying information ("doxing").
+- Personal insults, especially those using racist or sexist terms.
+- Unwelcome sexual attention.
+- Advocating for, or encouraging, any of the above behavior.
+- Repeated harassment of others. In general, if someone asks you to stop, then stop.
+
+Moderation
+
+These are the policies for upholding our community’s standards of conduct. If you feel that a thread needs moderation, please contact the community team at [[email protected]](mailto:[email protected]).
+
+1. **Remarks that violate the Relayer Utils standards of conduct, including hateful, hurtful, oppressive, or exclusionary remarks, are not allowed.** (Cursing is allowed, but never targeting another user, and never in a hateful manner.)
+2. **Remarks that moderators find inappropriate, whether listed in the code of conduct or not, are also not allowed.**
+3. **Moderators will first respond to such remarks with a warning.**
+4. **If the warning is unheeded, the user will be “kicked,” i.e., temporarily banned from the community.**
+5. **If the user comes back and continues to make trouble, they will be banned permanently from the community.**
+6. **Moderators may choose at their discretion to un-ban the user if it was a first offense and they offer the offended party a genuine apology.**
+7. **If a moderator bans someone and you think it was unjustified, please take it up with that moderator, or with a different moderator, in a private discussion.**
+
+**Please try to emulate these behaviors, especially when debating the merits of different options.**
+
+Thank you for helping make this a welcoming, friendly community for all.
+
+This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 1.4, available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html)
+
+
+## 2. Getting Started
+To start contributing, follow these steps:
+
+1. Fork the repository.
+2. Clone your fork to your local machine:
+    ```bash
+    git clone https://github.com/zkemail/email-recovery-demo.git
+    ```
+3.	Create a new branch for your feature or bugfix:
+    ```bash
+    git checkout -b feat/your-feature-name
+    ```
+4.	Install the necessary dependencies:
+    ```bash
+    cargo build
+    ```
+5.	Make your changes.
+
+## 3. Coding Guidelines
+
+Please follow the coding guidelines in [CODING_GUIDELINES.md](CODING_GUIDELINES.md) when contributing to this project.
+
+## 4. Testing
+
+Please write tests for your contributions. We aim for high test coverage.
+
+	•	Unit Tests: Place unit tests in the same file as the code they are testing.
+	•	Integration Tests: Place integration tests in the tests/ directory.
+
+Run all tests before submitting your code with cargo test.
+
+Run all tests before submitting your code with cargo test.
+
+## 5. Commit Messages
+
+Use conventional commit messages for your commits. This helps us automatically generate the changelog and follow semantic versioning.
+
+    •	Format: `<type>: <description>`
+    •	Example: `feat: add new feature`
+
+For more information, see [Conventional Commits](https://www.conventionalcommits.org/).
+
+## 6. Pull Request Process
+
+	1.	Ensure your branch is up-to-date with the main branch:
+	•	git fetch origin
+	•	git checkout main
+	•	git merge origin/main
+	2.	Push your branch to your fork:
+	•	git push origin feature/your-feature-name
+	3.	Open a pull request from your branch to the main branch of the original repository.
+	4.	Ensure that your pull request passes all checks (e.g., CI tests).
+	5.	A reviewer will review your pull request. Be prepared to make adjustments based on feedback.
+
+## 7. Contact
+
+If you have any questions or need further assistance, feel free to open an issue or contact us at [[email protected]](mailto:[email protected]).
+
+Thank you for your contributions!