> For the complete documentation index, see [llms.txt](https://carec.gitbook.io/carec-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://carec.gitbook.io/carec-docs/documentation/contributor-guide/contributor-handbook.md).

# Contributor Handbook

This handbook explains how to work effectively on CAREC. For the shortest onboarding path, begin with the [Team Hub](broken://pages/team-hub).

## Before starting work

1. Understand the project scope and current status.
2. Read safety guidance relevant to your work.
3. Choose a contribution track matching your skills.
4. Select a defined issue or discuss a proposed issue with the maintainer.
5. Confirm acceptance criteria and dependencies.
6. Identify whether the work affects architecture, interfaces, motion, autonomy, or safety.

## Task ownership

Have a clearly defined task before substantial implementation. The issue should state the problem, expected outcome, constraints, acceptance criteria, and known dependencies where possible. If the task is ambiguous, clarify it before writing a large amount of code.

## Branches and pull requests

Keep each branch focused on one issue or coherent change. Do not develop directly on `main`. Pull requests should explain what changed, why, how it was tested, evidence/results, known limitations, and safety/documentation impact.

Small, reviewable pull requests are preferred over large unrelated changes.

## Definition of done

A contribution should have, as applicable:

* acceptance criteria satisfied;
* code/document review complete;
* relevant tests passing;
* reproducible evidence attached or described;
* safety impact considered;
* interfaces/configuration documented;
* related GitBook documentation updated;
* known limitations recorded;
* required maintainer approval received.

## Engineering decisions

Do not silently introduce major dependencies, change interfaces or architecture, or redefine safety behavior. Raise the decision before implementation and record the outcome where future contributors can find it.

## Testing

Use the lowest-risk useful environment first: unit tests, isolated components, simulation, integration testing, controlled bench testing, then carefully controlled hardware testing. Experimental wheelchair motion must not be tested with a person in the wheelchair.

See [Testing Strategy](/carec-docs/documentation/development/testing-strategy.md), [Safety Test Scenarios](/carec-docs/documentation/simulation/safety-test-scenarios.md), and [Verification and Validation](/carec-docs/documentation/safety/verification-and-validation.md).

## Documentation expectations

Update documentation when your change affects setup, architecture, interfaces, configuration, expected behavior, supported hardware, testing, safety, or contributor workflow. A future engineer should not need private conversations to understand the system.

## Communication

Use GitHub issues for task-specific discussion and PRs for implementation review. Use the weekly meeting for coordination, blockers, cross-team decisions, and progress. Capture important conclusions back in GitHub or GitBook.

## Asking for help

Provide the issue/task, environment, expected behavior, actual behavior, logs/error output, what you tried, and a minimal reproduction when possible.

For permissions and approvals, use the [Access & Approval Guide](/carec-docs/documentation/contributor-guide/access-and-approval-guide.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://carec.gitbook.io/carec-docs/documentation/contributor-guide/contributor-handbook.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.