chore(syncweaver): update from CCBR/MOSuite@v0.5.0 (#12)

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

* chore: use MOSuite v0.5.0 docker

* test: runtime improvement

---------

Co-authored-by: ccbr-bot[bot] <258092125+ccbr-bot[bot]@users.noreply.github.com>
Co-authored-by: Kelly Sovacool, PhD <kelly-sovacool@users.noreply.github.com>
Co-authored-by: kelly-sovacool <kelly.sovacool@nih.gov>

Author: ccbr-bot[bot]

.codeocean/environment.json

@@ -1,6 +1,6 @@
 {
 	"version": 1,
-	"base_image": "codeocean/mosuite-minimal:v0.3.2",
+	"base_image": "codeocean/mosuite-minimal:v0.5.0",
 	"options": {
 		"registry_host_arg": true,
 		"git_ask_pass": true,

.syncweaver-lock.json

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

CHANGELOG.md

@@ -2,6 +2,8 @@
 
 ## Development version
 
+- Use MOSuite v0.5.0. (#12, @kelly-sovacool)
+
 ## v4.0
 
 - Hide the count subtype parameter and automatically use the `voom` subtype when plotting normalized counts (#11, @phoman14).

code/MOSuite/.Rbuildignore

@@ -30,6 +30,7 @@
 ^Rplots\.pdf$
 ^SECURITY\.md$
 ^tests/figures$
+^tests/testthat/figures/var
 ^vignettes/cli\.Rmd$
 ^vignettes/figures/$
 ^vignettes/memory\.Rmd$

code/MOSuite/.github/CONTRIBUTING.md

@@ -14,6 +14,52 @@ If you've decided to work on an issue,
 [assign yourself to the issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/assigning-issues-and-pull-requests-to-other-github-users#assigning-an-individual-issue-or-pull-request)
 so others will know you're working on it.
 
+## AI Use
+
+Generative AI usage is welcome for generating code, documentation, and other text in this repository.
+Please remember that this project is maintained by humans; every discussion,
+issue, and pull request is read and reviewed by humans (and sometimes machines,
+too).
+Therefore, there are guidelines to make sure contributors' AI usage is helpful,
+productive, and responsible:
+
+- **The human-in-the-loop must fully understand and approve all code and content.**
+  You must evaluate the output of AI tools.
+  Do not assume that AI-generated output is correct, accurate, or complete.
+  You must be able to explain what your changes do and how they interact with the
+  greater system in your own words.
+
+  From the [NIH AI Policy](https://nih.sharepoint.com/sites/NIH-ai/SitePages/Responsible-AI.aspx):
+  > Do not rely on the technology to be a software developer by proxy: All
+  > well-written code must adhere to security design and ethical principles.
+  > **All code output needs to be reviewed** for completeness, quality,
+  > efficiency, and, most of all, security.
+  > Leverage manual and automated validation tools and testing technologies to
+  > help ensure these factors.
+  > **If you cannot identify or understand what a piece of AI generated code
+  > does, you should not use it.**
+
+- **Issues and discussions can use AI assistance but must have a full human-in-the-loop.**
+  This means that any content generated with AI must have been reviewed _and
+  edited_ by a human before submission. AI is very good at being overly verbose
+  and including noise that distracts from the main point. Humans must do their
+  research and trim this down to be concise and precise.
+
+- **All AI usage should be disclosed.**
+  In the footer of commit messages and in Pull Request descriptions:
+  - State 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.)
+  - Include a brief description of how AI assistance was used
+    (e.g. writing code, writing unit tests, troubleshooting problems, software design discussion, commit messages, preparing pull requests).
+
+
+<sub>
+_These AI usage guidelines were adapted from
+[ghostty](https://github.com/ghostty-org/ghostty/blob/22d13172cde98a0a4dda05d3d6a3fcb0dd8ed018/AI_POLICY.md)
+and the
+[NIH AI Policy](https://nih.sharepoint.com/sites/NIH-ai/SitePages/Responsible-AI.aspx)._
+</sub>
+
 ## Pull request process
 
 We use [GitHub Flow](https://docs.github.com/en/get-started/using-github/github-flow)
@@ -50,20 +96,29 @@ cd MOSuite
 
 ### If this is your first time cloning the repo, install dependencies
 
+#### R dependencies
+
 - In an R console, install the R development dependencies with
-  `devtools::install_dev_deps()`, and then make sure the package passes R CMD
-  check by running `devtools::check()`. If R CMD check doesn't pass cleanly,
-  it's a good idea to ask for help before continuing.
+  `devtools::install_dev_deps()`.
+- Alternatively, we have a docker container available with MOSuite's dependencies installed:
+  [`docker://nciccbr/mosuite-minmal:latest`](https://hub.docker.com/r/nciccbr/mosuite-minimal).
+  You can launch the container using your preferred engine (e.g. Docker, Podman, apptainer/singularity)
+  with your clone of the repo mounted while developing your contributions.
 
-- Install [`pre-commit`](https://pre-commit.com/#install) if you don't already
-  have it. Then from the repo's root directory, run
+Before you make any changes, make sure the package passes R CMD check by running `devtools::check()`.
+If R CMD check doesn't pass cleanly, it's a good idea to **ask for help before continuing**.
 
-  ```sh
-  pre-commit install
-  ```
+#### Pre-commit
 
-  This will install the repo's pre-commit hooks.
-  You'll only need to do this step the first time you clone the repo.
+Install [`pre-commit`](https://pre-commit.com/#install) if you don't already
+have it. Then from the repo's root directory, run
+
+```sh
+pre-commit install
+```
+
+This will install the repo's pre-commit hooks.
+You'll only need to do this step the first time you clone the repo.
 
 ### Create a branch
 
@@ -109,6 +164,10 @@ Test files are organized as described in
 <https://style.tidyverse.org/tests.html>.
 Take a look at the existing code in this package for examples.
 
+Ensure your tests cover all of the code changes you make, including various
+parameter options and edge cases.
+Do not skip tests unless you can give a strong reason for doing so.
+
 #### document
 
 If you have written a new function or changed the API of an existing function,

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,7 +1,16 @@
 ## Changes
 
 <!--
-Provide a brief summary of what is included in this Pull Request (PR).
+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
@@ -11,11 +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
+-->
+
+<!-- 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 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/.github/copilot-instructions.md

@@ -9,9 +9,9 @@
 
 ## CI & enforcement suggestions (automatable)
 
-1. **PR template**: include optional AI-assistance disclosure fields (model used, high-level prompt intent, manual review confirmation).
+1. **Pull Request template**: include optional AI-assistance disclosure fields (model used, high-level prompt intent, manual review confirmation).
 2. **Pre-merge check (GitHub Action)**: verify `.github/copilot-instructions.md` is present in the repository and that new pipeline files include a `# CRAFT:` header.
-3. **Lint jobs**: `ruff` for Python, `shellcheck` for shell, `lintr` for R, and `nf-core lint` or Snakemake lint checks where applicable.
+3. **Lint jobs**: `ruff` for Python, `shellcheck` for shell, `lintr` for R, `nf-core lint` for Nextflow, or Snakemake lint checks where applicable.
 4. **Secrets scan**: run `TruffleHog` or `Gitleaks` on PRs to detect accidental credentials.
 5. **AI usage label**: if AI usage is declared, an Action should add `generated-by-AI` label (create this label if it does not exist); the PR body should end with the italicized Markdown line: _Generated using AI_, and any associated commit messages should end with the plain footer line: `Generated using AI`.
 
@@ -108,7 +108,7 @@ Rules:
 
 ## Pull Requests
 
-When opening a pull request, use the repository's pull request template (usually it is `.github/PULL_REQUEST_TEMPLATE.md`).
+When opening a pull request, agents and authors must use the repository's pull request template (`.github/PULL_REQUEST_TEMPLATE.md`).
 Different repos have different PR templates depending on their needs.
 Ensure that the pull request follows the repository's PR template and includes all required information.
 Do not allow the developer to proceed with opening a PR if it does not fill out all sections of the template.
@@ -138,6 +138,18 @@ Example:
 - Fix bug in `detect_absolute_paths()` to ignore comments. (#123, @username)
 ```
 
+## Release Process
+
+To cut a new release in a repo, first use the draft-release workflow
+(`.github/workflows/draft-release.yml`) to draft the release.
+Then the human developer must review the draft release and ensure it meets
+quality standards, then publish the release.
+AI agents must not publish a release, it can only be done by human developers.
+When the release is published, the post-release workflow (`.github/workflows/post-release.yml`)
+will run automatically and open a new Pull Request.
+The human developer must then review the PR, and approve & merge it if the PR
+meets quality standards.
+
 ## Onboarding checklist for new developers
 
 - [ ] Read `.github/CONTRIBUTING.md` and `.github/copilot-instructions.md`.

code/MOSuite/.gitignore

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