<!-- status: unverified -->
<!-- A filled architecture brief for a hypothetical robot, illustrating the
     brief-template. Not from a real trial run; promote to verified once an
     actual app is built from a brief like this. -->

# Architecture Brief: WarehouseBot (diff-drive warehouse navigator)

**Date:** 2026-07-10   **Status:** draft
**Author:** robium-architect subagent

## 1. Requirements

- **Robot type:** differential-drive mobile base (~40 cm footprint), 2D lidar +
  wheel odometry, no manipulator.
- **Task:** navigate autonomously between named pick/drop stations in a
  warehouse, avoiding dynamic obstacles (people, carts).
- **Hardware:** none yet, **sim-first**; a real base is a later phase.
- **Sim vs real:** MVP must run entirely in simulation.
- **GPU:** *assumed none* on the dev machine (laptop). **Assumption**: not
  confirmed; feeds open risks.
- **Local vs remote:** developed on a macOS laptop, so the stack runs in Docker;
  a headless workstation is a possible later target.

## 2. Chosen stack + reasoning

| Layer | Choice | Version | Why (and what was rejected) |
|---|---|---|---|
| Middleware | ROS 2 | project-supported release | Standard navigation ecosystem. Verify the release against Nav2 and simulator support before implementation. |
| Simulator | Gazebo | ROS-compatible release | No dedicated NVIDIA GPU is required for this slice. Isaac Sim is unnecessary for a lidar navigation demo. |
| Navigation | Nav2 | release matching ROS 2 | Standard ROS 2 navigation with costmaps, planners, controllers, and behavior trees. |
| Visualization | RViz2 (dev) + Foxglove (remote) | n/a | RViz2 locally for quick checks; Foxglove for the eventual headless workstation. Rerun rejected: not needed for classical nav. |
| Environment | Docker | Jazzy base image | Dev machine is macOS, which can't run the native ROS 2 + Gazebo desktop cleanly; Docker gives identical local/remote repro. uv rejected: this is a compiled ROS 2 workspace, not pure Python. |

Decisions trace to the architect trees: middleware → ROS 2 (mobile multi-node
system); simulator → Gazebo (no GPU); no training framework (classical nav).

## 3. Module breakdown

- **warehousebot_description**: URDF/xacro of the diff-drive base, lidar + wheel
  frames, meshes. Publishes the robot model. In/out: none / `robot_description`,
  TF.
- **warehousebot_sim**: Gazebo world (warehouse layout, shelves, spawn points)
  and spawn glue. In/out: `robot_description` / simulated `/scan`, `/odom`, TF.
- **warehousebot_navigation**: Nav2 config with costmaps (lidar-based obstacle
  layer + inflation), NavFn/Smac planner, DWB/MPPI controller, behavior tree,
  saved warehouse map. In/out: `/scan`,`/odom`,`/map`,goal / `/cmd_vel`.
- **warehousebot_bringup**: top-level launch (sim + nav + viz) and params.
  In/out: launch args / the running system.

## 4. Comms plan

Standard ROS 2 topics, single robot, all in-process for the MVP.

| Topic | Type | Rate | Producer → Consumer |
|---|---|---|---|
| `/scan` | `sensor_msgs/LaserScan` | ~10 Hz | Gazebo lidar → Nav2 costmap |
| `/odom` | `nav_msgs/Odometry` | ~30 Hz | Gazebo diff-drive → Nav2, TF |
| `/cmd_vel` | `geometry_msgs/Twist` | ~20 Hz | Nav2 controller → base |
| `/map` | `nav_msgs/OccupancyGrid` | latched | map_server → Nav2 |
| goal | Nav2 action (`NavigateToPose`) | on demand | app → Nav2 BT |

No cross-host transport needed for the MVP. If the fleet grows to multiple
robots later, revisit with the `integration` skill (namespacing, DDS discovery).

## 5. Environment strategy

Docker, single `Dockerfile` on a compatibility-checked ROS 2 base plus its
supported Gazebo and Nav2 packages; a `compose.yaml` running sim + nav + viz. macOS dev
uses an X/Wayland forward or Foxglove for viewing. The same image runs on the
headless workstation later; identical repro is the reason Docker was chosen
over a native workspace. No GPU passthrough (none required). Detail: route to
the `environments` skill.

## 6. Data plan

