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

# How to Contribute

> Ways to contribute code, producers, and docs to b1e55ed.

## Before you start

* Read the repo contribution rules in `CONTRIBUTING.md`.
* Open an issue first for large changes.

<Info>
  Pull requests should target the **`develop`** branch (not `main`).
</Info>

***

## Contributing code (PR workflow)

<Steps>
  <Step title="Fork + branch">
    ```bash theme={null}
    git checkout develop
    git checkout -b feat/my-change
    ```
  </Step>

  <Step title="Keep changes small and testable">
    * Prefer focused PRs
    * Add/adjust tests when behavior changes
  </Step>

  <Step title="Open a PR into develop">
    * Target branch: `develop`
    * Describe: what changed, why, how to test
  </Step>
</Steps>

***

## Contributing producers

Producers are signal generators that publish typed events into the local event store.

A good producer:

* produces **independent** information (low correlation with existing sources)
* is **observable** (clear inputs/outputs, deterministic payload schema)
* degrades gracefully (missing endpoint → no events, clear **DEGRADED** health)
* is safe to run on a VPS (bounded time/cost, robust retries)

### Interface expectations (today)

Even if the upstream data source differs, a producer should:

1. collect data (poll endpoint / read local file / run pipeline)
2. normalize into a stable event type (e.g. `signal.<domain>.<name>.v1`)
3. emit events into the DB so they can be consumed by:
   * the brain synthesis engine
   * API endpoints (`/signals`, `/events/stream`)
   * oracle provenance projections

<Note>
  Weights are applied at the **domain** level (curator/onchain/tradfi/social/technical/events), not per producer.
</Note>

***

## Contributing docs

Docs are Mintlify **MDX** pages.

Guidelines:

* Prefer copy/paste-ready snippets
* Use Mintlify components for clarity:
  * `<Steps>` / `<Step>` for procedures
  * `<Tip>` / `<Note>` / `<Info>` for callouts
  * `<AccordionGroup>` for long references
* Keep examples consistent with the CLI/API references

***

## Bug reports

Open a GitHub Issue with:

* what you expected
* what happened
* logs/output (redact secrets)
* version (`b1e55ed --version`)
* environment (OS, Python version)

***

## Links

* `CONTRIBUTING.md` (repo root)
* CLI: `/operations/cli-reference`
* Config: `/operations/config-reference`
* API: `/api/overview`