diff --git a/checkpoint.json b/checkpoint.json
new file mode 100644
index 000000000..4408345bd
--- /dev/null
+++ b/checkpoint.json
@@ -0,0 +1,57 @@
+{
+  "timestamp": "2026-03-16T12:01:31.984766Z",
+  "current_node": "setup",
+  "completed_nodes": [
+    "start",
+    "setup"
+  ],
+  "node_retries": {
+    "start": 1,
+    "setup": 1
+  },
+  "context_values": {
+    "internal.fidelity": "compact",
+    "outcome": "fail",
+    "internal.thread_id": "start",
+    "failure_class": "deterministic",
+    "graph.goal": "Add support for SCRIPT_NAME in STATIC_URL and MEDIA_URL\nDescription\n\t \n\t\t(last modified by Rostyslav Bryzgunov)\n\t \nBy default, {% static '...' %} tag just appends STATIC_URL in the path. When running on sub-path, using SCRIPT_NAME WSGI param, it results in incorrect static URL - it doesn't prepend SCRIPT_NAME prefix.\nThis problem can be solved with prepending SCRIPT_NAME to STATIC_URL in settings.py but that doesn't work when SCRIPT_NAME is a dynamic value.\nThis can be easily added into default Django static tag and django.contrib.staticfiles tag as following:\ndef render(self, context):\n\turl = self.url(context)\n\t# Updating url here with request.META['SCRIPT_NAME'] \n\tif self.varname is None:\n\t\treturn url\n\tcontext[self.varname] = url\n\t\treturn ''\nOn more research I found that FileSystemStorage and StaticFilesStorage ignores SCRIPT_NAME as well. \nWe might have to do a lot of changes but I think it's worth the efforts.\n\n\n\n## Additional Context\n\nThis change doesn't seem correct to me (for one, it seems like it could break existing sites). Why not include the appropriate prefix in your STATIC_URL and MEDIA_URL settings?\nThis is not a patch. This is just an idea I got about the patch for {% static %} only. The patch will (probably) involve FileSystemStorage and StaticFileSystemStorage classes. The main idea behind this feature was that Django will auto detect script_name header and use that accordingly for creating static and media urls. This will reduce human efforts for setting up sites in future. This patch will also take time to develop so it can be added in Django2.0 timeline.\nWhat I meant was that I don't think Django should automatically use SCRIPT_NAME in generating those URLs. If you're running your site on a subpath, then you should set your STATIC_URL to '​http://example.com/subpath/static/' or whatever. However, you might not even be hosting static and uploaded files on the same domain as your site (in fact, for user-uploaded files, you shouldn't do that ​for security reasons) in which case SCRIPT_URL is irrelevant in constructing the static/media URLs. How would the change make it easier to setup sites?\nI think that the idea basically makes sense. Ideally, a Django instance shouldn't need to know at which subpath it is being deployed, as this can be considered as purely sysadmin stuff. It would be a good separation of concerns. For example, the Web administrator may change the WSGIScriptAlias from /foo to /bar and the application should continue working. Of course, this only applies when *_URL settings are not full URIs. In practice, it's very likely that many running instances are adapting their *_URL settings to include the base script path, hence the behavior change would be backwards incompatible. The question is whether the change is worth the incompatibility.\nI see. I guess the idea would be to use get_script_prefix() like reverse() does as I don't think we have access to request everywhere we need it. It seems like some public APIs like get_static_url() and get_media_url() would replace accessing the settings directly whenever building URLs. For backwards compatibility, possibly these functions could try to detect if the setting is already prefixed appropriately. Removing the prefix from the settings, however, means that the URLs are no longer correct when generated outside of a request/response cycle though (#16734). I'm not sure if it might create any practical problems, but we might think about addressing that issue first.\nI'm here at DjangoCon US 2016 will try to create a patch for this ticket ;) Why? But before I make the patch, here are some reasons to do it. The first reason is consistency inside Django core: {% url '...' %} template tag does respect SCRIPT_NAME but {% static '...' %} does not reverse(...) function does respect SCRIPT_NAME but static(...) does not And the second reason is that there is no way to make it work in case when SCRIPT_NAME is a dynamic value - see an example below. Of course we shouldn't modify STATIC_URL when it's an absolute URL, with domain & protocol. But if it starts with / - it's relative to our Django project and we need to add SCRIPT_NAME prefix. Real life example You have Django running via WSGI behind reverse proxy (let's call it back-end server), and another HTTP server on the front (let's call it front-end server). Front-end server URL is http://some.domain.com/sub/path/, back-end server URL is http://1.2.3.4:5678/. You want them both to work. You pass SCRIPT_NAME = '/sub/path/' from front-end server to back-end one. But when you access back-end server directly - there is no SCRIPT_NAME passed to WSGI/Django. So we cannot hard-code SCRIPT_NAME in Django settings because it's dynamic.\nPull-request created: ​https://github.com/django/django/pull/7000\nAt least documentation and additional tests look like they are required.\nAbsolutely agree with your remarks, Tim. I'll add tests. Could you point to docs that need to be updated?\nI would like to take this ticket on and have a new PR for it: ​https://github.com/django/django/pull/10724",
+    "command.output": "fatal: destination path '.' already exists and is not an empty directory.\n",
+    "internal.node_visit_count": 1,
+    "internal.retry_count.start": 1,
+    "graph.rankdir": "LR",
+    "failure_signature": "setup|deterministic|script failed with exit code: <n> ## stdout fatal: destination path '.' already exists and is not an empty directory.",
+    "current.preamble": "Goal: Add support for SCRIPT_NAME in STATIC_URL and MEDIA_URL\nDescription\n\t \n\t\t(last modified by Rostyslav Bryzgunov)\n\t \nBy default, {% static '...' %} tag just appends STATIC_URL in the path. When running on sub-path, using SCRIPT_NAME WSGI param, it results in incorrect static URL - it doesn't prepend SCRIPT_NAME prefix.\nThis problem can be solved with prepending SCRIPT_NAME to STATIC_URL in settings.py but that doesn't work when SCRIPT_NAME is a dynamic value.\nThis can be easily added into default Django static tag and django.contrib.staticfiles tag as following:\ndef render(self, context):\n\turl = self.url(context)\n\t# Updating url here with request.META['SCRIPT_NAME'] \n\tif self.varname is None:\n\t\treturn url\n\tcontext[self.varname] = url\n\t\treturn ''\nOn more research I found that FileSystemStorage and StaticFilesStorage ignores SCRIPT_NAME as well. \nWe might have to do a lot of changes but I think it's worth the efforts.\n\n\n\n## Additional Context\n\nThis change doesn't seem correct to me (for one, it seems like it could break existing sites). Why not include the appropriate prefix in your STATIC_URL and MEDIA_URL settings?\nThis is not a patch. This is just an idea I got about the patch for {% static %} only. The patch will (probably) involve FileSystemStorage and StaticFileSystemStorage classes. The main idea behind this feature was that Django will auto detect script_name header and use that accordingly for creating static and media urls. This will reduce human efforts for setting up sites in future. This patch will also take time to develop so it can be added in Django2.0 timeline.\nWhat I meant was that I don't think Django should automatically use SCRIPT_NAME in generating those URLs. If you're running your site on a subpath, then you should set your STATIC_URL to '​http://example.com/subpath/static/' or whatever. However, you might not even be hosting static and uploaded files on the same domain as your site (in fact, for user-uploaded files, you shouldn't do that ​for security reasons) in which case SCRIPT_URL is irrelevant in constructing the static/media URLs. How would the change make it easier to setup sites?\nI think that the idea basically makes sense. Ideally, a Django instance shouldn't need to know at which subpath it is being deployed, as this can be considered as purely sysadmin stuff. It would be a good separation of concerns. For example, the Web administrator may change the WSGIScriptAlias from /foo to /bar and the application should continue working. Of course, this only applies when *_URL settings are not full URIs. In practice, it's very likely that many running instances are adapting their *_URL settings to include the base script path, hence the behavior change would be backwards incompatible. The question is whether the change is worth the incompatibility.\nI see. I guess the idea would be to use get_script_prefix() like reverse() does as I don't think we have access to request everywhere we need it. It seems like some public APIs like get_static_url() and get_media_url() would replace accessing the settings directly whenever building URLs. For backwards compatibility, possibly these functions could try to detect if the setting is already prefixed appropriately. Removing the prefix from the settings, however, means that the URLs are no longer correct when generated outside of a request/response cycle though (#16734). I'm not sure if it might create any practical problems, but we might think about addressing that issue first.\nI'm here at DjangoCon US 2016 will try to create a patch for this ticket ;) Why? But before I make the patch, here are some reasons to do it. The first reason is consistency inside Django core: {% url '...' %} template tag does respect SCRIPT_NAME but {% static '...' %} does not reverse(...) function does respect SCRIPT_NAME but static(...) does not And the second reason is that there is no way to make it work in case when SCRIPT_NAME is a dynamic value - see an example below. Of course we shouldn't modify STATIC_URL when it's an absolute URL, with domain & protocol. But if it starts with / - it's relative to our Django project and we need to add SCRIPT_NAME prefix. Real life example You have Django running via WSGI behind reverse proxy (let's call it back-end server), and another HTTP server on the front (let's call it front-end server). Front-end server URL is http://some.domain.com/sub/path/, back-end server URL is http://1.2.3.4:5678/. You want them both to work. You pass SCRIPT_NAME = '/sub/path/' from front-end server to back-end one. But when you access back-end server directly - there is no SCRIPT_NAME passed to WSGI/Django. So we cannot hard-code SCRIPT_NAME in Django settings because it's dynamic.\nPull-request created: ​https://github.com/django/django/pull/7000\nAt least documentation and additional tests look like they are required.\nAbsolutely agree with your remarks, Tim. I'll add tests. Could you point to docs that need to be updated?\nI would like to take this ticket on and have a new PR for it: ​https://github.com/django/django/pull/10724\n",
+    "command.stderr": "",
+    "internal.run_id": "01KKV8BF6PWB0V169ZXCH11Q5B",
+    "thread.start.current_node": "setup",
+    "internal.retry_count.setup": 1,
+    "current_node": "setup"
+  },
+  "logs": [],
+  "node_outcomes": {
+    "start": {
+      "status": "success",
+      "duration_ms": 0
+    },
+    "setup": {
+      "status": "fail",
+      "context_updates": {
+        "command.output": "fatal: destination path '.' already exists and is not an empty directory.\n",
+        "command.stderr": ""
+      },
+      "failure": {
+        "message": "Script failed with exit code: 128\n\n## stdout\nfatal: destination path '.' already exists and is not an empty directory.\n",
+        "failure_class": "deterministic"
+      },
+      "duration_ms": 83
+    }
+  },
+  "next_node_id": "solve",
+  "loop_failure_signatures": {
+    "setup|deterministic|script failed with exit code: <n> ## stdout fatal: destination path '.' already exists and is not an empty directory.": 1
+  },
+  "node_visits": {
+    "setup": 1,
+    "start": 1
+  }
+}
\ No newline at end of file
diff --git a/nodes/setup/script_invocation.json b/nodes/setup/script_invocation.json
new file mode 100644
index 000000000..c3c2359e7
--- /dev/null
+++ b/nodes/setup/script_invocation.json
@@ -0,0 +1,5 @@
+{
+  "command": "git clone https://github.com/django/django.git . && git checkout 580e644f24f1c5ae5b94784fb73a9953a178fd26 && python -m pip install -e .",
+  "language": "shell",
+  "timeout_ms": null
+}
\ No newline at end of file
diff --git a/nodes/setup/script_timing.json b/nodes/setup/script_timing.json
new file mode 100644
index 000000000..67a134f5e
--- /dev/null
+++ b/nodes/setup/script_timing.json
@@ -0,0 +1,5 @@
+{
+  "duration_ms": 82,
+  "exit_code": 128,
+  "timed_out": false
+}
\ No newline at end of file
diff --git a/nodes/setup/status.json b/nodes/setup/status.json
new file mode 100644
index 000000000..a20158d66
--- /dev/null
+++ b/nodes/setup/status.json
@@ -0,0 +1,6 @@
+{
+  "status": "fail",
+  "notes": null,
+  "failure_reason": "Script failed with exit code: 128\n\n## stdout\nfatal: destination path '.' already exists and is not an empty directory.\n",
+  "timestamp": "2026-03-16T12:01:31.984557+00:00"
+}
\ No newline at end of file
diff --git a/nodes/start/status.json b/nodes/start/status.json
new file mode 100644
index 000000000..fe77e37cf
--- /dev/null
+++ b/nodes/start/status.json
@@ -0,0 +1,6 @@
+{
+  "status": "success",
+  "notes": null,
+  "failure_reason": null,
+  "timestamp": "2026-03-16T12:01:31.900220+00:00"
+}
\ No newline at end of file