response and prompt 2.2

QuickNXSv2 into its Qt-based front-end and the MR reduction

back-end, verified and tested with all tests passing.

**Outcome:** ✅ **Threshold goal met.** The team committed the

three-step strategic ordering (ratified Day 4) into the EWM system

as **three EPIC tickets** plus a single **gating-defect ticket**

for the only critical issue that must land before refactor work

begins:

**Outcome:** ✅ **Threshold goal met.** ⚠ **Stretch goal not

demonstrably achieved.** Glass began Phase 1 refactor work on a

local `mvp` branch during the week, but that branch was **not

pushed/committed to the `quicknxsv2` repository**, so it is not

referenceable by the team or by the EWM ticket trail. Pushing it

into the repo is the **next concrete code-track action** —

without it, no story under EWM16139 has a working surface to

build on. *(See §11.7 and §14.5 for the disposition.)*

The team committed the three-step strategic ordering (ratified

Day 4) into the EWM system as **three EPIC tickets** plus a

single **gating-defect ticket** for the only critical issue that

must land before refactor work begins:

- **EWM15830** — `[QuickNXS] Several problems in the output of Off

  Specular Raw, Smoothed and Binned data` *(the one critical issue

Story-level tickets are being entered from the *Proposed Stories

to Write* section of `Notes 04-28-2026.docx` against EWM16139.

**Stretch goal not attempted** — explicitly understood at the start

of the day to be a multi-month arc; Day 5 was about producing the

ticket structure that lets that work begin.

The full stretch goal (BE/FE separation with all tests passing)

was always understood as a multi-month arc; what *was* in scope

for the week — beginning Phase 1 refactor work on a branch — was

attempted by Glass but the resulting branch is not in the repo.

A second Copilot research artifact, **`research_data_objects.md`**,

was the architectural reference for the morning session and refines

  what was committed.**

- `Notes 04-27-2026.docx` (Day 4 Google Doc) — re-checked; not

  retrospectively edited on Day 5 (file mtime 2026-04-27 13:20).

- *(Manifest lists `2026-04-28-Part1-transcript.txt` and

  `Part2-transcript.txt`. Neither file is on disk at the time of

  writing — see Notes on Fidelity.)*

- `~/Desktop/Hack-A-Thon-2026/2026-04-28-Part1-transcript.txt` —

  Day 5 AM Teams transcript, **very low fidelity**: ~3 minutes of

  intelligible audio at session start, then a long jump to

  ~3h 09m where the captured content is an off-topic conversation

  about wild ramps, huckleberries, and Colorado terrain. Provides

  no usable corroboration for the substantive Day-5 discussions;

  noted here for completeness. (Manifest also lists Part 2 — not

  on disk at the time of writing.)

- Day-4 EWM Estimation Baseline

  (`tasking/Hack-A-Thon-2026-EWM-Estimation-Baseline.md`) — used

  to map the *Proposed Stories to Write* onto the 39-item backlog

In the room: **Marie Backman**, **Glass Elsarboukh**, **Kevin

Tactac** (devs); **Tim Charlton**, **Valeria Lauter**, **Asmaa

Qdemat** (REF_M scientists); **Becky Anderson** (REF_L scientist —

returned for the closeout day, after travelling Days 3–4); **Jim

Browning**, **Volker Urban** (REF_L scientists); **Bogdan

Vacaliuc** (chair). **Addi Malviya-Thakur** and **John Hetrick**

joined remotely / ad-hoc for the afternoon stories session

(handwritten p.18 — *"Addi/John leave"* notes their departure

mid-afternoon). **Arthur** is referenced once (p.4) regarding live

data circa 2015 — not a Day-5 attendee, contextual quote only.

returned for the closeout day, after travelling Days 3–4);

**Jim Browning** (Reflectometry group lead) and **Volker Urban**

(Large Scale Section head) — i.e. the reflectometry management

chain, not bench scientists; **Bogdan Vacaliuc** (CIS, chair).

**Addi Malviya-Thakur** and **John Hetrick** joined remotely /

