# Repository Guidelines

## Project Structure & Module Organization
This repository is a .NET 6 + Vue 3 split-stack S7 PLC simulator.

- `WIDESEAWCS_S7Simulator.Core`: domain entities, memory regions (`M/DB/I/Q/T/C`), simulator runtime, persistence.
- `WIDESEAWCS_S7Simulator.Application`: application-layer abstractions and protocol/application services.
- `WIDESEAWCS_S7Simulator.Server`: ASP.NET Core Web API (`Controllers/`, `Program.cs`), runtime data under `Data/`.
- `WIDESEAWCS_S7Simulator.Web`: Vue 3 + TypeScript frontend (`src/views`, `src/api`, `src/router`, `src/types`).
- `WIDESEAWCS_S7Simulator.UnitTests`: xUnit tests for core/application behavior.
- `docs/`: design and protocol notes.

## Build, Test, and Development Commands
Run from repository root unless noted.

- `dotnet restore WIDESEAWCS_S7Simulator.slnx`: restore NuGet packages.
- `dotnet build WIDESEAWCS_S7Simulator.slnx`: build backend projects.
- `dotnet test WIDESEAWCS_S7Simulator.UnitTests`: run xUnit tests.
- `dotnet run --project WIDESEAWCS_S7Simulator.Server`: start API (default `http://localhost:5137`).
- `cd WIDESEAWCS_S7Simulator.Web && pnpm install`: install frontend deps.
- `cd WIDESEAWCS_S7Simulator.Web && pnpm dev`: start Vite dev server (typically `http://localhost:3000` or `5173`).
- `cd WIDESEAWCS_S7Simulator.Web && pnpm build`: type-check + production build.

## Coding Style & Naming Conventions
- C#: 4-space indentation, `PascalCase` for types/methods, `camelCase` for locals/parameters, interfaces prefixed with `I`.
- TypeScript/Vue: `PascalCase` for view components (e.g., `DetailsView.vue`), `camelCase` for variables/functions, keep API DTO types in `src/types`.
- Keep controllers thin; put business rules in Core/Application services.
- Prefer small, focused files over large mixed-responsibility classes.

## Testing Guidelines
- Framework: xUnit (`Microsoft.NET.Test.Sdk`, `coverlet.collector`).
- Name tests by behavior, e.g., `MemoryStoreTests.ReadBit_ReturnsExpectedValue`.
- Add/update tests for any change to memory parsing, protocol templates, persistence, or instance lifecycle.
- Run `dotnet test` before opening a PR.

## Commit & Pull Request Guidelines
- Follow Conventional Commit style seen in history: `feat: ...`, `fix: ...`, `refactor: ...` (Chinese summaries are acceptable).
- Keep one logical change per commit; avoid bundling unrelated files.
- PRs should include: purpose, key changes, test evidence (`dotnet test`, `pnpm build`), and screenshots/GIFs for UI changes.
- Link related issue/task IDs and call out any config/data migration impacts.