Drone-Designer

Imported from EMPAERIAL/Drone-Designer (AGENTS.md). Install upstream with npx skills add EMPAERIAL/Drone-Designer. Copyright stays with the author.

# Repository Guidelines

Project Structure & Module Organization

Drone Designer is a VB.NET Windows Forms app targeting .NET Framework 4.7.2.

• Core/: domain models, selection interfaces, and services (ComponentSelectionEngine, PipelineOrchestrator).
• UI/Forms/: main UI plus split partials for logic, export, CAD, and in-app test hooks.
• Utilities/: cross-cutting helpers (for example config management).
• Resources/: runtime assets (AppData/components.json, SolidWorks templates/macros).
• Test/: maintained scenario inputs (Scenarios/) and generated logs/artifacts.
• docs/: MkDocs-based user, maintainer, and reference documentation.

Build, Test, and Development Commands

Run from repo root in PowerShell:

• msbuild "Drone Designer.vbproj" /p:Configuration=Debug builds local debug output to bin\Debug\.
• msbuild "Drone Designer.vbproj" /p:Configuration=Release builds release output to bin\Release\.
• & "bin\Debug\Drone Designer.exe" launches the app for smoke checks.
• In app: Ctrl+Shift+T runs built-in scenarios; Ctrl+Shift+L loads CSV scenarios from Test/Scenarios/.
• mkdocs serve previews docs locally; mkdocs build validates documentation output.

Coding Style & Naming Conventions

• Follow existing VB.NET style: 4-space indentation, Option Explicit On, and descriptive PascalCase names for types/methods/properties.
• Keep private fields consistent with surrounding file conventions; avoid introducing new naming styles in mixed legacy files.
• Split form responsibilities by concern (MainForm.Logic.vb, MainForm.Export.vb, MainForm.CAD.vb) rather than growing MainForm.vb.

Testing Guidelines

This repo relies on layered validation, not a single external test suite.

• Always do: build + startup smoke test.
• For selection/schema changes: run one manual design flow and scenario harness (Ctrl+Shift+T).
• For export changes: verify .xlsx generation after a successful design run.
• For CAD changes: validate on a SolidWorks-capable machine.

Commit & Pull Request Guidelines

Recent history follows short, imperative prefixes such as fix: ..., docs: ..., and Update ....

• Use concise subject lines (type: summary) and keep commits scoped.
• PRs should include: change summary, risk area (selection/export/CAD/docs), and exact validation performed (for example Built Debug, ran Ctrl+Shift+T, verified Excel export).
• Attach screenshots only for UI-visible changes.
• When creating an issue, first read and follow the relevant template under .github/ISSUE_TEMPLATES/.

Issue implementation flow:

1. Always switch to master.
2. Pull from master to sync your local copy.
3. Implement the issue.
4. Open a PR after implementation.
5. Merge the PR, then switch back to master and pull again to re-sync.

Security & Configuration Tips

• Do not hardcode machine-specific paths.
• Keep runtime assets beside the executable; missing Resources/AppData/components.json will break selection.
• Treat Resources/SolidWorks/ files as required release assets when claiming CAD support.