# TASK 1.1: Define split admin flow and credential-trigger boundaries

## Summary

Define and lock the new admin flow boundary where customer create and update persist only customer data, while credential create and update become the only provisioning triggers.

This task exists to prevent later ambiguity about which endpoints own warehouse side effects and to align the backend contract with the frontend split flow.

## Dependencies

- none

## Files to Modify

Expected implementation touch points:

- `backend/Kds.Ai.ApiService/Endpoints/AdminCustomerEndpoints.cs`
- `backend/Kds.Ai.ApiService/Services/CustomerManagementService.cs`
- frontend admin customer and credential flow files under `Front/`
- related admin API tests under `backend/tests/Kds.Ai.ApiService.Tests/`

## Required Behavior

- `POST /admin/customers` and `PUT /admin/customers/{id}` must persist customer data and membership only.
- Customer create and update must no longer perform synchronous warehouse provisioning.
- Customer create and update must no longer be the main path for credential writes.
- `POST /admin/customers/{customerId}/api-keys` and `PUT /admin/customers/{customerId}/api-keys/{credentialId}` become the provisioning trigger points.
- `DELETE /admin/customers/{customerId}/api-keys/{credentialId}` must not trigger warehouse bootstrap or warehouse cleanup.
- Frontend flow must be updated immediately to use separate writes for customer basics and credentials.

## Acceptance Criteria

- [ ] Customer create/update ownership is defined as customer data plus membership only
- [ ] Credential create/update ownership is defined as the provisioning trigger path
- [ ] Credential delete behavior is defined as no bootstrap and no cleanup
- [ ] Frontend split flow is part of the task scope

## Notes

- Keep this task focused on endpoint and ownership boundaries.
- Do not design warehouse async state storage in this task; that belongs in TASK 1.2.