tets

Author: KSemenenko

AGENTS.md

@@ -304,6 +304,7 @@ Local `AGENTS.md` files may tighten these values, but they must not loosen them
 - Hardcoded values are forbidden.
 - String literals are forbidden in implementation code. Declare them once as named constants, enums, configuration entries, or dedicated value objects, then reuse those symbols.
 - Avoid magic literals. Extract shared values into constants, enums, configuration, or dedicated types.
+- Backlog metadata does not belong in product code: issue numbers, PR numbers, review language, and planning terminology must never appear in production runtime models, diagnostics, or user-facing text unless the feature explicitly exposes source-control metadata.
 - Design boundaries so real behaviour can be tested through public interfaces.
 - For `.NET`, the repo-root `.editorconfig` is the source of truth for formatting, naming, style, and analyzer severity.
 - Use nested `.editorconfig` files when they serve a clear subtree-specific purpose. Do not let IDE defaults, pipeline flags, and repo config disagree.
@@ -362,6 +363,7 @@ Ask first:
 - Installing stale, non-canonical, or non-`mcaf-*` skills into the repo-local agent skill directory.
 - Moving root governance out of the repository root.
 - Mixing multiple `.NET` test frameworks in the active solution without a documented migration plan.
+- Running build, test, or verification commands for file-only structural reorganizations when the user explicitly asked for folder cleanup without behavior changes.
 - Adding fallback paths or alternate harnesses that only make failures disappear in tests while the primary product path remains broken.
 - Switching desktop Uno pages into stacked or mobile-style responsive layouts during resize work unless the user explicitly asks for a different composition; desktop pages must stay desktop-first and protect geometry through sizing constraints instead.
 - Adding extra UI-test orchestration complexity when the actual goal is simply to run the tests and get an honest pass or fail result.

DotPilot.UITests/AGENTS.md

@@ -11,8 +11,9 @@ Stack: `.NET 10`, `NUnit`, `Uno.UITest`, browser-driven UI tests
 ## Entry Points
 
 - `DotPilot.UITests.csproj`
-- `Harness/*`
-- `Features/*`
+- `Harness/Constants.cs`
+- `Harness/TestBase.cs`
+- `Features/ApplicationShell/Given_MainPage.cs`
 
 ## Boundaries
 
@@ -21,7 +22,7 @@ Stack: `.NET 10`, `NUnit`, `Uno.UITest`, browser-driven UI tests
 - Treat browser-driver setup and app-launch prerequisites as part of the harness, not as assumptions inside individual tests.
 - The harness must make `dotnet test DotPilot.UITests/DotPilot.UITests.csproj` runnable without manual driver-path export and must fail loudly instead of silently skipping coverage.
 - Keep the harness direct and minimal; prefer the smallest deterministic setup needed to run the suite and return a real result.
-- Organize files by feature slice and harness boundary: browser/bootstrap infrastructure under harness folders, feature-flow tests under the slice they verify.
+- Keep the file layout explicit: browser harness code belongs under `Harness/`, harness self-tests under `Harness/Tests/`, end-to-end slice coverage under `Features/<Slice>/`, and cross-slice operator flows under `Journeys/`.
 - Use the official `Uno` MCP documentation as the source of truth for `Uno.UITest` browser behavior, and align selectors with the documented WebAssembly automation mapping before changing the harness.
 - Do not manually launch the app or a standalone `browserwasm` host while working on this project; browser-path reproduction and debugging must go through `dotnet test` and the real `DotPilot.UITests` harness only.
 - UI tests must cover each feature's interactive elements, expected behaviors, and full operator flows instead of only a top-level smoke path.
@@ -40,5 +41,5 @@ Stack: `.NET 10`, `NUnit`, `Uno.UITest`, browser-driven UI tests
 ## Local Risks Or Protected Areas
 
 - The harness targets a browser flow and auto-starts the `net10.0-browserwasm` head on a loopback URI resolved by the harness; any driver discovery or bootstrap logic must stay deterministic across local and agent environments.
-- `Constants.cs` and `TestBase.cs` define environment assumptions for every UI test; update them carefully and only when the automation target actually changes.
+- `Harness/Constants.cs` and `Harness/TestBase.cs` define environment assumptions for every UI test; update them carefully and only when the automation target actually changes.
 - Every new UI capability should arrive with assertions for the visible controls it adds and at least one complete end-to-end flow through the affected surface.