Перейти к основному содержимому
ОфициальныйSwiftObjective-C

Реализация сброса AIBuds

Добавьте в iOS-приложение защищённый сброс через публичный DeviceCommonAPI.

Установить навык

Скачайте полный проверенный пакет: исходный Markdown не включает вспомогательные материалы.

Скачать проверенный ZIP
1. Скачайте

Сохраните ZIP, не изменяя содержимое.

2. Распакуйте

Распакуйте папку навыка в одно из расположений:

~/.codex/skills/implement-aibuds-factory-reset%USERPROFILE%\.codex\skills\implement-aibuds-factory-reset
3. Вызовите

Используйте команду вызова в следующем сообщении Codex.

$implement-aibuds-factory-reset

После установки навык станет доступен в следующем сообщении.

Проверенный пакетSHA-256ff3a1c2f7a4c36b1f31c75621cafc7ea8b2a4628d2db03700ed683209a22d299
SKILL.md

Implement AIBuds Factory Reset

Add factory reset to the consumer application's existing device experience without replacing its connection architecture or UI framework.

Workflow

  1. Read references/implementation.md completely.
  2. Inspect how the application stores the connected DeviceConvertible, presents destructive confirmations, reports errors, and observes connection changes.
  3. Confirm that the target already has a connected-device flow. If it does not, explain that prerequisite instead of inventing a second device manager.
  4. Add an explicit destructive-action confirmation using the application's existing UI conventions.
  5. Check DeviceCommonAPI conformance before enabling or executing the action.
  6. Call factoryReset(_:) only after confirmation. Handle both success and nullable error, and return to the main queue before changing UI.
  7. Keep observing the application's existing SDK connection/state callbacks. Do not use a fixed delay or promise identical reset, restart, erasure, or re-pair behavior across devices.
  8. Add focused verification for unsupported devices, cancellation, success, failure with an error, and failure with a nil error.

Constraints

  • Use only public AIBuds SDK API.
  • Preserve unrelated application code and architecture.
  • Prevent duplicate submissions while the request is in flight.
  • Do not force-cast protocol support.
  • Do not expose raw implementation or transport concepts to application code.
  • Do not claim device-specific side effects unless the product specification supplied by the developer guarantees them.

Completion criteria

  • Unsupported devices cannot execute the operation.
  • The user must explicitly confirm the destructive action.
  • Success and failure both produce stable UI feedback on the main queue.
  • A nil error cannot crash or produce an empty failure message.
  • Follow-up state comes from SDK callbacks rather than timing assumptions.