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.