No learned components → no datasets. Data artifacts are: the saved warehouse
occupancy `map` (built once via SLAM in sim, then reused), Nav2 param YAMLs, and
recorded rosbags for regression. Rosbags and maps are versioned in-repo; large
bags gitignored. No Hub involvement.

## 7. Robium skills per build phase

| Phase | Skill(s) |
|---|---|
| Environment setup | environments |
| Robot model + bringup | ros2 |
| Simulation world | gazebo |
| Mapping + navigation | navigation |
| Visualization | visualization → rviz2 (local), foxglove (remote) |
| Smoke/regression tests | testing |

## 8. Open risks

- **GPU availability unconfirmed**: the design assumes no GPU and stays on
  Gazebo, which is fine. Blocks nothing for this app, but confirm before any
  future perception/learning phase that might want Isaac. *Resolve:* check
  `nvidia-smi` on the dev/target machine.
- **Dynamic-obstacle avoidance in sim ≠ real**: Gazebo pedestrians are scripted;
  real warehouse traffic is messier. Blocks confidence in the avoidance tuning.
  *De-risk:* keep the costmap/controller params in `warehousebot_navigation`
  easy to retune; plan a hardware validation phase.
- **macOS + Gazebo rendering**: GUI rendering under Docker on macOS can be slow
  or flaky. Blocks smooth local dev. *De-risk:* prefer Foxglove/headless sim for
  day-to-day; use RViz2 sparingly, or move dev to the Linux workstation early.
- **ROS 2 package compatibility**: the selected ROS 2, Nav2, and Gazebo
  combination has not yet been built. *Resolve:* stand up the Docker image
  first and confirm `colcon build` is clean before writing app code.

# Architecture decision record template

Use `docs/architecture-brief.md` for a new application or a genuine
re-architecture. It records decisions and uncertainty; it is not an immutable
contract. Update it when evidence authorizes a pivot.

Only the four core sections are required. Add optional detail when it changes a
decision or helps the next implementation step.

Lock the user-visible outcome, genuine constraints, and the next risk-reducing
slice. Exact methods, versions, hardware SKUs, training parameters, metric
thresholds, protocols, and deployment details stay provisional unless the user
requires them, compatibility/safety/cost makes them necessary, or a cheap probe
has validated that choice for the next slice. Record what actually worked as
implementation evidence instead of predicting it in the architecture brief.

```markdown
# Architecture Brief: <app name>

**Date:** <YYYY-MM-DD>
**Status:** <draft | active | superseded>

## Goal and constraints

The user-visible outcome, robot/task, sim-vs-real target, available hardware,
GPU/budget limits, and local/remote constraints. Mark unconfirmed inputs as
provisional.

## Decisions

| Decision | Choice | Why now | Confidence |
|---|---|---|---|
| First working slice | ... | Cheapest useful risk reduction | validated/provisional |
| Environment | uv/Docker/... | ... | validated/provisional |
| Simulator/middleware | ... | ... | validated/provisional |

Include an alternative only when it was a genuine contender. Do not invent a
rejected option to make the record look complete.

## Provisional assumptions and risks

| Assumption or risk | Impact | Cheapest validation | Authorized pivot |
|---|---|---|---|
| ... | ... | ... | What may change without a new design gate |

## Implementation path

1. The smallest user-visible or risk-reducing slice.
2. The smallest relevant check, or an explicit low-risk manual acceptance handoff.
3. The next integration step if it passes.
```

## Optional sections

Add only those the application needs:

- **Module boundaries and communications** for multi-process, ROS 2, remote, or
  multi-container systems.
- **Environment and deployment detail** when GPU, system dependencies, or
  local/remote parity is a real risk.
- **Data lifecycle** for dataset sourcing, storage, recording, publication, or
  model artifacts.
- **Skill routing** when several Robium skills will be used across phases.
- **Alternatives considered** for a material product or stack choice.

## Updating the record

- Replace a provisional assumption with evidence as soon as a cheap probe
  resolves it.
- Treat a failed probe as information, not a specification violation. Use the
  documented authorized pivot when it remains within the approved direction.
- Ask for another direction decision only when the evidence creates a material
  product choice, scope expansion, external-cost action, or safety concern.
- Set the record to `superseded` only for a genuine re-architecture. Ordinary
  implementation discoveries are normal edits to the active record.

