Questo è il contratto di progettazione e creazione compatto, rivolto all'intelligenza artificiale, per WebBlocks CMS. Leggetelo prima di proporre o applicare un progetto di pagina tramite Internal Content API.

Risponde a cinque domande per ogni blocco principale spedito:

1. Quali contenuti rimangono modificabili nell'amministrazione CMS?
2. Quali impostazioni e varianti condivise sono supportate?
3. Quali relazioni secondarie e multimediali sono valide?
4. Quale pubblico stabile HTML emette il renderer?
5. Quale risultato visivo può produrre il blocco senza la pagina grezza HTML?

Questo documento riepiloga il comportamento supportato dal codice sorgente. Il rilevamento delle API live rimane autorevole per ID specifici dell'installazione, plug-in abilitati, tipi di blocchi personalizzati, impostazioni internazionali, layout, record multimediali, menu di navigazione e funzionalità.

• Archivio: fklavyenet/webblocks-cms
• Filiale: main
• A commit controllato: 741a44bc0fe00bf38cae0753bd9edb02978b0dbe
• Adocumentazione di rilascio controllata: 1.40.2
• Adata di revisione: 2026-07-14
• Forma del repository: solo pacchetto Composer pacchetto
• Righe del catalogo principale pubblicate: 51
• Bozza delle righe del catalogo precedente: 7
• ARighe principali strutturate scrivibili dopo l'applicazione della policy seguente: 50
• AI righe grezze scrivibili HTML dopo l'applicazione della policy seguente: 0

Il riferimento di cui sopra è ancora l'ultimo audit completo. Queste voci sono state corrette contro la fonte in seguito invece di ricontrollare ogni blocco, quindi tratta qualsiasi cosa fuori da questo elenco come 1.40.2-era e confermalo tramite rilevamento API in tempo reale.

• card (1.40.5): esiste lo stile Carta variant. Questo documento in precedenza affermava che non esisteva alcun campo variante visiva della carta supportato, il che era sbagliato da 1.40.5 in poi.
• link-list (1.40.10): settings.row_layout e settings.list_frame.
• link-list-item (1.40.8): miniatura media_id opzionale.
• 1.91.0: relazioni immagine mobile opzionali su otto blocchi multimediali nativi.
• 1.91.1: tutte e nove le posizioni dei contenuti Slide e Slider.
• 1.93.0: Annulla/ripristina Rich Text, modalità di messa a fuoco, conteggio parole e comportamento di incollamento sicuro.
• 1.94.0–1.94.2: convalida di avvio del plug-in gestito, quarantena, pacchetti conservati e controlli di ripristino dell'account attivo.

Nota sul repository storico: l'albero CMS solo pre-pacchetto conteneva docs/feature-inventory.md, un'ampia matrice di rilevabilità delle funzionalità del prodotto. È stato rimosso quando è stato costruito l'albero del repository dei soli pacchetti e non era un inventario di creazione AI per blocco. Il contratto runtime ora risiede in resources/contracts/inventory.md.

Famiglie di origine ispezionate:

