Contributing

This section is for people who want to make CephalonEngine better — adding capabilities, contributing a new companion package, fixing bugs, improving docs. If you only want to build an app with CephalonEngine, you want Guide and Tutorials.

Start here

Set up the dev environment

Clone, restore, build, test. Local package feed, scripts, and the AGENTS conventions.

Set up Rules

Engineering standards

The non-negotiables — naming, async style, exception hygiene, test coverage, allocation budget.

Read the standards Modules

Module authoring

How to write a CephalonEngine module that other apps can rely on.

Author a module Companions

Observability provider authoring

The shared telemetry contract, diagnostics conventions, and planning language for new provider companions.

Author a provider Packaging

Package publishing

How CephalonEngine packages get versioned, signed, and shipped.

Publish a package Lifecycle

External package lifecycle

How third-party-shipped companions stay aligned with the engine surface.

Read the lifecycle Quality

Testing strategy

Composition smoke tests, behavior specs, integration tests, performance benchmarks.

Adopt the strategy Quality

Benchmarking

Cephalon.Benchmarks — BenchmarkDotNet suite, hot-path gates, regression discipline.

Run benchmarks Process

Release process

How a CephalonEngine version is cut, signed, and announced.

Read the process Process

Pull-request process

Branch shape, commit messages, review gates, when to ship vs. when to land later.

Read the process Community

Code of conduct

Expected behaviour for everyone working on or with CephalonEngine.

Read the CoC

How CephalonEngine grows

CephalonEngine has a small core and a wide catalogue. Contributions land in three lanes:

1. Engine + abstractions — the smallest surface, most cautious cadence. Changes require a roadmap-level rationale.
2. Companion packages — opt-in capabilities. Most contributions land here.
3. Tooling — CLI, scaffolding, reference-docs.

Every contribution carries a maturity label (M0–M4) and a graduation criterion. Many contributions ship as M2 first and graduate to M3/M4 as adoption demonstrates the path is broad enough.

Required reading before a PR

• Engineering standards — the non-negotiables.
• Testing strategy — what tests every PR must include.
• Pull-request process — branch shape, review gates.
• Code of conduct — non-optional.

Everything else is context that helps you frame the change.