# Ресурсные ограничения в **AfRel**

**AfRel** исходит из того, что любой проект, система или организация существуют не в идеальном мире, а в среде с конечными ресурсами. Игнорирование этих ограничений — основная причина паразитических (неверифицируемых, не достигающих цели) задач и провала архитектурных решений.

**AfRel** выделяет три первичных типа ресурсных ограничений, которые должны быть явно отражены в каждом артефакте ( `targ` , `req` , `task` , `check` ):

## Количество (Quantity, X)

Это масштаб системы (или задачи) в количественных единицах.

Примеры:

* Число пользователей, сервисов, запросов в секунду (RPS)
* Объём данных (TB, количество записей)
* Количество строк кода, модулей, команд
* Время выполнения (секунды, часы, дни)

Как фиксируется в артефактах:

* X должен иметь текущее значение (`current`), целевое (`target`) и единицу измерения (`unit`).
* Для `req`/`task`/`check` — вклад в изменение X по сравнению с родительским артефактом.

## Качество (Quality, Y)

Это «плотность» или эффективность на единицу количества.

Примеры:

* Латентность (`p95`,  `p99`), пропускная способность (`throughput`)
* Доступность (99.9%, время простоя)
* Частота ошибок (`error rate`), точность (`precision`/`recall`)
* Надёжность (**MTBF**), безопасность (количество уязвимостей)

Как фиксируется в артефактах:

* Y должен быть измеримым и привязанным к условиям (нагрузка, окружение).
* Y может улучшаться или ухудшаться, и это должно быть явно указано.

## Деньги и ресурсы (Money / Resources, Z)

Это стоимость достижения цели или поддержания состояния.

Что сюда входит:

* Бюджет (капитальные и операционные затраты)
* Зарплаты людей, человеко-часы
* Стоимость инфраструктуры (облако, железо, лицензии)
* Стоимость времени простоя, потери данных, юридических рисков

Как фиксируется в артефактах:

* Z должен содержать абсолютные или относительные значения (например, «экономия $100k/год» или «ROI 18 месяцев»).
* Z может быть отрицательным (отток денег на инвестиции), но тогда должен быть план возврата к положительному Z на горизонте цели.

## Взаимодействие ограничений

Три типа ограничений не независимы. **AfRel** требует фиксировать их вместе, потому что:

* Улучшение качества (Y↑) часто требует увеличения ресурсов (Z↓) или сокращения масштаба (X↓);
* Расширение масштаба (X↑) может привести к падению качества (Y↓) или росту затрат (Z↓);
* Экономия ресурсов (Z↑) может быть достигнута только за счёт сжатия (X↓) и ухудшения качества (Y↓) (меньше возможностей маневрирования);
* Экономия ресурсов (Z↑) может быть достигнута только за счёт сжатия (X↓) и улучшения качества (Y↑) (снижение рисков предоставления услуг);
* и т.п.

Любой артефакт, который описывает изменение только одной оси без учёта двух других, считается неполным (и, как правило, паразитическим).
Пример фиксации ограничений в артефакте YAML

```yaml
id: "1b-targ"
  x:
    current: "10 сервисов, 500 заказов/сек"
    target: "3 сервиса, 500 заказов/сек"
    unit: "число сервисов, заказы/сек"
  y:
    current: "latency p95=200ms, availability=99.9%"
    target: "latency p95=100ms, availability=99.99%"
    unit: "ms, %"
  z:
    current: "операционные затраты $500k/год"
    target: "затраты $350k/год, экономия $150k/год"
    unit: "USD/год"
```

Выход за ограничения (невозможно, но иногда кажется)

**AfRel** не запрещает ставить амбициозные цели, но требует:

* Явно указать, какие ограничения временно нарушаются (например, отток Z на время инвестиций)
* Описать обратный путь к соблюдению ограничений
* Иметь контрольные точки, на которых проверяется, не стали ли нарушения необратимыми

Если артефакт не содержит явного плана возврата к допустимым ограничениям — он считается нежизнеспособным.

## Связь с кубом выживания

Три оси куба выживания — это и есть ресурсные ограничения:

* X → количество
* Y → качество
* Z → деньги/ресурсы

Каждое состояние системы — точка в кубе. Каждая цель — вектор.
Допустимые движения определяются текущими и прогнозируемыми ограничениями.

Отрицательные значения по осям X, Y, Z (например, убыток, уменьшение количества, деградация качества) — это не выход за пределы куба, а состояния, ведущие к нежизнеспособности системы. Задача **AfRel** — не допустить, чтобы система попадала в такие состояния без плана выхода из них.