chore(syncweaver): update tracked sources from CCBR/MOSuite@v0.5.0

Author: ccbr-bot[bot]

.syncweaver-lock.json

@@ -5,8 +5,8 @@
   "sources": {
     "code/MOSuite": {
       "repo_url": "https://github.com/CCBR/MOSuite",
-      "ref": "v0.4.2",
-      "git_sha": "c06ecdff1292eefca106aa83112b579c8b509689"
+      "ref": "v0.5.0",
+      "git_sha": "a1b6f5091131dbe25023969342ee7abb573bb01a"
     }
   }
 }

code/MOSuite/.github/ISSUE_TEMPLATE/config.yml

@@ -1,4 +1,7 @@
 contact_links:
+  - name: MOObject
+    url: https://github.com/CCBR/MOObject/issues
+    about: Issues relating to the multiOmicDataSet object belong here.
   - name: Discussions
     url: https://github.com/CCBR/MOSuite/discussions
     about: Please ask and answer questions here.

code/MOSuite/.github/PULL_REQUEST_TEMPLATE.md

@@ -1,9 +1,16 @@
 ## Changes
 
 <!--
-Provide a brief summary of what is included in this Pull Request (PR).
-If the PR contains complex changes, include a brief description of the rationale
+Provide a brief, concise summary of what is included in this Pull Request (PR).
+If the PR contains complex changes, also include a brief description of the rationale
 behind the implementation decisions.
+Focus this section on the actual user-facing behavior change, bug fix, or design decision.
+Do not include descriptions of obvious, redundant, automated, or required changes that are already covered by checklist items.
+Do not add housekeeping-only bullets. In particular, do not list the following in the Changes section unless one of them is itself the primary behavior change being proposed:
+- regenerated `man/*.Rd` or `NAMESPACE` files
+- `NEWS.md` bookkeeping updates made to satisfy release/changelog requirements
+- routine roxygen2 or test file regeneration that only reflects the underlying feature/fix
+- any bullet that only says files were regenerated/updated (for example, "Regenerate `man/*.Rd`" or "Update `NEWS.md`")
 -->
 
 ## Issues
@@ -13,23 +20,27 @@ Reference any issues related to this PR.
 If this PR fixes any issues,
 [use a keyword](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)
 when referring to the issue so it will be closed automatically when the PR is merged.
+If there are no relevant issues, uncomment the below line:
+None
 -->
 
-<!-- Uncomment the below header if including an AI usage statement:
+<!-- If generative AI was used to draft or generate any part of this PR:
+1. Uncomment the header "## Generative AI Usage Statement" below
+2. Fill in a brief description of how generative AI was used
+3. Disclose the tool and model version used
+
+If generative AI was NOT used in any way, leave this entire section commented out.
+
 ## Generative AI Usage Statement
--->
-<!--
-Include a brief description of how AI assistance was used to generate any of the code or content included in this PR,
-e.g. writing code, writing unit tests, troubleshooting problems, software design discussion, commit messages, or preparing the PR.
-Disclose the tool and model version used, e.g. Claude Code w/ Claude Sonnet 5, Codex w/ GPT-5.6 Sol, Copilot w/ GPT-5.6 Terra, etc.
 
-If generative AI tools were not used in any way whatsoever, uncomment the following line:
-_No generative AI tools were used_
+Include a brief description of how generative AI assistance was used to generate any of the code or content included in this PR,
+e.g. writing code, writing unit tests, troubleshooting problems, software design discussion, commit messages, or preparing the PR.
+Disclose the tool and model version used, e.g. Claude Haiku 4.5, GPT-5.6, Copilot w/ Claude Sonnet 5, etc.
 -->
 
 ## PR Checklist
 
-(~Strikethrough~ any points that are not applicable.)
+(~Strikethrough~ any points that are not applicable. Check boxes only, do not append descriptions.)
 
 - [ ] This comment contains a description of changes with justifications, with any relevant issues linked.
 - [ ] Write unit tests for any new features, bug fixes, or other code changes.

code/MOSuite/.gitignore

@@ -22,3 +22,4 @@ plot-volc-enh.json
 Rplots.pdf
 VennDiagram.*.log
 volc-sum-params.json
+.github/PR_DRAFT.md

code/MOSuite/AGENTS.md

@@ -20,14 +20,20 @@ for detailed instructions on how to contribute to MOSuite.
 - The package must pass `devtools::check()`.
 - R code should adhere to the tidyverse style guide. https://style.tidyverse.org/
 - Only include one return statement at the end of a function. Explicit returns are preferred but not required for R functions.
-- `NAMESPACE` and `man/` are generated by `devtools::document()`; never edit these files directly.
+- `NAMESPACE` and `man/` are generated by `devtools::document()` and in the `auto-format` workflow; never edit these files directly.
 
 ## Commit messages
 
