housekeeping: Organize files into reports and reference directories

- Move audit reports and status reports to reports/ directory
- Move documentation, configuration files, and infrastructure to reference/ directory
- Keep only core project files (LICENSE, README.md) at root level
- Resolve organizational issues from previous branch merges

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

reports/AUDIT_REPORT_MGR-GEMINI_V2.md

@@ -0,0 +1,113 @@
+# Audit Report: sol-calc.com Project Review - Iteration 2 (MGR-GEMINI Branch)
+
+**Date:** 2025-09-03
+**Auditor:** Gemini (acting as external auditor/team member)
+**Scope:** Review of project documentation, Gemini's planning, and work identified across branches, incorporating insights from other agents' audits.
+
+## Executive Summary
+
+Since the initial audit, the `sol-calc.com` project has seen significant evolution in its planning, particularly with the detailed specification of the "Installation Planning Wizard" in `TASKS.md`. While the foundational architectural and security principles remain strong, the introduction of this complex core functionality, coupled with the project's current state of zero code implementation, elevates the overall risk profile. This audit incorporates insights from both Claude's and Grok's comprehensive reports, which largely concur on the project's ambitious scope and the critical need for concrete implementation and domain expertise.
+
+The project demonstrates excellent foresight in its architectural choices and commitment to security and modern development practices. However, the gap between detailed planning and actual execution, especially for the highly complex core features, is a primary concern.
+
+## Detailed Findings and Recommendations
+
+### 1. Project Vision and Scope Evolution
+
+*   **Finding:** The project vision has been significantly elaborated with the "Installation Planning Wizard" in `TASKS.md`. This section details critical functionalities like site assessment, system design, energy production estimation, and reporting, along with user flows, data inputs, and core calculations. This is a clear step towards defining the product's core value.
+*   **Assessment:** This detailed functional specification is a positive development, providing clarity on the product's intended capabilities. However, it also exposes the immense technical and domain complexity inherent in the project. Both Claude and Grok highlight this as a major concern, emphasizing the need for specialized solar engineering knowledge, 3D visualization, and complex algorithms.
+*   **Recommendation:**
+    *   **Prioritize MVP:** Re-evaluate the "Installation Planning Wizard" features to define a truly minimal viable product (MVP). Many listed features (e.g., 3D site visualization, CAD export) are highly complex and could be phased in later.
+    *   **Phased Implementation:** Break down the wizard into smaller, manageable phases. Focus on getting basic calculations and reporting functional before tackling advanced features.
+    *   **Domain Expertise:** As both Claude and Grok suggest, actively seek and integrate solar engineering domain expertise into the team. Research and consider leveraging existing, proven solar engineering libraries (e.g., pvlib, SAM) rather than building all calculations from scratch.
+
+### 2. Architecture and Technology Stack
+
+*   **Finding:** The microservices architecture, preferred languages (Rust, Go), gRPC, PostgreSQL, and comprehensive observability stack (OpenTelemetry, Prometheus, Grafana Loki, SigNoz) remain consistent and well-chosen for a scalable, high-performance system.
+*   **Assessment:** The architectural choices are sound for a long-term, robust solution. However, as Grok points out, this complexity might be an "overkill for initial MVP." The detailed wizard functionality further stresses the need for robust inter-service communication and data management, especially with the Dolibarr integration.
+*   **Recommendation:**
+    *   **Service Definition:** Begin defining concrete service interfaces using gRPC proto definitions for the core wizard functionalities. This will clarify inter-service contracts and facilitate parallel development.
+    *   **Data Modeling:** Develop detailed database schemas for the data inputs and outputs of the wizard, ensuring consistency across services.
+    *   **Integration Strategy:** Prioritize the robust implementation of the Dolibarr Integration Service, as it's critical for project and customer data. Define clear error handling and resilience strategies for all external integrations (Keycloak, Hyperswitch, external weather/solar APIs).
+
+### 3. Development Environment and Workflow
+
+*   **Finding:** The commitment to containerized development (Docker/devcontainers), feature branching, and frequent commits is consistently emphasized across documentation.
+*   **Assessment:** These practices are excellent for consistency and collaboration. However, the audit revealed that the initial documentation (`ARCHITECTURE.md`, `DEV-SETUP.md`, `PROD-SETUP.md`, `SECURITY.md`, and the "Testing Strategy" in `TASKS.md") was primarily developed in the `docs` branch. The "Installation Planning Wizard" content was introduced elsewhere (likely `main` or another branch merged into `main` and then into `MGR-GEMINI`). This suggests a potential divergence in documentation development workflows.
+*   **Recommendation:**
+    *   **Unified Documentation Workflow:** Clarify and enforce a single, consistent workflow for all documentation updates. If the `docs` branch is intended for all documentation, ensure all significant planning updates (like the wizard details) are routed through it.
+    *   **Automated Setup:** As suggested in my previous audit, develop automated scripts (e.g., `docker-compose.yml`) to quickly spin up the entire development environment, including all necessary microservices and the observability stack.
+
+### 4. Security and Compliance
+
+*   **Finding:** The project maintains a strong commitment to security, adhering to multiple compliance standards (SOC, SOX, PCI, GDPR, NIST) and emphasizing security-by-design principles.
+*   **Assessment:** The security posture is theoretically robust. However, as Claude notes, "No actual implementation" means the security review is currently theoretical. The complexity of the "Installation Planning Wizard" and its data inputs (e.g., geographic location, property boundaries) introduces new security considerations, particularly around data privacy and integrity.
+*   **Recommendation:**
+    *   **Threat Modeling for Wizard:** Conduct specific threat modeling exercises for the "Installation Planning Wizard" functionality, identifying potential vulnerabilities related to data input, calculations, and reporting.
+    *   **Data Classification:** Implement a clear data classification scheme for all data handled by the wizard, ensuring appropriate encryption and access controls.
+    *   **Input Validation:** Reinforce rigorous input validation for all wizard inputs to prevent malicious data injection or calculation manipulation.
+
+### 5. Testing Strategy
+
+*   **Finding:** The initial "Testing Strategy" in `TASKS.md` (now replaced by the wizard details) outlined a comprehensive approach to unit, integration, E2E, and performance testing.
+*   **Assessment:** While the strategy was sound, the removal of this section from `TASKS.md` is concerning. The complexity of the "Installation Planning Wizard" makes a robust testing strategy even more critical. Claude's report specifically highlights "Domain calculation validation strategy missing (critical for professional trust)."
+*   **Recommendation:**
+    *   **Re-establish Testing Strategy:** Re-integrate a dedicated and detailed testing strategy section into the project documentation.
+    *   **Prioritize Calculation Validation:** Develop a rigorous strategy for validating the accuracy of all solar engineering calculations within the wizard. This is paramount for the application's credibility and professional trust. Consider using known good test cases and comparing results against established industry tools.
+    *   **Automated Testing for Wizard:** Implement automated unit, integration, and E2E tests for the wizard's core functionalities as they are developed.
+
+### 6. CI/CD and Observability
+
+*   **Finding:** The CI/CD strategy (Gitea Actions, Jenkins) and comprehensive observability stack remain in place.
+*   **Assessment:** These are strong choices for a microservices environment. However, as Grok points out, "No actual pipeline definitions or workflows" exist yet. The increased complexity of the wizard will demand sophisticated CI/CD pipelines and detailed observability for debugging and performance monitoring.
+*   **Recommendation:**
+    *   **Pipeline Definition:** Begin defining concrete CI/CD pipelines for the initial microservices, focusing on automated builds, testing, and deployment to development environments.
+    *   **Observability Implementation:** Start implementing the observability stack alongside the first microservices. Ensure metrics, logs, and traces are collected for the wizard's core calculation services.
+
+### 7. Integration of Other Agents' Insights
+
+*   **Finding:** Both Claude's and Grok's audit reports provide valuable, largely consistent insights. They both emphasize the significant complexity of the "Installation Planning Wizard," the lack of concrete implementation, and the need for specialized domain expertise. Grok specifically highlights the learning curve for Rust/Go and the potential for microservices to be overkill for an MVP.
+*   **Assessment:** The convergence of these independent audits on key risks (scope, complexity, implementation gap) reinforces their criticality.
+*   **Recommendation:** Actively review and address the specific recommendations and concerns raised in both `MGR-CLAUDE-AUDIT-REPORT.md` and `MGR-GROK-COMPREHENSIVE-AUDIT-REPORT.md`. These reports serve as excellent external validations of the project's challenges.
+
+## Conclusion
+
+The `sol-calc.com` project has a clear vision and a robust theoretical foundation. The detailed "Installation Planning Wizard" is a significant step in defining the product. However, the project is at a critical juncture where the ambitious scope of this core functionality meets the reality of zero code implementation. The insights from Claude and Grok further underscore the challenges.
+
+To ensure success, the project must:
+1.  **Prioritize a truly minimal viable product (MVP)** for the "Installation Planning Wizard," focusing on core calculations and reporting.
+2.  **Begin concrete implementation** of microservices, starting with the most critical components of the wizard.
+3.  **Actively acquire and integrate domain expertise** in solar engineering.
+4.  **Re-establish and rigorously implement a comprehensive testing strategy**, with a strong emphasis on calculation validation.
+5.  **Unify and streamline documentation workflows.**
+
+Moving forward, the focus should shift from extensive planning to iterative development, with continuous validation and adaptation based on early implementations.
+
+This report will be committed to the `MGR-GEMINI` branch.
+
+## Review of sol-calc-supplychain Branch
+
+**Branch Name:** `sol-calc-supplychain`
+**Assessment Date:** 2025-09-03
+
+### Findings:
+
+1.  **Outdated Base:** The `sol-calc-supplychain` branch was found to be based on an older commit of the `main` branch. It does not contain the latest updates to core project documentation, most notably the detailed "Installation Planning Wizard" section in `TASKS.md`.
+2.  **No Explicit Supply Chain Plan:** Despite its name, the branch contains no explicit documentation, code, or configuration files that outline a plan for supply chain functionality. The `README.md`, `TASKS.md`, and other core documents within this branch are either identical to older versions in `main` or lack any supply-chain-specific content.
+3.  **No Supply Chain-Related Files:** A comprehensive listing of all files within the branch revealed no new directories or files that would indicate the development or planning of supply chain features.
+
+### Conclusion:
+
+The `sol-calc-supplychain` branch, as it currently stands, does not provide any discernible plan or implementation for supply chain functionality. Its outdated base makes it unsuitable for direct continuation of work related to the current project vision.
+
+### Recommendations:
+
+1.  **Re-evaluate Need:** Confirm if supply chain functionality is still a priority for the `sol-calc.com` project given the current focus on the "Installation Planning Wizard."
+2.  **New Branch for Supply Chain:** If supply chain functionality is still required, a new feature branch should be created from the *latest* `main` branch (or a stable release branch).
+3.  **Dedicated Planning:** A comprehensive plan for supply chain integration should be developed from scratch, taking into account the current architecture, the detailed "Installation Planning Wizard" functionality, and the overall project roadmap. This plan should clearly define:
+    *   The specific scope and features of the supply chain module (e.g., component sourcing, inventory management, vendor integration).
+    *   How it integrates with existing and planned modules (e.g., BOM generation, project management in Dolibarr).
+    *   Any new microservices, data models, or external integrations required.
+    *   The impact on the overall technology stack, security, and testing strategy.
+4.  **Archive/Delete Old Branch:** The `sol-calc-supplychain` branch should be considered for archiving or deletion to avoid confusion, as it does not reflect current project direction or contain relevant supply chain planning.
+