> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reasonos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Change proposals

> File an advisory change proposal against another project with rbs propose — suggest what should change without needing a fork or a branch.

`rbs propose` files a **change proposal** against another project on your
ReasonOS control plane. A proposal is a written argument for a change — a title
and a body — addressed to the project's contributors. It is not a pull request:
you send no code and no branch, and whether anything changes is entirely up to
the people who own the project.

```bash theme={null}
rbs propose @acme/webapp \
  --title "Support SSO re-auth" \
  --body "Sessions silently expire mid-flow; the login redirect loses form state..."
```

```text theme={null}
Filed proposal #12 against @acme/webapp.
It is advisory: the project's contributors decide what, if anything, changes.
```

## When to use it

Use a proposal when you've understood something about a project you don't
contribute to and want its owners to act on it:

* You depend on another team's service and its API is missing something you need.
* You found a bug or a design problem while reading a public project.
* You want to suggest a direction before investing in an actual change — filing a
  proposal is much cheaper than preparing a branch in a codebase you don't work
  in.

For changes to a project you *do* work in, don't file a proposal — make the change
on a branch and submit it as a [change request](/workflow/stacks), where it gets
reviewed and landed.

Proposals pair naturally with cross-project Atlas reads: study a project's
structure first, then propose what should change.

```bash theme={null}
rbs atlas query --workspace @acme/webapp "how does auth work"
rbs propose @acme/webapp --title "Support SSO re-auth" --body "..."
```

## Addressing and access

Projects are addressed as `@org/project-slug` — the same form used everywhere
cross-project reads are. **Public** projects accept proposals from anyone;
**private** projects require access to the project.

Filing goes through the control plane, so it must be reachable:

```bash theme={null}
export RBS_CONTROL_PLANE_URL=https://hub.example.com
export RBS_CONTROL_PLANE_TOKEN=...   # if you have one; required for private projects
```

<Note>
  Access errors are deliberately uninformative: a private project you cannot reach
  and a project that does not exist both report "not found or not accessible". You
  cannot probe for the existence of private projects by filing proposals.
</Note>

## Identity

A proposal carries a **claimed identity** so contributors know who is asking and
how to respond. By default that is your git `user.name` and `user.email`; override
either explicitly:

```bash theme={null}
rbs propose @acme/webapp --title "..." --body "..." \
  --author "Jane Doe" --email jane@example.com
```

## Writing the body

The body is the argument for the change — the more concrete, the more likely it
gets acted on. For anything longer than a sentence or two, write it in a file:

```bash theme={null}
rbs propose @acme/webapp \
  --title "Support SSO re-auth" \
  --body-file proposal.md
```

## Flags

| Flag          | Meaning                                            |
| ------------- | -------------------------------------------------- |
| `--title`     | One-line summary of the proposed change (required) |
| `--body`      | The argument for the change                        |
| `--body-file` | Read the body from a file                          |
| `--author`    | Claimed identity (default: git `user.name`)        |
| `--email`     | Contact email (default: git `user.email`)          |