> 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/access-and-approval-guide.md).

# Access & Approval Guide

What is public, what requires elevated access, and which CAREC changes require technical, safety, or project-owner approval.

CAREC is an open-source project with a public GitHub repository. Most contributors do **not** need repository permission to get started.

> **CAREC project owner:** `vinodkumar1947`
>
> Contact `vinodkumar1947` for **elevated permissions, restricted access, release authority, safety-critical approval, or hardware-related approval**.

## GitHub access

The primary repository is [vinodkumar1947/CAREC-Project](https://github.com/vinodkumar1947/CAREC-Project). It is **public**.

Anyone may, without requesting permission:

* view the repository;
* clone it;
* fork it;
* open issues;
* submit pull requests.

### When GitHub permission is required

Contact project owner `vinodkumar1947` if you need:

* collaborator or direct write access;
* repository administration or settings access;
* release/tag authority;
* access to restricted project resources;
* another permission that is not available to a normal public contributor.

Normal contributors should work through forks or branches and pull requests rather than direct changes to `main`.

## Documentation access

Public CAREC documentation can be read without edit access. If GitBook edit access is required, request permission from `vinodkumar1947`. Contributors who modify documentation should propose focused changes and follow review appropriate to the content. Architecture and safety documentation changes require corresponding technical/safety review.

## Approval levels

### Normal implementation

Examples: isolated software improvements, tests, tooling, documentation fixes.

**Expected path:** issue → implementation → tests/evidence → pull request → normal project review.

### Architecture/interface change

Examples: new component boundaries, message/interface changes, control-path changes, major dependencies.

**Expected path:** issue/proposal → technical discussion → `vinodkumar1947` agreement → implementation → review → merge.

### Safety-impacting change

Examples: motor control, stopping, emergency stop, obstacle detection, collision avoidance, autonomous navigation, takeover, fault behavior, power safety.

**Expected path:** identify safety impact/hazard → define verification evidence → technical + safety review → `vinodkumar1947` approval → controlled implementation/testing → merge only after blocking concerns are resolved.

## Permission and access requests

Contact `vinodkumar1947` for requests involving:

* collaborator/write permissions;
* GitBook/documentation edit access;
* branch, merge, release, or repository-level permissions;
* project resources or restricted shared development assets;
* approval to perform restricted or hardware-related work;
* any other CAREC permission not available to a normal public contributor.

You do **not** need to contact the project owner merely to read, clone, fork, open an issue, or submit a pull request.

## Requesting a new feature

Create or propose an issue that explains the user/problem, desired behavior, why it belongs in CAREC, affected components, safety implications, dependencies, and suggested acceptance criteria. Do not begin a large implementation until scope is agreed.

## Requesting hardware or a hardware test

Document what hardware is needed, why simulation or existing evidence is insufficient, the test objective, required equipment, expected duration, risks/safety controls, and evidence that will be captured. Send the request to `vinodkumar1947`. Hardware availability is not guaranteed; remote-first tasks should remain possible wherever practical.

## Requesting a technical decision

When multiple approaches are possible, describe the decision to make, options considered, tradeoffs, recommendation, affected interfaces/components, and safety implications. Record the final decision in the issue and update permanent documentation when it changes the system design. Final approval for architecture, safety-critical, release, and hardware decisions is with `vinodkumar1947`.

## Merge and release authority

Contributors submit pull requests. Review may be delegated according to the project workflow, while project owner `vinodkumar1947` retains owner-controlled authority for safety-critical merges, releases, and physical-hardware enablement.

## When unsure

If you are unsure whether elevated permission or owner approval is required, contact `vinodkumar1947` before proceeding. If a change could affect wheelchair motion, stopping, user control, autonomy, collision risk, or fault behavior, treat it as safety-impacting until reviewed. Do not bypass review because a change appears small.


---

# 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/access-and-approval-guide.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.