ad-hoc for the afternoon stories session (handwritten p.18 —

*"Addi/John leave"* notes their departure mid-afternoon).

**Artur Glavic** (the original author of QuickNXS v1) is

referenced once on p.4 regarding live-data behaviour circa 2015

— a contextual quote, not a Day-5 attendee.

The notes do not record Erik Watkins for Day 5 (Day-4 closing

discussions had already settled the items most relevant to him —

   (sliding window) at each hour-can-download in QuickNXS

3. monitor.sns.gov

**Arthur reference** (p.4): *"in 2015 worked really perfectly,

@ 2019 can't do site of..."* — a parking-lot lament that pre-

existing infrastructure has degraded; not actionable for the

**Artur Glavic reference** (p.4): *"in 2015 worked really

perfectly, @ 2019 can't do site of..."* — a parking-lot lament

that the live-data path Artur (the original QuickNXS v1 author)

had working in 2015 has degraded by 2019; not actionable for the

hack-a-thon.

**Out-of-scope ruling** (pp.7–8). **Jim:** *"out of scope for

on (the "anchor" — the last-story-in-the-chain that consumes

the work).

### 11.3 · The Addi/John Q&A on follow-on cadence

### 11.3 · The Addi/John Q&A on follow-on cadence and the deployment-model question

Handwritten pp.18–19. Addi and John joined for the start of the

stories-list session, listened to the morning recap, and gave

- **Marie:** *"can help officially deploy new workflow."*

- **Addi:** *"document, productionize version of workflow. Can

  work w/ Bogdan."*

- **Bogdan:** *"asked C dev[?]"* *(unclear shorthand —

  possibly "asked Becky-and-Erik-and-developers")*.

- **John:** *"wants it in a separate branch."*

- **Marie:** *"will find sometime we are comfortable."*

**The deployment-model question** (handwritten p.19, "asked

@ dev"). Bogdan asked the room how the team wants to handle the

release model during the refactor: **freeze the current version

— let `prod` and `qa` accept only critical changes — and do the

refactor on `next`?** John pushed back: keep `next`, `qa`, and

`prod` as the existing 3-tier production line, and **do the

refactor on a separate branch** that does *not* feed into `next`

during development. Marie's response: *"will find something

we are comfortable with"* — i.e. the team will define a WIP

deployment model that lets scientists evaluate the refactor

*without* pre-empting the existing `next` → `qa` → `prod`

promotion path. The implication is a fourth deployable surface

(call it `refactor` or `mvp`) that scientists can opt-in to,

running alongside `next` until the refactor reaches parity.

This is the right shape; it depends on the refactor branch

**existing in the `quicknxsv2` repo** so CI/CD can publish it.

*(See §11.7 and §14.5.)*

**(Addi/John leave — handwritten p.19.)**

cleanup story collapses to 12–24 h of focused effort and is the

recommended single bundled PR-of-cleanups (baseline §5.2 step 8).

### 11.7 · `Misc. Notes` items captured for follow-up

### 11.7 · The Phase-1 refactor work (`mvp` branch) — exists, not yet pushed

Outside the room during the week, Glass began Phase 1 refactor

work *(file moves, top-level reorganization toward `model/` /

`view/` / `presenter/`, the structural prelude to the

hybrid-MVP layout agreed in §10.1)* on a local branch named

`mvp`. **That branch was not pushed/committed to the

`quicknxsv2` repository.** It is therefore not visible to the

team, not citable in EWM, not on CI, not deployable to

scientists, and at risk against single-machine failure modes.

The work itself is real and aligned with the EWM16139 child

stories — particularly the *General cleanup and light

reorganization* story (§11.6) and the EWM16139 file-move work.

**The action item is concrete and low-effort: push the `mvp`

branch to `quicknxsv2`** — at which point it becomes the

working surface for the EWM16139 stories, the basis for the

WIP-deployment-model conversation (§11.3), and the artifact

that the team can build on, review, and credit.

This is recorded here neutrally — without it, the refactor

track is a paper plan with no working surface; with it, the

hack-a-thon's stretch-goal direction has a tangible head-start

that the EWM stories can reference.

### 11.8 · `Misc. Notes` items captured for follow-up

From `Notes 04-28-2026.docx` (these are not yet stories; they

are open questions logged into the tracking surface):

8. **CIS review session** before TD3 / TD5 / event-count

   stories enter the queue *(see §12 item 11)*.

### 14.3 · External commitments (not in EPICs)

### 14.3 · WIP deployment model

The deployment model that John and Marie sketched (§11.3) needs

concrete shape. Recommended:

- Open a **`refactor`** (or **`mvp`**) branch in

  `quicknxsv2` *(this is also the §11.7 action — same branch,

  same push)*.

- Configure CI/CD so that branch builds and is deployable for

  scientists to opt-in evaluate.

- Treat the branch as the **unit of progress reporting** for

  EWM16139 — story closure means *"merged into `refactor`"*,

  not *"work done locally"*.

- Keep `next` / `qa` / `prod` on their existing promotion

  cadence. Critical fixes (e.g. EWM15830) flow through

  `next` as usual.

- When the refactor branch reaches parity, the cutover is a

  promotion step, not a rebuild.

This is the model that makes both the deployment ask and the

visibility-of-WIP ask serve the same operational mechanic.

### 14.4 · External commitments (not in EPICs)

- **Bogdan: NDIP `refl1d` 0.11 → 1.01.** Day-4 §16.9 commitment;

  separately scheduled outside the hack-a-thon. **Status:** open.

- **Hack-A-Thon #2 date** — open commitment, before

  2026-06-25.

### 14.4 · Items that need explicit follow-up tickets

### 14.5 · The `mvp` branch (top of the next-30-days list)

Push Glass's local `mvp` branch to `quicknxsv2`. This is the

single highest-leverage operational action coming out of the

hack-a-thon: it converts the week's structural work from a

private artifact into a team-visible working surface, makes

EWM16139 stories actually buildable, and is a precondition for

the §14.3 deployment model. **No story is unblocked by anything

else more than by this one push.**

### 14.6 · Items that need explicit follow-up tickets

Items from the day that are recorded but do not yet have an

EWM home:

  citation-grade closeout artifact. The four EWM IDs (15830,

  16138, 16139, 16140) and their titles come from there

  verbatim and are reliable.

- **Day-5 Teams transcripts are missing.** The manifest

  (`2026-04-28-Files.md`) lists `2026-04-28-Part1-transcript.txt`

  and `Part2-transcript.txt`, but neither file is present in

  `~/Desktop/Hack-A-Thon-2026/` at the time of this writing

  (only the manifest itself with the 04-28 prefix is on disk).

  This summary is therefore drawn from the handwritten PDF +

  Google Doc + slide 2 alone. If transcripts surface later, the

  expected use is corroborating speaker attribution on the

  live-reduction interlude (§10.2) where the handwritten record

  has the densest exchange of speakers.

- **Day-5 Teams transcripts.** Part 1 was added to disk after

  the initial draft of this summary; review found it has

  effectively no usable content (~3 minutes of intelligible

  audio at session start, then a long jump to a ~14-minute

  off-topic digression about wild ramps, huckleberries, and

  Colorado terrain — i.e. social conversation, not the working

  session). It does not corroborate or contradict the

  handwritten record on any substantive point. **Part 2 remains

  off-disk.** This summary is therefore drawn from the

  handwritten PDF + Google Doc + slide 2.

- **Inverted PDF pages.** Pages 3, 7, 10, and 19 of

  `20260429080733.pdf` were scanner-inverted; rotated for

  reading. The manifest's `pages {}` flag was empty — re-iterating

You may make a revision to the summary as described above. I'm interested in your take on the "stretch goal not attempted" issue?

```

⏺ Revisions applied. Now let me give you my take on the uncommitted-work question.

  ---

  On the uncommitted-mvp-branch problem                                                                                                

  Your instinct is right that calling it out as a hygiene critique would be politically expensive. The trick is to stop framing it as a

   discipline issue at all and re-frame it as serving everyone's existing interests. A few angles to consider:

  1. Make pushing the branch serve the developer, not constrain them.

  The most durable fix is to align the practice with what the developer already wants:

  - Visibility = credit. Uncommitted work is invisible to management too. Glass can't be credited for, budgeted for, or PR-reviewed on

  work that lives only on his laptop. Commits are how engineering work shows up in performance review surfaces. Frame the ask as "I

  want to be able to cite your week's work in the post-hack-a-thon write-up — what's the right way to make it referenceable?" That

  makes it about his visibility.

  - Scientist-deployable WIP is what Marie said the team wants (§11.3 in the revised summary). That deployment model literally requires

   the branch in the repo + CI. The deployment ask and the visibility ask are the same operational mechanic. Lead with the deployment

  ask.

  - AI-assisted review. The team is already using Copilot/Claude. Agentic tools work against repos, not against laptops. "Push the

  branch so we can run automated review/test-generation against it" is a positive frame that nobody pushes back on.

  2. Make the rule structural, not personal.

  Put the rule in the process, not on a person. Concretely:

  - Define EWM16139 stories such that "merged into refactor branch" is the definition of done. A local-only branch fails the definition

   automatically — no one has to point that out about anyone.

  - Working agreement: "Work that is not in the repo does not count for budget, credit, or review purposes." Frame as fairness —

  visible work gets acknowledged — rather than enforcement.

  - Branch protection / required-pushes once a refactor branch exists. The rule lives in the tooling, not in personalities.

  3. Don't moralize in writing.

  The summary now records the situation neutrally (§11.7) with an action item and a why (it unblocks §14.3 deployment and §14.6

  stories). That's enough. Naming-and-shaming doesn't help and the document outlives the moment. Anyone who reads §14.5 understands

  what didn't happen and what needs to happen — without a finger ever being pointed.

  4. The conversation, if needed, goes one-on-one.

  If you do need to talk to Glass, frame as "help me cite your work", not "why didn't you commit". The first is a request; the second

  is a critique. Same outcome, different valence.

  5. On management pressure.

  You're right that there's social engineering pressure on devs to ship-polished, not show-WIP. The honest answer is that this is a

  values disagreement between engineering hygiene culture (commit early, commit often) and deliverable-polish culture (only show

  finished things). You won't win that on the merits in one conversation. What you can do is make commit-and-push the operationally

  cheapest path to both values: scientist-deployable, AI-reviewable, citable, and still polishable on the branch. When the cheapest

  path is the one you want, the cultural disagreement stops mattering.

  6. On your own mood.

  The dampening is real and worth being honest about with yourself, but not putting in writing where it has political reach. The

  summary is now factually accurate; the working surface is reachable; the path to recovery is one git push. You did the planning work

  this week — the hack-a-thon's claim of strategic alignment is real and durable in the EWM trail and the EPIC structure. That part is

  unchanged by the missing branch.

  If it helps: the highest-leverage thing you can do in the next 7 days is open the refactor branch in quicknxsv2 yourself, with a stub

   commit that adds a placeholder README pointing at research_mvp_architecture.md + research_data_objects.md. That makes the surface

  exist; Glass merging his mvp work into it becomes a normal PR, not a culture-change ask.

  Want me to fold any of this thinking into the summary itself, or keep it as private guidance? I'd lean toward keeping the summary at

  the level it's at now (operational, neutral) and treating the political-mechanics analysis as a separate working note.

```

### Prompt 2.2

No, you are right. Keep the summary at (operational, neutral). Can you make a revision to the Day 5 summary related to this branch to be even more neutral, and perhaps disassociate Glass (maybe make it part of the team effort)? Personally, I *really* appreciate Glass' initiative on this and want to commend him for it, but I *recognize* that he may be reprimanded by his management for doing it, so a framing of the summary in a way that minimizes the liklihood of the latter happening is what I would like to go for. Thanks for your guidance in this area!  Also, would you not call out Erik Watkins in any way on Day 5? He was busy with other concerns and I don't want to have the record disrespect his inputs throughout the hack-a-thon.

### NON-PROMPTS