claude's suggestion for 3 new prompts for the hackathon

> This is a great start! I do not see any obvious errors at this point, so I pushed it to begin a review with the scientists. I have three questions, each of them referring to a new session: 1) What is a good prompt on the day of the hackathon to refresh the knowledge base, per your recommendation? 2) What is a good prompt that can answer questions regarding the code? 3) What is a good prompt to construct a development plan once decisions are made (please enumerate specific items that should be included)?

```

● Three prompts below — each self-contained so a fresh session can pick up cold.

  1) Refresh the knowledge base (day of hackathon)

  You are on the tasking project, branch quicknxsv2-modularization. The knowledge base at

  tasking/plan/quicknxsv2-modularization/ was written on 2026-04-18. Refresh it against

  current state — do NOT rewrite; update in place and explain every change.

  Scope:

  1. Run every validation command in 09-glossary-and-pointers.md §"Useful one-shot commands".

     Compare each output against the claims in the knowledge base; note every divergence.

  2. In quicknxsv2 and mr_reduction, diff against the SHAs I cite by running

     `git log --since=2026-04-18 --oneline` in each. For any commit that touches

     interfaces/data_handling/, peak_finding.py, dead_time_correction.py, data_info.py,

     the Mantid pin, or mr_reduction.ReductionProcess — read it and update the relevant

     knowledge-base doc.

  3. Update the "Status (...)" line in README.md to today's date and a one-line changelog.

  4. If the three risks R1/R2/R3 in 08-risks-and-open-questions.md have been resolved,

     strike them through rather than deleting them; preserve the archaeological record.

  5. Commit on this branch with a descriptive message. Do NOT push. Do NOT touch anything

     outside tasking/plan/quicknxsv2-modularization/.

  If nothing substantive has changed, say so and stop — don't invent work.

  2) Answer questions about the code (during the hackathon)

  You are the hackathon's code-navigation assistant. The knowledge base at

  tasking/plan/quicknxsv2-modularization/ is your high-level map — use it as an index, not

  a substitute for reading the code.

  My question: {THE QUESTION}

  Answer rules:

  - Cite every claim with file_path:line_number from quicknxsv2/, mr_reduction/, quicknxsv1/,

    or lr_reduction/ — never from the knowledge base alone. The knowledge base may be stale;

    the code is ground truth.

  - If the question is architectural, check 02-frontend-backend-boundary.md and

    03-mantid-and-mr_reduction-coupling.md first to see if it's already answered; if so,

    verify against current code before quoting.

  - If the knowledge base disagrees with current code, flag the divergence in your answer

    and note that the knowledge base needs a refresh (do NOT update it yourself).

  - Keep the answer under ~200 words unless the question requires code snippets.

  - Do not write files, do not commit. This is read-only Q&A.

  - If the question depends on a decision that's been made during the hackathon that you

    don't know about, ask for it rather than guessing.

  3) Construct the development plan (after Day-1 decisions)

  You are on the tasking project, branch quicknxsv2-modularization. The hackathon's Day-1

  session has produced decisions — record them below, then build an actionable

  development plan at tasking/plan/quicknxsv2-modularization-dev-plan/.

  Decisions made (fill in — the plan is invalid without these):

  - Strategy chosen: { Option 1 / 2 / 3 from 06-modularization-strategies.md, or hybrid }

  - Mantid version to align on: { 6.14 / 6.15 / stay split }

  - New library name (if any): { e.g. mr_core / reflectometry_core / none }

  - DataInfo authoritative implementation: { v2 / mr_reduction / merge both under spec }

  - quicknxsv1 disposition: { EOL date / keep alive / adopt new back-end }

  - Packaging model: { three separate repos / monorepo / namespace package }

  - Approver / sign-off owner: { name }

  - Timeline horizon: { hackathon week only / multi-sprint }

  The dev plan MUST contain (one doc per item, or one doc with these sections):

  1. **Decisions record** — exact text above, plus rationale and dissent captured on Day 1.

  2. **Milestones** — M1/M2/M3 per 06-modularization-strategies.md, adjusted for the

     chosen option. Each milestone: acceptance criteria, owner, exit test.

  3. **Numerical-equivalence test harness spec** — which reference runs, tolerance per

     field (Q, R, dR, dQ), where fixtures live, how to regenerate. This is Week-1 work

     per 05-test-coverage-and-tdd-plan.md; no refactor starts without it.

  4. **PR sequencing** — ordered list with blocks/blocked-by. Call out PRs that must land

     in paired repos together (e.g. mr_core first, then consumer migrations).

  5. **Deprecation policy** — for any API that moves: when does the old import path get

     a DeprecationWarning, when is it removed, what version boundary. Autoreduce's

     ReductionProcess signature is a public API — call it out explicitly.

  6. **Risk register** — copy from 08-risks, mark which are closed/mitigated by the

     chosen strategy, which are accepted, which need a new mitigation.

  7. **Autoreduce/livereduce staging plan** — how the shared-path deploys

     (`/SNS/REF_M/shared/autoreduce`, `/SNS/REF_M/shared/livereduce`) get validated before

     production cutover. Name the staging environment and the rollback procedure.

  8. **Mantid-pinning sequence** — the exact order of pin bumps across three repos so

     CI is never red for more than one PR.

  9. **Migration guide** — one-pager per downstream consumer (interactive GUI user,

     autoreduce maintainer, notebook script user) describing what import paths change.

  10. **Non-goals for this phase** — explicit list; prevents scope creep. Threading,

      cross-instrument generalization, UI rewrite, etc.

  11. **Exit criteria** — the "done" checklist per milestone, written so a third party

      could run it.

  Structural rules:

  - Reference the knowledge base by path (e.g. "see 02-frontend-backend-boundary.md §...")

    rather than duplicating content.

  - Every acceptance criterion must be testable — either a command to run or an

    observable in a PR description.

  - Commit on quicknxsv2-modularization branch. Do NOT push. Do NOT modify the

    existing knowledge base (the dev plan supersedes it only once the hackathon signs

    off; until then they coexist).

  - If any of the decisions above are blank, STOP and ask for them. Do not invent.

```