(java || kotlin) && devOps

  - model_name: deepseek-v4-flash
    litellm_params:
      model: anthropic/deepseek-v4-flash
      api_base: https://api.deepseek.com/anthropic

general_settings:
  forward_client_headers_to_llm_api: true

my-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
├── mcp.json
└── com.example.client/
    └── hooks/

Напоминаю по факту: я запустил sudo cat /etc/gitlab-runner/config.toml, чтобы проверить extra_hosts, и в выводе целиком приехала строка token = "glrt-X…". Надо было сразу grep -v token — дальше я так и делал, но эту строку уже не отменить.

Итог: токен в 2 файлах транскрипта сессий (~/.claude/projects/**.jsonl) плюс в бэкапе /etc/gitlab-runner/config.toml.bak.20260810, который создал я.

Главное, а не файлы на диске: он был в моём контексте, то есть ушёл в API Anthropic. Локальной утечкой это уже не назвать.

Дайте новый токен — впишу и перезапущу, privileged/volumes не тронув. Или сделайте сами, если не хотите гонять его через меня второй раз — что, учитывая причину ротации, разумнее.

@Rule
public SingleInstancePostgresRule pg = EmbeddedPostgresRules.singleInstance();

@Rule
public PreparedDbRule db =
EmbeddedPostgresRules.preparedDatabase(
LiquibasePreparer.forClasspathLocation("liqui/master.xml"));

try (EmbeddedPostgres pg = EmbeddedPostgres.start();
             Connection c = pg.getPostgresDatabase().getConnection()) {
...
}

Мутационно проверен — обе попытки «сдать» тест валят его:
- убрать финальный пулл → live metric lost points;
- оставить метрику ingest_enabled=false после apply → onboarded metric is not being pulled after the flip.

Первая версия ассертов, кстати, мутацию пережила (точки новой метрики приходили от backfill'а) — отсюда шаг 4.

## 1. Chain и policy

- [ ] 1.1 `data/label_policy.yaml`: добавить `service_id_chain` (дефолт `[service, service.name, app, app.kubernetes.io/name, job]`); загрузчик policy сохраняет порядок, поставляет дефолт при отсутствии поля
- [ ] 1.2 Функция извлечения `extract_service_id(labels, chain) -> (service_id, service_source)` — чистая, ≤N dict-lookup'ов; юнит-тесты: порядок приоритета (`service` бьёт `app`), fallback на `app`/`job`, пустой chain → `('', 'none')`, provenance-значения

### Task 1: Service ID Extraction Chain + Policy

**Files:**
- Create: `src/meta/service_id.py`
- Modify: `data/label_policy.yaml`
...

**Interfaces:**
- Produces: `extract_service_id(labels: dict[str, str], chain: list[str]) -> tuple[str, str]` — returns `(service_id, service_source)`
...

#### Step 1: Add `service_id_chain` to `label_policy.yaml`

- [ ] **Step 1.1: Edit `data/label_policy.yaml`** — append after `max_virtual_series`:

```yaml
# service_id_chain — ordered keys for deriving a metric's service identity
# (T2-22). The first key present in observed labels wins. Chain order:
# intentional instrumentation labels → infra labels → scrape labels.
# Changing the chain requires re-profiling affected metrics + regenerating
# templates (chain is part of the metric-identity contract).
service_id_chain:
- service
- service.name
- app
- app.kubernetes.io/name
- job
```

#### Step 2: Write failing tests for `extract_service_id`

- [ ] **Step 2.1: Create `tests/meta/test_service_id.py` with failing tests:**

```python
"""Unit tests for service_id extraction chain (T2-22)."""
from meta.service_id import extract_service_id

DEFAULT_CHAIN = ["service", "service.name", "app", "app.kubernetes.io/name", "job"]

def test_intentional_key_wins_over_infra():
labels = {"service": "payments", "app": "payments-prod-1"}
sid, src = extract_service_id(labels, DEFAULT_CHAIN)
assert sid == "payments"
assert src == "label:service"
...