• src/Support/Blocks/CoreBlockTypeCatalogSyncer.php
• src/Support/BlockTypes/BlockTypeContractRegistry.php
• src/Support/Blocks/BlockTranslationRegistry.php
• src/Models/Block.php
• src/Http/Requests/Admin/BlockRequest.php
• src/Support/InternalContentApi/InternalContentPlanService.php
• src/Support/InternalContentApi/InternalContentApiOperations.php
• src/Http/Controllers/InternalContentApi/InternalContentResourceController.php
• src/Http/Controllers/InternalContentApi/InternalSharedSlotController.php
• src/Http/Controllers/InternalContentApi/InternalApiDiscoveryController.php
• routes/admin.php
• resources/views/admin/blocks/types/*.blade.php
• resources/views/admin/blocks/settings/*.blade.php
• resources/views/pages/partials/blocks/*.blade.php
• public/cms/css/public.css
• Test mirati dei pacchetti e documentazione attuale del prodotto

1. Utilizza blocchi strutturati. Non archiviare una pagina, una sezione, una raccolta di schede, una shell di navigazione, un modulo o un componente visivo in Trusted HTML.
2. html è una botola di fuga per soli umani. Il rilevamento API può identificarlo come non disponibile, ma nessuna mutazione API può creare, aggiornare, sostituire, spostare, riordinare, clonare, promuovere, pubblicare o eliminare un blocco HTML.
3. Non ignorare la restrizione HTML tramite Rich Text, <style>, <script>, attributi del gestore eventi, markup iframe, markup SVG, markup codificato o impostazioni inventate.
4. Utilizzare solo campi, valori enum, ruoli multimediali e relazioni secondarie documentate qui e confermate dal rilevamento in tempo reale.
5. Tratta un campo modificabile dall'amministratore come parte del contratto di creazione supportato. Un valore riconosciuto solo da un renderer o da un percorso di compatibilità legacy non è un normale campo di creazione AI.
6. Ie una regione visiva non può essere espressa con il contratto supportato, interrompi e segnala un divario di capacità. Non approssimarlo silenziosamente con blocchi non correlati e non ricorrere a HTML.
7. Il sito CSS può perfezionare la tipografia, la spaziatura, il colore, i bordi, le ombre e la presentazione reattiva attraverso hook pubblici stabili. Non deve diventare un archivio di contenuti nascosti o ricostruire il markup semantico mancante.
8. Non prendere di mira gli ID del database, gli ID dei blocchi generati, i selettori di posizione dei fratelli o :nth-child() per il comportamento di progettazione essenziale. Preferisci attributi di tipo blocco, classi wb-* native, classi del corpo della pagina e impostazioni documentate.
9. Mantieni ogni titolo, paragrafo, etichetta, pulsante, badge, immagine, didascalia, menu e impostazione del modulo visibili modificabili tramite il campo CMS nativo o il record correlato.
10. Convalidare prima, applicare solo dopo l'approvazione esplicita dell'utente, creare prima bozze e lasciare le azioni di aggiornamento del sistema in tempo reale e i test visivi in tempo reale all'operatore umano se non autorizzato separatamente.
11. Considera la scheda come una presentazione con partecipazione attiva, non come il modo predefinito per raggruppare la copia correlata. Utilizzare una carta solo per un'entità utilizzabile in modo indipendente, ripetibile o limitata come un prodotto, plug-in, piano tariffario, download o modulo.
12. Prima di scegliere i blocchi, indica una direzione di progettazione a livello di sito che copra carattere, densità, tipografia, geometria, immagini, angoli e contrasto. Fai in modo che l'albero dei blocchi e il sito CSS implementino quella direzione invece di scegliere ciascuna sezione isolatamente.
13. Varia deliberatamente il ritmo della pagina. Combina regioni strette, regolari, larghe e a larghezza intera; alterna copia silenziosa, immagini dominanti e raccolte strutturate anziché ripetere sezioni con lo stesso peso.

Il contratto del prodotto target è:

Questa policy viene applicata nel codice da una singola classe di policy del prodotto, WebBlocks\Cms\Support\BlockTypes\BlockTypeApiAuthoringPolicy. Ogni superficie API la consulta invece di ripetere la regola: entrambi i normalizzatori di blocco, PATCH del blocco esistente, creazione incrementale di pagine e Shared Slot, riordino di pagine/Shared Slot, eliminazione di sottoalbero, cancellazione di tutto Shared Slot, pubblicazione di pagine e Shared Slot, sostituzione di slot di bozza, creazione e promozione di aggiornamenti graduali, assegnazione di Shared Slot e Eliminazione della pagina API. I rifiuti avvengono prima di qualsiasi transazione o scrittura, restituiscono HTTP 422 con il codice stabile block_type_not_api_writable e non lasciano modifiche parziali. Nessuna funzionalità token lo sovrascrive.

Un progetto è gestibile dal CMS solo quando sono vere tutte le seguenti condizioni:

• Il contenuto visibile viene archiviato in campi di traduzione nativi, impostazioni, relazioni della libreria multimediale, record di navigazione, record commerciali o blocchi secondari.
• Il normale editor di blocchi espone i campi necessari per mantenere il risultato.
• Il markup pubblico proviene da un pacchetto o da un renderer di plug-in, non dal contenuto della pagina.
• La presentazione utilizza varianti documentate, impostazioni, token del tema e hook CSS stabili.
• Il riordinamento o la modifica del contenuto non richiede la modifica di HTML o CSS.
• Il comportamento mobile deriva dal renderer, WebBlocks UI, o dal sito stabile CSS anziché dal markup mobile duplicato nel contenuto.

Un renderer può riconoscere un valore legacy o interno che il normale modulo di amministrazione non espone. Tale valore è documentato come input di compatibilità, non come campo di creazione AI consigliato.

Utilizzare array children nidificati. Non inviare ID di relazione del database in un piano di contenuto.

Convenzioni del piano dei contenuti:

• Inserisci la copia di proprietà della locale direttamente in translations per la locale del piano selezionato.
• Inserisci URL, destinazione, variante di presentazione e altre opzioni condivise in settings.
• Inserisci l'assegnazione diretta della libreria multimediale in media_id.
• slide, image, hero, section, card, cta, content_header e link-list-item accetta anche un riferimento mobile_media_id di livello superiore opzionale un record della libreria multimediale di immagini. È memorizzato in block_media con il ruolo mobile_image, condiviso tra più impostazioni locali e modificabile tramite il supporto di amministrazione raccoglitrice e PATCH /blocks/{block}. Su schermi fino a 768 px di larghezza sostituisce l'immagine predefinita; a cui ricorre un'immagine mobile assente, cancellata o privata l'impostazione predefinita. Invia null per cancellarlo; ometterlo in PATCH lo preserva. Le immagini in primo piano utilizzano <picture><source media="(max-width: 768px)">; i blocchi di sfondo utilizzano uno sfondo reattivo CSS. Utilizzare un altro ritaglio del stesso aspetto visivo: testo alternativo, didascalie, posizione, adattamento, sovrapposizioni e collegamenti rimangono condiviso. Il Visualizzatore galleria del blocco Immagine continua ad aprire l'impostazione predefinita immagine a piena risoluzione. Gli elementi della Galleria, i loghi dei marchi, i video e l'audio non lo fanno accettare questo campo.
• Inserisci gli elementi della Galleria in gallery_items o gallery_media_ids.
• Utilizzare solo children nidificati; non inviare id, parent_id, block_id, slot_type_id o block_type_id.
• L'API attualmente accetta un oggetto settings di forma ampia. Quella permissività non è il permesso di inventare ambientazioni; utilizzare solo i tasti elencati di seguito.

Il rendering normale dello slot principale fornisce:

I blocchi contrassegnati come proprietario della radice inseriscono data-wb-public-block-type nella propria radice semantica. Altri blocchi di livello superiore normalmente ricevono:

I caratteri di sottolineatura si normalizzano in trattini in data-wb-public-block-type; ad esempio content_header diventa content-header.

L'attuale catalogo principale pubblicato contiene 55 righe:

Utilizzare plain per qualità, principi, vantaggi, riepiloghi dei processi e altri testi che non rappresentano oggetti indipendenti. Utilizzare cards solo quando ogni elemento ha un proprio confine significativo. Il numero di oggetti, in particolare il familiare set da tre, non è mai di per sé un motivo per scegliere le carte.

Non considerare un Blade partial come prova della disponibilità di un handle per il nuovo contenuto API. L'origine corrente contiene renderer di compatibilità e bozze di righe che non sono contratti di creazione principali pubblicati.

Le righe del catalogo bozza includono:

Gli handle solo renderer, alias, parziali o di compatibilità includono esempi come:

Regole:

• Non crearli mai semplicemente perché esiste un file renderer.
• Utilizzarli solo se il catalogo dei blocchi autenticati in tempo reale riporta l'handle esatto come pubblicato e utilizzabile per l'installazione corrente.
• Preferisci i blocchi strutturati canonici documentati sopra.
• I partial interni come il visualizzatore di gallerie e i renderer dei collegamenti della barra laterale non sono mai tipi di blocco del piano di contenuto.

Questi sono alberi di blocchi gestiti, non modelli fissi. Conferma tutti gli handle in fase di esecuzione.

Inizia dalla ricetta meno incorniciata che soddisfa il contenuto. Non ripetere la stessa ricetta in fasce di pagine adiacenti e non selezionare la ricetta della scheda caratteristica semplicemente perché la fonte contiene tre brevi elementi.

Utilizza un'immagine ampia e significativa e uno stile di superficie sobrio. Scegli layout:full-bleed quando l'immagine deve diventare una fascia di apertura senza cornice a livello di viewport; conserva split quando l'immagine è un contenuto semantico in primo piano.

Questo è il normale punto di partenza per qualità come esperienza, comunicazione, cura, velocità o affidabilità. Promuovilo su Carte solo quando gli oggetti sono utilizzabili o delimitati in modo indipendente.

Utilizzare questo solo quando la riga dell'azione deve trovarsi all'esterno della radice della promozione dell'Eroe. Hero stesso accetta i figli Button Link in ogni layout, inclusa la suddivisione; mantieni le azioni all'interno di Hero quando questa è la composizione prevista.

Ogni titolo, paragrafo e azione rimane modificabile in modo indipendente. Prenota questa ricetta per entità limitate come prodotti, plug-in, piani, download o servizi con le proprie azioni. Utilizzare il sito CSS per una skin della scheda coerente e specifica per il sito tramite ganci stabili; non iniettare la carta HTML.

Utilizza immagine per i contenuti multimediali in primo piano. Utilizza un blocco con supporto dello sfondo solo quando l'immagine è semanticamente uno sfondo.

Le etichette di navigazione e gli URL appartengono ai record di navigazione CMS, non a HTML.

Prima di applicare un design visivo, produrre una tabella di mappatura:

Per ogni regione:

1. Identifica ogni parte modificabile di testo, contenuto multimediale, azione, badge, dati di navigazione e record dinamico.
2. Mappa ogni pezzo su un campo nativo modificabile dall'amministratore.
3. Conferma le regole padre/figlio e il renderer HTML.
4. Conferma che la composizione visiva è possibile con il DOM documentato.
5. Utilizza il sito CSS solo per la presentazione che il DOM stabile può supportare.
6. Se manca un campo semantico, wrapper, slot o variante, contrassegna la regione come non supportata.
7. Proporre la più piccola funzionalità CMS o plug-in riutilizzabile: una variante del renderer, un nuovo blocco strutturato, un modello composto da blocchi esistenti o un blocco di dominio come una raccolta di prodotti Commerce.
8. Non applicare un sostituto consapevolmente a bassa fedeltà a meno che l'utente non approvi esplicitamente tale compromesso.

Formato del rapporto sul gap di capacità:

Utilizza i livelli di stile in questo ordine:

1. Primitive WebBlocks UI già emesse dal renderer.
2. Token del tema pubblico e ruoli di colore pubblico sensibili alla modalità.
3. Impostazioni e varianti del blocco nativo.
4. CSS stretto specifico per il sito utilizzando ganci stabili.
5. Un renderer riutilizzabile o una modifica del contratto di blocco quando manca il DOM richiesto.

I selettori stabili includono:

Non utilizzare il sito da CSS a:

• inserisci testo essenziale con pseudo-elementi;
• dipende dagli ID blocco generati;
• inferisce la semantica dall'ordine dei fratelli;
• nascondi il contenuto creato dal CMS semplicemente per sostituirlo con il contenuto CSS;
• ricostruire un layout mancante con posizionamento assoluto fragile;
• hardcode colori solo chiari che interrompono la modalità Chiaro/Scuro/Auto.

Questi sono risultati dell'implementazione, non autorizzazioni per inventare comportamenti:

1. Risolto: questo inventario ora viene spedito comeresources/contracts/inventory.mded è servito agli strumenti daGET /webadmin/api/inventory.
2. webblocks-cms-docs/docs/block-type-contracts.mddice 42 tipi principali pubblicati, mentre il catalogo attuale ne definisce 51.
3. Diversi documenti esistenti mostrano ancora i percorsi del renderer solo pre-pacchetto sottopackages/webblocks-cms/...; i percorsi attuali dei pacchetti iniziano daresources/views/....
4. Risolto: HTML attendibile non è più scrivibile tramite API.BlockTypeApiAuthoringPolicyblocca ogni percorso di mutazione dell'API, inclusa la normalizzazione generica, il PATCH del blocco esistente e le operazioni di riordino, eliminazione della sottostruttura, cancellazione di tutto e pubblicazione Shared Slot.
5. Risolto: Hero e CTA sono semplici contenitori perbutton_linkfigli sia nell'amministratore che nell'API. ILprimary_cta/secondary_ctai campi sopravvivono come una scorciatoia a due pulsanti. L'eredità ineditabuttonla riga del catalogo non è più un blocco della creazione.
6. Risolto: l'editor degli elementi di colonna ora espone il campo dei sottotitoli in Columnsstatsla variante viene visualizzata come valore statistico.
7. L'audio dispone di un normale selettore multimediale di amministrazione e di un renderer multimediale pubblico, ma la lista consentita dei media diretti del piano dei contenuti omette l'audio.
8. Risolto: la normalizzazione delle icone ha un proprietario.InternalContentApiOperationsdetiene il canonicoPUBLIC_ICON_BLOCK_TYPESlist più i normalizzatori slug/tone condivisi e il piano di contenuto completo delega loro, quindi i piani e gli endpoint di blocco incrementali convalidano le icone in modo identico.
9. Le impostazioni del blocco API non sono ancora regolate da uno schema di impostazioni leggibili dalla macchina per blocco. Le impostazioni sconosciute possono sopravvivere alla normalizzazione anche quando nessun renderer o campo di amministrazione le utilizza.
10. Risolto:navigation-autoora ha un contratto documentatoBlockTypeContractRegistryed è rilevabile tramite tipi di blocco e contratto di contenuto.
11. WebBlocks UI spedisce awb-footer-*anatomia (wb-footer-grid,wb-footer-brand,wb-footer-nav,wb-footer-link,wb-footer-list,wb-footer-item,wb-footer-copy,wb-footer-meta,wb-footer-text,wb-footer-logo) che nessun renderer CMS emette. Un piè di pagina con slot condiviso compone un file genericwb-section/wb-container/wb-grid/wb-stack/wb-clusterinvece, quindi il modello è raggiungibile solo da layout scritti a mano. Cosmetico dal 1.50.0 ha dato.wb-slot-footerla propria superficie; un blocco di composizione del piè di pagina rimane deliberatamente rinviato anziché in sospeso.
12. Risolto:GET /content-contractderiva il suomedia_librarysezione dalla tabella di routing registrata, quindisupported_operationsEunsupported_operationsnon può derivare da cosaopenapi.jsonpubblica. Caricamento, recupero remoto, eliminazione, sostituzione e spostamento vengono pubblicati come supportati con la funzionalità applicata da ciascun percorso.
13. Risolto: il consenso ha una metà rivolta al visitatore. L'attivazione/disattivazione del banner Impostazioni di sistema esegue il rendering del modello di consenso sui cookie di WebBlocks UI sulle pagine pubbliche e lo collega a quello esistentePOST /privacy-consent/syncpunto finale econtact_formguadagnatosettings.consent_requiredpiù un tradottoconsent_labelregistrato su ogni invio.
14. Il repository dispone di screenshot della dashboard e della gestione delle pagine, ma non di una galleria di dispositivi visivi canonici per blocco/per variante. Le descrizioni di "Aspetto di esempio" in questo inventario sono quindi riferimenti dorati derivati ​​dalla fonte e non supportati da screenshot. Fino a quando non esisterà quella galleria, preferisci composizioni neutre documentate ed evita di rivendicare la fedeltà visiva solo dalla prosa.
15. Risolto per la pianificazione:GET /content-contractora pubblica un contratto di direzione del design leggibile dalla macchina che copre carattere, densità, tipografia, geometria, immagini, angoli, contrasto, ruoli ritmici, politica delle carte e lacune compositive note. Non persiste deliberatamente un record di stile nascosto; Gli strumenti di intelligenza artificiale indicano la direzione nel loro piano/rapporto e la implementano attraverso scelte di blocchi supportati, token tematici e sito stabile CSS.

Il prodotto possiede questo contratto di runtime. Il repository della documentazione conserva uno snapshot della versione generata con un'identità di origine distinta; le modifiche iniziano nel contratto del prodotto.

Da CMS 1.94.3, composer test:inventory e composer test:docs convalidano resources/contracts/inventory-review.json rispetto al contratto corrente e alle impronte digitali dell'origine runtime. I file runtime modificati, aggiunti o rimossi e le modifiche alla versione del prodotto richiedono una nuova revisione esplicita. CI e pre-push eseguono lo stesso controllo; la preparazione del rilascio controlla l'albero di lavoro e il generatore di artefatti controlla l'albero Git selezionato.

Dopo aver esaminato i campi supportati, le enumerazioni, i figli, i media, il rendering, il comportamento dell'editor, le autorizzazioni e il ciclo di vita del plug-in, aggiorna questa prosa e registra la revisione con composer inventory:review -- --reviewed --note="review summary". Un contratto invariato dopo un cambio di fonte viene accettato solo con una spiegazione esplicita --no-authoring-impact="reason". I record di revisione non devono mai essere aggiornati automaticamente dall'elemento della configurazione o dagli script di rilascio.

Il record meccanico acquisisce il catalogo principale pubblicato, le regole secondarie, la proprietà root del renderer, la policy di scrittura API e il supporto multimediale mobile da parte degli assistenti del prodotto reali. PHPUnit confronta questo record con gli attuali helper e il controllo del codice sorgente richiede un'intestazione di inventario univoca per ogni blocco principale pubblicato. Le impronte digitali e i confronti meccanici impongono la revisione e la coerenza strutturale; non dimostrano il significato di ogni frase. Le spiegazioni in prosa e senza impatto rimangono responsabilità del collaboratore e del revisore.

tools/inventory-snapshot.php del repository della documentazione rigenera lo snapshot e la relativa provenienza inventory-source.json. I suoi controlli rifiutano le modifiche manuali alle istantanee e confrontano la versione del prodotto, l'impronta digitale di origine, il checksum delle revisioni e il contenuto del documento con il checkout del prodotto selezionato. I controlli isolati della documentazione verificano la provenienza registrata senza richiedere il prodotto in fase di esecuzione. La generazione di snapshot e la pubblicazione del CMS rimangono operazioni separate.

• webblocks-cms-docs/docs/ai-page-building-guide.md
• webblocks-cms-docs/docs/internal-content-api.md
• webblocks-cms-docs/docs/api-discovery.md
• webblocks-cms-docs/docs/block-type-contracts.md
• webblocks-cms-docs/docs/public-block-render-markup.md
• webblocks-cms-docs/docs/block-ui-renderer-contract.md
• webblocks-cms-docs/docs/public-theme-and-tones.md
• webblocks-cms-docs/docs/public-assets.md
• webblocks-cms-docs/docs/media-image-variants.md

Questo inventario dovrebbe essere il primo documento letto da un'intelligenza artificiale per la selezione della funzionalità di progettazione della pagina. I riferimenti dettagliati rimangono utili per i flussi di lavoro degli endpoint, la compatibilità storica e le note complete sul renderer.

L'installazione del catalogo e del ZIP, gli aggiornamenti e l'attivazione del pannello/API convalidano l'origine del plug-in, avvio, comandi e percorsi del provider in un nuovo processo PHP tramite cms:plugin-probe. La convalida è richiesta anche quando non è in sospeso alcuna migrazione. Una sonda non riuscita o scaduta lascia attivo il pacchetto corrente; la diagnostica del sottoprocesso non viene esposta nelle risposte. Il timeout di avvio predefinito è 30 secondi (webblocks-plugins.install.boot_timeout_seconds).

Gli aggiornamenti riusciti mantengono il pacchetto precedente e registrano se le migrazioni sono state eseguite. Gli errori di configurazione del database lasciano il plugin disabilitato e ne preservano le tabelle e i pacchetti. Gli errori di origine/percorso di runtime mettono in quarantena il plug-in; una disabilitazione esplicita ha la priorità abilitazione basata sulla configurazione. I record JSON del ciclo di vita utilizzano la sostituzione atomica.

/webadmin/plugin-recovery e il relativo modulo di accesso vengono caricati senza la sorgente del plug-in installata, percorsi o comandi. Controlli di accesso CMS esistenti, accesso amministratore attivo, autorizzazione Super admin e CSRF si applica la protezione. Il ripristino può disabilitare un plug-in o ripristinare il pacchetto conservato quando non è stata eseguita alcuna migrazione, dopo un'altra verifica di avvio. Un ripristino ripubblica anche le relative risorse. Si tratta del ripristino per i pacchetti gestiti da CMS; non isola i fornitori host arbitrari o eseguibile sandbox PHP. La terminazione del processo non catturabile richiede ancora il file separate richiesta di ripristino anziché un gestore di errori in-process.

GET /webadmin/api/system/health richiede la capacità da abilitare esplicitamente system-health.read e un token di sistema valido per l’intera installazione (allowed_site_ids: null), appartenente a un operatore attivo con access-system. Le credenziali personali e limitate ai siti non possono leggere lo stato dell’installazione. Il parametro facoltativo e validato site_id filtra i controlli dei siti mantenendo visibili quelli dell’intera installazione.

L’endpoint restituisce chiavi e parametri di messaggi sicuri, problemi ordinati, stati delle categorie (healthy, warning, critical, unknown, not_applicable), riepiloghi dei siti, informazioni di sistema ed esiti recenti delle operazioni. Le osservazioni su siti, backup, archiviazione, plugin, idoneità all’aggiornamento e cronologia vengono memorizzate nella cache per cinque minuti; le prove dello scheduler vengono lette a ogni richiesta. I controlli sconosciuti e facoltativi restano distinti da quelli riusciti. Leggere o aggiornare lo stato non modifica contenuti, riconcilia record dei backup, invia posta, esegue pulizia o aggiornamenti, recupera metadati delle versioni né genera prove dello scheduler. I componenti di report dei plugin conservano il contratto esistente per i report sullo stato; i messaggi grezzi e i dettagli delle eccezioni sono esclusi da questa vista.

Le rotte operative esistenti restano disponibili. Le destinazioni Aiuto dei plugin si uniscono a Sistema e quelle di Manutenzione vengono aggregate tramite la chiave stabile del gruppo di manutenzione; la voce Aiuto principale rimanda direttamente alla documentazione. Lo stato è una prova da esaminare, non un’autorizzazione a pubblicare contenuti, ripristinare un backup o aggiornare un host. I controlli della ricerca confrontano gli ambiti idonei di pagine pubblicate e lingue con le righe dell’indice; non dimostrano l’aggiornamento del testo. La disponibilità dei backup non dimostra l’integrità del ripristino. L’idoneità all’aggiornamento rimane distinta dal normale funzionamento del sito.