Complete ESP32-C6 schematic and organize hardware layout

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,26 @@
+---
+name: "🐛 Bug / Anomaly Report"
+about: Report an unexpected behavior, runtime exception, or hardware malfunction.
+title: '[BUG] '
+labels: 'type: bug'
+assignees: ''
+---
+
+### 1. Anomaly Description
+A clear and concise description of the bug, exception, or hardware malfunction.
+
+### 2. Steps to Reproduce
+1. 
+2. 
+3. 
+
+### 3. Expected Behavior
+What you expected to happen based on specifications or mission requirements.
+
+### 4. Environment
+- **Hardware Version:** 
+- **Firmware / OS:** 
+- **Testbed (HIL/SITL/Bench):** 
+
+### 5. Telemetry, Logs & Attachments
+Attach relevant logs, telemetry data, logic analyzer traces, or schematics here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,16 @@
+---
+name: "🚀 Feature / Enhancement Request"
+about: Suggest new functionality, components, or architectural capabilities.
+title: '[FEATURE] '
+labels: 'type: feature'
+assignees: ''
+---
+
+### 1. Technical Objective
+Describe the engineering problem, objective, or limitation of the current system.
+
+### 2. Proposed Solution
+A clear description of the new functionality, hardware component, or architectural capability.
+
+### 3. Alternatives Considered
+Describe any alternative solutions or COTS (Commercial Off-The-Shelf) options you've considered.

.github/ISSUE_TEMPLATE/inquiry.md

@@ -0,0 +1,13 @@
+---
+name: "❓ Inquiry / Technical Question"
+about: Requests for technical specifications, clarification, or usage guidance.
+title: '[INQUIRY] '
+labels: 'type: inquiry'
+assignees: ''
+---
+
+### Technical Question
+Describe your question or request for clarification.
+
+### Context
+Provide relevant context, such as the subsystem, datasheet referenced, or specific codebase module.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,18 @@
+## 📋 Description
+Provide a concise description of the changes introduced by this PR. Include the problem it solves and the approach taken.
+
+**Closes:** #
+
+## 🧪 Verification & Testing
+How was this change verified?
+- [ ] Unit Tests
+- [ ] SITL / Simulation
+- [ ] HIL / Hardware Testing (attach logs if applicable)
+
+## ⚠️ Safety & Risk Assessment
+- [ ] Failure modes and edge cases have been considered.
+- [ ] System safety margins are not degraded.
+- [ ] Documentation and datasheets have been updated if required.
+
+## 📌 Additional Notes
+Any deployment constraints, dependencies, or blockers.

.gitignore

@@ -41,3 +41,6 @@ fp-info-cache
 
 # Local project settings
 *.kicad_prl
+
+# JLCPCB
+**/jlcpcb

CHANGELOG.md

@@ -0,0 +1 @@
+

CONTRIBUTING.md

@@ -0,0 +1,69 @@
+# Contribution Guidelines
+
+As an engineering project, our development lifecycle demands strict adherence to verification, traceability, and reliability standards. Whether you are contributing to Software, Electronics, or Mechanical integration, please follow the guidelines outlined below.
+
+## 1. Licensing and Preamble
+
+All authored content must contain the appropriate preamble and copyright notice at the top of the file. We operate under a dual-licensing model:
+
+*   **Software (`software/`):** MIT License.
+*   **Hardware (`hardware/`, `mechanics/`):** CERN-OHL-P-2.0.
+
+Source code files must also include a brief Doxygen-style header documenting the author, date, and description:
+
+```
+/**
+ * \file filename.c
+ * \brief Brief description of the module.
+ * \author Author Name <author@email.com>
+ * \date YYYY/MM/DD
+ *
+ * SPDX-License-Identifier: MIT
+ */
+```
+
+## 2. Software Engineering
+
+We prioritize deterministic, safe, and readable code suitable for embedded systems.
+
+*   **Coding Standard:** We strongly prefer a recognized coding standard for the C Programming Language (based on MISRA-C).
+*   **Documentation:** All functions must include Doxygen headings specifying `\brief`, `\param`, and `\return`.
+*   **Include Guards:** All header files must implement preprocessor checking (`#ifndef FILENAME_H_`) to prevent multiple inclusions. Include dependencies only where strictly necessary.
+*   **Style:** Indent with **4 spaces** (no tabs). Variable names must be lowercase and separated by underscores (`int sensor_reading = 0;`).
+
+## 3. Hardware Engineering
+
+Hardware contributions must maintain the integrity of the system architecture and conform to applicable physical standards.
+
+*   **Toolchain:** Use KiCad for all schematic and PCB layout design.
+*   **Rule Checks:** Before committing any PCB changes, you **must** run and clear the Electrical Rule Check (ERC) and Design Rule Check (DRC). Pull Requests with ERC/DRC violations will be rejected.
+*   **Generated Files:** Do not commit manufacturing outputs (Gerbers, NC Drill, BOM) or 3D STEP files during regular development. These are generated exclusively by repository administrators during tagged release cycles to prevent synchronization issues.
+*   **Self-Contained Libraries:** To ensure 100% reproducibility and prevent missing dependencies, every hardware repository must be entirely self-contained. All symbols, footprints, and 3D models must be stored within project-specific local libraries (e.g., .kicad_sym, .kicad_mod) inside the repository. Never link to global, external, or user-specific machine libraries.
+
+## 4. Verification and Testing
+
+No code or hardware design is merged without proven verification.
+
+*   **Traceability:** Every Pull Request (PR) must reference a specific System Requirement (SRD) or an open Issue.
+*   **Testing:** Software PRs must include unit tests or hardware-in-the-loop validation logs. Hardware PRs must include physical integration checks or thermal/electromagnetic simulation results if applicable.
+
+## 5. Git Flow and Branching Strategy
+
+We utilize a segmented Git workflow to isolate disciplines and maintain a stable production environment.
+
+### Core Branches
+*   `main`: **Production Model (PM).** Contains only tested, stable, and production-ready releases.
+*   `dev`: **Integration / Development Model (DM).** The staging branch where all disciplines merge their validated work.
+
+### Segment Branches
+Regular development occurs in discipline-specific branches:
+*   `dev_hardware`
+*   `dev_software`
+*   `dev_mechanics`
+*   `dev_tests`
+
+### Workflow
+1. Create a feature branch originating from the relevant segment branch (e.g., `feature/eps-telemetry` from `dev_software`).
+2. Commit your changes with clear, descriptive messages.
+3. Open a Pull Request (PR) against the segment branch.
+4. The PR requires review and approval from repository administrators before being merged. Merges to `dev` and `main` are handled exclusively by maintainers after integration tests.

README.md

@@ -1 +1,75 @@
-# LIONv3R
+<div align="center">
+  <img src="https://framerusercontent.com/images/zX3lmokKbWs01tG0gns0ruBgLo.png" alt="Rodrigo Andrade Logo" width="96"/>
+</div>
+
+<h1 align="center">LIONv3-R Module</h1>
+
+<p align="center">
+    <a href="https://github.com/RodrigoCAndrade/LIONv3-R"><img alt="Status" src="https://img.shields.io/badge/Status-In Development-050505?style=for-the-badge"></a>
+    <a href="https://github.com/RodrigoCAndrade/LIONv3-R/releases"><img alt="GitHub Release" src="https://img.shields.io/github/v/release/RodrigoCAndrade/LIONv3-R?style=for-the-badge&color=050505&logo=github&logoColor=white"></a>
+    <a href="https://github.com/RodrigoCAndrade/LIONv3-R/issues"><img alt="GitHub Issues" src="https://img.shields.io/github/issues/RodrigoCAndrade/LIONv3-R?style=for-the-badge&color=050505&logo=github&logoColor=white"></a>
+    <a href="https://github.com/RodrigoCAndrade/LIONv3-R/pulls"><img alt="GitHub Pull Requests" src="https://img.shields.io/github/issues-pr/RodrigoCAndrade/LIONv3-R?style=for-the-badge&color=050505&logo=github&logoColor=white"></a>
+    <a href="https://github.com/RodrigoCAndrade/LIONv3-R/graphs/contributors"><img alt="GitHub Contributors" src="https://img.shields.io/github/contributors/RodrigoCAndrade/LIONv3-R?style=for-the-badge&color=050505&logo=github&logoColor=white"></a>
+</p>
+
+<br>
+
+<p align="center">
+    <img src="mechanics/3d_exports/PCB-Front.png" width="350"><img src="mechanics/3d_exports/PCB-Back.png" width="350">
+</p>
+
+## Overview
+
+The LIONv3-R is a powerful IoT and Direct-to-Satellite (DtS) board powered by the ESP32-C6, featuring 16MB of internal memory and versatile local connectivity through Wi-Fi, Zigbee, and Thread. For global communication, it utilizes LoRa (LR-FHSS) technology, which allows for a high density of devices transmitting data reliably directly to satellites from remote locations. By bridging local wireless networks with satellite reach, the LIONv3-R provides a complete and scalable hardware solution for telemetry, global tracking, and remote sensing applications.
+
+## Repository Organization
+
+* `docs`: Systems engineering, datasheets, requirements (SRD), and interface control (ICD).
+* `hardware`: Native KiCad project, schematics, and manufacturing files.
+* `mechanics`: 3D models, technical drawings, and physical integration constraints.
+* `software`: Embedded firmware and support testing scripts.
+
+## Releases
+
+<table>
+  <thead>
+    <tr>
+      <th>Render</th>
+      <th>Hardware Revision</th>
+      <th>Status</th>
+      <th>Latest Release</th>
+      <th>Date</th>
+      <th>Datasheet</th>
+      <th>BOM</th>
+      <th>Manufacturing Info</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td><img src="mechanics/3d_exports/PCB-Front.png" alt="board render" width="128"/></td>
+      <td>LIONv3-R</td>
+      <td>🚧 Development</td>
+      <td><a href="#">-</a></td>
+      <td>18-08-2026</td>
+      <td><a href="#">PDF</a></td>
+      <td>-</td>
+      <td><a href="#">Gerber</a></td>
+    </tr>
+  </tbody>
+</table>
+
+## Contributing
+
+We welcome contributions to this project! To ensure a smooth collaboration and maintain our engineering standards, please review our [Contribution Guidelines](CONTRIBUTING.md) before opening any issues, modifying the hardware design, or submitting pull requests.
+
+
+## References
+
+<br/>
+
+## License
+
+This project utilizes a dual-licensing approach to maximize flexibility and adoption:
+
+* **Hardware:** The hardware designs and schematics are licensed under the permissive **[CERN-OHL-P-2.0](hardware/LICENSE)** open-hardware license. You are entirely free to use, modify, distribute, and commercialize the design without any copyleft obligations to share your derived works under the same terms.
+* **Software:** All embedded firmware and utility scripts are licensed under the **[MIT License](software/LICENSE)**. You are free to use, modify, and distribute the code without restriction, provided the original copyright notice and permission notice are included.