# Business rules — russel-serverless-api

Evidence date: 2026-10-05. Source: `git@bitbucket.org:overdrive/russel-serverless-api.git`, `master` at `c6a6cd889f2da571fc0f10bb037041e5dfb65114`.

Provenance labels: **Documented**, **Implemented**, **Inferred**, **Planned**, **Unknown**.

No business-rules document existed in the repository or in `silicon_ark/russel-serverless-api/` before this file.

## Rules found in the repository

None that govern a product. The committed tree cannot enforce validation, permissions, calculations, pricing, or workflow gates, because it contains no application.

No rule below is inferred from the repository name. A name is not a domain rule.

## Identity and access

No login, role, or permission check exists in the source tree.

**Unknown / Requires Confirmation** who is allowed to push to the Bitbucket repository. That hosting permission was not inspected. `git fetch` of `origin/master` succeeded on 2026-10-05.

The untracked scan script does not authenticate a person. It reads a Sonar token from the environment (`SONAR_TOKEN` if set, otherwise `SONARQUBE_TOKEN`) and passes it to the scanner. Provenance: **Documented** in `sonarqube_scan.bat`. The file contains no token value. This is scanner authentication, not an application access rule.

## Domain behaviour

No domain object is defined. There is no customer, order, document, function, endpoint, or event type in this repository.

Other Silicon Ark documents mention Russel Sauer and a `website` branch named `development_russel`. They do not mention `russel-serverless-api`. Those documents are not rules of this repository. Whether the names should ever share a rule set is **Unknown / Requires Confirmation**.

## Validation

No validator, schema, parser, or form rule exists in git.

`.gitignore` lists file patterns the sample says are commonly ignored (dependencies, build output, logs, IDE files, OS files, media). The header says the list should be customized. Provenance: **Documented** in `.gitignore`. Those lines are version-control hygiene from the Atlassian sample. They are not domain validation.

## What the scan script decides

These behaviours are written in the untracked `sonarqube_scan.bat`. They apply only when someone runs that local file. They are not on `master`.

| Condition | Behaviour | Provenance |
|---|---|---|
| `git pull` returns a non-zero exit | Print a warning and continue the scan | **Documented** in the batch file |
| `SONAR_TOKEN` is defined | Pass that value as `sonar.token` | **Documented** |
| `SONAR_TOKEN` is not defined | Pass `SONARQUBE_TOKEN` instead, even if that variable is also empty | **Documented**. The script does not test the fallback |
| The scanner returns non-zero | Print "Scan failed!", wait for a key (`pause`), exit 1 | **Documented** |
| The scanner returns zero | Print "Scan completed successfully!" and end | **Documented** |

No coverage threshold, quality gate, or branch policy is written in either scan file.

## Explicit non-rules

The following were not adopted, because the evidence does not support them:

- "The product is a serverless API." Only the slug says that. **Not a rule.**
- "Requests must be authenticated" or any other API policy. No request handler exists. **Not a rule.**
- "The website project's Russel branch rules apply here." Different repository, no cross-reference. **Not a rule.**
- "A failed Sonar scan blocks merge." No pipeline file exists, and the batch file is not in git. **Not a rule.**

## Human confirmation

- Whether any business rule for this slug is kept outside the repository.
- Whether the local scan script's continue-on-failed-pull behaviour is an approved operational rule or only a convenience on the scan host.
- Whether this slug should inherit rules from any other Overdrive project.