Added dialogs and menus article

.claude/agent-memory/sampsharp-docs-writer/MEMORY.md

@@ -0,0 +1,2 @@
+- [Project architecture](project-architecture.md) — Two-layer API (Core vs Entities), key services, dialog/menu internals
+- [Docs conventions](docs-conventions.md) — Article structure, style, code sample idioms, toc.yml layout, AGENTS.md content

.claude/agent-memory/sampsharp-docs-writer/docs-conventions.md

@@ -0,0 +1,40 @@
+---
+name: docs-conventions
+description: Documentation structure, style, and formatting conventions observed from existing feature articles
+metadata:
+  type: project
+---
+
+## File locations
+- Feature articles: `docs/features/*.md`
+- Each feature directory has a `toc.yml` listing article hrefs
+- Top-level `docs/toc.yml` exists; features have their own `docs/features/toc.yml`
+
+## Article structure (from vehicles.md, timers.md, objects.md, commands.md)
+- YAML frontmatter: `title:` and `uid:` only — no other fields
+- Single H1 matching the title
+- Short intro paragraph (2–3 sentences max), no preamble fluff
+- H2 for major sections, H3 for sub-topics
+- **Bold lead** before code blocks ("Example: ...", or inline description)
+- Code blocks use `csharp` fence; always use `[Event]` attribute on event handler methods
+- xrefs with `<xref:FullyQualifiedTypeName>` for API types
+- Inline cross-links rather than a dedicated "See Also" section
+- End of section: `See <xref:...> for all available properties and methods.` is a common closing pattern
+
+## Tone and density
+- Direct, instructional — no marketing filler
+- Assume C# developer; explain SA-MP-specific concepts (dialogs, menus) when first introduced
+- Short sentences, active voice
+- DocFX alerts used sparingly — only when genuinely useful (not decorative)
+
+## Code sample idioms
+- Event handlers shown inside `ISystem` class with `[Event]` attribute
+- Services injected as method parameters (not constructor-injected in samples unless needed)
+- Named parameters used in constructor calls for clarity (`caption:`, `button1:`, etc.)
+- `async Task` return type shown when using `ShowAsync`
+
+## AGENTS.md is actually a DocFX xref cheat sheet
+- The file at `docs/AGENTS.md` (which is loaded as the project AGENTS file) is actually a DocFX cross-reference guide, not a traditional agent instructions file
+- Key rule: prefer `<xref:uid>` syntax; use `[text](xref:uid)` only for custom link text
+- UID for conceptual docs comes from YAML frontmatter `uid:` field
+- UID for API docs is the fully-qualified type/member name

.claude/agent-memory/sampsharp-docs-writer/project-architecture.md

@@ -0,0 +1,27 @@
+---
+name: project-architecture
+description: SampSharp source layout, key namespaces, and the two-layer API pattern (Core vs Entities)
+metadata:
+  type: project
+---
+
+SampSharp has two distinct layers in `sampsharp-src/src/`:
+
+**Layer 1 — `SampSharp.OpenMp.Core` (`SampSharp.OpenMp.Core.Api` namespace)**
+- Raw open.mp API bindings: `IPlayerDialogData`, `IDialogsComponent`, `IMenu`, `IMenusComponent`, etc.
+- Enums here use ALLCAPS or abbreviated names (e.g. `DialogStyle.MSGBOX`, `DialogResponse.Left/Right`)
+- Accessed directly only when working at the native level
+
+**Layer 2 — `SampSharp.OpenMp.Entities` (`SampSharp.Entities.SAMP` namespace)**
+- The idiomatic C# API developers actually use
+- Higher-level types: `MessageDialog`, `InputDialog`, `ListDialog`, `TablistDialog`, `Menu`, `Player`, `Vehicle`, etc.
+- Enums have friendly names: `DialogStyle.MessageBox`, `DialogResponse.LeftButton/RightButtonOrCancel/Disconnected`
+- Services registered as singletons: `IDialogService`, `IWorldService`, `ITimerService`, etc.
+- Event handlers live in `ISystem` implementations using `[Event]` attribute
+
+**Why this matters:** Always document the Entities layer API — that is what gamemode developers use. The Core layer is an implementation detail.
+
+**Key service for dialogs:** `IDialogService` — registered automatically, no setup needed.
+**Key service for menus:** `IWorldService.CreateMenu(...)` — menus are world entities.
+
+**Dialog ID note:** `DialogService` internally uses dialog ID `10000`. Dialog IDs are not exposed to gamemode code.