Facilitatore rotante riunioni

Nomi vuoti o indici negativi falliscono con invalid_input e non vengono fatturati.

Come funziona la titolarità rotante della riunione

Una rotazione equa dei facilitatori non è altro che un elenco ordinato fisso di persone e un contatore di quante volte la riunione si è già tenuta. Poiché la formula usa solo il resto della divisione intera, due client che condividono lo stesso ordine di roster e lo stesso contatore di occorrenza concordano sempre sullo stesso titolare anche in fusi orari diversi o offline. La capacità non inventa festività, ferie o elenchi di salti: se qualcuno è assente, modifichi il roster o avanzi l'indice nel suo strato di orchestrazione. Mantenere il nucleo puro consente a chatbot, GitHub Actions e plugin di fogli di riusare un unico oracolo invece di ricodificare la logica modulo in tre linguaggi. Indicizzi la prima occorrenza come meeting_index zero, la seconda come uno, e così via. Se il roster ha N persone, il titolare di quell'occorrenza si trova a owner_index uguale a meeting_index modulo N. Quando il contatore raggiunge N, il resto torna a zero e la prima persona facilita di nuovo; a N più uno, la seconda prende la sedia, e lo schema continua senza casi speciali per settimane bisestili o mesi del calendario. La posizione nel ciclo è riportata come owner_index più uno così che si possa dire «terzo di quattro in questo ciclo» senza convertire a mano indici a base zero. Il titolare successivo è il nome a owner_index più uno modulo N; il precedente avvolge nell'altro senso, utile quando Lei deve chiedere appunti al facilitatore della settimana scorsa.

Contratto di ingresso, campi di risposta ed errori di validazione

I campi di uscita opzionali non vengono mai riempiti con null: in questo contratto semplice ogni campo di successo è sempre presente. Invii con POST un corpo JSON con due campi obbligatori. roster è un array non vuoto da una a cento stringhe di nomi di facilitatore in ordine di rotazione; ogni voce viene trimmata e le stringhe vuote dopo il trim sono rifiutate come invalid_input indicando l'indice errato. meeting_index è un intero non negativo da zero a un miliardo che identifica quale occorrenza della serie sta risolvendo—zero è la prima riunione. Gli alias members, people e facilitators sono accettati per roster, e index, occurrence e week_number per meeting_index, così che l'automazione esistente possa mappare chiavi familiari senza rinominare i payload. In caso di successo il corpo riecheggia il roster normalizzato e meeting_index, roster_size, owner e owner_index, cycle_position (base uno nel ciclo), next_owner e next_owner_index, previous_owner e previous_owner_index, più una breve stringa di formula che afferma owner_index uguale a meeting_index mod roster_size. Esempio: roster Alice, Bob, Carol, Dana con meeting_index cinque produce owner_index uno perché cinque modulo quattro è uno, quindi Bob facilita, Carol è il successivo e Alice il precedente. Roster assente, vuoto, non array, meeting_index non intero o negativo, e roster troppo grandi falliscono con invalid_input e non consumano saldo.

Dove un'API di facilitatore rotante crea valore

I bot di product ops pubblicano messaggi «il facilitatore di questa settimana è …» in Slack o Teams chiamando l'API con l'indice della serie memorizzato in una chiave contatore. Poiché l'implementazione è parse di livello A, ogni chiamata riuscita costa il prezzo base pubblicato $0.002 senza token di modello né rete in uscita; la validazione fallita è gratuita. Mantenga il roster nello stesso ordine in ogni sistema di record, incrementi meeting_index una volta per occorrenza (incluse le settimane saltate se vuole che la rotazione avanzi) e otterrà decisioni di titolarità riproducibili per calendari, runbook e edge worker senza erigere un servizio di pianificazione proprio.