Phase 0
Spikes e prototipi — tooling, I/O deterministico, publishing rails, CLI spikes.
Seleziona la versione linguistica della pagina corrente.
Coretsia viene costruito attorno a release tracks canonici — da micro a enterprise — così che il nucleo architetturale non debba essere reinventato man mano che i sistemi crescono. Deterministico, modulare e progettato per codebase di lunga durata.
RELEASE TRACKS CANONICI, UN SOLO NUCLEO ARCHITETTURALE
Un framework monorepo costruito attorno a comportamento deterministico, confini rigorosi, release tracks documentati e formalizzazione SSoT
Coretsia viene costruito attorno a mode presets canonici e release tracks. L'insieme documentato delle modalità è MICRO, EXPRESS, HYBRID ed ENTERPRISE. I presets del framework appartengono al kernel, mentre gli overrides specifici del progetto restano di proprietà dell'utente nello skeleton.
Gli stessi dati di input → lo stesso risultato. Gli artifacts vengono compilati e verificati, i tests restano stabili e le builds rimangono riproducibili.
Gli invariants del Core vengono consolidati tramite docs SSoT, registries e gates. L'index è fissato come entrypoint unico, mentre registries e contracts si espandono phase dopo phase man mano che la roadmap avanza.
Secret leakage rails, observability policy, problem-details, middleware taxonomy e runtime safety vengono trattati come aspetti architetturali di prima classe — non come patch applicate all'ultimo momento.
Coretsia segue una roadmap pubblica costruita attorno a SSoT. Prelude ha stabilito repo bootstrap, packaging law e workflows canonici; Phase 0 e quelli successivi costruiscono il framework in ordine rigoroso.
Spikes e prototipi — tooling, I/O deterministico, publishing rails, CLI spikes.
Core: contracts, foundation, kernel, container e invariants di base della Platform invariants.
Infrastruttura delle modalità e CLI — catalogo comandi tag-first, mode presets, kernel facade.
Release: micro — runtime HTTP, observability, gestione degli errori e routing.
Release: express — web + persistenza + I/O (validation, filesystem, database, migrations, auth).
Release: hybrid — pattern asincroni, queue, events, scheduler, CQRS, secrets, enterprise E2E.
Release: enterprise — observability, caching, realtime protocols, AI/LLM gateway, tooling ops avanzato.
Ops (non-SSoT) — IaC templates, CI/CD, strategie zero-downtime, guida ops per HTTP/2+3.
Spikes e prototipi — tooling, I/O deterministico, publishing rails, CLI spikes.
Core: contracts, foundation, kernel, container e invariants di base della Platform invariants.
Infrastruttura delle modalità e CLI — catalogo comandi tag-first, mode presets, kernel facade.
Release: micro — runtime HTTP, observability, gestione degli errori e routing.
Release: express — web + persistenza + I/O (validation, filesystem, database, migrations, auth).
Release: hybrid — pattern asincroni, queue, events, scheduler, CQRS, secrets, enterprise E2E.
Release: enterprise — observability, caching, realtime protocols, AI/LLM gateway, tooling ops avanzato.
Ops (non-SSoT) — IaC templates, CI/CD, strategie zero-downtime, guida ops per HTTP/2+3.
PRIMA RELEASE TRACK PUBBLICA: MICRO · TUTTO È DOCUMENTATO IN SSOT — SENZA CONGETTURE
La documentazione pubblica definisce non solo ciò che Coretsia vuole diventare, ma anche come è strutturato il monorepo, come vengono nominati i packages e come ci si aspetta che lavorino i contributors.
L'identità del package è fissata come path ↔ package_id ↔ composer ↔ namespace. Le publishable units sono i packages; tools, docs e lo skeleton predefinito non sono release units.
Core contiene contracts, foundation e kernel. Platform aggiunge funzionalità integrate del framework. Integrations contiene adapters vendor-specific. Presets sono convenience packages, non runtime modes.
Lo skeleton è suddiviso in web, api, console e worker apps, con config, modules, resources, var e tests condivisi stratificati attorno ad esse.
Gli entrypoints per i contributors sono fissati nella root del repository: composer setup, composer test e composer ci. I managed Composer repositories fanno parte del workflow imposto.
La documentazione di Coretsia definisce già la roadmap, il packaging law, la structure, l'entrypoint SSoT e i workflows dei contributors. Inizia dagli entrypoints canonici qui sotto.
Ordine canonico delle phase da Prelude e SPIKES fino a CORE, mode infrastructure e release tracks.
APRI IL DOC →Il modello canonico di package identity, il publishable-units law e la policy di versioning del monorepo.
APRI IL DOC →Il modello a strati, i confini fra framework e skeleton e la topologia delle app per web, api, console e worker.
APRI IL DOC →L'unico navigation entrypoint per i documenti SSoT, con ordinamento deterministico e registration rules fisse.
APRI IL DOC →Il percorso canonico più rapido da clean clone a green baseline usando gli entrypoints del repository.
APRI IL DOC →La checklist per i contributors su environment setup, green baseline e regole del workflow quotidiano.
APRI IL DOC →Regole per i pre-commit hooks locali e per i controlli correlati che mantengono il workflow del monorepo imposto e prevedibile.
APRI IL DOC →Una panoramica dei layer, delle direzioni di dependency consentite e di come leggere il graph architetturale dei packages.
APRI IL DOC →Coretsia è costruito da sviluppatori per sviluppatori. Hai feedback, idee per funzionalità o vuoi semplicemente un accesso anticipato? Scrivici.