Install GARS

Python 3 for stages 00 and 01 — registering data and building samplesheets — and nothing else. Git, to clone.

Stage 02 runs the pipelines, and needs two conda environments: documented at README.md@e866cce, not walked on this page. Read the platform note before you start: that block installs apptainer and squashfuse, which conda-forge ships for Linux only, so it cannot complete on macOS. The repository's venue table does record a macOS/Docker run for single-cell RNA-seq — but no dependency recipe for that venue is published, so it is a record of a run rather than a road you can follow. On macOS, stage 02 is not reachable from the published instructions.

The agent side: The README names Claude Code and Codex, and says another agent that reads GARS's agent entry file gets the contracts but no live guard. GARS pins no model and has no tested-model list; the engine reads no API key, token or cloud credential. What does exist is on the evidence page: the same task pairs run by more than one model.

Under Claude Code, in a session opened in the gars/ folder, a guard hook checks the agent's eight file and shell tools: its shell runs only GARS's registered typed tools and read-only commands, writes to the system's own files and machine-owned records are refused, and a call the guard cannot judge is refused. Under Codex, the same guard decides shell commands and apply_patch edits once you approve both hooks (checked in a live Codex 0.154 session; decision 0266). A session at the repository root, or under any other agent, runs without the live guard. gars/.claude/settings.json also denies writes to the system, reference and template directories and to its own .claude settings, and denies web search and fetch. This page does not describe a sandbox, because the source does not.

Clone, then stay at the repository root — the verification commands below are relative to it.

git clone https://github.com/javrodriguez/genomics-agentic-research-system.git
cd genomics-agentic-research-system

Then check out the evidence pin. Every command and every expected output below is what that commit gives; any other commit may differ.

git checkout e866cce89c3f4b53fa987ad6a44b46d2a5d5d78b

That is not the engine any recording ran. To read the engine a recording ran, check out its commit instead; the verification below describes the evidence pin only:

git checkout 953184da8925   # engine 0.9.2 · 01-happy-path, 02-ambiguous-input, 03-human-gate

From the repository root, with nothing installed. These are the engine's own tests and its contract lint:

python3 tests/run_tests.py
python3 tests/check_contracts.py

The suite exercises every helper through its real command line, and the contract check reads every stage contract in the tree. Both are stdlib-only Python, so a cold clone can run them before you decide whether to go further.

Generate a small set of reads with the repository's own deterministic fixture generator, then ask GARS to inspect them. The inspect step is read-only: it writes nothing and registers nothing.

python3 evals/fixtures/gen_fastq.py --half control --seed 20260905 --out gars-demo-reads
python3 gars/_system/stage00_register.py inspect --assay rnaseq_bulk --source gars-demo-reads/src

The inspect prints a small JSON block: "ok": true, "raw_file_count": 12, "sample_count": 6, "layout": "paired-end", and the one non-FASTQ file it excluded.

Now the other half, which is the part worth seeing: point the same command at a folder holding a counts matrix rather than reads, and it refuses rather than improvising. This is the command the repository's own evaluation document prints:

python3 gars/_system/stage00_register.py inspect --assay rnaseq_bulk \
  --source evals/fixtures/planted-effect/positive/

It exits 2 with "raw_file_count": 0 and names the three files it excluded — the refusal is in the helper's exit code, not in the agent's judgement. The context for it is in the repository's evaluation document, at e866cce.

From reads to a samplesheet (stage 01)

The same reads, taken on to a samplesheet. Unlike inspect, these commands write: they create a project under gars/projects/, which the repository's .gitignore keeps out of git, and everything they write stays inside your clone. Register the reads as a project:

python3 gars/_system/stage00_register.py create --title demo-walk --assays rnaseq_bulk
python3 gars/_system/stage00_register.py link --project gars/projects/demo-walk --assay rnaseq_bulk --source gars-demo-reads/src
python3 gars/_system/stage00_register.py finalize --project gars/projects/demo-walk

Each prints "ok": true: link reports "linked": 12, and finalize creates the project's design table, samples.csv, with its condition, group and replicate columns left blank for a person to fill in.