See `../examples/architecture-brief-example.md` for a filled instance; older
examples may be more detailed than a small project requires.

# First-run examples

Use these candidates for the homepage prompts; they are not universal defaults
for every navigation or manipulation project. The application repository owns
commands, dependency pins, platform instructions, and measured results. Read
the current README and launcher before running. Existing evidence for one host
does not certify a fresh installation on another.

The homepage uses outcome-based wording, not robot or policy brands. Mapping,
localization, and a navigation goal suggest `robot-navigation`; a simulated
assistant that sees and follows natural-language instructions suggests
`silly-turtlebot`; pretrained two-arm cube transfer suggests
`act-aloha-cube-transfer`. These are candidates to inspect, not permission to
ignore platform constraints or silently choose a paid model provider. For the
assistant, explain the Gemini requirement and possible charges before live use.

| User outcome | Candidate and canonical instructions | First visible proof |
| --- | --- | --- |
| Map, localize, and navigate with a simulated TurtleBot | [robot-navigation](https://github.com/robium-ai/robium-apps/tree/main/robot-navigation): existing House environment and dashboard | Create and save a map, load it for localization, then reach a navigation goal. |
| Control a simulated TurtleBot with Gemini | [silly-turtlebot](https://github.com/robium-ai/robium-apps/tree/main/silly-turtlebot): fast TurtleBot3 simulation profile, not physical TurtleBot4 mode | An authorized live Gemini mission completes with camera updates; cancellation stops simulated motion. |
| Run pretrained ACT bimanual cube transfer | [act-aloha-cube-transfer](https://github.com/robium-ai/robium-apps/tree/main/act-aloha-cube-transfer): pinned checkpoint and documented default scenario | Viewer renders, actual inference runs, and the default transfer outcome is observed and reported honestly. No training. |

## First-user constraints

- Target simulation on Apple Silicon macOS or Linux x86_64 without requiring
  a dedicated GPU. Verify the selected app's actual compatibility before
  choosing its native or container path; do not extrapolate host support from
  a Docker image or macOS-only run.
- Navigation and Gemini simulation require Docker/Compose. Check availability,
  resources, and port conflicts without stopping an unrelated running demo.
- Gemini additionally needs authorized model access and may incur API charges.
  Guide the user to configure `GEMINI_API_KEY` locally without pasting it into
  chat. Do not require the maintainer's secret-store account. Missing or denied
  access must be explained before attempting a live mission. Mock checks are
  useful diagnostics only and must be identified as such.
- ACT uses an existing pretrained checkpoint. Setup may download the model and
  dependencies. Keep randomized trials optional and distinguish successful
  bring-up from policy success across arbitrary layouts.
- Do not present hosted warm-start estimates as local installation times.
  Record cold/warm timing only when actually measured, including cache state,
  platform, source revision, scenario, and result. Report untested paths openly.

# From a working example to the user's app

Use only the chosen path. This is not a checklist requiring all four paths or
a reason to delay a first demo for a design document.

## Adapt an example

- A request for a customized app authorizes a derivative, not changes to the
  shared reference checkout. Identify the source app and revision; preserve
  existing user work. Use the application's documented clone/copy workflow,
  a separate checkout, or a worktree as appropriate to its repository layout.
  A GitHub fork or push is optional and requires separate authorization.
- Prove the unchanged baseline before behavioral edits. Keep its launcher,
  compatible dependency pins, assets, viewer, and smallest relevant test.
  Reuse an already verified baseline when its revision, environment, and
  relevant behavior still match; do not repeat expensive setup ceremonially.
- Confirm or safely resolve the destination before copying. Never overwrite
  an existing project or drag secrets, virtual environments, build outputs,
  or large caches into a new repository. Preserve license and attribution;
  reference shared assets through the owning app's supported mechanism.
- Make the smallest requested customization, then check only the affected
  behavior once the change is coherent; do not rerun the whole baseline after
  every edit. Low-risk visual acceptance may be handed to the user with exact
  steps and an explicit unverified status.
  Keep unrelated behavior at the reference defaults rather than asking
  speculative customization questions. Keep an unchanged reference for
  comparison. Defer repo restructuring,
  optional services, training, and deployment until the user needs them.

## Reuse selected pieces

- Explain which concrete pieces fit and which do not: for example a bounded
  robot-control adapter, camera stream, simulator launcher, or viewer. Check
  interfaces, dependency coupling, platform evidence, and licensing before
  choosing extraction over a fresh implementation.
- Do not run or clone every candidate application just to reuse one module.
  Inspect its owning docs and existing evidence; run a focused check when
  compatibility is uncertain, without automatically writing a per-piece suite.
  Do not inherit a paid model dependency
  or an entire ROS stack for an unrelated dashboard component.
- Retain necessary configuration, pins, licenses, and source revision with
  the reused piece. Adapt only the boundary needed for the new app. A module
  that worked in its source app is not evidence that the new combination works.
- Create the smallest runnable app connecting those pieces and check one
  end-to-end behavior, or explicitly hand off low-risk manual acceptance.
  This need not be an automated harness. Expand only after that result is visible; do not build
  a general-purpose framework or complete all the source apps' features.

## Start fresh

- Briefly state why existing apps or pieces do not fit, unless the user already
  explicitly chose from scratch. Do not insist on running an unwanted example.
- Select domain skills for the first visible behavior, not every future feature.
  Research only unresolved compatibility or design decisions that could block
  that behavior. Bring in heavy architecture research only for a real ambiguity.
- Use [scaffold patterns](scaffold-patterns.md) as optional shapes, not required
  directory trees. One process or package may be enough. Keep any architecture
  brief short; do not make it a separate approval gate for an agreed build.
- Define one observable success check, get it running, then offer the next small
  customization. Keep hardware, paid APIs, and cloud provisioning behind their
  existing authorization boundaries.

# Scaffold patterns

Optional repo shapes after selecting adaptation, partial reuse, or a fresh
build. Do not scaffold for a try-only request or copy an entire app merely
because one component fits. Follow the chosen [reuse path](reuse-paths.md),
then prune anything the first working slice does not need.

The `tests/` directories below are optional. Reuse existing checks; add automated
coverage for meaningful risk or repeatable regressions, not to fill the tree.

Keep tiny-demo decisions inline; applications with meaningful architecture
choices can use a concise `docs/architecture-brief.md`.
Learning capture belongs to Robium's sibling `learnings/` tree and hooks rather
than an application-local ritual.

The env layer (Dockerfile vs `pyproject.toml`) is decided by the `environments`
skill; both trees below show the common case.

## ROS 2 application (navigation golden path)

For a mobile robot navigating in Gazebo with Nav2. A ROS 2 workspace with a
`src/` colcon layout, one package per concern.

```
my-nav-robot/
├── docs/
│   └── architecture-brief.md        # concise decision record
├── docker/
│   ├── Dockerfile                   # selected ROS 2 base + deps (environments skill)
│   └── compose.yaml                 # sim + nav + viz services
├── src/                             # colcon workspace source
│   ├── my_robot_description/        # URDF/xacro, meshes: the robot model
│   │   ├── urdf/
│   │   ├── meshes/
│   │   └── launch/                  # spawn/description launch
│   ├── my_robot_bringup/            # top-level launch + params, ties it together
│   │   ├── launch/                  # bringup.launch.py (sim + nav + viz)
│   │   └── config/                  # nav2_params.yaml, ros2 params
│   ├── my_robot_navigation/         # Nav2 config: costmaps, planners, BT
│   │   ├── config/
│   │   ├── behavior_trees/
│   │   └── maps/
│   └── my_robot_sim/                # Gazebo worlds + spawn glue
│       ├── worlds/
│       └── models/
├── tests/                           # smoke + launch tests (testing skill)
└── README.md
```

**What each dir holds**
- `*_description`: the robot's URDF/xacro, meshes, and the launch that
  publishes the model. One source of truth for the robot's geometry/frames.
- `*_bringup`: the composition layer; the launch file that starts sim + Nav2 +
  visualization together, plus the parameter YAMLs. Where a new user starts.
- `*_navigation`: everything Nav2 (`navigation` skill): costmap configs, planner and
  controller params, behavior trees, saved maps.
- `*_sim`: Gazebo (`gazebo` skill): world files, spawn models, sim-only glue.
- `docker/`: the reproducible environment (`environments` skill): a
  compatibility-checked ROS 2 base image and a compose file wiring services.
- `tests/`: smoke and launch tests (`testing` skill): "does the robot reach a
  goal in sim" as a regression.

## LeRobot application (manipulation golden path)

For training and evaluating a manipulation policy. A Python project managed by
`uv` (no colcon), organized around the data → train → eval loop.

```
my-arm-policy/
├── docs/
│   └── architecture-brief.md        # concise decision record
├── pyproject.toml                   # uv-managed deps (environments skill)
├── uv.lock
├── src/
│   └── my_policy/
│       ├── configs/                 # policy + training configs (ACT, Diffusion, SmolVLA…)
│       ├── datasets/                # LeRobotDataset prep / loading glue (lerobot)
│       ├── train.py                 # training entry point (lerobot)
│       ├── eval.py                  # in-sim evaluation entry point
│       └── env/                     # sim/hardware env wrappers
├── data/                            # local datasets / cache (gitignored; data skill)
├── outputs/                         # checkpoints, logs, eval videos (gitignored)
├── notebooks/                       # exploration (optional)
├── tests/                           # smoke tests: dataset loads, 1-step train runs
└── README.md
```

**What each dir holds**
- `src/my_policy/configs`: training and policy hyperparameter configs; which
  policy family (ACT / Diffusion / SmolVLA / π0) and its settings.
- `src/my_policy/datasets`: LeRobotDataset preparation, loading, transforms,
  and recording glue belong to `lerobot`; Hub authentication and transfers go
  through `huggingface`, and sourcing strategy through `data`.
- `src/my_policy/{train,eval}.py`: the `lerobot` training and evaluation
  entry points; keep them thin, config-driven.
- `src/my_policy/env`: wrappers around the sim (or, later, real hardware).
  Add `isaac-sim`/`isaac-lab` here **only if the GPU floor is met**; otherwise
  LeRobot's own sim.
- `data/` and `outputs/`: large, regenerable, git-ignored.
- `pyproject.toml` + `uv.lock`: the reproducible env (`environments` skill);
  uv is the default for the manipulation path since much of it is CPU-friendly
  Python and doesn't need the full ROS 2 Docker apparatus.

## Adapting

- A real-hardware version of either app keeps the tree and swaps the `*_sim` /
  `env` directory for a hardware-driver package/module.
- A hybrid (learned policy running inside a ROS 2 system) starts from the ROS 2
  tree and adds a `my_policy` package that wraps the LeRobot inference.
- Prune aggressively for an MVP; a single-package ROS 2 demo doesn't need four
  packages. Add `docs/architecture-brief.md` only when the application has
  meaningful decisions worth retaining beyond an inline explanation.

# Stack selection

Use these decisions only when the first application slice has not already made
the stack obvious. Verify supported versions, operating systems, hardware, and
package combinations in current official documentation before recording them.

## Start with the runtime shape

- Choose ROS 2 when the first slice benefits from standard robot drivers,
  multi-node communication, TF, ecosystem packages, or mobile navigation.
- Skip ROS 2 for a self-contained training or policy experiment that does not
  need robot middleware yet. It can be added at the hardware boundary later.
- If processes or hosts need nontrivial boundaries beyond a normal ROS graph,
  let `integration` choose the communication shape after the application
  modules are clear.

Official starting point: [ROS 2 documentation](https://docs.ros.org/).

## Choose a simulator for the evidence

- Prefer Gazebo for ROS-centric mobile robotics, common sensor simulation, and
  machines without a supported NVIDIA GPU.
- Prefer MuJoCo for lightweight contact-rich manipulation where a full ROS
  stack is unnecessary.
- Consider Isaac Sim when photorealistic perception, synthetic data, or the
  NVIDIA ecosystem materially changes the first slice and the machine meets
  its current GPU, driver, memory, OS, and storage requirements.
- Consider Isaac Lab when the actual goal is parallel reinforcement or
  imitation learning on top of Isaac Sim, not simply because a GPU is present.
- If hardware availability is unknown, choose a viable lower-cost path and
  record the higher-cost simulator as a provisional alternative.

Route final selection through `simulation`, then use `gazebo`, `mujoco`, or
`isaac-sim`/`isaac-lab` for mechanics. Current sources:
[Gazebo](https://gazebosim.org/docs/),
[MuJoCo](https://mujoco.readthedocs.io/), and
[Isaac Sim](https://docs.isaacsim.omniverse.nvidia.com/).

## Choose classical or learned behavior

- Use Nav2 through `navigation` when the robot needs classical localization,
  planning, and control for mobile navigation.
- Use `lerobot` for manipulation imitation learning, supported policies, data
  recording, training, and evaluation.
- Use `isaac-lab` for GPU-parallel RL or IL only after the simulator and
  hardware constraints are proven.
- Do not add a training framework to an application whose first behavior is
  fully served by conventional planning or control.

Data sourcing belongs to `data`; Hub operations belong to `huggingface`.
Current sources: [Nav2](https://docs.nav2.org/) and
[LeRobot](https://github.com/huggingface/lerobot).

## Select versions last

- Start from the compatibility matrix of the chosen upstream stack rather than
  selecting every component's newest release independently.
- Prefer a supported release with available binaries for all first-slice
  dependencies. An LTS label alone does not prove that the full combination is
  packaged.
- Verify the installed or containerized combination with the cheapest build and
  launch probe before treating it as an architecture decision.
- Record the working versions as implementation evidence. Revisit them only
  when a dependency, security issue, or required capability forces the change.

## Record only real branches

Keep small decisions inline; use `docs/architecture-brief.md` for choices that
need a durable record. Include the direction, why it fits, and the cheapest
falsifying probe. Mention alternatives only when they were genuine
contenders. Keep unresolved hardware or compatibility questions provisional
with an explicit fallback.

# Editable workspace and updates

Setup creates a user-chosen parent directory containing two ordinary Git
checkouts: `robium/` (skills/plugin source) and `robium-apps/` (reference apps).
The parent is not a Git repository. Do not assume its name or location.

## Find the existing source

Run `npx robium-ai workspace --json` to obtain `root`, `repo`, and `apps`.
Resolution is an explicit `--dir <workspace>`, an enclosing two-repository
workspace, then the root remembered in `~/.config/robium/workspace.json`.
`setup --dir <workspace>` selects and remembers a location; subsequent setup
reuses the checkouts without pulling them. A missing or invalid saved location
is a reason to ask where the user moved it, not to clone over it or guess.

Use `<apps>/REGISTRY.md` and the owning app's README for reference selection.
`npx robium-ai app list --json` discovers the local apps from outside the
workspace too. An explicit `app --dir` targets the apps repository itself;
setup/update `--dir` targets its parent. Honor an explicitly selected app
checkout or `ROBIUM_APPS_DIR` instead of silently using another workspace.

## Check quietly; update intentionally

Before starting a new reference example, optionally run
`npx robium-ai update --check --quiet`. Do not do this on every prompt, during
a running experiment, or as a prerequisite to unrelated maintenance. The CLI
limits these network checks to once per 24 hours per workspace, stays silent
when current/offline, and offers one combined notice no more than weekly and
never repeats the same known revisions. `ROBIUM_UPDATE_CHECKS=0` disables quiet
checks. There is no background daemon or required scheduling.

If the check prints nothing, continue without mentioning it. If it reports an
update, give at most one short non-blocking note at a natural stopping point;
do not pause the task or repeatedly ask. Follow a user's preference not to hear
about updates. A newer commit alone is not evidence of a relevant fix or a
security issue. Do not check unrelated third-party skill repositories.

When asked whether Robium is current, use `npx robium-ai update --check --json`
for a fresh comparison with both official `main` branches. Report `unknown`
honestly on network/repository errors. A check fetches a comparison ref; it
does not modify working files, the current branch, or dependencies.

When the user asks to update, run `npx robium-ai update`. Only clean `main`
branches with no local-only commits are fast-forwarded from official Robium
upstream, even if `origin` is the user's fork. Personal branches, dirty files,
detached HEADs, and divergent history are left alone with a reason. Do not
stash, reset, switch branches, rebase, or merge a personal branch without
separate direction. A partial update is not success for both repos.

Users can also fetch/pull manually after reviewing branch and remote state.
After a manual source update or personal edit, `npx robium-ai setup` reconnects
host integrations without pulling the repos. Follow its host-specific restart
instructions. Cached plugin activation is distinct from Git freshness; do not
claim an agent has loaded edited skills based only on an unchanged version
number. Never edit the installed cache as the user's source of truth.

Develop on a branch in either checkout, test there, and optionally fork and
open a PR later. Contribution is opt-in; never push local work automatically.