Integrate purpose, scope, and research context in technical paper

downloads/ARC-Explorer-v0.1-ACM-source.zip

@@ -1,3 +1,3 @@
 version https://git-lfs.github.com/spec/v1
-oid sha256:1e24afe007d9159d6600498c2d0397b366501a3fa8a739452d60b423895d1b40
-size 4023823
+oid sha256:23de6b808c9331f6f79981e236422888dcb914ca5b49249ff772780cde42ddd4
+size 4023683

downloads/ARC-Explorer-v0.1-source.zip

@@ -1,3 +1,3 @@
 version https://git-lfs.github.com/spec/v1
-oid sha256:bae7d883a808fc1a5416032a6f89730d022665688a812e9e2a301a14af619cb9
-size 9655855
+oid sha256:d13f975c5a07bb1a59ab7b041d7e0a4167c502c299aaac8d83d9db9b46907c16
+size 9655715

downloads/ARC-Explorer.pdf

@@ -1,3 +1,3 @@
 version https://git-lfs.github.com/spec/v1
-oid sha256:1ea2891a8ec083b16288d3bbee0ae8cae7dfa03f4d981f28cd4ca2a3fe6c34a0
-size 2109021
+oid sha256:be6453bac972eb260c9b91b247714b83b70b2826017007e3b8453d98f3e4be7f
+size 2108767

downloads/ARC-Explorer.tex

@@ -32,19 +32,15 @@ ARC Explorer is a native macOS application that brings connection profiles, reso
 \keywords{high-performance computing, Slurm, SSH, macOS, scientific gateways, remote development}
 \maketitle
 
-\section{Motivation and context}
+\section{Purpose and Research Context}
 
-Researchers using a shared cluster must coordinate several interfaces: SSH authentication, scheduler commands, allocation and storage reports, source repositories, text editors, interactive notebooks, and service documentation. ARC Explorer groups these operations around a saved cluster profile and an explicit resource request. The goal is to reduce interface switching while keeping the underlying commands, execution locations, and resource decisions visible.
+Working on a shared cluster requires coordination across authentication, scheduler commands, allocation and storage reports, source repositories, editors, notebooks, and service documentation. ARC Explorer brings these activities into a native macOS workspace organized around a saved cluster profile and an explicit resource request. Its purpose is to reduce interface switching while keeping commands, execution locations, and resource decisions visible to the researcher.
 
-Web gateways already provide broad access to high-performance computing. Open OnDemand is an established portal architecture for HPC centers \cite{hudak2018}, and ARC documents its deployment for files, jobs, shells, and interactive applications \cite{arcood}. ARC Explorer complements that infrastructure with a native desktop workspace, an embedded browser, a terminal, and local document dialogs. It does not replace the scheduler, identity provider, allocation service, or Open OnDemand deployment. No comparative usability advantage is asserted.
+This design extends an established ecosystem of HPC access tools. Open OnDemand provides a web-based portal architecture for HPC centers \cite{hudak2018}, and ARC documents its deployment for files, jobs, shells, and interactive applications \cite{arcood}. ARC Explorer combines an embedded browser, terminal, and local document dialogs with that infrastructure. Its desktop workflow complements the portal while continuing to rely on the cluster's identity, allocation, scheduling, and interactive-service mechanisms; comparative usability benefits remain to be evaluated.
 
-The scheduler remains the authority on resource allocation. Slurm exposes submission, queue inspection, accounting, and cancellation through established commands \cite{slurm}. The application translates form values into explicit scheduler arguments rather than implementing its own queue. ARC's login-node guidance constrains the intended use of interactive commands \cite{arcpolicy}. The distinction between management and compute is therefore part of both the interface and the implementation, although the general terminal cannot enforce that distinction.
+The boundary between requesting resources and receiving an allocation is fundamental to this workflow. The original Slurm paper describes scheduling and resource management as cluster services \cite{slurmpaper}, and Slurm's command interface exposes submission, queue inspection, accounting, and cancellation \cite{slurm}. ARC Explorer translates form values into explicit scheduler arguments so a request can be inspected and saved. The scheduler determines whether and when those resources become available. ARC's login-node guidance also shapes the interface's distinction between management commands and compute jobs \cite{arcpolicy}, although a general-purpose terminal cannot enforce that policy by itself.
 