Ask stage 01 to check that design before anyone has filled it in:

python3 gars/_system/stage01_samplesheet.py --project gars/projects/demo-walk --check

It refuses. It exits 1, writes nothing, and names every blank row, from samples.csv line 2: blank condition, group, replicate to line 7, and the same output also reports the blank replicate values as repeats within one blank group, which is the same unfilled design read a second way. That is the system declining to build a samplesheet from an incomplete design, and it is the result to expect here. The fixture generator wrote a filled-in design table beside the reads, three control samples and three treated, so copy it into the project and check again:

cp gars-demo-reads/samples.csv gars/projects/demo-walk/00_data/rnaseq_bulk/samples.csv
python3 gars/_system/stage01_samplesheet.py --project gars/projects/demo-walk --check

This time the check exits 0 with "ok": true, 2 groups and 6 samplesheet rows. Then write the samplesheet and read its head:

python3 gars/_system/stage01_samplesheet.py --project gars/projects/demo-walk
head -3 gars/projects/demo-walk/01_samplesheets/rnaseq_bulk_samplesheet.csv

The write exits 0 and names the two files it wrote, 01_samplesheets/rnaseq_bulk_samplesheet.csv and 01_samplesheets/rnaseq_bulk_design.csv. The samplesheet has the header sample,fastq_1,fastq_2,strandedness and 6 rows, one per sample; its fastq_1 and fastq_2 columns are absolute paths inside your clone, and strandedness reads auto.

The workspace is gars/ inside your clone. Open it with an agent and say what you want in plain words — the agent reads the stage contracts and routes to the stage that owns your request.

cd gars

Your projects live in gars/projects/, which is gitignored: real data never enters the repository. The quickstart is README.md@e866cce, and the recordings on this site are what that looks like in practice.

What the recordings ran under, as their own honesty blocks say: claude-fable-5 for 01-happy-path, 02-ambiguous-input, 03-human-gate. The honesty blocks of 01-happy-path, 02-ambiguous-input, 03-human-gate name Claude Code as the harness. That is a record of what ran, not a list of models GARS is tested with.

The executor is a workspace setting, not a spelling: _config/executor.yaml, seeded by stage 00 with name: slurm; with the file deleted, the built-in Slurm descriptor applies. The backend is a closed list, slurm or local, and any other name is refused; AWS Batch is reached through Nextflow, with a configuration admitted only as an exact rendering of one protected template (decision 0251). The local backend exists to exercise the submit → status walk without a cluster and is explicitly not a venue for analyses.

All of this is documented at docs/decisions/0039-the-executor-is-a-workspace-setting.md@e866cce, not shown in any recording: no tape on this site dispatches under Slurm.

Where the runs on this site actually dispatched. The layer that put work on AWS Batch was Nextflow's, not GARS's. In every case the GARS executor descriptor reads name: local, not the name: slurm stage 00 seeds, and points at a Nextflow config carrying the Batch executor: GARS ran the head process, and Nextflow fanned the pipeline tasks out. For the two memory projects the head itself also ran inside a container on AWS Batch, submitted by this demo's own driver rather than by GARS. The head images those runs used sit in a private registry, so this page names none — an image name you cannot pull is not something you can check.

What stage 02 needs on your own compute beyond the environments — the pinned pipeline checkout, the container images Apptainer pulls into a persistent cache, and a reference genome — is documented, not walked, in docs/execution-model.md@e866cce, for one pipeline (nf-core/rnaseq) and one reference (GRCh38). The pipeline tasks' images are nf-core's own, named by the pipeline rather than by GARS. Whether a warm-cache run needs outbound access is not stated there.

One consequence is worth stating rather than smoothing: the paragraph above says the local backend is not a venue for analyses, and the analyses on this site ran under exactly that descriptor. Both stand here unreconciled, the same way a recording's honesty block and its reading note do — the decision record and what the runs did are two facts, and reconciling them is the author's call and not this page's.

Delete the folder these commands created. Nothing was installed outside it, and your projects live inside it — so the clone is the whole footprint. Anything you installed from the linked Dependencies section (the conda environments) lives outside the clone and is yours to remove.