# infra-inventory

## Goal

Полная инвентаризация инфраструктуры kzntsv: какие машины существуют, где они физически, какие IP, какие домены/субдомены на них смотрят, какие стеки/сервисы крутятся. Результат — единая страница в global wiki (`projects-wiki/concepts/infrastructure-inventory.md`), доступная всем (босс в `.workshop`, агенты в любом проекте, разрабы). **Без этой карты любой агент / разраб угадывает hostname по software name** (последний инцидент: ляпнул `gitea.kzntsv.site` вместо `git.kzntsv.site`, перепутал source/destination IP в access-логах, построил неверную причину 404).

## Acceptance criteria

- Единая страница `projects-wiki/concepts/infrastructure-inventory.md` ингествованная через `mcp__projects-meta__knowledge_ingest`
- Содержит таблицу: **машина** | **физ. расположение / провайдер** | **public IP** | **internal IP** (если применимо) | **назначение** | **что крутится**
- Содержит таблицу: **subdomain** | **IP** | **на какой машине** | **что обслуживает** | **TLS-resolver** (если traefik)
- Явно зафиксированы **canonical hostnames** для каждого сервиса: `git.kzntsv.site` (Gitea, **НЕ** `gitea.kzntsv.site`), `registry.kzntsv.site`, `traefik.vds.kzntsv.site`, `mssql.kzntsv.site`, `board.kzntsv.site`, owncloud-host, и т.д.
- Раздел «aliases / wildcard» — что апекс и wildcard указывают, что туда **не** надо роутить production-traffic
- Раздел «not on this host» — anti-aliases (`gitea.kzntsv.site` не существует, использовать `git.kzntsv.site`; и аналоги если есть)
- Pointers — для каждого хоста ссылка на соответствующую `.wiki/concepts/<host>-bootstrap.md` если есть, на ops-MCP endpoint если есть (`opsmcp.vds.kzntsv.site`, `opsmcp.kzntsv.site` для NAS)

## Источники

- `mcp__projects-meta__knowledge_search` по существующим bootstrap-concept'ам (vds-kzntsv-bootstrap, vds-ntfy-push, owncloud-vds-deploy, etc. — в `.admin/.tasks/` уже куча)
- `vds-ops` MCP (`mcp__vds-ops__ops_docker_ps`) — что running на VDS
- `synology-ops` MCP — что running на NAS
- `git remote -v` на любом локальном clone → canonical Gitea hostname
- Public DNS probes (`nslookup`) для всех known subdomain
- `~/.config/projects-mcp/auth.toml` — Gitea base URL (canonical)
- Existing concept в `.admin/.wiki/concepts/` если есть (проверить перед написанием с нуля)

## Pending

- [ ] Inventory машин (как минимум: VDS Rusonyx, NAS Synology, dev-машина DESKTOP-NSEF0UK; возможно есть ещё)
- [ ] Inventory subdomain'ов через `nslookup` / list of known hostnames в проектах (`rg -tjsonl "kzntsv.site"` по `~/projects/`)
- [ ] Cross-check каждого hostname с реальным docker stack через ops-MCP
- [ ] Anti-aliases (hostnames которые «звучат правильно» но не существуют — `gitea.`, может другие — `git-registry.`, `nas.`, etc.)
- [ ] Ingest в global wiki через `mcp__projects-meta__knowledge_ingest({target_project: "OpeItcLoc03/projects-wiki", pagePath: "concepts/infrastructure-inventory.md", ...})`
- [ ] Pointer в `.admin/.wiki/CLAUDE.md` Domain conventions: «Перед любым hostname-mention свериться с `projects-wiki/concepts/infrastructure-inventory.md` (canonical names + anti-aliases)»
- [ ] Pointer в `~/projects/claude-skills/` skill `using-vds-ops` body и `using-synology-ops` body: «Canonical hostnames — см. infrastructure-inventory» (когда тот skeleton получит body)

## Acceptance — visible

- Любой агент в любом проекте на вопрос «какой hostname у Gitea?» сначала глянет в инвентаризацию, а не ляпнет `gitea.kzntsv.site` по аналогии с software name
- Босс в `.workshop/` при дизайне нового стека (например, новый сервис на VDS) сразу видит занятые subdomain'ы и не предлагает конфликтующие

## Decisions log

- 2026-05-22: таска создана из incident'а текущей сессии (агент перепутал `gitea.` vs `git.`, source vs destination IP в traefik access-логах, построил неверный root-cause 404 для board-viewer deploy). User: «никакого gitea.kzntsv.site нет, есть только git.kzntsv.site». Single source of truth → global wiki.

## Notes

- Это не оперативная таска (не блокирует deploy). Но без неё каждый новый агент/сессия рискует повторить ту же ошибку. Приоритет — высокий по latency: чем дольше нет inventory, тем больше circular incident'ов.

<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: .workshop / 2026-05-22 -->