+- Check for user approval before running commit commands. The `git commit` command should be shown expanded (with the full `-m` message text visible), not collapsed or abbreviated, so the user can see the exact message before it runs.
+- If approval has not been given, proceed with code changes and tests only; do not commit.
 - Commit messages must follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) (as enforced in `CONTRIBUTING.md`).
 - Generate messages from staged changes only (`git diff --staged`); do not include unrelated work.
 - Commits should be atomic: one logical change per commit.
 - If mixed changes are present, split into multiple logical commits; the number of commits does not need to equal the number of files changed.
+- Before staging, review `git status` and `git diff` to confirm the change set is small enough to describe in one sentence; if not, it likely needs to be split.
+- Do not blanket-stage with `git add .` or `git add -A`; stage files or hunks individually (`git add <file>`, `git add -p`) so unrelated changes are not swept into the same commit.
+- When splitting into multiple commits, order them so each commit leaves the repository in a working state (e.g., dependencies/config before the code that uses them).
+- Do not mix mechanical changes (formatting, renames, regenerated files) with substantive logic changes in the same commit.
 - Subject format must be: `<type>(optional-scope): short imperative summary` (<=72 chars), e.g., `fix(profile): update release table parser`.
 - Add a body only when needed to explain **why** and notable impact; never include secrets, tokens, PHI, or large diffs.
 - For commits containing any AI-generated code, commit messages, or any other AI-generated content,
@@ -37,37 +43,56 @@ for detailed instructions on how to contribute to MOSuite.
 ## Pull request (PR) process
 
 - PR titles must follow Conventional Commits format (see "Commit messages" section).
-- When opening a PR, use the request template (`.github/PULL_REQUEST_TEMPLATE.md`) and fill out all sections of the template in the PR description.
-- Do not allow the developer to proceed with opening a PR if it does not fill out all sections of the template.
-- Before a PR can be moved from draft to "ready for review", all of the relevant checklist items must be checked, and any
-irrelevant checklist items should be crossed out.
-- If the PR contains any code or other content that was generated with AI
-  assistance, including AI assistance for opening the PR itself, the PR should
-  be labeled `AI-assisted`. In the PR description, uncomment the heading
-  "Generative AI Usage Statement" and add a brief, concise statement of how AI
-  was used in creating the PR (model used, high-level prompt intent, manual
-  review confirmation, etc.).
+- When opening a PR, use the request template (`.github/PULL_REQUEST_TEMPLATE.md`) and fill out all sections of the template in the PR description. Do not allow the developer to proceed with opening a PR if the PR does not fill out all sections of the template.
+- Go through the PR template **section-by-section** in order:
+  1. **Changes**: Summarize user-facing behavior changes, bug fixes, or design decisions.
+  2. **Issues**: Reference any related issues using keywords.
+  3. **Generative AI Usage Statement**: Determine if AI was used for any part of this PR. If yes, uncomment this section and fill it in. If no, leave commented or uncomment and state "No generative AI tools were used".
+  4. **PR Checklist**: Process items sequentially (see checklist workflow below).
+- Write drafted PR descriptions to a gitignored file at [.github/PR_DRAFT.md](.github/PR_DRAFT.md) (overwrite if it already exists). Tell the developer where the file is and instruct them to review and edit it before using it — do not treat a draft as final or ready to ship without that review.
+- When drafting a PR description, initialize every checklist item in [.github/PR_DRAFT.md](.github/PR_DRAFT.md) with one explicit state:
+  - use `- [x]` when the item is verified by evidence (agent-run command output or explicit developer confirmation),
+  - use `- [ ]` when the item is relevant and pending verification,
+  - use `- ~[ ] item text~` when the item is not applicable.
+- Before processing checklist items, examine the current branch state with `git status` and `git diff` to understand what has already been modified. Do not add NEWS.md entries or other changes that may already be in the branch.
+- Quick open: use Cmd+Click on [.github/PR_DRAFT.md](.github/PR_DRAFT.md) in the editor.
+- Before asking for permission to run `gh pr create`, explicitly prompt the developer to open [.github/PR_DRAFT.md](.github/PR_DRAFT.md), review/edit it, and confirm that review is complete.
+- Apply this formatting consistently for both initial draft creation and all later checklist edits.
+- Process checklist items sequentially, one item at a time, before opening the PR.
+- For each checklist item:
+  - collect evidence,
+  - document evidence in the Changes section if it supports a feature or fix (e.g., "Added examples using synthetic data"),
+  - update only the checklist state (checked, unchecked, or crossed out) in [.github/PR_DRAFT.md](.github/PR_DRAFT.md) immediately — do not append evidence descriptions to checklist items.
+- If evidence cannot be collected automatically, ask the developer for confirmation, record that confirmation in the PR draft, and then update the checklist state.
+- Agents may open a PR with relevant pending items left as `- [ ]` only if the PR is opened as a draft.
+- Agents must not open a non-draft (ready-for-review) PR while any relevant checklist item remains pending (`- [ ]`).
+- Whenever an AI agent assists with creating or drafting a PR (including this exact workflow — a developer asking the agent to open or draft a PR), the PR is considered to have generative AI-assisted content and must be labeled `AI-assisted`.
+- The "Generative AI Usage Statement" heading in the PR template (which is commented out by default) must be uncommented and filled in with a brief, concise statement of how generative AI was used (model used, high-level prompt intent, manual review confirmation, etc.), regardless of whether the underlying code/commits were themselves generated by generative AI.
+- To open the PR, either:
+  - Instruct the user to paste the reviewed contents of [.github/PR_DRAFT.md](.github/PR_DRAFT.md) into GitHub's web UI, or
+  - run `gh pr create --title "<conventional-commit-style title>" --body-file .github/PR_DRAFT.md` (add `--draft` if the PR should open as a draft, and `--label "AI-assisted"` if applicable). Only run `gh pr create` with explicit developer approval, and only after prompting the developer to open [.github/PR_DRAFT.md](.github/PR_DRAFT.md) and receiving confirmation that review/edit is complete. Point the user to [.github/PR_DRAFT.md](.github/PR_DRAFT.md) for final review.
+  - If the AI-assisted label was not added at creation time, add it afterwards with `gh pr edit <PR-number-or-URL> --add-label "AI-assisted"`.
 - When new features, bug fixes, or other behavioral changes are introduced to
   the code, unit tests must be added or updated to cover the new or changed
-  functionality.
-- Unit tests should cover all of the code that is added or modified in a PR.
-- Unit tests should not be skipped without a strong reason.
+  functionality; unit tests should not be skipped without a strong reason.
 - If there are any API or other user-facing changes, the documentation must be updated both inline via roxygen comments and long-form docs in the `vignettes/` directory as R Markdown files.
+- Before a PR can be moved from draft to "ready for review", all of the relevant checklist items must be checked, and any
+irrelevant checklist items should be crossed out.
 - If there are merge conflicts, a human developer must resolve them. AI agents must not agree to assist with resolving merge conflicts. Human developers who are unsure how to proceed should reach out to the lead maintainer or code owner.
 - The `R-CMD-check` github actions workflow must pass before the PR can be approved.
 
 ### Changelog
 
 The changelog for the repository is maintained in `NEWS.md`  at the root of the repository.
 Each pull request that introduces user-facing changes must include a concise
-entry with the PR number and author username tagged.
-Developer-only changes (i.e. updates to CI workflows, development notes, etc.)
+entry with the **PR number** (not the issue number) and author's github username tagged.
+Developer-only changes (i.e. updates to CI workflows, development notes, internal developer documentation like AGENTS.md or PR templates, etc.)
 should never be included in the changelog.
 
 Example:
 
 ```
 ## development version
 
-- Fix bug in `detect_absolute_paths()` to ignore comments. (#123, @username)
+- Fix bug in `detect_absolute_paths()` to ignore comments. (#123, @github-username)
 ```

code/MOSuite/CITATION.cff

@@ -1,6 +1,6 @@
 Package: MOSuite
 Title: R package for differential multi-omics analysis
-Version: 0.4.2
+Version: 0.5.0
 Authors@R: c(
     person("Kelly", "Sovacool", , "kelly.sovacool@nih.gov", role = c("aut", "cre"),
            comment = c(ORCID = "0000-0003-3283-829X")),
@@ -38,6 +38,7 @@ Imports:
     limma,
     matrixStats,
     methods,
+    MOObject (>= 0.5.0),
     options,
     plotly,
     purrr,
@@ -80,6 +81,8 @@ Suggests:
     V8,
     VennDiagram,
     withr
+Remotes:
+    CCBR/MOObject
 VignetteBuilder:
     knitr
 biocViews:

code/MOSuite/DESCRIPTION

@@ -1,3 +1,9 @@
+## MOSuite 0.5.0
+
+- The `multiOmicDataSet` class has been moved to a new package, `MOObject`. (#277, @kelly-sovacool)
+  - Ensure backward compatibility by coercing legacy MOSuite MOO objects when read/loaded. (#281, @kelly-sovacool)
+- Harmonize Volcano Plot output dimensions as physical inches with 300 DPI defaults for Enhanced and Summary plots. (#274, @TJoshMeyer)
+
 ## MOSuite 0.4.2
 
 - Align Volcano Plot threshold comparisons across labeling, coloring, and summary filtering, and use resolved column names for classification. (#266, @TJoshMeyer)