From e5413706c2e983ee00dc39bfc8d6da1f60b969d9 Mon Sep 17 00:00:00 2001
From: Dave Thomas <7sharp9@mail.com>
Date: Mon, 27 Jul 2026 15:35:26 +0100
Subject: [PATCH 1/2] fix(deps): decouple Build target from RestoreClient/Clean
 dependency chain

Is the commented-out server watch-test line in WatchTests (Build.fs:244, `dotnet [ "watch"; "run"; "--no-restore" ] serverTestsPath`) abandoned, or still intended to be finished?

If it's abandoned, we can drop WatchTests's dependency on Build too, it only runs the client Fable/Vite watcher, so nothing in it currently needs a server build.

If it's not dead, then we can to leave the Build dependency in place as it is in this PR, so it's still there when that line gets uncommented and adressed.
---
 Build.fs | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/Build.fs b/Build.fs
index 7e28f049..65e96834 100644
--- a/Build.fs
+++ b/Build.fs
@@ -285,11 +285,23 @@ open Fake.Core.TargetOperators
 
 let dependencies =
     [
-        "Clean" ==> "RestoreClient" ==> "Bundle"
-        "Clean" ==> "RestoreClient" ==> "Build" ==> "Run"
+        // Two independent prongs: a self-sufficient server build (Build restores
+        // and builds GenPRES.sln itself, no npm involved) and a client toolchain
+        // (Clean clears stale Fable/.jsx output, then RestoreClient runs npm ci).
+        // Each leaf target below declares only the prong(s) its body actually uses,
+        // rather than chaining everything through one sequence.
+        "Clean" ==> "RestoreClient"
 
-        "RestoreClient" ==> "Build" ==> "TestHeadless"
-        "RestoreClient" ==> "Build" ==> "WatchTests"
+        "RestoreClient" ==> "Bundle"
+
+        "Build" ==> "Run"
+        "RestoreClient" ==> "Run"
+
+        "Build" ==> "TestHeadless"
+        "RestoreClient" ==> "TestHeadless"
+
+        "Build" ==> "WatchTests"
+        "RestoreClient" ==> "WatchTests"
 
         "Build" ==> "ServerTests"
         "Build" ==> "CheckVersions"

From b1d8cb4eb239c9df5413a08fca63b1f934278ffb Mon Sep 17 00:00:00 2001
From: Dave Thomas <7sharp9@mail.com>
Date: Mon, 27 Jul 2026 16:02:16 +0100
Subject: [PATCH 2/2] docs(deps): sync dependency diagram with decoupled
 Build/RestoreClient graph

Build.fs's target graph was split into independent Build and RestoreClient parts in the previous commit, but DEVELOPMENT.md's dependency diagram and
the Run target's prose description still showed the old linear chain.

Update both to match, and add ServerTests/CheckVersions to the diagram.

Addresses Greptile review feedback on PR #426.
---
 DEVELOPMENT.md | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/DEVELOPMENT.md b/DEVELOPMENT.md
index a213c13d..a87b137e 100644
--- a/DEVELOPMENT.md
+++ b/DEVELOPMENT.md
@@ -49,8 +49,10 @@ dotnet run [target]
                        └─► executes each target step
 ```
 
-For example, `dotnet run` (no target) runs the `Run` target, which depends on:
-`Clean → RestoreClient → Build → Run` (server + Fable watcher in parallel).
+For example, `dotnet run` (no target) runs the `Run` target, which depends on
+two independent prerequisites: `Build` (compiles the server, no npm involved)
+and `Clean → RestoreClient` (clears stale Fable output, then restores npm
+packages for the Fable/Vite dev server).
 
 ### FAKE Build Targets Reference
 
@@ -72,12 +74,23 @@ For example, `dotnet run` (no target) runs the `Run` target, which depends on:
 
 ```text
 Clean ──► RestoreClient ──► Bundle
-Clean ──► RestoreClient ──► Build ──► Run
 
-RestoreClient ──► Build ──► TestHeadless
-RestoreClient ──► Build ──► WatchTests
+Build ──► Run
+RestoreClient ──► Run
+
+Build ──► TestHeadless
+RestoreClient ──► TestHeadless
+
+Build ──► WatchTests
+RestoreClient ──► WatchTests
+
+Build ──► ServerTests
+Build ──► CheckVersions
 ```
 
+`Build` and `RestoreClient` are independent prongs — a target that only needs
+one of them (e.g. `ServerTests`, `CheckVersions`) doesn't pay for the other.
+
 ### What Happens During `dotnet run` (the `Run` target)
 
 The `Run` target starts two long-running processes **in parallel**: