# Release Gate Policy

`config/release_gate_policy.yml` — централізований конфіг строгості gate-ів для різних профілів деплойменту.

## Профілі

| Профіль | Призначення | privacy_watch | cost_watch |
|---------|-------------|---------------|------------|
| `dev` | Розробка | warn | warn |
| `staging` | Стейджинг | **strict** (fail_on error) | warn |
| `prod` | Продакшн | **strict** (fail_on error) | warn |

## Режими gate-ів

| Режим | Поведінка |
|-------|-----------|
| `off` | Gate повністю пропускається (не викликається, не виводиться) |
| `warn` | Gate завжди `pass=True`; findings → `recommendations` |
| `strict` | Gate може заблокувати реліз за умовами `fail_on` |

## Використання

Передати `gate_profile` у inputs release_check:

```json
{
  "gate_profile": "staging",
  "run_privacy_watch": true,
  "diff_text": "..."
}
```

## strict mode: privacy_watch

Блокує реліз якщо є findings із severity у `fail_on`:

```yaml
privacy_watch:
  mode: "strict"
  fail_on: ["error"]   # тільки error-severity блокує; warning = recommendation
```

Наприклад, `DG-SEC-001` (private key) = error → `release_check.pass = false`.  
`DG-LOG-001` (sensitive logger) = warning → не блокує у staging/prod.

## cost_watch

**Завжди `warn`** у всіх профілях — cost spikes ніколи не блокують реліз (тільки recommendations).

## Backward compatibility

Якщо `gate_profile` не переданий → використовується `dev` (warn для privacy і cost).  
Якщо `release_gate_policy.yml` відсутній → всі gates використовують `warn` (graceful fallback).

## Приклад виводу для staging з error finding

```json
{
  "pass": false,
  "gates": [
    { "name": "privacy_watch", "status": "pass", "errors": 1,
      "top_findings": [{"id": "DG-SEC-001", "severity": "error", ...}],
      "recommendations": ["Remove private key from code..."] }
  ],
  "summary": "❌ RELEASE CHECK FAILED. Failed: []. Errors: [].",
  "recommendations": ["Remove private key from code..."]
}
```