# Contributing New Labs

Treat this repository as an internal enablement product. Each scenario should be independent, resettable, easy to present, and clear enough for a consultant who is not a database specialist.

## Suggested Git Flow

```bash
git checkout -b feature/scenario-05-rag-vector-access
git add .
git commit -m "Add RAG vector access lab scenario"
git push -u origin feature/scenario-05-rag-vector-access
```

Open a pull request to `main` with:

- scenario objective
- expected evidence
- expected infrastructure impact
- positive and negative tests executed
- known limitations

## New Scenario Checklist

- `README.md` with business narrative and execution instructions.
- `RUNBOOK.md` with before/after steps, evidence, and official references.
- `metadata.yaml` with ID, criticality, dependencies, and estimated time.
- `sql/00_schema.sql`, when creating scenario-specific objects.
- `sql/01_seed_data.sql`, when seed data is needed.
- `sql/02_identities.sql`, when creating local end users or data roles.
- `sql/03_data_grants.sql`, for Oracle Deep Data Security policies.
- `sql/04_test_queries.sql`, for demo queries.
- `sql/99_reset.sql`, for rollback.
- `tests/positive_tests.sql`.
- `tests/negative_tests.sql`.
- `evidence/expected-results.md`.

## Rules

- Do not commit passwords, wallets, `.tfvars`, private keys, or real customer evidence.
- Keep SQL idempotent where possible.
- Separate Oracle Deep Data Security product demos from complementary controls such as TDE, Database Vault, Data Safe, and AVDF.
- Use simple language in guides; the demo must work for both CISO and DBA audiences.