-\subsection{Research context}
-
-The original Slurm paper describes resource management and scheduling as services of the cluster infrastructure \cite{slurmpaper}. This provides the architectural basis for keeping a desktop client's resource form separate from the scheduler that grants and enforces an allocation. A submitted request is therefore an auditable specification of desired resources, not proof of their availability.
-
-Research on Jupyter notebooks treats executable code, results, and explanatory prose as a shared publication artifact \cite{notebooks}. ARC Explorer's embedded notebook access supports that workflow, while the notebook server and compute allocation retain their own lifecycles. Peng's account of reproducible computational research emphasizes access to the computational artifacts needed to inspect a result \cite{repro}. The FAIR principles additionally distinguish findability, accessibility, interoperability, and reuse \cite{fair}. These perspectives motivate saving scripts, resource settings, environment information, and outputs together. They do not establish that a GUI, a saved script, or an exported log by itself makes an experiment reproducible or FAIR-compliant.
+A unified workspace is useful only if it also helps users retain the context of their computation. Jupyter notebooks connect executable code, results, and explanatory prose in a shared artifact \cite{notebooks}; ARC Explorer supports access to that workflow while notebook servers and compute allocations retain separate lifecycles. Peng's account of reproducible computational research emphasizes making computational artifacts available for inspection \cite{repro}, and the FAIR principles distinguish findability, accessibility, interoperability, and reuse \cite{fair}. These perspectives motivate keeping scripts, resource settings, environments, and outputs together. The report describes how the application supports those practices without treating the GUI or any individual saved artifact as sufficient evidence of reproducibility or FAIR compliance.
 
 \section{Architecture and execution boundaries}
 

downloads/SHA256SUMS.txt

@@ -1,8 +1,8 @@
-1e24afe007d9159d6600498c2d0397b366501a3fa8a739452d60b423895d1b40  ARC-Explorer-v0.1-ACM-source.zip
+23de6b808c9331f6f79981e236422888dcb914ca5b49249ff772780cde42ddd4  ARC-Explorer-v0.1-ACM-source.zip
 d191bfec4f50e94616f619a626f0e57a88a6b19d2d2690a54b339c33e83cc72d  ARC-Explorer-v0.1-macOS-arm64.zip
-bae7d883a808fc1a5416032a6f89730d022665688a812e9e2a301a14af619cb9  ARC-Explorer-v0.1-source.zip
-1ea2891a8ec083b16288d3bbee0ae8cae7dfa03f4d981f28cd4ca2a3fe6c34a0  ARC-Explorer.pdf
-0561fe3fcb5f9c4b5eba4c89f13162fcb5112a226556522b9219bd3e8a7e658a  ARC-Explorer.tex
+d13f975c5a07bb1a59ab7b041d7e0a4167c502c299aaac8d83d9db9b46907c16  ARC-Explorer-v0.1-source.zip
+be6453bac972eb260c9b91b247714b83b70b2826017007e3b8453d98f3e4be7f  ARC-Explorer.pdf
+b40408053169d2d6cae18eb1f24358efbfe7362e8810db1163961ec19c678550  ARC-Explorer.tex
 b91fde80a00748a7c4aa1bae38c1393d56205b0e477eb53acce4b0af75af73c1  RELEASE_MANIFEST.json
-e93a5a4af77533ff1da497292b6d9e994adda755a857aa46df21c1686527efc6  TECHNICAL_PAPER.md
+bb06f1e946e814ed8e7789742c13ea64b5b23e8302366d677efeb97c7e4d294c  TECHNICAL_PAPER.md
 8df9e079ac82197144422a3cd584a6737fafbe56047bbfb1d56f26da661c7cde  references.bib

downloads/TECHNICAL_PAPER.md

@@ -10,21 +10,17 @@ Technical report · ARC Explorer v0.1 · November 13, 2026
 
 ARC Explorer is a native macOS application that brings connection profiles, resource inspection, allocation accounting, GPU job submission, remote files, terminal sessions, web applications, and language-model assistance into one workspace for Virginia Tech Advanced Research Computing (ARC). The client combines SwiftUI, AppKit, WebKit, the system SSH client, and a small remote Python helper. Computational scripts are submitted to Slurm with explicit resource requests, while an integrated login-node terminal supports direct interactive administration. Five main sections organize the workflow: Connection, Resources, Jobs + software, Sessions, and Help. This report describes the implementation, file-editing safeguards, credential boundaries, installation workflow, and release validation. Twenty-eight Python tests and two native terminal tests pass for the release candidate. The evidence establishes functional checks of selected paths, not a performance benchmark, independent security audit, or guarantee of compatibility with every ARC service. Five application screenshots illustrate the workspace.
 
-## 1. Motivation and context
+## Purpose and Research Context
 
-Researchers using a shared cluster must coordinate several interfaces: SSH authentication, scheduler commands, allocation and storage reports, source repositories, text editors, interactive notebooks, and service documentation. ARC Explorer groups these operations around a saved cluster profile and an explicit resource request. The goal is to reduce interface switching while keeping the underlying commands, execution locations, and resource decisions visible.
+Working on a shared cluster requires coordination across authentication, scheduler commands, allocation and storage reports, source repositories, editors, notebooks, and service documentation. ARC Explorer brings these activities into a native macOS workspace organized around a saved cluster profile and an explicit resource request. Its purpose is to reduce interface switching while keeping commands, execution locations, and resource decisions visible to the researcher.
 
-Web gateways already provide broad access to high-performance computing. Open OnDemand is an established portal architecture for HPC centers [@hudak2018], and ARC documents its deployment for files, jobs, shells, and interactive applications [@arcood]. ARC Explorer complements that infrastructure with a native desktop workspace, an embedded browser, a terminal, and local document dialogs. It does not replace the scheduler, identity provider, allocation service, or Open OnDemand deployment. No comparative usability advantage is asserted.
+This design extends an established ecosystem of HPC access tools. Open OnDemand provides a web-based portal architecture for HPC centers ([Hudak et al., 2018](https://doi.org/10.21105/joss.00622)), and ARC documents its deployment for files, jobs, shells, and interactive applications ([Computing, n.d.](https://www.docs.arc.vt.edu/resources/ood.html)). ARC Explorer combines an embedded browser, terminal, and local document dialogs with that infrastructure. Its desktop workflow complements the portal while continuing to rely on the cluster's identity, allocation, scheduling, and interactive-service mechanisms; comparative usability benefits remain to be evaluated.
 
-The scheduler remains the authority on resource allocation. Slurm exposes submission, queue inspection, accounting, and cancellation through established commands [@slurm]. The application translates form values into explicit scheduler arguments rather than implementing its own queue. ARC's login-node guidance constrains the intended use of interactive commands [@arcpolicy]. The distinction between management and compute is therefore part of both the interface and the implementation, although the general terminal cannot enforce that distinction.
+The boundary between requesting resources and receiving an allocation is fundamental to this workflow. The original Slurm paper describes scheduling and resource management as cluster services ([Yoo et al., 2003](https://doi.org/10.1007/10968987_3)), and Slurm's command interface exposes submission, queue inspection, accounting, and cancellation ([SchedMD, n.d.](https://slurm.schedmd.com/documentation.html)). ARC Explorer translates form values into explicit scheduler arguments so a request can be inspected and saved. The scheduler determines whether and when those resources become available. ARC's login-node guidance also shapes the interface's distinction between management commands and compute jobs ([Computing, n.d.](https://www.docs.arc.vt.edu/usage/abuse.html)), although a general-purpose terminal cannot enforce that policy by itself.
 
-### Research context
+A unified workspace is useful only if it also helps users retain the context of their computation. Jupyter notebooks connect executable code, results, and explanatory prose in a shared artifact ([Kluyver et al., 2016](https://doi.org/10.3233/978-1-61499-649-1-87)); ARC Explorer supports access to that workflow while notebook servers and compute allocations retain separate lifecycles. Peng's account of reproducible computational research emphasizes making computational artifacts available for inspection ([Peng, 2011](https://doi.org/10.1126/science.1213847)), and the FAIR principles distinguish findability, accessibility, interoperability, and reuse ([Wilkinson et al., 2016](https://doi.org/10.1038/sdata.2016.18)). These perspectives motivate keeping scripts, resource settings, environments, and outputs together. The report describes how the application supports those practices without treating the GUI or any individual saved artifact as sufficient evidence of reproducibility or FAIR compliance.
 
-The original Slurm paper describes resource management and scheduling as services of the cluster infrastructure [SLURM: Simple Linux Utility for Resource Management](https://doi.org/10.1007/10968987_3). This provides the architectural basis for keeping a desktop client's resource form separate from the scheduler that grants and enforces an allocation. A submitted request is therefore an auditable specification of desired resources, not proof of their availability.
-
-Research on Jupyter notebooks treats executable code, results, and explanatory prose as a shared publication artifact [Jupyter Notebooks—a publishing format for reproducible computational workflows](https://doi.org/10.3233/978-1-61499-649-1-87). ARC Explorer's embedded notebook access supports that workflow, while the notebook server and compute allocation retain their own lifecycles. Peng's account of reproducible computational research emphasizes access to the computational artifacts needed to inspect a result [Reproducible Research in Computational Science](https://doi.org/10.1126/science.1213847). The FAIR principles additionally distinguish findability, accessibility, interoperability, and reuse [The FAIR Guiding Principles for scientific data management and stewardship](https://doi.org/10.1038/sdata.2016.18). These perspectives motivate saving scripts, resource settings, environment information, and outputs together. They do not establish that a GUI, a saved script, or an exported log by itself makes an experiment reproducible or FAIR-compliant.
-
-## 2. Architecture and execution boundaries
+## Architecture and execution boundaries
 
 The desktop application targets Apple Silicon Macs running macOS 15 or later. SwiftUI provides the workspace and forms; AppKit supplies native dialogs and terminal integration; WebKit renders web services. The application calls the macOS system SSH executable. It does not require a separately installed local Python interpreter, browser engine, or model weights. A system browser remains available as an alternative for web authentication and applications.
 
@@ -36,7 +32,7 @@ The remote helper is itself a Python process on the login node. ARC's published
 
 Nonsecret connection preferences, appearance, bookmarks, and workspace state are stored locally. Profiles contain connection and resource settings, not SSH passwords or private-key material. The local workspace preserves drafts for convenience; it is not a transaction log or a substitute for saving important scripts and files.
 
-## 3. Connection: profiles and authentication
+## Connection: profiles and authentication
 
 The Connection section presents saved profiles, host and port fields, a Virginia Tech PID, authentication mode, private-key path, and remote workspace location. Presets cover TinkerCliffs, Falcon, and Owl; a custom host can be entered. The selected profile also carries the account and resource preferences used by subsequent jobs. A preset is a convenience, not evidence that the host or a GPU partition is currently available.
 
@@ -48,7 +44,7 @@ Light mode is the default, with an explicit dark-mode option. The header uses a
 
 ![Connection section showing the saved profile and SSH form. Offline capture of the signed v0.1 build; no password, API key, or private-key contents are shown.](../paper/figures/01-connection.png)
 
-## 4. Resources: availability, accounting, and remote files
+## Resources: availability, accounting, and remote files
 
 Availability queries inspect cluster partitions, user associations, and storage information through the connected host. The application also opens ARC's all-cluster dashboards at the kiosk dashboard URL. These observations describe current or reported state; they neither reserve capacity nor predict queue time.
 
@@ -62,7 +58,7 @@ An opened file is associated with a revision derived from its content hash, devi
 
 ![Cropped detail of the remote file browser and lightweight text editor. This offline view illustrates the editing controls, not an active file transaction.](../paper/figures/06-file-editor.png)
 
-## 5. Jobs + software: resource requests and reproducible scripts
+## Jobs + software: resource requests and reproducible scripts
 
 The GPU request form exposes allocation, partition, wall time, GPU count, CPU count, memory, and working directory. Version 0.1 accepts one to eight GPUs, one to 256 CPUs, and one to 2,048 GiB-equivalent Slurm memory units expressed with the G suffix. These are client validation bounds, not promises that a partition supports every combination. Users must choose values allowed by their account and the selected partition.
 
@@ -78,7 +74,7 @@ Repository retrieval does not automatically run arbitrary setup instructions. Th
 
 ![Jobs + software showing explicit GPU resources and the editable script. The example script has not been submitted in this offline screenshot.](../paper/figures/03-jobs-software.png)
 
-## 6. Sessions: terminal, web applications, and tunnels
+## Sessions: terminal, web applications, and tunnels
 
 Sessions opens to the Login Node Terminal by default. The terminal occupies the available workspace width and accepts input directly at the shell prompt. SwiftTerm supplies terminal emulation [@swiftterm], connected to a local pseudo-terminal and the system SSH client, which requests a remote pseudo-terminal and an interactive login shell. Input, ANSI output, history keys, tab completion, interrupts, copying, pasting, and window-size changes follow the terminal session rather than a separate command-entry field. The scrollback limit is 5,000 lines.
 
@@ -92,7 +88,7 @@ For an existing service on an allocated compute node, a tunnel maps a local loop
 
 ![Sessions with the full-width Login Node Terminal controls, upper terminal pane, and red compute warning. The terminal is disconnected in this capture.](../paper/figures/04-sessions.png)
 
-## 7. Help: command reference and ARC-hosted language models
+## Help: command reference and ARC-hosted language models
 
 The Help section combines a fixed command reference with an optional ARC-hosted LLM assistant. The command reference includes partition inspection, queue and history queries, account associations, module discovery, and storage commands. A command can be copied or placed into the GPU script editor for review. This exposes the actual command syntax and keeps execution separate from explanation.
 
@@ -104,7 +100,7 @@ The transport requires HTTPS and refuses HTTP redirects, preventing automatic fo
 
 ![Help section with the ARC API configuration, model field, and question editor. The API key is empty; no live response is claimed.](../paper/figures/05-help.png)
 
-## 8. Verification, distribution, and reproducibility
+## Verification, distribution, and reproducibility
 
 The v0.1 release build passes 28 Python tests and two Swift terminal tests. Python coverage includes resource validation, rejection of malformed identifiers, submission through sbatch rather than login-shell script execution, ownership checks for cancellation, independent report failures, repository-update guards, transfer bounds, and remote editor conflicts. File tests exercise Unicode, byte-order marks, CRLF preservation, permission preservation, binary rejection, link rejection, exclusive creation, and cleanup after a detected save conflict.
 
@@ -116,7 +112,7 @@ The source distribution includes the Swift application, remote helper, native as
 
 The application and its helper are signed with a Developer ID Application identity and hardened runtime. The release workflow submits an archive to Apple's notarization service, staples an accepted ticket to the app, and verifies the resulting bundle before creating the downloadable ZIP. Notarization is a distribution check rather than a certification of the scientific workflow or a functional test. The release manifest records the actual notarization state and artifact checksums; source rebuilds require the builder's own signing identity and credentials for a separately notarized distribution.
 
-## 9. Limitations and future work
+## Limitations and future work
 
 ARC Explorer is experimental research software and an independent client, not an official replacement for ARC documentation or support. Partition names, command availability, API models, quotas, and site policies change. Query results depend on user permissions and may be incomplete. The interface can connect to a custom host, but the management helper assumes a compatible shell, Python 3, and Slurm environment.
 

paper/ARC-Explorer.pdf

@@ -1,3 +1,3 @@
 version https://git-lfs.github.com/spec/v1
-oid sha256:1ea2891a8ec083b16288d3bbee0ae8cae7dfa03f4d981f28cd4ca2a3fe6c34a0
-size 2109021
+oid sha256:be6453bac972eb260c9b91b247714b83b70b2826017007e3b8453d98f3e4be7f
+size 2108767

paper/ARC-Explorer.tex

@@ -32,19 +32,15 @@ ARC Explorer is a native macOS application that brings connection profiles, reso
 \keywords{high-performance computing, Slurm, SSH, macOS, scientific gateways, remote development}
 \maketitle
 
-\section{Motivation and context}
+\section{Purpose and Research Context}
 
-Researchers using a shared cluster must coordinate several interfaces: SSH authentication, scheduler commands, allocation and storage reports, source repositories, text editors, interactive notebooks, and service documentation. ARC Explorer groups these operations around a saved cluster profile and an explicit resource request. The goal is to reduce interface switching while keeping the underlying commands, execution locations, and resource decisions visible.
+Working on a shared cluster requires coordination across authentication, scheduler commands, allocation and storage reports, source repositories, editors, notebooks, and service documentation. ARC Explorer brings these activities into a native macOS workspace organized around a saved cluster profile and an explicit resource request. Its purpose is to reduce interface switching while keeping commands, execution locations, and resource decisions visible to the researcher.
 
-Web gateways already provide broad access to high-performance computing. Open OnDemand is an established portal architecture for HPC centers \cite{hudak2018}, and ARC documents its deployment for files, jobs, shells, and interactive applications \cite{arcood}. ARC Explorer complements that infrastructure with a native desktop workspace, an embedded browser, a terminal, and local document dialogs. It does not replace the scheduler, identity provider, allocation service, or Open OnDemand deployment. No comparative usability advantage is asserted.
+This design extends an established ecosystem of HPC access tools. Open OnDemand provides a web-based portal architecture for HPC centers \cite{hudak2018}, and ARC documents its deployment for files, jobs, shells, and interactive applications \cite{arcood}. ARC Explorer combines an embedded browser, terminal, and local document dialogs with that infrastructure. Its desktop workflow complements the portal while continuing to rely on the cluster's identity, allocation, scheduling, and interactive-service mechanisms; comparative usability benefits remain to be evaluated.
 
-The scheduler remains the authority on resource allocation. Slurm exposes submission, queue inspection, accounting, and cancellation through established commands \cite{slurm}. The application translates form values into explicit scheduler arguments rather than implementing its own queue. ARC's login-node guidance constrains the intended use of interactive commands \cite{arcpolicy}. The distinction between management and compute is therefore part of both the interface and the implementation, although the general terminal cannot enforce that distinction.
+The boundary between requesting resources and receiving an allocation is fundamental to this workflow. The original Slurm paper describes scheduling and resource management as cluster services \cite{slurmpaper}, and Slurm's command interface exposes submission, queue inspection, accounting, and cancellation \cite{slurm}. ARC Explorer translates form values into explicit scheduler arguments so a request can be inspected and saved. The scheduler determines whether and when those resources become available. ARC's login-node guidance also shapes the interface's distinction between management commands and compute jobs \cite{arcpolicy}, although a general-purpose terminal cannot enforce that policy by itself.
 
-\subsection{Research context}
-
-The original Slurm paper describes resource management and scheduling as services of the cluster infrastructure \cite{slurmpaper}. This provides the architectural basis for keeping a desktop client's resource form separate from the scheduler that grants and enforces an allocation. A submitted request is therefore an auditable specification of desired resources, not proof of their availability.
-
-Research on Jupyter notebooks treats executable code, results, and explanatory prose as a shared publication artifact \cite{notebooks}. ARC Explorer's embedded notebook access supports that workflow, while the notebook server and compute allocation retain their own lifecycles. Peng's account of reproducible computational research emphasizes access to the computational artifacts needed to inspect a result \cite{repro}. The FAIR principles additionally distinguish findability, accessibility, interoperability, and reuse \cite{fair}. These perspectives motivate saving scripts, resource settings, environment information, and outputs together. They do not establish that a GUI, a saved script, or an exported log by itself makes an experiment reproducible or FAIR-compliant.
+A unified workspace is useful only if it also helps users retain the context of their computation. Jupyter notebooks connect executable code, results, and explanatory prose in a shared artifact \cite{notebooks}; ARC Explorer supports access to that workflow while notebook servers and compute allocations retain separate lifecycles. Peng's account of reproducible computational research emphasizes making computational artifacts available for inspection \cite{repro}, and the FAIR principles distinguish findability, accessibility, interoperability, and reuse \cite{fair}. These perspectives motivate keeping scripts, resource settings, environments, and outputs together. The report describes how the application supports those practices without treating the GUI or any individual saved artifact as sufficient evidence of reproducibility or FAIR compliance.
 
 \section{Architecture and execution boundaries}
 

paper/TECHNICAL_PAPER.md

@@ -10,21 +10,17 @@ Technical report · ARC Explorer v0.1 · November 13, 2026
 
 ARC Explorer is a native macOS application that brings connection profiles, resource inspection, allocation accounting, GPU job submission, remote files, terminal sessions, web applications, and language-model assistance into one workspace for Virginia Tech Advanced Research Computing (ARC). The client combines SwiftUI, AppKit, WebKit, the system SSH client, and a small remote Python helper. Computational scripts are submitted to Slurm with explicit resource requests, while an integrated login-node terminal supports direct interactive administration. Five main sections organize the workflow: Connection, Resources, Jobs + software, Sessions, and Help. This report describes the implementation, file-editing safeguards, credential boundaries, installation workflow, and release validation. Twenty-eight Python tests and two native terminal tests pass for the release candidate. The evidence establishes functional checks of selected paths, not a performance benchmark, independent security audit, or guarantee of compatibility with every ARC service. Five application screenshots illustrate the workspace.
 
-## 1. Motivation and context
+## Purpose and Research Context
 
-Researchers using a shared cluster must coordinate several interfaces: SSH authentication, scheduler commands, allocation and storage reports, source repositories, text editors, interactive notebooks, and service documentation. ARC Explorer groups these operations around a saved cluster profile and an explicit resource request. The goal is to reduce interface switching while keeping the underlying commands, execution locations, and resource decisions visible.
+Working on a shared cluster requires coordination across authentication, scheduler commands, allocation and storage reports, source repositories, editors, notebooks, and service documentation. ARC Explorer brings these activities into a native macOS workspace organized around a saved cluster profile and an explicit resource request. Its purpose is to reduce interface switching while keeping commands, execution locations, and resource decisions visible to the researcher.
 
-Web gateways already provide broad access to high-performance computing. Open OnDemand is an established portal architecture for HPC centers [@hudak2018], and ARC documents its deployment for files, jobs, shells, and interactive applications [@arcood]. ARC Explorer complements that infrastructure with a native desktop workspace, an embedded browser, a terminal, and local document dialogs. It does not replace the scheduler, identity provider, allocation service, or Open OnDemand deployment. No comparative usability advantage is asserted.
+This design extends an established ecosystem of HPC access tools. Open OnDemand provides a web-based portal architecture for HPC centers ([Hudak et al., 2018](https://doi.org/10.21105/joss.00622)), and ARC documents its deployment for files, jobs, shells, and interactive applications ([Computing, n.d.](https://www.docs.arc.vt.edu/resources/ood.html)). ARC Explorer combines an embedded browser, terminal, and local document dialogs with that infrastructure. Its desktop workflow complements the portal while continuing to rely on the cluster's identity, allocation, scheduling, and interactive-service mechanisms; comparative usability benefits remain to be evaluated.
 
-The scheduler remains the authority on resource allocation. Slurm exposes submission, queue inspection, accounting, and cancellation through established commands [@slurm]. The application translates form values into explicit scheduler arguments rather than implementing its own queue. ARC's login-node guidance constrains the intended use of interactive commands [@arcpolicy]. The distinction between management and compute is therefore part of both the interface and the implementation, although the general terminal cannot enforce that distinction.
+The boundary between requesting resources and receiving an allocation is fundamental to this workflow. The original Slurm paper describes scheduling and resource management as cluster services ([Yoo et al., 2003](https://doi.org/10.1007/10968987_3)), and Slurm's command interface exposes submission, queue inspection, accounting, and cancellation ([SchedMD, n.d.](https://slurm.schedmd.com/documentation.html)). ARC Explorer translates form values into explicit scheduler arguments so a request can be inspected and saved. The scheduler determines whether and when those resources become available. ARC's login-node guidance also shapes the interface's distinction between management commands and compute jobs ([Computing, n.d.](https://www.docs.arc.vt.edu/usage/abuse.html)), although a general-purpose terminal cannot enforce that policy by itself.
 
-### Research context
+A unified workspace is useful only if it also helps users retain the context of their computation. Jupyter notebooks connect executable code, results, and explanatory prose in a shared artifact ([Kluyver et al., 2016](https://doi.org/10.3233/978-1-61499-649-1-87)); ARC Explorer supports access to that workflow while notebook servers and compute allocations retain separate lifecycles. Peng's account of reproducible computational research emphasizes making computational artifacts available for inspection ([Peng, 2011](https://doi.org/10.1126/science.1213847)), and the FAIR principles distinguish findability, accessibility, interoperability, and reuse ([Wilkinson et al., 2016](https://doi.org/10.1038/sdata.2016.18)). These perspectives motivate keeping scripts, resource settings, environments, and outputs together. The report describes how the application supports those practices without treating the GUI or any individual saved artifact as sufficient evidence of reproducibility or FAIR compliance.
 
-The original Slurm paper describes resource management and scheduling as services of the cluster infrastructure [SLURM: Simple Linux Utility for Resource Management](https://doi.org/10.1007/10968987_3). This provides the architectural basis for keeping a desktop client's resource form separate from the scheduler that grants and enforces an allocation. A submitted request is therefore an auditable specification of desired resources, not proof of their availability.
-
-Research on Jupyter notebooks treats executable code, results, and explanatory prose as a shared publication artifact [Jupyter Notebooks—a publishing format for reproducible computational workflows](https://doi.org/10.3233/978-1-61499-649-1-87). ARC Explorer's embedded notebook access supports that workflow, while the notebook server and compute allocation retain their own lifecycles. Peng's account of reproducible computational research emphasizes access to the computational artifacts needed to inspect a result [Reproducible Research in Computational Science](https://doi.org/10.1126/science.1213847). The FAIR principles additionally distinguish findability, accessibility, interoperability, and reuse [The FAIR Guiding Principles for scientific data management and stewardship](https://doi.org/10.1038/sdata.2016.18). These perspectives motivate saving scripts, resource settings, environment information, and outputs together. They do not establish that a GUI, a saved script, or an exported log by itself makes an experiment reproducible or FAIR-compliant.
-
-## 2. Architecture and execution boundaries
+## Architecture and execution boundaries
 
 The desktop application targets Apple Silicon Macs running macOS 15 or later. SwiftUI provides the workspace and forms; AppKit supplies native dialogs and terminal integration; WebKit renders web services. The application calls the macOS system SSH executable. It does not require a separately installed local Python interpreter, browser engine, or model weights. A system browser remains available as an alternative for web authentication and applications.
 
@@ -36,7 +32,7 @@ The remote helper is itself a Python process on the login node. ARC's published
 
 Nonsecret connection preferences, appearance, bookmarks, and workspace state are stored locally. Profiles contain connection and resource settings, not SSH passwords or private-key material. The local workspace preserves drafts for convenience; it is not a transaction log or a substitute for saving important scripts and files.
 
-## 3. Connection: profiles and authentication
+## Connection: profiles and authentication
 
 The Connection section presents saved profiles, host and port fields, a Virginia Tech PID, authentication mode, private-key path, and remote workspace location. Presets cover TinkerCliffs, Falcon, and Owl; a custom host can be entered. The selected profile also carries the account and resource preferences used by subsequent jobs. A preset is a convenience, not evidence that the host or a GPU partition is currently available.
 
@@ -48,7 +44,7 @@ Light mode is the default, with an explicit dark-mode option. The header uses a
 
 ![Connection section showing the saved profile and SSH form. Offline capture of the signed v0.1 build; no password, API key, or private-key contents are shown.](figures/01-connection.png)
 
-## 4. Resources: availability, accounting, and remote files
+## Resources: availability, accounting, and remote files
 
 Availability queries inspect cluster partitions, user associations, and storage information through the connected host. The application also opens ARC's all-cluster dashboards at the kiosk dashboard URL. These observations describe current or reported state; they neither reserve capacity nor predict queue time.
 
@@ -62,7 +58,7 @@ An opened file is associated with a revision derived from its content hash, devi
 
 ![Cropped detail of the remote file browser and lightweight text editor. This offline view illustrates the editing controls, not an active file transaction.](figures/06-file-editor.png)
 
-## 5. Jobs + software: resource requests and reproducible scripts
+## Jobs + software: resource requests and reproducible scripts
 
 The GPU request form exposes allocation, partition, wall time, GPU count, CPU count, memory, and working directory. Version 0.1 accepts one to eight GPUs, one to 256 CPUs, and one to 2,048 GiB-equivalent Slurm memory units expressed with the G suffix. These are client validation bounds, not promises that a partition supports every combination. Users must choose values allowed by their account and the selected partition.
 
@@ -78,7 +74,7 @@ Repository retrieval does not automatically run arbitrary setup instructions. Th
 
 ![Jobs + software showing explicit GPU resources and the editable script. The example script has not been submitted in this offline screenshot.](figures/03-jobs-software.png)
 
-## 6. Sessions: terminal, web applications, and tunnels
+## Sessions: terminal, web applications, and tunnels
 
 Sessions opens to the Login Node Terminal by default. The terminal occupies the available workspace width and accepts input directly at the shell prompt. SwiftTerm supplies terminal emulation [@swiftterm], connected to a local pseudo-terminal and the system SSH client, which requests a remote pseudo-terminal and an interactive login shell. Input, ANSI output, history keys, tab completion, interrupts, copying, pasting, and window-size changes follow the terminal session rather than a separate command-entry field. The scrollback limit is 5,000 lines.
 
@@ -92,7 +88,7 @@ For an existing service on an allocated compute node, a tunnel maps a local loop
 
 ![Sessions with the full-width Login Node Terminal controls, upper terminal pane, and red compute warning. The terminal is disconnected in this capture.](figures/04-sessions.png)
 
-## 7. Help: command reference and ARC-hosted language models
+## Help: command reference and ARC-hosted language models
 
 The Help section combines a fixed command reference with an optional ARC-hosted LLM assistant. The command reference includes partition inspection, queue and history queries, account associations, module discovery, and storage commands. A command can be copied or placed into the GPU script editor for review. This exposes the actual command syntax and keeps execution separate from explanation.
 
@@ -104,7 +100,7 @@ The transport requires HTTPS and refuses HTTP redirects, preventing automatic fo
 
 ![Help section with the ARC API configuration, model field, and question editor. The API key is empty; no live response is claimed.](figures/05-help.png)
 
-## 8. Verification, distribution, and reproducibility
+## Verification, distribution, and reproducibility
 
 The v0.1 release build passes 28 Python tests and two Swift terminal tests. Python coverage includes resource validation, rejection of malformed identifiers, submission through sbatch rather than login-shell script execution, ownership checks for cancellation, independent report failures, repository-update guards, transfer bounds, and remote editor conflicts. File tests exercise Unicode, byte-order marks, CRLF preservation, permission preservation, binary rejection, link rejection, exclusive creation, and cleanup after a detected save conflict.
 
@@ -116,7 +112,7 @@ The source distribution includes the Swift application, remote helper, native as
 
 The application and its helper are signed with a Developer ID Application identity and hardened runtime. The release workflow submits an archive to Apple's notarization service, staples an accepted ticket to the app, and verifies the resulting bundle before creating the downloadable ZIP. Notarization is a distribution check rather than a certification of the scientific workflow or a functional test. The release manifest records the actual notarization state and artifact checksums; source rebuilds require the builder's own signing identity and credentials for a separately notarized distribution.
 
-## 9. Limitations and future work
+## Limitations and future work
 
 ARC Explorer is experimental research software and an independent client, not an official replacement for ARC documentation or support. Partition names, command availability, API models, quotas, and site policies change. Query results depend on user permissions and may be incomplete. The interface can connect to a custom host, but the management helper assumes a compatible shell, Python 3, and Slurm environment.