Zimin A.N.
c8dd5aad4e
## AI Schema Assist Phase 1 (steps 1-2)
Approach A core (templates only, no LLM) — admin начинает создание нового
справочника с curated skeleton вместо пустого Monaco. Approach C (per-field
LLM suggest) — Phase 2 на этом фундаменте.
### Backend
- `templates/*.template.json` в ordinis-cuod-bundle resources — 6 шаблонов
(blank/spacecraft/ground-station/antenna/frequency-band/operator)
- `SchemaTemplateRegistry` (rest-api) — classpath scan at startup, strip
x-template-* metadata, expose canonical JSON Schema
- `SchemaTemplatesController` — GET /api/v1/dictionaries/templates (list)
+ /{id} (detail с schemaJson)
- Cross-bundle support: scanner matches classpath*:templates/*.template.json
— другие bundles могут shippит свои templates через те же conventions
### Frontend
- types: SchemaTemplateSummary + SchemaTemplateDetail
- queries: schemaTemplatesQuery + lazy detail query
- TemplatePicker.tsx — grid of cards (icon + name + description + tags),
click → fetch detail → fire onPick(detail)
- Integrated в DictionaryEditorDialog (create mode, properties.length===0
visible — после первой property picker исчезает чтобы не перезатереть)
## Nexus DevOps handoff
`docs-internal/ops/nexus-alpine-mirror.md` — runbook про APKINDEX vs file
inventory drift на v3.23 mirror. Includes:
- Verification commands
- 3 fix options (invalidate cache / scheduled refresh / self-host)
- Prometheus alert proposal
- Current workaround (node:22-alpine3.20 pin) reference
Active issue paired с CI saga !227/!229/!230 — нужен DevOps action.
Ordinis — internal documentation
Технические детали реализации, архитектура, operator runbooks и project state snapshots. НЕ deployment'ится через Diplodoc — это внутренние артефакты для команды Ordinis (не для consumers).
Consumer-facing документация находится в docs/ и build'ится через
Diplodoc → static HTML.
Что внутри
docs-internal/
├── ops/ # Operator runbook (on-call, incidents, recovery)
│ ├── README.md
│ ├── slo.md
│ ├── outbox-dlq.md
│ ├── db-migrations.md
│ ├── vault-unseal.md
│ └── kafka-restart.md
├── status/ # Project state snapshots (по дням сессий)
│ └── *-state.md
└── tech/ # Архитектурные deep-dives, legacy документы
└── api-integration.md # legacy (мигрирован в docs/integration/api/)
Когда что использовать
| Situation | Read |
|---|---|
| Я — consumer интегрирующий свой backend | docs/integration/api/ (Diplodoc) |
| Я — on-call инженер с alert | ops/README.md |
| Я — Ordinis dev планирующий feature | status/ latest snapshot + design docs в ~/.gstack/projects/claude/ |
| Я — новый разработчик в команде | Сначала consumer docs, потом ops/, потом status/ для context |
Архитектурные artifacts (вне репозитория)
Design docs / план-плансы хранятся в ~/.gstack/projects/claude/:
zimin-main-design-production-prep-20260507-123032.md— prod stand-up planzimin-main-design-approval-workflow-v2-20260507-121632.md— approval flow v2 (DEFERRED)zimin-main-design-dict-relationships-v2-20260507-230237.md— lineage + cascade rulescheckpoints/*.md— session state checkpoints для context-restore
Rationale разделения
Diplodoc документация — public contract для интеграторов:
- Может быть опубликована на public Pages
- Не должна leak'ать internal architecture (security)
- Должна быть стабильной (consumer'ы строят на ней свои интеграции)
docs-internal/ — operational state:
- Runbooks меняются часто (incidents, lessons learned)
- Status snapshots — historical record для команды
- Tech deep-dives — для разработчиков, не consumers
Это разделение делает Diplodoc более фокусированным и менее шумным для consumers.