AI_CODING_POLICY.md задає командний baseline
AI_CODING_POLICY.md — це коротка командна домовленість про безпечне застосування Claude Code, а не заміна детальним RISK_CLASSIFICATION.md, QUALITY_GATES.md чи Production Decision Gate. Її мета — прибрати різне трактування дозволених, контрольованих і заборонених дій.
Policy має бути достатньо короткою, щоб нею користувалися у щоденній роботі, і достатньо конкретною, щоб зрозуміло було, коли потрібен review або явне людське схвалення.
| Категорія | Приклади |
|---|---|
| Дозволено | Аналіз, пояснення коду, чернетки docs, PR-нотатки, локальний refactor із тестами |
| Потрібен review | Функціональний код, config, dependencies, shared hooks/plugins, write-capable MCP, public API |
| Human approval | Production deploy, destructive DB actions, force push, IAM, secrets, shared infrastructure |
Що повинна охоплювати policy
- класи використання AI та дозволені permission modes;
- обмеження для secrets, personal data і customer data;
- вимоги до PR та attribution AI assistance;
- правила схвалення plugins і MCP;
- межі CI/CD automation і захист гілок;
- дозволені середовища для експериментів: branch, worktree, staging;
- відповідальність людини за merge і release.
Policy потребує технічного enforcement
Документ сам по собі не блокує небезпечну дію. Командний baseline слід підсилювати session permissions, team-level settings, hooks, protected paths, branch protection і посиланням із CLAUDE.md.
Наприклад, force push і редагування .env можна блокувати, а публікацію пакета або зміни платіжного коду переводити в режим explicit approval.
- текст policy пояснює очікувану поведінку;
- permissions і hooks забезпечують технічну межу;
- quality gates перевіряють результат;
- human owner приймає фінальне рішення.
Як оновлювати policy за сигналами процесу
Policy варто змінювати через повторювані командні проблеми, а не через одиничну помилку. Командні зміни оформлюйте через PR і короткий changelog, щоб було видно, чому правило зʼявилося.
| Повторювана проблема | Місце покращення |
|---|---|
| Відсутні AI-нотатки в PR | PR template і policy |
| Хибне спрацювання reviewer-agent | SKILL.md або конфігурація агента |
| Force push або доступ до protected path | Policy, permissions і hooks |
| Невдалий shared workflow asset | README, changelog і rollout rules |
Перевірка готовності policy
- чи однозначно зрозуміло, що дозволяється без додаткового погодження;
- чи названі дії, для яких потрібен review;
- чи визначено, що неможливо без human approval;
- чи описано заборонені дані та середовища;
- чи вказано перевірки перед merge;
- чи названо відповідального за фінальне рішення;
- чи відомо, якими технічними механізмами policy enforced.
Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush