Phase 0
Spikes and prototypes — tooling, deterministic I/O, publishing rails, CLI spikes.
Select the language version of the current page.
Coretsia is being built around canonical release tracks — from micro to enterprise — so the architectural core does not need to be reinvented as systems grow. Deterministic, modular, and designed for long-lived codebases.
CANONICAL RELEASE TRACKS, ONE ARCHITECTURAL CORE
A framework monorepo built around deterministic behavior, strict boundaries, documented release tracks, and SSoT formalization
Coretsia is being built around canonical mode presets and release tracks. The documented mode set is MICRO, EXPRESS, HYBRID, and ENTERPRISE. Framework presets are kernel-owned, while project-specific overrides remain user-owned in the skeleton.
The same input data → the same result. Artifacts are compiled and verified, tests stay stable, and builds remain reproducible.
Core invariants are being cemented through SSoT docs, registries, and gates. The index is fixed as the single entrypoint, while registries and contracts expand phase by phase as the roadmap advances.
Secret leakage rails, observability policy, problem-details, middleware taxonomy, and runtime safety are treated as first-class architecture concerns — not last-minute patches.
Coretsia follows a public roadmap built around SSoT. Prelude established repo bootstrap, packaging law, and canonical workflows; Phase 0 and beyond build the framework in strict order.
Spikes and prototypes — tooling, deterministic I/O, publishing rails, CLI spikes.
Core: contracts, foundation, kernel, container, and baseline platform invariants.
Mode infrastructure and CLI — tag-first command catalog, mode presets, kernel facade.
Release: micro — HTTP runtime, observability, error handling, and routing.
Release: express — web + persistence + I/O (validation, filesystem, database, migrations, auth).
Release: hybrid — asynchronous patterns, queue, events, scheduler, CQRS, secrets, enterprise E2E.
Release: enterprise — observability, caching, realtime protocols, AI/LLM gateway, advanced ops tooling.
Ops (non-SSoT) — IaC templates, CI/CD, zero-downtime strategies, ops guide for HTTP/2+3.
Spikes and prototypes — tooling, deterministic I/O, publishing rails, CLI spikes.
Core: contracts, foundation, kernel, container, and baseline platform invariants.
Mode infrastructure and CLI — tag-first command catalog, mode presets, kernel facade.
Release: micro — HTTP runtime, observability, error handling, and routing.
Release: express — web + persistence + I/O (validation, filesystem, database, migrations, auth).
Release: hybrid — asynchronous patterns, queue, events, scheduler, CQRS, secrets, enterprise E2E.
Release: enterprise — observability, caching, realtime protocols, AI/LLM gateway, advanced ops tooling.
Ops (non-SSoT) — IaC templates, CI/CD, zero-downtime strategies, ops guide for HTTP/2+3.
FIRST PUBLIC RELEASE TRACK: MICRO · EVERYTHING IS DOCUMENTED IN SSOT — NO GUESSWORK
The public docs define not only what Coretsia aims to become, but also how the monorepo is structured, how packages are named, and how contributors are expected to work.
Package identity is fixed as path ↔ package_id ↔ composer ↔ namespace. Publishable units are packages; tools, docs, and the default skeleton are not release units.
Core holds contracts, foundation, and kernel. Platform adds built-in framework capabilities. Integrations carry vendor-specific adapters. Presets are convenience packages, not runtime modes.
The skeleton is split into web, api, console, and worker apps, with shared config, modules, resources, var, and tests layered around them.
Contributor entrypoints are fixed at the repository root: composer setup, composer test, and composer ci. Managed Composer repositories are part of the enforced workflow.
Coretsia docs already define the roadmap, packaging law, structure, SSoT entrypoint, and contributor workflows. Start with the canonical entrypoints below.
Canonical phase order from Prelude and SPIKES through CORE, mode infrastructure, and release tracks.
OPEN DOC →The canonical package identity model, publishable-units law, and monorepo versioning policy.
OPEN DOC →The layer model, framework versus skeleton boundaries, and the app topology for web, api, console, and worker.
OPEN DOC →The single navigation entrypoint for SSoT documents, with deterministic ordering and fixed registration rules.
OPEN DOC →The fastest canonical path from clean clone to a green baseline using the repository entrypoints.
OPEN DOC →The contributor checklist for environment setup, green baseline, and day-to-day workflow laws.
OPEN DOC →Rules for local pre-commit hooks and related checks that keep the monorepo workflow enforced and predictable.
OPEN DOC →An overview of layers, allowed dependency directions, and how to read the architectural package graph.
OPEN DOC →Coretsia is built by developers for developers. Have feedback, feature ideas, or simply want early access? Write to us.