initial pre-prompt planning and prompt 1

# quicknxsv2-modularization instructions

This project contains plans and artifacts gathered during the course of evaluating software

architecture and refactoring it for maintainability.

You may read any and all files that are in this folder and which are provided in the /home/controls/**.

There are also files that may be referenced from the read-only experiment filesystem mounts at /SNS/**.

You may use the ORNL intranet freely to research specifications and documentation. If there is information

that you require that references the public internet and are blocked from access, ask for help to obtain the file.

## Capabilites and Role

You are a neutron scattering scientist who is expert at python coding and have a deep understanding of the QT application programming interface.

You are able to direct agent teams who are expert system programmers and software developers who have a deep understanding of the C/C++ runtime model and how to diagnose and fix memory, concurrency and file system errors.

You will use best practices of python syntax and code development and will design tests to verify all code contributions.

You will use git to organize modifications for each feature that you add.

## Secure Temporary Files

When a task requires writing a temporary script or data file (e.g. to work around

shell quoting limits when calling an API), **never write it to a world-readable

path**.  `/tmp` on a multi-user Linux system is mode 1777 — files created there

with default umask are readable by every local user.

**Always create temporary files with mode 600 (owner read/write only):**

```python

import os, tempfile

# Preferred: tempfile.NamedTemporaryFile — mode 600 by default

with tempfile.NamedTemporaryFile('w', suffix='.py', delete=False) as fh:

    fh.write(script_content)

    tmp_path = fh.name

try:

    # use tmp_path ...

finally:

    os.unlink(tmp_path)   # always clean up

```

Or with the Write tool followed by an immediate chmod:

```bash

# After writing the file, restrict permissions immediately

chmod 600 /path/to/tempfile

```

**Additional rules:**

- Never embed credentials (tokens, passwords, keys) in files under `plan/`,

  `tests/`, or any other committed path.  Use environment variables or

  `~/.netrc` / `~/.config` files (also mode 600) instead.

- Delete temporary files as soon as they are no longer needed — use a

  `try/finally` block or the `delete=True` default of `NamedTemporaryFile`.

- If a script must be written to `/tmp` via the Write tool (which cannot set

  permissions atomically), run `chmod 600 <path>` in the very next Bash call

  before the file is used.

### Test data for development

Files in `/SNS/REF_L/`, `/SNS/REF_M/` and `/SNS/users/6ov/` are accessed via sshfs mounts with cache. See the

parent project's `CLAUDE.md` for network mount handling rules.

**Do not revert the `read_only` parameter** — the production mount is `-o ro` and tests

will fail with `OSError: [Errno 30] Read-only file system` without it.

# quicknxsv2-modularization-investigation

Using the [Claude](https://code.ornl.gov/6ov/claude) agentic-engineering knowledge transfer workflow, I organized quicknxsv2, mr_reduction, lr_reduction and quicknxsv2 subprojects to contain the full source code and edit history of those projects. As is my custom, I collect files and screenshots in my home folder on the DAQ/Analysis unified autohome folder mount, at the systematic path `${HOME}/${BL}/YYYY/MM/DD/*`. I also use the systematic path `${HOME}/shared/${INSTRUMENT}/*` to contain session output files. The agent runs on a machine that has the `/SNS/${INSTRUMENT}/` and `/SNS/users/${USER}/` mounted via an sshfs filesystem mount ( *which is setup easily by the workflow via `setup/mount-sshfs.sh`* ). The [architecture](https://code.ornl.gov/6ov/claude/-/blob/main/setup/docs/architecture.md?ref_type=heads) of this workflow and how knowledge transfers is documented.

```

6ov@uvdl3:/media/ssd2/Projects/Claude/2$ setup/mount-sshfs.sh --status REF_L REF_M users/6ov

=== SNS/REF_L ===

  Backend:    rclone (sftp-analysis-sns-gov)

  Mount:      /home/6ov/SNS/REF_L [mounted]

  Symlink:    /SNS/REF_L -> /home/6ov/SNS/REF_L

  Cache:      /home/6ov/.cache/sns-data/vfs/sftp-analysis-sns-gov/SNS/REF_L

  Cache size: 4.1M (1 files)

  Cache age:  oldest 2026-04-15, newest 2026-04-15

  SSH master: UP

  Watchdog:   not running

  Service:    (not installed)

=== SNS/REF_M ===

  Backend:    rclone (sftp-analysis-sns-gov)

  Mount:      /home/6ov/SNS/REF_M [mounted]

  Symlink:    /SNS/REF_M -> /home/6ov/SNS/REF_M

  Cache:      /home/6ov/.cache/sns-data/vfs/sftp-analysis-sns-gov/SNS/REF_M

  Cache size: 16M (1 files)

  Cache age:  oldest 2018-06-21, newest 2018-06-21

  SSH master: UP

  Watchdog:   not running

  Service:    (not installed)

=== SNS/users/6ov ===

  Backend:    sshfs

  Mount:      /home/6ov/SNS/users/6ov [mounted]

  Symlink:    /SNS/users/6ov -> /home/6ov/SNS/users/6ov

  Cache:      (no cached data)

  SSH master: UP

  Watchdog:   not running

  Service:    (not installed)

```

Under this environment, I created a branch in [tasking](https://code.ornl.gov/6ov/tasking/-/tree/quicknxsv2-modularization) to prepare for this investigation, based on previous work and an understanding of how to prompt the AI assistant to produce high quality results. From that step, I engaged in a the dialog that is captured below:

## Prompt 1

You are working on the tasking project, quicknxsv2-modularization branch. You are preparing documents to support a week-long software developer/neutron scientist "hack-a-thon". The goal of this "hack-a-thon" is to evaluate whether the software quicknxsv2 is suitable for being modularised into a "front-end" UI (currently based on Qt) and a "back-end" module (currently the mr_reduction project). The provenance of quicknxs draws its history from quicknxsv1 (which has had recent development in the feature/read-event-nexus branch). The task is to conduct an *extensive and through* investigation into the quicknxsv2 and mr_reduction software repositories. Please construct the necessary documents to provide a *knowledge-base* that future teams of agents can use to answer questions including (but not limited to) a) how the software is structured. b) the level of separation between "front-end" and "back-end", c) the feasibility and approaches that *future* sessions may use to *plan* such separation efforts using software best practices and red-green test driven development. Be expansively thorough and read as much git commit history as you need in quicknxsv2, mr_reduction and any other repository that you require. Be diligent and resourceful. If you need a tool to analyze the data that you do not have, use venv, uv and/or pixi to install it ask me to help you.