|
| 1 | +# Development & Contribution |
| 2 | + |
| 3 | +The **Gemini CLI Opinionated Framework** enforces a high-discipline development lifecycle. Whether you are a human or an AI contributor, adherence to these standards is mandatory. |
| 4 | + |
| 5 | +## 🔄 The Mandatory Workflow Lifecycle |
| 6 | + |
| 7 | +Every non-trivial change must follow this strict three-phase process: |
| 8 | + |
| 9 | +### 1. Research & Analysis |
| 10 | +Before proposing a change, use the `/research` command to gather context, analyze the current codebase, and identify potential risks. |
| 11 | + |
| 12 | +### 2. Strategic Planning |
| 13 | +A feature is not considered "active" until a persistent Markdown plan has been created in the `plans/` directory. Use the `/plan` command to generate this strategy and synchronize it with `TASKS.md`. |
| 14 | + |
| 15 | +### 3. Execution & Validation |
| 16 | +- **Incremental Implementation:** Break features into small, testable commits. |
| 17 | +- **Continuous Validation:** After every implementation turn, the framework automatically runs the `makefile`. Do not attempt to bypass this process. |
| 18 | +- **Journaling:** A brief, one-line technical log must be added to the daily journal for every significant turn. |
| 19 | + |
| 20 | +## ✅ Testing & Quality Standards |
| 21 | + |
| 22 | +- **Source of Truth:** The `makefile` is the central definition of project health. |
| 23 | +- **Mandatory Commands:** Ensure `make test`, `make lint`, and `make format` pass before committing. |
| 24 | +- **Documentation-as-Code:** Any new feature must be accompanied by relevant updates to the `docs/` directory. |
| 25 | + |
| 26 | +## 🌲 Git & Source Control |
| 27 | + |
| 28 | +### 1. Clean Working Tree |
| 29 | +The framework requires a clean working tree for critical actions. Commit often to avoid merge conflicts or large, unmanageable diffs. |
| 30 | + |
| 31 | +### 2. Conventional Commits |
| 32 | +All commit messages must follow the [Conventional Commits](https://www.conventionalcommits.org/) standard: |
| 33 | +- **`feat:`**: A new feature for the user. |
| 34 | +- **`fix:`**: A bug fix for the user. |
| 35 | +- **`docs:`**: Documentation-only changes. |
| 36 | +- **`chore:`**: Maintenance, dependencies, or internal tooling updates. |
| 37 | +- **`refactor:`**: Code changes that neither fix a bug nor add a feature. |
| 38 | + |
| 39 | +### 3. Commit Scoping |
| 40 | +When possible, provide a scope to the commit message (e.g., `feat(onboard): add documentation discovery`). |
| 41 | + |
| 42 | +## ✍️ Documentation Style |
| 43 | + |
| 44 | +- **Markdown:** All documentation and logs must be in GitHub-flavored Markdown. |
| 45 | +- **Kebab-case:** Use kebab-case for all filenames in the `docs/`, `plans/`, and `research/` directories. |
| 46 | +- **Direct & Technical:** Documentation should be concise, high-signal, and technically rigorous. |
| 47 | + |
| 48 | +--- |
| 49 | + |
| 50 | +*Return to the [Project Overview](index.md).* |
0 commit comments