BC requirements-clarification

Уточните материальное решение пользователя по продукту перед существенными обязательствами по реализации. Используйте только тогда, когда запрос и названные/управляющие доказательства оставляют выбор, который существенно изменит объем, поддержку платформы, пользовательский интерфейс, контракт данных/API, значения доменов, размещение проекта или межсистемную архитектуру; также используйте, когда усеченный запрос опускает такой выбор. В первом обращении просматривайте только названные или управляющие требования, затем спрашивайте напрямую без загрузки: предпочитайте структурированный ввод; задайте один блокирующий вопрос о результате или максимум три связанных вопроса; подождите. После ответа загрузите тело перед записью или делегированием. Не используйте для работы по реализации/сборке/исправлению/отладке/рефакторингу, когда ожидаемое поведение установлено, deliverables плана/дизайна принадлежат Плану, только сложность/greenfield/интеграция, технические решения, принадлежащие агенту, локально обнаруживаемые факты, обратимые значения по умолчанию, разрешение на начало или остановка/отсутствие инструментов. Никогда не переспрашивайте предоставленные факты и не превращайте уточнение в отказ.

машинный переводПоказать оригиналСкрыть оригинал«Clarify a material user-owned product decision before substantive impl…»

Clarify a material user-owned product decision before substantive implementation commitments. Use only when request and named/governing evidence still leave a choice that would materially change scope, platform support, user-facing surface, data/API contract, domain values, project placement, or cross-system architecture; also use when a truncated request omits such a choice. On the initial turn, inspect only named or governing requirements evidence, then ask directly without loading: prefer structured input; ask one blocking outcome question or at most three coupled questions; wait. After the answer, load the body before write or delegation. Do not use for implement/build/fix/debug/refactor work when expected behavior is settled, plan/design deliverables owned by Plan, complexity/greenfield/integration alone, agent-owned technical choices, locally discoverable facts, reversible defaults, permission to begin, or stop/no-tool turns. Never re-ask supplied facts or turn clarification into refusal.

Уточните материальное решение пользователя по продукту перед существенными обязательствами по реализации.

Как процесс C 62/100 · Есть пробелы — слабые места: результат и критерий готовности, ошибки и развилки, повторный запуск