Agent docs

AGENTS.md

@@ -4,7 +4,7 @@
 
 `SaCommonVS.sln` contains the shared Sarand libraries. `SacsStandardBase` provides core types and utilities; `SacsStandardDbas` provides database support; `SacsStandardProc` provides process and file-processing support; `SacsCoreWeb` provides ASP.NET components; and `SacsStandardAccounts` provides accounting integrations. Mobile support is in `SacsMobileMaui` and `SacsMobileXamarin`. Tests live in `SacsCoreUnitTests` and generally mirror the corresponding source area under `Standard`.
 
-These projects are consumed by sibling repositories, including `..\..\BusinessMgr\Workspace`. Preserve the relative repository layout when validating changes against downstream solutions.
+These projects are consumed by sibling workspaces, including `..\..\BusinessMgr\Workspace`, `..\..\MauiApps\Repositories\Sandtrap\Workspace\Sandtrap`, and `..\..\MauiApps\Repositories\Sandalwood\Workspace`. Preserve the relative layout because downstream solutions use direct project references.
 
 ## Build, Test, and Development Commands
 
@@ -18,13 +18,26 @@ dotnet test SacsCoreUnitTests/SacsCoreUnitTests.csproj --configuration Debug
 
 Use `--configuration Release` for release validation. Build the directly affected project first, then build the solution when a change affects public APIs or shared behavior. Mobile projects may require installed MAUI workloads and platform-specific tooling; report any unavailable workload separately from source failures.
 
+For changes to Common public APIs, target frameworks, packages, or shared behavior, validate the relevant downstream solutions. Coordinate framework upgrades across dependency boundaries. When consumers cannot move atomically, temporarily multi-target shared libraries where practical, migrate consumers, and remove the old target only after no in-scope consumer requires it.
+
 ## Coding Style & Naming Conventions
 
 Match the existing C# conventions: tabs, braces on new lines, top-of-file `using` directives, PascalCase public members, and established `Sacs`, `Sa`, `Sam`, and `Sax` prefixes. Follow nearby code where no repository-wide formatter rule exists. Target the framework versions declared in project files. Do not upgrade frameworks or NuGet packages unless explicitly requested.
 
 Processes derived from `SaProcess_Base` must actively poll `IsInterrupted` during long-running loops and before expensive or blocking stages, then exit promptly when cancellation is requested.
 
-Use Windows CRLF line endings for C# source, Visual Studio project files, configuration files, PowerShell or command scripts, and general documentation. Use LF for web assets and files commonly consumed by Unix tooling, including SVG, HTML, CSS, JavaScript, shell scripts, and YAML. Follow `.gitattributes` as the authoritative policy and preserve the configured ending when editing files.
+Use Windows CRLF line endings for C# source, Visual Studio project files, configuration files, PowerShell or command scripts, and general documentation. Use LF for web assets and files commonly consumed by Unix tooling, including SVG, HTML, CSS, JavaScript, shell scripts, and YAML. Follow `.gitattributes` as the authoritative policy. Whenever a file is created or edited, normalize that file to its required line ending as part of the edit, before validation and handoff; do not defer normalization as a separate cleanup step.
+
+New Markdown documents containing tables must include this document-level style so header and data cells are top aligned:
+
+```html
+<style>
+table th,
+table td {
+	vertical-align: top;
+}
+</style>
+```
 
 ## Testing Guidelines
 
@@ -34,6 +47,8 @@ Tests use MSTest and live in `SacsCoreUnitTests`. Add focused tests under the di
 
 Do not edit generated files or build output under `bin`, `obj`, or `TestResults`. Change source inputs instead. Preserve public API compatibility because multiple sibling solutions consume these libraries. Before implementing a significant architectural or breaking change, describe the affected projects, compatibility implications, and migration approach and wait for agreement.
 
+Treat every affected Git workspace as an independent change set. Check its status before editing, preserve unrelated changes, and report validation separately for each workspace.
+
 ## Conversation Tracking
 
 Read `docs/topics.md` and `docs/component-reviews.md` before starting repository review or follow-up work. Update them when a conversation identifies, starts, completes, or reprioritises work, or when a component is reviewed. Follow the tracking conventions in `docs/README.md` and use ISO `YYYY-MM-DD` dates.