Phase2.5: Skill SetUp Process
All checks were successful
Build and Push / build (push) Successful in 1m39s
All checks were successful
Build and Push / build (push) Successful in 1m39s
This commit is contained in:
@@ -57,6 +57,25 @@ export interface PackageDef {
|
||||
* that the customer is not aware of.
|
||||
*/
|
||||
customProvisioning?: boolean;
|
||||
/**
|
||||
* When true, customer-initiated enable requests are routed through
|
||||
* an admin approval queue (skill_activation_requests) instead of
|
||||
* being applied immediately. Platform-side manual work (hardware
|
||||
* provisioning, third-party account setup, DNS, etc.) happens
|
||||
* between request and approval, so we keep the tenant out of the
|
||||
* spec until that work is done and the operator would otherwise
|
||||
* fail to reconcile.
|
||||
*
|
||||
* Platform admins bypass the gate (direct PATCH from /admin still
|
||||
* applies immediately). Disable is always direct — there's no
|
||||
* gate on turning a skill off.
|
||||
*
|
||||
* Orthogonal to `requiresSecrets` and `customProvisioning`. A skill
|
||||
* can have all three: customer provides credentials, the secrets
|
||||
* are stored, the activation request lands in the admin queue,
|
||||
* admin does the manual work, then approves.
|
||||
*/
|
||||
requiresManualSetup?: boolean;
|
||||
}
|
||||
|
||||
export const PACKAGE_CATALOG: PackageDef[] = [
|
||||
|
||||
Reference in New Issue
Block a user