ReleasedGroup · kalen-releasedgroup · Apr 23, 2026 · Apr 23, 2026 · Apr 23, 2026
diff --git a/README.md b/README.md
@@ -4,6 +4,8 @@ This repository is being used to build a C#-based semantic test mining platform
 
 The current source of truth for the planned product is [docs/requirements.md](/mnt/c/Users/kenne/Desktop/ReleasedGroup/2EndSquaredTesting/docs/requirements.md). The concept document that informed it is [docs/concept.md](/mnt/c/Users/kenne/Desktop/ReleasedGroup/2EndSquaredTesting/docs/concept.md).
 
+In addition to being production-capable, the application is expected to support a local, production-like developer environment so changes can be exercised safely before they are pushed. The Blazor Server UI is also expected to be built early enough that major workflows can be visually tested during development rather than only through backend or CLI flows.
+
 ## Product Summary
 
 The application described in this repository is not intended to be a raw click recorder. It is intended to be a semantic test mining and stabilisation platform that:

diff --git a/WORKFLOW.md b/WORKFLOW.md
@@ -4,7 +4,7 @@ tracker:
   endpoint: https://api.github.com/graphql
   api_key: $GITHUB_TOKEN
   owner: releasedgroup
-  repo: nextmedia-manager-copilot
+  repo: 2EndSquaredTesting
   milestone: null
   include_pull_requests: true
   labels: []

diff --git a/docs/README.md b/docs/README.md
@@ -14,6 +14,7 @@ This folder now contains the planning and specification documents for the new te
 - [Security Plan](./security-plan.md)
 - [Testing Plan](./testing-plan.md)
 - [Implementation Roadmap](./implementation-roadmap.md)
+- [Sprint Plan](./sprint-plan.md)
 - [Requirements Traceability Matrix](./requirements-traceability-matrix.md)
 
 ## Recommended Reading Order
@@ -24,7 +25,8 @@ This folder now contains the planning and specification documents for the new te
 4. `security-plan.md`
 5. `testing-plan.md`
 6. `implementation-roadmap.md`
-7. `requirements-traceability-matrix.md`
+7. `sprint-plan.md`
+8. `requirements-traceability-matrix.md`
 
 ## Usage Guidance
 
@@ -33,3 +35,4 @@ This folder now contains the planning and specification documents for the new te
 - Use the UI/UX, security, and testing plans as non-optional design constraints.
 - Use the traceability matrix to connect future code, tests, ADRs, and pull requests back to requirements.
 - Treat all planning documents as subordinate to `requirements.md`; if a planning document and the requirements differ, update the planning document.
+- Treat the local production-like developer environment and early UI delivery as non-optional delivery constraints, not optional polish.
diff --git a/docs/implementation-roadmap.md b/docs/implementation-roadmap.md
@@ -24,6 +24,7 @@ Deliverables:
 - internal API versioning convention
 - SignalR infrastructure
 - artefact storage abstraction
+- local production-like developer environment bootstrap
 - fixture app test harness
 - baseline observability and audit primitives
 - ADRs for generator choice, authentication provider, replay execution boundary, and draft persistence shape
@@ -40,20 +41,24 @@ Prove the end-to-end path from recording to generated code to replay on a simple
 
 Suggested slices:
 
-1. Recording session creation plus allow-list validation
-2. Playwright browser launch and recorder injection
-3. Meaningful event capture for navigation, click, fill, select, and checkbox
-4. Incremental recording persistence
-5. Initial timeline UI with human-readable steps
-6. Locator candidate creation and ranking
-7. Draft scenario editing and immutable version creation
-8. Deterministic C# generator for one profile
-9. Basic replay execution and step-level result reporting
+1. Local production-like developer startup workflow with Blazor UI and PostgreSQL
+2. Application shell and navigation suitable for visual testing
+3. Recording session creation plus allow-list validation
+4. Playwright browser launch and recorder injection
+5. Meaningful event capture for navigation, click, fill, select, and checkbox
+6. Incremental recording persistence
+7. Initial timeline UI with human-readable steps
+8. Locator candidate creation and ranking
+9. Draft scenario editing and immutable version creation
+10. Deterministic C# generator for one profile
+11. Basic replay execution and step-level result reporting
 
 Phase 1 exit should match Section 18.5 Phase 1 exit criteria.
 
 Phase 1 is not complete unless URL allow-list enforcement and encryption of stored auth/session material are demonstrably working, because they are part of the stated exit criteria rather than optional hardening.
 
