feat(cube): its spinning

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,77 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible 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.
+
+We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our community include:
+
+- Demonstrating empathy and kindness toward other people
+- Being respectful of differing opinions, viewpoints, and experiences
+- Giving and gracefully accepting constructive feedback
+- Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
+- Focusing on what is best not just for us as individuals, but for the overall community
+
+Examples of unacceptable behavior include:
+
+- The use of sexualized language or imagery, and sexual attention or advances of any kind
+- Trolling, insulting or derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or email address, without their explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
+
+Community leaders 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, and will communicate reasons for moderation decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at [trananhquan1009@gmail.com](mailto:trananhquan1009@gmail.com). All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.1, available at [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html](https://www.contributor-covenant.org/version/2/1/code_of_conduct.html).
+
+Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).
+
+[homepage]: https://www.contributor-covenant.org

.github/COMMIT_CONVENTION.md

@@ -0,0 +1,85 @@
+## Git Commit Message Convention
+
+> This is adapted from [Angular's commit convention](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular).
+
+### Examples
+
+Appears under "Features" header, pencil subheader:
+
+```
+feat(pencil): add 'graphiteWidth' option
+```
+
+Appears under "Bug Fixes" header, graphite subheader, with a link to issue #28:
+
+```
+fix(graphite): stop graphite breaking when width < 0.1
+
+Closes #28
+```
+
+Appears under "Performance Improvements" header, and under "Breaking Changes" with the breaking change explanation:
+
+```
+perf(pencil): remove graphiteWidth option
+
+BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reason.
+```
+
+The following commit and commit `667ecc1` do not appear in the changelog if they are under the same release. If not, the revert commit appears under the "Reverts" header.
+
+```
+revert: feat(pencil): add 'graphiteWidth' option
+
+This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
+```
+
+### Commit Message Format
+
+A commit message consists of a **header**, **body** and **footer**. The header has a **type**, **scope** and **subject**:
+
+```
+<type>(<scope>): <subject>
+<BLANK LINE>
+<body>
+<BLANK LINE>
+<footer>
+```
+
+The **header** is mandatory and the **scope** of the header is optional.
+
+### Revert
+
+If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
+
+### Type
+
+If the prefix is `feat`, `fix` or `perf`, it will appear in the changelog. However if there is any [BREAKING CHANGE](#footer), the commit will always appear in the changelog.
+
+Other prefixes are up to your discretion. Suggested prefixes are `build`, `ci`, `docs` ,`style`, `refactor`, and `test` for non-changelog related tasks.
+
+Details regarding these types can be found in the [Contributing Guidelines](./CONTRIBUTING.md#commit-message-format).
+
+### Scope
+
+The scope could be anything specifying the place of the commit change. For example `services`, `commands`, `cli` etc...
+
+### Subject
+
+The subject contains a succinct description of the change:
+
+- use the imperative, present tense: "change" not "changed" nor "changes"
+- don't capitalize the first letter
+- no dot (.) at the end
+
+### Body
+
+Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes".
+The body should include the motivation for the change and contrast this with previous behavior.
+
+### Footer
+
+The footer should contain any information about **Breaking Changes** and is also the place to
+reference GitHub issues that this commit **Closes**.
+
+**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this.

.github/CONTRIBUTING.md

@@ -0,0 +1,170 @@
+# Contributing to Hope:RE
+
+We would love for you to contribute to this project and help make it even better!
+As a contributor, here are the guidelines we would like you to follow:
+
+- [Code of Conduct](#code-of-conduct)
+- [Question or Problem?](#question-or-problem)
+- [Issues and Bugs](#found-a-bug)
+- [Feature Requests](#missing-a-feature)
+- [Submission Guidelines](#submission-guidelines)
+- [Coding Rules](#coding-rules)
+- [Commit Message Format](#commit-message-format)
+
+## Code of Conduct
+
+Help us keep this project open and inclusive.
+Please read and follow our [Code of Conduct](./CODE_OF_CONDUCT.md).
+
+## Question or Problem?
+
+Do not open issues for general support questions as we want to keep GitHub issues for bug reports and feature requests.
+Instead, we recommend reaching out directly via [email](mailto:trananhquan1009@gmail.com) for support-related questions.
+
+## Found a Bug?
+
+If you find a bug in the source code, you can help us by [submitting an issue](#submitting-an-issue) to our [GitHub Repository](https://github.com/HopeArtOrg/hope-re/issues).
+Even better, you can [submit a Pull Request](#submitting-a-pull-request-pr) with a fix.
+
+## Missing a Feature?
+
+You can _request_ a new feature by [submitting an issue](#submitting-an-issue) to our GitHub Repository.
+If you would like to _implement_ a new feature, please consider the size of the change:
+
+- For a **Major Feature**, first open an issue and outline your proposal so that it can be discussed.
+- **Small Features** can be crafted and [directly submitted as a Pull Request](#submitting-a-pull-request-pr).
+
+## Submission Guidelines
+
+### Submitting an Issue
+
+Before you submit an issue, please search the issue tracker. An issue for your problem may already exist and the discussion might provide you with workarounds.
+
+We want to fix all the issues as soon as possible, but before fixing a bug we need to reproduce and confirm it. In order to reproduce bugs, we require that you provide a minimal reproduction.
+
+You can file new issues by selecting from our [new issue templates](https://github.com/HopeArtOrg/hope-re/issues/new/choose) and filling out the template.
+
+### Submitting a Pull Request (PR)
+
+Before you submit your Pull Request (PR), consider the following guidelines:
+
+1. Search [GitHub PRs](https://github.com/HopeArtOrg/hope-re/pulls) for an open or closed PR that relates to your submission.
+2. Make sure there is an issue describing the problem you are fixing, or documenting the design for the feature you would like to add.
+3. [Fork](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo) the repository.
+4. In your forked repository, make your changes in a new git branch:
+
+   ```sh
+   git checkout -b my-fix-branch main
+   ```
+
+5. Create your patch.
+6. Follow our [Coding Rules](#coding-rules).
+7. Make sure to test your changes.
+8. Run `pnpm lint` to ensure your code passes linting.
+9. Commit your changes using a descriptive commit message that follows our [commit message conventions](#commit-message-format).
+   ```sh
+   git commit --all
+   ```
+10. Push your branch to GitHub:
+    ```sh
+    git push origin my-fix-branch
+    ```
+11. On GitHub, send a pull request to the `main` branch.
+
+#### Reviewing a Pull Request
+
+The maintainers reserve the right to not accept pull requests from community members who have not shown good conduct. Such behavior includes not following the [Code of Conduct](./CODE_OF_CONDUCT.md).
+
+##### Addressing review feedback
+
+If we ask for changes via code reviews, then:
+
+1. Make the required updates to the code.
+2. Create a fixup commit and push to your GitHub repository:
+   ```sh
+   git commit --all --fixup HEAD
+   git push
+   ```
+
+##### Updating the commit message
+
+A reviewer might suggest changes to a commit message. To update the message of the last commit on your branch:
+
+1. Check out your branch:
+   ```sh
+   git checkout my-fix-branch
+   ```
+2. Amend the last commit and modify the commit message:
+   ```sh
+   git commit --amend
+   ```
+3. Push to your GitHub repository:
+   ```sh
+   git push --force-with-lease
+   ```
+
+#### After your pull request is merged
+
+After your pull request is merged, you can safely delete your branch and pull the changes from the main repository:
+
+- Delete the remote branch on GitHub via the GitHub web UI or your local shell:
+  ```sh
+  git push origin --delete my-fix-branch
+  ```
+- Check out the main branch:
+  ```sh
+  git checkout main -f
+  ```
+- Delete the local branch:
+  ```sh
+  git branch -D my-fix-branch
+  ```
+- Update your main branch with the latest upstream version:
+  ```sh
+  git pull --ff upstream main
+  ```
+
+## Coding Rules
+
+To ensure consistency throughout the source code, keep these rules in mind as you are working:
+
+- All features or bug fixes **must be tested**.
+- Run `pnpm lint` before committing to ensure code passes ESLint checks.
+- Follow Angular-style [commit message conventions](#commit-message-format).
+- Use `type` keyword for TypeScript type definitions, never `interface`.
+- Use `import type` for type-only imports.
+- Use Svelte 5 runes (`$props()`, `$state()`, `$derived()`, `$effect()`) -- no legacy Svelte syntax.
+- No `<style>` blocks in Svelte components -- use Tailwind CSS utility classes only.
+- File names must be kebab-case (except Rust files which use snake_case).
+
+## Commit Message Format
+
+We have very precise rules over how our Git commit messages are formatted. This format leads to **easier to read commit history**.
+
+Each commit message consists of a **header**, a **body**, and a **footer**.
+
+```
+<header>
+<BLANK LINE>
+<body>
+<BLANK LINE>
+<footer>
+```
+
+The `header` is mandatory and must conform to the format:
+
+```
+<type>(<scope>): <short summary>
+```
+
+- **type**: build | ci | docs | feat | fix | perf | refactor | test
+- **scope**: the place of the commit change (e.g. `protection`, `commands`, `ui`, or empty)
+- **summary**: imperative present tense, no capitalized first letter, no period at the end
+
+The `body` is optional. When present, it should explain the motivation for the change and contrast this with previous behavior.
+
+The `footer` is optional. It can contain information about breaking changes, deprecations, or references to issues and PRs.
+
+### Revert commits
+
+If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit.