mirror of
https://github.com/gwdevhub/Daybreak.git
synced 2026-09-14 04:19:24 +00:00
72 lines
2.7 KiB
Markdown
72 lines
2.7 KiB
Markdown
# Copilot instructions for Daybreak
|
|
|
|
Daybreak is a cross-platform Guild Wars launcher built on .NET 10 and
|
|
Photino.Blazor. Read the
|
|
[Architecture Overview](../README.md#architecture-overview) for the project
|
|
layout and [CONTRIBUTING.md](../CONTRIBUTING.md) for the branching and release
|
|
process.
|
|
|
|
## Workflow
|
|
|
|
- Branch off the current `release/[version]` branch, never off `master`.
|
|
- One feature or fix per branch and per PR.
|
|
- Never push to `master` and never edit the version in `Directory.Build.props`.
|
|
Both are owned by the release workflows.
|
|
- Title PRs `Short description (Closes #123)` so the linked issue gets labelled.
|
|
|
|
## Build and test
|
|
|
|
CI does not run on PRs targeting a release branch, so validate locally. Run the
|
|
smallest command that covers the change:
|
|
|
|
```bash
|
|
dotnet build Daybreak.Linux/Daybreak.Linux.csproj # or Daybreak.Windows
|
|
dotnet test Daybreak.Tests/Daybreak.Tests.csproj --filter "FullyQualifiedName~YourTests"
|
|
```
|
|
|
|
Keep the build warning-free.
|
|
|
|
## Where code goes
|
|
|
|
| Change | Project |
|
|
| -------------------------------------------------- | ------------------------------------ |
|
|
| Models, utilities, interfaces shared by everything | `Daybreak.Shared` |
|
|
| Blazor views and services | `Daybreak.Core` |
|
|
| Platform-specific implementations | `Daybreak.Windows`, `Daybreak.Linux` |
|
|
|
|
`Daybreak.Tests` only references `Daybreak.Core`. When adding platform code, put
|
|
the logic worth testing in `Daybreak.Shared` and leave the platform project as a
|
|
thin caller.
|
|
|
|
Add NuGet packages through `Directory.Packages.props`.
|
|
|
|
## C# conventions
|
|
|
|
`.editorconfig` is the source of truth. The projects are set up to treat
|
|
warnings as errors.
|
|
|
|
## Verify before claiming
|
|
|
|
Prefer evidence over reasoning about behaviour, especially for the Wine and
|
|
injection paths. Wine is scriptable, so reproduce the actual failure and confirm
|
|
the fix against it rather than inferring what a Win32 call does.
|
|
|
|
## Writing style
|
|
|
|
Applies to docs, comments, PR descriptions and answers.
|
|
|
|
- Be short. Cut filler, recap and process narration.
|
|
- No AI-isms and no inflated language.
|
|
- Do not paste code into documentation. Link to the file so there is only one
|
|
copy of it.
|
|
- Explain the reason for a change, not a summary of the diff.
|
|
|
|
## Markdown
|
|
|
|
- No inline HTML. Use `![alt][ref]` with a reference definition instead of an
|
|
`img` tag.
|
|
- Start a mermaid fence with the diagram type, for example `flowchart LR`. YAML
|
|
frontmatter inside the fence is rejected by some renderers.
|
|
- Long URLs belong in reference-style link definitions at the bottom of the
|
|
file.
|