+Phase 1 is also not complete unless a developer can run the real UI locally against a production-like stack shape and visually test the core workflow before push.
+
 ## 5. Phase 2: Robustness
 
 Objective:

diff --git a/docs/requirements-traceability-matrix.md b/docs/requirements-traceability-matrix.md
@@ -14,24 +14,25 @@ Use this document to keep future code changes, ADRs, test cases, and pull reques
 - [Security Plan](./security-plan.md)
 - [Testing Plan](./testing-plan.md)
 - [Implementation Roadmap](./implementation-roadmap.md)
+- [Sprint Plan](./sprint-plan.md)
 
 ## 3. Requirement Coverage Matrix
 
 | Requirement Area | Requirement Source | Primary Planning Docs |
 | --- | --- | --- |
 | Product intent and canonical scenario principle | Sections 1, 2, 7.1, 24 | Technical Specification, Implementation Roadmap |
-| Scope and phase boundaries | Sections 3, 18, 21 | Technical Specification, Implementation Roadmap |
+| Scope and phase boundaries | Sections 3, 18, 21 | Technical Specification, Implementation Roadmap, Sprint Plan |
 | Roles and primary use cases | Section 4 | UI/UX Plan, Technical Specification |
-| Logical architecture and lifecycles | Sections 5, 17 | Technical Specification, Implementation Roadmap |
+| Logical architecture and lifecycles | Sections 5, 17 | Technical Specification, Implementation Roadmap, Sprint Plan |
 | Technology stack and provider strategy | Section 6 | Technical Specification |
 | Domain entities and artefacts | Sections 7.2 through 7.5 | Technical Specification, Testing Plan |
-| Recording requirements | `FR-REC-001` through `FR-REC-010` | Technical Specification, UI/UX Plan, Security Plan, Testing Plan, Implementation Roadmap |
-| Inference requirements | `FR-INF-001` through `FR-INF-009` | Technical Specification, UI/UX Plan, Testing Plan |
-| Scenario authoring requirements | `FR-AUTH-001` through `FR-AUTH-006` | Technical Specification, UI/UX Plan, Testing Plan |
-| Generation requirements | `FR-GEN-001` through `FR-GEN-010` | Technical Specification, UI/UX Plan, Testing Plan, Implementation Roadmap |
-| Replay requirements | `FR-REP-001` through `FR-REP-005` | Technical Specification, UI/UX Plan, Security Plan, Testing Plan |
-| Healing requirements | `FR-HEAL-001` through `FR-HEAL-005` | Technical Specification, UI/UX Plan, Security Plan, Testing Plan, Implementation Roadmap |
-| Administration requirements | `FR-ADM-001` through `FR-ADM-004` | Technical Specification, UI/UX Plan, Security Plan, Testing Plan |
+| Recording requirements | `FR-REC-001` through `FR-REC-010` | Technical Specification, UI/UX Plan, Security Plan, Testing Plan, Implementation Roadmap, Sprint Plan |
+| Inference requirements | `FR-INF-001` through `FR-INF-009` | Technical Specification, UI/UX Plan, Testing Plan, Sprint Plan |
+| Scenario authoring requirements | `FR-AUTH-001` through `FR-AUTH-006` | Technical Specification, UI/UX Plan, Testing Plan, Sprint Plan |
+| Generation requirements | `FR-GEN-001` through `FR-GEN-010` | Technical Specification, UI/UX Plan, Testing Plan, Implementation Roadmap, Sprint Plan |
+| Replay requirements | `FR-REP-001` through `FR-REP-005` | Technical Specification, UI/UX Plan, Security Plan, Testing Plan, Sprint Plan |
+| Healing requirements | `FR-HEAL-001` through `FR-HEAL-005` | Technical Specification, UI/UX Plan, Security Plan, Testing Plan, Implementation Roadmap, Sprint Plan |
+| Administration requirements | `FR-ADM-001` through `FR-ADM-004` | Technical Specification, UI/UX Plan, Security Plan, Testing Plan, Sprint Plan |
 | UI requirements | Section 9 | UI/UX Plan, Technical Specification |
 | API and real-time requirements | Section 10 | Technical Specification, UI/UX Plan |
 | Configuration requirements | Section 11 | Technical Specification, Security Plan |
@@ -40,7 +41,8 @@ Use this document to keep future code changes, ADRs, test cases, and pull reques
 | Verification and testing requirements | Section 14 | Testing Plan |
 | Non-functional requirements | Section 15 | Technical Specification, UI/UX Plan, Testing Plan |
 | Deployment and operational safety | Section 16 | Technical Specification, Security Plan, Implementation Roadmap |
-| Acceptance criteria | Section 19 | Testing Plan, Technical Specification, Implementation Roadmap |
+| Local production-like developer environment and visual workflow validation | Sections 9.1, 14.1, 16.2, 18.1, 19 | Technical Specification, UI/UX Plan, Testing Plan, Implementation Roadmap, Sprint Plan |
+| Acceptance criteria | Section 19 | Testing Plan, Technical Specification, Implementation Roadmap, Sprint Plan |
 | Risks and constraints | Section 20 | Technical Specification, Implementation Roadmap |
 | Build, test, and delivery requirements | Section 22 | Testing Plan, Technical Specification, Security Plan |
 | Implementer guardrails | Section 23 | Security Plan, Technical Specification, Implementation Roadmap |
@@ -61,6 +63,7 @@ Use this document to keep future code changes, ADRs, test cases, and pull reques
 | Generated output remains reproducible | `FR-GEN-001`, `FR-GEN-010` | Technical Specification generation design, Testing Plan snapshot strategy |
 | Allow-list blocks disallowed targets | Section 12.4 | Security Plan allow-list control, Testing Plan allow-list tests |
 | Observability supports performance verification | Sections 13.1, 15.2 | Technical Specification observability design, Testing Plan performance instrumentation |
+| Developers can validate the real UI locally before push | Sections 9.1, 14.1, 16.2, 19 | UI/UX Plan local visual testing expectations, Testing Plan local validation environment, Sprint Plan sprint exit criteria |
 
 ## 5. Future Use
 

diff --git a/docs/requirements.md b/docs/requirements.md
@@ -13,6 +13,8 @@ The platform shall:
 - Generate readable C# Playwright test code and supporting assets from the scenario model.
 - Replay generated tests and attempt deterministic healing when selectors or data drift.
 - Preserve enough artefacts, metadata, and diagnostics to let users review, edit, approve, and regenerate scenarios over time.
+- Support a local, production-like developer environment so the full application can be exercised before changes are pushed or deployed.
+- Prioritise delivery of a usable Blazor Server UI early enough that major workflows can be visually tested throughout development, not only after backend completion.
 
 The platform shall be built with the following solution model:
 
@@ -75,6 +77,7 @@ The v1 platform shall support:
 - Deterministic selector healing workflows
 - Persistent storage of sessions, scenarios, steps, artefacts, and replay history
 - Multi-user authenticated web administration experience through Blazor Server
+- Local developer execution in a production-like stack shape suitable for pre-push and pre-deployment validation
 - Export of generated tests into repository-friendly file structures
 
 ### 3.2 Out of Scope for v1
@@ -1037,6 +1040,8 @@ The Blazor Server application shall provide at least these primary work areas:
 4. Replay and diagnostics workspace
 5. Administration area
 
+The UI shall be implemented early enough in the delivery plan that developers can visually exercise the primary workflows during development. API-only or backend-only completion is not sufficient for the intended v1 delivery workflow.
+
 ### 9.2 Recording Workspace
 
 The recording workspace shall display:
@@ -1248,6 +1253,8 @@ The platform implementation shall include automated coverage for:
 - Healing evaluation
 - Persistence mappings and migrations
 
+The implementation shall also support a local, production-like developer test environment so changes can be exercised end to end before they are pushed to GitHub or deployed. That local environment shall include the real Blazor UI, PostgreSQL, artefact storage, and representative fixture applications unless a specific component is intentionally stubbed for local-only ergonomics.
+
 ### 14.2 Test Layers
 
 At minimum, the repository should include:
@@ -1326,6 +1333,10 @@ The implementation shall support at least:
 - Shared non-production environment
 - Production-like server deployment
 
+The local developer execution profile shall mimic the actual application shape closely enough that a developer can validate the main workflows before pushing changes. At minimum, the local profile should run the ASP.NET Core host with the real Blazor Server UI, PostgreSQL, local artefact storage, and representative fixture applications or seeded test data.
+
+Differences between the local profile and shared/production-like environments shall be minimised and documented explicitly. Developer convenience shortcuts shall not bypass core safety behaviour such as allow-list enforcement, masking, audit logging, and encryption of sensitive stored material unless a local-only exception is intentionally documented and risk-accepted.
+
 ### 16.3 Packaging Direction
 
 Desktop packaging through .NET MAUI Hybrid or Electron is explicitly a future option. The initial architecture shall therefore keep the backend and UI boundaries clean enough that later packaging can host the same application surfaces without re-implementing core recording, generation, or replay services.
@@ -1369,8 +1380,9 @@ The application should be introduced into this repository as a new vertical slic
 
 Phase 1 shall target:
 
+- Local production-like developer environment bootstrap for safe pre-push validation
 - Recording of navigation, click, fill, select, checkbox, and simple assertion-relevant actions
-- Timeline UI
+- Timeline UI and core workflow surfaces sufficient for visual testing by developers
 - Locator ranking
 - Basic scenario persistence with immutable scenario version creation
 - C# Playwright generation
@@ -1416,6 +1428,7 @@ Phase 1 exit:
 - Generated C# Playwright output compiles against the emitted helper library.
 - Replay executes the generated scenario against the same fixture and reports pass/fail per step.
 - URL allow-list enforcement (Section 12.4) and encryption of storage state (Section 12.5) are enforced.
+- A developer can run a local, production-like environment with the Blazor UI and visually exercise the Phase 1 workflow before pushing changes.
 
 Phase 2 exit:
 - Assertion inference produces at least one outcome-oriented assertion suggestion for every save/submit/navigate step in the Phase 1 fixture library.
@@ -1447,6 +1460,7 @@ The implementation shall be considered to satisfy this specification only when a
 10. Generated output remains reproducible bit-for-bit (modulo timestamps declared as non-deterministic) from scenario data plus generation profile plus template version. [FR-GEN-001, FR-GEN-010]
 11. Recording and replay refuse to start against target URLs not present on the administrator-managed allow-list. [12.4]
 12. Observability emits the identifiers listed in 13.1 and permits verification of the performance targets in 15.2.
+13. A developer can run the application locally in a production-like configuration, including the real Blazor UI and PostgreSQL-backed persistence, to validate core workflows before push or deployment. [9.1, 14.1, 16.2]
 
 ## 20. Risks and Constraints
 
@@ -1492,6 +1506,7 @@ The test mining platform shall be introduced into this repository as a new verti
 - The solution shall build with the repository's documented required .NET SDK version. Any SDK upgrade shall be an explicit, documented change.
 - `dotnet restore`, `dotnet build`, and `dotnet test` shall succeed from a clean checkout with no unresolved warnings treated as errors in core projects.
 - Projects shall enable nullable reference types and treat analyzer warnings as errors where practical.
+- The repository should provide a documented local developer startup workflow for running a production-like application profile, including the Blazor UI and PostgreSQL dependency path.
 
 ### 22.3 Continuous Integration
 

diff --git a/docs/security-plan.md b/docs/security-plan.md
@@ -51,6 +51,8 @@ Recommended v1 approach:
 - shared environments: external identity provider via ASP.NET Core authentication
 - production-like environments: enforced external identity provider and secure cookie/session configuration
 
+The local developer environment should still exercise the real application shell and the core security-sensitive code paths wherever practical. Local convenience mode should reduce friction, not create a separate unrepresentative application path.
+
 ### 5.2 Authorization
 
 Minimum role model: